idnits 2.17.1 draft-ietf-ipsecme-ddos-protection-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document 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 (March 1, 2016) is 2971 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: September 2, 2016 ELVIS-PLUS 6 March 1, 2016 8 Protecting Internet Key Exchange Protocol version 2 (IKEv2) 9 Implementations from Distributed Denial of Service Attacks 10 draft-ietf-ipsecme-ddos-protection-04 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 September 2, 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. The Stateless Cookie . . . . . . . . . . . . . . . . . . 3 56 1.2. Conventions Used in This Document . . . . . . . . . . . . 4 57 2. The Vulnerability . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Puzzles . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 4. Retention Periods for Half-Open SAs . . . . . . . . . . . . . 8 60 5. Rate Limiting . . . . . . . . . . . . . . . . . . . . . . . . 9 61 6. Plan for Defending a Responder . . . . . . . . . . . . . . . 10 62 6.1. Session Resumption . . . . . . . . . . . . . . . . . . . 12 63 7. Using Puzzles in the Protocol . . . . . . . . . . . . . . . . 12 64 7.1. Puzzles in IKE_SA_INIT Exchange . . . . . . . . . . . . . 12 65 7.1.1. Presenting Puzzle . . . . . . . . . . . . . . . . . . 13 66 7.1.2. Solving Puzzle and Returning the Solution . . . . . . 15 67 7.1.3. Computing Puzzle . . . . . . . . . . . . . . . . . . 16 68 7.1.4. Analyzing Repeated Request . . . . . . . . . . . . . 16 69 7.1.5. Making Decision whether to Serve the Request . . . . 18 70 7.2. Puzzles in IKE_AUTH Exchange . . . . . . . . . . . . . . 19 71 7.2.1. Presenting Puzzle . . . . . . . . . . . . . . . . . . 19 72 7.2.2. Solving Puzzle and Returning the Solution . . . . . . 20 73 7.2.3. Computing Puzzle . . . . . . . . . . . . . . . . . . 21 74 7.2.4. Receiving Puzzle Solution . . . . . . . . . . . . . . 21 75 8. DoS Protection after IKE SA is created . . . . . . . . . . . 22 76 9. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 23 77 9.1. PUZZLE Notification . . . . . . . . . . . . . . . . . . . 23 78 9.2. Puzzle Solution Payload . . . . . . . . . . . . . . . . . 24 79 10. Operational Considerations . . . . . . . . . . . . . . . . . 24 80 11. Security Considerations . . . . . . . . . . . . . . . . . . . 25 81 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 82 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 83 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 84 14.1. Normative References . . . . . . . . . . . . . . . . . . 26 85 14.2. Informative References . . . . . . . . . . . . . . . . . 27 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 88 1. Introduction 90 Denial of Service (DoS) attacks have always been considered a serious 91 threat. These attacks are usually difficult to defend against since 92 the amount of resources the victim has is always bounded (regardless 93 of how high it is) and because some resources are required for 94 distinguishing a legitimate session from an attack. 96 The Internet Key Exchange protocol (IKE) described in [RFC7296] 97 includes defense against DoS attacks. In particular, there is a 98 cookie mechanism that allows the IKE Responder to effectively defend 99 itself against DoS attacks from spoofed IP-addresses. However, bot- 100 nets have become widespread, allowing attackers to perform 101 Distributed Denial of Service (DDoS) attacks, which are more 102 difficult to defend against. This document presents recommendations 103 to help the Responder thwart (D)DoS attacks. It also introduces a 104 new mechanism -- "puzzles" -- that can help accomplish this task. 106 The IKE_SA_INIT Exchange described in Section 1.2 of [RFC7296] 107 involves the Initiator sending a single message. The Responder 108 replies with a single message and also allocates memory for a 109 structure called a half-open IKE Security Association (SA). This 110 half-open SA is later authenticated in the IKE_AUTH Exchange. If 111 that IKE_AUTH request never comes, the half-open SA is kept for an 112 unspecified amount of time. Depending on the algorithms used and 113 implementation, such a half-open SA will use from around 100 bytes to 114 several thousands bytes of memory. 116 This creates an easy attack vector against an IKE Responder. 117 Generating the IKE_SA_INIT request is cheap, and sending multiple 118 such requests can either cause the Responder to allocate too much 119 resources and fail, or else if resource allocation is somehow 120 throttled, legitimate Initiators would also be prevented from setting 121 up IKE SAs. 123 An obvious defense, which is described in Section 5, is limiting the 124 number of half-open SAs opened by a single peer. However, since all 125 that is required is a single packet, an attacker can use multiple 126 spoofed source IP addresses. 128 1.1. The Stateless Cookie 130 Section 2.6 of [RFC7296] offers a mechanism to mitigate this DoS 131 attack: the stateless cookie. When the server is under load, the 132 Responder responds to the IKE_SA_INIT request with a calculated 133 "stateless cookie" - a value that can be re-calculated based on 134 values in the IKE_SA_INIT request without storing Responder-side 135 state. The Initiator is expected to repeat the IKE_SA_INIT request, 136 this time including the stateless cookie. 138 Attackers that have multiple source IP addresses with return 139 routability, such as in the case of bot-nets, can fill up a half-open 140 SA table anyway. The cookie mechanism limits the amount of allocated 141 state to the size of the bot-net, multiplied by the number of half- 142 open SAs allowed per peer address, multiplied by the amount of state 143 allocated for each half-open SA. With typical values this can easily 144 reach hundreds of megabytes. 146 The mechanism described in Section 3 adds a proof of work for the 147 Initiator by calculating a pre-image for a partial hash value. This 148 sets an upper bound, determined by the attacker's CPU, to the number 149 of negotiations it can initiate in a unit of time. 151 1.2. Conventions Used in This Document 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in [RFC2119]. 157 2. The Vulnerability 159 If we break down what a Responder has to do during an initial 160 exchange, there are three stages: 162 1. When the IKE_SA_INIT request arrives, the Responder: 164 * Generates or re-uses a Diffie-Hellman (D-H) private part. 166 * Generates a Responder Security Parameter Index (SPI). 168 * Stores the private part and peer public part in a half-open SA 169 database. 171 2. When the IKE_AUTH request arrives, the Responder: 173 * Derives the keys from the half-open SA. 175 * Decrypts the request. 177 3. If the IKE_AUTH request decrypts properly: 179 * Validates the certificate chain (if present) in the IKE_AUTH 180 request. 182 Yes, there's a stage 4 where the Responder actually creates Child 183 SAs, but when talking about (D)DoS, we never get to this stage. 185 Stage #1 is pretty light on CPU power, but requires some storage, and 186 it's very light for the Initiator as well. Stage #2 includes 187 private-key operations, so it's much heavier CPU-wise. Stage #3 188 includes public key operations, typically more than one. 190 To attack such a Responder, an attacker can attempt to either exhaust 191 memory or to exhaust CPU. Without any protection, the most efficient 192 attack is to send multiple IKE_SA_INIT requests and exhaust memory. 193 This should be easy because those requests are cheap. 195 There are obvious ways for the Responder to protect itself even 196 without changes to the protocol. It can reduce the time that an 197 entry remains in the half-open SA database, and it can limit the 198 amount of concurrent half-open SAs from a particular address or 199 prefix. The attacker can overcome this by using spoofed source 200 addresses. 202 The stateless cookie mechanism from Section 2.6 of [RFC7296] prevents 203 an attack with spoofed source addresses. This doesn't completely 204 solve the issue, but it makes the limiting of half-open SAs by 205 address or prefix work. Puzzles do the same thing only more of it. 206 They make it harder for an attacker to reach the goal of getting a 207 half-open SA. They don't have to be so hard that an attacker can't 208 afford to solve a single puzzle; it's enough that they increase the 209 cost of a half-open SAs for the attacker so that it can create only a 210 few. 212 Reducing the amount of time an abandoned half-open SA is kept attacks 213 the issue from the other side. It reduces the value the attacker 214 gets from managing to create a half-open SA. For example, if a half- 215 open SA is kept for 1 minute and the capacity is 60,000 half-open 216 SAs, an attacker would need to create 1,000 half-open SAs per second. 217 Reduce the retention time to 3 seconds, and the attacker needs to 218 create 20,000 half-open SAs per second. By introducing a puzzle, 219 each half-open SA becomes more expensive for an attacker, making it 220 more likely to thwart an exhaustion attack against Responder memory. 222 At this point, filling up the half-open SA database is no longer the 223 most efficient DoS attack. The attacker has two ways to do better: 225 1. Go back to spoofed addresses and try to overwhelm the CPU that 226 deals with generating cookies, or 228 2. Take the attack to the next level by also sending an IKE_AUTH 229 request. 231 It seems that the first thing cannot be dealt with at the IKE level. 232 It's probably better left to Intrusion Prevention System (IPS) 233 technology. 235 On the other hand, sending an IKE_AUTH request is surprisingly cheap. 236 It requires a proper IKE header with the correct IKE SPIs, and it 237 requires a single Encrypted payload. The content of the payload 238 might as well be junk. The Responder has to perform the relatively 239 expensive key derivation, only to find that the MAC on the Encrypted 240 payload on the IKE_AUTH request does not check. Depending on the 241 Responder implementation, this can be repeated with the same half- 242 open SA (if the Responder does not delete the half-open SA following 243 an unsuccessful decryption - see discussion in Section 4). 245 Here too, the number of half-open SAs that the attacker can achieve 246 is crucial, because each one allows the attacker to waste some CPU 247 time. So making it hard to make many half-open SAs is important. 249 A strategy against DDoS has to rely on at least 4 components: 251 1. Hardening the half-open SA database by reducing retention time. 253 2. Hardening the half-open SA database by rate-limiting single IPs/ 254 prefixes. 256 3. Guidance on what to do when an IKE_AUTH request fails to decrypt. 258 4. Increasing cost of half-open SA up to what is tolerable for 259 legitimate clients. 261 Puzzles have their place as part of #4. 263 3. Puzzles 265 The puzzle introduced here extends the cookie mechanism from 266 [RFC7296]. It is loosely based on the proof-of-work technique used 267 in Bitcoins [bitcoins]. 269 A puzzle is sent to the Initiator in two cases: 271 o The Responder is so overloaded that no half-open SAs may be 272 created without solving a puzzle, or 274 o The Responder is not too loaded, but the rate-limiting method 275 described in Section 5 prevents half-open SAs from being created 276 with this particular peer address or prefix without first solving 277 a puzzle. 279 When the Responder decides to send the challenge notification in 280 response to a IKE_SA_INIT request, the notification includes three 281 fields: 283 1. Cookie - this is calculated the same as in [RFC7296], i.e. the 284 process of generating the cookie is not specified. 286 2. Algorithm, this is the identifier of a Pseudo-Random Function 287 (PRF) algorithm, one of those proposed by the Initiator in the SA 288 payload. 290 3. Zero Bit Count (ZBC). This is a number between 8 and 255 (or a 291 special value - 0, see Section 7.1.1.1) that represents the 292 length of the zero-bit run at the end of the output of the PRF 293 function calculated over the cookie that the Initiator is to 294 send. The values 1-8 are explicitly excluded, because they 295 create a puzzle that is too easy to solve for it to make any 296 difference in mitigating DDoS attacks. Since the mechanism is 297 supposed to be stateless for the Responder, either the same ZBC 298 is used for all Initiators, or the ZBC is somehow encoded in the 299 cookie. If it is global then it means that this value is the 300 same for all the Initiators who are receiving puzzles at any 301 given point of time. The Responder, however, may change this 302 value over time depending on its load. 304 Upon receiving this challenge, the Initiator attempts to calculate 305 the PRF using different keys. When enough keys are found such that 306 the resulting PRF output calculated using each of them has a 307 sufficient number of trailing zero bits, that result is sent to the 308 Responder. 310 The reason for using several keys in the results rather than just one 311 key is to reduce the variance in the time it takes the initiator to 312 solve the puzzle. We have chosen the number of keys to be four (4) 313 as a compromise between the conflicting goals of reducing variance 314 and reducing the work the Responder needs to perform to verify the 315 puzzle solution. 317 When receiving a request with a solved puzzle, the Responder verifies 318 two things: 320 o That the cookie part is indeed valid. 322 o That the PRFs of the transmitted cookie calculated with the 323 transmitted keys has a sufficient number of trailing zero bits. 325 Example 1: Suppose the calculated cookie is 326 739ae7492d8a810cf5e8dc0f9626c9dda773c5a3 (20 octets), the algorithm 327 is PRF-HMAC-SHA256, and the required number of zero bits is 18. 328 After successively trying a bunch of keys, the Initiator finds the 329 following four 3-octet keys that work: 331 +--------+----------------------------------+----------+ 332 | Key | Last 32 Hex PRF Digits | # 0-bits | 333 +--------+----------------------------------+----------+ 334 | 061840 | e4f957b859d7fb1343b7b94a816c0000 | 18 | 335 | 073324 | 0d4233d6278c96e3369227a075800000 | 23 | 336 | 0c8a2a | 952a35d39d5ba06709da43af40700000 | 20 | 337 | 0d94c8 | 5a0452b21571e401a3d00803679c0000 | 18 | 338 +--------+----------------------------------+----------+ 340 Table 1: Three solutions for 18-bit puzzle 342 Example 2: Same cookie, but modify the required number of zero bits 343 to 22. The first 4-octet keys that work to satisfy that requirement 344 are 005d9e57, 010d8959, 0110778d, and 01187e37. Finding these 345 requires 18,382,392 invocations of the PRF. 347 +----------+-------------------------------+ 348 | # 0-bits | Time to Find 4 keys (seconds) | 349 +----------+-------------------------------+ 350 | 8 | 0.0025 | 351 | 10 | 0.0078 | 352 | 12 | 0.0530 | 353 | 14 | 0.2521 | 354 | 16 | 0.8504 | 355 | 17 | 1.5938 | 356 | 18 | 3.3842 | 357 | 19 | 3.8592 | 358 | 20 | 10.8876 | 359 +----------+-------------------------------+ 361 Table 2: The time needed to solve a puzzle of various difficulty for 362 the cookie = 739ae7492d8a810cf5e8dc0f9626c9dda773c5a3 364 The figures above were obtained on a 2.4 GHz single core i5. Run 365 times can be halved or quartered with multi-core code, but would be 366 longer on mobile phone processors, even if those are multi-core as 367 well. With these figures 18 bits is believed to be a reasonable 368 choice for puzzle level difficulty for all Initiators, and 20 bits is 369 acceptable for specific hosts/prefixes. 371 4. Retention Periods for Half-Open SAs 373 As a UDP-based protocol, IKEv2 has to deal with packet loss through 374 retransmissions. Section 2.4 of [RFC7296] recommends "that messages 375 be retransmitted at least a dozen times over a period of at least 376 several minutes before giving up". Retransmission policies in 377 practice wait at least one or two seconds before retransmitting for 378 the first time. 380 Because of this, setting the timeout on a half-open SA too low will 381 cause it to expire whenever even one IKE_AUTH request packet is lost. 382 When not under attack, the half-open SA timeout SHOULD be set high 383 enough that the Initiator will have enough time to send multiple 384 retransmissions, minimizing the chance of transient network 385 congestion causing IKE failure. 387 When the system is under attack, as measured by the amount of half- 388 open SAs, it makes sense to reduce this lifetime. The Responder 389 should still allow enough time for the round-trip, enough time for 390 the Initiator to derive the D-H shared value, and enough time to 391 derive the IKE SA keys and the create the IKE_AUTH request. Two 392 seconds is probably as low a value as can realistically be used. 394 It could make sense to assign a shorter value to half-open SAs 395 originating from IP addresses or prefixes that are considered suspect 396 because of multiple concurrent half-open SAs. 398 5. Rate Limiting 400 Even with DDoS, the attacker has only a limited amount of nodes 401 participating in the attack. By limiting the amount of half-open SAs 402 that are allowed to exist concurrently with each such node, the total 403 amount of half-open SAs is capped, as is the total amount of key 404 derivations that the Responder is forced to complete. 406 In IPv4 it makes sense to limit the number of half-open SAs based on 407 IP address. Most IPv4 nodes are either directly attached to the 408 Internet using a routable address or are hidden behind a NAT device 409 with a single IPv4 external address. IPv6 networks are currently a 410 rarity, so we can only speculate on what their wide deployment will 411 be like, but the current thinking is that ISP customers will be 412 assigned whole subnets, so we don't expect the kind of NAT deployment 413 that is common in IPv4. For this reason, it makes sense to use a 414 64-bit prefix as the basis for rate limiting in IPv6. 416 The number of half-open SAs is easy to measure, but it is also 417 worthwhile to measure the number of failed IKE_AUTH exchanges. If 418 possible, both factors should be taken into account when deciding 419 which IP address or prefix is considered suspicious. 421 There are two ways to rate-limit a peer address or prefix: 423 1. Hard Limit - where the number of half-open SAs is capped, and any 424 further IKE_SA_INIT requests are rejected. 426 2. Soft Limit - where if a set number of half-open SAs exist for a 427 particular address or prefix, any IKE_SA_INIT request will 428 require solving a puzzle. 430 The advantage of the hard limit method is that it provides a hard cap 431 on the amount of half-open SAs that the attacker is able to create. 432 The downside is that it allows the attacker to block IKE initiation 433 from small parts of the Internet. For example, if an network service 434 provider or some establishment offers Internet connectivity to its 435 customers or employees through an IPv4 NAT device, a single malicious 436 customer can create enough half-open SAs to fill the quota for the 437 NAT device external IP address. Legitimate Initiators on the same 438 network will not be able to initiate IKE. 440 The advantage of a soft limit is that legitimate clients can always 441 connect. The disadvantage is that an adversary with sufficient CPU 442 resources can still effectively DoS the Responder. 444 Regardless of the type of rate-limiting used, there is a huge 445 advantage in blocking the DoS attack using rate-limiting for 446 legitimate clients that are away from the attacking nodes. In such 447 cases, adverse impacts caused by the attack or by the measures used 448 to counteract the attack can be avoided. 450 6. Plan for Defending a Responder 452 This section outlines a plan for defending a Responder from a DDoS 453 attack based on the techniques described earlier. The numbers given 454 here are not normative, and their purpose is to illustrate the 455 configurable parameters needed for defeating the DDoS attack. 457 Implementations may be deployed in different environments, so it is 458 RECOMMENDED that the parameters be settable. As an example, most 459 commercial products are required to undergo benchmarking where the 460 IKE SA establishment rate is measured. Benchmarking is 461 indistinguishable from a DoS attack and the defenses described in 462 this document may defeat the benchmark by causing exchanges to fail 463 or take a long time to complete. Parameters should be tunable to 464 allow for benchmarking (if only by turning DDoS protection off). 466 Since all countermeasures may cause delays and work on the 467 Initiators, they SHOULD NOT be deployed unless an attack is likely to 468 be in progress. To minimize the burden imposed on Initiators, the 469 Responder should monitor incoming IKE requests, searching for two 470 things: 472 1. A general DDoS attack. Such an attack is indicated by a high 473 number of concurrent half-open SAs, a high rate of failed 474 IKE_AUTH exchanges, or a combination of both. For example, 475 consider a Responder that has 10,000 distinct peers of which at 476 peak 7,500 concurrently have VPN tunnels. At the start of peak 477 time, 600 peers might establish tunnels at any given minute, and 478 tunnel establishment (both IKE_SA_INIT and IKE_AUTH) takes 479 anywhere from 0.5 to 2 seconds. For this Responder, we expect 480 there to be less than 20 concurrent half-open SAs, so having 100 481 concurrent half-open SAs can be interpreted as an indication of 482 an attack. Similarly, IKE_AUTH request decryption failures 483 should never happen. Supposing the the tunnels are established 484 using EAP (see Section 2.16 of [RFC7296]), users enter the wrong 485 password about 20% of the time. So we'd expect 125 wrong 486 password failures a minute. If we get IKE_AUTH decryption 487 failures from multiple sources more than once per second, or EAP 488 failure more than 300 times per minute, that can also be an 489 indication of a DDoS attack. 491 2. An attack from a particular IP address or prefix. Such an attack 492 is indicated by an inordinate amount of half-open SAs from that 493 IP address or prefix, or an inordinate amount of IKE_AUTH 494 failures. A DDoS attack may be viewed as multiple such attacks. 495 If they are mitigated well enough, there will not be a need enact 496 countermeasures on all Initiators. Typical measures might be 5 497 concurrent half-open SAs, 1 decrypt failure, or 10 EAP failures 498 within a minute. 500 Note that using counter-measures against an attack from a particular 501 IP address may be enough to avoid the overload on the half-open SA 502 database and in this case the number of failed IKE_AUTH exchanges 503 never exceeds the threshold of attack detection. This is a good 504 thing as it prevents Initiators that are not close to the attackers 505 from being affected. 507 When there is no general DDoS attack, it is suggested that no cookie 508 or puzzles be used. At this point the only defensive measure is the 509 monitoring of the number of half-open SAs, and setting a soft limit 510 per peer IP or prefix. The soft limit can be set to 3-5, and the 511 puzzle difficulty should be set to such a level (number of zero-bits) 512 that all legitimate clients can handle it without degraded user 513 experience. 515 As soon as any kind of attack is detected, either a lot of 516 initiations from multiple sources or a lot of initiations from a few 517 sources, it is best to begin by requiring stateless cookies from all 518 Initiators. This will force the attacker to use real source 519 addresses, and help avoid the need to impose a greater burden in the 520 form of cookies on the general population of Initiators. This makes 521 the per-node or per-prefix soft limit more effective. 523 When cookies are activated for all requests and the attacker is still 524 managing to consume too many resources, the Responder MAY increase 525 the difficulty of puzzles imposed on IKE_SA_INIT requests coming from 526 suspicious nodes/prefixes. It should still be doable by all 527 legitimate peers, but it can degrade experience, for example by 528 taking up to 10 seconds to solve the puzzle. 530 If the load on the Responder is still too great, and there are many 531 nodes causing multiple half-open SAs or IKE_AUTH failures, the 532 Responder MAY impose hard limits on those nodes. 534 If it turns out that the attack is very widespread and the hard caps 535 are not solving the issue, a puzzle MAY be imposed on all Initiators. 536 Note that this is the last step, and the Responder should avoid this 537 if possible. 539 6.1. Session Resumption 541 When the Responder is under attack, it MAY choose to prefer 542 previously authenticated peers who present a Session Resumption 543 ticket (see [RFC5723] for details). The Responder MAY require such 544 Initiators to pass a return routability check by including the COOKIE 545 notification in the IKE_SESSION_RESUME response message, as allowed 546 by Section 4.3.2. of [RFC5723]. Note that the Responder SHOULD cache 547 tickets for a short time to reject reused tickets (Section 4.3.1), 548 and therefore there should be no issue of half-open SAs resulting 549 from replayed IKE_SESSION_RESUME messages. 551 7. Using Puzzles in the Protocol 553 This section describes how the puzzle mechanism is used in IKEv2. It 554 is organized as follows. The Section 7.1 describes using puzzles in 555 the IKE_SA_INIT exchange and the Section 7.2 describes using puzzles 556 in the IKE_AUTH exchange. Both sections are divided into subsections 557 describing how puzzles should be presented, solved and processed by 558 the Initiator and the Responder. 560 7.1. Puzzles in IKE_SA_INIT Exchange 562 IKE Initiator indicates the desire to create a new IKE SA by sending 563 IKE_SA_INIT request message. The message may optionally contain a 564 COOKIE notification if this is a repeated request performed after the 565 Responder's demand to return a cookie. 567 HDR, [N(COOKIE),] SA, KE, Ni, [V+][N+] --> 569 According to the plan, described in Section 6, the IKE Responder 570 should monitor incoming requests to detect whether it is under 571 attack. If the Responder learns that (D)DoS attack is likely to be 572 in progress, then its actions depend on the volume of the attack. If 573 the volume is moderate, then the Responder requests the Initiator to 574 return a cookie. If the volume is so high, that puzzles need to be 575 used for defense, then the Responder requests the Initiator to solve 576 a puzzle. 578 The Responder MAY choose to process some fraction of IKE_SA_INIT 579 requests without presenting a puzzle while being under attack to 580 allow legacy clients, that don't support puzzles, to have a chance to 581 be served. The decision whether to process any particular request 582 must be probabilistic, with the probability depending on the 583 Responder's load (i.e. on the volume of attack). The requests that 584 don't contain the COOKIE notification MUST NOT participate in this 585 lottery. In other words, the Responder must first perform return 586 routability check before allowing any legacy client to be served if 587 it is under attack. See Section 7.1.4 for details. 589 7.1.1. Presenting Puzzle 591 If the Responder makes a decision to use puzzles, then it MUST 592 include two notifications in its response message - the COOKIE 593 notification and the PUZZLE notification. The format of the PUZZLE 594 notification is described in Section 9.1. 596 <-- HDR, N(COOKIE), N(PUZZLE), [V+][N+] 598 The presence of these notifications in an IKE_SA_INIT response 599 message indicates to the Initiator that it should solve the puzzle to 600 get better chances to be served. 602 7.1.1.1. Selecting Puzzle Difficulty Level 604 The PUZZLE notification contains the difficulty level of the puzzle - 605 the minimum number of trailing zero bits that the result of PRF must 606 contain. In diverse environments it is next to impossible for the 607 Responder to set any specific difficulty level that will result in 608 roughly the same amount of work for all Initiators, because 609 computation power of different Initiators may vary by the order of 610 magnitude, or even more. The Responder may set difficulty level to 611 0, meaning that the Initiator is requested to spend as much power to 612 solve puzzle, as it can afford. In this case no specific value of 613 ZBC is required from the Initiator, however the larger the ZBC that 614 Initiator is able to get, the better the chances it will have to be 615 served by the Responder. In diverse environments it is RECOMMENDED 616 that the Initiator sets difficulty level to 0, unless the attack 617 volume is very high. 619 If the Responder sets non-zero difficulty level, then the level 620 should be determined by analyzing the volume of the attack. The 621 Responder MAY set different difficulty levels to different requests 622 depending on the IP address the request has come from. 624 7.1.1.2. Selecting Puzzle Algorithm 626 The PUZZLE notification also contains identifier of the algorithm, 627 that must be used by Initiator to compute puzzle. 629 Cryptographic algorithm agility is considered an important feature 630 for modern protocols ([RFC7696]). This feature ensures that protocol 631 doesn't rely on a single build-in set of cryptographic algorithms, 632 but has a means to replace one set with another and negotiate new set 633 with the peer. IKEv2 fully supports cryptographic algorithm agility 634 for its core operations. 636 To support this feature in case of puzzles, the algorithm that is 637 used to compute puzzle needs to be negotiated during IKE_SA_INIT 638 exchange. The negotiation is performed as follows. The initial 639 request message sent by Initiator contains SA payload with the list 640 of transforms the Initiator supports and is willing to use in the IKE 641 SA being established. The Responder parses received SA payload and 642 finds mutually supported set of transforms of type PRF. It selects 643 most preferred transform from this set and includes it into the 644 PUZZLE notification. There is no requirement that the PRF selected 645 for puzzles be the same, as the PRF that is negotiated later for the 646 use in core IKE SA crypto operations. If there are no mutually 647 supported PRFs, then negotiation will fail anyway and there is no 648 reason to return a puzzle. In this case the Responder returns 649 NO_PROPOSAL_CHOSEN notification. Note that PRF is a mandatory 650 transform type for IKE SA (see Sections 3.3.2 and 3.3.3 of [RFC7296]) 651 and at least one transform of this type must always be present in SA 652 payload in IKE_SA_INIT request message. 654 7.1.1.3. Generating Cookie 656 If Responder supports puzzles then cookie should be computed in such 657 a manner, that the Responder is able to learn some important 658 information from the sole cookie, when it is later returned back by 659 Initiator. In particular - the Responder should be able to learn the 660 following information: 662 o Whether the puzzle was given to the Initiator or only the cookie 663 was requested. 665 o The difficulty level of the puzzle given to the Initiator. 667 o The number of consecutive puzzles given to the Initiator. 669 o The amount of time the Initiator spent to solve the puzzles. This 670 can be calculated if the cookie is timestamped. 672 This information helps the Responder to make a decision whether to 673 serve this request or demand more work from the Initiator. 675 One possible approach to get this information is to encode it in the 676 cookie. The format of such encoding is a local matter of Responder, 677 as the cookie would remain an opaque blob to the Initiator. If this 678 information is encoded in the cookie, then the Responder MUST make it 679 integrity protected, so that any intended or accidental alteration of 680 this information in returned cookie is detectable. So, the cookie 681 would be generated as: 683 Cookie = | | 684 Hash(Ni | IPi | SPIi | | ) 686 Alternatively, the Responder may continue to generate cookie as 687 suggested in Section 2.6 of [RFC7296], but associate the additional 688 information, that would be stored locally, with the particular 689 version of the secret. In this case the Responder should have 690 different secrets for every combination of difficulty level and 691 number of consecutive puzzles, and should change the secrets 692 periodically, keeping a few previous versions, to be able to 693 calculate how long ago the cookie was generated. 695 The Responder may also combine these approaches. This document 696 doesn't mandate how the Responder learns this information from the 697 cookie. 699 7.1.2. Solving Puzzle and Returning the Solution 701 If the Initiator receives a puzzle but it doesn't support puzzles, 702 then it will ignore the PUZZLE notification as an unrecognized status 703 notification (in accordance to Section 3.10.1 of [RFC7296]). The 704 Initiator also MAY ignore the PUZZLE notification if it is not 705 willing to spend resources to solve the puzzle of the requested 706 difficulty, even if it supports puzzles. In both cases the Initiator 707 acts as described in Section 2.6 of [RFC7296] - it restarts the 708 request and includes the received COOKIE notification into it. The 709 Responder should be able to distinguish the situation when it just 710 requested a cookie from the situation when the puzzle was given to 711 the Initiator, but the Initiator for some reason ignored it. 713 If the received message contains a PUZZLE notification and doesn't 714 contain a COOKIE notification, then this message is malformed because 715 it requests to solve the puzzle, but doesn't provide enough 716 information to do it. In this case the Initiator SHOULD resend 717 IKE_SA_INIT request. If this situation repeats several times, then 718 it means that something is wrong and the IKE SA cannot be 719 established. 721 If the Initiator supports puzzles and is ready to deal with them, 722 then it tries to solve the given puzzle. After the puzzle is solved 723 the Initiator restarts the request and returns the puzzle solution in 724 a new payload called a Puzzle Solution payload (denoted as PS, see 725 Section 9.2) along with the received COOKIE notification back to the 726 Responder. 728 HDR, N(COOKIE), [PS,] SA, KE, Ni, [V+][N+] --> 730 7.1.3. Computing Puzzle 732 General principals of constructing puzzles in IKEv2 are described in 733 Section 3. They can be summarized as follows: given unpredictable 734 string S and pseudo-random function PRF find N different keys Ki 735 (where i=[1..N]) for that PRF so that the result of PRF(Ki,S) has at 736 least the specified number of trailing zero bits. This specification 737 requires that the solution to the puzzle contains 4 different keys 738 (i.e. N=4). 740 In the IKE_SA_INIT exchange it is the cookie that plays the role of 741 unpredictable string S. In other words, in IKE_SA_INIT the task for 742 the IKE Initiator is to find the four different, equal-sized keys Ki 743 for the agreed upon PRF such that each result of PRF(Ki,cookie) where 744 i = [1..4] has a sufficient number of trailing zero bits. Only the 745 content of the COOKIE notification is used in puzzle calculation, 746 i.e. the header of the Notification payload is not included. 748 Note, that puzzles in the IKE_AUTH exchange are computed differently 749 than in the IKE_SA_INIT_EXCHANGE. See Section 7.2.3 for details. 751 7.1.4. Analyzing Repeated Request 753 The received request must at least contain a COOKIE notification. 754 Otherwise it is an initial request and it must be processed according 755 to Section 7.1. First, the cookie MUST be checked for validity. If 756 the cookie is invalid, then the request is treated as initial and is 757 processed according to Section 7.1. It is RECOMMENDED that a new 758 cookie is requested in this case. 760 If the cookie is valid then some important information is learned 761 from it or from local state based on identifier of the cookie's 762 secret (see Section 7.1.1.3 for details). This information helps the 763 Responder to sort out incoming requests, giving more priority to 764 those of them, which were created by spending more of the Initiator's 765 resources. 767 First, the Responder determines if it requested only a cookie, or 768 presented a puzzle to the Initiator. If no puzzle was given, then it 769 means that at the time the Responder requested a cookie it didn't 770 detect the (D)DoS attack or the attack volume was low. In this case 771 the received request message must not contain the PS payload, and 772 this payload MUST be ignored if for any reason the message contains 773 it. Since no puzzle was given, the Responder marks the request with 774 the lowest priority since the Initiator spent little resources 775 creating it. 777 If the Responder learns from the cookie that the puzzle was given to 778 the Initiator, then it looks for the PS payload to determine whether 779 its request to solve the puzzle was honored or not. If the incoming 780 message doesn't contain a PS payload, then it means that the 781 Initiator either doesn't support puzzles or doesn't want to deal with 782 them. In either case the request is marked with the lowest priority 783 since the Initiator spent little resources creating it. 785 If a PS payload is found in the message, then the Responder MUST 786 verify the puzzle solution that it contains. The solution is 787 interpreted as four different keys. The result of using each of them 788 in the PRF (as described in Section 7.1.3) must contain at least the 789 requested number of trailing zero bits. The Responder MUST check all 790 the four returned keys. 792 If any checked result contains fewer bits than were requested, it 793 means that the Initiator spent less resources than expected by the 794 Responder. This request is marked with the lowest priority. 796 If the Initiator provided the solution to the puzzle satisfying the 797 requested difficulty level, or if the Responder didn't indicate any 798 particular difficulty level (by setting ZBC to zero) and the 799 Initiator was free to select any difficulty level it can afford, then 800 the priority of the request is calculated based on the following 801 considerations: 803 o The Responder must take the smallest number of trailing zero bits 804 among the checked results and count it as the number of zero bits 805 the Initiator got. 807 o The higher number of zero bits the Initiator got, the higher 808 priority its request should receive. 810 o The more consecutive puzzles the Initiator solved, the higher 811 priority it should receive. 813 o The more time the Initiator spent solving the puzzles, the higher 814 priority it should receive. 816 After the priority of the request is determined the final decision 817 whether to serve it or not is made. 819 7.1.5. Making Decision whether to Serve the Request 821 The Responder decides what to do with the request based on its 822 priority and Responder's current load. There are three possible 823 actions: 825 o Accept request. 827 o Reject request. 829 o Demand more work from Initiator by giving it a new puzzle. 831 The Responder SHOULD accept an incoming request if its priority is 832 high - it means that the Initiator spent quite a lot of resources. 833 The Responder MAY also accept some of low-priority requests where the 834 Initiators don't support puzzles. The percentage of accepted legacy 835 requests depends on the Responder's current load. 837 If the Initiator solved the puzzle, but didn't spend much resources 838 for it (the selected puzzle difficulty level appeared to be low and 839 the Initiator solved it quickly), then the Responder SHOULD give it 840 another puzzle. The more puzzles the Initiator solves the higher its 841 chances are to be served. 843 The details of how the Responder makes a decision for any particular 844 request, are implementation dependent. The Responder can collect all 845 the incoming requests for some short period of time, sort them out 846 based on their priority, calculate the number of available memory 847 slots for half-open IKE SAs and then serve that number of requests 848 from the head of the sorted list. The rest of requests can be either 849 discarded or responded to with new puzzles. 851 Alternatively, the Responder may decide whether to accept every 852 incoming request with some kind of lottery, taking into account its 853 priority and the available resources. 855 7.2. Puzzles in IKE_AUTH Exchange 857 Once the IKE_SA_INIT exchange is completed, the Responder has created 858 a state and is waiting for the first message of the IKE_AUTH exchange 859 from the Initiator. At this point the Initiator has already passed 860 return routability check and has proved that it has performed some 861 work to complete IKE_SA_INIT exchange. However, the Initiator is not 862 yet authenticated and this fact allows malicious Initiator to perform 863 an attack, described in Section 2. Unlike DoS attack in IKE_SA_INIT 864 exchange, which is targeted on the Responder's memory resources, the 865 goal of this attack is to exhaust a Responder's CPU power. The 866 attack is performed by sending the first IKE_AUTH message containing 867 garbage. This costs nothing to the Initiator, but the Responder has 868 to do relatively costly operations of computing the D-H shared secret 869 and deriving SK_* keys to be able to verify authenticity of the 870 message. If the Responder doesn't keep the computed keys after an 871 unsuccessful verification of the IKE_AUTH message, then the attack 872 can be repeated several times on the same IKE SA. 874 The Responder can use puzzles to make this attack more costly for the 875 Initiator. The idea is that the Responder includes a puzzle in the 876 IKE_SA_INIT response message and the Initiator includes a puzzle 877 solution in the first IKE_AUTH request message outside the Encrypted 878 payload, so that the Responder is able to verify puzzle solution 879 before computing D-H shared secret. The difficulty level of the 880 puzzle should be selected so that the Initiator would spend 881 substantially more time to solve the puzzle than the Responder to 882 compute the shared secret. 884 The Responder should constantly monitor the amount of the half-open 885 IKE SA states that receive IKE_AUTH messages that cannot be decrypted 886 due to integrity check failures. If the percentage of such states is 887 high and it takes an essential fraction of Responder's computing 888 power to calculate keys for them, then the Responder may assume that 889 it is under attack and SHOULD use puzzles to make it harder for 890 attackers. 892 7.2.1. Presenting Puzzle 894 The Responder requests the Initiator to solve a puzzle by including 895 the PUZZLE notification in the IKE_SA_INIT response message. The 896 Responder MUST NOT use puzzles in the IKE_AUTH exchange unless the 897 puzzle has been previously presented and solved in the preceding 898 IKE_SA_INIT exchange. 900 <-- HDR, SA, KE, Nr, N(PUZZLE), [V+][N+] 902 7.2.1.1. Selecting Puzzle Difficulty Level 904 The difficulty level of the puzzle in IKE_AUTH exchange should be 905 chosen so that the Initiator would spend more time to solve the 906 puzzle than the Responder to compute the D-H shared secret and the 907 keys, needed to decrypt and verify the IKE_AUTH request message. On 908 the other hand, the difficulty level should not be too high, 909 otherwise the legitimate clients would experience an additional delay 910 while establishing IKE SA. 912 Note, that since puzzles in the IKE_AUTH exchange are only allowed to 913 be used if they were used in the preceding IKE_SA_INIT exchange, the 914 Responder would be able to estimate the computational power of the 915 Initiator and to select the difficulty level accordingly. Unlike 916 puzzles in IKE_SA_INIT, the requested difficulty level for IKE_AUTH 917 puzzles MUST NOT be zero. In other words, the Responder must always 918 set specific difficulty level and must not let the Initiator to 919 choose it on its own. 921 7.2.1.2. Selecting Puzzle Algorithm 923 The algorithm for the puzzle is selected as described in 924 Section 7.1.1.2. There is no requirement, that the algorithm for the 925 puzzle in the IKE_SA INIT exchange be the same, as the algorithm for 926 the puzzle in IKE_AUTH exchange, however it is expected that in most 927 cases they will be the same. 929 7.2.2. Solving Puzzle and Returning the Solution 931 If the IKE_SA_INIT response message contains the PUZZLE notification 932 and the Initiator supports puzzles, it MUST solve the puzzle. Note, 933 that puzzle construction in the IKE_AUTH exchange differs from the 934 puzzle construction in the IKE_SA_INIT exchange and is described in 935 Section 7.2.3. Once the puzzle is solved the Initiator sends the 936 IKE_AUTH request message, containing the Puzzle Solution payload. 938 HDR, PS, SK {IDi, [CERT,] [CERTREQ,] 939 [IDr,] AUTH, SA, TSi, TSr} --> 941 The Puzzle Solution payload MUST be placed outside the Encrypted 942 payload, so that the Responder would be able to verify the puzzle 943 before calculating the D-H shared secret and the SK_* keys. 945 If IKE Fragmentation [RFC7383] is used in IKE_AUTH exchange, then the 946 PS payload MUST be present only in the first IKE Fragment message, in 947 accordance with the Section 2.5.3 of [RFC7383]. Note, that 948 calculation of the puzzle in the IKE_AUTH exchange doesn't depend on 949 the content of the IKE_AUTH message (see Section 7.2.3). Thus the 950 Initiator has to solve the puzzle only once and the solution is valid 951 for both unfragmented and fragmented IKE messages. 953 7.2.3. Computing Puzzle 955 The puzzles in the IKE_AUTH exchange are computed differently than in 956 the IKE_SA_INIT exchange (see Section 7.1.3). The general principle 957 is the same; the difference is in the construction of the string S. 958 Unlike the IKE_SA_INIT exchange, where S is the cookie, in the 959 IKE_AUTH exchange S is a concatenation of Nr and SPIr. In other 960 words, the task for IKE Initiator is to find the four different keys 961 Ki for the agreed upon PRF such that each result of PRF(Ki,Nr | SPIr) 962 where i=[1..4] has a sufficient number of trailing zero bits. Nr is 963 a nonce used by the Responder in IKE_SA_INIT exchange, stripped of 964 any headers. SPIr is IKE Responder's SPI from the IKE header of the 965 SA being established. 967 7.2.4. Receiving Puzzle Solution 969 If the Responder requested the Initiator to solve a puzzle in the 970 IKE_AUTH exchange, then it MUST silently discard all the IKE_AUTH 971 request messages without the Puzzle Solution payload. 973 Once the message containing a solution to the puzzle is received, the 974 Responder MUST verify the solution before performing computationlly 975 intensive operations i.e. computing the D-H shared secret and the 976 SK_* keys. The Responder MUST verify all the four returned keys. 978 The Responder MUST silently discard the received message if any 979 checked verification result is not correct (contains insufficient 980 number of trailing zero bits). If the Responder successfully 981 verifies the puzzle and calculates the SK_* key, but the message 982 authenticity check fails, then it SHOULD save the calculated keys in 983 the IKE SA state while waiting for the retransmissions from the 984 Initiator. In this case the Responder may skip verification of the 985 puzzle solution and ignore the Puzzle Solution payload in the 986 retransmitted messages. 988 If the Initiator uses IKE Fragmentation, then it is possible, that 989 due to packet loss and/or reordering the Responder could receive non- 990 first IKE Fragment messages before receiving the first one, 991 containing the PS payload. In this case the Responder MAY choose to 992 keep the received fragments until the first fragment containing the 993 solution to the puzzle is received. However, in this case the 994 Responder SHOULD NOT try to verify authenticity of the kept fragments 995 until the first fragment with the PS payload is received and the 996 solution to the puzzle is verified. After successful verification of 997 the puzzle the Responder could calculate the SK_* key and verify 998 authenticity of the collected fragments. 1000 8. DoS Protection after IKE SA is created 1002 Once IKE SA is created there is usually not much traffic over it. In 1003 most cases this traffic consists of exchanges aimed to create 1004 additional Child SAs, rekey, or delete them and check the liveness of 1005 the peer. With a typical setup and typical Child SA lifetimes, there 1006 are typically no more than a few such exchanges, often less. Some of 1007 these exchanges require relatively little resources (like liveness 1008 check), while others may be resource consuming (like creating or 1009 rekeying Child SA with D-H exchange). 1011 Since any endpoint can initiate a new exchange, there is a 1012 possibility that a peer would initiate too many exchanges that could 1013 exhaust host resources. For example, the peer can perform endless 1014 continuous Child SA rekeying or create overwhelming number of Child 1015 SAs with the same Traffic Selectors etc. Such behavior may be caused 1016 by buggy implementation, misconfiguration or be intentional. The 1017 latter becomes more of a real threat if the peer uses NULL 1018 Authentication, described in [RFC7619]. In this case the peer 1019 remains anonymous, allowing it to escape any responsibility for its 1020 actions. 1022 The following recommendations for defense against possible DoS 1023 attacks after IKE SA is established are mostly intended for 1024 implementations that allow unauthenticated IKE sessions; however, 1025 they may also be useful in other cases. 1027 o If the IKEv2 window size is greater than one, then the peer could 1028 initiate multiple simultaneous exchanges that could increase host 1029 resource consumption. Since currently there is no way in IKEv2 to 1030 decrease window size once it was increased (see Section 2.3 of 1031 [RFC7296]), the window size cannot be dynamically adjusted 1032 depending on the load. For that reason, it is NOT RECOMMENDED to 1033 ever increase the IKEv2 window size above its default value of one 1034 if the peer uses NULL Authentication. 1036 o If the peer initiates requests to rekey IKE SA or Child SA too 1037 often, implementations can respond to some of these requests with 1038 the TEMPORARY_FAILURE notification, indicating that the request 1039 should be retried after some period of time. 1041 o If the peer creates too many Child SA with the same or overlapping 1042 Traffic Selectors, implementations can respond with the 1043 NO_ADDITIONAL_SAS notification. 1045 o If the peer initiates too many exchanges of any kind, 1046 implementations can introduce an artificial delay before 1047 responding to request messages. This delay would decrease the 1048 rate the implementation need to process requests from any 1049 particular peer, making it possible to process requests from the 1050 others. The delay should not be too long to avoid causing the IKE 1051 SA to be deleted on the other end due to timeout. It is believed 1052 that a few seconds is enough. Note, that if the Responder 1053 receives retransmissions of the request message during the delay 1054 period, the retransmitted messages should be silently discarded. 1056 o If these counter-measures are inefficient, implementations can 1057 delete the IKE SA with an offending peer by sending Delete 1058 Payload. 1060 9. Payload Formats 1062 9.1. PUZZLE Notification 1064 The PUZZLE notification is used by the IKE Responder to inform the 1065 Initiator about the necessity to solve the puzzle. It contains the 1066 difficulty level of the puzzle and the PRF the Initiator should use. 1068 1 2 3 1069 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 1070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1071 | Next Payload |C| RESERVED | Payload Length | 1072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1073 |Protocol ID(=0)| SPI Size (=0) | Notify Message Type | 1074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1075 | PRF | Difficulty | 1076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1078 o Protocol ID (1 octet) -- MUST be 0. 1080 o SPI Size (1 octet) - MUST be 0, meaning no Security Parameter 1081 Index (SPI) is present. 1083 o Notify Message Type (2 octets) -- MUST be , the value 1084 assigned for the PUZZLE notification. 1086 o PRF (2 octets) -- Transform ID of the PRF algorithm that must be 1087 used to solve the puzzle. Readers should refer to the section 1088 "Transform Type 2 - Pseudo-Random Function Transform IDs" in 1089 [IKEV2-IANA] for the list of possible values. 1091 o Difficulty (1 octet) -- Difficulty Level of the puzzle. Specifies 1092 minimum number of trailing zero bits (ZBC), that each of the 1093 results of PRF must contain. Value 0 means that the Responder 1094 doesn't request any specific difficulty level and the Initiator is 1095 free to select appropriate difficulty level on its own (see 1096 Section 7.1.1.1 for details). 1098 This notification contains no data. 1100 9.2. Puzzle Solution Payload 1102 The solution to the puzzle is returned back to the Responder in a 1103 dedicated payload, called the Puzzle Solution payload and denoted as 1104 PS in this document. 1106 1 2 3 1107 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 1108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1109 | Next Payload |C| RESERVED | Payload Length | 1110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1111 | | 1112 ~ Puzzle Solution Data ~ 1113 | | 1114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1116 o Puzzle Solution Data (variable length) -- Contains the solution to 1117 the puzzle - four different keys for the selected PRF. This field 1118 MUST NOT be empty. All the keys MUST have the same size, 1119 therefore the size of this field is always a mutiple of 4 bytes. 1120 If the selected PRF accepts only fixed-size keys, then the size of 1121 each key MUST be of that fixed size. If the PRF agreed upon 1122 accepts keys of any size, then then the size of each key MUST be 1123 between 1 octet and the preferred key length of the PRF 1124 (inclusive). It is expected that in most cases the keys will be 4 1125 (or even less) octets in length, however it depends on puzzle 1126 difficulty and on the Initiator's strategy to find solutions, and 1127 thus the size is not mandated by this specification. The 1128 Responder determines the size of each key by dividing the size of 1129 the Puzzle Solution Data by 4 (the number of keys). Note that the 1130 size of Puzzle Solution Data is the size of Payload (as indicated 1131 in Payload Length field) minus 4 - the size of Payload Header. 1133 The payload type for the Puzzle Solution payload is . 1135 10. Operational Considerations 1137 The difficulty level should be set by balancing the requirement to 1138 minimize the latency for legitimate Initiators and making things 1139 difficult for attackers. A good rule of thumb is for taking about 1 1140 second to solve the puzzle. A typical Initiator or bot-net member in 1141 2014 can perform slightly less than a million hashes per second per 1142 core, so setting the difficulty level to n=20 is a good compromise. 1143 It should be noted that mobile Initiators, especially phones are 1144 considerably weaker than that. Implementations should allow 1145 administrators to set the difficulty level, and/or be able to set the 1146 difficulty level dynamically in response to load. 1148 Initiators should set a maximum difficulty level beyond which they 1149 won't try to solve the puzzle and log or display a failure message to 1150 the administrator or user. 1152 11. Security Considerations 1154 When selecting parameters for the puzzles, in particular the puzzle 1155 difficulty, care must be taken. If the puzzles appeared too easy for 1156 majority of the attackers, then the puzzles mechanism wouldn't be 1157 able to prevent DoS attack and would only impose an additional burden 1158 on the legitimate Initiators. On the other hand, if the puzzles 1159 appeared to be too hard for majority of the Initiators then many 1160 legitimate users would experience unacceptable delay in IKE SA setup 1161 (or unacceptable power consumption on mobile devices), that might 1162 cause them to cancel connection attempt. In this case the resources 1163 of the Responder are preserved, however the DoS attack can be 1164 considered successful. Thus a sensible balance should be kept by the 1165 Responder while choosing the puzzle difficulty - to defend itself and 1166 to not over-defend itself. It is RECOMMENDED that the puzzle 1167 difficulty be chosen so, that the Responder's load remain close to 1168 the maximum it can tolerate. It is also RECOMMENDED to dynamically 1169 adjust the puzzle difficulty in accordance to the current Responder's 1170 load. 1172 Solving puzzles requires a lot of CPU power, that would increase 1173 power consumption. This would influence battery-powered Initiators, 1174 e.g. mobile phones or some IoT devices. If puzzles are hard then the 1175 required additional power consumption may appear to be unacceptable 1176 for some Initiators. The Responder SHOULD take this possibility into 1177 considerations while choosing the puzzles difficulty and while 1178 selecting which percentage of Initiators are allowed to reject 1179 solving puzzles. See Section 7.1.4 for details. 1181 If the Initiator uses NULL Authentication [RFC7619] then its identity 1182 is never verified, that may be used by attackers to perform DoS 1183 attack after IKE SA is established. Responders that allow 1184 unauthenticated Initiators to connect must be prepared deal with 1185 various kinds of DoS attacks even after IKE SA is created. See 1186 Section 8 for details. 1188 12. IANA Considerations 1190 This document defines a new payload in the "IKEv2 Payload Types" 1191 registry: 1193 Puzzle Solution PS 1195 This document also defines a new Notify Message Type in the "IKEv2 1196 Notify Message Types - Status Types" registry: 1198 PUZZLE 1200 13. Acknowledgements 1202 The authors thank Tero Kivinen, Yaron Sheffer and Scott Fluhrer for 1203 their contribution into design of the protocol. In particular, Tero 1204 Kivinen suggested the kind of puzzle where the task is to find a 1205 solution with requested number of zero trailing bits. Yaron Sheffer 1206 and Scott Fluhrer suggested a way to make puzzle difficulty less 1207 erratic by solving several weaker puzles. The authors also thank 1208 David Waltermire for his carefull review of the draft and all others 1209 who commented the document. 1211 14. References 1213 14.1. Normative References 1215 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1216 Requirement Levels", BCP 14, RFC 2119, 1217 DOI 10.17487/RFC2119, March 1997, 1218 . 1220 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 1221 Kivinen, "Internet Key Exchange Protocol Version 2 1222 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 1223 2014, . 1225 [RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2 1226 (IKEv2) Message Fragmentation", RFC 7383, 1227 DOI 10.17487/RFC7383, November 2014, 1228 . 1230 [IKEV2-IANA] 1231 "Internet Key Exchange Version 2 (IKEv2) Parameters", 1232 . 1234 14.2. Informative References 1236 [bitcoins] 1237 Nakamoto, S., "Bitcoin: A Peer-to-Peer Electronic Cash 1238 System", October 2008, . 1240 [RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange 1241 Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, 1242 DOI 10.17487/RFC5723, January 2010, 1243 . 1245 [RFC7619] Smyslov, V. and P. Wouters, "The NULL Authentication 1246 Method in the Internet Key Exchange Protocol Version 2 1247 (IKEv2)", RFC 7619, DOI 10.17487/RFC7619, August 2015, 1248 . 1250 [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm 1251 Agility and Selecting Mandatory-to-Implement Algorithms", 1252 BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, 1253 . 1255 Authors' Addresses 1257 Yoav Nir 1258 Check Point Software Technologies Ltd. 1259 5 Hasolelim st. 1260 Tel Aviv 6789735 1261 Israel 1263 EMail: ynir.ietf@gmail.com 1265 Valery Smyslov 1266 ELVIS-PLUS 1267 PO Box 81 1268 Moscow (Zelenograd) 124460 1269 Russian Federation 1271 Phone: +7 495 276 0211 1272 EMail: svan@elvis.ru