A YANG Data Model for IP Traffic Flow SecurityLabN Consulting, L.L.C.dfedyk@labn.netLabN Consulting, L.L.C.chopps@chopps.orgThis 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 (NMDA) defined in .The published YANG modules for IPsec are defined in
. This document
uses these models as a general IPsec model that is augmented for IP-TFS.
The models in provide for both
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 fragmenting 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 enabledSA both directions - IP-TFS only enabled in one directionCase where IP-TFS statistics are for both directions:SA both directions - IP-TFS enable for both directionsThe IP-TFS model support IP-TFS configuration and operational data.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.RFC has a set of IPsec YANG
management objects. IP-TFS YANG augments the IKE and
the IKELESS models. In these models 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.
The model contains references to and
.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-ipsec-iptfsThe 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-ipsec-iptfsurn:ietf:params:xml:ns:yang:ietf-ipsec-iptfsiptfsRFC 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.IP-TFS hides the traffic flows through the network,
anywhere that access YANG statistics is enabled needs to be
protected from third party observation.The authors would like to thank Eric Kinzie, Juergen Schoenwaelder, Lou Berger and Tero Kivinen
for their feedback and review on the YANG model.Key words for use in RFCs to Indicate Requirement LevelsIn 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.Security Architecture for the Internet ProtocolThis 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 - A Data Modeling Language for the Network Configuration Protocol (NETCONF)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]The YANG 1.1 Data Modeling LanguageYANG 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).Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 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.Network Management Datastore Architecture (NMDA)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.IP-TFS: Aggregation and Fragmentation Mode for ESP and its Use for IP Traffic Flow SecurityLabN Consulting, L.L.C. This document describes a mechanism for aggregation and fragmentation
of IP packets when they are being encapsulated in ESP payload. This
new payload type can be used for various purposes such as decreasing
encapsulation overhead for small IP packets; however, the focus in
this document is to enhance IPsec traffic flow security (IP-TFS) by
adding Traffic Flow Confidentiality (TFC) to encrypted IP
encapsulated traffic. TFC is provided by obscuring the size and
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.
A YANG Data Model for IPsec Flow Protection Based on Software-Defined Networking (SDN)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: gateway-to-gateway and host-to-host. The service described in this document allows the configuration and monitoring of IPsec Security Associations (IPsec SAs) from an I2NSF Controller to one or several flow-based Network Security Functions (NSFs) that rely on IPsec to protect data traffic. This document focuses on the I2NSF NSF-Facing Interface by providing YANG data models for configuring the IPsec databases, namely Security Policy Database (SPD), Security Association Database (SAD), Peer Authorization Database (PAD), and Internet Key Exchange Version 2 (IKEv2). This allows IPsec SA establishment with minimal intervention by the network administrator. This document defines three YANG modules, but it does not define any new protocol.The IETF XML RegistryThis 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.Network Configuration Protocol (NETCONF)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]Using the NETCONF Protocol over Secure Shell (SSH)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]RESTCONF ProtocolThis 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).YANG Tree DiagramsThis 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.Network Configuration Access Control ModelThe 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.The Transport Layer Security (TLS) Protocol Version 1.3This 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.TCP Friendly Rate Control (TFRC): Protocol SpecificationThis document specifies TCP Friendly Rate Control (TFRC). TFRC is a congestion control mechanism for unicast flows operating in a best-effort Internet environment. It is reasonably fair when competing for bandwidth with TCP flows, but has a much lower variation of throughput over time compared with TCP, making it more suitable for applications such as streaming media where a relatively smooth sending rate is of importance.This document obsoletes RFC 3448 and updates RFC 4342. [STANDARDS-TRACK]The following examples show configuration and operational data for the ikeless and ike cases
using xml and json. Also, the operational statistics for the ikeless case
is illustrated.This example illustrates configuration for IP-TFS in the ikeless case.
Note that since this augments the ipsec ikeless schema only minimal a ikeless configuration
to satisfy the schema has been populated.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.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 arbitrary numbers for transmit.<tfs:traffic-flow-security>
<tfs:reorder-window-size>300</tfs:reorder-window-size>