draft-ietf-ipsecme-iptfs-01.txt   draft-ietf-ipsecme-iptfs-02.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 March 2, 2020 Intended status: Standards Track September 30, 2020
Expires: September 3, 2020 Expires: April 3, 2021
IP Traffic Flow Security IP Traffic Flow Security
draft-ietf-ipsecme-iptfs-01 draft-ietf-ipsecme-iptfs-02
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. control as well.
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 September 3, 2020. This Internet-Draft will expire on April 3, 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 16 skipping to change at page 2, line 16
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. IPTFS_PROTOCOL Payload Content . . . . . . . . . . . . . 4 2.2. IPTFS_PROTOCOL Payload Content . . . . . . . . . . . . . 4
2.2.1. Data Blocks . . . . . . . . . . . . . . . . . . . . . 5 2.2.1. Data Blocks . . . . . . . . . . . . . . . . . . . . . 5
2.2.2. No Implicit End Padding Required . . . . . . . . . . 6 2.2.2. No Implicit End Padding Required . . . . . . . . . . 6
2.2.3. Empty Payload . . . . . . . . . . . . . . . . . . . . 6 2.2.3. Fragmentation, Sequence Numbers and All-Pad Payloads 6
2.2.4. IP Header Value Mapping . . . . . . . . . . . . . . . 6 2.2.4. Empty Payload . . . . . . . . . . . . . . . . . . . . 6
2.2.5. IP Header Value Mapping . . . . . . . . . . . . . . . 7
2.3. Exclusive SA Use . . . . . . . . . . . . . . . . . . . . 7 2.3. Exclusive SA Use . . . . . . . . . . . . . . . . . . . . 7
2.4. Initiating IP-TFS Operation On The SA. . . . . . . . . . 7 2.4. Zero-Conf Receive-Side Operation On The SA. . . . . . . . 7
2.5. Modes of Operation . . . . . . . . . . . . . . . . . . . 7 2.5. Modes of Operation . . . . . . . . . . . . . . . . . . . 7
2.5.1. Non-Congestion Controlled Mode . . . . . . . . . . . 7 2.5.1. Non-Congestion Controlled Mode . . . . . . . . . . . 8
2.5.2. Congestion Controlled Mode . . . . . . . . . . . . . 8 2.5.2. Congestion Controlled Mode . . . . . . . . . . . . . 8
3. Congestion Information . . . . . . . . . . . . . . . . . . . 9 3. Congestion Information . . . . . . . . . . . . . . . . . . . 9
3.1. ECN Support . . . . . . . . . . . . . . . . . . . . . . . 10 3.1. ECN Support . . . . . . . . . . . . . . . . . . . . . . . 10
4. Configuration . . . . . . . . . . . . . . . . . . . . . . . . 10 4. Configuration . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2. Fixed Packet Size . . . . . . . . . . . . . . . . . . . . 10 4.2. Fixed Packet Size . . . . . . . . . . . . . . . . . . . . 11
4.3. Congestion Control . . . . . . . . . . . . . . . . . . . 11 4.3. Congestion Control . . . . . . . . . . . . . . . . . . . 11
5. IKEv2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. IKEv2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. USE_TFS Notification Message . . . . . . . . . . . . . . 11 5.1. USE_TFS Notification Message . . . . . . . . . . . . . . 11
6. Packet and Data Formats . . . . . . . . . . . . . . . . . . . 11 6. Packet and Data Formats . . . . . . . . . . . . . . . . . . . 12
6.1. IP-TFS Payload . . . . . . . . . . . . . . . . . . . . . 11 6.1. IP-TFS Payload . . . . . . . . . . . . . . . . . . . . . 12
6.1.1. Non-Congestion Control IPTFS_PROTOCOL Payload Format 12 6.1.1. Non-Congestion Control IPTFS_PROTOCOL Payload Format 12
6.1.2. Congestion Control IPTFS_PROTOCOL Payload Format . . 13 6.1.2. Congestion Control IPTFS_PROTOCOL Payload Format . . 13
6.1.3. Data Blocks . . . . . . . . . . . . . . . . . . . . . 14 6.1.3. Data Blocks . . . . . . . . . . . . . . . . . . . . . 14
6.1.4. IKEv2 USE_IPTFS Notification Message . . . . . . . . 15 6.1.4. IKEv2 USE_IPTFS Notification Message . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7.1. IPTFS_PROTOCOL Type . . . . . . . . . . . . . . . . . . . 16 7.1. IPTFS_PROTOCOL Type . . . . . . . . . . . . . . . . . . . 17
7.2. IPTFS_PROTOCOL Sub-Type Registry . . . . . . . . . . . . 16 7.2. IPTFS_PROTOCOL Sub-Type Registry . . . . . . . . . . . . 17
7.3. USE_IPTFS Notify Message Status Type . . . . . . . . . . 17 7.3. USE_IPTFS Notify Message Status Type . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . 18 9.1. Normative References . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . 18 9.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Example Of An Encapsulated IP Packet Flow . . . . . 20 Appendix A. Example Of An Encapsulated IP Packet Flow . . . . . 20
Appendix B. A Send and Loss Event Rate Calculation . . . . . . . 20 Appendix B. A Send and Loss Event Rate Calculation . . . . . . . 21
Appendix C. Comparisons of IP-TFS . . . . . . . . . . . . . . . 21 Appendix C. Comparisons of IP-TFS . . . . . . . . . . . . . . . 21
C.1. Comparing Overhead . . . . . . . . . . . . . . . . . . . 21 C.1. Comparing Overhead . . . . . . . . . . . . . . . . . . . 21
C.1.1. IP-TFS Overhead . . . . . . . . . . . . . . . . . . . 21 C.1.1. IP-TFS Overhead . . . . . . . . . . . . . . . . . . . 21
C.1.2. ESP with Padding Overhead . . . . . . . . . . . . . . 21 C.1.2. ESP with Padding Overhead . . . . . . . . . . . . . . 22
C.2. Overhead Comparison . . . . . . . . . . . . . . . . . . . 22
C.2. Overhead Comparison . . . . . . . . . . . . . . . . . . . 23
C.3. Comparing Available Bandwidth . . . . . . . . . . . . . . 23 C.3. Comparing Available Bandwidth . . . . . . . . . . . . . . 23
C.3.1. Ethernet . . . . . . . . . . . . . . . . . . . . . . 23 C.3.1. Ethernet . . . . . . . . . . . . . . . . . . . . . . 24
Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 25 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 26
Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 25 Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 26
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26
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].
[RFC4303] provides for TFC by allowing padding to be added to [RFC4303] provides for TFC by allowing padding to be added to
encrypted IP packets and allowing for transmission of all-pad packets encrypted IP packets and allowing for transmission of all-pad packets
(indicated using protocol 59). This method has the major limitation (indicated using protocol 59). This method has the major limitation
that it can significantly under-utilize the available bandwidth. that it can significantly under-utilize the available bandwidth.
The IP-TFS solution provides for full TFC without the aforementioned The IP-TFS solution provides for full TFC without the aforementioned
bandwidth limitation. To do this, we use a constant-send-rate IPsec bandwidth limitation. This is accomplished by using a constant-send-
[RFC4303] tunnel with fixed-sized encapsulating packets; however, rate IPsec [RFC4303] tunnel with fixed-sized encapsulating packets;
these fixed-sized packets can contain partial, whole or multiple IP however, these fixed-sized packets can contain partial, whole or
packets to maximize the bandwidth of the tunnel. multiple IP packets to maximize the bandwidth of the tunnel.
For a comparison of the overhead of IP-TFS with the RFC4303 For a comparison of the overhead of IP-TFS with the RFC4303
prescribed TFC solution see Appendix C. prescribed TFC solution see Appendix C.
Additionally, IP-TFS provides for dealing with network congestion Additionally, IP-TFS provides for dealing with network congestion
[RFC2914]. This is important for when the IP-TFS user is not in full [RFC2914]. This is important for when the IP-TFS user is not in full
control of the domain through which the IP-TFS tunnel path flows. control of the domain through which the IP-TFS tunnel path flows.
1.1. Terminology & Concepts 1.1. Terminology & Concepts
skipping to change at page 4, line 8 skipping to change at page 4, line 8
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119] [RFC8174] when, and only when, they appear in all capitals, [RFC2119] [RFC8174] when, and only when, they appear in all capitals,
as shown here. as shown here.
This document assumes familiarity with IP security concepts described This document assumes familiarity with IP security concepts described
in [RFC4301]. in [RFC4301].
2. The IP-TFS Tunnel 2. The IP-TFS Tunnel
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 we send fixed-sized (SA) as it's transport. To provide for full TFC, fixed-sized
encapsulating packets 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
of the tunnel. Two values are then required to provide for this of 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 can be
determined through the use of Path MTU discovery [RFC1191] and determined through the use of Path MTU discovery [RFC1191] and
[RFC8201]. [RFC8201].
skipping to change at page 4, line 36 skipping to change at page 4, line 36
(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.
2.1. Tunnel Content 2.1. Tunnel Content
As previously mentioned, one issue with the TFC padding solution in As previously mentioned, one issue with the TFC padding solution in
[RFC4303] is the large amount of wasted bandwidth as only one IP [RFC4303] is the large amount of wasted bandwidth as only one IP
packet can be sent per encapsulating packet. In order to maximize packet can be sent per encapsulating packet. In order to maximize
bandwidth IP-TFS breaks this one-to-one association. bandwidth IP-TFS breaks this one-to-one association.
With IP-TFS we aggregate as well as fragment the inner IP traffic IP-TFS aggregates as well as fragments the inner IP traffic flow into
flow into fixed-sized encapsulating IPsec tunnel packets. We only fixed-sized encapsulating IPsec tunnel packets. Padding is only
pad the tunnel packets if there is no data available to be sent at added to the the tunnel packets if there is no data available to be
the time of tunnel packet transmission, or if fragmentation has been sent at the time of tunnel packet transmission, or if fragmentation
disabled by the receiver. has been disabled by the receiver.
In order to do this we use a new Encapsulating Security Payload (ESP, This is accomplished using a new Encapsulating Security Payload (ESP,
[RFC4303]) type which is identified by the IP protocol number [RFC4303]) type which is identified by the IP protocol number
IPTFS_PROTOCOL (TBD1). IPTFS_PROTOCOL (TBD1).
2.2. IPTFS_PROTOCOL Payload Content 2.2. IPTFS_PROTOCOL Payload Content
The IPTFS_PROTOCOL payload content defined in this document is The IPTFS_PROTOCOL payload content defined in this document is
comprised of a 4 or 16 octet header followed by either a partial, a comprised of a 4 or 16 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 IPTFS_PROTOCOL payload within the ESP packet. See illustrates this IPTFS_PROTOCOL payload within the ESP packet. See
Section 6.1 for the exact formats of the IPTFS_PROTOCOL payload. Section 6.1 for the exact formats of the IPTFS_PROTOCOL payload.
skipping to change at page 5, line 38 skipping to change at page 5, line 38
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 quick recovery with minimal inner packet loss in the block allows for recovering the next full inner packet in the
presence of outer encapsulating packet loss. presence of 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.
+-------- +--------
skipping to change at page 6, line 23 skipping to change at page 6, line 23
an encapsulating packet. Even when the start of a data block occurs an encapsulating packet. Even when the start of a data block occurs
near the end of a encapsulating packet such that there is no room for near the end of a encapsulating packet such that there is no room for
the length field of the encapsulated header to be included in the the length field of the encapsulated header to be included in the
current encapsulating packet, the fact that the length comes at a current encapsulating packet, the fact that the length comes at a
known location and is guaranteed to be present is enough to fetch the known location and is guaranteed to be present is enough to fetch the
length field from the subsequent encapsulating packet payload. Only length field from the subsequent encapsulating packet payload. Only
when there is no data to encapsulated is end padding required, and when there is no data to encapsulated is end padding required, and
then an explicit "Pad Data Block" would be used to identify the then an explicit "Pad Data Block" would be used to identify the
padding. padding.
2.2.3. Empty Payload 2.2.3. Fragmentation, Sequence Numbers and All-Pad Payloads
In order for a receiver to be able to reassemble fragmented inner-
packets, the sender MUST send the inner-packet fragments back-to-back
in the logical IP-TFS packet stream (i.e., using consecutive ESP
sequence numbers). However, the sender is allowed to insert "all-
pad" IP-TFS packets (i.e., packets having payloads with a
"BlockOffset" of zero and a single pad "DataBlock") in between the
IP-TFS packets carrying the inner-packet fragment payloads. This
possible interleaving of all-pad packets allows the sender to always
be able to send an IP-TFS tunnel packet, regardless of the
encapsulation computational requirements.
When a receiver is reassembling an inner-packet, and it receives an
"all-pad" IP-TFS tunnel packet, it increments the expected sequence
number that the next inner-packet fragment is expected to arrive in.
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-IP-TFS enabled SA, IP-TFS allows for the (described later) on a non-IP-TFS enabled SA, IP-TFS allows for the
sending of an IP-TFS payload with no data blocks (i.e., the ESP sending of an IP-TFS payload with no data blocks (i.e., the ESP
payload length is equal to the IP-TFS header length). This special payload length is equal to the IP-TFS header length). This special
payload is called an empty payload. payload is called an empty payload.
2.2.4. IP Header Value Mapping 2.2.5. IP Header Value Mapping
[RFC4301] provides some direction on when and how to map various [RFC4301] provides some direction on when and how to map various
values from an inner IP header to the outer encapsulating header, values from an inner IP header to the outer encapsulating header,
namely the Don't-Fragment (DF) bit ([RFC0791] and [RFC8200]), the namely the Don't-Fragment (DF) bit ([RFC0791] and [RFC8200]), the
Differentiated Services (DS) field [RFC2474] and the Explicit Differentiated Services (DS) field [RFC2474] and the Explicit
Congestion Notification (ECN) field [RFC3168]. Unlike [RFC4301] with Congestion Notification (ECN) field [RFC3168]. Unlike [RFC4301], IP-
IP-TFS we may and often will be encapsulating more than 1 IP packet TFS may and often will be encapsulating more than one IP packet per
per ESP packet. To deal with this we further restrict these ESP packet. To deal with this, these mappings are restricted
mappings. In particular we never map the inner DF bit as it is further. In particular IP-TFS never maps the inner DF bit as it is
unrelated to the IP-TFS tunnel functionality; we never IP fragment unrelated to the IP-TFS tunnel functionality; IP-TFS never IP
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.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 IP-TFS enabled SA. In other words, an SA that has IP-TFS of an IP-TFS enabled SA. In other words, an SA that has IP-TFS
enabled is exclusively for IP-TFS use and MUST NOT have non-IP-TFS enabled is exclusively for IP-TFS use and MUST NOT have non-IP-TFS
payloads such as IP (IP protocol 4), TCP transport (IP protocol 6), payloads such as IP (IP protocol 4), TCP transport (IP protocol 6),
or ESP pad packets (protocol 59) intermixed with non-empty IP-TFS (IP or ESP pad packets (protocol 59) intermixed with non-empty IP-TFS (IP
protocol TBD1) payloads. While it's possible to envision making the protocol TBD1) payloads. While it's possible to envision making the
algorithm work in the presence of sequence number skips in the IP-TFS algorithm work in the presence of sequence number skips in the IP-TFS
payload stream, the added complexity is not deemed worthwhile. Other payload stream, the added complexity is not deemed worthwhile. Other
IPsec uses can configure and use their own SAs. IPsec uses can configure and use their own SAs.
2.4. Initiating IP-TFS Operation On The SA. 2.4. Zero-Conf Receive-Side Operation On The SA.
While a user will normally configure their IPsec tunnel (SA) to Receive-side operation of IP-TFS does not require any per-SA
operate using IP-TFS to start, we also allow IP-TFS operation to be configuration on the receiver; as such, an IP-TFS implementation
enabled post-SA creation and use. This late-enabling may be useful SHOULD support the option of switching to IP-TFS receive-side
for debugging or other purposes. To support this late-enabled operation on receipt of the first IP-TFS payload.
operation the receiver switches to IP-TFS operation on receipt of the
first ESP payload with the IPTFS_PROTOCOL indicated as the payload
type which also contains a data block (i.e., a non-empty IP-TFS
payload). The the receipt of an empty IPTFS_PROTOCOL payload (i.e.,
one without any data blocks) is used to communicate congestion
control information from the receiver back to the sender on a non-IP-
TFS enabled SA, and MUST NOT cause IP-TFS to be enabled on that SA.
2.5. Modes of Operation 2.5. 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 8, line 13 skipping to change at page 8, line 27
case packet loss should be reported to the administrator (e.g., via case packet loss should be reported to the administrator (e.g., via
syslog, YANG notification, SNMP traps, etc) so that any failures due syslog, YANG notification, SNMP traps, etc) so that any failures due
to a lack of bandwidth can be corrected. to a lack of bandwidth can be corrected.
2.5.2. Congestion Controlled Mode 2.5.2. Congestion Controlled Mode
With the congestion controlled mode, IP-TFS adapts to network With the congestion controlled mode, IP-TFS adapts to network
congestion by lowering the packet send rate to accommodate the congestion by lowering the packet send rate to accommodate the
congestion, as well as raising the rate when congestion subsides. congestion, as well as raising the rate when congestion subsides.
Since overhead is per packet, by allowing for maximal fixed-size Since overhead is per packet, by allowing for maximal fixed-size
packets and varying the send rate we minimize transport overhead. packets and varying the send rate transport overhead is minimized.
The output of the congestion control algorithm will adjust the rate The output of the congestion control algorithm will adjust the rate
at which the ingress sends packets. While this document does not at which the ingress sends packets. While this document does not
require a specific congestion control algorithm, best current require a specific congestion control algorithm, best current
practice RECOMMENDS that the algorithm conform to [RFC5348]. practice RECOMMENDS that the algorithm conform to [RFC5348].
Congestion control principles are documented in [RFC2914] as well. Congestion control principles are documented in [RFC2914] as well.
An example of an implementation of the [RFC5348] algorithm which An example of an implementation of the [RFC5348] algorithm which
matches the requirements of IP-TFS (i.e., designed for fixed-size matches the requirements of IP-TFS (i.e., designed for fixed-size
packet and send rate varied based on congestion) is documented in packet and send rate varied based on congestion) is documented in
[RFC4342]. [RFC4342].
The required inputs for the TCP friendly rate control algorithm The required inputs for the TCP friendly rate control algorithm
described in [RFC5348] are the receivers loss event rate and the described in [RFC5348] are the receiver's loss event rate and the
senders estimated round-trip time (RTT). These values are provided sender's estimated round-trip time (RTT). These values are provided
by IP-TFS using the congestion information header fields described in by IP-TFS using the congestion information header fields described in
Section 3. In particular these values are sufficient to implement Section 3. In particular these values are sufficient to implement
the algorithm described in [RFC5348]. the algorithm described in [RFC5348].
At a minimum, the congestion information must be sent, from the At a minimum, the congestion information must be sent, from the
receiver as well as from the sender, at least once per RTT. Prior to receiver and from the sender, at least once per RTT. Prior to
establishing an RTT the information SHOULD be sent constantly from establishing an RTT the information SHOULD be sent constantly from
the sender and the receiver so that an RTT estimate can be the sender and the receiver so that an RTT estimate can be
established. The lack of receiving this information over multiple established. The lack of receiving this information over multiple
consecutive RTT intervals should be considered a congestion event consecutive RTT intervals should be considered a congestion event
that causes the sender to adjust it's sending rate lower. For that causes the sender to adjust it's sending rate lower. For
example, [RFC4342] calls this the "no feedback timeout" and it is example, [RFC4342] calls this the "no feedback timeout" and it is
equal to 4 RTT intervals. When a "no feedback timeout" has occurred equal to 4 RTT intervals. When a "no feedback timeout" has occurred
[RFC4342] halves the sending rate. [RFC4342] halves the sending rate.
An implementation could choose to always include the congestion An implementation could choose to always include the congestion
skipping to change at page 20, line 12 skipping to change at page 20, line 31
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>.
Appendix A. Example Of An Encapsulated IP Packet Flow Appendix A. Example Of An Encapsulated IP Packet Flow
Below we show an example inner IP packet flow within the Below an example inner IP packet flow within the encapsulating tunnel
encapsulating tunnel packet stream. Notice how encapsulated IP packet stream is shown. Notice how encapsulated IP packets can start
packets can start and end anywhere, and more than one or less than 1 and end anywhere, and more than one or less than 1 may occur in a
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]
Figure 3: Inner and Outer Packet Flow Figure 3: Inner and Outer Packet Flow
The encapsulated IP packet flow (lengths include IP header and The encapsulated IP packet flow (lengths include IP header and
payload) is as follows: an 800 octet packet, an 800 octet packet, a payload) is as follows: an 800 octet packet, an 800 octet packet, a
60 octet packet, a 240 octet packet, a 4000 octet packet. 60 octet packet, a 240 octet packet, a 4000 octet packet.
skipping to change at page 20, line 42 skipping to change at page 21, line 12
start of the 60 octet data block. The third encapsulating packet start of the 60 octet data block. The third encapsulating packet
ESP3 contains the middle portion of the 4000 octet data block so the ESP3 contains the middle portion of the 4000 octet data block so the
offset points past its end and into the forth encapsulating packet. offset points past its end and into the forth encapsulating packet.
The fourth packet ESP4s offset is 1400 pointing at the padding which The fourth packet ESP4s offset is 1400 pointing at the padding which
follows the completion of the continued 4000 octet packet. follows the completion of the continued 4000 octet packet.
Appendix B. A Send and Loss Event Rate Calculation Appendix B. A Send and Loss Event Rate Calculation
The current best practice indicates that congestion control should be The current best practice indicates that congestion control should be
done in a TCP friendly way. A TCP friendly congestion control done in a TCP friendly way. A TCP friendly congestion control
algorithm is described in [RFC5348]. For our use case (as with algorithm is described in [RFC5348]. For this IP-TFS use case (as
[RFC4342]) we consider our (fixed) packet size the segment size for with [RFC4342]) the (fixed) packet size is used as the segment size
the algorithm. The formula for the send rate is then as follows: for the algorithm. The formula for the send rate is then as follows:
1 1
X_Pps = ----------------------------------------------- X_Pps = -----------------------------------------------
R * (sqrt(2*p/3) + 12*sqrt(3*p/8)*p*(1+32*p^2)) R * (sqrt(2*p/3) + 12*sqrt(3*p/8)*p*(1+32*p^2))
Where "X_Pps" is the send rate in packets per second, "R" is the Where "X_Pps" is the send rate in packets per second, "R" is the
round trip time estimate and "p" is the loss event rate (the inverse round trip time estimate and "p" is the loss event rate (the inverse
of which is provided by the receiver). of which is provided by the receiver).
The IP-TFS receiver, having the RTT estimate from the sender MAY use The IP-TFS receiver, having the RTT estimate from the sender MAY use
skipping to change at page 23, line 26 skipping to change at page 23, line 49
8960 15.7% 17.2% 0.0% 7.46% 2.74% 0.45% 8960 15.7% 17.2% 0.0% 7.46% 2.74% 0.45%
9000 15.2% 16.7% 100.0% 7.46% 2.74% 0.45% 9000 15.2% 16.7% 100.0% 7.46% 2.74% 0.45%
Figure 6: Overhead as Percentage of Inner Packet Size Figure 6: Overhead as Percentage of Inner Packet Size
C.3. Comparing Available Bandwidth C.3. Comparing Available Bandwidth
Another way to compare the two solutions is to look at the amount of Another way to compare the two solutions is to look at the amount of
available bandwidth each solution provides. The following sections available bandwidth each solution provides. The following sections
consider and compare the percentage of available bandwidth. For the consider and compare the percentage of available bandwidth. For the
sake of providing a well understood baseline we will also include sake of providing a well understood baseline normal (unencrypted)
normal (unencrypted) Ethernet as well as normal ESP values. Ethernet as well as normal ESP values are included.
C.3.1. Ethernet C.3.1. Ethernet
In order to calculate the available bandwidth we first calculate the In order to calculate the available bandwidth the per packet overhead
per packet overhead in bits. The total overhead of Ethernet is 14+4 is calculated first. The total overhead of Ethernet is 14+4 octets
octets of header and CRC plus and additional 20 octets of framing of header and CRC plus and additional 20 octets of framing (preamble,
(preamble, start, and inter-packet gap) for a total of 48 octets. start, and inter-packet gap) for a total of 38 octets. Additionally
Additionally the minimum payload is 46 octets. the minimum payload is 46 octets.
Size E + P E + P E + P IPTFS IPTFS IPTFS Enet ESP Size E + P E + P E + P IPTFS IPTFS IPTFS Enet ESP
MTU 590 1514 9014 590 1514 9014 any any MTU 590 1514 9014 590 1514 9014 any any
OH 74 74 74 78 78 78 38 74 OH 74 74 74 78 78 78 38 74
------------------------------------------------------------ ------------------------------------------------------------
40 614 1538 9038 45 42 40 84 114 40 614 1538 9038 45 42 40 84 114
128 614 1538 9038 146 134 129 166 202 128 614 1538 9038 146 134 129 166 202
256 614 1538 9038 293 269 258 294 330 256 614 1538 9038 293 269 258 294 330
536 614 1538 9038 614 564 540 574 610 536 614 1538 9038 614 564 540 574 610
576 1228 1538 9038 659 606 581 614 650 576 1228 1538 9038 659 606 581 614 650
skipping to change at page 25, line 26 skipping to change at page 26, line 7
Figure 10: Added Latency Figure 10: Added Latency
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 this work. We would like to thank Don Fedyk for help in reviewing and editing
this work.
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. 31 change blocks. 
75 lines changed or deleted 88 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/