draft-ietf-ipsecme-iptfs-03.txt   draft-ietf-ipsecme-iptfs-04.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 November 15, 2020 Intended status: Standards Track December 18, 2020
Expires: May 19, 2021 Expires: June 21, 2021
IP Traffic Flow Security IP Traffic Flow Security Using Aggregation and Fragmentation
draft-ietf-ipsecme-iptfs-03 draft-ietf-ipsecme-iptfs-04
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 May 19, 2021. This Internet-Draft will expire on June 21, 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 13 skipping to change at page 2, line 13
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
described in the Simplified BSD License. described in the Simplified BSD License.
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. Payload Content . . . . . . . . . . . . . . . . . . . . . 5
2.2.1. Data Blocks . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . 6 2.2.4. Empty Payload . . . . . . . . . . . . . . . . . . . . 7
2.2.5. IP Header Value Mapping . . . . . . . . . . . . . . . 7 2.2.5. IP Header Value Mapping . . . . . . . . . . . . . . . 7
2.3. Exclusive SA Use . . . . . . . . . . . . . . . . . . . . 7 2.3. Exclusive SA Use . . . . . . . . . . . . . . . . . . . . 7
2.4. Modes of Operation . . . . . . . . . . . . . . . . . . . 7 2.4. Modes of Operation . . . . . . . . . . . . . . . . . . . 7
2.4.1. Non-Congestion Controlled Mode . . . . . . . . . . . 7 2.4.1. Non-Congestion Controlled Mode . . . . . . . . . . . 8
2.4.2. Congestion Controlled Mode . . . . . . . . . . . . . 8 2.4.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 . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Configuration . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2. Fixed Packet Size . . . . . . . . . . . . . . . . . . . . 11 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_AGGFRAG Notification Message . . . . . . . . . . . . 11
6. Packet and Data Formats . . . . . . . . . . . . . . . . . . . 12 6. Packet and Data Formats . . . . . . . . . . . . . . . . . . . 12
6.1. IP-TFS Payload . . . . . . . . . . . . . . . . . . . . . 12 6.1. AGGFRAG_PAYLOAD Payload . . . . . . . . . . . . . . . . . 12
6.1.1. Non-Congestion Control IPTFS_PROTOCOL Payload Format 12 6.1.1. Non-Congestion Control AGGFRAG_PAYLOAD Payload Format 13
6.1.2. Congestion Control IPTFS_PROTOCOL Payload Format . . 13 6.1.2. Congestion Control AGGFRAG_PAYLOAD Payload Format . . 13
6.1.3. Data Blocks . . . . . . . . . . . . . . . . . . . . . 15 6.1.3. Data Blocks . . . . . . . . . . . . . . . . . . . . . 15
6.1.4. IKEv2 USE_IPTFS Notification Message . . . . . . . . 17 6.1.4. IKEv2 USE_AGGFRAG Notification Message . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
7.1. IPTFS_PROTOCOL Type . . . . . . . . . . . . . . . . . . . 18 7.1. AGGFRAG_PAYLOAD Sub-Type Registry . . . . . . . . . . . . 18
7.2. IPTFS_PROTOCOL Sub-Type Registry . . . . . . . . . . . . 18 7.2. USE_AGGFRAG Notify Message Status Type . . . . . . . . . 18
7.3. USE_IPTFS Notify Message Status Type . . . . . . . . . . 18 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Normative References . . . . . . . . . . . . . . . . . . 19 9.1. Normative References . . . . . . . . . . . . . . . . . . 19
9.2. Informative References . . . . . . . . . . . . . . . . . 19 9.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendix A. Example Of An Encapsulated IP Packet Flow . . . . . 21 Appendix A. Example Of An Encapsulated IP Packet Flow . . . . . 21
Appendix B. A Send and Loss Event Rate Calculation . . . . . . . 22 Appendix B. A Send and Loss Event Rate Calculation . . . . . . . 21
Appendix C. Comparisons of IP-TFS . . . . . . . . . . . . . . . 22 Appendix C. Comparisons of IP-TFS . . . . . . . . . . . . . . . 22
C.1. Comparing Overhead . . . . . . . . . . . . . . . . . . . 22 C.1. Comparing Overhead . . . . . . . . . . . . . . . . . . . 22
C.1.1. IP-TFS Overhead . . . . . . . . . . . . . . . . . . . 22 C.1.1. IP-TFS Overhead . . . . . . . . . . . . . . . . . . . 22
C.1.2. ESP with Padding Overhead . . . . . . . . . . . . . . 23 C.1.2. ESP with Padding Overhead . . . . . . . . . . . . . . 23
C.2. Overhead Comparison . . . . . . . . . . . . . . . . . . . 24 C.2. Overhead Comparison . . . . . . . . . . . . . . . . . . . 24
C.3. Comparing Available Bandwidth . . . . . . . . . . . . . . 25 C.3. Comparing Available Bandwidth . . . . . . . . . . . . . . 24
C.3.1. Ethernet . . . . . . . . . . . . . . . . . . . . . . 25 C.3.1. Ethernet . . . . . . . . . . . . . . . . . . . . . . 25
Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 27 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 27
Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 27 Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 27
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 27 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 27
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],
skipping to change at page 4, line 12 skipping to change at page 4, line 12
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, 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
of 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 can be
determined through the use of Path MTU discovery [RFC1191] and determined through the use of Path MTU discovery [RFC1191] and
[RFC8201]. [RFC8201].
Given the encapsulating packet size and the requested tunnel 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 payload packet send rate is the requested bandwidth divided by the size of
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.
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.
IP-TFS aggregates as well as fragments the inner IP traffic flow into IP-TFS aggregates as well as fragments the inner IP traffic flow into
fixed-sized encapsulating IPsec tunnel packets. Padding is only fixed-sized encapsulating IPsec tunnel packets. Padding is only
added to the the tunnel packets if there is no data available to be added to the the tunnel packets if there is no data available to be
sent at the time of tunnel packet transmission, or if fragmentation sent at the time of tunnel packet transmission, or if fragmentation
has been disabled by the receiver. has been disabled by the receiver.
This is accomplished using a new Encapsulating Security Payload (ESP, This is accomplished using a new Encapsulating Security Payload (ESP,
[RFC4303]) type which is identified by the number IPTFS_PROTOCOL [RFC4303]) type which is identified by the number AGGFRAG_PAYLOAD
(Section 6.1). (Section 6.1).
2.2. IPTFS_PROTOCOL Payload Content Other non-IP-TFS uses of this aggregation and fragmentation
encapsulation have been identified, such as increased performance
through packet aggregation, as well as handling MTU issues using
fragmentation. These uses are not defined here, but are also not
restricted by this document.
The IPTFS_PROTOCOL payload content defined in this document is 2.2. Payload Content
The AGGFRAG_PAYLOAD payload content defined in this document is
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 IPTFS_PROTOCOL payload within the ESP packet. See illustrates this payload within the ESP packet. See Section 6.1 for
Section 6.1 for the exact formats of the IPTFS_PROTOCOL payload. the exact formats of the AGGFRAG_PAYLOAD payload.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. Outer Encapsulating Header ... . . Outer Encapsulating Header ... .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. ESP Header... . . ESP Header... .
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| ... : BlockOffset | | ... : BlockOffset |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
: [Optional Congestion Info] : : [Optional Congestion Info] :
+---------------------------------------------------------------+ +---------------------------------------------------------------+
skipping to change at page 6, line 27 skipping to change at page 6, line 38
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. Fragmentation, Sequence Numbers and All-Pad Payloads 2.2.3. Fragmentation, Sequence Numbers and All-Pad Payloads
In order for a receiver to be able to reassemble fragmented inner- In order for a receiver to be able to reassemble fragmented inner-
packets, the sender MUST send the inner-packet fragments back-to-back packets, the sender MUST send the inner-packet fragments back-to-back
in the logical IP-TFS packet stream (i.e., using consecutive ESP in the logical outer packet stream (i.e., using consecutive ESP
sequence numbers). However, the sender is allowed to insert "all- sequence numbers). However, the sender is allowed to insert "all-
pad" IP-TFS packets (i.e., packets having payloads with a pad" payloads (i.e., payloads with a "BlockOffset" of zero and a
"BlockOffset" of zero and a single pad "DataBlock") in between the single pad "DataBlock") in between the packets carrying the inner-
IP-TFS packets carrying the inner-packet fragment payloads. This packet fragment payloads. This possible interleaving of all-pad
possible interleaving of all-pad packets allows the sender to always payloads allows the sender to always be able to send a tunnel packet,
be able to send an IP-TFS tunnel packet, regardless of the regardless of the encapsulation computational requirements.
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" IP-TFS tunnel packet, it increments the expected sequence "all-pad" payload, it increments the expected sequence number that
number that the next inner-packet fragment is expected to arrive in. the next inner-packet fragment is expected to arrive in.
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-IP-TFS enabled SA, IP-TFS allows for the (described later) on a non-AGGFRAG_PAYLOAD enabled SA, IP-TFS allows
sending of an IP-TFS payload with no data blocks (i.e., the ESP for the sending of an AGGFRAG_PAYLOAD payload with no data blocks
payload length is equal to the IP-TFS header length). This special (i.e., the ESP payload length is equal to the AGGFRAG_PAYLOAD header
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
[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], IP- Congestion Notification (ECN) field [RFC3168]. Unlike [RFC4301], IP-
TFS may and often will be encapsulating more than one IP packet per TFS may and often will be encapsulating more than one IP packet per
ESP packet. To deal with this, these mappings are restricted ESP packet. To deal with this, these mappings are restricted
skipping to change at page 7, line 28 skipping to change at page 7, line 36
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 AGGFRAG_PAYLOAD enabled SA. In other words, an SA that has
enabled is exclusively for IP-TFS use and MUST NOT have non-IP-TFS AGGFRAG_PAYLOAD enabled MUST NOT have non-AGGFRAG_PAYLOAD payloads
payloads such as IP (IP protocol 4), TCP transport (IP protocol 6), such as IP (IP protocol 4), TCP transport (IP protocol 6), or ESP pad
or ESP pad packets (protocol 59) intermixed with non-empty IP-TFS (IP packets (protocol 59) intermixed with non-empty AGGFRAG_PAYLOAD
protocol TBD1) payloads. While it's possible to envision making the payloads. While it's possible to envision making the algorithm work
algorithm work in the presence of sequence number skips in the IP-TFS 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
IPsec uses can configure and use their own SAs. 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
skipping to change at page 9, line 38 skipping to change at page 9, line 45
circuit breakers are outside the scope of this document. circuit breakers are outside the scope of this document.
3. Congestion Information 3. Congestion Information
In order to support the congestion control mode, the sender needs to In order to support the congestion control mode, the sender needs to
know the loss event rate and also be able to approximate the RTT know the loss event rate and also be able to approximate the RTT
([RFC5348]). In order to obtain these values the receiver sends ([RFC5348]). In order to obtain these values the receiver sends
congestion control information on it's SA back to the sender. Thus, congestion control information on it's SA back to the sender. Thus,
in order to support congestion control the receiver must have a in order to support congestion control the receiver must have a
paired SA back to the sender (this is always the case when the tunnel paired SA back to the sender (this is always the case when the tunnel
was created using IKEv2). If the SA back to the sender is a non-IP- was created using IKEv2). If the SA back to the sender is a non-
TFS enabled SA then an IPTFS_PROTOCOL empty payload (i.e., header AGGFRAG_PAYLOAD enabled SA then an AGGFRAG_PAYLOAD empty payload
only) is used to convey the information. (i.e., header only) is used to convey the information.
In order to calculate a loss event rate compatible with [RFC5348], In order to calculate a loss event rate compatible with [RFC5348],
the receiver needs to have a round-trip time estimate. Thus the the receiver needs to have a round-trip time estimate. Thus the
sender communicates this estimate in the "RTT" header field. On sender communicates this estimate in the "RTT" header field. On
startup this value will be zero as no RTT estimate is yet known. startup this value will be zero as no RTT estimate is yet known.
In order for the sender to estimate it's "RTT" value, the sender In order for the sender to estimate it's "RTT" value, the sender
places a timestamp value in the "TVal" header field. On first places a timestamp value in the "TVal" header field. On first
receipt of this "TVal", the receiver records the new "TVal" value receipt of this "TVal", the receiver records the new "TVal" value
along with the time it arrived locally, subsequent receipt of the along with the time it arrived locally, subsequent receipt of the
skipping to change at page 10, line 19 skipping to change at page 10, line 27
current transmission delay on the tunnel (i.e., the average time current transmission delay on the tunnel (i.e., the average time
between sending packets on it's half of the IP-TFS tunnel). When the between sending packets on it's half of the IP-TFS tunnel). When the
sender receives back it's "TVal" in the "TEcho" header field it sender receives back it's "TVal" in the "TEcho" header field it
calculates 2 RTT estimates. The first is the actual delay found by calculates 2 RTT estimates. The first is the actual delay found by
subtracting the "TEcho" value from it's current clock and then subtracting the "TEcho" value from it's current clock and then
subtracting "Echo Delay" as well. The second RTT estimate is found subtracting "Echo Delay" as well. The second RTT estimate is found
by adding the received "Transmit Delay" header value to the senders by adding the received "Transmit Delay" header value to the senders
own transmission delay (i.e., the average time between sending own transmission delay (i.e., the average time between sending
packets on it's half of the IP-TFS tunnel). The larger of these 2 packets on it's half of the IP-TFS tunnel). The larger of these 2
RTT estimates SHOULD be used as the "RTT" value. The two estimates RTT estimates SHOULD be used as the "RTT" value. The two estimates
are required to handle different combinations of faster or slow are required to handle different combinations of faster or slower
tunnel packet paths with fast or slow fixed tunnel rates. Choosing tunnel packet paths with faster or slower fixed tunnel rates.
the larger of the two values guarantees that the "RTT" is never Choosing the larger of the two values guarantees that the "RTT" is
considered faster than the aggregate transmission delay based on the never considered faster than the aggregate transmission delay based
IP-TFS tunnel rate (the second estimate), as well as never being on the IP-TFS tunnel rate (the second estimate), as well as never
considered faster than the actual RTT along the tunnel packet path being considered faster than the actual RTT along the tunnel packet
(the first estimate). path (the first estimate).
The receiver also calculates, and communicates in the "LossEventRate" The receiver also calculates, and communicates in the "LossEventRate"
header field, the loss event rate for use by the sender. This is header field, the loss event rate for use by the sender. This is
slightly different from [RFC4342] which periodically sends all the slightly different from [RFC4342] which periodically sends all the
loss interval data back to the sender so that it can do the loss interval data back to the sender so that it can do the
calculation. See Appendix B for a suggested way to calculate the calculation. See Appendix B for a suggested way to calculate the
loss event rate value. Initially this value will be zero (indicating loss event rate value. Initially this value will be zero (indicating
no loss) until enough data has been collected by the receiver to no loss) until enough data has been collected by the receiver to
update it. update it.
3.1. ECN Support 3.1. ECN Support
In additional to normal packet loss information IP-TFS supports use In additional to normal packet loss information IP-TFS supports use
of the ECN bits in the encapsulating IP header [RFC3168] for of the ECN bits in the encapsulating IP header [RFC3168] for
identifying congestion. If ECN use is enabled and a packet arrives identifying congestion. If ECN use is enabled and a packet arrives
at the egress endpoint with the Congestion Experienced (CE) value at the egress endpoint with the Congestion Experienced (CE) value
set, then the receiver considers that packet as being dropped, set, then the receiver considers that packet as being dropped,
although it does not drop it. The receiver MUST set the E bit in any although it does not drop it. The receiver MUST set the E bit in any
IPTFS_PROTOCOL payload header containing a "LossEventRate" value AGGFRAG_PAYLOAD payload header containing a "LossEventRate" value
derived from a CE value being considered. derived from a CE value being considered.
As noted in [RFC3168] the ECN bits are not protected by IPsec and As noted in [RFC3168] the ECN bits are not protected by IPsec and
thus may constitute a covert channel. For this reason ECN use SHOULD thus may constitute a covert channel. For this reason ECN use SHOULD
NOT be enabled by default. NOT be enabled by default.
4. Configuration 4. Configuration
IP-TFS is meant to be deployable with a minimal amount of IP-TFS is meant to be deployable with a minimal amount of
configuration. All IP-TFS specific configuration should be able to configuration. All IP-TFS specific configuration should be able to
skipping to change at page 11, line 36 skipping to change at page 11, line 42
Path MTU discovery (see [RFC1191] and [RFC8201]). No standardized Path MTU discovery (see [RFC1191] and [RFC8201]). No standardized
configuration method is required. 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_TFS Notification Message 5.1. USE_AGGFRAG Notification Message
When using IKEv2, a new "USE_IPTFS" Notification Message is used to As mentioned previously IP-TFS tunnels utilize ESP payloads of type
enable operation of IP-TFS on a child SA pair. The method used is AGGFRAG_PAYLOAD.
similar to how USE_TRANSPORT_MODE is negotiated, as described in
[RFC7296].
To request IP-TFS operation on the Child SA pair, the initiator When using IKEv2, a new "USE_AGGFRAG" Notification Message is used to
includes the USE_IPTFS notification in an SA payload requesting a new enable use of the AGGFRAG_PAYLOAD payload on a child SA pair. The
Child SA (either during the initial IKE_AUTH or during non-rekeying method used is similar to how USE_TRANSPORT_MODE is negotiated, as
CREATE_CHILD_SA exchanges). If the request is accepted then response described in [RFC7296].
MUST also include a notification of type USE_IPTFS. If the responder
declines the request the child SA will be established without IP-TFS
enabled. If this is unacceptable to the initiator, the initiator
MUST delete the child SA.
The USE_IPTFS notification MUST NOT be sent, and MUST be ignored, To request using the AGGFRAG_PAYLOAD payload on the Child SA pair,
the initiator includes the USE_AGGFRAG notification in an SA payload
requesting a new Child SA (either during the initial IKE_AUTH or
during non-rekeying CREATE_CHILD_SA exchanges). If the request is
accepted then response MUST also include a notification of type
USE_AGGFRAG. If the responder declines the request the child SA will
be established without AGGFRAG_PAYLOAD payload use enabled. If this
is unacceptable to the initiator, the initiator MUST delete the child
SA.
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 IP-TFS operation during rekeying. change use of the AGGFRAG_PAYLOAD payload type during rekeying.
The USE_IPTFS 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 IP-TFS mode (either by receiver then the receiver should not enable use of AGGFRAG_PAYLOAD
not responding with the USE_IPTFS notification, or in the case of the payload type (either by not responding with the USE_AGGFRAG
initiator, by deleting the child SA if the now established non-IP-TFS notification, or in the case of the initiator, by deleting the child
operation is unacceptable). SA if the now established non-AGGFRAG_PAYLOAD using SA is
unacceptable).
The notification type and payload flag values are defined in The notification type and payload flag values are defined in
Section 6.1.4. Section 6.1.4.
6. Packet and Data Formats 6. Packet and Data Formats
6.1. IP-TFS Payload 6.1. AGGFRAG_PAYLOAD Payload
ESP Payload Type: 0x5 ESP Payload Type: 0x5
An IP-TFS payload is identified by the ESP payload type An IP-TFS payload is identified by the ESP payload type
IPTFS_PROTOCOL which has the value 0x5. The first octet of this AGGFRAG_PAYLOAD which has the value 0x5. The first octet of this
payload indicates the format of the remaining payload data. payload indicates the format of the remaining payload data.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-
| Sub-type | ... | Sub-type | ...
+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-
Sub-type: Sub-type:
An 8 bit value indicating the payload format. An 8 bit value indicating the payload format.
This specification defines 2 payload sub-types. These payload This specification defines 2 payload sub-types. These payload
formats are defined in the following sections. formats are defined in the following sections.
6.1.1. Non-Congestion Control IPTFS_PROTOCOL Payload Format 6.1.1. Non-Congestion Control AGGFRAG_PAYLOAD Payload Format
The non-congestion control IPTFS_PROTOCOL payload is comprised of a 4 The non-congestion control AGGFRAG_PAYLOAD payload is comprised of a
octet header followed by a variable amount of "DataBlocks" data as 4 octet header followed by a variable amount of "DataBlocks" data as
shown below. shown below.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Type (0) | Reserved | BlockOffset | | Sub-Type (0) | Reserved | BlockOffset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DataBlocks ... | DataBlocks ...
+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-
skipping to change at page 13, line 35 skipping to change at page 13, line 41
block being re-assembled. If the "BlockOffset" extends into block being re-assembled. If the "BlockOffset" extends into
subsequent packets it continues to only count subsequent subsequent packets it continues to only count subsequent
"DataBlocks" data (i.e., it does not count subsequent packets "DataBlocks" data (i.e., it does not count subsequent packets
non-"DataBlocks" octets). non-"DataBlocks" octets).
DataBlocks: DataBlocks:
Variable number of octets that begins with the start of a data Variable number of octets that begins with the start of a data
block, or the continuation of a previous data block, followed by block, or the continuation of a previous data block, followed by
zero or more additional data blocks. zero or more additional data blocks.
6.1.2. Congestion Control IPTFS_PROTOCOL Payload Format 6.1.2. Congestion Control AGGFRAG_PAYLOAD Payload Format
The congestion control IPTFS_PROTOCOL payload is comprised of a 24 The congestion control AGGFRAG_PAYLOAD payload is comprised of a 24
octet header followed by a variable amount of "DataBlocks" data as octet header followed by a variable amount of "DataBlocks" data as
shown below. shown below.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-type (1) | Reserved |E| BlockOffset | | Sub-type (1) | Reserved |E| BlockOffset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LossEventRate | | LossEventRate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 14, line 48 skipping to change at page 14, line 48
LossEventRate: LossEventRate:
A 32 bit value specifying the inverse of the current loss event A 32 bit value specifying the inverse of the current loss event
rate as calculated by the receiver. A value of zero indicates no rate as calculated by the receiver. A value of zero indicates no
loss. Otherwise the loss event rate is "1/LossEventRate". loss. Otherwise the loss event rate is "1/LossEventRate".
RTT: RTT:
A 22 bit value specifying the sender's current round-trip time A 22 bit value specifying the sender's current round-trip time
estimate in microseconds. The value MAY be zero prior to the estimate in microseconds. The value MAY be zero prior to the
sender having calculated a round-trip time estimate. The value sender having calculated a round-trip time estimate. The value
SHOULD be set to zero on non-IP-TFS enabled SAs. If the value is SHOULD be set to zero on non-AGGFRAG_PAYLOAD enabled SAs. If the
equal to or larger than "0x3FFFFF" it MUST be set to "0x3FFFFF". value is equal to or larger than "0x3FFFFF" it MUST be set to
"0x3FFFFF".
Echo Delay: Echo Delay:
A 21 bit value specifying the delay in microseconds incurred A 21 bit value specifying the delay in microseconds incurred
between the receiver first receiving the "TVal" value which it is between the receiver first receiving the "TVal" value which it is
sending back in "TEcho". If the value is equal to or larger than sending back in "TEcho". If the value is equal to or larger than
"0x1FFFFF" it MUST be set to "0x1FFFFF". "0x1FFFFF" it MUST be set to "0x1FFFFF".
Transmit Delay: Transmit Delay:
A 21 bit value specifying the transmission delay in microseconds. A 21 bit value specifying the transmission delay in microseconds.
This is the fixed (or average) delay on the receiver between it This is the fixed (or average) delay on the receiver between it
sending packets on the IPTFS tunnel. If the value is equal to or sending packets on the IPTFS tunnel. If the value is equal to or
larger than "0x1FFFFF" it MUST be set to "0x1FFFFF". larger than "0x1FFFFF" it MUST be set to "0x1FFFFF".
TVal: TVal:
An opaque 32 bit value that will be echoed back by the receiver in An opaque 32 bit value that will be echoed back by the receiver in
later packets in the "TEcho" field, along with a "Delay" value of later packets in the "TEcho" field, along with an "Echo Delay"
how long that echo took. value of how long that echo took.
TEcho: TEcho:
The opaque 32 bit value from a received packet's "TVal" field. The opaque 32 bit value from a received packet's "TVal" field.
The received "TVal" is placed in "TEcho" along with a "Delay" The received "TVal" is placed in "TEcho" along with an "Echo
value indicating how long it has been since receiving the "TVal" Delay" value indicating how long it has been since receiving the
value. "TVal" value.
DataBlocks: DataBlocks:
Variable number of octets that begins with the start of a data Variable number of octets that begins with the start of a data
block, or the continuation of a previous data block, followed by block, or the continuation of a previous data block, followed by
zero or more additional data blocks. For the special case of zero or more additional data blocks. For the special case of
sending congestion control information on an non-IP-TFS enabled SA sending congestion control information on an non-IP-TFS enabled SA
this value MUST be empty (i.e., be zero octets long). this value MUST be empty (i.e., be zero octets long).
6.1.3. Data Blocks 6.1.3. Data Blocks
skipping to change at page 17, line 16 skipping to change at page 17, line 16
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0 | Padding ... | 0x0 | Padding ...
+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-
Type: Type:
A 4 bit value of 0x0 indicating a padding data block. A 4 bit value of 0x0 indicating a padding data block.
Padding: Padding:
extends to end of the encapsulating packet. extends to end of the encapsulating packet.
6.1.4. IKEv2 USE_IPTFS Notification Message 6.1.4. IKEv2 USE_AGGFRAG Notification Message
As discussed in Section 5.1 a notification message USE_IPTFS is used As discussed in Section 5.1 a notification message USE_AGGFRAG is
to negotiate IP-TFS operation in IKEv2. used to negotiate use of the ESP AGGFRAG_PAYLOAD payload type.
The USE_IPTFS Notification Message State Type is (TBD2). The USE_AGGFRAG Notification Message State Type is (TBD2).
The notification payload contains 1 octet of requirement flags. The notification payload contains 1 octet of requirement flags.
There are currently 2 requirement flags defined. This may be revised There are currently 2 requirement flags defined. This may be revised
by later specifications. by later specifications.
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|0|0|0|0|0|0|C|D| |0|0|0|0|0|0|C|D|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
0: 0:
skipping to change at page 17, line 46 skipping to change at page 17, line 46
Congestion Control bit. If set, then the sender is requiring that Congestion Control bit. If set, then the sender is requiring that
congestion control information MUST be returned to it periodically congestion control information MUST be returned to it periodically
as defined in Section 3. as defined in Section 3.
D: D:
Don't Fragment bit, if set indicates the sender of the notify Don't Fragment bit, if set indicates the sender of the notify
message does not support receiving packet fragments (i.e., inner message does not support receiving packet fragments (i.e., inner
packets MUST be sent using a single "Data Block"). This value packets MUST be sent using a single "Data Block"). This value
only applies to what the sender is capable of receiving; the only applies to what the sender is capable of receiving; the
sender MAY still send packet fragments unless similarly restricted sender MAY still send packet fragments unless similarly restricted
by the receiver in it's USE_IPTFS notification. by the receiver in it's USE_AGGFRAG notification.
7. IANA Considerations 7. IANA Considerations
7.1. IPTFS_PROTOCOL Type 7.1. AGGFRAG_PAYLOAD Sub-Type Registry
This document requests a protocol number IPTFS_PROTOCOL be allocated
by IANA from "Assigned Internet Protocol Numbers" registry for
identifying the IP-TFS payload.
Type:
TBD1
Description:
An IP-TFS payload.
Reference:
This document
7.2. IPTFS_PROTOCOL Sub-Type Registry
This document requests IANA create a registry called "IPTFS_PROTOCOL This document requests IANA create a registry called "AGGFRAG_PAYLOAD
Sub-Type Registry" under "IPTFS_PROTOCOL Parameters" IANA registries. Sub-Type Registry" under a new category named "ESP AGGFRAG_PAYLOAD
The registration policy for this registry is "Standards Action" Parameters". The registration policy for this registry is "Standards
([RFC8126] and [RFC7120]). Action" ([RFC8126] and [RFC7120]).
Name: Name:
IPTFS_PROTOCOL Sub-Type Registry AGGFRAG_PAYLOAD Sub-Type Registry
Description: Description:
IPTFS_PROTOCOL Payload Formats. AGGFRAG_PAYLOAD Payload Formats.
Reference: Reference:
This document This document
This initial content for this registry is as follows: This initial content for this registry is as follows:
Sub-Type Name Reference Sub-Type Name Reference
-------------------------------------------------------- --------------------------------------------------------
0 Non-Congestion Control Format This document 0 Non-Congestion Control Format This document
1 Congestion Control Format This document 1 Congestion Control Format This document
3-255 Reserved 3-255 Reserved
7.3. USE_IPTFS Notify Message Status Type 7.2. USE_AGGFRAG Notify Message Status Type
This document requests a status type USE_IPTFS be allocated from the This document requests a status type USE_AGGFRAG be allocated from
"IKEv2 Notify Message Types - Status Types" registry. the "IKEv2 Notify Message Types - Status Types" registry.
Value: Value:
TBD2 TBD2
Name: Name:
USE_IPTFS USE_AGGFRAG
Reference: Reference:
This document This document
8. Security Considerations 8. Security Considerations
This document describes a mechanism to add Traffic Flow This document describes a mechanism to add Traffic Flow
Confidentiality to IP traffic. Use of this mechanism is expected to Confidentiality to IP traffic. Use of this mechanism is expected to
increase the security of the traffic being transported. Other than increase the security of the traffic being transported. Other than
the additional security afforded by using this mechanism, IP-TFS the additional security afforded by using this mechanism, IP-TFS
skipping to change at page 22, line 33 skipping to change at page 22, line 21
which is provided by the receiver). which is provided by the receiver).
In addition the algorithm in [RFC5348] also uses an "X_recv" value In addition the algorithm in [RFC5348] also uses an "X_recv" value
(the receiver's receive rate). For IP-TFS one MAY set this value (the receiver's receive rate). For IP-TFS one MAY set this value
according to the sender's current tunnel send-rate ("X"). according to the sender's current tunnel send-rate ("X").
The IP-TFS receiver, having the RTT estimate from the sender can use The IP-TFS receiver, having the RTT estimate from the sender can use
the same method as described in [RFC5348] and [RFC4342] to collect the same method as described in [RFC5348] and [RFC4342] to collect
the loss intervals and calculate the loss event rate value using the the loss intervals and calculate the loss event rate value using the
weighted average as indicated. The receiver communicates the inverse weighted average as indicated. The receiver communicates the inverse
of this value back to the sender in the IPTFS_PROTOCOL payload header of this value back to the sender in the AGGFRAG_PAYLOAD payload
field "LossEventRate". header field "LossEventRate".
The IP-TFS sender now has both the "R" and "p" values and can The IP-TFS sender now has both the "R" and "p" values and can
calculate the correct sending rate. If following [RFC5348] the calculate the correct sending rate. If following [RFC5348] the
sender SHOULD also use the slow start mechanism described therein sender SHOULD also use the slow start mechanism described therein
when the IP-TFS SA is first established. when the IP-TFS SA is first established.
Appendix C. Comparisons of IP-TFS Appendix C. Comparisons of IP-TFS
C.1. Comparing Overhead C.1. Comparing Overhead
skipping to change at page 27, line 27 skipping to change at page 27, line 8
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 and editing We would like to thank Don Fedyk for help in reviewing and editing
this work. this work. We would also like to thank Valery Smyslov for reviews
and suggestions for 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. 56 change blocks. 
127 lines changed or deleted 123 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/