2. Known Incompatibilities between NA(P)T and IPsec

The incompatibilities between NA(P)T and IPsec can be divided into three categories:

Intrinsic NA(P)T issues. These incompatibilities derive directly from the NA(P)T functionality described in [RFC3022]. These incompatibilities will therefore be present in any NA(P)T device.
NA(P)T implementation weaknesses. These incompatibilities are not intrinsic to NA(P)T, but are present in many NA(P)T implementations. Included in this category are problems in handling inbound or outbound fragments. Since these issues are not intrinsic to NA(P)T, they can, in principle, be addressed in future NA(P)T implementations. However, since the implementation problems appear to be wide spread, they need to be taken into account in a NA(P)T traversal solution.
Helper issues. These incompatibilities are present in NA(P)T devices which attempt to provide for IPsec NA(P)T traversal. Ironically, this "helper" functionality creates further incompatibilities, making an already difficult problem harder to solve. While IPsec traversal "helper" functionality is not present in all NA(P)Ts, these features are becoming sufficiently popular that they also need to be taken into account in a NA(P)T traversal solution.

2.1. Intrinsic NA(P)T Issues

Incompatibilities that are intrinsic to NA(P)T include:

a) Incompatibility between IPsec AH [RFC2402] and NAT. Since the AH header incorporates the IP source and destination addresses in the keyed message integrity check, NAT or reverse NAT devices making changes to address fields will invalidate the message integrity check. Since IPsec ESP [RFC2406] does not incorporate the IP source and destination addresses in its keyed message integrity check, this issue does not arise for ESP.

b) Incompatibility between checksums and NAT. TCP and UDP checksums have a dependency on the IP source and destination addresses through inclusion of the "pseudo-header" in the calculation. As a result, where checksums are calculated and checked upon receipt, they will be invalidated by passage through a NAT or reverse NAT device.

As a result, IPsec Encapsulating Security Payload (ESP) will only pass through a NAT unimpeded if TCP/UDP protocols are not involved (as in IPsec tunnel mode or IPsec protected GRE), or checksums are not calculated (as is possible with IPv4 UDP). As described in [RFC793], TCP checksum calculation and verification is required in IPv4. UDP/TCP checksum calculation and verification is required in IPv6.

Stream Control Transmission Protocol (SCTP), as defined in [RFC2960] and [RFC3309], uses a CRC32C algorithm calculated only on the SCTP packet (common header + chunks), so that the IP header is not covered. As a result, NATs do not invalidate the SCTP CRC, and the problem does not arise.

Note that since transport mode IPsec traffic is integrity protected and authenticated using strong cryptography, modifications to the packet can be detected prior to checking UDP/TCP checksums. Thus, checksum verification only provides assurance against errors made in internal processing.

c) Incompatibility between IKE address identifiers and NAT. Where IP addresses are used as identifiers in Internet Key Exchange Protocol (IKE) Phase 1 [RFC2409] or Phase 2, modification of the IP source or destination addresses by NATs or reverse NATs will result in a mismatch between the identifiers and the addresses in the IP header. As described in [RFC2409], IKE implementations are required to discard such packets.

In order to avoid use of IP addresses as IKE Phase 1 and Phase 2 identifiers, userIDs and FQDNs can be used instead. Where user authentication is desired, an ID type of ID_USER_FQDN can be used, as described in [RFC2407]. Where machine authentication is desired, an ID type of ID_FQDN can be used. In either case, it is necessary to verify that the proposed identifier is authenticated as a result of processing an end-entity certificate, if certificates are exchanged in Phase 1. While use of USER_FQDN or FQDN identity types is possible within IKE, there are usage scenarios (e.g. Security Policy Database (SPD) entries describing subnets) that cannot be accommodated this way.

Since the source address in the Phase 2 identifier is often used to form a full 5-tuple inbound SA selector, the destination address, protocol, source port and destination port can be used in the selector so as not to weaken inbound SA processing.

d) Incompatibility between fixed IKE source ports and NAPT. Where multiple hosts behind the NAPT initiate IKE SAs to the same responder, a mechanism is needed to allow the NAPT to demultiplex the incoming IKE packets from the responder. This is typically accomplished by translating the IKE UDP source port on outbound packets from the initiator. Thus responders must be able to accept IKE traffic from a UDP source port other than 500, and must reply to that port. Care must be taken to avoid unpredictable behavior during re-keys. If the floated source port is not used as the destination port for the re-key, the NAT may not be able to send the re-key packets to the correct destination.

e) Incompatibilities between overlapping SPD entries and NAT. Where initiating hosts behind a NAT use their source IP addresses in Phase 2 identifiers, they can negotiate overlapping SPD entries with the same responder IP address. The responder could then send packets down the wrong IPsec SA. This occurs because to the responder, the IPsec SAs appear to be equivalent, since they exist between the same endpoints and can be used to pass the same traffic.

f) Incompatibilities between IPsec SPI selection and NAT. Since IPsec ESP traffic is encrypted and thus opaque to the NAT, the NAT must use elements of the IP and IPsec header to demultiplex incoming IPsec traffic. The combination of the destination IP address, security protocol (AH/ESP), and IPsec SPI is typically used for this purpose.

However, since the outgoing and incoming SPIs are chosen independently, there is no way for the NAT to determine what incoming SPI corresponds to what destination host merely by inspecting outgoing traffic. Thus, were two hosts behind the NAT to attempt to create IPsec SAs at the same destination simultaneously, it is possible that the NAT will deliver the incoming IPsec packets to the wrong destination.

Note that this is not an incompatibility with IPsec per se, but rather with the way it is typically implemented. With both AH and ESP, the receiving host specifies the SPI to use for a given SA, a choice which is significant only to the receiver. At present, the combination of Destination IP, SPI, and Security Protocol (AH, ESP) uniquely identifies a Security Association. Also, SPI values in the range 1-255 are reserved to IANA and may be used in the future. This means that, when negotiating with the same external host or gateway, the internal hosts behind the same NAPT can select the same SPI value, such that one host inbound SA is (SPI=470, Internal Dest IP=192.168.0.4) and a different host inbound SA is (SPI=470, Internal Dest IP=192.168.0.5). The receiving NAPT will not be able to determine which internal host an inbound IPsec packet with SPI=470 should be forwarded to.

It is also possible for the receiving host to allocate a unique SPI to each unicast Security Association. In this case, the Destination IP Address need only be checked to see if it is "any valid unicast IP for this host", not checked to see if it is the specific Destination IP address used by the sending host. Using this technique, the NA(P)T can be assured of a low but non-zero chance of forwarding packets to the wrong internal host, even when two or more hosts establish SAs with the same external host.

This approach is completely backwards compatible, and only requires the particular receiving host to make a change to its SPI allocation and IPsec_esp_input() code. However, NA(P)T devices may not be able to detect this behavior without problems associated with parsing IKE payloads. And a host may still be required to use a SPI in the IANA reserved range for the assigned purpose.

g) Incompatibilities between embedded IP addresses and NAT. Since the payload is integrity protected, any IP addresses enclosed within IPsec packets will not be translatable by a NAT. This renders ineffective Application Layer Gateways (ALGs) implemented within NATs. Protocols that utilize embedded IP addresses include FTP, IRC, SNMP, LDAP, H.323, SIP, SCTP (optionally), and many games. To address this issue, it is necessary to install ALGs on the host or security gateway that can operate on application traffic prior to IPsec encapsulation and after IPsec decapsulation.

h) Implicit directionality of NA(P)T. NA(P)Ts often require an initial outbound packet to flow through them in order to create an inbound mapping state. Directionality prohibits unsolicited establishment of IPsec SAs to hosts behind the NA(P)T.

i) Inbound SA selector verification. Assuming IKE negotiates phase 2 selectors, inbound SA processing will drop the decapsulated packet, since [RFC2401] requires a packet's source address match the SA selector value, which NA(P)T processing of an ESP packet would change.

2.2. NA(P)T Implementation Weaknesses

Implementation problems present in many NA(P)Ts include:

j) Inability to handle non-UDP/TCP traffic. Some NA(P)Ts discard non-UDP/TCP traffic or perform address-only translation when only one host is behind the NAT. Such NAPTs are unable to enable SCTP, ESP (protocol 50), or AH (protocol 51) traffic.

k) NAT mapping timeouts. NA(P)Ts vary in the time for which a UDP mapping will be maintained in the absence of traffic. Thus, even where IKE packets can be correctly translated, the translation state may be removed prematurely.

l) Inability to handle outgoing fragments. Most NA(P)Ts can properly fragment outgoing IP packets in the case where the IP packet size exceeds the MTU on the outgoing interface. However, proper translation of outgoing packets that are already fragmented is difficult and most NAPTs do not handle this correctly. As noted in Section 6.3 of [RFC3022], where two hosts originate fragmented packets to the same destination, the fragment identifiers can overlap. Since the destination host relies on the fragmentation identifier and fragment offset for reassembly, the result will be data corruption. Few NA(P)Ts protect against identifier collisions by supporting identifier translation. Identifier collisions are not an issue when NATs perform the fragmentation, since the fragment identifier need only be unique within a source/destination IP address pair.

Since a fragment can be as small as 68 octets [RFC791], there is no guarantee that the first fragment will contain a complete TCP header. Thus, a NA(P)T looking to recalculate the TCP checksum may need to modify a subsequent fragment. Since fragments can be reordered, and IP addresses can be embedded and possibly even split between fragments, the NA(P)T will need to perform reassembly prior to completing the translation. Few NA(P)Ts support this.

m) Inability to handle incoming fragments. Since only the first fragment will typically contain a complete IP/UDP/SCTP/TCP header, NAPTs need to be able to perform the translation based on the source/dest IP address and fragment identifier alone. Since fragments can be reordered, the headers to a given fragment identifier may not be known if a subsequent fragment arrives prior to the initial one, and the headers may be split between fragments. As a result, the NAPT may need to perform reassembly prior to completing the translation. Few NAPTs support this. Note that with NAT, the source/dest IP address is enough to determine the translation so that this does not arise. However, it is possible for the IPsec or IKE headers to be split between fragments, so that reassembly may still be required.

2.3. Helper Incompatibilities

Incompatibilities between IPsec and NAT "helper" functionality include:

n) Internet Security Association and Key Management Protocol (ISAKMP) header inspection. Today some NAT implementations attempt to use IKE cookies to de-multiplex incoming IKE traffic. As with source-port de-multiplexing, IKE cookie de-multiplexing results in problems with re-keying, since Phase 1 re-keys typically will not use the same cookies as the earlier traffic.

o) Special treatment of port 500. Since some IKE implementations are unable to handle non-500 UDP source ports, some NATs do not translate packets with a UDP source port of 500. This means that these NATs are limited to one IPsec client per destination gateway, unless they inspect details of the ISAKMP header to examine cookies which creates the problem noted above.

p) ISAKMP payload inspection. NA(P)T implementations that attempt to parse ISAKMP payloads may not handle all payload ordering combinations, or support vendor_id payloads for IKE option negotiation.