< draft-ietf-ipsecme-ikev2-fragmentation-01.txt		draft-ietf-ipsecme-ikev2-fragmentation-02.txt >
	Network Working Group V. Smyslov		Network Working Group V. Smyslov
	Internet-Draft ELVIS-PLUS		Internet-Draft ELVIS-PLUS
	Intended status: Standards Track August 23, 2013		Intended status: Standards Track September 9, 2013
	Expires: February 24, 2014		Expires: March 13, 2014
	IKEv2 Fragmentation		IKEv2 Fragmentation
	draft-ietf-ipsecme-ikev2-fragmentation-01		draft-ietf-ipsecme-ikev2-fragmentation-02
	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 February 24, 2014.		This Internet-Draft will expire on March 13, 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 20 ¶		skipping to change at page 2, line 20 ¶
	2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4		2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4
	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 . . . . . . . . . . . . 12
	4. Transport Considerations . . . . . . . . . . . . . . . . . . . 12		4. Transport Considerations . . . . . . . . . . . . . . . . . . . 13
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 13		5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 16		8.1. Normative References . . . . . . . . . . . . . . . . . . . 17
	8.2. Informative References . . . . . . . . . . . . . . . . . . 16		8.2. Informative References . . . . . . . . . . . . . . . . . . 17
	Appendix A. Design rationale . . . . . . . . . . . . . . . . . . 17		Appendix A. Design rationale . . . . . . . . . . . . . . . . . . 18
	Appendix B. Correlation between IP Datagram size and		Appendix B. Correlation between IP Datagram size and
	Encrypted Payload content size . . . . . . . . . . . 18		Encrypted Payload content size . . . . . . . . . . . 19
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20
	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 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
			original Message for some Exchange within a timeout interval, it acts
			according with Section 2.1 of [RFC5996], i.e. retransmits the
			fragmented request Message (in case of Initiator) or deems IKE SA to
			have failed. In the former case Initiator MAY refragment request
			Message using smaller fragmentation threshold before retransmitting
			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
	retransmissions and replays.		retransmissions and replays.
	skipping to change at page 13, line 5 ¶		skipping to change at page 13, line 16 ¶
	With IKE Fragmentation if any single IKE Fragment Message get lost,		With IKE Fragmentation if any single IKE Fragment Message get lost,
	receiver becomes unable to reassemble original Message. So, in		receiver becomes unable to reassemble original Message. So, in
	general, using IKE Fragmentation implies higher probability for the		general, using IKE Fragmentation implies higher probability for the
	Message not to be delivered to the peer. Although in most network		Message not to be delivered to the peer. Although in most network
	environments the difference will be insignificant, on some lossy		environments the difference will be insignificant, on some lossy
	networks it may become noticeable. When using IKE Fragmentation		networks it may become noticeable. When using IKE Fragmentation
	implementations MAY use longer timeouts and do more retransmits		implementations MAY use longer timeouts and do more retransmits
	before considering peer dead.		before considering peer dead.
			Note that Fragment Messages are not individually acknowledged. The
			response Fragment Messages are sent back all together only when all
			fragments of request are received, the original request Message is
			reassembled and successfully processed.
	5. Security Considerations		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 peers from Denial of		authenticity of fragments, thus protecting peers from Denial of
	Service attack.		Service attack.
	6. IANA Considerations		6. IANA Considerations
End of changes. 7 change blocks.
	15 lines changed or deleted		29 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/