--- 1/draft-ietf-ipsecme-ddos-protection-08.txt 2016-09-12 02:16:25.777312870 -0700 +++ 2/draft-ietf-ipsecme-ddos-protection-09.txt 2016-09-12 02:16:25.837314379 -0700 @@ -1,20 +1,20 @@ IPSecME Working Group Y. Nir Internet-Draft Check Point Intended status: Standards Track V. Smyslov -Expires: February 18, 2017 ELVIS-PLUS - August 17, 2016 +Expires: March 16, 2017 ELVIS-PLUS + September 12, 2016 Protecting Internet Key Exchange Protocol version 2 (IKEv2) Implementations from Distributed Denial of Service Attacks - draft-ietf-ipsecme-ddos-protection-08 + draft-ietf-ipsecme-ddos-protection-09 Abstract This document recommends implementation and configuration best practices for Internet Key Exchange Protocol version 2 (IKEv2) Responders, to allow them to resist Denial of Service and Distributed Denial of Service attacks. Additionally, the document introduces a new mechanism called "Client Puzzles" that help accomplish this task. Status of This Memo @@ -25,21 +25,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -103,22 +103,23 @@ against DoS attacks from spoofed IP-addresses. However, bot-nets have become widespread, allowing attackers to perform Distributed Denial of Service (DDoS) attacks, which are more difficult to defend against. This document presents recommendations to help the Responder counter (D)DoS attacks. It also introduces a new mechanism -- "puzzles" -- that can help accomplish this task. 2. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + [RFC2119]. 3. The Vulnerability The IKE_SA_INIT Exchange described in Section 1.2 of [RFC7296] involves the Initiator sending a single message. The Responder replies with a single message and also allocates memory for a structure called a half-open IKE Security Association (SA). This 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 unspecified amount of time. Depending on the algorithms used and @@ -475,40 +476,41 @@ half-open SAs resulting from replayed IKE_SESSION_RESUME messages. Several kinds of DoS attacks are possible on servers supported IKE Session Resumption. See Section 9.3 of [RFC5723] for details. 4.6. Keeping computed Shared Keys Once the IKE_SA_INIT exchange is finished, the Responder is waiting for the first message of the IKE_AUTH exchange from the Initiator. At this point the Initiator is not yet authenticated, and this fact - allows an attacker to perform an attack, described in Section 3. The - attacker can just send garbage in the IKE_AUTH message forcing the - Responder to perform costly CPU operations to compute SK_* keys. + allows an attacker to perform an attack, described in Section 3. + Instead of sending properly formed and encrypted IKE_AUTH message the + 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 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 attacker cannot get advantage of repeating the attack multiple times on a single IKE SA. The responder can also use puzzles in the IKE_AUTH exchange as decribed in Section 7.2. 4.7. Preventing "Hash and URL" Certificate Encoding Attacks In IKEv2 each side may use the "Hash and URL" Certificate Encoding to instruct the peer to retrieve certificates from the specified location (see Section 3.6 of [RFC7296] for details). Malicious initiators can use this feature to mount a DoS attack on the responder by providing an URL pointing to a large file possibly - containing garbage. While downloading the file the responder - consumes CPU, memory and network bandwidth. + containing meaningless bits. While downloading the file the + responder consumes CPU, memory and network bandwidth. To prevent this kind of attack, the responder should not blindly download the whole file. Instead, it SHOULD first read the initial 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, that it is always possible to determine the length of ASN.1 structures used in IKEv2, if they are DER-encoded, by analyzing the first few bytes. However, since the content of the file being downloaded can be under the attacker's control, implementations should not blindly trust the decoded length and SHOULD check whether @@ -768,28 +770,29 @@ Cryptographic algorithm agility is considered an important feature for modern protocols ([RFC7696]). Algorithm agility ensures that a protocol doesn't rely on a single built-in set of cryptographic algorithms, but has a means to replace one set with another, and negotiate new algorithms with the peer. IKEv2 fully supports cryptographic algorithm agility for its core operations. To support crypto agility in case of puzzles, the algorithm that is used to compute a puzzle needs to be negotiated during the IKE_SA_INIT exchange. The negotiation is performed as follows. The - initial request message sent by the Initiator contains an SA payload - with the list of transforms the Initiator supports and is willing to - use in the IKE SA being established. The Responder parses the - received SA payload and finds a mutually supported PRFs. The - Responder selects the preferred PRF from the list of mutually - supported ones 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 use in core IKE SA crypto + initial request message from the Initiator contains an SA payload, + containing a list of transforms of different types. Thereby the + Initiator asserts that it supports all transforms from this list and + can use any of them in the IKE SA being established. The Responder + parses the received SA payload and finds a mutually supported of type + PRF. The Responder selects the preferred PRF from the list of + mutually supported ones 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 use in core IKE SA crypto operations. If there are no mutually supported PRFs, then IKE SA negotiation will fail anyway and there is no reason to return a puzzle. In this case the Responder returns a 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 the SA payload in an IKE_SA_INIT request message. 7.1.1.3. Generating a Cookie @@ -881,21 +884,21 @@ least the specified number of trailing zero bits. This specification requires that the solution to the puzzle contain 4 different keys (i.e. N=4). 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 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) where i = [1..4] has a 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. + i.e. the header of the Notify payload is not included. 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. 7.1.4. Analyzing Repeated Request The received request must at least contain a COOKIE notification. 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 the cookie is invalid, then the request is treated as initial and is @@ -1002,37 +1005,34 @@ 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 from the Initiator. At this point the Initiator has already passed the 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 allows a malicious Initiator to 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 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 - containing garbage. This costs nothing to the Initiator, but the - Responder has to perform relatively costly operations when computing - the D-H shared secret and deriving SK_* keys to be able to verify - authenticity of the message. If the Responder doesn't keep the - computed keys after an unsuccessful verification of the IKE_AUTH + containing arbitrary data. This costs nothing to the Initiator, but + the Responder has to perform relatively costly operations when + computing the D-H shared secret and deriving SK_* keys to be able to + verify authenticity of the message. If the Responder doesn't keep + the computed keys after an unsuccessful verification of the 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 a puzzle in the IKE_SA_INIT response message and the Initiator includes a 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 the D-H 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. + before computing the D-H shared secret. The Responder should constantly monitor the amount of the half-open IKE SA states that receive IKE_AUTH messages that cannot be decrypted due to 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 may assume that it is under attack and SHOULD use puzzles to make it harder for attackers. 7.2.1. Presenting Puzzle @@ -1124,31 +1124,32 @@ The Responder MUST silently discard the received message if any checked verification result is not correct (contains insufficient number of trailing zero bits). If the Responder successfully verifies the puzzle and calculates the SK_* key, but the message authenticity check fails, then it 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 packet loss and/or reordering the Responder could 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. In this case the Responder SHOULD NOT try - to verify authenticity of the kept fragments until 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 - can then calculate the SK_* key and verify authenticity of the - collected fragments. + If the Initiator uses IKE Fragmentation, then it sends all fragments + of a message simultaneously. Due to packets loss and/or reordering + it is possible that the Responder receives subsequent fragments + before receiving the first one, that contains 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. In this case the Responder SHOULD NOT try to verify + authenticity of the kept fragments until 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 can then + calculate the SK_* key and verify authenticity of the collected + fragments. 8. Payload Formats 8.1. PUZZLE Notification The PUZZLE notification is used by the IKE Responder to inform the Initiator about the need to solve the puzzle. It contains the difficulty level of the puzzle and the PRF the Initiator should use. 1 2 3