Network Working Group                                         V. Smyslov
Internet-Draft                                                ELVIS-PLUS
Intended status: Standards Track                           April 4,                            May 23, 2014
Expires: October 6, November 24, 2014

                          IKEv2 Fragmentation
               draft-ietf-ipsecme-ikev2-fragmentation-07
               draft-ietf-ipsecme-ikev2-fragmentation-08

Abstract

   This document describes the way to avoid IP fragmentation of large
   IKEv2 messages.  This allows IKEv2 messages to traverse network
   devices that don't do not allow IP fragments to pass through.

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 http://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 October 6, November 24, 2014.

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
     1.1.  Problem description  . . . . . . . . . . . . . . . . . . .  3
     1.2.  Proposed solution  . . . . . . . . . . . . . . . . . . . .  3
     1.3.  Conventions Used in This Document  . . . . . . . . . . . .  3  4
   2.  Protocol details . . . . . . . . . . . . . . . . . . . . . . .  4  5
     2.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . .  4  5
     2.2.  Limitations  . . . . . . . . . . . . . . . . . . . . . . .  4  5
     2.3.  Negotiation  . . . . . . . . . . . . . . . . . . . . . . .  4  5
     2.4.  Using IKE Fragmentation  . . . . . . . . . . . . . . . . .  5  6
     2.5.  Fragmenting Message  . . . . . . . . . . . . . . . . . . .  6  7
       2.5.1.  Selecting Fragment Size  . . . . . . . . . . . . . . .  8  9
       2.5.2.  PMTU Discovery . . . . . . . . . . . . . . . . . . . .  8 10
       2.5.3.  Fragmenting Messages containing unencrypted unprotected
               Payloads . . . . . . . . . . . . . . . . . . . . . . . 10 11
     2.6.  Receiving IKE Fragment Message . . . . . . . . . . . . . . 10 12
       2.6.1.  Changes in  Replay Protection Logic . Detection and Retransmissions . . . . . . . . . 12 14
   3.  Interaction with other IKE extensions  . . . . . . . . . . . . 13 15
   4.  Transport Considerations . . . . . . . . . . . . . . . . . . . 14 16
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15 17
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16 18
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 19
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 20
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 18 20
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 18 20
   Appendix A.  Design rationale  . . . . . . . . . . . . . . . . . . 20 22
   Appendix B.  Correlation between IP Datagram size and
                Encrypted Payload content size  . . . . . . . . . . . 21 23
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23 25

1.  Introduction

1.1.  Problem description

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

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

   Security researchers have found and continue to find attack vectors
   that rely on IP fragmentation.  For these reasons, and also
   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
   and reachable probes.  They found that during any given trial period,
   ten percent of the probes did not receive fragmented packets.

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

1.2.  Proposed solution

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

   Avoiding IP fragmentation

   The primary goal of this solution is beneficial for to allow IKEv2 to operate in general.
   Security Considerations Section of [RFC5996] mentions exhausting of
   the
   environments, that may block IP reassembly buffers as one of possible attacks on the protocol.
   In the paper [DOSUDPPROT] several aspects of attacks on IKE using fragments.  This goal does not assume
   that IP fragmentation are discussed, and one of should be avoided completely, but only in those
   cases when it interferes with IKE operations.  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.  Security Considerations Section of
   [IKEv2] mentions exhausting of the IP reassembly buffers as one of
   the possible attacks on the protocol.  In the paper [DOSUDPPROT]
   several aspects of attacks on IKE using IP fragmentation are
   discussed, and one of the defenses it proposes is to perform IKE-level fragmentation, similar
   fragmentation within IKE similarly to the solution, solution described in this
   document.

1.1.

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

2.1.  Overview

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

2.2.  Limitations

   As

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

   This implies that messages of the IKE_SA_INIT Exchange cannot be
   fragmented.  In most cases this is not a problem, since 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.) these messages may become fairly large
   and get fragmented by IP level.  In this case the described solution
   won't
   will not help.

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

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

2.3.  Negotiation

   Initiator MAY indicate indicates its support for the IKE Fragmentation and
   willingness to use it by including Notification Payload of type
   IKEV2_FRAGMENTATION_SUPPORTED in IKE_SA_INIT request message.  If
   Responder also supports this extension and is willing to use it, it
   includes this notification in 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 is present.

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

   This Notification contains no data.

2.4.  Using IKE Fragmentation

   The IKE Fragmentation MUST NOT be used unless both peers have
   indicated their support for it.  After IKE Fragmentation is negotiated, that it is up to the the
   Initiator of each Exchange, exchange to decide whether to use it or not.  In most cases
   IKE Fragmentation will be used  The
   Responder usually replies in IKE_AUTH Exchange, especially if
   certificates are employed. the same form as the request message,
   but other considerations might override this.

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

   In general the

   The following general guidelines are applicable for initiator: apply:

   o  Initiator MAY fragment outgoing message if it  If either peer has some knowledge
      (possibly from lower layer or from configuration) or suspicions information that either request or response message will a part of the transaction is
      likely to be fragmented by at the IP
      level.

   o  Initiator layer, causing interference with
      the IKE exchange, that peer SHOULD fragment outgoing message if it has some
      knowledge (possibly use IKE Fragmentation.  This
      information may be passed from a lower layer or from configuration) or
      suspicions that either request layer, provided by
      configuration, or derived through heuristics.  Examples of
      heuristics are the lack of a complete response message will be
      fragmented by IP level after several
      retransmissions for the Initiator, and receiving repeated
      retransmissions of the request for the Responder.

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

   o  Initiator  IKE Fragmentation SHOULD NOT fragment outgoing message if be used in cases where IP-layer
      fragmentation of both the request and response messages of the Exchange are small enough not to cause
      fragmentation on IP level (for is
      unlikely.  For example, there is no point in fragmenting Liveness
      Check messages).

   In general the following guidelines are applicable for responder: messages.

   o  If none of the above apply, the Responder SHOULD send response message respond in the
      same form (fragmented or not) as corresponded request message.  If it
      received unfragmented request message, responded with unfragmented
      response message and then receives fragmented retransmission of the same request, it SHOULD resend its response back to Initiator
      fragmented.

   o  Responder MAY respond to unfragmented request message with fragmented
      response if it has some knowledge (possibly from lower layer or
      from configuration) or suspicions is
      responding to.  Note that response message will be
      fragmented by IP level.

   o  Responder MAY respond to fragmented message with unfragmented
      response if the size other guidelines might override this
      because of information or heuristics available to the response message is less than the
      smallest fragmentation threshold, supported by Responder (for
      example, there is no point Responder.

   In most cases IKE Fragmentation will be used in fragmenting Liveness Check
      messages). the IKE_AUTH
   Exchange, especially if certificates are employed.

2.5.  Fragmenting Message

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

   The Encrypted Fragment Payload, similarly to the Encrypted Payload,
   if present in a message, MUST be the last payload in the message.

   The Encrypted Fragment Payload is denoted SKF{...} and its payload
   type is XXX (TBA by IANA).  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) this field MUST be set to Payload Type of the
      first inner Payload (similarly to the Encrypted Payload).  In the
      rest fragments MUST be set to zero.

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

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

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

   When prepending IKE Header, Length field Header to the IKE Fragment 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 message and the Next Payload field MUST reflect is set
   to the payload type of the first Payload in the constructed message (that in (in
   most cases it will be Encrypted Fragment Payload).  All newly
   constructed messages MUST retain the same Message ID as original
   message.  After prepending
   IKE Header and possibly any of all Payloads that precedes possibly precede Encrypted Payload
   in original message (see (if 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 content of Encrypted Payload into chunks sender SHOULD chose
   choose their size of those chunks so, that resulting IP Datagram size not exceed Datagrams be smaller than
   some fragmentation threshold.  Implementation may calculate
   fragmentation threshold - be small enough to avoid IP
   fragmentation. using various sources of information.

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

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

   According to [RFC0791] the minimum IPv4 datagram size that is
   guaranteed not to be further fragmented is 68 bytes, but it is
   generally impossible to use such small value for 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 576 bytes as a safe low limit for IP datagrams size
   (Syslog, DNS, etc.).  Sender MAY use other values if they are
   appropriate.

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

2.5.2.  PMTU Discovery

   Initiator MAY try to discover path MTU by probing several values

   The amount of
   fragmentation threshold.  While doing probes, node MUST start from
   larger values and refragment message with next smaller value if traffic that IKE endpoint produces during lifetime of
   IKE SA is fairly modest - usually it
   doesn't receive response in is below one hundred kBytes
   within a reasonable time after period of several
   retransmissions.  This time is supposed to be hours.  Most of this traffic consists of
   relatively short, so
   that node could make all desired probes before exchange times out.
   When starting new probe (with smaller threshold) node MUST reset its
   retransmission timers so, that if it employs exponential back-off,
   the timers start over.  After reaching short messages - usually below several hundred bytes.  In
   most cases the smallest allowed value for
   fragmentation threshold implementation MUST continue probing using it
   until either only time when IKE endpoints exchange completes or times out.

   PMTU discovery messages of
   several kBytes in IKE size is supposed to be coarse-grained, i.e. it is
   expected, that node will try only few fragmentation thresholds, in
   order to minimize possible IKE SA establishment delay.  In a corner
   case, when host will use only and often each
   endpoint sends exactly one value, PMTU discovery will
   effectively be disabled.  In most cases such message.

   For the reasons atriculated above implementing PMTU discovery will not be
   needed, as in IKE
   is OPTIONAL.  It is believed that using values, the values recommended in section
   Section 2.5.1, should
   suffice.  It 2.5.1 as fragmentation threshold will be sufficient in most
   cases.  Using these values could lead to suboptimal fragmentation,
   but it is expected, that acceptable given the amount of traffic IKE produces.
   Implementation may support PMTU discovery may if there are good reasons
   to do it (for example if it is intended to be useful used in environments
   where PMTU MTU size are smaller, than those is possible to be less that values listed in
   Section 2.5.1, for example due to the presence of intermediate
   tunnels. 2.5.1).

   PMTU discovery in IKE follows recommendations, recommendations given in Section 10.4
   of RFC4821 [RFC4821] with some differences, the difference, induced by the specialties of IKE.  In particular:

   o  Unlike classical PMTUD [RFC1191] and PLMTUD [RFC4821] the goal of
      Path MTU discovery in IKE
   listed above.  The difference is not to find the largest size of IP
      packet, that will not be fragmented en route, but to find any
      reasonable size, probably far from optimal.

   o  There the PMTU search is no goal to completely disallow IP fragmentation until its
      presence leads to inability IKE to communicate (e.g. when IP
      fragments are dropped)

   o performed
   downward, while in [RFC4821] it is performed upward.  The reason for
   this change is that IKE usually sends large messages only in IKE_AUTH exchange, i.e.
      once per when IKE SA.  Most of other messages will have size below
      several hundred bytes.  Performing full PMTUD for sending exactly
      one large message SA
   is inefficient.

   In case of PMTU discovery Total Fragments field being established and in many cases there is used to
   distinguish between different sets of fragments, i.e. only one such
   message.  If the sets that probing were obtained by fragmenting original performed upward this message would be
   fragmented using different
   fragmentation thresholds.  As sender will start from larger fragments
   and then make them smaller, the smallest allowable threshold, and usually all
   other messages are small enough to avoid IP fragmentation, so there
   would be little value to continue probing.

   It is the Initiator of the exchange, who performs PMTU discovery.  It
   is done by probing several values of fragmentation threshold.
   Implementation MUST be prepared to probe in every exchange that
   utilizes IKE Fragmentation to deal with possible changes of path MTU
   over time.  While doing probes, it MUST start from larger values and
   refragment original message using next smaller value of threshold if
   it did not receive 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.  Performimg few retries within several
   seconds for each probe seems appropriate, but different environments
   may require different rules.  When starting new probe node MUST reset
   its retransmission timers so, that if it employs exponential back-
   off, the timers will start over.  After reaching the smallest allowed
   value for fragmentation threshold implementation MUST continue
   retransmitting until either exchange completes or times out using
   timeout interval from Section 2.4 of [IKEv2].

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

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

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

2.5.3.  Fragmenting Messages containing unencrypted unprotected Payloads

   Currently there are no one of IKEv2 Exchanges defines exchanges that define messages,
   containing both
   unencrypted unprotected payloads and payloads, protected by
   Encrypted Payload.
   But  However IKEv2 doesn't forbid does not prohibit such messages.
   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, fragment (with Fragment Number field equal to 1),
   along with Encrypted Fragment Payload, which MUST be present in any every
   IKE Fragment
   Message. Message and be the last payload in it.

   Below is an example of fragmenting message, containing both encrypted protected
   and unencrypted unprotected 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,

   Note that the size of each IP Datagram bearing IKE Fragment Messages
   SHOULD NOT
   should not exceed fragmentation threshold, including the very first,
   which first one,
   that contains unprotected Payloads.  This will reduce the size of
   Encrypted Fragment Payload content in the first IKE Fragment Message
   to accommodate all unprotected Payloads.  In extreme cases case Encrypted
   Fragment Payload will contain no data, but it is still MUST must be present
   in the message, because only its presence allows receiver to
   distinguish IKE Fragment Message from regular
   determine that sender have used IKE message. Fragmentation.

2.6.  Receiving IKE Fragment Message

   Receiver identifies IKE Fragment Message by the presence of Encrypted
   Fragment Payload in it.  Note, that  In most cases it is possible for this payload
   to be not the first (and the only) payload in the message (see
   Section 2.5.3).  But for all currently defined IKEv2 exchanges this
   payload will be the first and the
   only payload in the message. message, however this may not be true for some
   hypothetical IKE exchanges (see Section 2.5.3)

   Upon receiving IKE Fragment Message the following actions are
   performed:

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

      *  check that Fragment Number and Total Fragments fields are non-
         zero

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

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

      If any of this tests fails message MUST be silently discarded.

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

   o  Verify IKE Fragment Message authenticity by checking ICV in
      Encrypted Fragment Payload.  If ICV check fails message MUST be
      silently discarded.

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

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

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

   If receiver doesn't does not get all IKE Fragment Messages fragments needed to reassemble
   original Message for some Exchange within a timeout
   interval, it acts according with Section 2.1 of [RFC5996], i.e.

   retransmits interval, it MUST discard all
   received so far IKE Fragment Messages for the exchange.  Next actions
   depend on the role of receiver in the exchange.

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

   o  The Responder in this case acts as if no request message was
      received.  The reassembling timeout for Responder is RECOMMENDED
      to be equal to the fragmented request Message (in case time interval that implementation waits before
      completely giving up when acting as Initiator of Initiator) or
   deems Exchange to have failed.  If Exchange is abandoned, all
   received so far IKE Fragment Messages exchange.
      Section 2.4 of [IKEv2] gives recommendations for that Exchange MUST be
   discarded. selecting this
      interval.  Implementation MAY use shorter timeout to conserve
      memory.

2.6.1.  Changes in  Replay Protection Logic Detection and Retransmissions

   According to [RFC5996] IKEv2 MUST [IKEv2] implementation must reject message with the same
   Message ID as it has seen before (taking into consideration Response
   bit).  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: if message contains Encrypted
   Fragment Payload, the values of Fragment Number and Total Fragments
   fields from this payload MUST be used along with Message ID to detect
   retransmissions and replays.

   If Responder receives IKE Fragment Message after it received,
   successfully verified and processed regular message with the same
   Message ID, it means that response message didn't reach Initiator and
   it activated IKE Fragmentation.  If Fragment Number in Encrypted
   Fragment Payload in this message is equal to 1, Responder MUST
   fragment its response and retransmit it back to Initiator in
   fragmented form.

   If Responder receives a replay IKE Fragment Message for already
   reassembled, verified and processed fragmented message, it MUST
   retransmit response back to Initiator, but only if Fragment Number
   field in Encrypted Fragment Payload is equal to 1 and MUST silently
   discard received message otherwise.  If Total Fragments field in
   received IKE Fragment Message is greater than in IKE Fragment
   Messages that already processed fragmented message was reassembled
   from, Responder MAY refragment its response message using smaller
   fragmentation threshold before resending it back to Initiator.  In has already been updated by [RFC6311], which
   deliberately allows any number of messages with zero Message ID.
   This document also updates this case Total Fragments field in new logic for the situations, when IKE Fragment Messages MUST be
   greater than
   Fragmentation is in previously sent IKE Fragment Messages. use.

   If Initiator doesn't receive any incomimg message contains Encrypted Fragment Payload, the values
   of response IKE Fragment Messages
   within a timeout interval, it MAY refragment request Message using
   smaller fragmentation threshold before retransmitting it (see
   Section 2.5.1).  In this case Number and Total Fragments field in new IKE
   Fragment Messages fields MUST be greater than in previously sent IKE
   Fragment Messages.  Alternatively, if Initiator does receive some
   (but not all) used along with
   Message ID to detect retransmissions and replays.

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

3.  Interaction with other IKE extensions

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

   When IKE Fragmentation is used with IKE Session Resumption [RFC5723],
   ([RFC5723]), messages of IKE_SESSION_RESUME Exchange cannot be
   fragmented as since they
   don't do not contain Encrypted Payload.  These
   messages may be large due to the ticket size.  If this is the case the described solution won't help.  To avoid IP
   Fragmentation in this situation it is recommended to use smaller
   tickets, e.g. by utilizing "ticket by reference" approach instead of
   "ticket by value".

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

4.  Transport Considerations

   With IKE Fragmentation if any single IKE Fragment Message get lost,
   receiver becomes unable to reassemble original Message.  So, in
   general, using IKE Fragmentation implies higher probability for the
   Message 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
   implementations MAY use longer timeouts and do more retransmits than
   usual before considering peer dead.

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

5.  Security Considerations

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

   Security Considerations Section of [RFC5996] [IKEv2] mentions possible attack
   on IKE by exhausting of the IP reassembly buffers.  The mechanism,
   described in this document, allows IKE to avoid IP-fragmentation IP fragmentation and
   therefore increases its robustness to DoS attacks.

   The following attack is possible with IKE Fragmentation.  An attacker
   can initiate IKE_SA_INIT exchange, Exchange, complete it, compute SK_a and SK_e
   and then send a large, but still incomplete, set of IKE_AUTH
   fragments.  These fragments will pass the ICV check and will be
   stored in reassembly buffers, but as 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
   receiver limits the number of fragments it stores in reassembling
   queue so that the sum of the sizes of Encrypted Fragment Payload
   contents (after decryption) for fragments that are already placed
   into the reassembling queue be 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 attack or as 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 depending on receiver's memory load.  In any
   case, the value SHOULD NOT exceed 64 Kbytes (the maximum size of UDP
   datagram) because any IKE message before fragmentation must be
   shorter than that.

6.  IANA Considerations

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

     <TBA>       Encrypted and Authenticated Fragment      SKF

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

     <TBA>       IKEV2_FRAGMENTATION_SUPPORTED

7.  Acknowledgements

   The author would like to thank Tero Kivinen, Yoav Nir, Paul Wouters,
   Yaron Sheffer, Joe Touch, Derek Atkins 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.  Normative References

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

   [RFC5996]

   [IKEv2]    Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, P., and T.
              Kivinen, "Internet Key Exchange Protocol Version 2
              (IKEv2)",
              RFC 5996, September 2010. draft-kivinen-ipsecme-ikev2-rfc5996bis-03 (work
              in progress), April 2014.

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

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              September 1981.

   [RFC1191]  Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
              November 1990.

   [RFC1981]  McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
              for IP version 6", RFC 1981, August 1996.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC4787]  Audet, F. and C. Jennings, "Network Address Translation
              (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
              RFC 4787, January 2007.

   [RFC4821]  Mathis, M. and J. Heffner, "Packetization Layer Path MTU
              Discovery", RFC 4821, March 2007.

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

   [RFC5405]  Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines
              for Application Designers", BCP 145, RFC 5405,
              November 2008.

   [RFC5723]  Sheffer, Y. and H. Tschofenig, "Internet Key Exchange
              Protocol Version 2 (IKEv2) Session Resumption", RFC 5723,
              January 2010.

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

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

   [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 in
              progress), 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/
              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

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

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

Appendix B.  Correlation between IP Datagram size and Encrypted Payload
             content size

   For IPv4 Encrypted Payload content size is less than IP 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 marker size (4 bytes if present)

   o  IKE Header size (28 bytes)

   o  Encrypted Payload header size (4 bytes)

   o  IV size (varying)

   o  padding and its size (at least 1 byte)

   o  ICV size (varying)

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

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

   o  IPv6 header size (40 bytes)

   o  IPv6 extension headers (optional, size varies)

   o  UDP header size (8 bytes)

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

   o  IKE Header size (28 bytes)

   o  Encrypted Payload header size (4 bytes)

   o  IV size (varying)

   o  padding and its size (at least 1 byte)

   o  ICV size (varying)

   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 except for the fragment header
   which is always 8 bytes in length.

Author's Address

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

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