EP1130846A2 - Network address translation gateway - Google Patents
Network address translation gateway Download PDF

Info

Publication number

EP1130846A2

EP1130846A2 EP01400559A EP01400559A EP1130846A2 EP 1130846 A2 EP1130846 A2 EP 1130846A2 EP 01400559 A EP01400559 A EP 01400559A EP 01400559 A EP01400559 A EP 01400559A EP 1130846 A2 EP1130846 A2 EP 1130846A2

Authority

EP

European Patent Office

Prior art keywords

address

datagram

local

spi

external

Prior art date

2000-03-03

Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)

Withdrawn

Application number

EP01400559A

Other languages

German (de)

English (en)

French (fr)

Other versions

EP1130846A3 (en

Inventor

Israel Daniel Sultan

Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)

Nexland Inc

Original Assignee

Nexland Inc

Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)

2000-03-03

Filing date

2001-03-02

Publication date

2001-09-05

2001-03-02 Application filed by Nexland Inc filed Critical Nexland Inc

2001-09-05 Publication of EP1130846A2 publication Critical patent/EP1130846A2/en

2003-09-24 Publication of EP1130846A3 publication Critical patent/EP1130846A3/en

Status Withdrawn legal-status Critical Current

Links

Espacenet

EPO GPI

EP Register

Global Dossier

Discuss

Images

Classifications

H—ELECTRICITY

H04—ELECTRIC COMMUNICATION TECHNIQUE

H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION

H04L12/00—Data switching networks

H04L12/66—Arrangements for connecting between networks having differing types of switching systems, e.g. gateways

H—ELECTRICITY

H04—ELECTRIC COMMUNICATION TECHNIQUE

H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION

H04L63/00—Network architectures or network communication protocols for network security

H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls

H04L63/0272—Virtual private networks

H—ELECTRICITY

H04—ELECTRIC COMMUNICATION TECHNIQUE

H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION

H04L61/00—Network arrangements, protocols or services for addressing or naming

H—ELECTRICITY

H04—ELECTRIC COMMUNICATION TECHNIQUE

H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION

H04L61/00—Network arrangements, protocols or services for addressing or naming

H04L61/09—Mapping addresses

H04L61/25—Mapping addresses of the same type

H04L61/2503—Translation of Internet protocol [IP] addresses

H04L61/2514—Translation of Internet protocol [IP] addresses between local and global IP addresses

H—ELECTRICITY

H04—ELECTRIC COMMUNICATION TECHNIQUE

H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION

H04L61/00—Network arrangements, protocols or services for addressing or naming

H04L61/09—Mapping addresses

H04L61/25—Mapping addresses of the same type

H04L61/2503—Translation of Internet protocol [IP] addresses

H04L61/2517—Translation of Internet protocol [IP] addresses using port numbers

H—ELECTRICITY

H04—ELECTRIC COMMUNICATION TECHNIQUE

H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION

H04L61/00—Network arrangements, protocols or services for addressing or naming

H04L61/09—Mapping addresses

H04L61/25—Mapping addresses of the same type

H04L61/2503—Translation of Internet protocol [IP] addresses

H04L61/255—Maintenance or indexing of mapping tables

H—ELECTRICITY

H04—ELECTRIC COMMUNICATION TECHNIQUE

H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION

H04L61/00—Network arrangements, protocols or services for addressing or naming

H04L61/09—Mapping addresses

H04L61/25—Mapping addresses of the same type

H04L61/2503—Translation of Internet protocol [IP] addresses

H04L61/256—NAT traversal

H04L61/2564—NAT traversal for a higher-layer protocol, e.g. for session initiation protocol [SIP]

H—ELECTRICITY

H04—ELECTRIC COMMUNICATION TECHNIQUE

H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION

H04L63/00—Network architectures or network communication protocols for network security

H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks

H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload

H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption

H—ELECTRICITY

H04—ELECTRIC COMMUNICATION TECHNIQUE

H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION

H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass

H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]

H—ELECTRICITY

H04—ELECTRIC COMMUNICATION TECHNIQUE

H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION

H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass

H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]

H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields

H—ELECTRICITY

H04—ELECTRIC COMMUNICATION TECHNIQUE

H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION

H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass

H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]

H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields

H04L69/162—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields involving adaptations of sockets based mechanisms

H—ELECTRICITY

H04—ELECTRIC COMMUNICATION TECHNIQUE

H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION

H04L2101/00—Indexing scheme associated with group H04L61/00

H04L2101/60—Types of network addresses

H04L2101/618—Details of network addresses

H04L2101/663—Transport layer addresses, e.g. aspects of transmission control protocol [TCP] or user datagram protocol [UDP] ports

Definitions

Virtual private networking (VPN) using TCP/IP enables secure, high speed communications between remote computing sites, using the internet as a communications medium.

Information passing between sites across the internet may be protected against interception by unwanted eavesdroppers or malicious hackers by a variety of security measures.

Effective security measures must, at a minimum, incorporate functions that ensure any or all of the following protections: Data integrity against the inadvertent or malicious modification of data during transit; prevention against denial-of-service attacks by employing anti-repeat measures; source authentication; confidentiality of source address and other header information during transit; and packet payload protection against unwanted interception.

One standard model for providing internet security is the Internet Protocol Security suite, IPSec. IPSec works with the TCP/IP communications protocol to provide secure communications between devices connected to the internet or connected to private LANs (Local Area Networks) that are, themselves, connected to the internet.

the TCP/IP (Transmission Control Protocol/Internet Protocol) protocol suite uses IP addresses to identify each device on a network.

a global IP address uniquely identifies a device on the internet.

Such devices may be computers, printers, routers, switches, gateways, or other network devices.

Devices having global IP addresses may be directly referenced as a source or destination on the Internet.

the TCP/IP communications protocol is not exclusively limited to the internet, but may be used on private LANs as well. Private LANs using TCP/IP frequently use "local" IP addresses for network devices. Although no two devices on a private LAN may share the same local IP address, private LANs are isolated from the internet, and local devices on the LAN are not visible from the internet.

IP addresses for local devices therefore need not be "globally" unique.

a LAN using local IP addresses will be connected to the internet through a gateway, which is a device that may filter or route messages between the LAN and the internet. Since the gateway is directly attached to the internet, and is visible to it, the gateway must have a globally unique IP address for communicating across the internet. However, since the LAN is not directly visible from the internet, local machines on the LAN do not require IP addresses that are globally unique.

TCP/IP is the communications protocol that is used on the internet. Information to be communicated using TCP/IP is contained in "datagrams.â A datagram consists of a discrete "packet" of information to which one or more headers are appended. Headers contain information needed by TCP/IP to direct the packet to its intended destination and to ensure its proper handling during transit. Each datagram is individually addressable, and may be a connection-oriented TCP datagram or a "connectionless" UDP (User Datagram Protocol) datagram. Each UDP datagram includes an IP header and a UDP header. The IP header contains at least a "sourceâ IP address and a "destination" IP address, while the UDP header includes source and destination service addresses (port addresses, given as numbers).

IP addresses are 32 bits in length, and are associated with the now-familiar xxx.xxx.xxx.xxx format. In this format, each three-digit segment is a binary octet representing a number between 0 and 255.

a complete IP address combines the address of a logical network or network segment with the address of a "node" (device) on the network. The address of the network or network segment may encompass the first 3, 6, or 9 digits of the IP address.

a device on the network or network segment is identified by a node address that consists of those remaining digits that are not used in the network or network segment address.

the source and destination service addresses contained in a UDP header are 16-bit numbers, variously known as âportsâ or âsockets,â which are used to direct the packet to an intended process that is active on the sending or receiving device.

the term "port,â or âport address,â as used herein, refers to a service address field in a UDP header.

port 80 is reserved for HTTP

ports 20 and 21 are reserved for FTP.

the local host may select any port number from a pool of unreserved port numbers to identify the "sourceâ process.

a reply packet referencing that port number in the "destination" field will be directed to the process.

NAT Network Address Translation

a gateway device separating a LAN from the internet can provide security as a firewall while enabling machines with local IP addresses to access the internet through the unique global address of the gateway.

a device on a LAN may have a static local IP address, or it may have a local IP address dynamically assigned to it at log on.

the gateway maintains a translation table with the local IP addresses for each device on the LAN.

a UDP packet sent from a local machine and destined for the internet will have its local IP address and port address identified in the source fields of the IP and UDP headers, respectively.

the gateway will receive the packet from the local machine, will substitute its external globally-unique IP address and a new port address (taken from a pool of unused, unreserved port addresses) into the source fields of the IP and UDP headers. It will next update the CRC (Cyclical Redundancy Check) and make any other necessary changes to ensure data integrity, then will send the packet to the internet. As part of the process, the gateway will update its internal translation table to cross reference the local machine's IP address with the source port address originally reported by that machine, with the new source port address assigned to the internet-bound packet, and with the destination IP address. Upon receipt of a reply from the internet, the gateway will recognize its own IP address in the packet header, and will examine the incoming packet's destination port address.

CRC Cyclical Redundancy Check

the gateway will substitute the cross referenced local machine's IP address and original port address into the destination fields of the packet, will update the CRC and any other necessary parameters, and then will dispatch the packet to the LAN, where it will be received by the local machine and directed to the appropriate process. In this manner, a number of computers on a LAN having only local IP addresses can communicate across the internet through a single globally unique IP address.

NAT gateways provide firewall security against direct accessing of the LAN from the internet, they do not provide security against interception or modification of a packet intended for the LAN while in transit on the internet, and they do not ensure "trustworthiness" from challenges originating within the LAN.

the security provided by IPSec is a necessary protection for LANs that must maintain security while interfacing with the internet.

IPSec A common implementation of IPSec is to provide security for VPNs consisting of at least one main computing site and one or more remote LANs.

the main site and remote LANs are connected across the internet, using that high speed medium to communicate between sites instead of significantly more expensive private leased lines.

the drawback to using the internet as a transmission medium is that the internet is inherently insecure, and provides little or no inherent protection against the snooping, detection, "spoofing," or ultimate theft, modification or diversion of messages by hackers.

the IPSec protocol implements security measures to ensure authentication of data and data integrity.

the IPSec protocol suite implements security at the network layer of the multilayered OSI (Open Systems Interconnection) network reference model.

the suite includes a number of separate protocols that are used in conjunction with one another to ensure the security of UDP datagrams that carry information across the internet.

the base architecture of IPSec compliant systems is explained in RFC2401, "Security Architecture for the Internet Protocol," S. Kent and R. Atkinson (November 1998).

the AH (Authentication Header) protocol assures data integrity, source authentication, and incorporates "anti-repeatâ measures to deter denial-of-service attacks.

ESP Encapsulation Security Payload protocol provides protections similar to AH, but adds the additional feature of payload encryption.

SPI Security Parameters Index

ISAKMP/Oakley Internet Security Association and Key Management Protocol, also commonly referred to as Internet Key Exchange - IKE

ISAKMP/Oakley Internet Security Association and Key Management Protocol, also commonly referred to as Internet Key Exchange - IKE

the ISAKMP/Oakley protocol (hereafter referred to simply as ISAKMP) involves the initial exchanges of unencrypted messages to provide both machines with initialization data from which authentication may be established and secure keys for data encryption may be generated.

ISAKMP Internet Security Association and Key Management Protocol

SAs Security Associations

the SPI for each machine is computed from information exchanged during the ISAKMP transmissions, and is carried in the AH or ESP header that is appended to UDP packets. Because IPSec protocols may be nested to provide security in a variety of environments, a single datagram may include both an AH and an ESP header, and may encrypt some header information.

Each of the foregoing security protocols modifies the UDP packet by placing new header information on the packet, modifying certain fields within the packet to conform to the protocol being used and, in some cases, encrypting the payload and all or parts of other packet headers.

IPSec when a UDP datagram leaves a "secure" domain for transit across an untrusted network, it will normally consist of an IP header, an AH or ESP header (or both), and an encapsulated payload.

Header information will include a destination address, an SPI, and sufficient SA information to ensure that the datagram reaches its destination and can be authenticated to the destination host. Encapsulation of the payload ensures that information contained within the payload is denied to unwanted eavesdroppers and hackers.

the initial destination host for the datagram may be a router, gateway, or firewall between a LAN and the internet.

the datagram may be opened, examined or decrypted in whole or in part, analyzed for further address information, and routed to a local IP address on the LAN.

ISAKMP handshaking protocol used in IPSec requires that both hosts intending to establish a secure session between them use a process-specific port address (Port 500) for initial message exchanges. For this reason, Port 500 has been assigned for exclusive use with the ISAKMP protocol.

computers attempting to negotiate secure communications parameters by employing the ISAKMP protocol must communicate strictly through each computer's Port 500. That is, ISAKMP messages from either computer must identify Port 500 as both the source and destination port addresses. If either computer receives a packet in which Port 500 is not specified as being both the source and destination, the packet will be discarded.

While this protocol provides assurance that two hosts are communicating with each other, it becomes unworkable when one host is located on a LAN that uses local IP addresses and a NAT gateway.

Host A having a local IP address on a remote LAN protected by a NAT gateway, wishes to establish a secure session with Host B, located at a main office computing site.

Host A would initiate the protocol by sending an unencrypted UDP datagram to Host B, giving the "destination" as Host B's IP address, and the destination port address as "Port 500."

the gateway will translate the destination port address to an arbitrary port number.

the ISAKMP protocol Upon the arrival of the datagram at Host B, the ISAKMP protocol will not be recognized, and Host B will not respond. The computers will fail to establish a secure session. Because of this difficulty, it has heretofore been believed that the ISAKMP protocol cannot be used to establish a VPN using a NAT gateway where each computer on the remote LAN uses a local rather than a global IP address.

a computer using a local IP address on a remote LAN attached to an external network such as the internet through a NAT gateway will use the ISAKMP protocol to exchange keys and establish SAs that will support a secure session under IPSec.

the gateway performs address translation as normal. However, whenever a machine on the LAN originates an ISAKMP protocol message, the gateway will identify the datagram containing port addresses of Port 500. Upon encountering such a datagram, the gateway will translate the source IP address, but will not translate the source port address, leaving it at Port 500, and will dispatch the packet to the internet with Port 500 designated as both the source and destination port addresses.

the gateway will also update its internal table to "bind" Port 500 to the local IP address and associate that binding with the external IP address of the destination machine for a predetermined length of time. If a valid reply is not received within the predetermined length of time, the "binding" between Port 500 and the local IP address will be released. This feature is necessary to ensure that Port 500 is not tied-up indefinitely, such as, for example, in a situation in which an ISAKMP protocol transmission has been initiated to an incorrect destination IP address. Under those conditions, the gateway would never receive a valid reply. If there were no timer to release Port 500 after a period during which a valid reply is not received, the port would remain bound to the local IP address until the gateway was reset. For most conditions, a period of two seconds should be a sufficient length of time to maintain the binding between Port 500 and the local IP address while awaiting a valid reply.

Port 500 During the time that Port 500 is bound to a local IP address, the gateway will continue normal datagram processing of datagrams not having Port 500 port addresses while awaiting a valid reply.

a valid reply will be a datagram having a source IP address that is the same as the external IP address that is associated with Port 500, and will have both the source and destination port addresses as Port 500.

the gateway While awaiting a valid reply, the gateway will ignore other UDP datagrams from the external network having Port 500 source and destination port addresses, but not the proper source IP address.

Port 500 is bound to a local IP address

datagrams received from the LAN having source and destination port addresses of Port 500 will undergo "normal" address translation in which the Port 500 source port address will be translated to an arbitrary, unused port address before being sent to the external network.

Port 500 Because such a datagram does not have both a source and destination port address of Port 500, it is not a valid ISAKMP datagram, and will be ignored upon reaching its IP destination. If the period of binding Port 500 to a local IP address should expire without a valid datagram having been received by the gateway, the binding will be released, and Port 500 will become available for use by the next datagram having a Port 500 source and destination port address.

Port 500 While Port 500 is bound, upon receiving a valid reply datagram having source and destination port addresses of Port 500 and the correct source IP address, the gateway will process the datagram by substituting the IP address of the local machine into the datagram header's destination IP address field, then will pass the datagram through to the LAN for delivery to the local machine. When the datagram leaves the gateway, the gateway will release the binding between the local IP address and Port 500, and will resume normal datagram processing.

the gateway will time-out after a short predetermined length of time. If the gateway should time-out before a valid reply is received, that ISAKMP message exchange cannot be completed, but must be re-initiated.

the gateway will perform local address translations by referencing the SPI in the ESP header of incoming and outgoing datagrams.

the gateway will also ensure that each packet type (type 50 for an ESP packet) is correct for the datagram being passed through the gateway.

a secure session across a VPN will be interrupted, or a new session started.

the gateway's first indication of this will be its receipt of a type 50 datagram in which the IP addresses are recognized but the SPI associated with the destination does not appear in its internal table.

the gateway will dispatch the datagram to the destination IP address using the new SPI, and will also set the destination SPI value (SPI-in or SPI-out, depending upon the direction of the transmission) in its table to the new value, and the source's SPI value to zero.

the gateway Upon receiving a reply to the transmission, the gateway will replace the zero in the SPI field table with the new SPI for the destination IP address.

the gateway of this invention does not encrypt or decrypt messages, but simply passes the payload (which may be encrypted or unencrypted) through to the LAN or to the internet for processing at the receiving machine, it does not require intensive processing functionality, and may be used for private LANs in which expense and simplicity of setup and maintenance are considerations.

a virtual private network is shown in which a private local area network (LAN) 10 is connected to a computing site 30 located on the internet 50.

the LAN 10 uses local IP addresses, and is connected to the internet through the network address translation (NAT) gateway of this invention 20 .

the computing site 30 may be a business headquarters, or one of any number of private LANs used by a multinational corporation, an educational facility, or any other site which will be frequently accessed from remote locations.

Such sites will normally have a firewall or gateway 35 capable of running encryption and other security applications.

Such a gateway will have the ability to open a packet, decrypt or otherwise access its contents, and perform address translation, routing, de-encapsulation, and data manipulation functions as well.

a server 40 at the main site runs the VPN server software.

Computers 15 at remote sites each run appropriate VPN client software that implements IPSec security protocols on each computer.

a computer 15 on the LAN 10 will communicate with devices on or across the internet through gateway 20 by sending an IP datagram to a server 40 at the computing site 30.

Datagrams received at the gateway 20 are processed according to the decision charts shown in Figures 2 and 3.

the flow charts of Figures 2 and 3 show both the processing steps and a sequence for the steps, the order for performing some of the functions is not critical, and some of the steps may be done in an order other than is shown in the flow charts without affecting the ultimate result.

Figures 2 and 3 show that the first step after a datagram is received by the gateway is to determine the datagram type, while the last step is to perform the IP address translation that is necessary before the datagram is passed through the gateway. Some embodiments, however, could place the step of address translation to some point earlier in the process, and this would not affect the outcome of the process. Since the order of translating the IP address is not critical to the overall process, the determination of when this translation should be done is a matter of engineering choice.

the gateway upon receiving a datagram from the LAN, the gateway will check to see whether the datagram is encrypted. It will do so by checking the "Next Header" field in the IP header to determine the type of datagram it is dealing with, and to see whether the datagram has been encrypted.

a datagram type of 50 (ESP) indicates that the datagram is encrypted, and port address information may not be available.

the gateway will check the datagram's SPI to see whether it appears in the SPt-out field of the gateway's internal table. Representative fields from such a table are shown in Figures 5a - 5c. If the SPI of the datagram is found in the SPI-out field of the internal table, the gateway will modify the source IP address of the datagram to be the external IP address of the gateway, and will send the datagram to the external network for delivery to an external device.

the gateway will next check the datagram's destination port address. If the port address is anything but Port 500, the gateway will enter the source port address into its internal table, cross reference it with the (local) source IP address, and will then substitute an arbitrary, unused port address into the source port address field of the IP header. It will also enter the new port address in its internal table, again cross referenced to the (local) source IP address.

This process which is used for unencrypted datagrams not having Port 500 as a port address, shall be referred to as "normal address translation" for datagrams originating on the LAN. These translations are shown in Figure 6, rows 1 and 2. The datagram will then be dispatched to the internet for routing to the destination IP address.

the gateway must next check its tables to see whether Port 500 is already bound to an IP address. If Port 500 is free, then the gateway will "bind" Port 500 to the (local) source IP address of the datagram, will create an association between the port and the (external) destination IP address, and will send a signal to start the internal timer. The gateway will also process the datagram by substituting the gateway's external IP address for the local IP address in the source IP address field. It will not, however, translate the source port address. By suspending the "normal" translation of the source port address, the gateway ensures that the target machine will be able to recognize the datagram as being an ISAKMP datagram. These steps are also shown in Figure 6, rows 5 and 6.

a decision chart is shown which outlines the steps the gateway will follow in processing datagrams received from the internet.

the gateway Upon receiving a datagram, the gateway will first check its type and, if the datagram is encrypted, will check to see whether the SPI appears in its internal table. If the SPI is recognized, its destination IP address will be translated to be the IP address of the local device, and the datagram will be passed to the LAN for delivery to the local device. If the SPI is not recognized, the gateway will next check to see whether its SPI-in field corresponding to the datagram's source IP address is zero (0).

the gateway will assume that the datagram is the first reply of a new session and will replace the zero in the SPI-in field with the SPI of the datagram. The gateway will then translate the destination IP address to be the local IP address of the device on the LAN, and will send the datagram to the LAN for delivery. This event is shown in Figures 5b and 5c.

the SPI-in for local machine L-1 has been set to zero.

the gateway's receipt of a datagram from the internet having an SPI of 3288 the gateway will not find that SPI in its SPI-in field.

the gateway will next check to see whether the SPI-in field is holding a value of zero.

the gateway will replace the zero with the SPI of the datagram ("3288") and will send the datagram to the LAN. This is shown in Figure 5c.

the gateway will check to see whether it has a port address of 500. If it does not, the datagram will undergo "normal" address translation for datagrams from the external network, meaning that the local port address and local IP address of the device on the LAN will be substituted into the destination fields of the datagram, and the datagram will be sent to the LAN for delivery.

This "normal" address translation for datagrams from the internet is shown in Figure 6 at 17 rows 3 and 4.

Port 500 is bound to a local IP address and is 20 associated with the datagram's (external) source IP address. If it is, then the datagram is 21 valid, and will be passed to the LAN after the destination IP address has been translated 22 from that of the external gateway to the IP address of the local device. Upon passing the datagram to the LAN, the gateway will release Port 500. This event is illustrated in Figure 6 at rows 7 and 8.

Port 500 is bound to a local IP address, and is associated with an external IP address other than that found in the source IP address of the datagram, then the datagram is not valid and will not be further processed by the gateway. This event may be seen in Figure 7 at rows 25 - 31. At rows 25 and 26, local machine L-1 sends an ISAKMP datagram to target T-1. At this point, Port 500 is bound to the IP address of local machine L-1 and is associated with the IP address of target T-1. However, as shown in Figure 7, the timer "times" out before a reply is received at the gateway from T-1, and, at row 27, Port 500 is released.

local machine L-3 sends an ISAKMP datagram to target T-3, binding Port 500 to L-3's IP address and creating an association with T-3's IP address. While Port 500 is bound, a reply is received from T-1. However, because Port 500 is bound, and is associated with T-3's IP address, the reply from T-1 is discarded. This is shown at rows 30 and 31 of Figure 7.

Figures 5a - 5c depict an internal table of the gateway in which the IP addresses and SPI numbers for encrypted communications between local computers and targets on the internet are maintained. Fields for âL-1,â âL-2,â âL-x,â and âT-1â through âT-3â are included for ease of reference, and do not appear in the gateway's internal tables.

the field âSPI-ouf holds the SPI for each target machine during a secure session with a specific computer on the LAN.

the "SPI-inâ field gives the corresponding SPI that will be recognized by the local computer as signifying a valid datagram intended for it.

Figure 5a shows the table at a beginning time. Eight (8) local computers have participated in encrypted sessions with three targets, T-1 through T-3 during the life of the table's data.

each local machine shows an SPI-in associated with its IP address.

targets are shown in the table, it may be noted that each target is using a different SPI-out for communications with each local machine. In this manner, a target will know from which source an encrypted datagram was generated.

FIG. 5b shows the same local and target computers as Figure 5a.

the SPI-out for the session between L-1 and T-1 is a new SPI, indicating a new session between the computers.

the gateway's first indication that a new session is taking place is its receipt of an encrypted datagram from the LAN having an SPI - "14662" - that is not in its table.

the gateway forwards the datagram to the internet, but also modifies its table to place the new SPI in the SPI-out field associated with the source and destination IP addresses for that datagram. It also places a zero in the SPI-in field as a marker to indicate that a new SPI-in is also expected.

Figure 5c shows that a new SPI - "3288" - was included in a datagram received from T-1. That SPI has been entered into the gateway's SPI-in field, and further communications between L-1 and T-1 during this session will use those SPI's to authenticate their messages.

FIG. 6 charts the flow of representative datagrams through the gateway of this invention by a single computer on a LAN communicating with a remote target on the internet.

Each row of the chart represents information in a datagram at either the LAN interface with the gateway or the internet interface with the gateway. Consecutive rows represent data entering the gateway from one side and leaving the gateway at the other.

the gateway has one IP address, which may be a local IP address, at its interface with the LAN, and a global IP address at its interface with the internet.

the columns in Figure 6 depict the side of the gateway the datagram is traversing, the type of datagram, the datagram's source IP address and port address, the datagram's destination IP address and port address, and the datagram's Security Parameter Index (SPI) for encrypted datagrams of type 50, using ESP (Encapsulated Security Payload) protocol.

SPI Security Parameter Index

Row 1 of Figure 6 shows a UDP datagram arriving at the local interface of the gateway, and having a source IP address corresponding to local computer L-1, and a destination IP address of the target on the internet, T-1.

Figure 4 provides a table of IP addresses cross referenced with local designations L-1 through L-3, and target designations T-1 through T-3.

the source port address for L-1 is Port 6404, and the target's destination port is Port 80. Since the datagram is not encrypted, and does not exhibit a port number of 500, it undergoes a normal translation in which an "arbitrary" port address, Port 10425 is substituted into the source port address field and the gateway's external IP address is substituted for the source IP address of the datagram.

the translated source port address is said to be "arbitrary,â it will normally be the next in a sequence taken from a pool of unreserved and presently unused port addresses maintained by the gateway.

the address translation function of the gateway has substituted the gateway's external IP address into the datagram header for the source IP address, and has given the source port an arbitrary number.

Rows 3 and 4 show the reply datagram from the target.

a UDP datagram from the target shows the destination IP address as being the external IP address of the gateway, and a destination port as being the port address arbitrarily assigned by the gateway. Since the datagram is not encrypted and does not have a port address of 500, the datagram undergoes normal translation of the destination port address and IP address, then is sent to the LAN.

the gateway has substituted the local computer's local IP address and port addresses in the destination fields of the header before sending the datagram to the LAN.

the local computer initiates an ISAKMP protocol with the target.

the datagram type is shown as ISAKMP.

Both the source and destination port addresses are Port 500.

the gateway determines that the destination port address is Port 500, it checks to see whether Port 500 is currently bound to any IP address. Since it is not, the gateway passes the datagram, translating only the source IP address field to show the gateway's external IP address, but without changing the source port address.

rows 5 - 16 show the six standard ISAKMP "handshaking" datagram exchanges necessary to establish SAs (Security Associations) to support fully encrypted and authenticated datagrams. Although some modes of ISAKMP use fewer exchanges, the main mode is depicted in Figure 6. Following the establishing of SAs, the local computer and the target begin communicating using ESP protocol encrypted datagrams. Here, datagram validity is maintained through the use of Security Parameter Indexing - SPI - numbers in an SPI field of the datagram's header. Each host recognizes a datagram "addressed" to its SPI, which can be modified during a session by mutual agreement of the hosts as necessary to ensure continued security. When an encrypted datagram passes through the gateway, as depicted at Figure 6, rows 17 and 18, neither the source nor the destination SPI is modified by the gateway, although the datagram's source IP address is translated to be the gateway's external IP address.

SAs Security Associations

an encrypted datagram when received by the gateway, it will be signified by a datagram of type 50 (ESP).

the gateway Upon encountering that datagram type, the gateway will check the datagram's Security Parameter Index (SPI) to see whether that SPI is recorded in its internal table. If it is, the gateway will translate the datagram's source or destination IP address, as appropriate, and will send the datagram to the LAN or the internet, depending upon the direction of transmission. However, if the SPI of a datagram from the LAN does not appear in the gateway's internal table, and the source and destination are recognized IP addresses, the gateway will assume that a new session has been started.

SPI Security Parameter Index

Figure 7 is similar to Figure 6, except that it illustrates the passage through the gateway of this invention of datagrams between three computers on a LAN, designated L-1, L-2, and L-3, and three targets on the internet having unique global IP addresses, T-1, T-2 and T-3.

a table containing the IP addresses of these devices is given.

a transmission designated "L-1 Outâ represents a transmission from local computer L-1 to the gateway.

T-1 In represents a transmission from the gateway to target T-1.

T-1 Out represents a transmission from target T-1 to the gateway, while âL-1 Inâ represents a transmission from the gateway to computer L-1.

computers L-1 and L-2 conduct "in the clear" communications with targets T-1 and T-2.

L-1 commences an ISAKMP session with T-1.

Rows 9-14 show the first three messages exchanged between L-1 and T-1 during the ISAKMP protocol.

computer L-3 commences an ISAKMP-1 message exchange with T-3.

Port 500 is bound to L-1 and is associated with the IP address of T-1, awaiting an ISAKMP-4 reply from T-1.

the datagram from L-3 cannot bind Port 500, and its source port address will be translated. As such, L-3 cannot complete the transmission that was started at row 15.

T-1's reply (ISAKMP-4) is received at the gateway and sent to L-1, and Port 500 immediately becomes available.

L-3 reattempts its ISAKMP-1 transmission at row 19, the transmission is successful.

L-3's ISAKMP-1 transmission binds Port 500 to L-3's IP address.

Port 500 is not available, and the gateway simply translates the destination port address from Port 500 to an "arbitrary" port number - in this case, "9063" - and sends the datagram to the internet, where target T-1 will not recognize it as an ISAKMP datagram.

L-1's next attempt to send its ISAKMP-5 transmission is successfully received by T-1.

T-1's reply is slow, and, at row 27, Port 500 is released from its binding to L-1, and, at rows 28-29, is immediately grabbed by L-3 for an ISAKMP-3 transmission.

Port 500 is blocked, and the datagram is ignored.

L-1 not having received a reply to its ISAKMP-5 message, retransmits it at rows 34-35, and a reply from T-1 is received at rows 36-37.

L-1 and T-1 can communicate securely, using ESP protocol at rows 38-39 and 42-43.

Rows 38-57 of Figure 7 demonstrate the gateway's handling of a variety of datagrams between a number of local computers and targets. UDP datagrams are shown at rows 40-41, ESP datagrams at rows 42-43 and 52-53, and ISAKMP datagrams at rows 44-45. While the chart of Figure 7 shows different IP addresses for each device, in practice it may occur that a number of processes will be running on the same device. The substitution of unique source ports by the gateway, and the use of SPI's to differentiate encrypted transmissions ensures that datagrams emanating from multiple processes running on a single machine will not be misdirected.

Figure 8 depicts the initiation and transfer of signals between the datagram processing circuitry 100 and the timer 110.

a signal 120 Upon the occurrence of an event requiring a port address to be bound to an IP address, a signal 120 will be sent to the timer to commence timing.

the timer Upon the expiration of the appropriate interval, the timer will send a signal 140 indicating that time has expired, in which case any port that is bound will be released.

a disabling signal 130 will be sent to the timer indicating that the timer should be reset to await the next signal to begin timing.

Landscapes

Engineering & Computer Science (AREA)

Computer Networks & Wireless Communication (AREA)

Signal Processing (AREA)

Computer Security & Cryptography (AREA)

Computer Hardware Design (AREA)

Computing Systems (AREA)

General Engineering & Computer Science (AREA)

Data Exchanges In Wide-Area Networks (AREA)

Small-Scale Networks (AREA)

Computer And Data Communications (AREA)

EP01400559A 2000-03-03 2001-03-02 Network address translation gateway Withdrawn EP1130846A3 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title US09/518,399 US7058973B1 (en) 2000-03-03 2000-03-03 Network address translation gateway for local area networks using local IP addresses and non-translatable port addresses US518399 2000-03-03

Publications (2)

Publication Number Publication Date EP1130846A2 true EP1130846A2 (en) 2001-09-05 EP1130846A3 EP1130846A3 (en) 2003-09-24

Family

ID=24063767

Family Applications (2)

Application Number Title Priority Date Filing Date EP01916265A Expired - Lifetime EP1259886B1 (en) 2000-03-03 2001-02-27 Network address translation gateway for local area networks using local ip addresses and non-translatable port addresses EP01400559A Withdrawn EP1130846A3 (en) 2000-03-03 2001-03-02 Network address translation gateway

Family Applications Before (1)

Application Number Title Priority Date Filing Date EP01916265A Expired - Lifetime EP1259886B1 (en) 2000-03-03 2001-02-27 Network address translation gateway for local area networks using local ip addresses and non-translatable port addresses

Country Status (14)

Country Link US (3) US7058973B1 (tr) EP (2) EP1259886B1 (tr) JP (2) JP4634687B2 (tr) KR (2) KR100798660B1 (tr) CN (2) CN1209712C (tr) AT (1) ATE315860T1 (tr) AU (1) AU2001243311B2 (tr) BR (1) BR0109033B1 (tr) CA (1) CA2401103C (tr) DE (1) DE60116610T2 (tr) MX (1) MXPA02008626A (tr) RU (1) RU2241252C2 (tr) TW (1) TW494301B (tr) WO (1) WO2001067258A1 (tr)

Cited By (16)

* Cited by examiner, â Cited by third party Publication number Priority date Publication date Assignee Title GB2367222A (en) * 2000-05-23 2002-03-27 Ibm Network address translation integration with IP security WO2003041268A2 (en) * 2001-11-07 2003-05-15 Intel Corporation Method and apparatus to manage address translation for secure connections WO2003107624A1 (en) * 2002-06-13 2003-12-24 Nvidia Corporation Method and apparatus for enhanced security for communication over a network GB2405300A (en) * 2002-06-13 2005-02-23 Nvidia Corp Method and apparatus for enhanced security for communication over a network GB2418821A (en) * 2002-06-13 2006-04-05 Nvidia Corp Security protocol and address translation integration WO2006072052A2 (en) 2004-12-31 2006-07-06 Anonymizer, Inc. System for protecting identity in a network environment US7107614B1 (en) 1999-01-29 2006-09-12 International Business Machines Corporation System and method for network address translation integration with IP security US7120930B2 (en) 2002-06-13 2006-10-10 Nvidia Corporation Method and apparatus for control of security protocol negotiation US7143188B2 (en) 2002-06-13 2006-11-28 Nvidia Corporation Method and apparatus for network address translation integration with internet protocol security US7191331B2 (en) 2002-06-13 2007-03-13 Nvidia Corporation Detection of support for security protocol and address translation integration US7437548B1 (en) 2002-07-11 2008-10-14 Nvidia Corporation Network level protocol negotiation and operation US7558873B1 (en) 2002-05-08 2009-07-07 Nvidia Corporation Method for compressed large send US7620070B1 (en) 2003-06-24 2009-11-17 Nvidia Corporation Packet processing with re-insertion into network interface circuitry US7913294B1 (en) 2003-06-24 2011-03-22 Nvidia Corporation Network protocol processing for filtering packets CN1756259B (zh) * 2004-09-27 2011-04-20 å½é åä¸æºå¨å ¬å¸ å ç¹ç½åè®®ç½ç»ä¸­ä½¿ç¨ç½ç»å°åç¿»è¯çæ¹æ³åç³»ç» US8108553B2 (en) * 2001-06-14 2012-01-31 Rockstar Bidco, LP Providing network address translation information

Families Citing this family (146)

* Cited by examiner, â Cited by third party Publication number Priority date Publication date Assignee Title US7058973B1 (en) * 2000-03-03 2006-06-06 Symantec Corporation Network address translation gateway for local area networks using local IP addresses and non-translatable port addresses US20050198379A1 (en) 2001-06-13 2005-09-08 Citrix Systems, Inc. Automatically reconnecting a client across reliable and persistent communication sessions US7900042B2 (en) * 2001-06-26 2011-03-01 Ncipher Corporation Limited Encrypted packet inspection US7769865B1 (en) * 2001-10-16 2010-08-03 Sprint Communications Company L.P. Configuring computer network communications in response to detected firewalls US20030079000A1 (en) * 2001-10-19 2003-04-24 Chamberlain Robert L. Methods and apparatus for configuring multiple logical networks of devices on a single physical network KR100449809B1 (ko) * 2001-12-27 2004-09-22 íêµ­ì ìíµì ì°êµ¬ì ë¤ì¤ ë³´ì ìë¹ì¤ë¥¼ ì ê³µíë ê°ì ë ìì´í¼ ê³ì¸µìììí¨í· ë³´í¸ ë°©ë² JP2003204326A (ja) 2002-01-09 2003-07-18 Nec Corp éä¿¡ã·ã¹ãã ã¨æå·å¦çæ©è½ä»ãï½ï½ï½å¶å¾¡è£ ç½®ãåã³éä¿¡å¶å¾¡ãã­ã°ã©ã KR20030062106A (ko) * 2002-01-16 2003-07-23 íêµ­ì ìíµì ì°êµ¬ì ê°ì ì¬ì¤ë§ì¼ë¡ë¶í° ë°ì´í° í¨í·ì ìì íë ë°©ë² ë° ì¥ì¹ EP1331785B1 (en) * 2002-01-23 2005-04-20 Sony International (Europe) GmbH A method for enabling the negotiation of end-to-end QoS by using the end-to-end negotiation protocol (E2ENP) JP4010830B2 (ja) * 2002-03-05 2007-11-21 å¯å£«éæ ªå¼ä¼ç¤¾ éä¿¡è£ ç½®ããã³ãããã¯ã¼ã¯ã·ã¹ãã US7243368B2 (en) * 2002-03-29 2007-07-10 Hewlett-Packard Development Company, L.P. Access control system and method for a networked computer system US7676579B2 (en) * 2002-05-13 2010-03-09 Sony Computer Entertainment America Inc. Peer to peer network communication US7243141B2 (en) * 2002-05-13 2007-07-10 Sony Computer Entertainment America, Inc. Network configuration evaluation CN100433667C (zh) * 2002-05-29 2008-11-12 åä¸ºææ¯æéå ¬å¸ ç½ç»å°åè½¬æ¢ä¸­ç§ç½ç¨æ·è®¿é®èµæºåé æ¹æ³ JP3564117B2 (ja) 2002-07-01 2004-09-08 æ ªå¼ä¼ç¤¾ãããã¡ã­ã¼ ç¡ç·ï½ï½ï½è£ ç½® KR100878764B1 (ko) * 2002-07-06 2009-01-14 ì¼ì±ì ìì£¼ìíì¬ ì¬ì©ìì ìµëª ì±ë³´ì¥ì ìí ë¬´ì ë ìì¤í  ë° ì¬ì©ìììµëª ì± ë³´ì¥ë°©ë² JP4056849B2 (ja) * 2002-08-09 2008-03-05 å¯å£«éæ ªå¼ä¼ç¤¾ ä»®æ³éåç¶²ã·ã¹ãã US6826627B2 (en) 2002-09-03 2004-11-30 Burnbag, Ltd. Data transformation architecture FR2844949B1 (fr) * 2002-09-24 2006-05-26 Radiotelephone Sfr Procede de gestion d'une configuration d'une passerelle par un utilisateur de la passerelle CZ298394B6 (cs) * 2002-10-01 2007-09-19 Anect A. S. KomunikacnÃ­ infrastruktura spolupracujÃ­cÃ­ korporace KR100479261B1 (ko) 2002-10-12 2005-03-31 íêµ­ì ìíµì ì°êµ¬ì ë¤í¸ìí¬ ì£¼ì ë³í ìììì ë°ì´í° ì ì¡ ë°©ë² ë° ì¥ì¹ TWI220344B (en) * 2002-10-23 2004-08-11 Winbond Electronics Corp Manufacture and method for accelerating network address translation US7921285B2 (en) * 2002-12-27 2011-04-05 Verizon Corporate Services Group Inc. Means of mitigating denial of service attacks on IP fragmentation in high performance IPsec gateways US7290134B2 (en) * 2002-12-31 2007-10-30 Broadcom Corporation Encapsulation mechanism for packet processing CN1311664C (zh) * 2003-03-05 2007-04-18 åä¸ºææ¯æéå ¬å¸ å¨åå¸å¼ç½ç»äº¤æ¢ç³»ç»ä¸­å®ç°çç«¯å£æç»æ¹æ³ US7634805B2 (en) * 2003-03-05 2009-12-15 Microsoft Corporation Use of network address translation for implementation of stateful routing DE10310351A1 (de) 2003-03-10 2004-09-23 Giesecke & Devrient Gmbh Laden von Mediendaten in einen tragbaren DatentrÃ¤ger CN100356743C (zh) * 2003-06-03 2007-12-19 åä¸ºææ¯æéå ¬å¸ ç½å ³å°ååç½ç»å°åè½¬æ¢å°åæ± ä¸­å°åéå çå®ç°æ¹æ³ CN1331328C (zh) * 2003-06-06 2007-08-08 åä¸ºææ¯æéå ¬å¸ ä¸ç§åºäºèº«ä»½è®¤è¯çå°åè½¬æ¢æ¹æ³ CN100356752C (zh) * 2003-06-14 2007-12-19 åä¸ºææ¯æéå ¬å¸ ä¸ç§ç½ç»å°åèµæºçå©ç¨æ¹æ³ US20050021839A1 (en) * 2003-06-23 2005-01-27 Russell Thomas C. Method and apparatus for providing a selectively isolated equipment area network for machine elements with data communication therebetween and with remote sites KR100568178B1 (ko) 2003-07-18 2006-04-05 ì¼ì±ì ìì£¼ìíì¬ ê²ì´í¸ì¨ì´ ì¥ì¹ ë° ê·¸ ì ì´ë°©ë² CN1571440A (zh) * 2003-07-25 2005-01-26 ä¸­å ´éè®¯è¡ä»½æéå ¬å¸ ä¸ç§è·¨è¶ç§ç½å®ç°å¤åªä½å¼å«çç³»ç»åæ¹æ³ JP2005051473A (ja) * 2003-07-28 2005-02-24 Sony Corp ãããã¯ã¼ã¯ç¸äºæ¥ç¶è£ ç½®åã³ãããã¯ã¼ã¯ç¸äºæ¥ç¶æ¹æ³ãååè§£æ±ºè£ ç½®ãä¸¦ã³ã«ã³ã³ãã¥ã¼ã¿ã»ãã­ã°ã©ã CN100463551C (zh) * 2003-08-14 2009-02-18 ä¸­å ´éè®¯è¡ä»½æéå ¬å¸ ä¸ç§å¨ç§»å¨éä¿¡ç³»ç»ä¸­å®ç°å å¯éä¿¡çç³»ç»åæ¹æ³ CN100359893C (zh) * 2003-08-28 2008-01-02 åä¸ºææ¯æéå ¬å¸ ä»¥ä¸»æºä»£çæ¹å¼å®ç°å°åè½¬æ¢åºç¨ç½å ³çæ¹æ³ US8687485B1 (en) * 2003-09-12 2014-04-01 Rockstar Consortium USLP Method and apparatus for providing replay protection in systems using group security associations CN1317874C (zh) * 2003-09-27 2007-05-23 è´¢å¢æ³äººèµè®¯å·¥ä¸ç­è¿ä¼ æä¾èæä¸»æºæå¡å¿«éæ¥è¯¢ç½®æ¢çç½ç»å°åç«¯å£è½¬æ¢ç½å ³å¨ä¸æ¹æ³ US7978716B2 (en) 2003-11-24 2011-07-12 Citrix Systems, Inc. Systems and methods for providing a VPN solution CN100454882C (zh) * 2003-12-19 2009-01-21 åä¸ºææ¯æéå ¬å¸ å¤ispå±åç½çåºå£éæ©æ¹æ³åè£ ç½® US7992199B1 (en) * 2003-12-31 2011-08-02 Honeywell International Inc. Method for permitting two parties to establish connectivity with both parties behind firewalls EP1562346A1 (en) * 2004-02-06 2005-08-10 Matsushita Electric Industrial Co., Ltd. Method and system for reliably disconnecting IPSec security associations US7895648B1 (en) * 2004-03-01 2011-02-22 Cisco Technology, Inc. Reliably continuing a secure connection when the address of a machine at one end of the connection changes US8186026B2 (en) * 2004-03-03 2012-05-29 Rockstar Bidco, LP Technique for maintaining secure network connections US8738159B2 (en) * 2004-03-15 2014-05-27 Siemens Industry, Inc. System and method for accessing PLC data on demand US7539858B2 (en) * 2004-04-05 2009-05-26 Nippon Telegraph And Telephone Corporation Packet encryption substituting device, method thereof, and program recording medium US7422152B2 (en) 2004-05-13 2008-09-09 Cisco Technology, Inc. Methods and devices for providing scalable RFID networks FI20045234A0 (fi) * 2004-06-21 2004-06-21 Nokia Corp Datan lÃ¤hetys viestintÃ¤jÃ¤rjestelmÃ¤ssÃ¤ US7757074B2 (en) 2004-06-30 2010-07-13 Citrix Application Networking, Llc System and method for establishing a virtual private network US8495305B2 (en) 2004-06-30 2013-07-23 Citrix Systems, Inc. Method and device for performing caching of dynamically generated objects in a data communication network US8739274B2 (en) 2004-06-30 2014-05-27 Citrix Systems, Inc. Method and device for performing integrated caching in a data communication network AU2005266943C1 (en) 2004-07-23 2011-01-06 Citrix Systems, Inc. Systems and methods for optimizing communications between network nodes AU2005266945A1 (en) 2004-07-23 2006-02-02 Citrix Systems, Inc. A method and systems for securing remote access to private networks CA2576569A1 (en) 2004-08-13 2006-02-23 Citrix Systems, Inc. A method for maintaining transaction integrity across multiple remote access servers TWI253818B (en) * 2004-10-29 2006-04-21 Benq Corp Transparent address translation methods US8458467B2 (en) * 2005-06-21 2013-06-04 Cisco Technology, Inc. Method and apparatus for adaptive application message payload content transformation in a network infrastructure element US7664879B2 (en) 2004-11-23 2010-02-16 Cisco Technology, Inc. Caching content and state data at a network element US7987272B2 (en) 2004-12-06 2011-07-26 Cisco Technology, Inc. Performing message payload processing functions in a network element on behalf of an application US7725934B2 (en) 2004-12-07 2010-05-25 Cisco Technology, Inc. Network and application attack protection based on application layer message inspection US8082304B2 (en) * 2004-12-10 2011-12-20 Cisco Technology, Inc. Guaranteed delivery of application layer messages by a network element US8706877B2 (en) 2004-12-30 2014-04-22 Citrix Systems, Inc. Systems and methods for providing client-side dynamic redirection to bypass an intermediary US8954595B2 (en) 2004-12-30 2015-02-10 Citrix Systems, Inc. Systems and methods for providing client-side accelerated access to remote applications via TCP buffering US8700695B2 (en) 2004-12-30 2014-04-15 Citrix Systems, Inc. Systems and methods for providing client-side accelerated access to remote applications via TCP pooling US8549149B2 (en) 2004-12-30 2013-10-01 Citrix Systems, Inc. Systems and methods for providing client-side accelerated access to remote applications via TCP multiplexing US7810089B2 (en) 2004-12-30 2010-10-05 Citrix Systems, Inc. Systems and methods for automatic installation and execution of a client-side acceleration program US8255456B2 (en) 2005-12-30 2012-08-28 Citrix Systems, Inc. System and method for performing flash caching of dynamically generated objects in a data communication network KR20070104566A (ko) 2005-01-24 2007-10-26 ì¬ì´í¸ë¦­ì¤ ìì¤í ì¤, ì¸í¬. ë¤í¸ìí¬ìì ëì ì¼ë¡ ë°ìë ê°ì²´ë¤ì ìºì±ì ìííëìì¤í  ë° ë°©ë² CN100414929C (zh) * 2005-03-15 2008-08-27 åä¸ºææ¯æéå ¬å¸ ä¸ç§ç§»å¨äºèç½åè®®ç½ç»ä¸­çæ¥æä¼ éæ¹æ³ US7703124B2 (en) * 2005-03-31 2010-04-20 Hewlett-Packard Development Company, L.P. System and method for implementing a private virtual backbone on a common network infrastructure JP4768324B2 (ja) * 2005-06-07 2011-09-07 æ ªå¼ä¼ç¤¾æ±è ç¡ç·éä¿¡æ©å¨ US8266327B2 (en) * 2005-06-21 2012-09-11 Cisco Technology, Inc. Identity brokering in a network element ATE438856T1 (de) * 2005-06-22 2009-08-15 Univ Johns Hopkins Biomarker fÃ¼r eierstockkrebs: mit ctap3 verwandte proteine IES20050439A2 (en) * 2005-06-30 2006-08-09 Asavie R & D Ltd A method of network communication KR100799575B1 (ko) * 2005-12-07 2008-01-30 íêµ­ì ìíµì ì°êµ¬ì ï¼©ï¼°ï½ï¼ ë¤í¸ìí¬ìì ì´ëë ¸ëìê² ï¼¶ï¼°ï¼® ìë¹ì¤ë¥¼ì ê³µíë ë°©ë² ë° ì´ë¥¼ ìí ê²ì´í¸ì¨ì´ US7345585B2 (en) 2005-08-01 2008-03-18 Cisco Technology, Inc. Network based device for providing RFID middleware functionality US7672289B2 (en) * 2005-08-09 2010-03-02 Mitsubishi Electric Research Laboratories, Inc. Method for defining, allocating and assigning addresses in ad hoc wireless networks US20070079366A1 (en) * 2005-10-03 2007-04-05 Microsoft Corporation Stateless bi-directional proxy US20070088815A1 (en) * 2005-10-13 2007-04-19 Kenneth Ma Automated setup and test confirmation of dynamic DNS service CN100477671C (zh) * 2005-12-16 2009-04-08 ä¸­å½ç§å­¦é¢è®¡ç®ææ¯ç ç©¶æ Patæ¨¡å¼ä¸æ¯æå¤ä¼è¯åºç¨å±åè®®çç½ç»å°åè½¬æ¢æ¹æ³ US8301839B2 (en) 2005-12-30 2012-10-30 Citrix Systems, Inc. System and method for performing granular invalidation of cached dynamically generated objects in a data communication network US7921184B2 (en) 2005-12-30 2011-04-05 Citrix Systems, Inc. System and method for performing flash crowd caching of dynamically generated objects in a data communication network CN101047711B (zh) * 2006-04-27 2010-08-18 åä¸ºææ¯æéå ¬å¸ Ipæ¥æä¼ è¾ãååå¸¦å®½èçè½ååèçç½ç»å¸¦å®½çæ¹æ³ US7797406B2 (en) * 2006-07-27 2010-09-14 Cisco Technology, Inc. Applying quality of service to application messages in network elements based on roles and status US7539189B2 (en) * 2006-08-01 2009-05-26 Cisco Technology, Inc. Apparatus and methods for supporting 802.1X in daisy chained devices US8079077B2 (en) 2006-08-08 2011-12-13 A10 Networks, Inc. System and method for distributed multi-processing security gateway CN101155183B (zh) * 2006-09-29 2012-02-08 æ¾ä¸çµå¨äº§ä¸æ ªå¼ä¼ç¤¾ å¤çå·¢ç¶ç½é ç½ç»å®å ¨åè®®ä¿¡éçæ¹æ³åç½ç»è£ ç½® JP4708297B2 (ja) * 2006-09-29 2011-06-22 å¯å£«éãã¬ã³ã ãããã¯ã¼ã¯ã¹æ ªå¼ä¼ç¤¾ ï¼©ï¼°ï½ï½ ï½ã®è¤æ°ã»ãã·ã§ã³ãå¦çããéä¿¡è£ ç½® US8095786B1 (en) * 2006-11-09 2012-01-10 Juniper Networks, Inc. Application-specific network-layer virtual private network connections CN100525251C (zh) * 2006-11-30 2009-08-05 ä¸­å½ç§å­¦é¢è®¡ç®ææ¯ç ç©¶æ ä¸ç§ç½ç»å°åè½¬æ¢æ¹æ³ CN101072102B (zh) * 2007-03-23 2010-10-06 åäº¬èåç§æéå¢è¡ä»½æéå ¬å¸ ç½ç»ç¯å¢ä¸åºäºå®å ¨æ¡é¢çä¿¡æ¯é²æ³æ¼ææ¯ US8621552B1 (en) * 2007-05-22 2013-12-31 Skybox Security Inc. Method, a system, and a computer program product for managing access change assurance US7729366B2 (en) * 2007-10-03 2010-06-01 General Instrument Corporation Method, apparatus and system for network mobility of a mobile communication device CN101227494B (zh) * 2008-01-09 2013-06-12 ä¸­å ´éè®¯è¡ä»½æéå ¬å¸ æ¥å ¥å¤åç»æ°æ®ç½æ¶å ç¹ç½å®å ¨åè®®å®å ¨èççå»ºç«æ¹æ³ US7817636B2 (en) * 2008-01-30 2010-10-19 Cisco Technology, Inc. Obtaining information on forwarding decisions for a packet flow KR20090092503A (ko) * 2008-02-27 2009-09-01 ì£¼ìíì¬ í´ì»¤ë¥ì¤ íëì ìì´í¼ ì£¼ìë¡ ë³µìì ìì´í¼ ì¥ë¹ë¤ì ì§ìí ììë ë©í°í¬í¸ ì¥ì¹ GB2478470B8 (en) 2008-11-17 2014-05-21 Sierra Wireless Inc Method and apparatus for network port and netword address translation US8924486B2 (en) * 2009-02-12 2014-12-30 Sierra Wireless, Inc. Method and system for aggregating communications US8228848B2 (en) * 2008-11-17 2012-07-24 Sierra Wireless, Inc. Method and apparatus for facilitating push communication across a network boundary US20100235689A1 (en) * 2009-03-16 2010-09-16 Qualcomm Incorporated Apparatus and method for employing codes for telecommunications US8874785B2 (en) * 2010-02-15 2014-10-28 Damaka, Inc. System and method for signaling and data tunneling in a peer-to-peer environment US8356087B1 (en) * 2010-08-24 2013-01-15 Amazon Technologies, Inc. Automatically configuring virtual private networks US20120269059A1 (en) * 2010-10-19 2012-10-25 Qualcomm Incorporated Methods and apparatus for contemporaneously providing quality of service functionality and local ip access US9143480B2 (en) * 2011-01-10 2015-09-22 Secure Global Solutions, Llc Encrypted VPN connection US9258271B1 (en) * 2011-01-13 2016-02-09 Google Inc. Network address translation for virtual machines WO2012106820A1 (en) 2011-02-08 2012-08-16 Sierra Wireless, Inc. Method and system for forwarding data between network devices CN103299284B (zh) * 2011-04-29 2016-01-20 ä¸­å¤©å®æ³°ï¼åäº¬ï¼ä¿¡æ¯ææ¯æéå ¬å¸ æ°æ®å®å ¨è¯»åæ¹æ³åè£ ç½® US8838735B2 (en) 2011-06-28 2014-09-16 At&T Intellectual Property I, L.P. Methods, systems, and products for address translation in residential networks US8621038B2 (en) 2011-09-27 2013-12-31 Cloudflare, Inc. Incompatible network gateway provisioned through DNS US8438240B2 (en) * 2011-09-27 2013-05-07 Cloudflare, Inc. Distributing transmission of requests across multiple IP addresses of a proxy server in a cloud-based proxy service US9258272B1 (en) * 2011-10-21 2016-02-09 Juniper Networks, Inc. Stateless deterministic network address translation US9178846B1 (en) 2011-11-04 2015-11-03 Juniper Networks, Inc. Deterministic network address and port translation KR20130052240A (ko) * 2011-11-11 2013-05-22 ì¼ì±ì ìì£¼ìíì¬ ë¤í¸ìí¬ ì£¼ì ë³íê¸° íµê³¼ ê¸°ë²ì íë¡ë¹ì ëíê¸° ìí ë°©ë² ë° ì¥ì¹ CN103139189B (zh) * 2011-12-05 2017-03-22 äº¬ä¿¡éä¿¡ç³»ç»ï¼ä¸­å½ï¼æéå ¬å¸ ä¸ç§IPSecé§éå ±ç¨æ¹æ³ãç³»ç»åè®¾å¤ US9118618B2 (en) 2012-03-29 2015-08-25 A10 Networks, Inc. Hardware-based packet editor US8891540B2 (en) 2012-05-14 2014-11-18 Juniper Networks, Inc. Inline network address translation within a mobile gateway router US9596286B2 (en) 2012-05-25 2017-03-14 A10 Networks, Inc. Method to process HTTP header with hardware assistance KR101692751B1 (ko) 2012-09-25 2017-01-04 ìì´10 ë¤í¸ìí¬ì¤, ì¸ì½í¬ë ì´í°ë ë°ì´í°ë§ ë¶í ë¶ì° US10021174B2 (en) 2012-09-25 2018-07-10 A10 Networks, Inc. Distributing service sessions US10027761B2 (en) 2013-05-03 2018-07-17 A10 Networks, Inc. Facilitating a secure 3 party network session by a network device US20160255539A1 (en) * 2013-10-09 2016-09-01 Nec Corporation Communication system, communication apparatus and communication control method CN103797774B (zh) * 2013-11-05 2017-07-21 åä¸ºææ¯æéå ¬å¸ ä¸ç§ç½ç»å°åè½¬æ¢è®¾å¤åæ¹æ³ CN103607403A (zh) * 2013-11-26 2014-02-26 åäº¬æç½éæ·ç½ç»ææ¯æéå ¬å¸ ä¸ç§natç½ç»ç¯å¢ä¸ä½¿ç¨å®å ¨åçæ¹æ³ãè£ ç½®åç³»ç» KR102282548B1 (ko) * 2014-02-06 2021-07-29 ì´^ììì´í° í í¬ëë¡ì§ì¤ ììì¨ ë¤ì¤ ë³´ì ë§í¬ ìí¤í ì²ë¥¼ ì ê³µíë ìì¤í  ë° ë°©ë² CN103942499B (zh) * 2014-03-04 2017-01-11 ä¸­å¤©å®æ³°ï¼åäº¬ï¼ä¿¡æ¯ææ¯æéå ¬å¸ åºäºç§»å¨å­å¨å¨çæ°æ®é»æ´å¤çæ¹æ³åç§»å¨å­å¨å¨ US10020979B1 (en) 2014-03-25 2018-07-10 A10 Networks, Inc. Allocating resources in multi-core computing environments US9806943B2 (en) 2014-04-24 2017-10-31 A10 Networks, Inc. Enabling planned upgrade/downgrade of network devices without impacting network sessions US9525627B2 (en) 2014-05-27 2016-12-20 Google Inc. Network packet encapsulation and routing US10129207B1 (en) 2015-07-20 2018-11-13 Juniper Networks, Inc. Network address translation within network device having multiple service units EP3286954B1 (en) * 2015-08-21 2019-04-17 Telefonaktiebolaget LM Ericsson (publ) Communication of non-ip data over packet data networks US10038672B1 (en) * 2016-03-29 2018-07-31 EMC IP Holding Company LLC Virtual private network sessions generation CN106330653A (zh) * 2016-08-30 2017-01-11 æé½æç©ç½ç»ææ¯æéå ¬å¸ åºäºè½»éçº§å®å ¨èæä¸ç¨ç½çæºè½åæµç½å ³ US10469446B1 (en) 2016-09-27 2019-11-05 Juniper Networks, Inc. Subscriber-aware network address translation JP2018067248A (ja) * 2016-10-21 2018-04-26 å¯å£«éæ ªå¼ä¼ç¤¾ å¶å¾¡ãã­ã°ã©ã ãå¶å¾¡æ¹æ³ãåã³æ å ±å¦çè£ ç½® KR101920190B1 (ko) * 2016-11-22 2019-02-08 íêµ­ì¸í°ë·ì§í¥ì ììì ip ìì± ë°©ë² ë° ê·¸ ì¥ì¹ US10594829B2 (en) * 2017-05-24 2020-03-17 At&T Intellectual Property I, L.P. Cloud workload proxy as link-local service configured to access a service proxy gateway via a link-local IP address to communicate with an external target service via a private network US10565062B1 (en) * 2017-08-03 2020-02-18 Veritas Technologies Llc Systems and methods for managing replication of data to a remote storage device CN107547690B (zh) * 2017-09-25 2021-06-18 æ°åä¸ä¿¡æ¯å®å ¨ææ¯æéå ¬å¸ Natä¸­çç«¯å£åé æ¹æ³ãè£ ç½®ãnatè®¾å¤åå­å¨ä»è´¨ CN107943438A (zh) * 2017-12-21 2018-04-20 å½ç½æ²³åççµåæéå ¬å¸è¡¡æ°´ä¾çµåå ¬å¸ æ äººå¼å®åçµç«çåå ¬ä¼åæ¹æ³ US10791091B1 (en) * 2018-02-13 2020-09-29 Architecture Technology Corporation High assurance unified network switch CN110858229B (zh) 2018-08-23 2023-04-07 é¿éå·´å·´éå¢æ§è¡æéå ¬å¸ æ°æ®å¤çæ¹æ³ãè®¾å¤ãè®¿é®æ§å¶ç³»ç»åå­å¨ä»è´¨ CN109152096B (zh) * 2018-09-27 2020-09-25 å®ç§è®¯(ç¦å»º)ç§ææéå ¬å¸ Epsæ¶æçæ¥æä¼ è¾æ¹æ³åè®¡ç®æºå¯è¯»å­å¨ä»è´¨ CN110138748B (zh) * 2019-04-23 2020-10-23 åäº¬äº¤éå¤§å­¦ ä¸ç§ç½ç»èåéä¿¡æ¹æ³ãç½å ³è®¾å¤åç³»ç» JP7309443B2 (ja) * 2019-05-14 2023-07-18 ã­ã¤ãã³æ ªå¼ä¼ç¤¾ å°å·è£ ç½®ãå¶å¾¡æ¹æ³åã³ãã­ã°ã©ã CN112671939B (zh) * 2020-08-17 2022-07-05 ç´«å äºææ¯æéå ¬å¸ ä¸ç§åºånatå é¤ånatè§£ç»å¼¹æ§å ¬ç½ipçæ¹æ³ US11394686B1 (en) * 2021-02-25 2022-07-19 Nvidia Corporation Dynamic network address translation using prediction CN113794788B (zh) * 2021-09-14 2023-07-25 åäº¬ç¾åº¦ç½è®¯ç§ææéå ¬å¸ ç½å ³å¯¼æµæ¹æ³ãç³»ç»ãè£ ç½®ãè®¾å¤ãå­å¨ä»è´¨åäº§å

Citations (2)

* Cited by examiner, â Cited by third party Publication number Priority date Publication date Assignee Title WO1997040610A2 (en) * 1996-04-24 1997-10-30 Northern Telecom Limited Internet protocol filter WO1999035799A2 (en) * 1997-12-31 1999-07-15 Ssh Communications Security Oy A method for packet authentication in the presence of network address translations and protocol conversions

Family Cites Families (18)

* Cited by examiner, â Cited by third party Publication number Priority date Publication date Assignee Title US4727370A (en) * 1985-12-17 1988-02-23 Ampex Corporation Method and system for synchronous handshake generation US5577209A (en) 1991-07-11 1996-11-19 Itt Corporation Apparatus and method for providing multi-level security for communication among computers and terminals on a network AU1829897A (en) 1996-01-16 1997-08-11 Raptor Systems, Inc. Transferring encrypted packets over a public network AU1748797A (en) * 1996-01-16 1997-08-11 Raptor Systems, Inc. Key management for network communication US5781550A (en) * 1996-02-02 1998-07-14 Digital Equipment Corporation Transparent and secure network gateway US5983350A (en) * 1996-09-18 1999-11-09 Secure Computing Corporation Secure firewall supporting different levels of authentication based on address or encryption status US6353614B1 (en) * 1998-03-05 2002-03-05 3Com Corporation Method and protocol for distributed network address translation US7032242B1 (en) * 1998-03-05 2006-04-18 3Com Corporation Method and system for distributed network address translation with network security features US6055236A (en) * 1998-03-05 2000-04-25 3Com Corporation Method and system for locating network services with distributed network address translation US6006259A (en) 1998-11-20 1999-12-21 Network Alchemy, Inc. Method and apparatus for an internet protocol (IP) network clustering system US6691168B1 (en) * 1998-12-31 2004-02-10 Pmc-Sierra Method and apparatus for high-speed network rule processing US6330562B1 (en) * 1999-01-29 2001-12-11 International Business Machines Corporation System and method for managing security objects US6615357B1 (en) * 1999-01-29 2003-09-02 International Business Machines Corporation System and method for network address translation integration with IP security US6449251B1 (en) * 1999-04-02 2002-09-10 Nortel Networks Limited Packet mapper for dynamic data packet prioritization US6957346B1 (en) * 1999-06-15 2005-10-18 Ssh Communications Security Ltd. Method and arrangement for providing security through network address translations using tunneling and compensations US6347376B1 (en) * 1999-08-12 2002-02-12 International Business Machines Corp. Security rule database searching in a network security environment US7058973B1 (en) * 2000-03-03 2006-06-06 Symantec Corporation Network address translation gateway for local area networks using local IP addresses and non-translatable port addresses JP3597756B2 (ja) * 2000-06-09 2004-12-08 æ¥æ¬é»ä¿¡é»è©±æ ªå¼ä¼ç¤¾ ãããã¯ã¼ã¯ã¢ãã¬ã¹å¤æè£ ç½®ããã³ï½ï½ï½ã¯ã©ã¤ã¢ã³ãå¤éåã·ã¹ãã

2000

2000-03-03 US US09/518,399 patent/US7058973B1/en not_active Expired - Lifetime

2000-11-23 TW TW089124867A patent/TW494301B/zh not_active IP Right Cessation

2001

2001-02-27 JP JP2001565007A patent/JP4634687B2/ja not_active Expired - Fee Related

2001-02-27 AT AT01916265T patent/ATE315860T1/de not_active IP Right Cessation

2001-02-27 KR KR1020027011455A patent/KR100798660B1/ko not_active IP Right Cessation

2001-02-27 MX MXPA02008626A patent/MXPA02008626A/es active IP Right Grant

2001-02-27 WO PCT/US2001/006257 patent/WO2001067258A1/en active IP Right Grant

2001-02-27 EP EP01916265A patent/EP1259886B1/en not_active Expired - Lifetime

2001-02-27 BR BRPI0109033-0A patent/BR0109033B1/pt not_active IP Right Cessation

2001-02-27 DE DE60116610T patent/DE60116610T2/de not_active Expired - Lifetime

2001-02-27 RU RU2002126235/09A patent/RU2241252C2/ru not_active IP Right Cessation

2001-02-27 AU AU2001243311A patent/AU2001243311B2/en not_active Ceased

2001-02-27 CN CNB018059384A patent/CN1209712C/zh not_active Expired - Lifetime

2001-02-27 CA CA002401103A patent/CA2401103C/en not_active Expired - Lifetime

2001-03-02 EP EP01400559A patent/EP1130846A3/en not_active Withdrawn

2001-03-02 CN CN01117340A patent/CN1332552A/zh active Pending

2001-03-03 KR KR1020010011042A patent/KR20010087322A/ko not_active Application Discontinuation

2001-03-05 JP JP2001059821A patent/JP2001313679A/ja active Pending

2006

2006-04-17 US US11/405,222 patent/US7581247B2/en not_active Expired - Fee Related

2008

2008-11-12 US US12/269,173 patent/US8165140B2/en not_active Expired - Fee Related

Patent Citations (2)

* Cited by examiner, â Cited by third party Publication number Priority date Publication date Assignee Title WO1997040610A2 (en) * 1996-04-24 1997-10-30 Northern Telecom Limited Internet protocol filter WO1999035799A2 (en) * 1997-12-31 1999-07-15 Ssh Communications Security Oy A method for packet authentication in the presence of network address translations and protocol conversions

Non-Patent Citations (3)

* Cited by examiner, â Cited by third party Title D SENIE: "NAT Friendly Application Design Guidelines (draft-ietf-nat-app-guide-02.txt)" INTERNET ARTICLE, [Online] September 1999 (1999-09), page 1-8 XP002248278 IETF NAT Working Group Retrieved from the Internet: <URL:http://www.ietf.org/proceedings/99nov /I-D/draft-ietf-nat-app-guide-02.txt> [retrieved on 2003-07-18] * G MONTENEGRO: "Negotiated Address Reuse (NAR) (draft-montenegro-aatn-nar-01.txt)" INTERNET ARTICLE, [Online] 18 January 1999 (1999-01-18), pages 1-23, XP002248277 IETF Retrieved from the Internet: <URL:http://www.watersprings.org/pub/id/dr aft-montenegro-aatn-nar-01.txt> [retrieved on 2003-07-18] * M BORELLA: "RSIP Support for End-to-end IPsec (draft-ietf-nat-rsip-ipsec-02.txt)" INTERNET ARTICLE, [Online] February 2000 (2000-02), pages 1-19, XP002248276 IETF Retrieved from the Internet: <URL:http://www.watersprings.org/pub/id/dr aft-ietf-nat-rsip-ipsec-02.txt> [retrieved on 2003-07-18] *

Cited By (28)

* Cited by examiner, â Cited by third party Publication number Priority date Publication date Assignee Title US7107614B1 (en) 1999-01-29 2006-09-12 International Business Machines Corporation System and method for network address translation integration with IP security GB2367222B (en) * 2000-05-23 2004-01-14 Ibm System and method for network address translation integration with IP security GB2367222A (en) * 2000-05-23 2002-03-27 Ibm Network address translation integration with IP security US8484359B2 (en) 2001-06-14 2013-07-09 Rockstar Consortium Us Lp Providing telephony services to terminals behind a firewall and/or a network address translator US8244876B2 (en) 2001-06-14 2012-08-14 Rockstar Bidco, LP Providing telephony services to terminals behind a firewall and/or a network address translator US8108553B2 (en) * 2001-06-14 2012-01-31 Rockstar Bidco, LP Providing network address translation information WO2003041268A2 (en) * 2001-11-07 2003-05-15 Intel Corporation Method and apparatus to manage address translation for secure connections WO2003041268A3 (en) * 2001-11-07 2004-01-29 Intel Corp Method and apparatus to manage address translation for secure connections US7159109B2 (en) 2001-11-07 2007-01-02 Intel Corporation Method and apparatus to manage address translation for secure connections US7558873B1 (en) 2002-05-08 2009-07-07 Nvidia Corporation Method for compressed large send US7143137B2 (en) 2002-06-13 2006-11-28 Nvidia Corporation Method and apparatus for security protocol and address translation integration GB2413248A (en) * 2002-06-13 2005-10-19 Nvidia Corp Security protocol and address translation integration GB2405300B (en) * 2002-06-13 2006-07-12 Nvidia Corp Method and apparatus for enhanced security for communication over a network US7120930B2 (en) 2002-06-13 2006-10-10 Nvidia Corporation Method and apparatus for control of security protocol negotiation WO2003107624A1 (en) * 2002-06-13 2003-12-24 Nvidia Corporation Method and apparatus for enhanced security for communication over a network US7143188B2 (en) 2002-06-13 2006-11-28 Nvidia Corporation Method and apparatus for network address translation integration with internet protocol security GB2413248B (en) * 2002-06-13 2006-06-21 Nvidia Corp Method and apparatus for enhanced security for communication over a network US7191331B2 (en) 2002-06-13 2007-03-13 Nvidia Corporation Detection of support for security protocol and address translation integration GB2405300A (en) * 2002-06-13 2005-02-23 Nvidia Corp Method and apparatus for enhanced security for communication over a network GB2418821B (en) * 2002-06-13 2006-08-09 Nvidia Corp Method and apparatus for enhanced security for communication over a network GB2418821A (en) * 2002-06-13 2006-04-05 Nvidia Corp Security protocol and address translation integration US7437548B1 (en) 2002-07-11 2008-10-14 Nvidia Corporation Network level protocol negotiation and operation US7913294B1 (en) 2003-06-24 2011-03-22 Nvidia Corporation Network protocol processing for filtering packets US7620070B1 (en) 2003-06-24 2009-11-17 Nvidia Corporation Packet processing with re-insertion into network interface circuitry CN1756259B (zh) * 2004-09-27 2011-04-20 å½é åä¸æºå¨å ¬å¸ å ç¹ç½åè®®ç½ç»ä¸­ä½¿ç¨ç½ç»å°åç¿»è¯çæ¹æ³åç³»ç» EP1859354A2 (en) * 2004-12-31 2007-11-28 Anonymizer, Inc. System for protecting identity in a network environment WO2006072052A2 (en) 2004-12-31 2006-07-06 Anonymizer, Inc. System for protecting identity in a network environment EP1859354A4 (en) * 2004-12-31 2013-08-21 Ntrepid Corp SYSTEM FOR IDENTITY PROTECTION IN A NETWORK ENVIRONMENT

Also Published As

Publication number Publication date US8165140B2 (en) 2012-04-24 EP1130846A3 (en) 2003-09-24 CN1332552A (zh) 2002-01-23 JP2001313679A (ja) 2001-11-09 EP1259886A1 (en) 2002-11-27 RU2241252C2 (ru) 2004-11-27 EP1259886B1 (en) 2006-01-11 AU4331101A (en) 2001-09-17 KR100798660B1 (ko) 2008-01-28 KR20020079979A (ko) 2002-10-21 TW494301B (en) 2002-07-11 DE60116610D1 (de) 2006-04-06 RU2002126235A (ru) 2004-03-27 ATE315860T1 (de) 2006-02-15 DE60116610T2 (de) 2006-11-23 CN1209712C (zh) 2005-07-06 EP1259886A4 (en) 2004-04-28 CN1408088A (zh) 2003-04-02 CA2401103C (en) 2007-04-10 US7058973B1 (en) 2006-06-06 KR20010087322A (ko) 2001-09-15 JP4634687B2 (ja) 2011-02-16 WO2001067258A1 (en) 2001-09-13 US20090059940A1 (en) 2009-03-05 CA2401103A1 (en) 2001-09-13 BR0109033B1 (pt) 2015-03-10 BR0109033A (pt) 2003-06-03 MXPA02008626A (es) 2003-02-24 US20060185010A1 (en) 2006-08-17 AU2001243311B2 (en) 2003-12-18 US7581247B2 (en) 2009-08-25 JP2003526270A (ja) 2003-09-02

Similar Documents

Publication Publication Date Title EP1259886B1 (en) 2006-01-11 Network address translation gateway for local area networks using local ip addresses and non-translatable port addresses Patel et al. 2001 Securing L2TP using IPsec EP1872561B1 (en) 2012-11-07 Preventing duplicate sources from clients served by a network address port translator (napt) US8787393B2 (en) 2014-07-22 Preventing duplicate sources from clients served by a network address port translator US20020069356A1 (en) 2002-06-06 Integrated security gateway apparatus US20020042875A1 (en) 2002-04-11 Method and apparatus for end-to-end secure data communication US20120117376A1 (en) 2012-05-10 Method and apparatus for anonymous ip datagram exchange using dynamic newtork address translation US20230379390A1 (en) 2023-11-23 Session-based remote direct memory access Patel et al. 2001 RFC3193: Securing L2TP using IPsec Zorn et al. 2001 Network Working Group B. Patel Request for Comments: 3193 Intel Category: Standards Track B. Aboba W. Dixon Microsoft Schmitt 2006 Host Identity Protocol Extensions for the Traversal of Network Address Translators

Legal Events

Date Code Title Description