idnits 2.17.1 draft-smyslov-ipsecme-ikev2-fragmentation-01.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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Note, that the size of each IP Datagram bearing IKE Fragment Messages SHOULD not exceed fragmentation threshold, including the very first, which contains unprotected Payloads. This will reduce the size of Encrypted Fragment Payload content in the first IKE Fragment Message to accommodate unprotected Payloads. In extreme cases Encrypted Fragment Payload will contain no data, but it is still MUST be present in the message, because only its presence allows receiver to distinguish IKE Fragment Message from regular IKE message. -- The document date (April 10, 2013) is 4035 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'CERTREQ' is mentioned on line 137, 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 (~~), 3 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: Informational April 10, 2013 5 Expires: October 12, 2013 7 IKEv2 Fragmentation 8 draft-smyslov-ipsecme-ikev2-fragmentation-01 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 12, 2013. 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. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 67 6.1. Normative References . . . . . . . . . . . . . . . . . . . 14 68 6.2. Informative References . . . . . . . . . . . . . . . . . . 14 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 71 1. Introduction 73 The Internet Key Exchange Protocol version 2 (IKEv2), specified in 74 [RFC5996], uses UDP as a transport for its messages. When IKE 75 message size exceed path MTU, it gets fragmented by IP level. The 76 problem is that some network devices, specifically some NAT boxes, 77 don't allow IP fragments to pass through. This apparently blocks IKE 78 communication and, therefore, prevents peers from establishing IPsec 79 SA. 81 The solution to the problem described in this document is to perform 82 fragmentation of large messages by IKE itself, replacing them by 83 series of smaller messages. In this case the resulting IP Datagrams 84 will be small enough so that no fragmentation on IP level will take 85 place. 87 1.1. Conventions Used in This Document 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in [RFC2119]. 93 2. Protocol details 95 2.1. Overview 97 The idea of the protocol is to split large IKE message into the set 98 of smaller ones, calling Fragment Messages. On the receiving side 99 Fragment Messages are collected and merged together to get original 100 message. In general this approach increases receiver's vulnerability 101 to Denial of Service attack. To reduce this vulnerability Fragment 102 Messages are individually encrypted and authenticated. This implies 103 that message cannot be fragmented until shared secret is calculated. 105 2.2. Limitations 107 In general, original message can be fragmented if and only if it 108 contains Encrypted Payload. It means that messages in IKE_SA_INIT 109 Exchange cannot be fragmented. In most cases this is not a problem, 110 since IKE_SA_INIT messages are usually small enough to avoid IP 111 fragmentation. But in some cases (advertising a badly structured 112 long list of algorithms, using large MODP Groups, etc.) those 113 messages may become fairly large and get fragmented by IP level. In 114 these cases the described solution won't help. 116 Another limitation is that the minimal size of IP Datagram bearing 117 IKE Fragment Message is about 100 bytes depending on the algorithms 118 employed. According to [RFC0791] the minimum IP Datagram size that 119 is guaranteed not to be further fragmented is 68 bytes. So, even the 120 smallest IKE Fragment Messages could be fragmented by IP level in 121 some circumstances. But such extremely small PMTU sizes are very 122 rare in real life. 124 2.3. Negotiation 126 Initiator MAY indicate its support for IKE Fragmentation and 127 willingness to use it by including Notification Payload of type 128 IKE_FRAGMENTATION_SUPPORTED in IKE_SA_INIT request message. If 129 Responder also supports this extension and is willing to use it, it 130 includes this notification in response message. 132 Initiator Responder 133 ----------- ----------- 134 HDR, SAi1, KEi, Ni, 135 [N(IKE_FRAGMENTATION_SUPPORTED)] --> 137 <-- HDR, SAr1, KEr, Nr, [CERTREQ], 138 [N(IKE_FRAGMENTATION_SUPPORTED)] 140 The Notify payload is formatted as follows: 142 1 2 3 143 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 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | Next Payload |C| RESERVED | Payload Length | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 |Protocol ID(=0)| SPI Size (=0) | Notify Message Type | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 o Protocol ID (1 octet) MUST be 0. 152 o SPI Size (1 octet) MUST be 0, meaning no SPI is present. 154 o Notify Message Type (2 octets) - MUST be xxxxx, the value assigned 155 for IKE_FRAGMENTATION_SUPPORTED by IANA. 157 This Notification contains no data. 159 2.4. Using IKE Fragmentation 161 After IKE Fragmentation is negotiated, it is up to Initiator of each 162 Exchange, whether to use it or not. In most cases IKE Fragmentation 163 will be used in IKE_AUTH Exchange, especially if certificates are 164 employed. Initiator may first try to send unfragmented message and 165 resend it fragmented only if it didn't receive response after several 166 retransmissions, or it may always send messages fragmented (but see 167 Section 3), or it may fragment only large messages and messages 168 causing large responses. 170 In general the following guidelines are applicable: 172 o Initiator MAY fragment outgoing message if it suspects that either 173 request or response message may be fragmented by IP level. 175 o Initiator SHOULD fragment outgoing message if it suspects that 176 either request or response message may be fragmented by IP level 177 and IKE Fragmentation was already used in one of previous 178 Exchanges in the context of the current IKE SA. 180 o Initiator SHOULD NOT fragment outgoing message if both request and 181 response messages of the Exchange are small enough not to cause 182 fragmentation on IP level (for example, there is no point in 183 fragmenting Liveness Check messages). 185 Responder MUST send response message in the same form (fragmented or 186 not) as corresponded request message. If it received unfragmented 187 request message, responded with unfragmented response message and 188 then received fragmented retransmission of the same request, it MUST 189 resend its response back to Initiator fragmented. 191 2.5. Fragmenting Message 193 Message to be fragmented MUST contain Encrypted Payload. For the 194 purpose of IKE Fragment Messages construction original (unencrypted) 195 content of Encrypted Payload is broken down into parts. Its content 196 is treated as a binary blob and is broken down regardless of inner 197 Payloads boundaries. Each of resulting parts is treated as a content 198 for Encrypted Fragment Payload. 200 The Encrypted Fragment Payload, denoted SKF{...}, contains other 201 payloads in encrypted form. The Encrypted Fragment Payload, as well 202 as Encrypted Payload from [RFC5996], if present in a message, MUST be 203 the last payload in the message. 205 The payload type for an Encrypted Fragment payload is XXX (TBA by 206 IANA). 208 1 2 3 209 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 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | Next Payload |C| RESERVED | Payload Length | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Fragment Number | Total Fragments | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Initialization Vector | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 ~ Encrypted content ~ 218 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | | Padding (0-255 octets) | 220 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 221 | | Pad Length | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 ~ Integrity Checksum Data ~ 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 Encrypted Fragment Payload 228 o Next Fragment (1 octet) - in the very first fragment MUST be set 229 to Payload Type of the first inner Payload (as in Encrypted 230 Payload). In the rest fragments MUST be set to zero. 232 o Fragment Number (2 octets) - current fragment number starting from 233 1. This field MUST be less than or equal to the next field, Total 234 Fragments. 236 o Total Fragments (2 octets) - number of fragments original message 237 was divided into. This field MUST NOT be zero. 239 Other fields are identical to those specified in Section 3.14 of 240 [RFC5996]. 242 When prepending IKE Header, Length field MUST be adjusted to reflect 243 the length of constructed message and Next Payload field MUST reflect 244 payload type of the first Payload in the constructed message (that in 245 most cases will be Encrypted Fragment Payload). All newly 246 constructed messages MUST retain the same Message ID as original 247 message. After prepending IKE Header and possibly any of Payloads 248 that precedes Encrypted Payload in original message (see 249 Section 2.5.2), the resulting messages are sent to the peer. 251 Below is an example of fragmenting some message. 253 HDR(MID=n), SK(NextPld=PLD1) {PLD1 ... PLDN} 255 Original Message 257 HDR(MID=n), SKF(NextPld=PLD1, Frag#=1, TotalFrags=m) {...}, 258 HDR(MID=n), SKF(NextPld=0, Frag#=2, TotalFrags=m) {...}, 259 ... 260 HDR(MID=n), SKF(NextPld=0, Frag#=m, TotalFrags=m) {...} 262 IKE Fragment Messages 264 2.5.1. Selecting Fragment Size 266 When breaking content of Encrypted Payload down into parts sender 267 SHOULD chose size of those parts so, that resulting IP Datagram size 268 not exceed some fragmentation threshold - be small enough to avoid IP 269 fragmentation. 271 If sender has some knowledge about PMTU size it MAY use it. If 272 sender is a Responder in the Exchange and it has received fragmented 273 request, it MAY use maximum size of received IKE Fragment Message IP 274 Datagrams as threshold when constructing fragmented response. 276 Otherwise for messages to be sent over IPv6 it is RECOMMENDED to use 277 value 1280 bytes as a maximum IP Datagram size ([RFC2460]). For 278 messages to be sent over IPv4 it is RECOMMENDED to use value 576 279 bytes as a maximum IP Datagram size. 281 For IPv4 Encrypted Payload content size is less than IP Datagram size 282 by the sum of the following values: 284 o IPv4 header size (typically 20 bytes, up to 60 if IP options are 285 present) 287 o UDP header size (8 bytes) 289 o non-ESP marker size (4 bytes if present) 291 o IKE Header size (28 bytes) 293 o Encrypted Payload header size (4 bytes) 295 o IV size (varying) 297 o padding and its size (at least 1 byte) 299 o ICV size (varying) 301 The sum may be estimated as 61..105 bytes + IV + ICV + padding. For 302 IPv6 this estimation is difficult as there may be varying IPv6 303 Extension headers included. 305 According to [RFC0791] the minimum IPv4 datagram size that is 306 guaranteed not to be further fragmented is 68 bytes, but it is 307 generally impossible to use such small value for solution, described 308 in this document. Using 576 bytes is a compromise - the value is 309 large enough for the presented solution and small enough to avoid IP 310 fragmentation in most situations. Sender MAY use other values if 311 they are appropriate. 313 Initiator MAY try to discover path MTU by using several values of 314 fragmentation threshold, provided that it starts with larger values 315 and fragments message again with next smaller value if it doesn't 316 receive response in a reasonable time after several retransmissions. 317 In this case using next smaller value MUST result in increasing Total 318 Fragments field. 320 2.5.2. Fragmenting Messages containing unencrypted Payloads 322 Currently no one of IKEv2 Exchanges defines messages, containing both 323 unencrypted payloads and payloads, protected by Encrypted Payload. 324 But IKEv2 doesn't forbid such messages. If some future IKEv2 325 extension defines such a message and it needs to be fragmented, all 326 unprotected payloads MUST be in the first fragment, along with 327 Encrypted Fragment Payload, which MUST be present in any IKE Fragment 328 Message. 330 Below is an example of fragmenting message, containing both encrypted 331 and unencrypted Payloads. 333 HDR(MID=n), PLD0, SK(NextPld=PLD1) {PLD1 ... PLDN} 334 Original Message 336 HDR(MID=n), PLD0, SKF(NextPld=PLD1, Frag#=1, TotalFrags=m) {...}, 337 HDR(MID=n), SKF(NextPld=0, Frag#=2, TotalFrags=m) {...}, 338 ... 339 HDR(MID=n), SKF(NextPld=0, Frag#=m, TotalFrags=m) {...} 341 IKE Fragment Messages 343 Note, that the size of each IP Datagram bearing IKE Fragment Messages 344 SHOULD not exceed fragmentation threshold, including the very first, 345 which contains unprotected Payloads. This will reduce the size of 346 Encrypted Fragment Payload content in the first IKE Fragment Message 347 to accommodate unprotected Payloads. In extreme cases Encrypted 348 Fragment Payload will contain no data, but it is still MUST be 349 present in the message, because only its presence allows receiver to 350 distinguish IKE Fragment Message from regular IKE message. 352 2.6. Receiving IKE Fragment Message 354 Receiver identifies IKE Fragment Message by the presence of Encrypted 355 Fragment Payload in it. Note, that it is possible for this payload 356 to be not the first (and the only) payload in the message (see 357 Section 2.5.2). But for all currently defined IKEv2 exchanges this 358 payload will be the first and the only payload in the message. 360 Upon receiving IKE Fragment Message the following actions are 361 performed: 363 o Check message validity - in particular, check whether values of 364 Fragment Number and Total Fragments in Encrypted Fragment Payload 365 are valid. If not - message MUST be silently discarded. 367 o Check, that this IKE Fragment Message is new for the receiver and 368 not a replay. If IKE Fragment message with the same Message ID, 369 same Fragment Number and same Total Fragments fields was already 370 received and successfully processed, this message is considered a 371 replay and MUST be discarded. 373 o Verify IKE Fragment Message authenticity by checking ICV in 374 Encrypted Fragment Payload. If ICV check fails message MUST be 375 silently discarded. 377 o If reassembling isn't finished yet and Total Fragments field in 378 received IKE Fragment Message is greater than this field in 379 previously received fragments, receiver MUST discard all received 380 fragments and start reassembling over with just received IKE 381 Fragment Message. 383 o Store message in the list waiting for the rest of fragments to 384 arrive. 386 When all IKE Fragment Messages (as indicated in the Total Fragments 387 field) are received, content of their Encrypted Fragment Payloads is 388 decrypted and merged together to form content of original Encrypted 389 Payload, and, therefore, along with IKE Header, original message. 390 Then it is processed as if it was received, verified and decrypted as 391 as regular unfragmented message. 393 2.6.1. Changes in Replay Protection Logic 395 According to [RFC5996] IKEv2 MUST reject message with the same 396 Message ID as it has seen before (taking into consideration Response 397 bit). This logic has already been updated by [RFC6311], which 398 deliberately allows any number of messages with zero Message ID. 399 This document also updates this logic: if message contains Encrypted 400 Fragment Payload, the values of Fragment Number and Total Fragments 401 fields from this payload MUST be used along with Message ID to detect 402 retransmissions and replays. 404 If Responder receives IKE Fragment Message after it received, 405 successfully verified and processed regular message with the same 406 Message ID, it means that response message didn't reach Initiator and 407 it activated IKE Fragmentation. If Fragment Number in Encrypted 408 Fragment Payload in this message is equal to 1, Responder MUST 409 fragment its response and retransmit it back to Initiator in 410 fragmented form. 412 If Responder receives a replay IKE Fragment Message for already 413 reassembled, verified and processed fragmented message, it MUST 414 retransmit response back to Initiator, but only if Fragment Number 415 field in Encrypted Fragment Payload is equal to 1 and MUST silently 416 discard received message otherwise. 418 3. Interaction with other IKE extensions 420 IKE Fragmentation is compatible with most of defined IKE extensions, 421 like IKE Session Resumption [RFC5723], Quick Crash Detection Method 422 [RFC6290] and so on. It neither affect their operation, nor is 423 affected by them. It is believed that IKE Fragmentation will also be 424 compatible with most future IKE extensions, if they follow general 425 principles of formatting, sending and receiving IKE messages, 426 described in [RFC5996]. 428 The notable exception that requires a special care is [RFC6311] - 429 Protocol Support for High Availability of IKEv2. As it deliberately 430 allows any number of synchronization Exchanges to have the same 431 Message ID - zero, standard replay detection logic, based on checking 432 Message ID is not applicable for such messages, and receiver has to 433 check message content to detect replays. When implementing IKE 434 Fragmentation along with [RFC6311], IKE Message ID Synchronization 435 messages MUST NOT be sent fragmented to simplify receiver's task of 436 detecting replays. Fortunately, these messages are small and there 437 is no point in fragmenting them anyway. 439 4. Security Considerations 441 Most of the security considerations for IKE Fragmentation are the 442 same as those for base IKEv2 protocol described in [RFC5996]. This 443 extension introduces Encrypted Fragment Payload to protect content of 444 IKE Message Fragment. This allows receiver to individually check 445 authenticity of fragments, thus protecting itself from Denial of 446 Service attack. 448 5. IANA Considerations 450 This document defines new Payload in the "IKEv2 Payload Types" 451 registry: 453 Encrypted Fragment Payload SKF 455 This document also defines new Notify Message Types in the "Notify 456 Messages Types - Status Types" registry: 458 IKE_FRAGMENTATION_SUPPORTED 460 6. References 462 6.1. Normative References 464 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 465 Requirement Levels", BCP 14, RFC 2119, March 1997. 467 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 468 "Internet Key Exchange Protocol Version 2 (IKEv2)", 469 RFC 5996, September 2010. 471 [RFC6311] Singh, R., Kalyani, G., Nir, Y., Sheffer, Y., and D. 472 Zhang, "Protocol Support for High Availability of IKEv2/ 473 IPsec", RFC 6311, July 2011. 475 6.2. Informative References 477 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 478 September 1981. 480 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 481 (IPv6) Specification", RFC 2460, December 1998. 483 [RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange 484 Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, 485 January 2010. 487 [RFC6290] Nir, Y., Wierbowski, D., Detienne, F., and P. Sethi, "A 488 Quick Crash Detection Method for the Internet Key Exchange 489 Protocol (IKE)", RFC 6290, June 2011. 491 Author's Address 493 Valery Smyslov 494 ELVIS-PLUS 495 PO Box 81 496 Moscow (Zelenograd) 124460 497 RU 499 Phone: +7 495 276 0211 500 Email: svan@elvis.ru