< draft-ietf-ipsecme-ddos-protection-03.txt		draft-ietf-ipsecme-ddos-protection-04.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: June 18, 2016 ELVIS-PLUS		Expires: September 2, 2016 ELVIS-PLUS
	December 16, 2015		March 1, 2016
	Protecting Internet Key Exchange (IKE) Implementations from Distributed		Protecting Internet Key Exchange Protocol version 2 (IKEv2)
	Denial of Service Attacks		Implementations from Distributed Denial of Service Attacks
	draft-ietf-ipsecme-ddos-protection-03		draft-ietf-ipsecme-ddos-protection-04
	Abstract		Abstract
	This document recommends implementation and configuration best		This document recommends implementation and configuration best
	practices for Internet-connected IPsec Responders, to allow them to		practices for Internet Key Exchange Protocol version 2 (IKEv2)
	resist Denial of Service and Distributed Denial of Service attacks.		Responders, to allow them to resist Denial of Service and Distributed
	Additionally, the document introduces a new mechanism called "Client		Denial of Service attacks. Additionally, the document introduces a
	Puzzles" that help accomplish this task.		new mechanism called "Client Puzzles" that help accomplish this task.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 June 18, 2016.		This Internet-Draft will expire on September 2, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 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
	skipping to change at page 2, line 24 ¶		skipping to change at page 2, line 24 ¶
	4. Retention Periods for Half-Open SAs . . . . . . . . . . . . . 8		4. Retention Periods for Half-Open SAs . . . . . . . . . . . . . 8
	5. Rate Limiting . . . . . . . . . . . . . . . . . . . . . . . . 9		5. Rate Limiting . . . . . . . . . . . . . . . . . . . . . . . . 9
	6. Plan for Defending a Responder . . . . . . . . . . . . . . . 10		6. Plan for Defending a Responder . . . . . . . . . . . . . . . 10
	6.1. Session Resumption . . . . . . . . . . . . . . . . . . . 12		6.1. Session Resumption . . . . . . . . . . . . . . . . . . . 12
	7. Using Puzzles in the Protocol . . . . . . . . . . . . . . . . 12		7. Using Puzzles in the Protocol . . . . . . . . . . . . . . . . 12
	7.1. Puzzles in IKE_SA_INIT Exchange . . . . . . . . . . . . . 12		7.1. Puzzles in IKE_SA_INIT Exchange . . . . . . . . . . . . . 12
	7.1.1. Presenting Puzzle . . . . . . . . . . . . . . . . . . 13		7.1.1. Presenting Puzzle . . . . . . . . . . . . . . . . . . 13
	7.1.2. Solving Puzzle and Returning the Solution . . . . . . 15		7.1.2. Solving Puzzle and Returning the Solution . . . . . . 15
	7.1.3. Computing Puzzle . . . . . . . . . . . . . . . . . . 16		7.1.3. Computing Puzzle . . . . . . . . . . . . . . . . . . 16
	7.1.4. Analyzing Repeated Request . . . . . . . . . . . . . 16		7.1.4. Analyzing Repeated Request . . . . . . . . . . . . . 16
	7.1.5. Making Decision whether to Serve the Request . . . . 17		7.1.5. Making Decision whether to Serve the Request . . . . 18
	7.2. Puzzles in IKE_AUTH Exchange . . . . . . . . . . . . . . 18		7.2. Puzzles in IKE_AUTH Exchange . . . . . . . . . . . . . . 19
	7.2.1. Presenting Puzzle . . . . . . . . . . . . . . . . . . 19		7.2.1. Presenting Puzzle . . . . . . . . . . . . . . . . . . 19
	7.2.2. Solving Puzzle and Returning the Solution . . . . . . 20		7.2.2. Solving Puzzle and Returning the Solution . . . . . . 20
	7.2.3. Computing Puzzle . . . . . . . . . . . . . . . . . . 20		7.2.3. Computing Puzzle . . . . . . . . . . . . . . . . . . 21
	7.2.4. Receiving Puzzle Solution . . . . . . . . . . . . . . 21		7.2.4. Receiving Puzzle Solution . . . . . . . . . . . . . . 21
	8. DoS Protection after IKE SA is created . . . . . . . . . . . 21		8. DoS Protection after IKE SA is created . . . . . . . . . . . 22
	9. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 22		9. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 23
	9.1. PUZZLE Notification . . . . . . . . . . . . . . . . . . . 23		9.1. PUZZLE Notification . . . . . . . . . . . . . . . . . . . 23
	9.2. Puzzle Solution Payload . . . . . . . . . . . . . . . . . 23		9.2. Puzzle Solution Payload . . . . . . . . . . . . . . . . . 24
	10. Operational Considerations . . . . . . . . . . . . . . . . . 24		10. Operational Considerations . . . . . . . . . . . . . . . . . 24
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 24		11. Security Considerations . . . . . . . . . . . . . . . . . . . 25
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25		12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . 25		13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
	13.1. Normative References . . . . . . . . . . . . . . . . . . 25		14. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
	13.2. Informative References . . . . . . . . . . . . . . . . . 26		14.1. Normative References . . . . . . . . . . . . . . . . . . 26
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26		14.2. Informative References . . . . . . . . . . . . . . . . . 27
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
	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 (IKE) described in [RFC7296]
	skipping to change at page 6, line 33 ¶		skipping to change at page 6, line 37 ¶
	Puzzles have their place as part of #4.		Puzzles have their place as part of #4.
	3. Puzzles		3. 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].
	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, then no half-open SAs are allowed		o The Responder is so overloaded that no half-open SAs may be
	to be created without the 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 5 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:
	skipping to change at page 7, line 20 ¶		skipping to change at page 7, line 24 ¶
	create a puzzle that is too easy to solve for it to make any		create a puzzle that is too easy to solve for it to make any
	difference in mitigating DDoS attacks. Since the mechanism is		difference in mitigating DDoS attacks. Since the mechanism is
	supposed to be stateless for the Responder, either the same ZBC		supposed to be stateless for the Responder, either the same ZBC
	is used for all Initiators, or the ZBC is somehow encoded in the		is used for all Initiators, or the ZBC is somehow encoded in the
	cookie. If it is global then it means that this value is the		cookie. If it is global then it means that this value is the
	same for all the Initiators who are receiving puzzles at any		same for all the Initiators who are receiving puzzles at any
	given point of time. The Responder, however, may change this		given point of time. The Responder, however, may change this
	value over time depending on its load.		value over time depending on its load.
	Upon receiving this challenge, the Initiator attempts to calculate		Upon receiving this challenge, the Initiator attempts to calculate
	the PRF using different keys. When a key is found such that the		the PRF using different keys. When enough keys are found such that
	resulting PRF output has a sufficient number of trailing zero bits,		the resulting PRF output calculated using each of them has a
	that result is sent to the Responder.		sufficient number of trailing zero bits, that result is sent to the
			Responder.
			The reason for using several keys in the results rather than just one
			key is to reduce the variance in the time it takes the initiator to
			solve the puzzle. We have chosen the number of keys to be four (4)
			as a compromise between the conflicting goals of reducing variance
			and reducing the work the Responder needs to perform to verify the
			puzzle solution.
	When receiving a request with a solved puzzle, the Responder verifies		When receiving a request with a solved puzzle, the Responder verifies
	two things:		two things:
	o That the cookie part is indeed valid.		o That the cookie part is indeed valid.
	o That the PRF of the transmitted cookie calculated with the		o That the PRFs of the transmitted cookie calculated with the
	transmitted key has a sufficient number of trailing zero bits.		transmitted keys has a sufficient number of trailing zero bits.
	Example 1: Suppose the calculated cookie is		Example 1: Suppose the calculated cookie is
	fdbcfa5a430d7201282358a2a034de0013cfe2ae (20 octets), the algorithm		739ae7492d8a810cf5e8dc0f9626c9dda773c5a3 (20 octets), the algorithm
	is HMAC-SHA256, and the required number of zero bits is 18. After		is PRF-HMAC-SHA256, and the required number of zero bits is 18.
	successively trying a bunch of keys, the Initiator finds that the key		After successively trying a bunch of keys, the Initiator finds the
	that is all-zero except for the last three bytes which are 02fc95		following four 3-octet keys that work:
	yields HMAC_SHA256(k, cookie) =
	843ab73f35c5b431b1d8f80bedcd1cb9ef46832f799c1d4250a49f683c580000,
	which has 19 trailing zero bits, so it is an acceptable solution.
	Example 2: Same cookie, but this time the required number of zero		+--------+----------------------------------+----------+
	bits is 22. The first key to satisfy that requirement ends in		| Key | Last 32 Hex PRF Digits | # 0-bits |
	960cbb, which yields a hash with 23 trailing zero bits. Finding this		+--------+----------------------------------+----------+
	requires 9,833,659 invocations of the PRF.		| 061840 | e4f957b859d7fb1343b7b94a816c0000 | 18 |
			| 073324 | 0d4233d6278c96e3369227a075800000 | 23 |
			| 0c8a2a | 952a35d39d5ba06709da43af40700000 | 20 |
			| 0d94c8 | 5a0452b21571e401a3d00803679c0000 | 18 |
			+--------+----------------------------------+----------+
	+----------+--------------------------+--------+--------------------+		Table 1: Three solutions for 18-bit puzzle
	| Key | Last 24 Hex PRF Digits | # | Time to Calculate |
	| | | 0-bits | (seconds) |
	+----------+--------------------------+--------+--------------------+
	| 00 | 0cbbbd1e105f5a177f9697d4 | 2 | 0.000 |
	| 08 | 34cdedf89560f600aab93c68 | 3 | 0.000 |
	| 0b | 6153a5131b879a904cd7fbe0 | 5 | 0.000 |
	| 2b | 0098af3e9422aa40a6f7b140 | 6 | 0.000 |
	| 0147 | c8bf4a65fc8b974046b97c00 | 10 | 0.001 |
	| 06e2 | 541487a10cbdf3b21c382800 | 11 | 0.005 |
	| 0828 | 48719bd62393fcf9bc172000 | 13 | 0.006 |
	| 0204a7 | 3dce3414477c2364d5198000 | 15 | 0.186 |
	| 185297 | c19385bb7b9566e5fdf00000 | 20 | 2.146 |
	| 69dc34 | 1b61ecb347cb2e0cba200000 | 21 | 9.416 |
	| 960cbb | e48274bfac2b7e1930800000 | 23 | 13.300 |
	| 01597972 | 39a0141d0fe4b87aea000000 | 25 | 30.749 |
	| 0b13cd9a | 00b97bb323d6d33350000000 | 28 | 247.914 |
	| 37dc96e4 | 1e24babc92234aa3a0000000 | 29 | 1237.170 |
	| 7a1a56d8 | c98f0061e380a49e00000000 | 33 | 2726.150 |
	+----------+--------------------------+--------+--------------------+
	Table 1: The time needed to solve a puzzle of various difficulty for		Example 2: Same cookie, but modify the required number of zero bits
	the cookie = fdbcfa5a430d7201282358a2a034de0013cfe2ae		to 22. The first 4-octet keys that work to satisfy that requirement
			are 005d9e57, 010d8959, 0110778d, and 01187e37. Finding these
			requires 18,382,392 invocations of the PRF.
			+----------+-------------------------------+
			| # 0-bits | Time to Find 4 keys (seconds) |
			+----------+-------------------------------+
			| 8 | 0.0025 |
			| 10 | 0.0078 |
			| 12 | 0.0530 |
			| 14 | 0.2521 |
			| 16 | 0.8504 |
			| 17 | 1.5938 |
			| 18 | 3.3842 |
			| 19 | 3.8592 |
			| 20 | 10.8876 |
			+----------+-------------------------------+
			Table 2: The time needed to solve a puzzle of various difficulty for
			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 20 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, with 24 bits		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		4. Retention Periods for Half-Open SAs
	As a UDP-based protocol, IKEv2 has to deal with packet loss through		As a UDP-based protocol, IKEv2 has to deal with packet loss through
	retransmissions. Section 2.4 of [RFC7296] recommends "that messages		retransmissions. Section 2.4 of [RFC7296] recommends "that messages
	be retransmitted at least a dozen times over a period of at least		be retransmitted at least a dozen times over a period of at least
	several minutes before giving up". Retransmission policies in		several minutes before giving up". Retransmission policies in
	practice wait at least one or two seconds before retransmitting for		practice wait at least one or two seconds before retransmitting for
	the first time.		the first time.
	skipping to change at page 9, line 51 ¶		skipping to change at page 10, line 12 ¶
	1. Hard Limit - where the number of half-open SAs is capped, and any		1. Hard Limit - where the number of half-open SAs is capped, and any
	further IKE_SA_INIT requests are rejected.		further IKE_SA_INIT requests are rejected.
	2. Soft Limit - where if a set number of half-open SAs exist for a		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		particular address or prefix, any IKE_SA_INIT request will
	require solving a puzzle.		require solving a puzzle.
	The advantage of the hard limit method is that it provides a hard cap		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.		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		The downside is that it allows the attacker to block IKE initiation
	from small parts of the Internet. For example, if a certain purveyor		from small parts of the Internet. For example, if an network service
	of beverages resembling coffee provides Internet connectivity to its		provider or some establishment offers Internet connectivity to its
	customers through an IPv4 NAT device, a single malicious customer can		customers or employees through an IPv4 NAT device, a single malicious
	create enough half-open SAs to fill the quota for the NAT device		customer can create enough half-open SAs to fill the quota for the
	external IP address. Legitimate Initiators on the same network will		NAT device external IP address. Legitimate Initiators on the same
	not be able to initiate IKE.		network will not be able to initiate IKE.
	The advantage of a soft limit is that legitimate clients can always		The advantage of a soft limit is that legitimate clients can always
	connect. The disadvantage is that an adversary with sufficient CPU		connect. The disadvantage is that an adversary with sufficient CPU
	resources can still effectively DoS the Responder.		resources can still effectively DoS the Responder.
	Regardless of the type of rate-limiting used, there is a huge		Regardless of the type of rate-limiting used, there is a huge
	advantage in blocking the DoS attack using rate-limiting in that		advantage in blocking the DoS attack using rate-limiting for
	legitimate clients who are away from the attacking nodes should not		legitimate clients that are away from the attacking nodes. In such
	be adversely affected by either the attack or by the measures used to		cases, adverse impacts caused by the attack or by the measures used
	counteract it.		to counteract the attack can be avoided.
	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 13, line 48 ¶		skipping to change at page 14, line 7 ¶
	0, meaning that the Initiator is requested to spend as much power to		0, meaning that the Initiator is requested to spend as much power to
	solve puzzle, as it can afford. In this case no specific value of		solve puzzle, as it can afford. In this case no specific value of
	ZBC is required from the Initiator, however the larger the ZBC that		ZBC is required from the Initiator, however the larger the ZBC that
	Initiator is able to get, the better the chances it will have to be		Initiator is able to get, the better the chances it will have to be
	served by the Responder. In diverse environments it is RECOMMENDED		served by the Responder. In diverse environments it is RECOMMENDED
	that the Initiator sets difficulty level to 0, unless the attack		that the Initiator sets difficulty level to 0, unless the attack
	volume is very high.		volume is very high.
	If the Responder sets non-zero difficulty level, then the level		If the Responder sets non-zero difficulty level, then the level
	should be determined by analyzing the volume of the attack. The		should be determined by analyzing the volume of the attack. The
	Responder MAY set different difficulty levels to different requested		Responder MAY set different difficulty levels to different requests
	depending on the IP address the request has come from.		depending on the IP address the request has come from.
	7.1.1.2. Selecting Puzzle Algorithm		7.1.1.2. Selecting Puzzle Algorithm
	The PUZZLE notification also contains identifier of the algorithm,		The PUZZLE notification also contains identifier of the algorithm,
	that must be used by Initiator to compute puzzle.		that must be used by Initiator to compute puzzle.
	Cryptographic algorithm agility is considered an important feature		Cryptographic algorithm agility is considered an important feature
	for modern protocols ([RFC7696]). This feature ensures that protocol		for modern protocols ([RFC7696]). This feature ensures that protocol
	doesn't rely on a single build-in set of cryptographic algorithms,		doesn't rely on a single build-in set of cryptographic algorithms,
	but has a means to replace one set with another and negotiate new set		but has a means to replace one set with another and negotiate new set
	with the peer. IKEv2 fully supports cryptographic algorithm agility		with the peer. IKEv2 fully supports cryptographic algorithm agility
	for its core operations.		for its core operations.
	To support this feature in case of puzzles the algorithm, that is		To support this feature in case of puzzles, the algorithm that is
	used to compute puzzle, needs to be negotiated during IKE_SA_INIT		used to compute puzzle needs to be negotiated during IKE_SA_INIT
	exchange. The negotiation is done as follows. The initial request		exchange. The negotiation is performed as follows. The initial
	message sent by Initiator contains SA payload with the list of		request message sent by Initiator contains SA payload with the list
	transforms the Initiator supports and is willing to use in the IKE SA		of transforms the Initiator supports and is willing to use in the IKE
	being established. The Responder parses received SA payload and		SA being established. The Responder parses received SA payload and
	finds mutually supported set of transforms of type PRF. It selects		finds mutually supported set of transforms of type PRF. It selects
	most preferred transform from this set and includes it into the		most preferred transform from this set and includes it into the
	PUZZLE notification. There is no requirement that the PRF selected		PUZZLE notification. There is no requirement that the PRF selected
	for puzzles be the same, as the PRF that is negotiated later for the		for puzzles be the same, as the PRF that is negotiated later for the
	use in core IKE SA crypto operations. If there are no mutually		use in core IKE SA crypto operations. If there are no mutually
	supported PRFs, then negotiation will fail anyway and there is no		supported PRFs, then negotiation will fail anyway and there is no
	reason to return a puzzle. In this case the Responder returns		reason to return a puzzle. In this case the Responder returns
	NO_PROPOSAL_CHOSEN notification. Note that PRF is a mandatory		NO_PROPOSAL_CHOSEN notification. Note that PRF is a mandatory
	transform type for IKE SA (see Sections 3.3.2 and 3.3.3 of [RFC7296])		transform type for IKE SA (see Sections 3.3.2 and 3.3.3 of [RFC7296])
	and at least one transform of this type must always be present in SA		and at least one transform of this type must always be present in SA
	payload in IKE_SA_INIT exchange.		payload in IKE_SA_INIT request message.
	7.1.1.3. Generating Cookie		7.1.1.3. Generating Cookie
	If Responder supports puzzles then cookie should be computed in such		If Responder supports puzzles then cookie should be computed in such
	a manner, that the Responder is able to learn some important		a manner, that the Responder is able to learn some important
	information from the sole cookie, when it is later returned back by		information from the sole cookie, when it is later returned back by
	Initiator. In particular - the Responder should be able to learn the		Initiator. In particular - the Responder should be able to learn the
	following information:		following information:
	o Whether the puzzle was given to the Initiator or only the cookie		o Whether the puzzle was given to the Initiator or only the cookie
	skipping to change at page 15, line 23 ¶		skipping to change at page 15, line 28 ¶
	this information in returned cookie is detectable. So, the cookie		this information in returned cookie is detectable. So, the cookie
	would be generated as:		would be generated as:
	Cookie = <VersionIDofSecret> | <AdditionalInfo> |		Cookie = <VersionIDofSecret> | <AdditionalInfo> |
	Hash(Ni | IPi | SPIi | <AdditionalInfo> | <secret>)		Hash(Ni | IPi | SPIi | <AdditionalInfo> | <secret>)
	Alternatively, the Responder may continue to generate cookie as		Alternatively, the Responder may continue to generate cookie as
	suggested in Section 2.6 of [RFC7296], but associate the additional		suggested in Section 2.6 of [RFC7296], but associate the additional
	information, that would be stored locally, with the particular		information, that would be stored locally, with the particular
	version of the secret. In this case the Responder should have		version of the secret. In this case the Responder should have
	different secret for every combination of difficulty level and number		different secrets for every combination of difficulty level and
	of consecutive puzzles, and should change the secrets periodically,		number of consecutive puzzles, and should change the secrets
	keeping a few previous versions, to be able to calculate how long ago		periodically, keeping a few previous versions, to be able to
	the cookie was generated.		calculate how long ago the cookie was generated.
	The Responder may also combine these approaches. This document		The Responder may also combine these approaches. This document
	doesn't mandate how the Responder learns this information from the		doesn't mandate how the Responder learns this information from the
	cookie.		cookie.
	7.1.2. Solving Puzzle and Returning the Solution		7.1.2. Solving Puzzle and Returning the Solution
	If the Initiator receives a puzzle but it doesn't support puzzles,		If the Initiator receives a puzzle but it doesn't support puzzles,
	then it will ignore the PUZZLE notification as an unrecognized status		then it will ignore the PUZZLE notification as an unrecognized status
	notification (in accordance to Section 3.10.1 of [RFC7296]). The		notification (in accordance to Section 3.10.1 of [RFC7296]). The
	skipping to change at page 16, line 18 ¶		skipping to change at page 16, line 23 ¶
	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 9.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 3. They can be summarized as follows: given unpredictable
	string S and pseudo-random function PRF find the key K for that PRF		string S and pseudo-random function PRF find N different keys Ki
	so that the result of PRF(K,S) has the specified number of trailing		(where i=[1..N]) for that PRF so that the result of PRF(Ki,S) has at
	zero bits.		least the specified number of trailing zero bits. This specification
			requires that the solution to the puzzle contains 4 different keys
			(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 key K for the agreed upon PRF such		the IKE Initiator is to find the four different, equal-sized keys Ki
	that the result of PRF(K,cookie) has sufficient number of trailing		for the agreed upon PRF such that each result of PRF(Ki,cookie) where
	zero bits. Only the content of the COOKIE notification is used in		i = [1..4] has a sufficient number of trailing zero bits. Only the
	puzzle calculation, i.e. the header of the Notification payload is		content of the COOKIE notification is used in puzzle calculation,
	not included.		i.e. the header of the Notification payload is not included.
	Note, that puzzles in the IKE_AUTH exchange are computed differently		Note, that puzzles in the IKE_AUTH exchange are computed differently
	that in the IKE_SA_INIT_EXCHANGE. See Section 7.2.3 for details.		than in the IKE_SA_INIT_EXCHANGE. See Section 7.2.3 for details.
	7.1.4. Analyzing Repeated Request		7.1.4. Analyzing Repeated Request
	The received request must at least contain a COOKIE notification.		The received request must at least contain a COOKIE notification.
	Otherwise it is an initial request and it must be processed according		Otherwise it is an initial request and it must be processed according
	to Section 7.1. First, the cookie MUST be checked for validity. If		to Section 7.1. First, the cookie MUST be checked for validity. If
	the cookie is invalid, then the request is treated as initial and is		the cookie is invalid, then the request is treated as initial and is
	processed according to Section 7.1. If the cookie is valid then some		processed according to Section 7.1. It is RECOMMENDED that a new
	important information is learned from it or from local state based on		cookie is requested in this case.
	identifier of the cookie's secret (see Section 7.1.1.3 for details).
	This information helps the Responder to sort out incoming requests,		If the cookie is valid then some important information is learned
	giving more priority to those of them, which were created by spending		from it or from local state based on identifier of the cookie's
	more of the Initiator's resources.		secret (see Section 7.1.1.3 for details). This information helps the
			Responder to sort out incoming requests, giving more priority to
			those of them, which were created by spending more of the Initiator's
			resources.
	First, the Responder determines if it requested only a cookie, or		First, the Responder determines if it requested only a cookie, or
	presented a puzzle to the Initiator. If no puzzle was given, then it		presented a puzzle to the Initiator. If no puzzle was given, then it
	means that at the time the Responder requested a cookie it didn't		means that at the time the Responder requested a cookie it didn't
	detect the (D)DoS attack or the attack volume was low. In this case		detect the (D)DoS attack or the attack volume was low. In this case
	the received request message must not contain the PS payload, and		the received request message must not contain the PS payload, and
	this payload MUST be ignored if for any reason the message contains		this payload MUST be ignored if for any reason the message contains
	it. Since no puzzle was given, the Responder marks the request with		it. Since no puzzle was given, the Responder marks the request with
	the lowest priority since the Initiator spent little resources		the lowest priority since the Initiator spent little resources
	creating it.		creating it.
	If the Responder learns from the cookie that the puzzle was given to		If the Responder learns from the cookie that the puzzle was given to
	the Initiator, then it looks for the PS payload to determine whether		the Initiator, then it looks for the PS payload to determine whether
	its request to solve the puzzle was honored or not. If the incoming		its request to solve the puzzle was honored or not. If the incoming
	message doesn't contain a PS payload, then it means that the		message doesn't contain a PS payload, then it means that the
	Initiator either doesn't support puzzles or doesn't want to deal with		Initiator either doesn't support puzzles or doesn't want to deal with
	them. In either case the request is marked with the lowest priority		them. In either case the request is marked with the lowest priority
	since the Initiator spent little resources creating it.		since the Initiator spent little resources creating it.
	If a PS payload is found in the message, then the Responder MUST		If a PS payload is found in the message, then the Responder MUST
	verify the puzzle solution that it contains. The result must contain		verify the puzzle solution that it contains. The solution is
	at least the requested number of trailing zero bits (that is also		interpreted as four different keys. The result of using each of them
	learned from the cookie, as well as the PRF algorithm used in puzzle		in the PRF (as described in Section 7.1.3) must contain at least the
	solution). If the result of the solution contains fewer bits than		requested number of trailing zero bits. The Responder MUST check all
	were requested, it means that Initiator spent less resources than		the four returned keys.
	expected by the Responder. This request is marked with the lowest
	priority.		If any checked result contains fewer bits than were requested, it
			means that the Initiator spent less resources than expected by the
			Responder. This request is marked with the lowest priority.
	If the Initiator provided the solution to the puzzle satisfying the		If the Initiator provided the solution to the puzzle satisfying the
	requested difficulty level, or if the Responder didn't indicate any		requested difficulty level, or if the Responder didn't indicate any
	particular difficulty level (by requesting zero level) and the		particular difficulty level (by setting ZBC to zero) and the
	Initiator was free to select any difficulty level it can afford, then		Initiator was free to select any difficulty level it can afford, then
	the priority of the request is calculated based on the following		the priority of the request is calculated based on the following
	considerations:		considerations:
	o The higher zero bits the Initiator got, the higher priority its		o The Responder must take the smallest number of trailing zero bits
	request should receive.		among the checked results and count it as the number of zero bits
			the Initiator got.
			o The higher number of zero bits the Initiator got, the higher
			priority its request should receive.
	o The more consecutive puzzles the Initiator solved, the higher		o The more consecutive puzzles the Initiator solved, the higher
	priority it should receive.		priority it should receive.
	o The more time the Initiator spent solving the puzzles, the higher		o The more time the Initiator spent solving the puzzles, the higher
	priority it should receive.		priority it should receive.
	After the priority of the request is determined the final decision		After the priority of the request is determined the final decision
	whether to serve it or not is made.		whether to serve it or not is made.
	skipping to change at page 18, line 7 ¶		skipping to change at page 18, line 26 ¶
	The Responder decides what to do with the request based on its		The Responder decides what to do with the request based on its
	priority and Responder's current load. There are three possible		priority and Responder's current load. There are three possible
	actions:		actions:
	o Accept request.		o Accept request.
	o Reject request.		o Reject request.
	o Demand more work from Initiator by giving it a new puzzle.		o Demand more work from Initiator by giving it a new puzzle.
	The Responder SHOULD accept incoming request if its priority is high		The Responder SHOULD accept an incoming request if its priority is
	- it means that the Initiator spent quite a lot of resources. The		high - it means that the Initiator spent quite a lot of resources.
	Responder MAY also accept some of low-priority requests where the		The Responder MAY also accept some of low-priority requests where the
	Initiators don't support puzzles. The percentage of accepted legacy		Initiators don't support puzzles. The percentage of accepted legacy
	requests depends on the Responder's current load.		requests depends on the Responder's current load.
	If Initiator solved the puzzle, but didn't spend much resources for		If the Initiator solved the puzzle, but didn't spend much resources
	it (the selected puzzle difficulty level appeared to be low and the		for it (the selected puzzle difficulty level appeared to be low and
	Initiator solved it quickly), then the Responder SHOULD give it		the Initiator solved it quickly), then the Responder SHOULD give it
	another puzzle. The more puzzles the Initiator solves the higher its		another puzzle. The more puzzles the Initiator solves the higher its
	chances are to be served.		chances are to be served.
	The details of how the Responder makes decision on any particular		The details of how the Responder makes a decision for any particular
	request, are implementation dependent. The Responder can collect all		request, are implementation dependent. The Responder can collect all
	the incoming requests for some short period of time, sort them out		the incoming requests for some short period of time, sort them out
	based on their priority, calculate the number of available memory		based on their priority, calculate the number of available memory
	slots for half-open IKE SAs and then serve that number of requests		slots for half-open IKE SAs and then serve that number of requests
	from the head of the sorted list. The rest of requests can be either		from the head of the sorted list. The rest of requests can be either
	discarded or responded to with new puzzles.		discarded or responded to with new puzzles.
	Alternatively, the Responder may decide whether to accept every		Alternatively, the Responder may decide whether to accept every
	incoming request with some kind of lottery, taking into account its		incoming request with some kind of lottery, taking into account its
	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 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 2. 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
	skipping to change at page 19, line 31 ¶		skipping to change at page 20, line 7 ¶
	The Responder requests the Initiator to solve a puzzle by including		The Responder requests the Initiator to solve a puzzle by including
	the PUZZLE notification in the IKE_SA_INIT response message. The		the PUZZLE notification in the IKE_SA_INIT response message. The
	Responder MUST NOT use puzzles in the IKE_AUTH exchange unless the		Responder MUST NOT use puzzles in the IKE_AUTH exchange unless the
	puzzle has been previously presented and solved in the preceding		puzzle has been previously presented and solved in the preceding
	IKE_SA_INIT exchange.		IKE_SA_INIT exchange.
	<-- HDR, SA, KE, Nr, N(PUZZLE), [V+][N+]		<-- HDR, SA, KE, Nr, N(PUZZLE), [V+][N+]
	7.2.1.1. Selecting Puzzle Difficulty Level		7.2.1.1. Selecting Puzzle Difficulty Level
	The difficulty level of the puzzle in IKE_AUTH should be chosen so		The difficulty level of the puzzle in IKE_AUTH exchange should be
	that the Initiator would spend more time to solve the puzzle than the		chosen so that the Initiator would spend more time to solve the
	Responder to compute the D-H shared secret and the keys, needed to		puzzle than the Responder to compute the D-H shared secret and the
	decrypt and verify the IKE_AUTH request message. On the other hand,		keys, needed to decrypt and verify the IKE_AUTH request message. On
	the difficulty level should not be too high, otherwise the legitimate		the other hand, the difficulty level should not be too high,
	clients would experience an additional delay while establishing IKE		otherwise the legitimate clients would experience an additional delay
	SA.		while establishing IKE SA.
	Note, that since puzzles in the IKE_AUTH exchange are only allowed to		Note, that since puzzles in the IKE_AUTH exchange are only allowed to
	be used if they were used in the preceding IKE_SA_INIT exchange, the		be used if they were used in the preceding IKE_SA_INIT exchange, the
	Responder would be able to estimate the computing power of the		Responder would be able to estimate the computational power of the
	Initiator and to select the difficulty level accordingly. Unlike		Initiator and to select the difficulty level accordingly. Unlike
	puzzles in IKE_SA_INIT, the requested difficulty level for IKE_AUTH		puzzles in IKE_SA_INIT, the requested difficulty level for IKE_AUTH
	puzzles MUST NOT be zero. In other words, the Responder must always		puzzles MUST NOT be zero. In other words, the Responder must always
	set specific difficulty level and must not let the Initiator to		set specific difficulty level and must not let the Initiator to
	choose it on its own.		choose it on its own.
	7.2.1.2. Selecting Puzzle Algorithm		7.2.1.2. Selecting Puzzle Algorithm
	The algorithm for the puzzle is selected as described in		The algorithm for the puzzle is selected as described in
	Section 7.1.1.2. There is no requirement, that the algorithm for the		Section 7.1.1.2. There is no requirement, that the algorithm for the
	skipping to change at page 20, line 44 ¶		skipping to change at page 21, line 14 ¶
	Initiator has to solve the puzzle only once and the solution is valid		Initiator has to solve the puzzle only once and the solution is valid
	for both unfragmented and fragmented IKE messages.		for both unfragmented and fragmented IKE messages.
	7.2.3. Computing Puzzle		7.2.3. Computing Puzzle
	The puzzles in the IKE_AUTH exchange are computed differently than in		The puzzles in the IKE_AUTH exchange are computed differently than in
	the IKE_SA_INIT exchange (see Section 7.1.3). The general principle		the IKE_SA_INIT exchange (see Section 7.1.3). The general principle
	is the same; the difference is in the construction of the string S.		is the same; the difference is in the construction of the string S.
	Unlike the IKE_SA_INIT exchange, where S is the cookie, in the		Unlike the IKE_SA_INIT exchange, where S is the cookie, in the
	IKE_AUTH exchange S is a concatenation of Nr and SPIr. In other		IKE_AUTH exchange S is a concatenation of Nr and SPIr. In other
	words, the task for IKE Initiator is to find the key K for the agreed		words, the task for IKE Initiator is to find the four different keys
	upon PRF such that the result of PRF(K,Nr | SPIr) has a sufficient		Ki for the agreed upon PRF such that each result of PRF(Ki,Nr | SPIr)
	number of trailing zero bits. Nr is a nonce used by the Responder in		where i=[1..4] has a sufficient number of trailing zero bits. Nr is
	IKE_SA_INIT exchange, stripped of any headers. SPIr is IKE Responder		a nonce used by the Responder in IKE_SA_INIT exchange, stripped of
	SPI in the SA being established.		any headers. SPIr is IKE Responder's SPI from the IKE header of the
			SA being established.
	7.2.4. Receiving Puzzle Solution		7.2.4. Receiving Puzzle Solution
	If the Responder requested the Initiator to solve a puzzle in the		If the Responder requested the Initiator to solve a puzzle in the
	IKE_AUTH exchange, then it MUST silently discard all the IKE_AUTH		IKE_AUTH exchange, then it MUST silently discard all the IKE_AUTH
	request messages without the Puzzle Solution payload.		request messages without the Puzzle Solution payload.
	Once the message containing a solution to the puzzle is received, the		Once the message containing a solution to the puzzle is received, the
	Responder MUST verify the solution before performing computationlly		Responder MUST verify the solution before performing computationlly
	intensive operations i.e. computing the D-H shared secret and the		intensive operations i.e. computing the D-H shared secret and the
	SK_* keys. The Responder MUST silently discard the received message		SK_* keys. The Responder MUST verify all the four returned keys.
	if the puzzle solution is not correct (has insufficient number of
	trailing zero bits). If the Responder successfully verifies the		The Responder MUST silently discard the received message if any
	puzzle and calculates the SK_* key, but the message authenticity		checked verification result is not correct (contains insufficient
	check fails, then it SHOULD save the calculated keys in the IKE SA		number of trailing zero bits). If the Responder successfully
	state while waiting for the retransmissions from the Initiator. In		verifies the puzzle and calculates the SK_* key, but the message
	this case the Responder may skip verification of the puzzle solution		authenticity check fails, then it SHOULD save the calculated keys in
	and ignore the Puzzle Solution payload in the retransmitted messages.		the IKE SA state while waiting for the retransmissions from the
			Initiator. In this case the Responder may skip verification of the
			puzzle solution and ignore the Puzzle Solution payload in the
			retransmitted messages.
	If the Initiator uses IKE Fragmentation, then it is possible, that		If the Initiator uses IKE Fragmentation, then it is possible, that
	due to packet loss and/or reordering the Responder could receive non-		due to packet loss and/or reordering the Responder could receive non-
	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
	skipping to change at page 23, line 4 ¶		skipping to change at page 23, line 21 ¶
	SA to be deleted on the other end due to timeout. It is believed		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		that a few seconds is enough. Note, that if the Responder
	receives retransmissions of the request message during the delay		receives retransmissions of the request message during the delay
	period, the retransmitted messages should be silently discarded.		period, the retransmitted messages should be silently discarded.
	o If these counter-measures are inefficient, implementations can		o If these counter-measures are inefficient, implementations can
	delete the IKE SA with an offending peer by sending Delete		delete the IKE SA with an offending peer by sending Delete
	Payload.		Payload.
	9. Payload Formats		9. Payload Formats
	9.1. PUZZLE Notification		9.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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|Protocol ID(=0)| SPI Size (=0) | Notify Message Type |		|Protocol ID(=0)| SPI Size (=0) | Notify Message Type |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| PRF | Difficulty |		| PRF | Difficulty |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	o Protocol ID (1 octet) - MUST be 0.		o Protocol ID (1 octet) -- MUST be 0.
	o SPI Size (1 octet) - MUST be 0, meaning no Security Parameter		o SPI Size (1 octet) - MUST be 0, meaning no Security Parameter
	Index (SPI) is present.		Index (SPI) is present.
	o Notify Message Type (2 octets) - MUST be <TBA by IANA>, the value		o Notify Message Type (2 octets) -- MUST be <TBA by IANA>, the value
	assigned for the PUZZLE notification.		assigned for the PUZZLE notification.
	o PRF (2 octets) - Transform ID of the PRF algorithm that must be		o PRF (2 octets) -- Transform ID of the PRF algorithm that must be
	used to solve the puzzle. Readers should refer to the section		used to solve the puzzle. Readers should refer to the section
	"Transform Type 2 - Pseudo-Random Function Transform IDs" in		"Transform Type 2 - Pseudo-Random Function Transform IDs" in
	[IKEV2-IANA] for the list of possible values.		[IKEV2-IANA] for the list of possible values.
	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 bit, that the result of PRF must		minimum number of trailing zero bits (ZBC), that each of the
	contain. Value 0 means that the Responder doesn't request any		results of PRF must contain. Value 0 means that the Responder
	specific difficulty level and the Initiator is free to select		doesn't request any specific difficulty level and the Initiator is
	appropriate difficulty level of its own (see Section 7.1.1.1 for		free to select appropriate difficulty level on its own (see
	details).		Section 7.1.1.1 for details).
	This notification contains no data.		This notification contains no data.
	9.2. Puzzle Solution Payload		9.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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ Puzzle Solution Data ~		~ Puzzle Solution Data ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	o Puzzle Solution Data (variable length) - Contains the solution to		o Puzzle Solution Data (variable length) -- Contains the solution to
	the puzzle - i.e. the key for the PRF. This field MUST NOT be		the puzzle - four different keys for the selected PRF. This field
	empty. If the selected PRF has a fixed-size key, then the size of		MUST NOT be empty. All the keys MUST have the same size,
	the Puzzle Solution Data MUST be equal to the size of the key. If		therefore the size of this field is always a mutiple of 4 bytes.
	the PRF agreed upon accepts keys of any size, then then the size		If the selected PRF accepts only fixed-size keys, then the size of
	of the Puzzle Solution Data MUST be between 1 octet and the		each key MUST be of that fixed size. If the PRF agreed upon
	preferred key length of the PRF (inclusive).		accepts keys of any size, then then the size of each key MUST be
			between 1 octet and the preferred key length of the PRF
			(inclusive). It is expected that in most cases the keys will be 4
			(or even less) octets in length, however it depends on puzzle
			difficulty and on the Initiator's strategy to find solutions, and
			thus the size is not mandated by this specification. The
			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
			size of Puzzle Solution Data is the size of Payload (as indicated
			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		10. 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
	skipping to change at page 25, line 41 ¶		skipping to change at page 26, line 17 ¶
	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. References		13. Acknowledgements
	13.1. Normative References		The authors thank Tero Kivinen, Yaron Sheffer and Scott Fluhrer for
			their contribution into design of the protocol. In particular, Tero
			Kivinen suggested the kind of puzzle where the task is to find a
			solution with requested number of zero trailing bits. Yaron Sheffer
			and Scott Fluhrer suggested a way to make puzzle difficulty less
			erratic by solving several weaker puzles. The authors also thank
			David Waltermire for his carefull review of the draft and all others
			who commented the document.
			14. References
			14.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>.
	13.2. Informative References		14.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. 48 change blocks.
	160 lines changed or deleted		206 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/