idnits 2.17.1 draft-nir-ipsecme-puzzles-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 29, 2014) is 3622 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'CERTREQ' is mentioned on line 191, but not defined ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPSecME Working Group Y. Nir 3 Internet-Draft Check Point 4 Intended status: Standards Track April 29, 2014 5 Expires: October 31, 2014 7 Protecting Internet Key Exchange (IKE) Implementations from Denial of 8 Service Attacks through Client Puzzles 9 draft-nir-ipsecme-puzzles-00 11 Abstract 13 This document describes an enhancement to the Stateless Cookie 14 mechanism described in RFC 5996. Whereas the original mechanism 15 prevents denial-of-service (DoS) attacks that use multiple spoofed 16 source addresses, the mechanism here is effective against a 17 distributed denial of service attack (DDoS), where the attackers use 18 their own source address. This is accomplished by requiring proof of 19 work by the Initiator before allocating resources at the Responder. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on October 31, 2014. 38 Copyright Notice 40 Copyright (c) 2014 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Conventions Used in This Document . . . . . . . . . . . . . 3 57 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Puzzle Notification Format . . . . . . . . . . . . . . . . . . 4 59 4. Operational Considerations . . . . . . . . . . . . . . . . . . 5 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 62 7. Normative References . . . . . . . . . . . . . . . . . . . . . 6 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 1. Introduction 67 The Initial Exchange described in section 1.2 of [RFC5996] involves 68 the Initiator sending a single message. The Responder also sends a 69 single message, but also allocates state for a structure called a 70 half-open IKE SA (Security Association). This half-open SA is later 71 authenticated in the Authentication Exchange, but if that exchange 72 doesn't come, the half-open SA is kept for an unspecified amount of 73 time. 75 This creates an easy attack vector against an Internet Key Exchange 76 (IKE) Responder. Generating the Initial request is cheap, and 77 sending multiple such requests can either cause the Responder to 78 allocate too much resources and fail, or else if resource allocation 79 is limited, legitimate Initiators would also be prevented from 80 setting up IKE SAs. 82 An obvious defense is limiting the number of half-open SAs opened by 83 a single peer. However, since all that is required is a single 84 packet, an attacker can use multiple spoofed source IP addresses. 86 Section 2.6 of RFC 5996 offers a mechanism to mitigate this DoS 87 attack: the stateless cookie. When the server is under load, the 88 Responder responds to the Initial request with a calculated 89 "stateless cookie" - a value that can be re-calculated based on 90 values in the Initial request without storing Responder-side state. 91 The Initiator is expected to repeat the Initial request, this time 92 including the stateless cookie. 94 This mechanism is not effective against attackers that have multiple 95 source IP addresses with return routability, such as bot-nets. 97 The mechanism described here adds a proof of work for the Initiator, 98 by partially breaking a hash function. This sets an upper bound, 99 determined by the attacker's CPU to the number of negotiations it can 100 force the Responder to participate in. 102 1.1. Conventions Used in This Document 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in [RFC2119]. 108 2. Protocol Overview 110 As described in section 2.6 of RFC 5996, when a responder detects a 111 large number of half-open IKE SAs, it SHOULD reply to IKE_SA_INIT 112 requests with a response containing the COOKIE notification. When 113 the number of half-open SAs gets even higher, so that there is a 114 danger of degraded ability to reply to legitimate initiations, the 115 responder SHOULD switch to sending puzzles instead of cookies. The 116 puzzle is described in Section 3. The answer to the puzzle is the 117 value to be returned in the Cookie notification. 119 The Initiator solves the puzzle, figures out what the stateless 120 cookie is, and re-initiates as described in RFC 5996 with the Cookie 121 notification carrying the answer to the puzzle. 123 3. Puzzle Notification Format 125 This section details the notification format for the puzzle. This 126 notification is sent from Responder to the Initiator. See Section 4 127 for Operational Considerations in enabling this feature. 129 1 2 3 130 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 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 ! Next Payload !C! RESERVED ! Payload Length ! 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 ! Protocol ID ! SPI Size ! Puzzle Message Type ! 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | | 137 | | 138 | Cookie Hash | 139 | | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 ! Puzzle Size ! ! 142 +-+-+-+-+-+-+-+-+ | 143 | | 144 | | 145 | Masked Cookie | 146 | | 147 | | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 o Protocol ID is set to zero. 151 o SPI Size is set to zero. 152 o Puzzle Message Type is set to xxxxx, the value assigned by IANA 153 for the PUZZLE notification. 154 o Cookie Hash (32 bytes) is the SHA2-256 hash of the stateless 155 cookie. 156 o Puzzle len (1 byte) is the number of unknown bits in the Masked 157 Cookie field. 159 o Masked Cookie (arbitrary length) is the stateless cookie that the 160 Initiator is expected to return. The length is determined by the 161 Payload Length field. The final n bits MUST be set to zero, where 162 n is the number in the Puzzle Size field. 164 The Responder sets a difficulty level to a number of bits. See 165 Section 4 for considerations in setting this difficulty level. 167 To construct this payload, the Responder first calculates the 168 stateless cookie using the same procedure from RFC 5996. The 169 responder then calculates the SHA2-256 hash of this stateless cookie 170 to create the Cookie Hash field. The difficulty level is then placed 171 in the Puzzle Size field. Finally, the last n bits (where n is the 172 difficulty level) are zero'd out in the stateless cookie, and it is 173 copied into the Masked Cookie field. 175 To solve the puzzle, the Initiator repeatedly attempts to complete 176 the final n bits of the Masked Cookie, hashing each attempt until one 177 is found where the hash matches the Cookie Hash field. 179 The Initiator then begins the Initial exchange again, this time 180 including the Cookie Notification. 182 The entire exchange is below: 184 Initiator Responder 185 ------------------------------------------------------------------- 186 HDR(A,0), SAi1, KEi, Ni --> 187 <-- HDR(A,0), N(PUZZLE) 188 HDR(A,0), N(COOKIE), SAi1, 189 KEi, Ni --> 190 <-- HDR(A,B), SAr1, KEr, 191 Nr, [CERTREQ] 192 HDR(A,B), SK {IDi, [CERT,] 193 [CERTREQ,] [IDr,] AUTH, 194 SAi2, TSi, TSr} --> 195 <-- HDR(A,B), SK {IDr, [CERT,] 196 AUTH, SAr2, TSi, TSr} 198 4. Operational Considerations 200 [This section needs a lot of expanding] 202 Not all Initiators support this extension, but all initiators are 203 supposed to support stateless cookies. If this notification is sent 204 to a non-supporting but legitimate initiator, the exchange will fail. 205 Responders are advised to first try to mitigate the DoS using 206 stateless cookies, and only if the number of half-open SAs keeps 207 increasing, switch to using this mechanism. 209 The difficulty level should be set by balancing the requirement to 210 minimize the latency for legitimate initiators and making things 211 difficult for attackers. A good rule of thumb is for taking about 1 212 second to solve the puzzle. A typical initiator or bot-net member in 213 2014 can perform slightly less than a million hashes per second per 214 core, so setting the difficulty level to n=20 is a good compromise. 215 It should be noted that mobile initiators, especially phones are 216 considerably weaker than that. Implementations should allow 217 administrators to set the difficulty level, and/or be able to set the 218 difficulty level dynamically in response to load. 220 Initiators should set a maximum difficulty level beyond which they 221 won't try to solve the puzzle and log or display a failure message to 222 the administrator or user. 224 5. Security Considerations 226 To be added. 228 6. IANA Considerations 230 IANA is requested to assign a notify message type from the status 231 types range (16430-40959) of the "IKEv2 Notify Message Types - Status 232 Types" registry with name "PUZZLE". 234 7. Normative References 236 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 237 Requirement Levels", BCP 14, RFC 2119, March 1997. 239 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 240 "Internet Key Exchange Protocol Version 2 (IKEv2)", 241 RFC 5996, September 2010. 243 Author's Address 245 Yoav Nir 246 Check Point Software Technologies Ltd. 247 5 Hasolelim st. 248 Tel Aviv 6789735 249 Israel 251 Email: ynir.ietf@gmail.com