--- 1/draft-ietf-ipsecme-ikev2-fragmentation-03.txt 2013-10-18 06:14:33.483884781 -0700 +++ 2/draft-ietf-ipsecme-ikev2-fragmentation-04.txt 2013-10-18 06:14:33.519885691 -0700 @@ -1,18 +1,18 @@ Network Working Group V. Smyslov Internet-Draft ELVIS-PLUS -Intended status: Standards Track October 4, 2013 -Expires: April 7, 2014 +Intended status: Standards Track October 18, 2013 +Expires: April 21, 2014 IKEv2 Fragmentation - draft-ietf-ipsecme-ikev2-fragmentation-03 + draft-ietf-ipsecme-ikev2-fragmentation-04 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 April 7, 2014. + This Internet-Draft will expire on April 21, 2014. Copyright Notice Copyright (c) 2013 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 @@ -48,37 +48,38 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 2. Protocol details . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Negotiation . . . . . . . . . . . . . . . . . . . . . . . 4 2.4. Using IKE Fragmentation . . . . . . . . . . . . . . . . . 5 2.5. Fragmenting Message . . . . . . . . . . . . . . . . . . . 6 - 2.5.1. Selecting Fragment Size . . . . . . . . . . . . . . . 7 - 2.5.2. Fragmenting Messages containing unencrypted - Payloads . . . . . . . . . . . . . . . . . . . . . . . 8 - 2.6. Receiving IKE Fragment Message . . . . . . . . . . . . . . 9 - 2.6.1. Changes in Replay Protection Logic . . . . . . . . . . 10 - 3. Interaction with other IKE extensions . . . . . . . . . . . . 12 - 4. Transport Considerations . . . . . . . . . . . . . . . . . . . 13 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 - 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 - 8.2. Informative References . . . . . . . . . . . . . . . . . . 17 - Appendix A. Design rationale . . . . . . . . . . . . . . . . . . 18 + 2.5.1. Selecting Fragment Size . . . . . . . . . . . . . . . 8 + 2.5.2. PMTU Discovery . . . . . . . . . . . . . . . . . . . . 8 + 2.5.3. Fragmenting Messages containing unencrypted + Payloads . . . . . . . . . . . . . . . . . . . . . . . 9 + 2.6. Receiving IKE Fragment Message . . . . . . . . . . . . . . 10 + 2.6.1. Changes in Replay Protection Logic . . . . . . . . . . 11 + 3. Interaction with other IKE extensions . . . . . . . . . . . . 13 + 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 . . . . . . . . . . . . . . . . . . 19 Appendix B. Correlation between IP Datagram size and - Encrypted Payload content size . . . . . . . . . . . 19 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 + Encrypted Payload content size . . . . . . . . . . . 20 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21 1. Introduction The Internet Key Exchange Protocol version 2 (IKEv2), specified in [RFC5996], uses UDP as a transport for its messages. 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 allow IP fragments to pass through. This apparently blocks IKE communication and, therefore, prevents peers from establishing IPsec SA. @@ -164,49 +165,67 @@ 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. This Notification contains no data. 2.4. Using IKE Fragmentation - 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 unfragmented message and - resend it fragmented only if it didn't receive response after several - retransmissions, or it may always send messages fragmented (but see - Section 3), or it may fragment only large messages and messages - causing large responses. + 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 + unfragmented message and resend it fragmented only if it didn't + receive response after several retransmissions, or it may always send + messages fragmented (but see Section 3), or it may fragment only + large messages and messages causing large responses. - In general the following guidelines are applicable: + In general the following guidelines are applicable for initiator: - o Initiator MAY fragment outgoing message if it suspects that either - request or response message may be fragmented by IP level. + o Initiator MAY fragment outgoing message if it has some knowledge + (possibly from lower layer or from configuration) or suspicions + that either request or response message will be fragmented by IP + level. - o Initiator SHOULD fragment outgoing message if it suspects that - either request or response message may be fragmented by IP level - and IKE Fragmentation was already used in one of previous - Exchanges in the context of the current IKE SA. + o Initiator SHOULD fragment outgoing message if it has some + knowledge (possibly from lower layer or from configuration) or + suspicions that either request or response message will be + fragmented by IP level and IKE Fragmentation was already used in + one of previous Exchanges in the context of the current IKE SA. o Initiator SHOULD NOT fragment outgoing message if both request and response messages of the Exchange are small enough not to cause fragmentation on IP level (for example, there is no point in fragmenting Liveness Check messages). - Responder MUST send response message in the same form (fragmented or - not) as corresponded request message. If it received unfragmented - request message, responded with unfragmented response message and - then received fragmented retransmission of the same request, it MUST - resend its response back to Initiator fragmented. + In general the following guidelines are applicable for responder: + + o Responder SHOULD send response message 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 message with fragmented + response if it has some knowledge (possibly from lower layer or + from configuration) or suspicions that response message will be + fragmented by IP level. + + o Responder MAY respond to fragmented message with unfragmented + response if the size of the response message is less than the + smallest fragmentation threshold, supported by Responder (for + example, there is no point in fragmenting Liveness Check + messages). 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 @@ -242,38 +262,39 @@ o Next Payload (1 octet) - in the very first fragment 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. + was divided into. 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]. When prepending IKE Header, Length field MUST be adjusted to reflect the length of constructed message and Next Payload field MUST reflect payload type of the first Payload in the constructed message (that in most cases 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 Payloads that precedes Encrypted Payload in original message (see - Section 2.5.2), the resulting messages are sent to the peer. + 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 @@ -296,31 +317,46 @@ 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 using several values of fragmentation threshold, provided that it starts with larger values and fragments message again with next smaller value if it doesn't receive response in a reasonable time after several retransmissions. - In this case using next smaller value MUST result in increasing Total - Fragments field. - See Appendix B for correlation between IP Datagram size and Encrypted - Payload content size. + In case of PMTU discovery Total Fragments field is used to + distinguish between different sets of fragments, i.e. the sets that + were obtained by fragmenting original message using different + fragmentation thresholds. As sender will start from larger fragments + and then make them smaller, the value in Total Fragments field will + increase with each new try. When selecting next smaller value of + fragmentation threshold, sender MUST ensure that the value in Total + Fragments field is really increased. This requirement should not + become a problem for the sender, as PMTU discovery in IKE is supposed + to be coarse-grained, so difference between previous and next + fragmentation thresholds will be significant anyway. The necessity + to distinguish between the sets is vital for receiver as receiving + any valid fragment from newer set will mean that it have to start + reassembling over and not to mix fragments from different sets. -2.5.2. Fragmenting Messages containing unencrypted Payloads +2.5.3. Fragmenting Messages containing unencrypted Payloads Currently no one of IKEv2 Exchanges defines messages, containing both unencrypted payloads and payloads, protected by Encrypted Payload. But IKEv2 doesn't forbid such messages. If some future IKEv2 extension defines such a message and it needs to be fragmented, all unprotected payloads MUST be in the first fragment, along with Encrypted Fragment Payload, which MUST be present in any IKE Fragment Message. Below is an example of fragmenting message, containing both encrypted @@ -344,35 +380,47 @@ to accommodate unprotected Payloads. In extreme cases Encrypted Fragment Payload will contain no data, but it is still MUST be present in the message, because only its presence allows receiver to distinguish IKE Fragment Message from regular IKE message. 2.6. Receiving IKE Fragment Message Receiver identifies IKE Fragment Message by the presence of Encrypted Fragment Payload in it. Note, that it is possible for this payload to be not the first (and the only) payload in the message (see - Section 2.5.2). But for all currently defined IKEv2 exchanges this + Section 2.5.3). But for all currently defined IKEv2 exchanges this payload will be the first and the only payload in the message. 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. If not - message MUST be silently discarded. + 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, that have already received + + If either 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 already received and successfully processed, this message is considered a - replay and MUST be discarded. + 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 finished yet and Total Fragments field in received IKE Fragment Message is greater than this field in previously received fragments, receiver MUST discard all received fragments and start reassembling over with just received IKE Fragment Message.