draft-ietf-i2nsf-sdn-ipsec-flow-protection-08.txt   draft-ietf-i2nsf-sdn-ipsec-flow-protection-09.txt 
I2NSF R. Marin-Lopez I2NSF R. Marin-Lopez
Internet-Draft G. Lopez-Millan Internet-Draft G. Lopez-Millan
Intended status: Standards Track University of Murcia Intended status: Standards Track University of Murcia
Expires: December 19, 2020 F. Pereniguez-Garcia Expires: April 15, 2021 F. Pereniguez-Garcia
University Defense Center University Defense Center
June 17, 2020 October 12, 2020
Software-Defined Networking (SDN)-based IPsec Flow Protection Software-Defined Networking (SDN)-based IPsec Flow Protection
draft-ietf-i2nsf-sdn-ipsec-flow-protection-08 draft-ietf-i2nsf-sdn-ipsec-flow-protection-09
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 I2NSF Controller. It (integrity and confidentiality) by means of an Interface to Network
considers two main well-known scenarios in IPsec: (i) gateway-to- Security Function (I2NSF) controller. It considers two main well-
gateway and (ii) host-to-host. The service described in this known scenarios in IPsec: (i) gateway-to-gateway and (ii) host-to-
document allows the configuration and monitoring of IPsec information host. The service described in this document allows the
configuration and monitoring of IPsec Security Associations (SAs)
from a I2NSF Controller to one or several flow-based Network Security from a I2NSF Controller to one or several flow-based Network Security
Function (NSF) that implement IPsec to protect data traffic. Functions (NSFs) that rely on IPsec to protect data traffic.
The document focuses on the I2NSF NSF-Facing Interface by providing The document focuses on the I2NSF NSF-facing interface by providing
YANG data models for configuration and state data required to allow YANG data models for configuring the IPsec databases (SPD, SAD, PAD)
the I2NSF Controller to configure the IPsec databases (SPD, SAD, PAD) and IKEv2. This allows IPsec SA establishment with minimal
and IKEv2 to establish IPsec Security Associations with a reduced intervention by the network administrator. It does not define any
intervention of the network administrator. new protocol.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 19, 2020. This Internet-Draft will expire on April 15, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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
skipping to change at page 2, line 33 skipping to change at page 2, line 33
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. SDN-based IPsec management description . . . . . . . . . . . 6 4. SDN-based IPsec management description . . . . . . . . . . . 6
4.1. IKE case: IKEv2/IPsec in the NSF . . . . . . . . . . . . 6 4.1. IKE case: IKEv2/IPsec in the NSF . . . . . . . . . . . . 6
4.2. IKE-less case: IPsec (no IKEv2) in the NSF. . . . . . . . 7 4.2. IKE-less case: IPsec (no IKEv2) in the NSF. . . . . . . . 7
5. IKE case vs IKE-less case . . . . . . . . . . . . . . . . . . 9 5. IKE case vs IKE-less case . . . . . . . . . . . . . . . . . . 9
5.1. Rekeying process . . . . . . . . . . . . . . . . . . . . 10 5.1. Rekeying process . . . . . . . . . . . . . . . . . . . . 10
5.2. NSF state loss. . . . . . . . . . . . . . . . . . . . . . 11 5.2. NSF state loss. . . . . . . . . . . . . . . . . . . . . . 11
5.3. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 11 5.3. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 11
5.4. NSF registration and discovery . . . . . . . . . . . . . 12 5.4. NSF registration and discovery . . . . . . . . . . . . . 12
6. YANG configuration data models . . . . . . . . . . . . . . . 13 6. YANG configuration data models . . . . . . . . . . . . . . . 12
6.1. IKE case model . . . . . . . . . . . . . . . . . . . . . 13 6.1. IKE case model . . . . . . . . . . . . . . . . . . . . . 13
6.2. IKE-less case model . . . . . . . . . . . . . . . . . . . 16 6.2. IKE-less case model . . . . . . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
8.1. IKE case . . . . . . . . . . . . . . . . . . . . . . . . 22 8.1. IKE case . . . . . . . . . . . . . . . . . . . . . . . . 23
8.2. IKE-less case . . . . . . . . . . . . . . . . . . . . . . 23 8.2. IKE-less case . . . . . . . . . . . . . . . . . . . . . . 24
8.3. YANG modules . . . . . . . . . . . . . . . . . . . . . . 23 8.3. YANG modules . . . . . . . . . . . . . . . . . . . . . . 24
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
10.1. Normative References . . . . . . . . . . . . . . . . . . 25 10.1. Normative References . . . . . . . . . . . . . . . . . . 26
10.2. Informative References . . . . . . . . . . . . . . . . . 26 10.2. Informative References . . . . . . . . . . . . . . . . . 29
Appendix A. Common YANG model for IKE and IKE-less cases . . . . 29 Appendix A. Common YANG model for IKE and IKE-less cases . . . . 31
Appendix B. YANG model for IKE case . . . . . . . . . . . . . . 42 Appendix B. YANG model for IKE case . . . . . . . . . . . . . . 46
Appendix C. YANG model for IKE-less case . . . . . . . . . . . . 61 Appendix C. YANG model for IKE-less case . . . . . . . . . . . . 65
Appendix D. XML configuration example for IKE case (gateway-to- Appendix D. XML configuration example for IKE case (gateway-to-
gateway) . . . . . . . . . . . . . . . . . . . . . . 71 gateway) . . . . . . . . . . . . . . . . . . . . . . 76
Appendix E. XML configuration example for IKE-less case (host- Appendix E. XML configuration example for IKE-less case (host-
to-host) . . . . . . . . . . . . . . . . . . . . . . 75 to-host) . . . . . . . . . . . . . . . . . . . . . . 79
Appendix F. XML notification examples . . . . . . . . . . . . . 79 Appendix F. XML notification examples . . . . . . . . . . . . . 84
Appendix G. Operational use cases examples . . . . . . . . . . . 80 Appendix G. Operational use cases examples . . . . . . . . . . . 85
G.1. Example of IPsec SA establishment . . . . . . . . . . . . 80 G.1. Example of IPsec SA establishment . . . . . . . . . . . . 85
G.1.1. IKE case . . . . . . . . . . . . . . . . . . . . . . 81 G.1.1. IKE case . . . . . . . . . . . . . . . . . . . . . . 86
G.1.2. IKE-less case . . . . . . . . . . . . . . . . . . . . 83 G.1.2. IKE-less case . . . . . . . . . . . . . . . . . . . . 88
G.2. Example of the rekeying process in IKE-less case . . . . 85 G.2. Example of the rekeying process in IKE-less case . . . . 90
G.3. Example of managing NSF state loss in IKE-less case . . . 86 G.3. Example of managing NSF state loss in IKE-less case . . . 91
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 91
1. Introduction 1. Introduction
Software-Defined Networking (SDN) is an architecture that enables Software-Defined Networking (SDN) is an architecture that enables
users to directly program, orchestrate, control and manage network users to directly program, orchestrate, control and manage network
resources through software. The SDN paradigm relocates the control resources through software. The SDN paradigm relocates the control
of network resources to a centralized entity, namely SDN Controller. of network resources to a centralized entity, namely SDN Controller.
The SDN controller manages and configures the distributed network SDN controllers configure and manage distributed network resources
resources and provides an abstracted view of the network resources to and provide an abstracted view of the network resources to SDN
the SDN applications. The SDN application can customize and automate applications. SDN applications can customize and automate the
the operations (including management) of the abstracted network operations (including management) of the abstracted network resources
resources in a programmable manner via this interface [RFC7149] in a programmable manner via this interface [RFC7149] [ITU-T.Y.3300]
[ITU-T.Y.3300] [ONF-SDN-Architecture] [ONF-OpenFlow]. [ONF-SDN-Architecture] [ONF-OpenFlow].
Recently, several network scenarios are demanding a centralized way Recently, several network scenarios now demand a centralized way of
of managing different security aspects. For example, Software- managing different security aspects. For example, Software-Defined
Defined WANs (SD-WAN), an SDN extension providing a software WANs (SD-WANs). SD-WANs are an SDN extension providing a software
abstraction to create secure network overlays over traditional WAN abstraction to create secure network overlays over traditional WAN
and branch networks. SD-WAN is based on IPsec [RFC4301] as an and branch networks. SD-WANs utilize IPsec [RFC4301] as an
underlying security protocol and aims to provide flexible, automated, underlying security protocol. The goal of SD-WANs is to provide
and rapid deployment, enabling on-demand security network services, flexible and automated deployment from a centralized point to enable
such as IPsec Security Association (IPsec SA) management, from a on-demand network security services such as IPsec Security
centralized point. Additionally, Section 4.3.3 in [RFC8192] Association (IPsec SA) management. Additionally, Section 4.3.3 in
describes another example, a use case for Cloud Data Center Scenario, [RFC8192] describes another example use case for Cloud Data Center
entitled Client-Specific Security Policy in Cloud VPNs, where "the Scenario titled "Client-Specific Security Policy in Cloud VPNs". The
dynamic key management is critical for securing the VPN and the use case in RFC 8192 states that "dynamic key management is critical
distribution of policies". These VPNs can be established using for securing the VPN and the distribution of policies". These VPNs
IPsec. The management of IPsec SAs in data centers using a can be established using IPsec. The management of IPsec SAs in data
centralized entity is also an scenario of interest. centers using a centralized entity is a scenario where the current
specification maybe 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 data models for controlling and define set of software interfaces and data models for controlling and
monitoring aspects of physical and virtual Network Security monitoring aspects of physical and virtual Network Security
skipping to change at page 4, line 50 skipping to change at page 4, line 51
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 into the NSF. Therefore, the NSF will have only support for SAD into the NSF. Therefore, the NSF will have only support for
IPsec while key management functionality is moved to the I2NSF IPsec while key management functionality is moved to the I2NSF
Controller. Controller.
In both cases, a data model for the I2NSF NSF-Facing interface is In both cases, a data model for the I2NSF NSF-Facing interface is
required to carry out this provisioning in a secure manner between required to carry out this provisioning in a secure manner between
the I2NSF Controller and the NSF. Based on YANG models in the I2NSF Controller and the NSF. Using YANG data modelling language
[netconf-vpn] and [I-D.tran-ipsecme-yang], RFC 4301 [RFC4301] and RFC version 1.1 [RFC7950] and based on YANG models defined in
[netconf-vpn], [I-D.tran-ipsecme-yang], RFC 4301 [RFC4301] and RFC
7296 [RFC7296], this document defines the required interfaces with a 7296 [RFC7296], this document defines the required interfaces with a
YANG model for configuration and state data for IKE, PAD, SPD and SAD YANG model for configuration and state data for IKE, PAD, SPD and SAD
(see Appendix A, Appendix B and Appendix C). Examples of the usage (see Appendix A, Appendix B and Appendix C). The proposed YANG data
of these models can be found in Appendix D, Appendix E and model conforms to the Network Management Datastore Architecture
Appendix F. (NMDA) defined in [RFC8342]. Examples of the usage of these models
can be found in Appendix D, Appendix E and Appendix F.
In summary, the objetives of this I-D are: In summary, the objetives of this I-D are:
o To describe the architecture for the I2NSF-based IPsec management, o To describe the architecture for the I2NSF-based IPsec management,
which allows the establishment and management of IPsec security which allows the establishment and management of IPsec security
associations from the I2NSF Controller in order to protect associations from the I2NSF Controller in order to protect
specific data flows between two flow-based NSFs implementing specific data flows between two flow-based NSFs implementing
IPsec. IPsec.
o To map this architecture to the I2NSF Framework. o To map this architecture to the I2NSF Framework.
o To define the interfaces required to manage and monitor the IPsec o 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 a 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. management through the I2NSF NSF-Facing interface. Thus, this I-D
does not define any new protocol.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC "OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119]. When these words appear in lower case, they have 2119 [RFC2119]. When these words appear in lower case, they have
their natural language meaning. their natural language meaning.
3. Terminology 3. Terminology
This document uses the terminology described in [RFC8329], [RFC8192], This document uses the terminology described in [RFC8329], [RFC8192],
[RFC4301],[RFC7296], [RFC6241], [ITU-T.Y.3300], The following term is [RFC4301],[RFC7296], [RFC6241], [ITU-T.Y.3300]. The following term
defined in [ITU-T.Y.3300]: is defined in [ITU-T.Y.3300]:
o Software-Defined Networking. o Software-Defined Networking.
The following terms are in defined in [RFC8192]: The following terms are in defined in [RFC8192]:
o NSF. o NSF.
o Flow-based NSF. o Flow-based NSF.
The following terms are defined in [RFC4301]: The following terms are defined in [RFC4301]:
skipping to change at page 6, line 30 skipping to change at page 6, line 34
o State date. o State date.
o Startup configuration datastore. o Startup configuration datastore.
o Running configuration datastore. o Running configuration datastore.
4. SDN-based IPsec management description 4. 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 ships an IKEv2 implementation or not: IKE case and whether the NSF implements IKEv2 or not: IKE case and IKE-less case.
IKE-less case.
4.1. IKE case: IKEv2/IPsec in the NSF 4.1. IKE case: IKEv2/IPsec in the NSF
In this case, the NSF ships an IPsec implementation with IKEv2 In this case, the NSF implements IPsec with IKEv2 support. The I2NSF
support. The I2NSF Controller is in charge of managing and applying Controller is in charge of managing and applying IPsec connection
IPsec connection information (determining which nodes need to start information (determining which nodes need to start an IKEv2/IPsec
an IKEv2/IPsec session, identifying the type of traffic to be session, identifying the type of traffic to be protected, deriving
protected, deriving and delivering IKEv2 Credentials such as a pre- and delivering IKEv2 Credentials such as a pre-shared key,
shared key, certificates, etc.), and applying other IKEv2 certificates, etc.), and applying other IKEv2 configuration
configuration parameters (e.g. cryptographic algorithms for parameters (e.g. cryptographic algorithms for establishing an IKEv2
establishing an IKEv2 SA) to the NSF necessary for the IKEv2 SA) to the NSF necessary for the IKEv2 negotiation.
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 information (through the I2NSF information about the end points information (through the I2NSF
Consumer-Facing Interface, [RFC8329]), and the I2NSF Controller Consumer-Facing Interface, [RFC8329]), and the I2NSF Controller
translates these requirements into IKEv2, SPD and PAD entries that translates these requirements into IKEv2, SPD and PAD entries that
will be installed into the NSF (through the I2NSF NSF-Facing will be installed into the NSF (through the I2NSF NSF-Facing
Interface). With that information, the NSF can just run IKEv2 to Interface). With that information, the NSF can just run IKEv2 to
establish the required IPsec SA (when the traffic flow needs establish the required IPsec SA (when the traffic flow needs
protection). Figure 1 shows the different layers and corresponding protection). Figure 1 shows the different layers and corresponding
skipping to change at page 12, line 5 skipping to change at page 12, line 5
5.3. NAT Traversal 5.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. If there is a some of the peers or both are located behind a NAT. If there is a
NAT network configured between two peers, it is required to activate NAT network configured between two peers, it is required to activate
the usage of UDP or TCP/TLS encapsulation for ESP packets ([RFC3948], the usage of UDP or TCP/TLS encapsulation for ESP packets ([RFC3948],
[RFC8229]). Note that the usage of IPsec transport mode when NAT is [RFC8229]). Note that the usage of IPsec transport mode when NAT is
required MUST NOT be used in this specification. required MUST NOT be used in this specification.
In the IKE case, IKEv2 already provides a mechanism to detect whether
some of the peers or both are located behind a NAT. If there is a
NAT network configured between two peers, it is required to activate
the usage of UDP or TCP/TLS encapsulation for ESP packets ([RFC3948],
[RFC8229]). Note that the usage of IPsec transport mode when NAT is
required MUST NOT be used in this specification.
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 requesting the network under its control. This view is built either by
information to the NSFs under its control, or because these NSFs requesting information from the NSFs under its control, or by
inform the I2NSF Controller. Based on this information, the I2NSF information pushed from the NSFs to the I2NSF Controller. Based on
Controller MAY guess if there is a NAT configured between two hosts, this information, the I2NSF Controller MAY guess if there is a NAT
and apply the required policies to both NSFs besides activating the configured between two hosts, and apply the required policies to both
usage of UDP or TCP/TLS encapsulation of ESP packets ([RFC3948], NSFs besides activating the usage of UDP or TCP/TLS encapsulation of
[RFC8229]). The interface for discovering if the NSF is behind a NAT ESP packets ([RFC3948], [RFC8229]). The interface for discovering if
is out of scope of this document. the 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 5.4. NSF registration and discovery
NSF registration refers to the process of facilitating the I2NSF NSF registration refers to the process of facilitating 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 to 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 a NSF
can operate in this system, it MUST be registered in the I2NSF 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 is the cryptographic suite capabilities of this NSF, such as what is the cryptographic suite
skipping to change at page 13, line 12 skipping to change at page 12, line 52
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 6. YANG configuration data models
In order to support the IKE and IKE-less cases we have modeled the In order to support the IKE and IKE-less cases we have modeled the
different parameters and values that must be configured to manage different parameters and values that must be configured to manage
IPsec SAs. Specifically, the IKE case requires modeling IKEv2 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 models for the SPD and SAD. We have defined requires configuration models for the SPD and SAD. We have defined
three models: ietf-ipsec-common (Appendix A), ietf-ipsec-ike three models: ietf-i2nsf-ikec (Appendix A, common to both cases),
(Appendix B, IKE case), ietf-ipsec-ikeless (Appendix C, IKE-less ietf-i2nsf-ike (Appendix B, IKE case), ietf-i2nsf-ikeless
case). Since the model ietf-ipsec-common has only typedef and (Appendix C, IKE-less case). Since the model ietf-i2nsf-ikec has
groupings common to the other modules, we only show a simplified view only typedef and groupings common to the other modules, we only show
of the ietf-ipsec-ike and ietf-ipsec-ikeless models. a simplified view of the ietf-i2nsf-ike and ietf-i2nsf-ikeless
models.
6.1. IKE case model 6.1. IKE case model
The model related to IKEv2 has been extracted from reading IKEv2 The model related to IKEv2 has been extracted from reading IKEv2
standard in [RFC7296], and observing some open source standard in [RFC7296], and observing some open source
implementations, such as Strongswan [strongswan] or Libreswan implementations, 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: We have observed specification in section 4.4.3 in [RFC4301] (NOTE: We have observed
that many implementations integrate PAD configuration as part of the that many implementations integrate PAD configuration as part of the
IKEv2 configuration). IKEv2 configuration).
module: ietf-ipsec-ike The data model for the IKE case is defined by YANG model "ietf-i2nsf-
+--rw ipsec-ike ike". Its structure is depicted in the following diagram, using the
notation syntax for YANG tree diagrams ([RFC8340]).
module: ietf-i2nsf-ike
+--rw ipsec-ike
+--rw pad +--rw pad
| +--rw pad-entry* [name] | +--rw pad-entry* [name]
| +--rw name string | +--rw name string
| +--rw (identity) | +--rw (identity)
| | +--:(ipv4-address) | | +--:(ipv4-address)
| | | +--rw ipv4-address? inet:ipv4-address | | | +--rw ipv4-address? inet:ipv4-address
| | +--:(ipv6-address) | | +--:(ipv6-address)
| | | +--rw ipv6-address? inet:ipv6-address | | | +--rw ipv6-address? inet:ipv6-address
| | +--:(fqdn-string) | | +--:(fqdn-string)
| | | +--rw fqdn-string? inet:domain-name | | | +--rw fqdn-string? inet:domain-name
skipping to change at page 14, line 6 skipping to change at page 13, line 50
| | +--:(dnx509) | | +--:(dnx509)
| | | +--rw dnx509? string | | | +--rw dnx509? string
| | +--:(gnx509) | | +--:(gnx509)
| | | +--rw gnx509? string | | | +--rw gnx509? string
| | +--:(id-key) | | +--:(id-key)
| | | +--rw id-key? string | | | +--rw id-key? string
| | +--:(id-null) | | +--:(id-null)
| | +--rw id-null? empty | | +--rw id-null? empty
| +--rw auth-protocol? auth-protocol-type | +--rw auth-protocol? auth-protocol-type
| +--rw peer-authentication | +--rw peer-authentication
| +--rw auth-method? auth-method-type | +--rw auth-method? auth-method-type
| +--rw eap-method | +--rw eap-method
| | +--rw eap-type uint8 | | +--rw eap-type uint8
| +--rw pre-shared | +--rw pre-shared
| | +--rw secret? yang:hex-string | | +--rw secret yang:hex-string
| +--rw digital-signature | +--rw digital-signature
| +--rw ds-algorithm? uint8 | +--rw ds-algorithm? uint8
| +--rw (public-key) | +--rw (public-key)
| | +--:(raw-public-key) | | +--:(raw-public-key)
| | | +--rw raw-public-key? binary | | | +--rw raw-public-key? binary
| | +--:(cert-data) | | +--:(cert-data)
| | +--rw cert-data? ct:x509 | | +--rw cert-data? ct:x509
| +--rw private-key? binary | +--rw private-key? binary
| +--rw ca-data* ct:x509 | +--rw ca-data* ct:x509
| +--rw crl-data? ct:crl | +--rw crl-data? ct:crl
| +--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? boolean | +--rw fragmentation? boolean
| +--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 authalg* ic:integrity-algorithm-type | +--rw authalg* ic:integrity-algorithm-type
| +--rw encalg* ic:encryption-algorithm-type | +--rw encalg* [id]
| | +--rw id uint8
| | +--rw algorithm-type? ic:encryption-algorithm-type
| | +--rw key-length? uint16
| +--rw dh-group? pfs-group | +--rw dh-group? pfs-group
| +--rw half-open-ike-sa-timer? uint32 | +--rw half-open-ike-sa-timer? uint32
| +--rw half-open-ike-sa-cookie-threshold? uint32 | +--rw half-open-ike-sa-cookie-threshold? uint32
| +--rw local | +--rw local
| | +--rw local-pad-entry-name? string | | +--rw local-pad-entry-name string
| +--rw remote | +--rw remote
| | +--rw remote-pad-entry-name? string | | +--rw remote-pad-entry-name string
| +--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
| +--rw spd | +--rw spd
| | +--rw spd-entry* [name] | | +--rw spd-entry* [name]
| | +--rw name string | | +--rw name string
| | +--rw ipsec-policy-config | | +--rw ipsec-policy-config
| | +--rw anti-replay-window? uint64 | | +--rw anti-replay-window? uint64
| | +--rw traffic-selector | | +--rw traffic-selector
| | | +--rw local-subnet inet:ip-prefix | | | +--rw local-subnet inet:ip-prefix
| | | +--rw remote-subnet inet:ip-prefix | | | +--rw remote-subnet 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-parameters
| | | +--rw esp-algorithms | | | +--rw esp-algorithms
| | | | +--rw integrity* integrity-algorithm-type | | | | +--rw integrity* integrity-algorithm-type
| | | | +--rw encryption* encryption-algorithm-type | | | | +--rw encryption* [id]
| | | | +--rw tfc-pad? boolean | | | | | +--rw id uint8
| | | +--rw tunnel | | | | | +--rw algorithm-type? ic:encryption-algorithm-type
| | | +--rw local inet:ip-address | | | | | +--rw key-length? uint16
| | | +--rw remote inet:ip-address | | | | +--rw tfc-pad? boolean
| | | +--rw df-bit? enumeration | | | +--rw tunnel
| | | +--rw bypass-dscp? boolean | | | +--rw local inet:ip-address
| | | +--rw dscp-mapping? yang:hex-string | | | +--rw remote inet:ip-address
| | | +--rw ecn? boolean | | | +--rw df-bit? enumeration
| | +--rw spd-mark | | | +--rw bypass-dscp? boolean
| | +--rw mark? uint32 | | | +--rw dscp-mapping? yang:hex-string
| | +--rw mask? yang:hex-string | | | +--rw ecn? boolean
| | +--rw spd-mark
| | +--rw mark? uint32
| | +--rw mask? yang:hex-string
| +--rw child-sa-info | +--rw child-sa-info
| | +--rw pfs-groups* pfs-group | | +--rw pfs-groups* pfs-group
| | +--rw child-sa-lifetime-soft | | +--rw child-sa-lifetime-soft
| | | +--rw time? uint32 | | | +--rw time? uint32
| | | +--rw bytes? uint32 | | | +--rw bytes? uint32
| | | +--rw packets? uint32 | | | +--rw packets? uint32
| | | +--rw idle? uint32 | | | +--rw idle? uint32
| | | +--rw action? ic:lifetime-action | | | +--rw action? ic:lifetime-action
| | +--rw child-sa-lifetime-hard | | +--rw child-sa-lifetime-hard
| | +--rw time? uint32 | | +--rw time? uint32
skipping to change at page 16, line 22 skipping to change at page 16, line 25
| | +--ro dport? inet:port-number | | +--ro dport? inet:port-number
| | +--ro oaddr* inet:ip-address | | +--ro oaddr* inet:ip-address
| +--ro established? uint64 | +--ro established? uint64
| +--ro current-rekey-time? uint64 | +--ro current-rekey-time? uint64
| +--ro current-reauth-time? uint64 | +--ro current-reauth-time? uint64
+--ro number-ike-sas +--ro number-ike-sas
+--ro total? uint64 +--ro total? uint64
+--ro half-open? uint64 +--ro half-open? uint64
+--ro half-open-cookies? uint64 +--ro half-open-cookies? uint64
The data model consists of a unique "ipsec-ike" container defined as
follows. Firstly, it contains a "pad" container that serves to
configure the Peer Authentication Database with authentication
information about local and remote peers. More precisely, it
consists of a list of entries, each one indicating the identity,
authentication method and credentials that will use a particular
peer.
Next, we find a list "conn-entry" with information about the
different IKE connections a peer can maintain with others. Each
connection entry is composed of a wide number of parameters to
configure different aspects of a particular IKE connection between
two peers: local and remote peer authentication information; IKE SA
configuration (soft and hard lifetimes, cryptographic algorithms,
etc.); list of IPsec policies describing the type of network traffic
to be secured (local/remote subnet and ports, etc.) and how must be
protected (AH/ESP, tunnel/transport, cryptographic algorithms, etc.);
CHILD SA configuration (soft and hard lifetimes); and, state
information of the IKE connection (SPIs, usage of NAT, current
expiration times, etc.).
Lastly, the "ipsec-ike" container declares a "number-ike-sas"
container to specify state information reported by the IKE software
related to the amount of IKE connections established.
Appendix D shows an example of IKE case configuration for a NSF, in Appendix D shows an example of IKE case configuration for a NSF, in
tunnel mode (gateway-to-gateway), with NSFs authentication based on tunnel mode (gateway-to-gateway), with NSFs authentication based on
X.509 certificates. X.509 certificates.
6.2. IKE-less case model 6.2. IKE-less case model
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 Each IPsec policy (spd-entry) contains one traffic selector, o Each IPsec policy (spd-entry) contains one traffic selector,
instead of a list of them. The reason is that we have observed instead of a list of them. The reason is that we have observed
actual kernel implementations only admit a single traffic selector actual kernel implementations only admit a single traffic selector
per IPsec policy. per IPsec policy.
o Each IPsec policy contains a identifier (reqid) to relate the o Each IPsec policy contains a 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. o Each IPsec policy has only one name and not a list of names.
o Combined algorithms has been removed because encryption algorithms o Combined algorithms have been removed because encryption
MAY include authenticated encryption with associated data (AEAD). algorithms MAY include authenticated encryption with associated
data (AEAD).
o Tunnel information has been extended with information about DSCP o Tunnel information has been extended with information about DSCP
mapping and ECN bit. The reason is that we have observed real mapping and ECN bit. The reason is that we have observed real
kernel implementations admit the configurations of these values. kernel implementations accept 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 in [RFC4301] though with some changes,
namely: namely:
o Each IPsec SA (sad-entry) contains one traffic selector, instead o Each IPsec SA (sad-entry) contains one traffic selector, instead
of a list of them. The reason is that we have observed actual of a list of them. The reason is that we have observed actual
kernel implementations only admit a single traffic selector per kernel implementations only admit a single traffic selector per
IPsec SA. IPsec SA.
skipping to change at page 17, line 41 skipping to change at page 18, line 20
we have observed actual kernel implementations allow to set these we have observed actual kernel implementations allow to set these
types of lifetimes. types of lifetimes.
o Information to configure the type of encapsulation (encapsulation- o Information to configure the type of encapsulation (encapsulation-
type) for IPsec ESP packets in UDP ([RFC3948]), TCP ([RFC8229]) or type) for IPsec ESP packets in UDP ([RFC3948]), TCP ([RFC8229]) or
TLS ([RFC8229]) has been included. TLS ([RFC8229]) has been included.
The notifications model has been defined using as reference the The notifications model has been defined using as reference the
PF_KEYv2 standard in [RFC2367]. PF_KEYv2 standard in [RFC2367].
module: ietf-ipsec-ikeless The data model for the IKE-less case is defined by YANG model "ietf-
i2nsf-ikeless". Its structure is depicted in the following diagram,
using the notation syntax for YANG tree diagrams ([RFC8340]).
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? ic:ipsec-traffic-direction | +--rw direction ic:ipsec-traffic-direction
| +--rw reqid? uint64 | +--rw reqid? uint64
| +--rw ipsec-policy-config | +--rw ipsec-policy-config
| +--rw anti-replay-window? uint64 | +--rw anti-replay-window? uint64
| +--rw traffic-selector | +--rw traffic-selector
| | +--rw local-subnet inet:ip-prefix | | +--rw local-subnet inet:ip-prefix
| | +--rw remote-subnet inet:ip-prefix | | +--rw remote-subnet 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? | | +--rw protocol-parameters? ipsec-protocol-parameters
| | +--rw esp-algorithms | | +--rw esp-algorithms
| | | +--rw integrity* integrity-algorithm-type | | | +--rw integrity* integrity-algorithm-type
| | | +--rw encryption* encryption-algorithm-type | | | +--rw encryption* [id]
| | | +--rw tfc-pad? boolean | | | | +--rw id uint8
| | +--rw tunnel | | | | +--rw algorithm-type?ic:encryption-algorithm-type
| | +--rw local inet:ip-address | | | | +--rw key-length? uint16
| | +--rw remote inet:ip-address | | | +--rw tfc-pad? boolean
| | +--rw df-bit? enumeration | | +--rw tunnel
| | +--rw bypass-dscp? boolean | | +--rw local inet:ip-address
| | +--rw dscp-mapping? yang:hex-string | | +--rw remote inet:ip-address
| | +--rw ecn? boolean | | +--rw df-bit? enumeration
| +--rw spd-mark | | +--rw bypass-dscp? boolean
| +--rw mark? uint32 | | +--rw dscp-mapping? yang:hex-string
| +--rw mask? yang:hex-string | | +--rw ecn? boolean
+--rw sad | +--rw spd-mark
+--rw sad-entry* [name] | +--rw mark? uint32
+--rw name string | +--rw mask? yang:hex-string
+--rw reqid? uint64 +--rw sad
+--rw ipsec-sa-config +--rw sad-entry* [name]
| +--rw spi uint32 +--rw name string
| +--rw ext-seq-num? boolean +--rw reqid? uint64
| +--rw seq-number-counter? uint64 +--rw ipsec-sa-config
| +--rw seq-overflow? boolean | +--rw spi uint32
| +--rw anti-replay-window? uint32 | +--rw ext-seq-num? boolean
| +--rw traffic-selector | +--rw seq-number-counter? uint64
| | +--rw local-subnet inet:ip-prefix | +--rw seq-overflow? boolean
| | +--rw remote-subnet inet:ip-prefix | +--rw anti-replay-window? uint32
| | +--rw inner-protocol? ipsec-inner-protocol | +--rw traffic-selector
| | +--rw local-ports* [start end] | | +--rw local-subnet inet:ip-prefix
| | | +--rw start inet:port-number | | +--rw remote-subnet inet:ip-prefix
| | | +--rw end inet:port-number | | +--rw inner-protocol? ipsec-inner-protocol
| | +--rw remote-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 protocol-parameters? ic:ipsec-protocol-parameters | | +--rw remote-ports* [start end]
| +--rw mode? ic:ipsec-mode | | +--rw start inet:port-number
| +--rw esp-sa | | +--rw end inet:port-number
| | +--rw encryption | +--rw protocol-parameters? ic:ipsec-protocol-parameters
| | | +--rw encryption-algorithm? ic:encryption-algorithm-type | +--rw mode? ic:ipsec-mode
| | | +--rw key? yang:hex-string | +--rw esp-sa
| | | +--rw iv? yang:hex-string | | +--rw encryption
| | +--rw integrity | | | +--rw encryption-algorithm? ic:encryption-algorithm-type
| | +--rw integrity-algorithm? ic:integrity-algorithm-type | | | +--rw key? yang:hex-string
| | +--rw key? yang:hex-string | | | +--rw iv? yang:hex-string
| +--rw sa-lifetime-hard | | +--rw integrity
| | +--rw time? uint32 | | +--rw integrity-algorithm? ic:integrity-algorithm-type
| | +--rw bytes? uint32 | | +--rw key? yang:hex-string
| | +--rw packets? uint32 | +--rw sa-lifetime-hard
| | +--rw idle? uint32 | | +--rw time? uint32
| +--rw sa-lifetime-soft | | +--rw bytes? uint32
| | +--rw time? uint32 | | +--rw packets? uint32
| | +--rw bytes? uint32 | | +--rw idle? uint32
| | +--rw packets? uint32 | +--rw sa-lifetime-soft
| | +--rw idle? uint32 | | +--rw time? uint32
| | +--rw action? ic:lifetime-action | | +--rw bytes? uint32
| +--rw tunnel | | +--rw packets? uint32
| | +--rw local inet:ip-address | | +--rw idle? uint32
| | +--rw remote inet:ip-address | | +--rw action? ic:lifetime-action
| | +--rw df-bit? enumeration | +--rw tunnel
| | +--rw bypass-dscp? boolean | | +--rw local inet:ip-address
| | +--rw dscp-mapping? yang:hex-string | | +--rw remote inet:ip-address
| | +--rw ecn? boolean | | +--rw df-bit? enumeration
| +--rw encapsulation-type | | +--rw bypass-dscp? boolean
| +--rw espencap? esp-encap | | +--rw dscp-mapping? yang:hex-string
| +--rw sport? inet:port-number | | +--rw ecn? boolean
| +--rw dport? inet:port-number | +--rw encapsulation-type
| +--rw oaddr* inet:ip-address | +--rw espencap? esp-encap
+--ro ipsec-sa-state | +--rw sport? inet:port-number
+--ro sa-lifetime-current | +--rw dport? inet:port-number
| +--ro time? uint32 | +--rw oaddr* inet:ip-address
| +--ro bytes? uint32 +--ro ipsec-sa-state
| +--ro packets? uint32 +--ro sa-lifetime-current
| +--ro idle? uint32 | +--ro time? uint32
+--ro replay-stats | +--ro bytes? uint32
+--ro replay-window? uint64 | +--ro packets? uint32
+--ro packet-dropped? uint64 | +--ro idle? uint32
+--ro failed? uint32 +--ro replay-stats
+--ro seq-number-counter? uint64 +--ro replay-window? uint64
+--ro packet-dropped? uint64
+--ro failed? uint32
+--ro seq-number-counter? uint64
notifications: notifications:
+---n sadb-acquire +---n sadb-acquire
| +--ro ipsec-policy-name string | +--ro ipsec-policy-name string
| +--ro traffic-selector | +--ro traffic-selector
| +--ro local-subnet inet:ip-prefix | +--ro local-subnet inet:ip-prefix
| +--ro remote-subnet inet:ip-prefix | +--ro remote-subnet 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 +---n sadb-expire
| +--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? uint32 | +--ro bytes? uint32
| +--ro packets? uint32 | +--ro packets? uint32
| +--ro idle? uint32 | +--ro idle? uint32
+---n sadb-seq-overflow +---n sadb-seq-overflow
| +--ro ipsec-sa-name string | +--ro ipsec-sa-name string
+---n sadb-bad-spi +---n sadb-bad-spi
+--ro spi uint32 +--ro spi uint32
The data model consists of a unique "ipsec-ikeless" container which,
in turn, is integrated by two additional containers: "spd" and "sad".
The "spd" container consists of a list of entries that conform the
Security Policy Database. Compared to the IKE case data model, this
part specifies a few additional parameters necessary due to the
absence of an IKE software in the NSF: traffic direction to apply the
IPsec policy, and a value to link an IPsec policy with its associated
IPsec SAs. The "sad" container is a list of entries that conform the
Security Association Database. In general, each entry allows to
specify both configuration information (SPI, traffic selectors,
tunnel/transport mode, cryptographic algorithms and keying material,
soft/hard lifetimes, etc.) as well as state information (time to
expire, replay statistics, etc.) of a concrete IPsec SA.
In addition, the module defines a set of notifications to allow the
NSF inform I2NSF controller about relevant events such as IPsec SA
expiration, sequence number overflow or bad SPI in a received packet.
Appendix E shows an example of IKE-less case configuration for a NSF, Appendix E shows an example of IKE-less case configuration for a NSF,
in transport mode (host-to-host), with NSFs authentication based on in transport mode (host-to-host), with NSFs authentication based on
shared secrets. For the IKE-less case, Appendix F shows examples of shared secrets. For the IKE-less case, Appendix F shows examples of
IPsec SA expire, acquire, sequence number overflow and bad SPI IPsec SA expire, acquire, sequence number overflow and bad SPI
notifications. notifications.
7. IANA Considerations 7. IANA Considerations
This document registers three URIs in the "ns" subregistry of the This document registers three URIs in the "ns" subregistry of the
IETF XML Registry [RFC3688]. Following the format in [RFC3688], the IETF XML Registry [RFC3688]. Following the format in [RFC3688], the
following registrations are requested: following registrations are requested:
URI: urn:ietf:params:xml:ns:yang:ietf-ipsec-common URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikec
Registrant Contact: The I2NSF WG of the IETF. 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-ipsec-ike URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-ike
Registrant Contact: The I2NSF WG of the IETF. 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-ipsec-ikeless URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless
Registrant Contact: The I2NSF WG of the IETF. 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" This document registers three YANG modules in the "YANG Module Names"
registry [RFC6020]. Following the format in [RFC6020], the following registry [RFC6020]. Following the format in [RFC6020], the following
registrations are requested: registrations are requested:
Name: ietf-ipsec-common Name: ietf-i2nsf-ikec
Namespace: urn:ietf:params:xml:ns:yang:ietf-ipsec-common Namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikec
Prefix: ic Prefix: ic
Reference: RFC XXXX Reference: RFC XXXX
Name: ietf-ipsec-ike Name: ietf-i2nsf-ike
Namespace: urn:ietf:params:xml:ns:yang:ietf-ipsec-ike Namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-ike
Prefix: ike Prefix: ike
Reference: RFC XXXX Reference: RFC XXXX
Name: ietf-ipsec-ikeless Name: ietf-i2nsf-ikeless
Namespace: urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless Namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless
Prefix: ikeless Prefix: ikeless
Reference: RFC XXXX Reference: RFC XXXX
8. Security Considerations 8. 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" section 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. parameter, etc.) exchanged between these entities.
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 a
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 pre-configured
in the startup configuration datastore in the NSF before the NSF in 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 pre-configured with the required ALLOW
policies that allow to communicate the NSF with the I2NSF Controller policies that allow the NSF to communicate with the I2NSF Controller
once the NSF is deployed. This pre-configuration step is not carried once the NSF is deployed. This pre-configuration step is not carried
out by the I2NSF Controller but by some other entity before the NSF out by 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, we have divided this section in two parts in order to Finally, we have divided this section in two parts in order to
analyze different security considerations for both cases: NSF with analyze different security considerations for both cases: NSF with
IKEv2 (IKE case) and NSF without IKEv2 (IKE-less case). In general, IKEv2 (IKE case) and NSF without IKEv2 (IKE-less case). In general,
the I2NSF Controller, as typically in the SDN paradigm, is a target the I2NSF Controller, as typically in the SDN paradigm, is a target
for different type of attacks [SDNSecServ] and [SDNSecurity]. Thus, for different type of attacks [SDNSecServ] and [SDNSecurity]. Thus,
the I2NSF Controller is a key entity in the infrastructure and MUST the I2NSF Controller is a key entity in the infrastructure and MUST
be protected accordingly. In particular, the I2NSF Controller will be protected accordingly. In particular, the I2NSF Controller will
handle cryptographic material so that the attacker may try to access handle cryptographic material thus the attacker may try to access
this information. Although we can assume this attack will not likely this information. Although we can assume this attack is not likely
to happen due to the assumed security measurements to protect the to happen due to the assumed security measurements to protect the
I2NSF Controller, it deserves some analysis in the hypothetical case I2NSF Controller, it still deserves some analysis in the hypothetical
the attack occurs. The impact is different depending on the IKE case case that the attack occurs. The impact is different depending on
or IKE-less case. the IKE case or IKE-less case.
8.1. IKE case 8.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 I2NSF Controller and NSFs. The I2NSF
Controller MUST NOT store the IKEv2 credentials after distributing Controller MUST NOT store the IKEv2 credentials after distributing
them. Moreover, the NSFs MUST NOT allow the reading of these values them. Moreover, the NSFs MUST NOT allow the reading of these values
once they have been applied by the I2NSF Controller (i.e. write only once they have been applied by the I2NSF Controller (i.e. write only
operations). One option is to always return the same value (i.e. all operations). One option is to always return the same value (i.e. all
skipping to change at page 23, line 8 skipping to change at page 24, line 8
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 o 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 could generate the private key and export only the public the NSF could generate the private key and export only the public
key to the I2NSF Controller. key to the I2NSF Controller.
o If certificates are used, the NSF MAY generate the private key and o If certificates are used, the NSF MAY generate the private key and
exports 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 it is out of scope of private keys) and exports the public key, is out of scope of this
this document. document.
8.2. IKE-less case 8.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.
8.3. YANG modules 8.3. YANG modules
The YANG module specified in this document defines a schema for data The YANG modules specified in this document defines a schema for data
that is designed to be accessed via network management protocols such that is designed to be accessed via network management protocols such
as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer
is 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:
The YANG modules describe configuration data for the IKE case (ietf- For the IKE case (ietf-i2nsf-ike):
ipsec-ike) and IKE-less case (ietf-ipsec-ikeless). There is a common
module (ietf-ipsec-common) used in both cases.
For the IKE case (ietf-ipsec-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 a NSF),
the trust root (e.g. changing the trusted CA certificates), the the trust root (e.g. changing the trusted CA certificates), the
cryptographic algorithms (allowing a downgrading attack), the cryptographic algorithms (allowing a downgrading attack), the
IPsec policies (e.g. by allowing leaking of data traffic by IPsec policies (e.g. by allowing leaking of data traffic by
changing to a allow policy), and in general changing the IKE SA changing to a allow policy), and in general changing the IKE SA
conditions and credentials between any NSF. conditions and credentials between any NSF.
For the IKE-less case (ietf-ipsec-ikeless): For the IKE-less case (ietf-i2nsf-ikeless):
/ipsec-ikeless: The entire container in this module is /ipsec-ikeless: The entire container in this module is
sensitive to write operations. An attacker may add/modify/ sensitive to write operations. An attacker may add/modify/
delete any IPsec policies (e.g. by allowing leaking of data delete any IPsec policies (e.g. by allowing leaking of data
traffic by changing to a allow policy) in the /ipsec-ikeless/ traffic by changing to a allow policy) in the /ipsec-ikeless/
spd container, and add/modify/delete any IPsec SAs between two spd container, and add/modify/delete any IPsec SAs between two
NSF by means of /ipsec-ikeless/sad container and, in general NSF by means of /ipsec-ikeless/sad container and, in general
changing any IPsec SAs and IPsec policies between any NSF. changing any IPsec SAs and IPsec policies between any NSF.
Some of the readable data nodes in this YANG module may be considered Some of the readable data nodes in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus sensitive or vulnerable in some network environments. It is thus
important to control read access (e.g., via get, get-config, or important to control read access (e.g., via get, get-config, or
notification) to these data nodes. These are the subtrees and data notification) to these data nodes. These are the subtrees and data
nodes and their sensitivity/vulnerability: nodes and their sensitivity/vulnerability:
For the IKE case (ietf-ipsec-ike): For the IKE case (ietf-i2nsf-ike):
/ipsec-ike/pad: This container includes sensitive information /ipsec-ike/pad: This container includes sensitive information
to read operations. This information should never be returned to read operations. This information should never be returned
to a client. For example, cryptographic material configured in to a client. For example, cryptographic material configured in
the NSFs: peer-authentication/pre-shared/secret and peer- the 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-ipsec-ikeless): For the IKE-less case (ietf-i2nsf-ikeless):
/ipsec-ikeless/sad/ipsec-sa-config/esp-sa: This container /ipsec-ikeless/sad/ipsec-sa-config/esp-sa: This container
includes symmetric keys for the IPsec SAs. For example, includes symmetric keys for the IPsec SAs. For example,
encryption/key contains a ESP encryption key value and encryption/key contains a ESP encryption key value and
encryption/iv contains a initialization vector value. encryption/iv contains a initialization vector value.
Similarly, integrity/key has ESP integrity key value. Those Similarly, integrity/key has 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 9. Acknowledgements
Authors want to thank Paul Wouters, Valery Smyslov, Sowmini Varadhan, Authors want to thank Paul Wouters, Valery Smyslov, Sowmini Varadhan,
David Carrel, Yoav Nir, Tero Kivinen, Martin Bjorklund, Graham David Carrel, Yoav Nir, Tero Kivinen, Martin Bjorklund, Graham
Bartlett, Sandeep Kampati, Linda Dunbar, Carlos J. Bernardos, Bartlett, Sandeep Kampati, Linda Dunbar, Mohit Sethi, Martin
Alejandro Perez-Mendez, Alejandro Abad-Carrascosa, Ignacio Martinez, Bjorklund, Tom Petch, Christian Hopps, Rob Wilton, Carlos J.
Ruben Ricart and Roman Danyliw for their valuable comments. Bernardos, Alejandro Perez-Mendez, Alejandro Abad-Carrascosa, Ignacio
Martinez, Ruben Ricart and Roman Danyliw for their valuable comments.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.draft-ietf-netconf-crypto-types]
Watsen, K., "YANG Data Types and Groupings for
Cryptography", draft-ietf-netconf-crypto-types-18 (work in
progress), August 2020.
[IKEv2-Parameters]
Internet Assigned Numbers Authority (IANA), "Internet Key
Exchange Version 2 (IKEv2) Parameters", August 2020.
[ITU-T.X.690]
"Recommendation ITU-T X.690", August 2015.
[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,
"Negotiation of NAT-Traversal in the IKE", RFC 3947,
DOI 10.17487/RFC3947, January 2005,
<https://www.rfc-editor.org/info/rfc3947>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>. December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[RFC5915] Turner, S. and D. Brown, "Elliptic Curve Private Key
Structure", RFC 5915, DOI 10.17487/RFC5915, June 2010,
<https://www.rfc-editor.org/info/rfc5915>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010, DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>. <https://www.rfc-editor.org/info/rfc6020>.
[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>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013,
<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
(IKEv2) Message Fragmentation", RFC 7383,
DOI 10.17487/RFC7383, November 2014,
<https://www.rfc-editor.org/info/rfc7383>.
[RFC7427] Kivinen, T. and J. Snyder, "Signature Authentication in
the Internet Key Exchange Version 2 (IKEv2)", RFC 7427,
DOI 10.17487/RFC7427, January 2015,
<https://www.rfc-editor.org/info/rfc7427>.
[RFC7619] Smyslov, V. and P. Wouters, "The NULL Authentication
Method in the Internet Key Exchange Protocol Version 2
(IKEv2)", RFC 7619, DOI 10.17487/RFC7619, August 2015,
<https://www.rfc-editor.org/info/rfc7619>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
"PKCS #1: RSA Cryptography Specifications Version 2.2",
RFC 8017, DOI 10.17487/RFC8017, November 2016,
<https://www.rfc-editor.org/info/rfc8017>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>. <https://www.rfc-editor.org/info/rfc8040>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8221] Wouters, P., Migault, D., Mattsson, J., Nir, Y., and T.
Kivinen, "Cryptographic Algorithm Implementation
Requirements and Usage Guidance for Encapsulating Security
Payload (ESP) and Authentication Header (AH)", RFC 8221,
DOI 10.17487/RFC8221, October 2017,
<https://www.rfc-editor.org/info/rfc8221>.
[RFC8247] Nir, Y., Kivinen, T., Wouters, P., and D. Migault, [RFC8247] Nir, Y., Kivinen, T., Wouters, P., and D. Migault,
"Algorithm Implementation Requirements and Usage Guidance "Algorithm Implementation Requirements and Usage Guidance
for the Internet Key Exchange Protocol Version 2 (IKEv2)", for the Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 8247, DOI 10.17487/RFC8247, September 2017, RFC 8247, DOI 10.17487/RFC8247, September 2017,
<https://www.rfc-editor.org/info/rfc8247>. <https://www.rfc-editor.org/info/rfc8247>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341, Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018, DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>. <https://www.rfc-editor.org/info/rfc8341>.
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "Network Management Datastore Architecture
(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
<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 10.2. Informative References
[I-D.carrel-ipsecme-controller-ike] [I-D.carrel-ipsecme-controller-ike]
Carrel, D. and B. Weiss, "IPsec Key Exchange using a Carrel, D. and B. Weiss, "IPsec Key Exchange using a
Controller", draft-carrel-ipsecme-controller-ike-01 (work Controller", draft-carrel-ipsecme-controller-ike-01 (work
in progress), March 2019. in progress), March 2019.
[I-D.tran-ipsecme-yang] [I-D.tran-ipsecme-yang]
Tran, K., Wang, H., Nagaraj, V., and X. Chen, "Yang Data Tran, K., Wang, H., Nagaraj, V., and X. Chen, "Yang Data
Model for Internet Protocol Security (IPsec)", draft-tran- Model for Internet Protocol Security (IPsec)", draft-tran-
ipsecme-yang-01 (work in progress), June 2015. ipsecme-yang-01 (work in progress), June 2015.
[ITU-T.Y.3300] [ITU-T.Y.3300]
"Recommendation ITU-T Y.3300", June 2014. "Recommendation ITU-T Y.3300", June 2014.
[libreswan] [libreswan]
The Libreswan Project, "Libreswan VPN software", August The Libreswan Project, "Libreswan VPN software", September
2019. 2020.
[netconf-vpn] [netconf-vpn]
Stefan Wallin, "Tutorial: NETCONF and YANG", January 2014. Stefan Wallin, "Tutorial: NETCONF and YANG", January 2014.
[ONF-OpenFlow] [ONF-OpenFlow]
ONF, "OpenFlow Switch Specification (Version 1.4.0)", ONF, "OpenFlow Switch Specification (Version 1.4.0)",
October 2013. October 2013.
[ONF-SDN-Architecture] [ONF-SDN-Architecture]
"SDN Architecture", June 2014. "SDN Architecture", June 2014.
skipping to change at page 28, line 11 skipping to change at page 30, line 46
[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", 2013. Security: A Survey", 2013.
[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", 2013. and Dependable Software-Defined Networks", 2013.
[strongswan] [strongswan]
CESNET, "StrongSwan: the OpenSource IPsec-based VPN CESNET, "StrongSwan: the OpenSource IPsec-based VPN
Solution", August 2019. Solution", September 2020.
Appendix A. Common YANG model for IKE and IKE-less cases Appendix A. Common YANG model for IKE and IKE-less cases
<CODE BEGINS> file "ietf-ipsec-common@2019-08-05.yang" This Appendix is Normative.
module ietf-ipsec-common { This YANG module has normative references to [RFC3947], [RFC4301],
[RFC4303], [RFC8174], [RFC8221] and [IKEv2-Parameters].
This YANG module has informative references to [RFC3948] and
[RFC8229].
<CODE BEGINS> file "ietf-i2nsf-ikec@2020-10-12.yang"
module ietf-i2nsf-ikec {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec-common"; namespace "urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikec";
prefix "ipsec-common"; prefix "ic";
import ietf-inet-types { prefix inet; } import ietf-inet-types {
import ietf-yang-types { prefix yang; } prefix inet;
reference "RFC 6991: Common YANG Data Types";
}
import ietf-yang-types {
prefix yang;
reference "RFC 6991: Common YANG Data Types";
}
organization "IETF I2NSF Working Group"; organization "IETF I2NSF Working Group";
contact contact
"WG Web: <https://datatracker.ietf.org/wg/i2nsf/about/> "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) 2019 IETF Trust and the persons Copyright (c) 2020 IETF Trust and the persons
identified as authors of the code. All rights reserved. identified as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with Redistribution and use in source and binary forms, with
or without modification, is permitted pursuant to, and or without modification, is permitted pursuant to, and
subject to the license terms contained in, the subject to the license terms contained in, the
Simplified BSD License set forth in Section 4.c of the Simplified BSD License set forth in Section 4.c of the
IETF Trust's Legal Provisions Relating to IETF Documents IETF Trust's Legal Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX;; This version of this YANG module is part of RFC XXXX;;
see the RFC itself for full legal notices. 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 "2019-08-05" { revision "2020-10-12" {
description "Revision 06"; description "Initial version.";
reference "RFC XXXX: YANG Groupings and typedef reference "RFC XXXX: Software-Defined Networking
for IKE and IKE-less case"; (SDN)-based IPsec Flow Protection.";
} }
typedef encryption-algorithm-type { typedef encryption-algorithm-type {
type uint16; type uint16;
description description
"The encryption algorithm is specified with a 16-bit "The encryption algorithm is specified with a 16-bit
number extracted from IANA Registry. The acceptable number extracted from 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
skipping to change at page 34, line 30 skipping to change at page 36, line 45
IANA Registry - Protocol Numbers."; IANA Registry - Protocol Numbers.";
} }
grouping encap { grouping encap {
description description
"This group of nodes allows to define the type of "This group of nodes allows to define the type of
encapsulation in case NAT traversal is encapsulation in case NAT traversal is
required and port information."; required and port information.";
leaf espencap { leaf espencap {
type esp-encap; type esp-encap;
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 {
skipping to change at page 36, line 11 skipping to change at page 38, line 26
} }
reference reference
"Section 4.4.2.1 in RFC 4301."; "Section 4.4.2.1 in RFC 4301.";
} }
grouping port-range { grouping port-range {
description description
"This grouping defines a port range, such as "This grouping defines a port range, such as
expressed in RFC 4301. For example: 1500 (Start expressed in RFC 4301. For example: 1500 (Start
Port Number)-1600 (End Port Number). A port range Port Number)-1600 (End Port Number).
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;
description description
"End port number."; "End port number. The assigned value must be
equal or greater than the start port number.
To express a single port, set the same value
as start and end.";
} }
reference "Section 4.4.1.2 in RFC 4301."; reference "Section 4.4.1.2 in RFC 4301.";
} }
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.";
skipping to change at page 37, line 35 skipping to change at page 40, line 4
leaf bypass-dscp { leaf bypass-dscp {
type boolean; type boolean;
default true; default true;
description description
"If DSCP (Differentiated Services Code Point) "If DSCP (Differentiated Services Code Point)
values in the inner header have to be used to values in the inner header have to be used to
select one IPsec SA among several that match select one IPsec SA among several that match
the traffic selectors for an outbound packet"; the traffic selectors for an outbound packet";
reference reference
"Section 4.4.2.1. in RFC 4301."; "Section 4.4.2.1. in RFC 4301.";
} }
leaf dscp-mapping { leaf dscp-mapping {
type yang:hex-string; type yang:hex-string;
default "00:00:00:00:00:00";
description description
"DSCP values allowed for packets carried over "DSCP values allowed for packets carried over
this IPsec SA."; this IPsec SA.";
reference reference
"Section 4.4.2.1. in RFC 4301."; "Section 4.4.2.1. in RFC 4301.";
} }
leaf ecn { leaf ecn {
type boolean; type boolean;
default false; default false;
description description
skipping to change at page 38, line 36 skipping to change at page 41, line 6
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 represents protocol is ICMP this 16 bit value
code and type."; represents code and type.
If this list is not defined
it is assumed that start and
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."; code and type.If this list is not defined
it is assumed that start and end are 0 by
default (any port)";
} }
reference reference
"Section 4.4.1.2 in RFC 4301."; "Section 4.4.1.2 in RFC 4301.";
} }
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.";
skipping to change at page 41, line 27 skipping to change at page 44, line 4
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 algorithms, algorithm. With AEAD algorithms,
the integrity node is not the integrity node is not
used."; used.";
reference reference
"Section 3.2 in RFC 4303."; "Section 3.2 in RFC 4303.";
} }
leaf-list encryption { list encryption {
type encryption-algorithm-type; key id;
default 20;
ordered-by user; ordered-by user;
leaf id {
type uint8;
description
"The index of list with the
different encryption algorithms and
its key-length (if required).";
}
leaf algorithm-type {
type ic:encryption-algorithm-type;
default 20;
description
"Default value 20
(ENCR_AES_GCM_16)";
}
leaf key-length {
type uint16;
default 128;
description
"By default key length is 128
bits";
}
description description
"Configuration of ESP encryption "Encryption or AEAD algorithm for the
algorithms. The default value is IPsec SAs. This list is ordered
20 (ENCR_AES_GCM_16)."; following from the higher priority to
lower priority. First node of the
list will be the algorithm with
higher priority. In case the list
is empty, then
no encryption algorithm
is applied (NULL).";
reference reference
"Section 3.2 in RFC 4303."; "Section 3.2 in RFC 4303.";
} }
leaf tfc-pad { leaf tfc-pad {
type boolean; type boolean;
default false; default false;
description description
"If Traffic Flow Confidentiality "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."; "Section 2.7 in RFC 4303.";
} }
reference reference
"RFC 4303."; "RFC 4303.";
} }
container tunnel { container tunnel {
when "../mode = 'tunnel'"; when "../mode = 'tunnel'";
uses tunnel-grouping; uses tunnel-grouping;
description description
"IPsec tunnel endpoints definition."; "IPsec tunnel endpoints definition.";
} }
skipping to change at page 42, line 46 skipping to change at page 46, line 7
states."; states.";
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
Appendix B. YANG model for IKE case Appendix B. YANG model for IKE case
<CODE BEGINS> file "ietf-ipsec-ike@2019-08-05.yang" This Appendix is Normative.
module ietf-ipsec-ike {
This YANG module has normative references to [RFC2247], [RFC5280],
[RFC4301], [RFC5280], [RFC5915], [RFC6991], [RFC7296], [RFC7383],
[RFC7427], [RFC7619], [RFC8017], [RFC8174], [RFC8341], [ITU-T.X.690],
[I-D.draft-ietf-netconf-crypto-types] and [IKEv2-Parameters].
This YANG module has informative references to [RFC8229].
<CODE BEGINS> file "ietf-i2nsf-ike@2020-10-12.yang"
module ietf-i2nsf-ike {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec-ike"; namespace "urn:ietf:params:xml:ns:yang:ietf-i2nsf-ike";
prefix "ike"; prefix "nsfike";
import ietf-inet-types { prefix inet; } import ietf-inet-types {
import ietf-yang-types { prefix yang; } prefix inet;
reference "RFC 6991: Common YANG Data Types";
}
import ietf-yang-types {
prefix yang;
reference "RFC 6991: Common YANG Data Types";
}
import ietf-crypto-types { import ietf-crypto-types {
prefix ct; prefix ct;
reference reference "RFC XXXX: YANG Data Types and Groupings
"draft-ietf-netconf-crypto-types-10: for Cryptography.";
Common YANG Data Types for Cryptography.";
} }
import ietf-ipsec-common { import ietf-i2nsf-ikec {
prefix ic; prefix ic;
reference reference
"RFC XXXX: module ietf-ipsec-common, revision "Common Data model for SDN-based IPsec
2019-08-05."; configuration.";
} }
import ietf-netconf-acm { import ietf-netconf-acm {
prefix nacm; prefix nacm;
reference reference
"RFC 8341: Network Configuration Access Control "RFC 8341: Network Configuration Access Control
Model."; Model.";
} }
organization "IETF I2NSF Working Group"; organization "IETF I2NSF Working Group";
contact contact
"WG Web: <https://datatracker.ietf.org/wg/i2nsf/about/> "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 IPsec IKE case model for the SDN-based "This module contains IPsec IKE case model for the SDN-based
IPsec flow protection service. An NSF will implement this IPsec flow protection service. An NSF will implement this
module. module.
Copyright (c) 2019 IETF Trust and the persons identified as Copyright (c) 2020 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 XXXX; see
the RFC itself for full legal notices. 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 "2019-08-05" { revision "2020-10-12" {
description "Revision 6"; description "Initial version.";
reference reference "RFC XXXX: Software-Defined Networking
"RFC XXXX: YANG model for IKE case."; (SDN)-based IPsec Flow Protection.";
} }
typedef ike-spi { typedef ike-spi {
type uint64 { range "0..max"; } type uint64 { range "0..max"; }
description description
"Security Parameter Index (SPI)'s IKE SA."; "Security Parameter Index (SPI)'s IKE SA.";
reference reference
"Section 2.6 in RFC 7296."; "Section 2.6 in RFC 7296.";
} }
skipping to change at page 49, line 4 skipping to change at page 52, line 22
Organisation,CN=John Smith."; Organisation,CN=John Smith.";
reference reference
"RFC 2247."; "RFC 2247.";
} }
} }
case gnx509 { case gnx509 {
leaf gnx509 { leaf gnx509 {
type string; type string;
description description
"ASN.1 X.509 GeneralName. RFC "ASN.1 X.509 GeneralName. RFC
3280."; 5280.";
} }
} }
case id-key { case id-key {
leaf id-key { leaf id-key {
type string; type string;
description description
"Opaque octet stream that may be "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.";
skipping to change at page 50, line 36 skipping to change at page 54, line 6
reference reference
"Section 2.16 in RFC 7296."; "Section 2.16 in RFC 7296.";
} }
container pre-shared { container pre-shared {
when when
"../auth-method[.='pre-shared' or "../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;
mandatory true;
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."; reasons.";
} }
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 1;
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. Depending on the Registry. Depending on the
algorithm, the following leafs algorithm, the following leafs
must contain information. For must contain information. For
example if digital signature example if digital signature
involves a certificate then leaf involves a certificate then leaf
'cert-data' and 'private-key' 'cert-data' and 'private-key'
skipping to change at page 51, line 40 skipping to change at page 55, line 12
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 reference
"RFC XXX: Common YANG Data "RFC XXXX: YANG Data Types and
Types for Cryptography."; Groupings for Cryptography.";
} }
leaf cert-data { leaf cert-data {
type ct:x509; type ct:x509;
description description
"X.509 certificate data - "X.509 certificate data -
PEM4."; PEM4. If raw-public-key
is defined this leaf is
empty.";
reference reference
"RFC XXX: Common YANG Data "RFC XXXX: YANG Data Types and
Types for Cryptography."; Groupings for Cryptography.";
} }
description description
"If the I2NSF Controller "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
(the NSF generated the pair (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 leaf of this
choice. The NSF, based on choice but not the leaf
the public key value can know private-key. The NSF, based on
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."; 5915. This value is set
if public-key is defined and
I2NSF controller is in charge
of configuring the
private-key. Otherwise, it is
not set and the value is
kept in secret.";
reference reference
"RFC XXX: Common YANG Data "RFC XXXX: YANG Data Types and
Types for Cryptography."; Groupings for Cryptography.";
} }
leaf-list ca-data { leaf-list ca-data {
type ct:x509; type ct:x509;
description description
"List of trusted Certification "List of trusted Certification
Authorities (CA) certificates Authorities (CA) certificates
encoded using ASN.1 encoded using ASN.1
distinguished encoding rules distinguished encoding rules
(DER)."; (DER). If it is not defined
the default value is empty.";
reference reference
"RFC XXX: Common YANG Data "RFC XXXX: YANG Data Types and
Types for Cryptography."; Groupings for Cryptography.";
} }
leaf crl-data { leaf crl-data {
type ct:crl; type ct:crl;
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."; X.690. If it is not defined
the default value is empty.";
reference reference
"RFC XXX: Common YANG Data Types "RFC XXXX: YANG Data Types and
for Cryptography."; Groupings for Cryptography.";
} }
leaf crl-uri { leaf crl-uri {
type inet:uri; type inet:uri;
description description
"X.509 CRL certificate URI."; "X.509 CRL certificate URI.
If it is not defined
the default value is empty.";
} }
leaf oscp-uri { leaf oscp-uri {
type inet:uri; type inet:uri;
description description
"OCSP URI."; "OCSP URI.
If it is not defined
the default value is empty.";
} }
description description
"Digital Signature container."; "Digital Signature container.";
} /*container digital-signature*/ } /*container digital-signature*/
} /*container peer-authentication*/ } /*container peer-authentication*/
} }
} }
list conn-entry { list conn-entry {
key "name"; key "name";
description description
"IKE peer connection information. This list "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 be translated in with other peers. This will be translated in
real time by IKE Security Associations real time by IKE Security Associations
established with these nodes."; established with these nodes.";
leaf name { leaf name {
type string; type string;
mandatory true;
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
skipping to change at page 55, line 37 skipping to change at page 59, line 25
} }
leaf-list authalg { leaf-list authalg {
type ic:integrity-algorithm-type; type ic:integrity-algorithm-type;
default 12; default 12;
ordered-by user; ordered-by user;
description description
"Authentication algorithm for establishing "Authentication algorithm for establishing
the IKE SA. This list is ordered following 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 First node of the list will be the algorithm
with higher priority. If this list is empty with higher priority.";
the default integrity algorithm value assumed
is NONE.";
} }
leaf-list encalg {
type ic:encryption-algorithm-type; list encalg {
default 12; key id;
min-elements 1;
ordered-by user; ordered-by user;
leaf id {
type uint8;
description
"The index of the list with the
different encryption algorithms and its
key-length (if required). E.g. AES-CBC,
128 bits";
}
leaf algorithm-type {
type ic:encryption-algorithm-type;
default 12;
description
"Default value 12 (ENCR_AES_CBC)";
}
leaf key-length {
type uint16;
default 128;
description
"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 First node of the list will be the algorithm
with higher priority. If this list is empty with higher priority.";
the default encryption value assumed is
NULL.";
} }
leaf dh-group { leaf dh-group {
type pfs-group; type pfs-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;
default 0;
description description
"Set the half-open IKE SA timeout "Set the half-open IKE SA timeout
duration."; duration.";
reference reference
"Section 2 in RFC 7296."; "Section 2 in RFC 7296.";
} }
leaf half-open-ike-sa-cookie-threshold { leaf half-open-ike-sa-cookie-threshold {
type uint32; type uint32;
default 0;
description description
"Number of half-open IKE SAs that activate "Number of half-open IKE SAs that activate
the cookie mechanism." ; the cookie mechanism." ;
reference reference
"Section 2.6 in RFC 7296."; "Section 2.6 in RFC 7296.";
} }
container local { container local {
leaf local-pad-entry-name { leaf local-pad-entry-name {
type string; type string;
mandatory true;
description description
"Local peer authentication information. "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.";
skipping to change at page 56, line 44 skipping to change at page 61, line 4
description description
"Local peer authentication information. "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;
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.";
skipping to change at page 57, line 38 skipping to change at page 61, line 48
description description
"Configuration of the Security Policy "Configuration of the Security Policy
Database (SPD). This main information is 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;
mandatory true;
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 a IPsec policy.";
uses ic:ipsec-policy-grouping; uses ic:ipsec-policy-grouping;
} }
skipping to change at page 61, line 21 skipping to change at page 65, line 29
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>
Appendix C. YANG model for IKE-less case Appendix C. YANG model for IKE-less case
<CODE BEGINS> file "ietf-ipsec-ikeless@2019-08-05.yang" This Appendix is Normative.
module ietf-ipsec-ikeless { This YANG module has normative references to [RFC4301], [RFC6991],
[RFC8174] and [RFC8341].
yang-version 1.1; <CODE BEGINS> file "ietf-i2nsf-ikeless@2020-10-12.yang"
namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless";
prefix "ikeless"; module ietf-i2nsf-ikeless {
import ietf-yang-types { prefix yang; } yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless";
import ietf-ipsec-common { prefix "nsfikels";
import ietf-yang-types {
prefix yang;
reference "RFC 6991: Common YANG Data Types";
}
import ietf-i2nsf-ikec {
prefix ic; prefix ic;
reference reference
"Common Data model for SDN-based IPsec "Common Data model for SDN-based IPsec
configuration."; configuration.";
} }
import ietf-netconf-acm { import ietf-netconf-acm {
prefix nacm; prefix nacm;
reference reference
"RFC 8341: Network Configuration Access Control "RFC 8341: Network Configuration Access Control
Model."; Model.";
} }
organization "IETF I2NSF Working Group"; organization "IETF I2NSF Working Group";
contact contact
"WG Web: <https://datatracker.ietf.org/wg/i2nsf/about/> "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
"Data model for IKE-less case in the SDN-base IPsec flow "Data model for IKE-less case in the SDN-base IPsec flow
protection service. protection service.
Copyright (c) 2019 IETF Trust and the persons Copyright (c) 2020 IETF Trust and the persons
identified as authors of the code. All rights reserved. identified as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with Redistribution and use in source and binary forms, with
or without modification, is permitted pursuant to, and or without modification, is permitted pursuant to, and
subject to the license terms contained in, the subject to the license terms contained in, the
Simplified BSD License set forth in Section 4.c of the Simplified BSD License set forth in Section 4.c of the
IETF Trust's Legal Provisions Relating to IETF Documents IETF Trust's Legal Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX;; This version of this YANG module is part of RFC XXXX;;
see the RFC itself for full legal notices. 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 "2019-08-05" { revision "2020-10-12" {
description "Revision 06"; description "Initial version.";
reference "RFC XXXX: YANG model for IKE case."; reference "RFC XXXX: Software-Defined Networking
(SDN)-based IPsec Flow Protection.";
} }
container ipsec-ikeless { container ipsec-ikeless {
description description
"Container for configuration of the IKE-less "Container for configuration of the IKE-less
case. The container contains two additional case. The container contains two additional
containers: 'spd' and 'sad'. The first allows the containers: 'spd' and 'sad'. The first allows the
I2NSF Controller to configure IPsec policies in I2NSF Controller to configure IPsec policies in
the Security Policy Database SPD, and the second the Security Policy Database SPD, and the second
allows to configure IPsec Security Associations allows to configure IPsec Security Associations
skipping to change at page 63, line 22 skipping to change at page 67, line 37
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 "Section 4.4.1.2 in RFC 4301.";
list spd-entry { list spd-entry {
key "name"; key "name";
ordered-by user; ordered-by user;
leaf name { leaf name {
type string; type string;
mandatory true;
description description
"SPD entry unique name to identify this "SPD entry unique name to identify this
entry."; entry.";
} }
leaf direction { leaf direction {
type ic:ipsec-traffic-direction; type ic:ipsec-traffic-direction;
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
IPsec policy will require."; IPsec policy will require.";
skipping to change at page 66, line 13 skipping to change at page 70, line 28
} }
leaf protocol-parameters { leaf protocol-parameters {
type ic:ipsec-protocol-parameters; type ic:ipsec-protocol-parameters;
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 ic:ipsec-mode; type ic:ipsec-mode;
default transport;
description description
"Tunnel or transport mode."; "Tunnel or transport mode.";
} }
container esp-sa { container esp-sa {
when "../protocol-parameters = when "../protocol-parameters =
'esp'"; 'esp'";
description description
"In case the IPsec SA is "In case the IPsec SA is
Encapsulation Security Payload Encapsulation Security Payload
(ESP), it is required to specify (ESP), it is required to specify
skipping to change at page 66, line 35 skipping to change at page 70, line 51
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 { leaf encryption-algorithm {
type ic:encryption-algorithm-type; type ic:encryption-algorithm-type;
default 12;
description description
"Configuration of ESP "Configuration of ESP
encryption. With AEAD encryption. With AEAD
algorithms, the integrity algorithms, the integrity
node 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
the key is not defined
(e.g. encryption is NULL).
The key length is
determined by the
length of the key set in
this leaf. By default is
128 bits.";
}
leaf iv { leaf iv {
nacm:default-deny-all; nacm:default-deny-all;
type yang:hex-string; type yang:hex-string;
description description
"ESP encryption IV value."; "ESP encryption IV value. If
this leaf is not defined the
IV is not defined (e.g.
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 to configure integrity allows to configure integrity
algorithm when no AEAD algorithm when no AEAD
algorithms are used, and algorithms are used, and
integrity is required."; integrity is required.";
leaf integrity-algorithm { leaf integrity-algorithm {
type ic:integrity-algorithm-type; type ic:integrity-algorithm-type;
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
AUTH_HMAC_SHA2_256_128).
With AEAD algorithms,
the integrity 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 integrity key value."; "ESP integrity key value.
If this leaf is not defined
the key is not defined (e.g.
AEAD algorithm is chosen and
integrity algorithm is not
required). The key length is
determined by the length of
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 associated is terminate and
hold."; hold.";
uses ic:lifetime; uses ic:lifetime;
skipping to change at page 71, line 28 skipping to change at page 76, line 21
"Notify when the NSF receives a packet with an "Notify when the NSF receives a packet with an
incorrect SPI (i.e. not present in the SAD)."; incorrect SPI (i.e. not present in the SAD).";
leaf spi { leaf spi {
type uint32 { range "0..max"; } type uint32 { range "0..max"; }
mandatory true; mandatory true;
description description
"SPI number contained in the erroneous IPsec "SPI number contained in the erroneous IPsec
packet."; packet.";
} }
} }
}/*module ietf-ipsec*/ }
<CODE ENDS> <CODE ENDS>
Appendix D. XML configuration example for IKE case (gateway-to-gateway) Appendix D. XML configuration example for IKE case (gateway-to-gateway)
This example shows a XML configuration file sent by the I2NSF This example shows a XML configuration file sent by the I2NSF
Controller to establish a IPsec Security Association between two NSFs Controller to establish a IPsec Security Association between two NSFs
(see Figure 3) in tunnel mode (gateway-to-gateway) with ESP, (see Figure 3) in tunnel mode (gateway-to-gateway) with ESP,
authentication based on X.509 certificates and applying the IKE case. authentication based on X.509 certificates and applying the IKE case.
skipping to change at page 72, line 22 skipping to change at page 77, line 5
/ \ / \
+----+ +--------+ +--------+ +----+ +----+ +--------+ +--------+ +----+
| 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-ipsec-ike" <ipsec-ike xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-ike"
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
<pad> <pad>
<pad-entry> <pad-entry>
<name>nsf_h1_pad</name> <name>nsf_h1_pad</name>
<ipv6-address>2001:DB8:123::100</ipv6-address> <ipv6-address>2001:DB8:123::100</ipv6-address>
<peer-authentication> <peer-authentication>
<auth-method>digital-signature</auth-method> <auth-method>digital-signature</auth-method>
<digital-signature> <digital-signature>
<cert-data>base64encodedvalue==</cert-data> <cert-data>base64encodedvalue==</cert-data>
<private-key>base64encodedvalue==</private-key> <private-key>base64encodedvalue==</private-key>
skipping to change at page 73, line 19 skipping to change at page 77, line 48
<version>ikev2</version> <version>ikev2</version>
<initial-contact>false</initial-contact> <initial-contact>false</initial-contact>
<fragmentation>true</fragmentation> <fragmentation>true</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>
<authalg>7</authalg>
<!--AUTH_HMAC_SHA1_160--> <!--AUTH_HMAC_SHA1_160-->
<encalg>3</encalg> <authalg>7</authalg>
<!--ENCR_3DES --> <!--ENCR_AES_CBC - 128 bits-->
<dh-group>18</dh-group> <encalg>
<id>1</id>
</encalg>
<!--8192-bit MODP Group--> <!--8192-bit MODP Group-->
<dh-group>18</dh-group>
<half-open-ike-sa-timer>30</half-open-ike-sa-timer> <half-open-ike-sa-timer>30</half-open-ike-sa-timer>
<half-open-ike-sa-cookie-threshold> <half-open-ike-sa-cookie-threshold>
15 15
</half-open-ike-sa-cookie-threshold> </half-open-ike-sa-cookie-threshold>
<local> <local>
<local-pad-entry-name>nsf_h1_pad</local-pad-entry-name> <local-pad-entry-name>nsf_h1_pad</local-pad-entry-name>
</local> </local>
<remote> <remote>
<remote-pad-entry-name>nsf_h2_pad</remote-pad-entry-name> <remote-pad-entry-name>nsf_h2_pad</remote-pad-entry-name>
</remote> </remote>
skipping to change at page 74, line 16 skipping to change at page 78, line 48
<ipsec-sa-cfg> <ipsec-sa-cfg>
<pfp-flag>false</pfp-flag> <pfp-flag>false</pfp-flag>
<ext-seq-num>true</ext-seq-num> <ext-seq-num>true</ext-seq-num>
<seq-overflow>false</seq-overflow> <seq-overflow>false</seq-overflow>
<stateful-frag-check>false</stateful-frag-check> <stateful-frag-check>false</stateful-frag-check>
<mode>tunnel</mode> <mode>tunnel</mode>
<protocol-parameters>esp</protocol-parameters> <protocol-parameters>esp</protocol-parameters>
<esp-algorithms> <esp-algorithms>
<!-- AUTH_HMAC_SHA1_96 --> <!-- AUTH_HMAC_SHA1_96 -->
<integrity>2</integrity> <integrity>2</integrity>
<!-- ENCR_AES_CBC --> <encryption>
<encryption>12</encryption> <!-- ENCR_AES_CBC -->
<id>1</id>
<algorithm-type>12</algorithm-type>
<key-length>128</key-length>
</encryption>
<encryption>
<!-- ENCR_3DES-->
<id>2</id>
<algorithm-type>3</algorithm-type>
</encryption>
<tfc-pad>false</tfc-pad> <tfc-pad>false</tfc-pad>
</esp-algorithms> </esp-algorithms>
<tunnel> <tunnel>
<local>2001:DB8:123::100</local> <local>2001:DB8:123::100</local>
<remote>2001:DB8:123::200</remote> <remote>2001:DB8:123::200</remote>
<df-bit>clear</df-bit> <df-bit>clear</df-bit>
<bypass-dscp>true</bypass-dscp> <bypass-dscp>true</bypass-dscp>
<ecn>false</ecn> <ecn>false</ecn>
</tunnel> </tunnel>
</ipsec-sa-cfg> </ipsec-sa-cfg>
skipping to change at page 75, line 28 skipping to change at page 80, line 21
/ \ / \
/ \ / \
+--------+ +--------+ +--------+ +--------+
| 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-ipsec-ikeless" xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless"
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
<spd> <spd>
<spd-entry> <spd-entry>
<name> <name>
in/trans/2001:DB8:123::200/2001:DB8:123::100 in/trans/2001:DB8:123::200/2001:DB8:123::100
</name> </name>
<direction>inbound</direction> <direction>inbound</direction>
<reqid>1</reqid> <reqid>1</reqid>
<ipsec-policy-config> <ipsec-policy-config>
<traffic-selector> <traffic-selector>
skipping to change at page 76, line 18 skipping to change at page 81, line 9
<action>protect</action> <action>protect</action>
<ipsec-sa-cfg> <ipsec-sa-cfg>
<ext-seq-num>true</ext-seq-num> <ext-seq-num>true</ext-seq-num>
<seq-overflow>true</seq-overflow> <seq-overflow>true</seq-overflow>
<mode>transport</mode> <mode>transport</mode>
<protocol-parameters>esp</protocol-parameters> <protocol-parameters>esp</protocol-parameters>
<esp-algorithms> <esp-algorithms>
<!--AUTH_HMAC_SHA1_96--> <!--AUTH_HMAC_SHA1_96-->
<integrity>2</integrity> <integrity>2</integrity>
<!--ENCR_AES_CBC --> <!--ENCR_AES_CBC -->
<encryption>12</encryption> <encryption>
<id>1</id>
<algorithm-type>12</algorithm-type>
<key-length>128</key-length>
</encryption>
<encryption>
<id>2</id>
<algorithm-type>3</algorithm-type>
</encryption>
</esp-algorithms> </esp-algorithms>
</ipsec-sa-cfg> </ipsec-sa-cfg>
</processing-info> </processing-info>
</ipsec-policy-config> </ipsec-policy-config>
</spd-entry> </spd-entry>
<spd-entry> <spd-entry>
<name>out/trans/2001:DB8:123::100/2001:DB8:123::200</name> <name>out/trans/2001:DB8:123::100/2001:DB8:123::200</name>
<direction>outbound</direction> <direction>outbound</direction>
<reqid>1</reqid> <reqid>1</reqid>
<ipsec-policy-config> <ipsec-policy-config>
skipping to change at page 77, line 4 skipping to change at page 82, line 4
<action>protect</action> <action>protect</action>
<ipsec-sa-cfg> <ipsec-sa-cfg>
<ext-seq-num>true</ext-seq-num> <ext-seq-num>true</ext-seq-num>
<seq-overflow>true</seq-overflow> <seq-overflow>true</seq-overflow>
<mode>transport</mode> <mode>transport</mode>
<protocol-parameters>esp</protocol-parameters> <protocol-parameters>esp</protocol-parameters>
<esp-algorithms> <esp-algorithms>
<!-- AUTH_HMAC_SHA1_96 --> <!-- AUTH_HMAC_SHA1_96 -->
<integrity>2</integrity> <integrity>2</integrity>
<!-- ENCR_AES_CBC --> <!-- ENCR_AES_CBC -->
<encryption>12</encryption> <encryption>
<id>1</id>
<algorithm-type>12</algorithm-type>
<key-length>128</key-length>
</encryption>
<encryption>
<id>2</id>
<algorithm-type>3</algorithm-type>
</encryption>
</esp-algorithms> </esp-algorithms>
</ipsec-sa-cfg> </ipsec-sa-cfg>
</processing-info> </processing-info>
</ipsec-policy-config> </ipsec-policy-config>
</spd-entry> </spd-entry>
</spd> </spd>
<sad> <sad>
<sad-entry> <sad-entry>
<name>out/trans/2001:DB8:123::100/2001:DB8:123::200</name> <name>out/trans/2001:DB8:123::100/2001:DB8:123::200</name>
<reqid>1</reqid> <reqid>1</reqid>
skipping to change at page 79, line 18 skipping to change at page 84, line 25
</sad> </sad>
</ipsec-ikeless> </ipsec-ikeless>
Appendix F. XML notification examples Appendix F. XML notification examples
Below we show several XML files that represent different types of Below we show several XML files that represent different types of
notifications defined in the IKE-less YANG model, which are sent by notifications defined in the IKE-less YANG model, which are sent by
the NSF to the I2NSF Controller. The notifications happen in the the NSF to the I2NSF Controller. The notifications happen in the
IKE-less case. IKE-less case.
<sadb-expire xmlns="urn:ietf:params:xml:ns:yang:ietf-ipsec-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 sadb-expire notification.
<sadb-acquire xmlns="urn:ietf:params:xml:ns:yang:ietf-ipsec-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-subnet>2001:DB8:123::200/128</local-subnet> <local-subnet>2001:DB8:123::200/128</local-subnet>
<remote-subnet>2001:DB8:123::100/128</remote-subnet> <remote-subnet>2001:DB8:123::100/128</remote-subnet>
<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 sadb-acquire notification.
<sadb-seq-overflow <sadb-seq-overflow
xmlns="urn:ietf:params:xml:ns:yang:ietf-ipsec-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 sadb-seq-overflow notification.
<sadb-bad-spi <sadb-bad-spi
xmlns="urn:ietf:params:xml:ns:yang:ietf-ipsec-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 sadb-bad-spi notification.
Appendix G. Operational use cases examples Appendix G. Operational use cases examples
G.1. Example of IPsec SA establishment G.1. Example of IPsec SA establishment
This appendix exemplifies the applicability of IKE case and IKE-less This appendix exemplifies the applicability of IKE case and IKE-less
skipping to change at page 81, line 12 skipping to change at page 86, line 12
gateway-to-gateway. The examples we show in the following assume the gateway-to-gateway. The examples we show in the following assume the
existence of two NSFs needing to establish an end-to-end IPsec SA to existence of two NSFs needing to establish an end-to-end IPsec SA to
protect their communications. Both NSFs could be two hosts that protect their communications. Both NSFs could be two hosts that
exchange traffic (host-to-host) or gateways (gateway-to-gateway), for exchange traffic (host-to-host) or gateways (gateway-to-gateway), for
example, within an enterprise that needs to protect the traffic example, within an enterprise that needs to protect the traffic
between the networks of two branch offices. between the 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. Beside, IaaS services between branches and SaaS cloud services. Besides, IaaS services
providing virtualization environments are deployments solutions based providing virtualization environments are deployments that often rely
on IPsec to provide secure channels between virtual instances (host- on IPsec to provide secure channels between virtual instances (host-
to-host) and providing VPN solutions for virtualized networks to-host) and providing VPN solutions for virtualized networks
(gateway-to-gateway). (gateway-to-gateway).
As we will show in the following, the I2NSF-based IPsec management As we will show 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 to create 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
skipping to change at page 84, line 25 skipping to change at page 89, line 25
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 Other alternative to this operation is: the I2NSF Controller
sends first the IPsec policies and new inbound IPsec SAs to A and sends first the IPsec policies and new inbound IPsec SAs to A and
B and once it obtains a successful confirmation of these B and once it obtains a successful confirmation of these
operations from NSF A and NSF B, it proceeds with installing to operations from NSF A and NSF B, it proceeds with installing to
the new outbound IPsec SAs. Despite this procedure may increase the new outbound IPsec SAs. Even though this procedure may
the latency to complete the process, no traffic is sent over the increase the latency to complete the process, no traffic is sent
network until the IPsec SAs are completely operative. In any over the network until the IPsec SAs are completely operative.
case other alternatives MAY be possible to implement step 3. In any case other alternatives MAY be possible to implement step
3.
4. If some of the operations described above fails (e.g. the NSF A 4. If some of the operations described above fail (e.g. the 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 SA and SPD entry that had been successfully inbound or outbound SA and SPD entry that had been successfully
installed in any of the NSFs (e.g NSF B) and stop the process. installed in any of the NSFs (e.g NSF B) and stop the process.
Note that the I2NSF Controller may retry several times before Note that the I2NSF Controller may retry several times before
giving up. 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
skipping to change at page 85, line 4 skipping to change at page 90, line 5
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 saw first 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. In such as entries with the IPsec SAs to process the data packet. Again, if
reactive mode, upon reception of the sadb-acquire notification, the some of the operations installing the new inbound/outbound IPsec SAs
I2NSF Controller installs the new IPsec SAs in NSF A and B (following fail, the I2NSF Controller stops the process and performs a rollback
the procedure previously described in step 3) but without sending any operation by deleting any new inbound/outbound SAs that had been
IPsec policies, since IPsec policies are already installed in the successfully installed.
SPD. Again, if some of the operations installing the new inbound/
outbound IPsec SAs fail, the I2NSF Controller stops the process and
performs a rollback operation by deleting any new inbound/outbound
SAs that had been successfully installed.
G.2. Example of the rekeying process in IKE-less case G.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, let assume that SPIa1 identifies the inbound IPsec SA in A,
and SPIb1 the inbound IPsec SA in B. The rekeying process will take and SPIb1 the inbound IPsec SA in B. The rekeying process will take
the following steps: 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 A and SPIb2 for B. inbound IPsec SAs: for example, SPIa2 for A and SPIb2 for B.
skipping to change at page 86, line 31 skipping to change at page 91, line 28
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 Step 2 and step 3 can be performed at the same time at the cost of a
potential packet loss. If this is not critic 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 I2NSF Controller
and NSFs is lower. and NSFs is lower.
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 Campus de Espinardo S/N, Faculty of Computer Science
Murcia 30100 Murcia 30100
Spain Spain
 End of changes. 166 change blocks. 
451 lines changed or deleted 762 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/