RFC 8019

Protecting Internet Key Exchange Protocol Version 2 (IKEv2) Implementations from Distributed Denial-of-Service Attacks

📅 published November 2016, from ietf

RFC 8019: Protecting Internet Key Exchange Protocol Version 2 (IKEv2) Implementations from Distributed Denial-of-Service Attacks 🎀

okay so this one is from the Internet Engineering Task Force (IETF) 💖 it's RFC 8019, published November 2016, and the authors are Y. Nir (Check Point) and V. Smyslov (ELVIS-PLUS) 👑 it's a Standards Track doc, which means it's an official Internet standard and not just vibes ✨ it has the ISSN 2070-1721, and it doesn't list anything it obsoletes or updates, so it's standing on its own 🦋

Abstract 🌸

ok bestie, the big idea is that this doc gives implementation and configuration best practices for IKEv2 Responders 🔥 the goal is to help them resist Denial-of-Service (DoS) and Distributed Denial-of-Service (DDoS) attacks 🛡️💅 it also introduces a brand new mechanism called "Client Puzzles" that helps with all of this 🧩✨

Status of This Memo 💜

this is an Internet Standards Track document 🎀

this doc is a product of the IETF, and it represents the consensus of the IETF community 🌈 it got public review and was approved for publication by the Internet Engineering Steering Group (IESG) ✅ if you want more info on Internet Standards, check out Section 2 of RFC 7841 📚

for info on the current status of this doc, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc8019 🔗

Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. 💖

this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication of this document 📜 please read these carefully, bestie, because they describe your rights and restrictions for this doc 🫶 Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License ⚖️

Table of Contents 🧚

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  Conventions Used in This Document . . . . . . . . . . . . . .   3
3.  The Vulnerability . . . . . . . . . . . . . . . . . . . . . .   3
4.  Defense Measures While the IKE SA Is Being Created  . . . . .   6
  4.1.  Retention Periods for Half-Open SAs . . . . . . . . . . .   6
  4.2.  Rate Limiting . . . . . . . . . . . . . . . . . . . . . .   7
  4.3.  The Stateless Cookie  . . . . . . . . . . . . . . . . . .   8
  4.4.  Puzzles . . . . . . . . . . . . . . . . . . . . . . . . .   8
  4.5.  Session Resumption  . . . . . . . . . . . . . . . . . . .  11
  4.6.  Keeping Computed Shared Keys  . . . . . . . . . . . . . .  11
  4.7.  Preventing "Hash and URL" Certificate Encoding Attacks  .  11
  4.8.  IKE Fragmentation . . . . . . . . . . . . . . . . . . . .  12
5.  Defense Measures after an IKE SA Is Created . . . . . . . . .  12
6.  Plan for Defending a Responder  . . . . . . . . . . . . . . .  14
7.  Using Puzzles in the Protocol . . . . . . . . . . . . . . . .  16
  7.1.  Puzzles in IKE_SA_INIT Exchange . . . . . . . . . . . . .  16
    7.1.1.  Presenting a Puzzle . . . . . . . . . . . . . . . . .  17
    7.1.2.  Solving a Puzzle and Returning the Solution . . . . .  19
    7.1.3.  Computing a Puzzle  . . . . . . . . . . . . . . . . .  20
    7.1.4.  Analyzing Repeated Request  . . . . . . . . . . . . .  21
    7.1.5.  Deciding Whether to Serve the Request . . . . . . . .  22
  7.2.  Puzzles in an IKE_AUTH Exchange . . . . . . . . . . . . .  23
    7.2.1.  Presenting the Puzzle . . . . . . . . . . . . . . . .  24
    7.2.2.  Solving the Puzzle and Returning the Solution . . . .  24
    7.2.3.  Computing the Puzzle  . . . . . . . . . . . . . . . .  25
    7.2.4.  Receiving the Puzzle Solution . . . . . . . . . . . .  25
8.  Payload Formats . . . . . . . . . . . . . . . . . . . . . . .  26
  8.1.  PUZZLE Notification . . . . . . . . . . . . . . . . . . .  26
  8.2.  Puzzle Solution Payload . . . . . . . . . . . . . . . . .  27
9.  Operational Considerations  . . . . . . . . . . . . . . . . .  28
10. Security Considerations . . . . . . . . . . . . . . . . . . .  28
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  30
12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  30
  12.1.  Normative References . . . . . . . . . . . . . . . . . .  30
  12.2.  Informative References . . . . . . . . . . . . . . . . .  31
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  31
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  32

1. Introduction 🌸

okay so DoS attacks have always been seriously scary 😭 they're hard to defend against because a victim's resources are always limited (no matter how big the pile is), and some of those resources have to go toward figuring out which session is legit and which one is an attack 💀

the Internet Key Exchange Protocol version 2 (IKEv2), described in [RFC7296], already has defense against DoS attacks built in 🛡️ specifically, there's a cookie mechanism that lets the IKE Responder protect itself from DoS attacks that use spoofed IP addresses 🎀 but botnets are everywhere now, so attackers can do DDoS attacks, and those are way harder to stop 😤

so this doc gives recommendations to help the Responder fight off both DoS and DDoS attacks 💪 it also introduces a new mechanism, "puzzles", that can help with this task 🧩✨

2. Conventions Used in This Document 💅

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this doc are to be interpreted as described in [RFC2119] 📖 bestie, these are the capitalized words you'll see with real meaning in this spec, so read them carefully 🫶

3. The Vulnerability 💀

okay so the IKE_SA_INIT exchange from Section 1.2 of [RFC7296] 🧚 is pretty simple: the Initiator sends one message, and the Responder sends one message back. But the Responder also allocates memory for something called a half-open IKE Security Association (SA) 👀. This half-open SA gets authenticated later, in the IKE_AUTH exchange. If that IKE_AUTH request never shows up, the half-open SA just sticks around for an unspecified amount of time 😭. Depending on the algorithms and the implementation, one of these can eat anywhere from around one hundred to several thousand bytes of memory 💾.

This is literally an easy attack vector against an IKE Responder 🙈. Generating an IKE_SA_INIT request is cheap, so sending huge piles of them can make a Responder run out of resources 📉. And if the Responder tries to defend itself by throttling new requests, that also blocks legitimate Initiators from setting up IKE SAs 🥲.

An obvious defense is limiting how many half-open SAs one peer can open. That's described in Section 4.2 🧠. The catch is that all an attacker needs is a single packet, so they can just use multiple spoofed source IP addresses 🎭.

If we break down what a Responder has to do during an initial exchange, there are three stages 🎀:

  1. When the IKE_SA_INIT request arrives, the Responder:
    • Generates or reuses a Diffie-Hellman (DH) private part.
    • Generates a Responder Security Parameter Index (SPI).
    • Stores the private part and peer public part in a half-open SA database.
  2. When the IKE_AUTH request arrives, the Responder:
    • Derives the keys from the half-open SA.
    • Decrypts the request.
  3. If the IKE_AUTH request decrypts properly, the Responder:
    • Validates the certificate chain (if present) in the IKE_AUTH request.

The fourth stage, where the Responder creates the Child SA, isn't reached by attackers who can't get past the authentication step 🛑.

Stage #1 is pretty light on CPU but needs some storage, and it's very light for the Initiator too ✨. Stage #2 includes private-key operations, so it's way heavier CPU-wise 🔥. Stage #3 may include public key operations if certificates are involved, and those are often more computationally expensive than what happens at stage #2 🤯.

So to attack a Responder, an attacker can go after either memory or CPU 🎯. With no protection at all, the most efficient move is sending a bunch of IKE_SA_INIT requests to exhaust memory, and it's easy because those requests are cheap 💸.

There are obvious ways for the Responder to protect itself without changing the protocol 🛡️. It can shorten how long an entry stays in the half-open SA database, and it can cap the number of concurrent half-open SAs from one particular address or prefix. The attacker can get around that by using spoofed source addresses 🥷.

The stateless cookie mechanism from Section 2.6 of [RFC7296] stops attacks that use spoofed source addresses 🍪. It doesn't completely solve the problem, but it makes limiting half-open SAs by address or prefix actually work 💅. Puzzles, introduced in Section 4.4, do the same job, just with more of it 🧩. They make it harder for an attacker to get a half-open SA at all. Puzzles don't have to be so hard that an attacker can't afford to solve a single one. It's enough that they raise the cost of creating half-open SAs, so the attacker is limited in how many they can make 🙌.

Shortening how long an abandoned half-open SA lives also reduces the impact of these attacks ⏱️. For example, say a half-open SA is kept for 1 minute and the capacity is 60,000 half-open SAs. Then an attacker would need to create 1,000 half-open SAs per second. If the retention time drops to 3 seconds, the attacker would need 20,000 half-open SAs per second to get the same result 📈. By introducing a puzzle, each half-open SA gets more expensive for the attacker, which makes an exhaustion attack against Responder memory more likely to be prevented 🫶.

At this point, filling up the half-open SA database isn't the most efficient DoS attack anymore 🙅‍♀️. The attacker has two alternatives that do better:

  1. Go back to spoofed addresses and try to overwhelm the CPU that deals with generating cookies, or
  2. Take the attack to the next level by also sending an IKE_AUTH request.
If an attacker is so powerful that they can overwhelm the Responder's CPU that deals with generating cookies, then the attack can't be dealt with at the IKE level. It has to be handled with Intrusion Prevention System (IPS) technology 🚨.

The second option, sending an IKE_AUTH request, is very cheap 😈. It just takes a proper IKE header with the correct IKE SPIs and a single Encrypted payload. The content of that payload doesn't matter and might be junk 🗑️. The Responder still has to do the relatively expensive key derivation, only to find out that the Message Authentication Code (MAC) on the Encrypted payload fails the integrity check 💔. If a Responder doesn't hold on to the calculated SKEYSEED and SK_* keys (which it should do in case a valid IKE_AUTH comes in later), this attack can be repeated on the same half-open SA 🔁. Puzzles make this kind of attack more costly for the attacker. See Section 7.2 for details 📖.

Here too, the number of half-open SAs the attacker can reach is crucial, because each one lets them waste some CPU time ⏳. So making it hard to create lots of half-open SAs is important 🔑.

A strategy against DDoS has to rely on at least 4 components 💪:

  1. Hardening the half-open SA database by reducing retention time.
  2. Hardening the half-open SA database by rate-limiting single IPs/ prefixes.
  3. Guidance on what to do when an IKE_AUTH request fails to decrypt.
  4. Increasing the cost of half-open SAs up to what is tolerable for legitimate clients.

Puzzles are used as a solution for strategy #4 🧩✨.

4. Defense Measures While the IKE SA Is Being Created 🛡️

4.1. Retention Periods for Half-Open SAs ⏳

As a UDP-based protocol, IKEv2 has to deal with packet loss through retransmissions 📦. Section 2.4 of [RFC7296] recommends "that messages be retransmitted at least a dozen times over a period of at least several minutes before giving up." Lots of retransmission policies in practice wait one or two seconds before retransmitting for the first time 🕐.

So if you set the timeout on a half-open SA too low, it'll expire whenever even one IKE_AUTH request packet gets lost 😩. When you're not under attack, the half-open SA timeout SHOULD be set high enough that the Initiator has time to send multiple retransmissions. That way, transient network congestion is less likely to cause an IKE failure 🫶.

When the system is under attack, measured by the number of half-open SAs, it makes sense to reduce this lifetime 📉. The Responder should still allow enough time for the round-trip, for the Initiator to derive the DH shared value, and for the Initiator to derive the IKE SA keys and create the IKE_AUTH request. Two seconds is probably as low as it can realistically go 🥺.

It could make sense to give a shorter lifetime to half-open SAs that come from IP addresses or prefixes that look suspect because they have multiple concurrent half-open SAs 🕵️‍♀️.

4.2. Rate Limiting 🚦

Even with DDoS, the attacker only has a limited number of nodes taking part in the attack 🤖. By limiting how many half-open SAs each of those nodes is allowed to have at once, the total number of half-open SAs gets capped. The total number of key derivations the Responder is forced to complete gets capped too 🙌.

For IPv4, it makes sense to limit half-open SAs based on IP address. Most IPv4 nodes are either attached directly to the Internet with a routable address, or hidden behind a NAT device with a single IPv4 external address 🌐. For IPv6, ISPs assign between a /48 and a /64, so rate limiting on single IPv6 addresses doesn't really make sense 🙅‍♀️. Instead, rate limits should be applied based on either the /48 or the /64 of the misbehaving IPv6 address that was observed 👀.

Counting half-open SAs is easy, but it's also worth counting failed IKE_AUTH exchanges 📊. If possible, both factors should be taken into account when deciding which IP address or prefix counts as suspicious 🕵️.

There are two ways to rate limit a peer address or prefix 🎀:

  1. Hard Limit -- where the number of half-open SAs is capped, and any further IKE_SA_INIT requests are rejected.
  2. Soft Limit -- where, if a set number of half-open SAs exist for a particular address or prefix, any IKE_SA_INIT request will be required to solve a puzzle 🧩.

The advantage of the hard limit is that it gives a hard cap on how many half-open SAs the attacker can create 🧱. The disadvantage is that it lets the attacker block IKE initiation from small parts of the Internet 😬. For example, if a network service provider or some establishment offers Internet connectivity to customers or employees through an IPv4 NAT device, a single malicious customer can create enough half-open SAs to fill the quota for that NAT device's external IP address. Legitimate Initiators on the same network won't be able to start IKE at all 💔.

The advantage of a soft limit is that legitimate clients can always connect 🥰. The disadvantage is that an adversary with enough CPU resources can still effectively DoS the Responder 🥶.

No matter which type of rate limiting is used, legitimate Initiators that aren't on the same network segments as the attackers won't be affected 🎉. This matters a lot, because it reduces the bad side effects of the measures used to counter the attack, and it lets most Initiators keep working even if they don't support puzzles 💖.

Section 2.6 of [RFC7296] offers a mechanism to mitigate DoS attacks: the stateless cookie 🫧. When the server is under load, the Responder answers the IKE_SA_INIT request with a calculated "stateless cookie." This is a value that can be recalculated from values in the IKE_SA_INIT request, so the Responder doesn't have to store any state on its side 🧠. The Initiator is expected to repeat the IKE_SA_INIT request, this time including the stateless cookie. This mechanism stops DoS attacks from spoofed IP addresses, since an attacker needs a routable IP address to get the cookie back 🔙.

Attackers that have multiple source IP addresses with return routability, like in the case of botnets 🤖🤖🤖, can still fill up a half-open SA table anyway 😱. The cookie mechanism limits the amount of allocated state to the number of attackers, multiplied by the number of half-open SAs allowed per peer address, multiplied by the amount of state allocated for each half-open SA. With typical values, this can easily reach hundreds of megabytes 📈💀.

4.4. Puzzles 🧩

okay so puzzles are literally giving proof-of-work vibes 🔥 the idea is loosely based on the same kind of thing Bitcoin does [BITCOINS]. the whole point is to put a ceiling on how many negotiations an attacker can start in a unit of time, and that ceiling is set by how fast the attacker's CPU is 💅

A puzzle gets sent to the Initiator in two cases:

  • The Responder is so overloaded that no half-open SAs can be created without solving a puzzle, or
  • The Responder isn't too loaded, but the rate-limiting method from Section 4.2 stops half-open SAs from being created with this particular peer address or prefix unless a puzzle gets solved first. 🙈

When the Responder decides to send the challenge for a puzzle in response to an IKE_SA_INIT request, the message includes at least three components:

  1. Cookie -- this is calculated the same way as in [RFC7296], which means the process of generating the cookie is not specified. 🍪
  2. Algorithm, which is the identifier of a Pseudorandom Function (PRF) algorithm, picked from the ones the Initiator proposed in the SA payload.
  3. Zero-Bit Count (ZBC). This is a number between 8 and 255 (or a special value, 0; see Section 7.1.1.1) that represents the length of the zero-bit run at the end of the PRF output, calculated over the cookie the Initiator is about to send. The values 1-8 are explicitly excluded because they make a puzzle that is way too easy to solve. Since the mechanism is supposed to be stateless for the Responder, either the same ZBC gets used for every Initiator, or the ZBC gets encoded somehow inside the cookie. If it's global, that means the value is the same for all the Initiators receiving puzzles at any given moment. The Responder, however, may change this value over time depending on its load. 📈

Once the Initiator gets this challenge, it tries to calculate the PRF output using different keys. When it finds enough keys where the PRF output calculated with each one has a sufficient number of trailing zero bits, that result gets sent back to the Responder. ✨

Why use several keys instead of just one? It's all about reducing the variance in how long the Initiator takes to solve the puzzle. We chose four (4) keys as a compromise between two competing goals: lowering that variance, and not making the Responder do too much work when it verifies the puzzle solution. 🎀

When the Responder gets a request with a solved puzzle, it checks two things:

  • That the cookie is indeed valid.
  • That the results of the PRF over the transmitted cookie, calculated with the transmitted keys, have a sufficient number of trailing zero bits.

Example 1: Say the calculated cookie is 739ae7492d8a810cf5e8dc0f9626c9dda773c5a3 (20 octets), the algorithm is PRF-HMAC-SHA256, and the required number of zero bits is 18. After successively trying a bunch of keys, the Initiator finds the following four 3-octet keys that work:

   +--------+----------------------------------+----------------+
   |  Key   | Last 32 Hex PRF Digits           | # of Zero Bits |
   +--------+----------------------------------+----------------+
   | 061840 | e4f957b859d7fb1343b7b94a816c0000 |       18       |
   | 073324 | 0d4233d6278c96e3369227a075800000 |       23       |
   | 0c8a2a | 952a35d39d5ba06709da43af40700000 |       20       |
   | 0d94c8 | 5a0452b21571e401a3d00803679c0000 |       18       |
   +--------+----------------------------------+----------------+

            Table 1: Four Solutions for the 18-Bit Puzzle

Example 2: Same cookie, but now the required number of zero bits is 22. The first 4-octet keys that work to satisfy that requirement are 005d9e57, 010d8959, 0110778d, and 01187e37. Finding these takes 18,382,392 invocations of the PRF. 🥵

         +----------------+-------------------------------+
         | # of Zero Bits | Time to Find 4 Keys (Seconds) |
         +----------------+-------------------------------+
         |       8        |                        0.0025 |
         |       10       |                        0.0078 |
         |       12       |                        0.0530 |
         |       14       |                        0.2521 |
         |       16       |                        0.8504 |
         |       17       |                        1.5938 |
         |       18       |                        3.3842 |
         |       19       |                        3.8592 |
         |       20       |                       10.8876 |
         +----------------+-------------------------------+

   Table 2: The Time Needed to Solve a Puzzle of Various Difficulty for
            the Cookie 39ae7492d8a810cf5e8dc0f9626c9dda773c5a3

The figures above were measured on a 2.4 GHz single-core Intel i5 processor in a 2013 Apple MacBook Pro. Run times can be halved or quartered with multi-core code, but they would be longer on mobile phone processors, even multi-core ones. With these figures, 18 bits is believed to be a reasonable puzzle difficulty for all Initiators, and 20 bits is acceptable for specific hosts or prefixes. 📱

Using the puzzles mechanism in the IKE_SA_INIT exchange is described in Section 7.1. 💜

4.5. Session Resumption 🎟️

When the Responder is under attack, it SHOULD prefer previously authenticated peers who present a Session Resumption ticket [RFC5723]. However, the Responder SHOULD NOT serve resumed Initiators exclusively, because dropping all IKE_SA_INIT requests would lock out legitimate Initiators that don't have a resumption ticket. 😭 When under attack, the Responder SHOULD require Initiators presenting Session Resumption tickets to pass a return routability check, by including the COOKIE notification in the IKE_SESSION_RESUME response message, as described in Section 4.3.2. of [RFC5723]. Also, the Responder SHOULD cache tickets for a short time to reject reused tickets (Section 4.3.1 of [RFC5723]). Therefore, there should be no issue of half-open SAs resulting from replayed IKE_SESSION_RESUME messages. 🔒

Several kinds of DoS attacks are possible on servers that support IKE Session Resumption. See Section 9.3 of [RFC5723] for details. 🚨

4.6. Keeping Computed Shared Keys 🔑

Once the IKE_SA_INIT exchange is finished, the Responder is waiting for the first message of the IKE_AUTH exchange from the Initiator. At this point, the Initiator isn't authenticated yet, and that fact lets an attacker pull off the attack described in Section 3. 🙃 Instead of sending a properly formed and encrypted IKE_AUTH message, the attacker can just send arbitrary data, forcing the Responder to do costly CPU work to compute the SK_* keys. 🔥

If the received IKE_AUTH message fails to decrypt correctly (or fails the Integrity Check Value (ICV) check), then the Responder SHOULD still keep the computed SK_* keys. That way, if it turns out to be an attack, the attacker can't gain anything by repeating the attack multiple times on a single IKE SA. 🧠 The Responder can also use puzzles in the IKE_AUTH exchange, as described in Section 7.2.

4.7. Preventing "Hash and URL" Certificate Encoding Attacks 🕵️

In IKEv2, each side may use the "Hash and URL" Certificate Encoding to tell the peer to retrieve certificates from a specified location (see Section 3.6 of [RFC7296] for details). Malicious Initiators can abuse this feature to mount a DoS attack on the Responder by giving it a URL that points to a huge file, possibly full of meaningless bits. 😱 While downloading that file, the Responder burns CPU, memory, and network bandwidth. 💀

To stop this kind of attack, the Responder should not blindly download the whole file. Instead, it SHOULD first read the initial few bytes, decode the length of the ASN.1 structure from those bytes, and then download no more than the decoded number of bytes. It's always possible to determine the length of ASN.1 structures used in IKEv2, if they are DER-encoded, by analyzing the first few bytes. However, since the content of the file being downloaded can be under the attacker's control, implementations should not blindly trust the decoded length, and they SHOULD check whether it makes sense before continuing to download the file. 🧐 Implementations SHOULD also apply a configurable hard limit to the number of pulled bytes, and SHOULD provide an ability for an administrator to either completely disable this feature or limit its use to a configurable list of trusted URLs. ⚙️

4.8. IKE Fragmentation 🧩

IKE fragmentation, described in [RFC7383], lets IKE peers avoid IP fragmentation of large IKE messages. Attackers can mount several kinds of DoS attacks using IKE fragmentation. See Section 5 of [RFC7383] for details on how to mitigate these attacks. 🛡️

5. Defense Measures after an IKE SA Is Created ✨

Okay so once an IKE SA is created, there usually isn't a ton of IKE traffic going on 💅 The traffic that does happen is mostly exchanges to make extra Child SAs, IKE rekeys, IKE deletions, and IKE liveness tests. Some of these are super chill on resources (like a liveness check), while others are kinda resource-hungry (like making or rekeying a Child SA with a DH exchange).

Since any endpoint can start a new exchange, a peer could start way too many and drain the host's resources 😭 Like, it could do endless Child SA rekeying, or make an overwhelming pile of Child SAs with the same Traffic Selectors, etc. That can happen because of broken implementations or misconfiguration, or it can be an intentional attack. The attack side gets more real if the peer uses NULL Authentication, as described in [RFC7619]. Then the peer stays anonymous, so it can dodge any responsibility for what it does 🙈 See Section 3 of [RFC7619] for details on how to mitigate attacks when using NULL Authentication.

The following recommendations apply especially for NULL-authenticated IKE sessions, but they also apply to authenticated IKE sessions. The difference is that in the authenticated case, the identified peer can be locked out.

  • If the IKEv2 window size is greater than one, peers are able to initiate multiple simultaneous exchanges that increase host resource consumption. Since there is no way in IKEv2 to decrease window size once it has been increased (see Section 2.3 of [RFC7296]), the window size cannot be dynamically adjusted depending on the load. It is NOT RECOMMENDED to allow an IKEv2 window size greater than one when NULL Authentication has been used.
  • If a peer initiates an abusive amount of CREATE_CHILD_SA exchanges to rekey IKE SAs or Child SAs, the Responder SHOULD reply with TEMPORARY_FAILURE notifications indicating the peer must slow down their requests.
  • If a peer creates many Child SAs with the same or overlapping Traffic Selectors, implementations MAY respond with the NO_ADDITIONAL_SAS notification.
  • If a peer initiates many exchanges of any kind, the Responder MAY introduce an artificial delay before responding to each request message. This delay decreases the rate the Responder needs to process requests from any particular peer, and it frees up resources on the Responder that can be used for answering legitimate clients. If the Responder receives retransmissions of the request message during the delay period, the retransmitted messages MUST be silently discarded. The delay must be short enough to avoid legitimate peers deleting the IKE SA due to a timeout. It is believed that a few seconds is enough. Note, however, that even a few seconds may be too long when settings rely on an immediate response to the request message, e.g., for the purposes of quick detection of a dead peer.
  • If these countermeasures are inefficient, implementations MAY delete the IKE SA with an offending peer by sending Delete Payload.

In IKE, a client can request various configuration attributes from the server. Most often, these attributes include internal IP addresses. Malicious clients can try to exhaust a server's IP address pool by continuously requesting a large number of internal addresses. Server implementations SHOULD limit the number of IP addresses allocated to any particular client. Note, this is not possible with clients using NULL Authentication, since their identity cannot be verified.

6. Plan for Defending a Responder 🛡️

This section lays out a plan for defending a Responder from a DDoS attack, using the techniques we covered earlier. The numbers here are not normative. Their purpose is to show the configurable parameters you need for surviving DDoS attacks 🎀

Implementations get deployed in all kinds of environments, so it is RECOMMENDED that the parameters be settable. For example, most commercial products have to go through benchmarking where the IKE SA establishment rate gets measured. Benchmarking looks exactly like a DoS attack, and the defenses in this document may wreck the benchmark by causing exchanges to fail or to take a long time to complete. Parameters SHOULD be tunable so benchmarking is possible (even if the only option is turning DDoS protection off).

Since all countermeasures may cause delays and extra work for the Initiators, they SHOULD NOT be deployed unless an attack is likely to be in progress. To keep the burden on Initiators low, the Responder should monitor incoming IKE requests for two scenarios:

  1. A general DDoS attack. This shows up as a high number of concurrent half-open SAs, a high rate of failed IKE_AUTH exchanges, or a combination of both. For example, picture a Responder with 10,000 distinct peers, of which at peak, 7,500 concurrently have VPN tunnels. At the start of peak time, 600 peers might establish tunnels within any given minute, and tunnel establishment (both IKE_SA_INIT and IKE_AUTH) takes anywhere from 0.5 to 2 seconds. For this Responder, we expect there to be fewer than 20 concurrent half-open SAs, so having 100 concurrent half-open SAs can be read as a sign of an attack. Similarly, IKE_AUTH request decryption failures should never happen. Supposing the tunnels are established using Extensible Authentication Protocol (EAP) (see Section 2.16 of [RFC7296]), users may be expected to enter a wrong password about 20% of the time. So we'd expect 125 wrong password failures a minute. If we get IKE_AUTH decryption failures from multiple sources more than once per second, or EAP failures more than 300 times per minute, this can also be an indication of a DDoS attack 💀
  2. An attack from a particular IP address or prefix. This shows up as an inordinate amount of half-open SAs from a specific IP address or prefix, or an inordinate amount of IKE_AUTH failures. A DDoS attack may be viewed as multiple such attacks. If these are mitigated successfully, there won't be a need to enact countermeasures on all Initiators. For example, measures might be 5 concurrent half-open SAs, 1 decrypt failure, or 10 EAP failures within a minute.

Note that using countermeasures against an attack from a particular IP address may be enough to avoid overloading the half-open SA database. In that case, the number of failed IKE_AUTH exchanges will never exceed the threshold of attack detection.

When there is no general DDoS attack, it is suggested that no cookie or puzzles be used. At this point, the only defensive measure is to monitor the number of half-open SAs and set a soft limit per peer IP or prefix. The soft limit can be set to 3-5. If puzzles are used, the puzzle difficulty SHOULD be set to a level (number of zero bits) that all legitimate clients can handle without a degraded user experience.

As soon as any kind of attack is detected, either a lot of initiations from multiple sources or a lot of initiations from a few sources, it is best to begin by requiring stateless cookies from all Initiators. This mitigates attacks based on IP address spoofing and helps avoid having to impose a greater burden in the form of puzzles on the general population of Initiators. It also makes the per-node or per-prefix soft limit more effective.

When cookies are activated for all requests and the attacker is still managing to consume too many resources, the Responder MAY start to use puzzles for these requests, or increase the difficulty of puzzles imposed on IKE_SA_INIT requests coming from suspicious nodes/prefixes. This should still be doable by all legitimate peers, but puzzles at a higher difficulty may degrade the user experience, for example by taking up to 10 seconds to solve the puzzle.

If the load on the Responder is still too great, and there are many nodes causing multiple half-open SAs or IKE_AUTH failures, the Responder MAY impose hard limits on those nodes.

If it turns out the attack is very widespread and the hard caps aren't solving the issue, a puzzle MAY be imposed on all Initiators. Note that this is the last step, and the Responder should avoid it if possible.

7. Using Puzzles in the Protocol 🧩

This section describes how the puzzle mechanism is used in IKEv2. It's organized as follows. Section 7.1 describes using puzzles in the IKE_SA_INIT exchange, and Section 7.2 describes using puzzles in the IKE_AUTH exchange. Both sections are divided into subsections describing how puzzles should be presented, solved, and processed by the Initiator and the Responder.

7.1. Puzzles in IKE_SA_INIT Exchange

The IKE Initiator signals that it wants to create a new IKE SA by sending an IKE_SA_INIT request message. The message may optionally contain a COOKIE notification if this is a repeated request sent after the Responder asked for a cookie.

   HDR, [N(COOKIE),] SA, KE, Ni, [V+][N+]   -->

                   Figure 1: Initial IKE_SA_INIT Request

According to the plan described in Section 6, the IKE Responder monitors incoming requests to detect whether it is under attack. If the Responder learns that a DoS or DDoS attack is likely in progress, its actions depend on the volume of the attack. If the volume is moderate, the Responder asks the Initiator to return a cookie. If the volume is high enough that puzzles need to be used for defense, the Responder asks the Initiator to solve a puzzle 🔥

The Responder MAY choose to process some fraction of IKE_SA_INIT requests without presenting a puzzle while under attack, so legacy clients that don't support puzzles still get a chance to be served. The decision whether to process any particular request must be probabilistic, with the probability depending on the Responder's load (i.e., on the volume of attack). The requests that don't contain the COOKIE notification MUST NOT participate in this lottery. In other words, the Responder must first perform a return routability check before allowing any legacy client to be served if it is under attack. See Section 7.1.4 for details.

7.1.1. Presenting a Puzzle

If the Responder decides to use puzzles, it includes two notifications in its response message: the COOKIE notification and the PUZZLE notification. Note that the PUZZLE notification MUST always be accompanied by the COOKIE notification, since the content of the COOKIE notification is used as input data when solving the puzzle. The format of the PUZZLE notification is described in Section 8.1.

                             <--   HDR, N(COOKIE), N(PUZZLE), [V+][N+]

             Figure 2: IKE_SA_INIT Response Containing Puzzle

The presence of these notifications in an IKE_SA_INIT response message tells the Initiator that it should solve the puzzle to have a better chance of being served 💜

7.1.1.1. Selecting the Puzzle Difficulty Level ✨

okay so the PUZZLE notification carries the difficulty level, which is the minimum number of trailing zero bits that the result of PRF has to contain 🧚. ngl, picking one level that's fair for everyone is nearly impossible, because Initiators can have computing power that differs by an order of magnitude or even more 💀. The Responder can set the difficulty level to 0, which basically means "spend as much power as you can afford" 💅. In that case there's no specific ZBC required from the Initiator, BUT the bigger the ZBC it manages to get, the better its chance of being served by the Responder 🫶. In diverse environments, it is RECOMMENDED that the Initiator set the difficulty level to 0, unless the attack volume is very high 🌸.

If the Responder sets a non-zero difficulty level, then the level SHOULD be determined by analyzing the volume of the attack 📊. The Responder MAY set different difficulty levels to different requests depending on the IP address the request has come from 🌈.

7.1.1.2. Selecting the Puzzle Algorithm

The PUZZLE notification also includes an identifier of the algorithm that the Initiator uses to compute the puzzle 🔑.

Cryptographic algorithm agility is a big deal for modern protocols [RFC7696] 👑. It means a protocol doesn't get stuck with one built-in set of cryptographic algorithms. It has a way to swap in a different set and negotiate new algorithms with the peer 🦋. IKEv2 fully supports cryptographic algorithm agility for its core operations, so it's giving very organized energy 💖.

For puzzles to have that same crypto-agility, the algorithm used to compute a puzzle has to be negotiated during the IKE_SA_INIT exchange. Here's how that goes 👀. The initial request message from the Initiator contains an SA payload with a list of transforms of different types. By doing that, the Initiator is basically saying it supports every transform on that list and can use any of them in the IKE SA being established 🧁. The Responder parses the SA payload and finds the transforms of type PRF that both sides support. It then picks the preferred PRF from the mutually supported ones and includes it in the PUZZLE notification ✨. The PRF chosen for puzzles doesn't have to be the same as the PRF negotiated later for the core IKE SA crypto operations, so no need to match 💅. If there are no mutually supported PRFs, IKE SA negotiation fails anyway, so there's no point in returning a puzzle. In that case, the Responder returns a NO_PROPOSAL_CHOSEN notification 😭. Also, PRF is a mandatory transform type for IKE SA (see Sections 3.3.2 and 3.3.3 of [RFC7296]), so at least one transform of this type is always present in the SA payload in an IKE_SA_INIT request message 🫶.

If the Responder supports puzzles, the cookie should be built so the Responder can learn some important info from the cookie alone when the Initiator sends it back 🍓. Specifically, the Responder SHOULD be able to learn the following:

  • Whether the puzzle was given to the Initiator or only the cookie was requested.
  • The difficulty level of the puzzle given to the Initiator.
  • The number of consecutive puzzles given to the Initiator.
  • The amount of time the Initiator spent solving the puzzles. This can be calculated if the cookie is timestamped ⏰.

All of this helps the Responder decide whether to serve the request or demand more work from the Initiator 🧠.

One way to get this info is to encode it in the cookie 🎀. The format of that encoding is an implementation detail of the Responder, since the cookie stays an opaque block of data to the Initiator 🙈. If the info is encoded in the cookie, then the Responder MUST make it integrity protected, so any intended or accidental change to that info in the returned cookie is detectable 🔒. So the cookie would be generated as:

Cookie = <VersionIDofSecret> | <AdditionalInfo> |
                     Hash(Ni | IPi | SPIi | <AdditionalInfo> | <secret>)

Note that according to Section 2.6 of [RFC7296], the size of the cookie cannot exceed 64 bytes 📏.

Or, the Responder can generate a cookie as suggested in Section 2.6 of [RFC7296], but store the additional info in local storage tied to the particular version of the secret 🗄️. In this case, the Responder should have different secrets for every combination of difficulty level and number of consecutive puzzles. It should also change the secrets periodically, keeping a few previous versions so it can calculate how long ago a cookie was generated ⏳.

The Responder can also mix these approaches. This document doesn't mandate how the Responder learns this information from a cookie 🤷‍♀️.

When selecting cookie generation, algorithm implementations MUST ensure that an attacker gains no or insignificant benefit from reusing puzzle solutions in several requests. See Section 10 for details 🚨.

7.1.2. Solving a Puzzle and Returning the Solution

If the Initiator gets a puzzle but doesn't support puzzles, it ignores the PUZZLE notification as an unrecognized status notification (in accordance with Section 3.10.1 of [RFC7296]) 🙃. Even if the Initiator does support puzzles, it MAY ignore the PUZZLE notification if it isn't willing to spend resources solving a puzzle of the requested difficulty 🤐. In both cases, the Initiator acts as described in Section 2.6 of [RFC7296]: it restarts the request and includes the received COOKIE notification in it 🔁. The Responder should be able to tell the difference between "I only requested a cookie" and "I gave the Initiator a puzzle, but it ignored it for some reason" 🕵️‍♀️.

If the received message has a PUZZLE notification but no COOKIE notification, the message is malformed. It's asking for a puzzle to be solved without giving enough info to actually solve it 🤨. In this case, the Initiator MUST ignore the received message and keep waiting until either a valid PUZZLE notification arrives or the retransmission timer fires. If it doesn't get a valid message after several retransmissions of IKE_SA_INIT requests, something is wrong and the IKE SA cannot be established 💀.

If the Initiator supports puzzles and is ready to solve them, it tries to solve the given puzzle 💪. Once solved, the Initiator restarts the request and sends the puzzle solution back to the Responder in a new payload called a Puzzle Solution (PS) payload (see Section 8.2), along with the received COOKIE notification 🧩.

HDR, N(COOKIE), [PS,] SA, KE, Ni, [V+][N+]   -->

Figure 3: IKE_SA_INIT Request Containing Puzzle Solution 🖼️

7.1.3. Computing a Puzzle

The general principles for building puzzles in IKEv2 are described in Section 4.4 📚. Here's the quick version: given an unpredictable string S and a PRF, find N different keys Ki (where i=[1..N]) for that PRF so that the result of PRF(Ki,S) has at least the specified number of trailing zero bits. This specification requires that the puzzle solution contains 4 different keys (i.e., N=4) 🔢.

In the IKE_SA_INIT exchange, the cookie plays the role of the unpredictable string S 🍪. So the IKE Initiator's job is to find four different, equal-sized keys Ki for the agreed-upon PRF, where each result of PRF(Ki,cookie) for i = [1..4] has a sufficient number of trailing zero bits 🏆. Only the content of the COOKIE notification is used in the puzzle calculation, meaning the header of the Notify payload is not included 🎯.

Note that puzzles in the IKE_AUTH exchange are computed differently than in the IKE_SA_INIT_EXCHANGE. See Section 7.2.3 for details 👀.

7.1.4. Analyzing Repeated Request

The received request must at least contain a COOKIE notification. If it doesn't, it's an initial request, and in that case it MUST be processed according to Section 7.1. First, the cookie MUST be checked for validity. If the cookie is invalid, the request is treated as initial and processed according to Section 7.1. In this case, it is RECOMMENDED that a new cookie is requested 🔄.

If the cookie is valid, some important info is learned from it or from local state based on the identifier of the cookie's secret (see Section 7.1.1.3 for details). This info helps the Responder sort out incoming requests, giving more priority to the ones that cost the Initiator more resources 📈.

First, the Responder figures out whether it requested only a cookie or presented a puzzle to the Initiator 🔍. If no puzzle was given, that means that when the Responder requested the cookie, it didn't detect a DoS or DDoS attack, or the attack volume was low. In this case, the received request message must not contain the PS payload, and this payload MUST be ignored if the message contains a PS payload for any reason. Since no puzzle was given, the Responder marks the request with the lowest priority, because the Initiator spent little resources creating it 🐢.

If the Responder learns from the cookie that a puzzle was given to the Initiator, it looks for the PS payload to see whether the request to solve the puzzle was honored. If the incoming message doesn't contain a PS payload, the Initiator either doesn't support puzzles or doesn't want to deal with them. Either way, the request is marked with the lowest priority, since the Initiator spent little resources creating it 😬.

If a PS payload is found, the Responder MUST verify the puzzle solution it contains. The solution is interpreted as four different keys. The result of using each of them in the PRF (as described in Section 7.1.3) must contain at least the requested number of trailing zero bits. The Responder MUST check all four of the returned keys 🔐.

If any checked result has fewer bits than were requested, that means the Initiator spent fewer resources than the Responder expected. This request is marked with the lowest priority 📉.

If the Initiator provided a solution satisfying the requested difficulty level, or if the Responder didn't indicate any particular difficulty level (by setting the ZBC to 0) and the Initiator was free to pick any difficulty level it can afford, then the priority of the request is calculated using these considerations:

  • The Responder MUST take the smallest number of trailing zero bits among the checked results and count it as the number of zero bits the Initiator solved for 🧮.
  • The higher the number of zero bits the Initiator provides, the higher priority its request should receive 🚀.
  • The more consecutive puzzles the Initiator solved, the higher priority it should receive 🏅.
  • The more time the Initiator spent solving the puzzles, the higher priority it should receive 🌟.

After the priority of the request is determined, the final decision on whether to serve it or not gets made 💅✨.

7.1.5. Deciding Whether to Serve the Request 💅

okay so the Responder is the one deciding what happens to each request, and it looks at two things: the request's priority and its own current load 🧚 there are three things it can do:

  • Accept request.
  • Reject request.
  • Demand more work from the Initiator by giving it a new puzzle.

The Responder SHOULD accept an incoming request if its priority is high 💖 that means the Initiator spent quite a lot of resources, so it's giving main character energy and deserves to get served. The Responder MAY also accept some low-priority requests where the Initiators don't support puzzles 🌸 how many of those legacy requests get accepted depends on the Responder's current load.

If the Initiator solved the puzzle but didn't spend much effort on it (the selected puzzle difficulty level was low and the Initiator solved it quickly), then the Responder SHOULD give it another puzzle 🙈 the more puzzles the Initiator solves, the better its chances of being served. bestie, it's a whole grind-to-get-served situation 😭

How the Responder makes a decision for any particular request is implementation dependent 🎀 one approach is for it to collect all the incoming requests for a short period of time, sort them by priority, work out how many memory slots are free for half-open IKE SAs, and then serve that many requests from the top of the sorted list. Whatever is left over can either get discarded or get a fresh puzzle request ✨

Or, the Responder can decide whether to accept each incoming request with some kind of lottery, taking into account its priority and the available resources 🦋

7.2. Puzzles in an IKE_AUTH Exchange

okay this part is the plot twist 👑 once the IKE_SA_INIT exchange is done, the Responder has created a state and is waiting for the first message of the IKE_AUTH exchange from the Initiator. By this point, the Initiator has already passed the return routability check and has proved that it did some work to complete the IKE_SA_INIT exchange. BUT the Initiator is still not authenticated, and that lets a sneaky Initiator pull off an attack, as described in Section 3 🙈

Here's the difference from the DoS attack in the IKE_SA_INIT exchange: that one targets the Responder's memory, while this one is trying to drain the Responder's CPU power 💀 the attacker sends a first IKE_AUTH message containing arbitrary data. This costs the Initiator nothing, but the Responder has to do pretty expensive stuff, computing the DH shared secret and deriving the SK_* keys, just to verify that the message is authentic. If the Responder doesn't keep the computed keys after a failed verification of the IKE_AUTH message, the attacker can repeat this several times on the same IKE SA 😤

So the Responder can use puzzles to make this attack more costly for the Initiator 🔥 the idea is that the Responder includes a puzzle in the IKE_SA_INIT response message, and the Initiator includes a puzzle solution in the first IKE_AUTH request message, outside the Encrypted payload. That way the Responder can verify the puzzle solution before it computes the DH shared secret 🧠

The Responder keeps an eye on the number of half-open IKE SA states that receive IKE_AUTH messages which can't be decrypted because of integrity check failures. If the percentage of those states is high, and calculating keys for them eats up an essential chunk of the Responder's computing power, then the Responder may assume that it is under attack and SHOULD use puzzles to make things harder for attackers 🛡️

7.2.1. Presenting the Puzzle

The Responder asks the Initiator to solve a puzzle by including the PUZZLE notification in the IKE_SA_INIT response message 🎀 The Responder MUST NOT use puzzles in the IKE_AUTH exchange unless a puzzle has already been presented and solved in the preceding IKE_SA_INIT exchange. No cap, that's the rule 💅

                             <--   HDR, SA, KE, Nr, N(PUZZLE), [V+][N+]

Figure 4: IKE_SA_INIT Response Containing IKE_AUTH Puzzle

7.2.1.1. Selecting Puzzle Difficulty Level

The difficulty level of the puzzle in the IKE_AUTH exchange should be picked so that the Initiator spends more time solving the puzzle than the Responder spends computing the DH shared secret and the keys needed to decrypt and verify the IKE_AUTH request message ⏱️ but it also shouldn't be too high, or legitimate clients will get an extra delay while setting up the IKE SA. It's a vibe balance, bestie 🌈

Since puzzles in the IKE_AUTH exchange are only allowed if they were used in the preceding IKE_SA_INIT exchange, the Responder can roughly estimate the Initiator's computational power and choose the difficulty level accordingly 🧚 Unlike puzzles in the IKE_SA_INIT, the requested difficulty level for IKE_AUTH puzzles MUST NOT be 0. In other words, the Responder must always set a specific difficulty level and must not let the Initiator choose it on its own 🙅‍♀️

7.2.1.2. Selecting the Puzzle Algorithm

The algorithm for the puzzle is selected as described in Section 7.1.1.2. There's no requirement that the algorithm for the puzzle in the IKE_SA_INIT exchange be the same as the one in the IKE_AUTH exchange, but it is expected that in most cases they'll match 🦋

7.2.2. Solving the Puzzle and Returning the Solution

If the IKE_SA_INIT regular response message (the one with the SA, KE, NONCE payloads) contains the PUZZLE notification and the Initiator supports puzzles, it MUST solve the puzzle 💖 Note that puzzle construction in the IKE_AUTH exchange is different from puzzle construction in the IKE_SA_INIT exchange, and it's described in Section 7.2.3. Once the puzzle is solved, the Initiator sends the IKE_AUTH request message containing the PS payload ✨

   HDR, PS, SK {IDi, [CERT,] [CERTREQ,]
               [IDr,] AUTH, SA, TSi, TSr}   -->

Figure 5: IKE_AUTH Request Containing IKE_AUTH Puzzle Solution

The PS payload MUST be placed outside the Encrypted payload, so the Responder can verify the puzzle before calculating the DH shared secret and the SK_* keys 🔐

If IKE fragmentation [RFC7383] is used in the IKE_AUTH exchange, the PS payload MUST be present only in the first IKE Fragment message, in accordance with Section 2.5.3 of [RFC7383]. Also, calculating the puzzle in the IKE_AUTH exchange doesn't depend on the content of the IKE_AUTH message (see Section 7.2.3). So the Initiator only has to solve the puzzle once, and that solution is valid for both unfragmented and fragmented IKE messages 🌸

7.2.3. Computing the Puzzle

A puzzle in the IKE_AUTH exchange is computed differently than in the IKE_SA_INIT exchange (see Section 7.1.3) 🍓 The general principle is the same; the difference is how the string S is built. Unlike the IKE_SA_INIT exchange, where S is the cookie, in the IKE_AUTH exchange S is a concatenation of Nr and SPIr. In other words, the IKE Initiator has to find four different keys Ki for the agreed upon PRF, so that each result of PRF(Ki,Nr | SPIr), where i=[1..4], has a sufficient number of trailing zero bits 🧩 Nr is a nonce used by the Responder in the IKE_SA_INIT exchange, stripped of any headers. SPIr is the IKE Responder's SPI from the IKE header of the SA being established.

7.2.4. Receiving the Puzzle Solution

If the Responder asked the Initiator to solve a puzzle in the IKE_AUTH exchange, then it MUST silently discard all the IKE_AUTH request messages without the PS payload 🙈

Once the message containing a solution to the puzzle arrives, the Responder MUST verify the solution before doing computationally intensive operations, i.e., computing the DH shared secret and the SK_* keys. The Responder MUST verify all four of the returned keys 🔍

The Responder MUST silently discard the received message if any checked verification result is incorrect (it contains an insufficient number of trailing zero bits) 🗑️ If the Responder successfully verifies the puzzle and calculates the SK_* key, but the message authenticity check fails, then it SHOULD save the calculated keys in the IKE SA state while it waits for retransmissions from the Initiator. In this case, the Responder may skip verification of the puzzle solution and ignore the PS payload in the retransmitted messages 🫶

If the Initiator uses IKE fragmentation, it sends all fragments of a message simultaneously. Because of packet loss and/or reordering, the Responder might receive subsequent fragments before it receives the first one that contains the PS payload 😭 In this case, the Responder MAY choose to keep the received fragments until the first fragment containing the solution to the puzzle arrives. Then the Responder SHOULD NOT try to verify the authenticity of the kept fragments until the first fragment with the PS payload is received and the solution to the puzzle is verified. After successful verification of the puzzle, the Responder can calculate the SK_* key and verify the authenticity of the collected fragments 🎉

8. Payload Formats

8.1. PUZZLE Notification

The PUZZLE notification is how the IKE Responder tells the Initiator that it needs to solve a puzzle 🧁 It contains the difficulty level of the puzzle and the PRF the Initiator should use.

                        1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Next Payload  |C|  RESERVED   |         Payload Length        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Protocol ID(=0)| SPI Size (=0) |      Notify Message Type      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              PRF              |  Difficulty   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • Protocol ID (1 octet) -- MUST be 0.
  • SPI Size (1 octet) -- MUST be 0, meaning no SPI is present.
  • Notify Message Type (2 octets) -- MUST be 16434, the value assigned for the PUZZLE notification.
  • PRF (2 octets) -- Transform ID of the PRF algorithm that MUST be used to solve the puzzle. Readers should refer to the "Transform Type 2 - Pseudorandom Function Transform IDs" subregistry on [IKEV2-IANA] for the list of possible values.
  • Difficulty (1 octet) -- Difficulty level of the puzzle. Specifies the minimum number of trailing zero bits (ZBC) that each of the results of PRF must contain. Value 0 means that the Responder doesn't request any specific difficulty level, and the Initiator is free to select an appropriate difficulty level on its own (see Section 7.1.1.1 for details).

This notification contains no data ✨

Okay so bestie, this is the final stretch of RFC 8019, and it's where all the big stuff lands 💅✨

8.2. Puzzle Solution Payload 🧩

So once the Initiator solves the puzzle, the solution has to get back to the Responder, and it does that in a dedicated payload called the PS payload 🎀

                     1                   2                   3
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload  |C|  RESERVED   |         Payload Length        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                     Puzzle Solution Data                      ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • Puzzle Solution Data (variable length) 🔑: this is where the solution lives, which is four different keys for the selected PRF. This field MUST NOT be empty. All of the keys MUST have the same size, so the size of this field is always a multiple of 4 bytes. If the selected PRF accepts only fixed-size keys, then the size of each key MUST be that fixed size. If the agreed upon PRF accepts keys of any size, then the size of each key MUST be between 1 octet and the preferred key length of the PRF (inclusive). It's expected that in most cases the keys will be 4 (or even less) octets long 🥺, but that depends on the puzzle difficulty and on how the Initiator goes about finding solutions, so the size isn't mandated by this spec. The Responder works out the size of each key by dividing the size of the Puzzle Solution Data by 4 (the number of keys). Also, the size of Puzzle Solution Data is the Payload Length minus 4, which is the size of the Payload header 🧾

The payload type for the PS payload is 54 🌸

9. Operational Considerations 🛠️

The puzzle difficulty should be set by balancing two things: keeping latency low for legit Initiators, and making life hard for attackers 🥊 A good rule of thumb is taking about 1 second to solve the puzzle. When this document was written, a typical Initiator or botnet member could do slightly less than a million hashes per second per core, so setting the number of zero bits to 20 is a good compromise 👑 Heads up though: mobile Initiators, especially phones, are way weaker than that 📱 Implementations should let admins set the difficulty level, and ideally be able to change it dynamically based on load 💖

Initiators SHOULD set a maximum difficulty level beyond which they won't try to solve the puzzle, and they should log or display a failure message to the administrator or user 🚨

Until puzzles are widely adopted, most Initiators will ignore them, and so will all the attackers 🙃 For puzzles to be a really powerful defense against DDoS attacks, they have to be supported by the majority of legit clients 🫶

10. Security Considerations 🔐

Okay, this part is serious bestie, so pay attention 😭🔥 Care must be taken when selecting puzzle parameters, especially the difficulty. If the puzzles are too easy for most attackers, the mechanism can't stop DoS or DDoS attacks and just adds burden on legit Initiators 💀 On the flip side, if puzzles are too hard for most Initiators, then lots of legit users would face unacceptable delays in IKE SA setup (and unacceptable power drain on mobile devices), and they might cancel the connection attempt 🪫 In that case the Responder's resources are preserved, but the DoS attack can still be considered successful 😬 So the Responder needs a sensible balance when choosing difficulty: defend itself without over-defending itself ⚖️ It is RECOMMENDED that the puzzle difficulty be chosen so the Responder's load stays close to the maximum it can tolerate. It is also RECOMMENDED to dynamically adjust the puzzle difficulty according to the Responder's current load 📈

If the cookie is generated as suggested in Section 2.6 of [RFC7296], then an attacker can use the same SPIi and the same Ni for several requests from the same IPi. This results in the same cookies being generated for those requests until the Responder changes its cookie generation secret. Since cookies are an input to puzzles in the IKE_SA_INIT exchange, generating the same cookies lets the attacker reuse puzzle solutions and bypass the proof-of-work requirement 🕵️‍♀️ The attacker only gets limited benefit, though: once the half-open SA is created by the Responder, all later initial requests with the same IPi and SPIi get treated as retransmissions and discarded by the Responder. However, once that half-open SA expires and is deleted, the attacker can create a new one for free if the Responder hasn't changed its cookie generation secret yet 🙈

The Responder can use various countermeasures to completely eliminate or mitigate this scenario 🛡️ First, the Responder can change its cookie generation secret frequently, especially under attack, as recommended in Section 2.6 of [RFC7296]. For example, if the Responder keeps two values of the secret (current and previous) and the secret lifetime is no more than half of the current half-open SA retention time (see Section 4.1), then the attacker can't benefit from reusing a puzzle solution 🎉 But heads up, a really short cookie generation secret lifetime could hurt weak legit Initiators, since it could take them too long to solve puzzles, and their solutions would get thrown out if the secret has already changed a few times 😩

Another approach for the Responder is to modify the cookie generation algorithm so the generated cookies are always different, or only repeat within a short time period 🦋 If the Responder includes a timestamp in <AdditionalInfo> as suggested in Section 7.1.1.3, then cookies only repeat within a short interval equal to the timestamp resolution ⏱️ Another option is to keep a global counter that increments every time a cookie is generated and include that counter in <AdditionalInfo>. This makes every cookie unique 💜

Implementations MUST use one of the above (or some other) countermeasures to completely eliminate or make insignificant the possible benefit an attacker can get from reusing puzzle solutions. Note that this issue doesn't exist in IKE_AUTH puzzles (Section 7.2), since those puzzles are always unique if the Responder generates SPIr and Nr randomly in accordance with [RFC7296] ✨

Solving puzzles uses a lot of CPU, which increases power consumption 🔋 That extra drain can hurt battery-powered Initiators like mobile phones or some Internet of Things (IoT) devices. If puzzles are too hard, the extra power use may seem unacceptable to some Initiators. The Responder SHOULD take this into consideration when choosing puzzle difficulty and when selecting what percentage of Initiators are allowed to reject solving puzzles. See Section 7.1.4 for details 🧐

If the Initiator uses NULL Authentication [RFC7619], then its identity is never verified. Attackers may use this to perform a DoS attack after the IKE SA is established 😱 Responders that allow unauthenticated Initiators to connect MUST be prepared to deal with various kinds of DoS attacks even after the IKE SA is created. See Section 5 for details.

To prevent amplification attacks, implementations MUST strictly follow the retransmission rules described in Section 2.1 of [RFC7296] 🚫

11. IANA Considerations 📋

This document defines a new payload in the "IKEv2 Payload Types" registry:

  54       Puzzle Solution                   PS

This document also defines a new Notify Message Type in the "IKEv2 Notify Message Types - Status Types" registry:

  16434    PUZZLE

12. References 📚

12.1. Normative References 💎

[IKEV2-IANA]
           IANA, "Internet Key Exchange Version 2 (IKEv2)
           Parameters",
           <http://www.iana.org/assignments/ikev2-parameters>.

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <http://www.rfc-editor.org/info/rfc2119>.

[RFC5723]  Sheffer, Y. and H. Tschofenig, "Internet Key Exchange
           Protocol Version 2 (IKEv2) Session Resumption", RFC 5723,
           DOI 10.17487/RFC5723, January 2010,
           <http://www.rfc-editor.org/info/rfc5723>.

[RFC7296]  Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
           Kivinen, "Internet Key Exchange Protocol Version 2
           (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
           2014, <http://www.rfc-editor.org/info/rfc7296>.

[RFC7383]  Smyslov, V., "Internet Key Exchange Protocol Version 2
           (IKEv2) Message Fragmentation", RFC 7383,
           DOI 10.17487/RFC7383, November 2014,
           <http://www.rfc-editor.org/info/rfc7383>.

12.2. Informative References 🌷

[BITCOINS] Nakamoto, S., "Bitcoin: A Peer-to-Peer Electronic Cash
           System", October 2008, <https://bitcoin.org/bitcoin.pdf>.

[RFC7619]  Smyslov, V. and P. Wouters, "The NULL Authentication
           Method in the Internet Key Exchange Protocol Version 2
           (IKEv2)", RFC 7619, DOI 10.17487/RFC7619, August 2015,
           <http://www.rfc-editor.org/info/rfc7619>.

[RFC7696]  Housley, R., "Guidelines for Cryptographic Algorithm
           Agility and Selecting Mandatory-to-Implement Algorithms",
           BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015,
           <http://www.rfc-editor.org/info/rfc7696>.

Acknowledgements 🫶

The authors thank Tero Kivinen, Yaron Sheffer, and Scott Fluhrer for their contributions to the design of the protocol. In particular, Tero Kivinen suggested the kind of puzzle where the task is to find a solution with a requested number of zero trailing bits 🧠 Yaron Sheffer and Scott Fluhrer suggested a way to make puzzle difficulty less erratic by solving several weaker puzzles. The authors also thank David Waltermire and Paul Wouters for their careful reviews of the document, Graham Bartlett for pointing out the possibility of an attack related to "Hash & URL", Stephen Farrell for catching the repeated cookie issue, and everyone else who commented on the document 💕

Authors' Addresses 📮

Yoav Nir
Check Point Software Technologies Ltd.
5 Hasolelim st.
Tel Aviv  6789735
Israel

Email: ynir.ietf@gmail.com


Valery Smyslov
ELVIS-PLUS
PO Box 81
Moscow (Zelenograd)  124460
Russian Federation

Phone: +7 495 276 0211
Email: svan@elvis.ru
📦 where this page comes from