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]