idnits 2.17.1 draft-ietf-ipsecme-ddos-protection-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == 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 8, 2015) is 3337 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' == Outdated reference: A later version (-08) exists of draft-iab-crypto-alg-agility-02 == Outdated reference: A later version (-07) exists of draft-ietf-ipsecme-ikev2-null-auth-02 Summary: 0 errors (**), 0 flaws (~~), 4 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 9, 2015 ELVIS-PLUS 6 March 8, 2015 8 Protecting Internet Key Exchange (IKE) Implementations from Distributed 9 Denial of Service Attacks 10 draft-ietf-ipsecme-ddos-protection-01 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 September 9, 2015. 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. Conventions Used in This Document . . . . . . . . . . . . 3 56 2. The Vulnerability . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Puzzles . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 3.1. The Keyed-Cookie Notification . . . . . . . . . . . . . . 8 59 3.2. The Puzzle-Required Notification . . . . . . . . . . . . 8 60 4. Retention Periods for Half-Open SAs . . . . . . . . . . . . . 8 61 5. Rate Limiting . . . . . . . . . . . . . . . . . . . . . . . . 8 62 6. Plan for Defending a Responder . . . . . . . . . . . . . . . 9 63 6.1. Session Resumption . . . . . . . . . . . . . . . . . . . 11 64 7. Operational Considerations . . . . . . . . . . . . . . . . . 12 65 8. Using Puzzles in the Protocol . . . . . . . . . . . . . . . . 12 66 8.1. Puzzles in IKE_SA_INIT Exchange . . . . . . . . . . . . . 12 67 8.1.1. Presenting Puzzle . . . . . . . . . . . . . . . . . . 13 68 8.1.2. Solving Puzzle and Returning the Solution . . . . . . 15 69 8.1.3. Analyzing Repeated Request . . . . . . . . . . . . . 16 70 8.1.4. Making Decision whether to Serve the Request . . . . 17 71 8.2. Puzzles in IKE_AUTH Exchange . . . . . . . . . . . . . . 18 72 8.2.1. Presenting Puzzle . . . . . . . . . . . . . . . . . . 19 73 8.2.2. Solving Puzzle and Returning the Solution . . . . . . 20 74 8.2.3. Receiving Puzzle Solution . . . . . . . . . . . . . . 20 75 9. DoS Protection after IKE SA is created . . . . . . . . . . . 21 76 10. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 22 77 10.1. PUZZLE Notification . . . . . . . . . . . . . . . . . . 22 78 10.2. Puzzle Solution Payload . . . . . . . . . . . . . . . . 23 79 11. Security Considerations . . . . . . . . . . . . . . . . . . . 24 80 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 81 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 82 13.1. Normative References . . . . . . . . . . . . . . . . . . 24 83 13.2. Informative References . . . . . . . . . . . . . . . . . 24 85 1. Introduction 87 The IKE_SA_INIT Exchange described in section 1.2 of [RFC7296] 88 involves the Initiator sending a single message. The Responder 89 replies with a single message and also allocates memory for a 90 structure called a half-open IKE SA (Security Association). This 91 half-open SA is later authenticated in the IKE_AUTH Exchange, but if 92 that IKE_AUTH request never comes, the half-open SA is kept for an 93 unspecified amount of time. Depending on the algorithms used and 94 implementation, such a half-open SA will use from around 100 bytes to 95 several thousands bytes of memory. 97 This creates an easy attack vector against an Internet Key Exchange 98 (IKE) Responder. Generating the Initial request is cheap, and 99 sending multiple such requests can either cause the Responder to 100 allocate too much resources and fail, or else if resource allocation 101 is somehow throttled, legitimate Initiators would also be prevented 102 from setting up IKE SAs. 104 An obvious defense, which is described in Section 5, is limiting the 105 number of half-open SAs opened by a single peer. However, since all 106 that is required is a single packet, an attacker can use multiple 107 spoofed source IP addresses. 109 Section 2.6 of RFC 7296 offers a mechanism to mitigate this DoS 110 attack: the stateless cookie. When the server is under load, the 111 Responder responds to the Initial request with a calculated 112 "stateless cookie" - a value that can be re-calculated based on 113 values in the Initial request without storing Responder-side state. 114 The Initiator is expected to repeat the Initial request, this time 115 including the stateless cookie. 117 Attackers that have multiple source IP addresses with return 118 routability, such as bot-nets can fill up a half-open SA table 119 anyway. The cookie mechanism limits the amount of allocated state to 120 the size of the bot-net, multiplied by the number of half-open SAs 121 allowed for one peer address, multiplied by the amount of state 122 allocated for each half-open SA. With typical values this can easily 123 reach hundreds of megabytes. 125 The mechanism described in Section 3 adds a proof of work for the 126 Initiator, by calculating a pre-image for a partial hash value. This 127 sets an upper bound, determined by the attacker's CPU to the number 128 of negotiations it can initiate in a unit of time. 130 1.1. Conventions Used in This Document 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in [RFC2119]. 136 2. The Vulnerability 138 If we break down what a responder has to do during an initial 139 exchange, there are three stages: 141 1. When the Initial request arrives, the responder: 143 * Generates or re-uses a D-H private part. 145 * Generates a responder SPI. 147 * Stores the private part and peer public part in a half-open SA 148 database. 150 2. When the Authentication request arrives, the responder: 152 * Derives the keys from the half-open SA. 154 * Decrypts the request. 156 3. If the Authentication request decrypts properly: 158 * Validates the certificate chain (if present) in the auth 159 request. 161 Yes, there's a stage 4 where the responder actually creates Child 162 SAs, but when talking about (D)DoS, we never get to this stage. 164 Stage #1 is pretty light on CPU power, but requires some storage, and 165 it's very light for the initiator as well. Stage #2 includes 166 private-key operations, so it's much heavier CPU-wise, but it 167 releases the storage allocated in stage #1. Stage #3 includes a 168 public key operation, and possibly many of them. 170 To attack such a server, an attacker can attempt to either exhaust 171 memory or to exhaust CPU. Without any protection, the most efficient 172 attack is to send multiple Initial requests and exhaust memory. This 173 should be easy because those Initial requests are cheap. 175 There are obvious ways for the responder to protect itself even 176 without changes to the protocol. It can reduce the time that an 177 entry remains in the half-open SA database, and it can limit the 178 amount of concurrent half-open SAs from a particular address or 179 prefix. The attacker can overcome this by using spoofed source 180 addresses. 182 The stateless cookie mechanism from section 2.6 of RFC 7296 prevents 183 an attack with spoofed source addresses. This doesn't solve the 184 issue, but it makes the limiting of half-open SAs by address or 185 prefix work. Puzzles do the same thing only more of it. They make 186 it harder for an attacker to reach the goal of getting a half-open 187 SA. They don't have to be so hard that an attacker can't afford to 188 solve them - it's enough that they increase the cost of a half-open 189 SAs for the attacker. 191 Reducing the amount of time an abandoned half-open SA is kept attacks 192 the issue from the other side. It reduces the value the attacker 193 gets from managing to create a half-open SA. So if a half-open SA 194 takes 1 KB and it's kept for 1 minute and the capacity is 60,000 195 half-open SAs, an attacker would need to create 1,000 half-open SAs 196 per second. Reduce the retention time to 3 seconds, and the attacker 197 needs to create 20,000 half-open SAs per second. Make each of those 198 more expensive by introducing a puzzle, and you're likely to thwart 199 an exhaustion attack against responder memory. 201 At this point, filling up the half-open SA database in no longer the 202 most efficient DoS attack. The attacker has two ways to do better: 204 1. Go back to spoofed addresses and try to overwhelm the CPU that 205 deals with generating cookies, or 207 2. Take the attack to the next level by also sending an 208 Authentication request. 210 I don't think the first thing is something we can deal with at the 211 IKE level. It's probably better left to Intrusion Prevention System 212 (IPS) technology. 214 Sending an Authentication request is surprisingly cheap. It requires 215 a proper IKE header with the correct IKE SPIs, and it requires a 216 single encrypted payload. The content of the payload might as well 217 be junk. The responder has to perform the relatively expensive key 218 derivation, only to find that the Authentication request does not 219 decrypt. Depending on the responder implementation, this can be 220 repeated with the same half-open SA (if the responder does not delete 221 the half-open SA following an unsuccessful decryption - see 222 discussion in Section 4). 224 Here too, the number of half-open SAs that the attacker can achieve 225 is crucial, because each one of them allows the attacker to waste 226 some CPU time. So making it hard to make many half-open SAs is 227 important. 229 A strategy against DDoS has to rely on at least 4 components: 231 1. Hardening the half-open SA database by reducing retention time. 233 2. Hardening the half-open SA database by rate-limiting single IPs/ 234 prefixes. 236 3. Guidance on what to do when an Authentication request fails to 237 decrypt. 239 4. Increasing cost of half-open SA up to what is tolerable for 240 legitimate clients. 242 Puzzles have their place as part of #4. 244 3. Puzzles 246 The puzzle introduced here extends the cookie mechanism from RFC 247 7296. It is loosely based on the proof-of-work technique used in 248 BitCoins ([bitcoins]). Future versions of this document will have 249 the exact bit structure of the notification payloads, but for now, I 250 will only describe the semantics of the content. 252 A puzzle is sent to the Initiator in two cases: 254 o The Responder is so overloaded, than no half-open SAs are allowed 255 to be created without the puzzle, or 257 o The Responder is not too loaded, but the rate-limiting in 258 Section 5 prevents half-open SAs from being created with this 259 particular peer address or prefix without first solving a puzzle. 261 When the Responder decides to send the challenge notification in 262 response to a IKE_SA_INIT request, the notification includes three 263 fields: 265 1. Cookie - this is calculated the same as in RFC 7296. As in RFC 266 7296, the process of generating the cookie is not specified. 268 2. Algorithm, this is the identifier of a PRF algorithm, one of 269 those proposed by the Initiator in the SA payload. 271 3. Zero Bit Count. This is a number between 8 and 255 that 272 represents the length of the zero-bit run at the end of the 273 output of the PRF function calculated over the Keyed-Cookie 274 payload that the Initiator is to send. Since the mechanism is 275 supposed to be stateless for the Responder, the same value is 276 sent to all Initiators who are receiving this challenge. The 277 values 0 and 1-8 are explicitly excluded, because the value zero 278 is meaningless, and the values 1-8 create a puzzle that is too 279 easy to solve for it to make any difference in mitigating DDoS 280 attacks. 282 Upon receiving this challenge payload, the Initiator attempts to 283 calculate the PRF using different keys. When a key is found such 284 that the resulting PRF output has a sufficient number of trailing 285 zero bits, that result is sent to the Responder in a Keyed-Cookie 286 notification, as described in Section 3.1. 288 When receiving a request with a Keyed-Cookie, the Responder verifies 289 two things: 291 o That the cookie part is indeed valid. 293 o That the PRF of the transmitted cookie calculated with the 294 transmitted key has a sufficient number of trailing zero bits. 296 Example 1: Suppose the calculated cookie is 297 fdbcfa5a430d7201282358a2a034de0013cfe2ae (20 octets), the algorithm 298 is HMAC-SHA256, and the required number of zero bits is 18. After 299 successively trying a bunch of keys, the Initiator finds that the key 300 that is all-zero except for the last three bytes which are 02fc95 301 yields HMAC_SHA256(k, cookie) = 302 843ab73f35c5b431b1d8f80bedcd1cb9ef46832f799c1d4250a49f683c580000, 303 which has 19 trailing zero bits, so it is an acceptable solution. 305 Example 2: Same cookie, but this time the required number of zero 306 bits is 22. The first key to satisfy that requirement ends in 307 960cbb, which yields a hash with 23 trailing zero bits. Finding this 308 requires 9,833,659 invocations of the PRF. 310 +----------+--------------------------+----------+------------------+ 311 | key | Last 24 Hex PRF Digits | # 0-bits | Time To | 312 | | | | Calculate | 313 +----------+--------------------------+----------+------------------+ 314 | 00 | 0cbbbd1e105f5a177f9697d4 | 2 | 0.000 | 315 | 08 | 34cdedf89560f600aab93c68 | 3 | 0.000 | 316 | 0b | 6153a5131b879a904cd7fbe0 | 5 | 0.000 | 317 | 2b | 0098af3e9422aa40a6f7b140 | 6 | 0.000 | 318 | 0147 | c8bf4a65fc8b974046b97c00 | 10 | 0.001 | 319 | 06e2 | 541487a10cbdf3b21c382800 | 11 | 0.005 | 320 | 0828 | 48719bd62393fcf9bc172000 | 13 | 0.006 | 321 | 0204a7 | 3dce3414477c2364d5198000 | 15 | 0.186 | 322 | 185297 | c19385bb7b9566e5fdf00000 | 20 | 2.146 | 323 | 69dc34 | 1b61ecb347cb2e0cba200000 | 21 | 9.416 | 324 | 960cbb | e48274bfac2b7e1930800000 | 23 | 13.300 | 325 | 01597972 | 39a0141d0fe4b87aea000000 | 25 | 30.749 | 326 | 0b13cd9a | 00b97bb323d6d33350000000 | 28 | 247.914 | 327 | 37dc96e4 | 1e24babc92234aa3a0000000 | 29 | 1237.170 | 328 | 7a1a56d8 | c98f0061e380a49e00000000 | 33 | 2726.150 | 329 +----------+--------------------------+----------+------------------+ 331 Table 1: COOKIE=fdbcfa5a430d7201282358a2a034de0013cfe2ae 333 The figures above were obtained on a 2.4 GHz single core i5. Run 334 times can be halved or quartered with multi-core code, but would be 335 longer on mobile phone processors, even if those are multi-core as 336 well. With these figures I believe that 20 bits is a reasonable 337 choice for puzzle level difficulty for all Initiators, with 24 bits 338 acceptable for specific hosts/prefixes. 340 3.1. The Keyed-Cookie Notification 342 To be added 344 3.2. The Puzzle-Required Notification 346 To be added 348 4. Retention Periods for Half-Open SAs 350 As a UDP-based protocol, IKEv2 has to deal with packet loss through 351 retransmissions. Section 2.4 of RFC 7296 recommends "that messages 352 be retransmitted at least a dozen times over a period of at least 353 several minutes before giving up". Retransmission policies in 354 practice wait at least one or two seconds before retransmitting for 355 the first time. 357 Because of this, setting the timeout on a half-open SA too low will 358 cause it to expire whenever even one IKE_AUTH request packet is lost. 359 When not under attack, the half-open SA timeout SHOULD be set high 360 enough that the Initiator will have enough time to send multiple 361 retransmissions, minimizing the chance of transient network 362 congestion causing IKE failure. 364 When the system is under attack, as measured by the amount of half- 365 open SAs, it makes sense to reduce this lifetime. The Responder 366 should still allow enough time for the round-trip, enough time for 367 the Initiator to derive the Diffie-Hellman shared value, and enough 368 time to derive the IKE SA keys and the create the IKE_AUTH request. 369 Two seconds is probably as low a value as can realistically be used. 371 It could make sense to assign a shorter value to half-open SAs 372 originating from IP addresses or prefixes from which are considered 373 suspect because of multiple concurrent half-open SAs. 375 5. Rate Limiting 377 Even with DDoS, the attacker has only a limited amount of nodes 378 participating in the attack. By limiting the amount of half-open SAs 379 that are allowed to exist concurrently with each such node, the total 380 amount of half-open SAs is capped, as is the total amount of key 381 derivations that the Responder is forced to complete. 383 In IPv4 it makes sense to limit the number of half-open SAs based on 384 IP address. Most IPv4 nodes are either directly attached to the 385 Internet using a routable address or are hidden behind a NAT device 386 with a single IPv4 external address. IPv6 networks are currently a 387 rarity, so we can only speculate on what their wide deployment will 388 be like, but the current thinking is that ISP customers will be 389 assigned whole subnets, so we don't expect the kind of NAT deployment 390 that is common in IPv4. For this reason it makes sense to use a 391 64-bit prefix as the basis for rate limiting in IPv6. 393 The number of half-open SAs is easy to measure, but it is also 394 worthwhile to measure the number of failed IKE_AUTH exchanges. If 395 possible, both factors should be taken into account when deciding 396 which IP address or prefix is considered suspicious. 398 There are two ways to rate-limit a peer address or prefix: 400 1. Hard Limit - where the number of half-open SAs is capped, and any 401 further IKE_SA_INIT requests are rejected. 403 2. Soft Limit - where if a set number of half-open SAs exist for a 404 particular address or prefix, any IKE_SA_INIT request will 405 require solving a puzzle. 407 The advantage of the hard limit method is that it provides a hard cap 408 on the amount of half-open SAs that the attacker is able to create. 409 The downside is that it allows the attacker to block IKE initiation 410 from small parts of the Internet. For example, if a certain purveyor 411 of beverages resembling coffee provides Internet connectivity to its 412 customers through an IPv4 NAT device, a single malicious customer can 413 create enough half-open SAs to fill the quota for the NAT device 414 external IP address. Legitimate Initiators on the same network will 415 not be able to initiate IKE. 417 The advantage of a soft limit is that legitimate clients can always 418 connect. The disadvantage is that a sufficiently resourceful (in the 419 sense that they have a lot of resources) adversary can still 420 effectively DoS the Responder. 422 Regardless of the type of rate-limiting used, there is a huge 423 advantage in blocking the DoS attack using rate-limiting in that 424 legitimate clients who are away from the attacking nodes should not 425 be adversely affected by either the attack or by the measures used to 426 counteract it. 428 6. Plan for Defending a Responder 430 This section outlines a plan for defending a Responder from a DDoS 431 attack based on the techniques described earlier. The numbers given 432 here are not normative, and their purpose is to illustrate the 433 configurable parameters needed for defeating the DDoS attack. 435 Implementations may be deployed in different environments, so it is 436 RECOMMENDED that the parameters be settable. As an example, most 437 commercial products are required to undergo benchmarking where the 438 IKE SA establishment rate is measured. Benchmarking is 439 indistinguishable from a DoS attack and the defenses described in 440 this document may defeat the benchmark by causing exchanges to fail 441 or take a long time to complete. Parameters should be tunable to 442 allow for benchmarking (if only by turning DDoS protection off). 444 Since all countermeasures may cause delays and work on the 445 initiators, they SHOULD NOT be deployed unless an attack is likely to 446 be in progress. To minimize the burden imposed on Initiators, the 447 Responder should monitor incoming IKE requests, searching for two 448 things: 450 1. A general DDoS attack. Such an attack is indicated by a high 451 number of concurrent half-open SAs, a high rate of failed 452 IKE_AUTH exchanges, or a combination of both. For example, 453 consider a Responder that has 10,000 distinct peers of which at 454 peak 7,500 concurrently have VPN tunnels. At the start of peak 455 time, 600 peers might establish tunnels at any given minute, and 456 tunnel establishment (both IKE_SA_INIT and IKE_AUTH) takes 457 anywhere from 0.5 to 2 seconds. For this Responder, we expect 458 there to be less than 20 concurrent half-open SAs, so having 100 459 concurrent half-open SAs can be interpreted as an indication of 460 an attack. Similarly, IKE_AUTH request decryption failures 461 should never happen. Supposing the the tunnels are established 462 using EAP (see section 2.16 or RFC 7296), users enter the wrong 463 password about 20% of the time. So we'd expect 125 wrong 464 password failures a minute. If we get IKE_AUTH decryption 465 failures from multiple sources more than once per second, or EAP 466 failure more than 300 times per minute, that can also be an 467 indication of a DDoS attack. 469 2. An attack from a particular IP address or prefix. Such an attack 470 is indicated by an inordinate amount of half-open SAs from that 471 IP address or prefix, or an inordinate amount of IKE_AUTH 472 failures. A DDoS attack may be viewed as multiple such attacks. 473 If they are mitigated well enough, there will not be a need enact 474 countermeasures on all Initiators. Typical figures might be 5 475 concurrent half-open SAs, 1 decrypt failure, or 10 EAP failures 476 within a minute. 478 Note that using counter-measures against an attack from a particular 479 IP address may be enough to avoid the load on the half-open SA 480 database and the amount of failed IKE_AUTH exchanges to never exceed 481 the threshold of attack detection. This is a good thing as it 482 prevent Initiators that are not close to the attackers from being 483 affected. 485 When there is no general DDoS attack, it is suggested that no Cookie 486 or puzzles be used. At this point the only defensive measure is the 487 monitoring, and setting a soft limit per peer IP or prefix. The soft 488 limit can be set to 3-5, and the puzzle difficulty should be set to 489 such a level (number of zero-bits) that all legitimate clients can 490 handle it without degraded user experience. 492 As soon as any kind of attack is detected, either a lot of 493 initiations from multiple sources or a lot of initiations from a few 494 sources, it is best to begin by requiring stateless cookies from all 495 Initiators. This will force the attacker to use real source 496 addresses, and help avoid the need to impose a greater burden in the 497 form of cookies on the general population of initiators. This makes 498 the per-node or per-prefix soft limit more effective. 500 When Cookies are activated for all requests and the attacker is still 501 managing to consume too many resources, the Responder MAY increase 502 the difficulty of puzzles imposed on IKE_SA_INIT requests coming from 503 suspicious nodes/prefixes. It should still be doable by all 504 legitimate peers, but it can degrade experience, for example by 505 taking up to 10 seconds to calculate the cookie extension. 507 If the load on the Responder is still too great, and there are many 508 nodes causing multiple half-open SAs or IKE_AUTH failures, the 509 Responder MAY impose hard limits on those nodes. 511 If it turns out that the attack is very widespread and the hard caps 512 are not solving the issue, a puzzle MAY be imposed on all Initiators. 513 Note that this is the last step, and the Responder should avoid this 514 if possible. 516 6.1. Session Resumption 518 When the Responder is under attack, it MAY choose to prefer 519 previously authenticated peers who present a session resumption 520 [RFC5723] ticket. The Responder MAY require such Initiators to pass 521 a return routability check by including the COOKIE notification in 522 the IKE_SESSION_RESUME response message, as allowed by RFC 5723, Sec. 523 4.3.2. Note that the Responder SHOULD cache tickets for a short time 524 to reject reused tickets (Sec. 4.3.1), and therefore there should be 525 no issue of half-open SAs resulting from replayed IKE_SESSION_RESUME 526 messages 528 7. Operational Considerations 530 [This section needs a lot of expanding] 532 Not all Initiators support the puzzles, but all initiators are 533 supposed to support stateless cookies. If this notification is sent 534 to a non-supporting but legitimate initiator, the exchange will fail. 535 Responders are advised to first try to mitigate the DoS using 536 stateless cookies, even imposing them generally before resorting to 537 using puzzles. 539 The difficulty level should be set by balancing the requirement to 540 minimize the latency for legitimate initiators and making things 541 difficult for attackers. A good rule of thumb is for taking about 1 542 second to solve the puzzle. A typical initiator or bot-net member in 543 2014 can perform slightly less than a million hashes per second per 544 core, so setting the difficulty level to n=20 is a good compromise. 545 It should be noted that mobile initiators, especially phones are 546 considerably weaker than that. Implementations should allow 547 administrators to set the difficulty level, and/or be able to set the 548 difficulty level dynamically in response to load. 550 Initiators should set a maximum difficulty level beyond which they 551 won't try to solve the puzzle and log or display a failure message to 552 the administrator or user. 554 8. Using Puzzles in the Protocol 556 8.1. Puzzles in IKE_SA_INIT Exchange 558 IKE initiator indicates the desire to create new IKE SA by sending 559 IKE_SA_INIT request message. The message may optionally contain 560 COOKIE notification if this is a repeated request after the responder 561 asked initiator to return a cookie. 563 HDR, [N(COOKIE),] SA, KE, Ni, [V+][N+] --> 565 According to the plan, described in Section 6, IKE responder should 566 monitor incoming requests to detect whether it is under attack. If 567 the responder learns that (D)DoS attack is likely to be in progress, 568 then it either requests the initiator to return cookie or, if the 569 volume is so high, that puzzles need to be used for defense, it 570 requests the initiator to solve the puzzle. 572 The responder MAY choose to process some fraction of IKE_SA_INIT 573 requests without presenting a puzzle even being under attack to allow 574 legacy clients, that don't support puzzles, to have chances be 575 served. The decision whether to process any particular request must 576 be probabilistic, with the probability depending on the responder's 577 load (i.e. on the volume of the attack). Only those requests, that 578 contain COOKIE notification, must participate in this lottery. In 579 other words, the responder MUST first perform return routability 580 check before allowing any legacy client to be served if it is under 581 attack. See Section 8.1.3 for details. 583 8.1.1. Presenting Puzzle 585 If the responder takes a decision to use puzzles, then it includes 586 two notifications in its response message - the COOKIE notification 587 and the PUZZLE notification. The format of the PUZZLE notification 588 is described in Section 10.1. 590 <-- HDR, N(COOKIE), N(PUZZLE), [V+][N+] 592 The presence of these notifications in IKE_SA_INIT response message 593 indicates to the initiator that it should solve the puzzle to get 594 better chances to be served. 596 8.1.1.1. Selecting Puzzle Difficulty Level 598 The PUZZLE notification contains the difficulty level of the puzzle - 599 the minimum number of trailing zero bits that the result of PRF must 600 contain. In diverse environments it is next to impossible for the 601 responder to set any specific difficulty level that will result in 602 roughly the same amount of work for all initiators, because 603 computation power of different initiators may vary by the order of 604 magnitude, or even more. The responder may set difficulty level to 605 0, meaning that the initiator is requested to spend as much power to 606 solve puzzle, as it can afford. In this case no specific number of 607 trailing zero bits is required from the initiator, however the more 608 bits initiator is able to get, the higher chances it will have to be 609 served by the responder. In diverse environments it is RECOMMENDED 610 that the initiator sets difficulty level to 0. 612 If the responder sets non-zero difficulty level, then the level 613 should be determined by analyzing the volume of the attack. The 614 responder MAY set different difficulty levels to different requestd 615 depending on the IP address the request has come from. 617 8.1.1.2. Selecting Puzzle Algorithm 619 The PUZZLE notification also contains identificator of the algorithm, 620 that must be used by initiator in puzzle solution. 622 Cryptographic algorithm agility is considered an important feature 623 for modern protocols ([ALG-AGILITY]). This feature ensures that 624 protocol doesn't rely on a single build-in set of cryptographic 625 algorithms, but has a means to replace one set with another and 626 negotiate new set with the peer. IKEv2 fully supports cryptographic 627 algorithm agility for its core operations. 629 To support this feature in case of puzzles the algorithm, that is 630 used to compute puzzle, needs to be negotiated during IKE_SA_INIT 631 exchange. The negotiation is done as follows. The initial request 632 message sent by initiator contains SA payload with the list of 633 transforms the initiator supports and is willing to use in the IKE SA 634 being established. The responder parses received SA payload and 635 finds mutually supported set of transforms of type PRF. It selects 636 most preferred transform from this set and includes it into the 637 PUZZLE notification. There is no requirement that the PRF selected 638 for puzzles be the same, as the PRF that is negotiated later for the 639 use in core IKE SA crypto operations. If there are no mutually 640 supported PRFs, then negotiation will fail anyway and there is no 641 reason to return a puzzle. In this case the responder returns 642 NO_PROPOSAL_CHOSEN notification. Note that PRF is a mandatory 643 transform type for IKE SA (see Sections 3.3.2 and 3.3.3 of [RFC7296]) 644 and at least one transform of this type must always be present in SA 645 payload in IKE_SA_INIT exchange. 647 8.1.1.3. Generating Cookie 649 If responder supports puzzles then cookie should be computed in such 650 a manner, that the responder is able to learn some important 651 information from the sole cookie, when it is returned back by 652 initiator. In particular - the responder should be able to learn the 653 following information: 655 o Whether the puzzle was given to the initiator or only the cookie 656 was requested. 658 o The difficulty level of the puzzle given to the initiator. 660 o The number of consecutive puzzles given to the initiator. 662 o The amount of time the initiator spent to solve the puzzles. This 663 can be calculated if the cookie is timestamped. 665 This information helps the responder to make a decision whether to 666 serve this request or demand more work from the initiator. 668 One possible approach to get this information is to encode it in the 669 cookie. The format of such encoding is a local matter of responder, 670 as the cookie would remain an opaque blob to the initiator. If this 671 information is encoded in the cookie, then the responder MUST make it 672 integrity protected, so that any intended or accidental alteration of 673 this information in returned cookie is detectable. So, the cookie 674 would be generated as: 676 Cookie = | | 677 Hash(Ni | IPi | SPIi | | ) 679 Alternatively the responder may continue to generate cookie as 680 suggested in Section 2.6 of [RFC7296], but associate the additional 681 information, that would be stored locally, with the particular 682 version of the secret. In this case the responder should have 683 different secret for every combination of difficulty level and number 684 of consecutive puzzles, and should change the secrets periodically, 685 keeping a few previous versions, to be able to calculate how long ago 686 the cookie was generated. 688 The responder may also combine these approaches. This document 689 doesn't mandate how the responder learns this information from the 690 cookie. 692 8.1.2. Solving Puzzle and Returning the Solution 694 If initiator receives puzzle but it doesn't support puzzles, then it 695 will ignore PUZZLE notification as unrecognized status notification 696 (in accordance to Section 3.10.1 of [RFC7296]). The initiator also 697 MAY ignore puzzle if it is not willing to spend resources to solve 698 puzzle of requested difficulty, even if it supports puzzles. In both 699 cases the initiator acts as described in Section 2.6 of [RFC7296] - 700 it restarts the request and includes the received COOKIE notification 701 into it. The responder should be able to distinguish the situation 702 when it just requested a cookie from the situation when the puzzle 703 was given to the initiator, but the initiator for some reason ignored 704 it. 706 If the received message contains PUZZLE notification, but doesn't 707 contain cookie, then this message is malformed, because it requests 708 to solve the puzzle, but doesn't provide enough information to do it. 709 In this case the initiator SHOULD resend IKE_SA_INIT request. If 710 this situation repeats several times, then it means that something is 711 wrong and IKE SA cannot be established. 713 If initiator supports puzzles and is ready to deal with them, then it 714 tries to solve the given puzzle. After the puzzle is solved the 715 initiator restarts the request and returns the puzzle solution in a 716 new payload called Puzzle Solution payload (denoted as PS, see 717 Section 10.2) along with the received COOKIE notification back to the 718 responder. 720 HDR, N(COOKIE), [PS,] SA, KE, Ni, [V+][N+] --> 722 8.1.2.1. Computing Puzzle 724 General principals of constructing puzzles in IKEv2 are described in 725 Section 3. They can be summarized as follows: given unpredictable 726 string S and pseudo-random function PRF find the key K for that PRF 727 so that the result of PRF(K,S) has the specified number of trailing 728 zero bits. 730 In the IKE_SA_INIT exchange it is the cookie that plays the role of 731 unpredictable string S. In other words, in IKE_SA_INIT the task for 732 IKE initiator is to find the key K for the agreed upon PRF such that 733 the result of PRF(K,cookie) has sufficient number of trailing zero 734 bits. Only the content of the COOKIE notification is used in puzzle 735 calculation, i.e. the header of the Notification payload is not 736 included. 738 8.1.3. Analyzing Repeated Request 740 The received request must at least contain COOKIE notification. 741 Otherwise it is an initial request and it must be processed according 742 to Section 8.1. First, the cookie MUST be checked for validity. If 743 the cookie is invalid then the request is treated as initial and is 744 processed according to Section 8.1. If the cookie is valid then some 745 important information is learned from it or from local state based on 746 identifier of the cookie's secret (see Section 8.1.1.3 for details). 747 This information would allow the responder to sort out incoming 748 requests, giving more priority to those of them, which were created 749 spending more initiator's resources. 751 First, the responder determines if it requested only a cookie, or 752 presented a puzzle to the initiator. If no puzzle was given, then it 753 means that at the time the responder requested a cookie it didn't 754 detect the (D)DoS attack or the attack volume was low. In this case 755 the received request message must not contain the PS payload, and 756 this payload MUST be ignored if for any reason the message contains 757 it. Since no puzzle was given, the responder marks the request with 758 the lowest priority since the initiator spent a little resources 759 creating it. 761 If the responder learns from the cookie that the puzzle was given to 762 the initiator, then it looks for the PS payload to determine whether 763 its request to solve the puzzle was honored or not. If the incoming 764 message doesn't contain PS payload, then it means that the initiator 765 either doesn't support puzzles or doesn't want to deal with them. In 766 either case the request is marked with the lowest priority since the 767 initiator spent a little resources creating it. 769 If PS payload is found in the message then the responder MUST verify 770 the puzzle solution that it contains. The result must contain at 771 least the requested number of trailing zero bits (that is also 772 learned from the cookie, as well as the PRF algorithm used in puzzle 773 solution). If the result of the solution contais fewer bits, than 774 were requested, it means that initiator spent less resources, than 775 expected by the responder. This request is marked with the lowest 776 priority. 778 If the initiator provided the solution to the puzzle satisfying the 779 requested difficulty level, or if the responder didn't indicate any 780 particular difficulty level (by requesting zero level) and the 781 initiator was free to select any difficulty level it can afford, then 782 the priority of the request is calculated based on the following 783 considerations. 785 o The higher zero bits the initiator got, the higher priority its 786 request should achieve. 788 o The more consecutive puzzles the initiator solved (it must be 789 learned from the cookie), the higher priority its request should 790 achieve. 792 o The more time the initiator spent solving the puzzles (it must be 793 learned from the cookie), the higher priority its request should 794 achieve. 796 After the priority of the request is determined the final decision 797 whether to serve it or not is made. 799 8.1.4. Making Decision whether to Serve the Request 801 The responder decides what to do with the request based on its 802 priority and responder's current load. There are three possible 803 actions: 805 o Accept request. 807 o Reject request. 809 o Demand more work from initiator by giving it a new puzzle. 811 The responder SHOULD accept incoming request if its priority is high 812 - it means that the initiator spent quite a lot of resources. The 813 responder MAY also accept some of low-priority requests where the 814 initiators don't support puzzles. The percentage of accepted legacy 815 requests depends on the responder's current load. 817 If initiator solved the puzzle, but didn't spend much resources for 818 it (the selected puzzle difficulty level appeared to be low and the 819 initiator solved it quickly), then the responder SHOULD give it 820 another puzzle. The more puzzles the initiator solve the higher 821 would be its chances ro be served. 823 The details of how the responder takes decision on any particular 824 request are implementation dependant. The responder can collect all 825 the incoming requests for some short period of time, sort them out 826 based on their priority, calculate the number of alailable memory 827 slots for half-open IKE SAs and then serve that number of the 828 requests from the head of the sorted list. The rest of requests can 829 be either discarded or responded to with new puzzles. 831 Alternatively the responder may decide whether to accept every 832 incoming request with some kind of lottery, taking into account its 833 priority and the available resources. 835 8.2. Puzzles in IKE_AUTH Exchange 837 Once the IKE_SA_INIT exchange is completed, the responder has created 838 a state and is awaiting for the first message of the IKE_AUTH 839 exchange from initiator. At this point the initiator has already 840 passed return routability check and has proved that it has performed 841 some work to complete IKE_SA_INIT exchange. However, the initiator 842 is not yet authenticated and this fact allows malicious initiator to 843 conduct an attack, described in Section 2. Unlike DoS attack in 844 IKE_SA_INIT exchange, which is targeted on the responder's memory 845 resources, the goal of this attack is to exhaust responder's CPU 846 power. The attack is performed by sending the first IKE_AUTH message 847 containing garbage. This costs nothing to the initiator, but the 848 responder has to do relatively costly operations of computing the 849 Diffie-Hellman shared secret and deriving SK_* keys to be able to 850 verify authenticity of the message. If the responder doesn't save 851 the computed keys after unsuccessful verification of IKE_AUTH 852 message, then the attack can be repeated several times on the same 853 IKE SA. 855 The responder can use puzzles to make this attack more costly for the 856 initiator. The idea is that the responder includes puzzle in the 857 IKE_SA_INIT response message and the initiator includes puzzle 858 solution in the first IKE_AUTH request message outside the Encrypted 859 payload, so that the responder is able to verify puzzle solution 860 before computing Diffie-Hellman shared secret. The difficulty level 861 of the puzzle should be selected so, that the initiator would spend 862 substantially more time to solve the puzzle, than the responder to 863 compute the shared secret. 865 The responder should constantly monitor the amount of the half-open 866 IKE SA states, that receive IKE_AUTH messages, but cannot decrypt 867 them due to the integrity check failures. If the percentage of such 868 states is high and it takes an essential fraction of responder's 869 computing power to calculate keys for them, then the responder can 870 assume that it is under attack and can use puzzles to make it harder 871 for attackers. 873 8.2.1. Presenting Puzzle 875 The responder requests the initiator to solve a puzzle by including 876 the PUZZLE notification in the IKE_SA_INIT response message. The 877 responder MUST NOT use puzzles in the IKE_AUTH exchange unless the 878 puzzle has been previously presented and solved in the preceeding 879 IKE_SA_INIT exchange. 881 <-- HDR, SA, KE, Nr, N(PUZZLE), [V+][N+] 883 8.2.1.1. Selecting Puzzle Difficulty Level 885 The difficulty level of the puzzle in IKE_AUTH should be chosen so, 886 that the initiator would spend more time to solve the puzzle, than 887 the responder to compute Diffie-Hellman shared secret and the keys, 888 needed to decrypt and verify IKE_AUTH message. On the other hand, 889 the difficulty level should not be too high, otherwise the legitimate 890 clients would experience additional delay while establishing IKE SA. 892 Note, that since puzzles in the IKE_AUTH exchange are only allowed to 893 be used if they were used in the preceeding IKE_SA_INIT exchange, the 894 responder would be able to estimate the computing power of the 895 initiator and to select the difficulty level accordingly. Unlike 896 puzzles in IKE_SA_INIT, the requested difficulty level for IKE_AUTH 897 puzzles MUST NOT be zero. In other words, the responder must always 898 set specific difficulty level and must not let the initiator to 899 choose it on its own. 901 8.2.1.2. Selecting Puzzle Algorithm 903 The algorithm for the puzzle is selected as described in 904 Section 8.1.1.2. There is no requirement, that the algorithm for the 905 puzzle in the IKE_SA INIT exchange be the same, as the algorithm for 906 the puzzle in IKE_AUTH exchange, however it is expected that in most 907 cases they will be the same. 909 8.2.2. Solving Puzzle and Returning the Solution 911 If the IKE_SA_INIT response message contains the PUZZLE notification 912 and the initiator supports puzzles, it MUST solve the puzzle. Puzzle 913 construction on the IKE_AUTH exchange differs from the puzzle in the 914 IKE_SA_INIT exchange and is described in Section 8.2.2.1. Once the 915 puzzle is solved the initiator sends the IKE_AUTH request message, 916 containing the Puzzle Solution payload. 918 HDR, PS, SK {IDi, [CERT,] [CERTREQ,] 919 [IDr,] AUTH, SA, TSi, TSr} --> 921 The Puzzle Solution payload is placed outside the Encrypted payload, 922 so that the responder would be able to verify the puzzle before 923 calculating the Diffie-Hellman shared secret and the SK_* keys. 925 If IKE Fragmentation is used, then the PS payload MUST be present 926 only in the first IKE Fragment message, in accordance with the 927 Section 2.5.3 of [RFC7383]. Note, that calculation of the puzzle in 928 the IKE_AUTH exchange doesn't depend on the content of the IKE_AUTH 929 message (see Section 8.2.2.1). Thus the responder has to solve the 930 puzzle only once and the solution is valid for both unfragmented and 931 fragmented IKE messages. 933 8.2.2.1. Computing Puzzle 935 The puzzle in the IKE_AUTH exchange is computed differently, than in 936 the IKE_SA_INIT exchange (see Section 8.1.2.1). The general 937 principle is the same, the difference is in constructing of the 938 string S. Unlike the IKE_SA_INIT exchange, where S is the cookie, in 939 the IKE_AUTH exchange S is a concatenation of Nr and SPIr. In other 940 words, the task for IKE initiator is to find the key K for the agreed 941 upon PRF such that the result of PRF(K,Nr | SPIr) has sufficient 942 number of trailing zero bits. Nr is a nonce used by the responder in 943 IKE_SA_INIT exchange, stripped of any headers. SPIr is IKE responder 944 SPI in the SA being established. 946 8.2.3. Receiving Puzzle Solution 948 If the responder requested the initiator to solve puzzle in the 949 IKE_AUTH exchange, then it SHOULD silently discard all the IKE_AUTH 950 request messages without the Puzzle Solution payload. 952 Once the message containing solution for the puzzle is received the 953 responder SHOULD verify the solution before performing computationly 954 intensive operations - computing the Diffie-Hellman shared secret and 955 the SK_* keys. The responder MUST silently discard the received 956 message if the puzzle solution is not correct. If the puzzle is 957 successfully verified and the SK_* key are calculated, but the 958 message authenticity check fails, the responder SHOULD save the 959 calculated keys in the IKE SA state while waiting for the 960 retransmissions from the initiator. In this case the responder may 961 skip verification of the puzzle solution and ignore the Puzzle 962 Solution payload in the retransmitted messages. 964 If the initiator uses IKE Fragmentation, then it is possible, that 965 due to packets loss and/or reordering the responder would receive 966 non-first IKE Fragment messages before receiving the first one, 967 containing the PS payload. In this case the responder MAY choose to 968 keep the received fragments until the first fragment containing the 969 solution to the puzzle is received. However in this case the 970 responder SHOULD NOT try to verify authenticity (that would require 971 the calculation of the SK_* keys) untill the first fragment with the 972 PS payload is received and the solution to the puzzle is verified. 973 After successful verification of the puzzle the responder would 974 calculate the SK_* key and verify authenticity of the collected 975 fragments. 977 9. DoS Protection after IKE SA is created 979 Once IKE SA is created there is usually no much traffic over it. In 980 most cases this traffic consists of exchanges aimed to create 981 additional Child SAs, rekey or delete them and check the liveness of 982 the peer. With a typical setup and typical Child SA lifetimes there 983 must be no more than a few such exchanges in a minute, often less. 984 Some of these exchanges require relatively little resources (like 985 liveness check), while others may be resourse consuming (like 986 creating or rekeying Child SA with Diffie-Hellman exchange). 988 Since any endpoint can initiate new exchange, there is a possibility 989 that a peer would initiate too many exchanges, that could exhaust 990 host resources. For example the peer can perform endless continuous 991 Child SA rekeying or create overwhelming number of Child SAs with the 992 same Traffic Selectors etc. Such behaviour may be caused by buggy 993 implementation, misconfiguration or be intentional. The latter 994 becomes more real threat if the peer uses NULL Authentication, 995 described in [NULL-AUTH]. In this case the peer remains anonymous, 996 that allow it to escape any resposibility for its actions. 998 The following recommendations for defense against possible DoS 999 attacks after IKE SA is established are mostly intended for 1000 implementations that allow unauthenticated IKE sessions. However 1001 they may also be useful in other cases. 1003 o If the IKEv2 window size is greater than one, then the peer could 1004 initiate multiple simultaneous exchanges, that would potentially 1005 increase host resourse consumption. Since currently there is no 1006 way in IKEv2 to decrease window size once it was increased (see 1007 Section 2.3 of [RFC7296]), the window size cannot be dynamically 1008 adjusted depending on the load. For that reason if is NOT 1009 RECOMMENDED to ever increase IKEv2 window size above its default 1010 value of one if the peer uses NULL Authentication. 1012 o If the peer initiates requests to rekey IKE SA or Child SA too 1013 often, implementations can respond to some of these requests with 1014 the TEMPORARY_FAILURE notification, indicating that the request 1015 should be retried after some period of time. 1017 o If the peer creates too many Child SA with the same or overlapping 1018 Traffic Selectors, implementations can respond with the 1019 NO_ADDITIONAL_SAS notification. 1021 o If the peer initiates too many exchanges of any kind, 1022 implementations can introduce artificial delay before responding 1023 to request messages. This delay would decrease the rate the 1024 implementation need to process requests from any particular peer, 1025 making possible to process requests from the others. The delay 1026 should not be too long not to cause IKE SA to be deleted on the 1027 other end due to timeout. It is believed that a few seconds is 1028 enough. Note, that if the responder receives retransmissions of 1029 the request message during the delay period, the retransmitted 1030 messages should be silently discarded. 1032 o If these counter-measures are inefficient, implementations can 1033 delete IKE SA with an offending peer by sending Delete Payload. 1035 10. Payload Formats 1037 10.1. PUZZLE Notification 1039 The PUZZLE notification is used by IKE responder to inform the 1040 initiator about the necessity to solve the puzzle. It contains the 1041 difficulty level of the puzzle and the PRF the initiator should use. 1043 1 2 3 1044 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 1045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1046 | Next Payload |C| RESERVED | Payload Length | 1047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1048 |Protocol ID(=0)| SPI Size (=0) | Notify Message Type | 1049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1050 | PRF | Difficulty | 1051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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. 1071 This notification contains no data. 1073 10.2. Puzzle Solution Payload 1075 The solution to the puzzle is returned back to the responder in a 1076 dedicated payload, called Puzzle Solution payload and denoted as PS 1077 in this document. 1079 1 2 3 1080 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 1081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1082 | Next Payload |C| RESERVED | Payload Length | 1083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1084 | | 1085 ~ Puzzle Solution Data ~ 1086 | | 1087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1089 o Puzzle Solution Data (variable length) - Contains the solution to 1090 the puzzle - i.e. the key for the PRF. This field MUST NOT be 1091 empty. If the selected PRF has a fixed-size key, then the size of 1092 the Puzzle Solution Data MUST be equal to the size of the key. If 1093 the PRF agreed upon accepts keys of any size, then then the size 1094 of the Puzzle Solution Data MUST be between 1 octet and the 1095 preferred key length of the PRF (inclusive). 1097 The payload type for the Puzzle Solution payload is . 1099 11. Security Considerations 1101 To be added. 1103 12. IANA Considerations 1105 This document defines a new payload in the "IKEv2 Payload Types" 1106 registry: 1108 Puzzle Solution PS 1110 This document also defines a new Notify Message Type in the "IKEv2 1111 Notify Message Types - Status Types" registry: 1113 PUZZLE 1115 13. References 1117 13.1. Normative References 1119 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1120 Requirement Levels", BCP 14, RFC 2119, March 1997. 1122 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 1123 Kivinen, "Internet Key Exchange Protocol Version 2 1124 (IKEv2)", STD 79, RFC 7296, October 2014. 1126 [RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2 1127 (IKEv2) Message Fragmentation", RFC 7383, November 2014. 1129 [IKEV2-IANA] 1130 "Internet Key Exchange Version 2 (IKEv2) Parameters", 1131 . 1133 13.2. Informative References 1135 [RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange 1136 Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, 1137 January 2010. 1139 [bitcoins] 1140 Nakamoto, S., "Bitcoin: A Peer-to-Peer Electronic Cash 1141 System", October 2008, . 1143 [ALG-AGILITY] 1144 Housley, R., "Guidelines for Cryptographic Algorithm 1145 Agility", draft-iab-crypto-alg-agility-02 (work in 1146 progress), December 2014. 1148 [NULL-AUTH] 1149 Smyslov, V. and P. Wouters, "The NULL Authentication 1150 Method in IKEv2 Protocol", draft-ietf-ipsecme-ikev2-null- 1151 auth-02 (work in progress), January 2015. 1153 Authors' Addresses 1155 Yoav Nir 1156 Check Point Software Technologies Ltd. 1157 5 Hasolelim st. 1158 Tel Aviv 6789735 1159 Israel 1161 EMail: ynir.ietf@gmail.com 1163 Valery Smyslov 1164 ELVIS-PLUS 1165 PO Box 81 1166 Moscow (Zelenograd) 124460 1167 Russian Federation 1169 Phone: +7 495 276 0211 1170 EMail: svan@elvis.ru