RFC 9061
A YANG Data Model for IPsec Flow Protection Based on Software-Defined Networking (SDN)
RFC 9061: A YANG Data Model for IPsec Flow Protection Based on Software-Defined Networking (SDN) 🎀
Okay bestie, welcome to part 1 of 20 🧚 more parts are coming, so don't leave yet!
This one is an IETF doc (Request for Comments: 9061, ISSN 2070-1721) in the Standards Track category, dated July 2021. The authors are R. Marin-Lopez and G. Lopez-Millan from the University of Murcia, plus F. Pereniguez-Garcia from the University Defense Center 🫶. The title block doesn't list anything it obsoletes or updates, so there's no drama there 💅
Abstract
okay so this doc explains how to protect flows with IPsec (that means integrity AND confidentiality 🔐) using an Interface to Network Security Function (I2NSF) Controller. It covers the two big well-known IPsec setups: gateway-to-gateway and host-to-host 🌸 The service lets an I2NSF Controller configure and monitor IPsec Security Associations (IPsec SAs) on one or several flow-based Network Security Functions (NSFs) that use IPsec to protect data traffic. It's giving centralized control, no cap ✨
This doc focuses on the I2NSF NSF-Facing Interface. It gives YANG data models for configuring the IPsec databases: the Security Policy Database (SPD), the Security Association Database (SAD), the Peer Authorization Database (PAD), and Internet Key Exchange Version 2 (IKEv2) 🦋 The result is IPsec SA establishment with minimal intervention from the network administrator, which is so iconic for them 👑 The doc defines three YANG modules, but it does not define any new protocol 💖
Status of This Memo
This is an Internet Standards Track document 🌈
It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It went through public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check Section 2 of RFC 7841 📚
For the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc9061 🔗
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://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, because they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they are provided without warranty as described in the Simplified BSD License. 💜
Table of Contents 🗺️
1. Introduction
2. Terminology
2.1. Requirements Language
3. SDN-Based IPsec Management Description
3.1. IKE Case: IKEv2/IPsec in the NSF
3.2. IKE-less Case: IPsec (No IKEv2) in the NSF
4. IKE Case vs. IKE-less Case
4.1. Rekeying Process
4.2. NSF State Loss
4.3. NAT Traversal
4.4. NSF Registration and Discovery
5. YANG Configuration Data Models
5.1. The 'ietf-i2nsf-ikec' Module
5.1.1. Data Model Overview
5.1.2. YANG Module
5.2. The 'ietf-i2nsf-ike' Module
5.2.1. Data Model Overview
5.2.2. Example Usage
5.2.3. YANG Module
5.3. The 'ietf-i2nsf-ikeless' Module
5.3.1. Data Model Overview
5.3.2. Example Usage
5.3.3. YANG Module
6. IANA Considerations
7. Security Considerations
7.1. IKE Case
7.2. IKE-less Case
7.3. YANG Modules
8. References
8.1. Normative References
8.2. Informative References
Appendix A. XML Configuration Example for IKE Case
(Gateway-to-Gateway)
Appendix B. XML Configuration Example for IKE-less Case
(Host-to-Host)
Appendix C. XML Notification Examples
Appendix D. Operational Use Case Examples
D.1. Example of IPsec SA Establishment
D.1.1. IKE Case
D.1.2. IKE-less Case
D.2. Example of the Rekeying Process in IKE-less Case
D.3. Example of Managing NSF State Loss in the IKE-less Case
Acknowledgements
Authors' Addresses1. Introduction ✨
Software-Defined Networking (SDN) is an architecture that lets admins directly program, orchestrate, control, and manage network resources through software 💻 SDN moves control of network resources to one centralized entity, the SDN Controller. SDN Controllers configure and manage distributed network resources, and they give SDN applications an abstracted view of those resources. The apps can then customize and automate operations (management included) on the abstracted resources, all programmatically through this interface [RFC7149] [ITU-T.Y.3300] [ONF-SDN-Architecture] [ONF-OpenFlow] 🧠
Lately, a bunch of network scenarios need a centralized way to handle different security aspects. Software-Defined WANs (SD-WANs) are a big example 🌐 SD-WANs are SDN extensions that add software abstractions for building secure network overlays over traditional WAN and branch networks. They use IPsec [RFC4301] as their underlying security protocol 🔐 The goal is flexible, automated deployment from one central point, so you get on-demand network security services like IPsec Security Association (IPsec SA) management. Also, Section 4.3.3 ("Client-Specific Security Policy in Cloud VPNs") of [RFC8192] describes another use case, this time for a cloud data center. The use case in [RFC8192] says that "dynamic key management is critical for securing the VPN and the distribution of policies". These VPNs can be set up with IPsec, and managing IPsec SAs in data centers from a centralized entity is a scenario where the current specification may be applicable 🏢
So, as SDN-based scenarios grow and network resources get deployed in an autonomous way, a mechanism for managing IPsec SAs from a centralized entity matters more and more to the industry 📈
The Interface to Network Security Functions (I2NSF) charter answers this need. It says the goal of the working group is "to define a set of software interfaces and data models for controlling and monitoring aspects of physical and virtual NSFs" 🎯 As [RFC8192] defines it, a Network Security Function (NSF) is "a function that is used to ensure integrity, confidentiality, or availability of network communication; to detect unwanted network activity; or to block, or at least mitigate, the effects of unwanted activity". This doc pays special attention to flow-based NSFs that ensure integrity and confidentiality with IPsec 💜
Here's the tea: Section 3.1.9 of [RFC8192] says "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 SDN, the I2NSF framework [RFC8329] defines a centralized entity, the I2NSF Controller, which manages one or more NSFs through an I2NSF NSF-Facing Interface. This doc defines an architecture that lets the I2NSF Controller carry out the key management procedures. More specifically, it defines three YANG data models for the I2NSF NSF-Facing Interface, which let the I2NSF Controller configure and monitor IPsec-enabled, flow-based NSFs 🦋
The IPsec architecture [RFC4301] clearly separates the processing that provides security services to IP packets from the key management procedures that establish IPsec SAs. That separation lets the key management procedures be centralized in the I2NSF Controller 🌸 This doc considers two typical scenarios for autonomously managing IPsec SAs: gateway-to-gateway and host-to-host [RFC6071]. In these cases, hosts, gateways, or both may act as NSFs. The host-to-gateway scenario is out of scope because it's complicated 🙈 The complexity comes from the fact that the host may not be under the control of the I2NSF Controller, so it isn't configurable. That said, the I2NSF interfaces defined here can be considered a starting point for analyzing and building a solution for the host-to-gateway scenario 🍓
For the YANG data models on the I2NSF NSF-Facing Interface, this doc considers two general cases:
- IKE case. The NSF implements the Internet Key Exchange Version 2 (IKEv2) protocol and the IPsec databases: the Security Policy Database (SPD), the Security Association Database (SAD), and the Peer Authorization Database (PAD). The I2NSF Controller is in charge of provisioning the NSF with the required information in the SPD and PAD (e.g., IKE credentials) and the IKE protocol itself (e.g., parameters for the IKE_SA_INIT negotiation).
- IKE-less case. The NSF only implements the IPsec databases (no IKE implementation). The I2NSF Controller provides the required parameters to create valid entries in the SPD and the SAD of the NSF. So the NSF only has support for IPsec, and key management functionality moves to the I2NSF Controller 🧚
In both cases, a YANG data model for the I2NSF NSF-Facing Interface is required to carry out this provisioning securely between the I2NSF Controller and the NSF 🔒 This doc uses YANG data modeling language version 1.1 [RFC7950]. It's based on YANG data models defined in [netconf-vpn] and [TRAN-IPSECME-YANG], and on the data structures defined in [RFC4301] and [RFC7296]. It defines the required interfaces with a YANG data model for configuration and state data for IKE, PAD, SPD, and SAD (see Sections 5.1, 5.2, and 5.3). The proposed YANG data model conforms to the Network Management Datastore Architecture (NMDA) defined in [RFC8342]. Examples of using these data models are in Appendices A, B, and C 📖
Okay, the main objectives of this doc, in summary:
- To describe the architecture for I2NSF-based IPsec management, which allows the establishment and management of IPsec Security Associations from the I2NSF Controller, in order to protect specific data flows between two flow-based NSFs implementing IPsec 💅
- To map this architecture to the I2NSF framework 🗺️
- To define the interfaces required to manage and monitor the IPsec SAs in the NSF from an I2NSF Controller. YANG data models are defined for configuration and state data for IPsec and IKEv2 management through the I2NSF NSF-Facing Interface. The YANG data models can be used via existing protocols, such as the Network Configuration Protocol (NETCONF) [RFC6241] or RESTCONF [RFC8040]. So this doc defines three YANG modules (see Section 5) but does not define any new protocol 🎀
reminder bestie: three YANG modules, zero new protocols. The whole point is reusing what already exists 🫶
2. Terminology ✨
Okay so bestie, before we get into the juicy stuff, we need to agree on our vocab 💅 This doc borrows terms from a bunch of other specs: [ITU-T.Y.3300], [RFC8192], [RFC4301], [RFC6437], [RFC7296], [RFC6241], and [RFC8329]. Think of it as a shared group chat where everyone already knows the lingo 🫶
The following term is defined in [ITU-T.Y.3300]:
- Software-Defined Networking (SDN)
The following terms are defined in [RFC8192]:
- Network Security Function (NSF)
- flow-based NSF
The following terms are defined in [RFC4301]:
- Peer Authorization Database (PAD)
- Security Association Database (SAD)
- Security Policy Database (SPD)
The following two terms are related or have identical definition/usage in [RFC6437]:
- flow
- traffic flow
The following term is defined in [RFC7296]:
- Internet Key Exchange Version 2 (IKEv2)
The following terms are defined in [RFC6241]:
- configuration data
- configuration datastore
- state data
- startup configuration datastore
- running configuration datastore
2.1. Requirements Language 🦋
Here's where we talk about the BCP 14 key words, the ones that carry real weight 🔥 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. So if you see them in ALL CAPS, that's a real requirement, no cap 💖
3. SDN-Based IPsec Management Description 🌈
Remember Section 1? Two cases are on the menu, and it all depends 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 💜
Okay, so in this case the NSF implements IPsec with IKEv2 support 🧚 The I2NSF Controller is basically the manager bestie 👑 It handles IPsec connection information: figuring out 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. It also hands over other IKEv2 configuration parameters (e.g., cryptographic algorithms for establishing an IKEv2 SA) to the NSF so the IKEv2 negotiation can actually happen.
With these entries in place, the IKEv2 implementation can get to work and establish the IPsec SAs ✨ The I2NSF User sets the IPsec requirements and info about the endpoints (through the I2NSF Consumer-Facing Interface [RFC8329]). Then the I2NSF Controller translates those requirements into IKEv2, SPD, and PAD entries that get installed into the NSF (through the I2NSF NSF-Facing Interface). After that, the NSF can just run IKEv2 to set up the required IPsec SA whenever the traffic flow needs protection. Figure 1 shows the different layers and what they do 🎀
+-------------------------------------------+
| IPsec Management System | I2NSF User
+-------------------------------------------+
|
| I2NSF Consumer-Facing
| Interface
+-------------------------------------------+
| IKEv2 Configuration, PAD and SPD Entries | I2NSF
| Distribution | Controller
+-------------------------------------------+
|
| I2NSF NSF-Facing
| Interface
+-------------------------------------------+
| IKEv2 | IPsec(PAD, SPD) | Network
|-------------------------------------------| Security
| IPsec Data Protection and Forwarding | Function
+-------------------------------------------+
Figure 1: IKE Case: IKE/IPsec in the NSFI2NSF-based IPsec flow protection services give you dynamic and flexible management of IPsec SAs in flow-based NSFs 🦋 To support this 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, so the I2NSF Controller has to do the IKEv2 security functions and manage 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 those requirements into SPD and SAD entries, which get installed in the NSF. PAD entries are not required, since there is no IKEv2 in the NSF 🙈
+-----------------------------------------+
| IPsec Management System | I2NSF User
+-----------------------------------------+
|
| I2NSF Consumer-Facing Interface
|
+-----------------------------------------+
| SPD and SAD Entries | I2NSF
| Distribution | Controller
+-----------------------------------------+
|
| I2NSF NSF-Facing Interface
|
+-----------------------------------------+
| IPsec (SPD, SAD) | Network
|-----------------------------------------| Security
| IPsec Data Protection and Forwarding | Function
+-----------------------------------------+
Figure 2: IKE-less Case: IPsec (No IKEv2) in the NSFIn 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). Yes, MUST, bestie, that one's non-negotiable 🫶
Specifically, the IKE-less case assumes that the I2NSF Controller has to perform some security functions that IKEv2 typically does, namely (non-exhaustive list):
- Initialization Vector (IV) generation
- prevention of counter resets for the same key
- generation of pseudorandom cryptographic keys for the IPsec SAs
- generation of the IPsec SAs when required based on notifications (i.e., sadb-acquire) from the NSF
- rekey of the IPsec SAs based on notifications from the NSF (i.e., expire)
- NAT traversal discovery and management
Additionally to these functions, another set of tasks must be performed by the I2NSF Controller (non-exhaustive list):
- IPsec SA's Security Parameter Index (SPI) random generation
- cryptographic algorithm selection
- usage of extended sequence numbers
- establishment of proper Traffic Selectors
4. IKE Case vs. IKE-less Case ⚖️
Okay, the big showdown 💖 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. Gateways typically deploy an IKEv2/IPsec implementation, and hosts can easily install one too. The catch is that the NSF needs more resources to use IKEv2, like memory for the IKEv2 implementation and computation, since each IPsec Security Association rekeying MAY involve a Diffie-Hellman (DH) exchange 🧠
Alternatively, the IKE-less case is the one that helps deployment on resource-constrained NSFs 🌷 Plus, IKEv2 doesn't need to be performed in gateway-to-gateway and host-to-host scenarios under the same I2NSF Controller (see Appendix D.1) ✨ On the flip side, the complexity of creating and managing IPsec SAs gets shifted onto the I2NSF Controller, since IKEv2 isn't in the NSF. As a result, this may mean a more complex implementation on the controller side compared to the IKE case 😵💫 For example, the I2NSF Controller has to deal with the latency on the path between it and the NSF (to handle things like rekey) or with creating and installing new IPsec SAs. But this isn't specific to this work; it's a general thing in any SDN-based network 🌍 In summary, this complexity may create some scalability and performance issues when the number of NSFs is high 📈
Still, literature on SDN-based network management with a centralized controller (like the I2NSF Controller) is well aware of scalability and performance issues, and solutions have already been provided and discussed (e.g., hierarchical controllers, multiple replicated controllers, dedicated high-speed management networks, etc.) 🦋 In the context of I2NSF-based IPsec management, one way to cut down latency and ease some performance issues is 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 from an NSF that needs a new IPsec SA) before installing the IPsec SA (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 for the initial configuration (i.e., IKEv2, PAD, and SPD entries) it provides 🫶 Other solutions, such as Controller-IKE [IPSECME-CONTROLLER-IKE], propose that NSFs give their DH public keys to the I2NSF Controller so it can distribute all public keys to all peers. All peers can then calculate a unique pairwise secret for each other peer, and there are no inter-NSF messages 🤯 A rekey mechanism is further described in [IPSECME-CONTROLLER-IKE] 🎀
In terms of security, the IKE case has better security properties than the IKE-less case, as discussed in Section 7. The main reason? The NSFs generate the session keys, not the I2NSF Controller 🔐
4.1. Rekeying Process 🔄
Rekeying IPsec SAs is a seriously important operation in IPsec SA 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 itself (IKE-less case). Depending on the case, the rekey process is actually 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). So IPsec connections will just live on 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 about 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 own initiative, based on lifetime state data obtained from the NSF. How the I2NSF Controller implements its rekey algorithm is out of scope for this document 🙈 But an example of how this rekey could be performed is described in Appendix D.2 🧚
4.2. NSF State Loss 💔
okay so if one of the NSFs restarts, it loses its IPsec state (that's the affected NSF 😭). By default, the I2NSF Controller can assume that ALL the state is gone, which means it has to send IKEv2, SPD, and PAD info to the NSF in the IKE case, and SPD and SAD info in the IKE-less case. 🧚
In both cases, the I2NSF Controller already knows which NSF is affected. Maybe the NETCONF/TCP connection with it broke, or the Controller got a sadb-bad-spi notification from a particular NSF, etc. 👀 It also keeps a list of the NSFs that have IPsec SAs with the affected one, so it knows exactly which IPsec SAs are affected. main character energy 💅
In the IKE case, the I2NSF Controller may need to configure the affected NSF with the new IKEv2, SPD, and PAD info. Or, ✨ IKEv2 configuration MAY be made permanent between NSF reboots without compromising security by means of the startup configuration datastore in the NSF. Then every time an NSF reboots, it uses that configuration, so it never has to bother the I2NSF Controller, which is lowkey iconic 🎀. 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 that were 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 that have 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 (not my problem bestie 🙈). Still, an example of how this could be performed is described in Appendix D.3. 📚
4.3. NAT Traversal 🦋
In the IKE case, IKEv2 already has a mechanism to detect whether some of the peers, or both, are behind a NAT. IKEv2 really said "I got this" 💁. In that 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 doesn't get help from the IKEv2 implementation to detect whether it's behind a NAT. If the NSF has no other mechanism to detect this, 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. That view is built either by requesting info from the NSFs under its control, or by info pushed from the NSFs to the I2NSF Controller. Based on this info, the I2NSF Controller MAY guess if there's a NAT configured between two hosts and apply the required policies to both NSFs, besides activating 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 doesn't 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 is the process of giving the I2NSF Controller info about a valid NSF, such as its certificate, IP address, etc. 🪪 This info goes into 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. That way, when the NSF starts up and connects to the I2NSF Controller, it knows 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, like which cryptographic suites it supports, its authentication method, whether it supports the IKE case and/or the IKE-less case, etc. 🔍
The registration and discovery processes are out of 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 needs modeling of IKEv2 configuration parameters, SPD and PAD, while the IKE-less case needs 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-i2nsf-ikeless (Section 5.3, IKE-less case). Since the module ietf-i2nsf-ikec only has typedef and groupings common to the other modules, a simplified view of the ietf-i2nsf-ike and ietf-i2nsf-ikeless modules is shown. ✨
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-Protocols-Number], [IKEv2-Parameters], [IKEv2-Transform-Type-1], and [IKEv2-Transform-Type-3]. 🧾
<CODE BEGINS> file "ietf-i2nsf-ikec@2021-07-14.yang"
module ietf-i2nsf-ikec {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikec";
prefix nsfikec;
import ietf-inet-types {
prefix inet;
reference
"RFC 6991: Common YANG Data Types.";
}
organization
"IETF I2NSF Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/i2nsf/>
WG List: <mailto:i2nsf@ietf.org>
Author: Rafael Marin-Lopez
<mailto:rafa@um.es>
Author: Gabriel Lopez-Millan
<mailto:gabilm@um.es>
Author: Fernando Pereniguez-Garcia
<mailto:fernando.pereniguez@cud.upct.es>
";
description
"Common data model for the IKE and IKE-less cases
defined by the SDN-based IPsec flow protection service.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this
document are to be interpreted as described in BCP 14
(RFC 2119) (RFC 8174) when, and only when, they appear
in all capitals, as shown here.
Copyright (c) 2021 IETF Trust and the persons
identified as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC 9061; see
the RFC itself for full legal notices.";
revision 2021-07-14 {
description
"Initial version.";
reference
"RFC 9061: A YANG Data Model for IPsec Flow Protection
Based on Software-Defined Networking (SDN).";
}
typedef encr-alg-t {
type uint16;
description
"The encryption algorithm is specified with a 16-bit
number extracted from the IANA registry. The acceptable
values MUST follow the requirement levels for
encryption algorithms for ESP and IKEv2.";
reference
"IANA: Internet Key Exchange Version 2 (IKEv2) Parameters,
IKEv2 Transform Attribute Types, Transform Type 1 -
Encryption Algorithm Transform IDs
RFC 8221: Cryptographic Algorithm Implementation
Requirements and Usage Guidance for Encapsulating
Security Payload (ESP) and Authentication Header
(AH)
RFC 8247: Algorithm Implementation Requirements and Usage
Guidance for the Internet Key Exchange Protocol
Version 2 (IKEv2).";
}
typedef intr-alg-t {
type uint16;
description
"The integrity algorithm is specified with a 16-bit
number extracted from the IANA registry.
The acceptable values MUST follow the requirement
levels for integrity algorithms for ESP and IKEv2.";
reference
"IANA: Internet Key Exchange Version 2 (IKEv2) Parameters,
IKEv2 Transform Attribute Types, Transform Type 3 -
Integrity Algorithm Transform IDs
RFC 8221: Cryptographic Algorithm Implementation
Requirements and Usage Guidance for Encapsulating
Security Payload (ESP) and Authentication Header
(AH)
RFC 8247: Algorithm Implementation Requirements and Usage
Guidance for the Internet Key Exchange Protocol
Version 2 (IKEv2).";
}
typedef ipsec-mode {
type enumeration {
enum transport {
description
"IPsec transport mode. No Network Address
Translation (NAT) support.";
}
enum tunnel {
description
"IPsec tunnel mode.";
}
}
description
"Type definition of IPsec mode: transport or
tunnel.";
reference
"RFC 4301: Security Architecture for the Internet Protocol,
Section 3.2.";
}
typedef esp-encap {
type enumeration {
enum espintcp {
description
"ESP in TCP encapsulation.";
reference
"RFC 8229: TCP Encapsulation of IKE and
IPsec Packets.";
}
enum espinudp {
description
"ESP in UDP encapsulation.";
reference
"RFC 3948: UDP Encapsulation of IPsec ESP
Packets.";
}
enum none {
description
"No ESP encapsulation.";
}
}
description
"Types of ESP encapsulation when Network Address
Translation (NAT) may be present between two NSFs.";
reference
"RFC 8229: TCP Encapsulation of IKE and IPsec Packets
RFC 3948: UDP Encapsulation of IPsec ESP Packets.";
}
typedef ipsec-protocol-params {
type enumeration {
enum esp {
description
"IPsec ESP protocol.";
}
}
description
"Only the Encapsulation Security Protocol (ESP) is
supported, but it could be extended in the future.";
reference
"RFC 4303: IP Encapsulating Security Payload (ESP).";
}okay so this is where the YANG module gets into the actual building blocks: the typedefs and groupings that define lifetime actions, traffic directions, SPD actions, and selectors 💅🎀
typedef lifetime-action {
type enumeration {
enum terminate-clear {
description
"Terminates the IPsec SA and allows the
packets through.";
}
enum terminate-hold {
description
"Terminates the IPsec SA and drops the
packets.";
}
enum replace {
description
"Replaces the IPsec SA with a new one:
rekey.";
}
}
description
"When the lifetime of an IPsec SA expires, an action
needs to be performed for the IPsec SA that
reached the lifetime. There are three possible
options: terminate-clear, terminate-hold, and
replace.";
reference
"RFC 4301: Security Architecture for the Internet Protocol,
Section 4.5.";
}
typedef ipsec-traffic-direction {
type enumeration {
enum inbound {
description
"Inbound traffic.";
}
enum outbound {
description
"Outbound traffic.";
}
}
description
"IPsec traffic direction is defined in
two directions: inbound and outbound.
From an NSF perspective, inbound and
outbound are defined as mentioned
in Section 3.1 in RFC 4301.";
reference
"RFC 4301: Security Architecture for the Internet Protocol,
Section 3.1.";
}
typedef ipsec-spd-action {
type enumeration {
enum protect {
description
"PROTECT the traffic with IPsec.";
}
enum bypass {
description
"BYPASS the traffic. The packet is forwarded
without IPsec protection.";
}
enum discard {
description
"DISCARD the traffic. The IP packet is
discarded.";
}
}
description
"The action when traffic matches an IPsec security
policy. According to RFC 4301, there are three
possible values: BYPASS, PROTECT, and DISCARD.";
reference
"RFC 4301: Security Architecture for the Internet Protocol,
Section 4.4.1.";
}
typedef ipsec-inner-protocol {
type union {
type uint8;
type enumeration {
enum any {
value 256;
description
"Any IP protocol number value.";
}
}
}
default "any";
description
"IPsec protection can be applied to specific IP
traffic and Layer 4 traffic (TCP, UDP, SCTP, etc.)
or ANY protocol in the IP packet payload.
The IP protocol number is specified with a uint8
or ANY defining an enumerate with value 256 to
indicate the protocol number. Note that in case
of IPv6, the protocol in the IP packet payload
is indicated in the Next Header field of the IPv6
packet.";
reference
"RFC 4301: Security Architecture for the Internet Protocol,
Section 4.4.1.1
IANA: Protocol Numbers.";
}
grouping encap {
description
"This group of nodes allows defining of the type of
encapsulation in case NAT traversal is
required and includes port information.";
leaf espencap {
type esp-encap;
default "none";
description
"ESP in TCP, ESP in UDP, or ESP in TLS.";
}
leaf sport {
type inet:port-number;
default "4500";
description
"Encapsulation source port.";
}
leaf dport {
type inet:port-number;
default "4500";
description
"Encapsulation destination port.";
}
leaf-list oaddr {
type inet:ip-address;
description
"If required, this is the original address that
was used before NAT was applied over the packet.";
}
reference
"RFC 3947: Negotiation of NAT-Traversal in the IKE
RFC 8229: TCP Encapsulation of IKE and IPsec Packets.";
}
grouping lifetime {
description
"Different lifetime values limited to an IPsec SA.";
leaf time {
type uint32;
units "seconds";
default "0";
description
"Time in seconds since the IPsec SA was added.
For example, if this value is 180 seconds, it
means the IPsec SA expires in 180 seconds since
it was added. The value 0 implies infinite.";
}
leaf bytes {
type uint64;
default "0";
description
"If the IPsec SA processes the number of bytes
expressed in this leaf, the IPsec SA expires and
SHOULD be rekeyed. The value 0 implies
infinite.";
}
leaf packets {
type uint32;
default "0";
description
"If the IPsec SA processes the number of packets
expressed in this leaf, the IPsec SA expires and
SHOULD be rekeyed. The value 0 implies
infinite.";
}
leaf idle {
type uint32;
units "seconds";
default "0";
description
"When an NSF stores an IPsec SA, it
consumes system resources. For an idle IPsec SA, this
is a waste of resources. If the IPsec SA is idle
during this number of seconds, the IPsec SA
SHOULD be removed. The value 0 implies
infinite.";
}
reference
"RFC 4301: Security Architecture for the Internet Protocol,
Section 4.4.2.1.";
}
grouping port-range {
description
"This grouping defines a port range, such as that
expressed in RFC 4301, for example, 1500 (Start
Port Number)-1600 (End Port Number).
A port range is used in the Traffic Selector.";
leaf start {
type inet:port-number;
description
"Start port number.";
}
leaf end {
type inet:port-number;
must '. >= ../start' {
error-message
"The end port number MUST be equal or greater
than the start port number.";
}
description
"End port number. To express a single port, set
the same value as start and end.";
}
reference
"RFC 4301: Security Architecture for the Internet Protocol,
Section 4.4.1.2.";
}
grouping tunnel-grouping {
description
"The parameters required to define the IP tunnel
endpoints when IPsec SA requires tunnel mode. The
tunnel is defined by two endpoints: the local IP
address and the remote IP address.";
leaf local {
type inet:ip-address;
mandatory true;
description
"Local IP address' tunnel endpoint.";
}
leaf remote {
type inet:ip-address;
mandatory true;
description
"Remote IP address' tunnel endpoint.";
}
leaf df-bit {
type enumeration {
enum clear {
description
"Disable the Don't Fragment (DF) bit
in the outer header. This is the
default value.";
}
enum set {
description
"Enable the DF bit in the outer header.";
}
enum copy {
description
"Copy the DF bit to the outer header.";
}
}
default "clear";
description
"Allow configuring the DF bit when encapsulating
tunnel mode IPsec traffic. RFC 4301 describes
three options to handle the DF bit during
tunnel encapsulation: clear, set, and copy from
the inner IP header. This MUST be ignored or
has no meaning when the local/remote
IP addresses are IPv6 addresses.";
reference
"RFC 4301: Security Architecture for the Internet Protocol,
Section 8.1.";
}
leaf bypass-dscp {
type boolean;
default "true";
description
"If true, to copy the Differentiated Services Code
Point (DSCP) value from inner header to outer header.
If false, to map DSCP values
from an inner header to values in an outer header
following ../dscp-mapping.";
reference
"RFC 4301: Security Architecture for the Internet Protocol,
Section 4.4.1.2.";
}
list dscp-mapping {
must '../bypass-dscp = "false"';
key "id";
ordered-by user;
leaf id {
type uint8;
description
"The index of list with the
different mappings.";
}
leaf inner-dscp {
type inet:dscp;
description
"The DSCP value of the inner IP packet. If this
leaf is not defined, it means ANY inner DSCP value.";
}
leaf outer-dscp {
type inet:dscp;
default "0";
description
"The DSCP value of the outer IP packet.";
}
description
"A list that represents an array with the mapping from the
inner DSCP value to outer DSCP value when bypass-dscp is
false. To express a default mapping in the list where any
other inner dscp value is not matching a node in the list,
a new node has to be included at the end of the list where
the leaf inner-dscp is not defined (ANY) and the leaf
outer-dscp includes the value of the mapping. If there is
no value set in the leaf outer-dscp, the default value for
this leaf is 0.";
reference
"RFC 4301: Security Architecture for the Internet Protocol,
Section 4.4.1.2 and Appendix C.";
}
}
grouping selector-grouping {
description
"This grouping contains the definition of a Traffic
Selector, which is used in the IPsec policies and
IPsec SAs.";
leaf local-prefix {
type inet:ip-prefix;
mandatory true;
description
"Local IP address prefix.";
}
leaf remote-prefix {
type inet:ip-prefix;
mandatory true;
description
"Remote IP address prefix.";
}
leaf inner-protocol {
type ipsec-inner-protocol;
default "any";
description
"Inner protocol that is going to be
protected with IPsec.";
}
list local-ports {
key "start end";
uses port-range;
description
"List of local ports. When the inner
protocol is ICMP, this 16-bit value
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 {
key "start end";
uses port-range;
description
"List of remote ports. When the upper layer
protocol is ICMP, this 16-bit value represents
code and type. If this list is not defined,
it is assumed that start and end are 0 by
default (any port).";
}
reference
"RFC 4301: Security Architecture for the Internet Protocol,
Section 4.4.1.2.";
} grouping ipsec-policy-grouping {
description
"Holds configuration information for an IPsec SPD
entry.";
leaf anti-replay-window-size {
type uint32;
default "64";
description
"To set the anti-replay window size.
The default value is set
to 64, following the recommendation in RFC 4303.";
reference
"RFC 4303: IP Encapsulating Security Payload (ESP),
Section 3.4.3.";
}
container traffic-selector {
description
"Packets are selected for
processing actions based on Traffic Selector
values, which refer to IP and inner protocol
header information.";
uses selector-grouping;
reference
"RFC 4301: Security Architecture for the Internet Protocol,
Section 4.4.4.1.";
}
container processing-info {
description
"SPD processing. If the required processing
action is protect, it contains the required
information to process the packet.";
leaf action {
type ipsec-spd-action;
default "discard";
description
"If bypass or discard, container
ipsec-sa-cfg is empty.";
}
container ipsec-sa-cfg {
when "../action = 'protect'";
description
"IPsec SA configuration included in the SPD
entry.";
leaf pfp-flag {
type boolean;
default "false";
description
"Each selector has a Populate From
Packet (PFP) flag. If asserted for a
given selector X, the flag indicates
that the IPsec SA to be created should
take its value (local IP address,
remote IP address, Next Layer
Protocol, etc.) for X from the value
in the packet. Otherwise, the IPsec SA
should take its value(s) for X from
the value(s) in the SPD entry.";
}
leaf ext-seq-num {
type boolean;
default "false";
description
"True if this IPsec SA is using extended
sequence numbers. If true, the 64-bit
extended sequence number counter is used;
if false, the normal 32-bit sequence
number counter is used.";
}
leaf seq-overflow {
type boolean;
default "false";
description
"The flag indicating whether
overflow of the sequence number
counter should prevent transmission
of additional packets on the IPsec
SA (false) and, therefore, needs to
be rekeyed or whether rollover is
permitted (true). If Authenticated
Encryption with Associated Data
(AEAD) is used (leaf
esp-algorithms/encryption/algorithm-type),
this flag MUST be false. Setting this
flag to true is strongly discouraged.";
}
leaf stateful-frag-check {
type boolean;
default "false";
description
"Indicates whether (true) or not (false)
stateful fragment checking applies to
the IPsec SA to be created.";
}
leaf mode {
type ipsec-mode;
default "transport";
description
"IPsec SA has to be processed in
transport or tunnel mode.";
}
leaf protocol-parameters {
type ipsec-protocol-params;
default "esp";
description
"Security protocol of the IPsec SA.
Only ESP is supported, but it could be
extended in the future.";
}
container esp-algorithms {
when "../protocol-parameters = 'esp'";
description
"Configuration of Encapsulating
Security Payload (ESP) parameters and
algorithms.";
leaf-list integrity {
type intr-alg-t;
default "0";
ordered-by user;
description
"Configuration of ESP authentication
based on the specified integrity
algorithm. With AEAD encryption
algorithms, the integrity node is
not used.";
reference
"RFC 4303: IP Encapsulating Security Payload (ESP),
Section 3.2.";
}
list encryption {
key "id";
ordered-by user;
leaf id {
type uint16;
description
"An identifier that unequivocally identifies each
entry of the list, i.e., an encryption algorithm
and its key length (if required).";
}
leaf algorithm-type {
type encr-alg-t;
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
"Encryption or AEAD algorithm for the
IPsec SAs. This list is ordered
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
"RFC 4303: IP Encapsulating Security Payload (ESP),
Section 3.2.";
}
leaf tfc-pad {
type boolean;
default "false";
description
"If Traffic Flow Confidentiality
(TFC) padding for ESP encryption
can be used (true) or not (false).";
reference
"RFC 4303: IP Encapsulating Security Payload (ESP),
Section 2.7.";
}
reference
"RFC 4303: IP Encapsulating Security Payload (ESP).";
}
container tunnel {
when "../mode = 'tunnel'";
uses tunnel-grouping;
description
"IPsec tunnel endpoints definition.";
}
}
reference
"RFC 4301: Security Architecture for the Internet Protocol,
Section 4.4.1.2.";
}
}
}
<CODE ENDS>5.2. The 'ietf-i2nsf-ike' Module 🎀
Okay so this bit is all about the YANG module for the IKE case, and I'm lowkey obsessed with how it's organised. ✨
5.2.1. Data Model Overview ✨
okay bestie, the IKEv2 part of this model was built by reading the IKEv2 standard in [RFC7296] and then peeking at how open source implementations like strongSwan [strongswan] or Libreswan [libreswan] actually do it 🧚 real-world vibes only 💅
The PAD model came from Section 4.4.3 of [RFC4301] 🎀 ngl a lot of implementations just bake PAD config right into the IKEv2 config, so don't be shook if you spot it there 🙈
The SPD model is mostly pulled from Section 4.4.1 and Appendix D of [RFC4301] 🦋
The YANG data model for the IKE case is the ietf-i2nsf-ike module 💖 here's the tree diagram, drawn with the YANG tree diagram notation from [RFC8340] 🌸
module: ietf-i2nsf-ike
+--rw ipsec-ike
+--rw pad
| +--rw pad-entry* [name]
| +--rw name string
| +--rw (identity)
| | +--:(ipv4-address)
| | | +--rw ipv4-address? inet:ipv4-address
| | +--:(ipv6-address)
| | | +--rw ipv6-address? inet:ipv6-address
| | +--:(fqdn-string)
| | | +--rw fqdn-string? inet:domain-name
| | +--:(rfc822-address-string)
| | | +--rw rfc822-address-string? string
| | +--:(dnx509)
| | | +--rw dnx509? binary
| | +--:(gnx509)
| | | +--rw gnx509? binary
| | +--:(id-key)
| | | +--rw id-key? binary
| | +--:(id-null)
| | +--rw id-null? empty
| +--rw auth-protocol? auth-protocol-type
| +--rw peer-authentication
| +--rw auth-method? auth-method-type
| +--rw eap-method
| | +--rw eap-type uint64
| +--rw pre-shared
| | +--rw secret? yang:hex-string
| +--rw digital-signature
| +--rw ds-algorithm? uint8
| +--rw (public-key)?
| | +--:(raw-public-key)
| | | +--rw raw-public-key? binary
| | +--:(cert-data)
| | +--rw cert-data? binary
| +--rw private-key? binary
| +--rw ca-data* binary
| +--rw crl-data? binary
| +--rw crl-uri? inet:uri
| +--rw oscp-uri? inet:uri
+--rw conn-entry* [name]
| +--rw name string
| +--rw autostartup? autostartup-type
| +--rw initial-contact? boolean
| +--rw version? auth-protocol-type
| +--rw fragmentation
| | +--rw enabled? boolean
| | +--rw mtu? uint16
| +--rw ike-sa-lifetime-soft
| | +--rw rekey-time? uint32
| | +--rw reauth-time? uint32
| +--rw ike-sa-lifetime-hard
| | +--rw over-time? uint32
| +--rw ike-sa-intr-alg* nsfikec:intr-alg-t
| +--rw ike-sa-encr-alg* [id]
| | +--rw id uint16
| | +--rw algorithm-type? nsfikec:encr-alg-t
| | +--rw key-length? uint16
| +--rw dh-group? fs-group
| +--rw half-open-ike-sa-timer? uint32
| +--rw half-open-ike-sa-cookie-threshold? uint32
| +--rw local
| | +--rw local-pad-entry-name string
| +--rw remote
| | +--rw remote-pad-entry-name string
| +--rw encapsulation-type
| | +--rw espencap? esp-encap
| | +--rw sport? inet:port-number
| | +--rw dport? inet:port-number
| | +--rw oaddr* inet:ip-address
| +--rw spd
| | +--rw spd-entry* [name]
| | +--rw name string
| | +--rw ipsec-policy-config
| | +--rw anti-replay-window-size? uint32
| | +--rw traffic-selector
| | | +--rw local-prefix inet:ip-prefix
| | | +--rw remote-prefix inet:ip-prefix
| | | +--rw inner-protocol? ipsec-inner-protocol
| | | +--rw local-ports* [start end]
| | | | +--rw start inet:port-number
| | | | +--rw end inet:port-number
| | | +--rw remote-ports* [start end]
| | | +--rw start inet:port-number
| | | +--rw end inet:port-number
| | +--rw processing-info
| | +--rw action? ipsec-spd-action
| | +--rw ipsec-sa-cfg
| | +--rw pfp-flag? boolean
| | +--rw ext-seq-num? boolean
| | +--rw seq-overflow? boolean
| | +--rw stateful-frag-check? boolean
| | +--rw mode? ipsec-mode
| | +--rw protocol-parameters? ipsec-protocol-params
| | +--rw esp-algorithms
| | | +--rw integrity* intr-alg-t
| | | +--rw encryption* [id]
| | | | +--rw id uint16
| | | | +--rw algorithm-type? encr-alg-t
| | | | +--rw key-length? uint16
| | | +--rw tfc-pad? boolean
| | +--rw tunnel
| | +--rw local inet:ip-address
| | +--rw remote inet:ip-address
| | +--rw df-bit? enumeration
| | +--rw bypass-dscp? boolean
| | +--rw dscp-mapping* [id]
| | +--rw id uint8
| | +--rw inner-dscp? inet:dscp
| | +--rw outer-dscp? inet:dscp
| +--rw child-sa-info
| | +--rw fs-groups* fs-group
| | +--rw child-sa-lifetime-soft
| | | +--rw time? uint32
| | | +--rw bytes? yang:counter64
| | | +--rw packets? uint32
| | | +--rw idle? uint32
| | | +--rw action? nsfikec:lifetime-action
| | +--rw child-sa-lifetime-hard
| | +--rw time? uint32
| | +--rw bytes? yang:counter64
| | +--rw packets? uint32
| | +--rw idle? uint32
| +--ro state
| +--ro initiator? boolean
| +--ro initiator-ikesa-spi? ike-spi
| +--ro responder-ikesa-spi? ike-spi
| +--ro nat-local? boolean
| +--ro nat-remote? boolean
| +--ro encapsulation-type
| | +--ro espencap? esp-encap
| | +--ro sport? inet:port-number
| | +--ro dport? inet:port-number
| | +--ro oaddr* inet:ip-address
| +--ro established? uint64
| +--ro current-rekey-time? uint64
| +--ro current-reauth-time? uint64
+--ro number-ike-sas
+--ro total? yang:gauge64
+--ro half-open? yang:gauge64
+--ro half-open-cookies? yang:gauge64The big ipsec-ike container is the star of the show 👑 first up is the pad container, which configures the Peer Authentication Database with auth info about local and remote peers (NSFs) ✨ it's a list of entries, and each entry says which identity, auth method, and credentials a particular peer (local or remote) is going to use 🫶 so every entry holds identity, auth info, and credentials for either the local NSF or the remote NSF. That means the I2NF Controller can store identity, auth info, and credentials for the local NSF and the remote NSF 😭 iconic.
Next, the conn-entry list tracks the different IKE connections a peer can keep up with others 💜 each one has a ton of parameters for a particular IKE connection between two peers: local and remote peer auth info, IKE SA config (soft and hard lifetimes, crypto algorithms, etc.), a list of IPsec policies describing the type of traffic to secure (local/remote subnet and ports, etc.) and how it must be protected (ESP, tunnel/transport, crypto algorithms, etc.), Child SA config (soft and hard lifetimes), and state info for the IKE connection (SPIs, NAT usage, current expiration times, etc.) 🤯 main character energy for sure.
Last but not least, the number-ike-sas container reports state info from the IKE software about how many IKE connections are established 📊🍓
5.2.2. Example Usage 🎀
Appendix A shows an example of IKE case configuration for an NSF in tunnel mode (gateway-to-gateway), with NSF authentication based on X.509 certificates 🔐 go peek at it bestie 👀
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-Auth-Method], [IKEv2-Transform-Type-4], [IKEv2-Parameters], and [IANA-Method-Type] 📚 yes it's a lot, no cap 💅
<CODE BEGINS> file "ietf-i2nsf-ike@2021-07-14.yang"
module ietf-i2nsf-ike {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-i2nsf-ike";
prefix nsfike;
import ietf-inet-types {
prefix inet;
reference
"RFC 6991: Common YANG Data Types.";
}
import ietf-yang-types {
prefix yang;
reference
"RFC 6991: Common YANG Data Types.";
}
import ietf-i2nsf-ikec {
prefix nsfikec;
reference
"RFC 9061: A YANG Data Model for IPsec Flow Protection
Based on Software-Defined Networking (SDN).";
}
import ietf-netconf-acm {
prefix nacm;
reference
"RFC 8341: Network Configuration Access Control
Model.";
}
organization
"IETF I2NSF Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/i2nsf/>
WG List: <mailto:i2nsf@ietf.org>
Author: Rafael Marin-Lopez
<mailto:rafa@um.es>
Author: Gabriel Lopez-Millan
<mailto:gabilm@um.es>
Author: Fernando Pereniguez-Garcia
<mailto:fernando.pereniguez@cud.upct.es>
";
description
"This module contains the IPsec IKE case model for the SDN-based
IPsec flow protection service.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this
document are to be interpreted as described in BCP 14
(RFC 2119) (RFC 8174) when, and only when, they appear
in all capitals, as shown here.
Copyright (c) 2021 IETF Trust and the persons identified as
authors of the code. All rights reserved.okay bestie, we're still inside the module, and the license text is wrapping up 🎀
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC 9061; see
the RFC itself for full legal notices.";
revision 2021-07-14 {
description
"Initial version.";
reference
"RFC 9061: A YANG Data Model for IPsec Flow Protection
Based on Software-Defined Networking (SDN).";
}
typedef ike-spi {
type uint64 {
range "0..max";
}
description
"Security Parameter Index (SPI)'s IKE SA.";
reference
"RFC 7296: Internet Key Exchange Protocol Version 2
(IKEv2), Section 2.6.";
}
typedef autostartup-type {
type enumeration {
enum add {
description
"IKE/IPsec configuration is only loaded into
IKE implementation, but IKE/IPsec SA is not
started.";
}
enum on-demand {
description
"IKE/IPsec configuration is loaded
into IKE implementation. The IPsec policies
are transferred to the NSF, but the
IPsec SAs are not established immediately.
The IKE implementation will negotiate the
IPsec SAs when they are required
(i.e., through an ACQUIRE notification).";
}
enum start {
description
"IKE/IPsec configuration is loaded
and transferred to the NSF's kernel, and the
IKEv2-based IPsec SAs are established
immediately without waiting for any packet.";
}
}
description
"Different policies to set IPsec SA configuration
into NSF's kernel when IKEv2 implementation has
started.";
}
typedef fs-group {
type uint16;
description
"DH groups for IKE and IPsec SA rekey.";
reference
"IANA: Internet Key Exchange Version 2 (IKEv2) Parameters,
IKEv2 Transform Attribute Types, Transform Type 4 -
Diffie-Hellman Group Transform IDs
RFC 7296: Internet Key Exchange Protocol Version 2
(IKEv2), Section 3.3.2.";
}
typedef auth-protocol-type {
type enumeration {
enum ikev2 {
value 2;
description
"IKEv2 authentication protocol. It is the
only one defined right now. An enum is
used for further extensibility.";
}
}
description
"IKE authentication protocol version specified in the
Peer Authorization Database (PAD). It is defined as
enumerated to allow new IKE versions in the
future.";
reference
"RFC 7296: Internet Key Exchange Protocol Version 2
(IKEv2).";
}
typedef auth-method-type {
type enumeration {
enum pre-shared {
description
"Select pre-shared key as the
authentication method.";
reference
"RFC 7296: Internet Key Exchange Protocol Version 2
(IKEv2).";
}
enum eap {
description
"Select the Extensible Authentication Protocol (EAP) as
the authentication method.";
reference
"RFC 7296: Internet Key Exchange Protocol Version 2
(IKEv2).";
}
enum digital-signature {
description
"Select digital signature as the authentication method.";
reference
"RFC 7296: Internet Key Exchange Protocol Version 2
(IKEv2)
RFC 7427: Signature Authentication in the Internet Key
Exchange Version 2 (IKEv2).";
}
enum null {
description
"Null authentication.";
reference
"RFC 7619: The NULL Authentication Method in the Internet
Key Exchange Protocol Version 2 (IKEv2).";
}
}
description
"Peer authentication method specified in the Peer
Authorization Database (PAD).";
}Quick vibe check on what just happened: the ike-spi, autostartup-type, fs-group, auth-protocol-type and auth-method-type typedefs are the building blocks the rest of the module leans on 🧚 Each one carries its own description and reference, so the citations to RFC 7296, RFC 7427 and RFC 7619 are right there in the code 💜
Okay bestie, we're picking up mid-container, so no new heading needed 🎀 This is the ipsec-ike container and its PAD (Peer Authorization Database) list, where the I2NSF Controller stores the auth info for both the local and remote NSF. It's giving organized, and it's lowkey iconic ✨
container ipsec-ike {
description
"IKE configuration for an NSF. It includes PAD
parameters, IKE connection information, and state
data.";
container pad {
description
"Configuration of the Peer Authorization Database
(PAD). Each entry of PAD contains authentication
information of either the local peer or the remote peer.
Therefore, the I2NSF Controller stores authentication
information (and credentials) not only for the remote NSF
but also for the local NSF. The local NSF MAY use the
same identity for different types of authentication
and credentials. Pointing to the entry for a local NSF
(e.g., A) and the entry for remote NSF (e.g., B)
is possible to specify all the required information to
carry out the authentication between A and B (see
../conn-entry/local and ../conn-entry/remote).";
list pad-entry {
key "name";
ordered-by user;
description
"Peer Authorization Database (PAD) entry. It
is a list of PAD entries ordered by the
I2NSF Controller, and each entry is
unequivocally identified by a name.";
leaf name {
type string;
description
"PAD-unique name to identify this
entry.";
}
choice identity {
mandatory true;
description
"A particular IKE peer will be
identified by one of these identities.
This peer can be a remote peer or local
peer (this NSF).";
reference
"RFC 4301: Security Architecture for the Internet
Protocol, Section 4.4.3.1.";
case ipv4-address {
leaf ipv4-address {
type inet:ipv4-address;
description
"Specifies the identity as
a single 4-octet IPv4 address.";
}
}
case ipv6-address {
leaf ipv6-address {
type inet:ipv6-address;
description
"Specifies the identity as a
single 16-octet IPv6
address. An example is
2001:db8::8:800:200c:417a.";
}
}
case fqdn-string {
leaf fqdn-string {
type inet:domain-name;
description
"Specifies the identity as a
Fully Qualified Domain Name
(FQDN) string. An example is
example.com. The string MUST
NOT contain any terminators
(e.g., NULL, Carriage Return
(CR), etc.).";
}
}
case rfc822-address-string {
leaf rfc822-address-string {
type string;
description
"Specifies the identity as a
fully qualified email address
string (RFC 5322). An example is
jsmith@example.com. The string
MUST NOT contain any
terminators (e.g., NULL, CR,
etc.).";
reference
"RFC 5322: Internet Message Format.";
}
}
case dnx509 {
leaf dnx509 {
type binary;
description
"The binary
Distinguished Encoding Rules (DER)
encoding of an ASN.1 X.500
Distinguished Name, as specified in IKEv2.";
reference
"RFC 5280: Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation
List (CRL) Profile
RFC 7296: Internet Key Exchange Protocol Version 2
(IKEv2), Section 3.5.";
}
}
case gnx509 {
leaf gnx509 {
type binary;
description
"ASN.1 X.509 GeneralName structure,
as specified in RFC 5280, encoded
using ASN.1 Distinguished Encoding Rules
(DER), as specified in ITU-T X.690.";
reference
"RFC 5280: Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation
List (CRL) Profile.";
}
}
case id-key {
leaf id-key {
type binary;
description
"Opaque octet stream that may be
used to pass vendor-specific
information for proprietary
types of identification.";
reference
"RFC 7296: Internet Key Exchange Protocol Version 2
(IKEv2), Section 3.5.";
}
}
case id-null {
leaf id-null {
type empty;
description
"The ID_NULL identification is used
when the IKE identification payload
is not used.";
reference
"RFC 7619: The NULL Authentication Method in the
Internet Key Exchange Protocol Version 2
(IKEv2).";
}
}
}
leaf auth-protocol {
type auth-protocol-type;
default "ikev2";
description
"Only IKEv2 is supported right now, but
other authentication protocols may be
supported in the future.";
}
container peer-authentication {
description
"This container allows the security
controller to configure the
authentication method (pre-shared key,
eap, digital-signature, null) that
will be used with a particular peer and
the credentials to use, which will
depend on the selected authentication
method.";
leaf auth-method {
type auth-method-type;
default "pre-shared";
description
"Type of authentication method
(pre-shared key, eap, digital signature,
null).";
reference
"RFC 7296: Internet Key Exchange Protocol Version 2
(IKEv2), Section 2.15.";
}
container eap-method {
when "../auth-method = 'eap'";
leaf eap-type {
type uint32 {
range "1 .. 4294967295";
}
mandatory true;
description
"EAP method type specified with
a value extracted from the
IANA registry. This
information provides the
particular EAP method to be
used. Depending on the EAP
method, pre-shared keys or
certificates may be used.";
}
description
"EAP method description used when
authentication method is 'eap'.";
reference
"IANA: Extensible Authentication Protocol (EAP)
Registry, Method Types
RFC 7296: Internet Key Exchange Protocol Version 2
(IKEv2), Section 2.16.";
}
container pre-shared {
when "../auth-method[.='pre-shared' or
.='eap']";
leaf secret {
nacm:default-deny-all;
type yang:hex-string;
description
"Pre-shared secret value. The
NSF has to prevent read access
to this value for security
reasons. This value MUST be
set if the EAP method uses a
pre-shared key or pre-shared
authentication has been chosen.";
}
description
"Shared secret value for PSK or
EAP method authentication based on
PSK.";
}
container digital-signature {
when "../auth-method[.='digital-signature'
or .='eap']";
leaf ds-algorithm {
type uint8;
default "14";
description
"The digital signature
algorithm is specified with a
value extracted from the IANA
registry. Default is the generic
digital signature method. Depending
on the algorithm, the following leafs
MUST contain information. For
example, if digital signature or the
EAP method involves a certificate,
then leaves 'cert-data' and 'private-key'
will contain this information.";
reference
"IANA: Internet Key Exchange Version 2 (IKEv2)
Parameters, IKEv2 Authentication Method.";
}
choice public-key {
leaf raw-public-key {
type binary;
description
"A binary that contains the
value of the public key. The
interpretation of the content
is defined by the digital
signature algorithm. For
example, an RSA key is
represented as RSAPublicKey, as
defined in RFC 8017, and an
Elliptic Curve Cryptography
(ECC) key is represented
using the 'publicKey'
described in RFC 5915.";
reference
"RFC 5915: Elliptic Curve Private Key
Structure
RFC 8017: PKCS #1: RSA Cryptography
Specifications Version 2.2.";
}
leaf cert-data {
type binary;
description
"X.509 certificate data in DER
format. If raw-public-key is
defined, this leaf is empty.";
reference
"RFC 5280: Internet X.509 Public Key
Infrastructure Certificate
and Certificate Revocation
List (CRL) Profile.";
}
description
"If the I2NSF Controller
knows that the NSF
already owns a private key
associated to this public key
(e.g., the NSF generated the pair
public key/private key out of
band), it will only configure
one of the leaves of this
choice but not the leaf
private-key. The NSF, based onokay so we're still in the private key era 🔐, and nacm:default-deny-all means nobody gets a peek unless they're explicitly allowed 💅
the public key value, can know
the private key to be used.";
}
leaf private-key {
nacm:default-deny-all;
type binary;
description
"A binary that contains the
value of the private key. The
interpretation of the content
is defined by the digital
signature algorithm. For
example, an RSA key is
represented as RSAPrivateKey, as
defined in RFC 8017, and an
Elliptic Curve Cryptography
(ECC) key is represented as
ECPrivateKey, as defined in RFC
5915. This value is set
if public key is defined and the
I2NSF Controller is in charge
of configuring the
private key. Otherwise, it is
not set and the value is
kept in secret.";
reference
"RFC 5915: Elliptic Curve Private Key
Structure
RFC 8017: PKCS #1: RSA Cryptography
Specifications Version 2.2.";
}
leaf-list ca-data {
type binary;
description
"List of trusted Certification
Authorities (CAs) certificates
encoded using ASN.1
Distinguished Encoding Rules
(DER). If it is not defined,
the default value is empty.";
}
leaf crl-data {
type binary;
description
"A CertificateList structure, as
specified in RFC 5280,
encoded using ASN.1
Distinguished Encoding Rules
(DER), as specified in ITU-T
X.690. If it is not defined,
the default value is empty.";
reference
"RFC 5280: Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation
List (CRL) Profile.";
}
leaf crl-uri {
type inet:uri;
description
"X.509 Certificate Revocation List
(CRL) certificate URI.
If it is not defined,
the default value is empty.";
reference
"RFC 5280: Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation
List (CRL) Profile.";
}
leaf oscp-uri {
type inet:uri;
description
"Online Certificate Status Protocol
(OCSP) URI. If it is not defined,
the default value is empty.";
reference
"RFC 6960: X.509 Internet Public Key Infrastructure
Online Certificate Status Protocol - OCSP
RFC 5280: Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation
List (CRL) Profile.";
}
description
"digital-signature container.";
} /*container digital-signature*/
} /*container peer-authentication*/
}
}
list conn-entry {
key "name";
description
"IKE peer connection information. This list
contains the IKE connection for this peer
with other peers. This will create, in
real time, IKE Security Associations
established with these nodes.";
leaf name {
type string;
description
"Identifier for this connection
entry.";
}
leaf autostartup {
type autostartup-type;
default "add";
description
"By default, only add configuration
without starting the security
association.";
}
leaf initial-contact {
type boolean;
default "false";
description
"The goal of this value is to deactivate the
usage of INITIAL_CONTACT notification
(true). If this flag remains set to false, it
means the usage of the INITIAL_CONTACT
notification will depend on the IKEv2
implementation.";
}
leaf version {
type auth-protocol-type;
default "ikev2";
description
"IKE version. Only version 2 is supported.";
}
container fragmentation {
leaf enabled {
type boolean;
default "false";
description
"Whether or not to enable IKEv2
fragmentation (true or false).";
reference
"RFC 7383: Internet Key Exchange Protocol Version 2
(IKEv2) Message Fragmentation.";
}
leaf mtu {
when "../enabled='true'";
type uint16 {
range "68..65535";
}
description
"MTU that IKEv2 can use
for IKEv2 fragmentation.";
reference
"RFC 7383: Internet Key Exchange Protocol Version 2
(IKEv2) Message Fragmentation.";
}
description
"IKEv2 fragmentation, as per RFC 7383. If the
IKEv2 fragmentation is enabled, it is possible
to specify the MTU.";
}
container ike-sa-lifetime-soft {
description
"IKE SA lifetime soft. Two lifetime values
can be configured: either rekey time of the
IKE SA or reauth time of the IKE SA. When
the rekey lifetime expires, a rekey of the
IKE SA starts. When reauth lifetime
expires, an IKE SA reauthentication starts.";
leaf rekey-time {
type uint32;
units "seconds";
default "0";
description
"Time in seconds between each IKE SA
rekey. The value 0 means infinite.";
}
leaf reauth-time {
type uint32;
units "seconds";
default "0";
description
"Time in seconds between each IKE SA
reauthentication. The value 0 means
infinite.";
}
reference
"RFC 7296: Internet Key Exchange Protocol Version 2
(IKEv2), Section 2.8.";
}
container ike-sa-lifetime-hard {
description
"Hard IKE SA lifetime. When this
time is reached, the IKE SA is removed.";
leaf over-time {
type uint32;
units "seconds";
default "0";
description
"Time in seconds before the IKE SA is
removed. The value 0 means infinite.";
}
reference
"RFC 7296: Internet Key Exchange Protocol Version 2
(IKEv2).";
}
leaf-list ike-sa-intr-alg {
type nsfikec:intr-alg-t;
default "12";
ordered-by user;
description
"Integrity algorithm for establishing
the IKE SA. This list is ordered following
from the higher priority to lower priority.
The first node of the list will be the
algorithm with higher priority.
Default value 12 (AUTH_HMAC_SHA2_256_128).";
}
list ike-sa-encr-alg {
key "id";
min-elements 1;
ordered-by user;
leaf id {
type uint16;
description
"An identifier that unequivocally
identifies each entry of the list,
i.e., an encryption algorithm and
its key length (if required).";
}
leaf algorithm-type {
type nsfikec:encr-alg-t;
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
"Encryption or AEAD algorithm for the IKE
SAs. This list is ordered following
from the higher priority to lower priority.
The first node of the list will be the
algorithm with higher priority.";
}
leaf dh-group {
type fs-group;
default "14";
description
"Group number for Diffie-Hellman
Exponentiation used during IKE_SA_INIT
for the IKE SA key exchange.";
}
leaf half-open-ike-sa-timer {
type uint32;
units "seconds";
default "0";
description
"Set the half-open IKE SA timeout
duration. The value 0 implies infinite.";
reference
"RFC 7296: Internet Key Exchange Protocol Version 2
(IKEv2), Section 2.";
}
leaf half-open-ike-sa-cookie-threshold {
type uint32;
default "0";
description
"Number of half-open IKE SAs that activate
the cookie mechanism. The value 0 implies
infinite.";
reference
"RFC 7296: Internet Key Exchange Protocol Version 2
(IKEv2), Section 2.6.";
}
container local {
leaf local-pad-entry-name {
type string;
mandatory true;
description
"Local peer authentication information.
This node points to a specific entry in
the PAD where the authorization
information about this particular local
peer is stored. It MUST match a
pad-entry-name.";
}
description
"Local peer authentication information.";
}
container remote {
leaf remote-pad-entry-name {
type string;
mandatory true;
description
"Remote peer authentication information.
This node points to a specific entry in
the PAD where the authorization
information about this particular
remote peer is stored. It MUST match a
pad-entry-name.";
}
description
"Remote peer authentication information.";
}
container encapsulation-type {
uses nsfikec:encap;
description
"This container carries configuration
information about the source and destination
ports of encapsulation that IKE should use
and the type of encapsulation that
should be used when NAT traversal is required.
However, this is just a best effort since
the IKE implementation may need to use a
different encapsulation, as described in
RFC 8229.";
referencethe code above stops right at thereferenceline underencapsulation-type, so that's where we pick things up next 🫶
"RFC 8229: TCP Encapsulation of IKE and IPsec Packets."; } container spd { description "Configuration of the Security Policy Database (SPD). This main information is placed in the grouping ipsec-policy-grouping."; list spd-entry { key "name"; ordered-by user; leaf name { type string; description "SPD-entry-unique name to identify the IPsec policy."; } container ipsec-policy-config { description "This container carries the configuration of an IPsec policy."; uses nsfikec:ipsec-policy-grouping; } description "List of entries that will constitute the representation of the SPD. In this case, since the NSF implements IKE, it is only required to send an IPsec policy from this NSF where 'local' is this NSF and 'remote' the other NSF. The IKE implementation will install IPsec policies in the NSF's kernel in both directions (inbound and outbound) and their corresponding IPsec SAs based on the information in this SPD entry."; } reference "RFC 7296: Internet Key Exchange Protocol Version 2 (IKEv2), Section 2.9."; } container child-sa-info { leaf-list fs-groups { type fs-group; default "0"; ordered-by user; description "If non-zero, forward secrecy is required when a new IPsec SA is being created, the (non-zero) value indicates the group number to use for the key exchange process used to achieve forward secrecy. This list is ordered following from the higher priority to lower priority. The first node of the list will be the algorithm with higher priority."; } container child-sa-lifetime-soft { description "Soft IPsec SA lifetime. After the lifetime, the action is defined in this container in the leaf action."; uses nsfikec:lifetime; leaf action { type nsfikec:lifetime-action; default "replace"; description "When the lifetime of an IPsec SA expires, an action needs to be performed over the IPsec SA that reached the lifetime. There are three possible options: terminate-clear, terminate-hold, and replace."; reference "RFC 4301: Security Architecture for the Internet Protocol, Section 4.5 RFC 7296: Internet Key Exchange Protocol Version 2 (IKEv2), Section 2.8."; } } container child-sa-lifetime-hard { description "IPsec SA lifetime hard. The action will be to terminate the IPsec SA."; uses nsfikec:lifetime; reference "RFC 7296: Internet Key Exchange Protocol Version 2 (IKEv2), Section 2.8."; } description "Specific information for IPsec SAs. It includes the Perfect Forward Secrecy (PFS) group and IPsec SAs rekey lifetimes."; } container state { config false; leaf initiator { type boolean; description "It is acting as an initiator for this connection."; } leaf initiator-ikesa-spi { type ike-spi; description "Initiator's IKE SA SPI."; } leaf responder-ikesa-spi { type ike-spi; description "Responder's IKE SA SPI."; } leaf nat-local { type boolean; description "True if local endpoint is behind a NAT."; } leaf nat-remote { type boolean; description "True if remote endpoint is behind a NAT."; } container encapsulation-type { uses nsfikec:encap; description "This container provides information about the source and destination ports of encapsulation that IKE is using and the type of encapsulation when NAT traversal is required."; reference "RFC 8229: TCP Encapsulation of IKE and IPsec Packets."; } leaf established { type uint64; units "seconds"; description "Seconds since this IKE SA has been established."; } leaf current-rekey-time { type uint64; units "seconds"; description "Seconds before IKE SA is rekeyed."; } leaf current-reauth-time { type uint64; units "seconds"; description "Seconds before IKE SA is reauthenticated."; } description "IKE state data for a particular connection."; } /* ike-sa-state / } / ike-conn-entries / container number-ike-sas { config false; leaf total { type yang:gauge64; description "Total number of active IKE SAs."; } leaf half-open { type yang:gauge64; description "Number of half-open active IKE SAs."; } leaf half-open-cookies { type yang:gauge64; description "Number of half-open active IKE SAs with cookie activated."; } description "General information about the IKE SAs. In particular, it provides the current number of IKE SAs."; } } / container ipsec-ike */ } <CODE ENDS>
## 5.3. The 'ietf-i2nsf-ikeless' Module ✨
Okay bestie, now we're moving on to the IKE-less case 🧚 This section is where the YANG module for that case gets described, so get ready for the next part of the module 💅🌸
### 5.3.1. Data Model Overview
okay so for the IKE-less case, the SPD model is mostly borrowed from Section 4.4.1 and Appendix D in [RFC4301] 💅, but it got a few glow-ups along the way:
- 🎀 **One Traffic Selector per policy:** each IPsec policy (spd-entry) holds *one* Traffic Selector instead of a list. Real kernel implementations only admit a single Traffic Selector per IPsec policy, so this just matches reality 🧚
- 🔗 **A reqid:** each IPsec policy gets an identifier (reqid) that links it to the IPsec SA. This is super common in Linux-based systems 🐧
- 🌸 **One name only:** each IPsec policy has one name, not a list of names.
- 🙅♀️ **Combined algorithms are gone:** the combined algorithms were removed because encryption algorithms MAY include Authenticated Encryption with Associated Data (AEAD) 🔐
- 🦋 **DSCP mapping in tunnels:** tunnel information was extended with DSCP mapping info, because certain kernel implementations accept configuration of these values 🌈
The SAD model is also mostly lifted from Section 4.4.2 of [RFC4301], with its own set of upgrades, namely:
- 💖 **One Traffic Selector per SA:** each IPsec SA (sad-entry) contains *one* Traffic Selector instead of a list. Kernel implementations only admit a single Traffic Selector per IPsec SA, so yep, same energy as the SPD 👑
- 🔗 **A reqid here too:** each IPsec SA contains an identifier (reqid) that relates it to the IPsec policy. Real kernel implementations allow this value to be included, so it's in there ✨
- 🏷️ **Same naming vibes:** each IPsec SA is named in the same way as IPsec policies.
- 🔐 **Encryption choice:** the model lets you specify the encryption algorithm, and that can be Authenticated Encryption with Associated Data (AEAD) or non-AEAD. If an AEAD algorithm is specified, the integrity algorithm is not required. If a non-AEAD algorithm is specified, the integrity algorithm is required [RFC8221] 🫶
- 🌷 **DSCP in tunnels:** tunnel information was extended with Differentiated Services Code Point (DSCP) mapping. It is assumed that NSFs involved in this document provide ECN full functionality to prevent discarding of ECN congestion indications [RFC6040] 🍓
- ⏳ **More lifetime options:** the lifetime of the IPsec SAs also includes idle time, plus the number of IP packets as a threshold to trigger the lifetime. Actual kernel implementations allow for setting these types of lifetimes 💜
- 📦 **Encapsulation type:** info to configure the type of encapsulation (encapsulation-type) for IPsec ESP packets in UDP [RFC3948] or TCP [RFC8229] has been included 🚀
The notifications model was 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-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 spd
| +--rw spd-entry* [name] | ||
|---|---|---|
| +--rw name string | ||
| +--rw direction nsfikec:ipsec-traffic-direction | ||
| +--rw reqid? uint64 | ||
| +--rw ipsec-policy-config | ||
| +--rw anti-replay-window-size? uint32 | ||
| +--rw traffic-selector | ||
| +--rw local-prefix inet:ip-prefix | ||
| +--rw remote-prefix inet:ip-prefix | ||
| +--rw inner-protocol? ipsec-inner-protocol | ||
| +--rw local-ports* [start end] | ||
| +--rw start inet:port-number | ||
| +--rw end inet:port-number | ||
| +--rw remote-ports* [start end] | ||
| +--rw start inet:port-number | ||
| +--rw end inet:port-number | ||
| +--rw processing-info | ||
| +--rw action? ipsec-spd-action | ||
| +--rw ipsec-sa-cfg | ||
| +--rw pfp-flag? boolean | ||
| +--rw ext-seq-num? boolean | ||
| +--rw seq-overflow? boolean | ||
| +--rw stateful-frag-check? boolean | ||
| +--rw mode? ipsec-mode | ||
| +--rw protocol-parameters? ipsec-protocol-params | ||
| +--rw esp-algorithms | ||
| +--rw integrity* intr-alg-t | ||
| +--rw encryption* [id] | ||
| +--rw id uint16 | ||
| +--rw algorithm-type? encr-alg-t | ||
| +--rw key-length? uint16 | ||
| +--rw tfc-pad? boolean | ||
| +--rw tunnel | ||
| +--rw local inet:ip-address | ||
| +--rw remote inet:ip-address | ||
| +--rw df-bit? enumeration | ||
| +--rw bypass-dscp? boolean | ||
| +--rw dscp-mapping* [id] | ||
| +--rw id uint8 | ||
| +--rw inner-dscp? inet:dscp | ||
| +--rw outer-dscp? inet:dscp |
+--rw sad +--rw sad-entry* [name] +--rw name string +--rw reqid? uint64 +--rw ipsec-sa-config
| +--rw spi uint32 | ||
|---|---|---|
| +--rw ext-seq-num? boolean | ||
| +--rw seq-overflow? boolean | ||
| +--rw anti-replay-window-size? uint32 | ||
| +--rw traffic-selector | ||
| +--rw local-prefix inet:ip-prefix | ||
| +--rw remote-prefix inet:ip-prefix | ||
| +--rw inner-protocol? ipsec-inner-protocol | ||
| +--rw local-ports* [start end] | ||
| +--rw start inet:port-number | ||
| +--rw end inet:port-number | ||
| +--rw remote-ports* [start end] | ||
| +--rw start inet:port-number | ||
| +--rw end inet:port-number | ||
| +--rw protocol-parameters? nsfikec:ipsec-protocol-params | ||
| +--rw mode? nsfikec:ipsec-mode | ||
| +--rw esp-sa | ||
| +--rw encryption | ||
| +--rw encryption-algorithm? nsfikec:encr-alg-t | ||
| +--rw key? yang:hex-string | ||
| +--rw iv? yang:hex-string | ||
| +--rw integrity | ||
| +--rw integrity-algorithm? nsfikec:intr-alg-t | ||
| +--rw key? yang:hex-string | ||
| +--rw sa-lifetime-hard | ||
| +--rw time? uint32 | ||
| +--rw bytes? yang:counter64 | ||
| +--rw packets? uint32 | ||
| +--rw idle? uint32 | ||
| +--rw sa-lifetime-soft | ||
| +--rw time? uint32 | ||
| +--rw bytes? yang:counter64 | ||
| +--rw packets? uint32 | ||
| +--rw idle? uint32 | ||
| +--rw action? nsfikec:lifetime-action | ||
| +--rw tunnel | ||
| +--rw local inet:ip-address | ||
| +--rw remote inet:ip-address | ||
| +--rw df-bit? enumeration | ||
| +--rw bypass-dscp? boolean | ||
| +--rw dscp-mapping* [id] | ||
| +--rw id uint8 | ||
| +--rw inner-dscp? inet:dscp | ||
| +--rw outer-dscp? inet:dscp | ||
| +--rw dscp-values* inet:dscp | ||
| +--rw encapsulation-type | ||
| +--rw espencap? esp-encap | ||
| +--rw sport? inet:port-number | ||
| +--rw dport? inet:port-number | ||
| +--rw oaddr* inet:ip-address |
+--ro ipsec-sa-state +--ro sa-lifetime-current
| +--ro time? uint32 |
|---|
| +--ro bytes? yang:counter64 |
| +--ro packets? uint32 |
| +--ro idle? uint32 |
+--ro replay-stats +--ro replay-window
| +--ro w? uint32 |
|---|
| +--ro t? uint64 |
| +--ro b? uint64 |
+--ro packet-dropped? yang:counter64 +--ro failed? yang:counter64 +--ro seq-number-counter? uint64
notifications: +---n sadb-acquire {ikeless-notification}?
| +--ro ipsec-policy-name string | |
|---|---|
| +--ro traffic-selector | |
| +--ro local-prefix inet:ip-prefix | |
| +--ro remote-prefix inet:ip-prefix | |
| +--ro inner-protocol? ipsec-inner-protocol | |
| +--ro local-ports* [start end] | |
| +--ro start inet:port-number | |
| +--ro end inet:port-number | |
| +--ro remote-ports* [start end] | |
| +--ro start inet:port-number | |
| +--ro end inet:port-number |
+---n sadb-expire {ikeless-notification}?
| +--ro ipsec-sa-name string |
|---|
| +--ro soft-lifetime-expire? boolean |
| +--ro lifetime-current |
| +--ro time? uint32 |
| +--ro bytes? yang:counter64 |
| +--ro packets? uint32 |
| +--ro idle? uint32 |
+---n sadb-seq-overflow {ikeless-notification}?
| +--ro ipsec-sa-name string |
+---n sadb-bad-spi {ikeless-notification}? +--ro spi uint32
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 is 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: the 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/transport mode, cryptographic algorithms and keying material, soft/hard lifetimes, etc.) as well as stating information (time to expire, replay statistics, etc.) of a concrete IPsec SA 📊
In addition, the module defines a set of notifications so the NSF can tell 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 🎬
### 5.3.3. YANG Module
This YANG module has normative references to [RFC4301], [RFC4303], [RFC6991], [RFC8174] and [RFC8341]. 📚✨
<CODE BEGINS> file "ietf-i2nsf-ikeless@2021-07-14.yang" module ietf-i2nsf-ikeless { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless"; prefix nsfikels;
import ietf-inet-types { prefix inet; reference "RFC 6991: Common YANG Data Types."; } import ietf-yang-types { prefix yang; reference "RFC 6991: Common YANG Data Types."; } import ietf-i2nsf-ikec { prefix nsfikec; reference "RFC 9061: A YANG Data Model for IPsec Flow Protection Based on Software-Defined Networking (SDN)."; } import ietf-netconf-acm { prefix nacm; reference "RFC 8341: Network Configuration Access Control Model."; }
Okay bestie, the module's header info is wrapping up, and then we get our first feature, `ikeless-notification` 💖✨
organization "IETF I2NSF Working Group"; contact "WG Web: <https://datatracker.ietf.org/wg/i2nsf/> WG List: <mailto:i2nsf@ietf.org>
Author: Rafael Marin-Lopez <mailto:rafa@um.es>
Author: Gabriel Lopez-Millan <mailto:gabilm@um.es>
Author: Fernando Pereniguez-Garcia <mailto:fernando.pereniguez@cud.upct.es> "; description "Data model for IKE-less case in the SDN-based IPsec flow protection service.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here.
Copyright (c) 2021 IETF Trust and the persons identified as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC 9061; see the RFC itself for full legal notices.";
revision 2021-07-14 { description "Initial version."; reference "RFC 9061: A YANG Data Model for IPsec Flow Protection Based on Software-Defined Networking (SDN)."; }
feature ikeless-notification { description "This feature indicates that the server supports generating notifications in the ikeless module.
To ensure broader applicability of this module, the notifications are marked as a feature. For the implementation of the IKE-less case, the NSF is expected to implement this feature."; }
container ipsec-ikeless {
description
"Container for configuration of the IKE-less
case. The container contains two additional
containers: 'spd' and 'sad'. The first allows the
I2NSF Controller to configure IPsec policies in
the Security Policy Database (SPD), and the second
allows the I2NSF Controller to configure IPsec
Security Associations (IPsec SAs) in the Security
Association Database (SAD).";
reference
"RFC 4301: Security Architecture for the Internet Protocol.";
container spd {
description
"Configuration of the Security Policy Database
(SPD).";
reference
"RFC 4301: Security Architecture for the Internet Protocol,
Section 4.4.1.2.";
list spd-entry {
key "name";
ordered-by user;
leaf name {
type string;
description
"SPD-entry-unique name to identify this
entry.";
}
leaf direction {
type nsfikec:ipsec-traffic-direction;
mandatory true;
description
"Inbound traffic or outbound
traffic. In the IKE-less case, the
I2NSF Controller needs to
specify the policy direction to be
applied in the NSF. In the IKE case,
this direction does not need to be
specified, since IKE
will determine the direction that the
IPsec policy will require.";
}
leaf reqid {
type uint64;
default "0";
description
"This value allows linking this
IPsec policy with IPsec SAs with the
same reqid. It is only required in
the IKE-less model since, in the IKE
case, this link is handled internally
by IKE.";
}
container ipsec-policy-config {
description
"This container carries the
configuration of an IPsec policy.";
uses nsfikec:ipsec-policy-grouping;
}
description
"The SPD is represented as a list of SPD
entries, where each SPD entry represents an
IPsec policy.";
} /*list spd-entry*/
} /*container spd*/
container sad {
description
"Configuration of the IPsec Security Association
Database (SAD).";
reference
"RFC 4301: Security Architecture for the Internet Protocol,
Section 4.4.2.1.";
list sad-entry {
key "name";
ordered-by user;
leaf name {
type string;
description
"SAD-entry-unique name to identify this
entry.";
}
leaf reqid {
type uint64;
default "0";
description
"This value allows linking this
IPsec SA with an IPsec policy with
the same reqid.";
}
container ipsec-sa-config {
description
"This container allows configuring
details of an IPsec SA.";
leaf spi {
type uint32 {
range "0..max";
}
mandatory true;
description
"IPsec SA of Security Parameter Index (SPI).";
}
leaf ext-seq-num {
type boolean;
default "true";
description
"True if this IPsec SA is using extended
sequence numbers. If true, the 64-bit
extended sequence number counter is used;
if false, the normal 32-bit sequence
number counter is used.";
}
leaf seq-overflow {
type boolean;
default "false";
description
"The flag indicating whether
overflow of the sequence number
counter should prevent transmission
of additional packets on the IPsec
SA (false) and, therefore, needs to
be rekeyed or whether rollover is
permitted (true). If Authenticated
Encryption with Associated Data
(AEAD) is used (leaf
esp-algorithms/encryption/algorithm-type),
this flag MUST BE false. Setting this
flag to true is strongly discouraged.";
}
leaf anti-replay-window-size {
type uint32;
default "64";
description
"To set the anti-replay window size.
The default value is set to 64,
following the recommendation in RFC 4303.";
reference
"RFC 4303: IP Encapsulating Security Payload (ESP),
Section 3.4.3.";
}
container traffic-selector {
uses nsfikec:selector-grouping;
description
"The IPsec SA Traffic Selector.";
}
leaf protocol-parameters {
type nsfikec:ipsec-protocol-params;
default "esp";
description
"Security protocol of IPsec SA, only
ESP so far.";
}
leaf mode {
type nsfikec:ipsec-mode;
default "transport";
description
"Tunnel or transport mode.";
}
container esp-sa {
when "../protocol-parameters = 'esp'";
description
"In case the IPsec SA is an
Encapsulation Security Payload
(ESP), it is required to specify
encryption and integrity
algorithms and key materials.";
container encryption {
description
"Configuration of encryption or
AEAD algorithm for IPsec
Encapsulation Security Payload
(ESP).";
leaf encryption-algorithm {
type nsfikec:encr-alg-t;
default "12";
description
"Configuration of ESP
encryption. With AEAD
algorithms, the integrity-algorithm
leaf is not used.";
}
leaf key {
nacm:default-deny-all;
type yang:hex-string;
description
"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, it is
128 bits.";
}
leaf iv {
nacm:default-deny-all;
type yang:hex-string;
description
"ESP encryption IV value. If
this leaf is not defined, the
IV is not defined (e.g.,
encryption is NULL).";
}
}
container integrity {
description
"Configuration of integrity for
IPsec Encapsulation Security
Payload (ESP). This container
allows configuration of integrity
algorithms when no AEAD
algorithms are used and
integrity is required.";
leaf integrity-algorithm {
type nsfikec:intr-alg-t;
default "12";
description
"Message Authentication Code
(MAC) algorithm to provide
integrity in ESP (default
AUTH_HMAC_SHA2_256_128).
With AEAD algorithms,
the integrity leaf is not
used.";
}
leaf key {
nacm:default-deny-all;
type yang:hex-string;
description
"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 sa-lifetime-hard {
description
"IPsec SA hard lifetime. The action
associated is terminate and hold.";
uses nsfikec:lifetime;
}
container sa-lifetime-soft {
description
"IPsec SA soft lifetime.";
uses nsfikec:lifetime;
leaf action {
type nsfikec:lifetime-action;
description
"Action lifetime: terminate-clear,
terminate-hold, or replace.";
}
}
container tunnel {
when "../mode = 'tunnel'";
uses nsfikec:tunnel-grouping;
leaf-list dscp-values {
type inet:dscp;
description
"DSCP values allowed for ingress packets carried
over this IPsec SA. If no values are specified, no
DSCP-specific filtering is applied. When
../bypass-dscp is false and a dscp-mapping is
defined, each value here would be the same as the
'inner' DSCP value for the DSCP mapping (list
dscp-mapping).";
reference
"RFC 4301: Security Architecture for the Internet
Protocol, Section 4.4.2.1.";
}
description
"Endpoints of the IPsec tunnel.";
}
container encapsulation-type {
uses nsfikec:encap;
description
"This container carries
configuration information about
the source and destination ports
that will be used for ESP
encapsulation of ESP packets and
the type of encapsulation when NAT
traversal is in place.";
}
} /*ipsec-sa-config*/
container ipsec-sa-state {
config false;
description
"Container describing IPsec SA state
data.";
container sa-lifetime-current {
uses nsfikec:lifetime;
description
"SAD lifetime current.";
}
container replay-stats {
description
"State data about the anti-replay
window.";
container replay-window {
leaf w {
type uint32;
description
"Size of the replay window.";
}
leaf t { type uint64; description "Highest sequence number authenticated so far, upper bound of window."; } leaf b { type uint64; description "Lower bound of window."; } description "This container contains three parameters that define the state of the replay window: window size (w), highest sequence number authenticated (t), and lower bound of the window (b), according to Appendix A2.1 in RFC 4303 (w = t - b + 1)."; reference "RFC 4303: IP Encapsulating Security Payload (ESP), Appendix A."; } leaf packet-dropped { type yang:counter64; description "Packets dropped because they are replay packets."; } leaf failed { type yang:counter64; description "Number of packets detected out of the replay window."; } leaf seq-number-counter { type uint64; description "A 64-bit counter when this IPsec SA is using Extended Sequence Number or 32-bit counter when it is not. Current value of sequence number."; } } /* container replay-stats*/ } /ipsec-sa-state/ description "List of SAD entries that form the SAD."; } /list sad-entry/ } /container sad/ } /container ipsec-ikeless/
/* Notifications */
notification sadb-acquire { if-feature "ikeless-notification"; description "The NSF detects and notifies that an IPsec SA is required for an outbound IP packet that has matched an SPD entry. The traffic-selector container in this notification contains information about the IP packet that triggered this notification."; leaf ipsec-policy-name { type string; mandatory true; description "It contains the SPD entry name (unique) of the IPsec policy that hits the IP-packet-required IPsec SA. It is assumed the I2NSF Controller will have a copy of the information of this policy so it can extract all the information with this unique identifier. The type of IPsec SA is defined in the policy so the security controller can also know the type of IPsec SA that MUST be generated."; } container traffic-selector { description "The IP packet that triggered the acquire and requires an IPsec SA. Specifically, it will contain the IP source/mask and IP destination/mask, protocol (udp, tcp, etc.), and source and destination ports."; uses nsfikec:selector-grouping; } }
notification sadb-expire { if-feature "ikeless-notification"; description "An IPsec SA expiration (soft or hard)."; leaf ipsec-sa-name { type string; mandatory true; description "It contains the SAD entry name (unique) of the IPsec SA that is about to expire. It is assumed the I2NSF Controller will have a copy of the IPsec SA information (except the cryptographic material and state data) indexed by this name (unique identifier) so it can know all the information (crypto algorithms, etc.) about the IPsec SA that has expired in order to perform a rekey (soft lifetime) or delete it (hard lifetime) with this unique identifier."; } leaf soft-lifetime-expire { type boolean; default "true"; description "If this value is true, the lifetime expired is soft. If it is false, the lifetime is hard."; } container lifetime-current { description "IPsec SA current lifetime. If soft-lifetime-expired is true, this container is set with the lifetime information about current soft lifetime. It can help the NSF Controller to know which of the (soft) lifetime limits raised the event: time, bytes, packets, or idle."; uses nsfikec:lifetime; } }
notification sadb-seq-overflow { if-feature "ikeless-notification"; description "Sequence overflow notification."; leaf ipsec-sa-name { type string; mandatory true; description "It contains the SAD entry name (unique) of the IPsec SA that is about to have a sequence number overflow, and rollover is not permitted. When the NSF issues this event before reaching a sequence number, overflow is implementation specific and out of scope of this specification. It is assumed the I2NSF Controller will have a copy of the IPsec SA information (except the cryptographic material and state data) indexed by this name (unique identifier) so it can know all the information (crypto algorithms, etc.) about the IPsec SA in order to perform a rekey of the IPsec SA."; } }
notification sadb-bad-spi { if-feature "ikeless-notification"; description "Notify when the NSF receives a packet with an incorrect SPI (i.e., not present in the SAD)."; leaf spi { type uint32 { range "0..max"; } mandatory true; description "SPI number contained in the erroneous IPsec packet."; } } } <CODE ENDS>
# 6. IANA Considerations ✨
okay so IANA went and registered these namespaces in the "ns" subregistry inside 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 also registered the three 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
Name: ietf-i2nsf-ike Maintained by IANA: N Namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-ike Prefix: nsfike Reference: RFC 9061
Name: ietf-i2nsf-ikeless Maintained by IANA: N Namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless Prefix: nsfikels Reference: RFC 9061
# 7. Security Considerations 🔐
ngl this section is serious, so let's get into it 😭 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]. It's a whole package deal 💅
On 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). Not our problem here, but it's super important 🫶
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 preconfiguration step is not carried out by the I2NSF Controller but by some other entity before the NSF deployment. In this manner, when the NSF starts/reboots, it will always first apply the configuration in the startup configuration before contacting the I2NSF Controller. No cleartext leaks, periodt 🌸
Finally, this section is divided in two parts so we can look at the 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. Main character energy for the controller, and not in a good way 💀
## 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. Write-only vibes, iconic 🖤
> 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. 🙈
Here are the recommendations, bestie 🫶
- IKEv2 configurations SHOULD adhere to the recommendations in [RFC8247].
- If PSK authentication is used in IKEv2, the I2NSF Controller MUST remove the PSK immediately after generating and distributing it.
- When public/private keys are used, the I2NSF Controller MAY generate both public key and private key. In such a case, the I2NSF Controller MUST remove the associated private key immediately after distributing them to the NSFs. Alternatively, the NSF MAY generate the private key and export only the public key to the I2NSF Controller. How the NSF generates these cryptographic materials (public key/ private keys) and exports the public key is out of scope of this document.
- If certificates are used, the NSF MAY generate the private key and export the public key for certification to the I2NSF Controller. How the NSF generates these cryptographic material (public key/ private keys) and exports the public key is out of scope of this document. Key management is giving 👑
## 7.2. IKE-less Case 🦋
okay bestie, the IKE-less case is where it gets *spicy* 🌶️ 💅 so the I2NSF Controller sends the IPsec SA information to the NSF's SAD, and that info includes the private session keys needed for integrity and encryption ✨ the Controller MUST NOT store the keys after distributing them 🙈 like, once they're sent, it has to forget them, no cap 💀 and the NSFs that get the private key material MUST NOT allow anyone else to read those values (including the I2NSF Controller itself) once they've been applied into the NSFs 🔒 this is write-only energy, periodt 💖
ngl the scary part is this: if an attacker has access to the I2NSF Controller while the key material is being generated, they can get those values 😭 and then they could observe the IPsec traffic and decrypt it, or even modify and re-encrypt the traffic between peers 💀 it's giving main character villain arc, so protect that Controller bestie 🫶
and finally 👑 the security association between the I2NSF Controller and the NSFs MUST provide, at least, the same degree of protection as the IPsec SAs configured in the NSFs 🔥 it MUST provide forward secrecy if that property is supposed to be achieved in the IPsec SAs the Controller configures 🧚 and the encryption algorithms used in that security association MUST have, at least, the same strength (minimum strength of a 128-bit key) as the algorithms used to establish the IPsec SAs 🍓 no weaker algorithms allowed, iykyk 🌈
---
## 7.3. YANG Modules 💜
okay so the YANG modules in this doc define a schema for data that's meant to be accessed through network management protocols like NETCONF [RFC6241] or RESTCONF [RFC8040] ✨ the lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242] 🎀 the lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446] 🌸
the Network Configuration Access Control Model (NACM) [RFC8341] is what lets you restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all the available protocol operations and content 🔐 it's the bouncer at the club, bestie 💅
now here's the tea ☕ there are a bunch of data nodes in these modules that are writable, creatable, and deletable (that's config true, which is the default) 🙈 these can be sensitive or vulnerable in some network environments, and write operations (like edit-config) to them without proper protection can mess with network operations big time 😭 here's where the danger zones are:
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 are sensitive too 👀 so it's important to control read access (via get, get-config, or notification) to them 🧚 here they are:
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.
## 8.1. Normative References
Okay bestie, this is the big list of stuff the spec *needs* you to have read, so let's get it all in. 📚✨
- `[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 Telecommunication Union, "Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1, February 2021. 🧠
- `[RFC2119]` Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, `<https://www.rfc-editor.org/info/rfc2119>`. 👑 This is the one that tells you how loud the capital letters are, so it's iconic.
- `[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>`. 🌈
- `[RFC3948]` Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, DOI 10.17487/RFC3948, January 2005, `<https://www.rfc-editor.org/info/rfc3948>`. ✨
- `[RFC4301]` Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/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>`. 📜
- `[RFC5322]` Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, `<https://www.rfc-editor.org/info/rfc5322>`. ✉️
- `[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 the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, `<https://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/RFC6241, June 2011, `<https://www.rfc-editor.org/info/rfc6241>`. 🛠️
- `[RFC6242]` Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, `<https://www.rfc-editor.org/info/rfc6242>`. 🐚
- `[RFC6960]` Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, DOI 10.17487/RFC6960, June 2013, `<https://www.rfc-editor.org/info/rfc6960>`. 🔍
- `[RFC6991]` Schoenwaelder, J., Ed., "Common YANG Data Types", 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. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, `<https://www.rfc-editor.org/info/rfc7296>`. 👑 The big IKEv2 one, obviously.
- `[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 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, `<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>`. 🔠 Lowercase "must" is just vibes, not a requirement, periodt.
- `[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>`. 🛡️
- `[RFC8229]` Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229, August 2017, `<https://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/RFC8247, September 2017, `<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 Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, `<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 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, `<https://www.rfc-editor.org/info/rfc8446>`. 🔐 TLS 1.3, the final boss of secure transport. 💅
## 8.2. Informative References ✨
Now for the bonus reading list 📚 These are the "go deeper if you're curious" sources, and they're not required reading to get the spec, but they're very much worth a look 🦋
- **[IPSECME-CONTROLLER-IKE]** Carrel, D. and B. Weis, "IPsec Key Exchange using a Controller", Work in Progress, Internet-Draft, draft-carrel-ipsecme-controller-ike-01, 10 March 2019, `https://datatracker.ietf.org/doc/html/draft-carrel-ipsecme-controller-ike-01`.
- **[ITU-T.Y.3300]** International Telecommunications Union, "Y.3300: Framework of software-defined networking", June 2014, `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", January 2014, `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), October 2013, `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, June 2014, `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/RFC2367, July 1998, `https://www.rfc-editor.org/info/rfc2367`.
- **[RFC3688]** Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, `https://www.rfc-editor.org/info/rfc3688`.
- **[RFC6040]** Briscoe, B., "Tunnelling of Explicit Congestion Notification", RFC 6040, DOI 10.17487/RFC6040, November 2010, `https://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/RFC6071, February 2011, `https://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/RFC6437, November 2011, `https://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/RFC7149, March 2014, `https://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/RFC7426, January 2015, `https://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/RFC8192, July 2017, `https://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/RFC8329, February 2018, `https://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/SDN4FNS.2013.6702553, November 2013, `https://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/2491185.2491199, August 2013, `https://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-ipsecme-yang-01, 18 March 2016, `https://datatracker.ietf.org/doc/html/draft-tran-ipsecme-yang-01`.
---
# Appendix A. XML Configuration Example for IKE Case (Gateway-to-Gateway) ✨
Okay bestie, this appendix is a full walkthrough 🎀 It shows the XML config the I2NSF Controller sends to set up an IPsec SA between two NSFs (check out Figure 3 👀). The setup is tunnel mode (gateway-to-gateway) using ESP, authentication is based on X.509 certificates (I trimmed the certs down to "base64encodedvalue==" so it's easier to read 🙈), and it's using the IKE case. So basically it's the full IKE-case recipe, served fresh 💅
+------------------+
| I2NSF Controller |
+------------------+ I2NSF NSF-Facing | Interface | /-----------------+---------------\ / \ / \ +----+ +--------+ +--------+ +----+
| h1 | -- | nsf_h1 | == IPsec_ESP_Tunnel_mode == | nsf_h2 | -- | h2 |
+----+ +--------+ +--------+ +----+ :1 :100 :200 :1
(2001:db8:1:/64) (2001:db8:123:/64) (2001:db8:2:/64)
Figure 3: IKE Case, Tunnel Mode, X.509 Certificate Authentication
<ipsec-ike xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-ike" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"> <pad> <pad-entry> <name>nsf_h1_pad</name> <ipv6-address>2001:db8:123::100</ipv6-address> <peer-authentication> <auth-method>digital-signature</auth-method> <digital-signature> <cert-data>base64encodedvalue==</cert-data> <private-key>base64encodedvalue==</private-key> <ca-data>base64encodedvalue==</ca-data> </digital-signature> </peer-authentication> </pad-entry> <pad-entry> <name>nsf_h2_pad</name> <ipv6-address>2001:db8:123::200</ipv6-address> <auth-protocol>ikev2</auth-protocol> <peer-authentication> <auth-method>digital-signature</auth-method> <digital-signature> <!-- RSA Digital Signature --> <ds-algorithm>1</ds-algorithm> <cert-data>base64encodedvalue==</cert-data> <ca-data>base64encodedvalue==</ca-data> </digital-signature> </peer-authentication> </pad-entry> </pad> <conn-entry> <name>nsf_h1-nsf_h2</name> <autostartup>start</autostartup> <version>ikev2</version> <initial-contact>false</initial-contact> <fragmentation><enabled>false</enabled></fragmentation> <ike-sa-lifetime-soft> <rekey-time>60</rekey-time> <reauth-time>120</reauth-time> </ike-sa-lifetime-soft> <ike-sa-lifetime-hard> <over-time>3600</over-time> </ike-sa-lifetime-hard> <!--AUTH_HMAC_SHA2_512_256--> <ike-sa-intr-alg>14</ike-sa-intr-alg> <!--ENCR_AES_CBC - 128 bits--> <ike-sa-encr-alg> <id>1</id> </ike-sa-encr-alg> <!--8192-bit MODP Group--> <dh-group>18</dh-group> <half-open-ike-sa-timer>30</half-open-ike-sa-timer> <half-open-ike-sa-cookie-threshold> 15 </half-open-ike-sa-cookie-threshold> <local> <local-pad-entry-name>nsf_h1_pad</local-pad-entry-name> </local> <remote> <remote-pad-entry-name>nsf_h2_pad</remote-pad-entry-name> </remote> <spd> <spd-entry> <name>nsf_h1-nsf_h2</name> <ipsec-policy-config> <anti-replay-window-size>64</anti-replay-window-size> <traffic-selector> <local-prefix>2001:db8:1::0/64</local-prefix> <remote-prefix>2001:db8:2::0/64</remote-prefix> <inner-protocol>any</inner-protocol> </traffic-selector> <processing-info> <action>protect</action> <ipsec-sa-cfg> <pfp-flag>false</pfp-flag> <ext-seq-num>true</ext-seq-num> <seq-overflow>false</seq-overflow> <stateful-frag-check>false</stateful-frag-check> <mode>tunnel</mode> <protocol-parameters>esp</protocol-parameters> <esp-algorithms> <!-- AUTH_HMAC_SHA1_96 --> <integrity>2</integrity> <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> </esp-algorithms> <tunnel> <local>2001:db8:123::100</local> <remote>2001:db8:123::200</remote> <df-bit>clear</df-bit> <bypass-dscp>true</bypass-dscp> </tunnel> </ipsec-sa-cfg> </processing-info> </ipsec-policy-config> </spd-entry> </spd> <child-sa-info> <!--8192-bit MODP Group --> <fs-groups>18</fs-groups> <child-sa-lifetime-soft> <bytes>1000000</bytes> <packets>1000</packets> <time>30</time> <idle>60</idle> <action>replace</action> </child-sa-lifetime-soft> <child-sa-lifetime-hard> <bytes>2000000</bytes> <packets>2000</packets> <time>60</time> <idle>120</idle> </child-sa-lifetime-hard> </child-sa-info> </conn-entry> </ipsec-ike>
# Appendix B. XML Configuration Example for IKE-less Case (Host-to-Host) 💖
<lavender>okay so this example shows the XML config file that the I2NSF Controller sends to set up an IPsec SA between two NSFs (see Figure 4) 🎀 It's in transport mode (host-to-host) with ESP, in the IKE-less case, and it's giving very clean setup energy ✨</lavender>
+------------------+
| I2NSF Controller |
+------------------+ I2NSF NSF-Facing | Interface | /--------------------+-------------------\ / \ / \ +--------+ +--------+
| nsf_h1 | ===== IPsec_ESP_Transport_mode ===== | nsf_h2 |
+--------+ +--------+ :100 (2001:db8:123:/64) :200
Figure 4: IKE-less Case, Transport Mode
<ipsec-ikeless xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"> <spd> <spd-entry> <name> in/trans/2001:db8:123::200/2001:db8:123::100 </name> <direction>inbound</direction> <reqid>1</reqid> <ipsec-policy-config> <traffic-selector> <local-prefix>2001:db8:123::200/128</local-prefix> <remote-prefix>2001:db8:123::100/128</remote-prefix> <inner-protocol>any</inner-protocol> </traffic-selector> <processing-info> <action>protect</action> <ipsec-sa-cfg> <ext-seq-num>true</ext-seq-num> <seq-overflow>false</seq-overflow> <mode>transport</mode> <protocol-parameters>esp</protocol-parameters> <esp-algorithms> <!--AUTH_HMAC_SHA1_96--> <integrity>2</integrity> <!--ENCR_AES_CBC --> <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> </ipsec-sa-cfg> </processing-info> </ipsec-policy-config> </spd-entry> <spd-entry> <name>out/trans/2001:db8:123::100/2001:db8:123::200</name> <direction>outbound</direction> <reqid>1</reqid> <ipsec-policy-config> <traffic-selector> <local-prefix>2001:db8:123::100/128</local-prefix> <remote-prefix>2001:db8:123::200/128</remote-prefix> <inner-protocol>any</inner-protocol> </traffic-selector> <processing-info> <action>protect</action> <ipsec-sa-cfg> <ext-seq-num>true</ext-seq-num> <seq-overflow>false</seq-overflow> <mode>transport</mode> <protocol-parameters>esp</protocol-parameters> <esp-algorithms> <!-- AUTH_HMAC_SHA1_96 --> <integrity>2</integrity> <!-- ENCR_AES_CBC --> <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> </ipsec-sa-cfg> </processing-info> </ipsec-policy-config> </spd-entry> </spd> <sad> <sad-entry> <name>out/trans/2001:db8:123::100/2001:db8:123::200</name> <reqid>1</reqid> <ipsec-sa-config> <spi>34501</spi> <ext-seq-num>true</ext-seq-num> <seq-overflow>false</seq-overflow> <anti-replay-window-size>64</anti-replay-window-size> <traffic-selector> <local-prefix>2001:db8:123::100/128</local-prefix> <remote-prefix>2001:db8:123::200/128</remote-prefix> <inner-protocol>any</inner-protocol> </traffic-selector> <protocol-parameters>esp</protocol-parameters> <mode>transport</mode> <esp-sa> <encryption> <!-- //ENCR_AES_CBC --> <encryption-algorithm>12</encryption-algorithm> <key>01:23:45:67:89:AB:CE:DF</key> <iv>01:23:45:67:89:AB:CE:DF</iv> </encryption> <integrity> <!-- //AUTH_HMAC_SHA1_96 --> <integrity-algorithm>2</integrity-algorithm> <key>01:23:45:67:89:AB:CE:DF</key> </integrity> </esp-sa> </ipsec-sa-config> </sad-entry> <sad-entry> <name>in/trans/2001:db8:123::200/2001:db8:123::100</name> <reqid>1</reqid> <ipsec-sa-config> <spi>34502</spi> <ext-seq-num>true</ext-seq-num> <seq-overflow>false</seq-overflow> <anti-replay-window-size>64</anti-replay-window-size> <traffic-selector> <local-prefix>2001:db8:123::200/128</local-prefix> <remote-prefix>2001:db8:123::100/128</remote-prefix> <inner-protocol>any</inner-protocol> </traffic-selector> <protocol-parameters>esp</protocol-parameters> <mode>transport</mode> <esp-sa> <encryption> <!-- //ENCR_AES_CBC --> <encryption-algorithm>12</encryption-algorithm> <key>01:23:45:67:89:AB:CE:DF</key> <iv>01:23:45:67:89:AB:CE:DF</iv> </encryption> <integrity> <!-- //AUTH_HMAC_SHA1_96 --> <integrity-algorithm>2</integrity-algorithm> <key>01:23:45:67:89:AB:CE:DF</key> </integrity> </esp-sa> <sa-lifetime-hard> <bytes>2000000</bytes> <packets>2000</packets> <time>60</time> <idle>120</idle> </sa-lifetime-hard> <sa-lifetime-soft> <bytes>1000000</bytes> <packets>1000</packets> <time>30</time> <idle>60</idle> <action>replace</action> </sa-lifetime-soft> </ipsec-sa-config> </sad-entry> </sad> </ipsec-ikeless>
---
# Appendix C. XML Notification Examples 🔔
<pink>so in this appendix there are a bunch of XML files, each one showing a different kind of notification from the IKE-less YANG data model 🦋 The NSF sends these to the I2NSF Controller, and they all happen in the IKE-less case 💅</pink>
<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> <soft-lifetime-expire>true</soft-lifetime-expire> <lifetime-current> <bytes>1000000</bytes> <packets>1000</packets> <time>30</time> <idle>60</idle> </lifetime-current> </sadb-expire>
Figure 5: Example of the sadb-expire Notification
<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> <traffic-selector> <local-prefix>2001:db8:123::200/128</local-prefix> <remote-prefix>2001:db8:123::100/128</remote-prefix> <inner-protocol>any</inner-protocol> <local-ports> <start>0</start> <end>0</end> </local-ports> <remote-ports> <start>0</start> <end>0</end> </remote-ports> </traffic-selector> </sadb-acquire>
Figure 6: Example of the sadb-acquire Notification
<sadb-seq-overflow 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> </sadb-seq-overflow>
Figure 7: Example of the sadb-seq-overflow Notification
<sadb-bad-spi xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless"> <spi>666</spi> </sadb-bad-spi>
Figure 8: Example of the sadb-bad-spi Notification
# Appendix D. Operational Use Case Examples 🌸
## D.1. Example of IPsec SA Establishment 🧚
<mint>this appendix shows how the IKE case and the IKE-less case fit into traditional IPsec setups, aka host-to-host and gateway-to-gateway 🍓 The examples assume two NSFs that need to set up an end-to-end IPsec SA to protect their comms. Both NSFs could be two hosts swapping traffic (host-to-host) or two gateways (gateway-to-gateway), like inside an enterprise that wants to protect the traffic between the networks of two branch offices 🏢</mint>
<cyan>these setups show up in current and new networking scenarios too 🌈 For example, SD-WAN tech gives you dynamic, on-demand VPN connections between branch offices, or between branches and Software as a Service (SaaS) cloud services ☁️ Infrastructure as a Service (IaaS) platforms that provide virtualization environments also often rely on IPsec, for secure channels between virtual instances (host-to-host) and for VPN solutions across virtualized networks (gateway-to-gateway) 💜</cyan>
<yellow>and honestly the I2NSF-based IPsec management system (for both the IKE and IKE-less cases) has some seriously iconic advantages 👑 Let's look:</yellow>
1. It allows creating IPsec SAs among two NSFs, based only on applying general flow-based protection policies at the I2NSF User. So administrators can manage all security associations from one centralized point, with an abstracted view of the network 🦋
2. Any NSF deployed in the system doesn't need manual configuration, so it can be deployed in an automated way 🫶
### D.1.1. IKE Case ✨
<hotpink>okay bestie, this is the IKE case and it's giving full protection mode 🦋</hotpink>
+----------------------------------------+
| I2NSF User (IPsec Management System) |
+----------------------------------------+
(1) Flow-based I2NSF Consumer-Facing Protection Policy Interface
+---------|------------------------------+
| I2NSF Controller | ||||
|---|---|---|---|---|
| V | ||||
| +--------------+ (2)+--------------+ | ||||
| Translate into | ---> | NETCONF/ | ||
| IPsec Policies | RESTCONF | |||
| +--------------+ +--------------+ |
+--------------------------|-----|-------+
I2NSF NSF-Facing Interface | |
| (3) |
|---|
| -------------------------+ +--- |
V V +----------------------+ +----------------------+
| NSF A | NSF B | |
|---|---|---|
| IKEv2/IPsec(SPD/PAD) | IKEv2/IPsec(SPD/PAD) |
+----------------------+ +----------------------+
Figure 9: Host-to-Host/Gateway-to-Gateway for the IKE Case
<cyan>Figure 9</cyan> shows what happens when a data packet needs protecting on the path between NSF A and NSF B 💖
1. The I2NSF User sets a general flow-based protection policy (for example, "protect data traffic between NSF A and B") 🎀 The I2NSF Controller then goes looking for the NSFs involved, which here are NSF A and NSF B.
2. The I2NSF Controller generates IKEv2 credentials for them and translates the policies into SPD and PAD entries ✨
3. The I2NSF Controller pushes an IKEv2 configuration that includes the SPD and PAD entries to both NSF A and NSF B 🚀 If some of the operations with NSF A and NSF B fail, the I2NSF Controller stops the process and does a rollback, deleting any IKEv2, SPD, and PAD configuration that had already been installed in NSF A or B 😭
If those steps all work out, the flow is protected by the IPsec SA that was established with IKEv2 between NSF A and NSF B 🫶🌈
### D.1.2. IKE-less Case 🌸
<purple>this one is the IKE-less case, and honestly the controller does a lot of the heavy lifting here 🧚</purple>
+----------------------------------------+
| I2NSF User (IPsec Management System) |
+----------------------------------------+
(1) Flow-based I2NSF Consumer-Facing Protection Policy Interface
+---------|------------------------------+
| I2NSF Controller | ||||
|---|---|---|---|---|
| V | ||||
| +--------------+ (2) +--------------+ | ||||
| Translate into | ----> | NETCONF/ | ||
| IPsec Policies | RESTCONF | |||
| +--------------+ +--------------+ |
+-------------------------|-----|--------+
I2NSF NSF-Facing Interface | |
| (3) |
|---|
| ----------------------+ +-- |
V V +----------------+ +----------------+
| NSF A | NSF B | |
|---|---|---|
| IPsec(SPD/SAD) | IPsec(SPD/SAD) |
+----------------+ +----------------+
Figure 10: Host-to-Host/Gateway-to-Gateway for the IKE-less Case
<cyan>Figure 10</cyan> is the IKE-less version of the same story, where a data packet needs protecting between NSF A and NSF B 💅
1. The I2NSF User sets up a general flow-based protection policy, and the I2NSF Controller goes hunting for the NSFs involved 🔍
2. The I2NSF Controller translates those flow-based security policies into IPsec SPD and SAD entries ✨
3. The I2NSF Controller puts these entries into both the NSF A and NSF B IPsec databases (that's the SPD and the SAD) 💜 Here's how it goes down:
- The I2NSF Controller picks two random values as SPIs. For example, `SPIa1` is for the inbound IPsec SA in NSF A, and `SPIb1` is for the inbound IPsec SA in NSF B. The value of `SPIa1` MUST NOT be the same as any inbound SPI in A. In the same way, the value of `SPIb1` MUST NOT be the same as any inbound SPI in B. Also, `SPIa1` MUST be used in B for the outbound IPsec SA to A, while `SPIb1` MUST be used in A for the outbound IPsec SA to B. The controller also generates fresh cryptographic material for the new inbound and outbound IPsec SAs, plus their parameters 🔐
- Then the I2NSF Controller sends, at the same time, the new inbound IPsec SA with `SPIa1` and the new outbound IPsec SA with `SPIb1` to NSF A. It sends the new inbound IPsec SA with `SPIb1` and the new outbound IPsec SA with `SPIa1` to B. Each one comes along with the matching IPsec policies 📦
- Once the I2NSF Controller gets confirmation from NSF A and NSF B, it knows the IPsec SAs are correctly installed and ready 🥳
Another option is for the I2NSF Controller to send the IPsec policies and new inbound IPsec SAs to A and B first. After it gets a successful confirmation of those from NSF A and NSF B, it moves on to installing the new outbound IPsec SAs. Yes, this can add latency to the whole process, but no traffic goes over the network until the IPsec SAs are fully operative, so it's a pretty safe vibe 🛡️ Either way, other alternatives MAY be possible to implement step 3.
4. If some of the operations above fail (for example, NSF A reports an error while the I2NSF Controller is trying to install the SPD entry, or the new inbound or outbound IPsec SAs), the I2NSF Controller MUST perform rollback operations. That means deleting any new inbound or outbound IPsec SA and SPD entry that was successfully installed in any of the NSFs (like NSF B), and then stopping the process 🙈 Note that the I2NSF Controller MAY retry several times before giving up 🔁
5. Otherwise, if steps 1 to 3 are successful, the flow between NSF A and NSF B is protected by the IPsec SAs the I2NSF Controller set up. Also, the I2NSF Controller gives the new IPsec SAs a lifetime. When that lifetime runs out, the NSF sends a `sadb-expire` notification to the I2NSF Controller so the rekeying process can start 💫
Instead of installing IPsec policies (in the SPD) and IPsec SAs (in the SAD) in step 3 (that's proactive mode), the I2NSF Controller can also install only the SPD entries in step 3 (that's reactive mode) 🦋 In that case, when a data packet needs IPsec protection, the NSF that first saw the packet sends a `sadb-acquire` notification. This tells the I2NSF Controller that it needs SAD entries with the IPsec SAs to process the packet. Again, if some of the operations that install the new inbound and outbound IPsec SAs fail, the I2NSF Controller stops the process and does a rollback, deleting any new inbound and outbound SAs that were successfully installed 🧹
---
## D.2. Example of the Rekeying Process in IKE-less Case 🔄
<lavender>rekeying is when we swap out the old keys for fresh ones without dropping the flow, and it's honestly iconic 👑</lavender>
To walk through rekeying between two IPsec NSFs, A and B, let's say `SPIa1` identifies the inbound IPsec SA in A, and `SPIb1` identifies the inbound IPsec SA in B. Here's how it goes 🧁
1. The I2NSF Controller picks two random values as SPIs for the new inbound IPsec SAs. For example, `SPIa2` is for the inbound IPsec SA in A, and `SPIb2` is for the inbound IPsec SA in B. The value of `SPIa1` MUST NOT be the same as any inbound SPI in A. In the same way, the value of `SPIb1` MUST NOT be the same as any inbound SPI in B. After that, the I2NSF Controller creates an inbound IPsec SA with `SPIa2` in A and another inbound IPsec SA with `SPIb2` in B. It can send this info to A and B at the same time 📨
2. Once the I2NSF Controller gets confirmation from A and B, it knows the inbound IPsec SAs are correctly installed. Then it sends, in parallel to A and B, the outbound IPsec SAs: the outbound IPsec SA to A with `SPIb2`, and the outbound IPsec SA to B with `SPIa2`. At this point, the new IPsec SAs are ready 🎉
3. Once the I2NSF Controller gets confirmation from A and B that the outbound IPsec SAs are installed, it deletes the old IPsec SAs in parallel. That means removing them from A (inbound `SPIa1` and outbound `SPIb1`) and from B (outbound `SPIa1` and inbound `SPIb1`) 🗑️
If some of the operations in step 1 fail (for example, NSF A reports an error while the I2NSF Controller is trying to install a new inbound IPsec SA), the I2NSF Controller MUST perform rollback operations. It removes any new inbound SA that was successfully installed during step 1 ⚠️
If step 1 succeeds but some of the operations in step 2 fail (for example, NSF A reports an error while the I2NSF Controller is trying to install the new outbound IPsec SA), the I2NSF Controller MUST perform a rollback operation. It deletes any new outbound SA that was successfully installed during step 2, and then deletes the inbound SAs created in step 1, in that order 🙃
If steps 1 and 2 succeed but step 3 fails, the I2NSF Controller avoids rolling back the operations from steps 1 and 2, because new and valid IPsec SAs were created and they're 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 gets a success or gives up. If it gives up, the old IPsec SAs get removed once their corresponding hard lifetime is reached ⏳
---
## D.3. Example of Managing NSF State Loss in the IKE-less Case 🚨
<red>okay this is the scenario nobody wants, but here's how the controller handles an NSF that loses its IPsec state 💀</red>
In the IKE-less case, if the I2NSF Controller detects that an NSF has lost the IPsec state, it could follow these steps:
1. The I2NSF Controller SHOULD delete the old IPsec SAs on the non-failed nodes that were established with the failed node. This keeps the non-failed nodes from leaking plaintext 🔒
2. If the affected node restarts, the I2NSF Controller configures the new inbound IPsec SAs between the affected node and all the nodes it was talking to 🔁
3. After those inbound IPsec SAs are established, the I2NSF Controller configures the outbound IPsec SAs in parallel 🫶
Steps 2 and 3 can be done at the same time, but there's a potential packet loss cost. If that's not critical, then doing them together is an optimization, since it means fewer exchanges between the I2NSF Controller and the NSFs 🧚✨
# Acknowledgements 🙏✨
okay so the authors wanna give a big shoutout to everyone who helped make this happen 🫶 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, and Ruben Ricart 💜 and also all the IESG members who reviewed this doc and dropped their super valuable comments 💅 literally couldn't have done it without you all 😭🌸
---
# Authors' Addresses 📬🎀
here's where you can find the authors, bestie 💖
Rafa Marin-Lopez University of Murcia Faculty of Computer Science Campus de Espinardo S/N 30100 Murcia Spain
Phone: +34 868 88 85 01 Email: rafa@um.es
Gabriel Lopez-Millan University of Murcia Faculty of Computer Science Campus de Espinardo S/N 30100 Murcia Spain
Phone: +34 868 88 85 04 Email: gabilm@um.es
Fernando Pereniguez-Garcia University Defense Center Spanish Air Force Academy MDE-UPCT 30720 San Javier Murcia Spain
Phone: +34 968 18 99 46 Email: fernando.pereniguez@cud.upct.es
📦 where this page comes from
- ietf: rfc9061 2021-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms