idnits 2.17.1 draft-ietf-ipsecme-ddos-protection-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document 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 (December 16, 2015) is 3053 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: June 18, 2016 ELVIS-PLUS 6 December 16, 2015 8 Protecting Internet Key Exchange (IKE) Implementations from Distributed 9 Denial of Service Attacks 10 draft-ietf-ipsecme-ddos-protection-03 12 Abstract 14 This document recommends implementation and configuration best 15 practices for Internet-connected IPsec Responders, to allow them to 16 resist Denial of Service and Distributed Denial of Service attacks. 17 Additionally, the document introduces a new mechanism called "Client 18 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 June 18, 2016. 37 Copyright Notice 39 Copyright (c) 2015 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 . . . . 17 70 7.2. Puzzles in IKE_AUTH Exchange . . . . . . . . . . . . . . 18 71 7.2.1. Presenting Puzzle . . . . . . . . . . . . . . . . . . 19 72 7.2.2. Solving Puzzle and Returning the Solution . . . . . . 20 73 7.2.3. Computing Puzzle . . . . . . . . . . . . . . . . . . 20 74 7.2.4. Receiving Puzzle Solution . . . . . . . . . . . . . . 21 75 8. DoS Protection after IKE SA is created . . . . . . . . . . . 21 76 9. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 22 77 9.1. PUZZLE Notification . . . . . . . . . . . . . . . . . . . 23 78 9.2. Puzzle Solution Payload . . . . . . . . . . . . . . . . . 23 79 10. Operational Considerations . . . . . . . . . . . . . . . . . 24 80 11. Security Considerations . . . . . . . . . . . . . . . . . . . 24 81 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 82 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 83 13.1. Normative References . . . . . . . . . . . . . . . . . . 25 84 13.2. Informative References . . . . . . . . . . . . . . . . . 26 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 87 1. Introduction 89 Denial of Service (DoS) attacks have always been considered a serious 90 threat. These attacks are usually difficult to defend against since 91 the amount of resources the victim has is always bounded (regardless 92 of how high it is) and because some resources are required for 93 distinguishing a legitimate session from an attack. 95 The Internet Key Exchange protocol (IKE) described in [RFC7296] 96 includes defense against DoS attacks. In particular, there is a 97 cookie mechanism that allows the IKE Responder to effectively defend 98 itself against DoS attacks from spoofed IP-addresses. However, bot- 99 nets have become widespread, allowing attackers to perform 100 Distributed Denial of Service (DDoS) attacks, which are more 101 difficult to defend against. This document presents recommendations 102 to help the Responder thwart (D)DoS attacks. It also introduces a 103 new mechanism -- "puzzles" -- that can help accomplish this task. 105 The IKE_SA_INIT Exchange described in Section 1.2 of [RFC7296] 106 involves the Initiator sending a single message. The Responder 107 replies with a single message and also allocates memory for a 108 structure called a half-open IKE Security Association (SA). This 109 half-open SA is later authenticated in the IKE_AUTH Exchange. If 110 that IKE_AUTH request never comes, the half-open SA is kept for an 111 unspecified amount of time. Depending on the algorithms used and 112 implementation, such a half-open SA will use from around 100 bytes to 113 several thousands bytes of memory. 115 This creates an easy attack vector against an IKE Responder. 116 Generating the IKE_SA_INIT request is cheap, and sending multiple 117 such requests can either cause the Responder to allocate too much 118 resources and fail, or else if resource allocation is somehow 119 throttled, legitimate Initiators would also be prevented from setting 120 up IKE SAs. 122 An obvious defense, which is described in Section 5, is limiting the 123 number of half-open SAs opened by a single peer. However, since all 124 that is required is a single packet, an attacker can use multiple 125 spoofed source IP addresses. 127 1.1. The Stateless Cookie 129 Section 2.6 of [RFC7296] offers a mechanism to mitigate this DoS 130 attack: the stateless cookie. When the server is under load, the 131 Responder responds to the IKE_SA_INIT request with a calculated 132 "stateless cookie" - a value that can be re-calculated based on 133 values in the IKE_SA_INIT request without storing Responder-side 134 state. The Initiator is expected to repeat the IKE_SA_INIT request, 135 this time including the stateless cookie. 137 Attackers that have multiple source IP addresses with return 138 routability, such as in the case of bot-nets, can fill up a half-open 139 SA table anyway. The cookie mechanism limits the amount of allocated 140 state to the size of the bot-net, multiplied by the number of half- 141 open SAs allowed per peer address, multiplied by the amount of state 142 allocated for each half-open SA. With typical values this can easily 143 reach hundreds of megabytes. 145 The mechanism described in Section 3 adds a proof of work for the 146 Initiator by calculating a pre-image for a partial hash value. This 147 sets an upper bound, determined by the attacker's CPU, to the number 148 of negotiations it can initiate in a unit of time. 150 1.2. Conventions Used in This Document 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in [RFC2119]. 156 2. The Vulnerability 158 If we break down what a Responder has to do during an initial 159 exchange, there are three stages: 161 1. When the IKE_SA_INIT request arrives, the Responder: 163 * Generates or re-uses a Diffie-Hellman (D-H) private part. 165 * Generates a Responder Security Parameter Index (SPI). 167 * Stores the private part and peer public part in a half-open SA 168 database. 170 2. When the IKE_AUTH request arrives, the Responder: 172 * Derives the keys from the half-open SA. 174 * Decrypts the request. 176 3. If the IKE_AUTH request decrypts properly: 178 * Validates the certificate chain (if present) in the IKE_AUTH 179 request. 181 Yes, there's a stage 4 where the Responder actually creates Child 182 SAs, but when talking about (D)DoS, we never get to this stage. 184 Stage #1 is pretty light on CPU power, but requires some storage, and 185 it's very light for the Initiator as well. Stage #2 includes 186 private-key operations, so it's much heavier CPU-wise. Stage #3 187 includes public key operations, typically more than one. 189 To attack such a Responder, an attacker can attempt to either exhaust 190 memory or to exhaust CPU. Without any protection, the most efficient 191 attack is to send multiple IKE_SA_INIT requests and exhaust memory. 192 This should be easy because those requests are cheap. 194 There are obvious ways for the Responder to protect itself even 195 without changes to the protocol. It can reduce the time that an 196 entry remains in the half-open SA database, and it can limit the 197 amount of concurrent half-open SAs from a particular address or 198 prefix. The attacker can overcome this by using spoofed source 199 addresses. 201 The stateless cookie mechanism from Section 2.6 of [RFC7296] prevents 202 an attack with spoofed source addresses. This doesn't completely 203 solve the issue, but it makes the limiting of half-open SAs by 204 address or prefix work. Puzzles do the same thing only more of it. 205 They make it harder for an attacker to reach the goal of getting a 206 half-open SA. They don't have to be so hard that an attacker can't 207 afford to solve a single puzzle; it's enough that they increase the 208 cost of a half-open SAs for the attacker so that it can create only a 209 few. 211 Reducing the amount of time an abandoned half-open SA is kept attacks 212 the issue from the other side. It reduces the value the attacker 213 gets from managing to create a half-open SA. For example, if a half- 214 open SA is kept for 1 minute and the capacity is 60,000 half-open 215 SAs, an attacker would need to create 1,000 half-open SAs per second. 216 Reduce the retention time to 3 seconds, and the attacker needs to 217 create 20,000 half-open SAs per second. By introducing a puzzle, 218 each half-open SA becomes more expensive for an attacker, making it 219 more likely to thwart an exhaustion attack against Responder memory. 221 At this point, filling up the half-open SA database is no longer the 222 most efficient DoS attack. The attacker has two ways to do better: 224 1. Go back to spoofed addresses and try to overwhelm the CPU that 225 deals with generating cookies, or 227 2. Take the attack to the next level by also sending an IKE_AUTH 228 request. 230 It seems that the first thing cannot be dealt with at the IKE level. 231 It's probably better left to Intrusion Prevention System (IPS) 232 technology. 234 On the other hand, sending an IKE_AUTH request is surprisingly cheap. 235 It requires a proper IKE header with the correct IKE SPIs, and it 236 requires a single Encrypted payload. The content of the payload 237 might as well be junk. The Responder has to perform the relatively 238 expensive key derivation, only to find that the MAC on the Encrypted 239 payload on the IKE_AUTH request does not check. Depending on the 240 Responder implementation, this can be repeated with the same half- 241 open SA (if the Responder does not delete the half-open SA following 242 an unsuccessful decryption - see discussion in Section 4). 244 Here too, the number of half-open SAs that the attacker can achieve 245 is crucial, because each one allows the attacker to waste some CPU 246 time. So making it hard to make many half-open SAs is important. 248 A strategy against DDoS has to rely on at least 4 components: 250 1. Hardening the half-open SA database by reducing retention time. 252 2. Hardening the half-open SA database by rate-limiting single IPs/ 253 prefixes. 255 3. Guidance on what to do when an IKE_AUTH request fails to decrypt. 257 4. Increasing cost of half-open SA up to what is tolerable for 258 legitimate clients. 260 Puzzles have their place as part of #4. 262 3. Puzzles 264 The puzzle introduced here extends the cookie mechanism from 265 [RFC7296]. It is loosely based on the proof-of-work technique used 266 in Bitcoins [bitcoins]. 268 A puzzle is sent to the Initiator in two cases: 270 o The Responder is so overloaded, then no half-open SAs are allowed 271 to be created without the puzzle, or 273 o The Responder is not too loaded, but the rate-limiting method 274 described in Section 5 prevents half-open SAs from being created 275 with this particular peer address or prefix without first solving 276 a puzzle. 278 When the Responder decides to send the challenge notification in 279 response to a IKE_SA_INIT request, the notification includes three 280 fields: 282 1. Cookie - this is calculated the same as in [RFC7296], i.e. the 283 process of generating the cookie is not specified. 285 2. Algorithm, this is the identifier of a Pseudo-Random Function 286 (PRF) algorithm, one of those proposed by the Initiator in the SA 287 payload. 289 3. Zero Bit Count (ZBC). This is a number between 8 and 255 (or a 290 special value - 0, see Section 7.1.1.1) that represents the 291 length of the zero-bit run at the end of the output of the PRF 292 function calculated over the cookie that the Initiator is to 293 send. The values 1-8 are explicitly excluded, because they 294 create a puzzle that is too easy to solve for it to make any 295 difference in mitigating DDoS attacks. Since the mechanism is 296 supposed to be stateless for the Responder, either the same ZBC 297 is used for all Initiators, or the ZBC is somehow encoded in the 298 cookie. If it is global then it means that this value is the 299 same for all the Initiators who are receiving puzzles at any 300 given point of time. The Responder, however, may change this 301 value over time depending on its load. 303 Upon receiving this challenge, the Initiator attempts to calculate 304 the PRF using different keys. When a key is found such that the 305 resulting PRF output has a sufficient number of trailing zero bits, 306 that result is sent to the Responder. 308 When receiving a request with a solved puzzle, the Responder verifies 309 two things: 311 o That the cookie part is indeed valid. 313 o That the PRF of the transmitted cookie calculated with the 314 transmitted key has a sufficient number of trailing zero bits. 316 Example 1: Suppose the calculated cookie is 317 fdbcfa5a430d7201282358a2a034de0013cfe2ae (20 octets), the algorithm 318 is HMAC-SHA256, and the required number of zero bits is 18. After 319 successively trying a bunch of keys, the Initiator finds that the key 320 that is all-zero except for the last three bytes which are 02fc95 321 yields HMAC_SHA256(k, cookie) = 322 843ab73f35c5b431b1d8f80bedcd1cb9ef46832f799c1d4250a49f683c580000, 323 which has 19 trailing zero bits, so it is an acceptable solution. 325 Example 2: Same cookie, but this time the required number of zero 326 bits is 22. The first key to satisfy that requirement ends in 327 960cbb, which yields a hash with 23 trailing zero bits. Finding this 328 requires 9,833,659 invocations of the PRF. 330 +----------+--------------------------+--------+--------------------+ 331 | Key | Last 24 Hex PRF Digits | # | Time to Calculate | 332 | | | 0-bits | (seconds) | 333 +----------+--------------------------+--------+--------------------+ 334 | 00 | 0cbbbd1e105f5a177f9697d4 | 2 | 0.000 | 335 | 08 | 34cdedf89560f600aab93c68 | 3 | 0.000 | 336 | 0b | 6153a5131b879a904cd7fbe0 | 5 | 0.000 | 337 | 2b | 0098af3e9422aa40a6f7b140 | 6 | 0.000 | 338 | 0147 | c8bf4a65fc8b974046b97c00 | 10 | 0.001 | 339 | 06e2 | 541487a10cbdf3b21c382800 | 11 | 0.005 | 340 | 0828 | 48719bd62393fcf9bc172000 | 13 | 0.006 | 341 | 0204a7 | 3dce3414477c2364d5198000 | 15 | 0.186 | 342 | 185297 | c19385bb7b9566e5fdf00000 | 20 | 2.146 | 343 | 69dc34 | 1b61ecb347cb2e0cba200000 | 21 | 9.416 | 344 | 960cbb | e48274bfac2b7e1930800000 | 23 | 13.300 | 345 | 01597972 | 39a0141d0fe4b87aea000000 | 25 | 30.749 | 346 | 0b13cd9a | 00b97bb323d6d33350000000 | 28 | 247.914 | 347 | 37dc96e4 | 1e24babc92234aa3a0000000 | 29 | 1237.170 | 348 | 7a1a56d8 | c98f0061e380a49e00000000 | 33 | 2726.150 | 349 +----------+--------------------------+--------+--------------------+ 351 Table 1: The time needed to solve a puzzle of various difficulty for 352 the cookie = fdbcfa5a430d7201282358a2a034de0013cfe2ae 354 The figures above were obtained on a 2.4 GHz single core i5. Run 355 times can be halved or quartered with multi-core code, but would be 356 longer on mobile phone processors, even if those are multi-core as 357 well. With these figures 20 bits is believed to be a reasonable 358 choice for puzzle level difficulty for all Initiators, with 24 bits 359 acceptable for specific hosts/prefixes. 361 4. Retention Periods for Half-Open SAs 363 As a UDP-based protocol, IKEv2 has to deal with packet loss through 364 retransmissions. Section 2.4 of [RFC7296] recommends "that messages 365 be retransmitted at least a dozen times over a period of at least 366 several minutes before giving up". Retransmission policies in 367 practice wait at least one or two seconds before retransmitting for 368 the first time. 370 Because of this, setting the timeout on a half-open SA too low will 371 cause it to expire whenever even one IKE_AUTH request packet is lost. 372 When not under attack, the half-open SA timeout SHOULD be set high 373 enough that the Initiator will have enough time to send multiple 374 retransmissions, minimizing the chance of transient network 375 congestion causing IKE failure. 377 When the system is under attack, as measured by the amount of half- 378 open SAs, it makes sense to reduce this lifetime. The Responder 379 should still allow enough time for the round-trip, enough time for 380 the Initiator to derive the D-H shared value, and enough time to 381 derive the IKE SA keys and the create the IKE_AUTH request. Two 382 seconds is probably as low a value as can realistically be used. 384 It could make sense to assign a shorter value to half-open SAs 385 originating from IP addresses or prefixes that are considered suspect 386 because of multiple concurrent half-open SAs. 388 5. Rate Limiting 390 Even with DDoS, the attacker has only a limited amount of nodes 391 participating in the attack. By limiting the amount of half-open SAs 392 that are allowed to exist concurrently with each such node, the total 393 amount of half-open SAs is capped, as is the total amount of key 394 derivations that the Responder is forced to complete. 396 In IPv4 it makes sense to limit the number of half-open SAs based on 397 IP address. Most IPv4 nodes are either directly attached to the 398 Internet using a routable address or are hidden behind a NAT device 399 with a single IPv4 external address. IPv6 networks are currently a 400 rarity, so we can only speculate on what their wide deployment will 401 be like, but the current thinking is that ISP customers will be 402 assigned whole subnets, so we don't expect the kind of NAT deployment 403 that is common in IPv4. For this reason, it makes sense to use a 404 64-bit prefix as the basis for rate limiting in IPv6. 406 The number of half-open SAs is easy to measure, but it is also 407 worthwhile to measure the number of failed IKE_AUTH exchanges. If 408 possible, both factors should be taken into account when deciding 409 which IP address or prefix is considered suspicious. 411 There are two ways to rate-limit a peer address or prefix: 413 1. Hard Limit - where the number of half-open SAs is capped, and any 414 further IKE_SA_INIT requests are rejected. 416 2. Soft Limit - where if a set number of half-open SAs exist for a 417 particular address or prefix, any IKE_SA_INIT request will 418 require solving a puzzle. 420 The advantage of the hard limit method is that it provides a hard cap 421 on the amount of half-open SAs that the attacker is able to create. 422 The downside is that it allows the attacker to block IKE initiation 423 from small parts of the Internet. For example, if a certain purveyor 424 of beverages resembling coffee provides Internet connectivity to its 425 customers through an IPv4 NAT device, a single malicious customer can 426 create enough half-open SAs to fill the quota for the NAT device 427 external IP address. Legitimate Initiators on the same network will 428 not be able to initiate IKE. 430 The advantage of a soft limit is that legitimate clients can always 431 connect. The disadvantage is that an adversary with sufficient CPU 432 resources can still effectively DoS the Responder. 434 Regardless of the type of rate-limiting used, there is a huge 435 advantage in blocking the DoS attack using rate-limiting in that 436 legitimate clients who are away from the attacking nodes should not 437 be adversely affected by either the attack or by the measures used to 438 counteract it. 440 6. Plan for Defending a Responder 442 This section outlines a plan for defending a Responder from a DDoS 443 attack based on the techniques described earlier. The numbers given 444 here are not normative, and their purpose is to illustrate the 445 configurable parameters needed for defeating the DDoS attack. 447 Implementations may be deployed in different environments, so it is 448 RECOMMENDED that the parameters be settable. As an example, most 449 commercial products are required to undergo benchmarking where the 450 IKE SA establishment rate is measured. Benchmarking is 451 indistinguishable from a DoS attack and the defenses described in 452 this document may defeat the benchmark by causing exchanges to fail 453 or take a long time to complete. Parameters should be tunable to 454 allow for benchmarking (if only by turning DDoS protection off). 456 Since all countermeasures may cause delays and work on the 457 Initiators, they SHOULD NOT be deployed unless an attack is likely to 458 be in progress. To minimize the burden imposed on Initiators, the 459 Responder should monitor incoming IKE requests, searching for two 460 things: 462 1. A general DDoS attack. Such an attack is indicated by a high 463 number of concurrent half-open SAs, a high rate of failed 464 IKE_AUTH exchanges, or a combination of both. For example, 465 consider a Responder that has 10,000 distinct peers of which at 466 peak 7,500 concurrently have VPN tunnels. At the start of peak 467 time, 600 peers might establish tunnels at any given minute, and 468 tunnel establishment (both IKE_SA_INIT and IKE_AUTH) takes 469 anywhere from 0.5 to 2 seconds. For this Responder, we expect 470 there to be less than 20 concurrent half-open SAs, so having 100 471 concurrent half-open SAs can be interpreted as an indication of 472 an attack. Similarly, IKE_AUTH request decryption failures 473 should never happen. Supposing the the tunnels are established 474 using EAP (see Section 2.16 of [RFC7296]), users enter the wrong 475 password about 20% of the time. So we'd expect 125 wrong 476 password failures a minute. If we get IKE_AUTH decryption 477 failures from multiple sources more than once per second, or EAP 478 failure more than 300 times per minute, that can also be an 479 indication of a DDoS attack. 481 2. An attack from a particular IP address or prefix. Such an attack 482 is indicated by an inordinate amount of half-open SAs from that 483 IP address or prefix, or an inordinate amount of IKE_AUTH 484 failures. A DDoS attack may be viewed as multiple such attacks. 485 If they are mitigated well enough, there will not be a need enact 486 countermeasures on all Initiators. Typical measures might be 5 487 concurrent half-open SAs, 1 decrypt failure, or 10 EAP failures 488 within a minute. 490 Note that using counter-measures against an attack from a particular 491 IP address may be enough to avoid the overload on the half-open SA 492 database and in this case the number of failed IKE_AUTH exchanges 493 never exceeds the threshold of attack detection. This is a good 494 thing as it prevents Initiators that are not close to the attackers 495 from being affected. 497 When there is no general DDoS attack, it is suggested that no cookie 498 or puzzles be used. At this point the only defensive measure is the 499 monitoring of the number of half-open SAs, and setting a soft limit 500 per peer IP or prefix. The soft limit can be set to 3-5, and the 501 puzzle difficulty should be set to such a level (number of zero-bits) 502 that all legitimate clients can handle it without degraded user 503 experience. 505 As soon as any kind of attack is detected, either a lot of 506 initiations from multiple sources or a lot of initiations from a few 507 sources, it is best to begin by requiring stateless cookies from all 508 Initiators. This will force the attacker to use real source 509 addresses, and help avoid the need to impose a greater burden in the 510 form of cookies on the general population of Initiators. This makes 511 the per-node or per-prefix soft limit more effective. 513 When cookies are activated for all requests and the attacker is still 514 managing to consume too many resources, the Responder MAY increase 515 the difficulty of puzzles imposed on IKE_SA_INIT requests coming from 516 suspicious nodes/prefixes. It should still be doable by all 517 legitimate peers, but it can degrade experience, for example by 518 taking up to 10 seconds to solve the puzzle. 520 If the load on the Responder is still too great, and there are many 521 nodes causing multiple half-open SAs or IKE_AUTH failures, the 522 Responder MAY impose hard limits on those nodes. 524 If it turns out that the attack is very widespread and the hard caps 525 are not solving the issue, a puzzle MAY be imposed on all Initiators. 526 Note that this is the last step, and the Responder should avoid this 527 if possible. 529 6.1. Session Resumption 531 When the Responder is under attack, it MAY choose to prefer 532 previously authenticated peers who present a Session Resumption 533 ticket (see [RFC5723] for details). The Responder MAY require such 534 Initiators to pass a return routability check by including the COOKIE 535 notification in the IKE_SESSION_RESUME response message, as allowed 536 by Section 4.3.2. of [RFC5723]. Note that the Responder SHOULD cache 537 tickets for a short time to reject reused tickets (Section 4.3.1), 538 and therefore there should be no issue of half-open SAs resulting 539 from replayed IKE_SESSION_RESUME messages. 541 7. Using Puzzles in the Protocol 543 This section describes how the puzzle mechanism is used in IKEv2. It 544 is organized as follows. The Section 7.1 describes using puzzles in 545 the IKE_SA_INIT exchange and the Section 7.2 describes using puzzles 546 in the IKE_AUTH exchange. Both sections are divided into subsections 547 describing how puzzles should be presented, solved and processed by 548 the Initiator and the Responder. 550 7.1. Puzzles in IKE_SA_INIT Exchange 552 IKE Initiator indicates the desire to create a new IKE SA by sending 553 IKE_SA_INIT request message. The message may optionally contain a 554 COOKIE notification if this is a repeated request performed after the 555 Responder's demand to return a cookie. 557 HDR, [N(COOKIE),] SA, KE, Ni, [V+][N+] --> 559 According to the plan, described in Section 6, the IKE Responder 560 should monitor incoming requests to detect whether it is under 561 attack. If the Responder learns that (D)DoS attack is likely to be 562 in progress, then its actions depend on the volume of the attack. If 563 the volume is moderate, then the Responder requests the Initiator to 564 return a cookie. If the volume is so high, that puzzles need to be 565 used for defense, then the Responder requests the Initiator to solve 566 a puzzle. 568 The Responder MAY choose to process some fraction of IKE_SA_INIT 569 requests without presenting a puzzle while being under attack to 570 allow legacy clients, that don't support puzzles, to have a chance to 571 be served. The decision whether to process any particular request 572 must be probabilistic, with the probability depending on the 573 Responder's load (i.e. on the volume of attack). The requests that 574 don't contain the COOKIE notification MUST NOT participate in this 575 lottery. In other words, the Responder must first perform return 576 routability check before allowing any legacy client to be served if 577 it is under attack. See Section 7.1.4 for details. 579 7.1.1. Presenting Puzzle 581 If the Responder makes a decision to use puzzles, then it MUST 582 include two notifications in its response message - the COOKIE 583 notification and the PUZZLE notification. The format of the PUZZLE 584 notification is described in Section 9.1. 586 <-- HDR, N(COOKIE), N(PUZZLE), [V+][N+] 588 The presence of these notifications in an IKE_SA_INIT response 589 message indicates to the Initiator that it should solve the puzzle to 590 get better chances to be served. 592 7.1.1.1. Selecting Puzzle Difficulty Level 594 The PUZZLE notification contains the difficulty level of the puzzle - 595 the minimum number of trailing zero bits that the result of PRF must 596 contain. In diverse environments it is next to impossible for the 597 Responder to set any specific difficulty level that will result in 598 roughly the same amount of work for all Initiators, because 599 computation power of different Initiators may vary by the order of 600 magnitude, or even more. The Responder may set difficulty level to 601 0, meaning that the Initiator is requested to spend as much power to 602 solve puzzle, as it can afford. In this case no specific value of 603 ZBC is required from the Initiator, however the larger the ZBC that 604 Initiator is able to get, the better the chances it will have to be 605 served by the Responder. In diverse environments it is RECOMMENDED 606 that the Initiator sets difficulty level to 0, unless the attack 607 volume is very high. 609 If the Responder sets non-zero difficulty level, then the level 610 should be determined by analyzing the volume of the attack. The 611 Responder MAY set different difficulty levels to different requested 612 depending on the IP address the request has come from. 614 7.1.1.2. Selecting Puzzle Algorithm 616 The PUZZLE notification also contains identifier of the algorithm, 617 that must be used by Initiator to compute puzzle. 619 Cryptographic algorithm agility is considered an important feature 620 for modern protocols ([RFC7696]). This feature ensures that protocol 621 doesn't rely on a single build-in set of cryptographic algorithms, 622 but has a means to replace one set with another and negotiate new set 623 with the peer. IKEv2 fully supports cryptographic algorithm agility 624 for its core operations. 626 To support this feature in case of puzzles the algorithm, that is 627 used to compute puzzle, needs to be negotiated during IKE_SA_INIT 628 exchange. The negotiation is done as follows. The initial request 629 message sent by Initiator contains SA payload with the list of 630 transforms the Initiator supports and is willing to use in the IKE SA 631 being established. The Responder parses received SA payload and 632 finds mutually supported set of transforms of type PRF. It selects 633 most preferred transform from this set and includes it into the 634 PUZZLE notification. There is no requirement that the PRF selected 635 for puzzles be the same, as the PRF that is negotiated later for the 636 use in core IKE SA crypto operations. If there are no mutually 637 supported PRFs, then negotiation will fail anyway and there is no 638 reason to return a puzzle. In this case the Responder returns 639 NO_PROPOSAL_CHOSEN notification. Note that PRF is a mandatory 640 transform type for IKE SA (see Sections 3.3.2 and 3.3.3 of [RFC7296]) 641 and at least one transform of this type must always be present in SA 642 payload in IKE_SA_INIT exchange. 644 7.1.1.3. Generating Cookie 646 If Responder supports puzzles then cookie should be computed in such 647 a manner, that the Responder is able to learn some important 648 information from the sole cookie, when it is later returned back by 649 Initiator. In particular - the Responder should be able to learn the 650 following information: 652 o Whether the puzzle was given to the Initiator or only the cookie 653 was requested. 655 o The difficulty level of the puzzle given to the Initiator. 657 o The number of consecutive puzzles given to the Initiator. 659 o The amount of time the Initiator spent to solve the puzzles. This 660 can be calculated if the cookie is timestamped. 662 This information helps the Responder to make a decision whether to 663 serve this request or demand more work from the Initiator. 665 One possible approach to get this information is to encode it in the 666 cookie. The format of such encoding is a local matter of Responder, 667 as the cookie would remain an opaque blob to the Initiator. If this 668 information is encoded in the cookie, then the Responder MUST make it 669 integrity protected, so that any intended or accidental alteration of 670 this information in returned cookie is detectable. So, the cookie 671 would be generated as: 673 Cookie = | | 674 Hash(Ni | IPi | SPIi | | ) 676 Alternatively, the Responder may continue to generate cookie as 677 suggested in Section 2.6 of [RFC7296], but associate the additional 678 information, that would be stored locally, with the particular 679 version of the secret. In this case the Responder should have 680 different secret for every combination of difficulty level and number 681 of consecutive puzzles, and should change the secrets periodically, 682 keeping a few previous versions, to be able to calculate how long ago 683 the cookie was generated. 685 The Responder may also combine these approaches. This document 686 doesn't mandate how the Responder learns this information from the 687 cookie. 689 7.1.2. Solving Puzzle and Returning the Solution 691 If the Initiator receives a puzzle but it doesn't support puzzles, 692 then it will ignore the PUZZLE notification as an unrecognized status 693 notification (in accordance to Section 3.10.1 of [RFC7296]). The 694 Initiator also MAY ignore the PUZZLE notification if it is not 695 willing to spend resources to solve the puzzle of the requested 696 difficulty, even if it supports puzzles. In both cases the Initiator 697 acts as described in Section 2.6 of [RFC7296] - it restarts the 698 request and includes the received COOKIE notification into it. The 699 Responder should be able to distinguish the situation when it just 700 requested a cookie from the situation when the puzzle was given to 701 the Initiator, but the Initiator for some reason ignored it. 703 If the received message contains a PUZZLE notification and doesn't 704 contain a COOKIE notification, then this message is malformed because 705 it requests to solve the puzzle, but doesn't provide enough 706 information to do it. In this case the Initiator SHOULD resend 707 IKE_SA_INIT request. If this situation repeats several times, then 708 it means that something is wrong and the IKE SA cannot be 709 established. 711 If the Initiator supports puzzles and is ready to deal with them, 712 then it tries to solve the given puzzle. After the puzzle is solved 713 the Initiator restarts the request and returns the puzzle solution in 714 a new payload called a Puzzle Solution payload (denoted as PS, see 715 Section 9.2) along with the received COOKIE notification back to the 716 Responder. 718 HDR, N(COOKIE), [PS,] SA, KE, Ni, [V+][N+] --> 720 7.1.3. Computing Puzzle 722 General principals of constructing puzzles in IKEv2 are described in 723 Section 3. They can be summarized as follows: given unpredictable 724 string S and pseudo-random function PRF find the key K for that PRF 725 so that the result of PRF(K,S) has the specified number of trailing 726 zero bits. 728 In the IKE_SA_INIT exchange it is the cookie that plays the role of 729 unpredictable string S. In other words, in IKE_SA_INIT the task for 730 the IKE Initiator is to find the key K for the agreed upon PRF such 731 that the result of PRF(K,cookie) has sufficient number of trailing 732 zero bits. Only the content of the COOKIE notification is used in 733 puzzle calculation, i.e. the header of the Notification payload is 734 not included. 736 Note, that puzzles in the IKE_AUTH exchange are computed differently 737 that in the IKE_SA_INIT_EXCHANGE. See Section 7.2.3 for details. 739 7.1.4. Analyzing Repeated Request 741 The received request must at least contain a COOKIE notification. 742 Otherwise it is an initial request and it must be processed according 743 to Section 7.1. First, the cookie MUST be checked for validity. If 744 the cookie is invalid, then the request is treated as initial and is 745 processed according to Section 7.1. If the cookie is valid then some 746 important information is learned from it or from local state based on 747 identifier of the cookie's secret (see Section 7.1.1.3 for details). 748 This information helps the Responder to sort out incoming requests, 749 giving more priority to those of them, which were created by spending 750 more of the Initiator's resources. 752 First, the Responder determines if it requested only a cookie, or 753 presented a puzzle to the Initiator. If no puzzle was given, then it 754 means that at the time the Responder requested a cookie it didn't 755 detect the (D)DoS attack or the attack volume was low. In this case 756 the received request message must not contain the PS payload, and 757 this payload MUST be ignored if for any reason the message contains 758 it. Since no puzzle was given, the Responder marks the request with 759 the lowest priority since the Initiator spent little resources 760 creating it. 762 If the Responder learns from the cookie that the puzzle was given to 763 the Initiator, then it looks for the PS payload to determine whether 764 its request to solve the puzzle was honored or not. If the incoming 765 message doesn't contain a PS payload, then it means that the 766 Initiator either doesn't support puzzles or doesn't want to deal with 767 them. In either case the request is marked with the lowest priority 768 since the Initiator spent little resources creating it. 770 If a PS payload is found in the message, then the Responder MUST 771 verify the puzzle solution that it contains. The result must contain 772 at least the requested number of trailing zero bits (that is also 773 learned from the cookie, as well as the PRF algorithm used in puzzle 774 solution). If the result of the solution contains fewer bits than 775 were requested, it means that Initiator spent less resources than 776 expected by the Responder. This request is marked with the lowest 777 priority. 779 If the Initiator provided the solution to the puzzle satisfying the 780 requested difficulty level, or if the Responder didn't indicate any 781 particular difficulty level (by requesting zero level) and the 782 Initiator was free to select any difficulty level it can afford, then 783 the priority of the request is calculated based on the following 784 considerations: 786 o The higher zero bits the Initiator got, the higher priority its 787 request should receive. 789 o The more consecutive puzzles the Initiator solved, the higher 790 priority it should receive. 792 o The more time the Initiator spent solving the puzzles, the higher 793 priority it should receive. 795 After the priority of the request is determined the final decision 796 whether to serve it or not is made. 798 7.1.5. Making Decision whether to Serve the Request 800 The Responder decides what to do with the request based on its 801 priority and Responder's current load. There are three possible 802 actions: 804 o Accept request. 806 o Reject request. 808 o Demand more work from Initiator by giving it a new puzzle. 810 The Responder SHOULD accept incoming request if its priority is high 811 - it means that the Initiator spent quite a lot of resources. The 812 Responder MAY also accept some of low-priority requests where the 813 Initiators don't support puzzles. The percentage of accepted legacy 814 requests depends on the Responder's current load. 816 If Initiator solved the puzzle, but didn't spend much resources for 817 it (the selected puzzle difficulty level appeared to be low and the 818 Initiator solved it quickly), then the Responder SHOULD give it 819 another puzzle. The more puzzles the Initiator solves the higher its 820 chances are to be served. 822 The details of how the Responder makes decision on any particular 823 request, are implementation dependent. The Responder can collect all 824 the incoming requests for some short period of time, sort them out 825 based on their priority, calculate the number of available memory 826 slots for half-open IKE SAs and then serve that number of requests 827 from the head of the sorted list. The rest of requests can be either 828 discarded or responded to with new puzzles. 830 Alternatively, the Responder may decide whether to accept every 831 incoming request with some kind of lottery, taking into account its 832 priority and the available resources. 834 7.2. Puzzles in IKE_AUTH Exchange 836 Once the IKE_SA_INIT exchange is completed, the Responder has created 837 a state and is waiting for the first message of the IKE_AUTH exchange 838 from Initiator. At this point the Initiator has already passed 839 return routability check and has proved that it has performed some 840 work to complete IKE_SA_INIT exchange. However, the Initiator is not 841 yet authenticated and this fact allows malicious Initiator to perform 842 an attack, described in Section 2. Unlike DoS attack in IKE_SA_INIT 843 exchange, which is targeted on the Responder's memory resources, the 844 goal of this attack is to exhaust a Responder's CPU power. The 845 attack is performed by sending the first IKE_AUTH message containing 846 garbage. This costs nothing to the Initiator, but the Responder has 847 to do relatively costly operations of computing the D-H shared secret 848 and deriving SK_* keys to be able to verify authenticity of the 849 message. If the Responder doesn't keep the computed keys after an 850 unsuccessful verification of the IKE_AUTH message, then the attack 851 can be repeated several times on the same IKE SA. 853 The Responder can use puzzles to make this attack more costly for the 854 Initiator. The idea is that the Responder includes a puzzle in the 855 IKE_SA_INIT response message and the Initiator includes a puzzle 856 solution in the first IKE_AUTH request message outside the Encrypted 857 payload, so that the Responder is able to verify puzzle solution 858 before computing D-H shared secret. The difficulty level of the 859 puzzle should be selected so that the Initiator would spend 860 substantially more time to solve the puzzle than the Responder to 861 compute the shared secret. 863 The Responder should constantly monitor the amount of the half-open 864 IKE SA states that receive IKE_AUTH messages that cannot be decrypted 865 due to integrity check failures. If the percentage of such states is 866 high and it takes an essential fraction of Responder's computing 867 power to calculate keys for them, then the Responder may assume that 868 it is under attack and SHOULD use puzzles to make it harder for 869 attackers. 871 7.2.1. Presenting Puzzle 873 The Responder requests the Initiator to solve a puzzle by including 874 the PUZZLE notification in the IKE_SA_INIT response message. The 875 Responder MUST NOT use puzzles in the IKE_AUTH exchange unless the 876 puzzle has been previously presented and solved in the preceding 877 IKE_SA_INIT exchange. 879 <-- HDR, SA, KE, Nr, N(PUZZLE), [V+][N+] 881 7.2.1.1. Selecting Puzzle Difficulty Level 883 The difficulty level of the puzzle in IKE_AUTH should be chosen so 884 that the Initiator would spend more time to solve the puzzle than the 885 Responder to compute the D-H shared secret and the keys, needed to 886 decrypt and verify the IKE_AUTH request message. On the other hand, 887 the difficulty level should not be too high, otherwise the legitimate 888 clients would experience an additional delay while establishing IKE 889 SA. 891 Note, that since puzzles in the IKE_AUTH exchange are only allowed to 892 be used if they were used in the preceding IKE_SA_INIT exchange, the 893 Responder would be able to estimate the computing power of the 894 Initiator and to select the difficulty level accordingly. Unlike 895 puzzles in IKE_SA_INIT, the requested difficulty level for IKE_AUTH 896 puzzles MUST NOT be zero. In other words, the Responder must always 897 set specific difficulty level and must not let the Initiator to 898 choose it on its own. 900 7.2.1.2. Selecting Puzzle Algorithm 902 The algorithm for the puzzle is selected as described in 903 Section 7.1.1.2. There is no requirement, that the algorithm for the 904 puzzle in the IKE_SA INIT exchange be the same, as the algorithm for 905 the puzzle in IKE_AUTH exchange, however it is expected that in most 906 cases they will be the same. 908 7.2.2. Solving Puzzle and Returning the Solution 910 If the IKE_SA_INIT response message contains the PUZZLE notification 911 and the Initiator supports puzzles, it MUST solve the puzzle. Note, 912 that puzzle construction in the IKE_AUTH exchange differs from the 913 puzzle construction in the IKE_SA_INIT exchange and is described in 914 Section 7.2.3. Once the puzzle is solved the Initiator sends the 915 IKE_AUTH request message, containing the Puzzle Solution payload. 917 HDR, PS, SK {IDi, [CERT,] [CERTREQ,] 918 [IDr,] AUTH, SA, TSi, TSr} --> 920 The Puzzle Solution payload MUST be placed outside the Encrypted 921 payload, so that the Responder would be able to verify the puzzle 922 before calculating the D-H shared secret and the SK_* keys. 924 If IKE Fragmentation [RFC7383] is used in IKE_AUTH exchange, then the 925 PS payload MUST be present only in the first IKE Fragment message, in 926 accordance with the Section 2.5.3 of [RFC7383]. Note, that 927 calculation of the puzzle in the IKE_AUTH exchange doesn't depend on 928 the content of the IKE_AUTH message (see Section 7.2.3). Thus the 929 Initiator has to solve the puzzle only once and the solution is valid 930 for both unfragmented and fragmented IKE messages. 932 7.2.3. Computing Puzzle 934 The puzzles in the IKE_AUTH exchange are computed differently than in 935 the IKE_SA_INIT exchange (see Section 7.1.3). The general principle 936 is the same; the difference is in the construction of the string S. 937 Unlike the IKE_SA_INIT exchange, where S is the cookie, in the 938 IKE_AUTH exchange S is a concatenation of Nr and SPIr. In other 939 words, the task for IKE Initiator is to find the key K for the agreed 940 upon PRF such that the result of PRF(K,Nr | SPIr) has a sufficient 941 number of trailing zero bits. Nr is a nonce used by the Responder in 942 IKE_SA_INIT exchange, stripped of any headers. SPIr is IKE Responder 943 SPI in the SA being established. 945 7.2.4. Receiving Puzzle Solution 947 If the Responder requested the Initiator to solve a puzzle in the 948 IKE_AUTH exchange, then it MUST silently discard all the IKE_AUTH 949 request messages without the Puzzle Solution payload. 951 Once the message containing a solution to the puzzle is received, the 952 Responder MUST verify the solution before performing computationlly 953 intensive operations i.e. computing the D-H shared secret and the 954 SK_* keys. The Responder MUST silently discard the received message 955 if the puzzle solution is not correct (has insufficient number of 956 trailing zero bits). If the Responder successfully verifies the 957 puzzle and calculates the SK_* key, but the message authenticity 958 check fails, then it SHOULD save the calculated keys in the IKE SA 959 state while waiting for the retransmissions from the Initiator. In 960 this case the Responder may skip verification of the puzzle solution 961 and ignore the Puzzle Solution payload in the retransmitted messages. 963 If the Initiator uses IKE Fragmentation, then it is possible, that 964 due to packet loss and/or reordering the Responder could receive non- 965 first IKE Fragment messages before receiving the first one, 966 containing the PS payload. In this case the Responder MAY choose to 967 keep the received fragments until the first fragment containing the 968 solution to the puzzle is received. However, in this case the 969 Responder SHOULD NOT try to verify authenticity of the kept fragments 970 until the first fragment with the PS payload is received and the 971 solution to the puzzle is verified. After successful verification of 972 the puzzle the Responder could calculate the SK_* key and verify 973 authenticity of the collected fragments. 975 8. DoS Protection after IKE SA is created 977 Once IKE SA is created there is usually not much traffic over it. In 978 most cases this traffic consists of exchanges aimed to create 979 additional Child SAs, rekey, or delete them and check the liveness of 980 the peer. With a typical setup and typical Child SA lifetimes, there 981 are typically no more than a few such exchanges, often less. Some of 982 these exchanges require relatively little resources (like liveness 983 check), while others may be resource consuming (like creating or 984 rekeying Child SA with D-H exchange). 986 Since any endpoint can initiate a new exchange, there is a 987 possibility that a peer would initiate too many exchanges that could 988 exhaust host resources. For example, the peer can perform endless 989 continuous Child SA rekeying or create overwhelming number of Child 990 SAs with the same Traffic Selectors etc. Such behavior may be caused 991 by buggy implementation, misconfiguration or be intentional. The 992 latter becomes more of a real threat if the peer uses NULL 993 Authentication, described in [RFC7619]. In this case the peer 994 remains anonymous, allowing it to escape any responsibility for its 995 actions. 997 The following recommendations for defense against possible DoS 998 attacks after IKE SA is established are mostly intended for 999 implementations that allow unauthenticated IKE sessions; however, 1000 they may also be useful in other cases. 1002 o If the IKEv2 window size is greater than one, then the peer could 1003 initiate multiple simultaneous exchanges that could increase host 1004 resource consumption. Since currently there is no way in IKEv2 to 1005 decrease window size once it was increased (see Section 2.3 of 1006 [RFC7296]), the window size cannot be dynamically adjusted 1007 depending on the load. For that reason, it is NOT RECOMMENDED to 1008 ever increase the IKEv2 window size above its default value of one 1009 if the peer uses NULL Authentication. 1011 o If the peer initiates requests to rekey IKE SA or Child SA too 1012 often, implementations can respond to some of these requests with 1013 the TEMPORARY_FAILURE notification, indicating that the request 1014 should be retried after some period of time. 1016 o If the peer creates too many Child SA with the same or overlapping 1017 Traffic Selectors, implementations can respond with the 1018 NO_ADDITIONAL_SAS notification. 1020 o If the peer initiates too many exchanges of any kind, 1021 implementations can introduce an artificial delay before 1022 responding to request messages. This delay would decrease the 1023 rate the implementation need to process requests from any 1024 particular peer, making it possible to process requests from the 1025 others. The delay should not be too long to avoid causing the IKE 1026 SA to be deleted on the other end due to timeout. It is believed 1027 that a few seconds is enough. Note, that if the Responder 1028 receives retransmissions of the request message during the delay 1029 period, the retransmitted messages should be silently discarded. 1031 o If these counter-measures are inefficient, implementations can 1032 delete the IKE SA with an offending peer by sending Delete 1033 Payload. 1035 9. Payload Formats 1036 9.1. PUZZLE Notification 1038 The PUZZLE notification is used by the IKE Responder to inform the 1039 Initiator about the necessity to solve the puzzle. It contains the 1040 difficulty level of the puzzle and the PRF the Initiator should use. 1042 1 2 3 1043 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 1044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1045 | Next Payload |C| RESERVED | Payload Length | 1046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1047 |Protocol ID(=0)| SPI Size (=0) | Notify Message Type | 1048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1049 | PRF | Difficulty | 1050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1052 o Protocol ID (1 octet) - MUST be 0. 1054 o SPI Size (1 octet) - MUST be 0, meaning no Security Parameter 1055 Index (SPI) is present. 1057 o Notify Message Type (2 octets) - MUST be , the value 1058 assigned for the PUZZLE notification. 1060 o PRF (2 octets) - Transform ID of the PRF algorithm that must be 1061 used to solve the puzzle. Readers should refer to the section 1062 "Transform Type 2 - Pseudo-Random Function Transform IDs" in 1063 [IKEV2-IANA] for the list of possible values. 1065 o Difficulty (1 octet) - Difficulty Level of the puzzle. Specifies 1066 minimum number of trailing zero bit, that the result of PRF must 1067 contain. Value 0 means that the Responder doesn't request any 1068 specific difficulty level and the Initiator is free to select 1069 appropriate difficulty level of its own (see Section 7.1.1.1 for 1070 details). 1072 This notification contains no data. 1074 9.2. Puzzle Solution Payload 1076 The solution to the puzzle is returned back to the Responder in a 1077 dedicated payload, called the Puzzle Solution payload and denoted as 1078 PS in this document. 1080 1 2 3 1081 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 1082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1083 | Next Payload |C| RESERVED | Payload Length | 1084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1085 | | 1086 ~ Puzzle Solution Data ~ 1087 | | 1088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1090 o Puzzle Solution Data (variable length) - Contains the solution to 1091 the puzzle - i.e. the key for the PRF. This field MUST NOT be 1092 empty. If the selected PRF has a fixed-size key, then the size of 1093 the Puzzle Solution Data MUST be equal to the size of the key. If 1094 the PRF agreed upon accepts keys of any size, then then the size 1095 of the Puzzle Solution Data MUST be between 1 octet and the 1096 preferred key length of the PRF (inclusive). 1098 The payload type for the Puzzle Solution payload is . 1100 10. Operational Considerations 1102 The difficulty level should be set by balancing the requirement to 1103 minimize the latency for legitimate Initiators and making things 1104 difficult for attackers. A good rule of thumb is for taking about 1 1105 second to solve the puzzle. A typical Initiator or bot-net member in 1106 2014 can perform slightly less than a million hashes per second per 1107 core, so setting the difficulty level to n=20 is a good compromise. 1108 It should be noted that mobile Initiators, especially phones are 1109 considerably weaker than that. Implementations should allow 1110 administrators to set the difficulty level, and/or be able to set the 1111 difficulty level dynamically in response to load. 1113 Initiators should set a maximum difficulty level beyond which they 1114 won't try to solve the puzzle and log or display a failure message to 1115 the administrator or user. 1117 11. Security Considerations 1119 When selecting parameters for the puzzles, in particular the puzzle 1120 difficulty, care must be taken. If the puzzles appeared too easy for 1121 majority of the attackers, then the puzzles mechanism wouldn't be 1122 able to prevent DoS attack and would only impose an additional burden 1123 on the legitimate Initiators. On the other hand, if the puzzles 1124 appeared to be too hard for majority of the Initiators then many 1125 legitimate users would experience unacceptable delay in IKE SA setup 1126 (or unacceptable power consumption on mobile devices), that might 1127 cause them to cancel connection attempt. In this case the resources 1128 of the Responder are preserved, however the DoS attack can be 1129 considered successful. Thus a sensible balance should be kept by the 1130 Responder while choosing the puzzle difficulty - to defend itself and 1131 to not over-defend itself. It is RECOMMENDED that the puzzle 1132 difficulty be chosen so, that the Responder's load remain close to 1133 the maximum it can tolerate. It is also RECOMMENDED to dynamically 1134 adjust the puzzle difficulty in accordance to the current Responder's 1135 load. 1137 Solving puzzles requires a lot of CPU power, that would increase 1138 power consumption. This would influence battery-powered Initiators, 1139 e.g. mobile phones or some IoT devices. If puzzles are hard then the 1140 required additional power consumption may appear to be unacceptable 1141 for some Initiators. The Responder SHOULD take this possibility into 1142 considerations while choosing the puzzles difficulty and while 1143 selecting which percentage of Initiators are allowed to reject 1144 solving puzzles. See Section 7.1.4 for details. 1146 If the Initiator uses NULL Authentication [RFC7619] then its identity 1147 is never verified, that may be used by attackers to perform DoS 1148 attack after IKE SA is established. Responders that allow 1149 unauthenticated Initiators to connect must be prepared deal with 1150 various kinds of DoS attacks even after IKE SA is created. See 1151 Section 8 for details. 1153 12. IANA Considerations 1155 This document defines a new payload in the "IKEv2 Payload Types" 1156 registry: 1158 Puzzle Solution PS 1160 This document also defines a new Notify Message Type in the "IKEv2 1161 Notify Message Types - Status Types" registry: 1163 PUZZLE 1165 13. References 1167 13.1. Normative References 1169 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1170 Requirement Levels", BCP 14, RFC 2119, 1171 DOI 10.17487/RFC2119, March 1997, 1172 . 1174 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 1175 Kivinen, "Internet Key Exchange Protocol Version 2 1176 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 1177 2014, . 1179 [RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2 1180 (IKEv2) Message Fragmentation", RFC 7383, 1181 DOI 10.17487/RFC7383, November 2014, 1182 . 1184 [IKEV2-IANA] 1185 "Internet Key Exchange Version 2 (IKEv2) Parameters", 1186 . 1188 13.2. Informative References 1190 [bitcoins] 1191 Nakamoto, S., "Bitcoin: A Peer-to-Peer Electronic Cash 1192 System", October 2008, . 1194 [RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange 1195 Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, 1196 DOI 10.17487/RFC5723, January 2010, 1197 . 1199 [RFC7619] Smyslov, V. and P. Wouters, "The NULL Authentication 1200 Method in the Internet Key Exchange Protocol Version 2 1201 (IKEv2)", RFC 7619, DOI 10.17487/RFC7619, August 2015, 1202 . 1204 [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm 1205 Agility and Selecting Mandatory-to-Implement Algorithms", 1206 BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, 1207 . 1209 Authors' Addresses 1211 Yoav Nir 1212 Check Point Software Technologies Ltd. 1213 5 Hasolelim st. 1214 Tel Aviv 6789735 1215 Israel 1217 EMail: ynir.ietf@gmail.com 1218 Valery Smyslov 1219 ELVIS-PLUS 1220 PO Box 81 1221 Moscow (Zelenograd) 124460 1222 Russian Federation 1224 Phone: +7 495 276 0211 1225 EMail: svan@elvis.ru