--- 1/draft-ietf-ipsecme-iptfs-09.txt 2021-09-03 05:13:15.298950813 -0700 +++ 2/draft-ietf-ipsecme-iptfs-10.txt 2021-09-03 05:13:15.362952426 -0700 @@ -1,19 +1,19 @@ Network Working Group C. Hopps Internet-Draft LabN Consulting, L.L.C. -Intended status: Standards Track July 5, 2021 -Expires: January 6, 2022 +Intended status: Standards Track September 3, 2021 +Expires: March 7, 2022 IP-TFS: Aggregation and Fragmentation Mode for ESP and its Use for IP Traffic Flow Security - draft-ietf-ipsecme-iptfs-09 + draft-ietf-ipsecme-iptfs-10 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 January 6, 2022. + This Internet-Draft will expire on March 7, 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 @@ -295,46 +295,48 @@ 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, 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), or non-IP-TFS uses of AGGFRAG mode, can of - course use timers to drop packets as well. + reordering 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. 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, the window size for both MAY be reduced to the smaller of the two window sizes. This is because packets outside of the smaller window but inside the larger would still be dropped by the mechanism with the smaller window size. However, there is also no requirement to make these values the same. Indeed, in some cases, such as slow tunnels where a very small or zero reorder window size is - appropriate, the user may want a large replay detection window to log - replayed packets. Additionally, large replay windows can be + appropriate, the user may still want a large replay detection window + to log replayed packets. Additionally, large replay windows can be implemented with very little overhead compared to large reorder windows. Finally, as sequence numbers are reset when switching SAs (e.g., when re-keying a child SA), senders MUST 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, a sender MAY