draft-ietf-ipsecme-ddos-protection-08.txt		draft-ietf-ipsecme-ddos-protection-09.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: February 18, 2017 ELVIS-PLUS		Expires: March 16, 2017 ELVIS-PLUS
	August 17, 2016		September 12, 2016
	Protecting Internet Key Exchange Protocol version 2 (IKEv2)		Protecting Internet Key Exchange Protocol version 2 (IKEv2)
	Implementations from Distributed Denial of Service Attacks		Implementations from Distributed Denial of Service Attacks
	draft-ietf-ipsecme-ddos-protection-08		draft-ietf-ipsecme-ddos-protection-09
	Abstract		Abstract
	This document recommends implementation and configuration best		This document recommends implementation and configuration best
	practices for Internet Key Exchange Protocol version 2 (IKEv2)		practices for Internet Key Exchange Protocol version 2 (IKEv2)
	Responders, to allow them to resist Denial of Service and Distributed		Responders, to allow them to resist Denial of Service and Distributed
	Denial of Service attacks. Additionally, the document introduces a		Denial of Service attacks. Additionally, the document introduces a
	new mechanism called "Client Puzzles" that help accomplish this task.		new mechanism called "Client Puzzles" that help accomplish this task.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 36 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on February 18, 2017.		This Internet-Draft will expire on March 16, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 3, line 20 ¶		skipping to change at page 3, line 20 ¶
	against DoS attacks from spoofed IP-addresses. However, bot-nets		against DoS attacks from spoofed IP-addresses. However, bot-nets
	have become widespread, allowing attackers to perform Distributed		have become widespread, allowing attackers to perform Distributed
	Denial of Service (DDoS) attacks, which are more difficult to defend		Denial of Service (DDoS) attacks, which are more difficult to defend
	against. This document presents recommendations to help the		against. This document presents recommendations to help the
	Responder counter (D)DoS attacks. It also introduces a new mechanism		Responder counter (D)DoS attacks. It also introduces a new mechanism
	-- "puzzles" -- that can help accomplish this task.		-- "puzzles" -- that can help accomplish this task.
	2. Conventions Used in This Document		2. Conventions Used in This Document
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	document are to be interpreted as described in [RFC2119].		"OPTIONAL" in this document are to be interpreted as described in
			[RFC2119].
	3. The Vulnerability		3. The Vulnerability
	The IKE_SA_INIT Exchange described in Section 1.2 of [RFC7296]		The IKE_SA_INIT Exchange described in Section 1.2 of [RFC7296]
	involves the Initiator sending a single message. The Responder		involves the Initiator sending a single message. The Responder
	replies with a single message and also allocates memory for a		replies with a single message and also allocates memory for a
	structure called a half-open IKE Security Association (SA). This		structure called a half-open IKE Security Association (SA). This
	half-open SA is later authenticated in the IKE_AUTH Exchange. If		half-open SA is later authenticated in the IKE_AUTH Exchange. If
	that IKE_AUTH request never comes, the half-open SA is kept for an		that IKE_AUTH request never comes, the half-open SA is kept for an
	unspecified amount of time. Depending on the algorithms used and		unspecified amount of time. Depending on the algorithms used and
	skipping to change at page 11, line 13 ¶		skipping to change at page 11, line 13 ¶
	half-open SAs resulting from replayed IKE_SESSION_RESUME messages.		half-open SAs resulting from replayed IKE_SESSION_RESUME messages.
	Several kinds of DoS attacks are possible on servers supported IKE		Several kinds of DoS attacks are possible on servers supported IKE
	Session Resumption. See Section 9.3 of [RFC5723] for details.		Session Resumption. See Section 9.3 of [RFC5723] for details.
	4.6. Keeping computed Shared Keys		4.6. Keeping computed Shared Keys
	Once the IKE_SA_INIT exchange is finished, the Responder is waiting		Once the IKE_SA_INIT exchange is finished, the Responder is waiting
	for the first message of the IKE_AUTH exchange from the Initiator.		for the first message of the IKE_AUTH exchange from the Initiator.
	At this point the Initiator is not yet authenticated, and this fact		At this point the Initiator is not yet authenticated, and this fact
	allows an attacker to perform an attack, described in Section 3. The		allows an attacker to perform an attack, described in Section 3.
	attacker can just send garbage in the IKE_AUTH message forcing the		Instead of sending properly formed and encrypted IKE_AUTH message the
	Responder to perform costly CPU operations to compute SK_* keys.		attacker can just send arbitrary data, forcing the Responder to
			perform costly CPU operations to compute SK_* keys.
	If the received IKE_AUTH message failed to decrypt correctly (or		If the received IKE_AUTH message failed to decrypt correctly (or
	failed to pass ICV check), then the Responder SHOULD still keep the		failed to pass ICV check), then the Responder SHOULD still keep the
	computed SK_* keys, so that if it happened to be an attack, then an		computed SK_* keys, so that if it happened to be an attack, then an
	attacker cannot get advantage of repeating the attack multiple times		attacker cannot get advantage of repeating the attack multiple times
	on a single IKE SA. The responder can also use puzzles in the		on a single IKE SA. The responder can also use puzzles in the
	IKE_AUTH exchange as decribed in Section 7.2.		IKE_AUTH exchange as decribed in Section 7.2.
	4.7. Preventing "Hash and URL" Certificate Encoding Attacks		4.7. Preventing "Hash and URL" Certificate Encoding Attacks
	In IKEv2 each side may use the "Hash and URL" Certificate Encoding to		In IKEv2 each side may use the "Hash and URL" Certificate Encoding to
	instruct the peer to retrieve certificates from the specified		instruct the peer to retrieve certificates from the specified
	location (see Section 3.6 of [RFC7296] for details). Malicious		location (see Section 3.6 of [RFC7296] for details). Malicious
	initiators can use this feature to mount a DoS attack on the		initiators can use this feature to mount a DoS attack on the
	responder by providing an URL pointing to a large file possibly		responder by providing an URL pointing to a large file possibly
	containing garbage. While downloading the file the responder		containing meaningless bits. While downloading the file the
	consumes CPU, memory and network bandwidth.		responder consumes CPU, memory and network bandwidth.
	To prevent this kind of attack, the responder should not blindly		To prevent this kind of attack, the responder should not blindly
	download the whole file. Instead, it SHOULD first read the initial		download the whole file. Instead, it SHOULD first read the initial
	few bytes, decode the length of the ASN.1 structure from these bytes,		few bytes, decode the length of the ASN.1 structure from these bytes,
	and then download no more than the decoded number of bytes. Note,		and then download no more than the decoded number of bytes. Note,
	that it is always possible to determine the length of ASN.1		that it is always possible to determine the length of ASN.1
	structures used in IKEv2, if they are DER-encoded, by analyzing the		structures used in IKEv2, if they are DER-encoded, by analyzing the
	first few bytes. However, since the content of the file being		first few bytes. However, since the content of the file being
	downloaded can be under the attacker's control, implementations		downloaded can be under the attacker's control, implementations
	should not blindly trust the decoded length and SHOULD check whether		should not blindly trust the decoded length and SHOULD check whether
	skipping to change at page 17, line 25 ¶		skipping to change at page 17, line 25 ¶
	Cryptographic algorithm agility is considered an important feature		Cryptographic algorithm agility is considered an important feature
	for modern protocols ([RFC7696]). Algorithm agility ensures that a		for modern protocols ([RFC7696]). Algorithm agility ensures that a
	protocol doesn't rely on a single built-in set of cryptographic		protocol doesn't rely on a single built-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 algorithms with the peer. IKEv2 fully supports		negotiate new algorithms with the peer. IKEv2 fully supports
	cryptographic algorithm agility for its core operations.		cryptographic algorithm agility for its core operations.
	To support crypto agility in case of puzzles, the algorithm that is		To support crypto agility in case of puzzles, the algorithm that is
	used to compute a puzzle needs to be negotiated during the		used to compute a puzzle needs to be negotiated during the
	IKE_SA_INIT exchange. The negotiation is performed as follows. The		IKE_SA_INIT exchange. The negotiation is performed as follows. The
	initial request message sent by the Initiator contains an SA payload		initial request message from the Initiator contains an SA payload,
	with the list of transforms the Initiator supports and is willing to		containing a list of transforms of different types. Thereby the
	use in the IKE SA being established. The Responder parses the		Initiator asserts that it supports all transforms from this list and
	received SA payload and finds a mutually supported PRFs. The		can use any of them in the IKE SA being established. The Responder
	Responder selects the preferred PRF from the list of mutually		parses the received SA payload and finds a mutually supported of type
	supported ones and includes it into the PUZZLE notification. There		PRF. The Responder selects the preferred PRF from the list of
	is no requirement that the PRF selected for puzzles be the same as		mutually supported ones and includes it into the PUZZLE notification.
	the PRF that is negotiated later for use in core IKE SA crypto		There is no requirement that the PRF selected for puzzles be the same
			as the PRF that is negotiated later for use in core IKE SA crypto
	operations. If there are no mutually supported PRFs, then IKE SA		operations. If there are no mutually supported PRFs, then IKE SA
	negotiation will fail anyway and there is no reason to return a		negotiation will fail anyway and there is no reason to return a
	puzzle. In this case the Responder returns a NO_PROPOSAL_CHOSEN		puzzle. In this case the Responder returns a NO_PROPOSAL_CHOSEN
	notification. Note that PRF is a mandatory transform type for IKE SA		notification. Note that PRF is a mandatory transform type for IKE SA
	(see Sections 3.3.2 and 3.3.3 of [RFC7296]) and at least one		(see Sections 3.3.2 and 3.3.3 of [RFC7296]) and at least one
	transform of this type must always be present in the SA payload in an		transform of this type must always be present in the SA payload in an
	IKE_SA_INIT request message.		IKE_SA_INIT request message.
	7.1.1.3. Generating a Cookie		7.1.1.3. Generating a Cookie
	skipping to change at page 19, line 40 ¶		skipping to change at page 19, line 42 ¶
	least the specified number of trailing zero bits. This specification		least the specified number of trailing zero bits. This specification
	requires that the solution to the puzzle contain 4 different keys		requires that the solution to the puzzle contain 4 different keys
	(i.e. N=4).		(i.e. N=4).
	In the IKE_SA_INIT exchange it is the cookie that plays the role of		In the IKE_SA_INIT exchange it is the cookie that plays the role of
	unpredictable string S. In other words, in the IKE_SA_INIT the task		unpredictable string S. In other words, in the IKE_SA_INIT the task
	for the IKE Initiator is to find the four different, equal-sized keys		for the IKE Initiator is to find the four different, equal-sized keys
	Ki for the agreed upon PRF such that each result of PRF(Ki,cookie)		Ki for the agreed upon PRF such that each result of PRF(Ki,cookie)
	where i = [1..4] has a sufficient number of trailing zero bits. Only		where i = [1..4] has a sufficient number of trailing zero bits. Only
	the content of the COOKIE notification is used in puzzle calculation,		the content of the COOKIE notification is used in puzzle calculation,
	i.e. the header of the Notification payload is not included.		i.e. the header of the Notify 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
	than 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
	skipping to change at page 22, line 17 ¶		skipping to change at page 22, line 21 ¶
	Once the IKE_SA_INIT exchange is completed, the Responder has created		Once the IKE_SA_INIT exchange is completed, the Responder has created
	a state and is waiting for the first message of the IKE_AUTH exchange		a state and is waiting for the first message of the IKE_AUTH exchange
	from the Initiator. At this point the Initiator has already passed		from the Initiator. At this point the Initiator has already passed
	the return routability check and has proved that it has performed		the 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 allows a malicious Initiator to		is not yet authenticated and this allows a malicious Initiator to
	perform an attack, described in Section 3. Unlike a DoS attack in		perform an attack, described in Section 3. Unlike a DoS attack in
	the IKE_SA_INIT exchange, which is targeted on the Responder's memory		the IKE_SA_INIT exchange, which is targeted on the Responder's memory
	resources, the goal of this attack is to exhaust a Responder's CPU		resources, the goal of this attack is to exhaust a 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 arbitrary data. This costs nothing to the Initiator, but
	Responder has to perform relatively costly operations when computing		the Responder has to perform relatively costly operations when
	the D-H shared secret and deriving SK_* keys to be able to verify		computing the D-H shared secret and deriving SK_* keys to be able to
	authenticity of the message. If the Responder doesn't keep the		verify authenticity of the message. If the Responder doesn't keep
	computed keys after an unsuccessful verification of the IKE_AUTH		the computed keys after an unsuccessful verification of the 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 a puzzle in the		Initiator. The idea is that the Responder includes a puzzle in the
	IKE_SA_INIT response message and the Initiator includes a puzzle		IKE_SA_INIT response message and the Initiator includes a 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 the D-H shared secret. The difficulty level of the		before computing the D-H shared secret.
	puzzle should be selected so that the Initiator would spend
	substantially more time to solve the puzzle than the Responder to
	compute the shared secret.
	The Responder should constantly monitor the amount of the half-open		The Responder should constantly monitor the amount of the half-open
	IKE SA states that receive IKE_AUTH messages that cannot be decrypted		IKE SA states that receive IKE_AUTH messages that cannot be decrypted
	due to integrity check failures. If the percentage of such states is		due to integrity check failures. If the percentage of such states is
	high and it takes an essential fraction of Responder's computing		high and it takes an essential fraction of Responder's computing
	power to calculate keys for them, then the Responder may assume that		power to calculate keys for them, then the Responder may assume that
	it is under attack and SHOULD use puzzles to make it harder for		it is under attack and SHOULD use puzzles to make it harder for
	attackers.		attackers.
	7.2.1. Presenting Puzzle		7.2.1. Presenting Puzzle
	skipping to change at page 24, line 42 ¶		skipping to change at page 24, line 42 ¶
	The Responder MUST silently discard the received message if any		The Responder MUST silently discard the received message if any
	checked verification result is not correct (contains insufficient		checked verification result is not correct (contains insufficient
	number of trailing zero bits). If the Responder successfully		number of trailing zero bits). If the Responder successfully
	verifies the puzzle and calculates the SK_* key, but the message		verifies the puzzle and calculates the SK_* key, but the message
	authenticity check fails, then it SHOULD save the calculated keys in		authenticity check fails, then it SHOULD save the calculated keys in
	the IKE SA state while waiting for the retransmissions from the		the IKE SA state while waiting for the retransmissions from the
	Initiator. In this case the Responder may skip verification of the		Initiator. In this case the Responder may skip verification of the
	puzzle solution and ignore the Puzzle Solution payload in the		puzzle solution and ignore the Puzzle Solution payload in the
	retransmitted messages.		retransmitted messages.
	If the Initiator uses IKE Fragmentation, then it is possible, that		If the Initiator uses IKE Fragmentation, then it sends all fragments
	due to packet loss and/or reordering the Responder could receive non-		of a message simultaneously. Due to packets loss and/or reordering
	first IKE Fragment messages before receiving the first one containing		it is possible that the Responder receives subsequent fragments
	the PS payload. In this case the Responder MAY choose to keep the		before receiving the first one, that contains the PS payload. In
	received fragments until the first fragment containing the solution		this case the Responder MAY choose to keep the received fragments
	to the puzzle is received. In this case the Responder SHOULD NOT try		until the first fragment containing the solution to the puzzle is
	to verify authenticity of the kept fragments until the first fragment		received. In this case the Responder SHOULD NOT try to verify
	with the PS payload is received and the solution to the puzzle is		authenticity of the kept fragments until the first fragment with the
	verified. After successful verification of the puzzle, the Responder		PS payload is received and the solution to the puzzle is verified.
	can then calculate the SK_* key and verify authenticity of the		After successful verification of the puzzle, the Responder can then
	collected fragments.		calculate the SK_* key and verify authenticity of the collected
			fragments.
	8. Payload Formats		8. Payload Formats
	8.1. PUZZLE Notification		8.1. PUZZLE Notification
	The PUZZLE notification is used by the IKE Responder to inform the		The PUZZLE notification is used by the IKE Responder to inform the
	Initiator about the need to solve the puzzle. It contains the		Initiator about the need 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
End of changes. 11 change blocks.
	40 lines changed or deleted		41 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/