draft-ietf-ipsecme-ddos-protection-01.txt		draft-ietf-ipsecme-ddos-protection-02.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 9, 2015 ELVIS-PLUS		Expires: January 6, 2016 ELVIS-PLUS
	March 8, 2015		July 5, 2015
	Protecting Internet Key Exchange (IKE) Implementations from Distributed		Protecting Internet Key Exchange (IKE) Implementations from Distributed
	Denial of Service Attacks		Denial of Service Attacks
	draft-ietf-ipsecme-ddos-protection-01		draft-ietf-ipsecme-ddos-protection-02
	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-connected IPsec Responders, to allow them to
	resist Denial of Service and Distributed Denial of Service attacks.		resist Denial of Service and Distributed Denial of Service attacks.
	Additionally, the document introduces a new mechanism called "Client		Additionally, the document introduces a new mechanism called "Client
	Puzzles" that help accomplish this task.		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 9, 2015.		This Internet-Draft will expire on January 6, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 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
	skipping to change at page 5, line 21		skipping to change at page 5, line 21
	At this point, filling up the half-open SA database in no longer the		At this point, filling up the half-open SA database in no longer the
	most efficient DoS attack. The attacker has two ways to do better:		most efficient DoS attack. The attacker has two ways to do better:
	1. Go back to spoofed addresses and try to overwhelm the CPU that		1. Go back to spoofed addresses and try to overwhelm the CPU that
	deals with generating cookies, or		deals with generating cookies, or
	2. Take the attack to the next level by also sending an		2. Take the attack to the next level by also sending an
	Authentication request.		Authentication request.
	I don't think the first thing is something we can deal with at the		It seems that the first thing cannot be dealt with at the IKE level.
	IKE level. It's probably better left to Intrusion Prevention System		It's probably better left to Intrusion Prevention System (IPS)
	(IPS) technology.		technology.
	Sending an Authentication request is surprisingly cheap. It requires		On the other hand sending an Authentication request is surprisingly
	a proper IKE header with the correct IKE SPIs, and it requires a		cheap. It requires a proper IKE header with the correct IKE SPIs,
	single encrypted payload. The content of the payload might as well		and it requires a single encrypted payload. The content of the
	be junk. The responder has to perform the relatively expensive key		payload might as well be junk. The responder has to perform the
	derivation, only to find that the Authentication request does not		relatively expensive key derivation, only to find that the
	decrypt. Depending on the responder implementation, this can be		Authentication request does not decrypt. Depending on the responder
	repeated with the same half-open SA (if the responder does not delete		implementation, this can be repeated with the same half-open SA (if
	the half-open SA following an unsuccessful decryption - see		the responder does not delete the half-open SA following an
	discussion in Section 4).		unsuccessful decryption - see discussion in Section 4).
	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 of them allows the attacker to waste		is crucial, because each one of them allows the attacker to waste
	some CPU time. So making it hard to make many half-open SAs is		some CPU time. So making it hard to make many half-open SAs is
	important.		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.
	skipping to change at page 6, line 11		skipping to change at page 6, line 11
	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		3. Puzzles
	The puzzle introduced here extends the cookie mechanism from RFC		The puzzle introduced here extends the cookie mechanism from RFC
	7296. It is loosely based on the proof-of-work technique used in		7296. It is loosely based on the proof-of-work technique used in
	BitCoins ([bitcoins]). Future versions of this document will have		BitCoins ([bitcoins]).
	the exact bit structure of the notification payloads, but for now, I
	will only describe the semantics of the content.
	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, than no half-open SAs are allowed		o The Responder is so overloaded, than no half-open SAs are allowed
	to be created without the puzzle, or		to be created without the puzzle, or
	o The Responder is not too loaded, but the rate-limiting in		o The Responder is not too loaded, but the rate-limiting in
	Section 5 prevents half-open SAs from being created with this		Section 5 prevents half-open SAs from being created with this
	particular peer address or prefix without first solving a puzzle.		particular peer address or prefix without first solving 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 RFC 7296. As in RFC		1. Cookie - this is calculated the same as in RFC 7296. As in RFC
	7296, the process of generating the cookie is not specified.		7296, the process of generating the cookie is not specified.
	2. Algorithm, this is the identifier of a PRF algorithm, one of		2. Algorithm, this is the identifier of a PRF algorithm, one of
	those proposed by the Initiator in the SA payload.		those proposed by the Initiator in the SA payload.
	3. Zero Bit Count. This is a number between 8 and 255 that		3. Zero Bit Count. This is a number between 8 and 255 (or a special
	represents the length of the zero-bit run at the end of the		value - 0, see Section 8.1.1.1) that represents the length of the
	output of the PRF function calculated over the Keyed-Cookie		zero-bit run at the end of the output of the PRF function
	payload that the Initiator is to send. Since the mechanism is		calculated over the Keyed-Cookie payload that the Initiator is to
	supposed to be stateless for the Responder, the same value is		send. Since the mechanism is supposed to be stateless for the
	sent to all Initiators who are receiving this challenge. The		Responder, either the same value is sent to all Initiators who
	values 0 and 1-8 are explicitly excluded, because the value zero		are receiving this challenge or the value is somehow encoded in
	is meaningless, and the values 1-8 create a puzzle that is too		the cookie. The values 1-8 are explicitly excluded, because they
	easy to solve for it to make any difference in mitigating DDoS		create a puzzle that is too easy to solve for it to make any
	attacks.		difference in mitigating DDoS attacks.
	Upon receiving this challenge payload, the Initiator attempts to		Upon receiving this challenge payload, the Initiator attempts to
	calculate the PRF using different keys. When a key is found such		calculate the PRF using different keys. When a key is found such
	that the resulting PRF output has a sufficient number of trailing		that the resulting PRF output has a sufficient number of trailing
	zero bits, that result is sent to the Responder in a Keyed-Cookie		zero bits, that result is sent to the Responder in a Keyed-Cookie
	notification, as described in Section 3.1.		notification, as described in Section 3.1.
	When receiving a request with a Keyed-Cookie, the Responder verifies		When receiving a request with a Keyed-Cookie, the Responder verifies
	two things:		two things:
	skipping to change at page 7, line 50		skipping to change at page 7, line 48
	| 0b13cd9a | 00b97bb323d6d33350000000 | 28 | 247.914 |		| 0b13cd9a | 00b97bb323d6d33350000000 | 28 | 247.914 |
	| 37dc96e4 | 1e24babc92234aa3a0000000 | 29 | 1237.170 |		| 37dc96e4 | 1e24babc92234aa3a0000000 | 29 | 1237.170 |
	| 7a1a56d8 | c98f0061e380a49e00000000 | 33 | 2726.150 |		| 7a1a56d8 | c98f0061e380a49e00000000 | 33 | 2726.150 |
	+----------+--------------------------+----------+------------------+		+----------+--------------------------+----------+------------------+
	Table 1: COOKIE=fdbcfa5a430d7201282358a2a034de0013cfe2ae		Table 1: COOKIE=fdbcfa5a430d7201282358a2a034de0013cfe2ae
	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 I believe that 20 bits is a reasonable		well. With these figures 20 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, with 24 bits
	acceptable for specific hosts/prefixes.		acceptable for specific hosts/prefixes.
	3.1. The Keyed-Cookie Notification		3.1. The Keyed-Cookie Notification
	To be added		To be added
	3.2. The Puzzle-Required Notification		3.2. The Puzzle-Required Notification
	To be added		To be added
	skipping to change at page 11, line 27		skipping to change at page 11, line 27
	Initiators. This will force the attacker to use real source		Initiators. This will force the attacker to use real source
	addresses, and help avoid the need to impose a greater burden in the		addresses, and help avoid the need to impose a greater burden in the
	form of cookies on the general population of initiators. This makes		form of cookies on the general population of initiators. This makes
	the per-node or per-prefix soft limit more effective.		the per-node or per-prefix soft limit more effective.
	When Cookies are activated for all requests and the attacker is still		When Cookies are activated for all requests and the attacker is still
	managing to consume too many resources, the Responder MAY increase		managing to consume too many resources, the Responder MAY increase
	the difficulty of puzzles imposed on IKE_SA_INIT requests coming from		the difficulty of puzzles imposed on IKE_SA_INIT requests coming from
	suspicious nodes/prefixes. It should still be doable by all		suspicious nodes/prefixes. It should still be doable by all
	legitimate peers, but it can degrade experience, for example by		legitimate peers, but it can degrade experience, for example by
	taking up to 10 seconds to calculate the cookie extension.		taking up to 10 seconds to solve the puzzle.
	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.
	skipping to change at page 12, line 9		skipping to change at page 12, line 9
	the IKE_SESSION_RESUME response message, as allowed by RFC 5723, Sec.		the IKE_SESSION_RESUME response message, as allowed by RFC 5723, Sec.
	4.3.2. Note that the Responder SHOULD cache tickets for a short time		4.3.2. Note that the Responder SHOULD cache tickets for a short time
	to reject reused tickets (Sec. 4.3.1), and therefore there should be		to reject reused tickets (Sec. 4.3.1), and therefore there should be
	no issue of half-open SAs resulting from replayed IKE_SESSION_RESUME		no issue of half-open SAs resulting from replayed IKE_SESSION_RESUME
	messages		messages
	7. Operational Considerations		7. Operational Considerations
	[This section needs a lot of expanding]		[This section needs a lot of expanding]
	Not all Initiators support the puzzles, but all initiators are
	supposed to support stateless cookies. If this notification is sent
	to a non-supporting but legitimate initiator, the exchange will fail.
	Responders are advised to first try to mitigate the DoS using
	stateless cookies, even imposing them generally before resorting to
	using puzzles.
	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.
	8. Using Puzzles in the Protocol		8. Using Puzzles in the Protocol
	8.1. Puzzles in IKE_SA_INIT Exchange		8.1. Puzzles in IKE_SA_INIT Exchange
	IKE initiator indicates the desire to create new IKE SA by sending		IKE initiator indicates the desire to create a new IKE SA by sending
	IKE_SA_INIT request message. The message may optionally contain		IKE_SA_INIT request message. The message may optionally contain
	COOKIE notification if this is a repeated request after the responder		COOKIE notification if this is a repeated request performed after the
	asked initiator to return a cookie.		responder's demand to return a cookie.
	HDR, [N(COOKIE),] SA, KE, Ni, [V+][N+] -->		HDR, [N(COOKIE),] SA, KE, Ni, [V+][N+] -->
	According to the plan, described in Section 6, IKE responder should		According to the plan, described in Section 6, IKE responder should
	monitor incoming requests to detect whether it is under attack. If		monitor incoming requests to detect whether it is under attack. If
	the responder learns that (D)DoS attack is likely to be in progress,		the responder learns that (D)DoS attack is likely to be in progress,
	then it either requests the initiator to return cookie or, if the		then it either requests the initiator to return a cookie or, if the
	volume is so high, that puzzles need to be used for defense, it		volume is so high, that puzzles need to be used for defense, it
	requests the initiator to solve the puzzle.		requests the initiator to solve a puzzle.
	The responder MAY choose to process some fraction of IKE_SA_INIT		The responder MAY choose to process some fraction of IKE_SA_INIT
	requests without presenting a puzzle even being under attack to allow		requests without presenting a puzzle even being under attack to allow
	legacy clients, that don't support puzzles, to have chances be		legacy clients, that don't support puzzles, to have chances to be
	served. The decision whether to process any particular request must		served. The decision whether to process any particular request must
	be probabilistic, with the probability depending on the responder's		be probabilistic, with the probability depending on the responder's
	load (i.e. on the volume of the attack). Only those requests, that		load (i.e. on the volume of attack). Only those requests, that
	contain COOKIE notification, must participate in this lottery. In		contain COOKIE notification, must participate in this lottery. In
	other words, the responder MUST first perform return routability		other words, the responder MUST first perform return routability
	check before allowing any legacy client to be served if it is under		check before allowing any legacy client to be served if it is under
	attack. See Section 8.1.3 for details.		attack. See Section 8.1.3 for details.
	8.1.1. Presenting Puzzle		8.1.1. Presenting Puzzle
	If the responder takes a decision to use puzzles, then it includes		If the responder takes a decision to use puzzles, then it includes
	two notifications in its response message - the COOKIE notification		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 10.1.		is described in Section 10.1.
	<-- HDR, N(COOKIE), N(PUZZLE), [V+][N+]		<-- HDR, N(COOKIE), N(PUZZLE), [V+][N+]
	The presence of these notifications in IKE_SA_INIT response message		The presence of these notifications in an IKE_SA_INIT response
	indicates to the initiator that it should solve the puzzle to get		message indicates to the initiator that it should solve the puzzle to
	better chances to be served.		get better chances to be served.
	8.1.1.1. Selecting Puzzle Difficulty Level		8.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 -
	the minimum number of trailing zero bits that the result of PRF must		the minimum number of trailing zero bits that the result of PRF must
	contain. In diverse environments it is next to impossible for the		contain. In diverse environments it is next to impossible for the
	responder to set any specific difficulty level that will result in		responder to set any specific difficulty level that will result in
	roughly the same amount of work for all initiators, because		roughly the same amount of work for all initiators, because
	computation power of different initiators may vary by the order of		computation power of different initiators may vary by the order of
	magnitude, or even more. The responder may set difficulty level to		magnitude, or even more. The responder may set difficulty level to
	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 number of		solve puzzle, as it can afford. In this case no specific number of
	trailing zero bits is required from the initiator, however the more		trailing zero bits is required from the initiator, however the more
	bits initiator is able to get, the higher chances it will have to be		bits initiator is able to get, the higher 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.		that the initiator sets difficulty level to 0, unless the attack
			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 requestd		responder MAY set different difficulty levels to different requestd
	depending on the IP address the request has come from.		depending on the IP address the request has come from.
	8.1.1.2. Selecting Puzzle Algorithm		8.1.1.2. Selecting Puzzle Algorithm
	The PUZZLE notification also contains identificator of the algorithm,		The PUZZLE notification also contains identificator of the algorithm,
	that must be used by initiator in puzzle solution.		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 ([ALG-AGILITY]). This feature ensures that		for modern protocols ([ALG-AGILITY]). This feature ensures that
	protocol doesn't rely on a single build-in set of cryptographic		protocol doesn't rely on a single build-in set of cryptographic
	algorithms, but has a means to replace one set with another and		algorithms, but has a means to replace one set with another and
	negotiate new set with the peer. IKEv2 fully supports cryptographic		negotiate new set with the peer. IKEv2 fully supports cryptographic
	algorithm agility for its core operations.		algorithm agility 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
	skipping to change at page 14, line 31		skipping to change at page 14, line 27
	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 exchange.
	8.1.1.3. Generating Cookie		8.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 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
	was requested.		was requested.
	o The difficulty level of the puzzle given to the initiator.		o The difficulty level of the puzzle given to the initiator.
	o The number of consecutive puzzles given to the initiator.		o The number of consecutive puzzles given to the initiator.
	skipping to change at page 16, line 46		skipping to change at page 16, line 44
	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 a little resources		the lowest priority since the initiator spent a 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 puzzle was given to the
	the initiator, then it looks for the PS payload to determine whether		initiator, then it looks for the PS payload to determine whether its
	its request to solve the puzzle was honored or not. If the incoming		request to solve the puzzle was honored or not. If the incoming
	message doesn't contain PS payload, then it means that the initiator		message doesn't contain PS payload, then it means that the initiator
	either doesn't support puzzles or doesn't want to deal with them. In		either doesn't support puzzles or doesn't want to deal with them. In
	either case the request is marked with the lowest priority since the		either case the request is marked with the lowest priority since the
	initiator spent a little resources creating it.		initiator spent a little resources creating it.
	If PS payload is found in the message then the responder MUST verify		If PS payload is found in the message then the responder MUST verify
	the puzzle solution that it contains. The result must contain at		the puzzle solution that it contains. The result must contain at
	least the requested number of trailing zero bits (that is also		least the requested number of trailing zero bits (that is also
	learned from the cookie, as well as the PRF algorithm used in puzzle		learned from the cookie, as well as the PRF algorithm used in puzzle
	solution). If the result of the solution contais fewer bits, than		solution). If the result of the solution contais fewer bits, than
	skipping to change at page 18, line 8		skipping to change at page 18, line 8
	The responder SHOULD accept incoming request if its priority is high		The responder SHOULD accept incoming request if its priority is high
	- it means that the initiator spent quite a lot of resources. The		- it means that the initiator spent quite a lot of resources. The
	responder MAY also accept some of low-priority requests where 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 initiator solved the puzzle, but didn't spend much resources for
	it (the selected puzzle difficulty level appeared to be low and the		it (the selected puzzle difficulty level appeared to be low and the
	initiator solved it quickly), then the responder SHOULD give it		initiator solved it quickly), then the responder SHOULD give it
	another puzzle. The more puzzles the initiator solve the higher		another puzzle. The more puzzles the initiator solves the higher
	would be its chances ro be served.		would be its chances ro be served.
	The details of how the responder takes decision on any particular		The details of how the responder takes decision on any particular
	request are implementation dependant. The responder can collect all		request are implementation dependant. 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 alailable memory		based on their priority, calculate the number of alailable memory
	slots for half-open IKE SAs and then serve that number of the		slots for half-open IKE SAs and then serve that number of the
	requests from the head of the sorted list. The rest of requests can		requests from the head of the sorted list. The rest of requests can
	be either discarded or responded to with new puzzles.		be either discarded or responded to with new puzzles.
	skipping to change at page 18, line 31		skipping to change at page 18, line 31
	priority and the available resources.		priority and the available resources.
	8.2. Puzzles in IKE_AUTH Exchange		8.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 awaiting for the first message of the IKE_AUTH		a state and is awaiting for the first message of the IKE_AUTH
	exchange from initiator. At this point the initiator has already		exchange from initiator. At this point the initiator has already
	passed return routability check and has proved that it has performed		passed return routability check and has proved that it has performed
	some work to complete IKE_SA_INIT exchange. However, the initiator		some work to complete IKE_SA_INIT exchange. However, the initiator
	is not yet authenticated and this fact allows malicious initiator to		is not yet authenticated and this fact allows malicious initiator to
	conduct an attack, described in Section 2. Unlike DoS attack in		perform an attack, described in Section 2. Unlike DoS attack in
	IKE_SA_INIT exchange, which is targeted on the responder's memory		IKE_SA_INIT exchange, which is targeted on the responder's memory
	resources, the goal of this attack is to exhaust responder's CPU		resources, the goal of this attack is to exhaust responder's CPU
	power. The attack is performed by sending the first IKE_AUTH message		power. The attack is performed by sending the first IKE_AUTH message
	containing garbage. This costs nothing to the initiator, but the		containing garbage. This costs nothing to the initiator, but the
	responder has to do relatively costly operations of computing the		responder has to do relatively costly operations of computing the
	Diffie-Hellman shared secret and deriving SK_* keys to be able to		Diffie-Hellman shared secret and deriving SK_* keys to be able to
	verify authenticity of the message. If the responder doesn't save		verify authenticity of the message. If the responder doesn't keep
	the computed keys after unsuccessful verification of IKE_AUTH		the computed keys after unsuccessful verification of IKE_AUTH
	message, then the attack can be repeated several times on the same		message, then the attack can be repeated several times on the same
	IKE SA.		IKE SA.
	The responder can use puzzles to make this attack more costly for the		The responder can use puzzles to make this attack more costly for the
	initiator. The idea is that the responder includes puzzle in the		initiator. The idea is that the responder includes puzzle in the
	IKE_SA_INIT response message and the initiator includes puzzle		IKE_SA_INIT response message and the initiator includes puzzle
	solution in the first IKE_AUTH request message outside the Encrypted		solution in the first IKE_AUTH request message outside the Encrypted
	payload, so that the responder is able to verify puzzle solution		payload, so that the responder is able to verify puzzle solution
	before computing Diffie-Hellman shared secret. The difficulty level		before computing Diffie-Hellman shared secret. The difficulty level
	skipping to change at page 19, line 28		skipping to change at page 19, line 28
	puzzle has been previously presented and solved in the preceeding		puzzle has been previously presented and solved in the preceeding
	IKE_SA_INIT exchange.		IKE_SA_INIT exchange.
	<-- HDR, SA, KE, Nr, N(PUZZLE), [V+][N+]		<-- HDR, SA, KE, Nr, N(PUZZLE), [V+][N+]
	8.2.1.1. Selecting Puzzle Difficulty Level		8.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 should be chosen so,
	that the initiator would spend more time to solve the puzzle, than		that the initiator would spend more time to solve the puzzle, than
	the responder to compute Diffie-Hellman shared secret and the keys,		the responder to compute Diffie-Hellman shared secret and the keys,
	needed to decrypt and verify IKE_AUTH message. On the other hand,		needed to decrypt and verify the IKE_AUTH request message. On the
	the difficulty level should not be too high, otherwise the legitimate		other hand, the difficulty level should not be too high, otherwise
	clients would experience additional delay while establishing IKE SA.		the legitimate clients would experience additional delay 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 preceeding IKE_SA_INIT exchange, the		be used if they were used in the preceeding IKE_SA_INIT exchange, the
	responder would be able to estimate the computing power of the		responder would be able to estimate the computing 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.
	skipping to change at page 20, line 21		skipping to change at page 20, line 21
	puzzle is solved the initiator sends the IKE_AUTH request message,		puzzle is solved the initiator sends the IKE_AUTH request message,
	containing the Puzzle Solution payload.		containing the Puzzle Solution payload.
	HDR, PS, SK {IDi, [CERT,] [CERTREQ,]		HDR, PS, SK {IDi, [CERT,] [CERTREQ,]
	[IDr,] AUTH, SA, TSi, TSr} -->		[IDr,] AUTH, SA, TSi, TSr} -->
	The Puzzle Solution payload is placed outside the Encrypted payload,		The Puzzle Solution payload is placed outside the Encrypted payload,
	so that the responder would be able to verify the puzzle before		so that the responder would be able to verify the puzzle before
	calculating the Diffie-Hellman shared secret and the SK_* keys.		calculating the Diffie-Hellman shared secret and the SK_* keys.
	If IKE Fragmentation is used, then the PS payload MUST be present		If IKE Fragmentation [RFC7383] is used in IKE_AUTH exchange, then the
	only in the first IKE Fragment message, in accordance with the		PS payload MUST be present only in the first IKE Fragment message, in
	Section 2.5.3 of [RFC7383]. Note, that calculation of the puzzle in		accordance with the Section 2.5.3 of RFC7383. Note, that calculation
	the IKE_AUTH exchange doesn't depend on the content of the IKE_AUTH		of the puzzle in the IKE_AUTH exchange doesn't depend on the content
	message (see Section 8.2.2.1). Thus the responder has to solve the		of the IKE_AUTH message (see Section 8.2.2.1). Thus the responder
	puzzle only once and the solution is valid for both unfragmented and		has to solve the puzzle only once and the solution is valid for both
	fragmented IKE messages.		unfragmented and fragmented IKE messages.
	8.2.2.1. Computing Puzzle		8.2.2.1. Computing Puzzle
	The puzzle in the IKE_AUTH exchange is computed differently, than in		The puzzle in the IKE_AUTH exchange is computed differently, than in
	the IKE_SA_INIT exchange (see Section 8.1.2.1). The general		the IKE_SA_INIT exchange (see Section 8.1.2.1). The general
	principle is the same, the difference is in constructing of the		principle is the same, the difference is in constructing of the
	string S. Unlike the IKE_SA_INIT exchange, where S is the cookie, in		string S. 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		the 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 key K for the agreed
	upon PRF such that the result of PRF(K,Nr | SPIr) has sufficient		upon PRF such that the result of PRF(K,Nr | SPIr) has sufficient
	skipping to change at page 20, line 52		skipping to change at page 20, line 52
	8.2.3. Receiving Puzzle Solution		8.2.3. Receiving Puzzle Solution
	If the responder requested the initiator to solve puzzle in the		If the responder requested the initiator to solve puzzle in the
	IKE_AUTH exchange, then it SHOULD silently discard all the IKE_AUTH		IKE_AUTH exchange, then it SHOULD silently discard all the IKE_AUTH
	request messages without the Puzzle Solution payload.		request messages without the Puzzle Solution payload.
	Once the message containing solution for the puzzle is received the		Once the message containing solution for the puzzle is received the
	responder SHOULD verify the solution before performing computationly		responder SHOULD verify the solution before performing computationly
	intensive operations - computing the Diffie-Hellman shared secret and		intensive operations - computing the Diffie-Hellman shared secret and
	the SK_* keys. The responder MUST silently discard the received		the SK_* keys. The responder MUST silently discard the received
	message if the puzzle solution is not correct. If the puzzle is		message if the puzzle solution is not correct (has insufficient
	successfully verified and the SK_* key are calculated, but the		number of trailing zero bits). If the puzzle is successfully
	message authenticity check fails, the responder SHOULD save the		verified and the SK_* key are calculated, but the message
	calculated keys in the IKE SA state while waiting for the		authenticity check fails, the responder SHOULD save the calculated
	retransmissions from the initiator. In this case the responder may		keys in the IKE SA state while waiting for the retransmissions from
	skip verification of the puzzle solution and ignore the Puzzle		the initiator. In this case the responder may skip verification of
	Solution payload in the retransmitted messages.		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 packets loss and/or reordering the responder would receive		due to packets loss and/or reordering the responder would receive
	non-first IKE Fragment messages before receiving the first one,		non-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 (that would require		responder SHOULD NOT try to verify authenticity of the kept fragments
	the calculation of the SK_* keys) untill the first fragment with the		untill the first fragment with the PS payload is received and the
	PS payload is received and the solution to the puzzle is verified.		solution to the puzzle is verified. After successful verification of
	After successful verification of the puzzle the responder would		the puzzle the responder would calculate the SK_* key and verify
	calculate the SK_* key and verify authenticity of the collected		authenticity of the collected fragments.
	fragments.
	9. DoS Protection after IKE SA is created		9. DoS Protection after IKE SA is created
	Once IKE SA is created there is usually no much traffic over it. In		Once IKE SA is created there is usually no much traffic over it. In
	most cases this traffic consists of exchanges aimed to create		most cases this traffic consists of exchanges aimed to create
	additional Child SAs, rekey or delete them and check the liveness of		additional Child SAs, rekey or delete them and check the liveness of
	the peer. With a typical setup and typical Child SA lifetimes there		the peer. With a typical setup and typical Child SA lifetimes there
	must be no more than a few such exchanges in a minute, often less.		must be no more than a few such exchanges in a minute, often less.
	Some of these exchanges require relatively little resources (like		Some of these exchanges require relatively little resources (like
	liveness check), while others may be resourse consuming (like		liveness check), while others may be resource consuming (like
	creating or rekeying Child SA with Diffie-Hellman exchange).		creating or rekeying Child SA with Diffie-Hellman exchange).
	Since any endpoint can initiate new exchange, there is a possibility		Since any endpoint can initiate new exchange, there is a possibility
	that a peer would initiate too many exchanges, that could exhaust		that a peer would initiate too many exchanges, that could exhaust
	host resources. For example the peer can perform endless continuous		host resources. For example the peer can perform endless continuous
	Child SA rekeying or create overwhelming number of Child SAs with the		Child SA rekeying or create overwhelming number of Child SAs with the
	same Traffic Selectors etc. Such behaviour may be caused by buggy		same Traffic Selectors etc. Such behaviour may be caused by buggy
	implementation, misconfiguration or be intentional. The latter		implementation, misconfiguration or be intentional. The latter
	becomes more real threat if the peer uses NULL Authentication,		becomes more real threat if the peer uses NULL Authentication,
	described in [NULL-AUTH]. In this case the peer remains anonymous,		described in [NULL-AUTH]. In this case the peer remains anonymous,
	skipping to change at page 23, line 21		skipping to change at page 23, line 21
	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 bit, that the result of PRF must
	contain. Value 0 means that the responder doesn't request any		contain. Value 0 means that the responder doesn't request any
	specific difficulty level and the initiator is free to select		specific difficulty level and the initiator is free to select
	appropriate difficulty level of its own.		appropriate difficulty level of its own (see Section 8.1.1.1 for
			details).
	This notification contains no data.		This notification contains no data.
	10.2. Puzzle Solution Payload		10.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 Puzzle Solution payload and denoted as PS		dedicated payload, called Puzzle Solution payload and denoted as PS
	in this document.		in this document.
	1 2 3		1 2 3
	skipping to change at page 24, line 51		skipping to change at page 24, line 51
	[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,
	January 2010.		January 2010.
	[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>.
	[ALG-AGILITY]		[ALG-AGILITY]
	Housley, R., "Guidelines for Cryptographic Algorithm		Housley, R., "Guidelines for Cryptographic Algorithm
	Agility", draft-iab-crypto-alg-agility-02 (work in		Agility", draft-iab-crypto-alg-agility-05 (work in
	progress), December 2014.		progress), December 2014.
	[NULL-AUTH]		[NULL-AUTH]
	Smyslov, V. and P. Wouters, "The NULL Authentication		Smyslov, V. and P. Wouters, "The NULL Authentication
	Method in IKEv2 Protocol", draft-ietf-ipsecme-ikev2-null-		Method in IKEv2 Protocol", draft-ietf-ipsecme-ikev2-null-
	auth-02 (work in progress), January 2015.		auth-07 (work in progress), January 2015.
	Authors' Addresses		Authors' Addresses
	Yoav Nir		Yoav Nir
	Check Point Software Technologies Ltd.		Check Point Software Technologies Ltd.
	5 Hasolelim st.		5 Hasolelim st.
	Tel Aviv 6789735		Tel Aviv 6789735
	Israel		Israel
	EMail: ynir.ietf@gmail.com		EMail: ynir.ietf@gmail.com
End of changes. 32 change blocks.
	84 lines changed or deleted		78 lines changed or added
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/