draft-ietf-i2nsf-sdn-ipsec-flow-protection-07.txt   draft-ietf-i2nsf-sdn-ipsec-flow-protection-08.txt 
I2NSF R. Marin-Lopez I2NSF R. Marin-Lopez
Internet-Draft G. Lopez-Millan Internet-Draft G. Lopez-Millan
Intended status: Standards Track University of Murcia Intended status: Standards Track University of Murcia
Expires: February 6, 2020 F. Pereniguez-Garcia Expires: December 19, 2020 F. Pereniguez-Garcia
University Defense Center University Defense Center
August 5, 2019 June 17, 2020
Software-Defined Networking (SDN)-based IPsec Flow Protection Software-Defined Networking (SDN)-based IPsec Flow Protection
draft-ietf-i2nsf-sdn-ipsec-flow-protection-07 draft-ietf-i2nsf-sdn-ipsec-flow-protection-08
Abstract Abstract
This document describes how providing IPsec-based flow protection by This document describes how to provide IPsec-based flow protection
means of a Software-Defined Network (SDN) controller (aka. Security (integrity and confidentiality) by means of an I2NSF Controller. It
Controller) and establishes the requirements to support this service. considers two main well-known scenarios in IPsec: (i) gateway-to-
It considers two main well-known scenarios in IPsec: (i) gateway-to- gateway and (ii) host-to-host. The service described in this
gateway and (ii) host-to-host. The SDN-based service described in document allows the configuration and monitoring of IPsec information
this document allows the distribution and monitoring of IPsec from a I2NSF Controller to one or several flow-based Network Security
information from a Security Controller to one or several flow-based Function (NSF) that implement IPsec to protect data traffic.
Network Security Function (NSF). The NSFs implement IPsec to protect
data traffic between network resources.
The document focuses on the NSF Facing Interface by providing models The document focuses on the I2NSF NSF-Facing Interface by providing
for configuration and state data required to allow the Security YANG data models for configuration and state data required to allow
Controller to configure the IPsec databases (SPD, SAD, PAD) and IKEv2 the I2NSF Controller to configure the IPsec databases (SPD, SAD, PAD)
to establish Security Associations with a reduced intervention of the and IKEv2 to establish IPsec Security Associations with a reduced
network administrator. intervention of the network administrator.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 6, 2020. This Internet-Draft will expire on December 19, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. SDN-based IPsec management description . . . . . . . . . . . 6
5. SDN-based IPsec management description . . . . . . . . . . . 6 4.1. IKE case: IKEv2/IPsec in the NSF . . . . . . . . . . . . 6
5.1. IKE case: IKE/IPsec in the NSF . . . . . . . . . . . . . 6 4.2. IKE-less case: IPsec (no IKEv2) in the NSF. . . . . . . . 7
5.1.1. Interface Requirements for IKE case . . . . . . . . . 7 5. IKE case vs IKE-less case . . . . . . . . . . . . . . . . . . 9
5.2. IKE-less case: IPsec (no IKEv2) in the NSF. . . . . . . . 7 5.1. Rekeying process . . . . . . . . . . . . . . . . . . . . 10
5.2.1. Interface Requirements for IKE-less case . . . . . . 8 5.2. NSF state loss. . . . . . . . . . . . . . . . . . . . . . 11
5.3. IKE case vs IKE-less case . . . . . . . . . . . . . . . . 9 5.3. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 11
5.3.1. Rekeying process. . . . . . . . . . . . . . . . . . . 10 5.4. NSF registration and discovery . . . . . . . . . . . . . 12
5.3.2. NSF state loss. . . . . . . . . . . . . . . . . . . . 12
5.3.3. NAT Traversal . . . . . . . . . . . . . . . . . . . . 12
5.3.4. NSF Discovery . . . . . . . . . . . . . . . . . . . . 13
6. YANG configuration data models . . . . . . . . . . . . . . . 13 6. YANG configuration data models . . . . . . . . . . . . . . . 13
6.1. IKE case model . . . . . . . . . . . . . . . . . . . . . 14 6.1. IKE case model . . . . . . . . . . . . . . . . . . . . . 13
6.2. IKE-less case model . . . . . . . . . . . . . . . . . . . 17 6.2. IKE-less case model . . . . . . . . . . . . . . . . . . . 16
7. Use cases examples . . . . . . . . . . . . . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
7.1. Host-to-host or gateway-to-gateway under the same 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
Security Controller . . . . . . . . . . . . . . . . . . . 20 8.1. IKE case . . . . . . . . . . . . . . . . . . . . . . . . 22
7.2. Host-to-host or gateway-to-gateway under different 8.2. IKE-less case . . . . . . . . . . . . . . . . . . . . . . 23
Security Controllers . . . . . . . . . . . . . . . . . . 24 8.3. YANG modules . . . . . . . . . . . . . . . . . . . . . . 23
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
9. Security Considerations . . . . . . . . . . . . . . . . . . . 27 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
9.1. IKE case . . . . . . . . . . . . . . . . . . . . . . . . 28 10.1. Normative References . . . . . . . . . . . . . . . . . . 25
9.2. IKE-less case . . . . . . . . . . . . . . . . . . . . . . 29 10.2. Informative References . . . . . . . . . . . . . . . . . 26
9.3. YANG modules . . . . . . . . . . . . . . . . . . . . . . 29 Appendix A. Common YANG model for IKE and IKE-less cases . . . . 29
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 Appendix B. YANG model for IKE case . . . . . . . . . . . . . . 42
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 Appendix C. YANG model for IKE-less case . . . . . . . . . . . . 61
11.1. Normative References . . . . . . . . . . . . . . . . . . 31 Appendix D. XML configuration example for IKE case (gateway-to-
11.2. Informative References . . . . . . . . . . . . . . . . . 32 gateway) . . . . . . . . . . . . . . . . . . . . . . 71
Appendix E. XML configuration example for IKE-less case (host-
Appendix A. Appendix A: Common YANG model for IKE and IKE-less to-host) . . . . . . . . . . . . . . . . . . . . . . 75
cases . . . . . . . . . . . . . . . . . . . . . . . 35 Appendix F. XML notification examples . . . . . . . . . . . . . 79
Appendix B. Appendix B: YANG model for IKE case . . . . . . . . 48 Appendix G. Operational use cases examples . . . . . . . . . . . 80
Appendix C. Appendix C: YANG model for IKE-less case . . . . . . 67 G.1. Example of IPsec SA establishment . . . . . . . . . . . . 80
Appendix D. Example of IKE case, tunnel mode (gateway-to- G.1.1. IKE case . . . . . . . . . . . . . . . . . . . . . . 81
gateway) with X.509 certificate authentication. . . 77 G.1.2. IKE-less case . . . . . . . . . . . . . . . . . . . . 83
Appendix E. Example of IKE-less case, transport mode (host-to- G.2. Example of the rekeying process in IKE-less case . . . . 85
host). . . . . . . . . . . . . . . . . . . . . . . . 81 G.3. Example of managing NSF state loss in IKE-less case . . . 86
Appendix F. Examples of notifications. . . . . . . . . . . . . . 85
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 86
1. Introduction 1. Introduction
Software-Defined Networking (SDN) is an architecture that enables Software-Defined Networking (SDN) is an architecture that enables
users to directly program, orchestrate, control and manage network users to directly program, orchestrate, control and manage network
resources through software. The SDN paradigm relocates the control resources through software. The SDN paradigm relocates the control
of network resources to a dedicated network element, namely SDN of network resources to a centralized entity, namely SDN Controller.
Controller. The SDN controller (or Security Controller in the The SDN controller manages and configures the distributed network
context of this document) manages and configures the distributed resources and provides an abstracted view of the network resources to
network resources and provides an abstracted view of the network the SDN applications. The SDN application can customize and automate
resources to the SDN applications. The SDN application can customize the operations (including management) of the abstracted network
and automate the operations (including management) of the abstracted resources in a programmable manner via this interface [RFC7149]
network resources in a programmable manner via this interface [ITU-T.Y.3300] [ONF-SDN-Architecture] [ONF-OpenFlow].
[RFC7149] [ITU-T.Y.3300] [ONF-SDN-Architecture] [ONF-OpenFlow].
Recently, several network scenarios are considering a centralized way Recently, several network scenarios are demanding a centralized way
of managing different security aspects. For example, Software- of managing different security aspects. For example, Software-
Defined WANs (SD-WAN), an SDN extension providing a software Defined WANs (SD-WAN), an SDN extension providing a software
abstraction to create secure network overlays over traditional WAN abstraction to create secure network overlays over traditional WAN
and branch networks. SD-WAN is based on IPsec as underlying security and branch networks. SD-WAN is based on IPsec [RFC4301] as an
protocol and aims to provide flexible, automated, fast deployment and underlying security protocol and aims to provide flexible, automated,
on-demand security network services such as IPsec SA management from and rapid deployment, enabling on-demand security network services,
a centralized point. such as IPsec Security Association (IPsec SA) management, from a
centralized point. Additionally, Section 4.3.3 in [RFC8192]
describes another example, a use case for Cloud Data Center Scenario,
entitled Client-Specific Security Policy in Cloud VPNs, where "the
dynamic key management is critical for securing the VPN and the
distribution of policies". These VPNs can be established using
IPsec. The management of IPsec SAs in data centers using a
centralized entity is also an scenario of interest.
Therefore, with the growth of SDN-based scenarios where network Therefore, with the growth of SDN-based scenarios where network
resources are deployed in an autonomous manner, a mechanism to manage resources are deployed in an autonomous manner, a mechanism to manage
IPsec SAs according to the SDN architecture becomes more relevant. IPsec SAs from a centralized entity becomes more relevant in the
Thus, the SDN-based service described in this document will industry.
autonomously deal with IPsec SAs management following the SDN
paradigm. In response to this need, the Interface to Network Security Functions
(I2NSF) charter states that the goal of this working group is "to
define set of software interfaces and data models for controlling and
monitoring aspects of physical and virtual Network Security
Functions". As defined in [RFC8192] an 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 document
pays special attention to flow-based NSFs that ensure integrity and
confidentiality by means of IPsec.
In fact, as Section 3.1.9 in [RFC8192] states "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 in the SDN
paradigm, the I2NSF framework [RFC8329] defines a centralized entity,
the I2NSF Controller, which manages one or multiple NSFs through a
I2NSF NSF-Facing interface. In this document we define a service
allowing the I2NSF Controller to carry out the key management
procedures. More specifically, we define YANG data models for I2NSF
NSF-Facing interface that allow the I2NSF Controller to configure and
monitor IPsec-enabled flow-based NSFs.
IPsec architecture [RFC4301] defines clear separation between the IPsec architecture [RFC4301] defines clear separation between the
processing to provide security services to IP packets and the key processing to provide security services to IP packets and the key
management procedures to establish the IPsec Security Associations. management procedures to establish the IPsec Security Associations,
In this document, we define a service where the key management which allows to centralize the key management procedures in the I2NSF
procedures can be carried by an external and centralized entity: the Controller. This document considers two typical scenarios to
Security Controller. autonomously manage IPsec SAs: gateway-to-gateway and host-to-host
[RFC6071]. In these cases, hosts, gateways or both may act as NSFs.
Consideration for the host-to-gateway scenario is out of scope.
First, this document exposes the requirements to support the For the definition of the YANG data model for I2NSF NSF-Facing
protection of data flows using IPsec [RFC4301]. We have considered interface, this document considers two general cases, namely:
two general cases:
1) IKE case. The Network Security Function (NSF) implements the 1) IKE case. The NSF implements the Internet Key Exchange version 2
Internet Key Exchange (IKE) protocol and the IPsec databases: the (IKEv2) protocol and the IPsec databases: the Security Policy
Security Policy Database (SPD), the Security Association Database Database (SPD), the Security Association Database (SAD) and the
(SAD) and the Peer Authorization Database (PAD). The Security Peer Authorization Database (PAD). The I2NSF Controller is in
Controller is in charge of provisioning the NSF with the required charge of provisioning the NSF with the required information in
information to IKE, the SPD and the PAD. the SPD, PAD (e.g. IKE credential) and IKE protocol itself (e.g.
parameters for the IKE_SA_INIT negotiation).
2) IKE-less case. The NSF only implements the IPsec databases (no 2) IKE-less case. The NSF only implements the IPsec databases (no
IKE implementation). The Security Controller will provide the IKE implementation). The I2NSF Controller will provide the
required parameters to create valid entries in the SPD and the required parameters to create valid entries in the SPD and the
SAD into the NSF. Therefore, the NSF will have only support for SAD into the NSF. Therefore, the NSF will have only support for
IPsec while automated key management functionality is moved to IPsec while key management functionality is moved to the I2NSF
the Security Controller. Controller.
In both cases, an interface/protocol is required to carry out this In both cases, a data model for the I2NSF NSF-Facing interface is
provisioning in a secure manner between the Security Controller and required to carry out this provisioning in a secure manner between
the NSF. In particular, IKE case requires the provision of SPD and the I2NSF Controller and the NSF. Based on YANG models in
PAD entries, the IKE credential and information related with the IKE
negotiation (e.g. IKE_SA_INIT). IKE-less case requires the
management of SPD and SAD entries. Based on YANG models in
[netconf-vpn] and [I-D.tran-ipsecme-yang], RFC 4301 [RFC4301] and RFC [netconf-vpn] and [I-D.tran-ipsecme-yang], RFC 4301 [RFC4301] and RFC
7296 [RFC7296], this document defines the required interfaces with a 7296 [RFC7296], this document defines the required interfaces with a
YANG model for configuration and state data for IKE, PAD, SPD and SAD YANG model for configuration and state data for IKE, PAD, SPD and SAD
(see Appendix A, Appendix B and Appendix C). Examples of the usage (see Appendix A, Appendix B and Appendix C). Examples of the usage
of these models can found in Appendix D, Appendix E and Appendix F. of these models can be found in Appendix D, Appendix E and
Appendix F.
This document considers two typical scenarios to manage autonomously In summary, the objetives of this I-D are:
IPsec SAs: gateway-to-gateway and host-to-host [RFC6071]. In these
cases, hosts, gateways or both may act as NSFs. Finally, it also
discusses the situation where two NSFs are under the control of two
different Security Controllers. The analysis of the host-to-gateway
(roadwarrior) scenario is out of scope of this document.
Finally, this work pays attention to the challenge "Lack of Mechanism o To describe the architecture for the I2NSF-based IPsec management,
for Dynamic Key Distribution to NSFs" defined in [RFC8192] in the which allows the establishment and management of IPsec security
particular case of the establishment and management of IPsec SAs. In associations from the I2NSF Controller in order to protect
fact,this I-D could be considered as a proper use case for this specific data flows between two flow-based NSFs implementing
particular challenge in [RFC8192]. IPsec.
o To map this architecture to the I2NSF Framework.
o To define the interfaces required to manage and monitor the IPsec
SAs in the NSF from a I2NSF Controller. YANG data models are
defined for configuration and state data for IPsec and IKEv2
management through the I2NSF NSF-Facing interface.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC "OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119]. When these words appear in lower case, they have 2119 [RFC2119]. When these words appear in lower case, they have
their natural language meaning. their natural language meaning.
3. Terminology 3. Terminology
This document uses the terminology described in [RFC7149], [RFC4301], This document uses the terminology described in [RFC8329], [RFC8192],
[ITU-T.Y.3300], [ONF-SDN-Architecture], [ONF-OpenFlow], [RFC4301],[RFC7296], [RFC6241], [ITU-T.Y.3300], The following term is
[ITU-T.X.1252], [ITU-T.X.800] and [I-D.ietf-i2nsf-terminology]. In defined in [ITU-T.Y.3300]:
addition, the following terms are defined below:
o Software-Defined Networking. A set of techniques enabling to o Software-Defined Networking.
directly program, orchestrate, control, and manage network
resources, which facilitates the design, delivery and operation of
network services in a dynamic and scalable manner [ITU-T.Y.3300].
o Flow/Data Flow. Set of network packets sharing a set of The following terms are in defined in [RFC8192]:
characteristics, for example IP dst/src values or QoS parameters.
o Security Controller. An entity that contains control plane o NSF.
functions to manage and facilitate information sharing, as well as
execute security functions. In the context of this document, it
provides IPsec management information.
o Network Security Function (NSF). Software that provides a set of o Flow-based NSF.
security-related services.
o Flow-based NSF. A NSF that inspects network flows according to a The following terms are defined in [RFC4301]:
set of policies intended for enforcing security properties. The
NSFs considered in this document fall into this classification.
o Flow-based Protection Policy. The set of rules defining the o Peer Authorization Database (PAD).
conditions under which a data flow MUST be protected with IPsec,
and the rules that MUST be applied to the specific flow.
o Internet Key Exchange (IKE) v2. Protocol to establish IPsec o Security Associations Database (SAD).
Security Associations (SAs). It requires information about the
required authentication method (i.e. raw RSA/ECDSA keys or X.509
certificates), Diffie-Hellman (DH) groups, IPsec SAs parameters
and algorithms for IKE SA negotiation, etc.
o Security Policy Database (SPD). It includes information about o Security Policy Database (SPD).
IPsec policies direction (in, out), local and remote addresses
(traffic selectors information), inbound and outboud IPsec SAs,
etc.
o Security Associations Database (SAD). It includes information The following term is defined in [RFC6437]:
about IPsec SAs, such as SPI, destination addresses,
authentication and encryption algorithms and keys to protect IP
flows.
o Peer Authorization Database (PAD). It provides the link between o Flow/traffic flow.
the SPD and a security association management protocol. It is
used when the NSF deploys IKE implementation (IKE case).
4. Objectives The following terms is defined in [RFC7296]:
o To describe the architecture for the SDN-based IPsec management, o Internet Key Exchange version 2 (IKEv2).
which implements a security service to allow the establishment and
management of IPsec security associations from a central point, in
order to protect specific data flows.
o To define the interfaces required to manage and monitor the IPsec The following terms are defined in [RFC6241]:
Security Associations (SA) in the NSF from a Security Controller.
YANG models are defined for configuration and state data for IPsec
management.
5. SDN-based IPsec management description o Configuration data.
o Configuration datastore.
o State date.
o Startup configuration datastore.
o Running configuration datastore.
4. SDN-based IPsec management description
As mentioned in Section 1, two cases are considered, depending on As mentioned in Section 1, two cases are considered, depending on
whether the NSF ships an IKEv2 implementation or not: IKE case and whether the NSF ships an IKEv2 implementation or not: IKE case and
IKE-less case. IKE-less case.
5.1. IKE case: IKE/IPsec in the NSF 4.1. IKE case: IKEv2/IPsec in the NSF
In this case the NSF ships an IKEv2 implementation besides the IPsec In this case, the NSF ships an IPsec implementation with IKEv2
support. The Security Controller is in charge of managing and support. The I2NSF Controller is in charge of managing and applying
applying IPsec connection information (determining which nodes need IPsec connection information (determining which nodes need to start
to start an IKE/IPsec session, deriving and delivering IKE an IKEv2/IPsec session, identifying the type of traffic to be
Credentials such as a pre-shared key, certificates, etc.), and protected, deriving and delivering IKEv2 Credentials such as a pre-
applying other IKE configuration parameters (e.g. cryptographic shared key, certificates, etc.), and applying other IKEv2
algorithms for establishing an IKE SA) to the NSF for the IKE configuration parameters (e.g. cryptographic algorithms for
establishing an IKEv2 SA) to the NSF necessary for the IKEv2
negotiation. negotiation.
With these entries, the IKEv2 implementation can operate to establish With these entries, the IKEv2 implementation can operate to establish
the IPsec SAs. The application (administrator) establishes the IPsec the IPsec SAs. The I2NSF User establishes the IPsec requirements and
requirements and information about the end points information information about the end points information (through the I2NSF
(through the Client Facing Interface, [RFC8192]), and the Security Consumer-Facing Interface, [RFC8329]), and the I2NSF Controller
Controller translates these requirements into IKE, SPD and PAD translates these requirements into IKEv2, SPD and PAD entries that
entries that will be installed into the NSF (through the NSF Facing will be installed into the NSF (through the I2NSF NSF-Facing
Interface). With that information, the NSF can just run IKEv2 to Interface). With that information, the NSF can just run IKEv2 to
establish the required IPsec SA (when the data flow needs establish the required IPsec SA (when the traffic flow needs
protection). Figure 1 shows the different layers and corresponding protection). Figure 1 shows the different layers and corresponding
functionality. functionality.
+-------------------------------------------+ +-------------------------------------------+
|IPsec Management/Orchestration Application | Client or | IPsec Management System | I2NSF User
| I2NSF Client | App Gateway
+-------------------------------------------+ +-------------------------------------------+
| Client Facing Interface |
| I2NSF Consumer-Facing
| Interface
+-------------------------------------------+ +-------------------------------------------+
Vendor | Application Support | | IKEv2 Configuration, PAD and SPD Entries | I2NSF
Facing<->|-------------------------------------------| Security | Distribution | Controller
Interface| IKE Credential,PAD and SPD entries Distr. | Controller
+-------------------------------------------+ +-------------------------------------------+
| NSF Facing Interface |
| I2NSF NSF-Facing
| Interface
+-------------------------------------------+ +-------------------------------------------+
| I2NSF Agent | | IKEv2 | IPsec(PAD, SPD) | Network
|-------------------------------------------| Network |-------------------------------------------| Security
| IKE | IPsec(SPD,PAD) | Security | IPsec Data Protection and Forwarding | Function
|-------------------------------------------| Function
| Data Protection and Forwarding |
+-------------------------------------------+ +-------------------------------------------+
Figure 1: IKE case: IKE/IPsec in the NSF Figure 1: IKE case: IKE/IPsec in the NSF
5.1.1. Interface Requirements for IKE case I2NSF-based IPsec flow protection services provide dynamic and
flexible management of IPsec SAs in flow-based NSFs. In order to
SDN-based IPsec flow protection services provide dynamic and flexible support this capability in the IKE case, a YANG data model for IKEv2,
management of IPsec SAs in flow-based NSFs. In order to support this SPD and PAD configuration data, and for IKEv2 state data MUST be
capability in IKE case, the following interface requirements need to defined for the I2NSF NSF-Facing Interface.
be met:
o A YANG data model for IKEv2, SPD and PAD configuration data, and
for IKE state data.
o In scenarios where multiple Security Controllers are implicated,
SDN-based IPsec management services may require a mechanism to
discover which Security Controller is managing a specific NSF.
Moreover, an east-west interface [RFC7426] is required to exchange
IPsec-related information. For example, if two gateways need to
establish an IPsec SA and both are under the control of two
different controllers, then both Security Controllers need to
exchange information to properly configure their own NSFs. That
is, the may need to agree on whether IKEv2 authentication will be
based on raw public keys, pre-shared keys, etc. In case of using
pre-shared keys they will have to agree in the PSK.
5.2. IKE-less case: IPsec (no IKEv2) in the NSF.
In this case, the NSF does not deploy IKEv2 and, therefore, the
Security Controller has to perform the IKE security functions and
management of IPsec SAs by populating and managing the SPD and the
SAD.
+-----------------------------------------+
| IPsec Management Application | Client or
| I2NSF Client | App Gateway
+-----------------------------------------+
| Client Facing Interface
+-----------------------------------------+
Vendor| Application Support |
Facing<->|-----------------------------------------| Security
Interface| SPD, SAD and PAD Entries Distr. | Controller
+-----------------------------------------+
| NSF Facing Interface
+-----------------------------------------+
| I2NSF Agent | Network
|-----------------------------------------| Security
| IPsec (SPD,SAD) | Function (NSF)
|-----------------------------------------|
| Data Protection and Forwarding |
+-----------------------------------------+
Figure 2: IKE-less case: IPsec (no IKE) in the NSF 4.2. IKE-less case: IPsec (no IKEv2) in the NSF.
As shown in Figure 2, applications for flow protection run on the top In this case, the NSF does not deploy IKEv2 and, therefore, the I2NSF
of the Security Controller. When an administrator enforces flow- Controller has to perform the IKEv2 security functions and management
based protection policies through the Client Facing Interface, the of IPsec SAs by populating and managing the SPD and the SAD.
Security Controller translates these requirements into SPD and SAD
entries, which are installed in the NSF. PAD entries are not
required since there is no IKEv2 in the NSF.
5.2.1. Interface Requirements for IKE-less case +-----------------------------------------+
| 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
+-----------------------------------------+
In order to support the IKE-less case, the following requirements Figure 2: IKE-less case: IPsec (no IKEv2) in the NSF
need to be met:
o A YANG data model for configuration data for SPD and SAD and for As shown in Figure 2, when an I2NSF User enforces flow-based
state data for SAD. protection policies through the Consumer-Facing Interface, the I2NSF
Controller translates these requirements into SPD and SAD entries,
which are installed in the NSF. PAD entries are not required since
there is no IKEv2 in the NSF.
o In scenarios where multiple controllers are implicated, SDN-based In order to support the IKE-less case, a YANG data model for SPD and
IPsec management services may require a mechanism to discover SAD configuration data and SAD state data MUST be defined for the
which Security Controller is managing a specific NSF. Moreover, NSF-Facing Interface.
an east-west interface [RFC7426] is required to exchange IPsec-
related information. NOTE: A possible east-west protocol for this
IKE-less case could be IKEv2. However, this needs to be explore
since the IKEv2 peers would be the Security Controllers.
Specifically, the IKE-less case assumes that the SDN controller has Specifically, the IKE-less case assumes that the I2NSF Controller has
to perform some security functions that IKEv2 typically does, namely to perform some security functions that IKEv2 typically does, namely
(non-exhaustive): (non-exhaustive):
o IV generation. o IV generation.
o Prevent counter resets for the same key. o Prevent counter resets for the same key.
o Generation of pseudo-random cryptographic keys for the IPsec SAs. o Generation of pseudo-random cryptographic keys for the IPsec SAs.
o Rekey of the IPsec SAs based on notifications from the NSF (i.e.
expire).
o Generation of the IPsec SAs when required based on notifications o Generation of the IPsec SAs when required based on notifications
(i.e. sadb-acquire) from the NSF. (i.e. sadb-acquire) from the NSF.
o Rekey of the IPsec SAs based on notifications from the NSF (i.e.
expire).
o NAT Traversal discovery and management. o NAT Traversal discovery and management.
Additionally to these functions, another set of tasks must be Additionally to these functions, another set of tasks must be
performed by the Security Controller (non-exhaustive list): performed by the I2NSF Controller (non-exhaustive list):
o IPsec SA's SPI random generation. o IPsec SA's SPI random generation.
o Cryptographic algorithm/s selection. o Cryptographic algorithm/s selection.
o Usage of extended sequence numbers. o Usage of extended sequence numbers.
o Establishment of proper traffic selectors. o Establishment of proper traffic selectors.
5.3. IKE case vs IKE-less case 5. IKE case vs IKE-less case
In principle, IKE case is easier to deploy than IKE-less case because In principle, the IKE case is easier to deploy than the IKE-less case
current gateways typically have an IKEv2/IPsec implementation. because current flow-based NSFs (either hosts or gateways) have
Moreover hosts can install easily an IKE implementation. As access to IKEv2 implementations. While gateways typically deploy an
downside, the NSF needs more resources to hold IKEv2. Moreover, the IKEv2/IPsec implementation, hosts can easily install it. As
IKEv2 implementation needs to implement an internal interface so that downside, the NSF needs more resources to hold IKEv2 such as memory
the IKE configuration sent by the Security Controller can be enforced for the IKEv2 implementation, and computation, since each IPsec
in runtime. security association rekeying MAY involve a Diffie-Hellman exchange.
Alternatively, IKE-less case allows lighter NSFs (no IKEv2 Alternatively, IKE-less case benefits the deployment in resource-
implementation), which benefits the deployment in constrained NSFs. constrained NSFs. Moreover, IKEv2 does not need to be performed in
Moreover, IKEv2 does not need to be performed in gateway-to-gateway gateway-to-gateway and host-to-host scenarios under the same I2NSF
and host-to-host scenarios under the same Security Controller (see Controller (see Appendix G.1). On the contrary, the complexity of
Section 7.1). On the contrary, the overload of creating and managing creating and managing IPsec SAs is shifted to the I2NSF Controller
IPsec SAs is shifted to the Security Controller since IKEv2 is not in since IKEv2 is not in the NSF. As a consequence, this may result in
the NSF. As a consequence, this may result in a more complex a more complex implementation in the controller side in comparison
implementation in the controller side in comparison with IKE case. with IKE case. For example, the I2NSF Controller has to deal with
For example, the Security Controller have to deal with the latency the latency existing in the path between the I2NSF Controller and the
existing in the path between the Security Controller and the NSF in NSF, in order to solve tasks such as rekey, or creation and
order to solve tasks such as, rekey or creation and installation of installation of new IPsec SAs. However, this is not specific to this
new IPsec SAs. However, this is not specific to our contribution but contribution but a general aspect in any SDN-based network. In
a general aspect in any SDN-based network. In summary, this overload summary, this complexity MAY create some scalability and performance
may create some scalability and performance issues when the number of issues when the number of NSFs is high.
NSFs is high.
Nevertheless, literature around SDN-based network management using a Nevertheless, literature around SDN-based network management using a
centralized Security Controller is aware about scalability and centralized controller (like the I2NSF Controller) is aware about
performance issues and solutions have been already provided and scalability and performance issues and solutions have been already
discussed (e.g. hierarchical Security Controllers; having multiple provided and discussed (e.g. hierarchical controllers; having
replicated Security Controllers, dedicated high-speed management multiple replicated controllers, dedicated high-speed management
networks, etc). In the context of SDN-based IPsec management, one networks, etc). In the context of I2SNF-based IPsec management, one
way to reduce the latency and alleviate some performance issues can way to reduce the latency and alleviate some performance issues can
be the installation of the IPsec policies and IPsec SAs at the same be the installation of the IPsec policies and IPsec SAs at the same
time (proactive mode, as described in Section 7.1) instead of waiting time (proactive mode, as described in Appendix G.1) instead of
for notifications (e.g. a notification sadb-acquire when a new IPsec waiting for notifications (e.g. a notification sadb-acquire when a
SA is required) to proceed with the IPsec SA installations (reactive new IPsec SA is required) to proceed with the IPsec SA installation
mode). Another way to reduce the overhead and the potential (reactive mode). Another way to reduce the overhead and the
scalability and performance issues in the Security Controller is to potential scalability and performance issues in the I2NSF Controller
apply the IKE case described in this document, since the IPsec SAs is to apply the IKE case described in this document, since the IPsec
are managed between NSFs without the involvement of the Security SAs are managed between NSFs without the involvement of the I2NSF
Controller at all, except by the initial IKE configuration provided Controller at all, except by the initial configuration (i.e. IKEv2,
by the Security Controller. Other solutions, such as Controller-IKE PAD and SPD entries) provided by the I2NSF Controller. Other
solutions, such as Controller-IKE
[I-D.carrel-ipsecme-controller-ike], have proposed that NSFs provide [I-D.carrel-ipsecme-controller-ike], have proposed that NSFs provide
their DH public keys to the Security Controller, so that the Security their DH public keys to the I2NSF Controller, so that the I2NSF
Controller distributes all public keys to all peers. All peers can Controller distributes all public keys to all peers. All peers can
calculate a unique pairwise secret for each other peer and there is calculate a unique pairwise secret for each other peer and there is
no inter-NSF messages. A rekey mechanism is further described in no inter-NSF messages. A rekey mechanism is further described in
[I-D.carrel-ipsecme-controller-ike]. [I-D.carrel-ipsecme-controller-ike].
In terms of security, IKE case provides better security properties In terms of security, IKE case provides better security properties
than IKE-less case, as we discuss in section Section 9. The main than IKE-less case, as we discuss in section Section 8. The main
reason is that the NSFs are generating the session keys and not the reason is that the NSFs generate the session keys and not the I2NSF
Security Controller. Controller.
5.3.1. Rekeying process.
For IKE case, the rekeying process is carried out by IKEv2, following
the information defined in the SPD and SAD. Therefore, connections
will live unless something different is required by the administrator
or the Security Controller detects something wrong.
Traditionally, during a rekey process of the IPSec SA using IKE, a
bundle of inbound and outbound IPsec SAs is taken into account from
the perspective of one of the NSFs. For example, if the inbound
IPsec SA expires both the inbound and outbound IPsec SA are rekeyed
at the same time in that NSF. However, when IKE is not used, we have
followed a different approach to avoid any packet loss during rekey:
the Security Controller installs first the new inbound SAs in both
NSFs and then, the outbound IPsec SAs.
In other words, for the IKE-less case, the Security Controller needs
to take care of the rekeying process. When the IPsec SA is going to
expire (e.g. IPsec SA soft lifetime), it has to create a new IPsec
SA and remove the old one. This rekeying process starts when the
Security Controller receives a sadb-expire notification or it decides
so, based on lifetime state data obtained from the NSF.
To explain the rekeying process between two IPsec NSFs A and B, let
assume that SPIa1 identifies the inbound IPsec SA in A, and SPIb1 the
inbound IPsec SA in B. The rekeying process will take the following
steps:
1. The Security Controller chooses two random values as SPI for the
new inbound IPsec SAs: for example, SPIa2 for A and SPIb2 for B.
These numbers MUST NOT be in conflict with any IPsec SA in A or
B. Then, the Security Controller creates an inbound IPsec SA
with SPIa2 in A and another inbound IPsec SA in B with SPIb2. It
can send this information simultaneously to A and B.
2. Once the Security Controller receives confirmation from A and B,
the controller knows that the inbound IPsec A are correctly
installed. Then it proceeds to send in parallel to A and B, the
outbound IPsec SAs: it sends 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 Security Controller receives confirmation from A and B 5.1. Rekeying process
that the outbound IPsec SAs have been installed, the Security
Controller, in parallel, deletes the old IPsec SAs from A
(inbound SPIa1 and outbound SPIb1) and B (outbound SPIa1 and
inbound SPIb1).
If some of the operations in step 1 fail (e.g. the NSF A reports an Performing a rekey for IPsec SAs is an important operation during the
error when the Security Controller is trying to install a new inbound IPsec SAs management. With the YANG data models defined in this
IPsec SA) the Security Controller must perform rollback operations by document the I2NSF Controller can configure and conduct the rekey
removing any new inbound SA that had been successfully installed process. Depending on the case, the rekey process is different.
during step 1.
If step 1 is successful but some of the operations in step 2 fails For the IKE case, the rekeying process is carried out by IKEv2,
(e.g. the NSF A reports an error when the Security Controller is following the information defined in the SPD and SAD (i.e. based on
trying to install the new outbound IPsec SA), the Security Controller the IPsec SA lifetime established by the I2NSF Controller using the
must perform a rollback operation by deleting any new outbound SA YANG data model defined in this document). Therefore, IPsec
that had been successfully installed during step 2 and by deleting connections will live unless something different is required by the
the inbound SAs created in step 1. I2NSF User or the I2NSF Controller detects something wrong.
If the steps 1 an 2 are successful and the step 3 fails the Security For the IKE-less case, the I2NSF Controller MUST take care of the
Controller will avoid any rollback of the operations carried out in rekeying process. When the IPsec SA is going to expire (e.g. IPsec
step 1 and step 2 since new and valid IPsec SAs were created and are SA soft lifetime), it MUST create a new IPsec SA and it MAY remove
functional. The Security Controller may reattempt to remove the old the old one (if a IPsec SA lifetime has not been defined). This
inbound and outbound SAs in NSF A and NSF B several times until it rekeying process starts when the I2NSF Controller receives a sadb-
receives a success or it gives up. In the last case, the old IPsec expire notification or it decides so, based on lifetime state data
SAs will be removed when the hard lifetime is reached. obtained from the NSF. How the I2NSF Controller implements an
algorithm for the rekey process is out of the scope of this document.
Nevertheless, an example of how this rekey could be performed is in
Appendix G.2.
5.3.2. NSF state loss. 5.2. NSF state loss.
If one of the NSF restarts, it will lose the IPsec state (affected If one of the NSF restarts, it will lose the IPsec state (affected
NSF). By default, the Security Controller can assume that all the NSF). By default, the I2NSF Controller can assume that all the state
state has been lost and therefore it will have to send IKEv2, SPD and has been lost and therefore it will have to send IKEv2, SPD and PAD
PAD information to the NSF in the IKE case, and SPD and SAD information to the NSF in the IKE case, and SPD and SAD information
information in IKE-less case. in the IKE-less case.
In both cases, the Security Controller is aware of the affected NSF In both cases, the I2NSF Controller is aware of the affected NSF
(e.g. the NETCONF/TCP connection is broken with the affected NSF, the (e.g. the NETCONF/TCP connection is broken with the affected NSF, the
Security Controller is receiving sadb-bad-spi notification from a I2NSF Controller is receiving sadb-bad-spi notification from a
particular NSF, etc.). Moreover, the Security Controller has a particular NSF, etc.). Moreover, the I2NSF Controller keeps a list
register about all the NSFs that have IPsec SAs with the affected of NSFs that have IPsec SAs with the affected NSF. Therefore, it
NSF. Therefore, it knows the affected IPsec SAs. knows the affected IPsec SAs.
In IKE case, the Security Controller will configure the affected NSF In the IKE case, the I2NSF Controller will configure the affected NSF
with the new IKEv2, SPD and PAD information. It has also to send new with the new IKEv2, SPD and PAD information. It has also to send new
parameters (e.g. a new fresh PSK for authentication) to the NSFs parameters (e.g. a new fresh PSK for authentication) to the NSFs
which have IKEv2 SAs and IPsec SAs with the affected NSF. Finally, which have IKEv2 SAs and IPsec SAs with the affected NSF. Finally,
the Security Controller will instruct the affected NSF to start the the I2NSF Controller will instruct the affected NSF to start the
IKEv2 negotiation with the new configuration. IKEv2 negotiation with the new configuration.
In IKE-less case, if the Security Controller detects that a NSF has Alternatively, IKEv2 configuration MAY be made permanent between NSFs
lost the IPsec SAs it will delete the old IPsec SAs on the non-failed reboots without compromising security by means of the startup
nodes, established with the failed node (step 1). This prevents the configuration datastore in the NSF. This way, each time a NSF
non-failed nodes from leaking plaintext. If the affected node comes reboots it will use that configuration for each rebooting. It would
to live, the Security Controller will configure the new inbound IPsec imply avoiding to contact with the I2NSF Controller.
SAs between the affected node and all the nodes it was talking to
(step 2). After these inbound IPsec SAs have been established, the
Security Controller can configure the outbound IPsec SAs in parallel
(step 3).
Nevertheless other more optimized options can be considered (e.g. In the IKE-less case, the I2NSF Controller SHOULD delete the old
making the IKEv2 configuration permanent between reboots). IPsec SAs in the non-failed nodes established with the affected NSF.
Once the affected node restarts, the I2NSF Controller MUST take the
necessary actions to reestablish IPsec protected communication
between the failed node and those others having IPsec SAs with the
affected NSF. How the I2NSF Controller implements an algorithm for
managing a potential NSF state loss is out of the scope of this
document. Nevertheless, an example of how this could be performed is
described in Appendix G.3.
5.3.3. NAT Traversal 5.3. NAT Traversal
In the IKE case, IKEv2 already provides a mechanism to detect whether In the IKE case, IKEv2 already provides a mechanism to detect whether
some of the peers or both are located behind a NAT. If there is a some of the peers or both are located behind a NAT. If there is a
NAT network configured between two peers, it is required to activate NAT network configured between two peers, it is required to activate
the usage of UDP or TCP/TLS encapsulation for ESP packets ([RFC3948], the usage of UDP or TCP/TLS encapsulation for ESP packets ([RFC3948],
[RFC8229]). Note that the usage of IPsec transport mode when NAT is [RFC8229]). Note that the usage of IPsec transport mode when NAT is
required MUST NOT be used in this specification. required MUST NOT be used in this specification.
On the contrary, the IKE-less case does not have any protocol in the In the IKE case, IKEv2 already provides a mechanism to detect whether
NSFs to detect whether they are located behind a NAT or not. some of the peers or both are located behind a NAT. If there is a
However, the SDN paradigm generally assumes the Security Controller NAT network configured between two peers, it is required to activate
has a view of the network under its control. This view is built the usage of UDP or TCP/TLS encapsulation for ESP packets ([RFC3948],
either requesting information to the NSFs under its control, or [RFC8229]). Note that the usage of IPsec transport mode when NAT is
because these NSFs inform the Security Controller. Based on this required MUST NOT be used in this specification.
information, the Security Controller can guess if there is a NAT
configured between two hosts, and apply the required policies to both
NSFs besides activating the usage of UDP or TCP/TLS encapsulation of
ESP packets ([RFC3948], [RFC8229]).
For example, the Security Controller could directly request the NSF In the IKE-less case, the NSF does not have the assistance of the
for specific data such as networking configuration, NAT support, etc. IKEv2 implementation to detect if it is located behind a NAT. If the
Protocols such as NETCONF or SNMP can be used here. For example, RFC NSF does not have any other mechanism to detect this situation, the
7317 [RFC7317] provides a YANG data model for system management or I2NSF Controller SHOULD implement a mechanism to detect that case.
[RFC8512] a data model for NAT management. The Security Controller The SDN paradigm generally assumes the I2NSF Controller has a view of
can use this NETCONF module with a NSF to collect NAT information or the network under its control. This view is built either requesting
even configure a NAT network. In any case, if this NETCONF module is information to the NSFs under its control, or because these NSFs
not available in the NSF and the Security Controller does not have a inform the I2NSF Controller. Based on this information, the I2NSF
mechanism to know whether a host is behind a NAT or not, then the IKE Controller MAY guess if there is a NAT configured between two hosts,
case should be the right choice and not the IKE-less case. and apply the required policies to both NSFs besides activating the
usage of UDP or TCP/TLS encapsulation of ESP packets ([RFC3948],
[RFC8229]). The interface for discovering if the NSF is behind a NAT
is out of scope of this document.
5.3.4. NSF Discovery If the I2NSF Controller does not have any mechanism to know whether a
host is behind a NAT or not, then the IKE-case MUST be used and not
the IKE-less case.
5.4. NSF registration and discovery
NSF registration refers to the process of facilitating the I2NSF
Controller information about a valid NSF such as certificate, IP
address, etc. This information is incorporated to a list of NSFs
under its control.
The assumption in this document is that, for both cases, before a NSF The assumption in this document is that, for both cases, before a NSF
can operate in this system, it MUST be registered in the Security can operate in this system, it MUST be registered in the I2NSF
Controller. In this way, when the NSF comes to live and establishes Controller. In this way, when the NSF starts and establishes a
a connection to the Security Controller, it knows that the NSF is connection to the I2NSF Controller, it knows that the NSF is valid
valid for joining the system. for joining the system.
Either during this registration process or when the NSF connects with Either during this registration process or when the NSF connects with
the Security Controller, the Security Controller MUST discover the I2NSF Controller, the I2NSF Controller MUST discover certain
certain capabilities of this NSF, such as what is the cryptographic capabilities of this NSF, such as what is the cryptographic suite
suite supported, authentication method, the support of the IKE case supported, authentication method, the support of the IKE case and/or
or the IKE-less case, etc. This discovery process is out of the the IKE-less case, etc.
scope of this document.
The registration and discovery processes are out of the scope of this
document.
6. YANG configuration data models 6. YANG configuration data models
In order to support the IKE and IKE-less cases we have modeled the In order to support the IKE and IKE-less cases we have modeled the
different parameters and values that must be configured to manage different parameters and values that must be configured to manage
IPsec SAs. Specifically, IKE requires modeling IKEv2, SPD and PAD, IPsec SAs. Specifically, the IKE case requires modeling IKEv2
while IKE-less case requires configuration models for the SPD and configuration parameters, SPD and PAD, while the IKE-less case
SAD. We have defined three models: ietf-ipsec-common (Appendix A), requires configuration models for the SPD and SAD. We have defined
ietf-ipsec-ike (Appendix B, IKE case), ietf-ipsec-ikeless three models: ietf-ipsec-common (Appendix A), ietf-ipsec-ike
(Appendix C, IKE-less case). Since the model ietf-ipsec-common has (Appendix B, IKE case), ietf-ipsec-ikeless (Appendix C, IKE-less
only typedef and groupings common to the other modules, we only show case). Since the model ietf-ipsec-common has only typedef and
a simplified view of the ietf-ipsec-ike and ietf-ipsec-ikeless groupings common to the other modules, we only show a simplified view
models. of the ietf-ipsec-ike and ietf-ipsec-ikeless models.
6.1. IKE case model 6.1. IKE case model
The model related to IKEv2 has been extracted from reading IKEv2 The model related to IKEv2 has been extracted from reading IKEv2
standard in [RFC7296], and observing some open source standard in [RFC7296], and observing some open source
implementations, such as Strongswan [strongswan] or Libreswan implementations, such as Strongswan [strongswan] or Libreswan
[libreswan]. [libreswan].
The definition of the PAD model has been extracted from the The definition of the PAD model has been extracted from the
specification in section 4.4.3 in [RFC4301] (NOTE: We have observed specification in section 4.4.3 in [RFC4301] (NOTE: We have observed
skipping to change at page 17, line 24 skipping to change at page 16, line 30
+--ro half-open-cookies? uint64 +--ro half-open-cookies? uint64
Appendix D shows an example of IKE case configuration for a NSF, in Appendix D shows an example of IKE case configuration for a NSF, in
tunnel mode (gateway-to-gateway), with NSFs authentication based on tunnel mode (gateway-to-gateway), with NSFs authentication based on
X.509 certificates. X.509 certificates.
6.2. IKE-less case model 6.2. IKE-less case model
For this case, the definition of the SPD model has been mainly For this case, the definition of the SPD model has been mainly
extracted from the specification in section 4.4.1 and Appendix D in extracted from the specification in section 4.4.1 and Appendix D in
[RFC4301], though with some simplications. For example, each IPsec [RFC4301], though with some changes, namely:
policy (spd-entry) contains one traffic selector, instead a list of
them. The reason is that we have observed real kernel
implementations only admit a traffic selector per IPsec policy.
The definition of the SAD model has been extracted from the o Each IPsec policy (spd-entry) contains one traffic selector,
specification in section 4.4.2 in [RFC4301]. Note that this model instead of a list of them. The reason is that we have observed
not only allows to associate an IPsec SA with its corresponding actual kernel implementations only admit a single traffic selector
policy through the specific traffic selector but also an identifier per IPsec policy.
(reqid).
o Each IPsec policy contains a identifier (reqid) to relate the
policy with the IPsec SA. This is common in Linux-based systems.
o Each IPsec policy has only one name and not a list of names.
o Combined algorithms has been removed because encryption algorithms
MAY include authenticated encryption with associated data (AEAD).
o Tunnel information has been extended with information about DSCP
mapping and ECN bit. The reason is that we have observed real
kernel implementations admit the configurations of these values.
The definition of the SAD model has been mainly extracted from the
specification in section 4.4.2 in [RFC4301] though with some changes,
namely:
o Each IPsec SA (sad-entry) contains one traffic selector, instead
of a list of them. The reason is that we have observed actual
kernel implementations only admit a single traffic selector per
IPsec SA.
o Each IPsec SA contains a identifier (reqid) to relate the policy
with the IPsec Policy. The reason is that we have observed real
kernel implementations allow to include this value.
o Each IPsec SA has also a name in the same way as IPsec policies.
o Combined algorithm has been removed because encryption algorithm
MAY include authenticated encryption with associated data (AEAD).
o Tunnel information has been extended with information about
Differentiated Services Code Point (DSCP) mapping and Explicit
Congestion Notificsation (ECN) bit. The reason is that we have
observed actual kernel implementations admit the configurations of
these values.
o Lifetime of the IPsec SAs also include idle time and number of IP
packets as threshold to trigger the lifetime. The reason is that
we have observed actual kernel implementations allow to set these
types of lifetimes.
o Information to configure the type of encapsulation (encapsulation-
type) for IPsec ESP packets in UDP ([RFC3948]), TCP ([RFC8229]) or
TLS ([RFC8229]) has been included.
The notifications model has been defined using as reference the The notifications model has been defined using as reference the
PF_KEYv2 standard in [RFC2367]. PF_KEYv2 standard in [RFC2367].
module: ietf-ipsec-ikeless module: ietf-ipsec-ikeless
+--rw ipsec-ikeless +--rw ipsec-ikeless
+--rw spd +--rw spd
| +--rw spd-entry* [name] | +--rw spd-entry* [name]
| +--rw name string | +--rw name string
| +--rw direction? ic:ipsec-traffic-direction | +--rw direction? ic:ipsec-traffic-direction
skipping to change at page 20, line 36 skipping to change at page 20, line 37
| +--ro ipsec-sa-name string | +--ro ipsec-sa-name string
+---n sadb-bad-spi +---n sadb-bad-spi
+--ro spi uint32 +--ro spi uint32
Appendix E shows an example of IKE-less case configuration for a NSF, Appendix E shows an example of IKE-less case configuration for a NSF,
in transport mode (host-to-host), with NSFs authentication based on in transport mode (host-to-host), with NSFs authentication based on
shared secrets. For the IKE-less case, Appendix F shows examples of shared secrets. For the IKE-less case, Appendix F shows examples of
IPsec SA expire, acquire, sequence number overflow and bad SPI IPsec SA expire, acquire, sequence number overflow and bad SPI
notifications. notifications.
7. Use cases examples 7. IANA Considerations
This section explains how different traditional configurations, that
is, host-to-host and gateway-to-gateway, are deployed using this SDN-
based IPsec management service. In turn, these configurations will
be typical in modern networks where, for example, virtualization will
be key.
7.1. Host-to-host or gateway-to-gateway under the same Security
Controller
+----------------------------------------+
| Security Controller |
| |
(1)| +--------------+ (2)+--------------+ |
Flow-based ------> |Translate into|--->| South. Prot. | |
Security. Pol. | |IPsec Policies| | | |
| +--------------+ +--------------+ |
| | | |
| | | |
+--------------------------|-----|-------+
| |
| (3) |
|-------------------------+ +---|
V V
+----------------------+ +----------------------+
| NSF A |<=======>| NSF B |
|IKEv2/IPsec(SPD/PAD) | |IKEv2/IPsec(SPD/PAD) |
+----------------------+ (4) +----------------------+
Figure 3: Host-to-host / gateway-to-gateway single Security
Controller for the IKE case.
Figure 3 describes the IKE case:
1. The administrator defines general flow-based security policies.
The Security Controller looks for the NSFs involved (NSF A and
NSF B).
2. The Security Controller generates IKEv2 credentials for them and
translates the policies into SPD and PAD entries.
3. The Security Controller inserts an IKEv2 configuration that
includes the SPD and PAD entries in both NSF A and NSF B. If
some of operations with NSF A and NSF B fail the Security
Controller will stop the process and perform a rollback operation
by deleting any IKEv2, SPD and PAD configuration that had been
successfully installed in NSF A or B.
4. If the previous step is successful, the flow is protected by
means of the IPsec SA established with IKEv2.
+----------------------------------------+
| (1) Security Controller |
Flow-based | |
Security -----------| |
Policy | V |
| +---------------+ (2)+-------------+ |
| |Translate into |--->| South. Prot.| |
| |IPsec policies | | | |
| +---------------+ +-------------+ |
| | | |
| | | |
+-------------------------| --- |--------+
| |
| (3) |
|----------------------+ +--|
V V
+------------------+ +------------------+
| NSF A |<=====>| NSF B |
|IPsec(SPD/SAD) | 4) |IPsec(SPD/SAD) |
+------------------+ +------------------+
Figure 4: Host-to-host / gateway-to-gateway single Security
Controller for IKE-less case.
In the IKE-less case, flow-based security policies defined by the
administrator are translated into IPsec SPD entries and inserted into
the corresponding NSFs. Besides, fresh SAD entries will be also
generated by the Security Controller and enforced in the NSFs. In
this case, the Security Controller does not run any IKEv2
implementation (neither the NSFs), and it provides the cryptographic
material for the IPsec SAs. These keys will be also distributed
securely through the southbound interface. Note that this is
possible because both NSFs are managed by the same Security
Controller.
Figure 4 describes the IKE-less case, when a data packet needs to be
protected in the path between the NSF A and NSF B:
1. The administrator establishes the flow-based security policies,
and the Security Controller looks for the involved NSFs.
2. The Security Controller translates the flow-based security
policies into IPsec SPD and SAD entries.
3. The Security Controller inserts these entries in both NSF A and
NSF B IPsec databases (SPD and SAD). The following text
describes how this happens between two NSFs A and B:
* The Security Controller chooses two random values as SPIs: for
example, SPIa1 for NSF A and SPIb1 for NSF B. These numbers
MUST NOT be in conflict with any IPsec SA in NSF A or NSF B.
It also generates fresh cryptographic material for the new
inbound/outbound IPsec SAs and their parameters and send
simultaneously the new inbound IPsec SA with SPIa1 and new
outbound IPsec SAs with SPIb1 to NSF A; and the new inbound
IPsec SA with SPIb1 and new outbound IPsec SAs with SPIa1 to
B, together with the corresponding IPsec policies.
* Once the Security Controller receives confirmation from NSF A
and NSF B, the controller knows that the IPsec SAs are
correctly installed and ready.
If some of the operations described above fails (e.g. the NSF A
reports an error when the Security Controller is trying to
install the SPD entry, the new inbound and outbound IPsec SAs)
the Security Controller must perform rollback operations by
deleting any new inbound or outbound SA and SPD entry that had
been successfully installed in any of the NSFs (e.g NSF B) and
stop the process (NOTE: the Security Controller may retry several
times before giving up). Other alternative to this operation is:
the Security Controller sends first the IPsec policies and new
inbound IPsec SAs to A and B and once it obtains a successful
confirmation of these operations from NSF A and NSF B, it
proceeds with installing to the new outbound IPsec SAs. However,
this may increase the latency to complete the process. As an
advantage, no traffic is sent over the network until the IPsec
SAs are completely operative. In any case other alternatives may
be possible. Finally, it is worth mentioning that the Security
Controller associates a lifetime to the new IPsec SAs. When this
lifetime expires, the NSF will send a sadb-expire notification to
the Security Controller in order to start the rekeying process.
4. The flow is protected with the IPsec SA established by the
Security Controller.
Instead of installing IPsec policies in the SPD and IPsec SAs in the
SAD in step 3 (proactive mode), it is also possible that the Security
Controller only installs the SPD entries in step 3 (reactive mode).
In such a case, when a data packet requires to be protected with
IPsec, the NSF that saw first the data packet will send a sadb-
acquire notification that informs the Security Controller that needs
SAD entries with the IPsec SAs to process the data packet. In such
as reactive mode, since IPsec policies are already installed in the
SPD, the Security Controller installs first the new IPsec SAs in NSF
A and B with the operations described in step 3 but without sending
any IPsec policies. Again, if some of the operations installing the
new inbound/outbound IPsec SAs fail, the Security Controller stops
the process and performs a rollback operation by deleting any new
inbound/outbound SAs that had been successfully installed.
Both NSFs could be two hosts that exchange traffic and require to
establish an end-to-end security association to protect their
communications (host-to-host) or two gateways (gateway-to-gateway),
for example, within an enterprise that needs to protect the traffic
between the networks of two branch offices.
Applicability of these configurations appear in current and new
networking scenarios. For example, SD-WAN technologies are providing
dynamic and on-demand VPN connections between branch offices, or
between branches and SaaS cloud services. Beside, IaaS services
providing virtualization environments are deployments solutions based
on IPsec to provide secure channels between virtual instances (host-
to-host) and providing VPN solutions for virtualized networks
(gateway-to-gateway).
In general (for IKE and IKE-less cases), this system has various
advantages:
1. It allows to create IPsec SAs among two NSFs, based only on the
application of general Flow-based Security Policies at the
application layer. Thus, administrators can manage all security
associations in a centralized point with an abstracted view of
the network.
2. Any NSF deployed in the system does not need manual
configuration, therefore allowing its deployment in an automated
manner.
7.2. Host-to-host or gateway-to-gateway under different Security
Controllers
It is also possible that two NSFs (i.e. NSF A and NSF B) are under
the control of two different Security Controllers. This may happen,
for example, when two organizations, namely Enterprise A and
Enterprise B, have their headquarters interconnected through a WAN
connection and they both have deployed a SDN-based architecture to
provide connectivity to all their clients.
+-------------+ +-------------+
| | | |
Flow-based| Security |<=========>| Security <--Flow-based
Sec. Pol.--> Controller | (3) | Controller | Sec. Pol.
(1) | A | | B | (2)
+-------------+ +-------------+
| |
| (4) (4) |
V V
+--------------------+ +--------------------+
| NSF A |<=======>| NSF B |
|IKEv2/IPsec(SPD/PAD)| |IKEv2/IPsec(SPD/PAD)|
+--------------------+ (5) +--------------------+
Figure 5: Different Security Controllers in the IKE case.
Figure 5 describes IKE case when two Security Controllers are
involved in the process.
1. The A's administrator establishes general Flow-based Security
Policies in Security Controller A.
2. The B's administrator establishes general Flow-based Security
Policies in Security Controller B.
3. The Security Controller A realizes that protection is required
between the NSF A and NSF B, but the NSF B is under the control
of another Security Controller (Security Controller B), so it
starts negotiations with the other controller to agree on the
IPsec SPD policies and IKEv2 credentials for their respective
NSFs. NOTE: This may require extensions in the East/West
interface.
4. Then, both Security Controllers enforce the IKEv2 credentials,
related parameters and the SPD and PAD entries in their
respective NSFs.
5. The flow is protected with the IPsec SAs established with IKEv2
between both NSFs.
+--------------+ +--------------+
| | | |
Flow-based. ---> | | <---Flow-based
Prot. | Security |<===========>| Security |Sec.
Pol.(1)| Controller | (3) | Controller |Pol. (2)
| A | | B |
+--------------+ +--------------+
| |
| (4) (4) |
V V
+--------------+ (5) +--------------+
| NSF A |<==============>| NSF B |
|IPsec(SPD/SAD)| |IPsec(SPD/SAD)|
+--------------+ +--------------+
Figure 6: Different Security Controllers in the IKE-less case.
Figure 6 describes IKE-less case when two Security Controllers are
involved in the process.
1. The A's administrator establishes general Flow Protection
Policies in Security Controller A.
2. The B's administrator establishes general Flow Protection
Policies in Security Controller B.
3. The Security Controller A realizes that the flow between NSF B
and NSF B MUST be protected. Nevertheless, it notices that NSF B
is under the control of another Security Controller B, so it
starts negotiations with the other controller to agree on the
IPsec SPD and SAD entries that define the IPsec SAs. NOTE: It
would worth evaluating IKEv2 as the protocol for the East/West
interface in this case.
4. Once the Security Controllers have agreed on the key material and
the details of the IPsec SAs, they both enforce this information
into their respective NSFs.
5. The flow is protected with the IPsec SAs established by both
Security Controllers in their respective NSFs.
8. IANA Considerations
This document registers three URIs in the "ns" subregistry of the This document registers three URIs in the "ns" subregistry of the
IETF XML Registry [RFC3688]. Following the format in [RFC3688], the IETF XML Registry [RFC3688]. Following the format in [RFC3688], the
following registrations are requested: following registrations are requested:
URI: urn:ietf:params:xml:ns:yang:ietf-ipsec-common URI: urn:ietf:params:xml:ns:yang:ietf-ipsec-common
Registrant Contact: The I2NSF WG of the IETF. Registrant Contact: The I2NSF WG of the IETF.
XML: N/A, the requested URI is an XML namespace. XML: N/A, the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-ipsec-ike URI: urn:ietf:params:xml:ns:yang:ietf-ipsec-ike
Registrant Contact: The I2NSF WG of the IETF. Registrant Contact: The I2NSF WG of the IETF.
XML: N/A, the requested URI is an XML namespace. XML: N/A, the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless URI: urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless
Registrant Contact: The I2NSF WG of the IETF. Registrant Contact: The I2NSF WG of the IETF.
XML: N/A, the requested URI is an XML namespace. XML: N/A, the requested URI is an XML namespace.
This document registers three YANG modules in the "YANG Module Names" This document registers three YANG modules in the "YANG Module Names"
registry [RFC6020]. Following the format in [RFC6020], the following registry [RFC6020]. Following the format in [RFC6020], the following
registrations are requested: registrations are requested:
Name: ietf-ipsec-common Name: ietf-ipsec-common
Namespace: urn:ietf:params:xml:ns:yang:ietf-ipsec-common Namespace: urn:ietf:params:xml:ns:yang:ietf-ipsec-common
Prefix: ic Prefix: ic
Reference: RFC XXXX Reference: RFC XXXX
Name: ietf-ipsec-ike Name: ietf-ipsec-ike
Namespace: urn:ietf:params:xml:ns:yang:ietf-ipsec-ike Namespace: urn:ietf:params:xml:ns:yang:ietf-ipsec-ike
Prefix: ike Prefix: ike
Reference: RFC XXXX Reference: RFC XXXX
Name: ietf-ipsec-ikeless Name: ietf-ipsec-ikeless
Namespace: urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless Namespace: urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless
Prefix: ikeless Prefix: ikeless
Reference: RFC XXXX Reference: RFC XXXX
9. Security Considerations 8. Security Considerations
First of all, this document shares all the security issues of SDN First of all, this document shares all the security issues of SDN
that are specified in the "Security Considerations" section of that are specified in the "Security Considerations" section of
[ITU-T.Y.3300] and [RFC8192]. [ITU-T.Y.3300] and [RFC7426].
On the one hand, it is important to note that there MUST exit a On the one hand, it is important to note that there MUST exist a
security association between the Security Controller and the NSFs to security association between the I2NSF Controller and the NSFs to
protect of the critical information (cryptographic keys, protect the critical information (cryptographic keys, configuration
configuration parameter, etc...) exchanged between these entities. parameter, etc.) exchanged between these entities.
For example, when NETCONF is used as southbound protocol between the
Security Controller and the NSFs, it is defined that TLS or SSH
security association MUST be established between both entities.
On the other hand, if encryption is mandatory for all traffic of a On the other hand, if encryption is mandatory for all traffic of a
NSF, its default policy MUST be to drop (DISCARD) packets to prevent NSF, its default policy MUST be to drop (DISCARD) packets to prevent
cleartext packet leaks. This default policy MUST be in the startup cleartext packet leaks. This default policy MUST be pre-configured
configuration datastore in the NSF before the NSF contacts with the in the startup configuration datastore in the NSF before the NSF
Security Controller. Moreover, the startup configuration datastore contacts the I2NSF Controller. Moreover, the startup configuration
MUST be pre-configured with the required ALLOW policies that allow to datastore MUST be also pre-configured with the required ALLOW
communicate the NSF with the Security Controller once the NSF is policies that allow to communicate the NSF with the I2NSF Controller
deployed. This pre-configuration step is not carried out by the once the NSF is deployed. This pre-configuration step is not carried
Security Controller but by some other entity before the NSF out by the I2NSF Controller but by some other entity before the NSF
deployment. In this manner, when the NSF starts/reboots, it will deployment. In this manner, when the NSF starts/reboots, it will
always apply first the configuration in the startup configuration always first apply the configuration in the startup configuration
before contacting the Security Controller. before contacting the I2NSF Controller.
Finally, we have divided this section in two parts in order to Finally, we have divided this section in two parts in order to
analyze different security considerations for both cases: NSF with analyze different security considerations for both cases: NSF with
IKEv2 (IKE case) and NSF without IKEv2 (IKE-less case). In general, IKEv2 (IKE case) and NSF without IKEv2 (IKE-less case). In general,
the Security Controller, as typically in the SDN paradigm, is a the I2NSF Controller, as typically in the SDN paradigm, is a target
target for different type of attacks. Thus, the Security Controller for different type of attacks [SDNSecServ] and [SDNSecurity]. Thus,
is a key entity in the infrastructure and MUST be protected the I2NSF Controller is a key entity in the infrastructure and MUST
accordingly. In particular, the Security Controller will handle be protected accordingly. In particular, the I2NSF Controller will
cryptographic material so that the attacker may try to access this handle cryptographic material so that the attacker may try to access
information. Although we can assume this attack will not likely to this information. Although we can assume this attack will not likely
happen due to the assumed security measurements to protect the to happen due to the assumed security measurements to protect the
Security Controller, it deserves some analysis in the hypothetical I2NSF Controller, it deserves some analysis in the hypothetical case
case the attack occurs. The impact is different depending on the IKE the attack occurs. The impact is different depending on the IKE case
case or IKE-less case. or IKE-less case.
9.1. IKE case 8.1. IKE case
In IKE case, the Security Controller sends IKE credentials (PSK, In the IKE case, the I2NSF Controller sends IKEv2 credentials (PSK,
public/private keys, certificates, etc.) to the NSFs using the public/private keys, certificates, etc.) to the NSFs using the
security association between Security Controller and NSFs. The security association between I2NSF Controller and NSFs. The I2NSF
general recommendation is that the Security Controller MUST NOT store Controller MUST NOT store the IKEv2 credentials after distributing
the IKE credentials after distributing them. Moreover, the NSFs MUST them. Moreover, the NSFs MUST NOT allow the reading of these values
NOT allow the reading of these values once they have been applied by once they have been applied by the I2NSF Controller (i.e. write only
the Security Controller (i.e. write only operations). One option is operations). One option is to always return the same value (i.e. all
to return always the same value (i.e. all 0s) if a read operation is 0s) if a read operation is carried out.
carried out. If the attacker has access to the Security 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. If PSK authentication is used
in IKEv2, the Security Controller MUST remove the PSK immediately
after generating and distributing it. Moreover, the PSK MUST have a
proper length (e.g. minimum 128 bit length) and strength. When
public/private keys are used, the Security Controller MAY generate
both public key and private key. In such a case, the Security
Controller MUST remove the associated private key immediately after
distributing them to the NSFs. Alternatively, the NSF could generate
the private key and export only the public key to the Security
Controller. If certificates are used, the NSF MAY generate the
private key and exports the public key for certification to the
Security Controller. How the NSF generates these cryptographic
material (public key/private keys) and export the public key, or it
is instructed to do so, it is out of the scope of this document.
9.2. IKE-less case 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.
In the IKE-less case, the Security Controller sends the IPsec SA o IKEv2 configurations should adhere to the recommendations in
[RFC8247].
o If PSK authentication is used in IKEv2, the I2NSF Controller MUST
remove the PSK immediately after generating and distributing it.
o 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 could generate the private key and export only the public
key to the I2NSF Controller.
o If certificates are used, the NSF MAY generate the private key and
exports 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 it is out of scope of
this document.
8.2. IKE-less case
In the IKE-less case, the I2NSF Controller sends the IPsec SA
information to the NSF's SAD that includes the private session keys information to the NSF's SAD that includes the private session keys
required for integrity and encryption. The general recommendation is required for integrity and encryption. The I2NSF Controller MUST NOT
that it MUST NOT store the keys after distributing them. Moreover, store the keys after distributing them. Moreover, the NSFs receiving
the NSFs receiving private key material MUST NOT allow the reading of private key material MUST NOT allow the reading of these values by
these values by any other entity (including the Security Controller any other entity (including the I2NSF Controller itself) once they
itself) once they have been applied (i.e. write only operations) into have been applied (i.e. write only operations) into the NSFs.
the NSFs. Nevertheless, if the attacker has access to the Security Nevertheless, if the attacker has access to the I2NSF Controller
Controller during the period of time that key material is generated, during the period of time that key material is generated, it may
it may obtain these values. In other words, the attacker might be obtain these values. In other words, the attacker might be able to
able to observe the IPsec traffic and decrypt, or even modify and re- observe the IPsec traffic and decrypt, or even modify and re-encrypt,
encrypt the traffic between peers. the traffic between peers.
9.3. YANG modules 8.3. YANG modules
The YANG module specified in this document defines a schema for data The YANG module specified in this document defines a schema for data
that is designed to be accessed via network management protocols such that is designed to be accessed via network management protocols such
as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer
is the secure transport layer, and the mandatory-to-implement secure is the secure transport layer, and the mandatory-to-implement secure
transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer
is HTTPS, and the mandatory-to-implement secure transport is TLS is HTTPS, and the mandatory-to-implement secure transport is TLS
[RFC8446]. [RFC8446].
The Network Configuration Access Control Model (NACM) [RFC8341] The Network Configuration Access Control Model (NACM) [RFC8341]
skipping to change at page 30, line 8 skipping to change at page 24, line 14
The YANG modules describe configuration data for the IKE case (ietf- The YANG modules describe configuration data for the IKE case (ietf-
ipsec-ike) and IKE-less case (ietf-ipsec-ikeless). There is a common ipsec-ike) and IKE-less case (ietf-ipsec-ikeless). There is a common
module (ietf-ipsec-common) used in both cases. module (ietf-ipsec-common) used in both cases.
For the IKE case (ietf-ipsec-ike): For the IKE case (ietf-ipsec-ike):
/ipsec-ike: The entire container in this module is sensitive to /ipsec-ike: The entire container in this module is sensitive to
write operations. An attacker may add/modify the credentials write operations. An attacker may add/modify the credentials
to be used for the authentication (e.g. to impersonate a NSF), to be used for the authentication (e.g. to impersonate a NSF),
the trust root (e.g. changing the trusted CA certificates), the trust root (e.g. changing the trusted CA certificates), the
the cryptographic algorithms (allowing a downgrading attack), cryptographic algorithms (allowing a downgrading attack), the
the IPsec policies (e.g. by allowing leaking of data traffic by IPsec policies (e.g. by allowing leaking of data traffic by
changing to a allow policy), and in general changing the IKE SA changing to a allow policy), and in general changing the IKE SA
conditions and credentials between any NSF. conditions and credentials between any NSF.
For the IKE-less case (ietf-ipsec-ikeless): For the IKE-less case (ietf-ipsec-ikeless):
/ipsec-ikeless: The entire container in this module is /ipsec-ikeless: The entire container in this module is
sensitive to write operations. An attacker may add/modify/ sensitive to write operations. An attacker may add/modify/
delete any IPsec policies (e.g. by allowing leaking of data delete any IPsec policies (e.g. by allowing leaking of data
traffic by changing to a allow policy) in the /ipsec-ikeless/ traffic by changing to a allow policy) in the /ipsec-ikeless/
spd container, and add/modify/delete any IPsec SAs between two spd container, and add/modify/delete any IPsec SAs between two
skipping to change at page 31, line 5 skipping to change at page 25, line 7
For the IKE-less case (ietf-ipsec-ikeless): For the IKE-less case (ietf-ipsec-ikeless):
/ipsec-ikeless/sad/ipsec-sa-config/esp-sa: This container /ipsec-ikeless/sad/ipsec-sa-config/esp-sa: This container
includes symmetric keys for the IPsec SAs. For example, includes symmetric keys for the IPsec SAs. For example,
encryption/key contains a ESP encryption key value and encryption/key contains a ESP encryption key value and
encryption/iv contains a initialization vector value. encryption/iv contains a initialization vector value.
Similarly, integrity/key has ESP integrity key value. Those Similarly, integrity/key has ESP integrity key value. Those
values must not be read by anyone and are protected by the NACM values must not be read by anyone and are protected by the NACM
extension "default-deny-all" in this document. extension "default-deny-all" in this document.
10. Acknowledgements 9. Acknowledgements
Authors want to thank Paul Wouters, Valery Smyslov, Sowmini Varadhan, Authors want to thank Paul Wouters, Valery Smyslov, Sowmini Varadhan,
David Carrel, Yoav Nir, Tero Kivinen, Martin Bjorklund, Graham David Carrel, Yoav Nir, Tero Kivinen, Martin Bjorklund, Graham
Bartlett, Sandeep Kampati, Linda Dunbar, Carlos J. Bernardos, Bartlett, Sandeep Kampati, Linda Dunbar, Carlos J. Bernardos,
Alejandro Perez-Mendez, Alejandro Abad-Carrascosa, Ignacio Martinez Alejandro Perez-Mendez, Alejandro Abad-Carrascosa, Ignacio Martinez,
and Ruben Ricart for their valuable comments. Ruben Ricart and Roman Danyliw for their valuable comments.
11. References 10. References
11.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>. December 2005, <https://www.rfc-editor.org/info/rfc4301>.
skipping to change at page 31, line 49 skipping to change at page 26, line 5
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2 Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/info/rfc7296>. 2014, <https://www.rfc-editor.org/info/rfc7296>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>. <https://www.rfc-editor.org/info/rfc8040>.
[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>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341, Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018, DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>. <https://www.rfc-editor.org/info/rfc8341>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
11.2. Informative References 10.2. Informative References
[I-D.carrel-ipsecme-controller-ike] [I-D.carrel-ipsecme-controller-ike]
Carrel, D. and B. Weiss, "IPsec Key Exchange using a Carrel, D. and B. Weiss, "IPsec Key Exchange using a
Controller", draft-carrel-ipsecme-controller-ike-01 (work Controller", draft-carrel-ipsecme-controller-ike-01 (work
in progress), March 2019. in progress), March 2019.
[I-D.ietf-i2nsf-terminology]
Hares, S., Strassner, J., Lopez, D., Xia, L., and H.
Birkholz, "Interface to Network Security Functions (I2NSF)
Terminology", draft-ietf-i2nsf-terminology-08 (work in
progress), July 2019.
[I-D.tran-ipsecme-yang] [I-D.tran-ipsecme-yang]
Tran, K., Wang, H., Nagaraj, V., and X. Chen, "Yang Data Tran, K., Wang, H., Nagaraj, V., and X. Chen, "Yang Data
Model for Internet Protocol Security (IPsec)", draft-tran- Model for Internet Protocol Security (IPsec)", draft-tran-
ipsecme-yang-01 (work in progress), June 2015. ipsecme-yang-01 (work in progress), June 2015.
[ITU-T.X.1252]
"Baseline Identity Management Terms and Definitions",
April 2010.
[ITU-T.X.800]
"Security Architecture for Open Systems Interconnection
for CCITT Applications", March 1991.
[ITU-T.Y.3300] [ITU-T.Y.3300]
"Recommendation ITU-T Y.3300", June 2014. "Recommendation ITU-T Y.3300", June 2014.
[libreswan] [libreswan]
The Libreswan Project, "Libreswan VPN software", August The Libreswan Project, "Libreswan VPN software", August
2019. 2019.
[netconf-vpn] [netconf-vpn]
Stefan Wallin, "Tutorial: NETCONF and YANG", January 2014. Stefan Wallin, "Tutorial: NETCONF and YANG", January 2014.
skipping to change at page 33, line 24 skipping to change at page 27, line 19
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets", Stenberg, "UDP Encapsulation of IPsec ESP Packets",
RFC 3948, DOI 10.17487/RFC3948, January 2005, RFC 3948, DOI 10.17487/RFC3948, January 2005,
<https://www.rfc-editor.org/info/rfc3948>. <https://www.rfc-editor.org/info/rfc3948>.
[RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and [RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and
Internet Key Exchange (IKE) Document Roadmap", RFC 6071, Internet Key Exchange (IKE) Document Roadmap", RFC 6071,
DOI 10.17487/RFC6071, February 2011, DOI 10.17487/RFC6071, February 2011,
<https://www.rfc-editor.org/info/rfc6071>. <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 [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined
Networking: A Perspective from within a Service Provider Networking: A Perspective from within a Service Provider
Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014,
<https://www.rfc-editor.org/info/rfc7149>. <https://www.rfc-editor.org/info/rfc7149>.
[RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for
System Management", RFC 7317, DOI 10.17487/RFC7317, August
2014, <https://www.rfc-editor.org/info/rfc7317>.
[RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S.,
Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software-
Defined Networking (SDN): Layers and Architecture Defined Networking (SDN): Layers and Architecture
Terminology", RFC 7426, DOI 10.17487/RFC7426, January Terminology", RFC 7426, DOI 10.17487/RFC7426, January
2015, <https://www.rfc-editor.org/info/rfc7426>. 2015, <https://www.rfc-editor.org/info/rfc7426>.
[RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., [RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R.,
and J. Jeong, "Interface to Network Security Functions and J. Jeong, "Interface to Network Security Functions
(I2NSF): Problem Statement and Use Cases", RFC 8192, (I2NSF): Problem Statement and Use Cases", RFC 8192,
DOI 10.17487/RFC8192, July 2017, DOI 10.17487/RFC8192, July 2017,
<https://www.rfc-editor.org/info/rfc8192>. <https://www.rfc-editor.org/info/rfc8192>.
[RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation [RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation
of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229, of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229,
August 2017, <https://www.rfc-editor.org/info/rfc8229>. August 2017, <https://www.rfc-editor.org/info/rfc8229>.
[RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C., [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R.
Vinapamula, S., and Q. Wu, "A YANG Module for Network Kumar, "Framework for Interface to Network Security
Address Translation (NAT) and Network Prefix Translation Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018,
(NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019, <https://www.rfc-editor.org/info/rfc8329>.
<https://www.rfc-editor.org/info/rfc8512>.
[SDNSecServ]
Scott-Hayward, S., O'Callaghan, G., and P. Sezer, "SDN
Security: A Survey", 2013.
[SDNSecurity]
Kreutz, D., Ramos, F., and P. Verissimo, "Towards Secure
and Dependable Software-Defined Networks", 2013.
[strongswan] [strongswan]
CESNET, "StrongSwan: the OpenSource IPsec-based VPN CESNET, "StrongSwan: the OpenSource IPsec-based VPN
Solution", August 2019. Solution", August 2019.
Appendix A. Appendix A: Common YANG model for IKE and IKE-less cases Appendix A. Common YANG model for IKE and IKE-less cases
<CODE BEGINS> file "ietf-ipsec-common@2019-08-05.yang" <CODE BEGINS> file "ietf-ipsec-common@2019-08-05.yang"
module ietf-ipsec-common { module ietf-ipsec-common {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec-common"; namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec-common";
prefix "ipsec-common"; prefix "ipsec-common";
import ietf-inet-types { prefix inet; } import ietf-inet-types { prefix inet; }
import ietf-yang-types { prefix yang; } import ietf-yang-types { prefix yang; }
skipping to change at page 45, line 42 skipping to change at page 39, line 42
leaf action { leaf action {
type ipsec-spd-action; type ipsec-spd-action;
default discard; default discard;
description description
"If bypass or discard, container "If bypass or discard, container
ipsec-sa-cfg is empty."; ipsec-sa-cfg is empty.";
} }
container ipsec-sa-cfg { container ipsec-sa-cfg {
when "../action = 'protect'"; when "../action = 'protect'";
description description
"IPSec SA configuration included in the SPD "IPsec SA configuration included in the SPD
entry."; entry.";
leaf pfp-flag { leaf pfp-flag {
type boolean; type boolean;
default false; default false;
description description
"Each selector has a Populate From "Each selector has a Populate From
Packet (PFP) flag. If asserted for a Packet (PFP) flag. If asserted for a
given selector X, the flag indicates given selector X, the flag indicates
that the IPSec SA to be created should that the IPsec SA to be created should
take its value (local IP address, take its value (local IP address,
remote IP address, Next Layer remote IP address, Next Layer
Protocol, etc.) for X from the value Protocol, etc.) for X from the value
in the packet. Otherwise, the IPsec SA in the packet. Otherwise, the IPsec SA
should take its value(s) for X from should take its value(s) for X from
the value(s) in the SPD entry."; the value(s) in the SPD entry.";
} }
leaf ext-seq-num { leaf ext-seq-num {
type boolean; type boolean;
default false; default false;
skipping to change at page 48, line 44 skipping to change at page 42, line 44
description description
"Mask used to match XFRM policies and "Mask used to match XFRM policies and
states."; states.";
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
Appendix B. Appendix B: YANG model for IKE case Appendix B. YANG model for IKE case
<CODE BEGINS> file "ietf-ipsec-ike@2019-08-05.yang" <CODE BEGINS> file "ietf-ipsec-ike@2019-08-05.yang"
module ietf-ipsec-ike { module ietf-ipsec-ike {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec-ike"; namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec-ike";
prefix "ike"; prefix "ike";
import ietf-inet-types { prefix inet; } import ietf-inet-types { prefix inet; }
import ietf-yang-types { prefix yang; } import ietf-yang-types { prefix yang; }
skipping to change at page 49, line 51 skipping to change at page 43, line 51
Author: Gabriel Lopez-Millan Author: Gabriel Lopez-Millan
<mailto:gabilm@um.es> <mailto:gabilm@um.es>
Author: Fernando Pereniguez-Garcia Author: Fernando Pereniguez-Garcia
<mailto:fernando.pereniguez@cud.upct.es> <mailto:fernando.pereniguez@cud.upct.es>
"; ";
description description
"This module contains IPSec IKE case model for the SDN-based "This module contains IPsec IKE case model for the SDN-based
IPsec flow protection service. An NSF will implement this IPsec flow protection service. An NSF will implement this
module. module.
Copyright (c) 2019 IETF Trust and the persons identified as Copyright (c) 2019 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
skipping to change at page 53, line 21 skipping to change at page 47, line 21
NSF with identity A will use some particular NSF with identity A will use some particular
authentication with remote NSF with identity B authentication with remote NSF with identity B
and what are the authentication mechanisms and what are the authentication mechanisms
allowed to B."; allowed to B.";
list pad-entry { list pad-entry {
key "name"; key "name";
ordered-by user; ordered-by user;
description description
"Peer Authorization Database (PAD) entry. It "Peer Authorization Database (PAD) entry. It
is a list of PAD entries ordered by the is a list of PAD entries ordered by the
Security Controller."; I2NSF Controller.";
leaf name { leaf name {
type string; type string;
description description
"PAD unique name to identify this "PAD unique name to identify this
entry."; entry.";
} }
choice identity { choice identity {
mandatory true; mandatory true;
description description
"A particular IKE peer will be "A particular IKE peer will be
skipping to change at page 58, line 7 skipping to change at page 52, line 7
type ct:x509; type ct:x509;
description description
"X.509 certificate data - "X.509 certificate data -
PEM4."; PEM4.";
reference reference
"RFC XXX: Common YANG Data "RFC XXX: Common YANG Data
Types for Cryptography."; Types for Cryptography.";
} }
description description
"If the Security Controller "If the I2NSF Controller
knows that the NSF knows that the NSF
already owns a private key already owns a private key
associated to this public key associated to this public key
(the NSF generated the pair (the NSF generated the pair
public key/private key out of public key/private key out of
band), it will only configure band), it will only configure
one of the leaf of this one of the leaf of this
choice. The NSF, based on choice. The NSF, based on
the public key value can know the public key value can know
the private key to be used."; the private key to be used.";
skipping to change at page 67, line 19 skipping to change at page 61, line 19
description description
"General information about the IKE SAs. In "General information about the IKE SAs. In
particular, it provides the current number of particular, it provides the current number of
IKE SAs."; IKE SAs.";
} }
} /* container ipsec-ike */ } /* container ipsec-ike */
} }
<CODE ENDS> <CODE ENDS>
Appendix C. Appendix C: YANG model for IKE-less case Appendix C. YANG model for IKE-less case
<CODE BEGINS> file "ietf-ipsec-ikeless@2019-08-05.yang" <CODE BEGINS> file "ietf-ipsec-ikeless@2019-08-05.yang"
module ietf-ipsec-ikeless { module ietf-ipsec-ikeless {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless"; namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless";
prefix "ikeless"; prefix "ikeless";
import ietf-yang-types { prefix yang; } import ietf-yang-types { prefix yang; }
import ietf-ipsec-common { import ietf-ipsec-common {
prefix ic; prefix ic;
reference reference
"Common Data model for SDN-based IPSec "Common Data model for SDN-based IPsec
configuration."; configuration.";
} }
import ietf-netconf-acm { import ietf-netconf-acm {
prefix nacm; prefix nacm;
reference reference
"RFC 8341: Network Configuration Access Control "RFC 8341: Network Configuration Access Control
Model."; Model.";
} }
organization "IETF I2NSF Working Group";
organization "IETF I2NSF Working Group";
contact contact
"WG Web: <https://datatracker.ietf.org/wg/i2nsf/about/> "WG Web: <https://datatracker.ietf.org/wg/i2nsf/about/>
WG List: <mailto:i2nsf@ietf.org> WG List: <mailto:i2nsf@ietf.org>
Author: Rafael Marin-Lopez Author: Rafael Marin-Lopez
<mailto:rafa@um.es> <mailto:rafa@um.es>
Author: Gabriel Lopez-Millan Author: Gabriel Lopez-Millan
<mailto:gabilm@um.es> <mailto:gabilm@um.es>
skipping to change at page 69, line 7 skipping to change at page 63, line 5
revision "2019-08-05" { revision "2019-08-05" {
description "Revision 06"; description "Revision 06";
reference "RFC XXXX: YANG model for IKE case."; reference "RFC XXXX: YANG model for IKE case.";
} }
container ipsec-ikeless { container ipsec-ikeless {
description description
"Container for configuration of the IKE-less "Container for configuration of the IKE-less
case. The container contains two additional case. The container contains two additional
containers: 'spd' and 'sad'. The first allows the containers: 'spd' and 'sad'. The first allows the
Security Controller to configure IPsec policies in I2NSF Controller to configure IPsec policies in
the Security Policy Database SPD, and the second the Security Policy Database SPD, and the second
allows to configure IPsec Security Associations allows to configure IPsec Security Associations
(IPsec SAs) in the Security Association Database (IPsec SAs) in the Security Association Database
(SAD)."; (SAD).";
reference "RFC 4301."; reference "RFC 4301.";
container spd { container spd {
description description
"Configuration of the Security Policy Database "Configuration of the Security Policy Database
(SPD.)"; (SPD.)";
reference "Section 4.4.1.2 in RFC 4301."; reference "Section 4.4.1.2 in RFC 4301.";
skipping to change at page 69, line 34 skipping to change at page 63, line 32
mandatory true; mandatory true;
description description
"SPD entry unique name to identify this "SPD entry unique name to identify this
entry."; entry.";
} }
leaf direction { leaf direction {
type ic:ipsec-traffic-direction; type ic:ipsec-traffic-direction;
description description
"Inbound traffic or outbound "Inbound traffic or outbound
traffic. In the IKE-less case the traffic. In the IKE-less case the
Security Controller needs to I2NSF Controller needs to
specify the policy direction to be specify the policy direction to be
applied in the NSF. In the IKE case applied in the NSF. In the IKE case
this direction does not need to be this direction does not need to be
specified since IKE specified since IKE
will determine the direction that will determine the direction that
IPsec policy will require."; IPsec policy will require.";
} }
leaf reqid { leaf reqid {
type uint64; type uint64;
default 0; default 0;
skipping to change at page 70, line 22 skipping to change at page 64, line 19
} }
description description
"The SPD is represented as a list of SPD "The SPD is represented as a list of SPD
entries, where each SPD entry represents an entries, where each SPD entry represents an
IPsec policy."; IPsec policy.";
} /*list spd-entry*/ } /*list spd-entry*/
} /*container spd*/ } /*container spd*/
container sad { container sad {
description description
"Configuration of the IPSec Security Association "Configuration of the IPsec Security Association
Database (SAD)"; Database (SAD)";
reference "Section 4.4.2.1 in RFC 4301."; reference "Section 4.4.2.1 in RFC 4301.";
list sad-entry { list sad-entry {
key "name"; key "name";
ordered-by user; ordered-by user;
leaf name { leaf name {
type string; type string;
description description
"SAD entry unique name to identify this "SAD entry unique name to identify this
entry."; entry.";
skipping to change at page 72, line 31 skipping to change at page 66, line 29
description description
"In case the IPsec SA is "In case the IPsec SA is
Encapsulation Security Payload Encapsulation Security Payload
(ESP), it is required to specify (ESP), it is required to specify
encryption and integrity encryption and integrity
algorithms, and key material."; algorithms, and key material.";
container encryption { container encryption {
description description
"Configuration of encryption or "Configuration of encryption or
AEAD algorithm for IPSec AEAD algorithm for IPsec
Encapsulation Security Payload Encapsulation Security Payload
(ESP)."; (ESP).";
leaf encryption-algorithm { leaf encryption-algorithm {
type ic:encryption-algorithm-type; type ic:encryption-algorithm-type;
description description
"Configuration of ESP "Configuration of ESP
encryption. With AEAD encryption. With AEAD
algorithms, the integrity algorithms, the integrity
node is not used."; node is not used.";
skipping to change at page 73, line 12 skipping to change at page 67, line 10
leaf iv { leaf iv {
nacm:default-deny-all; nacm:default-deny-all;
type yang:hex-string; type yang:hex-string;
description description
"ESP encryption IV value."; "ESP encryption IV value.";
} }
} }
container integrity { container integrity {
description description
"Configuration of integrity for "Configuration of integrity for
IPSec Encapsulation Security IPsec Encapsulation Security
Payload (ESP). This container Payload (ESP). This container
allows to configure integrity allows to configure integrity
algorithm when no AEAD algorithm when no AEAD
algorithms are used, and algorithms are used, and
integrity is required."; integrity is required.";
leaf integrity-algorithm { leaf integrity-algorithm {
type ic:integrity-algorithm-type; type ic:integrity-algorithm-type;
description description
"Message Authentication Code "Message Authentication Code
(MAC) algorithm to provide (MAC) algorithm to provide
skipping to change at page 73, line 43 skipping to change at page 67, line 41
container sa-lifetime-hard { container sa-lifetime-hard {
description description
"IPsec SA hard lifetime. The action "IPsec SA hard lifetime. The action
associated is terminate and associated is terminate and
hold."; hold.";
uses ic:lifetime; uses ic:lifetime;
} }
container sa-lifetime-soft { container sa-lifetime-soft {
description description
"IPSec SA soft lifetime."; "IPsec SA soft lifetime.";
uses ic:lifetime; uses ic:lifetime;
leaf action { leaf action {
type ic:lifetime-action; type ic:lifetime-action;
description description
"Action lifetime: "Action lifetime:
terminate-clear, terminate-clear,
terminate-hold or replace."; terminate-hold or replace.";
} }
} }
container tunnel { container tunnel {
when "../mode = 'tunnel'"; when "../mode = 'tunnel'";
uses ic:tunnel-grouping; uses ic:tunnel-grouping;
description description
"Endpoints of the IPsec tunnel."; "Endpoints of the IPsec tunnel.";
} }
container encapsulation-type container encapsulation-type
{ {
uses ic:encap; uses ic:encap;
skipping to change at page 75, line 44 skipping to change at page 69, line 41
"An IPsec SA is required. The traffic-selector "An IPsec SA is required. The traffic-selector
container contains information about the IP packet container contains information about the IP packet
that triggers the acquire notification."; that triggers the acquire notification.";
leaf ipsec-policy-name { leaf ipsec-policy-name {
type string; type string;
mandatory true; mandatory true;
description description
"It contains the SPD entry name (unique) of "It contains the SPD entry name (unique) of
the IPsec policy that hits the IP packet the IPsec policy that hits the IP packet
required IPsec SA. It is assumed the required IPsec SA. It is assumed the
Security Controller will have a copy of the I2NSF Controller will have a copy of the
information of this policy so it can information of this policy so it can
extract all the information with this extract all the information with this
unique identifier. The type of IPsec SA is unique identifier. The type of IPsec SA is
defined in the policy so the Security defined in the policy so the Security
Controller can also know the type of IPsec Controller can also know the type of IPsec
SA that must be generated."; SA that must be generated.";
} }
container traffic-selector { container traffic-selector {
description description
"The IP packet that triggered the acquire "The IP packet that triggered the acquire
skipping to change at page 76, line 23 skipping to change at page 70, line 21
} }
notification sadb-expire { notification sadb-expire {
description "An IPsec SA expiration (soft or hard)."; description "An IPsec SA expiration (soft or hard).";
leaf ipsec-sa-name { leaf ipsec-sa-name {
type string; type string;
mandatory true; mandatory true;
description description
"It contains the SAD entry name (unique) of "It contains the SAD entry name (unique) of
the IPsec SA that has expired. It is assumed the IPsec SA that has expired. It is assumed
the Security Controller will have a copy of the the I2NSF Controller will have a copy of the
IPsec SA information (except the cryptographic IPsec SA information (except the cryptographic
material and state data) indexed by this name material and state data) indexed by this name
(unique identifier) so it can know all the (unique identifier) so it can know all the
information (crypto algorithms, etc.) about information (crypto algorithms, etc.) about
the IPsec SA that has expired in order to the IPsec SA that has expired in order to
perform a rekey (soft lifetime) or delete it perform a rekey (soft lifetime) or delete it
(hard lifetime) with this unique identifier."; (hard lifetime) with this unique identifier.";
} }
leaf soft-lifetime-expire { leaf soft-lifetime-expire {
type boolean; type boolean;
skipping to change at page 77, line 9 skipping to change at page 71, line 7
} }
notification sadb-seq-overflow { notification sadb-seq-overflow {
description "Sequence overflow notification."; description "Sequence overflow notification.";
leaf ipsec-sa-name { leaf ipsec-sa-name {
type string; type string;
mandatory true; mandatory true;
description description
"It contains the SAD entry name (unique) of "It contains the SAD entry name (unique) of
the IPsec SA that is about to have sequence the IPsec SA that is about to have sequence
number overflow and rollover is not permitted. number overflow and rollover is not permitted.
It is assumed the Security Controller will have It is assumed the I2NSF Controller will have
a copy of the IPsec SA information (except the a copy of the IPsec SA information (except the
cryptographic material and state data) indexed cryptographic material and state data) indexed
by this name (unique identifier) so the it can by this name (unique identifier) so the it can
know all the information (crypto algorithms, know all the information (crypto algorithms,
etc.) about the IPsec SA that has expired in etc.) about the IPsec SA that has expired in
order to perform a rekey of the IPsec SA."; order to perform a rekey of the IPsec SA.";
} }
} }
notification sadb-bad-spi { notification sadb-bad-spi {
description description
skipping to change at page 77, line 34 skipping to change at page 71, line 32
mandatory true; mandatory true;
description description
"SPI number contained in the erroneous IPsec "SPI number contained in the erroneous IPsec
packet."; packet.";
} }
} }
}/*module ietf-ipsec*/ }/*module ietf-ipsec*/
<CODE ENDS> <CODE ENDS>
Appendix D. Example of IKE case, tunnel mode (gateway-to-gateway) with Appendix D. XML configuration example for IKE case (gateway-to-gateway)
X.509 certificate authentication.
This example shows a XML configuration file sent by the Security This example shows a XML configuration file sent by the I2NSF
Controller to establish a IPsec Security Association between two NSFs Controller to establish a IPsec Security Association between two NSFs
in tunnel mode (gateway-to-gateway) with ESP, and authentication (see Figure 3) in tunnel mode (gateway-to-gateway) with ESP,
based on X.509 certificates using IKEv2. authentication based on X.509 certificates and applying the IKE case.
Security Controller +------------------+
| | I2NSF Controller |
/---- Southbound interface -----\ +------------------+
/ \ I2NSF NSF-Facing |
/ \ Interface |
/ \ /------------------+-----------------\
/ \ / \
nsf_h1 nsf_h2 / \
h1---- (:1/:100)===== IPsec_ESP_Tunnel_mode =====(:200/:1)-------h2 +----+ +--------+ +--------+ +----+
2001:DB8:1:/64 (2001:DB8:123:/64) 2001:DB8:2:/64 | h1 |--| nsf_h1 |== IPsec_ESP_Tunnel_mode == | nsf_h2 |--| h2 |
+----+ +--------+ +--------+ +----+
:1 :100 :200 :1
Figure 7: IKE case, tunnel mode , X.509 certicate authentication. (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-ipsec-ike" <ipsec-ike xmlns="urn:ietf:params:xml:ns:yang:ietf-ipsec-ike"
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
<pad> <pad>
<pad-entry> <pad-entry>
<name>nsf_h1_pad</name> <name>nsf_h1_pad</name>
<ipv6-address>2001:DB8:123::100</ipv6-address> <ipv6-address>2001:DB8:123::100</ipv6-address>
<peer-authentication> <peer-authentication>
<auth-method>digital-signature</auth-method> <auth-method>digital-signature</auth-method>
<digital-signature> <digital-signature>
skipping to change at page 81, line 5 skipping to change at page 75, line 5
<child-sa-lifetime-hard> <child-sa-lifetime-hard>
<bytes>2000000</bytes> <bytes>2000000</bytes>
<packets>2000</packets> <packets>2000</packets>
<time>60</time> <time>60</time>
<idle>120</idle> <idle>120</idle>
</child-sa-lifetime-hard> </child-sa-lifetime-hard>
</child-sa-info> </child-sa-info>
</conn-entry> </conn-entry>
</ipsec-ike> </ipsec-ike>
Appendix E. Example of IKE-less case, transport mode (host-to-host). Appendix E. XML configuration example for IKE-less case (host-to-host)
This example shows a XML configuration file sent by the Security This example shows a XML configuration file sent by the I2NSF
Controller to establish a IPsec Security association between two NSFs Controller to establish a IPsec Security Association between two NSFs
in transport mode (host-to-host) with ESP. (see Figure 4) in transport mode (host-to-host) with ESP, and
applying the IKE-less case.
Security Controller +------------------+
| | I2NSF Controller |
/---- Southbound interface -----\ +------------------+
/ \ I2NSF NSF-Facing |
/ \ Interface |
/ \ /--------------------+-------------------\
/ \ / \
nsf_h1 nsf_h2 / \
(:100)===== IPsec_ESP_Transport_mode =====(:200) +--------+ +--------+
(2001:DB8:123:/64) | nsf_h1 |===== IPsec_ESP_Transport_mode =====| nsf_h2 |
+--------+ +--------+
:100 (2001:DB8:123:/64) :200
Figure 8: IKE-less case, transport mode. Figure 4: IKE-less case, transport mode.
<ipsec-ikeless <ipsec-ikeless
xmlns="urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless" xmlns="urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless"
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
<spd> <spd>
<spd-entry> <spd-entry>
<name> <name>
in/trans/2001:DB8:123::200/2001:DB8:123::100 in/trans/2001:DB8:123::200/2001:DB8:123::100
</name> </name>
<direction>inbound</direction> <direction>inbound</direction>
skipping to change at page 84, line 46 skipping to change at page 79, line 4
<packets>2000</packets> <packets>2000</packets>
<time>60</time> <time>60</time>
<idle>120</idle> <idle>120</idle>
</sa-lifetime-hard> </sa-lifetime-hard>
<sa-lifetime-soft> <sa-lifetime-soft>
<bytes>1000000</bytes> <bytes>1000000</bytes>
<packets>1000</packets> <packets>1000</packets>
<time>30</time> <time>30</time>
<idle>60</idle> <idle>60</idle>
<action>replace</action> <action>replace</action>
</sa-lifetime-soft> </sa-lifetime-soft>
</ipsec-sa-config> </ipsec-sa-config>
</sad-entry> </sad-entry>
</sad> </sad>
</ipsec-ikeless> </ipsec-ikeless>
Appendix F. Examples of notifications. Appendix F. XML notification examples
Below we show several XML files that represent different types of Below we show several XML files that represent different types of
notifications defined in the IKE-less YANG model, which are sent by notifications defined in the IKE-less YANG model, which are sent by
the NSF to the Security Controller. The notifications happen in the the NSF to the I2NSF Controller. The notifications happen in the
IKE-less case. IKE-less case.
<sadb-expire xmlns="urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless"> <sadb-expire xmlns="urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless">
<ipsec-sa-name>in/trans/2001:DB8:123::200/2001:DB8:123::100 <ipsec-sa-name>in/trans/2001:DB8:123::200/2001:DB8:123::100
</ipsec-sa-name> </ipsec-sa-name>
<soft-lifetime-expire>true</soft-lifetime-expire> <soft-lifetime-expire>true</soft-lifetime-expire>
<lifetime-current> <lifetime-current>
<bytes>1000000</bytes> <bytes>1000000</bytes>
<packets>1000</packets> <packets>1000</packets>
<time>30</time> <time>30</time>
<idle>60</idle> <idle>60</idle>
</lifetime-current> </lifetime-current>
</sadb-expire> </sadb-expire>
Figure 9: Example of sadb-expire notification. Figure 5: Example of sadb-expire notification.
<sadb-acquire xmlns="urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless"> <sadb-acquire xmlns="urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless">
<ipsec-policy-name>in/trans/2001:DB8:123::200/2001:DB8:123::100 <ipsec-policy-name>in/trans/2001:DB8:123::200/2001:DB8:123::100
</ipsec-policy-name> </ipsec-policy-name>
<traffic-selector> <traffic-selector>
<local-subnet>2001:DB8:123::200/128</local-subnet> <local-subnet>2001:DB8:123::200/128</local-subnet>
<remote-subnet>2001:DB8:123::100/128</remote-subnet> <remote-subnet>2001:DB8:123::100/128</remote-subnet>
<inner-protocol>any</inner-protocol> <inner-protocol>any</inner-protocol>
<local-ports> <local-ports>
<start>0</start> <start>0</start>
<end>0</end> <end>0</end>
</local-ports> </local-ports>
<remote-ports> <remote-ports>
<start>0</start> <start>0</start>
<end>0</end> <end>0</end>
</remote-ports> </remote-ports>
</traffic-selector> </traffic-selector>
</sadb-acquire> </sadb-acquire>
Figure 10: Example of sadb-acquire notification. Figure 6: Example of sadb-acquire notification.
<sadb-seq-overflow <sadb-seq-overflow
xmlns="urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless"> xmlns="urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless">
<ipsec-sa-name>in/trans/2001:DB8:123::200/2001:DB8:123::100 <ipsec-sa-name>in/trans/2001:DB8:123::200/2001:DB8:123::100
</ipsec-sa-name> </ipsec-sa-name>
</sadb-seq-overflow> </sadb-seq-overflow>
Figure 11: Example of sadb-seq-overflow notification. Figure 7: Example of sadb-seq-overflow notification.
<sadb-bad-spi <sadb-bad-spi
xmlns="urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless"> xmlns="urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless">
<spi>666</spi> <spi>666</spi>
</sadb-bad-spi> </sadb-bad-spi>
Figure 12: Example of sadb-bad-spi notification. Figure 8: Example of sadb-bad-spi notification.
Appendix G. Operational use cases examples
G.1. Example of IPsec SA establishment
This appendix exemplifies the applicability of IKE case and IKE-less
case to traditional IPsec configurations, that is, host-to-host and
gateway-to-gateway. The examples we show in the following assume the
existence of two NSFs needing to establish an end-to-end IPsec SA to
protect their communications. Both NSFs could be two hosts that
exchange traffic (host-to-host) or gateways (gateway-to-gateway), for
example, within an enterprise that needs to protect the traffic
between the networks of two branch offices.
Applicability of these configurations appear in current and new
networking scenarios. For example, SD-WAN technologies are providing
dynamic and on-demand VPN connections between branch offices, or
between branches and SaaS cloud services. Beside, IaaS services
providing virtualization environments are deployments solutions based
on IPsec to provide secure channels between virtual instances (host-
to-host) and providing VPN solutions for virtualized networks
(gateway-to-gateway).
As we will show in the following, the I2NSF-based IPsec management
system (for IKE and IKE-less cases), exhibits various advantages:
1. It allows to create IPsec SAs among two NSFs, based only on the
application of general Flow-based Protection Policies at the
I2NSF User. Thus, administrators can manage all security
associations in a centralized point with an abstracted view of
the network.
2. Any NSF deployed in the system does not need manual
configuration, therefore allowing its deployment in an automated
manner.
G.1.1. IKE case
+----------------------------------------+
| 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.
Figure 9 describes the application of the IKE case when a data packet
needs to be protected in the path between the NSF A and NSF B:
1. The I2NSF User defines a general flow-based protection policy
(e.g. protect data traffic between NSF A and B). The I2NSF
Controller looks for the NSFs involved (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 inserts an IKEv2 configuration that includes
the SPD and PAD entries in both NSF A and NSF B. If some of
operations with NSF A and NSF B fail the I2NSF Controller will
stop the process and perform a rollback operation by deleting any
IKEv2, SPD and PAD configuration that had been successfully
installed in NSF A or B.
If the previous steps are successful, the flow is protected by means
of the IPsec SA established with IKEv2 between NSF A and NSF B.
G.1.2. IKE-less case
+----------------------------------------+
| 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 IKE-less case.
Figure 10 describes the application of the IKE-less case when a data
packet needs to be protected in the path between the NSF A and NSF B:
1. The I2NSF User establishes a general Flow-based Protection Policy
and the I2NSF Controller looks for the involved NSFs.
2. The I2NSF Controller translates the flow-based security policies
into IPsec SPD and SAD entries.
3. The I2NSF Controller inserts these entries in both NSF A and NSF
B IPsec databases (SPD and SAD). The following text describes
how this would happen:
* The I2NSF Controller chooses two random values as SPIs: for
example, SPIa1 for NSF A and SPIb1 for NSF B. These numbers
MUST NOT be in conflict with any IPsec SA in NSF A or NSF B.
It also generates fresh cryptographic material for the new
inbound/outbound IPsec SAs and their parameters.
* After that, the I2NSF Controller sends simultaneously the new
inbound IPsec SA with SPIa1 and new outbound IPsec SA with
SPIb1 to NSF A; and the new inbound IPsec SA with SPIb1 and
new outbound IPsec SA with SPIa1 to B, together with the
corresponding IPsec policies.
* Once the I2NSF Controller receives confirmation from NSF A and
NSF B, it knows that the IPsec SAs are correctly installed and
ready.
Other alternative to this operation is: the I2NSF Controller
sends first the IPsec policies and new inbound IPsec SAs to A and
B and once it obtains a successful confirmation of these
operations from NSF A and NSF B, it proceeds with installing to
the new outbound IPsec SAs. Despite this procedure may increase
the latency to complete the process, no traffic is sent over the
network until the IPsec SAs are completely operative. In any
case other alternatives MAY be possible to implement step 3.
4. If some of the operations described above fails (e.g. the NSF A
reports an error when the I2NSF Controller is trying to install
the SPD entry, the new inbound or outbound IPsec SAs) the I2NSF
Controller must perform rollback operations by deleting any new
inbound or outbound SA and SPD entry that had been successfully
installed in any of the NSFs (e.g NSF B) and stop the process.
Note that the I2NSF Controller may retry several times before
giving up.
5. Otherwise, if the steps 1 to 3 are successful, the flow between
NSF A and NSF B is protected by means of the IPsec SAs
established by the I2NSF Controller. It is worth mentioning that
the I2NSF Controller associates a lifetime to the new IPsec SAs.
When this lifetime expires, the NSF will send a sadb-expire
notification to the I2NSF Controller in order to start the
rekeying process.
Instead of installing IPsec policies (in the SPD) and IPsec SAs (in
the SAD) in step 3 (proactive mode), it is also possible that the
I2NSF Controller only installs the SPD entries in step 3 (reactive
mode). In such a case, when a data packet requires to be protected
with IPsec, the NSF that saw first the data packet will send a sadb-
acquire notification that informs the I2NSF Controller that needs SAD
entries with the IPsec SAs to process the data packet. In such as
reactive mode, upon reception of the sadb-acquire notification, the
I2NSF Controller installs the new IPsec SAs in NSF A and B (following
the procedure previously described in step 3) but without sending any
IPsec policies, since IPsec policies are already installed in the
SPD. Again, if some of the operations installing the new inbound/
outbound IPsec SAs fail, the I2NSF Controller stops the process and
performs a rollback operation by deleting any new inbound/outbound
SAs that had been successfully installed.
G.2. Example of the rekeying process in IKE-less case
To explain an example of the rekeying process between two IPsec NSFs
A and B, let assume that SPIa1 identifies the inbound IPsec SA in A,
and SPIb1 the inbound IPsec SA in B. The rekeying process will take
the following steps:
1. The I2NSF Controller chooses two random values as SPI for the new
inbound IPsec SAs: for example, SPIa2 for A and SPIb2 for B.
These numbers MUST NOT be in conflict with any IPsec SA in A or
B. Then, the I2NSF Controller creates an inbound IPsec SA with
SPIa2 in A and another inbound IPsec SA in B with SPIb2. It can
send this information simultaneously to A and B.
2. Once the I2NSF Controller receives confirmation from A and B, the
controller knows that the inbound IPsec SAs are correctly
installed. Then it proceeds to send 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 receives confirmation from A and B that
the outbound IPsec SAs have been installed, the I2NSF Controller,
in parallel, deletes the old IPsec SAs from A (inbound SPIa1 and
outbound SPIb1) and B (outbound SPIa1 and inbound SPIb1).
If some of the operations in step 1 fail (e.g. the NSF A reports an
error when the I2NSF Controller is trying to install a new inbound
IPsec SA) the I2NSF Controller must perform rollback operations by
removing any new inbound SA that had been successfully installed
during step 1.
If step 1 is successful but some of the operations in step 2 fails
(e.g. the NSF A reports an error when the I2NSF Controller is trying
to install the new outbound IPsec SA), the I2NSF Controller must
perform a rollback operation by deleting any new outbound SA that had
been successfully installed during step 2 and by deleting the inbound
SAs created in step 1.
If the steps 1 an 2 are successful and the step 3 fails, the I2NSF
Controller will avoid any rollback of the operations carried out in
step 1 and step 2 since new and valid IPsec SAs were created and are
functional. The I2NSF Controller may reattempt to remove the old
inbound and outbound SAs in NSF A and NSF B several times until it
receives a success or it gives up. In the last case, the old IPsec
SAs will be removed when their corresponding hard lifetime is
reached.
G.3. Example of managing NSF state loss in IKE-less case
In the IKE-less case, if the I2NSF Controller detects that a NSF has
lost the IPsec state, it could follow the next steps:
1. The I2NSF Controller SHOULD delete the old IPsec SAs on the non-
failed nodes, established with the failed node. This prevents
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 these inbound IPsec SAs have been established, the I2NSF
Controller configures the outbound IPsec SAs in parallel.
Step 2 and step 3 can be performed at the same time at the cost of a
potential packet loss. If this is not critic then it is an
optimization since the number of exchanges between I2NSF Controller
and NSFs is lower.
Authors' Addresses Authors' Addresses
Rafa Marin-Lopez Rafa Marin-Lopez
University of Murcia University of Murcia
Campus de Espinardo S/N, Faculty of Computer Science Campus de Espinardo S/N, Faculty of Computer Science
Murcia 30100 Murcia 30100
Spain Spain
Phone: +34 868 88 85 01 Phone: +34 868 88 85 01
 End of changes. 155 change blocks. 
878 lines changed or deleted 858 lines changed or added

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