draft-ietf-ipsecme-ddos-protection-08.txt   draft-ietf-ipsecme-ddos-protection-09.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: February 18, 2017 ELVIS-PLUS Expires: March 16, 2017 ELVIS-PLUS
August 17, 2016 September 12, 2016
Protecting Internet Key Exchange Protocol version 2 (IKEv2) Protecting Internet Key Exchange Protocol version 2 (IKEv2)
Implementations from Distributed Denial of Service Attacks Implementations from Distributed Denial of Service Attacks
draft-ietf-ipsecme-ddos-protection-08 draft-ietf-ipsecme-ddos-protection-09
Abstract Abstract
This document recommends implementation and configuration best This document recommends implementation and configuration best
practices for Internet Key Exchange Protocol version 2 (IKEv2) practices for Internet Key Exchange Protocol version 2 (IKEv2)
Responders, to allow them to resist Denial of Service and Distributed Responders, to allow them to resist Denial of Service and Distributed
Denial of Service attacks. Additionally, the document introduces a Denial of Service attacks. Additionally, the document introduces a
new mechanism called "Client Puzzles" that help accomplish this task. new mechanism called "Client Puzzles" that help accomplish this task.
Status of This Memo Status of This Memo
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 18, 2017. This Internet-Draft will expire on March 16, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 20 skipping to change at page 3, line 20
against DoS attacks from spoofed IP-addresses. However, bot-nets against DoS attacks from spoofed IP-addresses. However, bot-nets
have become widespread, allowing attackers to perform Distributed have become widespread, allowing attackers to perform Distributed
Denial of Service (DDoS) attacks, which are more difficult to defend Denial of Service (DDoS) attacks, which are more difficult to defend
against. This document presents recommendations to help the against. This document presents recommendations to help the
Responder counter (D)DoS attacks. It also introduces a new mechanism Responder counter (D)DoS attacks. It also introduces a new mechanism
-- "puzzles" -- that can help accomplish this task. -- "puzzles" -- that can help accomplish this task.
2. Conventions Used in This Document 2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in
[RFC2119].
3. The Vulnerability 3. The Vulnerability
The IKE_SA_INIT Exchange described in Section 1.2 of [RFC7296] The IKE_SA_INIT Exchange described in Section 1.2 of [RFC7296]
involves the Initiator sending a single message. The Responder involves the Initiator sending a single message. The Responder
replies with a single message and also allocates memory for a replies with a single message and also allocates memory for a
structure called a half-open IKE Security Association (SA). This structure called a half-open IKE Security Association (SA). This
half-open SA is later authenticated in the IKE_AUTH Exchange. If half-open SA is later authenticated in the IKE_AUTH Exchange. If
that IKE_AUTH request never comes, the half-open SA is kept for an that IKE_AUTH request never comes, the half-open SA is kept for an
unspecified amount of time. Depending on the algorithms used and unspecified amount of time. Depending on the algorithms used and
skipping to change at page 11, line 13 skipping to change at page 11, line 13
half-open SAs resulting from replayed IKE_SESSION_RESUME messages. half-open SAs resulting from replayed IKE_SESSION_RESUME messages.
Several kinds of DoS attacks are possible on servers supported IKE Several kinds of DoS attacks are possible on servers supported IKE
Session Resumption. See Section 9.3 of [RFC5723] for details. Session Resumption. See Section 9.3 of [RFC5723] for details.
4.6. Keeping computed Shared Keys 4.6. Keeping computed Shared Keys
Once the IKE_SA_INIT exchange is finished, the Responder is waiting Once the IKE_SA_INIT exchange is finished, the Responder is waiting
for the first message of the IKE_AUTH exchange from the Initiator. for the first message of the IKE_AUTH exchange from the Initiator.
At this point the Initiator is not yet authenticated, and this fact At this point the Initiator is not yet authenticated, and this fact
allows an attacker to perform an attack, described in Section 3. The allows an attacker to perform an attack, described in Section 3.
attacker can just send garbage in the IKE_AUTH message forcing the Instead of sending properly formed and encrypted IKE_AUTH message the
Responder to perform costly CPU operations to compute SK_* keys. attacker can just send arbitrary data, forcing the Responder to
perform costly CPU operations to compute SK_* keys.
If the received IKE_AUTH message failed to decrypt correctly (or If the received IKE_AUTH message failed to decrypt correctly (or
failed to pass ICV check), then the Responder SHOULD still keep the failed to pass ICV check), then the Responder SHOULD still keep the
computed SK_* keys, so that if it happened to be an attack, then an computed SK_* keys, so that if it happened to be an attack, then an
attacker cannot get advantage of repeating the attack multiple times attacker cannot get advantage of repeating the attack multiple times
on a single IKE SA. The responder can also use puzzles in the on a single IKE SA. The responder can also use puzzles in the
IKE_AUTH exchange as decribed in Section 7.2. IKE_AUTH exchange as decribed in Section 7.2.
4.7. Preventing "Hash and URL" Certificate Encoding Attacks 4.7. Preventing "Hash and URL" Certificate Encoding Attacks
In IKEv2 each side may use the "Hash and URL" Certificate Encoding to In IKEv2 each side may use the "Hash and URL" Certificate Encoding to
instruct the peer to retrieve certificates from the specified instruct the peer to retrieve certificates from the specified
location (see Section 3.6 of [RFC7296] for details). Malicious location (see Section 3.6 of [RFC7296] for details). Malicious
initiators can use this feature to mount a DoS attack on the initiators can use this feature to mount a DoS attack on the
responder by providing an URL pointing to a large file possibly responder by providing an URL pointing to a large file possibly
containing garbage. While downloading the file the responder containing meaningless bits. While downloading the file the
consumes CPU, memory and network bandwidth. responder consumes CPU, memory and network bandwidth.
To prevent this kind of attack, the responder should not blindly To prevent this kind of attack, the responder should not blindly
download the whole file. Instead, it SHOULD first read the initial download the whole file. Instead, it SHOULD first read the initial
few bytes, decode the length of the ASN.1 structure from these bytes, few bytes, decode the length of the ASN.1 structure from these bytes,
and then download no more than the decoded number of bytes. Note, and then download no more than the decoded number of bytes. Note,
that it is always possible to determine the length of ASN.1 that it is always possible to determine the length of ASN.1
structures used in IKEv2, if they are DER-encoded, by analyzing the structures used in IKEv2, if they are DER-encoded, by analyzing the
first few bytes. However, since the content of the file being first few bytes. However, since the content of the file being
downloaded can be under the attacker's control, implementations downloaded can be under the attacker's control, implementations
should not blindly trust the decoded length and SHOULD check whether should not blindly trust the decoded length and SHOULD check whether
skipping to change at page 17, line 25 skipping to change at page 17, line 25
Cryptographic algorithm agility is considered an important feature Cryptographic algorithm agility is considered an important feature
for modern protocols ([RFC7696]). Algorithm agility ensures that a for modern protocols ([RFC7696]). Algorithm agility ensures that a
protocol doesn't rely on a single built-in set of cryptographic protocol doesn't rely on a single built-in set of cryptographic
algorithms, but has a means to replace one set with another, and algorithms, but has a means to replace one set with another, and
negotiate new algorithms with the peer. IKEv2 fully supports negotiate new algorithms with the peer. IKEv2 fully supports
cryptographic algorithm agility for its core operations. cryptographic algorithm agility for its core operations.
To support crypto agility in case of puzzles, the algorithm that is To support crypto agility in case of puzzles, the algorithm that is
used to compute a puzzle needs to be negotiated during the used to compute a puzzle needs to be negotiated during the
IKE_SA_INIT exchange. The negotiation is performed as follows. The IKE_SA_INIT exchange. The negotiation is performed as follows. The
initial request message sent by the Initiator contains an SA payload initial request message from the Initiator contains an SA payload,
with the list of transforms the Initiator supports and is willing to containing a list of transforms of different types. Thereby the
use in the IKE SA being established. The Responder parses the Initiator asserts that it supports all transforms from this list and
received SA payload and finds a mutually supported PRFs. The can use any of them in the IKE SA being established. The Responder
Responder selects the preferred PRF from the list of mutually parses the received SA payload and finds a mutually supported of type
supported ones and includes it into the PUZZLE notification. There PRF. The Responder selects the preferred PRF from the list of
is no requirement that the PRF selected for puzzles be the same as mutually supported ones and includes it into the PUZZLE notification.
the PRF that is negotiated later for use in core IKE SA crypto There is no requirement that the PRF selected for puzzles be the same
as the PRF that is negotiated later for use in core IKE SA crypto
operations. If there are no mutually supported PRFs, then IKE SA operations. If there are no mutually supported PRFs, then IKE SA
negotiation will fail anyway and there is no reason to return a negotiation will fail anyway and there is no reason to return a
puzzle. In this case the Responder returns a NO_PROPOSAL_CHOSEN puzzle. In this case the Responder returns a NO_PROPOSAL_CHOSEN
notification. Note that PRF is a mandatory transform type for IKE SA notification. Note that PRF is a mandatory transform type for IKE SA
(see Sections 3.3.2 and 3.3.3 of [RFC7296]) and at least one (see Sections 3.3.2 and 3.3.3 of [RFC7296]) and at least one
transform of this type must always be present in the SA payload in an transform of this type must always be present in the SA payload in an
IKE_SA_INIT request message. IKE_SA_INIT request message.
7.1.1.3. Generating a Cookie 7.1.1.3. Generating a Cookie
skipping to change at page 19, line 40 skipping to change at page 19, line 42
least the specified number of trailing zero bits. This specification least the specified number of trailing zero bits. This specification
requires that the solution to the puzzle contain 4 different keys requires that the solution to the puzzle contain 4 different keys
(i.e. N=4). (i.e. N=4).
In the IKE_SA_INIT exchange it is the cookie that plays the role of In the IKE_SA_INIT exchange it is the cookie that plays the role of
unpredictable string S. In other words, in the IKE_SA_INIT the task unpredictable string S. In other words, in the IKE_SA_INIT the task
for the IKE Initiator is to find the four different, equal-sized keys for the IKE Initiator is to find the four different, equal-sized keys
Ki for the agreed upon PRF such that each result of PRF(Ki,cookie) Ki for the agreed upon PRF such that each result of PRF(Ki,cookie)
where i = [1..4] has a sufficient number of trailing zero bits. Only where i = [1..4] has a sufficient number of trailing zero bits. Only
the content of the COOKIE notification is used in puzzle calculation, the content of the COOKIE notification is used in puzzle calculation,
i.e. the header of the Notification payload is not included. i.e. the header of the Notify payload is not included.
Note, that puzzles in the IKE_AUTH exchange are computed differently Note, that puzzles in the IKE_AUTH exchange are computed differently
than in the IKE_SA_INIT_EXCHANGE. See Section 7.2.3 for details. than in the IKE_SA_INIT_EXCHANGE. See Section 7.2.3 for details.
7.1.4. Analyzing Repeated Request 7.1.4. Analyzing Repeated Request
The received request must at least contain a COOKIE notification. The received request must at least contain a COOKIE notification.
Otherwise it is an initial request and it must be processed according Otherwise it is an initial request and 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
skipping to change at page 22, line 17 skipping to change at page 22, line 21
Once the IKE_SA_INIT exchange is completed, the Responder has created Once the IKE_SA_INIT exchange is completed, the Responder has created
a state and is waiting for the first message of the IKE_AUTH exchange a state and is waiting for the first message of the IKE_AUTH exchange
from the Initiator. At this point the Initiator has already passed from the Initiator. At this point the Initiator has already passed
the return routability check and has proved that it has performed the return routability check and has proved that it has performed
some work to complete IKE_SA_INIT exchange. However, the Initiator some work to complete IKE_SA_INIT exchange. However, the Initiator
is not yet authenticated and this allows a malicious Initiator to is not yet authenticated and this allows a malicious Initiator to
perform an attack, described in Section 3. Unlike a DoS attack in perform an attack, described in Section 3. Unlike a DoS attack in
the IKE_SA_INIT exchange, which is targeted on the Responder's memory the IKE_SA_INIT exchange, which is targeted on the Responder's memory
resources, the goal of this attack is to exhaust a Responder's CPU resources, the goal of this attack is to exhaust a Responder's CPU
power. The attack is performed by sending the first IKE_AUTH message power. The attack is performed by sending the first IKE_AUTH message
containing garbage. This costs nothing to the Initiator, but the containing arbitrary data. This costs nothing to the Initiator, but
Responder has to perform relatively costly operations when computing the Responder has to perform relatively costly operations when
the D-H shared secret and deriving SK_* keys to be able to verify computing the D-H shared secret and deriving SK_* keys to be able to
authenticity of the message. If the Responder doesn't keep the verify authenticity of the message. If the Responder doesn't keep
computed keys after an unsuccessful verification of the IKE_AUTH the computed keys after an unsuccessful verification of the IKE_AUTH
message, then the attack can be repeated several times on the same message, then the attack can be repeated several times on the same
IKE SA. IKE SA.
The Responder can use puzzles to make this attack more costly for the The Responder can use puzzles to make this attack more costly for the
Initiator. The idea is that the Responder includes a puzzle in the Initiator. The idea is that the Responder includes a puzzle in the
IKE_SA_INIT response message and the Initiator includes a puzzle IKE_SA_INIT response message and the Initiator includes a puzzle
solution in the first IKE_AUTH request message outside the Encrypted solution in the first IKE_AUTH request message outside the Encrypted
payload, so that the Responder is able to verify puzzle solution payload, so that the Responder is able to verify puzzle solution
before computing the D-H shared secret. The difficulty level of the before computing the D-H shared secret.
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 The Responder should constantly monitor the amount of the half-open
IKE SA states that receive IKE_AUTH messages that cannot be decrypted IKE SA states that receive IKE_AUTH messages that cannot be decrypted
due to integrity check failures. If the percentage of such states is due to integrity check failures. If the percentage of such states is
high and it takes an essential fraction of Responder's computing high and it takes an essential fraction of Responder's computing
power to calculate keys for them, then the Responder may assume that power to calculate keys for them, then the Responder may assume that
it is under attack and SHOULD use puzzles to make it harder for it is under attack and SHOULD use puzzles to make it harder for
attackers. attackers.
7.2.1. Presenting Puzzle 7.2.1. Presenting Puzzle
skipping to change at page 24, line 42 skipping to change at page 24, line 42
The Responder MUST silently discard the received message if any The Responder MUST silently discard the received message if any
checked verification result is not correct (contains insufficient checked verification result is not correct (contains insufficient
number of trailing zero bits). If the Responder successfully number of trailing zero bits). If the Responder successfully
verifies the puzzle and calculates the SK_* key, but the message verifies the puzzle and calculates the SK_* key, but the message
authenticity check fails, then it SHOULD save the calculated keys in authenticity check fails, then it SHOULD save the calculated keys in
the IKE SA state while waiting for the retransmissions from the the IKE SA state while waiting for the retransmissions from the
Initiator. In this case the Responder may skip verification of the Initiator. In this case the Responder may skip verification of the
puzzle solution and ignore the Puzzle Solution payload in the puzzle solution and ignore the Puzzle Solution payload in the
retransmitted messages. retransmitted messages.
If the Initiator uses IKE Fragmentation, then it is possible, that If the Initiator uses IKE Fragmentation, then it sends all fragments
due to packet loss and/or reordering the Responder could receive non- of a message simultaneously. Due to packets loss and/or reordering
first IKE Fragment messages before receiving the first one containing it is possible that the Responder receives subsequent fragments
the PS payload. In this case the Responder MAY choose to keep the before receiving the first one, that contains the PS payload. In
received fragments until the first fragment containing the solution this case the Responder MAY choose to keep the received fragments
to the puzzle is received. In this case the Responder SHOULD NOT try until the first fragment containing the solution to the puzzle is
to verify authenticity of the kept fragments until the first fragment received. In this case the Responder SHOULD NOT try to verify
with the PS payload is received and the solution to the puzzle is authenticity of the kept fragments until the first fragment with the
verified. After successful verification of the puzzle, the Responder PS payload is received and the solution to the puzzle is verified.
can then calculate the SK_* key and verify authenticity of the After successful verification of the puzzle, the Responder can then
collected fragments. calculate the SK_* key and verify authenticity of the collected
fragments.
8. Payload Formats 8. Payload Formats
8.1. PUZZLE Notification 8.1. PUZZLE Notification
The PUZZLE notification is used by the IKE Responder to inform the The PUZZLE notification is used by the IKE Responder to inform the
Initiator about the need to solve the puzzle. It contains the Initiator about the need to solve the puzzle. It contains the
difficulty level of the puzzle and the PRF the Initiator should use. difficulty level of the puzzle and the PRF the Initiator should use.
1 2 3 1 2 3
 End of changes. 11 change blocks. 
40 lines changed or deleted 41 lines changed or added

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