rfc9061.original   rfc9061.txt 
I2NSF R. Marin-Lopez Internet Engineering Task Force (IETF) R. Marin-Lopez
Internet-Draft G. Lopez-Millan Request for Comments: 9061 G. Lopez-Millan
Intended status: Standards Track University of Murcia Category: Standards Track University of Murcia
Expires: September 26, 2021 F. Pereniguez-Garcia ISSN: 2070-1721 F. Pereniguez-Garcia
University Defense Center University Defense Center
March 25, 2021 June 2021
Software-Defined Networking (SDN)-based IPsec Flow Protection A YANG Data Model for IPsec Flow Protection Based on Software-Defined
draft-ietf-i2nsf-sdn-ipsec-flow-protection-14 Networking (SDN)
Abstract Abstract
This document describes how to provide IPsec-based flow protection This document describes how to provide IPsec-based flow protection
(integrity and confidentiality) by means of an Interface to Network (integrity and confidentiality) by means of an Interface to Network
Security Function (I2NSF) controller. It considers two main well- Security Function (I2NSF) Controller. It considers two main well-
known scenarios in IPsec: (i) gateway-to-gateway and (ii) host-to- known scenarios in IPsec: gateway-to-gateway and host-to-host. The
host. The service described in this document allows the service described in this document allows the configuration and
configuration and monitoring of IPsec Security Associations (IPsec monitoring of IPsec Security Associations (IPsec SAs) from an I2NSF
SAs) from a I2NSF Controller to one or several flow-based Network Controller to one or several flow-based Network Security Functions
Security Functions (NSFs) that rely on IPsec to protect data traffic. (NSFs) that rely on IPsec to protect data traffic.
The document focuses on the I2NSF NSF-facing Interface by providing This document focuses on the I2NSF NSF-Facing Interface by providing
YANG data models for configuring the IPsec databases, namely Security YANG data models for configuring the IPsec databases, namely Security
Policy Database (SPD), Security Association Database (SAD), Peer Policy Database (SPD), Security Association Database (SAD), Peer
Authorization Database (PAD), and IKEv2. This allows IPsec SA Authorization Database (PAD), and Internet Key Exchange Version 2
establishment with minimal intervention by the network administrator. (IKEv2). This allows IPsec SA establishment with minimal
It defines three YANG modules but it does not define any new intervention by the network administrator. This document defines
protocol. three YANG modules, but it does not define any new protocol.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on September 26, 2021. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9061.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 2. Terminology
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Requirements Language
4. SDN-based IPsec management description . . . . . . . . . . . 7 3. SDN-Based IPsec Management Description
4.1. IKE case: IKEv2/IPsec in the NSF . . . . . . . . . . . . 7 3.1. IKE Case: IKEv2/IPsec in the NSF
4.2. IKE-less case: IPsec (no IKEv2) in the NSF. . . . . . . . 8 3.2. IKE-less Case: IPsec (No IKEv2) in the NSF
5. IKE case vs IKE-less case . . . . . . . . . . . . . . . . . . 10 4. IKE Case vs. IKE-less Case
5.1. Rekeying process . . . . . . . . . . . . . . . . . . . . 11 4.1. Rekeying Process
5.2. NSF state loss. . . . . . . . . . . . . . . . . . . . . . 11 4.2. NSF State Loss
5.3. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 12 4.3. NAT Traversal
5.4. NSF registration and discovery . . . . . . . . . . . . . 13 4.4. NSF Registration and Discovery
6. YANG configuration data models . . . . . . . . . . . . . . . 13 5. YANG Configuration Data Models
6.1. The 'ietf-i2nsf-ikec' Module . . . . . . . . . . . . . . 13 5.1. The 'ietf-i2nsf-ikec' Module
6.1.1. Data model overview . . . . . . . . . . . . . . . . . 14 5.1.1. Data Model Overview
6.1.2. YANG Module . . . . . . . . . . . . . . . . . . . . . 14 5.1.2. YANG Module
6.2. The 'ietf-i2nsf-ike' Module . . . . . . . . . . . . . . . 28 5.2. The 'ietf-i2nsf-ike' Module
6.2.1. Data model overview . . . . . . . . . . . . . . . . . 29 5.2.1. Data Model Overview
6.2.2. Example Usage . . . . . . . . . . . . . . . . . . . . 33 5.2.2. Example Usage
6.2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . 33 5.2.3. YANG Module
6.3. The 'ietf-i2nsf-ikeless' Module . . . . . . . . . . . . . 53 5.3. The 'ietf-i2nsf-ikeless' Module
6.3.1. Data model overview . . . . . . . . . . . . . . . . . 53 5.3.1. Data Model Overview
6.3.2. Example Usage . . . . . . . . . . . . . . . . . . . . 57 5.3.2. Example Usage
6.3.3. YANG Module . . . . . . . . . . . . . . . . . . . . . 58 5.3.3. YANG Module
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 70 6. IANA Considerations
8. Security Considerations . . . . . . . . . . . . . . . . . . . 71 7. Security Considerations
8.1. IKE case . . . . . . . . . . . . . . . . . . . . . . . . 72 7.1. IKE Case
8.2. IKE-less case . . . . . . . . . . . . . . . . . . . . . . 72 7.2. IKE-less Case
8.3. YANG modules . . . . . . . . . . . . . . . . . . . . . . 73 7.3. YANG Modules
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 74 8. References
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 75 8.1. Normative References
10.1. Normative References . . . . . . . . . . . . . . . . . . 75 8.2. Informative References
10.2. Informative References . . . . . . . . . . . . . . . . . 79 Appendix A. XML Configuration Example for IKE Case
Appendix A. XML configuration example for IKE case (gateway-to- (Gateway-to-Gateway)
gateway) . . . . . . . . . . . . . . . . . . . . . . 81 Appendix B. XML Configuration Example for IKE-less Case
Appendix B. XML configuration example for IKE-less case (host- (Host-to-Host)
to-host) . . . . . . . . . . . . . . . . . . . . . . 84 Appendix C. XML Notification Examples
Appendix C. XML notification examples . . . . . . . . . . . . . 88 Appendix D. Operational Use Case Examples
Appendix D. Operational use cases examples . . . . . . . . . . . 89 D.1. Example of IPsec SA Establishment
D.1. Example of IPsec SA establishment . . . . . . . . . . . . 89 D.1.1. IKE Case
D.1.1. IKE case . . . . . . . . . . . . . . . . . . . . . . 90 D.1.2. IKE-less Case
D.1.2. IKE-less case . . . . . . . . . . . . . . . . . . . . 91 D.2. Example of the Rekeying Process in IKE-less Case
D.2. Example of the rekeying process in IKE-less case . . . . 93 D.3. Example of Managing NSF State Loss in the IKE-less Case
D.3. Example of managing NSF state loss in IKE-less case . . . 94 Acknowledgements
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 94 Authors' Addresses
1. Introduction 1. Introduction
Software-Defined Networking (SDN) is an architecture that enables Software-Defined Networking (SDN) is an architecture that enables
administrators to directly program, orchestrate, control and manage administrators to directly program, orchestrate, control, and manage
network resources through software. The SDN paradigm relocates the network resources through software. The SDN paradigm relocates the
control of network resources to a centralized entity, namely the SDN control of network resources to a centralized entity, namely the SDN
Controller. SDN controllers configure and manage distributed network Controller. SDN Controllers configure and manage distributed network
resources and provide an abstracted view of the network resources to resources and provide an abstracted view of the network resources to
SDN applications. SDN applications can customize and automate the SDN applications. SDN applications can customize and automate the
operations (including management) of the abstracted network resources operations (including management) of the abstracted network resources
in a programmable manner via this interface [RFC7149] [ITU-T.Y.3300] in a programmable manner via this interface [RFC7149] [ITU-T.Y.3300]
[ONF-SDN-Architecture] [ONF-OpenFlow]. [ONF-SDN-Architecture] [ONF-OpenFlow].
Recently, several network scenarios now demand a centralized way of Recently, several network scenarios now demand a centralized way of
managing different security aspects, for example, Software-Defined managing different security aspects, for example, Software-Defined
WANs (SD-WANs). SD-WANs are an SDN extension providing a software WANs (SD-WANs). SD-WANs are SDN extensions providing software
abstraction to create secure network overlays over traditional WAN abstractions to create secure network overlays over traditional WAN
and branch networks. SD-WANs utilize IPsec [RFC4301] as an and branch networks. SD-WANs utilize IPsec [RFC4301] as an
underlying security protocol. The goal of SD-WANs is to provide underlying security protocol. The goal of SD-WANs is to provide
flexible and automated deployment from a centralized point to enable flexible 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. Additionally, Section 4.3.3 in Association (IPsec SA) management. Additionally, Section 4.3.3
[RFC8192] describes another example use case for Cloud Data Center ("Client-Specific Security Policy in Cloud VPNs") of [RFC8192]
Scenario titled "Client-Specific Security Policy in Cloud VPNs". The describes another example use case for a cloud data center scenario.
use case in RFC 8192 states that "dynamic key management is critical The use case in [RFC8192] states that "dynamic key management is
for securing the VPN and the distribution of policies". These VPNs critical for securing the VPN and the distribution of policies".
can be established using IPsec. The management of IPsec SAs in data These VPNs can be established using IPsec. The management of IPsec
centers using a centralized entity is a scenario where the current SAs in data centers using a centralized entity is a scenario where
specification may be applicable. the current specification may be applicable.
Therefore, with the growth of SDN-based scenarios where network Therefore, with the growth of SDN-based scenarios where network
resources are deployed in an autonomous manner, a mechanism to manage resources are deployed in an autonomous manner, a mechanism to manage
IPsec SAs from a centralized entity becomes more relevant in the IPsec SAs from a centralized entity becomes more relevant in the
industry. industry.
In response to this need, the Interface to Network Security Functions In response to this need, the Interface to Network Security Functions
(I2NSF) charter states that the goal of this working group is "to (I2NSF) charter states that the goal of this working group is "to
define set of software interfaces and YANG data models for define a set of software interfaces and data models for controlling
controlling and monitoring aspects of physical and virtual Network and monitoring aspects of physical and virtual NSFs". As defined in
Security Functions". As defined in [RFC8192] an Network Security [RFC8192], a Network Security Function (NSF) is "a function that is
Function (NSF) is "a function that is used to ensure integrity, used to ensure integrity, confidentiality, or availability of network
confidentiality, or availability of network communication; to detect communication; to detect unwanted network activity; or to block, or
unwanted network activity; or to block, or at least mitigate, the at least mitigate, the effects of unwanted activity". This document
effects of unwanted activity". This document pays special attention pays special attention to flow-based NSFs that ensure integrity and
to flow-based NSFs that ensure integrity and confidentiality by means confidentiality by means of IPsec.
of IPsec.
In fact, as Section 3.1.9 in [RFC8192] states "there is a need for a In fact, Section 3.1.9 of [RFC8192] states that "there is a need for
controller to create, manage, and distribute various keys to a controller to create, manage, and distribute various keys to
distributed NSFs.", however "there is a lack of a standard interface distributed NSFs"; however, "there is a lack of a standard interface
to provision and manage security associations". Inspired by the SDN to provision and manage security associations". Inspired by the SDN
paradigm, the I2NSF framework [RFC8329] defines a centralized entity, paradigm, the I2NSF framework [RFC8329] defines a centralized entity,
the I2NSF Controller, which manages one or multiple NSFs through a the I2NSF Controller, which manages one or multiple NSFs through an
I2NSF NSF-Facing Interface. In this document an architecture is I2NSF NSF-Facing Interface. In this document, an architecture is
defined for allowing the I2NSF Controller to carry out the key defined for allowing the I2NSF Controller to carry out the key
management procedures. More specifically, three YANG data models are management procedures. More specifically, three YANG data models are
defined for the I2NSF NSF-Facing Interface that allow the I2NSF defined for the I2NSF NSF-Facing Interface, which allows the I2NSF
Controller to configure and monitor IPsec-enabled flow-based NSFs. Controller to configure and monitor IPsec-enabled, flow-based NSFs.
The IPsec architecture [RFC4301] defines a clear separation between The IPsec architecture [RFC4301] defines a clear separation between
the processing to provide security services to IP packets and the key the processing to provide security services to IP packets and the key
management procedures to establish the IPsec SAs, which allows management procedures to establish the IPsec SAs, which allows
centralizing the key management procedures in the I2NSF Controller. centralizing the key management procedures in the I2NSF Controller.
This document considers two typical scenarios to autonomously manage This document considers two typical scenarios to autonomously manage
IPsec SAs: gateway-to-gateway and host-to-host [RFC6071]. In these IPsec SAs: gateway-to-gateway and host-to-host [RFC6071]. In these
cases, 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 scenario is out of complexity, consideration for the host-to-gateway scenario is out of
scope. The source of this complexity comes from the fact that, in scope. The source of this complexity comes from the fact that, in
this scenario, the host may not be under the control of the I2NSF this scenario, the host may not be under the control of the I2NSF
controller and, therefore, it is not configurable. Nevertheless, the Controller and, therefore, it is not configurable. Nevertheless, the
I2NSF interfaces defined in this document can be considered as a I2NSF interfaces defined in this document can be considered as a
starting point to analyze and provide a solution for the host-to- starting point to analyze and provide a solution for the host-to-
gateway scenario. gateway scenario.
For the definition of the YANG data models for I2NSF NSF-Facing For the definition of the YANG data models for the I2NSF NSF-Facing
Interface, this document considers two general cases, namely: Interface, this document considers two general cases, namely:
1) IKE case. The NSF implements the Internet Key Exchange version 2 1. IKE case. The NSF implements the Internet Key Exchange Version 2
(IKEv2) protocol and the IPsec databases: the Security Policy (IKEv2) protocol and the IPsec databases: the Security Policy
Database (SPD), the Security Association Database (SAD) and the Database (SPD), the Security Association Database (SAD), and the
Peer Authorization Database (PAD). The I2NSF Controller is in Peer Authorization Database (PAD). The I2NSF Controller is in
charge of provisioning the NSF with the required information in charge of provisioning the NSF with the required information in
the SPD and PAD (e.g., IKE credentials), and for the IKE protocol the SPD and PAD (e.g., IKE credentials) and the IKE protocol
itself (e.g., parameters for the IKE_SA_INIT negotiation). itself (e.g., parameters for the IKE_SA_INIT negotiation).
2) IKE-less case. The NSF only implements the IPsec databases (no 2. IKE-less case. The NSF only implements the IPsec databases (no
IKE implementation). The I2NSF Controller will provide the IKE implementation). The I2NSF Controller will provide the
required parameters to create valid entries in the SPD and the required parameters to create valid entries in the SPD and the
SAD of the NSF. Therefore, the NSF will only have support for SAD of the NSF. Therefore, the NSF will only have support for
IPsec while key management functionality is moved to the I2NSF IPsec whereas key management functionality is moved to the I2NSF
Controller. Controller.
In both cases, a YANG data model for the I2NSF NSF-Facing Interface In both cases, a YANG data model for the I2NSF NSF-Facing Interface
is required to carry out this provisioning in a secure manner between is required to carry out this provisioning in a secure manner between
the I2NSF Controller and the NSF. Using YANG data modelling language the I2NSF Controller and the NSF. Using YANG data modeling language
version 1.1 [RFC7950] and based on YANG data models defined in version 1.1 [RFC7950] and based on YANG data models defined in
[netconf-vpn], [I-D.tran-ipsecme-yang], an the data structures [netconf-vpn] and [TRAN-IPSECME-YANG] and the data structures defined
defined in RFC 4301 [RFC4301] and RFC 7296 [RFC7296], this document in [RFC4301] and [RFC7296], this document defines the required
defines the required interfaces with a YANG data model for interfaces with a YANG data model for configuration and state data
configuration and state data for IKE, PAD, SPD and SAD (see for IKE, PAD, SPD, and SAD (see Sections 5.1, 5.2, and 5.3). The
Section 6.1, Section 6.2 and Section 6.3). The proposed YANG data proposed YANG data model conforms to the Network Management Datastore
model conforms to the Network Management Datastore Architecture Architecture (NMDA) defined in [RFC8342]. Examples of the usage of
(NMDA) defined in [RFC8342]. Examples of the usage of these data these data models can be found in Appendices A, B, and C.
models can be found in Appendix A, Appendix B and Appendix C.
In summary, the objectives of this document are: In summary, the objectives of this document are:
o To describe the architecture for I2NSF-based IPsec management, * To describe the architecture for I2NSF-based IPsec management,
which allows the establishment and management of IPsec security which allows for the establishment and management of IPsec
associations from the I2NSF Controller in order to protect Security Associations from the I2NSF Controller in order to
specific data flows between two flow-based NSFs implementing protect specific data flows between two flow-based NSFs
IPsec. implementing IPsec.
o To map this architecture to the I2NSF Framework. * To map this architecture to the I2NSF framework.
o To define the interfaces required to manage and monitor the IPsec * To define the interfaces required to manage and monitor the IPsec
SAs in the NSF from a I2NSF Controller. YANG data models are SAs in the NSF from an I2NSF Controller. YANG data models are
defined for configuration and state data for IPsec and IKEv2 defined for configuration and state data for IPsec and IKEv2
management through the I2NSF NSF-Facing Interface. The YANG management through the I2NSF NSF-Facing Interface. The YANG data
models can be used via existing protocols such as NETCONF models can be used via existing protocols, such as the Network
[RFC6241] or RESTCONF [RFC8040]. Thus, this document defines Configuration Protocol (NETCONF) [RFC6241] or RESTCONF [RFC8040].
three YANG modules (see Section 6) but does not define any new Thus, this document defines three YANG modules (see Section 5) but
protocol. does not define any new protocol.
2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 2. Terminology
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Terminology This document uses the terminology described in [ITU-T.Y.3300],
[RFC8192], [RFC4301], [RFC6437], [RFC7296], [RFC6241], and [RFC8329].
This document uses the terminology described in [RFC8329], [RFC8192], The following term is defined in [ITU-T.Y.3300]:
[RFC4301],[RFC7296], [RFC6241], [ITU-T.Y.3300]. The following term
is defined in [ITU-T.Y.3300]:
o Software-Defined Networking. * Software-Defined Networking (SDN)
The following terms are defined in [RFC8192]: The following terms are defined in [RFC8192]:
o NSF. * Network Security Function (NSF)
o Flow-based NSF. * flow-based NSF
The following terms are defined in [RFC4301]: The following terms are defined in [RFC4301]:
o Peer Authorization Database (PAD). * Peer Authorization Database (PAD)
o Security Associations Database (SAD). * Security Association Database (SAD)
o Security Policy Database (SPD). * Security Policy Database (SPD)
The following two terms that are related or have identical The following two terms are related or have identical definition/
definition/usage in [RFC6437]: usage in [RFC6437]:
o Flow or traffic flow. * flow
* traffic flow
The following term is defined in [RFC7296]: The following term is defined in [RFC7296]:
o Internet Key Exchange version 2 (IKEv2). * Internet Key Exchange Version 2 (IKEv2)
The following terms are defined in [RFC6241]: The following terms are defined in [RFC6241]:
o Configuration data. * configuration data
o Configuration datastore. * configuration datastore
o State data. * state data
o Startup configuration datastore. * startup configuration datastore
o Running configuration datastore. * running configuration datastore
4. SDN-based IPsec management description 2.1. Requirements Language
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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. SDN-Based IPsec Management Description
As mentioned in Section 1, two cases are considered, depending on As mentioned in Section 1, two cases are considered, depending on
whether the NSF implements IKEv2 or not: the IKE case and the IKE- whether the NSF implements IKEv2 or not: the IKE case and the IKE-
less case. less case.
4.1. IKE case: IKEv2/IPsec in the NSF 3.1. IKE Case: IKEv2/IPsec in the NSF
In this case, the NSF implements IPsec with IKEv2 support. The I2NSF In this case, the NSF implements IPsec with IKEv2 support. The I2NSF
Controller is in charge of managing and applying IPsec connection Controller is in charge of managing and applying IPsec connection
information (determining which nodes need to start an IKEv2/IPsec information (determining which nodes need to start an IKEv2/IPsec
session, identifying the type of traffic to be protected, deriving session, identifying the type of traffic to be protected, and
and delivering IKEv2 credentials such as a pre-shared key, deriving and delivering IKEv2 credentials, such as a pre-shared key
certificates, etc.), and applying other IKEv2 configuration (PSK), certificates, etc.) and applying other IKEv2 configuration
parameters (e.g., cryptographic algorithms for establishing an IKEv2 parameters (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.
With these entries, the IKEv2 implementation can operate to establish With these entries, the IKEv2 implementation can operate to establish
the IPsec SAs. The I2NSF User establishes the IPsec requirements and the IPsec SAs. The I2NSF User establishes the IPsec requirements and
information about the end points (through the I2NSF Consumer-Facing information about the endpoints (through the I2NSF Consumer-Facing
Interface, [RFC8329]), and the I2NSF Controller translates these Interface [RFC8329]), and the I2NSF Controller translates these
requirements into IKEv2, SPD and PAD entries that will be installed requirements into IKEv2, SPD, and PAD entries that will be installed
into the NSF (through the I2NSF NSF-Facing Interface). With that into the NSF (through the I2NSF NSF-Facing Interface). With that
information, the NSF can just run IKEv2 to establish the required information, the NSF can just run IKEv2 to establish the required
IPsec SA (when the traffic flow needs protection). Figure 1 shows IPsec SA (when the traffic flow needs protection). Figure 1 shows
the different layers and corresponding functionality. the different layers and corresponding functionality.
+-------------------------------------------+ +-------------------------------------------+
| IPsec Management System | I2NSF User | IPsec Management System | I2NSF User
+-------------------------------------------+ +-------------------------------------------+
| |
| I2NSF Consumer-Facing | I2NSF Consumer-Facing
skipping to change at page 8, line 24 skipping to change at line 329
+-------------------------------------------+ +-------------------------------------------+
| |
| 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
+-------------------------------------------+ +-------------------------------------------+
Figure 1: IKE case: IKE/IPsec in the NSF Figure 1: IKE Case: IKE/IPsec in the NSF
I2NSF-based IPsec flow protection services provide dynamic and I2NSF-based IPsec flow protection services provide dynamic and
flexible management of IPsec SAs in flow-based NSFs. In order to flexible management of IPsec SAs in flow-based NSFs. In order to
support this capability in the IKE case, a YANG data model for IKEv2, support this capability in the IKE case, a YANG data model for IKEv2,
SPD and PAD configuration data, and for IKEv2 state data needs to be SPD, and PAD configuration data and for IKEv2 state data needs to be
defined for the I2NSF NSF-Facing Interface (see Section 6). defined for the I2NSF NSF-Facing Interface (see Section 5).
4.2. IKE-less case: IPsec (no IKEv2) in the NSF. 3.2. IKE-less Case: IPsec (No IKEv2) in the NSF
In this case, the NSF does not deploy IKEv2 and, therefore, the I2NSF In this case, the NSF does not deploy IKEv2 and, therefore, the I2NSF
Controller has to perform the IKEv2 security functions and management Controller has to perform the IKEv2 security functions and management
of IPsec SAs by populating and managing the SPD and the SAD. of IPsec SAs by populating and managing the SPD and the SAD.
As shown in Figure 2, when an I2NSF User enforces flow-based As shown in Figure 2, when an I2NSF User enforces flow-based
protection policies through the Consumer-Facing Interface, the I2NSF protection policies through the Consumer-Facing Interface, the I2NSF
Controller translates these requirements into SPD and SAD entries, Controller translates these requirements into SPD and SAD entries,
which are installed in the NSF. PAD entries are not required since which are installed in the NSF. PAD entries are not required, since
there is no IKEv2 in the NSF. there is no IKEv2 in the NSF.
+-----------------------------------------+ +-----------------------------------------+
| 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
skipping to change at page 9, line 24 skipping to change at line 368
+-----------------------------------------+ +-----------------------------------------+
| |
| 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
+-----------------------------------------+ +-----------------------------------------+
Figure 2: IKE-less case: IPsec (no IKEv2) in the NSF Figure 2: IKE-less Case: IPsec (No IKEv2) in the NSF
In order to support the IKE-less case, a YANG data model for SPD and In order to support the IKE-less case, a YANG data model for SPD and
SAD configuration data and SAD state data MUST be defined for the SAD configuration data and SAD state data MUST be defined for the
NSF-Facing Interface (see Section 6). NSF-Facing Interface (see Section 5).
Specifically, the IKE-less case assumes that the I2NSF Controller has Specifically, the IKE-less case assumes that the I2NSF Controller has
to perform some security functions that IKEv2 typically does, namely to perform some security functions that IKEv2 typically does, namely
(non-exhaustive): (non-exhaustive list):
o IV generation. * Initialization Vector (IV) generation
o Prevent counter resets for the same key. * prevention of counter resets for the same key
o Generation of pseudo-random cryptographic keys for the IPsec SAs. * generation of pseudorandom cryptographic keys for the IPsec SAs
o Generation of the IPsec SAs when required based on notifications * generation of the IPsec SAs when required based on notifications
(i.e. sadb-acquire) from the NSF. (i.e., sadb-acquire) from the NSF
o Rekey of the IPsec SAs based on notifications from the NSF (i.e. * rekey of the IPsec SAs based on notifications from the NSF (i.e.,
expire). expire)
o NAT Traversal discovery and management. * NAT traversal discovery and management
Additionally to these functions, another set of tasks must be Additionally to these functions, another set of tasks must be
performed by the I2NSF Controller (non-exhaustive list): performed by the I2NSF Controller (non-exhaustive list):
o IPsec SA's SPI random generation. * IPsec SA's Security Parameter Index (SPI) random generation
o Cryptographic algorithm selection. * cryptographic algorithm selection
o Usage of extended sequence numbers. * usage of extended sequence numbers
o Establishment of proper traffic selectors. * establishment of proper Traffic Selectors
5. IKE case vs IKE-less case 4. IKE Case vs. IKE-less Case
In principle, the IKE case is easier to deploy than the IKE-less case In principle, the IKE case is easier to deploy than the IKE-less case
because current flow-based NSFs (either hosts or gateways) have because current flow-based NSFs (either hosts or gateways) have
access to IKEv2 implementations. While gateways typically deploy an access to IKEv2 implementations. While gateways typically deploy an
IKEv2/IPsec implementation, hosts can easily install it. As a IKEv2/IPsec implementation, hosts can easily install it. As a
downside, the NSF needs more resources to use IKEv2 such as memory downside, the NSF needs more resources to use IKEv2, such as memory
for the IKEv2 implementation, and computation, since each IPsec for the IKEv2 implementation and computation, since each IPsec
security association rekeying MAY involve a Diffie-Hellman exchange. Security Association rekeying MAY involve a Diffie-Hellman (DH)
exchange.
Alternatively, the IKE-less case benefits the deployment in resource- Alternatively, the IKE-less case benefits the deployment in resource-
constrained NSFs. Moreover, IKEv2 does not need to be performed in constrained NSFs. Moreover, IKEv2 does not need to be performed in
gateway-to-gateway and host-to-host scenarios under the same I2NSF gateway-to-gateway and host-to-host scenarios under the same I2NSF
Controller (see Appendix D.1). On the contrary, the complexity of Controller (see Appendix D.1). On the contrary, the complexity of
creating and managing IPsec SAs is shifted to the I2NSF Controller creating and managing IPsec SAs is shifted to the I2NSF Controller
since IKEv2 is not in the NSF. As a consequence, this may result in since IKEv2 is not in the NSF. As a consequence, this may result in
a more complex implementation in the controller side in comparison a more complex implementation in the controller side in comparison
with IKE case. For example, the I2NSF Controller has to deal with with the IKE case. For example, the I2NSF Controller has to deal
the latency existing in the path between the I2NSF Controller and the with the latency existing in the path between the I2NSF Controller
NSF, in order to solve tasks such as rekey, or creation and and the NSF (in order to solve tasks, such as rekey) or creation and
installation of new IPsec SAs. However, this is not specific to this installation of new IPsec SAs. However, this is not specific to this
contribution but a general aspect in any SDN-based network. In contribution but a general aspect in any SDN-based network. In
summary, this complexity may create some scalability and performance summary, this complexity may create some scalability and performance
issues when the number of NSFs is high. issues when the number of NSFs is high.
Nevertheless, literature around SDN-based network management using a Nevertheless, literature around SDN-based network management using a
centralized controller (like the I2NSF Controller) is aware of centralized controller (like the I2NSF Controller) is aware of
scalability and performance issues and solutions have been already scalability and performance issues, and solutions have been already
provided and discussed (e.g., hierarchical controllers, having provided and discussed (e.g., hierarchical controllers, having
multiple replicated controllers, dedicated high-speed management multiple replicated controllers, dedicated high-speed management
networks, etc). In the context of I2SNF-based IPsec management, one networks, etc.). In the context of I2NSF-based IPsec management, one
way to reduce the latency and alleviate some performance issues can way to reduce the latency and alleviate some performance issues can
be the installation of the IPsec policies and IPsec SAs at the same be to install the IPsec policies and IPsec SAs at the same time
time (proactive mode, as described in Appendix D.1) instead of (proactive mode, as described in Appendix D.1) instead of waiting for
waiting for notifications (e.g., a sadb-acquire notification received notifications (e.g., a sadb-acquire notification received from an NSF
from a NSF requiring a new IPsec SA) to proceed with the IPsec SA requiring a new IPsec SA) to proceed with the IPsec SA installation
installation (reactive mode). Another way to reduce the overhead and (reactive mode). Another way to reduce the overhead and the
the potential scalability and performance issues in the I2NSF potential scalability and performance issues in the I2NSF Controller
Controller is to apply the IKE case described in this document, since is to apply the IKE case described in this document since the IPsec
the IPsec SAs are managed between NSFs without the involvement of the SAs are managed between NSFs without the involvement of the I2NSF
I2NSF Controller at all, except by the initial configuration (i.e. Controller at all, except by the initial configuration (i.e., IKEv2,
IKEv2, PAD and SPD entries) provided by the I2NSF Controller. Other PAD, and SPD entries) provided by the I2NSF Controller. Other
solutions, such as Controller-IKE solutions, such as Controller-IKE [IPSECME-CONTROLLER-IKE], have
[I-D.carrel-ipsecme-controller-ike], have proposed that NSFs provide proposed that NSFs provide their DH public keys to the I2NSF
their DH public keys to the I2NSF Controller, so that the I2NSF Controller so that the I2NSF Controller distributes all public keys
Controller distributes all public keys to all peers. All peers can to all peers. All peers can calculate a unique pairwise secret for
calculate a unique pairwise secret for each other peer and there is each other peer, and there is no inter-NSF messages. A rekey
no inter-NSF messages. A rekey mechanism is further described in mechanism is further described in [IPSECME-CONTROLLER-IKE].
[I-D.carrel-ipsecme-controller-ike].
In terms of security, IKE case provides better security properties In terms of security, the IKE case provides better security
than IKE-less case, as discussed in Section 8. The main reason is properties than the IKE-less case, as discussed in Section 7. The
that the NSFs generate the session keys and not the I2NSF Controller. main reason is that the NSFs generate the session keys and not the
I2NSF Controller.
5.1. Rekeying process 4.1. Rekeying Process
Performing a rekey for IPsec SAs is an important operation during the Performing a rekey for IPsec SAs is an important operation during the
IPsec SAs management. With the YANG data models defined in this IPsec SAs management. With the YANG data models defined in this
document the I2NSF Controller can configure parameters of the rekey document the I2NSF Controller can configure parameters of the rekey
process (IKE case) or conduct the rekey process (IKE-less case). process (IKE case) or conduct the rekey process (IKE-less case).
Indeed, depending on the case, the rekey process is different. Indeed, depending on the case, the rekey process is different.
For the IKE case, the rekeying process is carried out by IKEv2, For the IKE case, the rekeying process is carried out by IKEv2,
following the information defined in the SPD and SAD (i.e. based on following the information defined in the SPD and SAD (i.e., based on
the IPsec SA lifetime established by the I2NSF Controller using the the IPsec SA lifetime established by the I2NSF Controller using the
YANG data model defined in this document). Therefore, IPsec YANG data model defined in this document). Therefore, IPsec
connections will live unless something different is required by the connections will live unless something different is required by the
I2NSF User or the I2NSF Controller detects something wrong. I2NSF User or the I2NSF Controller detects something wrong.
For the IKE-less case, the I2NSF Controller MUST take care of the For the IKE-less case, the I2NSF Controller MUST take care of the
rekeying process. When the IPsec SA is going to expire (e.g., IPsec rekeying process. When the IPsec SA is going to expire (e.g., IPsec
SA soft lifetime), it MUST create a new IPsec SA and it MAY remove SA soft lifetime), it MUST create a new IPsec SA and it MAY remove
the old one (e.g. when the lifetime of the old IPsec SA has not been the old one (e.g., when the lifetime of the old IPsec SA has not been
defined). This rekeying process starts when the I2NSF Controller defined). This rekeying process starts when the I2NSF Controller
receives a sadb-expire notification or, on the I2NSF Controller's receives a sadb-expire notification or, on the I2NSF Controller's
initiative, based on lifetime state data obtained from the NSF. How initiative, based on lifetime state data obtained from the NSF. How
the I2NSF Controller implements an algorithm for the rekey process is the I2NSF Controller implements an algorithm for the rekey process is
out of the scope of this document. Nevertheless, an example of how out of the scope of this document. Nevertheless, an example of how
this rekey could be performed is described in Appendix D.2. this rekey could be performed is described in Appendix D.2.
5.2. NSF state loss. 4.2. NSF State Loss
If one of the NSF restarts, it will lose the IPsec state (affected If one of the NSF restarts, it will lose the IPsec state (affected
NSF). By default, the I2NSF Controller can assume that all the state NSF). By default, the I2NSF Controller can assume that all the state
has been lost and therefore it will have to send IKEv2, SPD and PAD has been lost and, therefore, it will have to send IKEv2, SPD, and
information to the NSF in the IKE case, and SPD and SAD information PAD information to the NSF in the IKE case and SPD and SAD
in the IKE-less case. information in the IKE-less case.
In both cases, the I2NSF Controller is aware of the affected NSF In both cases, the I2NSF Controller is aware of the affected NSF
(e.g., the NETCONF/TCP connection is broken with the affected NSF, (e.g., the NETCONF/TCP connection is broken with the affected NSF,
the I2NSF Controller is receiving sadb-bad-spi notification from a the I2NSF Controller is receiving a sadb-bad-spi notification from a
particular NSF, etc.). Moreover, the I2NSF Controller keeps a list particular NSF, etc.). Moreover, the I2NSF Controller keeps a list
of NSFs that have IPsec SAs with the affected NSF. Therefore, it of NSFs that have IPsec SAs with the affected NSF. Therefore, it
knows the affected IPsec SAs. knows the affected IPsec SAs.
In the IKE case, the I2NSF Controller may need to configure the In the IKE case, the I2NSF Controller may need to configure the
affected NSF with the new IKEv2, SPD and PAD information. affected NSF with the new IKEv2, SPD, and PAD information.
Alternatively, IKEv2 configuration MAY be made permanent between NSF Alternatively, IKEv2 configuration MAY be made permanent between NSF
reboots without compromising security by means of the startup reboots without compromising security by means of the startup
configuration datastore in the NSF. This way, each time a NSF configuration datastore in the NSF. This way, each time an NSF
reboots it will use that configuration for each rebooting. It would reboots, it will use that configuration for each rebooting. It would
imply avoiding contact with the I2NSF Controller. Finally, the I2NSF imply avoiding contact with the I2NSF Controller. Finally, the I2NSF
Controller may also need to send new parameters (e.g., a new fresh Controller may also need to send new parameters (e.g., a new fresh
PSK for authentication) to the NSFs which had IKEv2 SAs and IPsec SAs PSK for authentication) to the NSFs that had IKEv2 SAs and IPsec SAs
with the affected NSF. with the affected NSF.
In the IKE-less case, the I2NSF Controller SHOULD delete the old In the IKE-less case, the I2NSF Controller SHOULD delete the old
IPsec SAs in the non-failed nodes established with the affected NSF. IPsec SAs in the non-failed nodes established with the affected NSF.
Once the affected node restarts, the I2NSF Controller MUST take the Once the affected node restarts, the I2NSF Controller MUST take the
necessary actions to reestablish IPsec protected communication necessary actions to reestablish IPsec-protected communication
between the failed node and those others having IPsec SAs with the between the failed node and those others having IPsec SAs with the
affected NSF. How the I2NSF Controller implements an algorithm for affected NSF. How the I2NSF Controller implements an algorithm for
managing a potential NSF state loss is out of the scope of this managing a potential NSF state loss is out of the scope of this
document. Nevertheless, an example of how this could be performed is document. Nevertheless, an example of how this could be performed is
described in Appendix D.3. described in Appendix D.3.
5.3. NAT Traversal 4.3. NAT Traversal
In the IKE case, IKEv2 already provides a mechanism to detect whether In the IKE case, IKEv2 already provides a mechanism to detect whether
some of the peers or both are located behind a NAT. In this case, some of the peers or both are located behind a NAT. In this case,
UDP or TCP encapsulation for ESP packets ([RFC3948], [RFC8229]) is UDP or TCP encapsulation for Encapsulating Security Payload (ESP)
required. Note that IPsec transport mode MUST NOT be used in this packets [RFC3948] [RFC8229] is required. Note that IPsec transport
specification when NAT is required. mode MUST NOT be used in this specification when NAT is required.
In the IKE-less case, the NSF does not have the assistance of the In the IKE-less case, the NSF does not have the assistance of the
IKEv2 implementation to detect if it is located behind a NAT. If the IKEv2 implementation to detect if it is located behind a NAT. If the
NSF does not have any other mechanism to detect this situation, the NSF does not have any other mechanism to detect this situation, the
I2NSF Controller SHOULD implement a mechanism to detect that case. I2NSF Controller SHOULD implement a mechanism to detect that case.
The SDN paradigm generally assumes the I2NSF Controller has a view of The SDN paradigm generally assumes the I2NSF Controller has a view of
the network under its control. This view is built either by the network under its control. This view is built either by
requesting information from the NSFs under its control, or by requesting information from the NSFs under its control or information
information pushed from the NSFs to the I2NSF Controller. Based on pushed from the NSFs to the I2NSF Controller. Based on this
this information, the I2NSF Controller MAY guess if there is a NAT information, the I2NSF Controller MAY guess if there is a NAT
configured between two hosts, and apply the required policies to both configured between two hosts and apply the required policies to both
NSFs besides activating the usage of UDP or TCP encapsulation of ESP NSFs besides activating the usage of UDP or TCP encapsulation of ESP
packets ([RFC3948], [RFC8229]). The interface for discovering if the packets [RFC3948] [RFC8229]. The interface for discovering if the
NSF is behind a NAT is out of scope of this document. NSF is behind a NAT is out of scope of this document.
If the I2NSF Controller does not have any mechanism to know whether a If the I2NSF Controller does not have any mechanism to know whether a
host is behind a NAT or not, then the IKE-case MUST be used and not host is behind a NAT or not, then the IKE case MUST be used and not
the IKE-less case. the IKE-less case.
5.4. NSF registration and discovery 4.4. NSF Registration and Discovery
NSF registration refers to the process of providing the I2NSF NSF registration refers to the process of providing the I2NSF
Controller information about a valid NSF such as certificate, IP Controller information about a valid NSF, such as certificate, IP
address, etc. This information is incorporated in a list of NSFs address, etc. This information is incorporated in a list of NSFs
under its control. under its control.
The assumption in this document is that, for both cases, before a NSF The assumption in this document is that, for both cases, before an
can operate in this system, it MUST be registered in the I2NSF NSF can operate in this system, it MUST be registered in the I2NSF
Controller. In this way, when the NSF starts and establishes a Controller. In this way, when the NSF starts and establishes a
connection to the I2NSF Controller, it knows that the NSF is valid connection to the I2NSF Controller, it knows that the NSF is valid
for joining the system. for joining the system.
Either during this registration process or when the NSF connects with Either during this registration process or when the NSF connects with
the I2NSF Controller, the I2NSF Controller MUST discover certain the I2NSF Controller, the I2NSF Controller MUST discover certain
capabilities of this NSF, such as what are the cryptographic suites capabilities of this NSF, such as what are the cryptographic suites
supported, authentication method, the support of the IKE case and/or supported, the authentication method, the support of the IKE case
the IKE-less case, etc. and/or the IKE-less case, etc.
The registration and discovery processes are out of the scope of this The registration and discovery processes are out of the scope of this
document. document.
6. YANG configuration data models 5. YANG Configuration Data Models
In order to support the IKE and IKE-less cases, models are provided In order to support the IKE and IKE-less cases, models are provided
for the different parameters and values that must be configured to for the different parameters and values that must be configured to
manage IPsec SAs. Specifically, the IKE case requires modeling IKEv2 manage IPsec SAs. Specifically, the IKE case requires modeling IKEv2
configuration parameters, SPD and PAD, while the IKE-less case configuration parameters, SPD and PAD, while the IKE-less case
requires configuration YANG data models for the SPD and SAD. Three requires configuration YANG data models for the SPD and SAD. Three
modules have been defined: ietf-i2nsf-ikec (Section 6.1, common to modules have been defined: ietf-i2nsf-ikec (Section 5.1, common to
both cases), ietf-i2nsf-ike (Section 6.2, IKE case), ietf-i2nsf- both cases), ietf-i2nsf-ike (Section 5.2, IKE case), and ietf-i2nsf-
ikeless (Section 6.3, IKE-less case). Since the module ietf-i2nsf- ikeless (Section 5.3, IKE-less case). Since the module ietf-i2nsf-
ikec has only typedef and groupings common to the other modules, a ikec has only typedef and groupings common to the other modules, a
simplified view of the ietf-i2nsf-ike and ietf-i2nsf-ikeless modules simplified view of the ietf-i2nsf-ike and ietf-i2nsf-ikeless modules
is shown. is shown.
6.1. The 'ietf-i2nsf-ikec' Module 5.1. The 'ietf-i2nsf-ikec' Module
6.1.1. Data model overview
The module ietf-i2nsf-ikec has only definition of data types
(typedef) and groupings which are common to the other modules.
6.1.2. YANG Module 5.1.1. Data Model Overview
This module has normative references to [RFC3947], [RFC4301], The module ietf-i2nsf-ikec only has definitions of data types
[RFC4303], [RFC8174], [RFC8221], [RFC3948], [RFC8229], (typedef) and groupings that are common to the other modules.
[IANA-Protocols-Number], [IKEv2-Parameters], [IKEv2-Transform-Type-1]
and [IKEv2-Transform-Type-3].
<CODE BEGINS> file "ietf-i2nsf-ikec@2021-03-18.yang" 5.1.2. YANG Module
module ietf-i2nsf-ikec { This module has normative references to [RFC3947], [RFC4301],
yang-version 1.1; [RFC4303], [RFC8174], [RFC8221], [RFC3948], [RFC8229], [RFC6991],
namespace "urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikec"; [IANA-Protocols-Number], [IKEv2-Parameters],
prefix "nsfikec"; [IKEv2-Transform-Type-1], and [IKEv2-Transform-Type-3].
import ietf-inet-types { <CODE BEGINS> file "ietf-i2nsf-ikec@2021-06-09.yang"
prefix inet; module ietf-i2nsf-ikec {
reference "RFC 6991: Common YANG Data Types"; yang-version 1.1;
} namespace "urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikec";
prefix nsfikec;
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 { }
type union {
type uint8; typedef ipsec-inner-protocol {
type enumeration { type union {
enum any { type uint8;
value 256; type enumeration {
description enum any {
"Any IP protocol number value."; value 256;
} description
} "Any IP protocol number value.";
} }
default any; }
description }
"IPsec protection can be applied to specific IP default "any";
traffic and layer 4 traffic (TCP, UDP, SCTP, etc.) description
or ANY protocol in the IP packet payload. We "IPsec protection can be applied to specific IP
The IP protocol number is specified with an uint8 traffic and Layer 4 traffic (TCP, UDP, SCTP, etc.)
or ANY protocol in the IP packet payload.
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> }
<CODE ENDS>
6.2. The 'ietf-i2nsf-ike' Module 5.2. The 'ietf-i2nsf-ike' Module
In this section, the YANG module for the IKE case is described. In this section, the YANG module for the IKE case is described.
6.2.1. Data model overview 5.2.1. Data Model Overview
The model related to IKEv2 has been extracted from reading IKEv2 The model related to IKEv2 has been extracted from reading the IKEv2
standard in [RFC7296], and observing some open source standard in [RFC7296] and observing some open source implementations,
implementations, such as Strongswan [strongswan] or Libreswan such as strongSwan [strongswan] or Libreswan [libreswan].
[libreswan].
The definition of the PAD model has been extracted from the The definition of the PAD model has been extracted from the
specification in section 4.4.3 in [RFC4301] (NOTE: Many specification in Section 4.4.3 of [RFC4301]. (Note that many
implementations integrate PAD configuration as part of the IKEv2 implementations integrate PAD configuration as part of the IKEv2
configuration). configuration.)
The definition of the SPD model has been mainly extracted from the The definition of the SPD model has been mainly extracted from the
specification in section 4.4.1 and Appendix D in [RFC4301]. specification in Section 4.4.1 and Appendix D of [RFC4301].
The YANG data model for the IKE case is defined by the module "ietf- The YANG data model for the IKE case is defined by the module "ietf-
i2nsf-ike". Its structure is depicted in the following diagram, i2nsf-ike". Its structure is depicted in the following diagram,
using the notation syntax for YANG tree diagrams ([RFC8340]). using the notation syntax for YANG tree diagrams [RFC8340].
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)
skipping to change at page 30, line 23 skipping to change at line 1383
| +--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 page 31, line 22 skipping to change at line 1430
| | | +--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 page 32, line 28 skipping to change at line 1484
+--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
The YANG data model consists of a unique "ipsec-ike" container The YANG data model consists of a unique "ipsec-ike" container
defined as follows. Firstly, it contains a "pad" container that defined as follows. Firstly, it contains a "pad" container that
serves to configure the Peer Authentication Database with serves to configure the Peer Authentication Database with
authentication information about local and remote peers (NSFs). More authentication information about local and remote peers (NSFs). More
precisely, it consists of a list of entries, each one indicating the precisely, it consists of a list of entries, each one indicating the
identity, authentication method and credentials that a particular identity, authentication method, and credentials that a particular
peer (local or remote) will use. Therefore, each entry contains peer (local or remote) will use. Therefore, each entry contains
identity, authentication information, and credentials of either the identity, authentication information, and credentials of either the
local NSF or the remote NSF. As a consequence, the I2NF Controller local NSF or the remote NSF. As a consequence, the I2NF Controller
can store identity, authentication information and credentials for can store identity, authentication information, and credentials for
the local NSF and the remote NSF. the local NSF and the remote NSF.
Next, a list "conn-entry" is defined with information about the Next, a list "conn-entry" is defined with information about the
different IKE connections a peer can maintain with others. Each different IKE connections a peer can maintain with others. Each
connection entry is composed of a wide number of parameters to connection entry is composed of a wide number of parameters to
configure different aspects of a particular IKE connection between configure different aspects of a particular IKE connection between
two peers: local and remote peer authentication information; IKE SA two peers: local and remote peer authentication information, IKE SA
configuration (soft and hard lifetimes, cryptographic algorithms, configuration (soft and hard lifetimes, cryptographic algorithms,
etc.); list of IPsec policies describing the type of network traffic etc.), a list of IPsec policies describing the type of network
to be secured (local/remote subnet and ports, etc.) and how must be traffic to be secured (local/remote subnet and ports, etc.) and how
protected (ESP, tunnel/transport, cryptographic algorithms, etc.); it must be protected (ESP, tunnel/transport, cryptographic
CHILD SA configuration (soft and hard lifetimes); and, state algorithms, etc.), Child SA configuration (soft and hard lifetimes),
information of the IKE connection (SPIs, usage of NAT, current and state information of the IKE connection (SPIs, usage of NAT,
expiration times, etc.). current expiration times, etc.).
Lastly, the "ipsec-ike" container declares a "number-ike-sas" Lastly, the "ipsec-ike" container declares a "number-ike-sas"
container to specify state information reported by the IKE software container to specify state information reported by the IKE software
related to the amount of IKE connections established. related to the amount of IKE connections established.
6.2.2. Example Usage 5.2.2. Example Usage
Appendix A shows an example of IKE case configuration for a NSF, in Appendix A shows an example of IKE case configuration for an NSF, in
tunnel mode (gateway-to-gateway), with NSFs authentication based on tunnel mode (gateway-to-gateway), with NSF authentication based on
X.509 certificates. X.509 certificates.
6.2.3. YANG Module 5.2.3. YANG Module
This YANG module has normative references to [RFC2247], [RFC5280],
[RFC4301], [RFC5280], [RFC5915], [RFC6991], [RFC7296], [RFC7383],
[RFC7427], [RFC7619], [RFC8017], [ITU-T.X.690], [RFC5322], [RFC8229],
[RFC8174], [IKEv2-Auth-Method], [IKEv2-Transform-Type-4],
[IKEv2-Parameters] and [IANA-Method-Type].
<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 { This YANG module has normative references to [RFC5280], [RFC4301],
prefix yang; [RFC5915], [RFC6991], [RFC7296], [RFC7383], [RFC7427], [RFC7619],
reference "RFC 6991: Common YANG Data Types"; [RFC8017], [ITU-T.X.690], [RFC5322], [RFC8229], [RFC8174], [RFC6960],
} [IKEv2-Auth-Method], [IKEv2-Transform-Type-4], [IKEv2-Parameters],
and [IANA-Method-Type].
import ietf-i2nsf-ikec { <CODE BEGINS> file "ietf-i2nsf-ike@2021-06-09.yang"
prefix nsfikec; module ietf-i2nsf-ike {
reference yang-version 1.1;
"RFC XXXX: Software-Defined Networking namespace "urn:ietf:params:xml:ns:yang:ietf-i2nsf-ike";
(SDN)-based IPsec Flow Protection."; prefix nsfike;
}
import ietf-netconf-acm { import ietf-inet-types {
prefix nacm; prefix inet;
reference reference
"RFC 8341: Network Configuration Access Control "RFC 6991: Common YANG Data Types.";
Model."; }
} 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.";
}
organization "IETF I2NSF Working Group"; organization
contact "IETF I2NSF Working Group";
"WG Web: <https://datatracker.ietf.org/wg/i2nsf/> 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 { }
type enumeration {
enum ikev2 { typedef auth-protocol-type {
value 2; type enumeration {
description enum ikev2 {
"IKEv2 authentication protocol. It is the value 2;
only one defined right now. An enum is description
"IKEv2 authentication protocol. It is the
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
Protocol, Section 4.4.3.1.";
case ipv4-address { case ipv4-address {
leaf ipv4-address { leaf ipv4-address {
type inet:ipv4-address; type inet:ipv4-address;
description description
"Specifies the identity as "Specifies the identity as
a single four (4) octet IPv4 address."; a single 4-octet IPv4 address.";
} }
} }
case ipv6-address{ case ipv6-address {
leaf ipv6-address { leaf ipv6-address {
type inet:ipv6-address; type inet:ipv6-address;
description description
"Specifies the identity as a "Specifies the identity as a
single sixteen (16) octet IPv6 single 16-octet IPv6
address. An example is 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 { leaf auth-protocol {
type auth-protocol-type; type auth-protocol-type;
default ikev2; default "ikev2";
description description
"Only IKEv2 is supported right now but "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: Internet X.509 Public Key Infrastructure
"RFC 5280"; Certificate and Certificate Revocation
} List (CRL) Profile.";
leaf oscp-uri { }
type inet:uri; leaf oscp-uri {
description type inet:uri;
"OCSP URI. description
If it is not defined "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 */
} }
<CODE ENDS>
<CODE ENDS>
6.3. The 'ietf-i2nsf-ikeless' Module 5.3. The 'ietf-i2nsf-ikeless' Module
In this section, the YANG module for the IKE-less case is described. In this section, the YANG module for the IKE-less case is described.
6.3.1. Data model overview 5.3.1. Data Model Overview
For this case, the definition of the SPD model has been mainly 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 extracted from the specification in Section 4.4.1 and Appendix D in
[RFC4301], though with some changes, namely: [RFC4301], though with some changes, namely:
o For simplicity, each IPsec policy (spd-entry) contains one traffic * For simplicity, each IPsec policy (spd-entry) contains one Traffic
selector, instead of a list of them. The reason is that actual Selector, instead of a list of them. The reason is that actual
kernel implementations only admit a single traffic selector per kernel implementations only admit a single Traffic Selector per
IPsec policy. IPsec policy.
o Each IPsec policy contains an identifier (reqid) to relate the * Each IPsec policy contains an identifier (reqid) to relate the
policy with the IPsec SA. This is common in Linux-based systems. policy with the IPsec SA. This is common in Linux-based systems.
o Each IPsec policy has only one name and not a list of names. * Each IPsec policy has only one name and not a list of names.
o Combined algorithms have been removed because encryption * Combined algorithms have been removed because encryption
algorithms MAY include authenticated encryption with associated algorithms MAY include Authenticated Encryption with Associated
data (AEAD). Data (AEAD).
o Tunnel information has been extended with information about DSCP * Tunnel information has been extended with information about DSCP
mapping. The reason is that certain kernel implementations accept mapping. The reason is that certain kernel implementations accept
configuration of these values. configuration of these values.
The definition of the SAD model has been mainly extracted from the The definition of the SAD model has been mainly extracted from the
specification in section 4.4.2 in [RFC4301] though with some changes, specification in Section 4.4.2 of [RFC4301], though with some
namely: changes, namely:
o For simplicity, each IPsec SA (sad-entry) contains one traffic * For simplicity, each IPsec SA (sad-entry) contains one Traffic
selector, instead of a list of them. The reason is that actual Selector, instead of a list of them. The reason is that actual
kernel implementations only admit a single traffic selector per kernel implementations only admit a single Traffic Selector per
IPsec SA. IPsec SA.
o Each IPsec SA contains a identifier (reqid) to relate the IPsec SA * Each IPsec SA contains an identifier (reqid) to relate the IPsec
with the IPsec Policy. The reason is that real kernel SA with the IPsec policy. The reason is that real kernel
implementations allow to include this value. implementations allow this value to be included.
o Each IPsec SA has also a name in the same way as IPsec policies. * Each IPsec SA is also named in the same way as IPsec policies.
o The model allows specifying the algorithm for encryption. This * The model allows specifying the algorithm for encryption. This
can be an Authenticated Encryption with Associated Data (AEAD) or can be Authenticated Encryption with Associated Data (AEAD) or
non-AEAD. If an AEAD is specified the integrity algorithm is not non-AEAD. If an AEAD algorithm is specified, the integrity
required. If an non-AEAD algorithm is specified the integrity algorithm is not required. If a non-AEAD algorithm is specified,
algorithm is required [RFC8221]. the integrity algorithm is required [RFC8221].
o Tunnel information has been extended with information about * Tunnel information has been extended with information about
Differentiated Services Code Point (DSCP) mapping. It is assumed Differentiated Services Code Point (DSCP) mapping. It is assumed
that NSFs involved in this document provide ECN full-functionality that NSFs involved in this document provide ECN full functionality
to prevent discarding of ECN congestion indications [RFC6040]. to prevent discarding of ECN congestion indications [RFC6040].
o Lifetime of the IPsec SAs also include idle time and number of IP * The lifetime of the IPsec SAs also includes idle time and the
packets as threshold to trigger the lifetime. The reason is that number of IP packets as a threshold to trigger the lifetime. The
actual kernel implementations allow to set these types of reason is that actual kernel implementations allow for setting
lifetimes. these types of lifetimes.
o Information to configure the type of encapsulation (encapsulation- * Information to configure the type of encapsulation (encapsulation-
type) for IPsec ESP packets in UDP ([RFC3948]), or TCP ([RFC8229]) type) for IPsec ESP packets in UDP [RFC3948] or TCP [RFC8229] has
has been included. been included.
The notifications model has been defined using as reference the The notifications model has been defined using, as reference, the
PF_KEYv2 specification in [RFC2367]. PF_KEYv2 specification in [RFC2367].
The YANG data model for the IKE-less case is defined by the module The YANG data model for the IKE-less case is defined by the module
"ietf-i2nsf-ikeless". Its structure is depicted in the following "ietf-i2nsf-ikeless". Its structure is depicted in the following
diagram, using the notation syntax for YANG tree diagrams diagram, using the notation syntax for YANG tree diagrams [RFC8340].
([RFC8340]).
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: notifications:
+---n sadb-acquire {ikeless-notification}? +---n sadb-acquire {ikeless-notification}?
| +--ro ipsec-policy-name string | +--ro ipsec-policy-name string
| +--ro traffic-selector | +--ro traffic-selector
| +--ro local-prefix inet:ip-prefix | +--ro local-prefix inet:ip-prefix
| +--ro remote-prefix inet:ip-prefix | +--ro remote-prefix inet:ip-prefix
| +--ro inner-protocol? ipsec-inner-protocol | +--ro inner-protocol? ipsec-inner-protocol
| +--ro local-ports* [start end] | +--ro local-ports* [start end]
| | +--ro start inet:port-number | | +--ro start inet:port-number
| | +--ro end inet:port-number | | +--ro end inet:port-number
| +--ro remote-ports* [start end] | +--ro remote-ports* [start end]
| +--ro start inet:port-number | +--ro start inet:port-number
| +--ro end inet:port-number | +--ro end inet:port-number
+---n sadb-expire {ikeless-notification}? +---n sadb-expire {ikeless-notification}?
| +--ro ipsec-sa-name string | +--ro ipsec-sa-name string
| +--ro soft-lifetime-expire? boolean | +--ro soft-lifetime-expire? boolean
| +--ro lifetime-current | +--ro 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
+---n sadb-seq-overflow {ikeless-notification}? +---n sadb-seq-overflow {ikeless-notification}?
| +--ro ipsec-sa-name string | +--ro ipsec-sa-name string
+---n sadb-bad-spi {ikeless-notification}? +---n sadb-bad-spi {ikeless-notification}?
+--ro spi uint32 +--ro spi uint32
The YANG data model consists of a unique "ipsec-ikeless" container The YANG data model consists of a unique "ipsec-ikeless" container,
which, in turn, is composed of two additional containers: "spd" and which, in turn, is composed of two additional containers: "spd" and
"sad". The "spd" container consists of a list of entries that form "sad". The "spd" container consists of a list of entries that form
the Security Policy Database. Compared to the IKE case YANG data the Security Policy Database. Compared to the IKE case YANG data
model, this part specifies a few additional parameters necessary due model, this part specifies a few additional parameters necessary due
to the absence of an IKE software in the NSF: traffic direction to to the absence of an IKE software in the NSF: traffic direction to
apply the IPsec policy, and a "reqid" value to link an IPsec policy apply the IPsec policy and a "reqid" value to link an IPsec policy
with its associated IPsec SAs since it is otherwise a little hard to with its associated IPsec SAs since it is otherwise a little hard to
find by searching. The "sad" container is a list of entries that find by searching. The "sad" container is a list of entries that
form the Security Association Database. In general, each entry form the Security Association Database. In general, each entry
allows specifying both configuration information (SPI, traffic allows specifying both configuration information (SPI, Traffic
selectors, tunnel/transport mode, cryptographic algorithms and keying Selectors, tunnel/transport mode, cryptographic algorithms and keying
material, soft/hard lifetimes, etc.) as well as state information material, soft/hard lifetimes, etc.) as well as stating information
(time to expire, replay statistics, etc.) of a concrete IPsec SA. (time to expire, replay statistics, etc.) of a concrete IPsec SA.
In addition, the module defines a set of notifications to allow the In addition, the module defines a set of notifications to allow the
NSF inform I2NSF controller about relevant events such as IPsec SA NSF to inform the I2NSF Controller about relevant events, such as
expiration, sequence number overflow or bad SPI in a received packet. IPsec SA expiration, sequence number overflow, or bad SPI in a
received packet.
6.3.2. Example Usage 5.3.2. Example Usage
Appendix B shows an example of IKE-less case configuration for a NSF, Appendix B shows an example of an IKE-less case configuration for an
in transport mode (host-to-host). Additionally, Appendix C shows NSF in transport mode (host-to-host). Additionally, Appendix C shows
examples of IPsec SA expire, acquire, sequence number overflow and examples of IPsec SA expire, acquire, sequence number overflow, and
bad SPI notifications. bad SPI notifications.
6.3.3. YANG Module 5.3.3. YANG Module
This YANG module has normative references to [RFC4301], [RFC6991],
[RFC8174] and [RFC8341].
<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 { This YANG module has normative references to [RFC4301], [RFC4303],
prefix nacm; [RFC6991], [RFC8174] and [RFC8341].
reference
"RFC 8341: Network Configuration Access Control
Model.";
}
organization "IETF I2NSF Working Group"; <CODE BEGINS> file "ietf-i2nsf-ikeless@2021-06-09.yang"
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 {
description container ipsec-ikeless {
"Container for configuration of the IKE-less description
"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 { leaf protocol-parameters {
type nsfikec:ipsec-protocol-parameters; type nsfikec:ipsec-protocol-params;
default esp; default "esp";
description description
"Security protocol of IPsec SA: Only "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
determined by the
The key length is length of the key set in
determined by the this leaf. By default, it is
length of the key set in 128 bits.";
this leaf. By default is }
128 bits."; leaf iv {
} nacm:default-deny-all;
leaf iv { type yang:hex-string;
nacm:default-deny-all; description
type yang:hex-string; "ESP encryption IV value. If
description this leaf is not defined, the
"ESP encryption IV value. If
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> 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>
7. IANA Considerations 6. IANA Considerations
This document registers three URIs in the "ns" subregistry of the IANA has registered the following namespaces in the "ns" subregistry
IETF XML Registry [RFC3688]. Following the format in [RFC3688], the within the "IETF XML Registry" [RFC3688]:
following registrations are requested:
URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikec URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikec
Registrant Contact: The IESG. Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace. XML: N/A, the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-ike URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-ike
Registrant Contact: The IESG. Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace. XML: N/A, the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless
Registrant Contact: The IESG. Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace. XML: N/A, the requested URI is an XML namespace.
This document registers three YANG modules in the "YANG Module Names" IANA has registered the following YANG modules in the "YANG Module
registry [RFC6020]. Following the format in [RFC6020], the following Names" registry [RFC6020]:
registrations are requested:
Name: ietf-i2nsf-ikec Name: ietf-i2nsf-ikec
Namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikec Maintained by IANA: N
Prefix: nsfikec Namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikec
Reference: RFC XXXX Prefix: nsfikec
Reference: RFC 9061
Name: ietf-i2nsf-ike Name: ietf-i2nsf-ike
Namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-ike Maintained by IANA: N
Prefix: nsfike Namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-ike
Reference: RFC XXXX Prefix: nsfike
Reference: RFC 9061
Name: ietf-i2nsf-ikeless Name: ietf-i2nsf-ikeless
Namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless Maintained by IANA: N
Prefix: nsfikels Namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless
Reference: RFC XXXX Prefix: nsfikels
Reference: RFC 9061
8. Security Considerations 7. Security Considerations
First of all, this document shares all the security issues of SDN First of all, this document shares all the security issues of SDN
that are specified in the "Security Considerations" section of that are specified in the Security Considerations sections of
[ITU-T.Y.3300] and [RFC7426]. [ITU-T.Y.3300] and [RFC7426].
On the one hand, it is important to note that there MUST exist a On the one hand, it is important to note that there MUST exist a
security association between the I2NSF Controller and the NSFs to security association between the I2NSF Controller and the NSFs to
protect the critical information (cryptographic keys, configuration protect the critical information (cryptographic keys, configuration
parameter, etc.) exchanged between these entities. The nature of and parameter, etc.) exchanged between these entities. The nature of and
means to create that security association is out of the scope of this means to create that security association is out of the scope of this
document (i.e., it is part of device provisioning or onboarding). document (i.e., it is part of device provisioning or onboarding).
On the other hand, if encryption is mandatory for all traffic of a On the other hand, if encryption is mandatory for all traffic of an
NSF, its default policy MUST be to drop (DISCARD) packets to prevent NSF, its default policy MUST be to drop (DISCARD) packets to prevent
cleartext packet leaks. This default policy MUST be pre-configured cleartext packet leaks. This default policy MUST be preconfigured in
in the startup configuration datastore in the NSF before the NSF the startup configuration datastore in the NSF before the NSF
contacts the I2NSF Controller. Moreover, the startup configuration contacts the I2NSF Controller. Moreover, the startup configuration
datastore MUST be also pre-configured with the required ALLOW datastore MUST be also preconfigured with the required ALLOW policies
policies that allow the NSF to communicate with the I2NSF Controller that allow the NSF to communicate with the I2NSF Controller once the
once the NSF is deployed. This pre-configuration step is not carried NSF is deployed. This preconfiguration step is not carried out by
out by the I2NSF Controller but by some other entity before the NSF the I2NSF Controller but by some other entity before the NSF
deployment. In this manner, when the NSF starts/reboots, it will deployment. In this manner, when the NSF starts/reboots, it will
always first apply the configuration in the startup configuration always first apply the configuration in the startup configuration
before contacting the I2NSF Controller. before contacting the I2NSF Controller.
Finally, this section is divided in two parts in order to analyze Finally, this section is divided in two parts in order to analyze
different security considerations for both cases: NSF with IKEv2 (IKE different security considerations for both cases: NSF with IKEv2 (IKE
case) and NSF without IKEv2 (IKE-less case). In general, the I2NSF case) and NSF without IKEv2 (IKE-less case). In general, the I2NSF
Controller, as typically in the SDN paradigm, is a target for Controller, as typically in the SDN paradigm, is a target for
different type of attacks [SDNSecServ] and [SDNSecurity]. Thus, the different type of attacks; see [SDNSecServ] and [SDNSecurity]. Thus,
I2NSF Controller is a key entity in the infrastructure and MUST be the I2NSF Controller is a key entity in the infrastructure and MUST
protected accordingly. In particular, the I2NSF Controller will be protected accordingly. In particular, the I2NSF Controller will
handle cryptographic material thus the attacker may try to access handle cryptographic material; thus, the attacker may try to access
this information. The impact is different depending on the IKE case this information. The impact is different depending on the IKE case
or the IKE-less case. or the IKE-less case.
8.1. IKE case 7.1. IKE Case
In the IKE case, the I2NSF Controller sends IKEv2 credentials (PSK, In the IKE case, the I2NSF Controller sends IKEv2 credentials (PSK,
public/private keys, certificates, etc.) to the NSFs using the public/private keys, certificates, etc.) to the NSFs using the
security association between I2NSF Controller and NSFs. The I2NSF security association between the I2NSF Controller and NSFs. The
Controller MUST NOT store the IKEv2 credentials after distributing I2NSF Controller MUST NOT store the IKEv2 credentials after
them. Moreover, the NSFs MUST NOT allow the reading of these values distributing them. Moreover, the NSFs MUST NOT allow the reading of
once they have been applied by the I2NSF Controller (i.e. write only these values once they have been applied by the I2NSF Controller
operations). One option is to always return the same value (i.e. all (i.e., write-only operations). One option is to always return the
0s) if a read operation is carried out. same value (i.e., all 0s) if a read operation is carried out.
If the attacker has access to the I2NSF Controller during the period If the attacker has access to the I2NSF Controller during the period
of time that key material is generated, it might have access to the of time that key material is generated, it might have access to the
key material. Since these values are used during NSF authentication key material. Since these values are used during NSF authentication
in IKEv2, it may impersonate the affected NSFs. Several in IKEv2, it may impersonate the affected NSFs. Several
recommendations are important. recommendations are important.
o IKEv2 configurations SHOULD adhere to the recommendations in * IKEv2 configurations SHOULD adhere to the recommendations in
[RFC8247]. [RFC8247].
o If PSK authentication is used in IKEv2, the I2NSF Controller MUST * If PSK authentication is used in IKEv2, the I2NSF Controller MUST
remove the PSK immediately after generating and distributing it. remove the PSK immediately after generating and distributing it.
o When public/private keys are used, the I2NSF Controller MAY * When public/private keys are used, the I2NSF Controller MAY
generate both public key and private key. In such a case, the generate both public key and private key. In such a case, the
I2NSF Controller MUST remove the associated private key I2NSF Controller MUST remove the associated private key
immediately after distributing them to the NSFs. Alternatively, immediately after distributing them to the NSFs. Alternatively,
the NSF MAY generate the private key and export only the public the NSF MAY generate the private key and export only the public
key to the I2NSF Controller. How the NSF generates these key to the I2NSF Controller. How the NSF generates these
cryptographic material (public key/ private keys) and exports the cryptographic materials (public key/ private keys) and exports the
public key, is out of scope of this document. public key is out of scope of this document.
o If certificates are used, the NSF MAY generate the private key and * If certificates are used, the NSF MAY generate the private key and
export the public key for certification to the I2NSF Controller. export the public key for certification to the I2NSF Controller.
How the NSF generates these cryptographic material (public key/ How the NSF generates these cryptographic material (public key/
private keys) and exports the public key, is out of scope of this private keys) and exports the public key is out of scope of this
document. document.
8.2. IKE-less case 7.2. IKE-less Case
In the IKE-less case, the I2NSF Controller sends the IPsec SA In the IKE-less case, the I2NSF Controller sends the IPsec SA
information to the NSF's SAD that includes the private session keys information to the NSF's SAD that includes the private session keys
required for integrity and encryption. The I2NSF Controller MUST NOT required for integrity and encryption. The I2NSF Controller MUST NOT
store the keys after distributing them. Moreover, the NSFs receiving store the keys after distributing them. Moreover, the NSFs receiving
private key material MUST NOT allow the reading of these values by private key material MUST NOT allow the reading of these values by
any other entity (including the I2NSF Controller itself) once they any other entity (including the I2NSF Controller itself) once they
have been applied (i.e. write only operations) into the NSFs. have been applied (i.e., write-only operations) into the NSFs.
Nevertheless, if the attacker has access to the I2NSF Controller Nevertheless, if the attacker has access to the I2NSF Controller
during the period of time that key material is generated, it may during the period of time that key material is generated, it may
obtain these values. In other words, the attacker might be able to obtain these values. In other words, the attacker might be able to
observe the IPsec traffic and decrypt, or even modify and re-encrypt, observe the IPsec traffic and decrypt, or even modify and re-encrypt,
the traffic between peers. the traffic between peers.
Finally, the security association between the I2NSF Controller and Finally, the security association between the I2NSF Controller and
the NSFs MUST provide, at least, the same degree of protection as the the NSFs MUST provide, at least, the same degree of protection as the
one achieved by the IPsec SAs configured in the NSFs. In particular, one achieved by the IPsec SAs configured in the NSFs. In particular,
the security association between the I2NSF Controller and the NSFs the security association between the I2NSF Controller and the NSFs
MUST provide forward secrecy if this property is to be achieved in MUST provide forward secrecy if this property is to be achieved in
the IPsec SAs that the I2NSF Controller configures in the NSFs. the IPsec SAs that the I2NSF Controller configures in the NSFs.
Similarly, the encryption algorithms used in the security association Similarly, the encryption algorithms used in the security association
between I2NSF Controller and the NSF MUST have, at least, the same between the I2NSF Controller and the NSF MUST have, at least, the
strength (minimum strength of a 128-bit key) as the algorithms used same strength (minimum strength of a 128-bit key) as the algorithms
to establish the IPsec SAs. used to establish the IPsec SAs.
8.3. YANG modules 7.3. YANG Modules
The modules specified in this document define a schema for data that The YANG modules specified in this document define a schema for data
is designed to be accessed via network management protocols such as that is designed to be accessed via network management protocols such
NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer
the secure transport layer, and the mandatory-to-implement secure is the secure transport layer, and the mandatory-to-implement secure
transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer
is HTTPS, and the mandatory-to-implement secure transport is TLS is HTTPS, and the mandatory-to-implement secure transport is TLS
[RFC8446]. [RFC8446].
The Network Configuration Access Control Model (NACM) [RFC8341] The Network Configuration Access Control Model (NACM) [RFC8341]
provides the means to restrict access for particular NETCONF or provides the means to restrict access for particular NETCONF or
RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or
RESTCONF protocol operations and content. RESTCONF protocol operations and content.
There are a number of data nodes defined in these YANG modules that There are a number of data nodes defined in these YANG modules that
are writable/creatable/deletable (i.e., config true, which is the are writable/creatable/deletable (i.e., config true, which is the
default). These data nodes may be considered sensitive or vulnerable default). These data nodes may be considered sensitive or vulnerable
in some network environments. Write operations (e.g., edit-config) in some network environments. Write operations (e.g., edit-config)
to these data nodes without proper protection can have a negative to these data nodes without proper protection can have a negative
effect on network operations. These are the subtrees and data nodes effect on network operations. These are the subtrees and data nodes
and their sensitivity/vulnerability: and their sensitivity/vulnerability:
For the IKE case (ietf-i2nsf-ike): For the IKE case (ietf-i2nsf-ike):
/ipsec-ike: The entire container in this module is sensitive to
/ipsec-ike: The entire container in this module is sensitive to
write operations. An attacker may add/modify the credentials write operations. An attacker may add/modify the credentials
to be used for the authentication (e.g., to impersonate a NSF), to be used for the authentication (e.g., to impersonate an
the trust root (e.g., changing the trusted CA certificates), NSF), for the trust root (e.g., changing the trusted CA
the cryptographic algorithms (allowing a downgrading attack), certificates), for the cryptographic algorithms (allowing a
the IPsec policies (e.g., by allowing leaking of data traffic downgrading attack), for the IPsec policies (e.g., by allowing
by changing to an allow policy), and in general changing the leaking of data traffic by changing to an allow policy), and in
IKE SA conditions and credentials between any NSF. general, changing the IKE SA conditions and credentials between
any NSF.
For the IKE-less case (ietf-i2nsf-ikeless): For the IKE-less case (ietf-i2nsf-ikeless):
/ipsec-ikeless: The entire container in this module is sensitive
to write operations. An attacker may add/modify/delete any
IPsec policies (e.g., by allowing leaking of data traffic by
changing to an allow policy) in the /ipsec-ikeless/spd
container, add/modify/delete any IPsec SAs between two NSF by
means of /ipsec-ikeless/sad container, and, in general, change
any IPsec SAs and IPsec policies between any NSF.
/ipsec-ikeless: The entire container in this module is Some of the readable data nodes in these YANG modules may be
sensitive to write operations. An attacker may add/modify/ considered sensitive or vulnerable in some network environments. It
delete any IPsec policies (e.g., by allowing leaking of data is thus important to control read access (e.g., via get, get-config,
traffic by changing to a allow policy) in the /ipsec-ikeless/ or notification) to these data nodes. These are the subtrees and
spd container, and add/modify/delete any IPsec SAs between two data nodes and their sensitivity/vulnerability:
NSF by means of /ipsec-ikeless/sad container and, in general,
changing any IPsec SAs and IPsec policies between any NSF.
Some of the readable data nodes in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus
important to control read access (e.g., via get, get-config, or
notification) to these data nodes. These are the subtrees and data
nodes and their sensitivity/vulnerability:
For the IKE case (ietf-i2nsf-ike): For the IKE case (ietf-i2nsf-ike):
/ipsec-ike/pad: This container includes sensitive information to
/ipsec-ike/pad: This container includes sensitive information read operations. This information MUST NOT be returned to a
to read operations. This information MUST NOT be returned to a
client. For example, cryptographic material configured in the client. For example, cryptographic material configured in the
NSFs (peer-authentication/pre-shared/secret and peer- NSFs (peer-authentication/pre-shared/secret and peer-
authentication/digital-signature/private-key) are already authentication/digital-signature/private-key) are already
protected by the NACM extension "default-deny-all" in this protected by the NACM extension "default-deny-all" in this
document. document.
For the IKE-less case (ietf-i2nsf-ikeless): For the IKE-less case (ietf-i2nsf-ikeless):
/ipsec-ikeless/sad/sad-entry/ipsec-sa-config/esp-sa: This
/ipsec-ikeless/sad/sad-entry/ipsec-sa-config/esp-sa: This
container includes symmetric keys for the IPsec SAs. For container includes symmetric keys for the IPsec SAs. For
example, encryption/key contains an ESP encryption key value example, encryption/key contains an ESP encryption key value
and encryption/iv contains an initialization vector value. and encryption/iv contains an Initialization Vector value.
Similarly, integrity/key has an ESP integrity key value. Those Similarly, integrity/key has an ESP integrity key value. Those
values MUST NOT be read by anyone and are protected by the NACM values MUST NOT be read by anyone and are protected by the NACM
extension "default-deny-all" in this document. extension "default-deny-all" in this document.
9. Acknowledgements 8. References
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.
10. References
10.1. Normative References 8.1. Normative References
[IANA-Method-Type] [IANA-Method-Type]
Internet Assigned Numbers Authority (IANA), "Method Type", IANA, "Method Type",
April 2020, <https://www.iana.org/assignments/eap-numbers/ <https://www.iana.org/assignments/eap-numbers/>.
eap-numbers.xhtml#eap-numbers-4>.
[IANA-Protocols-Number] [IANA-Protocols-Number]
Internet Assigned Numbers Authority (IANA), "Protocol IANA, "Protocol Numbers",
Numbers", January 2020, <https://www.iana.org/assignments/ <https://www.iana.org/assignments/protocol-numbers/>.
protocol-numbers/protocol-numbers.xhtml>.
[IKEv2-Auth-Method] [IKEv2-Auth-Method]
Internet Assigned Numbers Authority (IANA), "Internet Key IANA, "IKEv2 Authentication Method",
Exchange Version 2 (IKEv2) Parameters - IKEv2 <https://www.iana.org/assignments/ikev2-parameters/>.
Authentication Method", August 2020,
<https://www.iana.org/assignments/ikev2-parameters/
ikev2-parameters.xhtml#ikev2-parameters-12>.
[IKEv2-Parameters] [IKEv2-Parameters]
Internet Assigned Numbers Authority (IANA), "Internet Key IANA, "Internet Key Exchange Version 2 (IKEv2)
Exchange Version 2 (IKEv2) Parameters", August 2020, Parameters",
<https://www.iana.org/assignments/ikev2-parameters/ <https://www.iana.org/assignments/ikev2-parameters/>.
ikev2-parameters.xhtml>.
[IKEv2-Transform-Type-1] [IKEv2-Transform-Type-1]
Internet Assigned Numbers Authority (IANA), "Internet Key IANA, "Transform Type 1 - Encryption Algorithm Transform
Exchange Version 2 (IKEv2) Parameters - Transform Type IDs",
Values - Transform Type 1 - Encryption Algorithm Transform <https://www.iana.org/assignments/ikev2-parameters/>.
IDs", August 2020, <https://www.iana.org/assignments/
ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-
5>.
[IKEv2-Transform-Type-3] [IKEv2-Transform-Type-3]
Internet Assigned Numbers Authority (IANA), "Internet Key IANA, "Transform Type 3 - Integrity Algorithm Transform
Exchange Version 2 (IKEv2) Parameters - Transform Type IDs",
Values - Transform Type 3 - Integrity Algorithm Transform <https://www.iana.org/assignments/ikev2-parameters/>.
IDs", August 2020, <https://www.iana.org/assignments/
ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-
7>.
[IKEv2-Transform-Type-4] [IKEv2-Transform-Type-4]
Internet Assigned Numbers Authority (IANA), "Internet Key IANA, "Transform Type 4 - Diffie-Hellman Group Transform
Exchange Version 2 (IKEv2) Parameters - Transform Type IDs",
Values - Transform Type 4 - Diffie-Hellman Group Transform <https://www.iana.org/assignments/ikev2-parameters/>.
IDs", August 2020, <https://www.iana.org/assignments/
ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-
8>.
[ITU-T.X.690] [ITU-T.X.690]
"Recommendation ITU-T X.690", August 2015. International Telecommunication Union, "Information
Technology - ASN.1 encoding rules: Specification of Basic
Encoding Rules (BER), Canonical Encoding Rules (CER) and
Distinguished Encoding Rules (DER)", ITU-T Recommendation
X.690, ISO/IEC 8825-1, February 2021.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R., and S.
Sataluri, "Using Domains in LDAP/X.500 Distinguished
Names", RFC 2247, DOI 10.17487/RFC2247, January 1998,
<https://www.rfc-editor.org/info/rfc2247>.
[RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe,
"Negotiation of NAT-Traversal in the IKE", RFC 3947, "Negotiation of NAT-Traversal in the IKE", RFC 3947,
DOI 10.17487/RFC3947, January 2005, DOI 10.17487/RFC3947, January 2005,
<https://www.rfc-editor.org/info/rfc3947>. <https://www.rfc-editor.org/info/rfc3947>.
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets", Stenberg, "UDP Encapsulation of IPsec ESP Packets",
RFC 3948, DOI 10.17487/RFC3948, January 2005, RFC 3948, DOI 10.17487/RFC3948, January 2005,
<https://www.rfc-editor.org/info/rfc3948>. <https://www.rfc-editor.org/info/rfc3948>.
skipping to change at page 77, line 23 skipping to change at line 3621
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc6242>. <https://www.rfc-editor.org/info/rfc6242>.
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
Galperin, S., and C. Adams, "X.509 Internet Public Key
Infrastructure Online Certificate Status Protocol - OCSP",
RFC 6960, DOI 10.17487/RFC6960, June 2013,
<https://www.rfc-editor.org/info/rfc6960>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013, RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>. <https://www.rfc-editor.org/info/rfc6991>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2 Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/info/rfc7296>. 2014, <https://www.rfc-editor.org/info/rfc7296>.
[RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2 [RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2
skipping to change at page 79, line 5 skipping to change at line 3703
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "Network Management Datastore Architecture and R. Wilton, "Network Management Datastore Architecture
(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
<https://www.rfc-editor.org/info/rfc8342>. <https://www.rfc-editor.org/info/rfc8342>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
10.2. Informative References 8.2. Informative References
[I-D.carrel-ipsecme-controller-ike]
Carrel, D. and B. Weiss, "IPsec Key Exchange using a
Controller", draft-carrel-ipsecme-controller-ike-01 (work
in progress), March 2019.
[I-D.tran-ipsecme-yang] [IPSECME-CONTROLLER-IKE]
Tran, K., Wang, H., Nagaraj, V., and X. Chen, "Yang Data Carrel, D. and B. Weis, "IPsec Key Exchange using a
Model for Internet Protocol Security (IPsec)", draft-tran- Controller", Work in Progress, Internet-Draft, draft-
ipsecme-yang-01 (work in progress), June 2015. carrel-ipsecme-controller-ike-01, 10 March 2019,
<https://datatracker.ietf.org/doc/html/draft-carrel-
ipsecme-controller-ike-01>.
[ITU-T.Y.3300] [ITU-T.Y.3300]
"Recommendation ITU-T Y.3300", June 2014, International Telecommunications Union, "Y.3300: Framework
of software-defined networking", June 2014,
<https://www.itu.int/rec/T-REC-Y.3300/en>. <https://www.itu.int/rec/T-REC-Y.3300/en>.
[libreswan] [libreswan]
The Libreswan Project, "Libreswan VPN software", September The Libreswan Project, "Libreswan VPN software",
2020, <https://libreswan.org/>. <https://libreswan.org/>.
[netconf-vpn] [netconf-vpn]
Stefan Wallin, "Tutorial: NETCONF and YANG", January 2014, Stefan Wallin, "Tutorial: NETCONF and YANG", January 2014,
<https://ripe68.ripe.net/presentations/181-NETCONF-YANG- <https://ripe68.ripe.net/presentations/181-NETCONF-YANG-
tutorial-43.pdf>. tutorial-43.pdf>.
[ONF-OpenFlow] [ONF-OpenFlow]
ONF, "OpenFlow Switch Specification (Version 1.4.0)", Open Networking Foundation, "OpenFlow Switch
Specification", Version 1.4.0 (Wire Protocol 0x05),
October 2013, <https://www.opennetworking.org/wp- October 2013, <https://www.opennetworking.org/wp-
content/uploads/2014/10/openflow-spec-v1.4.0.pdf >. content/uploads/2014/10/openflow-spec-v1.4.0.pdf>.
[ONF-SDN-Architecture] [ONF-SDN-Architecture]
"SDN Architecture", June 2014, Open Networking Foundation, "SDN architecture", Issue 1,
<https://www.opennetworking.org/wp- June 2014, <https://www.opennetworking.org/wp-
content/uploads/2013/02/TR_SDN_ARCH_1.0_06062014.pdf >. content/uploads/2013/02/TR_SDN_ARCH_1.0_06062014.pdf>.
[RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key [RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key
Management API, Version 2", RFC 2367, Management API, Version 2", RFC 2367,
DOI 10.17487/RFC2367, July 1998, DOI 10.17487/RFC2367, July 1998,
<https://www.rfc-editor.org/info/rfc2367>. <https://www.rfc-editor.org/info/rfc2367>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>. <https://www.rfc-editor.org/info/rfc3688>.
skipping to change at page 80, line 38 skipping to change at line 3783
(I2NSF): Problem Statement and Use Cases", RFC 8192, (I2NSF): Problem Statement and Use Cases", RFC 8192,
DOI 10.17487/RFC8192, July 2017, DOI 10.17487/RFC8192, July 2017,
<https://www.rfc-editor.org/info/rfc8192>. <https://www.rfc-editor.org/info/rfc8192>.
[RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R.
Kumar, "Framework for Interface to Network Security Kumar, "Framework for Interface to Network Security
Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018,
<https://www.rfc-editor.org/info/rfc8329>. <https://www.rfc-editor.org/info/rfc8329>.
[SDNSecServ] [SDNSecServ]
Scott-Hayward, S., O'Callaghan, G., and P. Sezer, "SDN Scott-Hayward, S., O'Callaghan, G., and P. Sezer, "Sdn
Security: A Survey. IEEE SDN for Future Networks and Security: A Survey", 2013 IEEE SDN for Future Networks and
Services (SDN4FNS), Trento, 2013, pp. 1-7, doi: 10.1109/ Services (SDN4FNS), pp. 1-7,
SDN4FNS.2013.6702553.", 2013. DOI 10.1109/SDN4FNS.2013.6702553, November 2013,
<https://doi.org/10.1109/SDN4FNS.2013.6702553>.
[SDNSecurity] [SDNSecurity]
Kreutz, D., Ramos, F., and P. Verissimo, "Towards secure Kreutz, D., Ramos, F., and P. Verissimo, "Towards secure
and dependable software-defined networks. HotSDN 2013 - and dependable software-defined networks", Proceedings of
Proceedings of the 2013 ACM SIGCOMM Workshop on Hot Topics the second ACM SIGCOMM workshop on Hot Topics in software
in Software Defined Networking. 55-60. defined networking, pp. 55-60,
10.1145/2491185.2491199.", 2013. DOI 10.1145/2491185.2491199, August 2013,
<https://doi.org/10.1145/2491185.2491199>.
[strongswan] [strongswan]
CESNET, "StrongSwan: the OpenSource IPsec-based VPN CESNET, "strongSwan: the OpenSource IPsec-based VPN
Solution", September 2020, <https://www.strongswan.org/>. Solution", <https://www.strongswan.org/>.
Appendix A. XML configuration example for IKE case (gateway-to-gateway) [TRAN-IPSECME-YANG]
Tran, K., Wang, H., Nagaraj, V. K., and X. Chen, "Yang
Data Model for Internet Protocol Security (IPsec)", Work
in Progress, Internet-Draft, draft-tran-ipsecme-yang-01,
18 March 2016, <https://datatracker.ietf.org/doc/html/
draft-tran-ipsecme-yang-01>.
This example shows a XML configuration file sent by the I2NSF Appendix A. XML Configuration Example for IKE Case (Gateway-to-Gateway)
Controller to establish a IPsec SA between two NSFs (see Figure 3) in
tunnel mode (gateway-to-gateway) with ESP, authentication based on This example shows an XML configuration file sent by the I2NSF
X.509 certificates (simplified for brevity with Controller to establish an IPsec SA between two NSFs (see Figure 3)
in tunnel mode (gateway-to-gateway) with ESP, with authentication
based on X.509 certificates (simplified for brevity with
"base64encodedvalue==") and applying the IKE case. "base64encodedvalue==") and applying the IKE case.
+------------------+ +------------------+
| 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)
Figure 3: IKE case, tunnel mode , X.509 certificate authentication. Figure 3: IKE Case, Tunnel Mode, X.509 Certificate Authentication
<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>
skipping to change at page 82, line 19 skipping to change at line 3868
<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 page 84, line 16 skipping to change at line 3960
<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>
Appendix B. XML configuration example for IKE-less case (host-to-host) Appendix B. XML Configuration Example for IKE-less Case (Host-to-Host)
This example shows a XML configuration file sent by the I2NSF This example shows an XML configuration file sent by the I2NSF
Controller to establish a IPsec SA between two NSFs (see Figure 4) in Controller to establish an IPsec SA between two NSFs (see Figure 4)
transport mode (host-to-host) with ESP in the IKE-less case. in transport mode (host-to-host) with ESP in the IKE-less case.
+------------------+ +------------------+
| 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
Figure 4: IKE-less case, transport mode. Figure 4: IKE-less Case, Transport Mode
<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>
skipping to change at page 88, line 5 skipping to change at line 4135
<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>
Appendix C. XML notification examples Appendix C. XML Notification Examples
In the following, several XML files are shown to illustrate different In the following, several XML files are shown to illustrate different
types of notifications defined in the IKE-less YANG model, which are types of notifications defined in the IKE-less YANG data model, which
sent by the NSF to the I2NSF Controller. The notifications happen in are sent by the NSF to the I2NSF Controller. The notifications
the IKE-less case. happen in the IKE-less case.
<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>
Figure 5: Example of sadb-expire notification. Figure 5: Example of the sadb-expire Notification
<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>
Figure 6: Example of sadb-acquire notification. Figure 6: Example of the sadb-acquire Notification
<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>
Figure 7: Example of sadb-seq-overflow notification. Figure 7: Example of the sadb-seq-overflow Notification
<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>
Figure 8: Example of sadb-bad-spi notification. Figure 8: Example of the sadb-bad-spi Notification
Appendix D. Operational use cases examples Appendix D. Operational Use Case Examples
D.1. Example of IPsec SA establishment D.1. Example of IPsec SA Establishment
This appendix exemplifies the applicability of IKE case and IKE-less This appendix exemplifies the applicability of the IKE case and IKE-
case to traditional IPsec configurations, that is, host-to-host and less case to traditional IPsec configurations, that is, host-to-host
gateway-to-gateway. The following examples assume the existence of and gateway-to-gateway. The following examples assume the existence
two NSFs needing to establish an end-to-end IPsec SA to protect their of two NSFs needing to establish an end-to-end IPsec SA to protect
communications. Both NSFs could be two hosts that exchange traffic their communications. Both NSFs could be two hosts that exchange
(host-to-host) or gateways (gateway-to-gateway), for example, within traffic (host-to-host) or gateways (gateway-to-gateway), for example,
an enterprise that needs to protect the traffic between the networks within an enterprise that needs to protect the traffic between the
of two branch offices. networks of two branch offices.
Applicability of these configurations appear in current and new Applicability of these configurations appear in current and new
networking scenarios. For example, SD-WAN technologies are providing networking scenarios. For example, SD-WAN technologies are providing
dynamic and on-demand VPN connections between branch offices, or dynamic and on-demand VPN connections between branch offices or
between branches and SaaS cloud services. Besides, IaaS services between branches and Software as a Service (SaaS) cloud services.
providing virtualization environments are deployments that often rely Besides, Infrastructure as a Service (IaaS) services providing
on IPsec to provide secure channels between virtual instances (host- virtualization environments are deployments that often rely on IPsec
to-host) and providing VPN solutions for virtualized networks to provide secure channels between virtual instances (host-to-host)
(gateway-to-gateway). and providing VPN solutions for virtualized networks (gateway-to-
gateway).
As can be observed in the following, the I2NSF-based IPsec management As can be observed in the following, the I2NSF-based IPsec management
system (for IKE and IKE-less cases), exhibits various advantages: system (for IKE and IKE-less cases) exhibits various advantages:
1. It allows to create IPsec SAs among two NSFs, based only on the 1. It allows creating IPsec SAs among two NSFs, based only on the
application of general Flow-based Protection Policies at the application of general flow-based protection policies at the
I2NSF User. Thus, administrators can manage all security I2NSF User. Thus, administrators can manage all security
associations in a centralized point with an abstracted view of associations in a centralized point with an abstracted view of
the network. the network.
2. Any NSF deployed in the system does not need manual 2. Any NSF deployed in the system does not need manual
configuration, therefore allowing its deployment in an automated configuration, therefore, allowing its deployment in an automated
manner. manner.
D.1.1. IKE case D.1.1. IKE Case
+----------------------------------------+ +----------------------------------------+
| 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
| |
+---------|------------------------------+ +---------|------------------------------+
| | | | | |
skipping to change at page 90, line 39 skipping to change at line 4257
| | | |
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) |
+----------------------+ +----------------------+ +----------------------+ +----------------------+
Figure 9: Host-to-host / gateway-to-gateway for the IKE case. Figure 9: Host-to-Host/Gateway-to-Gateway for the IKE Case
Figure 9 describes the application of the IKE case when a data packet Figure 9 describes the application of the IKE case when a data packet
needs to be protected in the path between the NSF A and NSF B: needs to be protected in the path between NSF A and NSF B:
1. The I2NSF User defines a general flow-based protection policy 1. The I2NSF User defines a general flow-based protection policy
(e.g., protect data traffic between NSF A and B). The I2NSF (e.g., protect data traffic between NSF A and B). The I2NSF
Controller looks for the NSFs involved (NSF A and NSF B). Controller looks for the NSFs involved (NSF A and NSF B).
2. The I2NSF Controller generates IKEv2 credentials for them and 2. The I2NSF Controller generates IKEv2 credentials for them and
translates the policies into SPD and PAD entries. translates the policies into SPD and PAD entries.
3. The I2NSF Controller inserts an IKEv2 configuration that includes 3. The I2NSF Controller inserts an IKEv2 configuration that includes
the SPD and PAD entries in both NSF A and NSF B. If some of the SPD and PAD entries in both NSF A and NSF B. If some of
operations with NSF A and NSF B fail the I2NSF Controller will operations with NSF A and NSF B fail, the I2NSF Controller will
stop the process and perform a rollback operation by deleting any stop the process and perform a rollback operation by deleting any
IKEv2, SPD and PAD configuration that had been successfully IKEv2, SPD, and PAD configuration that had been successfully
installed in NSF A or B. installed in NSF A or B.
If the previous steps are successful, the flow is protected by means If the previous steps are successful, the flow is protected by means
of the IPsec SA established with IKEv2 between NSF A and NSF B. of the IPsec SA established with IKEv2 between NSF A and NSF B.
D.1.2. IKE-less case D.1.2. IKE-less Case
+----------------------------------------+ +----------------------------------------+
| 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
| |
+---------|------------------------------+ +---------|------------------------------+
| | | | | |
skipping to change at page 91, line 44 skipping to change at line 4308
| | | |
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) |
+----------------+ +----------------+ +----------------+ +----------------+
Figure 10: Host-to-host / gateway-to-gateway for IKE-less case. Figure 10: Host-to-Host/Gateway-to-Gateway for the IKE-less Case
Figure 10 describes the application of the IKE-less case when a data Figure 10 describes the application of the IKE-less case when a data
packet needs to be protected in the path between the NSF A and NSF B: packet needs to be protected in the path between NSF A and NSF B:
1. The I2NSF User establishes a general Flow-based Protection Policy 1. The I2NSF User establishes a general flow-based protection
and the I2NSF Controller looks for the involved NSFs. policy, and the I2NSF Controller looks for the involved NSFs.
2. The I2NSF Controller translates the flow-based security policies 2. The I2NSF Controller translates the flow-based security policies
into IPsec SPD and SAD entries. into IPsec SPD and SAD entries.
3. The I2NSF Controller inserts these entries in both NSF A and NSF 3. The I2NSF Controller inserts these entries in both NSF A and NSF
B IPsec databases (i.e., SPD and SAD). The following text B IPsec databases (i.e., SPD and SAD). The following text
describes how this would happen: describes how this would happen:
* The I2NSF Controller chooses two random values as SPIs: for * The I2NSF Controller chooses two random values as SPIs, for
example, SPIa1 for the inbound IPsec SA in the NSF A and SPIb1 example, SPIa1 for the inbound IPsec SA in NSF A and SPIb1 for
for the inbound IPsec SA in NSF B. The value of the SPIa1 the inbound IPsec SA in NSF B. The value of the SPIa1 MUST
MUST NOT be the same as any inbound SPI in A. In the same NOT be the same as any inbound SPI in A. In the same way, the
way, the value of the SPIb1 MUST NOT be the same as any value of the SPIb1 MUST NOT be the same as any inbound SPI in
inbound SPI in B. Moreover, the SPIa1 MUST be used in B for B. Moreover, the SPIa1 MUST be used in B for the outbound
the outbound IPsec SA to A, while SPIb1 MUST be used in A for IPsec SA to A, while SPIb1 MUST be used in A for the outbound
the outbound IPsec SA to B. It also generates fresh IPsec SA to B. It also generates fresh cryptographic material
cryptographic material for the new inbound/outbound IPsec SAs for the new inbound/outbound IPsec SAs and their parameters.
and their parameters.
* After that, the I2NSF Controller sends simultaneously the new * After that, the I2NSF Controller simultaneously sends the new
inbound IPsec SA with SPIa1 and new outbound IPsec SA with inbound IPsec SA with SPIa1 and new outbound IPsec SA with
SPIb1 to NSF A; and the new inbound IPsec SA with SPIb1 and SPIb1 to NSF A and the new inbound IPsec SA with SPIb1 and new
new outbound IPsec SA with SPIa1 to B, together with the outbound IPsec SA with SPIa1 to B, together with the
corresponding IPsec policies. corresponding IPsec policies.
* Once the I2NSF Controller receives confirmation from NSF A and * Once the I2NSF Controller receives confirmation from NSF A and
NSF B, it knows that the IPsec SAs are correctly installed and NSF B, it knows that the IPsec SAs are correctly installed and
ready. ready.
Other alternative to this operation is: the I2NSF Controller Another alternative to this operation is the I2NSF Controller
sends first the IPsec policies and new inbound IPsec SAs to A and first sends the IPsec policies and new inbound IPsec SAs to A and
B and, once it obtains a successful confirmation of these B. Once it obtains a successful confirmation of these operations
operations from NSF A and NSF B, it proceeds with installing the from NSF A and NSF B, it proceeds with installing the new
new outbound IPsec SAs. Even though this procedure may increase outbound IPsec SAs. Even though this procedure may increase the
the latency to complete the process, no traffic is sent over the latency to complete the process, no traffic is sent over the
network until the IPsec SAs are completely operative. In any network until the IPsec SAs are completely operative. In any
case other alternatives MAY be possible to implement step 3. case, other alternatives MAY be possible to implement step 3.
4. If some of the operations described above fail (e.g., the NSF A 4. If some of the operations described above fail (e.g., NSF A
reports an error when the I2NSF Controller is trying to install reports an error when the I2NSF Controller is trying to install
the SPD entry, the new inbound or outbound IPsec SAs) the I2NSF the SPD entry, the new inbound or outbound IPsec SAs), the I2NSF
Controller MUST perform rollback operations by deleting any new Controller MUST perform rollback operations by deleting any new
inbound or outbound IPsec SA and SPD entry that had been inbound or outbound IPsec SA and SPD entry that had been
successfully installed in any of the NSFs (e.g., NSF B) and stop successfully installed in any of the NSFs (e.g., NSF B) and stop
the process. Note that the I2NSF Controller MAY retry several the process. Note that the I2NSF Controller MAY retry several
times before giving up. times before giving up.
5. Otherwise, if the steps 1 to 3 are successful, the flow between 5. 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 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. rekeying process.
Instead of installing IPsec policies (in the SPD) and IPsec SAs (in Instead of installing IPsec policies (in the SPD) and IPsec SAs (in
the SAD) in step 3 (proactive mode), it is also possible that the the SAD) in step 3 (proactive mode), it is also possible that the
I2NSF Controller only installs the SPD entries in step 3 (reactive I2NSF Controller only installs the SPD entries in step 3 (reactive
mode). In such a case, when a data packet requires to be protected mode). In such a case, when a data packet requires to be protected
with IPsec, the NSF that saw first the data packet will send a sadb- with IPsec, the NSF that first saw the data packet will send a sadb-
acquire notification that informs the I2NSF Controller that needs SAD acquire notification that informs the I2NSF Controller that needs SAD
entries with the IPsec SAs to process the data packet. Again, if entries with the IPsec SAs to process the data packet. Again, if
some of the operations installing the new inbound/outbound IPsec SAs some of the operations installing the new inbound/outbound IPsec SAs
fail, the I2NSF Controller stops the process and performs a rollback fail, the I2NSF Controller stops the process and performs a rollback
operation by deleting any new inbound/outbound SAs that had been operation by deleting any new inbound/outbound SAs that had been
successfully installed. successfully installed.
D.2. Example of the rekeying process in IKE-less case D.2. Example of the Rekeying Process in IKE-less Case
To explain an example of the rekeying process between two IPsec NSFs To explain an example of the rekeying process between two IPsec NSFs,
A and B, let assume that SPIa1 identifies the inbound IPsec SA in A, A and B, assume that SPIa1 identifies the inbound IPsec SA in A and
and SPIb1 the inbound IPsec SA in B. The rekeying process will take SPIb1 identifies the inbound IPsec SA in B. The rekeying process
the following steps: will take the following steps:
1. The I2NSF Controller chooses two random values as SPI for the new 1. The I2NSF Controller chooses two random values as SPI for the new
inbound IPsec SAs: for example, SPIa2 for the inbound IPsec SA in inbound IPsec SAs, for example, SPIa2 for the inbound IPsec SA in
A and SPIb2 for the inbound IPsec SA in B. The value of the A and SPIb2 for the inbound IPsec SA in B. The value of the
SPIa1 MUST NOT be the same as any inbound SPI in A. In the same SPIa1 MUST NOT be the same as any inbound SPI in A. In the same
way, the value of the SPIb1 MUST NOT be the same as any inbound way, the value of the SPIb1 MUST NOT be the same as any inbound
SPI in B. Then, the I2NSF Controller creates an inbound IPsec SA SPI in B. Then, the I2NSF Controller creates an inbound IPsec SA
with SPIa2 in A and another inbound IPsec SA in B with SPIb2. It with SPIa2 in A and another inbound IPsec SA in B with SPIb2. It
can send this information simultaneously to A and B. can send this information simultaneously to A and B.
2. Once the I2NSF Controller receives confirmation from A and B, the 2. Once the I2NSF Controller receives confirmation from A and B, the
controller knows that the inbound IPsec SAs are correctly controller knows that the inbound IPsec SAs are correctly
installed. Then it proceeds to send in parallel to A and B, the installed. Then, it proceeds to send, in parallel to A and B,
outbound IPsec SAs: the outbound IPsec SA to A with SPIb2, and the outbound IPsec SAs: the outbound IPsec SA to A with SPIb2 and
the outbound IPsec SA to B with SPIa2. At this point the new the outbound IPsec SA to B with SPIa2. At this point, the new
IPsec SAs are ready. IPsec SAs are ready.
3. Once the I2NSF Controller receives confirmation from A and B that 3. Once the I2NSF Controller receives confirmation from A and B that
the outbound IPsec SAs have been installed, the I2NSF Controller, the outbound IPsec SAs have been installed, the I2NSF Controller,
in parallel, deletes the old IPsec SAs from A (inbound SPIa1 and in parallel, deletes the old IPsec SAs from A (inbound SPIa1 and
outbound SPIb1) and B (outbound SPIa1 and inbound SPIb1). outbound SPIb1) and B (outbound SPIa1 and inbound SPIb1).
If some of the operations in step 1 fail (e.g., the NSF A reports an If some of the operations in step 1 fail (e.g., NSF A reports an
error when the I2NSF Controller is trying to install a new inbound error when the I2NSF Controller is trying to install a new inbound
IPsec SA) the I2NSF Controller MUST perform rollback operations by IPsec SA), the I2NSF Controller MUST perform rollback operations by
removing any new inbound SA that had been successfully installed removing any new inbound SA that had been successfully installed
during step 1. during step 1.
If step 1 is successful but some of the operations in step 2 fail If step 1 is successful but some of the operations in step 2 fail
(e.g., the NSF A reports an error when the I2NSF Controller is trying (e.g., NSF A reports an error when the I2NSF Controller is trying to
to install the new outbound IPsec SA), the I2NSF Controller MUST install the new outbound IPsec SA), the I2NSF Controller MUST perform
perform a rollback operation by deleting any new outbound SA that had a rollback operation by deleting any new outbound SA that had been
been successfully installed during step 2 and by deleting the inbound successfully installed during step 2 and by deleting the inbound SAs
SAs created in step 1, in that order. created in step 1, in that order.
If the steps 1 and 2 are successful but the step 3 fails, the I2NSF If the steps 1 and 2 are successful but the step 3 fails, the I2NSF
Controller will avoid any rollback of the operations carried out in Controller will avoid any rollback of the operations carried out in
step 1 and step 2 since new and valid IPsec SAs were created and are steps 1 and 2, since new and valid IPsec SAs were created and are
functional. The I2NSF Controller MAY reattempt to remove the old functional. The I2NSF Controller MAY reattempt to remove the old
inbound and outbound IPsec SAs in NSF A and NSF B several times until inbound and outbound IPsec SAs in NSF A and NSF B several times until
it receives a success or it gives up. In the last case, the old it receives a success or it gives up. In the last case, the old
IPsec SAs will be removed when their corresponding hard lifetime is IPsec SAs will be removed when their corresponding hard lifetime is
reached. reached.
D.3. Example of managing NSF state loss in IKE-less case D.3. Example of Managing NSF State Loss in the IKE-less Case
In the IKE-less case, if the I2NSF Controller detects that a NSF has In the IKE-less case, if the I2NSF Controller detects that an NSF has
lost the IPsec state, it could follow the next steps: lost the IPsec state, it could follow the next steps:
1. The I2NSF Controller SHOULD delete the old IPsec SAs on the non- 1. The I2NSF Controller SHOULD delete the old IPsec SAs on the non-
failed nodes, established with the failed node. This prevents failed nodes, established with the failed node. This prevents
the non-failed nodes from leaking plaintext. the non-failed nodes from leaking plaintext.
2. If the affected node restarts, the I2NSF Controller configures 2. If the affected node restarts, the I2NSF Controller configures
the new inbound IPsec SAs between the affected node and all the the new inbound IPsec SAs between the affected node and all the
nodes it was talking to. nodes it was talking to.
3. After these inbound IPsec SAs have been established, the I2NSF 3. After these inbound IPsec SAs have been established, the I2NSF
Controller configures the outbound IPsec SAs in parallel. Controller configures the outbound IPsec SAs in parallel.
Step 2 and step 3 can be performed at the same time at the cost of a Steps 2 and 3 can be performed at the same time at the cost of a
potential packet loss. If this is not critical then it is an potential packet loss. If this is not critical, then it is an
optimization since the number of exchanges between I2NSF Controller optimization since the number of exchanges between the I2NSF
and NSFs is lower. Controller and NSFs is lower.
Acknowledgements
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.
Authors' Addresses Authors' Addresses
Rafa Marin-Lopez Rafa Marin-Lopez
University of Murcia University of Murcia
Campus de Espinardo S/N, Faculty of Computer Science Faculty of Computer Science
Murcia 30100 Campus de Espinardo S/N
30100 Murcia
Spain Spain
Phone: +34 868 88 85 01 Phone: +34 868 88 85 01
EMail: rafa@um.es Email: rafa@um.es
Gabriel Lopez-Millan Gabriel Lopez-Millan
University of Murcia University of Murcia
Campus de Espinardo S/N, Faculty of Computer Science Faculty of Computer Science
Murcia 30100 Campus de Espinardo S/N
30100 Murcia
Spain Spain
Phone: +34 868 88 85 04 Phone: +34 868 88 85 04
EMail: gabilm@um.es Email: gabilm@um.es
Fernando Pereniguez-Garcia Fernando Pereniguez-Garcia
University Defense Center University Defense Center
Spanish Air Force Academy, MDE-UPCT Spanish Air Force Academy
San Javier (Murcia) 30720 MDE-UPCT
30720 San Javier Murcia
Spain Spain
Phone: +34 968 18 99 46 Phone: +34 968 18 99 46
EMail: fernando.pereniguez@cud.upct.es Email: fernando.pereniguez@cud.upct.es
 End of changes. 505 change blocks. 
2571 lines changed or deleted 2613 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/