LabN Consulting, L.L.C.

dfedyk@labn.net

LabN Consulting, L.L.C.

chopps@chopps.org

This document describes a yang module for the management of IP Traffic Flow Security additions to IKEv2 and IPsec.

This document defines a YANG module for the management of the IP Traffic Flow Security (IP-TFS) extensions as defined in . IP-TFS provides enhancements to an IPsec tunnel Security Association to provide improved traffic confidentiality. Traffic confidentiality reduces the ability of traffic analysis to determine identity and correlate observable traffic patterns. IP-TFS offers efficiency when aggregating traffic in fixed size IPsec tunnel packets. The YANG data model in this document conforms to the Network Management Datastore Architecture defined in . The only actively published YANG modules for IPsec are found in . This document uses these models as a general IPsec model that can be augmented. The models in provide for an ike and an ikeless model.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in when, and only when, they appear in all capitals, as shown here.

This document defines configuration and operational parameters of IP traffic flow security (IP-TFS). IP-TFS, defined in , defines a security association for tunnel mode IPsec with characteristics that improve traffic confidentiality and reduce bandwidth efficiency loss. These documents assume familiarity with IP security concepts described in . IP-TFS uses tunnel mode to improve confidentiality by hiding inner packet identifiable information, packet size and packet timing. IP-TFS provides a general capability allowing aggregation of multiple packets in uniform size outer tunnel ipsec packets. It maintains the outer packet size by utilizing combinations of aggregating, padding and fragmentating inner packets to fll out the IPsec outer tunnel packet. Zero byte padding is used to fill the packet when no data is available to send. This document specifies an extensible configuration model for IP-TFS. This version utilizes the capabilities of IP-TFS to configure fixed size IP-TFS Packets that are transmitted at a constant rate. This model is structured to allow for different types of operation through future augmentation. IP-TFS YANG augments IPsec YANG model from . IP-TFS makes use of IPsec tunnel mode and adds a small number configuration items to tunnel mode IPsec. As defined in , any SA configured to use IP-TFS supports only IP-TFS packets i.e. no mixed IPsec modes. The behavior for IP-TFS is controlled by the source. The self-describing format of an IP-TFS packets allows a sending side to adjust the packet-size and timing independently from any receiver. Both directions are also independent, e.g. IP-TFS may be run only in one direction. This means that counters, which are created here for both directions may be 0 or not updated in the case of an SA that uses IP-TFS only in on direction. Cases where IP-TFS statistics are active for one direction: SA one direction - IP-TFS enabled SA both directions - IP-TFS only enabled in one direction Case where IP-TFS statistics are for both directions: SA both directions - IP-TFS enable for both directions The data model uses following constructs for configuration and management: o Configuration o Operational State This YANG module supports configuration of fixed size and fixed rate packets, and elements that may be augmented to support future configuration. The protocol specification , goes beyond this simple fixed mode of operation by defining a general format for any type of scheme. In this document the outer IPsec packets can be sent with fixed or variable size (without padding). The configuration allows the fixed packet size to be determined by the path MTU. The fixed packet size can also be configured if a value lower than the path MTU is desired. Other configuration items include: Congestion Control. A congestion control setting to allow IP-TFS to reduce the packet rate when congestion is detected. Fixed Rate configuration. The IP-TFS tunnel rate can be configured taking into account either layer 2 overhead or layer 3 overhead. Layer 3 overhead is the IP data rate and layer 2 overhead is the rate of bits on the link. The combination of packet size and rate determines the nominal maximum bandwidth and the transmission interval when fixed size packets are used. User packet Fragmentation Control. While fragmentation is recommended for improved efficiency, a configuration is provided if users wish to observe the effect no-fragmentation on their data flows. The YANG operational data allows the readout of the configured parameters as well as the per SA statistics and error counters for IP-TFS. Per SA IPsec packet statistics are provided as a feature and per SA IP-TFS specific statistics as another feature. Both sets of statistics augment the IPsec YANG models with counters that allow observation of IP-TFS packet efficiency. Draft has a mature set of IPsec YANG management objects. IP-TFS YANG augments: Yang catalog entry for ietf-i2nsf-ike@2020-10-30.yang Yang catalog entry for ietf-i2nsf-ikeless@20202-10-30.yang The Security Policy database entry and Security Association entry for an IPsec Tunnel can be augmented with IP-TFS.

The following is the YANG tree diagram () for the IP-TFS extensions.

The following is the YANG module for managing the IP-TFS extensions.

file "ietf-ipsecme-iptfs@2021-03-08.yang" module ietf-ipsecme-iptfs { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-ipsecme-iptfs"; prefix iptfs; import ietf-i2nsf-ike { prefix nsfike; } import ietf-i2nsf-ikeless { prefix nsfikels; } organization "IETF IPSECME Working Group (IPSECME)"; contact "WG Web: WG List: Author: Don Fedyk Author: Christian Hopps "; // RFC Ed.: replace XXXX with actual RFC number and // remove this note. description "This module defines the configuration and operational state for managing the IP Traffic Flow Security functionality [RFC XXXX]. Copyright (c) 2020 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX (https://tools.ietf.org/html/rfcXXXX); see the RFC itself for full legal notices."; revision 2021-03-08 { description "Initial Revision"; reference "RFC XXXX: IP Traffic Flow Security YANG Module"; } feature ipsec-stats { description "This feature indicates the device supports per SA IPsec statistics"; } feature iptfs-stats { description "This feature indicates the device supports per SA IP Traffic Flow Security statistics"; } /*--------------------*/ /* groupings */ /*--------------------*/ grouping ipsec-tx-stat-grouping { description "IPsec outbound statistics"; leaf tx-pkts { type uint64; config false; description "Outbound Packet count"; } leaf tx-octets { type uint64; config false; description "Outbound Packet bytes"; } leaf tx-drop-pkts { type uint64; config false; description "Outbound dropped packets count"; } } grouping ipsec-rx-stat-grouping { description "IPsec inbound statistics"; leaf rx-pkts { type uint64; config false; description "Inbound Packet count"; } leaf rx-octets { type uint64; config false; description "Inbound Packet bytes"; } leaf rx-drop-pkts { type uint64; config false; description "Inbound dropped packets count"; } } grouping iptfs-inner-tx-stat-grouping { description "IP-TFS outbound inner packet statistics"; leaf tx-pkts { type uint64; config false; description "Total number of IP-TFS inner packets sent. This count is whole packets only. A fragmented packet counts as one packet"; reference "draft-ietf-ipsecme-iptfs"; } leaf tx-octets { type uint64; config false; description "Total number of IP-TFS inner octets sent. This is inner packet octets only. Does not count padding."; reference "draft-ietf-ipsecme-iptfs"; } } grouping iptfs-outer-tx-stat-grouping { description "IP-TFS outbound inner packet statistics"; leaf tx-all-pad-pkts { type uint64; config false; description "Total number of transmitted IP-TFS packets that were all padding with no inner packet data."; reference "draft-ietf-ipsecme-iptfs section 2.2.3"; } leaf tx-all-pad-octets { type uint64; config false; description "Total number transmitted octets of padding added to IP-TFS packets with no inner packet data."; reference "draft-ietf-ipsecme-iptfs section 2.2.3"; } leaf tx-extra-pad-pkts { type uint64; config false; description "Total number of transmitted outer IP-TFS packets that included some padding."; reference "draft-ietf-ipsecme-iptfs section 2.2.3.1"; } leaf tx-extra-pad-octets { type uint64; config false; description "Total number of transmitted octets of padding added to outer IP-TFS packets with data."; reference "draft-ietf-ipsecme-iptfs section 2.2.3.1"; } } grouping iptfs-inner-rx-stat-grouping { description "IP-TFS inner packet inbound statistics"; leaf rx-pkts { type uint64; config false; description "Total number of IP-TFS inner packets received."; reference "draft-ietf-ipsecme-iptfs section 2.2"; } leaf rx-octets { type uint64; config false; description "Total number of IP-TFS inner octets received. Does not include padding or overhead"; reference "draft-ietf-ipsecme-iptfs section 2.2"; } leaf rx-incomplete-pkts { type uint64; config false; description "Total number of IP-TFS inner packets that were incomplete. Usually this is due to fragments not received. Also, this may be due to misordering or errors in received outer packets."; reference "draft-ietf-ipsecme-iptfs"; } } grouping iptfs-outer-rx-stat-grouping { description "IP-TFS outer packet inbound statistics"; leaf rx-all-pad-pkts { type uint64; config false; description "Total number of received IP-TFS packets that were all padding with no inner packet data."; reference "draft-ietf-ipsecme-iptfs section 2.2.3"; } leaf rx-all-pad-octets { type uint64; config false; description "Total number received octets of padding added to IP-TFS packets with no inner packet data."; reference "draft-ietf-ipsecme-iptfs section 2.2.3"; } leaf rx-extra-pad-pkts { type uint64; config false; description "Total number of received outer IP-TFS packets that included some padding."; reference "draft-ietf-ipsecme-iptfs section 2.2.3.1"; } leaf rx-extra-pad-octets { type uint64; config false; description "Total number of received octets of padding added to outer IP-TFS packets with data."; reference "draft-ietf-ipsecme-iptfs section 2.2.3.1"; } leaf rx-errored-pkts { type uint64; config false; description "Total number of IP-TFS outer packets dropped due to errors."; reference "draft-ietf-ipsecme-iptfs"; } leaf rx-missed-pkts { type uint64; config false; description "Total number of IP-TFS outer packets missing indicated by missing sequence number."; reference "draft-ietf-ipsecme-iptfs"; } } grouping iptfs-config { description "This is the grouping for iptfs configuration"; container traffic-flow-security { // config true; want this so we can refine? description "Configure the IPSec TFS in Security Association Database (SAD)"; leaf congestion-control { type boolean; default "true"; description "Congestion Control With the congestion controlled mode, IP-TFS adapts to network congestion by lowering the packet send rate to accommodate the congestion, as well as raising the rate when congestion subsides."; reference "draft-ietf-ipsecme-iptfs section 2.5.2"; } container packet-size { description "Packet size is either auto-discovered or manually configured."; leaf use-path-mtu-discovery { type boolean; default "true"; description "Utilize path mtu discovery to determine maximum IP-TFS packet size. If the packet size is explicitly configured, then it will only be adjusted downward if use-path-mtu-discovery is set."; reference "draft-ietf-ipsecme-iptfs section 4.2"; } leaf outer-packet-size { type uint16; description "The size of the outer encapsulating tunnel packet (i.e., the IP packet containing the ESP payload)."; reference "draft-ietf-ipsecme-iptfs section 4.2"; } } choice tunnel-rate { description "TFS bit rate may be specified at layer 2 wire rate or layer 3 packet rate"; leaf l2-fixed-rate { type uint64; description "Target bandwidth/bit rate in bps for iptfs tunnel. This fixed rate is the nominal timing for the fixed size packet. If congestion control is enabled the rate may be adjusted down (or up if unset)."; reference "draft-ietf-ipsecme-iptfs section 4.1"; } leaf l3-fixed-rate { type uint64; description "Target bandwidth/bit rate in bps for iptfs tunnel. This fixed rate is the nominal timing for the fixed size packet. If congestion control is enabled the rate may be adjusted down (or up if unset)."; reference "draft-ietf-ipsecme-iptfs section 4.1"; } } leaf dont-fragment { type boolean; default "false"; description "Disable packet fragmentation across consecutive iptfs tunnel packets"; reference "draft-ietf-ipsecme-iptfs section 2.2.4 and 6.4.1"; } leaf max-aggregation-time { type decimal64 { fraction-digits 6; } units "milliseconds"; description "Maximum Aggregation Time in Milliseconds or fractional milliseconds down to 1 nanosecond"; } } } /* * IP-TFS ike configuration */ augment "/nsfike:ipsec-ike/nsfike:conn-entry/nsfike:spd/" + "nsfike:spd-entry/" + "nsfike:ipsec-policy-config/" + "nsfike:processing-info/" + "nsfike:ipsec-sa-cfg" { description "IP-TFS configuration for this policy."; uses iptfs-config; } augment "/nsfike:ipsec-ike/nsfike:conn-entry/" + "nsfike:child-sa-info" { description "IP-TFS configured on this SA."; uses iptfs-config { refine "traffic-flow-security" { config false; } } } /* * IP-TFS ikeless configuration */ augment "/nsfikels:ipsec-ikeless/nsfikels:spd/" + "nsfikels:spd-entry/" + "nsfikels:ipsec-policy-config/" + "nsfikels:processing-info/" + "nsfikels:ipsec-sa-cfg" { description "IP-TFS configuration for this policy."; uses iptfs-config; } augment "/nsfikels:ipsec-ikeless/nsfikels:sad/" + "nsfikels:sad-entry" { description "IP-TFS configured on this SA."; uses iptfs-config { refine "traffic-flow-security" { config false; } } } /* * packet counters */ augment "/nsfike:ipsec-ike/nsfike:conn-entry/" + "nsfike:child-sa-info" { description "Per SA Counters"; container ipsec-stats { if-feature "ipsec-stats"; config false; description "IPsec per SA packet counters."; uses ipsec-tx-stat-grouping { //when "direction = 'outbound'"; } uses ipsec-rx-stat-grouping { //when "direction = 'inbound'"; } } container iptfs-inner-pkt-stats { if-feature "iptfs-stats"; config false; description "IPTFS per SA inner packet counters."; uses iptfs-inner-tx-stat-grouping { //when "direction = 'outbound'"; } uses iptfs-inner-rx-stat-grouping { //when "direction = 'inbound'"; } } container iptfs-outer-pkt-stats { if-feature "iptfs-stats"; config false; description "IPTFS per SA outer packets counters."; uses iptfs-outer-tx-stat-grouping { //when "direction = 'outbound'"; } uses iptfs-outer-rx-stat-grouping { //when "direction = 'inbound'"; } } } /* * packet counters */ augment "/nsfikels:ipsec-ikeless/nsfikels:sad/" + "nsfikels:sad-entry" { description "Per SA Counters"; container ipsec-stats { if-feature "ipsec-stats"; description "IPsec per SA packet counters."; uses ipsec-tx-stat-grouping { //when "direction = 'outbound'"; } uses ipsec-rx-stat-grouping { //when "direction = 'inbound'"; } } container iptfs-inner-pkt-stats { if-feature "iptfs-stats"; config false; description "IPTFS per SA inner packet counters."; uses iptfs-inner-tx-stat-grouping { //when "direction = 'outbound'"; } uses iptfs-inner-rx-stat-grouping { //when "direction = 'inbound'"; } } container iptfs-outer-pkt-stats { if-feature "iptfs-stats"; config false; description "IPTFS per SA outer packets counters."; uses iptfs-outer-tx-stat-grouping { //when "direction = 'outbound'"; } uses iptfs-outer-rx-stat-grouping { //when "direction = 'inbound'"; } } } } ]]>

This document registers a URI in the "IETF XML Registry" . Following the format in , the following registration has been made: urn:ietf:params:xml:ns:yang:ietf-ipsecme-iptfs The IESG. N/A; the requested URI is an XML namespace.

This document registers one YANG module in the "YANG Module Names" registry . Following the format in , the following registration has been made: ietf-ipsecme-iptfs urn:ietf:params:xml:ns:yang:ietf-ipsecme-iptfs iptfs RFC XXXX (RFC Ed.: replace XXXX with actual RFC number and remove this note.)

The YANG module specified in this document defines a schema for data that is designed to be accessed via network management protocols such as NETCONF or RESTCONF . The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) . The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS . The Network Configuration Access Control Model (NACM) provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. The YANG module defined in this document can enable, disable and modify the behavior of IP traffic flow security, for the implications regarding these types of changes consult the which defines the functionality.

The authors would like to thank Eric Kinzie for his feedback on the YANG model.

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document describes an updated version of the "Security Architecture for IP", which is designed to provide security services for traffic at the IP layer. This document obsoletes RFC 2401 (November 1998). [STANDARDS-TRACK] YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK] YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF). RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Datastores are a fundamental concept binding the data models written in the YANG data modeling language to network management protocols such as the Network Configuration Protocol (NETCONF) and RESTCONF. This document defines an architectural framework for datastores based on the experience gained with the initial simpler model, addressing requirements that were not well supported in the initial model. This document updates RFC 7950. 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. This document describes how to provide IPsec-based flow protection (integrity and confidentiality) by means of an Interface to Network Security Function (I2NSF) controller. It considers two main well- known scenarios in IPsec: (i) gateway-to-gateway and (ii) host-to- host. The service described in this document allows the configuration and monitoring of IPsec Security Associations (SAs) from a I2NSF Controller to one or several flow-based Network Security Functions (NSFs) that rely on IPsec to protect data traffic. The document focuses on the I2NSF NSF-facing interface by providing YANG data models for configuring the IPsec databases (SPD, SAD, PAD) and IKEv2. This allows IPsec SA establishment with minimal intervention by the network administrator. It does not define any new protocol. This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas. The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK] This document describes a method for invoking and running the Network Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem. This document obsoletes RFC 4742. [STANDARDS-TRACK] This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF). This document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language. The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model.This document obsoletes RFC 6536. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.

The following examples show configuration and operational data for the ikeless case in xml and ike case in json. Also, the operational statistics for the ikeless case are shown using xml.

This example illustrates configuration for IP-TFS in the ikeless case. Note that since this augments the ipsec ikeless schema only minimal ikeless configuration to satisfy the schema has been populated.

protect-policy-1 outbound 1.1.1.1/32 2.2.2.2/32 protect true true 1000000000 0.1 ]]>

This example illustrates operational data for IP-TFS in the ikeless case. Note that since this augments the ipsec ikeless schema only minimal ikeless configuration to satisfy the schema has been populated.

sad-1 1 1.1.1.1/32 2.2.2.2/32 true true 1000000000 0.100 ]]>

This example illustrates config data for IP-TFS in the ike case. Note that since this augments the ipsec ike schema only minimal ike configuration to satisfy the schema has been populated.

This example illustrates operational data for IP-TFS in the ike case. Note that since this augments the ipsec ike tree only minimal ike configuration to satisfy the schema has been populated.

This example shows the json formated statistics for IP-TFS. Note a unidirectional IP-TFS transmit side is illustrated, with arbitray numbers for transmit.