idnits 2.17.1 draft-ietf-ipsecme-ikev2-fragmentation-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (June 6, 2014) is 3604 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'CERTREQ' is mentioned on line 201, but not defined == Outdated reference: A later version (-04) exists of draft-kivinen-ipsecme-ikev2-rfc5996bis-03 -- Possible downref: Normative reference to a draft: ref. 'IKEv2' -- Obsolete informational reference (is this intentional?): RFC 1981 (Obsoleted by RFC 8201) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 5405 (Obsoleted by RFC 8085) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group V. Smyslov 3 Internet-Draft ELVIS-PLUS 4 Intended status: Standards Track June 6, 2014 5 Expires: December 8, 2014 7 IKEv2 Fragmentation 8 draft-ietf-ipsecme-ikev2-fragmentation-09 10 Abstract 12 This document describes the way to avoid IP fragmentation of large 13 IKEv2 messages. This allows IKEv2 messages to traverse network 14 devices that do not allow IP fragments to pass through. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on December 8, 2014. 33 Copyright Notice 35 Copyright (c) 2014 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1. Problem description . . . . . . . . . . . . . . . . . . . 3 52 1.2. Proposed solution . . . . . . . . . . . . . . . . . . . . 3 53 1.3. Conventions Used in This Document . . . . . . . . . . . . 4 54 2. Protocol details . . . . . . . . . . . . . . . . . . . . . . . 5 55 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 2.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . 5 57 2.3. Negotiation . . . . . . . . . . . . . . . . . . . . . . . 5 58 2.4. Using IKE Fragmentation . . . . . . . . . . . . . . . . . 6 59 2.5. Fragmenting Message . . . . . . . . . . . . . . . . . . . 7 60 2.5.1. Selecting Fragment Size . . . . . . . . . . . . . . . 9 61 2.5.2. PMTU Discovery . . . . . . . . . . . . . . . . . . . . 10 62 2.5.3. Fragmenting Messages containing unprotected 63 Payloads . . . . . . . . . . . . . . . . . . . . . . . 11 64 2.6. Receiving IKE Fragment Message . . . . . . . . . . . . . . 12 65 2.6.1. Replay Detection and Retransmissions . . . . . . . . . 14 66 3. Interaction with other IKE extensions . . . . . . . . . . . . 15 67 4. Transport Considerations . . . . . . . . . . . . . . . . . . . 16 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 70 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 72 8.1. Normative References . . . . . . . . . . . . . . . . . . . 20 73 8.2. Informative References . . . . . . . . . . . . . . . . . . 20 74 Appendix A. Design rationale . . . . . . . . . . . . . . . . . . 22 75 Appendix B. Correlation between IP Datagram size and 76 Encrypted Payload content size . . . . . . . . . . . 23 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25 79 1. Introduction 81 1.1. Problem description 83 The Internet Key Exchange Protocol version 2 (IKEv2), specified in 84 [IKEv2], uses UDP as a transport for its messages. Most IKEv2 85 messages are relatively small, usually below several hundred bytes. 86 Noticeable exception is IKE_AUTH Exchange, which requires fairly 87 large messages, up to several kBytes, especially when certificates 88 are transferred. When IKE message size exceeds path MTU, it gets 89 fragmented by IP level. The problem is that some network devices, 90 specifically some NAT boxes, do not allow IP fragments to pass 91 through. This apparently blocks IKE communication and, therefore, 92 prevents peers from establishing IPsec SA. Section 2 of [IKEv2] 93 discusses the impact of IP fragmentation on IKEv2 and acknowledges 94 this problem. 96 Widespread deployment of Carrier-Grade NATs (CGN) introduces new 97 challenges. [RFC6888] describes requirements for CGNs. It states, 98 that CGNs must comply with Section 11 of [RFC4787], which requires 99 NAT to support receiving IP fragments (REQ-14). In real life 100 fulfillment of this requirement creates an additional burden in terms 101 of memory, especially for high-capacity devices, used in CGNs. It 102 was found by people deploying IKE, that more and more ISPs use 103 equipment that drop IP fragments, violating this requirement. 105 Security researchers have found and continue to find attack vectors 106 that rely on IP fragmentation. For these reasons, and also 107 articulated in [FRAGDROP], many network operators filter all IPv6 108 fragments. Also, the default behavior of many currently deployed 109 firewalls is to discard IPv6 fragments. 111 In one recent study [BLACKHOLES], two researchers utilized a 112 measurement network to measure fragment filtering. They sent 113 packets, fragmented to the minimum MTU of 1280, to 502 IPv6 enabled 114 and reachable probes. They found that during any given trial period, 115 ten percent of the probes did not receive fragmented packets. 117 Thus this problem is valid for both IPv4 and IPv6 and may be caused 118 either by deficiency of network devices or by operational choice. 120 1.2. Proposed solution 122 The solution to the problem described in this document is to perform 123 fragmentation of large messages by IKEv2 itself, replacing them by 124 series of smaller messages. In this case the resulting IP Datagrams 125 will be small enough so that no fragmentation on IP level will take 126 place. 128 The primary goal of this solution is to allow IKEv2 to operate in 129 environments, that might block IP fragments. This goal does not 130 assume that IP fragmentation should be avoided completely, but only 131 in those cases when it interferes with IKE operations. However this 132 solution could be used to avoid IP fragmentation in all situations 133 where fragmentation within IKE is applicable, as it is recommended in 134 Section 3.2 of [RFC5405]. Avoiding IP fragmentation would be 135 beneficial for IKEv2 in general. Security Considerations Section of 136 [IKEv2] mentions exhausting of the IP reassembly buffers as one of 137 the possible attacks on the protocol. In the paper [DOSUDPPROT] 138 several aspects of attacks on IKE using IP fragmentation are 139 discussed, and one of the defenses it proposes is to perform 140 fragmentation within IKE similarly to the solution described in this 141 document. 143 1.3. Conventions Used in This Document 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in [RFC2119]. 149 2. Protocol details 151 2.1. Overview 153 The idea of the protocol is to split large IKEv2 message into a set 154 of smaller ones, called IKE Fragment Messages. Fragmentation takes 155 place before the original message is encrypted and authenticated, so 156 that each IKE Fragment Message receives individual protection. On 157 the receiving side IKE Fragment Messages are collected, verified, 158 decrypted and merged together to get the original message before 159 encryption. See Appendix A for design rationale. 161 2.2. Limitations 163 Since IKE Fragment Messages are cryptographically protected, SK_a and 164 SK_e must already be calculated. In general, it means that original 165 message can be fragmented if and only if it contains an Encrypted 166 Payload. 168 This implies that messages of the IKE_SA_INIT Exchange cannot be 169 fragmented. In most cases this is not a problem because IKE_SA_INIT 170 messages are usually small enough to avoid IP fragmentation. But in 171 some cases (advertising a badly structured long list of algorithms, 172 using large MODP Groups, etc.) these messages may become fairly large 173 and get fragmented by IP level. In this case the described solution 174 will not help. 176 Among existing IKEv2 extensions, messages of IKE_SESSION_RESUME 177 Exchange, defined in [RFC5723], cannot be fragmented either. See 178 Section 3 for details. 180 Another limitation is that the minimal size of IP Datagram bearing 181 IKE Fragment Message is about 100 bytes depending on the algorithms 182 employed. According to [RFC0791] the minimum IPv4 Datagram size that 183 is guaranteed not to be further fragmented is 68 bytes. So, even the 184 smallest IKE Fragment Messages could be fragmented by IP level in 185 some circumstances. But such extremely small PMTU sizes are very 186 rare in real life. 188 2.3. Negotiation 190 The Initiator indicates its support for the IKE Fragmentation and 191 willingness to use it by including Notification Payload of type 192 IKEV2_FRAGMENTATION_SUPPORTED in IKE_SA_INIT request message. If 193 Responder also supports this extension and is willing to use it, it 194 includes this notification in response message. 196 Initiator Responder 197 ----------- ----------- 198 HDR, SAi1, KEi, Ni, 199 [N(IKEV2_FRAGMENTATION_SUPPORTED)] --> 201 <-- HDR, SAr1, KEr, Nr, [CERTREQ], 202 [N(IKEV2_FRAGMENTATION_SUPPORTED)] 204 The Notify payload is formatted as follows: 206 1 2 3 207 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 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | Next Payload |C| RESERVED | Payload Length | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 |Protocol ID(=0)| SPI Size (=0) | Notify Message Type | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 o Protocol ID (1 octet) MUST be 0. 216 o SPI Size (1 octet) MUST be 0, meaning no SPI is present. 218 o Notify Message Type (2 octets) - MUST be xxxxx, the value assigned 219 for IKEV2_FRAGMENTATION_SUPPORTED notification. 221 This Notification contains no data. 223 2.4. Using IKE Fragmentation 225 The IKE Fragmentation MUST NOT be used unless both peers have 226 indicated their support for it. After that it is up to the Initiator 227 of each exchange to decide whether or not to use it. The Responder 228 usually replies in the same form as the request message, but other 229 considerations might override this. 231 The Initiator can employ various policies regarding the use of IKE 232 Fragmentation. It might first try to send an unfragmented message 233 and resend it as fragmented only if no complete response is received 234 even after several retransmissions. Alternatively, it might choose 235 always to send fragmented messages (but see Section 3), or it might 236 fragment only large messages and messages that are expected to result 237 in large responses. 239 The following general guidelines apply: 241 o If either peer has information that a part of the transaction is 242 likely to be fragmented at the IP layer, causing interference with 243 the IKE exchange, that peer SHOULD use IKE Fragmentation. This 244 information might be passed from a lower layer, provided by 245 configuration, or derived through heuristics. Examples of 246 heuristics are the lack of a complete response after several 247 retransmissions for the Initiator, and receiving repeated 248 retransmissions of the request for the Responder. 250 o If either peer knows that IKE Fragmentation has been used in a 251 previous exchange in the context of the current IKE SA, that peer 252 SHOULD continue the use of IKE Fragmentation for the messages that 253 are larger than the current fragmentation threshold (see 254 Section 2.5.1). 256 o IKE Fragmentation SHOULD NOT be used in cases where IP-layer 257 fragmentation of both the request and response messages is 258 unlikely. For example, there is no point in fragmenting Liveness 259 Check messages. 261 o If none of the above apply, the Responder SHOULD respond in the 262 same form (fragmented or not) as the request message it is 263 responding to. Note that the other guidelines might override this 264 because of information or heuristics available to the Responder. 266 In most cases IKE Fragmentation will be used in the IKE_AUTH 267 Exchange, especially if certificates are employed. 269 2.5. Fragmenting Message 271 Only messages that contain an Encrypted Payload are subject for IKE 272 Fragmentation. For the purpose of IKE Fragment Messages construction 273 original (unencrypted) content of the Encrypted Payload is split into 274 chunks. The content is treated as a binary blob and is split 275 regardless of inner Payloads boundaries. Each of resulting chunks is 276 treated as an original content of the Encrypted Fragment Payload and 277 is then encrypted and authenticated. Thus, the Encrypted Fragment 278 Payload contains a chunk of the original content of the Encrypted 279 Payload in encrypted form. The cryptographic processing of the 280 Encrypted Fragment Payload is identical to Section 3.14 of [IKEv2], 281 as well as documents updating it for particular algorithms or modes, 282 such as [RFC5282]. 284 The Encrypted Fragment Payload, similarly to the Encrypted Payload, 285 if present in a message, MUST be the last payload in the message. 287 The Encrypted Fragment Payload is denoted SKF{...} and its payload 288 type is XXX (TBA by IANA). This payload is also called the 289 "Encrypted and Authenticated Fragment" payload. 291 1 2 3 292 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 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Next Payload |C| RESERVED | Payload Length | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | Fragment Number | Total Fragments | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Initialization Vector | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 ~ Encrypted content ~ 301 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | | Padding (0-255 octets) | 303 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 304 | | Pad Length | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 ~ Integrity Checksum Data ~ 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 Encrypted Fragment Payload 311 o Next Payload (1 octet) - in the very first fragment (with Fragment 312 Number equal to 1) this field MUST be set to Payload Type of the 313 first inner Payload (similarly to the Encrypted Payload). In the 314 rest fragments MUST be set to zero. 316 o Fragment Number (2 octets) - current fragment number starting from 317 1. This field MUST be less than or equal to the next field, Total 318 Fragments. This field MUST NOT be zero. 320 o Total Fragments (2 octets) - number of fragments original message 321 was divided into. This field MUST NOT be zero. With PMTU 322 discovery this field plays additional role. See Section 2.5.2 for 323 details. 325 The other fields are identical to those specified in Section 3.14 of 326 [IKEv2]. 328 When prepending IKE Header to the IKE Fragment Messages it MUST be 329 taken intact from the original message, except for the Length and the 330 Next Payload fields. The Length field is adjusted to reflect the 331 length of the constructed message and the Next Payload field is set 332 to the payload type of the first Payload in constructed message (in 333 most cases it will be Encrypted Fragment Payload). After prepending 334 IKE Header and all Payloads that possibly precede Encrypted Payload 335 in original message (if any, see Section 2.5.3), the resulting 336 messages are sent to the peer. 338 Below is an example of fragmenting a message. 340 HDR(MID=n), SK(NextPld=PLD1) {PLD1 ... PLDN} 342 Original Message 344 HDR(MID=n), SKF(NextPld=PLD1, Frag#=1, TotalFrags=m) {...}, 345 HDR(MID=n), SKF(NextPld=0, Frag#=2, TotalFrags=m) {...}, 346 ... 347 HDR(MID=n), SKF(NextPld=0, Frag#=m, TotalFrags=m) {...} 349 IKE Fragment Messages 351 2.5.1. Selecting Fragment Size 353 When splitting content of Encrypted Payload into chunks sender SHOULD 354 choose their size so, that resulting IP Datagrams be smaller than 355 some fragmentation threshold. Implementations may calculate 356 fragmentation threshold using various sources of information. 358 If the Sender has information about PMTU size it SHOULD use it. The 359 Responder in the exchange may use maximum size of received IKE 360 Fragment Message IP Datagrams as threshold when constructing 361 fragmented response. Successful completion of previous exchanges 362 (including those exchanges, that cannot employ IKE Fragmentation, 363 e.g. IKE_SA_INIT) may be an indication, that fragmentation threshold 364 can be set to the size of the largest of already sent messages. 366 Otherwise for messages to be sent over IPv6 it is RECOMMENDED to use 367 value 1280 bytes as a maximum IP Datagram size ([RFC2460]). For 368 messages to be sent over IPv4 it is RECOMMENDED to use value 576 369 bytes as a maximum IP Datagram size. Presence of tunnels on the path 370 may reduce these values. Implementations may use other values if 371 they are appropriate in current environment. 373 According to [RFC0791] the minimum IPv4 Datagram size that is 374 guaranteed not to be further fragmented is 68 bytes, but it is 375 generally impossible to use such small value for solution, described 376 in this document. Using 576 bytes is a compromise - the value is 377 large enough for the presented solution and small enough to avoid IP 378 fragmentation in most situations. Several other UDP-based protocol 379 assume the value 576 bytes as a safe low limit for IP Datagrams size 380 (Syslog, DNS, etc.). 382 See Appendix B for correlation between IP Datagram size and Encrypted 383 Payload content size. 385 2.5.2. PMTU Discovery 387 The amount of traffic that IKE endpoint produces during lifetime of 388 IKE SA is fairly modest - usually it is below one hundred kBytes 389 within a period of several hours. Most of this traffic consists of 390 relatively short messages - usually below several hundred bytes. In 391 most cases the only time when IKE endpoints exchange messages of 392 several kBytes in size is IKE SA establishment and often each 393 endpoint sends exactly one such message. 395 For the reasons articulated above implementing PMTU discovery in IKE 396 is OPTIONAL. It is believed that using the values recommended in 397 Section 2.5.1 as fragmentation threshold will be sufficient in most 398 cases. Using these values could lead to suboptimal fragmentation, 399 but it is acceptable given the amount of traffic IKE produces. 400 Implementations may support PMTU discovery if there are good reasons 401 to do it (for example if it is intended to be used in environments 402 where MTU size is possible to be less that values listed in 403 Section 2.5.1). 405 PMTU discovery in IKE follows recommendations given in Section 10.4 406 of [RFC4821] with the difference, induced by the specialties of IKE 407 listed above. The difference is that the PMTU search is performed 408 downward, while in [RFC4821] it is performed upward. The reason for 409 this change is that IKE usually sends large messages only when IKE SA 410 is being established and in many cases there is only one such 411 message. If the probing were performed upward this message would be 412 fragmented using the smallest allowable threshold, and usually all 413 other messages are small enough to avoid IP fragmentation, so there 414 would be little value to continue probing. 416 It is the Initiator of the exchange, who performs PMTU discovery. It 417 is done by probing several values of fragmentation threshold. 418 Implementations MUST be prepared to probe in every exchange that 419 utilizes IKE Fragmentation to deal with possible changes of path MTU 420 over time. While doing probes, it MUST start from larger values and 421 refragment original message using next smaller value of threshold if 422 it did not receive response in a reasonable time after several 423 retransmissions. The exact number of retransmissions and length of 424 timeouts are not covered in this specification because they do not 425 affect interoperability. However, the timeout interval is supposed 426 to be relatively short, so that unsuccessful probes would not delay 427 IKE operations too much. Performing few retries within several 428 seconds for each probe seems appropriate, but different environments 429 may require different rules. When starting new probe node MUST reset 430 its retransmission timers so, that if it employs exponential back- 431 off, the timers will start over. After reaching the smallest allowed 432 value for the fragmentation threshold an implementation MUST continue 433 retransmitting until either exchange completes or times out using 434 timeout interval from Section 2.4 of [IKEv2]. 436 PMTU discovery in IKE is supposed to be coarse-grained, i.e. it is 437 expected, that node will try only few fragmentation thresholds, in 438 order to minimize delays caused by unsuccessful probes. If no 439 information about path MTU is known yet, endpoint may start probing 440 from link MTU size. In the following exchanges node should start 441 from the current value of fragmentation threshold. 443 If an implementation is capable to receive ICMP error messages it can 444 additionally utilize classic PMTU discovery methods, described in 445 [RFC1191] and [RFC1981]. In particular, if the Initiator receives 446 Packet Too Big error in response to the probe, and it contains 447 smaller value, than current fragmentation threshold, then the 448 Initiator SHOULD stop retransmitting the probe and SHOULD select new 449 value for fragmentation threshold that is less than or equal to the 450 value from the ICMP message and meets the requirements listed below. 452 In case of PMTU discovery Total Fragments field is used to 453 distinguish between different sets of fragments, i.e. the sets that 454 were created by fragmenting original message using different 455 fragmentation thresholds. Since sender starts from larger fragments 456 and then make them smaller, the value in Total Fragments field 457 increases with each new probe. When selecting next smaller value for 458 fragmentation threshold, sender MUST ensure that the value in Total 459 Fragments field is really increased. This requirement should not be 460 a problem for the sender, because PMTU discovery in IKE is supposed 461 to be coarse-grained, so difference between previous and next 462 fragmentation thresholds should be significant anyway. The necessity 463 to distinguish between the sets is vital for receiver since receiving 464 valid fragment from newer set means that it have to start 465 reassembling over and not to mix fragments from different sets. 467 2.5.3. Fragmenting Messages containing unprotected Payloads 469 Currently there are no IKEv2 exchanges that define messages, 470 containing both unprotected payloads and payloads, protected by 471 Encrypted Payload. However IKEv2 does not prohibit such 472 construction. If some future IKEv2 extension defines such a message 473 and it needs to be fragmented, all unprotected payloads MUST be 474 placed in the first fragment (with Fragment Number field equal to 1), 475 along with Encrypted Fragment Payload, which MUST be present in every 476 IKE Fragment Message and be the last payload in it. 478 Below is an example of fragmenting message, containing both protected 479 and unprotected Payloads. 481 HDR(MID=n), PLD0, SK(NextPld=PLD1) {PLD1 ... PLDN} 483 Original Message 485 HDR(MID=n), PLD0, SKF(NextPld=PLD1, Frag#=1, TotalFrags=m) {...}, 486 HDR(MID=n), SKF(NextPld=0, Frag#=2, TotalFrags=m) {...}, 487 ... 488 HDR(MID=n), SKF(NextPld=0, Frag#=m, TotalFrags=m) {...} 490 IKE Fragment Messages 492 Note that the size of each IP Datagram bearing IKE Fragment Messages 493 should not exceed fragmentation threshold, including the first one, 494 that contains unprotected Payloads. This will reduce the size of 495 Encrypted Fragment Payload content in the first IKE Fragment Message 496 to accommodate all unprotected Payloads. In extreme case Encrypted 497 Fragment Payload will contain no data, but it still must be present 498 in the message, because only its presence allows receiver to 499 determine that sender have used IKE Fragmentation. 501 2.6. Receiving IKE Fragment Message 503 The Receiver identifies the IKE Fragment Message by the presence of 504 an Encrypted Fragment Payload in it. In most cases it will be the 505 first and the only payload in the message, however this may not be 506 true for some hypothetical IKE exchanges (see Section 2.5.3) 508 Upon receiving the IKE Fragment Message the following actions are 509 performed: 511 o Check message validity - in particular, check whether the values 512 in the Fragment Number and the Total Fragments fields in the 513 Encrypted Fragment Payload are valid. The following tests need to 514 be performed. 516 * check that the Fragment Number and the Total Fragments fields 517 contain non-zero values 519 * check that the value in the Fragment Number field is less than 520 or equal to the value in the Total Fragments field 522 * if reassembling has already started, check that the value in 523 the Total Fragments field is equal to or greater than Total 524 Fragments field in the fragments that have already been stored 525 in the reassembling queue 527 If any of this tests fails the message MUST be silently discarded. 529 o Check, that this IKE Fragment Message is new for the receiver and 530 not a replay. If IKE Fragment message with the same Message ID, 531 same Fragment Number and same Total Fragments fields is already 532 present in the reassembling queue, this message is considered a 533 replay and MUST be silently discarded. 535 o Verify IKE Fragment Message authenticity by checking ICV in 536 Encrypted Fragment Payload. If ICV check fails message MUST be 537 silently discarded. 539 o If reassembling is not finished yet and Total Fragments field in 540 received fragment is greater than this field in those fragments, 541 that are in the reassembling queue, receiver MUST discard all 542 received fragments and start reassembling over with just received 543 IKE Fragment Message. 545 o Store message in the reassembling queue waiting for the rest of 546 fragments to arrive. 548 When all IKE Fragment Messages (as indicated in the Total Fragments 549 field) are received, the decrypted content of all Encrypted Fragment 550 Payloads is merged together to form content of original Encrypted 551 Payload, and, therefore, along with IKE Header and unprotected 552 Payloads (if any), original message. Then it is processed as if it 553 was received, verified and decrypted as regular IKE message. 555 If receiver does not get all IKE fragments needed to reassemble the 556 original Message within a timeout interval, it MUST discard all IKE 557 Fragment Messages received so far for the exchange. The next actions 558 depend on the role of receiver in the exchange. 560 o The Initiator acts as described in Section 2.1 of [IKEv2]. It 561 either retransmits the fragmented request Message or deems IKE SA 562 to have failed and deletes it. The number of retransmits and 563 length of timeouts for the Initiator are not covered in this 564 specification since they are assumed to be the same as in regular 565 IKEv2 exchange and are discussed in Section 2.4 of [IKEv2]. 567 o The Responder in this case acts as if no request message was 568 received. It would delete any memory of the incomplete request 569 message, and not treat it as an IKE SA failure. The reassembling 570 timeout for the Responder is RECOMMENDED to be equal to the time 571 interval that the implementation waits before completely giving up 572 when acting as Initiator of exchange. Section 2.4 of [IKEv2] 573 gives recommendations for selecting this interval. 574 Implementations can use a shorter timeout to conserve memory. 576 2.6.1. Replay Detection and Retransmissions 578 According to [IKEv2] implementations must reject message with the 579 same Message ID as it has seen before (taking into consideration 580 Response bit). This logic has already been updated by [RFC6311], 581 which deliberately allows any number of messages with zero Message 582 ID. This document also updates this logic for the situations, when 583 IKE Fragmentation is in use. 585 If incoming message contains Encrypted Fragment Payload, the values 586 of Fragment Number and Total Fragments fields MUST be used along with 587 Message ID to detect retransmissions and replays. 589 If Responder receives retransmitted fragment of request when it has 590 already processed that request and has sent back a response, that 591 event MUST only trigger retransmission of the response message 592 (fragmented or not) if Fragment Number field in received fragment is 593 set to 1 and MUST be ignored otherwise. 595 3. Interaction with other IKE extensions 597 IKE Fragmentation is compatible with most of IKE extensions, such as 598 IKE Session Resumption ([RFC5723]), Quick Crash Detection Method 599 ([RFC6290]) and so on. It neither affect their operation, nor is 600 affected by them. It is believed that IKE Fragmentation will also be 601 compatible with future IKE extensions, if they follow general 602 principles of formatting, sending and receiving IKE messages, 603 described in [IKEv2]. 605 When IKE Fragmentation is used with IKE Session Resumption 606 ([RFC5723]), messages of IKE_SESSION_RESUME Exchange cannot be 607 fragmented since they do not contain Encrypted Payload. These 608 messages may be large due to the ticket size. To avoid IP 609 Fragmentation in this situation it is recommended to use smaller 610 tickets, e.g. by utilizing "ticket by reference" approach instead of 611 "ticket by value". 613 One exception that requires a special care is Protocol Support for 614 High Availability of IKEv2/IPsec ([RFC6311]). Since it deliberately 615 allows any number of synchronization exchanges to have the same 616 Message ID, namely zero, standard IKEv2 replay detection logic, based 617 on checking Message ID is not applicable for such messages, and 618 receiver has to check message content to detect replays. When 619 implementing IKE Fragmentation along with [RFC6311], IKE Message ID 620 Synchronization messages MUST NOT be sent fragmented to simplify 621 receiver's task of detecting replays. Fortunately, these messages 622 are small and there is no point in fragmenting them anyway. 624 4. Transport Considerations 626 With IKE Fragmentation if any single IKE Fragment Message get lost, 627 receiver becomes unable to reassemble original Message. So, in 628 general, using IKE Fragmentation implies higher probability for the 629 Message not to be delivered to the peer. Although in most network 630 environments the difference will be insignificant, on some lossy 631 networks it may become noticeable. When using IKE Fragmentation 632 implementations MAY use longer timeouts and do more retransmits than 633 usual before considering peer dead. 635 Note that Fragment Messages are not individually acknowledged. The 636 response Fragment Messages are sent back all together only when all 637 fragments of request are received, the original request Message is 638 reassembled and successfully processed. 640 5. Security Considerations 642 Most of the security considerations for IKE Fragmentation are the 643 same as those for the base IKEv2 protocol described in [IKEv2]. This 644 extension introduces Encrypted Fragment Payload to protect content of 645 IKE Message Fragment. This allows receiver to individually check 646 authenticity of fragments, thus protecting peers from DoS attack. 648 Security Considerations Section of [IKEv2] mentions possible attack 649 on IKE by exhausting of the IP reassembly buffers. The mechanism, 650 described in this document, allows IKE to avoid IP fragmentation and 651 therefore increases its robustness to DoS attacks. 653 The following attack is possible with IKE Fragmentation. An attacker 654 can initiate IKE_SA_INIT Exchange, complete it, compute SK_a and SK_e 655 and then send a large, but still incomplete, set of IKE_AUTH 656 fragments. These fragments will pass the ICV check and will be 657 stored in reassembly buffers, but since the set is incomplete, the 658 reassembling will never succeed and eventually will time out. If the 659 set is large, this attack could potentially exhaust the receiver's 660 memory resources. 662 To mitigate the impact of this attack, it is RECOMMENDED that 663 receiver limits the number of fragments it stores in reassembling 664 queue so that the sum of the sizes of Encrypted Fragment Payload 665 contents (after decryption) for fragments that are already placed 666 into the reassembling queue is less than some value that is 667 reasonable for the implementation. If the peer sends so many 668 fragments that the above condition is not met, the receiver can 669 consider this situation to be either attack or as broken sender 670 implementation. In either case, the receiver SHOULD drop the 671 connection and discard all the received fragments. 673 This value can be predefined, can be a configurable option, or can be 674 calculated dynamically depending on the receiver's memory load. Some 675 care should be taken when selecting this value because, if it is too 676 small, it might prevent legitimate peer to establish IKE SA if the 677 size of messages it sends exceeds this value. It is NOT RECOMMENDED 678 for this value to exceed 64 Kbytes because any IKE message before 679 fragmentation would likely be shorter than that. 681 6. IANA Considerations 683 This document defines new Payload in the "IKEv2 Payload Types" 684 registry: 686 Encrypted and Authenticated Fragment SKF 688 This document also defines new Notify Message Types in the "Notify 689 Message Types - Status Types" registry: 691 IKEV2_FRAGMENTATION_SUPPORTED 693 7. Acknowledgements 695 The author would like to thank Tero Kivinen, Yoav Nir, Paul Wouters, 696 Yaron Sheffer, Joe Touch, Derek Atkins, Ole Troan and others for 697 their reviews and valuable comments. Thanks to Ron Bonica for 698 contributing text to the Introduction Section. Thanks to Paul 699 Hoffman and Barry Leiba for improving text clarity. 701 8. References 703 8.1. Normative References 705 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 706 Requirement Levels", BCP 14, RFC 2119, March 1997. 708 [IKEv2] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 709 Kivinen, "Internet Key Exchange Protocol Version 2 710 (IKEv2)", draft-kivinen-ipsecme-ikev2-rfc5996bis-03 (work 711 in progress), April 2014. 713 [RFC6311] Singh, R., Kalyani, G., Nir, Y., Sheffer, Y., and D. 714 Zhang, "Protocol Support for High Availability of IKEv2/ 715 IPsec", RFC 6311, July 2011. 717 8.2. Informative References 719 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 720 September 1981. 722 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 723 November 1990. 725 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 726 for IP version 6", RFC 1981, August 1996. 728 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 729 (IPv6) Specification", RFC 2460, December 1998. 731 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 732 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 733 RFC 4787, January 2007. 735 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 736 Discovery", RFC 4821, March 2007. 738 [RFC5282] Black, D. and D. McGrew, "Using Authenticated Encryption 739 Algorithms with the Encrypted Payload of the Internet Key 740 Exchange version 2 (IKEv2) Protocol", RFC 5282, 741 August 2008. 743 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 744 for Application Designers", BCP 145, RFC 5405, 745 November 2008. 747 [RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange 748 Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, 749 January 2010. 751 [RFC6290] Nir, Y., Wierbowski, D., Detienne, F., and P. Sethi, "A 752 Quick Crash Detection Method for the Internet Key Exchange 753 Protocol (IKE)", RFC 6290, June 2011. 755 [RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 756 and H. Ashida, "Common Requirements for Carrier-Grade NATs 757 (CGNs)", BCP 127, RFC 6888, April 2013. 759 [FRAGDROP] 760 Jaeggli, J., Colitti, L., Kumari, W., Vyncke, E., Kaeo, 761 M., and T. Taylor, "Why Operators Filter Fragments and 762 What It Implies", draft-taylor-v6ops-fragdrop-02 (work in 763 progress), December 2013. 765 [BLACKHOLES] 766 De Boer, M. and J. Bosma, "Discovering Path MTU black 767 holes on the Internet using RIPE Atlas", July 2012, . 771 [DOSUDPPROT] 772 Kaufman, C., Perlman, R., and B. Sommerfeld, "DoS 773 protection for UDP-based protocols", ACM Conference on 774 Computer and Communications Security, October 2003. 776 Appendix A. Design rationale 778 The simplest approach to the IKE fragmentation would have been to 779 fragment message that is fully formed and ready to be sent. But if 780 message got fragmented after being encrypted and authenticated, this 781 could open a possibility for a simple Denial of Service attack. The 782 attacker could infrequently emit forged but valid looking fragments 783 into the network, and some of these fragments would be fetched by 784 receiver into the reassembling queue. Receiver could not distinguish 785 forged fragments from valid ones and could only determine that some 786 of received fragments were forged when the whole message got 787 reassembled and check for its authenticity failed. 789 To prevent this kind of attack and also to reduce vulnerability to 790 some other kinds of DoS attacks it was decided to make fragmentation 791 before applying cryptographic protection to the message. In this 792 case each Fragment Message becomes individually encrypted and 793 authenticated, that allows receiver to determine forged fragments and 794 not to store them in the reassembling queue. 796 Appendix B. Correlation between IP Datagram size and Encrypted Payload 797 content size 799 For IPv4 Encrypted Payload content size is less than IP Datagram size 800 by the sum of the following values: 802 o IPv4 header size (typically 20 bytes, up to 60 if IP options are 803 present) 805 o UDP header size (8 bytes) 807 o non-ESP marker size (4 bytes if present) 809 o IKE Header size (28 bytes) 811 o Encrypted Payload header size (4 bytes) 813 o IV size (varying) 815 o padding and its size (at least 1 byte) 817 o ICV size (varying) 819 The sum may be estimated as 61..105 bytes + IV + ICV + padding. 821 For IPv6 Encrypted Payload content size is less than IP Datagram size 822 by the sum of the following values: 824 o IPv6 header size (40 bytes) 826 o IPv6 extension headers (optional, size varies) 828 o UDP header size (8 bytes) 830 o non-ESP marker size (4 bytes if present) 832 o IKE Header size (28 bytes) 834 o Encrypted Payload header size (4 bytes) 836 o IV size (varying) 838 o padding and its size (at least 1 byte) 840 o ICV size (varying) 842 If no extension header is present, the sum may be estimated as 81..85 843 bytes + IV + ICV + padding. If extension headers are present, the 844 payload content size is further reduced by the sum of the size of the 845 extension headers. The length of each extension header can be 846 calculated as 8 * (Hdr Ext Len) bytes except for the fragment header 847 which is always 8 bytes in length. 849 Author's Address 851 Valery Smyslov 852 ELVIS-PLUS 853 PO Box 81 854 Moscow (Zelenograd) 124460 855 Russian Federation 857 Phone: +7 495 276 0211 858 Email: svan@elvis.ru