idnits 2.17.00 (12 Aug 2021) /tmp/idnits41248/draft-ietf-ipsecme-ddos-protection-00.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 date (October 27, 2014) is 2763 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). 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 October 27, 2014 5 Expires: April 30, 2015 7 Protecting Internet Key Exchange (IKE) Implementations from Distributed 8 Denial of Service Attacks 9 draft-ietf-ipsecme-ddos-protection-00 11 Abstract 13 This document recommends implementation and configuration best 14 practices for Internet-connected IPsec Responders, to allow them to 15 resist Denial of Service and Distributed Denial of Service attacks. 16 Additionally, the document introduces a new mechanism called "Client 17 Puzzles" that help accomplish this task. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 30, 2015. 36 Copyright Notice 38 Copyright (c) 2014 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 55 2. The Vulnerability . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Puzzles . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 4. Retention Periods for Half-Open SAs . . . . . . . . . . . . . 7 58 5. Rate Limiting . . . . . . . . . . . . . . . . . . . . . . . . 8 59 6. Plan for Defending a Responder . . . . . . . . . . . . . . . 9 60 7. Operational Considerations . . . . . . . . . . . . . . . . . 11 61 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 62 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 63 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 64 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 65 10.2. Informative References . . . . . . . . . . . . . . . . . 12 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 68 1. Introduction 70 The IKE_SA_INIT Exchange described in section 1.2 of [RFC7296] 71 involves the Initiator sending a single message. The Responder 72 replies with a single message and also allocates memory for a 73 structure called a half-open IKE SA (Security Association). This 74 half-open SA is later authenticated in the IKE_AUTH Exchange, but if 75 that IKE_AUTH request never comes, the half-open SA is kept for an 76 unspecified amount of time. Depending on the algorithms used and 77 implementation, such a half-open SA will use from around 100 bytes to 78 several thousands bytes of memory. 80 This creates an easy attack vector against an Internet Key Exchange 81 (IKE) Responder. Generating the Initial request is cheap, and 82 sending multiple such requests can either cause the Responder to 83 allocate too much resources and fail, or else if resource allocation 84 is somehow throttled, legitimate Initiators would also be prevented 85 from setting up IKE SAs. 87 An obvious defense, which is described in Section 5, is limiting the 88 number of half-open SAs opened by a single peer. However, since all 89 that is required is a single packet, an attacker can use multiple 90 spoofed source IP addresses. 92 Section 2.6 of RFC 7296 offers a mechanism to mitigate this DoS 93 attack: the stateless cookie. When the server is under load, the 94 Responder responds to the Initial request with a calculated 95 "stateless cookie" - a value that can be re-calculated based on 96 values in the Initial request without storing Responder-side state. 97 The Initiator is expected to repeat the Initial request, this time 98 including the stateless cookie. 100 Attackers that have multiple source IP addresses with return 101 routability, such as bot-nets can fill up a half-open SA table 102 anyway. The cookie mechanism limits the amount of allocated state to 103 the size of the bot-net, multiplied by the number of half-open SAs 104 allowed for one peer address, multiplied by the amount of state 105 allocated for each half-open SA. With typical values this can easily 106 reach hundreds of megabytes. 108 The mechanism described in Section 3 adds a proof of work for the 109 Initiator, by calculating a pre-image for a partial hash value. This 110 sets an upper bound, determined by the attacker's CPU to the number 111 of negotiations it can initiate in a unit of time. 113 1.1. Conventions Used in This Document 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in [RFC2119]. 119 2. The Vulnerability 121 If we break down what a responder has to do during an initial 122 exchange, there are three stages: 124 1. When the Initial request arrives, the responder: 126 * Generates or re-uses a D-H private part. 127 * Generates a responder SPI. 128 * Stores the private part and peer public part in a half-open SA 129 database. 130 2. When the Authentication request arrives, the responder: 132 * Derives the keys from the half-open SA. 133 * Decrypts the request. 134 3. If the Authentication request decrypts properly: 136 * Validates the certificate chain (if present) in the auth 137 request. 139 Yes, there's a stage 4 where the responder actually creates Child 140 SAs, but when talking about (D)DoS, we never get to this stage. 142 Stage #1 is pretty light on CPU power, but requires some storage, and 143 it's very light for the initiator as well. Stage #2 includes 144 private-key operations, so it's much heavier CPU-wise, but it 145 releases the storage allocated in stage #1. Stage #3 includes a 146 public key operation, and possibly many of them. 148 To attack such a server, an attacker can attempt to either exhaust 149 memory or to exhaust CPU. Without any protection, the most efficient 150 attack is to send multiple Initial requests and exhaust memory. This 151 should be easy because those Initial requests are cheap. 153 There are obvious ways for the responder to protect itself even 154 without changes to the protocol. It can reduce the time that an 155 entry remains in the half-open SA database, and it can limit the 156 amount of concurrent half-open SAs from a particular address or 157 prefix. The attacker can overcome this by using spoofed source 158 addresses. 160 The stateless cookie mechanism from section 2.6 of RFC 7296 prevents 161 an attack with spoofed source addresses. This doesn't solve the 162 issue, but it makes the limiting of half-open SAs by address or 163 prefix work. Puzzles do the same thing only more of it. They make 164 it harder for an attacker to reach the goal of getting a half-open 165 SA. They don't have to be so hard that an attacker can't afford to 166 solve them - it's enough that they increase the cost of a half-open 167 SAs for the attacker. 169 Reducing the amount of time an abandoned half-open SA is kept attacks 170 the issue from the other side. It reduces the value the attacker 171 gets from managing to create a half-open SA. So if a half-open SA 172 takes 1 KB and it's kept for 1 minute and the capacity is 60,000 173 half-open SAs, an attacker would need to create 1,000 half-open SAs 174 per second. Reduce the retention time to 3 seconds, and the attacker 175 needs to create 20,000 half-open SAs per second. Make each of those 176 more expensive by introducing a puzzle, and you're likely to thwart 177 an exhaustion attack against responder memory. 179 At this point, filling up the half-open SA database in no longer the 180 most efficient DoS attack. The attacker has two ways to do better: 182 1. Go back to spoofed addresses and try to overwhelm the CPU that 183 deals with generating cookies, or 184 2. Take the attack to the next level by also sending an 185 Authentication request. 187 I don't think the first thing is something we can deal with at the 188 IKE level. It's probably better left to Intrusion Prevention System 189 (IPS) technology. 191 Sending an Authentication request is surprisingly cheap. It requires 192 a proper IKE header with the correct IKE SPIs, and it requires a 193 single encrypted payload. The content of the payload might as well 194 be junk. The responder has to perform the relatively expensive key 195 derivation, only to find that the Authentication request does not 196 decrypt. Depending on the responder implementation, this can be 197 repeated with the same half-open SA (if the responder does not delete 198 the half-open SA following an unsuccessful decryption - see 199 discussion in Section 4). 201 Here too, the number of half-open SAs that the attacker can achieve 202 is crucial, because each one of them allows the attacker to waste 203 some CPU time. So making it hard to make many half-open SAs is 204 important. 206 A strategy against DDoS has to rely on at least 4 components: 208 1. Hardening the half-open SA database by reducing retention time. 209 2. Hardening the half-open SA database by rate-limiting single IPs/ 210 prefixes. 211 3. Guidance on what to do when an Authentication request fails to 212 decrypt. 213 4. Increasing cost of half-open SA up to what is tolerable for 214 legitimate clients. 216 Puzzles have their place as part of #4. 218 3. Puzzles 220 The puzzle introduced here extends the cookie mechanism from RFC 221 7296. It is loosely based on the proof-of-work technique used in 222 BitCoins ([bitcoins]). Future versions of this document will have 223 the exact bit structure of the notification payloads, but for now, I 224 will only describe the semantics of the content. 226 A puzzle is sent to the Initiator in two cases: 228 o The Responder is so overloaded, than no half-open SAs are allowed 229 to be created without the puzzle, or 230 o The Responder is not too loaded, but the rate-limiting in 231 Section 5 prevents half-open SAs from being created with this 232 particular peer address or prefix without first solving a puzzle. 234 When the Responder decides to send the challenge notification in 235 response to a IKE_SA_INIT request, the notification includes two 236 fields: 238 1. Cookie - this is calculated the same as in RFC 7296. As in RFC 239 7296, the process of generating the cookie is not specified, but 240 this specification does assume that it is fixed-length, meaning 241 that all cookies produced by a particular responder are of the 242 same length. 243 2. Zero Bit Count. This is a number between 8 and 255 that 244 represents the length of the zero-bit run at the end of the 245 SHA-256 hash of the Cookie payload that the Initiator is to send. 246 Since the mechanism is supposed to be stateless for the 247 Responder, the same value is sent to all Initiators who are 248 receiving this challenge. The values 0 and 1-8 are explicitly 249 excluded, because the value zero is meaningless, and the values 250 1-8 create a puzzle that is too easy to solve to make any 251 difference in mitigating DDoS attacks. 253 Upon receiving this challenge payload, the Initiator attempts to 254 append different strings to the Cookie field from the challenge, and 255 calculates the SHA-256 hash of the result. When a string is found 256 such that the resulting hash has a sufficient number of trailing zero 257 bits, that result is sent to the Responder in a Cookie notification, 258 similar to what is described in RFC 7296. The difference is that the 259 string in this Cookie notification is longer than the one 260 transmitted. 262 When receiving a request with an extended Cookie, the Responder 263 verifies two things: 265 o That the first bits of the transmitted cookie are indeed valid. 266 o That the hash of the transmitted cookie has a sufficient number of 267 trailing zero bits. 269 Example 1: Suppose the calculated cookie is 270 fdbcfa5a430d7201282358a2a034de0013cfe2ae (20 octets) and the required 271 number of zero bits is 16. After successively trying a bunch of 272 strings, the Initiator finds out that appending three octets: 022b3d 273 yields a 23-octet string whose SHA-256 hash is 274 3b4bdf201105e059e09f65219021738b8f6a148896b2e1be2fdc726aeb6e0000. 275 That has 17 trailing zero bits, so it is an acceptable cookie. 277 Example 2: Same cookie, but this time the required number of zero 278 bits is 22. The first string to satisfy that requirement is 5c2880, 279 which yields a hash with 23 trailing zero bits. Finding this 280 requires 6,105,472 hashes. 282 +--------------+--------------------------+---------+---------------+ 283 | Appended | Last 24 Hex Hash Digits | # | Time To | 284 | String | | 0-bits | Calculate | 285 +--------------+--------------------------+---------+---------------+ 286 | 04 | 2817ae10f20f4e0b0739f5cc | 2 | 0.000 | 287 | 06 | e540cf315fff88c1c5f362a8 | 3 | 0.000 | 288 | 0d | 8c459376268f747d7ed40da0 | 5 | 0.000 | 289 | 1c | 398c49be1babe50576cdae40 | 6 | 0.000 | 290 | 00f0 | 3f523ad7c0e00252c51ad980 | 7 | 0.000 | 291 | 0182 | e284296e2ffffa256bdfa800 | 11 | 0.000 | 292 | 235c | 7dc74302dc8bd695821ab000 | 12 | 0.006 | 293 | 7186 | a4411c3df3661eff1d574000 | 14 | 0.019 | 294 | d836 | 498bcd04ab1ae0c2c3a08000 | 15 | 0.036 | 295 | 022b3d | 96b2e1be2fdc726aeb6e0000 | 17 | 0.136 | 296 | 0aa679 | 620f48af85428996c1f00000 | 20 | 0.512 | 297 | 4ffbad | f9ba0ece854cd0fa88e00000 | 21 | 3.602 | 298 | 5c2880 | d44e6467d8fc37723d800000 | 23 | 4.143 | 299 | cdafe1 | 0d4058660c3e67be62000000 | 25 | 9.245 | 300 | 022bffc8 | 5f2d874764a71e2948000000 | 27 | 36.169 | 301 | 181ac92a | c3b5449fa1019b0580000000 | 31 | 255.076 | 302 | a987978d | 95a5673968a9b37a00000000 | 33 | 1309.519 | 303 +--------------+--------------------------+---------+---------------+ 305 Table 1: COOKIE=fdbcfa5a430d7201282358a2a034de0013cfe2ae 307 The figures above were obtained on a 2.4 GHz single core i5. Run 308 times can be halved or quartered with multi-core code, but would be 309 longer on mobile phone processors, even if those are multi-core as 310 well. With these figures I believe that 20 bits is a reasonable 311 choice for puzzle level difficulty for all Initiators, with 24 bits 312 acceptable for specific hosts/prefixes. 314 4. Retention Periods for Half-Open SAs 316 As a UDP-based protocol, IKEv2 has to deal with packet loss through 317 retransmissions. Section 2.4 of RFC 7296 recommends "that messages 318 be retransmitted at least a dozen times over a period of at least 319 several minutes before giving up". Retransmission policies in 320 practice wait at least one or two seconds before retransmitting for 321 the first time. 323 Because of this, setting the timeout on a half-open SA too low will 324 cause it to expire whenever even one IKE_AUTH request packet is lost. 325 When not under attack, the half-open SA timeout SHOULD be set high 326 enough that the Initiator will have enough time to send multiple 327 retransmissions, minimizing the chance of transient network 328 congestion causing IKE failure. 330 When the system is under attack, as measured by the amount of half- 331 open SAs, it makes sense to reduce this lifetime. The Responder 332 should still allow enough time for the round-trip, enough time for 333 the Initiator to derive the Diffie-Hellman shared value, and enough 334 time to derive the IKE SA keys and the create the IKE_AUTH request. 335 Two seconds is probably as low a value as can realistically be used. 337 It could make sense to assign a shorter value to half-open SAs 338 originating from IP addresses or prefixes from which are considered 339 suspect because of multiple concurrent half-open SAs. 341 5. Rate Limiting 343 Even with DDoS, the attacker has only a limited amount of nodes 344 participating in the attack. By limiting the amount of half-open SAs 345 that are allowed to exist concurrently with each such node, the total 346 amount of half-open SAs is capped, as is the total amount of key 347 derivations that the Responder is forced to complete. 349 In IPv4 it makes sense to limit the number of half-open SAs based on 350 IP address. Most IPv4 nodes are either directly attached to the 351 Internet using a routable address or are hidden behind a NAT device 352 with a single IPv4 external address. IPv6 networks are currently a 353 rarity, so we can only speculate on what their wide deployment will 354 be like, but the current thinking is that ISP customers will be 355 assigned whole subnets, so we don't expect the kind of NAT deployment 356 that is common in IPv4. For this reason it makes sense to use a 357 64-bit prefix as the basis for rate limiting in IPv6. 359 The number of half-open SAs is easy to measure, but it is also 360 worthwhile to measure the number of failed IKE_AUTH exchanges. If 361 possible, both factors should be taken into account when deciding 362 which IP address or prefix is considered suspicious. 364 There are two ways to rate-limit a peer address or prefix: 366 1. Hard Limit - where the number of half-open SAs is capped, and any 367 further IKE_SA_INIT requests are rejected. 368 2. Soft Limit - where if a set number of half-open SAs exist for a 369 particular address or prefix, any IKE_SA_INIT request will 370 require solving a puzzle. 372 The advantage of the hard limit method is that it provides a hard cap 373 on the amount of half-open SAs that the attacker is able to create. 374 The downside is that it allows the attacker to block IKE initiation 375 from small parts of the Internet. For example, if a certain purveyor 376 of beverages resembling coffee provides Internet connectivity to its 377 customers through an IPv4 NAT device, a single malicious customer can 378 create enough half-open SAs to fill the quota for the NAT device 379 external IP address. Legitimate Initiators on the same network will 380 not be able to initiate IKE. 382 The advantage of a soft limit is that legitimate clients can always 383 connect. The disadvantage is that a sufficiently resourceful (in the 384 sense that they have a lot of resources) adversary can still 385 effectively DoS the Responder. 387 Regardless of the type of rate-limiting used, there is a huge 388 advantage in blocking the DoS attack using rate-limiting in that 389 legitimate clients who are away from the attacking nodes should not 390 be adversely affected by either the attack or by the measures used to 391 counteract it. 393 6. Plan for Defending a Responder 395 This section outlines a plan for defending a Responder from a DDoS 396 attack based on the techniques described earlier. The numbers given 397 here are not normative, and their purpose is to illustrate the 398 configurable parameters needed for defeating the DDoS attack. 400 Implementations may be deployed in different environments, so it is 401 RECOMMENDED that the parameters be settable. As an example, most 402 commercial products are required to undergo benchmarking where the 403 IKE SA establishment rate is measured. Benchmarking is 404 indistinguishable from a DoS attack and the defenses described in 405 this document may defeat the benchmark by causing exchanges to fail 406 or take a long time to complete. Parameters should be tunable to 407 allow for benchmarking (if only by turning DDoS protection off). 409 Since all countermeasures may cause delays and work on the 410 initiators, they SHOULD NOT be deployed unless an attack is likely to 411 be in progress. To minimize the burden imposed on Initiators, the 412 Responder should monitor incoming IKE requests, searching for two 413 things: 415 1. A general DDoS attack. Such an attack is indicated by a high 416 number of concurrent half-open SAs, a high rate of failed 417 IKE_AUTH exchanges, or a combination of both. For example, 418 consider a Responder that has 10,000 distinct peers of which at 419 peak 7,500 concurrently have VPN tunnels. At the start of peak 420 time, 600 peers might establish tunnels at any given minute, and 421 tunnel establishment (both IKE_SA_INIT and IKE_AUTH) takes 422 anywhere from 0.5 to 2 seconds. For this Responder, we expect 423 there to be less than 20 concurrent half-open SAs, so having 100 424 concurrent half-open SAs can be interpreted as an indication of 425 an attack. Similarly, IKE_AUTH request decryption failures 426 should never happen. Supposing the the tunnels are established 427 using EAP (see section 2.16 or RFC 7296), users enter the wrong 428 password about 20% of the time. So we'd expect 125 wrong 429 password failures a minute. If we get IKE_AUTH decryption 430 failures from multiple sources more than once per second, or EAP 431 failure more than 300 times per minute, that can also be an 432 indication of a DDoS attack. 433 2. An attack from a particular IP address or prefix. Such an attack 434 is indicated by an inordinate amount of half-open SAs from that 435 IP address or prefix, or an inordinate amount of IKE_AUTH 436 failures. A DDoS attack may be viewed as multiple such attacks. 437 If they are mitigated well enough, there will not be a need enact 438 countermeasures on all Initiators. Typical figures might be 5 439 concurrent half-open SAs, 1 decrypt failure, or 10 EAP failures 440 within a minute. 442 Note that using counter-measures against an attack from a particular 443 IP address may be enough to avoid the load on the half-open SA 444 database and the amount of failed IKE_AUTH exchanges to never exceed 445 the threshold of attack detection. This is a good thing as it 446 prevent Initiators that are not close to the attackers from being 447 affected. 449 When there is no general DDoS attack, it is suggested that no Cookie 450 or puzzles be used. At this point the only defensive measure is the 451 monitoring, and setting a soft limit per peer IP or prefix. The soft 452 limit can be set to 3-5, and the puzzle difficulty should be set to 453 such a level (number of zero-bits) that all legitimate clients can 454 handle it without degraded user experience. 456 As soon as any kind of attack is detected, either a lot of 457 initiations from multiple sources or a lot of initiations from a few 458 sources, it is best to begin by requiring stateless cookies from all 459 Initiators. This will force the attacker to use real source 460 addresses, and help avoid the need to impose a greater burden in the 461 form of cookies on the general population of initiators. This makes 462 the per-node or per-prefix soft limit more effective. 464 When Cookies are activated for all requests and the attacker is still 465 managing to consume too many resources, the Responder MAY increase 466 the difficulty of puzzles imposed on IKE_SA_INIT requests coming from 467 suspicious nodes/prefixes. It should still be doable by all 468 legitimate peers, but it can degrade experience, for example by 469 taking up to 10 seconds to calculate the cookie extension. 471 If the load on the Responder is still too great, and there are many 472 nodes causing multiple half-open SAs or IKE_AUTH failures, the 473 Responder MAY impose hard limits on those nodes. 475 If it turns out that the attack is very widespread and the hard caps 476 are not solving the issue, a puzzle MAY be imposed on all Initiators. 477 Note that this is the last step, and the Responder should avoid this 478 if possible. 480 7. Operational Considerations 482 [This section needs a lot of expanding] 484 Not all Initiators support the puzzles, but all initiators are 485 supposed to support stateless cookies. If this notification is sent 486 to a non-supporting but legitimate initiator, the exchange will fail. 487 Responders are advised to first try to mitigate the DoS using 488 stateless cookies, even imposing them generally before resorting to 489 using puzzles. 491 The difficulty level should be set by balancing the requirement to 492 minimize the latency for legitimate initiators and making things 493 difficult for attackers. A good rule of thumb is for taking about 1 494 second to solve the puzzle. A typical initiator or bot-net member in 495 2014 can perform slightly less than a million hashes per second per 496 core, so setting the difficulty level to n=20 is a good compromise. 497 It should be noted that mobile initiators, especially phones are 498 considerably weaker than that. Implementations should allow 499 administrators to set the difficulty level, and/or be able to set the 500 difficulty level dynamically in response to load. 502 Initiators should set a maximum difficulty level beyond which they 503 won't try to solve the puzzle and log or display a failure message to 504 the administrator or user. 506 8. Security Considerations 508 To be added. 510 9. IANA Considerations 512 IANA is requested to assign a notify message type from the status 513 types range (16430-40959) of the "IKEv2 Notify Message Types - Status 514 Types" registry with name "PUZZLE". 516 10. References 518 10.1. Normative References 520 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 521 Requirement Levels", BCP 14, RFC 2119, March 1997. 523 [RFC7296] Kivinen, T., Kaufman, C., Hoffman, P., Nir, Y., and P. 524 Eronen, "Internet Key Exchange Protocol Version 2 525 (IKEv2)", RFC 7296, October 2014. 527 10.2. Informative References 529 [bitcoins] 530 Nakamoto, S., "Bitcoin: A Peer-to-Peer Electronic Cash 531 System", October 2008. 533 Author's Address 535 Yoav Nir 536 Check Point Software Technologies Ltd. 537 5 Hasolelim st. 538 Tel Aviv 6789735 539 Israel 541 Email: ynir.ietf@gmail.com