| IPSECME Working Group | S. Piriyath |
| Internet-Draft | U. Mangla |
| Intended status: Standards Track | N. Melam |
| Expires: September 1, 2018 | R. Bonica |
| Juniper Networks | |
| February 28, 2018 |
Packetization Layer Path Maximum Transmission Unit Discovery (PLPMTUD) For IPsec Tunnels
draft-spiriyath-ipsecme-dynamic-ipsec-pmtu-01
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.
The procedures described in this document are applicable to IPSec tunnels that are signaled by IKEv2 and provide authentication services.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 1, 2018.
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
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:
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 [RFC4443] 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:
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) [RFC8201] 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 [RFC8174] 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:
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 [I-D.fairhurst-tsvwg-datagram-plpmtud]. When applied to IPSec tunnels, these procedures can be summarized as follows:
Section 3.2 of this document describes the Probe Packet. Section 3.3 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. Figure 1 depicts the IPv4 Probe Packet while Figure 2 depicts the IPv6 Probe Packet. In either case, the encrypting node forwards the Probe Packet through the IPSec tunnel.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |Version| IHL |Type of Service| Total Length |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Identification |Flags| Fragment Offset |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Time to Live | Protocol | Header Checksum |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 | Source Address |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Destination Address |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Source Port | Dest Port |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | UDP Length | UDP Checksum |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |P| Reserved |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
| // Padding //
| | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: IPv4 Probe Packet
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |Version| Traffic Class | Flow Label |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Payload Length | Next Header | Hop Limit |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
| + +
| | |
| + Source Address +
IPv6 | |
| + +
| | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
| + +
| | |
| + Destination Address +
| | |
| + +
| | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Source Port | Dest Port |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | UDP Length | UDP Checksum |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |P| Reserved |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
| // Padding //
| | |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: IPv6 Probe 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. Figure 3 depicts the IPv4 Acknowledgment Packet while Figure 4 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.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |Version| IHL |Type of Service| Total Length |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Identification |Flags| Fragment Offset |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Time to Live | Protocol | Header Checksum |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 | Source Address |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Destination Address |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Source Port | Dest Port |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
UDP | UDP Length | UDP Checksum |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |P| Reserved | Probe Length |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: IPv4 Acknowledgement Packet
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |Version| Traffic Class | Flow Label |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Payload Length | Next Header | Hop Limit |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
| + +
| | |
| + Source Address +
IPv6 | |
| + +
| | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
| + +
| | |
| + Destination Address +
| | |
| + +
| | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Source Port | Dest Port |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
UDP | UDP Length | UDP Checksum |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |P| Reserved | Probe Length |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: IPv6 Acknowledgement Packet
Regardless of whether the Acknowledgment Packet is IPv4 or IPv6:
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.
| [I-D.roca-ipsecme-ptb-pts-attack] | Roca, V. and S. Fall, "Too Big or Too Small? The PTB-PTS ICMP-based Attack against IPsec Gateways", Internet-Draft draft-roca-ipsecme-ptb-pts-attack-00, July 2015. |