draft-ietf-i2nsf-sdn-ipsec-flow-protection-03.txt   draft-ietf-i2nsf-sdn-ipsec-flow-protection-04.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: April 25, 2019 October 22, 2018 Expires: September 12, 2019 F. Pereniguez-Garcia
University Defense Center
March 11, 2019
Software-Defined Networking (SDN)-based IPsec Flow Protection Software-Defined Networking (SDN)-based IPsec Flow Protection
draft-ietf-i2nsf-sdn-ipsec-flow-protection-03 draft-ietf-i2nsf-sdn-ipsec-flow-protection-04
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
skipping to change at page 1, line 44 skipping to change at page 1, line 46
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 April 25, 2019. This Internet-Draft will expire on September 12, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. SDN-based IPsec management description . . . . . . . . . . . 6 5. SDN-based IPsec management description . . . . . . . . . . . 6
5.1. Case 1: IKE/IPsec in the NSF . . . . . . . . . . . . . . 6 5.1. IKE case: IKE/IPsec in the NSF . . . . . . . . . . . . . 6
5.1.1. Interface Requirements for Case 1 . . . . . . . . . . 7 5.1.1. Interface Requirements for IKE case . . . . . . . . . 7
5.2. Case 2: IPsec (no IKEv2) in the NSF . . . . . . . . . . . 7 5.2. IKE-less case: IPsec (no IKEv2) in the NSF . . . . . . . 8
5.2.1. Interface Requirements for Case 2 . . . . . . . . . . 8 5.2.1. Interface Requirements for IKE-less case . . . . . . 8
5.3. Case 1 vs Case 2 . . . . . . . . . . . . . . . . . . . . 8 5.3. IKE case vs IKE-less case . . . . . . . . . . . . . . . . 9
5.3.1. Rekeying process . . . . . . . . . . . . . . . . . . 9 5.3.1. Rekeying process . . . . . . . . . . . . . . . . . . 10
5.3.2. NSF state loss . . . . . . . . . . . . . . . . . . . 10 5.3.2. NSF state loss . . . . . . . . . . . . . . . . . . . 11
5.3.3. NAT Traversal . . . . . . . . . . . . . . . . . . . . 10 5.3.3. NAT Traversal . . . . . . . . . . . . . . . . . . . . 12
6. YANG configuration data models . . . . . . . . . . . . . . . 11 6. YANG configuration data models . . . . . . . . . . . . . . . 12
6.1. Security Policy Database (SPD) Model . . . . . . . . . . 11 6.1. IKE case model . . . . . . . . . . . . . . . . . . . . . 13
6.2. Security Association Database (SAD) Model . . . . . . . . 13 6.2. IKE-less case model . . . . . . . . . . . . . . . . . . . 16
6.3. Peer Authorization Database (PAD) Model . . . . . . . . . 16 7. Use cases examples . . . . . . . . . . . . . . . . . . . . . 21
6.4. Internet Key Exchange (IKEv2) Model . . . . . . . . . . . 17 7.1. Host-to-host or gateway-to-gateway under the same
7. Use cases examples . . . . . . . . . . . . . . . . . . . . . 19 controller . . . . . . . . . . . . . . . . . . . . . . . 21
7.1. Host-to-Host or Gateway-to-gateway under the same 7.2. Host-to-host or gateway-to-gateway under different
controller . . . . . . . . . . . . . . . . . . . . . . . 19 security controllers . . . . . . . . . . . . . . . . . . 23
7.2. Host-to-Host or Gateway-to-gateway under different 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25
Security controllers . . . . . . . . . . . . . . . . . . 22 8.1. IKE case . . . . . . . . . . . . . . . . . . . . . . . . 26
8. Implementation notes . . . . . . . . . . . . . . . . . . . . 24 8.2. IKE-less case . . . . . . . . . . . . . . . . . . . . . . 26
9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
9.1. Case 1 . . . . . . . . . . . . . . . . . . . . . . . . . 26 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
9.2. Case 2 . . . . . . . . . . . . . . . . . . . . . . . . . 26 10.1. Normative References . . . . . . . . . . . . . . . . . . 27
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 10.2. Informative References . . . . . . . . . . . . . . . . . 28
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 Appendix A. Appendix A: Common YANG model for IKE and IKEless
11.1. Normative References . . . . . . . . . . . . . . . . . . 27 cases . . . . . . . . . . . . . . . . . . . . . . . 31
11.2. Informative References . . . . . . . . . . . . . . . . . 27 Appendix B. Appendix B: YANG model for IKE case . . . . . . . . 37
Appendix C. Appendix C: YANG model for IKE-less case . . . . . . 43
Appendix A. Appendix A: YANG model IPsec Configuration data . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48
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. SDN paradigm relocates the control of
network resources to a dedicated network element, namely SDN network resources to a dedicated network element, namely SDN
controller. The SDN controller manages and configures the controller. The SDN controller manages and configures the
distributed network resources and provides an abstracted view of the distributed network resources and provides an abstracted view of the
network resources to the SDN applications. The SDN application can network resources to the SDN applications. The SDN application can
customize and automate the operations (including management) of the customize and automate the operations (including management) of the
abstracted network resources in a programmable manner via this abstracted network resources in a programmable manner via this
interface [RFC7149][ITU-T.Y.3300] interface [RFC7149][ITU-T.Y.3300]
[ONF-SDN-Architecture][ONF-OpenFlow]. [ONF-SDN-Architecture][ONF-OpenFlow].
Typically, traditional IPsec VPN concentrators and, in general, Recently, several network scenarios are considering a centralized way
entities (i.e. hosts or security gateways) supporting IKE/IPsec, must of managing different security aspects. For example, Software-
be configured directly by the administrator. This makes the IPsec Defined WANs (SD-WAN) advocates to manage IPsec SAs from a
security association (SA) management difficult and generates a lack centralized point. Therefore, with the growth of SDN-based scenarios
of flexibility, specially if the number of security policies and SAs where network resources are deployed in an autonomous manner, a
to handle is high. With the growth of SDN-based scenarios where mechanism to manage IPsec SAs according to the SDN architecture
network resources are deployed in an autonomous manner, a mechanism becomes more relevant. Thus, the SDN-based service described in this
to manage IPsec SAs according to the SDN architecture becomes more document will autonomously deal with IPsec SAs management following a
relevant. Thus, the SDN-based service described in this document SDN paradigm.
will autonomously deal with IPsec SAs management.
An example of usage can be the notion of Software Defined WAN (SD- An example of usage can be the notion of Software Defined WAN (SD-
WAN), SDN extension providing a software abstraction to create secure WAN), SDN extension providing a software abstraction to create secure
network overlays over traditional WAN and branch networks. SD-WAN is network overlays over traditional WAN and branch networks. SD-WAN is
based on IPsec as underlying security protocol and aims to provide based on IPsec as underlying security protocol and aims to provide
flexible, automated, fast deployment and on-demand security network flexible, automated, fast deployment and on-demand security network
services. services.
IPsec architecture [RFC4301] defines a clear separation between the IPsec architecture [RFC4301] defines a 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 entity: the Security
Controller. 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) The Network Security Function (NSF) implements the Internet Key 1) IKE case. The Network Security Function (NSF) implements the
Exchange (IKE) protocol and the IPsec databases: the Security Internet Key Exchange (IKE) protocol and the IPsec databases: the
Policy Database (SPD), the Security Association Database (SAD) Security Policy Database (SPD), the Security Association Database
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) The NSF only implements the IPsec databases (no IKE 2) IKE-less case. The NSF only implements the IPsec databases (no
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 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, Case 1 requires the provision of SPD and PAD the NSF. In particular, IKE case requires the provision of SPD and
entries and the IKE credential and information related with the IKE PAD entries and the IKE credential and information related with the
negotiation (e.g. IKE_SA_INIT); and Case 2 requires the management IKE negotiation (e.g. IKE_SA_INIT), and IKE-less case requires the
of SPD and SAD entries. Based on YANG models in [netconf-vpn] and management of SPD and SAD entries. Based on YANG models in
[I-D.tran-ipsecme-yang], RFC 4301 [RFC4301] and RFC 7296 [RFC7296] [netconf-vpn] and [I-D.tran-ipsecme-yang], RFC 4301 [RFC4301] and RFC
this document defines the required interfaces with a YANG model for 7296 [RFC7296] this document defines the required interfaces with a
configuration and state data for IKE, PAD, SPD and SAD Appendix A. YANG model for configuration and state data for IKE, PAD, SPD and SAD
(see Appendix A, Appendix B and Appendix C).
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]. The
analysis of the host-to-gateway (roadwarrior) scenario is TBD. In analysis of the host-to-gateway (roadwarrior) scenario is out of
these cases, host or gateways or both may act as NSFs. Finally, it scope of this document. In these cases, host or gateways or both may
also discusses the situation where two NSFs are under the control of act as NSFs. Finally, it also discusses the situation where two NSFs
two different Security Controllers. are under the control of two different Security Controllers.
NOTE: This work pays attention to the challenge "Lack of Mechanism NOTE: This work pays attention to the challenge "Lack of Mechanism
for Dynamic Key Distribution to NSFs" defined in for Dynamic Key Distribution to NSFs" defined in [RFC8192] in the
[I-D.ietf-i2nsf-problem-and-use-cases] in the particular case of the particular case of the establishment and management of IPsec SAs. In
establishment and management of IPsec SAs. In fact, this I-D could fact, this I-D could be considered as a proper use case for this
be considered as a proper use case for this particular challenge in particular challenge in [RFC8192].
[I-D.ietf-i2nsf-problem-and-use-cases].
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
skipping to change at page 5, line 20 skipping to change at page 5, line 16
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. A Controller is a management component that
contains control plane functions to manage and facilitate contains control plane functions to manage and facilitate
information sharing, as well as execute security functions. In information sharing, as well as execute security functions. In
the context of this document, it provides IPsec management the context of this document, it 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 falls 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. preshared keys), DH groups, required authentication method (i.e. raw RSA/ECDSA keys or X.509
modes and algorithms for IKE SA negotiation, etc. certificates), DH groups, modes 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. inbound and outboud 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
flow. 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 such as IKE
or the SDN-based solution described in this document. or the SDN-based solution described in this document.
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 to management of IPsec security associations from a central point, in
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 in the NSF from a Security Controller. YANG
models are defined for configuration and state data for IPsec 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:
5.1. Case 1: 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 SPD and PAD entries (deriving and delivering IKE Credentials
such as a pre-shared key, certificates, etc.), and applying other IKE such as a pre-shared key, certificates, etc.), and applying other IKE
configuration parameters (e.g. IKE_SA_INIT algorithms) to the NSF configuration parameters (e.g. IKE_SA_INIT algorithms) to the NSF
for the IKE negotiation. 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), and the Security Controller (through the Client Facing Interface, [RFC8192]), and the Security
translates those requirements into IKE, SPD and PAD entries that will Controller translates those requirements into IKE, SPD and PAD
be installed into the NSF (through the NSF Facing Interface). With entries that will be installed into the NSF (through the NSF Facing
that information, the NSF can just run IKEv2 to establish the Interface). With that information, the NSF can just run IKEv2 to
required IPsec SA (when the data flow needs protection). Figure 1 establish the required IPsec SA (when the data flow needs
shows the different layers and corresponding functionality. protection). Figure 1 shows the different layers and corresponding
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: Case 1: IKE/IPsec in the NSF Figure 1: IKE case: IKE/IPsec in the NSF
5.1.1. Interface Requirements for Case 1 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 NSF. In order to support this
capability in case 1, the following interface requirements are to be capability in case IKE case, the following interface requirements are
met: to be met:
o A YANG data model for Configuration data for IKEv2, SPD and PAD. o A YANG data model for configuration data for IKEv2, SPD and PAD.
o A YANG data model for State data for IKE, SPD, PAD and SAD (NOTE: o A YANG data model for state data for IKE, PAD, SPD and SAD (NOTE:
the SAD entries are created in runtime by IKEv2.) the SAD entries are created in runtime by IKEv2.)
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 is required to exchange IPsec-related an east-west interface [RFC7426] is required to exchange IPsec-
information. related information. For example, if two gateways need to
establish an IPsec SA and both are under the control of two
different controllers then both Security Controllers need to
exchange information to properly configure their own gateways.
That is, the may need to agree on whether IKEv2 authentication
will be based on raw public keys or pre-shared keys. In case of
using pre-shared keys they will have to agree in the PSK.
5.2. Case 2: 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 management of IPsec SAs by Security Controller has to perform the IKE security functions and
populating and monitoring the SPD and the SAD. management of IPsec SAs by populating and managing the SPD and the
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: Case 2: 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 those 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 Case 2 5.2.1. Interface Requirements for IKE-less case
In order to support case 2, the following requirements are to be met: In order to support the IKE-less case, the following requirements are
to be met:
o A YANG data model for Configuration data for SPD and SAD. 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 state data for SPD and 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 is required to exchange IPsec-related an east-west interface [RFC7426] is required to exchange IPsec-
information. related information. NOTE: A possible east-west protocol for this
IKE-less case could be IKEv2. However, this needs to be explore
since the IKEv2 peers would be the Security Controllers.
5.3. Case 1 vs Case 2 Specifically, the IKE-less case assumes that the SDN controller has
to perform some security functions that IKEv2 typically does, namely
(non-exhaustive):
Case 1 MAY be easier to deploy than Case 2 because current gateways o IV generation.
typically have an IKEv2/IPsec implementation. Moreover hosts can
install easily an IKE implementation. As downside, the NSF needs
more resources to hold IKEv2. Moreover, the IKEv2 implementation
needs to implement an interface so that the I2NSF Agent can interact
with them.
Alternatively, Case 2 allows lighter NSFs (no IKEv2 implementation), o prevent counter resets for same key.
which benefits the deployment in constrained NSFs. Moreover, IKEv2
does not need to be performed in gateway-to-gateway and host-to-host o Generation of pseudo-random cryptographic keys for the IPsec SAs.
scenarios under the same Security Controller (see Section 7.1). On
the contrary, the overload of creating fresh IPsec SAs is shifted to o Rekey of the IPsec SAs based on notification from the NSF (i.e.
the Security Controller since IKEv2 is not in the NSF. As a expire).
consequence, this may result in a more complex implementation in the
controller side. o Generation of the IPsec SAs when required based on notifications
(i.e. sadb_acquire).
o NAT Traversal discovery and management.
Additionally to these functions, another set of tasks must be
performed by the Controller (non-exhaustive list):
o SPI random generation.
o Cryptographic algorithm/s selection.
o Usage of extended sequence numbers.
o Establishment of proper traffic selectors.
5.3. IKE case vs IKE-less case
IKE case MAY be easier to deploy than IKE-less case because current
gateways typically have an IKEv2/IPsec implementation. Moreover
hosts can install easily an IKE implementation. As downside, the NSF
needs more resources to hold IKEv2. Moreover, the IKEv2
implementation needs to implement an interface so that the I2NSF
Agent can interact with them.
Alternatively, IKE-less case allows lighter NSFs (no IKEv2
implementation), which benefits the deployment in constrained NSFs.
Moreover, IKEv2 does not need to be performed in gateway-to-gateway
and host-to-host scenarios under the same Security Controller (see
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
NSF. As a consequence, this may result in a more complex
implementation in the controller side. This overload may create some
scalability issues when the number of NSFs is high.
In general, literature around SDN-based network management using a
centralized SDN controller is aware about scalability issues and
solutions have been already provided (e.g. hierarchical SDN
controllers; having multiple replicated SDN controllers, etc). In
the context of IPsec management, one straight way to reduce the
overhead and the potential scalability issue in the Security
Controller is to apply IKE case, described in this document, since
the IPsec SAs are managed between NSFs without the involvement of the
Security Controller at all, except by the initial IKE configuration
provided by the Security Controller. Other option with IKE-less is
to use techniques already seen in SDN world such as, for example,
hierarchical SDN controllers. Other solutions, such as Controller-
IKE [I-D.carrel-ipsecme-controller-ike], have proposed that NSFs
provide their DH public keys to the Security Controller, so that the
Security Controller distributes all public keys to all peers. All
peers can calculate a unique pairwise secret for each other peer and
there is no inter-NSF messages. A re-key mechanism is further
described in [I-D.carrel-ipsecme-controller-ike].
In terms of security, IKE case provides better security properties
than IKE-less case, as we discuss in section Section 8. The main
reason is that the Security Controller is not able to observe any
session keys generated for the IPsec SAs because IKEv2 is in charge
of negotiating the IPsec SAs.
5.3.1. Rekeying process 5.3.1. Rekeying process
For case 1, the rekeying process is carried out by IKEv2, following For IKE case, the rekeying process is carried out by IKEv2, following
the configuration defined in the SPD. the information defined in the SPD and SAD.
For case 2, the Security Controller needs to take care of the For 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 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 SA soft lifetime), it has to create a new IPsec SA and remove the old
one. This rekeying process starts when the Security Controller one. This rekeying process starts when the Security Controller
receives a sadb_expire notification or it decides so, based on receives a sadb_expire notification or it decides so, based on
lifetime state data obtained from the NSF. 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 SA in A and SPIb1 the
inbound SA in B. inbound 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 SAs: for example, SPIa2 for A and SPIb2 for B. These
numbers MUST not be in conflict with any IPsec SA in A or B. numbers MUST not be in conflict with any IPsec SA in A or B.
Then,the Security Controller creates an inbound SA with SPIa2 in
Then, the Security Controller creates an inbound SA with SPIa2 in
A and another inbound SA in B with SPIb2. It can send this A and another inbound SA in B with SPIb2. It can send this
information simultenously 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 inbound SA are correctly installed. Then it proceeds to send in
parallel to A and B the outbound SAs: it sends the outbound SA to parallel to A and B the outbound SAs: it sends the outbound SA to
A with SPIb2 and the outbound SA to B with SPIa2. At this point A with SPIb2 and the outbound SA to B with SPIa2. At this point
the new IPsec SA is ready. the new IPsec SA is ready.
3. The Security Controller deletes the old IPsec SAs from A (inbound 3. Once the Security Controller receives confirmation from A and B,
SPIa1 and outbound SPIb1) and B (outbound SPIa1 and inbound that the outbound SAs have been installed, the Security
SPIb1) in parallel. Controller deletes the old IPsec SAs from A (inbound SPIa1 and
outbound SPIb1) and B (outbound SPIa1 and inbound SPIb1) in
parallel. It is worth noting that if the IPsec implementation
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 may lose part or all the IPsec state If one of the NSF restarts, it will lose the IPsec state (affected
(affected NSF). By default, the Security Controller can assume that NSF). By default, the Security Controller can assume that all the
all the state has been lost and therefore it will have to send IKEv2, state has been lost and therefore it will have to send IKEv2, SPD and
SPD and PAD information to the NSF in case 1 and SPD and SAD PAD information to the NSF in IKE case, and SPD and SAD information
information in case 2. in IKE-less case.
In both cases, the Security Controller MUST be aware of the affected In both cases, the Security Controller is aware of the affected NSF
NSF (e.g. the NETCONF/TCP connection is broken with the affected NSF, (e.g. the NETCONF/TCP connection is broken with the affected NSF, the
it is receiving bad_spi notification from a particular NSF, etc...). Security Controller is receiving sadb_bad-spi notification from a
Moreover, the Security Controller MUST have a register about all the particular NSF, etc.). Moreover, the Security Controller has a
NSFs that have IPsec SAs with the affected NSF. Therefore, it knows register about all the NSFs that have IPsec SAs with the affected
the affected IPsec SAs. NSF. Therefore, it knows the affected IPsec SAs.
In Case 1, 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) to the NSFs which have IKEv2 SAs parameters (e.g. a new fresh PSK for authentication) to the NSFs
and IPsec SAs with the affected NSF. It can also instruct the which have IKEv2 SAs and IPsec SAs with the affected NSF. It can
affected NSF to send IKEv2 INITIAL_CONTACT (It is TBD in the model). also instruct the affected NSF to send IKEv2 INITIAL_CONTACT.
Finally, the Security Controller will instruct the affected NSF to Finally, the Security Controller will instruct the affected NSF to
start the IKEv2 negotiation with the new configuration. start the IKEv2 negotiation with the new configuration.
In Case 2, if the Security Controller detects that a NSF has lost the In IKE-less case, if the Security Controller detects that a NSF has
IPsec SAs (e.g. it reboots) it will follow similar steps to rekey: lost the IPsec SAs (e.g. it reboots) it will delete the old IPsec SAs
the steps 1 and 2 remain equal but the step 3 will be slightly of the non-failed nodes established with the failed node (step 1).
different. For example, if we assume that NSF B has lost its state, This prevents the non-failed nodes from leaking plaintext. If the
the Security Controller MUST only delete the old IPsec SAs from A in failed node comes to live, the Security Controller will configure the
step 3. new inbound IPsec SAs between the failed node and all the nodes the
failed was talking to (step 2). After these inbound IPsec SAs have
been established, the Security Controller can configure the outbound
IPsec SAs (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 IKEv2 configuration permanent between reboots).
5.3.3. NAT Traversal 5.3.3. NAT Traversal
In case 1, IKEv2 already owns a mechanism to detect whether some of In IKE case, IKEv2 already owns a mechanism to detect whether some of
the peers or both are behind a NAT. If there is a NAT network the peers or both are located behind a NAT. If there is a NAT
configured between two peers, it is required to activate the usage of network configured between two peers, it is required to activate the
UDP or TCP/TLS encapsulation of ESP packets ([RFC3948], [RFC8229]) usage of UDP or TCP/TLS encapsulation of ESP packets ([RFC3948],
[RFC8229]). Note that the usage of TRANSPORT mode when NAT is
required is forbidden in this specification.
On the contrary, case 2 does not have any protocol in the NSFs to On the contrary, IKE-less case does not have any protocol in the NSFs
detect whether they are behind a NAT or not. However, the SDN to detect whether they are located behind a NAT or not. However, the
paradigm generally assumes the Security Controller has a view of the SDN paradigm generally assumes the Security Controller has a view of
network it controls. This view is built either requesting the network it controls. This view is built either requesting
information to the NSFs under its control, or because these NSFs information to the NSFs under its control, or because these NSFs
inform to the Security Controller. Based on this information, the inform to the Security Controller. Based on this information, the
Security Controller can guess if there is a NAT configured between Security Controller can guess if there is a NAT configured between
two hosts, apply the required policies to both NSFs besides two hosts, and apply the required policies to both NSFs besides
activating the usage of UDP or TCP/TLS encapsulation of ESP packets activating the usage of UDP or TCP/TLS encapsulation of ESP packets
([RFC3948], [RFC8229]). ([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.sivakumar-yang-nat] a data model for NAT management. [I-D.ietf-opsawg-nat-yang] a data model for NAT management. The
Security Controller can use this NETCONF module with a gateway to
collect NAT information or even configure a NAT. In any case, if
this NETCONF module is not available and the Security Controller
cannot know if a host is behind a NAT or not, then IKE case should be
the right choice and not the IKE-less.
6. YANG configuration data models 6. YANG configuration data models
In order to support case 1 and case 2 we have modelled the different In order to support IKE case and IKE-less case we have modelled the
parameters and values that must be configured to manage IPsec SAs. different parameters and values that must be configured to manage
Specifically, case 1 requires modelling IKEv2, SPD and PAD while case IPsec SAs. Specifically, IKE requires modeling IKEv2, SPD and PAD
2 requires models for the SPD and SAD. A single YANG file represents while IKE-less case requires configuration models for the SPD and
both cases though some part of the models are selectively activated SAD. We have defined three models: ietf-ipsec-common (Appendix A),
depending a feature defined in the YANG file. For example, the IKE ietf-ipsec-ike (Appendix B, IKE case), ietf-ipsec-ikeless
configuration is not enabled in case 2. (Appendix C, IKE-less case). Since the model ietf-ipsec-common has
only typedef and groupings common to the other modules, in the
In the following, we summarize, by using a tree representation, the following we only show a simplified view of the ietf-ipsec-ike and
different configuration and state data models. The complete YANG ietf-ipsec-ikeless models.
configuration data model is in Appendix A
6.1. Security Policy Database (SPD) Model
The definition of this model has been extracted from the
specification in section 4.4.1 and Appendix D in [RFC4301]
+--rw spd
| +--rw spd-entry* [rule-number]
| +--rw rule-number uint64
| +--rw priority? uint32
| +--rw names* [name]
| | +--rw name-type? ipsec-spd-name
| | +--rw name string
| +--rw condition
| | +--rw traffic-selector-list* [ts-number]
| | +--rw ts-number uint32
| | +--rw direction? ipsec-traffic-direction
| | +--rw local-addresses* [start end]
| | | +--rw start inet:ip-address
| | | +--rw end inet:ip-address
| | +--rw remote-addresses* [start end]
| | | +--rw start inet:ip-address
| | | +--rw end inet:ip-address
| | +--rw next-layer-protocol* ipsec-next-layer-proto
| | +--rw local-ports* [start end]
| | | +--rw start inet:port-number
| | | +--rw end inet:port-number
| | +--rw remote-ports* [start end]
| | | +--rw start inet:port-number
| | | +--rw end inet:port-number
| | +--rw selector-priority? uint32
| +--rw processing-info
| | +--rw action ipsec-spd-operation
| | +--rw ipsec-sa-cfg
| | +--rw pfp-flag? boolean
| | +--rw extSeqNum? boolean
| | +--rw seqOverflow? boolean
| | +--rw statefulfragCheck? boolean
| | +--rw security-protocol? ipsec-protocol
| | +--rw mode? ipsec-mode
| | +--rw ah-algorithms
| | | +--rw ah-algorithm* integrity-algorithm-t
| | +--rw esp-algorithms
| | | +--rw authentication* integrity-algorithm-t
| | | +--rw encryption* encryption-algorithm-t
| | +--rw tunnel
| | +--rw local? inet:ip-address
| | +--rw remote? inet:ip-address
| | +--rw bypass-df? boolean
| | +--rw bypass-dscp? boolean
| | +--rw dscp-mapping? yang:hex-string
| | +--rw ecn? boolean
| +--rw spd-mark
| | +--rw mark? uint32
| | +--rw mask? yang:hex-string
| +--rw spd-lifetime-hard
| | +--rw added? uint64
| | +--rw used? uint64
| | +--rw bytes? uint32
| | +--rw packets? uint32
| | +--rw action? lifetime-action
| +--rw spd-lifetime-soft
| | +--rw added? uint64
| | +--rw used? uint64
| | +--rw bytes? uint32
| | +--rw packets? uint32
| | +--rw action? lifetime-action
| +--ro spd-lifetime-current
| +--ro added? uint64
| +--ro used? uint64
| +--ro bytes? uint32
| +--ro packets? uint32
6.2. Security Association Database (SAD) Model 6.1. IKE case model
The definition of this model has been extracted from the The model related to IKEv2 has been extracted from reading IKEv2
specification in section 4.4.2 in [RFC4301] standard in [RFC7296], and observing some open source
implementations, such as Strongswan or Libreswan.
+--rw sad The definition of the PAD model has been extracted from the
| +--rw sad-entry* [spi] specification in section 4.4.3 in [RFC4301] (NOTE: We have observed
| +--rw spi ipsec-spi that many implementations integrate PAD configuration as part of the
| +--rw seq-number? uint64 IKEv2 configuration.)
| +--rw seq-number-overflow-flag? boolean
| +--rw anti-replay-window? uint16
| +--rw rule-number? uint32
| +--rw local-addresses* [start end]
| | +--rw start inet:ip-address
| | +--rw end inet:ip-address
| +--rw remote-addresses* [start end]
| | +--rw start inet:ip-address
| | +--rw end inet:ip-address
| +--rw next-layer-protocol* ipsec-next-layer-proto
| +--rw local-ports* [start end]
| | +--rw start inet:port-number
| | +--rw end inet:port-number
| +--rw remote-ports* [start end]
| | +--rw start inet:port-number
| | +--rw end inet:port-number
| +--rw security-protocol? ipsec-protocol
| +--rw ah-sa
| | +--rw integrity
| | +--rw integrity-algorithm? integrity-algorithm-t
| | +--rw key? string
| +--rw esp-sa
| | +--rw encryption
| | | +--rw encryption-algorithm? encryption-algorithm-t
| | | +--rw key? string
| | | +--rw iv? string
| | +--rw integrity
| | | +--rw integrity-algorithm? integrity-algorithm-t
| | | +--rw key? string
| | +--rw combined-enc-intr? boolean
| +--rw sad-lifetime-hard
| | +--rw added? uint64
| | +--rw used? uint64
| | +--rw bytes? uint32
| | +--rw packets? uint32
| | +--rw action? lifetime-action
| +--rw sad-lifetime-soft
| | +--rw added? uint64
| | +--rw used? uint64
| | +--rw bytes? uint32
| | +--rw packets? uint32
| | +--rw action? lifetime-action
| +--rw mode? ipsec-mode
| +--rw statefulfragCheck? boolean
| +--rw dscp? yang:hex-string
| +--rw path-mtu? uint16
| +--rw tunnel
| | +--rw local? inet:ip-address
| | +--rw remote? inet:ip-address
| | +--rw bypass-df? boolean
| | +--rw bypass-dscp? boolean
| | +--rw dscp-mapping? yang:hex-string
| | +--rw ecn? boolean
| +--rw encap
| | +--rw espencap? esp-encap
| | +--rw sport? inet:port-number
| | +--rw dport? inet:port-number
| | +--rw oaddr? inet:ip-address
| +--ro sad-lifetime-current
| | +--ro added? uint64
| | +--ro used? uint64
| | +--ro bytes? uint32
| | +--ro packets? uint32
| +--ro state? sa-state
| +--ro stats
| | +--ro replay-window? uint32
| | +--ro replay? uint32
| | +--ro failed? uint32
| +--ro replay_state
| | +--ro seq? uint32
| | +--ro oseq? uint32
| | +--ro bitmap? uint32
| +--ro replay_state_esn
| +--ro bmp-len? uint32
| +--ro oseq? uint32
| +--ro oseq-hi? uint32
| +--ro seq-hi? uint32
| +--ro replay-window? uint32
| +--ro bmp* uint32
rpcs: module: ietf-ipsec-ike
+---x sadb_register +--rw ikev2
+---w input +--rw pad
| +---w base-list* [version] | +--rw pad-entry* [pad-entry-id]
| +---w version string | +--rw pad-entry-id uint64
| +---w msg_type? sadb-msg-type | +--rw (identity)?
| +---w msg_satype? sadb-msg-satype | | +--:(ipv4-address)
| +---w msg_seq? uint32 | | | +--rw ipv4-address? inet:ipv4-address
+--ro output | | +--:(ipv6-address)
+--ro base-list* [version] | | | +--rw ipv6-address? inet:ipv6-address
| +--ro version string | | +--:(fqdn-string)
| +--ro msg_type? sadb-msg-type | | | +--rw fqdn-string? inet:domain-name
| +--ro msg_satype? sadb-msg-satype | | +--:(rfc822-address-string)
| +--ro msg_seq? uint32 | | | +--rw rfc822-address-string? string
+--ro algorithm-supported* | | +--:(dnX509)
+--ro authentication | | | +--rw dnX509? string
| +--ro name? integrity-algorithm-t | | +--:(id_key)
| +--ro ivlen? uint8 | | | +--rw id_key? string
| +--ro min-bits? uint16 | | +--:(id_null)
| +--ro max-bits? uint16 | | | +--rw id_null? empty
+--ro encryption | | +--:(user_fqdn)
+--ro name? encryption-algorithm-t | | +--rw user_fqdn? string
+--ro ivlen? uint8 | +--rw my-identifier string
+--ro min-bits? uint16 | +--rw pad-auth-protocol? auth-protocol-type
+--ro max-bits? uint16 | +--rw auth-method
| +--rw auth-m? auth-method-type
| +--rw eap-method
| | +--rw eap-type? uint8
| +--rw pre-shared
| | +--rw secret? yang:hex-string
| +--rw digital-signature
| +--rw ds-algorithm? signature-algorithm-t
| +--rw raw-public-key? yang:hex-string
| +--rw key-data? string
| +--rw key-file? string
| +--rw ca-data* string
| +--rw ca-file? string
| +--rw cert-data? string
| +--rw cert-file? string
| +--rw crl-data? string
| +--rw crl-file? string
| +--rw oscp-uri? inet:uri
+--rw ike-conn-entry* [conn-name]
| +--rw conn-name string
| +--rw autostartup type-autostartup
| +--rw initial-contact? boolean
| +--rw version? enumeration
| +--rw ike-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 time? yang:timestamp
| | +--rw idle? yang:timestamp
| | +--rw bytes? uint32
| | +--rw packets? uint32
| | +--rw action? ic:lifetime-action
| +--rw ike-sa-authalg* ic:integrity-algorithm-t
| +--rw ike-sa-encalg* ic:encryption-algorithm-t
| +--rw dh_group uint32
| +--rw half-open-ike-sa-timer? uint32
| +--rw half-open-ike-sa-cookie-threshold? uint32
| +--rw local
| | +--rw local-pad-id? uint64
| +--rw remote
| | +--rw remote-pad-id? uint64
| +--rw espencap? esp-encap
| +--rw sport? inet:port-number
| +--rw dport? inet:port-number
| +--rw oaddr* inet:ip-address
| +--rw spd
| | +--rw spd-entry* [spd-entry-id]
| | +--rw spd-entry-id uint64
| | +--rw priority? uint32
| | +--rw anti-replay-window? uint16
| | +--rw names* [name]
| | | +--rw name-type? ipsec-spd-name
| | | +--rw name string
| | +--rw condition
| | | +--rw traffic-selector-list* [ts-number]
| | | +--rw ts-number uint32
| | | +--rw direction? ipsec-traffic-direction
| | | +--rw local-subnet? inet:ip-prefix
| | | +--rw remote-subnet? inet:ip-prefix
| | | +--rw upper-layer-protocol* ipsec-upper-layer-proto
| | | +--rw local-ports* [start end]
| | | | +--rw start inet:port-number
| | | | +--rw end inet:port-number
| | | +--rw remote-ports* [start end]
| | | +--rw start inet:port-number
| | | +--rw end inet:port-number
| | +--rw processing-info
| | | +--rw action ipsec-spd-operation
| | | +--rw ipsec-sa-cfg
| | | +--rw pfp-flag? boolean
| | | +--rw extSeqNum? boolean
| | | +--rw seqOverflow? boolean
| | | +--rw statefulfragCheck? boolean
| | | +--rw security-protocol? ipsec-protocol
| | | +--rw mode? ipsec-mode
| | | +--rw ah-algorithms
| | | | +--rw ah-algorithm* integrity-algorithm-t
| | | | +--rw trunc-length? uint32
| | | +--rw esp-algorithms
| | | | +--rw authentication* integrity-algorithm-t
| | | | +--rw encryption* encryption-algorithm-t
| | | | +--rw tfc_pad? uint32
| | | +--rw tunnel
| | | +--rw local? inet:ip-address
| | | +--rw remote? inet:ip-address
| | | +--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
| +--ro ike-sa-state
| +--ro uptime
| | +--ro running? yang:date-and-time
| | +--ro since? yang:date-and-time
| +--ro initiator? boolean
| +--ro initiator-ikesa-spi? uint64
| +--ro responder-ikesa-spi? uint64
| +--ro nat-local? boolean
| +--ro nat-remote? boolean
| +--ro nat-any? boolean
| +--ro espencap? esp-encap
| +--ro sport? inet:port-number
| +--ro dport? inet:port-number
| +--ro oaddr* inet:ip-address
| +--ro established? uint64
| +--ro rekey-time? uint64
| +--ro 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 total? uint32
+--ro half-open? uint32
+--ro half-open-cookies? uint32
notifications: 6.2. IKE-less case model
+---n spdb_expire
| +--ro index? uint64
+---n sadb_acquire
| +--ro base-list* [version]
| +--ro version string
| +--ro msg_type? sadb-msg-type
| +--ro msg_satype? sadb-msg-satype
| +--ro msg_seq? 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? ipsec-spi
| +--ro anti-replay-window? uint16
| +--ro state? sa-state
| +--ro encryption-algorithm? encryption-algorithm-t
| +--ro authentication-algorithm? integrity-algorithm-t
| +--ro sad-lifetime-hard
| | +--ro added? uint64
| | +--ro used? uint64
| | +--ro bytes? uint32
| | +--ro packets? uint32
| +--ro sad-lifetime-soft
| | +--ro added? uint64
| | +--ro used? uint64
| | +--ro bytes? uint32
| | +--ro packets? uint32
| +--ro sad-lifetime-current
| +--ro added? uint64
| +--ro used? uint64
| +--ro bytes? uint32
| +--ro packets? uint32
+---n sadb_bad-spi
+--ro state ipsec-spi
6.3. Peer Authorization Database (PAD) Model The definition of the SPD model has been mainly extracted from the
specification in section 4.4.1 and Appendix D in [RFC4301]. Unlike
existing implementations (e.g. XFRM), it is worth mentioning that
this model follows [RFC4301] and, consequently, each policy (spd-
entry) consists of one or more traffic selectors.
The definition of this model has been extracted from the The definition of the SAD model has been extracted from the
specification in section 4.4.3 in [RFC4301] (NOTE: We have observed specification in section 4.4.2 in [RFC4301]. Note that this model
that many implementations integrate PAD configuration as part of the not only associates an IPsec SA with its corresponding policy (spd-
IKEv2 configuration.) entry-id) but also indicates the specific traffic selector that
+--rw pad {case1}? caused its establishment. In other words, each traffic selector of a
+--rw pad-entries* [pad-entry-id] policy (spd-entry) generates a different IPsec SA (sad-entry).
+--rw pad-entry-id uint64
+--rw (identity)?
| +--:(ipv4-address)
| | +--rw ipv4-address? inet:ipv4-address
| +--:(ipv6-address)
| | +--rw ipv6-address? inet:ipv6-address
| +--:(fqdn-string)
| | +--rw fqdn-string? inet:domain-name
| +--:(rfc822-address-string)
| | +--rw rfc822-address-string? string
| +--:(dnX509)
| | +--rw dnX509? string
| +--:(id_key)
| +--rw id_key? string
+--rw pad-auth-protocol? auth-protocol-type
+--rw auth-method
+--rw auth-m? auth-method-type
+--rw pre-shared
| +--rw secret? string
+--rw rsa-signature
+--rw key-data? string
+--rw key-file? string
+--rw ca-data* string
+--rw ca-file? string
+--rw cert-data? string
+--rw cert-file? string
+--rw crl-data? string
+--rw crl-file? string
6.4. Internet Key Exchange (IKEv2) Model The notifications model has been defined using as reference the
PF_KEYv2 standard in [RFC2367].
The model related to IKEv2 has been extracted from reading IKEv2 module: ietf-ipsec-ikeless
standard in [RFC7296], and observing some open source +--rw ietf-ipsec
implementations, such as Strongswan or Libreswan. +--rw spd
| +--rw spd-entry* [spd-entry-id]
| +--rw spd-entry-id uint64
| +--rw priority? uint32
| +--rw anti-replay-window? uint16
| +--rw names* [name]
| | +--rw name-type? ipsec-spd-name
| | +--rw name string
| +--rw condition
| | +--rw traffic-selector-list* [ts-number]
| | +--rw ts-number uint32
| | +--rw direction? ipsec-traffic-direction
| | +--rw local-subnet? inet:ip-prefix
| | +--rw remote-subnet? inet:ip-prefix
| | +--rw upper-layer-protocol* ipsec-upper-layer-proto
| | +--rw local-ports* [start end]
| | | +--rw start inet:port-number
| | | +--rw end inet:port-number
| | +--rw remote-ports* [start end]
| | +--rw start inet:port-number
| | +--rw end inet:port-number
| +--rw processing-info
| | +--rw action ipsec-spd-operation
| | +--rw ipsec-sa-cfg
| | +--rw pfp-flag? boolean
| | +--rw extSeqNum? boolean
| | +--rw seqOverflow? boolean
| | +--rw statefulfragCheck? boolean
| | +--rw security-protocol? ipsec-protocol
| | +--rw mode? ipsec-mode
| | +--rw ah-algorithms
| | | +--rw ah-algorithm* integrity-algorithm-t
| | | +--rw trunc-length? uint32
| | +--rw esp-algorithms
| | | +--rw authentication* integrity-algorithm-t
| | | +--rw encryption* encryption-algorithm-t
| | | +--rw tfc_pad? uint32
| | +--rw tunnel
| | +--rw local? inet:ip-address
| | +--rw remote? inet:ip-address
| | +--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-entry* [sad-entry-id]
+--rw sad-entry-id uint64
+--rw spi? ic:ipsec-spi
+--rw seq-number? uint64
+--rw seq-number-overflow-flag? boolean
+--rw anti-replay-window? uint16
+--rw spd-entry-id? uint64
+--rw local-subnet? inet:ip-prefix
+--rw remote-subnet? inet:ip-prefix
+--rw upper-layer-protocol* ipsec-upper-layer-proto
+--rw local-ports* [start end]
| +--rw start inet:port-number
| +--rw end inet:port-number
+--rw remote-ports* [start end]
| +--rw start inet:port-number
| +--rw end inet:port-number
+--rw security-protocol? ic:ipsec-protocol
+--rw sad-lifetime-hard
| +--rw time? yang:timestamp
| +--rw idle? yang:timestamp
| +--rw bytes? uint32
| +--rw packets? uint32
+--rw sad-lifetime-soft
| +--rw time? yang:timestamp
| +--rw idle? yang:timestamp
| +--rw bytes? uint32
| +--rw packets? uint32
| +--rw action? ic:lifetime-action
+--rw mode? ic:ipsec-mode
+--rw statefulfragCheck? boolean
+--rw dscp? yang:hex-string
+--rw path-mtu? uint16
+--rw tunnel
| +--rw local? inet:ip-address
| +--rw remote? inet:ip-address
| +--rw bypass-df? boolean
| +--rw bypass-dscp? boolean
| +--rw dscp-mapping? yang:hex-string
| +--rw ecn? boolean
+--rw espencap? esp-encap
+--rw sport? inet:port-number
+--rw dport? inet:port-number
+--rw oaddr* inet:ip-address
+--ro sad-lifetime-current
| +--ro time? yang:timestamp
| +--ro idle? yang:timestamp
| +--ro bytes? uint32
| +--ro packets? uint32
+--ro stats
| +--ro replay-window? uint32
| +--ro replay? uint32
| +--ro failed? uint32
+--ro replay_state
| +--ro seq? uint32
| +--ro oseq? uint32
| +--ro bitmap? uint32
+--ro replay_state_esn
| +--ro bmp-len? uint32
| +--ro oseq? uint32
| +--ro oseq-hi? uint32
| +--ro seq-hi? uint32
| +--ro replay-window? uint32
| +--ro bmp* uint32
+--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
+--rw ikev2 {case1}? notifications:
| +--rw ike-connection +---n spdb_expire
| | +--rw ike-conn-entries* [conn-name] | +--ro index? uint64
| | +--rw conn-name string +---n sadb_acquire
| | +--rw autostartup type-autostartup | +--ro base-list* [version]
| | +--rw nat-traversal? boolean | | +--ro version string
| | +--rw initial-contact? boolean | | +--ro msg_type? sadb-msg-type
| | +--rw encap | | +--ro msg_satype? sadb-msg-satype
| | | +--rw espencap? esp-encap | | +--ro msg_seq? uint32
| | | +--rw sport? inet:port-number | +--ro local-subnet? inet:ip-prefix
| | | +--rw dport? inet:port-number | +--ro remote-subnet? inet:ip-prefix
| | | +--rw oaddr? inet:ip-address | +--ro upper-layer-protocol* ipsec-upper-layer-proto
| | +--rw version? enumeration | +--ro local-ports* [start end]
| | +--rw phase1-lifetime uint32 | | +--ro start inet:port-number
| | +--rw phase1-authalg* integrity-algorithm-t | | +--ro end inet:port-number
| | +--rw phase1-encalg* encryption-algorithm-t | +--ro remote-ports* [start end]
| | +--rw combined-enc-intr? boolean | +--ro start inet:port-number
| | +--rw dh_group uint32 | +--ro end inet:port-number
| | +--rw local +---n sadb_expire
| | | +--rw (my-identifier-type)? | +--ro base-list* [version]
| | | | +--:(ipv4) | | +--ro version string
| | | | | +--rw ipv4? inet:ipv4-address | | +--ro msg_type? sadb-msg-type
| | | | +--:(ipv6) | | +--ro msg_satype? sadb-msg-satype
| | | | | +--rw ipv6? inet:ipv6-address | | +--ro msg_seq? uint32
| | | | +--:(fqdn) | +--ro spi? ic:ipsec-spi
| | | | | +--rw fqdn? inet:domain-name | +--ro anti-replay-window? uint16
| | | | +--:(dn) | +--ro encryption-algorithm? ic:encryption-algorithm-t
| | | | | +--rw dn? string | +--ro authentication-algorithm? ic:integrity-algorithm-t
| | | | +--:(user_fqdn) | +--ro sad-lifetime-hard
| | | | +--rw user_fqdn? string | | +--ro time? yang:timestamp
| | | +--rw my-identifier string | | +--ro idle? yang:timestamp
| | +--rw remote | | +--ro bytes? uint32
| | | +--rw (my-identifier-type)? | | +--ro packets? uint32
| | | | +--:(ipv4) | +--ro sad-lifetime-soft
| | | | | +--rw ipv4? inet:ipv4-address | | +--ro time? yang:timestamp
| | | | +--:(ipv6) | | +--ro idle? yang:timestamp
| | | | | +--rw ipv6? inet:ipv6-address | | +--ro bytes? uint32
| | | | +--:(fqdn) | | +--ro packets? uint32
| | | | | +--rw fqdn? inet:domain-name | +--ro sad-lifetime-current
| | | | +--:(dn) | +--ro time? yang:timestamp
| | | | | +--rw dn? string | +--ro idle? yang:timestamp
| | | | +--:(user_fqdn) | +--ro bytes? uint32
| | | | +--rw user_fqdn? string | +--ro packets? uint32
| | | +--rw my-identifier string +---n sadb_bad-spi
| | +--rw pfs_group* uint32 +--ro state ic:ipsec-spi
| | +--rw ipsec-sad-lifetime-hard
| | | +--rw added? uint64
| | | +--rw used? uint64
| | | +--rw bytes? uint32
| | | +--rw packets? uint32
| | | +--rw action? lifetime-action
| | +--rw ipsec-sad-lifetime-soft
| | | +--rw added? uint64
| | | +--rw used? uint64
| | | +--rw bytes? uint32
| | | +--rw packets? uint32
| | | +--rw action? lifetime-action
| | +--ro ike-stats
| | +--ro uptime
| | | +--ro running? yang:date-and-time
| | | +--ro since? yang:date-and-time
| | +--ro initiator? boolean
| | +--ro initiator-spi? uint64
| | +--ro responder-spi? uint64
| | +--ro nat-local? boolean
| | +--ro nat-remote? boolean
| | +--ro nat-any? boolean
| | +--ro established? uint64
| | +--ro rekey-time? uint64
| | +--ro reauth-time? uint64
| | +--ro child-sas*
| | +--ro spis
| | +--ro spi-in? ipsec-spi
| | +--ro spi-out? ipsec-spi
| +--ro number-ike-sas
| +--ro total? uint32
| +--ro half-open? uint32
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 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 controller flow
for case 1 . for the IKE case.
Figure 3 describes the case 1: Figure 3 describes the case 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 the SPD and PAD entries in both
NSF1 and NSF2. NSF1 and NSF2.
skipping to change at page 21, line 26 skipping to change at page 22, 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 controller flow
for case 2. for IKE-less case.
In case 2, flow-based security policies defined by the administrator In IKE-less case, flow-based security policies defined by the
are also translated into IPsec SPD entries and inserted into the administrator are translated into IPsec SPD entries and inserted into
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 IKE implementation, and it this case, the controller does not run any IKEv2 implementation, and
provides the cryptographic material for the IPsec SAs. These keys it provides the cryptographic material for the IPsec SAs. These keys
will be also distributed securely through the southbound interface. will be also distributed securely through the southbound interface.
Note that this is possible because both NSFs are managed by the same Note that this is possible because both NSFs are managed by the same
controller. controller.
Figure 4 describes the case 2, when a data packet needs to be Figure 4 describes the IKE-less, 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. 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 the these entries in both NSF1
and NSF2 IPsec databases. and NSF2 IPsec databases. It associates a lifetime to the IPsec
SAs. When this lifetime expires, the NSF will send a sadb_expire
notification to the Security Controller in order to start the
rekeying process.
4. The flow is protected with the IPsec SA established by the 4. The flow is protected with the IPsec SA established by the
Security Controller. Security Controller.
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, for example, 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 case 1 and case 2), this system presents various In general (for IKE and IKE-less case), 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, with only the
application of more general flow-based security policies at the application of more 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. All NSFs deployed after the application of the new policies are
NOT manually configured, therefore allowing its deployment in an NOT manually configured, therefore allowing its deployment in an
automated manner. automated 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.
+-------------+ +-------------+ +-------------+ +-------------+
skipping to change at page 23, line 19 skipping to change at page 24, line 19
(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 Case 1 Figure 5: Different security controllers in IKE case
Figure 5 describes case 1 when two Security Controllers are involved Figure 5 describes IKE case when two security controllers are
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
skipping to change at page 24, line 20 skipping to change at page 25, line 20
| 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 case 2 Figure 6: Different security controllers in IKE-less case
Figure 5 describes case 2 when two Security Controllers are involved Figure 5 describes IKE-less case when two security controllers are
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, the controller notices
that NSF2 is under the control of another Security Controller, so that NSF2 is under the control of another Security Controller, so
skipping to change at page 24, line 46 skipping to change at page 25, line 46
would worth evaluating IKEv2 as the protocol for the East/West would worth evaluating IKEv2 as the protocol for the East/West
interface in this case. interface in this case.
4. Once the Security Controllers have agreed on key material and the 4. Once the Security Controllers have agreed on key material and the
details of the IPsec SAs, they both enforce this information into details of the IPsec SAs, they both enforce this information into
their respective NSFs. 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. Implementation notes 8. Security Considerations
At the time of writing this document, we have implemented a proof-of-
concept using NETCONF as southbound protocol, and the YANG model
described in Appendix A. The netopeer implementation [netopeer] has
been used for both case 1 and case 2 using host-to-host and gateway-
to-gateway configuration. For the case 1, we have used Strongswan
[strongswan] distribution for the IKE implementation.
Note that the proposed YANG model provides the models for SPD, SAD,
PAD and IKE, but, as describe before, only part of them are required
depending of the case (1 or 2) been applied. The Security Controller
should be able to know the kind of case to be applied in the NSF and
to select the corresponding models based on the YANG features defines
for each one.
Internally to the NSF, the NETCONF server (that implements the I2NSF
Agent) is able to apply the required configuration updating the
corresponding NETCONF datastores (running, startup, etc.). Besides,
it can deal with the SPD and SAD configuration at kernel level,
through different APIs. For example, the IETF RFC 2367 (PF_KEYv2)
[RFC2367] provides a generic key management API that can be used not
only for IPsec but also for other network security services to manage
the IPsec SAD. Besides, as an extension to this API, the document
[I-D.pfkey-spd] specifies some PF_KEY extensions to maintain the SPD.
This API is accessed using sockets.
An alternative key management API based on Netlink socket API
[RFC3549] is used to configure IPsec on the Linux Operating System.
To allow the NETCONF server implementation interacts with the IKE
daemon, we have used the Versatile IKE Configuration Interface (VICI)
in Strongswan. This allows changes in the IKE part of the
configuration data to be applied in the IKE daemon dynamically.
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]. On the one hand, it is important to
note that there must exit a security association between the Security note that there MUST exit a security association between the Security
Controller and the NSFs to protect of the critical information Controller and the NSFs to protect of the critical information
(cryptographic keys, configuration parameter, etc...) exchanged (cryptographic keys, configuration parameter, etc...) exchanged
between these entities. For example, if NETCONF is used as between these entities. For example, if NETCONF is used as
southbound protocol between the Security Controller and the NSFs, it southbound protocol between the Security Controller and the NSFs, it
is defined that TLS or SSH security assocation must be established is defined that TLS or SSH security association MUST be established
between both entities. On the other hand, we have divided this between both entities. On the other hand, we have divided this
section in two parts to analyze different security considerations for section in two parts to analyze different security considerations for
both cases: NSF with IKEv2 (case 1) and NSF without IKEv2 (case 2). both cases: NSF with IKEv2 (IKE case) and NSF without IKEv2 (IKE-less
In general, the Security Controller, as typically in the SDN case). In general, the Security Controller, as typically in the SDN
paradigm, is a target for different type of attacks. As a paradigm, is a target for different type of attacks. As a
consequence, the Security Controller is a key entity in the consequence, the Security Controller is a key entity in the
infrastructure and MUST be protected accordingly. In particular, infrastructure and MUST be protected accordingly. In particular,
according to this document, the Security Controller will handle according to this document, 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 case 1 the attack occurs. The impact is different depending on the IKE case
or case 2. or IKE-less case.
9.1. Case 1 8.1. IKE case
In this case 1, 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 SHOULD NEVER
store the IKE credentials after distributing them. Moreover the NSFs store the IKE credentials after distributing them. Moreover the NSFs
MUST NOT allow the reading of these values once they have been MUST NOT allow the reading of these values once they have been
applied by the Security Controller (i.e. write only operations). If applied by the Security Controller (i.e. write only operations). One
the attacker has access to the Security Controller during the period option is return always the same value (all 0s). If the attacker has
of time that key material is generated, it may access to these access to the Security Controller during the period of time that key
values. Since these values are used during NSF authentication in material is generated, it may access to these values. Since these
IKEv2, it may impersonate the affected NSFs. Several recommendations values are used during NSF authentication in IKEv2, it may
are important. If PSK authentication is used in IKEv2, the Security impersonate the affected NSFs. Several recommendations are
important. If PSK authentication is used in IKEv2, the Security
Controller SHOULD remove the PSK immediately after generating and Controller SHOULD remove the PSK immediately after generating and
distributing it. If raw public keys are used, the Security distributing it. Moreover, the PSK MUST have a proper length (e.g.
Controller SHOULD remove the associated private key immediately after minimu, 128 bit length) and strength. If raw public keys are used,
generating and distributing them to the NSFs. If certificates are the Security Controller SHOULD remove the associated private key
used, the NSF may generate the private key and exports the public key immediately after generating and distributing them to the NSFs. If
for certification in the Security Controller. certificates are used, the NSF may generate the private key and
exports the public key for certification to the Security Controller.
9.2. Case 2 8.2. IKE-less case
In the case 2, the controller sends the IPsec SA information to the In the IKE-less case, the controller sends the IPsec SA information
SAD that includes the keys for integrity and encryption (when ESP is to the SAD that includes the keys for integrity and encryption (when
used). That key material are symmetric keys to protect data traffic. ESP is used). That key material are symmetric keys to protect data
The general recommendation is that the Security Controller SHOULD traffic. The general recommendation is that the Security Controller
NEVER stores the keys after distributing them. Moreover the NSFs SHOULD NEVER stores the keys after distributing them. Moreover, the
MUST NOT allow the reading of these values once they have been NSFs MUST NOT allow the reading of these values once they have been
applied by the Security Controller (i.e. write only operations). applied by the Security Controller (i.e. write only operations).
Nevertheless, if the attacker has access to the Security Controller Nevertheless, if the attacker has access to the Security Controller
during the period of time that key material is generated, it may during the period of time that key material is generated, it may
access to these values. In other words, it may have access to the access to these values. In other words, it may have access to the
key material used in the distributed IPsec SAs and observe the key material used in the distributed IPsec SAs and observe the
traffic between peers. In any case, some escenarios with special traffic between peers. In any case, some escenarios with special
secure enviroments (e.g. physically isolated data centers) make this secure environments (e.g. physically isolated data centers) make this
type of attack difficult. Moreover, some scenarios such as IoT type of attack difficult. Moreover, some scenarios such as IoT
networks with constrained devices, where reducing implementation and networks with constrained devices, where reducing implementation and
computation overhead is important, can apply case 2 as a tradeoff computation overhead is important, can apply IKE-less case as a
between security and low overhead at the constrained device, at the tradeoff between security and low overhead at the constrained device,
cost of assuming the security impact described above. at the cost of assuming the security impact described above.
10. Acknowledgements 9. Acknowledgements
Authors want to thank Sowmini Varadhan, David Carrel, Yoav Nir, Tero Authors want to thank Paul Wouters, Sowmini Varadhan, David Carrel,
Kivinen, Paul Wouters, Graham Bartlett, Sandeep Kampati, Linda Yoav Nir, Tero Kivinen, Graham Bartlett, Sandeep Kampati, Linda
Dunbar, Carlos J. Bernardos, Alejandro Perez-Mendez, Fernando Dunbar, Carlos J. Bernardos, Alejandro Perez-Mendez, Alejandro Abad-
Pereniguez-Garcia, Alejandro Abad-Carrascosa, Ignacio Martinez and Carrascosa, Ignacio Martinez and Ruben Ricart for their valuable
Ruben Ricart for their valuable comments. comments.
11. References 10. References
11.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>. December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226, IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<https://www.rfc-editor.org/info/rfc5226>. <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>.
11.2. Informative References [RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R.,
and J. Jeong, "Interface to Network Security Functions
(I2NSF): Problem Statement and Use Cases", RFC 8192,
DOI 10.17487/RFC8192, July 2017,
<https://www.rfc-editor.org/info/rfc8192>.
[RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R.
Kumar, "Framework for Interface to Network Security
Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018,
<https://www.rfc-editor.org/info/rfc8329>.
10.2. Informative References
[I-D.carrel-ipsecme-controller-ike]
Carrel, D. and B. Weiss, "IPsec Key Exchange using a
Controller", draft-carrel-ipsecme-controller-ike-01 (work
in progress), March 2019.
[I-D.ietf-i2nsf-framework] [I-D.ietf-i2nsf-framework]
Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R.
Kumar, "Framework for Interface to Network Security Kumar, "Framework for Interface to Network Security
Functions", draft-ietf-i2nsf-framework-10 (work in Functions", draft-ietf-i2nsf-framework-10 (work in
progress), November 2017. progress), November 2017.
[I-D.ietf-i2nsf-problem-and-use-cases] [I-D.ietf-i2nsf-problem-and-use-cases]
Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R.,
and J. Jeong, "I2NSF Problem Statement and Use cases", and J. Jeong, "I2NSF Problem Statement and Use cases",
draft-ietf-i2nsf-problem-and-use-cases-16 (work in draft-ietf-i2nsf-problem-and-use-cases-16 (work in
progress), May 2017. 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-06 (work in Terminology", draft-ietf-i2nsf-terminology-07 (work in
progress), July 2018. progress), January 2019.
[I-D.ietf-opsawg-nat-yang]
Boucadair, M., Sivakumar, S., Jacquenet, C., Vinapamula,
S., and Q. Wu, "A YANG Module for Network Address
Translation (NAT) and Network Prefix Translation (NPT)",
draft-ietf-opsawg-nat-yang-17 (work in progress),
September 2018.
[I-D.jeong-i2nsf-sdn-security-services-05] [I-D.jeong-i2nsf-sdn-security-services-05]
Jeong, J., Kim, H., Park, J., Ahn, T., and S. Lee, Jeong, J., Kim, H., Park, J., Ahn, T., and S. Lee,
"Software-Defined Networking Based Security Services using "Software-Defined Networking Based Security Services using
Interface to Network Security Functions", draft-jeong- Interface to Network Security Functions", draft-jeong-
i2nsf-sdn-security-services-05 (work in progress), July i2nsf-sdn-security-services-05 (work in progress), July
2016. 2016.
[I-D.pfkey-spd] [I-D.pfkey-spd]
Sakane, S., "PF_KEY Extensions for IPsec Policy Management Sakane, S., "PF_KEY Extensions for IPsec Policy Management
in KAME Stack", October 2002. in KAME Stack", October 2002.
[I-D.sivakumar-yang-nat]
Sivakumar, S., Boucadair, M., and S. Vinapamula, "YANG
Data Model for Network Address Translation (NAT)", draft-
sivakumar-yang-nat-07 (work in progress), July 2017.
[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]
skipping to change at page 29, line 37 skipping to change at page 30, line 29
[RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined
Networking: A Perspective from within a Service Provider Networking: A Perspective from within a Service Provider
Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014,
<https://www.rfc-editor.org/info/rfc7149>. <https://www.rfc-editor.org/info/rfc7149>.
[RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for
System Management", RFC 7317, DOI 10.17487/RFC7317, August System Management", RFC 7317, DOI 10.17487/RFC7317, August
2014, <https://www.rfc-editor.org/info/rfc7317>. 2014, <https://www.rfc-editor.org/info/rfc7317>.
[RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S.,
and J. Jeong, "Interface to Network Security Functions Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software-
(I2NSF): Problem Statement and Use Cases", RFC 8192, Defined Networking (SDN): Layers and Architecture
DOI 10.17487/RFC8192, July 2017, Terminology", RFC 7426, DOI 10.17487/RFC7426, January
<https://www.rfc-editor.org/info/rfc8192>. 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, CESNET., "StrongSwan: the OpenSource IPsec-based
VPN Solution", April 2017. VPN Solution", April 2017.
Appendix A. Appendix A: YANG model IPsec Configuration data Appendix A. Appendix A: Common YANG model for IKE and IKEless cases
<CODE BEGINS> file "ietf-ipsec@2018-10-20.yang" <CODE BEGINS> file "ietf-ipsec-common@2019-03-11.yang"
module ietf-ipsec {
namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec"; module ietf-ipsec-common{
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec-common";
prefix "ipsec-common";
prefix "eipsec"; import ietf-inet-types { prefix inet; }
import ietf-yang-types { prefix yang; }
import ietf-inet-types { prefix inet; } import ietf-crypto-types {
import ietf-yang-types { prefix yang; } prefix ct;
reference "draft-ietf-netconf-crypto-types-01: Common YANG Dta Types for Cryptography";
}
organization "University of Murcia"; organization "IETF I2NSF (Interface to Network Security Functions) Working Group";
contact contact
" Rafael Marin Lopez " Rafael Marin Lopez
Dept. Information and Communications Engineering (DIIC) Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia Faculty of Computer Science-University of Murcia
30100 Murcia - Spain 30100 Murcia - Spain
Telf: +34868888501 Telf: +34868888501
e-mail: rafa@um.es e-mail: rafa@um.es
Gabriel Lopez Millan Gabriel Lopez Millan
Dept. Information and Communications Engineering (DIIC) Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia Faculty of Computer Science-University of Murcia
30100 Murcia - Spain 30100 Murcia - Spain
Tel: +34 868888504 Tel: +34 868888504
email: gabilm@um.es email: gabilm@um.es
";
description "Data model for IPSec"; 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
";
revision "2018-10-20" { description "Common Data model for SDN-based IPSec configuration.";
description
"Revision";
reference "";
}
feature case1 { description "feature case 1: IKE SPD PAD"; } // IKE/IPSec in the NSFs revision "2019-03-11" {
feature case2 { description "feature case 2: SPD SAD"; } // Only IPSec in the NSFs description "Revision";
reference "";
}
typedef encryption-algorithm-t { typedef encryption-algorithm-t {
type ct:encryption-algorithm-ref;
description "typedef";
}
type enumeration { typedef integrity-algorithm-t {
enum reserved-0 {description "reserved";} type ct:mac-algorithm-ref;
enum des-iv4 { description "DES IV 4";} description
enum des { description "DES"; } "This typedef enables importing modules to easily define an
enum 3des { description "3DES"; } identityref to the 'asymmetric-key-encryption-algorithm'
enum rc5 { description "RC5"; } base identity.";
enum idea { description "IDEA"; } }
enum cast { description "CAST"; }
enum blowfish { description "BlowFish"; }
enum 3idea { description "3IDEA"; }
enum des-iv32 { description "DES-IV32"; }
enum reserved-10 { description "reserved-10"; }
enum null { description "NULL"; }
enum aes-cbc { description "AES-CBC"; }
enum aes-ctr { description "AES-CTR"; }
enum aes-ccm-8 { description "AES-CCM-8"; }
enum aes-ccm-12 { description "AES-CCM-12"; }
enum aes-ccm-16 { description "AES-CCM-16"; }
enum reserved-17 { description "reserved-17"; }
enum aes-gcm-8-icv { description "AES-GCM-8-ICV"; }
enum aes-gcm-12-icv { description "AES-GCM-12-ICV"; }
enum aes-gcm-16-icv { description "AES-GCM-16-ICV"; }
enum null-auth-aes-gmac { description "Null-Auth-AES-GMAC"; }
enum ieee-p1619-xts-aes { description "encr-ieee-p1619-xts-aes -&gt; Reserved for IEEE P1619 XTS-AES.";}
enum camellia-cbc { description "CAMELLIA-CBC"; }
enum camellia-ctr { description "CAMELLIA.CTR"; }
enum camellia-ccm-8-icv { description "CAMELLIA-CCM-8-ICV"; }
enum camellia-ccm-12-icv { description "CAMELLIA-CCM-12-ICV"; }
enum camellia-ccm-16-icv { description "CAMELLIA-CCM-16-ICV"; }
enum aes-cbc-128 { description "AES-CBC-128"; }
enum aes-cbc-192 { description "AES-CBC-192"; }
enum aes-cbc-256 { description "AES-CBC-256"; }
enum blowfish-128 { description "BlowFish-128"; }
enum blowfish-192 { description "BlowFish-192"; }
enum blowfish-256 { description "BlowFish-256"; }
enum blowfish-448 { description "BlowFish-448"; }
enum camellia-128 { description "CAMELLIA-128"; }
enum camellia-192 { description "CAMELLIA-192"; }
enum camellia-256 { description "CAMELLIA-256"; }
}
description "Encryption algorithms -&gt; RFC_5996";
}
typedef integrity-algorithm-t { typedef ipsec-mode {
type enumeration {
enum TRANSPORT { description "Transport mode. No NAT support."; }
enum TUNNEL { description "Tunnel mode"; }
}
description "Type definition of IPsec mode";
}
type enumeration { typedef esp-encap {
enum none { description "NONE"; } type enumeration {
enum hmac-md5-96 { description "HMAC-MD5-96"; } enum ESPINTCP { description "ESP in TCP encapulation.";}
enum hmac-sha1-96 { description "HMAC-SHA1-96"; } enum ESPINTLS { description "ESP in TCP encapsulation using TLS.";}
enum des-mac { description "DES-MAC"; } enum ESPINUDP { description "ESP in UDP encapsulation. RFC 3948 ";}
enum kpdk-md5 {description "KPDK-MD5"; } enum NONE { description "NOT ESP encapsulation" ; }
enum aes-xcbc-96 { description "AES-XCBC-96"; } }
enum hmac-md5-128 { description "HMAC-MD5-128"; } description "type defining types of ESP encapsulation";
enum hmac-sha1-160 { description "HMAC-SHA1-160"; } }
enum aes-cmac-96 { description "AES-CMAC-96"; }
enum aes-128-gmac { description "AES-128-GMAC"; }
enum aes-192-gmac { description "AES-192-GMAC"; }
enum aes-256-gmac { description "AES-256-GMAC"; }
enum hmac-sha2-256-128 { description "HMAC-SHA2-256-128"; }
enum hmac-sha2-384-192 { description "HMAC-SHA2-384-192"; }
enum hmac-sha2-512-256 { description "HMAC-SHA2-512-256"; }
enum hmac-sha2-256-96 { description "HMAC-SHA2-256-096"; }
}
description "Integrity Algorithms -&gt; RFC_5996";
}
typedef type-autostartup { grouping encap { /* This is defined by XFRM */
type enumeration { description "Encapsulation container";
enum ALWAYSON { description " ";} leaf espencap { type esp-encap; description "ESP in TCP, ESP in UDP or ESP in TLS";}
enum INITIATE-ON-DEMAND {description " ";} leaf sport {type inet:port-number; description "Encapsulation source port";}
enum RESPOND-ONLY {description " ";} leaf dport {type inet:port-number; description "Encapsulation destination port"; }
} leaf-list oaddr {type inet:ip-address; description "Encapsulation Original Address ";}
description "Different types of how IKEv2 starts the IPsec SAs"; }
}
typedef auth-protocol-type { typedef ipsec-protocol {
type enumeration { type enumeration {
enum IKEv1 { description "Authentication protocol based on IKEv1"; } enum ah { description "AH Protocol"; }
enum IKEv2 { description "Authentication protocol based on IKEv2"; } enum esp { description "ESP Protocol"; }
enum KINK { description "Authentication protocol based on KINK"; } }
} description "type define of ipsec security protocol";
description "Peer authentication protocols";
}
typedef ipsec-mode { }
type enumeration {
enum TRANSPORT { description "Transport mode"; }
enum TUNNEL { description "Tunnel mode"; }
enum BEET { description "Bound End-to-End Tunnel (BEET) mode for ESP.";}
enum RO { description "Route Optimization mode for Mobile IPv6";}
enum IN_TRIGGER {description "In trigger mode for Mobile IPv6";}
}
description "type define of ipsec mode";
}
typedef esp-encap { typedef ipsec-spi {
type enumeration { type uint32 { range "0..max"; }
enum ESPINTCP { description "ESP in TCP encapulation.";} description "SPI";
enum ESPINTLS { description "ESP in TCP encapsulation using TLS.";} }
enum ESPINUDP { description "ESP in UDP encapsulation. RFC 3948 ";}
}
description "type defining types of ESP encapsulation";
}
typedef ipsec-protocol { typedef lifetime-action {
type enumeration { type enumeration {
enum ah { description "AH Protocol"; } enum terminate-clear {description "Terminate the IPsec SA and allow the packets through";}
enum esp { description "ESP Protocol"; } enum terminate-hold {description "Terminate the IPsec SA and drop the packets";}
enum comp { description "IP Compression";} /*Supported by XFRM*/ enum replace {description "Replace the IPsec SA with a new one";}
enum route2 { description "Routing Header type 2. Mobile IPv6";} /*Supported by XFRM*/ }
enum hao {description "Home Agent Option";} /*Supported by XFRM*/ description "Action when lifetime expiration";
} }
description "type define of ipsec security protocol";
}
typedef ipsec-spi { /*################## SPD basic groupings ####################*/
type uint32 { range "0..max"; }
description "SPI";
}
typedef lifetime-action { typedef ipsec-traffic-direction {
type enumeration { type enumeration {
enum terminate {description "Terminate the IPsec SA";} enum INBOUND { description "Inbound traffic"; }
enum replace {description "Replace the IPsec SA with a new one";} enum OUTBOUND { description "Outbound traffic"; }
} }
description "Action when lifetime expiration"; description "IPsec traffic direction";
} }
typedef ipsec-traffic-direction { typedef ipsec-spd-operation {
type enumeration { type enumeration {
enum INBOUND { description "Inbound traffic"; } enum PROTECT { description "PROTECT the traffic with IPsec"; }
enum OUTBOUND { description "Outbound traffic"; } enum BYPASS { description "BYPASS the traffic"; }
enum FORWARD{ description "Forwarded traffic"; } enum DISCARD { description "DISCARD the traffic"; }
} }
description "IPsec traffic direction"; description "The operation when traffic matches IPsec security policy";
} }
typedef ipsec-spd-operation { typedef ipsec-upper-layer-proto {
type enumeration { type enumeration {
enum PROTECT { description "PROTECT the traffic with IPsec"; } enum TCP { description "TCP traffic"; }
enum BYPASS { description "BYPASS the traffic"; } enum UDP { description "UDP traffic"; }
enum DISCARD { description "DISCARD the traffic"; } enum SCTP { description "SCTP traffic";}
} enum DCCP { description "DCCP traffic";}
description "The operation when traffic matches IPsec security policy"; 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 {
description "lifetime current state data";
leaf time {type yang:timestamp; default 0; description "Time since the element is added";}
leaf idle {type yang:timestamp; default 0; description "Time the element is in idle state";}
leaf bytes { type uint32; default 0; description "Lifetime in bytes number";}
leaf packets {type uint32; default 0; description "Lifetime in packets number";}
}
typedef ipsec-next-layer-proto { /*################## SAD and SPD common basic groupings ####################*/
type enumeration {
enum TCP { description "PROTECT the traffic with IPsec"; }
enum UDP { description "BYPASS the traffic"; }
enum SCTP { description "PROTECT the traffic with IPsec";}
enum DCCP { description "PROTECT the traffic with IPsec";}
enum ICMP { description "PROTECT the traffic with IPsec";}
enum IPv6-ICMP { description "PROTECT the traffic with IPsec";}
enum MH {description "PROTECT the traffic with IPsec";}
enum GRE {description "PROTECT the traffic with IPsec";}
}
description "Next layer proto on top of IP";
}
typedef ipsec-spd-name { grouping port-range {
type enumeration { description "Port range grouping";
enum id_rfc_822_addr { description "Fully qualified user name string."; } leaf start { type inet:port-number; description "Start Port Number"; }
enum id_fqdn { description "Fully qualified DNS name."; } leaf end { type inet:port-number; description "End Port Number"; }
enum id_der_asn1_dn { description "X.500 distinguished name."; } }
enum id_key { description "IKEv2 Key ID."; }
}
description "IPsec SPD name type";
}
typedef auth-method-type { grouping tunnel-grouping {
/* Most implementations also provide XAUTH protocol, others used are: BLISS, P12, NTLM, PIN */ description "Tunnel mode grouping";
type enumeration { leaf local{ type inet:ip-address; description "Local tunnel endpoint"; }
enum pre-shared { description "Select pre-shared key message as the authentication method"; } leaf remote{ type inet:ip-address; description "Remote tunnel enpoint"; }
enum rsa-signature { description "Select rsa digital signature as the authentication method"; } leaf bypass-df { type boolean; description "Bypass DF bit"; }
enum dss-signature { description "Select dss digital signature as the authentication method"; } leaf bypass-dscp { type boolean; description "Bypass DSCP"; }
enum eap { description "Select EAP as the authentication method"; } leaf dscp-mapping { type yang:hex-string; description "DSCP mapping"; }
} leaf ecn { type boolean; description "Bit ECN"; } /* RFC 4301 ASN1 notation. Annex C*/
description "Peer authentication method"; }
}
typedef sa-state { grouping selector-grouping {
type enumeration { description "Traffic selector grouping";
enum Larval { description "SA larval state";}
enum Mature { description "SA mature state";}
enum Dying { description "SA dying state";}
enum Dead { description "SA dead state";}
}
description "Security Association state";
}
grouping lifetime { leaf local-subnet { type inet:ip-prefix; description "Local IP address subnet"; }
description "lifetime current state data"; leaf remote-subnet { type inet:ip-prefix; description "Remote IP address subnet"; }
leaf added {type uint64; default 0; description "added time and date";}
leaf used {type uint64; default 0; description "used time and date";}
leaf bytes { type uint32; default 0; description "current lifetime bytes";}
leaf packets {type uint32; default 0; description "current lifetime packets";}
}
/*################## PAD grouping ####################*/ leaf-list upper-layer-protocol { type ipsec-upper-layer-proto; description "List of Upper Layer Protocol";}
grouping auth-method-grouping { list local-ports {
description "Peer authentication method data"; key "start end";
uses port-range;
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";
container auth-method { }
description "Peer authentication method container";
leaf auth-m { type auth-method-type; description "Type of authentication method (preshared, rsa, etc.)"; } 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 respresents code and type as mentioned in RFC 4301";
}
}
container pre-shared { /*################## SPD ipsec-policy-grouping ####################*/
when "../auth-m = 'pre-shared'";
leaf secret { type string; description "Pre-shared secret value";}
description "Shared secret value";
}
container rsa-signature { grouping ipsec-policy-grouping {
when "../auth-m = 'rsa-signature'";
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"; }
description "RSA signature container";
}
}
}
grouping identity-grouping { description "Holds configuration information for an IPSec SPD entry.";
description "Identification type. It is an union identity";
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 spd-entry-id { type uint64; description "SPD entry id "; }
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 priority {type uint32; default 0; description "Policy priority";}
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 anti-replay-window { type uint16 { range "0 | 32..1024"; } description "Anti replay window size"; }
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";
} /* From RFC4301 list of id types */
}
} /* grouping identity-grouping */
/*################ end PAD grouping ##################*/ list names {
key "name";
leaf name-type { type ipsec-spd-name; description "SPD name type."; }
leaf name { type string; description "Policy name"; }
description "List of policy names";
}
/*################## SAD and SPD grouping ####################*/ 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";
}
}
grouping ip-addr-range { container processing-info {
description "IP address range grouping"; description "SPD processing - RFC4301";
leaf start { type inet:ip-address; description "Start IP address"; } leaf action{ type ipsec-spd-operation; mandatory true; description "Bypass or discard, container ipsec-sa-cfg is empty";}
leaf end { type inet:ip-address; description "End IP address"; }
}
grouping port-range { container ipsec-sa-cfg {
description "Port range grouping"; when "../action = 'PROTECT'";
leaf start { type inet:port-number; description "Start IP address"; }
leaf end { type inet:port-number; description "End IP address"; }
}
grouping tunnel-grouping { leaf pfp-flag { type boolean; description "Each selector has with a pfp flag."; }
description "Tunnel mode grouping"; leaf extSeqNum { type boolean; description "TRUE 64 bit counter, FALSE 32 bit"; }
leaf local{ type inet:ip-address; description "Local tunnel endpoint"; } leaf seqOverflow { type boolean; description "TRUE rekey, FALSE terminare &amp; audit"; }
leaf remote{ type inet:ip-address; description "Remote tunnel enpoint"; } leaf statefulfragCheck { type boolean; description "Indicates whether (TRUE) or not (FALSE) stateful fragment checking (RFC 4301) applies to the SA to be created."; }
leaf bypass-df { type boolean; description "bypass DF bit"; } leaf security-protocol { type ipsec-protocol; description "Security protocol of IPsec SA: Either AH or ESP."; }
leaf bypass-dscp { type boolean; description "bypass DSCP"; } leaf mode { type ipsec-mode; description "transport/tunnel"; }
leaf dscp-mapping { type yang:hex-string; description "DSCP mapping"; }
leaf ecn { type boolean; description "Bit ECN"; } /* RFC 4301 ASN1 notation. Annex C*/
}
grouping selector-grouping { container ah-algorithms {
description "Traffic selector grouping"; when "../security-protocol = 'ah'";
list local-addresses { leaf-list ah-algorithm { type integrity-algorithm-t; description "Configure Authentication Header (AH)."; }
key "start end"; leaf trunc-length { type uint32; description "Truncation value for AH algorithm"; }
uses ip-addr-range; description "AH algoritms ";
description "List of local addresses"; }
}
list remote-addresses {
key "start end";
uses ip-addr-range;
description "List of remote addresses";
}
leaf-list next-layer-protocol { type ipsec-next-layer-proto; description "List of Next Layer Protocol";}
list local-ports {
key "start end";
uses port-range;
description "List of local ports";
}
list remote-ports {
key "start end";
uses port-range;
description "List of remote ports";
}
}
/*################## SAD grouping ####################*/ container esp-algorithms {
grouping ipsec-sa-grouping { when "../security-protocol = 'esp'";
description "Configure Security Association (SA). Section 4.4.2.1 in RFC 4301"; description "Configure Encapsulating Security Payload (ESP).";
leaf-list authentication { type integrity-algorithm-t; description "Configure ESP authentication"; }
/* With AEAD algorithms, the authentication node is not used */
leaf-list encryption { type encryption-algorithm-t; description "Configure ESP encryption"; }
leaf tfc_pad { type uint32; default 0; description "TFC padding for ESP encryption"; }
}
leaf spi { type ipsec-spi; description "Security Parameter Index";} container tunnel {
leaf seq-number { type uint64; description "Current sequence number of IPsec packet."; } when "../mode = 'TUNNEL'";
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."; } uses tunnel-grouping;
leaf anti-replay-window { type uint16 { range "0 | 32..1024"; } description "Anti replay window size"; } description "tunnel grouping container";
leaf rule-number {type uint32; description "This value links the SA with the SPD entry";} }
uses selector-grouping; description " IPSec SA configuration container";
}
}
leaf security-protocol { type ipsec-protocol; description "Security protocol of IPsec SA: Either AH or ESP."; } container spd-lifetime-soft {
description "SPD lifetime hard state data";
uses lifetime;
leaf action {type lifetime-action; description "Action lifetime";}
}
container ah-sa { container spd-lifetime-hard {
when "../security-protocol = 'ah'"; description "SPD lifetime hard state data. The action after the lifetime is to remove the SPD entry.";
description "Configure Authentication Header (AH) for SA"; uses lifetime;
container integrity { }
description "Configure integrity for IPSec Authentication Header (AH)";
leaf integrity-algorithm { type integrity-algorithm-t; description "Configure Authentication Header (AH)."; }
leaf key { type string; description "AH key value";}
}
}
container esp-sa { // State data for an IPsec SPD entry
when "../security-protocol = 'esp'"; container spd-lifetime-current {
description "Set IPSec Encapsulation Security Payload (ESP)"; uses lifetime;
config false;
description "SPD lifetime current state data";
}
} /* grouping ipsec-policy-grouping */
container encryption { }
description "Configure encryption for IPSec Encapsulation Secutiry Payload (ESP)"; <CODE ENDS>
leaf encryption-algorithm { type encryption-algorithm-t; description "Configure ESP encryption"; }
leaf key { type string; description "ESP encryption key value";}
leaf iv {type string; description "ESP encryption IV value"; }
}
container integrity { Appendix B. Appendix B: YANG model for IKE case
description "Configure authentication for IPSec Encapsulation Secutiry Payload (ESP)";
leaf integrity-algorithm { type integrity-algorithm-t; description "Configure Authentication Header (AH)."; }
leaf key { type string; description "ESP integrity key value";}
}
leaf combined-enc-intr { type boolean; description "ESP combined mode algorithms. The algorithm is specified in encryption-algorithm in the container encryption";} <CODE BEGINS> file "ietf-ipsec-ike@2019-03-11.yang"
}
container sad-lifetime-hard { module ietf-ipsec-ike {
description "SAD lifetime hard state data"; yang-version 1.1;
uses lifetime; namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec-ike";
leaf action {type lifetime-action; description "action lifetime";} prefix "ipsec-ike";
}
container sad-lifetime-soft { import ietf-inet-types { prefix inet; }
description "SAD lifetime hard state data"; import ietf-yang-types { prefix yang; }
uses lifetime;
leaf action {type lifetime-action; description "action lifetime";}
}
leaf mode { type ipsec-mode; description "SA Mode"; } import ietf-crypto-types {
leaf statefulfragCheck { type boolean; description "TRUE stateful fragment checking, FALSE no stateful fragment checking"; } prefix ct;
leaf dscp { type yang:hex-string; description "DSCP value"; } reference "draft-ietf-netconf-crypto-types-01: Common YANG Data Types for Cryptography";
leaf path-mtu { type uint16; description "Maximum size of an IPsec packet that can be transmitted without fragmentation"; } }
container tunnel { import ietf-ipsec-common {
when "../mode = 'TUNNEL'"; prefix ic;
uses tunnel-grouping; reference "Common Data model for SDN-based IPSec configuration";
description "Container for tunnel grouping"; }
}
container encap { /* This is defined by XFRM */ organization "IETF I2NSF (Interface to Network Security Functions) Working Group";
description "Encapsulation container";
leaf espencap { type esp-encap; description "ESP in TCP, ESP in UDP or ESP in TLS";}
leaf sport {type inet:port-number; description "Encapsulation source port";}
leaf dport {type inet:port-number; description "Encapsulation destination port"; }
leaf oaddr {type inet:ip-address; description "Encapsulation Original Address ";}
}
// STATE DATA for SA contact
container sad-lifetime-current { " Rafael Marin Lopez
uses lifetime; Dept. Information and Communications Engineering (DIIC)
config false; Faculty of Computer Science-University of Murcia
description "SAD lifetime current state data"; 30100 Murcia - Spain
} Telf: +34868888501
e-mail: rafa@um.es
leaf state {type sa-state; config false; description "current state of SA (mature, larval, dying or dead)"; } 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
container stats { // xfrm.h Fernando Pereniguez Garcia
leaf replay-window {type uint32; default 0; description " "; } Department of Sciences and Informatics
leaf replay {type uint32; default 0; description "packets detected out of the replay window and dropped because they are replay packets";} University Defense Center (CUD), Spanish Air Force Academy, MDE-UPCT
leaf failed {type uint32; default 0; description "packets detected out of the replay window ";} 30720 San Javier - Spain
config false; Tel: +34 968189946
description "SAD statistics"; email: fernando.pereniguez@cud.upct.es
} ";
container replay_state { // xfrm.h description "Data model for IKE case.";
leaf seq {type uint32; default 0; description "input traffic sequence number when anti-replay-window != 0";} revision "2019-03-11" {
leaf oseq {type uint32; default 0; description "output traffic sequence number";} description "Revision 1.1";
leaf bitmap {type uint32; default 0; description "";} reference "";
config false; }
description "Anti-replay Sequence Number state";
}
container replay_state_esn { // xfrm.h typedef type-autostartup {
leaf bmp-len {type uint32; default 0; description "bitmap length for ESN"; } type enumeration {
leaf oseq { type uint32; default 0; description "output traffic sequence number"; } enum ADD {description "IPsec configuration is only loaded but not started.";}
leaf oseq-hi { type uint32; default 0; description ""; } enum ON-DEMAND {description "IPsec configuration is loaded and transferred to the NSF's kernel";}
leaf seq-hi { type uint32; default 0; description ""; } enum START { description "IPsec configuration is loaded and transferred to the NSF's kernel, and the IKEv2 based IPsec SAs are established";}
leaf replay-window {type uint32; default 0; description ""; } }
leaf-list bmp { type uint32; description "bitmaps for ESN (depends on bmp-len) "; } description "Different policies of when to start an IKEv2 based IPsec SA";
config false; }
description "Anti-replay Extended Sequence Number (ESN) state";
}
} typedef auth-protocol-type {
type enumeration {
enum IKEv2 { description "Authentication protocol based on IKEv2"; }
}
description "IKE authentication protocol version";
}
/*################## end SAD grouping ##################*/ 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";
}
/*################## SPD grouping ####################*/ /*################## PAD ####################*/
grouping ipsec-policy-grouping { typedef auth-method-type {
description "Holds configuration information for an IPSec SPD entry."; /* Most implementations also provide XAUTH protocol, others used are: BLISS, P12, NTLM, PIN */
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";
}
leaf rule-number { type uint64; description "SPD index. RFC4301 does not mention an index however real implementations provide a policy index/or id to refer a policy. "; } typedef signature-algorithm-t {
leaf priority {type uint32; default 0; description "Policy priority";} type ct:signature-algorithm-ref; // We must reference to "signature-algorithm-ref" but we temporary use hash-algorithm-ref
description "This typedef enables referencing to any digital signature algorithm";
}
list names { grouping auth-method-grouping {
key "name"; description "Peer authentication method data";
leaf name-type { type ipsec-spd-name; description "SPD name type."; }
leaf name { type string; description "Policy name"; }
description "List of policy names";
}
container condition { container auth-method {
description "SPD condition -&gt; RFC4301"; description "Peer authentication method container";
list traffic-selector-list {
key "ts-number";
leaf ts-number { type uint32; description "Traffic selector number"; }
leaf direction { type ipsec-traffic-direction; description "in/fwd/out"; }
uses selector-grouping;
leaf selector-priority {type uint32; default 0; description "It establishes a priority to the traffic selector";}
ordered-by user;
description "List of traffic selectors";
}
}
container processing-info { leaf auth-m { type auth-method-type; description "Type of authentication method (pre-shared, eap, digital signature, null)"; }
description "SPD processing -&gt; RFC4301";
leaf action{ type ipsec-spd-operation; mandatory true; description "If the action is bypass or discard processing container ipsec-sa-cfg is empty";}
container ipsec-sa-cfg { container eap-method {
when "../action = 'PROTECT'"; when "../auth-m = 'eap'";
leaf pfp-flag { type boolean; description "Each selector has with a pfp flag."; } leaf eap-type { type uint8; description "EAP method type"; }
leaf extSeqNum { type boolean; description "TRUE 64 bit counter, FALSE 32 bit"; } description "EAP method description used when auth method is eap";
leaf seqOverflow { type boolean; description "TRUE rekey, FALSE terminare &amp; audit"; } }
leaf statefulfragCheck { type boolean; description "TRUE stateful fragment checking, FALSE no stateful fragment checking"; }
leaf security-protocol { type ipsec-protocol; description "Security protocol of IPsec SA: Either AH or ESP."; }
leaf mode { type ipsec-mode; description "transport/tunnel"; }
container ah-algorithms { container pre-shared {
when "../security-protocol = 'ah'"; when "../auth-m[.='pre-shared' or .='eap']";
leaf-list ah-algorithm { type integrity-algorithm-t; description "Configure Authentication Header (AH)."; } leaf secret { type yang:hex-string; description "Pre-shared secret value";}
description "AH algoritms "; description "Shared secret value";
} }
container esp-algorithms { container digital-signature {
when "../security-protocol = 'esp'"; when "../auth-m[.='digital-signature' or .='eap']";
description "Configure Encapsulating Security Payload (ESP)."; leaf ds-algorithm {type signature-algorithm-t; description "Name of the digital signature algorithm";}
leaf-list authentication { type integrity-algorithm-t; description "Configure ESP authentication"; } leaf raw-public-key {type yang:hex-string; description "RSA raw public key" ;}
leaf-list encryption { type encryption-algorithm-t; description "Configure ESP encryption"; } 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";
}
}
}
container tunnel { grouping identity-grouping {
when "../mode = 'TUNNEL'"; description "Identification type. It is an union identity";
uses tunnel-grouping; choice identity {
description "tunnel grouping container"; 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. "; }
description " IPSec SA configuration container"; 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 ##################*/
}
container spd-mark { /*################## IKEv2-grouping ##################*/
description "policy: mark MARK mask MASK "; grouping ike-proposal {
leaf mark { type uint32; default 0; description "mark value";} description "IKEv2 proposal grouping";
leaf mask { type yang:hex-string; default 00:00:00:00; description "mask value 0x00000000";}
}
container spd-lifetime-hard { container ike-sa-lifetime-hard {
description "SPD lifetime hard state data"; description "IKE SA lifetime hard";
uses lifetime; uses ic:lifetime;
leaf action {type lifetime-action; description "action lifetime";} }
}
container spd-lifetime-soft { container ike-sa-lifetime-soft {
description "SPD lifetime hard state data"; description "IPsec SA lifetime soft";
uses lifetime; uses ic:lifetime;
leaf action {type lifetime-action; description "action lifetime";} leaf action {type ic:lifetime-action; description "Action lifetime";}
} }
// State data leaf-list ike-sa-authalg { type ic:integrity-algorithm-t; description "Auth algorigthm for IKE SA";}
container spd-lifetime-current { leaf-list ike-sa-encalg { type ic:encryption-algorithm-t; description "Auth algorigthm for IKE SAs";}
uses lifetime; leaf dh_group { type uint32; mandatory true; description "Group number for Diffie Hellman Exponentiation";}
config false; leaf half-open-ike-sa-timer { type uint32; description "Set the half-open IKE SA timeout duration" ; }
description "SPD lifetime current state data"; leaf half-open-ike-sa-cookie-threshold { type uint32; description "Number of half-open IKE SAs that activate the cookie mechanism." ; }
} }
} /* grouping ipsec-policy-grouping */ grouping ike-child-sa-info {
description "IPsec SA Information";
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"; }
/*################ end SPD grouping ##################*/ container child-sa-lifetime-soft {
description "IPsec SA lifetime soft";
uses ic:lifetime;
leaf action {type ic:lifetime-action; description "action lifetime";}
}
/*################## IKEv2-grouping ##################*/ container child-sa-lifetime-hard {
description "IPsec SA lifetime hard. The action will be to terminate the IPsec SA.";
uses ic:lifetime;
}
}
grouping isakmp-proposal { /*################## End IKEv2-grouping ##################*/
description "ISAKMP proposal grouping";
leaf phase1-lifetime { type uint32; mandatory true; description "lifetime for IKE Phase 1 SAs";}
leaf-list phase1-authalg { type integrity-algorithm-t; description "Auth algorigthm for IKE Phase 1 SAs";}
leaf-list phase1-encalg { type encryption-algorithm-t; description "Auth algorigthm for IKE Phase 1 SAs";}
leaf combined-enc-intr { type boolean; description "Combined mode algorithms (encryption and integrity).";}
leaf dh_group { type uint32; mandatory true; description "Group number for Diffie Hellman Exponentiation";}
} /* list isakmp-proposal */
grouping phase2-info { container ikev2 {
description "IKE Phase 2 Information";
leaf-list pfs_group { type uint32; description "If non-zero, require perfect forward secrecy when requesting new SA. The non-zero value is the required group number"; }
container ipsec-sad-lifetime-hard { description "Configure the IKEv2 software";
description "IPsec SA lifetime hard";
uses lifetime; container pad {
leaf action {type lifetime-action; description "action lifetime";} description "Configure Peer Authorization Database (PAD)";
list pad-entry {
key "pad-entry-id";
ordered-by user;
description "Peer Authorization Database (PAD)";
leaf pad-entry-id { type uint64; description "SAD index. ";}
uses identity-grouping;
leaf pad-auth-protocol { type auth-protocol-type; description "IKEv2, etc. ";}
uses auth-method-grouping;
}
}
list ike-conn-entry {
key "conn-name";
description "IKE peer connection information";
leaf conn-name { type string; mandatory true; description "Name of IKE connection";}
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)"; }
uses ike-proposal;
container local {
description "Local peer connection information";
leaf local-pad-id { type uint64; description " ";}
}
container remote {
description "Remote peer connection information";
leaf remote-pad-id { type uint64; description " ";}
}
uses ic:encap;
container spd {
description "Configure the Security Policy Database (SPD)";
list spd-entry {
key "spd-entry-id";
uses ic:ipsec-policy-grouping;
ordered-by user;
description "List of SPD entries";
}
}
container ike-sa-state {
container uptime {
description "IKE service uptime";
leaf running { type yang:date-and-time; description "Relative uptime";}
leaf since { type yang:date-and-time; description "Absolute uptime";}
}
leaf initiator { type boolean; description "It is acting as initiator in this connection";}
leaf initiator-ikesa-spi {type uint64; description "Initiator's IKE SA SPI";}
leaf responder-ikesa-spi {type uint64; description "Responsder's IKE SA SPI";}
leaf nat-local {type boolean; description "YES, if local endpoint is behind a NAT";}
leaf nat-remote {type boolean; description "YES, if remote endpoint is behind a NAT";}
leaf nat-any {type boolean; description "YES, if both local and remote endpoints are behind a NAT";}
uses ic:encap;
leaf established {type uint64; description "Seconds the IKE SA has been established";}
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";}
}
description "State data about IKE CHILD SAs";
}
config false;
description "IKE state data";
} /* ike-sa-state */
} /* ike-conn-entries */
container number-ike-sas{
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>
Appendix C. Appendix C: YANG model for IKE-less case
<CODE BEGINS> file "ietf-ipsec-ikeless@2019-03-11.yang"
module ietf-ipsec-ikeless {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless";
prefix "ipsec-ikeless";
import ietf-yang-types { prefix yang; }
import ietf-ipsec-common {
prefix ic;
reference "Common Data model for SDN-based IPSec configuration";
} }
container ipsec-sad-lifetime-soft { organization "IETF I2NSF (Interface to Network Security Functions) Working Group";
description "IPsec SA lifetime soft";
uses lifetime;
leaf action {type lifetime-action; description "action lifetime";}
}
} 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
grouping local-grouping { Gabriel Lopez Millan
description "Configure the local peer in an IKE connection"; Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Tel: +34 868888504
email: gabilm@um.es
container local { Fernando Pereniguez Garcia
description "Local container"; Department of Sciences and Informatics
choice my-identifier-type { University Defense Center (CUD), Spanish Air Force Academy, MDE-UPCT
default ipv4; 30720 San Javier - Spain
case ipv4 { Tel: +34 968189946
leaf ipv4 { type inet:ipv4-address; description "IPv4 dotted-decimal address"; } email: fernando.pereniguez@cud.upct.es
} ";
case ipv6 {
leaf ipv6 { type inet:ipv6-address; description "numerical IPv6 address"; }
}
case fqdn {
leaf fqdn { type inet:domain-name; description "Fully Qualifed Domain name "; }
}
case dn {
leaf dn { type string; description "Domain name"; }
}
case user_fqdn {
leaf user_fqdn { type string; description "User FQDN"; }
}
description "Local ID type";
}
leaf my-identifier { type string; mandatory true; description "Local id used for authentication";}
}
} // local-grouping
grouping remote-grouping { description "Data model for IKE-less case";
description "Configure the remote peer in an IKE connection";
container remote { revision "2019-03-11" {
description "Remote container"; description "Revision";
choice my-identifier-type { reference "";
default ipv4; }
case ipv4 {
leaf ipv4 { type inet:ipv4-address; description "IPv4 dotted-decimal address"; }
}
case ipv6 {
leaf ipv6 { type inet:ipv6-address; description "numerical IPv6 address"; }
}
case fqdn {
leaf fqdn { type inet:domain-name; description "Fully Qualifed Domain name "; }
}
case dn {
leaf dn { type string; description "Domain name"; }
}
case user_fqdn {
leaf user_fqdn { type string; description "User FQDN"; }
}
description "Local ID type";
}
leaf my-identifier { type string; mandatory true; description "Local id used for authentication"; }
}
} // remote-grouping
/*################## End IKEv2-groupingUMU ##################*/ /*################## SAD grouping ####################*/
grouping ipsec-sa-grouping {
description "Configure Security Association (SA). Section 4.4.2.1 in RFC 4301";
/*################# Register grouping #################*/ leaf sad-entry-id {type uint64; description "This value identifies a specific entry in the SAD";}
leaf spi { type ic:ipsec-spi; description "Security Parameter Index. This may not be unique for a particular SA";}
leaf seq-number { type uint64; description "Current sequence number of IPsec packet."; }
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."; }
leaf anti-replay-window { type uint16 { range "0 | 32..1024"; } description "Anti replay window size"; }
leaf spd-entry-id {type uint64; description "This value links the SA with the SPD entry";}
typedef sadb-msg-type { uses ic:selector-grouping;
type enumeration { leaf security-protocol { type ic:ipsec-protocol; description "Security protocol of IPsec SA: Either AH or ESP."; }
enum sadb_reserved { description "SADB_RESERVED";}
enum sadb_getspi { description "SADB_GETSPI";}
enum sadb_update { description "SADB_UPDATE";}
enum sadb_add { description "SADB_ADD";}
enum sadb_delete { description "SADB_DELETE"; }
enum sadb_get { description "SADB_GET"; }
enum sadb_acquire { description "SADB_ACQUIRE"; }
enum sadb_register { description "SADB_REGISTER"; }
enum sadb_expire { description "SADB_EXPIRE"; }
enum sadb_flush { description "SADB_FLUSH"; }
enum sadb_dump { description "SADB_DUMP"; }
enum sadb_x_promisc { description "SADB_X_PROMISC"; }
enum sadb_x_pchange { description "SADB_X_PCHANGE"; }
enum sadb_max{ description "SADB_MAX"; }
}
description "PF_KEY base message types";
}
typedef sadb-msg-satype { container sad-lifetime-hard {
type enumeration { description "SAD lifetime hard state data. The action associated is terminate.";
enum sadb_satype_unspec { description "SADB_SATYPE_UNSPEC"; } uses ic:lifetime;
enum sadb_satype_ah { description "SADB_SATYPE_AH"; } }
enum sadb_satype_esp { description "SADB_SATYPE_ESP"; } container sad-lifetime-soft {
enum sadb_satype_rsvp { description "SADB_SATYPE_RSVP"; } description "SAD lifetime hard state data";
enum sadb_satype_ospfv2 { description "SADB_SATYPE_OSPFv2"; } uses ic:lifetime;
enum sadb_satype_ripv2 { description "SADB_SATYPE_RIPv2"; } leaf action {type ic:lifetime-action; description "action lifetime";}
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 { leaf mode { type ic:ipsec-mode; description "SA Mode"; }
description "Configuration for the message header format"; leaf statefulfragCheck { type boolean; description "Indicates whether (TRUE) or not (FALSE) stateful fragment checking (RFC 4301) applies to this SA."; }
list base-list {
key "version";
leaf version { type string; description "Version of PF_KEY (MUST be PF_KEY_V2)"; }
leaf msg_type { type sadb-msg-type; description "Identifies the type of message"; }
leaf msg_satype { type sadb-msg-satype; description "Defines the type of Security Association"; }
leaf msg_seq { type uint32; description "Sequence number of this message."; }
description "Configuration for a specific message header format";
}
}
grouping algorithm-grouping { leaf dscp { type yang:hex-string; description "DSCP value"; }
description "List of supported authentication and encryptation algorithms"; leaf path-mtu { type uint16; description "Maximum size of an IPsec packet that can be transmitted without fragmentation"; }
container algorithm-supported { container tunnel {
description "lists of encryption and authentication algorithms"; when "../mode = 'TUNNEL'";
list enc-algs { uses ic:tunnel-grouping;
key "name"; description "Container for tunnel grouping";
leaf name { type encryption-algorithm-t; description "Name of encryption algorithm"; } }
leaf ivlen { type uint8; description "Length of the initialization vector to be used for the algorithm"; }
leaf min-bits { type uint16; description "The minimun acceptable key length, in bits"; }
leaf max-bits { type uint16; description "The maximun acceptable key length, in bits"; }
description "list of encryption algorithm supported ";
}
list auth-algs {
key "name";
leaf name { type integrity-algorithm-t; description "Name of authentication algorithm";}
leaf ivlen { type uint8; description "Length of the initialization vector to be used for the algorithm"; }
leaf min-bits { type uint16; description "The minimun acceptable key length, in bits"; }
leaf max-bits { type uint16; description "The maximun acceptable key length, in bits"; }
description "list of authentication algorithm supported ";
}
}
}
/*################# End Register grouping #################*/
/*################## ipsec ##################*/ uses ic:encap;
container ietf-ipsec { // STATE DATA for SA
description "Main IPsec container "; container sad-lifetime-current {
uses ic:lifetime;
config false;
description "SAD lifetime current state data";
}
container ikev2 { container stats { // xfrm.h
if-feature case1; leaf replay-window {type uint32; default 0; description " "; }
description "Configure the IKEv2"; leaf replay {type uint32; default 0; description "packets detected out of the replay window and dropped because they are replay packets";}
leaf failed {type uint32; default 0; description "packets detected out of the replay window ";}
config false;
description "SAD statistics";
}
container ike-connection { container replay_state { // xfrm.h
description "IKE connections configuration"; leaf seq {type uint32; default 0; description "input traffic sequence number when anti-replay-window != 0";}
leaf oseq {type uint32; default 0; description "output traffic sequence number";}
leaf bitmap {type uint32; default 0; description "";}
config false;
description "Anti-replay Sequence Number state";
}
list ike-conn-entries { container replay_state_esn { // xfrm.h
key "conn-name"; leaf bmp-len {type uint32; default 0; description "bitmap length for ESN"; }
description "IKE peer connetion information"; leaf oseq { type uint32; default 0; description "output traffic sequence number"; }
leaf conn-name { type string; mandatory true; description "Name of IKE connection";} leaf oseq-hi { type uint32; default 0; description ""; }
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 seq-hi { type uint32; default 0; description ""; }
leaf nat-traversal { type boolean; default false; description "Enable/Disable NAT traversal"; } leaf replay-window {type uint32; default 0; description ""; }
leaf initial-contact {type boolean; default false; description "This IKE SA is the only currently active between the authenticated identities";} leaf-list bmp { type uint32; description "bitmaps for ESN (depends on bmp-len) "; }
config false;
description "Anti-replay Extended Sequence Number (ESN) state";
}
container encap { }
when "../nat-traversal = 'true'"; /*################## end SAD grouping ##################*/
description "Encapsulation container";
leaf espencap { type esp-encap; description "ESP in TCP, ESP in UDP or ESP in TLS";}
leaf sport {type inet:port-number; description "Encapsulation source port";}
leaf dport {type inet:port-number; description "Encapsulation destination port"; }
leaf oaddr {type inet:ip-address; description "Encapsulation Original Address ";}
}
leaf version { /*################# Register grouping #################*/
type enumeration { typedef sadb-msg-type {
enum ikev2 {value 2; description "IKE version 2";} type enumeration {
} enum sadb_acquire { description "SADB_ACQUIRE"; }
description "IKE version"; enum sadb_expire { description "SADB_EXPIRE"; }
} }
description "Notifications (PF_KEY message types) that must be forwarded by the NSF to the controller in IKE-less case";
}
uses isakmp-proposal; typedef sadb-msg-satype {
uses local-grouping; type enumeration {
uses remote-grouping; enum sadb_satype_unspec { description "SADB_SATYPE_UNSPEC"; }
uses phase2-info; enum sadb_satype_ah { description "SADB_SATYPE_AH"; }
enum sadb_satype_esp { description "SADB_SATYPE_ESP"; }
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";
}
container ike-stats { grouping base-grouping {
container uptime { description "Configuration for the message header format";
description "IKE service uptime"; list base-list {
leaf running { type yang:date-and-time; description "Relative uptime";} key "version";
leaf since { type yang:date-and-time; description "Absolute uptime";} leaf version { type string; description "Version of PF_KEY (MUST be PF_KEY_V2)"; }
leaf msg_type { type sadb-msg-type; description "Identifies the type of message"; }
leaf msg_satype { type sadb-msg-satype; description "Defines the type of Security Association"; }
leaf msg_seq { type uint32; description "Sequence number of this message."; }
description "Configuration for a specific message header format";
}
}
/*################# End Register grouping #################*/
} /*################## IPsec configuration ##################*/
leaf initiator { type boolean; description "It is acting as initiator in this connection";} container ietf-ipsec {
leaf initiator-spi {type uint64; description "Initiator's IKE SA SPI";} description "IPsec configuration";
leaf responder-spi {type uint64; description "Responsder's IKE SA SPI";}
leaf nat-local {type boolean; description "YES, if local endpoint is behind a NAT";}
leaf nat-remote {type boolean; description "YES, if remote endpoint is behind a NAT";}
leaf nat-any {type boolean; description "YES, if both local and remote endpoints are behind a NAT";}
leaf established {type uint64; description "Seconds the IKE SA has been established";}
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 "IKE active SA's SPI '";
leaf spi-in {type ipsec-spi; description "Security Parameter Index for Inbound IPsec SA";}
leaf spi-out {type ipsec-spi; description "Security Parameter Index for the corresponding outbound IPsec SA";}
}
description "State data about IKE CHILD SAs";
}
config false;
description "IKE state data";
} /* ike-stats */
} /* ike-conn-entries */ container spd {
} /* container ike-connection */ description "Configure the Security Policy Database (SPD)";
list spd-entry {
key "spd-entry-id";
uses ic:ipsec-policy-grouping;
ordered-by user;
description "List of SPD entries";
}
}
container number-ike-sas{ container sad {
leaf total {type uint32; description "Total number of IKEv2 SAs";} description "Configure the IPSec Security Association Database (SAD)";
leaf half-open {type uint32; description "Total number of half-open IKEv2 SAs";}
config false;
description "Number of IKE SAs";
}
} /* container ikev2 */ list sad-entry {
key "sad-entry-id";
container ipsec { uses ipsec-sa-grouping;
description "Configuration IPsec";
container spd { container ah-sa {
description "Configure the Security Policy Database (SPD)"; when "../security-protocol = 'ah'";
list spd-entry { description "Configure Authentication Header (AH) for SA";
key "rule-number"; container integrity {
uses ipsec-policy-grouping; description "Configure integrity for IPSec Authentication Header (AH)";
ordered-by user; leaf integrity-algorithm { type ic:integrity-algorithm-t; description "Configure Authentication Header (AH)."; }
description "List of SPD entries"; leaf key { type string; description "AH key value";}
} }
} }
container sad {
description "Configure the IPSec Security Association Database (SAD)"; container esp-sa {
list sad-entry { when "../security-protocol = 'esp'";
key "spi"; description "Set IPSec Encapsulation Security Payload (ESP)";
uses ipsec-sa-grouping;
description "List of SAD entries";
}
}
container pad { container encryption {
if-feature case1; description "Configure encryption for IPSec Encapsulation Secutiry Payload (ESP)";
description "Configure Peer Authorization Database (PAD)"; leaf encryption-algorithm { type ic:encryption-algorithm-t; description "Configure ESP encryption"; }
leaf key { type yang:hex-string; description "ESP encryption key value";}
leaf iv {type yang:hex-string; description "ESP encryption IV value"; }
}
list pad-entries { container integrity {
key "pad-entry-id"; description "Configure authentication for IPSec Encapsulation Secutiry Payload (ESP)";
ordered-by user; leaf integrity-algorithm { type ic:integrity-algorithm-t; description "Configure Authentication Header (AH)."; }
description "Peer Authorization Database (PAD)"; leaf key { type yang:hex-string; description "ESP integrity key value";}
leaf pad-entry-id { type uint64; description "SAD index. ";} }
uses identity-grouping; /* With AEAD algorithms, the integrity node is not used */
leaf pad-auth-protocol { type auth-protocol-type; description "IKEv1, IKEv2, KINK, etc. ";}
uses auth-method-grouping;
}
}
}
} /* container ietf-ipsec */ leaf combined-enc-intr { type boolean; description "ESP combined mode algorithms. The algorithm is specified in encryption-algorithm";}
}
description "List of SAD entries";
}
}
} /* container ietf-ipsec */
/*################## RPC and Notifications ##################*/ /*################## RPC and Notifications ##################*/
/* Note: not yet completed */ // These RPCs are needed by a Security Controller in IKEless case
// Those RPCs are needed by a Security Controller in case 2 */
rpc sadb_register { notification spdb_expire {
description "Allows netconf to register its key socket as able to acquire new security associations for the kernel"; description "A SPD entry has expired";
input { 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. "; }
uses base-grouping; }
}
output {
uses base-grouping;
uses algorithm-grouping;
}
}
notification spdb_expire { notification sadb_acquire {
description "A SPD entry has expired"; description "A IPsec SA is required ";
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. "; } uses base-grouping;
uses ic:selector-grouping; // To indicate the concrete traffic selector of the policy that triggered this acquire.
}
} notification sadb_expire {
description "A IPsec SA expiration (soft or hard)";
notification sadb_acquire { uses base-grouping;
description "A IPsec SA is required "; leaf spi { type ic:ipsec-spi; description "Security Parameter Index";}
uses base-grouping; leaf anti-replay-window { type uint16 { range "0 | 32..1024"; } description "Anti replay window"; }
}
notification sadb_expire { leaf encryption-algorithm { type ic:encryption-algorithm-t; description "encryption algorithm of the expired SA"; }
description "A IPsec SA expiration (soft or hard)"; leaf authentication-algorithm { type ic:integrity-algorithm-t; description "authentication algorithm of the expired SA"; }
uses base-grouping; container sad-lifetime-hard {
leaf spi { type ipsec-spi; description "Security Parameter Index";} description "SAD lifetime hard state data";
leaf anti-replay-window { type uint16 { range "0 | 32..1024"; } description "Anti replay window"; } uses ic:lifetime;
leaf state {type sa-state; description "current state of SA (mature, larval, dying or dead)"; } }
container sad-lifetime-soft {
description "SAD lifetime soft state data";
uses ic:lifetime;
}
leaf encryption-algorithm { type encryption-algorithm-t; description "encryption algorithm of the expired SA"; } container sad-lifetime-current {
leaf authentication-algorithm { type integrity-algorithm-t; description "authentication algorithm of the expired SA"; } description "SAD lifetime current state data";
uses ic:lifetime;
}
container sad-lifetime-hard { }
description "SAD lifetime hard state data";
uses lifetime;
}
container sad-lifetime-soft {
description "SAD lifetime hard state data";
uses lifetime;
}
container sad-lifetime-current {
description "SAD lifetime current state data";
uses lifetime;
}
}
notification sadb_bad-spi { notification sadb_bad-spi {
description "....."; description "Notifiy when the NSF receives a packet with an incorrect SPI (i.e. not present in the SAD)";
leaf state { type ipsec-spi; mandatory "true"; description "Notify when a SPI"; } leaf state { type ic:ipsec-spi; mandatory "true"; description "SPI number contained in the erroneous IPsec packet"; }
} }
} /*module ietf-ipsec*/
<CODE ENDS> }/*module ietf-ipsec*/
<CODE ENDS>
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
EMail: rafa@um.es EMail: rafa@um.es
Gabriel Lopez-Millan Gabriel Lopez-Millan
skipping to change at line 2190 skipping to change at page 49, line 35
EMail: rafa@um.es EMail: rafa@um.es
Gabriel Lopez-Millan Gabriel Lopez-Millan
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 04 Phone: +34 868 88 85 04
EMail: gabilm@um.es EMail: gabilm@um.es
Fernando Pereniguez-Garcia
University Defense Center
Spanish Air Force Academy, MDE-UPCT
San Javier (Murcia) 30720
Spain
Phone: +34 968 18 99 46
EMail: fernando.pereniguez@cud.upct.es
 End of changes. 251 change blocks. 
1388 lines changed or deleted 1455 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/