--- 1/draft-ietf-ipsecme-ikev2-fragmentation-06.txt	2014-04-04 09:14:35.575912126 -0700
+++ 2/draft-ietf-ipsecme-ikev2-fragmentation-07.txt	2014-04-04 09:14:35.615913108 -0700
@@ -1,18 +1,18 @@
 
 Network Working Group                                         V. Smyslov
 Internet-Draft                                                ELVIS-PLUS
-Intended status: Standards Track                          March 14, 2014
-Expires: September 15, 2014
+Intended status: Standards Track                           April 4, 2014
+Expires: October 6, 2014
 
                           IKEv2 Fragmentation
-               draft-ietf-ipsecme-ikev2-fragmentation-06
+               draft-ietf-ipsecme-ikev2-fragmentation-07
 
 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 allow IP fragments to pass through.
 
 Status of this Memo
 
    This Internet-Draft is submitted in full conformance with the
@@ -21,21 +21,21 @@
    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 September 15, 2014.
+   This Internet-Draft will expire on October 6, 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
@@ -596,37 +596,63 @@
    same as those for base IKEv2 protocol described in [RFC5996].  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] mentions possible attack
    on IKE by exhausting of the IP reassembly buffers.  The mechanism,
    described in this document, allows IKE to avoid 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, 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 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 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 and others for their reviews and valuable
-   comments.
+   Yaron Sheffer, Joe Touch, Derek Atkins and others for their reviews
+   and valuable comments.
 
 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]  Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
               "Internet Key Exchange Protocol Version 2 (IKEv2)",