rfc9348.original.xml   rfc9348.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>
<?rfc toc="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" category="std"
<?rfc compact="no"?> number="9348" docName="draft-ietf-ipsecme-yang-iptfs-11" submissionType="IETF"
<?rfc subcompact="no"?> consensus="true" obsoletes="" updates="" xml:lang="en" tocInclude="true" symRefs
<?rfc symrefs="yes" ?> ="true" sortRefs="true" version="3">
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no"?>
<?rfc strict="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" category="std"
docName="draft-ietf-ipsecme-yang-iptfs-11" submissionType="IETF" obsoletes="" u
pdates="" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version
="3">
<!-- xml2rfc v2v3 conversion 3.14.0 --> <!-- xml2rfc v2v3 conversion 3.14.0 -->
<front> <front>
<title abbrev="A YANG Data Model for IP-TFS">A YANG Data Model for IP Traffi c Flow Security</title> <title abbrev="A YANG Data Model for IP-TFS">A YANG Data Model for IP Traffi c Flow Security</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-ipsecme-yang-iptfs-11"/> <seriesInfo name="RFC" value="9348"/>
<author initials="D." surname="Fedyk" fullname="Don Fedyk"> <author initials="D." surname="Fedyk" fullname="Don Fedyk">
<organization>LabN Consulting, L.L.C.</organization> <organization>LabN Consulting, L.L.C.</organization>
<address> <address>
<email>dfedyk@labn.net</email> <email>dfedyk@labn.net</email>
</address> </address>
</author> </author>
<author initials="C." surname="Hopps" fullname="Christian Hopps"> <author initials="C." surname="Hopps" fullname="Christian Hopps">
<organization>LabN Consulting, L.L.C.</organization> <organization>LabN Consulting, L.L.C.</organization>
<address> <address>
<email>chopps@chopps.org</email> <email>chopps@chopps.org</email>
</address> </address>
</author> </author>
<date/> <date year="2023" month="January"/>
<abstract> <abstract>
<t>This document describes a YANG module for the management of IP <t>This document describes a YANG module for the management of IP
Traffic Flow Security additions to IKEv2 and IPsec.</t> Traffic Flow Security (IP-TFS) additions to Internet Key Exchange Protocol versi on 2 (IKEv2) and IPsec.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Introduction</name> <name>Introduction</name>
<t>This document defines a YANG module <xref target="RFC7950" format="defa ult"/> for the management of the IP <t>This document defines a YANG module <xref target="RFC7950" format="defa ult"/> for the management of the IP
Traffic Flow Security (IP-TFS) extensions as defined in Traffic Flow Security (IP-TFS) extensions defined in
<xref target="I-D.ietf-ipsecme-iptfs" format="default"/>. IP-TFS provides enhan <xref target="RFC9347" format="default"/>. IP-TFS provides enhancements to an I
cements to an IPsec tunnel Psec tunnel
Security Association to provide improved traffic confidentiality. Traffic Security Association (SA) to provide improved traffic confidentiality. Traffic
confidentiality reduces the ability of traffic analysis to determine identity confidentiality reduces the ability of traffic analysis to determine identity
and correlate observable traffic patterns. IP-TFS offers efficiency when and correlate observable traffic patterns. IP-TFS offers efficiency when
aggregating traffic in fixed size IPsec tunnel packets.</t> aggregating traffic in fixed-size IPsec tunnel packets.</t>
<t>The YANG data model in this document conforms to the Network <t>The YANG data model in this document conforms to the Network
Management Datastore Architecture (NMDA) defined in <xref target="RFC8342" forma t="default"/>.</t> Management Datastore Architecture (NMDA) defined in <xref target="RFC8342" forma t="default"/>.</t>
<t>The published YANG modules for IPsec are defined in <t>The published YANG modules for IPsec are defined in
<xref target="RFC9061" format="default"/>. This document <xref target="RFC9061" format="default"/>. This document
uses these models as a general IPsec model that is augmented for IP-TFS. uses these models as a general IPsec model that is augmented for IP-TFS.
The models in <xref target="RFC9061" format="default"/> provide for both The models in <xref target="RFC9061" format="default"/> provide for both
an IKE and an IKELESS model.</t> an IKE and an IKE-less model.</t>
<!-- <section numbered="true" toc="default"> </section>
<name>Terminology &amp; Concepts</name>
<t>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
<xref target="RFC2119" format="default"/> <xref target="RFC8174" format="default
"/> when, and only when, they appear in all capitals,
as shown here.</t>
</section> -->
</section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Overview</name> <name>Overview</name>
<t>This document defines configuration and operational parameters of IP tr <t>This document defines configuration and operational parameters of IP Tr
affic affic
flow security (IP-TFS). IP-TFS, defined in <xref target="I-D.ietf-ipsecme-iptfs Flow Security (IP-TFS). IP-TFS, defined in <xref target="RFC9347" format="defau
" format="default"/>, lt"/>,
defines a security association for tunnel mode IPsec with characteristics defines a security association for tunnel mode IPsec with characteristics
that improve traffic confidentiality and reduce bandwidth efficiency loss. that improve traffic confidentiality and reduce bandwidth efficiency loss.
These documents assume familiarity with IP security concepts described These documents assume familiarity with the IPsec concepts described
in <xref target="RFC4301" format="default"/>.</t> in <xref target="RFC4301" format="default"/>.</t>
<t>IP-TFS uses tunnel mode to improve confidentiality by hiding inner pack et <t>IP-TFS uses tunnel mode to improve confidentiality by hiding inner pack et
identifiable information, packet size and packet timing. IP-TFS provides a identifiable information, packet size, and packet timing. IP-TFS provides a
general capability allowing aggregation of multiple packets in uniform general capability allowing aggregation of multiple packets in uniform-size oute
size outer tunnel IPsec packets. It maintains the outer packet size r tunnel IPsec packets. It maintains the outer packet size
by utilizing combinations of aggregating, padding and fragmenting inner by utilizing combinations of aggregating, padding, and fragmenting inner
packets to fill out the IPsec outer tunnel packet. packets to fill out the IPsec outer tunnel packet.
Zero byte padding is used to fill the packet when no data is available to send.< /t> Padding is used to fill the packet when no data is available to send.</t>
<t>This document specifies an extensible configuration model for IP-TFS. This <t>This document specifies an extensible configuration model for IP-TFS. This
version utilizes the capabilities of IP-TFS to configure fixed size IP-TFS 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 packets that are transmitted at a constant rate. This model is structured to
allow for different types of operation through future augmentation.</t> allow for different types of operation through future augmentation.</t>
<t>The IP-TFS YANG module augments IPsec YANG model from <t>The IP-TFS YANG module augments the IPsec YANG module from
<xref target="RFC9061" format="default"/>. IP-TFS makes use of IPsec tunnel <xref target="RFC9061" format="default"/>. IP-TFS makes use of IPsec tunnel
mode and adds a small number configuration items to tunnel mode IPsec. As mode and adds a small number of configuration items to IPsec tunnel mode. As
defined in <xref target="I-D.ietf-ipsecme-iptfs" format="default"/>, any SA conf defined in <xref target="RFC9347" format="default"/>, any SA configured to use I
igured to use IP-TFS supports P-TFS supports
only IP-TFS packets i.e. no mixed IPsec modes.</t> only IP-TFS packets, i.e., no mixed IPsec modes.</t>
<t>The behavior for IP-TFS is controlled by the source. <t>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 self-describing format of an IP-TFS packet allows a sending side to adjust
the packet-size and timing independently from any receiver. Both directions 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. 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 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.< /t> be 0 or not updated in the case of an SA that uses IP-TFS only in on direction.< /t>
<t>Cases where IP-TFS statistics are active for one direction:</t> <t>Cases where IP-TFS statistics are active for one direction:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>SA one direction - IP-TFS enabled</li> <li>SA one direction - IP-TFS enabled</li>
<li>SA both directions - IP-TFS only enabled in one direction</li> <li>SA both directions - IP-TFS only enabled in one direction</li>
</ul> </ul>
<t>Case where IP-TFS statistics are for both directions:</t> <t>Case where IP-TFS statistics are active for both directions:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>SA both directions - IP-TFS enable for both directions</li> <li>SA both directions - IP-TFS enable for both directions</li>
</ul> </ul>
<t>The IP-TFS model support IP-TFS configuration and operational data.</t> <t>The IP-TFS model supports IP-TFS configuration and operational data.</t
<t>This YANG module supports configuration of fixed size and fixed rate pa >
ckets, <t>This YANG module supports configuration of fixed-size and fixed-rate pa
and elements that may be augmented to support future configuration. The ckets,
protocol specification <xref target="I-D.ietf-ipsecme-iptfs" format="default"/>, as well as elements that may be augmented to support future configuration. The
goes beyond this simple protocol specification <xref target="RFC9347" format="default"/> goes beyond thi
s simple,
fixed mode of operation by defining a general format for any type of scheme. 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 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 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 determined by the path MTU. The fixed packet size can also be configured if a
value lower than the path MTU is desired.</t> value lower than the path MTU is desired.</t>
<t>Other configuration items include:</t> <t>Other configuration items include:</t>
<ul spacing="normal"> <dl newline="true" spacing="normal">
<li>Congestion Control. A congestion control setting to allow IP-TFS <dt>Congestion Control:</dt>
to reduce the packet rate when congestion is detected.</li> <dd>A congestion control setting to allow IP-TFS
<li>Fixed Rate configuration. The IP-TFS tunnel rate can be configured t to reduce the packet rate when congestion is detected.</dd>
aking <dt>Fixed-Rate Configuration:</dt>
<dd>The IP-TFS tunnel rate can be configured by taking
into account either layer 2 overhead or layer 3 overhead. Layer 3 overhead 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. 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 The combination of packet size and rate determines the
nominal maximum bandwidth and the transmission interval when fixed size packets nominal maximum bandwidth and the transmission interval when fixed-size packets
are used.</li> are used.</dd>
<li>User packet Fragmentation Control. While fragmentation is recommende <dt>User Packet Fragmentation Control:</dt>
d <dd>While fragmentation is recommended
for improved efficiency, a for improved efficiency, a
configuration is provided if users wish to observe configuration is provided if users wish to observe
the effect no-fragmentation on their data flows.</li> the effect of no fragmentation on their data flows.</dd>
</ul> </dl>
<t>The YANG operational data allows the readout of the configured paramete <t>The YANG operational data allows the readout of the configured paramete
rs as rs, as
well as the per SA statistics and error counters for IP-TFS. Per SA IPsec packe well as the per-SA statistics and error counters for IP-TFS. Per-SA IPsec packe
t t
statistics are provided as a feature and per SA IP-TFS specific statistics statistics are provided as a feature, and per-SA IP-TFS-specific statistics are
provided
as another feature. as another feature.
Both sets of statistics augment the IPsec YANG models with Both sets of statistics augment the IPsec YANG modules with
counters that allow observation of IP-TFS packet efficiency.</t> counters that allow observation of IP-TFS packet efficiency.</t>
<t><xref target="RFC9061" format="default"/> has a set of IPsec YANG <t> IPsec YANG
management objects. IP-TFS YANG augments the IKE and management objects are set in <xref target="RFC9061" format="default"/>. IP-TFS
the IKELESS models. In these models the Security Policy YANG augments the IKE and
the IKE-less models. In these models, the Security Policy
database entry and Security Association entry for an IPsec database entry and Security Association entry for an IPsec
Tunnel can be augmented with IP-TFS. In addition, tunnel can be augmented with IP-TFS. In addition,
this model uses YANG types defined in <xref target="RFC6991" format="default"/>. this model uses YANG types defined in <xref target="RFC6991" format="default"/>.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>YANG Management</name> <name>YANG Management</name>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>YANG Tree</name> <name>YANG Tree</name>
<t>The following is the YANG tree diagram (<xref target="RFC8340" format ="default"/>) for the IP-TFS <t>The following is the YANG tree diagram <xref target="RFC8340" format= "default"/> for the IP-TFS
extensions.</t> extensions.</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode type="yangtree"><![CDATA[
module: ietf-ipsec-iptfs module: ietf-ipsec-iptfs
augment /nsfike:ipsec-ike/nsfike:conn-entry/nsfike:spd augment /nsfike:ipsec-ike/nsfike:conn-entry/nsfike:spd
/nsfike:spd-entry/nsfike:ipsec-policy-config /nsfike:spd-entry/nsfike:ipsec-policy-config
/nsfike:processing-info/nsfike:ipsec-sa-cfg: /nsfike:processing-info/nsfike:ipsec-sa-cfg:
+--rw traffic-flow-security +--rw traffic-flow-security
+--rw congestion-control? boolean +--rw congestion-control? boolean
+--rw packet-size +--rw packet-size
| +--rw use-path-mtu-discovery? boolean | +--rw use-path-mtu-discovery? boolean
| +--rw outer-packet-size? uint16 | +--rw outer-packet-size? uint16
+--rw (tunnel-rate)? +--rw (tunnel-rate)?
| +--:(l2-fixed-rate) | +--:(l2-fixed-rate)
skipping to change at line 270 skipping to change at line 255
+--ro tx-all-pad-pkts? yang:counter64 +--ro tx-all-pad-pkts? yang:counter64
+--ro tx-all-pad-octets? yang:counter64 +--ro tx-all-pad-octets? yang:counter64
+--ro tx-extra-pad-pkts? yang:counter64 +--ro tx-extra-pad-pkts? yang:counter64
+--ro tx-extra-pad-octets? yang:counter64 +--ro tx-extra-pad-octets? yang:counter64
+--ro rx-all-pad-pkts? yang:counter64 +--ro rx-all-pad-pkts? yang:counter64
+--ro rx-all-pad-octets? yang:counter64 +--ro rx-all-pad-octets? yang:counter64
+--ro rx-extra-pad-pkts? yang:counter64 +--ro rx-extra-pad-pkts? yang:counter64
+--ro rx-extra-pad-octets? yang:counter64 +--ro rx-extra-pad-octets? yang:counter64
+--ro rx-errored-pkts? yang:counter64 +--ro rx-errored-pkts? yang:counter64
+--ro rx-missed-pkts? yang:counter64 +--ro rx-missed-pkts? yang:counter64
]]></artwork> ]]></sourcecode>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>YANG Module</name> <name>YANG Module</name>
<t>The following is the YANG module for managing the IP-TFS extensions. <t>The following is the YANG module for managing the IP-TFS extensions.
The model contains references to <xref target="I-D.ietf-ipsecme-iptfs" format="d The model contains references to <xref target="RFC9347" format="default"/> and
efault"/> and <xref target="RFC5348" format="default"/>.</t>
<xref target="RFC5348" format="default"/>.</t> <sourcecode name="ietf-ipsec-iptfs@2022-12-16.yang" type="yang" markers=
<sourcecode name="ietf-ipsec-iptfs@2022-09-22.yang" type="" markers="tru "true"><![CDATA[
e"><![CDATA[
module ietf-ipsec-iptfs { module ietf-ipsec-iptfs {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec-iptfs"; namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec-iptfs";
prefix iptfs; prefix iptfs;
import ietf-i2nsf-ike { import ietf-i2nsf-ike {
prefix nsfike; prefix nsfike;
reference reference
"RFC 9061 A YANG Data Model for IPsec Flow Protection Based on "RFC 9061: A YANG Data Model for IPsec Flow Protection Based on
Software-Defined Networking (SDN) Section 5.2"; Software-Defined Networking (SDN), Section 5.2";
} }
import ietf-i2nsf-ikeless { import ietf-i2nsf-ikeless {
prefix nsfikels; prefix nsfikels;
reference reference
"RFC 9061 A YANG Data Model for IPsec Flow Protection Based on "RFC 9061: A YANG Data Model for IPsec Flow Protection Based on
Software-Defined Networking (SDN) Section 5.3"; Software-Defined Networking (SDN), Section 5.3";
} }
import ietf-yang-types { import ietf-yang-types {
prefix yang; prefix yang;
reference reference
"RFC 6991: Common YANG Data Types"; "RFC 6991: Common YANG Data Types";
} }
organization organization
"IETF IPSECME Working Group (IPSECME)"; "IETF IPSECME Working Group (IPSECME)";
contact contact
"WG Web: <https://datatracker.ietf.org/wg/ipsecme/> "WG Web: <https://datatracker.ietf.org/wg/ipsecme/>
WG List: <mailto:ipsecme@ietf.org> WG List: <mailto:ipsecme@ietf.org>
Author: Don Fedyk Author: Don Fedyk
<mailto:dfedyk@labn.net> <mailto:dfedyk@labn.net>
Author: Christian Hopps Author: Christian Hopps
<mailto:chopps@chopps.org>"; <mailto:chopps@chopps.org>";
// RFC Ed.: replace XXXX with actual RFC number and
// remove this note.
description description
"This module defines the configuration and operational state for "This module defines the configuration and operational state for
managing the IP Traffic Flow Security functionality [RFC XXXX]. managing the IP Traffic Flow Security functionality (RFC 9348).
Copyright (c) 2022 IETF Trust and the persons identified as Copyright (c) 2023 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Revised BSD License to the license terms contained in, the Revised BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see This version of this YANG module is part of RFC 9348; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
// RFC Ed.: replace XXXX with actual RFC number and remove revision 2022-12-16 {
// this note
// replace '2016-03-20' with the module publication date
// the format is (2022-09-22)
revision 2022-09-22 {
description description
"Initial Revision"; "Initial revision";
reference reference
"RFC XXXX: IP Traffic Flow Security YANG Module"; "RFC 9348: A YANG Data Model for IP Traffic Flow Security";
} }
feature ipsec-stats { feature ipsec-stats {
description description
"This feature indicates the device supports "This feature indicates the device supports
per SA IPsec statistics"; per-SA IPsec statistics.";
} }
feature iptfs-stats { feature iptfs-stats {
description description
"This feature indicates the device supports "This feature indicates the device supports
per SA IP Traffic Flow Security statistics"; per-SA IP Traffic Flow Security statistics.";
} }
/*--------------------*/ /*--------------------*/
/* groupings */ /* groupings */
/*--------------------*/ /*--------------------*/
grouping ipsec-tx-stat-grouping { grouping ipsec-tx-stat-grouping {
description description
"IPsec outbound statistics"; "IPsec outbound statistics";
leaf tx-pkts { leaf tx-pkts {
skipping to change at line 415 skipping to change at line 391
} }
} }
grouping iptfs-inner-tx-stat-grouping { grouping iptfs-inner-tx-stat-grouping {
description description
"IP-TFS outbound inner packet statistics"; "IP-TFS outbound inner packet statistics";
leaf tx-pkts { leaf tx-pkts {
type yang:counter64; type yang:counter64;
config false; config false;
description description
"Total number of IP-TFS inner packets sent. This "Total number of IP-TFS inner packets sent. This
count is whole packets only. A fragmented packet count is whole packets only. A fragmented packet
counts as one packet"; counts as one packet.";
reference reference
"draft-ietf-ipsecme-iptfs"; "RFC 9347: Aggregation and Fragmentation Mode for
Encapsulating Security Payload (ESP) and Its Use for
IP Traffic Flow Security (IP-TFS)";
} }
leaf tx-octets { leaf tx-octets {
type yang:counter64; type yang:counter64;
config false; config false;
description description
"Total number of IP-TFS inner octets sent. This is "Total number of IP-TFS inner octets sent. This is
inner packet octets only. Does not count padding."; inner packet octets only. It does not count padding.";
reference reference
"draft-ietf-ipsecme-iptfs"; "RFC 9347: Aggregation and Fragmentation Mode for
Encapsulating Security Payload (ESP) and Its Use for
IP Traffic Flow Security (IP-TFS)";
} }
} }
grouping iptfs-outer-tx-stat-grouping { grouping iptfs-outer-tx-stat-grouping {
description description
"IP-TFS outbound inner packet statistics"; "IP-TFS outbound inner packet statistics";
leaf tx-all-pad-pkts { leaf tx-all-pad-pkts {
type yang:counter64; type yang:counter64;
config false; config false;
description description
"Total number of transmitted IP-TFS packets that "Total number of transmitted IP-TFS packets that
were all padding with no inner packet data."; were all padding with no inner packet data.";
reference reference
"draft-ietf-ipsecme-iptfs section 2.2.3"; "RFC 9347: Aggregation and Fragmentation Mode for
Encapsulating Security Payload (ESP) and Its Use for
IP Traffic Flow Security (IP-TFS), Section 2.2.3";
} }
leaf tx-all-pad-octets { leaf tx-all-pad-octets {
type yang:counter64; type yang:counter64;
config false; config false;
description description
"Total number transmitted octets of padding added to "Total number transmitted octets of padding added to
IP-TFS packets with no inner packet data."; IP-TFS packets with no inner packet data.";
reference reference
"draft-ietf-ipsecme-iptfs section 2.2.3"; "RFC 9347: Aggregation and Fragmentation Mode for
Encapsulating Security Payload (ESP) and Its Use for
IP Traffic Flow Security (IP-TFS), Section 2.2.3";
} }
leaf tx-extra-pad-pkts { leaf tx-extra-pad-pkts {
type yang:counter64; type yang:counter64;
config false; config false;
description description
"Total number of transmitted outer IP-TFS packets "Total number of transmitted outer IP-TFS packets
that included some padding."; that included some padding.";
reference reference
"draft-ietf-ipsecme-iptfs section 2.2.3.1"; "RFC 9347: Aggregation and Fragmentation Mode for
Encapsulating Security Payload (ESP) and Its Use for
IP Traffic Flow Security (IP-TFS), Section 2.2.3.1";
} }
leaf tx-extra-pad-octets { leaf tx-extra-pad-octets {
type yang:counter64; type yang:counter64;
config false; config false;
description description
"Total number of transmitted octets of padding added "Total number of transmitted octets of padding added
to outer IP-TFS packets with data."; to outer IP-TFS packets with data.";
reference reference
"draft-ietf-ipsecme-iptfs section 2.2.3.1"; "RFC 9347: Aggregation and Fragmentation Mode for
Encapsulating Security Payload (ESP) and Its Use for
IP Traffic Flow Security (IP-TFS), Section 2.2.3.1";
} }
} }
grouping iptfs-inner-rx-stat-grouping { grouping iptfs-inner-rx-stat-grouping {
description description
"IP-TFS inner packet inbound statistics"; "IP-TFS inner packet inbound statistics";
leaf rx-pkts { leaf rx-pkts {
type yang:counter64; type yang:counter64;
config false; config false;
description description
"Total number of IP-TFS inner packets received."; "Total number of IP-TFS inner packets received.";
reference reference
"draft-ietf-ipsecme-iptfs section 2.2"; "RFC 9347: Aggregation and Fragmentation Mode for
Encapsulating Security Payload (ESP) and Its Use for
IP Traffic Flow Security (IP-TFS), Section 2.2";
} }
leaf rx-octets { leaf rx-octets {
type yang:counter64; type yang:counter64;
config false; config false;
description description
"Total number of IP-TFS inner octets received. Does "Total number of IP-TFS inner octets received. It does
not include padding or overhead"; not include padding or overhead.";
reference reference
"draft-ietf-ipsecme-iptfs section 2.2"; "RFC 9347: Aggregation and Fragmentation Mode for
Encapsulating Security Payload (ESP) and Its Use for
IP Traffic Flow Security (IP-TFS), Section 2.2";
} }
leaf rx-incomplete-pkts { leaf rx-incomplete-pkts {
type yang:counter64; type yang:counter64;
config false; config false;
description description
"Total number of IP-TFS inner packets that were "Total number of IP-TFS inner packets that were
incomplete. Usually this is due to fragments not incomplete. Usually this is due to fragments that are
received. Also, this may be due to misordering or not received. Also, this may be due to misordering or
errors in received outer packets."; errors in received outer packets.";
reference reference
"draft-ietf-ipsecme-iptfs"; "RFC 9347: Aggregation and Fragmentation Mode for
Encapsulating Security Payload (ESP) and Its Use for
IP Traffic Flow Security (IP-TFS)";
} }
} }
grouping iptfs-outer-rx-stat-grouping { grouping iptfs-outer-rx-stat-grouping {
description description
"IP-TFS outer packet inbound statistics"; "IP-TFS outer packet inbound statistics";
leaf rx-all-pad-pkts { leaf rx-all-pad-pkts {
type yang:counter64; type yang:counter64;
config false; config false;
description description
"Total number of received IP-TFS packets that were "Total number of received IP-TFS packets that were
all padding with no inner packet data."; all padding with no inner packet data.";
reference reference
"draft-ietf-ipsecme-iptfs section 2.2.3"; "RFC 9347: Aggregation and Fragmentation Mode for
Encapsulating Security Payload (ESP) and Its Use for
IP Traffic Flow Security (IP-TFS), Section 2.2.3";
} }
leaf rx-all-pad-octets { leaf rx-all-pad-octets {
type yang:counter64; type yang:counter64;
config false; config false;
description description
"Total number received octets of padding added to "Total number of received octets of padding added to
IP-TFS packets with no inner packet data."; IP-TFS packets with no inner packet data.";
reference reference
"draft-ietf-ipsecme-iptfs section 2.2.3"; "RFC 9347: Aggregation and Fragmentation Mode for
Encapsulating Security Payload (ESP) and Its Use for
IP Traffic Flow Security (IP-TFS), Section 2.2.3";
} }
leaf rx-extra-pad-pkts { leaf rx-extra-pad-pkts {
type yang:counter64; type yang:counter64;
config false; config false;
description description
"Total number of received outer IP-TFS packets that "Total number of received outer IP-TFS packets that
included some padding."; included some padding.";
reference reference
"draft-ietf-ipsecme-iptfs section 2.2.3.1"; "RFC 9347: Aggregation and Fragmentation Mode for
Encapsulating Security Payload (ESP) and Its Use for
IP Traffic Flow Security (IP-TFS), Section 2.2.3.1";
} }
leaf rx-extra-pad-octets { leaf rx-extra-pad-octets {
type yang:counter64; type yang:counter64;
config false; config false;
description description
"Total number of received octets of padding added to "Total number of received octets of padding added to
outer IP-TFS packets with data."; outer IP-TFS packets with data.";
reference reference
"draft-ietf-ipsecme-iptfs section 2.2.3.1"; "RFC 9347: Aggregation and Fragmentation Mode for
Encapsulating Security Payload (ESP) and Its Use for
IP Traffic Flow Security (IP-TFS), Section 2.2.3.1";
} }
leaf rx-errored-pkts { leaf rx-errored-pkts {
type yang:counter64; type yang:counter64;
config false; config false;
description description
"Total number of IP-TFS outer packets dropped due to "Total number of IP-TFS outer packets dropped due to
errors."; errors.";
reference reference
"draft-ietf-ipsecme-iptfs"; "RFC 9347: Aggregation and Fragmentation Mode for
Encapsulating Security Payload (ESP) and Its Use for
IP Traffic Flow Security (IP-TFS)";
} }
leaf rx-missed-pkts { leaf rx-missed-pkts {
type yang:counter64; type yang:counter64;
config false; config false;
description description
"Total number of IP-TFS outer packets missing "Total number of IP-TFS outer packets missing,
indicated by missing sequence number."; indicated by a missing sequence number.";
reference reference
"draft-ietf-ipsecme-iptfs"; "RFC 9347: Aggregation and Fragmentation Mode for
Encapsulating Security Payload (ESP) and Its Use for
IP Traffic Flow Security (IP-TFS)";
} }
} }
grouping iptfs-config { grouping iptfs-config {
description description
"This is the grouping for iptfs configuration"; "This is the grouping for IP-TFS configuration.";
container traffic-flow-security { container traffic-flow-security {
description description
"Configure the IPSec TFS in Security "Configure the IPsec TFS in the Security
Association Database (SAD)"; Association Database (SAD).";
leaf congestion-control { leaf congestion-control {
type boolean; type boolean;
default "true"; default "true";
description description
"When set to true, the default, this enables the "When set to true, the default, this enables the
congestion control on-the-wire exchange of data that is congestion control on-the-wire exchange of data that is
required by congestion control algorithms as defined by required by congestion control algorithms, as defined by
RFC 5348. When set to false, IP-TFS sends fixed-sized RFC 5348. When set to false, IP-TFS sends fixed-size
packets over an IP-TFS tunnel at a constant rate."; packets over an IP-TFS tunnel at a constant rate.";
reference reference
"draft-ietf-ipsecme-iptfs section 2.5.2, RFC 5348"; "RFC 9347: Aggregation and Fragmentation Mode for
Encapsulating Security Payload (ESP) and Its Use for
IP Traffic Flow Security (IP-TFS), Section 2.4.2;
RFC 5348: TCP Friendly Rate Control (TFRC): Protocol
Specification";
} }
container packet-size { container packet-size {
description description
"Packet size is either auto-discovered or manually "Packet size is either auto-discovered or manually
configured."; configured.";
leaf use-path-mtu-discovery { leaf use-path-mtu-discovery {
type boolean; type boolean;
default "true"; default "true";
description description
"Utilize path mtu discovery to determine maximum "Utilize path MTU discovery to determine maximum
IP-TFS packet size. If the packet size is explicitly IP-TFS packet size. If the packet size is explicitly
configured, then it will only be adjusted downward if configured, then it will only be adjusted downward if
use-path-mtu-discovery is set."; use-path-mtu-discovery is set.";
reference reference
"draft-ietf-ipsecme-iptfs section 4.2"; "RFC 9347: Aggregation and Fragmentation Mode for
Encapsulating Security Payload (ESP) and Its Use for
IP Traffic Flow Security (IP-TFS), Section 4.2";
} }
leaf outer-packet-size { leaf outer-packet-size {
type uint16; type uint16;
units bytes; units "bytes";
description description
"On transmission, the size of the outer encapsulating "On transmission, the size of the outer encapsulating
tunnel packet (i.e., the IP packet containing the ESP tunnel packet (i.e., the IP packet containing
payload)."; Encapsulating Security Payload (ESP)).";
reference reference
"draft-ietf-ipsecme-iptfs section 4.2"; "RFC 9347: Aggregation and Fragmentation Mode for
Encapsulating Security Payload (ESP) and Its Use for
IP Traffic Flow Security (IP-TFS), Section 4.2";
} }
} }
choice tunnel-rate { choice tunnel-rate {
description description
"TFS bit rate may be specified at layer 2 wire "The TFS bit rate may be specified at layer 2 wire
rate or layer 3 packet rate"; rate or layer 3 packet rate.";
leaf l2-fixed-rate { leaf l2-fixed-rate {
type yang:gauge64; type yang:gauge64;
units "bits/second"; units "bits/second";
description description
"On transmission, target bandwidth/bit rate in "On transmission, target bandwidth/bit rate in
bits/second for iptfs tunnel. This fixed rate is the bits/second for IP-TFS tunnel. This fixed rate is the
nominal timing for the fixed size packet. If nominal timing for the fixed-size packet. If
congestion control is enabled the rate may be congestion control is enabled, the rate may be
adjusted down (or up if unset)."; adjusted down (or up if unset).";
reference reference
"draft-ietf-ipsecme-iptfs section 4.1"; "RFC 9347: Aggregation and Fragmentation Mode for
Encapsulating Security Payload (ESP) and Its Use for
IP Traffic Flow Security (IP-TFS), Section 4.1";
} }
leaf l3-fixed-rate { leaf l3-fixed-rate {
type yang:gauge64; type yang:gauge64;
units "bits/second"; units "bits/second";
description description
"On transmission, target bandwidth/bit rate in "On transmission, target bandwidth/bit rate in
bits/second for iptfs tunnel. This fixed rate is the bits/second for IP-TFS tunnel. This fixed rate is the
nominal timing for the fixed size packet. If nominal timing for the fixed-size packet. If
congestion control is enabled the rate may be congestion control is enabled, the rate may be
adjusted down (or up if unset)."; adjusted down (or up if unset).";
reference reference
"draft-ietf-ipsecme-iptfs section 4.1"; "RFC 9347: Aggregation and Fragmentation Mode for
Encapsulating Security Payload (ESP) and Its Use for
IP Traffic Flow Security (IP-TFS), Section 4.1";
} }
} }
leaf dont-fragment { leaf dont-fragment {
type boolean; type boolean;
default "false"; default "false";
description description
"On transmission, disable packet fragmentation across "On transmission, disable packet fragmentation across
consecutive iptfs tunnel packets; inner packets larger consecutive IP-TFS tunnel packets; inner packets larger
than what can be transmitted in outer packets will be than what can be transmitted in outer packets will be
dropped."; dropped.";
reference reference
"draft-ietf-ipsecme-iptfs section 2.2.4 and 6.1.4"; "RFC 9347: Aggregation and Fragmentation Mode for
Encapsulating Security Payload (ESP) and Its Use for
IP Traffic Flow Security (IP-TFS), Section 2.2.4 and
6.1.4";
} }
leaf max-aggregation-time { leaf max-aggregation-time {
type decimal64 { type decimal64 {
fraction-digits 6; fraction-digits 6;
} }
units "milliseconds"; units "milliseconds";
description description
"On transmission, maximum aggregation time is the "On transmission, maximum aggregation time is the
maximum length of time a received inner packet can be maximum length of time a received inner packet can be
held prior to transmission in the iptfs tunnel. Inner held prior to transmission in the IP-TFS tunnel. Inner
packets that would be held longer than this time, based packets that would be held longer than this time, based
on the current tunnel configuration will be dropped on the current tunnel configuration, will be dropped
rather than be queued for transmission. Maximum rather than be queued for transmission. Maximum
aggregation time is configurable in milliseconds or aggregation time is configurable in milliseconds or
fractional milliseconds down to 1 nanosecond."; fractional milliseconds down to 1 nanosecond.";
} }
leaf window-size { leaf window-size {
type uint16 { type uint16 {
range "0..65535"; range "0..65535";
} }
description description
"On reception, the maximum number of out-of-order "On reception, the maximum number of out-of-order
packets that will be reordered by an iptfs receiver packets that will be reordered by an IP-TFS receiver
while performing the reordering operation. The value 0 while performing the reordering operation. The value 0
disables any reordering."; disables any reordering.";
reference reference
"draft-ietf-ipsecme-iptfs section 2.2.3"; "RFC 9347: Aggregation and Fragmentation Mode for
Encapsulating Security Payload (ESP) and Its Use for
IP Traffic Flow Security (IP-TFS), Section 2.2.3";
} }
leaf send-immediately { leaf send-immediately {
type boolean; type boolean;
default "false"; default "false";
description description
"On reception, send inner packets as soon as possible, do "On reception, send inner packets as soon as possible; do
not wait for lost or misordered outer packets. not wait for lost or misordered outer packets.
Selecting this option reduces the inner (user) packet Selecting this option reduces the inner (user) packet
delay but can amplify out-of-order delivery of the delay but can amplify out-of-order delivery of the
inner packet stream in the presence of packet inner packet stream in the presence of packet
aggregation and any reordering."; aggregation and any reordering.";
reference reference
"draft-ietf-ipsecme-iptfs section 2.5"; "RFC 9347: Aggregation and Fragmentation Mode for
Encapsulating Security Payload (ESP) and Its Use for
IP Traffic Flow Security (IP-TFS), Section 2.5";
} }
leaf lost-packet-timer-interval { leaf lost-packet-timer-interval {
type decimal64 { type decimal64 {
fraction-digits 6; fraction-digits 6;
} }
units "milliseconds"; units "milliseconds";
description description
"On reception, this interval defines the length of time "On reception, this interval defines the length of time
an iptfs receiver will wait for a missing packet before an IP-TFS receiver will wait for a missing packet before
considering it lost. If not using send-immediately, considering it lost. If not using send-immediately,
then each lost packet will delay inner (user) packets then each lost packet will delay inner (user) packets
until this timer expires. Setting this value too low until this timer expires. Setting this value too low
can impact reordering and reassembly. The value is can impact reordering and reassembly. The value is
configurable in milliseconds or fractional milliseconds configurable in milliseconds or fractional milliseconds
down to 1 nanosecond."; down to 1 nanosecond.";
reference reference
"draft-ietf-ipsecme-iptfs section 2.2.3"; "RFC 9347: Aggregation and Fragmentation Mode for
Encapsulating Security Payload (ESP) and Its Use for
IP Traffic Flow Security (IP-TFS), Section 2.2.3";
} }
} }
} }
/* /*
* IP-TFS ike configuration * IP-TFS ike configuration
*/ */
augment "/nsfike:ipsec-ike/nsfike:conn-entry/nsfike:spd/" augment "/nsfike:ipsec-ike/nsfike:conn-entry/nsfike:spd/"
+ "nsfike:spd-entry/" + "nsfike:spd-entry/"
skipping to change at line 767 skipping to change at line 794
} }
} }
/* /*
* packet counters * packet counters
*/ */
augment "/nsfike:ipsec-ike/nsfike:conn-entry/" augment "/nsfike:ipsec-ike/nsfike:conn-entry/"
+ "nsfike:child-sa-info" { + "nsfike:child-sa-info" {
description description
"Per SA Counters"; "Per-SA counters";
container ipsec-stats { container ipsec-stats {
if-feature "ipsec-stats"; if-feature "ipsec-stats";
config false; config false;
description description
"IPsec per SA packet counters. "IPsec per-SA packet counters.
tx = outbound, rx = inbound"; tx = outbound, rx = inbound";
uses ipsec-tx-stat-grouping; uses ipsec-tx-stat-grouping;
uses ipsec-rx-stat-grouping; uses ipsec-rx-stat-grouping;
} }
container iptfs-inner-pkt-stats { container iptfs-inner-pkt-stats {
if-feature "iptfs-stats"; if-feature "iptfs-stats";
config false; config false;
description description
"IPTFS per SA inner packet counters. "IP-TFS per-SA inner packet counters.
tx = outbound, rx = inbound"; tx = outbound, rx = inbound";
uses iptfs-inner-tx-stat-grouping; uses iptfs-inner-tx-stat-grouping;
uses iptfs-inner-rx-stat-grouping; uses iptfs-inner-rx-stat-grouping;
} }
container iptfs-outer-pkt-stats { container iptfs-outer-pkt-stats {
if-feature "iptfs-stats"; if-feature "iptfs-stats";
config false; config false;
description description
"IPTFS per SA outer packets counters. "IP-TFS per-SA outer packets counters.
tx = outbound, rx = inbound"; tx = outbound, rx = inbound";
uses iptfs-outer-tx-stat-grouping; uses iptfs-outer-tx-stat-grouping;
uses iptfs-outer-rx-stat-grouping; uses iptfs-outer-rx-stat-grouping;
} }
} }
/* /*
* packet counters * packet counters
*/ */
augment "/nsfikels:ipsec-ikeless/nsfikels:sad/" augment "/nsfikels:ipsec-ikeless/nsfikels:sad/"
+ "nsfikels:sad-entry" { + "nsfikels:sad-entry" {
description description
"Per SA Counters"; "Per-SA counters";
container ipsec-stats { container ipsec-stats {
if-feature "ipsec-stats"; if-feature "ipsec-stats";
config false; config false;
description description
"IPsec per SA packet counters. "IPsec per-SA packet counters.
tx = outbound, rx = inbound"; tx = outbound, rx = inbound";
uses ipsec-tx-stat-grouping; uses ipsec-tx-stat-grouping;
uses ipsec-rx-stat-grouping; uses ipsec-rx-stat-grouping;
} }
container iptfs-inner-pkt-stats { container iptfs-inner-pkt-stats {
if-feature "iptfs-stats"; if-feature "iptfs-stats";
config false; config false;
description description
"IPTFS per SA inner packet counters. "IP-TFS per-SA inner packet counters.
tx = outbound, rx = inbound"; tx = outbound, rx = inbound";
uses iptfs-inner-tx-stat-grouping; uses iptfs-inner-tx-stat-grouping;
uses iptfs-inner-rx-stat-grouping; uses iptfs-inner-rx-stat-grouping;
} }
container iptfs-outer-pkt-stats { container iptfs-outer-pkt-stats {
if-feature "iptfs-stats"; if-feature "iptfs-stats";
config false; config false;
description description
"IPTFS per SA outer packets counters. "IP-TFS per-SA outer packets counters.
tx = outbound, rx = inbound"; tx = outbound, rx = inbound";
uses iptfs-outer-tx-stat-grouping; uses iptfs-outer-tx-stat-grouping;
uses iptfs-outer-rx-stat-grouping; uses iptfs-outer-rx-stat-grouping;
} }
} }
} }
]]></sourcecode> ]]></sourcecode>
</section> </section>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Updates to the IETF XML Registry</name> <name>Updates to the IETF XML Registry</name>
<t>This document registers a URI in the "IETF XML Registry" <xref target <t>Per this document, IANA has registered a URI in the "IETF XML Registr
="RFC3688" format="default"/>. y" <xref target="RFC3688" format="default"/> as follows.</t>
Following the format in <xref target="RFC3688" format="default"/>, the following <dl newline="false" spacing="compact">
registration has been
made:</t>
<dl newline="true" spacing="normal">
<dt>URI:</dt> <dt>URI:</dt>
<dd>urn:ietf:params:xml:ns:yang:ietf-ipsec-iptfs</dd> <dd>urn:ietf:params:xml:ns:yang:ietf-ipsec-iptfs</dd>
<dt>Registrant Contact:</dt> <dt>Registrant Contact:</dt>
<dd>The IESG.</dd> <dd>The IESG.</dd>
<dt>XML:</dt> <dt>XML:</dt>
<dd>N/A; the requested URI is an XML namespace.</dd> <dd>N/A; the requested URI is an XML namespace.</dd>
</dl> </dl>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Updates to the YANG Module Names Registry</name> <name>Updates to the YANG Module Names Registry</name>
<t>This document registers one YANG module in the "YANG Module Names" <t>Per this document, IANA has registered one YANG module in the "YANG M
registry <xref target="RFC6020" format="default"/>. Following the format in <xre odule Names"
f target="RFC6020" format="default"/>, the following registry <xref target="RFC6020" format="default"/> as follows.</t>
registration has been made:</t> <dl newline="false" spacing="compact">
<dl newline="true" spacing="normal"> <dt>Name:</dt>
<dt>name:</dt>
<dd>ietf-ipsec-iptfs</dd> <dd>ietf-ipsec-iptfs</dd>
<dt>namespace:</dt> <dt>Namespace:</dt>
<dd>urn:ietf:params:xml:ns:yang:ietf-ipsec-iptfs</dd> <dd>urn:ietf:params:xml:ns:yang:ietf-ipsec-iptfs</dd>
<dt>prefix:</dt> <dt>Prefix:</dt>
<dd>iptfs</dd> <dd>iptfs</dd>
<dt>reference:</dt> <dt>Reference:</dt>
<dd>RFC XXXX (RFC Ed.: replace XXXX with actual RFC number and remove <dd>RFC 9348</dd>
this note.)</dd>
</dl> </dl>
</section> </section>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>The YANG module specified in this document defines a schema for data <t>The YANG module specified in this document defines a schema for data
that is designed to be accessed via network management protocols such that is designed to be accessed via network management protocols such
as NETCONF <xref target="RFC6241" format="default"/> or RESTCONF <xref target="R FC8040" format="default"/>. The lowest NETCONF layer is as NETCONF <xref target="RFC6241" format="default"/> or RESTCONF <xref target="R FC8040" format="default"/>. The lowest NETCONF layer is
the secure transport layer, and the mandatory-to-implement secure the secure transport layer, and the mandatory-to-implement secure
transport is Secure Shell (SSH) <xref target="RFC6242" format="default"/>. The l owest RESTCONF layer is transport is Secure Shell (SSH) <xref target="RFC6242" format="default"/>. The l owest RESTCONF layer is
HTTPS, and the mandatory-to-implement secure transport is TLS HTTPS, and the mandatory-to-implement secure transport is TLS
<xref target="RFC8446" format="default"/>.</t> <xref target="RFC8446" format="default"/>.</t>
<t>The Network Configuration Access Control Model (NACM) <xref target="RFC 8341" format="default"/> <t>The Network Configuration Access Control Model (NACM) <xref target="RFC 8341" format="default"/>
provides the means to restrict access for particular NETCONF or provides the means to restrict access for particular NETCONF or
RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or
RESTCONF protocol operations and content.</t> RESTCONF protocol operations and content.</t>
<t>Certain data nodes defined in this YANG module are <t> There are a number of data nodes defined in this YANG module that are
writable/creatable/deletable. These changes can enable, disable and writable/creatable/deletable (i.e., config true, which is the default). These da
modify the behavior of IP traffic flow security, for the implications ta nodes may be considered sensitive or vulnerable in some network environments.
regarding these types of changes consult the <xref target="I-D.ietf-ipsecme-iptf Write operations (e.g., edit-config) to these data nodes without proper protect
s" format="default"/> ion can have a negative effect on network operations. These are the subtrees and
which defines the functionality. The relevant sub-trees or nodes are: data nodes and their sensitivity/vulnerability:</t>
</t>
<dl spacing="normal" indent="3" newline="false"> <dl spacing="normal" indent="3" newline="false">
<dt>../traffic-flow-security:</dt> <dt>../traffic-flow-security:</dt>
<dd>Enabling IP traffic flow security is controlled by setting the entri <dd>Enabling IP-TFS is controlled by setting the entries
es under traffic-flow-security in IKE or IKE-less models. IP-TFS
under traffic-flow-security in IKE or IKE-less models. IP traffic flow is set either to be congestion sensitive or a fixed rate by setting
security is set either to be congestion sensitive or a fixed rate by setting parameters in this subtree.
parameters in this sub-tree.
</dd> </dd>
</dl> </dl>
<t>Certain readable data nodes in this YANG module may be considered sensi <t> Some of the readable data nodes in this YANG module may be considered
tive sensitive or vulnerable in some network environments. It is thus important to co
or vulnerable in some network environments. While IP-TFS hides the ntrol read access (e.g., via get, get-config, or notification) to these data nod
traffic flows through the network, IP-TFS YANG statistics could reveal es. These are the subtrees and data nodes and their sensitivity/vulnerability:
some information about traffic flows. Therefore, access to IP-TFS YANG
statistics also needs to be protected from third party observation.
These IP-TFS YANG statistics can be found at:
</t> </t>
<dl spacing="normal" indent="3" newline="false"> <dl spacing="normal" indent="3" newline="false">
<dt>../iptfs-inner-pkt-stats and ../iptfs-outer-pkt-stats:</dt> <dt>../iptfs-inner-pkt-stats and ../iptfs-outer-pkt-stats:</dt>
<dd> <dd>
Access to IP traffic flow security statistics can provide information Access to IP-TFS statistics can provide information
that IP traffic flow security obscures such as the true activity of the flows that IP-TFS obscures, such as the true activity of the flows
using IP traffic flow security. using IP-TFS.
</dd> </dd>
</dl> </dl>
</section> </section>
<section numbered="true" toc="default">
<name>Acknowledgements</name>
<t>The authors would like to thank Eric Kinzie, Juergen Schoenwaelder, Lou
Berger and Tero Kivinen
for their feedback and review on the YANG model.</t>
</section>
</middle> </middle>
<back> <back>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<!--<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/r <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
fc2119"> C.4301.xml"/>
<front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
<title>Key words for use in RFCs to Indicate Requirement Levels</tit C.6020.xml"/>
le> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
<author initials="S." surname="Bradner" fullname="S. Bradner"> C.7950.xml"/>
<organization/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
</author> C.8342.xml"/>
<date year="1997" month="March"/>
<abstract>
<t>In many standards track documents several words are used to sig
nify the requirements in the specification. These words are often capitalized.
This document defines these words as they should be interpreted in IETF document
s. This document specifies an Internet Best Current Practices for the Internet
Community, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>-->
<reference anchor="RFC4301" target="https://www.rfc-editor.org/info/rfc4
301">
<front>
<title>Security Architecture for the Internet Protocol</title>
<author initials="S." surname="Kent" fullname="S. Kent">
<organization/>
</author>
<author initials="K." surname="Seo" fullname="K. Seo">
<organization/>
</author>
<date year="2005" month="December"/>
<abstract>
<t>This document describes an updated version of the "Security Arc
hitecture for IP", which is designed to provide security services for traffic at
the IP layer. This document obsoletes RFC 2401 (November 1998). [STANDARDS-TR
ACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4301"/>
<seriesInfo name="DOI" value="10.17487/RFC4301"/>
</reference>
<reference anchor="RFC6020" target="https://www.rfc-editor.org/info/rfc6
020">
<front>
<title>YANG - A Data Modeling Language for the Network Configuration
Protocol (NETCONF)</title>
<author initials="M." surname="Bjorklund" fullname="M. Bjorklund" ro
le="editor">
<organization/>
</author>
<date year="2010" month="October"/>
<abstract>
<t>YANG is a data modeling language used to model configuration an
d state data manipulated by the Network Configuration Protocol (NETCONF), NETCON
F remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6020"/>
<seriesInfo name="DOI" value="10.17487/RFC6020"/>
</reference>
<reference anchor="RFC7950" target="https://www.rfc-editor.org/info/rfc7
950">
<front>
<title>The YANG 1.1 Data Modeling Language</title>
<author initials="M." surname="Bjorklund" fullname="M. Bjorklund" ro
le="editor">
<organization/>
</author>
<date year="2016" month="August"/>
<abstract>
<t>YANG is a data modeling language used to model configuration da
ta, 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 langua
ge, addressing ambiguities and defects in the original specification. There are
a small number of backward incompatibilities from YANG version 1. This documen
t also specifies the YANG mappings to the Network Configuration Protocol (NETCON
F).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7950"/>
<seriesInfo name="DOI" value="10.17487/RFC7950"/>
</reference>
<!--<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/r
fc8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author initials="B." surname="Leiba" fullname="B. Leiba">
<organization/>
</author>
<date year="2017" month="May"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protoco
l specifications. This document aims to reduce the ambiguity by clarifying tha
t only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>-->
<reference anchor="RFC8342" target="https://www.rfc-editor.org/info/rfc8
342">
<front>
<title>Network Management Datastore Architecture (NMDA)</title>
<author initials="M." surname="Bjorklund" fullname="M. Bjorklund">
<organization/>
</author>
<author initials="J." surname="Schoenwaelder" fullname="J. Schoenwae
lder">
<organization/>
</author>
<author initials="P." surname="Shafer" fullname="P. Shafer">
<organization/>
</author>
<author initials="K." surname="Watsen" fullname="K. Watsen">
<organization/>
</author>
<author initials="R." surname="Wilton" fullname="R. Wilton">
<organization/>
</author>
<date year="2018" month="March"/>
<abstract>
<t>Datastores are a fundamental concept binding the data models wr
itten in the YANG data modeling language to network management protocols such as
the Network Configuration Protocol (NETCONF) and RESTCONF. This document define
s 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.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8342"/>
<seriesInfo name="DOI" value="10.17487/RFC8342"/>
</reference>
<reference anchor="I-D.ietf-ipsecme-iptfs" target="https://www.ietf.org/
archive/id/draft-ietf-ipsecme-iptfs-19.txt">
<front>
<title>IP-TFS: Aggregation and Fragmentation Mode for ESP and its Us
e for IP Traffic Flow Security</title>
<author fullname="Christian Hopps">
<organization>LabN Consulting, L.L.C.</organization>
</author>
<date month="November" day="8" year="2021"/>
<abstract>
<t> This document describes a mechanism for aggregation and frag
mentation
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.
</t> <reference anchor="RFC9347" target="https://www.rfc-editor.org/info/rfc9347">
</abstract> <front>
</front> <title>Aggregation and Fragmentation Mode for Encapsulating Security Payload (ES
<seriesInfo name="Internet-Draft" value="draft-ietf-ipsecme-iptfs-19"/ P) and Its Use for IP Traffic Flow Security (IP-TFS)</title>
> <author initials="C" surname="Hopps" fullname="Christian Hopps">
</reference> <organization>LabN Consulting, L.L.C.</organization>
<reference anchor="RFC9061" target="https://www.rfc-editor.org/info/rfc9 </author>
061"> <date month="January" year="2023"/>
<front> </front>
<title>A YANG Data Model for IPsec Flow Protection Based on Software <seriesInfo name="RFC" value="9347"/>
-Defined Networking (SDN)</title> <seriesInfo name="DOI" value="10.17487/RFC9347"/>
<author initials="R." surname="Marin-Lopez" fullname="R. Marin-Lopez </reference>
">
<organization/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9061.
</author> xml"/>
<author initials="G." surname="Lopez-Millan" fullname="G. Lopez-Mill <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6991.
an"> xml"/>
<organization/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.
</author> xml"/>
<author initials="F." surname="Pereniguez-Garcia" fullname="F. Peren <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6241.
iguez-Garcia"> xml"/>
<organization/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6242.
</author> xml"/>
<date year="2021" month="July"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8341.
<abstract> xml"/>
<t>This document describes how to provide IPsec-based flow protect <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8040.
ion (integrity and confidentiality) by means of an Interface to Network Security xml"/>
Function (I2NSF) Controller. It considers two main well-known scenarios in IPs
ec: gateway-to-gateway and host-to-host. The service described in this document
allows the configuration and monitoring of IPsec Security Associations (IPsec SA
s) from an I2NSF Controller to one or several flow-based Network Security Functi
ons (NSFs) that rely on IPsec to protect data traffic. </t>
<t>This document focuses on the I2NSF NSF-Facing Interface by prov
iding YANG data models for configuring the IPsec databases, namely Security Poli
cy Database (SPD), Security Association Database (SAD), Peer Authorization Datab
ase (PAD), and Internet Key Exchange Version 2 (IKEv2). This allows IPsec SA est
ablishment with minimal intervention by the network administrator. This document
defines three YANG modules, but it does not define any new protocol.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9061"/>
<seriesInfo name="DOI" value="10.17487/RFC9061"/>
</reference>
<reference anchor="RFC6991" target="https://www.rfc-editor.org/info/rfc6
991" quoteTitle="true" derivedAnchor="RFC6991">
<front>
<title>Common YANG Data Types</title>
<author initials="J." surname="Schoenwaelder" fullname="J. Schoenwae
lder" role="editor">
<organization showOnFrontPage="true"/>
</author>
<date year="2013" month="July"/>
<abstract>
<t indent="0">This document introduces a collection of common data
types to be used with the YANG data modeling language. This document obsoletes
RFC 6021.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6991"/>
<seriesInfo name="DOI" value="10.17487/RFC6991"/>
</reference>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="RFC3688" target="https://www.rfc-editor.org/info/rfc3 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3688.
688"> xml"/>
<front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8340.
<title>The IETF XML Registry</title> xml"/>
<author initials="M." surname="Mealling" fullname="M. Mealling"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5348.
<organization/> xml"/>
</author>
<date year="2004" month="January"/>
<abstract>
<t>This document describes an IANA maintained registry for IETF st
andards which use Extensible Markup Language (XML) related items such as Namespa
ces, Document Type Declarations (DTDs), Schemas, and Resource Description Framew
ork (RDF) Schemas.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="81"/>
<seriesInfo name="RFC" value="3688"/>
<seriesInfo name="DOI" value="10.17487/RFC3688"/>
</reference>
<reference anchor="RFC6241" target="https://www.rfc-editor.org/info/rfc6
241">
<front>
<title>Network Configuration Protocol (NETCONF)</title>
<author initials="R." surname="Enns" fullname="R. Enns" role="editor
">
<organization/>
</author>
<author initials="M." surname="Bjorklund" fullname="M. Bjorklund" ro
le="editor">
<organization/>
</author>
<author initials="J." surname="Schoenwaelder" fullname="J. Schoenwae
lder" role="editor">
<organization/>
</author>
<author initials="A." surname="Bierman" fullname="A. Bierman" role="
editor">
<organization/>
</author>
<date year="2011" month="June"/>
<abstract>
<t>The Network Configuration Protocol (NETCONF) defined in this do
cument provides mechanisms to install, manipulate, and delete the configuration
of network devices. It uses an Extensible Markup Language (XML)-based data enco
ding for the configuration data as well as the protocol messages. The NETCONF p
rotocol operations are realized as remote procedure calls (RPCs). This document
obsoletes RFC 4741. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6241"/>
<seriesInfo name="DOI" value="10.17487/RFC6241"/>
</reference>
<reference anchor="RFC6242" target="https://www.rfc-editor.org/info/rfc6
242">
<front>
<title>Using the NETCONF Protocol over Secure Shell (SSH)</title>
<author initials="M." surname="Wasserman" fullname="M. Wasserman">
<organization/>
</author>
<date year="2011" month="June"/>
<abstract>
<t>This document describes a method for invoking and running the N
etwork Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as a
n SSH subsystem. This document obsoletes RFC 4742. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6242"/>
<seriesInfo name="DOI" value="10.17487/RFC6242"/>
</reference>
<reference anchor="RFC8040" target="https://www.rfc-editor.org/info/rfc8
040">
<front>
<title>RESTCONF Protocol</title>
<author initials="A." surname="Bierman" fullname="A. Bierman">
<organization/>
</author>
<author initials="M." surname="Bjorklund" fullname="M. Bjorklund">
<organization/>
</author>
<author initials="K." surname="Watsen" fullname="K. Watsen">
<organization/>
</author>
<date year="2017" month="January"/>
<abstract>
<t>This document describes an HTTP-based protocol that provides a
programmatic interface for accessing data defined in YANG, using the datastore c
oncepts defined in the Network Configuration Protocol (NETCONF).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8040"/>
<seriesInfo name="DOI" value="10.17487/RFC8040"/>
</reference>
<reference anchor="RFC8340" target="https://www.rfc-editor.org/info/rfc8
340">
<front>
<title>YANG Tree Diagrams</title>
<author initials="M." surname="Bjorklund" fullname="M. Bjorklund">
<organization/>
</author>
<author initials="L." surname="Berger" fullname="L. Berger" role="ed
itor">
<organization/>
</author>
<date year="2018" month="March"/>
<abstract>
<t>This document captures the current syntax used in YANG module t
ree 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 evol
ution of the YANG language.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="215"/>
<seriesInfo name="RFC" value="8340"/>
<seriesInfo name="DOI" value="10.17487/RFC8340"/>
</reference>
<reference anchor="RFC8341" target="https://www.rfc-editor.org/info/rfc8
341">
<front>
<title>Network Configuration Access Control Model</title>
<author initials="A." surname="Bierman" fullname="A. Bierman">
<organization/>
</author>
<author initials="M." surname="Bjorklund" fullname="M. Bjorklund">
<organization/>
</author>
<date year="2018" month="March"/>
<abstract>
<t>The standardization of network configuration interfaces for use
with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requ
ires 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 preconfig
ured subset of all available NETCONF or RESTCONF protocol operations and content
. This document defines such an access control model.</t>
<t>This document obsoletes RFC 6536.</t>
</abstract>
</front>
<seriesInfo name="STD" value="91"/>
<seriesInfo name="RFC" value="8341"/>
<seriesInfo name="DOI" value="10.17487/RFC8341"/>
</reference>
<reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8
446">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl
e>
<author initials="E." surname="Rescorla" fullname="E. Rescorla">
<organization/>
</author>
<date year="2018" month="August"/>
<abstract>
<t>This document specifies version 1.3 of the Transport Layer Secu
rity (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.</t>
<t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 50
77, 5246, and 6961. This document also specifies new requirements for TLS 1.2 i
mplementations.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8446"/>
<seriesInfo name="DOI" value="10.17487/RFC8446"/>
</reference>
<reference anchor="RFC5348" target="https://www.rfc-editor.org/info/rfc5
348">
<front>
<title>TCP Friendly Rate Control (TFRC): Protocol Specification</tit
le>
<author initials="S." surname="Floyd" fullname="S. Floyd">
<organization/>
</author>
<author initials="M." surname="Handley" fullname="M. Handley">
<organization/>
</author>
<author initials="J." surname="Padhye" fullname="J. Padhye">
<organization/>
</author>
<author initials="J." surname="Widmer" fullname="J. Widmer">
<organization/>
</author>
<date year="2008" month="September"/>
<abstract>
<t>This 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 T
CP flows, but has a much lower variation of throughput over time compared with T
CP, making it more suitable for applications such as streaming media where a rel
atively smooth sending rate is of importance.</t>
<t>This document obsoletes RFC 3448 and updates RFC 4342. [STANDA
RDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5348"/>
<seriesInfo name="DOI" value="10.17487/RFC5348"/>
</reference>
</references> </references>
</references> </references>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Examples</name> <name>Examples</name>
<t>The following examples show configuration and operational data for the IKE-less and IKE cases <t>The following examples show configuration and operational data for the IKE-less and IKE cases
using XML and JSON. Also, the operational statistics for the IKE-less case using XML and JSON. Also, the operational statistics for the IKE-less case
is illustrated.</t> is illustrated.</t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Example XML Configuration</name> <name>Example XML Configuration</name>
<t>This example illustrates configuration for IP-TFS in the IKE-less cas e. <t>This example illustrates configuration for IP-TFS in the IKE-less cas e.
Note that since this augments the IPsec IKE-less schema only minimal a IKE-less configuration Note that, since this augments the IPsec IKE-less schema, only a minimal IKE-les s configuration
to satisfy the schema has been populated.</t> to satisfy the schema has been populated.</t>
<figure anchor="sec-example-ip-tfs-xml-configuration"> <figure anchor="sec-example-ip-tfs-xml-configuration">
<name>Example IP-TFS XML configuration</name> <name>Example IP-TFS XML Configuration</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode type="xml"><![CDATA[
<i:ipsec-ikeless <i:ipsec-ikeless
xmlns:i="urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless" xmlns:i="urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless"
xmlns:tfs="urn:ietf:params:xml:ns:yang:ietf-ipsec-iptfs"> xmlns:tfs="urn:ietf:params:xml:ns:yang:ietf-ipsec-iptfs">
<i:spd> <i:spd>
<i:spd-entry> <i:spd-entry>
<i:name>protect-policy-1</i:name> <i:name>protect-policy-1</i:name>
<i:direction>outbound</i:direction> <i:direction>outbound</i:direction>
<i:ipsec-policy-config> <i:ipsec-policy-config>
<i:traffic-selector> <i:traffic-selector>
<i:local-prefix>192.0.2.0/16</i:local-prefix> <i:local-prefix>192.0.2.0/16</i:local-prefix>
skipping to change at line 1286 skipping to change at line 1015
<tfs:send-immediately>false</tfs:send-immediately> <tfs:send-immediately>false</tfs:send-immediately>
<tfs:lost-packet-timer-interval <tfs:lost-packet-timer-interval
>0.2</tfs:lost-packet-timer-interval> >0.2</tfs:lost-packet-timer-interval>
</tfs:traffic-flow-security> </tfs:traffic-flow-security>
</i:ipsec-sa-cfg> </i:ipsec-sa-cfg>
</i:processing-info> </i:processing-info>
</i:ipsec-policy-config> </i:ipsec-policy-config>
</i:spd-entry> </i:spd-entry>
</i:spd> </i:spd>
</i:ipsec-ikeless> </i:ipsec-ikeless>
]]></artwork> ]]></sourcecode>
</figure> </figure>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Example XML Operational Data</name> <name>Example XML Operational Data</name>
<t>This example illustrates operational data for IP-TFS in the IKE-less case. <t>This example illustrates operational data for IP-TFS in the IKE-less case.
Note that since this augments the IPsec IKE-less schema only minimal IKE-less co nfiguration Note that, since this augments the IPsec IKE-less schema only, a minimal IKE-les s configuration
to satisfy the schema has been populated.</t> to satisfy the schema has been populated.</t>
<figure anchor="sec-example-ip-tfs-xml-operational-data"> <figure anchor="sec-example-ip-tfs-xml-operational-data">
<name>Example IP-TFS XML Operational data</name> <name>Example IP-TFS XML Operational Data</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode type="xml"><![CDATA[
<i:ipsec-ikeless <i:ipsec-ikeless
xmlns:i="urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless" xmlns:i="urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless"
xmlns:tfs="urn:ietf:params:xml:ns:yang:ietf-ipsec-iptfs"> xmlns:tfs="urn:ietf:params:xml:ns:yang:ietf-ipsec-iptfs">
<i:sad> <i:sad>
<i:sad-entry> <i:sad-entry>
<i:name>sad-1</i:name> <i:name>sad-1</i:name>
<i:ipsec-sa-config> <i:ipsec-sa-config>
<i:spi>1</i:spi> <i:spi>1</i:spi>
<i:traffic-selector> <i:traffic-selector>
<i:local-prefix>2001:db8:1::/48</i:local-prefix> <i:local-prefix>2001:db8:1::/48</i:local-prefix>
skipping to change at line 1326 skipping to change at line 1055
<tfs:l2-fixed-rate>1000000000</tfs:l2-fixed-rate> <tfs:l2-fixed-rate>1000000000</tfs:l2-fixed-rate>
<tfs:max-aggregation-time>0.100</tfs:max-aggregation-time> <tfs:max-aggregation-time>0.100</tfs:max-aggregation-time>
<tfs:window-size>0</tfs:window-size> <tfs:window-size>0</tfs:window-size>
<tfs:send-immediately>true</tfs:send-immediately> <tfs:send-immediately>true</tfs:send-immediately>
<tfs:lost-packet-timer-interval <tfs:lost-packet-timer-interval
>0.200</tfs:lost-packet-timer-interval> >0.200</tfs:lost-packet-timer-interval>
</tfs:traffic-flow-security> </tfs:traffic-flow-security>
</i:sad-entry> </i:sad-entry>
</i:sad> </i:sad>
</i:ipsec-ikeless> </i:ipsec-ikeless>
]]></artwork> ]]></sourcecode>
</figure> </figure>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Example JSON Configuration</name> <name>Example JSON Configuration</name>
<t>This example illustrates config data for IP-TFS in the IKE case. <t>This example illustrates configuration data for IP-TFS in the IKE cas
Note that since this augments the IPsec IKE schema only minimal ike configuratio e.
n Note that, since this augments the IPsec IKE schema, only a minimal IKE configur
ation
to satisfy the schema has been populated.</t> to satisfy the schema has been populated.</t>
<figure anchor="sec-example-ip-tfs-json-configuration"> <figure anchor="sec-example-ip-tfs-json-configuration">
<name>Example IP-TFS JSON configuration</name> <name>Example IP-TFS JSON Configuration</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode name="" type="json"><![CDATA[
{ {
"ietf-i2nsf-ike:ipsec-ike": { "ietf-i2nsf-ike:ipsec-ike": {
"ietf-i2nsf-ike:conn-entry": [ "ietf-i2nsf-ike:conn-entry": [
{ {
"name": "my-peer-connection", "name": "my-peer-connection",
"ike-sa-encr-alg": [ "ike-sa-encr-alg": [
{ {
"id": 1, "id": 1,
"algorithm-type": 12, "algorithm-type": 12,
"key-length": 128 "key-length": 128
skipping to change at line 1388 skipping to change at line 1117
} }
} }
} }
} }
] ]
} }
} }
] ]
} }
} }
]]></artwork> ]]></sourcecode>
</figure> </figure>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Example JSON Operational Data</name> <name>Example JSON Operational Data</name>
<t>This example illustrates operational data for IP-TFS in the IKE case. <t>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 Note that, since this augments the IPsec IKE tree, only a minimal IKE configurat ion
to satisfy the schema has been populated.</t> to satisfy the schema has been populated.</t>
<figure anchor="sec-example-ip-tfs-json-operational-data"> <figure anchor="sec-example-ip-tfs-json-operational-data">
<name>Example IP-TFS JSON Operational data</name> <name>Example IP-TFS JSON Operational Data</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode type="json"><![CDATA[
{ {
"ietf-i2nsf-ike:ipsec-ike": { "ietf-i2nsf-ike:ipsec-ike": {
"ietf-i2nsf-ike:conn-entry": [ "ietf-i2nsf-ike:conn-entry": [
{ {
"name": "my-peer-connection", "name": "my-peer-connection",
"ike-sa-encr-alg": [ "ike-sa-encr-alg": [
{ {
"id": 1, "id": 1,
"algorithm-type": 12, "algorithm-type": 12,
"key-length": 128 "key-length": 128
skipping to change at line 1434 skipping to change at line 1163
"max-aggregation-time": "0.1", "max-aggregation-time": "0.1",
"window-size": 5, "window-size": 5,
"send-immediately": false, "send-immediately": false,
"lost-packet-timer-interval": "0.2" "lost-packet-timer-interval": "0.2"
} }
} }
} }
] ]
} }
} }
]]></artwork> ]]></sourcecode>
</figure> </figure>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Example JSON Operational Statistics</name> <name>Example JSON Operational Statistics</name>
<t>This example shows the JSON formatted statistics for IP-TFS. <t>This example shows the JSON formatted statistics for IP-TFS.
Note a unidirectional IP-TFS transmit side is illustrated, with arbitrary number s for transmit.</t> Note a unidirectional IP-TFS transmit side is illustrated, with arbitrary number s for transmit.</t>
<figure anchor="sec-example-ip-tfs-json-statistics"> <figure anchor="sec-example-ip-tfs-json-statistics">
<name>Example IP-TFS JSON Statistics</name> <name>Example IP-TFS JSON Statistics</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode type="json"><![CDATA[
{ {
"ietf-i2nsf-ikeless:ipsec-ikeless": { "ietf-i2nsf-ikeless:ipsec-ikeless": {
"sad": { "sad": {
"sad-entry": [ "sad-entry": [
{ {
"name": "sad-1", "name": "sad-1",
"ipsec-sa-config": { "ipsec-sa-config": {
"spi": 1, "spi": 1,
"traffic-selector": { "traffic-selector": {
"local-prefix": "192.0.2.1/16", "local-prefix": "192.0.2.1/16",
skipping to change at line 1502 skipping to change at line 1231
"bytes": "400606", "bytes": "400606",
"packets": 1000, "packets": 1000,
"idle": 5 "idle": 5
} }
} }
} }
] ]
} }
} }
} }
]]></artwork> ]]></sourcecode>
</figure> </figure>
</section> </section>
</section> </section>
<section numbered="false" toc="default">
<name>Acknowledgements</name>
<t>The authors would like to thank <contact fullname="Eric Kinzie"/>, <con
tact fullname="Jürgen Schönwälder"/>, <contact fullname="Lou Berger"/>, and <con
tact fullname="Tero Kivinen"/>
for their feedback and review on the YANG module.</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 124 change blocks. 
664 lines changed or deleted 312 lines changed or added

This html diff was produced by rfcdiff 1.48.