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
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Shibu Piriyath , Umesh Mangla , Nagavenkata Melam , Ron Bonica | ||
| Last updated | 2018-01-17 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-spiriyath-ipsecme-dynamic-ipsec-pmtu-00
IPSECME Working Group S. Piriyath
Internet-Draft U. Mangla
Intended status: Standards Track N. Melam
Expires: July 21, 2018 R. Bonica
Juniper Networks
January 17, 2018
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
Piriyath, et al. Expires July 21, 2018 [Page 1]
Internet-Draft IKE PMTUD January 2018
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
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. PMTU Discovery Procedures . . . . . . . . . . . . . . . . . . 4
3.1. Method of Operation . . . . . . . . . . . . . . . . . . . 4
3.2. IKE PMTU Notify Payload . . . . . . . . . . . . . . . . . 5
3.3. Tunnel-In-Tunnel Scenarios . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5. ECMP Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Problem Statement
IPsec [RFC4301] 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:
o PMTU is the smallest MTU associated with a link on the path
between the tunnel ingress node and the tunnel egress node
o 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,
Piriyath, et al. Expires July 21, 2018 [Page 2]
Internet-Draft IKE PMTUD January 2018
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 ICMP [RFC0792] [RFC4443] Packet Too
Big (PTB) message to the packet's source.
In the paragraph above, IPv4 [RFC0791] packets with the Don't
Fragment (DF) bit set to zero can be fragmented. IPv6 [RFC8200]
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) [RFC1191] [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) [RFC7296]. Unlike ICMP-based
PMTUD procedures, IKE-based PMTUD procedures are not susceptible to
attack by forgery [I-D.roca-ipsecme-ptb-pts-attack]. 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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Piriyath, et al. Expires July 21, 2018 [Page 3]
Internet-Draft IKE PMTUD January 2018
3. PMTU Discovery Procedures
3.1. Method of Operation
An IPv4 IPsec tunnel is configured on the ingress node as follows:
o Outer header is IPv4
o IPv4 DF bit is always set to zero (fragmentation within the tunnel
is allowed)
o PMTU is set to a high value (e.g., 15, 000 bytes)
o 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.
Piriyath, et al. Expires July 21, 2018 [Page 4]
Internet-Draft IKE PMTUD January 2018
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.
Piriyath, et al. Expires July 21, 2018 [Page 5]
Internet-Draft IKE PMTUD January 2018
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.
Piriyath, et al. Expires July 21, 2018 [Page 6]
Internet-Draft IKE PMTUD January 2018
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
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, DOI 10.17487/RFC0792, September 1981,
<https://www.rfc-editor.org/info/rfc792>.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
DOI 10.17487/RFC1191, November 1990,
<https://www.rfc-editor.org/info/rfc1191>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/info/rfc4443>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/info/rfc7296>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Piriyath, et al. Expires July 21, 2018 [Page 7]
Internet-Draft IKE PMTUD January 2018
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
"Path MTU Discovery for IP version 6", STD 87, RFC 8201,
DOI 10.17487/RFC8201, July 2017,
<https://www.rfc-editor.org/info/rfc8201>.
8.2. Informative References
[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", draft-roca-
ipsecme-ptb-pts-attack-00 (work in progress), July 2015.
Authors' Addresses
Shibu Piriyath
Juniper Networks
Elnath-Exora Business Park
Bangalore, KA 93117
India
Email: spiriyath@juniper.net
Umesh Mangla
Juniper Networks
1133 Innovation Way
Sunnyvale, CA 94089
USA
Email: umangla@juniper.net
Nagavenkata Suresh Melam
Juniper Networks
1133 Innovation Way
Sunnyvale, CA 94089
USA
Email: nmelam@juniper.net
Piriyath, et al. Expires July 21, 2018 [Page 8]
Internet-Draft IKE PMTUD January 2018
Ron Bonica
Juniper Networks
2251 Corporate Park Drive
Herndon, Virginia 20171
USA
Email: rbonica@juniper.net
Piriyath, et al. Expires July 21, 2018 [Page 9]