BRPI0607516B1 - METHOD TO PREVENT DUPLICATE SOURCES IN A NETWORK PROTOCOL - Google Patents

Abstract

Preventing duplicate sources in a network that uses network address port translation on an established connection. In response to receiving an inbound packet at a destination host, input values are obtained therefrom and used to consult a mapping. If no match is found, a translation is performed, whereby a determination is made as to whether or not a port number is available within a range of port numbers that comply with a security association governing the connection. If so, an available port number is assigned to the connection, thereby avoiding a possibility of a duplicate source. If a port number is not available, the packet is rejected.

Description

“METHOD TO PREVENT DUPLICATE SOURCES IN A NETWORK PROTOCOL

Technical field

[001] The invention generally refers to the Internet network and specifically to the handling of conflicts caused by the network address and the translation of ports.

Background of the Invention

[002] The problems and solutions described here are described in terms of the Internet and the TCP / IP protocols that form the basis of Internet communications. However, the techniques can also apply to other communication protocols, depending on the specifics of the protocols.

[003] Internet network address translation is used for several reasons. The main reason is to save on the use of public addresses. The IP address (Internet Protocol) of a Network Address Translator (NAT) is usually a public address. In other words, the NAT IP address is known in the outside world, while all servers or clients behind NAT are private addresses, unknown to the outside world. In this case, the outside world communicates with NAT and NAT controls communications with the appropriate servers and clients behind it. This means that the IP addresses of the devices behind NAT need only be unique within this family, but can be duplicated from other IP addresses in the rest of the world. NATs only involve translating IP addresses. There is another type of translation known as NAPT (Network Address Port Translation), in which IP addresses and port numbers are translated. Standards for network address translation (NAT) and

Petition 870190106009, of 10/20/2019, p. 9/28

2/19 Network Address Port Translation (NAPT) are set out in IETF RFC 3022 (F), entitled Traditional IP Network Address Translation.

[004] The original Internet was not safely designed as a primary factor. In fact, the Internet was purposely made relatively open as an aid to scientific and educational communication. However, the advent of the Web and its commercial uses has increased the need for secure communications on the Internet. The Internet Security Protocol, known as IPsec, has been defined to address these problems. For example, IPsec provides authentication for network devices and / or encryption of transmitted data. An IPsec communication between the source and destination addresses is managed according to a security association (SA), which is one or more rules that define the IPsec processing applied to the communication. IPsec is defined in RFC 2401 and other RFCs. Whether a packet is denied, allowed without IPsec processing or allowed with IPsec processing is determined by matching the attributes of a packet to the security rules in a security policy database ( SPD). To make this determination, the known technique searches for static and dynamic rules in order from the most specific attributes to the least specific attributes for outgoing and incoming packets. A set of static rules is essentially a security policy. Static rules are predefined and generally don't change very often.

[005] Dynamic rules are rules negotiated between

Petition 870190106009, of 10/20/2019, p. 10/28

3/19 nodes during IKE (Internet Key Exchange) processing and dynamically added to the security policy database as needed. US Patent 6,347,376 to International Business Machines describes a preferred method for researching the static and dynamic rules of an SPD. This patent is hereby incorporated by reference in its entirety.

[006] There are inherent incompatibilities between the network address or port translation and IPsec processing. These incompatibilities are a barrier to the deployment of IPsec. RFC 3715 recognizes and discusses some of these incompatibilities, but does not offer general solutions. For example, Section 4.1 of RFC 3715 refers to a limited solution proposed in RFC 3456, Dynamic Host Configuration Protocol (DHCPv4, IPsec Tunnel Mode Configuration), but states that a more general solution is needed. In addition, Section 5 of RFC 3948, entitled UDP Encapsulation of IPsec ESP Packets from the IETF IPsec Working Group, also addresses some of the incompatibility issues. In particular, Section 5.2 of the RFC briefly describes an issue in determining which IPsec security associations should be used when connecting to clients served by a NAT. This section also describes another problem with allowing a clear text connection to a client behind a NAPT when NAPT also handles IPsec traffic.

[007] Therefore, it is necessary to solve the problem of avoiding duplicate sources when customers are served by a NAPT. No solution is provided for this problem

Petition 870190106009, of 10/20/2019, p. 11/28

4/19 for any of the related IETF IFC documents. For the purposes of this specification, duplicate fonts are defined as packets with the same source address (for example, an IP address of a NAPT assigned to an original packet encapsulated in IPsec), the same transport protocol and the same port number. original source (that is, a port number in the transport header of the IPsec encapsulated packet).

[008] Duplicate origins result in duplicate connections that promote network integrity. For example, packages can be sent to the wrong destination.

[009] RFC 3947, entitled NATTraversal Negotiation in IKE describes what is required in phases 1 and 2 of IKE (Internet Key Exchange) to support NAT traversal. This includes detecting whether the two ends in a packet communication support NAT traversal and detecting whether there are one or more NATs in the path from host to host. It also discusses how to negotiate the use of IPsec packets encapsulated in User Datagram Protocol (UDP) protocol in IKE Quick Mode and describes how to transmit an original source IP address to the other end, if necessary. UDP is defined in RFC 768. RFC 3948, UDP Encapsulation of ESP IPsec packets, defines methods for encapsulating and decapsulating ESP (security encapsulation payload) packets within UDP packets for the purpose of traversing NATs. ESP is defined in RFC 2406. ESP is designed to provide a combination of security services over IPv4 and IPv6.

Summary of the invention

Petition 870190106009, of 10/20/2019, p. 12/28

5/19

[0010] The present invention therefore provides the prevention of duplicate sources of packets on connections that use source addresses, protocols and source port numbers to identify source applications that are served by a NAPT. When a packet is received on a server, it is determined whether the packet is a UDP packet that encapsulates an ESP packet whose transmission path contains a NAPT (network address port translator). In this case, the original packet is decapsulated to obtain an original source port and an original transport protocol. A source port mapping table (SPMT) is searched for an association between the NAPT source IP address, the original source port number and the original transport protocol associated with the NAPT source IP address and the converted source port. If an incorrect association is found, the package will be rejected for representing an illegal duplicate source; that is, a second packet from a different host served by a NAPT that has the same source IP address, source port number and protocol.

[0011] In the preferred mode, the host entries of the Network Address Port Translator (NAPT) in SPMT on the server are dynamically constructed in response to IKE (Internet Key Exchange) messages from Internet hosts. Each NAPT host entry contains the NAPT source IP address and a source port assigned by NAPT. Source port entries in SPMT are built dynamically as encrypted packets arrive and are decrypted and associations are established

Petition 870190106009, of 10/20/2019, p. 13/28

6/19 between the source port entries and the SPMT NAPT host entries. Each source port entry contains an NAPT source IP address, an original source port number, and an original protocol.

Brief description of the drawings

[0012] A preferred embodiment of the present invention will now be described by way of example only with reference to the following drawings in which:

Fig. 1 shows a packet that progresses from a client, through a NAPT to a destination host and changes to the packet headers and contents as the packet progresses;

Fig. 2 shows a return package responsive to the package in Fig. 1;

Fig. 3 shows an illustrative modality of the Source Port Mapping Table (SPMT);

Fig. 4 shows a packet translated by NAPT that encapsulates an original encrypted packet;

Fig. 5 shows the package of figure 4 after decryption;

Figs. 6 and 7 correspond to Figs. 4 and 5, respectively, and show a second packet on the same path as the previous packet that represents an illegal duplicate source caused by the inclusion of a NAPT in the transmission path;

Fig. 8 is a flowchart of creating NAPT host entries in SPMT;

Fig. 9 is a flow chart showing the options available when an incoming package arrives first

Petition 870190106009, of 10/20/2019, p. 14/28

7/19 to a destination host;

Fig. 10 is a flowchart showing the processing of an incoming packet that encapsulates an original encrypted packet and has passed through a NAPT; and

Figs. 11 and 12 are flowcharts that show alternative ways of processing incoming packets that do not meet the conditions of encapsulation and passing through a NAPT.

Detailed Description

[0013] Although the problems addressed by the modalities of the present invention described here exist for the mode of transport and the mode of tunnel in Internet transmissions, the mode disclosed is directed to the mode of transport. A small variation to be described adapts the disclosure of the mode of transport for operation in tunnel mode.

[0014] Modalities of the present invention can be implemented in software or hardware or in a combination of software and hardware. In addition, the modalities may take the form of a computer program product on a usable or computer-readable storage medium, with program code means incorporated into the medium for use by or in connection with a computer or any execution system. instructions. In the context of this document, a usable or computer-readable medium may be any medium that may contain, store, communicate, propagate or transport the program for use by or in connection with the system, apparatus or device for carrying out instructions. .

Petition 870190106009, of 10/20/2019, p. 15/28

8/19

[0015] The medium can be, for example, but is not limited to an electronic, magnetic, optical, electromagnetic, infrared, or propagation system, device or device. More specific examples (an incomplete list) of the computer-readable medium would include an electrical connection with one or more wires, a removable floppy disk, a random access memory (RAM), a read-only memory (ROM), a programmable erasable memory (EPROM or Flash memory), an optical fiber and a portable read-only CD memory (CD-ROM). Please note that the computer-usable or computer-readable media may even be paper or other suitable media that the program is printed on, as the program can be captured electronically, for example, through optical scanning of paper or other media and compiled, properly interpreted or otherwise processed, if necessary, and stored in the computer's memory.

[0016] In this report, equal numbers refer to equal elements.

[0017] IPsec processing can be used to authenticate or encrypt packet content for security reasons. Authentication and encryption can be applied to a package or can be applied separately. To simplify this presentation, the description of IPsec processing discusses the encapsulation and decapsulation of packets in terms of encryption and decryption. The described processing is equally valid if the authentication is being applied alone or together with the

Petition 870190106009, of 10/20/2019, p. 16/28

9/19 encryption.

[0018] When IPsec processing is applied to outgoing packets from a source client, the processing encrypts the original source and destination ports and the protocol field and encapsulates this encrypted material in a UDP packet. The source IP address of the original client is maintained in the UDP packet, but the source port number is set to 4500, as prescribed by RFC 3948 UDP Encapsulation of ESP IPsec packets. If the UDP packet passes through a NAPT, NAPT will perform other transformations. These transformations are described in detail below in relation to Figs. 1 and 2. Specifically, NAPT replaces its own IP address with the client's source IP address, assigns a new unique port number to the UDP header, and tracks these translations so that return packets can be mapped to the original source. RFC 3948 describes a scheme in which the original source port number in a TCP or UDP packet is not changed by the NAPT device, as it is part of the original transport header which is now encrypted as part of the IPsec ESP payload. The port number in the UDP header added to the UDP encapsulation is changed instead, as mentioned above. When such an IPsec packet is received by a server and decrypted, the original source and destination ports of the packet are revealed. For packets that are not processed through IPsec, the NAPT device converts the original source IP address and source port. For unencrypted packets, NAPTs ensure that there are no duplicate connections (sources

Petition 870190106009, of 10/20/2019, p. 17/28

10/19 duplicates).

[0019] Fig. 1 shows a package that progresses from a 10.1.1.1 client, through a NAPT 210.1.1.1 and a NAT

211.1.1.1 for a target host 11.1.1.1 and changes to the packet headers and content as the packet progresses.

[0020] Figure 2 illustrates the progress of the return package in the reverse direction, from the server to the client. With reference to Fig. 1, the client at IP address 10.1.1.1 sends an encrypted packet destined for the server at IP address

11.1.1.1. The original content of the packet before processing by IPsec is shown in 100. The left column of 100 describes a type of field in the packet, while the right column shows the content of the field. Note that the destination IP address at 100 is 211.1.1.1, which is the public NAT address in front of the actual destination server

11.1.1.1. It is the responsibility of NAT 211.1.1.1 to map packages to its back-end servers, such as 11.1.1.1. In 100, the source and destination ports are illustratively set to 4096 and 21, respectively. The contents of the packet after IPsec processing is shown in 102. The slightly shaded part at the bottom of packet 102 illustrates the part encrypted by IPsec. The heavier shaded parts of 102 (and the package contents at other points in the transmission path) illustrate fields that have been changed or added at that point in the transmission. In 102, the actual source and destination ports are encrypted values of 4096 and 21 per IPsec and cannot be read at this time. IPsec processing added a

Petition 870190106009, of 10/20/2019, p. 18/28

11/19 UDP header to indicate that this is an IPsec packet that

[0021] encapsulates the ports and the protocol of the client's original packet. The source and destination ports in the clear text UDP header added by IPsec are set to 4500, as specified in RFC 3948. A SPI (Security Parameter Index) field is illustratively set to 256. The SPI field, along with a security protocol and a destination address, points to a security association between the client

10.1.1.1 and the server 11.1.1.1 that governs the encryption algorithm and other security parameters between these entities.

[0022] The packet at 102 is translated by NAPT at IP address 210.1.1.1 and results in the packet shown at 104. At that point, NAPT 210.1.1.1 changed the source IP address to reflect its own 210.1.1.1 address. NAPT also defines a new unique source port number. In Fig. 1, the selected source port number is illustratively changed from 4500 to 4501. NAPT 210.1.1.1 controls this conversion for packets returned from the server 11.1.1.1 and for future outgoing packets from the client's IP 10.1.1.1 and original port 4500.

[0023] The package at 104 is back-translated by NAT

211.1.1.1 in the server's incoming packet 11.1.1.1. This incoming packet is shown in 106. Essentially, the packet's destination IP address is mapped by NAT 211.1.1.1 to the actual destination address 11.1.1.1 of the destination server. IPsec processing of the packet removes the UDP header added by IPsec processing at source 10.1.1.1 and

Petition 870190106009, of 10/20/2019, p. 19/28

12/19 restores the source and destination port numbers. The restored package, as shown in 108, is delivered to the destination port (21 in this example) for processing the application.

[0024] To complete, Fig. 2 shows a flow of return packets from the server 211.1.1.1 to the original client 10.1.1.1. There is no need to discuss this packet flow in any detail, because the problem of duplicated origin addressed by the modalities of the present invention cannot occur for return packets.

[0025] Referring again to Fig. 1, the packet at 108 contains the NAPT address as the source address

210.1.1.1 and a source port number 4096. However, it is possible that another client, say 10.1.1.2, is the NAPT

210.1. 1.1 is also sending packets to host 11.1.1.1 on source port 4096. Therefore, due to the presence of a NAPT in the path between client 10.1.1.1 and host 11.1.1.1, there is the possibility of an illegal duplicate source that results in a conflict.

[0026] A source port mapping table (SPMT) is used to detect duplicate sources in which packets are received from clients or servers served by a NAPT. An illustrative SPMT is shown in Figure 3 at 300. This table is created dynamically when Internet Key Exchange (IKE) packets are received on a server when an IPsec security association is established. Referring to Fig. 3, when IKE negotiates an IPsec security association that traverses a NAPT, the TCP / IP stack is notified to create a NAPT host entry such as 302 for

Petition 870190106009, of 10/20/2019, p. 20/28

13/19 represent the remote client, represented by NAPT. This entry contains the NAPT source IP address (210.1.1.1 in this example) and the source port assigned to this client by NAPT (4501 in this example). Fig. 3 shows a second illustrative NAPT client 304 with the same source IP address NAPT 210.1.1.1 and a different source port 4502 assigned by NAPT. On the right side of the SPMT 300 are the original port entries. These entries are created when IPsec-encoded packets arrive for which there is no existing entry. The process of adding source port entries occurs after IPsec decryption. The 306 associations that map the source port entries to the NAPT host entries are created as the source port entries are created. A NAPT host entry is removed when the last security association is deleted that belongs to the entry. When a packet arrives and is decrypted, the source NAPT address, the source port of the original packet and the protocol of the original packet are available. The SPMT source port entries are searched for a match on these attributes. If a match is found, the associated NAPT host entry is checked for a match at the NAPT source address and the NAPT-assigned source port. If these last attributes do not match, it means that two clients behind the source NAPT are trying to use the same source port numbers. This represents a duplicate source and the second package is rejected. If these last attributes match, the package is allowed.

Petition 870190106009, of 10/20/2019, p. 21/28

14/19

[0027] Figs. 4-7 help to illustrate the above discussion. Fig. 4 shows a packet from a NAPT source. The customer's address and port are assumed to be

10.1.1.1 and 4096, respectively, for illustration. 400 is the IP header updated by NAPT. It contains the NAPT address 210.1.1.1 and a destination host address 11.1.1.1. 402 is the tunnel UDP header added by IPsec processing and updated by NAPT. The source port

4500 was changed to 4501 by the NAPT. 404 contains the ESP (Encapsulated Security Protocol) header added by IPsec processing. The TCP transport header 406 contains the source and destination ports of the original client, 4096 and 21. 408 contains the payload data followed by the ESP trailer. Transport header 406 and payload 408 are encrypted according to IPsec processing. Fig. 5 represents the package in Fig. 4 after decryption on the destination host. Notice now that the source NAPT address

210.1.1.1 (from packet field 500) and client source port 4096 and protocol (TCP) are now available in field 506. SPMT 300 source port entries are searched using these attributes. In this example, a match is found at 308. The matching association 306 points to entry 302 of the NAPT host. The source NAPT address 210.1.1.1 and the source NAPT port

4501 correspond to this packet (the original port NAPT 4501 is available in field 402 of the received packet). Therefore, this package is associated with a correct connection and is accepted.

[0028] Figs. 6 and 7 represent a second duplicate source packet that will be rejected. This is because

Petition 870190106009, of 10/20/2019, p. 22/28

15/19 the NAPT source address 210.1.1.1 of field 700, the protocol of field 706 and port 4096 of the originating client correspond to 308 of the SPMT 300 source port entries, but the associated NAPT entry 302 does not correspond to the port number assigned to NAPT 4502 from field 602 of received packet.

[0029] Now, this process is explained in more detail below in association with appropriate flowcharts.

[0030] Fig. 8 illustrates the initialization of the SPMT 300 NAPT host entries during IKE negotiations. IKE negotiation is represented in step 802. After negotiation, step 804 sends a notification to the TCP / IP stack to create an associated NAPT host entry on the SPMT 300. This notification contains the NAPT source address and port number. retrieved from IKE streams.

[0031] Fig. 9 starts the process of detecting a duplicate source when a data packet arrives at the destination host. Step 902 determines whether the received packet contains an ESP packet encapsulated in a UDP header and the source port in the UDP header is not the default UDP tunnel port 4500. If the above is true, the packet will be using IPsec, either for encryption or authentication, and a NAPT is involved in the transmission path. If a packet is using a UDP protocol with a destination port of 4500 and the first four bytes contain non-zero data, the packet will be identified as a UDP-encapsulated ESP packet. If the answer in step 902 is negative, there are two alternative processing options, option 1 in 904 and option 2 in 906. Both are discussed below. Assuming the answer in 902 is yes, then 908

Petition 870190106009, of 10/20/2019, p. 23/28

16/19 continues in A in Fig. 10. In Fig. 10, step 1002 performs the IPsec processing required to decrypt the packet. As a result, the NAPT source address, the original customer's source port number and the protocol are obtained clearly, as explained above. Step 1004 searches for the SPMT 300 source port entries in these attributes. At 1006, if a match is not found, a source port entry is created in step 1008 and packet inbound processing continues normally. If a match is found in step 1006, step 1010 uses the corresponding 306 association to compare the source address and port number assigned to the NAPT from the NAPT host entry corresponding to the same attributes as the decrypted packet. If this comparison fails, the packet will be rejected in 1011. If a match is obtained, processing of the packet will normally continue in 1012.

[0032] Options 1 and 2 in Fig. 9 represent situations in which packets are sent in the clear (without IPsec processing) or there is no address translation (NAPT) in the path. However, duplicate fonts are still possible. Alternative options 1 and 2 detect these duplicate packages. Processing of option 1 starts at B in Figure 11. This option processes all data packets through the SPMT 300 table. This is done by adding another single NAPT host entry designated as NO IPSEC / NAPT. When a packet arrives, the SMPT 300 source port entries are searched as explained above. If no match is found, a door entry

Petition 870190106009, of 10/20/2019, p. 24/28

17/19 origin will be created in 1106 and associated with the NAPT NO IPSEC / NAPT host entry. If a corresponding source port entry is found in 1104, step 1110 will determine whether the corresponding 306 association will point to the NAPT NO IPSEC / NAPT host entry. In this case, the package is allowed in step 1108. Otherwise, it is rejected in step 1112. The advantage of this option 1 is simplicity. Its disadvantage is that all data traffic is processed through SPMT table 300.

[0033] Option 2 uses incoming IPsec packet filtering to reject duplicate source packets. After IPsec is on a host, all packets are processed by the IPsec rules table (the SPD), regardless of whether any packets are encrypted or not. This is to verify that unencrypted packets on a given connection are indeed permitted by the IPsec rule that governs the connection. The option 2 process starts at C in Fig. 12. The received packet is processed through the IPsec rules table (not shown) in step 1202. An example of how this is done in a preferred mode can be determined from that US patent 6,347,376. This patent is hereby incorporated by reference in its entirety. If the packet is encrypted (step 1204), step 1206 will determine whether the IPsec control rule requires encryption. Assuming this is the case, the packet is allowed in 1208. Otherwise, it will be rejected in 1210. If the packet is not encrypted in step 1204, a determination will be made in 1212 if the government IPsec rule allows unencrypted packets and the package is allowed or rejected in

Petition 870190106009, of 10/20/2019, p. 25/28

18/19 compliance.

[0034] In encapsulation mode, IPsec SA is not necessarily end-to-end. For example, an SA can be between a host and a gateway that serves multiple clients or servers. In tunnel mode, a single NAPT address (which is the source IP address in the UDP tunnel header) can potentially represent multiple hosts. In encapsulation mode, the encrypted and encapsulated part of a packet contains the original IP address of the source and a transport header. For the purposes of this specification, the original IP address of the source in tunnel mode is called the IP address of the internal source. Since the internal source IP address is not globally unique, it is not usable for packet routing or to represent the source of a connection. The original source port, as contained in the SPMT 300 source port entries, and the encapsulation source IP address with only the UDP port, as described above for the mode of transport, may not be unique. To resolve this, an additional field that contains the internal source IP address is added to the SPMT 300 source port entries (for example, 308) in Fig. 3. The internal source IP address (not available in transport mode) ) when combined with the other values of the source port entries produce a unique identifier for hosts protected by an IPsec SA in encapsulation mode. The internal source IP address is added to the source port entry as part of step 1008. When a packet in tunnel mode arrives, the SPMT source port entries are searched

Petition 870190106009, of 10/20/2019, p. 26/28

19/19 as described in step 1004 to find an association with a NAPT host entry and step 1010, in addition to what has already been described, it checks whether the IP address of the internal source client obtained from the decrypted packet is the same as the client IP address at the source port entry. If this check fails, the packet will be rejected

[0035] It will be evident to those skilled in the art that the preferred modalities can have many minor variations. For example, the ICMP protocol does not use port numbers; instead, they use query identifiers. With regard to the invention, as disclosed and claimed, query identifiers are equivalent to port numbers.

Claims (6)

1. Method for preventing duplicate source conflicts in a network protocol that uses network addresses, protocols and port numbers to identify connections characterized by the fact that it comprises: receive an inbound packet on a connection to a destination host from a remote source client; in response to a determination that the packet was translated by a network address translator and that the packet was received according to a security association defining how the packets are subjected to one or more encryptions and authentication for communication between the host and the source client, determine whether the port number is available within a range of security association port numbers (1112) and, where a port number is available, assign the available port number for the connection; and in response to the determination that no port number is available within a range of port numbers, reject the packet as a duplicate source (1114). 2. Method, according to claim 1, characterized by the fact that it also comprises the maintenance of a list of port numbers attributable to each remote source client and the assigned and unassigned states of each port number in the list. 3. Method according to claim 2, characterized by the fact that each list of assignable port numbers is a vector of bits in which the bit positions identify port numbers and the bit states Petition 870180154978, of 11/26/2018, p. 33/35 2/3 describe the assigned and unassigned states of the port numbers. 4. Method, according to claim 1, characterized by the fact that it also includes the maintenance of a Source Port Translation Table that associates each client-side connection with a translated port number. 5. Method, according to claim 4, characterized by the fact that the Source Port Translation Table contains the source port entries and translated source port entries, in which each source port entry is uniquely associated with an input port. translated source port and each source port entry contains an Internet source address, a UDP source port number assigned by a NAPT, a client source port number and a client protocol identifier, and each translated source port entry contains an Internet source address, a translated client source port number and a client protocol identifier, where translated source port entries are fetched from incoming packets to identify a port number previously assigned to a remote client connection and the translated source port entries are fetched from outgoing packets to identify a client port number from a previously assigned translated port number. 6. Apparatus to prevent duplicate source conflicts in a network protocol that uses network addresses, protocols and port numbers to identify connections, characterized by comprising: Petition 870180154978, of 11/26/2018, p. 34/35 3/3 means for receiving an incoming packet over a connection on a destination host from a remote source client; means responsive to a determination that the packet has been translated by a network address port translator and that the packet is received according to a security association defining how the packets are subject to one or more encryption and authentication for communication between the host and the source client, to determine if a port number is available within a range of port numbers for the security association (1112) and, where a port number is available, by assigning the available port number to the connection; and means responsive to a determination that no port number is available within the range of port numbers to reject the packet as a duplicate source (1114).