draft-ietf-ipsecme-ddos-protection-04.txt   draft-ietf-ipsecme-ddos-protection-05.txt 
IPSecME Working Group Y. Nir IPSecME Working Group Y. Nir
Internet-Draft Check Point Internet-Draft Check Point
Intended status: Standards Track V. Smyslov Intended status: Standards Track V. Smyslov
Expires: September 2, 2016 ELVIS-PLUS Expires: September 22, 2016 ELVIS-PLUS
March 1, 2016 March 21, 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-04 draft-ietf-ipsecme-ddos-protection-05
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 help accomplish this task.
Status of This Memo Status of This Memo
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 2, 2016. This Internet-Draft will expire on September 22, 2016.
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. The Stateless Cookie . . . . . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
1.2. Conventions Used in This Document . . . . . . . . . . . . 4 3. The Vulnerability . . . . . . . . . . . . . . . . . . . . . . 3
2. The Vulnerability . . . . . . . . . . . . . . . . . . . . . . 4 4. Defense Measures while IKE SA is being created . . . . . . . 6
3. Puzzles . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Retention Periods for Half-Open SAs . . . . . . . . . . . 6
4. Retention Periods for Half-Open SAs . . . . . . . . . . . . . 8 4.2. Rate Limiting . . . . . . . . . . . . . . . . . . . . . . 6
5. Rate Limiting . . . . . . . . . . . . . . . . . . . . . . . . 9 4.3. The Stateless Cookie . . . . . . . . . . . . . . . . . . 7
6. Plan for Defending a Responder . . . . . . . . . . . . . . . 10 4.4. Puzzles . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Session Resumption . . . . . . . . . . . . . . . . . . . 12 4.5. Session Resumption . . . . . . . . . . . . . . . . . . . 10
7. Using Puzzles in the Protocol . . . . . . . . . . . . . . . . 12 4.6. Keeping computed Shared Keys . . . . . . . . . . . . . . 10
7.1. Puzzles in IKE_SA_INIT Exchange . . . . . . . . . . . . . 12 4.7. Preventing Attacks using "Hash and URL" Certificate
7.1.1. Presenting Puzzle . . . . . . . . . . . . . . . . . . 13 Encoding . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1.2. Solving Puzzle and Returning the Solution . . . . . . 15 5. Defense Measures after IKE SA is created . . . . . . . . . . 11
7.1.3. Computing Puzzle . . . . . . . . . . . . . . . . . . 16 6. Plan for Defending a Responder . . . . . . . . . . . . . . . 12
7.1.4. Analyzing Repeated Request . . . . . . . . . . . . . 16 7. Using Puzzles in the Protocol . . . . . . . . . . . . . . . . 14
7.1.5. Making Decision whether to Serve the Request . . . . 18 7.1. Puzzles in IKE_SA_INIT Exchange . . . . . . . . . . . . . 15
7.2. Puzzles in IKE_AUTH Exchange . . . . . . . . . . . . . . 19 7.1.1. Presenting Puzzle . . . . . . . . . . . . . . . . . . 15
7.2.1. Presenting Puzzle . . . . . . . . . . . . . . . . . . 19 7.1.2. Solving Puzzle and Returning the Solution . . . . . . 18
7.2.2. Solving Puzzle and Returning the Solution . . . . . . 20 7.1.3. Computing Puzzle . . . . . . . . . . . . . . . . . . 18
7.2.3. Computing Puzzle . . . . . . . . . . . . . . . . . . 21 7.1.4. Analyzing Repeated Request . . . . . . . . . . . . . 19
7.2.4. Receiving Puzzle Solution . . . . . . . . . . . . . . 21 7.1.5. Making Decision whether to Serve the Request . . . . 20
8. DoS Protection after IKE SA is created . . . . . . . . . . . 22 7.2. Puzzles in IKE_AUTH Exchange . . . . . . . . . . . . . . 21
9. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 23 7.2.1. Presenting Puzzle . . . . . . . . . . . . . . . . . . 22
9.1. PUZZLE Notification . . . . . . . . . . . . . . . . . . . 23 7.2.2. Solving Puzzle and Returning the Solution . . . . . . 22
9.2. Puzzle Solution Payload . . . . . . . . . . . . . . . . . 24 7.2.3. Computing Puzzle . . . . . . . . . . . . . . . . . . 23
10. Operational Considerations . . . . . . . . . . . . . . . . . 24 7.2.4. Receiving Puzzle Solution . . . . . . . . . . . . . . 23
11. Security Considerations . . . . . . . . . . . . . . . . . . . 25 8. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 24
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 8.1. PUZZLE Notification . . . . . . . . . . . . . . . . . . . 24
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 8.2. Puzzle Solution Payload . . . . . . . . . . . . . . . . . 25
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 9. Operational Considerations . . . . . . . . . . . . . . . . . 26
14.1. Normative References . . . . . . . . . . . . . . . . . . 26 10. Security Considerations . . . . . . . . . . . . . . . . . . . 26
14.2. Informative References . . . . . . . . . . . . . . . . . 27 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
13.1. Normative References . . . . . . . . . . . . . . . . . . 27
13.2. Informative References . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
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 (IKE) described in [RFC7296] The Internet Key Exchange protocol version 2 (IKEv2) described in
includes defense against DoS attacks. In particular, there is a [RFC7296] includes defense against DoS attacks. In particular, there
cookie mechanism that allows the IKE Responder to effectively defend is a cookie mechanism that allows the IKE Responder to effectively
itself against DoS attacks from spoofed IP-addresses. However, bot- defend itself against DoS attacks from spoofed IP-addresses.
nets have become widespread, allowing attackers to perform However, bot-nets have become widespread, allowing attackers to
Distributed Denial of Service (DDoS) attacks, which are more perform Distributed Denial of Service (DDoS) attacks, which are more
difficult to defend against. This document presents recommendations difficult to defend against. This document presents recommendations
to help the Responder thwart (D)DoS attacks. It also introduces a to help the Responder thwart (D)DoS attacks. It also introduces a
new mechanism -- "puzzles" -- that can help accomplish this task. new mechanism -- "puzzles" -- that can help accomplish this task.
2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
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 100 bytes to
several thousands bytes of memory. several thousands 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, and sending multiple Generating the IKE_SA_INIT request is cheap, and sending multiple
such requests can either cause the Responder to allocate too much such requests can either cause the Responder to allocate too much
resources and fail, or else if resource allocation is somehow resources and fail, or else if resource allocation is somehow
throttled, legitimate Initiators would also be prevented from setting throttled, legitimate Initiators would also be prevented from setting
up IKE SAs. up IKE SAs.
An obvious defense, which is described in Section 5, is limiting the An obvious defense, which is described in Section 4.2, is limiting
number of half-open SAs opened by a single peer. However, since all the number of half-open SAs opened by a single peer. However, since
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.
1.1. The Stateless Cookie
Section 2.6 of [RFC7296] offers a mechanism to mitigate this DoS
attack: the stateless cookie. When the server is under load, the
Responder responds to the IKE_SA_INIT request with a calculated
"stateless cookie" - a value that can be re-calculated based on
values in the IKE_SA_INIT request without storing Responder-side
state. The Initiator is expected to repeat the IKE_SA_INIT request,
this time including the stateless cookie.
Attackers that have multiple source IP addresses with return
routability, such as in the case of bot-nets, can fill up a half-open
SA table anyway. The cookie mechanism limits the amount of allocated
state to the size of the bot-net, multiplied by the number of half-
open SAs allowed per peer address, multiplied by the amount of state
allocated for each half-open SA. With typical values this can easily
reach hundreds of megabytes.
The mechanism described in Section 3 adds a proof of work for the
Initiator by calculating a pre-image for a partial hash value. This
sets an upper bound, determined by the attacker's CPU, to the number
of negotiations it can initiate in a unit of time.
1.2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. The Vulnerability
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 re-uses a Diffie-Hellman (D-H) 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
skipping to change at page 5, line 20 skipping to change at page 4, line 46
There are obvious ways for the Responder to protect itself even There are obvious ways for the Responder to protect itself even
without changes to the protocol. It can reduce the time that an without changes to the protocol. It can reduce the time that an
entry remains in the half-open SA database, and it can limit the entry remains in the half-open SA database, and it can limit the
amount of concurrent half-open SAs from a particular address or amount of concurrent half-open SAs from a particular address or
prefix. The attacker can overcome this by using spoofed source prefix. The attacker can overcome this by using spoofed source
addresses. 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 do the same thing only more of it. address or prefix work. Puzzles, introduced in Section 4.4, do the
They make it harder for an attacker to reach the goal of getting a same thing only more of it. They make it harder for an attacker to
half-open SA. They don't have to be so hard that an attacker can't reach the goal of getting a half-open SA. They don't have to be so
afford to solve a single puzzle; it's enough that they increase the hard that an attacker can't afford to solve a single puzzle; it's
cost of a half-open SAs for the attacker so that it can create only a enough that they increase the cost of a half-open SAs for the
few. attacker so that it can create only a few.
Reducing the amount of time an abandoned half-open SA is kept attacks Reducing the amount of time an abandoned half-open SA is kept attacks
the issue from the other side. It reduces the value the attacker the issue from the other side. It reduces the value the attacker
gets from managing to create a half-open SA. For example, if a half- gets from managing to create a half-open SA. For example, if a half-
open SA is kept for 1 minute and the capacity is 60,000 half-open open SA is kept for 1 minute and the capacity is 60,000 half-open
SAs, an attacker would need to create 1,000 half-open SAs per second. SAs, an attacker would need to create 1,000 half-open SAs per second.
Reduce the retention time to 3 seconds, and the attacker needs to Reduce the retention time to 3 seconds, and the attacker needs to
create 20,000 half-open SAs per second. By introducing a puzzle, create 20,000 half-open SAs per second. By introducing a puzzle,
each half-open SA becomes more expensive for an attacker, making it each half-open SA becomes more expensive for an attacker, making it
more likely to thwart an exhaustion attack against Responder memory. more likely to thwart an exhaustion attack against Responder memory.
skipping to change at page 6, line 8 skipping to change at page 5, line 35
It's probably better left to Intrusion Prevention System (IPS) It's probably better left to Intrusion Prevention System (IPS)
technology. technology.
On the other hand, sending an IKE_AUTH request is surprisingly cheap. On the other hand, sending an IKE_AUTH request is surprisingly cheap.
It requires a proper IKE header with the correct IKE SPIs, and it It requires a proper IKE header with the correct IKE SPIs, and it
requires a single Encrypted payload. The content of the payload requires a single Encrypted payload. The content of the payload
might as well be junk. The Responder has to perform the relatively might as well be junk. The Responder has to perform the relatively
expensive key derivation, only to find that the MAC on the Encrypted expensive key derivation, only to find that the MAC on the Encrypted
payload on the IKE_AUTH request does not check. Depending on the payload on the IKE_AUTH request does not check. Depending on the
Responder implementation, this can be repeated with the same half- Responder implementation, this can be repeated with the same half-
open SA (if the Responder does not delete the half-open SA following open SA. Puzzles can make attacks of such sort more costly for an
an unsuccessful decryption - see discussion in Section 4). 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 IPs/
prefixes. 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 cost of half-open SA up to what is tolerable for 4. Increasing cost of half-open SA up to what is tolerable for
legitimate clients. legitimate clients.
Puzzles have their place as part of #4. Puzzles have their place as part of #4.
3. Puzzles 4. Defense Measures while IKE SA is being created
4.1. Retention Periods for Half-Open SAs
As a UDP-based protocol, IKEv2 has to deal with packet loss through
retransmissions. Section 2.4 of [RFC7296] recommends "that messages
be retransmitted at least a dozen times over a period of at least
several minutes before giving up". Retransmission policies in
practice wait at least one or two seconds before retransmitting for
the first time.
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.
When not under attack, the half-open SA timeout SHOULD be set high
enough that the Initiator will have enough time to send multiple
retransmissions, minimizing the chance of transient network
congestion causing IKE failure.
When the system is under attack, as measured by the amount of half-
open SAs, it makes sense to reduce this lifetime. The Responder
should still allow enough time for the round-trip, enough time for
the Initiator to derive the D-H shared value, and enough time to
derive the IKE SA keys and the create the IKE_AUTH request. Two
seconds is probably as low a value as can realistically be used.
It could make sense to assign a shorter value to half-open SAs
originating from IP addresses or prefixes that are considered suspect
because of multiple concurrent half-open SAs.
4.2. Rate Limiting
Even with DDoS, the attacker has only a limited amount of nodes
participating in the attack. By limiting the amount of half-open SAs
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
derivations that the Responder is forced to complete.
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
Internet using a routable address or are hidden behind a NAT device
with a single IPv4 external address. IPv6 networks are currently a
rarity, so we can only speculate on what their wide deployment will
be like, but the current thinking is that ISP customers will be
assigned whole subnets, so we don't expect the kind of NAT deployment
that is common in IPv4. For this reason, it makes sense to use a
64-bit prefix as the basis for rate limiting in IPv6.
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
possible, both factors should be taken into account when deciding
which IP address or prefix is considered suspicious.
There are two ways to rate-limit a peer address or prefix:
1. Hard Limit - where the number of half-open SAs is capped, and any
further IKE_SA_INIT requests are rejected.
2. Soft Limit - where if a set number of half-open SAs exist for a
particular address or prefix, any IKE_SA_INIT request will
require solving a puzzle.
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.
The downside is that it allows the attacker to block IKE initiation
from small parts of the Internet. For example, if an network service
provider or some establishment offers Internet connectivity to its
customers or employees through an IPv4 NAT device, a single malicious
customer can create enough half-open SAs to fill the quota for the
NAT device external IP address. Legitimate Initiators on the same
network will not be able to initiate IKE.
The advantage of a soft limit is that legitimate clients can always
connect. The disadvantage is that an adversary with sufficient CPU
resources can still effectively DoS the Responder.
Regardless of the type of rate-limiting used, there is a huge
advantage in blocking the DoS attack using rate-limiting for
legitimate clients that are away from the attacking nodes. In such
cases, adverse impacts caused by the attack or by the measures used
to counteract the attack can be avoided.
4.3. The Stateless Cookie
Section 2.6 of [RFC7296] offers a mechanism to mitigate DoS attack:
the stateless cookie. When the server is under load, the Responder
responds to the IKE_SA_INIT request with a calculated "stateless
cookie" - a value that can be re-calculated based on values in the
IKE_SA_INIT request without storing Responder-side state. The
Initiator is expected to repeat the IKE_SA_INIT request, this time
including the stateless cookie.
Attackers that have multiple source IP addresses with return
routability, such as in the case of bot-nets, can fill up a half-open
SA table anyway. The cookie mechanism limits the amount of allocated
state to the size of the bot-net, multiplied by the number of half-
open SAs allowed per peer address, multiplied by the amount of state
allocated for each half-open SA. With typical values this can easily
reach hundreds of megabytes.
4.4. Puzzles
The puzzle introduced here extends the cookie mechanism from The puzzle introduced here extends the cookie mechanism from
[RFC7296]. It is loosely based on the proof-of-work technique used [RFC7296]. It is loosely based on the proof-of-work technique used
in Bitcoins [bitcoins]. in Bitcoins [bitcoins]. This sets an upper bound, determined by the
attacker's CPU, to the number of negotiations it can initiate in a
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 5 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 notification in When the Responder decides to send the challenge notification in
response to a IKE_SA_INIT request, the notification includes three response to a IKE_SA_INIT request, the notification includes three
fields: fields:
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.
skipping to change at page 8, line 45 skipping to change at page 10, line 29
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 = 739ae7492d8a810cf5e8dc0f9626c9dda773c5a3
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 i5. Run
times can be halved or quartered with multi-core code, but would be times can be halved or quartered with multi-core code, but would be
longer on mobile phone processors, even if those are multi-core as longer on mobile phone processors, even if those are multi-core as
well. With these figures 18 bits is believed to be a reasonable well. With these figures 18 bits is believed to be a reasonable
choice for puzzle level difficulty for all Initiators, and 20 bits is choice for puzzle level difficulty for all Initiators, and 20 bits is
acceptable for specific hosts/prefixes. acceptable for specific hosts/prefixes.
4. Retention Periods for Half-Open SAs Using puzzles mechanism in the IKE_SA_INIT exchange is described in
Section 7.1.
As a UDP-based protocol, IKEv2 has to deal with packet loss through 4.5. Session Resumption
retransmissions. Section 2.4 of [RFC7296] recommends "that messages
be retransmitted at least a dozen times over a period of at least
several minutes before giving up". Retransmission policies in
practice wait at least one or two seconds before retransmitting for
the first time.
Because of this, setting the timeout on a half-open SA too low will When the Responder is under attack, it MAY choose to prefer
cause it to expire whenever even one IKE_AUTH request packet is lost. previously authenticated peers who present a Session Resumption
When not under attack, the half-open SA timeout SHOULD be set high ticket (see [RFC5723] for details). The Responder MAY require such
enough that the Initiator will have enough time to send multiple Initiators to pass a return routability check by including the COOKIE
retransmissions, minimizing the chance of transient network notification in the IKE_SESSION_RESUME response message, as allowed
congestion causing IKE failure. by Section 4.3.2. of [RFC5723]. Note that the Responder SHOULD cache
tickets for a short time to reject reused tickets (Section 4.3.1),
and therefore there should be no issue of half-open SAs resulting
from replayed IKE_SESSION_RESUME messages.
When the system is under attack, as measured by the amount of half- 4.6. Keeping computed Shared Keys
open SAs, it makes sense to reduce this lifetime. The Responder
should still allow enough time for the round-trip, enough time for
the Initiator to derive the D-H shared value, and enough time to
derive the IKE SA keys and the create the IKE_AUTH request. Two
seconds is probably as low a value as can realistically be used.
It could make sense to assign a shorter value to half-open SAs Once the IKE_SA_INIT exchange is finished, the Responder is waiting
originating from IP addresses or prefixes that are considered suspect for the first message of the IKE_AUTH exchange from the Initiator.
because of multiple concurrent half-open SAs. At this point the Initiator is not yet authenticated and this fact
allows a malicious peer to perform an attack, described in Section 3
- it can just send a garbage in the IKE_AUTH message thus forcing the
Responder to perform CPU costly operations to compute SK_* keys.
5. Rate Limiting If the received IKE_AUTH message failed to decrypt correctly (or
failed to pass ICV check), then the Responder SHOULD still keep the
computed SK_* keys, so that if it happened to be an attack, then the
malicious Initiator cannot get advantage of repeating the attack
multiple times on a single IKE SA. The responder can also use
puzzles in the IKE_AUTH exchange as decribed in Section 7.2.
Even with DDoS, the attacker has only a limited amount of nodes 4.7. Preventing Attacks using "Hash and URL" Certificate Encoding
participating in the attack. By limiting the amount of half-open SAs
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
derivations that the Responder is forced to complete.
In IPv4 it makes sense to limit the number of half-open SAs based on In IKEv2 each side may use "Hash and URL" Certificate Encoding to
IP address. Most IPv4 nodes are either directly attached to the instruct the peer to retrieve certificates from the specified
Internet using a routable address or are hidden behind a NAT device location (see Section 3.6 of [RFC7296] for details). Malicious
with a single IPv4 external address. IPv6 networks are currently a initiators can use this feature to mount a DoS attack on responder by
rarity, so we can only speculate on what their wide deployment will providing an URL pointing to a large file possibly containing
be like, but the current thinking is that ISP customers will be garbage. While downloading the file the responder consumes CPU,
assigned whole subnets, so we don't expect the kind of NAT deployment memory and network bandwidth.
that is common in IPv4. For this reason, it makes sense to use a
64-bit prefix as the basis for rate limiting in IPv6.
The number of half-open SAs is easy to measure, but it is also To prevent this kind of attacks the responder should not blindly
worthwhile to measure the number of failed IKE_AUTH exchanges. If download the whole file. Instead it SHOULD first read the initial
possible, both factors should be taken into account when deciding few bytes, decode the length of the ASN.1 structure from these bytes,
which IP address or prefix is considered suspicious. and then download no more than the decoded number of bytes. Note,
that it is always possible to determine the length of ASN.1
structures used in IKEv2 by analyzing the first few bytes, if they
are DER-encoded. Implementations SHOULD also apply a configurable
hard limit to the number of pulled bytes and SHOULD provide an
ability for an administrator to either completely disable this
feature or to limit its use to a configurable list of trusted URLs.
There are two ways to rate-limit a peer address or prefix: 5. Defense Measures after IKE SA is created
1. Hard Limit - where the number of half-open SAs is capped, and any Once IKE SA is created there is usually not much traffic over it. In
further IKE_SA_INIT requests are rejected. most cases this traffic consists of exchanges aimed to create
additional Child SAs, rekey, or delete them and check the liveness of
the peer. With a typical setup and typical Child SA lifetimes, there
are typically no more than a few such exchanges, often less. Some of
these exchanges require relatively little resources (like liveness
check), while others may be resource consuming (like creating or
rekeying Child SA with D-H exchange).
2. Soft Limit - where if a set number of half-open SAs exist for a Since any endpoint can initiate a new exchange, there is a
particular address or prefix, any IKE_SA_INIT request will possibility that a peer would initiate too many exchanges that could
require solving a puzzle. exhaust host resources. For example, the peer can perform endless
continuous Child SA rekeying or create overwhelming number of Child
SAs with the same Traffic Selectors etc. Such behavior may be caused
by buggy implementation, misconfiguration or be intentional. The
latter becomes more of a real threat if the peer uses NULL
Authentication, described in [RFC7619]. In this case the peer
remains anonymous, allowing it to escape any responsibility for its
actions.
The advantage of the hard limit method is that it provides a hard cap The following recommendations for defense against possible DoS
on the amount of half-open SAs that the attacker is able to create. attacks after IKE SA is established are mostly intended for
The downside is that it allows the attacker to block IKE initiation implementations that allow unauthenticated IKE sessions; however,
from small parts of the Internet. For example, if an network service they may also be useful in other cases.
provider or some establishment offers Internet connectivity to its
customers or employees through an IPv4 NAT device, a single malicious
customer can create enough half-open SAs to fill the quota for the
NAT device external IP address. Legitimate Initiators on the same
network will not be able to initiate IKE.
The advantage of a soft limit is that legitimate clients can always o If the IKEv2 window size is greater than one, then the peer could
connect. The disadvantage is that an adversary with sufficient CPU initiate multiple simultaneous exchanges that could increase host
resources can still effectively DoS the Responder. resource consumption. Since currently there is no way in IKEv2 to
decrease window size once it was increased (see Section 2.3 of
[RFC7296]), the window size cannot be dynamically adjusted
depending on the load. For that reason, it is NOT RECOMMENDED to
ever increase the IKEv2 window size above its default value of one
if the peer uses NULL Authentication.
Regardless of the type of rate-limiting used, there is a huge o If the peer initiates requests to rekey IKE SA or Child SA too
advantage in blocking the DoS attack using rate-limiting for often, implementations can respond to some of these requests with
legitimate clients that are away from the attacking nodes. In such the TEMPORARY_FAILURE notification, indicating that the request
cases, adverse impacts caused by the attack or by the measures used should be retried after some period of time.
to counteract the attack can be avoided.
o If the peer creates too many Child SA with the same or overlapping
Traffic Selectors, implementations can respond with the
NO_ADDITIONAL_SAS notification.
o If the peer initiates too many exchanges of any kind,
implementations can introduce an artificial delay before
responding to request messages. This delay would decrease the
rate the implementation need to process requests from any
particular peer, making it possible to process requests from the
others. The delay should not be too long to avoid causing the IKE
SA to be deleted on the other end due to timeout. It is believed
that a few seconds is enough. Note, that if the Responder
receives retransmissions of the request message during the delay
period, the retransmitted messages should be silently discarded.
o If these counter-measures are inefficient, implementations can
delete the IKE SA with an offending peer by sending Delete
Payload.
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 defeating the DDoS attack. configurable parameters needed for defeating the DDoS attack.
Implementations may be deployed in different environments, so it is Implementations may be deployed in different environments, so it is
RECOMMENDED that the parameters be settable. As an example, most RECOMMENDED that the parameters be settable. As an example, most
skipping to change at page 12, line 21 skipping to change at page 14, line 39
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.
6.1. Session Resumption
When the Responder is under attack, it MAY choose to prefer
previously authenticated peers who present a Session Resumption
ticket (see [RFC5723] for details). The Responder MAY require such
Initiators to pass a return routability check by including the COOKIE
notification in the IKE_SESSION_RESUME response message, as allowed
by Section 4.3.2. of [RFC5723]. Note that the Responder SHOULD cache
tickets for a short time to reject reused tickets (Section 4.3.1),
and therefore there should be no issue of half-open SAs resulting
from replayed IKE_SESSION_RESUME messages.
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. The Section 7.1 describes using puzzles in
the IKE_SA_INIT exchange and the Section 7.2 describes using puzzles the IKE_SA_INIT exchange and the Section 7.2 describes using puzzles
in the IKE_AUTH exchange. Both sections are divided into subsections in the 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
skipping to change at page 13, line 27 skipping to change at page 15, line 39
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 return lottery. In other words, the Responder must first perform 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 Puzzle 7.1.1. Presenting Puzzle
If the Responder makes a decision to use puzzles, then it MUST If the Responder makes a decision to use puzzles, then it MUST
include two notifications in its response message - the COOKIE include two notifications in its response message - the COOKIE
notification and the PUZZLE notification. The format of the PUZZLE notification and the PUZZLE notification. The format of the PUZZLE
notification is described in Section 9.1. notification is described in Section 8.1.
<-- HDR, N(COOKIE), N(PUZZLE), [V+][N+] <-- HDR, N(COOKIE), N(PUZZLE), [V+][N+]
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
get better chances to be served. get better chances to be served.
7.1.1.1. Selecting Puzzle Difficulty Level 7.1.1.1. Selecting Puzzle Difficulty Level
The PUZZLE notification contains the difficulty level of the puzzle - The PUZZLE notification contains the difficulty level of the puzzle -
skipping to change at page 16, line 5 skipping to change at page 18, line 22
difficulty, even if it supports puzzles. In both cases the Initiator difficulty, even if it supports puzzles. In both cases the Initiator
acts as described in Section 2.6 of [RFC7296] - it restarts the acts as described in Section 2.6 of [RFC7296] - it restarts the
request and includes the received COOKIE notification into it. The request and includes the received COOKIE notification into it. The
Responder should be able to distinguish the situation when it just Responder should be able to distinguish the situation when it just
requested a cookie from the situation when the puzzle was given to requested a cookie from the situation when the puzzle was given to
the Initiator, but the Initiator for some reason ignored it. the 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 do it. In this case the Initiator SHOULD resend information to do it. In this case the Initiator MUST ignore the
IKE_SA_INIT request. If this situation repeats several times, then received message and continue to wait until either the valid one is
it means that something is wrong and the IKE SA cannot be received or the retransmission timer fires. If it fails to receive
established. the valid message after several retransmissions of IKE_SA_INIT
request, then it means that something is wrong and the IKE SA cannot
be established.
If the Initiator supports puzzles and is ready to deal with them, If the Initiator supports puzzles and is ready to deal with them,
then it tries to solve the given puzzle. After the puzzle is solved then it tries to solve the given puzzle. After the puzzle is solved
the Initiator restarts the request and returns the puzzle solution in the Initiator restarts the request and returns the puzzle solution in
a new payload called a Puzzle Solution payload (denoted as PS, see a new payload called a Puzzle Solution payload (denoted as PS, see
Section 9.2) along with the received COOKIE notification back to the Section 8.2) along with the received COOKIE notification back to the
Responder. Responder.
HDR, N(COOKIE), [PS,] SA, KE, Ni, [V+][N+] --> HDR, N(COOKIE), [PS,] SA, KE, Ni, [V+][N+] -->
7.1.3. Computing Puzzle 7.1.3. Computing Puzzle
General principals of constructing puzzles in IKEv2 are described in General principals of constructing puzzles in IKEv2 are described in
Section 3. 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 pseudo-random function PRF find N different keys Ki
(where i=[1..N]) for that PRF so that the result of PRF(Ki,S) has at (where i=[1..N]) for that PRF so that the result of PRF(Ki,S) has at
least the specified number of trailing zero bits. This specification least the specified number of trailing zero bits. This specification
requires that the solution to the puzzle contains 4 different keys requires that the solution to the puzzle contains 4 different keys
(i.e. N=4). (i.e. 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 IKE_SA_INIT the task for unpredictable string S. In other words, in IKE_SA_INIT the task for
the IKE Initiator is to find the four different, equal-sized keys Ki 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) where for the agreed upon PRF such that each result of PRF(Ki,cookie) where
skipping to change at page 19, line 13 skipping to change at page 21, line 27
priority and the available resources. priority and the available resources.
7.2. Puzzles in IKE_AUTH Exchange 7.2. Puzzles in 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
return routability check and has proved that it has performed some return routability check and has proved that it has performed some
work to complete IKE_SA_INIT exchange. However, the Initiator is not work to complete IKE_SA_INIT exchange. However, the Initiator is not
yet authenticated and this fact allows malicious Initiator to perform yet authenticated and this fact allows malicious Initiator to perform
an attack, described in Section 2. Unlike DoS attack in IKE_SA_INIT an attack, described in Section 3. Unlike DoS attack in IKE_SA_INIT
exchange, which is targeted on the Responder's memory resources, the exchange, which is targeted on the Responder's memory resources, the
goal of this attack is to exhaust a Responder's CPU power. The goal of this attack is to exhaust a Responder's CPU power. The
attack is performed by sending the first IKE_AUTH message containing attack is performed by sending the first IKE_AUTH message containing
garbage. This costs nothing to the Initiator, but the Responder has garbage. This costs nothing to the Initiator, but the Responder has
to do relatively costly operations of computing the D-H shared secret to do relatively costly operations of computing the D-H shared secret
and deriving SK_* keys to be able to verify authenticity of the and deriving SK_* keys to be able to verify authenticity of the
message. If the Responder doesn't keep the computed keys after an message. If the Responder doesn't keep the computed keys after an
unsuccessful verification of the IKE_AUTH message, then the attack unsuccessful verification of the IKE_AUTH message, then the attack
can be repeated several times on the same IKE SA. can be repeated several times on the same IKE SA.
skipping to change at page 22, line 7 skipping to change at page 24, line 21
first IKE Fragment messages before receiving the first one, first IKE Fragment messages before receiving the first one,
containing the PS payload. In this case the Responder MAY choose to containing the PS payload. In this case the Responder MAY choose to
keep the received fragments until the first fragment containing the keep the received fragments until the first fragment containing the
solution to the puzzle is received. However, in this case the solution to the puzzle is received. However, in this case the
Responder SHOULD NOT try to verify authenticity of the kept fragments Responder SHOULD NOT try to verify authenticity of the kept fragments
until the first fragment with the PS payload is received and the until the first fragment with the PS payload is received and the
solution to the puzzle is verified. After successful verification of solution to the puzzle is verified. After successful verification of
the puzzle the Responder could calculate the SK_* key and verify the puzzle the Responder could calculate the SK_* key and verify
authenticity of the collected fragments. authenticity of the collected fragments.
8. DoS Protection after IKE SA is created 8. Payload Formats
Once IKE SA is created there is usually not much traffic over it. In
most cases this traffic consists of exchanges aimed to create
additional Child SAs, rekey, or delete them and check the liveness of
the peer. With a typical setup and typical Child SA lifetimes, there
are typically no more than a few such exchanges, often less. Some of
these exchanges require relatively little resources (like liveness
check), while others may be resource consuming (like creating or
rekeying Child SA with D-H exchange).
Since any endpoint can initiate a new exchange, there is a
possibility that a peer would initiate too many exchanges that could
exhaust host resources. For example, the peer can perform endless
continuous Child SA rekeying or create overwhelming number of Child
SAs with the same Traffic Selectors etc. Such behavior may be caused
by buggy implementation, misconfiguration or be intentional. The
latter becomes more of a real threat if the peer uses NULL
Authentication, described in [RFC7619]. In this case the peer
remains anonymous, allowing it to escape any responsibility for its
actions.
The following recommendations for defense against possible DoS
attacks after IKE SA is established are mostly intended for
implementations that allow unauthenticated IKE sessions; however,
they may also be useful in other cases.
o If the IKEv2 window size is greater than one, then the peer could
initiate multiple simultaneous exchanges that could increase host
resource consumption. Since currently there is no way in IKEv2 to
decrease window size once it was increased (see Section 2.3 of
[RFC7296]), the window size cannot be dynamically adjusted
depending on the load. For that reason, it is NOT RECOMMENDED to
ever increase the IKEv2 window size above its default value of one
if the peer uses NULL Authentication.
o If the peer initiates requests to rekey IKE SA or Child SA too
often, implementations can respond to some of these requests with
the TEMPORARY_FAILURE notification, indicating that the request
should be retried after some period of time.
o If the peer creates too many Child SA with the same or overlapping
Traffic Selectors, implementations can respond with the
NO_ADDITIONAL_SAS notification.
o If the peer initiates too many exchanges of any kind,
implementations can introduce an artificial delay before
responding to request messages. This delay would decrease the
rate the implementation need to process requests from any
particular peer, making it possible to process requests from the
others. The delay should not be too long to avoid causing the IKE
SA to be deleted on the other end due to timeout. It is believed
that a few seconds is enough. Note, that if the Responder
receives retransmissions of the request message during the delay
period, the retransmitted messages should be silently discarded.
o If these counter-measures are inefficient, implementations can
delete the IKE SA with an offending peer by sending Delete
Payload.
9. Payload Formats
9.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 necessity to solve the puzzle. It contains the Initiator about the necessity 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.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 24, line 11 skipping to change at page 25, line 14
o Difficulty (1 octet) -- Difficulty Level of the puzzle. Specifies o Difficulty (1 octet) -- Difficulty Level of the puzzle. Specifies
minimum number of trailing zero bits (ZBC), that each of 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 is
free to select appropriate difficulty level on its own (see free to select 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.
9.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 Puzzle Solution payload and denoted as
PS in this document. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 24, line 46 skipping to change at page 26, line 5
(or even less) octets in length, however it depends on puzzle (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 Payload (as indicated
in Payload Length field) minus 4 - the size of Payload Header. in Payload Length field) minus 4 - the size of Payload Header.
The payload type for the Puzzle Solution payload is <TBA by IANA>. The payload type for the Puzzle Solution payload is <TBA by IANA>.
10. Operational Considerations 9. Operational Considerations
The difficulty level should be set by balancing the requirement to The difficulty level should be set by balancing the requirement to
minimize the latency for legitimate Initiators and making things minimize the latency for legitimate Initiators and making things
difficult for attackers. A good rule of thumb is for taking about 1 difficult for attackers. A good rule of thumb is for taking about 1
second to solve the puzzle. A typical Initiator or bot-net member in second to solve the puzzle. A typical Initiator or bot-net member in
2014 can perform slightly less than a million hashes per second per 2014 can perform slightly less than a million hashes per second per
core, so setting the difficulty level to n=20 is a good compromise. core, so setting the difficulty level to n=20 is a good compromise.
It should be noted that mobile Initiators, especially phones are It should be noted that mobile Initiators, especially phones are
considerably weaker than that. Implementations should allow considerably weaker than that. Implementations should allow
administrators to set the difficulty level, and/or be able to set the administrators to set the difficulty level, and/or be able to set the
difficulty level dynamically in response to load. difficulty level 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.
11. Security Considerations 10. Security Considerations
When selecting parameters for the puzzles, in particular the puzzle When selecting parameters for the puzzles, in particular the puzzle
difficulty, care must be taken. If the puzzles appeared too easy for difficulty, care must be taken. If the puzzles appeared too easy for
majority of the attackers, then the puzzles mechanism wouldn't be majority of the attackers, then the puzzles mechanism wouldn't be
able to prevent DoS attack and would only impose an additional burden able to prevent DoS attack and would only impose an additional burden
on the legitimate Initiators. On the other hand, if the puzzles on the legitimate Initiators. On the other hand, if the puzzles
appeared to be too hard for majority of the Initiators then many appeared to be too hard for majority of the Initiators then many
legitimate users would experience unacceptable delay in IKE SA setup legitimate users would experience unacceptable delay in IKE SA setup
(or unacceptable power consumption on mobile devices), that might (or unacceptable power consumption on mobile devices), that might
cause them to cancel connection attempt. In this case the resources cause them to cancel connection attempt. In this case the resources
skipping to change at page 25, line 49 skipping to change at page 27, line 7
for some Initiators. The Responder SHOULD take this possibility into for some Initiators. The Responder SHOULD take this possibility into
considerations while choosing the puzzles difficulty and while considerations while choosing the puzzles difficulty and while
selecting which percentage of Initiators are allowed to reject selecting which percentage of Initiators are allowed to reject
solving puzzles. See 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 identity
is never verified, that may be used by attackers to perform DoS is never verified, that may be used by attackers to perform DoS
attack after IKE SA is established. Responders that allow attack after IKE SA is established. Responders that allow
unauthenticated Initiators to connect must be prepared deal with unauthenticated Initiators to connect must be prepared deal with
various kinds of DoS attacks even after IKE SA is created. See various kinds of DoS attacks even after IKE SA is created. See
Section 8 for details. Section 5 for details.
12. IANA Considerations To prevent amplification attacks implementations must strictly follow
the retransmission rules described in Section 2.1 of [RFC7296].
11. IANA Considerations
This document defines a new payload in the "IKEv2 Payload Types" This document defines a new payload in the "IKEv2 Payload Types"
registry: registry:
<TBA> Puzzle Solution PS <TBA> 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 <TBA> PUZZLE
13. Acknowledgements 12. Acknowledgements
The authors thank Tero Kivinen, Yaron Sheffer and Scott Fluhrer for The authors thank Tero Kivinen, Yaron Sheffer and Scott Fluhrer for
their contribution into design of the protocol. In particular, Tero their contribution into design of the protocol. In particular, Tero
Kivinen suggested the kind of puzzle where the task is to find a Kivinen suggested the kind of puzzle where the task is to find a
solution with requested number of zero trailing bits. Yaron Sheffer solution with requested number of zero trailing bits. Yaron Sheffer
and Scott Fluhrer suggested a way to make puzzle difficulty less and Scott Fluhrer suggested a way to make puzzle difficulty less
erratic by solving several weaker puzles. The authors also thank erratic by solving several weaker puzles. The authors also thank
David Waltermire for his carefull review of the draft and all others David Waltermire for his carefull review of the document, Graham
who commented the document. Bartlett for pointing out to the possibility of "Hash & URL" related
attack, and all others who commented the document.
14. References 13. References
14.1. Normative References 13.1. Normative References
[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>.
[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] [IKEV2-IANA]
"Internet Key Exchange Version 2 (IKEv2) Parameters", "Internet Key Exchange Version 2 (IKEv2) Parameters",
<http://www.iana.org/assignments/ikev2-parameters>. <http://www.iana.org/assignments/ikev2-parameters>.
14.2. Informative References 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>.
[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>.
 End of changes. 46 change blocks. 
244 lines changed or deleted 293 lines changed or added

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