--- 1/draft-ietf-ipsecme-iptfs-00.txt 2020-03-02 06:13:14.069379149 -0800 +++ 2/draft-ietf-ipsecme-iptfs-01.txt 2020-03-02 06:13:14.125380560 -0800 @@ -1,18 +1,18 @@ Network Working Group C. Hopps Internet-Draft LabN Consulting, L.L.C. -Intended status: Standards Track December 16, 2019 -Expires: June 18, 2020 +Intended status: Standards Track March 2, 2020 +Expires: September 3, 2020 IP Traffic Flow Security - draft-ietf-ipsecme-iptfs-00 + draft-ietf-ipsecme-iptfs-01 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. @@ -24,83 +24,81 @@ 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 18, 2020. + This Internet-Draft will expire on September 3, 2020. 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. 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 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology & Concepts . . . . . . . . . . . . . . . . . 3 2. The IP-TFS Tunnel . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Tunnel Content . . . . . . . . . . . . . . . . . . . . . 4 2.2. IPTFS_PROTOCOL Payload Content . . . . . . . . . . . . . 4 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.4. IP Header Value Mapping . . . . . . . . . . . . . . . 6 2.3. Exclusive SA Use . . . . . . . . . . . . . . . . . . . . 7 2.4. Initiating IP-TFS Operation On The SA. . . . . . . . . . 7 2.5. Modes of Operation . . . . . . . . . . . . . . . . . . . 7 2.5.1. Non-Congestion Controlled Mode . . . . . . . . . . . 7 2.5.2. Congestion Controlled Mode . . . . . . . . . . . . . 8 3. Congestion Information . . . . . . . . . . . . . . . . . . . 9 3.1. ECN Support . . . . . . . . . . . . . . . . . . . . . . . 10 4. Configuration . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2. Fixed Packet Size . . . . . . . . . . . . . . . . . . . . 10 4.3. Congestion Control . . . . . . . . . . . . . . . . . . . 11 5. IKEv2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 - 5.1. TFS Type Transform Type . . . . . . . . . . . . . . . . . 11 - 5.2. IPTFS_REQUIREMENTS Status Notification . . . . . . . . . 11 - 6. Packet and Data Formats . . . . . . . . . . . . . . . . . . . 12 - 6.1. ESP IP-TFS Payload . . . . . . . . . . . . . . . . . . . 12 + 5.1. USE_TFS Notification Message . . . . . . . . . . . . . . 11 + 6. Packet and Data Formats . . . . . . . . . . . . . . . . . . . 11 + 6.1. IP-TFS Payload . . . . . . . . . . . . . . . . . . . . . 11 6.1.1. Non-Congestion Control IPTFS_PROTOCOL Payload Format 12 6.1.2. Congestion Control IPTFS_PROTOCOL Payload Format . . 13 6.1.3. Data Blocks . . . . . . . . . . . . . . . . . . . . . 14 + 6.1.4. IKEv2 USE_IPTFS Notification Message . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7.1. IPTFS_PROTOCOL Type . . . . . . . . . . . . . . . . . . . 16 - 7.2. IKEv2 Transform Type TFS Type . . . . . . . . . . . . . . 16 - 7.3. TFS Type Transform IDs Registry . . . . . . . . . . . . . 17 - 7.4. IPTFS_REQUIREMENTS Notify Message Status Type . . . . . . 17 + 7.2. IPTFS_PROTOCOL Sub-Type Registry . . . . . . . . . . . . 16 + 7.3. USE_IPTFS Notify Message Status Type . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 9.1. Normative References . . . . . . . . . . . . . . . . . . 17 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 9.1. Normative 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 C. Comparisons of IP-TFS . . . . . . . . . . . . . . . 21 C.1. Comparing Overhead . . . . . . . . . . . . . . . . . . . 21 C.1.1. IP-TFS Overhead . . . . . . . . . . . . . . . . . . . 21 C.1.2. ESP with Padding Overhead . . . . . . . . . . . . . . 21 - C.2. Overhead Comparison . . . . . . . . . . . . . . . . . . . 22 C.3. Comparing Available Bandwidth . . . . . . . . . . . . . . 23 C.3.1. Ethernet . . . . . . . . . . . . . . . . . . . . . . 23 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 25 Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 25 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25 1. Introduction Traffic Analysis ([RFC4301], [AppCrypt]) is the act of extracting @@ -153,48 +151,48 @@ The fixed packet size may either be specified manually or can be determined through the use of Path MTU discovery [RFC1191] and [RFC8201]. Given the encapsulating packet size and the requested tunnel bandwidth, the corresponding packet send rate can be calculated. The packet send rate is the requested bandwidth divided by the payload size of the encapsulating packet. - The egress of the IP-TFS tunnel MUST allow for, and expect the - ingress (sending) side of the IP-TFS tunnel to vary the size and rate - of sent encapsulating packets, unless constrained by other policy. + The egress of the IP-TFS tunnel MUST allow for and expect the ingress + (sending) side of the IP-TFS tunnel to vary the size and rate of sent + encapsulating packets, unless constrained by other policy. 2.1. Tunnel Content As previously mentioned, one issue with the TFC padding solution in [RFC4303] is the large amount of wasted bandwidth as only one IP packet can be sent per encapsulating packet. In order to maximize bandwidth IP-TFS breaks this one-to-one association. With IP-TFS we aggregate as well as fragment the inner IP traffic flow into fixed-sized encapsulating IPsec tunnel packets. We only 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 disabled by the receiver. 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). 2.2. IPTFS_PROTOCOL Payload Content - The IPTFS_PROTOCOL ESP payload is comprised a 4 or 16 octet header - followed by either a partial, a full or multiple partial or full data - blocks. The following diagram illustrates the IPTFS_PROTOCOL ESP - payload within the ESP packet. See Section 6.1 for the exact formats - of the IPTFS_PROTOCOL payload. + The IPTFS_PROTOCOL payload content defined in this document is + comprised of a 4 or 16 octet header followed by either a partial, a + full or multiple partial or full data blocks. The following diagram + illustrates this IPTFS_PROTOCOL payload within the ESP packet. See + Section 6.1 for the exact formats of the IPTFS_PROTOCOL payload. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Outer Encapsulating Header ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ESP Header... . +---------------------------------------------------------------+ | ... : BlockOffset | +---------------------------------------------------------------+ : [Optional Congestion Info] : +---------------------------------------------------------------+ @@ -235,32 +233,33 @@ Figure 2: Layout of IP-TFS data block 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 with the IPv4/IPv6 version field values so that no per-data block type overhead is required to encapsulate an IP packet. Likewise, the length of the data block is extracted from the encapsulated IPv4 or 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 - the end of an encapsulating packet. Even when the start of a data - block occurs near the end of a encapsulating packet such that there - is no room for the length field of the encapsulated header to be - included in the current encapsulating packet, the fact that the - length comes at a known location and is guaranteed to be present is - enough to fetch the length field from the subsequent encapsulating - packet payload. Only when there is no data to encapsulate is padding - required, and then an explicit "Pad Data Block" would be used to - identify the padding. + It's worth noting that since a data block type is identified by its + first octet there is never a need for an implicit pad at the end of + an encapsulating packet. Even when the start of a data block occurs + near the end of a encapsulating packet such that there is no room for + the length field of the encapsulated header to be included in the + current encapsulating packet, the fact that the length comes at a + known location and is guaranteed to be present is enough to fetch the + length field from the subsequent encapsulating packet payload. Only + when there is no data to encapsulated is end padding required, and + then an explicit "Pad Data Block" would be used to identify the + padding. 2.2.3. Empty Payload In order to support reporting of congestion control information (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 payload length is equal to the IP-TFS header length). This special payload is called an empty payload. 2.2.4. IP Header Value Mapping @@ -471,103 +470,90 @@ Path MTU discovery (see [RFC1191] and [RFC8201]). No standardized configuration method is required. 4.3. Congestion Control Congestion control is a local configuration option. No standardized configuration method is required. 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) - is used to negotiate (as defined in [RFC7296]) the possible operation - of IP-TFS on a child SA pair. This document defines 3 "TFS Type" - Transform IDs for the new "TFS Type" Transform Type: None (0), - 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. + When using IKEv2, a new "USE_IPTFS" Notification Message is used to + enable operation of IP-TFS on a child SA pair. The method used is + similar to how USE_TRANSPORT_MODE is negotiated, as described in + [RFC7296]. - Additional "TFS Type" Transform IDs may be defined in the future, and - so readers are referred to [IKEV2IANA] for the most up to date list. + To request IP-TFS operation on the Child SA pair, the initiator + 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 - Type IPTFS_REQUIREMENTS (TBD3) MAY be sent by the initiator and/or - the responder to further refine what will be supported. This - notification is sent during IKE_AUTH and new CREATE_CHILD_SA - exchanges; however, it MUST NOT be sent, and MUST be ignored, during - a CREATE_CHILD_SA rekeying exchange as the requirements are not - allowed to change during rekeying. + The USE_IPTFS 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 IP-TFS mode (either by + not responding with the USE_IPTFS notification, or in the case of the + initiator, by deleting the child SA if the now established non-IP-TFS + operation is unacceptable). - The IPTFS_REQUIREMENTS notification contains a 1 octet payload of - flags that specify any extra requirements from the sender of the - 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. + The notification type and payload flag values are defined in + Section 6.1.4. - +-+-+-+-+-+-+-+-+ - |0|0|0|0|0|0|0|D| - +-+-+-+-+-+-+-+-+ +6. Packet and Data Formats - 0: - MUST be zero on send and MUST be ignored on receive. +6.1. IP-TFS Payload - 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 IPTFS_REQUIREMENTS notification. + An IP-TFS payload is identified by the IP protocol number + IPTFS_PROTOCOL (TBD1). The first octet of this payload indicates the + format of the remaining payload data. -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 - IPTFS_PROTOCOL (TBD1). This payload begins with a fixed 4 or 16 - octet header followed by a variable amount of "DataBlocks" data. The - exact payload format and fields are defined in the following - sections. + This specification defines 2 payload sub-types. These payload + formats are defined in the following sections. 6.1.1. Non-Congestion Control IPTFS_PROTOCOL Payload Format The non-congestion control IPTFS_PROTOCOL payload is comprised of a 4 octet header followed by a variable amount of "DataBlocks" data as shown below. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |V|C| Reserved | BlockOffset | + | Sub-Type (0) | Reserved | BlockOffset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DataBlocks ... +-+-+-+-+-+-+-+-+-+-+- - V: - A 1 bit version field that MUST be set to zero. If received as - one the packet MUST be dropped. - - C: - A 1 bit value that MUST be set to 0 to indicate no congestion - control information is present. + Sub-type: + An octet indicating the payload format. For this non-congestion + control format, the value is 0. Reserved: - A 14 bit field set to 0 and ignored on receipt. + An octet set to 0 on generation, and ignored on receipt. BlockOffset: A 16 bit unsigned integer counting the number of octets of "DataBlocks" data before the start of a new data block. "BlockOffset" can count past the end of the "DataBlocks" data in which case all the "DataBlocks" data belongs to the previous data block being re-assembled. If the "BlockOffset" extends into subsequent packets it continues to only count subsequent "DataBlocks" data (i.e., it does not count subsequent packets non-"DataBlocks" octets). @@ -579,50 +565,44 @@ 6.1.2. Congestion Control IPTFS_PROTOCOL Payload Format The congestion control IPTFS_PROTOCOL payload is comprised of a 16 octet header followed by a variable amount of "DataBlocks" data as shown below. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |V|C|E| Reserved | BlockOffset | + | Sub-type (1) | Reserved |E| BlockOffset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTT | Delay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LossEventRate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LastSeqNum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DataBlocks ... +-+-+-+-+-+-+-+-+-+-+- - V: - A 1 bit version field that MUST be set to zero. If received as - one the packet MUST be dropped. + Sub-type: + An octet indicating the payload format. For this congestion + control format, the value is 1. - C: - A 1 bit value that MUST be set to 1 which indicates the presence - of the congestion information header fields "RTT", "Delay", - "LossEventRate" and "LastSeqNum". + Reserved: + A 7 bit field set to 0 on generation, and ignored on receipt. E: A 1 bit value if set indicates that Congestion Experienced (CE) ECN bits were received and used in deriving the reported "LossEventRate". - Reserved: - A 13 bit field set to 0 and ignored on receipt. - BlockOffset: - The same value as the non-congestion controlled payload format value. RTT: A 16 bit value specifying the sender's current round-trip time estimate in milliseconds. The value MAY be zero prior to the sender having calculated a round-trip time estimate. The value SHOULD be set to zero on non-IP-TFS enabled SAs. Delay: @@ -674,45 +655,47 @@ These values are the actual values within the encapsulated IPv4 header. In other words, the start of this data block is the start of the encapsulated IP packet. Type: A 4 bit value of 0x4 indicating IPv4 (i.e., first nibble of the IPv4 packet). 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 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 header. In other words, the start of this data block is the start of the encapsulated IP packet. Type: A 4 bit value of 0x6 indicating IPv6 (i.e., first nibble of the IPv6 packet). - TotalLength: - The 16 bit unsigned integer length field of the inner IPv6 inner - packet. + PayloadLength: + The 16 bit unsigned integer "Payload Length" field of the inner + IPv6 inner packet. 6.1.3.3. Pad Data Block + 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x0 | Padding ... +-+-+-+-+-+-+-+-+-+-+- Type: A 4 bit value of 0x0 indicating a padding data block. Padding: @@ -711,77 +694,103 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x0 | Padding ... +-+-+-+-+-+-+-+-+-+-+- Type: A 4 bit value of 0x0 indicating a padding data block. Padding: 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.1. IPTFS_PROTOCOL Type This document requests a protocol number IPTFS_PROTOCOL be allocated by IANA from "Assigned Internet Protocol Numbers" registry for - identifying the IP-TFS ESP payload format. + identifying the IP-TFS payload. Type: TBD1 Description: - IP-TFS ESP payload format. + An IP-TFS payload. Reference: 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 - allocated by IANA from the "Transform Type Values" registry. + This document requests IANA create a registry called "IPTFS_PROTOCOL + Sub-Type Registry" under "IPTFS_PROTOCOL Parameters" IANA registries. + The registration policy for this registry is "Standards Action" + ([RFC8126] and [RFC7120]). - Type: - TBD2 + Name: + IPTFS_PROTOCOL Sub-Type Registry Description: - TFS Type - - Used In: - (optional in ESP) + IPTFS_PROTOCOL Payload Formats. Reference: This document -7.3. TFS Type Transform IDs Registry - - 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: + This initial content for this registry is as follows: - Number Name Reference - ---------------------------------------- - 0 NONE This document - 1 TFS_IPTFS_CC This document - 2 TFS_IPTFS_NOCC This document - 3-65535 Reserved This document + Sub-Type Name Reference + -------------------------------------------------------- + 0 Non-Congestion Control Format This document + 1 Congestion Control Format This document + 3-255 Reserved -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 - from the "IKEv2 Notify Message Types - Status Types" registry. + This document requests a status type USE_IPTFS be allocated from the + "IKEv2 Notify Message Types - Status Types" registry. Value: - TBD3 + TBD2 Name: - IPTFS_REQUIREMENTS + USE_IPTFS Reference: This document 8. Security Considerations This document describes a mechanism to add Traffic Flow Confidentiality to IP traffic. Use of this mechanism is expected to increase the security of the traffic being transported. Other than the additional security afforded by using this mechanism, IP-TFS @@ -819,25 +828,20 @@ [AppCrypt] Schneier, B., "Applied Cryptography: Protocols, Algorithms, and Source Code in C", 11 2017. [I-D.iab-wire-image] Trammell, B. and M. Kuehlewind, "The Wire Image of a Network Protocol", draft-iab-wire-image-01 (work in progress), November 2018. - [IKEV2IANA] - IANA, "Internet Key Exchange Version 2 (IKEv2) - Parameters", - . - [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, . [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, DOI 10.17487/RFC1191, November 1990, . [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS @@ -862,29 +866,38 @@ Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, DOI 10.17487/RFC4342, March 2006, . [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 5348, DOI 10.17487/RFC5348, September 2008, . + [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code + Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January + 2014, . + [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, "Encapsulating MPLS in UDP", RFC 7510, DOI 10.17487/RFC7510, April 2015, . [RFC8084] Fairhurst, G., "Network Transport Circuit Breakers", BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017, . + [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, + . + [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., "Path MTU Discovery for IP version 6", STD 87, RFC 8201, DOI 10.17487/RFC8201, July 2017, .