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