JP4426443B2 - Improved security method and apparatus for communicating over a network - Google Patents

Abstract

Method and apparatus for Internet Protocol Security (IPSec) and Network Address Translation (NAT) integration is described. Additionally, method and apparatus for enhanced security for communication over a network, and more particularly to control of security protocol negotiation to enable multiple clients to establish a virtual private network connection with a same remote address, is described. Furthermore, method and apparatus for enhanced security for communication over a network, and more particularly to NAT integration IPSec, is described. Moreover, method and apparatus for integration of NAT and source address security, including, but not limited to, determining whether a gateway computer is integrated for NAT and source address security, is described.

Description

Field of Invention

  The present invention generally relates to enhanced security for communicating over a network.

Background of the Invention

  The Internet is a public network that continues to grow. Many companies rely on communication over the Internet to facilitate their sales activities. However, public access also carries security risks. In order to improve security on the Internet, the Internet Engineering Task Force (IETF) has designed a set of protocols collectively known as Internet Protocol Security ("IPSec"). This IPSec is designed to provide authentication and encryption for communication over a network such as the Internet. Network address translation (NAT) is also a major factor in the growth of the Internet, but unfortunately, NAT operations are not consistent with IPSec.

  A NAT is a set of one or more private IP (Internet Protocol) addresses used for local internal network traffic, and one or more “to be dynamically selected when an internal address wants to exchange traffic with an external machine. Convert between public IP addresses. The translation table at the NAT gateway allows an organization's Internet traffic to share one (or more) public addresses specified for that organization. An outgoing packet for a new connection causes the gateway to create a new NAT translation table entry. The NAT translation table is used to perform inverse translation on traffic arriving in the reverse direction (ie, traffic coming from the public Internet).

  A LAN client computer may have a statically assigned local IP address, but traditionally a dynamic host configuration protocol (DHCP) server entity dynamically assigns a private IP address to a LAN client computer. To do. Such private addresses are uniquely selected from a pool of available private IP addresses. The DHCP server process is often co-located with the NAT gateway, but can be hosted on a separate device in the private network. Thus, for example, an IP packet from a client computer or other local machine that is part of a local or private domain ("behind") to the NAT gateway includes an IP source and destination address in the IP header of the packet, and Source and destination port addresses are included in the packet's User Datagram Protocol or Transmission Control Protocol (UDP or TCP) header. Traditionally, the IP source address field of a packet contains a private IP address that is statically or dynamically assigned to the client computer, whereas the IP destination address field of the packet is destined for another machine behind the NAT gateway. Packets that contain private IP addresses, or packets that are destined for another machine that is not behind a NAT gateway, such as a remote computer connected to the Internet.

  In the latter example, the NAT gateway changes the IP source address field of the outgoing packet from a locally unique private IP address to a public or globally unique IP address. The new source address of the packet, here the public IP source address, is conventionally the IP address of the NAT gateway's external interface, or an IP address assigned from a pool of available public addresses managed by the NAT gateway. is there.

  In addition, NAT gateways may require translation of transport layer addresses (ie TCP or UDP ports) to allow more connections to share the same IP address. If the NAT gateway uses its own public IP address as the public IP address for packets leaving the local machine, the external connection appears to come out of the NAT gateway computer. A NAT gateway computer to prevent two local client machines from communicating with the same remote IP address and selecting the same destination TCP or UDP port to prevent the NAT gateway from determining which clients should send traffic back To make outgoing traffic appear to come out of a uniquely identifiable IP public address and TCP or UDP source port pair. Opportunities such as this appear to be insignificant, especially as the number of local clients increases and can be avoided by performing TCP or UDP port translation in addition to IP address translation. is there. NAT gateways store not only private / public IP address associations, but also TCP or UDP port associations for translating and forwarding incoming traffic, so NAT sometimes also has network address and port translation (NAPT). Called.

  IPSec relies in part on the negotiation of parameters governing connections that require improved security. Among other known items governing negotiated security parameters between peer stations, a set of parameters including exemplary items such as authentication and / or encryption session key, key life time, encryption or authentication algorithm is , Collectively known as Security Association (SA). SA negotiation is performed based on a protocol known as the Internet Security Association and Key Management Protocol (ISAKMP) that uses the Oakley key determination algorithm. ISAKMP / Oakley is more commonly known as Internet Key Exchange (IKE). One result of IKE negotiation is a private agreement on a random selection session key to be used for encryption and decryption and / or digital signature messages (ie, IP packets). A UDP port 500 is designated for the ISAKMP and IPSec control protocols.

  IPSec protected IP packets coalesce at least one of the two forms of the IPSec security protocol header based on whether authentication was negotiated in IKE, encryption was negotiated, or both were negotiated. Summarizing these IPSec security protocol headers for clarity, the “authentication header” (AH) is used when authentication is negotiated and the “encapsulated security payload” (ESP) header is used when encryption is negotiated. When an IP packet includes both AH and ESP headers, for example, when ESP is negotiated with AH, AH that encapsulates the ESP header is used.

  When an IPSec security association is established, the Internet protocol header of each IPSec protected packet specifies the type of security protocol to use, ie, AH or ESP, or a combination thereof. In IP version 4 (“IPv4”), there is an 8-bit “Protocol” field in the IPv4 header, which points to the next higher layer protocol that is logically above the IP layer. In IP version 6 (“IPv6”), there is an 8-bit “next header” field that performs the same function as the protocol field in the IPv4 header. In both IPv4 and IPv6, a value of 0x32 means ESP and 0x33 means AH. Both AH and ESP headers contain a 32-bit field for the numeric value known as the security parameter index (SPI). If an IP packet is digitally signed (using AH), certain important parts of the IP header of such an IP packet need not be changed, otherwise such IP packet The IPSec peer station receiving the IP packet cannot confirm that the digital signature of the IP packet is correct. However, during conventional operation, the NAT gateway is the IP source address of the packet for outgoing (ie local to remote or private to public) packets, or incoming (ie remote to local or public to private). ) Change the packet destination address for the packet. In either direction, NAT translation of the IP header interferes with the IPSec peer station's ability to verify AH digital signatures. In the outgoing traffic example, if the intervening NAT gateway or router translates the packet's private IP source address to a global or public IP address, authentication at the receiving computer fails. This is because the private IP address is no longer available to the receiver for digital signature verification. To date, IPSec AH is not compatible with NAT because of the necessary changes to IP packets while traveling through a NAT gateway.

  In the case of a packet that is encrypted but not signed (ie, an IPSec packet protected by ESP without AH), the transport layer header cannot be decrypted by a third party including the NAT gateway ( Even though it can be decrypted, it is not in a normal position within the packet), and therefore, no TCP or UDP port number is available to the NAT gateway for use in the outgoing and / or incoming translation process. Thus, IPSec ESP alone (ie, only ESP without AH) prevents basic NAT operation regardless of the presence of the authentication header. By extension, in the case of an IP packet protected by both AH and ESP, the source IP address does not need to be changed, but the port number is encrypted.

  In summary, an AH header, an ESP header, or both may be added to an IP packet. Important for NAT, the IP source address field of an AH protected packet cannot be changed because it is part of the input to the digital signature algorithm. Importantly for ESP protected packets, the peer station may change the IP source address without interfering with the ability to decrypt the received packet, but the source and destination port numbers are encrypted, so the NAT gateway Cannot be decrypted. Thus, for ESP, the TCP or UDP port number cannot be decrypted by the NAT gateway, so far there is no mechanism to clarify the return traffic route, i.e. to determine which private stations should receive ESP protected packets. . Furthermore, ESP protected traffic for virtual private networks (VPNs) has so far limited the number of VPN sessions to the same remote IP address, or limited such non-standard changes to VPN clients.

  Thus providing NAT and IPSec integration without adding significant overhead and without requiring IP source or destination address and / or TCP or UDP source or destination port translation that does not conform to IPSec security algorithms It is desired and useful to do.

Summary of the Invention

  Aspects of the present invention relate to an improved security method when communicating over a network between a client computer behind a gateway computer configured for address translation and a remote computer. The client computer of the gateway computer is given a public address, which is one of the gateway computer public address and a pool of gateway computer public addresses. The gateway computer participates in the security association negotiation with the remote computer. The gateway computer uses security association negotiation as an indicator for recording the local address of the client computer in relation to the destination address of the remote computer, and the local address and destination address are obtained from the security association negotiation and the gateway computer Stored in a data structure accessible by.

  Another aspect of the invention relates to a method for processing Internet Protocol Security (IPSec) packets with a Network Address Translation (NAT) gateway computer. In response to checking at the NAT gateway that the public Internet Protocol (IP) source address for the IPSec packet can be specified at the NAT gateway computer, and in response to being able to specify the public IP source address at the NAT gateway computer, the IPSec packet is sent by the local computer. A check is made to see if it has been sent. In response to the confirmation that the IPSec packet was sent by the local computer, the IPSec packet is sent to the destination address without translating the public IP source address.

  Another aspect of the invention relates to a method for routing a received packet having a source address and a public address of a gateway computer. Check the source address of the mapping table listed in relation to the public address of the gateway computer and obtain the security parameter index from the received packet. Check that the security parameter index of the mapping table is related to the source address of the received packet. In response to finding that the security parameter index of the mapping table is related to the source address of the received packet, the received packet is routed to the local address associated with the security parameter index in the mapping table and the source address, where The local address is not the public address of the gateway computer.

  Another aspect of the present invention relates to an Internet Key Exchange (IKE) control method. A gateway computer configured with a mapping table is provided. A packet is received from the local client computer to the gateway computer and a check is made to determine if this packet is an IKE packet. In response to the packet being an IKE packet, a check is made against the mapping table record that matches both the Internet Protocol (IP) destination address and the local medium access control (MAC) address of the IKE packet in the mapping table. . In response to identifying the mapping table record, a check is made for a security parameter index associated with the mapping table record.

  Another aspect of the present invention relates to a security negotiation control method for a gateway computer. The gateway computer is given access to the data structure. A packet is received at the gateway computer and it is determined whether the packet is a security negotiation packet. The data structure is checked for a medium access control (MAC) source address and a destination address in response to the packet being part of a security negotiation. In response to the destination address being found in the data structure and the MAC source address associated with the destination address not found in the data structure, it is determined whether the security value of the destination address is in the data structure. In response to the fact that the security value of the destination address is not found in the data structure, transmission of the security negotiation packet is suppressed.

  Another aspect of the invention relates to a method for forming a packet by a client computer. A public address for the client computer is obtained from the network address translation gateway computer. The obtained public address is used as the source address for the packet.

  Another aspect of the invention relates to a method for generating a mapping table for network address translation (NAT) integration with Internet Protocol Security (IPSec) protected packets. The gateway computer is given access to the mapping table. At the gateway computer, a packet is received from a client computer associated with the media access control address, and the media access control address is transmitted along with the packet in addition to the source address of the packet. The source address is the public address of the gateway computer. The gateway computer determines whether the packet is a security negotiation packet, and in response to the packet being a security negotiation packet, the media access control address is a destination address of the packet associated with the media access control address; The initiator is associated with at least one of the medium access control address and the destination address, and is recorded in the mapping table.

  Another aspect of the invention relates to a method for network address translation (NAT) integration with an authentication header (AH) protected packet. The client computer is given a public address from the NAT gateway computer. The client computer forms an AH protected packet having the public address as a source address, and transmits the AH protected packet from the client computer to the NAT gateway computer.

  Another aspect of the invention relates to a data structure for a gateway computer. A medium access control address field, a local public address field associated with the medium access control address field, a non-local address field associated with the medium access control address field, and a security parameter index field associated with the non-local address field. Provided. The security parameter index field is for storing a security parameter index related to communication from a non-local machine.

  Another aspect of the invention relates to a method for probing a gateway computer by a client computer to determine whether network address translation is integrated with source address security. A first request for a first address is made for a gateway computer by a client computer having a first client identifier. In response to the first request, a first address is transmitted by the gateway computer. A second request is made for the second address from the gateway computer by the client computer having the second client identifier, where the second client identifier is similar to the first client identifier. The second address is received by the client computer from the gateway computer in response to the second request. The client computer determines from the requested second address whether network address translation is integrated with source address security for the gateway computer.

  Another aspect of the present invention relates to a network address translation method for source address protection packets. The client computer is provided to communicate with the address server computer. A first request from the client computer is made to the first address from the address server computer, and the client computer can be identified by the media access control number by the address server computer. In response to the first request, the address server computer provides a private address to the client computer. A change in the media access control number is generated by the client computer and given the changed media access control number. A second address from the address server is requested by the client computer, and the client computer can be identified by the address server computer with the changed media access control number. The address server computer associates the client computer with the first request and the second request by associating the media access control number with the changed media access control number, and in response to the second request, the address server computer sends the public address to the client. Give to computer.

  For a detailed understanding of how the features, advantages and objects of the present invention are achieved, the present invention, briefly summarized above, will be described in detail with reference to the embodiments thereof illustrated in the accompanying drawings.

  It should be noted, however, that the accompanying drawings illustrate only typical embodiments of the present invention and are not intended to limit the scope thereof, and that the present invention can be equally effectively implemented in other ways.

Detailed description

  The present invention relates to a method and apparatus for coexisting IPSec and NAT, and when a packet destined for the outside of a client computer is configured not to use a private IP source address, the IP address of a NAT that does not conform to IPSec Alternatively, a method and apparatus is provided that creates a mechanism that does not require TCP or UDP port translation to be performed on the packet. Rather, the client's IPSec software generates a packet destined for the outside using the public IP address provided by the NAT device.

  The traffic from each remote IP address to each local peer client machine has a unique security parameter index in the AH or ESP header, which can be used in place of the TCP or UDP port for any local station to have IPSec protection. The NAT can be allowed to determine whether to send a packet. As long as each local client speaks to one remote IP address and no other clients speak to that same remote IP address, the translation may be a conventional NAT translation that includes only the IP source address field. However, if multiple local client machines are directed to communicate with the same remote IP address, the IPSec capable NAT gateway ensures that only one SA is negotiated at a time between the local / remote pair machines. In order to do this, it is necessary to execute IKE suppression. The security parameter index is used in clear text, but there is some confusion here in the fact that it is negotiated privately, so the NAT gateway sends the first IPSec protected packet to the local station. Until you have access to the negotiated security parameter index in use. Knowing the security parameter index, other local stations may negotiate their security associations with the remote station, one at a time.

  One aspect of the invention relates to a method for allowing the use of IPSec AH in a situation where a NAT gateway is located between a client computer and a remote computer. The client computer requests a public address from the gateway computer, and in response, the public address is provided to the client computer. An IPSec security association is negotiated with the remote computer. The security association negotiation records the association between the client's local address (its MAC address in the case of NAT / AH coexistence, its private IP address in the case of NAT / ESP coexistence) and the IP address of the remote computer. Used as a trigger for the gateway computer, wherein the local address and the destination address are obtained from the first outgoing security association negotiation packet. The security parameter index value resulting from the security association negotiation with the remote computer is obtained and stored in relation to the local address for future use, i.e. when the remote station begins to send IPSec protected traffic to the local client Is obtained and stored.

  One aspect of the invention relates to a data structure for a gateway computer. The data structure includes a local address (medium access control (MAC) or IP address) field, a remote IP address field associated with the local address field, and a remote-to-local security parameter index (SPI) associated with the local address field. And a remote address field for specifically identifying traffic flowing from the remote address to the local address. The remote to local SPI field is for storing at least one security parameter index from a remotely located machine.

  One aspect of the invention relates to an Internet Key Exchange (IKE) suppression method. The gateway computer is configured with a mapping table. The received packet is checked to determine if it is an IKE packet. If it is an IKE packet, the mapping table is checked to see if the destination (remote) IP address matches a mapping table entry that also matches the source MAC or IP address of the packet. In addition, the ISAKMP “initiator cookie” value (64 bits) is checked for a match between entries in this mapping table, ie, entries that match the client's MAC or IP address and a pair of addresses that are remote IP addresses. In response to finding a matching entry in the mapping table, a check is made for an indication that a security negotiation between the local client and the remote IP address is in progress or has been completed. If the remote-to-local security parameter index is not already in the mapping table, transmission of the IKE packet is suppressed.

  One aspect of the present invention resides in a gateway routing method. The remote-to-local packet is checked to see if the valid security parameter index for the mapping table entry matches the packet's remote IP address (the IP source address of the remote-to-local packet) and its IP destination address, which is the gateway The machine must be the public IP address assigned to the machine using the local client's MAC address. If a matching remote-to-local security parameter index associated with this remote IP address is found, its public IP destination address and its MAC address, or its private IP, as indicated by the contents of that row in the mapping table Using the address, the packet is forwarded to the local client. When the private IP address field is full, the contents of the public IP address and MAC address fields are blank.

  One aspect of the invention relates to a method for processing IPSec AH packets by a NAT gateway computer. The IP source address field for a local-to-remote IPSec packet is checked to see if it contains a private address or a public address specified for the station processing the MAC address found in the MAC source address field of the packet. The gateway also discovers that the IP source address of the packet is a public address, and that the gateway also knows that this public address was specified for a machine with the same MAC address as the MAC source address field of the packet If so, the IPSec packet remains unchanged by the NAT gateway computer (except for reducing the TTL and updating the IP checksum for IPv4 packets; the IPv6 packet is so abundant that NAT is not required. Yes, so there is no IPSec vs. NAT issue for IPv6).

  The IP source address field of the remote-to-local IPSec packet is matched against the remote IP address string in the mapping table, and the packet's SPI is expected to be stored in the mapping table row associated with this remote IP address. A match is made against the remote versus local SPI. If a matching mapping table entry is found, the packet is forwarded to the local client MAC address (or private IP address) extracted from the matching row in the mapping table.

  In the following description, numerous specific details are set forth in order to provide a more thorough understanding of the present invention. However, it will be apparent to one skilled in the art that the present invention may be practiced without one or more of these specific details. In other instances, well-known features are not described in order to avoid obscuring the present invention.

  FIG. 1 is a block diagram illustrating an embodiment of a computer system 10 in accordance with one or more aspects of the present invention. The computer system 10 includes a CPU 11, a system memory 13, an input / output (I / O) interface 12, and a NIC 100. NIC 100 may be coupled to / from network 110 as an I / O. The NIC 100 includes a local memory 112.

  FIG. 2 is a network diagram illustrating an embodiment of a network 110 in accordance with one or more aspects of the present invention. The network 110 includes a wide area network (WAN) 104. The WAN 104 may be the Internet, an Internet subnetwork (“subnet”), or other wide area network. One or more computer systems 101 may be logged on to the WAN 104 from time to time. Importantly, one or more computer systems 101 may be servers. In addition, DHCP server / NAT gateways (“gateways”) 106 and 107 are coupled to the LANs 102 and 103, respectively. Client computers 106 -A, 106 -B and 106 -C may enter a state of communication with gateway 106 via LAN 102. Similarly, the client computers 107 -A, 107 -B and 107 -C may enter a communication state with the gateway 107 via the LAN 103. NAT gateways 106 and 107 may be coupled to WAN 104 via router 108. Alternatively, the gateways 106 and 107 may be gateway-routers, ie, NAT gateway and router combinations, and DHCP server functions may be incorporated into the integrated device.

  Network 110 is merely an example, and fewer or more computers, gateways, LANs or WANs, and combinations thereof may be used. Further, the client computers 106-A, 106-B, and 106-C may be configured similarly to the computer system 10 of FIG. 1 in that each has a NIC 100 with a local memory 112. For clarity, other constructs may be used as described herein, but the remainder of this description is DHCP / NAT coupled to the Internet 104 via the router 108 to communicate with the remote server 101. This is for the client computer 106 -A behind the gateway 106. A conventional example of such a network may be an employee of a small office / home office (SOHO) network that connects to a company server via the Internet. For clarity, the local address refers to the address specified by the gateway, and the non-local address refers to all other addresses.

  FIG. 3 is a flowchart illustrating an embodiment of a portion of an IPSec / NAT integration process 200 in accordance with one or more aspects of the present invention. The integration process 200 includes an IPSec / NAT client side integration subprocess 299 and an IPSec / NAT gateway side integration subprocess 298. With reference to FIG. 3 and with reference again to FIGS. 1 and 2, the integration process 200 will be described.

  In step 201, a client computer, such as a client computer (or “client”) 106 -A, requests an IP address from a gateway, such as gateway 106. Such a request in step 201 may be made by software programmed in the client computer 106-A, and more specifically for a network interface such as a “network interface card” or “NIC” 100. It may be part of the driver, or part of NIC hardware or firmware, including but not limited to program code 299 stored in local memory 112.

  When client 106-A receives the private IP address, client 106A knows that the NAT gateway is used because client 106A can send traffic outside the private address domain. Since the list of private IP addresses is well known, the client 106A can perform a test to determine whether a private IP address has been assigned to it. In step 202, client 106A submits another request for an IP address, this time inverting the local bit in its DHCP client identifier (also known as its MAC address). As is well known, each computer in a LAN, including both gateways and clients, is assigned a unique number, or MAC address, for such a LAN. Traditional MAC addresses are 48-bit numbers divided into two 24-bit segments known as organization-specific identifiers (OUI) and manufacturer-specific identifiers. In the first byte of the OUI, the least significant bit (LSB) is a multicast bit. The least significant next bit in the most significant byte is the local bit.

  For example, the DHCP process at the NAT gateway 106 responds to the first DHCP request with the first client identifier from step 201 to the client computer 106-A logged on to the LAN, such as the LAN 102, and at step 251 the private IP address. Then, a second DHCP request may be made to the NAT gateway 106 in step 202 with a different client identifier from the client computer 106-A logged on to the LAN 102. Importantly, this second client identifier is derived from the associated first client identifier. Thus, if the gateway 106 supports IPSec beyond NAT, as indicated by the implicit check in step 252, it can be recognized that the two MAC addresses are from the same requesting station. A NAT gateway configured to support AH IPSec makes this determination and therefore does not send a second private IP address, but rather a public IP address in step 255. However, if such a NAT gateway does not support AH IPSec, the DHCP server specifies a second private IP address in step 253. This is because it does not result from the relationship between two MAC addresses that differ only in their local bit values.

  If the gateway 106 is configured to run AH IPSec with NAT, at step 254, the gateway 106 sends the MAC address of the client computer 106-A to the mapping table in the mapping table along with the public IP source address. May be recorded as eligible for transmission. Alternatively, the gateway 106 may wait for an IKE, as described in detail below.

  Based on the designation of the private IP address after step 201, the client 106-A can infer the presence of the NAT gateway 106 in advance. The designation of the second private IP address indicates in step 204 to client 106-A that NAT gateway 106 does not support AH IPSec. However, if client 106-A receives a non-private (ie, public) IP address in response to a DHCP request from step 202, client 106-A responds with a NAT at step 206 in response. Knowing that the gateway 106 supports AH IPSec, step 206 records the public IP address in relation to the MAC address, as described in detail below. Further, if the NAT gateway 106 supports AH IPSec, the client 106-A may subsequently negotiate AH and / or ESP using IKE, and this capability is noted in step 207. Or it may be recorded. On the other hand, if it is detected that the NAT gateway 106 does not support AH IPSec, the client 106-A is limited to negotiating ESP with only IKE.

  The DHCP server at the NAT gateway 106 sets the two MAC addresses to the same client computer 106 when the client identifier supplied in the initial DHCP request differs from the subsequent DHCP client identifier only in that the local bit is inverted. Configured to correlate as corresponding to -A. In other words, with the exception of local bits, each DHCP client identifier is otherwise identical. Such a DHCP server is responsive to the fact that the two MAC addresses stored in the mapping table differ by a local bit so as to send the public address (one of) obtained to the gateway 106 to the client computer 106-A. So that such public IP addresses can be used for AH or ESP and AH IPSec sessions, as described in detail below.

  However, if the DHCP server does not support correlation of two DHCP requests from the same client computer 106-A, as described above, only the local bit value of the client identifier is different, the second private IP address is Sent to the requesting client computer 106-A. When client computer 106-A receives the second private address, it uses DHCP to release one of the private IP addresses back to the pool of private addresses in step 204 and designate it as another local station. It can be so. Thus, if the second private IP address is sent from the DHCP server, this informs the client computer 106-A that NAT is being used and that public IP addressing capability is not provided. To do. In other words, the gateway 106 supports NAT but does not support AH IPSec and NAT based on the algorithm defined herein. Accordingly, at step 205, the client computer determines that only IKE negotiations of ESP-based security associations can be securely supported for reasons detailed below.

  Notably, one or more aspects of the present invention for ESP-only IPSec do not require a public IP address. However, conventionally, it is not known in advance whether IPSec of AH only, ESP only, or ESP with AH will be used as a result of IKE negotiation. Thus, the process 200 requests a public IP address in advance, such as when an ASP alone or an ESP IPSec with an AH is agreed upon with the IKE. If available, the public IP source address is used to flag the gateway 106 that IPSec communication is being performed. The gateway 106 also observes that the client 106A has sent a DHCP client identifier with the local bit inverted to request a public IP address (and that one was specified by the gateway 106), and the client 106A Based on the start of IKE exchange from 106-A, a clue that IPSec communication is being executed can also be obtained. In addition, the public IP source address described here works for ESP-only IPSec and ESP IPSec traffic with AH only or with AH, so the public IP source address for IKE and all other IPSec traffic. Using it when it is available increases the likelihood of a successful IPSec operation. In step 210, client computer 106-A initiates an IKE negotiation. The IKE negotiation proceeds in a conventional manner where the protocol stack starts with a private IP address and generates an IKE start packet. Notably, in the case of IKE negotiation, the private IP address may be used as the IP source address because IKE is a “NAT security” protocol. If a public IP address is available, client 106-A may choose to use the public IP address as the IP source address when initiating IKE negotiation.

  Alternatively, the client computer 106-A may start with an IKE before obtaining a public IP address. However, if the gateway 106 is not configured to provide a public IP address (or cannot perform such operations), use only AH or ESP with AH that does not match such gateway 106. This is not discovered until an IKE negotiation is completed that may include an agreement for Therefore, it is necessary to execute a new IKE. The client computer 106-A may form a packet having as its IP source address a public address that is a public address of the gateway itself or an address selected from a pool of public addresses managed by the gateway 106. Client computer 106A may form a packet having a private IP source address. In other words, the client computer 106-A may be configured to make a selection between a private IP address and a public IP address, and this selection may be based on availability in some cases, In some cases, it is assumed that the IPSec protocol should be used if available. Once a public address is obtained, a packet may be formed in a conventional manner using such a public address as a source address. In the latter case, if AH IPSec NAT is allowed, both IPSec protected traffic and non-IPSec protected traffic may flow. Recall that non-IPSec protected traffic may use conventional NAT. Also, in a private domain such as a LAN, the client 106-A may or may not participate in IPSec protected communication with another local client. In such an example of intra-domain communication with IPSec, even if IPSec is used, it is not necessary to use a public IP address because the IP destination address is in the same private address domain as client computer 106-A. . Thus, the user of client 106-A decides whether to communicate with a peer station with IPSec, and, in the case of such communication, such a peer station is in the private address domain of client computer 106-A. Alternatively, it may be determined whether it is internal, i.e. has a local domain address.

  In response to the IKE being initiated at step 210 by the client computer, the gateway 106 uses the receipt of the IKE initialization packet at step 260 to identify the MAC address of such client computer and such IKE. The destination IP address of the initialization packet may be recorded. The NAT gateway 106 may determine that the packet is an IKE packet by checking that the packet is a UDP packet where both the source and destination ports are equal to 500. In step 260, a bit or pending bit may be set to indicate that outgoing traffic for the IKE with this MAC address has been transmitted. The destination IP address of this IKE packet is for a remote machine such as the remote server described above. The gateway 106 does not participate directly in the IKE negotiation anyway, but other NAT translation of the IKE packet is also possible, which is the client 106-A uses a private IP address such as the source address of the IKE packet. Only if. A NAT gateway that supports IPSec must support IKE suppression, which can only proceed with one IKE negotiation at any given time, so when translating an IKE packet to a network address, the IP address Note that port conversion is not necessary because only conversion is sufficient.

  5A and 5B illustrate an embodiment of an IPSec allocation mapping table (IPSAMT) 300 at different times in accordance with one or more aspects of the present invention. This IPSAMT 300 includes a row for each IKE to be started, a time stamp 305, an ISAKMP initiator cookie 307, an IPSec protocol identifier, a local client MAC address 301, a local client public IP address 309, a local client private IP address 306, remote-to-local security. A column for each field of a parameter index 302, a pending bit 303, and a remote IP address 304.

  The time stamp field 305 is interpreted based on the state of the pending bit field 303. When the pending bit field 303 is set, the time stamp field 305 is configured by the time of the latest IKE packet between the address of the remote IP address field 304 and the related address of the local client MAC address field 301. . When the state of the pending bit field 303 is clear, the time stamp field 305 is a time when the latest IPSec protection packet is received from the remote IP address that matches the address of the remote IP address field 304 in the row of the mapping table 300. including. If the mapping table 300 is full, the row that has been idle for the longest time is taken as the first deleted line using information from the timestamp field 305.

  The IPSec protocol field 308 can be encoded as a 2-bit field, where 00 indicates an invalid pattern, 10 indicates AH, 01 indicates ESP, and 11 indicates ESP with AH, while others It should be understood that encoding is also possible. The remote-to-local security parameter index field 302 stores a security parameter index value associated with traffic destined for a particular local client identified by the MAC address and public or private IP address from the address of the remote IP address field 304. Is for.

  Continuing to refer to FIGS. 5A and 5B and referring again to FIGS. 1, 2 and 3, the NAT gateway 106 matches the MAC address of the client computer 106-A with the first remote IP address recorded in the mapping table. Thus, after recording in the mapping table, “IKE suppression” can be used to ensure that only one IKE exchange occurs at a time between the local client machine and the remote IP address. Since there is only one IKE negotiation outstanding between a local client and a remote IP address at a given time, an incomplete missing security parameter index entry for a mapping table row at a given time There is only one. If multiple local machines are directed to access the same remote IP address using IPSec, IKE negotiation is handled on a first-come, first-served basis. Once the earliest IKE negotiation is complete, i.e. a new incoming security parameter index is recorded from that remote IP address, another IKE negotiation is allowed to begin. More specifically, the gateway 106 receives a packet destined for one of its public IP addresses from the remote IP address, which has 1) a pending bit 303 set in a row of the mapping table. ) Does not have a security parameter index entry in that row of the mapping table. The gateway 106 records the security parameter index of this packet in this empty slot in this row of the mapping table, such as IPSAMT 300, and then forwards this packet to the client address taken from the same row of the mapping table.

  Notably, AH and ESP have their own security parameter index types, and there are both incoming and outgoing security parameter index types. Thus, the mapping table may have a column for AH or ESP traffic, where AH includes ESP with AH. However, a row is added to the mapping table by monitoring IKE exchanges between the local machine and the remote machine associated with the remote IP address.

  A security table index is stored from such an IKE peer using a mapping table having the remote IP address of the IKE peer and the MAC address of the local client participating in the IKE conversation with such an IKE peer. Notably, after the IKE negotiation is complete, such a security parameter index may be used for such mapping until IPSec protected traffic actually flows from the remote machine for such remote IP address to the NAT gateway 106. Cannot add to table The security parameter index is encrypted during IKE and does not appear unencrypted or “plaintext” unless the true data for such an IPSec session is transmitted, ie after the IKE session has been successfully completed. . In addition to the reasons described above regarding the relevance between security parameter indexes from remote addresses, the security parameter index is encrypted during IKE and appears only in plain text when true encrypted data begins to flow, so IKE suppression Only one open remote-to-local security parameter index entry at a time for the same destination IP address may be allowed in the mapping table until the actual data begins to flow as part of. Multiple IKE sessions may occur through the gateway 106 as long as each active client negotiates with a different remote IP address. Once a security parameter index for a successfully negotiated IKE is obtained for a remote IP address, another IKE session may be initiated for that same remote IP address.

  Thus, it should be understood that there are multiple communication modes. If client 106-A uses the public IP address as the source address when sending its IKE or IPSec protected traffic, the return traffic is secured against the client's MAC address using the mapping table. When a parameter index is obtained, it is mapped to it, and until such a security parameter index is obtained, the return traffic is sent to a remote IP having a pending bit open to the client's MAC address using a mapping table. Maps to an address.

  If client 106-A uses a private IP address when sending its ESP-only IPSec traffic, and the traffic is subsequently network address translated, NAT IP address translation for incoming traffic is , By associating the client's private IP address with the remote IP address stored in the mapping table (ie, the source address for incoming traffic), and port address translation is performed using the mapping table. When a security parameter index is obtained for an IP address, it is mapped there. If no security parameter index is available for such a remote IP address, the client's private IP address with an open pending bit associated with such remote IP address is used. The gateway 106 cannot determine in a definite manner whether the ISAKMP negotiation initiated by the local client 106-A has been successfully completed. However, there are two implicit cues that can be used to help keep unnecessary pending states from being maintained in the mapping table. When the local client starts the ISAKMP main mode exchange, the quick mode exchange must be continued immediately after such a main mode exchange. If more than 5 seconds have passed without a quick mode packet being seen, this negotiation will fail and the lines generated in response to such an ISAKMP main mode exchange may be removed from such a mapping table. it can.

  Alternatively, the local client may initiate an aggressive mode exchange that always picks up three packets. If two packets are seen and then 5 seconds elapse without looking at the third packet, such negotiation fails and the line generated in response to such an ISAKMP aggressive mode exchange is It can be removed from such a mapping table. Thus, associating a time stamp with an ISAKMP initiator cookie in a mapping table may be used to determine if such a time limit has passed. Thus, it will be apparent that a special or modified VPN is not required to support multiple VPN connections simultaneously since the security parameter index, not the port number, is used for the reverse translation. Therefore, there is no need to be able to access a TCP or UDP header for reverse conversion as described herein. Furthermore, since the security parameter index is a fixed offset, it is easy to access it in the packet for use as an index into the mapping table. Alternatively, if an ESP-only VPN is used instead of changing the local client's NIC by the driver of the program product configured to execute a second DHCP request to obtain a public IP address The gateway 106 is configured with a mapping table, but the client 106-A does not need to change because the IPSec of IKE and ESP only matches the NAT.

  IKE suppression is not used for clients communicating with a number of individual remote IP addresses using ESP-only IPSec. IKE suppression is used to support multiple local machines communicating with the same remote IP address. However, the ability to have a many-to-one mapping for local to remote machines for VPN sessions without changing the VPN is substantially effective. An example is a telecommuter for a company that all wants to communicate to the same server of the company.

  Incorporating obtaining a public IP address at the network interface level eliminates the need to include an operating system (OS). In other words, at the OS level, IKE is started, and in response to such start, the NIC 100 automatically requests a public IP address. This request does not require any OS action other than IKE initiation. Furthermore, the NIC 100 is configured for IPSec, so if a public address is obtained, it may be automatically used for IPSec packets. Furthermore, known protocols supported by clients and gateways may be used without introducing additional signaling channels.

  FIG. 3A is a flowchart illustrating an embodiment of an IPSec / NAT gate side integration sub-process 298 with IKE suppression in accordance with one or more aspects of the present invention. In step 217, the NAT gateway 106 receives the packet. This packet may be an IKE start packet from step 210 of FIG. In step 218, the NAT gateway 106 checks such a packet to determine if it is an IKE packet.

  Continuing to refer to FIG. 3A and referring again to FIGS. 1, 2, 5A and 5B, if in step 218 the received packet is not an IKE packet, then in step 219 such packet is public or A check is made to determine if it has a private IP address. The NAT gateway 106 can receive IPSec and non-IPSec packets, but client computers such as client computers 106-A to C in the LAN 102 send a public IP address as an IP source address to the NAT gateway 106 only for communications related to the IPSec session. To do. It should be noted that negotiating an ESP-only IPSec is not a problem. This is because the public IP address may be used as the IP source address for ESP only traffic through the NAT gateway 106. In step 219, if the source IP address is a public IP address obtained to the NAT gateway 106, this instructs the NAT gateway 106 to process such received packets for the IPSec session. Thus, if a packet with a public IP source address is found in step 219, it is processed in step 256 without NAT. In other words, the NAT gateway 106 transmits a packet having a public IP address as a source IP address but not accompanied by a NAT. If a packet with a private IP source address is found in step 219, it is processed in step 257 with NAT. In other words, the NAT gateway 106 replaces the public IP address with such a private IP source address before sending this packet to the WAN 104.

  If the received packet is an IKE packet at step 218, a check is made at step 221 to determine if the destination IP address of such a packet is in the mapping table as part of the IKE suppression subroutine 297. With IKE control or suppression, it should be understood that IKE suppressed packets are sent by the gateway 106 until the remote-to-local SPI is stored and the pending bit is inverted, as described in detail below. In other words, only one IKE “conversation” may be in progress between a given local client MAC address and a given remote IP address.

  Assuming that NAT forces all external traffic to be initiated by the local client, IKE traffic is always initiated by a local client, such as client 106-A. This intuitively requires public addresses to be replaced with private addresses, so traffic can only flow through NAT in one direction, that is, only from the local (private) side to the remote (public) side. Because. The first IKE “main mode” transaction of client 106-A and the subsequent IKE “quick mode” transaction (alternatively, the client may choose an “aggressive mode” transaction instead of main and quick). A client selected 64-bit initiator cookie is used in the ISAKMP header. Subsequent rekeying is done at the discretion of the local client 106-A, which can be configured with either another quick mode exchange or a new main mode exchange (this means that the client selects a new initiator cookie). Request that IPSAMP 300 generate a new line, which is initially defined by the local client's IP or MAC address, the remote IP address, and the client's initiator cookie).

  In step 221, such a destination IP address does not appear in IPSAMT 300, then in step 222 a line is generated in IPSAMT 300, and in step 260, the MAC address of client computer 106-A and the destination of remote computer system 101 are also generated. If the IP address is stored in the relevant state and the pending bit for such a row is set, for example, set to 1 in the mapping table, the remote-to-local security parameter index associated with the remote IP address (IKE of the local client) Indicates that the first IP destination address found in the packet has not yet been observed. Since the IKE packet conforms to NAT, NAT processing is then performed at step 257.

  In step 221, if the destination IP address of the received packet already exists in IPSAMT 300, an ISAKMP is issued in response to an indication that a security negotiation between the local client MAC address or private IP address and the remote IP address is already in progress. The “initiator cookie” is checked. Traditionally, an ISAKMP initiator cookie is a 64-bit binary number, but with future revisions of the ISAKMP standard, the size of this field will be randomly selected by the client machine and changed to allow such clients and their ISAKMP peers to change. All subsequent ISAKMP conversations in between can be uniquely identified. This cookie is not a web cookie, which is a traditional small text file that a web server stores on a client computer by a web browser. Use of this field allows to correlate multiple ISAKMP negotiations. If such an initiator cookie does not appear in such a mapping table at step 221, a row is generated in IPSAMT 300 at step 222.

  If, in step 221, the ISAKMP initiator cookie in the mapping table matches the received ISAKMP cookie, then in step 223 the pending bits are the relevant row of such mapping table: the client's MAC address, the remote IP address, and A check is made to determine if it was set for the associated row by an initiator cookie that matches this received IKE packet being processed. Of note, the pending bits are arbitrary. This is because the security parameter index may be checked instead. In the case of a new IKE conversation between the local client 106-A and the remote IP address, the security parameter index field 302 is an open or empty entry for this row. This is because IPSec protected traffic resulting from this IKE exchange has not yet been observed by the gateway 106. Notably, in subsequent or new IKE conversations, re-keying allows a new IKE conversation to negotiate a new security parameter index that will be carried over when the old security parameter index expires. Can do. If the pending bit field 303 pending bit is set and a security parameter index value exists in the remote-to-local SPI field 302, the security parameter index value may expire soon, so the gateway 106 The security parameter index in IPSec protected traffic may be expected to change to a new value. This pending bit is cleared when such a new security parameter index is detected in a remote-to-local IPSec protection packet.

  In step 223, the pending bit in the pending bit field 303 is set, eg set to 1, the remote-to-local security parameter index is from the machine whose destination IP address was obtained and recorded in the IPSAMT 300. Instruct. If such a bit is set to indicate that the remote-to-local security parameter index is obtained for the machine associated with the destination IP address, then in step 222 such mapping table A row is generated at This means that another IKE is not suppressed for the same remote IP address because the remote-to-local security parameter index (from a different local client) is obtained for the previous IKE. However, if in step 223 the remote-to-local security parameter index pending bit in the pending bit field 303 has not been inverted from its default value, i.e. still zero (0), this means that other local clients Indicates that IKE cannot be used to negotiate with the same remote IP address. This is because the remote-to-local security parameter index from the indicated remote IP address has not been observed in use. Thus, in step 224, such IKE packets or more specifically IKE initial packets are optionally queued, and the remote vs. local security parameter index for the previous IPSec session by repeating the check in step 223. When the pending bit 303 is set, it is released in step 222 and a row is generated in the mapping table. Options other than queuing the ISAKMP packet are to send an ICMP destination unreachable (format == 3) to the local client with subcode == 3 (port unreachable) or subcode == 9 (destination The communication with the host is administratively prohibited), and ICMP destination unreachable (format == 3) is transmitted.

  FIG. 4 is a flowchart illustrating a receiver-side embodiment of an IPSec / NAT integration process 200 in accordance with one or more aspects of the present invention. With continued reference to FIG. 4 and further reference to FIGS. 1 and 2, the receiver side of the integration process 200 will be described. In step 407, the IP packet is received by the NAT gateway 106 from the computer system 101. In step 408, a comparison is made to determine whether a security parameter index exists in the packet thus received. In other words, it is an IPSec protected packet that uses one of AH only, ESP only, and ESP with AH.

  When an IKE negotiation is initiated by a local client for a remote IP address, the pending bit in the pending bit field 303 is set. This is because remote-to-local security parameters related to traffic from the remote computer system 101 to the local client 106-A that initiated such IKE negotiations are not observed and recorded. When the IP source address of the IKE packet of the local client 106 -A is a private address, the private IP address of the client is stored in the local client IP address field 306. When this field is occupied, the gateway 106 knows for IPSec traffic that ESP-only traffic must be allocated between the client 106-A and the remote machine associated with this remote IP address. However, if the local client 106-A uses the public IP address as the IP source address in the IKE packet, the gateway 106 forgets this by storing the client's MAC address in the local client MAC address field 301. Must do so. When this IKE local client MAC address field is occupied, client 106-A can use IPSec AH only, ESP only, or ESP with AH. Notably, in such a case, client 106-A will use the public IP address specified by gateway 106 and is stored in step 254, so that the machine with this MAC address Recall that a public IP address has been specified. Only the MAC address recorded in step 254 must be allowed to use the associated public IP address.

  If IKE suppression is used and IPSec protection data does not flow from the machine with the associated remote IP address to the local client in the mapping table after IKE negotiation, the pending bit in the pending bit field 303 is set to 1, for example. To prevent other clients from initiating IKE negotiation with the same destination IP address. Therefore, using the time stamp 305, the remote-to-local security parameter index in the remote-to-local security parameter index field 302 is not obtained within the determined time, so such a pending bit is set to eg zero (0). If cleared, the expired row can be removed from the IPSAMT 300 to allow another IKE to the same remote IP address to be performed. This line does not need to be removed until another station actually attempts to initiate an IKE negotiation with the same remote IP address and is notified of a collision at this point. Thus, it is confirmed that the pending bit in the pending bit field 303 is set to 1 and the associated timestamp in the timestamp field 305 confirms that this row or these row entries are old enough to purge. Will be checked.

  If the pending bit 303 is cleared, ie set to zero (0), another IKE session is started between the same two addresses, namely the local MAC or local client private IP address and the remote IP address. Until then, the relevant row is kept in IPSAMT 300. If another IKE session is started between machines that already have an IKE session for which a remote-to-local security parameter index has been obtained, the relevant line for the previous IKE session between these two machines is the remote-to-local security Even if the parameter index is known, the bit of the pending bit field 303 is set. In this case, setting such a pending bit to 1, for example, indicates that the related line is in the delete pending state.

  In situations where a new IKE replaces an existing IKE for which a remote-to-local security parameter index has been obtained, start using the new remote-to-local security parameter index for traffic from the remote IP address to the local client At this point, a new row that differs only in the value of the remote-to-local security parameter index can be cloned from the old row. When such a new row is generated, the pending bit in the pending bit field 303 of the old row can be cleared again, i.e. set to zero (0). More generally, each time a packet appears to match a table entry, the timestamp field 305 is updated, but the old row causes traffic to arrive using the old remote-to-local security parameter index and the time You must immediately stop making the line older and older with the passage of time. When this line is old enough, it is eliminated by the normal “garbage collection” operation. For example, a new IKE can be initiated because the exchanged key is about to expire or has expired.

  A new IKE negotiation can be made at any time at the local client's decision to initiate a new IKE communication. The IKE negotiation is not initiated at the remote machine or remote IP address, even for an established IKE session. The session originator, which must always be a local client in the case of NAT, initiates all further IKE conversations, eg, rekeying negotiations. Continuing to refer to FIGS. 5A and 5B and referring again to FIG. 4, if in step 408 the received packet, such as a packet not protected by IPSec, does not have a security parameter index, such a packet is In FIG. 3, the routing is performed without checking the IPSAMT 300. Such routing decisions may be driven by a gateway NAT table that promotes the non-IPsec NAT function of the gateway 106. Since NAT is well known, a detailed description of NAT is omitted for clarity.

  In step 408, if a security parameter index is found in the packet received in step 407, the IPSAMT 300 is checked in step 410 to determine the IP source address of the packet that matches the address in the remote IP address field 304. To determine if a remote-to-local security parameter index exists. If there is a value in the remote-to-local security parameter index field 302 from the ISAMT 300 at step 410, then at step 411 such a matching packet is remote-to-local from the IPSAMT 300 found in such a received packet. Routed to the associated address in the local client MAC address field 301 or local client private IP address field 306 associated with such a value in the security parameter index field 302.

  When the gateway 106 identifies a client computer using the MAC address of the mapping table, the local client uses the gateway-provided public IP address as the IP source address in its local-to-remote packet. In such a case, the gateway 106 stores such a local client address from the local client public IP address field 309 to remember or remember, so the gateway 106 (reverses its local bit). It is possible to ensure that only the MAC address in this domain that first used DHCP to obtain such a public IP address can use this public IP address. Since the IP source address of such a local-to-remote packet is already a public IP address, the gateway need not perform NAT translation of the packet. Therefore, AH protected packets may leave the local domain without encountering IP address translation, and thus the remote side can see the digital signature embedded in the AH header. Regardless of whether the local client address is a private IP address or (public IP address, MAC address) pair, it is recorded from the initial traffic from the local client to the remote IP address, so the gateway 106 It is possible to decide whether to return traffic to the client. The local client's MAC address is extracted from the MAC source address field of the first local-to-remote packet with the remote IP address as the destination.

  In situations where there are clients that are more active than gateway-managed public IP addresses, there is a many-to-one mapping of remote IP addresses to local clients, in this case using the remote-to-local security parameter index to determine which of the tables Identifies whether the row corresponds to an appropriate local client. The gateway 106 remembers for recall what form of destination address to use for final delivery to the local station. For local client machines where the MAC address and public IP address are recorded, the IP destination address in the return traffic is also the same public IP address that the gateway 106 assigns to each such local client machine. Therefore, the gateway 106 does not change the packet destined for the client's public IP address (the MAC source address of the MAC frame becomes the address of the LAN interface of the gateway in the local subnetwork, and the MAC destination address of the frame is The gateway 106 knows it can be sent securely (except that it becomes the local client MAC address recorded in the matching row of the table).

  For traffic to the local client where the private IP address is recorded (only ESP-only traffic falls into this category), the gateway 106 sets the address in the remote IP address field 304 and the remote-to-local security parameter index field 302. The value is used to identify the appropriate row in the mapping table, from which the address in the local client private IP address field 306 is extracted, so that the IP destination address of the packet is the private IP of such local client. Convert to address.

  In step 410, there is no value in the remote-to-local security parameter index field 302 associated with the mapping table row whose address in the remote IP address field 304 matches the IP source address of the received packet, and in such a mapping table. If the bit in the pending bit field 303 of this row is set to 1, for example, in step 412, from a received packet having such an IP source address and having such a pending value, a remote to local security parameter index field IPSAMT 300 is updated by adding the value added to 302. In response, the bit in pending bit field 303 is cleared for this row (ie, set to zero (0)) to indicate receipt of the pending remote-to-local security parameter index value. Each time a packet matches a row in the table, the timestamp field 305 is updated for that row.

  In FIG. 5B, the value of the remote-to-local security parameter index field 302 and the value of the pending bit field 303 are written to the remote-to-local security parameter index string or field 302 and the pending bit string or field 303, respectively, as an example. The IPSec IPSAMT 300 is updated. Furthermore, if IKE suppression is active, clearing the bit in the pending bit field 303, for example, by inverting it to zero (0), causes another local client to previously receive the security parameter index value pending state. Allows to initiate an IKE session to the same remote IP address. After the update in step 412, in step 411 such an incoming IP packet is associated with it from the local gateway MAC address field 301 or the local client private IP address field 306 in the IPSAMT 300 based on the address by the NAT gateway 106. Routed to client computer 106-A.

  Notably, if there is no row with a matching remote-to-local security parameter index 302 for the received packet, the NAT gateway 106 communicates with such a remote IP address to be one local client MAC. Given only the address, such a received packet can still be routed correctly. Alternatively, if more than one open remote-to-local security parameter index is allowed for the same remote IP address, such a packet will be sent to each local client MAC address that communicates with such remote IP address. Or may be sent to the broadcast MAC address for all client computers on the LAN 102, and then the NAT gateway 106 sends the appropriate local client to the appropriate remote-to-local security for that remote IP address. A two-way response can be awaited so that it can be linked to the parameter index.

  It is possible that two different local clients may select the same remote-to-local security parameter index value when participating in an IKE negotiation with the same remote IP address. This is possible even if IKE suppression is used if all clients share the same public IP address.

  However, if two clients select the same remote-to-local security parameter index value and they are assigned different local client public IP addresses, the four associations with the received packet, namely the remote IP Packets can be forwarded based on address, remote-to-local security parameter index, IPSec protocol, and local client public IP address.

  If the local client has the same public IP address, either MAC address that first enters IPSAMT 300 receives all relevant traffic for that remote-to-local security parameter index 302. This is because there is no way for the gateway 106 to contour the traffic for one station separately from the traffic of another station with the same four relationships. However, communication between the second local client and this remote IP address will not be successful, so those communicating parties will attempt a new IKE negotiation, which is unique in all possibilities. This will result in the selection of remote versus local security parameter index values. This is because the remote-to-local security parameter index has been designated from 0 to 255 and is a number randomly selected from the range from 256 to 4,294,967,295. One way to prevent the selection of overlapping remote-to-local security parameter indexes is to have the final stations broadcast their current IP address and security parameter index to the LAN, thus causing other stations in the domain to duplicate. It is to be able to check. However, such a configuration requires significant changes in the client software, thus causing the communication session to fail, causing a low probability event, and restoring the IKE session that was invalid at the last station to another IKE session. Compared to what is done by starting, it is considerably more complicated.

  Notably, after a successful IKE negotiation, the IPSec packet encrypts the upper layer of protocol information, so this information is not available to the NAT gateway. However, the security parameter index is obtained at the gateway because it is not encrypted for the IPSec session. Furthermore, the security parameter index can be obtained in each header type, ie, ESP header and AH, where AH includes, but is not limited to, ESP with AH. Thus, once the IKE is completed by the client computer and the destination computer and the encrypted data is exchanged using the key, the NAT gateway can be used to communicate with either or both types of IPSec, ie ESP and AH. It includes an updated IPSAMT 300 with remote-to-local security parameter index values. Of note, although the IPSAMT structure is described herein as a single entity, it is clear that such an IPSAMT may be divided into multiple tables to duplicate one or more columns. Will. This has the effect that one or more tables can be formed by hardware, firmware, software or a combination thereof. Therefore, the mapping table includes a single mapping table and a plurality of related mapping tables. Further, the collected and associated information described herein may be stored in forms other than tables, including but not limited to data structures such as databases.

  A new security parameter index in an AH or ESP packet may also be identified through the use of a sequence number field in such a packet. The first packet in a new security association (SA) always has the sequence number “0x00-00-00-01”. Although the header formats are different, AH and ESP each start with a sequence number “0x00-00-00-01” in both cases, incremented by 1 for each transmitted packet, and 0xFF The sequence number field is used in the same way in that it does not exceed -FF-FF-FF. The first remote-to-local security parameter index must arrive with the sequence number “0x00-00-00-01” and when two stations participate in re-keying, the new remote-to-local security parameter index , Must arrive with a sequence number field set to "0x00-00-00-01". A packet that includes a new security parameter index value but whose sequence number is greater than “0x00-00-00-01” is an invalid packet and the gateway can choose to discard it. However, since the client can detect such an error condition equally, forwarding such a packet is probably not harmful.

  Another error condition that the gateway can select for implementation is to block packets whose remote-to-local security parameter index wraps from 0xFF-FF-FF-FF to 0x00-00-00-00. In order for the gateway to enforce this restriction, the gateway tracks the sequence number of each row in the mapping table by deleting the matching row from the mapping table so that future traffic cannot be forwarded, or 0xFF− The sequence number value of FF-FF-FF must be triggered. Again, the local client must be able to enforce this restriction, so the gateway does not need to shield the client from this state, but such a shield is described here even if enabled. It does not interfere with the algorithm.

  In addition, SA renegotiation may be predetermined or anticipated by the gateway. This is because, as described above, the sequence number field is not allowed to wrap from 0xFF-FF-FF-FF to 0x00-00-00-00. When the sequence number value falls below 33% of 0xFF-FF-FF-FF, the gateway can reasonably expect to see a new IKE exchange and set a new SA. Of course, the two parties can choose to negotiate a new SA more quickly than the sequence number space can wrap, ie the negotiated lifetime of the SA is probably 4,294,967,295 peers. This is much shorter than the time required to transmit the packet. However, if the SA is negotiated with a very long lifetime and the packet transmission rate is very high during that time, the sequence number gives a queue that a new IKE exchange is imminent. There may be multiple SAs between the local client and the remote machine. There are AH only, ESP only, or ESP with AH, each with a unique security parameter index. Accordingly, the mapping table 300 includes an “IPSec protocol” value column 308 that indicates whether the remote-to-local security parameter index value is associated with AH, ESP, or both. Furthermore, the mapping table 300 may record both the AH and ESP security parameter indexes independently, for example, in separate rows of the table 300. This is because the remote-to-local security parameter index value has the same opportunity for AH and ESP, so it is necessary to record the AH or ESP protocol type to inform which is which. Notably, if two local clients talk to the same remote IP address, and both choose the same remote-to-local security parameter index for the same IPSec protocol, the gateway 106 Forward all traffic for the security association to the client that initially negotiated its remote-to-local security parameter index.

  SAs may be idle for a long time after an IKR initial exchange or after a re-keying exchange, even if they agree on a new security parameter index on each side, they may not communicate IPSec protected data. Yes, therefore, IPSec protection data will not reach the gateway 106 to allow the remote-to-local security parameter index field 302 in the mapping table 300 to be clustered. During this quiet period, it is possible that a third party could send a counterfeit and fake packet with sequence number 0x00-00-00-01 at a randomly selected (invalid) security parameter index. Gateway 106 determines that the IKE for the line matching the intended IP source address in the incoming packet is not performed between the internal and external machines (ie, pending bit field 303 is set to 1). However, if there is no row in the mapping table 300 that does not have a security parameter index value in the remote-to-local security parameter index field 306, such a packet can be immediately rejected. However, if an IKE exchange has occurred but IPSec traffic has not yet flowed through the gateway 106, only the endpoint of the IKE connection can reliably know whether the security parameter index is valid. Therefore, the gateway 106 must monitor the complete two-way IPSec protected traffic exchange between IKE peers before recording a new remote-to-local security parameter index in field 302.

  If the counterfeit packet is transmitted as described above, the local client 106-A discards the counterfeit packet, transmits an error message, or starts a new IKE exchange, and Confirm SA or make a new negotiation. If the client 106-A responds with an IPSec protection packet, but the remote IP address uses a different security parameter index in its response, the gateway 106 will assume that the first security parameter index that it sees is imitation remote vs. local. Know that it was a security parameter index.

  Gateway 106 cannot clear pending bit 303 until it sees a two-way IPSec protection exchange between the external machine and the internal machine. The gateway 106 can use the initial sequence number as additional evidence that it has the correct remote-to-local security parameter index value. If a fake packet is received and the security parameter index of such a fake packet is not in the mapping table 300, then the gateway 106 is assumed to be from a remote IP address that does not have a known security parameter index. A protection packet can be discarded. However, this is a case where the gateway 106 knows that the IKE exchange is not performed and the existing security parameter index of the mapping table 300 may be validly invalidated. The gateway 106 can discard such a packet regardless of the value of the sequence number field. Briefly, if a mismatched security parameter index arrives from a remote IP address and there is no line with the pending bit 303 set in a line that matches the IP address, the packet may be deleted.

  Certain embodiments of the present invention are program products that can be fully or partially resident on a gateway and / or client computer. The memory is a volatile and / or nonvolatile memory, such as a magnetically readable memory (for example, floppy disk, hard disk, etc.), an optically readable memory (for example, CD-ROM, -RW, DVD). -ROM, -RAM, etc.), as well as electrically readable memory (e.g., DRAM, SRAM, EEPROM, registers, latches, etc.), but not limited thereto. Accordingly, an embodiment of the present invention is a program product that includes a machine-readable program. The program product (s) define the functions of these embodiments and can be included in various signal / retention media, including (i) non-writable storage media (eg, Information permanently stored in a read-only memory device in a computer such as a CD-ROM disk readable by a CD-ROM drive), (ii) a writable storage medium (eg in a diskette drive or hard disk drive) Including, but not limited to, changeable information stored on a floppy disk) or (iii) information carried to the computer by a communication medium such as a computer or telephone network including wireless communication. The latter embodiment specifically includes information downloaded from the Internet and other networks. Such a signal bearing medium represents an embodiment of the present invention when carrying computer readable instructions that direct the functions of the present invention.

  While preferred embodiments of the invention have been described above, other and further embodiments of the invention may be devised without departing from the basic scope thereof, and thus the scope of the invention Is defined by the claims. A claim describing a step does not imply that order unless the order of steps is clearly indicated. All trademarks are the property of their respective owners.

FIG. 7 is a block diagram illustrating an embodiment of a computer system in accordance with one or more aspects of the present invention. 1 is a network diagram illustrating an embodiment of a network in accordance with one or more aspects of the present invention. FIG. 6 is a flowchart illustrating an embodiment of portions of an IPSec / NAT integration process in accordance with one or more aspects of the present invention. 6 is a flowchart illustrating an embodiment of portions of an IPSec / NAT integration process in accordance with one or more aspects of the present invention. 6 is a flowchart illustrating an embodiment of portions of an IPSec / NAT integration process in accordance with one or more aspects of the present invention. FIG. 6 is a table diagram illustrating an embodiment of an IPSec association mapping table (IPSAMT) in accordance with one or more aspects of the present invention. FIG. 6 is a table diagram illustrating an embodiment of an IPSec association mapping table (IPSAMT) in accordance with one or more aspects of the present invention.

Explanation of symbols

DESCRIPTION OF SYMBOLS 10 ... Computer system, 11 ... CPU, 13 ... System memory, 12 ... Input / output (I / O) interface, 100 ... NIC, 101 ... Computer system, 102, 103 ... LAN, 104 ... Wide area network (WAN), 106, 107 ... DHCP server / NAT gateway (gateway), 106-A, 106-B, 106-C ... Client computer, 107- A, 107-B, 107-C ... client computer, 108 ... router, 110 ... network, 112 ... local memory, 200 ... IPSec / NAT integration process, 298 ... IPSec / NAT gateway side integration subprocess, 299 ... IPSe / NAT client integration subprocess, 300 · · · IPSec allocation mapping table (IPSAMT)

Claims (10)

A gateway computer capable of network address translation (NAT) and establishing a secure communication channel between a remote computer and a client computer,
Memory,
A processor coupled to the memory;
With
The processor is
Providing the client computer with one gateway computer public address in a pool of gateway computer public addresses;
Receiving from the client computer a first request for an Internet Protocol (IP) address corresponding to the remote computer;
A security parameter index (SPI) value is obtained by negotiating a security association with the remote computer;
Based on the SPI value, a local address of the client computer obtained from the negotiated security association, a destination address of the remote computer obtained from the security association, a medium access control (MAC) address in a mapping table, In the memory,
Establishing a secure communication channel between the remote computer and the client computer by directing data packets received from the remote computer to the client computer based on the mapping table;
A gateway computer characterized by that. The processor further obtains an initiator indicator from the client computer that includes a negotiation status bit associated with the negotiated security association;
The gateway computer according to claim 1. The processor further stores in the mapping table the initiator indicator, a time stamp, and a security protocol type identifier associated with a security protocol header of the first request;
The gateway computer according to claim 2. The processor further comprises:
Setting a flag bit indicating that the SPI value is not stored in the mapping table;
Clearing the flag bit after obtaining the SPI value;
The gateway computer according to claim 1. The processor further removes information stored in the mapping table when new information cannot be acquired even after a predetermined time has elapsed.
The gateway computer according to claim 1. The processor further comprises:
Assigning a first client identifier to the first request;
Receiving from the client computer a second request for a different IP address;
Assigning to the second request a second client identifier derived from the first client identifier;
The gateway computer according to claim 1. The mapping table further stores an initiator cookie established by the client computer that identifies further communication between the client computer and the remote computer;
The gateway computer according to claim 1. Only the client computer can use the provided gateway computer public address,
The gateway computer according to claim 1. The SPI value specifies a unique row in the mapping table;
The gateway computer according to claim 1. Internet Protocol Security (IPSec) manages transactions between the gateway computer and the remote computer;
The transaction includes a header having an authentication header (AH) or an encapsulating security payload (ESP);
The gateway computer according to claim 1.

Images