Packetization Layer Path Maximum Transmission Unit Discovery (PLPMTUD) For IPsec Tunnels

IPsec tunnels provides private and/or authenticated connectivity between an encrypting node and a decrypting node. An IPsec tunnel is constrained by the number of bytes that it can convey in a single packet, without fragmentation of any kind. This constraint is called the tunnel Maximum Transmission Unit (MTU). An IPSec tunnel's MTU can be calculated as its Path MTU (PMTU) minus IPSec tunnel overhead, where: PMTU is the smallest MTU of all the links forming a path between the encrypting node and the decrypting node. IPSec tunnel overhead is the maximum number of bytes required for padding (by the encryption algorithm) plus the number of bytes required for IPSec encapsulation. When forwarding a packet through an IPSec tunnel, the encrypting node compares the packet's length to the tunnel MTU. If the packet length is less than or equal to the tunnel MTU, the encrypting node encrypts the packet, encapsulates it and forwards it through the IPSec tunnel. If the packet length is greater than the tunnel MTU and the packet cannot be fragmented, the encrypting node discards the packet and sends an ICMP Packet Too Big (PTB) message to the packet's source. If the packet length is greater than the tunnel MTU and the packet can be fragmented, the encrypting node can execute either of the following procedures: Fragment, encrypt and encapsulate (FEE) Encrypt, encapsulate and fragment (EEF) If the encrypting node executes FEE procedures, it fragments the packet first. Then it encrypts, encapsulates and forwards each fragment. When a fragment arrives at the decrypting node, the decrypting node decapsulates and decrypts the fragment. Finally, the decrypting node forwards the fragment to its ultimate destination, where it can be reassembled. If the encrypting node executes EEF procedures, it encrypts and encapsulates the packet first. Then it fragments the resulting packet and forwards each fragment to the decrypting node. When the decrypting node has received all fragments, it reassembles the packet, decapsulates and decrypts it. Finally, it forwards the packet, in one piece, to its ultimate destination. In the paragraphs above, IPv4 packets with the Don't Fragment (DF) bit set to zero can be fragmented. IPv6 packets and IPv4 packets with the DF bit set to one cannot be fragmented. In the above-described procedure, the encrypting node maintains an estimate of the tunnel MTU. Network operators can configure the tunnel MTU on the encrypting node. Alternatively, they can configure the encrypting node to automatically discover and maintain a running estimate of the tunnel MTU. Today, when a encrypting node is configured to automatically discover the tunnel MTU, it executes ICMP-based PMTU Discovery (PMTUD) procedures. Having discovered the PMTU, it calculates the tunnel MTU by subtracting the IPSec tunnel overhead from the PMTU. The above-mentioned ICMP-based PMTUD procedures are susceptible to attack. An attacker can forge an ICMP PTB message, setting the MTU to a low value. When the encrypting node receives the forged ICMP PTB message, it decreases its estimate of tunnel MTU, causing unnecessary fragmentation. Therefore, many IPsec implementations do not implement tunnel MTU discovery at all. This document describes Packetization Layer PMTU Discovery (PLPMTUD) procedures for IPSec tunnels. In these procedures, the encrypting node discovers and maintains a running estimate of the tunnel MTU. In order to do this, the encrypting nodes sends Probe Packets of various size through the IPSec tunnel. If the size of Probe Packet exceeds the tunnel MTU, a downstream node discards the packet and sends an ICMP PTB message to the encrypting node. The encrypting node ignores the ICMP PTB message. If the size of the Probe Packet does not exceed the tunnel MTU and the decrypting node receives the Probe Packet, the decrypting node sends an Acknowledgement Packet to encrypting node through the IPSec tunnel. The Acknowledgement Packet indicates the size of the Probe Packet. Unlike ICMP PTB messages, this Acknowledgement Packet cannot be forged. The procedures described in this document are applicable to IPSec tunnels that are signaled by Internet Key Exchange version 2 (IKEv2) and provide authentication services.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

A special loopback interface is configured on the encrypting and decrypting nodes. In this document, these loopback interfaces are called the IPSec PLPMTUD interfaces. The encrypting node executes IKEv2 procedures to signal an IPSec tunnel between itself and a decrypting node. The IPSec tunnel MUST provide authentication services. It MAY also provide privacy services. If the outermost header of the IPSec tunnel is an IPv4 header, the DF bit must be set. IKEv2 endpoints MUST exchange traffic selectors advertising their IPSec PLPMTUD interface addresses. Implementations MUST ensure that traffic from one IPSec PLPMTUD address to another traverses the appropriate tunnel using the correct security association. As part of the tunnel establishment process, the encrypting node produces an initial estimate of the tunnel MTU. The encrypting node's initial estimate of the tunnel MTU is equal to its initial PMTU estimate minus IPSec tunnel overhead, where: The initial PMTU estimate is equal to the MTU of the first link along the path between the encrypting node and the decrypting node. IPSec tunnel overhead is the maximum number of bytes required for padding (by the encryption algorithm) plus the number of bytes required for IPSec encapsulation. This initial estimate may be greater than the actual tunnel MTU. Having established the IPSec tunnel, the ingress node begins to refine its estimate of the tunnel MTU. It MAY pass traffic through the tunnel as it refines the tunnel MTU estimate. In order to refine its estimate of the tunnel MTU, the ingress node executes the Packetization Layer PMTU Discovery (PLPMTUD) procedures described in Section 4 of . When applied to IPSec tunnels, these procedures can be summarized as follows: The encrypting node sends Probe Packets of various size through the IPSec tunnel. If the size of the Probe Packet exceeds the tunnel MTU, a downstream device drops the packet and sends an ICMP Packet Too Big (PTB) message to the encrypting node. The encrypting node ignores the ICMP PTB message. If the Probe Packet reaches the decrypting node, the decrypting node acknowledges receipt of the Probe Packet. of this document describes the Probe Packet. of this document describes how the decrypting node acknowledges receipt of the Probe Packet.

The encrypting node can probe the IPSec tunnel using an IPv4 packet or an IPv6 packet. depicts the IPv4 Probe Packet while depicts the IPv6 Probe Packet. In either case, the encrypting node forwards the Probe Packet through the IPSec tunnel.

Regardless of whether the Probe Packet is IPv4 or IPv6: The Source Address is the encrypting node's IPSec PLPMTUD interface address. The Destination Address is the decrypting node's IPSec PLPMTUD interface address. The Source Port is chosen from the dynamic port range (49152-65535) The Destination Port is equal to IPSec PLPMTUD. (Value TBD by IANA). The P-bit is set to indicate that this is a Probe Packet. The Reserved Field MUST be set to zero and MUST be ignored upon receipt. The Padding field is used to vary the size of the packet.

When the decrypting node receives a Probe Packet, it returns an Acknowledgment Packet. The Acknowledgment Packet can be an IPv4 packet or an IPv6 packet. depicts the IPv4 Acknowledgment Packet while depicts the IPv6 Acknowledgment Packet. In either case, the decrypting node forwards the Acknowledgment Packet through the IPSec tunnel that connects it to the encrypting node.

Regardless of whether the Acknowledgment Packet is IPv4 or IPv6: The Source Address is copied from the Destination Address of the corresponding Probe Packet The Destination Address is copied from the Source Address of the corresponding Probe Packet The Source Port is copied from the Destination Port of the corresponding Probe Packet The Destination Port copied from the Source Port of the corresponding Probe Packet The P-bit is clear to indicate that this is an Acknowledgement Packet. The Reserved Field MUST be set to zero and MUST be ignored upon receipt. The Probe length represents the total length of the corresponding Probe Packet, measured in bytes and not counting IPSec overhead

The procedures described herein are an improvement upon ICMP-based PMTUD procedures because unlike ICMP PTB messages, the Acknowledgement Packets described herein cannot be forged. The decrypting node MUST protect the encrypting node from forged Acknowledgement Packets. Therefore, the decrypting MAY originate packets whose source address is its PLPMTUD interface address. However, it MUST NOT forward packets whose source address is its PLPMTUD interface address.

Packets traversing a network, with multi paths (ECMP), would end up picking the lowest MTU available in any of the ECMP paths, when the proposed solution is employed (assuming that paths have different MTU values for the sake of analysis). This might cause some additional load on the encryption end, due to the lower MTU level fragmentation. This wouldn't be a major issue, as even otherwise, these loads would have got processed on the receiving side (decryption side) for reassembly and holding the packets in memory. It is worth noting that, at the encryption side it is more of 'stateless' action in terms of packet fragmentation is concerned as compared to at decryption side it is more of a 'stateful' action, where in, it need to maintain the fragments queue for reassembly. Moreover, reassembly node has no control over arrival of the fragments. So, when a choice has to be made for loading the end between encryption and decryption end, it is always better to load the encryption side due to the fact that the operation is stateless and less costly to perform comparatively.

IANA is request to allocate a UDP port called "IPSec PLPMTUD" from the Registered Port Range (1024 to 49151).

Thanks to Yoav Nir, Joe Touch, and Dan Wing for their review and comments.