--- 1/draft-ietf-ipsecme-iptfs-05.txt 2021-01-19 09:13:15.513678287 -0800 +++ 2/draft-ietf-ipsecme-iptfs-06.txt 2021-01-19 09:13:15.573679813 -0800 @@ -1,18 +1,18 @@ Network Working Group C. Hopps Internet-Draft LabN Consulting, L.L.C. -Intended status: Standards Track December 20, 2020 -Expires: June 23, 2021 +Intended status: Standards Track January 19, 2021 +Expires: July 23, 2021 - IP Traffic Flow Security Using Aggregation and Fragmentation - draft-ietf-ipsecme-iptfs-05 + IP-TFS: IP Traffic Flow Security Using Aggregation and Fragmentation + draft-ietf-ipsecme-iptfs-06 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,25 +24,25 @@ 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 23, 2021. + This Internet-Draft will expire on July 23, 2021. Copyright Notice - Copyright (c) 2020 IETF Trust and the persons identified as the + 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -51,62 +51,62 @@ Table of Contents 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.4. Empty Payload . . . . . . . . . . . . . . . . . . . . 8 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.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.4. Modes of Operation . . . . . . . . . . . . . . . . . . . 9 2.4.1. Non-Congestion Controlled Mode . . . . . . . . . . . 9 - 2.4.2. Congestion Controlled Mode . . . . . . . . . . . . . 9 - 3. Congestion Information . . . . . . . . . . . . . . . . . . . 10 + 2.4.2. Congestion Controlled Mode . . . . . . . . . . . . . 10 + 3. Congestion Information . . . . . . . . . . . . . . . . . . . 11 3.1. ECN Support . . . . . . . . . . . . . . . . . . . . . . . 12 - 4. Configuration . . . . . . . . . . . . . . . . . . . . . . . . 12 - 4.1. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . 12 - 4.2. Fixed Packet Size . . . . . . . . . . . . . . . . . . . . 12 - 4.3. Congestion Control . . . . . . . . . . . . . . . . . . . 12 + 4. Configuration . . . . . . . . . . . . . . . . . . . . . . . . 13 + 4.1. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . 13 + 4.2. Fixed Packet Size . . . . . . . . . . . . . . . . . . . . 13 + 4.3. Congestion Control . . . . . . . . . . . . . . . . . . . 13 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. Packet and Data Formats . . . . . . . . . . . . . . . . . . . 14 + 6.1. AGGFRAG_PAYLOAD Payload . . . . . . . . . . . . . . . . . 14 + 6.1.1. Non-Congestion Control AGGFRAG_PAYLOAD Payload Format 15 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 + 6.1.3. Data Blocks . . . . . . . . . . . . . . . . . . . . . 17 + 6.1.4. IKEv2 USE_AGGFRAG Notification Message . . . . . . . 19 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 + 7.1. AGGFRAG_PAYLOAD Sub-Type Registry . . . . . . . . . . . . 20 + 7.2. USE_AGGFRAG Notify Message Status Type . . . . . . . . . 20 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 21 + 9.2. Informative References . . . . . . . . . . . . . . . . . 21 + Appendix A. Example Of An Encapsulated IP Packet Flow . . . . . 23 + Appendix B. A Send and Loss Event Rate Calculation . . . . . . . 24 + Appendix C. Comparisons of IP-TFS . . . . . . . . . . . . . . . 24 + C.1. Comparing Overhead . . . . . . . . . . . . . . . . . . . 24 + C.1.1. IP-TFS Overhead . . . . . . . . . . . . . . . . . . . 24 + C.1.2. ESP with Padding Overhead . . . . . . . . . . . . . . 25 - 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 + C.2. Overhead Comparison . . . . . . . . . . . . . . . . . . . 26 + C.3. Comparing Available Bandwidth . . . . . . . . . . . . . . 26 + C.3.1. Ethernet . . . . . . . . . . . . . . . . . . . . . . 27 + Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 29 + Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 29 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 29 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]. @@ -277,57 +277,86 @@ 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. + 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 + 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. Implementations that are + concerned about memory use when packets are delayed (e.g., when an SA + deletion is delayed) can of course use timers to drop packets as + well. + + 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 specification so + the sequence number stream is further restricted to not contain gaps + (i.e., each subsequent outer packet must be sent with the sequence + number incremented by 1). + + When using the AGGFRAG_PAYLOAD in conjunction with replay detection, + the window size for both MAY be reduced to share the smaller of the + two window sizes. This is b/c packets outside of the smaller window + but inside the larger would still be dropped by the mechanism with + the smaller window size. + + Finally, as sequence numbers are reset when switching SAs (e.g., when + re-keying a child SA), an implementation SHOULD NOT send initial + fragments of an inner packet using one SA and subsequent fragments in + a different SA. 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. + naturally not fragment). An implementation MAY also choose to allow + for a minimum fragment size to be configured (e.g., as a percentage + of the AGGFRAG_PAYLOAD payload size) to avoid fragmentation at the + cost of tunnel bandwidth. The cost with these methods 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. + throughput of a tunnel. Implementations implementing either of the + above approaches 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 @@ -343,48 +372,56 @@ 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. + It is worth noting that an implementation MAY still set the ECN value + of inner packets based on the normal ECN specification ([RFC3168]). + 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. + requiring IP fragmentation prior to tunnel ingress. That said, an + implementation MAY allow for explicitly configuring an MTU for the + tunnel. 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 - IPsec uses can configure and use their own SAs. + payloads. Empty AGGFRAG_PAYLOAD payloads (Section 2.2.4) are used to + transmit congestion control information on non-IP-TFS enabled SAs, so + intermixing is allowed in this specific case. 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 mode and congestion controlled mode. @@ -586,21 +623,23 @@ 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 use of the AGGFRAG_PAYLOAD payload type during rekeying. + change use of the AGGFRAG_PAYLOAD payload type during rekeying. A + new child SA due to re-keying inherits the use of AGGFRAG_PAYLOAD + from the re-keyed child SA. 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 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).