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/ |