Embodiments of the present invention relate to network security.
Internet Protocol security (IPSec) is a protocol suite that provides mechanisms for authenticating and encrypting data flowing within a network such as a Virtual Private Network (VPN).
Authentication Header (AH) and Encapsulating Security Payload (ESP) are wire-level protocols provided by IPSec to authenticate (AH) and encrypt (ESP) data. AH may be used in tunnel mode or transport mode.
Transport mode provides a secure connection between two endpoints as it encapsulates the payload portion of Internet Protocol (IP) packets sent over the secure connection. With tunnel mode, the entire IP packet is encapsulated thereby to provide a virtual secure hop between the two endpoints.
Network Address Translation (NAT) is a technology that is used to map a range of private addresses to and from a (usually) smaller set of public addresses. This reduces the demand for routable public IP space. NAT devices work by modifying IP headers associated with an IP datagram on the fly. In particular the source and/or destination IP addresses are changed. When a source or header IP address is changed, it forces a recalculation of the header checksum. This has to be done anyway, because the NAT device typically serves as one “hop” in the path from source to destination, and this requires the decrement of the TTL (Time To Live) field. However, as noted above since the TTL and header checksum fields are always modified in flight, AH knows to excludes them from coverage, but this does not apply to the IP addresses. These are included in the integrity check value, and any modification will cause the check to fail when verified by the recipient.
Because the ICV incorporates a secret key which is unknown by intermediate parties, the NAT router is not able to recalculate the ICV, making NAT incompatible with IPSec AH authentication.
According to a first aspect of the invention, a method for routing IP packets with IPSec AH authentication is disclosed. The method includes locating overlay edge routers between private domains and their associated NAT routers. Outbound packets from a source private domain are modified by its overlay edge router to include IPSec AH authorization data computed using IP source and destination addresses that match a packet's final source and destination IP address upon final NAT translation immediately prior to delivery to a host of a destination private domain.
Other aspects of the invention will be apparent from the detailed description below.
In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the invention. It will be apparent, however, to one skilled in the art that the invention can be practiced without these specific details. In other instances, structures and devices are shown in block or flow diagram form only in order to avoid obscuring the invention.
Reference in this specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the invention. The appearance of the phrase “in one embodiment” in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. Moreover, various features are described which may be exhibited by some embodiments and not by others. Similarly, various requirements are described which may be requirements for some embodiments but not other embodiments.
Moreover, although the following description contains many specifics for the purposes of illustration, anyone skilled in the art will appreciate that many variations and/or alterations to the details are within the scope of the present invention. Similarly, although many of the features of the present invention are described in terms of each other, or in conjunction with each other, one skilled in the art will appreciate that many of these features can be provided independently of other features. Accordingly, this description of the invention is set forth without any loss of generality to, and without imposing limitations upon, the invention.
Broadly, embodiments of the present invention teach extending IPSec AH Authentication to NAT device so that IPSec AH authentication may be used to protect IP packets that traverse a NAT device.
To understand embodiments of the invention, consider the network setup 200 shown in
In one embodiment, an overlay domain is created to facilitate routing with the network setup 200. The overlay domain may include a plurality of overlay edge routers (OERs) each coupled to an overlay controller (OC). The overlay controller (OC) orchestrates secure overlay routing based on defined policy and control logic. Communications between the overlay controller (OC) and the overlay edge routers (OERs) are facilitated by an overlay protocol (OP) which runs over secure DTLS connections through a core transport network. Each overlay edge router (OER) is defines an edge not that is located at the boundary of the overlay domain. All overlay edge routers (OERs) connect directly with each other over the core transport network via IPSec tunnels.
300: R1 receives an IP packet bound for a target host device (Host B) from a source host device (Host A).
302: R1 determines the private IPA of the last hop overlay edge router (R1). This is done via the overlay protocol (OP) wherein the overlay controller (OC) communicates the same to R1 via a DTLS control channel established through the network 210.
304: R1 calculates the authentication data based on the public IP address of R1 and the private IP address R2. This is illustrated in
306: R1 adds the authentication data into the AH header portion of the IP Packet
308: R1 inserts the original IP and UDP headers into the IP packet. This means that the private IPA of R1 is the source IP address and the public IPA of R2 is the destination IP address as is shown in
310: R1 transmits the IP packet.
When the packet arrives at R2 it would have been modified through NAT so that its outer header will have the public IPA of R1 as the source and the private IPA of R2 as the destination. This can be seen from
The hardware also typically receives a number of inputs and outputs for communicating information externally. For interface with a user or operator, the hardware may include one or more user input output devices 706 (e.g., a keyboard, mouse, etc.) and a display 708. For additional storage, the hardware 700 may also include one or more mass storage devices 710, e.g., a Universal Serial Bus (USB) or other removable disk drive, a hard disk drive, a Direct Access Storage Device (DASD), an optical drive (e.g. a Compact Disk (CD) drive, a Digital Versatile Disk (DVD) drive, etc.) and/or a USB drive, among others. Furthermore, the hardware may include an interface with one or more networks 712 (e.g., a local area network (LAN), a wide area network (WAN), a wireless network, and/or the Internet among others) to permit the communication of information with other computers coupled to the networks. It should be appreciated that the hardware typically includes suitable analog and/or digital interfaces between the processor 712 and each of the components, as is well known in the art.
The hardware 700 operates under the control of an operating system 714, and executes application software 716 which includes various computer software applications, components, programs, objects, modules, etc. to perform the techniques described above.
In general, the routines executed to implement the embodiments of the invention, may be implemented as part of an operating system or a specific application, component, program, object, module or sequence of instructions referred to as “computer programs.” The computer programs typically comprise one or more instructions set at various times in various memory and storage devices in a computer, and that, when read and executed by one or more processors in a computer, cause the computer to perform operations necessary to execute elements involving the various aspects of the invention. Moreover, while the invention has been described in the context of fully functioning computers and computer systems, those skilled in the art will appreciate that the various embodiments of the invention are capable of being distributed as a program product in a variety of forms, and that the invention applies equally regardless of the particular type of machine or computer-readable media used to actually effect the distribution. Examples of computer-readable media include but are not limited to recordable type media such as volatile and non-volatile memory devices, USB and other removable media, hard disk drives, optical disks (e.g., Compact Disk Read-Only Memory (CD ROMS), Digital Versatile Disks, (DVDs), etc.), flash drives among others.
Although the present invention has been described with reference to specific exemplary embodiments, it will be evident that the various modification and changes can be made to these embodiments without departing from the broader spirit of the invention. Accordingly, the specification and drawings are to be regarded in an illustrative sense rather than in a restrictive sense.
This application is a Continuation of U.S. application Ser. No. 15/583,984, filed May 1, 2017, which is a Continuation of U.S. application Ser. No. 13/966,281, filed Aug. 13, 2013, which are incorporated herein by reference.
Number | Name | Date | Kind |
---|---|---|---|
6963982 | Brustoloni et al. | Nov 2005 | B1 |
7120930 | Maufer et al. | Oct 2006 | B2 |
7143137 | Maufer et al. | Nov 2006 | B2 |
7360083 | Ragireddy et al. | Apr 2008 | B1 |
7366894 | Kalimuthu et al. | Apr 2008 | B1 |
7519834 | Dondeti et al. | Apr 2009 | B1 |
7606191 | Breau et al. | Oct 2009 | B1 |
7620070 | Maufer et al. | Nov 2009 | B1 |
7716369 | Le Pennec et al. | May 2010 | B2 |
7848335 | Kang et al. | Dec 2010 | B1 |
7860098 | Biswas et al. | Dec 2010 | B1 |
7949785 | Alkatib et al. | May 2011 | B2 |
8041824 | Maeng | Oct 2011 | B1 |
8291119 | Rao | Oct 2012 | B2 |
8776209 | Kumar et al. | Jul 2014 | B1 |
20020133534 | Forslow | Sep 2002 | A1 |
20030005103 | Narad et al. | Jan 2003 | A1 |
20030076830 | Asano | Apr 2003 | A1 |
20030108041 | Aysan et al. | Jun 2003 | A1 |
20030233452 | Maufer | Dec 2003 | A1 |
20030233568 | Maufer et al. | Dec 2003 | A1 |
20040037260 | Kakemizu et al. | Feb 2004 | A1 |
20040136356 | Kuo | Jul 2004 | A1 |
20040205245 | Le Pennec et al. | Oct 2004 | A1 |
20040249911 | Alkhatib et al. | Dec 2004 | A1 |
20050022017 | Maufer et al. | Jan 2005 | A1 |
20050135359 | Chang | Jun 2005 | A1 |
20060253701 | Kim | Nov 2006 | A1 |
20060259583 | Matsuura | Nov 2006 | A1 |
20070002857 | Maher | Jan 2007 | A1 |
20070058644 | Barhmbhatt et al. | Mar 2007 | A1 |
20080317011 | Datta et al. | Dec 2008 | A1 |
20090022152 | Henry et al. | Jan 2009 | A1 |
20090040942 | Yang | Feb 2009 | A1 |
20090097490 | Sanderson | Apr 2009 | A1 |
20090113203 | Tsuge | Apr 2009 | A1 |
20090157901 | Asati | Jun 2009 | A1 |
20100205313 | Boire-Lavigne et al. | Aug 2010 | A1 |
20100232503 | Morimoto et al. | Sep 2010 | A1 |
20110013637 | Kue et al. | Jan 2011 | A1 |
20110016309 | Motoyama et al. | Jan 2011 | A1 |
20120011589 | Chen et al. | Jan 2012 | A1 |
20120106559 | Kim | May 2012 | A1 |
20130133057 | Yoon et al. | May 2013 | A1 |
20130294461 | Zhou et al. | Nov 2013 | A1 |
20140075189 | Abraham | Mar 2014 | A1 |
20140280839 | Agrawal et al. | Sep 2014 | A1 |
20150359033 | Stojanovski et al. | Dec 2015 | A1 |
Entry |
---|
McGrew et al., Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH), Aug. 2014, Internet Engineering Task Force (IETF), RFC 7321, pp. 1-11. |
Manral, Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH), Apr. 2007, Network Working Group, Request for Comments: 4835. pp. 1-11. |
Kent, IP Authentication Header, 1212005, Network Working Group, Request for Comments:4302, pp. 1-34. |
Kent et al., IP Authentication Header, Nov. 1998, Network Working Group, Request for Comments: 2402, pp. 1-22. |
BB. Aboba, et al., “IPsec-Network Address Translation (NAT) Compatibility Requirements”, Mar. 2004, Network Narking Group RFC: 3715, p. 1-18. |
Steve Fried!, “An Illustrated Guide to IPsec”, Jun. 2008, Steve Friedl's Unixwiz.net Tech Tips, http://unixwiz.net/echtips/iguideipsec_html, p. 1-19. |
Number | Date | Country | |
---|---|---|---|
20180302389 A1 | Oct 2018 | US |
Number | Date | Country | |
---|---|---|---|
Parent | 15583984 | May 2017 | US |
Child | 15948988 | US | |
Parent | 13966281 | Aug 2013 | US |
Child | 15583984 | US |