I2NSF R. Marin-Lopez Internet-Draft G. Lopez-Millan Intended status: Standards Track University of Murcia Expires:April 25,September 12, 2019 F. Pereniguez-Garcia University Defense Center March 11, 2019October 22, 2018Software-Defined Networking (SDN)-based IPsec Flow Protectiondraft-ietf-i2nsf-sdn-ipsec-flow-protection-03draft-ietf-i2nsf-sdn-ipsec-flow-protection-04 Abstract This document describes how providing IPsec-based flow protection by means of a Software-Defined Network (SDN) controller (aka. Security Controller) and establishes the requirements to support this service. It considers two main well-known scenarios in IPsec: (i) gateway-to- gateway and (ii) host-to-host. The SDN-based service described in this document allows the distribution and monitoring of IPsec information from a Security Controller to one or several flow-based Network Security Function (NSF). The NSFs implement IPsec to protect data traffic between network resources with IPsec. The document focuses in the NSF Facing Interface by providing models for Configuration and State data model required to allow the Security Controller to configure the IPsec databases (SPD, SAD, PAD) and IKEv2 to establish security associations with a reduced intervention of the network administrator. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire onApril 25,September 12, 2019. Copyright Notice Copyright (c)20182019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . .54 4. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. SDN-based IPsec management description . . . . . . . . . . . 6 5.1.Case 1:IKE case: IKE/IPsec in the NSF . . . . . . . . . . . . ..6 5.1.1. Interface Requirements forCase 1 .IKE case . . . . . . . . . 7 5.2.Case 2:IKE-less case: IPsec (no IKEv2) in the NSF . . . . . . .. . . . 78 5.2.1. Interface Requirements forCase 2 . . . .IKE-less case . . . . . . 8 5.3.Case 1IKE case vsCase 2 . . . .IKE-less case . . . . . . . . . . . . . . . .89 5.3.1. Rekeying process . . . . . . . . . . . . . . . . . .910 5.3.2. NSF state loss . . . . . . . . . . . . . . . . . . .1011 5.3.3. NAT Traversal . . . . . . . . . . . . . . . . . . . .1012 6. YANG configuration data models . . . . . . . . . . . . . . .1112 6.1.Security Policy Database (SPD) ModelIKE case model . . . . . . . . . .11 6.2. Security Association Database (SAD) Model. . . . . . . .13 6.3. Peer Authorization Database (PAD) Model. . . 13 6.2. IKE-less case model . . . . . . . .16 6.4. Internet Key Exchange (IKEv2) Model. . . . . . . . . . .1716 7. Use cases examples . . . . . . . . . . . . . . . . . . . . .1921 7.1.Host-to-HostHost-to-host orGateway-to-gatewaygateway-to-gateway under the same controller . . . . . . . . . . . . . . . . . . . . . . .1921 7.2.Host-to-HostHost-to-host orGateway-to-gatewaygateway-to-gateway under differentSecuritysecurity controllers . . . . . . . . . . . . . . . . . .2223 8.Implementation notesSecurity Considerations . . . . . . . . . . . . . . . . . . . 25 8.1. IKE case . .24 9. Security Considerations. . . . . . . . . . . . . . . . . . .25 9.1. Case 1. . . 26 8.2. IKE-less case . . . . . . . . . . . . . . . . . . . . . . 269.2. Case 29. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 10. References . . .26 10. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . 2711.10.1. Normative References . . . . . . . . . . . . . . . . . . 27 10.2. Informative References . . . . . . . . .27 11.1. Normative References. . . . . . . . 28 Appendix A. Appendix A: Common YANG model for IKE and IKEless cases . . . . . . . . . . . . .27 11.2. Informative References. . . . . . . . . . 31 Appendix B. Appendix B: YANG model for IKE case . . . . . . .27. 37 AppendixA.C. AppendixA:C: YANG modelIPsec Configuration datafor IKE-less case . . . .30. . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .4849 1. Introduction Software-Defined Networking (SDN) is an architecture that enables users to directly program, orchestrate, control and manage network resources through software. SDN paradigm relocates the control of network resources to a dedicated network element, namely SDN controller. The SDN controller manages and configures the distributed network resources and provides an abstracted view of the network resources to the SDN applications. The SDN application can customize and automate the operations (including management) of the abstracted network resources in a programmable manner via this interface [RFC7149][ITU-T.Y.3300] [ONF-SDN-Architecture][ONF-OpenFlow].Typically, traditional IPsec VPN concentrators and, in general, entities (i.e. hosts or security gateways) supporting IKE/IPsec, must be configured directly by the administrator. This makes the IPsec security association (SA) management difficult and generatesRecently, several network scenarios are considering alack of flexibility, specially if the numbercentralized way of managing different securitypolicies and SAsaspects. For example, Software- Defined WANs (SD-WAN) advocates tohandle is high. Withmanage IPsec SAs from a centralized point. Therefore, with the growth of SDN-based scenarios where network resources are deployed in an autonomous manner, a mechanism to manage IPsec SAs according to the SDN architecture becomes more relevant. Thus, the SDN-based service described in this document will autonomously deal with IPsec SAsmanagement.management following a SDN paradigm. An example of usage can be the notion of Software Defined WAN (SD- WAN), SDN extension providing a software abstraction to create secure network overlays over traditional WAN and branch networks. SD-WAN is based on IPsec as underlying security protocol and aims to provide flexible, automated, fast deployment and on-demand security network services. IPsec architecture [RFC4301] defines a clear separation between the processing to provide security services to IP packets and the key management procedures to establish the IPsec security associations. In this document, we define a service where the key management procedures can be carried by an external entity: the Security Controller. First, this document exposes the requirements to support the protection of data flows using IPsec [RFC4301]. We have considered two general cases: 1) IKE case. The Network Security Function (NSF) implements the Internet Key Exchange (IKE) protocol and the IPsec databases: the Security Policy Database (SPD), the Security Association Database (SAD) and the Peer Authorization Database (PAD). The Security Controller is in charge of provisioning the NSF with the required information to IKE, the SPD and the PAD. 2) IKE-less case. The NSF only implements the IPsec databases (no IKE implementation). The Security Controller will provide the required parameters to create valid entries in the SPD and the SAD into the NSF. Therefore, the NSF will have only support for IPsec while automated key management functionality is moved to the controller. In both cases, an interface/protocol is required to carry out this provisioning in a secure manner between the Security Controller and the NSF. In particular,Case 1IKE case requires the provision of SPD and PAD entries and the IKE credential and information related with the IKE negotiation (e.g.IKE_SA_INIT);IKE_SA_INIT), andCase 2IKE-less case requires the management of SPD and SAD entries. Based on YANG models in [netconf-vpn] and [I-D.tran-ipsecme-yang], RFC 4301 [RFC4301] and RFC 7296 [RFC7296] this document defines the required interfaces with a YANG model for configuration and state data for IKE, PAD, SPD and SAD (see AppendixA.A, Appendix B and Appendix C). This document considers two typical scenarios to manage autonomously IPsec SAs: gateway-to-gateway and host-to-host [RFC6071]. The analysis of the host-to-gateway (roadwarrior) scenario isTBD.out of scope of this document. In 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 two different Security Controllers. NOTE: This work pays attention to the challenge "Lack of Mechanism for Dynamic Key Distribution to NSFs" defined in[I-D.ietf-i2nsf-problem-and-use-cases][RFC8192] in the particular case of the establishment and management of IPsec SAs. In fact, this I-D could be considered as a proper use case for this particular challenge in[I-D.ietf-i2nsf-problem-and-use-cases].[RFC8192]. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. When these words appear in lower case, they have their natural language meaning. 3. Terminology This document uses the terminology described in [RFC7149], [RFC4301], [ITU-T.Y.3300], [ONF-SDN-Architecture], [ONF-OpenFlow], [ITU-T.X.1252], [ITU-T.X.800] and [I-D.ietf-i2nsf-terminology]. In addition, the following terms are defined below: o Software-Defined Networking. A set of techniques enabling to directly program, orchestrate, control, and manage network resources, which facilitates the design, delivery and operation of network services in a dynamic and scalable manner [ITU-T.Y.3300]. o Flow/Data Flow. Set of network packets sharing a set of characteristics, for example IP dst/src values or QoS parameters. o Security Controller. A Controller is a managementComponentcomponent that contains control plane functions to manage and facilitate information sharing, as well as execute security functions. In the context of this document, it provides IPsec management information. o Network Security Function (NSF). Software that provides a set of security-related services. o Flow-based NSF. A NSF that inspects network flows according to a set of policies intended for enforcing security properties. The NSFs considered in this document falls into this classification. o Flow-based Protection Policy. The set of rules defining the conditions under which a data flow MUST be protected with IPsec, and the rules that MUST be applied to the specific flow. o Internet Key Exchange (IKE) v2 Protocol to establish IPsec Security Associations (SAs). It requires information about the required authentication method (i.e.preshared keys),raw RSA/ECDSA keys or X.509 certificates), DH groups, modes and algorithms for IKE SA negotiation, etc. o Security Policy Database (SPD). It includes information about IPsec policies direction (in, out), local and remote addresses, inbound and outboud SAs, etc. o Security Associations Database (SAD). It includes information about IPsec SAs, such as SPI, destination addresses, authentication and encryption algorithms and keys to protect IPflow.flows. o Peer Authorization Database (PAD). It provides the link between the SPD and a security association management protocol such as IKE or the SDN-based solution described in this document. 4. Objectives o To describe the architecture for the SDN-based IPsec management, which implements a security service to allow the establishment and management of IPsec security associations from a centralpointpoint, in order to protect specific data flows. o To define the interfaces required to manage and monitor the IPsec Security Associations in the NSF from a Security Controller. YANG models are defined for configuration and state data for IPsec management. 5. SDN-based IPsec management description As mentioned in Section 1, two cases are considered: 5.1.Case 1:IKE case: IKE/IPsec in the NSF In this case the NSF ships an IKEv2 implementation besides the IPsec support. The Security Controller is in charge of managing and applying SPD and PAD entries (deriving and delivering IKE Credentials such as a pre-shared key, certificates, etc.), and applying other IKE configuration parameters (e.g. IKE_SA_INIT algorithms) to the NSF for the IKE negotiation. With these entries, the IKEv2 implementation can operate to establish the IPsec SAs. The application (administrator) establishes the IPsec requirements and information about the end points information (through the Client FacingInterface),Interface, [RFC8192]), and the Security Controller translates those requirements into IKE, SPD and PAD entries that will be installed into the NSF (through the NSF Facing Interface). With that information, the NSF can just run IKEv2 to establish the required IPsec SA (when the data flow needs protection). Figure 1 shows the different layers and corresponding functionality.+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-------------------------------------------+ |IPsec Management/Orchestration Application | Client or | I2NSF Client | App Gateway+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-------------------------------------------+ | Client Facing Interface+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-------------------------------------------+ Vendor | Application Support |Facing<->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Facing<->|-------------------------------------------| Security Interface| IKE Credential,PAD and SPD entries Distr. | Controller+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-------------------------------------------+ | NSF Facing Interface+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-------------------------------------------+ | I2NSF Agent |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|-------------------------------------------| Network | IKE | IPsec(SPD,PAD) | Security+-------------------------------------------+|-------------------------------------------| Function | Data Protection and Forwarding |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-------------------------------------------+ Figure 1:Case 1:IKE case: IKE/IPsec in the NSF 5.1.1. Interface Requirements forCase 1IKE case SDN-based IPsec flow protection services provide dynamic and flexible management of IPsec SAs in flow-based NSF. In order to support this capability in case1,IKE case, the following interface requirements are to be met: o A YANG data model forConfigurationconfiguration data for IKEv2, SPD and PAD. o A YANG data model forStatestate data for IKE,SPD, PADPAD, SPD and SAD (NOTE: the SAD entries are created in runtime by IKEv2.) o In scenarios where multiple controllers are implicated, SDN-based IPsec management services may require a mechanism to discover which Security Controller is managing a specific NSF. Moreover, an east-west interface [RFC7426] is required to exchangeIPsec-relatedIPsec- related information. For example, if two gateways need to establish an IPsec SA and both are under the control of two different controllers then both Security Controllers need to exchange information to properly configure their own gateways. That is, the may need to agree on whether IKEv2 authentication will be based on raw public keys or pre-shared keys. In case of using pre-shared keys they will have to agree in the PSK. 5.2.Case 2:IKE-less case: IPsec (no IKEv2) in the NSF In this case, the NSF does not deploy IKEv2 and, therefore, the Security Controller has to perform the IKE security functions and management of IPsec SAs by populating andmonitoringmanaging the SPD and the SAD.+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-----------------------------------------+ | IPsec Management Application | Client or | I2NSF Client | App Gateway+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-----------------------------------------+ | Client Facing Interface+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-----------------------------------------+ Vendor| Application Support |Facing<->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Facing<->|-----------------------------------------| Security Interface| SPD, SAD and PAD Entries Distr. | Controller+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-----------------------------------------+ | NSF Facing Interface+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-----------------------------------------+ | I2NSF Agent | Network+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|-----------------------------------------| Security | IPsec (SPD,SAD) | Function (NSF)+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|-----------------------------------------| | Data Protection and Forwarding | +-----------------------------------------+ Figure 2:Case 2:IKE-less case: IPsec (no IKE) in the NSF As shown in Figure 2, applications for flow protection run on the top of the Security Controller. When an administrator enforces flow- based protection policies through the Client Facing Interface, the Security Controller translates those requirements into SPD and SAD entries, which are installed in the NSF. PAD entries are not required since there is no IKEv2 in the NSF. 5.2.1. Interface Requirements forCase 2IKE-less case In order to supportcase 2,the IKE-less case, the following requirements are to be met: o A YANG data model forConfigurationconfiguration data for SPD and SAD. o A YANG data model forStatestate data for SPD and SAD. o In scenarios where multiple controllers are implicated, SDN-based IPsec management services may require a mechanism to discover which Security Controller is managing a specific NSF. Moreover, an east-west interface [RFC7426] is required to exchangeIPsec-relatedIPsec- related information. NOTE: A possible east-west protocol for this IKE-less case could be IKEv2. However, this needs to be explore since the IKEv2 peers would be the Security Controllers. Specifically, the IKE-less case assumes that the SDN controller has to perform some security functions that IKEv2 typically does, namely (non-exhaustive): o IV generation. o prevent counter resets for same key. o Generation of pseudo-random cryptographic keys for the IPsec SAs. o Rekey of the IPsec SAs based on notification from the NSF (i.e. expire). o Generation of the IPsec SAs when required based on notifications (i.e. sadb_acquire). o NAT Traversal discovery and management. Additionally to these functions, another set of tasks must be performed by the Controller (non-exhaustive list): o SPI random generation. o Cryptographic algorithm/s selection. o Usage of extended sequence numbers. o Establishment of proper traffic selectors. 5.3.Case 1IKE case vsCase 2 Case 1IKE-less case IKE case MAY be easier to deploy thanCase 2IKE-less case because current gateways typically have an IKEv2/IPsec implementation. Moreover hosts can install easily an IKE implementation. As downside, the NSF needs more resources to hold IKEv2. Moreover, the IKEv2 implementation needs to implement an interface so that the I2NSF Agent can interact with them. Alternatively,Case 2IKE-less case allows lighter NSFs (no IKEv2 implementation), which benefits the deployment in constrained NSFs. Moreover, IKEv2 does not need to be performed in gateway-to-gateway and host-to-host scenarios under the same Security Controller (see Section 7.1). On the contrary, the overload of creating fresh IPsec SAs is shifted to the Security Controller since IKEv2 is not in the NSF. As a consequence, this may result in a more complex implementation in the controller side.5.3.1. Rekeying process For case 1, the rekeying process is carried out by IKEv2, following the configuration defined in the SPD. For case 2,This overload may create some scalability issues when theSecurity Controller needs to take carenumber of NSFs is high. In general, literature around SDN-based network management using a centralized SDN controller is aware about scalability issues and solutions have been already provided (e.g. hierarchical SDN controllers; having multiple replicated SDN controllers, etc). In the context of IPsec management, one straight way to reduce the overhead and the potential scalability issue in the Security Controller is to apply IKE case, described in this document, since the IPsec SAs are managed between NSFs without the involvement of the Security Controller at all, except by the initial IKE configuration provided by the Security Controller. Other option with IKE-less is to use techniques already seen in SDN world such as, for example, hierarchical SDN controllers. Other solutions, such as Controller- IKE [I-D.carrel-ipsecme-controller-ike], have proposed that NSFs provide their DH public keys to the Security Controller, so that the Security Controller distributes all public keys to all peers. All peers can calculate a unique pairwise secret for each other peer and there is no inter-NSF messages. A re-key mechanism is further described in [I-D.carrel-ipsecme-controller-ike]. In terms of security, IKE case provides better security properties than IKE-less case, as we discuss in section Section 8. The main reason is that the Security Controller is not able to observe any session keys generated for the IPsec SAs because IKEv2 is in charge of negotiating the IPsec SAs. 5.3.1. Rekeying process For IKE case, the rekeying process is carried out by IKEv2, following the information defined in the SPD and SAD. For IKE-less case, the Security Controller needs to take care of the rekeying process. When the IPsec SA is going to expire (e.g. IPsec SA soft lifetime), it has to create a new IPsec SA and remove the old one. This rekeying process starts when the Security Controller receives a sadb_expire notification or it decides so, based on lifetime state data obtained from the NSF. To explain the rekeying process between two IPsec peers A and B, let assume that SPIa1 identifies the inbound SA in A and SPIb1 the inbound SA in B. 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,theThen, the Security Controller creates an inbound SA with SPIa2 in A and another inbound SA in B with SPIb2. It can send this informationsimultenouslysimultaneously 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.TheOnce the Security Controller receives confirmation from A and B, that the outbound SAs have been installed, 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 allIt is worth noting that if the IPsecstate (affected NSF). By default,implementation can itself detect traffic on the new IPsec SA, and it can delete the old IPsec SA itself without instruction from the Security Controller, then this step 3 is not required. 5.3.2. NSF state loss If one of the NSF restarts, it will lose 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 incase 1IKE case, and SPD and SAD information incase 2.IKE-less case. In both cases, the Security ControllerMUST beis aware of the affected NSF (e.g. the NETCONF/TCP connection is broken with the affected NSF,itthe Security Controller is receivingbad_spisadb_bad-spi notification from a particular NSF,etc...).etc.). Moreover, the Security ControllerMUST havehas a register about all the NSFs that have IPsec SAs with the affected NSF. Therefore, it knows the affected IPsec SAs. InCase 1,IKE case, the Security Controller will configure the affected NSF with the new IKEv2, SPD and PAD information. It has also to send new parameters (e.g. a new freshPSK)PSK for authentication) to the NSFs which have IKEv2 SAs and IPsec SAs with the affected NSF. It can also instruct the affected NSF to send IKEv2INITIAL_CONTACT (It is TBD in the model).INITIAL_CONTACT. Finally, the Security Controller will instruct the affected NSF to start the IKEv2 negotiation with the new configuration. InCase 2,IKE-less case, if the Security Controller detects that a NSF has lost the IPsec SAs (e.g. it reboots) it willfollow similar stepsdelete the old IPsec SAs of the non-failed nodes established with the failed node (step 1). This prevents the non-failed nodes from leaking plaintext. If the failed node comes torekey:live, thesteps 1Security Controller will configure the new inbound IPsec SAs between the failed node and2 remain equal butall thestep 3 will be slightly different. For example, if we assume that NSF B has lost its state,nodes the failed was talking to (step 2). After these inbound IPsec SAs have been established, the Security ControllerMUST only deletecan configure theoldoutbound IPsec SAsfrom A in step 3.(step 3). Nevertheless other more optimized options can be considered (e.g. makingiKEv2IKEv2 configuration permanent between reboots). 5.3.3. NAT Traversal Incase 1,IKE case, IKEv2 already owns a mechanism to detect whether some of the peers or both are located behind a NAT. If there is a NAT network configured between two peers, it is required to activate the usage of UDP or TCP/TLS encapsulation of ESP packets ([RFC3948],[RFC8229])[RFC8229]). Note that the usage of TRANSPORT mode when NAT is required is forbidden in this specification. On the contrary, IKE-less case2does not have any protocol in the NSFs to detect whether they are located 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, and apply the required policies to both NSFs besides activating the usage of UDP or TCP/TLS encapsulation of ESP packets ([RFC3948], [RFC8229]). For example, the Security Controller could directly request the NSF 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][I-D.ietf-opsawg-nat-yang] a data model for NAT management. The Security Controller can use this NETCONF module with a gateway to collect NAT information or even configure a NAT. In any case, if this NETCONF module is not available and the Security Controller cannot know if a host is behind a NAT or not, then IKE case should be the right choice and not the IKE-less. 6. YANG configuration data models In order to support IKE case1and IKE-less case2we have modelled the different parameters and values that must be configured to manage IPsec SAs. Specifically,case 1IKE requiresmodellingmodeling IKEv2, SPD and PAD while IKE-less case2requires configuration models for the SPD and SAD.A single YANG file represents both cases though some part of the models are selectively activated depending a featureWe have definedin the YANG file. For example, thethree models: ietf-ipsec-common (Appendix A), ietf-ipsec-ike (Appendix B, IKEconfiguration is not enabled in case 2. Incase), ietf-ipsec-ikeless (Appendix C, IKE-less case). Since thefollowing,model ietf-ipsec-common has only typedef and groupings common to the other modules, in the following wesummarize, by usingonly show atree representation,simplified view of thedifferent configurationietf-ipsec-ike andstate dataietf-ipsec-ikeless models. 6.1. IKE case model Thecomplete YANG configuration datamodelisrelated to IKEv2 has been extracted from reading IKEv2 standard inAppendix A 6.1. Security Policy Database (SPD) Model[RFC7296], and observing some open source implementations, such as Strongswan or Libreswan. The definition ofthisthe PAD model has been extracted from the specification in section4.4.1 and Appendix D4.4.3 in [RFC4301] (NOTE: We have observed that many implementations integrate PAD configuration as part of the IKEv2 configuration.) module: ietf-ipsec-ike +--rwspdikev2 +--rw pad | +--rwspd-entry* [rule-number]pad-entry* [pad-entry-id] | +--rwrule-numberpad-entry-id uint64 | +--rwpriority? uint32(identity)? |+--rw names* [name]| +--:(ipv4-address) |+--rw name-type? ipsec-spd-name| | +--rwname stringipv4-address? inet:ipv4-address |+--rw condition| +--:(ipv6-address) |+--rw traffic-selector-list* [ts-number]| | +--rwts-number uint32ipv6-address? inet:ipv6-address | |+--rw direction? ipsec-traffic-direction+--:(fqdn-string) | | | +--rwlocal-addresses* [start end]fqdn-string? inet:domain-name | | +--:(rfc822-address-string) | | | +--rwstart inet:ip-addressrfc822-address-string? string | | +--:(dnX509) |+--rw end inet:ip-address| | +--rwremote-addresses* [start end]dnX509? string | | +--:(id_key) | | | +--rwstart inet:ip-addressid_key? string | | +--:(id_null) | | | +--rwend inet:ip-addressid_null? empty | | +--:(user_fqdn) | | +--rwnext-layer-protocol* ipsec-next-layer-protouser_fqdn? string | +--rw my-identifier string | +--rwlocal-ports* [start end]pad-auth-protocol? auth-protocol-type | +--rw auth-method | +--rw auth-m? auth-method-type | +--rwstart inet:port-numbereap-method | | +--rw eap-type? uint8 | +--rwend inet:port-numberpre-shared | | +--rwremote-ports* [start end]secret? yang:hex-string | +--rw digital-signature | +--rw ds-algorithm? signature-algorithm-t | +--rwstart inet:port-numberraw-public-key? yang:hex-string | +--rw key-data? string | +--rw key-file? string | +--rwend inet:port-numberca-data* string | +--rw ca-file? string | +--rwselector-priority? uint32cert-data? string | +--rwprocessing-infocert-file? string | +--rw crl-data? string | +--rwaction ipsec-spd-operationcrl-file? string | +--rw oscp-uri? inet:uri +--rw ike-conn-entry* [conn-name] | +--rwipsec-sa-cfgconn-name string | +--rw autostartup type-autostartup | +--rwpfp-flag?initial-contact? boolean | +--rw version? enumeration | +--rwextSeqNum?ike-fragmentation? boolean ||+--rwseqOverflow? booleanike-sa-lifetime-hard | | +--rwstatefulfragCheck? booleantime? yang:timestamp | | +--rwsecurity-protocol? ipsec-protocolidle? yang:timestamp | | +--rwmode? ipsec-modebytes? uint32 | | +--rwah-algorithmspackets? uint32 | +--rw ike-sa-lifetime-soft | | +--rwah-algorithm* integrity-algorithm-ttime? yang:timestamp | | +--rwesp-algorithms |idle? yang:timestamp | | +--rwauthentication* integrity-algorithm-t |bytes? uint32 | | +--rwencryption* encryption-algorithm-tpackets? uint32 | | +--rwtunnelaction? ic:lifetime-action | +--rw ike-sa-authalg* ic:integrity-algorithm-t | +--rwlocal? inet:ip-addressike-sa-encalg* ic:encryption-algorithm-t | +--rw dh_group uint32 | +--rwremote? inet:ip-addresshalf-open-ike-sa-timer? uint32 | +--rw half-open-ike-sa-cookie-threshold? uint32 | +--rwbypass-df? booleanlocal | | +--rwbypass-dscp? boolean |local-pad-id? uint64 | +--rwdscp-mapping? yang:hex-stringremote | | +--rwecn? booleanremote-pad-id? uint64 | +--rwspd-mark |espencap? esp-encap | +--rwmark? uint32sport? inet:port-number | +--rw dport? inet:port-number | +--rwmask? yang:hex-stringoaddr* inet:ip-address | +--rwspd-lifetime-hardspd | | +--rwadded? uint64spd-entry* [spd-entry-id] | | +--rwused?spd-entry-id uint64 | | +--rwbytes?priority? uint32 | | +--rwpackets? uint32 |anti-replay-window? uint16 |+--rw action? lifetime-action| +--rwspd-lifetime-soft |names* [name] |+--rw added? uint64| | +--rwused? uint64 |name-type? ipsec-spd-name |+--rw bytes? uint32| | +--rwpackets? uint32name string | | +--rwaction? lifetime-action | +--ro spd-lifetime-current | +--ro added? uint64condition |+--ro used? uint64|+--ro bytes? uint32|+--ro packets? uint32 6.2. Security Association Database (SAD) Model The definition of this model has been extracted from the specification in section 4.4.2 in [RFC4301]+--rwsadtraffic-selector-list* [ts-number] |+--rw sad-entry* [spi]|+--rw spi ipsec-spi| +--rwseq-number? uint64ts-number uint32 |+--rw seq-number-overflow-flag? boolean|+--rw anti-replay-window? uint16| +--rwrule-number? uint32direction? ipsec-traffic-direction |+--rw local-addresses* [start end]| | +--rwstart inet:ip-addresslocal-subnet? inet:ip-prefix | |+--rw end inet:ip-address| +--rwremote-addresses* [start end] |remote-subnet? inet:ip-prefix |+--rw start inet:ip-address| | +--rwend inet:ip-addressupper-layer-protocol* ipsec-upper-layer-proto | |+--rw next-layer-protocol* ipsec-next-layer-proto| +--rw local-ports* [start end] | | | | +--rw start inet:port-number | | | | +--rw end inet:port-number | | | +--rw remote-ports* [start end] | | | +--rw start inet:port-number | | | +--rw end inet:port-number |+--rw security-protocol? ipsec-protocol | +--rw ah-sa || +--rwintegrity |processing-info |+--rw integrity-algorithm? integrity-algorithm-t| | +--rwkey? stringaction ipsec-spd-operation |+--rw esp-sa| | +--rwencryptionipsec-sa-cfg | | | +--rwencryption-algorithm? encryption-algorithm-tpfp-flag? boolean | | | +--rwkey? stringextSeqNum? boolean | | | +--rwiv? stringseqOverflow? boolean | | | +--rwintegritystatefulfragCheck? boolean | | | +--rwintegrity-algorithm? integrity-algorithm-tsecurity-protocol? ipsec-protocol | | | +--rwkey? stringmode? ipsec-mode | |+--rw combined-enc-intr? boolean| +--rwsad-lifetime-hardah-algorithms | |+--rw added? uint64| | +--rwused? uint64ah-algorithm* integrity-algorithm-t | |+--rw bytes? uint32| | +--rwpackets?trunc-length? uint32 | |+--rw action? lifetime-action| +--rwsad-lifetime-softesp-algorithms | |+--rw added? uint64| | +--rwused? uint64authentication* integrity-algorithm-t | |+--rw bytes? uint32| | +--rwpackets? uint32encryption* encryption-algorithm-t | |+--rw action? lifetime-action|+--rw mode? ipsec-mode| +--rwstatefulfragCheck? booleantfc_pad? uint32 |+--rw dscp? yang:hex-string|+--rw path-mtu? uint16| +--rw tunnel | | | +--rw local? inet:ip-address | | | +--rw remote? inet:ip-address | | | +--rw bypass-df? boolean | | | +--rw bypass-dscp? boolean | | | +--rw dscp-mapping? yang:hex-string | | | +--rw ecn? boolean | | +--rwencapspd-lifetime-soft | | | +--rwespencap? esp-encaptime? yang:timestamp | | | +--rwsport? inet:port-numberidle? yang:timestamp | | | +--rwdport? inet:port-number | | +--rw oaddr? inet:ip-address | +--ro sad-lifetime-current | | +--ro added? uint64 | | +--ro used? uint64 | | +--robytes? uint32 | |+--ro| +--rw packets? uint32 |+--ro state? sa-state | +--ro stats | | +--ro replay-window? uint32| |+--ro replay? uint32+--rw action? lifetime-action | |+--ro failed? uint32+--rw spd-lifetime-hard |+--ro replay_state| |+--ro seq? uint32+--rw time? yang:timestamp | |+--ro oseq? uint32| +--rw idle? yang:timestamp |+--ro bitmap? uint32|+--ro replay_state_esn|+--ro bmp-len?+--rw bytes? uint32 |+--ro oseq? uint32|+--ro oseq-hi? uint32|+--ro seq-hi?+--rw packets? uint32 |+--ro replay-window? uint32| +--robmp* uint32 rpcs: +---x sadb_register +---w input | +---w base-list* [version] | +---w version string | +---w msg_type? sadb-msg-typespd-lifetime-current |+---w msg_satype? sadb-msg-satype|+---w msg_seq? uint32 +--ro output+--robase-list* [version]time? yang:timestamp |+--ro version string| +--romsg_type? sadb-msg-typeidle? yang:timestamp |+--ro msg_satype? sadb-msg-satype| +--romsg_seq?bytes? uint32+--ro algorithm-supported* +--ro authentication | +--ro name? integrity-algorithm-t | +--ro ivlen? uint8 | +--ro min-bits? uint16 | +--ro max-bits? uint16 +--ro encryption +--ro name? encryption-algorithm-t +--ro ivlen? uint8 +--ro min-bits? uint16 +--ro max-bits? uint16 notifications: +---n spdb_expire | +--ro index? uint64 +---n sadb_acquire | +--ro base-list* [version] | +--ro version string | +--ro msg_type? sadb-msg-type|+--ro msg_satype? sadb-msg-satype| +--romsg_seq?packets? uint32+---n sadb_expire | +--ro base-list* [version] || +--roversion string |ike-sa-state | +--romsg_type? sadb-msg-typeuptime | | +--romsg_satype? sadb-msg-satyperunning? yang:date-and-time | | +--romsg_seq? uint32since? yang:date-and-time | +--rospi? ipsec-spiinitiator? boolean | +--roanti-replay-window? uint16initiator-ikesa-spi? uint64 | +--rostate? sa-stateresponder-ikesa-spi? uint64 | +--roencryption-algorithm? encryption-algorithm-tnat-local? boolean | +--roauthentication-algorithm? integrity-algorithm-tnat-remote? boolean | +--rosad-lifetime-hard |nat-any? boolean | +--roadded? uint64 |espencap? esp-encap | +--roused? uint64 |sport? inet:port-number | +--robytes? uint32 |dport? inet:port-number | +--ropackets? uint32oaddr* inet:ip-address | +--rosad-lifetime-soft |established? uint64 | +--roadded?rekey-time? uint64 ||+--roused?reauth-time? uint64 ||+--robytes? uint32 |child-sas* [] | +--ropackets? uint32spis | +--rosad-lifetime-currentspi-in? ic:ipsec-spi | +--roadded? uint64 |spi-out? ic:ipsec-spi +--roused? uint64 |number-ike-sas +--robytes?total? uint32|+--ropackets?half-open? uint32+---n sadb_bad-spi+--rostate ipsec-spi 6.3. Peer Authorization Database (PAD) Modelhalf-open-cookies? uint32 6.2. IKE-less case model The definition ofthisthe SPD model has been mainly extracted from the specification in section4.4.34.4.1 and Appendix D in [RFC4301]. Unlike existing implementations (e.g. XFRM), it is worth mentioning that this model follows [RFC4301](NOTE: We have observedand, consequently, each policy (spd- entry) consists of one or more traffic selectors. The definition of the SAD model has been extracted from the specification in section 4.4.2 in [RFC4301]. Note thatmany implementations integrate PAD configuration as partthis model not only associates an IPsec SA with its corresponding policy (spd- entry-id) but also indicates the specific traffic selector that caused its establishment. In other words, each traffic selector of a policy (spd-entry) generates a different IPsec SA (sad-entry). The notifications model has been defined using as reference theIKEv2 configuration.) +--rw pad {case1}? +--rw pad-entries* [pad-entry-id]PF_KEYv2 standard in [RFC2367]. module: ietf-ipsec-ikeless +--rwpad-entry-id uint64ietf-ipsec +--rw(identity)? | +--:(ipv4-address) |spd | +--rwipv4-address? inet:ipv4-address | +--:(ipv6-address) |spd-entry* [spd-entry-id] | +--rwipv6-address? inet:ipv6-address | +--:(fqdn-string) |spd-entry-id uint64 | +--rwfqdn-string? inet:domain-name | +--:(rfc822-address-string) |priority? uint32 | +--rwrfc822-address-string? stringanti-replay-window? uint16 |+--:(dnX509)+--rw names* [name] | | +--rwdnX509? stringname-type? ipsec-spd-name |+--:(id_key)| +--rwid_key?name string+--rw pad-auth-protocol? auth-protocol-type +--rw auth-method +--rw auth-m? auth-method-type +--rw pre-shared| +--rwsecret? string +--rw rsa-signature +--rw key-data? string +--rw key-file? string +--rw ca-data* string +--rw ca-file? string +--rw cert-data? string +--rw cert-file? string +--rw crl-data? string +--rw crl-file? string 6.4. Internet Key Exchange (IKEv2) Model The model related to IKEv2 has been extracted from reading IKEv2 standard in [RFC7296], and observing some open source implementations, such as Strongswan or Libreswan. +--rw ikev2 {case1}?condition | | +--rwike-connectiontraffic-selector-list* [ts-number] | | +--rwike-conn-entries* [conn-name]ts-number uint32 | | +--rwconn-name stringdirection? ipsec-traffic-direction | | +--rwautostartup type-autostartuplocal-subnet? inet:ip-prefix | | +--rwnat-traversal? booleanremote-subnet? inet:ip-prefix | | +--rwinitial-contact? booleanupper-layer-protocol* ipsec-upper-layer-proto | | +--rwencaplocal-ports* [start end] | | | +--rwespencap? esp-encapstart inet:port-number | | | +--rwsport?end inet:port-number | | +--rw remote-ports* [start end] | | +--rwdport?start inet:port-number | | +--rw end inet:port-number | +--rwoaddr? inet:ip-addressprocessing-info | | +--rwversion? enumerationaction ipsec-spd-operation | | +--rwphase1-lifetime uint32ipsec-sa-cfg | | +--rwphase1-authalg* integrity-algorithm-tpfp-flag? boolean | | +--rwphase1-encalg* encryption-algorithm-textSeqNum? boolean | | +--rwcombined-enc-intr?seqOverflow? boolean | | +--rwdh_group uint32statefulfragCheck? boolean | | +--rwlocal |security-protocol? ipsec-protocol | | +--rw(my-identifier-type)? | | | | +--:(ipv4) | | |mode? ipsec-mode | | +--rwipv4? inet:ipv4-address | | | | +--:(ipv6) | |ah-algorithms | | | +--rwipv6? inet:ipv6-address | | | | +--:(fqdn) | |ah-algorithm* integrity-algorithm-t | | | +--rwfqdn? inet:domain-name | | | | +--:(dn) | | |trunc-length? uint32 | | +--rwdn? string | |esp-algorithms | |+--:(user_fqdn)| +--rw authentication* integrity-algorithm-t | | | +--rwuser_fqdn? stringencryption* encryption-algorithm-t | | | +--rwmy-identifier stringtfc_pad? uint32 | | +--rwremote |tunnel | | +--rw(my-identifier-type)? | | | | +--:(ipv4) |local? inet:ip-address | | +--rw remote? inet:ip-address | | +--rwipv4? inet:ipv4-addressbypass-df? boolean | | +--rw bypass-dscp? boolean | |+--:(ipv6)+--rw dscp-mapping? yang:hex-string | | +--rw ecn? boolean | +--rw spd-lifetime-soft | | +--rwipv6? inet:ipv6-address |time? yang:timestamp | | +--rw idle? yang:timestamp |+--:(fqdn)| +--rw bytes? uint32 | | +--rw packets? uint32 | | +--rwfqdn? inet:domain-nameaction? lifetime-action | +--rw spd-lifetime-hard | | +--rw time? yang:timestamp |+--:(dn)| +--rw idle? yang:timestamp | | +--rw bytes? uint32 | | +--rwdn? string |packets? uint32 | +--ro spd-lifetime-current | +--ro time? yang:timestamp |+--:(user_fqdn)+--ro idle? yang:timestamp | +--ro bytes? uint32 | +--ro packets? uint32 +--rw sad +--rw sad-entry* [sad-entry-id] +--rw sad-entry-id uint64 +--rw spi? ic:ipsec-spi +--rw seq-number? uint64 +--rw seq-number-overflow-flag? boolean +--rw anti-replay-window? uint16 +--rw spd-entry-id? uint64 +--rw local-subnet? inet:ip-prefix +--rw remote-subnet? inet:ip-prefix +--rw upper-layer-protocol* ipsec-upper-layer-proto +--rw local-ports* [start end] | +--rw start inet:port-number | +--rwuser_fqdn? stringend inet:port-number +--rw remote-ports* [start end] | +--rw start inet:port-number | +--rw end inet:port-number +--rw security-protocol? ic:ipsec-protocol +--rw sad-lifetime-hard | +--rwmy-identifier stringtime? yang:timestamp | +--rw idle? yang:timestamp | +--rwpfs_group*bytes? uint32 ||+--rwipsec-sad-lifetime-hard | | |packets? uint32 +--rwadded? uint64 | |sad-lifetime-soft | +--rwused? uint64 |time? yang:timestamp | +--rw idle? yang:timestamp | +--rw bytes? uint32 || |+--rw packets? uint32 || |+--rw action?lifetime-action | |ic:lifetime-action +--rw mode? ic:ipsec-mode +--rw statefulfragCheck? boolean +--rw dscp? yang:hex-string +--rw path-mtu? uint16 +--rwipsec-sad-lifetime-softtunnel | +--rw local? inet:ip-address | +--rw remote? inet:ip-address | +--rwadded? uint64bypass-df? boolean | +--rw bypass-dscp? boolean | +--rw dscp-mapping? yang:hex-string | +--rwused? uint64ecn? boolean +--rw espencap? esp-encap +--rw sport? inet:port-number +--rw dport? inet:port-number +--rw oaddr* inet:ip-address +--ro sad-lifetime-current | +--ro time? yang:timestamp | +--ro idle? yang:timestamp |+--rw+--ro bytes? uint32 || | +--rw+--ro packets? uint32| | | +--rw action? lifetime-action | |+--roike-stats |stats | +--rouptimereplay-window? uint32 | +--ro replay? uint32 | +--ro failed? uint32 +--ro replay_state | +--rorunning? yang:date-and-timeseq? uint32 | +--ro oseq? uint32 | +--ro bitmap? uint32 +--ro replay_state_esn | +--rosince? yang:date-and-timebmp-len? uint32 | +--ro oseq? uint32 | +--roinitiator? booleanoseq-hi? uint32 | +--ro seq-hi? uint32 | +--roinitiator-spi? uint64replay-window? uint32 | +--ro bmp* uint32 +--rw ah-sa | +--rw integrity | +--rw integrity-algorithm? ic:integrity-algorithm-t | +--rw key? string +--rw esp-sa +--rw encryption | +--rw encryption-algorithm? ic:encryption-algorithm-t | +--rw key? yang:hex-string | +--rw iv? yang:hex-string +--rw integrity | +--rw integrity-algorithm? ic:integrity-algorithm-t | +--rw key? yang:hex-string +--rw combined-enc-intr? boolean notifications: +---n spdb_expire | +--roresponder-spi?index? uint64 +---n sadb_acquire | +--ro base-list* [version] | | +--ronat-local? booleanversion string | | +--ronat-remote? booleanmsg_type? sadb-msg-type | | +--ronat-any? booleanmsg_satype? sadb-msg-satype | | +--roestablished? uint64msg_seq? uint32 | +--ro local-subnet? inet:ip-prefix | +--rorekey-time? uint64remote-subnet? inet:ip-prefix | +--ro upper-layer-protocol* ipsec-upper-layer-proto | +--roreauth-time? uint64local-ports* [start end] | | +--rochild-sas*start inet:port-number | | +--rospisend inet:port-number | +--ro remote-ports* [start end] | +--rospi-in? ipsec-spistart inet:port-number | +--ro end inet:port-number +---n sadb_expire | +--rospi-out? ipsec-spibase-list* [version] | | +--ronumber-ike-sasversion string | | +--rototal?msg_type? sadb-msg-type | | +--ro msg_satype? sadb-msg-satype | | +--ro msg_seq? uint32 | +--rohalf-open?spi? ic:ipsec-spi | +--ro anti-replay-window? uint16 | +--ro encryption-algorithm? ic:encryption-algorithm-t | +--ro authentication-algorithm? ic:integrity-algorithm-t | +--ro sad-lifetime-hard | | +--ro time? yang:timestamp | | +--ro idle? yang:timestamp | | +--ro bytes? uint32 | | +--ro packets? uint32 | +--ro sad-lifetime-soft | | +--ro time? yang:timestamp | | +--ro idle? yang:timestamp | | +--ro bytes? uint32 | | +--ro packets? uint32 | +--ro sad-lifetime-current | +--ro time? yang:timestamp | +--ro idle? yang:timestamp | +--ro bytes? uint32 | +--ro packets? uint32 +---n sadb_bad-spi +--ro state ic:ipsec-spi 7. Use cases examples This section explains how different traditional configurations, that is, host-to-host and gateway-to-gateway are deployed using this SDN- based IPsec management service. In turn, these configurations will be typical in modern networks where, for example, virtualization will be key. 7.1.Host-to-HostHost-to-host orGateway-to-gatewaygateway-to-gateway under the same controller +----------------------------------------+ | Security Controller | | | (1)| +--------------+ (2)+--------------+ | Flow-based ------> |Translate into|--->| South. Prot. | | Security. Pol. | |IPsec Policies| | | | | +--------------+ +--------------+ | | | | | | | | | +--------------------------|-----|-------+ | | | (3) | |-------------------------+ +---| V V +----------------------+ +----------------------+ | NSF1 |<=======>| NSF2 | |IKEv2/IPsec(SPD/PAD) | |IKEv2/IPsec(SPD/PAD) | +----------------------+ (4) +----------------------+ Figure 3:Host-to-HostHost-to-host /Gateway-to-Gatewaygateway-to-gateway single controller flow forcase 1 .the IKE case. Figure 3 describes the case1:IKE case: 1. The administrator defines general flow-based security policies. The Security Controller looks for the NSFs involved (NSF1 and NSF2). 2. The Security Controller generates IKEv2 credentials for them and translates the policies into SPD and PAD entries. 3. The Security Controller inserts the SPD and PAD entries in both NSF1 and NSF2. 4. The flow is protected with the IPsec SA established with IKEv2. +----------------------------------------+ | (1) Security Controller | Flow-based | | Security -----------| | Policy | V | | +---------------+ (2)+-------------+ | | |Translate into |--->| South. Prot.| | | |IPsec policies | | | | | +---------------+ +-------------+ | | | | | | | | | +-------------------------| --- |--------+ | | | (3) | |----------------------+ +--| V V +------------------+ +------------------+ | NSF1 |<=====>| NSF2 | |IPsec(SPD/SAD) | 4) |IPsec(SPD/SAD) | +------------------+ +------------------+ Figure 4:Host-to-HostHost-to-host /Gateway-to-Gatewaygateway-to-gateway single controller flow forcase 2.IKE-less case. Incase 2,IKE-less case, flow-based security policies defined by the administrator arealsotranslated into IPsec SPD entries and inserted into the corresponding NSFs. Besides, fresh SAD entries will be also generated by the Security Controller and enforced in the NSFs. In thiscasecase, the controller does not run anyIKEIKEv2 implementation, and it provides the cryptographic material for the IPsec SAs. These keys will be also distributed securely through the southbound interface. Note that this is possible because both NSFs are managed by the same controller. Figure 4 describes thecase 2,IKE-less, when a data packet needs to be protected in the path between the NSF1 and NSF2: 1. The administrator establishes the flow-based security policies. The Security Controller looks for the involved NSFs. 2. The Security Controller translates the flow-based security policies into IPsec SPD and SAD entries. 3. The Security Controller inserts the these entries in both NSF1 and NSF2 IPsec databases.4. The flow is protected with the IPsecIt associates a lifetime to the IPsec SAs. When this lifetime expires, the NSF will send a sadb_expire notification to the Security Controller in order to start the rekeying process. 4. The flow is protected with the IPsec SA established by the Security Controller. Both NSFs could be two hosts that exchange traffic and require to establish an end-to-end security association to protect their communications (host-to-host) or two gateways(gateway-to-gateway)),(gateway-to-gateway), for example, within an enterprise that needs to protect the traffic between, for example, the networks of two branch offices. Applicability of these configurations appear in current and new networking scenarios. For example, SD-WAN technologies are providing dynamic and on-demand VPN connections between branchofficesoffices, or between branches and SaaS cloud services. Beside, IaaS services providing virtualization environments are deployments solutions based on IPsec to provide secure channels between virtual instances(Host- to-Host)(host- to-host) and providing VPN solutions for virtualized networks(Gateway-to-Gateway).(gateway-to-gateway). In general (forcase 1IKE andcase 2),IKE-less case), this systempresentshas various advantages: 1. It allows to create IPsec SAs among two NSFs, with only the application of more general flow-based security policies at the application layer. Thus, administrators can manage all security associations in a centralized point with an abstracted view of thenetwork;network. 2. All NSFs deployed after the application of the new policies are NOT manually configured, therefore allowing its deployment in an automated manner. 7.2.Host-to-HostHost-to-host orGateway-to-gatewaygateway-to-gateway under differentSecuritysecurity controllers It is also possible that two NSFs (i.e. NSF1 and NSF2) are under the control of two different Security Controllers. This may happen, for example, when two organizations, namely Enterprise A and Enterprise B, have their headquarters interconnected through a WAN connection and they both have deployed a SDN-based architecture to provide connectivity to all their clients. +-------------+ +-------------+ | | | | Flow-based| Security |<===============>| Security <--Flow-based Sec. Pol.--> Controller | (3) | Controller | Sec. Pol. (1) | A | | B | (2) +-------------+ +-------------+ | | | (4) (4) | V V +----------------------+ +----------------------+ | NSF1 |<========>| NSF2 | |IKEv2/IPsec(SPD/PAD) | |IKEv2/IPsec(SPD/PAD) | +----------------------+ (5) +----------------------+ Figure 5: DifferentSecurity Controllerssecurity controllers inCase 1IKE case Figure 5 describes IKE case1when twoSecurity Controllerssecurity controllers are involved in the process. 1. The A's administrator establishes general Flow-based Security Policies in Security Controller A. 2. The B's administrator establishes general Flow-based Security Policies in Security Controller B. 3. The Security Controller A realizes that protection is required between the NSF1 and NSF2, but the NSF2 is under the control of another Security Controller (Security Controller B), so it starts negotiations with the other controller to agree on the IPsec SPD policies and IKEv2 credentials for their respective NSFs. NOTE: This may require extensions in the East/West interface. 4. Then, both Security Controllers enforce the IKEv2 credentials and related parameters and the SPD and PAD entries in their respective NSFs. 5. The flow is protected with the IPsec SAs established with IKEv2 between both NSFs. +--------------+ +--------------+ | | | | Flow-based. ---> | <--- Flow-based Prot. | Security |<=================>| Security |Sec. Pol.(1)| Controller | (3) | Controller |Pol. (2) | A | | B | +--------------+ +--------------+ | | | (4) (4) | V V +------------------+ (5) +------------------+ | NSF1 |<==============>| NSF2 | |IPsec(SPD/SAD) | | IPsec(SPD/SAD) | +------------------+ +------------------+ Figure 6: DifferentSecurity Controllerssecurity controllers in IKE-less case2Figure 5 describes IKE-less case2when twoSecurity Controllerssecurity controllers are involved in the process. 1. The A's administrator establishes general Flow Protection Policies in Security Controller A. 2. The B's administrator establishes general Flow Protection Policies in Security Controller B. 3. The Security Controller A realizes that the flow between NSF1 and NSF2 MUST be protected. Nevertheless, the controller notices that NSF2 is under the control of another Security Controller, so it starts negotiations with the other controller to agree on the IPsec SPD and SAD entries that define the IPsec SAs. NOTE: It would worth evaluating IKEv2 as the protocol for the East/West interface in this case. 4. Once the Security Controllers have agreed on key material and the details of the IPsec SAs, they both enforce this information into their respective NSFs. 5. The flow is protected with the IPsec SAs established by both Security Controllers in their respective NSFs. 8.Implementation notes At the timeSecurity Considerations First ofwritingall, thisdocument, we have implemented a proof-of- concept using NETCONF as southbound protocol, and the YANG model described in Appendix A. The netopeer implementation [netopeer] has been used for both case 1 and case 2 using host-to-host and gateway- to-gateway configuration. For the case 1, we have used Strongswan [strongswan] distribution for the IKE implementation. Note that the proposed YANG model providesdocument shares all themodels for SPD, SAD, PAD and IKE, but, as describe before, only partsecurity issues ofthemSDN that arerequired depending of the case (1 or 2) been applied. The Security Controller should be able to know the kind of case to be appliedspecified in theNSF"Security Considerations" section of [ITU-T.Y.3300] andto select the corresponding models based on[RFC8192]. On theYANG features defines for each one. Internallyone hand, it is important to note that there MUST exit a security association between theNSF, the NETCONF server (that implementsSecurity Controller and theI2NSF Agent) is ableNSFs toapplyprotect of therequiredcritical information (cryptographic keys, configurationupdating the correspondingparameter, etc...) exchanged between these entities. For example, if NETCONFdatastores (running, startup, etc.). Besides, it can deal withis used as southbound protocol between theSPD and SAD configuration at kernel level, through different APIs. For example, the IETF RFC 2367 (PF_KEYv2) [RFC2367] provides a generic key management API that can be used not only for IPsec but also for other network security services to manage the IPsec SAD. Besides, as an extension to this API, the document [I-D.pfkey-spd] specifies some PF_KEY extensions to maintain the SPD. This API is accessed using sockets. An alternative key management API based on Netlink socket API [RFC3549] is used to configure IPsec on the Linux Operating System. To allow the NETCONF server implementation interacts with the IKE daemon, we have used the Versatile IKE Configuration Interface (VICI) in Strongswan. This allows changes in the IKE part of the configuration data to be applied in the IKE daemon dynamically. 9. Security Considerations First of all, this document shares all the security issues of SDN that are specified in the "Security Considerations" section of [ITU-T.Y.3300] and [RFC8192]. On the one hand, it is important to note that there must exit a security association between the Security Controller and the NSFs to protect of the critical information (cryptographic keys, configuration parameter, etc...) exchanged between these entities. For example, if NETCONF is used as southbound protocol between the Security ControllerSecurity Controller and the NSFs, it is defined that TLS or SSH securityassocation mustassociation MUST be established between both entities. On the other hand, we have divided this section in two parts to analyze different security considerations for both cases: NSF with IKEv2(case 1)(IKE case) and NSF without IKEv2(case 2).(IKE-less case). In general, the Security Controller, as typically in the SDN paradigm, is a target for different type of attacks. As a consequence, the Security Controller is a key entity in the infrastructure and MUST be protected accordingly. In particular, according to this document, the Security Controller will handle cryptographic material so that the attacker may try to access this information. Although, we can assume this attack will not likely to happen due to the assumed security measurements to protect the Security Controller, it deserves some analysis in the hypothetical the attack occurs. The impact is different depending on the IKE case1or IKE-less case. 8.1. IKE case2. 9.1. Case 1Inthis case 1,IKE case, the Security Controller sends IKE credentials (PSK, public/private keys, certificates, etc...) to the NSFs using the security association between Security Controller and NSFs. The general recommendation is that the Security Controller SHOULD NEVER store the IKE credentials after distributing them. Moreover the NSFs MUST NOT allow the reading of these values once they have been applied by the Security Controller (i.e. write only operations). One option is return always the same value (all 0s). If the attacker has access to the Security Controller during the period of time that key material is generated, it may access to these values. Since these values are used during NSF authentication in IKEv2, it may impersonate the affected NSFs. Several recommendations are important. If PSK authentication is used in IKEv2, the Security Controller SHOULD remove the PSK immediately after generating and distributing it. Moreover, the PSK MUST have a proper length (e.g. minimu, 128 bit length) and strength. If raw public keys are used, the Security Controller SHOULD remove the associated private key immediately after generating and distributing them to the NSFs. If certificates are used, the NSF may generate the private key and exports the public key for certificationinto the Security Controller.9.2. Case 28.2. IKE-less case In thecase 2,IKE-less case, the controller sends the IPsec SA information to the SAD that includes the keys for integrity and encryption (when ESP is used). That key material are symmetric keys to protect data traffic. The general recommendation is that the Security Controller SHOULD NEVER stores the keys after distributing them.MoreoverMoreover, the NSFs MUST NOT allow the reading of these values once they have been applied by the Security Controller (i.e. write only operations). Nevertheless, if the attacker has access to the Security Controller during the period of time that key material is generated, it may access to these values. In other words, it may have access to the key material used in the distributed IPsec SAs and observe the traffic between peers. In any case, some escenarios with special secureenviromentsenvironments (e.g. physically isolated data centers) make this type of attack difficult. Moreover, some scenarios such as IoT networks with constrained devices, where reducing implementation and computation overhead is important, can apply IKE-less case2as a tradeoff between security and low overhead at the constrained device, at the cost of assuming the security impact described above.10.9. Acknowledgements Authors want to thank Paul Wouters, Sowmini Varadhan, David Carrel, Yoav Nir, Tero Kivinen,Paul Wouters,Graham Bartlett, Sandeep Kampati, Linda Dunbar, Carlos J. Bernardos, Alejandro Perez-Mendez,Fernando Pereniguez-Garcia,AlejandroAbad-Carrascosa,Abad- Carrascosa, Ignacio Martinez and Ruben Ricart for their valuable comments.11.10. References11.1.10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, <https://www.rfc-editor.org/info/rfc4301>. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 5226, DOI 10.17487/RFC5226, May 2008, <https://www.rfc-editor.org/info/rfc5226>. [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, <https://www.rfc-editor.org/info/rfc7296>.11.2. Informative References [I-D.ietf-i2nsf-framework][RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., and J. Jeong, "Interface to Network Security Functions (I2NSF): Problem Statement and Use Cases", RFC 8192, DOI 10.17487/RFC8192, July 2017, <https://www.rfc-editor.org/info/rfc8192>. [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. Kumar, "Framework for Interface to Network Security Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, <https://www.rfc-editor.org/info/rfc8329>. 10.2. Informative References [I-D.carrel-ipsecme-controller-ike] Carrel, D. and B. Weiss, "IPsec Key Exchange using a Controller", draft-carrel-ipsecme-controller-ike-01 (work in progress), March 2019. [I-D.ietf-i2nsf-framework] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. Kumar, "Framework for Interface to Network Security Functions", draft-ietf-i2nsf-framework-10 (work in progress), November 2017. [I-D.ietf-i2nsf-problem-and-use-cases] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., and J. Jeong, "I2NSF Problem Statement and Use cases", draft-ietf-i2nsf-problem-and-use-cases-16 (work in progress), May 2017. [I-D.ietf-i2nsf-terminology] Hares, S., Strassner, J., Lopez, D., Xia, L., and H. Birkholz, "Interface to Network Security Functions (I2NSF) Terminology",draft-ietf-i2nsf-terminology-06draft-ietf-i2nsf-terminology-07 (work in progress),JulyJanuary 2019. [I-D.ietf-opsawg-nat-yang] Boucadair, M., Sivakumar, S., Jacquenet, C., Vinapamula, S., and Q. Wu, "A YANG Module for Network Address Translation (NAT) and Network Prefix Translation (NPT)", draft-ietf-opsawg-nat-yang-17 (work in progress), September 2018. [I-D.jeong-i2nsf-sdn-security-services-05] Jeong, J., Kim, H., Park, J., Ahn, T., and S. Lee, "Software-Defined Networking Based Security Services using Interface to Network Security Functions", draft-jeong- i2nsf-sdn-security-services-05 (work in progress), July 2016. [I-D.pfkey-spd] Sakane, S., "PF_KEY Extensions for IPsec Policy Management in KAME Stack", October 2002.[I-D.sivakumar-yang-nat] Sivakumar, S., Boucadair, M., and S. Vinapamula, "YANG Data Model for Network Address Translation (NAT)", draft- sivakumar-yang-nat-07 (work in progress), July 2017.[I-D.tran-ipsecme-yang] Tran, K., Wang, H., Nagaraj, V., and X. Chen, "Yang Data Model for Internet Protocol Security (IPsec)", draft-tran- ipsecme-yang-01 (work in progress), June 2015. [ITU-T.X.1252] "Baseline Identity Management Terms and Definitions", April 2010. [ITU-T.X.800] "Security Architecture for Open Systems Interconnection for CCITT Applications", March 1991. [ITU-T.Y.3300] "Recommendation ITU-T Y.3300", June 2014. [netconf-vpn] Stefan Wallin, "Tutorial: NETCONF and YANG", January 2014. [netopeer] CESNET, CESNET., "NETCONF toolset Netopeer", November 2016. [ONF-OpenFlow] ONF, "OpenFlow Switch Specification (Version 1.4.0)", October 2013. [ONF-SDN-Architecture] "SDN Architecture", June 2014. [RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key Management API, Version 2", RFC 2367, DOI 10.17487/RFC2367, July 1998, <https://www.rfc-editor.org/info/rfc2367>. [RFC3549] Salim, J., Khosravi, H., Kleen, A., and A. Kuznetsov, "Linux Netlink as an IP Services Protocol", RFC 3549, DOI 10.17487/RFC3549, July 2003, <https://www.rfc-editor.org/info/rfc3549>. [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, DOI 10.17487/RFC3948, January 2005, <https://www.rfc-editor.org/info/rfc3948>. [RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap", RFC 6071, DOI 10.17487/RFC6071, February 2011, <https://www.rfc-editor.org/info/rfc6071>. [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined Networking: A Perspective from within a Service Provider Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, <https://www.rfc-editor.org/info/rfc7149>. [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for System Management", RFC 7317, DOI 10.17487/RFC7317, August 2014, <https://www.rfc-editor.org/info/rfc7317>.[RFC8192] Hares,[RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S.,Lopez,Hadi Salim, J., Meyer, D.,Zarny, M., Jacquenet, C., Kumar, R.,andJ. Jeong, "Interface to Network Security Functions (I2NSF): Problem StatementO. Koufopavlou, "Software- Defined Networking (SDN): Layers andUse Cases",Architecture Terminology", RFC8192,7426, DOI10.17487/RFC8192, July 2017, <https://www.rfc-editor.org/info/rfc8192>.10.17487/RFC7426, January 2015, <https://www.rfc-editor.org/info/rfc7426>. [RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229, August 2017, <https://www.rfc-editor.org/info/rfc8229>. [strongswan] CESNET, CESNET., "StrongSwan: the OpenSource IPsec-based VPN Solution", April 2017. Appendix A. Appendix A: Common YANG modelIPsec Configuration datafor IKE and IKEless cases <CODE BEGINS> file"ietf-ipsec@2018-10-20.yang""ietf-ipsec-common@2019-03-11.yang" moduleietf-ipsec {ietf-ipsec-common{ yang-version 1.1; namespace"urn:ietf:params:xml:ns:yang:ietf-ipsec";"urn:ietf:params:xml:ns:yang:ietf-ipsec-common"; prefix"eipsec";"ipsec-common"; import ietf-inet-types { prefix inet; } import ietf-yang-types { prefix yang; } import ietf-crypto-types { prefix ct; reference "draft-ietf-netconf-crypto-types-01: Common YANG Dta Types for Cryptography"; } organization"University of Murcia";"IETF I2NSF (Interface to Network Security Functions) Working Group"; contact " Rafael Marin Lopez Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 e-mail: rafa@um.es Gabriel Lopez Millan Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Tel: +34 868888504 email: gabilm@um.es Fernando Pereniguez Garcia Department of Sciences and Informatics University Defense Center (CUD), Spanish Air Force Academy, MDE-UPCT 30720 San Javier - Spain Tel: +34 968189946 email: fernando.pereniguez@cud.upct.es "; description"Data"Common Data model forIPSec";SDN-based IPSec configuration."; revision"2018-10-20""2019-03-11" { description "Revision"; reference ""; }feature case1typedef encryption-algorithm-t { type ct:encryption-algorithm-ref; description"feature case 1: IKE SPD PAD";"typedef"; }// IKE/IPSec in the NSFs feature case2typedef integrity-algorithm-t { type ct:mac-algorithm-ref; description"feature case 2: SPD SAD"; } // Only IPSec in"This typedef enables importing modules to easily define an identityref to theNSFs'asymmetric-key-encryption-algorithm' base identity."; } typedefencryption-algorithm-tipsec-mode { type enumeration { enumreserved-0 {description "reserved";} enum des-iv4 { description "DES IV 4";} enum desTRANSPORT { description"DES";"Transport mode. No NAT support."; } enum3desTUNNEL { description"3DES";"Tunnel mode"; }enum rc5 { description "RC5";}enum idea {description"IDEA";"Type definition of IPsec mode"; }enum casttypedef esp-encap {description "CAST"; } enum blowfishtype enumeration {description "BlowFish"; }enum3ideaESPINTCP { description"3IDEA"; }"ESP in TCP encapulation.";} enumdes-iv32ESPINTLS { description"DES-IV32"; }"ESP in TCP encapsulation using TLS.";} enumreserved-10ESPINUDP { description"reserved-10"; }"ESP in UDP encapsulation. RFC 3948 ";} enumnullNONE { description"NULL";"NOT ESP encapsulation" ; }enum aes-cbc { description "AES-CBC";}enum aes-ctr {description"AES-CTR";"type defining types of ESP encapsulation"; }enum aes-ccm-8 { description "AES-CCM-8"; } enum aes-ccm-12grouping encap { /* This is defined by XFRM */ description"AES-CCM-12"; } enum aes-ccm-16"Encapsulation container"; leaf espencap { type esp-encap; description"AES-CCM-16"; } enum reserved-17 {"ESP in TCP, ESP in UDP or ESP in TLS";} leaf sport {type inet:port-number; description "Encapsulation source port";} leaf dport {type inet:port-number; description"reserved-17";"Encapsulation destination port"; }enum aes-gcm-8-icv {leaf-list oaddr {type inet:ip-address; description"AES-GCM-8-ICV";"Encapsulation Original Address ";} } typedef ipsec-protocol { type enumeration { enumaes-gcm-12-icvah { description"AES-GCM-12-ICV";"AH Protocol"; } enumaes-gcm-16-icvesp { description"AES-GCM-16-ICV";"ESP Protocol"; } }enum null-auth-aes-gmac {description"Null-Auth-AES-GMAC";"type define of ipsec security protocol"; }enum ieee-p1619-xts-aestypedef ipsec-spi {description "encr-ieee-p1619-xts-aes -> Reserved for IEEE P1619 XTS-AES.";} enum camellia-cbctype uint32 {description "CAMELLIA-CBC";range "0..max"; }enum camellia-ctr {description"CAMELLIA.CTR";"SPI"; }enum camellia-ccm-8-icvtypedef lifetime-action {description "CAMELLIA-CCM-8-ICV"; } enum camellia-ccm-12-icvtype enumeration {description "CAMELLIA-CCM-12-ICV"; }enumcamellia-ccm-16-icv { description "CAMELLIA-CCM-16-ICV"; }terminate-clear {description "Terminate the IPsec SA and allow the packets through";} enumaes-cbc-128 { description "AES-CBC-128"; }terminate-hold {description "Terminate the IPsec SA and drop the packets";} enumaes-cbc-192 { description "AES-CBC-192";replace {description "Replace the IPsec SA with a new one";} }enum aes-cbc-256 {description"AES-CBC-256";"Action when lifetime expiration"; }enum blowfish-128/*################## SPD basic groupings ####################*/ typedef ipsec-traffic-direction { type enumeration {description "BlowFish-128"; }enumblowfish-192INBOUND { description"BlowFish-192";"Inbound traffic"; } enumblowfish-256OUTBOUND { description"BlowFish-256";"Outbound traffic"; } }enum blowfish-448 {description"BlowFish-448";"IPsec traffic direction"; } typedef ipsec-spd-operation { type enumeration { enumcamellia-128PROTECT { description"CAMELLIA-128";"PROTECT the traffic with IPsec"; } enumcamellia-192BYPASS { description"CAMELLIA-192";"BYPASS the traffic"; } enumcamellia-256DISCARD { description"CAMELLIA-256";"DISCARD the traffic"; } } description"Encryption algorithms -> RFC_5996";"The operation when traffic matches IPsec security policy"; } typedefintegrity-algorithm-tipsec-upper-layer-proto { type enumeration { enumnoneTCP { description"NONE";"TCP traffic"; } enumhmac-md5-96UDP { description"HMAC-MD5-96";"UDP traffic"; } enumhmac-sha1-96SCTP { description"HMAC-SHA1-96"; }"SCTP traffic";} enumdes-macDCCP { description"DES-MAC"; } enum kpdk-md5 {description "KPDK-MD5"; }"DCCP traffic";} enumaes-xcbc-96ICMP { description"AES-XCBC-96"; }"ICMP traffic";} enumhmac-md5-128IPv6-ICMP { description"HMAC-MD5-128"; }"IPv6-ICMP traffic";} enumhmac-sha1-160 { description "HMAC-SHA1-160";GRE {description "GRE traffic";} }enum aes-cmac-96 {description"AES-CMAC-96";"Next layer proto on top of IP"; }enum aes-128-gmactypedef ipsec-spd-name {description "AES-128-GMAC"; } enum aes-192-gmactype enumeration {description "AES-192-GMAC"; }enumaes-256-gmacid_rfc_822_addr { description"AES-256-GMAC";"Fully qualified user name string."; } enumhmac-sha2-256-128id_fqdn { description"HMAC-SHA2-256-128";"Fully qualified DNS name."; } enumhmac-sha2-384-192id_der_asn1_dn { description"HMAC-SHA2-384-192";"X.500 distinguished name."; } enumhmac-sha2-512-256id_key { description"HMAC-SHA2-512-256"; } enum hmac-sha2-256-96 { description "HMAC-SHA2-256-096";"IKEv2 Key ID."; } } description"Integrity Algorithms -> RFC_5996";"IPsec SPD name type"; }typedef type-autostartup { type enumeration { enum ALWAYSONgrouping lifetime { description" ";} enum INITIATE-ON-DEMAND {description " ";} enum RESPOND-ONLY {description " ";} }"lifetime current state data"; leaf time {type yang:timestamp; default 0; description"Different types of how IKEv2 starts"Time since theIPsec SAs"; } typedef auth-protocol-typeelement is added";} leaf idle {type yang:timestamp; default 0; description "Time the element is in idle state";} leaf bytes { typeenumeration { enum IKEv1 {uint32; default 0; description"Authentication protocol based on IKEv1"; } enum IKEv2 {"Lifetime in bytes number";} leaf packets {type uint32; default 0; description"Authentication protocol based on IKEv2";"Lifetime in packets number";} }enum KINK/*################## SAD and SPD common basic groupings ####################*/ grouping port-range { description"Authentication protocol based on KINK"; } } description "Peer authentication protocols"; } typedef ipsec-mode"Port range grouping"; leaf start { typeenumeration { enum TRANSPORT {inet:port-number; description"Transport mode";"Start Port Number"; }enum TUNNELleaf end { type inet:port-number; description"Tunnel mode";"End Port Number"; }enum BEET} grouping tunnel-grouping { description"Bound End-to-End Tunnel (BEET)"Tunnel modefor ESP.";} enum RO {grouping"; leaf local{ type inet:ip-address; description"Route Optimization mode for Mobile IPv6";} enum IN_TRIGGER {description "In trigger mode for Mobile IPv6";}"Local tunnel endpoint"; } leaf remote{ type inet:ip-address; description"type define of ipsec mode";"Remote tunnel enpoint"; }typedef esp-encapleaf bypass-df { typeenumeration { enum ESPINTCP { description "ESP in TCP encapulation.";} enum ESPINTLS { description "ESP in TCP encapsulation using TLS.";} enum ESPINUDP {boolean; description"ESP in UDP encapsulation. RFC 3948 ";}"Bypass DF bit"; } leaf bypass-dscp { type boolean; description"type defining types of ESP encapsulation";"Bypass DSCP"; }typedef ipsec-protocolleaf dscp-mapping { typeenumeration { enum ah {yang:hex-string; description"AH Protocol";"DSCP mapping"; }enum espleaf ecn { type boolean; description"ESP Protocol";"Bit ECN"; }enum comp/* RFC 4301 ASN1 notation. Annex C*/ } grouping selector-grouping { description"IP Compression";} /*Supported by XFRM*/ enum route2"Traffic selector grouping"; leaf local-subnet {description "Routing Headertype2. Mobile IPv6";} /*Supported by XFRM*/ enum hao {description "Home Agent Option";} /*Supported by XFRM*/ }inet:ip-prefix; description"type define of ipsec security protocol";"Local IP address subnet"; }typedef ipsec-spileaf remote-subnet { typeuint32 { range "0..max"; }inet:ip-prefix; description"SPI";"Remote IP address subnet"; }typedef lifetime-actionleaf-list upper-layer-protocol { typeenumerationipsec-upper-layer-proto; description "List of Upper Layer Protocol";} list local-ports {enum terminate {description "Terminate the IPsec SA";} enum replace {description "Replacekey "start end"; uses port-range; description "List of local ports. When theIPsec SA with a new one";}upper-layer-protocol is ICMP this 16 bit value respresents code and type as mentioned in RFC 4301"; } list remote-ports { key "start end"; uses port-range; description"Action when lifetime expiration";"List of remote ports. When the upper-layer-protocol is ICMP this 16 bit value respresents code and type as mentioned in RFC 4301"; }typedef ipsec-traffic-direction} /*################## SPD ipsec-policy-grouping ####################*/ grouping ipsec-policy-grouping { description "Holds configuration information for an IPSec SPD entry."; leaf spd-entry-id { typeenumerationuint64; description "SPD entry id "; } leaf priority {type uint32; default 0; description "Policy priority";} leaf anti-replay-window {enum INBOUNDtype uint16 { range "0 | 32..1024"; } description"Inbound traffic";"Anti replay window size"; }enum OUTBOUNDlist names { key "name"; leaf name-type { type ipsec-spd-name; description"Outbound traffic";"SPD name type."; }enum FORWARD{leaf name { type string; description"Forwarded traffic"; }"Policy name"; } description"IPsec traffic direction";"List of policy names"; }typedef ipsec-spd-operationcontainer condition {type enumerationdescription "SPD condition - RFC4301"; list traffic-selector-list {enum PROTECTkey "ts-number"; leaf ts-number { type uint32; description"PROTECT the traffic with IPsec";"Traffic selector number"; }enum BYPASSleaf direction { type ipsec-traffic-direction; description"BYPASS the traffic";"in/out"; }enum DISCARD {uses selector-grouping; ordered-by user; description"DISCARD the traffic";"List of traffic selectors"; } }description "The operation when traffic matches IPsec security policy"; } typedef ipsec-next-layer-protocontainer processing-info { description "SPD processing - RFC4301"; leaf action{ typeenumerationipsec-spd-operation; mandatory true; description "Bypass or discard, container ipsec-sa-cfg is empty";} container ipsec-sa-cfg {enum TCPwhen "../action = 'PROTECT'"; leaf pfp-flag { type boolean; description"PROTECT the traffic"Each selector has withIPsec";a pfp flag."; }enum UDPleaf extSeqNum { type boolean; description"BYPASS the traffic";"TRUE 64 bit counter, FALSE 32 bit"; }enum SCTP { description "PROTECT the traffic with IPsec";} enum DCCP { description "PROTECT the traffic with IPsec";} enum ICMPleaf seqOverflow { type boolean; description"PROTECT the traffic with IPsec";} enum IPv6-ICMP"TRUE rekey, FALSE terminare & audit"; } leaf statefulfragCheck { type boolean; description"PROTECT the traffic with IPsec";} enum MH {description "PROTECT the traffic with IPsec";} enum GRE {description "PROTECT"Indicates whether (TRUE) or not (FALSE) stateful fragment checking (RFC 4301) applies to thetraffic with IPsec";}SA to be created."; } leaf security-protocol { type ipsec-protocol; description"Next layer proto on top"Security protocol ofIP";IPsec SA: Either AH or ESP."; }typedef ipsec-spd-nameleaf mode { typeenumerationipsec-mode; description "transport/tunnel"; } container ah-algorithms {enum id_rfc_822_addrwhen "../security-protocol = 'ah'"; leaf-list ah-algorithm { type integrity-algorithm-t; description"Fully qualified user name string.";"Configure Authentication Header (AH)."; }enum id_fqdnleaf trunc-length { type uint32; description"Fully qualified DNS name.";"Truncation value for AH algorithm"; }enum id_der_asn1_dn {description"X.500 distinguished name.";"AH algoritms "; }enum id_keycontainer esp-algorithms { when "../security-protocol = 'esp'"; description"IKEv2 Key ID."; } }"Configure Encapsulating Security Payload (ESP)."; leaf-list authentication { type integrity-algorithm-t; description"IPsec SPD name type";"Configure ESP authentication"; }typedef auth-method-type {/*Most implementations also provide XAUTH protocol, othersWith AEAD algorithms, the authentication node is not usedare: BLISS, P12, NTLM, PIN*/type enumeration { enum pre-sharedleaf-list encryption { type encryption-algorithm-t; description"Select pre-shared key message as the authentication method";"Configure ESP encryption"; }enum rsa-signatureleaf tfc_pad { type uint32; default 0; description"Select rsa digital signature as the authentication method";"TFC padding for ESP encryption"; }enum dss-signature { description "Select dss digital signature as the authentication method";}enum eapcontainer tunnel { when "../mode = 'TUNNEL'"; uses tunnel-grouping; description"Select EAP as the authentication method"; } } description "Peer authentication method";"tunnel grouping container"; }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";}" IPSec SA configuration container"; }description "Security Association state";}grouping lifetimecontainer spd-lifetime-soft { description"lifetime current"SPD lifetime hard state data"; uses lifetime; leafadded {type uint64; default 0; description "added time and date";} leaf usedaction {typeuint64; default 0;lifetime-action; description"used time and date";} leaf bytes"Action lifetime";} } container spd-lifetime-hard {type uint32; default 0;description"current"SPD lifetimebytes";} leaf packets {type uint32; default 0; description "currenthard state data. The action after the lifetimepackets";}is to remove the SPD entry."; uses lifetime; }/*################## PAD grouping ####################*/ grouping auth-method-grouping// State data for an IPsec SPD entry container spd-lifetime-current { uses lifetime; config false; description"Peer authentication method"SPD lifetime current state data";container auth-method} } /* grouping ipsec-policy-grouping */ } <CODE ENDS> Appendix B. Appendix B: YANG model for IKE case <CODE BEGINS> file "ietf-ipsec-ike@2019-03-11.yang" module ietf-ipsec-ike {description "Peer authentication method container"; leaf auth-myang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec-ike"; prefix "ipsec-ike"; import ietf-inet-types {type auth-method-type; description "Type of authentication method (preshared, rsa, etc.)";prefix inet; }container pre-shared { when "../auth-m = 'pre-shared'"; leaf secretimport ietf-yang-types {type string; description "Pre-shared secret value";} description "Shared secret value";prefix yang; }container rsa-signatureimport ietf-crypto-types {when "../auth-m = 'rsa-signature'"; leaf key-data { type string; description "RSA private key data - PEM";prefix ct; reference "draft-ietf-netconf-crypto-types-01: Common YANG Data Types for Cryptography"; }leaf key-fileimport ietf-ipsec-common {type string; description "RSA private key file name ";prefix ic; reference "Common Data model for SDN-based IPSec configuration"; }leaf-list ca-data { type string; description "Listorganization "IETF I2NSF (Interface to Network Security Functions) Working Group"; contact " Rafael Marin Lopez Dept. Information and Communications Engineering (DIIC) Faculty oftrusted CA certsComputer Science-University of Murcia 30100 Murcia -PEM"; } leaf ca-file { type string; description "ListSpain Telf: +34868888501 e-mail: rafa@um.es Gabriel Lopez Millan Dept. Information and Communications Engineering (DIIC) Faculty oftrusted CA certs file"; } leaf cert-data { type string; description "X.509 certificate dataComputer Science-University of Murcia 30100 Murcia -PEM4"; } leaf cert-file { type string; description "X.509 certificate file"; } leaf crl-data { type string; description "X.509 CRL certificate data in base64"; } leaf crl-file { type string; description " X.509 CRL certificate file"; } description "RSA signature container"; } } } grouping identity-grouping { description "Identification type. It is an union identity"; choice identity { description "ChoiceSpain Tel: +34 868888504 email: gabilm@um.es Fernando Pereniguez Garcia Department ofidentity."; 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.Sciences and Informatics University Defense Center (CUD), Spanish Air Force Academy, MDE-UPCT 30720 San Javier - Spain Tel: +34 968189946 email: fernando.pereniguez@cud.upct.es ";} 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 */ /*################ end PAD grouping ##################*/ /*################## SAD and SPD grouping ####################*/ grouping ip-addr-range { description "IP address range grouping"; leaf start { type inet:ip-address; description "Start IP address"; } leaf end { type inet:ip-address; description "End IP address"; } } grouping port-range { 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 { 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 { description "Traffic selector grouping"; list local-addresses { key "start end"; uses ip-addr-range; description "List of local addresses"; } list remote-addresses { key "start end"; uses ip-addr-range; description "List of remote addresses"; } leaf-list next-layer-protocol { type ipsec-next-layer-proto; description "List of Next Layer Protocol";} list local-ports { key "start end"; uses port-range; description "List of local ports"; } list remote-ports { key "start end"; uses port-range; description "List of remote ports"; } } /*################## SAD grouping ####################*/ grouping ipsec-sa-grouping { description "Configure Security Association (SA). Section 4.4.2.1 in RFC 4301"; leaf spi { type ipsec-spi; description "Security Parameter Index";} leaf seq-number { type uint64; description "Current sequence number of IPsec packet."; } leaf seq-number-overflow-flag { type boolean; description "The flag indicating whether overflow of the sequence number counter should prevent transmission of additional packets on the SA, or whether rollover is permitted."; } leaf anti-replay-window { type uint16 { range "0 | 32..1024"; } description "Anti replay window size"; } leaf rule-number {type uint32; description "This value links the SA with the SPD entry";} uses selector-grouping; leaf security-protocol { type ipsec-protocol; description "Security protocol of IPsec SA: Either AH or ESP."; } container ah-sa { when "../security-protocol = 'ah'"; description "Configure Authentication Header (AH) for SA"; container integrity { description "Configure integrity for IPSec Authentication Header (AH)"; leaf integrity-algorithm { type integrity-algorithm-t; description "Configure Authentication Header (AH)."; } leaf key { type string; description "AH key value";} } } container esp-sa { when "../security-protocol = 'esp'"; description "Set IPSec Encapsulation Security Payload (ESP)"; container encryption { description "Configure encryption for IPSec Encapsulation Secutiry Payload (ESP)"; leaf encryption-algorithm { type encryption-algorithm-t; description "Configure ESP encryption"; } leaf key { type string; description "ESP encryption key value";} leaf iv {type string; description "ESP encryption IV value"; } } container integrity { description "Configure authentication for IPSec Encapsulation Secutiry Payload (ESP)"; leaf integrity-algorithm { type integrity-algorithm-t; description "Configure Authentication Header (AH)."; } leaf key { type string; description "ESP integrity key value";} } leaf combined-enc-intr { type boolean; description "ESP combined mode algorithms. The algorithm is specified in encryption-algorithm in the container encryption";} } container sad-lifetime-hard { description "SAD lifetime hard state data"; uses lifetime; leaf action {type lifetime-action; description "action lifetime";} } container sad-lifetime-soft { description "SAD lifetime hard state data"; uses lifetime; leaf action {type lifetime-action; description "action lifetime";} } leaf mode { type ipsec-mode; description "SA Mode"; } leaf statefulfragCheck { type boolean; description "TRUE stateful fragment checking, FALSE no stateful fragment checking"; } 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 tunnel { when "../mode = 'TUNNEL'"; uses tunnel-grouping; description "Container for tunnel grouping"; } container encap { /* This is defined by XFRM */ description "Encapsulation container"; leaf espencap { type esp-encap; description "ESP in TCP, ESP in UDP or ESP in TLS";} leaf sport {type inet:port-number; description "Encapsulation source port";} leaf dport {type inet:port-number; description "Encapsulation destination port"; } leaf oaddr {type inet:ip-address; description "Encapsulation Original Address ";} } // STATE DATA for SA container sad-lifetime-current { uses lifetime; config false; description "SAD lifetime current state data"; } leaf state {type sa-state; config false; description "current state of SA (mature, larval, dying or dead)"; } container stats { // xfrm.h leaf replay-window {type uint32; default 0; description " "; } leaf replay {type uint32; default 0; description "packets detected out of the replay window and dropped because they are replay packets";} leaf failed {type uint32; default 0; description "packets detected out of the replay window ";} config false; description "SAD statistics"; } container replay_state { // xfrm.h leaf seq {type uint32; default 0; description "input traffic sequence number when anti-replay-window != 0";} leaf oseq {type uint32; default 0; description "output traffic sequence number";} leaf bitmap {type uint32; default 0; description "";} config false; description "Anti-replay Sequence Number state"; } 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"Data model for IKE case."; revision "2019-03-11" {type uint32; default 0;description "Revision 1.1"; reference ""; }leaf seq-hitypedef type-autostartup { typeuint32; default 0;enumeration { enum ADD {description "IPsec configuration is only loaded but not started.";} enum ON-DEMAND {description "IPsec configuration is loaded and transferred to the NSF's kernel";} enum START { description"";"IPsec configuration is loaded and transferred to the NSF's kernel, and the IKEv2 based IPsec SAs are established";} }leaf replay-window {type uint32; default 0;description"";"Different policies of when to start an IKEv2 based IPsec SA"; }leaf-list bmptypedef auth-protocol-type { typeuint32;enumeration { enum IKEv2 { description"bitmaps for ESN (depends"Authentication protocol based onbmp-len) ";IKEv2"; }config false; description "Anti-replay Extended Sequence Number (ESN) state";} description "IKE authentication protocol version"; }/*################## end SAD grouping ##################*/ /*################## SPD grouping ####################*/ grouping ipsec-policy-groupingtypedef pfs-group { type enumeration { enum NONE {description "NONE";} enum 768-bit-MODP {description "768-bit MODP Group";} enum 1024-bit-MODP {description "1024-bit MODP Group";} enum 1536-bit-MODP {description "1536-bit MODP Group";} enum 2048-bit-MODP {description "2048-bit MODP Group";} enum 3072-bit-MODP {description "3072-bit MODP Group";} enum 4096-bit-MODP {description "4096-bit MODP Group";} enum 6144-bit-MODP {description "6144-bit MODP Group";} enum 8192-bit-MODP {description "8192-bit MODP Group";} } description"Holds configuration information"PFS group foran IPSec SPD entry."; leaf rule-numberIPsec rekey"; } /*################## PAD ####################*/ typedef auth-method-type {type uint64; description "SPD index. RFC4301 does not mention an index however real/* Most implementations also providea policy index/or id to refer a policy. "; } leaf priority {type uint32; default 0; description "Policy priority";} list namesXAUTH protocol, others used are: BLISS, P12, NTLM, PIN */ type enumeration { enum pre-shared { description "Select pre-shared key"name"; leaf name-typemessage as the authentication method"; } enum eap {type ipsec-spd-name;description"SPD name type.";"Select EAP as the authentication method"; }leaf nameenum digital-signature { description "Select digital signature method";} enum null {description "null authentication";} } description "Peer authentication method"; } typedef signature-algorithm-t { typestring;ct:signature-algorithm-ref; // We must reference to "signature-algorithm-ref" but we temporary use hash-algorithm-ref description"Policy name";"This typedef enables referencing to any digital signature algorithm"; } grouping auth-method-grouping { description"List of policy names"; }"Peer authentication method data"; containerconditionauth-method { description"SPD condition -> RFC4301"; list traffic-selector-list { key "ts-number";"Peer authentication method container"; leafts-numberauth-m { typeuint32;auth-method-type; description"Traffic selector number";"Type of authentication method (pre-shared, eap, digital signature, null)"; } container eap-method { when "../auth-m = 'eap'"; leafdirectioneap-type { typeipsec-traffic-direction;uint8; description"in/fwd/out";"EAP method type"; }uses selector-grouping; leaf selector-priority {type uint32; default 0;description"It establishes a priority to the traffic selector";} ordered-by user;"EAP method description"List of traffic selectors"; }used when auth method is eap"; } containerprocessing-infopre-shared {description "SPD processing -> RFC4301";when "../auth-m[.='pre-shared' or .='eap']"; leafaction{secret { typeipsec-spd-operation; mandatory true;yang:hex-string; description"If the action is bypass or discard processing container ipsec-sa-cfg is empty";}"Pre-shared secret value";} description "Shared secret value"; } containeripsec-sa-cfgdigital-signature { when"../action = 'PROTECT'";"../auth-m[.='digital-signature' or .='eap']"; leafpfp-flag { type boolean;ds-algorithm {type signature-algorithm-t; description"Each selector has with a pfp flag."; }"Name of the digital signature algorithm";} leafextSeqNum { type boolean;raw-public-key {type yang:hex-string; description"TRUE 64 bit counter, FALSE 32 bit"; }"RSA raw public key" ;} leafseqOverflowkey-data { typeboolean;string; description"TRUE rekey, FALSE terminare & audit";"RSA private key data - PEM"; } leafstatefulfragCheckkey-file { typeboolean;string; description"TRUE stateful fragment checking, FALSE no stateful fragment checking";"RSA private key file name "; }leaf security-protocolleaf-list ca-data { typeipsec-protocol;string; description"Security protocol"List ofIPsec SA: Either AH or ESP.";trusted CA certs - PEM"; } leafmodeca-file { typeipsec-mode;string; description"transport/tunnel";"List of trusted CA certs file"; }container ah-algorithms { when "../security-protocol = 'ah'"; leaf-list ah-algorithmleaf cert-data { typeintegrity-algorithm-t; description "Configure Authentication Header (AH)."; }string; description"AH algoritms ";"X.509 certificate data - PEM4"; }container esp-algorithmsleaf cert-file {when "../security-protocol = 'esp'";type string; description"Configure Encapsulating Security Payload (ESP)."; leaf-list authentication"X.509 certificate file"; } leaf crl-data { typeintegrity-algorithm-t;string; description"Configure ESP authentication";"X.509 CRL certificate data in base64"; }leaf-list encryptionleaf crl-file { typeencryption-algorithm-t;string; description"Configure ESP encryption"; }" X.509 CRL certificate file"; }container tunnelleaf oscp-uri {when "../mode = 'TUNNEL'"; uses tunnel-grouping;type inet:uri; description"tunnel grouping container"; }"OCSP URI";} description" IPSec SA configuration"RSA signature container"; } }container spd-mark} grouping identity-grouping { description "Identification type. It is an union identity"; choice identity { description "Choice of identity."; leaf ipv4-address { type inet:ipv4-address; description"policy: mark MARK mask MASK"Specifies the identity as a single four (4) octet IPv4 address. An example is, 10.10.10.10. "; } leafmarkipv6-address { typeuint32; default 0;inet:ipv6-address; description"mark value";}"Specifies the identity as a single sixteen (16) octet IPv6 address. An example is FF01::101, 2001:DB8:0:0:8:800:200C:417A ."; } leafmaskfqdn-string { typeyang:hex-string; default 00:00:00:00;inet:domain-name; description"mask value 0x00000000";}"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.)."; }container spd-lifetime-hardleaf rfc822-address-string { type string; description"SPD lifetime hard state data"; uses lifetime;"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.)."; } leafaction {type lifetime-action;dnX509 { type string; description"action lifetime";}"Specifies the identity as a distinguished name in the X.509 tradition."; }container spd-lifetime-softleaf id_key { type string; description"SPD lifetime hard state data"; uses lifetime;"Key id"; } leafaction {type lifetime-action;id_null { type empty; description"action lifetime";}"RFC 7619" ; } leaf user_fqdn { type string; description "User FQDN"; }// State data container spd-lifetime-current} leaf my-identifier {uses lifetime; config false;type string; mandatory true; description"SPD lifetime current state data";"id used for authentication"; } }/* grouping ipsec-policy-grouping *//*################ endSPD groupingPAD ##################*/ /*################## IKEv2-grouping ##################*/ groupingisakmp-proposalike-proposal { description"ISAKMP"IKEv2 proposal grouping";leaf phase1-lifetimecontainer ike-sa-lifetime-hard {type uint32; mandatory true;description"lifetime for IKE Phase 1 SAs";}"IKE SA lifetime hard"; uses ic:lifetime; } container ike-sa-lifetime-soft { description "IPsec SA lifetime soft"; uses ic:lifetime; leaf action {type ic:lifetime-action; description "Action lifetime";} } leaf-listphase1-authalgike-sa-authalg { typeintegrity-algorithm-t;ic:integrity-algorithm-t; description "Auth algorigthm for IKEPhase 1 SAs";}SA";} leaf-listphase1-encalgike-sa-encalg { typeencryption-algorithm-t;ic:encryption-algorithm-t; description "Auth algorigthm for IKEPhase 1SAs";} leafcombined-enc-intr { type boolean; description "Combined mode algorithms (encryption and integrity).";} leafdh_group { type uint32; mandatory true; description "Group number for Diffie Hellman Exponentiation";} leaf half-open-ike-sa-timer { type uint32; description "Set the half-open IKE SA timeout duration" ; } leaf half-open-ike-sa-cookie-threshold { type uint32; description "Number of half-open IKE SAs that activate the cookie mechanism." ; } }/* list isakmp-proposal */groupingphase2-infoike-child-sa-info { description"IKE Phase 2"IPsec SA Information"; leaf-listpfs_grouppfs_groups { typeuint32;pfs-group; description "If non-zero, require perfect forward secrecy when requesting new SA. The non-zero value is the required group number"; } containeripsec-sad-lifetime-hardchild-sa-lifetime-soft { description "IPsec SA lifetimehard";soft"; useslifetime;ic:lifetime; leaf action {typelifetime-action;ic:lifetime-action; description "action lifetime";} } containeripsec-sad-lifetime-softchild-sa-lifetime-hard { description "IPsec SA lifetimesoft"; uses lifetime; leafhard. The action{type lifetime-action; description "action lifetime";}will be to terminate the IPsec SA."; uses ic:lifetime; } }grouping local-grouping/*################## End IKEv2-grouping ##################*/ container ikev2 { description "Configure thelocal peer in an IKE connection";IKEv2 software"; containerlocalpad { description"Local container"; choice my-identifier-type { default ipv4; case ipv4"Configure Peer Authorization Database (PAD)"; list pad-entry { key "pad-entry-id"; ordered-by user; description "Peer Authorization Database (PAD)"; leafipv4pad-entry-id { typeinet:ipv4-address;uint64; description"IPv4 dotted-decimal address"; } } case ipv6 {"SAD index. ";} uses identity-grouping; leafipv6pad-auth-protocol { typeinet:ipv6-address;auth-protocol-type; description"numerical IPv6 address";"IKEv2, etc. ";} uses auth-method-grouping; } }case fqdnlist ike-conn-entry { key "conn-name"; description "IKE peer connection information"; leaffqdnconn-name { typeinet:domain-name;string; mandatory true; description"Fully Qualifed Domain name "; } } case dn"Name of IKE connection";} leaf autostartup { type type-autostartup; mandatory true; description "if True: automatically start tunnel at startup; else we do lazy tunnel setup based on trigger from datapath";} leaf initial-contact {type boolean; default false; description "This IKE SA is the only currently active between the authenticated identities";} leafdnversion { typestring;enumeration { enum ikev2 {value 2; description"Domain name";"IKE version 2";} } description "IKE version"; }case user_fqdn {leafuser_fqdnike-fragmentation { typestring;boolean; description"User FQDN"; }"Whether to use IKEv2 fragmentation as per RFC 7383 (TRUE or FALSE)"; } uses ike-proposal; container local { description "LocalID type"; }peer connection information"; leafmy-identifierlocal-pad-id { typestring; mandatory true;uint64; description"Local id used for authentication";} }" ";} }// local-grouping grouping remote-grouping { description "Configure the remote peer in an IKE connection";container remote { description "Remotecontainer"; choice my-identifier-type { default ipv4; case ipv4 {peer connection information"; leafipv4remote-pad-id { typeinet:ipv4-address;uint64; description"IPv4 dotted-decimal address"; }" ";} }case ipv6uses ic:encap; container spd {leaf ipv6description "Configure the Security Policy Database (SPD)"; list spd-entry {type inet:ipv6-address;key "spd-entry-id"; uses ic:ipsec-policy-grouping; ordered-by user; description"numerical IPv6 address";"List of SPD entries"; } }case fqdncontainer ike-sa-state { container uptime { description "IKE service uptime"; leaffqdnrunning { typeinet:domain-name;yang:date-and-time; description"Fully Qualifed Domain name "; } } case dn {"Relative uptime";} leafdnsince { typestring;yang:date-and-time; description"Domain name"; }"Absolute uptime";} }case user_fqdn {leafuser_fqdninitiator { typestring;boolean; description"User FQDN"; } }"It is acting as initiator in this connection";} leaf initiator-ikesa-spi {type uint64; description"Local ID type"; }"Initiator's IKE SA SPI";} leafmy-identifier { type string; mandatory true;responder-ikesa-spi {type uint64; description"Local id used for authentication"; } } } // remote-grouping /*################## End IKEv2-groupingUMU ##################*/ /*################# Register grouping #################*/ typedef sadb-msg-type { type enumeration { enum sadb_reserved {"Responsder's IKE SA SPI";} leaf nat-local {type boolean; description"SADB_RESERVED";} enum sadb_getspi {"YES, if local endpoint is behind a NAT";} leaf nat-remote {type boolean; description"SADB_GETSPI";} enum sadb_update {"YES, if remote endpoint is behind a NAT";} leaf nat-any {type boolean; description"SADB_UPDATE";} enum sadb_add {"YES, if both local and remote endpoints are behind a NAT";} uses ic:encap; leaf established {type uint64; description "Seconds the IKE SA has been established";} leaf rekey-time {type uint64; description"SADB_ADD";} enum sadb_delete {"Seconds before IKE SA gets rekeyed";} leaf reauth-time {type uint64; description"SADB_DELETE"; } enum sadb_get"Seconds before IKE SA gets re-authenticated";} list child-sas { container spis{ description"SADB_GET"; } enum sadb_acquire {"IPsec SA's SPI '"; leaf spi-in {type ic:ipsec-spi; description"SADB_ACQUIRE"; } enum sadb_register {"Security Parameter Index for inbound IPsec SA";} leaf spi-out {type ic:ipsec-spi; description"SADB_REGISTER";"Security Parameter Index for the corresponding outbound IPsec SA";} }enum sadb_expire {description"SADB_EXPIRE";"State data about IKE CHILD SAs"; }enum sadb_flush {config false; description"SADB_FLUSH";"IKE state data"; }enum sadb_dump { description "SADB_DUMP";/* ike-sa-state */ }enum sadb_x_promisc {/* ike-conn-entries */ container number-ike-sas{ leaf total {type uint32; description"SADB_X_PROMISC"; } enum sadb_x_pchange {"Total number of IKEv2 SAs";} leaf half-open {type uint32; description"SADB_X_PCHANGE"; } enum sadb_max{"Number of half-open IKEv2 SAs";} leaf half-open-cookies {type uint32; description"SADB_MAX"; } }"Number of half open IKE SAs with cookie activated" ;} config false; description"PF_KEY base message types";"Number of IKE SAs"; }typedef sadb-msg-satype { type enumeration { enum sadb_satype_unspec { description "SADB_SATYPE_UNSPEC";}enum sadb_satype_ah { description "SADB_SATYPE_AH";/* container ikev2 */ }enum sadb_satype_esp<CODE ENDS> Appendix C. Appendix C: YANG model for IKE-less case <CODE BEGINS> file "ietf-ipsec-ikeless@2019-03-11.yang" module ietf-ipsec-ikeless {description "SADB_SATYPE_ESP"; } enum sadb_satype_rsvpyang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless"; prefix "ipsec-ikeless"; import ietf-yang-types {description "SADB_SATYPE_RSVP";prefix yang; }enum sadb_satype_ospfv2import ietf-ipsec-common {description "SADB_SATYPE_OSPFv2";prefix ic; reference "Common Data model for SDN-based IPSec configuration"; }enum sadb_satype_ripv2 {organization "IETF I2NSF (Interface to Network Security Functions) Working Group"; contact " Rafael Marin Lopez Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 e-mail: rafa@um.es Gabriel Lopez Millan Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Tel: +34 868888504 email: gabilm@um.es Fernando Pereniguez Garcia Department of Sciences and Informatics University Defense Center (CUD), Spanish Air Force Academy, MDE-UPCT 30720 San Javier - Spain Tel: +34 968189946 email: fernando.pereniguez@cud.upct.es "; description"SADB_SATYPE_RIPv2"; } enum sadb_satype_mip"Data model for IKE-less case"; revision "2019-03-11" { description"SADB_SATYPE_MIP";"Revision"; reference ""; }enum sadb_satype_max/*################## SAD grouping ####################*/ grouping ipsec-sa-grouping { description"SADB_SATYPE_MAX"; } } description "PF_KEY"Configure Security Associationtypes"; } grouping base-grouping {(SA). Section 4.4.2.1 in RFC 4301"; leaf sad-entry-id {type uint64; description"Configuration for"This value identifies a specific entry in themessage header format"; list base-list { key "version";SAD";} leafversionspi { typestring;ic:ipsec-spi; description"Version of PF_KEY (MUST"Security Parameter Index. This may not bePF_KEY_V2)"; }unique for a particular SA";} leafmsg_typeseq-number { typesadb-msg-type;uint64; description"Identifies the type"Current sequence number ofmessage";IPsec packet."; } leafmsg_satypeseq-number-overflow-flag { typesadb-msg-satype;boolean; description"Defines"The flag indicating whether overflow of thetypesequence number counter should prevent transmission ofSecurity Association";additional packets on the SA, or whether rollover is permitted."; } leafmsg_seqanti-replay-window { typeuint32; description "Sequence number of this message.";uint16 { range "0 | 32..1024"; } description"Configuration for a specific message header format"; }"Anti replay window size"; }grouping algorithm-grouping { description "List of supported authentication and encryptation algorithms"; container algorithm-supported { description "lists of encryption and authentication algorithms"; list enc-algs { key "name";leafname { type encryption-algorithm-t;spd-entry-id {type uint64; description"Name of encryption algorithm"; }"This value links the SA with the SPD entry";} uses ic:selector-grouping; leafivlensecurity-protocol { typeuint8;ic:ipsec-protocol; description"Length"Security protocol ofthe initialization vector to be used for the algorithm";IPsec SA: Either AH or ESP."; }leaf min-bitscontainer sad-lifetime-hard {type uint16;description"The minimun acceptable key length, in bits";"SAD lifetime hard state data. The action associated is terminate."; uses ic:lifetime; }leaf max-bitscontainer sad-lifetime-soft {type uint16;description"The maximun acceptable key length, in bits"; }"SAD lifetime hard state data"; uses ic:lifetime; leaf action {type ic:lifetime-action; description"list of encryption algorithm supported ";"action lifetime";} }list auth-algs { key "name";leafnamemode { typeintegrity-algorithm-t;ic:ipsec-mode; description"Name of authentication algorithm";}"SA Mode"; } leafivlenstatefulfragCheck { typeuint8;boolean; description"Length of the initialization vector"Indicates whether (TRUE) or not (FALSE) stateful fragment checking (RFC 4301) applies tobe used for the algorithm";this SA."; } leafmin-bitsdscp { typeuint16;yang:hex-string; description"The minimun acceptable key length, in bits";"DSCP value"; } leafmax-bitspath-mtu { type uint16; description"The maximun acceptable key length, in bits"; } description "list"Maximum size ofauthentication algorithm supported "; } }an IPsec packet that can be transmitted without fragmentation"; }/*################# End Register grouping #################*/ /*################## ipsec ##################*/containerietf-ipsectunnel { when "../mode = 'TUNNEL'"; uses ic:tunnel-grouping; description"Main IPsec"Container for tunnel grouping"; } uses ic:encap; // STATE DATA for SA container";sad-lifetime-current { uses ic:lifetime; config false; description "SAD lifetime current state data"; } containerikev2stats {if-feature case1;// xfrm.h leaf replay-window {type uint32; default 0; description"Configure" "; } leaf replay {type uint32; default 0; description "packets detected out of theIKEv2";replay window and dropped because they are replay packets";} leaf failed {type uint32; default 0; description "packets detected out of the replay window ";} config false; description "SAD statistics"; } containerike-connectionreplay_state { // xfrm.h leaf seq {type uint32; default 0; description"IKE connections configuration"; list ike-conn-entries { key "conn-name";"input traffic sequence number when anti-replay-window != 0";} leaf oseq {type uint32; default 0; description"IKE peer connetion information";"output traffic sequence number";} leafconn-namebitmap {type uint32; default 0; description "";} config false; description "Anti-replay Sequence Number state"; } container replay_state_esn {type string; mandatory true;// xfrm.h leaf bmp-len {type uint32; default 0; description"Name of IKE connection";}"bitmap length for ESN"; } leafautostartuposeq { typetype-autostartup; mandatory true;uint32; default 0; description"if True: automatically start tunnel at startup; else we do lazy tunnel setup based on trigger from datapath";}"output traffic sequence number"; } leafnat-traversaloseq-hi { typeboolean;uint32; defaultfalse;0; description"Enable/Disable NAT traversal";""; } leafinitial-contactseq-hi { type uint32; default 0; description ""; } leaf replay-window {typeboolean;uint32; defaultfalse;0; description"This IKE SA is the only currently active between the authenticated identities";} container encap""; } leaf-list bmp {when "../nat-traversal = 'true'";type uint32; description"Encapsulation container"; leaf espencap"bitmaps for ESN (depends on bmp-len) "; } config false; description "Anti-replay Extended Sequence Number (ESN) state"; } } /*################## end SAD grouping ##################*/ /*################# Register grouping #################*/ typedef sadb-msg-type { typeesp-encap; description "ESP in TCP, ESP in UDP or ESP in TLS";} leaf sport {type inet:port-number;enumeration { enum sadb_acquire { description"Encapsulation source port";} leaf dport {type inet:port-number;"SADB_ACQUIRE"; } enum sadb_expire { description"Encapsulation destination port";"SADB_EXPIRE"; } }leaf oaddr {type inet:ip-address;description"Encapsulation Original Address ";}"Notifications (PF_KEY message types) that must be forwarded by the NSF to the controller in IKE-less case"; }leaf versiontypedef sadb-msg-satype { type enumeration { enumikev2 {value 2;sadb_satype_unspec { description"IKE version 2";}"SADB_SATYPE_UNSPEC"; } enum sadb_satype_ah { description"IKE version";"SADB_SATYPE_AH"; }uses isakmp-proposal; uses local-grouping; uses remote-grouping; uses phase2-info; container ike-stats { container uptimeenum sadb_satype_esp { description"IKE service uptime"; leaf running"SADB_SATYPE_ESP"; } enum sadb_satype_rsvp {type yang:date-and-time;description"Relative uptime";} leaf since"SADB_SATYPE_RSVP"; } enum sadb_satype_ospfv2 {type yang:date-and-time;description"Absolute uptime";}"SADB_SATYPE_OSPFv2"; }leaf initiatorenum sadb_satype_ripv2 {type boolean;description"It is acting as initiator in this connection";} leaf initiator-spi {type uint64;"SADB_SATYPE_RIPv2"; } enum sadb_satype_mip { description"Initiator's IKE SA SPI";} leaf responder-spi {type uint64;"SADB_SATYPE_MIP"; } enum sadb_satype_max { description"Responsder's IKE SA SPI";} leaf nat-local {type boolean;"SADB_SATYPE_MAX"; } } description"YES, if local endpoint is behind a NAT";} leaf nat-remote {type boolean;"PF_KEY Security Association types"; } grouping base-grouping { description"YES, if remote endpoint is behind a NAT";}"Configuration for the message header format"; list base-list { key "version"; leafnat-any {type boolean;version { type string; description"YES, if both local and remote endpoints are behind a NAT";}"Version of PF_KEY (MUST be PF_KEY_V2)"; } leafestablished {type uint64;msg_type { type sadb-msg-type; description"Seconds"Identifies theIKE SA has been established";}type of message"; } leafrekey-time {type uint64;msg_satype { type sadb-msg-satype; description"Seconds before IKE SA gets rekeyed";}"Defines the type of Security Association"; } leafreauth-time {type uint64; description "Seconds before IKE SA gets re-authenticated";} list child-sasmsg_seq {container spis{type uint32; description"IKE active SA's SPI '"; leaf spi-in {type ipsec-spi;"Sequence number of this message."; } description"Security Parameter Index"Configuration forInbounda specific message header format"; } } /*################# End Register grouping #################*/ /*################## IPsecSA";} leaf spi-out {type ipsec-spi;configuration ##################*/ container ietf-ipsec { description"Security Parameter Index for the corresponding outbound IPsec SA";} }"IPsec configuration"; container spd { description"State data about IKE CHILD SAs"; } config false;"Configure the Security Policy Database (SPD)"; list spd-entry { key "spd-entry-id"; uses ic:ipsec-policy-grouping; ordered-by user; description"IKE state data"; } /* ike-stats */"List of SPD entries"; }/* ike-conn-entries */}/*containerike-connection */sad { description "Configure the IPSec Security Association Database (SAD)"; list sad-entry { key "sad-entry-id"; uses ipsec-sa-grouping; containernumber-ike-sas{ leaf total {type uint32;ah-sa { when "../security-protocol = 'ah'"; description"Total number of IKEv2 SAs";}"Configure Authentication Header (AH) for SA"; container integrity { description "Configure integrity for IPSec Authentication Header (AH)"; leafhalf-open {type uint32;integrity-algorithm { type ic:integrity-algorithm-t; description"Total number of half-open IKEv2 SAs";} config false;"Configure Authentication Header (AH)."; } leaf key { type string; description"Number of IKE SAs";"AH key value";} } }/*containerikev2 */ container ipsecesp-sa { when "../security-protocol = 'esp'"; description"Configuration IPsec";"Set IPSec Encapsulation Security Payload (ESP)"; containerspdencryption { description "Configurethe Security Policy Database (SPD)"; list spd-entryencryption for IPSec Encapsulation Secutiry Payload (ESP)"; leaf encryption-algorithm {key "rule-number"; uses ipsec-policy-grouping; ordered-by user;type ic:encryption-algorithm-t; description"List of SPD entries"; }"Configure ESP encryption"; }container sadleaf key { type yang:hex-string; description"Configure the IPSec Security Association Database (SAD)"; list sad-entry {"ESP encryption key"spi"; uses ipsec-sa-grouping;value";} leaf iv {type yang:hex-string; description"List of SAD entries";"ESP encryption IV value"; } } containerpadintegrity {if-feature case1;description "ConfigurePeer Authorization Database (PAD)"; list pad-entriesauthentication for IPSec Encapsulation Secutiry Payload (ESP)"; leaf integrity-algorithm {key "pad-entry-id"; ordered-by user;type ic:integrity-algorithm-t; description"Peer Authorization Database (PAD)";"Configure Authentication Header (AH)."; } leafpad-entry-idkey { typeuint64;yang:hex-string; description"SAD index. ";} uses identity-grouping;"ESP integrity key value";} } /* With AEAD algorithms, the integrity node is not used */ leafpad-auth-protocolcombined-enc-intr { typeauth-protocol-type;boolean; description"IKEv1, IKEv2, KINK, etc. ";} uses auth-method-grouping;"ESP combined mode algorithms. The algorithm is specified in encryption-algorithm";} } description "List of SAD entries"; } } } /* container ietf-ipsec */ /*################## RPC and Notifications ##################*//* Note: not yet completed *///ThoseThese RPCs are needed by a Security Controller in IKEless case2 */ 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; } }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 { description "A IPsec SA is required "; uses base-grouping; uses ic:selector-grouping; // To indicate the concrete traffic selector of the policy that triggered this acquire. } notification sadb_expire { description "A IPsec SA expiration (soft or hard)"; uses base-grouping; leaf spi { typeipsec-spi;ic:ipsec-spi; description "Security Parameter Index";} leaf anti-replay-window { type uint16 { range "0 | 32..1024"; } description "Anti replay window"; } leafstate {type sa-state; description "current state of SA (mature, larval, dying or dead)"; } leafencryption-algorithm { typeencryption-algorithm-t;ic:encryption-algorithm-t; description "encryption algorithm of the expired SA"; } leaf authentication-algorithm { typeintegrity-algorithm-t;ic:integrity-algorithm-t; description "authentication algorithm of the expired SA"; } container sad-lifetime-hard { description "SAD lifetime hard state data"; useslifetime;ic:lifetime; } container sad-lifetime-soft { description "SAD lifetimehardsoft state data"; useslifetime;ic:lifetime; } container sad-lifetime-current { description "SAD lifetime current state data"; useslifetime;ic:lifetime; } } notification sadb_bad-spi { description".....";"Notifiy when the NSF receives a packet with an incorrect SPI (i.e. not present in the SAD)"; leaf state { typeipsec-spi;ic:ipsec-spi; mandatory "true"; description"Notify when a SPI"; }"SPI number contained in the erroneous IPsec packet"; } }/*module}/*module ietf-ipsec*/ <CODE ENDS> Authors' Addresses Rafa Marin-Lopez University of Murcia Campus de Espinardo S/N, Faculty of Computer Science Murcia 30100 Spain Phone: +34 868 88 85 01 EMail: rafa@um.es Gabriel Lopez-Millan University of Murcia Campus de Espinardo S/N, Faculty of Computer Science Murcia 30100 Spain Phone: +34 868 88 85 04 EMail: gabilm@um.es Fernando Pereniguez-Garcia University Defense Center Spanish Air Force Academy, MDE-UPCT San Javier (Murcia) 30720 Spain Phone: +34 968 18 99 46 EMail: fernando.pereniguez@cud.upct.es