draft-ietf-ipsecme-ikev2-fragmentation-06.txt		draft-ietf-ipsecme-ikev2-fragmentation-07.txt
	Network Working Group V. Smyslov		Network Working Group V. Smyslov
	Internet-Draft ELVIS-PLUS		Internet-Draft ELVIS-PLUS
	Intended status: Standards Track March 14, 2014		Intended status: Standards Track April 4, 2014
	Expires: September 15, 2014		Expires: October 6, 2014
	IKEv2 Fragmentation		IKEv2 Fragmentation
	draft-ietf-ipsecme-ikev2-fragmentation-06		draft-ietf-ipsecme-ikev2-fragmentation-07
	Abstract		Abstract
	This document describes the way to avoid IP fragmentation of large		This document describes the way to avoid IP fragmentation of large
	IKEv2 messages. This allows IKEv2 messages to traverse network		IKEv2 messages. This allows IKEv2 messages to traverse network
	devices that don't allow IP fragments to pass through.		devices that don't allow IP fragments to pass through.
	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
	skipping to change at page 1, line 32		skipping to change at page 1, line 32
	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 15, 2014.		This Internet-Draft will expire on October 6, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 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 16, line 5		skipping to change at page 15, line 18
	same as those for base IKEv2 protocol described in [RFC5996]. This		same as those for base IKEv2 protocol described in [RFC5996]. This
	extension introduces Encrypted Fragment Payload to protect content of		extension introduces Encrypted Fragment Payload to protect content of
	IKE Message Fragment. This allows receiver to individually check		IKE Message Fragment. This allows receiver to individually check
	authenticity of fragments, thus protecting peers from DoS attack.		authenticity of fragments, thus protecting peers from DoS attack.
	Security Considerations Section of [RFC5996] mentions possible attack		Security Considerations Section of [RFC5996] mentions possible attack
	on IKE by exhausting of the IP reassembly buffers. The mechanism,		on IKE by exhausting of the IP reassembly buffers. The mechanism,
	described in this document, allows IKE to avoid IP-fragmentation and		described in this document, allows IKE to avoid IP-fragmentation and
	therefore increases its robustness to DoS attacks.		therefore increases its robustness to DoS attacks.
			The following attack is possible with IKE Fragmentation. An attacker
			can initiate IKE_SA_INIT exchange, complete it, compute SK_a and SK_e
			and then send a large, but still incomplete, set of IKE_AUTH
			fragments. These fragments will pass the ICV check and will be
			stored in reassembly buffers, but as the set is incomplete, the
			reassembling will never succeed and eventually will time out. If the
			set is large, this attack could potentially exhaust the receiver's
			memory resources.
			To mitigate the impact of this attack, it is RECOMMENDED that
			receiver limits the number of fragments it stores in reassembling
			queue so that the sum of the sizes of Encrypted Fragment Payload
			contents (after decryption) for fragments that are already placed
			into reassembling queue be less than some value that is reasonable
			for the implementation. If the peer sends so many fragments, that
			the above condition is not met, the receiver can consider this
			situation to be either attack or as broken sender implementation. In
			either case, the receiver SHOULD drop the connection and discard all
			the received fragments.
			This value can be predefined, can be a configurable option, or can be
			calculated dynamically depending on receiver's memory load. In any
			case, the value SHOULD NOT exceed 64 Kbytes (the maximum size of UDP
			datagram) because any IKE message before fragmentation must be
			shorter than that.
	6. IANA Considerations		6. IANA Considerations
	This document defines new Payload in the "IKEv2 Payload Types"		This document defines new Payload in the "IKEv2 Payload Types"
	registry:		registry:
	<TBA> Encrypted and Authenticated Fragment SKF		<TBA> Encrypted and Authenticated Fragment SKF
	This document also defines new Notify Message Types in the "Notify		This document also defines new Notify Message Types in the "Notify
	Message Types - Status Types" registry:		Message Types - Status Types" registry:
	<TBA> IKEV2_FRAGMENTATION_SUPPORTED		<TBA> IKEV2_FRAGMENTATION_SUPPORTED
	7. Acknowledgements		7. Acknowledgements
	The author would like to thank Tero Kivinen, Yoav Nir, Paul Wouters,		The author would like to thank Tero Kivinen, Yoav Nir, Paul Wouters,
	Yaron Sheffer, Joe Touch and others for their reviews and valuable		Yaron Sheffer, Joe Touch, Derek Atkins and others for their reviews
	comments.		and valuable comments.
	8. References		8. References
	8.1. Normative References		8.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, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,		[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
	"Internet Key Exchange Protocol Version 2 (IKEv2)",		"Internet Key Exchange Protocol Version 2 (IKEv2)",
End of changes. 5 change blocks.
	6 lines changed or deleted		32 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/