--- 1/draft-ietf-ipsecme-ikev2-fragmentation-08.txt 2014-06-06 07:14:25.975363547 -0700 +++ 2/draft-ietf-ipsecme-ikev2-fragmentation-09.txt 2014-06-06 07:14:26.019364626 -0700 @@ -1,18 +1,18 @@ Network Working Group V. Smyslov Internet-Draft ELVIS-PLUS -Intended status: Standards Track May 23, 2014 -Expires: November 24, 2014 +Intended status: Standards Track June 6, 2014 +Expires: December 8, 2014 IKEv2 Fragmentation - draft-ietf-ipsecme-ikev2-fragmentation-08 + draft-ietf-ipsecme-ikev2-fragmentation-09 Abstract This document describes the way to avoid IP fragmentation of large IKEv2 messages. This allows IKEv2 messages to traverse network devices that do not 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 November 24, 2014. + This Internet-Draft will expire on December 8, 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 @@ -77,21 +77,21 @@ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25 1. Introduction 1.1. Problem description The Internet Key Exchange Protocol version 2 (IKEv2), specified in [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, which requires fairly - large messages, up to several kbytes, especially when certificates + 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, 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] describes requirements for CGNs. It states, @@ -119,25 +119,25 @@ 1.2. Proposed solution The solution to the problem described in this document is to perform fragmentation of large messages by 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. The primary goal of this solution is to allow IKEv2 to operate in - environments, that may 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 this solution - could be used to avoid IP fragmentation in all situations where - fragmentation within IKE is applicable, as it is recommended in + 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 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 fragmentation within IKE similarly to the solution described in this document. 1.3. Conventions Used in This Document @@ -155,21 +155,21 @@ 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. See Appendix A for design rationale. 2.2. Limitations 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 + message can be fragmented if and only if it contains an Encrypted Payload. This implies that messages of the IKE_SA_INIT Exchange cannot be fragmented. In most 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.) these messages may become fairly large and get fragmented by IP level. In this case the described solution will not help. @@ -180,21 +180,21 @@ 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 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 indicates its support for the IKE Fragmentation and + The Initiator 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)] --> @@ -216,39 +216,39 @@ 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 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 that it is up to the the - Initiator of each exchange to decide whether to use it or not. The - Responder usually replies in the same form as the request message, - but other considerations might override this. + indicated their support for it. After that it is up to the Initiator + of each exchange to decide whether or not to use it. The Responder + usually replies in 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 no complete response is received even - after several retransmissions. Alternatively, it may choose always - to send fragmented messages (but see Section 3), or it may fragment - only large messages and messages that are expected to result in large - responses. + The Initiator can employ various policies regarding the use of IKE + 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 send fragmented messages (but 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. This - information may be passed from a lower layer, provided by + 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, and receiving repeated retransmissions of the request for the Responder. o If either peer knows that IKE Fragmentation has been used in a previous exchange in the context of the current IKE 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). @@ -261,31 +261,32 @@ o If none of the above apply, the Responder SHOULD respond in the same form (fragmented or not) as the request message it is responding to. Note that the other guidelines might override this because of information or heuristics available to the Responder. In most cases IKE Fragmentation will be used in 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 [IKEv2], as well as documents updating it for - particular algorithms or modes, such as [RFC5282]. + Only messages that contain an Encrypted Payload are subject for IKE + Fragmentation. For the purpose of IKE Fragment Messages construction + original (unencrypted) content of the 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 the Encrypted Fragment Payload and + is then encrypted and authenticated. Thus, the Encrypted Fragment + Payload contains a chunk of the original content of the Encrypted + Payload in encrypted form. The cryptographic processing of the + Encrypted Fragment Payload is identical to Section 3.14 of [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 @@ -344,109 +345,109 @@ 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 choose their size so, that resulting IP Datagrams be smaller than - some fragmentation threshold. Implementation may calculate + some fragmentation threshold. Implementations may calculate fragmentation threshold using various sources of information. - If sender has information about PMTU size it SHOULD use it. The + If the Sender has information about PMTU size it SHOULD use it. The Responder in the 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. + may reduce these values. Implementations may use other values if + they are appropriate in current environment. - According to [RFC0791] the minimum IPv4 datagram size that is + 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 + assume the value 576 bytes as a safe low limit for IP Datagrams size (Syslog, DNS, etc.). See Appendix B for correlation between IP Datagram size and Encrypted Payload content size. 2.5.2. PMTU Discovery The amount of traffic that IKE endpoint produces during lifetime of IKE SA is fairly modest - usually it is below one hundred kBytes within a period of several hours. Most of this traffic consists of relatively short messages - usually below several hundred bytes. In most cases the only time when IKE endpoints exchange messages of several kBytes in size is IKE SA establishment and often each endpoint sends exactly one such message. - For the reasons atriculated above implementing PMTU discovery in IKE + For the reasons articulated above implementing PMTU discovery in IKE is OPTIONAL. It is believed that using the values recommended in Section 2.5.1 as 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. - Implementation may support PMTU discovery if there are good reasons + Implementations may support PMTU discovery if there are good reasons to do it (for example if it is intended to be used in environments where MTU size is possible to be less that values listed in Section 2.5.1). PMTU discovery in IKE follows recommendations given in Section 10.4 of [RFC4821] with the difference, induced by the specialties 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 IKE SA is being established and in many cases there is only one such message. If the probing were performed 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 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 + Implementations 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 + IKE operations too much. Performing 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 + value for the fragmentation threshold an 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 + If an implementation is capable to receive ICMP error messages it can 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 is used to distinguish between different sets of fragments, i.e. the sets that @@ -492,44 +493,45 @@ should not exceed fragmentation threshold, including the 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 case Encrypted Fragment Payload will contain no data, but it still must be present in the message, because only its presence allows receiver to determine that sender have used IKE Fragmentation. 2.6. Receiving IKE Fragment Message - Receiver identifies IKE Fragment Message by the presence of Encrypted - Fragment Payload in it. In most cases it will be the first and the - only payload in the message, however this may not be true for some - hypothetical IKE exchanges (see Section 2.5.3) + The Receiver identifies the IKE Fragment Message by the presence of + an Encrypted Fragment Payload in it. In most cases it will be the + first and the only payload in the 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 + Upon receiving the 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. + o Check message validity - in particular, check whether the values + in the Fragment Number and the Total Fragments fields in the + 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 the Fragment Number and the Total Fragments fields + contain non-zero values - * check that Fragment Number field is less than or equal to Total - Fragments field + * 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 Total Fragments - field is equal to or greater than Total Fragments field in - fragments that have already been stored in the reassembling - queue + * if reassembling has already started, check that the value in + the Total Fragments field is equal to or greater than Total + Fragments field in the fragments that have already been stored + in the reassembling queue - If any of this tests fails message MUST be silently discarded. + If any of this tests fails the 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 is already 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. @@ -537,56 +539,57 @@ o If reassembling is not finished yet and Total Fragments field in received fragment is greater than this field in 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 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 all Encrypted Fragment + field) are received, the decrypted content of all Encrypted Fragment Payloads is merged together to form content of original Encrypted Payload, and, therefore, along with IKE Header and unprotected Payloads (if any), original message. Then it is processed as if it was received, verified and decrypted as regular IKE message. - If receiver does not get all IKE fragments needed to reassemble - original Message within a timeout interval, it MUST discard all - received so far IKE Fragment Messages for the exchange. Next actions + If receiver does not get all IKE fragments needed to reassemble the + original Message within a timeout interval, it MUST discard all IKE + Fragment Messages received so far for the exchange. The 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 time interval that implementation waits before - completely giving up when acting as Initiator of exchange. - Section 2.4 of [IKEv2] gives recommendations for selecting this - interval. Implementation MAY use shorter timeout to conserve - memory. + received. It would delete any memory of the incomplete request + message, and not treat it as an IKE SA failure. The reassembling + timeout for the Responder is RECOMMENDED to be equal to the time + interval that the implementation waits before completely giving up + when acting as Initiator of exchange. Section 2.4 of [IKEv2] + 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] 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 for the situations, when IKE - Fragmentation is in use. + According to [IKEv2] implementations 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 for the situations, when + IKE Fragmentation is in use. - If incomimg message contains Encrypted Fragment Payload, the values + If incoming message contains Encrypted Fragment Payload, the values of Fragment Number and Total Fragments fields MUST be used along with Message ID to detect retransmissions and replays. If Responder receives retransmitted fragment of request when it has already processed that request and has sent back a response, that event MUST only trigger retransmission of the response message (fragmented or not) if Fragment Number field in received fragment is set to 1 and MUST be ignored otherwise. 3. Interaction with other IKE extensions @@ -653,32 +656,34 @@ 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 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 + 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 + 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. + calculated dynamically depending on the receiver's memory load. Some + care should be taken when selecting this value because, if it is too + small, it might prevent legitimate peer to establish IKE SA if the + size of messages it sends exceeds this value. It is NOT RECOMMENDED + for this value to exceed 64 Kbytes because any IKE message before + fragmentation would likely be shorter than that. 6. IANA Considerations This document defines new Payload in the "IKEv2 Payload Types" registry: Encrypted and Authenticated Fragment SKF This document also defines new Notify Message Types in the "Notify Message Types - Status Types" registry: