idnits 2.17.1 draft-ietf-ipsecme-ddos-protection-06.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 seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (April 15, 2016) is 2927 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'IKEV2-IANA' Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPSecME Working Group Y. Nir 3 Internet-Draft Check Point 4 Intended status: Standards Track V. Smyslov 5 Expires: October 17, 2016 ELVIS-PLUS 6 April 15, 2016 8 Protecting Internet Key Exchange Protocol version 2 (IKEv2) 9 Implementations from Distributed Denial of Service Attacks 10 draft-ietf-ipsecme-ddos-protection-06 12 Abstract 14 This document recommends implementation and configuration best 15 practices for Internet Key Exchange Protocol version 2 (IKEv2) 16 Responders, to allow them to resist Denial of Service and Distributed 17 Denial of Service attacks. Additionally, the document introduces a 18 new mechanism called "Client Puzzles" that help accomplish this task. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on October 17, 2016. 37 Copyright Notice 39 Copyright (c) 2016 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 56 3. The Vulnerability . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Defense Measures while IKE SA is being created . . . . . . . 6 58 4.1. Retention Periods for Half-Open SAs . . . . . . . . . . . 6 59 4.2. Rate Limiting . . . . . . . . . . . . . . . . . . . . . . 6 60 4.3. The Stateless Cookie . . . . . . . . . . . . . . . . . . 7 61 4.4. Puzzles . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 4.5. Session Resumption . . . . . . . . . . . . . . . . . . . 10 63 4.6. Keeping computed Shared Keys . . . . . . . . . . . . . . 10 64 4.7. Preventing Attacks using "Hash and URL" Certificate 65 Encoding . . . . . . . . . . . . . . . . . . . . . . . . 11 66 4.8. IKE Fragmentation . . . . . . . . . . . . . . . . . . . . 11 67 5. Defense Measures after IKE SA is created . . . . . . . . . . 11 68 6. Plan for Defending a Responder . . . . . . . . . . . . . . . 13 69 7. Using Puzzles in the Protocol . . . . . . . . . . . . . . . . 15 70 7.1. Puzzles in IKE_SA_INIT Exchange . . . . . . . . . . . . . 15 71 7.1.1. Presenting Puzzle . . . . . . . . . . . . . . . . . . 16 72 7.1.2. Solving Puzzle and Returning the Solution . . . . . . 18 73 7.1.3. Computing Puzzle . . . . . . . . . . . . . . . . . . 19 74 7.1.4. Analyzing Repeated Request . . . . . . . . . . . . . 19 75 7.1.5. Making Decision whether to Serve the Request . . . . 20 76 7.2. Puzzles in IKE_AUTH Exchange . . . . . . . . . . . . . . 21 77 7.2.1. Presenting Puzzle . . . . . . . . . . . . . . . . . . 22 78 7.2.2. Solving Puzzle and Returning the Solution . . . . . . 23 79 7.2.3. Computing Puzzle . . . . . . . . . . . . . . . . . . 23 80 7.2.4. Receiving Puzzle Solution . . . . . . . . . . . . . . 24 81 8. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 24 82 8.1. PUZZLE Notification . . . . . . . . . . . . . . . . . . . 24 83 8.2. Puzzle Solution Payload . . . . . . . . . . . . . . . . . 25 84 9. Operational Considerations . . . . . . . . . . . . . . . . . 26 85 10. Security Considerations . . . . . . . . . . . . . . . . . . . 26 86 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 87 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 88 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 89 13.1. Normative References . . . . . . . . . . . . . . . . . . 28 90 13.2. Informative References . . . . . . . . . . . . . . . . . 28 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 93 1. Introduction 95 Denial of Service (DoS) attacks have always been considered a serious 96 threat. These attacks are usually difficult to defend against since 97 the amount of resources the victim has is always bounded (regardless 98 of how high it is) and because some resources are required for 99 distinguishing a legitimate session from an attack. 101 The Internet Key Exchange protocol version 2 (IKEv2) described in 102 [RFC7296] includes defense against DoS attacks. In particular, there 103 is a cookie mechanism that allows the IKE Responder to effectively 104 defend itself against DoS attacks from spoofed IP-addresses. 105 However, bot-nets have become widespread, allowing attackers to 106 perform Distributed Denial of Service (DDoS) attacks, which are more 107 difficult to defend against. This document presents recommendations 108 to help the Responder thwart (D)DoS attacks. It also introduces a 109 new mechanism -- "puzzles" -- that can help accomplish this task. 111 2. Conventions Used in This Document 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in [RFC2119]. 117 3. The Vulnerability 119 The IKE_SA_INIT Exchange described in Section 1.2 of [RFC7296] 120 involves the Initiator sending a single message. The Responder 121 replies with a single message and also allocates memory for a 122 structure called a half-open IKE Security Association (SA). This 123 half-open SA is later authenticated in the IKE_AUTH Exchange. If 124 that IKE_AUTH request never comes, the half-open SA is kept for an 125 unspecified amount of time. Depending on the algorithms used and 126 implementation, such a half-open SA will use from around 100 bytes to 127 several thousands bytes of memory. 129 This creates an easy attack vector against an IKE Responder. 130 Generating the IKE_SA_INIT request is cheap, and sending multiple 131 such requests can either cause the Responder to allocate too much 132 resources and fail, or else if resource allocation is somehow 133 throttled, legitimate Initiators would also be prevented from setting 134 up IKE SAs. 136 An obvious defense, which is described in Section 4.2, is limiting 137 the number of half-open SAs opened by a single peer. However, since 138 all that is required is a single packet, an attacker can use multiple 139 spoofed source IP addresses. 141 If we break down what a Responder has to do during an initial 142 exchange, there are three stages: 144 1. When the IKE_SA_INIT request arrives, the Responder: 146 * Generates or re-uses a Diffie-Hellman (D-H) private part. 148 * Generates a Responder Security Parameter Index (SPI). 150 * Stores the private part and peer public part in a half-open SA 151 database. 153 2. When the IKE_AUTH request arrives, the Responder: 155 * Derives the keys from the half-open SA. 157 * Decrypts the request. 159 3. If the IKE_AUTH request decrypts properly: 161 * Validates the certificate chain (if present) in the IKE_AUTH 162 request. 164 Yes, there's a stage 4 where the Responder actually creates Child 165 SAs, but when talking about (D)DoS, we never get to this stage. 167 Stage #1 is pretty light on CPU power, but requires some storage, and 168 it's very light for the Initiator as well. Stage #2 includes 169 private-key operations, so it's much heavier CPU-wise. Stage #3 170 includes public key operations, typically more than one. 172 To attack such a Responder, an attacker can attempt to either exhaust 173 memory or to exhaust CPU. Without any protection, the most efficient 174 attack is to send multiple IKE_SA_INIT requests and exhaust memory. 175 This should be easy because those requests are cheap. 177 There are obvious ways for the Responder to protect itself even 178 without changes to the protocol. It can reduce the time that an 179 entry remains in the half-open SA database, and it can limit the 180 amount of concurrent half-open SAs from a particular address or 181 prefix. The attacker can overcome this by using spoofed source 182 addresses. 184 The stateless cookie mechanism from Section 2.6 of [RFC7296] prevents 185 an attack with spoofed source addresses. This doesn't completely 186 solve the issue, but it makes the limiting of half-open SAs by 187 address or prefix work. Puzzles, introduced in Section 4.4, do the 188 same thing only more of it. They make it harder for an attacker to 189 reach the goal of getting a half-open SA. They don't have to be so 190 hard that an attacker can't afford to solve a single puzzle; it's 191 enough that they increase the cost of a half-open SAs for the 192 attacker so that it can create only a few. 194 Reducing the amount of time an abandoned half-open SA is kept attacks 195 the issue from the other side. It reduces the value the attacker 196 gets from managing to create a half-open SA. For example, if a half- 197 open SA is kept for 1 minute and the capacity is 60,000 half-open 198 SAs, an attacker would need to create 1,000 half-open SAs per second. 199 Reduce the retention time to 3 seconds, and the attacker needs to 200 create 20,000 half-open SAs per second. By introducing a puzzle, 201 each half-open SA becomes more expensive for an attacker, making it 202 more likely to thwart an exhaustion attack against Responder memory. 204 At this point, filling up the half-open SA database is no longer the 205 most efficient DoS attack. The attacker has two ways to do better: 207 1. Go back to spoofed addresses and try to overwhelm the CPU that 208 deals with generating cookies, or 210 2. Take the attack to the next level by also sending an IKE_AUTH 211 request. 213 It seems that the first thing cannot be dealt with at the IKE level. 214 It's probably better left to Intrusion Prevention System (IPS) 215 technology. 217 On the other hand, sending an IKE_AUTH request is surprisingly cheap. 218 It requires a proper IKE header with the correct IKE SPIs, and it 219 requires a single Encrypted payload. The content of the payload 220 might as well be junk. The Responder has to perform the relatively 221 expensive key derivation, only to find that the MAC on the Encrypted 222 payload on the IKE_AUTH request does not check. Depending on the 223 Responder implementation, this can be repeated with the same half- 224 open SA. Puzzles can make attacks of such sort more costly for an 225 attacker. See Section 7.2 for details. 227 Here too, the number of half-open SAs that the attacker can achieve 228 is crucial, because each one allows the attacker to waste some CPU 229 time. So making it hard to make many half-open SAs is important. 231 A strategy against DDoS has to rely on at least 4 components: 233 1. Hardening the half-open SA database by reducing retention time. 235 2. Hardening the half-open SA database by rate-limiting single IPs/ 236 prefixes. 238 3. Guidance on what to do when an IKE_AUTH request fails to decrypt. 240 4. Increasing cost of half-open SA up to what is tolerable for 241 legitimate clients. 243 Puzzles have their place as part of #4. 245 4. Defense Measures while IKE SA is being created 247 4.1. Retention Periods for Half-Open SAs 249 As a UDP-based protocol, IKEv2 has to deal with packet loss through 250 retransmissions. Section 2.4 of [RFC7296] recommends "that messages 251 be retransmitted at least a dozen times over a period of at least 252 several minutes before giving up". Retransmission policies in 253 practice wait at least one or two seconds before retransmitting for 254 the first time. 256 Because of this, setting the timeout on a half-open SA too low will 257 cause it to expire whenever even one IKE_AUTH request packet is lost. 258 When not under attack, the half-open SA timeout SHOULD be set high 259 enough that the Initiator will have enough time to send multiple 260 retransmissions, minimizing the chance of transient network 261 congestion causing IKE failure. 263 When the system is under attack, as measured by the amount of half- 264 open SAs, it makes sense to reduce this lifetime. The Responder 265 should still allow enough time for the round-trip, enough time for 266 the Initiator to derive the D-H shared value, and enough time to 267 derive the IKE SA keys and the create the IKE_AUTH request. Two 268 seconds is probably as low a value as can realistically be used. 270 It could make sense to assign a shorter value to half-open SAs 271 originating from IP addresses or prefixes that are considered suspect 272 because of multiple concurrent half-open SAs. 274 4.2. Rate Limiting 276 Even with DDoS, the attacker has only a limited amount of nodes 277 participating in the attack. By limiting the amount of half-open SAs 278 that are allowed to exist concurrently with each such node, the total 279 amount of half-open SAs is capped, as is the total amount of key 280 derivations that the Responder is forced to complete. 282 In IPv4 it makes sense to limit the number of half-open SAs based on 283 IP address. Most IPv4 nodes are either directly attached to the 284 Internet using a routable address or are hidden behind a NAT device 285 with a single IPv4 external address. For IPv6, ISPs assign between a 286 /48 and a /64, so it makes sense to use a 64-bit prefix as the basis 287 for rate limiting in IPv6. 289 The number of half-open SAs is easy to measure, but it is also 290 worthwhile to measure the number of failed IKE_AUTH exchanges. If 291 possible, both factors should be taken into account when deciding 292 which IP address or prefix is considered suspicious. 294 There are two ways to rate-limit a peer address or prefix: 296 1. Hard Limit - where the number of half-open SAs is capped, and any 297 further IKE_SA_INIT requests are rejected. 299 2. Soft Limit - where if a set number of half-open SAs exist for a 300 particular address or prefix, any IKE_SA_INIT request will 301 require solving a puzzle. 303 The advantage of the hard limit method is that it provides a hard cap 304 on the amount of half-open SAs that the attacker is able to create. 305 The downside is that it allows the attacker to block IKE initiation 306 from small parts of the Internet. For example, if an network service 307 provider or some establishment offers Internet connectivity to its 308 customers or employees through an IPv4 NAT device, a single malicious 309 customer can create enough half-open SAs to fill the quota for the 310 NAT device external IP address. Legitimate Initiators on the same 311 network will not be able to initiate IKE. 313 The advantage of a soft limit is that legitimate clients can always 314 connect. The disadvantage is that an adversary with sufficient CPU 315 resources can still effectively DoS the Responder. 317 Regardless of the type of rate-limiting used, there is a huge 318 advantage in blocking the DoS attack using rate-limiting for 319 legitimate clients that are away from the attacking nodes. In such 320 cases, adverse impacts caused by the attack or by the measures used 321 to counteract the attack can be avoided. 323 4.3. The Stateless Cookie 325 Section 2.6 of [RFC7296] offers a mechanism to mitigate DoS attack: 326 the stateless cookie. When the server is under load, the Responder 327 responds to the IKE_SA_INIT request with a calculated "stateless 328 cookie" - a value that can be re-calculated based on values in the 329 IKE_SA_INIT request without storing Responder-side state. The 330 Initiator is expected to repeat the IKE_SA_INIT request, this time 331 including the stateless cookie. This mechanism prevents DoS attacks 332 from spoofed IP addresses, since an attacker needs to have a routable 333 IP address to return the cookie. 335 Attackers that have multiple source IP addresses with return 336 routability, such as in the case of bot-nets, can fill up a half-open 337 SA table anyway. The cookie mechanism limits the amount of allocated 338 state to the number of attackers, multiplied by the number of half- 339 open SAs allowed per peer address, multiplied by the amount of state 340 allocated for each half-open SA. With typical values this can easily 341 reach hundreds of megabytes. 343 4.4. Puzzles 345 The puzzle introduced here extends the cookie mechanism from 346 [RFC7296]. It is loosely based on the proof-of-work technique used 347 in Bitcoins [bitcoins]. This sets an upper bound, determined by the 348 attacker's CPU, to the number of negotiations it can initiate in a 349 unit of time. 351 A puzzle is sent to the Initiator in two cases: 353 o The Responder is so overloaded that no half-open SAs may be 354 created without solving a puzzle, or 356 o The Responder is not too loaded, but the rate-limiting method 357 described in Section 4.2 prevents half-open SAs from being created 358 with this particular peer address or prefix without first solving 359 a puzzle. 361 When the Responder decides to send the challenge notification in 362 response to a IKE_SA_INIT request, the notification includes three 363 fields: 365 1. Cookie - this is calculated the same as in [RFC7296], i.e. the 366 process of generating the cookie is not specified. 368 2. Algorithm, this is the identifier of a Pseudo-Random Function 369 (PRF) algorithm, one of those proposed by the Initiator in the SA 370 payload. 372 3. Zero Bit Count (ZBC). This is a number between 8 and 255 (or a 373 special value - 0, see Section 7.1.1.1) that represents the 374 length of the zero-bit run at the end of the output of the PRF 375 function calculated over the cookie that the Initiator is to 376 send. The values 1-8 are explicitly excluded, because they 377 create a puzzle that is too easy to solve for it to make any 378 difference in mitigating DDoS attacks. Since the mechanism is 379 supposed to be stateless for the Responder, either the same ZBC 380 is used for all Initiators, or the ZBC is somehow encoded in the 381 cookie. If it is global then it means that this value is the 382 same for all the Initiators who are receiving puzzles at any 383 given point of time. The Responder, however, may change this 384 value over time depending on its load. 386 Upon receiving this challenge, the Initiator attempts to calculate 387 the PRF using different keys. When enough keys are found such that 388 the resulting PRF output calculated using each of them has a 389 sufficient number of trailing zero bits, that result is sent to the 390 Responder. 392 The reason for using several keys in the results rather than just one 393 key is to reduce the variance in the time it takes the initiator to 394 solve the puzzle. We have chosen the number of keys to be four (4) 395 as a compromise between the conflicting goals of reducing variance 396 and reducing the work the Responder needs to perform to verify the 397 puzzle solution. 399 When receiving a request with a solved puzzle, the Responder verifies 400 two things: 402 o That the cookie part is indeed valid. 404 o That the PRFs of the transmitted cookie calculated with the 405 transmitted keys has a sufficient number of trailing zero bits. 407 Example 1: Suppose the calculated cookie is 408 739ae7492d8a810cf5e8dc0f9626c9dda773c5a3 (20 octets), the algorithm 409 is PRF-HMAC-SHA256, and the required number of zero bits is 18. 410 After successively trying a bunch of keys, the Initiator finds the 411 following four 3-octet keys that work: 413 +--------+----------------------------------+----------+ 414 | Key | Last 32 Hex PRF Digits | # 0-bits | 415 +--------+----------------------------------+----------+ 416 | 061840 | e4f957b859d7fb1343b7b94a816c0000 | 18 | 417 | 073324 | 0d4233d6278c96e3369227a075800000 | 23 | 418 | 0c8a2a | 952a35d39d5ba06709da43af40700000 | 20 | 419 | 0d94c8 | 5a0452b21571e401a3d00803679c0000 | 18 | 420 +--------+----------------------------------+----------+ 422 Table 1: Three solutions for 18-bit puzzle 424 Example 2: Same cookie, but modify the required number of zero bits 425 to 22. The first 4-octet keys that work to satisfy that requirement 426 are 005d9e57, 010d8959, 0110778d, and 01187e37. Finding these 427 requires 18,382,392 invocations of the PRF. 429 +----------+-------------------------------+ 430 | # 0-bits | Time to Find 4 keys (seconds) | 431 +----------+-------------------------------+ 432 | 8 | 0.0025 | 433 | 10 | 0.0078 | 434 | 12 | 0.0530 | 435 | 14 | 0.2521 | 436 | 16 | 0.8504 | 437 | 17 | 1.5938 | 438 | 18 | 3.3842 | 439 | 19 | 3.8592 | 440 | 20 | 10.8876 | 441 +----------+-------------------------------+ 443 Table 2: The time needed to solve a puzzle of various difficulty for 444 the cookie = 739ae7492d8a810cf5e8dc0f9626c9dda773c5a3 446 The figures above were obtained on a 2.4 GHz single core i5. Run 447 times can be halved or quartered with multi-core code, but would be 448 longer on mobile phone processors, even if those are multi-core as 449 well. With these figures 18 bits is believed to be a reasonable 450 choice for puzzle level difficulty for all Initiators, and 20 bits is 451 acceptable for specific hosts/prefixes. 453 Using puzzles mechanism in the IKE_SA_INIT exchange is described in 454 Section 7.1. 456 4.5. Session Resumption 458 When the Responder is under attack, it MAY choose to prefer 459 previously authenticated peers who present a Session Resumption 460 ticket (see [RFC5723] for details). The Responder MAY require such 461 Initiators to pass a return routability check by including the COOKIE 462 notification in the IKE_SESSION_RESUME response message, as allowed 463 by Section 4.3.2. of [RFC5723]. Note that the Responder SHOULD cache 464 tickets for a short time to reject reused tickets (Section 4.3.1), 465 and therefore there should be no issue of half-open SAs resulting 466 from replayed IKE_SESSION_RESUME messages. 468 Several kinds of DoS attacks are possible on servers supported IKE 469 Session Resumption. See Section 9.3 of [RFC5723] for details. 471 4.6. Keeping computed Shared Keys 473 Once the IKE_SA_INIT exchange is finished, the Responder is waiting 474 for the first message of the IKE_AUTH exchange from the Initiator. 475 At this point the Initiator is not yet authenticated and this fact 476 allows a malicious peer to perform an attack, described in Section 3 477 - it can just send a garbage in the IKE_AUTH message thus forcing the 478 Responder to perform CPU costly operations to compute SK_* keys. 480 If the received IKE_AUTH message failed to decrypt correctly (or 481 failed to pass ICV check), then the Responder SHOULD still keep the 482 computed SK_* keys, so that if it happened to be an attack, then the 483 malicious Initiator cannot get advantage of repeating the attack 484 multiple times on a single IKE SA. The responder can also use 485 puzzles in the IKE_AUTH exchange as decribed in Section 7.2. 487 4.7. Preventing Attacks using "Hash and URL" Certificate Encoding 489 In IKEv2 each side may use "Hash and URL" Certificate Encoding to 490 instruct the peer to retrieve certificates from the specified 491 location (see Section 3.6 of [RFC7296] for details). Malicious 492 initiators can use this feature to mount a DoS attack on responder by 493 providing an URL pointing to a large file possibly containing 494 garbage. While downloading the file the responder consumes CPU, 495 memory and network bandwidth. 497 To prevent this kind of attacks the responder should not blindly 498 download the whole file. Instead it SHOULD first read the initial 499 few bytes, decode the length of the ASN.1 structure from these bytes, 500 and then download no more than the decoded number of bytes. Note, 501 that it is always possible to determine the length of ASN.1 502 structures used in IKEv2 by analyzing the first few bytes, if they 503 are DER-encoded. However, since the content of the file being 504 downloaded can be under attacker's control, implementations should 505 not blindly trust the decoded length and SHOULD check whether it 506 makes sense before continue downloading. Implementations SHOULD also 507 apply a configurable hard limit to the number of pulled bytes and 508 SHOULD provide an ability for an administrator to either completely 509 disable this feature or to limit its use to a configurable list of 510 trusted URLs. 512 4.8. IKE Fragmentation 514 IKE Fragmentation described in [RFC7383] allows IKE peers to avoid IP 515 fragmentation of large IKE messages. Attackers can mount several 516 kinds of DoS attacks using IKE Fragmentation. See Section 5 of 517 [RFC7383] for details. 519 5. Defense Measures after IKE SA is created 521 Once IKE SA is created there is usually not much traffic over it. In 522 most cases this traffic consists of exchanges aimed to create 523 additional Child SAs, rekey, or delete them and check the liveness of 524 the peer. With a typical setup and typical Child SA lifetimes, there 525 are typically no more than a few such exchanges, often less. Some of 526 these exchanges require relatively little resources (like liveness 527 check), while others may be resource consuming (like creating or 528 rekeying Child SA with D-H exchange). 530 Since any endpoint can initiate a new exchange, there is a 531 possibility that a peer would initiate too many exchanges that could 532 exhaust host resources. For example, the peer can perform endless 533 continuous Child SA rekeying or create overwhelming number of Child 534 SAs with the same Traffic Selectors etc. Such behavior may be caused 535 by buggy implementation, misconfiguration or be intentional. The 536 latter becomes more of a real threat if the peer uses NULL 537 Authentication, described in [RFC7619]. In this case the peer 538 remains anonymous, allowing it to escape any responsibility for its 539 actions. See Section 3 of [RFC7619] for details. 541 The following recommendations for defense against possible DoS 542 attacks after IKE SA is established are mostly intended for 543 implementations that allow unauthenticated IKE sessions; however, 544 they may also be useful in other cases. 546 o If the IKEv2 window size is greater than one, then the peer could 547 initiate multiple simultaneous exchanges that could increase host 548 resource consumption. Since currently there is no way in IKEv2 to 549 decrease window size once it was increased (see Section 2.3 of 550 [RFC7296]), the window size cannot be dynamically adjusted 551 depending on the load. For that reason, it is NOT RECOMMENDED to 552 ever increase the IKEv2 window size above its default value of one 553 if the peer uses NULL Authentication. 555 o If the peer initiates requests to rekey IKE SA or Child SA too 556 often, implementations can respond to some of these requests with 557 the TEMPORARY_FAILURE notification, indicating that the request 558 should be retried after some period of time. 560 o If the peer creates too many Child SA with the same or overlapping 561 Traffic Selectors, implementations can respond with the 562 NO_ADDITIONAL_SAS notification. 564 o If the peer initiates too many exchanges of any kind, 565 implementations can introduce an artificial delay before 566 responding to each request message. This delay would decrease the 567 rate the implementation need to process requests from any 568 particular peer, making it possible to process requests from the 569 others. Note, that if the Responder receives retransmissions of 570 the request message during the delay period, the retransmitted 571 messages should be silently discarded. The delay should not be 572 too long to avoid causing the IKE SA to be deleted on the other 573 end due to timeout. It is believed that a few seconds is enough. 574 Note however, that even a few seconds may be too long in those 575 settings, that rely on immediate response to the request message, 576 e.g. for the purposes of quick detection of a dead peer. 578 o If these counter-measures are inefficient, implementations can 579 delete the IKE SA with an offending peer by sending Delete 580 Payload. 582 In IKEv2 client can request various configuration attributes from 583 server. Most often those attributes include internal IP addresses. 584 Malicious clients can try to exhaust server's IP address pool by 585 continuously requesting a large number of internal addresses. Server 586 implementations SHOULD limit the number of IP addresses allocated to 587 any particular client. Note, that it is not possible with clients 588 using NULL Authentication, since their identity cannot be verified. 590 6. Plan for Defending a Responder 592 This section outlines a plan for defending a Responder from a DDoS 593 attack based on the techniques described earlier. The numbers given 594 here are not normative, and their purpose is to illustrate the 595 configurable parameters needed for defeating the DDoS attack. 597 Implementations may be deployed in different environments, so it is 598 RECOMMENDED that the parameters be settable. As an example, most 599 commercial products are required to undergo benchmarking where the 600 IKE SA establishment rate is measured. Benchmarking is 601 indistinguishable from a DoS attack and the defenses described in 602 this document may defeat the benchmark by causing exchanges to fail 603 or take a long time to complete. Parameters should be tunable to 604 allow for benchmarking (if only by turning DDoS protection off). 606 Since all countermeasures may cause delays and work on the 607 Initiators, they SHOULD NOT be deployed unless an attack is likely to 608 be in progress. To minimize the burden imposed on Initiators, the 609 Responder should monitor incoming IKE requests, searching for two 610 things: 612 1. A general DDoS attack. Such an attack is indicated by a high 613 number of concurrent half-open SAs, a high rate of failed 614 IKE_AUTH exchanges, or a combination of both. For example, 615 consider a Responder that has 10,000 distinct peers of which at 616 peak 7,500 concurrently have VPN tunnels. At the start of peak 617 time, 600 peers might establish tunnels at any given minute, and 618 tunnel establishment (both IKE_SA_INIT and IKE_AUTH) takes 619 anywhere from 0.5 to 2 seconds. For this Responder, we expect 620 there to be less than 20 concurrent half-open SAs, so having 100 621 concurrent half-open SAs can be interpreted as an indication of 622 an attack. Similarly, IKE_AUTH request decryption failures 623 should never happen. Supposing the the tunnels are established 624 using EAP (see Section 2.16 of [RFC7296]), users enter the wrong 625 password about 20% of the time. So we'd expect 125 wrong 626 password failures a minute. If we get IKE_AUTH decryption 627 failures from multiple sources more than once per second, or EAP 628 failure more than 300 times per minute, that can also be an 629 indication of a DDoS attack. 631 2. An attack from a particular IP address or prefix. Such an attack 632 is indicated by an inordinate amount of half-open SAs from that 633 IP address or prefix, or an inordinate amount of IKE_AUTH 634 failures. A DDoS attack may be viewed as multiple such attacks. 635 If they are mitigated well enough, there will not be a need enact 636 countermeasures on all Initiators. Typical measures might be 5 637 concurrent half-open SAs, 1 decrypt failure, or 10 EAP failures 638 within a minute. 640 Note that using counter-measures against an attack from a particular 641 IP address may be enough to avoid the overload on the half-open SA 642 database and in this case the number of failed IKE_AUTH exchanges 643 never exceeds the threshold of attack detection. This is a good 644 thing as it prevents Initiators that are not close to the attackers 645 from being affected. 647 When there is no general DDoS attack, it is suggested that no cookie 648 or puzzles be used. At this point the only defensive measure is the 649 monitoring of the number of half-open SAs, and setting a soft limit 650 per peer IP or prefix. The soft limit can be set to 3-5, and the 651 puzzle difficulty should be set to such a level (number of zero-bits) 652 that all legitimate clients can handle it without degraded user 653 experience. 655 As soon as any kind of attack is detected, either a lot of 656 initiations from multiple sources or a lot of initiations from a few 657 sources, it is best to begin by requiring stateless cookies from all 658 Initiators. This will force the attacker to use real source 659 addresses, and help avoid the need to impose a greater burden in the 660 form of cookies on the general population of Initiators. This makes 661 the per-node or per-prefix soft limit more effective. 663 When cookies are activated for all requests and the attacker is still 664 managing to consume too many resources, the Responder MAY increase 665 the difficulty of puzzles imposed on IKE_SA_INIT requests coming from 666 suspicious nodes/prefixes. It should still be doable by all 667 legitimate peers, but it can degrade experience, for example by 668 taking up to 10 seconds to solve the puzzle. 670 If the load on the Responder is still too great, and there are many 671 nodes causing multiple half-open SAs or IKE_AUTH failures, the 672 Responder MAY impose hard limits on those nodes. 674 If it turns out that the attack is very widespread and the hard caps 675 are not solving the issue, a puzzle MAY be imposed on all Initiators. 676 Note that this is the last step, and the Responder should avoid this 677 if possible. 679 7. Using Puzzles in the Protocol 681 This section describes how the puzzle mechanism is used in IKEv2. It 682 is organized as follows. The Section 7.1 describes using puzzles in 683 the IKE_SA_INIT exchange and the Section 7.2 describes using puzzles 684 in the IKE_AUTH exchange. Both sections are divided into subsections 685 describing how puzzles should be presented, solved and processed by 686 the Initiator and the Responder. 688 7.1. Puzzles in IKE_SA_INIT Exchange 690 IKE Initiator indicates the desire to create a new IKE SA by sending 691 IKE_SA_INIT request message. The message may optionally contain a 692 COOKIE notification if this is a repeated request performed after the 693 Responder's demand to return a cookie. 695 HDR, [N(COOKIE),] SA, KE, Ni, [V+][N+] --> 697 According to the plan, described in Section 6, the IKE Responder 698 should monitor incoming requests to detect whether it is under 699 attack. If the Responder learns that (D)DoS attack is likely to be 700 in progress, then its actions depend on the volume of the attack. If 701 the volume is moderate, then the Responder requests the Initiator to 702 return a cookie. If the volume is so high, that puzzles need to be 703 used for defense, then the Responder requests the Initiator to solve 704 a puzzle. 706 The Responder MAY choose to process some fraction of IKE_SA_INIT 707 requests without presenting a puzzle while being under attack to 708 allow legacy clients, that don't support puzzles, to have a chance to 709 be served. The decision whether to process any particular request 710 must be probabilistic, with the probability depending on the 711 Responder's load (i.e. on the volume of attack). The requests that 712 don't contain the COOKIE notification MUST NOT participate in this 713 lottery. In other words, the Responder must first perform return 714 routability check before allowing any legacy client to be served if 715 it is under attack. See Section 7.1.4 for details. 717 7.1.1. Presenting Puzzle 719 If the Responder makes a decision to use puzzles, then it MUST 720 include two notifications in its response message - the COOKIE 721 notification and the PUZZLE notification. The format of the PUZZLE 722 notification is described in Section 8.1. 724 <-- HDR, N(COOKIE), N(PUZZLE), [V+][N+] 726 The presence of these notifications in an IKE_SA_INIT response 727 message indicates to the Initiator that it should solve the puzzle to 728 get better chances to be served. 730 7.1.1.1. Selecting Puzzle Difficulty Level 732 The PUZZLE notification contains the difficulty level of the puzzle - 733 the minimum number of trailing zero bits that the result of PRF must 734 contain. In diverse environments it is next to impossible for the 735 Responder to set any specific difficulty level that will result in 736 roughly the same amount of work for all Initiators, because 737 computation power of different Initiators may vary by the order of 738 magnitude, or even more. The Responder may set difficulty level to 739 0, meaning that the Initiator is requested to spend as much power to 740 solve puzzle, as it can afford. In this case no specific value of 741 ZBC is required from the Initiator, however the larger the ZBC that 742 Initiator is able to get, the better the chances it will have to be 743 served by the Responder. In diverse environments it is RECOMMENDED 744 that the Initiator sets difficulty level to 0, unless the attack 745 volume is very high. 747 If the Responder sets non-zero difficulty level, then the level 748 should be determined by analyzing the volume of the attack. The 749 Responder MAY set different difficulty levels to different requests 750 depending on the IP address the request has come from. 752 7.1.1.2. Selecting Puzzle Algorithm 754 The PUZZLE notification also contains identifier of the algorithm, 755 that must be used by Initiator to compute puzzle. 757 Cryptographic algorithm agility is considered an important feature 758 for modern protocols ([RFC7696]). This feature ensures that protocol 759 doesn't rely on a single build-in set of cryptographic algorithms, 760 but has a means to replace one set with another and negotiate new set 761 with the peer. IKEv2 fully supports cryptographic algorithm agility 762 for its core operations. 764 To support this feature in case of puzzles, the algorithm that is 765 used to compute puzzle needs to be negotiated during IKE_SA_INIT 766 exchange. The negotiation is performed as follows. The initial 767 request message sent by Initiator contains SA payload with the list 768 of transforms the Initiator supports and is willing to use in the IKE 769 SA being established. The Responder parses received SA payload and 770 finds mutually supported set of transforms of type PRF. It selects 771 most preferred transform from this set and includes it into the 772 PUZZLE notification. There is no requirement that the PRF selected 773 for puzzles be the same, as the PRF that is negotiated later for the 774 use in core IKE SA crypto operations. If there are no mutually 775 supported PRFs, then negotiation will fail anyway and there is no 776 reason to return a puzzle. In this case the Responder returns 777 NO_PROPOSAL_CHOSEN notification. Note that PRF is a mandatory 778 transform type for IKE SA (see Sections 3.3.2 and 3.3.3 of [RFC7296]) 779 and at least one transform of this type must always be present in SA 780 payload in IKE_SA_INIT request message. 782 7.1.1.3. Generating Cookie 784 If Responder supports puzzles then cookie should be computed in such 785 a manner, that the Responder is able to learn some important 786 information from the sole cookie, when it is later returned back by 787 Initiator. In particular - the Responder should be able to learn the 788 following information: 790 o Whether the puzzle was given to the Initiator or only the cookie 791 was requested. 793 o The difficulty level of the puzzle given to the Initiator. 795 o The number of consecutive puzzles given to the Initiator. 797 o The amount of time the Initiator spent to solve the puzzles. This 798 can be calculated if the cookie is timestamped. 800 This information helps the Responder to make a decision whether to 801 serve this request or demand more work from the Initiator. 803 One possible approach to get this information is to encode it in the 804 cookie. The format of such encoding is a local matter of Responder, 805 as the cookie would remain an opaque blob to the Initiator. If this 806 information is encoded in the cookie, then the Responder MUST make it 807 integrity protected, so that any intended or accidental alteration of 808 this information in returned cookie is detectable. So, the cookie 809 would be generated as: 811 Cookie = | | 812 Hash(Ni | IPi | SPIi | | ) 814 Alternatively, the Responder may continue to generate cookie as 815 suggested in Section 2.6 of [RFC7296], but associate the additional 816 information, that would be stored locally, with the particular 817 version of the secret. In this case the Responder should have 818 different secrets for every combination of difficulty level and 819 number of consecutive puzzles, and should change the secrets 820 periodically, keeping a few previous versions, to be able to 821 calculate how long ago the cookie was generated. 823 The Responder may also combine these approaches. This document 824 doesn't mandate how the Responder learns this information from the 825 cookie. 827 7.1.2. Solving Puzzle and Returning the Solution 829 If the Initiator receives a puzzle but it doesn't support puzzles, 830 then it will ignore the PUZZLE notification as an unrecognized status 831 notification (in accordance to Section 3.10.1 of [RFC7296]). The 832 Initiator also MAY ignore the PUZZLE notification if it is not 833 willing to spend resources to solve the puzzle of the requested 834 difficulty, even if it supports puzzles. In both cases the Initiator 835 acts as described in Section 2.6 of [RFC7296] - it restarts the 836 request and includes the received COOKIE notification into it. The 837 Responder should be able to distinguish the situation when it just 838 requested a cookie from the situation when the puzzle was given to 839 the Initiator, but the Initiator for some reason ignored it. 841 If the received message contains a PUZZLE notification and doesn't 842 contain a COOKIE notification, then this message is malformed because 843 it requests to solve the puzzle, but doesn't provide enough 844 information to do it. In this case the Initiator MUST ignore the 845 received message and continue to wait until either the valid one is 846 received or the retransmission timer fires. If it fails to receive 847 the valid message after several retransmissions of IKE_SA_INIT 848 request, then it means that something is wrong and the IKE SA cannot 849 be established. 851 If the Initiator supports puzzles and is ready to deal with them, 852 then it tries to solve the given puzzle. After the puzzle is solved 853 the Initiator restarts the request and returns the puzzle solution in 854 a new payload called a Puzzle Solution payload (denoted as PS, see 855 Section 8.2) along with the received COOKIE notification back to the 856 Responder. 858 HDR, N(COOKIE), [PS,] SA, KE, Ni, [V+][N+] --> 860 7.1.3. Computing Puzzle 862 General principals of constructing puzzles in IKEv2 are described in 863 Section 4.4. They can be summarized as follows: given unpredictable 864 string S and pseudo-random function PRF find N different keys Ki 865 (where i=[1..N]) for that PRF so that the result of PRF(Ki,S) has at 866 least the specified number of trailing zero bits. This specification 867 requires that the solution to the puzzle contains 4 different keys 868 (i.e. N=4). 870 In the IKE_SA_INIT exchange it is the cookie that plays the role of 871 unpredictable string S. In other words, in IKE_SA_INIT the task for 872 the IKE Initiator is to find the four different, equal-sized keys Ki 873 for the agreed upon PRF such that each result of PRF(Ki,cookie) where 874 i = [1..4] has a sufficient number of trailing zero bits. Only the 875 content of the COOKIE notification is used in puzzle calculation, 876 i.e. the header of the Notification payload is not included. 878 Note, that puzzles in the IKE_AUTH exchange are computed differently 879 than in the IKE_SA_INIT_EXCHANGE. See Section 7.2.3 for details. 881 7.1.4. Analyzing Repeated Request 883 The received request must at least contain a COOKIE notification. 884 Otherwise it is an initial request and it must be processed according 885 to Section 7.1. First, the cookie MUST be checked for validity. If 886 the cookie is invalid, then the request is treated as initial and is 887 processed according to Section 7.1. It is RECOMMENDED that a new 888 cookie is requested in this case. 890 If the cookie is valid then some important information is learned 891 from it or from local state based on identifier of the cookie's 892 secret (see Section 7.1.1.3 for details). This information helps the 893 Responder to sort out incoming requests, giving more priority to 894 those of them, which were created by spending more of the Initiator's 895 resources. 897 First, the Responder determines if it requested only a cookie, or 898 presented a puzzle to the Initiator. If no puzzle was given, then it 899 means that at the time the Responder requested a cookie it didn't 900 detect the (D)DoS attack or the attack volume was low. In this case 901 the received request message must not contain the PS payload, and 902 this payload MUST be ignored if for any reason the message contains 903 it. Since no puzzle was given, the Responder marks the request with 904 the lowest priority since the Initiator spent little resources 905 creating it. 907 If the Responder learns from the cookie that the puzzle was given to 908 the Initiator, then it looks for the PS payload to determine whether 909 its request to solve the puzzle was honored or not. If the incoming 910 message doesn't contain a PS payload, then it means that the 911 Initiator either doesn't support puzzles or doesn't want to deal with 912 them. In either case the request is marked with the lowest priority 913 since the Initiator spent little resources creating it. 915 If a PS payload is found in the message, then the Responder MUST 916 verify the puzzle solution that it contains. The solution is 917 interpreted as four different keys. The result of using each of them 918 in the PRF (as described in Section 7.1.3) must contain at least the 919 requested number of trailing zero bits. The Responder MUST check all 920 the four returned keys. 922 If any checked result contains fewer bits than were requested, it 923 means that the Initiator spent less resources than expected by the 924 Responder. This request is marked with the lowest priority. 926 If the Initiator provided the solution to the puzzle satisfying the 927 requested difficulty level, or if the Responder didn't indicate any 928 particular difficulty level (by setting ZBC to zero) and the 929 Initiator was free to select any difficulty level it can afford, then 930 the priority of the request is calculated based on the following 931 considerations: 933 o The Responder must take the smallest number of trailing zero bits 934 among the checked results and count it as the number of zero bits 935 the Initiator got. 937 o The higher number of zero bits the Initiator got, the higher 938 priority its request should receive. 940 o The more consecutive puzzles the Initiator solved, the higher 941 priority it should receive. 943 o The more time the Initiator spent solving the puzzles, the higher 944 priority it should receive. 946 After the priority of the request is determined the final decision 947 whether to serve it or not is made. 949 7.1.5. Making Decision whether to Serve the Request 951 The Responder decides what to do with the request based on its 952 priority and Responder's current load. There are three possible 953 actions: 955 o Accept request. 957 o Reject request. 959 o Demand more work from Initiator by giving it a new puzzle. 961 The Responder SHOULD accept an incoming request if its priority is 962 high - it means that the Initiator spent quite a lot of resources. 963 The Responder MAY also accept some of low-priority requests where the 964 Initiators don't support puzzles. The percentage of accepted legacy 965 requests depends on the Responder's current load. 967 If the Initiator solved the puzzle, but didn't spend much resources 968 for it (the selected puzzle difficulty level appeared to be low and 969 the Initiator solved it quickly), then the Responder SHOULD give it 970 another puzzle. The more puzzles the Initiator solves the higher its 971 chances are to be served. 973 The details of how the Responder makes a decision for any particular 974 request, are implementation dependent. The Responder can collect all 975 the incoming requests for some short period of time, sort them out 976 based on their priority, calculate the number of available memory 977 slots for half-open IKE SAs and then serve that number of requests 978 from the head of the sorted list. The rest of requests can be either 979 discarded or responded to with new puzzles. 981 Alternatively, the Responder may decide whether to accept every 982 incoming request with some kind of lottery, taking into account its 983 priority and the available resources. 985 7.2. Puzzles in IKE_AUTH Exchange 987 Once the IKE_SA_INIT exchange is completed, the Responder has created 988 a state and is waiting for the first message of the IKE_AUTH exchange 989 from the Initiator. At this point the Initiator has already passed 990 return routability check and has proved that it has performed some 991 work to complete IKE_SA_INIT exchange. However, the Initiator is not 992 yet authenticated and this fact allows malicious Initiator to perform 993 an attack, described in Section 3. Unlike DoS attack in IKE_SA_INIT 994 exchange, which is targeted on the Responder's memory resources, the 995 goal of this attack is to exhaust a Responder's CPU power. The 996 attack is performed by sending the first IKE_AUTH message containing 997 garbage. This costs nothing to the Initiator, but the Responder has 998 to do relatively costly operations of computing the D-H shared secret 999 and deriving SK_* keys to be able to verify authenticity of the 1000 message. If the Responder doesn't keep the computed keys after an 1001 unsuccessful verification of the IKE_AUTH message, then the attack 1002 can be repeated several times on the same IKE SA. 1004 The Responder can use puzzles to make this attack more costly for the 1005 Initiator. The idea is that the Responder includes a puzzle in the 1006 IKE_SA_INIT response message and the Initiator includes a puzzle 1007 solution in the first IKE_AUTH request message outside the Encrypted 1008 payload, so that the Responder is able to verify puzzle solution 1009 before computing D-H shared secret. The difficulty level of the 1010 puzzle should be selected so that the Initiator would spend 1011 substantially more time to solve the puzzle than the Responder to 1012 compute the shared secret. 1014 The Responder should constantly monitor the amount of the half-open 1015 IKE SA states that receive IKE_AUTH messages that cannot be decrypted 1016 due to integrity check failures. If the percentage of such states is 1017 high and it takes an essential fraction of Responder's computing 1018 power to calculate keys for them, then the Responder may assume that 1019 it is under attack and SHOULD use puzzles to make it harder for 1020 attackers. 1022 7.2.1. Presenting Puzzle 1024 The Responder requests the Initiator to solve a puzzle by including 1025 the PUZZLE notification in the IKE_SA_INIT response message. The 1026 Responder MUST NOT use puzzles in the IKE_AUTH exchange unless the 1027 puzzle has been previously presented and solved in the preceding 1028 IKE_SA_INIT exchange. 1030 <-- HDR, SA, KE, Nr, N(PUZZLE), [V+][N+] 1032 7.2.1.1. Selecting Puzzle Difficulty Level 1034 The difficulty level of the puzzle in IKE_AUTH exchange should be 1035 chosen so that the Initiator would spend more time to solve the 1036 puzzle than the Responder to compute the D-H shared secret and the 1037 keys, needed to decrypt and verify the IKE_AUTH request message. On 1038 the other hand, the difficulty level should not be too high, 1039 otherwise the legitimate clients would experience an additional delay 1040 while establishing IKE SA. 1042 Note, that since puzzles in the IKE_AUTH exchange are only allowed to 1043 be used if they were used in the preceding IKE_SA_INIT exchange, the 1044 Responder would be able to estimate the computational power of the 1045 Initiator and to select the difficulty level accordingly. Unlike 1046 puzzles in IKE_SA_INIT, the requested difficulty level for IKE_AUTH 1047 puzzles MUST NOT be zero. In other words, the Responder must always 1048 set specific difficulty level and must not let the Initiator to 1049 choose it on its own. 1051 7.2.1.2. Selecting Puzzle Algorithm 1053 The algorithm for the puzzle is selected as described in 1054 Section 7.1.1.2. There is no requirement, that the algorithm for the 1055 puzzle in the IKE_SA INIT exchange be the same, as the algorithm for 1056 the puzzle in IKE_AUTH exchange, however it is expected that in most 1057 cases they will be the same. 1059 7.2.2. Solving Puzzle and Returning the Solution 1061 If the IKE_SA_INIT response message contains the PUZZLE notification 1062 and the Initiator supports puzzles, it MUST solve the puzzle. Note, 1063 that puzzle construction in the IKE_AUTH exchange differs from the 1064 puzzle construction in the IKE_SA_INIT exchange and is described in 1065 Section 7.2.3. Once the puzzle is solved the Initiator sends the 1066 IKE_AUTH request message, containing the Puzzle Solution payload. 1068 HDR, PS, SK {IDi, [CERT,] [CERTREQ,] 1069 [IDr,] AUTH, SA, TSi, TSr} --> 1071 The Puzzle Solution payload MUST be placed outside the Encrypted 1072 payload, so that the Responder would be able to verify the puzzle 1073 before calculating the D-H shared secret and the SK_* keys. 1075 If IKE Fragmentation [RFC7383] is used in IKE_AUTH exchange, then the 1076 PS payload MUST be present only in the first IKE Fragment message, in 1077 accordance with the Section 2.5.3 of [RFC7383]. Note, that 1078 calculation of the puzzle in the IKE_AUTH exchange doesn't depend on 1079 the content of the IKE_AUTH message (see Section 7.2.3). Thus the 1080 Initiator has to solve the puzzle only once and the solution is valid 1081 for both unfragmented and fragmented IKE messages. 1083 7.2.3. Computing Puzzle 1085 The puzzles in the IKE_AUTH exchange are computed differently than in 1086 the IKE_SA_INIT exchange (see Section 7.1.3). The general principle 1087 is the same; the difference is in the construction of the string S. 1088 Unlike the IKE_SA_INIT exchange, where S is the cookie, in the 1089 IKE_AUTH exchange S is a concatenation of Nr and SPIr. In other 1090 words, the task for IKE Initiator is to find the four different keys 1091 Ki for the agreed upon PRF such that each result of PRF(Ki,Nr | SPIr) 1092 where i=[1..4] has a sufficient number of trailing zero bits. Nr is 1093 a nonce used by the Responder in IKE_SA_INIT exchange, stripped of 1094 any headers. SPIr is IKE Responder's SPI from the IKE header of the 1095 SA being established. 1097 7.2.4. Receiving Puzzle Solution 1099 If the Responder requested the Initiator to solve a puzzle in the 1100 IKE_AUTH exchange, then it MUST silently discard all the IKE_AUTH 1101 request messages without the Puzzle Solution payload. 1103 Once the message containing a solution to the puzzle is received, the 1104 Responder MUST verify the solution before performing computationlly 1105 intensive operations i.e. computing the D-H shared secret and the 1106 SK_* keys. The Responder MUST verify all the four returned keys. 1108 The Responder MUST silently discard the received message if any 1109 checked verification result is not correct (contains insufficient 1110 number of trailing zero bits). If the Responder successfully 1111 verifies the puzzle and calculates the SK_* key, but the message 1112 authenticity check fails, then it SHOULD save the calculated keys in 1113 the IKE SA state while waiting for the retransmissions from the 1114 Initiator. In this case the Responder may skip verification of the 1115 puzzle solution and ignore the Puzzle Solution payload in the 1116 retransmitted messages. 1118 If the Initiator uses IKE Fragmentation, then it is possible, that 1119 due to packet loss and/or reordering the Responder could receive non- 1120 first IKE Fragment messages before receiving the first one, 1121 containing the PS payload. In this case the Responder MAY choose to 1122 keep the received fragments until the first fragment containing the 1123 solution to the puzzle is received. However, in this case the 1124 Responder SHOULD NOT try to verify authenticity of the kept fragments 1125 until the first fragment with the PS payload is received and the 1126 solution to the puzzle is verified. After successful verification of 1127 the puzzle the Responder could calculate the SK_* key and verify 1128 authenticity of the collected fragments. 1130 8. Payload Formats 1132 8.1. PUZZLE Notification 1134 The PUZZLE notification is used by the IKE Responder to inform the 1135 Initiator about the necessity to solve the puzzle. It contains the 1136 difficulty level of the puzzle and the PRF the Initiator should use. 1138 1 2 3 1139 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 1140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1141 | Next Payload |C| RESERVED | Payload Length | 1142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1143 |Protocol ID(=0)| SPI Size (=0) | Notify Message Type | 1144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1145 | PRF | Difficulty | 1146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1148 o Protocol ID (1 octet) -- MUST be 0. 1150 o SPI Size (1 octet) - MUST be 0, meaning no Security Parameter 1151 Index (SPI) is present. 1153 o Notify Message Type (2 octets) -- MUST be , the value 1154 assigned for the PUZZLE notification. 1156 o PRF (2 octets) -- Transform ID of the PRF algorithm that must be 1157 used to solve the puzzle. Readers should refer to the section 1158 "Transform Type 2 - Pseudo-Random Function Transform IDs" in 1159 [IKEV2-IANA] for the list of possible values. 1161 o Difficulty (1 octet) -- Difficulty Level of the puzzle. Specifies 1162 minimum number of trailing zero bits (ZBC), that each of the 1163 results of PRF must contain. Value 0 means that the Responder 1164 doesn't request any specific difficulty level and the Initiator is 1165 free to select appropriate difficulty level on its own (see 1166 Section 7.1.1.1 for details). 1168 This notification contains no data. 1170 8.2. Puzzle Solution Payload 1172 The solution to the puzzle is returned back to the Responder in a 1173 dedicated payload, called the Puzzle Solution payload and denoted as 1174 PS in this document. 1176 1 2 3 1177 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 1178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1179 | Next Payload |C| RESERVED | Payload Length | 1180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1181 | | 1182 ~ Puzzle Solution Data ~ 1183 | | 1184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1185 o Puzzle Solution Data (variable length) -- Contains the solution to 1186 the puzzle - four different keys for the selected PRF. This field 1187 MUST NOT be empty. All the keys MUST have the same size, 1188 therefore the size of this field is always a mutiple of 4 bytes. 1189 If the selected PRF accepts only fixed-size keys, then the size of 1190 each key MUST be of that fixed size. If the PRF agreed upon 1191 accepts keys of any size, then then the size of each key MUST be 1192 between 1 octet and the preferred key length of the PRF 1193 (inclusive). It is expected that in most cases the keys will be 4 1194 (or even less) octets in length, however it depends on puzzle 1195 difficulty and on the Initiator's strategy to find solutions, and 1196 thus the size is not mandated by this specification. The 1197 Responder determines the size of each key by dividing the size of 1198 the Puzzle Solution Data by 4 (the number of keys). Note that the 1199 size of Puzzle Solution Data is the size of Payload (as indicated 1200 in Payload Length field) minus 4 - the size of Payload Header. 1202 The payload type for the Puzzle Solution payload is . 1204 9. Operational Considerations 1206 The difficulty level should be set by balancing the requirement to 1207 minimize the latency for legitimate Initiators and making things 1208 difficult for attackers. A good rule of thumb is for taking about 1 1209 second to solve the puzzle. A typical Initiator or bot-net member in 1210 2014 can perform slightly less than a million hashes per second per 1211 core, so setting the difficulty level to n=20 is a good compromise. 1212 It should be noted that mobile Initiators, especially phones are 1213 considerably weaker than that. Implementations should allow 1214 administrators to set the difficulty level, and/or be able to set the 1215 difficulty level dynamically in response to load. 1217 Initiators should set a maximum difficulty level beyond which they 1218 won't try to solve the puzzle and log or display a failure message to 1219 the administrator or user. 1221 10. Security Considerations 1223 When selecting parameters for the puzzles, in particular the puzzle 1224 difficulty, care must be taken. If the puzzles appeared too easy for 1225 majority of the attackers, then the puzzles mechanism wouldn't be 1226 able to prevent DoS attack and would only impose an additional burden 1227 on the legitimate Initiators. On the other hand, if the puzzles 1228 appeared to be too hard for majority of the Initiators then many 1229 legitimate users would experience unacceptable delay in IKE SA setup 1230 (or unacceptable power consumption on mobile devices), that might 1231 cause them to cancel connection attempt. In this case the resources 1232 of the Responder are preserved, however the DoS attack can be 1233 considered successful. Thus a sensible balance should be kept by the 1234 Responder while choosing the puzzle difficulty - to defend itself and 1235 to not over-defend itself. It is RECOMMENDED that the puzzle 1236 difficulty be chosen so, that the Responder's load remain close to 1237 the maximum it can tolerate. It is also RECOMMENDED to dynamically 1238 adjust the puzzle difficulty in accordance to the current Responder's 1239 load. 1241 Solving puzzles requires a lot of CPU power, that would increase 1242 power consumption. This would influence battery-powered Initiators, 1243 e.g. mobile phones or some IoT devices. If puzzles are hard then the 1244 required additional power consumption may appear to be unacceptable 1245 for some Initiators. The Responder SHOULD take this possibility into 1246 considerations while choosing the puzzles difficulty and while 1247 selecting which percentage of Initiators are allowed to reject 1248 solving puzzles. See Section 7.1.4 for details. 1250 If the Initiator uses NULL Authentication [RFC7619] then its identity 1251 is never verified, that may be used by attackers to perform DoS 1252 attack after IKE SA is established. Responders that allow 1253 unauthenticated Initiators to connect must be prepared to deal with 1254 various kinds of DoS attacks even after IKE SA is created. See 1255 Section 5 for details. 1257 To prevent amplification attacks implementations must strictly follow 1258 the retransmission rules described in Section 2.1 of [RFC7296]. 1260 11. IANA Considerations 1262 This document defines a new payload in the "IKEv2 Payload Types" 1263 registry: 1265 Puzzle Solution PS 1267 This document also defines a new Notify Message Type in the "IKEv2 1268 Notify Message Types - Status Types" registry: 1270 PUZZLE 1272 12. Acknowledgements 1274 The authors thank Tero Kivinen, Yaron Sheffer and Scott Fluhrer for 1275 their contribution into design of the protocol. In particular, Tero 1276 Kivinen suggested the kind of puzzle where the task is to find a 1277 solution with requested number of zero trailing bits. Yaron Sheffer 1278 and Scott Fluhrer suggested a way to make puzzle difficulty less 1279 erratic by solving several weaker puzles. The authors also thank 1280 David Waltermire for his carefull review of the document, Graham 1281 Bartlett for pointing out to the possibility of "Hash & URL" related 1282 attack, and all others who commented the document. 1284 13. References 1286 13.1. Normative References 1288 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1289 Requirement Levels", BCP 14, RFC 2119, 1290 DOI 10.17487/RFC2119, March 1997, 1291 . 1293 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 1294 Kivinen, "Internet Key Exchange Protocol Version 2 1295 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 1296 2014, . 1298 [RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2 1299 (IKEv2) Message Fragmentation", RFC 7383, 1300 DOI 10.17487/RFC7383, November 2014, 1301 . 1303 [IKEV2-IANA] 1304 "Internet Key Exchange Version 2 (IKEv2) Parameters", 1305 . 1307 13.2. Informative References 1309 [bitcoins] 1310 Nakamoto, S., "Bitcoin: A Peer-to-Peer Electronic Cash 1311 System", October 2008, . 1313 [RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange 1314 Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, 1315 DOI 10.17487/RFC5723, January 2010, 1316 . 1318 [RFC7619] Smyslov, V. and P. Wouters, "The NULL Authentication 1319 Method in the Internet Key Exchange Protocol Version 2 1320 (IKEv2)", RFC 7619, DOI 10.17487/RFC7619, August 2015, 1321 . 1323 [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm 1324 Agility and Selecting Mandatory-to-Implement Algorithms", 1325 BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, 1326 . 1328 Authors' Addresses 1330 Yoav Nir 1331 Check Point Software Technologies Ltd. 1332 5 Hasolelim st. 1333 Tel Aviv 6789735 1334 Israel 1336 EMail: ynir.ietf@gmail.com 1338 Valery Smyslov 1339 ELVIS-PLUS 1340 PO Box 81 1341 Moscow (Zelenograd) 124460 1342 Russian Federation 1344 Phone: +7 495 276 0211 1345 EMail: svan@elvis.ru