Path Maximum Transmission Unit Discovery (PMTUD) For IPsec Tunnels Using The Internet Key Exchange Protocol (IKE) Version 2
draft-spiriyath-ipsecme-dynamic-ipsec-pmtu-00

Abstract

This document describes new Path MTU Discovery (PMTUD) procedures that leverage the Internet Key Exchange (IKE) version 2. Unlike ICMP-based PMTUD procedures, IKE-based PMTUD procedures are not susceptible to attack by forgery. This is because IKE messages are cryptographically authenticated.

The procedures described in this document are applicable in IPsec tunnel mode only and then, only when the outermost IP header is IPv4.

Status of This Memo

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 July 21, 2018.

Copyright Notice

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.

Table of Contents

• 1. Problem Statement
• 2. Requirements Language
• 3. PMTU Discovery Procedures
• 3.1. Method of Operation
• 3.2. IKE PMTU Notify Payload
• 3.3. Tunnel-In-Tunnel Scenarios
• 4. Security Considerations
• 5. ECMP Considerations
• 6. IANA Considerations
• 7. Acknowledgements
• 8. References
• 8.1. Normative References
• 8.2. Informative References
• Authors' Addresses

1. Problem Statement

IPsec tunnels provides private and/or authenticated connectivity between a tunnel ingress node and a tunnel egress node. An IPsec tunnel, like any other tunnel, is constrained by the number of bytes that it can convey in a single IP packet. This constraint is called the tunnel Maximum Transmission Unit (MTU).

A tunnel's MTU can be calculated as Path MTU (PMTU) minus overhead, where:

ICMP [RFC4443] Packet Too Big (PTB) message to the packet's source.

• PMTU is the smallest MTU associated with a link on the path between the tunnel ingress node and the tunnel egress node
• Overhead is the number of bytes required for tunnel encapsulation

When forwarding a packet through a tunnel, the tunnel ingress node compares the packet's length to the tunnel MTU. If the packet length is less than or equal to the tunnel MTU, the ingress node encapsulates the packet and forwards it through the tunnel. If the packet length is greater than the tunnel MTU and the packet can be fragmented, the ingress node fragments the packet, encapsulates each fragment, and forwards each encapsulated fragment through the tunnel. Each encapsulated fragment is delivered to the tunnel egress node, decapsulated and forwarded from there to its destination, where the packet is reassembled. If the packet length is greater than the tunnel MTU and the packet cannot be fragmented, the ingress node discards the packet and sends an

In the paragraph 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 tunnel ingress node maintains an estimate of the tunnel MTU. Network operators can configure the tunnel MTU on the tunnel ingress node. Alternatively, they can configure the tunnel ingress node to automatically discover and maintain a running estimate of the tunnel MTU. Today, when a tunnel ingress 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 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. This will cause the tunnel ingress node to decrease its estimate of tunnel MTU, causing unnecessary fragmentation. Therefore, many IPsec implementations do not implement tunnel MTU discovery at all.

This document describes new PMTUD procedures that are based upon the Internet Key Exchange version 2 (IKEv2). Unlike ICMP-based PMTUD procedures, IKE-based PMTUD procedures are not susceptible to attack by forgery. This is because IKE messages are cryptographically authenticated.

The procedures described in this document are applicable in IPsec tunnel mode only and then, only when the outermost IP header is IPv4.

2. Requirements Language

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.

3. PMTU Discovery Procedures

3.1. Method of Operation

An IPv4 IPsec tunnel is configured on the ingress node as follows:

• Outer header is IPv4
• IPv4 DF bit is always set to zero (fragmentation within the tunnel is allowed)
• PMTU is set to a high value (e.g., 15, 000 bytes)
• Tunnel MTU is set to the PMTU minus the number of bytes required for IPsec tunnel mode encapsulation

The IPsec tunnel is signalled using IKEv2 procedures. Although its estimate of the tunnel MTU is high, it begins to forward traffic. At some time in the future, the ingress node may forward a packet through the tunnel whose length is greater than the actual tunnel MTU. When this occurs, the ingress node encrypts and integrity protects the packet, encapsulates it within a transport header, and forwards it through the tunnel. The packet is fragmented enroute and reassembled by the egress node. It is also decrypted and/or authenticated by the egress node.

When the egress node reassembles the packet, it initiates an IKE INFORMATIONAL exchange with the ingress node. Within the context of this INFORMATIONAL exchange, the egress node sends a message to the ingress node that contains the Notify Payload described in Section 3.2 of this document. The ingress node responds with an empty message (i.e., no payload).

The above-mentioned Notify Payload includes the length of the largest fragment received. Using this value, the ingress node revises its estimate of the PMTU between itself and the egress node. Having updated its PMTU estimate, the tunnel ingress node also updates its estimate of the tunnel MTU. The new tunnel MTU is estimated to be the new PMTU minus the number of bytes required for IPsec tunnel mode operation.

Periodically, the tunnel ingress node resets it PMTU and tunnel MTU estimates to their initial values. This allows the ingress node to detect increases in the PMTU and tunnel MTU.

3.2. IKE PMTU Notify Payload

                          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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ! Next Payload  !C!  Reserved   !         Payload Length        !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !  Protocol ID  !   SPI Size    !      Notify Message Type      !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !                                                               !
     ~                Security Parameter Index (SPI)                 ~
     !                                                               !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !            Path MTU           !          Reserved             !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

IKE PMTU Notify Payload

The Next Payload, C, Reserved, and Payload Length fields are part of the IKE Generic Payload Header. The IKE Generic Payload Header is defined in Section 3.2 of RFC 7296. When applied to the PMTU Notify Payload, the C bit must be set to one.

The Protocol ID, SPI Size, Notify Message Type, and SPI fields are part of the IKE Notify Payload header. The IKE Notify Payload Header is defined in Section 3.10 of RFC 7296. When applied to the PMTU Notify Payload, the Notify Message Type MUST be equal to PMTU Notification. This value is to be reserved by IANA.

The Path MTU field indicates the size of the largest fragment received byte the message inititiator.

3.3. Tunnel-In-Tunnel Scenarios

Additional encapsulation such as GRE-o-IPSEC, or IP-o-IP etc are possible, en-route, which would have an impact on MTU and fragmentation. These additional headers are removed before the packet is submitted to IPsec decryption processing, because of that IPsec module will be blind towards additional encapsulation headers employed en-route.

In order to handle this specific scenario - during IPsec capability exchange, a 'mark down' value can be negotiated which will be used to subtract from the MTU value signaled dynamically during operation. This is in anticipation of additional layers of encapsulations enroute. This can be a an optional configuration.

Worst case, if we don't do anything to handle this, with this solution employed, it will be guaranteed to receive maximum of two fragments than (possible) several ones in a tunnel-in-tunnel scenario. It is due to the fact that, the lowest MTU allowed is 256 bytes and even multiple tunneling overhead will be less than 256 bytes in a practical scenario. Two Fragments would be still better off as compared to several (possibly unknown number of) fragments.

4. Security Considerations

A possible security scenario can be considered such that, MTU messages can be induced by a middle (rogue) router that fragments the ESP packets at lower values, intentionally. Assuming that the rogue router fragments ESP packets, so that TUNNEL MTU messages are triggered and initiator is compelled to do pre-fragmentation at lower MTU values, this will increase some CPU usage for fragmentation and producing sub optimal size ESP packets at the initiator side.

If the rogue router case is indeed possible, and MTU in the path is lowered ill intentionally, without this solution employed too, resulting impact would be to wait for more ESP fragments to arrive at the decryption end, before it can be reassembled and passed for decryption.

So, the odds are equal in both cases and does not give any specific degradation or improvement in terms of security consideration in this particular scenario.

5. ECMP Considerations

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.

6. IANA Considerations

IANA is requested to allocate a PMTU Notification codepoint from the "IKEv2 Notify Message Types - Status Types" registry (range 16384-40959).

7. Acknowledgements

8. References

8.1. Normative References

8.2. Informative References

Authors' Addresses