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/