Electrical computers and digital processing systems: support – Multiple computer communication using cryptography – Protection at a particular protocol layer
Reexamination Certificate
1999-01-29
2003-09-02
Barron, Gilberto (Department: 2132)
Electrical computers and digital processing systems: support
Multiple computer communication using cryptography
Protection at a particular protocol layer
C713S153000, C709S238000
Reexamination Certificate
active
06615357
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Technical Field of the Invention
This invention pertains to security over virtual private network (VPN) connections. More particularly, it relates to VPN NAT, or concurrent use of network address translation (NAT) and IP Security (IPSec) protocols.
2. Background Art
Network Address Translation (NAT), widely deployed in Internet and in companies connecting to the Internet, causes problems for IP Security. In fact, NAT breaks IP Security (IP Sec). That is, NAT “is the feature which finally breaks the semantic overload of the IP address as both a locator, and the end-point identifier”. As a result, two hosts cannot establish an IP Sec connection if there is a NAT system in between. There are two reasons why.
First, the IP traffic that flows between the two hosts (for the IP Sec connection) will have AH or ESP applied. With respect to ESP in tunnel mode, the IP address that needs to be translated is inside the ESP tunnel and is encrypted. It is, therefore, unavailable to NAT. With respect to AH in transport or tunnel mode, the IP address that needs to be translated is visible in NAT, but the AH authentication includes it. Therefore, changing the IP address will break the authentication at the remote end of the IP Sec connection. With respect to ESP in transport mode, even if ESP is used with authentication, the IP address is available to NAT. But, if the IP address is changed, the IP Sec connection breaks due to the breaking of authentication at the remote end of the IP Sec connection.
Second, even if the IP traffic for the IP Sec connection could be translated, it would fail because the IP Sec connection is based on Security Associations which contain the two host IP addresses. These are fundamental to the Security Association architecture, in that the inbound IP Sec, on the host where decrypting (or authentication) is to occur, must be uniquely determined by the triple:
{destination IP addr, SPI, IP Sec protocol}.
For example, given hosts A & W, assume NAT is applied to an IP datagram (a generic term for bytes that go on the wire) with ESP in transport mode that is going from A to W. Hence the IP source address is changed. Upon arrival at W, the packet will probably be decrypted successfully since that doesn't depend on IP source address (which was in plaintext—not tunneled). If strictly implemented however, the inbound SPD checking which should follow decrypting will fail, due to the changed IP source address (because it was not the address used to negotiate the security association). So, even the transport mode ESP case fails.
Simply making NAT and IP Sec mutually exclusive is not the solution sought by the art. NAT is being deployed widely because it solves many problems, such as: masks global address changes, lowers address utilization, lowers ISP support burden, allows load sharing as virtual hosts. Yet, NAT is viewed as the greatest single threat to security integration being deployed in the Internet today. This “NAT problem”, as it is invariably termed, is architecturally fundamental. Yet, legacy applications and services (for example, those developed for IP version
4
) will continue to a long co-existence as applications and services develop for IP version
6
. Consequently, there is a great need in the art for providing NAT and IP Sec coexistence, at least in selected situations, and to do so without introducing serious configuration problems.
A VPN connection between two address domains can have the effect of directly connecting the two domains, which most likely will not been planned to be connected. Hence increased use of VPNs is likely to increase address conflicts. It is also understood that VPNs redefine network visibility and increase the likelihood of address collision when traversing NATs. Address management in the hidden space behind NATs will become a significant burden. There is, therefore, a need in the art to ameliorate that burden.
It is an object of the invention to provide an improved system and method for concurrently implementing both Network Address Translation (NAT) and IP Security (IP Sec).
It is a further object of the invention to provide a system and method for solving the increased likelyhood of IP address conflicts inherent in the use of a virtual private network (VPN).
It is a further object of the invention to provide a system and method for enabling utilization of VPNs without requiting re-addressing a domain (a expensive alternative).
It is a further object of the invention to provide a system and method for VPN NAT which is accomplished entirely in the IP Sec gateway without require changes in domain hosts.
It is a further object of the invention to provide a system and method for VPN NAT which requires no, or only minor changes to routing, in each connected domain.
It is a further object of the invention to provide a system and method for VPN NAT which is simple to configure.
It is a further object of the invention to provide a solution to the address collision problems caused by VPNs.
SUMMARY OF THE INVENTION
In accordance with the invention, IP security is provided in a virtual private network using network address translation (NAT) by performing one or a combination of the three types of VPN NAT. This involves dynamically generating NAT rules and associating them with the manual or dynamically generated (IKE) Security Associations, before beginning IP security that uses the Security Associations. Then, as IP Sec is performed on outbound and inbound datagrams, the NAT function is also performed.
REFERENCES:
patent: 5550984 (1996-08-01), Gelb
patent: 5640456 (1997-06-01), Adams, Jr. et al.
patent: 5757924 (1998-05-01), Friedman et al.
patent: 5761201 (1998-06-01), Vaudreuil
patent: 5793763 (1998-08-01), Mayes et al.
patent: 5825891 (1998-10-01), Levesque et al.
patent: 5828893 (1998-10-01), Wied et al.
patent: 5835726 (1998-11-01), Shwed et al.
patent: 6055236 (2000-04-01), Nessett et al.
patent: 6266707 (2001-07-01), Boden et al.
patent: 6353614 (2002-03-01), Borella et al.
The Microsoft Press Computer Dictionary, 3rded., Microsoft Press, p. 272.*
“Virtual Private Networks on Vendor Independent Networks”,IBM Technical Disclosure Bulletin, vol. 35, No. 4A Sep. 1992 pp. 326-329.
Boden Edward B.
Gruber Franklin A.
Barron Gilberto
Beckstrand Shelley M.
International Business Machines - Corporation
Meislahn Douglas
LandOfFree
System and method for network address translation... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with System and method for network address translation..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and System and method for network address translation... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3095100