draft-ietf-ipsecme-ikev2-fragmentation-05.txt		draft-ietf-ipsecme-ikev2-fragmentation-06.txt
	Network Working Group V. Smyslov		Network Working Group V. Smyslov
	Internet-Draft ELVIS-PLUS		Internet-Draft ELVIS-PLUS
	Intended status: Standards Track November 3, 2013		Intended status: Standards Track March 14, 2014
	Expires: May 7, 2014		Expires: September 15, 2014
	IKEv2 Fragmentation		IKEv2 Fragmentation
	draft-ietf-ipsecme-ikev2-fragmentation-05		draft-ietf-ipsecme-ikev2-fragmentation-06
	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 May 5, 2014.		This Internet-Draft will expire on September 15, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 2, line 32		skipping to change at page 2, line 32
	4. Transport Considerations . . . . . . . . . . . . . . . . . . . 14		4. Transport Considerations . . . . . . . . . . . . . . . . . . . 14
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 15		5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 18		8.1. Normative References . . . . . . . . . . . . . . . . . . . 18
	8.2. Informative References . . . . . . . . . . . . . . . . . . 18		8.2. Informative References . . . . . . . . . . . . . . . . . . 18
	Appendix A. Design rationale . . . . . . . . . . . . . . . . . . 20		Appendix A. Design rationale . . . . . . . . . . . . . . . . . . 20
	Appendix B. Correlation between IP Datagram size and		Appendix B. Correlation between IP Datagram size and
	Encrypted Payload content size . . . . . . . . . . . 21		Encrypted Payload content size . . . . . . . . . . . 21
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23
	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. Most IKEv2		[RFC5996], uses UDP as a transport for its messages. Most IKEv2
	messages are relatively small, usually below several hundred bytes.		messages are relatively small, usually below several hundred bytes.
	Noticeable exception is IKE_AUTH exchange, which requires fairly		Noticeable exception is IKE_AUTH exchange, which requires fairly
	large messages, up to several kbytes, especially when certificates		large messages, up to several kbytes, especially when certificates
	are transferred. When IKE message size exceeds path MTU, it gets		are transferred. When IKE message size exceeds path MTU, it gets
	fragmented by IP level. The problem is that some network devices,		fragmented by IP level. The problem is that some network devices,
	skipping to change at page 4, line 48		skipping to change at page 4, line 48
	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
	Initiator MAY indicate its support for IKE Fragmentation and		Initiator MAY indicate its support for IKE Fragmentation and
	willingness to use it by including Notification Payload of type		willingness to use it by including Notification Payload of type
	IKE_FRAGMENTATION_SUPPORTED in IKE_SA_INIT request message. If		IKEV2_FRAGMENTATION_SUPPORTED in IKE_SA_INIT request message. If
	Responder also supports this extension and is willing to use it, it		Responder also supports this extension and is willing to use it, it
	includes this notification in response message.		includes this notification in response message.
	Initiator Responder		Initiator Responder
	----------- -----------		----------- -----------
	HDR, SAi1, KEi, Ni,		HDR, SAi1, KEi, Ni,
	[N(IKE_FRAGMENTATION_SUPPORTED)] -->		[N(IKEV2_FRAGMENTATION_SUPPORTED)] -->
	<-- HDR, SAr1, KEr, Nr, [CERTREQ],		<-- HDR, SAr1, KEr, Nr, [CERTREQ],
	[N(IKE_FRAGMENTATION_SUPPORTED)]		[N(IKEV2_FRAGMENTATION_SUPPORTED)]
	The Notify payload is formatted as follows:		The Notify payload is formatted as follows:
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|Protocol ID(=0)| SPI Size (=0) | Notify Message Type |		|Protocol ID(=0)| SPI Size (=0) | Notify Message Type |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	o Protocol ID (1 octet) MUST be 0.		o Protocol ID (1 octet) MUST be 0.
	o SPI Size (1 octet) MUST be 0, meaning no SPI is present.		o SPI Size (1 octet) MUST be 0, meaning no SPI is present.
	o Notify Message Type (2 octets) - MUST be xxxxx, the value assigned		o Notify Message Type (2 octets) - MUST be xxxxx, the value assigned
	for IKE_FRAGMENTATION_SUPPORTED by IANA.		for IKEV2_FRAGMENTATION_SUPPORTED by IANA.
	This Notification contains no data.		This Notification contains no data.
	2.4. Using IKE Fragmentation		2.4. Using IKE Fragmentation
	IKE Fragmentation MUST NOT be used unless both peers indicated their		IKE Fragmentation MUST NOT be used unless both peers indicated their
	support for it. After IKE Fragmentation is negotiated, it is up to		support for it. After IKE Fragmentation is negotiated, it is up to
	Initiator of each Exchange, whether to use it or not. In most cases		Initiator of each Exchange, whether to use it or not. In most cases
	IKE Fragmentation will be used in IKE_AUTH Exchange, especially if		IKE Fragmentation will be used in IKE_AUTH Exchange, especially if
	certificates are employed. Initiator may first try to send		certificates are employed. Initiator may first try to send
	skipping to change at page 6, line 51		skipping to change at page 6, line 51
	authenticated. Thus, the Encrypted Fragment Payload contains a chunk		authenticated. Thus, the Encrypted Fragment Payload contains a chunk
	of the original content of Encrypted Payload in encrypted form. The		of the original content of Encrypted Payload in encrypted form. The
	cryptographic processing of Encrypted Fragment Payload is identical		cryptographic processing of Encrypted Fragment Payload is identical
	to Section 3.14 of [RFC5996], as well as documents updating it for		to Section 3.14 of [RFC5996], as well as documents updating it for
	particular algorithms or modes, such as [RFC5282].		particular algorithms or modes, such as [RFC5282].
	The Encrypted Fragment Payload, similarly to the Encrypted Payload,		The Encrypted Fragment Payload, similarly to the Encrypted Payload,
	if present in a message, MUST be the last payload in the message.		if present in a message, MUST be the last payload in the message.
	The Encrypted Fragment Payload is denoted SKF{...} and its payload		The Encrypted Fragment Payload is denoted SKF{...} and its payload
	type is XXX (TBA by IANA).		type is XXX (TBA by IANA). This payload is also called the
			"Encrypted and Authenticated Fragment" payload.
	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 9, line 9		skipping to change at page 9, line 11
	Initiator MAY try to discover path MTU by probing several values of		Initiator MAY try to discover path MTU by probing several values of
	fragmentation threshold. While doing probes, node MUST start from		fragmentation threshold. While doing probes, node MUST start from
	larger values and refragment message with next smaller value if it		larger values and refragment message with next smaller value if it
	doesn't receive response in a reasonable time after several		doesn't receive response in a reasonable time after several
	retransmissions. This time is supposed to be relatively short, so		retransmissions. This time is supposed to be relatively short, so
	that node could make all desired probes before exchange times out.		that node could make all desired probes before exchange times out.
	When starting new probe (with smaller threshold) node MUST reset its		When starting new probe (with smaller threshold) node MUST reset its
	retransmission timers so, that if it employs exponential back-off,		retransmission timers so, that if it employs exponential back-off,
	the timers start over. After reaching the smallest allowed value for		the timers start over. After reaching the smallest allowed value for
	fragmentation threshold implementation MUST continue probing using it		fragmentation threshold implementation MUST continue probing using it
	untill either exchange completes ot times out.		until either exchange completes or times out.
	PMTU discovery in IKE is supposed to be coarse-grained, i.e. it is		PMTU discovery in IKE is supposed to be coarse-grained, i.e. it is
	expected, that node will try only few fragmentation thresholds, in		expected, that node will try only few fragmentation thresholds, in
	order to minimize possible IKE SA establishment delay. In a corner		order to minimize possible IKE SA establishment delay. In a corner
	case, when host will use only one value, PMTU discovery will		case, when host will use only one value, PMTU discovery will
	effectively be disabled. In most cases PMTU discovery will not be		effectively be disabled. In most cases PMTU discovery will not be
	needed, as using values, recommended in section Section 2.5.1, should		needed, as using values, recommended in section Section 2.5.1, should
	suffice. It is expected, that PMTU discovery may be useful in		suffice. It is expected, that PMTU discovery may be useful in
	environments where PMTU size are smaller, than those listed in		environments where PMTU size are smaller, than those listed in
	Section 2.5.1, for example due to the presence of intermediate		Section 2.5.1, for example due to the presence of intermediate
	tunnels.		tunnels.
	PMTU discovery in IKE follows recommendations, given in Section 10.4		PMTU discovery in IKE follows recommendations, given in Section 10.4
	of RFC4821 [RFC4821] with some differences, induced by the		of RFC4821 [RFC4821] with some differences, induced by the
	specialities of IKE. In particular:		specialties of IKE. In particular:
	o Unlike classical PMTUD [RFC1191] and PLMTUD [RFC4821] the goal of		o Unlike classical PMTUD [RFC1191] and PLMTUD [RFC4821] the goal of
	Path MTU discovery in IKE is not to find the largest size of IP		Path MTU discovery in IKE is not to find the largest size of IP
	packet, that will not be fragmented en route, but to find any		packet, that will not be fragmented en route, but to find any
	reasonal size, probably far from optimal.		reasonable size, probably far from optimal.
	o There is no goal to completely disallow IP fragmentation until its		o There is no goal to completely disallow IP fragmentation until its
	presence leads to inability IKE to communicate (e.g. when IP		presence leads to inability IKE to communicate (e.g. when IP
	fragments are dropped)		fragments are dropped)
	o IKE usually sends large messages only in IKE_AUTH exchange, i.e.		o IKE usually sends large messages only in IKE_AUTH exchange, i.e.
	once per IKE SA. Most of other messages will have size below		once per IKE SA. Most of other messages will have size below
	several hundred bytes. Performing full PMTUD for sending exactly		several hundred bytes. Performing full PMTUD for sending exactly
	one large message is inefficient.		one large message is inefficient.
	skipping to change at page 11, line 48		skipping to change at page 11, line 49
	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 already decrypted Encrypted		field) are received, content of their already decrypted Encrypted
	Fragment Payloads is merged together to form content of original		Fragment Payloads is merged together to form content of original
	Encrypted Payload, and, therefore, along with IKE Header and		Encrypted Payload, and, therefore, along with IKE Header and
	unencrypted Payloads (if any), original message. Then it is		unencrypted Payloads (if any), original message. Then it is
	processed as if it was received, verified and decrypted as regular		processed as if it was received, verified and decrypted as regular
	unfragmented message.		unfragmented message.
	If receiver does't get all IKE Fragment Messages needed to reassemble		If receiver doesn't get all IKE Fragment Messages needed to
	original Message for some Exchange within a timeout interval, it acts		reassemble original Message for some Exchange within a timeout
	according with Section 2.1 of [RFC5996], i.e. retransmits the		interval, it acts according with Section 2.1 of [RFC5996], i.e.
	fragmented request Message (in case of Initiator) or deems Exchange
	to have failed. If Exchange is abandoned, all received so far IKE		retransmits the fragmented request Message (in case of Initiator) or
	Fragment Messages for that Exchange MUST be discarded.		deems Exchange to have failed. If Exchange is abandoned, all
			received so far IKE 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 12, line 38		skipping to change at page 12, line 42
	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 in IKE 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		If Initiator doesn't receive any of response IKE Fragment Messages
	withing a timeout interval, it MAY refragment request Message using		within a timeout interval, it MAY refragment request Message using
	smaller fragmentation threshold before retransmitting it (see		smaller fragmentation threshold before retransmitting it (see
	Section 2.5.1). In this case Total Fragments field in new IKE		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 MUST be greater than in previously sent IKE
	Fragment Messages. Alternatively, if Initiator does receive some		Fragment Messages. Alternatively, if Initiator does receive some
	(but not all) of response IKE Fragment Messages, it MAY retransmit		(but not all) of response IKE Fragment Messages, it MAY retransmit
	only the first of request IKE Fragment Messages, where Fragment		only the first of request IKE Fragment Messages, where Fragment
	Number field is equal to 1.		Number field is equal to 1.
	3. Interaction with other IKE extensions		3. Interaction with other IKE extensions
	skipping to change at page 16, line 10		skipping to change at page 16, line 10
	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.
	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 Fragment Payload 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
	Messages Types - Status Types" registry:		Message Types - Status Types" registry:
	<TBA> IKE_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 and others for their reviews and valueable comments.		Yaron Sheffer, Joe Touch and others for their reviews 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)",
	skipping to change at page 20, line 11		skipping to change at page 20, line 11
	Kaufman, C., Perlman, R., and B. Sommerfeld, "DoS		Kaufman, C., Perlman, R., and B. Sommerfeld, "DoS
	protection for UDP-based protocols", ACM Conference on		protection for UDP-based protocols", ACM Conference on
	Computer and Communications Security, October 2003.		Computer and Communications Security, October 2003.
	Appendix A. Design rationale		Appendix A. Design rationale
	The simplest approach to the IKE fragmentation would have been to		The simplest approach to the IKE fragmentation would have been to
	fragment message that is fully formed and ready to be sent. But if		fragment message that is fully formed and ready to be sent. But if
	message got fragmented after being encrypted and authenticated, this		message got fragmented after being encrypted and authenticated, this
	could open a possibility for a simple Denial of Service attack. The		could open a possibility for a simple Denial of Service attack. The
	attacker could infrequently emit forged but looking valid fragments		attacker could infrequently emit forged but valid looking fragments
	into the network, and some of these fragments would be fetched by		into the network, and some of these fragments would be fetched by
	receiver into the reassempling queue. Receiver could not distinguish		receiver into the reassembling queue. Receiver could not distinguish
	forged fragments from valid ones and could only determine that some		forged fragments from valid ones and could only determine that some
	of received fragments were forged when the whole message got		of received fragments were forged when the whole message got
	reassembled and check for its authenticity failed.		reassembled and check for its authenticity failed.
	To prevent this kind of attack and also to reduce vulnerability to		To prevent this kind of attack and also to reduce vulnerability to
	some other kinds of DoS attacks it was decided to make fragmentation		some other kinds of DoS attacks it was decided to make fragmentation
	before applying cryptographic protection to the message. In this		before applying cryptographic protection to the message. In this
	case each Fragment Message becomes individually encrypted and		case each Fragment Message becomes individually encrypted and
	authenticated, that allows receiver to determine forgeg fragments and		authenticated, that allows receiver to determine forged fragments and
	not to fetch them into the reassempling queue.		not to store them in the reassembling queue.
	Appendix B. Correlation between IP Datagram size and Encrypted Payload		Appendix B. Correlation between IP Datagram size and Encrypted Payload
	content size		content size
	For IPv4 Encrypted Payload content size is less than IP Datagram size		For IPv4 Encrypted Payload content size is less than IP Datagram size
	by the sum of the following values:		by the sum of the following values:
	o IPv4 header size (typically 20 bytes, up to 60 if IP options are		o IPv4 header size (typically 20 bytes, up to 60 if IP options are
	present)		present)
	skipping to change at page 21, line 30		skipping to change at page 21, line 30
	o Encrypted Payload header size (4 bytes)		o Encrypted Payload header size (4 bytes)
	o IV size (varying)		o IV size (varying)
	o padding and its size (at least 1 byte)		o padding and its size (at least 1 byte)
	o ICV size (varying)		o ICV size (varying)
	The sum may be estimated as 61..105 bytes + IV + ICV + padding.		The sum may be estimated as 61..105 bytes + IV + ICV + padding.
	For IPv6 this estimation is difficult as there may be varying IPv6		For IPv6 Encrypted Payload content size is less than IP Datagram size
	Extension headers included.		by the sum of the following values:
			o IPv6 header size (40 bytes)
			o IPv6 extension headers (optional, size varies)
			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)
			If no extension header is present, the sum may be estimated as 81..85
			bytes + IV + ICV + padding. If extension headers are present, the
			payload content size is further reduced by the sum of the size of the
			extension headers. The length of each extension header can be
			calculated as 8 * (Hdr Ext Len) bytes except for the fragment header
			which is always 8 bytes in length.
	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		Russian Federation
	Phone: +7 495 276 0211		Phone: +7 495 276 0211
	Email: svan@elvis.ru		Email: svan@elvis.ru
End of changes. 24 change blocks.
	32 lines changed or deleted		61 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/