--- 1/draft-ietf-ipsecme-ddos-protection-05.txt 2016-04-15 13:15:55.459912130 -0700 +++ 2/draft-ietf-ipsecme-ddos-protection-06.txt 2016-04-15 13:15:55.519913605 -0700 @@ -1,20 +1,20 @@ IPSecME Working Group Y. Nir Internet-Draft Check Point Intended status: Standards Track V. Smyslov -Expires: September 22, 2016 ELVIS-PLUS - March 21, 2016 +Expires: October 17, 2016 ELVIS-PLUS + April 15, 2016 Protecting Internet Key Exchange Protocol version 2 (IKEv2) Implementations from Distributed Denial of Service Attacks - draft-ietf-ipsecme-ddos-protection-05 + draft-ietf-ipsecme-ddos-protection-06 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,76 +25,77 @@ 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 September 22, 2016. + This Internet-Draft will expire on October 17, 2016. 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 3. The Vulnerability . . . . . . . . . . . . . . . . . . . . . . 3 4. Defense Measures while IKE SA is being created . . . . . . . 6 4.1. Retention Periods for Half-Open SAs . . . . . . . . . . . 6 4.2. Rate Limiting . . . . . . . . . . . . . . . . . . . . . . 6 4.3. The Stateless Cookie . . . . . . . . . . . . . . . . . . 7 4.4. Puzzles . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.5. Session Resumption . . . . . . . . . . . . . . . . . . . 10 4.6. Keeping computed Shared Keys . . . . . . . . . . . . . . 10 4.7. Preventing Attacks using "Hash and URL" Certificate Encoding . . . . . . . . . . . . . . . . . . . . . . . . 11 + 4.8. IKE Fragmentation . . . . . . . . . . . . . . . . . . . . 11 5. Defense Measures after IKE SA is created . . . . . . . . . . 11 - 6. Plan for Defending a Responder . . . . . . . . . . . . . . . 12 - 7. Using Puzzles in the Protocol . . . . . . . . . . . . . . . . 14 + 6. Plan for Defending a Responder . . . . . . . . . . . . . . . 13 + 7. Using Puzzles in the Protocol . . . . . . . . . . . . . . . . 15 7.1. Puzzles in IKE_SA_INIT Exchange . . . . . . . . . . . . . 15 - 7.1.1. Presenting Puzzle . . . . . . . . . . . . . . . . . . 15 + 7.1.1. Presenting Puzzle . . . . . . . . . . . . . . . . . . 16 7.1.2. Solving Puzzle and Returning the Solution . . . . . . 18 - 7.1.3. Computing Puzzle . . . . . . . . . . . . . . . . . . 18 + 7.1.3. Computing Puzzle . . . . . . . . . . . . . . . . . . 19 7.1.4. Analyzing Repeated Request . . . . . . . . . . . . . 19 7.1.5. Making Decision whether to Serve the Request . . . . 20 7.2. Puzzles in IKE_AUTH Exchange . . . . . . . . . . . . . . 21 7.2.1. Presenting Puzzle . . . . . . . . . . . . . . . . . . 22 - 7.2.2. Solving Puzzle and Returning the Solution . . . . . . 22 + 7.2.2. Solving Puzzle and Returning the Solution . . . . . . 23 7.2.3. Computing Puzzle . . . . . . . . . . . . . . . . . . 23 - 7.2.4. Receiving Puzzle Solution . . . . . . . . . . . . . . 23 + 7.2.4. Receiving Puzzle Solution . . . . . . . . . . . . . . 24 8. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 24 8.1. PUZZLE Notification . . . . . . . . . . . . . . . . . . . 24 8.2. Puzzle Solution Payload . . . . . . . . . . . . . . . . . 25 9. Operational Considerations . . . . . . . . . . . . . . . . . 26 10. Security Considerations . . . . . . . . . . . . . . . . . . . 26 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 - 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 - 13.1. Normative References . . . . . . . . . . . . . . . . . . 27 + 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 + 13.1. Normative References . . . . . . . . . . . . . . . . . . 28 13.2. Informative References . . . . . . . . . . . . . . . . . 28 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 1. Introduction Denial of Service (DoS) attacks have always been considered a serious threat. These attacks are usually difficult to defend against since the amount of resources the victim has is always bounded (regardless of how high it is) and because some resources are required for distinguishing a legitimate session from an attack. The Internet Key Exchange protocol version 2 (IKEv2) described in @@ -274,26 +275,23 @@ Even with DDoS, the attacker has only a limited amount of nodes participating in the attack. By limiting the amount of half-open SAs that are allowed to exist concurrently with each such node, the total amount of half-open SAs is capped, as is the total amount of key derivations that the Responder is forced to complete. In IPv4 it makes sense to limit the number of half-open SAs based on IP address. Most IPv4 nodes are either directly attached to the Internet using a routable address or are hidden behind a NAT device - with a single IPv4 external address. IPv6 networks are currently a - rarity, so we can only speculate on what their wide deployment will - be like, but the current thinking is that ISP customers will be - assigned whole subnets, so we don't expect the kind of NAT deployment - that is common in IPv4. For this reason, it makes sense to use a - 64-bit prefix as the basis for rate limiting in IPv6. + with a single IPv4 external address. For IPv6, ISPs assign between a + /48 and a /64, so it makes sense to use a 64-bit prefix as the basis + for rate limiting in IPv6. The number of half-open SAs is easy to measure, but it is also worthwhile to measure the number of failed IKE_AUTH exchanges. If possible, both factors should be taken into account when deciding which IP address or prefix is considered suspicious. There are two ways to rate-limit a peer address or prefix: 1. Hard Limit - where the number of half-open SAs is capped, and any further IKE_SA_INIT requests are rejected. @@ -323,26 +321,28 @@ to counteract the attack can be avoided. 4.3. The Stateless Cookie Section 2.6 of [RFC7296] offers a mechanism to mitigate DoS attack: the stateless cookie. When the server is under load, the Responder responds to the IKE_SA_INIT request with a calculated "stateless cookie" - a value that can be re-calculated based on values in the IKE_SA_INIT request without storing Responder-side state. The Initiator is expected to repeat the IKE_SA_INIT request, this time - including the stateless cookie. + including the stateless cookie. This mechanism prevents DoS attacks + from spoofed IP addresses, since an attacker needs to have a routable + IP address to return the cookie. Attackers that have multiple source IP addresses with return routability, such as in the case of bot-nets, can fill up a half-open SA table anyway. The cookie mechanism limits the amount of allocated - state to the size of the bot-net, multiplied by the number of half- + state to the number of attackers, multiplied by the number of half- open SAs allowed per peer address, multiplied by the amount of state allocated for each half-open SA. With typical values this can easily reach hundreds of megabytes. 4.4. Puzzles The puzzle introduced here extends the cookie mechanism from [RFC7296]. It is loosely based on the proof-of-work technique used in Bitcoins [bitcoins]. This sets an upper bound, determined by the attacker's CPU, to the number of negotiations it can initiate in a @@ -458,20 +458,23 @@ When the Responder is under attack, it MAY choose to prefer previously authenticated peers who present a Session Resumption ticket (see [RFC5723] for details). 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 Section 4.3.2. of [RFC5723]. Note that the Responder SHOULD cache tickets for a short time to reject reused tickets (Section 4.3.1), and therefore there should be no issue of 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 a malicious peer to perform an attack, described in Section 3 - it can just send a garbage in the IKE_AUTH message thus forcing the Responder to perform CPU costly operations to compute SK_* keys. If the received IKE_AUTH message failed to decrypt correctly (or @@ -490,24 +493,35 @@ providing an URL pointing to a large file possibly containing garbage. While downloading the file the responder consumes CPU, memory and network bandwidth. To prevent this kind of attacks 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 by analyzing the first few bytes, if they - are DER-encoded. Implementations SHOULD also apply a configurable - hard limit to the number of pulled bytes and SHOULD provide an - ability for an administrator to either completely disable this - feature or to limit its use to a configurable list of trusted URLs. + are DER-encoded. However, since the content of the file being + downloaded can be under attacker's control, implementations should + not blindly trust the decoded length and SHOULD check whether it + makes sense before continue downloading. Implementations SHOULD also + apply a configurable hard limit to the number of pulled bytes and + SHOULD provide an ability for an administrator to either completely + disable this feature or to limit its use to a configurable list of + trusted URLs. + +4.8. IKE Fragmentation + + IKE Fragmentation described in [RFC7383] allows IKE peers to avoid IP + fragmentation of large IKE messages. Attackers can mount several + kinds of DoS attacks using IKE Fragmentation. See Section 5 of + [RFC7383] for details. 5. Defense Measures after IKE SA is created Once IKE SA is created there is usually not 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 are typically no more than a few such exchanges, often less. Some of these exchanges require relatively little resources (like liveness check), while others may be resource consuming (like creating or @@ -515,21 +529,21 @@ Since any endpoint can initiate a 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 behavior may be caused by buggy implementation, misconfiguration or be intentional. The latter becomes more of a real threat if the peer uses NULL Authentication, described in [RFC7619]. In this case the peer remains anonymous, allowing it to escape any responsibility for its - actions. + actions. See Section 3 of [RFC7619] for details. 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 could increase host resource consumption. Since currently there is no way in IKEv2 to decrease window size once it was increased (see Section 2.3 of @@ -542,33 +556,44 @@ 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 an artificial delay before - responding to request messages. This delay would decrease the + responding to each request message. This delay would decrease the rate the implementation need to process requests from any particular peer, making it possible to process requests from the - others. The delay should not be too long to avoid causing the 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. + others. Note, that if the Responder receives retransmissions of + the request message during the delay period, the retransmitted + messages should be silently discarded. The delay should not be + too long to avoid causing the IKE SA to be deleted on the other + end due to timeout. It is believed that a few seconds is enough. + Note however, that even a few seconds may be too long in those + settings, that rely on immediate response to the request message, + e.g. for the purposes of quick detection of a dead peer. o If these counter-measures are inefficient, implementations can delete the IKE SA with an offending peer by sending Delete Payload. + In IKEv2 client can request various configuration attributes from + server. Most often those attributes include internal IP addresses. + Malicious clients can try to exhaust server's IP address pool by + continuously requesting a large number of internal addresses. Server + implementations SHOULD limit the number of IP addresses allocated to + any particular client. Note, that it is not possible with clients + using NULL Authentication, since their identity cannot be verified. + 6. Plan for Defending a Responder This section outlines a plan for defending a Responder from a DDoS attack based on the techniques described earlier. The numbers given here are not normative, and their purpose is to illustrate the configurable parameters needed for defeating the DDoS attack. Implementations may be deployed in different environments, so it is RECOMMENDED that the parameters be settable. As an example, most commercial products are required to undergo benchmarking where the @@ -1219,21 +1243,21 @@ e.g. mobile phones or some IoT devices. If puzzles are hard then the required additional power consumption may appear to be unacceptable for some Initiators. The Responder SHOULD take this possibility into considerations while choosing the puzzles difficulty and while selecting which percentage of Initiators are allowed to reject solving puzzles. See Section 7.1.4 for details. If the Initiator uses NULL Authentication [RFC7619] then its identity is never verified, that may be used by attackers to perform DoS attack after IKE SA is established. Responders that allow - unauthenticated Initiators to connect must be prepared deal with + unauthenticated Initiators to connect must be prepared to deal with various kinds of DoS attacks even after IKE SA is created. See Section 5 for details. To prevent amplification attacks implementations must strictly follow the retransmission rules described in Section 2.1 of [RFC7296]. 11. IANA Considerations This document defines a new payload in the "IKEv2 Payload Types" registry: