[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

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

Abstract

   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.

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 September 1, 2018.




Piriyath, et al.        Expires September 1, 2018               [Page 1]


Internet-Draft              PLPMTUD for IPSec              February 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.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   4
   3.  PLPMTU Discovery Procedures . . . . . . . . . . . . . . . . .   4
     3.1.  Method of Operation . . . . . . . . . . . . . . . . . . .   4
     3.2.  PLPMTUD Probe . . . . . . . . . . . . . . . . . . . . . .   6
     3.3.  PLPMTUD Acknowledgement . . . . . . . . . . . . . . . . .   8
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   5.  ECMP Considerations . . . . . . . . . . . . . . . . . . . . .  10
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   IPsec [RFC4301] 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:

   o  PMTU is the smallest MTU of all the links forming a path between
      the encrypting node and the decrypting node.

   o  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.



Piriyath, et al.        Expires September 1, 2018               [Page 2]


Internet-Draft              PLPMTUD for IPSec              February 2018


   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 [RFC0792] [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:

   o  Fragment, encrypt and encapsulate (FEE)

   o  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 [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 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) [RFC1191] [RFC8201] procedures.
   Having discovered the PMTU, it calculates the tunnel MTU by
   subtracting the IPSec tunnel overhead from the PMTU.





Piriyath, et al.        Expires September 1, 2018               [Page 3]


Internet-Draft              PLPMTUD for IPSec              February 2018


   The above-mentioned ICMP-based PMTUD procedures are susceptible to
   attack [I-D.roca-ipsecme-ptb-pts-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)
   [RFC7296] and provide authentication services.

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.

3.  PLPMTU Discovery Procedures

3.1.  Method of Operation

   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



Piriyath, et al.        Expires September 1, 2018               [Page 4]


Internet-Draft              PLPMTUD for IPSec              February 2018


   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:

   o  The initial PMTU estimate is equal to the MTU of the first link
      along the path between the encrypting node and the decrypting
      node.

   o  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 [I-D.fairhurst-tsvwg-datagram-plpmtud].
   When applied to IPSec tunnels, these procedures can be summarized as
   follows:

   o  The encrypting node sends Probe Packets of various size through
      the IPSec tunnel.

   o  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.

   o  If the Probe Packet reaches the decrypting node, the decrypting
      node acknowledges receipt of the Probe Packet.

   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.








Piriyath, et al.        Expires September 1, 2018               [Page 5]


Internet-Draft              PLPMTUD for IPSec              February 2018


3.2.  PLPMTUD Probe

   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



















Piriyath, et al.        Expires September 1, 2018               [Page 6]


Internet-Draft              PLPMTUD for IPSec              February 2018


       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

   Regardless of whether the Probe Packet is IPv4 or IPv6:

   o  The Source Address is the encrypting node's IPSec PLPMTUD
      interface address.

   o  The Destination Address is the decrypting node's IPSec PLPMTUD
      interface address.

   o  The Source Port is chosen from the dynamic port range
      (49152-65535) [RFC6335]





Piriyath, et al.        Expires September 1, 2018               [Page 7]


Internet-Draft              PLPMTUD for IPSec              February 2018


   o  The Destination Port is equal to IPSec PLPMTUD.  (Value TBD by
      IANA).

   o  The P-bit is set to indicate that this is a Probe Packet.

   o  The Reserved Field MUST be set to zero and MUST be ignored upon
      receipt.

   o  The Padding field is used to vary the size of the packet.

3.3.  PLPMTUD Acknowledgement

   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










Piriyath, et al.        Expires September 1, 2018               [Page 8]


Internet-Draft              PLPMTUD for IPSec              February 2018


       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:

   o  The Source Address is copied from the Destination Address of the
      corresponding Probe Packet

   o  The Destination Address is copied from the Source Address of the
      corresponding Probe Packet

   o  The Source Port is copied from the Destination Port of the
      corresponding Probe Packet

   o  The Destination Port copied from the Source Port of the
      corresponding Probe Packet

   o  The P-bit is clear to indicate that this is an Acknowledgement
      Packet.



Piriyath, et al.        Expires September 1, 2018               [Page 9]


Internet-Draft              PLPMTUD for IPSec              February 2018


   o  The Reserved Field MUST be set to zero and MUST be ignored upon
      receipt.

   o  The Probe length represents the total length of the corresponding
      Probe Packet, measured in bytes and not counting IPSec overhead

4.  Security Considerations

   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.

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 request to allocate a UDP port called "IPSec PLPMTUD" from
   the Registered Port Range (1024 to 49151).

7.  Acknowledgements

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




Piriyath, et al.        Expires September 1, 2018              [Page 10]


Internet-Draft              PLPMTUD for IPSec              February 2018


8.  References

8.1.  Normative References

   [I-D.fairhurst-tsvwg-datagram-plpmtud]
              Fairhurst, G., Jones, T., Tuexen, M., and I. Ruengeler,
              "Packetization Layer Path MTU Discovery for Datagram
              Transports", draft-fairhurst-tsvwg-datagram-plpmtud-02
              (work in progress), December 2017.

   [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>.

   [RFC6335]  Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
              Cheshire, "Internet Assigned Numbers Authority (IANA)
              Procedures for the Management of the Service Name and
              Transport Protocol Port Number Registry", BCP 165,
              RFC 6335, DOI 10.17487/RFC6335, August 2011,
              <https://www.rfc-editor.org/info/rfc6335>.

   [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>.



Piriyath, et al.        Expires September 1, 2018              [Page 11]


Internet-Draft              PLPMTUD for IPSec              February 2018


   [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>.

   [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 September 1, 2018              [Page 12]


Internet-Draft              PLPMTUD for IPSec              February 2018


   Ron Bonica
   Juniper Networks
   2251 Corporate Park Drive
   Herndon, Virginia  20171
   USA

   Email: rbonica@juniper.net












































Piriyath, et al.        Expires September 1, 2018              [Page 13]

Html markup produced by rfcmarkup 1.126, available from https://tools.ietf.org/tools/rfcmarkup/