--- 1/draft-ietf-ipsecme-iptfs-04.txt 2020-12-19 21:13:12.185289077 -0800 +++ 2/draft-ietf-ipsecme-iptfs-05.txt 2020-12-19 21:13:12.241290500 -0800 @@ -1,18 +1,18 @@ Network Working Group C. Hopps Internet-Draft LabN Consulting, L.L.C. -Intended status: Standards Track December 18, 2020 -Expires: June 21, 2021 +Intended status: Standards Track December 20, 2020 +Expires: June 23, 2021 IP Traffic Flow Security Using Aggregation and Fragmentation - draft-ietf-ipsecme-iptfs-04 + draft-ietf-ipsecme-iptfs-05 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 June 21, 2021. + This Internet-Draft will expire on June 23, 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 @@ -52,58 +52,61 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology & Concepts . . . . . . . . . . . . . . . . . 3 2. The IP-TFS Tunnel . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Tunnel Content . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . 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_AGGFRAG Notification Message . . . . . . . . . . . . 11 - 6. Packet and Data Formats . . . . . . . . . . . . . . . . . . . 12 - 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_AGGFRAG Notification Message . . . . . . . 17 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 - 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 . . . . . . . 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 . . . . . . . . . . . . . . 24 - C.3.1. Ethernet . . . . . . . . . . . . . . . . . . . . . . 25 - Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 27 - Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 27 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 27 + 2.2.5. IP Header Value Mapping . . . . . . . . . . . . . . . 8 + 2.2.6. IP Time-To-Live (TTL) and Tunnel errors . . . . . . . 8 + 2.2.7. Effective MTU of the Tunnel . . . . . . . . . . . . . 8 + 2.3. Exclusive SA Use . . . . . . . . . . . . . . . . . . . . 8 + 2.4. Modes of Operation . . . . . . . . . . . . . . . . . . . 9 + 2.4.1. Non-Congestion Controlled Mode . . . . . . . . . . . 9 + 2.4.2. Congestion Controlled Mode . . . . . . . . . . . . . 9 + 3. Congestion Information . . . . . . . . . . . . . . . . . . . 10 + 3.1. ECN Support . . . . . . . . . . . . . . . . . . . . . . . 12 + 4. Configuration . . . . . . . . . . . . . . . . . . . . . . . . 12 + 4.1. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . 12 + 4.2. Fixed Packet Size . . . . . . . . . . . . . . . . . . . . 12 + 4.3. Congestion Control . . . . . . . . . . . . . . . . . . . 12 + 5. IKEv2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 5.1. USE_AGGFRAG Notification Message . . . . . . . . . . . . 13 + 6. Packet and Data Formats . . . . . . . . . . . . . . . . . . . 13 + 6.1. AGGFRAG_PAYLOAD Payload . . . . . . . . . . . . . . . . . 13 + 6.1.1. Non-Congestion Control AGGFRAG_PAYLOAD Payload Format 14 + 6.1.2. Congestion Control AGGFRAG_PAYLOAD Payload Format . . 15 + 6.1.3. Data Blocks . . . . . . . . . . . . . . . . . . . . . 16 + 6.1.4. IKEv2 USE_AGGFRAG Notification Message . . . . . . . 18 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 + 7.1. AGGFRAG_PAYLOAD Sub-Type Registry . . . . . . . . . . . . 19 + 7.2. USE_AGGFRAG Notify Message Status Type . . . . . . . . . 19 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 20 + 9.2. Informative References . . . . . . . . . . . . . . . . . 20 + Appendix A. Example Of An Encapsulated IP Packet Flow . . . . . 22 + Appendix B. A Send and Loss Event Rate Calculation . . . . . . . 23 + Appendix C. Comparisons of IP-TFS . . . . . . . . . . . . . . . 23 + C.1. Comparing Overhead . . . . . . . . . . . . . . . . . . . 23 + C.1.1. IP-TFS Overhead . . . . . . . . . . . . . . . . . . . 23 + C.1.2. ESP with Padding Overhead . . . . . . . . . . . . . . 24 + + C.2. Overhead Comparison . . . . . . . . . . . . . . . . . . . 25 + C.3. Comparing Available Bandwidth . . . . . . . . . . . . . . 25 + C.3.1. Ethernet . . . . . . . . . . . . . . . . . . . . . . 26 + Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 28 + Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 28 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 28 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], the traffic pattern itself exposes information due to variations in it's shape and timing ([I-D.iab-wire-image], [AppCrypt]). Hiding the size and frequency of traffic is referred to as Traffic Flow Confidentiality (TFC) per [RFC4303]. @@ -143,23 +146,25 @@ 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 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]. + The fixed packet size MAY either be specified manually or could be + determined through the other methods such as the Packetization Layer + MTU Discovery (PLMTUD) ([RFC4821], [RFC8899]) or Path MTU discovery + (PMTUD) ([RFC1191], [RFC8201]). PMTUD is known to have issues so + PLMTUD is considered the more robust option. Given the encapsulating packet size and the requested tunnel used bandwidth, the corresponding packet send rate can be calculated. The 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. @@ -192,21 +197,21 @@ 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 payload within the ESP packet. See Section 6.1 for the exact formats of the AGGFRAG_PAYLOAD payload. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Outer Encapsulating Header ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ESP Header... . +---------------------------------------------------------------+ - | ... : BlockOffset | + | [AGGFRAG subtype/flags] : BlockOffset | +---------------------------------------------------------------+ : [Optional Congestion Info] : +---------------------------------------------------------------+ | DataBlocks ... ~ ~ ~ ~ | +---------------------------------------------------------------| . ESP Trailer... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . @@ -220,22 +225,22 @@ Conversely, if the "BlockOffset" value is non-zero it points to the start of the new data block, and the initial "DataBlocks" data belongs to a previous data block that is still being re-assembled. The "BlockOffset" can point past the end of the "DataBlocks" data which indicates that the next data block occurs in a subsequent encapsulating packet. Having the "BlockOffset" always point at the next available data - block allows for recovering the next full inner packet in the - presence of outer encapsulating packet loss. + block allows for recovering the next inner packet in the presence of + outer encapsulating packet loss. An example IP-TFS packet flow can be found in Appendix A. 2.2.1. Data Blocks +---------------------------------------------------------------+ | Type | rest of IPv4, IPv6 or pad. +-------- Figure 2: Layout of IP-TFS data block @@ -270,20 +275,60 @@ 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" payload, it increments the expected sequence number that the next inner-packet fragment is expected to arrive in. + Given the above, the receiver will need to handle out-of-order + arrival of outer ESP packets prior to reassembly processing. ESP + already provides for detecting replay attacks (normally) utilizing a + window. A similar sequence number based sliding window can be used + to correct re-ordering of the outer packet stream. Receiving a + larger (newer) sequence number packet advances the window, and + received older ESP packets whose sequence numbers the window has + passed by are dropped. A good choice for the size of this window + depends on the amount of re-ordering the user may normally + experience. As the amount of reordering that may be present is hard + to predict the window size SHOULD be configurable by the user. + Implementations MAY also dynamically adjust the reordering window + based on actual reordering seen in arriving packets. Finally, we + note that as IP-TFS is sending a continuous stream of packets there + is no requirement for timers (although there's no prohibition either) + as newly arrived packets will cause the window to advance and older + packets will then be processed as they leave the window. + +2.2.3.1. Optional Extra Padding + + When the tunnel bandwidth is not being fully utilized, an + implementation MAY pad-out the current encapsulating packet in order + to deliver an inner packet un-fragmented in the following outer + packet. The benefit would be to avoid inner-packet fragmentation in + the presence of a bursty offered load (non-bursty traffic will + naturally not fragment). The cost is complexity and added delay of + inner traffic. The main advantage to avoiding fragmentation is to + minimize inner packet loss in the presence of outer packet loss. + When this is worthwhile (e.g., how much loss and what type of loss is + required, given different inner traffic shapes and utilization, for + this to make sense), and what values to use for the allowable/added + delay may be worth researching, but is outside the scope of this + document. + + While use of padding to avoid fragmentation does not impact + interoperability, used inappropriately it can reduce the effective + throughput of a tunnel. Implementations implementing the above + approach will need to take care to not reduce the effective capacity, + and overall utility, of the tunnel through the overuse of padding. + 2.2.4. Empty Payload In order to support reporting of congestion control information (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 @@ -298,20 +343,37 @@ unrelated to the IP-TFS tunnel functionality; IP-TFS never IP fragments the inner packets and the inner packets will not affect the fragmentation of the outer encapsulation packets. Likewise, the ECN 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.2.6. IP Time-To-Live (TTL) and Tunnel errors + + [RFC4301] specifies how to modify the inner packet TTL ([RFC0791]). + + Any errors (e.g., ICMP errors arriving back at the tunnel ingress due + to tunnel traffic) should be handled the same as with non IP-TFS + IPsec tunnels. + +2.2.7. Effective MTU of the Tunnel + + Unlike [RFC4301], there is normally no effective MTU (EMTU) on an IP- + TFS tunnel as all IP packet sizes are properly transmitted without + requiring IP fragmentation prior to tunnel ingress. + + If IP-TFS fragmentation has been disabled, then the tunnel's EMTU and + behaviors are the same as normal IPsec tunnels ([RFC4301]). + 2.3. Exclusive SA Use It is not the intention of this specification to allow for mixed use of an AGGFRAG_PAYLOAD enabled SA. In other words, an SA that has 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 @@ -489,23 +551,25 @@ Bandwidth is a local configuration option. For non-congestion controlled mode the bandwidth SHOULD be configured. For congestion controlled mode one can configure the bandwidth or have no configuration and let congestion control discover the maximum bandwidth available. No standardized configuration method is required. 4.2. Fixed Packet Size The fixed packet size to be used for the tunnel encapsulation packets - can be configured manually or can be automatically determined using - Path MTU discovery (see [RFC1191] and [RFC8201]). No standardized - configuration method is required. + MAY be configured manually or can be automatically determined using + other methods such as PLMTUD ([RFC4821], [RFC8899]) or PMTUD + ([RFC1191], [RFC8201]). As PMTUD is known to have issues, PLMTUD is + considered the more robust option. No standardized configuration + method is required. 4.3. Congestion Control Congestion control is a local configuration option. No standardized configuration method is required. 5. IKEv2 5.1. USE_AGGFRAG Notification Message @@ -897,20 +962,24 @@ [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, . [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, DOI 10.17487/RFC4342, March 2006, . + [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU + Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, + . + [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 5348, DOI 10.17487/RFC5348, September 2008, . [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 2014, . [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, @@ -930,20 +999,25 @@ [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., "Path MTU Discovery for IP version 6", STD 87, RFC 8201, DOI 10.17487/RFC8201, July 2017, . + [RFC8899] Fairhurst, G., Jones, T., Tuexen, M., Ruengeler, I., and + T. Voelker, "Packetization Layer Path MTU Discovery for + Datagram Transports", RFC 8899, DOI 10.17487/RFC8899, + September 2020, . + Appendix A. Example Of An Encapsulated IP Packet Flow Below an example inner IP packet flow within the encapsulating tunnel packet stream is shown. Notice how encapsulated IP packets can start and end anywhere, and more than one or less than 1 may occur in a single encapsulating packet. Offset: 0 Offset: 100 Offset: 2900 Offset: 1400 [ ESP1 (1500) ][ ESP2 (1500) ][ ESP3 (1500) ][ ESP4 (1500) ] [--800--][--800--][60][-240-][--4000----------------------][pad] @@ -1187,21 +1261,22 @@ 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. We would also like to thank Valery Smyslov for reviews - and suggestions for improvements. + and suggestions for improvements as well as Joseph Touch for the + transport area review and suggested improvements. Appendix E. Contributors The following people made significant contributions to this document. Lou Berger LabN Consulting, L.L.C. Email: lberger@labn.net