Traversing a NAT

All of these RFCs have been implemented on z/OS®, providing z/OS with the capability to perform IPSec while traversing a NAT in a limited set of environments. RFC 3947 augments IKE's Main mode, Aggressive mode, and Quick mode messages flows to include additional information. It also provides for the negotiation of two new encapsulation modes.

Impacts to IKEv1 phase 1 (Main and Aggressive mode)

RFC 3947 requires that a vendor ID payload containing a NAT traversal vendor ID be exchanged between two IKEv1 peers. The vendor ID payload is an existing ISAKMP payload. The vendor ID payload is used by an IKE daemon to advertise support for a feature that is an extension to RFC 2408 (ISAKMP) and RFC 2409 (IKE). The vendor ID that is contained in the payload identifies the feature. The NAT traversal vendor ID is defined to be an MD5 hash of the vendor string RFC 3947.

The NAT traversal vendor ID must be received before an IKE daemon can send any of the new payloads and encapsulation modes that are defined in RFC 3947. Likewise, an IKE daemon should not send any of the new payloads and encapsulation modes defined in RFC 3947 without first sending the NAT traversal vendor ID.

If the initiator of an IKEv1 phase 1 negotiation wants to advertise support for RFC 3947, it must send the NAT traversal vendor ID in message 1 of a Main mode exchange or message 1 of an Aggressive mode exchange. If the responder of an IKEv1 phase 1 negotiation wants to advertise support for RFC 3947, it must send the NAT traversal vendor ID in message 2 of a Main mode exchange or message 2 of an Aggressive mode exchange.

z/OS provides limited support for several pre-RFC 3947 drafts, as well as additional z/OS-to-z/OS NAT traversal capabilities. Unique vendor IDs are used to identify these various levels of NAT traversal support. Table 1 shows the NAT traversal vendor IDs that are recognized by z/OS. The vendor IDs are listed from least functional to most functional. If z/OS receives multiples of these IDs, it uses the most functional level of support that it received.

Table 1 lists vendor ID strings.

Table 1. Vendor ID

Vendor ID string	Vendor ID
draft-ietf-ipsec-nat-t-ike-02\n	90cb8091 3ebb696e 086381b5 ec427b1f
draft-ietf-ipsec-nat-t-ike-02	cd604643 35df21f8 7cfdb2fc 68b6a448
draft-ietf-ipsec-nat-t-ike-03	7d9419a6 5310ca6f 2c179d92 15529d56
RFC 3947	4a131c81070358455c5728f20e95452f
z/OS CS-IKE NAT Traversal Level 1	95305bb5 64b82a30b 66968bbc 5326a8d

In z/OS, NAT traversal support can be enabled or disabled with the AllowNat parameter. The AllowNat parameter can be specified on the KeyExchangePolicy statement, the KeyExchangeAction statement of the IPSec Policy file, or both. When AllowNat is set to NO the z/OS IKE daemon does not send NAT traversal vendor IDs. See z/OS Communications Server: IP Configuration Reference for additional details about the AllowNat parameter.

RFC 3947 defines a mechanism for discovering the existence of NAT devices residing between two IKE daemons using IKEv1, as well as the location of the NAT devices. This mechanism is the NAT Discovery (NAT-D) payload. The NAT-D payload is an extension to RFC 2408 and 2409. It contains a hash of several pieces of information including an IP address and port value from the IP packet that is being sent to an IKE peer (for example, the packet containing the NAT-D payload).

Each IKEv1 peer sends two or more NAT-D payloads. The destination IP address and port of the outbound IKE packet are used to construct the hash that is contained within the first NAT-D payload. The source IP address and port of the outbound IKE packet are used to construct the hash that is contained within the second NAT-D payload. Normally, only two NAT-D payloads are exchanged; however, if the sender of the packet has multiple IP addresses and it does not know which IP address is used to send the packet, it can send a NAT-D payload for each IP address it owns.

The initiator of an IKEv1 phase 1 negotiation must send its NAT-D payloads in message 3 of a Main mode exchange or message 3 of an Aggressive mode exchange. The responder of an IKEv1 phase 1 negotiation must send its NAT-D payloads in message 4 of a Main mode exchange or message 2 of an Aggressive mode exchange.

Impacts to IKEv2 phase 1 (IKE_SA_INIT)

RFC 5996 requires that an IKE daemon that supports IKEv2 NAT traversal must send NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP payloads.

In z/OS, you can enable or disable NAT traversal support with the AllowNat parameter. You can specify the AllowNat parameter on the KeyExchangePolicy statement, the KeyExchangeAction statement of the IPSec Policy file, or both. When AllowNat is set to NO, the z/OS IKE daemon does not send NAT_DETECTION_SOURCE_IP or NAT_DETECTION_DESTINATION_IP payloads. See z/OS Communications Server: IP Configuration Reference for additional details about the AllowNat parameter.

If the initiator of an IKEv2 phase 1 negotiation wants to advertise support for IKEv2 NAT Traversal, it must send NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP payloads in the IKE_SA_INIT request. If the responder of an IKEv2 phase 1 negotiation wants to advertise support for IKEv2 NAT Traversal, it must send NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP payloads in the IKE_SA_INIT response.

RFC 5996 defines a mechanism for discovering the existence of NAT devices residing between two IKE daemons utilizing IKEv2, as well as the location of the NAT devices. This mechanism is based upon the NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP payloads. The NAT_DETECTION_SOURCE_IP payload contains a hash of several pieces of information including the source IP address and source port value from the IP packet that is being sent to an IKE peer (for example, the packet containing the NAT_DETECTION_SOURCE_IP payload). The NAT_DETECTION_DESTINATION_IP payload contains a hash of several pieces of information including the destination IP address and destination port value from the IP packet that is being sent to an IKE peer (for example, the packet containing the NAT_DETECTION_DESTINATION_IP payload).

Each IKEv2 peer sends one or more NAT_DETECTION_SOURCE_IP payloads and one NAT_DETECTION_DESTINATION_IP payload. The destination IP address and port of the outbound IKE packet are used to construct the hash that is contained within the first NAT_DETECTION_DESTINATION_IP payload. The source IP address and port of the outbound IKE packet are used to construct the hash that is contained within the NAT_DETECTION_SOURCE_IP payload. Normally, only one NAT_DETECTION_SOURCE_IP payload is sent; however, if the sender of the packet has multiple IP addresses and it does not know which IP address is used to send the packet, it can send a NAT_DETECTION_SOURCE_IP payload for each IP address it owns.

z/OS provides limited support for IKEv2 NAT traversal, as well as additional z/OS-to-z/OS NAT traversal capabilities. A unique vendor ID is used to identify one z/OS IKE daemon to another. The z/OS IKE daemon sends a vendor ID payload incorporating the "z/OS CS-IKE NAT Traversal Level 1" vendor ID string shown in Table 1 to identify itself as a z/OS IKE daemon to the peer. The z/OS IKE daemon includes this vendor ID payload in messages it sends that contain the NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP payloads.

Impacts to IKEv1 phase 2 (Quick mode)

RFC 3947 defines two new encapsulation mode values: UDP-Encapsulated-Transport and UDP-Encapsulated-Tunnel. These new encapsulation modes are defined in RFC 3948. See z/OS Communications Server: IP Configuration Guide for a description of these new modes.

When one or more NAT devices are detected between two IKEv1 peers, messages 1 and 2 of a Quick mode exchange should not use offers containing tunnel or transport mode of encapsulation. Offers containing UDP-Encapsulated-Transport or UDP-Encapsulated-Tunnel mode of encapsulation should be used instead. Likewise, when no NAT devices are detected between two IKEv1 peers, messages 1 and 2 of a Quick mode exchange should not use offers containing UDP-Encapsulated-Transport or UDP-Encapsulated-Tunnel mode of encapsulation.

On z/OS, only the tunnel or transport mode of encapsulation can be specified on the IpDataOffer statement (see z/OS Communications Server: IP Configuration Reference). The decision to use UDP-Encapsulated-Transport or UDP-Encapsulated-Tunnel mode is made heuristically by the IKE daemon. When a NAT is detected between two IKEv1 peers, the z/OS IKE daemon converts IpDataOffer statements containing tunnel mode encapsulation to UDP-Encapsulated-Tunnel mode and IpDataOffers containing transport mode encapsulation to UDP-Encapsulated-Transport mode.

In order to facilitate incremental TCP and UDP checksum verification, RFC 3947 requires that IKEv1 peers exchange their view of each other's IP addresses when sending SA offers containing UDP-Encapsulated-Transport mode encapsulation. RFC 3947 defines a new payload for this purpose. This new payload is the NAT Original Address (NAT-OA) payload. The NAT-OA payload is an extension of RFC 2408 and 2409. It contains an IP address.

When the initiator of a Quick mode exchange sends a proposal utilizing UDP-Encapsulated-Transport mode, RFC 3947 requires the initiator to send two NAT-OA payload in message 1. The first NAT-OA payload contains the initiator's view of their IP address. The second NAT-OA payload contains the initiator's view of the responder's IP address.

When the responder of a Quick mode exchange accepts a proposal utilizing UDP-Encapsulated-Transport mode, RFC 3947 requires the responder to send two NAT-OA payloads in message 2. The first NAT-OA payload contains the responder's view of the initiator's address. The second NAT-OA payload contains the responder's view of his address.

In pre-RFC 3947 drafts, only one NAT-OA payload can be sent in messages 1 and 2 of a Quick mode exchange. Sending this NAT-OA payload was recommended when sending a proposal utilizing UDP-Encapsulated-Transport encapsulation, but not required. In message 1, it contained the initiator's view of his IP address. In message 2, it contained the responder's view of his IP address.

Impacts to IKEv2 phase 2

RFC 5996 defines only two encapsulation modes: tunnel mode and transport mode. On z/OS, tunnel or transport mode of encapsulation for IKEv2 can be specified on the HowToEncapIKEv2 parameter of the IpDynVpnAction statement (see z/OS Communications Server: IP Configuration Reference). The decision to use UDP-Encapsulated-Transport or UDP-Encapsulated-Tunnel mode is made heuristically by the IKE daemon. When a NAT is detected between two IKEv2 peers, a child SA that negotiates transport mode will use UDP-Encapsulated-Transport mode for the traffic protected by the child SA. When a NAT is detected between two IKEv2 peers, a child SA that does not negotiate transport mode will use UDP-Encapsulated-Tunnel mode for the traffic protected by the child SA. The TCP/IP stack must process received UDP-encapsulated ESP packets even when no NAT is detected.

In order to facilitate incremental TCP and UDP checksum verification when using transport mode encapsulation, the original source and destination IP address are obtained from the Traffic Selector payloads. When a NAT is detected and the initiator proposes transport mode, the Traffic Selector payloads may only contain one unique IP address, which is then used as the original IP address. A given Traffic Selector payload may contain multiple Traffic Selectors provided each Traffic Selector has the same IP address.

When a NAT has been detected and the initiator proposes transport mode, the request that includes the Traffic Selector payloads contains the initiator's view of the initiator's IP address in the TSi payload and includes the initiator's view of responder's IP address in the TSr payload. Likewise, if the responder accepts transport mode, the response that includes the Traffic Selector payloads includes the responder's view of the initiator's IP address in the TSi payload and includes the responder's view of responder's IP address in the TSr payload.

Utilizing port UDP 4500

To avoid any problems that could arise by IPSec-aware NAT devices, RFC 3947 and RFC 5996 both require the initiator to use UDP port 4500 to send and receive IKE traffic after the initiator detects the existence of a NAT device. RFC 3947 and RFC 5996 allow IKEv2 traffic to use port 4500 regardless of whether a NAT is detected, even when the initiator is sending the first phase 1 request. In Main mode, the initiator detects the existence of a NAT when processing message 4 and switches to source port UDP 4500 and destination port 4500 when the initiator is sending message 5. In Aggressive mode, the initiator detects the existence of a NAT when processing message 2 and switches to a source port of UDP 4500 and a destination port of UDP 4500 when sending message 3. In IKEv2, the initiator detects the existence of a NAT when processing the IKE_SA_INIT response. When the responder sends the initiator a message it must use the port values from the last message that was received from the initiator.

After the initiator switches to port 4500, which is known as port floating, all subsequent messages must use the floated ports. The initiator always expects to send and receive messages on source port 4500 and destination port 4500. For the responder, if the remote peer is located behind a NAPT, the source port may have been changed to a value other than 4500. If so, the responder receives a message on a random source port Y and destination port 4500. After receiving this message, the responder sends subsequent messages using a source port of 4500 and destination port of Y.

These ports are also used to send UDP-encapsulated ESP traffic. In order to be able to distinguish UDP encapsulated ESP traffic from IKE traffic, a non-ESP marker is added to each IKE message sent using the UDP encapsulation ports. A non-ESP marker is 4 bytes of 0.

Figure 1 shows an IKE packet with and without the non-ESP marker.

Figure 1. IKE packet with and without the non-ESP marker