draft-ietf-i2nsf-sdn-ipsec-flow-protection-04.txt   draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.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: September 12, 2019 F. Pereniguez-Garcia Expires: January 8, 2020 F. Pereniguez-Garcia
University Defense Center University Defense Center
March 11, 2019 July 7, 2019
Software-Defined Networking (SDN)-based IPsec Flow Protection Software-Defined Networking (SDN)-based IPsec Flow Protection
draft-ietf-i2nsf-sdn-ipsec-flow-protection-04 draft-ietf-i2nsf-sdn-ipsec-flow-protection-05
Abstract Abstract
This document describes how providing IPsec-based flow protection by This document describes how providing IPsec-based flow protection by
means of a Software-Defined Network (SDN) controller (aka. Security means of a Software-Defined Network (SDN) controller (aka. Security
Controller) and establishes the requirements to support this service. Controller) and establishes the requirements to support this service.
It 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 SDN-based service described in gateway and (ii) host-to-host. The SDN-based service described in
this document allows the distribution and monitoring of IPsec this document allows the distribution and monitoring of IPsec
information from a Security Controller to one or several flow-based information from a Security Controller to one or several flow-based
Network Security Function (NSF). The NSFs implement IPsec to protect Network Security Function (NSF). The NSFs implement IPsec to protect
data traffic between network resources with IPsec. data traffic between network resources.
The document focuses in the NSF Facing Interface by providing models The document focuses on the NSF Facing Interface by providing models
for Configuration and State data model required to allow the Security for configuration and state data required to allow the Security
Controller to configure the IPsec databases (SPD, SAD, PAD) and IKEv2 Controller to configure the IPsec databases (SPD, SAD, PAD) and IKEv2
to establish security associations with a reduced intervention of the to establish Security Associations with a reduced intervention of the
network administrator. 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 September 12, 2019. This Internet-Draft will expire on January 8, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. SDN-based IPsec management description . . . . . . . . . . . 6 5. SDN-based IPsec management description . . . . . . . . . . . 6
5.1. IKE case: IKE/IPsec in the NSF . . . . . . . . . . . . . 6 5.1. IKE case: IKE/IPsec in the NSF . . . . . . . . . . . . . 6
5.1.1. Interface Requirements for IKE case . . . . . . . . . 7 5.1.1. Interface Requirements for IKE case . . . . . . . . . 7
5.2. IKE-less case: IPsec (no IKEv2) in the NSF . . . . . . . 8 5.2. IKE-less case: IPsec (no IKEv2) in the NSF. . . . . . . . 7
5.2.1. Interface Requirements for IKE-less case . . . . . . 8 5.2.1. Interface Requirements for IKE-less case . . . . . . 8
5.3. IKE case vs IKE-less case . . . . . . . . . . . . . . . . 9 5.3. IKE case vs IKE-less case . . . . . . . . . . . . . . . . 9
5.3.1. Rekeying process . . . . . . . . . . . . . . . . . . 10 5.3.1. Rekeying process. . . . . . . . . . . . . . . . . . . 10
5.3.2. NSF state loss . . . . . . . . . . . . . . . . . . . 11 5.3.2. NSF state loss. . . . . . . . . . . . . . . . . . . . 11
5.3.3. NAT Traversal . . . . . . . . . . . . . . . . . . . . 12 5.3.3. NAT Traversal . . . . . . . . . . . . . . . . . . . . 12
6. YANG configuration data models . . . . . . . . . . . . . . . 12 5.3.4. NSF Discovery . . . . . . . . . . . . . . . . . . . . 12
6. YANG configuration data models . . . . . . . . . . . . . . . 13
6.1. IKE case model . . . . . . . . . . . . . . . . . . . . . 13 6.1. IKE case model . . . . . . . . . . . . . . . . . . . . . 13
6.2. IKE-less case model . . . . . . . . . . . . . . . . . . . 16 6.2. IKE-less case model . . . . . . . . . . . . . . . . . . . 16
7. Use cases examples . . . . . . . . . . . . . . . . . . . . . 21 7. Use cases examples . . . . . . . . . . . . . . . . . . . . . 20
7.1. Host-to-host or gateway-to-gateway under the same 7.1. Host-to-host or gateway-to-gateway under the same
controller . . . . . . . . . . . . . . . . . . . . . . . 21 Security Controller . . . . . . . . . . . . . . . . . . . 20
7.2. Host-to-host or gateway-to-gateway under different 7.2. Host-to-host or gateway-to-gateway under different
security controllers . . . . . . . . . . . . . . . . . . 23 Security Controllers . . . . . . . . . . . . . . . . . . 22
8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
8.1. IKE case . . . . . . . . . . . . . . . . . . . . . . . . 26 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25
8.2. IKE-less case . . . . . . . . . . . . . . . . . . . . . . 26 9.1. IKE case . . . . . . . . . . . . . . . . . . . . . . . . 25
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 9.2. IKE-less case . . . . . . . . . . . . . . . . . . . . . . 26
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
10.1. Normative References . . . . . . . . . . . . . . . . . . 27 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
10.2. Informative References . . . . . . . . . . . . . . . . . 28 11.1. Normative References . . . . . . . . . . . . . . . . . . 27
Appendix A. Appendix A: Common YANG model for IKE and IKEless 11.2. Informative References . . . . . . . . . . . . . . . . . 27
cases . . . . . . . . . . . . . . . . . . . . . . . 31 Appendix A. Appendix A: Common YANG model for IKE and IKE-less
Appendix B. Appendix B: YANG model for IKE case . . . . . . . . 37 cases . . . . . . . . . . . . . . . . . . . . . . . 30
Appendix C. Appendix C: YANG model for IKE-less case . . . . . . 43 Appendix B. Appendix B: YANG model for IKE case . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 Appendix C. Appendix C: YANG model for IKE-less case . . . . . . 62
Appendix D. Example of IKE case, tunnel mode (gateway-to-
gateway) with X.509 certificate authentication. . . 72
Appendix E. Example of IKE-less case, transport mode (host-to-
host). . . . . . . . . . . . . . . . . . . . . . . . 75
Appendix F. Examples of notifications. . . . . . . . . . . . . . 79
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 81
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. SDN paradigm relocates the control of resources through software. The SDN paradigm relocates the control
network resources to a dedicated network element, namely SDN of network resources to a dedicated network element, namely SDN
controller. The SDN controller manages and configures the Controller. The SDN controller (or Security Controller in the
distributed network resources and provides an abstracted view of the context of this document) manages and configures the distributed
network resources to the SDN applications. The SDN application can network resources and provides an abstracted view of the network
customize and automate the operations (including management) of the resources to the SDN applications. The SDN application can customize
abstracted network resources in a programmable manner via this and automate the operations (including management) of the abstracted
interface [RFC7149][ITU-T.Y.3300] network resources in a programmable manner via this interface
[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 considering a centralized way
of managing different security aspects. For example, Software- of managing different security aspects. For example, Software-
Defined WANs (SD-WAN) advocates to manage IPsec SAs from a Defined WANs (SD-WAN), an SDN extension providing a software
centralized point. Therefore, with the growth of SDN-based scenarios abstraction to create secure network overlays over traditional WAN
where network resources are deployed in an autonomous manner, a and branch networks. SD-WAN is based on IPsec as underlying security
mechanism to manage IPsec SAs according to the SDN architecture protocol and aims to provide flexible, automated, fast deployment and
becomes more relevant. Thus, the SDN-based service described in this on-demand security network services such as IPsec SA management from
document will autonomously deal with IPsec SAs management following a a centralized point.
SDN paradigm.
An example of usage can be the notion of Software Defined WAN (SD- Therefore, with the growth of SDN-based scenarios where network
WAN), SDN extension providing a software abstraction to create secure resources are deployed in an autonomous manner, a mechanism to manage
network overlays over traditional WAN and branch networks. SD-WAN is IPsec SAs according to the SDN architecture becomes more relevant.
based on IPsec as underlying security protocol and aims to provide Thus, the SDN-based service described in this document will
flexible, automated, fast deployment and on-demand security network autonomously deal with IPsec SAs management following the SDN
services. paradigm.
IPsec architecture [RFC4301] defines a 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 In this document, we define a service where the key management
procedures can be carried by an external entity: the Security procedures can be carried by an external and centralized entity: the
Controller. Security Controller.
First, this document exposes the requirements to support the First, this document exposes the requirements to support the
protection of data flows using IPsec [RFC4301]. We have considered protection of data flows using IPsec [RFC4301]. We have considered
two general cases: two general cases:
1) IKE case. The Network Security Function (NSF) implements the 1) IKE case. The Network Security Function (NSF) implements the
Internet Key Exchange (IKE) protocol and the IPsec databases: the Internet Key Exchange (IKE) protocol and the IPsec databases: the
Security Policy Database (SPD), the Security Association Database Security Policy Database (SPD), the Security Association Database
(SAD) and the Peer Authorization Database (PAD). The Security (SAD) and the Peer Authorization Database (PAD). The Security
Controller is in charge of provisioning the NSF with the required Controller is in charge of provisioning the NSF with the required
information to IKE, the SPD and the PAD. information to IKE, the SPD and the PAD.
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 Security 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 automated key management functionality is moved to
the controller. the Security Controller.
In both cases, an interface/protocol is required to carry out this In both cases, an interface/protocol is required to carry out this
provisioning in a secure manner between the Security Controller and provisioning in a secure manner between the Security Controller and
the NSF. In particular, IKE case requires the provision of SPD and the NSF. In particular, IKE case requires the provision of SPD and
PAD entries and the IKE credential and information related with the PAD entries, the IKE credential and information related with the IKE
IKE negotiation (e.g. IKE_SA_INIT), and IKE-less case requires the negotiation (e.g. IKE_SA_INIT). IKE-less case requires the
management of SPD and SAD entries. Based on YANG models in 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). (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.
This document considers two typical scenarios to manage autonomously This document considers two typical scenarios to manage autonomously
IPsec SAs: gateway-to-gateway and host-to-host [RFC6071]. The IPsec SAs: gateway-to-gateway and host-to-host [RFC6071]. In these
analysis of the host-to-gateway (roadwarrior) scenario is out of cases, hosts, gateways or both may act as NSFs. Finally, it also
scope of this document. In these cases, host or gateways or both may discusses the situation where two NSFs are under the control of two
act as NSFs. Finally, it also discusses the situation where two NSFs different Security Controllers. The analysis of the host-to-gateway
are under the control of two different Security Controllers. (roadwarrior) scenario is out of scope of this document.
NOTE: This work pays attention to the challenge "Lack of Mechanism Finally, this work pays attention to the challenge "Lack of Mechanism
for Dynamic Key Distribution to NSFs" defined in [RFC8192] in the for Dynamic Key Distribution to NSFs" defined in [RFC8192] in the
particular case of the establishment and management of IPsec SAs. In particular case of the establishment and management of IPsec SAs. In
fact, this I-D could be considered as a proper use case for this fact,this I-D could be considered as a proper use case for this
particular challenge in [RFC8192]. particular challenge in [RFC8192].
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", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
When these words appear in lower case, they have their natural When these words appear in lower case, they have their natural
language meaning. language meaning.
3. Terminology 3. Terminology
This document uses the terminology described in [RFC7149], [RFC4301], This document uses the terminology described in [RFC7149], [RFC4301],
[ITU-T.Y.3300], [ONF-SDN-Architecture], [ONF-OpenFlow], [ITU-T.Y.3300], [ONF-SDN-Architecture], [ONF-OpenFlow],
[ITU-T.X.1252], [ITU-T.X.800] and [I-D.ietf-i2nsf-terminology]. In [ITU-T.X.1252], [ITU-T.X.800] and [I-D.ietf-i2nsf-terminology]. In
addition, the following terms are defined below: addition, the following terms are defined below:
o Software-Defined Networking. A set of techniques enabling to o Software-Defined Networking. A set of techniques enabling to
directly program, orchestrate, control, and manage network directly program, orchestrate, control, and manage network
resources, which facilitates the design, delivery and operation of resources, which facilitates the design, delivery and operation of
network services in a dynamic and scalable manner [ITU-T.Y.3300]. network services in a dynamic and scalable manner [ITU-T.Y.3300].
o Flow/Data Flow. Set of network packets sharing a set of o Flow/Data Flow. Set of network packets sharing a set of
characteristics, for example IP dst/src values or QoS parameters. characteristics, for example IP dst/src values or QoS parameters.
skipping to change at page 5, line 16 skipping to change at page 5, line 23
addition, the following terms are defined below: addition, the following terms are defined below:
o Software-Defined Networking. A set of techniques enabling to o Software-Defined Networking. A set of techniques enabling to
directly program, orchestrate, control, and manage network directly program, orchestrate, control, and manage network
resources, which facilitates the design, delivery and operation of resources, which facilitates the design, delivery and operation of
network services in a dynamic and scalable manner [ITU-T.Y.3300]. network services in a dynamic and scalable manner [ITU-T.Y.3300].
o Flow/Data Flow. Set of network packets sharing a set of o Flow/Data Flow. Set of network packets sharing a set of
characteristics, for example IP dst/src values or QoS parameters. characteristics, for example IP dst/src values or QoS parameters.
o Security Controller. A Controller is a management component that o Security Controller. An entity that contains control plane
contains control plane functions to manage and facilitate functions to manage and facilitate information sharing, as well as
information sharing, as well as execute security functions. In execute security functions. In the context of this document, it
the context of this document, it provides IPsec management provides IPsec management information.
information.
o Network Security Function (NSF). Software that provides a set of o Network Security Function (NSF). Software that provides a set of
security-related services. security-related services.
o Flow-based NSF. A NSF that inspects network flows according to a o Flow-based NSF. A NSF that inspects network flows according to a
set of policies intended for enforcing security properties. The set of policies intended for enforcing security properties. The
NSFs considered in this document falls into this classification. NSFs considered in this document fall into this classification.
o Flow-based Protection Policy. The set of rules defining the o Flow-based Protection Policy. The set of rules defining the
conditions under which a data flow MUST be protected with IPsec, conditions under which a data flow MUST be protected with IPsec,
and the rules that MUST be applied to the specific flow. and the rules that MUST be applied to the specific flow.
o Internet Key Exchange (IKE) v2 Protocol to establish IPsec o Internet Key Exchange (IKE) v2. Protocol to establish IPsec
Security Associations (SAs). It requires information about the Security Associations (SAs). It requires information about the
required authentication method (i.e. raw RSA/ECDSA keys or X.509 required authentication method (i.e. raw RSA/ECDSA keys or X.509
certificates), DH groups, modes and algorithms for IKE SA certificates), Diffie-Hellman (DH) groups, IPsec SAs parameters
negotiation, etc. and algorithms for IKE SA negotiation, etc.
o Security Policy Database (SPD). It includes information about o Security Policy Database (SPD). It includes information about
IPsec policies direction (in, out), local and remote addresses, IPsec policies direction (in, out), local and remote addresses
inbound and outboud SAs, etc. (traffic selectors information), inbound and outboud IPsec SAs,
etc.
o Security Associations Database (SAD). It includes information o Security Associations Database (SAD). It includes information
about IPsec SAs, such as SPI, destination addresses, about IPsec SAs, such as SPI, destination addresses,
authentication and encryption algorithms and keys to protect IP authentication and encryption algorithms and keys to protect IP
flows. flows.
o Peer Authorization Database (PAD). It provides the link between o Peer Authorization Database (PAD). It provides the link between
the SPD and a security association management protocol such as IKE the SPD and a security association management protocol. It is
or the SDN-based solution described in this document. used when the NSF deploys IKE implementation (IKE case).
4. Objectives 4. Objectives
o To describe the architecture for the SDN-based IPsec management, o To describe the architecture for the SDN-based IPsec management,
which implements a security service to allow the establishment and which implements a security service to allow the establishment and
management of IPsec security associations from a central point, in management of IPsec security associations from a central point, in
order to protect specific data flows. order to protect specific data flows.
o To define the interfaces required to manage and monitor the IPsec o To define the interfaces required to manage and monitor the IPsec
Security Associations in the NSF from a Security Controller. YANG Security Associations (SA) in the NSF from a Security Controller.
models are defined for configuration and state data for IPsec YANG models are defined for configuration and state data for IPsec
management. management.
5. SDN-based IPsec management description 5. SDN-based IPsec management description
As mentioned in Section 1, two cases are considered: As mentioned in Section 1, two cases are considered, depending on
whether the NSF ships an IKEv2 implementation or not: IKE case and
IKE-less case.
5.1. IKE case: IKE/IPsec in the NSF 5.1. IKE case: IKE/IPsec in the NSF
In this case the NSF ships an IKEv2 implementation besides the IPsec In this case the NSF ships an IKEv2 implementation besides the IPsec
support. The Security Controller is in charge of managing and support. The Security Controller is in charge of managing and
applying SPD and PAD entries (deriving and delivering IKE Credentials applying IPsec connection information (determining which nodes need
such as a pre-shared key, certificates, etc.), and applying other IKE to start an IKE/IPsec session, deriving and delivering IKE
configuration parameters (e.g. IKE_SA_INIT algorithms) to the NSF Credentials such as a pre-shared key, certificates, etc.), and
for the IKE negotiation. applying other IKE configuration parameters (e.g. cryptographic
algorithms for establishing an IKE SA) to the NSF for the IKE
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 application (administrator) establishes the IPsec
requirements and information about the end points information requirements and information about the end points information
(through the Client Facing Interface, [RFC8192]), and the Security (through the Client Facing Interface, [RFC8192]), and the Security
Controller translates those requirements into IKE, SPD and PAD Controller translates these requirements into IKE, SPD and PAD
entries that will be installed into the NSF (through the NSF Facing entries that will be installed into the NSF (through the 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 data 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/Orchestration Application | Client or
| I2NSF Client | App Gateway | I2NSF Client | App Gateway
+-------------------------------------------+ +-------------------------------------------+
| Client Facing Interface | Client Facing Interface
+-------------------------------------------+ +-------------------------------------------+
Vendor | Application Support | Vendor | Application Support |
Facing<->|-------------------------------------------| Security Facing<->|-------------------------------------------| Security
Interface| IKE Credential,PAD and SPD entries Distr. | Controller Interface| IKE Credential,PAD and SPD entries Distr. | Controller
+-------------------------------------------+ +-------------------------------------------+
| NSF Facing Interface | NSF Facing Interface
+-------------------------------------------+ +-------------------------------------------+
| I2NSF Agent | | I2NSF Agent |
|-------------------------------------------| Network |-------------------------------------------| Network
| IKE | IPsec(SPD,PAD) | Security | IKE | IPsec(SPD,PAD) | Security
|-------------------------------------------| Function |-------------------------------------------| Function
| Data Protection and Forwarding | | 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 5.1.1. Interface Requirements for IKE case
SDN-based IPsec flow protection services provide dynamic and flexible SDN-based IPsec flow protection services provide dynamic and flexible
management of IPsec SAs in flow-based NSF. In order to support this management of IPsec SAs in flow-based NSFs. In order to support this
capability in case IKE case, the following interface requirements are capability in IKE case, the following interface requirements need to
to be met: be met:
o A YANG data model for configuration data for IKEv2, SPD and PAD.
o A YANG data model for state data for IKE, PAD, SPD and SAD (NOTE: o A YANG data model for IKEv2, SPD and PAD configuration data, and
the SAD entries are created in runtime by IKEv2.) for IKE state data.
o In scenarios where multiple controllers are implicated, SDN-based o In scenarios where multiple Security Controllers are implicated,
IPsec management services may require a mechanism to discover SDN-based IPsec management services may require a mechanism to
which Security Controller is managing a specific NSF. Moreover, discover which Security Controller is managing a specific NSF.
an east-west interface [RFC7426] is required to exchange IPsec- Moreover, an east-west interface [RFC7426] is required to exchange
related information. For example, if two gateways need to IPsec-related information. For example, if two gateways need to
establish an IPsec SA and both are under the control of two establish an IPsec SA and both are under the control of two
different controllers then both Security Controllers need to different controllers, then both Security Controllers need to
exchange information to properly configure their own gateways. exchange information to properly configure their own NSFs. That
That is, the may need to agree on whether IKEv2 authentication is, the may need to agree on whether IKEv2 authentication will be
will be based on raw public keys or pre-shared keys. In case of based on raw public keys, pre-shared keys, etc. In case of using
using pre-shared keys they will have to agree in the PSK. pre-shared keys they will have to agree in the PSK.
5.2. IKE-less case: IPsec (no IKEv2) in the NSF 5.2. IKE-less case: IPsec (no IKEv2) in the NSF.
In this case, the NSF does not deploy IKEv2 and, therefore, the In this case, the NSF does not deploy IKEv2 and, therefore, the
Security Controller has to perform the IKE security functions and Security Controller has to perform the IKE security functions and
management of IPsec SAs by populating and managing the SPD and the management of IPsec SAs by populating and managing the SPD and the
SAD. SAD.
+-----------------------------------------+ +-----------------------------------------+
| IPsec Management Application | Client or | IPsec Management Application | Client or
| I2NSF Client | App Gateway | I2NSF Client | App Gateway
+-----------------------------------------+ +-----------------------------------------+
| Client Facing Interface | Client Facing Interface
+-----------------------------------------+ +-----------------------------------------+
Vendor| Application Support | Vendor| Application Support |
Facing<->|-----------------------------------------| Security Facing<->|-----------------------------------------| Security
Interface| SPD, SAD and PAD Entries Distr. | Controller Interface| SPD, SAD and PAD Entries Distr. | Controller
+-----------------------------------------+ +-----------------------------------------+
| NSF Facing Interface | NSF Facing Interface
+-----------------------------------------+ +-----------------------------------------+
| I2NSF Agent | Network | I2NSF Agent | Network
|-----------------------------------------| Security |-----------------------------------------| Security
| IPsec (SPD,SAD) | Function (NSF) | IPsec (SPD,SAD) | Function (NSF)
|-----------------------------------------| |-----------------------------------------|
| Data Protection and Forwarding | | Data Protection and Forwarding |
+-----------------------------------------+ +-----------------------------------------+
Figure 2: IKE-less case: IPsec (no IKE) in the NSF Figure 2: IKE-less case: IPsec (no IKE) in the NSF
As shown in Figure 2, applications for flow protection run on the top As shown in Figure 2, applications for flow protection run on the top
of the Security Controller. When an administrator enforces flow- of the Security Controller. When an administrator enforces flow-
based protection policies through the Client Facing Interface, the based protection policies through the Client Facing Interface, the
Security Controller translates those requirements into SPD and SAD Security Controller translates these requirements into SPD and SAD
entries, which are installed in the NSF. PAD entries are not entries, which are installed in the NSF. PAD entries are not
required since there is no IKEv2 in the NSF. required since there is no IKEv2 in the NSF.
5.2.1. Interface Requirements for IKE-less case 5.2.1. Interface Requirements for IKE-less case
In order to support the IKE-less case, the following requirements are In order to support the IKE-less case, the following requirements
to be met: need to be met:
o A YANG data model for configuration data for SPD and SAD.
o A YANG data model for state data for SPD and SAD. o A YANG data model for configuration data for SPD and SAD and for
state data for SAD.
o In scenarios where multiple controllers are implicated, SDN-based o In scenarios where multiple controllers are implicated, SDN-based
IPsec management services may require a mechanism to discover IPsec management services may require a mechanism to discover
which Security Controller is managing a specific NSF. Moreover, which Security Controller is managing a specific NSF. Moreover,
an east-west interface [RFC7426] is required to exchange IPsec- an east-west interface [RFC7426] is required to exchange IPsec-
related information. NOTE: A possible east-west protocol for this related information. NOTE: A possible east-west protocol for this
IKE-less case could be IKEv2. However, this needs to be explore IKE-less case could be IKEv2. However, this needs to be explore
since the IKEv2 peers would be the Security Controllers. 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 SDN 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 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 notification from the NSF (i.e. o Rekey of the IPsec SAs based on notifications from the NSF (i.e.
expire). 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). (i.e. sadb-acquire) from the NSF.
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 Controller (non-exhaustive list): performed by the Security Controller (non-exhaustive list):
o 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.3. IKE case vs IKE-less case
IKE case MAY be easier to deploy than IKE-less case because current In principle, IKE case is easier to deploy than IKE-less case because
gateways typically have an IKEv2/IPsec implementation. Moreover current gateways typically have an IKEv2/IPsec implementation.
hosts can install easily an IKE implementation. As downside, the NSF Moreover hosts can install easily an IKE implementation. As
needs more resources to hold IKEv2. Moreover, the IKEv2 downside, the NSF needs more resources to hold IKEv2. Moreover, the
implementation needs to implement an interface so that the I2NSF IKEv2 implementation needs to implement an internal interface so that
Agent can interact with them. the IKE configuration sent by the Security Controller can be enforced
in runtime.
Alternatively, IKE-less case allows lighter NSFs (no IKEv2 Alternatively, IKE-less case allows lighter NSFs (no IKEv2
implementation), which benefits the deployment in constrained NSFs. implementation), which benefits the deployment in constrained NSFs.
Moreover, IKEv2 does not need to be performed in gateway-to-gateway Moreover, IKEv2 does not need to be performed in gateway-to-gateway
and host-to-host scenarios under the same Security Controller (see and host-to-host scenarios under the same Security Controller (see
Section 7.1). On the contrary, the overload of creating fresh IPsec Section 7.1). On the contrary, the overload of creating fresh IPsec
SAs is shifted to the Security Controller since IKEv2 is not in the SAs is shifted to the Security Controller since IKEv2 is not in the
NSF. As a consequence, this may result in a more complex NSF. As a consequence, this may result in a more complex
implementation in the controller side. This overload may create some implementation in the controller side. This overload may create some
scalability issues when the number of NSFs is high. scalability issues when the number of NSFs is high.
In general, literature around SDN-based network management using a In general, literature around SDN-based network management using a
centralized SDN controller is aware about scalability issues and centralized Security Controller is aware about scalability issues and
solutions have been already provided (e.g. hierarchical SDN solutions have been already provided (e.g. hierarchical Security
controllers; having multiple replicated SDN controllers, etc). In Controllers; having multiple replicated Security Controllers, etc).
the context of IPsec management, one straight way to reduce the In the context of SDN-based IPsec management, one straight way to
overhead and the potential scalability issue in the Security reduce the overhead and the potential scalability issue in the
Controller is to apply IKE case, described in this document, since Security Controller is to apply the IKE case described in this
the IPsec SAs are managed between NSFs without the involvement of the document, since the IPsec SAs are managed between NSFs without the
Security Controller at all, except by the initial IKE configuration involvement of the Security Controller at all, except by the initial
provided by the Security Controller. Other option with IKE-less is IKE configuration provided by the Security Controller. Other
to use techniques already seen in SDN world such as, for example, solutions, such as Controller-IKE
hierarchical SDN controllers. Other solutions, such as Controller- [I-D.carrel-ipsecme-controller-ike], have proposed that NSFs provide
IKE [I-D.carrel-ipsecme-controller-ike], have proposed that NSFs their DH public keys to the Security Controller, so that the Security
provide their DH public keys to the Security Controller, so that the Controller distributes all public keys to all peers. All peers can
Security Controller distributes all public keys to all peers. All calculate a unique pairwise secret for each other peer and there is
peers can calculate a unique pairwise secret for each other peer and no inter-NSF messages. A rekey mechanism is further described in
there is no inter-NSF messages. A re-key mechanism is further [I-D.carrel-ipsecme-controller-ike].
described in [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 8. The main than IKE-less case, as we discuss in section Section 9. The main
reason is that the Security Controller is not able to observe any reason is that the NSFs are generating the session keys and not the
session keys generated for the IPsec SAs because IKEv2 is in charge Security Controller.
of negotiating the IPsec SAs.
5.3.1. Rekeying process 5.3.1. Rekeying process.
For IKE case, the rekeying process is carried out by IKEv2, following For IKE case, the rekeying process is carried out by IKEv2, following
the information defined in the SPD and SAD. 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.
For IKE-less case, the Security Controller needs to take care of the Traditionally, during a rekey process of the IPSec SA using IKE, a
rekeying process. When the IPsec SA is going to expire (e.g. IPsec bundle of inbound and outbound IPsec SAs is taken into account from
SA soft lifetime), it has to create a new IPsec SA and remove the old the perspective of one of the NSFs. For example, if the inbound
one. This rekeying process starts when the Security Controller IPsec SA expires both the inbound and outbound IPsec SA are rekeyed
receives a sadb_expire notification or it decides so, based on at the same time in that NSF. However, when IKE is not used, we have
lifetime state data obtained from the NSF. 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 peers A and B, let To explain the rekeying process between two IPsec peers A and B, let
assume that SPIa1 identifies the inbound SA in A and SPIb1 the assume that SPIa1 identifies the inbound IPsec SA in A, and SPIb1 the
inbound SA in B. inbound IPsec SA in B.
1. The Security Controller chooses two random values as SPI for the 1. The Security Controller chooses two random values as SPI for the
new inbound SAs: for example, SPIa2 for A and SPIb2 for B. These new inbound IPsec SAs: for example, SPIa2 for A and SPIb2 for B.
numbers MUST not be in conflict with any IPsec SA in A or 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
Then, the Security Controller creates an inbound SA with SPIa2 in with SPIa2 in A and another inbound IPsec SA in B with SPIb2. It
A and another inbound SA in B with SPIb2. It can send this can send this information simultaneously to A and B.
information simultaneously to A and B.
2. Once the Security Controller receives confirmation from A and B, 2. Once the Security Controller receives confirmation from A and B,
inbound SA are correctly installed. Then it proceeds to send in the controller knows that the inbound IPsec A are correctly
parallel to A and B the outbound SAs: it sends the outbound SA to installed. Then it proceeds to send in parallel to A and B, the
A with SPIb2 and the outbound SA to B with SPIa2. At this point outbound IPsec SAs: it sends the outbound IPsec SA to A with
the new IPsec SA is ready. 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, 3. Once the Security Controller receives confirmation from A and B
that the outbound SAs have been installed, the Security that the outbound IPsec SAs have been installed, the Security
Controller deletes the old IPsec SAs from A (inbound SPIa1 and Controller, in parallel, deletes the old IPsec SAs from A
outbound SPIb1) and B (outbound SPIa1 and inbound SPIb1) in (inbound SPIa1 and outbound SPIb1) and B (outbound SPIa1 and
parallel. It is worth noting that if the IPsec implementation inbound SPIb1).
can itself detect traffic on the new IPsec SA, and it can delete
the old IPsec SA itself without instruction from the Security
Controller, then this step 3 is not required.
5.3.2. NSF state loss 5.3.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 Security Controller can assume that all the
state has been lost and therefore it will have to send IKEv2, SPD and state has been lost and therefore it will have to send IKEv2, SPD and
PAD information to the NSF in IKE case, and SPD and SAD information PAD information to the NSF in the IKE case, and SPD and SAD
in IKE-less case. information in IKE-less case.
In both cases, the Security Controller is aware of the affected NSF In both cases, the Security 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 Security Controller is receiving sadb-bad-spi notification from a
particular NSF, etc.). Moreover, the Security Controller has a particular NSF, etc.). Moreover, the Security Controller has a
register about all the NSFs that have IPsec SAs with the affected register about all the NSFs that have IPsec SAs with the affected
NSF. Therefore, it knows the affected IPsec SAs. NSF. Therefore, it knows the affected IPsec SAs.
In IKE case, the Security Controller will configure the affected NSF In IKE case, the Security 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. It can which have IKEv2 SAs and IPsec SAs with the affected NSF. Finally,
also instruct the affected NSF to send IKEv2 INITIAL_CONTACT. the Security Controller will instruct the affected NSF to start the
Finally, the Security Controller will instruct the affected NSF to IKEv2 negotiation with the new configuration.
start the IKEv2 negotiation with the new configuration.
In IKE-less case, if the Security Controller detects that a NSF has In IKE-less case, if the Security Controller detects that a NSF has
lost the IPsec SAs (e.g. it reboots) it will delete the old IPsec SAs lost the IPsec SAs it will delete the old IPsec SAs on the non-failed
of the non-failed nodes established with the failed node (step 1). nodes, established with the failed node (step 1). This prevents the
This prevents the non-failed nodes from leaking plaintext. If the non-failed nodes from leaking plaintext. If the affected node comes
failed node comes to live, the Security Controller will configure the to live, the Security Controller will configure the new inbound IPsec
new inbound IPsec SAs between the failed node and all the nodes the SAs between the affected node and all the nodes it was talking to
failed was talking to (step 2). After these inbound IPsec SAs have (step 2). After these inbound IPsec SAs have been established, the
been established, the Security Controller can configure the outbound Security Controller can configure the outbound IPsec SAs in parallel
IPsec SAs (step 3). (step 3).
Nevertheless other more optimized options can be considered (e.g. Nevertheless other more optimized options can be considered (e.g.
making IKEv2 configuration permanent between reboots). making the IKEv2 configuration permanent between reboots).
5.3.3. NAT Traversal 5.3.3. NAT Traversal
In IKE case, IKEv2 already owns a mechanism to detect whether some of In the IKE case, IKEv2 already provides a mechanism to detect whether
the peers or both are located behind a NAT. If there is a NAT some of the peers or both are located behind a NAT. If there is a
network configured between two peers, it is required to activate the NAT network configured between two peers, it is required to activate
usage of UDP or TCP/TLS encapsulation of ESP packets ([RFC3948], the usage of UDP or TCP/TLS encapsulation for ESP packets ([RFC3948],
[RFC8229]). Note that the usage of TRANSPORT mode when NAT is [RFC8229]). Note that the usage of IPsec transport mode when NAT is
required is forbidden in this specification. required MUST NOT be used in this specification.
On the contrary, IKE-less case does not have any protocol in the NSFs On the contrary, the IKE-less case does not have any protocol in the
to detect whether they are located behind a NAT or not. However, the NSFs to detect whether they are located behind a NAT or not.
SDN paradigm generally assumes the Security Controller has a view of However, the SDN paradigm generally assumes the Security Controller
the network it controls. This view is built either requesting has a view of the network under its control. This view is built
information to the NSFs under its control, or because these NSFs either requesting information to the NSFs under its control, or
inform to the Security Controller. Based on this information, the because these NSFs inform the Security Controller. Based on this
Security Controller can guess if there is a NAT configured between information, the Security Controller can guess if there is a NAT
two hosts, and apply the required policies to both NSFs besides configured between two hosts, and apply the required policies to both
activating the usage of UDP or TCP/TLS encapsulation of ESP packets NSFs besides activating the usage of UDP or TCP/TLS encapsulation of
([RFC3948], [RFC8229]). ESP packets ([RFC3948], [RFC8229]).
For example, the Security Controller could directly request the NSF For example, the Security Controller could directly request the NSF
for specific data such as networking configuration, NAT support, etc. for specific data such as networking configuration, NAT support, etc.
Protocols such as NETCONF or SNMP can be used here. For example, RFC Protocols such as NETCONF or SNMP can be used here. For example, RFC
7317 [RFC7317] provides a YANG data model for system management or 7317 [RFC7317] provides a YANG data model for system management or
[I-D.ietf-opsawg-nat-yang] a data model for NAT management. The [I-D.ietf-opsawg-nat-yang] a data model for NAT management. The
Security Controller can use this NETCONF module with a gateway to Security Controller can use this NETCONF module with a NSF to collect
collect NAT information or even configure a NAT. In any case, if NAT information or even configure a NAT network. In any case, if
this NETCONF module is not available and the Security Controller this NETCONF module is not available in the NSF and the Security
cannot know if a host is behind a NAT or not, then IKE case should be Controller does not have a mechanism to know whether a host is behind
the right choice and not the IKE-less. a NAT or not, then the IKE case should be the right choice and not
the IKE-less case.
5.3.4. NSF Discovery
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
Controller. In this way, when the NSF comes to live and establishes
a connection to the Security Controller, it knows that the NSF is
valid for joining the system.
Either during this registration process or when the NSF connects with
the Security Controller, the Security Controller MUST discover
certain capabilities of this NSF, such as what is the cryptographic
suite supported, authentication method, the support of the IKE case
or the IKE-less case, etc. This discovery process is out of the
scope of this document.
6. YANG configuration data models 6. YANG configuration data models
In order to support IKE case and IKE-less case we have modelled 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, IKE requires modeling IKEv2, SPD and PAD,
while IKE-less case requires configuration models for the SPD and while IKE-less case requires configuration models for the SPD and
SAD. We have defined three models: ietf-ipsec-common (Appendix A), SAD. We have defined three models: ietf-ipsec-common (Appendix A),
ietf-ipsec-ike (Appendix B, IKE case), ietf-ipsec-ikeless ietf-ipsec-ike (Appendix B, IKE case), ietf-ipsec-ikeless
(Appendix C, IKE-less case). Since the model ietf-ipsec-common has (Appendix C, IKE-less case). Since the model ietf-ipsec-common has
only typedef and groupings common to the other modules, in the only typedef and groupings common to the other modules, we only show
following we only show a simplified view of the ietf-ipsec-ike and a simplified view of the ietf-ipsec-ike and ietf-ipsec-ikeless
ietf-ipsec-ikeless models. 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 or Libreswan. implementations, such as Strongswan [strongswan] or Libreswan
[libreswan].
The definition of the PAD model has been extracted from the The definition of the PAD model has been extracted from the
specification in section 4.4.3 in [RFC4301] (NOTE: We have observed specification in section 4.4.3 in [RFC4301] (NOTE: We have observed
that many implementations integrate PAD configuration as part of the that many implementations integrate PAD configuration as part of the
IKEv2 configuration.) IKEv2 configuration).
module: ietf-ipsec-ike module: ietf-ipsec-ike
+--rw ikev2 +--rw ipsec-ike
+--rw pad +--rw pad
| +--rw pad-entry* [pad-entry-id] | +--rw pad-entry* [name]
| +--rw pad-entry-id uint64 | +--rw name string
| +--rw (identity)? | +--rw (identity)
| | +--:(ipv4-address) | | +--:(ipv4-address)
| | | +--rw ipv4-address? inet:ipv4-address | | | +--rw ipv4-address? inet:ipv4-address
| | +--:(ipv6-address) | | +--:(ipv6-address)
| | | +--rw ipv6-address? inet:ipv6-address | | | +--rw ipv6-address? inet:ipv6-address
| | +--:(fqdn-string) | | +--:(fqdn-string)
| | | +--rw fqdn-string? inet:domain-name | | | +--rw fqdn-string? inet:domain-name
| | +--:(rfc822-address-string) | | +--:(rfc822-address-string)
| | | +--rw rfc822-address-string? string | | | +--rw rfc822-address-string? string
| | +--:(dnX509) | | +--:(dnx509)
| | | +--rw dnX509? string | | | +--rw dnx509? string
| | +--:(id_key) | | +--:(gnx509)
| | | +--rw id_key? string | | | +--rw gnx509? string
| | +--:(id_null) | | +--:(id-key)
| | | +--rw id_null? empty | | | +--rw id-key? string
| | +--:(user_fqdn) | | +--:(id-null)
| | +--rw user_fqdn? string | | +--rw id-null? empty
| +--rw my-identifier string | +--rw auth-protocol? auth-protocol-type
| +--rw pad-auth-protocol? auth-protocol-type | +--rw peer-authentication
| +--rw auth-method | +--rw auth-method? auth-method-type
| +--rw auth-m? auth-method-type
| +--rw eap-method | +--rw eap-method
| | +--rw eap-type? uint8 | | +--rw eap-type uint8
| +--rw pre-shared | +--rw pre-shared
| | +--rw secret? yang:hex-string | | +--rw secret? yang:hex-string
| +--rw digital-signature | +--rw digital-signature
| +--rw ds-algorithm? signature-algorithm-t | +--rw ds-algorithm? uint8
| +--rw raw-public-key? yang:hex-string | +--rw (public-key)
| +--rw key-data? string | | +--:(raw-public-key)
| +--rw key-file? string | | | +--rw raw-public-key? binary
| +--rw ca-data* string | | +--:(cert-data)
| +--rw ca-file? string | | +--rw cert-data? ct:x509
| +--rw cert-data? string | +--rw private-key? binary
| +--rw cert-file? string | +--rw ca-data* ct:x509
| +--rw crl-data? string | +--rw crl-data? ct:crl
| +--rw crl-file? string | +--rw crl-uri? inet:uri
| +--rw oscp-uri? inet:uri | +--rw oscp-uri? inet:uri
+--rw ike-conn-entry* [conn-name] +--rw conn-entry* [name]
| +--rw conn-name string | +--rw name string
| +--rw autostartup type-autostartup | +--rw autostartup? autostartup-type
| +--rw initial-contact? boolean | +--rw initial-contact? boolean
| +--rw version? enumeration | +--rw version? auth-protocol-type
| +--rw ike-fragmentation? boolean | +--rw fragmentation? boolean
| +--rw ike-sa-lifetime-hard
| | +--rw time? yang:timestamp
| | +--rw idle? yang:timestamp
| | +--rw bytes? uint32
| | +--rw packets? uint32
| +--rw ike-sa-lifetime-soft | +--rw ike-sa-lifetime-soft
| | +--rw time? yang:timestamp | | +--rw rekey-time? uint32
| | +--rw idle? yang:timestamp | | +--rw reauth-time? uint32
| | +--rw bytes? uint32 | +--rw ike-sa-lifetime-hard
| | +--rw packets? uint32 | | +--rw over-time? uint32
| | +--rw action? ic:lifetime-action | +--rw authalg* ic:integrity-algorithm-type
| +--rw ike-sa-authalg* ic:integrity-algorithm-t | +--rw encalg* ic:encryption-algorithm-type
| +--rw ike-sa-encalg* ic:encryption-algorithm-t | +--rw dh-group? pfs-group
| +--rw dh_group uint32
| +--rw half-open-ike-sa-timer? uint32 | +--rw half-open-ike-sa-timer? uint32
| +--rw half-open-ike-sa-cookie-threshold? uint32 | +--rw half-open-ike-sa-cookie-threshold? uint32
| +--rw local | +--rw local
| | +--rw local-pad-id? uint64 | | +--rw local-pad-entry-name? string
| +--rw remote | +--rw remote
| | +--rw remote-pad-id? uint64 | | +--rw remote-pad-entry-name? string
| +--rw espencap? esp-encap | +--rw encapsulation-type
| +--rw sport? inet:port-number | | +--rw espencap? esp-encap
| +--rw dport? inet:port-number | | +--rw sport? inet:port-number
| +--rw oaddr* inet:ip-address | | +--rw dport? inet:port-number
| | +--rw oaddr* inet:ip-address
| +--rw spd | +--rw spd
| | +--rw spd-entry* [spd-entry-id] | | +--rw spd-entry* [name]
| | +--rw spd-entry-id uint64 | | +--rw name string
| | +--rw priority? uint32 | | +--rw ipsec-policy-config
| | +--rw anti-replay-window? uint16 | | +--rw anti-replay-window? uint64
| | +--rw names* [name] | | +--rw traffic-selector
| | | +--rw name-type? ipsec-spd-name | | | +--rw local-subnet inet:ip-prefix
| | | +--rw name string | | | +--rw remote-subnet inet:ip-prefix
| | +--rw condition | | | +--rw inner-protocol? ipsec-inner-protocol
| | | +--rw traffic-selector-list* [ts-number] | | | +--rw local-ports* [start end]
| | | +--rw ts-number uint32 | | | | +--rw start inet:port-number
| | | +--rw direction? ipsec-traffic-direction | | | | +--rw end inet:port-number
| | | +--rw local-subnet? inet:ip-prefix | | | +--rw remote-ports* [start end]
| | | +--rw remote-subnet? inet:ip-prefix | | | +--rw start inet:port-number
| | | +--rw upper-layer-protocol* ipsec-upper-layer-proto | | | +--rw end inet:port-number
| | | +--rw local-ports* [start end] | | +--rw processing-info
| | | | +--rw start inet:port-number | | | +--rw action? ipsec-spd-action
| | | | +--rw end inet:port-number | | | +--rw ipsec-sa-cfg
| | | +--rw remote-ports* [start end] | | | +--rw pfp-flag? boolean
| | | +--rw start inet:port-number | | | +--rw ext-seq-num? boolean
| | | +--rw end inet:port-number | | | +--rw seq-overflow? boolean
| | +--rw processing-info | | | +--rw stateful-frag-check? boolean
| | | +--rw action ipsec-spd-operation | | | +--rw mode? ipsec-mode
| | | +--rw ipsec-sa-cfg | | | +--rw protocol-parameters? ipsec-protocol-parameters
| | | +--rw pfp-flag? boolean | | | +--rw esp-algorithms
| | | +--rw extSeqNum? boolean | | | | +--rw integrity* integrity-algorithm-type
| | | +--rw seqOverflow? boolean | | | | +--rw encryption* encryption-algorithm-type
| | | +--rw statefulfragCheck? boolean | | | | +--rw tfc-pad? boolean
| | | +--rw security-protocol? ipsec-protocol | | | +--rw tunnel
| | | +--rw mode? ipsec-mode | | | +--rw local inet:ip-address
| | | +--rw ah-algorithms | | | +--rw remote inet:ip-address
| | | | +--rw ah-algorithm* integrity-algorithm-t | | | +--rw df-bit? enumeration
| | | | +--rw trunc-length? uint32 | | | +--rw bypass-dscp? boolean
| | | +--rw esp-algorithms | | | +--rw dscp-mapping? yang:hex-string
| | | | +--rw authentication* integrity-algorithm-t | | | +--rw ecn? boolean
| | | | +--rw encryption* encryption-algorithm-t | | +--rw spd-mark
| | | | +--rw tfc_pad? uint32 | | +--rw mark? uint32
| | | +--rw tunnel | | +--rw mask? yang:hex-string
| | | +--rw local? inet:ip-address | +--rw child-sa-info
| | | +--rw remote? inet:ip-address | | +--rw pfs-groups* pfs-group
| | | +--rw bypass-df? boolean | | +--rw child-sa-lifetime-soft
| | | +--rw bypass-dscp? boolean | | | +--rw time? uint32
| | | +--rw dscp-mapping? yang:hex-string | | | +--rw bytes? uint32
| | | +--rw ecn? boolean | | | +--rw packets? uint32
| | +--rw spd-lifetime-soft | | | +--rw idle? uint32
| | | +--rw time? yang:timestamp | | | +--rw action? ic:lifetime-action
| | | +--rw idle? yang:timestamp | | +--rw child-sa-lifetime-hard
| | | +--rw bytes? uint32 | | +--rw time? uint32
| | | +--rw packets? uint32 | | +--rw bytes? uint32
| | | +--rw action? lifetime-action | | +--rw packets? uint32
| | +--rw spd-lifetime-hard | | +--rw idle? uint32
| | | +--rw time? yang:timestamp | +--ro state
| | | +--rw idle? yang:timestamp
| | | +--rw bytes? uint32
| | | +--rw packets? uint32
| | +--ro spd-lifetime-current
| | +--ro time? yang:timestamp
| | +--ro idle? yang:timestamp
| | +--ro bytes? uint32
| | +--ro packets? uint32
| +--ro ike-sa-state
| +--ro uptime
| | +--ro running? yang:date-and-time
| | +--ro since? yang:date-and-time
| +--ro initiator? boolean | +--ro initiator? boolean
| +--ro initiator-ikesa-spi? uint64 | +--ro initiator-ikesa-spi? ike-spi
| +--ro responder-ikesa-spi? uint64 | +--ro responder-ikesa-spi? ike-spi
| +--ro nat-local? boolean | +--ro nat-local? boolean
| +--ro nat-remote? boolean | +--ro nat-remote? boolean
| +--ro nat-any? boolean | +--ro encapsulation-type
| +--ro espencap? esp-encap | | +--ro espencap? esp-encap
| +--ro sport? inet:port-number | | +--ro sport? inet:port-number
| +--ro dport? inet:port-number | | +--ro dport? inet:port-number
| +--ro oaddr* inet:ip-address | | +--ro oaddr* inet:ip-address
| +--ro established? uint64 | +--ro established? uint64
| +--ro rekey-time? uint64 | +--ro current-rekey-time? uint64
| +--ro reauth-time? uint64 | +--ro current-reauth-time? uint64
| +--ro child-sas* []
| +--ro spis
| +--ro spi-in? ic:ipsec-spi
| +--ro spi-out? ic:ipsec-spi
+--ro number-ike-sas +--ro number-ike-sas
+--ro total? uint32 +--ro total? uint64
+--ro half-open? uint32 +--ro half-open? uint64
+--ro half-open-cookies? uint32 +--ro half-open-cookies? uint64
Appendix D shows an example of IKE case configuration for a NSF, in
tunnel mode (gateway-to-gateway), with NSFs authentication based on
X.509 certificates.
6.2. IKE-less case model 6.2. IKE-less case model
The definition of the SPD model has been mainly extracted from the For this case, the definition of the SPD model has been mainly
specification in section 4.4.1 and Appendix D in [RFC4301]. Unlike extracted from the specification in section 4.4.1 and Appendix D in
existing implementations (e.g. XFRM), it is worth mentioning that [RFC4301], though with some simplications. For example, each IPsec
this model follows [RFC4301] and, consequently, each policy (spd- policy (spd-entry) contains one traffic selector, instead a list of
entry) consists of one or more traffic selectors. 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 The definition of the SAD model has been extracted from the
specification in section 4.4.2 in [RFC4301]. Note that this model specification in section 4.4.2 in [RFC4301]. Note that this model
not only associates an IPsec SA with its corresponding policy (spd- not only allows to associate an IPsec SA with its corresponding
entry-id) but also indicates the specific traffic selector that policy through the specific traffic selector but also an identifier
caused its establishment. In other words, each traffic selector of a (reqid).
policy (spd-entry) generates a different IPsec SA (sad-entry).
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 ietf-ipsec +--rw ipsec-ikeless
+--rw spd +--rw spd
| +--rw spd-entry* [spd-entry-id] | +--rw spd-entry* [name]
| +--rw spd-entry-id uint64 | +--rw name string
| +--rw priority? uint32 | +--rw direction? ic:ipsec-traffic-direction
| +--rw anti-replay-window? uint16 | +--rw reqid? uint64
| +--rw names* [name] | +--rw ipsec-policy-config
| | +--rw name-type? ipsec-spd-name | +--rw anti-replay-window? uint64
| | +--rw name string | +--rw traffic-selector
| +--rw condition | | +--rw local-subnet inet:ip-prefix
| | +--rw traffic-selector-list* [ts-number] | | +--rw remote-subnet inet:ip-prefix
| | +--rw ts-number uint32 | | +--rw inner-protocol? ipsec-inner-protocol
| | +--rw direction? ipsec-traffic-direction | | +--rw local-ports* [start end]
| | +--rw local-subnet? inet:ip-prefix | | | +--rw start inet:port-number
| | +--rw remote-subnet? inet:ip-prefix | | | +--rw end inet:port-number
| | +--rw upper-layer-protocol* ipsec-upper-layer-proto | | +--rw remote-ports* [start end]
| | +--rw local-ports* [start end] | | +--rw start inet:port-number
| | | +--rw start inet:port-number | | +--rw end inet:port-number
| | | +--rw end inet:port-number | +--rw processing-info
| | +--rw remote-ports* [start end] | | +--rw action? ipsec-spd-action
| | +--rw start inet:port-number | | +--rw ipsec-sa-cfg
| | +--rw end inet:port-number | | +--rw pfp-flag? boolean
| +--rw processing-info | | +--rw ext-seq-num? boolean
| | +--rw action ipsec-spd-operation | | +--rw seq-overflow? boolean
| | +--rw ipsec-sa-cfg | | +--rw stateful-frag-check? boolean
| | +--rw pfp-flag? boolean | | +--rw mode? ipsec-mode
| | +--rw extSeqNum? boolean | | +--rw protocol-parameters?
| | +--rw seqOverflow? boolean | | +--rw esp-algorithms
| | +--rw statefulfragCheck? boolean | | | +--rw integrity* integrity-algorithm-type
| | +--rw security-protocol? ipsec-protocol | | | +--rw encryption* encryption-algorithm-type
| | +--rw mode? ipsec-mode | | | +--rw tfc-pad? boolean
| | +--rw ah-algorithms | | +--rw tunnel
| | | +--rw ah-algorithm* integrity-algorithm-t | | +--rw local inet:ip-address
| | | +--rw trunc-length? uint32 | | +--rw remote inet:ip-address
| | +--rw esp-algorithms | | +--rw df-bit? enumeration
| | | +--rw authentication* integrity-algorithm-t | | +--rw bypass-dscp? boolean
| | | +--rw encryption* encryption-algorithm-t | | +--rw dscp-mapping? yang:hex-string
| | | +--rw tfc_pad? uint32 | | +--rw ecn? boolean
| | +--rw tunnel | +--rw spd-mark
| | +--rw local? inet:ip-address | +--rw mark? uint32
| | +--rw remote? inet:ip-address | +--rw mask? yang:hex-string
| | +--rw bypass-df? boolean
| | +--rw bypass-dscp? boolean
| | +--rw dscp-mapping? yang:hex-string
| | +--rw ecn? boolean
| +--rw spd-lifetime-soft
| | +--rw time? yang:timestamp
| | +--rw idle? yang:timestamp
| | +--rw bytes? uint32
| | +--rw packets? uint32
| | +--rw action? lifetime-action
| +--rw spd-lifetime-hard
| | +--rw time? yang:timestamp
| | +--rw idle? yang:timestamp
| | +--rw bytes? uint32
| | +--rw packets? uint32
| +--ro spd-lifetime-current
| +--ro time? yang:timestamp
| +--ro idle? yang:timestamp
| +--ro bytes? uint32
| +--ro packets? uint32
+--rw sad +--rw sad
+--rw sad-entry* [sad-entry-id] +--rw sad-entry* [name]
+--rw sad-entry-id uint64 +--rw name string
+--rw spi? ic:ipsec-spi +--rw reqid? uint64
+--rw seq-number? uint64 +--rw ipsec-sa-config
+--rw seq-number-overflow-flag? boolean | +--rw spi uint32
+--rw anti-replay-window? uint16 | +--rw ext-seq-num? boolean
+--rw spd-entry-id? uint64 | +--rw seq-number-counter? uint64
+--rw local-subnet? inet:ip-prefix | +--rw seq-overflow? boolean
+--rw remote-subnet? inet:ip-prefix | +--rw anti-replay-window? uint32
+--rw upper-layer-protocol* ipsec-upper-layer-proto | +--rw traffic-selector
+--rw local-ports* [start end] | | +--rw local-subnet inet:ip-prefix
| +--rw start inet:port-number | | +--rw remote-subnet inet:ip-prefix
| +--rw end inet:port-number | | +--rw inner-protocol? ipsec-inner-protocol
+--rw remote-ports* [start end] | | +--rw local-ports* [start end]
| +--rw start inet:port-number | | | +--rw start inet:port-number
| +--rw end inet:port-number | | | +--rw end inet:port-number
+--rw security-protocol? ic:ipsec-protocol | | +--rw remote-ports* [start end]
+--rw sad-lifetime-hard | | +--rw start inet:port-number
| +--rw time? yang:timestamp | | +--rw end inet:port-number
| +--rw idle? yang:timestamp | +--rw protocol-parameters? ic:ipsec-protocol-parameters
| +--rw bytes? uint32 | +--rw mode? ic:ipsec-mode
| +--rw packets? uint32 | +--rw esp-sa
+--rw sad-lifetime-soft | | +--rw encryption
| +--rw time? yang:timestamp | | | +--rw encryption-algorithm? ic:encryption-algorithm-type
| +--rw idle? yang:timestamp | | | +--rw key? yang:hex-string
| +--rw bytes? uint32 | | | +--rw iv? yang:hex-string
| +--rw packets? uint32 | | +--rw integrity
| +--rw action? ic:lifetime-action | | +--rw integrity-algorithm? ic:integrity-algorithm-type
+--rw mode? ic:ipsec-mode | | +--rw key? yang:hex-string
+--rw statefulfragCheck? boolean | +--rw sa-lifetime-hard
+--rw dscp? yang:hex-string | | +--rw time? uint32
+--rw path-mtu? uint16 | | +--rw bytes? uint32
+--rw tunnel | | +--rw packets? uint32
| +--rw local? inet:ip-address | | +--rw idle? uint32
| +--rw remote? inet:ip-address | +--rw sa-lifetime-soft
| +--rw bypass-df? boolean | | +--rw time? uint32
| +--rw bypass-dscp? boolean | | +--rw bytes? uint32
| +--rw dscp-mapping? yang:hex-string | | +--rw packets? uint32
| +--rw ecn? boolean | | +--rw idle? uint32
+--rw espencap? esp-encap | | +--rw action? ic:lifetime-action
+--rw sport? inet:port-number | +--rw tunnel
+--rw dport? inet:port-number | | +--rw local inet:ip-address
+--rw oaddr* inet:ip-address | | +--rw remote inet:ip-address
+--ro sad-lifetime-current | | +--rw df-bit? enumeration
| +--ro time? yang:timestamp | | +--rw bypass-dscp? boolean
| +--ro idle? yang:timestamp | | +--rw dscp-mapping? yang:hex-string
| +--ro bytes? uint32 | | +--rw ecn? boolean
| +--ro packets? uint32 | +--rw encapsulation-type
+--ro stats | +--rw espencap? esp-encap
| +--ro replay-window? uint32 | +--rw sport? inet:port-number
| +--ro replay? uint32 | +--rw dport? inet:port-number
| +--ro failed? uint32 | +--rw oaddr* inet:ip-address
+--ro replay_state +--ro ipsec-sa-state
| +--ro seq? uint32 +--ro sa-lifetime-current
| +--ro oseq? uint32 | +--ro time? uint32
| +--ro bitmap? uint32 | +--ro bytes? uint32
+--ro replay_state_esn | +--ro packets? uint32
| +--ro bmp-len? uint32 | +--ro idle? uint32
| +--ro oseq? uint32 +--ro replay-stats
| +--ro oseq-hi? uint32 +--ro replay-window? uint64
| +--ro seq-hi? uint32 +--ro packet-dropped? uint64
| +--ro replay-window? uint32 +--ro failed? uint32
| +--ro bmp* uint32 +--ro seq-number-counter? uint64
+--rw ah-sa
| +--rw integrity
| +--rw integrity-algorithm? ic:integrity-algorithm-t
| +--rw key? string
+--rw esp-sa
+--rw encryption
| +--rw encryption-algorithm? ic:encryption-algorithm-t
| +--rw key? yang:hex-string
| +--rw iv? yang:hex-string
+--rw integrity
| +--rw integrity-algorithm? ic:integrity-algorithm-t
| +--rw key? yang:hex-string
+--rw combined-enc-intr? boolean
notifications: notifications:
+---n spdb_expire +---n sadb-acquire
| +--ro index? uint64 | +--ro ipsec-policy-name string
+---n sadb_acquire | +--ro traffic-selector
| +--ro base-list* [version] | +--ro local-subnet inet:ip-prefix
| | +--ro version string | +--ro remote-subnet inet:ip-prefix
| | +--ro msg_type? sadb-msg-type | +--ro inner-protocol? ipsec-inner-protocol
| | +--ro msg_satype? sadb-msg-satype | +--ro local-ports* [start end]
| | +--ro msg_seq? uint32 | | +--ro start inet:port-number
| +--ro local-subnet? inet:ip-prefix | | +--ro end inet:port-number
| +--ro remote-subnet? inet:ip-prefix | +--ro remote-ports* [start end]
| +--ro upper-layer-protocol* ipsec-upper-layer-proto | +--ro start inet:port-number
| +--ro local-ports* [start end] | +--ro end inet:port-number
| | +--ro start inet:port-number +---n sadb-expire
| | +--ro end inet:port-number | +--ro ipsec-sa-name string
| +--ro remote-ports* [start end] | +--ro soft-lifetime-expire? boolean
| +--ro start inet:port-number | +--ro lifetime-current
| +--ro end inet:port-number | +--ro time? uint32
+---n sadb_expire
| +--ro base-list* [version]
| | +--ro version string
| | +--ro msg_type? sadb-msg-type
| | +--ro msg_satype? sadb-msg-satype
| | +--ro msg_seq? uint32
| +--ro spi? ic:ipsec-spi
| +--ro anti-replay-window? uint16
| +--ro encryption-algorithm? ic:encryption-algorithm-t
| +--ro authentication-algorithm? ic:integrity-algorithm-t
| +--ro sad-lifetime-hard
| | +--ro time? yang:timestamp
| | +--ro idle? yang:timestamp
| | +--ro bytes? uint32
| | +--ro packets? uint32
| +--ro sad-lifetime-soft
| | +--ro time? yang:timestamp
| | +--ro idle? yang:timestamp
| | +--ro bytes? uint32
| | +--ro packets? uint32
| +--ro sad-lifetime-current
| +--ro time? yang:timestamp
| +--ro idle? yang:timestamp
| +--ro bytes? uint32 | +--ro bytes? uint32
| +--ro packets? uint32 | +--ro packets? uint32
+---n sadb_bad-spi | +--ro idle? uint32
+--ro state ic:ipsec-spi +---n sadb-seq-overflow
| +--ro ipsec-sa-name string
+---n sadb-bad-spi
+--ro spi uint32
Appendix E shows an example of IKE-less case configuration for a NSF,
in transport mode (host-to-host), with NSFs authentication based on
shared secrets. For the IKE-less case, Appendix F shows examples of
IPsec SA expire, acquire, sequence number overflow and bad SPI
notifications.
7. Use cases examples 7. Use cases examples
This section explains how different traditional configurations, that This section explains how different traditional configurations, that
is, host-to-host and gateway-to-gateway are deployed using this SDN- is, host-to-host and gateway-to-gateway, are deployed using this SDN-
based IPsec management service. In turn, these configurations will based IPsec management service. In turn, these configurations will
be typical in modern networks where, for example, virtualization will be typical in modern networks where, for example, virtualization will
be key. be key.
7.1. Host-to-host or gateway-to-gateway under the same controller 7.1. Host-to-host or gateway-to-gateway under the same Security
Controller
+----------------------------------------+ +----------------------------------------+
| Security Controller | | Security Controller |
| | | |
(1)| +--------------+ (2)+--------------+ | (1)| +--------------+ (2)+--------------+ |
Flow-based ------> |Translate into|--->| South. Prot. | | Flow-based ------> |Translate into|--->| South. Prot. | |
Security. Pol. | |IPsec Policies| | | | Security. Pol. | |IPsec Policies| | | |
| +--------------+ +--------------+ | | +--------------+ +--------------+ |
| | | | | | | |
| | | | | | | |
+--------------------------|-----|-------+ +--------------------------|-----|-------+
| | | |
| (3) | | (3) |
|-------------------------+ +---| |-------------------------+ +---|
V V V V
+----------------------+ +----------------------+ +----------------------+ +----------------------+
| NSF1 |<=======>| NSF2 | | NSF1 |<=======>| NSF2 |
|IKEv2/IPsec(SPD/PAD) | |IKEv2/IPsec(SPD/PAD) | |IKEv2/IPsec(SPD/PAD) | |IKEv2/IPsec(SPD/PAD) |
+----------------------+ (4) +----------------------+ +----------------------+ (4) +----------------------+
Figure 3: Host-to-host / gateway-to-gateway single controller flow Figure 3: Host-to-host / gateway-to-gateway single Security
for the IKE case. Controller for the IKE case.
Figure 3 describes the case IKE case: Figure 3 describes the IKE case:
1. The administrator defines general flow-based security policies. 1. The administrator defines general flow-based security policies.
The Security Controller looks for the NSFs involved (NSF1 and The Security Controller looks for the NSFs involved (NSF1 and
NSF2). NSF2).
2. The Security Controller generates IKEv2 credentials for them and 2. The Security Controller generates IKEv2 credentials for them and
translates the policies into SPD and PAD entries. translates the policies into SPD and PAD entries.
3. The Security Controller inserts the SPD and PAD entries in both 3. The Security Controller inserts an IKEv2 configuration that
NSF1 and NSF2. include the SPD and PAD entries in both NSF1 and NSF2.
4. The flow is protected with the IPsec SA established with IKEv2. 4. The flow is protected by means of the IPsec SA established with
IKEv2.
+----------------------------------------+ +----------------------------------------+
| (1) Security Controller | | (1) Security Controller |
Flow-based | | Flow-based | |
Security -----------| | Security -----------| |
Policy | V | Policy | V |
| +---------------+ (2)+-------------+ | | +---------------+ (2)+-------------+ |
| |Translate into |--->| South. Prot.| | | |Translate into |--->| South. Prot.| |
| |IPsec policies | | | | | |IPsec policies | | | |
| +---------------+ +-------------+ | | +---------------+ +-------------+ |
skipping to change at page 22, line 26 skipping to change at page 21, line 26
+-------------------------| --- |--------+ +-------------------------| --- |--------+
| | | |
| (3) | | (3) |
|----------------------+ +--| |----------------------+ +--|
V V V V
+------------------+ +------------------+ +------------------+ +------------------+
| NSF1 |<=====>| NSF2 | | NSF1 |<=====>| NSF2 |
|IPsec(SPD/SAD) | 4) |IPsec(SPD/SAD) | |IPsec(SPD/SAD) | 4) |IPsec(SPD/SAD) |
+------------------+ +------------------+ +------------------+ +------------------+
Figure 4: Host-to-host / gateway-to-gateway single controller flow Figure 4: Host-to-host / gateway-to-gateway single Security
for IKE-less case. Controller for IKE-less case.
In IKE-less case, flow-based security policies defined by the In the IKE-less case, flow-based security policies defined by the
administrator are translated into IPsec SPD entries and inserted into administrator are translated into IPsec SPD entries and inserted into
the corresponding NSFs. Besides, fresh SAD entries will be also the corresponding NSFs. Besides, fresh SAD entries will be also
generated by the Security Controller and enforced in the NSFs. In generated by the Security Controller and enforced in the NSFs. In
this case, the controller does not run any IKEv2 implementation, and this case, the Security Controller does not run any IKEv2
it provides the cryptographic material for the IPsec SAs. These keys implementation (neither the NSFs), and it provides the cryptographic
will be also distributed securely through the southbound interface. material for the IPsec SAs. These keys will be also distributed
Note that this is possible because both NSFs are managed by the same securely through the southbound interface. Note that this is
controller. possible because both NSFs are managed by the same Security
Controller.
Figure 4 describes the IKE-less, when a data packet needs to be Figure 4 describes the IKE-less case, when a data packet needs to be
protected in the path between the NSF1 and NSF2: protected in the path between the NSF1 and NSF2:
1. The administrator establishes the flow-based security policies. 1. The administrator establishes the flow-based security policies,
The Security Controller looks for the involved NSFs. and the Security Controller looks for the involved NSFs.
2. The Security Controller translates the flow-based security 2. The Security Controller translates the flow-based security
policies into IPsec SPD and SAD entries. policies into IPsec SPD and SAD entries.
3. The Security Controller inserts the these entries in both NSF1 3. The Security Controller inserts these entries in both NSF1 and
and NSF2 IPsec databases. It associates a lifetime to the IPsec NSF2 IPsec databases. It associates a lifetime to the IPsec SAs.
SAs. When this lifetime expires, the NSF will send a sadb_expire When this lifetime expires, the NSF will send a sadb-expire
notification to the Security Controller in order to start the notification to the Security Controller in order to start the
rekeying process. rekeying process.
4. The flow is protected with the IPsec SA established by the 4. The flow is protected with the IPsec SA established by the
Security Controller. Security Controller.
It is also possible that the Security Controller only installs the
SPD entries in step 2. 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 SAD entries with the IPsec SAs required to process
the data packet needs to be installed in the NSFs.
Both NSFs could be two hosts that exchange traffic and require to Both NSFs could be two hosts that exchange traffic and require to
establish an end-to-end security association to protect their establish an end-to-end security association to protect their
communications (host-to-host) or two gateways (gateway-to-gateway), communications (host-to-host) or two gateways (gateway-to-gateway),
for example, within an enterprise that needs to protect the traffic for example, within an enterprise that needs to protect the traffic
between, for example, the networks of two branch offices. between the networks of two branch offices.
Applicability of these configurations appear in current and new Applicability of these configurations appear in current and new
networking scenarios. For example, SD-WAN technologies are providing networking scenarios. For example, SD-WAN technologies are providing
dynamic and on-demand VPN connections between branch offices, or dynamic and on-demand VPN connections between branch offices, or
between branches and SaaS cloud services. Beside, IaaS services between branches and SaaS cloud services. Beside, IaaS services
providing virtualization environments are deployments solutions based providing virtualization environments are deployments solutions based
on IPsec to provide secure channels between virtual instances (host- on IPsec to provide secure channels between virtual instances (host-
to-host) and providing VPN solutions for virtualized networks to-host) and providing VPN solutions for virtualized networks
(gateway-to-gateway). (gateway-to-gateway).
In general (for IKE and IKE-less case), this system has various In general (for IKE and IKE-less cases), this system has various
advantages: advantages:
1. It allows to create IPsec SAs among two NSFs, with only the 1. It allows to create IPsec SAs among two NSFs, based only on the
application of more general flow-based security policies at the application of general Flow-based Security Policies at the
application layer. Thus, administrators can manage all security application layer. Thus, administrators can manage all security
associations in a centralized point with an abstracted view of associations in a centralized point with an abstracted view of
the network. the network.
2. All NSFs deployed after the application of the new policies are 2. Any NSF deployed in the system does not need manual
NOT manually configured, therefore allowing its deployment in an configuration, therefore allowing its deployment in an automated
automated manner. manner.
7.2. Host-to-host or gateway-to-gateway under different security 7.2. Host-to-host or gateway-to-gateway under different Security
controllers Controllers
It is also possible that two NSFs (i.e. NSF1 and NSF2) are under the It is also possible that two NSFs (i.e. NSF1 and NSF2) are under the
control of two different Security Controllers. This may happen, for control of two different Security Controllers. This may happen, for
example, when two organizations, namely Enterprise A and Enterprise example, when two organizations, namely Enterprise A and Enterprise
B, have their headquarters interconnected through a WAN connection B, have their headquarters interconnected through a WAN connection
and they both have deployed a SDN-based architecture to provide and they both have deployed a SDN-based architecture to provide
connectivity to all their clients. connectivity to all their clients.
+-------------+ +-------------+ +-------------+ +-------------+
| | | | | | | |
Flow-based| Security |<===============>| Security <--Flow-based Flow-based| Security |<=========>| Security <--Flow-based
Sec. Pol.--> Controller | (3) | Controller | Sec. Pol. Sec. Pol.--> Controller | (3) | Controller | Sec. Pol.
(1) | A | | B | (2) (1) | A | | B | (2)
+-------------+ +-------------+ +-------------+ +-------------+
| | | |
| (4) (4) | | (4) (4) |
V V V V
+----------------------+ +----------------------+ +--------------------+ +--------------------+
| NSF1 |<========>| NSF2 | | NSF1 |<========>| NSF2 |
|IKEv2/IPsec(SPD/PAD) | |IKEv2/IPsec(SPD/PAD) | |IKEv2/IPsec(SPD/PAD)| |IKEv2/IPsec(SPD/PAD)|
+----------------------+ (5) +----------------------+ +--------------------+ (5) +--------------------+
Figure 5: Different security controllers in IKE case Figure 5: Different Security Controllers in the IKE case.
Figure 5 describes IKE case when two security controllers are Figure 5 describes IKE case when two Security Controllers are
involved in the process. involved in the process.
1. The A's administrator establishes general Flow-based Security 1. The A's administrator establishes general Flow-based Security
Policies in Security Controller A. Policies in Security Controller A.
2. The B's administrator establishes general Flow-based Security 2. The B's administrator establishes general Flow-based Security
Policies in Security Controller B. Policies in Security Controller B.
3. The Security Controller A realizes that protection is required 3. The Security Controller A realizes that protection is required
between the NSF1 and NSF2, but the NSF2 is under the control of between the NSF1 and NSF2, but the NSF2 is under the control of
another Security Controller (Security Controller B), so it starts another Security Controller (Security Controller B), so it starts
negotiations with the other controller to agree on the IPsec SPD negotiations with the other controller to agree on the IPsec SPD
policies and IKEv2 credentials for their respective NSFs. NOTE: policies and IKEv2 credentials for their respective NSFs. NOTE:
This may require extensions in the East/West interface. This may require extensions in the East/West interface.
4. Then, both Security Controllers enforce the IKEv2 credentials and 4. Then, both Security Controllers enforce the IKEv2 credentials,
related parameters and the SPD and PAD entries in their related parameters and the SPD and PAD entries in their
respective NSFs. respective NSFs.
5. The flow is protected with the IPsec SAs established with IKEv2 5. The flow is protected with the IPsec SAs established with IKEv2
between both NSFs. between both NSFs.
+--------------+ +--------------+ +--------------+ +--------------+
| | | | | | | |
Flow-based. ---> | <--- Flow-based Flow-based. ---> | | <---Flow-based
Prot. | Security |<=================>| Security |Sec. Prot. | Security |<===========>| Security |Sec.
Pol.(1)| Controller | (3) | Controller |Pol. (2) Pol.(1)| Controller | (3) | Controller |Pol. (2)
| A | | B | | A | | B |
+--------------+ +--------------+ +--------------+ +--------------+
| | | |
| (4) (4) | | (4) (4) |
V V V V
+------------------+ (5) +------------------+ +--------------+ (5) +--------------+
| NSF1 |<==============>| NSF2 | | NSF1 |<==============>| NSF2 |
|IPsec(SPD/SAD) | | IPsec(SPD/SAD) | |IPsec(SPD/SAD)| |IPsec(SPD/SAD)|
+------------------+ +------------------+ +--------------+ +--------------+
Figure 6: Different security controllers in IKE-less case Figure 6: Different Security Controllers in the IKE-less case.
Figure 5 describes IKE-less case when two security controllers are Figure 6 describes IKE-less case when two Security Controllers are
involved in the process. involved in the process.
1. The A's administrator establishes general Flow Protection 1. The A's administrator establishes general Flow Protection
Policies in Security Controller A. Policies in Security Controller A.
2. The B's administrator establishes general Flow Protection 2. The B's administrator establishes general Flow Protection
Policies in Security Controller B. Policies in Security Controller B.
3. The Security Controller A realizes that the flow between NSF1 and 3. The Security Controller A realizes that the flow between NSF1 and
NSF2 MUST be protected. Nevertheless, the controller notices NSF2 MUST be protected. Nevertheless, it notices that NSF2 is
that NSF2 is under the control of another Security Controller, so under the control of another Security Controller B, so it starts
it starts negotiations with the other controller to agree on the negotiations with the other controller to agree on the IPsec SPD
IPsec SPD and SAD entries that define the IPsec SAs. NOTE: It and SAD entries that define the IPsec SAs. NOTE: It would worth
would worth evaluating IKEv2 as the protocol for the East/West evaluating IKEv2 as the protocol for the East/West interface in
interface in this case. this case.
4. Once the Security Controllers have agreed on key material and the 4. Once the Security Controllers have agreed on the key material and
details of the IPsec SAs, they both enforce this information into the details of the IPsec SAs, they both enforce this information
their respective NSFs. into their respective NSFs.
5. The flow is protected with the IPsec SAs established by both 5. The flow is protected with the IPsec SAs established by both
Security Controllers in their respective NSFs. Security Controllers in their respective NSFs.
8. Security Considerations 8. IANA Considerations
TBD
9. 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]. On the one hand, it is important to [ITU-T.Y.3300] and [RFC8192].
note that there MUST exit a security association between the Security
Controller and the NSFs to protect of the critical information On the one hand, it is important to note that there MUST exit a
(cryptographic keys, configuration parameter, etc...) exchanged security association between the Security Controller and the NSFs to
between these entities. For example, if NETCONF is used as protect of the critical information (cryptographic keys,
southbound protocol between the Security Controller and the NSFs, it configuration parameter, etc...) exchanged between these entities.
is defined that TLS or SSH security association MUST be established For example, when NETCONF is used as southbound protocol between the
between both entities. On the other hand, we have divided this Security Controller and the NSFs, it is defined that TLS or SSH
section in two parts to analyze different security considerations for security association MUST be established between both entities.
both cases: NSF with IKEv2 (IKE case) and NSF without IKEv2 (IKE-less
case). In general, the Security Controller, as typically in the SDN On the other hand, if encryption is mandatory for all traffic of a
paradigm, is a target for different type of attacks. As a NSF, its default policy MUST be to drop (DISCARD) packets to prevent
consequence, the Security Controller is a key entity in the cleartext packet leaks. This default policy MUST be in the startup
infrastructure and MUST be protected accordingly. In particular, configuration datastore in the NSF before the NSF contacts with the
according to this document, the Security Controller will handle Security Controller. Moreover, the startup configuration datastore
MUST be pre-configured with the required ALLOW policies that allow to
communicate the NSF with the Security Controller once the NSF is
deployed. This pre-configuration step is not carried out by the
Security Controller but by some other entity before the NSF
deployment. In this manner, when the NSF starts/reboots, it will
always apply first the configuration in the startup configuration
before contacting the Security Controller.
Finally, we have divided this section in two parts in order to
analyze different security considerations for both cases: NSF with
IKEv2 (IKE case) and NSF without IKEv2 (IKE-less case). In general,
the Security Controller, as typically in the SDN paradigm, is a
target for different type of attacks. Thus, the Security Controller
is a key entity in the infrastructure and MUST be protected
accordingly. In particular, the Security Controller will handle
cryptographic material so that the attacker may try to access this cryptographic material so that the attacker may try to access this
information. Although, we can assume this attack will not likely to information. Although we can assume this attack will not likely to
happen due to the assumed security measurements to protect the happen due to the assumed security measurements to protect the
Security Controller, it deserves some analysis in the hypothetical Security Controller, it deserves some analysis in the hypothetical
the attack occurs. The impact is different depending on the IKE case case the attack occurs. The impact is different depending on the IKE
or IKE-less case. case or IKE-less case.
8.1. IKE case 9.1. IKE case
In IKE case, the Security Controller sends IKE credentials (PSK, In IKE case, the Security Controller sends IKE 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 Security Controller and NSFs. The
general recommendation is that the Security Controller SHOULD NEVER general recommendation is that the Security Controller MUST NOT store
store the IKE credentials after distributing them. Moreover the NSFs the IKE credentials after distributing them. Moreover, the NSFs MUST
MUST NOT allow the reading of these values once they have been NOT allow the reading of these values once they have been applied by
applied by the Security Controller (i.e. write only operations). One the Security Controller (i.e. write only operations). One option is
option is return always the same value (all 0s). If the attacker has to return always the same value (i.e. all 0s) if a read operation is
access to the Security Controller during the period of time that key carried out. If the attacker has access to the Security Controller
material is generated, it may access to these values. Since these during the period of time that key material is generated, it might
values are used during NSF authentication in IKEv2, it may have access to the key material. Since these values are used during
impersonate the affected NSFs. Several recommendations are NSF authentication in IKEv2, it may impersonate the affected NSFs.
important. If PSK authentication is used in IKEv2, the Security Several recommendations are important. If PSK authentication is used
Controller SHOULD remove the PSK immediately after generating and in IKEv2, the Security Controller MUST remove the PSK immediately
distributing it. Moreover, the PSK MUST have a proper length (e.g. after generating and distributing it. Moreover, the PSK MUST have a
minimu, 128 bit length) and strength. If raw public keys are used, proper length (e.g. minimum 128 bit length) and strength. When
the Security Controller SHOULD remove the associated private key public/private keys are used, the Security Controller MAY generate
immediately after generating and distributing them to the NSFs. If both public key and private key. In such a case, the Security
certificates are used, the NSF may generate the private key and Controller MUST remove the associated private key immediately after
exports the public key for certification to the Security Controller. 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.
8.2. IKE-less case 9.2. IKE-less case
In the IKE-less case, the controller sends the IPsec SA information In the IKE-less case, the Security Controller sends the IPsec SA
to the SAD that includes the keys for integrity and encryption (when information to the NSF's SAD that includes the private session keys
ESP is used). That key material are symmetric keys to protect data required for integrity and encryption. The general recommendation is
traffic. The general recommendation is that the Security Controller that it MUST NOT store the keys after distributing them. Moreover,
SHOULD NEVER stores the keys after distributing them. Moreover, the the NSFs receiving private key material MUST NOT allow the reading of
NSFs MUST NOT allow the reading of these values once they have been these values by any other entity (including the Security Controller
applied by the Security Controller (i.e. write only operations). itself) once they have been applied (i.e. write only operations) into
Nevertheless, if the attacker has access to the Security Controller the NSFs. Nevertheless, if the attacker has access to the Security
during the period of time that key material is generated, it may Controller during the period of time that key material is generated,
access to these values. In other words, it may have access to the it may obtain these values. In other words, the attacker might be
key material used in the distributed IPsec SAs and observe the able to observe the IPsec traffic and decrypt, or even modify and re-
traffic between peers. In any case, some escenarios with special encrypt the traffic between peers.
secure environments (e.g. physically isolated data centers) make this
type of attack difficult. Moreover, some scenarios such as IoT
networks with constrained devices, where reducing implementation and
computation overhead is important, can apply IKE-less case as a
tradeoff between security and low overhead at the constrained device,
at the cost of assuming the security impact described above.
9. Acknowledgements 10. Acknowledgements
Authors want to thank Paul Wouters, Sowmini Varadhan, David Carrel, Authors want to thank Paul Wouters, Sowmini Varadhan, David Carrel,
Yoav Nir, Tero Kivinen, Graham Bartlett, Sandeep Kampati, Linda Yoav Nir, Tero Kivinen, Graham Bartlett, Sandeep Kampati, Linda
Dunbar, Carlos J. Bernardos, Alejandro Perez-Mendez, Alejandro Abad- Dunbar, Carlos J. Bernardos, Alejandro Perez-Mendez, Alejandro Abad-
Carrascosa, Ignacio Martinez and Ruben Ricart for their valuable Carrascosa, Ignacio Martinez and Ruben Ricart for their valuable
comments. comments.
10. References 11. References
10.1. Normative References 11.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>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<https://www.rfc-editor.org/info/rfc5226>.
[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>.
[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>.
[RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 11.2. Informative References
Kumar, "Framework for Interface to Network Security
Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018,
<https://www.rfc-editor.org/info/rfc8329>.
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-framework]
Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R.
Kumar, "Framework for Interface to Network Security
Functions", draft-ietf-i2nsf-framework-10 (work in
progress), November 2017.
[I-D.ietf-i2nsf-problem-and-use-cases]
Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R.,
and J. Jeong, "I2NSF Problem Statement and Use cases",
draft-ietf-i2nsf-problem-and-use-cases-16 (work in
progress), May 2017.
[I-D.ietf-i2nsf-terminology] [I-D.ietf-i2nsf-terminology]
Hares, S., Strassner, J., Lopez, D., Xia, L., and H. Hares, S., Strassner, J., Lopez, D., Xia, L., and H.
Birkholz, "Interface to Network Security Functions (I2NSF) Birkholz, "Interface to Network Security Functions (I2NSF)
Terminology", draft-ietf-i2nsf-terminology-07 (work in Terminology", draft-ietf-i2nsf-terminology-08 (work in
progress), January 2019. progress), July 2019.
[I-D.ietf-opsawg-nat-yang] [I-D.ietf-opsawg-nat-yang]
Boucadair, M., Sivakumar, S., Jacquenet, C., Vinapamula, Boucadair, M., Sivakumar, S., Jacquenet, C., Vinapamula,
S., and Q. Wu, "A YANG Module for Network Address S., and Q. Wu, "A YANG Module for Network Address
Translation (NAT) and Network Prefix Translation (NPT)", Translation (NAT) and Network Prefix Translation (NPT)",
draft-ietf-opsawg-nat-yang-17 (work in progress), draft-ietf-opsawg-nat-yang-17 (work in progress),
September 2018. September 2018.
[I-D.jeong-i2nsf-sdn-security-services-05]
Jeong, J., Kim, H., Park, J., Ahn, T., and S. Lee,
"Software-Defined Networking Based Security Services using
Interface to Network Security Functions", draft-jeong-
i2nsf-sdn-security-services-05 (work in progress), July
2016.
[I-D.pfkey-spd]
Sakane, S., "PF_KEY Extensions for IPsec Policy Management
in KAME Stack", October 2002.
[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] [ITU-T.X.1252]
"Baseline Identity Management Terms and Definitions", "Baseline Identity Management Terms and Definitions",
April 2010. April 2010.
[ITU-T.X.800] [ITU-T.X.800]
"Security Architecture for Open Systems Interconnection "Security Architecture for Open Systems Interconnection
for CCITT Applications", March 1991. 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]
The Libreswan Project, "Libreswan VPN software", July
2019.
[netconf-vpn] [netconf-vpn]
Stefan Wallin, "Tutorial: NETCONF and YANG", January 2014. Stefan Wallin, "Tutorial: NETCONF and YANG", January 2014.
[netopeer]
CESNET, CESNET., "NETCONF toolset Netopeer", November
2016.
[ONF-OpenFlow] [ONF-OpenFlow]
ONF, "OpenFlow Switch Specification (Version 1.4.0)", ONF, "OpenFlow Switch Specification (Version 1.4.0)",
October 2013. October 2013.
[ONF-SDN-Architecture] [ONF-SDN-Architecture]
"SDN Architecture", June 2014. "SDN Architecture", June 2014.
[RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key [RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key
Management API, Version 2", RFC 2367, Management API, Version 2", RFC 2367,
DOI 10.17487/RFC2367, July 1998, DOI 10.17487/RFC2367, July 1998,
<https://www.rfc-editor.org/info/rfc2367>. <https://www.rfc-editor.org/info/rfc2367>.
[RFC3549] Salim, J., Khosravi, H., Kleen, A., and A. Kuznetsov,
"Linux Netlink as an IP Services Protocol", RFC 3549,
DOI 10.17487/RFC3549, July 2003,
<https://www.rfc-editor.org/info/rfc3549>.
[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>.
skipping to change at page 30, line 40 skipping to change at page 29, line 16
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>.
[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>.
[strongswan] [strongswan]
CESNET, CESNET., "StrongSwan: the OpenSource IPsec-based CESNET, "StrongSwan: the OpenSource IPsec-based VPN
VPN Solution", April 2017. Solution", July 2019.
Appendix A. Appendix A: Common YANG model for IKE and IKEless cases
<CODE BEGINS> file "ietf-ipsec-common@2019-03-11.yang"
module ietf-ipsec-common{
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec-common";
prefix "ipsec-common";
import ietf-inet-types { prefix inet; }
import ietf-yang-types { prefix yang; }
import ietf-crypto-types {
prefix ct;
reference "draft-ietf-netconf-crypto-types-01: Common YANG Dta Types for Cryptography";
}
organization "IETF I2NSF (Interface to Network Security Functions) Working Group";
contact
" Rafael Marin Lopez
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501
e-mail: rafa@um.es
Gabriel Lopez Millan
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Tel: +34 868888504
email: gabilm@um.es
Fernando Pereniguez Garcia
Department of Sciences and Informatics
University Defense Center (CUD), Spanish Air Force Academy, MDE-UPCT
30720 San Javier - Spain
Tel: +34 968189946
email: fernando.pereniguez@cud.upct.es
";
description "Common Data model for SDN-based IPSec configuration.";
revision "2019-03-11" { Appendix A. Appendix A: Common YANG model for IKE and IKE-less cases
description "Revision";
reference "";
}
typedef encryption-algorithm-t { <CODE BEGINS> file "ietf-ipsec-common@2019-07-07.yang"
type ct:encryption-algorithm-ref;
description "typedef";
}
typedef integrity-algorithm-t { module ietf-ipsec-common {
type ct:mac-algorithm-ref; yang-version 1.1;
description namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec-common";
"This typedef enables importing modules to easily define an prefix "ipsec-common";
identityref to the 'asymmetric-key-encryption-algorithm'
base identity.";
}
typedef ipsec-mode { import ietf-inet-types { prefix inet; }
type enumeration { import ietf-yang-types { prefix yang; }
enum TRANSPORT { description "Transport mode. No NAT support."; }
enum TUNNEL { description "Tunnel mode"; }
}
description "Type definition of IPsec mode";
}
typedef esp-encap { organization "IETF I2NSF Working Group";
type enumeration {
enum ESPINTCP { description "ESP in TCP encapulation.";}
enum ESPINTLS { description "ESP in TCP encapsulation using TLS.";}
enum ESPINUDP { description "ESP in UDP encapsulation. RFC 3948 ";}
enum NONE { description "NOT ESP encapsulation" ; }
}
description "type defining types of ESP encapsulation";
}
grouping encap { /* This is defined by XFRM */ contact
description "Encapsulation container"; "WG Web: <https://datatracker.ietf.org/wg/i2nsf/about/>
leaf espencap { type esp-encap; description "ESP in TCP, ESP in UDP or ESP in TLS";} WG List: <mailto:i2nsf@ietf.org>
leaf sport {type inet:port-number; description "Encapsulation source port";}
leaf dport {type inet:port-number; description "Encapsulation destination port"; }
leaf-list oaddr {type inet:ip-address; description "Encapsulation Original Address ";}
}
typedef ipsec-protocol { Author: Rafael Marin-Lopez
type enumeration { <mailto:rafa@um.es>
enum ah { description "AH Protocol"; }
enum esp { description "ESP Protocol"; }
}
description "type define of ipsec security protocol";
} Author: Gabriel Lopez-Millan
<mailto:gabilm@um.es>
typedef ipsec-spi { Author: Fernando Pereniguez-Garcia
type uint32 { range "0..max"; } <mailto:fernando.pereniguez@cud.upct.es>
description "SPI"; ";
}
typedef lifetime-action { description
type enumeration { "Common Data model for the IKE and IKE-less cases
enum terminate-clear {description "Terminate the IPsec SA and allow the packets through";} defined by the SDN-based IPsec flow protection service.
enum terminate-hold {description "Terminate the IPsec SA and drop the packets";}
enum replace {description "Replace the IPsec SA with a new one";}
}
description "Action when lifetime expiration";
}
/*################## SPD basic groupings ####################*/ Copyright (c) 2019 IETF Trust and the persons
identified as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with
or without modification, is permitted pursuant to, and
subject to the license terms contained in, the
Simplified BSD License set forth in Section 4.c of the
IETF Trust's Legal Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info).
typedef ipsec-traffic-direction { This version of this YANG module is part of RFC XXXX;;
type enumeration { see the RFC itself for full legal notices.
enum INBOUND { description "Inbound traffic"; }
enum OUTBOUND { description "Outbound traffic"; }
}
description "IPsec traffic direction";
}
typedef ipsec-spd-operation { The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
type enumeration { 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
enum PROTECT { description "PROTECT the traffic with IPsec"; } 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this
enum BYPASS { description "BYPASS the traffic"; } document are to be interpreted as described in BCP 14
enum DISCARD { description "DISCARD the traffic"; } (RFC 2119) (RFC 8174) when, and only when, they appear
} in all capitals, as shown here.";
description "The operation when traffic matches IPsec security policy";
}
typedef ipsec-upper-layer-proto { revision "2019-07-07" {
type enumeration { description "Revision 05";
enum TCP { description "TCP traffic"; } reference "RFC XXXX: YANG Groupings and typedef
enum UDP { description "UDP traffic"; } for IKE and IKE-less case";
enum SCTP { description "SCTP traffic";} }
enum DCCP { description "DCCP traffic";}
enum ICMP { description "ICMP traffic";}
enum IPv6-ICMP { description "IPv6-ICMP traffic";}
enum GRE {description "GRE traffic";}
}
description "Next layer proto on top of IP";
}
typedef ipsec-spd-name {
type enumeration {
enum id_rfc_822_addr { description "Fully qualified user name string."; }
enum id_fqdn { description "Fully qualified DNS name."; }
enum id_der_asn1_dn { description "X.500 distinguished name."; }
enum id_key { description "IKEv2 Key ID."; }
}
description "IPsec SPD name type";
}
grouping lifetime { typedef encryption-algorithm-type {
description "lifetime current state data"; type uint32;
leaf time {type yang:timestamp; default 0; description "Time since the element is added";} description
leaf idle {type yang:timestamp; default 0; description "Time the element is in idle state";} "The encryption algorithm is specified with a 32-bit
leaf bytes { type uint32; default 0; description "Lifetime in bytes number";} number extracted from IANA Registry. The acceptable
leaf packets {type uint32; default 0; description "Lifetime in packets number";} values MUST follow the requirement levels for
} encryption algorithms for ESP and IKEv2.";
reference
"IANA Registry- Transform Type 1 - Encryption
Algorithm Transform IDs. RFC 8221 - Cryptographic
Algorithm Implementation Requirements and Usage
Guidance for Encapsulating Security Payload (ESP)
and Authentication Header (AH) and RFC 8247 -
Algorithm Implementation Requirements and Usage
Guidance for the Internet Key Exchange Protocol
Version 2 (IKEv2).";
}
/*################## SAD and SPD common basic groupings ####################*/ typedef integrity-algorithm-type {
type uint32;
description
"The integrity algorithm is specified with a 32-bit
number extracted from IANA Registry.
The acceptable values MUST follow the requirement
levels for encryption algorithms for ESP and IKEv2.";
reference
"IANA Registry- Transform Type 3 - Integrity
Algorithm Transform IDs. RFC 8221 - Cryptographic
Algorithm Implementation Requirements and Usage
Guidance for Encapsulating Security Payload (ESP)
and Authentication Header (AH) and RFC 8247 -
Algorithm Implementation Requirements and Usage
Guidance for the Internet Key Exchange Protocol
Version 2 (IKEv2).";
}
grouping port-range { typedef ipsec-mode {
description "Port range grouping"; type enumeration {
leaf start { type inet:port-number; description "Start Port Number"; } enum transport {
leaf end { type inet:port-number; description "End Port Number"; } description
} "IPsec transport mode. No Network Address
Translation (NAT) support.";
}
enum tunnel {
description "IPsec tunnel mode.";
}
}
description
"Type definition of IPsec mode: transport or
tunnel.";
reference
"Section 3.2 in RFC 4301.";
}
grouping tunnel-grouping { typedef esp-encap {
description "Tunnel mode grouping"; type enumeration {
leaf local{ type inet:ip-address; description "Local tunnel endpoint"; } enum espintcp {
leaf remote{ type inet:ip-address; description "Remote tunnel enpoint"; } description
leaf bypass-df { type boolean; description "Bypass DF bit"; } "ESP in TCP encapsulation.";
leaf bypass-dscp { type boolean; description "Bypass DSCP"; } reference
leaf dscp-mapping { type yang:hex-string; description "DSCP mapping"; } "RFC 8229 - TCP Encapsulation of IKE and
leaf ecn { type boolean; description "Bit ECN"; } /* RFC 4301 ASN1 notation. Annex C*/ IPsec Packets.";
} }
enum espintls {
description
"ESP in TCP encapsulation using TLS.";
reference
"RFC 8229 - TCP Encapsulation of IKE and
IPsec Packets.";
}
enum espinudp {
description
"ESP in UDP encapsulation.";
reference
"RFC 3948 - UDP Encapsulation of IPsec ESP
Packets.";
}
enum none {
description
"NOT ESP encapsulation.";
}
}
description
"Types of ESP encapsulation when Network Address
Translation (NAT) is present between two NSFs.";
grouping selector-grouping { reference
description "Traffic selector grouping"; "RFC 8229 - TCP Encapsulation of IKE and IPsec
Packets and RFC 3948 - UDP Encapsulation of IPsec
ESP Packets.";
}
leaf local-subnet { type inet:ip-prefix; description "Local IP address subnet"; } typedef ipsec-protocol-parameters {
leaf remote-subnet { type inet:ip-prefix; description "Remote IP address subnet"; } type enumeration {
enum esp { description "IPsec ESP protocol."; }
}
description
"Only the Encapsulation Security Protocol (ESP) is
supported but it could be extended in the future.";
reference
"RFC 4303- IP Encapsulating Security Payload
(ESP).";
leaf-list upper-layer-protocol { type ipsec-upper-layer-proto; description "List of Upper Layer Protocol";} }
list local-ports { typedef lifetime-action {
key "start end"; type enumeration {
uses port-range; enum terminate-clear {
description "List of local ports. When the upper-layer-protocol is ICMP this 16 bit value respresents code and type as mentioned in RFC 4301"; description
"Terminates the IPsec SA and allows the
packets through.";
}
enum terminate-hold {
description
"Terminates the IPsec SA and drops the
packets.";
}
enum replace {
description
"Replaces the IPsec SA with a new one:
rekey. ";
}
}
description
"When the lifetime of an IPsec SA expires an action
needs to be performed over the IPsec SA that
reached the lifetime. There are three posible
options: terminate-clear, terminate-hold and
replace.";
reference
"Section 4.5 in RFC 4301.";
}
} typedef ipsec-traffic-direction {
type enumeration {
enum inbound {
description "Inbound traffic.";
}
enum outbound {
description "Outbound traffic.";
}
}
description
"IPsec traffic direction is defined in two
directions: inbound and outbound. From a NSF
perspective inbound means the traffic that enters
the NSF and outbound is the traffic that is sent
from the NSF.";
reference
"Section 5 in RFC 4301.";
}
list remote-ports { typedef ipsec-spd-action {
key "start end"; type enumeration {
uses port-range; enum protect {
description "List of remote ports. When the upper-layer-protocol is ICMP this 16 bit value respresents code and type as mentioned in RFC 4301"; description
} "PROTECT the traffic with IPsec.";
} }
enum bypass {
description
"BYPASS the traffic. The packet is forwarded
without IPsec protection.";
}
enum discard {
description
"DISCARD the traffic. The IP packet is
discarded.";
}
}
description
"The action when traffic matches an IPsec security
policy. According to RFC 4301 there are three
possible values: BYPASS, PROTECT AND DISCARD";
reference
"Section 4.4.1 in RFC 4301.";
}
/*################## SPD ipsec-policy-grouping ####################*/ typedef ipsec-inner-protocol {
type union {
type uint8;
type enumeration {
enum any {
value 256;
description
"Any IP protocol number value.";
}
}
}
default any;
description
"IPsec protection can be applied to specific IP
traffic and layer 4 traffic (TCP, UDP, SCTP, etc.)
or ANY protocol in the IP packet payload. We
specify the IP protocol number with an uint8 or
ANY defining an enumerate with value 256 to
indicate the protocol number.";
reference
"Section 4.4.1.1 in RFC 4301.
IANA Registry - Protocol Numbers.";
}
grouping ipsec-policy-grouping { grouping encap {
description
"This group of nodes allows to define the type of
encapsulation in case NAT traversal is
required and port information.";
leaf espencap {
type esp-encap;
description
"ESP in TCP, ESP in UDP or ESP in TLS.";
}
leaf sport {
type inet:port-number;
default 4500;
description
"Encapsulation source port.";
}
leaf dport {
type inet:port-number;
default 4500;
description
"Encapsulation destination port.";
}
description "Holds configuration information for an IPSec SPD entry."; leaf-list oaddr {
type inet:ip-address;
description
"If required, this is the original address that
was used before NAT was applied over the Packet.
";
leaf spd-entry-id { type uint64; description "SPD entry id "; } }
leaf priority {type uint32; default 0; description "Policy priority";} reference
leaf anti-replay-window { type uint16 { range "0 | 32..1024"; } description "Anti replay window size"; } "RFC 3947 and RFC 8229.";
}
list names { grouping lifetime {
key "name"; description
leaf name-type { type ipsec-spd-name; description "SPD name type."; } "Different lifetime values limited to an IPsec SA.";
leaf name { type string; description "Policy name"; } leaf time {
description "List of policy names"; type uint32;
} default 0;
description
"Time in seconds since the IPsec SA was added.
For example, if this value is 180 seconds it
means the IPsec SA expires in 180 seconds since
it was added. The value 0 implies infinite.";
}
leaf bytes {
type uint32;
default 0;
description
"If the IPsec SA processes the number of bytes
expressed in this leaf, the IPsec SA expires and
should be rekeyed. The value 0 implies
infinite.";
}
leaf packets {
type uint32;
default 0;
description
"If the IPsec SA processes the number of packets
expressed in this leaf, the IPsec SA expires and
should be rekeyed. The value 0 implies
infinite.";
}
leaf idle {
type uint32;
default 0;
description
"When a NSF stores an IPsec SA, it
consumes system resources. In an idle NSF this
is a waste of resources. If the IPsec SA is idle
during this number of seconds the IPsec SA
should be removed. The value 0 implies
infinite.";
}
reference
"Section 4.4.2.1 in RFC 4301.";
container condition { }
description "SPD condition - RFC4301";
list traffic-selector-list {
key "ts-number";
leaf ts-number { type uint32; description "Traffic selector number"; }
leaf direction { type ipsec-traffic-direction; description "in/out"; }
uses selector-grouping;
ordered-by user;
description "List of traffic selectors";
}
}
container processing-info { grouping port-range {
description "SPD processing - RFC4301"; description
leaf action{ type ipsec-spd-operation; mandatory true; description "Bypass or discard, container ipsec-sa-cfg is empty";} "This grouping defines a port range, such as
expressed in RFC 4301. For example: 1500 (Start
Port Number)-1600 (End Port Number). A port range
is used in the Traffic Selector.";
container ipsec-sa-cfg { leaf start {
when "../action = 'PROTECT'"; type inet:port-number;
description
"Start port number.";
}
leaf end {
type inet:port-number;
description
"End port number.";
}
reference "Section 4.4.1.2 in RFC 4301.";
}
leaf pfp-flag { type boolean; description "Each selector has with a pfp flag."; } grouping tunnel-grouping {
leaf extSeqNum { type boolean; description "TRUE 64 bit counter, FALSE 32 bit"; } description
leaf seqOverflow { type boolean; description "TRUE rekey, FALSE terminare &amp; audit"; } "The parameters required to define the IP tunnel
leaf statefulfragCheck { type boolean; description "Indicates whether (TRUE) or not (FALSE) stateful fragment checking (RFC 4301) applies to the SA to be created."; } endpoints when IPsec SA requires tunnel mode. The
leaf security-protocol { type ipsec-protocol; description "Security protocol of IPsec SA: Either AH or ESP."; } tunnel is defined by two endpoints: the local IP
leaf mode { type ipsec-mode; description "transport/tunnel"; } address and the remote IP address.";
container ah-algorithms { leaf local {
when "../security-protocol = 'ah'"; type inet:ip-address;
leaf-list ah-algorithm { type integrity-algorithm-t; description "Configure Authentication Header (AH)."; } mandatory true;
leaf trunc-length { type uint32; description "Truncation value for AH algorithm"; } description
description "AH algoritms "; "Local IP address' tunnel endpoint.";
} }
leaf remote {
type inet:ip-address;
mandatory true;
description
"Remote IP address' tunnel endpoint.";
}
leaf df-bit {
type enumeration {
enum clear {
description
"Disable the DF (Don't Fragment) bit
from the outer header. This is the
default value.";
container esp-algorithms { }
when "../security-protocol = 'esp'"; enum set {
description "Configure Encapsulating Security Payload (ESP)."; description
leaf-list authentication { type integrity-algorithm-t; description "Configure ESP authentication"; } "Enable the DF bit in the outer header.";
/* With AEAD algorithms, the authentication node is not used */ }
leaf-list encryption { type encryption-algorithm-t; description "Configure ESP encryption"; } enum copy {
leaf tfc_pad { type uint32; default 0; description "TFC padding for ESP encryption"; } description
} "Copy the DF bit to the outer header.";
}
}
default clear;
description
"Allow configuring the DF bit when encapsulating
tunnel mode IPsec traffic. RFC 4301 describes
three options to handle the DF bit during
tunnel encapsulation: clear, set and copy from
the inner IP header.";
reference
"Section 8.1 in RFC 4301.";
}
leaf bypass-dscp {
type boolean;
default true;
description
"If DSCP (Differentiated Services Code Point)
values in the inner header have to be used to
select one IPsec SA among several that match
the traffic selectors for an outbound packet";
reference
"Section 4.4.2.1. in RFC 4301.";
}
leaf dscp-mapping {
type yang:hex-string;
description
"DSCP values allowed for packets carried over
this IPsec SA.";
reference
"Section 4.4.2.1. in RFC 4301.";
}
leaf ecn {
type boolean;
default false;
description
"Explicit Congestion Notification (ECN). If true
copy CE bits to inner header.";
reference
"Section 5.2.1 and Annex C in RFC 4301.";
}
container tunnel { }
when "../mode = 'TUNNEL'";
uses tunnel-grouping;
description "tunnel grouping container";
}
description " IPSec SA configuration container"; grouping selector-grouping {
} description
} "This grouping contains the definition of a Traffic
Selector, which is used in the IPsec policies and
IPsec SAs.";
container spd-lifetime-soft { leaf local-subnet {
description "SPD lifetime hard state data"; type inet:ip-prefix;
uses lifetime; mandatory true;
leaf action {type lifetime-action; description "Action lifetime";} description
} "Local IP address subnet.";
}
leaf remote-subnet {
type inet:ip-prefix;
mandatory true;
description
"Remote IP address subnet.";
}
leaf inner-protocol {
type ipsec-inner-protocol;
default any;
description
"Inner Protocol that is going to be
protected with IPsec.";
}
list local-ports {
key "start end";
uses port-range;
description
"List of local ports. When the inner
protocol is ICMP this 16 bit value represents
code and type.";
}
list remote-ports {
key "start end";
uses port-range;
description
"List of remote ports. When the upper layer
protocol is ICMP this 16 bit value represents
code and type.";
}
reference
"Section 4.4.1.2 in RFC 4301.";
}
container spd-lifetime-hard { grouping ipsec-policy-grouping {
description "SPD lifetime hard state data. The action after the lifetime is to remove the SPD entry."; description
uses lifetime; "Holds configuration information for an IPsec SPD
} entry.";
// State data for an IPsec SPD entry leaf anti-replay-window {
container spd-lifetime-current { type uint64;
uses lifetime; default 32;
config false; description
description "SPD lifetime current state data"; "A 64-bit counter used to determine whether an
} inbound ESP packet is a replay.";
} /* grouping ipsec-policy-grouping */ reference
"Section 4.4.2.1 in RFC 4301.";
}
container traffic-selector {
description
"Packets are selected for
processing actions based on the IP and inner
protocol header information, selectors,
matched against entries in the SPD.";
uses selector-grouping;
reference
"Section 4.4.4.1 in RFC 4301.";
}
container processing-info {
description
"SPD processing. If the required processing
action is protect, it contains the required
information to process the packet.";
leaf action {
type ipsec-spd-action;
default discard;
description
"If bypass or discard, container
ipsec-sa-cfg is empty.";
}
container ipsec-sa-cfg {
when "../action = 'protect'";
description
"IPSec SA configuration included in the SPD
entry.";
leaf pfp-flag {
type boolean;
default false;
description
"Each selector has a Populate From
Packet (PFP) flag. If asserted for a
given selector X, the flag indicates
that the IPSec SA to be created should
take its value (local IP address,
remote IP address, Next Layer
Protocol, etc.) for X from the value
in the packet. Otherwise, the IPsec SA
should take its value(s) for X from
the value(s) in the SPD entry.";
}
leaf ext-seq-num {
type boolean;
default false;
description
"True if this IPsec SA is using extended
sequence numbers. True 64 bit counter,
False 32 bit.";
}
leaf seq-overflow {
type boolean;
default false;
description
"The flag indicating whether
overflow of the sequence number
counter should prevent transmission
of additional packets on the IPsec
SA (false) and, therefore needs to
be rekeyed, or whether rollover is
permitted (true). If Authenticated
Encryption with Associated Data
(AEAD) is used this flag MUST BE
false.";
}
leaf stateful-frag-check {
type boolean;
default false;
description
"Indicates whether (true) or not (false)
stateful fragment checking applies to
the IPsec SA to be created.";
}
leaf mode {
type ipsec-mode;
default transport;
description
"IPsec SA has to be processed in
transport or tunnel mode.";
}
leaf protocol-parameters {
type ipsec-protocol-parameters;
default esp;
description
"Security protocol of the IPsec SA:
Only ESP is supported but it could be
extended in the future.";
}
container esp-algorithms {
when "../protocol-parameters = 'esp'";
description
"Configuration of Encapsulating
Security Payload (ESP) parameters and
algorithms.";
leaf-list integrity {
type integrity-algorithm-type;
default 0;
ordered-by user;
description
"Configuration of ESP authentication
based on the specified integrity
algorithm. With AEAD algorithms,
the integrity node is not
used.";
reference
"Section 3.2 in RFC 4303.";
}
leaf-list encryption {
type encryption-algorithm-type;
default 20;
ordered-by user;
description
"Configuration of ESP encryption
algorithms. The default value is
20 (ENCR_AES_GCM_16).";
reference
"Section 3.2 in RFC 4303.";
}
leaf tfc-pad {
type boolean;
default false;
description
"If Traffic Flow Confidentiality
(TFC) padding for ESP encryption
can be used (true) or not (false)";
reference
"Section 2.7 in RFC 4303.";
}
reference
"RFC 4303.";
}
container tunnel {
when "../mode = 'tunnel'";
uses tunnel-grouping;
description
"IPsec tunnel endpoints definition.";
}
}
reference
"Section 4.4.1.2 in RFC 4301.";
}
container spd-mark {
description
"The Mark to set for the IPsec SA of this
connection. This option is only available
on linux NETKEY/XFRM kernels. It can be
used with iptables to create custom
iptables rules using CONNMARK. It can also
be used with Virtual Tunnel Interfaces
(VTI) to direct marked traffic to
specific vtiXX devices.";
leaf mark {
type uint32;
default 0;
description
"Mark used to match XFRM policies and
states.";
}
leaf mask {
type yang:hex-string;
default 00:00:00:00;
description
"Mask used to match XFRM policies and
states.";
}
}
}
}
} <CODE ENDS>
<CODE ENDS>
Appendix B. Appendix B: YANG model for IKE case Appendix B. Appendix B: YANG model for IKE case
<CODE BEGINS> file "ietf-ipsec-ike@2019-03-11.yang" <CODE BEGINS> file "ietf-ipsec-ike@2019-07-07.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 "ipsec-ike";
import ietf-inet-types { prefix inet; }
import ietf-yang-types { prefix yang; }
import ietf-crypto-types {
prefix ct;
reference "draft-ietf-netconf-crypto-types-01: Common YANG Data Types for Cryptography";
}
import ietf-ipsec-common {
prefix ic;
reference "Common Data model for SDN-based IPSec configuration";
}
organization "IETF I2NSF (Interface to Network Security Functions) Working Group";
contact
" Rafael Marin Lopez
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501
e-mail: rafa@um.es
Gabriel Lopez Millan
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Tel: +34 868888504
email: gabilm@um.es
Fernando Pereniguez Garcia
Department of Sciences and Informatics
University Defense Center (CUD), Spanish Air Force Academy, MDE-UPCT
30720 San Javier - Spain
Tel: +34 968189946
email: fernando.pereniguez@cud.upct.es
";
description "Data model for IKE case.";
revision "2019-03-11" {
description "Revision 1.1";
reference "";
}
typedef type-autostartup {
type enumeration {
enum ADD {description "IPsec configuration is only loaded but not started.";}
enum ON-DEMAND {description "IPsec configuration is loaded and transferred to the NSF's kernel";}
enum START { description "IPsec configuration is loaded and transferred to the NSF's kernel, and the IKEv2 based IPsec SAs are established";}
}
description "Different policies of when to start an IKEv2 based IPsec SA";
}
typedef auth-protocol-type {
type enumeration {
enum IKEv2 { description "Authentication protocol based on IKEv2"; }
}
description "IKE authentication protocol version";
}
typedef pfs-group {
type enumeration {
enum NONE {description "NONE";}
enum 768-bit-MODP {description "768-bit MODP Group";}
enum 1024-bit-MODP {description "1024-bit MODP Group";}
enum 1536-bit-MODP {description "1536-bit MODP Group";}
enum 2048-bit-MODP {description "2048-bit MODP Group";}
enum 3072-bit-MODP {description "3072-bit MODP Group";}
enum 4096-bit-MODP {description "4096-bit MODP Group";}
enum 6144-bit-MODP {description "6144-bit MODP Group";}
enum 8192-bit-MODP {description "8192-bit MODP Group";}
}
description "PFS group for IPsec rekey";
}
/*################## PAD ####################*/
typedef auth-method-type { import ietf-inet-types { prefix inet; }
/* Most implementations also provide XAUTH protocol, others used are: BLISS, P12, NTLM, PIN */ import ietf-yang-types { prefix yang; }
type enumeration {
enum pre-shared { description "Select pre-shared key message as the authentication method"; }
enum eap { description "Select EAP as the authentication method"; }
enum digital-signature { description "Select digital signature method";}
enum null {description "null authentication";}
}
description "Peer authentication method";
}
typedef signature-algorithm-t { import ietf-crypto-types {
type ct:signature-algorithm-ref; // We must reference to "signature-algorithm-ref" but we temporary use hash-algorithm-ref prefix ct;
description "This typedef enables referencing to any digital signature algorithm"; reference
} "draft-ietf-netconf-crypto-types-09:
Common YANG Data Types for Cryptography.";
}
grouping auth-method-grouping { import ietf-ipsec-common {
description "Peer authentication method data"; prefix ic;
reference
"RFC XXXX: module ietf-ipsec-common, revision
2019-07-07.";
}
container auth-method { import ietf-netconf-acm {
description "Peer authentication method container"; prefix nacm;
reference
"RFC 8341: Network Configuration Access Control
Model.";
}
leaf auth-m { type auth-method-type; description "Type of authentication method (pre-shared, eap, digital signature, null)"; } organization "IETF I2NSF Working Group";
container eap-method { contact
when "../auth-m = 'eap'"; "WG Web: <https://datatracker.ietf.org/wg/i2nsf/about/>
leaf eap-type { type uint8; description "EAP method type"; } WG List: <mailto:i2nsf@ietf.org>
description "EAP method description used when auth method is eap";
}
container pre-shared { Author: Rafael Marin-Lopez
when "../auth-m[.='pre-shared' or .='eap']"; <mailto:rafa@um.es>
leaf secret { type yang:hex-string; description "Pre-shared secret value";}
description "Shared secret value";
}
container digital-signature { Author: Gabriel Lopez-Millan
when "../auth-m[.='digital-signature' or .='eap']"; <mailto:gabilm@um.es>
leaf ds-algorithm {type signature-algorithm-t; description "Name of the digital signature algorithm";}
leaf raw-public-key {type yang:hex-string; description "RSA raw public key" ;}
leaf key-data { type string; description "RSA private key data - PEM"; }
leaf key-file { type string; description "RSA private key file name "; }
leaf-list ca-data { type string; description "List of trusted CA certs - PEM"; }
leaf ca-file { type string; description "List of trusted CA certs file"; }
leaf cert-data { type string; description "X.509 certificate data - PEM4"; }
leaf cert-file { type string; description "X.509 certificate file"; }
leaf crl-data { type string; description "X.509 CRL certificate data in base64"; }
leaf crl-file { type string; description " X.509 CRL certificate file"; }
leaf oscp-uri { type inet:uri; description "OCSP URI";}
description "RSA signature container";
}
}
}
grouping identity-grouping { Author: Fernando Pereniguez-Garcia
description "Identification type. It is an union identity"; <mailto:fernando.pereniguez@cud.upct.es>
choice identity { ";
description "Choice of identity.";
leaf ipv4-address { type inet:ipv4-address; description "Specifies the identity as a single four (4) octet IPv4 address. An example is, 10.10.10.10. "; }
leaf ipv6-address { type inet:ipv6-address; description "Specifies the identity as a single sixteen (16) octet IPv6 address. An example is FF01::101, 2001:DB8:0:0:8:800:200C:417A ."; }
leaf fqdn-string { type inet:domain-name; description "Specifies the identity as a Fully-Qualified Domain Name (FQDN) string. An example is: example.com. The string MUST not contain any terminators (e.g., NULL, CR, etc.)."; }
leaf rfc822-address-string { type string; description "Specifies the identity as a fully-qualified RFC822 email address string. An example is, jsmith@example.com. The string MUST not contain any terminators (e.g., NULL, CR, etc.)."; }
leaf dnX509 { type string; description "Specifies the identity as a distinguished name in the X.509 tradition."; }
leaf id_key { type string; description "Key id"; }
leaf id_null { type empty; description "RFC 7619" ; }
leaf user_fqdn { type string; description "User FQDN"; }
}
leaf my-identifier { type string; mandatory true; description "id used for authentication"; }
}
/*################ end PAD ##################*/ description
/*################## IKEv2-grouping ##################*/ "This module contains IPSec IKE case model for the SDN-based
grouping ike-proposal { IPsec flow protection service. An NSF will implement this
description "IKEv2 proposal grouping"; module.
container ike-sa-lifetime-hard { Copyright (c) 2019 IETF Trust and the persons identified as
description "IKE SA lifetime hard"; authors of the code. All rights reserved.
uses ic:lifetime;
}
container ike-sa-lifetime-soft { Redistribution and use in source and binary forms, with or
description "IPsec SA lifetime soft"; without modification, is permitted pursuant to, and subject
uses ic:lifetime; to the license terms contained in, the Simplified BSD License
leaf action {type ic:lifetime-action; description "Action lifetime";} set forth in Section 4.c of the IETF Trust's Legal Provisions
} Relating to IETF Documents
(http://trustee.ietf.org/license-info).
leaf-list ike-sa-authalg { type ic:integrity-algorithm-t; description "Auth algorigthm for IKE SA";} This version of this YANG module is part of RFC XXXX; see
leaf-list ike-sa-encalg { type ic:encryption-algorithm-t; description "Auth algorigthm for IKE SAs";} the RFC itself for full legal notices.
leaf dh_group { type uint32; mandatory true; description "Group number for Diffie Hellman Exponentiation";}
leaf half-open-ike-sa-timer { type uint32; description "Set the half-open IKE SA timeout duration" ; }
leaf half-open-ike-sa-cookie-threshold { type uint32; description "Number of half-open IKE SAs that activate the cookie mechanism." ; }
}
grouping ike-child-sa-info { The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
description "IPsec SA Information"; 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
leaf-list pfs_groups { type pfs-group; description "If non-zero, require perfect forward secrecy when requesting new SA. The non-zero value is the required group number"; } 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this
document are to be interpreted as described in BCP 14
(RFC 2119) (RFC 8174) when, and only when, they appear
in all capitals, as shown here.";
container child-sa-lifetime-soft { revision "2019-07-07" {
description "IPsec SA lifetime soft"; description "Revision 5";
uses ic:lifetime; reference
leaf action {type ic:lifetime-action; description "action lifetime";} "RFC XXXX: YANG model for IKE case.";
} }
container child-sa-lifetime-hard { typedef ike-spi {
description "IPsec SA lifetime hard. The action will be to terminate the IPsec SA."; type uint64 { range "0..max"; }
uses ic:lifetime; description
} "Security Parameter Index (SPI)'s IKE SA.";
} reference
"Section 2.6 in RFC 7296.";
}
/*################## End IKEv2-grouping ##################*/ typedef autostartup-type {
type enumeration {
enum add {
description
"IKE/IPsec configuration is only loaded into
IKE implementation but IKE/IPsec SA is not
started.";
}
enum on-demand {
description
"IKE/IPsec configuration is loaded
into IKE implementation. The IPsec policies
are transferred to the NSF's kernel but the
IPsec SAs are not established immediately.
The IKE implementation will negotiate the
IPsec SAs when the NSF's kernel requests it
(i.e. through an ACQUIRE notification).";
}
enum start {
description "IKE/IPsec configuration is loaded
and transferred to the NSF's kernel, and the
IKEv2 based IPsec SAs are established
immediately without waiting any packet.";
}
}
description
"Different policies to set IPsec SA configuration
into NSF's kernel when IKEv2 implementation has
started.";
}
container ikev2 { typedef pfs-group {
type uint32;
description
"DH groups for IKE and IPsec SA rekey.";
reference
"Section 3.3.2 in RFC 7296. Transform Type 4 -
Diffie-Hellman Group Transform IDs in IANA Registry
- Internet Key Exchange Version 2 (IKEv2)
Parameters.";
}
description "Configure the IKEv2 software"; typedef auth-protocol-type {
type enumeration {
enum ikev2 {
value 2;
description
"IKEv2 authentication protocol. It is the
only defined right now. An enum is used for
further extensibility.";
}
}
description
"IKE authentication protocol version specified in the
Peer Authorization Database (PAD). It is defined as
enumerate to allow new IKE versions in the
future.";
reference
"RFC 7296.";
}
container pad { typedef auth-method-type {
description "Configure Peer Authorization Database (PAD)"; type enumeration {
list pad-entry { enum pre-shared {
key "pad-entry-id"; description
ordered-by user; "Select pre-shared key as the
description "Peer Authorization Database (PAD)"; authentication method.";
leaf pad-entry-id { type uint64; description "SAD index. ";} reference
uses identity-grouping; "RFC 7296.";
leaf pad-auth-protocol { type auth-protocol-type; description "IKEv2, etc. ";} }
uses auth-method-grouping; enum eap {
} description
} "Select EAP as the authentication method.";
reference
"RFC 7296.";
}
enum digital-signature {
description
"Select digital signature method.";
reference
"RFC 7296 and RFC 7427.";
}
enum null {
description
"Null authentication.";
reference
"RFC 7619.";
}
list ike-conn-entry { }
key "conn-name"; description
description "IKE peer connection information"; "Peer authentication method specified in the Peer
leaf conn-name { type string; mandatory true; description "Name of IKE connection";} Authorization Database (PAD).";
leaf autostartup { type type-autostartup; mandatory true; description "if True: automatically start tunnel at startup; else we do lazy tunnel setup based on trigger from datapath";} }
leaf initial-contact {type boolean; default false; description "This IKE SA is the only currently active between the authenticated identities";}
leaf version {
type enumeration {
enum ikev2 {value 2; description "IKE version 2";}
}
description "IKE version";
}
leaf ike-fragmentation { type boolean; description "Whether to use IKEv2 fragmentation as per RFC 7383 (TRUE or FALSE)"; } container ipsec-ike {
uses ike-proposal; description
"IKE configuration for a NSF. It includes PAD
parameters, IKE connections information and state
data.";
container local { container pad {
description "Local peer connection information"; description
leaf local-pad-id { type uint64; description " ";} "Configuration of Peer Authorization Database
} (PAD). The PAD contains information about IKE
peer (local and remote). Therefore, the Security
Controller also stores authentication
information for this NSF and can include
several entries for the local NSF not only
remote peers. Storing local and remote
information makes possible to specify that this
NSF with identity A will use some particular
authentication with remote NSF with identity B
and what are the authentication mechanisms
allowed to B.";
list pad-entry {
key "name";
ordered-by user;
description
"Peer Authorization Database (PAD) entry. It
is a list of PAD entries ordered by the
Security Controller.";
leaf name {
type string;
description
"PAD unique name to identify this
entry.";
}
choice identity {
mandatory true;
description
"A particular IKE peer will be
identified by one of these identities.
This peer can be a remote peer or local
peer (this NSF).";
reference
"Section 4.4.3.1 in RFC 4301.";
case ipv4-address{
leaf ipv4-address {
type inet:ipv4-address;
description
"Specifies the identity as a
single four (4) octet IPv4
addressExample: 10.10.10.10.";
}
}
case ipv6-address{
leaf ipv6-address {
type inet:ipv6-address;
description
"Specifies the identity as a
single sixteen (16) octet IPv6
address. An example is
2001:DB8:0:0:8:800:200C:417A.";
}
}
case fqdn-string {
leaf fqdn-string {
type inet:domain-name;
description
"Specifies the identity as a
Fully-QualifiedDomain Name
(FQDN) string. An example is:
example.com. The string MUST
not contain any terminators
(e.g., NULL, CR, etc.).";
}
}
case rfc822-address-string {
leaf rfc822-address-string {
type string;
description
"Specifies the identity as a
fully-qualified RFC822 email
address string. An example is,
jsmith@example.com. The string
MUST not contain any
terminators e.g., NULL, CR,
etc.).";
reference
"RFC 822.";
}
}
case dnx509 {
leaf dnx509 {
type string;
description
"Specifies the identity as a
ASN.1 X.500 Distinguished
Name. An example is
C=US,O=Example
Organisation,CN=John Smith.";
reference
"RFC 2247.";
}
}
case gnx509 {
leaf gnx509 {
type string;
description
"ASN.1 X.509 GeneralName. RFC
3280.";
}
}
case id-key {
leaf id-key {
type string;
description
"Opaque octet stream that may be
used to pass vendor-specific
information for proprietary
types of identification.";
reference
"Section 3.5 in RFC 7296.";
}
}
case id-null {
leaf id-null {
type empty;
description
"ID_NULL identification used
when IKE identification payload
is not used." ;
reference
"RFC 7619.";
}
}
}
leaf auth-protocol {
type auth-protocol-type;
default ikev2;
description
"Only IKEv2 is supported right now but
other authentication protocols may be
supported in the future.";
}
container peer-authentication {
description
"This container allows the Security
Controller to configure the
authentication method (pre-shared key,
eap, digitial-signature, null) that
will use a particular peer and the
credentials, which will depend on the
selected authentication method.";
leaf auth-method {
type auth-method-type;
default pre-shared;
description
"Type of authentication method
(pre-shared, eap, digital signature,
null).";
reference
"Section 2.15 in RFC 7296.";
}
container eap-method {
when "../auth-method = 'eap'";
leaf eap-type {
type uint8;
mandatory true;
description
"EAP method type. This
information provides the
particular EAP method to be
used. Depending on the EAP
method, pre-shared keys or
certificates may be used.";
}
description
"EAP method description used when
authentication method is 'eap'.";
reference
"Section 2.16 in RFC 7296.";
}
container pre-shared {
when
"../auth-method[.='pre-shared' or
.='eap']";
leaf secret {
nacm:default-deny-all;
type yang:hex-string;
description
"Pre-shared secret value. The
NSF has to prevent read access
to this value for security
reasons.";
}
description
"Shared secret value for PSK or
EAP method authentication based on
PSK.";
}
container digital-signature {
when
"../auth-method[.='digital-signature'
or .='eap']";
leaf ds-algorithm {
type uint8;
description
"The digital signature
algorithm is specified with a
value extracted from the IANA
Registry. Depending on the
algorithm, the following leafs
must contain information. For
example if digital signature
involves a certificate then leaf
'cert-data' and 'private-key'
will contain this information.";
reference
"IKEv2 Authentication Method -
IANA Registry - Internet Key
Exchange Version 2 (IKEv2)
Parameters.";
}
container remote { choice public-key {
description "Remote peer connection information"; mandatory true;
leaf remote-pad-id { type uint64; description " ";} leaf raw-public-key {
} type binary;
description
"A binary that contains the
value of the public key. The
interpretation of the content
is defined by the digital
signature algorithm. For
example, an RSA key is
represented as RSAPublicKey as
defined in RFC 8017, and an
Elliptic Curve Cryptography
(ECC) key is represented
using the 'publicKey'
described in RFC 5915.";
reference
"RFC XXX: Common YANG Data
Types for Cryptography.";
}
leaf cert-data {
type ct:x509;
description
"X.509 certificate data -
PEM4.";
reference
"RFC XXX: Common YANG Data
Types for Cryptography.";
}
description
"If the Security Controller
knows that the NSF
already owns a private key
associated to this public key
(the NSF generated the pair
public key/private key out of
band), it will only configure
one of the leaf of this
choice. The NSF, based on
the public key value can know
the private key to be used.";
}
leaf private-key {
nacm:default-deny-all;
type binary;
description
"A binary that contains the
value of the private key. The
interpretation of the content
is defined by the digital
signature algorithm. For
example, an RSA key is
represented as RSAPrivateKey as
defined in RFC 8017, and an
Elliptic Curve Cryptography
(ECC) key is represented as
ECPrivateKey as defined in RFC
5915.";
reference
"RFC XXX: Common YANG Data
Types for Cryptography.";
}
leaf-list ca-data {
type ct:x509;
description
"List of trusted Certification
Authorities (CA) certificates
encoded using ASN.1
distinguished encoding rules
(DER).";
reference
"RFC XXX: Common YANG Data
Types for Cryptography.";
}
leaf crl-data {
type ct:crl;
description
"A CertificateList structure, as
specified in RFC 5280,
encoded using ASN.1
distinguished encoding rules
(DER),as specified in ITU-T
X.690.";
reference
"RFC XXX: Common YANG Data Types
for Cryptography.";
}
leaf crl-uri {
type inet:uri;
description
"X.509 CRL certificate URI.";
}
leaf oscp-uri {
type inet:uri;
description
"OCSP URI.";
}
description
"Digital Signature container.";
uses ic:encap; } /*container digital-signature*/
} /*container peer-authentication*/
}
}
container spd { list conn-entry {
description "Configure the Security Policy Database (SPD)"; key "name";
list spd-entry { description
key "spd-entry-id"; "IKE peer connection information. This list
uses ic:ipsec-policy-grouping; contains the IKE connection for this peer
ordered-by user; with other peers. This will be translated in
description "List of SPD entries"; real time by IKE Security Associations
} established with these nodes.";
} leaf name {
type string;
mandatory true;
description
"Identifier for this connection
entry.";
}
leaf autostartup {
type autostartup-type;
default add;
description
"By-default: Only add configuration
without starting the security
association.";
}
leaf initial-contact {
type boolean;
default false;
description
"The goal of this value is to deactivate the
usage of INITIAL_CONTACT notification
(true). If this flag remains to false it
means the usage of the INITIAL_CONTACT
notification will depend on the IKEv2
implementation.";
}
leaf version {
type auth-protocol-type;
default ikev2;
description
"IKE version. Only version 2 is supported
so far.";
}
leaf fragmentation {
type boolean;
default false;
description
"Whether or not to enable IKE
fragmentation as per RFC 7383 (true or
false).";
reference
"RFC 7383.";
}
container ike-sa-lifetime-soft {
description
"IKE SA lifetime soft. Two lifetime values
can be configured: either rekey time of the
IKE SA or reauth time of the IKE SA. When
the rekey lifetime expires a rekey of the
IKE SA starts. When reauth lifetime
expires a IKE SA reauthentication starts.";
leaf rekey-time {
type uint32;
default 0;
description
"Time in seconds between each IKE SA
rekey.The value 0 means infinite.";
}
leaf reauth-time {
type uint32;
default 0;
description
"Time in seconds between each IKE SA
reauthentication. The value 0 means
infinite.";
}
reference
"Section 2.8 in RFC 7296.";
}
container ike-sa-lifetime-hard {
description
"Hard IKE SA lifetime. When this
time is reached the IKE SA is removed.";
leaf over-time {
type uint32;
default 0;
description
"Time in seconds before the IKE SA is
removed. The value 0 means infinite.";
}
reference
"RFC 7296.";
}
leaf-list authalg {
type ic:integrity-algorithm-type;
default 12;
ordered-by user;
description
"Authentication algorithm for establishing
the IKE SA. This list is ordered following
from the higher priority to lower priority.
First node of the list will be the algorithm
with higher priority. If this list is empty
the default integrity algorithm value assumed
is NONE.";
}
leaf-list encalg {
type ic:encryption-algorithm-type;
default 12;
ordered-by user;
description
"Encryption or AEAD algorithm for the IKE
SAs. This list is ordered following
from the higher priority to lower priority.
First node of the list will be the algorithm
with higher priority. If this list is empty
the default encryption value assumed is
NULL.";
}
leaf dh-group {
type pfs-group;
default 14;
description
"Group number for Diffie-Hellman
Exponentiation used during IKE_SA_INIT
for the IKE SA key exchange.";
}
leaf half-open-ike-sa-timer {
type uint32;
description
"Set the half-open IKE SA timeout
duration.";
reference
"Section 2 in RFC 7296.";
}
container ike-sa-state { leaf half-open-ike-sa-cookie-threshold {
container uptime { type uint32;
description "IKE service uptime"; description
leaf running { type yang:date-and-time; description "Relative uptime";} "Number of half-open IKE SAs that activate
leaf since { type yang:date-and-time; description "Absolute uptime";} the cookie mechanism." ;
} reference
"Section 2.6 in RFC 7296.";
}
container local {
leaf local-pad-entry-name {
type string;
description
"Local peer authentication information.
This node points to a specific entry in
the PAD where the authorization
information about this particular local
peer is stored. It MUST match a
pad-entry-name.";
}
description
"Local peer authentication information.";
}
container remote {
leaf remote-pad-entry-name {
type string;
description
"Remote peer authentication information.
This node points to a specific entry in
the PAD where the authorization
information about this particular
remote peer is stored. It MUST match a
pad-entry-name.";
}
description
"Remote peer authentication information.";
}
container encapsulation-type
{
uses ic:encap;
description
"This container carries configuration
information about the source and destination
ports of encapsulation that IKE should use
and the type of encapsulation that
should use when NAT traversal is required.
However, this is just a best effort since
the IKE implementation may need to use a
different encapsulation as
described in RFC 8229.";
reference
"RFC 8229.";
}
container spd {
description
"Configuration of the Security Policy
Database (SPD). This main information is
placed in the grouping
ipsec-policy-grouping.";
list spd-entry {
key "name";
ordered-by user;
leaf name {
type string;
mandatory true;
description
"SPD entry unique name to identify
the IPsec policy.";
}
container ipsec-policy-config {
description
"This container carries the
configuration of a IPsec policy.";
uses ic:ipsec-policy-grouping;
}
description
"List of entries which will constitute
the representation of the SPD. Since we
have IKE in this case, it is only
required to send a IPsec policy from
this NSF where 'local' is this NSF and
remote the other NSF. The IKE
implementation will install IPsec
policies in the NSF's kernel in both
directions (inbound and outbound) and
their corresponding IPsec SAs based on
the information in this SPD entry.";
}
reference
"Section 2.9 in RFC 7296.";
}
container child-sa-info {
leaf-list pfs-groups {
type pfs-group;
default 0;
ordered-by user;
description
"If non-zero, it is required perfect
forward secrecy when requesting new
IPsec SA. The non-zero value is
the required group number. This list is
ordered following from the higher
priority to lower priority. First node
of the list will be the algorithm
with higher priority.";
}
container child-sa-lifetime-soft {
description
"Soft IPsec SA lifetime soft.
After the lifetime the action is
defined in this container
in the leaf action.";
uses ic:lifetime;
leaf action {
type ic:lifetime-action;
default replace;
description
"When the lifetime of an IPsec SA
expires an action needs to be
performed over the IPsec SA that
reached the lifetime. There are
three possible options:
terminate-clear, terminate-hold and
replace.";
reference
"Section 4.5 in RFC 4301 and Section 2.8
in RFC 7296.";
}
}
container child-sa-lifetime-hard {
description
"IPsec SA lifetime hard. The action will
be to terminate the IPsec SA.";
uses ic:lifetime;
reference
"Section 2.8 in RFC 7296.";
}
description
"Specific information for IPsec SAs
SAs. It includes PFS group and IPsec SAs
rekey lifetimes.";
}
container state {
config false;
leaf initiator { type boolean; description "It is acting as initiator in this connection";} leaf initiator {
leaf initiator-ikesa-spi {type uint64; description "Initiator's IKE SA SPI";} type boolean;
leaf responder-ikesa-spi {type uint64; description "Responsder's IKE SA SPI";} description
leaf nat-local {type boolean; description "YES, if local endpoint is behind a NAT";} "It is acting as initiator for this
leaf nat-remote {type boolean; description "YES, if remote endpoint is behind a NAT";} connection.";
leaf nat-any {type boolean; description "YES, if both local and remote endpoints are behind a NAT";} }
leaf initiator-ikesa-spi {
type ike-spi;
description
"Initiator's IKE SA SPI.";
}
leaf responder-ikesa-spi {
type ike-spi;
description
"Responder's IKE SA SPI.";
}
leaf nat-local {
type boolean;
description
"True, if local endpoint is behind a
NAT.";
}
leaf nat-remote {
type boolean;
description
"True, if remote endpoint is behind
a NAT.";
}
container encapsulation-type
{
uses ic:encap;
description
"This container provides information
about the source and destination
ports of encapsulation that IKE is
using, and the type of encapsulation
when NAT traversal is required.";
reference
"RFC 8229.";
}
leaf established {
type uint64;
description
"Seconds since this IKE SA has been
established.";
}
leaf current-rekey-time {
type uint64;
description
"Seconds before IKE SA must be rekeyed.";
}
leaf current-reauth-time {
type uint64;
description
"Seconds before IKE SA must be
re-authenticated.";
}
description
"IKE state data for a particular
connection.";
} /* ike-sa-state */
} /* ike-conn-entries */
uses ic:encap; container number-ike-sas {
config false;
leaf total {
type uint64;
description
"Total number of active IKE SAs.";
}
leaf half-open {
type uint64;
description
"Number of half-open active IKE SAs.";
}
leaf half-open-cookies {
type uint64;
description
"Number of half open active IKE SAs with
cookie activated.";
}
description
"General information about the IKE SAs. In
particular, it provides the current number of
IKE SAs.";
}
} /* container ipsec-ike */
}
leaf established {type uint64; description "Seconds the IKE SA has been established";} <CODE ENDS>
leaf rekey-time {type uint64; description "Seconds before IKE SA gets rekeyed";}
leaf reauth-time {type uint64; description "Seconds before IKE SA gets re-authenticated";}
list child-sas {
container spis{
description "IPsec SA's SPI '";
leaf spi-in {type ic:ipsec-spi; description "Security Parameter Index for inbound IPsec SA";}
leaf spi-out {type ic:ipsec-spi; description "Security Parameter Index for the corresponding outbound IPsec SA";}
} Appendix C. Appendix C: YANG model for IKE-less case
description "State data about IKE CHILD SAs";
}
config false;
description "IKE state data";
} /* ike-sa-state */
} /* ike-conn-entries */
container number-ike-sas{ <CODE BEGINS> file "ietf-ipsec-ikeless@2019-07-07.yang"
leaf total {type uint32; description "Total number of IKEv2 SAs";}
leaf half-open {type uint32; description "Number of half-open IKEv2 SAs";}
leaf half-open-cookies {type uint32; description "Number of half open IKE SAs with cookie activated" ;}
config false;
description "Number of IKE SAs";
}
} /* container ikev2 */
}
<CODE ENDS> module ietf-ipsec-ikeless {
Appendix C. Appendix C: YANG model for IKE-less case yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless";
<CODE BEGINS> file "ietf-ipsec-ikeless@2019-03-11.yang" prefix "ikeless";
module ietf-ipsec-ikeless { import ietf-yang-types { prefix yang; }
yang-version 1.1; import ietf-ipsec-common {
namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless"; prefix ic;
reference
"Common Data model for SDN-based IPSec
configuration.";
}
prefix "ipsec-ikeless"; import ietf-netconf-acm {
prefix nacm;
reference
"RFC 8341: Network Configuration Access Control
Model.";
}
organization "IETF I2NSF Working Group";
import ietf-yang-types { prefix yang; } contact
"WG Web: <https://datatracker.ietf.org/wg/i2nsf/about/>
WG List: <mailto:i2nsf@ietf.org>
import ietf-ipsec-common { Author: Rafael Marin-Lopez
prefix ic; <mailto:rafa@um.es>
reference "Common Data model for SDN-based IPSec configuration";
}
organization "IETF I2NSF (Interface to Network Security Functions) Working Group"; Author: Gabriel Lopez-Millan
<mailto:gabilm@um.es>
contact Author: Fernando Pereniguez-Garcia
" Rafael Marin Lopez <mailto:fernando.pereniguez@cud.upct.es>
Dept. Information and Communications Engineering (DIIC) ";
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501
e-mail: rafa@um.es
Gabriel Lopez Millan description
Dept. Information and Communications Engineering (DIIC) "Data model for IKE-less case in the SDN-base IPsec flow
Faculty of Computer Science-University of Murcia protection service.
30100 Murcia - Spain
Tel: +34 868888504
email: gabilm@um.es
Fernando Pereniguez Garcia Copyright (c) 2019 IETF Trust and the persons
Department of Sciences and Informatics identified as authors of the code. All rights reserved.
University Defense Center (CUD), Spanish Air Force Academy, MDE-UPCT Redistribution and use in source and binary forms, with
30720 San Javier - Spain or without modification, is permitted pursuant to, and
Tel: +34 968189946 subject to the license terms contained in, the
email: fernando.pereniguez@cud.upct.es Simplified BSD License set forth in Section 4.c of the
"; IETF Trust's Legal Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info).
description "Data model for IKE-less case"; This version of this YANG module is part of RFC XXXX;;
see the RFC itself for full legal notices.
revision "2019-03-11" { The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
description "Revision"; 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
reference ""; 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this
} document are to be interpreted as described in BCP 14
(RFC 2119) (RFC 8174) when, and only when, they appear
in all capitals, as shown here.";
/*################## SAD grouping ####################*/ revision "2019-07-07" {
grouping ipsec-sa-grouping { description "Revision 05";
description "Configure Security Association (SA). Section 4.4.2.1 in RFC 4301"; reference "RFC XXXX: YANG model for IKE case.";
}
leaf sad-entry-id {type uint64; description "This value identifies a specific entry in the SAD";} container ipsec-ikeless {
leaf spi { type ic:ipsec-spi; description "Security Parameter Index. This may not be unique for a particular SA";} description
leaf seq-number { type uint64; description "Current sequence number of IPsec packet."; } "Container for configuration of the IKE-less
leaf seq-number-overflow-flag { type boolean; description "The flag indicating whether overflow of the sequence number counter should prevent transmission of additional packets on the SA, or whether rollover is permitted."; } case. The container contains two additional
leaf anti-replay-window { type uint16 { range "0 | 32..1024"; } description "Anti replay window size"; } containers: 'spd' and 'sad'. The first allows the
leaf spd-entry-id {type uint64; description "This value links the SA with the SPD entry";} Security Controller to configure IPsec policies in
the Security Policy Database SPD, and the second
allows to configure IPsec Security Associations
(IPsec SAs) in the Security Association Database
(SAD).";
reference "RFC 4301.";
container spd {
description
"Configuration of the Security Policy Database
(SPD.)";
reference "Section 4.4.1.2 in RFC 4301.";
uses ic:selector-grouping; list spd-entry {
key "name";
ordered-by user;
leaf name {
type string;
mandatory true;
description
"SPD entry unique name to identify this
entry.";
}
leaf direction {
type ic:ipsec-traffic-direction;
description
"Inbound traffic or outbound
traffic. In the IKE-less case the
Security Controller needs to
specify the policy direction to be
applied in the NSF. In the IKE case
this direction does not need to be
specified since IKE
will determine the direction that
IPsec policy will require.";
}
leaf reqid {
type uint64;
default 0;
description
"This value allows to link this
IPsec policy with IPsec SAs with the
same reqid. It is only required in
the IKE-less model since, in the IKE
case this link is handled internally
by IKE.";
leaf security-protocol { type ic:ipsec-protocol; description "Security protocol of IPsec SA: Either AH or ESP."; } }
container sad-lifetime-hard { container ipsec-policy-config {
description "SAD lifetime hard state data. The action associated is terminate."; description
uses ic:lifetime; "This container carries the
} configuration of a IPsec policy.";
container sad-lifetime-soft { uses ic:ipsec-policy-grouping;
description "SAD lifetime hard state data"; }
uses ic:lifetime; description
leaf action {type ic:lifetime-action; description "action lifetime";} "The SPD is represented as a list of SPD
} entries, where each SPD entry represents an
IPsec policy.";
} /*list spd-entry*/
} /*container spd*/
leaf mode { type ic:ipsec-mode; description "SA Mode"; } container sad {
leaf statefulfragCheck { type boolean; description "Indicates whether (TRUE) or not (FALSE) stateful fragment checking (RFC 4301) applies to this SA."; } description
"Configuration of the IPSec Security Association
Database (SAD)";
reference "Section 4.4.2.1 in RFC 4301.";
list sad-entry {
key "name";
ordered-by user;
leaf name {
type string;
description
"SAD entry unique name to identify this
entry.";
}
leaf reqid {
type uint64;
default 0;
description
"This value allows to link this
IPsec SA with an IPsec policy with
the same reqid.";
}
leaf dscp { type yang:hex-string; description "DSCP value"; } container ipsec-sa-config {
leaf path-mtu { type uint16; description "Maximum size of an IPsec packet that can be transmitted without fragmentation"; } description
"This container allows configuring
details of an IPsec SA.";
leaf spi {
type uint32 { range "0..max"; }
mandatory true;
description
"Security Parameter Index (SPI)'s
IPsec SA.";
container tunnel { }
when "../mode = 'TUNNEL'"; leaf ext-seq-num {
uses ic:tunnel-grouping; type boolean;
description "Container for tunnel grouping"; default true;
} description
"True if this IPsec SA is using
extended sequence numbers. True 64
bit counter, FALSE 32 bit.";
}
leaf seq-number-counter {
type uint64;
default 0;
description
"A 64-bit counter when this IPsec
SA is using Extended Sequence
Number or 32-bit counter when it
is not. It used to generate the
initial Sequence Number field
in ESP headers.";
}
leaf seq-overflow {
type boolean;
default false;
description
"The flag indicating whether
overflow of the sequence number
counter should prevent transmission
of additional packets on the IPsec
SA (false) and, therefore needs to
be rekeyed, or whether rollover is
permitted (true). If Authenticated
Encryption with Associated Data
(AEAD) is used this flag MUST BE
false.";
}
leaf anti-replay-window {
type uint32;
default 32;
description
"A 32-bit counter and a bit-map (or
equivalent) used to determine
whether an inbound ESP packet is a
replay. If set to 0 no anti-replay
mechanism is performed.";
}
container traffic-selector {
uses ic:selector-grouping;
description
"The IPsec SA traffic selector.";
}
leaf protocol-parameters {
type ic:ipsec-protocol-parameters;
default esp;
description
"Security protocol of IPsec SA: Only
ESP so far.";
}
leaf mode {
type ic:ipsec-mode;
description
"Tunnel or transport mode.";
}
container esp-sa {
when "../protocol-parameters =
'esp'";
description
"In case the IPsec SA is
Encapsulation Security Payload
(ESP), it is required to specify
encryption and integrity
algorithms, and key material.";
uses ic:encap; container encryption {
description
"Configuration of encryption or
AEAD algorithm for IPSec
Encapsulation Security Payload
(ESP).";
// STATE DATA for SA leaf encryption-algorithm {
container sad-lifetime-current { type ic:encryption-algorithm-type;
uses ic:lifetime; description
config false; "Configuration of ESP
description "SAD lifetime current state data"; encryption. With AEAD
} algorithms, the integrity
node is not used.";
}
container stats { // xfrm.h leaf key {
leaf replay-window {type uint32; default 0; description " "; } nacm:default-deny-all;
leaf replay {type uint32; default 0; description "packets detected out of the replay window and dropped because they are replay packets";} type yang:hex-string;
leaf failed {type uint32; default 0; description "packets detected out of the replay window ";} description
config false; "ESP encryption key value.";
description "SAD statistics"; }
} leaf iv {
nacm:default-deny-all;
type yang:hex-string;
description
"ESP encryption IV value.";
}
}
container integrity {
description
"Configuration of integrity for
IPSec Encapsulation Security
Payload (ESP). This container
allows to configure integrity
algorithm when no AEAD
algorithms are used, and
integrity is required.";
leaf integrity-algorithm {
type ic:integrity-algorithm-type;
description
"Message Authentication Code
(MAC) algorithm to provide
integrity in ESP.";
}
leaf key {
nacm:default-deny-all;
type yang:hex-string;
description
"ESP integrity key value.";
}
}
} /*container esp-sa*/
container replay_state { // xfrm.h container sa-lifetime-hard {
leaf seq {type uint32; default 0; description "input traffic sequence number when anti-replay-window != 0";} description
leaf oseq {type uint32; default 0; description "output traffic sequence number";} "IPsec SA hard lifetime. The action
leaf bitmap {type uint32; default 0; description "";} associated is terminate and
config false; hold.";
description "Anti-replay Sequence Number state"; uses ic:lifetime;
} }
container sa-lifetime-soft {
description
"IPSec SA soft lifetime.";
uses ic:lifetime;
leaf action {
type ic:lifetime-action;
description
"Action lifetime:
terminate-clear,
terminate-hold or replace.";
}
container replay_state_esn { // xfrm.h }
leaf bmp-len {type uint32; default 0; description "bitmap length for ESN"; } container tunnel {
leaf oseq { type uint32; default 0; description "output traffic sequence number"; } when "../mode = 'tunnel'";
leaf oseq-hi { type uint32; default 0; description ""; } uses ic:tunnel-grouping;
leaf seq-hi { type uint32; default 0; description ""; } description
leaf replay-window {type uint32; default 0; description ""; } "Endpoints of the IPsec tunnel.";
leaf-list bmp { type uint32; description "bitmaps for ESN (depends on bmp-len) "; } }
config false; container encapsulation-type
description "Anti-replay Extended Sequence Number (ESN) state"; {
} uses ic:encap;
description
"This container carries
configuration information about
the source and destination ports
which will be used for ESP
encapsulation that ESP packets the
type of encapsulation when NAT
traversal is in place.";
}
} /*ipsec-sa-config*/
} container ipsec-sa-state {
/*################## end SAD grouping ##################*/ config false;
description
"Container describing IPsec SA state
data.";
container sa-lifetime-current {
uses ic:lifetime;
description
"SAD lifetime current.";
}
container replay-stats {
description
"State data about the anti-replay
window.";
leaf replay-window {
type uint64;
description
"Current state of the replay
window.";
}
leaf packet-dropped {
type uint64;
description
"Packets detected out of the
replay window and dropped
because they are replay
packets.";
/*################# Register grouping #################*/ }
typedef sadb-msg-type { leaf failed {
type enumeration { type uint32;
enum sadb_acquire { description "SADB_ACQUIRE"; } description
enum sadb_expire { description "SADB_EXPIRE"; } "Number of packets detected out
} of the replay window.";
description "Notifications (PF_KEY message types) that must be forwarded by the NSF to the controller in IKE-less case"; }
} leaf seq-number-counter {
type uint64;
description
"A 64-bit counter when this
IPsec SA is using Extended
Sequence Number or 32-bit
counter when it is not.
Current value of sequence
number.";
}
} /* container replay-stats*/
} /*ipsec-sa-state*/
typedef sadb-msg-satype { description
type enumeration { "List of SAD entries that conforms the SAD.";
enum sadb_satype_unspec { description "SADB_SATYPE_UNSPEC"; } } /*list sad-entry*/
enum sadb_satype_ah { description "SADB_SATYPE_AH"; } } /*container sad*/
enum sadb_satype_esp { description "SADB_SATYPE_ESP"; } }/*container ipsec-ikeless*/
enum sadb_satype_rsvp { description "SADB_SATYPE_RSVP"; }
enum sadb_satype_ospfv2 { description "SADB_SATYPE_OSPFv2"; }
enum sadb_satype_ripv2 { description "SADB_SATYPE_RIPv2"; }
enum sadb_satype_mip { description "SADB_SATYPE_MIP"; }
enum sadb_satype_max { description "SADB_SATYPE_MAX"; }
}
description "PF_KEY Security Association types";
}
grouping base-grouping { /* Notifications */
description "Configuration for the message header format"; notification sadb-acquire {
list base-list { description
key "version"; "An IPsec SA is required. The traffic-selector
leaf version { type string; description "Version of PF_KEY (MUST be PF_KEY_V2)"; } container contains information about the IP packet
leaf msg_type { type sadb-msg-type; description "Identifies the type of message"; } that triggers the acquire notification.";
leaf msg_satype { type sadb-msg-satype; description "Defines the type of Security Association"; } leaf ipsec-policy-name {
leaf msg_seq { type uint32; description "Sequence number of this message."; } type string;
description "Configuration for a specific message header format"; mandatory true;
} description
"It contains the SPD entry name (unique) of
the IPsec policy that hits the IP packet
required IPsec SA. It is assumed the
Security Controller will have a copy of the
information of this policy so it can
extract all the information with this
unique identifier. The type of IPsec SA is
defined in the policy so the Security
Controller can also know the type of IPsec
SA that must be generated.";
}
container traffic-selector {
description
"The IP packet that triggered the acquire
and requires an IPsec SA. Specifically it
will contain the IP source/mask and IP
destination/mask; protocol (udp, tcp,
etc...); and source and destination
ports.";
uses ic:selector-grouping;
} }
/*################# End Register grouping #################*/ }
/*################## IPsec configuration ##################*/
container ietf-ipsec {
description "IPsec configuration";
container spd { notification sadb-expire {
description "Configure the Security Policy Database (SPD)"; description "An IPsec SA expiration (soft or hard).";
list spd-entry { leaf ipsec-sa-name {
key "spd-entry-id"; type string;
uses ic:ipsec-policy-grouping; mandatory true;
ordered-by user; description
description "List of SPD entries"; "It contains the SAD entry name (unique) of
} the IPsec SA that has expired. It is assumed
} the Security Controller will have a copy of the
IPsec SA information (except the cryptographic
material and state data) indexed by this name
(unique identifier) so it can know all the
information (crypto algorithms, etc.) about
the IPsec SA that has expired in order to
perform a rekey (soft lifetime) or delete it
(hard lifetime) with this unique identifier.";
}
leaf soft-lifetime-expire {
type boolean;
default true;
description
"If this value is true the lifetime expired is
soft. If it is false is hard.";
}
container lifetime-current {
description
"IPsec SA current lifetime. If
soft-lifetime-expired is true this container is
set with the lifetime information about current
soft lifetime.";
uses ic:lifetime;
}
}
notification sadb-seq-overflow {
description "Sequence overflow notification.";
leaf ipsec-sa-name {
type string;
mandatory true;
description
"It contains the SAD entry name (unique) of
the IPsec SA that is about to have sequence
number overflow and rollover is not permitted.
It is assumed the Security Controller will have
a copy of the IPsec SA information (except the
cryptographic material and state data) indexed
by this name (unique identifier) so the it can
know all the information (crypto algorithms,
etc.) about the IPsec SA that has expired in
order to perform a rekey of the IPsec SA.";
}
}
notification sadb-bad-spi {
description
"Notify when the NSF receives a packet with an
incorrect SPI (i.e. not present in the SAD).";
leaf spi {
type uint32 { range "0..max"; }
mandatory true;
description
"SPI number contained in the erroneous IPsec
packet.";
}
}
}/*module ietf-ipsec*/
container sad { <CODE ENDS>
description "Configure the IPSec Security Association Database (SAD)";
list sad-entry { Appendix D. Example of IKE case, tunnel mode (gateway-to-gateway) with
key "sad-entry-id"; X.509 certificate authentication.
uses ipsec-sa-grouping; This example shows a XML configuration file sent by the Security
Controller to establish a IPsec Security Association between two NSFs
in tunnel mode (gateway-to-gateway) with ESP, and authentication
based on X.509 certificates using IKEv2.
container ah-sa { Security Controller
when "../security-protocol = 'ah'"; |
description "Configure Authentication Header (AH) for SA"; /---- Southbound interface -----\
container integrity { / \
description "Configure integrity for IPSec Authentication Header (AH)"; / \
leaf integrity-algorithm { type ic:integrity-algorithm-t; description "Configure Authentication Header (AH)."; } / \
leaf key { type string; description "AH key value";} / \
} 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
container esp-sa { Figure 7: IKE case, tunnel mode , X.509 certicate authentication.
when "../security-protocol = 'esp'";
description "Set IPSec Encapsulation Security Payload (ESP)";
container encryption { <ipsec-ike xmlns="urn:ietf:params:xml:ns:yang:ietf-ipsec-ike"
description "Configure encryption for IPSec Encapsulation Secutiry Payload (ESP)"; xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
leaf encryption-algorithm { type ic:encryption-algorithm-t; description "Configure ESP encryption"; } <pad>
leaf key { type yang:hex-string; description "ESP encryption key value";} <pad-entry>
leaf iv {type yang:hex-string; description "ESP encryption IV value"; } <name>nsf_h1_pad</name>
} <ipv6-address>2001:DB8:123::100</ipv6-address>
<peer-authentication>
<auth-method>digital-signature</auth-method>
<digital-signature>
<cert-data>base64encodedvalue==</cert-data>
<private-key>base64encodedvalue==</private-key>
<ca-data>base64encodedvalue==</ca-data>
</digital-signature>
</peer-authentication>
</pad-entry>
<pad-entry>
<name>nsf_h2_pad</name>
<ipv6-address>2001:DB8:123::200</ipv6-address>
<auth-protocol>ikev2</auth-protocol>
<peer-authentication>
<auth-method>digital-signature</auth-method>
<digital-signature>
<!-- RSA Digital Signature -->
<ds-algorithm>1</ds-algorithm>
<cert-data>base64encodedvalue==</cert-data>
<ca-data>base64encodedvalue==</ca-data>
</digital-signature>
</peer-authentication>
</pad-entry>
</pad>
<conn-entry>
<name>nsf_h1-nsf_h2</name>
<autostartup>start</autostartup>
<version>ikev2</version>
<initial-contact>false</initial-contact>
<fragmentation>true</fragmentation>
<ike-sa-lifetime-soft>
<rekey-time>60</rekey-time>
<reauth-time>120</reauth-time>
</ike-sa-lifetime-soft>
<ike-sa-lifetime-hard>
<over-time>3600</over-time>
</ike-sa-lifetime-hard>
<authalg>7</authalg>
<!--AUTH_HMAC_SHA1_160-->
<encalg>3</encalg>
<!--ENCR_3DES -->
<dh-group>18</dh-group>
<!--8192-bit MODP Group-->
<half-open-ike-sa-timer>30</half-open-ike-sa-timer>
<half-open-ike-sa-cookie-threshold>15</half-open-ike-sa-cookie-threshold>
<local>
<local-pad-entry-name>nsf_h1_pad</local-pad-entry-name>
</local>
<remote>
<remote-pad-entry-name>nsf_h2_pad</remote-pad-entry-name>
</remote>
<spd>
<spd-entry>
<name>nsf_h1-nsf_h2</name>
<ipsec-policy-config>
<anti-replay-window>32</anti-replay-window>
<traffic-selector>
<local-subnet>2001:DB8:1::0/64</local-subnet>
<remote-subnet>2001:DB8:2::0/64</remote-subnet>
<inner-protocol>any</inner-protocol>
<local-ports>
<start>0</start>
<end>0</end>
</local-ports>
<remote-ports>
<start>0</start>
<end>0</end>
</remote-ports>
</traffic-selector>
<processing-info>
<action>protect</action>
<ipsec-sa-cfg>
<pfp-flag>false</pfp-flag>
<ext-seq-num>true</ext-seq-num>
<seq-overflow>false</seq-overflow>
<stateful-frag-check>false</stateful-frag-check>
<mode>tunnel</mode>
<protocol-parameters>esp</protocol-parameters>
<esp-algorithms>
<!-- AUTH_HMAC_SHA1_96 -->
<integrity>2</integrity>
<!-- ENCR_AES_CBC -->
<encryption>12</encryption>
<tfc-pad>false</tfc-pad>
</esp-algorithms>
<tunnel>
<local>2001:DB8:123::100</local>
<remote>2001:DB8:123::200</remote>
<df-bit>clear</df-bit>
<bypass-dscp>true</bypass-dscp>
<ecn>false</ecn>
</tunnel>
</ipsec-sa-cfg>
</processing-info>
</ipsec-policy-config>
</spd-entry>
</spd>
<child-sa-info>
<!--8192-bit MODP Group -->
<pfs-groups>18</pfs-groups>
<child-sa-lifetime-soft>
<bytes>1000000</bytes>
<packets>1000</packets>
<time>30</time>
<idle>60</idle>
<action>replace</action>
</child-sa-lifetime-soft>
<child-sa-lifetime-hard>
<bytes>2000000</bytes>
<packets>2000</packets>
<time>60</time>
<idle>120</idle>
</child-sa-lifetime-hard>
</child-sa-info>
</conn-entry>
</ipsec-ike>
container integrity { Appendix E. Example of IKE-less case, transport mode (host-to-host).
description "Configure authentication for IPSec Encapsulation Secutiry Payload (ESP)";
leaf integrity-algorithm { type ic:integrity-algorithm-t; description "Configure Authentication Header (AH)."; }
leaf key { type yang:hex-string; description "ESP integrity key value";}
}
/* With AEAD algorithms, the integrity node is not used */
leaf combined-enc-intr { type boolean; description "ESP combined mode algorithms. The algorithm is specified in encryption-algorithm";} This example shows a XML configuration file sent by the Security
} Controller to establish a IPsec Security association between two NSFs
description "List of SAD entries"; in transport mode (host-to-host) with ESP.
}
}
} /* container ietf-ipsec */
/*################## RPC and Notifications ##################*/ Security Controller
|
/---- Southbound interface -----\
/ \
/ \
/ \
/ \
nsf_h1 nsf_h2
(:100)===== IPsec_ESP_Transport_mode =====(:200)
(2001:DB8:123:/64)
// These RPCs are needed by a Security Controller in IKEless case Figure 8: IKE-less case, transport mode.
notification spdb_expire { <ipsec-ikeless
description "A SPD entry has expired"; xmlns="urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless"
leaf index { type uint64; description "SPD index. RFC4301 does not mention an index however real implementations (e.g. XFRM or PFKEY_v2 with KAME extensions provide a policy index to refer a policy. "; } xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
} <spd>
<spd-entry>
<name>
in/trans/2001:DB8:123::200/2001:DB8:123::100
</name>
<direction>inbound</direction>
<reqid>1</reqid>
<ipsec-policy-config>
<traffic-selector>
<local-subnet>2001:DB8:123::200/128</local-subnet>
<remote-subnet>2001:DB8:123::100/128</remote-subnet>
<inner-protocol>any</inner-protocol>
<local-ports>
<start>0</start>
<end>0</end>
</local-ports>
<remote-ports>
<start>0</start>
<end>0</end>
</remote-ports>
</traffic-selector>
<processing-info>
<action>protect</action>
<ipsec-sa-cfg>
<ext-seq-num>true</ext-seq-num>
<seq-overflow>true</seq-overflow>
<mode>transport</mode>
<protocol-parameters>esp</protocol-parameters>
<esp-algorithms>
<!--AUTH_HMAC_SHA1_96-->
<integrity>2</integrity>
<!--ENCR_AES_CBC -->
<encryption>12</encryption>
</esp-algorithms>
</ipsec-sa-cfg>
</processing-info>
</ipsec-policy-config>
</spd-entry>
<spd-entry>
<name>out/trans/2001:DB8:123::100/2001:DB8:123::200</name>
<direction>outbound</direction>
<reqid>1</reqid>
<ipsec-policy-config>
<traffic-selector>
<local-subnet>2001:DB8:123::100/128</local-subnet>
<remote-subnet>2001:DB8:123::200/128</remote-subnet>
<inner-protocol>any</inner-protocol>
<local-ports>
<start>0</start>
<end>0</end>
</local-ports>
<remote-ports>
<start>0</start>
<end>0</end>
</remote-ports>
</traffic-selector>
<processing-info>
<action>protect</action>
<ipsec-sa-cfg>
<ext-seq-num>true</ext-seq-num>
<seq-overflow>true</seq-overflow>
<mode>transport</mode>
<protocol-parameters>esp</protocol-parameters>
<esp-algorithms>
<!-- AUTH_HMAC_SHA1_96 -->
<integrity>2</integrity>
<!-- ENCR_AES_CBC -->
<encryption>12</encryption>
</esp-algorithms>
</ipsec-sa-cfg>
</processing-info>
</ipsec-policy-config>
</spd-entry>
</spd>
<sad>
<sad-entry>
<name>out/trans/2001:DB8:123::100/2001:DB8:123::200</name>
<reqid>1</reqid>
<ipsec-sa-config>
<spi>34501</spi>
<ext-seq-num>true</ext-seq-num>
<seq-number-counter>100</seq-number-counter>
<seq-overflow>true</seq-overflow>
<anti-replay-window>32</anti-replay-window>
<traffic-selector>
<local-subnet>2001:DB8:123::100/128</local-subnet>
<remote-subnet>2001:DB8:123::200/128</remote-subnet>
<inner-protocol>any</inner-protocol>
<local-ports>
<start>0</start>
<end>0</end>
</local-ports>
<remote-ports>
<start>0</start>
<end>0</end>
</remote-ports>
</traffic-selector>
<protocol-parameters>esp</protocol-parameters>
<mode>transport</mode>
<esp-sa>
<encryption>
<!-- //ENCR_AES_CBC -->
<encryption-algorithm>12</encryption-algorithm>
<key>01:23:45:67:89:AB:CE:DF</key>
<iv>01:23:45:67:89:AB:CE:DF</iv>
</encryption>
<integrity>
<!-- //AUTH_HMAC_SHA1_96 -->
<integrity-algorithm>2</integrity-algorithm>
<key>01:23:45:67:89:AB:CE:DF</key>
</integrity>
</esp-sa>
</ipsec-sa-config>
</sad-entry>
<sad-entry>
<name>in/trans/2001:DB8:123::200/2001:DB8:123::100</name>
<reqid>1</reqid>
<ipsec-sa-config>
<spi>34502</spi>
<ext-seq-num>true</ext-seq-num>
<seq-number-counter>100</seq-number-counter>
<seq-overflow>true</seq-overflow>
<anti-replay-window>32</anti-replay-window>
<traffic-selector>
<local-subnet>2001:DB8:123::200/128</local-subnet>
<remote-subnet>2001:DB8:123::100/128</remote-subnet>
<inner-protocol>any</inner-protocol>
<local-ports>
<start>0</start>
<end>0</end>
</local-ports>
<remote-ports>
<start>0</start>
<end>0</end>
</remote-ports>
</traffic-selector>
<protocol-parameters>esp</protocol-parameters>
<mode>transport</mode>
<esp-sa>
<encryption>
<!-- //ENCR_AES_CBC -->
<encryption-algorithm>12</encryption-algorithm>
<key>01:23:45:67:89:AB:CE:DF</key>
<iv>01:23:45:67:89:AB:CE:DF</iv>
</encryption>
<integrity>
<!-- //AUTH_HMAC_SHA1_96 -->
<integrity-algorithm>2</integrity-algorithm>
<key>01:23:45:67:89:AB:CE:DF</key>
</integrity>
</esp-sa>
<sa-lifetime-hard>
<bytes>2000000</bytes>
<packets>2000</packets>
<time>60</time>
<idle>120</idle>
</sa-lifetime-hard>
<sa-lifetime-soft>
<bytes>1000000</bytes>
<packets>1000</packets>
<time>30</time>
<idle>60</idle>
<action>replace</action>
</sa-lifetime-soft>
</ipsec-sa-config>
</sad-entry>
</sad>
</ipsec-ikeless>
notification sadb_acquire { Appendix F. Examples of notifications.
description "A IPsec SA is required ";
uses base-grouping;
uses ic:selector-grouping; // To indicate the concrete traffic selector of the policy that triggered this acquire.
}
notification sadb_expire { Below we show several XML files that represent different types of
description "A IPsec SA expiration (soft or hard)"; notifications defined in the IKE-less YANG model, which are sent by
the NSF to the Security Controller. The notifications happen in the
IKE-less case.
uses base-grouping; <sadb-expire xmlns="urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless">
leaf spi { type ic:ipsec-spi; description "Security Parameter Index";} <ipsec-sa-name>in/trans/2001:DB8:123::200/2001:DB8:123::100</ipsec-sa-name>
leaf anti-replay-window { type uint16 { range "0 | 32..1024"; } description "Anti replay window"; } <soft-lifetime-expire>true</soft-lifetime-expire>
<lifetime-current>
<bytes>1000000</bytes>
<packets>1000</packets>
<time>30</time>
<idle>60</idle>
</lifetime-current>
</sadb-expire>
leaf encryption-algorithm { type ic:encryption-algorithm-t; description "encryption algorithm of the expired SA"; } Figure 9: Example of sadb-expire notification.
leaf authentication-algorithm { type ic:integrity-algorithm-t; description "authentication algorithm of the expired SA"; }
container sad-lifetime-hard { <sadb-acquire xmlns="urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless">
description "SAD lifetime hard state data"; <ipsec-policy-name>in/trans/2001:DB8:123::200/2001:DB8:123::100</ipsec-policy-name>
uses ic:lifetime; <traffic-selector>
} <local-subnet>2001:DB8:123::200/128</local-subnet>
container sad-lifetime-soft { <remote-subnet>2001:DB8:123::100/128</remote-subnet>
description "SAD lifetime soft state data"; <inner-protocol>any</inner-protocol>
uses ic:lifetime; <local-ports>
} <start>0</start>
<end>0</end>
</local-ports>
<remote-ports>
<start>0</start>
<end>0</end>
</remote-ports>
</traffic-selector>
</sadb-acquire>
container sad-lifetime-current { Figure 10: Example of sadb-acquire notification.
description "SAD lifetime current state data";
uses ic:lifetime;
}
} <sadb-seq-overflow 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>
</sadb-seq-overflow>
notification sadb_bad-spi { Figure 11: Example of sadb-seq-overflow notification.
description "Notifiy when the NSF receives a packet with an incorrect SPI (i.e. not present in the SAD)";
leaf state { type ic:ipsec-spi; mandatory "true"; description "SPI number contained in the erroneous IPsec packet"; }
}
}/*module ietf-ipsec*/ <sadb-bad-spi
xmlns="urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless">
<spi>666</spi>
</sadb-bad-spi>
<CODE ENDS> Figure 12: Example of sadb-bad-spi notification.
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. 276 change blocks. 
1478 lines changed or deleted 2999 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/