< draft-ietf-ipsecme-ikev2-fragmentation-02.txt		draft-ietf-ipsecme-ikev2-fragmentation-03.txt >
	Network Working Group V. Smyslov		Network Working Group V. Smyslov
	Internet-Draft ELVIS-PLUS		Internet-Draft ELVIS-PLUS
	Intended status: Standards Track September 9, 2013		Intended status: Standards Track October 4, 2013
	Expires: March 13, 2014		Expires: April 7, 2014
	IKEv2 Fragmentation		IKEv2 Fragmentation
	draft-ietf-ipsecme-ikev2-fragmentation-02		draft-ietf-ipsecme-ikev2-fragmentation-03
	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 March 13, 2014.		This Internet-Draft will expire on April 7, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 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 4, line 10 ¶		skipping to change at page 4, line 10 ¶
	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", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	2. Protocol details		2. Protocol details
	2.1. Overview		2.1. Overview
	The idea of the protocol is to split large IKE message into the set		The idea of the protocol is to split large IKE message into the set
	of smaller ones, calling Fragment Messages. Fragmentation takes		of smaller ones, calling IKE Fragment Messages. Fragmentation takes
	place before the original message is encrypted and authenticated, so		place before the original message is encrypted and authenticated, so
	that each Fragment Message receives individual protection. On the		that each IKE Fragment Message receives individual protection. On
	receiving side Fragment Messages are collected, verified, decrypted		the receiving side IKE Fragment Messages are collected, verified,
	and merged together to get the original message before encryption.		decrypted and merged together to get the original message before
	For design rationale see Appendix A.		encryption. For design rationale see Appendix A.
	2.2. Limitations		2.2. Limitations
	As Fragment Messages are cryptographically protected, SK_a and SK_e		As IKE Fragment Messages are cryptographically protected, SK_a and
	must already be calculated. In general, it means that original		SK_e must already be calculated. In general, it means that original
	message can be fragmented if and only if it contains Encrypted		message can be fragmented if and only if it contains Encrypted
	Payload.		Payload.
	This implies that messages of the IKE_SA_INIT Exchange cannot be		This implies that messages of the IKE_SA_INIT Exchange cannot be
	fragmented. In most cases this is not a problem, since IKE_SA_INIT		fragmented. In most cases this is not a problem, since IKE_SA_INIT
	messages are usually small enough to avoid IP fragmentation. But in		messages are usually small enough to avoid IP fragmentation. But in
	some cases (advertising a badly structured long list of algorithms,		some cases (advertising a badly structured long list of algorithms,
	using large MODP Groups, etc.) these messages may become fairly large		using large MODP Groups, etc.) these messages may become fairly large
	and get fragmented by IP level. In this case the described solution		and get fragmented by IP level. In this case the described solution
	won't help.		won't help.
	skipping to change at page 7, line 12 ¶		skipping to change at page 7, line 12 ¶
	~ Integrity Checksum Data ~		~ Integrity Checksum Data ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Encrypted Fragment Payload		Encrypted Fragment Payload
	o Next Payload (1 octet) - in the very first fragment MUST be set to		o Next Payload (1 octet) - in the very first fragment MUST be set to
	Payload Type of the first inner Payload (similarly to the		Payload Type of the first inner Payload (similarly to the
	Encrypted Payload). In the rest fragments MUST be set to zero.		Encrypted Payload). In the rest fragments MUST be set to zero.
	o Fragment Number (2 octets) - current fragment number starting from		o Fragment Number (2 octets) - current fragment number starting from
	1. This field MUST be less than or equal to the next field, Total		1. This field MUST be less than or equal to the next field, Total
	Fragments.		Fragments. This field MUST NOT be zero.
	o Total Fragments (2 octets) - number of fragments original message		o Total Fragments (2 octets) - number of fragments original message
	was divided into. This field MUST NOT be zero.		was divided into. This field MUST NOT be zero.
	The other fields are identical to those specified in Section 3.14 of		The other fields are identical to those specified in Section 3.14 of
	[RFC5996].		[RFC5996].
	When prepending IKE Header, Length field MUST be adjusted to reflect		When prepending IKE Header, Length field MUST be adjusted to reflect
	the length of constructed message and Next Payload field MUST reflect		the length of constructed message and Next Payload field MUST reflect
	payload type of the first Payload in the constructed message (that in		payload type of the first Payload in the constructed message (that in
	skipping to change at page 10, line 15 ¶		skipping to change at page 10, line 15 ¶
	o Store message in the list waiting for the rest of fragments to		o Store message in the list waiting for the rest of fragments to
	arrive.		arrive.
	When all IKE Fragment Messages (as indicated in the Total Fragments		When all IKE Fragment Messages (as indicated in the Total Fragments
	field) are received, content of their Encrypted Fragment Payloads is		field) are received, content of their Encrypted Fragment Payloads is
	decrypted and merged together to form content of original Encrypted		decrypted and merged together to form content of original Encrypted
	Payload, and, therefore, along with IKE Header and unencrypted		Payload, and, therefore, along with IKE Header and unencrypted
	Payloads (if any), original message. Then it is processed as if it		Payloads (if any), original message. Then it is processed as if it
	was received, verified and decrypted as regular unfragmented message.		was received, verified and decrypted as regular unfragmented message.
	If receiver does't get all Fragment Messages needed to reassemble		If receiver does't get all IKE Fragment Messages needed to reassemble
	original Message for some Exchange within a timeout interval, it acts		original Message for some Exchange within a timeout interval, it acts
	according with Section 2.1 of [RFC5996], i.e. retransmits the		according with Section 2.1 of [RFC5996], i.e. retransmits the
	fragmented request Message (in case of Initiator) or deems IKE SA to		fragmented request Message (in case of Initiator) or deems Exchange
	have failed. In the former case Initiator MAY refragment request		to have failed. If Exchange is abandoned, all received so far IKE
	Message using smaller fragmentation threshold before retransmitting		Fragment Messages for that Exchange MUST be discarded.
	it (see Section 2.5.1). If Exchange is abandoned, all received so
	far Fragment Messages for that Exchange MUST be discarded.
	2.6.1. Changes in Replay Protection Logic		2.6.1. Changes in Replay Protection Logic
	According to [RFC5996] IKEv2 MUST reject message with the same		According to [RFC5996] IKEv2 MUST reject message with the same
	Message ID as it has seen before (taking into consideration Response		Message ID as it has seen before (taking into consideration Response
	bit). This logic has already been updated by [RFC6311], which		bit). This logic has already been updated by [RFC6311], which
	deliberately allows any number of messages with zero Message ID.		deliberately allows any number of messages with zero Message ID.
	This document also updates this logic: if message contains Encrypted		This document also updates this logic: if message contains Encrypted
	Fragment Payload, the values of Fragment Number and Total Fragments		Fragment Payload, the values of Fragment Number and Total Fragments
	fields from this payload MUST be used along with Message ID to detect		fields from this payload MUST be used along with Message ID to detect
	skipping to change at page 10, line 48 ¶		skipping to change at page 10, line 46 ¶
	it activated IKE Fragmentation. If Fragment Number in Encrypted		it activated IKE Fragmentation. If Fragment Number in Encrypted
	Fragment Payload in this message is equal to 1, Responder MUST		Fragment Payload in this message is equal to 1, Responder MUST
	fragment its response and retransmit it back to Initiator in		fragment its response and retransmit it back to Initiator in
	fragmented form.		fragmented form.
	If Responder receives a replay IKE Fragment Message for already		If Responder receives a replay IKE Fragment Message for already
	reassembled, verified and processed fragmented message, it MUST		reassembled, verified and processed fragmented message, it MUST
	retransmit response back to Initiator, but only if Fragment Number		retransmit response back to Initiator, but only if Fragment Number
	field in Encrypted Fragment Payload is equal to 1 and MUST silently		field in Encrypted Fragment Payload is equal to 1 and MUST silently
	discard received message otherwise. If Total Fragments field in		discard received message otherwise. If Total Fragments field in
	received IKE Fragment Message is greater than this field in Fragment		received IKE Fragment Message is greater than in IKE Fragment
	Messages that already processed fragmented message was reassembled		Messages that already processed fragmented message was reassembled
	from, Responder MAY refragment its response message using smaller		from, Responder MAY refragment its response message using smaller
	fragmentation threshold before resending it back to Initiator. In		fragmentation threshold before resending it back to Initiator. In
	this case Total Fragments field in new IKE Fragment Messages MUST be		this case Total Fragments field in new IKE Fragment Messages MUST be
	greater than in previously sent IKE Fragment Messages.		greater than in previously sent IKE Fragment Messages.
			If Initiator doesn't receive any of response IKE Fragment Messages
			withing a timeout interval, it MAY refragment request Message using
			smaller fragmentation threshold before retransmitting it (see
			Section 2.5.1). In this case Total Fragments field in new IKE
			Fragment Messages MUST be greater than in previously sent IKE
			Fragment Messages. Alternatively, if Initiator does receive some
			(but not all) of response IKE Fragment Messages, it MAY retransmit
			only the first of request IKE Fragment Messages, where Fragment
			Number field is equal to 1.
	3. Interaction with other IKE extensions		3. Interaction with other IKE extensions
	IKE Fragmentation is compatible with most of defined IKE extensions,		IKE Fragmentation is compatible with most of defined IKE extensions,
	like IKE Session Resumption [RFC5723], Quick Crash Detection Method		like IKE Session Resumption [RFC5723], Quick Crash Detection Method
	[RFC6290] and so on. It neither affect their operation, nor is		[RFC6290] and so on. It neither affect their operation, nor is
	affected by them. It is believed that IKE Fragmentation will also be		affected by them. It is believed that IKE Fragmentation will also be
	compatible with most future IKE extensions, if they follow general		compatible with most future IKE extensions, if they follow general
	principles of formatting, sending and receiving IKE messages,		principles of formatting, sending and receiving IKE messages,
	described in [RFC5996].		described in [RFC5996].
End of changes. 11 change blocks.
	19 lines changed or deleted		27 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/