< draft-ietf-ipsecme-iptfs-05.txt		draft-ietf-ipsecme-iptfs-06.txt >
	Network Working Group C. Hopps		Network Working Group C. Hopps
	Internet-Draft LabN Consulting, L.L.C.		Internet-Draft LabN Consulting, L.L.C.
	Intended status: Standards Track December 20, 2020		Intended status: Standards Track January 19, 2021
	Expires: June 23, 2021		Expires: July 23, 2021
	IP Traffic Flow Security Using Aggregation and Fragmentation		IP-TFS: IP Traffic Flow Security Using Aggregation and Fragmentation
	draft-ietf-ipsecme-iptfs-05		draft-ietf-ipsecme-iptfs-06
	Abstract		Abstract
	This document describes a mechanism to enhance IPsec traffic flow		This document describes a mechanism to enhance IPsec traffic flow
	security by adding traffic flow confidentiality to encrypted IP		security by adding traffic flow confidentiality to encrypted IP
	encapsulated traffic. Traffic flow confidentiality is provided by		encapsulated traffic. Traffic flow confidentiality is provided by
	obscuring the size and frequency of IP traffic using a fixed-sized,		obscuring the size and frequency of IP traffic using a fixed-sized,
	constant-send-rate IPsec tunnel. The solution allows for congestion		constant-send-rate IPsec tunnel. The solution allows for congestion
	control as well as non-constant send-rate usage.		control as well as non-constant send-rate usage.
	skipping to change at page 1, line 35 ¶		skipping to change at page 1, line 35 ¶
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://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 June 23, 2021.		This Internet-Draft will expire on July 23, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2021 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
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://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 17 ¶		skipping to change at page 2, line 17 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Terminology & Concepts . . . . . . . . . . . . . . . . . 3		1.1. Terminology & Concepts . . . . . . . . . . . . . . . . . 3
	2. The IP-TFS Tunnel . . . . . . . . . . . . . . . . . . . . . . 4		2. The IP-TFS Tunnel . . . . . . . . . . . . . . . . . . . . . . 4
	2.1. Tunnel Content . . . . . . . . . . . . . . . . . . . . . 4		2.1. Tunnel Content . . . . . . . . . . . . . . . . . . . . . 4
	2.2. Payload Content . . . . . . . . . . . . . . . . . . . . . 5		2.2. Payload Content . . . . . . . . . . . . . . . . . . . . . 5
	2.2.1. Data Blocks . . . . . . . . . . . . . . . . . . . . . 6		2.2.1. Data Blocks . . . . . . . . . . . . . . . . . . . . . 6
	2.2.2. No Implicit End Padding Required . . . . . . . . . . 6		2.2.2. No Implicit End Padding Required . . . . . . . . . . 6
	2.2.3. Fragmentation, Sequence Numbers and All-Pad Payloads 6		2.2.3. Fragmentation, Sequence Numbers and All-Pad Payloads 6
	2.2.4. Empty Payload . . . . . . . . . . . . . . . . . . . . 7		2.2.4. Empty Payload . . . . . . . . . . . . . . . . . . . . 8
	2.2.5. IP Header Value Mapping . . . . . . . . . . . . . . . 8		2.2.5. IP Header Value Mapping . . . . . . . . . . . . . . . 8
	2.2.6. IP Time-To-Live (TTL) and Tunnel errors . . . . . . . 8		2.2.6. IP Time-To-Live (TTL) and Tunnel errors . . . . . . . 9
	2.2.7. Effective MTU of the Tunnel . . . . . . . . . . . . . 8		2.2.7. Effective MTU of the Tunnel . . . . . . . . . . . . . 9
	2.3. Exclusive SA Use . . . . . . . . . . . . . . . . . . . . 8		2.3. Exclusive SA Use . . . . . . . . . . . . . . . . . . . . 9
	2.4. Modes of Operation . . . . . . . . . . . . . . . . . . . 9		2.4. Modes of Operation . . . . . . . . . . . . . . . . . . . 9
	2.4.1. Non-Congestion Controlled Mode . . . . . . . . . . . 9		2.4.1. Non-Congestion Controlled Mode . . . . . . . . . . . 9
	2.4.2. Congestion Controlled Mode . . . . . . . . . . . . . 9		2.4.2. Congestion Controlled Mode . . . . . . . . . . . . . 10
	3. Congestion Information . . . . . . . . . . . . . . . . . . . 10		3. Congestion Information . . . . . . . . . . . . . . . . . . . 11
	3.1. ECN Support . . . . . . . . . . . . . . . . . . . . . . . 12		3.1. ECN Support . . . . . . . . . . . . . . . . . . . . . . . 12
	4. Configuration . . . . . . . . . . . . . . . . . . . . . . . . 12		4. Configuration . . . . . . . . . . . . . . . . . . . . . . . . 13
	4.1. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . 12		4.1. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . 13
	4.2. Fixed Packet Size . . . . . . . . . . . . . . . . . . . . 12		4.2. Fixed Packet Size . . . . . . . . . . . . . . . . . . . . 13
	4.3. Congestion Control . . . . . . . . . . . . . . . . . . . 12		4.3. Congestion Control . . . . . . . . . . . . . . . . . . . 13
	5. IKEv2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13		5. IKEv2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	5.1. USE_AGGFRAG Notification Message . . . . . . . . . . . . 13		5.1. USE_AGGFRAG Notification Message . . . . . . . . . . . . 13
	6. Packet and Data Formats . . . . . . . . . . . . . . . . . . . 13		6. Packet and Data Formats . . . . . . . . . . . . . . . . . . . 14
	6.1. AGGFRAG_PAYLOAD Payload . . . . . . . . . . . . . . . . . 13		6.1. AGGFRAG_PAYLOAD Payload . . . . . . . . . . . . . . . . . 14
	6.1.1. Non-Congestion Control AGGFRAG_PAYLOAD Payload Format 14		6.1.1. Non-Congestion Control AGGFRAG_PAYLOAD Payload Format 15
	6.1.2. Congestion Control AGGFRAG_PAYLOAD Payload Format . . 15		6.1.2. Congestion Control AGGFRAG_PAYLOAD Payload Format . . 15
	6.1.3. Data Blocks . . . . . . . . . . . . . . . . . . . . . 16		6.1.3. Data Blocks . . . . . . . . . . . . . . . . . . . . . 17
	6.1.4. IKEv2 USE_AGGFRAG Notification Message . . . . . . . 18		6.1.4. IKEv2 USE_AGGFRAG Notification Message . . . . . . . 19
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
	7.1. AGGFRAG_PAYLOAD Sub-Type Registry . . . . . . . . . . . . 19		7.1. AGGFRAG_PAYLOAD Sub-Type Registry . . . . . . . . . . . . 20
	7.2. USE_AGGFRAG Notify Message Status Type . . . . . . . . . 19		7.2. USE_AGGFRAG Notify Message Status Type . . . . . . . . . 20
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 19		8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
	9.1. Normative References . . . . . . . . . . . . . . . . . . 20		9.1. Normative References . . . . . . . . . . . . . . . . . . 21
	9.2. Informative References . . . . . . . . . . . . . . . . . 20		9.2. Informative References . . . . . . . . . . . . . . . . . 21
	Appendix A. Example Of An Encapsulated IP Packet Flow . . . . . 22		Appendix A. Example Of An Encapsulated IP Packet Flow . . . . . 23
	Appendix B. A Send and Loss Event Rate Calculation . . . . . . . 23		Appendix B. A Send and Loss Event Rate Calculation . . . . . . . 24
	Appendix C. Comparisons of IP-TFS . . . . . . . . . . . . . . . 23		Appendix C. Comparisons of IP-TFS . . . . . . . . . . . . . . . 24
	C.1. Comparing Overhead . . . . . . . . . . . . . . . . . . . 23		C.1. Comparing Overhead . . . . . . . . . . . . . . . . . . . 24
	C.1.1. IP-TFS Overhead . . . . . . . . . . . . . . . . . . . 23		C.1.1. IP-TFS Overhead . . . . . . . . . . . . . . . . . . . 24
	C.1.2. ESP with Padding Overhead . . . . . . . . . . . . . . 24		C.1.2. ESP with Padding Overhead . . . . . . . . . . . . . . 25
	C.2. Overhead Comparison . . . . . . . . . . . . . . . . . . . 25		C.2. Overhead Comparison . . . . . . . . . . . . . . . . . . . 26
	C.3. Comparing Available Bandwidth . . . . . . . . . . . . . . 25		C.3. Comparing Available Bandwidth . . . . . . . . . . . . . . 26
	C.3.1. Ethernet . . . . . . . . . . . . . . . . . . . . . . 26		C.3.1. Ethernet . . . . . . . . . . . . . . . . . . . . . . 27
	Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 28		Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 29
	Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 28		Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 29
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 28		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 29
	1. Introduction		1. Introduction
	Traffic Analysis ([RFC4301], [AppCrypt]) is the act of extracting		Traffic Analysis ([RFC4301], [AppCrypt]) is the act of extracting
	information about data being sent through a network. While one may		information about data being sent through a network. While one may
	directly obscure the data through the use of encryption [RFC4303],		directly obscure the data through the use of encryption [RFC4303],
	the traffic pattern itself exposes information due to variations in		the traffic pattern itself exposes information due to variations in
	it's shape and timing ([I-D.iab-wire-image], [AppCrypt]). Hiding the		it's shape and timing ([I-D.iab-wire-image], [AppCrypt]). Hiding the
	size and frequency of traffic is referred to as Traffic Flow		size and frequency of traffic is referred to as Traffic Flow
	Confidentiality (TFC) per [RFC4303].		Confidentiality (TFC) per [RFC4303].
	skipping to change at page 6, line 52 ¶		skipping to change at page 6, line 52 ¶
	packet fragment payloads. This possible interleaving of all-pad		packet fragment payloads. This possible interleaving of all-pad
	payloads allows the sender to always be able to send a tunnel packet,		payloads allows the sender to always be able to send a tunnel packet,
	regardless of the encapsulation computational requirements.		regardless of the encapsulation computational requirements.
	When a receiver is reassembling an inner-packet, and it receives an		When a receiver is reassembling an inner-packet, and it receives an
	"all-pad" payload, it increments the expected sequence number that		"all-pad" payload, it increments the expected sequence number that
	the next inner-packet fragment is expected to arrive in.		the next inner-packet fragment is expected to arrive in.
	Given the above, the receiver will need to handle out-of-order		Given the above, the receiver will need to handle out-of-order
	arrival of outer ESP packets prior to reassembly processing. ESP		arrival of outer ESP packets prior to reassembly processing. ESP
	already provides for detecting replay attacks (normally) utilizing a		already provides for optionally detecting replay attacks. Detecting
	window. A similar sequence number based sliding window can be used		replay attacks normally utilizes a window method. A similar sequence
	to correct re-ordering of the outer packet stream. Receiving a		number based sliding window can be used to correct re-ordering of the
	larger (newer) sequence number packet advances the window, and		outer packet stream. Receiving a larger (newer) sequence number
	received older ESP packets whose sequence numbers the window has		packet advances the window, and received older ESP packets whose
	passed by are dropped. A good choice for the size of this window		sequence numbers the window has passed by are dropped. A good choice
	depends on the amount of re-ordering the user may normally		for the size of this window depends on the amount of re-ordering the
	experience. As the amount of reordering that may be present is hard		user may normally experience.
	to predict the window size SHOULD be configurable by the user.
	Implementations MAY also dynamically adjust the reordering window		As the amount of reordering that may be present is hard to predict
	based on actual reordering seen in arriving packets. Finally, we		the window size SHOULD be configurable by the user. Implementations
	note that as IP-TFS is sending a continuous stream of packets there		MAY also dynamically adjust the reordering window based on actual
	is no requirement for timers (although there's no prohibition either)		reordering seen in arriving packets. Finally, we note that as IP-TFS
	as newly arrived packets will cause the window to advance and older		is sending a continuous stream of packets there is no requirement for
	packets will then be processed as they leave the window.		timers (although there's no prohibition either) as newly arrived
			packets will cause the window to advance and older packets will then
			be processed as they leave the window. Implementations that are
			concerned about memory use when packets are delayed (e.g., when an SA
			deletion is delayed) can of course use timers to drop packets as
			well.
			While ESP guarantees an increasing sequence number with subsequently
			sent packets, it does not actually require the sequence numbers to be
			generated with no gaps (e.g., sending only even numbered sequence
			numbers would be allowed as long as they are always increasing).
			Gaps in the sequence numbers will not work for this specification so
			the sequence number stream is further restricted to not contain gaps
			(i.e., each subsequent outer packet must be sent with the sequence
			number incremented by 1).
			When using the AGGFRAG_PAYLOAD in conjunction with replay detection,
			the window size for both MAY be reduced to share the smaller of the
			two window sizes. This is b/c packets outside of the smaller window
			but inside the larger would still be dropped by the mechanism with
			the smaller window size.
			Finally, as sequence numbers are reset when switching SAs (e.g., when
			re-keying a child SA), an implementation SHOULD NOT send initial
			fragments of an inner packet using one SA and subsequent fragments in
			a different SA.
	2.2.3.1. Optional Extra Padding		2.2.3.1. Optional Extra Padding
	When the tunnel bandwidth is not being fully utilized, an		When the tunnel bandwidth is not being fully utilized, an
	implementation MAY pad-out the current encapsulating packet in order		implementation MAY pad-out the current encapsulating packet in order
	to deliver an inner packet un-fragmented in the following outer		to deliver an inner packet un-fragmented in the following outer
	packet. The benefit would be to avoid inner-packet fragmentation in		packet. The benefit would be to avoid inner-packet fragmentation in
	the presence of a bursty offered load (non-bursty traffic will		the presence of a bursty offered load (non-bursty traffic will
	naturally not fragment). The cost is complexity and added delay of		naturally not fragment). An implementation MAY also choose to allow
	inner traffic. The main advantage to avoiding fragmentation is to		for a minimum fragment size to be configured (e.g., as a percentage
	minimize inner packet loss in the presence of outer packet loss.		of the AGGFRAG_PAYLOAD payload size) to avoid fragmentation at the
	When this is worthwhile (e.g., how much loss and what type of loss is		cost of tunnel bandwidth. The cost with these methods is complexity
	required, given different inner traffic shapes and utilization, for		and added delay of inner traffic. The main advantage to avoiding
	this to make sense), and what values to use for the allowable/added		fragmentation is to minimize inner packet loss in the presence of
	delay may be worth researching, but is outside the scope of this		outer packet loss. When this is worthwhile (e.g., how much loss and
	document.		what type of loss is required, given different inner traffic shapes
			and utilization, for this to make sense), and what values to use for
			the allowable/added delay may be worth researching, but is outside
			the scope of this document.
	While use of padding to avoid fragmentation does not impact		While use of padding to avoid fragmentation does not impact
	interoperability, used inappropriately it can reduce the effective		interoperability, used inappropriately it can reduce the effective
	throughput of a tunnel. Implementations implementing the above		throughput of a tunnel. Implementations implementing either of the
	approach will need to take care to not reduce the effective capacity,		above approaches will need to take care to not reduce the effective
	and overall utility, of the tunnel through the overuse of padding.		capacity, and overall utility, of the tunnel through the overuse of
			padding.
	2.2.4. Empty Payload		2.2.4. Empty Payload
	In order to support reporting of congestion control information		In order to support reporting of congestion control information
	(described later) on a non-AGGFRAG_PAYLOAD enabled SA, IP-TFS allows		(described later) on a non-AGGFRAG_PAYLOAD enabled SA, IP-TFS allows
	for the sending of an AGGFRAG_PAYLOAD payload with no data blocks		for the sending of an AGGFRAG_PAYLOAD payload with no data blocks
	(i.e., the ESP payload length is equal to the AGGFRAG_PAYLOAD header		(i.e., the ESP payload length is equal to the AGGFRAG_PAYLOAD header
	length). This special payload is called an empty payload.		length). This special payload is called an empty payload.
	2.2.5. IP Header Value Mapping		2.2.5. IP Header Value Mapping
	skipping to change at page 8, line 25 ¶		skipping to change at page 8, line 50 ¶
	unrelated to the IP-TFS tunnel functionality; IP-TFS never IP		unrelated to the IP-TFS tunnel functionality; IP-TFS never IP
	fragments the inner packets and the inner packets will not affect the		fragments the inner packets and the inner packets will not affect the
	fragmentation of the outer encapsulation packets. Likewise, the ECN		fragmentation of the outer encapsulation packets. Likewise, the ECN
	value need not be mapped as any congestion related to the constant-		value need not be mapped as any congestion related to the constant-
	send-rate IP-TFS tunnel is unrelated (by design!) to the inner		send-rate IP-TFS tunnel is unrelated (by design!) to the inner
	traffic flow. Finally, by default the DS field SHOULD NOT be copied		traffic flow. Finally, by default the DS field SHOULD NOT be copied
	although an implementation MAY choose to allow for configuration to		although an implementation MAY choose to allow for configuration to
	override this behavior. An implementation SHOULD also allow the DS		override this behavior. An implementation SHOULD also allow the DS
	value to be set by configuration.		value to be set by configuration.
			It is worth noting that an implementation MAY still set the ECN value
			of inner packets based on the normal ECN specification ([RFC3168]).
	2.2.6. IP Time-To-Live (TTL) and Tunnel errors		2.2.6. IP Time-To-Live (TTL) and Tunnel errors
	[RFC4301] specifies how to modify the inner packet TTL ([RFC0791]).		[RFC4301] specifies how to modify the inner packet TTL ([RFC0791]).
	Any errors (e.g., ICMP errors arriving back at the tunnel ingress due		Any errors (e.g., ICMP errors arriving back at the tunnel ingress due
	to tunnel traffic) should be handled the same as with non IP-TFS		to tunnel traffic) should be handled the same as with non IP-TFS
	IPsec tunnels.		IPsec tunnels.
	2.2.7. Effective MTU of the Tunnel		2.2.7. Effective MTU of the Tunnel
	Unlike [RFC4301], there is normally no effective MTU (EMTU) on an IP-		Unlike [RFC4301], there is normally no effective MTU (EMTU) on an IP-
	TFS tunnel as all IP packet sizes are properly transmitted without		TFS tunnel as all IP packet sizes are properly transmitted without
	requiring IP fragmentation prior to tunnel ingress.		requiring IP fragmentation prior to tunnel ingress. That said, an
			implementation MAY allow for explicitly configuring an MTU for the
			tunnel.
	If IP-TFS fragmentation has been disabled, then the tunnel's EMTU and		If IP-TFS fragmentation has been disabled, then the tunnel's EMTU and
	behaviors are the same as normal IPsec tunnels ([RFC4301]).		behaviors are the same as normal IPsec tunnels ([RFC4301]).
	2.3. Exclusive SA Use		2.3. Exclusive SA Use
	It is not the intention of this specification to allow for mixed use		It is not the intention of this specification to allow for mixed use
	of an AGGFRAG_PAYLOAD enabled SA. In other words, an SA that has		of an AGGFRAG_PAYLOAD enabled SA. In other words, an SA that has
	AGGFRAG_PAYLOAD enabled MUST NOT have non-AGGFRAG_PAYLOAD payloads		AGGFRAG_PAYLOAD enabled MUST NOT have non-AGGFRAG_PAYLOAD payloads
	such as IP (IP protocol 4), TCP transport (IP protocol 6), or ESP pad		such as IP (IP protocol 4), TCP transport (IP protocol 6), or ESP pad
	packets (protocol 59) intermixed with non-empty AGGFRAG_PAYLOAD		packets (protocol 59) intermixed with non-empty AGGFRAG_PAYLOAD
	payloads. While it's possible to envision making the algorithm work		payloads. Empty AGGFRAG_PAYLOAD payloads (Section 2.2.4) are used to
	in the presence of sequence number skips in the AGGFRAG_PAYLOAD		transmit congestion control information on non-IP-TFS enabled SAs, so
	payload stream, the added complexity is not deemed worthwhile. Other		intermixing is allowed in this specific case. While it's possible to
	IPsec uses can configure and use their own SAs.		envision making the algorithm work in the presence of sequence number
			skips in the AGGFRAG_PAYLOAD payload stream, the added complexity is
			not deemed worthwhile. Other IPsec uses can configure and use their
			own SAs.
	2.4. Modes of Operation		2.4. Modes of Operation
	Just as with normal IPsec/ESP tunnels, IP-TFS tunnels are		Just as with normal IPsec/ESP tunnels, IP-TFS tunnels are
	unidirectional. Bidirectional IP-TFS functionality is achieved by		unidirectional. Bidirectional IP-TFS functionality is achieved by
	setting up 2 IP-TFS tunnels, one in either direction.		setting up 2 IP-TFS tunnels, one in either direction.
	An IP-TFS tunnel can operate in 2 modes, a non-congestion controlled		An IP-TFS tunnel can operate in 2 modes, a non-congestion controlled
	mode and congestion controlled mode.		mode and congestion controlled mode.
	skipping to change at page 13, line 29 ¶		skipping to change at page 14, line 17 ¶
	requesting a new Child SA (either during the initial IKE_AUTH or		requesting a new Child SA (either during the initial IKE_AUTH or
	during non-rekeying CREATE_CHILD_SA exchanges). If the request is		during non-rekeying CREATE_CHILD_SA exchanges). If the request is
	accepted then response MUST also include a notification of type		accepted then response MUST also include a notification of type
	USE_AGGFRAG. If the responder declines the request the child SA will		USE_AGGFRAG. If the responder declines the request the child SA will
	be established without AGGFRAG_PAYLOAD payload use enabled. If this		be established without AGGFRAG_PAYLOAD payload use enabled. If this
	is unacceptable to the initiator, the initiator MUST delete the child		is unacceptable to the initiator, the initiator MUST delete the child
	SA.		SA.
	The USE_AGGFRAG notification MUST NOT be sent, and MUST be ignored,		The USE_AGGFRAG notification MUST NOT be sent, and MUST be ignored,
	during a CREATE_CHILD_SA rekeying exchange as it is not allowed to		during a CREATE_CHILD_SA rekeying exchange as it is not allowed to
	change use of the AGGFRAG_PAYLOAD payload type during rekeying.		change use of the AGGFRAG_PAYLOAD payload type during rekeying. A
			new child SA due to re-keying inherits the use of AGGFRAG_PAYLOAD
			from the re-keyed child SA.
	The USE_AGGFRAG notification contains a 1 octet payload of flags that		The USE_AGGFRAG notification contains a 1 octet payload of flags that
	specify any requirements from the sender of the message. If any		specify any requirements from the sender of the message. If any
	requirement flags are not understood or cannot be supported by the		requirement flags are not understood or cannot be supported by the
	receiver then the receiver should not enable use of AGGFRAG_PAYLOAD		receiver then the receiver should not enable use of AGGFRAG_PAYLOAD
	payload type (either by not responding with the USE_AGGFRAG		payload type (either by not responding with the USE_AGGFRAG
	notification, or in the case of the initiator, by deleting the child		notification, or in the case of the initiator, by deleting the child
	SA if the now established non-AGGFRAG_PAYLOAD using SA is		SA if the now established non-AGGFRAG_PAYLOAD using SA is
	unacceptable).		unacceptable).
End of changes. 18 change blocks.
	72 lines changed or deleted		111 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/