idnits 2.17.1 draft-ietf-ipsecme-ikev2-fragmentation-07.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 date (April 4, 2014) is 3673 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 171, but not defined ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 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 April 4, 2014 5 Expires: October 6, 2014 7 IKEv2 Fragmentation 8 draft-ietf-ipsecme-ikev2-fragmentation-07 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 don't 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 October 6, 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. Conventions Used in This Document . . . . . . . . . . . . 3 52 2. Protocol details . . . . . . . . . . . . . . . . . . . . . . . 4 53 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . 4 55 2.3. Negotiation . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.4. Using IKE Fragmentation . . . . . . . . . . . . . . . . . 5 57 2.5. Fragmenting Message . . . . . . . . . . . . . . . . . . . 6 58 2.5.1. Selecting Fragment Size . . . . . . . . . . . . . . . 8 59 2.5.2. PMTU Discovery . . . . . . . . . . . . . . . . . . . . 8 60 2.5.3. Fragmenting Messages containing unencrypted 61 Payloads . . . . . . . . . . . . . . . . . . . . . . . 10 62 2.6. Receiving IKE Fragment Message . . . . . . . . . . . . . . 10 63 2.6.1. Changes in Replay Protection Logic . . . . . . . . . . 12 64 3. Interaction with other IKE extensions . . . . . . . . . . . . 13 65 4. Transport Considerations . . . . . . . . . . . . . . . . . . . 14 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 68 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 70 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 71 8.2. Informative References . . . . . . . . . . . . . . . . . . 18 72 Appendix A. Design rationale . . . . . . . . . . . . . . . . . . 20 73 Appendix B. Correlation between IP Datagram size and 74 Encrypted Payload content size . . . . . . . . . . . 21 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23 77 1. Introduction 79 The Internet Key Exchange Protocol version 2 (IKEv2), specified in 80 [RFC5996], uses UDP as a transport for its messages. Most IKEv2 81 messages are relatively small, usually below several hundred bytes. 82 Noticeable exception is IKE_AUTH exchange, which requires fairly 83 large messages, up to several kbytes, especially when certificates 84 are transferred. When IKE message size exceeds path MTU, it gets 85 fragmented by IP level. The problem is that some network devices, 86 specifically some NAT boxes, don't allow IP fragments to pass 87 through. This apparently blocks IKE communication and, therefore, 88 prevents peers from establishing IPsec SA. 90 Widespread deployment of Carrier-Grade NATs (CGN) introduces new 91 challenges. RFC6888 [RFC6888] describes requirements for CGNs. It 92 states, that CGNs must comply with Section 11 of RFC4787 [RFC4787], 93 which requires NAT to support receiving IP fragments (REQ-14). In 94 real life fulfillment of this requirement creates an additional 95 burden in terms of memory, especially for high-capacity devices, used 96 in CGNs. It was found by people deploying IKE, that some ISPs have 97 begun to drop IP fragments, violating that requirement. 99 The solution to the problem described in this document is to perform 100 fragmentation of large messages by IKE itself, replacing them by 101 series of smaller messages. In this case the resulting IP Datagrams 102 will be small enough so that no fragmentation on IP level will take 103 place. 105 Avoiding IP fragmentation is beneficial for IKEv2 in general. 106 Security Considerations Section of [RFC5996] mentions exhausting of 107 the IP reassembly buffers as one of possible attacks on the protocol. 108 In the paper [DOSUDPPROT] several aspects of attacks on IKE using IP 109 fragmentation are discussed, and one of defenses it proposes is to 110 perform IKE-level fragmentation, similar to the solution, described 111 in this document. 113 1.1. Conventions Used in This Document 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in [RFC2119]. 119 2. Protocol details 121 2.1. Overview 123 The idea of the protocol is to split large IKE message into a set of 124 smaller ones, called IKE Fragment Messages. Fragmentation takes 125 place before the original message is encrypted and authenticated, so 126 that each IKE Fragment Message receives individual protection. On 127 the receiving side IKE Fragment Messages are collected, verified, 128 decrypted and merged together to get the original message before 129 encryption. For design rationale see Appendix A. 131 2.2. Limitations 133 As IKE Fragment Messages are cryptographically protected, SK_a and 134 SK_e must already be calculated. In general, it means that original 135 message can be fragmented if and only if it contains Encrypted 136 Payload. 138 This implies that messages of the IKE_SA_INIT Exchange cannot be 139 fragmented. In most cases this is not a problem, since IKE_SA_INIT 140 messages are usually small enough to avoid IP fragmentation. But in 141 some cases (advertising a badly structured long list of algorithms, 142 using large MODP Groups, etc.) these messages may become fairly large 143 and get fragmented by IP level. In this case the described solution 144 won't help. 146 Among existing IKEv2 extensions, messages of IKE_SESSION_RESUME 147 Exchange, defined in [RFC5723], cannot be fragmented either. See 148 Section 3 for details. 150 Another limitation is that the minimal size of IP Datagram bearing 151 IKE Fragment Message is about 100 bytes depending on the algorithms 152 employed. According to [RFC0791] the minimum IP Datagram size that 153 is guaranteed not to be further fragmented is 68 bytes. So, even the 154 smallest IKE Fragment Messages could be fragmented by IP level in 155 some circumstances. But such extremely small PMTU sizes are very 156 rare in real life. 158 2.3. Negotiation 160 Initiator MAY indicate its support for IKE Fragmentation and 161 willingness to use it by including Notification Payload of type 162 IKEV2_FRAGMENTATION_SUPPORTED in IKE_SA_INIT request message. If 163 Responder also supports this extension and is willing to use it, it 164 includes this notification in response message. 166 Initiator Responder 167 ----------- ----------- 168 HDR, SAi1, KEi, Ni, 169 [N(IKEV2_FRAGMENTATION_SUPPORTED)] --> 171 <-- HDR, SAr1, KEr, Nr, [CERTREQ], 172 [N(IKEV2_FRAGMENTATION_SUPPORTED)] 174 The Notify payload is formatted as follows: 176 1 2 3 177 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 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | Next Payload |C| RESERVED | Payload Length | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 |Protocol ID(=0)| SPI Size (=0) | Notify Message Type | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 o Protocol ID (1 octet) MUST be 0. 186 o SPI Size (1 octet) MUST be 0, meaning no SPI is present. 188 o Notify Message Type (2 octets) - MUST be xxxxx, the value assigned 189 for IKEV2_FRAGMENTATION_SUPPORTED by IANA. 191 This Notification contains no data. 193 2.4. Using IKE Fragmentation 195 IKE Fragmentation MUST NOT be used unless both peers indicated their 196 support for it. After IKE Fragmentation is negotiated, it is up to 197 Initiator of each Exchange, whether to use it or not. In most cases 198 IKE Fragmentation will be used in IKE_AUTH Exchange, especially if 199 certificates are employed. Initiator may first try to send 200 unfragmented message and resend it fragmented only if it didn't 201 receive response after several retransmissions, or it may always send 202 messages fragmented (but see Section 3), or it may fragment only 203 large messages and messages causing large responses. 205 In general the following guidelines are applicable for initiator: 207 o Initiator MAY fragment outgoing message if it has some knowledge 208 (possibly from lower layer or from configuration) or suspicions 209 that either request or response message will be fragmented by IP 210 level. 212 o Initiator SHOULD fragment outgoing message if it has some 213 knowledge (possibly from lower layer or from configuration) or 214 suspicions that either request or response message will be 215 fragmented by IP level and IKE Fragmentation was already used in 216 one of previous Exchanges in the context of the current IKE SA. 218 o Initiator SHOULD NOT fragment outgoing message if both request and 219 response messages of the Exchange are small enough not to cause 220 fragmentation on IP level (for example, there is no point in 221 fragmenting Liveness Check messages). 223 In general the following guidelines are applicable for responder: 225 o Responder SHOULD send response message in the same form 226 (fragmented or not) as corresponded request message. If it 227 received unfragmented request message, responded with unfragmented 228 response message and then receives fragmented retransmission of 229 the same request, it SHOULD resend its response back to Initiator 230 fragmented. 232 o Responder MAY respond to unfragmented message with fragmented 233 response if it has some knowledge (possibly from lower layer or 234 from configuration) or suspicions that response message will be 235 fragmented by IP level. 237 o Responder MAY respond to fragmented message with unfragmented 238 response if the size of the response message is less than the 239 smallest fragmentation threshold, supported by Responder (for 240 example, there is no point in fragmenting Liveness Check 241 messages). 243 2.5. Fragmenting Message 245 Message to be fragmented MUST contain Encrypted Payload. For the 246 purpose of IKE Fragment Messages construction original (unencrypted) 247 content of Encrypted Payload is split into chunks. The content is 248 treated as a binary blob and is split regardless of inner Payloads 249 boundaries. Each of resulting chunks is treated as an original 250 content of Encrypted Fragment Payload and is then encrypted and 251 authenticated. Thus, the Encrypted Fragment Payload contains a chunk 252 of the original content of Encrypted Payload in encrypted form. The 253 cryptographic processing of Encrypted Fragment Payload is identical 254 to Section 3.14 of [RFC5996], as well as documents updating it for 255 particular algorithms or modes, such as [RFC5282]. 257 The Encrypted Fragment Payload, similarly to the Encrypted Payload, 258 if present in a message, MUST be the last payload in the message. 260 The Encrypted Fragment Payload is denoted SKF{...} and its payload 261 type is XXX (TBA by IANA). This payload is also called the 262 "Encrypted and Authenticated Fragment" payload. 264 1 2 3 265 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 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Next Payload |C| RESERVED | Payload Length | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Fragment Number | Total Fragments | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | Initialization Vector | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 ~ Encrypted content ~ 274 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | | Padding (0-255 octets) | 276 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 277 | | Pad Length | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 ~ Integrity Checksum Data ~ 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 Encrypted Fragment Payload 284 o Next Payload (1 octet) - in the very first fragment MUST be set to 285 Payload Type of the first inner Payload (similarly to the 286 Encrypted Payload). In the rest fragments MUST be set to zero. 288 o Fragment Number (2 octets) - current fragment number starting from 289 1. This field MUST be less than or equal to the next field, Total 290 Fragments. This field MUST NOT be zero. 292 o Total Fragments (2 octets) - number of fragments original message 293 was divided into. With PMTU discovery this field plays additional 294 role. See Section 2.5.2 for details. This field MUST NOT be 295 zero. 297 The other fields are identical to those specified in Section 3.14 of 298 [RFC5996]. 300 When prepending IKE Header, Length field MUST be adjusted to reflect 301 the length of constructed message and Next Payload field MUST reflect 302 payload type of the first Payload in the constructed message (that in 303 most cases will be Encrypted Fragment Payload). All newly 304 constructed messages MUST retain the same Message ID as original 305 message. After prepending IKE Header and possibly any of Payloads 306 that precedes Encrypted Payload in original message (see 307 Section 2.5.3), the resulting messages are sent to the peer. 309 Below is an example of fragmenting a message. 311 HDR(MID=n), SK(NextPld=PLD1) {PLD1 ... PLDN} 313 Original Message 315 HDR(MID=n), SKF(NextPld=PLD1, Frag#=1, TotalFrags=m) {...}, 316 HDR(MID=n), SKF(NextPld=0, Frag#=2, TotalFrags=m) {...}, 317 ... 318 HDR(MID=n), SKF(NextPld=0, Frag#=m, TotalFrags=m) {...} 320 IKE Fragment Messages 322 2.5.1. Selecting Fragment Size 324 When splitting content of Encrypted into chunks sender SHOULD chose 325 size of those chunks so, that resulting IP Datagram size not exceed 326 some fragmentation threshold - be small enough to avoid IP 327 fragmentation. 329 If sender has some knowledge about PMTU size it MAY use it. If 330 sender is a Responder in the Exchange and it has received fragmented 331 request, it MAY use maximum size of received IKE Fragment Message IP 332 Datagrams as threshold when constructing fragmented response. 334 Otherwise for messages to be sent over IPv6 it is RECOMMENDED to use 335 value 1280 bytes as a maximum IP Datagram size ([RFC2460]). For 336 messages to be sent over IPv4 it is RECOMMENDED to use value 576 337 bytes as a maximum IP Datagram size. Presence of tunnels on the path 338 may reduce these values. 340 According to [RFC0791] the minimum IPv4 datagram size that is 341 guaranteed not to be further fragmented is 68 bytes, but it is 342 generally impossible to use such small value for solution, described 343 in this document. Using 576 bytes is a compromise - the value is 344 large enough for the presented solution and small enough to avoid IP 345 fragmentation in most situations. Several other UDP-based protocol 346 assume the value 576 bytes as a safe low limit for IP datagrams size 347 (Syslog, DNS, etc.). Sender MAY use other values if they are 348 appropriate. 350 See Appendix B for correlation between IP Datagram size and Encrypted 351 Payload content size. 353 2.5.2. PMTU Discovery 355 Initiator MAY try to discover path MTU by probing several values of 356 fragmentation threshold. While doing probes, node MUST start from 357 larger values and refragment message with next smaller value if it 358 doesn't receive response in a reasonable time after several 359 retransmissions. This time is supposed to be relatively short, so 360 that node could make all desired probes before exchange times out. 361 When starting new probe (with smaller threshold) node MUST reset its 362 retransmission timers so, that if it employs exponential back-off, 363 the timers start over. After reaching the smallest allowed value for 364 fragmentation threshold implementation MUST continue probing using it 365 until either exchange completes or times out. 367 PMTU discovery in IKE is supposed to be coarse-grained, i.e. it is 368 expected, that node will try only few fragmentation thresholds, in 369 order to minimize possible IKE SA establishment delay. In a corner 370 case, when host will use only one value, PMTU discovery will 371 effectively be disabled. In most cases PMTU discovery will not be 372 needed, as using values, recommended in section Section 2.5.1, should 373 suffice. It is expected, that PMTU discovery may be useful in 374 environments where PMTU size are smaller, than those listed in 375 Section 2.5.1, for example due to the presence of intermediate 376 tunnels. 378 PMTU discovery in IKE follows recommendations, given in Section 10.4 379 of RFC4821 [RFC4821] with some differences, induced by the 380 specialties of IKE. In particular: 382 o Unlike classical PMTUD [RFC1191] and PLMTUD [RFC4821] the goal of 383 Path MTU discovery in IKE is not to find the largest size of IP 384 packet, that will not be fragmented en route, but to find any 385 reasonable size, probably far from optimal. 387 o There is no goal to completely disallow IP fragmentation until its 388 presence leads to inability IKE to communicate (e.g. when IP 389 fragments are dropped) 391 o IKE usually sends large messages only in IKE_AUTH exchange, i.e. 392 once per IKE SA. Most of other messages will have size below 393 several hundred bytes. Performing full PMTUD for sending exactly 394 one large message is inefficient. 396 In case of PMTU discovery Total Fragments field is used to 397 distinguish between different sets of fragments, i.e. the sets that 398 were obtained by fragmenting original message using different 399 fragmentation thresholds. As sender will start from larger fragments 400 and then make them smaller, the value in Total Fragments field will 401 increase with each new try. When selecting next smaller value of 402 fragmentation threshold, sender MUST ensure that the value in Total 403 Fragments field is really increased. This requirement should not 404 become a problem for the sender, as PMTU discovery in IKE is supposed 405 to be coarse-grained, so difference between previous and next 406 fragmentation thresholds will be significant anyway. The necessity 407 to distinguish between the sets is vital for receiver as receiving 408 any valid fragment from newer set will mean that it have to start 409 reassembling over and not to mix fragments from different sets. 411 2.5.3. Fragmenting Messages containing unencrypted Payloads 413 Currently no one of IKEv2 Exchanges defines messages, containing both 414 unencrypted payloads and payloads, protected by Encrypted Payload. 415 But IKEv2 doesn't forbid such messages. If some future IKEv2 416 extension defines such a message and it needs to be fragmented, all 417 unprotected payloads MUST be in the first fragment, along with 418 Encrypted Fragment Payload, which MUST be present in any IKE Fragment 419 Message. 421 Below is an example of fragmenting message, containing both encrypted 422 and unencrypted Payloads. 424 HDR(MID=n), PLD0, SK(NextPld=PLD1) {PLD1 ... PLDN} 426 Original Message 428 HDR(MID=n), PLD0, SKF(NextPld=PLD1, Frag#=1, TotalFrags=m) {...}, 429 HDR(MID=n), SKF(NextPld=0, Frag#=2, TotalFrags=m) {...}, 430 ... 431 HDR(MID=n), SKF(NextPld=0, Frag#=m, TotalFrags=m) {...} 433 IKE Fragment Messages 435 Note, that the size of each IP Datagram bearing IKE Fragment Messages 436 SHOULD NOT exceed fragmentation threshold, including the very first, 437 which contains unprotected Payloads. This will reduce the size of 438 Encrypted Fragment Payload content in the first IKE Fragment Message 439 to accommodate unprotected Payloads. In extreme cases Encrypted 440 Fragment Payload will contain no data, but it is still MUST be 441 present in the message, because only its presence allows receiver to 442 distinguish IKE Fragment Message from regular IKE message. 444 2.6. Receiving IKE Fragment Message 446 Receiver identifies IKE Fragment Message by the presence of Encrypted 447 Fragment Payload in it. Note, that it is possible for this payload 448 to be not the first (and the only) payload in the message (see 449 Section 2.5.3). But for all currently defined IKEv2 exchanges this 450 payload will be the first and the only payload in the message. 452 Upon receiving IKE Fragment Message the following actions are 453 performed: 455 o Check message validity - in particular, check whether values of 456 Fragment Number and Total Fragments in Encrypted Fragment Payload 457 are valid. The following tests need to be performed. 459 * check that Fragment Number and Total Fragments fields are non- 460 zero 462 * check that Fragment Number field is less than or equal to Total 463 Fragments field 465 * if reassembling has already started, check that Total Fragments 466 field is equal to or greater than Total Fragments field in 467 fragments, that have already received 469 If any of this tests fails message MUST be silently discarded. 471 o Check, that this IKE Fragment Message is new for the receiver and 472 not a replay. If IKE Fragment message with the same Message ID, 473 same Fragment Number and same Total Fragments fields was already 474 received and successfully processed, this message is considered a 475 replay and MUST be silently discarded. 477 o Verify IKE Fragment Message authenticity by checking ICV in 478 Encrypted Fragment Payload. If ICV check fails message MUST be 479 silently discarded. 481 o If reassembling isn't finished yet and Total Fragments field in 482 received IKE Fragment Message is greater than this field in 483 previously received fragments, receiver MUST discard all received 484 fragments and start reassembling over with just received IKE 485 Fragment Message. 487 o Store message in the list waiting for the rest of fragments to 488 arrive. 490 When all IKE Fragment Messages (as indicated in the Total Fragments 491 field) are received, content of their already decrypted Encrypted 492 Fragment Payloads is merged together to form content of original 493 Encrypted Payload, and, therefore, along with IKE Header and 494 unencrypted Payloads (if any), original message. Then it is 495 processed as if it was received, verified and decrypted as regular 496 unfragmented message. 498 If receiver doesn't get all IKE Fragment Messages needed to 499 reassemble original Message for some Exchange within a timeout 500 interval, it acts according with Section 2.1 of [RFC5996], i.e. 502 retransmits the fragmented request Message (in case of Initiator) or 503 deems Exchange to have failed. If Exchange is abandoned, all 504 received so far IKE Fragment Messages for that Exchange MUST be 505 discarded. 507 2.6.1. Changes in Replay Protection Logic 509 According to [RFC5996] IKEv2 MUST reject message with the same 510 Message ID as it has seen before (taking into consideration Response 511 bit). This logic has already been updated by [RFC6311], which 512 deliberately allows any number of messages with zero Message ID. 513 This document also updates this logic: if message contains Encrypted 514 Fragment Payload, the values of Fragment Number and Total Fragments 515 fields from this payload MUST be used along with Message ID to detect 516 retransmissions and replays. 518 If Responder receives IKE Fragment Message after it received, 519 successfully verified and processed regular message with the same 520 Message ID, it means that response message didn't reach Initiator and 521 it activated IKE Fragmentation. If Fragment Number in Encrypted 522 Fragment Payload in this message is equal to 1, Responder MUST 523 fragment its response and retransmit it back to Initiator in 524 fragmented form. 526 If Responder receives a replay IKE Fragment Message for already 527 reassembled, verified and processed fragmented message, it MUST 528 retransmit response back to Initiator, but only if Fragment Number 529 field in Encrypted Fragment Payload is equal to 1 and MUST silently 530 discard received message otherwise. If Total Fragments field in 531 received IKE Fragment Message is greater than in IKE Fragment 532 Messages that already processed fragmented message was reassembled 533 from, Responder MAY refragment its response message using smaller 534 fragmentation threshold before resending it back to Initiator. In 535 this case Total Fragments field in new IKE Fragment Messages MUST be 536 greater than in previously sent IKE Fragment Messages. 538 If Initiator doesn't receive any of response IKE Fragment Messages 539 within a timeout interval, it MAY refragment request Message using 540 smaller fragmentation threshold before retransmitting it (see 541 Section 2.5.1). In this case Total Fragments field in new IKE 542 Fragment Messages MUST be greater than in previously sent IKE 543 Fragment Messages. Alternatively, if Initiator does receive some 544 (but not all) of response IKE Fragment Messages, it MAY retransmit 545 only the first of request IKE Fragment Messages, where Fragment 546 Number field is equal to 1. 548 3. Interaction with other IKE extensions 550 IKE Fragmentation is compatible with most of defined IKE extensions, 551 like IKE Session Resumption [RFC5723], Quick Crash Detection Method 552 [RFC6290] and so on. It neither affect their operation, nor is 553 affected by them. It is believed that IKE Fragmentation will also be 554 compatible with most future IKE extensions, if they follow general 555 principles of formatting, sending and receiving IKE messages, 556 described in [RFC5996]. 558 When IKE Fragmentation is used with IKE Session Resumption [RFC5723], 559 messages of IKE_SESSION_RESUME Exchange cannot be fragmented as they 560 don't contain Encrypted Payload. These messages may be large due to 561 ticket size. If this is the case the described solution won't help. 562 To avoid IP Fragmentation in this situation it is recommended to use 563 smaller tickets, e.g. by utilizing "ticket by reference" approach 564 instead of "ticket by value". 566 One exception that requires a special care is [RFC6311] - Protocol 567 Support for High Availability of IKEv2. As it deliberately allows 568 any number of synchronization Exchanges to have the same Message ID - 569 zero, standard replay detection logic, based on checking Message ID 570 is not applicable for such messages, and receiver has to check 571 message content to detect replays. When implementing IKE 572 Fragmentation along with [RFC6311], IKE Message ID Synchronization 573 messages MUST NOT be sent fragmented to simplify receiver's task of 574 detecting replays. Fortunately, these messages are small and there 575 is no point in fragmenting them anyway. 577 4. Transport Considerations 579 With IKE Fragmentation if any single IKE Fragment Message get lost, 580 receiver becomes unable to reassemble original Message. So, in 581 general, using IKE Fragmentation implies higher probability for the 582 Message not to be delivered to the peer. Although in most network 583 environments the difference will be insignificant, on some lossy 584 networks it may become noticeable. When using IKE Fragmentation 585 implementations MAY use longer timeouts and do more retransmits 586 before considering peer dead. 588 Note that Fragment Messages are not individually acknowledged. The 589 response Fragment Messages are sent back all together only when all 590 fragments of request are received, the original request Message is 591 reassembled and successfully processed. 593 5. Security Considerations 595 Most of the security considerations for IKE Fragmentation are the 596 same as those for base IKEv2 protocol described in [RFC5996]. This 597 extension introduces Encrypted Fragment Payload to protect content of 598 IKE Message Fragment. This allows receiver to individually check 599 authenticity of fragments, thus protecting peers from DoS attack. 601 Security Considerations Section of [RFC5996] mentions possible attack 602 on IKE by exhausting of the IP reassembly buffers. The mechanism, 603 described in this document, allows IKE to avoid IP-fragmentation and 604 therefore increases its robustness to DoS attacks. 606 The following attack is possible with IKE Fragmentation. An attacker 607 can initiate IKE_SA_INIT exchange, complete it, compute SK_a and SK_e 608 and then send a large, but still incomplete, set of IKE_AUTH 609 fragments. These fragments will pass the ICV check and will be 610 stored in reassembly buffers, but as the set is incomplete, the 611 reassembling will never succeed and eventually will time out. If the 612 set is large, this attack could potentially exhaust the receiver's 613 memory resources. 615 To mitigate the impact of this attack, it is RECOMMENDED that 616 receiver limits the number of fragments it stores in reassembling 617 queue so that the sum of the sizes of Encrypted Fragment Payload 618 contents (after decryption) for fragments that are already placed 619 into reassembling queue be less than some value that is reasonable 620 for the implementation. If the peer sends so many fragments, that 621 the above condition is not met, the receiver can consider this 622 situation to be either attack or as broken sender implementation. In 623 either case, the receiver SHOULD drop the connection and discard all 624 the received fragments. 626 This value can be predefined, can be a configurable option, or can be 627 calculated dynamically depending on receiver's memory load. In any 628 case, the value SHOULD NOT exceed 64 Kbytes (the maximum size of UDP 629 datagram) because any IKE message before fragmentation must be 630 shorter than that. 632 6. IANA Considerations 634 This document defines new Payload in the "IKEv2 Payload Types" 635 registry: 637 Encrypted and Authenticated Fragment SKF 639 This document also defines new Notify Message Types in the "Notify 640 Message Types - Status Types" registry: 642 IKEV2_FRAGMENTATION_SUPPORTED 644 7. Acknowledgements 646 The author would like to thank Tero Kivinen, Yoav Nir, Paul Wouters, 647 Yaron Sheffer, Joe Touch, Derek Atkins and others for their reviews 648 and valuable comments. 650 8. References 652 8.1. Normative References 654 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 655 Requirement Levels", BCP 14, RFC 2119, March 1997. 657 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 658 "Internet Key Exchange Protocol Version 2 (IKEv2)", 659 RFC 5996, September 2010. 661 [RFC6311] Singh, R., Kalyani, G., Nir, Y., Sheffer, Y., and D. 662 Zhang, "Protocol Support for High Availability of IKEv2/ 663 IPsec", RFC 6311, July 2011. 665 8.2. Informative References 667 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 668 September 1981. 670 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 671 November 1990. 673 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 674 (IPv6) Specification", RFC 2460, December 1998. 676 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 677 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 678 RFC 4787, January 2007. 680 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 681 Discovery", RFC 4821, March 2007. 683 [RFC5282] Black, D. and D. McGrew, "Using Authenticated Encryption 684 Algorithms with the Encrypted Payload of the Internet Key 685 Exchange version 2 (IKEv2) Protocol", RFC 5282, 686 August 2008. 688 [RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange 689 Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, 690 January 2010. 692 [RFC6290] Nir, Y., Wierbowski, D., Detienne, F., and P. Sethi, "A 693 Quick Crash Detection Method for the Internet Key Exchange 694 Protocol (IKE)", RFC 6290, June 2011. 696 [RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 697 and H. Ashida, "Common Requirements for Carrier-Grade NATs 698 (CGNs)", BCP 127, RFC 6888, April 2013. 700 [DOSUDPPROT] 701 Kaufman, C., Perlman, R., and B. Sommerfeld, "DoS 702 protection for UDP-based protocols", ACM Conference on 703 Computer and Communications Security, October 2003. 705 Appendix A. Design rationale 707 The simplest approach to the IKE fragmentation would have been to 708 fragment message that is fully formed and ready to be sent. But if 709 message got fragmented after being encrypted and authenticated, this 710 could open a possibility for a simple Denial of Service attack. The 711 attacker could infrequently emit forged but valid looking fragments 712 into the network, and some of these fragments would be fetched by 713 receiver into the reassembling queue. Receiver could not distinguish 714 forged fragments from valid ones and could only determine that some 715 of received fragments were forged when the whole message got 716 reassembled and check for its authenticity failed. 718 To prevent this kind of attack and also to reduce vulnerability to 719 some other kinds of DoS attacks it was decided to make fragmentation 720 before applying cryptographic protection to the message. In this 721 case each Fragment Message becomes individually encrypted and 722 authenticated, that allows receiver to determine forged fragments and 723 not to store them in the reassembling queue. 725 Appendix B. Correlation between IP Datagram size and Encrypted Payload 726 content size 728 For IPv4 Encrypted Payload content size is less than IP Datagram size 729 by the sum of the following values: 731 o IPv4 header size (typically 20 bytes, up to 60 if IP options are 732 present) 734 o UDP header size (8 bytes) 736 o non-ESP marker size (4 bytes if present) 738 o IKE Header size (28 bytes) 740 o Encrypted Payload header size (4 bytes) 742 o IV size (varying) 744 o padding and its size (at least 1 byte) 746 o ICV size (varying) 748 The sum may be estimated as 61..105 bytes + IV + ICV + padding. 750 For IPv6 Encrypted Payload content size is less than IP Datagram size 751 by the sum of the following values: 753 o IPv6 header size (40 bytes) 755 o IPv6 extension headers (optional, size varies) 757 o UDP header size (8 bytes) 759 o non-ESP marker size (4 bytes if present) 761 o IKE Header size (28 bytes) 763 o Encrypted Payload header size (4 bytes) 765 o IV size (varying) 767 o padding and its size (at least 1 byte) 769 o ICV size (varying) 771 If no extension header is present, the sum may be estimated as 81..85 772 bytes + IV + ICV + padding. If extension headers are present, the 773 payload content size is further reduced by the sum of the size of the 774 extension headers. The length of each extension header can be 775 calculated as 8 * (Hdr Ext Len) bytes except for the fragment header 776 which is always 8 bytes in length. 778 Author's Address 780 Valery Smyslov 781 ELVIS-PLUS 782 PO Box 81 783 Moscow (Zelenograd) 124460 784 Russian Federation 786 Phone: +7 495 276 0211 787 Email: svan@elvis.ru