draft-ietf-i2nsf-sdn-ipsec-flow-protection-01.txt   draft-ietf-i2nsf-sdn-ipsec-flow-protection-02.txt 
I2NSF R. Marin-Lopez I2NSF R. Marin-Lopez
Internet-Draft G. Lopez-Millan Internet-Draft G. Lopez-Millan
Intended status: Standards Track University of Murcia Intended status: Standards Track University of Murcia
Expires: September 6, 2018 March 5, 2018 Expires: January 3, 2019 July 2, 2018
Software-Defined Networking (SDN)-based IPsec Flow Protection Software-Defined Networking (SDN)-based IPsec Flow Protection
draft-ietf-i2nsf-sdn-ipsec-flow-protection-01 draft-ietf-i2nsf-sdn-ipsec-flow-protection-02
Abstract Abstract
This document describes the use case of providing IPsec-based flow This document describes how providing IPsec-based flow protection by
protection by means of a Software-Defined Network (SDN) controller means of a Software-Defined Network (SDN) controller (aka. Security
(aka. Security Controller) and establishes the requirements to Controller) and establishes the requirements to support this service.
support this service. It considers two main well-known scenarios in It considers two main well-known scenarios in IPsec: (i) gateway-to-
IPsec: (i) gateway-to-gateway and (ii) host-to-host. This document gateway and (ii) host-to-host. The SDN-based service described in
describes a mechanism based on the SDN paradigm to support the this document allows the distribution and monitoring of IPsec
distribution and monitoring of IPsec information from a Security information from a Security Controller to one or several flow-based
Controller to one or several flow-based Network Security Function Network Security Function (NSF). The NSFs implement IPsec to protect
(NSF). The NSFs implement IPsec to protect data traffic between data traffic between network resources with IPsec.
network resources with IPsec.
The document focuses in the NSF Facing Interface by providing models The document focuses in the NSF Facing Interface by providing models
for Configuration and State data model required to allow the Security for Configuration and State data model required to allow the Security
Controller to configure the IPsec databases (SPD, SAD, PAD) and IKE Controller to configure the IPsec databases (SPD, SAD, PAD) and IKEv2
to establish security associations with a reduced intervention of the to establish security associations with a reduced intervention of the
network administrator. NOTE: State data model will be developed as network administrator.
part of this work but it is still TBD.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 6, 2018. This Internet-Draft will expire on January 3, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. SDN-based IPsec management description . . . . . . . . . . . 6 5. SDN-based IPsec management description . . . . . . . . . . . 6
5.1. Case 1: IKE/IPsec in the NSF . . . . . . . . . . . . . . 6 5.1. Case 1: IKE/IPsec in the NSF . . . . . . . . . . . . . . 6
5.1.1. Interface Requirements for Case 1 . . . . . . . . . . 7 5.1.1. Interface Requirements for Case 1 . . . . . . . . . . 7
5.2. Case 2: IPsec (no IKE) in the NSF . . . . . . . . . . . . 7 5.2. Case 2: IPsec (no IKEv2) in the NSF . . . . . . . . . . . 7
5.2.1. Interface Requirements for Case 2 . . . . . . . . . . 8 5.2.1. Interface Requirements for Case 2 . . . . . . . . . . 8
5.3. Case 1 vs Case 2 . . . . . . . . . . . . . . . . . . . . 8 5.3. Case 1 vs Case 2 . . . . . . . . . . . . . . . . . . . . 8
6. YANG configuration data models . . . . . . . . . . . . . . . 10 5.3.1. Rekeying process . . . . . . . . . . . . . . . . . . 9
6.1. Security Policy Database (SPD) Model . . . . . . . . . . 10 5.3.2. NSF state loss . . . . . . . . . . . . . . . . . . . 10
6.2. Security Association Database (SAD) Model . . . . . . . . 12 5.3.3. NAT Traversal . . . . . . . . . . . . . . . . . . . . 10
6.3. Peer Authorization Database (PAD) Model . . . . . . . . . 14 6. YANG configuration data models . . . . . . . . . . . . . . . 11
6.4. Internet Key Exchange (IKE) Model . . . . . . . . . . . . 15 6.1. Security Policy Database (SPD) Model . . . . . . . . . . 11
7. Use cases examples . . . . . . . . . . . . . . . . . . . . . 17 6.2. Security Association Database (SAD) Model . . . . . . . . 13
6.3. Peer Authorization Database (PAD) Model . . . . . . . . . 16
6.4. Internet Key Exchange (IKEv2) Model . . . . . . . . . . . 17
7. Use cases examples . . . . . . . . . . . . . . . . . . . . . 19
7.1. Host-to-Host or Gateway-to-gateway under the same 7.1. Host-to-Host or Gateway-to-gateway under the same
controller . . . . . . . . . . . . . . . . . . . . . . . 17 controller . . . . . . . . . . . . . . . . . . . . . . . 19
7.2. Host-to-Host or Gateway-to-gateway under different 7.2. Host-to-Host or Gateway-to-gateway under different
Security controllers . . . . . . . . . . . . . . . . . . 19 Security controllers . . . . . . . . . . . . . . . . . . 21
8. Implementation notes . . . . . . . . . . . . . . . . . . . . 21 8. Implementation notes . . . . . . . . . . . . . . . . . . . . 23
9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
9.1. Case 1 . . . . . . . . . . . . . . . . . . . . . . . . . 23 9.1. Case 1 . . . . . . . . . . . . . . . . . . . . . . . . . 25
9.2. Case 2 . . . . . . . . . . . . . . . . . . . . . . . . . 23 9.2. Case 2 . . . . . . . . . . . . . . . . . . . . . . . . . 25
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
11.1. Normative References . . . . . . . . . . . . . . . . . . 24 11.1. Normative References . . . . . . . . . . . . . . . . . . 26
11.2. Informative References . . . . . . . . . . . . . . . . . 24 11.2. Informative References . . . . . . . . . . . . . . . . . 26
Appendix A. Appendix A: YANG model IPsec Configuration data . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 Appendix A. Appendix A: YANG model IPsec Configuration data . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47
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
skipping to change at page 4, line 22 skipping to change at page 4, line 24
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, Case 1 requires the provision of SPD and PAD
entries and the IKE credential and information related with the IKE entries and the IKE credential and information related with the IKE
negotiation (e.g. IKE_SA_INIT); and Case 2 requires the management negotiation (e.g. IKE_SA_INIT); and Case 2 requires the management
of SPD and SAD entries. Based on YANG models in [netconf-vpn] and of SPD and SAD entries. Based on YANG models in [netconf-vpn] and
[I-D.tran-ipsecme-yang], RFC 4301 [RFC4301] and RFC 7296 [RFC7296] [I-D.tran-ipsecme-yang], RFC 4301 [RFC4301] and RFC 7296 [RFC7296]
this document defines the required interfaces with a YANG model for this document defines the required interfaces with a YANG model for
configuration data for IKE, PAD, SPD and SAD Appendix A . State data configuration and state data for IKE, PAD, SPD and SAD Appendix A.
is TBD.
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 TBD. In
these cases, host or gateways or both may act as NSFs. Finally, it these cases, host or gateways or both may act as NSFs. Finally, it
also discusses the situation where two NSFs are under the control of also discusses the situation where two NSFs are under the control of
two different Security Controllers. 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
skipping to change at page 5, line 49 skipping to change at page 6, line 7
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. flow.
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 our SDN-based solution. 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 to
protect specific data flows. 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. Case 1: IKE/IPsec in the NSF
In this case the NSF ships an IKE 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 IKE 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), and the Security Controller
translates those requirements into IKE, SPD and PAD entries that will translates those requirements into IKE, SPD and PAD entries that will
be installed into the NSF (through the NSF Facing Interface). With be installed into the NSF (through the NSF Facing Interface). With
that information, the NSF can just run IKE to establish the required that information, the NSF can just run IKEv2 to establish the
IPsec SA (when the data flow needs protection). Figure 1 shows the required IPsec SA (when the data flow needs protection). Figure 1
different layers and corresponding functionality. 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
skipping to change at page 7, line 33 skipping to change at page 7, line 33
Figure 1: Case 1: IKE/IPsec in the NSF Figure 1: Case 1: IKE/IPsec in the NSF
5.1.1. Interface Requirements for Case 1 5.1.1. Interface Requirements for Case 1
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 1, the following interface requirements are to be
met: met:
o A YANG data model for Configuration data for IKE, 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, SPD, PAD and SAD (NOTE:
that SAD entries are created in runtime by IKE.) 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 is required to exchange IPsec-related
information. information.
5.2. Case 2: IPsec (no IKE) in the NSF 5.2. Case 2: IPsec (no IKEv2) in the NSF
In this case the NSF does not deploy IKE and, therefore, the Security In this case, the NSF does not deploy IKEv2 and, therefore, the
Controller has to perform the management of IPsec SAs by populating Security Controller has to perform the management of IPsec SAs by
and monitoring the SPD and the SAD. populating and monitoring 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
skipping to change at page 8, line 31 skipping to change at page 8, line 31
| Data Protection and Forwarding | | Data Protection and Forwarding |
+-----------------------------------------+ +-----------------------------------------+
Figure 2: Case 2: IPsec (no IKE) in the NSF Figure 2: Case 2: 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 IKE 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 Case 2
In order to support case 2, the following requirements are to be met: In order to support case 2, 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 is required to exchange IPsec-related
information. information.
5.3. Case 1 vs Case 2 5.3. Case 1 vs Case 2
Case 1 MAY be easier to deploy than Case 2 because current gateways Case 1 MAY be easier to deploy than Case 2 because current gateways
typically have an IKE/IPsec implementation. Moreover hosts can typically have an IKEv2/IPsec implementation. Moreover hosts can
install easily an IKE implementation. As downside, the NSF needs install easily an IKE implementation. As downside, the NSF needs
more resources to hold IKE. Moreover, the IKE implementation needs more resources to hold IKEv2. Moreover, the IKEv2 implementation
to implement an interface so that the I2NSF Agent can interact with needs to implement an interface so that the I2NSF Agent can interact
them. with them.
Alternatively, Case 2 allows lighter NSFs (no IKE implementation), Alternatively, Case 2 allows lighter NSFs (no IKEv2 implementation),
which benefits the deployment in constrained NSFs. Moreover, IKE which benefits the deployment in constrained NSFs. Moreover, IKEv2
does not need to be performed in gateway-to-gateway and host-to-host 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 scenarios under the same Security Controller (see Section 7.1). On
the contrary, the overload of creation of fresh IPsec SA is shifted the contrary, the overload of creating fresh IPsec SAs is shifted to
to the Security Controller since IKE is not in the NSF. As a the Security Controller since IKEv2 is not in the NSF. As a
consequence, this may result in a more complex implementation in the consequence, this may result in a more complex implementation in the
controller side. controller side.
For example, the Security Controller needs to supervise the IPsec SAs 5.3.1. Rekeying process
states and take care of the rekeying process so that, after some
period of time (e.g. IPsec SA soft lifetime), it has to create a new
IPsec SA and remove the old one. Or the Security Controller needs to
process events coming from the NSF when, for example, an IPsec SA is
requested (e.g. acquire or expire events).
Another example is the NAT traversal support. In general, the SDN For case 1, the rekeying process is carried out by IKEv2, following
paradigm assumes the Security Controller has a view of the network it the configuration defined in the SPD.
controls. This view is built either requesting information to the
NSFs under its control or because these NSFs inform the Security
Controller. Based on this information, the Security Controller can
guess if there is a NAT configured between two hosts, apply the
required policies to both NSFs besides activating the usage of UDP or
TCP/TLS encapsulation of ESP packets ([RFC3948], [RFC8229]).
In those scenarios, the Controller could directly request the NSF for For case 2, the Security Controller needs to take care of the
specific data such as networking configuration, NAT support, etc. rekeying process. When the IPsec SA is going to expire (e.g. IPsec
Protocols such as NETCONF or SNMP can be used here. For example, RFC SA soft lifetime), it has to create a new IPsec SA and remove the old
7317 [RFC7317] provides a YANG data model for system management or one. This rekeying process starts when the Security Controller
[I-D.sivakumar-yang-nat] a data model for NAT management. receives a sadb_expire notification or it decides so, based on
lifetime state data obtained from the NSF.
Finally, if one of the NSF restarts, it may lose part or all the To explain the rekeying process between two IPsec peers A and B, let
IPsec state (affected NSF). By default, the Security Controller can assume that SPIa1 identifies the inbound SA in A and SPIb1 the
assume that all the state has been lost and therefore it will have to inbound SA in B.
send IKEv2, SPD and PAD information to the NSF in case 1 and SPD and
SAD information in case 2. 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
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
A and another inbound SA in B with SPIb2. It can send this
information simultenously to 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
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
the new IPsec SA is ready.
3. The Security Controller deletes the old IPsec SAs from A (inbound
SPIa1 and outbound SPIb1) and B (outbound SPIa1 and inbound
SPIb1) in parallel.
5.3.2. NSF state loss
If one of the NSF restarts, it may lose part or all the IPsec state
(affected NSF). By default, the Security Controller can assume that
all the state has been lost and therefore it will have to send IKEv2,
SPD and PAD information to the NSF in case 1 and SPD and SAD
information in case 2.
In both cases, the Security Controller MUST be aware of the affected In both cases, the Security Controller MUST be aware of the affected
NSF (e.g. the NETCONF/TCP connection is broken with the affected NSF, NSF (e.g. the NETCONF/TCP connection is broken with the affected NSF,
it is receiving bad_spi notification from a particular NSF, etc...). it is receiving bad_spi notification from a particular NSF, etc...).
Moreover, the SDN controller MUST have a register about all the NSFs Moreover, the Security Controller MUST have a register about all the
that have IPsec SAS with the affected NSF. Therefore, it can know NSFs that have IPsec SAs with the affected NSF. Therefore, it knows
the affected IPsec SAs. the affected IPsec SAs.
In Case 1, the SDN controller will configure the affected NSF with In Case 1, the Security Controller will configure the affected NSF
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) to the NSFs which have IKEv2 SAs
and IPsec SAs with the affected NSF. It can also instruct the and IPsec SAs with the affected NSF. It can also instruct the
affected NSF to send INITIAL_CONTACT notification (It is TBD in the affected NSF to send IKEv2 INITIAL_CONTACT (It is TBD in the model).
model). Finally, the SDN controller will instruct the affected NSF Finally, the Security Controller will instruct the affected NSF to
to start the IKEv2 negotiation with the new configuration. start the IKEv2 negotiation with the new configuration.
In Case 2, the SDN controller will have to: 1) install new SAD In Case 2, if the Security Controller detects that a NSF has lost the
entries and remove old SAD entries (and SPD entries if it is needed) IPsec SAs (e.g. it reboots) it will follow similar steps to rekey:
in the NSFs that had IPsec SAs with the affected NSF; and 2) install the steps 1 and 2 remain equal but the step 3 will be slightly
new SPD entries and new SAD entries in the affected NSF to match with different. For example, if we assume that NSF B has lost its state,
the rest of the peers. the Security Controller MUST only delete the old IPsec SAs from A in
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
In case 1, IKEv2 already owns a mechanism to detect whether some of
the peers or both are behind a NAT. If there is a NAT network
configured between two peers, it is required to activate the usage of
UDP or TCP/TLS encapsulation of ESP packets ([RFC3948], [RFC8229])
On the contrary, case 2 does not have any protocol in the NSFs to
detect whether they are behind a NAT or not. However, the SDN
paradigm generally assumes the Security Controller has a view of the
network it controls. This view is built either requesting
information to the NSFs under its control, or because these NSFs
inform to the Security Controller. Based on this information, the
Security Controller can guess if there is a NAT configured between
two hosts, apply the required policies to both NSFs besides
activating the usage of UDP or TCP/TLS encapsulation of ESP packets
([RFC3948], [RFC8229]).
For example, the Security Controller could directly request the NSF
for specific data such as networking configuration, NAT support, etc.
Protocols such as NETCONF or SNMP can be used here. For example, RFC
7317 [RFC7317] provides a YANG data model for system management or
[I-D.sivakumar-yang-nat] a data model for NAT management.
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 case 1 and case 2 we have modelled the different
parameters and values that must be configured to manage IPsec SAs. parameters and values that must be configured to manage IPsec SAs.
Specifically, case 1 requires modelling IKEv2, SPD and PAD while case Specifically, case 1 requires modelling IKEv2, SPD and PAD while case
2 requires models for the SPD and SAD. A single YANG file represents 2 requires models for the SPD and SAD. A single YANG file represents
both cases though some part of the models are selectively activated both cases though some part of the models are selectively activated
depending a feature defined in the YANG file. For example, the IKE depending a feature defined in the YANG file. For example, the IKE
configuration is not enabled in case 2. configuration is not enabled in case 2.
In the following, we summarize, by using a tree representation, the In the following, we summarize, by using a tree representation, the
different configuration data models (NOTE: State data models are TBD different configuration and state data models. The complete YANG
though they are expected to be very similar to the model defined configuration data model is in Appendix A
here). The complete YANG configuration data model is in Appendix A
6.1. Security Policy Database (SPD) Model 6.1. Security Policy Database (SPD) Model
The definition of this model has been extracted from the The definition of this model has been extracted from the
specification in section 4.4.1 and Appendix D in [RFC4301] specification in section 4.4.1 and Appendix D in [RFC4301]
+--rw spd +--rw spd
| +--rw spd-entry* [rule-number] | +--rw spd-entry* [rule-number]
| +--rw rule-number uint64 | +--rw rule-number uint64
| +--rw priority? uint32 | +--rw priority? uint32
| +--rw names* [name] | +--rw names* [name]
| | +--rw name-type? ipsec-spd-name | | +--rw name-type? ipsec-spd-name
| | +--rw name string | | +--rw name string
| +--rw condition | +--rw condition
| | +--rw traffic-selector-list* [ts-number] | | +--rw traffic-selector-list* [ts-number]
| | +--rw ts-number uint32 | | +--rw ts-number uint32
| | +--rw direction? ipsec-traffic-direction | | +--rw direction? ipsec-traffic-direction
| | +--rw local-addresses* [start end] | | +--rw local-addresses* [start end]
| | | +--rw start inet:ip-address | | | +--rw start inet:ip-address
| | | +--rw end inet:ip-address | | | +--rw end inet:ip-address
skipping to change at page 11, line 41 skipping to change at page 12, line 32
| | +--rw esp-algorithms | | +--rw esp-algorithms
| | | +--rw authentication* integrity-algorithm-t | | | +--rw authentication* integrity-algorithm-t
| | | +--rw encryption* encryption-algorithm-t | | | +--rw encryption* encryption-algorithm-t
| | +--rw tunnel | | +--rw tunnel
| | +--rw local? inet:ip-address | | +--rw local? inet:ip-address
| | +--rw remote? inet:ip-address | | +--rw remote? inet:ip-address
| | +--rw bypass-df? boolean | | +--rw bypass-df? boolean
| | +--rw bypass-dscp? boolean | | +--rw bypass-dscp? boolean
| | +--rw dscp-mapping? yang:hex-string | | +--rw dscp-mapping? yang:hex-string
| | +--rw ecn? boolean | | +--rw ecn? boolean
| +--rw spd-lifetime | +--rw spd-mark
| +--rw time-soft? uint32 | | +--rw mark? uint32
| +--rw time-hard? uint32 | | +--rw mask? yang:hex-string
| +--rw time-use-soft? uint32 | +--rw spd-lifetime-hard
| +--rw time-use-hard? uint32 | | +--rw added? uint64
| +--rw byte-soft? uint32 | | +--rw used? uint64
| +--rw byte-hard? uint32 | | +--rw bytes? uint32
| +--rw packet-soft? uint32 | | +--rw packets? uint32
| +--rw packet-hard? 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.2. Security Association Database (SAD) Model
The definition of this model has been extracted from the The definition of this model has been extracted from the
specification in section 4.4.2 in [RFC4301] specification in section 4.4.2 in [RFC4301]
+--rw sad {case2}? +--rw sad
| +--rw sad-entry* [spi] | +--rw sad-entry* [spi]
| +--rw spi ipsec-spi | +--rw spi ipsec-spi
| +--rw seq-number? uint64 | +--rw seq-number? uint64
| +--rw seq-number-overflow-flag? boolean | +--rw seq-number-overflow-flag? boolean
| +--rw anti-replay-window? uint16 | +--rw anti-replay-window? uint16
| +--rw rule-number? uint32 | +--rw rule-number? uint32
| +--rw local-addresses* [start end] | +--rw local-addresses* [start end]
| | +--rw start inet:ip-address | | +--rw start inet:ip-address
| | +--rw end inet:ip-address | | +--rw end inet:ip-address
| +--rw remote-addresses* [start end] | +--rw remote-addresses* [start end]
skipping to change at page 12, line 44 skipping to change at page 13, line 44
| | +--rw key? string | | +--rw key? string
| +--rw esp-sa | +--rw esp-sa
| | +--rw encryption | | +--rw encryption
| | | +--rw encryption-algorithm? encryption-algorithm-t | | | +--rw encryption-algorithm? encryption-algorithm-t
| | | +--rw key? string | | | +--rw key? string
| | | +--rw iv? string | | | +--rw iv? string
| | +--rw integrity | | +--rw integrity
| | | +--rw integrity-algorithm? integrity-algorithm-t | | | +--rw integrity-algorithm? integrity-algorithm-t
| | | +--rw key? string | | | +--rw key? string
| | +--rw combined-enc-intr? boolean | | +--rw combined-enc-intr? boolean
| +--rw sa-lifetime | +--rw sad-lifetime-hard
| | +--rw time-soft? uint32 | | +--rw added? uint64
| | +--rw time-hard? uint32 | | +--rw used? uint64
| | +--rw time-use-soft? uint32 | | +--rw bytes? uint32
| | +--rw time-use-hard? uint32 | | +--rw packets? uint32
| | +--rw byte-soft? uint32 | | +--rw action? lifetime-action
| | +--rw byte-hard? uint32 | +--rw sad-lifetime-soft
| | +--rw packet-soft? uint32 | | +--rw added? uint64
| | +--rw packet-hard? uint32 | | +--rw used? uint64
| | +--rw action? lifetime-action | | +--rw bytes? uint32
| | +--rw packets? uint32
| | +--rw action? lifetime-action
| +--rw mode? ipsec-mode | +--rw mode? ipsec-mode
| +--rw statefulfragCheck? boolean | +--rw statefulfragCheck? boolean
| +--rw dscp? yang:hex-string | +--rw dscp? yang:hex-string
| +--rw path-mtu? uint16
| +--rw tunnel | +--rw tunnel
| | +--rw local? inet:ip-address | | +--rw local? inet:ip-address
| | +--rw remote? inet:ip-address | | +--rw remote? inet:ip-address
| | +--rw bypass-df? boolean | | +--rw bypass-df? boolean
| | +--rw bypass-dscp? boolean | | +--rw bypass-dscp? boolean
| | +--rw dscp-mapping? yang:hex-string | | +--rw dscp-mapping? yang:hex-string
| | +--rw ecn? boolean | | +--rw ecn? boolean
| +--rw path-mtu? uint16
| +--rw encap | +--rw encap
| +--rw espencap? esp-encap | | +--rw espencap? esp-encap
| +--rw sport? inet:port-number | | +--rw sport? inet:port-number
| +--rw dport? inet:port-number | | +--rw dport? inet:port-number
| +--rw oaddr? inet:ip-address | | +--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: rpcs:
+---x sadb_register +---x sadb_register
+---w input +---w input
| +---w base-list* [version] | +---w base-list* [version]
| +---w version string | +---w version string
| +---w msg_type? sadb-msg-type | +---w msg_type? sadb-msg-type
| +---w msg_satype? sadb-msg-satype | +---w msg_satype? sadb-msg-satype
| +---w msg_seq? uint32 | +---w msg_seq? uint32
+--ro output +--ro output
skipping to change at page 14, line 35 skipping to change at page 15, line 35
+--ro encryption +--ro encryption
+--ro name? encryption-algorithm-t +--ro name? encryption-algorithm-t
+--ro ivlen? uint8 +--ro ivlen? uint8
+--ro min-bits? uint16 +--ro min-bits? uint16
+--ro max-bits? uint16 +--ro max-bits? uint16
notifications: notifications:
+---n spdb_expire +---n spdb_expire
| +--ro index? uint64 | +--ro index? uint64
+---n sadb_acquire +---n sadb_acquire
| +--ro state uint32 | +--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 +---n sadb_expire
| +--ro state uint32 | +--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 +---n sadb_bad-spi
+--ro state ipsec-spi +--ro state ipsec-spi
6.3. Peer Authorization Database (PAD) Model 6.3. Peer Authorization Database (PAD) Model
The definition of this model has been extracted from the The definition of this model has been extracted from the
specification in section 4.4.3 in [RFC4301] (NOTE: We have observed specification in section 4.4.3 in [RFC4301] (NOTE: We have observed
that many implementations integrate PAD configuration as part of the that many implementations integrate PAD configuration as part of the
IKE configuration.) IKEv2 configuration.)
+--rw pad {case1}? +--rw pad {case1}?
+--rw pad-entries* [pad-entry-id] +--rw pad-entries* [pad-entry-id]
+--rw pad-entry-id uint64 +--rw pad-entry-id uint64
+--rw (identity)? +--rw (identity)?
| +--:(ipv4-address) | +--:(ipv4-address)
| | +--rw ipv4-address? inet:ipv4-address | | +--rw ipv4-address? inet:ipv4-address
| +--:(ipv6-address) | +--:(ipv6-address)
| | +--rw ipv6-address? inet:ipv6-address | | +--rw ipv6-address? inet:ipv6-address
| +--:(fqdn-string) | +--:(fqdn-string)
| | +--rw fqdn-string? inet:domain-name | | +--rw fqdn-string? inet:domain-name
skipping to change at page 15, line 35 skipping to change at page 17, line 35
+--rw rsa-signature +--rw rsa-signature
+--rw key-data? string +--rw key-data? string
+--rw key-file? string +--rw key-file? string
+--rw ca-data* string +--rw ca-data* string
+--rw ca-file? string +--rw ca-file? string
+--rw cert-data? string +--rw cert-data? string
+--rw cert-file? string +--rw cert-file? string
+--rw crl-data? string +--rw crl-data? string
+--rw crl-file? string +--rw crl-file? string
6.4. Internet Key Exchange (IKE) Model 6.4. Internet Key Exchange (IKEv2) Model
The model related to IKEv2 has been extracted from reading IKEv2 The model related to IKEv2 has been extracted from reading IKEv2
standard in [RFC7296], and observing some open source standard in [RFC7296], and observing some open source
implementations, such as Strongswan or Libreswan. implementations, such as Strongswan or Libreswan.
+--rw ikev2 {case1}? +--rw ikev2 {case1}?
| +--rw ike-connection | +--rw ike-connection
| +--rw ike-conn-entries* [conn-name] | | +--rw ike-conn-entries* [conn-name]
| +--rw conn-name string | | +--rw conn-name string
| +--rw autostartup type-autostartup | | +--rw autostartup type-autostartup
| +--rw nat-traversal? boolean | | +--rw nat-traversal? boolean
| +--rw encap | | +--rw encap
| | +--rw espencap? esp-encap | | | +--rw espencap? esp-encap
| | +--rw sport? inet:port-number | | | +--rw sport? inet:port-number
| | +--rw dport? inet:port-number | | | +--rw dport? inet:port-number
| | +--rw oaddr? inet:ip-address | | | +--rw oaddr? inet:ip-address
| +--rw version? enumeration | | +--rw version? enumeration
| +--rw phase1-lifetime uint32 | | +--rw phase1-lifetime uint32
| +--rw phase1-authalg* integrity-algorithm-t | | +--rw phase1-authalg* integrity-algorithm-t
| +--rw phase1-encalg* encryption-algorithm-t | | +--rw phase1-encalg* encryption-algorithm-t
| +--rw combined-enc-intr? boolean | | +--rw combined-enc-intr? boolean
| +--rw dh_group uint32 | | +--rw dh_group uint32
| +--rw local | | +--rw local
| | +--rw (my-identifier-type)? | | | +--rw (my-identifier-type)?
| | | +--:(ipv4) | | | | +--:(ipv4)
| | | | +--rw ipv4? inet:ipv4-address | | | | | +--rw ipv4? inet:ipv4-address
| | | +--:(ipv6) | | | | +--:(ipv6)
| | | | +--rw ipv6? inet:ipv6-address | | | | | +--rw ipv6? inet:ipv6-address
| | | +--:(fqdn) | | | | +--:(fqdn)
| | | | +--rw fqdn? inet:domain-name | | | | | +--rw fqdn? inet:domain-name
| | | +--:(dn) | | | | +--:(dn)
| | | | +--rw dn? string | | | | | +--rw dn? string
| | | +--:(user_fqdn) | | | | +--:(user_fqdn)
| | | +--rw user_fqdn? string | | | | +--rw user_fqdn? string
| | +--rw my-identifier string | | | +--rw my-identifier string
| +--rw remote | | +--rw remote
| | +--rw (my-identifier-type)? | | | +--rw (my-identifier-type)?
| | | +--:(ipv4) | | | | +--:(ipv4)
| | | | +--rw ipv4? inet:ipv4-address | | | | | +--rw ipv4? inet:ipv4-address
| | | +--:(ipv6) | | | | +--:(ipv6)
| | | | +--rw ipv6? inet:ipv6-address | | | | | +--rw ipv6? inet:ipv6-address
| | | +--:(fqdn) | | | | +--:(fqdn)
| | | | +--rw fqdn? inet:domain-name | | | | | +--rw fqdn? inet:domain-name
| | | +--:(dn) | | | | +--:(dn)
| | | | +--rw dn? string | | | | | +--rw dn? string
| | | +--:(user_fqdn) | | | | +--:(user_fqdn)
| | | +--rw user_fqdn? string | | | | +--rw user_fqdn? string
| | +--rw my-identifier string | | | +--rw my-identifier string
| +--rw pfs_group* uint32 | | +--rw pfs_group* uint32
| | +--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 our 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)+--------------+ |
skipping to change at page 17, line 31 skipping to change at page 19, line 41
| +--------------+ +--------------+ | | +--------------+ +--------------+ |
| | | | | | | |
| | | | | | | |
+--------------------------|-----|-------+ +--------------------------|-----|-------+
| | | |
| (3) | | (3) |
|-------------------------+ +---| |-------------------------+ +---|
V V V V
+----------------------+ +----------------------+ +----------------------+ +----------------------+
| NSF1 |<=======>| NSF2 | | NSF1 |<=======>| NSF2 |
|IKE/IPsec(SPD/PAD) | |IKE/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 case 1 .
Figure 3 describes the case 1: Figure 3 describes the case 1:
1. The administrator defines general flow-based security policies. 1. The administrator defines general flow-based security policies.
The controller looks for the NSFs involved (NSF1 and NSF2). The Security Controller looks for the NSFs involved (NSF1 and
NSF2).
2. The controller generates IKE credentials for them and translates 2. The Security Controller generates IKEv2 credentials for them and
the policies into SPD and PAD entries. translates the policies into SPD and PAD entries.
3. The controller inserts the SPD and PAD entries in both NSF1 and 3. The Security Controller inserts the SPD and PAD entries in both
NSF2. NSF1 and NSF2.
4. The flow is protected with the IPsec SA established with IKEv2. 4. The flow is protected with the IPsec SA established with IKEv2.
+----------------------------------------+ +----------------------------------------+
| (1) Security Controller | | (1) Security Controller |
Flow-based | | Flow-based | |
Security -----------| | Security -----------| |
Policy | V | Policy | V |
| +---------------+ (2)+-------------+ | | +---------------+ (2)+-------------+ |
| |Translate into |--->| South. Prot.| | | |Translate into |--->| South. Prot.| |
skipping to change at page 18, line 32 skipping to change at page 20, line 44
| 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 case 2.
In case 2, flow-based security policies defined by the administrator In case 2, flow-based security policies defined by the administrator
are also translated into IPsec SPD entries and inserted into the are also translated into IPsec SPD entries and inserted into the
corresponding NSFs. Besides, fresh SAD entries will be also corresponding NSFs. Besides, fresh SAD entries will be also
generated by the controller and enforced in the NSFs. In this case generated by the Security Controller and enforced in the NSFs. In
the controller does not run any IKE implementation, and it provides this case the controller does not run any IKE implementation, and it
the cryptographic material for the IPsec SAs. These keys will be provides the cryptographic material for the IPsec SAs. These keys
also distributed securely through the southbound interface. Note will be also distributed securely through the southbound interface.
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 case 2, 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 controller looks for the involved NSFs. The Security Controller looks for the involved NSFs.
2. The controller translates the flow-based security policies into 2. The Security Controller translates the flow-based security
IPsec SPD and SAD entries. policies into IPsec SPD and SAD entries.
3. The controller inserts the these entries in both NSF1 and NSF2 3. The Security Controller inserts the these entries in both NSF1
IPsec databases. and NSF2 IPsec databases.
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.
skipping to change at page 19, line 23 skipping to change at page 21, line 35
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 case 1 and case 2), this system presents various
advantages: advantages:
1. It allows to create a IPsec SA 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
skipping to change at page 20, line 16 skipping to change at page 22, line 18
| | | | | | | |
Flow-based| Security |<===============>| Security <--Flow-based Flow-based| Security |<===============>| Security <--Flow-based
Sec. Pol.--> Controller | (3) | Controller | Sec. Pol. Sec. Pol.--> Controller | (3) | Controller | Sec. Pol.
(1) | A | | B | (2) (1) | A | | B | (2)
+-------------+ +-------------+ +-------------+ +-------------+
| | | |
| (4) (4) | | (4) (4) |
V V V V
+----------------------+ +----------------------+ +----------------------+ +----------------------+
| NSF1 |<========>| NSF2 | | NSF1 |<========>| NSF2 |
|IKE/IPsec(SPD/PAD) | |IKE/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 Case 1
Figure 5 describes case 1 when two Security Controllers are involved Figure 5 describes case 1 when two Security Controllers are involved
in the process. in the process.
1. The A's 'administrator establishes general Flow-based Security 1. The A's administrator establishes general Flow-based Security
Policies in Security Controller A. Policies in Security Controller A.
2. The B's administrator establishes general Flow-based Security 2. The B's administrator establishes general Flow-based Security
Policies in Security Controller B. Policies in Security Controller B.
3. The Security Controller A realizes that protection is required 3. The Security Controller A realizes that protection is required
between the NSF1 and NSF2, but the NSF2 is under the control of between the NSF1 and NSF2, but the NSF2 is under the control of
another Security Controller (Security Controller B), so it starts another Security Controller (Security Controller B), so it starts
negotiations with the other controller to agree on the IPsec SPD negotiations with the other controller to agree on the IPsec SPD
policies and IKE credentials for their respective NSFs. NOTE: policies and IKEv2 credentials for their respective NSFs. NOTE:
This may require extensions in the East/West interface. This may require extensions in the East/West interface.
4. Then, both Security Controllers enforce the IKE credentials and 4. Then, both Security Controllers enforce the IKEv2 credentials and
related parameters and the SPD and PAD entries in their related parameters and the SPD and PAD entries in their
respective NSFs. respective NSFs.
5. The flow is protected with the IPsec SA established with IKEv2 5. The flow is protected with the IPsec SAs established with IKEv2
between both NSFs. between both NSFs.
+--------------+ +--------------+ +--------------+ +--------------+
| | | | | | | |
Flow-based. ---> | <---- Flow-based Flow-based. ---> | <--- Flow-based
Prot. | Security |<=================>| Security |Sec. Prot. | Security |<=================>| Security |Sec.
Pol.(1)| Controller | (3) | Controller |Pol. (2) Pol.(1)| Controller | (3) | Controller |Pol. (2)
| A | | B | | A | | B |
+--------------+ +--------------+ +--------------+ +--------------+
| | | |
| (4) (4) | | (4) (4) |
V V V V
+------------------+ (5) +------------------+ +------------------+ (5) +------------------+
| NSF1 |<==============>| NSF2 | | NSF1 |<==============>| NSF2 |
|IPsec(SPD/SAD) | | IPsec(SPD/SAD) | |IPsec(SPD/SAD) | | IPsec(SPD/SAD) |
+------------------+ +------------------+ +------------------+ +------------------+
Figure 6: Different Security Controllers in case 2 Figure 6: Different Security Controllers in case 2
Figure 5 describes case 1 when two Security Controllers are involved Figure 5 describes case 2 when two Security Controllers are involved
in the process. 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
it starts negotiations with the other controller to agree on the it starts negotiations with the other controller to agree on the
IPsec SPD and SAD entries that define the IPsec SAs. NOTE: It IPsec SPD and SAD entries that define the IPsec SAs. NOTE: It
would worth evaluating IKE 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 controllers have agreed on key material and the details 4. Once the Security Controllers have agreed on key material and the
of the IPsec SA, they both enforce this information into their details of the IPsec SAs, they both enforce this information into
respective NSFs. their respective NSFs.
5. The flow is protected with the IPsec SA 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. Implementation notes
At the time of writing this document, we have implemented a proof-of- At the time of writing this document, we have implemented a proof-of-
concept using NETCONF as southbound protocol, and the YANG model concept using NETCONF as southbound protocol, and the YANG model
described in Appendix A. The netopeer implementation [netopeer] has described in Appendix A. The netopeer implementation [netopeer] has
been used for both case 1 and case 2 using host-to-host and gateway- 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 to-gateway configuration. For the case 1, we have used Strongswan
[strongswan] distribution for the IKE implementation. [strongswan] distribution for the IKE implementation.
Note that the proposed YANG model provides the models for SPD, SAD, 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 PAD and IKE, but, as describe before, only part of them are required
depending of the case (1 or 2) been applied. The Controller should depending of the case (1 or 2) been applied. The Security Controller
be able to know the kind of case to be applied in the NSF and to should be able to know the kind of case to be applied in the NSF and
select the corresponding models based on the YANG features defines to select the corresponding models based on the YANG features defines
for each one for each one.
Internally to the NSF, the NETCONF server (that implements the I2NSF Internally to the NSF, the NETCONF server (that implements the I2NSF
Agent) is able to apply the required configuration updating the Agent) is able to apply the required configuration updating the
corresponding NETCONF datastores (running, startup, etc.). Besides, corresponding NETCONF datastores (running, startup, etc.). Besides,
it can deal with the SPD and SAD configuration at kernel level, it can deal with the SPD and SAD configuration at kernel level,
through different APIs. For example, the IETF RFC 2367 (PF_KEYv2) through different APIs. For example, the IETF RFC 2367 (PF_KEYv2)
[RFC2367] provides a generic key management API that can be used not [RFC2367] provides a generic key management API that can be used not
only for IPsec but also for other network security services to manage only for IPsec but also for other network security services to manage
the IPsec SAD. Besides, as an extension to this API, the document 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. [I-D.pfkey-spd] specifies some PF_KEY extensions to maintain the SPD.
skipping to change at page 22, line 47 skipping to change at page 24, line 47
[ITU-T.Y.3300] and [RFC8192]. We have divided this section in two [ITU-T.Y.3300] and [RFC8192]. We have divided this section in two
parts to analyze different security considerations for both cases: parts to analyze different security considerations for both cases:
NSF with IKEv2 (case 1) and NSF without IKEv2 (case 2). In general, NSF with IKEv2 (case 1) and NSF without IKEv2 (case 2). In general,
the Security Controller, as typically in the SDN paradigm, is a the Security Controller, as typically in the SDN paradigm, is a
target for different type of attacks. As a consequence, the Security target for different type of attacks. As a consequence, the Security
Controller is a key entity in the infrastructure and MUST be Controller is a key entity in the infrastructure and MUST be
protected accordingly. In particular, according to this document, protected accordingly. In particular, according to this document,
the Security Controller will handle cryptographic material so that the Security Controller will handle cryptographic material so that
the attacker may try to access this information. Although, we can the attacker may try to access this information. Although, we can
assume this attack will not likely to happen due to the assumed assume this attack will not likely to happen due to the assumed
security measurements to protect the Security Controller, some security measurements to protect the Security Controller, it deserves
analysis of the impact deserves some analysis in the hypothetical the some analysis in the hypothetical the attack occurs. The impact is
attack occurs. The impact is different depending on the case 1 or different depending on the case 1 or case 2.
case 2.
9.1. Case 1 9.1. Case 1
In this case 1, the controller sends IKE credentials (PSK, public/ In this case 1, the Security Controller sends IKE credentials (PSK,
private keys, certificates, etc...) to the NSFs. The general public/private keys, certificates, etc...) to the NSFs. The general
recommendation is that the Security Controller NEVER stores the IKE recommendation is that the Security Controller NEVER stores the IKE
credentials after distributing them. Moreover the NSFs MUST NOT credentials after distributing them. Moreover the NSFs MUST NOT
allow the reading of these values once they have been applied by the allow the reading of these values once they have been applied by the
Security Controller (i.e. write only operations). If the attacker Security Controller (i.e. write only operations). If the attacker
has access to the Security Controller during the period of time that has access to the Security Controller during the period of time that
key material is generated, it may access to these values. Since key material is generated, it may access to these values. Since
these values are used during NSF authentication in IKEv2, it may these values are used during NSF authentication in IKEv2, it may
impersonate the affected NSFs. Several recommendations are impersonate the affected NSFs. Several recommendations are
important. If PSK is used, immediately after generating and important. If PSK authentication is used in IKEv2 is used,
distributing it, the Security Controller should remove it. If raw immediately after generating and distributing it, the Security
public keys are used, the Security Controller should remove the Controller should remove it. If raw public keys are used, the
associate private key immediately after generating and distributing Security Controller should remove the associate private key
them to the Security Controller. If certificates are used, the NSF immediately after generating and distributing them to the NSFs. If
may generate the private key and exports the public key for certificates are used, the NSF may generate the private key and
certification in the Security Controller. exports the public key for certification in the Security Controller.
9.2. Case 2 9.2. Case 2
In the case 2, the controller sends the IPsec SA to the SAD that In the case 2, the controller sends the IPsec SA information to the
includes the keys for integrity and encryption (when ESP is used). SAD that includes the keys for integrity and encryption (when ESP is
That key material are symmetric keys to protect data traffic. The used). That key material are symmetric keys to protect data traffic.
general recommendation is that the Security Controller NEVER stores The general recommendation is that the Security Controller NEVER
the keys after distributing them. Moreover the NSFs MUST NOT allow stores the keys after distributing them. Moreover the NSFs MUST NOT
the reading of these values once they have been applied by the allow the reading of these values once they have been applied by the
Security Controller (i.e. write only operations). Nevertheless, if Security Controller (i.e. write only operations). Nevertheless, if
the attacker has access to the Security Controller during the period the attacker has access to the Security Controller during the period
of time that key material is generated, it may access to these of time that key material is generated, it may access to these
values. In other words, it may have access to the key material used values. In other words, it may have access to the key material used
in the distributed IPsec SAs. in the distributed IPsec SAs and observe the traffic between peers.
10. Acknowledgements 10. Acknowledgements
Authors want to thank Sowmini Varadhan, David Carrel, Yoav Nir, Tero Authors want to thank Sowmini Varadhan, David Carrel, Yoav Nir, Tero
Kivinen, Paul Wouters, Graham Bartlett, Sandeep Kampati, Linda Kivinen, Paul Wouters, Graham Bartlett, Sandeep Kampati, Linda
Dunbar, Carlos J. Bernardos, Alejandro Perez-Mendez, Fernando Dunbar, Carlos J. Bernardos, Alejandro Perez-Mendez, Fernando
Pereniguez-Garcia, Alejandro Abad-Carrascosa, Ignacio Martinez and Pereniguez-Garcia, Alejandro Abad-Carrascosa, Ignacio Martinez and
Ruben Ricart for their valuable comments. Ruben Ricart for their valuable comments.
11. References 11. References
skipping to change at page 27, line 7 skipping to change at page 29, line 7
[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: YANG model IPsec Configuration data
<CODE BEGINS> file "ietf-ipsec@2018-01-08.yang" <CODE BEGINS> file "ietf-ipsec@2018-06-29.yang"
module ietf-ipsec { module ietf-ipsec {
namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec"; namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec";
prefix "eipsec";
import ietf-inet-types { prefix inet; }
import ietf-yang-types { prefix yang; }
organization "University of Murcia";
contact prefix "eipsec";
" Rafael Marin Lopez
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501
e-mail: rafa@um.es
Gabriel Lopez Millan import ietf-inet-types { prefix inet; }
Dept. Information and Communications Engineering (DIIC) import ietf-yang-types { prefix yang; }
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Tel: +34 868888504
email: gabilm@um.es
";
description "Data model for IPSec"; organization "University of Murcia";
revision "2018-01-08" { contact
description " Rafael Marin Lopez
"Initial revision."; Dept. Information and Communications Engineering (DIIC)
reference ""; Faculty of Computer Science-University of Murcia
} 30100 Murcia - Spain
Telf: +34868888501
e-mail: rafa@um.es
feature case1 { description "feature case 1: IKE SPD PAD"; } // IKE/IPSec in the NSFs Gabriel Lopez Millan
feature case2 { description "feature case 2: SPD SAD"; } // Only IPSec in the NSFs Dept. Information and Communications Engineering (DIIC)
typedef encryption-algorithm-t { Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Tel: +34 868888504
email: gabilm@um.es
";
type enumeration { description "Data model for IPSec";
enum reserved-0 {description "reserved";}
enum des-iv4 { description "DES IV 4";}
enum des { description "DES"; }
enum 3des { description "3DES"; }
enum rc5 { description "RC5"; }
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 -> 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"; }
enum AES-GCM-16-ICV { description "AES-GCM-16-ICV (AEAD)"; }
enum AES-CCM { description "AES-CCM (AEAD)"; }
}
description "Encryption algorithms -> RFC_5996";
}
typedef integrity-algorithm-t { revision "2018-06-29" {
description
"Revision";
reference "";
}
type enumeration { feature case1 { description "feature case 1: IKE SPD PAD"; } // IKE/IPSec in the NSFs
enum none { description "NONE"; } feature case2 { description "feature case 2: SPD SAD"; } // Only IPSec in the NSFs
enum hmac-md5-96 { description "HMAC-MD5-96"; }
enum hmac-sha1-96 { description "HMAC-SHA1-96"; }
enum des-mac { description "DES-MAC"; }
enum kpdk-md5 {description "KPDK-MD5"; }
enum aes-xcbc-96 { description "AES-XCBC-96"; }
enum hmac-md5-128 { description "HMAC-MD5-128"; }
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 -> RFC_5996";
}
typedef type-autostartup typedef encryption-algorithm-t {
{
type enumeration {
enum ALWAYSON { description " ";}
enum INITIATE-ON-DEMAND {description " ";}
enum RESPOND-ONLY {description " ";}
}
description "Different types of how IKEv2 starts the IPsec SAs";
}
typedef auth-protocol-type { type enumeration {
type enumeration { enum reserved-0 {description "reserved";}
enum IKEv1 { // not supported by model enum des-iv4 { description "DES IV 4";}
description "Authentication protocol based on IKEv1"; enum des { description "DES"; }
} enum 3des { description "3DES"; }
enum IKEv2 { enum rc5 { description "RC5"; }
description "Authentication protocol based on IKEv2"; enum idea { description "IDEA"; }
} enum cast { description "CAST"; }
enum KINK { // not supported by model enum blowfish { description "BlowFish"; }
description "Authentication protocol based on KINK"; 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";
description "Peer authentication protocols"; }
}
typedef ipsec-mode { typedef integrity-algorithm-t {
type enumeration { type enumeration {
enum TRANSPORT { description "Transport mode"; } enum none { description "NONE"; }
enum TUNNEL { description "Tunnel mode"; } enum hmac-md5-96 { description "HMAC-MD5-96"; }
enum BEET { description "Bound End-to-End Tunnel (BEET) mode for ESP.";} enum hmac-sha1-96 { description "HMAC-SHA1-96"; }
enum RO { description "Route Optimization mode for Mobile IPv6";} enum des-mac { description "DES-MAC"; }
enum IN_TRIGGER {description "In trigger mode for Mobile IPv6";} enum kpdk-md5 {description "KPDK-MD5"; }
} enum aes-xcbc-96 { description "AES-XCBC-96"; }
description "type define of ipsec mode"; enum hmac-md5-128 { description "HMAC-MD5-128"; }
} 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 esp-encap { typedef type-autostartup {
type enumeration {
enum ALWAYSON { description " ";}
enum INITIATE-ON-DEMAND {description " ";}
enum RESPOND-ONLY {description " ";}
}
description "Different types of how IKEv2 starts the IPsec SAs";
}
type enumeration { typedef auth-protocol-type {
enum ESPINTCP { description "ESP in TCP encapulation.";} type enumeration {
enum ESPINTLS { description "ESP in TCP encapsulation using TLS.";} enum IKEv1 { description "Authentication protocol based on IKEv1"; }
enum ESPINUDP { description "ESP in UDP encapsulation. RFC 3948 ";} enum IKEv2 { description "Authentication protocol based on IKEv2"; }
} enum KINK { description "Authentication protocol based on KINK"; }
description "type defining types of ESP encapsulation"; }
} description "Peer authentication protocols";
}
typedef ipsec-protocol { 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";
}
type enumeration { typedef esp-encap {
enum ah { description "AH Protocol"; } type enumeration {
enum esp { description "ESP Protocol"; } enum ESPINTCP { description "ESP in TCP encapulation.";}
enum comp { description "IP Compression";} /*Supported by XFRM*/ enum ESPINTLS { description "ESP in TCP encapsulation using TLS.";}
enum route2 { description "Routing Header type 2. Mobile IPv6";} /*Supported by XFRM*/ enum ESPINUDP { description "ESP in UDP encapsulation. RFC 3948 ";}
enum hao {description "Home Agent Option";} /*Supported by XFRM*/ }
} description "type defining types of ESP encapsulation";
description "type define of ipsec security protocol"; }
}
typedef ipsec-spi { typedef ipsec-protocol {
type enumeration {
enum ah { description "AH Protocol"; }
enum esp { description "ESP Protocol"; }
enum comp { description "IP Compression";} /*Supported by XFRM*/
enum route2 { description "Routing Header type 2. Mobile IPv6";} /*Supported by XFRM*/
enum hao {description "Home Agent Option";} /*Supported by XFRM*/
}
description "type define of ipsec security protocol";
}
type uint32 { range "1..max"; } typedef ipsec-spi {
description "SPI"; type uint32 { range "0..max"; }
} description "SPI";
}
typedef lifetime-action { typedef lifetime-action {
type enumeration { type enumeration {
enum terminate {description "Terminate the IPsec SA";} enum terminate {description "Terminate the IPsec SA";}
enum replace {description "Replace the IPsec SA with a new one";} enum replace {description "Replace the IPsec SA with a new one";}
} }
description "Action when lifetime expiration"; description "Action when lifetime expiration";
} }
typedef ipsec-traffic-direction {
type enumeration {
enum INBOUND { description "Inbound traffic"; }
enum OUTBOUND { description "Outbound traffic"; }
enum FORWARD{ description "Forwarded traffic"; }
}
description "IPsec traffic direction";
}
typedef ipsec-spd-operation {
type enumeration {
enum PROTECT { description "PROTECT the traffic with IPsec"; }
enum BYPASS { description "BYPASS the traffic"; }
enum DISCARD { description "DISCARD the traffic"; }
}
description "The operation when traffic matches IPsec security policy";
}
typedef ipsec-next-layer-proto { typedef ipsec-traffic-direction {
type enumeration {
enum INBOUND { description "Inbound traffic"; }
enum OUTBOUND { description "Outbound traffic"; }
enum FORWARD{ description "Forwarded traffic"; }
}
description "IPsec traffic direction";
}
type enumeration { typedef ipsec-spd-operation {
enum TCP { description "PROTECT the traffic with IPsec"; } type enumeration {
enum UDP { description "BYPASS the traffic"; } enum PROTECT { description "PROTECT the traffic with IPsec"; }
enum SCTP { description "PROTECT the traffic with IPsec";} enum BYPASS { description "BYPASS the traffic"; }
enum DCCP { description "PROTECT the traffic with IPsec";} enum DISCARD { description "DISCARD the traffic"; }
enum ICMP { description "PROTECT the traffic with IPsec";} }
enum IPv6-ICMP { description "PROTECT the traffic with IPsec";} description "The operation when traffic matches IPsec security policy";
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 { }
type enumeration { typedef ipsec-next-layer-proto {
enum id_rfc_822_addr { type enumeration {
description "Fully qualified user name string."; 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";}
} }
enum id_fqdn { description "Next layer proto on top of IP";
description "Fully qualified DNS name."; }
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."; }
} }
enum id_der_asn1_dn { description "IPsec SPD name type";
description "X.500 distinguished name."; }
typedef auth-method-type {
/* 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 rsa-signature { description "Select rsa digital signature as the authentication method"; }
enum dss-signature { description "Select dss digital signature as the authentication method"; }
enum eap { description "Select EAP as the authentication method"; }
} }
enum id_key { description "Peer authentication method";
description "IKEv2 Key ID."; }
typedef sa-state {
type enumeration {
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";
description "IPsec SPD name type"; }
}
typedef auth-method-type { grouping lifetime {
/* Most implementations also provide XAUTH protocol, others used are: BLISS, P12, NTLM, PIN */ description "lifetime current state data";
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";}
}
type enumeration { /*################## PAD grouping ####################*/
enum pre-shared {
description "Select pre-shared key message as the authentication method";
}
enum rsa-signature {
description "Select rsa digital signature as the authentication method";
}
enum dss-signature {
description "Select dss digital signature as the authentication method";
}
enum eap {
description "Select EAP as the authentication method";
}
}
description "Peer authentication method";
}
/*################## PAD grouping ####################*/ grouping auth-method-grouping {
description "Peer authentication method data";
grouping auth-method-grouping { container auth-method {
description "Peer authentication method data"; description "Peer authentication method container";
container auth-method { leaf auth-m { type auth-method-type; description "Type of authentication method (preshared, rsa, etc.)"; }
description "Peer authentication method container";
leaf auth-m { container pre-shared {
type auth-method-type; when "../auth-m = 'pre-shared'";
description "Type of authentication method (preshared, rsa, etc.)"; leaf secret { type string; description "Pre-shared secret value";}
description "Shared secret value";
}
container rsa-signature {
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";
}
} }
container pre-shared { }
when "../auth-m = 'pre-shared'";
leaf secret { type string; description "Pre-shared secret value";} grouping identity-grouping {
description "Shared secret value"; 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 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";
} /* From RFC4301 list of id types */
} }
} /* grouping identity-grouping */
container rsa-signature { /*################ end PAD grouping ##################*/
when "../auth-m = 'rsa-signature'";
leaf key-data {
type string;
description "RSA private key data - PEM";
}
leaf key-file { /*################## SAD and SPD grouping ####################*/
type string;
description "RSA private key file name ";
}
leaf-list ca-data { grouping ip-addr-range {
type string; description "IP address range grouping";
description "List of trusted CA certs - PEM"; leaf start { type inet:ip-address; description "Start IP address"; }
} leaf end { type inet:ip-address; description "End IP address"; }
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 { grouping port-range {
description "Identification type. It is an union identity"; description "Port range grouping";
choice identity { leaf start { type inet:port-number; description "Start IP address"; }
description "Choice of identity."; leaf end { type inet:port-number; description "End IP address"; }
}
leaf ipv4-address { grouping tunnel-grouping {
type inet:ipv4-address; description "Tunnel mode grouping";
description "Specifies the identity as a single four (4) octet IPv4 address. An example is, 10.10.10.10. "; leaf local{ type inet:ip-address; description "Local tunnel endpoint"; }
} leaf remote{ type inet:ip-address; description "Remote tunnel enpoint"; }
leaf ipv6-address { leaf bypass-df { type boolean; description "bypass DF bit"; }
type inet:ipv6-address; leaf bypass-dscp { type boolean; description "bypass DSCP"; }
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 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 {
description "Traffic selector grouping";
list local-addresses {
key "start end";
uses ip-addr-range;
description "List of local addresses";
} }
leaf fqdn-string { list remote-addresses {
type inet:domain-name; key "start end";
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.)."; uses ip-addr-range;
description "List of remote addresses";
} }
leaf rfc822-address-string { leaf-list next-layer-protocol { type ipsec-next-layer-proto; description "List of Next Layer Protocol";}
type string; list local-ports {
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.)."; key "start end";
uses port-range;
description "List of local ports";
} }
leaf dnX509 { list remote-ports {
type string; key "start end";
description "Specifies the identity as a distinguished name in the X.509 tradition."; uses port-range;
description "List of remote ports";
} }
leaf id_key { }
type string;
description "Key id";
} /* From RFC4301 list of id types */
}
} /* grouping identity-grouping */
/*################ end PAD grouping ##################*/
/*################## SAD and SPD grouping ####################*/ /*################## SAD grouping ####################*/
grouping ipsec-sa-grouping {
description "Configure Security Association (SA). Section 4.4.2.1 in RFC 4301";
grouping ip-addr-range { leaf spi { type ipsec-spi; description "Security Parameter Index";}
description "IP address range grouping"; leaf seq-number { type uint64; description "Current sequence number of IPsec packet."; }
leaf start { 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."; }
type inet:ip-address; leaf anti-replay-window { type uint16 { range "0 | 32..1024"; } description "Anti replay window size"; }
description "Start IP address"; leaf rule-number {type uint32; description "This value links the SA with the SPD entry";}
}
leaf end {
type inet:ip-address;
description "End IP address";
}
}
grouping port-range { uses selector-grouping;
description "Port range grouping";
leaf start {
type inet:port-number;
description "Start IP address";
}
leaf end {
type inet:port-number;
description "End IP address";
}
}
grouping tunnel-grouping { leaf security-protocol { type ipsec-protocol; description "Security protocol of IPsec SA: Either AH or ESP."; }
description "Tunnel mode grouping";
leaf local{ type inet:ip-address; description "Local tunnel endpoint"; }
leaf remote{ type inet:ip-address; description "Remote tunnel enpoint"; }
leaf bypass-df { type boolean; description "bypass DF bit"; }
leaf bypass-dscp { type boolean; description "bypass DSCP"; }
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-sa {
description "Traffic selector grouping"; when "../security-protocol = 'ah'";
list local-addresses { description "Configure Authentication Header (AH) for SA";
key "start end"; container integrity {
uses ip-addr-range; description "Configure integrity for IPSec Authentication Header (AH)";
description "List of local addresses"; leaf integrity-algorithm { type integrity-algorithm-t; description "Configure Authentication Header (AH)."; }
} leaf key { type string; description "AH key value";}
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 { container esp-sa {
key "start end"; when "../security-protocol = 'esp'";
uses port-range; description "Set IPSec Encapsulation Security Payload (ESP)";
description "List of remote ports";
}
}
/*################## SAD grouping ####################*/ container encryption {
grouping ipsec-sa-grouping { description "Configure encryption for IPSec Encapsulation Secutiry Payload (ESP)";
description "Configure Security Association (SA). Section 4.4.2.1 in RFC 4301"; 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"; }
}
leaf spi { type ipsec-spi; description "Security Parameter Index";} container integrity {
leaf seq-number { type uint64; description "Current sequence number of IPsec packet."; } description "Configure authentication for IPSec Encapsulation Secutiry Payload (ESP)";
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 integrity-algorithm { type integrity-algorithm-t; description "Configure Authentication Header (AH)."; }
leaf anti-replay-window { type uint16 { range "0 | 32..1024"; } description "Anti replay window"; } leaf key { type string; description "ESP integrity key value";}
leaf rule-number {type uint32; description "This value links the SA with the SPD entry";} }
uses selector-grouping; leaf combined-enc-intr { type boolean; description "ESP combined mode algorithms. The algorithm is specified in encryption-algorithm in the container encryption";}
}
leaf security-protocol { type ipsec-protocol; description "Security protocol of IPsec SA: Either AH or ESP."; } container sad-lifetime-hard {
description "SAD lifetime hard state data";
uses lifetime;
leaf action {type lifetime-action; description "action lifetime";}
}
container ah-sa { container sad-lifetime-soft {
when "../security-protocol = 'ah'"; description "SAD lifetime hard state data";
description "Configure Authentication Header (AH) for SA"; uses lifetime;
container integrity { leaf action {type lifetime-action; description "action lifetime";}
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 { leaf mode { type ipsec-mode; description "SA Mode"; }
when "../security-protocol = 'esp'"; leaf statefulfragCheck { type boolean; description "TRUE stateful fragment checking, FALSE no stateful fragment checking"; }
description "Set IPSec Encapsulation Security Payload (ESP)"; leaf dscp { type yang:hex-string; description "DSCP value"; }
leaf path-mtu { type uint16; description "Maximum size of an IPsec packet that can be transmitted without fragmentation"; }
container encryption { container tunnel {
description "Configure encryption for IPSec Encapsulation Secutiry Payload (ESP)"; when "../mode = 'TUNNEL'";
leaf encryption-algorithm { type encryption-algorithm-t; description "Configure ESP encryption"; } uses tunnel-grouping;
leaf key { type string; description "ESP encryption key value";} description "Container for tunnel grouping";
leaf iv {type string; description "ESP encryption IV value"; }
} }
container integrity { container encap { /* This is defined by XFRM */
description "Configure authentication for IPSec Encapsulation Secutiry Payload (ESP)"; description "Encapsulation container";
leaf integrity-algorithm { type integrity-algorithm-t; description "Configure Authentication Header (AH)."; } leaf espencap { type esp-encap; description "ESP in TCP, ESP in UDP or ESP in TLS";}
leaf key { type string; description "ESP integrity key value";} 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 combined-enc-intr { type boolean; description "ESP combined mode algorithms. The algorithm is specified in encryption-algorithm in the container encryption";}
}
container sa-lifetime { // STATE DATA for SA
description "This may be expressed as a time or byte count, or a simultaneous use of both with the first lifetime to expire taking precedence"; container sad-lifetime-current {
leaf time-soft { type uint32; default 0; description "Soft time lifetime";} uses lifetime;
leaf time-hard { type uint32; default 0; description "Hard time lifetime"; } config false;
leaf time-use-soft { type uint32; default 0; description "Use Soft time lifetime";} description "SAD lifetime current state data";
leaf time-use-hard { type uint32; default 0; description "Use Hard time lifetime";} }
leaf byte-soft { type uint32; default 0;description "Byte soft lifetime"; }
leaf byte-hard { type uint32; default 0; description "Byte hard lifetime";}
leaf packet-soft {type uint32; default 0; description "Packet soft lifetime";}
leaf packet-hard { type uint32; default 0; description "Packet hard lifetime";}
leaf action {type lifetime-action; description "action lifetime";}
}
leaf mode { type ipsec-mode; description "SA Mode"; } leaf state {type sa-state; config false; description "current state of SA (mature, larval, dying or dead)"; }
leaf statefulfragCheck { type boolean; description "TRUE stateful fragment checking, FALSE no stateful fragment checking"; }
leaf dscp { type yang:hex-string; description "DSCP value"; }
container tunnel { container stats { // xfrm.h
when "../mode = 'TUNNEL'"; leaf replay-window {type uint32; default 0; description " "; }
uses tunnel-grouping; leaf replay {type uint32; default 0; description "packets detected out of the replay window and dropped because they are replay packets";}
description "Container for tunnel grouping"; leaf failed {type uint32; default 0; description "packets detected out of the replay window ";}
} config false;
description "SAD statistics";
}
leaf path-mtu { type uint16; description "Maximum size of an IPsec packet that can be transmitted without fragmentation"; } container replay_state { // xfrm.h
container encap { /* This is defined by XFRM */ leaf seq {type uint32; default 0; description "input traffic sequence number when anti-replay-window != 0";}
description "Encapsulation container"; leaf oseq {type uint32; default 0; description "output traffic sequence number";}
leaf espencap { type esp-encap; description "ESP in TCP, ESP in UDP or ESP in TLS";} leaf bitmap {type uint32; default 0; description "";}
leaf sport {type inet:port-number; description "Encapsulation source port";} config false;
leaf dport {type inet:port-number; description "Encapsulation destination port"; } description "Anti-replay Sequence Number state";
leaf oaddr {type inet:ip-address; description "Encapsulation Original Address ";} }
}
} container replay_state_esn { // xfrm.h
leaf bmp-len {type uint32; default 0; description "bitmap length for ESN"; }
leaf oseq { type uint32; default 0; description "output traffic sequence number"; }
leaf oseq-hi { type uint32; default 0; description ""; }
leaf seq-hi { type uint32; default 0; description ""; }
leaf replay-window {type uint32; default 0; description ""; }
leaf-list bmp { type uint32; description "bitmaps for ESN (depends on bmp-len) "; }
config false;
description "Anti-replay Extended Sequence Number (ESN) state";
}
}
/*################## end SAD grouping ##################*/ /*################## end SAD grouping ##################*/
/*################## SPD grouping ####################*/ /*################## SPD grouping ####################*/
grouping ipsec-policy-grouping { grouping ipsec-policy-grouping {
description "Holds configuration information for an IPSec SPD entry."; description "Holds configuration information for an IPSec SPD entry.";
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. ";
}
leaf priority {type uint32; default 0; description "Policy priority";}
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";
}
container condition {
description "SPD condition -> RFC4301";
list traffic-selector-list {
key "ts-number";
leaf ts-number { type uint32; description "Traffic selector number"; } 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. "; }
leaf direction { type ipsec-traffic-direction; description "in/fwd/out"; } leaf priority {type uint32; default 0; description "Policy priority";}
uses selector-grouping; list names {
leaf selector-priority {type uint32; default 0; description "It establishes a priority to the traffic selector";} key "name";
ordered-by user; leaf name-type { type ipsec-spd-name; description "SPD name type."; }
leaf name { type string; description "Policy name"; }
description "List of policy names";
}
description "List of traffic selectors"; container condition {
description "SPD condition -&gt; 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/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 { container processing-info {
description "SPD processing -> RFC4301"; 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";} 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 ipsec-sa-cfg {
when "../action = 'PROTECT'"; when "../action = 'PROTECT'";
leaf pfp-flag { type boolean; description "Each selector has with a pfp flag."; }
leaf extSeqNum { type boolean; description "TRUE 64 bit counter, FALSE 32 bit"; }
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"; }
leaf pfp-flag { type boolean; description "Each selector has with a pfp flag."; } container ah-algorithms {
leaf extSeqNum { type boolean; description "TRUE 64 bit counter, FALSE 32 bit"; } when "../security-protocol = 'ah'";
leaf seqOverflow { type boolean; description "TRUE rekey, FALSE terminare & audit"; } leaf-list ah-algorithm { type integrity-algorithm-t; description "Configure Authentication Header (AH)."; }
leaf statefulfragCheck { type boolean; description "TRUE stateful fragment checking, FALSE no stateful fragment checking"; } description "AH algoritms ";
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 esp-algorithms {
when "../security-protocol = 'ah'"; when "../security-protocol = 'esp'";
leaf-list ah-algorithm { description "Configure Encapsulating Security Payload (ESP).";
type integrity-algorithm-t; leaf-list authentication { type integrity-algorithm-t; description "Configure ESP authentication"; }
description "Configure Authentication Header (AH)."; leaf-list encryption { type encryption-algorithm-t; description "Configure ESP encryption"; }
} }
description "AH algoritms ";
}
container esp-algorithms { container tunnel {
when "../security-protocol = 'esp'"; when "../mode = 'TUNNEL'";
description "Configure Encapsulating Security Payload (ESP)."; uses tunnel-grouping;
leaf-list authentication { type integrity-algorithm-t; description "Configure ESP authentication"; } description "tunnel grouping container";
leaf-list encryption { type encryption-algorithm-t; description "Configure ESP encryption"; } }
} description " IPSec SA configuration container";
container tunnel { }
when "../mode = 'TUNNEL'";
uses tunnel-grouping;
description "tunnel grouping container";
}
description " IPSec SA configuration container";
} }
}
container spd-lifetime {
description "SPD lifetime parameters";
leaf time-soft { type uint32; default 0; description "Soft time lifetime";}
leaf time-hard { type uint32; default 0; description "Hard time lifetime";}
leaf time-use-soft { type uint32; default 0; description "Use soft lifetime";}
leaf time-use-hard { type uint32; default 0; description "Use hard lifetime";}
leaf byte-soft { type uint32; default 0; description "Byte soft lifetime";}
leaf byte-hard { type uint32; default 0; description "Hard soft lifetime";}
leaf packet-soft {type uint32; default 0; description "Packet soft lifetime";}
leaf packet-hard { type uint32; default 0; description "Packet hard lifetime";}
}
}/* grouping ipsec-policy-grouping */
/*################ end SPD grouping ##################*/ container spd-mark {
description "policy: mark MARK mask MASK ";
leaf mark { type uint32; default 0; description "mark value";}
leaf mask { type yang:hex-string; default 00:00:00:00; description "mask value 0x00000000";}
}
/*################## IKEv2-grouping ##################*/ container spd-lifetime-hard {
description "SPD lifetime hard state data";
uses lifetime;
leaf action {type lifetime-action; description "action lifetime";}
}
grouping isakmp-proposal { container spd-lifetime-soft {
description "ISAKMP proposal grouping"; description "SPD lifetime hard state data";
leaf phase1-lifetime { uses lifetime;
type uint32; leaf action {type lifetime-action; description "action lifetime";}
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).";} // State data
container spd-lifetime-current {
uses lifetime;
config false;
description "SPD lifetime current state data";
}
leaf dh_group { } /* grouping ipsec-policy-grouping */
type uint32;
mandatory true;
description "Group number for Diffie Hellman Exponentiation";
}
} /* list isakmp-proposal */
grouping phase2-info { /*################ end SPD grouping ##################*/
description "IKE Phase 2 Information";
leaf-list pfs_group { /*################## IKEv2-grouping ##################*/
type uint32;
description
"If non-zero, require perfect forward secrecy
when requesting new SA. The non-zero value is
the required group number";
}
} grouping isakmp-proposal {
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 local-grouping { grouping phase2-info {
description "Configure the local peer in an IKE connection"; 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"; }
}
grouping local-grouping {
description "Configure the local peer in an IKE connection";
container local { container local {
description "Local container"; description "Local container";
choice my-identifier-type { choice my-identifier-type {
default ipv4; default ipv4;
case ipv4 { case ipv4 {
leaf ipv4 { leaf ipv4 { type inet:ipv4-address; description "IPv4 dotted-decimal address"; }
type inet:ipv4-address; }
description "IPv4 dotted-decimal address"; case ipv6 {
} leaf ipv6 { type inet:ipv6-address; description "numerical IPv6 address"; }
} }
case ipv6 { case fqdn {
leaf ipv6 { leaf fqdn { type inet:domain-name; description "Fully Qualifed Domain name "; }
type inet:ipv6-address; }
description "numerical IPv6 address"; case dn {
} leaf dn { type string; description "Domain name"; }
} }
case fqdn { case user_fqdn {
leaf fqdn { leaf user_fqdn { type string; description "User 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"; description "Local ID type";
} }
leaf my-identifier { leaf my-identifier { type string; mandatory true; description "Local id used for authentication";}
type string;
mandatory true;
description "Local id used for authentication";
}
}
}
grouping remote-grouping {
description "Configure the remote peer in an IKE connection";
container remote {
description "Remote container";
choice my-identifier-type {
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";
}
} }
} } // local-grouping
/*################## End IKEv2-groupingUMU ##################*/ grouping remote-grouping {
description "Configure the remote peer in an IKE connection";
/*################# Register grouping #################*/ container remote {
description "Remote container";
choice my-identifier-type {
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
typedef sadb-msg-type { /*################## End IKEv2-groupingUMU ##################*/
type enumeration { /*################# Register grouping #################*/
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 { typedef sadb-msg-type {
type enumeration { type enumeration {
enum sadb_satype_unspec { description "SADB_SATYPE_UNSPEC"; } enum sadb_reserved { description "SADB_RESERVED";}
enum sadb_satype_ah { description "SADB_SATYPE_AH"; } enum sadb_getspi { description "SADB_GETSPI";}
enum sadb_satype_esp { description "SADB_SATYPE_ESP"; } enum sadb_update { description "SADB_UPDATE";}
enum sadb_satype_rsvp { description "SADB_SATYPE_RSVP"; } enum sadb_add { description "SADB_ADD";}
enum sadb_satype_ospfv2 { description "SADB_SATYPE_OSPFv2"; } enum sadb_delete { description "SADB_DELETE"; }
enum sadb_satype_ripv2 { description "SADB_SATYPE_RIPv2"; } enum sadb_get { description "SADB_GET"; }
enum sadb_satype_mip { description "SADB_SATYPE_MIP"; } enum sadb_acquire { description "SADB_ACQUIRE"; }
enum sadb_satype_max { description "SADB_SATYPE_MAX"; } enum sadb_register { description "SADB_REGISTER"; }
} enum sadb_expire { description "SADB_EXPIRE"; }
description "PF_KEY Security Association types"; 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";
}
grouping base-grouping { typedef sadb-msg-satype {
description "Configuration for the message header format";
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 { type enumeration {
description "List of supported authentication and encryptation algorithms"; enum sadb_satype_unspec { description "SADB_SATYPE_UNSPEC"; }
list algorithm-supported{ enum sadb_satype_ah { description "SADB_SATYPE_AH"; }
container authentication { enum sadb_satype_esp { description "SADB_SATYPE_ESP"; }
description "Authentication algorithm supported"; enum sadb_satype_rsvp { description "SADB_SATYPE_RSVP"; }
leaf name { type integrity-algorithm-t; description "Name of authentication algorithm"; } enum sadb_satype_ospfv2 { description "SADB_SATYPE_OSPFv2"; }
leaf ivlen { type uint8; description "Length of the initialization vector to be used for the algorithm"; } enum sadb_satype_ripv2 { description "SADB_SATYPE_RIPv2"; }
leaf min-bits { type uint16; description "The minimun acceptable key length, in bits"; } enum sadb_satype_mip { description "SADB_SATYPE_MIP"; }
leaf max-bits { type uint16; description "The maximun acceptable key length, in bits"; } enum sadb_satype_max { description "SADB_SATYPE_MAX"; }
} }
container encryption { description "PF_KEY Security Association types";
description "Encryptation algorithm supported"; }
leaf name { type encryption-algorithm-t; description "Name of encryption algorithm"; } grouping base-grouping {
leaf ivlen { type uint8; description "Length of the initialization vector to be used for the algorithm"; } description "Configuration for the message header format";
leaf min-bits { type uint16; description "The minimun acceptable key length, in bits"; } list base-list {
leaf max-bits { type uint16; description "The maximun acceptable key length, in bits"; } 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";
} }
description "List for a specific algorithm"; }
}
}
/*################# End Register grouping #################*/ grouping algorithm-grouping {
description "List of supported authentication and encryptation algorithms";
/*################## ipsec ##################*/ container algorithm-supported {
description "lists of encryption and authentication algorithms";
list enc-algs {
key "name";
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 ";
}
}
}
container ietf-ipsec { /*################# End Register grouping #################*/
description "Main IPsec container ";
container ikev2 { /*################## ipsec ##################*/
if-feature case1;
description "Configure the IKEv2";
container ike-connection { container ietf-ipsec {
description "IKE connections configuration"; description "Main IPsec container ";
list ike-conn-entries { container ikev2 {
key "conn-name"; if-feature case1;
description "IKE peer connetion information"; description "Configure the IKEv2";
leaf conn-name { container ike-connection {
type string; description "IKE connections configuration";
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 nat-traversal {
type boolean;
default false;
description "Enable/Disable NAT traversal";
}
container encap { list ike-conn-entries {
when "../nat-traversal = 'true'"; key "conn-name";
description "Encapsulation container"; description "IKE peer connetion information";
leaf espencap { type esp-encap; description "ESP in TCP, ESP in UDP or ESP in TLS";} leaf conn-name { type string; mandatory true; description "Name of IKE connection";}
leaf sport {type inet:port-number; description "Encapsulation source port";} 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 dport {type inet:port-number; description "Encapsulation destination port"; } leaf nat-traversal { type boolean; default false; description "Enable/Disable NAT traversal"; }
leaf oaddr {type inet:ip-address; description "Encapsulation Original Address ";}
}
leaf version { container encap {
type enumeration { when "../nat-traversal = 'true'";
/* we only support ikev2 in this version */ description "Encapsulation container";
enum ikev2 {value 2; description "IKE version 2";} 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";}
description "IKE version"; leaf dport {type inet:port-number; description "Encapsulation destination port"; }
} leaf oaddr {type inet:ip-address; description "Encapsulation Original Address ";}
}
uses isakmp-proposal; leaf version {
uses local-grouping; type enumeration {
uses remote-grouping; enum ikev2 {value 2; description "IKE version 2";}
uses phase2-info; }
description "IKE version";
}
} /* ike-conn-entries */ uses isakmp-proposal;
} /* container ike-connection */ uses local-grouping;
} /* container ikev2 */ uses remote-grouping;
uses phase2-info;
container ipsec { container ike-stats {
description "Configuration IPsec"; 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-spi {type uint64; description "Initiator's IKE SA SPI";}
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 */
container spd { } /* ike-conn-entries */
description "Configure the Security Policy Database (SPD)"; } /* container ike-connection */
list spd-entry {
key "rule-number";
uses ipsec-policy-grouping;
ordered-by user;
description "List of SPD entries";
}
}
container sad { container number-ike-sas{
if-feature case2; 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";}
list sad-entry { config false;
key "spi"; description "Number of IKE SAs";
uses ipsec-sa-grouping; }
description "List of SAD entries";
}
}
container pad { } /* container ikev2 */
if-feature case1;
description "Configure Peer Authorization Database (PAD)";
list pad-entries {
key "pad-entry-id";
ordered-by user;
description "Peer Authorization Database (PAD)";
leaf pad-entry-id { container ipsec {
type uint64; description "Configuration IPsec";
description "SAD index. ";
}
uses identity-grouping; container spd {
description "Configure the Security Policy Database (SPD)";
list spd-entry {
key "rule-number";
uses ipsec-policy-grouping;
ordered-by user;
description "List of SPD entries";
}
}
leaf pad-auth-protocol { container sad {
type auth-protocol-type;
description "IKEv1, IKEv2, KINK, etc. "; description "Configure the IPSec Security Association Database (SAD)";
} list sad-entry {
uses auth-method-grouping; key "spi";
} uses ipsec-sa-grouping;
description "List of SAD entries";
}
}
container pad {
if-feature case1;
description "Configure Peer Authorization Database (PAD)";
list pad-entries {
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 "IKEv1, IKEv2, KINK, etc. ";}
uses auth-method-grouping;
}
}
} }
}
} /* container ietf-ipsec */ } /* container ietf-ipsec */
/*########## State Data ############*/ /*################## RPC and Notifications ##################*/
// TBD /* Note: not yet completed */
// Those RPCs are needed by a Security Controller in case 2 */
/*################## RPC and Notifications ##################*/ rpc sadb_register {
description "Allows netconf to register its key socket as able to acquire new security associations for the kernel";
input {
uses base-grouping;
}
output {
uses base-grouping;
uses algorithm-grouping;
}
}
/* Note: not yet completed */ notification spdb_expire {
// Those RPCs are needed by a Security Controller in case 2 */ description "A SPD entry has expired";
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. "; }
}
rpc sadb_register { notification sadb_acquire {
description "Allows netconf to register its key socket as able to acquire new security associations for the kernel"; description "A IPsec SA is required ";
input {
uses base-grouping;
}
output {
uses base-grouping; uses base-grouping;
uses algorithm-grouping; }
}
}
notification spdb_expire {
description "A SPD entry has expired";
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. ";
}
}
notification sadb_acquire { notification sadb_expire {
description "A IPsec SA is required "; description "A IPsec SA expiration (soft or hard)";
leaf state { uses base-grouping;
type uint32; leaf spi { type ipsec-spi; description "Security Parameter Index";}
mandatory "true"; leaf anti-replay-window { type uint16 { range "0 | 32..1024"; } description "Anti replay window"; }
description leaf state {type sa-state; description "current state of SA (mature, larval, dying or dead)"; }
"Request the creation of a SADB entry";
}
}
notification sadb_expire { leaf encryption-algorithm { type encryption-algorithm-t; description "encryption algorithm of the expired SA"; }
description "....."; leaf authentication-algorithm { type integrity-algorithm-t; description "authentication algorithm of the expired SA"; }
leaf state {
type uint32;
mandatory "true";
description
"Notify the expiration of a entry in the SADB";
}
}
notification sadb_bad-spi { container sad-lifetime-hard {
description "....."; description "SAD lifetime hard state data";
leaf state { uses lifetime;
type ipsec-spi;
mandatory "true";
description "Notify when a SPI";
} }
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 {
description ".....";
leaf state { type ipsec-spi; mandatory "true"; description "Notify when a SPI"; }
}
} /*module ietf-ipsec*/ } /*module ietf-ipsec*/
<CODE ENDS> <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
 End of changes. 207 change blocks. 
1045 lines changed or deleted 1073 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/