< draft-ietf-ipsecme-ddos-protection-00.txt   draft-ietf-ipsecme-ddos-protection-01.txt >
IPSecME Working Group Y. Nir IPSecME Working Group Y. Nir
Internet-Draft Check Point Internet-Draft Check Point
Intended status: Standards Track October 27, 2014 Intended status: Standards Track V. Smyslov
Expires: April 30, 2015 Expires: September 9, 2015 ELVIS-PLUS
March 8, 2015
Protecting Internet Key Exchange (IKE) Implementations from Distributed Protecting Internet Key Exchange (IKE) Implementations from Distributed
Denial of Service Attacks Denial of Service Attacks
draft-ietf-ipsecme-ddos-protection-00 draft-ietf-ipsecme-ddos-protection-01
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-connected IPsec Responders, to allow them to
resist Denial of Service and Distributed Denial of Service attacks. resist Denial of Service and Distributed Denial of Service attacks.
Additionally, the document introduces a new mechanism called "Client Additionally, the document introduces a new mechanism called "Client
Puzzles" that help accomplish this task. Puzzles" that help accomplish this task.
Status of This Memo Status of This Memo
skipping to change at page 1, line 35 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 April 30, 2015. This Internet-Draft will expire on September 9, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions Used in This Document . . . . . . . . . . . . 3 1.1. Conventions Used in This Document . . . . . . . . . . . . 3
2. The Vulnerability . . . . . . . . . . . . . . . . . . . . . . 3 2. The Vulnerability . . . . . . . . . . . . . . . . . . . . . . 3
3. Puzzles . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Puzzles . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Retention Periods for Half-Open SAs . . . . . . . . . . . . . 7 3.1. The Keyed-Cookie Notification . . . . . . . . . . . . . . 8
3.2. The Puzzle-Required Notification . . . . . . . . . . . . 8
4. Retention Periods for Half-Open SAs . . . . . . . . . . . . . 8
5. Rate Limiting . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Rate Limiting . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Plan for Defending a Responder . . . . . . . . . . . . . . . 9 6. Plan for Defending a Responder . . . . . . . . . . . . . . . 9
7. Operational Considerations . . . . . . . . . . . . . . . . . 11 6.1. Session Resumption . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Operational Considerations . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. Using Puzzles in the Protocol . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Puzzles in IKE_SA_INIT Exchange . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . 11 8.1.1. Presenting Puzzle . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . 12 8.1.2. Solving Puzzle and Returning the Solution . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 8.1.3. Analyzing Repeated Request . . . . . . . . . . . . . 16
8.1.4. Making Decision whether to Serve the Request . . . . 17
8.2. Puzzles in IKE_AUTH Exchange . . . . . . . . . . . . . . 18
8.2.1. Presenting Puzzle . . . . . . . . . . . . . . . . . . 19
8.2.2. Solving Puzzle and Returning the Solution . . . . . . 20
8.2.3. Receiving Puzzle Solution . . . . . . . . . . . . . . 20
9. DoS Protection after IKE SA is created . . . . . . . . . . . 21
10. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 22
10.1. PUZZLE Notification . . . . . . . . . . . . . . . . . . 22
10.2. Puzzle Solution Payload . . . . . . . . . . . . . . . . 23
11. Security Considerations . . . . . . . . . . . . . . . . . . . 24
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
13.1. Normative References . . . . . . . . . . . . . . . . . . 24
13.2. Informative References . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
The IKE_SA_INIT Exchange described in section 1.2 of [RFC7296] The IKE_SA_INIT Exchange described in section 1.2 of [RFC7296]
involves the Initiator sending a single message. The Responder involves the Initiator sending a single message. The Responder
replies with a single message and also allocates memory for a replies with a single message and also allocates memory for a
structure called a half-open IKE SA (Security Association). This structure called a half-open IKE SA (Security Association). This
half-open SA is later authenticated in the IKE_AUTH Exchange, but if half-open SA is later authenticated in the IKE_AUTH Exchange, but if
that IKE_AUTH request never comes, the half-open SA is kept for an that IKE_AUTH request never comes, the half-open SA is kept for an
unspecified amount of time. Depending on the algorithms used and unspecified amount of time. Depending on the algorithms used and
skipping to change at page 5, line 44 skipping to change at page 6, line 19
The puzzle introduced here extends the cookie mechanism from RFC The puzzle introduced here extends the cookie mechanism from RFC
7296. It is loosely based on the proof-of-work technique used in 7296. It is loosely based on the proof-of-work technique used in
BitCoins ([bitcoins]). Future versions of this document will have BitCoins ([bitcoins]). Future versions of this document will have
the exact bit structure of the notification payloads, but for now, I the exact bit structure of the notification payloads, but for now, I
will only describe the semantics of the content. will only describe the semantics of the content.
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, than no half-open SAs are allowed o The Responder is so overloaded, than no half-open SAs are allowed
to be created without the puzzle, or to be created without the puzzle, or
o The Responder is not too loaded, but the rate-limiting in o The Responder is not too loaded, but the rate-limiting in
Section 5 prevents half-open SAs from being created with this Section 5 prevents half-open SAs from being created with this
particular peer address or prefix without first solving a puzzle. particular peer address or prefix without first solving 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 two response to a IKE_SA_INIT request, the notification includes three
fields: fields:
1. Cookie - this is calculated the same as in RFC 7296. As in RFC 1. Cookie - this is calculated the same as in RFC 7296. As in RFC
7296, the process of generating the cookie is not specified, but 7296, the process of generating the cookie is not specified.
this specification does assume that it is fixed-length, meaning
that all cookies produced by a particular responder are of the 2. Algorithm, this is the identifier of a PRF algorithm, one of
same length. those proposed by the Initiator in the SA payload.
2. Zero Bit Count. This is a number between 8 and 255 that
3. Zero Bit Count. This is a number between 8 and 255 that
represents the length of the zero-bit run at the end of the represents the length of the zero-bit run at the end of the
SHA-256 hash of the Cookie payload that the Initiator is to send. output of the PRF function calculated over the Keyed-Cookie
Since the mechanism is supposed to be stateless for the payload that the Initiator is to send. Since the mechanism is
Responder, the same value is sent to all Initiators who are supposed to be stateless for the Responder, the same value is
receiving this challenge. The values 0 and 1-8 are explicitly sent to all Initiators who are receiving this challenge. The
excluded, because the value zero is meaningless, and the values values 0 and 1-8 are explicitly excluded, because the value zero
1-8 create a puzzle that is too easy to solve to make any is meaningless, and the values 1-8 create a puzzle that is too
difference in mitigating DDoS attacks. easy to solve for it to make any difference in mitigating DDoS
attacks.
Upon receiving this challenge payload, the Initiator attempts to Upon receiving this challenge payload, the Initiator attempts to
append different strings to the Cookie field from the challenge, and calculate the PRF using different keys. When a key is found such
calculates the SHA-256 hash of the result. When a string is found that the resulting PRF output has a sufficient number of trailing
such that the resulting hash has a sufficient number of trailing zero zero bits, that result is sent to the Responder in a Keyed-Cookie
bits, that result is sent to the Responder in a Cookie notification, notification, as described in Section 3.1.
similar to what is described in RFC 7296. The difference is that the
string in this Cookie notification is longer than the one
transmitted.
When receiving a request with an extended Cookie, the Responder When receiving a request with a Keyed-Cookie, the Responder verifies
verifies two things: two things:
o That the first bits of the transmitted cookie are indeed valid. o That the cookie part is indeed valid.
o That the hash of the transmitted cookie has a sufficient number of
trailing zero bits. o That the PRF of the transmitted cookie calculated with the
transmitted key 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) and the required fdbcfa5a430d7201282358a2a034de0013cfe2ae (20 octets), the algorithm
number of zero bits is 16. After successively trying a bunch of is HMAC-SHA256, and the required number of zero bits is 18. After
strings, the Initiator finds out that appending three octets: 022b3d successively trying a bunch of keys, the Initiator finds that the key
yields a 23-octet string whose SHA-256 hash is that is all-zero except for the last three bytes which are 02fc95
3b4bdf201105e059e09f65219021738b8f6a148896b2e1be2fdc726aeb6e0000. yields HMAC_SHA256(k, cookie) =
That has 17 trailing zero bits, so it is an acceptable 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 Example 2: Same cookie, but this time the required number of zero
bits is 22. The first string to satisfy that requirement is 5c2880, bits is 22. The first key to satisfy that requirement ends in
which yields a hash with 23 trailing zero bits. Finding this 960cbb, which yields a hash with 23 trailing zero bits. Finding this
requires 6,105,472 hashes. requires 9,833,659 invocations of the PRF.
+--------------+--------------------------+---------+---------------+ +----------+--------------------------+----------+------------------+
| Appended | Last 24 Hex Hash Digits | # | Time To | | key | Last 24 Hex PRF Digits | # 0-bits | Time To |
| String | | 0-bits | Calculate | | | | | Calculate |
+--------------+--------------------------+---------+---------------+ +----------+--------------------------+----------+------------------+
| 04 | 2817ae10f20f4e0b0739f5cc | 2 | 0.000 | | 00 | 0cbbbd1e105f5a177f9697d4 | 2 | 0.000 |
| 06 | e540cf315fff88c1c5f362a8 | 3 | 0.000 | | 08 | 34cdedf89560f600aab93c68 | 3 | 0.000 |
| 0d | 8c459376268f747d7ed40da0 | 5 | 0.000 | | 0b | 6153a5131b879a904cd7fbe0 | 5 | 0.000 |
| 1c | 398c49be1babe50576cdae40 | 6 | 0.000 | | 2b | 0098af3e9422aa40a6f7b140 | 6 | 0.000 |
| 00f0 | 3f523ad7c0e00252c51ad980 | 7 | 0.000 | | 0147 | c8bf4a65fc8b974046b97c00 | 10 | 0.001 |
| 0182 | e284296e2ffffa256bdfa800 | 11 | 0.000 | | 06e2 | 541487a10cbdf3b21c382800 | 11 | 0.005 |
| 235c | 7dc74302dc8bd695821ab000 | 12 | 0.006 | | 0828 | 48719bd62393fcf9bc172000 | 13 | 0.006 |
| 7186 | a4411c3df3661eff1d574000 | 14 | 0.019 | | 0204a7 | 3dce3414477c2364d5198000 | 15 | 0.186 |
| d836 | 498bcd04ab1ae0c2c3a08000 | 15 | 0.036 | | 185297 | c19385bb7b9566e5fdf00000 | 20 | 2.146 |
| 022b3d | 96b2e1be2fdc726aeb6e0000 | 17 | 0.136 | | 69dc34 | 1b61ecb347cb2e0cba200000 | 21 | 9.416 |
| 0aa679 | 620f48af85428996c1f00000 | 20 | 0.512 | | 960cbb | e48274bfac2b7e1930800000 | 23 | 13.300 |
| 4ffbad | f9ba0ece854cd0fa88e00000 | 21 | 3.602 | | 01597972 | 39a0141d0fe4b87aea000000 | 25 | 30.749 |
| 5c2880 | d44e6467d8fc37723d800000 | 23 | 4.143 | | 0b13cd9a | 00b97bb323d6d33350000000 | 28 | 247.914 |
| cdafe1 | 0d4058660c3e67be62000000 | 25 | 9.245 | | 37dc96e4 | 1e24babc92234aa3a0000000 | 29 | 1237.170 |
| 022bffc8 | 5f2d874764a71e2948000000 | 27 | 36.169 | | 7a1a56d8 | c98f0061e380a49e00000000 | 33 | 2726.150 |
| 181ac92a | c3b5449fa1019b0580000000 | 31 | 255.076 | +----------+--------------------------+----------+------------------+
| a987978d | 95a5673968a9b37a00000000 | 33 | 1309.519 |
+--------------+--------------------------+---------+---------------+
Table 1: COOKIE=fdbcfa5a430d7201282358a2a034de0013cfe2ae Table 1: COOKIE=fdbcfa5a430d7201282358a2a034de0013cfe2ae
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 I believe that 20 bits is a reasonable well. With these figures I believe that 20 bits is a reasonable
choice for puzzle level difficulty for all Initiators, with 24 bits choice for puzzle level difficulty for all Initiators, with 24 bits
acceptable for specific hosts/prefixes. acceptable for specific hosts/prefixes.
3.1. The Keyed-Cookie Notification
To be added
3.2. The Puzzle-Required Notification
To be added
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 RFC 7296 recommends "that messages retransmissions. Section 2.4 of RFC 7296 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.
Because of this, setting the timeout on a half-open SA too low will Because of this, setting the timeout on a half-open SA too low will
skipping to change at page 11, line 10 skipping to change at page 11, line 38
If the load on the Responder is still too great, and there are many If the load on the Responder is still too great, and there are many
nodes causing multiple half-open SAs or IKE_AUTH failures, the nodes causing multiple half-open SAs or IKE_AUTH failures, the
Responder MAY impose hard limits on those nodes. Responder MAY impose hard limits on those nodes.
If it turns out that the attack is very widespread and the hard caps If it turns out that the attack is very widespread and the hard caps
are not solving the issue, a puzzle MAY be imposed on all Initiators. are not solving the issue, a puzzle MAY be imposed on all Initiators.
Note that this is the last step, and the Responder should avoid this Note that this is the last step, and the Responder should avoid this
if possible. if possible.
6.1. Session Resumption
When the Responder is under attack, it MAY choose to prefer
previously authenticated peers who present a session resumption
[RFC5723] ticket. The Responder MAY require such Initiators to pass
a return routability check by including the COOKIE notification in
the IKE_SESSION_RESUME response message, as allowed by RFC 5723, Sec.
4.3.2. Note that the Responder SHOULD cache tickets for a short time
to reject reused tickets (Sec. 4.3.1), and therefore there should be
no issue of half-open SAs resulting from replayed IKE_SESSION_RESUME
messages
7. Operational Considerations 7. Operational Considerations
[This section needs a lot of expanding] [This section needs a lot of expanding]
Not all Initiators support the puzzles, but all initiators are Not all Initiators support the puzzles, but all initiators are
supposed to support stateless cookies. If this notification is sent supposed to support stateless cookies. If this notification is sent
to a non-supporting but legitimate initiator, the exchange will fail. to a non-supporting but legitimate initiator, the exchange will fail.
Responders are advised to first try to mitigate the DoS using Responders are advised to first try to mitigate the DoS using
stateless cookies, even imposing them generally before resorting to stateless cookies, even imposing them generally before resorting to
using puzzles. using puzzles.
skipping to change at page 11, line 36 skipping to change at page 12, line 31
core, so setting the difficulty level to n=20 is a good compromise. core, so setting the difficulty level to n=20 is a good compromise.
It should be noted that mobile initiators, especially phones are It should be noted that mobile initiators, especially phones are
considerably weaker than that. Implementations should allow considerably weaker than that. Implementations should allow
administrators to set the difficulty level, and/or be able to set the administrators to set the difficulty level, and/or be able to set the
difficulty level dynamically in response to load. difficulty level dynamically in response to load.
Initiators should set a maximum difficulty level beyond which they Initiators should set a maximum difficulty level beyond which they
won't try to solve the puzzle and log or display a failure message to won't try to solve the puzzle and log or display a failure message to
the administrator or user. the administrator or user.
8. Security Considerations 8. Using Puzzles in the Protocol
8.1. Puzzles in IKE_SA_INIT Exchange
IKE initiator indicates the desire to create new IKE SA by sending
IKE_SA_INIT request message. The message may optionally contain
COOKIE notification if this is a repeated request after the responder
asked initiator to return a cookie.
HDR, [N(COOKIE),] SA, KE, Ni, [V+][N+] -->
According to the plan, described in Section 6, IKE responder should
monitor incoming requests to detect whether it is under attack. If
the responder learns that (D)DoS attack is likely to be in progress,
then it either requests the initiator to return cookie or, if the
volume is so high, that puzzles need to be used for defense, it
requests the initiator to solve the puzzle.
The responder MAY choose to process some fraction of IKE_SA_INIT
requests without presenting a puzzle even being under attack to allow
legacy clients, that don't support puzzles, to have chances be
served. The decision whether to process any particular request must
be probabilistic, with the probability depending on the responder's
load (i.e. on the volume of the attack). Only those requests, that
contain COOKIE notification, must participate in this lottery. In
other words, the responder MUST first perform return routability
check before allowing any legacy client to be served if it is under
attack. See Section 8.1.3 for details.
8.1.1. Presenting Puzzle
If the responder takes a decision to use puzzles, then it includes
two notifications in its response message - the COOKIE notification
and the PUZZLE notification. The format of the PUZZLE notification
is described in Section 10.1.
<-- HDR, N(COOKIE), N(PUZZLE), [V+][N+]
The presence of these notifications in IKE_SA_INIT response message
indicates to the initiator that it should solve the puzzle to get
better chances to be served.
8.1.1.1. Selecting Puzzle Difficulty Level
The PUZZLE notification contains the difficulty level of the puzzle -
the minimum number of trailing zero bits that the result of PRF must
contain. In diverse environments it is next to impossible for the
responder to set any specific difficulty level that will result in
roughly the same amount of work for all initiators, because
computation power of different initiators may vary by the order of
magnitude, or even more. The responder may set difficulty level 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 number of
trailing zero bits is required from the initiator, however the more
bits initiator is able to get, the higher chances it will have to be
served by the responder. In diverse environments it is RECOMMENDED
that the initiator sets difficulty level to 0.
If the responder sets non-zero difficulty level, then the level
should be determined by analyzing the volume of the attack. The
responder MAY set different difficulty levels to different requestd
depending on the IP address the request has come from.
8.1.1.2. Selecting Puzzle Algorithm
The PUZZLE notification also contains identificator of the algorithm,
that must be used by initiator in puzzle solution.
Cryptographic algorithm agility is considered an important feature
for modern protocols ([ALG-AGILITY]). This feature ensures that
protocol 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 with the peer. IKEv2 fully supports cryptographic
algorithm agility for its core operations.
To support this feature in case of puzzles the algorithm, that is
used to compute puzzle, needs to be negotiated during IKE_SA_INIT
exchange. The negotiation is done as follows. The initial request
message sent by initiator contains SA payload with the list of
transforms the initiator supports and is willing to use in the IKE SA
being established. The responder parses received SA payload and
finds mutually supported set of transforms of type PRF. It selects
most preferred transform from this set and includes it into the
PUZZLE notification. There is no requirement that the PRF selected
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
supported PRFs, then negotiation will fail anyway and there is no
reason to return a puzzle. In this case the responder returns
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])
and at least one transform of this type must always be present in SA
payload in IKE_SA_INIT exchange.
8.1.1.3. Generating Cookie
If responder supports puzzles then cookie should be computed in such
a manner, that the responder is able to learn some important
information from the sole cookie, when it is returned back by
initiator. In particular - the responder should be able to learn the
following information:
o Whether the puzzle was given to the initiator or only the cookie
was requested.
o The difficulty level of the puzzle 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
can be calculated if the cookie is timestamped.
This information helps the responder to make a decision whether to
serve this request or demand more work from the initiator.
One possible approach to get this information is to encode it in the
cookie. The format of such encoding is a local matter of responder,
as the cookie would remain an opaque blob to the initiator. If this
information is encoded in the cookie, then the responder MUST make it
integrity protected, so that any intended or accidental alteration of
this information in returned cookie is detectable. So, the cookie
would be generated as:
Cookie = <VersionIDofSecret> | <AdditionalInfo> |
Hash(Ni | IPi | SPIi | <AdditionalInfo> | <secret>)
Alternatively the responder may continue to generate cookie as
suggested in Section 2.6 of [RFC7296], but associate the additional
information, that would be stored locally, with the particular
version of the secret. In this case the responder should have
different secret for every combination of difficulty level and number
of consecutive puzzles, and should change the secrets periodically,
keeping a few previous versions, to be able to calculate how long ago
the cookie was generated.
The responder may also combine these approaches. This document
doesn't mandate how the responder learns this information from the
cookie.
8.1.2. Solving Puzzle and Returning the Solution
If initiator receives puzzle but it doesn't support puzzles, then it
will ignore PUZZLE notification as unrecognized status notification
(in accordance to Section 3.10.1 of [RFC7296]). The initiator also
MAY ignore puzzle if it is not willing to spend resources to solve
puzzle of requested difficulty, even if it supports puzzles. In both
cases the initiator acts as described in Section 2.6 of [RFC7296] -
it restarts the request and includes the received COOKIE notification
into it. The responder should be able to distinguish the situation
when it just requested a cookie from the situation when the puzzle
was given to the initiator, but the initiator for some reason ignored
it.
If the received message contains PUZZLE notification, but doesn't
contain cookie, then this message is malformed, because it requests
to solve the puzzle, but doesn't provide enough information to do it.
In this case the initiator SHOULD resend IKE_SA_INIT request. If
this situation repeats several times, then it means that something is
wrong and IKE SA cannot be established.
If initiator supports puzzles and is ready to deal with them, then it
tries to solve the given puzzle. After the puzzle is solved the
initiator restarts the request and returns the puzzle solution in a
new payload called Puzzle Solution payload (denoted as PS, see
Section 10.2) along with the received COOKIE notification back to the
responder.
HDR, N(COOKIE), [PS,] SA, KE, Ni, [V+][N+] -->
8.1.2.1. Computing Puzzle
General principals of constructing puzzles in IKEv2 are described in
Section 3. They can be summarized as follows: given unpredictable
string S and pseudo-random function PRF find the key K for that PRF
so that the result of PRF(K,S) has the specified number of trailing
zero bits.
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
IKE initiator is to find the key K for the agreed upon PRF such that
the result of PRF(K,cookie) has sufficient number of trailing zero
bits. Only the content of the COOKIE notification is used in puzzle
calculation, i.e. the header of the Notification payload is not
included.
8.1.3. Analyzing Repeated Request
The received request must at least contain COOKIE notification.
Otherwise it is an initial request and it must be processed according
to Section 8.1. First, the cookie MUST be checked for validity. If
the cookie is invalid then the request is treated as initial and is
processed according to Section 8.1. If the cookie is valid then some
important information is learned from it or from local state based on
identifier of the cookie's secret (see Section 8.1.1.3 for details).
This information would allow the responder to sort out incoming
requests, giving more priority to those of them, which were created
spending more initiator's resources.
First, the responder determines if it requested only a cookie, or
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
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
this payload MUST be ignored if for any reason the message contains
it. Since no puzzle was given, the responder marks the request with
the lowest priority since the initiator spent a little resources
creating it.
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
its request to solve the puzzle was honored or not. If the incoming
message doesn't contain PS payload, then it means that the 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 since the
initiator spent a little resources creating it.
If PS payload is found in the message then the responder MUST verify
the puzzle solution that it contains. The result must contain at
least the requested number of trailing zero bits (that is also
learned from the cookie, as well as the PRF algorithm used in puzzle
solution). If the result of the solution contais fewer bits, than
were requested, it means that 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
requested difficulty level, or if the responder didn't indicate any
particular difficulty level (by requesting zero level) and the
initiator was free to select any difficulty level it can afford, then
the priority of the request is calculated based on the following
considerations.
o The higher zero bits the initiator got, the higher priority its
request should achieve.
o The more consecutive puzzles the initiator solved (it must be
learned from the cookie), the higher priority its request should
achieve.
o The more time the initiator spent solving the puzzles (it must be
learned from the cookie), the higher priority its request should
achieve.
After the priority of the request is determined the final decision
whether to serve it or not is made.
8.1.4. Making Decision whether to Serve the Request
The responder decides what to do with the request based on its
priority and responder's current load. There are three possible
actions:
o Accept request.
o Reject request.
o Demand more work from initiator by giving it a new puzzle.
The responder SHOULD accept incoming request if its priority is high
- it means that the initiator spent quite a lot of resources. The
responder MAY also accept some of low-priority requests where the
initiators don't support puzzles. The percentage of accepted legacy
requests depends on the responder's current load.
If initiator solved the puzzle, but didn't spend much resources for
it (the selected puzzle difficulty level appeared to be low and the
initiator solved it quickly), then the responder SHOULD give it
another puzzle. The more puzzles the initiator solve the higher
would be its chances ro be served.
The details of how the responder takes decision on any particular
request are implementation dependant. The responder can collect all
the incoming requests for some short period of time, sort them out
based on their priority, calculate the number of alailable memory
slots for half-open IKE SAs and then serve that number of the
requests from the head of the sorted list. The rest of requests can
be either discarded or responded to with new puzzles.
Alternatively the responder may decide whether to accept every
incoming request with some kind of lottery, taking into account its
priority and the available resources.
8.2. Puzzles in IKE_AUTH Exchange
Once the IKE_SA_INIT exchange is completed, the responder has created
a state and is awaiting for the first message of the IKE_AUTH
exchange from initiator. At this point the initiator has already
passed return routability check and has proved that it has performed
some work to complete IKE_SA_INIT exchange. However, the initiator
is not yet authenticated and this fact allows malicious initiator to
conduct an attack, described in Section 2. Unlike DoS attack in
IKE_SA_INIT exchange, which is targeted on the responder's memory
resources, the goal of this attack is to exhaust responder's CPU
power. The attack is performed by sending the first IKE_AUTH message
containing garbage. This costs nothing to the initiator, but the
responder has to do relatively costly operations of computing the
Diffie-Hellman shared secret and deriving SK_* keys to be able to
verify authenticity of the message. If the responder doesn't save
the computed keys after unsuccessful verification of IKE_AUTH
message, then the attack can be repeated several times on the same
IKE SA.
The responder can use puzzles to make this attack more costly for the
initiator. The idea is that the responder includes puzzle in the
IKE_SA_INIT response message and the initiator includes puzzle
solution in the first IKE_AUTH request message outside the Encrypted
payload, so that the responder is able to verify puzzle solution
before computing Diffie-Hellman shared secret. The difficulty level
of the puzzle should be selected so, that the initiator would spend
substantially more time to solve the puzzle, than the responder to
compute the shared secret.
The responder should constantly monitor the amount of the half-open
IKE SA states, that receive IKE_AUTH messages, but cannot decrypt
them due to the integrity check failures. If the percentage of such
states is high and it takes an essential fraction of responder's
computing power to calculate keys for them, then the responder can
assume that it is under attack and can use puzzles to make it harder
for attackers.
8.2.1. Presenting Puzzle
The responder requests the initiator to solve a puzzle by including
the PUZZLE notification in the IKE_SA_INIT response message. The
responder MUST NOT use puzzles in the IKE_AUTH exchange unless the
puzzle has been previously presented and solved in the preceeding
IKE_SA_INIT exchange.
<-- HDR, SA, KE, Nr, N(PUZZLE), [V+][N+]
8.2.1.1. Selecting Puzzle Difficulty Level
The difficulty level of the puzzle in IKE_AUTH should be chosen so,
that the initiator would spend more time to solve the puzzle, than
the responder to compute Diffie-Hellman shared secret and the keys,
needed to decrypt and verify IKE_AUTH message. On the other hand,
the difficulty level should not be too high, otherwise the legitimate
clients would experience additional delay while establishing IKE SA.
Note, that since puzzles in the IKE_AUTH exchange are only allowed to
be used if they were used in the preceeding IKE_SA_INIT exchange, the
responder would be able to estimate the computing power of the
initiator and to select the difficulty level accordingly. Unlike
puzzles in IKE_SA_INIT, the requested difficulty level for IKE_AUTH
puzzles MUST NOT be zero. In other words, the responder must always
set specific difficulty level and must not let the initiator to
choose it on its own.
8.2.1.2. Selecting Puzzle Algorithm
The algorithm for the puzzle is selected as described in
Section 8.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
the puzzle in IKE_AUTH exchange, however it is expected that in most
cases they will be the same.
8.2.2. Solving Puzzle and Returning the Solution
If the IKE_SA_INIT response message contains the PUZZLE notification
and the initiator supports puzzles, it MUST solve the puzzle. Puzzle
construction on the IKE_AUTH exchange differs from the puzzle in the
IKE_SA_INIT exchange and is described in Section 8.2.2.1. Once the
puzzle is solved the initiator sends the IKE_AUTH request message,
containing the Puzzle Solution payload.
HDR, PS, SK {IDi, [CERT,] [CERTREQ,]
[IDr,] AUTH, SA, TSi, TSr} -->
The Puzzle Solution payload is placed outside the Encrypted payload,
so that the responder would be able to verify the puzzle before
calculating the Diffie-Hellman shared secret and the SK_* keys.
If IKE Fragmentation is used, then the PS payload MUST be present
only in the first IKE Fragment message, in accordance with the
Section 2.5.3 of [RFC7383]. Note, that calculation of the puzzle in
the IKE_AUTH exchange doesn't depend on the content of the IKE_AUTH
message (see Section 8.2.2.1). Thus the responder has to solve the
puzzle only once and the solution is valid for both unfragmented and
fragmented IKE messages.
8.2.2.1. Computing Puzzle
The puzzle in the IKE_AUTH exchange is computed differently, than in
the IKE_SA_INIT exchange (see Section 8.1.2.1). The general
principle is the same, the difference is in constructing of the
string S. Unlike the IKE_SA_INIT exchange, where S is the cookie, in
the IKE_AUTH exchange S is a concatenation of Nr and SPIr. In other
words, the task for IKE initiator is to find the key K for the agreed
upon PRF such that the result of PRF(K,Nr | SPIr) has sufficient
number of trailing zero bits. Nr is a nonce used by the responder in
IKE_SA_INIT exchange, stripped of any headers. SPIr is IKE responder
SPI in the SA being established.
8.2.3. Receiving Puzzle Solution
If the responder requested the initiator to solve puzzle in the
IKE_AUTH exchange, then it SHOULD silently discard all the IKE_AUTH
request messages without the Puzzle Solution payload.
Once the message containing solution for the puzzle is received the
responder SHOULD verify the solution before performing computationly
intensive operations - computing the Diffie-Hellman shared secret and
the SK_* keys. The responder MUST silently discard the received
message if the puzzle solution is not correct. If the puzzle is
successfully verified and the SK_* key are calculated, but the
message authenticity check fails, the responder SHOULD save the
calculated keys in 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
due to packets loss and/or reordering the responder would receive
non-first IKE Fragment messages before receiving the first one,
containing the PS payload. In this case the responder MAY choose to
keep the received fragments until the first fragment containing the
solution to the puzzle is received. However in this case the
responder SHOULD NOT try to verify authenticity (that would require
the calculation of the SK_* keys) untill the first fragment with the
PS payload is received and the solution to the puzzle is verified.
After successful verification of the puzzle the responder would
calculate the SK_* key and verify authenticity of the collected
fragments.
9. DoS Protection after IKE SA is created
Once IKE SA is created there is usually no much traffic over it. In
most cases this traffic consists of exchanges aimed to create
additional Child SAs, rekey or delete them and check the liveness of
the peer. With a typical setup and typical Child SA lifetimes there
must be no more than a few such exchanges in a minute, often less.
Some of these exchanges require relatively little resources (like
liveness check), while others may be resourse consuming (like
creating or rekeying Child SA with Diffie-Hellman exchange).
Since any endpoint can initiate new exchange, there is a possibility
that a peer would initiate too many exchanges, that could exhaust
host resources. For example the peer can perform endless continuous
Child SA rekeying or create overwhelming number of Child SAs with the
same Traffic Selectors etc. Such behaviour may be caused by buggy
implementation, misconfiguration or be intentional. The latter
becomes more real threat if the peer uses NULL Authentication,
described in [NULL-AUTH]. In this case the peer remains anonymous,
that allow it to escape any resposibility for its actions.
The following recommendations for defense against possible DoS
attacks after IKE SA is established are mostly intended for
implementations that allow unauthenticated IKE sessions. However
they may also be useful in other cases.
o If the IKEv2 window size is greater than one, then the peer could
initiate multiple simultaneous exchanges, that would potentially
increase host resourse consumption. Since currently there is no
way in IKEv2 to decrease window size once it was increased (see
Section 2.3 of [RFC7296]), the window size cannot be dynamically
adjusted depending on the load. For that reason if is NOT
RECOMMENDED to ever increase IKEv2 window size above its default
value of one if the peer uses NULL Authentication.
o If the peer initiates requests to rekey IKE SA or Child SA too
often, implementations can respond to some of these requests with
the TEMPORARY_FAILURE notification, indicating that the request
should be retried after some period of time.
o If the peer creates too many Child SA with the same or overlapping
Traffic Selectors, implementations can respond with the
NO_ADDITIONAL_SAS notification.
o If the peer initiates too many exchanges of any kind,
implementations can introduce artificial delay before responding
to request messages. This delay would decrease the rate the
implementation need to process requests from any particular peer,
making possible to process requests from the others. The delay
should not be too long not to cause IKE SA to be deleted on the
other end due to timeout. It is believed that a few seconds is
enough. Note, that if the responder receives retransmissions of
the request message during the delay period, the retransmitted
messages should be silently discarded.
o If these counter-measures are inefficient, implementations can
delete IKE SA with an offending peer by sending Delete Payload.
10. Payload Formats
10.1. PUZZLE Notification
The PUZZLE notification is used by IKE responder to inform the
initiator about the necessity to solve the puzzle. It contains the
difficulty level of the puzzle and the PRF the initiator should use.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Protocol ID(=0)| SPI Size (=0) | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PRF | Difficulty |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Protocol ID (1 octet) - MUST be 0.
o SPI Size (1 octet) - MUST be 0, meaning no Security Parameter
Index (SPI) is present.
o Notify Message Type (2 octets) - MUST be <TBA by IANA>, the value
assigned for the PUZZLE notification.
o PRF (2 octets) - Transform ID of the PRF algorithm that must be
used to solve the puzzle. Readers should refer to the section
"Transform Type 2 - Pseudo-random Function Transform IDs" in
[IKEV2-IANA] for the list of possible values.
o Difficulty (1 octet) - Difficulty Level of the puzzle. Specifies
minimum number of trailing zero bit, that the result of PRF must
contain. Value 0 means that the responder doesn't request any
specific difficulty level and the initiator is free to select
appropriate difficulty level of its own.
This notification contains no data.
10.2. Puzzle Solution Payload
The solution to the puzzle is returned back to the responder in a
dedicated payload, called Puzzle Solution payload and denoted as PS
in this document.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Puzzle Solution Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Puzzle Solution Data (variable length) - Contains the solution to
the puzzle - i.e. the key for the PRF. This field MUST NOT be
empty. If the selected PRF has a fixed-size key, then the size of
the Puzzle Solution Data MUST be equal to the size of the key. If
the PRF agreed upon accepts keys of any size, then then the size
of the Puzzle Solution Data MUST be between 1 octet and the
preferred key length of the PRF (inclusive).
The payload type for the Puzzle Solution payload is <TBA by IANA>.
11. Security Considerations
To be added. To be added.
9. IANA Considerations 12. IANA Considerations
IANA is requested to assign a notify message type from the status This document defines a new payload in the "IKEv2 Payload Types"
types range (16430-40959) of the "IKEv2 Notify Message Types - Status registry:
Types" registry with name "PUZZLE".
10. References <TBA> Puzzle Solution PS
10.1. Normative References This document also defines a new Notify Message Type in the "IKEv2
Notify Message Types - Status Types" registry:
<TBA> PUZZLE
13. 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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC7296] Kivinen, T., Kaufman, C., Hoffman, P., Nir, Y., and P. [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Eronen, "Internet Key Exchange Protocol Version 2 Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", RFC 7296, October 2014. (IKEv2)", STD 79, RFC 7296, October 2014.
10.2. Informative References [RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2
(IKEv2) Message Fragmentation", RFC 7383, November 2014.
[IKEV2-IANA]
"Internet Key Exchange Version 2 (IKEv2) Parameters",
<http://www.iana.org/assignments/ikev2-parameters>.
13.2. Informative References
[RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange
Protocol Version 2 (IKEv2) Session Resumption", RFC 5723,
January 2010.
[bitcoins] [bitcoins]
Nakamoto, S., "Bitcoin: A Peer-to-Peer Electronic Cash Nakamoto, S., "Bitcoin: A Peer-to-Peer Electronic Cash
System", October 2008. System", October 2008, <https://bitcoin.org/bitcoin.pdf>.
Author's Address [ALG-AGILITY]
Housley, R., "Guidelines for Cryptographic Algorithm
Agility", draft-iab-crypto-alg-agility-02 (work in
progress), December 2014.
[NULL-AUTH]
Smyslov, V. and P. Wouters, "The NULL Authentication
Method in IKEv2 Protocol", draft-ietf-ipsecme-ikev2-null-
auth-02 (work in progress), January 2015.
Authors' Addresses
Yoav Nir Yoav Nir
Check Point Software Technologies Ltd. Check Point Software Technologies Ltd.
5 Hasolelim st. 5 Hasolelim st.
Tel Aviv 6789735 Tel Aviv 6789735
Israel Israel
Email: ynir.ietf@gmail.com EMail: ynir.ietf@gmail.com
Valery Smyslov
ELVIS-PLUS
PO Box 81
Moscow (Zelenograd) 124460
Russian Federation
Phone: +7 495 276 0211
EMail: svan@elvis.ru
 End of changes. 28 change blocks. 
83 lines changed or deleted 692 lines changed or added

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