Protecting Internet Key Exchange (IKE) Implementations from Denial of Service Attacks through Client PuzzlesCheck Point Software Technologies Ltd.5 Hasolelim st.Tel Aviv6789735Israelynir.ietf@gmail.com
Security Area
IPSecME Working GroupInternet-Draft This document describes an enhancement to the Stateless Cookie mechanism described in RFC 5996. Whereas the original mechanism prevents denial-of-service (DoS) attacks that use multiple spoofed source addresses, the mechanism here is effective against a distributed denial of service attack (DDoS), where the attackers use their own source address. This is accomplished by requiring proof of work by the Initiator before allocating resources at the Responder. The Initial Exchange described in section 1.2 of involves the Initiator sending a single message. The Responder also sends a single message, but also allocates state for a structure called a half-open IKE SA (Security Association). This half-open SA is later authenticated in the Authentication Exchange, but if that exchange doesn't come, the half-open SA is kept for an unspecified amount of time. This creates an easy attack vector against an Internet Key Exchange (IKE) Responder. Generating the Initial request is cheap, and sending multiple such requests can either cause the Responder to allocate too much resources and fail, or else if resource allocation is limited, legitimate Initiators would also be prevented from setting up IKE SAs. An obvious defense is limiting the number of half-open SAs opened by a single peer. However, since all that is required is a single packet, an attacker can use multiple spoofed source IP addresses. Section 2.6 of RFC 5996 offers a mechanism to mitigate this DoS attack: the stateless cookie. When the server is under load, the Responder responds to the Initial request with a calculated "stateless cookie" - a value that can be re-calculated based on values in the Initial request without storing Responder-side state. The Initiator is expected to repeat the Initial request, this time including the stateless cookie. This mechanism is not effective against attackers that have multiple source IP addresses with return routability, such as bot-nets. The mechanism described here adds a proof of work for the Initiator, by partially breaking a hash function. This sets an upper bound, determined by the attacker's CPU to the number of negotiations it can force the Responder to participate in.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 . As described in section 2.6 of RFC 5996, when a responder detects a large number of half-open IKE SAs, it SHOULD reply to IKE_SA_INIT requests with a response containing the COOKIE notification. When the number of half-open SAs gets even higher, so that there is a danger of degraded ability to reply to legitimate initiations, the responder SHOULD switch to sending puzzles instead of cookies. The puzzle is described in . The answer to the puzzle is the value to be returned in the Cookie notification. The Initiator solves the puzzle, figures out what the stateless cookie is, and re-initiates as described in RFC 5996 with the Cookie notification carrying the answer to the puzzle. This section details the notification format for the puzzle. This notification is sent from Responder to the Initiator. See for Operational Considerations in enabling this feature. Protocol ID is set to zero. SPI Size is set to zero. Puzzle Message Type is set to xxxxx, the value assigned by IANA for the PUZZLE notification. Cookie Hash (32 bytes) is the SHA2-256 hash of the stateless cookie. Puzzle len (1 byte) is the number of unknown bits in the Masked Cookie field. Masked Cookie (arbitrary length) is the stateless cookie that the Initiator is expected to return. The length is determined by the Payload Length field. The final n bits MUST be set to zero, where n is the number in the Puzzle Size field. The Responder sets a difficulty level to a number of bits. See for considerations in setting this difficulty level. To construct this payload, the Responder first calculates the stateless cookie using the same procedure from RFC 5996. The responder then calculates the SHA2-256 hash of this stateless cookie to create the Cookie Hash field. The difficulty level is then placed in the Puzzle Size field. Finally, the last n bits (where n is the difficulty level) are zero'd out in the stateless cookie, and it is copied into the Masked Cookie field. To solve the puzzle, the Initiator repeatedly attempts to complete the final n bits of the Masked Cookie, hashing each attempt until one is found where the hash matches the Cookie Hash field. The Initiator then begins the Initial exchange again, this time including the Cookie Notification. The entire exchange is below: [This section needs a lot of expanding] Not all Initiators support this extension, but all initiators are supposed to support stateless cookies. If this notification is sent to a non-supporting but legitimate initiator, the exchange will fail. Responders are advised to first try to mitigate the DoS using stateless cookies, and only if the number of half-open SAs keeps increasing, switch to using this mechanism. The difficulty level should be set by balancing the requirement to minimize the latency for legitimate initiators and making things difficult for attackers. A good rule of thumb is for taking about 1 second to solve the puzzle. A typical initiator or bot-net member in 2014 can perform slightly less than a million hashes per second per core, so setting the difficulty level to n=20 is a good compromise. It should be noted that mobile initiators, especially phones are considerably weaker than that. Implementations should allow administrators to set the difficulty level, and/or be able to set the difficulty level dynamically in response to load. 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 the administrator or user. To be added. IANA is requested to assign a notify message type from the status types range (16430-40959) of the "IKEv2 Notify Message Types - Status Types" registry with name "PUZZLE".Key words for use in RFCs to Indicate Requirement LevelsHarvard University1350 Mass. Ave.CambridgeMA 02138- +1 617 495 3864sob@harvard.edu
General
keywordInternet Key Exchange Protocol Version 2 (IKEv2)