draft-ietf-ipsecme-ddos-protection-04.txt		draft-ietf-ipsecme-ddos-protection-05.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: September 2, 2016 ELVIS-PLUS		Expires: September 22, 2016 ELVIS-PLUS
	March 1, 2016		March 21, 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-04		draft-ietf-ipsecme-ddos-protection-05
	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 September 2, 2016.		This Internet-Draft will expire on September 22, 2016.
	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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. The Stateless Cookie . . . . . . . . . . . . . . . . . . 3		2. Conventions Used in This Document . . . . . . . . . . . . . . 3
	1.2. Conventions Used in This Document . . . . . . . . . . . . 4		3. The Vulnerability . . . . . . . . . . . . . . . . . . . . . . 3
	2. The Vulnerability . . . . . . . . . . . . . . . . . . . . . . 4		4. Defense Measures while IKE SA is being created . . . . . . . 6
	3. Puzzles . . . . . . . . . . . . . . . . . . . . . . . . . . . 6		4.1. Retention Periods for Half-Open SAs . . . . . . . . . . . 6
	4. Retention Periods for Half-Open SAs . . . . . . . . . . . . . 8		4.2. Rate Limiting . . . . . . . . . . . . . . . . . . . . . . 6
	5. Rate Limiting . . . . . . . . . . . . . . . . . . . . . . . . 9		4.3. The Stateless Cookie . . . . . . . . . . . . . . . . . . 7
	6. Plan for Defending a Responder . . . . . . . . . . . . . . . 10		4.4. Puzzles . . . . . . . . . . . . . . . . . . . . . . . . . 8
	6.1. Session Resumption . . . . . . . . . . . . . . . . . . . 12		4.5. Session Resumption . . . . . . . . . . . . . . . . . . . 10
	7. Using Puzzles in the Protocol . . . . . . . . . . . . . . . . 12		4.6. Keeping computed Shared Keys . . . . . . . . . . . . . . 10
	7.1. Puzzles in IKE_SA_INIT Exchange . . . . . . . . . . . . . 12		4.7. Preventing Attacks using "Hash and URL" Certificate
	7.1.1. Presenting Puzzle . . . . . . . . . . . . . . . . . . 13		Encoding . . . . . . . . . . . . . . . . . . . . . . . . 11
	7.1.2. Solving Puzzle and Returning the Solution . . . . . . 15		5. Defense Measures after IKE SA is created . . . . . . . . . . 11
	7.1.3. Computing Puzzle . . . . . . . . . . . . . . . . . . 16		6. Plan for Defending a Responder . . . . . . . . . . . . . . . 12
	7.1.4. Analyzing Repeated Request . . . . . . . . . . . . . 16		7. Using Puzzles in the Protocol . . . . . . . . . . . . . . . . 14
	7.1.5. Making Decision whether to Serve the Request . . . . 18		7.1. Puzzles in IKE_SA_INIT Exchange . . . . . . . . . . . . . 15
	7.2. Puzzles in IKE_AUTH Exchange . . . . . . . . . . . . . . 19		7.1.1. Presenting Puzzle . . . . . . . . . . . . . . . . . . 15
	7.2.1. Presenting Puzzle . . . . . . . . . . . . . . . . . . 19		7.1.2. Solving Puzzle and Returning the Solution . . . . . . 18
	7.2.2. Solving Puzzle and Returning the Solution . . . . . . 20		7.1.3. Computing Puzzle . . . . . . . . . . . . . . . . . . 18
	7.2.3. Computing Puzzle . . . . . . . . . . . . . . . . . . 21		7.1.4. Analyzing Repeated Request . . . . . . . . . . . . . 19
	7.2.4. Receiving Puzzle Solution . . . . . . . . . . . . . . 21		7.1.5. Making Decision whether to Serve the Request . . . . 20
	8. DoS Protection after IKE SA is created . . . . . . . . . . . 22		7.2. Puzzles in IKE_AUTH Exchange . . . . . . . . . . . . . . 21
	9. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 23		7.2.1. Presenting Puzzle . . . . . . . . . . . . . . . . . . 22
	9.1. PUZZLE Notification . . . . . . . . . . . . . . . . . . . 23		7.2.2. Solving Puzzle and Returning the Solution . . . . . . 22
	9.2. Puzzle Solution Payload . . . . . . . . . . . . . . . . . 24		7.2.3. Computing Puzzle . . . . . . . . . . . . . . . . . . 23
	10. Operational Considerations . . . . . . . . . . . . . . . . . 24		7.2.4. Receiving Puzzle Solution . . . . . . . . . . . . . . 23
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 25		8. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 24
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26		8.1. PUZZLE Notification . . . . . . . . . . . . . . . . . . . 24
	13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26		8.2. Puzzle Solution Payload . . . . . . . . . . . . . . . . . 25
	14. References . . . . . . . . . . . . . . . . . . . . . . . . . 26		9. Operational Considerations . . . . . . . . . . . . . . . . . 26
	14.1. Normative References . . . . . . . . . . . . . . . . . . 26		10. Security Considerations . . . . . . . . . . . . . . . . . . . 26
	14.2. Informative References . . . . . . . . . . . . . . . . . 27		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27		12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
			13. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
			13.1. Normative References . . . . . . . . . . . . . . . . . . 27
			13.2. Informative References . . . . . . . . . . . . . . . . . 28
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
	1. Introduction		1. Introduction
	Denial of Service (DoS) attacks have always been considered a serious		Denial of Service (DoS) attacks have always been considered a serious
	threat. These attacks are usually difficult to defend against since		threat. These attacks are usually difficult to defend against since
	the amount of resources the victim has is always bounded (regardless		the amount of resources the victim has is always bounded (regardless
	of how high it is) and because some resources are required for		of how high it is) and because some resources are required for
	distinguishing a legitimate session from an attack.		distinguishing a legitimate session from an attack.
	The Internet Key Exchange protocol (IKE) described in [RFC7296]		The Internet Key Exchange protocol version 2 (IKEv2) described in
	includes defense against DoS attacks. In particular, there is a		[RFC7296] includes defense against DoS attacks. In particular, there
	cookie mechanism that allows the IKE Responder to effectively defend		is a cookie mechanism that allows the IKE Responder to effectively
	itself against DoS attacks from spoofed IP-addresses. However, bot-		defend itself against DoS attacks from spoofed IP-addresses.
	nets have become widespread, allowing attackers to perform		However, bot-nets have become widespread, allowing attackers to
	Distributed Denial of Service (DDoS) attacks, which are more		perform Distributed Denial of Service (DDoS) attacks, which are more
	difficult to defend against. This document presents recommendations		difficult to defend against. This document presents recommendations
	to help the Responder thwart (D)DoS attacks. It also introduces a		to help the Responder thwart (D)DoS attacks. It also introduces a
	new mechanism -- "puzzles" -- that can help accomplish this task.		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].
			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
	implementation, such a half-open SA will use from around 100 bytes to		implementation, such a half-open SA will use from around 100 bytes to
	several thousands bytes of memory.		several thousands bytes of memory.
	This creates an easy attack vector against an IKE Responder.		This creates an easy attack vector against an IKE Responder.
	Generating the IKE_SA_INIT request is cheap, and sending multiple		Generating the IKE_SA_INIT request is cheap, and sending multiple
	such requests can either cause the Responder to allocate too much		such requests can either cause the Responder to allocate too much
	resources and fail, or else if resource allocation is somehow		resources and fail, or else if resource allocation is somehow
	throttled, legitimate Initiators would also be prevented from setting		throttled, legitimate Initiators would also be prevented from setting
	up IKE SAs.		up IKE SAs.
	An obvious defense, which is described in Section 5, is limiting the		An obvious defense, which is described in Section 4.2, is limiting
	number of half-open SAs opened by a single peer. However, since all		the number of half-open SAs opened by a single peer. However, since
	that is required is a single packet, an attacker can use multiple		all that is required is a single packet, an attacker can use multiple
	spoofed source IP addresses.		spoofed source IP addresses.
	1.1. The Stateless Cookie
	Section 2.6 of [RFC7296] offers a mechanism to mitigate this 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.
	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-
	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.
	The mechanism described in Section 3 adds a proof of work for the
	Initiator by calculating a pre-image for a partial hash value. This
	sets an upper bound, determined by the attacker's CPU, to the number
	of negotiations it can initiate in a unit of time.
	1.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].
	2. The Vulnerability
	If we break down what a Responder has to do during an initial		If we break down what a Responder has to do during an initial
	exchange, there are three stages:		exchange, there are three stages:
	1. When the IKE_SA_INIT request arrives, the Responder:		1. When the IKE_SA_INIT request arrives, the Responder:
	* Generates or re-uses a Diffie-Hellman (D-H) private part.		* Generates or re-uses a Diffie-Hellman (D-H) private part.
	* Generates a Responder Security Parameter Index (SPI).		* Generates a Responder Security Parameter Index (SPI).
	* Stores the private part and peer public part in a half-open SA		* Stores the private part and peer public part in a half-open SA
	skipping to change at page 5, line 20 ¶		skipping to change at page 4, line 46 ¶
	There are obvious ways for the Responder to protect itself even		There are obvious ways for the Responder to protect itself even
	without changes to the protocol. It can reduce the time that an		without changes to the protocol. It can reduce the time that an
	entry remains in the half-open SA database, and it can limit the		entry remains in the half-open SA database, and it can limit the
	amount of concurrent half-open SAs from a particular address or		amount of concurrent half-open SAs from a particular address or
	prefix. The attacker can overcome this by using spoofed source		prefix. The attacker can overcome this by using spoofed source
	addresses.		addresses.
	The stateless cookie mechanism from Section 2.6 of [RFC7296] prevents		The stateless cookie mechanism from Section 2.6 of [RFC7296] prevents
	an attack with spoofed source addresses. This doesn't completely		an attack with spoofed source addresses. This doesn't completely
	solve the issue, but it makes the limiting of half-open SAs by		solve the issue, but it makes the limiting of half-open SAs by
	address or prefix work. Puzzles do the same thing only more of it.		address or prefix work. Puzzles, introduced in Section 4.4, do the
	They make it harder for an attacker to reach the goal of getting a		same thing only more of it. They make it harder for an attacker to
	half-open SA. They don't have to be so hard that an attacker can't		reach the goal of getting a half-open SA. They don't have to be so
	afford to solve a single puzzle; it's enough that they increase the		hard that an attacker can't afford to solve a single puzzle; it's
	cost of a half-open SAs for the attacker so that it can create only a		enough that they increase the cost of a half-open SAs for the
	few.		attacker so that it can create only a few.
	Reducing the amount of time an abandoned half-open SA is kept attacks		Reducing the amount of time an abandoned half-open SA is kept attacks
	the issue from the other side. It reduces the value the attacker		the issue from the other side. It reduces the value the attacker
	gets from managing to create a half-open SA. For example, if a half-		gets from managing to create a half-open SA. For example, if a half-
	open SA is kept for 1 minute and the capacity is 60,000 half-open		open SA is kept for 1 minute and the capacity is 60,000 half-open
	SAs, an attacker would need to create 1,000 half-open SAs per second.		SAs, an attacker would need to create 1,000 half-open SAs per second.
	Reduce the retention time to 3 seconds, and the attacker needs to		Reduce the retention time to 3 seconds, and the attacker needs to
	create 20,000 half-open SAs per second. By introducing a puzzle,		create 20,000 half-open SAs per second. By introducing a puzzle,
	each half-open SA becomes more expensive for an attacker, making it		each half-open SA becomes more expensive for an attacker, making it
	more likely to thwart an exhaustion attack against Responder memory.		more likely to thwart an exhaustion attack against Responder memory.
	skipping to change at page 6, line 8 ¶		skipping to change at page 5, line 35 ¶
	It's probably better left to Intrusion Prevention System (IPS)		It's probably better left to Intrusion Prevention System (IPS)
	technology.		technology.
	On the other hand, sending an IKE_AUTH request is surprisingly cheap.		On the other hand, sending an IKE_AUTH request is surprisingly cheap.
	It requires a proper IKE header with the correct IKE SPIs, and it		It requires a proper IKE header with the correct IKE SPIs, and it
	requires a single Encrypted payload. The content of the payload		requires a single Encrypted payload. The content of the payload
	might as well be junk. The Responder has to perform the relatively		might as well be junk. The Responder has to perform the relatively
	expensive key derivation, only to find that the MAC on the Encrypted		expensive key derivation, only to find that the MAC on the Encrypted
	payload on the IKE_AUTH request does not check. Depending on the		payload on the IKE_AUTH request does not check. Depending on the
	Responder implementation, this can be repeated with the same half-		Responder implementation, this can be repeated with the same half-
	open SA (if the Responder does not delete the half-open SA following		open SA. Puzzles can make attacks of such sort more costly for an
	an unsuccessful decryption - see discussion in Section 4).		attacker. See Section 7.2 for details.
	Here too, the number of half-open SAs that the attacker can achieve		Here too, the number of half-open SAs that the attacker can achieve
	is crucial, because each one allows the attacker to waste some CPU		is crucial, because each one allows the attacker to waste some CPU
	time. So making it hard to make many half-open SAs is important.		time. So making it hard to make many half-open SAs is important.
	A strategy against DDoS has to rely on at least 4 components:		A strategy against DDoS has to rely on at least 4 components:
	1. Hardening the half-open SA database by reducing retention time.		1. Hardening the half-open SA database by reducing retention time.
	2. Hardening the half-open SA database by rate-limiting single IPs/		2. Hardening the half-open SA database by rate-limiting single IPs/
	prefixes.		prefixes.
	3. Guidance on what to do when an IKE_AUTH request fails to decrypt.		3. Guidance on what to do when an IKE_AUTH request fails to decrypt.
	4. Increasing cost of half-open SA up to what is tolerable for		4. Increasing cost of half-open SA up to what is tolerable for
	legitimate clients.		legitimate clients.
	Puzzles have their place as part of #4.		Puzzles have their place as part of #4.
	3. Puzzles		4. Defense Measures while IKE SA is being created
			4.1. Retention Periods for Half-Open SAs
			As a UDP-based protocol, IKEv2 has to deal with packet loss through
			retransmissions. Section 2.4 of [RFC7296] recommends "that messages
			be retransmitted at least a dozen times over a period of at least
			several minutes before giving up". Retransmission policies in
			practice wait at least one or two seconds before retransmitting for
			the first time.
			Because of this, setting the timeout on a half-open SA too low will
			cause it to expire whenever even one IKE_AUTH request packet is lost.
			When not under attack, the half-open SA timeout SHOULD be set high
			enough that the Initiator will have enough time to send multiple
			retransmissions, minimizing the chance of transient network
			congestion causing IKE failure.
			When the system is under attack, as measured by the amount of half-
			open SAs, it makes sense to reduce this lifetime. The Responder
			should still allow enough time for the round-trip, enough time for
			the Initiator to derive the D-H shared value, and enough time to
			derive the IKE SA keys and the create the IKE_AUTH request. Two
			seconds is probably as low a value as can realistically be used.
			It could make sense to assign a shorter value to half-open SAs
			originating from IP addresses or prefixes that are considered suspect
			because of multiple concurrent half-open SAs.
			4.2. Rate Limiting
			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.
			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.
			2. Soft Limit - where if a set number of half-open SAs exist for a
			particular address or prefix, any IKE_SA_INIT request will
			require solving a puzzle.
			The advantage of the hard limit method is that it provides a hard cap
			on the amount of half-open SAs that the attacker is able to create.
			The downside is that it allows the attacker to block IKE initiation
			from small parts of the Internet. For example, if an network service
			provider or some establishment offers Internet connectivity to its
			customers or employees through an IPv4 NAT device, a single malicious
			customer can create enough half-open SAs to fill the quota for the
			NAT device external IP address. Legitimate Initiators on the same
			network will not be able to initiate IKE.
			The advantage of a soft limit is that legitimate clients can always
			connect. The disadvantage is that an adversary with sufficient CPU
			resources can still effectively DoS the Responder.
			Regardless of the type of rate-limiting used, there is a huge
			advantage in blocking the DoS attack using rate-limiting for
			legitimate clients that are away from the attacking nodes. In such
			cases, adverse impacts caused by the attack or by the measures used
			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.
			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-
			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		The puzzle introduced here extends the cookie mechanism from
	[RFC7296]. It is loosely based on the proof-of-work technique used		[RFC7296]. It is loosely based on the proof-of-work technique used
	in Bitcoins [bitcoins].		in Bitcoins [bitcoins]. This sets an upper bound, determined by the
			attacker's CPU, to the number of negotiations it can initiate in a
			unit of time.
	A puzzle is sent to the Initiator in two cases:		A puzzle is sent to the Initiator in two cases:
	o The Responder is so overloaded that no half-open SAs may be		o The Responder is so overloaded that no half-open SAs may be
	created without solving a puzzle, or		created without solving a puzzle, or
	o The Responder is not too loaded, but the rate-limiting method		o The Responder is not too loaded, but the rate-limiting method
	described in Section 5 prevents half-open SAs from being created		described in Section 4.2 prevents half-open SAs from being created
	with this particular peer address or prefix without first solving		with this particular peer address or prefix without first solving
	a puzzle.		a puzzle.
	When the Responder decides to send the challenge notification in		When the Responder decides to send the challenge notification in
	response to a IKE_SA_INIT request, the notification includes three		response to a IKE_SA_INIT request, the notification includes three
	fields:		fields:
	1. Cookie - this is calculated the same as in [RFC7296], i.e. the		1. Cookie - this is calculated the same as in [RFC7296], i.e. the
	process of generating the cookie is not specified.		process of generating the cookie is not specified.
	skipping to change at page 8, line 45 ¶		skipping to change at page 10, line 29 ¶
	Table 2: The time needed to solve a puzzle of various difficulty for		Table 2: The time needed to solve a puzzle of various difficulty for
	the cookie = 739ae7492d8a810cf5e8dc0f9626c9dda773c5a3		the cookie = 739ae7492d8a810cf5e8dc0f9626c9dda773c5a3
	The figures above were obtained on a 2.4 GHz single core i5. Run		The figures above were obtained on a 2.4 GHz single core i5. Run
	times can be halved or quartered with multi-core code, but would be		times can be halved or quartered with multi-core code, but would be
	longer on mobile phone processors, even if those are multi-core as		longer on mobile phone processors, even if those are multi-core as
	well. With these figures 18 bits is believed to be a reasonable		well. With these figures 18 bits is believed to be a reasonable
	choice for puzzle level difficulty for all Initiators, and 20 bits is		choice for puzzle level difficulty for all Initiators, and 20 bits is
	acceptable for specific hosts/prefixes.		acceptable for specific hosts/prefixes.
	4. Retention Periods for Half-Open SAs		Using puzzles mechanism in the IKE_SA_INIT exchange is described in
			Section 7.1.
	As a UDP-based protocol, IKEv2 has to deal with packet loss through		4.5. Session Resumption
	retransmissions. Section 2.4 of [RFC7296] recommends "that messages
	be retransmitted at least a dozen times over a period of at least
	several minutes before giving up". Retransmission policies in
	practice wait at least one or two seconds before retransmitting for
	the first time.
	Because of this, setting the timeout on a half-open SA too low will		When the Responder is under attack, it MAY choose to prefer
	cause it to expire whenever even one IKE_AUTH request packet is lost.		previously authenticated peers who present a Session Resumption
	When not under attack, the half-open SA timeout SHOULD be set high		ticket (see [RFC5723] for details). The Responder MAY require such
	enough that the Initiator will have enough time to send multiple		Initiators to pass a return routability check by including the COOKIE
	retransmissions, minimizing the chance of transient network		notification in the IKE_SESSION_RESUME response message, as allowed
	congestion causing IKE failure.		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.
	When the system is under attack, as measured by the amount of half-		4.6. Keeping computed Shared Keys
	open SAs, it makes sense to reduce this lifetime. The Responder
	should still allow enough time for the round-trip, enough time for
	the Initiator to derive the D-H shared value, and enough time to
	derive the IKE SA keys and the create the IKE_AUTH request. Two
	seconds is probably as low a value as can realistically be used.
	It could make sense to assign a shorter value to half-open SAs		Once the IKE_SA_INIT exchange is finished, the Responder is waiting
	originating from IP addresses or prefixes that are considered suspect		for the first message of the IKE_AUTH exchange from the Initiator.
	because of multiple concurrent half-open SAs.		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.
	5. Rate Limiting		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 the
			malicious Initiator 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.
	Even with DDoS, the attacker has only a limited amount of nodes		4.7. Preventing Attacks using "Hash and URL" Certificate Encoding
	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		In IKEv2 each side may use "Hash and URL" Certificate Encoding to
	IP address. Most IPv4 nodes are either directly attached to the		instruct the peer to retrieve certificates from the specified
	Internet using a routable address or are hidden behind a NAT device		location (see Section 3.6 of [RFC7296] for details). Malicious
	with a single IPv4 external address. IPv6 networks are currently a		initiators can use this feature to mount a DoS attack on responder by
	rarity, so we can only speculate on what their wide deployment will		providing an URL pointing to a large file possibly containing
	be like, but the current thinking is that ISP customers will be		garbage. While downloading the file the responder consumes CPU,
	assigned whole subnets, so we don't expect the kind of NAT deployment		memory and network bandwidth.
	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.
	The number of half-open SAs is easy to measure, but it is also		To prevent this kind of attacks the responder should not blindly
	worthwhile to measure the number of failed IKE_AUTH exchanges. If		download the whole file. Instead it SHOULD first read the initial
	possible, both factors should be taken into account when deciding		few bytes, decode the length of the ASN.1 structure from these bytes,
	which IP address or prefix is considered suspicious.		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.
	There are two ways to rate-limit a peer address or prefix:		5. Defense Measures after IKE SA is created
	1. Hard Limit - where the number of half-open SAs is capped, and any		Once IKE SA is created there is usually not much traffic over it. In
	further IKE_SA_INIT requests are rejected.		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
			rekeying Child SA with D-H exchange).
	2. Soft Limit - where if a set number of half-open SAs exist for a		Since any endpoint can initiate a new exchange, there is a
	particular address or prefix, any IKE_SA_INIT request will		possibility that a peer would initiate too many exchanges that could
	require solving a puzzle.		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.
	The advantage of the hard limit method is that it provides a hard cap		The following recommendations for defense against possible DoS
	on the amount of half-open SAs that the attacker is able to create.		attacks after IKE SA is established are mostly intended for
	The downside is that it allows the attacker to block IKE initiation		implementations that allow unauthenticated IKE sessions; however,
	from small parts of the Internet. For example, if an network service		they may also be useful in other cases.
	provider or some establishment offers Internet connectivity to its
	customers or employees through an IPv4 NAT device, a single malicious
	customer can create enough half-open SAs to fill the quota for the
	NAT device external IP address. Legitimate Initiators on the same
	network will not be able to initiate IKE.
	The advantage of a soft limit is that legitimate clients can always		o If the IKEv2 window size is greater than one, then the peer could
	connect. The disadvantage is that an adversary with sufficient CPU		initiate multiple simultaneous exchanges that could increase host
	resources can still effectively DoS the Responder.		resource consumption. Since currently there is no way in IKEv2 to
			decrease window size once it was increased (see Section 2.3 of
			[RFC7296]), the window size cannot be dynamically adjusted
			depending on the load. For that reason, it is NOT RECOMMENDED to
			ever increase the IKEv2 window size above its default value of one
			if the peer uses NULL Authentication.
	Regardless of the type of rate-limiting used, there is a huge		o If the peer initiates requests to rekey IKE SA or Child SA too
	advantage in blocking the DoS attack using rate-limiting for		often, implementations can respond to some of these requests with
	legitimate clients that are away from the attacking nodes. In such		the TEMPORARY_FAILURE notification, indicating that the request
	cases, adverse impacts caused by the attack or by the measures used		should be retried after some period of time.
	to counteract the attack can be avoided.
			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
			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.
			o If these counter-measures are inefficient, implementations can
			delete the IKE SA with an offending peer by sending Delete
			Payload.
	6. Plan for Defending a Responder		6. Plan for Defending a Responder
	This section outlines a plan for defending a Responder from a DDoS		This section outlines a plan for defending a Responder from a DDoS
	attack based on the techniques described earlier. The numbers given		attack based on the techniques described earlier. The numbers given
	here are not normative, and their purpose is to illustrate the		here are not normative, and their purpose is to illustrate the
	configurable parameters needed for defeating the DDoS attack.		configurable parameters needed for defeating the DDoS attack.
	Implementations may be deployed in different environments, so it is		Implementations may be deployed in different environments, so it is
	RECOMMENDED that the parameters be settable. As an example, most		RECOMMENDED that the parameters be settable. As an example, most
	skipping to change at page 12, line 21 ¶		skipping to change at page 14, line 39 ¶
	If the load on the Responder is still too great, and there are many		If the load on the Responder is still too great, and there are many
	nodes causing multiple half-open SAs or IKE_AUTH failures, the		nodes causing multiple half-open SAs or IKE_AUTH failures, the
	Responder MAY impose hard limits on those nodes.		Responder MAY impose hard limits on those nodes.
	If it turns out that the attack is very widespread and the hard caps		If it turns out that the attack is very widespread and the hard caps
	are not solving the issue, a puzzle MAY be imposed on all Initiators.		are not solving the issue, a puzzle MAY be imposed on all Initiators.
	Note that this is the last step, and the Responder should avoid this		Note that this is the last step, and the Responder should avoid this
	if possible.		if possible.
	6.1. Session Resumption
	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.
	7. Using Puzzles in the Protocol		7. Using Puzzles in the Protocol
	This section describes how the puzzle mechanism is used in IKEv2. It		This section describes how the puzzle mechanism is used in IKEv2. It
	is organized as follows. The Section 7.1 describes using puzzles in		is organized as follows. The Section 7.1 describes using puzzles in
	the IKE_SA_INIT exchange and the Section 7.2 describes using puzzles		the IKE_SA_INIT exchange and the Section 7.2 describes using puzzles
	in the IKE_AUTH exchange. Both sections are divided into subsections		in the IKE_AUTH exchange. Both sections are divided into subsections
	describing how puzzles should be presented, solved and processed by		describing how puzzles should be presented, solved and processed by
	the Initiator and the Responder.		the Initiator and the Responder.
	7.1. Puzzles in IKE_SA_INIT Exchange		7.1. Puzzles in IKE_SA_INIT Exchange
	skipping to change at page 13, line 27 ¶		skipping to change at page 15, line 39 ¶
	don't contain the COOKIE notification MUST NOT participate in this		don't contain the COOKIE notification MUST NOT participate in this
	lottery. In other words, the Responder must first perform return		lottery. In other words, the Responder must first perform return
	routability check before allowing any legacy client to be served if		routability check before allowing any legacy client to be served if
	it is under attack. See Section 7.1.4 for details.		it is under attack. See Section 7.1.4 for details.
	7.1.1. Presenting Puzzle		7.1.1. Presenting Puzzle
	If the Responder makes a decision to use puzzles, then it MUST		If the Responder makes a decision to use puzzles, then it MUST
	include two notifications in its response message - the COOKIE		include two notifications in its response message - the COOKIE
	notification and the PUZZLE notification. The format of the PUZZLE		notification and the PUZZLE notification. The format of the PUZZLE
	notification is described in Section 9.1.		notification is described in Section 8.1.
	<-- HDR, N(COOKIE), N(PUZZLE), [V+][N+]		<-- HDR, N(COOKIE), N(PUZZLE), [V+][N+]
	The presence of these notifications in an IKE_SA_INIT response		The presence of these notifications in an IKE_SA_INIT response
	message indicates to the Initiator that it should solve the puzzle to		message indicates to the Initiator that it should solve the puzzle to
	get better chances to be served.		get better chances to be served.
	7.1.1.1. Selecting Puzzle Difficulty Level		7.1.1.1. Selecting Puzzle Difficulty Level
	The PUZZLE notification contains the difficulty level of the puzzle -		The PUZZLE notification contains the difficulty level of the puzzle -
	skipping to change at page 16, line 5 ¶		skipping to change at page 18, line 22 ¶
	difficulty, even if it supports puzzles. In both cases the Initiator		difficulty, even if it supports puzzles. In both cases the Initiator
	acts as described in Section 2.6 of [RFC7296] - it restarts the		acts as described in Section 2.6 of [RFC7296] - it restarts the
	request and includes the received COOKIE notification into it. The		request and includes the received COOKIE notification into it. The
	Responder should be able to distinguish the situation when it just		Responder should be able to distinguish the situation when it just
	requested a cookie from the situation when the puzzle was given to		requested a cookie from the situation when the puzzle was given to
	the Initiator, but the Initiator for some reason ignored it.		the Initiator, but the Initiator for some reason ignored it.
	If the received message contains a PUZZLE notification and doesn't		If the received message contains a PUZZLE notification and doesn't
	contain a COOKIE notification, then this message is malformed because		contain a COOKIE notification, then this message is malformed because
	it requests to solve the puzzle, but doesn't provide enough		it requests to solve the puzzle, but doesn't provide enough
	information to do it. In this case the Initiator SHOULD resend		information to do it. In this case the Initiator MUST ignore the
	IKE_SA_INIT request. If this situation repeats several times, then		received message and continue to wait until either the valid one is
	it means that something is wrong and the IKE SA cannot be		received or the retransmission timer fires. If it fails to receive
	established.		the valid message after several retransmissions of IKE_SA_INIT
			request, then it means that something is wrong and the IKE SA cannot
			be established.
	If the Initiator supports puzzles and is ready to deal with them,		If the Initiator supports puzzles and is ready to deal with them,
	then it tries to solve the given puzzle. After the puzzle is solved		then it tries to solve the given puzzle. After the puzzle is solved
	the Initiator restarts the request and returns the puzzle solution in		the Initiator restarts the request and returns the puzzle solution in
	a new payload called a Puzzle Solution payload (denoted as PS, see		a new payload called a Puzzle Solution payload (denoted as PS, see
	Section 9.2) along with the received COOKIE notification back to the		Section 8.2) along with the received COOKIE notification back to the
	Responder.		Responder.
	HDR, N(COOKIE), [PS,] SA, KE, Ni, [V+][N+] -->		HDR, N(COOKIE), [PS,] SA, KE, Ni, [V+][N+] -->
	7.1.3. Computing Puzzle		7.1.3. Computing Puzzle
	General principals of constructing puzzles in IKEv2 are described in		General principals of constructing puzzles in IKEv2 are described in
	Section 3. They can be summarized as follows: given unpredictable		Section 4.4. They can be summarized as follows: given unpredictable
	string S and pseudo-random function PRF find N different keys Ki		string S and pseudo-random function PRF find N different keys Ki
	(where i=[1..N]) for that PRF so that the result of PRF(Ki,S) has at		(where i=[1..N]) for that PRF so that the result of PRF(Ki,S) has at
	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 contains 4 different keys		requires that the solution to the puzzle contains 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 IKE_SA_INIT the task for		unpredictable string S. In other words, in IKE_SA_INIT the task for
	the IKE Initiator is to find the four different, equal-sized keys Ki		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		for the agreed upon PRF such that each result of PRF(Ki,cookie) where
	skipping to change at page 19, line 13 ¶		skipping to change at page 21, line 27 ¶
	priority and the available resources.		priority and the available resources.
	7.2. Puzzles in IKE_AUTH Exchange		7.2. Puzzles in IKE_AUTH Exchange
	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
	return routability check and has proved that it has performed some		return routability check and has proved that it has performed some
	work to complete IKE_SA_INIT exchange. However, the Initiator is not		work to complete IKE_SA_INIT exchange. However, the Initiator is not
	yet authenticated and this fact allows malicious Initiator to perform		yet authenticated and this fact allows malicious Initiator to perform
	an attack, described in Section 2. Unlike DoS attack in IKE_SA_INIT		an attack, described in Section 3. Unlike DoS attack in IKE_SA_INIT
	exchange, which is targeted on the Responder's memory resources, the		exchange, which is targeted on the Responder's memory resources, the
	goal of this attack is to exhaust a Responder's CPU power. 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		attack is performed by sending the first IKE_AUTH message containing
	garbage. This costs nothing to the Initiator, but the Responder has		garbage. This costs nothing to the Initiator, but the Responder has
	to do relatively costly operations of computing the D-H shared secret		to do relatively costly operations of computing the D-H shared secret
	and deriving SK_* keys to be able to verify authenticity of the		and deriving SK_* keys to be able to verify authenticity of the
	message. If the Responder doesn't keep the computed keys after an		message. If the Responder doesn't keep the computed keys after an
	unsuccessful verification of the IKE_AUTH message, then the attack		unsuccessful verification of the IKE_AUTH message, then the attack
	can be repeated several times on the same IKE SA.		can be repeated several times on the same IKE SA.
	skipping to change at page 22, line 7 ¶		skipping to change at page 24, line 21 ¶
	first IKE Fragment messages before receiving the first one,		first IKE Fragment messages before receiving the first one,
	containing the PS payload. In this case the Responder MAY choose to		containing the PS payload. In this case the Responder MAY choose to
	keep the received fragments until the first fragment containing the		keep the received fragments until the first fragment containing the
	solution to the puzzle is received. However, in this case the		solution to the puzzle is received. However, in this case the
	Responder SHOULD NOT try to verify authenticity of the kept fragments		Responder SHOULD NOT try to verify authenticity of the kept fragments
	until the first fragment with the PS payload is received and the		until the first fragment with the PS payload is received and the
	solution to the puzzle is verified. After successful verification of		solution to the puzzle is verified. After successful verification of
	the puzzle the Responder could calculate the SK_* key and verify		the puzzle the Responder could calculate the SK_* key and verify
	authenticity of the collected fragments.		authenticity of the collected fragments.
	8. DoS Protection after IKE SA is created		8. Payload Formats
	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
	rekeying Child SA with D-H exchange).
	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.
	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
	[RFC7296]), the window size cannot be dynamically adjusted
	depending on the load. For that reason, it is NOT RECOMMENDED to
	ever increase the IKEv2 window size above its default value of one
	if the peer uses NULL Authentication.
	o If the peer initiates requests to rekey IKE SA or Child SA too
	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
	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.
	o If these counter-measures are inefficient, implementations can
	delete the IKE SA with an offending peer by sending Delete
	Payload.
	9. Payload Formats
	9.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 necessity to solve the puzzle. It contains the		Initiator about the necessity 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
	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		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Next Payload |C| RESERVED | Payload Length |		| Next Payload |C| RESERVED | Payload Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 24, line 11 ¶		skipping to change at page 25, line 14 ¶
	o Difficulty (1 octet) -- Difficulty Level of the puzzle. Specifies		o Difficulty (1 octet) -- Difficulty Level of the puzzle. Specifies
	minimum number of trailing zero bits (ZBC), that each of the		minimum number of trailing zero bits (ZBC), that each of the
	results of PRF must contain. Value 0 means that the Responder		results of PRF must contain. Value 0 means that the Responder
	doesn't request any specific difficulty level and the Initiator is		doesn't request any specific difficulty level and the Initiator is
	free to select appropriate difficulty level on its own (see		free to select appropriate difficulty level on its own (see
	Section 7.1.1.1 for details).		Section 7.1.1.1 for details).
	This notification contains no data.		This notification contains no data.
	9.2. Puzzle Solution Payload		8.2. Puzzle Solution Payload
	The solution to the puzzle is returned back to the Responder in a		The solution to the puzzle is returned back to the Responder in a
	dedicated payload, called the Puzzle Solution payload and denoted as		dedicated payload, called the Puzzle Solution payload and denoted as
	PS in this document.		PS in this document.
	1 2 3		1 2 3
	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		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Next Payload |C| RESERVED | Payload Length |		| Next Payload |C| RESERVED | Payload Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 24, line 46 ¶		skipping to change at page 26, line 5 ¶
	(or even less) octets in length, however it depends on puzzle		(or even less) octets in length, however it depends on puzzle
	difficulty and on the Initiator's strategy to find solutions, and		difficulty and on the Initiator's strategy to find solutions, and
	thus the size is not mandated by this specification. The		thus the size is not mandated by this specification. The
	Responder determines the size of each key by dividing the size of		Responder determines the size of each key by dividing the size of
	the Puzzle Solution Data by 4 (the number of keys). Note that the		the Puzzle Solution Data by 4 (the number of keys). Note that the
	size of Puzzle Solution Data is the size of Payload (as indicated		size of Puzzle Solution Data is the size of Payload (as indicated
	in Payload Length field) minus 4 - the size of Payload Header.		in Payload Length field) minus 4 - the size of Payload Header.
	The payload type for the Puzzle Solution payload is <TBA by IANA>.		The payload type for the Puzzle Solution payload is <TBA by IANA>.
	10. Operational Considerations		9. Operational Considerations
	The difficulty level should be set by balancing the requirement to		The difficulty level should be set by balancing the requirement to
	minimize the latency for legitimate Initiators and making things		minimize the latency for legitimate Initiators and making things
	difficult for attackers. A good rule of thumb is for taking about 1		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		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		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.		core, so setting the difficulty level to n=20 is a good compromise.
	It should be noted that mobile Initiators, especially phones are		It should be noted that mobile Initiators, especially phones are
	considerably weaker than that. Implementations should allow		considerably weaker than that. Implementations should allow
	administrators to set the difficulty level, and/or be able to set the		administrators to set the difficulty level, and/or be able to set the
	difficulty level dynamically in response to load.		difficulty level dynamically in response to load.
	Initiators should set a maximum difficulty level beyond which they		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		won't try to solve the puzzle and log or display a failure message to
	the administrator or user.		the administrator or user.
	11. Security Considerations		10. Security Considerations
	When selecting parameters for the puzzles, in particular the puzzle		When selecting parameters for the puzzles, in particular the puzzle
	difficulty, care must be taken. If the puzzles appeared too easy for		difficulty, care must be taken. If the puzzles appeared too easy for
	majority of the attackers, then the puzzles mechanism wouldn't be		majority of the attackers, then the puzzles mechanism wouldn't be
	able to prevent DoS attack and would only impose an additional burden		able to prevent DoS attack and would only impose an additional burden
	on the legitimate Initiators. On the other hand, if the puzzles		on the legitimate Initiators. On the other hand, if the puzzles
	appeared to be too hard for majority of the Initiators then many		appeared to be too hard for majority of the Initiators then many
	legitimate users would experience unacceptable delay in IKE SA setup		legitimate users would experience unacceptable delay in IKE SA setup
	(or unacceptable power consumption on mobile devices), that might		(or unacceptable power consumption on mobile devices), that might
	cause them to cancel connection attempt. In this case the resources		cause them to cancel connection attempt. In this case the resources
	skipping to change at page 25, line 49 ¶		skipping to change at page 27, line 7 ¶
	for some Initiators. The Responder SHOULD take this possibility into		for some Initiators. The Responder SHOULD take this possibility into
	considerations while choosing the puzzles difficulty and while		considerations while choosing the puzzles difficulty and while
	selecting which percentage of Initiators are allowed to reject		selecting which percentage of Initiators are allowed to reject
	solving puzzles. See Section 7.1.4 for details.		solving puzzles. See Section 7.1.4 for details.
	If the Initiator uses NULL Authentication [RFC7619] then its identity		If the Initiator uses NULL Authentication [RFC7619] then its identity
	is never verified, that may be used by attackers to perform DoS		is never verified, that may be used by attackers to perform DoS
	attack after IKE SA is established. Responders that allow		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 deal with
	various kinds of DoS attacks even after IKE SA is created. See		various kinds of DoS attacks even after IKE SA is created. See
	Section 8 for details.		Section 5 for details.
	12. IANA Considerations		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"		This document defines a new payload in the "IKEv2 Payload Types"
	registry:		registry:
	<TBA> Puzzle Solution PS		<TBA> Puzzle Solution PS
	This document also defines a new Notify Message Type in the "IKEv2		This document also defines a new Notify Message Type in the "IKEv2
	Notify Message Types - Status Types" registry:		Notify Message Types - Status Types" registry:
	<TBA> PUZZLE		<TBA> PUZZLE
	13. Acknowledgements		12. Acknowledgements
	The authors thank Tero Kivinen, Yaron Sheffer and Scott Fluhrer for		The authors thank Tero Kivinen, Yaron Sheffer and Scott Fluhrer for
	their contribution into design of the protocol. In particular, Tero		their contribution into design of the protocol. In particular, Tero
	Kivinen suggested the kind of puzzle where the task is to find a		Kivinen suggested the kind of puzzle where the task is to find a
	solution with requested number of zero trailing bits. Yaron Sheffer		solution with requested number of zero trailing bits. Yaron Sheffer
	and Scott Fluhrer suggested a way to make puzzle difficulty less		and Scott Fluhrer suggested a way to make puzzle difficulty less
	erratic by solving several weaker puzles. The authors also thank		erratic by solving several weaker puzles. The authors also thank
	David Waltermire for his carefull review of the draft and all others		David Waltermire for his carefull review of the document, Graham
	who commented the document.		Bartlett for pointing out to the possibility of "Hash & URL" related
			attack, and all others who commented the document.
	14. References		13. References
	14.1. Normative References		13.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.		[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
	Kivinen, "Internet Key Exchange Protocol Version 2		Kivinen, "Internet Key Exchange Protocol Version 2
	(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October		(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
	2014, <http://www.rfc-editor.org/info/rfc7296>.		2014, <http://www.rfc-editor.org/info/rfc7296>.
	[RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2		[RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2
	(IKEv2) Message Fragmentation", RFC 7383,		(IKEv2) Message Fragmentation", RFC 7383,
	DOI 10.17487/RFC7383, November 2014,		DOI 10.17487/RFC7383, November 2014,
	<http://www.rfc-editor.org/info/rfc7383>.		<http://www.rfc-editor.org/info/rfc7383>.
	[IKEV2-IANA]		[IKEV2-IANA]
	"Internet Key Exchange Version 2 (IKEv2) Parameters",		"Internet Key Exchange Version 2 (IKEv2) Parameters",
	<http://www.iana.org/assignments/ikev2-parameters>.		<http://www.iana.org/assignments/ikev2-parameters>.
	14.2. Informative References		13.2. Informative References
	[bitcoins]		[bitcoins]
	Nakamoto, S., "Bitcoin: A Peer-to-Peer Electronic Cash		Nakamoto, S., "Bitcoin: A Peer-to-Peer Electronic Cash
	System", October 2008, <https://bitcoin.org/bitcoin.pdf>.		System", October 2008, <https://bitcoin.org/bitcoin.pdf>.
	[RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange		[RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange
	Protocol Version 2 (IKEv2) Session Resumption", RFC 5723,		Protocol Version 2 (IKEv2) Session Resumption", RFC 5723,
	DOI 10.17487/RFC5723, January 2010,		DOI 10.17487/RFC5723, January 2010,
	<http://www.rfc-editor.org/info/rfc5723>.		<http://www.rfc-editor.org/info/rfc5723>.
End of changes. 46 change blocks.
	244 lines changed or deleted		293 lines changed or added
This html diff was produced by rfcdiff 1.44. The latest version is available from http://tools.ietf.org/tools/rfcdiff/