idnits 2.17.1 draft-ietf-ipsecme-ikev2-fragmentation-04.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 (October 18, 2013) is 3836 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 151, 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 October 18, 2013 5 Expires: April 21, 2014 7 IKEv2 Fragmentation 8 draft-ietf-ipsecme-ikev2-fragmentation-04 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 April 21, 2014. 33 Copyright Notice 35 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . 9 62 2.6. Receiving IKE Fragment Message . . . . . . . . . . . . . . 10 63 2.6.1. Changes in Replay Protection Logic . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . . 19 73 Appendix B. Correlation between IP Datagram size and 74 Encrypted Payload content size . . . . . . . . . . . 20 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21 77 1. Introduction 79 The Internet Key Exchange Protocol version 2 (IKEv2), specified in 80 [RFC5996], uses UDP as a transport for its messages. When IKE 81 message size exceeds path MTU, it gets fragmented by IP level. The 82 problem is that some network devices, specifically some NAT boxes, 83 don't allow IP fragments to pass through. This apparently blocks IKE 84 communication and, therefore, prevents peers from establishing IPsec 85 SA. 87 The solution to the problem described in this document is to perform 88 fragmentation of large messages by IKE itself, replacing them by 89 series of smaller messages. In this case the resulting IP Datagrams 90 will be small enough so that no fragmentation on IP level will take 91 place. 93 1.1. Conventions Used in This Document 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [RFC2119]. 99 2. Protocol details 101 2.1. Overview 103 The idea of the protocol is to split large IKE message into the set 104 of smaller ones, calling IKE Fragment Messages. Fragmentation takes 105 place before the original message is encrypted and authenticated, so 106 that each IKE Fragment Message receives individual protection. On 107 the receiving side IKE Fragment Messages are collected, verified, 108 decrypted and merged together to get the original message before 109 encryption. For design rationale see Appendix A. 111 2.2. Limitations 113 As IKE Fragment Messages are cryptographically protected, SK_a and 114 SK_e must already be calculated. In general, it means that original 115 message can be fragmented if and only if it contains Encrypted 116 Payload. 118 This implies that messages of the IKE_SA_INIT Exchange cannot be 119 fragmented. In most cases this is not a problem, since IKE_SA_INIT 120 messages are usually small enough to avoid IP fragmentation. But in 121 some cases (advertising a badly structured long list of algorithms, 122 using large MODP Groups, etc.) these messages may become fairly large 123 and get fragmented by IP level. In this case the described solution 124 won't help. 126 Among existing IKEv2 extensions, messages of IKE_SESSION_RESUME 127 Exchange, defined in [RFC5723], cannot be fragmented either. See 128 Section 3 for details. 130 Another limitation is that the minimal size of IP Datagram bearing 131 IKE Fragment Message is about 100 bytes depending on the algorithms 132 employed. According to [RFC0791] the minimum IP Datagram size that 133 is guaranteed not to be further fragmented is 68 bytes. So, even the 134 smallest IKE Fragment Messages could be fragmented by IP level in 135 some circumstances. But such extremely small PMTU sizes are very 136 rare in real life. 138 2.3. Negotiation 140 Initiator MAY indicate its support for IKE Fragmentation and 141 willingness to use it by including Notification Payload of type 142 IKE_FRAGMENTATION_SUPPORTED in IKE_SA_INIT request message. If 143 Responder also supports this extension and is willing to use it, it 144 includes this notification in response message. 146 Initiator Responder 147 ----------- ----------- 148 HDR, SAi1, KEi, Ni, 149 [N(IKE_FRAGMENTATION_SUPPORTED)] --> 151 <-- HDR, SAr1, KEr, Nr, [CERTREQ], 152 [N(IKE_FRAGMENTATION_SUPPORTED)] 154 The Notify payload is formatted as follows: 156 1 2 3 157 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 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | Next Payload |C| RESERVED | Payload Length | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 |Protocol ID(=0)| SPI Size (=0) | Notify Message Type | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 o Protocol ID (1 octet) MUST be 0. 166 o SPI Size (1 octet) MUST be 0, meaning no SPI is present. 168 o Notify Message Type (2 octets) - MUST be xxxxx, the value assigned 169 for IKE_FRAGMENTATION_SUPPORTED by IANA. 171 This Notification contains no data. 173 2.4. Using IKE Fragmentation 175 IKE Fragmentation MUST NOT be used unless both peers indicated their 176 support for it. After IKE Fragmentation is negotiated, it is up to 177 Initiator of each Exchange, whether to use it or not. In most cases 178 IKE Fragmentation will be used in IKE_AUTH Exchange, especially if 179 certificates are employed. Initiator may first try to send 180 unfragmented message and resend it fragmented only if it didn't 181 receive response after several retransmissions, or it may always send 182 messages fragmented (but see Section 3), or it may fragment only 183 large messages and messages causing large responses. 185 In general the following guidelines are applicable for initiator: 187 o Initiator MAY fragment outgoing message if it has some knowledge 188 (possibly from lower layer or from configuration) or suspicions 189 that either request or response message will be fragmented by IP 190 level. 192 o Initiator SHOULD fragment outgoing message if it has some 193 knowledge (possibly from lower layer or from configuration) or 194 suspicions that either request or response message will be 195 fragmented by IP level and IKE Fragmentation was already used in 196 one of previous Exchanges in the context of the current IKE SA. 198 o Initiator SHOULD NOT fragment outgoing message if both request and 199 response messages of the Exchange are small enough not to cause 200 fragmentation on IP level (for example, there is no point in 201 fragmenting Liveness Check messages). 203 In general the following guidelines are applicable for responder: 205 o Responder SHOULD send response message in the same form 206 (fragmented or not) as corresponded request message. If it 207 received unfragmented request message, responded with unfragmented 208 response message and then receives fragmented retransmission of 209 the same request, it SHOULD resend its response back to Initiator 210 fragmented. 212 o Responder MAY respond to unfragmented message with fragmented 213 response if it has some knowledge (possibly from lower layer or 214 from configuration) or suspicions that response message will be 215 fragmented by IP level. 217 o Responder MAY respond to fragmented message with unfragmented 218 response if the size of the response message is less than the 219 smallest fragmentation threshold, supported by Responder (for 220 example, there is no point in fragmenting Liveness Check 221 messages). 223 2.5. Fragmenting Message 225 Message to be fragmented MUST contain Encrypted Payload. For the 226 purpose of IKE Fragment Messages construction original (unencrypted) 227 content of Encrypted Payload is split into chunks. The content is 228 treated as a binary blob and is split regardless of inner Payloads 229 boundaries. Each of resulting chunks is treated as an original 230 content of Encrypted Fragment Payload and is then encrypted and 231 authenticated. Thus, the Encrypted Fragment Payload contains a chunk 232 of the original content of Encrypted Payload in encrypted form. The 233 cryptographic processing of Encrypted Fragment Payload is identical 234 to Section 3.14 of [RFC5996], as well as documents updating it for 235 particular algorithms or modes, such as [RFC5282]. 237 The Encrypted Fragment Payload, similarly to the Encrypted Payload, 238 if present in a message, MUST be the last payload in the message. 240 The Encrypted Fragment Payload is denoted SKF{...} and its payload 241 type is XXX (TBA by IANA). 243 1 2 3 244 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 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Next Payload |C| RESERVED | Payload Length | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Fragment Number | Total Fragments | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Initialization Vector | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 ~ Encrypted content ~ 253 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | | Padding (0-255 octets) | 255 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 256 | | Pad Length | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 ~ Integrity Checksum Data ~ 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 Encrypted Fragment Payload 263 o Next Payload (1 octet) - in the very first fragment MUST be set to 264 Payload Type of the first inner Payload (similarly to the 265 Encrypted Payload). In the rest fragments MUST be set to zero. 267 o Fragment Number (2 octets) - current fragment number starting from 268 1. This field MUST be less than or equal to the next field, Total 269 Fragments. This field MUST NOT be zero. 271 o Total Fragments (2 octets) - number of fragments original message 272 was divided into. With PMTU discovery this field plays additional 273 role. See Section 2.5.2 for details. This field MUST NOT be 274 zero. 276 The other fields are identical to those specified in Section 3.14 of 277 [RFC5996]. 279 When prepending IKE Header, Length field MUST be adjusted to reflect 280 the length of constructed message and Next Payload field MUST reflect 281 payload type of the first Payload in the constructed message (that in 282 most cases will be Encrypted Fragment Payload). All newly 283 constructed messages MUST retain the same Message ID as original 284 message. After prepending IKE Header and possibly any of Payloads 285 that precedes Encrypted Payload in original message (see 286 Section 2.5.3), the resulting messages are sent to the peer. 288 Below is an example of fragmenting a message. 290 HDR(MID=n), SK(NextPld=PLD1) {PLD1 ... PLDN} 291 Original Message 293 HDR(MID=n), SKF(NextPld=PLD1, Frag#=1, TotalFrags=m) {...}, 294 HDR(MID=n), SKF(NextPld=0, Frag#=2, TotalFrags=m) {...}, 295 ... 296 HDR(MID=n), SKF(NextPld=0, Frag#=m, TotalFrags=m) {...} 298 IKE Fragment Messages 300 2.5.1. Selecting Fragment Size 302 When splitting content of Encrypted into chunks sender SHOULD chose 303 size of those chunks so, that resulting IP Datagram size not exceed 304 some fragmentation threshold - be small enough to avoid IP 305 fragmentation. 307 If sender has some knowledge about PMTU size it MAY use it. If 308 sender is a Responder in the Exchange and it has received fragmented 309 request, it MAY use maximum size of received IKE Fragment Message IP 310 Datagrams as threshold when constructing fragmented response. 312 Otherwise for messages to be sent over IPv6 it is RECOMMENDED to use 313 value 1280 bytes as a maximum IP Datagram size ([RFC2460]). For 314 messages to be sent over IPv4 it is RECOMMENDED to use value 576 315 bytes as a maximum IP Datagram size. 317 According to [RFC0791] the minimum IPv4 datagram size that is 318 guaranteed not to be further fragmented is 68 bytes, but it is 319 generally impossible to use such small value for solution, described 320 in this document. Using 576 bytes is a compromise - the value is 321 large enough for the presented solution and small enough to avoid IP 322 fragmentation in most situations. Several other UDP-based protocol 323 assume the value 576 bytes as a safe low limit for IP datagrams size 324 (Syslog, DNS, etc.). Sender MAY use other values if they are 325 appropriate. 327 See Appendix B for correlation between IP Datagram size and Encrypted 328 Payload content size. 330 2.5.2. PMTU Discovery 332 Initiator MAY try to discover path MTU by using several values of 333 fragmentation threshold, provided that it starts with larger values 334 and fragments message again with next smaller value if it doesn't 335 receive response in a reasonable time after several retransmissions. 337 In case of PMTU discovery Total Fragments field is used to 338 distinguish between different sets of fragments, i.e. the sets that 339 were obtained by fragmenting original message using different 340 fragmentation thresholds. As sender will start from larger fragments 341 and then make them smaller, the value in Total Fragments field will 342 increase with each new try. When selecting next smaller value of 343 fragmentation threshold, sender MUST ensure that the value in Total 344 Fragments field is really increased. This requirement should not 345 become a problem for the sender, as PMTU discovery in IKE is supposed 346 to be coarse-grained, so difference between previous and next 347 fragmentation thresholds will be significant anyway. The necessity 348 to distinguish between the sets is vital for receiver as receiving 349 any valid fragment from newer set will mean that it have to start 350 reassembling over and not to mix fragments from different sets. 352 2.5.3. Fragmenting Messages containing unencrypted Payloads 354 Currently no one of IKEv2 Exchanges defines messages, containing both 355 unencrypted payloads and payloads, protected by Encrypted Payload. 356 But IKEv2 doesn't forbid such messages. If some future IKEv2 357 extension defines such a message and it needs to be fragmented, all 358 unprotected payloads MUST be in the first fragment, along with 359 Encrypted Fragment Payload, which MUST be present in any IKE Fragment 360 Message. 362 Below is an example of fragmenting message, containing both encrypted 363 and unencrypted Payloads. 365 HDR(MID=n), PLD0, SK(NextPld=PLD1) {PLD1 ... PLDN} 367 Original Message 369 HDR(MID=n), PLD0, SKF(NextPld=PLD1, Frag#=1, TotalFrags=m) {...}, 370 HDR(MID=n), SKF(NextPld=0, Frag#=2, TotalFrags=m) {...}, 371 ... 372 HDR(MID=n), SKF(NextPld=0, Frag#=m, TotalFrags=m) {...} 374 IKE Fragment Messages 376 Note, that the size of each IP Datagram bearing IKE Fragment Messages 377 SHOULD NOT exceed fragmentation threshold, including the very first, 378 which contains unprotected Payloads. This will reduce the size of 379 Encrypted Fragment Payload content in the first IKE Fragment Message 380 to accommodate unprotected Payloads. In extreme cases Encrypted 381 Fragment Payload will contain no data, but it is still MUST be 382 present in the message, because only its presence allows receiver to 383 distinguish IKE Fragment Message from regular IKE message. 385 2.6. Receiving IKE Fragment Message 387 Receiver identifies IKE Fragment Message by the presence of Encrypted 388 Fragment Payload in it. Note, that it is possible for this payload 389 to be not the first (and the only) payload in the message (see 390 Section 2.5.3). But for all currently defined IKEv2 exchanges this 391 payload will be the first and the only payload in the message. 393 Upon receiving IKE Fragment Message the following actions are 394 performed: 396 o Check message validity - in particular, check whether values of 397 Fragment Number and Total Fragments in Encrypted Fragment Payload 398 are valid. The following tests need to be performed. 400 * check that Fragment Number and Total Fragments fields are non- 401 zero 403 * check that Fragment Number field is less than or equal to Total 404 Fragments field 406 * if reassembling has already started, check that Total Fragments 407 field is equal to or greater than Total Fragments field in 408 fragments, that have already received 410 If either of this tests fails message MUST be silently discarded. 412 o Check, that this IKE Fragment Message is new for the receiver and 413 not a replay. If IKE Fragment message with the same Message ID, 414 same Fragment Number and same Total Fragments fields was already 415 received and successfully processed, this message is considered a 416 replay and MUST be silently discarded. 418 o Verify IKE Fragment Message authenticity by checking ICV in 419 Encrypted Fragment Payload. If ICV check fails message MUST be 420 silently discarded. 422 o If reassembling isn't finished yet and Total Fragments field in 423 received IKE Fragment Message is greater than this field in 424 previously received fragments, receiver MUST discard all received 425 fragments and start reassembling over with just received IKE 426 Fragment Message. 428 o Store message in the list waiting for the rest of fragments to 429 arrive. 431 When all IKE Fragment Messages (as indicated in the Total Fragments 432 field) are received, content of their Encrypted Fragment Payloads is 433 decrypted and merged together to form content of original Encrypted 434 Payload, and, therefore, along with IKE Header and unencrypted 435 Payloads (if any), original message. Then it is processed as if it 436 was received, verified and decrypted as regular unfragmented message. 438 If receiver does't get all IKE Fragment Messages needed to reassemble 439 original Message for some Exchange within a timeout interval, it acts 440 according with Section 2.1 of [RFC5996], i.e. retransmits the 441 fragmented request Message (in case of Initiator) or deems Exchange 442 to have failed. If Exchange is abandoned, all received so far IKE 443 Fragment Messages for that Exchange MUST be discarded. 445 2.6.1. Changes in Replay Protection Logic 447 According to [RFC5996] IKEv2 MUST reject message with the same 448 Message ID as it has seen before (taking into consideration Response 449 bit). This logic has already been updated by [RFC6311], which 450 deliberately allows any number of messages with zero Message ID. 451 This document also updates this logic: if message contains Encrypted 452 Fragment Payload, the values of Fragment Number and Total Fragments 453 fields from this payload MUST be used along with Message ID to detect 454 retransmissions and replays. 456 If Responder receives IKE Fragment Message after it received, 457 successfully verified and processed regular message with the same 458 Message ID, it means that response message didn't reach Initiator and 459 it activated IKE Fragmentation. If Fragment Number in Encrypted 460 Fragment Payload in this message is equal to 1, Responder MUST 461 fragment its response and retransmit it back to Initiator in 462 fragmented form. 464 If Responder receives a replay IKE Fragment Message for already 465 reassembled, verified and processed fragmented message, it MUST 466 retransmit response back to Initiator, but only if Fragment Number 467 field in Encrypted Fragment Payload is equal to 1 and MUST silently 468 discard received message otherwise. If Total Fragments field in 469 received IKE Fragment Message is greater than in IKE Fragment 470 Messages that already processed fragmented message was reassembled 471 from, Responder MAY refragment its response message using smaller 472 fragmentation threshold before resending it back to Initiator. In 473 this case Total Fragments field in new IKE Fragment Messages MUST be 474 greater than in previously sent IKE Fragment Messages. 476 If Initiator doesn't receive any of response IKE Fragment Messages 477 withing a timeout interval, it MAY refragment request Message using 478 smaller fragmentation threshold before retransmitting it (see 479 Section 2.5.1). In this case Total Fragments field in new IKE 480 Fragment Messages MUST be greater than in previously sent IKE 481 Fragment Messages. Alternatively, if Initiator does receive some 482 (but not all) of response IKE Fragment Messages, it MAY retransmit 483 only the first of request IKE Fragment Messages, where Fragment 484 Number field is equal to 1. 486 3. Interaction with other IKE extensions 488 IKE Fragmentation is compatible with most of defined IKE extensions, 489 like IKE Session Resumption [RFC5723], Quick Crash Detection Method 490 [RFC6290] and so on. It neither affect their operation, nor is 491 affected by them. It is believed that IKE Fragmentation will also be 492 compatible with most future IKE extensions, if they follow general 493 principles of formatting, sending and receiving IKE messages, 494 described in [RFC5996]. 496 When IKE Fragmentation is used with IKE Session Resumption [RFC5723], 497 messages of IKE_SESSION_RESUME Exchange cannot be fragmented as they 498 don't contain Encrypted Payload. These messages may be large due to 499 ticket size. If this is the case the described solution won't help. 500 To avoid IP Fragmentation in this situation it is recommended to use 501 smaller tickets, e.g. by utilizing "ticket by reference" approach 502 instead of "ticket by value". 504 One exception that requires a special care is [RFC6311] - Protocol 505 Support for High Availability of IKEv2. As it deliberately allows 506 any number of synchronization Exchanges to have the same Message ID - 507 zero, standard replay detection logic, based on checking Message ID 508 is not applicable for such messages, and receiver has to check 509 message content to detect replays. When implementing IKE 510 Fragmentation along with [RFC6311], IKE Message ID Synchronization 511 messages MUST NOT be sent fragmented to simplify receiver's task of 512 detecting replays. Fortunately, these messages are small and there 513 is no point in fragmenting them anyway. 515 4. Transport Considerations 517 With IKE Fragmentation if any single IKE Fragment Message get lost, 518 receiver becomes unable to reassemble original Message. So, in 519 general, using IKE Fragmentation implies higher probability for the 520 Message not to be delivered to the peer. Although in most network 521 environments the difference will be insignificant, on some lossy 522 networks it may become noticeable. When using IKE Fragmentation 523 implementations MAY use longer timeouts and do more retransmits 524 before considering peer dead. 526 Note that Fragment Messages are not individually acknowledged. The 527 response Fragment Messages are sent back all together only when all 528 fragments of request are received, the original request Message is 529 reassembled and successfully processed. 531 5. Security Considerations 533 Most of the security considerations for IKE Fragmentation are the 534 same as those for base IKEv2 protocol described in [RFC5996]. This 535 extension introduces Encrypted Fragment Payload to protect content of 536 IKE Message Fragment. This allows receiver to individually check 537 authenticity of fragments, thus protecting peers from Denial of 538 Service attack. 540 6. IANA Considerations 542 This document defines new Payload in the "IKEv2 Payload Types" 543 registry: 545 Encrypted Fragment Payload SKF 547 This document also defines new Notify Message Types in the "Notify 548 Messages Types - Status Types" registry: 550 IKE_FRAGMENTATION_SUPPORTED 552 7. Acknowledgements 554 The author would like to thank Tero Kivinen, Yoav Nir, Paul Wouters, 555 Yaron Sheffer and others for their reviews and valueable comments. 557 8. References 559 8.1. Normative References 561 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 562 Requirement Levels", BCP 14, RFC 2119, March 1997. 564 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 565 "Internet Key Exchange Protocol Version 2 (IKEv2)", 566 RFC 5996, September 2010. 568 [RFC6311] Singh, R., Kalyani, G., Nir, Y., Sheffer, Y., and D. 569 Zhang, "Protocol Support for High Availability of IKEv2/ 570 IPsec", RFC 6311, July 2011. 572 8.2. Informative References 574 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 575 September 1981. 577 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 578 (IPv6) Specification", RFC 2460, December 1998. 580 [RFC5282] Black, D. and D. McGrew, "Using Authenticated Encryption 581 Algorithms with the Encrypted Payload of the Internet Key 582 Exchange version 2 (IKEv2) Protocol", RFC 5282, 583 August 2008. 585 [RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange 586 Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, 587 January 2010. 589 [RFC6290] Nir, Y., Wierbowski, D., Detienne, F., and P. Sethi, "A 590 Quick Crash Detection Method for the Internet Key Exchange 591 Protocol (IKE)", RFC 6290, June 2011. 593 Appendix A. Design rationale 595 The simplest approach to the IKE fragmentation would have been to 596 fragment message that is fully formed and ready to be sent. But if 597 message got fragmented after being encrypted and authenticated, this 598 could open a possibility for a simple Denial of Service attack. The 599 attacker could infrequently emit forged but looking valid fragments 600 into the network, and some of these fragments would be fetched by 601 receiver into the reassempling queue. Receiver could not distinguish 602 forged fragments from valid ones and could only determine that some 603 of received fragments were forged when the whole message got 604 reassembled and check for its authenticity failed. 606 To prevent this kind of attack and also to reduce vulnerability to 607 some other kinds of DoS attacks it was decided to make fragmentation 608 before applying cryptographic protection to the message. In this 609 case each Fragment Message becomes individually encrypted and 610 authenticated, that allows receiver to determine forgeg fragments and 611 not to fetch them into the reassempling queue. 613 Appendix B. Correlation between IP Datagram size and Encrypted Payload 614 content size 616 For IPv4 Encrypted Payload content size is less than IP Datagram size 617 by the sum of the following values: 619 o IPv4 header size (typically 20 bytes, up to 60 if IP options are 620 present) 622 o UDP header size (8 bytes) 624 o non-ESP marker size (4 bytes if present) 626 o IKE Header size (28 bytes) 628 o Encrypted Payload header size (4 bytes) 630 o IV size (varying) 632 o padding and its size (at least 1 byte) 634 o ICV size (varying) 636 The sum may be estimated as 61..105 bytes + IV + ICV + padding. 638 For IPv6 this estimation is difficult as there may be varying IPv6 639 Extension headers included. 641 Author's Address 643 Valery Smyslov 644 ELVIS-PLUS 645 PO Box 81 646 Moscow (Zelenograd) 124460 647 RU 649 Phone: +7 495 276 0211 650 Email: svan@elvis.ru