Control channel security for realm specific internet protocol

Details Control channel security for realm specific internet protocol Control channel security for realm specific internet protocol

2000-08-09

2002-03-05

Trammell, James P. (Department: 2161)

Electrical computers and digital processing systems: support

Multiple computer communication using cryptography

Protection at a particular protocol layer

Reexamination Certificate

active

06353891

ABSTRACT:

FIELD OF INVENTION
This invention relates to computer networks, network addressing, and network security. More specifically, it relates to a security system and method for use with the Realm Specific Internet Protocol (RSIP).
BACKGROUND OF THE INVENTION
Internet Protocol (IP) is an addressing protocol designed to facilitate the routing of traffic within a network or between networks. IP is used on many computer networks including the Internet, intranets and other networks. Current versions of IP, such as IP version-4 (IPv4), are becoming obsolete because of limited address space. With a 32-bit address-field, it is possible to assign 2
32
different addresses, which is 4,294,967,296, or greater than 4 billion globally unique addresses.
However, with the explosive growth of the Internet and intranets, IP addresses using a 32-bit address-field may soon be exhausted. IP version-6 (IPv6) proposes the use of a 128-bit address-field for IP addresses. A large number of legacy networks, however, including a large number of Internet subnets, will still be using older versions for IP with a 32-bit address space for many years to come.
Network Address Translation (NAT) has been proposed to extend the lifetime of IPv4 by allowing subnets to exist behind a single or small number of globally unique IP addresses (see, e.g., Internet Engineering Task Force (IETF) Requests For Comments (RFC) 2663). A single global IP address is used for communication with external networks, such as the Internet. Internally, a sub-network (“subnet”) uses local addressing. Local addressing may be either any addressing scheme that is different from IP addressing, or a non-unique usage of IP addresses. In either case, local addresses on a subnet are not used on the external, global Internet. When a device or node using local addressing desires to communicate with the external world, its local address is translated to a common external IP address used for communication with an external network by a NAT device. That is, NAT allows one or more global IP addresses to be shared among a larger number of local addresses.
There are several problems associated with using NAT to extend the life of the IP. NAT interferes with the end-to-end routing principal of the Internet which recommends that packets flow end-to-end between network devices without changing the contents of any packet along a transmission route (see e.g., “Routing in the Internet,” by C. Huitema, Prentice Hall, 1995, ISBN 0-131-321-927).
Current versions of NAT replace a local network address in a data packet header with an external global network address on outbound traffic, and replace an external network address in a data packet header with a local network address on inbound traffic. This type of address translation is computationally expensive, causes security problems by preventing certain types of encryption from being used, or breaks a number of existing applications in a network that cannot provide NAT (e.g., File Transfer Protocol (“FTP”)). Such computational burdens placed on a NAT router may be significant and degrade network performance, especially if several NAT-enabled sub-networks share the same NAT router. In a worst case scenario, a NAT router translates every inbound and outbound data packet.
RSIP is a technology that can replace NAT and overcome many of the problems associated with NAT. For instance, unlike NAT, RSIP does not break the end-to-end nature of a packet flow; thus, it is able to operate without application layer gateways and can support end-to-end IP security (IPSEC). RSIP implementations may consist of both a host and a gateway component. The host portion resides in an end-user device (e.g., a PC), while the gateway portion resides in a boundary router between the host's administrative domain and a public IP network (e.g., the Internet). For more information on RSIP, see “Realm Specific IP: Protocol Specification,” by M. Borella and D. Grabelsky, IETF Internet Draft <draft-ietf-nat-rsip-protocol-06.txt>, March 2000, which is specifically incorporated in its entirety herein by reference.
RSIP uses a Transmission Control Protocol (TCP) or a User Datagram Protocol (UDP) control channel to negotiate the leasing of public addressing parameters, such as IP addresses and TCP/UDP ports, from an RSIP gateway to privately-addressed RSIP host devices. For more information on TCP and UDP, see RFC 793 and RFC 768, respectively, both of which are specifically incorporated herein by reference. If packets on the control channel are transmitted in the clear, they may be vulnerable to attacks from malicious users. While security may not be required in all scenarios, there are a number of compelling deployments for RSIP, including visitor-based networks (hotel networks, Internet kiosks), in which security may be desirable. The present application describes the elements of and mechanisms for securing an RSIP control channel.
SUMMARY OF THE INVENTION
The present application provides a first security system and method wherein authentication is provided with a combination of a userid and HMAC parameters. The userid parameter identifies the sender, and the HMAC parameters are used with a shared key that only the sender and recipient know. Integrity is also provided by the HMAC parameters. Reflection attacks are prevented by the fact that in the RSIP protocol, each entity plays the role of either a host or a gateway, and each RSIP control message can be sent by either a host or a gateway, but not both. Liveness is provided by the combination of the replay counters, userids, host and gateway cookies, and the shared key. The use of cookies allows the shared key to be used between two different sessions, even if the replay counter is reset.
In addition, the present application provides a second security system and method wherein authentication is provided by a certificate exchange, with a combination of a userid and signed hash parameters. The userid parameter identifies the sender, and it is easy to verify that the signed hash has been signed by the proper sender. Integrity is also provided by the signed hash parameters. Replay protection is provided by the replay counter. Reflection attacks are prevented by the fact that in the RSIP protocol, each entity plays the role of either a host or a gateway, and each RSIP control message can be sent by either a host or a gateway, but not both. Liveness is provided by the combination of the replay counters, userids, and host and gateway cookies. In particular, the cookies uniquely identify a session between the two entities. The probability of the two entities generating the same exact cookies in the future session is infinitesimal.


REFERENCES:
patent: 5159592 (1992-10-01), Perkins
patent: 5227778 (1993-07-01), Vacon et al.
patent: 5526489 (1996-06-01), Nilakantan et al.
patent: 5550984 (1996-08-01), Gelb
patent: 5636216 (1997-06-01), Fox et al.
patent: 5708655 (1998-01-01), Toth et al.
patent: 5793763 (1998-08-01), Mayes et al.
patent: 5812819 (1998-09-01), Rodwin et al.
patent: 5867660 (1999-02-01), Schmidt et al.
patent: 5872847 (1999-02-01), Boyle et al.
patent: 5950195 (1999-09-01), Stockwell et al.
patent: 6011782 (2000-01-01), DeSimone et al.
patent: 6055236 (2000-04-01), Nessett et al.
patent: 6079021 (2000-06-01), Abadi et al.
patent: 6134591 (2000-10-01), Nickles
G. Montene, Internet Engineering Task Force, Internet Draft, “Negotiated Address Reuse” (NAR), <draft-montenegro-aatn-nar-00.txt>, May 1998, pp. 1 to 22.
George Tsirtsis, Alan O'Neill, Internet Engineering Task Force, Internet Draft, “NAT Bypass for End 2 End ‘Sensitive’ Applications,” <draft-tsirtsis-nat-bypass-00.txt>, Jan. 1998, pp. 1 to 5.
George Tsirtsis, Pyda Srishuresh, Internet Engineering Task Force, Internet Draft, “Network Address Translation—Protocol Translation” (NAT-PT), <draft-ieft-ngtrans-natpt-04.txt>, Jan. 1999, pp. 1 to 13.
Jeffrey Lo, K. Taniguchi, Internet Engineering Task Force, Internet Draft, “IP Host Network Address (and port) Translation,” <draft-ietf-nat-hnat-00.txt>, Nov. 1

Affiliated with

Also associated with

Rating

Control channel security for realm specific internet protocol does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Control channel security for realm specific internet protocol, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Control channel security for realm specific internet protocol will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-2832922