draft-ietf-ipsecme-ddos-protection-09.txt   draft-ietf-ipsecme-ddos-protection-10.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: March 16, 2017 ELVIS-PLUS Expires: April 4, 2017 ELVIS-PLUS
September 12, 2016 October 1, 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-09 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 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 March 16, 2017. This Internet-Draft will expire on April 4, 2017.
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
skipping to change at page 2, line 28 skipping to change at page 2, line 28
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 . . . . . . . . . . . . . . . 13
7. Using Puzzles in the Protocol . . . . . . . . . . . . . . . . 15 7. Using Puzzles in the Protocol . . . . . . . . . . . . . . . . 15
7.1. Puzzles in IKE_SA_INIT Exchange . . . . . . . . . . . . . 15 7.1. Puzzles in IKE_SA_INIT Exchange . . . . . . . . . . . . . 15
7.1.1. Presenting a Puzzle . . . . . . . . . . . . . . . . . 16 7.1.1. Presenting a Puzzle . . . . . . . . . . . . . . . . . 16
7.1.2. Solving a Puzzle and Returning the Solution . . . . . 18 7.1.2. Solving a Puzzle and Returning the Solution . . . . . 18
7.1.3. Computing a Puzzle . . . . . . . . . . . . . . . . . 19 7.1.3. Computing a Puzzle . . . . . . . . . . . . . . . . . 19
7.1.4. Analyzing Repeated Request . . . . . . . . . . . . . 19 7.1.4. Analyzing Repeated Request . . . . . . . . . . . . . 20
7.1.5. Deciding if to Serve the Request . . . . . . . . . . 21 7.1.5. Deciding if to Serve the Request . . . . . . . . . . 21
7.2. Puzzles in an IKE_AUTH Exchange . . . . . . . . . . . . . 22 7.2. Puzzles in an IKE_AUTH Exchange . . . . . . . . . . . . . 22
7.2.1. Presenting Puzzle . . . . . . . . . . . . . . . . . . 22 7.2.1. Presenting Puzzle . . . . . . . . . . . . . . . . . . 22
7.2.2. Solving Puzzle and Returning the Solution . . . . . . 23 7.2.2. Solving Puzzle and Returning the Solution . . . . . . 23
7.2.3. Computing the Puzzle . . . . . . . . . . . . . . . . 24 7.2.3. Computing the Puzzle . . . . . . . . . . . . . . . . 24
7.2.4. Receiving the Puzzle Solution . . . . . . . . . . . . 24 7.2.4. Receiving the Puzzle Solution . . . . . . . . . . . . 24
8. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 25 8. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 25
8.1. PUZZLE Notification . . . . . . . . . . . . . . . . . . . 25 8.1. PUZZLE Notification . . . . . . . . . . . . . . . . . . . 25
8.2. Puzzle Solution Payload . . . . . . . . . . . . . . . . . 25 8.2. Puzzle Solution Payload . . . . . . . . . . . . . . . . . 26
9. Operational Considerations . . . . . . . . . . . . . . . . . 26 9. Operational Considerations . . . . . . . . . . . . . . . . . 26
10. Security Considerations . . . . . . . . . . . . . . . . . . . 27 10. Security Considerations . . . . . . . . . . . . . . . . . . . 27
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
13.1. Normative References . . . . . . . . . . . . . . . . . . 28 13.1. Normative References . . . . . . . . . . . . . . . . . . 29
13.2. Informative References . . . . . . . . . . . . . . . . . 28 13.2. Informative References . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
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, bot-nets against DoS attacks from spoofed IP-addresses. However, botnets have
have become widespread, allowing attackers to perform Distributed become widespread, allowing attackers to perform Distributed Denial
Denial of Service (DDoS) attacks, which are more difficult to defend 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 (D)DoS attacks. It also introduces a new mechanism
-- "puzzles" -- that can help accomplish this task. -- "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].
skipping to change at page 8, line 11 skipping to change at page 8, line 11
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 re-calculated 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 bot-nets, 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 easily
reach hundreds of megabytes. 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 Bitcoins
skipping to change at page 9, line 49 skipping to change at page 9, line 49
+--------+----------------------------------+----------+ +--------+----------------------------------+----------+
| Key | Last 32 Hex PRF Digits | # 0-bits | | Key | Last 32 Hex PRF Digits | # 0-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: Three solutions for 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) | | # 0-bits | Time to Find 4 keys (seconds) |
+----------+-------------------------------+ +----------+-------------------------------+
| 8 | 0.0025 | | 8 | 0.0025 |
skipping to change at page 14, line 43 skipping to change at page 14, line 43
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 counter-measures 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 setting a soft limit per monitor the number of half-open SAs, and set a soft limit per peer IP
peer IP or prefix. The soft limit can be set to 3-5. If the puzzles or prefix. The soft limit can be set to 3-5. If the puzzles are
are used, the puzzle difficulty should be set to such a level (number used, the puzzle difficulty SHOULD be set to such a level (number of
of zero-bits) that all legitimate clients can handle it without zero-bits) that all legitimate clients can handle it without degraded
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 This will mitigate attacks based on IP address Initiators. This will mitigate attacks based on IP address spoofing,
spoofing, and help avoid the need to impose a greater burden in the and help avoid the need to impose a greater burden in the form of
form of puzzles on the general population of Initiators. This makes puzzles on the general population of Initiators. This makes the per-
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.
skipping to change at page 15, line 46 skipping to change at page 15, line 46
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 IKE Initiator indicates the desire to create a new IKE SA by sending
an IKE_SA_INIT request message. The message may optionally contain a an IKE_SA_INIT request message. The message may optionally contain a
COOKIE notification if this is a repeated request performed after the COOKIE notification if this is a repeated request performed after the
Responder's demand to return a cookie. Responder's demand to return a cookie.
HDR, [N(COOKIE),] SA, KE, Ni, [V+][N+] --> HDR, [N(COOKIE),] SA, KE, Ni, [V+][N+] -->
According to the plan, described in Section 6, the IKE Responder According to the plan, described in Section 6, the IKE Responder
should monitor incoming requests to detect whether it is under monitors incoming requests to detect whether it is under attack. If
attack. If the Responder learns that a (D)DoS attack is likely to be the Responder learns that a (D)DoS attack is likely to be in
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 so high, that puzzles need to be return a cookie. If the volume is high to such an extent that
used for defense, then the Responder requests the Initiator to solve puzzles need to be used for defense, then the Responder requests the
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
skipping to change at page 16, line 38 skipping to change at page 16, line 38
<-- 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
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 must
contain. In diverse environments it is next to impossible for the contain. In diverse environments it is nearly impossible for the
Responder to set any specific difficulty level that will result in Responder to set any specific difficulty level that will result in
roughly the same amount of work for all Initiators, because 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 Initiator is able to get, the better the chance is that it will
be served by the Responder. In diverse environments it is 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 identifier of the algorithm, The PUZZLE notification also contains an identifier of the algorithm,
that must be used by Initiator to compute puzzle. that is used by Initiator to compute 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. Thereby the
Initiator asserts that it supports all transforms from this list and Initiator asserts that it supports all transforms from this list and
can use any of them in the IKE SA being established. The Responder can use any of them in the IKE SA being established. The Responder
parses the received SA payload and finds a mutually supported of type parses the received SA payload and finds a mutually supported of type
PRF. The Responder selects the preferred PRF from the list of PRF. The Responder selects the preferred PRF from the list of
mutually supported ones and includes it into the PUZZLE notification. mutually supported ones and includes it into the PUZZLE notification.
There is no requirement that the PRF selected for puzzles be the same There is no requirement that the PRF selected for puzzles be the same
as the PRF that is negotiated later for use in core IKE SA crypto as the PRF that is negotiated later for use in core IKE SA crypto
operations. If there are no mutually supported PRFs, then IKE SA operations. If there are no mutually supported PRFs, then IKE SA
negotiation will fail anyway and there is no reason to return a negotiation will fail anyway and there is no reason to return a
puzzle. In this case the Responder returns a NO_PROPOSAL_CHOSEN puzzle. In this case the Responder returns a NO_PROPOSAL_CHOSEN
notification. Note that PRF is a mandatory transform type for IKE SA notification. Note that PRF is a mandatory transform type for IKE SA
(see Sections 3.3.2 and 3.3.3 of [RFC7296]) and at least one (see Sections 3.3.2 and 3.3.3 of [RFC7296]) and at least one
transform of this type must always be present in the SA payload in an transform of this type is always present in the SA payload in an
IKE_SA_INIT request message. 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 in
such a manner that the Responder is able to learn some important 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 Initiator. In particular - the Responder SHOULD be able to learn the
following information: 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 blob to the Responder, as the cookie would remain an opaque block of data to the
Initiator. If this information is encoded in the cookie, then the Initiator. If this information is encoded in the cookie, then the
Responder MUST make it integrity protected, so that any intended or Responder MUST make it integrity protected, so that any intended or
accidental alteration of this information in the returned cookie is accidental alteration of this information in the returned cookie is
detectable. So, the cookie would be generated as: 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 the Section 2.6 of [RFC7296], the size of the
cookie cannot exceed 64 bytes. cookie cannot exceed 64 bytes.
Alternatively, the Responder may continue to generate a cookie as Alternatively, the Responder may generate a cookie as suggested in
suggested in Section 2.6 of [RFC7296], but associate the additional Section 2.6 of [RFC7296], but associate the additional information,
information, using local storage identified with the particular using local storage identified with the particular version of the
version of the secret. In this case the Responder should have secret. In this case the Responder should have different secrets for
different secrets for every combination of difficulty level and every combination of difficulty level and number of consecutive
number of consecutive puzzles, and should change the secrets puzzles, and should change the secrets periodically, keeping a few
periodically, keeping a few previous versions, to be able to previous versions, to be able to calculate how long ago a cookie was
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
ensure that an attacker gains no or insignificant benefit from re-
using puzzle solutions in several requests. See Section 10 for
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 to 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 into it. The Responder
skipping to change at page 19, line 28 skipping to change at page 19, line 33
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 payload
(denoted as PS, see Section 8.2) along with the received COOKIE (denoted as PS, 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+] -->
7.1.3. Computing a Puzzle 7.1.3. Computing a Puzzle
General principals 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 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 contain 4 different keys requires that the puzzle solution contains 4 different keys (i.e.,
(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 it must be processed according Otherwise it is an initial request and in this case it MUST be
to Section 7.1. First, the cookie MUST be checked for validity. If processed according to Section 7.1. First, the cookie MUST be
the cookie is invalid, then the request is treated as initial and is checked for validity. If the cookie is invalid, then the request is
processed according to Section 7.1. It is RECOMMENDED that a new treated as initial and is processed according to Section 7.1. It is
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 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 which 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
skipping to change at page 21, line 5 skipping to change at page 21, line 8
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 ZBC to zero) 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
skipping to change at page 22, line 36 skipping to change at page 22, line 39
message, then the attack can be repeated several times on the same message, then the attack can be repeated several times on the same
IKE SA. 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 puzzle solution
before computing the D-H shared secret. before computing the D-H shared secret.
The Responder should constantly monitor the amount of the half-open The Responder constantly monitors the amount of the half-open IKE SA
IKE SA states that receive IKE_AUTH messages that cannot be decrypted states that receive IKE_AUTH messages that cannot be decrypted due to
due to integrity check failures. If the percentage of such states is integrity check failures. If the percentage of such states is high
high and it takes an essential fraction of Responder's computing and it takes an essential fraction of Responder's computing power to
power to calculate keys for them, then the Responder may assume that calculate keys for them, then the Responder may assume that it is
it is under attack and SHOULD use puzzles to make it harder for under attack and SHOULD use puzzles to make it harder for attackers.
attackers.
7.2.1. Presenting Puzzle 7.2.1. Presenting 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+]
skipping to change at page 23, line 17 skipping to change at page 23, line 21
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 D-H 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 estimate the computational power of the Responder would be able to roughly estimate the computational power
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 zero. In other words, the Responder
must always set a specific difficulty level and must not let the must always set a specific difficulty level and must not let the
Initiator to choose it on its own. Initiator to 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 IKE_AUTH exchange; however, it is expected that in most
cases they will be the same. cases they will be the same.
7.2.2. Solving Puzzle and Returning the Solution 7.2.2. Solving Puzzle and Returning the Solution
If the IKE_SA_INIT response message contains the PUZZLE notification If the IKE_SA_INIT regular response message (i.e. the message
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 Puzzle Solution 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 The Puzzle Solution (PS) payload MUST be placed outside the Encrypted
payload, so that the Responder is able to verify the puzzle before payload, so that the Responder is able to verify the puzzle before
calculating the D-H shared secret and the SK_* keys. calculating the D-H shared secret and the SK_* keys.
If IKE Fragmentation [RFC7383] is used in IKE_AUTH exchange, then the If IKE Fragmentation [RFC7383] is used in IKE_AUTH exchange, then the
PS payload MUST be present only in the first IKE Fragment message, in PS payload MUST be present only in the first IKE Fragment message, in
skipping to change at page 24, line 29 skipping to change at page 24, line 35
of the SA being established. 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 Puzzle Solution 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 computationlly
intensive operations i.e. computing the D-H shared secret and the intensive operations i.e., computing the D-H 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 Puzzle Solution payload in the
skipping to change at page 25, line 33 skipping to change at page 25, line 38
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 Security Parameter
Index (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 <TBA by IANA>, 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 section
"Transform Type 2 - Pseudo-Random Function Transform IDs" in "Transform Type 2 - Pseudo-Random Function Transform IDs" in
[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 is
free to select an appropriate difficulty level on its own (see 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).
skipping to change at page 26, line 40 skipping to change at page 26, line 46
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>.
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 for
taking about 1 second to solve the puzzle. A typical Initiator or taking about 1 second to solve the puzzle. A typical Initiator or
bot-net member in 2014 can perform slightly less than a million botnet member at the time this document is written can perform
hashes per second per core, so setting the difficulty level to n=20 slightly less than a million hashes per second per core, so setting
is a good compromise. It should be noted that mobile Initiators, the number of zero bits to 20 is a good compromise. It should be
especially phones are considerably weaker than that. Implementations noted that mobile Initiators, especially phones are considerably
should allow administrators to set the difficulty level, and/or be weaker than that. Implementations should allow administrators to set
able to set the difficulty level dynamically in response to load. the difficulty level, and/or be able to set the 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.
Until the widespread adoption of puzzles happens, most Initiators
will ignore them, as will all attackers. For puzzles to become a
really powerfull defense measure against DDoS attacks they must be
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 attacker, then the puzzle mechanism wouldn't be able
to prevent (D)DoS attacks and would only impose an additional burden to prevent (D)DoS attacks and would only impose an additional burden
on legitimate Initiators. On the other hand, if the puzzles are too on legitimate Initiators. On the other hand, if the puzzles are too
hard for the majority of Initiators, then many legitimate users would hard for the majority of Initiators, then many legitimate users would
experience unacceptable delays in IKE SA setup (and unacceptable experience unacceptable delays in IKE SA setup (and unacceptable
power consumption on mobile devices), that might cause them to cancel power consumption on mobile devices), that might cause them to cancel
the connection attempt. In this case the resources of the Responder the connection attempt. In this case the resources of the Responder
are preserved, however the DoS attack can be considered successful. are preserved, however the DoS attack can be considered successful.
Thus a sensible balance should be kept by the Responder while Thus a sensible balance should be kept by the Responder while
choosing the puzzle difficulty - to defend itself and to not over- choosing the puzzle difficulty - to defend itself and to not over-
defend itself. It is RECOMMENDED that the puzzle difficulty be defend itself. It is RECOMMENDED that the puzzle difficulty be
chosen so, that the Responder's load remains close to the maximum it chosen so, that the Responder's load remains close to the maximum it
can tolerate. It is also RECOMMENDED to dynamically adjust the can tolerate. It is also RECOMMENDED to dynamically adjust the
puzzle difficulty in accordance to the current Responder's load. puzzle difficulty in accordance to the current Responder's load.
If the cookie is generated as suggested in Section 2.6 of [RFC7296],
then an attacker can use the same SPIi and the same Ni for several
requests from the same IPi. This will result in generating the same
cookies for these requests until the Responder changes the value of
its cookie generation secret. Since the cookies are used as an input
data for puzzles in the IKE_SA_INIT exchange, generating same cookies
allows the attacker to re-use puzzle solution, thus bypassing proof
of work requirement. Note, that the attacker can get only limited
benefit from this situation - once the half-open SA is created by the
Responder all the subsequent initial requests with the same IPi and
SPIi will be treated as retransmissions and discarded by the
Responder. However, once this half-open SA is expired and deleted,
the attacker can create a new one for free if the Responder haven't
changed its cookie generation secret yet.
The Responder can use various countermeasures to completely eliminate
or mitigate this scenatio. First, the Responder can change its
cookie generation secret frequently especially if under attack, as
recommended in the Section 2.6 of [RFC7296]. For example, if the
Responder keeps two values of the secret (current and previous) and
the secret lifetime is no more than a half of the current half-open
SA retention time (see Section 4.1), then the attacker cannot get
benefit from re-using puzzle solution. However, short cookie
generation secret lifetime could have negative consequence on weak
legitimate Initiators, since it could take too long for them to solve
puzzles and their solutons would be discarded if the cookie
generation secret has been already changed few times.
Another approach for the Responder is to modify cookie generation
algorithm in such a way, that the generated cookies are always
different or are repeated only within short time period. If the
Responder includes timestamp in the <AdditionalInfo> as suggested in
Section 7.1.1.3, then the cookies will repeat only within short time
interval equal to timestamp resolution. Another approach for the
Responder is to maintain a global counter that is incremented every
time a cookie is generated and include this counter in the
<AdditionalInfo>. This will make every cookies unique.
Implementations MUST use one of the above (or some other)
countermeasures to completely eliminate or make insignificant the
possible benefit an attacker can get from re-using puzzle solutions.
Note, this issue doesn't exist in IKE_AUTH puzzles (Section 7.2)
since the puzzles in IKE_AUTH are always unique if the Responder
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 power 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 IoT devices.
If puzzles are too hard, then the required additional power If puzzles are too hard, then the required additional power
consumption may appear to be unacceptable for some Initiators. The consumption may appear to be unacceptable for some Initiators. The
Responder SHOULD take this possibility into consideration while Responder SHOULD take this possibility into consideration while
choosing the puzzle difficulty, and while selecting which percentage choosing the puzzle difficulty, and while selecting which percentage
of Initiators are allowed to reject solving puzzles. See of Initiators are allowed to reject solving puzzles. See
Section 7.1.4 for details. Section 7.1.4 for details.
skipping to change at page 28, line 17 skipping to change at page 29, line 27
12. 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 contributions to the design of the protocol. In particular, their contributions to the design of the protocol. In particular,
Tero Kivinen suggested the kind of puzzle where the task is to find a Tero Kivinen suggested the kind of puzzle where the task is to find a
solution with a requested number of zero trailing bits. Yaron solution with a requested number of zero trailing bits. Yaron
Sheffer and Scott Fluhrer suggested a way to make puzzle difficulty Sheffer and Scott Fluhrer suggested a way to make puzzle difficulty
less erratic by solving several weaker puzles. The authors also less erratic by solving several weaker puzles. The authors also
thank David Waltermire and Paul Wouters for their careful reviews of thank David Waltermire and Paul Wouters for their careful reviews of
the document, Graham Bartlett for pointing out to the possibility of the document, Graham Bartlett for pointing out to the possibility of
the "Hash & URL" related attack, and all others who commented the the "Hash & URL" related attack, Stephen Farrell for catching the
document. repeated cookie issue, and all others who commented the document.
13. References 13. References
13.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>.
 End of changes. 40 change blocks. 
82 lines changed or deleted 138 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/