--- 1/draft-ietf-ipsecme-iptfs-11.txt 2021-11-08 06:13:56.253936397 -0800 +++ 2/draft-ietf-ipsecme-iptfs-12.txt 2021-11-08 06:13:56.317937994 -0800 @@ -1,19 +1,19 @@ Network Working Group C. Hopps Internet-Draft LabN Consulting, L.L.C. -Intended status: Standards Track October 24, 2021 -Expires: April 27, 2022 +Intended status: Standards Track November 8, 2021 +Expires: May 12, 2022 IP-TFS: Aggregation and Fragmentation Mode for ESP and its Use for IP Traffic Flow Security - draft-ietf-ipsecme-iptfs-11 + draft-ietf-ipsecme-iptfs-12 Abstract This document describes a mechanism for aggregation and fragmentation of IP packets when they are being encapsulated in ESP payload. This new payload type can be used for various purposes such as decreasing encapsulation overhead for small IP packets; however, the focus in this document is to enhance IPsec traffic flow security (IP-TFS) by adding Traffic Flow Confidentiality (TFC) to encrypted IP encapsulated traffic. TFC is provided by obscuring the size and @@ -29,21 +29,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 April 27, 2022. + This Internet-Draft will expire on May 12, 2022. Copyright Notice Copyright (c) 2021 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 @@ -60,58 +60,58 @@ 2. The AGGFRAG Tunnel . . . . . . . . . . . . . . . . . . . . . 4 2.1. Tunnel Content . . . . . . . . . . . . . . . . . . . . . 4 2.2. Payload Content . . . . . . . . . . . . . . . . . . . . . 5 2.2.1. Data Blocks . . . . . . . . . . . . . . . . . . . . . 6 2.2.2. End Padding . . . . . . . . . . . . . . . . . . . . . 6 2.2.3. Fragmentation, Sequence Numbers and All-Pad Payloads 6 2.2.4. Empty Payload . . . . . . . . . . . . . . . . . . . . 8 2.2.5. IP Header Value Mapping . . . . . . . . . . . . . . . 8 2.2.6. IP Time-To-Live (TTL) and Tunnel errors . . . . . . . 9 2.2.7. Effective MTU of the Tunnel . . . . . . . . . . . . . 9 - 2.3. Exclusive SA Use . . . . . . . . . . . . . . . . . . . . 9 + 2.3. Exclusive SA Use . . . . . . . . . . . . . . . . . . . . 10 2.4. Modes of Operation . . . . . . . . . . . . . . . . . . . 10 2.4.1. Non-Congestion Controlled Mode . . . . . . . . . . . 10 2.4.2. Congestion Controlled Mode . . . . . . . . . . . . . 10 2.5. Summary of Receiver Processing . . . . . . . . . . . . . 12 3. Congestion Information . . . . . . . . . . . . . . . . . . . 12 - 3.1. ECN Support . . . . . . . . . . . . . . . . . . . . . . . 13 + 3.1. ECN Support . . . . . . . . . . . . . . . . . . . . . . . 14 4. Configuration of AGGFRAG Tunnels for IP-TFS . . . . . . . . . 14 4.1. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . 14 4.2. Fixed Packet Size . . . . . . . . . . . . . . . . . . . . 14 4.3. Congestion Control . . . . . . . . . . . . . . . . . . . 14 - 5. IKEv2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 5.1. USE_AGGFRAG Notification Message . . . . . . . . . . . . 14 + 5. IKEv2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 + 5.1. USE_AGGFRAG Notification Message . . . . . . . . . . . . 15 6. Packet and Data Formats . . . . . . . . . . . . . . . . . . . 15 6.1. AGGFRAG_PAYLOAD Payload . . . . . . . . . . . . . . . . . 15 6.1.1. Non-Congestion Control AGGFRAG_PAYLOAD Payload Format 16 - 6.1.2. Congestion Control AGGFRAG_PAYLOAD Payload Format . . 16 - 6.1.3. Data Blocks . . . . . . . . . . . . . . . . . . . . . 18 + 6.1.2. Congestion Control AGGFRAG_PAYLOAD Payload Format . . 17 + 6.1.3. Data Blocks . . . . . . . . . . . . . . . . . . . . . 19 6.1.4. IKEv2 USE_AGGFRAG Notification Message . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 7.1. AGGFRAG_PAYLOAD Sub-Type Registry . . . . . . . . . . . . 21 7.2. USE_AGGFRAG Notify Message Status Type . . . . . . . . . 21 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 9.1. Normative References . . . . . . . . . . . . . . . . . . 22 9.2. Informative References . . . . . . . . . . . . . . . . . 22 Appendix A. Example Of An Encapsulated IP Packet Flow . . . . . 24 Appendix B. A Send and Loss Event Rate Calculation . . . . . . . 25 - Appendix C. Comparisons of IP-TFS . . . . . . . . . . . . . . . 25 - C.1. Comparing Overhead . . . . . . . . . . . . . . . . . . . 25 + Appendix C. Comparisons of IP-TFS . . . . . . . . . . . . . . . 26 + C.1. Comparing Overhead . . . . . . . . . . . . . . . . . . . 26 C.1.1. IP-TFS Overhead . . . . . . . . . . . . . . . . . . . 26 C.1.2. ESP with Padding Overhead . . . . . . . . . . . . . . 26 C.2. Overhead Comparison . . . . . . . . . . . . . . . . . . . 27 C.3. Comparing Available Bandwidth . . . . . . . . . . . . . . 28 C.3.1. Ethernet . . . . . . . . . . . . . . . . . . . . . . 28 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 30 Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 30 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 30 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 31 1. Introduction Traffic Analysis ([RFC4301], [AppCrypt]) is the act of extracting information about data being sent through a network. While directly obscuring the data with encryption [RFC4303], the traffic pattern itself exposes information due to variations in its shape and timing ([RFC8546], [AppCrypt]). Hiding the size and frequency of traffic is referred to as Traffic Flow Confidentiality (TFC) per [RFC4303]. @@ -289,36 +289,38 @@ 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 optionally detecting replay attacks. Detecting replay attacks normally utilizes a window method. 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 + for the size of this window depends on the amount of misordering the user may normally experience. - As the amount of reordering that may be present is hard to predict, + As the amount of misordering 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. + misordering seen in arriving packets. Please note when IP-TFS sends a continuous stream of packets, there - is no requirement for an explicit drop timer; however, using a drop - timer is RECOMMENDED. If an implementation does not use a drop timer - and only considers an outer packet lost when the reorder window moves - by it, the inner traffic can be delayed by up to the reorder window - size times the per packet send rate. This amount of delay could be - significant for slower send rates or when larger reorder window sizes - are in use. + is no requirement for an explicit lost packet timer; however, using a + lost packet timer is RECOMMENDED. If an implementation does not use + a lost packet timer and only considers an outer packet lost when the + reorder window moves by it, the inner traffic can be delayed by up to + the reorder window size times the per packet send rate. This amount + of delay could be significant for slower send rates or when larger + reorder window sizes are in use. As the lost packet timer affects + delay of inner packet delivery, one could choose to set it + proportionate to the tunnel rate. While ESP guarantees an increasing sequence number with subsequently sent packets, it does not actually require the sequence numbers to be generated with no gaps (e.g., sending only even numbered sequence numbers would be allowed as long as they are always increasing). Gaps in the sequence numbers will not work for this document so the sequence number stream MUST increase monotonically by 1 for each subsequent packet. When using the AGGFRAG_PAYLOAD in conjunction with replay detection, @@ -518,38 +520,51 @@ define and implement circuit breakers [RFC8084] as a recovery method of last resort. Enabling circuit breakers is also a reason a user may wish to enable congestion information reports even when using the non-congestion controlled mode of operation. The definition of circuit breakers are outside the scope of this document. 2.5. Summary of Receiver Processing An AGGFRAG enabled SA receiver has a few tasks to perform. - The receiver first reorders, possibly out-of-order ESP packets - received on an SA into in-sequence-order AGGFRAG_PAYLOAD payloads - (Section 2.2.3). If congestion control is enabled, the receiver - considers a packet lost when it's sequence number is abandoned (e.g., - pushed out of the re-ordering window, or timed-out) by the reordering - algorithm. As an optional optimization (e.g., to handle very lossy - and/or reordered tunnel paths), the receiver MAY transmit any fully - formed inner packets contained within the AGGFRAG_PAYLOADs prior to - re-ordering the outer packets. + The receiver MAY process incoming AGGFRAG_PAYLOAD payloads as soon as + they arrive as much as it can. I.e., if the incoming AGGFRAG_PAYLOAD + packet contains complete inner packet(s), the receiver should extract + and transmit them immediately. For partial packets the receiver + needs to keep the partial packets in the memory until the they fall + out from the reordering window, or until the missing parts of the + packets are received, in which case it will reassemble and transmit + them. If AGGFRAG_PAYLOAD payload contains multiple packets they + SHOULD be sent out in the order they are in the AGGFRAG_PAYLOAD + (i.e., keep the original order they were received on the other end). + The cost of using this method is that an amplification of out-of- + order delivery of inner packets can occur due to inner packet + aggregation. + + Instead of the method described in the previous paragraph, the + receiver MAY reorder out-of-order AGGFRAG_PAYLOAD payloads received + into in-sequence-order AGGFRAG_PAYLOAD payloads (Section 2.2.3), and + only after it has in-order AGGFRAG_PAYLOAD payload stream, the + receiver transmits the inner-packets. Using this method will make + sure the packets are sent in-order, i.e., there is no reordering + possible, but the cost is that a lost packet will cause delay of up + to the lost packet timer interval (or the full reorder window if no + lost packet timer is used), and there will be extra burstiness in the + output stream (when lost packet is dropped out from the re-order + window, all outer packets received after that are then immediately + processed, and sent out back to back). Additionally, if congestion control is enabled, the receiver sends congestion control data (Section 6.1.2) back to the sender as described in Section 2.4.2 and Section 3. - Finally, the receiver processes the now in-order AGGFRAG_PAYLOAD - payload stream to extract the inner-packets (Section 2.2.3, - Section 6.1). - 3. Congestion Information In order to support the congestion control mode, the sender needs to know the loss event rate and 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, 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-AGGFRAG_PAYLOAD enabled SA then an AGGFRAG_PAYLOAD empty payload (i.e., header only)