draft-ietf-ipsecme-ikev2-fragmentation-04.txt		draft-ietf-ipsecme-ikev2-fragmentation-05.txt
	Network Working Group V. Smyslov		Network Working Group V. Smyslov
	Internet-Draft ELVIS-PLUS		Internet-Draft ELVIS-PLUS
	Intended status: Standards Track October 18, 2013		Intended status: Standards Track November 3, 2013
	Expires: April 21, 2014		Expires: May 7, 2014
	IKEv2 Fragmentation		IKEv2 Fragmentation
	draft-ietf-ipsecme-ikev2-fragmentation-04		draft-ietf-ipsecme-ikev2-fragmentation-05
	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 April 21, 2014.		This Internet-Draft will expire on May 5, 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 18		skipping to change at page 2, line 18
	1.1. Conventions Used in This Document . . . . . . . . . . . . 3		1.1. Conventions Used in This Document . . . . . . . . . . . . 3
	2. Protocol details . . . . . . . . . . . . . . . . . . . . . . . 4		2. Protocol details . . . . . . . . . . . . . . . . . . . . . . . 4
	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 . . . . . . . . . . . . . . . 8		2.5.1. Selecting Fragment Size . . . . . . . . . . . . . . . 8
	2.5.2. PMTU Discovery . . . . . . . . . . . . . . . . . . . . 8		2.5.2. PMTU Discovery . . . . . . . . . . . . . . . . . . . . 8
	2.5.3. Fragmenting Messages containing unencrypted		2.5.3. Fragmenting Messages containing unencrypted
	Payloads . . . . . . . . . . . . . . . . . . . . . . . 9		Payloads . . . . . . . . . . . . . . . . . . . . . . . 10
	2.6. Receiving IKE Fragment Message . . . . . . . . . . . . . . 10		2.6. Receiving IKE Fragment Message . . . . . . . . . . . . . . 10
	2.6.1. Changes in Replay Protection Logic . . . . . . . . . . 11		2.6.1. Changes in Replay Protection Logic . . . . . . . . . . 12
	3. Interaction with other IKE extensions . . . . . . . . . . . . 13		3. Interaction with other IKE extensions . . . . . . . . . . . . 13
	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 . . . . . . . . . . . . . . . . . . 19		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 . . . . . . . . . . . 20		Encrypted Payload content size . . . . . . . . . . . 21
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22
	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. Most IKEv2
	message size exceeds path MTU, it gets fragmented by IP level. The		messages are relatively small, usually below several hundred bytes.
	problem is that some network devices, specifically some NAT boxes,		Noticeable exception is IKE_AUTH exchange, which requires fairly
	don't allow IP fragments to pass through. This apparently blocks IKE		large messages, up to several kbytes, especially when certificates
	communication and, therefore, prevents peers from establishing IPsec		are transferred. When IKE message size exceeds path MTU, it gets
	SA.		fragmented by IP level. The problem is that some network devices,
			specifically some NAT boxes, don't allow IP fragments to pass
			through. This apparently blocks IKE communication and, therefore,
			prevents peers from establishing IPsec SA.
			Widespread deployment of Carrier-Grade NATs (CGN) introduces new
			challenges. RFC6888 [RFC6888] describes requirements for CGNs. It
			states, that CGNs must comply with Section 11 of RFC4787 [RFC4787],
			which requires NAT to support receiving IP fragments (REQ-14). In
			real life fulfillment of this requirement creates an additional
			burden in terms of memory, especially for high-capacity devices, used
			in CGNs. It was found by people deploying IKE, that some ISPs have
			begun to drop IP fragments, violating that requirement.
	The solution to the problem described in this document is to perform		The solution to the problem described in this document is to perform
	fragmentation of large messages by IKE itself, replacing them by		fragmentation of large messages by IKE itself, replacing them by
	series of smaller messages. In this case the resulting IP Datagrams		series of smaller messages. In this case the resulting IP Datagrams
	will be small enough so that no fragmentation on IP level will take		will be small enough so that no fragmentation on IP level will take
	place.		place.
			Avoiding IP fragmentation is beneficial for IKEv2 in general.
			Security Considerations Section of [RFC5996] mentions exhausting of
			the IP reassembly buffers as one of possible attacks on the protocol.
			In the paper [DOSUDPPROT] several aspects of attacks on IKE using IP
			fragmentation are discussed, and one of defenses it proposes is to
			perform IKE-level fragmentation, similar to the solution, described
			in this document.
	1.1. Conventions Used in This Document		1.1. Conventions Used in This Document
	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 a set of
	of smaller ones, calling IKE Fragment Messages. Fragmentation takes		smaller ones, called 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 IKE Fragment Message receives individual protection. On		that each IKE Fragment Message receives individual protection. On
	the receiving side IKE Fragment Messages are collected, verified,		the receiving side IKE Fragment Messages are collected, verified,
	decrypted and merged together to get the original message before		decrypted and merged together to get the original message before
	encryption. For design rationale see Appendix A.		encryption. For design rationale see Appendix A.
	2.2. Limitations		2.2. Limitations
	As IKE Fragment Messages are cryptographically protected, SK_a and		As IKE Fragment Messages are cryptographically protected, SK_a and
	SK_e must already be calculated. In general, it means that original		SK_e must already be calculated. In general, it means that original
	skipping to change at page 8, line 28		skipping to change at page 8, line 28
	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. Presence of tunnels on the path
			may reduce these values.
	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.
	See Appendix B for correlation between IP Datagram size and Encrypted		See Appendix B for correlation between IP Datagram size and Encrypted
	Payload content size.		Payload content size.
	2.5.2. PMTU Discovery		2.5.2. PMTU Discovery
	Initiator MAY try to discover path MTU by using several values of		Initiator MAY try to discover path MTU by probing several values of
	fragmentation threshold, provided that it starts with larger values		fragmentation threshold. While doing probes, node MUST start from
	and fragments message again with next smaller value if it doesn't		larger values and refragment message with next smaller value if it
	receive response in a reasonable time after several retransmissions.		doesn't receive response in a reasonable time after several
			retransmissions. This time is supposed to be relatively short, so
			that node could make all desired probes before exchange times out.
			When starting new probe (with smaller threshold) node MUST reset its
			retransmission timers so, that if it employs exponential back-off,
			the timers start over. After reaching the smallest allowed value for
			fragmentation threshold implementation MUST continue probing using it
			untill either exchange completes ot times out.
			PMTU discovery in IKE is supposed to be coarse-grained, i.e. it is
			expected, that node will try only few fragmentation thresholds, in
			order to minimize possible IKE SA establishment delay. In a corner
			case, when host will use only one value, PMTU discovery will
			effectively be disabled. In most cases PMTU discovery will not be
			needed, as using values, recommended in section Section 2.5.1, should
			suffice. It is expected, that PMTU discovery may be useful in
			environments where PMTU size are smaller, than those listed in
			Section 2.5.1, for example due to the presence of intermediate
			tunnels.
			PMTU discovery in IKE follows recommendations, given in Section 10.4
			of RFC4821 [RFC4821] with some differences, induced by the
			specialities of IKE. In particular:
			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
			packet, that will not be fragmented en route, but to find any
			reasonal size, probably far from optimal.
			o There is no goal to completely disallow IP fragmentation until its
			presence leads to inability IKE to communicate (e.g. when IP
			fragments are dropped)
			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
			several hundred bytes. Performing full PMTUD for sending exactly
			one large message is inefficient.
	In case of PMTU discovery Total Fragments field is used to		In case of PMTU discovery Total Fragments field is used to
	distinguish between different sets of fragments, i.e. the sets that		distinguish between different sets of fragments, i.e. the sets that
	were obtained by fragmenting original message using different		were obtained by fragmenting original message using different
	fragmentation thresholds. As sender will start from larger fragments		fragmentation thresholds. As sender will start from larger fragments
	and then make them smaller, the value in Total Fragments field will		and then make them smaller, the value in Total Fragments field will
	increase with each new try. When selecting next smaller value of		increase with each new try. When selecting next smaller value of
	fragmentation threshold, sender MUST ensure that the value in Total		fragmentation threshold, sender MUST ensure that the value in Total
	Fragments field is really increased. This requirement should not		Fragments field is really increased. This requirement should not
	become a problem for the sender, as PMTU discovery in IKE is supposed		become a problem for the sender, as PMTU discovery in IKE is supposed
	skipping to change at page 10, line 30		skipping to change at page 11, line 19
	* check that Fragment Number and Total Fragments fields are non-		* check that Fragment Number and Total Fragments fields are non-
	zero		zero
	* check that Fragment Number field is less than or equal to Total		* check that Fragment Number field is less than or equal to Total
	Fragments field		Fragments field
	* if reassembling has already started, check that Total Fragments		* if reassembling has already started, check that Total Fragments
	field is equal to or greater than Total Fragments field in		field is equal to or greater than Total Fragments field in
	fragments, that have already received		fragments, that have already received
	If either of this tests fails message MUST be silently discarded.		If any of this tests fails message MUST be silently discarded.
	o Check, that this IKE Fragment Message is new for the receiver and		o Check, that this IKE Fragment Message is new for the receiver and
	not a replay. If IKE Fragment message with the same Message ID,		not a replay. If IKE Fragment message with the same Message ID,
	same Fragment Number and same Total Fragments fields was already		same Fragment Number and same Total Fragments fields was already
	received and successfully processed, this message is considered a		received and successfully processed, this message is considered a
	replay and MUST be silently discarded.		replay and MUST be silently discarded.
	o Verify IKE Fragment Message authenticity by checking ICV in		o Verify IKE Fragment Message authenticity by checking ICV in
	Encrypted Fragment Payload. If ICV check fails message MUST be		Encrypted Fragment Payload. If ICV check fails message MUST be
	silently discarded.		silently discarded.
	skipping to change at page 10, line 52		skipping to change at page 11, line 41
	o If reassembling isn't finished yet and Total Fragments field in		o If reassembling isn't finished yet and Total Fragments field in
	received IKE Fragment Message is greater than this field in		received IKE Fragment Message is greater than this field in
	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 already decrypted Encrypted
	decrypted and merged together to form content of original Encrypted		Fragment Payloads is merged together to form content of original
	Payload, and, therefore, along with IKE Header and unencrypted		Encrypted Payload, and, therefore, along with IKE Header and
	Payloads (if any), original message. Then it is processed as if it		unencrypted Payloads (if any), original message. Then it is
	was received, verified and decrypted as regular unfragmented message.		processed as if it was received, verified and decrypted as regular
			unfragmented message.
	If receiver does't get all IKE 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 Exchange		fragmented request Message (in case of Initiator) or deems Exchange
	to have failed. If Exchange is abandoned, all received so far IKE		to have failed. If Exchange is abandoned, all received so far IKE
	Fragment Messages for that Exchange MUST be discarded.		Fragment Messages for that Exchange MUST be discarded.
	2.6.1. Changes in Replay Protection Logic		2.6.1. Changes in Replay Protection Logic
	skipping to change at page 15, line 11		skipping to change at page 15, line 11
	response Fragment Messages are sent back all together only when all		response Fragment Messages are sent back all together only when all
	fragments of request are received, the original request Message is		fragments of request are received, the original request Message is
	reassembled and successfully processed.		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 DoS attack.
	Service attack.
			Security Considerations Section of [RFC5996] mentions possible attack
			on IKE by exhausting of the IP reassembly buffers. The mechanism,
			described in this document, allows IKE to avoid IP-fragmentation and
			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 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:
	skipping to change at page 18, line 25		skipping to change at page 18, line 25
	[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.
	8.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.
			[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
			November 1990.
	[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.
			[RFC4787] Audet, F. and C. Jennings, "Network Address Translation
			(NAT) Behavioral Requirements for Unicast UDP", BCP 127,
			RFC 4787, January 2007.
			[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
			Discovery", RFC 4821, March 2007.
	[RFC5282] Black, D. and D. McGrew, "Using Authenticated Encryption		[RFC5282] Black, D. and D. McGrew, "Using Authenticated Encryption
	Algorithms with the Encrypted Payload of the Internet Key		Algorithms with the Encrypted Payload of the Internet Key
	Exchange version 2 (IKEv2) Protocol", RFC 5282,		Exchange version 2 (IKEv2) Protocol", RFC 5282,
	August 2008.		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.
			[RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A.,
			and H. Ashida, "Common Requirements for Carrier-Grade NATs
			(CGNs)", BCP 127, RFC 6888, April 2013.
			[DOSUDPPROT]
			Kaufman, C., Perlman, R., and B. Sommerfeld, "DoS
			protection for UDP-based protocols", ACM Conference on
			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 looking valid 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 reassempling 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
End of changes. 18 change blocks.
	30 lines changed or deleted		111 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/