draft-ietf-ipsecme-iptfs-04.txt   draft-ietf-ipsecme-iptfs-05.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 18, 2020 Intended status: Standards Track December 20, 2020
Expires: June 21, 2021 Expires: June 23, 2021
IP Traffic Flow Security Using Aggregation and Fragmentation IP Traffic Flow Security Using Aggregation and Fragmentation
draft-ietf-ipsecme-iptfs-04 draft-ietf-ipsecme-iptfs-05
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 21, 2021. This Internet-Draft will expire on June 23, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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
skipping to change at page 2, line 18 skipping to change at page 2, line 18
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 . . . . . . . . . . . . . . . . . . . . 7
2.2.5. IP Header Value Mapping . . . . . . . . . . . . . . . 7 2.2.5. IP Header Value Mapping . . . . . . . . . . . . . . . 8
2.3. Exclusive SA Use . . . . . . . . . . . . . . . . . . . . 7 2.2.6. IP Time-To-Live (TTL) and Tunnel errors . . . . . . . 8
2.4. Modes of Operation . . . . . . . . . . . . . . . . . . . 7 2.2.7. Effective MTU of the Tunnel . . . . . . . . . . . . . 8
2.4.1. Non-Congestion Controlled Mode . . . . . . . . . . . 8 2.3. Exclusive SA Use . . . . . . . . . . . . . . . . . . . . 8
2.4.2. Congestion Controlled Mode . . . . . . . . . . . . . 8 2.4. Modes of Operation . . . . . . . . . . . . . . . . . . . 9
3. Congestion Information . . . . . . . . . . . . . . . . . . . 9 2.4.1. Non-Congestion Controlled Mode . . . . . . . . . . . 9
3.1. ECN Support . . . . . . . . . . . . . . . . . . . . . . . 10 2.4.2. Congestion Controlled Mode . . . . . . . . . . . . . 9
4. Configuration . . . . . . . . . . . . . . . . . . . . . . . . 11 3. Congestion Information . . . . . . . . . . . . . . . . . . . 10
4.1. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . 11 3.1. ECN Support . . . . . . . . . . . . . . . . . . . . . . . 12
4.2. Fixed Packet Size . . . . . . . . . . . . . . . . . . . . 11 4. Configuration . . . . . . . . . . . . . . . . . . . . . . . . 12
4.3. Congestion Control . . . . . . . . . . . . . . . . . . . 11 4.1. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . 12
5. IKEv2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2. Fixed Packet Size . . . . . . . . . . . . . . . . . . . . 12
5.1. USE_AGGFRAG Notification Message . . . . . . . . . . . . 11 4.3. Congestion Control . . . . . . . . . . . . . . . . . . . 12
6. Packet and Data Formats . . . . . . . . . . . . . . . . . . . 12 5. IKEv2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. AGGFRAG_PAYLOAD Payload . . . . . . . . . . . . . . . . . 12 5.1. USE_AGGFRAG Notification Message . . . . . . . . . . . . 13
6.1.1. Non-Congestion Control AGGFRAG_PAYLOAD Payload Format 13 6. Packet and Data Formats . . . . . . . . . . . . . . . . . . . 13
6.1.2. Congestion Control AGGFRAG_PAYLOAD Payload Format . . 13 6.1. AGGFRAG_PAYLOAD Payload . . . . . . . . . . . . . . . . . 13
6.1.3. Data Blocks . . . . . . . . . . . . . . . . . . . . . 15 6.1.1. Non-Congestion Control AGGFRAG_PAYLOAD Payload Format 14
6.1.4. IKEv2 USE_AGGFRAG Notification Message . . . . . . . 17 6.1.2. Congestion Control AGGFRAG_PAYLOAD Payload Format . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 6.1.3. Data Blocks . . . . . . . . . . . . . . . . . . . . . 16
7.1. AGGFRAG_PAYLOAD Sub-Type Registry . . . . . . . . . . . . 18 6.1.4. IKEv2 USE_AGGFRAG Notification Message . . . . . . . 18
7.2. USE_AGGFRAG Notify Message Status Type . . . . . . . . . 18 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7.1. AGGFRAG_PAYLOAD Sub-Type Registry . . . . . . . . . . . . 19
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 7.2. USE_AGGFRAG Notify Message Status Type . . . . . . . . . 19
9.1. Normative References . . . . . . . . . . . . . . . . . . 19 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9.2. Informative References . . . . . . . . . . . . . . . . . 19 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
Appendix A. Example Of An Encapsulated IP Packet Flow . . . . . 21 9.1. Normative References . . . . . . . . . . . . . . . . . . 20
Appendix B. A Send and Loss Event Rate Calculation . . . . . . . 21 9.2. Informative References . . . . . . . . . . . . . . . . . 20
Appendix C. Comparisons of IP-TFS . . . . . . . . . . . . . . . 22 Appendix A. Example Of An Encapsulated IP Packet Flow . . . . . 22
C.1. Comparing Overhead . . . . . . . . . . . . . . . . . . . 22 Appendix B. A Send and Loss Event Rate Calculation . . . . . . . 23
C.1.1. IP-TFS Overhead . . . . . . . . . . . . . . . . . . . 22 Appendix C. Comparisons of IP-TFS . . . . . . . . . . . . . . . 23
C.1.2. ESP with Padding Overhead . . . . . . . . . . . . . . 23 C.1. Comparing Overhead . . . . . . . . . . . . . . . . . . . 23
C.2. Overhead Comparison . . . . . . . . . . . . . . . . . . . 24 C.1.1. IP-TFS Overhead . . . . . . . . . . . . . . . . . . . 23
C.3. Comparing Available Bandwidth . . . . . . . . . . . . . . 24 C.1.2. ESP with Padding Overhead . . . . . . . . . . . . . . 24
C.3.1. Ethernet . . . . . . . . . . . . . . . . . . . . . . 25
Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 27 C.2. Overhead Comparison . . . . . . . . . . . . . . . . . . . 25
Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 27 C.3. Comparing Available Bandwidth . . . . . . . . . . . . . . 25
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 27 C.3.1. Ethernet . . . . . . . . . . . . . . . . . . . . . . 26
Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 28
Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 28
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 28
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 4, line 16 skipping to change at page 4, line 16
As mentioned in Section 1 IP-TFS utilizes an IPsec [RFC4303] tunnel As mentioned in Section 1 IP-TFS utilizes an IPsec [RFC4303] tunnel
(SA) as it's transport. To provide for full TFC, fixed-sized (SA) as it's transport. To provide for full TFC, fixed-sized
encapsulating packets are sent at a constant rate on the tunnel. encapsulating packets are sent at a constant rate on the tunnel.
The primary input to the tunnel algorithm is the requested bandwidth The primary input to the tunnel algorithm is the requested bandwidth
used by the tunnel. Two values are then required to provide for this used by the tunnel. Two values are then required to provide for this
bandwidth, the fixed size of the encapsulating packets, and rate at bandwidth, the fixed size of the encapsulating packets, and rate at
which to send them. which to send them.
The fixed packet size may either be specified manually or can be The fixed packet size MAY either be specified manually or could be
determined through the use of Path MTU discovery [RFC1191] and determined through the other methods such as the Packetization Layer
[RFC8201]. MTU Discovery (PLMTUD) ([RFC4821], [RFC8899]) or Path MTU discovery
(PMTUD) ([RFC1191], [RFC8201]). PMTUD is known to have issues so
PLMTUD is considered the more robust option.
Given the encapsulating packet size and the requested tunnel used Given the encapsulating packet size and the requested tunnel used
bandwidth, the corresponding packet send rate can be calculated. The bandwidth, the corresponding packet send rate can be calculated. The
packet send rate is the requested bandwidth divided by the size of packet send rate is the requested bandwidth divided by the size of
the encapsulating packet. the encapsulating packet.
The egress of the IP-TFS tunnel MUST allow for and expect the ingress The egress of the IP-TFS tunnel MUST allow for and expect the ingress
(sending) side of the IP-TFS tunnel to vary the size and rate of sent (sending) side of the IP-TFS tunnel to vary the size and rate of sent
encapsulating packets, unless constrained by other policy. encapsulating packets, unless constrained by other policy.
skipping to change at page 5, line 18 skipping to change at page 5, line 18
comprised of a 4 or 24 octet header followed by either a partial, a comprised of a 4 or 24 octet header followed by either a partial, a
full or multiple partial or full data blocks. The following diagram full or multiple partial or full data blocks. The following diagram
illustrates this payload within the ESP packet. See Section 6.1 for illustrates this payload within the ESP packet. See Section 6.1 for
the exact formats of the AGGFRAG_PAYLOAD payload. the exact formats of the AGGFRAG_PAYLOAD payload.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. Outer Encapsulating Header ... . . Outer Encapsulating Header ... .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. ESP Header... . . ESP Header... .
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| ... : BlockOffset | | [AGGFRAG subtype/flags] : BlockOffset |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
: [Optional Congestion Info] : : [Optional Congestion Info] :
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| DataBlocks ... ~ | DataBlocks ... ~
~ ~ ~ ~
~ | ~ |
+---------------------------------------------------------------| +---------------------------------------------------------------|
. ESP Trailer... . . ESP Trailer... .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
skipping to change at page 5, line 46 skipping to change at page 5, line 46
Conversely, if the "BlockOffset" value is non-zero it points to the Conversely, if the "BlockOffset" value is non-zero it points to the
start of the new data block, and the initial "DataBlocks" data start of the new data block, and the initial "DataBlocks" data
belongs to a previous data block that is still being re-assembled. belongs to a previous data block that is still being re-assembled.
The "BlockOffset" can point past the end of the "DataBlocks" data The "BlockOffset" can point past the end of the "DataBlocks" data
which indicates that the next data block occurs in a subsequent which indicates that the next data block occurs in a subsequent
encapsulating packet. encapsulating packet.
Having the "BlockOffset" always point at the next available data Having the "BlockOffset" always point at the next available data
block allows for recovering the next full inner packet in the block allows for recovering the next inner packet in the presence of
presence of outer encapsulating packet loss. outer encapsulating packet loss.
An example IP-TFS packet flow can be found in Appendix A. An example IP-TFS packet flow can be found in Appendix A.
2.2.1. Data Blocks 2.2.1. Data Blocks
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| Type | rest of IPv4, IPv6 or pad. | Type | rest of IPv4, IPv6 or pad.
+-------- +--------
Figure 2: Layout of IP-TFS data block Figure 2: Layout of IP-TFS data block
skipping to change at page 7, line 5 skipping to change at page 6, line 50
pad" payloads (i.e., payloads with a "BlockOffset" of zero and a pad" payloads (i.e., payloads with a "BlockOffset" of zero and a
single pad "DataBlock") in between the packets carrying the inner- single pad "DataBlock") in between the packets carrying the inner-
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
arrival of outer ESP packets prior to reassembly processing. ESP
already provides for detecting replay attacks (normally) utilizing a
window. A similar sequence number based sliding window can be used
to correct re-ordering of the outer packet stream. Receiving a
larger (newer) sequence number packet advances the window, and
received older ESP packets whose sequence numbers the window has
passed by are dropped. A good choice for the size of this window
depends on the amount of re-ordering the user may normally
experience. As the amount of reordering that may be present is hard
to predict the window size SHOULD be configurable by the user.
Implementations MAY also dynamically adjust the reordering window
based on actual reordering seen in arriving packets. Finally, we
note that as IP-TFS is sending a continuous stream of packets there
is no requirement for 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.
2.2.3.1. Optional Extra Padding
When the tunnel bandwidth is not being fully utilized, an
implementation MAY pad-out the current encapsulating packet in order
to deliver an inner packet un-fragmented in the following outer
packet. The benefit would be to avoid inner-packet fragmentation in
the presence of a bursty offered load (non-bursty traffic will
naturally not fragment). The cost is complexity and added delay of
inner traffic. The main advantage to avoiding fragmentation is to
minimize inner packet loss in the presence of outer packet loss.
When this is worthwhile (e.g., how much loss and 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
interoperability, used inappropriately it can reduce the effective
throughput of a tunnel. Implementations implementing the above
approach will need to take care to not reduce the effective 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 7, line 33 skipping to change at page 8, line 25
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.
2.2.6. IP Time-To-Live (TTL) and Tunnel errors
[RFC4301] specifies how to modify the inner packet TTL ([RFC0791]).
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
IPsec tunnels.
2.2.7. Effective MTU of the Tunnel
Unlike [RFC4301], there is normally no effective MTU (EMTU) on an IP-
TFS tunnel as all IP packet sizes are properly transmitted without
requiring IP fragmentation prior to tunnel ingress.
If IP-TFS fragmentation has been disabled, then the tunnel's EMTU and
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. While it's possible to envision making the algorithm work
in the presence of sequence number skips in the AGGFRAG_PAYLOAD in the presence of sequence number skips in the AGGFRAG_PAYLOAD
payload stream, the added complexity is not deemed worthwhile. Other payload stream, the added complexity is not deemed worthwhile. Other
skipping to change at page 11, line 31 skipping to change at page 12, line 40
Bandwidth is a local configuration option. For non-congestion Bandwidth is a local configuration option. For non-congestion
controlled mode the bandwidth SHOULD be configured. For congestion controlled mode the bandwidth SHOULD be configured. For congestion
controlled mode one can configure the bandwidth or have no controlled mode one can configure the bandwidth or have no
configuration and let congestion control discover the maximum configuration and let congestion control discover the maximum
bandwidth available. No standardized configuration method is bandwidth available. No standardized configuration method is
required. required.
4.2. Fixed Packet Size 4.2. Fixed Packet Size
The fixed packet size to be used for the tunnel encapsulation packets The fixed packet size to be used for the tunnel encapsulation packets
can be configured manually or can be automatically determined using MAY be configured manually or can be automatically determined using
Path MTU discovery (see [RFC1191] and [RFC8201]). No standardized other methods such as PLMTUD ([RFC4821], [RFC8899]) or PMTUD
configuration method is required. ([RFC1191], [RFC8201]). As PMTUD is known to have issues, PLMTUD is
considered the more robust option. No standardized configuration
method is required.
4.3. Congestion Control 4.3. Congestion Control
Congestion control is a local configuration option. No standardized Congestion control is a local configuration option. No standardized
configuration method is required. configuration method is required.
5. IKEv2 5. IKEv2
5.1. USE_AGGFRAG Notification Message 5.1. USE_AGGFRAG Notification Message
skipping to change at page 20, line 30 skipping to change at page 21, line 30
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>. December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for
Datagram Congestion Control Protocol (DCCP) Congestion Datagram Congestion Control Protocol (DCCP) Congestion
Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342,
DOI 10.17487/RFC4342, March 2006, DOI 10.17487/RFC4342, March 2006,
<https://www.rfc-editor.org/info/rfc4342>. <https://www.rfc-editor.org/info/rfc4342>.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
<https://www.rfc-editor.org/info/rfc4821>.
[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP
Friendly Rate Control (TFRC): Protocol Specification", Friendly Rate Control (TFRC): Protocol Specification",
RFC 5348, DOI 10.17487/RFC5348, September 2008, RFC 5348, DOI 10.17487/RFC5348, September 2008,
<https://www.rfc-editor.org/info/rfc5348>. <https://www.rfc-editor.org/info/rfc5348>.
[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code
Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January
2014, <https://www.rfc-editor.org/info/rfc7120>. 2014, <https://www.rfc-editor.org/info/rfc7120>.
[RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black,
skipping to change at page 21, line 15 skipping to change at page 22, line 20
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>. <https://www.rfc-editor.org/info/rfc8200>.
[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
"Path MTU Discovery for IP version 6", STD 87, RFC 8201, "Path MTU Discovery for IP version 6", STD 87, RFC 8201,
DOI 10.17487/RFC8201, July 2017, DOI 10.17487/RFC8201, July 2017,
<https://www.rfc-editor.org/info/rfc8201>. <https://www.rfc-editor.org/info/rfc8201>.
[RFC8899] Fairhurst, G., Jones, T., Tuexen, M., Ruengeler, I., and
T. Voelker, "Packetization Layer Path MTU Discovery for
Datagram Transports", RFC 8899, DOI 10.17487/RFC8899,
September 2020, <https://www.rfc-editor.org/info/rfc8899>.
Appendix A. Example Of An Encapsulated IP Packet Flow Appendix A. Example Of An Encapsulated IP Packet Flow
Below an example inner IP packet flow within the encapsulating tunnel Below an example inner IP packet flow within the encapsulating tunnel
packet stream is shown. Notice how encapsulated IP packets can start packet stream is shown. Notice how encapsulated IP packets can start
and end anywhere, and more than one or less than 1 may occur in a and end anywhere, and more than one or less than 1 may occur in a
single encapsulating packet. single encapsulating packet.
Offset: 0 Offset: 100 Offset: 2900 Offset: 1400 Offset: 0 Offset: 100 Offset: 2900 Offset: 1400
[ ESP1 (1500) ][ ESP2 (1500) ][ ESP3 (1500) ][ ESP4 (1500) ] [ ESP1 (1500) ][ ESP2 (1500) ][ ESP3 (1500) ][ ESP4 (1500) ]
[--800--][--800--][60][-240-][--4000----------------------][pad] [--800--][--800--][60][-240-][--4000----------------------][pad]
skipping to change at page 27, line 9 skipping to change at page 28, line 9
Notice that the latency values are very similar between the two Notice that the latency values are very similar between the two
solutions; however, whereas IP-TFS provides for constant high solutions; however, whereas IP-TFS provides for constant high
bandwidth, in some cases even exceeding native Ethernet, ESP with bandwidth, in some cases even exceeding native Ethernet, ESP with
padding often greatly reduces available bandwidth. padding often greatly reduces available bandwidth.
Appendix D. Acknowledgements Appendix D. Acknowledgements
We would like to thank Don Fedyk for help in reviewing and editing We would like to thank Don Fedyk for help in reviewing and editing
this work. We would also like to thank Valery Smyslov for reviews this work. We would also like to thank Valery Smyslov for reviews
and suggestions for improvements. and suggestions for improvements as well as Joseph Touch for the
transport area review and suggested improvements.
Appendix E. Contributors Appendix E. Contributors
The following people made significant contributions to this document. The following people made significant contributions to this document.
Lou Berger Lou Berger
LabN Consulting, L.L.C. LabN Consulting, L.L.C.
Email: lberger@labn.net Email: lberger@labn.net
 End of changes. 13 change blocks. 
52 lines changed or deleted 126 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/