--- 1/draft-ietf-ipsecme-ikev2-fragmentation-05.txt 2014-03-13 22:14:34.872188994 -0700 +++ 2/draft-ietf-ipsecme-ikev2-fragmentation-06.txt 2014-03-13 22:14:34.912189968 -0700 @@ -1,18 +1,18 @@ Network Working Group V. Smyslov Internet-Draft ELVIS-PLUS -Intended status: Standards Track November 3, 2013 -Expires: May 7, 2014 +Intended status: Standards Track March 14, 2014 +Expires: September 15, 2014 IKEv2 Fragmentation - draft-ietf-ipsecme-ikev2-fragmentation-05 + draft-ietf-ipsecme-ikev2-fragmentation-06 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,25 +21,25 @@ 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 May 5, 2014. + This Internet-Draft will expire on September 15, 2014. Copyright Notice - Copyright (c) 2013 IETF Trust and the persons identified as the + 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 @@ -65,21 +65,21 @@ 4. Transport Considerations . . . . . . . . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 8.2. Informative References . . . . . . . . . . . . . . . . . . 18 Appendix A. Design rationale . . . . . . . . . . . . . . . . . . 20 Appendix B. Correlation between IP Datagram size and Encrypted Payload content size . . . . . . . . . . . 21 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction The Internet Key Exchange Protocol version 2 (IKEv2), specified in [RFC5996], 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, 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, @@ -152,48 +152,48 @@ employed. According to [RFC0791] the minimum IP 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 its support for IKE Fragmentation and willingness to use it by including Notification Payload of type - IKE_FRAGMENTATION_SUPPORTED in IKE_SA_INIT request message. If + 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(IKE_FRAGMENTATION_SUPPORTED)] --> + [N(IKEV2_FRAGMENTATION_SUPPORTED)] --> <-- HDR, SAr1, KEr, Nr, [CERTREQ], - [N(IKE_FRAGMENTATION_SUPPORTED)] + [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 IKE_FRAGMENTATION_SUPPORTED by IANA. + for IKEV2_FRAGMENTATION_SUPPORTED by IANA. This Notification contains no data. 2.4. Using IKE Fragmentation IKE Fragmentation MUST NOT be used unless both peers indicated their support for it. After IKE Fragmentation is negotiated, it is up to Initiator of each Exchange, whether to use it or not. In most cases IKE Fragmentation will be used in IKE_AUTH Exchange, especially if certificates are employed. Initiator may first try to send @@ -251,21 +251,22 @@ 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], 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). + 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -353,41 +355,41 @@ Initiator MAY try to discover path MTU by probing several values of fragmentation threshold. While doing probes, node MUST start from larger values and refragment message with next smaller value if it doesn't receive response in a reasonable time after several retransmissions. This time is supposed to be 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 the smallest allowed value for fragmentation threshold implementation MUST continue probing using it - untill either exchange completes ot times out. + until either exchange completes or times out. 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 possible IKE SA establishment delay. In a corner case, when host will use only one value, PMTU discovery will effectively be disabled. In most cases PMTU discovery will not be needed, as using values, recommended in section Section 2.5.1, should suffice. It is expected, that PMTU discovery may be useful in environments where PMTU size are smaller, than those listed in Section 2.5.1, for example due to the presence of intermediate tunnels. PMTU discovery in IKE follows recommendations, given in Section 10.4 of RFC4821 [RFC4821] with some differences, induced by the - specialities of IKE. In particular: + specialties of IKE. In particular: o Unlike classical PMTUD [RFC1191] and PLMTUD [RFC4821] the goal of Path MTU discovery in IKE is not to find the largest size of IP packet, that will not be fragmented en route, but to find any - reasonal size, probably far from optimal. + reasonable size, probably far from optimal. o There 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 IKE usually sends large messages only in IKE_AUTH exchange, i.e. once per IKE SA. Most of other messages will have size below several hundred bytes. Performing full PMTUD for sending exactly one large message is inefficient. @@ -486,26 +488,28 @@ arrive. When all IKE Fragment Messages (as indicated in the Total Fragments field) are received, content of their already decrypted Encrypted Fragment Payloads is merged together to form content of original Encrypted Payload, and, therefore, along with IKE Header and unencrypted Payloads (if any), original message. Then it is processed as if it was received, verified and decrypted as regular unfragmented message. - If receiver does't get all IKE Fragment Messages needed to reassemble - original Message for some Exchange within a timeout interval, it acts - according with Section 2.1 of [RFC5996], i.e. retransmits the - fragmented request Message (in case of Initiator) or deems Exchange - to have failed. If Exchange is abandoned, all received so far IKE - Fragment Messages for that Exchange MUST be discarded. + If receiver doesn't get all IKE Fragment Messages needed to + reassemble original Message for some Exchange within a timeout + interval, it acts according with Section 2.1 of [RFC5996], i.e. + + retransmits the fragmented request Message (in case of Initiator) or + deems Exchange to have failed. If Exchange is abandoned, all + received so far IKE Fragment Messages for that Exchange MUST be + discarded. 2.6.1. Changes in Replay Protection Logic According to [RFC5996] IKEv2 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 @@ -525,21 +529,21 @@ 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 this case Total Fragments field in new IKE Fragment Messages MUST be greater than in previously sent IKE Fragment Messages. If Initiator doesn't receive any of response IKE Fragment Messages - withing a timeout interval, it MAY refragment request Message using + within a timeout interval, it MAY refragment request Message using smaller fragmentation threshold before retransmitting it (see Section 2.5.1). In this case Total Fragments field in new IKE Fragment Messages MUST be greater than in previously sent IKE Fragment Messages. Alternatively, if Initiator does receive some (but not all) of response IKE Fragment Messages, it MAY retransmit only the first of request IKE Fragment Messages, where Fragment Number field is equal to 1. 3. Interaction with other IKE extensions @@ -597,31 +601,32 @@ 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. 6. IANA Considerations This document defines new Payload in the "IKEv2 Payload Types" registry: - Encrypted Fragment Payload SKF + Encrypted and Authenticated Fragment SKF This document also defines new Notify Message Types in the "Notify - Messages Types - Status Types" registry: + Message Types - Status Types" registry: - IKE_FRAGMENTATION_SUPPORTED + IKEV2_FRAGMENTATION_SUPPORTED 7. Acknowledgements The author would like to thank Tero Kivinen, Yoav Nir, Paul Wouters, - Yaron Sheffer and others for their reviews and valueable comments. + Yaron Sheffer, Joe Touch 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)", @@ -670,33 +675,33 @@ 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 looking valid fragments + attacker could infrequently emit forged but valid looking fragments into the network, and some of these fragments would be fetched by - receiver into the reassempling queue. Receiver could not distinguish + 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 forgeg fragments and - not to fetch them into the reassempling queue. + 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) @@ -709,23 +714,48 @@ 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 this estimation is difficult as there may be varying IPv6 - Extension headers included. + 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 - RU + Russian Federation Phone: +7 495 276 0211 Email: svan@elvis.ru