Network Working Group
Internet Engineering Task Force (IETF)                        V. Smyslov
Internet-Draft
Request for Comments: 7383                                    ELVIS-PLUS
Intended status:
Category: Standards Track                           June 10, 2014
Expires: December 12,                                  November 2014

                          IKEv2
ISSN: 2070-1721

 Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation
               draft-ietf-ipsecme-ikev2-fragmentation-10

Abstract

   This document describes the a way to avoid IP fragmentation of large
   IKEv2
   Internet Key Exchange Protocol version 2 (IKEv2) messages.  This
   allows IKEv2 messages to traverse network devices that do not allow
   IP fragments to pass through.

Status of this This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid the IETF community.  It has
   received public review and has been approved for a maximum publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of six months this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained 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 December 12, 2014.
   http://www.rfc-editor.org/info/rfc7383.

Copyright Notice

   Copyright (c) 2014 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
   (http://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 . . . . . . . . . . . . . . . . . . . . . . . . .  3 ....................................................2
      1.1. Problem description  . . . . . . . . . . . . . . . . . . .  3 Description ........................................2
      1.2. Proposed solution  . . . . . . . . . . . . . . . . . . . .  3 Solution ..........................................3
      1.3. Conventions Used in This Document  . . . . . . . . . . . .  4 ..........................4
   2. Protocol details . . . . . . . . . . . . . . . . . . . . . . .  5 Details ................................................4
      2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . .  5 ...................................................4
      2.2. Limitations  . . . . . . . . . . . . . . . . . . . . . . .  5 ................................................4
      2.3. Negotiation  . . . . . . . . . . . . . . . . . . . . . . .  5 ................................................5
      2.4. Using IKE Fragmentation  . . . . . . . . . . . . . . . . .  6 ....................................5
      2.5. Fragmenting Message  . . . . . . . . . . . . . . . . . . .  7 ........................................6
           2.5.1. Selecting Fragment Size  . . . . . . . . . . . . . . .  9 .............................8
           2.5.2. PMTU Discovery . . . . . . . . . . . . . . . . . . . . 10 ......................................9
           2.5.3. Fragmenting Messages containing unprotected Containing Unprotected
                  Payloads . . . . . . . . . . . . . . . . . . . . . . . 11 ...........................................11
      2.6. Receiving IKE Fragment Message . . . . . . . . . . . . . . 12 ............................11
           2.6.1. Replay Detection and Retransmissions . . . . . . . . . 14 ...............13
   3. Interaction with other Other IKE extensions  . . . . . . . . . . . . 15 Extensions ..........................14
   4. Transport Considerations . . . . . . . . . . . . . . . . . . . 16 .......................................14
   5. Security Considerations  . . . . . . . . . . . . . . . . . . . 17 ........................................15
   6. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19 ............................................16
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
   8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
     8.1. .....................................................16
      7.1. Normative References . . . . . . . . . . . . . . . . . . . 21
     8.2. ......................................16
      7.2. Informative References . . . . . . . . . . . . . . . . . . 21 ....................................16
   Appendix A. Design rationale  . . . . . . . . . . . . . . . . . . 23 Rationale ......................................19
   Appendix B. Correlation between IP Datagram size Size and Encrypted
               Payload content size  . . . . . . . . . . . 24 Content Size ..................................19
   Acknowledgements ..................................................20
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26 ..................................................20

1.  Introduction

1.1.  Problem description Description

   The Internet Key Exchange Protocol version 2 (IKEv2), specified in
   [IKEv2],
   [RFC7296], uses UDP as a transport for its messages.  Most IKEv2
   messages are relatively small, usually below several hundred bytes.
   Noticeable
   A notable exception is the IKE_AUTH Exchange, exchange, which requires fairly
   large messages, up to several kBytes, KB, especially when certificates are
   transferred.  When the IKE message size exceeds the path MTU, it gets
   fragmented by at the IP level.  The problem is that some network
   devices, specifically some NAT boxes, do not allow IP fragments to
   pass through.  This apparently blocks IKE communication and,
   therefore, prevents peers from establishing an IPsec SA. Security
   Association (SA).  Section 2 of [IKEv2] [RFC7296] discusses the impact of IP
   fragmentation on IKEv2 and acknowledges this problem.

   Widespread deployment of Carrier-Grade NATs (CGN) (CGNs) introduces new
   challenges.  [RFC6888] describes requirements for CGNs.  It states, states
   that CGNs must comply with Section 11 of [RFC4787], which requires
   NAT
   NATs to support receiving IP fragments (REQ-14).  In real life life,
   fulfillment of this requirement creates an additional burden in terms
   of memory, especially for high-capacity devices, devices used in CGNs.  It was
   found by people deploying IKE, IKE that more and more ISPs use equipment
   that drop drops IP fragments, thereby violating this requirement.

   Security researchers have found found, and continue to find find, attack vectors
   that rely on IP fragmentation.  For these reasons, and also as
   articulated in [FRAGDROP], many network operators filter all IPv6
   fragments.  Also, the default behavior of many currently deployed
   firewalls is to discard IPv6 fragments.

   In one recent study [BLACKHOLES], two researchers utilized a
   measurement network to measure fragment filtering.  They sent
   packets, fragmented to the minimum MTU of 1280, to 502 IPv6 enabled IPv6-enabled
   and reachable probes.  They found that during any given trial period,
   ten percent of the probes did not receive fragmented packets.

   Thus

   Thus, this problem is valid for both IPv4 and IPv6 and may be caused
   either
   by either deficiency of network devices or by operational choice.

1.2.  Proposed solution Solution

   The solution to the problem described in this document is to perform
   fragmentation of large messages by IKEv2 itself, replacing itself and replace them by with
   a series of smaller messages.  In this case case, the resulting IP Datagrams
   datagrams will be small enough so that no fragmentation on at the IP
   level will take place.

   The primary goal of this solution is to allow IKEv2 to operate in
   environments,
   environments that might block IP fragments.  This goal does not
   assume that IP fragmentation should be avoided completely, but only
   in those cases when it interferes with IKE operations.  However  However, this
   solution could be used to avoid IP fragmentation in all situations
   where fragmentation within IKE is applicable, as it is recommended in
   Section 3.2 of [RFC5405].  Avoiding IP fragmentation would be
   beneficial for IKEv2 in general.  The Security Considerations Section section
   of
   [IKEv2] [RFC7296] mentions exhausting exhaustion of the IP reassembly buffers as one
   of the possible attacks on the protocol.  In the paper [DOSUDPPROT] [DOSUDPPROT], several
   aspects of attacks on IKE using IP fragmentation are discussed, and
   one of the defenses it proposes is to perform fragmentation within IKE similarly
   IKE, similar to the solution described in this document.

1.3.  Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.  Protocol details Details

2.1.  Overview

   The idea of the protocol described in this document is to split large
   IKEv2 message messages into a set of smaller ones, called IKE Fragment Messages.
   messages.  Fragmentation takes place before the original message is
   encrypted and authenticated, so that each IKE Fragment Message message
   receives individual protection.  On the receiving side side, IKE Fragment Messages
   messages are collected, verified,
   decrypted decrypted, and merged together to
   get the original message before encryption.  See Appendix A for
   details on design rationale.

2.2.  Limitations

   Since IKE Fragment Messages messages are cryptographically protected, SK_a and
   SK_e must already be calculated.  In general, it means that the
   original message can be fragmented if and only if it contains an
   Encrypted
   Payload. payload.

   This implies that messages of the IKE_SA_INIT Exchange exchange cannot be
   fragmented.  In most cases cases, this is not a problem because IKE_SA_INIT
   messages are usually small enough to avoid IP fragmentation.  But in
   some cases (advertising a badly structured long list of algorithms,
   using large MODP Groups, etc.) Modular Exponentiation (MODP) groups, etc.), these
   messages may become fairly large and get fragmented by at the IP level.
   In this case case, the described solution described in this document will not help.

   Among existing IKEv2 extensions, messages of an IKE_SESSION_RESUME
   Exchange,
   exchange, as defined in [RFC5723], cannot be fragmented either.  See
   Section 3 for details.

   Another limitation is that the minimal minimum size of an IP Datagram datagram bearing
   an IKE Fragment Message message is about 100 bytes bytes, depending on the
   algorithms employed.  According to [RFC0791] [RFC0791], the minimum IPv4 Datagram
   datagram size that is guaranteed not to be further fragmented is
   68 bytes.  So, even the smallest IKE Fragment Messages messages could be
   fragmented by at the IP level in some circumstances.  But such extremely
   small PMTU Path MTU (PMTU) sizes are very rare in real life.

2.3.  Negotiation

   The Initiator initiator indicates its support for the IKE Fragmentation fragmentation and
   willingness to use it by including a Notification Payload payload of type
   IKEV2_FRAGMENTATION_SUPPORTED in the IKE_SA_INIT request message.  If
   Responder
   the responder also supports this extension and is willing to use it,
   it includes this notification in the response message.

   Initiator                   Responder
   -----------                 -----------
   HDR, SAi1, KEi, Ni,
      [N(IKEV2_FRAGMENTATION_SUPPORTED)]  -->

                       <--   HDR, SAr1, KEr, Nr, [CERTREQ],
                                  [N(IKEV2_FRAGMENTATION_SUPPORTED)]

   The Notify payload is formatted as follows:

                        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(=0)| SPI Size (=0) |      Notify Message Type      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Protocol ID (1 octet) - MUST be 0.

   o  SPI Size (1 octet) - MUST be 0, meaning no SPI Security Parameter
      Index (SPI) is present.

   o  Notify Message Type (2 octets) - MUST be xxxxx, 16430, the value assigned
      for the IKEV2_FRAGMENTATION_SUPPORTED notification.

   This Notification notification contains no data.

2.4.  Using IKE Fragmentation

   The

   IKE Fragmentation fragmentation MUST NOT be used unless both peers have indicated
   their support for it.  After that that, it is up to the Initiator initiator of each
   exchange to decide whether or not to use it.  The Responder responder usually
   replies in the same form as the request message, but other
   considerations might override this.

   The Initiator initiator can employ various policies regarding the use of IKE
   Fragmentation.
   fragmentation.  It might first try to send an unfragmented message
   and resend it as fragmented only if no complete response is received
   even after several retransmissions.  Alternatively, it might choose
   always
   to always send fragmented messages (but (however, see Section 3), or it
   might fragment only large messages and messages that are expected to
   result in large responses.

   The following general guidelines apply:

   o  If either peer has information that a part of the transaction is
      likely to be fragmented at the IP layer, causing interference with
      the IKE exchange, that peer SHOULD use IKE Fragmentation. fragmentation.  This
      information might be passed from a lower layer, provided by
      configuration, or derived through heuristics.  Examples of
      heuristics are the lack of a complete response after several
      retransmissions for the Initiator, initiator, and receiving repeated
      retransmissions of the request for the Responder. responder.

   o  If either peer knows that IKE Fragmentation fragmentation has been used in a
      previous exchange in the context of the current IKE SA, that peer
      SHOULD continue the to use of IKE Fragmentation fragmentation for the messages that are
      larger than the current fragmentation threshold (see
      Section 2.5.1).

   o  IKE Fragmentation fragmentation SHOULD NOT be used in cases where IP-layer
      fragmentation of both the request and response messages is
      unlikely.  For example, there is no point in fragmenting Liveness
      Check liveness
      check messages.

   o  If none of the above apply, the Responder responder SHOULD respond in the
      same form (fragmented or not) as the request message to which it
      is
      responding to. responding.  Note that the other guidelines might override this
      because of information or heuristics available to the Responder. responder.

   In most cases cases, IKE Fragmentation fragmentation will be used in the IKE_AUTH
   Exchange,
   exchange, especially if certificates are employed.

2.5.  Fragmenting Message

   Only messages that contain an Encrypted Payload payload are subject for to IKE
   Fragmentation.
   fragmentation.  For the purpose of construction of IKE Fragment Messages construction
   messages, the original (unencrypted) content of the Encrypted Payload payload
   is split into chunks.  The content is treated as a binary blob and is
   split regardless of the boundaries of inner Payloads boundaries. payloads.  Each of the
   resulting chunks is treated as an original content of the Encrypted
   Fragment Payload payload and is then encrypted and authenticated.  Thus, the
   Encrypted Fragment
   Payload payload contains a chunk of the original content
   of the Encrypted
   Payload payload in encrypted form.  The cryptographic
   processing of the Encrypted Fragment Payload payload is identical to that
   described in Section 3.14 of [IKEv2], [RFC7296], as well as documents updating it
   such processing for particular algorithms or modes, such as
   [RFC5282].

   The

   As is the case for the Encrypted Fragment Payload, similarly to payload, the Encrypted Payload, Fragment
   payload, if present in a message, MUST be the last payload in the
   message.

   The Encrypted Fragment Payload payload is denoted SKF{...} SKF{...}, and its payload
   type is XXX (TBA by IANA). 53.  This payload is also called the "Encrypted and
   Authenticated Fragment" 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        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Fragment Number        |        Total Fragments        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Initialization Vector                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                      Encrypted content                        ~
   +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               |             Padding (0-255 octets)            |
   +-+-+-+-+-+-+-+-+                               +-+-+-+-+-+-+-+-+
   |                                               |  Pad Length   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                    Integrity Checksum Data                    ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Encrypted Fragment Payload

   o  Next Payload (1 octet) - in the very first fragment (with Fragment
      Number equal to 1) 1), this field MUST be set to Payload Type the payload type of
      the first inner Payload (similarly to payload (the same as for the Encrypted Payload). payload).
      In the rest fragments of the Fragment messages (with Fragment Number greater
      than 1), this field MUST be set to zero.

   o  Fragment Number (2 octets) octets, unsigned integer) - current fragment number Fragment
      message number, starting from 1.  This field MUST be less than or
      equal to the next field, Total
      Fragments. field (Total Fragments).  This field MUST NOT be
      zero.

   o  Total Fragments (2 octets) octets, unsigned integer) - number of fragments Fragment
      messages into which the original message was divided into. divided.  This field
      MUST NOT be zero.  With PMTU
      discovery discovery, this field plays an
      additional role.  See Section 2.5.2 for details.

   The other fields are identical to those specified in Section 3.14 of
   [IKEv2].
   [RFC7296].

   When prepending the IKE Header header to the IKE Fragment Messages messages, it MUST
   be taken intact from the original message, except for the Length and the
   Next Payload fields.  The Length field is adjusted to reflect the
   length of the constructed IKE Fragment message being constructed, and the Next
   Payload field is set to the payload type of the first Payload payload in constructed that
   message (in most cases cases, it will be the Encrypted Fragment Payload). payload).
   After prepending the IKE Header header and all Payloads payloads that possibly
   precede the Encrypted Payload payload in the original message (if any, any; see
   Section 2.5.3), the resulting messages are sent to the peer.

   Below is an example of fragmenting a message.

   HDR(MID=n), SK(NextPld=PLD1) {PLD1 ... PLDN}

                             Original Message

   HDR(MID=n), SKF(NextPld=PLD1, Frag#=1, TotalFrags=m) {...},
   HDR(MID=n), SKF(NextPld=0, Frag#=2, TotalFrags=m) {...},
   ...
   HDR(MID=n), SKF(NextPld=0, Frag#=m, TotalFrags=m) {...}

                           IKE Fragment Messages

2.5.1.  Selecting Fragment Size

   When splitting the content of an Encrypted Payload payload into chunks chunks, the
   sender SHOULD choose their size so, so that the resulting IP Datagrams datagrams
   will be smaller than some fragmentation threshold.  Implementations
   may calculate the fragmentation threshold using various sources of
   information.

   If the Sender sender has information about the PMTU size size, it SHOULD use it.
   The
   Responder responder in the exchange may use the maximum size of the
   received IKE Fragment Message message IP Datagrams datagrams as a threshold when
   constructing a fragmented response.  Successful completion of
   previous exchanges (including those exchanges, exchanges that cannot employ IKE Fragmentation,
   e.g.
   fragmentation, e.g., IKE_SA_INIT) may be an indication, indication that the
   fragmentation threshold can be set to the size of the largest message
   of those messages already sent messages.

   Otherwise sent.

   Otherwise, for messages to be sent over IPv6 IPv6, it is RECOMMENDED to use that
   a value of 1280 bytes as a maximum IP Datagram datagram size be used
   ([RFC2460]).  For messages to be sent over IPv4 IPv4, it is RECOMMENDED to use
   that a value of 576 bytes as a maximum IP Datagram size.  Presence datagram size be used.  The
   presence of tunnels on the path may reduce these values.
   Implementations may use other values if they are appropriate in the
   current environment.

   According to [RFC0791] [RFC0791], the minimum IPv4 Datagram datagram size that is
   guaranteed not to be further fragmented is 68 bytes, but it is
   generally impossible to use such a small value for solution, the solution
   described in this document.  Using 576 bytes is a compromise - -- the
   value is large enough for the presented solution and small enough to
   avoid IP fragmentation in most situations.  Several other UDP-based protocol
   assume the value
   protocols (Syslog, DNS, etc.) use 576 bytes as a safe low limit for
   IP Datagrams size
   (Syslog, DNS, etc.). datagram size.

   See Appendix B for correlation between IP Datagram datagram size and Encrypted
   Payload
   payload content size.

2.5.2.  PMTU Discovery

   The amount of traffic that the IKE endpoint produces during the
   lifetime of an IKE SA is fairly modest - usually -- it is usually below one hundred kBytes 100 KB
   within a period of several hours.  Most of this traffic consists of
   relatively short messages - -- usually below several hundred bytes.  In
   most cases cases, the only time when IKE endpoints exchange messages of
   several kBytes KB in size is IKE SA establishment establishment, and often each endpoint
   sends exactly one such message.

   For the reasons articulated above above, implementing PMTU discovery in IKE
   is OPTIONAL.  It is believed that using the values recommended in
   Section 2.5.1 as a fragmentation threshold will be sufficient in most
   cases.  Using these values could lead to suboptimal fragmentation,
   but it is acceptable given the amount of traffic IKE produces.
   Implementations may support PMTU discovery if there are good reasons
   to do it (for example example, if it is they are intended to be used in
   environments where the MTU size is possible to might be less that than the values listed
   in Section 2.5.1).

   PMTU discovery in IKE follows recommendations given in Section 10.4
   of [RFC4821] with the difference, some modifications, induced by the specialties distinctive
   features of IKE listed above.  The difference is that the PMTU search
   is performed downward, while in [RFC4821] it is performed upward.
   The reason for this change is that IKE usually sends large messages
   only when the IKE SA is being established established, and in many cases there is
   only one such message.  If the probing were performed upward upward, this
   message would be fragmented using the smallest allowable threshold,
   and usually all other messages are small enough to avoid IP
   fragmentation, so there continued probing would be of little value to continue probing. value.

   It is the Initiator initiator of the exchange, exchange who performs PMTU discovery.  It
   This is done by probing several values of fragmentation threshold.
   Implementations MUST be prepared to probe in every exchange that
   utilizes IKE Fragmentation fragmentation to deal with possible changes of in path MTU
   over time.  While doing probes, it MUST start from larger values and
   refragment the original message message, using the next smaller value of the
   threshold if it did not receive a response in a reasonable time after
   several retransmissions.  The exact number of retransmissions and
   length of timeouts are not covered in this specification because they
   do not affect interoperability.  However, the timeout interval is
   supposed to be relatively short, so that unsuccessful probes would
   not delay IKE operations too much.  Performing a few retries within
   several seconds for each probe seems appropriate, but different
   environments may require different rules.  When starting a new probe probe,
   the node MUST reset its retransmission timers so, so that if it employs
   exponential back-
   off, back-off the timers will start over.  After reaching the
   smallest allowed value for the fragmentation threshold threshold, an
   implementation MUST continue retransmitting until either the exchange either
   completes or times out using some timeout interval from as discussed in
   Section 2.4 of [IKEv2]. [RFC7296].

   PMTU discovery in IKE is supposed to be coarse-grained, i.e. i.e., it is
   expected,
   expected that a node will try only a few fragmentation thresholds, thresholds in
   order to minimize delays caused by unsuccessful probes.  If no
   information about path MTU
   information is known yet, not yet available, the endpoint may start probing
   from use the link MTU size.
   size when it starts probing.  In subsequent exchanges, the following exchanges node
   should start
   from with the current value of the fragmentation threshold.

   If an implementation is capable to receive of receiving ICMP error messages messages, it
   can additionally utilize classic PMTU discovery methods, as described
   in [RFC1191] and [RFC1981].  In particular, if the Initiator initiator receives
   a Packet Too Big error in response to the probe, and it contains a
   smaller value, value than the current fragmentation threshold, then the
   Initiator
   initiator SHOULD stop retransmitting the probe and SHOULD select a
   new value for the fragmentation threshold that is less than or equal
   to the value from the ICMP message and meets the requirements listed
   below.

   In the case of PMTU discovery discovery, the Total Fragments field is used to
   distinguish between different sets of fragments, i.e. i.e., the sets that
   were created by fragmenting the original message using different
   fragmentation thresholds.  Since the sender starts from larger
   fragments and then make makes them smaller, the value in the Total
   Fragments field increases with each new probe.  When selecting the
   next smaller value for the fragmentation threshold, the sender MUST
   ensure that the value in the Total Fragments field is really
   increased.  This requirement should not be a problem for the sender,
   because PMTU discovery in IKE is supposed to be coarse-grained, so
   the difference between previous and next fragmentation thresholds
   should be significant anyway.  The necessity need to distinguish between the
   sets is vital for receiver the receiver, since receiving a valid fragment from
   a newer set means that it have has to start
   reassembling the reassembly process over
   and not to mix fragments from different sets.

2.5.3.  Fragmenting Messages containing unprotected Containing Unprotected Payloads

   Currently

   Currently, there are no IKEv2 exchanges that define messages,
   containing both unprotected payloads and payloads, that are protected
   by the Encrypted Payload.  However payload.  However, IKEv2 does not prohibit such
   construction.  If some future IKEv2 extension defines such a message
   and it needs to be fragmented, all unprotected payloads MUST be
   placed in the first fragment (with the Fragment Number field equal to
   1), along with the Encrypted Fragment Payload, payload, which MUST be present
   in every IKE Fragment Message message and be the last payload in it.

   Below is an example of a fragmenting message, containing message that contains both
   protected and unprotected Payloads. payloads.

   HDR(MID=n), PLD0, SK(NextPld=PLD1) {PLD1 ... PLDN}

                             Original Message

   HDR(MID=n), PLD0, SKF(NextPld=PLD1, Frag#=1, TotalFrags=m) {...},
   HDR(MID=n), SKF(NextPld=0, Frag#=2, TotalFrags=m) {...},
   ...
   HDR(MID=n), SKF(NextPld=0, Frag#=m, TotalFrags=m) {...}

                           IKE Fragment Messages

   Note that the size of each IP Datagram datagram bearing IKE Fragment Messages messages
   should not exceed the fragmentation threshold, including the first
   one, that contains unprotected Payloads. payloads.  This will reduce the size
   of the Encrypted Fragment Payload payload content in the first IKE Fragment Message
   message to accommodate all unprotected Payloads. payloads.  In an extreme case case,
   the Encrypted Fragment Payload payload will contain no data, but it still
   must be present in the message, because only its presence allows the
   receiver to determine that the sender have has used IKE Fragmentation. fragmentation.

2.6.  Receiving IKE Fragment Message

   The Receiver receiver identifies the IKE Fragment Message message by the presence of
   an Encrypted Fragment Payload payload in it.  In most cases cases, it will be the
   first and the only payload in the message, however message; however, this may not be true
   for some hypothetical IKE exchanges (see Section 2.5.3) 2.5.3).

   Upon receiving the IKE Fragment Message message, the following actions are
   performed:

   o  Check message validity - in particular, check whether the values
      in the Fragment Number and the Total Fragments fields in the
      Encrypted Fragment Payload payload are valid.  The following tests need to
      be performed.

      *  check that the Fragment Number and the Total Fragments fields
         contain non-zero values

      *  check that the value in the Fragment Number field is less than
         or equal to the value in the Total Fragments field

      *  if reassembling has already started, check that the value in
         the Total Fragments field is equal to or greater than the Total
         Fragments field in the fragments that have already been stored
         in the reassembling queue

      If any of this these tests fails fail, the message MUST be silently
      discarded.

   o  Check,  Check that this IKE Fragment Message message is new for the receiver and
      not a replay.  If an IKE Fragment message with the same Message
      ID,
      same Fragment Number Number, and same Total Fragments fields is already present
      in the reassembling queue, this message is considered a replay and
      MUST be silently discarded.

   o  Verify IKE Fragment Message message authenticity by checking ICV the Integrity
      Check Value (ICV) in the Encrypted Fragment Payload. payload.  If the ICV
      check fails fails, the message MUST be silently discarded.

   o  If reassembling is not finished yet and the Total Fragments field
      in the received fragment is greater than this the Total Fragments field
      in those fragments, fragments that are in the reassembling queue, the
      receiver MUST discard all received fragments and start reassembling the
      reassembly process over with just the received IKE Fragment Message.
      message.

   o  Store the message in the reassembling queue waiting for the rest
      of the fragments to arrive.

   When all IKE Fragment Messages messages (as indicated in the Total Fragments
   field) are received, the decrypted content of all Encrypted Fragment
   Payloads
   payloads is merged together to form the content of the original
   Encrypted
   Payload, payload and, therefore, along with the IKE Header header and
   unprotected
   Payloads payloads (if any), the original message.  Then  Then, it is
   processed as if it was received, verified verified, and decrypted as a regular
   IKE message.

   If the receiver does not get all IKE fragments needed to reassemble
   the original Message message within a timeout interval, it MUST discard all
   IKE Fragment Messages messages received so far for the exchange.  The next
   actions depend on the role of the receiver in the exchange.

   o  The Initiator initiator acts as described in Section 2.1 of [IKEv2]. [RFC7296].  It
      either retransmits the fragmented request Message message or deems the IKE
      SA to have failed and deletes it.  The number of retransmits and
      length of timeouts for the Initiator initiator are not covered in this
      specification
      specification, since they are assumed to be the same as in a
      regular IKEv2 exchange and are discussed in Section 2.4 of [IKEv2].
      [RFC7296].

   o  The Responder responder in this case acts as if no request message was
      received.  It would delete any memory of the incomplete request
      message,
      message and not treat it as an IKE SA failure.  The  It is RECOMMENDED
      that the reassembling timeout for the Responder is RECOMMENDED to responder be equal to the
      time interval that the implementation waits before completely
      giving up when acting as Initiator the initiator of an exchange.
      Section 2.4 of [IKEv2] [RFC7296] gives recommendations for selecting this
      interval.  Implementations can use a shorter timeout to conserve
      memory.

2.6.1.  Replay Detection and Retransmissions

   According to [IKEv2] implementations must reject message with Section 2.2 of [RFC7296], the
   same Message ID as it has seen before (taking into consideration
   Response bit). is used, in
   particular, to identify retransmissions of IKE messages.  Each
   request or response message, sent by either side, must have a unique
   Message ID, or be considered a retransmission otherwise.  This logic
   has already been updated by [RFC6311], which deliberately allows any
   number of messages with zero Message ID.  This document also updates
   this logic for the situations, when those situations where IKE Fragmentation fragmentation is in use.

   If an incoming message contains an Encrypted Fragment Payload, payload, the
   values of the Fragment Number and Total Fragments fields MUST be used
   along with the Message ID to detect retransmissions and replays.

   If Responder the responder receives a retransmitted fragment of a request when
   it has already processed that request and has sent back a response,
   that event MUST only trigger a retransmission of the response message
   (fragmented or not) if the Fragment Number field in the received
   fragment is set to 1 and 1; otherwise, it MUST be ignored otherwise. ignored.

3.  Interaction with other Other IKE extensions Extensions

   IKE Fragmentation fragmentation is compatible with most of IKE extensions, such as IKE
   Session Resumption ([RFC5723]), the Quick Crash Detection Method
   ([RFC6290])
   ([RFC6290]), and so on.  It neither affect affects their operation, operation nor is
   affected by them.  It is believed that IKE Fragmentation fragmentation will also be
   compatible with future IKE extensions, if they follow general
   principles of formatting, sending sending, and receiving IKE messages, as
   described in [IKEv2]. [RFC7296].

   When IKE Fragmentation fragmentation is used with IKE Session Resumption
   ([RFC5723]), messages of an IKE_SESSION_RESUME Exchange exchange cannot be
   fragmented
   fragmented, since they do not contain an Encrypted Payload. payload.  These
   messages may be large due to the ticket size.  To avoid IP
   Fragmentation
   fragmentation in this situation situation, it is recommended to use that smaller
   tickets, e.g.
   tickets be used, e.g., by utilizing a "ticket by reference" approach
   instead of "ticket by value".

   One exception that requires a special care is

   Protocol Support for High Availability of IKEv2/IPsec ([RFC6311]). IKEv2/IPsec, described in
   [RFC6311], requires special care when deciding whether to fragment an
   IKE message or not.  Since it deliberately allows any number of
   synchronization exchanges to have the same Message ID, namely zero,
   standard IKEv2 replay detection logic, based on checking the Message ID
   ID, is not applicable for such messages, and the receiver has to
   check message content to detect replays.  When implementing IKE Fragmentation
   fragmentation along with [RFC6311], IKE Message ID Synchronization
   messages MUST NOT be sent fragmented fragmented, to simplify the receiver's task
   of detecting replays.  Fortunately, these messages are small small, and
   there is no point in fragmenting them anyway.

4.  Transport Considerations

   With IKE Fragmentation fragmentation, if any single IKE Fragment Message get message gets lost,
   the receiver becomes unable to reassemble the original Message. message.  So,
   in general, using IKE Fragmentation fragmentation implies a higher probability for that
   the
   Message message will not to be delivered to the peer.  Although in most
   network environments the difference will be insignificant, on some
   lossy networks it may become noticeable.  When using IKE Fragmentation
   fragmentation, implementations MAY use longer timeouts and do more
   retransmits than usual before considering the peer dead.

   Note that Fragment Messages messages are not individually acknowledged.  The
   response Fragment Messages messages are all sent back all together only when all
   fragments of the request are received, and the original request Message
   message is reassembled and successfully processed.

5.  Security Considerations

   Most of the security considerations for IKE Fragmentation fragmentation are the
   same as those for the base IKEv2 protocol described in [IKEv2]. [RFC7296].
   This extension introduces the Encrypted Fragment Payload payload to protect
   the content of an IKE Message Fragment.  This allows the receiver to
   individually check the authenticity of fragments, thus protecting
   peers from a DoS attack.

   The Security Considerations Section section of [IKEv2] [RFC7296] mentions a possible
   attack on IKE where an attacker could prevent an exchange from
   completing by exhausting of the IP reassembly buffers.  The mechanism, mechanism
   described in this document, document allows IKE to avoid IP fragmentation and
   therefore increases its robustness to DoS attacks.

   The following attack is possible with IKE Fragmentation. fragmentation.  An attacker
   can initiate an IKE_SA_INIT Exchange, exchange, complete it, compute SK_a and SK_e
   SK_e, and then send a large, large but still incomplete, incomplete set of IKE_AUTH
   fragments.  These fragments will pass the ICV check and will be
   stored in reassembly buffers, but since the set is incomplete, the
   reassembling will never succeed and eventually will time out.  If the
   set is large, this attack could potentially exhaust the receiver's
   memory resources.

   To mitigate the impact of this attack, it is RECOMMENDED that the
   receiver limits limit the number of fragments it stores in the reassembling
   queue so that the sum of the sizes of Encrypted Fragment Payload payload
   contents (after decryption) for fragments that are already placed
   into the reassembling queue is less than some value that is
   reasonable for the implementation.  If the peer sends so many
   fragments that the above condition is not met, the receiver can
   consider this situation to be either an attack or as a broken sender
   implementation.  In either case, the receiver SHOULD drop the
   connection and discard all the received fragments.

   This value can be predefined, can be a configurable option, or can be
   calculated dynamically dynamically, depending on the receiver's memory load.
   Some care should be taken when selecting this value because, because if it is
   too
   small, small it might prevent a legitimate peer to establish from establishing an IKE
   SA if the size of messages it sends exceeds this value.  It is NOT
   RECOMMENDED for this value to exceed 64 Kbytes KB because any IKE message
   before fragmentation would likely be shorter than that.

   If IKE fragments arrive in order, it is possible, but not advised,
   for the receiver to parse the beginning of the message that is being
   reassembled and extract the already available already-available payloads before the
   reassembly is complete.  It can be dangerous to take any action based
   on the content of these payloads, because the fragments that have not
   yet been received
   fragments might contain payloads that could change the
   meaning of them (or could even make the whole message invalid) invalid), and
   this can potentially be exploited by an attacker.  It is important to
   address this threat by ensuring that all the fragments are received
   prior to parse parsing the reassembled message, as it described in
   Section 2.6.

6.  IANA Considerations

   This document defines a new Payload payload in the "IKEv2 Payload Types"
   registry:

     <TBA>

     53       Encrypted and Authenticated Fragment      SKF

   This document also defines a new Notify Message Types Type in the "Notify "IKEv2
   Notify Message Types - Status Types" registry:

     <TBA>

     16430       IKEV2_FRAGMENTATION_SUPPORTED

7.  Acknowledgements

   The author would like to thank Tero Kivinen, Yoav Nir, Paul Wouters,
   Yaron Sheffer, Joe Touch, Derek Atkins, Ole Troan and others for
   their reviews and valuable comments.  Thanks to Ron Bonica for
   contributing text to the Introduction Section.  Thanks to Paul
   Hoffman and Barry Leiba for improving text clarity.

8.  References

8.1.

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [IKEv2] 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC7296]  Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
              Kivinen, "Internet Key Exchange Protocol Version 2
              (IKEv2)", draft-kivinen-ipsecme-ikev2-rfc5996bis-03 (work
              in progress), April 2014. STD 79, RFC 7296, October 2014,
              <http://www.rfc-editor.org/info/rfc7296>.

   [RFC6311]  Singh, R., Kalyani, G., Nir, Y., Sheffer, Y., and D.
              Zhang, "Protocol Support for High Availability of IKEv2/
              IPsec", RFC 6311, July 2011.

8.2. 2011,
              <http://www.rfc-editor.org/info/rfc6311>.

7.2.  Informative References

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              September 1981. 1981, <http://www.rfc-editor.org/info/rfc791>.

   [RFC1191]  Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
              November 1990. 1990, <http://www.rfc-editor.org/info/rfc1191>.

   [RFC1981]  McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
              for IP version 6", RFC 1981, August 1996. 1996,
              <http://www.rfc-editor.org/info/rfc1981>.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998. 1998,
              <http://www.rfc-editor.org/info/rfc2460>.

   [RFC4787]  Audet, F. and C. Jennings, "Network Address Translation
              (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
              RFC 4787, January 2007. 2007,
              <http://www.rfc-editor.org/info/rfc4787>.

   [RFC4821]  Mathis, M. and J. Heffner, "Packetization Layer Path MTU
              Discovery", RFC 4821, March 2007. 2007,
              <http://www.rfc-editor.org/info/rfc4821>.

   [RFC5282]  Black, D. and D. McGrew, "Using Authenticated Encryption
              Algorithms with the Encrypted Payload of the Internet Key
              Exchange version 2 (IKEv2) Protocol", RFC 5282,
              August 2008. 2008, <http://www.rfc-editor.org/info/rfc5282>.

   [RFC5405]  Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines
              for Application Designers", BCP 145, RFC 5405,
              November 2008. 2008, <http://www.rfc-editor.org/info/rfc5405>.

   [RFC5723]  Sheffer, Y. and H. Tschofenig, "Internet Key Exchange
              Protocol Version 2 (IKEv2) Session Resumption", RFC 5723,
              January 2010. 2010, <http://www.rfc-editor.org/info/rfc5723>.

   [RFC6290]  Nir, Y., Wierbowski, D., Detienne, F., and P. Sethi, "A
              Quick Crash Detection Method for the Internet Key Exchange
              Protocol (IKE)", RFC 6290, June 2011. 2011,
              <http://www.rfc-editor.org/info/rfc6290>.

   [RFC6888]  Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A.,
              and H. Ashida, "Common Requirements for Carrier-Grade NATs
              (CGNs)", BCP 127, RFC 6888, April 2013. 2013,
              <http://www.rfc-editor.org/info/rfc6888>.

   [FRAGDROP]
              Jaeggli, J., Colitti, L., Kumari, W., Vyncke, E., Kaeo,
              M., and T. Taylor, "Why Operators Filter Fragments and
              What It Implies", draft-taylor-v6ops-fragdrop-02 (work Work in
              progress), Progress, draft-taylor-v6ops-
              fragdrop-02, December 2013.

   [BLACKHOLES]
              De Boer, M. and J. Bosma, "Discovering Path MTU black
              holes on the Internet using RIPE Atlas", July 2012, <http:
              //www.nlnetlabs.nl/downloads/publications/
              <http://www.nlnetlabs.nl/downloads/publications/
              pmtu-black-holes-msc-thesis.pdf>.

   [DOSUDPPROT]
              Kaufman, C., Perlman, R., and B. Sommerfeld, "DoS
              protection for UDP-based protocols", ACM Conference on
              Computer and Communications Security, October 2003.

Appendix A.  Design rationale Rationale

   The simplest approach to the IKE fragmentation would have been to
   fragment a message that is fully formed and ready to be sent.  But
   However, if a message got fragmented after being encrypted and
   authenticated, this could open a possibility for make a simple Denial of Service attack. DoS attack possible.  The
   attacker could infrequently emit forged but valid looking valid-looking fragments
   into the network, and some of these fragments would be fetched by the
   receiver into the reassembling queue.  Receiver could  The receiver would not be able
   to distinguish forged fragments from valid ones and could would only be
   able to determine that some of the received fragments were forged when
   after the whole message got was reassembled and check for its authenticity check
   failed.

   To prevent this kind of attack and also to reduce vulnerability to some
   other kinds of DoS attacks attacks, it was decided to make perform fragmentation
   before applying cryptographic protection to the message.  In this
   case
   case, each Fragment Message message becomes individually encrypted and
   authenticated, that
   authenticated; this allows the receiver to determine forged fragments
   and not to store them in the reassembling queue.

Appendix B.  Correlation between IP Datagram size Size and Encrypted Payload
             Content Size

   In the case of IPv4, the content size

   For IPv4 of the Encrypted Payload content size is
   less than the IP Datagram datagram size by the sum of the following values:

   o  IPv4 header size (typically 20 bytes, up to 60 if IP options are
      present)

   o  UDP header size (8 bytes)

   o  non-ESP (Encapsulating Security Payload) marker size (4 bytes if
      present)

   o  IKE Header header size (28 bytes)

   o  Encrypted Payload payload header size (4 bytes)

   o  IV  initialization vector (IV) size (varying) (variable)

   o  padding and its size (at least 1 byte)

   o  ICV size (varying) (variable)

   The sum may be estimated as 61..105 bytes + IV + ICV + padding.

   For IPv6 Encrypted Payload

   In the case of IPv6, the content size of the Encrypted Payload is
   less than the IP Datagram datagram size by the sum of the following values:

   o  IPv6 header size (40 bytes)

   o  IPv6 extension headers (optional, (optional; size varies)

   o  UDP header size (8 bytes)

   o  non-ESP marker size (4 bytes if present)

   o  IKE Header header size (28 bytes)

   o  Encrypted Payload payload header size (4 bytes)

   o  IV size (varying) (variable)

   o  padding and its size (at least 1 byte)

   o  ICV size (varying) (variable)

   If no extension header is present, the sum may be estimated as
   81..85 bytes + IV + ICV + padding.  If extension headers are present,
   the payload content size is further reduced by the sum of the size of
   the extension headers.  The length of each extension header can be
   calculated as 8 * (Hdr Ext Len) bytes bytes, except for the fragment header
   header, which is always 8 bytes in length.

Acknowledgements

   The author would like to thank Tero Kivinen, Yoav Nir, Paul Wouters,
   Yaron Sheffer, Joe Touch, Derek Atkins, Ole Troan, and others for
   their reviews and valuable comments.  Thanks to Ron Bonica for
   contributing text to the Introduction section.  Thanks to Paul
   Hoffman and Barry Leiba for improving text clarity.

Author's Address

   Valery Smyslov
   ELVIS-PLUS
   PO Box 81
   Moscow (Zelenograd)  124460
   Russian Federation

   Phone: +7 495 276 0211
   Email:
   EMail: svan@elvis.ru