RFC 9061: A YANG Data Model for IPsec Flow Protection Based on Software-Defined Networking (SDN)
- R. Marin-Lopez,
- G. Lopez-Millan,
- F. Pereniguez-Garcia
Abstract
This document describes how to provide IPsec-based
flow protection (integrity and confidentiality
This document focuses on the I2NSF NSF-Facing Interface by providing YANG data models for configuring the IPsec databases, namely Security Policy Database (SPD), Security Association Database (SAD), Peer Authorization Database (PAD), and Internet Key Exchange Version 2 (IKEv2). This allows IPsec SA establishment with minimal intervention by the network administrator. This document defines three YANG modules, but it does not define any new protocol.¶
Status of This Memo
This is an Internet Standards Track document.¶
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
https://
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://
1. Introduction
Software
Recently, several network scenarios now demand a centralized
way of managing different security aspects, for example,
Software
Therefore, with the growth of SDN-based scenarios where network resources are deployed in an autonomous manner, a mechanism to manage IPsec SAs from a centralized entity becomes more relevant in the industry.¶
In response to this need, the Interface to Network Security
Functions (I2NSF) charter states that the goal of this
working group is "to define a set of software interfaces and
data models for controlling and monitoring aspects of
physical and virtual NSFs". As defined
in [RFC8192], a Network Security Function (NSF) is "a function
that is used to ensure integrity, confidentiality
In fact, Section 3.1.9 of [RFC8192] states that "there is a need for a controller to create, manage, and distribute various keys to distributed NSFs"; however, "there is a lack of a standard interface to provision and manage security associations". Inspired by the SDN paradigm, the I2NSF framework [RFC8329] defines a centralized entity, the I2NSF Controller, which manages one or multiple NSFs through an I2NSF NSF-Facing Interface. In this document, an architecture is defined for allowing the I2NSF Controller to carry out the key management procedures. More specifically, three YANG data models are defined for the I2NSF NSF-Facing Interface, which allows the I2NSF Controller to configure and monitor IPsec-enabled, flow-based NSFs.¶
The IPsec architecture [RFC4301] defines
a clear separation between the processing to provide
security services to IP packets and the key management
procedures to establish the IPsec SAs,
which allows centralizing the key management procedures
in the I2NSF Controller.
This document considers two typical scenarios to
autonomously manage IPsec SAs: gateway
For the definition of the YANG data models for the I2NSF NSF-Facing Interface, this document considers two general cases, namely:¶
In both cases, a YANG data model for the I2NSF NSF-Facing
Interface is required to carry out this provisioning
in a secure manner between the I2NSF Controller and the NSF.
Using YANG data modeling language version 1.1 [RFC7950] and
based on YANG data models defined in [netconf-vpn] and
[TRAN
In summary, the objectives of this document are:¶
2. Terminology
This document uses the terminology described in [ITU-T.Y.3300], [RFC8192], [RFC4301], [RFC6437], [RFC7296], [RFC6241], and [RFC8329].¶
The following term is defined in [ITU-T.Y.3300]:¶
The following terms are defined in [RFC8192]:¶
The following terms are defined in [RFC4301]:¶
The following two terms are related or
have identical definition
The following term is defined in [RFC7296]:¶
The following terms are defined in [RFC6241]:¶
2.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
3. SDN-Based IPsec Management Description
As mentioned in Section 1, two cases are considered, depending on whether the NSF implements IKEv2 or not: the IKE case and the IKE-less case.¶
3.1. IKE Case: IKEv2/IPsec in the NSF
In this case, the NSF implements IPsec with IKEv2 support. The I2NSF Controller is in charge of managing and applying IPsec connection information (determining which nodes need to start an IKEv2/IPsec session, identifying the type of traffic to be protected, and deriving and delivering IKEv2 credentials, such as a pre-shared key (PSK), certificates, etc.) and applying other IKEv2 configuration parameters (e.g., cryptographic algorithms for establishing an IKEv2 SA) to the NSF necessary for the IKEv2 negotiation.¶
With these entries, the IKEv2 implementation can operate to establish the IPsec SAs. The I2NSF User establishes the IPsec requirements and information about the endpoints (through the I2NSF Consumer-Facing Interface [RFC8329]), and the I2NSF Controller translates these requirements into IKEv2, SPD, and PAD entries that will be installed into the NSF (through the I2NSF NSF-Facing Interface). With that information, the NSF can just run IKEv2 to establish the required IPsec SA (when the traffic flow needs protection). Figure 1 shows the different layers and corresponding functionality.¶
I2NSF-based IPsec flow protection services provide dynamic and flexible management of IPsec SAs in flow-based NSFs. In order to support this capability in the IKE case, a YANG data model for IKEv2, SPD, and PAD configuration data and for IKEv2 state data needs to be defined for the I2NSF NSF-Facing Interface (see Section 5).¶
3.2. IKE-less Case: IPsec (No IKEv2) in the NSF
In this case, the NSF does not deploy IKEv2 and, therefore, the I2NSF Controller has to perform the IKEv2 security functions and management of IPsec SAs by populating and managing the SPD and the SAD.¶
As shown in Figure 2, when an I2NSF User enforces flow-based protection policies through the Consumer-Facing Interface, the I2NSF Controller translates these requirements into SPD and SAD entries, which are installed in the NSF. PAD entries are not required, since there is no IKEv2 in the NSF.¶
In order to support the IKE-less case, a YANG data model for SPD and SAD configuration data and SAD state data MUST be defined for the NSF-Facing Interface (see Section 5).¶
Specifically, the IKE-less case assumes that the I2NSF Controller has to perform some security functions that IKEv2 typically does, namely (non-exhaustive list):¶
Additionally to these functions, another set of tasks must be performed by the I2NSF Controller (non-exhaustive list):¶
4. IKE Case vs. IKE-less Case
In principle, the IKE case is easier to deploy than the IKE-less
case because current flow-based NSFs (either hosts or gateways)
have access to IKEv2 implementations
Alternatively, the IKE-less case benefits the
deployment in resource
Nevertheless, literature around SDN-based network management
using a centralized controller (like the I2NSF Controller)
is aware of scalability and performance issues, and solutions
have been already provided and discussed (e.g., hierarchical
controllers, having multiple replicated controllers, dedicated
high-speed management networks, etc.). In the context of
I2NSF-based IPsec management, one way to reduce the latency and
alleviate some performance issues can be to install the
IPsec policies and IPsec SAs at the same time (proactive mode,
as described in Appendix D.1)
instead of waiting for notifications (e.g., a
sadb-acquire notification received from an NSF requiring a new IPsec SA)
to proceed with the IPsec SA installation (reactive mode).
Another way to reduce the overhead and the potential scalability
and performance issues in the I2NSF Controller is to apply the
IKE case described in this document since the IPsec SAs are
managed between NSFs without the involvement of the I2NSF
Controller at all, except by the initial configuration (i.e.,
IKEv2, PAD, and SPD entries) provided by the I2NSF Controller.
Other solutions, such as Controller-IKE
[IPSECME
In terms of security, the IKE case provides better security properties than the IKE-less case, as discussed in Section 7. The main reason is that the NSFs generate the session keys and not the I2NSF Controller.¶
4.1. Rekeying Process
Performing a rekey for IPsec SAs is an important operation during the IPsec SAs management. With the YANG data models defined in this document the I2NSF Controller can configure parameters of the rekey process (IKE case) or conduct the rekey process (IKE-less case). Indeed, depending on the case, the rekey process is different.¶
For the IKE case, the rekeying process is carried out by IKEv2, following the information defined in the SPD and SAD (i.e., based on the IPsec SA lifetime established by the I2NSF Controller using the YANG data model defined in this document). Therefore, IPsec connections will live unless something different is required by the I2NSF User or the I2NSF Controller detects something wrong.¶
For the IKE-less case, the I2NSF Controller MUST take care of the rekeying process. When the IPsec SA is going to expire (e.g., IPsec SA soft lifetime), it MUST create a new IPsec SA and it MAY remove the old one (e.g., when the lifetime of the old IPsec SA has not been defined). This rekeying process starts when the I2NSF Controller receives a sadb-expire notification or, on the I2NSF Controller's initiative, based on lifetime state data obtained from the NSF. How the I2NSF Controller implements an algorithm for the rekey process is out of the scope of this document. Nevertheless, an example of how this rekey could be performed is described in Appendix D.2.¶
4.2. NSF State Loss
If one of the NSF restarts, it will lose the IPsec state (affected NSF). By default, the I2NSF Controller can assume that all the state has been lost and, therefore, it will have to send IKEv2, SPD, and PAD information to the NSF in the IKE case and SPD and SAD information in the IKE-less case.¶
In both cases, the I2NSF Controller is aware of the affected NSF (e.g., the NETCONF/TCP connection is broken with the affected NSF, the I2NSF Controller is receiving a sadb-bad-spi notification from a particular NSF, etc.). Moreover, the I2NSF Controller keeps a list of NSFs that have IPsec SAs with the affected NSF. Therefore, it knows the affected IPsec SAs.¶
In the IKE case, the I2NSF Controller may need to configure the affected NSF with the new IKEv2, SPD, and PAD information. Alternatively, IKEv2 configuration MAY be made permanent between NSF reboots without compromising security by means of the startup configuration datastore in the NSF. This way, each time an NSF reboots, it will use that configuration for each rebooting. It would imply avoiding contact with the I2NSF Controller. Finally, the I2NSF Controller may also need to send new parameters (e.g., a new fresh PSK for authentication) to the NSFs that had IKEv2 SAs and IPsec SAs with the affected NSF.¶
In the IKE-less case, the I2NSF Controller SHOULD delete the old IPsec SAs in the non-failed nodes established with the affected NSF. Once the affected node restarts, the I2NSF Controller MUST take the necessary actions to reestablish IPsec-protected communication between the failed node and those others having IPsec SAs with the affected NSF. How the I2NSF Controller implements an algorithm for managing a potential NSF state loss is out of the scope of this document. Nevertheless, an example of how this could be performed is described in Appendix D.3.¶
4.3. NAT Traversal
In the IKE case, IKEv2 already provides a mechanism to detect whether some of the peers or both are located behind a NAT. In this case, UDP or TCP encapsulation for Encapsulating Security Payload (ESP) packets [RFC3948] [RFC8229] is required. Note that IPsec transport mode MUST NOT be used in this specification when NAT is required.¶
In the IKE-less case, the NSF does not have the assistance of the 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 I2NSF Controller SHOULD implement a mechanism to detect that case. The SDN paradigm generally assumes the I2NSF Controller has a view of the network under its control. This view is built either by requesting information from the NSFs under its control or information pushed from the NSFs to the I2NSF Controller. Based on this information, the I2NSF Controller MAY guess if there is a NAT configured between two hosts and apply the required policies to both NSFs besides activating the usage of UDP or TCP encapsulation of ESP packets [RFC3948] [RFC8229]. The interface for discovering if 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 host is behind a NAT or not, then the IKE case MUST be used and not the IKE-less case.¶
4.4. NSF Registration and Discovery
NSF registration refers to the process of providing the I2NSF Controller information about a valid NSF, such as certificate, IP address, etc. This information is incorporated in a list of NSFs under its control.¶
The assumption in this document is that, for both cases, before an NSF can operate in this system, it MUST be registered in the I2NSF Controller. In this way, when the NSF starts and establishes a connection to the I2NSF Controller, it knows that the NSF is valid for joining the system.¶
Either during this registration process or when the NSF connects with the I2NSF Controller, the I2NSF Controller MUST discover certain capabilities of this NSF, such as what are the cryptographic suites supported, the authentication method, the support of the IKE case and/or the IKE-less case, etc.¶
The registration and discovery processes are out of the scope of this document.¶
5. YANG Configuration Data Models
In order to support the IKE and IKE-less cases,
models are provided for the different parameters and
values that must be configured to manage IPsec SAs.
Specifically, the IKE case requires modeling IKEv2
configuration parameters, SPD and PAD,
while the IKE-less case requires configuration
YANG data models for the
SPD and SAD. Three modules have been defined: ietf-i2nsf-ikec
(Section 5.1, common to both cases),
ietf-i2nsf-ike (Section 5.2, IKE case), and
ietf
5.1. The 'ietf-i2nsf-ikec' Module
5.1.1. Data Model Overview
The module ietf-i2nsf-ikec only has definitions of data types (typedef) and groupings that are common to the other modules.¶
5.1.2. YANG Module
This module has normative references to [RFC3947], [RFC4301], [RFC4303], [RFC8174], [RFC8221], [RFC3948], [RFC8229], [RFC6991], [IANA
5.2. The 'ietf-i2nsf-ike' Module
In this section, the YANG module for the IKE case is described.¶
5.2.1. Data Model Overview
The model related to IKEv2 has been extracted from
reading the IKEv2 standard in
[RFC7296] and observing some open
source implementations
The definition of the PAD model has been extracted from the specification in Section 4.4.3 of [RFC4301]. (Note that many implementations integrate PAD configuration as part of the IKEv2 configuration.)¶
The definition of the SPD model has been mainly extracted from the specification in Section 4.4.1 and Appendix D of [RFC4301].¶
The YANG data model for the IKE case is defined by the module "ietf
The YANG data model 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 (NSFs). More precisely, it consists of a list of entries, each one indicating the identity, authentication method, and credentials that a particular peer (local or remote) will use. Therefore, each entry contains identity, authentication information, and credentials of either the local NSF or the remote NSF. As a consequence, the I2NF Controller can store identity, authentication information, and credentials for the local NSF and the remote NSF.¶
Next, a list "conn-entry" is defined 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.), a list of IPsec
policies describing the type of network traffic
to be secured (local/remote subnet and ports,
etc.) and how it must be protected (ESP,
tunnel
Lastly, the "ipsec-ike" container declares a
"number
5.2.2. Example Usage
Appendix A shows an example
of IKE case configuration for an NSF, in tunnel
mode
5.2.3. YANG Module
This YANG module has normative references to [RFC5280], [RFC4301], [RFC5915], [RFC6991], [RFC7296], [RFC7383], [RFC7427], [RFC7619], [RFC8017], [ITU-T.X.690], [RFC5322], [RFC8229], [RFC8174], [RFC6960], [IKEv2
5.3. The 'ietf-i2nsf-ikeless' Module
In this section, the YANG module for the IKE-less case is described.¶
5.3.1. Data Model Overview
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 [RFC4301], though with some changes, namely:¶
The definition of the SAD model has been mainly extracted from the specification in Section 4.4.2 of [RFC4301], though with some changes, namely:¶
The notifications model has been defined using, as reference, the PF_KEYv2 specification in [RFC2367].¶
The YANG data model for the IKE-less case is defined by the module "ietf
The YANG data model consists of a unique
"ipsec-ikeless" container, which, in turn, is
composed of two additional containers: "spd" and
"sad". The "spd" container consists of a list of
entries that form the Security Policy Database.
Compared to the IKE case YANG 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 "reqid" value to link an IPsec
policy with its associated IPsec SAs since it is
otherwise a little hard to find by searching.
The "sad" container is a list of entries that form the Security Association Database. In general, each entry allows specifying both configuration information (SPI, Traffic Selectors, tunnel
In addition, the module defines a set of notifications to allow the NSF to inform the I2NSF Controller about relevant events, such as IPsec SA expiration, sequence number overflow, or bad SPI in a received packet.¶
5.3.2. Example Usage
Appendix B shows an example of an IKE-less case configuration for an NSF in transport mode (host-to-host). Additionally, Appendix C shows examples of IPsec SA expire, acquire, sequence number overflow, and bad SPI notifications.¶
6. IANA Considerations
IANA has registered the following namespaces in the "ns" subregistry within the "IETF XML Registry" [RFC3688]:¶
- URI:
- urn
:ietf :params :xml :ns :yang :ietf -i2nsf -ikec¶ - Registrant Contact:
- The IESG.¶
- XML:
- N/A, the requested URI is an XML namespace.¶
- URI:
- urn
:ietf :params :xml :ns :yang :ietf -i2nsf -ike¶ - Registrant Contact:
- The IESG.¶
- XML:
- N/A, the requested URI is an XML namespace.¶
- URI:
- urn
:ietf :params :xml :ns :yang :ietf -i2nsf -ikeless¶ - Registrant Contact:
- The IESG.¶
- XML:
- N/A, the requested URI is an XML namespace.¶
IANA has registered the following YANG modules in the "YANG Module Names" registry [RFC6020]:¶
- Name:
- ietf-i2nsf-ikec¶
- Maintained by IANA:
- N¶
- Namespace:
- urn
:ietf :params :xml :ns :yang :ietf -i2nsf -ikec¶ - Prefix:
- nsfikec¶
- Reference:
- RFC 9061¶
7. Security Considerations
First of all, this document shares all the security issues of SDN that are specified in the Security Considerations sections of [ITU-T.Y.3300] and [RFC7426].¶
On the one hand, it is important to note that there MUST exist a security association between the I2NSF Controller and the NSFs to protect the critical information (cryptographic keys, configuration parameter, etc.) exchanged between these entities. The nature of and means to create that security association is out of the scope of this document (i.e., it is part of device provisioning or onboarding).¶
On the other hand, if encryption is mandatory for all
traffic of an NSF, its default policy MUST be to drop
(DISCARD) packets to prevent cleartext packet leaks.
This default policy MUST be preconfigured in the startup
configuration datastore in the NSF
before the NSF contacts the
I2NSF Controller. Moreover, the startup configuration
datastore MUST be also preconfigured with the required
ALLOW policies that allow the NSF to communicate with the
I2NSF Controller once the NSF is deployed. This
preconfiguratio
Finally, this section is divided in two parts in order to analyze different security considerations for both cases: NSF with IKEv2 (IKE case) and NSF without IKEv2 (IKE-less case). In general, the I2NSF Controller, as typically in the SDN paradigm, is a target for different type of attacks; see [SDNSecServ] and [SDNSecurity]. Thus, the I2NSF Controller is a key entity in the infrastructure and MUST be protected accordingly. In particular, the I2NSF Controller will handle cryptographic material; thus, the attacker may try to access this information. The impact is different depending on the IKE case or the IKE-less case.¶
7.1. IKE Case
In the IKE case, the I2NSF Controller sends IKEv2 credentials (PSK, public/private keys, certificates, etc.) to the NSFs using the security association between the I2NSF Controller and NSFs. The I2NSF Controller MUST NOT store the IKEv2 credentials after distributing 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 operations). One option is to always return the same value (i.e., all 0s) if a read operation is carried out.¶
If the attacker has access to the I2NSF Controller during the period of time that key material is generated, it might have access to the key material. Since these values are used during NSF authentication in IKEv2, it may impersonate the affected NSFs. Several recommendations are important.¶
7.2. IKE-less Case
In the IKE-less case, the I2NSF Controller sends the IPsec SA information to the NSF's SAD that includes the private session keys required for integrity and encryption. The I2NSF Controller MUST NOT store the keys after distributing them. Moreover, the NSFs receiving private key material MUST NOT allow the reading of these values by any other entity (including the I2NSF Controller itself) once they have been applied (i.e., write-only operations) into the NSFs. Nevertheless, if the attacker has access to the I2NSF Controller during the period of time that key material is generated, it may obtain these values. In other words, the attacker might be able to observe the IPsec traffic and decrypt, or even modify and re-encrypt, the traffic between peers.¶
Finally, the security association between the I2NSF Controller and the NSFs MUST provide, at least, the same degree of protection as the one achieved by the IPsec SAs configured in the NSFs. In particular, the security association between the I2NSF Controller and the NSFs MUST provide forward secrecy if this property is to be achieved in the IPsec SAs that the I2NSF Controller configures in the NSFs. Similarly, the encryption algorithms used in the security association between the I2NSF Controller and the NSF MUST have, at least, the same strength (minimum strength of a 128-bit key) as the algorithms used to establish the IPsec SAs.¶
7.3. YANG Modules
The YANG modules specified in this document define a
schema for data that is designed to be accessed via
network management protocols such as NETCONF
[RFC6241] or RESTCONF
[RFC8040]. The lowest NETCONF layer
is the secure transport layer, and the
mandatory
The Network Configuration Access Control Model (NACM) [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content.¶
There are a number of data nodes defined in these YANG
modules that are writable
- For the IKE case
(ietf -i2nsf -ike ): -
- /ipsec-ike:
- The entire container in this module is sensitive to write operations. An attacker may add/modify the credentials to be used for the authentication (e.g., to impersonate an NSF), for the trust root (e.g., changing the trusted CA certificates), for the cryptographic algorithms (allowing a downgrading attack), for the IPsec policies (e.g., by allowing leaking of data traffic by changing to an allow policy), and in general, changing the IKE SA conditions and credentials between any NSF.¶
- For the IKE-less case
(ietf -i2nsf -ikeless ): -
- /ipsec-ikeless:
- The entire container in this
module is sensitive to write operations. An
attacker may add
/modify /delete any IPsec policies (e.g., by allowing leaking of data traffic by changing to an allow policy) in the /ipsec -ikeless /spd container, add /modify /delete any IPsec SAs between two NSF by means of /ipsec -ikeless /sad container, and, in general, change any IPsec SAs and IPsec policies between any NSF.¶
Some of the readable data nodes in these YANG modules may
be considered sensitive or vulnerable in some network
environments. It is thus important to control read
access (e.g., via get, get-config, or notification) to
these data nodes. These are the subtrees and data nodes
and their sensitivity
- For the IKE case
(ietf -i2nsf -ike ): -
- /ipsec-ike/pad:
- This container includes sensitive
information to read operations. This information
MUST NOT be returned to a client. For
example, cryptographic material configured in
the NSFs
(peer -authentication /pre -shared /secret and peer -authentication /digital -signature /private -key ) are already protected by the NACM extension "default -deny -all" in this document.¶
- For the IKE-less case
(ietf -i2nsf -ikeless ): -
- /ipsec
-ikeless /sad /sad -entry /ipsec -sa -config /esp -sa : - This
container includes symmetric keys for the IPsec
SAs. For example, encryption/key contains an ESP
encryption key value and encryption/iv contains
an Initialization Vector value. Similarly,
integrity/key has an ESP
integrity key value. Those values MUST NOT be
read by anyone and are protected by the NACM
extension "default
-deny -all" in this document.¶
- /ipsec
8. References
8.1. Normative References
- [IANA
-Method -Type] -
IANA, "Method Type", <https://
www >..iana .org /assignments /eap -numbers / - [IANA
-Protocols -Number] -
IANA, "Protocol Numbers", <https://
www >..iana .org /assignments /protocol -numbers / - [IKEv2
-Auth -Method] -
IANA, "IKEv2 Authentication Method", <https://
www >..iana .org /assignments /ikev2 -parameters / - [IKEv2
-Parameters] -
IANA, "Internet Key Exchange Version 2 (IKEv2) Parameters", <https://
www >..iana .org /assignments /ikev2 -parameters / - [IKEv2
-Transform -Type -1] -
IANA, "Transform Type 1 - Encryption Algorithm Transform IDs", <https://
www >..iana .org /assignments /ikev2 -parameters / - [IKEv2
-Transform -Type -3] -
IANA, "Transform Type 3 - Integrity Algorithm Transform IDs", <https://
www >..iana .org /assignments /ikev2 -parameters / - [IKEv2
-Transform -Type -4] -
IANA, "Transform Type 4 - Diffie-Hellman Group Transform IDs", <https://
www >..iana .org /assignments /ikev2 -parameters / - [ITU-T.X.690]
-
International Telecommunicati
on Union , "Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1, . - [RFC2119]
-
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10
.17487 , , <https:///RFC2119 www >..rfc -editor .org /info /rfc2119 - [RFC3947]
-
Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, "Negotiation of NAT-Traversal in the IKE", RFC 3947, DOI 10
.17487 , , <https:///RFC3947 www >..rfc -editor .org /info /rfc3947 - [RFC3948]
-
Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, DOI 10
.17487 , , <https:///RFC3948 www >..rfc -editor .org /info /rfc3948 - [RFC4301]
-
Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10
.17487 , , <https:///RFC4301 www >..rfc -editor .org /info /rfc4301 - [RFC4303]
-
Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10
.17487 , , <https:///RFC4303 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 , , <https:///RFC5280 www >..rfc -editor .org /info /rfc5280 - [RFC5322]
-
Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10
.17487 , , <https:///RFC5322 www >..rfc -editor .org /info /rfc5322 - [RFC5915]
-
Turner, S. and D. Brown, "Elliptic Curve Private Key Structure", RFC 5915, DOI 10
.17487 , , <https:///RFC5915 www >..rfc -editor .org /info /rfc5915 - [RFC6020]
-
Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10
.17487 , , <https:///RFC6020 www >..rfc -editor .org /info /rfc6020 - [RFC6241]
-
Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10
.17487 , , <https:///RFC6241 www >..rfc -editor .org /info /rfc6241 - [RFC6242]
-
Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10
.17487 , , <https:///RFC6242 www >..rfc -editor .org /info /rfc6242 - [RFC6960]
-
Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, DOI 10
.17487 , , <https:///RFC6960 www >..rfc -editor .org /info /rfc6960 - [RFC6991]
-
Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10
.17487 , , <https:///RFC6991 www >..rfc -editor .org /info /rfc6991 - [RFC7296]
-
Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10
.17487 , , <https:///RFC7296 www >..rfc -editor .org /info /rfc7296 - [RFC7383]
-
Smyslov, V., "Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation", RFC 7383, DOI 10
.17487 , , <https:///RFC7383 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 , , <https:///RFC7427 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 , , <https:///RFC7619 www >..rfc -editor .org /info /rfc7619 - [RFC7950]
-
Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10
.17487 , , <https:///RFC7950 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 , , <https:///RFC8017 www >..rfc -editor .org /info /rfc8017 - [RFC8040]
-
Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10
.17487 , , <https:///RFC8040 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 , , <https:///RFC8174 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 , , <https:///RFC8221 www >..rfc -editor .org /info /rfc8221 - [RFC8229]
-
Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation of IKE and IPsec Packets", RFC 8229, DOI 10
.17487 , , <https:///RFC8229 www >..rfc -editor .org /info /rfc8229 - [RFC8247]
-
Nir, Y., Kivinen, T., Wouters, P., and D. Migault, "Algorithm Implementation Requirements and Usage Guidance for the Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 8247, DOI 10
.17487 , , <https:///RFC8247 www >..rfc -editor .org /info /rfc8247 - [RFC8340]
-
Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10
.17487 , , <https:///RFC8340 www >..rfc -editor .org /info /rfc8340 - [RFC8341]
-
Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10
.17487 , , <https:///RFC8341 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 , , <https:///RFC8342 www >..rfc -editor .org /info /rfc8342 - [RFC8446]
-
Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10
.17487 , , <https:///RFC8446 www >..rfc -editor .org /info /rfc8446
8.2. Informative References
- [IPSECME
-CONTROLLER -IKE] -
Carrel, D. and B. Weis, "IPsec Key Exchange using a Controller", Work in Progress, Internet-Draft, draft
-carrel , , <https://-ipsecme -controller -ike -01 datatracker >..ietf .org /doc /html /draft -carrel -ipsecme -controller -ike -01 - [ITU-T.Y.3300]
-
International Telecommunicati
ons Union , "Y.3300: Framework of software-defined networking" , , <https://www >..itu .int /rec /T -REC -Y .3300 /en - [libreswan]
-
The Libreswan Project, "Libreswan VPN software", <https://
libreswan >..org / - [netconf-vpn]
-
Stefan Wallin, "Tutorial: NETCONF and YANG", , <https://
ripe68 >..ripe .net /presentations /181 -NETCONF -YANG -tutorial -43 .pdf - [ONF-OpenFlow]
-
Open Networking Foundation, "OpenFlow Switch Specification", Version 1.4.0 (Wire Protocol 0x05), , <https://
www >..opennetworking .org /wp -content /uploads /2014 /10 /openflow -spec -v1 .4 .0 .pdf - [ONF
-SDN -Architecture] -
Open Networking Foundation, "SDN architecture", Issue 1, , <https://
www >..opennetworking .org /wp -content /uploads /2013 /02 /TR _SDN _ARCH _1 .0 _06062014 .pdf - [RFC2367]
-
McDonald, D., Metz, C., and B. Phan, "PF_KEY Key Management API, Version 2", RFC 2367, DOI 10
.17487 , , <https:///RFC2367 www >..rfc -editor .org /info /rfc2367 - [RFC3688]
-
Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10
.17487 , , <https:///RFC3688 www >..rfc -editor .org /info /rfc3688 - [RFC6040]
-
Briscoe, B., "Tunnelling of Explicit Congestion Notification", RFC 6040, DOI 10
.17487 , , <https:///RFC6040 www >..rfc -editor .org /info /rfc6040 - [RFC6071]
-
Frankel, S. and S. Krishnan, "IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap", RFC 6071, DOI 10
.17487 , , <https:///RFC6071 www >..rfc -editor .org /info /rfc6071 - [RFC6437]
-
Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification", RFC 6437, DOI 10
.17487 , , <https:///RFC6437 www >..rfc -editor .org /info /rfc6437 - [RFC7149]
-
Boucadair, M. and C. Jacquenet, "Software
-Defined Networking: A Perspective from within a Service Provider Environment" , RFC 7149, DOI 10.17487 , , <https:///RFC7149 www >..rfc -editor .org /info /rfc7149 - [RFC7426]
-
Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software
-Defined Networking (SDN): Layers and Architecture Terminology" , RFC 7426, DOI 10.17487 , , <https:///RFC7426 www >..rfc -editor .org /info /rfc7426 - [RFC8192]
-
Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., and J. Jeong, "Interface to Network Security Functions (I2NSF): Problem Statement and Use Cases", RFC 8192, DOI 10
.17487 , , <https:///RFC8192 www >..rfc -editor .org /info /rfc8192 - [RFC8329]
-
Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. Kumar, "Framework for Interface to Network Security Functions", RFC 8329, DOI 10
.17487 , , <https:///RFC8329 www >..rfc -editor .org /info /rfc8329 - [SDNSecServ]
-
Scott-Hayward, S., O'Callaghan, G., and P. Sezer, "Sdn Security: A Survey", 2013 IEEE SDN for Future Networks and Services (SDN4FNS), pp. 1-7, DOI 10
.1109 , , <https:///SDN4FNS .2013 .6702553 doi >..org /10 .1109 /SDN4FNS .2013 .6702553 - [SDNSecurity]
-
Kreutz, D., Ramos, F., and P. Verissimo, "Towards secure and dependable software
-defined networks" , Proceedings of the second ACM SIGCOMM workshop on Hot Topics in software defined networking, pp. 55-60, DOI 10.1145 , , <https:///2491185 .2491199 doi >..org /10 .1145 /2491185 .2491199 - [strongswan]
-
CESNET, "strongSwan: the OpenSource IPsec-based VPN Solution", <https://
www >..strongswan .org / - [TRAN
-IPSECME -YANG] -
Tran, K., Wang, H., Nagaraj, V. K., and X. Chen, "Yang Data Model for Internet Protocol Security (IPsec)", Work in Progress, Internet-Draft, draft
-tran , , <https://-ipsecme -yang -01 datatracker >..ietf .org /doc /html /draft -tran -ipsecme -yang -01
Appendix A. XML Configuration Example for IKE Case (Gateway-to-Gateway)
This example shows an XML configuration file sent by the I2NSF Controller to establish an IPsec SA between two NSFs (see Figure 3) in tunnel mode
Appendix B. XML Configuration Example for IKE-less Case (Host-to-Host)
This example shows an XML configuration file sent by the I2NSF Controller to establish an IPsec SA between two NSFs (see Figure 4) in transport mode (host-to-host) with ESP in the IKE-less case.¶
Appendix C. XML Notification Examples
In the following, several XML files are shown to illustrate different types of notifications defined in the IKE-less YANG data model, which are sent by the NSF to the I2NSF Controller. The notifications happen in the IKE-less case.¶
Appendix D. Operational Use Case Examples
D.1. Example of IPsec SA Establishment
This appendix exemplifies the applicability of the IKE case and
IKE-less case to traditional IPsec configurations, that is,
host-to-host and gateway
Applicability of these configurations appear in current and new
networking scenarios.
For example, SD-WAN technologies are
providing dynamic and on-demand VPN connections between branch
offices or between branches and Software as a Service (SaaS)
cloud services. Besides,
Infrastructure as a Service (IaaS)
services providing virtualization environments are deployments that
often rely on IPsec to provide secure channels between virtual
instances (host-to-host) and providing VPN solutions for
virtualized networks
As can be observed in the following, the I2NSF-based IPsec management system (for IKE and IKE-less cases) exhibits various advantages:¶
D.1.1. IKE Case
Figure 9 describes the application of the IKE case when a data packet needs to be protected in the path between NSF A and NSF B:¶
If the previous steps are successful, the flow is protected by means of the IPsec SA established with IKEv2 between NSF A and NSF B.¶
D.1.2. IKE-less Case
Figure 10 describes the application of the IKE-less case when a data packet needs to be protected in the path between NSF A and NSF B:¶
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 I2NSF Controller only installs the SPD
entries in step 3 (reactive mode). In such a case, when a
data packet requires to be protected with IPsec, the NSF
that first saw the data packet will send a sadb-acquire
notification that informs the I2NSF Controller that needs
SAD entries with the IPsec SAs to process the data
packet. Again, if some of the operations installing
the new inbound
D.2. Example of the Rekeying Process in IKE-less Case
To explain an example of the rekeying process between two IPsec NSFs, A and B, assume that SPIa1 identifies the inbound IPsec SA in A and SPIb1 identifies the inbound IPsec SA in B. The rekeying process will take the following steps:¶
If some of the operations in step 1 fail (e.g., NSF A reports an error when the I2NSF Controller is trying to install a new inbound IPsec SA), the I2NSF Controller MUST perform rollback operations by removing any new inbound SA that had been successfully installed during step 1.¶
If step 1 is successful but some of the operations in step 2 fail (e.g., NSF A reports an error when the I2NSF Controller is trying to install the new outbound IPsec SA), the I2NSF Controller MUST perform a rollback operation by deleting any new outbound SA that had been successfully installed during step 2 and by deleting the inbound SAs created in step 1, in that order.¶
If the steps 1 and 2 are successful but the step 3 fails, the I2NSF Controller will avoid any rollback of the operations carried out in steps 1 and 2, since new and valid IPsec SAs were created and are functional. The I2NSF Controller MAY reattempt to remove the old inbound and outbound IPsec SAs in NSF A and NSF B several times until it receives a success or it gives up. In the last case, the old IPsec SAs will be removed when their corresponding hard lifetime is reached.¶
D.3. Example of Managing NSF State Loss in the IKE-less Case
In the IKE-less case, if the I2NSF Controller detects that an NSF has lost the IPsec state, it could follow the next steps:¶
Steps 2 and 3 can be performed at the same time at the cost of a potential packet loss. If this is not critical, then it is an optimization since the number of exchanges between the I2NSF Controller and NSFs is lower.¶
Acknowledgements
Authors want to thank Paul Wouters, Valery Smyslov, Sowmini Varadhan, David Carrel, Yoav Nir, Tero Kivinen, Martin Bjorklund, Graham Bartlett, Sandeep Kampati, Linda Dunbar, Mohit Sethi, Martin Bjorklund, Tom Petch, Christian Hopps, Rob Wilton, Carlos J. Bernardos, Alejandro Perez-Mendez, Alejandro Abad-Carrascosa, Ignacio Martinez, Ruben Ricart, and all IESG members that have reviewed this document for their valuable comments.¶