draft-ietf-ipsecme-iptfs-00.txt   draft-ietf-ipsecme-iptfs-01.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 December 16, 2019 Intended status: Standards Track March 2, 2020
Expires: June 18, 2020 Expires: September 3, 2020
IP Traffic Flow Security IP Traffic Flow Security
draft-ietf-ipsecme-iptfs-00 draft-ietf-ipsecme-iptfs-01
Abstract Abstract
This document describes a mechanism to enhance IPsec traffic flow This document describes a mechanism to enhance IPsec traffic flow
security by adding traffic flow confidentiality to encrypted IP security by adding traffic flow confidentiality to encrypted IP
encapsulated traffic. Traffic flow confidentiality is provided by encapsulated traffic. Traffic flow confidentiality is provided by
obscuring the size and frequency of IP traffic using a fixed-sized, obscuring the size and frequency of IP traffic using a fixed-sized,
constant-send-rate IPsec tunnel. The solution allows for congestion constant-send-rate IPsec tunnel. The solution allows for congestion
control as well. control as well.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 June 18, 2020. This Internet-Draft will expire on September 3, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology & Concepts . . . . . . . . . . . . . . . . . 3 1.1. Terminology & Concepts . . . . . . . . . . . . . . . . . 3
2. The IP-TFS Tunnel . . . . . . . . . . . . . . . . . . . . . . 4 2. The IP-TFS Tunnel . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Tunnel Content . . . . . . . . . . . . . . . . . . . . . 4 2.1. Tunnel Content . . . . . . . . . . . . . . . . . . . . . 4
2.2. IPTFS_PROTOCOL Payload Content . . . . . . . . . . . . . 4 2.2. IPTFS_PROTOCOL Payload Content . . . . . . . . . . . . . 4
2.2.1. Data Blocks . . . . . . . . . . . . . . . . . . . . . 5 2.2.1. Data Blocks . . . . . . . . . . . . . . . . . . . . . 5
2.2.2. No Implicit Padding Required . . . . . . . . . . . . 6 2.2.2. No Implicit End Padding Required . . . . . . . . . . 6
2.2.3. Empty Payload . . . . . . . . . . . . . . . . . . . . 6 2.2.3. Empty Payload . . . . . . . . . . . . . . . . . . . . 6
2.2.4. IP Header Value Mapping . . . . . . . . . . . . . . . 6 2.2.4. IP Header Value Mapping . . . . . . . . . . . . . . . 6
2.3. Exclusive SA Use . . . . . . . . . . . . . . . . . . . . 7 2.3. Exclusive SA Use . . . . . . . . . . . . . . . . . . . . 7
2.4. Initiating IP-TFS Operation On The SA. . . . . . . . . . 7 2.4. Initiating IP-TFS Operation On The SA. . . . . . . . . . 7
2.5. Modes of Operation . . . . . . . . . . . . . . . . . . . 7 2.5. Modes of Operation . . . . . . . . . . . . . . . . . . . 7
2.5.1. Non-Congestion Controlled Mode . . . . . . . . . . . 7 2.5.1. Non-Congestion Controlled Mode . . . . . . . . . . . 7
2.5.2. Congestion Controlled Mode . . . . . . . . . . . . . 8 2.5.2. Congestion Controlled Mode . . . . . . . . . . . . . 8
3. Congestion Information . . . . . . . . . . . . . . . . . . . 9 3. Congestion Information . . . . . . . . . . . . . . . . . . . 9
3.1. ECN Support . . . . . . . . . . . . . . . . . . . . . . . 10 3.1. ECN Support . . . . . . . . . . . . . . . . . . . . . . . 10
4. Configuration . . . . . . . . . . . . . . . . . . . . . . . . 10 4. Configuration . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2. Fixed Packet Size . . . . . . . . . . . . . . . . . . . . 10 4.2. Fixed Packet Size . . . . . . . . . . . . . . . . . . . . 10
4.3. Congestion Control . . . . . . . . . . . . . . . . . . . 11 4.3. Congestion Control . . . . . . . . . . . . . . . . . . . 11
5. IKEv2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. IKEv2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. TFS Type Transform Type . . . . . . . . . . . . . . . . . 11 5.1. USE_TFS Notification Message . . . . . . . . . . . . . . 11
5.2. IPTFS_REQUIREMENTS Status Notification . . . . . . . . . 11 6. Packet and Data Formats . . . . . . . . . . . . . . . . . . . 11
6. Packet and Data Formats . . . . . . . . . . . . . . . . . . . 12 6.1. IP-TFS Payload . . . . . . . . . . . . . . . . . . . . . 11
6.1. ESP IP-TFS Payload . . . . . . . . . . . . . . . . . . . 12
6.1.1. Non-Congestion Control IPTFS_PROTOCOL Payload Format 12 6.1.1. Non-Congestion Control IPTFS_PROTOCOL Payload Format 12
6.1.2. Congestion Control IPTFS_PROTOCOL Payload Format . . 13 6.1.2. Congestion Control IPTFS_PROTOCOL Payload Format . . 13
6.1.3. Data Blocks . . . . . . . . . . . . . . . . . . . . . 14 6.1.3. Data Blocks . . . . . . . . . . . . . . . . . . . . . 14
6.1.4. IKEv2 USE_IPTFS Notification Message . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7.1. IPTFS_PROTOCOL Type . . . . . . . . . . . . . . . . . . . 16 7.1. IPTFS_PROTOCOL Type . . . . . . . . . . . . . . . . . . . 16
7.2. IKEv2 Transform Type TFS Type . . . . . . . . . . . . . . 16 7.2. IPTFS_PROTOCOL Sub-Type Registry . . . . . . . . . . . . 16
7.3. TFS Type Transform IDs Registry . . . . . . . . . . . . . 17 7.3. USE_IPTFS Notify Message Status Type . . . . . . . . . . 17
7.4. IPTFS_REQUIREMENTS Notify Message Status Type . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . 18 9.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Example Of An Encapsulated IP Packet Flow . . . . . 19 Appendix A. Example Of An Encapsulated IP Packet Flow . . . . . 20
Appendix B. A Send and Loss Event Rate Calculation . . . . . . . 20 Appendix B. A Send and Loss Event Rate Calculation . . . . . . . 20
Appendix C. Comparisons of IP-TFS . . . . . . . . . . . . . . . 21 Appendix C. Comparisons of IP-TFS . . . . . . . . . . . . . . . 21
C.1. Comparing Overhead . . . . . . . . . . . . . . . . . . . 21 C.1. Comparing Overhead . . . . . . . . . . . . . . . . . . . 21
C.1.1. IP-TFS Overhead . . . . . . . . . . . . . . . . . . . 21 C.1.1. IP-TFS Overhead . . . . . . . . . . . . . . . . . . . 21
C.1.2. ESP with Padding Overhead . . . . . . . . . . . . . . 21 C.1.2. ESP with Padding Overhead . . . . . . . . . . . . . . 21
C.2. Overhead Comparison . . . . . . . . . . . . . . . . . . . 22 C.2. Overhead Comparison . . . . . . . . . . . . . . . . . . . 22
C.3. Comparing Available Bandwidth . . . . . . . . . . . . . . 23 C.3. Comparing Available Bandwidth . . . . . . . . . . . . . . 23
C.3.1. Ethernet . . . . . . . . . . . . . . . . . . . . . . 23 C.3.1. Ethernet . . . . . . . . . . . . . . . . . . . . . . 23
Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 25 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 25
Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 25 Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 25
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
Traffic Analysis ([RFC4301], [AppCrypt]) is the act of extracting Traffic Analysis ([RFC4301], [AppCrypt]) is the act of extracting
skipping to change at page 4, line 25 skipping to change at page 4, line 25
The fixed packet size may either be specified manually or can be The fixed packet size may either be specified manually or can be
determined through the use of Path MTU discovery [RFC1191] and determined through the use of Path MTU discovery [RFC1191] and
[RFC8201]. [RFC8201].
Given the encapsulating packet size and the requested tunnel Given the encapsulating packet size and the requested tunnel
bandwidth, the corresponding packet send rate can be calculated. The bandwidth, the corresponding packet send rate can be calculated. The
packet send rate is the requested bandwidth divided by the payload packet send rate is the requested bandwidth divided by the payload
size of the encapsulating packet. size of the encapsulating packet.
The egress of the IP-TFS tunnel MUST allow for, and expect the The egress of the IP-TFS tunnel MUST allow for and expect the ingress
ingress (sending) side of the IP-TFS tunnel to vary the size and rate (sending) side of the IP-TFS tunnel to vary the size and rate of sent
of sent encapsulating packets, unless constrained by other policy. encapsulating packets, unless constrained by other policy.
2.1. Tunnel Content 2.1. Tunnel Content
As previously mentioned, one issue with the TFC padding solution in As previously mentioned, one issue with the TFC padding solution in
[RFC4303] is the large amount of wasted bandwidth as only one IP [RFC4303] is the large amount of wasted bandwidth as only one IP
packet can be sent per encapsulating packet. In order to maximize packet can be sent per encapsulating packet. In order to maximize
bandwidth IP-TFS breaks this one-to-one association. bandwidth IP-TFS breaks this one-to-one association.
With IP-TFS we aggregate as well as fragment the inner IP traffic With IP-TFS we aggregate as well as fragment the inner IP traffic
flow into fixed-sized encapsulating IPsec tunnel packets. We only flow into fixed-sized encapsulating IPsec tunnel packets. We only
pad the tunnel packets if there is no data available to be sent at pad the tunnel packets if there is no data available to be sent at
the time of tunnel packet transmission, or if fragmentation has been the time of tunnel packet transmission, or if fragmentation has been
disabled by the receiver. disabled by the receiver.
In order to do this we use a new Encapsulating Security Payload (ESP, In order to do this we use a new Encapsulating Security Payload (ESP,
[RFC4303]) payload type which is the new IP protocol number [RFC4303]) type which is identified by the IP protocol number
IPTFS_PROTOCOL (TBD1). IPTFS_PROTOCOL (TBD1).
2.2. IPTFS_PROTOCOL Payload Content 2.2. IPTFS_PROTOCOL Payload Content
The IPTFS_PROTOCOL ESP payload is comprised a 4 or 16 octet header The IPTFS_PROTOCOL payload content defined in this document is
followed by either a partial, a full or multiple partial or full data comprised of a 4 or 16 octet header followed by either a partial, a
blocks. The following diagram illustrates the IPTFS_PROTOCOL ESP full or multiple partial or full data blocks. The following diagram
payload within the ESP packet. See Section 6.1 for the exact formats illustrates this IPTFS_PROTOCOL payload within the ESP packet. See
of the IPTFS_PROTOCOL payload. Section 6.1 for the exact formats of the IPTFS_PROTOCOL payload.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. Outer Encapsulating Header ... . . Outer Encapsulating Header ... .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. ESP Header... . . ESP Header... .
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| ... : BlockOffset | | ... : BlockOffset |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
: [Optional Congestion Info] : : [Optional Congestion Info] :
+---------------------------------------------------------------+ +---------------------------------------------------------------+
skipping to change at page 6, line 9 skipping to change at page 6, line 9
Figure 2: Layout of IP-TFS data block Figure 2: Layout of IP-TFS data block
A data block is defined by a 4-bit type code followed by the data A data block is defined by a 4-bit type code followed by the data
block data. The type values have been carefully chosen to coincide block data. The type values have been carefully chosen to coincide
with the IPv4/IPv6 version field values so that no per-data block with the IPv4/IPv6 version field values so that no per-data block
type overhead is required to encapsulate an IP packet. Likewise, the type overhead is required to encapsulate an IP packet. Likewise, the
length of the data block is extracted from the encapsulated IPv4 or length of the data block is extracted from the encapsulated IPv4 or
IPv6 packet's length field. IPv6 packet's length field.
2.2.2. No Implicit Padding Required 2.2.2. No Implicit End Padding Required
It's worth noting that there is never a need for an implicit pad at It's worth noting that since a data block type is identified by its
the end of an encapsulating packet. Even when the start of a data first octet there is never a need for an implicit pad at the end of
block occurs near the end of a encapsulating packet such that there an encapsulating packet. Even when the start of a data block occurs
is no room for the length field of the encapsulated header to be near the end of a encapsulating packet such that there is no room for
included in the current encapsulating packet, the fact that the the length field of the encapsulated header to be included in the
length comes at a known location and is guaranteed to be present is current encapsulating packet, the fact that the length comes at a
enough to fetch the length field from the subsequent encapsulating known location and is guaranteed to be present is enough to fetch the
packet payload. Only when there is no data to encapsulate is padding length field from the subsequent encapsulating packet payload. Only
required, and then an explicit "Pad Data Block" would be used to when there is no data to encapsulated is end padding required, and
identify the padding. then an explicit "Pad Data Block" would be used to identify the
padding.
2.2.3. Empty Payload 2.2.3. Empty Payload
In order to support reporting of congestion control information In order to support reporting of congestion control information
(described later) on a non-IP-TFS enabled SA, IP-TFS allows for the (described later) on a non-IP-TFS enabled SA, IP-TFS allows for the
sending of an IP-TFS payload with no data blocks (i.e., the ESP sending of an IP-TFS payload with no data blocks (i.e., the ESP
payload length is equal to the IP-TFS header length). This special payload length is equal to the IP-TFS header length). This special
payload is called an empty payload. payload is called an empty payload.
2.2.4. IP Header Value Mapping 2.2.4. IP Header Value Mapping
skipping to change at page 11, line 12 skipping to change at page 11, line 12
Path MTU discovery (see [RFC1191] and [RFC8201]). No standardized Path MTU discovery (see [RFC1191] and [RFC8201]). No standardized
configuration method is required. configuration method is required.
4.3. Congestion Control 4.3. Congestion Control
Congestion control is a local configuration option. No standardized Congestion control is a local configuration option. No standardized
configuration method is required. configuration method is required.
5. IKEv2 5. IKEv2
5.1. TFS Type Transform Type 5.1. USE_TFS Notification Message
When IP-TFS is used with IKEv2 a new "TFS Type" Transform Type (TBD2) When using IKEv2, a new "USE_IPTFS" Notification Message is used to
is used to negotiate (as defined in [RFC7296]) the possible operation enable operation of IP-TFS on a child SA pair. The method used is
of IP-TFS on a child SA pair. This document defines 3 "TFS Type" similar to how USE_TRANSPORT_MODE is negotiated, as described in
Transform IDs for the new "TFS Type" Transform Type: None (0), [RFC7296].
TFS_IPTFS_CC (1) for congestion-controlled IP-TFS mode or
TFS_IPTFS_NOCC (2) for non-congestion controlled IP-TFS mode. The
selection of a proposal with a "TFS Type" Transform ID TFS_IPTFS_CC
or TFS_IPTFS_NOCC does not mandate the use of IP-TFS, rather it
indicates a willingness or intent to use IP-TFS on the SA pair. In
addition, a new Notify Message Status Type IPTFS_REQUIREMENTS (TBD3)
MAY be used by the initiator as well as the responder to further
refine any operational requirements.
Additional "TFS Type" Transform IDs may be defined in the future, and To request IP-TFS operation on the Child SA pair, the initiator
so readers are referred to [IKEV2IANA] for the most up to date list. includes the USE_IPTFS notification in an SA payload 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_IPTFS. If the responder
declines the request the child SA will be established without IP-TFS
enabled. If this is unacceptable to the initiator, the initiator
MUST delete the child SA.
5.2. IPTFS_REQUIREMENTS Status Notification The USE_IPTFS notification MUST NOT be sent, and MUST be ignored,
during a CREATE_CHILD_SA rekeying exchange as it is not allowed to
change IP-TFS operation during rekeying.
As mentioned in the previous section, a new Notify Message Status The USE_IPTFS notification contains a 1 octet payload of flags that
Type IPTFS_REQUIREMENTS (TBD3) MAY be sent by the initiator and/or specify any requirements from the sender of the message. If any
the responder to further refine what will be supported. This requirement flags are not understood or cannot be supported by the
notification is sent during IKE_AUTH and new CREATE_CHILD_SA receiver then the receiver should not enable IP-TFS mode (either by
exchanges; however, it MUST NOT be sent, and MUST be ignored, during not responding with the USE_IPTFS notification, or in the case of the
a CREATE_CHILD_SA rekeying exchange as the requirements are not initiator, by deleting the child SA if the now established non-IP-TFS
allowed to change during rekeying. operation is unacceptable).
The IPTFS_REQUIREMENTS notification contains a 1 octet payload of The notification type and payload flag values are defined in
flags that specify any extra requirements from the sender of the Section 6.1.4.
message. The flag values (currently a single flag) are defined
below. If the IPTFS_REQUIREMENTS notification is not sent then it
implies that all the flag bits are clear.
+-+-+-+-+-+-+-+-+ 6. Packet and Data Formats
|0|0|0|0|0|0|0|D|
+-+-+-+-+-+-+-+-+
0: 6.1. IP-TFS Payload
MUST be zero on send and MUST be ignored on receive.
D: An IP-TFS payload is identified by the IP protocol number
Don't Fragment bit, if set indicates the sender of the notify IPTFS_PROTOCOL (TBD1). The first octet of this payload indicates the
message does not support receiving packet fragments (i.e., inner format of the remaining payload data.
packets MUST be sent using a single "Data Block"). This value
only applies to what the sender is capable of receiving; the
sender MAY still send packet fragments unless similarly restricted
by the receiver in it's IPTFS_REQUIREMENTS notification.
6. Packet and Data Formats 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-
| Sub-type | ...
+-+-+-+-+-+-+-+-+-+-+-
6.1. ESP IP-TFS Payload Sub-type:
An 8 bit value indicating the payload format.
An ESP IP-TFS payload is identified by the IP protocol number This specification defines 2 payload sub-types. These payload
IPTFS_PROTOCOL (TBD1). This payload begins with a fixed 4 or 16 formats are defined in the following sections.
octet header followed by a variable amount of "DataBlocks" data. The
exact payload format and fields are defined in the following
sections.
6.1.1. Non-Congestion Control IPTFS_PROTOCOL Payload Format 6.1.1. Non-Congestion Control IPTFS_PROTOCOL Payload Format
The non-congestion control IPTFS_PROTOCOL payload is comprised of a 4 The non-congestion control IPTFS_PROTOCOL payload is comprised of a 4
octet header followed by a variable amount of "DataBlocks" data as octet header followed by a variable amount of "DataBlocks" data as
shown below. shown below.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V|C| Reserved | BlockOffset | | Sub-Type (0) | Reserved | BlockOffset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DataBlocks ... | DataBlocks ...
+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-
V: Sub-type:
A 1 bit version field that MUST be set to zero. If received as An octet indicating the payload format. For this non-congestion
one the packet MUST be dropped. control format, the value is 0.
C:
A 1 bit value that MUST be set to 0 to indicate no congestion
control information is present.
Reserved: Reserved:
A 14 bit field set to 0 and ignored on receipt. An octet set to 0 on generation, and ignored on receipt.
BlockOffset: BlockOffset:
A 16 bit unsigned integer counting the number of octets of A 16 bit unsigned integer counting the number of octets of
"DataBlocks" data before the start of a new data block. "DataBlocks" data before the start of a new data block.
"BlockOffset" can count past the end of the "DataBlocks" data in "BlockOffset" can count past the end of the "DataBlocks" data in
which case all the "DataBlocks" data belongs to the previous data which case all the "DataBlocks" data belongs to the previous data
block being re-assembled. If the "BlockOffset" extends into block being re-assembled. If the "BlockOffset" extends into
subsequent packets it continues to only count subsequent subsequent packets it continues to only count subsequent
"DataBlocks" data (i.e., it does not count subsequent packets "DataBlocks" data (i.e., it does not count subsequent packets
non-"DataBlocks" octets). non-"DataBlocks" octets).
skipping to change at page 13, line 23 skipping to change at page 13, line 14
6.1.2. Congestion Control IPTFS_PROTOCOL Payload Format 6.1.2. Congestion Control IPTFS_PROTOCOL Payload Format
The congestion control IPTFS_PROTOCOL payload is comprised of a 16 The congestion control IPTFS_PROTOCOL payload is comprised of a 16
octet header followed by a variable amount of "DataBlocks" data as octet header followed by a variable amount of "DataBlocks" data as
shown below. shown below.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V|C|E| Reserved | BlockOffset | | Sub-type (1) | Reserved |E| BlockOffset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTT | Delay | | RTT | Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LossEventRate | | LossEventRate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LastSeqNum | | LastSeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DataBlocks ... | DataBlocks ...
+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-
V: Sub-type:
A 1 bit version field that MUST be set to zero. If received as An octet indicating the payload format. For this congestion
one the packet MUST be dropped. control format, the value is 1.
C: Reserved:
A 1 bit value that MUST be set to 1 which indicates the presence A 7 bit field set to 0 on generation, and ignored on receipt.
of the congestion information header fields "RTT", "Delay",
"LossEventRate" and "LastSeqNum".
E: E:
A 1 bit value if set indicates that Congestion Experienced (CE) A 1 bit value if set indicates that Congestion Experienced (CE)
ECN bits were received and used in deriving the reported ECN bits were received and used in deriving the reported
"LossEventRate". "LossEventRate".
Reserved:
A 13 bit field set to 0 and ignored on receipt.
BlockOffset: BlockOffset:
The same value as the non-congestion controlled payload format The same value as the non-congestion controlled payload format
value. value.
RTT: RTT:
A 16 bit value specifying the sender's current round-trip time A 16 bit value specifying the sender's current round-trip time
estimate in milliseconds. The value MAY be zero prior to the estimate in milliseconds. The value MAY be zero prior to the
sender having calculated a round-trip time estimate. The value sender having calculated a round-trip time estimate. The value
SHOULD be set to zero on non-IP-TFS enabled SAs. SHOULD be set to zero on non-IP-TFS enabled SAs.
Delay: Delay:
skipping to change at page 15, line 24 skipping to change at page 15, line 6
These values are the actual values within the encapsulated IPv4 These values are the actual values within the encapsulated IPv4
header. In other words, the start of this data block is the start of header. In other words, the start of this data block is the start of
the encapsulated IP packet. the encapsulated IP packet.
Type: Type:
A 4 bit value of 0x4 indicating IPv4 (i.e., first nibble of the A 4 bit value of 0x4 indicating IPv4 (i.e., first nibble of the
IPv4 packet). IPv4 packet).
TotalLength: TotalLength:
The 16 bit unsigned integer length field of the IPv4 inner packet. The 16 bit unsigned integer "Total Length" field of the IPv4 inner
packet.
6.1.3.2. IPv6 Data Block 6.1.3.2. IPv6 Data Block
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x6 | TrafficClass | FlowLabel | | 0x6 | TrafficClass | FlowLabel |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TotalLength | Rest of the inner packet ... | PayloadLength | Rest of the inner packet ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
These values are the actual values within the encapsulated IPv6 These values are the actual values within the encapsulated IPv6
header. In other words, the start of this data block is the start of header. In other words, the start of this data block is the start of
the encapsulated IP packet. the encapsulated IP packet.
Type: Type:
A 4 bit value of 0x6 indicating IPv6 (i.e., first nibble of the A 4 bit value of 0x6 indicating IPv6 (i.e., first nibble of the
IPv6 packet). IPv6 packet).
TotalLength: PayloadLength:
The 16 bit unsigned integer length field of the inner IPv6 inner The 16 bit unsigned integer "Payload Length" field of the inner
packet. IPv6 inner packet.
6.1.3.3. Pad Data Block 6.1.3.3. Pad Data Block
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0 | Padding ... | 0x0 | Padding ...
+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-
Type: Type:
A 4 bit value of 0x0 indicating a padding data block. A 4 bit value of 0x0 indicating a padding data block.
Padding: Padding:
skipping to change at page 16, line 16 skipping to change at page 15, line 45
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0 | Padding ... | 0x0 | Padding ...
+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-
Type: Type:
A 4 bit value of 0x0 indicating a padding data block. A 4 bit value of 0x0 indicating a padding data block.
Padding: Padding:
extends to end of the encapsulating packet. extends to end of the encapsulating packet.
6.1.4. IKEv2 USE_IPTFS Notification Message
As discussed in Section 5.1 a notification message USE_IPTFS is used
to negotiate IP-TFS operation in IKEv2.
The USE_IPTFS Notification Message State Type is (TBD2).
The notification payload contains 1 octet of requirement flags.
There are currently 2 requirement flags defined. This may be revised
by later specifications.
+-+-+-+-+-+-+-+-+
|0|0|0|0|0|0|C|D|
+-+-+-+-+-+-+-+-+
0:
6 bits - reserved, MUST be zero on send, unless defined by later
specifications.
C:
Congestion Control bit. If set, then the sender is requiring that
congestion control information MUST be returned to it periodically
as defined in Section 3.
D:
Don't Fragment bit, if set indicates the sender of the notify
message does not support receiving packet fragments (i.e., inner
packets MUST be sent using a single "Data Block"). This value
only applies to what the sender is capable of receiving; the
sender MAY still send packet fragments unless similarly restricted
by the receiver in it's USE_IPTFS notification.
7. IANA Considerations 7. IANA Considerations
7.1. IPTFS_PROTOCOL Type 7.1. IPTFS_PROTOCOL Type
This document requests a protocol number IPTFS_PROTOCOL be allocated This document requests a protocol number IPTFS_PROTOCOL be allocated
by IANA from "Assigned Internet Protocol Numbers" registry for by IANA from "Assigned Internet Protocol Numbers" registry for
identifying the IP-TFS ESP payload format. identifying the IP-TFS payload.
Type: Type:
TBD1 TBD1
Description: Description:
IP-TFS ESP payload format. An IP-TFS payload.
Reference: Reference:
This document This document
7.2. IKEv2 Transform Type TFS Type 7.2. IPTFS_PROTOCOL Sub-Type Registry
This document requests an IKEv2 Transform Type "TFS Type" be This document requests IANA create a registry called "IPTFS_PROTOCOL
allocated by IANA from the "Transform Type Values" registry. Sub-Type Registry" under "IPTFS_PROTOCOL Parameters" IANA registries.
The registration policy for this registry is "Standards Action"
([RFC8126] and [RFC7120]).
Type: Name:
TBD2 IPTFS_PROTOCOL Sub-Type Registry
Description: Description:
TFS Type IPTFS_PROTOCOL Payload Formats.
Used In:
(optional in ESP)
Reference: Reference:
This document This document
7.3. TFS Type Transform IDs Registry This initial content for this registry is as follows:
This document requests a "Transform Type TBD3 - TFS Type Transform
IDs" registry be created. The registration procedure is Expert
Review. The initial values are as follows:
Number Name Reference Sub-Type Name Reference
---------------------------------------- --------------------------------------------------------
0 NONE This document 0 Non-Congestion Control Format This document
1 TFS_IPTFS_CC This document 1 Congestion Control Format This document
2 TFS_IPTFS_NOCC This document 3-255 Reserved
3-65535 Reserved This document
7.4. IPTFS_REQUIREMENTS Notify Message Status Type 7.3. USE_IPTFS Notify Message Status Type
This document requests a status type IPTFS_REQUIREMENTS be allocated This document requests a status type USE_IPTFS be allocated from the
from the "IKEv2 Notify Message Types - Status Types" registry. "IKEv2 Notify Message Types - Status Types" registry.
Value: Value:
TBD3 TBD2
Name: Name:
IPTFS_REQUIREMENTS USE_IPTFS
Reference: Reference:
This document This document
8. Security Considerations 8. Security Considerations
This document describes a mechanism to add Traffic Flow This document describes a mechanism to add Traffic Flow
Confidentiality to IP traffic. Use of this mechanism is expected to Confidentiality to IP traffic. Use of this mechanism is expected to
increase the security of the traffic being transported. Other than increase the security of the traffic being transported. Other than
the additional security afforded by using this mechanism, IP-TFS the additional security afforded by using this mechanism, IP-TFS
skipping to change at page 18, line 34 skipping to change at page 18, line 38
[AppCrypt] [AppCrypt]
Schneier, B., "Applied Cryptography: Protocols, Schneier, B., "Applied Cryptography: Protocols,
Algorithms, and Source Code in C", 11 2017. Algorithms, and Source Code in C", 11 2017.
[I-D.iab-wire-image] [I-D.iab-wire-image]
Trammell, B. and M. Kuehlewind, "The Wire Image of a Trammell, B. and M. Kuehlewind, "The Wire Image of a
Network Protocol", draft-iab-wire-image-01 (work in Network Protocol", draft-iab-wire-image-01 (work in
progress), November 2018. progress), November 2018.
[IKEV2IANA]
IANA, "Internet Key Exchange Version 2 (IKEv2)
Parameters",
<http://www.iana.org/assignments/ikev2-parameters/>.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981, DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>. <https://www.rfc-editor.org/info/rfc791>.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
DOI 10.17487/RFC1191, November 1990, DOI 10.17487/RFC1191, November 1990,
<https://www.rfc-editor.org/info/rfc1191>. <https://www.rfc-editor.org/info/rfc1191>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
skipping to change at page 19, line 29 skipping to change at page 19, line 29
Datagram Congestion Control Protocol (DCCP) Congestion Datagram Congestion Control Protocol (DCCP) Congestion
Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342,
DOI 10.17487/RFC4342, March 2006, DOI 10.17487/RFC4342, March 2006,
<https://www.rfc-editor.org/info/rfc4342>. <https://www.rfc-editor.org/info/rfc4342>.
[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP
Friendly Rate Control (TFRC): Protocol Specification", Friendly Rate Control (TFRC): Protocol Specification",
RFC 5348, DOI 10.17487/RFC5348, September 2008, RFC 5348, DOI 10.17487/RFC5348, September 2008,
<https://www.rfc-editor.org/info/rfc5348>. <https://www.rfc-editor.org/info/rfc5348>.
[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code
Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January
2014, <https://www.rfc-editor.org/info/rfc7120>.
[RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black,
"Encapsulating MPLS in UDP", RFC 7510, "Encapsulating MPLS in UDP", RFC 7510,
DOI 10.17487/RFC7510, April 2015, DOI 10.17487/RFC7510, April 2015,
<https://www.rfc-editor.org/info/rfc7510>. <https://www.rfc-editor.org/info/rfc7510>.
[RFC8084] Fairhurst, G., "Network Transport Circuit Breakers", [RFC8084] Fairhurst, G., "Network Transport Circuit Breakers",
BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017, BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017,
<https://www.rfc-editor.org/info/rfc8084>. <https://www.rfc-editor.org/info/rfc8084>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>. <https://www.rfc-editor.org/info/rfc8200>.
[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
"Path MTU Discovery for IP version 6", STD 87, RFC 8201, "Path MTU Discovery for IP version 6", STD 87, RFC 8201,
DOI 10.17487/RFC8201, July 2017, DOI 10.17487/RFC8201, July 2017,
<https://www.rfc-editor.org/info/rfc8201>. <https://www.rfc-editor.org/info/rfc8201>.
 End of changes. 56 change blocks. 
142 lines changed or deleted 154 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/