draft-ietf-ipsecme-ikev2-fragmentation-00.txt		draft-ietf-ipsecme-ikev2-fragmentation-01.txt
	Network Working Group V. Smyslov		Network Working Group V. Smyslov
	Internet-Draft ELVIS-PLUS		Internet-Draft ELVIS-PLUS
	Intended status: Standards Track July 2, 2013		Intended status: Standards Track August 23, 2013
	Expires: January 3, 2014		Expires: February 24, 2014
	IKEv2 Fragmentation		IKEv2 Fragmentation
	draft-ietf-ipsecme-ikev2-fragmentation-00		draft-ietf-ipsecme-ikev2-fragmentation-01
	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 January 3, 2014.		This Internet-Draft will expire on February 24, 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 2, line 21		skipping to change at page 2, line 21
	2.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . 4		2.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . 4
	2.3. Negotiation . . . . . . . . . . . . . . . . . . . . . . . 4		2.3. Negotiation . . . . . . . . . . . . . . . . . . . . . . . 4
	2.4. Using IKE Fragmentation . . . . . . . . . . . . . . . . . 5		2.4. Using IKE Fragmentation . . . . . . . . . . . . . . . . . 5
	2.5. Fragmenting Message . . . . . . . . . . . . . . . . . . . 6		2.5. Fragmenting Message . . . . . . . . . . . . . . . . . . . 6
	2.5.1. Selecting Fragment Size . . . . . . . . . . . . . . . 7		2.5.1. Selecting Fragment Size . . . . . . . . . . . . . . . 7
	2.5.2. Fragmenting Messages containing unencrypted		2.5.2. Fragmenting Messages containing unencrypted
	Payloads . . . . . . . . . . . . . . . . . . . . . . . 8		Payloads . . . . . . . . . . . . . . . . . . . . . . . 8
	2.6. Receiving IKE Fragment Message . . . . . . . . . . . . . . 9		2.6. Receiving IKE Fragment Message . . . . . . . . . . . . . . 9
	2.6.1. Changes in Replay Protection Logic . . . . . . . . . . 10		2.6.1. Changes in Replay Protection Logic . . . . . . . . . . 10
	3. Interaction with other IKE extensions . . . . . . . . . . . . 11		3. Interaction with other IKE extensions . . . . . . . . . . . . 11
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 12		4. Transport Considerations . . . . . . . . . . . . . . . . . . . 12
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
	7.1. Normative References . . . . . . . . . . . . . . . . . . . 15		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	7.2. Informative References . . . . . . . . . . . . . . . . . . 15		8.1. Normative References . . . . . . . . . . . . . . . . . . . 16
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16		8.2. Informative References . . . . . . . . . . . . . . . . . . 16
			Appendix A. Design rationale . . . . . . . . . . . . . . . . . . 17
			Appendix B. Correlation between IP Datagram size and
			Encrypted Payload content size . . . . . . . . . . . 18
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19
	1. Introduction		1. Introduction
	The Internet Key Exchange Protocol version 2 (IKEv2), specified in		The Internet Key Exchange Protocol version 2 (IKEv2), specified in
	[RFC5996], uses UDP as a transport for its messages. When IKE		[RFC5996], uses UDP as a transport for its messages. When IKE
	message size exceeds path MTU, it gets fragmented by IP level. The		message size exceeds path MTU, it gets fragmented by IP level. The
	problem is that some network devices, specifically some NAT boxes,		problem is that some network devices, specifically some NAT boxes,
	don't allow IP fragments to pass through. This apparently blocks IKE		don't allow IP fragments to pass through. This apparently blocks IKE
	communication and, therefore, prevents peers from establishing IPsec		communication and, therefore, prevents peers from establishing IPsec
	SA.		SA.
	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. On the receiving side		of smaller ones, calling Fragment Messages. Fragmentation takes
	Fragment Messages are collected and merged together to get original		place before the original message is encrypted and authenticated, so
	message. In general this approach increases receiver's vulnerability		that each Fragment Message receives individual protection. On the
	to Denial of Service attack. To reduce this vulnerability Fragment		receiving side Fragment Messages are collected, verified, decrypted
	Messages are individually encrypted and authenticated. This implies		and merged together to get the original message before encryption.
	that message cannot be fragmented until shared secret is calculated.		For design rationale see Appendix A.
	2.2. Limitations		2.2. Limitations
	In general, original message can be fragmented if and only if it		As Fragment Messages are cryptographically protected, SK_a and SK_e
	contains Encrypted Payload. It means that messages in IKE_SA_INIT		must already be calculated. In general, it means that original
	Exchange cannot be fragmented. In most cases this is not a problem,		message can be fragmented if and only if it contains Encrypted
	since IKE_SA_INIT messages are usually small enough to avoid IP		Payload.
	fragmentation. But in some cases (advertising a badly structured
	long list of algorithms, using large MODP Groups, etc.) those		This implies that messages of the IKE_SA_INIT Exchange cannot be
	messages may become fairly large and get fragmented by IP level. In		fragmented. In most cases this is not a problem, since IKE_SA_INIT
	these cases the described solution won't help.		messages are usually small enough to avoid IP fragmentation. But in
			some cases (advertising a badly structured long list of algorithms,
			using large MODP Groups, etc.) these messages may become fairly large
			and get fragmented by IP level. In this case the described solution
			won't help.
			Among existing IKEv2 extensions, messages of IKE_SESSION_RESUME
			Exchange, defined in [RFC5723], cannot be fragmented either. See
			Section 3 for details.
	Another limitation is that the minimal size of IP Datagram bearing		Another limitation is that the minimal size of IP Datagram bearing
	IKE Fragment Message is about 100 bytes depending on the algorithms		IKE Fragment Message is about 100 bytes depending on the algorithms
	employed. According to [RFC0791] the minimum IP Datagram size that		employed. According to [RFC0791] the minimum IP Datagram size that
	is guaranteed not to be further fragmented is 68 bytes. So, even the		is guaranteed not to be further fragmented is 68 bytes. So, even the
	smallest IKE Fragment Messages could be fragmented by IP level in		smallest IKE Fragment Messages could be fragmented by IP level in
	some circumstances. But such extremely small PMTU sizes are very		some circumstances. But such extremely small PMTU sizes are very
	rare in real life.		rare in real life.
	2.3. Negotiation		2.3. Negotiation
	skipping to change at page 6, line 9		skipping to change at page 6, line 20
	Responder MUST send response message in the same form (fragmented or		Responder MUST send response message in the same form (fragmented or
	not) as corresponded request message. If it received unfragmented		not) as corresponded request message. If it received unfragmented
	request message, responded with unfragmented response message and		request message, responded with unfragmented response message and
	then received fragmented retransmission of the same request, it MUST		then received fragmented retransmission of the same request, it MUST
	resend its response back to Initiator fragmented.		resend its response back to Initiator fragmented.
	2.5. Fragmenting Message		2.5. Fragmenting Message
	Message to be fragmented MUST contain Encrypted Payload. For the		Message to be fragmented MUST contain Encrypted Payload. For the
	purpose of IKE Fragment Messages construction original (unencrypted)		purpose of IKE Fragment Messages construction original (unencrypted)
	content of Encrypted Payload is broken down into parts. Its content		content of Encrypted Payload is split into chunks. The content is
	is treated as a binary blob and is broken down regardless of inner		treated as a binary blob and is split regardless of inner Payloads
	Payloads boundaries. Each of resulting parts is treated as a content		boundaries. Each of resulting chunks is treated as an original
	for Encrypted Fragment Payload.		content of Encrypted Fragment Payload and is then encrypted and
			authenticated. Thus, the Encrypted Fragment Payload contains a chunk
			of the original content of Encrypted Payload in encrypted form. The
			cryptographic processing of Encrypted Fragment Payload is identical
			to Section 3.14 of [RFC5996], as well as documents updating it for
			particular algorithms or modes, such as [RFC5282].
	The Encrypted Fragment Payload, denoted SKF{...}, contains other		The Encrypted Fragment Payload, similarly to the Encrypted Payload,
	payloads in encrypted form. The Encrypted Fragment Payload, as well		if present in a message, MUST be the last payload in the message.
	as Encrypted Payload from [RFC5996], if present in a message, MUST be
	the last payload in the message.
	The payload type for an Encrypted Fragment payload is XXX (TBA by		The Encrypted Fragment Payload is denoted SKF{...} and its payload
	IANA).		type is XXX (TBA by IANA).
	1 2 3		1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Next Payload |C| RESERVED | Payload Length |		| Next Payload |C| RESERVED | Payload Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Fragment Number | Total Fragments |		| Fragment Number | Total Fragments |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Initialization Vector |		| Initialization Vector |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 6, line 39		skipping to change at page 7, line 4
	| Initialization Vector |		| Initialization Vector |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ Encrypted content ~		~ Encrypted content ~
	+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| | Padding (0-255 octets) |		| | Padding (0-255 octets) |
	+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
	| | Pad Length |		| | Pad Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ 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 (as in Encrypted Payload).		Payload Type of the first inner Payload (similarly to the
	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.
	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.
	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
	most cases will be Encrypted Fragment Payload). All newly		most cases will be Encrypted Fragment Payload). All newly
	constructed messages MUST retain the same Message ID as original		constructed messages MUST retain the same Message ID as original
	message. After prepending IKE Header and possibly any of Payloads		message. After prepending IKE Header and possibly any of Payloads
	that precedes Encrypted Payload in original message (see		that precedes Encrypted Payload in original message (see
	Section 2.5.2), the resulting messages are sent to the peer.		Section 2.5.2), the resulting messages are sent to the peer.
	Below is an example of fragmenting some message.		Below is an example of fragmenting a message.
	HDR(MID=n), SK(NextPld=PLD1) {PLD1 ... PLDN}		HDR(MID=n), SK(NextPld=PLD1) {PLD1 ... PLDN}
	Original Message		Original Message
	HDR(MID=n), SKF(NextPld=PLD1, Frag#=1, TotalFrags=m) {...},		HDR(MID=n), SKF(NextPld=PLD1, Frag#=1, TotalFrags=m) {...},
	HDR(MID=n), SKF(NextPld=0, Frag#=2, TotalFrags=m) {...},		HDR(MID=n), SKF(NextPld=0, Frag#=2, TotalFrags=m) {...},
	...		...
	HDR(MID=n), SKF(NextPld=0, Frag#=m, TotalFrags=m) {...}		HDR(MID=n), SKF(NextPld=0, Frag#=m, TotalFrags=m) {...}
	IKE Fragment Messages		IKE Fragment Messages
	2.5.1. Selecting Fragment Size		2.5.1. Selecting Fragment Size
	When breaking content of Encrypted Payload down into parts sender		When splitting content of Encrypted into chunks sender SHOULD chose
	SHOULD chose size of those parts so, that resulting IP Datagram size		size of those chunks so, that resulting IP Datagram size not exceed
	not exceed some fragmentation threshold - be small enough to avoid IP		some fragmentation threshold - be small enough to avoid IP
	fragmentation.		fragmentation.
	If sender has some knowledge about PMTU size it MAY use it. If		If sender has some knowledge about PMTU size it MAY use it. If
	sender is a Responder in the Exchange and it has received fragmented		sender is a Responder in the Exchange and it has received fragmented
	request, it MAY use maximum size of received IKE Fragment Message IP		request, it MAY use maximum size of received IKE Fragment Message IP
	Datagrams as threshold when constructing fragmented response.		Datagrams as threshold when constructing fragmented response.
	Otherwise for messages to be sent over IPv6 it is RECOMMENDED to use		Otherwise for messages to be sent over IPv6 it is RECOMMENDED to use
	value 1280 bytes as a maximum IP Datagram size ([RFC2460]). For		value 1280 bytes as a maximum IP Datagram size ([RFC2460]). For
	messages to be sent over IPv4 it is RECOMMENDED to use value 576		messages to be sent over IPv4 it is RECOMMENDED to use value 576
	bytes as a maximum IP Datagram size.		bytes as a maximum IP Datagram size.
	For IPv4 Encrypted Payload content size is less than IP Datagram size
	by the sum of the following values:
	o IPv4 header size (typically 20 bytes, up to 60 if IP options are
	present)
	o UDP header size (8 bytes)
	o non-ESP marker size (4 bytes if present)
	o IKE Header size (28 bytes)
	o Encrypted Payload header size (4 bytes)
	o IV size (varying)
	o padding and its size (at least 1 byte)
	o ICV size (varying)
	The sum may be estimated as 61..105 bytes + IV + ICV + padding. For
	IPv6 this estimation is difficult as there may be varying IPv6
	Extension headers included.
	According to [RFC0791] the minimum IPv4 datagram size that is		According to [RFC0791] the minimum IPv4 datagram size that is
	guaranteed not to be further fragmented is 68 bytes, but it is		guaranteed not to be further fragmented is 68 bytes, but it is
	generally impossible to use such small value for solution, described		generally impossible to use such small value for solution, described
	in this document. Using 576 bytes is a compromise - the value is		in this document. Using 576 bytes is a compromise - the value is
	large enough for the presented solution and small enough to avoid IP		large enough for the presented solution and small enough to avoid IP
	fragmentation in most situations. Several other UDP-based protocol		fragmentation in most situations. Several other UDP-based protocol
	assume the value 576 bytes as a safe low limit for IP datagrams size		assume the value 576 bytes as a safe low limit for IP datagrams size
	(Syslog, DNS, etc.). Sender MAY use other values if they are		(Syslog, DNS, etc.). Sender MAY use other values if they are
	appropriate.		appropriate.
	Initiator MAY try to discover path MTU by using several values of		Initiator MAY try to discover path MTU by using several values of
	fragmentation threshold, provided that it starts with larger values		fragmentation threshold, provided that it starts with larger values
	and fragments message again with next smaller value if it doesn't		and fragments message again with next smaller value if it doesn't
	receive response in a reasonable time after several retransmissions.		receive response in a reasonable time after several retransmissions.
	In this case using next smaller value MUST result in increasing Total		In this case using next smaller value MUST result in increasing Total
	Fragments field.		Fragments field.
			See Appendix B for correlation between IP Datagram size and Encrypted
			Payload content size.
	2.5.2. Fragmenting Messages containing unencrypted Payloads		2.5.2. Fragmenting Messages containing unencrypted Payloads
	Currently no one of IKEv2 Exchanges defines messages, containing both		Currently no one of IKEv2 Exchanges defines messages, containing both
	unencrypted payloads and payloads, protected by Encrypted Payload.		unencrypted payloads and payloads, protected by Encrypted Payload.
	But IKEv2 doesn't forbid such messages. If some future IKEv2		But IKEv2 doesn't forbid such messages. If some future IKEv2
	extension defines such a message and it needs to be fragmented, all		extension defines such a message and it needs to be fragmented, all
	unprotected payloads MUST be in the first fragment, along with		unprotected payloads MUST be in the first fragment, along with
	Encrypted Fragment Payload, which MUST be present in any IKE Fragment		Encrypted Fragment Payload, which MUST be present in any IKE Fragment
	Message.		Message.
	skipping to change at page 10, line 14		skipping to change at page 10, line 11
	previously received fragments, receiver MUST discard all received		previously received fragments, receiver MUST discard all received
	fragments and start reassembling over with just received IKE		fragments and start reassembling over with just received IKE
	Fragment Message.		Fragment Message.
	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, original message.		Payload, and, therefore, along with IKE Header and unencrypted
	Then it is processed as if it was received, verified and decrypted as		Payloads (if any), original message. Then it is processed as if it
	as regular unfragmented message.		was received, verified and decrypted as regular unfragmented message.
	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 41		skipping to change at page 10, line 38
	Message ID, it means that response message didn't reach Initiator and		Message ID, it means that response message didn't reach Initiator and
	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.		discard received message otherwise. If Total Fragments field in
			received IKE Fragment Message is greater than this field in Fragment
			Messages that already processed fragmented message was reassembled
			from, Responder MAY refragment its response message using smaller
			fragmentation threshold before resending it back to Initiator. In
			this case Total Fragments field in new IKE Fragment Messages MUST be
			greater than in previously sent IKE Fragment Messages.
	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].
	The notable exception that requires a special care is [RFC6311] -		When IKE Fragmentation is used with IKE Session Resumption [RFC5723],
	Protocol Support for High Availability of IKEv2. As it deliberately		messages of IKE_SESSION_RESUME Exchange cannot be fragmented as they
	allows any number of synchronization Exchanges to have the same		don't contain Encrypted Payload. These messages may be large due to
	Message ID - zero, standard replay detection logic, based on checking		ticket size. If this is the case the described solution won't help.
	Message ID is not applicable for such messages, and receiver has to		To avoid IP Fragmentation in this situation it is recommended to use
	check message content to detect replays. When implementing IKE		smaller tickets, e.g. by utilizing "ticket by reference" approach
			instead of "ticket by value".
			One exception that requires a special care is [RFC6311] - Protocol
			Support for High Availability of IKEv2. As it deliberately allows
			any number of synchronization Exchanges to have the same Message ID -
			zero, standard replay detection logic, based on checking Message ID
			is not applicable for such messages, and receiver has to check
			message content to detect replays. When implementing IKE
	Fragmentation along with [RFC6311], IKE Message ID Synchronization		Fragmentation along with [RFC6311], IKE Message ID Synchronization
	messages MUST NOT be sent fragmented to simplify receiver's task of		messages MUST NOT be sent fragmented to simplify receiver's task of
	detecting replays. Fortunately, these messages are small and there		detecting replays. Fortunately, these messages are small and there
	is no point in fragmenting them anyway.		is no point in fragmenting them anyway.
	4. Security Considerations		4. Transport Considerations
			With IKE Fragmentation if any single IKE Fragment Message get lost,
			receiver becomes unable to reassemble original Message. So, in
			general, using IKE Fragmentation implies higher probability for the
			Message not to be delivered to the peer. Although in most network
			environments the difference will be insignificant, on some lossy
			networks it may become noticeable. When using IKE Fragmentation
			implementations MAY use longer timeouts and do more retransmits
			before considering peer dead.
			5. Security Considerations
	Most of the security considerations for IKE Fragmentation are the		Most of the security considerations for IKE Fragmentation are the
	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 itself from Denial of		authenticity of fragments, thus protecting peers from Denial of
	Service attack.		Service attack.
	5. 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 Fragment Payload SKF		<TBA> Encrypted Fragment Payload SKF
	This document also defines new Notify Message Types in the "Notify		This document also defines new Notify Message Types in the "Notify
	Messages Types - Status Types" registry:		Messages Types - Status Types" registry:
	<TBA> IKE_FRAGMENTATION_SUPPORTED		<TBA> IKE_FRAGMENTATION_SUPPORTED
	6. Acknowledgements		7. Acknowledgements
	We would like to thank Tero Kivinen, Yoav Nir, Paul Wouters for their		The author would like to thank Tero Kivinen, Yoav Nir, Paul Wouters,
	review comments.		Yaron Sheffer and others for their reviews and valueable comments.
	7. References		8. References
	7.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)",
	RFC 5996, September 2010.		RFC 5996, September 2010.
	[RFC6311] Singh, R., Kalyani, G., Nir, Y., Sheffer, Y., and D.		[RFC6311] Singh, R., Kalyani, G., Nir, Y., Sheffer, Y., and D.
	Zhang, "Protocol Support for High Availability of IKEv2/		Zhang, "Protocol Support for High Availability of IKEv2/
	IPsec", RFC 6311, July 2011.		IPsec", RFC 6311, July 2011.
	7.2. Informative References		8.2. Informative References
	[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,		[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
	September 1981.		September 1981.
	[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6		[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
	(IPv6) Specification", RFC 2460, December 1998.		(IPv6) Specification", RFC 2460, December 1998.
			[RFC5282] Black, D. and D. McGrew, "Using Authenticated Encryption
			Algorithms with the Encrypted Payload of the Internet Key
			Exchange version 2 (IKEv2) Protocol", RFC 5282,
			August 2008.
	[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.
	[RFC6290] Nir, Y., Wierbowski, D., Detienne, F., and P. Sethi, "A		[RFC6290] Nir, Y., Wierbowski, D., Detienne, F., and P. Sethi, "A
	Quick Crash Detection Method for the Internet Key Exchange		Quick Crash Detection Method for the Internet Key Exchange
	Protocol (IKE)", RFC 6290, June 2011.		Protocol (IKE)", RFC 6290, June 2011.
			Appendix A. Design rationale
			The simplest approach to the IKE fragmentation would have been to
			fragment message that is fully formed and ready to be sent. But if
			message got fragmented after being encrypted and authenticated, this
			could open a possibility for a simple Denial of Service attack. The
			attacker could infrequently emit forged but looking valid fragments
			into the network, and some of these fragments would be fetched by
			receiver into the reassempling queue. Receiver could not distinguish
			forged fragments from valid ones and could only determine that some
			of received fragments were forged when the whole message got
			reassembled and check for its authenticity failed.
			To prevent this kind of attack and also to reduce vulnerability to
			some other kinds of DoS attacks it was decided to make fragmentation
			before applying cryptographic protection to the message. In this
			case each Fragment Message becomes individually encrypted and
			authenticated, that allows receiver to determine forgeg fragments and
			not to fetch them into the reassempling queue.
			Appendix B. Correlation between IP Datagram size and Encrypted Payload
			content size
			For IPv4 Encrypted Payload content size is less than IP Datagram size
			by the sum of the following values:
			o IPv4 header size (typically 20 bytes, up to 60 if IP options are
			present)
			o UDP header size (8 bytes)
			o non-ESP marker size (4 bytes if present)
			o IKE Header size (28 bytes)
			o Encrypted Payload header size (4 bytes)
			o IV size (varying)
			o padding and its size (at least 1 byte)
			o ICV size (varying)
			The sum may be estimated as 61..105 bytes + IV + ICV + padding.
			For IPv6 this estimation is difficult as there may be varying IPv6
			Extension headers included.
	Author's Address		Author's Address
	Valery Smyslov		Valery Smyslov
	ELVIS-PLUS		ELVIS-PLUS
	PO Box 81		PO Box 81
	Moscow (Zelenograd) 124460		Moscow (Zelenograd) 124460
	RU		RU
	Phone: +7 495 276 0211		Phone: +7 495 276 0211
	Email: svan@elvis.ru		Email: svan@elvis.ru
End of changes. 29 change blocks.
	86 lines changed or deleted		157 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/