--- 1/draft-ietf-ipsecme-iptfs-03.txt 2020-12-18 08:13:54.323320140 -0800 +++ 2/draft-ietf-ipsecme-iptfs-04.txt 2020-12-18 08:13:54.379321568 -0800 @@ -1,18 +1,18 @@ Network Working Group C. Hopps Internet-Draft LabN Consulting, L.L.C. -Intended status: Standards Track November 15, 2020 -Expires: May 19, 2021 +Intended status: Standards Track December 18, 2020 +Expires: June 21, 2021 - IP Traffic Flow Security - draft-ietf-ipsecme-iptfs-03 + IP Traffic Flow Security Using Aggregation and Fragmentation + draft-ietf-ipsecme-iptfs-04 Abstract This document describes a mechanism to enhance IPsec traffic flow security by adding traffic flow confidentiality to encrypted IP encapsulated traffic. Traffic flow confidentiality is provided by obscuring the size and frequency of IP traffic using a fixed-sized, constant-send-rate IPsec tunnel. The solution allows for congestion control as well as non-constant send-rate usage. @@ -24,21 +24,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -47,60 +47,59 @@ include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology & Concepts . . . . . . . . . . . . . . . . . 3 2. The IP-TFS Tunnel . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Tunnel Content . . . . . . . . . . . . . . . . . . . . . 4 - 2.2. IPTFS_PROTOCOL Payload Content . . . . . . . . . . . . . 4 - 2.2.1. Data Blocks . . . . . . . . . . . . . . . . . . . . . 5 + 2.2. Payload Content . . . . . . . . . . . . . . . . . . . . . 5 + 2.2.1. Data Blocks . . . . . . . . . . . . . . . . . . . . . 6 2.2.2. No Implicit End Padding Required . . . . . . . . . . 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.3. Exclusive SA Use . . . . . . . . . . . . . . . . . . . . 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 3. Congestion Information . . . . . . . . . . . . . . . . . . . 9 3.1. ECN Support . . . . . . . . . . . . . . . . . . . . . . . 10 4. Configuration . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2. Fixed Packet Size . . . . . . . . . . . . . . . . . . . . 11 4.3. Congestion Control . . . . . . . . . . . . . . . . . . . 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.1. IP-TFS Payload . . . . . . . . . . . . . . . . . . . . . 12 - 6.1.1. Non-Congestion Control IPTFS_PROTOCOL Payload Format 12 - 6.1.2. Congestion Control IPTFS_PROTOCOL Payload Format . . 13 + 6.1. AGGFRAG_PAYLOAD Payload . . . . . . . . . . . . . . . . . 12 + 6.1.1. Non-Congestion Control AGGFRAG_PAYLOAD Payload Format 13 + 6.1.2. Congestion Control AGGFRAG_PAYLOAD Payload Format . . 13 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.1. IPTFS_PROTOCOL Type . . . . . . . . . . . . . . . . . . . 18 - 7.2. IPTFS_PROTOCOL Sub-Type Registry . . . . . . . . . . . . 18 - 7.3. USE_IPTFS Notify Message Status Type . . . . . . . . . . 18 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 + 7.1. AGGFRAG_PAYLOAD Sub-Type Registry . . . . . . . . . . . . 18 + 7.2. USE_AGGFRAG Notify Message Status Type . . . . . . . . . 18 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 9.2. Informative References . . . . . . . . . . . . . . . . . 19 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 C.1. Comparing Overhead . . . . . . . . . . . . . . . . . . . 22 C.1.1. IP-TFS Overhead . . . . . . . . . . . . . . . . . . . 22 C.1.2. ESP with Padding Overhead . . . . . . . . . . . . . . 23 C.2. Overhead Comparison . . . . . . . . . . . . . . . . . . . 24 - C.3. Comparing Available Bandwidth . . . . . . . . . . . . . . 25 + C.3. Comparing Available Bandwidth . . . . . . . . . . . . . . 24 C.3.1. Ethernet . . . . . . . . . . . . . . . . . . . . . . 25 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 27 Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 27 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 27 1. Introduction Traffic Analysis ([RFC4301], [AppCrypt]) is the act of extracting information about data being sent through a network. While one may directly obscure the data through the use of encryption [RFC4303], @@ -140,61 +139,67 @@ This document assumes familiarity with IP security concepts described in [RFC4301]. 2. The IP-TFS 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 encapsulating packets are sent at a constant rate on the tunnel. 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 which to send them. The fixed packet size may either be specified manually or can be determined through the use of Path MTU discovery [RFC1191] and [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 - packet send rate is the requested bandwidth divided by the payload - size of the encapsulating packet. + packet send rate is the requested bandwidth divided by the size of + the encapsulating packet. 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 encapsulating packets, unless constrained by other policy. 2.1. Tunnel Content As previously mentioned, one issue with the TFC padding solution in [RFC4303] is the large amount of wasted bandwidth as only one IP packet can be sent per encapsulating packet. In order to maximize bandwidth IP-TFS breaks this one-to-one association. IP-TFS aggregates as well as fragments the inner IP traffic flow into fixed-sized encapsulating IPsec tunnel packets. Padding is only 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 has been disabled by the receiver. 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). -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 full or multiple partial or full data blocks. The following diagram - illustrates this IPTFS_PROTOCOL payload within the ESP packet. See - Section 6.1 for the exact formats of the IPTFS_PROTOCOL payload. + illustrates this payload within the ESP packet. See Section 6.1 for + the exact formats of the AGGFRAG_PAYLOAD payload. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Outer Encapsulating Header ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ESP Header... . +---------------------------------------------------------------+ | ... : BlockOffset | +---------------------------------------------------------------+ : [Optional Congestion Info] : +---------------------------------------------------------------+ @@ -253,40 +258,39 @@ known location and is guaranteed to be present is enough to fetch the length field from the subsequent encapsulating packet payload. Only when there is no data to encapsulated is end padding required, and then an explicit "Pad Data Block" would be used to identify the padding. 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 + in the logical outer 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. + pad" payloads (i.e., payloads with a "BlockOffset" of zero and a + single pad "DataBlock") in between the packets carrying the inner- + packet fragment payloads. This possible interleaving of all-pad + payloads allows the sender to always be able to send a 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. + "all-pad" payload, 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 - (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 - payload length is equal to the IP-TFS header length). This special - payload is called an empty payload. + (described later) on a non-AGGFRAG_PAYLOAD enabled SA, IP-TFS allows + 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 + length). This special payload is called an empty payload. 2.2.5. IP Header Value Mapping [RFC4301] provides some direction on when and how to map various values from an inner IP header to the outer encapsulating header, namely the Don't-Fragment (DF) bit ([RFC0791] and [RFC8200]), the Differentiated Services (DS) field [RFC2474] and the Explicit Congestion Notification (ECN) field [RFC3168]. Unlike [RFC4301], IP- TFS may and often will be encapsulating more than one IP packet per ESP packet. To deal with this, these mappings are restricted @@ -297,26 +301,26 @@ value need not be mapped as any congestion related to the constant- send-rate IP-TFS tunnel is unrelated (by design!) to the inner traffic flow. Finally, by default the DS field SHOULD NOT be copied although an implementation MAY choose to allow for configuration to override this behavior. An implementation SHOULD also allow the DS value to be set by configuration. 2.3. Exclusive SA 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 - 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), - or ESP pad packets (protocol 59) intermixed with non-empty IP-TFS (IP - protocol TBD1) payloads. While it's possible to envision making the - algorithm work in the presence of sequence number skips in the IP-TFS + of an AGGFRAG_PAYLOAD enabled SA. In other words, an SA that has + AGGFRAG_PAYLOAD enabled MUST NOT have non-AGGFRAG_PAYLOAD payloads + such as IP (IP protocol 4), TCP transport (IP protocol 6), or ESP pad + packets (protocol 59) intermixed with non-empty AGGFRAG_PAYLOAD + payloads. While it's possible to envision making the algorithm work + in the presence of sequence number skips in the AGGFRAG_PAYLOAD payload stream, the added complexity is not deemed worthwhile. Other IPsec uses can configure and use their own SAs. 2.4. Modes of Operation Just as with normal IPsec/ESP tunnels, IP-TFS tunnels are unidirectional. Bidirectional IP-TFS functionality is achieved by setting up 2 IP-TFS tunnels, one in either direction. An IP-TFS tunnel can operate in 2 modes, a non-congestion controlled @@ -404,23 +408,23 @@ circuit breakers are outside the scope of this document. 3. Congestion Information 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 ([RFC5348]). In order to obtain these values the receiver sends congestion control information on it's SA back to the sender. Thus, 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 - was created using IKEv2). If the SA back to the sender is a non-IP- - TFS enabled SA then an IPTFS_PROTOCOL empty payload (i.e., header - only) is used to convey the information. + was created using IKEv2). If the SA back to the sender is a non- + AGGFRAG_PAYLOAD enabled SA then an AGGFRAG_PAYLOAD empty payload + (i.e., header only) is used to convey the information. In order to calculate a loss event rate compatible with [RFC5348], the receiver needs to have a round-trip time estimate. Thus the sender communicates this estimate in the "RTT" header field. On 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 places a timestamp value in the "TVal" header field. On first receipt of this "TVal", the receiver records the new "TVal" value along with the time it arrived locally, subsequent receipt of the @@ -433,46 +437,46 @@ 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 sender receives back it's "TVal" in the "TEcho" header field it calculates 2 RTT estimates. The first is the actual delay found by subtracting the "TEcho" value from it's current clock and then subtracting "Echo Delay" as well. The second RTT estimate is found by adding the received "Transmit Delay" header value to the senders 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 RTT estimates SHOULD be used as the "RTT" value. The two estimates - are required to handle different combinations of faster or slow - tunnel packet paths with fast or slow fixed tunnel rates. Choosing - the larger of the two values guarantees that the "RTT" is never - considered faster than the aggregate transmission delay based on the - IP-TFS tunnel rate (the second estimate), as well as never being - considered faster than the actual RTT along the tunnel packet path - (the first estimate). + are required to handle different combinations of faster or slower + tunnel packet paths with faster or slower fixed tunnel rates. + Choosing the larger of the two values guarantees that the "RTT" is + never considered faster than the aggregate transmission delay based + on the IP-TFS tunnel rate (the second estimate), as well as never + being considered faster than the actual RTT along the tunnel packet + path (the first estimate). The receiver also calculates, and communicates in the "LossEventRate" header field, the loss event rate for use by the sender. This is slightly different from [RFC4342] which periodically sends all 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 loss event rate value. Initially this value will be zero (indicating no loss) until enough data has been collected by the receiver to update it. 3.1. ECN Support In additional to normal packet loss information IP-TFS supports use of the ECN bits in the encapsulating IP header [RFC3168] for identifying congestion. If ECN use is enabled and a packet arrives at the egress endpoint with the Congestion Experienced (CE) value 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 - IPTFS_PROTOCOL payload header containing a "LossEventRate" value + AGGFRAG_PAYLOAD payload header containing a "LossEventRate" value derived from a CE value being considered. 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 NOT be enabled by default. 4. Configuration IP-TFS is meant to be deployable with a minimal amount of configuration. All IP-TFS specific configuration should be able to @@ -496,76 +500,81 @@ Path MTU discovery (see [RFC1191] and [RFC8201]). No standardized configuration method is required. 4.3. Congestion Control Congestion control is a local configuration option. No standardized configuration method is required. 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 - enable operation of IP-TFS on a child SA pair. The method used is - similar to how USE_TRANSPORT_MODE is negotiated, as described in - [RFC7296]. + As mentioned previously IP-TFS tunnels utilize ESP payloads of type + AGGFRAG_PAYLOAD. - To request IP-TFS operation on the Child SA pair, the initiator - includes the USE_IPTFS 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_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. + When using IKEv2, a new "USE_AGGFRAG" Notification Message is used to + enable use of the AGGFRAG_PAYLOAD payload on a child SA pair. The + method used is similar to how USE_TRANSPORT_MODE is negotiated, as + described in [RFC7296]. - 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 - 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 requirement flags are not understood or cannot be supported by the - receiver then the receiver should not enable IP-TFS mode (either by - not responding with the USE_IPTFS notification, or in the case of the - initiator, by deleting the child SA if the now established non-IP-TFS - operation is unacceptable). + receiver then the receiver should not enable use of AGGFRAG_PAYLOAD + payload type (either by not responding with the USE_AGGFRAG + notification, or in the case of the initiator, by deleting the child + SA if the now established non-AGGFRAG_PAYLOAD using SA is + unacceptable). The notification type and payload flag values are defined in Section 6.1.4. 6. Packet and Data Formats -6.1. IP-TFS Payload +6.1. AGGFRAG_PAYLOAD Payload ESP Payload Type: 0x5 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. 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+- | Sub-type | ... +-+-+-+-+-+-+-+-+-+-+- Sub-type: An 8 bit value indicating the payload format. This specification defines 2 payload sub-types. These payload 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 - octet header followed by a variable amount of "DataBlocks" data as + The non-congestion control AGGFRAG_PAYLOAD payload is comprised of a + 4 octet header followed by a variable amount of "DataBlocks" data as shown below. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Type (0) | Reserved | BlockOffset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DataBlocks ... +-+-+-+-+-+-+-+-+-+-+- @@ -584,23 +593,23 @@ block being re-assembled. If the "BlockOffset" extends into subsequent packets it continues to only count subsequent "DataBlocks" data (i.e., it does not count subsequent packets non-"DataBlocks" octets). DataBlocks: Variable number of octets that begins with the start of a data block, or the continuation of a previous data block, followed by 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 shown below. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-type (1) | Reserved |E| BlockOffset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LossEventRate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -633,46 +642,47 @@ LossEventRate: A 32 bit value specifying the inverse of the current loss event rate as calculated by the receiver. A value of zero indicates no loss. Otherwise the loss event rate is "1/LossEventRate". RTT: A 22 bit value specifying the sender's current round-trip time estimate in microseconds. The value MAY be zero prior to the 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 - equal to or larger than "0x3FFFFF" it MUST be set to "0x3FFFFF". + SHOULD be set to zero on non-AGGFRAG_PAYLOAD enabled SAs. If the + value is equal to or larger than "0x3FFFFF" it MUST be set to + "0x3FFFFF". Echo Delay: A 21 bit value specifying the delay in microseconds incurred between the receiver first receiving the "TVal" value which it is sending back in "TEcho". If the value is equal to or larger than "0x1FFFFF" it MUST be set to "0x1FFFFF". Transmit Delay: A 21 bit value specifying the transmission delay in microseconds. 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 larger than "0x1FFFFF" it MUST be set to "0x1FFFFF". TVal: 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 - how long that echo took. + later packets in the "TEcho" field, along with an "Echo Delay" + value of how long that echo took. TEcho: The opaque 32 bit value from a received packet's "TVal" field. - The received "TVal" is placed in "TEcho" along with a "Delay" - value indicating how long it has been since receiving the "TVal" - value. + The received "TVal" is placed in "TEcho" along with an "Echo + Delay" value indicating how long it has been since receiving the + "TVal" value. DataBlocks: Variable number of octets that begins with the start of a data block, or the continuation of a previous data block, followed by zero or more additional data blocks. For the special case of sending congestion control information on an non-IP-TFS enabled SA this value MUST be empty (i.e., be zero octets long). 6.1.3. Data Blocks @@ -735,26 +745,26 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x0 | Padding ... +-+-+-+-+-+-+-+-+-+-+- Type: A 4 bit value of 0x0 indicating a padding data block. Padding: 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 - to negotiate IP-TFS operation in IKEv2. + As discussed in Section 5.1 a notification message USE_AGGFRAG is + 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. There are currently 2 requirement flags defined. This may be revised by later specifications. +-+-+-+-+-+-+-+-+ |0|0|0|0|0|0|C|D| +-+-+-+-+-+-+-+-+ 0: @@ -765,73 +775,58 @@ Congestion Control bit. If set, then the sender is requiring that congestion control information MUST be returned to it periodically as defined in Section 3. D: Don't Fragment bit, if set indicates the sender of the notify message does not support receiving packet fragments (i.e., inner packets MUST be sent using a single "Data Block"). This value only applies to what the sender is capable of receiving; the 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.1. IPTFS_PROTOCOL Type - - 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 +7.1. AGGFRAG_PAYLOAD Sub-Type Registry - This document requests IANA create a registry called "IPTFS_PROTOCOL - Sub-Type Registry" under "IPTFS_PROTOCOL Parameters" IANA registries. - The registration policy for this registry is "Standards Action" - ([RFC8126] and [RFC7120]). + This document requests IANA create a registry called "AGGFRAG_PAYLOAD + Sub-Type Registry" under a new category named "ESP AGGFRAG_PAYLOAD + Parameters". The registration policy for this registry is "Standards + Action" ([RFC8126] and [RFC7120]). Name: - IPTFS_PROTOCOL Sub-Type Registry + AGGFRAG_PAYLOAD Sub-Type Registry Description: - IPTFS_PROTOCOL Payload Formats. + AGGFRAG_PAYLOAD Payload Formats. Reference: This document This initial content for this registry is as follows: Sub-Type Name Reference -------------------------------------------------------- 0 Non-Congestion Control Format This document 1 Congestion Control Format This document 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 - "IKEv2 Notify Message Types - Status Types" registry. + This document requests a status type USE_AGGFRAG be allocated from + the "IKEv2 Notify Message Types - Status Types" registry. Value: TBD2 Name: - USE_IPTFS + USE_AGGFRAG Reference: This document 8. Security Considerations This document describes a mechanism to add Traffic Flow Confidentiality to IP traffic. Use of this mechanism is expected to increase the security of the traffic being transported. Other than the additional security afforded by using this mechanism, IP-TFS @@ -988,22 +983,22 @@ which is provided by the receiver). 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 according to the sender's current tunnel send-rate ("X"). 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 loss intervals and calculate the loss event rate value using the weighted average as indicated. The receiver communicates the inverse - of this value back to the sender in the IPTFS_PROTOCOL payload header - field "LossEventRate". + of this value back to the sender in the AGGFRAG_PAYLOAD payload + header field "LossEventRate". The IP-TFS sender now has both the "R" and "p" values and can calculate the correct sending rate. If following [RFC5348] the sender SHOULD also use the slow start mechanism described therein when the IP-TFS SA is first established. Appendix C. Comparisons of IP-TFS C.1. Comparing Overhead @@ -1192,21 +1186,22 @@ Figure 10: Added Latency Notice that the latency values are very similar between the two solutions; however, whereas IP-TFS provides for constant high bandwidth, in some cases even exceeding native Ethernet, ESP with padding often greatly reduces available bandwidth. Appendix D. Acknowledgements 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 The following people made significant contributions to this document. Lou Berger LabN Consulting, L.L.C. Email: lberger@labn.net