draft-ietf-ipsecme-ddos-protection-03.txt   draft-ietf-ipsecme-ddos-protection-04.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: June 18, 2016 ELVIS-PLUS Expires: September 2, 2016 ELVIS-PLUS
December 16, 2015 March 1, 2016
Protecting Internet Key Exchange (IKE) Implementations from Distributed Protecting Internet Key Exchange Protocol version 2 (IKEv2)
Denial of Service Attacks Implementations from Distributed Denial of Service Attacks
draft-ietf-ipsecme-ddos-protection-03 draft-ietf-ipsecme-ddos-protection-04
Abstract Abstract
This document recommends implementation and configuration best This document recommends implementation and configuration best
practices for Internet-connected IPsec Responders, to allow them to practices for Internet Key Exchange Protocol version 2 (IKEv2)
resist Denial of Service and Distributed Denial of Service attacks. Responders, to allow them to resist Denial of Service and Distributed
Additionally, the document introduces a new mechanism called "Client Denial of Service attacks. Additionally, the document introduces a
Puzzles" that help accomplish this task. new mechanism called "Client Puzzles" that help accomplish this task.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 June 18, 2016. This Internet-Draft will expire on September 2, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 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
skipping to change at page 2, line 24 skipping to change at page 2, line 24
4. Retention Periods for Half-Open SAs . . . . . . . . . . . . . 8 4. Retention Periods for Half-Open SAs . . . . . . . . . . . . . 8
5. Rate Limiting . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Rate Limiting . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Plan for Defending a Responder . . . . . . . . . . . . . . . 10 6. Plan for Defending a Responder . . . . . . . . . . . . . . . 10
6.1. Session Resumption . . . . . . . . . . . . . . . . . . . 12 6.1. Session Resumption . . . . . . . . . . . . . . . . . . . 12
7. Using Puzzles in the Protocol . . . . . . . . . . . . . . . . 12 7. Using Puzzles in the Protocol . . . . . . . . . . . . . . . . 12
7.1. Puzzles in IKE_SA_INIT Exchange . . . . . . . . . . . . . 12 7.1. Puzzles in IKE_SA_INIT Exchange . . . . . . . . . . . . . 12
7.1.1. Presenting Puzzle . . . . . . . . . . . . . . . . . . 13 7.1.1. Presenting Puzzle . . . . . . . . . . . . . . . . . . 13
7.1.2. Solving Puzzle and Returning the Solution . . . . . . 15 7.1.2. Solving Puzzle and Returning the Solution . . . . . . 15
7.1.3. Computing Puzzle . . . . . . . . . . . . . . . . . . 16 7.1.3. Computing Puzzle . . . . . . . . . . . . . . . . . . 16
7.1.4. Analyzing Repeated Request . . . . . . . . . . . . . 16 7.1.4. Analyzing Repeated Request . . . . . . . . . . . . . 16
7.1.5. Making Decision whether to Serve the Request . . . . 17 7.1.5. Making Decision whether to Serve the Request . . . . 18
7.2. Puzzles in IKE_AUTH Exchange . . . . . . . . . . . . . . 18 7.2. Puzzles in IKE_AUTH Exchange . . . . . . . . . . . . . . 19
7.2.1. Presenting Puzzle . . . . . . . . . . . . . . . . . . 19 7.2.1. Presenting Puzzle . . . . . . . . . . . . . . . . . . 19
7.2.2. Solving Puzzle and Returning the Solution . . . . . . 20 7.2.2. Solving Puzzle and Returning the Solution . . . . . . 20
7.2.3. Computing Puzzle . . . . . . . . . . . . . . . . . . 20 7.2.3. Computing Puzzle . . . . . . . . . . . . . . . . . . 21
7.2.4. Receiving Puzzle Solution . . . . . . . . . . . . . . 21 7.2.4. Receiving Puzzle Solution . . . . . . . . . . . . . . 21
8. DoS Protection after IKE SA is created . . . . . . . . . . . 21 8. DoS Protection after IKE SA is created . . . . . . . . . . . 22
9. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 22 9. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 23
9.1. PUZZLE Notification . . . . . . . . . . . . . . . . . . . 23 9.1. PUZZLE Notification . . . . . . . . . . . . . . . . . . . 23
9.2. Puzzle Solution Payload . . . . . . . . . . . . . . . . . 23 9.2. Puzzle Solution Payload . . . . . . . . . . . . . . . . . 24
10. Operational Considerations . . . . . . . . . . . . . . . . . 24 10. Operational Considerations . . . . . . . . . . . . . . . . . 24
11. Security Considerations . . . . . . . . . . . . . . . . . . . 24 11. Security Considerations . . . . . . . . . . . . . . . . . . . 25
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
13.1. Normative References . . . . . . . . . . . . . . . . . . 25 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
13.2. Informative References . . . . . . . . . . . . . . . . . 26 14.1. Normative References . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 14.2. Informative References . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
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 (IKE) described in [RFC7296]
skipping to change at page 6, line 33 skipping to change at page 6, line 37
Puzzles have their place as part of #4. Puzzles have their place as part of #4.
3. Puzzles 3. 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].
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, then no half-open SAs are allowed o The Responder is so overloaded that no half-open SAs may be
to be created without the 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 5 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:
skipping to change at page 7, line 20 skipping to change at page 7, line 24
create a puzzle that is too easy to solve for it to make any create a puzzle that is too easy to solve for it to make any
difference in mitigating DDoS attacks. Since the mechanism is difference in mitigating DDoS attacks. Since the mechanism is
supposed to be stateless for the Responder, either the same ZBC supposed to be stateless for the Responder, either the same ZBC
is used for all Initiators, or the ZBC is somehow encoded in the is used for all Initiators, or the ZBC is somehow encoded in the
cookie. If it is global then it means that this value is the cookie. If it is global then it means that this value is the
same for all the Initiators who are receiving puzzles at any same for all the Initiators who are receiving puzzles at any
given point of time. The Responder, however, may change this given point of time. The Responder, however, may change this
value over time depending on its load. value over time depending on its load.
Upon receiving this challenge, the Initiator attempts to calculate Upon receiving this challenge, the Initiator attempts to calculate
the PRF using different keys. When a key is found such that the the PRF using different keys. When enough keys are found such that
resulting PRF output has a sufficient number of trailing zero bits, the resulting PRF output calculated using each of them has a
that result is sent to the Responder. sufficient number of trailing zero bits, that result is sent to the
Responder.
The reason for using several keys in the results rather than just one
key is to reduce the variance in the time it takes the initiator to
solve the puzzle. We have chosen the number of keys to be four (4)
as a compromise between the conflicting goals of reducing variance
and reducing the work the Responder needs to perform to verify the
puzzle solution.
When receiving a request with a solved puzzle, the Responder verifies When receiving a request with a solved puzzle, the Responder verifies
two things: two things:
o That the cookie part is indeed valid. o That the cookie part is indeed valid.
o That the PRF of the transmitted cookie calculated with the o That the PRFs of the transmitted cookie calculated with the
transmitted key has a sufficient number of trailing zero bits. transmitted keys has a sufficient number of trailing zero bits.
Example 1: Suppose the calculated cookie is Example 1: Suppose the calculated cookie is
fdbcfa5a430d7201282358a2a034de0013cfe2ae (20 octets), the algorithm 739ae7492d8a810cf5e8dc0f9626c9dda773c5a3 (20 octets), the algorithm
is HMAC-SHA256, and the required number of zero bits is 18. After is PRF-HMAC-SHA256, and the required number of zero bits is 18.
successively trying a bunch of keys, the Initiator finds that the key After successively trying a bunch of keys, the Initiator finds the
that is all-zero except for the last three bytes which are 02fc95 following four 3-octet keys that work:
yields HMAC_SHA256(k, cookie) =
843ab73f35c5b431b1d8f80bedcd1cb9ef46832f799c1d4250a49f683c580000,
which has 19 trailing zero bits, so it is an acceptable solution.
Example 2: Same cookie, but this time the required number of zero +--------+----------------------------------+----------+
bits is 22. The first key to satisfy that requirement ends in | Key | Last 32 Hex PRF Digits | # 0-bits |
960cbb, which yields a hash with 23 trailing zero bits. Finding this +--------+----------------------------------+----------+
requires 9,833,659 invocations of the PRF. | 061840 | e4f957b859d7fb1343b7b94a816c0000 | 18 |
| 073324 | 0d4233d6278c96e3369227a075800000 | 23 |
| 0c8a2a | 952a35d39d5ba06709da43af40700000 | 20 |
| 0d94c8 | 5a0452b21571e401a3d00803679c0000 | 18 |
+--------+----------------------------------+----------+
+----------+--------------------------+--------+--------------------+ Table 1: Three solutions for 18-bit puzzle
| Key | Last 24 Hex PRF Digits | # | Time to Calculate |
| | | 0-bits | (seconds) |
+----------+--------------------------+--------+--------------------+
| 00 | 0cbbbd1e105f5a177f9697d4 | 2 | 0.000 |
| 08 | 34cdedf89560f600aab93c68 | 3 | 0.000 |
| 0b | 6153a5131b879a904cd7fbe0 | 5 | 0.000 |
| 2b | 0098af3e9422aa40a6f7b140 | 6 | 0.000 |
| 0147 | c8bf4a65fc8b974046b97c00 | 10 | 0.001 |
| 06e2 | 541487a10cbdf3b21c382800 | 11 | 0.005 |
| 0828 | 48719bd62393fcf9bc172000 | 13 | 0.006 |
| 0204a7 | 3dce3414477c2364d5198000 | 15 | 0.186 |
| 185297 | c19385bb7b9566e5fdf00000 | 20 | 2.146 |
| 69dc34 | 1b61ecb347cb2e0cba200000 | 21 | 9.416 |
| 960cbb | e48274bfac2b7e1930800000 | 23 | 13.300 |
| 01597972 | 39a0141d0fe4b87aea000000 | 25 | 30.749 |
| 0b13cd9a | 00b97bb323d6d33350000000 | 28 | 247.914 |
| 37dc96e4 | 1e24babc92234aa3a0000000 | 29 | 1237.170 |
| 7a1a56d8 | c98f0061e380a49e00000000 | 33 | 2726.150 |
+----------+--------------------------+--------+--------------------+
Table 1: The time needed to solve a puzzle of various difficulty for Example 2: Same cookie, but modify the required number of zero bits
the cookie = fdbcfa5a430d7201282358a2a034de0013cfe2ae to 22. The first 4-octet keys that work to satisfy that requirement
are 005d9e57, 010d8959, 0110778d, and 01187e37. Finding these
requires 18,382,392 invocations of the PRF.
+----------+-------------------------------+
| # 0-bits | Time to Find 4 keys (seconds) |
+----------+-------------------------------+
| 8 | 0.0025 |
| 10 | 0.0078 |
| 12 | 0.0530 |
| 14 | 0.2521 |
| 16 | 0.8504 |
| 17 | 1.5938 |
| 18 | 3.3842 |
| 19 | 3.8592 |
| 20 | 10.8876 |
+----------+-------------------------------+
Table 2: The time needed to solve a puzzle of various difficulty for
the cookie = 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 20 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, with 24 bits 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 4. Retention Periods for Half-Open SAs
As a UDP-based protocol, IKEv2 has to deal with packet loss through As a UDP-based protocol, IKEv2 has to deal with packet loss through
retransmissions. Section 2.4 of [RFC7296] recommends "that messages retransmissions. Section 2.4 of [RFC7296] recommends "that messages
be retransmitted at least a dozen times over a period of at least be retransmitted at least a dozen times over a period of at least
several minutes before giving up". Retransmission policies in several minutes before giving up". Retransmission policies in
practice wait at least one or two seconds before retransmitting for practice wait at least one or two seconds before retransmitting for
the first time. the first time.
skipping to change at page 9, line 51 skipping to change at page 10, line 12
1. Hard Limit - where the number of half-open SAs is capped, and any 1. Hard Limit - where the number of half-open SAs is capped, and any
further IKE_SA_INIT requests are rejected. further IKE_SA_INIT requests are rejected.
2. Soft Limit - where if a set number of half-open SAs exist for a 2. Soft Limit - where if a set number of half-open SAs exist for a
particular address or prefix, any IKE_SA_INIT request will particular address or prefix, any IKE_SA_INIT request will
require solving a puzzle. require solving a puzzle.
The advantage of the hard limit method is that it provides a hard cap The advantage of the hard limit method is that it provides a hard cap
on the amount of half-open SAs that the attacker is able to create. on the amount of half-open SAs that the attacker is able to create.
The downside is that it allows the attacker to block IKE initiation The downside is that it allows the attacker to block IKE initiation
from small parts of the Internet. For example, if a certain purveyor from small parts of the Internet. For example, if an network service
of beverages resembling coffee provides Internet connectivity to its provider or some establishment offers Internet connectivity to its
customers through an IPv4 NAT device, a single malicious customer can customers or employees through an IPv4 NAT device, a single malicious
create enough half-open SAs to fill the quota for the NAT device customer can create enough half-open SAs to fill the quota for the
external IP address. Legitimate Initiators on the same network will NAT device external IP address. Legitimate Initiators on the same
not be able to initiate IKE. network will not be able to initiate IKE.
The advantage of a soft limit is that legitimate clients can always The advantage of a soft limit is that legitimate clients can always
connect. The disadvantage is that an adversary with sufficient CPU connect. The disadvantage is that an adversary with sufficient CPU
resources can still effectively DoS the Responder. resources can still effectively DoS the Responder.
Regardless of the type of rate-limiting used, there is a huge Regardless of the type of rate-limiting used, there is a huge
advantage in blocking the DoS attack using rate-limiting in that advantage in blocking the DoS attack using rate-limiting for
legitimate clients who are away from the attacking nodes should not legitimate clients that are away from the attacking nodes. In such
be adversely affected by either the attack or by the measures used to cases, adverse impacts caused by the attack or by the measures used
counteract it. to counteract the attack can be avoided.
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 13, line 48 skipping to change at page 14, line 7
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 puzzle, as it can afford. In this case no specific value of solve puzzle, as it can afford. In this case no specific value of
ZBC is required from the Initiator, however the larger the ZBC that ZBC is required from the Initiator, however the larger the ZBC that
Initiator is able to get, the better the chances it will have to be Initiator is able to get, the better the chances it will have to be
served by the Responder. In diverse environments it is RECOMMENDED served by the Responder. In diverse environments it is RECOMMENDED
that the Initiator sets difficulty level to 0, unless the attack that the Initiator sets difficulty level to 0, unless the attack
volume is very high. volume is very high.
If the Responder sets non-zero difficulty level, then the level If the Responder sets 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 requested 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 Puzzle Algorithm 7.1.1.2. Selecting Puzzle Algorithm
The PUZZLE notification also contains identifier of the algorithm, The PUZZLE notification also contains identifier of the algorithm,
that must be used by Initiator to compute puzzle. that must be 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]). This feature ensures that protocol for modern protocols ([RFC7696]). This feature ensures that protocol
doesn't rely on a single build-in set of cryptographic algorithms, doesn't rely on a single build-in set of cryptographic algorithms,
but has a means to replace one set with another and negotiate new set but has a means to replace one set with another and negotiate new set
with the peer. IKEv2 fully supports cryptographic algorithm agility with the peer. IKEv2 fully supports cryptographic algorithm agility
for its core operations. for its core operations.
To support this feature in case of puzzles the algorithm, that is To support this feature in case of puzzles, the algorithm that is
used to compute puzzle, needs to be negotiated during IKE_SA_INIT used to compute puzzle needs to be negotiated during IKE_SA_INIT
exchange. The negotiation is done as follows. The initial request exchange. The negotiation is performed as follows. The initial
message sent by Initiator contains SA payload with the list of request message sent by Initiator contains SA payload with the list
transforms the Initiator supports and is willing to use in the IKE SA of transforms the Initiator supports and is willing to use in the IKE
being established. The Responder parses received SA payload and SA being established. The Responder parses received SA payload and
finds mutually supported set of transforms of type PRF. It selects finds mutually supported set of transforms of type PRF. It selects
most preferred transform from this set and includes it into the most preferred transform from this set and includes it into the
PUZZLE notification. There is no requirement that the PRF selected PUZZLE notification. There is no requirement that the PRF selected
for puzzles be the same, as the PRF that is negotiated later for the for puzzles be the same, as the PRF that is negotiated later for the
use in core IKE SA crypto operations. If there are no mutually use in core IKE SA crypto operations. If there are no mutually
supported PRFs, then negotiation will fail anyway and there is no supported PRFs, then negotiation will fail anyway and there is no
reason to return a puzzle. In this case the Responder returns reason to return a puzzle. In this case the Responder returns
NO_PROPOSAL_CHOSEN notification. Note that PRF is a mandatory NO_PROPOSAL_CHOSEN notification. Note that PRF is a mandatory
transform type for IKE SA (see Sections 3.3.2 and 3.3.3 of [RFC7296]) transform type for IKE SA (see Sections 3.3.2 and 3.3.3 of [RFC7296])
and at least one transform of this type must always be present in SA and at least one transform of this type must always be present in SA
payload in IKE_SA_INIT exchange. payload in IKE_SA_INIT request message.
7.1.1.3. Generating Cookie 7.1.1.3. Generating Cookie
If Responder supports puzzles then cookie should be computed in such If Responder supports puzzles then cookie should be computed in such
a manner, that the Responder is able to learn some important 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
skipping to change at page 15, line 23 skipping to change at page 15, line 28
this information in returned cookie is detectable. So, the cookie this information in returned cookie is detectable. So, the cookie
would be generated as: would be generated as:
Cookie = <VersionIDofSecret> | <AdditionalInfo> | Cookie = <VersionIDofSecret> | <AdditionalInfo> |
Hash(Ni | IPi | SPIi | <AdditionalInfo> | <secret>) Hash(Ni | IPi | SPIi | <AdditionalInfo> | <secret>)
Alternatively, the Responder may continue to generate cookie as Alternatively, the Responder may continue to generate cookie as
suggested in Section 2.6 of [RFC7296], but associate the additional suggested in Section 2.6 of [RFC7296], but associate the additional
information, that would be stored locally, with the particular information, that would be stored locally, with the particular
version of the secret. In this case the Responder should have version of the secret. In this case the Responder should have
different secret for every combination of difficulty level and number different secrets for every combination of difficulty level and
of consecutive puzzles, and should change the secrets periodically, number of consecutive puzzles, and should change the secrets
keeping a few previous versions, to be able to calculate how long ago periodically, keeping a few previous versions, to be able to
the cookie was generated. calculate how long ago the cookie was 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 the doesn't mandate how the Responder learns this information from the
cookie. cookie.
7.1.2. Solving Puzzle and Returning the Solution 7.1.2. Solving 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
skipping to change at page 16, line 18 skipping to change at page 16, line 23
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 9.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 3. They can be summarized as follows: given unpredictable
string S and pseudo-random function PRF find the key K for that PRF string S and pseudo-random function PRF find N different keys Ki
so that the result of PRF(K,S) has the specified number of trailing (where i=[1..N]) for that PRF so that the result of PRF(Ki,S) has at
zero bits. least the specified number of trailing zero bits. This specification
requires that the solution to the puzzle contains 4 different keys
(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 key K for the agreed upon PRF such the IKE Initiator is to find the four different, equal-sized keys Ki
that the result of PRF(K,cookie) has sufficient number of trailing for the agreed upon PRF such that each result of PRF(Ki,cookie) where
zero bits. Only the content of the COOKIE notification is used in i = [1..4] has a sufficient number of trailing zero bits. Only the
puzzle calculation, i.e. the header of the Notification payload is content of the COOKIE notification is used in puzzle calculation,
not included. i.e. the header of the Notification 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
that 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 it must be processed according
to Section 7.1. First, the cookie MUST be checked for validity. If to Section 7.1. First, the cookie MUST be checked for validity. If
the cookie is invalid, then the request is treated as initial and is the cookie is invalid, then the request is treated as initial and is
processed according to Section 7.1. If the cookie is valid then some processed according to Section 7.1. It is RECOMMENDED that a new
important information is learned from it or from local state based on cookie is requested in this case.
identifier of the cookie's secret (see Section 7.1.1.3 for details).
This information helps the Responder to sort out incoming requests, If the cookie is valid then some important information is learned
giving more priority to those of them, which were created by spending from it or from local state based on identifier of the cookie's
more of the Initiator's resources. secret (see Section 7.1.1.3 for details). This information helps the
Responder to sort out incoming requests, giving more priority to
those of them, which were created by spending more of the Initiator's
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, then it presented a puzzle to the Initiator. If no puzzle was given, then it
means that at the time the Responder requested a cookie it didn't means that at the time the Responder requested a cookie it didn't
detect the (D)DoS attack or the attack volume was low. In this case detect the (D)DoS attack or the attack volume was low. In this case
the received request message must not contain the PS payload, and the received request message must not contain the PS payload, and
this payload MUST be ignored if for any reason the message contains this payload MUST be ignored if for any reason the message contains
it. Since no puzzle was given, the Responder marks the request with it. Since no puzzle was given, the Responder marks the request with
the lowest priority since the Initiator spent little resources the lowest priority since the Initiator spent little resources
creating it. creating it.
If the Responder learns from the cookie that the puzzle was given to If the Responder learns from the cookie that the puzzle was given to
the Initiator, then it looks for the PS payload to determine whether the Initiator, then it looks for the PS payload to determine whether
its request to solve the puzzle was honored or not. If the incoming its request to solve the puzzle was honored or not. If the incoming
message doesn't contain a PS payload, then it means that the message doesn't contain a PS payload, then it means that the
Initiator either doesn't support puzzles or doesn't want to deal with Initiator either doesn't support puzzles or doesn't want to deal with
them. In either case the request is marked with the lowest priority them. In either case the request is marked with the lowest priority
since the Initiator spent little resources creating it. since the Initiator spent little resources creating it.
If a PS payload is found in the message, then the Responder MUST If a PS payload is found in the message, then the Responder MUST
verify the puzzle solution that it contains. The result must contain verify the puzzle solution that it contains. The solution is
at least the requested number of trailing zero bits (that is also interpreted as four different keys. The result of using each of them
learned from the cookie, as well as the PRF algorithm used in puzzle in the PRF (as described in Section 7.1.3) must contain at least the
solution). If the result of the solution contains fewer bits than requested number of trailing zero bits. The Responder MUST check all
were requested, it means that Initiator spent less resources than the four returned keys.
expected by the Responder. This request is marked with the lowest
priority. If any checked result contains fewer bits than were requested, it
means that the Initiator spent less resources than expected by the
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 requesting zero level) 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 higher zero bits the Initiator got, the higher priority its o The Responder must take the smallest number of trailing zero bits
request should receive. among the checked results and count it as the number of zero bits
the Initiator got.
o The higher number of zero bits the Initiator got, the higher
priority its request should receive.
o The more consecutive puzzles the Initiator solved, the higher o The more consecutive puzzles the Initiator solved, the higher
priority it should receive. priority it should receive.
o The more time the Initiator spent solving the puzzles, the higher o The more time the Initiator spent solving the puzzles, the higher
priority it should receive. priority it should receive.
After the priority of the request is determined the final decision After the priority of the request is determined the final decision
whether to serve it or not is made. whether to serve it or not is made.
skipping to change at page 18, line 7 skipping to change at page 18, line 26
The Responder decides what to do with the request based on its The Responder decides what to do with the request based on its
priority and Responder's current load. There are three possible priority and Responder's current load. There are three possible
actions: actions:
o Accept request. o Accept request.
o Reject request. o Reject request.
o Demand more work from Initiator by giving it a new puzzle. o Demand more work from Initiator by giving it a new puzzle.
The Responder SHOULD accept incoming request if its priority is high The Responder SHOULD accept an incoming request if its priority is
- it means that the Initiator spent quite a lot of resources. The high - it means that the Initiator spent quite a lot of resources.
Responder MAY also accept some of low-priority requests where the The Responder MAY also accept some of low-priority requests where the
Initiators don't support puzzles. The percentage of accepted legacy Initiators don't support puzzles. The percentage of accepted legacy
requests depends on the Responder's current load. requests depends on the Responder's current load.
If Initiator solved the puzzle, but didn't spend much resources for If the Initiator solved the puzzle, but didn't spend much resources
it (the selected puzzle difficulty level appeared to be low and the for it (the selected puzzle difficulty level appeared to be low and
Initiator solved it quickly), then the Responder SHOULD give it the Initiator solved it quickly), then the Responder SHOULD give it
another puzzle. The more puzzles the Initiator solves the higher its another puzzle. The more puzzles the Initiator solves the higher its
chances are to be served. chances are to be served.
The details of how the Responder makes decision on any particular The details of how the Responder makes a decision for any particular
request, are implementation dependent. The Responder can collect all request, are implementation dependent. The Responder can collect all
the incoming requests for some short period of time, sort them out the incoming requests for some short period of time, sort them out
based on their priority, calculate the number of available memory based on their priority, calculate the number of available memory
slots for half-open IKE SAs and then serve that number of requests slots for half-open IKE SAs and then serve that number of requests
from the head of the sorted list. The rest of requests can be either from the head of the sorted list. The rest of requests can be either
discarded or responded to with new puzzles. discarded or responded to with new puzzles.
Alternatively, the Responder may decide whether to accept every Alternatively, the Responder may decide whether to accept every
incoming request with some kind of lottery, taking into account its incoming request with some kind of lottery, taking into account its
priority and the available resources. priority and the available resources.
7.2. Puzzles in 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 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 2. 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
skipping to change at page 19, line 31 skipping to change at page 20, line 7
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 the Responder MUST NOT use puzzles in the IKE_AUTH exchange unless the
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+]
7.2.1.1. Selecting Puzzle Difficulty Level 7.2.1.1. Selecting Puzzle Difficulty Level
The difficulty level of the puzzle in IKE_AUTH should be chosen so The difficulty level of the puzzle in IKE_AUTH exchange should be
that the Initiator would spend more time to solve the puzzle than the chosen so that the Initiator would spend more time to solve the
Responder to compute the D-H shared secret and the keys, needed to puzzle than the Responder to compute the D-H shared secret and the
decrypt and verify the IKE_AUTH request message. On the other hand, keys, needed to decrypt and verify the IKE_AUTH request message. On
the difficulty level should not be too high, otherwise the legitimate the other hand, the difficulty level should not be too high,
clients would experience an additional delay while establishing IKE otherwise the legitimate clients would experience an additional delay
SA. while establishing 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 computing power of the Responder would be able to estimate the computational power of the
Initiator and to select the difficulty level accordingly. Unlike Initiator and to select the difficulty level accordingly. Unlike
puzzles in IKE_SA_INIT, the requested difficulty level for IKE_AUTH puzzles in IKE_SA_INIT, the requested difficulty level for IKE_AUTH
puzzles MUST NOT be zero. In other words, the Responder must always puzzles MUST NOT be zero. In other words, the Responder must always
set specific difficulty level and must not let the Initiator to set specific difficulty level and must not let the Initiator to
choose it on its own. choose it on its own.
7.2.1.2. Selecting Puzzle Algorithm 7.2.1.2. Selecting 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
skipping to change at page 20, line 44 skipping to change at page 21, line 14
Initiator has to solve the puzzle only once and the solution is valid Initiator has to solve the puzzle only once and the solution is valid
for both unfragmented and fragmented IKE messages. for both unfragmented and fragmented IKE messages.
7.2.3. Computing Puzzle 7.2.3. Computing Puzzle
The puzzles in the IKE_AUTH exchange are computed differently than in The puzzles in the IKE_AUTH exchange are computed differently than in
the IKE_SA_INIT exchange (see Section 7.1.3). The general principle the IKE_SA_INIT exchange (see Section 7.1.3). The general principle
is the same; the difference is in the construction of the string S. is the same; the difference is in the construction of the string S.
Unlike the IKE_SA_INIT exchange, where S is the cookie, in the Unlike the IKE_SA_INIT exchange, where S is the cookie, in the
IKE_AUTH exchange S is a concatenation of Nr and SPIr. In other IKE_AUTH exchange S is a concatenation of Nr and SPIr. In other
words, the task for IKE Initiator is to find the key K for the agreed words, the task for IKE Initiator is to find the four different keys
upon PRF such that the result of PRF(K,Nr | SPIr) has a sufficient Ki for the agreed upon PRF such that each result of PRF(Ki,Nr | SPIr)
number of trailing zero bits. Nr is a nonce used by the Responder in where i=[1..4] has a sufficient number of trailing zero bits. Nr is
IKE_SA_INIT exchange, stripped of any headers. SPIr is IKE Responder a nonce used by the Responder in IKE_SA_INIT exchange, stripped of
SPI in the SA being established. any headers. SPIr is IKE Responder's SPI from the IKE header of the
SA being established.
7.2.4. Receiving Puzzle Solution 7.2.4. Receiving 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 silently discard the received message SK_* keys. The Responder MUST verify all the four returned keys.
if the puzzle solution is not correct (has insufficient number of
trailing zero bits). If the Responder successfully verifies the The Responder MUST silently discard the received message if any
puzzle and calculates the SK_* key, but the message authenticity checked verification result is not correct (contains insufficient
check fails, then it SHOULD save the calculated keys in the IKE SA number of trailing zero bits). If the Responder successfully
state while waiting for the retransmissions from the Initiator. In verifies the puzzle and calculates the SK_* key, but the message
this case the Responder may skip verification of the puzzle solution authenticity check fails, then it SHOULD save the calculated keys in
and ignore the Puzzle Solution payload in the retransmitted messages. the IKE SA state while waiting for the retransmissions from the
Initiator. In this case the Responder may skip verification of the
puzzle solution and ignore the Puzzle Solution payload in the
retransmitted messages.
If the Initiator uses IKE Fragmentation, then it is possible, that If the Initiator uses IKE Fragmentation, then it is possible, that
due to packet loss and/or reordering the Responder could receive non- due to packet loss and/or reordering the Responder could receive non-
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
skipping to change at page 23, line 20 skipping to change at page 23, line 38
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Protocol ID(=0)| SPI Size (=0) | Notify Message Type | |Protocol ID(=0)| SPI Size (=0) | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PRF | Difficulty | | PRF | Difficulty |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Protocol ID (1 octet) - MUST be 0. o Protocol ID (1 octet) -- MUST be 0.
o SPI Size (1 octet) - MUST be 0, meaning no Security Parameter o SPI Size (1 octet) - MUST be 0, meaning no 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
minimum number of trailing zero bit, that the result of PRF must minimum number of trailing zero bits (ZBC), that each of the
contain. Value 0 means that the Responder doesn't request any results of PRF must contain. Value 0 means that the Responder
specific difficulty level and the Initiator is free to select doesn't request any specific difficulty level and the Initiator is
appropriate difficulty level of its own (see Section 7.1.1.1 for free to select appropriate difficulty level on its own (see
details). Section 7.1.1.1 for details).
This notification contains no data. This notification contains no data.
9.2. Puzzle Solution Payload 9.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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Puzzle Solution Data ~ ~ Puzzle Solution Data ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Puzzle Solution Data (variable length) - Contains the solution to o Puzzle Solution Data (variable length) -- Contains the solution to
the puzzle - i.e. the key for the PRF. This field MUST NOT be the puzzle - four different keys for the selected PRF. This field
empty. If the selected PRF has a fixed-size key, then the size of MUST NOT be empty. All the keys MUST have the same size,
the Puzzle Solution Data MUST be equal to the size of the key. If therefore the size of this field is always a mutiple of 4 bytes.
the PRF agreed upon accepts keys of any size, then then the size If the selected PRF accepts only fixed-size keys, then the size of
of the Puzzle Solution Data MUST be between 1 octet and the each key MUST be of that fixed size. If the PRF agreed upon
preferred key length of the PRF (inclusive). accepts keys of any size, then then the size of each key MUST be
between 1 octet and the preferred key length of the PRF
(inclusive). It is expected that in most cases the keys will be 4
(or even less) octets in length, however it depends on puzzle
difficulty and on the Initiator's strategy to find solutions, and
thus the size is not mandated by this specification. The
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
size of Puzzle Solution Data is the size of Payload (as indicated
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 10. 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
skipping to change at page 25, line 41 skipping to change at page 26, line 17
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. References 13. Acknowledgements
13.1. Normative References The authors thank Tero Kivinen, Yaron Sheffer and Scott Fluhrer for
their contribution into design of the protocol. In particular, Tero
Kivinen suggested the kind of puzzle where the task is to find a
solution with requested number of zero trailing bits. Yaron Sheffer
and Scott Fluhrer suggested a way to make puzzle difficulty less
erratic by solving several weaker puzles. The authors also thank
David Waltermire for his carefull review of the draft and all others
who commented the document.
14. References
14.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>.
13.2. Informative References 14.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. 47 change blocks. 
160 lines changed or deleted 205 lines changed or added

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