rfc9061xml2.original.xml   rfc9061.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!-- $Id: draft-ietf-i2nsf-sdn-ipsec-flow-protection-14.xml,v 1.5 2020/10/07 06: <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
27:15 Exp $ -->
<!-- This template is for creating an Internet Draft using xml2rfc, <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
which is available here: http://xml.resource.org. --> -ietf-i2nsf-sdn-ipsec-flow-protection-14" number="9061" obsoletes="" updates=""
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ submissionType="IETF" category="std" consensus="true" xml:lang="en" tocInclude="
<!-- One method to get references from the online citation libraries. true" tocDepth="3" symRefs="true" sortRefs="true" version="3">
There has to be one entity for each item to be referenced. <!-- xml2rfc v2v3 conversion 3.7.0 -->
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.2119.xml">
<!ENTITY RFC2865 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.2865.xml">
<!ENTITY RFC2866 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.2866.xml">
<!ENTITY RFC3575 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.3575.xml">
<!ENTITY RFC3579 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.3579.xml">
<!ENTITY RFC4849 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.4849.xml">
<!ENTITY RFC5080 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.5080.xml">
<!ENTITY RFC5226 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.5226.xml">
<!ENTITY RFC7149 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.7149.xml">
<!ENTITY RFC4301 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.4301.xml">
<!ENTITY RFC6071 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.6071.xml">
<!ENTITY RFC2367 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.2367.xml">
<!ENTITY RFC3549 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.3549.xml">
<!ENTITY RFC3948 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.3948.xml">
<!ENTITY RFC6437 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.6437.xml">
<!ENTITY RFC7296 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.7296.xml">
<!ENTITY RFC8229 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.8229.xml">
<!ENTITY RFC8192 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.8192.xml">
<!ENTITY RFC7426 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.7426.xml">
<!ENTITY RFC8329 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.8329.xml">
<!ENTITY RFC6020 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.6020.xml">
<!ENTITY RFC3688 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.3688.xml">
<!ENTITY RFC8446 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.8446.xml">
<!ENTITY RFC6241 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.6241.xml">
<!ENTITY RFC6242 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.6242.xml">
<!ENTITY RFC8341 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.8341.xml">
<!ENTITY RFC8040 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.8040.xml">
<!ENTITY RFC8247 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.8247.xml">
<!ENTITY RFC7950 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.7950.xml">
<!ENTITY RFC8342 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.8342.xml">
<!ENTITY RFC8340 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.8340.xml">
<!ENTITY RFC2247 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.2247.xml">
<!ENTITY RFC3947 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.3947.xml">
<!ENTITY RFC4303 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.4303.xml">
<!ENTITY RFC5280 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.5280.xml">
<!ENTITY RFC5915 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.5915.xml">
<!ENTITY RFC6040 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.6040.xml">
<!ENTITY RFC6991 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.6991.xml">
<!ENTITY RFC7383 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.7383.xml">
<!ENTITY RFC7427 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.7427.xml">
<!ENTITY RFC7619 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.7619.xml">
<!ENTITY RFC8017 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.8017.xml">
<!ENTITY RFC8174 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.8174.xml">
<!ENTITY RFC8221 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.8221.xml">
<!ENTITY RFC5322 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.5322.xml">
<!ENTITY RFC8221 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.3280.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), pleas
e see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds
might want to use. (Here they are set differently than their defaults in xml2rf
c v1.32) -->
<!-- <?rfc strict="yes" ?> -->
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="3"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<?rfc inline="yes"?>
<?rfc strict="no"?>
<?rfc rfcedstyle="yes"?>
<rfc ipr="trust200902" category="std" docName="draft-ietf-i2nsf-sdn-ipsec-flow-p
rotection-14">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front> <front>
<!-- The abbreviated title is used in the page header - it is only neces <title abbrev="IPsec Flow Protection Based on SDN">A YANG Data Model for
sary if the IPsec Flow Protection Based on Software-Defined Networking (SDN)</title>
full title is longer than 39 characters --> <seriesInfo name="RFC" value="9061"/>
<title abbrev="SDN-based IPsec Flow Protection"> Software-Defined Networ
king (SDN)-based IPsec Flow Protection</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Rafa Marin-Lopez" initials="R." surname="Marin-Lopez"> <author fullname="Rafa Marin-Lopez" initials="R." surname="Marin-Lopez">
<organization>University of Murcia</organization> <organization>University of Murcia</organization>
<address> <address>
<postal> <postal>
<street>Campus de Espinardo S/N, Faculty of Computer Science <extaddr>Faculty of Computer Science</extaddr>
</street> <street>Campus de Espinardo S/N</street>
<!-- Reorder these if your country does things differently - <region>Murcia</region>
-> <code>30100</code>
<city>Murcia</city> <country>Spain</country>
<region/> </postal>
<code>30100</code> <phone>+34 868 88 85 01</phone>
<country>Spain</country> <email>rafa@um.es</email>
</postal>
<phone>+34 868 88 85 01</phone>
<email>rafa@um.es</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<author fullname="Gabriel Lopez-Millan" initials="G." surname="Lopez-Mil <author fullname="Gabriel Lopez-Millan" initials="G." surname="Lopez-Millan"
lan"> >
<organization>University of Murcia</organization> <organization>University of Murcia</organization>
<address> <address>
<postal> <postal>
<street>Campus de Espinardo S/N, Faculty of Computer Science <extaddr>Faculty of Computer Science</extaddr>
</street> <street>Campus de Espinardo S/N</street>
<!-- Reorder these if your country does things differently - <region>Murcia</region>
-> <code>30100</code>
<city>Murcia</city> <country>Spain</country>
<region/> </postal>
<code>30100</code> <phone>+34 868 88 85 04</phone>
<country>Spain</country> <email>gabilm@um.es</email>
</postal>
<phone>+34 868 88 85 04</phone>
<email>gabilm@um.es</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<author fullname="Fernando Pereniguez-Garcia" initials="F." surname="Per <author fullname="Fernando Pereniguez-Garcia" initials="F." surname="Perenig
eniguez-Garcia"> uez-Garcia">
<organization>University Defense Center</organization> <organization>University Defense Center</organization>
<address> <address>
<postal> <postal>
<street>Spanish Air Force Academy, MDE-UPCT</street> <extaddr>Spanish Air Force Academy</extaddr>
<!-- Reorder these if your country does things differently - <street>MDE-UPCT</street>
-> <city>San Javier</city>
<city>San Javier (Murcia)</city> <region>Murcia</region>
<region/> <code>30720</code>
<code>30720</code> <country>Spain</country>
<country>Spain</country> </postal>
</postal> <phone>+34 968 18 99 46</phone>
<phone>+34 968 18 99 46</phone> <email>fernando.pereniguez@cud.upct.es</email>
<email>fernando.pereniguez@cud.upct.es</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<date month="March" year="2021"/> <date month="June" year="2021"/>
<!-- If the month and year are both specified and are the current ones,
xml2rfc will fill
in the current day for you. If only the current year is specified, xml2
rfc will fill
in the current day and month for you. If the year is not the current one, i
t is
necessary to specify at least a month (xml2rfc assumes day="1" if not speci
fied for the
purpose of calculating the expiry date). With drafts it is normally suffic
ient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>General</area> <area>General</area>
<workgroup>I2NSF</workgroup> <workgroup>I2NSF</workgroup>
<!-- WG name at the upperleft corner of the doc, <keyword>NSF</keyword>
IETF is fine for individual submissions. <keyword>SDN</keyword>
If this element is not present, the default is "Network Working Group", <keyword>IPsec</keyword>
which is used by the RFC Editor as a nod to the history of the IETF. --
>
<keyword>NSF, SDN, IPsec</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract> <abstract>
<t>This document describes how to provide IPsec-based <t>This document describes how to provide IPsec-based
flow protection (integrity and confidentiality) by means flow protection (integrity and confidentiality) by means
of an Interface to Network Security Function (I2NSF) of an Interface to Network Security Function (I2NSF)
controller. It considers two main well-known scenarios Controller. It considers two main well-known scenarios
in IPsec: (i) gateway-to-gateway and (ii) host-to-host. in IPsec: gateway-to-gateway and host-to-host.
The service described in this document allows the The service described in this document allows the
configuration and monitoring of IPsec Security configuration and monitoring of IPsec Security
Associations (IPsec SAs) from a I2NSF Controller to one Associations (IPsec SAs) from an I2NSF Controller to one
or several flow-based Network Security Functions (NSFs) or several flow-based Network Security Functions (NSFs)
that rely on IPsec to protect data traffic. that rely on IPsec to protect data traffic.
</t> </t>
<t> The document focuses on the I2NSF NSF-facing <t> This document focuses on the I2NSF NSF-Facing
Interface by providing YANG data models for configuring Interface by providing YANG data models for configuring
the IPsec databases, namely Security Policy Database the IPsec databases, namely Security Policy Database
(SPD), Security Association Database (SAD), Peer (SPD), Security Association Database (SAD), Peer
Authorization Database (PAD), and IKEv2. This allows Authorization Database (PAD), and Internet Key Exchange
IPsec SA establishment Version 2 (IKEv2). This allows IPsec SA establishment
with minimal intervention by the network administrator. It defin with minimal intervention by the network administrator.
es three YANG modules but it does not define any new protocol. This document defines three YANG modules, but it does not define any
</t> new protocol.
</abstract> </t>
</front> </abstract>
<middle> </front>
<section anchor="intro" title="Introduction"> <middle>
<t> <section anchor="intro" numbered="true" toc="default">
<name>Introduction</name>
<t>
Software-Defined Networking (SDN) is an architecture Software-Defined Networking (SDN) is an architecture
that enables administrators to directly program, that enables administrators to directly program,
orchestrate, control and manage network resources orchestrate, control, and manage network resources
through software. through software.
The SDN paradigm relocates the control of network The SDN paradigm relocates the control of network
resources to a centralized entity, namely the SDN resources to a centralized entity, namely the SDN
Controller. Controller.
SDN controllers configure and manage distributed SDN Controllers configure and manage distributed
network network
resources and provide an abstracted view of the resources and provide an abstracted view of the
network network
resources to SDN applications. resources to SDN applications.
SDN applications can customize and automate the SDN applications can customize and automate the
operations operations
(including management) of the abstracted network (including management) of the abstracted network
resources in a programmable manner via this interface <xref targ resources in a programmable manner via this interface <xref targ
et="RFC7149"/> et="RFC7149" format="default"/>
<xref target="ITU-T.Y.3300"/> <xref target="ITU-T.Y.3300" format="default"/>
<xref target="ONF-SDN-Architecture"/> <xref target="ONF-SDN-Architecture" format="default"/>
<xref target="ONF-OpenFlow"/>. <xref target="ONF-OpenFlow" format="default"/>.
</t> </t>
<t> <t>
Recently, several network scenarios now demand a centralized Recently, several network scenarios now demand a centralized
way of managing different security aspects, for example, way of managing different security aspects, for example,
Software-Defined WANs (SD-WANs). SD-WANs are an SDN extension Software-Defined WANs (SD-WANs). SD-WANs are SDN extensions
providing a software abstraction to create secure network providing software abstractions to create secure network
overlays over traditional WAN and branch networks. SD-WANs overlays over traditional WAN and branch networks. SD-WANs
utilize IPsec <xref target="RFC4301"/> as an underlying utilize IPsec <xref target="RFC4301" format="default"/> as an un derlying
security protocol. The goal of SD-WANs is to provide flexible security protocol. The goal of SD-WANs is to provide flexible
and automated deployment from a centralized point to enable and automated deployment from a centralized point to enable
on-demand network security services such as IPsec Security on-demand network security services, such as IPsec Security
Association (IPsec SA) management. Association (IPsec SA) management.
Additionally, Section 4.3.3 in <xref target="RFC8192"/> Additionally, Section <xref target="RFC8192" sectionFormat="bare
describes another example use case for Cloud Data Center "
Scenario titled "Client-Specific Security Policy in Cloud section="4.3.3">"Client-Specific Security Policy in Cloud
VPNs". The use case in RFC 8192 states that "dynamic key VPNs"</xref> of <xref target="RFC8192"/>
describes another example use case for a cloud data center
scenario. The use case in <xref target="RFC8192" format="default
"/> states that "dynamic key
management is critical for securing the VPN and the management is critical for securing the VPN and the
distribution of policies". These VPNs can be established using distribution of policies". These VPNs can be established using
IPsec. The management of IPsec SAs in data centers using a IPsec. The management of IPsec SAs in data centers using a
centralized entity is a scenario where the current centralized entity is a scenario where the current
specification may be applicable. specification may be applicable.
</t> </t>
<t>
<t>
Therefore, with the growth of SDN-based scenarios where Therefore, with the growth of SDN-based scenarios where
network resources are deployed in an autonomous manner, network resources are deployed in an autonomous manner,
a mechanism to manage IPsec SAs from a centralized entity a mechanism to manage IPsec SAs from a centralized entity
becomes more relevant in the industry. becomes more relevant in the industry.
</t> </t>
<t> In response to this need, the Interface to Network Security
<t> In response to this need, the Interface to Network Security
Functions (I2NSF) charter states that the goal of this Functions (I2NSF) charter states that the goal of this
working group is "to define set of software interfaces and working group is "to define a set of software interfaces and
YANG data models for controlling and monitoring aspects of data models for controlling and monitoring aspects of
physical and virtual Network Security Functions". As defined physical and virtual NSFs". As defined
in <xref target="RFC8192"/> an Network Security Function (NSF) i in <xref target="RFC8192" format="default"/>, a Network Security
s "a function Function (NSF) is "a function
that is used to ensure integrity, confidentiality, or that is used to ensure integrity, confidentiality, or
availability of network communication; to detect availability of network communication; to detect
unwanted network activity; or to block, or at least unwanted network activity; or to block, or at least
mitigate, the effects of unwanted activity". This document mitigate, the effects of unwanted activity". This document
pays special attention to flow-based NSFs that ensure pays special attention to flow-based NSFs that ensure
integrity and confidentiality by means of IPsec.</t> integrity and confidentiality by means of IPsec.</t>
<t> In fact, <xref target="RFC8192" sectionFormat="of" section="3
<t> In fact, as Section 3.1.9 in <xref target="RFC8192"/> states .1.9"/> states that
"there is a need for a controller to create, manage, "there is a need for a controller to create, manage,
and distribute various keys to distributed NSFs.", however and distribute various keys to distributed NSFs"; however,
"there is a lack of a standard interface to provision "there is a lack of a standard interface to provision
and manage security associations". Inspired by the SDN and manage security associations". Inspired by the SDN
paradigm, the I2NSF framework <xref target="RFC8329"/> paradigm, the I2NSF framework <xref target="RFC8329" format="def ault"/>
defines a centralized entity, the I2NSF Controller, defines a centralized entity, the I2NSF Controller,
which manages one or multiple NSFs through a which manages one or multiple NSFs through an
I2NSF NSF-Facing Interface. In this I2NSF NSF-Facing Interface. In this
document an architecture is defined for allowing the I2NSF Contr oller to document, an architecture is defined for allowing the I2NSF Cont roller to
carry out the key management procedures. More specifically, carry out the key management procedures. More specifically,
three YANG data models are defined for the I2NSF NSF-Facing Inte three YANG data models are defined for the I2NSF NSF-Facing Inte
rface that rface, which
allow the I2NSF Controller to configure allows the I2NSF Controller to configure
and monitor IPsec-enabled flow-based NSFs.</t> and monitor IPsec-enabled, flow-based NSFs.</t>
<t>The IPsec architecture <xref target="RFC4301" format="default"/> define
<t>The IPsec architecture <xref target="RFC4301"/> defines s
a clear separation between the processing to provide a clear separation between the processing to provide
security services to IP packets and the key management security services to IP packets and the key management
procedures to establish the IPsec SAs, procedures to establish the IPsec SAs,
which allows centralizing the key management procedures which allows centralizing the key management procedures
in the I2NSF Controller. in the I2NSF Controller.
This document considers two typical scenarios to This document considers two typical scenarios to
autonomously manage IPsec SAs: gateway-to-gateway and autonomously manage IPsec SAs: gateway-to-gateway and
host-to-host <xref target="RFC6071"/>. In these cases, host-to-host <xref target="RFC6071" format="default"/>. In these
hosts, gateways or both may act as NSFs. Due to its cases,
hosts, gateways, or both may act as NSFs. Due to its
complexity, consideration for the host-to-gateway complexity, consideration for the host-to-gateway
scenario is out of scope. The source of this scenario is out of scope. The source of this
complexity comes from the fact that, in this complexity comes from the fact that, in this
scenario, the host may not be under the control of scenario, the host may not be under the control of
the I2NSF controller and, therefore, it is not the I2NSF Controller and, therefore, it is not
configurable. Nevertheless, the I2NSF interfaces configurable. Nevertheless, the I2NSF interfaces
defined in this document can be considered as a defined in this document can be considered as a
starting starting
point to analyze and provide a solution for the point to analyze and provide a solution for the
host-to-gateway scenario.</t> host-to-gateway scenario.</t>
<t> For the definition of the YANG data models for the I2NSF
<t> For the definition of the YANG data models for I2NSF
NSF-Facing Interface, this document considers NSF-Facing Interface, this document considers
two general cases, namely: two general cases, namely:</t>
<list style="format %d)"> <ol spacing="normal" type="1">
<t> IKE case. The NSF <li> IKE case. The NSF
implements the Internet Key Exchange version 2 (IKEv2) implements the Internet Key Exchange Version 2 (IKEv2)
protocol and the IPsec databases: the Security protocol and the IPsec databases: the Security
Policy Database (SPD), the Security Association Policy Database (SPD), the Security Association
Database (SAD) and the Peer Authorization Database Database (SAD), and the Peer Authorization Database
(PAD). The I2NSF Controller is in charge of (PAD). The I2NSF Controller is in charge of
provisioning the NSF with the required information provisioning the NSF with the required information
in the SPD and PAD (e.g., IKE credentials), and for the in the SPD and PAD (e.g., IKE credentials) and the
IKE protocol itself (e.g., parameters for the IKE_SA_INIT IKE protocol itself (e.g., parameters for the IKE_SA_INIT
negotiation). negotiation).</li>
</t> <li> IKE-less case. The NSF only implements the IPsec
<t> IKE-less case. The NSF only implements the IPsec
databases (no IKE implementation). databases (no IKE implementation).
The I2NSF Controller will provide the required The I2NSF Controller will provide the required
parameters to create valid entries in the SPD and parameters to create valid entries in the SPD and
the SAD of the NSF. Therefore, the NSF will only have the SAD of the NSF. Therefore, the NSF will only have
support for IPsec while key management support for IPsec whereas key management
functionality is moved to the I2NSF Controller. functionality is moved to the I2NSF Controller.</li>
</t> </ol>
</list> <t> In both cases, a YANG data model for the I2NSF NSF-Facing
</t>
<t> In both cases, a YANG data model for the I2NSF NSF-Facing
Interface is required to carry out this provisioning Interface is required to carry out this provisioning
in a secure manner between the I2NSF Controller and the NSF. in a secure manner between the I2NSF Controller and the NSF.
<!--In particular, the IKE case requires the provision Using YANG data modeling language version 1.1 <xref target="RFC7
of SPD and PAD entries, the IKE credential and 950" format="default"/> and
information related with the IKE negotiation based on YANG data models defined in <xref target="netconf-vpn"
(e.g. IKE_SA_INIT). --> format="default"/> and
Using YANG data modelling language version 1.1 <xref target="RFC <xref target="I-D.tran-ipsecme-yang" format="default"/> and the
7950"/> and data structures defined
based on YANG data models defined in <xref target="netconf-vpn"/ in <xref target="RFC4301" format="default"/> and
>, <xref target="RFC7296" format="default"/>, this document defines
<xref target="I-D.tran-ipsecme-yang"/>, an the data structures d the
efined in RFC 4301 <xref target="RFC4301"/> and RFC 7296
<xref target="RFC7296"/>, this document defines the
required interfaces with a YANG data model for configuration required interfaces with a YANG data model for configuration
and state data for IKE, PAD, SPD and SAD and state data for IKE, PAD, SPD, and SAD
(see <xref target="ike-common-model"/>, (see Sections <xref target="ike-common-model" format="counter"/>
<xref target="ike-case-model"/> and ,
<xref target="ike-less-model"/>). <xref target="ike-case-model" format="counter"/>, and
<xref target="ike-less-model" format="counter"/>).
The proposed YANG data model conforms to the Network Management The proposed YANG data model conforms to the Network Management
Datastore Architecture (NMDA) defined in <xref target="RFC8342"/ Datastore Architecture (NMDA) defined in <xref target="RFC8342"
>. format="default"/>.
Examples of the usage of these data models can be found in <xref Examples of the usage of these data models can be found in Appen
target="appendix-d"/>, dices <xref target="appendix-d" format="counter"/>,
<xref target="appendix-e"/> <xref target="appendix-e" format="counter"/>,
and <xref target="appendix-f"/>. and <xref target="appendix-f" format="counter"/>.
</t> </t>
<!-- <t>
This document considers two typical scenarios to manage
autonomously IPsec SAs: gateway-to-gateway and
host-to-host <xref target="RFC6071" />. In these cases,
hosts, gateways or both may act as NSFs. Consideration
for the host-to-gateway scenario is out of scope of
this document.
</t> -->
<!--<t>
Finally, this work pays attention to the challenge "Lack
of Mechanism for Dynamic Key Distribution to NSFs"
defined in <xref target="RFC8192" /> in the particular
case of the establishment and management of IPsec SAs.
In fact,this I-D could be considered as a proper use
case for this particular challenge in
<xref target="RFC8192" />.
</t>-->
<t> In summary, the objectives of this document are:</t> <t> In summary, the objectives of this document are:</t>
<t> <ul spacing="normal">
<list style="symbols"> <li> To describe the architecture for I2NSF-based
<t> To describe the architecture for I2NSF-based IPsec management, which allows for the
IPsec management, which allows the
establishment and management of IPsec establishment and management of IPsec
security associations from the I2NSF Security Associations from the I2NSF
Controller in order to protect specific data Controller in order to protect specific data
flows between two flow-based NSFs flows between two flow-based NSFs
implementing IPsec.</t> implementing IPsec.</li>
<t>To map this architecture to the I2NSF <li>To map this architecture to the I2NSF
Framework.</t> framework.</li>
<t>To define the interfaces required to manage <li>To define the interfaces required to manage
and monitor the IPsec SAs in the NSF from a and monitor the IPsec SAs in the NSF from an
I2NSF Controller. YANG data models are I2NSF Controller. YANG data models are
defined for configuration and state data for defined for configuration and state data for
IPsec and IKEv2 management through the I2NSF IPsec and IKEv2 management through the I2NSF
NSF-Facing Interface. The YANG models can be NSF-Facing Interface. The YANG data models can be
used via existing protocols such as NETCONF used via existing protocols, such as the Network Configuration Protoco
<xref target="RFC6241"/> or RESTCONF l (NETCONF)
<xref target="RFC8040"/>. Thus, this <xref target="RFC6241" format="default"/> or RESTCONF
<xref target="RFC8040" format="default"/>. Thus, this
document defines three YANG modules (see document defines three YANG modules (see
<xref target="models"/>) but does not define any new <xref target="models" format="default"/>) but does not define any new
protocol.</t> protocol.</li>
</list> </ul>
</t> </section>
</section> <section anchor="notation" numbered="true" toc="default">
<section title="Requirements Language"> <name>Terminology</name>
<t> <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 BCP 14
<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 anchor="notation" title="Terminology">
<t>
This document uses the terminology described in This document uses the terminology described in
<xref target="RFC8329"/>, <xref target="RFC8192"/>, <xref target="ITU-T.Y.3300" format="default"/>, <xref target="RFC
<xref target="RFC4301"/>,<xref target="RFC7296"/>, 8192" format="default"/>,
<xref target="RFC6241"/>, <xref target="RFC4301" format="default"/>, <xref target="RFC6437"
<xref target="ITU-T.Y.3300"/>. format="default"/>,
<xref target="RFC7296" format="default"/>, <xref target="RFC6241"
<!--<xref target="ONF-SDN-Architecture"/>, format="default"/>, and
<xref target="ONF-OpenFlow"/>, <xref target="RFC8329" format="default"/>. </t>
<t>The following term is defined in <xref target="ITU-T.Y.3300" format="de
<xref target="ITU-T.X.1252"/>, fault"/>:</t>
<ul spacing="normal">
and <xref target="ITU-T.X.800"/>. <li>Software-Defined Networking (SDN)</li>
</ul>
<xref target="RFC7149"/>--> <t>The following terms are defined in <xref target="RFC8192" format="defau
lt"/>:</t>
The following term is defined in <xref target="ITU-T.Y.3300"/>: <ul spacing="normal">
<li>Network Security Function (NSF)</li>
<list style="symbols"> <li>flow-based NSF</li>
<t> </ul>
Software-Defined Networking. <t>The following terms are defined in <xref target="RFC4301" format="defau
</t> lt"/>:</t>
</list> <ul spacing="normal">
<li>Peer Authorization Database (PAD)</li>
The following terms are defined in <xref target="RFC8192"/>: <li>Security Association Database (SAD)</li>
<li>Security Policy Database (SPD)</li>
<list style="symbols"> </ul>
<t>The following two terms are related or
<t>NSF.</t> have identical definition/usage in <xref target="RFC6437" format="defau
<t>Flow-based NSF.</t> lt"/>:</t>
</list> <ul spacing="normal">
<li>flow</li>
The following terms are defined in <xref target="RFC4301"/>: <li>traffic flow</li>
</ul>
<list style="symbols"> <t>The following term is defined in <xref target="RFC7296" format="default
<t> "/>:</t>
Peer Authorization Database (PAD). <ul spacing="normal">
</t> <li>Internet Key Exchange Version 2 (IKEv2)</li>
<t> </ul>
Security Associations Database (SAD). <t>The following terms are defined in <xref target="RFC6241" format="defau
</t> lt"/>: </t>
<t> <ul spacing="normal">
Security Policy Database (SPD). <li>configuration data</li>
</t> <li>configuration datastore</li>
<li>state data</li>
</list> <li>startup configuration datastore</li>
<li>running configuration datastore</li>
The following two terms that are related or </ul>
have identical definition/usage in <xref target="RFC6437"/>: <section numbered="true" toc="default">
<name>Requirements Language</name>
<list style="symbols"> <t>
<t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
Flow or traffic flow. IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
</t> NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
</list> RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
The following term is defined in <xref target="RFC7296"/>: be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
<list style="symbols"> when, and only when, they appear in all capitals, as shown here.
<t> </t>
Internet Key Exchange version 2 (IKEv2). </section>
</t> </section>
</list> <section anchor="cases" numbered="true" toc="default">
<name>SDN-Based IPsec Management Description</name>
<!--<t> <t> As mentioned in <xref target="intro" format="default"/>, two cases are
Flow-based Protection Policy. The set of rules
defining the conditions under which a data flow
MUST be protected with IPsec, and the rules
that MUST be applied to the specific flow.
</t>-->
The following terms are defined in <xref target="RFC6241"/>:
<list style="symbols">
<t>
Configuration data.
</t><t>
Configuration datastore.
</t><t>
State data.
</t><t>
Startup configuration datastore.
</t><t>
Running configuration datastore.
</t>
</list>
</t>
</section>
<!-- Terminology -->
<section anchor="cases" title="SDN-based IPsec management description">
<t> As mentioned in <xref target="intro"/>, two cases are
considered, depending on whether the NSF implements IKEv2 considered, depending on whether the NSF implements IKEv2
or not: the IKE case and the IKE-less case. </t> or not: the IKE case and the IKE-less case. </t>
<section anchor="case1" numbered="true" toc="default">
<section anchor="case1" title="IKE case: IKEv2/IPsec in the NSF"> <name>IKE Case: IKEv2/IPsec in the NSF</name>
<t> In this case, the NSF implements IPsec with <t> In this case, the NSF implements IPsec with
IKEv2 support. The I2NSF Controller is in IKEv2 support. The I2NSF Controller is in
charge of managing and applying IPsec connection charge of managing and applying IPsec connection
information (determining which nodes need to start an information (determining which nodes need to start an
IKEv2/IPsec session, identifying the type of traffic to be IKEv2/IPsec session, identifying the type of traffic to be
protected, deriving and delivering IKEv2 credentials such protected, and deriving and delivering IKEv2 credentials, su
as a pre-shared key, certificates, etc.), and applying ch
as a pre-shared key (PSK), certificates, etc.) and applying
other IKEv2 configuration parameters other IKEv2 configuration parameters
(e.g., cryptographic algorithms for establishing an IKEv2 (e.g., cryptographic algorithms for establishing an IKEv2
SA) to the NSF necessary for the IKEv2 negotiation. SA) to the NSF necessary for the IKEv2 negotiation.
</t> </t>
<t> With these entries, the IKEv2 implementation can operate <t> With these entries, the IKEv2 implementation can operate
to establish the IPsec SAs. The I2NSF User to establish the IPsec SAs. The I2NSF User
establishes the IPsec requirements and information about establishes the IPsec requirements and information about
the end points (through the I2NSF the endpoints (through the I2NSF
Consumer-Facing Interface, Consumer-Facing Interface
<xref target="RFC8329"/>), and the I2NSF Controller <xref target="RFC8329" format="default"/>), and the I2NSF Co
translates these requirements into IKEv2, SPD and PAD ntroller
translates these requirements into IKEv2, SPD, and PAD
entries that will be installed into the NSF (through the entries that will be installed into the NSF (through the
I2NSF NSF-Facing Interface). With that information, I2NSF NSF-Facing Interface). With that information,
the NSF can just run IKEv2 to establish the required the NSF can just run IKEv2 to establish the required
IPsec SA (when the traffic flow needs protection). IPsec SA (when the traffic flow needs protection).
<xref target="fig:nsf-architecture1"/> <xref target="fig_nsf-architecture1" format="default"/>
shows the different layers and corresponding functionality. shows the different layers and corresponding functionality.
</t> </t>
<!-- maximum wide of the figure <figure anchor="fig_nsf-architecture1">
--> <name>IKE Case: IKE/IPsec in the NSF</name>
<figure align="center" anchor="fig:nsf-architecture1" title="IKE <artwork align="center" name="" type="" alt=""><![CDATA[
case: IKE/IPsec in the NSF">
<artwork align="center">
<![CDATA[
+-------------------------------------------+ +-------------------------------------------+
| IPsec Management System | I2NSF User | IPsec Management System | I2NSF User
+-------------------------------------------+ +-------------------------------------------+
| |
| I2NSF Consumer-Facing | I2NSF Consumer-Facing
| Interface | Interface
+-------------------------------------------+ +-------------------------------------------+
| IKEv2 Configuration, PAD and SPD Entries | I2NSF | IKEv2 Configuration, PAD and SPD Entries | I2NSF
| Distribution | Controller | Distribution | Controller
+-------------------------------------------+ +-------------------------------------------+
| |
| I2NSF NSF-Facing | I2NSF NSF-Facing
| Interface | Interface
+-------------------------------------------+ +-------------------------------------------+
| IKEv2 | IPsec(PAD, SPD) | Network | IKEv2 | IPsec(PAD, SPD) | Network
|-------------------------------------------| Security |-------------------------------------------| Security
| IPsec Data Protection and Forwarding | Function | IPsec Data Protection and Forwarding | Function
+-------------------------------------------+ +-------------------------------------------+
]]> ]]></artwork>
</artwork> </figure>
</figure> <t>
<t>
I2NSF-based IPsec flow protection services provide I2NSF-based IPsec flow protection services provide
dynamic and flexible management of IPsec SAs in dynamic and flexible management of IPsec SAs in
flow-based NSFs. In order to support this capability flow-based NSFs. In order to support this capability
in the IKE case, a YANG data model for IKEv2, SPD and PAD in the IKE case, a YANG data model for IKEv2, SPD, and PAD
configuration data, and for IKEv2 state data configuration data and for IKEv2 state data
needs to be defined for needs to be defined for
the I2NSF NSF-Facing Interface (see <xref target="models"/>) the I2NSF NSF-Facing Interface (see <xref target="models" fo
.</t> rmat="default"/>).</t>
</section> </section>
<!-- "IKE case: IKE/IPsec in the NSF"" --> <section anchor="case2" numbered="true" toc="default">
<section anchor="case2" title="IKE-less case: IPsec (no IKEv2) in th <name>IKE-less Case: IPsec (No IKEv2) in the NSF</name>
e NSF."> <t>
<t>
In this case, the NSF does not deploy IKEv2 and, In this case, the NSF does not deploy IKEv2 and,
therefore, the I2NSF Controller has to perform the therefore, the I2NSF Controller has to perform the
IKEv2 security functions and management of IPsec SAs by IKEv2 security functions and management of IPsec SAs by
populating and managing the SPD and the SAD. populating and managing the SPD and the SAD.
</t> </t>
<t> <t>
As shown in <xref target="fig:nsf-architecture2"/>, As shown in <xref target="fig_nsf-architecture2" format="def
ault"/>,
when an I2NSF User enforces flow-based when an I2NSF User enforces flow-based
protection policies through the Consumer-Facing protection policies through the Consumer-Facing
Interface, the I2NSF Controller translates these Interface, the I2NSF Controller translates these
requirements into SPD and SAD entries, which are requirements into SPD and SAD entries, which are
installed in the NSF. PAD entries are not required since installed in the NSF. PAD entries are not required, since
there is no IKEv2 in the NSF. there is no IKEv2 in the NSF.
</t> </t>
<figure align="center" anchor="fig:nsf-architecture2" title="IKE <figure anchor="fig_nsf-architecture2">
-less case: IPsec (no IKEv2) in the NSF"> <name>IKE-less Case: IPsec (No IKEv2) in the NSF</name>
<artwork align="center"> <artwork align="center" name="" type="" alt=""><![CDATA[
<![CDATA[
+-----------------------------------------+ +-----------------------------------------+
| IPsec Management System | I2NSF User | IPsec Management System | I2NSF User
+-----------------------------------------+ +-----------------------------------------+
| |
| I2NSF Consumer-Facing Interface | I2NSF Consumer-Facing Interface
| |
+-----------------------------------------+ +-----------------------------------------+
| SPD and SAD Entries | I2NSF | SPD and SAD Entries | I2NSF
| Distribution | Controller | Distribution | Controller
+-----------------------------------------+ +-----------------------------------------+
| |
| I2NSF NSF-Facing Interface | I2NSF NSF-Facing Interface
| |
+-----------------------------------------+ +-----------------------------------------+
| IPsec (SPD, SAD) | Network | IPsec (SPD, SAD) | Network
|-----------------------------------------| Security |-----------------------------------------| Security
| IPsec Data Protection and Forwarding | Function | IPsec Data Protection and Forwarding | Function
+-----------------------------------------+ +-----------------------------------------+
]]></artwork>
]]> </figure>
</artwork> <t>
</figure>
<t>
In order to support the IKE-less case, a YANG data model In order to support the IKE-less case, a YANG data model
for SPD and SAD configuration data and SAD state data MUST for SPD and SAD configuration data and SAD state data <bcp14
be defined for the NSF-Facing Interface (see <xref target="m >MUST</bcp14>
odels"/>). be defined for the NSF-Facing Interface (see <xref target="m
</t> odels" format="default"/>).
<t> Specifically, the IKE-less case assumes that the I2NSF </t>
<t> Specifically, the IKE-less case assumes that the I2NSF
Controller has to perform some security functions that Controller has to perform some security functions that
IKEv2 typically does, namely (non-exhaustive):</t> IKEv2 typically does, namely (non-exhaustive list):</t>
<t> <ul spacing="normal">
<list style="symbols"> <li>Initialization Vector (IV) generation</li>
<t>IV generation.</t> <li>prevention of counter resets for the same key</li>
<t>Prevent counter resets for the same key.</t> <li>generation of pseudorandom cryptographic
<t>Generation of pseudo-random cryptographic keys for the IPsec SAs</li>
keys for the IPsec SAs.</t> <li>generation of the IPsec SAs when required
<t>Generation of the IPsec SAs when required based on notifications (i.e., sadb-acquire) from
based on notifications (i.e. sadb-acquire) from the NSF</li>
the NSF.</t> <li>rekey of the IPsec SAs based on notifications
<t>Rekey of the IPsec SAs based on notifications from the NSF (i.e., expire)</li>
from the NSF (i.e. expire).</t> <li>NAT traversal discovery and management</li>
<t>NAT Traversal discovery and management.</t> </ul>
</list> <t>Additionally to these functions, another set of tasks
</t>
<t>Additionally to these functions, another set of tasks
must be performed by the I2NSF Controller must be performed by the I2NSF Controller
(non-exhaustive list):</t> (non-exhaustive list):</t>
<t> <ul spacing="normal">
<list style="symbols"> <li>IPsec SA's Security Parameter Index (SPI) random generation</li>
<t>IPsec SA's SPI random generation.</t> <li>cryptographic algorithm selection</li>
<t>Cryptographic algorithm selection.</t> <li>usage of extended sequence numbers</li>
<t>Usage of extended sequence numbers.</t> <li>establishment of proper Traffic Selectors</li>
<t>Establishment of proper traffic </ul>
selectors.</t> </section>
</list> </section>
</t> <section anchor="comparison" numbered="true" toc="default">
</section> <name>IKE Case vs. IKE-less Case</name>
</section> <t>In principle, the IKE case is easier to deploy than the IKE-less
<!-- "IKE-less case: IPsec (no IKE) in the NSF" -->
<section anchor="comparison" title="IKE case vs IKE-less case">
<t>In principle, the IKE case is easier to deploy than the IKE-less
case because current flow-based NSFs (either hosts or gateways) case because current flow-based NSFs (either hosts or gateways)
have access to IKEv2 implementations. While gateways typically have access to IKEv2 implementations. While gateways typically
deploy an IKEv2/IPsec implementation, hosts can easily install it. deploy an IKEv2/IPsec implementation, hosts can easily install it.
As a downside, the NSF needs more resources to use IKEv2 such as As a downside, the NSF needs more resources to use IKEv2, such as
memory for the IKEv2 implementation, and computation, since each memory for the IKEv2 implementation and computation, since each
IPsec security association rekeying MAY involve a Diffie-Hellman IPsec Security Association rekeying <bcp14>MAY</bcp14> involve a Dif
fie-Hellman (DH)
exchange. exchange.
</t> </t>
<t>Alternatively, the IKE-less case benefits the <t>Alternatively, the IKE-less case benefits the
deployment in resource-constrained NSFs. Moreover, IKEv2 does not ne ed to be deployment in resource-constrained NSFs. Moreover, IKEv2 does not ne ed to be
performed in gateway-to-gateway and host-to-host scenarios performed in gateway-to-gateway and host-to-host scenarios
under the same I2NSF Controller (see under the same I2NSF Controller (see
<xref target="appendix-g1"/>). On the contrary, <xref target="appendix-g1" format="default"/>). On the contrary,
the complexity of creating and managing IPsec SAs is shifted the complexity of creating and managing IPsec SAs is shifted
to the I2NSF Controller since IKEv2 is not in the to the I2NSF Controller since IKEv2 is not in the
NSF. As a consequence, this may result in a more complex NSF. As a consequence, this may result in a more complex
implementation in the controller side in comparison with implementation in the controller side in comparison with the
IKE case. For example, the I2NSF Controller has to IKE case. For example, the I2NSF Controller has to
deal with the latency existing in the path between the deal with the latency existing in the path between the
I2NSF Controller and the NSF, in order to solve tasks I2NSF Controller and the NSF (in order to solve tasks,
such as rekey, or creation and installation of new IPsec such as rekey) or creation and installation of new IPsec
SAs. However, this is not specific to this SAs. However, this is not specific to this
contribution but a general aspect in any SDN-based contribution but a general aspect in any SDN-based
network. In summary, this complexity may create some network. In summary, this complexity may create some
scalability and performance issues when the number of NSFs scalability and performance issues when the number of NSFs
is high. is high.
</t> </t>
<t>Nevertheless, literature around SDN-based network management <t>Nevertheless, literature around SDN-based network management
using a centralized controller (like the I2NSF Controller) using a centralized controller (like the I2NSF Controller)
is aware of scalability and performance issues and solutions is aware of scalability and performance issues, and solutions
have been already provided and discussed (e.g., hierarchical have been already provided and discussed (e.g., hierarchical
controllers, having multiple replicated controllers, dedicated controllers, having multiple replicated controllers, dedicated
high-speed management networks, etc). In the context of high-speed management networks, etc.). In the context of
I2SNF-based IPsec management, one way to reduce the latency and I2NSF-based IPsec management, one way to reduce the latency and
alleviate some performance issues can be the installation of the alleviate some performance issues can be to install the
IPsec policies and IPsec SAs at the same time (proactive mode, IPsec policies and IPsec SAs at the same time (proactive mode,
as described in <xref target="appendix-g1"/>) as described in <xref target="appendix-g1" format="default"/>)
instead of waiting for notifications (e.g., a instead of waiting for notifications (e.g., a
sadb-acquire notification received from a NSF requiring a new IP sec SA) sadb-acquire notification received from an NSF requiring a new I Psec SA)
to proceed with the IPsec SA installation (reactive mode). to proceed with the IPsec SA installation (reactive mode).
Another way to reduce the overhead and the potential scalability Another way to reduce the overhead and the potential scalability
and performance issues in the I2NSF Controller is to apply the and performance issues in the I2NSF Controller is to apply the
IKE case described in this document, since the IPsec SAs are IKE case described in this document since the IPsec SAs are
managed between NSFs without the involvement of the I2NSF managed between NSFs without the involvement of the I2NSF
Controller at all, except by the initial configuration (i.e. Controller at all, except by the initial configuration (i.e.,
IKEv2, PAD and SPD entries) provided by the I2NSF Controller. IKEv2, PAD, and SPD entries) provided by the I2NSF Controller.
Other solutions, such as Controller-IKE Other solutions, such as Controller-IKE
<xref target="I-D.carrel-ipsecme-controller-ike"/>, <xref target="I-D.carrel-ipsecme-controller-ike" format="default "/>,
have proposed that NSFs provide their DH public keys to the have proposed that NSFs provide their DH public keys to the
I2NSF Controller, so that the I2NSF Controller I2NSF Controller so that the I2NSF Controller
distributes all public keys to all peers. All peers can distributes all public keys to all peers. All peers can
calculate a unique pairwise secret for each other peer and calculate a unique pairwise secret for each other peer, and
there is no inter-NSF messages. A rekey mechanism is there is no inter-NSF messages. A rekey mechanism is
further described in further described in
<xref target="I-D.carrel-ipsecme-controller-ike"/>. <xref target="I-D.carrel-ipsecme-controller-ike" format="default
</t> "/>.
<t>In terms of security, IKE case provides better </t>
security properties than IKE-less case, as discussed in <t>In terms of security, the IKE case provides better
<xref target="security"/>. The main reason is that the security properties than the IKE-less case, as discussed in
<xref target="security" format="default"/>. The main reason is that
the
NSFs generate the session keys and not the NSFs generate the session keys and not the
I2NSF Controller.</t> I2NSF Controller.</t>
<section anchor="rekeying" numbered="true" toc="default">
<section anchor="rekeying" title="Rekeying process"> <name>Rekeying Process</name>
<t>Performing a rekey for IPsec SAs is an important <t>Performing a rekey for IPsec SAs is an important
operation during the IPsec SAs management. With operation during the IPsec SAs management. With
the YANG data models defined in this the YANG data models defined in this
document the I2NSF Controller can configure document the I2NSF Controller can configure
parameters of the rekey process (IKE case) or parameters of the rekey process (IKE case) or
conduct the rekey process (IKE-less case). conduct the rekey process (IKE-less case).
Indeed, depending on the case, the rekey process Indeed, depending on the case, the rekey process
is different.</t> is different.</t>
<t>For the IKE case, the rekeying process is carried
<t>For the IKE case, the rekeying process is carried
out by IKEv2, following the information defined out by IKEv2, following the information defined
in the SPD and SAD (i.e. based on the IPsec SA in the SPD and SAD (i.e., based on the IPsec SA
lifetime established by the I2NSF Controller using the YANG lifetime established by the I2NSF Controller using the YANG
data model defined in this document). data model defined in this document).
Therefore, IPsec connections will live unless something Therefore, IPsec connections will live unless something
different is required by the I2NSF User or the I2NSF different is required by the I2NSF User or the I2NSF
Controller detects something wrong.</t> Controller detects something wrong.</t>
<t>For the IKE-less case, the
<t>For the IKE-less case, the I2NSF Controller <bcp14>MUST</bcp14> take care
I2NSF Controller MUST take care
of the rekeying process. When the IPsec SA is of the rekeying process. When the IPsec SA is
going to expire (e.g., IPsec SA soft lifetime), going to expire (e.g., IPsec SA soft lifetime),
it MUST create a new IPsec SA and it MAY remove the it <bcp14>MUST</bcp14> create a new IPsec SA and it <bcp14>M
old one (e.g. when the lifetime of the old IPsec SA has not AY</bcp14> remove the
been defined). old one (e.g., when the lifetime of the old IPsec SA has not
been defined).
This rekeying process starts when the This rekeying process starts when the
I2NSF Controller receives a sadb-expire I2NSF Controller receives a sadb-expire
notification or, on the I2NSF Controller's initiative, notification or, on the I2NSF Controller's initiative,
based on lifetime state data obtained from the NSF. based on lifetime state data obtained from the NSF.
How the I2NSF Controller implements an algorithm for How the I2NSF Controller implements an algorithm for
the rekey process is out of the scope of this document. the rekey process is out of the scope of this document.
Nevertheless, an example of how this rekey could be Nevertheless, an example of how this rekey could be
performed is described in <xref target="appendix-g2"/>.</t> performed is described in <xref target="appendix-g2" format="default"/
</section> >.</t>
</section>
<section anchor="restart" title="NSF state loss."> <section anchor="restart" numbered="true" toc="default">
<t>If one of the NSF restarts, it will lose the <name>NSF State Loss</name>
<t>If one of the NSF restarts, it will lose the
IPsec state (affected NSF). By default, the IPsec state (affected NSF). By default, the
I2NSF Controller can assume that all the I2NSF Controller can assume that all the
state has been lost and therefore it will have state has been lost and, therefore, it will have
to send IKEv2, SPD and PAD information to the to send IKEv2, SPD, and PAD information to the
NSF in the IKE case, and SPD and SAD information NSF in the IKE case and SPD and SAD information
in the IKE-less case.</t> in the IKE-less case.</t>
<t> In both cases, the I2NSF Controller is aware of <t> In both cases, the I2NSF Controller is aware of
the affected NSF (e.g., the NETCONF/TCP connection is the affected NSF (e.g., the NETCONF/TCP connection is
broken with the affected NSF, the I2NSF Controller is broken with the affected NSF, the I2NSF Controller is
receiving sadb-bad-spi notification from a particular receiving a sadb-bad-spi notification from a particular
NSF, etc.). Moreover, the I2NSF Controller keeps NSF, etc.). Moreover, the I2NSF Controller keeps
a list of NSFs that have IPsec SAs with the a list of NSFs that have IPsec SAs with the
affected NSF. Therefore, it knows the affected IPsec affected NSF. Therefore, it knows the affected IPsec
SAs.</t> SAs.</t>
<t>In the IKE case, the I2NSF Controller may need <t>In the IKE case, the I2NSF Controller may need
to configure the affected NSF with the new IKEv2, to configure the affected NSF with the new IKEv2,
SPD and PAD information. Alternatively, IKEv2 SPD, and PAD information. Alternatively, IKEv2
configuration MAY be made configuration <bcp14>MAY</bcp14> be made
permanent between NSF reboots without permanent between NSF reboots without
compromising security by means of the startup compromising security by means of the startup
configuration datastore in the NSF. This configuration datastore in the NSF. This
way, each time a NSF reboots it will use that way, each time an NSF reboots, it will use that
configuration for each rebooting. It would imply configuration for each rebooting. It would imply
avoiding contact with the I2NSF Controller. avoiding contact with the I2NSF Controller.
Finally, the I2NSF Controller Finally, the I2NSF Controller
may also need to send new parameters may also need to send new parameters
(e.g., a new fresh PSK for authentication) to the NSFs (e.g., a new fresh PSK for authentication) to the NSFs
which had IKEv2 SAs and IPsec SAs with the affected that had IKEv2 SAs and IPsec SAs with the affected
NSF.</t> NSF.</t>
<t>In the IKE-less case, the I2NSF Controller <bcp14>SHOULD</bcp14> dele
<t>In the IKE-less case, the I2NSF Controller SHOULD delete te
the old IPsec SAs in the non-failed nodes established with the old IPsec SAs in the non-failed nodes established with
the affected NSF. Once the affected node restarts, the I2NSF the affected NSF. Once the affected node restarts, the I2NSF
Controller MUST take the necessary actions to reestablish Controller <bcp14>MUST</bcp14> take the necessary actions to
IPsec protected communication between the failed node and reestablish
IPsec-protected communication between the failed node and
those others having IPsec SAs with the affected NSF. those others having IPsec SAs with the affected NSF.
How the I2NSF Controller implements an algorithm for How the I2NSF Controller implements an algorithm for
managing a potential NSF state loss is out of the scope of managing a potential NSF state loss is out of the scope of
this document. Nevertheless, an example of how this could be this document. Nevertheless, an example of how this could be
performed is described in <xref target="appendix-g3"/>. performed is described in <xref target="appendix-g3" format="
</t> default"/>.
</t>
</section> </section>
<section anchor="nat-traversal" title="NAT Traversal"> <section anchor="nat-traversal" numbered="true" toc="default">
<name>NAT Traversal</name>
<t>In the IKE case, IKEv2 already provides a mechanism <t>In the IKE case, IKEv2 already provides a mechanism
to detect whether some of the peers or both are located to detect whether some of the peers or both are located
behind a NAT. In this case, UDP or TCP behind a NAT. In this case, UDP or TCP
encapsulation for ESP packets (<xref target="RFC3948"/>, <xref target="RFC8229"/ encapsulation for Encapsulating Security Payload (ESP) packets <xref target="RFC
>) is required. 3948" format="default"/> <xref target="RFC8229" format="default"/> is required.
Note that IPsec transport mode MUST NOT be used in this specification Note that IPsec transport mode <bcp14>MUST NOT</bcp14> be used in this
specification
when NAT is required. when NAT is required.
</t> </t>
<t>In the IKE-less case, the NSF does not have the assistance
<t>In the IKE-less case, the NSF does not have the assistance
of the IKEv2 implementation to detect if it is located of the IKEv2 implementation to detect if it is located
behind a NAT. If the NSF does not have any other mechanism behind a NAT. If the NSF does not have any other mechanism
to detect this situation, the I2NSF Controller SHOULD to detect this situation, the I2NSF Controller <bcp14>SHOULD< /bcp14>
implement a mechanism to detect that case. The SDN paradigm implement a mechanism to detect that case. The SDN paradigm
generally assumes the I2NSF Controller has a view of the generally assumes the I2NSF Controller has a view of the
network under its control. This view is built either by network under its control. This view is built either by
requesting information from the NSFs under its control, or requesting information from the NSFs under its control or
by information pushed from the NSFs to the I2NSF Controller. information pushed from the NSFs to the I2NSF Controller.
Based on this information, the I2NSF Controller MAY guess Based on this information, the I2NSF Controller <bcp14>MAY</b
if there is a NAT configured between two hosts, and apply cp14> guess
if there is a NAT configured between two hosts and apply
the required policies to both NSFs besides activating the the required policies to both NSFs besides activating the
usage of UDP or TCP encapsulation of ESP packets usage of UDP or TCP encapsulation of ESP packets
(<xref target="RFC3948"/>, <xref target="RFC8229"/>). <xref target="RFC3948" format="default"/> <xref target="RFC82 29" format="default"/>.
The interface for discovering if the NSF The interface for discovering if the NSF
is behind a NAT is out of scope of this document.</t> is behind a NAT is out of scope of this document.</t>
<t>If the I2NSF Controller does not have any mechanism to know
<t>If the I2NSF Controller does not have any mechanism to know whether a host is behind a NAT or not, then the IKE case
whether a host is behind a NAT or not, then the IKE-case <bcp14>MUST</bcp14> be used and not the IKE-less case.</t>
MUST be used and not the IKE-less case.</t> </section>
</section> <section anchor="nsf-discovery" numbered="true" toc="default">
<name>NSF Registration and Discovery</name>
<section anchor="nsf-discovery" title="NSF registration and discover <t>NSF registration refers to the process of providing the
y"> I2NSF Controller information about a valid NSF, such as
<t>NSF registration refers to the process of providing the
I2NSF Controller information about a valid NSF such as
certificate, IP address, etc. This information is certificate, IP address, etc. This information is
incorporated in a list of NSFs under its control.</t> incorporated in a list of NSFs under its control.</t>
<t>The assumption in this document is that, for both <t>The assumption in this document is that, for both
cases, before a NSF can operate in this system, it MUST cases, before an NSF can operate in this system, it <bcp14>MU
ST</bcp14>
be registered in the I2NSF Controller. In this way, when be registered in the I2NSF Controller. In this way, when
the NSF starts and establishes a connection to the I2NSF the NSF starts and establishes a connection to the I2NSF
Controller, it knows that the NSF is valid for joining the Controller, it knows that the NSF is valid for joining the
system.</t> system.</t>
<t>Either during this registration process or when the <t>Either during this registration process or when the
NSF connects with the I2NSF Controller, the I2NSF NSF connects with the I2NSF Controller, the I2NSF
Controller MUST discover certain capabilities of this Controller <bcp14>MUST</bcp14> discover certain capabilities of this
NSF, such as what are the cryptographic suites supported, NSF, such as what are the cryptographic suites supported,
authentication method, the support of the IKE case and/or the authentication method, the support of the IKE case and/or
the IKE-less case, etc.</t> the IKE-less case, etc.</t>
<t>The registration and discovery processes are out of <t>The registration and discovery processes are out of
the scope of this document.</t> the scope of this document.</t>
</section> </section>
</section> </section>
<!--SDN-based IPsec management description--> <section anchor="models" numbered="true" toc="default">
<section anchor="models" title="YANG configuration data models"> <name>YANG Configuration Data Models</name>
<t> In order to support the IKE and IKE-less cases, <t> In order to support the IKE and IKE-less cases,
models are provided for the different parameters and models are provided for the different parameters and
values that must be configured to manage IPsec SAs. values that must be configured to manage IPsec SAs.
Specifically, the IKE case requires modeling IKEv2 Specifically, the IKE case requires modeling IKEv2
configuration parameters, SPD and PAD, configuration parameters, SPD and PAD,
while the IKE-less case requires configuration while the IKE-less case requires configuration
YANG data models for the YANG data models for the
SPD and SAD. Three modules have been defined: ietf-i2nsf-ikec SPD and SAD. Three modules have been defined: ietf-i2nsf-ikec
(<xref target="ike-common-model"/>, common to both cases), (<xref target="ike-common-model" format="default"/>, common to b
ietf-i2nsf-ike (<xref target="ike-case-model"/>, IKE case), oth cases),
ietf-i2nsf-ikeless (<xref target="ike-less-model"/>, IKE-less ca ietf-i2nsf-ike (<xref target="ike-case-model" format="default"/
se). >, IKE case), and
ietf-i2nsf-ikeless (<xref target="ike-less-model" format="defaul
t"/>, IKE-less case).
Since the module ietf-i2nsf-ikec has only typedef and Since the module ietf-i2nsf-ikec has only typedef and
groupings common to the other modules, a groupings common to the other modules, a
simplified view of the ietf-i2nsf-ike and ietf-i2nsf-ikeless simplified view of the ietf-i2nsf-ike and ietf-i2nsf-ikeless
modules is shown.</t> modules is shown.</t>
<!--> <section anchor="ike-common-model" numbered="true" toc="default">
<t> In the following, we just summarize, by using a tree representat <name>The 'ietf-i2nsf-ikec' Module</name>
ion, the <section anchor="common-overview" numbered="true" toc="default">
different configuration and state data models related with SPD, <name>Data Model Overview</name>
SAD, PAD and IKEv2.</t> <t>The module ietf-i2nsf-ikec only has definitions of
data types (typedef) and groupings that are common
<section anchor="spd-model" title="Security Policy Database (SPD) Mo
del">-->
<section anchor="ike-common-model" title="The 'ietf-i2nsf-ikec' Modu
le">
<section anchor="common-overview" title="Data model overview">
<t>The module ietf-i2nsf-ikec has only definition of
data types (typedef) and groupings which are common
to the other modules.</t> to the other modules.</t>
</section>
<section anchor="common-module" numbered="true" toc="default">
<name>YANG Module</name>
<t>
This module has normative references to <xref target="RFC3
947" format="default"/>, <xref target="RFC4301" format="default"/>, <xref target
="RFC4303" format="default"/>, <xref target="RFC8174" format="default"/>, <xref
target="RFC8221" format="default"/>, <xref target="RFC3948" format="default"/>,
<xref target="RFC8229" format="default"/>, <xref target="RFC6991" format="defau
lt"/>, <xref target="IANA-Protocols-Number" format="default"/>, <xref target="IK
Ev2-Parameters" format="default"/>, <xref target="IKEv2-Transform-Type-1" format
="default"/>, and <xref target="IKEv2-Transform-Type-3" format="default"/>.
</t>
<sourcecode name="ietf-i2nsf-ikec@2021-06-09.yang" type="yang" markers="true"><!
[CDATA[
</section> module ietf-i2nsf-ikec {
yang-version 1.1;
<section anchor="common-module" title="YANG Module"> namespace "urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikec";
<t> prefix nsfikec;
This module has normative references to <xref target="RFC3
947"/>, <xref target="RFC4301"/>, <xref target="RFC4303"/>, <xref target="RFC817
4"/>, <xref target="RFC8221"/>, <xref target="RFC3948"/>, <xref target="RFC8229
"/>, <xref target="IANA-Protocols-Number"/>, <xref target="IKEv2-Parameters"/>,
<xref target="IKEv2-Transform-Type-1"/> and <xref target="IKEv2-Transform-Type-3
"/>.
</t>
<t>
<figure>
<artwork>
<![CDATA[
<CODE BEGINS> file "ietf-i2nsf-ikec@2021-03-18.yang"
module ietf-i2nsf-ikec {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikec";
prefix "nsfikec";
import ietf-inet-types {
prefix inet;
reference "RFC 6991: Common YANG Data Types";
}
organization "IETF I2NSF Working Group"; import ietf-inet-types {
prefix inet;
reference
"RFC 6991: Common YANG Data Types.";
}
contact organization
"WG Web: <https://datatracker.ietf.org/wg/i2nsf/> "IETF I2NSF Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/i2nsf/>
WG List: <mailto:i2nsf@ietf.org> WG List: <mailto:i2nsf@ietf.org>
Author: Rafael Marin-Lopez Author: Rafael Marin-Lopez
<mailto:rafa@um.es> <mailto:rafa@um.es>
Author: Gabriel Lopez-Millan Author: Gabriel Lopez-Millan
<mailto:gabilm@um.es> <mailto:gabilm@um.es>
Author: Fernando Pereniguez-Garcia Author: Fernando Pereniguez-Garcia
<mailto:fernando.pereniguez@cud.upct.es> <mailto:fernando.pereniguez@cud.upct.es>
"; ";
description
description "Common data model for the IKE and IKE-less cases
"Common Data model for the IKE and IKE-less cases
defined by the SDN-based IPsec flow protection service. defined by the SDN-based IPsec flow protection service.
Copyright (c) 2020 IETF Trust and the persons
identified as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with
or without modification, is permitted pursuant to, and
subject to the license terms contained in, the
Simplified BSD License set forth in Section 4.c of the
IETF Trust's Legal Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX;;
see the RFC itself for full legal notices.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this
document are to be interpreted as described in BCP 14 document are to be interpreted as described in BCP 14
(RFC 2119) (RFC 8174) when, and only when, they appear (RFC 2119) (RFC 8174) when, and only when, they appear
in all capitals, as shown here."; in all capitals, as shown here.
revision "2021-03-18" { Copyright (c) 2021 IETF Trust and the persons
description "Initial version."; identified as authors of the code. All rights reserved.
reference "RFC XXXX: Software-Defined Networking
(SDN)-based IPsec Flow Protection.";
}
typedef encr-alg-t { Redistribution and use in source and binary forms, with or
type uint16; without modification, is permitted pursuant to, and subject
description to the license terms contained in, the Simplified BSD License
"The encryption algorithm is specified with a 16-bit set forth in Section 4.c of the IETF Trust's Legal Provisions
number extracted from the IANA Registry. The acceptable Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC 9061; see
the RFC itself for full legal notices.";
revision 2021-06-09 {
description
"Initial version.";
reference
"RFC 9061: A YANG Data Model for IPsec Flow Protection
Based on Software-Defined Networking (SDN).";
}
typedef encr-alg-t {
type uint16;
description
"The encryption algorithm is specified with a 16-bit
number extracted from the IANA registry. The acceptable
values MUST follow the requirement levels for values MUST follow the requirement levels for
encryption algorithms for ESP and IKEv2."; encryption algorithms for ESP and IKEv2.";
reference reference
"IANA; Internet Key Exchange V2 (IKEv2) Parameters; "IANA: Internet Key Exchange Version 2 (IKEv2) Parameters,
Transform Atribute Types; Transform Type 1 - Encryption IKEv2 Transform Attribute Types, Transform Type 1 -
Algorithm Transform IDs. RFC 8221 - Cryptographic Encryption Algorithm Transform IDs
Algorithm Implementation Requirements and Usage RFC 8221: Cryptographic Algorithm Implementation
Guidance for Encapsulating Security Payload (ESP) Requirements and Usage Guidance for Encapsulating
and Authentication Header (AH) and RFC 8247 - Security Payload (ESP) and Authentication Header
Algorithm Implementation Requirements and Usage (AH)
Guidance for the Internet Key Exchange Protocol RFC 8247: Algorithm Implementation Requirements and Usage
Version 2 (IKEv2)."; Guidance for the Internet Key Exchange Protocol
} Version 2 (IKEv2).";
}
typedef intr-alg-t { typedef intr-alg-t {
type uint16; type uint16;
description description
"The integrity algorithm is specified with a 16-bit "The integrity algorithm is specified with a 16-bit
number extracted from the IANA Registry. number extracted from the IANA registry.
The acceptable values MUST follow the requirement The acceptable values MUST follow the requirement
levels for integrity algorithms for ESP and IKEv2."; levels for integrity algorithms for ESP and IKEv2.";
reference reference
"IANA; Internet Key Exchange V2 (IKEv2) Parameters; "IANA: Internet Key Exchange Version 2 (IKEv2) Parameters,
Transform Atribute Types; Transform Type 3 - Integrity IKEv2 Transform Attribute Types, Transform Type 3 -
Algorithm Transform IDs. RFC 8221 - Cryptographic Integrity Algorithm Transform IDs
Algorithm Implementation Requirements and Usage RFC 8221: Cryptographic Algorithm Implementation
Guidance for Encapsulating Security Payload (ESP) Requirements and Usage Guidance for Encapsulating
and Authentication Header (AH) and RFC 8247 - Security Payload (ESP) and Authentication Header
Algorithm Implementation Requirements and Usage (AH)
Guidance for the Internet Key Exchange Protocol RFC 8247: Algorithm Implementation Requirements and Usage
Version 2 (IKEv2)."; Guidance for the Internet Key Exchange Protocol
} Version 2 (IKEv2).";
}
typedef ipsec-mode { typedef ipsec-mode {
type enumeration { type enumeration {
enum transport { enum transport {
description description
"IPsec transport mode. No Network Address "IPsec transport mode. No Network Address
Translation (NAT) support."; Translation (NAT) support.";
} }
enum tunnel { enum tunnel {
description "IPsec tunnel mode."; description
} "IPsec tunnel mode.";
} }
description }
"Type definition of IPsec mode: transport or description
"Type definition of IPsec mode: transport or
tunnel."; tunnel.";
reference reference
"Section 3.2 in RFC 4301."; "RFC 4301: Security Architecture for the Internet Protocol,
} Section 3.2.";
}
typedef esp-encap { typedef esp-encap {
type enumeration { type enumeration {
enum espintcp { enum espintcp {
description description
"ESP in TCP encapsulation."; "ESP in TCP encapsulation.";
reference reference
"RFC 8229 - TCP Encapsulation of IKE and "RFC 8229: TCP Encapsulation of IKE and
IPsec Packets."; IPsec Packets.";
} }
enum espinudp { enum espinudp {
description description
"ESP in UDP encapsulation."; "ESP in UDP encapsulation.";
reference reference
"RFC 3948 - UDP Encapsulation of IPsec ESP "RFC 3948: UDP Encapsulation of IPsec ESP
Packets."; Packets.";
} }
enum none { enum none {
description description
"No ESP encapsulation."; "No ESP encapsulation.";
} }
} }
description description
"Types of ESP encapsulation when Network Address "Types of ESP encapsulation when Network Address
Translation (NAT) may be present between two NSFs."; Translation (NAT) may be present between two NSFs.";
reference reference
"RFC 8229 - TCP Encapsulation of IKE and IPsec "RFC 8229: TCP Encapsulation of IKE and IPsec Packets
Packets and RFC 3948 - UDP Encapsulation of IPsec RFC 3948: UDP Encapsulation of IPsec ESP Packets.";
ESP Packets."; }
}
typedef ipsec-protocol-parameters { typedef ipsec-protocol-params {
type enumeration { type enumeration {
enum esp { description "IPsec ESP protocol."; } enum esp {
} description
description "IPsec ESP protocol.";
"Only the Encapsulation Security Protocol (ESP) is }
supported but it could be extended in the future."; }
reference description
"RFC 4303- IP Encapsulating Security Payload "Only the Encapsulation Security Protocol (ESP) is
(ESP)."; supported, but it could be extended in the future.";
} reference
"RFC 4303: IP Encapsulating Security Payload (ESP).";
}
typedef lifetime-action { typedef lifetime-action {
type enumeration { type enumeration {
enum terminate-clear { enum terminate-clear {
description description
"Terminates the IPsec SA and allows the "Terminates the IPsec SA and allows the
packets through."; packets through.";
} }
enum terminate-hold { enum terminate-hold {
description description
"Terminates the IPsec SA and drops the "Terminates the IPsec SA and drops the
packets."; packets.";
} }
enum replace { enum replace {
description description
"Replaces the IPsec SA with a new one: "Replaces the IPsec SA with a new one:
rekey. "; rekey.";
} }
} }
description description
"When the lifetime of an IPsec SA expires an action "When the lifetime of an IPsec SA expires, an action
needs to be performed for the IPsec SA that needs to be performed for the IPsec SA that
reached the lifetime. There are three posible reached the lifetime. There are three possible
options: terminate-clear, terminate-hold and options: terminate-clear, terminate-hold, and
replace."; replace.";
reference reference
"Section 4.5 in RFC 4301."; "RFC 4301: Security Architecture for the Internet Protocol,
} Section 4.5.";
}
typedef ipsec-traffic-direction { typedef ipsec-traffic-direction {
type enumeration { type enumeration {
enum inbound { enum inbound {
description "Inbound traffic."; description
} "Inbound traffic.";
enum outbound { }
description "Outbound traffic."; enum outbound {
} description
} "Outbound traffic.";
description }
"IPsec traffic direction is defined in }
description
"IPsec traffic direction is defined in
two directions: inbound and outbound. two directions: inbound and outbound.
From a NSF perspective, inbound and From an NSF perspective, inbound and
outbound are defined as mentioned outbound are defined as mentioned
in RFC 4301 (Section 3.1)."; in Section 3.1 in RFC 4301.";
reference reference
"Section 3.1 in RFC 4301."; "RFC 4301: Security Architecture for the Internet Protocol,
} Section 3.1.";
}
typedef ipsec-spd-action { typedef ipsec-spd-action {
type enumeration { type enumeration {
enum protect { enum protect {
description description
"PROTECT the traffic with IPsec."; "PROTECT the traffic with IPsec.";
} }
enum bypass { enum bypass {
description description
"BYPASS the traffic. The packet is forwarded "BYPASS the traffic. The packet is forwarded
without IPsec protection."; without IPsec protection.";
} }
enum discard { enum discard {
description description
"DISCARD the traffic. The IP packet is "DISCARD the traffic. The IP packet is
discarded."; discarded.";
} }
} }
description description
"The action when traffic matches an IPsec security "The action when traffic matches an IPsec security
policy. According to RFC 4301 there are three policy. According to RFC 4301, there are three
possible values: BYPASS, PROTECT AND DISCARD"; possible values: BYPASS, PROTECT, and DISCARD.";
reference reference
"Section 4.4.1 in RFC 4301."; "RFC 4301: Security Architecture for the Internet Protocol,
} Section 4.4.1.";
}
typedef ipsec-inner-protocol { typedef ipsec-inner-protocol {
type union { type union {
type uint8; type uint8;
type enumeration { type enumeration {
enum any { enum any {
value 256; value 256;
description description
"Any IP protocol number value."; "Any IP protocol number value.";
} }
} }
} }
default any; default "any";
description description
"IPsec protection can be applied to specific IP "IPsec protection can be applied to specific IP
traffic and layer 4 traffic (TCP, UDP, SCTP, etc.) traffic and Layer 4 traffic (TCP, UDP, SCTP, etc.)
or ANY protocol in the IP packet payload. We or ANY protocol in the IP packet payload.
The IP protocol number is specified with an uint8 The IP protocol number is specified with a uint8
or ANY defining an enumerate with value 256 to or ANY defining an enumerate with value 256 to
indicate the protocol number. NOTE: In case indicate the protocol number. Note that in case
of IPv6, the protocol in the IP packet payload of IPv6, the protocol in the IP packet payload
is indicated in the Next Header field of the IPv6 is indicated in the Next Header field of the IPv6
packet."; packet.";
reference reference
"Section 4.4.1.1 in RFC 4301. "RFC 4301: Security Architecture for the Internet Protocol,
IANA Registry - Protocol Numbers."; Section 4.4.1.1
} IANA: Protocol Numbers.";
}
grouping encap { grouping encap {
description description
"This group of nodes allows to define the type of "This group of nodes allows defining of the type of
encapsulation in case NAT traversal is encapsulation in case NAT traversal is
required and includes port information."; required and includes port information.";
leaf espencap { leaf espencap {
type esp-encap; type esp-encap;
default none; default "none";
description description
"ESP in TCP, ESP in UDP or ESP in TLS."; "ESP in TCP, ESP in UDP, or ESP in TLS.";
} }
leaf sport { leaf sport {
type inet:port-number; type inet:port-number;
default 4500; default "4500";
description description
"Encapsulation source port."; "Encapsulation source port.";
} }
leaf dport { leaf dport {
type inet:port-number; type inet:port-number;
default 4500; default "4500";
description description
"Encapsulation destination port."; "Encapsulation destination port.";
} }
leaf-list oaddr {
leaf-list oaddr { type inet:ip-address;
type inet:ip-address; description
description "If required, this is the original address that
"If required, this is the original address that was used before NAT was applied over the packet.";
was used before NAT was applied over the Packet. }
"; reference
} "RFC 3947: Negotiation of NAT-Traversal in the IKE
reference RFC 8229: TCP Encapsulation of IKE and IPsec Packets.";
"RFC 3947 and RFC 8229."; }
}
grouping lifetime { grouping lifetime {
description description
"Different lifetime values limited to an IPsec SA."; "Different lifetime values limited to an IPsec SA.";
leaf time { leaf time {
type uint32; type uint32;
units "seconds"; units "seconds";
default 0; default "0";
description description
"Time in seconds since the IPsec SA was added. "Time in seconds since the IPsec SA was added.
For example, if this value is 180 seconds it For example, if this value is 180 seconds, it
means the IPsec SA expires in 180 seconds since means the IPsec SA expires in 180 seconds since
it was added. The value 0 implies infinite."; it was added. The value 0 implies infinite.";
} }
leaf bytes { leaf bytes {
type uint64; type uint64;
default 0; default "0";
description description
"If the IPsec SA processes the number of bytes "If the IPsec SA processes the number of bytes
expressed in this leaf, the IPsec SA expires and expressed in this leaf, the IPsec SA expires and
SHOULD be rekeyed. The value 0 implies SHOULD be rekeyed. The value 0 implies
infinite.";
}
leaf packets {
type uint32;
default 0;
description
"If the IPsec SA processes the number of packets
expressed in this leaf, the IPsec SA expires and
SHOULD be rekeyed. The value 0 implies
infinite.";
}
leaf idle {
type uint32;
units "seconds";
default 0;
description
"When a NSF stores an IPsec SA, it
consumes system resources. For an idle IPsec SA this
is a waste of resources. If the IPsec SA is idle
during this number of seconds the IPsec SA
SHOULD be removed. The value 0 implies
infinite."; infinite.";
} }
reference leaf packets {
"Section 4.4.2.1 in RFC 4301."; type uint32;
} default "0";
description
"If the IPsec SA processes the number of packets
expressed in this leaf, the IPsec SA expires and
SHOULD be rekeyed. The value 0 implies
infinite.";
}
leaf idle {
type uint32;
units "seconds";
default "0";
description
"When an NSF stores an IPsec SA, it
consumes system resources. For an idle IPsec SA, this
is a waste of resources. If the IPsec SA is idle
during this number of seconds, the IPsec SA
SHOULD be removed. The value 0 implies
infinite.";
}
reference
"RFC 4301: Security Architecture for the Internet Protocol,
Section 4.4.2.1.";
}
grouping port-range { grouping port-range {
description description
"This grouping defines a port range, such as "This grouping defines a port range, such as that
expressed in RFC 4301. For example: 1500 (Start expressed in RFC 4301, for example, 1500 (Start
Port Number)-1600 (End Port Number). Port Number)-1600 (End Port Number).
A port range is used in the Traffic Selector."; A port range is used in the Traffic Selector.";
leaf start {
leaf start { type inet:port-number;
type inet:port-number; description
description "Start port number."; "Start port number.";
} }
leaf end { leaf end {
type inet:port-number; type inet:port-number;
must '. >= ../start' { must '. >= ../start' {
error-message error-message
"The end port number MUST be equal or greater "The end port number MUST be equal or greater
than the start port number."; than the start port number.";
} }
description description
"End port number. To express a single port, set "End port number. To express a single port, set
the same value as start and end."; the same value as start and end.";
} }
reference "Section 4.4.1.2 in RFC 4301."; reference
} "RFC 4301: Security Architecture for the Internet Protocol,
Section 4.4.1.2.";
}
grouping tunnel-grouping { grouping tunnel-grouping {
description description
"The parameters required to define the IP tunnel "The parameters required to define the IP tunnel
endpoints when IPsec SA requires tunnel mode. The endpoints when IPsec SA requires tunnel mode. The
tunnel is defined by two endpoints: the local IP tunnel is defined by two endpoints: the local IP
address and the remote IP address."; address and the remote IP address.";
leaf local {
leaf local { type inet:ip-address;
type inet:ip-address; mandatory true;
mandatory true; description
description "Local IP address' tunnel endpoint.";
"Local IP address' tunnel endpoint."; }
} leaf remote {
leaf remote { type inet:ip-address;
type inet:ip-address; mandatory true;
mandatory true; description
description "Remote IP address' tunnel endpoint.";
"Remote IP address' tunnel endpoint."; }
} leaf df-bit {
leaf df-bit { type enumeration {
type enumeration { enum clear {
enum clear { description
description "Disable the Don't Fragment (DF) bit
"Disable the DF (Don't Fragment) bit in the outer header. This is the
in the outer header. This is the
default value."; default value.";
} }
enum set { enum set {
description description
"Enable the DF bit in the outer header."; "Enable the DF bit in the outer header.";
} }
enum copy { enum copy {
description description
"Copy the DF bit to the outer header."; "Copy the DF bit to the outer header.";
} }
} }
default clear; default "clear";
description description
"Allow configuring the DF bit when encapsulating "Allow configuring the DF bit when encapsulating
tunnel mode IPsec traffic. RFC 4301 describes tunnel mode IPsec traffic. RFC 4301 describes
three options to handle the DF bit during three options to handle the DF bit during
tunnel encapsulation: clear, set and copy from tunnel encapsulation: clear, set, and copy from
the inner IP header. This MUST be ignored or the inner IP header. This MUST be ignored or
has no meaning when the local/remote has no meaning when the local/remote
IP addresses are IPv6 addresses."; IP addresses are IPv6 addresses.";
reference reference
"Section 8.1 in RFC 4301."; "RFC 4301: Security Architecture for the Internet Protocol,
} Section 8.1.";
leaf bypass-dscp { }
type boolean; leaf bypass-dscp {
default true; type boolean;
description default "true";
"If True to copy the DSCP value from inner header description
to outer header. If False to map DSCP values "If true, to copy the Differentiated Services Code
Point (DSCP) value from inner header to outer header.
If false, to map DSCP values
from an inner header to values in an outer header from an inner header to values in an outer header
following ../dscp-mapping"; following ../dscp-mapping.";
reference reference
"Section 4.4.1.2. in RFC 4301."; "RFC 4301: Security Architecture for the Internet Protocol,
} Section 4.4.1.2.";
}
list dscp-mapping { list dscp-mapping {
must '../bypass-dscp = "false"'; must '../bypass-dscp = "false"';
key id; key "id";
ordered-by user; ordered-by user;
leaf id { leaf id {
type uint8; type uint8;
description description
"The index of list with the "The index of list with the
different mappings."; different mappings.";
} }
leaf inner-dscp {
leaf inner-dscp { type inet:dscp;
type inet:dscp; description
description "The DSCP value of the inner IP packet. If this
"The DSCP value of the inner IP packet. If this leaf is not defined, it means ANY inner DSCP value.";
leaf is not defined it means ANY inner DSCP value"; }
} leaf outer-dscp {
leaf outer-dscp { type inet:dscp;
type inet:dscp; default "0";
default 0; description
description "The DSCP value of the outer IP packet.";
"The DSCP value of the outer IP packet"; }
} description
description "A list that represents an array with the mapping from the
"A list that represents an array with the mapping from the
inner DSCP value to outer DSCP value when bypass-dscp is inner DSCP value to outer DSCP value when bypass-dscp is
False. To express a default mapping in the list where any false. To express a default mapping in the list where any
other inner dscp value is not matching a node in the list, other inner dscp value is not matching a node in the list,
a new node has to be included at the end of the list where a new node has to be included at the end of the list where
the leaf inner-dscp is not defined (ANY) and the leaf the leaf inner-dscp is not defined (ANY) and the leaf
outer-dscp includes the value of the mapping. If there is no outer-dscp includes the value of the mapping. If there is
value set in the leaf outer-dscp the default value for this no value set in the leaf outer-dscp, the default value for
leaf is 0."; this leaf is 0.";
reference reference
"Section 4.4.1.2. and Appendix C in RFC 4301."; "RFC 4301: Security Architecture for the Internet Protocol,
} Section 4.4.1.2 and Appendix C.";
} }
}
grouping selector-grouping { grouping selector-grouping {
description description
"This grouping contains the definition of a Traffic "This grouping contains the definition of a Traffic
Selector, which is used in the IPsec policies and Selector, which is used in the IPsec policies and
IPsec SAs."; IPsec SAs.";
leaf local-prefix {
leaf local-prefix { type inet:ip-prefix;
type inet:ip-prefix; mandatory true;
mandatory true; description
description "Local IP address prefix.";
"Local IP address prefix."; }
} leaf remote-prefix {
leaf remote-prefix { type inet:ip-prefix;
type inet:ip-prefix; mandatory true;
mandatory true; description
description "Remote IP address prefix.";
"Remote IP address prefix."; }
} leaf inner-protocol {
leaf inner-protocol { type ipsec-inner-protocol;
type ipsec-inner-protocol; default "any";
default any; description
description "Inner protocol that is going to be
"Inner Protocol that is going to be
protected with IPsec."; protected with IPsec.";
} }
list local-ports { list local-ports {
key "start end"; key "start end";
uses port-range; uses port-range;
description description
"List of local ports. When the inner "List of local ports. When the inner
protocol is ICMP this 16 bit value protocol is ICMP, this 16-bit value
represents code and type. represents code and type.
If this list is not defined If this list is not defined,
it is assumed that start and it is assumed that start and
end are 0 by default (any port)."; end are 0 by default (any port).";
} }
list remote-ports { list remote-ports {
key "start end"; key "start end";
uses port-range; uses port-range;
description description
"List of remote ports. When the upper layer "List of remote ports. When the upper layer
protocol is ICMP this 16 bit value represents protocol is ICMP, this 16-bit value represents
code and type.If this list is not defined code and type. If this list is not defined,
it is assumed that start and end are 0 by it is assumed that start and end are 0 by
default (any port)"; default (any port).";
} }
reference reference
"Section 4.4.1.2 in RFC 4301."; "RFC 4301: Security Architecture for the Internet Protocol,
} Section 4.4.1.2.";
}
grouping ipsec-policy-grouping { grouping ipsec-policy-grouping {
description description
"Holds configuration information for an IPsec SPD "Holds configuration information for an IPsec SPD
entry."; entry.";
leaf anti-replay-window-size {
leaf anti-replay-window-size { type uint32;
type uint32; default "64";
default 64; description
description "To set the anti-replay window size.
"To set the anti-replay window size.
The default value is set The default value is set
to 64 following RFC 4303 recommendation."; to 64, following the recommendation in RFC 4303.";
reference reference
"Section 3.4.3 in RFC 4303"; "RFC 4303: IP Encapsulating Security Payload (ESP),
} Section 3.4.3.";
container traffic-selector { }
description container traffic-selector {
"Packets are selected for description
processing actions based on traffic selector "Packets are selected for
processing actions based on Traffic Selector
values, which refer to IP and inner protocol values, which refer to IP and inner protocol
header information."; header information.";
uses selector-grouping; uses selector-grouping;
reference reference
"Section 4.4.4.1 in RFC 4301."; "RFC 4301: Security Architecture for the Internet Protocol,
} Section 4.4.4.1.";
container processing-info { }
description container processing-info {
"SPD processing. If the required processing description
"SPD processing. If the required processing
action is protect, it contains the required action is protect, it contains the required
information to process the packet."; information to process the packet.";
leaf action { leaf action {
type ipsec-spd-action; type ipsec-spd-action;
default discard; default "discard";
description description
"If bypass or discard, container "If bypass or discard, container
ipsec-sa-cfg is empty."; ipsec-sa-cfg is empty.";
} }
container ipsec-sa-cfg { container ipsec-sa-cfg {
when "../action = 'protect'"; when "../action = 'protect'";
description description
"IPsec SA configuration included in the SPD "IPsec SA configuration included in the SPD
entry."; entry.";
leaf pfp-flag { leaf pfp-flag {
type boolean; type boolean;
default false; default "false";
description description
"Each selector has a Populate From "Each selector has a Populate From
Packet (PFP) flag. If asserted for a Packet (PFP) flag. If asserted for a
given selector X, the flag indicates given selector X, the flag indicates
that the IPsec SA to be created should that the IPsec SA to be created should
take its value (local IP address, take its value (local IP address,
remote IP address, Next Layer remote IP address, Next Layer
Protocol, etc.) for X from the value Protocol, etc.) for X from the value
in the packet. Otherwise, the IPsec SA in the packet. Otherwise, the IPsec SA
should take its value(s) for X from should take its value(s) for X from
the value(s) in the SPD entry."; the value(s) in the SPD entry.";
} }
leaf ext-seq-num { leaf ext-seq-num {
type boolean; type boolean;
default false; default "false";
description description
"True if this IPsec SA is using extended "True if this IPsec SA is using extended
sequence numbers. If true, the 64-bit sequence numbers. If true, the 64-bit
extended sequence number counter is used; extended sequence number counter is used;
if false, the normal 32-bit sequence if false, the normal 32-bit sequence
number counter is used."; number counter is used.";
} }
leaf seq-overflow { leaf seq-overflow {
type boolean; type boolean;
default false; default "false";
description description
"The flag indicating whether "The flag indicating whether
overflow of the sequence number overflow of the sequence number
counter should prevent transmission counter should prevent transmission
of additional packets on the IPsec of additional packets on the IPsec
SA (false) and, therefore needs to SA (false) and, therefore, needs to
be rekeyed, or whether rollover is be rekeyed or whether rollover is
permitted (true). If Authenticated permitted (true). If Authenticated
Encryption with Associated Data Encryption with Associated Data
(AEAD) is used (leaf (AEAD) is used (leaf
esp-algorithms/encryption/algorithm-type) esp-algorithms/encryption/algorithm-type),
this flag MUST be false. Setting this this flag MUST be false. Setting this
flag to true is strongly discouraged."; flag to true is strongly discouraged.";
} }
leaf stateful-frag-check { leaf stateful-frag-check {
type boolean; type boolean;
default false; default "false";
description description
"Indicates whether (true) or not (false) "Indicates whether (true) or not (false)
stateful fragment checking applies to stateful fragment checking applies to
the IPsec SA to be created."; the IPsec SA to be created.";
} }
leaf mode { leaf mode {
type ipsec-mode; type ipsec-mode;
default transport; default "transport";
description description
"IPsec SA has to be processed in "IPsec SA has to be processed in
transport or tunnel mode."; transport or tunnel mode.";
} }
leaf protocol-parameters { leaf protocol-parameters {
type ipsec-protocol-parameters; type ipsec-protocol-params;
default esp; default "esp";
description description
"Security protocol of the IPsec SA: "Security protocol of the IPsec SA.
Only ESP is supported but it could be Only ESP is supported, but it could be
extended in the future."; extended in the future.";
} }
container esp-algorithms { container esp-algorithms {
when "../protocol-parameters = 'esp'"; when "../protocol-parameters = 'esp'";
description description
"Configuration of Encapsulating "Configuration of Encapsulating
Security Payload (ESP) parameters and Security Payload (ESP) parameters and
algorithms."; algorithms.";
leaf-list integrity {
leaf-list integrity { type intr-alg-t;
type intr-alg-t; default "0";
default 0; ordered-by user;
ordered-by user; description
description "Configuration of ESP authentication
"Configuration of ESP authentication based on the specified integrity
based on the specified integrity algorithm. With AEAD encryption
algorithm. With AEAD encryption algorithms, the integrity node is
algorithms, the integrity node is not used.";
not used."; reference
reference "RFC 4303: IP Encapsulating Security Payload (ESP),
"Section 3.2 in RFC 4303."; Section 3.2.";
} }
list encryption { list encryption {
key id; key "id";
ordered-by user; ordered-by user;
leaf id { leaf id {
type uint16; type uint16;
description description
"An identifier that unequivocally identifies each "An identifier that unequivocally identifies each
entry of the list, i.e., an encryption algorithm entry of the list, i.e., an encryption algorithm
and its key-length (if required)."; and its key length (if required).";
} }
leaf algorithm-type { leaf algorithm-type {
type encr-alg-t; type encr-alg-t;
default 20; default "20";
description description
"Default value 20 (ENCR_AES_GCM_16)"; "Default value 20 (ENCR_AES_GCM_16).";
} }
leaf key-length { leaf key-length {
type uint16; type uint16;
default 128; default "128";
description description
"By default key length is 128 "By default, key length is 128
bits"; bits.";
} }
description description
"Encryption or AEAD algorithm for the "Encryption or AEAD algorithm for the
IPsec SAs. This list is ordered IPsec SAs. This list is ordered
following from the higher priority to following from the higher priority to
lower priority. First node of the lower priority. First node of the
list will be the algorithm with list will be the algorithm with
higher priority. In case the list higher priority. In case the list
is empty, then is empty, then no encryption algorithm
no encryption algorithm
is applied (NULL)."; is applied (NULL).";
reference reference
"Section 3.2 in RFC 4303."; "RFC 4303: IP Encapsulating Security Payload (ESP),
} Section 3.2.";
leaf tfc-pad { }
type boolean; leaf tfc-pad {
default false; type boolean;
description default "false";
"If Traffic Flow Confidentiality description
"If Traffic Flow Confidentiality
(TFC) padding for ESP encryption (TFC) padding for ESP encryption
can be used (true) or not (false)"; can be used (true) or not (false).";
reference reference
"Section 2.7 in RFC 4303."; "RFC 4303: IP Encapsulating Security Payload (ESP),
} Section 2.7.";
reference }
"RFC 4303."; reference
} "RFC 4303: IP Encapsulating Security Payload (ESP).";
container tunnel { }
when "../mode = 'tunnel'"; container tunnel {
uses tunnel-grouping; when "../mode = 'tunnel'";
description uses tunnel-grouping;
"IPsec tunnel endpoints definition."; description
} "IPsec tunnel endpoints definition.";
} }
reference }
"Section 4.4.1.2 in RFC 4301."; reference
} "RFC 4301: Security Architecture for the Internet Protocol,
} Section 4.4.1.2.";
} }
}
<CODE ENDS> }
]]></sourcecode>
]]> </section>
</artwork> </section>
</figure> <section anchor="ike-case-model" numbered="true" toc="default">
</t> <name>The 'ietf-i2nsf-ike' Module</name>
</section>
</section>
<section anchor="ike-case-model" title="The 'ietf-i2nsf-ike' Module"
>
<t>In this section, the YANG module for the IKE case is described.</t> <t>In this section, the YANG module for the IKE case is described.</t>
<section anchor="ike-overview" numbered="true" toc="default">
<section anchor="ike-overview" title="Data model overview"> <name>Data Model Overview</name>
<t>The model related to IKEv2 has been extracted from
<t>The model related to IKEv2 has been extracted from reading the IKEv2 standard in
reading IKEv2 standard in <xref target="RFC7296" format="default"/> and observing some o
<xref target="RFC7296"/>, and observing some open pen
source implementations, such as Strongswan source implementations, such as strongSwan
<xref target="strongswan"/> or Libreswan <xref target="strongswan" format="default"/> or Libreswan
<xref target="libreswan"/>.</t> <xref target="libreswan" format="default"/>.</t>
<t>The definition of the PAD model has been
<t>The definition of the PAD model has been extracted from the specification in
extracted from the specification in section 4.4.3 in <xref target="RFC4301" sectionFormat="of" section="4.4.3"/>. (No
<xref target="RFC4301"/> (NOTE: Many te that many
implementations integrate PAD configuration as part implementations integrate PAD configuration as part
of the of the IKEv2 configuration.)</t>
IKEv2 configuration).</t> <t> The definition of the SPD model has been
mainly extracted from the specification in Section
<t> The definition of the SPD model has been <xref target="RFC4301" section="4.4.1" sectionFormat="bare"/> an
mainly extracted from the specification in section d Appendix <xref target="RFC4301" section="D" sectionFormat="bare"/> of <xref ta
4.4.1 and Appendix D in <xref target="RFC4301"/>. rget="RFC4301" format="default"/>.
</t> </t>
<t> The YANG data model for the IKE case is defined by the module "iet
<t> The YANG data model for the IKE case is defined by the mod f-i2nsf-ike". Its structure is depicted in the following diagram, using the nota
ule "ietf-i2nsf-ike". Its structure is depicted in the following diagram, using tion syntax for YANG tree diagrams <xref target="RFC8340" format="default"/>.
the notation syntax for YANG tree diagrams (<xref target="RFC8340"/>). </t>
</t> <sourcecode type="yangtree"><![CDATA[
<t>
<figure>
<artwork>
<![CDATA[
module: ietf-i2nsf-ike module: ietf-i2nsf-ike
+--rw ipsec-ike +--rw ipsec-ike
+--rw pad +--rw pad
| +--rw pad-entry* [name] | +--rw pad-entry* [name]
| +--rw name string | +--rw name string
| +--rw (identity) | +--rw (identity)
| | +--:(ipv4-address) | | +--:(ipv4-address)
| | | +--rw ipv4-address? inet:ipv4-address | | | +--rw ipv4-address? inet:ipv4-address
| | +--:(ipv6-address) | | +--:(ipv6-address)
| | | +--rw ipv6-address? inet:ipv6-address | | | +--rw ipv6-address? inet:ipv6-address
skipping to change at line 1652 skipping to change at line 1444
| +--rw ca-data* binary | +--rw ca-data* binary
| +--rw crl-data? binary | +--rw crl-data? binary
| +--rw crl-uri? inet:uri | +--rw crl-uri? inet:uri
| +--rw oscp-uri? inet:uri | +--rw oscp-uri? inet:uri
+--rw conn-entry* [name] +--rw conn-entry* [name]
| +--rw name string | +--rw name string
| +--rw autostartup? autostartup-type | +--rw autostartup? autostartup-type
| +--rw initial-contact? boolean | +--rw initial-contact? boolean
| +--rw version? auth-protocol-type | +--rw version? auth-protocol-type
| +--rw fragmentation | +--rw fragmentation
| | +--rw enable? boolean | | +--rw enabled? boolean
| | +--rw mtu? uint16 | | +--rw mtu? uint16
| +--rw ike-sa-lifetime-soft | +--rw ike-sa-lifetime-soft
| | +--rw rekey-time? uint32 | | +--rw rekey-time? uint32
| | +--rw reauth-time? uint32 | | +--rw reauth-time? uint32
| +--rw ike-sa-lifetime-hard | +--rw ike-sa-lifetime-hard
| | +--rw over-time? uint32 | | +--rw over-time? uint32
| +--rw ike-sa-intr-alg* nsfikec:intr-alg-t | +--rw ike-sa-intr-alg* nsfikec:intr-alg-t
| +--rw ike-sa-encr-alg* [id] | +--rw ike-sa-encr-alg* [id]
| | +--rw id uint16 | | +--rw id uint16
| | +--rw algorithm-type? nsfikec:encr-alg-t | | +--rw algorithm-type? nsfikec:encr-alg-t
skipping to change at line 1699 skipping to change at line 1491
| | | +--rw start inet:port-number | | | +--rw start inet:port-number
| | | +--rw end inet:port-number | | | +--rw end inet:port-number
| | +--rw processing-info | | +--rw processing-info
| | +--rw action? ipsec-spd-action | | +--rw action? ipsec-spd-action
| | +--rw ipsec-sa-cfg | | +--rw ipsec-sa-cfg
| | +--rw pfp-flag? boolean | | +--rw pfp-flag? boolean
| | +--rw ext-seq-num? boolean | | +--rw ext-seq-num? boolean
| | +--rw seq-overflow? boolean | | +--rw seq-overflow? boolean
| | +--rw stateful-frag-check? boolean | | +--rw stateful-frag-check? boolean
| | +--rw mode? ipsec-mode | | +--rw mode? ipsec-mode
| | +--rw protocol-parameters? ipsec-protocol-parameters | | +--rw protocol-parameters? ipsec-protocol-params
| | +--rw esp-algorithms | | +--rw esp-algorithms
| | | +--rw integrity* intr-alg-t | | | +--rw integrity* intr-alg-t
| | | +--rw encryption* [id] | | | +--rw encryption* [id]
| | | | +--rw id uint16 | | | | +--rw id uint16
| | | | +--rw algorithm-type? encr-alg-t | | | | +--rw algorithm-type? encr-alg-t
| | | | +--rw key-length? uint16 | | | | +--rw key-length? uint16
| | | +--rw tfc-pad? boolean | | | +--rw tfc-pad? boolean
| | +--rw tunnel | | +--rw tunnel
| | +--rw local inet:ip-address | | +--rw local inet:ip-address
| | +--rw remote inet:ip-address | | +--rw remote inet:ip-address
skipping to change at line 1747 skipping to change at line 1539
| | +--ro sport? inet:port-number | | +--ro sport? inet:port-number
| | +--ro dport? inet:port-number | | +--ro dport? inet:port-number
| | +--ro oaddr* inet:ip-address | | +--ro oaddr* inet:ip-address
| +--ro established? uint64 | +--ro established? uint64
| +--ro current-rekey-time? uint64 | +--ro current-rekey-time? uint64
| +--ro current-reauth-time? uint64 | +--ro current-reauth-time? uint64
+--ro number-ike-sas +--ro number-ike-sas
+--ro total? yang:gauge64 +--ro total? yang:gauge64
+--ro half-open? yang:gauge64 +--ro half-open? yang:gauge64
+--ro half-open-cookies? yang:gauge64 +--ro half-open-cookies? yang:gauge64
]]> ]]></sourcecode>
</artwork> <t>
</figure>
</t>
<t>
The YANG data model consists of a unique The YANG data model consists of a unique
"ipsec-ike" "ipsec-ike"
container defined as follows. Firstly, it container defined as follows. Firstly, it
contains a "pad" container that serves to contains a "pad" container that serves to
configure the Peer Authentication Database configure the Peer Authentication Database
with authentication information about local with authentication information about local
and remote peers (NSFs). More precisely, it and remote peers (NSFs). More precisely, it
consists of a list of entries, each one consists of a list of entries, each one
indicating the identity, authentication method indicating the identity, authentication method,
and credentials that a particular peer (local or and credentials that a particular peer (local or
remote) will use. Therefore, each entry contains remote) will use. Therefore, each entry contains
identity, authentication information, and identity, authentication information, and
credentials of either the local NSF or the credentials of either the local NSF or the
remote NSF. As a consequence, the I2NF Controller can remote NSF. As a consequence, the I2NF Controller can
store identity, authentication information and store identity, authentication information, and
credentials for the local NSF and the remote credentials for the local NSF and the remote
NSF. NSF.
</t> </t>
<t> Next, a list "conn-entry" is defined with
<t> Next, a list "conn-entry" is defined with
information about the different IKE connections information about the different IKE connections
a peer can maintain with others. Each connection a peer can maintain with others. Each connection
entry is composed of a wide number of parameters entry is composed of a wide number of parameters
to configure different aspects of a particular to configure different aspects of a particular
IKE connection between two peers: local and IKE connection between two peers: local and
remote peer authentication information; IKE SA remote peer authentication information, IKE SA
configuration (soft and hard lifetimes, configuration (soft and hard lifetimes,
cryptographic algorithms, etc.); list of IPsec cryptographic algorithms, etc.), a list of IPsec
policies describing the type of network traffic policies describing the type of network traffic
to be secured (local/remote subnet and ports, to be secured (local/remote subnet and ports,
etc.) and how must be protected (ESP, etc.) and how it must be protected (ESP,
tunnel/transport, cryptographic algorithms, tunnel/transport, cryptographic algorithms,
etc.); CHILD SA configuration (soft and hard etc.), Child SA configuration (soft and hard
lifetimes); and, state information of the IKE lifetimes), and state information of the IKE
connection (SPIs, usage of NAT, current connection (SPIs, usage of NAT, current
expiration times, etc.). expiration times, etc.).
</t> </t>
<t>Lastly, the "ipsec-ike" container declares a
<t>Lastly, the "ipsec-ike" container declares a
"number-ike-sas" container to specify state "number-ike-sas" container to specify state
information reported by the IKE software related information reported by the IKE software related
to the amount of IKE connections established. to the amount of IKE connections established.
</t> </t>
</section>
</section> <section anchor="ike-example" numbered="true" toc="default">
<section anchor="ike-example" title="Example Usage"> <name>Example Usage</name>
<t><xref target="appendix-d" format="default"/> shows an example
<t><xref target="appendix-d"/> shows an example of IKE case configuration for an NSF, in tunnel
of IKE case configuration for a NSF, in tunnel mode (gateway-to-gateway), with NSF
mode (gateway-to-gateway), with NSFs
authentication based on X.509 certificates.</t> authentication based on X.509 certificates.</t>
</section>
<section anchor="ike-module" numbered="true" toc="default">
<name>YANG Module</name>
<t>This YANG module has normative references to <xref target="RFC5280"
format="default"/>, <xref target="RFC4301" format="default"/>, <xref target="RF
C5915" format="default"/>, <xref target="RFC6991" format="default"/>, <xref targ
et="RFC7296" format="default"/>, <xref target="RFC7383" format="default"/>, <xre
f target="RFC7427" format="default"/>, <xref target="RFC7619" format="default"/>
, <xref target="RFC8017" format="default"/>, <xref target="ITU-T.X.690" format="
default"/>, <xref target="RFC5322" format="default"/>, <xref target="RFC8229" fo
rmat="default"/>, <xref target="RFC8174" format="default"/>, <xref target="RFC69
60" format="default"/>, <xref target="IKEv2-Auth-Method" format="default"/>, <xr
ef target="IKEv2-Transform-Type-4" format="default"/>, <xref target="IKEv2-Param
eters" format="default"/>, and <xref target="IANA-Method-Type" format="default"/
>.
</t>
<sourcecode name="ietf-i2nsf-ike@2021-06-09.yang" type="yang" markers="true"><![
CDATA[
</section> module ietf-i2nsf-ike {
yang-version 1.1;
<section anchor="ike-module" title="YANG Module"> namespace "urn:ietf:params:xml:ns:yang:ietf-i2nsf-ike";
prefix nsfike;
<t>
This YANG module has normative references to <xref targe
t="RFC2247"/>, <xref target="RFC5280"/>, <xref target="RFC4301"/>, <xref target=
"RFC5280"/>, <xref target="RFC5915"/>, <xref target="RFC6991"/>, <xref target="R
FC7296"/>, <xref target="RFC7383"/>, <xref target="RFC7427"/>, <xref target="RFC
7619"/>, <xref target="RFC8017"/>, <xref target="ITU-T.X.690"/>, <xref target="R
FC5322"/>, <xref target="RFC8229"/>, <xref target="RFC8174"/>, <xref target="IKE
v2-Auth-Method"/>, <xref target="IKEv2-Transform-Type-4"/>, <xref target="IKEv2-
Parameters"/> and <xref target="IANA-Method-Type"/>.
</t>
<t>
<figure>
<artwork>
<![CDATA[
<CODE BEGINS> file "ietf-i2nsf-ike@2021-03-18.yang"
module ietf-i2nsf-ike {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-i2nsf-ike";
prefix "nsfike";
import ietf-inet-types {
prefix inet;
reference "RFC 6991: Common YANG Data Types";
}
import ietf-yang-types {
prefix yang;
reference "RFC 6991: Common YANG Data Types";
}
import ietf-i2nsf-ikec {
prefix nsfikec;
reference
"RFC XXXX: Software-Defined Networking
(SDN)-based IPsec Flow Protection.";
}
import ietf-netconf-acm {
prefix nacm;
reference
"RFC 8341: Network Configuration Access Control
Model.";
}
organization "IETF I2NSF Working Group"; import ietf-inet-types {
prefix inet;
reference
"RFC 6991: Common YANG Data Types.";
}
import ietf-yang-types {
prefix yang;
reference
"RFC 6991: Common YANG Data Types.";
}
import ietf-i2nsf-ikec {
prefix nsfikec;
reference
"RFC 9061: A YANG Data Model for IPsec Flow Protection
Based on Software-Defined Networking (SDN).";
}
import ietf-netconf-acm {
prefix nacm;
reference
"RFC 8341: Network Configuration Access Control
Model.";
}
contact organization
"WG Web: <https://datatracker.ietf.org/wg/i2nsf/> "IETF I2NSF Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/i2nsf/>
WG List: <mailto:i2nsf@ietf.org> WG List: <mailto:i2nsf@ietf.org>
Author: Rafael Marin-Lopez Author: Rafael Marin-Lopez
<mailto:rafa@um.es> <mailto:rafa@um.es>
Author: Gabriel Lopez-Millan Author: Gabriel Lopez-Millan
<mailto:gabilm@um.es> <mailto:gabilm@um.es>
Author: Fernando Pereniguez-Garcia Author: Fernando Pereniguez-Garcia
<mailto:fernando.pereniguez@cud.upct.es> <mailto:fernando.pereniguez@cud.upct.es>
"; ";
description
description "This module contains the IPsec IKE case model for the SDN-based
"This module contains IPsec IKE case model for the SDN-based
IPsec flow protection service. IPsec flow protection service.
Copyright (c) 2020 IETF Trust and the persons identified as 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 BCP 14
(RFC 2119) (RFC 8174) when, and only when, they appear
in all capitals, as shown here.
Copyright (c) 2021 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 Simplified BSD License to the license terms contained in, the Simplified 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
(http://trustee.ietf.org/license-info). (http://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 9061; see
the RFC itself for full legal notices. the RFC itself for full legal notices.";
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 BCP 14
(RFC 2119) (RFC 8174) when, and only when, they appear
in all capitals, as shown here.";
revision "2021-03-18" { revision 2021-06-09 {
description "Initial version."; description
reference "Initial version.";
"RFC XXXX: Software-Defined Networking reference
(SDN)-based IPsec Flow Protection."; "RFC 9061: A YANG Data Model for IPsec Flow Protection
} Based on Software-Defined Networking (SDN).";
}
typedef ike-spi { typedef ike-spi {
type uint64 { range "0..max"; } type uint64 {
description range "0..max";
"Security Parameter Index (SPI)'s IKE SA."; }
reference description
"Section 2.6 in RFC 7296."; "Security Parameter Index (SPI)'s IKE SA.";
} reference
"RFC 7296: Internet Key Exchange Protocol Version 2
(IKEv2), Section 2.6.";
}
typedef autostartup-type { typedef autostartup-type {
type enumeration { type enumeration {
enum add { enum add {
description description
"IKE/IPsec configuration is only loaded into "IKE/IPsec configuration is only loaded into
IKE implementation but IKE/IPsec SA is not IKE implementation, but IKE/IPsec SA is not
started."; started.";
} }
enum on-demand { enum on-demand {
description description
"IKE/IPsec configuration is loaded "IKE/IPsec configuration is loaded
into IKE implementation. The IPsec policies into IKE implementation. The IPsec policies
are transferred to the NSF but the are transferred to the NSF, but the
IPsec SAs are not established immediately. IPsec SAs are not established immediately.
The IKE implementation will negotiate the The IKE implementation will negotiate the
IPsec SAs when they are required. IPsec SAs when they are required
(i.e. through an ACQUIRE notification)."; (i.e., through an ACQUIRE notification).";
} }
enum start { enum start {
description description
"IKE/IPsec configuration is loaded "IKE/IPsec configuration is loaded
and transferred to the NSF's kernel, and the and transferred to the NSF's kernel, and the
IKEv2 based IPsec SAs are established IKEv2-based IPsec SAs are established
immediately without waiting for any packet."; immediately without waiting for any packet.";
} }
} }
description description
"Different policies to set IPsec SA configuration "Different policies to set IPsec SA configuration
into NSF's kernel when IKEv2 implementation has into NSF's kernel when IKEv2 implementation has
started."; started.";
} }
typedef fs-group { typedef fs-group {
type uint16; type uint16;
description description
"DH groups for IKE and IPsec SA rekey."; "DH groups for IKE and IPsec SA rekey.";
reference reference
"IANA; Internet Key Exchange V2 (IKEv2) Parameters; "IANA: Internet Key Exchange Version 2 (IKEv2) Parameters,
Transform Atribute Types; Transform Type 4 - IKEv2 Transform Attribute Types, Transform Type 4 -
Diffie-Hellman Group Transform IDs. Diffie-Hellman Group Transform IDs
Section 3.3.2 in RFC 7296."; RFC 7296: Internet Key Exchange Protocol Version 2
} (IKEv2), Section 3.3.2.";
}
typedef auth-protocol-type { typedef auth-protocol-type {
type enumeration { type enumeration {
enum ikev2 { enum ikev2 {
value 2; value 2;
description description
"IKEv2 authentication protocol. It is the "IKEv2 authentication protocol. It is the
only one defined right now. An enum is only one defined right now. An enum is
used for further extensibility."; used for further extensibility.";
} }
} }
description description
"IKE authentication protocol version specified in the "IKE authentication protocol version specified in the
Peer Authorization Database (PAD). It is defined as Peer Authorization Database (PAD). It is defined as
enumerated to allow new IKE versions in the enumerated to allow new IKE versions in the
future."; future.";
reference reference
"RFC 7296."; "RFC 7296: Internet Key Exchange Protocol Version 2
} (IKEv2).";
}
typedef auth-method-type { typedef auth-method-type {
type enumeration { type enumeration {
enum pre-shared { enum pre-shared {
description description
"Select pre-shared key as the "Select pre-shared key as the
authentication method."; authentication method.";
reference reference
"RFC 7296."; "RFC 7296: Internet Key Exchange Protocol Version 2
} (IKEv2).";
enum eap { }
description enum eap {
"Select EAP as the authentication method."; description
reference "Select the Extensible Authentication Protocol (EAP) as
"RFC 7296."; the authentication method.";
} reference
enum digital-signature { "RFC 7296: Internet Key Exchange Protocol Version 2
description (IKEv2).";
"Select digital signature as the authentication method."; }
reference enum digital-signature {
"RFC 7296 and RFC 7427."; description
} "Select digital signature as the authentication method.";
enum null { reference
description "RFC 7296: Internet Key Exchange Protocol Version 2
"Null authentication."; (IKEv2)
reference RFC 7427: Signature Authentication in the Internet Key
"RFC 7619."; Exchange Version 2 (IKEv2).";
} }
} enum null {
description description
"Peer authentication method specified in the Peer "Null authentication.";
reference
"RFC 7619: The NULL Authentication Method in the Internet
Key Exchange Protocol Version 2 (IKEv2).";
}
}
description
"Peer authentication method specified in the Peer
Authorization Database (PAD)."; Authorization Database (PAD).";
} }
container ipsec-ike { container ipsec-ike {
description description
"IKE configuration for a NSF. It includes PAD "IKE configuration for an NSF. It includes PAD
parameters, IKE connection information and state parameters, IKE connection information, and state
data."; data.";
container pad {
container pad { description
description "Configuration of the Peer Authorization Database
"Configuration of the Peer Authorization Database (PAD). Each entry of PAD contains authentication
(PAD). Each entry of PAD contains authentication
information of either the local peer or the remote peer. information of either the local peer or the remote peer.
Therefore, the I2NSF Controller stores authentication Therefore, the I2NSF Controller stores authentication
information (and credentials) not only for the remote NSF information (and credentials) not only for the remote NSF
but also for the local NSF. The local NSF MAY use the but also for the local NSF. The local NSF MAY use the
same identity for different types of authentication same identity for different types of authentication
and credentials. Pointing to the entry for a local NSF and credentials. Pointing to the entry for a local NSF
(e.g., A) and the entry for remote NSF (e.g., B) (e.g., A) and the entry for remote NSF (e.g., B)
is possible to specify all the required information to is possible to specify all the required information to
carry out the authentication between A and B (see carry out the authentication between A and B (see
../conn-entry/local and ../conn-entry/remote)."; ../conn-entry/local and ../conn-entry/remote).";
list pad-entry {
list pad-entry { key "name";
key "name"; ordered-by user;
ordered-by user; description
description "Peer Authorization Database (PAD) entry. It
"Peer Authorization Database (PAD) entry. It
is a list of PAD entries ordered by the is a list of PAD entries ordered by the
I2NSF Controller and each entry is I2NSF Controller, and each entry is
univocally identified by a name"; unequivocally identified by a name.";
leaf name { leaf name {
type string; type string;
description description
"PAD unique name to identify this "PAD-unique name to identify this
entry."; entry.";
} }
choice identity { choice identity {
mandatory true; mandatory true;
description description
"A particular IKE peer will be "A particular IKE peer will be
identified by one of these identities. identified by one of these identities.
This peer can be a remote peer or local This peer can be a remote peer or local
peer (this NSF)."; peer (this NSF).";
reference reference
"Section 4.4.3.1 in RFC 4301."; "RFC 4301: Security Architecture for the Internet
case ipv4-address { Protocol, Section 4.4.3.1.";
leaf ipv4-address { case ipv4-address {
type inet:ipv4-address; leaf ipv4-address {
description type inet:ipv4-address;
"Specifies the identity as description
a single four (4) octet IPv4 address."; "Specifies the identity as
} a single 4-octet IPv4 address.";
} }
case ipv6-address{ }
leaf ipv6-address { case ipv6-address {
type inet:ipv6-address; leaf ipv6-address {
description type inet:ipv6-address;
"Specifies the identity as a description
single sixteen (16) octet IPv6 "Specifies the identity as a
address. An example is single 16-octet IPv6
address. An example is
2001:db8::8:800:200c:417a."; 2001:db8::8:800:200c:417a.";
} }
} }
case fqdn-string { case fqdn-string {
leaf fqdn-string { leaf fqdn-string {
type inet:domain-name; type inet:domain-name;
description description
"Specifies the identity as a "Specifies the identity as a
Fully-Qualified Domain Name Fully Qualified Domain Name
(FQDN) string. An example is: (FQDN) string. An example is
example.com. The string MUST example.com. The string MUST
NOT contain any terminators NOT contain any terminators
(e.g., NULL, CR, etc.)."; (e.g., NULL, Carriage Return
} (CR), etc.).";
} }
case rfc822-address-string { }
leaf rfc822-address-string { case rfc822-address-string {
type string; leaf rfc822-address-string {
description type string;
"Specifies the identity as a description
fully-qualified RFC5322 email "Specifies the identity as a
address string. An example is, fully qualified email address
jsmith@example.com. The string string (RFC 5322). An example is
jsmith@example.com. The string
MUST NOT contain any MUST NOT contain any
terminators (e.g., NULL, CR, terminators (e.g., NULL, CR,
etc.)."; etc.).";
reference reference
"RFC 5322."; "RFC 5322: Internet Message Format.";
} }
} }
case dnx509 { case dnx509 {
leaf dnx509 { leaf dnx509 {
type binary; type binary;
description description
"The binary "The binary
Distinguished Encoding Rules (DER) Distinguished Encoding Rules (DER)
encoding of an ASN.1 X.500 encoding of an ASN.1 X.500
Distinguished Name, as specified in IKEv2."; Distinguished Name, as specified in IKEv2.";
reference reference
"RFC 5280. Section 3.5 in RFC 7296."; "RFC 5280: Internet X.509 Public Key Infrastructure
} Certificate and Certificate Revocation
} List (CRL) Profile
case gnx509 { RFC 7296: Internet Key Exchange Protocol Version 2
leaf gnx509 { (IKEv2), Section 3.5.";
type binary; }
description }
"ASN.1 X.509 GeneralName case gnx509 {
structure as leaf gnx509 {
specified in RFC 5280, type binary;
encoded using ASN.1 description
distinguished encoding rules "ASN.1 X.509 GeneralName structure,
(DER), as specified in ITU-T as specified in RFC 5280, encoded
X.690."; using ASN.1 Distinguished Encoding Rules
reference (DER), as specified in ITU-T X.690.";
"RFC 5280"; reference
} "RFC 5280: Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation
} List (CRL) Profile.";
case id-key { }
leaf id-key { }
type binary; case id-key {
description leaf id-key {
"Opaque octet stream that may be type binary;
description
"Opaque octet stream that may be
used to pass vendor-specific used to pass vendor-specific
information for proprietary information for proprietary
types of identification."; types of identification.";
reference reference
"Section 3.5 in RFC 7296."; "RFC 7296: Internet Key Exchange Protocol Version 2
} (IKEv2), Section 3.5.";
} }
case id-null { }
leaf id-null { case id-null {
type empty; leaf id-null {
description type empty;
"The ID_NULL identification is used description
"The ID_NULL identification is used
when the IKE identification payload when the IKE identification payload
is not used." ; is not used.";
reference reference
"RFC 7619."; "RFC 7619: The NULL Authentication Method in the
} Internet Key Exchange Protocol Version 2
} (IKEv2).";
} }
}
leaf auth-protocol { }
type auth-protocol-type; leaf auth-protocol {
default ikev2; type auth-protocol-type;
description default "ikev2";
"Only IKEv2 is supported right now but description
"Only IKEv2 is supported right now, but
other authentication protocols may be other authentication protocols may be
supported in the future."; supported in the future.";
} }
container peer-authentication { container peer-authentication {
description description
"This container allows the Security "This container allows the security
Controller to configure the controller to configure the
authentication method (pre-shared key, authentication method (pre-shared key,
eap, digitial-signature, null) that eap, digital-signature, null) that
will be used with a particular peer and will be used with a particular peer and
the credentials to use, which will the credentials to use, which will
depend on the selected authentication depend on the selected authentication
method."; method.";
leaf auth-method {
leaf auth-method { type auth-method-type;
type auth-method-type; default "pre-shared";
default pre-shared; description
description "Type of authentication method
"Type of authentication method (pre-shared key, eap, digital signature,
(pre-shared, eap, digital signature, null).";
null)."; reference
reference "RFC 7296: Internet Key Exchange Protocol Version 2
"Section 2.15 in RFC 7296."; (IKEv2), Section 2.15.";
} }
container eap-method { container eap-method {
when "../auth-method = 'eap'"; when "../auth-method = 'eap'";
leaf eap-type { leaf eap-type {
type uint32 {range "1 .. 4294967295"; } type uint32 {
mandatory true; range "1 .. 4294967295";
description }
"EAP method type specified with mandatory true;
description
"EAP method type specified with
a value extracted from the a value extracted from the
IANA Registry. This IANA registry. This
information provides the information provides the
particular EAP method to be particular EAP method to be
used. Depending on the EAP used. Depending on the EAP
method, pre-shared keys or method, pre-shared keys or
certificates may be used."; certificates may be used.";
} }
description description
"EAP method description used when "EAP method description used when
authentication method is 'eap'."; authentication method is 'eap'.";
reference reference
"IANA Registry; Extensible Authentication "IANA: Extensible Authentication Protocol (EAP)
Protocol (EAP); Registry; Method Types. Registry, Method Types
Section 2.16 in RFC 7296."; RFC 7296: Internet Key Exchange Protocol Version 2
} (IKEv2), Section 2.16.";
container pre-shared { }
when container pre-shared {
"../auth-method[.='pre-shared' or when "../auth-method[.='pre-shared' or
.='eap']"; .='eap']";
leaf secret { leaf secret {
nacm:default-deny-all; nacm:default-deny-all;
type yang:hex-string; type yang:hex-string;
description description
"Pre-shared secret value. The "Pre-shared secret value. The
NSF has to prevent read access NSF has to prevent read access
to this value for security to this value for security
reasons. This value MUST be reasons. This value MUST be
set if the EAP method uses a set if the EAP method uses a
pre-shared key or pre-shared pre-shared key or pre-shared
authentication has been chosen."; authentication has been chosen.";
} }
description description
"Shared secret value for PSK or "Shared secret value for PSK or
EAP method authentication based on EAP method authentication based on
PSK."; PSK.";
} }
container digital-signature { container digital-signature {
when when "../auth-method[.='digital-signature'
"../auth-method[.='digital-signature' or .='eap']";
or .='eap']"; leaf ds-algorithm {
leaf ds-algorithm { type uint8;
type uint8; default "14";
default 14; description
description "The digital signature
"The digital signature
algorithm is specified with a algorithm is specified with a
value extracted from the IANA value extracted from the IANA
Registry. Default is the generic registry. Default is the generic
Digital Signature method. Depending digital signature method. Depending
on the algorithm, the following leafs on the algorithm, the following leafs
MUST contain information. For MUST contain information. For
example if digital signature or the example, if digital signature or the
EAP method involves a certificate EAP method involves a certificate,
then leaf 'cert-data' and 'private-key' then leaves 'cert-data' and 'private-key'
will contain this information."; will contain this information.";
reference reference
"IANA Registry; Internet Key "IANA: Internet Key Exchange Version 2 (IKEv2)
Exchange Version 2 (IKEv2); Parameters, IKEv2 Authentication Method.";
Parameters; IKEv2 Authentication Method."; }
} choice public-key {
leaf raw-public-key {
choice public-key { type binary;
leaf raw-public-key { description
type binary; "A binary that contains the
description
"A binary that contains the
value of the public key. The value of the public key. The
interpretation of the content interpretation of the content
is defined by the digital is defined by the digital
signature algorithm. For signature algorithm. For
example, an RSA key is example, an RSA key is
represented as RSAPublicKey as represented as RSAPublicKey, as
defined in RFC 8017, and an defined in RFC 8017, and an
Elliptic Curve Cryptography Elliptic Curve Cryptography
(ECC) key is represented (ECC) key is represented
using the 'publicKey' using the 'publicKey'
described in RFC 5915."; described in RFC 5915.";
} reference
"RFC 5915: Elliptic Curve Private Key
leaf cert-data { Structure
type binary; RFC 8017: PKCS #1: RSA Cryptography
description Specifications Version 2.2.";
"X.509 certificate data in DER }
format. If raw-public-key is leaf cert-data {
type binary;
description
"X.509 certificate data in DER
format. If raw-public-key is
defined, this leaf is empty."; defined, this leaf is empty.";
reference "RFC 5280"; reference
} "RFC 5280: Internet X.509 Public Key
description Infrastructure Certificate
"If the I2NSF Controller and Certificate Revocation
List (CRL) Profile.";
}
description
"If the I2NSF Controller
knows that the NSF knows that the NSF
already owns a private key already owns a private key
associated to this public key associated to this public key
(e.g., the NSF generated the pair (e.g., the NSF generated the pair
public key/private key out of public key/private key out of
band), it will only configure band), it will only configure
one of the leaf of this one of the leaves of this
choice but not the leaf choice but not the leaf
private-key. The NSF, based on private-key. The NSF, based on
the public key value, can know the public key value, can know
the private key to be used."; the private key to be used.";
} }
leaf private-key { leaf private-key {
nacm:default-deny-all; nacm:default-deny-all;
type binary; type binary;
description description
"A binary that contains the "A binary that contains the
value of the private key. The value of the private key. The
interpretation of the content interpretation of the content
is defined by the digital is defined by the digital
signature algorithm. For signature algorithm. For
example, an RSA key is example, an RSA key is
represented as RSAPrivateKey as represented as RSAPrivateKey, as
defined in RFC 8017, and an defined in RFC 8017, and an
Elliptic Curve Cryptography Elliptic Curve Cryptography
(ECC) key is represented as (ECC) key is represented as
ECPrivateKey as defined in RFC ECPrivateKey, as defined in RFC
5915. This value is set 5915. This value is set
if public-key is defined and if public key is defined and the
I2NSF controller is in charge I2NSF Controller is in charge
of configuring the of configuring the
private-key. Otherwise, it is private key. Otherwise, it is
not set and the value is not set and the value is
kept in secret."; kept in secret.";
} reference
leaf-list ca-data { "RFC 5915: Elliptic Curve Private Key
type binary; Structure
description RFC 8017: PKCS #1: RSA Cryptography
"List of trusted Certification Specifications Version 2.2.";
Authorities (CA) certificates }
leaf-list ca-data {
type binary;
description
"List of trusted Certification
Authorities (CAs) certificates
encoded using ASN.1 encoded using ASN.1
distinguished encoding rules Distinguished Encoding Rules
(DER). If it is not defined (DER). If it is not defined,
the default value is empty."; the default value is empty.";
} }
leaf crl-data { leaf crl-data {
type binary; type binary;
description description
"A CertificateList structure, as "A CertificateList structure, as
specified in RFC 5280, specified in RFC 5280,
encoded using ASN.1 encoded using ASN.1
distinguished encoding rules Distinguished Encoding Rules
(DER),as specified in ITU-T (DER), as specified in ITU-T
X.690. If it is not defined X.690. If it is not defined,
the default value is empty."; the default value is empty.";
reference reference
"RFC 5280"; "RFC 5280: Internet X.509 Public Key Infrastructure
} Certificate and Certificate Revocation
leaf crl-uri { List (CRL) Profile.";
type inet:uri; }
description leaf crl-uri {
"X.509 CRL certificate URI. type inet:uri;
If it is not defined description
"X.509 Certificate Revocation List
(CRL) certificate URI.
If it is not defined,
the default value is empty."; the default value is empty.";
reference reference
"RFC 5280"; "RFC 5280: Internet X.509 Public Key Infrastructure
} Certificate and Certificate Revocation
leaf oscp-uri { List (CRL) Profile.";
type inet:uri; }
description leaf oscp-uri {
"OCSP URI. type inet:uri;
If it is not defined description
"Online Certificate Status Protocol
(OCSP) URI. If it is not defined,
the default value is empty."; the default value is empty.";
reference reference
"RFC 2560 and RFC 5280"; "RFC 6960: X.509 Internet Public Key Infrastructure
} Online Certificate Status Protocol - OCSP
description RFC 5280: Internet X.509 Public Key Infrastructure
"Digital Signature container."; Certificate and Certificate Revocation
} /*container digital-signature*/ List (CRL) Profile.";
} /*container peer-authentication*/ }
} description
} "digital-signature container.";
} /*container digital-signature*/
list conn-entry { } /*container peer-authentication*/
key "name"; }
description }
"IKE peer connection information. This list list conn-entry {
key "name";
description
"IKE peer connection information. This list
contains the IKE connection for this peer contains the IKE connection for this peer
with other peers. This will create in with other peers. This will create, in
real time IKE Security Associations real time, IKE Security Associations
established with these nodes."; established with these nodes.";
leaf name { leaf name {
type string; type string;
description description
"Identifier for this connection "Identifier for this connection
entry."; entry.";
} }
leaf autostartup { leaf autostartup {
type autostartup-type; type autostartup-type;
default add; default "add";
description description
"By-default: Only add configuration "By default, only add configuration
without starting the security without starting the security
association."; association.";
} }
leaf initial-contact { leaf initial-contact {
type boolean; type boolean;
default false; default "false";
description description
"The goal of this value is to deactivate the "The goal of this value is to deactivate the
usage of INITIAL_CONTACT notification usage of INITIAL_CONTACT notification
(true). If this flag remains to false it (true). If this flag remains set to false, it
means the usage of the INITIAL_CONTACT means the usage of the INITIAL_CONTACT
notification will depend on the IKEv2 notification will depend on the IKEv2
implementation."; implementation.";
} }
leaf version { leaf version {
type auth-protocol-type; type auth-protocol-type;
default ikev2; default "ikev2";
description description
"IKE version. Only version 2 is supported."; "IKE version. Only version 2 is supported.";
} }
container fragmentation {
container fragmentation { leaf enabled {
leaf enable { type boolean;
type boolean; default "false";
default false; description
description "Whether or not to enable IKEv2
"Whether or not to enable IKEv2 fragmentation (true or false).";
fragmentation (true or reference
false)."; "RFC 7383: Internet Key Exchange Protocol Version 2
reference (IKEv2) Message Fragmentation.";
"RFC 7383."; }
} leaf mtu {
leaf mtu { when "../enabled='true'";
when "../enable='true'"; type uint16 {
type uint16 { range "68..65535"; } range "68..65535";
description }
"MTU that IKEv2 can use description
"MTU that IKEv2 can use
for IKEv2 fragmentation."; for IKEv2 fragmentation.";
reference reference
"RFC 7383."; "RFC 7383: Internet Key Exchange Protocol Version 2
} (IKEv2) Message Fragmentation.";
description }
"IKEv2 fragmentation as per RFC 7383. If the description
IKEv2 fragmentation is enabled it is possible "IKEv2 fragmentation, as per RFC 7383. If the
IKEv2 fragmentation is enabled, it is possible
to specify the MTU."; to specify the MTU.";
} }
container ike-sa-lifetime-soft {
container ike-sa-lifetime-soft { description
description "IKE SA lifetime soft. Two lifetime values
"IKE SA lifetime soft. Two lifetime values
can be configured: either rekey time of the can be configured: either rekey time of the
IKE SA or reauth time of the IKE SA. When IKE SA or reauth time of the IKE SA. When
the rekey lifetime expires a rekey of the the rekey lifetime expires, a rekey of the
IKE SA starts. When reauth lifetime IKE SA starts. When reauth lifetime
expires a IKE SA reauthentication starts."; expires, an IKE SA reauthentication starts.";
leaf rekey-time { leaf rekey-time {
type uint32; type uint32;
units "seconds"; units "seconds";
default 0; default "0";
description description
"Time in seconds between each IKE SA "Time in seconds between each IKE SA
rekey. The value 0 means infinite."; rekey. The value 0 means infinite.";
} }
leaf reauth-time { leaf reauth-time {
type uint32; type uint32;
units "seconds"; units "seconds";
default 0; default "0";
description description
"Time in seconds between each IKE SA "Time in seconds between each IKE SA
reauthentication. The value 0 means reauthentication. The value 0 means
infinite."; infinite.";
} }
reference reference
"Section 2.8 in RFC 7296."; "RFC 7296: Internet Key Exchange Protocol Version 2
} (IKEv2), Section 2.8.";
container ike-sa-lifetime-hard { }
description container ike-sa-lifetime-hard {
"Hard IKE SA lifetime. When this description
time is reached the IKE SA is removed."; "Hard IKE SA lifetime. When this
leaf over-time { time is reached, the IKE SA is removed.";
type uint32; leaf over-time {
units "seconds"; type uint32;
default 0; units "seconds";
description default "0";
"Time in seconds before the IKE SA is description
removed. The value 0 means infinite."; "Time in seconds before the IKE SA is
} removed. The value 0 means infinite.";
reference }
"RFC 7296."; reference
} "RFC 7296: Internet Key Exchange Protocol Version 2
leaf-list ike-sa-intr-alg { (IKEv2).";
type nsfikec:intr-alg-t; }
default 12; leaf-list ike-sa-intr-alg {
ordered-by user; type nsfikec:intr-alg-t;
description default "12";
"Integrity algorithm for establishing ordered-by user;
the IKE SA. This list is ordered following description
"Integrity algorithm for establishing
the IKE SA. This list is ordered following
from the higher priority to lower priority. from the higher priority to lower priority.
First node of the list will be the algorithm The first node of the list will be the
with higher priority. algorithm with higher priority.
Default value 12 (AUTH_HMAC_SHA2_256_128)"; Default value 12 (AUTH_HMAC_SHA2_256_128).";
} }
list ike-sa-encr-alg { list ike-sa-encr-alg {
key id; key "id";
min-elements 1; min-elements 1;
ordered-by user; ordered-by user;
leaf id { leaf id {
type uint16; type uint16;
description description
"An identifier that unequivocally "An identifier that unequivocally
identifies each entry of the list, identifies each entry of the list,
i.e., an encryption algorithm and i.e., an encryption algorithm and
its key-length (if required)"; its key length (if required).";
} }
leaf algorithm-type { leaf algorithm-type {
type nsfikec:encr-alg-t; type nsfikec:encr-alg-t;
default 12; default "12";
description description
"Default value 12 (ENCR_AES_CBC)"; "Default value 12 (ENCR_AES_CBC).";
} }
leaf key-length { leaf key-length {
type uint16; type uint16;
default 128; default "128";
description description
"By default key length is 128 bits"; "By default, key length is 128 bits.";
} }
description description
"Encryption or AEAD algorithm for the IKE "Encryption or AEAD algorithm for the IKE
SAs. This list is ordered following SAs. This list is ordered following
from the higher priority to lower priority. from the higher priority to lower priority.
First node of the list will be the algorithm The first node of the list will be the
with higher priority"; algorithm with higher priority.";
} }
leaf dh-group { leaf dh-group {
type fs-group; type fs-group;
default 14; default "14";
description description
"Group number for Diffie-Hellman "Group number for Diffie-Hellman
Exponentiation used during IKE_SA_INIT Exponentiation used during IKE_SA_INIT
for the IKE SA key exchange."; for the IKE SA key exchange.";
} }
leaf half-open-ike-sa-timer { leaf half-open-ike-sa-timer {
type uint32; type uint32;
units "seconds"; units "seconds";
default 0; default "0";
description description
"Set the half-open IKE SA timeout "Set the half-open IKE SA timeout
duration. The value 0 implies infinite."; duration. The value 0 implies infinite.";
reference reference
"Section 2 in RFC 7296."; "RFC 7296: Internet Key Exchange Protocol Version 2
} (IKEv2), Section 2.";
leaf half-open-ike-sa-cookie-threshold { }
type uint32; leaf half-open-ike-sa-cookie-threshold {
default 0; type uint32;
description default "0";
"Number of half-open IKE SAs that activate description
the cookie mechanism. The value 0 implies "Number of half-open IKE SAs that activate
infinite." ; the cookie mechanism. The value 0 implies
reference infinite.";
"Section 2.6 in RFC 7296."; reference
} "RFC 7296: Internet Key Exchange Protocol Version 2
container local { (IKEv2), Section 2.6.";
leaf local-pad-entry-name { }
type string; container local {
mandatory true; leaf local-pad-entry-name {
description type string;
"Local peer authentication information. mandatory true;
description
"Local peer authentication information.
This node points to a specific entry in This node points to a specific entry in
the PAD where the authorization the PAD where the authorization
information about this particular local information about this particular local
peer is stored. It MUST match a peer is stored. It MUST match a
pad-entry-name."; pad-entry-name.";
} }
description description
"Local peer authentication information."; "Local peer authentication information.";
} }
container remote { container remote {
leaf remote-pad-entry-name { leaf remote-pad-entry-name {
type string; type string;
mandatory true; mandatory true;
description description
"Remote peer authentication information. "Remote peer authentication information.
This node points to a specific entry in This node points to a specific entry in
the PAD where the authorization the PAD where the authorization
information about this particular information about this particular
remote peer is stored. It MUST match a remote peer is stored. It MUST match a
pad-entry-name."; pad-entry-name.";
} }
description description
"Remote peer authentication information."; "Remote peer authentication information.";
} }
container encapsulation-type { container encapsulation-type {
uses nsfikec:encap; uses nsfikec:encap;
description description
"This container carries configuration "This container carries configuration
information about the source and destination information about the source and destination
ports of encapsulation that IKE should use ports of encapsulation that IKE should use
and the type of encapsulation that and the type of encapsulation that
should use when NAT traversal is required. should be used when NAT traversal is required.
However, this is just a best effort since However, this is just a best effort since
the IKE implementation may need to use a the IKE implementation may need to use a
different encapsulation as different encapsulation, as described in
described in RFC 8229."; RFC 8229.";
reference reference
"RFC 8229."; "RFC 8229: TCP Encapsulation of IKE and IPsec
} Packets.";
container spd { }
description container spd {
"Configuration of the Security Policy description
Database (SPD). This main information is "Configuration of the Security Policy
Database (SPD). This main information is
placed in the grouping placed in the grouping
ipsec-policy-grouping."; ipsec-policy-grouping.";
list spd-entry { list spd-entry {
key "name"; key "name";
ordered-by user; ordered-by user;
leaf name { leaf name {
type string; type string;
description description
"SPD entry unique name to identify "SPD-entry-unique name to identify
the IPsec policy."; the IPsec policy.";
} }
container ipsec-policy-config { container ipsec-policy-config {
description description
"This container carries the "This container carries the
configuration of a IPsec policy."; configuration of an IPsec policy.";
uses nsfikec:ipsec-policy-grouping; uses nsfikec:ipsec-policy-grouping;
} }
description description
"List of entries which will constitute "List of entries that will constitute
the representation of the SPD. In this the representation of the SPD. In this
case, since the NSF implements IKE, it case, since the NSF implements IKE, it
is only required to send a IPsec policy is only required to send an IPsec policy
from this NSF where 'local' is this NSF from this NSF where 'local' is this NSF
and 'remote' the other NSF. The IKE and 'remote' the other NSF. The IKE
implementation will install IPsec implementation will install IPsec
policies in the NSF's kernel in both policies in the NSF's kernel in both
directions (inbound and outbound) and directions (inbound and outbound) and
their corresponding IPsec SAs based on their corresponding IPsec SAs based on
the information in this SPD entry."; the information in this SPD entry.";
} }
reference reference
"Section 2.9 in RFC 7296."; "RFC 7296: Internet Key Exchange Protocol Version 2
} (IKEv2), Section 2.9.";
container child-sa-info { }
leaf-list fs-groups { container child-sa-info {
type fs-group; leaf-list fs-groups {
default 0; type fs-group;
ordered-by user; default "0";
description ordered-by user;
"If non-zero, forward secrecy is description
"If non-zero, forward secrecy is
required when a new IPsec SA is being required when a new IPsec SA is being
created. The (non-zero) value indicates created, the (non-zero) value indicates
the group number to use for the key the group number to use for the key
exchange process used to achieve forward exchange process used to achieve forward
secrecy. secrecy.
This list is ordered following from the This list is ordered following from the
higher priority to lower priority. First higher priority to lower priority. The
node of the list will be the algorithm first node of the list will be the
with higher priority."; algorithm with higher priority.";
} }
container child-sa-lifetime-soft { container child-sa-lifetime-soft {
description description
"Soft IPsec SA lifetime. "Soft IPsec SA lifetime.
After the lifetime the action is After the lifetime, the action is
defined in this container defined in this container
in the leaf action."; in the leaf action.";
uses nsfikec:lifetime; uses nsfikec:lifetime;
leaf action { leaf action {
type nsfikec:lifetime-action; type nsfikec:lifetime-action;
default replace; default "replace";
description description
"When the lifetime of an IPsec SA "When the lifetime of an IPsec SA
expires an action needs to be expires, an action needs to be
performed over the IPsec SA that performed over the IPsec SA that
reached the lifetime. There are reached the lifetime. There are
three possible options: three possible options:
terminate-clear, terminate-hold and terminate-clear, terminate-hold, and
replace."; replace.";
reference reference
"Section 4.5 in RFC 4301 and Section 2.8 "RFC 4301: Security Architecture for the Internet
in RFC 7296."; Protocol, Section 4.5
} RFC 7296: Internet Key Exchange Protocol Version 2
} (IKEv2), Section 2.8.";
container child-sa-lifetime-hard { }
description }
"IPsec SA lifetime hard. The action will container child-sa-lifetime-hard {
description
"IPsec SA lifetime hard. The action will
be to terminate the IPsec SA."; be to terminate the IPsec SA.";
uses nsfikec:lifetime; uses nsfikec:lifetime;
reference reference
"Section 2.8 in RFC 7296."; "RFC 7296: Internet Key Exchange Protocol Version 2
} (IKEv2), Section 2.8.";
description }
"Specific information for IPsec SAs description
SAs. It includes PFS group and IPsec SAs "Specific information for IPsec SAs.
rekey lifetimes."; It includes the Perfect Forward Secrecy (PFS)
} group and IPsec SAs rekey lifetimes.";
container state { }
config false; container state {
leaf initiator { config false;
type boolean; leaf initiator {
description type boolean;
"It is acting as initiator for this description
"It is acting as an initiator for this
connection."; connection.";
} }
leaf initiator-ikesa-spi { leaf initiator-ikesa-spi {
type ike-spi; type ike-spi;
description description
"Initiator's IKE SA SPI."; "Initiator's IKE SA SPI.";
} }
leaf responder-ikesa-spi { leaf responder-ikesa-spi {
type ike-spi; type ike-spi;
description description
"Responder's IKE SA SPI."; "Responder's IKE SA SPI.";
} }
leaf nat-local { leaf nat-local {
type boolean; type boolean;
description description
"True, if local endpoint is behind a "True if local endpoint is behind a
NAT."; NAT.";
} }
leaf nat-remote { leaf nat-remote {
type boolean; type boolean;
description description
"True, if remote endpoint is behind "True if remote endpoint is behind
a NAT."; a NAT.";
} }
container encapsulation-type { container encapsulation-type {
uses nsfikec:encap; uses nsfikec:encap;
description description
"This container provides information "This container provides information
about the source and destination about the source and destination
ports of encapsulation that IKE is ports of encapsulation that IKE is
using, and the type of encapsulation using and the type of encapsulation
when NAT traversal is required."; when NAT traversal is required.";
reference reference
"RFC 8229."; "RFC 8229: TCP Encapsulation of IKE and IPsec Packets.";
} }
leaf established { leaf established {
type uint64; type uint64;
units "seconds"; units "seconds";
description description
"Seconds since this IKE SA has been "Seconds since this IKE SA has been
established."; established.";
} }
leaf current-rekey-time { leaf current-rekey-time {
type uint64; type uint64;
units "seconds"; units "seconds";
description description
"Seconds before IKE SA is rekeyed."; "Seconds before IKE SA is rekeyed.";
} }
leaf current-reauth-time { leaf current-reauth-time {
type uint64; type uint64;
units "seconds"; units "seconds";
description description
"Seconds before IKE SA is "Seconds before IKE SA is
re-authenticated."; reauthenticated.";
} }
description description
"IKE state data for a particular "IKE state data for a particular
connection."; connection.";
} /* ike-sa-state */ } /* ike-sa-state */
} /* ike-conn-entries */ } /* ike-conn-entries */
container number-ike-sas {
container number-ike-sas { config false;
config false; leaf total {
leaf total { type yang:gauge64;
type yang:gauge64; description
description "Total number of active IKE SAs.";
"Total number of active IKE SAs."; }
} leaf half-open {
leaf half-open { type yang:gauge64;
type yang:gauge64; description
description "Number of half-open active IKE SAs.";
"Number of half-open active IKE SAs."; }
} leaf half-open-cookies {
leaf half-open-cookies { type yang:gauge64;
type yang:gauge64; description
description "Number of half-open active IKE SAs with
"Number of half open active IKE SAs with
cookie activated."; cookie activated.";
} }
description description
"General information about the IKE SAs. In "General information about the IKE SAs. In
particular, it provides the current number of particular, it provides the current number of
IKE SAs."; IKE SAs.";
} }
} /* container ipsec-ike */ } /* container ipsec-ike */
} }
]]></sourcecode>
<CODE ENDS> </section>
</section>
]]> <section anchor="ike-less-model" numbered="true" toc="default">
<name>The 'ietf-i2nsf-ikeless' Module</name>
</artwork> <t>In this section, the YANG module for the IKE-less case is described.<
</figure> /t>
</t> <section anchor="ikeless-overview" numbered="true" toc="default">
<name>Data Model Overview</name>
</section> <t> For this case, the definition of the SPD model has been
mainly extracted from the specification in Section
</section> <xref target="RFC4301" section="4.4.1" sectionFormat="ba
re"/> and Appendix <xref target="RFC4301" section="D" sectionFormat="bare"/> in
<section anchor="ike-less-model" title="The 'ietf-i2nsf-ikeless' <xref target="RFC4301" format="default"/>,
Module ">
<t>In this section, the YANG module for the IKE-less case is d
escribed.</t>
<section anchor="ikeless-overview" title="Data model overview"
>
<t> For this case, the definition of the SPD model has been
mainly extracted from the specification in section
4.4.1 and Appendix D in <xref target="RFC4301"/>,
though with some changes, namely:</t> though with some changes, namely:</t>
<t> <ul spacing="normal">
<list style="symbols"> <li>For simplicity, each IPsec policy (spd-entry) contains one
<t>For simplicity, each IPsec policy (spd-entry) con Traffic Selector, instead of a list of them. The
tains one
traffic selector, instead of a list of them. The
reason is that actual kernel reason is that actual kernel
implementations only admit a single traffic implementations only admit a single Traffic
selector per IPsec policy.</t> Selector per IPsec policy.</li>
<t>Each IPsec policy contains an identifier (reqid) <li>Each IPsec policy contains an identifier (reqid)
to relate the policy with the IPsec SA. This is to relate the policy with the IPsec SA. This is
common in Linux-based systems.</t> common in Linux-based systems.</li>
<t>Each IPsec policy has only one name and not a <li>Each IPsec policy has only one name and not a
list of names.</t> list of names.</li>
<t>Combined algorithms have been removed because <li>Combined algorithms have been removed because
encryption algorithms MAY include authenticated encryption algorithms <bcp14>MAY</bcp14> include Aut
encryption with associated data (AEAD).</t> henticated
<t>Tunnel information has been extended Encryption with Associated Data (AEAD).</li>
<li>Tunnel information has been extended
with information about DSCP mapping. with information about DSCP mapping.
The reason is that certain kernel The reason is that certain kernel
implementations accept configuration of implementations accept configuration of
these values.</t> these values.</li>
</list> </ul>
</t> <t>The definition of the SAD model has been mainly
extracted from the specification in
<t>The definition of the SAD model has been mainly <xref target="RFC4301" sectionFormat="of" section="4.4.2"/>,
extracted from the specification in section 4.4.2 in though with some changes, namely:</t>
<xref target="RFC4301"/> though with some changes, <ul spacing="normal">
namely:</t> <li>For simplicity, each IPsec SA
<t> (sad-entry) contains one Traffic
<list style="symbols"> Selector, instead of a list of them. The
<t>For simplicity, each IPsec SA
(sad-entry) contains one traffic
selector, instead of a list of them. The
reason is that actual kernel reason is that actual kernel
implementations implementations
only admit a single traffic selector per only admit a single Traffic Selector per
IPsec SA.</t> IPsec SA.</li>
<li>Each IPsec SA contains an identifier (reqid) to
<t>Each IPsec SA contains a identifier (reqid) to relate the IPsec SA with the IPsec policy. The reaso
relate the IPsec SA with the IPsec Policy. The reaso n
n is that real kernel implementations allow
is that real kernel implementations allow to include this value to be included.</li>
this value.</t> <li>Each IPsec SA is also named in the same way as
IPsec policies.</li>
<t>Each IPsec SA has also a name in the same way as <li>The model allows specifying the
IPsec policies.</t> algorithm for encryption. This can be
<t>The model allows specifying the
algorithm for encryption. This can be an
Authenticated Encryption with Associated Authenticated Encryption with Associated
Data (AEAD) or non-AEAD. If an AEAD is Data (AEAD) or non-AEAD. If an AEAD algorithm is
specified the integrity algorithm is not specified, the integrity algorithm is not
required. If an non-AEAD algorithm is required. If a non-AEAD algorithm is
specified the integrity algorithm is specified, the integrity algorithm is
required <xref target="RFC8221"/>.</t> required <xref target="RFC8221" format="default"/>.<
/li>
<t>Tunnel information has been extended <li>Tunnel information has been extended
with information about Differentiated with information about Differentiated
Services Code Point (DSCP) mapping. It Services Code Point (DSCP) mapping. It
is assumed that is assumed that
NSFs involved in this document provide NSFs involved in this document provide
ECN full-functionality to prevent ECN full functionality to prevent
discarding of ECN congestion discarding of ECN congestion
indications <xref target="RFC6040"/>.</t> indications <xref target="RFC6040" format="default"/
>.</li>
<t>Lifetime of the IPsec SAs also <li>The lifetime of the IPsec SAs also
include idle time includes idle time
and number of IP packets as threshold to trigger and the number of IP packets as a threshold to trigg
er
the lifetime. The reason is that the lifetime. The reason is that
actual kernel implementations allow to set these actual kernel implementations allow for setting thes
types of lifetimes.</t> e
types of lifetimes.</li>
<t>Information to configure the type of <li>Information to configure the type of
encapsulation (encapsulation-type) for IPsec ESP encapsulation (encapsulation-type) for IPsec ESP
packets in UDP (<xref target="RFC3948"/>), packets in UDP <xref target="RFC3948" format="defaul
or TCP (<xref target="RFC8229"/>) has been included. t"/>
</t> or TCP <xref target="RFC8229" format="default"/> has
</list> been included.</li>
</t> </ul>
<!--In other words, each traffic selector of a policy <t> The notifications model has been defined using, as
(spd-entry) generates a different IPsec SA (sad-entry). --> reference, the PF_KEYv2 specification in
<t> The notifications model has been defined using as <xref target="RFC2367" format="default"/>.</t>
reference the PF_KEYv2 specification in <t> The YANG data model for the IKE-less case is defined by the module
<xref target="RFC2367"/>.</t> "ietf-i2nsf-ikeless". Its structure is depicted in the following diagram, using
the notation syntax for YANG tree diagrams <xref target="RFC8340" format="defau
<t> The YANG data model for the IKE-less case is defined by lt"/>.
the module "ietf-i2nsf-ikeless". Its structure is depicted in the following diag </t>
ram, using the notation syntax for YANG tree diagrams (<xref target="RFC8340"/>) <sourcecode type="yangtree"><![CDATA[
.
</t>
<t>
<figure>
<artwork>
<![CDATA[
module: ietf-i2nsf-ikeless module: ietf-i2nsf-ikeless
+--rw ipsec-ikeless +--rw ipsec-ikeless
+--rw spd +--rw spd
| +--rw spd-entry* [name] | +--rw spd-entry* [name]
| +--rw name string | +--rw name string
| +--rw direction nsfikec:ipsec-traffic-direction | +--rw direction nsfikec:ipsec-traffic-direction
| +--rw reqid? uint64 | +--rw reqid? uint64
| +--rw ipsec-policy-config | +--rw ipsec-policy-config
| +--rw anti-replay-window-size? uint32 | +--rw anti-replay-window-size? uint32
| +--rw traffic-selector | +--rw traffic-selector
| | +--rw local-prefix inet:ip-prefix | | +--rw local-prefix inet:ip-prefix
| | +--rw remote-prefix inet:ip-prefix | | +--rw remote-prefix inet:ip-prefix
| | +--rw inner-protocol? ipsec-inner-protocol | | +--rw inner-protocol? ipsec-inner-protocol
| | +--rw local-ports* [start end] | | +--rw local-ports* [start end]
| | | +--rw start inet:port-number | | | +--rw start inet:port-number
| | | +--rw end inet:port-number | | | +--rw end inet:port-number
| | +--rw remote-ports* [start end] | | +--rw remote-ports* [start end]
| | +--rw start inet:port-number | | +--rw start inet:port-number
| | +--rw end inet:port-number | | +--rw end inet:port-number
| +--rw processing-info | +--rw processing-info
| +--rw action? ipsec-spd-action | +--rw action? ipsec-spd-action
| +--rw ipsec-sa-cfg | +--rw ipsec-sa-cfg
| +--rw pfp-flag? boolean | +--rw pfp-flag? boolean
| +--rw ext-seq-num? boolean | +--rw ext-seq-num? boolean
| +--rw seq-overflow? boolean | +--rw seq-overflow? boolean
| +--rw stateful-frag-check? boolean | +--rw stateful-frag-check? boolean
| +--rw mode? ipsec-mode | +--rw mode? ipsec-mode
| +--rw protocol-parameters? ipsec-protocol-parameters | +--rw protocol-parameters? ipsec-protocol-params
| +--rw esp-algorithms | +--rw esp-algorithms
| | +--rw integrity* intr-alg-t | | +--rw integrity* intr-alg-t
| | +--rw encryption* [id] | | +--rw encryption* [id]
| | | +--rw id uint16 | | | +--rw id uint16
| | | +--rw algorithm-type? encr-alg-t | | | +--rw algorithm-type? encr-alg-t
| | | +--rw key-length? uint16 | | | +--rw key-length? uint16
| | +--rw tfc-pad? boolean | | +--rw tfc-pad? boolean
| +--rw tunnel | +--rw tunnel
| +--rw local inet:ip-address | +--rw local inet:ip-address
| +--rw remote inet:ip-address | +--rw remote inet:ip-address
| +--rw df-bit? enumeration | +--rw df-bit? enumeration
| +--rw bypass-dscp? boolean | +--rw bypass-dscp? boolean
| +--rw dscp-mapping* [id] | +--rw dscp-mapping* [id]
| +--rw id uint8 | +--rw id uint8
| +--rw inner-dscp? inet:dscp | +--rw inner-dscp? inet:dscp
| +--rw outer-dscp? inet:dscp | +--rw outer-dscp? inet:dscp
+--rw sad +--rw sad
+--rw sad-entry* [name] +--rw sad-entry* [name]
+--rw name string +--rw name string
+--rw reqid? uint64 +--rw reqid? uint64
+--rw ipsec-sa-config +--rw ipsec-sa-config
| +--rw spi uint32 | +--rw spi uint32
| +--rw ext-seq-num? boolean | +--rw ext-seq-num? boolean
| +--rw seq-overflow? boolean | +--rw seq-overflow? boolean
| +--rw anti-replay-window-size? uint32 | +--rw anti-replay-window-size? uint32
| +--rw traffic-selector | +--rw traffic-selector
| | +--rw local-prefix inet:ip-prefix | | +--rw local-prefix inet:ip-prefix
| | +--rw remote-prefix inet:ip-prefix | | +--rw remote-prefix inet:ip-prefix
| | +--rw inner-protocol? ipsec-inner-protocol | | +--rw inner-protocol? ipsec-inner-protocol
| | +--rw local-ports* [start end] | | +--rw local-ports* [start end]
| | | +--rw start inet:port-number | | | +--rw start inet:port-number
| | | +--rw end inet:port-number | | | +--rw end inet:port-number
| | +--rw remote-ports* [start end] | | +--rw remote-ports* [start end]
| | +--rw start inet:port-number | | +--rw start inet:port-number
| | +--rw end inet:port-number | | +--rw end inet:port-number
| +--rw protocol-parameters? nsfikec:ipsec-protocol-parameters | +--rw protocol-parameters? nsfikec:ipsec-protocol-params
| +--rw mode? nsfikec:ipsec-mode | +--rw mode? nsfikec:ipsec-mode
| +--rw esp-sa | +--rw esp-sa
| | +--rw encryption | | +--rw encryption
| | | +--rw encryption-algorithm? nsfikec:encr-alg-t | | | +--rw encryption-algorithm? nsfikec:encr-alg-t
| | | +--rw key? yang:hex-string | | | +--rw key? yang:hex-string
| | | +--rw iv? yang:hex-string | | | +--rw iv? yang:hex-string
| | +--rw integrity | | +--rw integrity
| | +--rw integrity-algorithm? nsfikec:intr-alg-t | | +--rw integrity-algorithm? nsfikec:intr-alg-t
| | +--rw key? yang:hex-string | | +--rw key? yang:hex-string
| +--rw sa-lifetime-hard | +--rw sa-lifetime-hard
| | +--rw time? uint32 | | +--rw time? uint32
| | +--rw bytes? yang:counter64 | | +--rw bytes? yang:counter64
| | +--rw packets? uint32 | | +--rw packets? uint32
| | +--rw idle? uint32 | | +--rw idle? uint32
| +--rw sa-lifetime-soft | +--rw sa-lifetime-soft
| | +--rw time? uint32 | | +--rw time? uint32
| | +--rw bytes? yang:counter64 | | +--rw bytes? yang:counter64
| | +--rw packets? uint32 | | +--rw packets? uint32
| | +--rw idle? uint32 | | +--rw idle? uint32
| | +--rw action? nsfikec:lifetime-action | | +--rw action? nsfikec:lifetime-action
| +--rw tunnel | +--rw tunnel
| | +--rw local inet:ip-address | | +--rw local inet:ip-address
| | +--rw remote inet:ip-address | | +--rw remote inet:ip-address
| | +--rw df-bit? enumeration | | +--rw df-bit? enumeration
| | +--rw bypass-dscp? boolean | | +--rw bypass-dscp? boolean
| | +--rw dscp-mapping* [id] | | +--rw dscp-mapping* [id]
| | | +--rw id uint8 | | | +--rw id uint8
| | | +--rw inner-dscp? inet:dscp | | | +--rw inner-dscp? inet:dscp
| | | +--rw outer-dscp? inet:dscp | | | +--rw outer-dscp? inet:dscp
| | +--rw dscp-values* inet:dscp | | +--rw dscp-values* inet:dscp
| +--rw encapsulation-type | +--rw encapsulation-type
| +--rw espencap? esp-encap | +--rw espencap? esp-encap
| +--rw sport? inet:port-number | +--rw sport? inet:port-number
| +--rw dport? inet:port-number | +--rw dport? inet:port-number
| +--rw oaddr* inet:ip-address | +--rw oaddr* inet:ip-address
+--ro ipsec-sa-state +--ro ipsec-sa-state
+--ro sa-lifetime-current +--ro sa-lifetime-current
| +--ro time? uint32 | +--ro time? uint32
| +--ro bytes? yang:counter64 | +--ro bytes? yang:counter64
| +--ro packets? uint32 | +--ro packets? uint32
| +--ro idle? uint32 | +--ro idle? uint32
+--ro replay-stats +--ro replay-stats
+--ro replay-window +--ro replay-window
| +--ro w? uint32 | +--ro w? uint32
| +--ro t? uint64 | +--ro t? uint64
| +--ro b? uint64 | +--ro b? uint64
+--ro packet-dropped? yang:counter64 +--ro packet-dropped? yang:counter64
+--ro failed? yang:counter64 +--ro failed? yang:counter64
+--ro seq-number-counter? uint64 +--ro seq-number-counter? uint64
notifications:
+---n sadb-acquire {ikeless-notification}?
| +--ro ipsec-policy-name string
| +--ro traffic-selector
| +--ro local-prefix inet:ip-prefix
| +--ro remote-prefix inet:ip-prefix
| +--ro inner-protocol? ipsec-inner-protocol
| +--ro local-ports* [start end]
| | +--ro start inet:port-number
| | +--ro end inet:port-number
| +--ro remote-ports* [start end]
| +--ro start inet:port-number
| +--ro end inet:port-number
+---n sadb-expire {ikeless-notification}?
| +--ro ipsec-sa-name string
| +--ro soft-lifetime-expire? boolean
| +--ro lifetime-current
| +--ro time? uint32
| +--ro bytes? yang:counter64
| +--ro packets? uint32
| +--ro idle? uint32
+---n sadb-seq-overflow {ikeless-notification}?
| +--ro ipsec-sa-name string
+---n sadb-bad-spi {ikeless-notification}?
+--ro spi uint32
]]>
</artwork>
</figure>
</t>
<t> The YANG data model consists of a unique notifications:
"ipsec-ikeless" container which, in turn, is +---n sadb-acquire {ikeless-notification}?
| +--ro ipsec-policy-name string
| +--ro traffic-selector
| +--ro local-prefix inet:ip-prefix
| +--ro remote-prefix inet:ip-prefix
| +--ro inner-protocol? ipsec-inner-protocol
| +--ro local-ports* [start end]
| | +--ro start inet:port-number
| | +--ro end inet:port-number
| +--ro remote-ports* [start end]
| +--ro start inet:port-number
| +--ro end inet:port-number
+---n sadb-expire {ikeless-notification}?
| +--ro ipsec-sa-name string
| +--ro soft-lifetime-expire? boolean
| +--ro lifetime-current
| +--ro time? uint32
| +--ro bytes? yang:counter64
| +--ro packets? uint32
| +--ro idle? uint32
+---n sadb-seq-overflow {ikeless-notification}?
| +--ro ipsec-sa-name string
+---n sadb-bad-spi {ikeless-notification}?
+--ro spi uint32
]]></sourcecode>
<t> The YANG data model consists of a unique
"ipsec-ikeless" container, which, in turn, is
composed of two additional containers: "spd" and composed of two additional containers: "spd" and
"sad". The "spd" container consists of a list of "sad". The "spd" container consists of a list of
entries that form the Security Policy Database. entries that form the Security Policy Database.
Compared to the IKE case YANG data model, this Compared to the IKE case YANG data model, this
part specifies a few additional parameters part specifies a few additional parameters
necessary due to the absence of an IKE software necessary due to the absence of an IKE software
in the NSF: traffic direction to apply the IPsec in the NSF: traffic direction to apply the IPsec
policy, and a "reqid" value to link an IPsec policy and a "reqid" value to link an IPsec
policy with its associated IPsec SAs since it is policy with its associated IPsec SAs since it is
otherwise a little hard to find by searching. otherwise a little hard to find by searching.
The "sad" container is a list of entries that form the Secur The "sad" container is a list of entries that form the Secur
ity Association Database. In general, each entry allows specifying both configur ity Association Database. In general, each entry allows specifying both configur
ation information (SPI, traffic selectors, tunnel/transport mode, cryptographic ation information (SPI, Traffic Selectors, tunnel/transport mode, cryptographic
algorithms and keying material, soft/hard lifetimes, etc.) as well as state info algorithms and keying material, soft/hard lifetimes, etc.) as well as stating in
rmation (time to expire, replay statistics, etc.) of a concrete IPsec SA. formation (time to expire, replay statistics, etc.) of a concrete IPsec SA.
</t> </t>
<t>In addition, the module defines a set of notifications to allow
<t> the NSF to inform the I2NSF Controller about relevant events, such
In addition, the module defines a set of notifications to al as IPsec SA expiration, sequence number overflow, or bad SPI in a recei
low the NSF inform I2NSF controller about relevant events such as IPsec SA expir ved packet.
ation, sequence number overflow or bad SPI in a received packet. </t>
</t> </section>
<section anchor="ikeless-examples" numbered="true" toc="default">
</section> <name>Example Usage</name>
<section anchor="ikeless-examples" title="Example Usage"> <t>
<t> <xref target="appendix-e" format="default"/> shows an ex
<xref target="appendix-e"/> shows an example ample
of IKE-less case configuration for a NSF, in of an IKE-less case configuration for an NSF in
transport mode (host-to-host). Additionally, transport mode (host-to-host). Additionally,
<xref target="appendix-f"/> shows examples <xref target="appendix-f" format="default"/> shows examp les
of IPsec SA expire, acquire, sequence number of IPsec SA expire, acquire, sequence number
overflow and bad SPI notifications. overflow, and bad SPI notifications.
</t> </t>
</section>
</section> <section anchor="ikeless-module" numbered="true" toc="default">
<section anchor="ikeless-module" title="YANG Module"> <name>YANG Module</name>
<t> <t>
This YANG module has normative references to This YANG module has normative references to
<xref target="RFC4301"/>, <xref target="RFC4301" format="default"/>,
<xref target="RFC6991"/>, <xref target="RFC4303" format="default"/>,
<xref target="RFC8174"/> and <xref target="RFC6991" format="default"/>,
<xref target="RFC8341"/>. <xref target="RFC8174" format="default"/> and
</t> <xref target="RFC8341" format="default"/>.
</t>
<t> <sourcecode name="ietf-i2nsf-ikeless@2021-06-09.yang" type="yang" markers="true"
<figure> ><![CDATA[
<artwork>
<![CDATA[
<CODE BEGINS> file "ietf-i2nsf-ikeless@2021-03-18.yang"
module ietf-i2nsf-ikeless {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless";
prefix "nsfikels";
import ietf-inet-types {
prefix inet;
reference "RFC 6991: Common YANG Data Types";
}
import ietf-yang-types {
prefix yang;
reference "RFC 6991: Common YANG Data Types";
}
import ietf-i2nsf-ikec {
prefix nsfikec;
reference
"RFC XXXX: Software-Defined Networking
(SDN)-based IPsec Flow Protection.";
}
import ietf-netconf-acm {
prefix nacm;
reference
"RFC 8341: Network Configuration Access Control
Model.";
}
organization "IETF I2NSF Working Group"; module ietf-i2nsf-ikeless {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless";
prefix nsfikels;
contact import ietf-inet-types {
"WG Web: <https://datatracker.ietf.org/wg/i2nsf/> prefix inet;
WG List: <mailto:i2nsf@ietf.org> reference
"RFC 6991: Common YANG Data Types.";
}
import ietf-yang-types {
prefix yang;
reference
"RFC 6991: Common YANG Data Types.";
}
import ietf-i2nsf-ikec {
prefix nsfikec;
reference
"RFC 9061: A YANG Data Model for IPsec Flow Protection
Based on Software-Defined Networking (SDN).";
}
import ietf-netconf-acm {
prefix nacm;
reference
"RFC 8341: Network Configuration Access Control
Model.";
}
Author: Rafael Marin-Lopez organization
<mailto:rafa@um.es> "IETF I2NSF Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/i2nsf/>
WG List: <mailto:i2nsf@ietf.org>
Author: Gabriel Lopez-Millan Author: Rafael Marin-Lopez
<mailto:gabilm@um.es> <mailto:rafa@um.es>
Author: Fernando Pereniguez-Garcia Author: Gabriel Lopez-Millan
<mailto:fernando.pereniguez@cud.upct.es> <mailto:gabilm@um.es>
";
description Author: Fernando Pereniguez-Garcia
"Data model for IKE-less case in the SDN-base IPsec flow <mailto:fernando.pereniguez@cud.upct.es>
";
description
"Data model for IKE-less case in the SDN-based IPsec flow
protection service. protection service.
Copyright (c) 2020 IETF Trust and the persons
identified as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with
or without modification, is permitted pursuant to, and
subject to the license terms contained in, the
Simplified BSD License set forth in Section 4.c of the
IETF Trust's Legal Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX;;
see the RFC itself for full legal notices.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this
document are to be interpreted as described in BCP 14 document are to be interpreted as described in BCP 14
(RFC 2119) (RFC 8174) when, and only when, they appear (RFC 2119) (RFC 8174) when, and only when, they appear
in all capitals, as shown here."; in all capitals, as shown here.
revision "2021-03-18" { Copyright (c) 2021 IETF Trust and the persons
description "Initial version."; identified as authors of the code. All rights reserved.
reference
"RFC XXXX: Software-Defined Networking
(SDN)-based IPsec Flow Protection.";
}
feature ikeless-notification { Redistribution and use in source and binary forms, with or
description without modification, is permitted pursuant to, and subject
"This feature indicates that the server supports to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC 9061; see
the RFC itself for full legal notices.";
revision 2021-06-09 {
description
"Initial version.";
reference
"RFC 9061: A YANG Data Model for IPsec Flow Protection
Based on Software-Defined Networking (SDN).";
}
feature ikeless-notification {
description
"This feature indicates that the server supports
generating notifications in the ikeless module. generating notifications in the ikeless module.
To ensure broader applicability of this module, To ensure broader applicability of this module,
the notifications are marked as a feature. the notifications are marked as a feature.
For the implementation of ikeless case, For the implementation of the IKE-less case,
the NSF is expected to implement this the NSF is expected to implement this
feature."; feature.";
} }
container ipsec-ikeless { container ipsec-ikeless {
description description
"Container for configuration of the IKE-less "Container for configuration of the IKE-less
case. The container contains two additional case. The container contains two additional
containers: 'spd' and 'sad'. The first allows the containers: 'spd' and 'sad'. The first allows the
I2NSF Controller to configure IPsec policies in I2NSF Controller to configure IPsec policies in
the Security Policy Database SPD, and the second the Security Policy Database (SPD), and the second
allows to configure IPsec Security Associations allows the I2NSF Controller to configure IPsec
(IPsec SAs) in the Security Association Database Security Associations (IPsec SAs) in the Security
(SAD)."; Association Database (SAD).";
reference "RFC 4301."; reference
"RFC 4301: Security Architecture for the Internet Protocol.";
container spd { container spd {
description description
"Configuration of the Security Policy Database "Configuration of the Security Policy Database
(SPD.)"; (SPD).";
reference "Section 4.4.1.2 in RFC 4301."; reference
"RFC 4301: Security Architecture for the Internet Protocol,
list spd-entry { Section 4.4.1.2.";
key "name"; list spd-entry {
ordered-by user; key "name";
leaf name { ordered-by user;
type string; leaf name {
description type string;
"SPD entry unique name to identify this description
"SPD-entry-unique name to identify this
entry."; entry.";
} }
leaf direction { leaf direction {
type nsfikec:ipsec-traffic-direction; type nsfikec:ipsec-traffic-direction;
mandatory true; mandatory true;
description description
"Inbound traffic or outbound "Inbound traffic or outbound
traffic. In the IKE-less case the traffic. In the IKE-less case, the
I2NSF Controller needs to I2NSF Controller needs to
specify the policy direction to be specify the policy direction to be
applied in the NSF. In the IKE case applied in the NSF. In the IKE case,
this direction does not need to be this direction does not need to be
specified since IKE specified, since IKE
will determine the direction that will determine the direction that the
IPsec policy will require."; IPsec policy will require.";
} }
leaf reqid { leaf reqid {
type uint64; type uint64;
default 0; default "0";
description description
"This value allows to link this "This value allows linking this
IPsec policy with IPsec SAs with the IPsec policy with IPsec SAs with the
same reqid. It is only required in same reqid. It is only required in
the IKE-less model since, in the IKE the IKE-less model since, in the IKE
case this link is handled internally case, this link is handled internally
by IKE."; by IKE.";
} }
container ipsec-policy-config {
container ipsec-policy-config { description
description "This container carries the
"This container carries the configuration of an IPsec policy.";
configuration of a IPsec policy."; uses nsfikec:ipsec-policy-grouping;
uses nsfikec:ipsec-policy-grouping; }
} description
description "The SPD is represented as a list of SPD
"The SPD is represented as a list of SPD
entries, where each SPD entry represents an entries, where each SPD entry represents an
IPsec policy."; IPsec policy.";
} /*list spd-entry*/ } /*list spd-entry*/
} /*container spd*/ } /*container spd*/
container sad {
container sad { description
description "Configuration of the IPsec Security Association
"Configuration of the IPsec Security Association Database (SAD).";
Database (SAD)"; reference
reference "Section 4.4.2.1 in RFC 4301."; "RFC 4301: Security Architecture for the Internet Protocol,
Section 4.4.2.1.";
list sad-entry { list sad-entry {
key "name"; key "name";
ordered-by user; ordered-by user;
leaf name { leaf name {
type string; type string;
description description
"SAD entry unique name to identify this "SAD-entry-unique name to identify this
entry."; entry.";
} }
leaf reqid { leaf reqid {
type uint64; type uint64;
default 0; default "0";
description description
"This value allows to link this "This value allows linking this
IPsec SA with an IPsec policy with IPsec SA with an IPsec policy with
the same reqid."; the same reqid.";
} }
container ipsec-sa-config {
container ipsec-sa-config { description
description "This container allows configuring
"This container allows configuring
details of an IPsec SA."; details of an IPsec SA.";
leaf spi { leaf spi {
type uint32 { range "0..max"; } type uint32 {
mandatory true; range "0..max";
description }
"Security Parameter Index (SPI)'s mandatory true;
IPsec SA."; description
} "IPsec SA of Security Parameter Index (SPI).";
}
leaf ext-seq-num { leaf ext-seq-num {
type boolean; type boolean;
default true; default "true";
description description
"True if this IPsec SA is using extended "True if this IPsec SA is using extended
sequence numbers. If true, the 64-bit sequence numbers. If true, the 64-bit
extended sequence number counter is used; extended sequence number counter is used;
if false, the normal 32-bit sequence if false, the normal 32-bit sequence
number counter is used."; number counter is used.";
} }
leaf seq-overflow {
leaf seq-overflow { type boolean;
type boolean; default "false";
default false; description
description "The flag indicating whether
"The flag indicating whether
overflow of the sequence number overflow of the sequence number
counter should prevent transmission counter should prevent transmission
of additional packets on the IPsec of additional packets on the IPsec
SA (false) and, therefore needs to SA (false) and, therefore, needs to
be rekeyed, or whether rollover is be rekeyed or whether rollover is
permitted (true). If Authenticated permitted (true). If Authenticated
Encryption with Associated Data Encryption with Associated Data
(AEAD) is used (leaf (AEAD) is used (leaf
esp-algorithms/encryption/algorithm-type) esp-algorithms/encryption/algorithm-type),
this flag MUST BE false. Setting this this flag MUST BE false. Setting this
flag to true is strongly discouraged."; flag to true is strongly discouraged.";
} }
leaf anti-replay-window-size { leaf anti-replay-window-size {
type uint32; type uint32;
default 64; default "64";
description description
"To set the anti-replay window size. "To set the anti-replay window size.
The default value is set to 64 The default value is set to 64,
following RFC 4303 recommendation."; following the recommendation in RFC 4303.";
reference reference
"Section 3.4.3 in RFC 4303"; "RFC 4303: IP Encapsulating Security Payload (ESP),
} Section 3.4.3.";
container traffic-selector { }
uses nsfikec:selector-grouping; container traffic-selector {
description uses nsfikec:selector-grouping;
"The IPsec SA traffic selector."; description
} "The IPsec SA Traffic Selector.";
leaf protocol-parameters { }
type nsfikec:ipsec-protocol-parameters; leaf protocol-parameters {
default esp; type nsfikec:ipsec-protocol-params;
description default "esp";
"Security protocol of IPsec SA: Only description
"Security protocol of IPsec SA, only
ESP so far."; ESP so far.";
} }
leaf mode { leaf mode {
type nsfikec:ipsec-mode; type nsfikec:ipsec-mode;
default transport; default "transport";
description description
"Tunnel or transport mode."; "Tunnel or transport mode.";
} }
container esp-sa { container esp-sa {
when "../protocol-parameters = 'esp'"; when "../protocol-parameters = 'esp'";
description description
"In case the IPsec SA is "In case the IPsec SA is an
Encapsulation Security Payload Encapsulation Security Payload
(ESP), it is required to specify (ESP), it is required to specify
encryption and integrity encryption and integrity
algorithms, and key material."; algorithms and key materials.";
container encryption {
container encryption { description
description "Configuration of encryption or
"Configuration of encryption or AEAD algorithm for IPsec
AEAD algorithm for IPsec Encapsulation Security Payload
Encapsulation Security Payload (ESP).";
(ESP)."; leaf encryption-algorithm {
type nsfikec:encr-alg-t;
leaf encryption-algorithm { default "12";
type nsfikec:encr-alg-t; description
default 12; "Configuration of ESP
description encryption. With AEAD
"Configuration of ESP
encryption. With AEAD
algorithms, the integrity-algorithm algorithms, the integrity-algorithm
leaf is not used."; leaf is not used.";
} }
leaf key {
leaf key { nacm:default-deny-all;
nacm:default-deny-all; type yang:hex-string;
type yang:hex-string; description
description "ESP encryption key value.
"ESP encryption key value. If this leaf is not defined,
If this leaf is not defined the key is not defined
the key is not defined (e.g., encryption is NULL).
(e.g., encryption is NULL). The key length is
The key length is determined by the
determined by the length of the key set in
length of the key set in this leaf. By default, it is
this leaf. By default is 128 bits.";
128 bits."; }
} leaf iv {
leaf iv { nacm:default-deny-all;
nacm:default-deny-all; type yang:hex-string;
type yang:hex-string; description
description "ESP encryption IV value. If
"ESP encryption IV value. If this leaf is not defined, the
this leaf is not defined the
IV is not defined (e.g., IV is not defined (e.g.,
encryption is NULL)"; encryption is NULL).";
} }
} }
container integrity {
container integrity { description
description "Configuration of integrity for
"Configuration of integrity for
IPsec Encapsulation Security IPsec Encapsulation Security
Payload (ESP). This container Payload (ESP). This container
allows configuration of integrity allows configuration of integrity
algorithms when no AEAD algorithms when no AEAD
algorithms are used, and algorithms are used and
integrity is required."; integrity is required.";
leaf integrity-algorithm {
leaf integrity-algorithm { type nsfikec:intr-alg-t;
type nsfikec:intr-alg-t; default "12";
default 12; description
description "Message Authentication Code
"Message Authentication Code
(MAC) algorithm to provide (MAC) algorithm to provide
integrity in ESP integrity in ESP (default
(default
AUTH_HMAC_SHA2_256_128). AUTH_HMAC_SHA2_256_128).
With AEAD algorithms, With AEAD algorithms,
the integrity leaf is not the integrity leaf is not
used."; used.";
} }
leaf key {
leaf key { nacm:default-deny-all;
nacm:default-deny-all; type yang:hex-string;
type yang:hex-string; description
description "ESP integrity key value.
"ESP integrity key value. If this leaf is not defined,
If this leaf is not defined
the key is not defined (e.g., the key is not defined (e.g.,
AEAD algorithm is chosen and AEAD algorithm is chosen and
integrity algorithm is not integrity algorithm is not
required). The key length is required). The key length is
determined by the length of determined by the length of
the key configured."; the key configured.";
} }
} }
} /*container esp-sa*/ } /*container esp-sa*/
container sa-lifetime-hard {
container sa-lifetime-hard { description
description "IPsec SA hard lifetime. The action
"IPsec SA hard lifetime. The action associated is terminate and hold.";
associated is terminate and uses nsfikec:lifetime;
hold."; }
uses nsfikec:lifetime; container sa-lifetime-soft {
} description
container sa-lifetime-soft { "IPsec SA soft lifetime.";
description uses nsfikec:lifetime;
"IPsec SA soft lifetime."; leaf action {
uses nsfikec:lifetime; type nsfikec:lifetime-action;
leaf action { description
type nsfikec:lifetime-action; "Action lifetime: terminate-clear,
description terminate-hold, or replace.";
"Action lifetime: }
terminate-clear, }
terminate-hold or replace."; container tunnel {
} when "../mode = 'tunnel'";
} uses nsfikec:tunnel-grouping;
container tunnel { leaf-list dscp-values {
when "../mode = 'tunnel'"; type inet:dscp;
uses nsfikec:tunnel-grouping; description
leaf-list dscp-values { "DSCP values allowed for ingress packets carried
type inet:dscp; over this IPsec SA. If no values are specified, no
description DSCP-specific filtering is applied. When
"DSCP values allowed for ingress packets carried
over this IPsec SA. If no values are specified, no
DSCP-specific filtering is applied. When
../bypass-dscp is false and a dscp-mapping is ../bypass-dscp is false and a dscp-mapping is
defined, each value here would be the same as the defined, each value here would be the same as the
'inner' DSCP value for the DSCP mapping (list 'inner' DSCP value for the DSCP mapping (list
dscp-mapping)"; dscp-mapping).";
reference reference
"Section 4.4.2.1. in RFC 4301."; "RFC 4301: Security Architecture for the Internet
} Protocol, Section 4.4.2.1.";
description }
"Endpoints of the IPsec tunnel."; description
} "Endpoints of the IPsec tunnel.";
container encapsulation-type { }
uses nsfikec:encap; container encapsulation-type {
description uses nsfikec:encap;
"This container carries description
"This container carries
configuration information about configuration information about
the source and destination ports the source and destination ports
which will be used for ESP that will be used for ESP
encapsulation that ESP packets the encapsulation of ESP packets and
type of encapsulation when NAT the type of encapsulation when NAT
traversal is in place."; traversal is in place.";
} }
} /*ipsec-sa-config*/ } /*ipsec-sa-config*/
container ipsec-sa-state {
container ipsec-sa-state { config false;
config false; description
description "Container describing IPsec SA state
"Container describing IPsec SA state
data."; data.";
container sa-lifetime-current { container sa-lifetime-current {
uses nsfikec:lifetime; uses nsfikec:lifetime;
description description
"SAD lifetime current."; "SAD lifetime current.";
} }
container replay-stats { container replay-stats {
description description
"State data about the anti-replay "State data about the anti-replay
window."; window.";
container replay-window {
container replay-window { leaf w {
leaf w { type uint32;
type uint32; description
description "Size of the replay window.";
"Size of the replay window."; }
} leaf t {
leaf t { type uint64;
type uint64; description
description "Highest sequence number
"Highest sequence number
authenticated so far, authenticated so far,
upper bound of window."; upper bound of window.";
} }
leaf b { leaf b {
type uint64; type uint64;
description description
"Lower bound of window."; "Lower bound of window.";
} }
description description
"This container contains three "This container contains three
parameters that defines the state parameters that define the state
of the replay window: window size (w), of the replay window: window size (w),
highest sequence number authenticated (t) highest sequence number authenticated (t),
and lower bound of the window (b). According and lower bound of the window (b), according
to Appendix A2.1 - RFC 4303 w = t-b+1."; to Appendix A2.1 in RFC 4303 (w = t - b + 1).";
reference reference
"Appendix A in RFC 4303."; "RFC 4303: IP Encapsulating Security Payload (ESP),
} Appendix A.";
}
leaf packet-dropped { leaf packet-dropped {
type yang:counter64; type yang:counter64;
description description
"Packets dropped "Packets dropped
because they are because they are
replay packets."; replay packets.";
} }
leaf failed {
leaf failed { type yang:counter64;
type yang:counter64; description
description "Number of packets detected out
"Number of packets detected out
of the replay window."; of the replay window.";
} }
leaf seq-number-counter {
leaf seq-number-counter { type uint64;
type uint64; description
description "A 64-bit counter when this
"A 64-bit counter when this
IPsec SA is using Extended IPsec SA is using Extended
Sequence Number or 32-bit Sequence Number or 32-bit
counter when it is not. counter when it is not.
Current value of sequence Current value of sequence
number."; number.";
} }
} /* container replay-stats*/ } /* container replay-stats*/
} /*ipsec-sa-state*/ } /*ipsec-sa-state*/
description
"List of SAD entries that form the SAD.";
} /*list sad-entry*/
} /*container sad*/
} /*container ipsec-ikeless*/
description /* Notifications */
"List of SAD entries that forms the SAD.";
} /*list sad-entry*/
} /*container sad*/
}/*container ipsec-ikeless*/
/* Notifications */ notification sadb-acquire {
notification sadb-acquire { if-feature "ikeless-notification";
if-feature ikeless-notification; description
description "The NSF detects and notifies that
"The NSF detects and notifies that
an IPsec SA is required for an an IPsec SA is required for an
outbound IP packet that has matched a SPD entry. outbound IP packet that has matched an SPD entry.
The traffic-selector container in this The traffic-selector container in this
notification contains information about notification contains information about
the IP packet that triggered this the IP packet that triggered this
notification."; notification.";
leaf ipsec-policy-name { leaf ipsec-policy-name {
type string; type string;
mandatory true; mandatory true;
description description
"It contains the SPD entry name (unique) of "It contains the SPD entry name (unique) of
the IPsec policy that hits the IP packet the IPsec policy that hits the IP-packet-required
required IPsec SA. It is assumed the IPsec SA. It is assumed the
I2NSF Controller will have a copy of the I2NSF Controller will have a copy of the
information of this policy so it can information of this policy so it can
extract all the information with this extract all the information with this
unique identifier. The type of IPsec SA is unique identifier. The type of IPsec SA is
defined in the policy so the Security defined in the policy so the security
Controller can also know the type of IPsec controller can also know the type of IPsec
SA that MUST be generated."; SA that MUST be generated.";
} }
container traffic-selector { container traffic-selector {
description description
"The IP packet that triggered the acquire "The IP packet that triggered the acquire
and requires an IPsec SA. Specifically it and requires an IPsec SA. Specifically, it
will contain the IP source/mask and IP will contain the IP source/mask and IP
destination/mask; protocol (udp, tcp, destination/mask, protocol (udp, tcp,
etc...); and source and destination etc.), and source and destination
ports."; ports.";
uses nsfikec:selector-grouping; uses nsfikec:selector-grouping;
} }
} }
notification sadb-expire { notification sadb-expire {
if-feature ikeless-notification; if-feature "ikeless-notification";
description "An IPsec SA expiration (soft or hard)."; description
leaf ipsec-sa-name { "An IPsec SA expiration (soft or hard).";
type string; leaf ipsec-sa-name {
mandatory true; type string;
description mandatory true;
"It contains the SAD entry name (unique) of description
"It contains the SAD entry name (unique) of
the IPsec SA that is about to expire. It is assumed the IPsec SA that is about to expire. It is assumed
the I2NSF Controller will have a copy of the the I2NSF Controller will have a copy of the
IPsec SA information (except the cryptographic IPsec SA information (except the cryptographic
material and state data) indexed by this name material and state data) indexed by this name
(unique identifier) so it can know all the (unique identifier) so it can know all the
information (crypto algorithms, etc.) about information (crypto algorithms, etc.) about
the IPsec SA that has expired in order to the IPsec SA that has expired in order to
perform a rekey (soft lifetime) or delete it perform a rekey (soft lifetime) or delete it
(hard lifetime) with this unique identifier."; (hard lifetime) with this unique identifier.";
} }
leaf soft-lifetime-expire { leaf soft-lifetime-expire {
type boolean; type boolean;
default true; default "true";
description description
"If this value is true the lifetime expired is "If this value is true, the lifetime expired is
soft. If it is false is hard."; soft. If it is false, the lifetime is hard.";
} }
container lifetime-current { container lifetime-current {
description description
"IPsec SA current lifetime. If "IPsec SA current lifetime. If
soft-lifetime-expired is true soft-lifetime-expired is true,
this container is set with the this container is set with the
lifetime information about current lifetime information about current
soft lifetime. soft lifetime.
It can help the NSF Controller It can help the NSF Controller
to know which of the (soft) lifetime to know which of the (soft) lifetime
limits raised the event: time, bytes, limits raised the event: time, bytes,
packets or idle."; packets, or idle.";
uses nsfikec:lifetime;
uses nsfikec:lifetime; }
} }
}
notification sadb-seq-overflow { notification sadb-seq-overflow {
if-feature ikeless-notification; if-feature "ikeless-notification";
description "Sequence overflow notification."; description
leaf ipsec-sa-name { "Sequence overflow notification.";
type string; leaf ipsec-sa-name {
mandatory true; type string;
description mandatory true;
"It contains the SAD entry name (unique) of description
"It contains the SAD entry name (unique) of
the IPsec SA that is about to have a sequence the IPsec SA that is about to have a sequence
number overflow and rollover is not permitted. number overflow, and rollover is not permitted.
When the NSF issues this event before reaching When the NSF issues this event before reaching
a sequence number overflow is implementation a sequence number, overflow is implementation
specific and out of scope of this specification. specific and out of scope of this specification.
It is assumed the I2NSF Controller will have a It is assumed the I2NSF Controller will have a
copy of the IPsec SA information (except the copy of the IPsec SA information (except the
cryptographic material and state data) indexed cryptographic material and state data) indexed
by this name (unique identifier) so it can by this name (unique identifier) so it can
know all the information (crypto algorithms, know all the information (crypto algorithms,
etc.) about the IPsec SA in etc.) about the IPsec SA in
order to perform a rekey of the IPsec SA."; order to perform a rekey of the IPsec SA.";
} }
} }
notification sadb-bad-spi {
if-feature ikeless-notification;
description
"Notify when the NSF receives a packet with an
incorrect SPI (i.e. not present in the SAD).";
leaf spi {
type uint32 { range "0..max"; }
mandatory true;
description
"SPI number contained in the erroneous IPsec
packet.";
}
}
}
<CODE ENDS>
]]>
</artwork>
</figure>
</t>
</section>
</section>
</section>
<section anchor="iana" title="IANA Considerations">
<t>This document registers three URIs in the "ns"
subregistry of the IETF XML Registry
<xref target="RFC3688"/>.
Following the format in <xref target="RFC3688"/>, the
following registrations are requested:</t>
<t>
<figure>
<artwork>
URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikec
Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-ike
Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless
Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace.
</artwork>
</figure>
</t>
<t>This document registers three YANG modules in the "YANG
Module Names" registry <xref target="RFC6020"/>. Following t
he
format in <xref target="RFC6020"/>, the following registrati
ons
are requested:</t>
<t>
<figure>
<artwork>
Name: ietf-i2nsf-ikec
Namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikec
Prefix: nsfikec
Reference: RFC XXXX
Name: ietf-i2nsf-ike
Namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-ike
Prefix: nsfike
Reference: RFC XXXX
Name: ietf-i2nsf-ikeless notification sadb-bad-spi {
Namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless if-feature "ikeless-notification";
Prefix: nsfikels description
Reference: RFC XXXX "Notify when the NSF receives a packet with an
</artwork> incorrect SPI (i.e., not present in the SAD).";
</figure> leaf spi {
</t> type uint32 {
</section> range "0..max";
<section anchor="security" title="Security Considerations"> }
<t> mandatory true;
description
"SPI number contained in the erroneous IPsec
packet.";
}
}
}
]]></sourcecode>
</section>
</section>
</section>
<section anchor="iana" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>IANA has registered the following namespaces in the "ns"
subregistry within the "IETF XML Registry"
<xref target="RFC3688" format="default"/>:</t>
<dl newline="false" spacing="compact">
<dt>URI:</dt>
<dd>urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikec</dd>
<dt>Registrant Contact:</dt>
<dd>The IESG.</dd>
<dt>XML:</dt>
<dd>N/A, the requested URI is an XML namespace.</dd>
</dl>
<dl newline="false" spacing="compact">
<dt>URI:</dt>
<dd>urn:ietf:params:xml:ns:yang:ietf-i2nsf-ike</dd>
<dt>Registrant Contact:</dt>
<dd>The IESG.</dd>
<dt>XML:</dt>
<dd>N/A, the requested URI is an XML namespace.</dd>
</dl>
<dl newline="false" spacing="compact">
<dt>URI:</dt>
<dd>urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless</dd>
<dt>Registrant Contact:</dt>
<dd>The IESG.</dd>
<dt>XML:</dt>
<dd>N/A, the requested URI is an XML namespace.</dd>
</dl>
<t>IANA has registered the following YANG modules in the "YANG
Module Names" registry <xref target="RFC6020" format="defaul
t"/>:</t>
<dl newline="false" spacing="compact" indent="14">
<dt>Name:</dt>
<dd>ietf-i2nsf-ikec</dd>
<dt>Maintained by IANA:</dt>
<dd>N</dd>
<dt>Namespace:</dt>
<dd>urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikec</dd>
<dt>Prefix:</dt>
<dd>nsfikec</dd>
<dt>Reference:</dt>
<dd>RFC 9061</dd>
</dl>
<dl newline="false" spacing="compact" indent="14">
<dt>Name:</dt>
<dd>ietf-i2nsf-ike</dd>
<dt>Maintained by IANA:</dt>
<dd>N</dd>
<dt>Namespace:</dt>
<dd>urn:ietf:params:xml:ns:yang:ietf-i2nsf-ike</dd>
<dt>Prefix:</dt>
<dd>nsfike</dd>
<dt>Reference:</dt>
<dd>RFC 9061</dd>
</dl>
<dl newline="false" spacing="compact" indent="14">
<dt>Name:</dt>
<dd>ietf-i2nsf-ikeless</dd>
<dt>Maintained by IANA:</dt>
<dd>N</dd>
<dt>Namespace:</dt>
<dd>urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless</dd>
<dt>Prefix:</dt>
<dd>nsfikels</dd>
<dt>Reference:</dt>
<dd>RFC 9061</dd>
</dl>
</section>
<section anchor="security" numbered="true" toc="default">
<name>Security Considerations</name>
<t>
First of all, this document shares all the security First of all, this document shares all the security
issues of SDN that are specified in the "Security issues of SDN that are specified in the Security
Considerations" section of <xref target="ITU-T.Y.3300"/> Considerations sections of <xref target="ITU-T.Y.3300" forma
and <xref target="RFC7426"/>. </t> t="default"/>
<t>On the one hand, it is important to note that and <xref target="RFC7426" format="default"/>. </t>
there MUST <t>On the one hand, it is important to note that
there <bcp14>MUST</bcp14>
exist a security association between the I2NSF exist a security association between the I2NSF
Controller and the NSFs to protect the critical Controller and the NSFs to protect the critical
information (cryptographic keys, configuration information (cryptographic keys, configuration
parameter, etc.) exchanged between these parameter, etc.) exchanged between these
entities. The nature of and means to create that entities. The nature of and means to create that
security association is out of the scope of this security association is out of the scope of this
document (i.e., it is part of device document (i.e., it is part of device
provisioning or onboarding).</t> provisioning or onboarding).</t>
<t>On the other hand, if encryption is mandatory for all <t>On the other hand, if encryption is mandatory for all
traffic of a NSF, its default policy MUST be to drop traffic of an NSF, its default policy <bcp14>MUST</bcp14> be
to drop
(DISCARD) packets to prevent cleartext packet leaks. (DISCARD) packets to prevent cleartext packet leaks.
This default policy MUST be pre-configured in the startup This default policy <bcp14>MUST</bcp14> be preconfigured in the startup
configuration datastore in the NSF configuration datastore in the NSF
before the NSF contacts the before the NSF contacts the
I2NSF Controller. Moreover, the startup configuration I2NSF Controller. Moreover, the startup configuration
datastore MUST be also pre-configured with the required datastore <bcp14>MUST</bcp14> be also preconfigured with the required
ALLOW policies that allow the NSF to communicate with the ALLOW policies that allow the NSF to communicate with the
I2NSF Controller once the NSF is deployed. This I2NSF Controller once the NSF is deployed. This
pre-configuration step is not carried out by the preconfiguration step is not carried out by the
I2NSF Controller but by some other entity before the I2NSF Controller but by some other entity before the
NSF deployment. <!--Moreover, this initial startup NSF deployment. In this manner, when the NSF
configuration MUST include the different policies that
allow this NSF to contact the SC once the NSF has been
deployed. -->In this manner, when the NSF
starts/reboots, it will always first apply the starts/reboots, it will always first apply the
configuration in the startup configuration before configuration in the startup configuration before
contacting the I2NSF Controller.</t> contacting the I2NSF Controller.</t>
<t>Finally, this section is divided in two <t>Finally, this section is divided in two
parts in order to analyze different security parts in order to analyze different security
considerations for both cases: NSF with IKEv2 considerations for both cases: NSF with IKEv2
(IKE case) and NSF without IKEv2 (IKE-less (IKE case) and NSF without IKEv2 (IKE-less
case). In general, the case). In general, the
I2NSF Controller, as typically in the SDN I2NSF Controller, as typically in the SDN
paradigm, is a target for different type of paradigm, is a target for different type of
attacks attacks; see
<xref target="SDNSecServ"/> and <xref target="SDNSecServ" format="default"/> and
<xref target="SDNSecurity"/>. Thus, the <xref target="SDNSecurity" format="default"/>. Thus, the
I2NSF Controller is a key entity in the I2NSF Controller is a key entity in the
infrastructure and MUST be protected accordingly. infrastructure and <bcp14>MUST</bcp14> be protected accordin gly.
In particular, the I2NSF Controller will handle In particular, the I2NSF Controller will handle
cryptographic material thus the attacker may try to access cryptographic material; thus, the attacker may try to access
this information. The impact is different depending on the I KE this information. The impact is different depending on the I KE
case or the IKE-less case.</t> case or the IKE-less case.</t>
<section anchor="sec-case1" title="IKE case"> <section anchor="sec-case1" numbered="true" toc="default">
<t>In the IKE case, the I2NSF Controller sends IKEv2 <name>IKE Case</name>
<t>In the IKE case, the I2NSF Controller sends IKEv2
credentials (PSK, public/private keys, certificates, credentials (PSK, public/private keys, certificates,
etc.) to the NSFs using the security association etc.) to the NSFs using the security association
between I2NSF Controller and NSFs. The I2NSF between the I2NSF Controller and NSFs. The I2NSF
Controller MUST NOT store the IKEv2 credentials after Controller <bcp14>MUST NOT</bcp14> store the IKEv2 creden
distributing them. Moreover, the NSFs MUST NOT allow tials after
distributing them. Moreover, the NSFs <bcp14>MUST NOT</bc
p14> allow
the reading of these values once they have been applied the reading of these values once they have been applied
by the I2NSF Controller (i.e. write only operations). by the I2NSF Controller (i.e., write-only operations).
One option is to always return the same value (i.e. all One option is to always return the same value (i.e., all
0s) if a read operation is carried out.</t> 0s) if a read operation is carried out.</t>
<t>If the attacker has access to the I2NSF Controller
<t>If the attacker has access to the I2NSF Controller
during the period of time that key material is during the period of time that key material is
generated, it might have access to the key material. generated, it might have access to the key material.
Since these values are used during NSF authentication in Since these values are used during NSF authentication in
IKEv2, it may impersonate the affected NSFs. Several IKEv2, it may impersonate the affected NSFs. Several
recommendations are important. recommendations are important. </t>
<ul spacing="normal">
<list style="symbols"> <li> IKEv2 configurations <bcp14>SHOULD</bcp14> adhere to the
recommendations in <xref target="RFC8247" format="defaul
<t> IKEv2 configurations SHOULD adhere to the t"/>. </li>
recommendations in <xref target="RFC8247"/>. </t> <li> If PSK authentication is
used in IKEv2, the I2NSF Controller <bcp14>MUST</bcp14>
<t> If PSK authentication is remove the
used in IKEv2, the I2NSF Controller MUST remove the
PSK immediately after generating and distributing it. PSK immediately after generating and distributing it.
</t> </li>
<li>When public/private keys are used, the I2NSF
<t>When public/private keys are used, the I2NSF Controller <bcp14>MAY</bcp14> generate both public key a
Controller MAY generate both public key and private nd private
key. In such a case, the I2NSF Controller MUST remove key. In such a case, the I2NSF Controller <bcp14>MUST</b
cp14> remove
the associated private key immediately after the associated private key immediately after
distributing them to the NSFs. distributing them to the NSFs.
Alternatively, the NSF Alternatively, the NSF
MAY generate the private key and export only <bcp14>MAY</bcp14> generate the private key and export o nly
the public key to the I2NSF Controller. How the public key to the I2NSF Controller. How
the NSF generates these the NSF generates these
cryptographic material (public key/ private cryptographic materials (public key/ private
keys) and keys) and
exports the public key, is out of scope of exports the public key is out of scope of
this document. this document.
</t> </li>
<li>If certificates are used, the NSF <bcp14>MAY</bcp14> generate the
<t>If certificates are used, the NSF MAY generate the
private key and export the public key for certification private key and export the public key for certification
to the I2NSF Controller. How the NSF generates these to the I2NSF Controller. How the NSF generates these
cryptographic material (public key/ private keys) and cryptographic material (public key/ private keys) and
exports the public key, is out of scope of this exports the public key is out of scope of this
document.</t> document.</li>
</list> </ul>
</t> </section>
<section anchor="sec-case2" numbered="true" toc="default">
</section> <name>IKE-less Case</name>
<section anchor="sec-case2" title="IKE-less case"> <t>
<t>
In the IKE-less case, the I2NSF Controller sends In the IKE-less case, the I2NSF Controller sends
the IPsec SA information to the NSF's SAD that the IPsec SA information to the NSF's SAD that
includes the private session keys required for includes the private session keys required for
integrity and encryption. The I2NSF Controller integrity and encryption. The I2NSF Controller
MUST NOT store the keys after <bcp14>MUST NOT</bcp14> store the keys after
distributing them. Moreover, the NSFs receiving distributing them. Moreover, the NSFs receiving
private key material MUST NOT allow the reading of private key material <bcp14>MUST NOT</bcp14> allow the r eading of
these values by any other entity (including the these values by any other entity (including the
I2NSF Controller itself) once they have been I2NSF Controller itself) once they have been
applied (i.e. write only operations) into the NSFs. applied (i.e., write-only operations) into the NSFs.
Nevertheless, if the attacker has access to the Nevertheless, if the attacker has access to the
I2NSF Controller during the period of time that I2NSF Controller during the period of time that
key material is generated, it may obtain these key material is generated, it may obtain these
values. In other words, the attacker might be able to values. In other words, the attacker might be able to
observe the IPsec traffic and decrypt, or even observe the IPsec traffic and decrypt, or even
modify and re-encrypt, the traffic between peers. modify and re-encrypt, the traffic between peers.
</t> </t>
<t>Finally, the security association between the <t>Finally, the security association between the
I2NSF Controller and the NSFs MUST provide, at I2NSF Controller and the NSFs <bcp14>MUST</bcp14> provide, a
t
least, the same degree of protection as the one least, the same degree of protection as the one
achieved by the IPsec SAs configured in the achieved by the IPsec SAs configured in the
NSFs. In particular, the security association NSFs. In particular, the security association
between the I2NSF Controller and the NSFs MUST between the I2NSF Controller and the NSFs <bcp14>MUST</bcp14 >
provide forward secrecy if this property is to provide forward secrecy if this property is to
be achieved in the IPsec SAs that the I2NSF be achieved in the IPsec SAs that the I2NSF
Controller configures in the NSFs. Similarly, Controller configures in the NSFs. Similarly,
the encryption algorithms used in the security the encryption algorithms used in the security
association between I2NSF Controller and the NSF association between the I2NSF Controller and the NSF
MUST have, at least, the same strength (minimum <bcp14>MUST</bcp14> have, at least, the same strength (minim
um
strength of a 128-bit key) as the algorithms strength of a 128-bit key) as the algorithms
used to establish the IPsec SAs. used to establish the IPsec SAs.
</t> </t>
</section> </section>
<section anchor="sec-yang" title="YANG modules"> <section anchor="sec-yang" numbered="true" toc="default">
<t>The modules specified in this document define a <name>YANG Modules</name>
<t>The YANG modules specified in this document define a
schema for data that is designed to be accessed via schema for data that is designed to be accessed via
network management protocols such as NETCONF network management protocols such as NETCONF
<xref target="RFC6241"/> or RESTCONF <xref target="RFC6241" format="default"/> or RESTCONF
<xref target="RFC8040"/>. The lowest NETCONF layer <xref target="RFC8040" format="default"/>. The lowest NE
TCONF layer
is the secure transport layer, and the is the secure transport layer, and the
mandatory-to-implement secure transport is Secure Shell mandatory-to-implement secure transport is Secure Shell
(SSH) <xref target="RFC6242"/>. The lowest RESTCONF (SSH) <xref target="RFC6242" format="default"/>. The low est RESTCONF
layer is HTTPS, and the mandatory-to-implement secure layer is HTTPS, and the mandatory-to-implement secure
transport is TLS <xref target="RFC8446"/>.</t> transport is TLS <xref target="RFC8446" format="default"
/>.</t>
<t>The Network Configuration Access Control Model (NACM) <t>The Network Configuration Access Control Model (NACM)
<xref target="RFC8341"/> provides the means to restrict <xref target="RFC8341" format="default"/> provides the m
eans to restrict
access for particular NETCONF or RESTCONF users to a access for particular NETCONF or RESTCONF users to a
preconfigured subset of all available NETCONF or preconfigured subset of all available NETCONF or
RESTCONF protocol operations and content.</t> RESTCONF protocol operations and content.</t>
<t>There are a number of data nodes defined in these YANG
<t>There are a number of data nodes defined in these YANG
modules that are writable/creatable/deletable (i.e., modules that are writable/creatable/deletable (i.e.,
config true, which is the default). These data nodes config true, which is the default). These data nodes
may be considered sensitive or vulnerable in some may be considered sensitive or vulnerable in some
network environments. Write operations network environments. Write operations
(e.g., edit-config) to these data nodes without (e.g., edit-config) to these data nodes without
proper protection can have a negative proper protection can have a negative
effect on network operations. These are the subtrees and effect on network operations. These are the subtrees and
data nodes and their sensitivity/vulnerability:</t> data nodes and their sensitivity/vulnerability:</t>
<t> For the IKE case (ietf-i2nsf-ike): <dl newline="true" spacing="normal">
<dt>For the IKE case (ietf-i2nsf-ike):</dt>
<list hangIndent="6" style="hanging"> <dd>
<t>/ipsec-ike: The entire container in this module <dl newline="false" spacing="normal">
<dt>/ipsec-ike:</dt>
<dd>The entire container in this module
is sensitive to write operations. An attacker may is sensitive to write operations. An attacker may
add/modify the credentials to be used for the add/modify the credentials to be used for the
authentication (e.g., to impersonate a NSF), the authentication (e.g., to impersonate an NSF), for th e
trust root (e.g., changing the trusted CA trust root (e.g., changing the trusted CA
certificates), the cryptographic algorithms certificates), for the cryptographic algorithms
(allowing a downgrading attack), the IPsec (allowing a downgrading attack), for the IPsec
policies (e.g., by allowing leaking of data traffic policies (e.g., by allowing leaking of data traffic
by changing to an allow policy), and in general by changing to an allow policy), and in general,
changing the IKE SA conditions and credentials changing the IKE SA conditions and credentials
between any NSF.</t> between any NSF.</dd></dl>
</list> </dd>
</t> <dt> For the IKE-less case (ietf-i2nsf-ikeless):</dt>
<t> For the IKE-less case (ietf-i2nsf-ikeless): <dd>
<dl newline="false" spacing="normal">
<list hangIndent="6" style="hanging"> <dt>/ipsec-ikeless: </dt>
<t>/ipsec-ikeless: The entire container in this <dd>The entire container in this
module is sensitive to write operations. An module is sensitive to write operations. An
attacker may add/modify/delete any IPsec policies attacker may add/modify/delete any IPsec policies
(e.g., by allowing leaking of data traffic by (e.g., by allowing leaking of data traffic by
changing to a allow policy) in the changing to an allow policy) in the
/ipsec-ikeless/spd container, and /ipsec-ikeless/spd container,
add/modify/delete any IPsec SAs between add/modify/delete any IPsec SAs between
two NSF by means of /ipsec-ikeless/sad container two NSF by means of /ipsec-ikeless/sad container,
and, in general, changing any IPsec SAs and IPsec and, in general, change any IPsec SAs and IPsec
policies between any NSF.</t> policies between any NSF.</dd></dl>
</list> </dd>
</t> </dl>
<t>Some of the readable data nodes in this YANG module may <t>Some of the readable data nodes in these YANG modules may
be considered sensitive or vulnerable in some network be considered sensitive or vulnerable in some network
environments. It is thus important to control read environments. It is thus important to control read
access (e.g., via get, get-config, or notification) to access (e.g., via get, get-config, or notification) to
these data nodes. These are the subtrees and data nodes these data nodes. These are the subtrees and data nodes
and their sensitivity/vulnerability:</t> and their sensitivity/vulnerability:</t>
<dl newline="true" spacing="normal">
<t> For the IKE case (ietf-i2nsf-ike): <dt> For the IKE case (ietf-i2nsf-ike):</dt>
<dd>
<list hangIndent="6" style="hanging"> <dl newline="false" spacing="normal">
<t>/ipsec-ike/pad: This container includes sensitive <dt>/ipsec-ike/pad:</dt>
<dd>This container includes sensitive
information to read operations. This information information to read operations. This information
MUST NOT be returned to a client. For <bcp14>MUST NOT</bcp14> be returned to a client. For
example, cryptographic material configured in example, cryptographic material configured in
the NSFs (peer-authentication/pre-shared/secret and peer-authentication/digital-signature/private-key) the NSFs (peer-authentication/pre-shared/secret and peer-authentication/digital-signature/private-key)
are already protected by the NACM are already protected by the NACM
extension "default-deny-all" in this extension "default-deny-all" in this
document.</t> document.</dd></dl>
</list> </dd>
</t> <dt> For the IKE-less case (ietf-i2nsf-ikeless):</dt>
<t> For the IKE-less case (ietf-i2nsf-ikeless): <dd>
<dl newline="false" spacing="normal">
<list hangIndent="6" style="hanging"> <dt>/ipsec-ikeless/sad/sad-entry/ipsec-sa-config/esp-sa:</dt>
<t>/ipsec-ikeless/sad/sad-entry/ipsec-sa-config/esp- <dd>This
sa: This
container includes symmetric keys for the IPsec container includes symmetric keys for the IPsec
SAs. For example, encryption/key contains an ESP SAs. For example, encryption/key contains an ESP
encryption key value and encryption/iv contains encryption key value and encryption/iv contains
an initialization vector value. Similarly, an Initialization Vector value. Similarly,
integrity/key has an ESP integrity/key has an ESP
integrity key value. Those values MUST NOT be integrity key value. Those values <bcp14>MUST NO T</bcp14> be
read by anyone and are protected by the NACM read by anyone and are protected by the NACM
extension "default-deny-all" in this document. extension "default-deny-all" in this document.
</t> </dd></dl>
</list> </dd>
</t> </dl>
</section> </section>
</section> </section>
<section anchor="ack" title="Acknowledgements"> </middle>
<t> <back>
Authors want to thank Paul Wouters, Valery
Smyslov,Sowmini Varadhan, David Carrel, Yoav
Nir, Tero Kivinen,
Martin Bjorklund, Graham Bartlett, Sandeep
Kampati, Linda
Dunbar, Mohit Sethi, Martin Bjorklund, Tom
Petch, Christian
Hopps, Rob Wilton, Carlos J. Bernardos, Alejandro
Perez-Mendez, Alejandro Abad-Carrascosa, Ignacio
Martinez, Ruben Ricart, and all IESG members
that have reviewed this document for their
valuable comments.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC4301;
&RFC7296;
&RFC6020;
&RFC8446;
&RFC6241;
&RFC6242;
&RFC8341;
&RFC8040;
&RFC7950;
&RFC8247;
&RFC8342;
&RFC8340;
&RFC2247;
&RFC3947;
&RFC4303;
&RFC5280;
&RFC5915;
&RFC7383;
&RFC7427;
&RFC7619;
&RFC8017;
&RFC8174;
&RFC8221;
&RFC6991;
&RFC5322;
&RFC3948;
&RFC8229;
<reference anchor="IKEv2-Parameters" target='https://www.iana.or
g/assignments/ikev2-parameters/ikev2-parameters.xhtml'>
<front>
<title>Internet Key Exchange Version 2 (IKEv2) Parameter
s </title>
<author initials="IANA">
<organization>Internet Assigned Numbers Authority (I
ANA)</organization>
</author>
<date month="August" day="14" year="2020"/>
</front>
<format type="TXT" target="https://www.iana.org/assignments/
ikev2-parameters/ikev2-parameters.xhtml"/>
</reference>
<reference anchor="IKEv2-Transform-Type-1" target='https://www.i
ana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-5'>
<front>
<title>Internet Key Exchange Version 2 (IKEv2) Parameter
s - Transform Type Values - Transform Type 1 - Encryption Algorithm Transform ID
s</title>
<author initials="IANA">
<organization>Internet Assigned Numbers Authority (I
ANA)</organization>
</author>
<date month="August" day="14" year="2020"/>
</front>
<format type="TXT" target="https://www.iana.org/assignments/
ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-5"/>
</reference>
<reference anchor="IKEv2-Transform-Type-3" target='https://www.i <displayreference target="I-D.tran-ipsecme-yang" to="TRAN-IPSECME-YANG"/>
ana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-7'> <displayreference target="I-D.carrel-ipsecme-controller-ike" to="IPSECME-CONTROL
<front> LER-IKE"/>
<title>Internet Key Exchange Version 2 (IKEv2) Parameter
s - Transform Type Values - Transform Type 3 - Integrity Algorithm Transform IDs
</title>
<author initials="IANA">
<organization>Internet Assigned Numbers Authority (I
ANA)</organization>
</author>
<date month="August" day="14" year="2020"/>
</front>
<format type="TXT" target="https://www.iana.org/assignments/
ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-7"/>
</reference>
<reference anchor="IKEv2-Transform-Type-4" target='https://www.i <references>
ana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-8'> <name>References</name>
<front> <references>
<title>Internet Key Exchange Version 2 (IKEv2) Parameter <name>Normative References</name>
s - Transform Type Values - Transform Type 4 - Diffie-Hellman Group Transform ID <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
s</title> FC.2119.xml"/>
<author initials="IANA"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<organization>Internet Assigned Numbers Authority (I FC.4301.xml"/>
ANA)</organization> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
</author> FC.7296.xml"/>
<date month="August" day="14" year="2020"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
</front> FC.6020.xml"/>
<format type="TXT" target="https://www.iana.org/assignments/ <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-8"/> FC.8446.xml"/>
</reference> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6241.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6242.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8341.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8040.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7950.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8247.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8342.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8340.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3947.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4303.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5280.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5915.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7383.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7427.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7619.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8017.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8221.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6991.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5322.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3948.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8229.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6960.xml"/>
<reference anchor="IKEv2-Auth-Method" target='https://www.iana.o <reference anchor="IKEv2-Parameters" target="https://www.iana.org/assign
rg/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-12'> ments/ikev2-parameters/">
<front> <front>
<title>Internet Key Exchange Version 2 (IKEv2) Parameter <title>Internet Key Exchange Version 2 (IKEv2) Parameters </title>
s - IKEv2 Authentication Method</title> <author>
<author initials="IANA"> <organization>IANA</organization>
<organization>Internet Assigned Numbers Authority (I </author>
ANA)</organization> </front>
</author> </reference>
<date month="August" day="14" year="2020"/>
</front>
<format type="TXT" target="https://www.iana.org/assignments/
ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-12"/>
</reference>
<reference anchor="IANA-Protocols-Number" target='https://www.ia <reference anchor="IKEv2-Transform-Type-1" target="https://www.iana.org/
na.org/assignments/protocol-numbers/protocol-numbers.xhtml'> assignments/ikev2-parameters/">
<front> <front>
<title>Protocol Numbers</title> <title>Transform Type 1 - Encryption Algorithm Transform IDs</title>
<author initials="IANA"> <author>
<organization>Internet Assigned Numbers Authority (I <organization>IANA</organization>
ANA)</organization> </author>
</author> </front>
<date month="January" day="31" year="2020"/> </reference>
</front>
<format type="TXT" target="https://www.iana.org/assignments/
protocol-numbers/protocol-numbers.xhtml"/>
</reference>
<reference anchor="IANA-Method-Type" target='https://www.iana.or <reference anchor="IKEv2-Transform-Type-3" target="https://www.iana.org/
g/assignments/eap-numbers/eap-numbers.xhtml#eap-numbers-4'> assignments/ikev2-parameters/">
<front> <front>
<title>Method Type</title> <title>Transform Type 3 - Integrity Algorithm Transform IDs</title>
<author initials="IANA"> <author>
<organization>Internet Assigned Numbers Authority (I <organization>IANA</organization>
ANA)</organization> </author>
</author> </front>
<date month="April" day="14" year="2020"/> </reference>
</front>
<format type="TXT" target="https://www.iana.org/assignments/
protocol-numbers/protocol-numbers.xhtml"/>
</reference>
<reference anchor="ITU-T.X.690"> <reference anchor="IKEv2-Transform-Type-4" target="https://www.iana.org/
<front> assignments/ikev2-parameters/">
<title>Recommendation ITU-T X.690</title> <front>
<author/> <title>Transform Type 4 - Diffie-Hellman Group Transform IDs</title>
<date month="August" year="2015"/> <author>
</front> <organization>IANA</organization>
</reference> </author>
</front>
</reference>
</references> <reference anchor="IKEv2-Auth-Method" target="https://www.iana.org/assig
nments/ikev2-parameters/">
<front>
<title>IKEv2 Authentication Method</title>
<author>
<organization>IANA</organization>
</author>
</front>
</reference>
<references title="Informative References"> <reference anchor="IANA-Protocols-Number" target="https://www.iana.org/a
&RFC7149; ssignments/protocol-numbers/">
&RFC2367; <front>
&RFC6071; <title>Protocol Numbers</title>
&RFC7426; <author>
&RFC3688; <organization>IANA</organization>
&RFC6437; </author>
&RFC8192; </front>
&RFC8329; </reference>
&RFC6040;
<reference anchor="I-D.tran-ipsecme-yang">
<front>
<title>Yang Data Model for Internet Protocol
Security (IPsec)</title>
<author initials="K" surname="Tran" fullname="Khanh Tran
">
<organization/>
</author>
<author initials="H" surname="Wang" fullname="Honglei Wa
ng">
<organization/>
</author>
<author initials="V" surname="Nagaraj" fullname="Vijay K
umar Nagaraj">
<organization/>
</author>
<author initials="X" surname="Chen" fullname="Xia Chen">
<organization/>
</author>
<date month="June" day="15" year="2015"/>
<abstract>
<t>
This document describes a YANG data model
for the IPsec(Internet Protocol Security)
protocol. The model covers the IPsec
protocol operational state and remote
procedural calls.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-tran-ipsecme-
yang-01"/>
<format type="TXT" target="https://tools.ietf.org/html/draft
-tran-ipsecme-yang-01"/>
</reference>
<reference anchor="I-D.carrel-ipsecme-controller-ike"> <reference anchor="IANA-Method-Type" target="https://www.iana.org/assign
<front> ments/eap-numbers/">
<title>IPsec Key Exchange using a <front>
Controller</title> <title>Method Type</title>
<author initials="D" surname="Carrel" fullname="David Ca <author>
rrel"> <organization>IANA</organization>
<organization/> </author>
</author> </front>
<author initials="B" surname="Weiss" fullname="Brian Wei </reference>
ss"> <reference anchor="ITU-T.X.690">
<organization/> <front>
</author> <title>Information Technology - ASN.1 encoding rules: Specification
<date month="March" day="11" year="2019"/> of Basic
<abstract> Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguishe
<t> d Encoding
This document presents a key exchange Rules (DER)</title>
method allowing devices managed by a <author><organization>International Telecommunication
controller (e.g., an SDN management Union</organization></author>
station) to create private <date month="February" year="2021"/>
pair-wise IPsec SAs without IKEv2 or any </front>
other direct peer-to-peer <refcontent>ITU-T Recommendation X.690</refcontent>
session establishment messages. The <refcontent>ISO/IEC 8825-1</refcontent>
method can be used when a full </reference>
mesh of IKEv2 sessions between IPsec </references>
devices is not appropriate. <references>
</t> <name>Informative References</name>
</abstract> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
</front> FC.7149.xml"/>
<seriesInfo name="Internet-Draft" value="draft-carrel-ipsecm <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
e-controller-ike-01"/> FC.2367.xml"/>
<format type="TXT" target="https://tools.ietf.org/html/draft <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
-carrel-ipsecme-controller-ike-01"/> FC.6071.xml"/>
</reference> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7426.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3688.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6437.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8192.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8329.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6040.xml"/>
<reference anchor="ITU-T.Y.3300" target='https://www.itu.int/rec <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
/T-REC-Y.3300/en'> .tran-ipsecme-yang.xml"/>
<front>
<title>Recommendation ITU-T Y.3300</title>
<author/>
<date month="June" year="2014"/>
</front>
</reference>
<reference anchor="ONF-SDN-Architecture" target='https://www.ope <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
nnetworking.org/wp-content/uploads/2013/02/TR_SDN_ARCH_1.0_06062014.pdf .carrel-ipsecme-controller-ike.xml"/>
'>
<front>
<title>SDN Architecture</title>
<author/>
<date month="June" year="2014"/>
</front>
</reference>
<reference anchor="ONF-OpenFlow" target='https://www.opennetwork <reference anchor="ITU-T.Y.3300" target="https://www.itu.int/rec/T-REC-Y
ing.org/wp-content/uploads/2014/10/openflow-spec-v1.4.0.pdf .3300/en">
'> <front>
<front> <title>Y.3300: Framework of software-defined networking</title>
<title>OpenFlow Switch Specification (Version <author>
1.4.0)</title> <organization>International Telecommunications Union</organization>
<author> </author>
<organization>ONF</organization> <date month="June" year="2014"/>
</author> </front>
<date month="October" year="2013"/> </reference>
</front>
</reference>
<!--<reference anchor="ITU-T.X.1252"> <reference anchor="ONF-SDN-Architecture" target="https://www.opennetwork
<front> ing.org/wp-content/uploads/2013/02/TR_SDN_ARCH_1.0_06062014.pdf ">
<title>Baseline Identity Management Terms and <front>
Definitions</title> <title>SDN architecture</title>
<author/> <author>
<date month="April" year="2010"/> <organization>Open Networking Foundation</organization>
</front> </author>
</reference>--> <date month="June" year="2014"/>
</front>
<seriesInfo name="Issue" value="1"/>
</reference>
<!--<reference anchor="ITU-T.X.800"> <reference anchor="ONF-OpenFlow" target="https://www.opennetworking.org/
<front> wp-content/uploads/2014/10/openflow-spec-v1.4.0.pdf ">
<title>Security Architecture for Open Systems <front>
Interconnection for CCITT <title>OpenFlow Switch Specification</title>
Applications</title> <author>
<author/> <organization>Open Networking Foundation</organization>
<date month="March" year="1991"/> </author>
</front> <date month="October" year="2013"/>
</reference>--> </front>
<reference anchor="netconf-vpn" target='https://ripe68.ripe.net/ <seriesInfo name="Version" value="1.4.0 (Wire Protocol 0x05)"/>
presentations/181-NETCONF-YANG-tutorial-43.pdf'> </reference>
<front> <reference anchor="netconf-vpn" target="https://ripe68.ripe.net/
<title>Tutorial: NETCONF and YANG</title> presentations/181-NETCONF-YANG-tutorial-43.pdf">
<author> <front>
<organization>Stefan Wallin</organization> <title>Tutorial: NETCONF and YANG</title>
</author> <author>
<date month="January" year="2014"/> <organization>Stefan Wallin</organization>
</front> </author>
</reference> <date month="January" year="2014"/>
</front>
</reference>
<reference anchor="strongswan" target='https://www.strongswan.or <reference anchor="strongswan" target="https://www.strongswan.org/">
g/'> <front>
<front> <title>strongSwan: the OpenSource IPsec-based VPN
<title>StrongSwan: the OpenSource IPsec-based VPN
Solution</title> Solution</title>
<author initials="CESNET"> <author initials="CESNET">
<organization>CESNET</organization> <organization>CESNET</organization>
</author> </author>
<date month="September" day="07" year="2020"/> </front>
</front> <format type="TXT" target="https://www.strongswan.org"/>
<format type="TXT" target="https://www.strongswan.org"/> </reference>
</reference>
<reference anchor="libreswan" target='https://libreswan.org/'>
<front>
<title>Libreswan VPN software</title>
<author initials="The Libreswan Project">
<organization>The Libreswan Project</organization>
</author>
<date month="September" day="7" year="2020"/>
</front>
<format type="TXT" target="https://libreswan.org/"/>
</reference>
<reference anchor="SDNSecurity">
<front>
<title>Towards secure and dependable software-defined ne
tworks. HotSDN 2013 - Proceedings of the 2013 ACM SIGCOMM Workshop on Hot Topics
in Software Defined Networking. 55-60. 10.1145/2491185.2491199.
</title>
<author initials="D" surname="Kreutz" fullname="D. Kreut
z">
<organization/>
</author>
<author initials="F" surname="Ramos" fullname="F. Ramos"
>
<organization/>
</author>
<author initials="P" surname="Verissimo" fullname="P. Ve
rissimo">
<organization/>
</author>
<date year="2013"/>
</front>
</reference>
<reference anchor="SDNSecServ">
<front>
<title>SDN Security: A Survey. IEEE SDN for Future Netwo
rks and Services (SDN4FNS), Trento, 2013, pp. 1-7, doi: 10.1109/SDN4FNS.2013.670
2553.</title>
<author initials="S" surname="Scott-Hayward" fullname="S
. Scott-Hayward">
<organization/>
</author>
<author initials="G" surname="O'Callaghan" fullname="G.
O'Callaghan">
<organization/>
</author>
<author initials="P" surname="Sezer" fullname="P. Sezer"
>
<organization/>
</author>
<date year="2013"/>
</front>
</reference>
</references>
<section anchor="appendix-d" title="XML configuration example for IK <reference anchor="libreswan" target="https://libreswan.org/">
E case (gateway-to-gateway)"> <front>
<title>Libreswan VPN software</title>
<author initials="The Libreswan Project">
<organization>The Libreswan Project</organization>
</author>
</front>
</reference>
<t>This example shows a XML configuration file sent by the I2NSF <reference anchor="SDNSecurity">
Controller to establish a IPsec SA between two NSFs (see <xref target="fig:exam <front>
ple-ike"/>) in tunnel mode (gateway-to-gateway) with ESP, authentication based o <title>Towards secure and dependable software-defined networks</titl
n X.509 certificates (simplified for brevity with "base64encodedvalue==") and ap e>
plying the IKE case.</t> <author initials="D" surname="Kreutz" fullname="D. Kreutz">
<organization/>
</author>
<author initials="F" surname="Ramos" fullname="F. Ramos">
<organization/>
</author>
<author initials="P" surname="Verissimo" fullname="P. Verissimo">
<organization/>
</author>
<date month="August" year="2013"/>
</front>
<refcontent>Proceedings of the second ACM SIGCOMM workshop on Hot Topic
s in software defined networking, pp. 55-60</refcontent>
<seriesInfo name="DOI" value="10.1145/2491185.2491199"/>
</reference>
<t> <reference anchor="SDNSecServ">
<figure align="center" anchor="fig:example-ike" title="IKE c <front>
ase, tunnel mode , X.509 certificate authentication."> <title>Sdn Security: A Survey</title>
<artwork align="center"> <author initials="S" surname="Scott-Hayward" fullname="S. Scott-Hayw
<![CDATA[ ard">
<organization/>
</author>
<author initials="G" surname="O'Callaghan" fullname="G. O'Callaghan"
>
<organization/>
</author>
<author initials="P" surname="Sezer" fullname="P. Sezer">
<organization/>
</author>
<date month="November" year="2013"/>
</front>
<refcontent>2013 IEEE SDN for Future Networks and Services (SDN4FNS), p
p. 1-7</refcontent>
<seriesInfo name="DOI" value="10.1109/SDN4FNS.2013.6702553"/>
</reference>
</references>
</references>
<section anchor="appendix-d" numbered="true" toc="default">
<name>XML Configuration Example for IKE Case (Gateway-to-Gateway)</name>
<t>This example shows an XML configuration file sent by the I2NSF Controll
er to establish an IPsec SA between two NSFs (see <xref target="fig_example-ike"
format="default"/>) in tunnel mode (gateway-to-gateway) with ESP, with authenti
cation based on X.509 certificates (simplified for brevity with "base64encodedva
lue==") and applying the IKE case.</t>
<figure anchor="fig_example-ike">
<name>IKE Case, Tunnel Mode, X.509 Certificate Authentication</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
+------------------+ +------------------+
| I2NSF Controller | | I2NSF Controller |
+------------------+ +------------------+
I2NSF NSF-Facing | I2NSF NSF-Facing |
Interface | Interface |
/-----------------+---------------\ /-----------------+---------------\
/ \ / \
/ \ / \
+----+ +--------+ +--------+ +----+ +----+ +--------+ +--------+ +----+
| h1 |--| nsf_h1 |== IPsec_ESP_Tunnel_mode == | nsf_h2 |--| h2 | | h1 |--| nsf_h1 |== IPsec_ESP_Tunnel_mode == | nsf_h2 |--| h2 |
+----+ +--------+ +--------+ +----+ +----+ +--------+ +--------+ +----+
:1 :100 :200 :1 :1 :100 :200 :1
(2001:db8:1:/64) (2001:db8:123:/64) (2001:db8:2:/64) (2001:db8:1:/64) (2001:db8:123:/64) (2001:db8:2:/64)
]]> ]]></artwork>
</artwork> </figure>
</figure> <sourcecode type="xml"><![CDATA[
</t>
<t>
<figure>
<artwork>
<![CDATA[
<ipsec-ike xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-ike" <ipsec-ike xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-ike"
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
<pad> <pad>
<pad-entry> <pad-entry>
<name>nsf_h1_pad</name> <name>nsf_h1_pad</name>
<ipv6-address>2001:db8:123::100</ipv6-address> <ipv6-address>2001:db8:123::100</ipv6-address>
<peer-authentication> <peer-authentication>
<auth-method>digital-signature</auth-method> <auth-method>digital-signature</auth-method>
<digital-signature> <digital-signature>
<cert-data>base64encodedvalue==</cert-data> <cert-data>base64encodedvalue==</cert-data>
skipping to change at line 4325 skipping to change at line 4000
<ca-data>base64encodedvalue==</ca-data> <ca-data>base64encodedvalue==</ca-data>
</digital-signature> </digital-signature>
</peer-authentication> </peer-authentication>
</pad-entry> </pad-entry>
</pad> </pad>
<conn-entry> <conn-entry>
<name>nsf_h1-nsf_h2</name> <name>nsf_h1-nsf_h2</name>
<autostartup>start</autostartup> <autostartup>start</autostartup>
<version>ikev2</version> <version>ikev2</version>
<initial-contact>false</initial-contact> <initial-contact>false</initial-contact>
<fragmentation><enable>false</enable></fragmentation> <fragmentation><enabled>false</enabled></fragmentation>
<ike-sa-lifetime-soft> <ike-sa-lifetime-soft>
<rekey-time>60</rekey-time> <rekey-time>60</rekey-time>
<reauth-time>120</reauth-time> <reauth-time>120</reauth-time>
</ike-sa-lifetime-soft> </ike-sa-lifetime-soft>
<ike-sa-lifetime-hard> <ike-sa-lifetime-hard>
<over-time>3600</over-time> <over-time>3600</over-time>
</ike-sa-lifetime-hard> </ike-sa-lifetime-hard>
<!--AUTH_HMAC_SHA2_512_256--> <!--AUTH_HMAC_SHA2_512_256-->
<ike-sa-intr-alg>14</ike-sa-intr-alg> <ike-sa-intr-alg>14</ike-sa-intr-alg>
<!--ENCR_AES_CBC - 128 bits--> <!--ENCR_AES_CBC - 128 bits-->
skipping to change at line 4416 skipping to change at line 4091
</child-sa-lifetime-soft> </child-sa-lifetime-soft>
<child-sa-lifetime-hard> <child-sa-lifetime-hard>
<bytes>2000000</bytes> <bytes>2000000</bytes>
<packets>2000</packets> <packets>2000</packets>
<time>60</time> <time>60</time>
<idle>120</idle> <idle>120</idle>
</child-sa-lifetime-hard> </child-sa-lifetime-hard>
</child-sa-info> </child-sa-info>
</conn-entry> </conn-entry>
</ipsec-ike> </ipsec-ike>
]]> ]]></sourcecode>
</artwork> </section>
</figure> <section anchor="appendix-e" numbered="true" toc="default">
</t> <name>XML Configuration Example for IKE-less Case (Host-to-Host)</name>
</section> <t>This example shows an XML configuration file sent by the I2NSF Controll
<section anchor="appendix-e" title="XML configuration example for IK er to establish an IPsec SA between two NSFs (see <xref target="fig_example-ikel
E-less case (host-to-host)"> ess" format="default"/>) in transport mode (host-to-host) with ESP in the IKE-le
<t>This example shows a XML configuration file sent by the I2NSF ss case.</t>
Controller to establish a IPsec SA between two NSFs (see <xref target="fig:exam <figure anchor="fig_example-ikeless">
ple-ikeless"/>) in transport mode (host-to-host) with ESP in the IKE-less case.< <name>IKE-less Case, Transport Mode</name>
/t> <artwork align="center" name="" type="" alt=""><![CDATA[
<t>
<figure align="center" anchor="fig:example-ikeless" title="I
KE-less case, transport mode.">
<artwork align="center">
<![CDATA[
+------------------+ +------------------+
| I2NSF Controller | | I2NSF Controller |
+------------------+ +------------------+
I2NSF NSF-Facing | I2NSF NSF-Facing |
Interface | Interface |
/--------------------+-------------------\ /--------------------+-------------------\
/ \ / \
/ \ / \
+--------+ +--------+ +--------+ +--------+
| nsf_h1 |===== IPsec_ESP_Transport_mode =====| nsf_h2 | | nsf_h1 |===== IPsec_ESP_Transport_mode =====| nsf_h2 |
+--------+ +--------+ +--------+ +--------+
:100 (2001:db8:123:/64) :200 :100 (2001:db8:123:/64) :200
]]></artwork>
]]> </figure>
</artwork> <sourcecode type="xml"><![CDATA[
</figure>
</t>
<t>
<figure>
<artwork>
<![CDATA[
<ipsec-ikeless <ipsec-ikeless
xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless" xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless"
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
<spd> <spd>
<spd-entry> <spd-entry>
<name> <name>
in/trans/2001:db8:123::200/2001:db8:123::100 in/trans/2001:db8:123::200/2001:db8:123::100
</name> </name>
<direction>inbound</direction> <direction>inbound</direction>
<reqid>1</reqid> <reqid>1</reqid>
skipping to change at line 4601 skipping to change at line 4267
<bytes>1000000</bytes> <bytes>1000000</bytes>
<packets>1000</packets> <packets>1000</packets>
<time>30</time> <time>30</time>
<idle>60</idle> <idle>60</idle>
<action>replace</action> <action>replace</action>
</sa-lifetime-soft> </sa-lifetime-soft>
</ipsec-sa-config> </ipsec-sa-config>
</sad-entry> </sad-entry>
</sad> </sad>
</ipsec-ikeless> </ipsec-ikeless>
]]> ]]></sourcecode>
</artwork> </section>
</figure> <section anchor="appendix-f" numbered="true" toc="default">
</t> <name>XML Notification Examples</name>
</section> <t>In the following, several XML files are shown to
<section anchor="appendix-f" title="XML notification examples">
<t>In the following, several XML files are shown to
illustrate different types of notifications defined illustrate different types of notifications defined
in the IKE-less YANG model, which are sent by the in the IKE-less YANG data model, which are sent by the
NSF to the I2NSF Controller. The notifications NSF to the I2NSF Controller. The notifications
happen in the IKE-less case.</t> happen in the IKE-less case.</t>
<t> <figure anchor="sadb-expire-not">
<figure align="center" anchor="fig:expire-example" title="Ex <name>Example of the sadb-expire Notification</name>
ample of sadb-expire notification."> <sourcecode type="xml"><![CDATA[
<artwork>
<![CDATA[
<sadb-expire xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless"> <sadb-expire xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless">
<ipsec-sa-name>in/trans/2001:db8:123::200/2001:db8:123::100 <ipsec-sa-name>in/trans/2001:db8:123::200/2001:db8:123::100
</ipsec-sa-name> </ipsec-sa-name>
<soft-lifetime-expire>true</soft-lifetime-expire> <soft-lifetime-expire>true</soft-lifetime-expire>
<lifetime-current> <lifetime-current>
<bytes>1000000</bytes> <bytes>1000000</bytes>
<packets>1000</packets> <packets>1000</packets>
<time>30</time> <time>30</time>
<idle>60</idle> <idle>60</idle>
</lifetime-current> </lifetime-current>
</sadb-expire> </sadb-expire>
]]> ]]></sourcecode>
</artwork> </figure>
</figure> <figure anchor="sadb-acquire-not">
</t> <name>Example of the sadb-acquire Notification</name>
<t> <sourcecode type="xml"><![CDATA[
<figure align="center" anchor="fig:acquire-example" title="E
xample of sadb-acquire notification.">
<artwork>
<![CDATA[
<sadb-acquire xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless"> <sadb-acquire xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless">
<ipsec-policy-name>in/trans/2001:db8:123::200/2001:db8:123::100 <ipsec-policy-name>in/trans/2001:db8:123::200/2001:db8:123::100
</ipsec-policy-name> </ipsec-policy-name>
<traffic-selector> <traffic-selector>
<local-prefix>2001:db8:123::200/128</local-prefix> <local-prefix>2001:db8:123::200/128</local-prefix>
<remote-prefix>2001:db8:123::100/128</remote-prefix> <remote-prefix>2001:db8:123::100/128</remote-prefix>
<inner-protocol>any</inner-protocol> <inner-protocol>any</inner-protocol>
<local-ports> <local-ports>
<start>0</start> <start>0</start>
<end>0</end> <end>0</end>
</local-ports> </local-ports>
<remote-ports> <remote-ports>
<start>0</start> <start>0</start>
<end>0</end> <end>0</end>
</remote-ports> </remote-ports>
</traffic-selector> </traffic-selector>
</sadb-acquire> </sadb-acquire>
]]> ]]></sourcecode>
</artwork> </figure>
</figure> <figure anchor="sadb-seq-overflow-not">
</t> <name>Example of the sadb-seq-overflow Notification</name>
<t> <sourcecode type="xml"><![CDATA[
<figure align="center" anchor="fig:seqoverflow-example" titl
e="Example of sadb-seq-overflow notification.">
<artwork>
<![CDATA[
<sadb-seq-overflow <sadb-seq-overflow
xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless"> xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless">
<ipsec-sa-name>in/trans/2001:db8:123::200/2001:db8:123::100 <ipsec-sa-name>in/trans/2001:db8:123::200/2001:db8:123::100
</ipsec-sa-name> </ipsec-sa-name>
</sadb-seq-overflow> </sadb-seq-overflow>
]]> ]]></sourcecode>
</artwork> </figure>
</figure> <figure anchor="sadb-bad-spi-not">
</t> <name>Example of the sadb-bad-spi Notification</name>
<t> <sourcecode type="xml"><![CDATA[
<figure align="center" anchor="fig:bad-spi-example" title="E
xample of sadb-bad-spi notification.">
<artwork>
<![CDATA[
<sadb-bad-spi <sadb-bad-spi
xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless"> xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless">
<spi>666</spi> <spi>666</spi>
</sadb-bad-spi> </sadb-bad-spi>
]]> ]]></sourcecode>
</artwork> </figure>
</figure> </section>
</t> <section anchor="appendix-g" numbered="true" toc="default">
</section> <name>Operational Use Case Examples</name>
<section anchor="appendix-g1" numbered="true" toc="default">
<section anchor="appendix-g" title="Operational use cases examples"> <name>Example of IPsec SA Establishment</name>
<t>This appendix exemplifies the applicability of the IKE case and
<section anchor="appendix-g1" title="Example of IPsec SA establishment">
<t>This appendix exemplifies the applicability of IKE case and
IKE-less case to traditional IPsec configurations, that is, IKE-less case to traditional IPsec configurations, that is,
host-to-host and gateway-to-gateway. The following examples assume host-to-host and gateway-to-gateway. The following examples assume
the existence of two NSFs needing to establish an the existence of two NSFs needing to establish an
end-to-end IPsec SA to protect their communications. Both NSFs end-to-end IPsec SA to protect their communications. Both NSFs
could be two hosts that exchange traffic (host-to-host) or gateways could be two hosts that exchange traffic (host-to-host) or gateways
(gateway-to-gateway), for example, within an enterprise that needs (gateway-to-gateway), for example, within an enterprise that needs
to protect the traffic between the networks of two branch to protect the traffic between the networks of two branch
offices.</t> offices.</t>
<t>Applicability of these configurations appear in current and new
<t>Applicability of these configurations appear in current and new networking scenarios.
networking scenarios. For example, SD-WAN technologies are For example, SD-WAN technologies are
providing dynamic and on-demand VPN connections between branch providing dynamic and on-demand VPN connections between branch
offices, or between branches and SaaS cloud services. Besides, IaaS offices or between branches and Software as a Service (SaaS)
cloud services. Besides,
Infrastructure as a Service (IaaS)
services providing virtualization environments are deployments that services providing virtualization environments are deployments that
often rely on IPsec to provide secure channels between virtual often rely on IPsec to provide secure channels between virtual
instances (host-to-host) and providing VPN solutions for instances (host-to-host) and providing VPN solutions for
virtualized networks (gateway-to-gateway).</t> virtualized networks (gateway-to-gateway).</t>
<t>As can be observed in the following, the I2NSF-based
<t>As can be observed in the following, the I2NSF-based IPsec management system (for IKE and IKE-less cases)
IPsec management system (for IKE and IKE-less cases), exhibits various advantages:
exhibits various </t>
advantages: <ol spacing="normal" type="1"><li>
<list style="numbers"> It allows creating IPsec SAs among two NSFs,
<t>
It allows to create IPsec SAs among two NSFs,
based only on the application based only on the application
of general Flow-based Protection Policies at the of general flow-based protection policies at the
I2NSF User. Thus, administrators can I2NSF User. Thus, administrators can
manage all security associations in a manage all security associations in a
centralized point with an abstracted view of the centralized point with an abstracted view of the
network. network.
</t> </li>
<t> <li>
Any NSF deployed in the system does not need Any NSF deployed in the system does not need
manual configuration, therefore allowing its manual configuration, therefore, allowing its
deployment in an automated manner. deployment in an automated manner.
</t> </li>
</list> </ol>
</t> <section anchor="sec-example-ikecase" numbered="true" toc="default">
<name>IKE Case</name>
<section anchor="sec-example-ikecase" title="IKE case"> <figure anchor="fig_g2gsinglecontroller1">
<name>Host-to-Host/Gateway-to-Gateway for the IKE Case</name>
<!-- maximum wide of the figure <artwork align="center" name="" type="" alt=""><![CDATA[
-->
<figure align="center" anchor="fig:g2gsinglecontroller1" title="H
ost-to-host / gateway-to-gateway for the IKE case.">
<artwork align="center">
<![CDATA[
+----------------------------------------+ +----------------------------------------+
| I2NSF User (IPsec Management System) | | I2NSF User (IPsec Management System) |
+----------------------------------------+ +----------------------------------------+
| |
(1) Flow-based I2NSF Consumer-Facing (1) Flow-based I2NSF Consumer-Facing
Protection Policy Interface Protection Policy Interface
| |
+---------|------------------------------+ +---------|------------------------------+
| | | | | |
| | I2NSF Controller | | | I2NSF Controller |
skipping to change at line 4762 skipping to change at line 4409
+--------------------------|-----|-------+ +--------------------------|-----|-------+
| | | |
I2NSF NSF-Facing Interface | | I2NSF NSF-Facing Interface | |
| (3) | | (3) |
|-------------------------+ +---| |-------------------------+ +---|
V V V V
+----------------------+ +----------------------+ +----------------------+ +----------------------+
| NSF A | | NSF B | | NSF A | | NSF B |
| IKEv2/IPsec(SPD/PAD) | | IKEv2/IPsec(SPD/PAD) | | IKEv2/IPsec(SPD/PAD) | | IKEv2/IPsec(SPD/PAD) |
+----------------------+ +----------------------+ +----------------------+ +----------------------+
]]> ]]></artwork>
</artwork> </figure>
</figure> <t>
<t> <xref target="fig_g2gsinglecontroller1" format="default"/>
<xref target="fig:g2gsinglecontroller1"/> describes the describes the
application of the IKE case when a data packet needs to be application of the IKE case when a data packet needs to be
protected in the path between the NSF A and NSF B: protected in the path between NSF A and NSF B:
</t> </t>
<t> <ol spacing="normal" type="1">
<list style="numbers"> <li>The I2NSF User defines a general flow-based
<t>
The I2NSF User defines a general flow-based
protection policy (e.g., protect data traffic between protection policy (e.g., protect data traffic between
NSF A and B). The I2NSF Controller looks NSF A and B). The I2NSF Controller looks
for the NSFs involved (NSF A and NSF B). for the NSFs involved (NSF A and NSF B).
</t> </li>
<li>The I2NSF Controller generates IKEv2
<t>
The I2NSF Controller generates IKEv2
credentials for them and translates the policies credentials for them and translates the policies
into SPD and PAD entries. into SPD and PAD entries.
</t> </li>
<t> <li>The I2NSF Controller inserts an IKEv2
The I2NSF Controller inserts an IKEv2
configuration that includes the SPD and PAD configuration that includes the SPD and PAD
entries in both NSF A and NSF B. If some of entries in both NSF A and NSF B. If some of
operations with NSF A and NSF B fail the operations with NSF A and NSF B fail, the
I2NSF Controller will stop the process and I2NSF Controller will stop the process and
perform a rollback operation by deleting any perform a rollback operation by deleting any
IKEv2, SPD and PAD configuration that had been IKEv2, SPD, and PAD configuration that had been
successfully installed in NSF A or B. successfully installed in NSF A or B.
</t> </li>
</list> </ol>
</t> <t> If the previous steps are successful, the flow is
<t> If the previous steps are successful, the flow is
protected by means of the IPsec SA established with IKEv2 protected by means of the IPsec SA established with IKEv2
between NSF A and NSF B.</t> between NSF A and NSF B.</t>
</section> </section>
<section anchor="sec-example-ikeless-case" title="IKE-less case"> <section anchor="sec-example-ikeless-case" numbered="true" toc="default"
>
<!-- maximum wide of the figure <name>IKE-less Case</name>
--> <figure anchor="fig_g2gsinglecontroller2">
<figure align="center" anchor="fig:g2gsinglecontroller2" title="Ho <name>Host-to-Host/Gateway-to-Gateway for the IKE-less Case</name>
st-to-host / gateway-to-gateway for IKE-less case."> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="center">
<![CDATA[
+----------------------------------------+ +----------------------------------------+
| I2NSF User (IPsec Management System) | | I2NSF User (IPsec Management System) |
+----------------------------------------+ +----------------------------------------+
| |
(1) Flow-based I2NSF Consumer-Facing (1) Flow-based I2NSF Consumer-Facing
Protection Policy Interface Protection Policy Interface
| |
+---------|------------------------------+ +---------|------------------------------+
| | | | | |
| | I2NSF Controller | | | I2NSF Controller |
skipping to change at line 4832 skipping to change at line 4471
+-------------------------|-----|--------+ +-------------------------|-----|--------+
| | | |
I2NSF NSF-Facing Interface | | I2NSF NSF-Facing Interface | |
| (3) | | (3) |
|----------------------+ +--| |----------------------+ +--|
V V V V
+----------------+ +----------------+ +----------------+ +----------------+
| NSF A | | NSF B | | NSF A | | NSF B |
| IPsec(SPD/SAD) | | IPsec(SPD/SAD) | | IPsec(SPD/SAD) | | IPsec(SPD/SAD) |
+----------------+ +----------------+ +----------------+ +----------------+
]]> ]]></artwork>
</artwork> </figure>
</figure> <t>
<xref target="fig_g2gsinglecontroller2" format="default"/> descri
<t> bes the
<xref target="fig:g2gsinglecontroller2"/> describes the
application of the IKE-less case when a data packet needs to be application of the IKE-less case when a data packet needs to be
protected in the path between the NSF A and NSF B: protected in the path between NSF A and NSF B:
</t> </t>
<t> <ol spacing="normal" type="1">
<list style="numbers"> <li>The I2NSF User establishes a general flow-based
<t>The I2NSF User establishes a general Flow-based protection policy, and the I2NSF Controller
Protection Policy and the I2NSF Controller looks for the involved NSFs.</li>
looks for the involved NSFs.</t> <li> The I2NSF Controller translates the flow-based security
<t> The I2NSF Controller translates the flow-based security policies into IPsec SPD and SAD entries.</li>
policies into IPsec SPD and SAD entries.</t> <li>
<t>The I2NSF Controller inserts these entries <t>The I2NSF Controller inserts these entries
in both NSF A and NSF B IPsec databases (i.e., SPD and in both NSF A and NSF B IPsec databases (i.e., SPD and
SAD). The following text describes how this SAD). The following text describes how this
would happen: would happen:</t>
<list style="symbols"> <ul spacing="normal">
<t>The I2NSF Controller chooses two random <li>The I2NSF Controller chooses two random
values as SPIs: for example, SPIa1 for the values as SPIs, for example, SPIa1 for the
inbound IPsec SA in the NSF A and SPIb1 for inbound IPsec SA in NSF A and SPIb1 for
the inbound IPsec SA in NSF B. The value of the inbound IPsec SA in NSF B. The value of
the SPIa1 MUST NOT be the same as any inbound the SPIa1 <bcp14>MUST NOT</bcp14> be the same as any inbo und
SPI in A. In the same way, the value of the SPI in A. In the same way, the value of the
SPIb1 MUST NOT be the same as any inbound SPI SPIb1 <bcp14>MUST NOT</bcp14> be the same as any inbound
in B. Moreover, the SPIa1 MUST be used in B SPI
in B. Moreover, the SPIa1 <bcp14>MUST</bcp14> be used in
B
for the outbound IPsec SA to A, while SPIb1 for the outbound IPsec SA to A, while SPIb1
MUST be used in A for the outbound IPsec SA <bcp14>MUST</bcp14> be used in A for the outbound IPsec S A
to B. to B.
It also generates fresh cryptographic It also generates fresh cryptographic
material for the new inbound/outbound IPsec material for the new inbound/outbound IPsec
SAs and their parameters.</t> SAs and their parameters.</li>
<li> After that, the I2NSF Controller simultaneously sends
<t> After that, the I2NSF Controller sends the new inbound IPsec SA with SPIa1 and
simultaneously the new inbound IPsec SA with SPIa1 and new outbound IPsec SA with SPIb1 to NSF A and the new
new outbound IPsec SA with SPIb1 to NSF A; and the new
inbound IPsec SA with SPIb1 and new outbound inbound IPsec SA with SPIb1 and new outbound
IPsec SA with SPIa1 to B, together with the IPsec SA with SPIa1 to B, together with the
corresponding IPsec policies. </t> corresponding IPsec policies. </li>
<li>Once the I2NSF Controller receives confirmation from
<t>Once the I2NSF Controller receives confirmation from
NSF A and NSF B, it knows that the IPsec SAs are NSF A and NSF B, it knows that the IPsec SAs are
correctly installed and ready.</t> correctly installed and ready.</li>
</list> </ul>
<t> Another alternative to this operation is
Other alternative to this operation is: the I2NSF Controller first sends the IPsec
the I2NSF Controller sends first the IPsec policies and new inbound IPsec SAs to A and B.
policies and new inbound IPsec SAs to A and B Once it obtains a successful confirmation of
and, once it obtains a successful confirmation of
these operations from NSF A and NSF B, it these operations from NSF A and NSF B, it
proceeds with installing the new outbound proceeds with installing the new outbound
IPsec SAs. Even though this procedure may increase the IPsec SAs. Even though this procedure may increase the
latency to complete the process, no traffic is sent latency to complete the process, no traffic is sent
over the network until the IPsec SAs are over the network until the IPsec SAs are
completely operative. In any case other completely operative. In any case, other
alternatives MAY be possible to implement step 3. alternatives <bcp14>MAY</bcp14> be possible to implement st
</t> ep 3.</t>
</li>
<t>If some of the operations described above fail <li>If some of the operations described above fail
(e.g., the NSF A reports an error when the (e.g., NSF A reports an error when the
I2NSF Controller is trying to install the SPD I2NSF Controller is trying to install the SPD
entry, the new inbound or outbound IPsec SAs) entry, the new inbound or outbound IPsec SAs),
the I2NSF Controller MUST perform rollback the I2NSF Controller <bcp14>MUST</bcp14> perform rollback
operations by deleting any new inbound or operations by deleting any new inbound or
outbound IPsec SA and SPD entry that had been outbound IPsec SA and SPD entry that had been
successfully installed in any of the NSFs successfully installed in any of the NSFs
(e.g., NSF B) and stop the process. Note that the (e.g., NSF B) and stop the process. Note that the
I2NSF Controller MAY retry several I2NSF Controller <bcp14>MAY</bcp14> retry several
times before giving up.</t> times before giving up.</li>
<li> Otherwise, if the steps 1 to 3 are successful, the flow
<t> Otherwise, if the steps 1 to 3 are successful, the flow
between NSF A and NSF B is protected by means of the IPsec SAs between NSF A and NSF B is protected by means of the IPsec SAs
established by the I2NSF Controller. It is worth mentioning that established by the I2NSF Controller. It is worth mentioning that
the I2NSF Controller associates a lifetime to the new IPsec SAs. the I2NSF Controller associates a lifetime to the new IPsec SAs.
When this lifetime expires, the NSF will send a sadb-expire When this lifetime expires, the NSF will send a sadb-expire
notification to the I2NSF Controller in order to start the notification to the I2NSF Controller in order to start the
rekeying process.</t> rekeying process.</li>
</list> </ol>
</t> <t>Instead of installing IPsec policies (in the SPD) and IPsec
<t>Instead of installing IPsec policies (in the SPD) and IPsec
SAs (in the SAD) in step 3 (proactive mode), it is also SAs (in the SAD) in step 3 (proactive mode), it is also
possible that the I2NSF Controller only installs the SPD possible that the I2NSF Controller only installs the SPD
entries in step 3 (reactive mode). In such a case, when a entries in step 3 (reactive mode). In such a case, when a
data packet requires to be protected with IPsec, the NSF data packet requires to be protected with IPsec, the NSF
that saw first the data packet will send a sadb-acquire that first saw the data packet will send a sadb-acquire
notification that informs the I2NSF Controller that needs notification that informs the I2NSF Controller that needs
SAD entries with the IPsec SAs to process the data SAD entries with the IPsec SAs to process the data
packet. Again, if some of the operations installing packet. Again, if some of the operations installing
the new inbound/outbound IPsec SAs fail, the I2NSF Controller stops the the new inbound/outbound IPsec SAs fail, the I2NSF Controller stops the
process and performs a rollback operation by deleting any new process and performs a rollback operation by deleting any new
inbound/outbound SAs that had been successfully installed.</t> inbound/outbound SAs that had been successfully installed.</t>
</section>
</section> </section>
</section> <section anchor="appendix-g2" numbered="true" toc="default">
<name>Example of the Rekeying Process in IKE-less Case</name>
<section anchor="appendix-g2" title="Example of the rekeying process in IKE-
less case">
<t>To explain an example of the rekeying process between two <t>To explain an example of the rekeying process between two
IPsec NSFs A and B, let assume that SPIa1 IPsec NSFs, A and B, assume that SPIa1
identifies the inbound IPsec SA in A, and SPIb1 identifies the inbound IPsec SA in A and SPIb1 identifies
the inbound IPsec SA in B. The rekeying process the inbound IPsec SA in B. The rekeying process
will take the following steps:</t> will take the following steps:</t>
<t> <ol spacing="normal" type="1">
<list style="numbers"> <li>The I2NSF Controller chooses two
<t>The I2NSF Controller chooses two
random values as SPI for the new inbound random values as SPI for the new inbound
IPsec SAs: for example, SPIa2 for the IPsec SAs, for example, SPIa2 for the
inbound IPsec SA in A and SPIb2 for the inbound IPsec SA in A and SPIb2 for the
inbound IPsec SA in B. The value of the inbound IPsec SA in B. The value of the
SPIa1 MUST NOT be the same as any SPIa1 <bcp14>MUST NOT</bcp14> be the same as any
inbound SPI in A. In the same way, the inbound SPI in A. In the same way, the
value of the SPIb1 MUST NOT be the same value of the SPIb1 <bcp14>MUST NOT</bcp14> be the sa me
as any inbound SPI in B. Then, as any inbound SPI in B. Then,
the I2NSF Controller creates an inbound IPsec SA the I2NSF Controller creates an inbound IPsec SA
with SPIa2 in A and another inbound IPsec SA in B with SPIa2 in A and another inbound IPsec SA in B
with SPIb2. It can send this information with SPIb2. It can send this information
simultaneously to A and B.</t> simultaneously to A and B.</li>
<li> Once the I2NSF Controller receives
<t> Once the I2NSF Controller receives
confirmation from A and B, the controller knows that confirmation from A and B, the controller knows that
the inbound IPsec SAs are correctly installed. Then the inbound IPsec SAs are correctly installed. Then,
it proceeds to send in parallel to A and B, the it proceeds to send, in parallel to A and B, the
outbound IPsec SAs: the outbound IPsec SA outbound IPsec SAs: the outbound IPsec SA
to A with SPIb2, and the outbound IPsec SA to B with to A with SPIb2 and the outbound IPsec SA to B with
SPIa2. At this point the new IPsec SAs are SPIa2. At this point, the new IPsec SAs are
ready.</t> ready.</li>
<li> Once the I2NSF Controller receives
<t> Once the I2NSF Controller receives
confirmation from A and B that the outbound IPsec confirmation from A and B that the outbound IPsec
SAs have been installed, the I2NSF Controller, in SAs have been installed, the I2NSF Controller, in
parallel, deletes the old IPsec SAs from A (inbound parallel, deletes the old IPsec SAs from A (inbound
SPIa1 and outbound SPIb1) and B (outbound SPIa1 and SPIa1 and outbound SPIb1) and B (outbound SPIa1 and
inbound SPIb1).</t> inbound SPIb1).</li>
</list> </ol>
</t> <t>If some of the operations in step 1 fail (e.g.,
<t>If some of the operations in step 1 fail (e.g., the
NSF A reports an error when the I2NSF Controller is NSF A reports an error when the I2NSF Controller is
trying to install a new inbound IPsec SA) the trying to install a new inbound IPsec SA), the
I2NSF Controller MUST perform rollback operations by I2NSF Controller <bcp14>MUST</bcp14> perform rollback operat
ions by
removing any new inbound SA that had been successfully removing any new inbound SA that had been successfully
installed during step 1. installed during step 1.
</t> </t>
<t>If step 1 is successful but some of the operations in <t>If step 1 is successful but some of the operations in
step 2 fail (e.g., the NSF A reports an error when the step 2 fail (e.g., NSF A reports an error when the
I2NSF Controller is trying to install the new I2NSF Controller is trying to install the new
outbound IPsec SA), the I2NSF Controller MUST perform outbound IPsec SA), the I2NSF Controller <bcp14>MUST</bcp14> perform
a rollback operation by deleting any new outbound SA a rollback operation by deleting any new outbound SA
that had been successfully installed during step 2 and that had been successfully installed during step 2 and
by deleting the inbound SAs created in step 1, by deleting the inbound SAs created in step 1,
in that order. in that order.
</t> </t>
<t>If the steps 1 and 2 are successful but the step 3 <t>If the steps 1 and 2 are successful but the step 3
fails, the I2NSF Controller will avoid any rollback of fails, the I2NSF Controller will avoid any rollback of
the operations carried out in step 1 and step 2 since the operations carried out in steps 1 and 2, since
new and valid IPsec SAs were created and are functional. new and valid IPsec SAs were created and are functional.
The I2NSF Controller MAY reattempt to remove the old The I2NSF Controller <bcp14>MAY</bcp14> reattempt to remove the old
inbound and outbound IPsec SAs in NSF A and NSF B several ti mes inbound and outbound IPsec SAs in NSF A and NSF B several ti mes
until it receives a success or it gives up. In the last until it receives a success or it gives up. In the last
case, the old IPsec SAs will be removed when their case, the old IPsec SAs will be removed when their
corresponding hard lifetime is reached. corresponding hard lifetime is reached.
</t> </t>
</section> </section>
<section anchor="appendix-g3" numbered="true" toc="default">
<section anchor="appendix-g3" title="Example of managing NSF sta <name>Example of Managing NSF State Loss in the IKE-less Case</name>
te loss in IKE-less case"> <t> In the IKE-less case, if the I2NSF Controller detects
<t> In the IKE-less case, if the I2NSF Controller detects that an NSF has lost the IPsec state, it could follow the
that a NSF has lost the IPsec state, it could follow the
next steps: next steps:
<list style="numbers"> </t>
<t> The I2NSF Controller SHOULD delete the old <ol spacing="normal" type="1">
<li> The I2NSF Controller <bcp14>SHOULD</bcp14> delete the old
IPsec SAs on the non-failed nodes, established with IPsec SAs on the non-failed nodes, established with
the failed node. This prevents the non-failed nodes the failed node. This prevents the non-failed nodes
from leaking plaintext.</t> from leaking plaintext.</li>
<t>If the affected node restarts, the I2NSF <li>If the affected node restarts, the I2NSF
Controller configures the new inbound IPsec SAs Controller configures the new inbound IPsec SAs
between the affected node and all the nodes it was between the affected node and all the nodes it was
talking to. </t> talking to. </li>
<t> After these inbound IPsec SAs have been <li> After these inbound IPsec SAs have been
established, the I2NSF Controller configures the established, the I2NSF Controller configures the
outbound IPsec SAs in parallel. </t> outbound IPsec SAs in parallel. </li>
</list> </ol>
</t> <t>Steps 2 and 3 can be performed at the same time at
<t>Step 2 and step 3 can be performed at the same time at
the cost of a potential packet loss. If this is not the cost of a potential packet loss. If this is not
critical then it is an optimization since the number of critical, then it is an optimization since the number of
exchanges between I2NSF Controller and NSFs is lower.</t> exchanges between the I2NSF Controller and NSFs is lower.</
t>
</section> </section>
</section>
</section> <section anchor="ack" numbered="false" toc="default">
</back> <name>Acknowledgements</name>
</rfc> <t>
Authors want to thank <contact fullname="Paul Wouters"/>, <contact full
name="Valery
Smyslov"/>,<contact fullname="Sowmini Varadhan"/>, <contact fullname="D
avid Carrel"/>,
<contact fullname="Yoav Nir"/>, <contact fullname="Tero Kivinen"/>,
<contact fullname="Martin Bjorklund"/>, <contact fullname="Graham Bartl
ett"/>,
<contact fullname="Sandeep Kampati"/>, <contact fullname="Linda
Dunbar"/>, <contact fullname="Mohit Sethi"/>, <contact fullname="Martin
Bjorklund"/>,
<contact fullname="Tom Petch"/>, <contact fullname="Christian
Hopps"/>, <contact fullname="Rob Wilton"/>, <contact fullname="Carlos J
. Bernardos"/>,
<contact fullname="Alejandro Perez-Mendez"/>, <contact fullname="Alejand
ro
Abad-Carrascosa"/>, <contact fullname="Ignacio
Martinez"/>, <contact fullname="Ruben Ricart"/>, and all IESG members
that have reviewed this document for their
valuable comments.
</t>
</section>
</back>
</rfc>
 End of changes. 514 change blocks. 
3680 lines changed or deleted 3299 lines changed or added

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