draft-ietf-ipsecme-ddos-protection-10.txt   rfc8019.txt 
IPSecME Working Group Y. Nir Internet Engineering Task Force (IETF) Y. Nir
Internet-Draft Check Point Request for Comments: 8019 Check Point
Intended status: Standards Track V. Smyslov Category: Standards Track V. Smyslov
Expires: April 4, 2017 ELVIS-PLUS ISSN: 2070-1721 ELVIS-PLUS
October 1, 2016 November 2016
Protecting Internet Key Exchange Protocol version 2 (IKEv2) Protecting Internet Key Exchange Protocol Version 2 (IKEv2)
Implementations from Distributed Denial of Service Attacks Implementations from Distributed Denial-of-Service Attacks
draft-ietf-ipsecme-ddos-protection-10
Abstract Abstract
This document recommends implementation and configuration best This document recommends implementation and configuration best
practices for Internet Key Exchange Protocol version 2 (IKEv2) practices for Internet Key Exchange Protocol version 2 (IKEv2)
Responders, to allow them to resist Denial of Service and Distributed Responders, to allow them to resist Denial-of-Service and Distributed
Denial of Service attacks. Additionally, the document introduces a Denial-of-Service attacks. Additionally, the document introduces a
new mechanism called "Client Puzzles" that help accomplish this task. new mechanism called "Client Puzzles" that helps accomplish this
task.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on April 4, 2017. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc8019.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. The Vulnerability . . . . . . . . . . . . . . . . . . . . . . 3 3. The Vulnerability . . . . . . . . . . . . . . . . . . . . . . 3
4. Defense Measures while the IKE SA is being created . . . . . 6 4. Defense Measures While the IKE SA Is Being Created . . . . . 6
4.1. Retention Periods for Half-Open SAs . . . . . . . . . . . 6 4.1. Retention Periods for Half-Open SAs . . . . . . . . . . . 6
4.2. Rate Limiting . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Rate Limiting . . . . . . . . . . . . . . . . . . . . . . 7
4.3. The Stateless Cookie . . . . . . . . . . . . . . . . . . 7 4.3. The Stateless Cookie . . . . . . . . . . . . . . . . . . 8
4.4. Puzzles . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.4. Puzzles . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.5. Session Resumption . . . . . . . . . . . . . . . . . . . 10 4.5. Session Resumption . . . . . . . . . . . . . . . . . . . 11
4.6. Keeping computed Shared Keys . . . . . . . . . . . . . . 11 4.6. Keeping Computed Shared Keys . . . . . . . . . . . . . . 11
4.7. Preventing "Hash and URL" Certificate Encoding Attacks . 11 4.7. Preventing "Hash and URL" Certificate Encoding Attacks . 11
4.8. IKE Fragmentation . . . . . . . . . . . . . . . . . . . . 12 4.8. IKE Fragmentation . . . . . . . . . . . . . . . . . . . . 12
5. Defense Measures after an IKE SA is created . . . . . . . . . 12 5. Defense Measures after an IKE SA Is Created . . . . . . . . . 12
6. Plan for Defending a Responder . . . . . . . . . . . . . . . 13 6. Plan for Defending a Responder . . . . . . . . . . . . . . . 14
7. Using Puzzles in the Protocol . . . . . . . . . . . . . . . . 15 7. Using Puzzles in the Protocol . . . . . . . . . . . . . . . . 16
7.1. Puzzles in IKE_SA_INIT Exchange . . . . . . . . . . . . . 15 7.1. Puzzles in IKE_SA_INIT Exchange . . . . . . . . . . . . . 16
7.1.1. Presenting a Puzzle . . . . . . . . . . . . . . . . . 16 7.1.1. Presenting a Puzzle . . . . . . . . . . . . . . . . . 17
7.1.2. Solving a Puzzle and Returning the Solution . . . . . 18 7.1.2. Solving a Puzzle and Returning the Solution . . . . . 19
7.1.3. Computing a Puzzle . . . . . . . . . . . . . . . . . 19 7.1.3. Computing a Puzzle . . . . . . . . . . . . . . . . . 20
7.1.4. Analyzing Repeated Request . . . . . . . . . . . . . 20 7.1.4. Analyzing Repeated Request . . . . . . . . . . . . . 21
7.1.5. Deciding if to Serve the Request . . . . . . . . . . 21 7.1.5. Deciding Whether to Serve the Request . . . . . . . . 22
7.2. Puzzles in an IKE_AUTH Exchange . . . . . . . . . . . . . 22 7.2. Puzzles in an IKE_AUTH Exchange . . . . . . . . . . . . . 23
7.2.1. Presenting Puzzle . . . . . . . . . . . . . . . . . . 22 7.2.1. Presenting the Puzzle . . . . . . . . . . . . . . . . 24
7.2.2. Solving Puzzle and Returning the Solution . . . . . . 23 7.2.2. Solving the Puzzle and Returning the Solution . . . . 24
7.2.3. Computing the Puzzle . . . . . . . . . . . . . . . . 24 7.2.3. Computing the Puzzle . . . . . . . . . . . . . . . . 25
7.2.4. Receiving the Puzzle Solution . . . . . . . . . . . . 24 7.2.4. Receiving the Puzzle Solution . . . . . . . . . . . . 25
8. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 25 8. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 26
8.1. PUZZLE Notification . . . . . . . . . . . . . . . . . . . 25 8.1. PUZZLE Notification . . . . . . . . . . . . . . . . . . . 26
8.2. Puzzle Solution Payload . . . . . . . . . . . . . . . . . 26 8.2. Puzzle Solution Payload . . . . . . . . . . . . . . . . . 27
9. Operational Considerations . . . . . . . . . . . . . . . . . 26 9. Operational Considerations . . . . . . . . . . . . . . . . . 28
10. Security Considerations . . . . . . . . . . . . . . . . . . . 27 10. Security Considerations . . . . . . . . . . . . . . . . . . . 28
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 12.1. Normative References . . . . . . . . . . . . . . . . . . 30
13.1. Normative References . . . . . . . . . . . . . . . . . . 29 12.2. Informative References . . . . . . . . . . . . . . . . . 31
13.2. Informative References . . . . . . . . . . . . . . . . . 30 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
Denial of Service (DoS) attacks have always been considered a serious Denial-of-Service (DoS) attacks have always been considered a serious
threat. These attacks are usually difficult to defend against since threat. These attacks are usually difficult to defend against since
the amount of resources the victim has is always bounded (regardless the amount of resources the victim has is always bounded (regardless
of how high it is) and because some resources are required for of how high it is) and because some resources are required for
distinguishing a legitimate session from an attack. distinguishing a legitimate session from an attack.
The Internet Key Exchange protocol version 2 (IKEv2) described in The Internet Key Exchange Protocol version 2 (IKEv2) described in
[RFC7296] includes defense against DoS attacks. In particular, there [RFC7296] includes defense against DoS attacks. In particular, there
is a cookie mechanism that allows the IKE Responder to defend itself is a cookie mechanism that allows the IKE Responder to defend itself
against DoS attacks from spoofed IP-addresses. However, botnets have against DoS attacks from spoofed IP addresses. However, botnets have
become widespread, allowing attackers to perform Distributed Denial become widespread, allowing attackers to perform Distributed
of Service (DDoS) attacks, which are more difficult to defend Denial-of-Service (DDoS) attacks, which are more difficult to defend
against. This document presents recommendations to help the against. This document presents recommendations to help the
Responder counter (D)DoS attacks. It also introduces a new mechanism Responder counter DoS and DDoS attacks. It also introduces a new
-- "puzzles" -- that can help accomplish this task. mechanism -- "puzzles" -- that can help accomplish this task.
2. Conventions Used in This Document 2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
3. The Vulnerability 3. The Vulnerability
The IKE_SA_INIT Exchange described in Section 1.2 of [RFC7296] The IKE_SA_INIT exchange described in Section 1.2 of [RFC7296]
involves the Initiator sending a single message. The Responder involves the Initiator sending a single message. The Responder
replies with a single message and also allocates memory for a replies with a single message and also allocates memory for a
structure called a half-open IKE Security Association (SA). This structure called a half-open IKE Security Association (SA). This
half-open SA is later authenticated in the IKE_AUTH Exchange. If half-open SA is later authenticated in the IKE_AUTH exchange. If
that IKE_AUTH request never comes, the half-open SA is kept for an that IKE_AUTH request never comes, the half-open SA is kept for an
unspecified amount of time. Depending on the algorithms used and unspecified amount of time. Depending on the algorithms used and
implementation, such a half-open SA will use from around 100 bytes to implementation, such a half-open SA will use from around one hundred
several thousands bytes of memory. to several thousand bytes of memory.
This creates an easy attack vector against an IKE Responder. This creates an easy attack vector against an IKE Responder.
Generating the IKE_SA_INIT request is cheap. Sending large amounts Generating the IKE_SA_INIT request is cheap. Sending large amounts
of IKE_SA_INIT requests can cause a Responder to use up all its of IKE_SA_INIT requests can cause a Responder to use up all its
resources. If the Responder tries to defend against this by resources. If the Responder tries to defend against this by
throttling new requests, this will also prevent legitimate Initiators throttling new requests, this will also prevent legitimate Initiators
from setting up IKE SAs. from setting up IKE SAs.
An obvious defense, which is described in Section 4.2, is limiting An obvious defense, which is described in Section 4.2, is limiting
the number of half-open SAs opened by a single peer. However, since the number of half-open SAs opened by a single peer. However, since
all that is required is a single packet, an attacker can use multiple all that is required is a single packet, an attacker can use multiple
spoofed source IP addresses. spoofed source IP addresses.
If we break down what a Responder has to do during an initial If we break down what a Responder has to do during an initial
exchange, there are three stages: exchange, there are three stages:
1. When the IKE_SA_INIT request arrives, the Responder: 1. When the IKE_SA_INIT request arrives, the Responder:
* Generates or re-uses a Diffie-Hellman (D-H) private part. * Generates or reuses a Diffie-Hellman (DH) private part.
* Generates a Responder Security Parameter Index (SPI). * Generates a Responder Security Parameter Index (SPI).
* Stores the private part and peer public part in a half-open SA * Stores the private part and peer public part in a half-open SA
database. database.
2. When the IKE_AUTH request arrives, the Responder: 2. When the IKE_AUTH request arrives, the Responder:
* Derives the keys from the half-open SA. * Derives the keys from the half-open SA.
* Decrypts the request. * Decrypts the request.
3. If the IKE_AUTH request decrypts properly: 3. If the IKE_AUTH request decrypts properly, the Responder:
* Validates the certificate chain (if present) in the IKE_AUTH * Validates the certificate chain (if present) in the IKE_AUTH
request. request.
The fourth stage where the Responder creates the Child SA is not The fourth stage where the Responder creates the Child SA is not
reached by attackers who cannot pass the authentication step. reached by attackers who cannot pass the authentication step.
Stage #1 is pretty light on CPU power, but requires some storage, and Stage #1 is pretty light on CPU usage, but requires some storage, and
it's very light for the Initiator as well. Stage #2 includes it's very light for the Initiator as well. Stage #2 includes
private-key operations, so it is much heavier CPU-wise. Stage #3 may private-key operations, so it is much heavier CPU-wise. Stage #3 may
include public key operations if certificates are involved. These include public key operations if certificates are involved. These
operations are often more computationly expensive than those operations are often more computationally expensive than those
performed at stage #2. performed at stage #2.
To attack such a Responder, an attacker can attempt either to exhaust To attack such a Responder, an attacker can attempt to exhaust either
memory or to exhaust CPU. Without any protection, the most efficient memory or CPU. Without any protection, the most efficient attack is
attack is to send multiple IKE_SA_INIT requests and exhaust memory. to send multiple IKE_SA_INIT requests and exhaust memory. This is
This is easy because IKE_SA_INIT requests are cheap. easy because IKE_SA_INIT requests are cheap.
There are obvious ways for the Responder to protect itself without There are obvious ways for the Responder to protect itself without
changes to the protocol. It can reduce the time that an entry changes to the protocol. It can reduce the time that an entry
remains in the half-open SA database, and it can limit the amount of remains in the half-open SA database, and it can limit the amount of
concurrent half-open SAs from a particular address or prefix. The concurrent half-open SAs from a particular address or prefix. The
attacker can overcome this by using spoofed source addresses. attacker can overcome this by using spoofed source addresses.
The stateless cookie mechanism from Section 2.6 of [RFC7296] prevents The stateless cookie mechanism from Section 2.6 of [RFC7296] prevents
an attack with spoofed source addresses. This doesn't completely an attack with spoofed source addresses. This doesn't completely
solve the issue, but it makes the limiting of half-open SAs by solve the issue, but it makes the limiting of half-open SAs by
address or prefix work. Puzzles, introduced in Section 4.4, address or prefix work. Puzzles, introduced in Section 4.4,
accomplish the same thing only more of it. They make it harder for accomplish the same thing -- only more of it. They make it harder
an attacker to reach the goal of getting a half-open SA. Puzzles do for an attacker to reach the goal of getting a half-open SA. Puzzles
not have to be so hard that an attacker cannot afford to solve a do not have to be so hard that an attacker cannot afford to solve a
single puzzle; it is enough that puzzles increase the cost of single puzzle; it is enough that puzzles increase the cost of
creating a half-open SAs, so the attacker is limited in the amount creating half-open SAs, so the attacker is limited in the amount they
they can create. can create.
Reducing the lifetime of an abandoned half-open SA also reduces the Reducing the lifetime of an abandoned half-open SA also reduces the
impact of such attacks. For example, if a half-open SA is kept for 1 impact of such attacks. For example, if a half-open SA is kept for 1
minute and the capacity is 60 thousand half-open SAs, an attacker minute and the capacity is 60,000 half-open SAs, an attacker would
would need to create one thousand half-open SAs per second. If the need to create 1,000 half-open SAs per second. If the retention time
retention time is reduced to 3 seconds, the attacker would need to is reduced to 3 seconds, the attacker would need to create 20,000
create 20 thousand half-open SAs per second to get the same result. half-open SAs per second to get the same result. By introducing a
By introducing a puzzle, each half-open SA becomes more expensive for puzzle, each half-open SA becomes more expensive for an attacker,
an attacker, making it more likely to prevent an exhaustion attack making it more likely to prevent an exhaustion attack against
against Responder memory. Responder memory.
At this point, filling up the half-open SA database is no longer the At this point, filling up the half-open SA database is no longer the
most efficient DoS attack. The attacker has two alternative attacks most efficient DoS attack. The attacker has two alternative attacks
to do better: to do better:
1. Go back to spoofed addresses and try to overwhelm the CPU that 1. Go back to spoofed addresses and try to overwhelm the CPU that
deals with generating cookies, or deals with generating cookies, or
2. Take the attack to the next level by also sending an IKE_AUTH 2. Take the attack to the next level by also sending an IKE_AUTH
request. request.
If an attacker is so powerfull that it is able to overwhelm the If an attacker is so powerful that it is able to overwhelm the
Responder's CPU that deals with generating cookies, then the attack Responder's CPU that deals with generating cookies, then the attack
cannot be dealt with at the IKE level and must be handled by means of cannot be dealt with at the IKE level and must be handled by means of
the Intrusion Prevention System (IPS) technology. the Intrusion Prevention System (IPS) technology.
On the other hand, the second alternative of sending an IKE_AUTH On the other hand, the second alternative of sending an IKE_AUTH
request is very cheap. It requires generating a proper IKE header request is very cheap. It requires generating a proper IKE header
with the correct IKE SPIs and a single Encrypted payload. The with the correct IKE SPIs and a single Encrypted payload. The
content of the payload is irrelevant and might be junk. The content of the payload is irrelevant and might be junk. The
Responder has to perform the relatively expensive key derivation, Responder has to perform the relatively expensive key derivation,
only to find that the MAC on the Encrypted payload on the IKE_AUTH only to find that the Message Authentication Code (MAC) on the
request fails the integrity check. If a Responder does not hold on Encrypted payload on the IKE_AUTH request fails the integrity check.
to the calculated SKEYSEED and SK_* keys (which it should in case a If a Responder does not hold on to the calculated SKEYSEED and SK_*
valid IKE_AUTH comes in later) this attack might be repeated on the keys (which it should in case a valid IKE_AUTH comes in later), this
same half-open SA. Puzzles make attacks of such sort more costly for attack might be repeated on the same half-open SA. Puzzles make
an attacker. See Section 7.2 for details. attacks of such sort more costly for an attacker. See Section 7.2
for details.
Here too, the number of half-open SAs that the attacker can achieve Here too, the number of half-open SAs that the attacker can achieve
is crucial, because each one allows the attacker to waste some CPU is crucial, because each one allows the attacker to waste some CPU
time. So making it hard to make many half-open SAs is important. time. So making it hard to make many half-open SAs is important.
A strategy against DDoS has to rely on at least 4 components: A strategy against DDoS has to rely on at least 4 components:
1. Hardening the half-open SA database by reducing retention time. 1. Hardening the half-open SA database by reducing retention time.
2. Hardening the half-open SA database by rate-limiting single IPs/ 2. Hardening the half-open SA database by rate-limiting single
prefixes. IPs/ prefixes.
3. Guidance on what to do when an IKE_AUTH request fails to decrypt. 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 4. Increasing the cost of half-open SAs up to what is tolerable for
legitimate clients. legitimate clients.
Puzzles are used as a solution for strategy #4. Puzzles are used as a solution for strategy #4.
4. Defense Measures while the IKE SA is being created 4. Defense Measures While the IKE SA Is Being Created
4.1. Retention Periods for Half-Open SAs 4.1. Retention Periods for Half-Open SAs
As a UDP-based protocol, IKEv2 has to deal with packet loss through As a UDP-based protocol, IKEv2 has to deal with packet loss through
retransmissions. Section 2.4 of [RFC7296] recommends "that messages retransmissions. Section 2.4 of [RFC7296] recommends "that messages
be retransmitted at least a dozen times over a period of at least be retransmitted at least a dozen times over a period of at least
several minutes before giving up". Many retransmission policies in several minutes before giving up." Many retransmission policies in
practice wait one or two seconds before retransmitting for the first practice wait one or two seconds before retransmitting for the first
time. time.
Because of this, setting the timeout on a half-open SA too low will Because of this, setting the timeout on a half-open SA too low will
cause it to expire whenever even one IKE_AUTH request packet is lost. cause it to expire whenever even one IKE_AUTH request packet is lost.
When not under attack, the half-open SA timeout SHOULD be set high When not under attack, the half-open SA timeout SHOULD be set high
enough that the Initiator will have enough time to send multiple enough that the Initiator will have enough time to send multiple
retransmissions, minimizing the chance of transient network retransmissions, minimizing the chance of transient network
congestion causing an IKE failure. congestion causing an IKE failure.
When the system is under attack, as measured by the amount of half- When the system is under attack, as measured by the amount of half-
open SAs, it makes sense to reduce this lifetime. The Responder open SAs, it makes sense to reduce this lifetime. The Responder
should still allow enough time for the round-trip, enough time for should still allow enough time for the round-trip, for the Initiator
the Initiator to derive the D-H shared value, and enough time to to derive the DH shared value, and to derive the IKE SA keys and
derive the IKE SA keys and the create the IKE_AUTH request. Two create the IKE_AUTH request. Two seconds is probably as low a value
seconds is probably as low a value as can realistically be used. as can realistically be used.
It could make sense to assign a shorter value to half-open SAs It could make sense to assign a shorter value to half-open SAs
originating from IP addresses or prefixes that are considered suspect originating from IP addresses or prefixes that are considered suspect
because of multiple concurrent half-open SAs. because of multiple concurrent half-open SAs.
4.2. Rate Limiting 4.2. Rate Limiting
Even with DDoS, the attacker has only a limited amount of nodes Even with DDoS, the attacker has only a limited amount of nodes
participating in the attack. By limiting the amount of half-open SAs participating in the attack. By limiting the amount of half-open SAs
that are allowed to exist concurrently with each such node, the total that are allowed to exist concurrently with each such node, the total
amount of half-open SAs is capped, as is the total amount of key amount of half-open SAs is capped, as is the total amount of key
derivations that the Responder is forced to complete. derivations that the Responder is forced to complete.
In IPv4 it makes sense to limit the number of half-open SAs based on In IPv4, it makes sense to limit the number of half-open SAs based on
IP address. Most IPv4 nodes are either directly attached to the IP address. Most IPv4 nodes are either directly attached to the
Internet using a routable address or are hidden behind a NAT device Internet using a routable address or hidden behind a NAT device with
with a single IPv4 external address. For IPv6, ISPs assign between a a single IPv4 external address. For IPv6, ISPs assign between a /48
/48 and a /64, so it does not make sense for rate-limiting to work on and a /64, so it does not make sense for rate limiting to work on
single IPv6 IPs. Instead, ratelimits should be done based on either single IPv6 IPs. Instead, rate limits should be done based on either
the /48 or /64 of the misbehaving IPv6 address observed. the /48 or /64 of the misbehaving IPv6 address observed.
The number of half-open SAs is easy to measure, but it is also The number of half-open SAs is easy to measure, but it is also
worthwhile to measure the number of failed IKE_AUTH exchanges. If worthwhile to measure the number of failed IKE_AUTH exchanges. If
possible, both factors should be taken into account when deciding possible, both factors should be taken into account when deciding
which IP address or prefix is considered suspicious. which IP address or prefix is considered suspicious.
There are two ways to rate-limit a peer address or prefix: 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 1. Hard Limit -- where the number of half-open SAs is capped, and
further IKE_SA_INIT requests are rejected. any further IKE_SA_INIT requests are rejected.
2. Soft Limit - where if a set number of half-open SAs exist for a 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 particular address or prefix, any IKE_SA_INIT request will be
required to solve a puzzle. required to solve a puzzle.
The advantage of the hard limit method is that it provides a hard cap The advantage of the hard limit method is that it provides a hard cap
on the amount of half-open SAs that the attacker is able to create. on the amount of half-open SAs that the attacker is able to create.
The disadvantage is that it allows the attacker to block IKE The disadvantage is that it allows the attacker to block IKE
initiation from small parts of the Internet. For example, if an initiation from small parts of the Internet. For example, if a
network service provider or some establishment offers Internet network service provider or some establishment offers Internet
connectivity to its customers or employees through an IPv4 NAT connectivity to its customers or employees through an IPv4 NAT
device, a single malicious customer can create enough half-open SAs device, a single malicious customer can create enough half-open SAs
to fill the quota for the NAT device external IP address. Legitimate to fill the quota for the NAT device external IP address. Legitimate
Initiators on the same network will not be able to initiate IKE. Initiators on the same network will not be able to initiate IKE.
The advantage of a soft limit is that legitimate clients can always The advantage of a soft limit is that legitimate clients can always
connect. The disadvantage is that an adversary with sufficient CPU connect. The disadvantage is that an adversary with sufficient CPU
resources can still effectively DoS the Responder. resources can still effectively DoS the Responder.
Regardless of the type of rate-limiting used, legitimate initiators Regardless of the type of rate limiting used, legitimate Initiators
that are not on the same network segments as the attackers will not that are not on the same network segments as the attackers will not
be affected. This is very important as it reduces the adverse impact be affected. This is very important as it reduces the adverse impact
caused by the measures used to counteract the attack, and allows most caused by the measures used to counteract the attack and allows most
initiators to keep working even if they do not support puzzles. Initiators to keep working even if they do not support puzzles.
4.3. The Stateless Cookie 4.3. The Stateless Cookie
Section 2.6 of [RFC7296] offers a mechanism to mitigate DoS attacks: Section 2.6 of [RFC7296] offers a mechanism to mitigate DoS attacks:
the stateless cookie. When the server is under load, the Responder the stateless cookie. When the server is under load, the Responder
responds to the IKE_SA_INIT request with a calculated "stateless responds to the IKE_SA_INIT request with a calculated "stateless
cookie" - a value that can be re-calculated based on values in the cookie" -- a value that can be recalculated based on values in the
IKE_SA_INIT request without storing Responder-side state. The IKE_SA_INIT request without storing Responder-side state. The
Initiator is expected to repeat the IKE_SA_INIT request, this time Initiator is expected to repeat the IKE_SA_INIT request, this time
including the stateless cookie. This mechanism prevents DoS attacks including the stateless cookie. This mechanism prevents DoS attacks
from spoofed IP addresses, since an attacker needs to have a routable from spoofed IP addresses, since an attacker needs to have a routable
IP address to return the cookie. IP address to return the cookie.
Attackers that have multiple source IP addresses with return Attackers that have multiple source IP addresses with return
routability, such as in the case of botnets, can fill up a half-open routability, such as in the case of botnets, can fill up a half-open
SA table anyway. The cookie mechanism limits the amount of allocated SA table anyway. The cookie mechanism limits the amount of allocated
state to the number of attackers, multiplied by the number of half- state to the number of attackers, multiplied by the number of half-
open SAs allowed per peer address, multiplied by the amount of state open SAs allowed per peer address, multiplied by the amount of state
allocated for each half-open SA. With typical values this can easily allocated for each half-open SA. With typical values, this can
reach hundreds of megabytes. easily reach hundreds of megabytes.
4.4. Puzzles 4.4. Puzzles
The puzzle introduced here extends the cookie mechanism of [RFC7296]. The puzzle introduced here extends the cookie mechanism of [RFC7296].
It is loosely based on the proof-of-work technique used in Bitcoins It is loosely based on the proof-of-work technique used in Bitcoin
[bitcoins]. Puzzles set an upper bound, determined by the attacker's [BITCOINS]. Puzzles set an upper bound, determined by the attacker's
CPU, to the number of negotiations the attacker can initiate in a CPU, to the number of negotiations the attacker can initiate in a
unit of time. unit of time.
A puzzle is sent to the Initiator in two cases: A puzzle is sent to the Initiator in two cases:
o The Responder is so overloaded that no half-open SAs may be o The Responder is so overloaded that no half-open SAs may be
created without solving a puzzle, or created without solving a puzzle, or
o The Responder is not too loaded, but the rate-limiting method o The Responder is not too loaded, but the rate-limiting method
described in Section 4.2 prevents half-open SAs from being created described in Section 4.2 prevents half-open SAs from being created
with this particular peer address or prefix without first solving with this particular peer address or prefix without first solving
a puzzle. a puzzle.
When the Responder decides to send the challenge to solve a puzzle in When the Responder decides to send the challenge to solve a puzzle in
response to a IKE_SA_INIT request, the message includes at least response to an IKE_SA_INIT request, the message includes at least
three components: three components:
1. Cookie - this is calculated the same as in [RFC7296], i.e. the 1. Cookie -- this is calculated the same as in [RFC7296], i.e., the
process of generating the cookie is not specified. process of generating the cookie is not specified.
2. Algorithm, this is the identifier of a Pseudo-Random Function 2. Algorithm, this is the identifier of a Pseudorandom Function
(PRF) algorithm, one of those proposed by the Initiator in the SA (PRF) algorithm, one of those proposed by the Initiator in the SA
payload. payload.
3. Zero Bit Count (ZBC). This is a number between 8 and 255 (or a 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 special value - 0; see Section 7.1.1.1) that represents the
length of the zero-bit run at the end of the output of the PRF length of the zero-bit run at the end of the output of the PRF
function calculated over the cookie that the Initiator is to function calculated over the cookie that the Initiator is to
send. The values 1-8 are explicitly excluded, because they send. The values 1-8 are explicitly excluded, because they
create a puzzle that is too easy to solve. Since the mechanism create a puzzle that is too easy to solve. Since the mechanism
is supposed to be stateless for the Responder, either the same is supposed to be stateless for the Responder, either the same
ZBC is used for all Initiators, or the ZBC is somehow encoded in ZBC is used for all Initiators or the ZBC is somehow encoded in
the cookie. If it is global then it means that this value is the the cookie. If it is global, then it means that this value is
same for all the Initiators who are receiving puzzles at any the same for all the Initiators who are receiving puzzles at any
given point of time. The Responder, however, may change this given point of time. The Responder, however, may change this
value over time depending on its load. value over time depending on its load.
Upon receiving this challenge, the Initiator attempts to calculate Upon receiving this challenge, the Initiator attempts to calculate
the PRF output using different keys. When enough keys are found such the PRF output using different keys. When enough keys are found such
that the resulting PRF output calculated using each of them has a that the resulting PRF output calculated using each of them has a
sufficient number of trailing zero bits, that result is sent to the sufficient number of trailing zero bits, that result is sent to the
Responder. Responder.
The reason for using several keys in the results, rather than just The reason for using several keys in the results, rather than just
one key, is to reduce the variance in the time it takes the initiator one key, is to reduce the variance in the time it takes the Initiator
to solve the puzzle. We have chosen the number of keys to be four to solve the puzzle. We have chosen the number of keys to be four
(4) as a compromise between the conflicting goals of reducing (4) as a compromise between the conflicting goals of reducing
variance and reducing the work the Responder needs to perform to variance and reducing the work the Responder needs to perform to
verify the puzzle solution. verify the puzzle solution.
When receiving a request with a solved puzzle, the Responder verifies When receiving a request with a solved puzzle, the Responder verifies
two things: two things:
o That the cookie is indeed valid. o That the cookie is indeed valid.
o That the results of PRF of the transmitted cookie calculated with o That the results of PRF of the transmitted cookie calculated with
the transmitted keys has a sufficient number of trailing zero the transmitted keys has a sufficient number of trailing zero
bits. bits.
Example 1: Suppose the calculated cookie is Example 1: Suppose the calculated cookie is
739ae7492d8a810cf5e8dc0f9626c9dda773c5a3 (20 octets), the algorithm 739ae7492d8a810cf5e8dc0f9626c9dda773c5a3 (20 octets), the algorithm
is PRF-HMAC-SHA256, and the required number of zero bits is 18. is PRF-HMAC-SHA256, and the required number of zero bits is 18.
After successively trying a bunch of keys, the Initiator finds the After successively trying a bunch of keys, the Initiator finds the
following four 3-octet keys that work: following four 3-octet keys that work:
+--------+----------------------------------+----------+ +--------+----------------------------------+----------------+
| Key | Last 32 Hex PRF Digits | # 0-bits | | Key | Last 32 Hex PRF Digits | # of Zero Bits |
+--------+----------------------------------+----------+ +--------+----------------------------------+----------------+
| 061840 | e4f957b859d7fb1343b7b94a816c0000 | 18 | | 061840 | e4f957b859d7fb1343b7b94a816c0000 | 18 |
| 073324 | 0d4233d6278c96e3369227a075800000 | 23 | | 073324 | 0d4233d6278c96e3369227a075800000 | 23 |
| 0c8a2a | 952a35d39d5ba06709da43af40700000 | 20 | | 0c8a2a | 952a35d39d5ba06709da43af40700000 | 20 |
| 0d94c8 | 5a0452b21571e401a3d00803679c0000 | 18 | | 0d94c8 | 5a0452b21571e401a3d00803679c0000 | 18 |
+--------+----------------------------------+----------+ +--------+----------------------------------+----------------+
Table 1: Four solutions for the 18-bit puzzle Table 1: Four Solutions for the 18-Bit Puzzle
Example 2: Same cookie, but modify the required number of zero bits Example 2: Same cookie, but modify the required number of zero bits
to 22. The first 4-octet keys that work to satisfy that requirement to 22. The first 4-octet keys that work to satisfy that requirement
are 005d9e57, 010d8959, 0110778d, and 01187e37. Finding these are 005d9e57, 010d8959, 0110778d, and 01187e37. Finding these
requires 18,382,392 invocations of the PRF. requires 18,382,392 invocations of the PRF.
+----------+-------------------------------+ +----------------+-------------------------------+
| # 0-bits | Time to Find 4 keys (seconds) | | # of Zero Bits | Time to Find 4 Keys (Seconds) |
+----------+-------------------------------+ +----------------+-------------------------------+
| 8 | 0.0025 | | 8 | 0.0025 |
| 10 | 0.0078 | | 10 | 0.0078 |
| 12 | 0.0530 | | 12 | 0.0530 |
| 14 | 0.2521 | | 14 | 0.2521 |
| 16 | 0.8504 | | 16 | 0.8504 |
| 17 | 1.5938 | | 17 | 1.5938 |
| 18 | 3.3842 | | 18 | 3.3842 |
| 19 | 3.8592 | | 19 | 3.8592 |
| 20 | 10.8876 | | 20 | 10.8876 |
+----------+-------------------------------+ +----------------+-------------------------------+
Table 2: The time needed to solve a puzzle of various difficulty for Table 2: The Time Needed to Solve a Puzzle of Various Difficulty for
the cookie = 739ae7492d8a810cf5e8dc0f9626c9dda773c5a3 the Cookie 39ae7492d8a810cf5e8dc0f9626c9dda773c5a3
The figures above were obtained on a 2.4 GHz single core i5. Run The figures above were obtained on a 2.4 GHz single-core Intel i5
times can be halved or quartered with multi-core code, but would be processor in a 2013 Apple MacBook Pro. Run times can be halved or
longer on mobile phone processors, even if those are multi-core as quartered with multi-core code, but they would be longer on mobile
well. With these figures 18 bits is believed to be a reasonable phone processors, even if those are multi-core as well. With these
choice for puzzle level difficulty for all Initiators, and 20 bits is figures, 18 bits is believed to be a reasonable choice for puzzle
acceptable for specific hosts/prefixes. level difficulty for all Initiators, and 20 bits is acceptable for
specific hosts/prefixes.
Using puzzles mechanism in the IKE_SA_INIT exchange is described in Using the puzzles mechanism in the IKE_SA_INIT exchange is described
Section 7.1. in Section 7.1.
4.5. Session Resumption 4.5. Session Resumption
When the Responder is under attack, it SHOULD prefer previously When the Responder is under attack, it SHOULD prefer previously
authenticated peers who present a Session Resumption ticket authenticated peers who present a Session Resumption ticket
[RFC5723]. However, the Responder SHOULD NOT serve resumed [RFC5723]. However, the Responder SHOULD NOT serve resumed
Initiators exclusively because dropping all IKE_SA_INIT requests Initiators exclusively because dropping all IKE_SA_INIT requests
would lock out legitimate Initiators that have no resumption ticket. would lock out legitimate Initiators that have no resumption ticket.
When under attack the Responder SHOULD require Initiators presenting When under attack, the Responder SHOULD require Initiators presenting
Session Resumption Tickets to pass a return routability check by Session Resumption tickets to pass a return routability check by
including the COOKIE notification in the IKE_SESSION_RESUME response including the COOKIE notification in the IKE_SESSION_RESUME response
message, as described in Section 4.3.2. of [RFC5723]. Note that the message, as described in Section 4.3.2. of [RFC5723]. Note that the
Responder SHOULD cache tickets for a short time to reject reused Responder SHOULD cache tickets for a short time to reject reused
tickets (Section 4.3.1), and therefore there should be no issue of tickets (Section 4.3.1 of [RFC5723]); therefore, there should be no
half-open SAs resulting from replayed IKE_SESSION_RESUME messages. issue of half-open SAs resulting from replayed IKE_SESSION_RESUME
messages.
Several kinds of DoS attacks are possible on servers supported IKE Several kinds of DoS attacks are possible on servers supported by IKE
Session Resumption. See Section 9.3 of [RFC5723] for details. Session Resumption. See Section 9.3 of [RFC5723] for details.
4.6. Keeping computed Shared Keys 4.6. Keeping Computed Shared Keys
Once the IKE_SA_INIT exchange is finished, the Responder is waiting Once the IKE_SA_INIT exchange is finished, the Responder is waiting
for the first message of the IKE_AUTH exchange from the Initiator. for the first message of the IKE_AUTH exchange from the Initiator.
At this point the Initiator is not yet authenticated, and this fact At this point, the Initiator is not yet authenticated, and this fact
allows an attacker to perform an attack, described in Section 3. allows an attacker to perform an attack, described in Section 3.
Instead of sending properly formed and encrypted IKE_AUTH message the Instead of sending a properly formed and encrypted IKE_AUTH message,
attacker can just send arbitrary data, forcing the Responder to the attacker can just send arbitrary data, forcing the Responder to
perform costly CPU operations to compute SK_* keys. perform costly CPU operations to compute SK_* keys.
If the received IKE_AUTH message failed to decrypt correctly (or If the received IKE_AUTH message failed to decrypt correctly (or
failed to pass ICV check), then the Responder SHOULD still keep the failed to pass the Integrity Check Value (ICV) check), then the
computed SK_* keys, so that if it happened to be an attack, then an Responder SHOULD still keep the computed SK_* keys, so that if it
attacker cannot get advantage of repeating the attack multiple times happened to be an attack, then an attacker cannot get an advantage of
on a single IKE SA. The responder can also use puzzles in the repeating the attack multiple times on a single IKE SA. The
IKE_AUTH exchange as decribed in Section 7.2. 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 4.7. Preventing "Hash and URL" Certificate Encoding Attacks
In IKEv2 each side may use the "Hash and URL" Certificate Encoding to In IKEv2, each side may use the "Hash and URL" Certificate Encoding
instruct the peer to retrieve certificates from the specified to instruct the peer to retrieve certificates from the specified
location (see Section 3.6 of [RFC7296] for details). Malicious location (see Section 3.6 of [RFC7296] for details). Malicious
initiators can use this feature to mount a DoS attack on the Initiators can use this feature to mount a DoS attack on the
responder by providing an URL pointing to a large file possibly Responder by providing a URL pointing to a large file possibly
containing meaningless bits. While downloading the file the containing meaningless bits. While downloading the file, the
responder consumes CPU, memory and network bandwidth. Responder consumes CPU, memory, and network bandwidth.
To prevent this kind of attack, the responder should not blindly To prevent this kind of attack, the Responder should not blindly
download the whole file. Instead, it SHOULD first read the initial download the whole file. Instead, it SHOULD first read the initial
few bytes, decode the length of the ASN.1 structure from these bytes, few bytes, decode the length of the ASN.1 structure from these bytes,
and then download no more than the decoded number of bytes. Note, and then download no more than the decoded number of bytes. Note
that it is always possible to determine the length of ASN.1 that it is always possible to determine the length of ASN.1
structures used in IKEv2, if they are DER-encoded, by analyzing the structures used in IKEv2, if they are DER-encoded, by analyzing the
first few bytes. However, since the content of the file being first few bytes. However, since the content of the file being
downloaded can be under the attacker's control, implementations downloaded can be under the attacker's control, implementations
should not blindly trust the decoded length and SHOULD check whether should not blindly trust the decoded length and SHOULD check whether
it makes sense before continuing to download the file. it makes sense before continuing to download the file.
Implementations SHOULD also apply a configurable hard limit to the Implementations SHOULD also apply a configurable hard limit to the
number of pulled bytes and SHOULD provide an ability for an number of pulled bytes and SHOULD provide an ability for an
administrator to either completely disable this feature or to limit administrator to either completely disable this feature or limit its
its use to a configurable list of trusted URLs. use to a configurable list of trusted URLs.
4.8. IKE Fragmentation 4.8. IKE Fragmentation
IKE Fragmentation described in [RFC7383] allows IKE peers to avoid IP IKE fragmentation described in [RFC7383] allows IKE peers to avoid IP
fragmentation of large IKE messages. Attackers can mount several fragmentation of large IKE messages. Attackers can mount several
kinds of DoS attacks using IKE Fragmentation. See Section 5 of kinds of DoS attacks using IKE fragmentation. See Section 5 of
[RFC7383] for details on how to mitigate these attacks. [RFC7383] for details on how to mitigate these attacks.
5. Defense Measures after an IKE SA is created 5. Defense Measures after an IKE SA Is Created
Once an IKE SA is created there usually are only a limited amount of Once an IKE SA is created, there is usually only a limited amount of
IKE messages exchanged. This IKE traffic consists of exchanges aimed IKE messages exchanged. This IKE traffic consists of exchanges aimed
to create additional Child SAs, IKE rekeys, IKE deletions and IKE to create additional Child SAs, IKE rekeys, IKE deletions, and IKE
liveness tests. Some of these exchanges require relatively little liveness tests. Some of these exchanges require relatively little
resources (like liveness check), while others may be resource resources (like a liveness check), while others may be resource
consuming (like creating or rekeying Child SA with D-H exchange). consuming (like creating or rekeying a Child SA with DH exchange).
Since any endpoint can initiate a new exchange, there is a Since any endpoint can initiate a new exchange, there is a
possibility that a peer would initiate too many exchanges that could possibility that a peer would initiate too many exchanges that could
exhaust host resources. For example, the peer can perform endless exhaust host resources. For example, the peer can perform endless
continuous Child SA rekeying or create an overwhelming number of continuous Child SA rekeying or create an overwhelming number of
Child SAs with the same Traffic Selectors etc. Such behavior can be Child SAs with the same Traffic Selectors, etc. Such behavior can be
caused by broken implementations, misconfiguration, or as an caused by broken implementations, misconfiguration, or as an
intentional attack. The latter becomes more of a real threat if the intentional attack. The latter becomes more of a real threat if the
peer uses NULL Authentication, as described in [RFC7619]. In this peer uses NULL Authentication, as described in [RFC7619]. In this
case the peer remains anonymous, allowing it to escape any case, the peer remains anonymous, allowing it to escape any
responsibility for its behaviour. See Section 3 of [RFC7619] for responsibility for its behavior. See Section 3 of [RFC7619] for
details on how to mitigate attacks when using NULL Authentication. details on how to mitigate attacks when using NULL Authentication.
The following recommendations apply especially for NULL Authenticated The following recommendations apply especially for NULL-authenticated
IKE sessions, but also apply to authenticated IKE sessions, with the IKE sessions, but also apply to authenticated IKE sessions, with the
difference that in the latter case, the identified peer can be locked difference that in the latter case, the identified peer can be locked
out. out.
o If the IKEv2 window size is greater than one, peers are able to o If the IKEv2 window size is greater than one, peers are able to
initiate multiple simultaneous exchanges that increase host initiate multiple simultaneous exchanges that increase host
resource consumption. Since there is no way in IKEv2 to decrease resource consumption. Since there is no way in IKEv2 to decrease
window size once it has been increased (see Section 2.3 of window size once it has been increased (see Section 2.3 of
[RFC7296]), the window size cannot be dynamically adjusted [RFC7296]), the window size cannot be dynamically adjusted
depending on the load. It is NOT RECOMMENDED to allow an IKEv2 depending on the load. It is NOT RECOMMENDED to allow an IKEv2
window size greater than one when NULL Authentication has been window size greater than one when NULL Authentication has been
used. used.
o If a peer initiates an abusive amount of CREATE_CHILD_SA exchanges o If a peer initiates an abusive amount of CREATE_CHILD_SA exchanges
to rekey IKE SAs or Child SAs, the Responder SHOULD reply with to rekey IKE SAs or Child SAs, the Responder SHOULD reply with
TEMPORARY_FAILURE notifications indicating the peer must slow down TEMPORARY_FAILURE notifications indicating the peer must slow down
their requests. their requests.
o If a peer creates many Child SA with the same or overlapping o If a peer creates many Child SAs with the same or overlapping
Traffic Selectors, implementations MAY respond with the Traffic Selectors, implementations MAY respond with the
NO_ADDITIONAL_SAS notification. NO_ADDITIONAL_SAS notification.
o If a peer initiates many exchanges of any kind, the Responder MAY o If a peer initiates many exchanges of any kind, the Responder MAY
introduce an artificial delay before responding to each request introduce an artificial delay before responding to each request
message. This delay would decrease the rate the Responder needs message. This delay would decrease the rate the Responder needs
to process requests from any particular peer, and frees up to process requests from any particular peer and frees up
resources on the Responder that can be used for answering resources on the Responder that can be used for answering
legitimate clients. If the Responder receives retransmissions of legitimate clients. If the Responder receives retransmissions of
the request message during the delay period, the retransmitted the request message during the delay period, the retransmitted
messages MUST be silently discarded. The delay must be short messages MUST be silently discarded. The delay must be short
enough to avoid legitimate peers deleting the IKE SA due to a enough to avoid legitimate peers deleting the IKE SA due to a
timeout. It is believed that a few seconds is enough. Note timeout. It is believed that a few seconds is enough. Note,
however, that even a few seconds may be too long when settings 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 rely on an immediate response to the request message, e.g., for
purposes of quick detection of a dead peer. the purposes of quick detection of a dead peer.
o If these counter-measures are inefficient, implementations MAY o If these countermeasures are inefficient, implementations MAY
delete the IKE SA with an offending peer by sending Delete delete the IKE SA with an offending peer by sending Delete
Payload. Payload.
In IKE, a client can request various configuration attributes from In IKE, a client can request various configuration attributes from
server. Most often these attributes include internal IP addresses. the server. Most often, these attributes include internal IP
Malicious clients can try to exhaust a server's IP address pool by addresses. Malicious clients can try to exhaust a server's IP
continuously requesting a large number of internal addresses. Server address pool by continuously requesting a large number of internal
implementations SHOULD limit the number of IP addresses allocated to addresses. Server implementations SHOULD limit the number of IP
any particular client. Note, this is not possible with clients using addresses allocated to any particular client. Note, this is not
NULL Authentication, since their identity cannot be verified. possible with clients using NULL Authentication, since their identity
cannot be verified.
6. Plan for Defending a Responder 6. Plan for Defending a Responder
This section outlines a plan for defending a Responder from a DDoS This section outlines a plan for defending a Responder from a DDoS
attack based on the techniques described earlier. The numbers given attack based on the techniques described earlier. The numbers given
here are not normative, and their purpose is to illustrate the here are not normative, and their purpose is to illustrate the
configurable parameters needed for surviving DDoS attacks. configurable parameters needed for surviving DDoS attacks.
Implementations are deployed in different environments, so it is Implementations are deployed in different environments, so it is
RECOMMENDED that the parameters be settable. For example, most RECOMMENDED that the parameters be settable. For example, most
commercial products are required to undergo benchmarking where the commercial products are required to undergo benchmarking where the
IKE SA establishment rate is measured. Benchmarking is IKE SA establishment rate is measured. Benchmarking is
indistinguishable from a DoS attack and the defenses described in indistinguishable from a DoS attack, and the defenses described in
this document may defeat the benchmark by causing exchanges to fail this document may defeat the benchmark by causing exchanges to fail
or take a long time to complete. Parameters SHOULD be tunable to or to take a long time to complete. Parameters SHOULD be tunable to
allow for benchmarking (if only by turning DDoS protection off). allow for benchmarking (if only by turning DDoS protection off).
Since all countermeasures may cause delays and additional work for Since all countermeasures may cause delays and additional work for
the Initiators, they SHOULD NOT be deployed unless an attack is the Initiators, they SHOULD NOT be deployed unless an attack is
likely to be in progress. To minimize the burden imposed on likely to be in progress. To minimize the burden imposed on
Initiators, the Responder should monitor incoming IKE requests, for Initiators, the Responder should monitor incoming IKE requests for
two scenarios: two scenarios:
1. A general DDoS attack. Such an attack is indicated by a high 1. A general DDoS attack. Such an attack is indicated by a high
number of concurrent half-open SAs, a high rate of failed number of concurrent half-open SAs, a high rate of failed
IKE_AUTH exchanges, or a combination of both. For example, IKE_AUTH exchanges, or a combination of both. For example,
consider a Responder that has 10,000 distinct peers of which at consider a Responder that has 10,000 distinct peers of which at
peak 7,500 concurrently have VPN tunnels. At the start of peak peak, 7,500 concurrently have VPN tunnels. At the start of peak
time, 600 peers might establish tunnels within any given minute, time, 600 peers might establish tunnels within any given minute,
and tunnel establishment (both IKE_SA_INIT and IKE_AUTH) takes and tunnel establishment (both IKE_SA_INIT and IKE_AUTH) takes
anywhere from 0.5 to 2 seconds. For this Responder, we expect anywhere from 0.5 to 2 seconds. For this Responder, we expect
there to be less than 20 concurrent half-open SAs, so having 100 there to be less than 20 concurrent half-open SAs, so having 100
concurrent half-open SAs can be interpreted as an indication of concurrent half-open SAs can be interpreted as an indication of
an attack. Similarly, IKE_AUTH request decryption failures an attack. Similarly, IKE_AUTH request decryption failures
should never happen. Supposing that the tunnels are established should never happen. Supposing that the tunnels are established
using EAP (see Section 2.16 of [RFC7296]), users may be expected using Extensible Authentication Protocol (EAP) (see Section 2.16
to enter a wrong password about 20% of the time. So we'd expect of [RFC7296]), users may be expected to enter a wrong password
125 wrong password failures a minute. If we get IKE_AUTH about 20% of the time. So we'd expect 125 wrong password
decryption failures from multiple sources more than once per failures a minute. If we get IKE_AUTH decryption failures from
second, or EAP failures more than 300 times per minute, this can multiple sources more than once per second, or EAP failures more
also be an indication of a DDoS attack. 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. Such an attack 2. An attack from a particular IP address or prefix. Such an attack
is indicated by an inordinate amount of half-open SAs from a is indicated by an inordinate amount of half-open SAs from a
specific IP address or prefix, or an inordinate amount of specific IP address or prefix, or an inordinate amount of
IKE_AUTH failures. A DDoS attack may be viewed as multiple such IKE_AUTH failures. A DDoS attack may be viewed as multiple such
attacks. If these are mitigated successfully, there will not be attacks. If these are mitigated successfully, there will not be
a need to enact countermeasures on all Initiators. For example, a need to enact countermeasures on all Initiators. For example,
measures might be 5 concurrent half-open SAs, 1 decrypt failure, measures might be 5 concurrent half-open SAs, 1 decrypt failure,
or 10 EAP failures within a minute. or 10 EAP failures within a minute.
Note that using counter-measures against an attack from a particular Note that using countermeasures against an attack from a particular
IP address may be enough to avoid the overload on the half-open SA IP address may be enough to avoid the overload on the half-open SA
database. In this case the number of failed IKE_AUTH exchanges will database. In this case, the number of failed IKE_AUTH exchanges will
never exceed the threshold of attack detection. never exceed the threshold of attack detection.
When there is no general DDoS attack, it is suggested that no cookie 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 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 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 the puzzles are or prefix. The soft limit can be set to 3-5. If the puzzles are
used, the puzzle difficulty SHOULD be set to such a level (number of used, the puzzle difficulty SHOULD be set to such a level (number of
zero-bits) that all legitimate clients can handle it without degraded zero bits) that all legitimate clients can handle it without degraded
user experience. user experience.
As soon as any kind of attack is detected, either a lot of 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 initiations from multiple sources or a lot of initiations from a few
sources, it is best to begin by requiring stateless cookies from all sources, it is best to begin by requiring stateless cookies from all
Initiators. This will mitigate attacks based on IP address spoofing, Initiators. This will mitigate attacks based on IP address spoofing
and help avoid the need to impose a greater burden in the form of and help avoid the need to impose a greater burden in the form of
puzzles on the general population of Initiators. This makes the per- puzzles on the general population of Initiators. This makes the per-
node or per-prefix soft limit more effective. node or per-prefix soft limit more effective.
When cookies are activated for all requests and the attacker is still When cookies are activated for all requests and the attacker is still
managing to consume too many resources, the Responder MAY start to managing to consume too many resources, the Responder MAY start to
use puzzles for these requests or increase the difficulty of puzzles use puzzles for these requests or increase the difficulty of puzzles
imposed on IKE_SA_INIT requests coming from suspicious nodes/ imposed on IKE_SA_INIT requests coming from suspicious nodes/
prefixes. This should still be doable by all legitimate peers, but prefixes. This should still be doable by all legitimate peers, but
the use of puzzles at a higher difficulty may degrade the user the use of puzzles at a higher difficulty may degrade the user
experience, for example by taking up to 10 seconds to solve the experience, for example, by taking up to 10 seconds to solve the
puzzle. puzzle.
If the load on the Responder is still too great, and there are many 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 nodes causing multiple half-open SAs or IKE_AUTH failures, the
Responder MAY impose hard limits on those nodes. Responder MAY impose hard limits on those nodes.
If it turns out that the attack is very widespread and the hard caps If it turns out that the attack is very widespread and the hard caps
are not solving the issue, a puzzle MAY be imposed on all Initiators. are not solving the issue, a puzzle MAY be imposed on all Initiators.
Note that this is the last step, and the Responder should avoid this Note that this is the last step, and the Responder should avoid this
if possible. if possible.
7. Using Puzzles in the Protocol 7. Using Puzzles in the Protocol
This section describes how the puzzle mechanism is used in IKEv2. It This section describes how the puzzle mechanism is used in IKEv2. It
is organized as follows. The Section 7.1 describes using puzzles in is organized as follows. Section 7.1 describes using puzzles in the
the IKE_SA_INIT exchange and the Section 7.2 describes using puzzles IKE_SA_INIT exchange and Section 7.2 describes using puzzles in the
in the IKE_AUTH exchange. Both sections are divided into subsections IKE_AUTH exchange. Both sections are divided into subsections
describing how puzzles should be presented, solved and processed by describing how puzzles should be presented, solved, and processed by
the Initiator and the Responder. the Initiator and the Responder.
7.1. Puzzles in IKE_SA_INIT Exchange 7.1. Puzzles in IKE_SA_INIT Exchange
IKE Initiator indicates the desire to create a new IKE SA by sending The IKE Initiator indicates the desire to create a new IKE SA by
an IKE_SA_INIT request message. The message may optionally contain a sending an IKE_SA_INIT request message. The message may optionally
COOKIE notification if this is a repeated request performed after the contain a COOKIE notification if this is a repeated request performed
Responder's demand to return a cookie. after the Responder's demand to return a cookie.
HDR, [N(COOKIE),] SA, KE, Ni, [V+][N+] --> 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 According to the plan, described in Section 6, the IKE Responder
monitors incoming requests to detect whether it is under attack. If monitors incoming requests to detect whether it is under attack. If
the Responder learns that a (D)DoS attack is likely to be in the Responder learns that a DoS or DDoS attack is likely to be in
progress, then its actions depend on the volume of the attack. If progress, then its actions depend on the volume of the attack. If
the volume is moderate, then the Responder requests the Initiator to the volume is moderate, then the Responder requests the Initiator to
return a cookie. If the volume is high to such an extent that return a cookie. If the volume is high to such an extent that
puzzles need to be used for defense, then the Responder requests the puzzles need to be used for defense, then the Responder requests the
Initiator to solve a puzzle. Initiator to solve a puzzle.
The Responder MAY choose to process some fraction of IKE_SA_INIT The Responder MAY choose to process some fraction of IKE_SA_INIT
requests without presenting a puzzle while being under attack to requests without presenting a puzzle while being under attack to
allow legacy clients, that don't support puzzles, to have a chance to allow legacy clients, that don't support puzzles, to have a chance to
be served. The decision whether to process any particular request be served. The decision whether to process any particular request
must be probabilistic, with the probability depending on the must be probabilistic, with the probability depending on the
Responder's load (i.e. on the volume of attack). The requests that Responder's load (i.e., on the volume of attack). The requests that
don't contain the COOKIE notification MUST NOT participate in this don't contain the COOKIE notification MUST NOT participate in this
lottery. In other words, the Responder must first perform a return lottery. In other words, the Responder must first perform a return
routability check before allowing any legacy client to be served if routability check before allowing any legacy client to be served if
it is under attack. See Section 7.1.4 for details. it is under attack. See Section 7.1.4 for details.
7.1.1. Presenting a Puzzle 7.1.1. Presenting a Puzzle
If the Responder makes a decision to use puzzles, then it includes If the Responder makes a decision to use puzzles, then it includes
two notifications in its response message - the COOKIE notification two notifications in its response message -- the COOKIE notification
and the PUZZLE notification. Note that the PUZZLE notification MUST and the PUZZLE notification. Note that the PUZZLE notification MUST
always be accompanied with the COOKIE notification, since the content always be accompanied with the COOKIE notification, since the content
of the COOKIE notification is used as an input data when solving of the COOKIE notification is used as an input data when solving the
puzzle. The format of the PUZZLE notification is described in puzzle. The format of the PUZZLE notification is described in
Section 8.1. Section 8.1.
<-- HDR, N(COOKIE), N(PUZZLE), [V+][N+] <-- 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 The presence of these notifications in an IKE_SA_INIT response
message indicates to the Initiator that it should solve the puzzle to message indicates to the Initiator that it should solve the puzzle to
have a better chance to be served. have a better chance to be served.
7.1.1.1. Selecting the Puzzle Difficulty Level 7.1.1.1. Selecting the Puzzle Difficulty Level
The PUZZLE notification contains the difficulty level of the puzzle - The PUZZLE notification contains the difficulty level of the puzzle
the minimum number of trailing zero bits that the result of PRF must -- the minimum number of trailing zero bits that the result of PRF
contain. In diverse environments it is nearly impossible for the must contain. In diverse environments, it is nearly impossible for
Responder to set any specific difficulty level that will result in the Responder to set any specific difficulty level that will result
roughly the same amount of work for all Initiators, because in roughly the same amount of work for all Initiators, because
computation power of different Initiators may vary by an order of computation power of different Initiators may vary by an order of
magnitude, or even more. The Responder may set the difficulty level magnitude, or even more. The Responder may set the difficulty level
to 0, meaning that the Initiator is requested to spend as much power to 0, meaning that the Initiator is requested to spend as much power
to solve a puzzle as it can afford. In this case no specific value to solve a puzzle as it can afford. In this case, no specific value
of ZBC is required from the Initiator, however the larger the ZBC of ZBC is required from the Initiator; however, the larger the ZBC
that Initiator is able to get, the better the chance is that it will that the Initiator is able to get, the better the chance is that it
be served by the Responder. In diverse environments it is will be served by the Responder. In diverse environments, it is
RECOMMENDED that the Initiator set the difficulty level to 0, unless RECOMMENDED that the Initiator set the difficulty level to 0, unless
the attack volume is very high. the attack volume is very high.
If the Responder sets a non-zero difficulty level, then the level If the Responder sets a non-zero difficulty level, then the level
SHOULD be determined by analyzing the volume of the attack. The SHOULD be determined by analyzing the volume of the attack. The
Responder MAY set different difficulty levels to different requests Responder MAY set different difficulty levels to different requests
depending on the IP address the request has come from. depending on the IP address the request has come from.
7.1.1.2. Selecting the Puzzle Algorithm 7.1.1.2. Selecting the Puzzle Algorithm
The PUZZLE notification also contains an identifier of the algorithm, The PUZZLE notification also contains an identifier of the algorithm
that is used by Initiator to compute puzzle. that is used by the Initiator to compute the puzzle.
Cryptographic algorithm agility is considered an important feature Cryptographic algorithm agility is considered an important feature
for modern protocols [RFC7696]. Algorithm agility ensures that a for modern protocols [RFC7696]. Algorithm agility ensures that a
protocol doesn't rely on a single built-in set of cryptographic protocol doesn't rely on a single built-in set of cryptographic
algorithms, but has a means to replace one set with another and algorithms but has a means to replace one set with another and
negotiate new algorithms with the peer. IKEv2 fully supports negotiate new algorithms with the peer. IKEv2 fully supports
cryptographic algorithm agility for its core operations. cryptographic algorithm agility for its core operations.
To support crypto agility in case of puzzles, the algorithm that is To support crypto-agility in case of puzzles, the algorithm that is
used to compute a puzzle needs to be negotiated during the used to compute a puzzle needs to be negotiated during the
IKE_SA_INIT exchange. The negotiation is performed as follows. The IKE_SA_INIT exchange. The negotiation is performed as follows. The
initial request message from the Initiator contains an SA payload initial request message from the Initiator contains an SA payload
containing a list of transforms of different types. Thereby the containing a list of transforms of different types. In that manner,
Initiator asserts that it supports all transforms from this list and the Initiator asserts that it supports all transforms from this list
can use any of them in the IKE SA being established. The Responder and can use any of them in the IKE SA being established. The
parses the received SA payload and finds a mutually supported of type Responder parses the received SA payload and finds mutually supported
PRF. The Responder selects the preferred PRF from the list of transforms of type PRF. The Responder selects the preferred PRF from
mutually supported ones and includes it into the PUZZLE notification. the list of mutually supported ones and includes it into the PUZZLE
There is no requirement that the PRF selected for puzzles be the same notification. There is no requirement that the PRF selected for
as the PRF that is negotiated later for use in core IKE SA crypto puzzles be the same as the PRF that is negotiated later for use in
operations. If there are no mutually supported PRFs, then IKE SA core IKE SA crypto operations. If there are no mutually supported
negotiation will fail anyway and there is no reason to return a PRFs, then IKE SA negotiation will fail anyway and there is no reason
puzzle. In this case the Responder returns a NO_PROPOSAL_CHOSEN to return a puzzle. In this case, the Responder returns a
notification. Note that PRF is a mandatory transform type for IKE SA NO_PROPOSAL_CHOSEN notification. Note that PRF is a mandatory
(see Sections 3.3.2 and 3.3.3 of [RFC7296]) and at least one transform type for IKE SA (see Sections 3.3.2 and 3.3.3 of
transform of this type is always present in the SA payload in an [RFC7296]), and at least one transform of this type is always present
IKE_SA_INIT request message. in the SA payload in an IKE_SA_INIT request message.
7.1.1.3. Generating a Cookie 7.1.1.3. Generating a Cookie
If the Responder supports puzzles then a cookie should be computed in If the Responder supports puzzles, then a cookie should be computed
such a manner that the Responder is able to learn some important in such a manner that the Responder is able to learn some important
information from the sole cookie, when it is later returned back by information from the sole cookie, when it is later returned back by
Initiator. In particular - the Responder SHOULD be able to learn the the Initiator. In particular, the Responder SHOULD be able to learn
following information: the following information:
o Whether the puzzle was given to the Initiator or only the cookie o Whether the puzzle was given to the Initiator or only the cookie
was requested. was requested.
o The difficulty level of the puzzle given to the Initiator. o The difficulty level of the puzzle given to the Initiator.
o The number of consecutive puzzles given to the Initiator. o The number of consecutive puzzles given to the Initiator.
o The amount of time the Initiator spent to solve the puzzles. This o The amount of time the Initiator spent to solve the puzzles. This
can be calculated if the cookie is timestamped. can be calculated if the cookie is timestamped.
This information helps the Responder to make a decision whether to This information helps the Responder to make a decision whether to
serve this request or demand more work from the Initiator. serve this request or demand more work from the Initiator.
One possible approach to get this information is to encode it in the One possible approach to get this information is to encode it in the
cookie. The format of such encoding is an implementation detail of cookie. The format of such encoding is an implementation detail of
Responder, as the cookie would remain an opaque block of data to the the Responder, as the cookie would remain an opaque block of data to
Initiator. If this information is encoded in the cookie, then the the Initiator. If this information is encoded in the cookie, then
Responder MUST make it integrity protected, so that any intended or the Responder MUST make it integrity protected, so that any intended
accidental alteration of this information in the returned cookie is or accidental alteration of this information in the returned cookie
detectable. So, the cookie would be generated as: is detectable. So, the cookie would be generated as:
Cookie = <VersionIDofSecret> | <AdditionalInfo> | Cookie = <VersionIDofSecret> | <AdditionalInfo> |
Hash(Ni | IPi | SPIi | <AdditionalInfo> | <secret>) Hash(Ni | IPi | SPIi | <AdditionalInfo> | <secret>)
Note, that according to the Section 2.6 of [RFC7296], the size of the Note that according to Section 2.6 of [RFC7296], the size of the
cookie cannot exceed 64 bytes. cookie cannot exceed 64 bytes.
Alternatively, the Responder may generate a cookie as suggested in Alternatively, the Responder may generate a cookie as suggested in
Section 2.6 of [RFC7296], but associate the additional information, Section 2.6 of [RFC7296], but associate the additional information,
using local storage identified with the particular version of the using local storage identified with the particular version of the
secret. In this case the Responder should have different secrets for secret. In this case, the Responder should have different secrets
every combination of difficulty level and number of consecutive for every combination of difficulty level and number of consecutive
puzzles, and should change the secrets periodically, keeping a few puzzles, and should change the secrets periodically, keeping a few
previous versions, to be able to calculate how long ago a cookie was previous versions, to be able to calculate how long ago a cookie was
generated. generated.
The Responder may also combine these approaches. This document The Responder may also combine these approaches. This document
doesn't mandate how the Responder learns this information from a doesn't mandate how the Responder learns this information from a
cookie. cookie.
When selecting cookie generation algorithm implementations MUST When selecting cookie generation, algorithm implementations MUST
ensure that an attacker gains no or insignificant benefit from re- ensure that an attacker gains no or insignificant benefit from
using puzzle solutions in several requests. See Section 10 for reusing puzzle solutions in several requests. See Section 10 for
details. details.
7.1.2. Solving a Puzzle and Returning the Solution 7.1.2. Solving a Puzzle and Returning the Solution
If the Initiator receives a puzzle but it doesn't support puzzles, If the Initiator receives a puzzle but it doesn't support puzzles,
then it will ignore the PUZZLE notification as an unrecognized status then it will ignore the PUZZLE notification as an unrecognized status
notification (in accordance to Section 3.10.1 of [RFC7296]). The notification (in accordance with Section 3.10.1 of [RFC7296]). The
Initiator MAY ignore the PUZZLE notification if it is not willing to Initiator MAY ignore the PUZZLE notification if it is not willing to
spend resources to solve the puzzle of the requested difficulty, even spend resources to solve the puzzle of the requested difficulty, even
if it supports puzzles. In both cases the Initiator acts as if it supports puzzles. In both cases, the Initiator acts as
described in Section 2.6 of [RFC7296] - it restarts the request and described in Section 2.6 of [RFC7296] -- it restarts the request and
includes the received COOKIE notification into it. The Responder includes the received COOKIE notification in it. The Responder
should be able to distinguish the situation when it just requested a should be able to distinguish the situation when it just requested a
cookie from the situation where the puzzle was given to the cookie from the situation where the puzzle was given to the
Initiator, but the Initiator for some reason ignored it. Initiator, but the Initiator for some reason ignored it.
If the received message contains a PUZZLE notification and doesn't If the received message contains a PUZZLE notification and doesn't
contain a COOKIE notification, then this message is malformed because contain a COOKIE notification, then this message is malformed because
it requests to solve the puzzle, but doesn't provide enough it requests to solve the puzzle but doesn't provide enough
information to allow the puzzle to be solved. In this case the information to allow the puzzle to be solved. In this case, the
Initiator MUST ignore the received message and continue to wait until Initiator MUST ignore the received message and continue to wait until
either a valid PUZZLE notification is received or the retransmission either a valid PUZZLE notification is received or the retransmission
timer fires. If it fails to receive a valid message after several timer fires. If it fails to receive a valid message after several
retransmissions of IKE_SA_INIT requests, then it means that something retransmissions of IKE_SA_INIT requests, then this means that
is wrong and the IKE SA cannot be established. something is wrong and the IKE SA cannot be established.
If the Initiator supports puzzles and is ready to solve them, then it If the Initiator supports puzzles and is ready to solve them, then it
tries to solve the given puzzle. After the puzzle is solved the tries to solve the given puzzle. After the puzzle is solved, the
Initiator restarts the request and returns back to the Responder the Initiator restarts the request and returns back to the Responder the
puzzle solution in a new payload called a Puzzle Solution payload puzzle solution in a new payload called a Puzzle Solution (PS)
(denoted as PS, see Section 8.2) along with the received COOKIE payload (see Section 8.2) along with the received COOKIE
notification. notification.
HDR, N(COOKIE), [PS,] SA, KE, Ni, [V+][N+] --> HDR, N(COOKIE), [PS,] SA, KE, Ni, [V+][N+] -->
Figure 3: IKE_SA_INIT Request Containing Puzzle Solution
7.1.3. Computing a Puzzle 7.1.3. Computing a Puzzle
General principles of constructing puzzles in IKEv2 are described in General principles of constructing puzzles in IKEv2 are described in
Section 4.4. They can be summarized as follows: given unpredictable Section 4.4. They can be summarized as follows: given unpredictable
string S and pseudo-random function PRF find N different keys Ki string S and PRF, find N different keys Ki (where i=[1..N]) for that
(where i=[1..N]) for that PRF so that the result of PRF(Ki,S) has at PRF so that the result of PRF(Ki,S) has at least the specified number
least the specified number of trailing zero bits. This specification of trailing zero bits. This specification requires that the puzzle
requires that the puzzle solution contains 4 different keys (i.e., solution contains 4 different keys (i.e., N=4).
N=4).
In the IKE_SA_INIT exchange it is the cookie that plays the role of In the IKE_SA_INIT exchange, it is the cookie that plays the role of
unpredictable string S. In other words, in the IKE_SA_INIT the task unpredictable string S. In other words, in the IKE_SA_INIT, the task
for the IKE Initiator is to find the four different, equal-sized keys for the IKE Initiator is to find the four different, equal-sized keys
Ki for the agreed upon PRF such that each result of PRF(Ki,cookie) Ki for the agreed upon PRF such that each result of PRF(Ki,cookie)
where i = [1..4] has a sufficient number of trailing zero bits. Only where i = [1..4] has a sufficient number of trailing zero bits. Only
the content of the COOKIE notification is used in puzzle calculation, the content of the COOKIE notification is used in puzzle calculation,
i.e., the header of the Notify payload is not included. i.e., the header of the Notify payload is not included.
Note, that puzzles in the IKE_AUTH exchange are computed differently 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. than in the IKE_SA_INIT_EXCHANGE. See Section 7.2.3 for details.
7.1.4. Analyzing Repeated Request 7.1.4. Analyzing Repeated Request
The received request must at least contain a COOKIE notification. The received request must at least contain a COOKIE notification.
Otherwise it is an initial request and in this case it MUST be Otherwise, it is an initial request and in this case, it MUST be
processed according to Section 7.1. First, the cookie MUST be processed according to Section 7.1. First, the cookie MUST be
checked for validity. If the cookie is invalid, then the request is checked for validity. If the cookie is invalid, then the request is
treated as initial and is processed according to Section 7.1. It is treated as initial and is processed according to Section 7.1. It is
RECOMMENDED that a new cookie is requested in this case. RECOMMENDED that a new cookie is requested in this case.
If the cookie is valid, then some important information is learned If the cookie is valid, then some important information is learned
from it, or from local state based on identifier of the cookie's from it or from local state based on the identifier of the cookie's
secret (see Section 7.1.1.3 for details). This information helps the secret (see Section 7.1.1.3 for details). This information helps the
Responder to sort out incoming requests, giving more priority to Responder to sort out incoming requests, giving more priority to
those which were created by spending more of the Initiator's those that were created by spending more of the Initiator's
resources. resources.
First, the Responder determines if it requested only a cookie, or First, the Responder determines if it requested only a cookie or
presented a puzzle to the Initiator. If no puzzle was given, this presented a puzzle to the Initiator. If no puzzle was given, this
means that at the time the Responder requested a cookie it didn't means that at the time the Responder requested a cookie, it didn't
detect the (D)DoS attack or the attack volume was low. In this case detect the DoS or DDoS attack, or the attack volume was low. In this
the received request message must not contain the PS payload, and case, the received request message must not contain the PS payload,
this payload MUST be ignored if the message contains a PS payload for and this payload MUST be ignored if the message contains a PS payload
any reason. Since no puzzle was given, the Responder marks the for any reason. Since no puzzle was given, the Responder marks the
request with the lowest priority since the Initiator spent little request with the lowest priority since the Initiator spent little
resources creating it. resources creating it.
If the Responder learns from the cookie that the puzzle was given to If the Responder learns from the cookie that the puzzle was given to
the Initiator, then it looks for the PS payload to determine whether the Initiator, then it looks for the PS payload to determine whether
its request to solve the puzzle was honored or not. If the incoming its request to solve the puzzle was honored or not. If the incoming
message doesn't contain a PS payload, this means that the Initiator message doesn't contain a PS payload, this means that the Initiator
either doesn't support puzzles or doesn't want to deal with them. In either doesn't support puzzles or doesn't want to deal with them. In
either case the request is marked with the lowest priority since the either case, the request is marked with the lowest priority since the
Initiator spent little resources creating it. Initiator spent little resources creating it.
If a PS payload is found in the message, then the Responder MUST If a PS payload is found in the message, then the Responder MUST
verify the puzzle solution that it contains. The solution is verify the puzzle solution that it contains. The solution is
interpreted as four different keys. The result of using each of them 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 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 requested number of trailing zero bits. The Responder MUST check all
of the four returned keys. of the four returned keys.
If any checked result contains fewer bits than were requested, this If any checked result contains fewer bits than were requested, this
means that the Initiator spent less resources than expected by the means that the Initiator spent less resources than expected by the
Responder. This request is marked with the lowest priority. Responder. This request is marked with the lowest priority.
If the Initiator provided the solution to the puzzle satisfying the If the Initiator provided the solution to the puzzle satisfying the
requested difficulty level, or if the Responder didn't indicate any requested difficulty level, or if the Responder didn't indicate any
particular difficulty level (by setting ZBC to zero) and the particular difficulty level (by setting the ZBC to 0) and the
Initiator was free to select any difficulty level it can afford, then Initiator was free to select any difficulty level it can afford, then
the priority of the request is calculated based on the following the priority of the request is calculated based on the following
considerations: considerations:
o The Responder MUST take the smallest number of trailing zero bits o The Responder MUST take the smallest number of trailing zero bits
among the checked results and count it as the number of zero bits among the checked results and count it as the number of zero bits
the Initiator solved for. the Initiator solved for.
o The higher number of zero bits the Initiator provides, the higher o The higher number of zero bits the Initiator provides, the higher
priority its request should receive. priority its request should receive.
o The more consecutive puzzles the Initiator solved, the higher o The more consecutive puzzles the Initiator solved, the higher
priority it should receive. priority it should receive.
o The more time the Initiator spent solving the puzzles, the higher o The more time the Initiator spent solving the puzzles, the higher
priority it should receive. priority it should receive.
After the priority of the request is determined the final decision After the priority of the request is determined, the final decision
whether to serve it or not is made. whether to serve it or not is made.
7.1.5. Deciding if to Serve the Request 7.1.5. Deciding Whether to Serve the Request
The Responder decides what to do with the request based on the The Responder decides what to do with the request based on the
request's priority and the Responder's current load. There are three request's priority and the Responder's current load. There are three
possible actions: possible actions:
o Accept request. o Accept request.
o Reject request. o Reject request.
o Demand more work from the Initiator by giving it a new puzzle. o Demand more work from the Initiator by giving it a new puzzle.
The Responder SHOULD accept an incoming request if its priority is The Responder SHOULD accept an incoming request if its priority is
high - this means that the Initiator spent quite a lot of resources. high -- this means that the Initiator spent quite a lot of resources.
The Responder MAY also accept some low-priority requests where the The Responder MAY also accept some low-priority requests where the
Initiators don't support puzzles. The percentage of accepted legacy Initiators don't support puzzles. The percentage of accepted legacy
requests depends on the Responder's current load. requests depends on the Responder's current load.
If the Initiator solved the puzzle, but didn't spend much resources If the Initiator solved the puzzle, but didn't spend much resources
for it (the selected puzzle difficulty level appeared to be low and for it (the selected puzzle difficulty level appeared to be low and
the Initiator solved it quickly), then the Responder SHOULD give it the Initiator solved it quickly), then the Responder SHOULD give it
another puzzle. The more puzzles the Initiator solves the higher its another puzzle. The more puzzles the Initiator solves the higher its
chances are to be served. chances are to be served.
The details of how the Responder makes a decision for any particular The details of how the Responder makes a decision for any particular
request are implementation dependent. The Responder can collect all request are implementation dependent. The Responder can collect all
of the incoming requests for some short period of time, sort them out of the incoming requests for some short period of time, sort them out
based on their priority, calculate the number of available memory based on their priority, calculate the number of available memory
slots for half-open IKE SAs and then serve that number of requests slots for half-open IKE SAs, and then serve that number of requests
from the head of the sorted list. The remainder of requests can be from the head of the sorted list. The remainder of requests can be
either discarded or responded to with new puzzle requests. either discarded or responded to with new puzzle requests.
Alternatively, the Responder may decide whether to accept every Alternatively, the Responder may decide whether to accept every
incoming request with some kind of lottery, taking into account its incoming request with some kind of lottery, taking into account its
priority and the available resources. priority and the available resources.
7.2. Puzzles in an IKE_AUTH Exchange 7.2. Puzzles in an IKE_AUTH Exchange
Once the IKE_SA_INIT exchange is completed, the Responder has created Once the IKE_SA_INIT exchange is completed, the Responder has created
a state and is waiting for the first message of the IKE_AUTH exchange a state and is waiting for the first message of the IKE_AUTH exchange
from the Initiator. At this point the Initiator has already passed from the Initiator. At this point, the Initiator has already passed
the return routability check and has proved that it has performed the return routability check and has proved that it has performed
some work to complete IKE_SA_INIT exchange. However, the Initiator some work to complete the IKE_SA_INIT exchange. However, the
is not yet authenticated and this allows a malicious Initiator to Initiator is not yet authenticated, and this allows a malicious
perform an attack, described in Section 3. Unlike a DoS attack in Initiator to perform an attack, as described in Section 3. Unlike a
the IKE_SA_INIT exchange, which is targeted on the Responder's memory DoS attack in the IKE_SA_INIT exchange, which is targeted on the
resources, the goal of this attack is to exhaust a Responder's CPU Responder's memory resources, the goal of this attack is to exhaust a
power. The attack is performed by sending the first IKE_AUTH message Responder's CPU power. The attack is performed by sending the first
containing arbitrary data. This costs nothing to the Initiator, but IKE_AUTH message containing arbitrary data. This costs nothing to
the Responder has to perform relatively costly operations when the Initiator, but the Responder has to perform relatively costly
computing the D-H shared secret and deriving SK_* keys to be able to operations when computing the DH shared secret and deriving SK_* keys
verify authenticity of the message. If the Responder doesn't keep to be able to verify authenticity of the message. If the Responder
the computed keys after an unsuccessful verification of the IKE_AUTH doesn't keep the computed keys after an unsuccessful verification of
message, then the attack can be repeated several times on the same the IKE_AUTH message, then the attack can be repeated several times
IKE SA. on the same IKE SA.
The Responder can use puzzles to make this attack more costly for the 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 Initiator. The idea is that the Responder includes a puzzle in the
IKE_SA_INIT response message and the Initiator includes a puzzle IKE_SA_INIT response message and the Initiator includes a puzzle
solution in the first IKE_AUTH request message outside the Encrypted solution in the first IKE_AUTH request message outside the Encrypted
payload, so that the Responder is able to verify puzzle solution payload, so that the Responder is able to verify a puzzle solution
before computing the D-H shared secret. before computing the DH shared secret.
The Responder constantly monitors the amount of the half-open IKE SA The Responder constantly monitors the amount of the half-open IKE SA
states that receive IKE_AUTH messages that cannot be decrypted due to states that receive IKE_AUTH messages that cannot be decrypted due to
integrity check failures. If the percentage of such states is high integrity check failures. If the percentage of such states is high
and it takes an essential fraction of Responder's computing power to and it takes an essential fraction of the Responder's computing power
calculate keys for them, then the Responder may assume that it is to calculate keys for them, then the Responder may assume that it is
under attack and SHOULD use puzzles to make it harder for attackers. under attack and SHOULD use puzzles to make it harder for attackers.
7.2.1. Presenting Puzzle 7.2.1. Presenting the Puzzle
The Responder requests the Initiator to solve a puzzle by including The Responder requests the Initiator to solve a puzzle by including
the PUZZLE notification in the IKE_SA_INIT response message. The the PUZZLE notification in the IKE_SA_INIT response message. The
Responder MUST NOT use puzzles in the IKE_AUTH exchange unless a Responder MUST NOT use puzzles in the IKE_AUTH exchange unless a
puzzle has been previously presented and solved in the preceding puzzle has been previously presented and solved in the preceding
IKE_SA_INIT exchange. IKE_SA_INIT exchange.
<-- HDR, SA, KE, Nr, N(PUZZLE), [V+][N+] <-- 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 7.2.1.1. Selecting Puzzle Difficulty Level
The difficulty level of the puzzle in the IKE_AUTH exchange should be The difficulty level of the puzzle in the IKE_AUTH exchange should be
chosen so that the Initiator would spend more time to solve the chosen so that the Initiator would spend more time to solve the
puzzle than the Responder to compute the D-H shared secret and the puzzle than the Responder to compute the DH shared secret and the
keys needed to decrypt and verify the IKE_AUTH request message. On keys needed to decrypt and verify the IKE_AUTH request message. On
the other hand, the difficulty level should not be too high, the other hand, the difficulty level should not be too high,
otherwise legitimate clients will experience an additional delay otherwise legitimate clients will experience an additional delay
while establishing the IKE SA. while establishing the IKE SA.
Note, that since puzzles in the IKE_AUTH exchange are only allowed to Note that since puzzles in the IKE_AUTH exchange are only allowed to
be used if they were used in the preceding IKE_SA_INIT exchange, the be used if they were used in the preceding IKE_SA_INIT exchange, the
Responder would be able to roughly estimate the computational power Responder would be able to roughly estimate the computational power
of the Initiator and select the difficulty level accordingly. Unlike of the Initiator and select the difficulty level accordingly. Unlike
puzzles in the IKE_SA_INIT, the requested difficulty level for puzzles in the IKE_SA_INIT, the requested difficulty level for
IKE_AUTH puzzles MUST NOT be zero. In other words, the Responder IKE_AUTH puzzles MUST NOT be 0. In other words, the Responder must
must always set a specific difficulty level and must not let the always set a specific difficulty level and must not let the Initiator
Initiator to choose it on its own. choose it on its own.
7.2.1.2. Selecting the Puzzle Algorithm 7.2.1.2. Selecting the Puzzle Algorithm
The algorithm for the puzzle is selected as described in The algorithm for the puzzle is selected as described in
Section 7.1.1.2. There is no requirement that the algorithm for the Section 7.1.1.2. There is no requirement that the algorithm for the
puzzle in the IKE_SA INIT exchange be the same as the algorithm for puzzle in the IKE_SA INIT exchange be the same as the algorithm for
the puzzle in IKE_AUTH exchange; however, it is expected that in most the puzzle in the IKE_AUTH exchange; however, it is expected that in
cases they will be the same. most cases they will be the same.
7.2.2. Solving Puzzle and Returning the Solution 7.2.2. Solving the Puzzle and Returning the Solution
If the IKE_SA_INIT regular response message (i.e. the message If the IKE_SA_INIT regular response message (i.e., the message
containing SA, KE, NONCE payloads) contains the PUZZLE notification containing SA, KE, NONCE payloads) contains the PUZZLE notification
and the Initiator supports puzzles, it MUST solve the puzzle. Note, and the Initiator supports puzzles, it MUST solve the puzzle. Note
that puzzle construction in the IKE_AUTH exchange differs from the that puzzle construction in the IKE_AUTH exchange differs from the
puzzle construction in the IKE_SA_INIT exchange and is described in puzzle construction in the IKE_SA_INIT exchange and is described in
Section 7.2.3. Once the puzzle is solved the Initiator sends the Section 7.2.3. Once the puzzle is solved, the Initiator sends the
IKE_AUTH request message containing the Puzzle Solution payload. IKE_AUTH request message containing the PS payload.
HDR, PS, SK {IDi, [CERT,] [CERTREQ,] HDR, PS, SK {IDi, [CERT,] [CERTREQ,]
[IDr,] AUTH, SA, TSi, TSr} --> [IDr,] AUTH, SA, TSi, TSr} -->
The Puzzle Solution (PS) payload MUST be placed outside the Encrypted Figure 5: IKE_AUTH Request Containing IKE_AUTH Puzzle Solution
payload, so that the Responder is able to verify the puzzle before
calculating the D-H shared secret and the SK_* keys.
If IKE Fragmentation [RFC7383] is used in IKE_AUTH exchange, then the The PS payload MUST be placed outside the Encrypted payload, so that
PS payload MUST be present only in the first IKE Fragment message, in the Responder is able to verify the puzzle before calculating the DH
accordance with the Section 2.5.3 of [RFC7383]. Note, that shared secret and the SK_* keys.
If IKE fragmentation [RFC7383] is used in the IKE_AUTH exchange, then
the PS payload MUST be present only in the first IKE Fragment
message, in accordance with Section 2.5.3 of [RFC7383]. Note that
calculation of the puzzle in the IKE_AUTH exchange doesn't depend on calculation of the puzzle in the IKE_AUTH exchange doesn't depend on
the content of the IKE_AUTH message (see Section 7.2.3). Thus the the content of the IKE_AUTH message (see Section 7.2.3). Thus, the
Initiator has to solve the puzzle only once and the solution is valid Initiator has to solve the puzzle only once, and the solution is
for both unfragmented and fragmented IKE messages. valid for both unfragmented and fragmented IKE messages.
7.2.3. Computing the Puzzle 7.2.3. Computing the Puzzle
A puzzle in the IKE_AUTH exchange is computed differently than in the 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 IKE_SA_INIT exchange (see Section 7.1.3). The general principle is
the same; the difference is in the construction of the string S. the same; the difference is in the construction of the string S.
Unlike the IKE_SA_INIT exchange, where S is the cookie, in the 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 IKE_AUTH exchange, S is a concatenation of Nr and SPIr. In other
words, the task for IKE Initiator is to find the four different keys words, the task for the IKE Initiator is to find the four different
Ki for the agreed upon PRF such that each result of PRF(Ki,Nr | SPIr) keys Ki for the agreed upon PRF such that each result of PRF(Ki,Nr |
where i=[1..4] has a sufficient number of trailing zero bits. Nr is SPIr) where i=[1..4] has a sufficient number of trailing zero bits.
a nonce used by the Responder in the IKE_SA_INIT exchange, stripped Nr is a nonce used by the Responder in the IKE_SA_INIT exchange,
of any headers. SPIr is the IKE Responder's SPI from the IKE header stripped of any headers. SPIr is the IKE Responder's SPI from the
of the SA being established. IKE header of the SA being established.
7.2.4. Receiving the Puzzle Solution 7.2.4. Receiving the Puzzle Solution
If the Responder requested the Initiator to solve a puzzle in the If the Responder requested the Initiator to solve a puzzle in the
IKE_AUTH exchange, then it MUST silently discard all the IKE_AUTH IKE_AUTH exchange, then it MUST silently discard all the IKE_AUTH
request messages without the Puzzle Solution payload. request messages without the PS payload.
Once the message containing a solution to the puzzle is received, the Once the message containing a solution to the puzzle is received, the
Responder MUST verify the solution before performing computationlly Responder MUST verify the solution before performing computationally
intensive operations i.e., computing the D-H shared secret and the intensive operations, i.e., computing the DH shared secret and the
SK_* keys. The Responder MUST verify all four of the returned keys. SK_* keys. The Responder MUST verify all four of the returned keys.
The Responder MUST silently discard the received message if any The Responder MUST silently discard the received message if any
checked verification result is not correct (contains insufficient checked verification result is not correct (contains insufficient
number of trailing zero bits). If the Responder successfully number of trailing zero bits). If the Responder successfully
verifies the puzzle and calculates the SK_* key, but the message verifies the puzzle and calculates the SK_* key, but the message
authenticity check fails, then it SHOULD save the calculated keys in authenticity check fails, then it SHOULD save the calculated keys in
the IKE SA state while waiting for the retransmissions from the the IKE SA state while waiting for the retransmissions from the
Initiator. In this case the Responder may skip verification of the Initiator. In this case, the Responder may skip verification of the
puzzle solution and ignore the Puzzle Solution payload in the puzzle solution and ignore the PS payload in the retransmitted
retransmitted messages. messages.
If the Initiator uses IKE Fragmentation, then it sends all fragments If the Initiator uses IKE fragmentation, then it sends all fragments
of a message simultaneously. Due to packets loss and/or reordering of a message simultaneously. Due to packets loss and/or reordering,
it is possible that the Responder receives subsequent fragments it is possible that the Responder receives subsequent fragments
before receiving the first one, that contains the PS payload. In before receiving the first one that contains the PS payload. In this
this case the Responder MAY choose to keep the received fragments case, the Responder MAY choose to keep the received fragments until
until the first fragment containing the solution to the puzzle is the first fragment containing the solution to the puzzle is received.
received. In this case the Responder SHOULD NOT try to verify In this case, the Responder SHOULD NOT try to verify authenticity of
authenticity of the kept fragments until the first fragment with the the kept fragments until the first fragment with the PS payload is
PS payload is received and the solution to the puzzle is verified. received, and the solution to the puzzle is verified. After
After successful verification of the puzzle, the Responder can then successful verification of the puzzle, the Responder can then
calculate the SK_* key and verify authenticity of the collected calculate the SK_* key and verify authenticity of the collected
fragments. fragments.
8. Payload Formats 8. Payload Formats
8.1. PUZZLE Notification 8.1. PUZZLE Notification
The PUZZLE notification is used by the IKE Responder to inform the The PUZZLE notification is used by the IKE Responder to inform the
Initiator about the need to solve the puzzle. It contains the Initiator about the need to solve the puzzle. It contains the
difficulty level of the puzzle and the PRF the Initiator should use. difficulty level of the puzzle and the PRF the Initiator should use.
skipping to change at page 25, line 32 skipping to change at page 26, line 41
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length | | Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Protocol ID(=0)| SPI Size (=0) | Notify Message Type | |Protocol ID(=0)| SPI Size (=0) | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PRF | Difficulty | | PRF | Difficulty |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Protocol ID (1 octet) -- MUST be 0. o Protocol ID (1 octet) -- MUST be 0.
o SPI Size (1 octet) - MUST be 0, meaning no Security Parameter o SPI Size (1 octet) -- MUST be 0, meaning no SPI is present.
Index (SPI) is present.
o Notify Message Type (2 octets) -- MUST be <TBA by IANA>, the value o Notify Message Type (2 octets) -- MUST be 16434, the value
assigned for the PUZZLE notification. assigned for the PUZZLE notification.
o PRF (2 octets) -- Transform ID of the PRF algorithm that MUST be o PRF (2 octets) -- Transform ID of the PRF algorithm that MUST be
used to solve the puzzle. Readers should refer to the section used to solve the puzzle. Readers should refer to the "Transform
"Transform Type 2 - Pseudo-Random Function Transform IDs" in Type 2 - Pseudorandom Function Transform IDs" subregistry on
[IKEV2-IANA] for the list of possible values. [IKEV2-IANA] for the list of possible values.
o Difficulty (1 octet) -- Difficulty Level of the puzzle. Specifies o Difficulty (1 octet) -- Difficulty level of the puzzle. Specifies
the minimum number of trailing zero bits (ZBC), that each of the the minimum number of trailing zero bits (ZBC) that each of the
results of PRF must contain. Value 0 means that the Responder results of PRF must contain. Value 0 means that the Responder
doesn't request any specific difficulty level and the Initiator is doesn't request any specific difficulty level, and the Initiator
free to select an appropriate difficulty level on its own (see is free to select an appropriate difficulty level on its own (see
Section 7.1.1.1 for details). Section 7.1.1.1 for details).
This notification contains no data. This notification contains no data.
8.2. Puzzle Solution Payload 8.2. Puzzle Solution Payload
The solution to the puzzle is returned back to the Responder in a The solution to the puzzle is returned back to the Responder in a
dedicated payload, called the Puzzle Solution payload and denoted as dedicated payload, called the PS payload.
PS in this document.
1 2 3 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 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 | | Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Puzzle Solution Data ~ ~ Puzzle Solution Data ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Puzzle Solution Data (variable length) -- Contains the solution to o Puzzle Solution Data (variable length) -- Contains the solution to
the puzzle - four different keys for the selected PRF. This field the puzzle -- four different keys for the selected PRF. This
MUST NOT be empty. All of the keys MUST have the same size, field MUST NOT be empty. All of the keys MUST have the same size;
therefore the size of this field is always a mutiple of 4 bytes. therefore, 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 If the selected PRF accepts only fixed-size keys, then the size of
each key MUST be of that fixed size. If the agreed upon PRF each key MUST be of that fixed size. If the agreed upon PRF
accepts keys of any size, then then the size of each key MUST be accepts keys of any size, then the size of each key MUST be
between 1 octet and the preferred key length of the PRF between 1 octet and the preferred key length of the PRF
(inclusive). It is expected that in most cases the keys will be 4 (inclusive). It is expected that in most cases, the keys will be
(or even less) octets in length, however it depends on puzzle 4 (or even less) octets in length; however, it depends on puzzle
difficulty and on the Initiator's strategy to find solutions, and difficulty and on the Initiator's strategy to find solutions, and
thus the size is not mandated by this specification. The thus the size is not mandated by this specification. The
Responder determines the size of each key by dividing the size of Responder determines the size of each key by dividing the size of
the Puzzle Solution Data by 4 (the number of keys). Note that the the Puzzle Solution Data by 4 (the number of keys). Note that the
size of Puzzle Solution Data is the size of Payload (as indicated size of Puzzle Solution Data is the size of the Payload (as
in Payload Length field) minus 4 - the size of Payload Header. indicated in the Payload Length field) minus 4 -- the size of the
Payload header.
The payload type for the Puzzle Solution payload is <TBA by IANA>. The payload type for the PS payload is 54.
9. Operational Considerations 9. Operational Considerations
The puzzle difficulty level should be set by balancing the The puzzle difficulty level should be set by balancing the
requirement to minimize the latency for legitimate Initiators with requirement to minimize the latency for legitimate Initiators with
making things difficult for attackers. A good rule of thumb is for making things difficult for attackers. A good rule of thumb is
taking about 1 second to solve the puzzle. A typical Initiator or taking about 1 second to solve the puzzle. At the time this document
botnet member at the time this document is written can perform was written, a typical Initiator or botnet member can perform
slightly less than a million hashes per second per core, so setting slightly less than a million hashes per second per core, so setting
the number of zero bits to 20 is a good compromise. It should be the number of zero bits to 20 is a good compromise. It should be
noted that mobile Initiators, especially phones are considerably noted that mobile Initiators, especially phones, are considerably
weaker than that. Implementations should allow administrators to set weaker than that. Implementations should allow administrators to set
the difficulty level, and/or be able to set the difficulty level the difficulty level and/or be able to set the difficulty level
dynamically in response to load. dynamically in response to load.
Initiators SHOULD set a maximum difficulty level beyond which they Initiators SHOULD set a maximum difficulty level beyond which they
won't try to solve the puzzle and log or display a failure message to won't try to solve the puzzle and log or display a failure message to
the administrator or user. the administrator or user.
Until the widespread adoption of puzzles happens, most Initiators Until the widespread adoption of puzzles happens, most Initiators
will ignore them, as will all attackers. For puzzles to become a will ignore them, as will all attackers. For puzzles to become a
really powerfull defense measure against DDoS attacks they must be really powerful defense measure against DDoS attacks, they must be
supported by the majority of legitimate clients. supported by the majority of legitimate clients.
10. Security Considerations 10. Security Considerations
Care must be taken when selecting parameters for the puzzles, in Care must be taken when selecting parameters for the puzzles, in
particular the puzzle difficulty. If the puzzles are too easy for particular the puzzle difficulty. If the puzzles are too easy for
the majority of attacker, then the puzzle mechanism wouldn't be able the majority of attackers, then the puzzle mechanism wouldn't be able
to prevent (D)DoS attacks and would only impose an additional burden to prevent DoS or DDoS attacks and would only impose an additional
on legitimate Initiators. On the other hand, if the puzzles are too burden on legitimate Initiators. On the other hand, if the puzzles
hard for the majority of Initiators, then many legitimate users would are too hard for the majority of Initiators, then many legitimate
experience unacceptable delays in IKE SA setup (and unacceptable users would experience unacceptable delays in IKE SA setup (and
power consumption on mobile devices), that might cause them to cancel unacceptable power consumption on mobile devices) that might cause
the connection attempt. In this case the resources of the Responder them to cancel the connection attempt. In this case, the resources
are preserved, however the DoS attack can be considered successful. of the Responder are preserved; however, the DoS attack can be
Thus a sensible balance should be kept by the Responder while considered successful. Thus, a sensible balance should be kept by
choosing the puzzle difficulty - to defend itself and to not over- the Responder while choosing the puzzle difficulty -- to defend
defend itself. It is RECOMMENDED that the puzzle difficulty be itself and to not over-defend itself. It is RECOMMENDED that the
chosen so, that the Responder's load remains close to the maximum it puzzle difficulty be chosen, so that the Responder's load remains
can tolerate. It is also RECOMMENDED to dynamically adjust the close to the maximum it can tolerate. It is also RECOMMENDED to
puzzle difficulty in accordance to the current Responder's load. dynamically adjust the puzzle difficulty in accordance to the current
Responder's load.
If the cookie is generated as suggested in Section 2.6 of [RFC7296], 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 then an attacker can use the same SPIi and the same Ni for several
requests from the same IPi. This will result in generating the same requests from the same IPi. This will result in generating the same
cookies for these requests until the Responder changes the value of cookies for these requests until the Responder changes the value of
its cookie generation secret. Since the cookies are used as an input its cookie generation secret. Since the cookies are used as an input
data for puzzles in the IKE_SA_INIT exchange, generating same cookies data for puzzles in the IKE_SA_INIT exchange, generating the same
allows the attacker to re-use puzzle solution, thus bypassing proof cookies allows the attacker to reuse puzzle solutions, thus bypassing
of work requirement. Note, that the attacker can get only limited the proof-of-work requirement. Note that the attacker can get only
benefit from this situation - once the half-open SA is created by the limited benefit from this situation -- once the half-open SA is
Responder all the subsequent initial requests with the same IPi and created by the Responder, all the subsequent initial requests with
SPIi will be treated as retransmissions and discarded by the the same IPi and SPIi will be treated as retransmissions and
Responder. However, once this half-open SA is expired and deleted, discarded by the Responder. However, once this half-open SA is
the attacker can create a new one for free if the Responder haven't expired and deleted, the attacker can create a new one for free if
changed its cookie generation secret yet. the Responder hasn't changed its cookie generation secret yet.
The Responder can use various countermeasures to completely eliminate The Responder can use various countermeasures to completely eliminate
or mitigate this scenatio. First, the Responder can change its or mitigate this scenario. First, the Responder can change its
cookie generation secret frequently especially if under attack, as cookie generation secret frequently especially if under attack, as
recommended in the Section 2.6 of [RFC7296]. For example, if the recommended in Section 2.6 of [RFC7296]. For example, if the
Responder keeps two values of the secret (current and previous) and Responder keeps two values of the secret (current and previous) and
the secret lifetime is no more than a half of the current half-open the secret lifetime is no more than a half of the current half-open
SA retention time (see Section 4.1), then the attacker cannot get SA retention time (see Section 4.1), then the attacker cannot get
benefit from re-using puzzle solution. However, short cookie benefit from reusing a puzzle solution. However, short cookie
generation secret lifetime could have negative consequence on weak generation secret lifetime could have a negative consequence on weak
legitimate Initiators, since it could take too long for them to solve legitimate Initiators, since it could take too long for them to solve
puzzles and their solutons would be discarded if the cookie puzzles, and their solutions would be discarded if the cookie
generation secret has been already changed few times. generation secret has been already changed few times.
Another approach for the Responder is to modify cookie generation Another approach for the Responder is to modify the cookie generation
algorithm in such a way, that the generated cookies are always algorithm in such a way that the generated cookies are always
different or are repeated only within short time period. If the different or are repeated only within a short time period. If the
Responder includes timestamp in the <AdditionalInfo> as suggested in Responder includes a timestamp in <AdditionalInfo> as suggested in
Section 7.1.1.3, then the cookies will repeat only within short time Section 7.1.1.3, then the cookies will repeat only within a short
interval equal to timestamp resolution. Another approach for the time interval equal to timestamp resolution. Another approach for
Responder is to maintain a global counter that is incremented every the Responder is to maintain a global counter that is incremented
time a cookie is generated and include this counter in the every time a cookie is generated and include this counter in
<AdditionalInfo>. This will make every cookies unique. <AdditionalInfo>. This will make every cookie unique.
Implementations MUST use one of the above (or some other) Implementations MUST use one of the above (or some other)
countermeasures to completely eliminate or make insignificant the countermeasures to completely eliminate or make insignificant the
possible benefit an attacker can get from re-using puzzle solutions. possible benefit an attacker can get from reusing puzzle solutions.
Note, this issue doesn't exist in IKE_AUTH puzzles (Section 7.2) Note that this issue doesn't exist in IKE_AUTH puzzles (Section 7.2)
since the puzzles in IKE_AUTH are always unique if the Responder since the puzzles in IKE_AUTH are always unique if the Responder
generates SPIr and Nr randomly in accordance with [RFC7296]. generates SPIr and Nr randomly in accordance with [RFC7296].
Solving puzzles requires a lot of CPU power that increases power Solving puzzles requires a lot of CPU usage that increases power
consumption. This additional power consumption can negatively affect consumption. This additional power consumption can negatively affect
battery-powered Initiators, e.g. mobile phones or some IoT devices. battery-powered Initiators, e.g., mobile phones or some Internet of
If puzzles are too hard, then the required additional power Things (IoT) devices. If puzzles are too hard, then the required
consumption may appear to be unacceptable for some Initiators. The additional power consumption may appear to be unacceptable for some
Responder SHOULD take this possibility into consideration while Initiators. The Responder SHOULD take this possibility into
choosing the puzzle difficulty, and while selecting which percentage consideration while choosing the puzzle difficulty and while
of Initiators are allowed to reject solving puzzles. See selecting which percentage of Initiators are allowed to reject
Section 7.1.4 for details. solving puzzles. See Section 7.1.4 for details.
If the Initiator uses NULL Authentication [RFC7619] then its identity If the Initiator uses NULL Authentication [RFC7619], then its
is never verified. This condition may be used by attackers to identity is never verified. This condition may be used by attackers
perform a DoS attack after the IKE SA is established. Responders to perform a DoS attack after the IKE SA is established. Responders
that allow unauthenticated Initiators to connect must be prepared to that allow unauthenticated Initiators to connect must be prepared to
deal with various kinds of DoS attacks even after the IKE SA is deal with various kinds of DoS attacks even after the IKE SA is
created. See Section 5 for details. created. See Section 5 for details.
To prevent amplification attacks implementations must strictly follow To prevent amplification attacks, implementations must strictly
the retransmission rules described in Section 2.1 of [RFC7296]. follow the retransmission rules described in Section 2.1 of
[RFC7296].
11. IANA Considerations 11. IANA Considerations
This document defines a new payload in the "IKEv2 Payload Types" This document defines a new payload in the "IKEv2 Payload Types"
registry: registry:
<TBA> Puzzle Solution PS 54 Puzzle Solution PS
This document also defines a new Notify Message Type in the "IKEv2 This document also defines a new Notify Message Type in the "IKEv2
Notify Message Types - Status Types" registry: Notify Message Types - Status Types" registry:
<TBA> PUZZLE 16434 PUZZLE
12. Acknowledgements
The authors thank Tero Kivinen, Yaron Sheffer, and Scott Fluhrer for 12. References
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 puzles. The authors also
thank David Waltermire and Paul Wouters for their careful reviews of
the document, Graham Bartlett for pointing out to the possibility of
the "Hash & URL" related attack, Stephen Farrell for catching the
repeated cookie issue, and all others who commented the document.
13. References 12.1. Normative References
13.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 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange [RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange
Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, Protocol Version 2 (IKEv2) Session Resumption", RFC 5723,
DOI 10.17487/RFC5723, January 2010, DOI 10.17487/RFC5723, January 2010,
<http://www.rfc-editor.org/info/rfc5723>. <http://www.rfc-editor.org/info/rfc5723>.
skipping to change at page 30, line 5 skipping to change at page 31, line 15
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2 Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <http://www.rfc-editor.org/info/rfc7296>. 2014, <http://www.rfc-editor.org/info/rfc7296>.
[RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2 [RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2
(IKEv2) Message Fragmentation", RFC 7383, (IKEv2) Message Fragmentation", RFC 7383,
DOI 10.17487/RFC7383, November 2014, DOI 10.17487/RFC7383, November 2014,
<http://www.rfc-editor.org/info/rfc7383>. <http://www.rfc-editor.org/info/rfc7383>.
[IKEV2-IANA] 12.2. Informative References
"Internet Key Exchange Version 2 (IKEv2) Parameters",
<http://www.iana.org/assignments/ikev2-parameters>.
13.2. Informative References
[bitcoins] [BITCOINS] Nakamoto, S., "Bitcoin: A Peer-to-Peer Electronic Cash
Nakamoto, S., "Bitcoin: A Peer-to-Peer Electronic Cash
System", October 2008, <https://bitcoin.org/bitcoin.pdf>. System", October 2008, <https://bitcoin.org/bitcoin.pdf>.
[RFC7619] Smyslov, V. and P. Wouters, "The NULL Authentication [RFC7619] Smyslov, V. and P. Wouters, "The NULL Authentication
Method in the Internet Key Exchange Protocol Version 2 Method in the Internet Key Exchange Protocol Version 2
(IKEv2)", RFC 7619, DOI 10.17487/RFC7619, August 2015, (IKEv2)", RFC 7619, DOI 10.17487/RFC7619, August 2015,
<http://www.rfc-editor.org/info/rfc7619>. <http://www.rfc-editor.org/info/rfc7619>.
[RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm
Agility and Selecting Mandatory-to-Implement Algorithms", Agility and Selecting Mandatory-to-Implement Algorithms",
BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015,
<http://www.rfc-editor.org/info/rfc7696>. <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 all others who commented on the document.
Authors' Addresses Authors' Addresses
Yoav Nir Yoav Nir
Check Point Software Technologies Ltd. Check Point Software Technologies Ltd.
5 Hasolelim st. 5 Hasolelim st.
Tel Aviv 6789735 Tel Aviv 6789735
Israel Israel
EMail: ynir.ietf@gmail.com Email: ynir.ietf@gmail.com
Valery Smyslov Valery Smyslov
ELVIS-PLUS ELVIS-PLUS
PO Box 81 PO Box 81
Moscow (Zelenograd) 124460 Moscow (Zelenograd) 124460
Russian Federation Russian Federation
Phone: +7 495 276 0211 Phone: +7 495 276 0211
EMail: svan@elvis.ru Email: svan@elvis.ru
 End of changes. 194 change blocks. 
475 lines changed or deleted 488 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/