draft-ietf-ipsecme-iptfs-11.txt   draft-ietf-ipsecme-iptfs-12.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 October 24, 2021 Intended status: Standards Track November 8, 2021
Expires: April 27, 2022 Expires: May 12, 2022
IP-TFS: Aggregation and Fragmentation Mode for ESP and its Use for IP IP-TFS: Aggregation and Fragmentation Mode for ESP and its Use for IP
Traffic Flow Security Traffic Flow Security
draft-ietf-ipsecme-iptfs-11 draft-ietf-ipsecme-iptfs-12
Abstract Abstract
This document describes a mechanism for aggregation and fragmentation This document describes a mechanism for aggregation and fragmentation
of IP packets when they are being encapsulated in ESP payload. This of IP packets when they are being encapsulated in ESP payload. This
new payload type can be used for various purposes such as decreasing new payload type can be used for various purposes such as decreasing
encapsulation overhead for small IP packets; however, the focus in encapsulation overhead for small IP packets; however, the focus in
this document is to enhance IPsec traffic flow security (IP-TFS) by this document is to enhance IPsec traffic flow security (IP-TFS) by
adding Traffic Flow Confidentiality (TFC) to encrypted IP adding Traffic Flow Confidentiality (TFC) to encrypted IP
encapsulated traffic. TFC is provided by obscuring the size and encapsulated traffic. TFC is provided by obscuring the size and
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 April 27, 2022. This Internet-Draft will expire on May 12, 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 25 skipping to change at page 2, line 25
2. The AGGFRAG Tunnel . . . . . . . . . . . . . . . . . . . . . 4 2. The AGGFRAG Tunnel . . . . . . . . . . . . . . . . . . . . . 4
2.1. Tunnel Content . . . . . . . . . . . . . . . . . . . . . 4 2.1. Tunnel Content . . . . . . . . . . . . . . . . . . . . . 4
2.2. Payload Content . . . . . . . . . . . . . . . . . . . . . 5 2.2. Payload Content . . . . . . . . . . . . . . . . . . . . . 5
2.2.1. Data Blocks . . . . . . . . . . . . . . . . . . . . . 6 2.2.1. Data Blocks . . . . . . . . . . . . . . . . . . . . . 6
2.2.2. End Padding . . . . . . . . . . . . . . . . . . . . . 6 2.2.2. End Padding . . . . . . . . . . . . . . . . . . . . . 6
2.2.3. Fragmentation, Sequence Numbers and All-Pad Payloads 6 2.2.3. Fragmentation, Sequence Numbers and All-Pad Payloads 6
2.2.4. Empty Payload . . . . . . . . . . . . . . . . . . . . 8 2.2.4. Empty Payload . . . . . . . . . . . . . . . . . . . . 8
2.2.5. IP Header Value Mapping . . . . . . . . . . . . . . . 8 2.2.5. IP Header Value Mapping . . . . . . . . . . . . . . . 8
2.2.6. IP Time-To-Live (TTL) and Tunnel errors . . . . . . . 9 2.2.6. IP Time-To-Live (TTL) and Tunnel errors . . . . . . . 9
2.2.7. Effective MTU of the Tunnel . . . . . . . . . . . . . 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. Modes of Operation . . . . . . . . . . . . . . . . . . . 10
2.4.1. Non-Congestion Controlled Mode . . . . . . . . . . . 10 2.4.1. Non-Congestion Controlled Mode . . . . . . . . . . . 10
2.4.2. Congestion Controlled Mode . . . . . . . . . . . . . 10 2.4.2. Congestion Controlled Mode . . . . . . . . . . . . . 10
2.5. Summary of Receiver Processing . . . . . . . . . . . . . 12 2.5. Summary of Receiver Processing . . . . . . . . . . . . . 12
3. Congestion Information . . . . . . . . . . . . . . . . . . . 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. Configuration of AGGFRAG Tunnels for IP-TFS . . . . . . . . . 14
4.1. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . 14 4.1. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2. Fixed Packet Size . . . . . . . . . . . . . . . . . . . . 14 4.2. Fixed Packet Size . . . . . . . . . . . . . . . . . . . . 14
4.3. Congestion Control . . . . . . . . . . . . . . . . . . . 14 4.3. Congestion Control . . . . . . . . . . . . . . . . . . . 14
5. IKEv2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5. IKEv2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. USE_AGGFRAG Notification Message . . . . . . . . . . . . 14 5.1. USE_AGGFRAG Notification Message . . . . . . . . . . . . 15
6. Packet and Data Formats . . . . . . . . . . . . . . . . . . . 15 6. Packet and Data Formats . . . . . . . . . . . . . . . . . . . 15
6.1. AGGFRAG_PAYLOAD Payload . . . . . . . . . . . . . . . . . 15 6.1. AGGFRAG_PAYLOAD Payload . . . . . . . . . . . . . . . . . 15
6.1.1. Non-Congestion Control AGGFRAG_PAYLOAD Payload Format 16 6.1.1. Non-Congestion Control AGGFRAG_PAYLOAD Payload Format 16
6.1.2. Congestion Control AGGFRAG_PAYLOAD Payload Format . . 16 6.1.2. Congestion Control AGGFRAG_PAYLOAD Payload Format . . 17
6.1.3. Data Blocks . . . . . . . . . . . . . . . . . . . . . 18 6.1.3. Data Blocks . . . . . . . . . . . . . . . . . . . . . 19
6.1.4. IKEv2 USE_AGGFRAG Notification Message . . . . . . . 20 6.1.4. IKEv2 USE_AGGFRAG Notification Message . . . . . . . 20
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
7.1. AGGFRAG_PAYLOAD Sub-Type Registry . . . . . . . . . . . . 21 7.1. AGGFRAG_PAYLOAD Sub-Type Registry . . . . . . . . . . . . 21
7.2. USE_AGGFRAG Notify Message Status Type . . . . . . . . . 21 7.2. USE_AGGFRAG Notify Message Status Type . . . . . . . . . 21
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . . 22 9.1. Normative References . . . . . . . . . . . . . . . . . . 22
9.2. Informative References . . . . . . . . . . . . . . . . . 22 9.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A. Example Of An Encapsulated IP Packet Flow . . . . . 24 Appendix A. Example Of An Encapsulated IP Packet Flow . . . . . 24
Appendix B. A Send and Loss Event Rate Calculation . . . . . . . 25 Appendix B. A Send and Loss Event Rate Calculation . . . . . . . 25
Appendix C. Comparisons of IP-TFS . . . . . . . . . . . . . . . 25 Appendix C. Comparisons of IP-TFS . . . . . . . . . . . . . . . 26
C.1. Comparing Overhead . . . . . . . . . . . . . . . . . . . 25 C.1. Comparing Overhead . . . . . . . . . . . . . . . . . . . 26
C.1.1. IP-TFS Overhead . . . . . . . . . . . . . . . . . . . 26 C.1.1. IP-TFS Overhead . . . . . . . . . . . . . . . . . . . 26
C.1.2. ESP with Padding Overhead . . . . . . . . . . . . . . 26 C.1.2. ESP with Padding Overhead . . . . . . . . . . . . . . 26
C.2. Overhead Comparison . . . . . . . . . . . . . . . . . . . 27 C.2. Overhead Comparison . . . . . . . . . . . . . . . . . . . 27
C.3. Comparing Available Bandwidth . . . . . . . . . . . . . . 28 C.3. Comparing Available Bandwidth . . . . . . . . . . . . . . 28
C.3.1. Ethernet . . . . . . . . . . . . . . . . . . . . . . 28 C.3.1. Ethernet . . . . . . . . . . . . . . . . . . . . . . 28
Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 30 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 30
Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 30 Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 30
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 30 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 31
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 directly information about data being sent through a network. While directly
obscuring the data with encryption [RFC4303], the traffic pattern obscuring the data with encryption [RFC4303], the traffic pattern
itself exposes information due to variations in its shape and timing itself exposes information due to variations in its shape and timing
([RFC8546], [AppCrypt]). Hiding the size and frequency of traffic is ([RFC8546], [AppCrypt]). Hiding the size and frequency of traffic is
referred to as Traffic Flow Confidentiality (TFC) per [RFC4303]. referred to as Traffic Flow Confidentiality (TFC) per [RFC4303].
skipping to change at page 7, line 17 skipping to change at page 7, line 17
the next inner-packet fragment is expected to arrive in. the next inner-packet fragment is expected to arrive in.
Given the above, the receiver will need to handle out-of-order Given the above, the receiver will need to handle out-of-order
arrival of outer ESP packets prior to reassembly processing. ESP arrival of outer ESP packets prior to reassembly processing. ESP
already provides for optionally detecting replay attacks. Detecting already provides for optionally detecting replay attacks. Detecting
replay attacks normally utilizes a window method. A similar sequence replay attacks normally utilizes a window method. A similar sequence
number based sliding window can be used to correct re-ordering of the number based sliding window can be used to correct re-ordering of the
outer packet stream. Receiving a larger (newer) sequence number outer packet stream. Receiving a larger (newer) sequence number
packet advances the window, and received older ESP packets whose packet advances the window, and received older ESP packets whose
sequence numbers the window has passed by are dropped. A good choice 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. 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 the window size SHOULD be configurable by the user. Implementations
MAY also dynamically adjust the reordering window based on actual 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 Please note when IP-TFS sends a continuous stream of packets, there
is no requirement for an explicit drop timer; however, using a drop is no requirement for an explicit lost packet timer; however, using a
timer is RECOMMENDED. If an implementation does not use a drop timer lost packet timer is RECOMMENDED. If an implementation does not use
and only considers an outer packet lost when the reorder window moves a lost packet timer and only considers an outer packet lost when the
by it, the inner traffic can be delayed by up to the reorder window reorder window moves by it, the inner traffic can be delayed by up to
size times the per packet send rate. This amount of delay could be the reorder window size times the per packet send rate. This amount
significant for slower send rates or when larger reorder window sizes of delay could be significant for slower send rates or when larger
are in use. 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 While ESP guarantees an increasing sequence number with subsequently
sent packets, it does not actually require the sequence numbers to be sent packets, it does not actually require the sequence numbers to be
generated with no gaps (e.g., sending only even numbered sequence generated with no gaps (e.g., sending only even numbered sequence
numbers would be allowed as long as they are always increasing). numbers would be allowed as long as they are always increasing).
Gaps in the sequence numbers will not work for this document so the Gaps in the sequence numbers will not work for this document so the
sequence number stream MUST increase monotonically by 1 for each sequence number stream MUST increase monotonically by 1 for each
subsequent packet. subsequent packet.
When using the AGGFRAG_PAYLOAD in conjunction with replay detection, When using the AGGFRAG_PAYLOAD in conjunction with replay detection,
skipping to change at page 12, line 9 skipping to change at page 12, line 11
define and implement circuit breakers [RFC8084] as a recovery method define and implement circuit breakers [RFC8084] as a recovery method
of last resort. Enabling circuit breakers is also a reason a user of last resort. Enabling circuit breakers is also a reason a user
may wish to enable congestion information reports even when using the may wish to enable congestion information reports even when using the
non-congestion controlled mode of operation. The definition of non-congestion controlled mode of operation. The definition of
circuit breakers are outside the scope of this document. circuit breakers are outside the scope of this document.
2.5. Summary of Receiver Processing 2.5. Summary of Receiver Processing
An AGGFRAG enabled SA receiver has a few tasks to perform. An AGGFRAG enabled SA receiver has a few tasks to perform.
The receiver first reorders, possibly out-of-order ESP packets The receiver MAY process incoming AGGFRAG_PAYLOAD payloads as soon as
received on an SA into in-sequence-order AGGFRAG_PAYLOAD payloads they arrive as much as it can. I.e., if the incoming AGGFRAG_PAYLOAD
(Section 2.2.3). If congestion control is enabled, the receiver packet contains complete inner packet(s), the receiver should extract
considers a packet lost when it's sequence number is abandoned (e.g., and transmit them immediately. For partial packets the receiver
pushed out of the re-ordering window, or timed-out) by the reordering needs to keep the partial packets in the memory until the they fall
algorithm. As an optional optimization (e.g., to handle very lossy out from the reordering window, or until the missing parts of the
and/or reordered tunnel paths), the receiver MAY transmit any fully packets are received, in which case it will reassemble and transmit
formed inner packets contained within the AGGFRAG_PAYLOADs prior to them. If AGGFRAG_PAYLOAD payload contains multiple packets they
re-ordering the outer packets. 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 Additionally, if congestion control is enabled, the receiver sends
congestion control data (Section 6.1.2) back to the sender as congestion control data (Section 6.1.2) back to the sender as
described in Section 2.4.2 and Section 3. 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 3. Congestion Information
In order to support the congestion control mode, the sender needs to In order to support the congestion control mode, the sender needs to
know the loss event rate and to approximate the RTT [RFC5348]. In know the loss event rate and to approximate the RTT [RFC5348]. In
order to obtain these values, the receiver sends congestion control order to obtain these values, the receiver sends congestion control
information on it's SA back to the sender. Thus, to support information on it's SA back to the sender. Thus, to support
congestion control the receiver must have a paired SA back to the congestion control the receiver must have a paired SA back to the
sender (this is always the case when the tunnel was created using 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 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) enabled SA then an AGGFRAG_PAYLOAD empty payload (i.e., header only)
 End of changes. 16 change blocks. 
37 lines changed or deleted 52 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/