idnits 2.17.00 (12 Aug 2021) /tmp/idnits47799/draft-ietf-ipsecme-ikev2-fragmentation-00.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 (July 2, 2013) is 3245 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 138, 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 July 2, 2013 5 Expires: January 3, 2014 7 IKEv2 Fragmentation 8 draft-ietf-ipsecme-ikev2-fragmentation-00 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 January 3, 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 . . . . . . . . . . . . 11 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 66 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 68 7.1. Normative References . . . . . . . . . . . . . . . . . . . 15 69 7.2. Informative References . . . . . . . . . . . . . . . . . . 15 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 72 1. Introduction 74 The Internet Key Exchange Protocol version 2 (IKEv2), specified in 75 [RFC5996], uses UDP as a transport for its messages. When IKE 76 message size exceeds path MTU, it gets fragmented by IP level. The 77 problem is that some network devices, specifically some NAT boxes, 78 don't allow IP fragments to pass through. This apparently blocks IKE 79 communication and, therefore, prevents peers from establishing IPsec 80 SA. 82 The solution to the problem described in this document is to perform 83 fragmentation of large messages by IKE itself, replacing them by 84 series of smaller messages. In this case the resulting IP Datagrams 85 will be small enough so that no fragmentation on IP level will take 86 place. 88 1.1. Conventions Used in This Document 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in [RFC2119]. 94 2. Protocol details 96 2.1. Overview 98 The idea of the protocol is to split large IKE message into the set 99 of smaller ones, calling Fragment Messages. On the receiving side 100 Fragment Messages are collected and merged together to get original 101 message. In general this approach increases receiver's vulnerability 102 to Denial of Service attack. To reduce this vulnerability Fragment 103 Messages are individually encrypted and authenticated. This implies 104 that message cannot be fragmented until shared secret is calculated. 106 2.2. Limitations 108 In general, original message can be fragmented if and only if it 109 contains Encrypted Payload. It means that messages in IKE_SA_INIT 110 Exchange cannot be fragmented. In most cases this is not a problem, 111 since IKE_SA_INIT messages are usually small enough to avoid IP 112 fragmentation. But in some cases (advertising a badly structured 113 long list of algorithms, using large MODP Groups, etc.) those 114 messages may become fairly large and get fragmented by IP level. In 115 these cases the described solution won't help. 117 Another limitation is that the minimal size of IP Datagram bearing 118 IKE Fragment Message is about 100 bytes depending on the algorithms 119 employed. According to [RFC0791] the minimum IP Datagram size that 120 is guaranteed not to be further fragmented is 68 bytes. So, even the 121 smallest IKE Fragment Messages could be fragmented by IP level in 122 some circumstances. But such extremely small PMTU sizes are very 123 rare in real life. 125 2.3. Negotiation 127 Initiator MAY indicate its support for IKE Fragmentation and 128 willingness to use it by including Notification Payload of type 129 IKE_FRAGMENTATION_SUPPORTED in IKE_SA_INIT request message. If 130 Responder also supports this extension and is willing to use it, it 131 includes this notification in response message. 133 Initiator Responder 134 ----------- ----------- 135 HDR, SAi1, KEi, Ni, 136 [N(IKE_FRAGMENTATION_SUPPORTED)] --> 138 <-- HDR, SAr1, KEr, Nr, [CERTREQ], 139 [N(IKE_FRAGMENTATION_SUPPORTED)] 141 The Notify payload is formatted as follows: 143 1 2 3 144 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 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | Next Payload |C| RESERVED | Payload Length | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 |Protocol ID(=0)| SPI Size (=0) | Notify Message Type | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 o Protocol ID (1 octet) MUST be 0. 153 o SPI Size (1 octet) MUST be 0, meaning no SPI is present. 155 o Notify Message Type (2 octets) - MUST be xxxxx, the value assigned 156 for IKE_FRAGMENTATION_SUPPORTED by IANA. 158 This Notification contains no data. 160 2.4. Using IKE Fragmentation 162 After IKE Fragmentation is negotiated, it is up to Initiator of each 163 Exchange, whether to use it or not. In most cases IKE Fragmentation 164 will be used in IKE_AUTH Exchange, especially if certificates are 165 employed. Initiator may first try to send unfragmented message and 166 resend it fragmented only if it didn't receive response after several 167 retransmissions, or it may always send messages fragmented (but see 168 Section 3), or it may fragment only large messages and messages 169 causing large responses. 171 In general the following guidelines are applicable: 173 o Initiator MAY fragment outgoing message if it suspects that either 174 request or response message may be fragmented by IP level. 176 o Initiator SHOULD fragment outgoing message if it suspects that 177 either request or response message may be fragmented by IP level 178 and IKE Fragmentation was already used in one of previous 179 Exchanges in the context of the current IKE SA. 181 o Initiator SHOULD NOT fragment outgoing message if both request and 182 response messages of the Exchange are small enough not to cause 183 fragmentation on IP level (for example, there is no point in 184 fragmenting Liveness Check messages). 186 Responder MUST send response message in the same form (fragmented or 187 not) as corresponded request message. If it received unfragmented 188 request message, responded with unfragmented response message and 189 then received fragmented retransmission of the same request, it MUST 190 resend its response back to Initiator fragmented. 192 2.5. Fragmenting Message 194 Message to be fragmented MUST contain Encrypted Payload. For the 195 purpose of IKE Fragment Messages construction original (unencrypted) 196 content of Encrypted Payload is broken down into parts. Its content 197 is treated as a binary blob and is broken down regardless of inner 198 Payloads boundaries. Each of resulting parts is treated as a content 199 for Encrypted Fragment Payload. 201 The Encrypted Fragment Payload, denoted SKF{...}, contains other 202 payloads in encrypted form. The Encrypted Fragment Payload, as well 203 as Encrypted Payload from [RFC5996], if present in a message, MUST be 204 the last payload in the message. 206 The payload type for an Encrypted Fragment payload is XXX (TBA by 207 IANA). 209 1 2 3 210 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 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | Next Payload |C| RESERVED | Payload Length | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | Fragment Number | Total Fragments | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Initialization Vector | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 ~ Encrypted content ~ 219 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | | Padding (0-255 octets) | 221 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 222 | | Pad Length | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 ~ Integrity Checksum Data ~ 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 Encrypted Fragment Payload 229 o Next Payload (1 octet) - in the very first fragment MUST be set to 230 Payload Type of the first inner Payload (as in Encrypted Payload). 231 In the rest fragments MUST be set to zero. 233 o Fragment Number (2 octets) - current fragment number starting from 234 1. This field MUST be less than or equal to the next field, Total 235 Fragments. 237 o Total Fragments (2 octets) - number of fragments original message 238 was divided into. This field MUST NOT be zero. 240 Other fields are identical to those specified in Section 3.14 of 241 [RFC5996]. 243 When prepending IKE Header, Length field MUST be adjusted to reflect 244 the length of constructed message and Next Payload field MUST reflect 245 payload type of the first Payload in the constructed message (that in 246 most cases will be Encrypted Fragment Payload). All newly 247 constructed messages MUST retain the same Message ID as original 248 message. After prepending IKE Header and possibly any of Payloads 249 that precedes Encrypted Payload in original message (see 250 Section 2.5.2), the resulting messages are sent to the peer. 252 Below is an example of fragmenting some message. 254 HDR(MID=n), SK(NextPld=PLD1) {PLD1 ... PLDN} 256 Original Message 258 HDR(MID=n), SKF(NextPld=PLD1, Frag#=1, TotalFrags=m) {...}, 259 HDR(MID=n), SKF(NextPld=0, Frag#=2, TotalFrags=m) {...}, 260 ... 261 HDR(MID=n), SKF(NextPld=0, Frag#=m, TotalFrags=m) {...} 263 IKE Fragment Messages 265 2.5.1. Selecting Fragment Size 267 When breaking content of Encrypted Payload down into parts sender 268 SHOULD chose size of those parts so, that resulting IP Datagram size 269 not exceed some fragmentation threshold - be small enough to avoid IP 270 fragmentation. 272 If sender has some knowledge about PMTU size it MAY use it. If 273 sender is a Responder in the Exchange and it has received fragmented 274 request, it MAY use maximum size of received IKE Fragment Message IP 275 Datagrams as threshold when constructing fragmented response. 277 Otherwise for messages to be sent over IPv6 it is RECOMMENDED to use 278 value 1280 bytes as a maximum IP Datagram size ([RFC2460]). For 279 messages to be sent over IPv4 it is RECOMMENDED to use value 576 280 bytes as a maximum IP Datagram size. 282 For IPv4 Encrypted Payload content size is less than IP Datagram size 283 by the sum of the following values: 285 o IPv4 header size (typically 20 bytes, up to 60 if IP options are 286 present) 288 o UDP header size (8 bytes) 290 o non-ESP marker size (4 bytes if present) 292 o IKE Header size (28 bytes) 294 o Encrypted Payload header size (4 bytes) 296 o IV size (varying) 298 o padding and its size (at least 1 byte) 300 o ICV size (varying) 302 The sum may be estimated as 61..105 bytes + IV + ICV + padding. For 303 IPv6 this estimation is difficult as there may be varying IPv6 304 Extension headers included. 306 According to [RFC0791] the minimum IPv4 datagram size that is 307 guaranteed not to be further fragmented is 68 bytes, but it is 308 generally impossible to use such small value for solution, described 309 in this document. Using 576 bytes is a compromise - the value is 310 large enough for the presented solution and small enough to avoid IP 311 fragmentation in most situations. Several other UDP-based protocol 312 assume the value 576 bytes as a safe low limit for IP datagrams size 313 (Syslog, DNS, etc.). Sender MAY use other values if they are 314 appropriate. 316 Initiator MAY try to discover path MTU by using several values of 317 fragmentation threshold, provided that it starts with larger values 318 and fragments message again with next smaller value if it doesn't 319 receive response in a reasonable time after several retransmissions. 320 In this case using next smaller value MUST result in increasing Total 321 Fragments field. 323 2.5.2. Fragmenting Messages containing unencrypted Payloads 325 Currently no one of IKEv2 Exchanges defines messages, containing both 326 unencrypted payloads and payloads, protected by Encrypted Payload. 327 But IKEv2 doesn't forbid such messages. If some future IKEv2 328 extension defines such a message and it needs to be fragmented, all 329 unprotected payloads MUST be in the first fragment, along with 330 Encrypted Fragment Payload, which MUST be present in any IKE Fragment 331 Message. 333 Below is an example of fragmenting message, containing both encrypted 334 and unencrypted Payloads. 336 HDR(MID=n), PLD0, SK(NextPld=PLD1) {PLD1 ... PLDN} 338 Original Message 340 HDR(MID=n), PLD0, SKF(NextPld=PLD1, Frag#=1, TotalFrags=m) {...}, 341 HDR(MID=n), SKF(NextPld=0, Frag#=2, TotalFrags=m) {...}, 342 ... 343 HDR(MID=n), SKF(NextPld=0, Frag#=m, TotalFrags=m) {...} 345 IKE Fragment Messages 347 Note, that the size of each IP Datagram bearing IKE Fragment Messages 348 SHOULD NOT exceed fragmentation threshold, including the very first, 349 which contains unprotected Payloads. This will reduce the size of 350 Encrypted Fragment Payload content in the first IKE Fragment Message 351 to accommodate unprotected Payloads. In extreme cases Encrypted 352 Fragment Payload will contain no data, but it is still MUST be 353 present in the message, because only its presence allows receiver to 354 distinguish IKE Fragment Message from regular IKE message. 356 2.6. Receiving IKE Fragment Message 358 Receiver identifies IKE Fragment Message by the presence of Encrypted 359 Fragment Payload in it. Note, that it is possible for this payload 360 to be not the first (and the only) payload in the message (see 361 Section 2.5.2). But for all currently defined IKEv2 exchanges this 362 payload will be the first and the only payload in the message. 364 Upon receiving IKE Fragment Message the following actions are 365 performed: 367 o Check message validity - in particular, check whether values of 368 Fragment Number and Total Fragments in Encrypted Fragment Payload 369 are valid. If not - message MUST be silently discarded. 371 o Check, that this IKE Fragment Message is new for the receiver and 372 not a replay. If IKE Fragment message with the same Message ID, 373 same Fragment Number and same Total Fragments fields was already 374 received and successfully processed, this message is considered a 375 replay and MUST be discarded. 377 o Verify IKE Fragment Message authenticity by checking ICV in 378 Encrypted Fragment Payload. If ICV check fails message MUST be 379 silently discarded. 381 o If reassembling isn't finished yet and Total Fragments field in 382 received IKE Fragment Message is greater than this field in 383 previously received fragments, receiver MUST discard all received 384 fragments and start reassembling over with just received IKE 385 Fragment Message. 387 o Store message in the list waiting for the rest of fragments to 388 arrive. 390 When all IKE Fragment Messages (as indicated in the Total Fragments 391 field) are received, content of their Encrypted Fragment Payloads is 392 decrypted and merged together to form content of original Encrypted 393 Payload, and, therefore, along with IKE Header, original message. 394 Then it is processed as if it was received, verified and decrypted as 395 as regular unfragmented message. 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. 422 3. Interaction with other IKE extensions 424 IKE Fragmentation is compatible with most of defined IKE extensions, 425 like IKE Session Resumption [RFC5723], Quick Crash Detection Method 426 [RFC6290] and so on. It neither affect their operation, nor is 427 affected by them. It is believed that IKE Fragmentation will also be 428 compatible with most future IKE extensions, if they follow general 429 principles of formatting, sending and receiving IKE messages, 430 described in [RFC5996]. 432 The notable exception that requires a special care is [RFC6311] - 433 Protocol Support for High Availability of IKEv2. As it deliberately 434 allows any number of synchronization Exchanges to have the same 435 Message ID - zero, standard replay detection logic, based on checking 436 Message ID is not applicable for such messages, and receiver has to 437 check message content to detect replays. When implementing IKE 438 Fragmentation along with [RFC6311], IKE Message ID Synchronization 439 messages MUST NOT be sent fragmented to simplify receiver's task of 440 detecting replays. Fortunately, these messages are small and there 441 is no point in fragmenting them anyway. 443 4. Security Considerations 445 Most of the security considerations for IKE Fragmentation are the 446 same as those for base IKEv2 protocol described in [RFC5996]. This 447 extension introduces Encrypted Fragment Payload to protect content of 448 IKE Message Fragment. This allows receiver to individually check 449 authenticity of fragments, thus protecting itself from Denial of 450 Service attack. 452 5. IANA Considerations 454 This document defines new Payload in the "IKEv2 Payload Types" 455 registry: 457 Encrypted Fragment Payload SKF 459 This document also defines new Notify Message Types in the "Notify 460 Messages Types - Status Types" registry: 462 IKE_FRAGMENTATION_SUPPORTED 464 6. Acknowledgements 466 We would like to thank Tero Kivinen, Yoav Nir, Paul Wouters for their 467 review comments. 469 7. References 471 7.1. Normative References 473 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 474 Requirement Levels", BCP 14, RFC 2119, March 1997. 476 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 477 "Internet Key Exchange Protocol Version 2 (IKEv2)", 478 RFC 5996, September 2010. 480 [RFC6311] Singh, R., Kalyani, G., Nir, Y., Sheffer, Y., and D. 481 Zhang, "Protocol Support for High Availability of IKEv2/ 482 IPsec", RFC 6311, July 2011. 484 7.2. Informative References 486 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 487 September 1981. 489 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 490 (IPv6) Specification", RFC 2460, December 1998. 492 [RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange 493 Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, 494 January 2010. 496 [RFC6290] Nir, Y., Wierbowski, D., Detienne, F., and P. Sethi, "A 497 Quick Crash Detection Method for the Internet Key Exchange 498 Protocol (IKE)", RFC 6290, June 2011. 500 Author's Address 502 Valery Smyslov 503 ELVIS-PLUS 504 PO Box 81 505 Moscow (Zelenograd) 124460 506 RU 508 Phone: +7 495 276 0211 509 Email: svan@elvis.ru