I2NSF R. Marin-Lopez Internet-Draft G. Lopez-Millan Intended status: Standards Track University of Murcia Expires:September 12, 2019January 8, 2020 F. Pereniguez-Garcia University Defense CenterMarch 11,July 7, 2019 Software-Defined Networking (SDN)-based IPsec Flow Protectiondraft-ietf-i2nsf-sdn-ipsec-flow-protection-04draft-ietf-i2nsf-sdn-ipsec-flow-protection-05 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 networkresources with IPsec.resources. The document focusesinon the NSF Facing Interface by providing models forConfigurationconfiguration andStatestate datamodelrequired to allow the Security Controller to configure the IPsec databases (SPD, SAD, PAD) and IKEv2 to establishsecurity associationsSecurity 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 onSeptember 12, 2019.January 8, 2020. Copyright Notice Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . . .45 4. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. SDN-based IPsec management description . . . . . . . . . . . 6 5.1. IKE case: IKE/IPsec in the NSF . . . . . . . . . . . . . 6 5.1.1. Interface Requirements for IKE case . . . . . . . . . 7 5.2. IKE-less case: IPsec (no IKEv2) in theNSFNSF. . . . . . . .87 5.2.1. Interface Requirements for IKE-less case . . . . . . 8 5.3. IKE case vs IKE-less case . . . . . . . . . . . . . . . . 9 5.3.1. Rekeyingprocessprocess. . . . . . . . . . . . . . . . . . . 10 5.3.2. NSF statelossloss. . . . . . . . . . . . . . . . . . . . 11 5.3.3. NAT Traversal . . . . . . . . . . . . . . . . . . . . 12 5.3.4. NSF Discovery . . . . . . . . . . . . . . . . . . . . 12 6. YANG configuration data models . . . . . . . . . . . . . . .1213 6.1. IKE case model . . . . . . . . . . . . . . . . . . . . . 13 6.2. IKE-less case model . . . . . . . . . . . . . . . . . . . 16 7. Use cases examples . . . . . . . . . . . . . . . . . . . . .2120 7.1. Host-to-host or gateway-to-gateway under the samecontroller . . . .Security Controller . . . . . . . . . . . . . . . . . . .2120 7.2. Host-to-host or gateway-to-gateway under differentsecurity controllersSecurity Controllers . . . . . . . . . . . . . . . . . .2322 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 9. Security Considerations . . . . . . . . . . . . . . . . . . . 258.1.9.1. IKE case . . . . . . . . . . . . . . . . . . . . . . . .26 8.2.25 9.2. IKE-less case . . . . . . . . . . . . . . . . . . . . . . 269.10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . .27 10.26 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 2710.1.11.1. Normative References . . . . . . . . . . . . . . . . . . 2710.2.11.2. Informative References . . . . . . . . . . . . . . . . .2827 Appendix A. Appendix A: Common YANG model for IKE andIKElessIKE-less cases . . . . . . . . . . . . . . . . . . . . . . .3130 Appendix B. Appendix B: YANG model for IKE case . . . . . . . .3743 Appendix C. Appendix C: YANG model for IKE-less case . . . . . .4362 Appendix D. Example of IKE case, tunnel mode (gateway-to- gateway) with X.509 certificate authentication. . . 72 Appendix E. Example of IKE-less case, transport mode (host-to- host). . . . . . . . . . . . . . . . . . . . . . . . 75 Appendix F. Examples of notifications. . . . . . . . . . . . . . 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .4981 1. Introduction Software-Defined Networking (SDN) is an architecture that enables users to directly program, orchestrate, control and manage network resources through software. The SDN paradigm relocates the control of network resources to a dedicated network element, namely SDNcontroller.Controller. The SDN controller (or Security Controller in the context of this document) 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].[RFC7149] [ITU-T.Y.3300] [ONF-SDN-Architecture] [ONF-OpenFlow]. Recently, several network scenarios are considering a centralized way of managing different security aspects. For example, Software- Defined WANs(SD-WAN) advocates(SD-WAN), an SDN extension providing a software abstraction tomanagecreate secure network overlays over traditional WAN and branch networks. SD-WAN is based on IPsecSAsas underlying security protocol and aims to provide flexible, automated, fast deployment and on-demand security network services such as IPsec SA management 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 SAs management followingathe SDN paradigm.An example of usage can beIPsec architecture [RFC4301] defines clear separation between thenotion of Software Defined WAN (SD- WAN), SDN extension providing a software abstractionprocessing tocreate 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 provideprovide security services to IP packets and the key management procedures to establish the IPsecsecurity associations.Security Associations. In this document, we define a service where the key management procedures can be carried by an external and centralized 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 thecontroller.Security 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, IKE case requires the provision of SPD and PADentries andentries, the IKE credential and information related with the IKE negotiation (e.g.IKE_SA_INIT), andIKE_SA_INIT). IKE-less case requires the management of SPD and SAD entries. Based on YANG models in [netconf-vpn] and [I-D.tran-ipsecme-yang], RFC 4301 [RFC4301] and RFC 7296[RFC7296][RFC7296], this document defines the required interfaces with a YANG model for configuration and state data for IKE, PAD, SPD and SAD (see Appendix A, Appendix B and Appendix C). Examples of the usage of these models can found in Appendix D, Appendix E and Appendix F. 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 is out of scope of this document.In these cases,host orhosts, 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: ThisThe analysis of the host-to-gateway (roadwarrior) scenario is out of scope of this document. Finally, this work pays attention to the challenge "Lack of Mechanism for Dynamic Key Distribution to NSFs" defined in [RFC8192] in the particular case of the establishment and management of IPsec SAs. Infact, thisfact,this I-D could be considered as a proper use case for this particular challenge in [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 management componentAn entity 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 documentfallsfall 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)v2v2. Protocol to establish IPsec Security Associations (SAs). It requires information about the required authentication method (i.e. raw RSA/ECDSA keys or X.509 certificates),DHDiffie-Hellman (DH) groups,modesIPsec SAs parameters and algorithms for IKE SA negotiation, etc. o Security Policy Database (SPD). It includes information about IPsec policies direction (in, out), local and remoteaddresses,addresses (traffic selectors information), inbound and outboud IPsec 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 IP flows. o Peer Authorization Database (PAD). It provides the link between the SPD and a security association managementprotocol such as IKE orprotocol. It is used when theSDN-based solution described in this document.NSF deploys IKE implementation (IKE case). 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 central point, in order to protect specific data flows. o To define the interfaces required to manage and monitor the IPsec Security Associations (SA) in the NSF from a Security Controller. YANG models are defined for configuration and state data for IPsec management. 5. SDN-based IPsec management description As mentioned in Section 1, two cases areconsidered:considered, depending on whether the NSF ships an IKEv2 implementation or not: IKE case and IKE-less case. 5.1. IKE case: IKE/IPsec in the NSF In this case the NSF ships an IKEv2 implementation besides the IPsec support. The Security Controller is in charge of managing and applyingSPD and PAD entries (derivingIPsec connection information (determining which nodes need to start an IKE/IPsec session, 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)cryptographic algorithms for establishing an IKE SA) 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 Facing Interface, [RFC8192]), and the Security Controller translatesthosethese 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<->|-------------------------------------------| 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: IKE case: IKE/IPsec in the NSF 5.1.1. Interface Requirements for IKE case SDN-based IPsec flow protection services provide dynamic and flexible management of IPsec SAs in flow-basedNSF.NSFs. In order to support this capability incaseIKE case, the following interface requirementsareneed to be met: o A YANG data model forconfiguration data forIKEv2, SPD andPAD. o A YANG data modelPAD configuration data, and for IKE statedata for IKE, PAD, SPD and SAD (NOTE: the SAD entries are created in runtime by IKEv2.)data. o In scenarios where multiplecontrollersSecurity 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 differentcontrollerscontrollers, then both Security Controllers need to exchange information to properly configure their owngateways.NSFs. That is, the may need to agree on whether IKEv2 authentication will be based on raw publickeys orkeys, pre-sharedkeys.keys, etc. In case of using pre-shared keys they will have to agree in the PSK. 5.2. IKE-less case: IPsec (no IKEv2) in theNSFNSF. In this case, the NSF does not deploy IKEv2 and, therefore, the Security Controller has to perform the IKE security functions and management of IPsec SAs by populating and managing the SPD and the SAD. +-----------------------------------------+ | IPsec Management Application | Client or | I2NSF Client | App Gateway +-----------------------------------------+ | Client Facing Interface +-----------------------------------------+ Vendor| Application Support | Facing<->|-----------------------------------------| Security Interface| SPD, SAD and PAD Entries Distr. | Controller +-----------------------------------------+ | NSF Facing Interface +-----------------------------------------+ | I2NSF Agent | Network |-----------------------------------------| Security | IPsec (SPD,SAD) | Function (NSF) |-----------------------------------------| | Data Protection and Forwarding | +-----------------------------------------+ Figure 2: IKE-less case: IPsec (no IKE) in the NSF 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 translatesthosethese requirements into SPD and SAD entries, which are installed in the NSF. PAD entries are not required since there is no IKEv2 in the NSF. 5.2.1. Interface Requirements for IKE-less case In order to support the IKE-less case, the following requirementsareneed to be met: o A YANG data model for configuration data for SPD andSAD. o A YANG data modelSAD and for state data forSPD andSAD. 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 exchange IPsec- related information. NOTE: A possible east-west protocol for this IKE-less case could be IKEv2. However, this needs to be explore since the IKEv2 peers would be the Security Controllers. Specifically, the IKE-less case assumes that the SDN controller has to perform some security functions that IKEv2 typically does, namely (non-exhaustive): o IV generation. opreventPrevent counter resets for the same key. o Generation of pseudo-random cryptographic keys for the IPsec SAs. o Rekey of the IPsec SAs based onnotificationnotifications from the NSF (i.e. expire). o Generation of the IPsec SAs when required based on notifications (i.e.sadb_acquire).sadb-acquire) from the NSF. o NAT Traversal discovery and management. Additionally to these functions, another set of tasks must be performed by the Security Controller (non-exhaustive list): o IPsec SA's SPI random generation. o Cryptographic algorithm/s selection. o Usage of extended sequence numbers. o Establishment of proper traffic selectors. 5.3. IKE case vs IKE-less case In principle, IKE caseMAY beis easier to deploy than IKE-less case because current gateways typically have an IKEv2/IPsec implementation. Moreover hosts can install easily an IKE implementation. As downside, the NSF needs more resources to hold IKEv2. Moreover, the IKEv2 implementation needs to implement an internal interface so that theI2NSF AgentIKE configuration sent by the Security Controller caninteract with them.be enforced in runtime. Alternatively, IKE-less case allows lighter NSFs (no IKEv2 implementation), which benefits the deployment in constrained NSFs. Moreover, IKEv2 does not need to be performed in gateway-to-gateway and host-to-host scenarios under the same Security Controller (see Section 7.1). On the contrary, the overload of creating fresh IPsec SAs is shifted to the Security Controller since IKEv2 is not in the NSF. As a consequence, this may result in a more complex implementation in the controller side. This overload may create some scalability issues when the number of NSFs is high. In general, literature around SDN-based network management using a centralizedSDN controllerSecurity Controller is aware about scalability issues and solutions have been already provided (e.g. hierarchicalSDN controllers;Security Controllers; having multiple replicatedSDN controllers,Security Controllers, etc). In the context of SDN-based IPsec management, one straight way to reduce the overhead and the potential scalability issue in the Security Controller is to apply the IKEcase,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. Otheroption with IKE-less is to use techniques already seen in SDN world such as, for example, hierarchical SDN controllers. Othersolutions, such asController- IKEController-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. Are-keyrekey 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 Section8.9. The main reason is that theSecurity Controller is not able to observe anyNSFs are generating the session keysgenerated for the IPsec SAs because IKEv2 is in charge of negotiatingand not theIPsec SAs.Security Controller. 5.3.1. Rekeyingprocessprocess. For IKE case, the rekeying process is carried out by IKEv2, following the information defined in the SPD and SAD. Therefore, connections will live unless something different is required by the administrator or the Security Controller detects something wrong. Traditionally, during a rekey process of the IPSec SA using IKE, a bundle of inbound and outbound IPsec SAs is taken into account from the perspective of one of the NSFs. For example, if the inbound IPsec SA expires both the inbound and outbound IPsec SA are rekeyed at the same time in that NSF. However, when IKE is not used, we have followed a different approach to avoid any packet loss during rekey: the Security Controller installs first the new inbound SAs in both NSFs and then, the outbound IPsec SAs. In other words, for the IKE-less case, the Security Controller needs to take care of the rekeying process. When the IPsec SA is going to expire (e.g. IPsec SA soft lifetime), it has to create a new IPsec SA and remove the old one. This rekeying process starts when the Security Controller receives asadb_expiresadb-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 IPsec SA inAA, and SPIb1 the inbound IPsec SA in B. 1. The Security Controller chooses two random values as SPI for the new inbound IPsec SAs: for example, SPIa2 for A and SPIb2 for B. These numbers MUST not be in conflict with any IPsec SA in A or B. Then, the Security Controller creates an inbound IPsec SA with SPIa2 in A and another inbound IPsec SA in B with SPIb2. It can send this information simultaneously to A and B. 2. Once the Security Controller receives confirmation from A and B, the controller knows that the inboundSAIPsec A are correctly installed. Then it proceeds to send in parallel to A andBB, the outbound IPsec SAs: it sends the outbound IPsec SA to A with SPIb2 and the outbound IPsec SA to B with SPIa2. At this point the new IPsecSA isSAs are ready. 3. Once the Security Controller receives confirmation from A andB,B that the outbound IPsec SAs have been installed, the SecurityControllerController, in parallel, deletes the old IPsec SAs from A (inbound SPIa1 and outbound SPIb1) and B (outbound SPIa1 and inboundSPIb1) in parallel. It is worth noting that if the IPsec implementation can itself detect traffic on the new IPsec SA, and it can delete the old IPsec SA itself without instruction from the Security Controller, then this step 3 is not required.SPIb1). 5.3.2. NSF statelossloss. 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 in the IKE case, and SPD and SAD information in IKE-less case. In both cases, the Security Controller is aware of the affected NSF (e.g. the NETCONF/TCP connection is broken with the affected NSF, the Security Controller is receivingsadb_bad-spisadb-bad-spi notification from a particular NSF, etc.). Moreover, the Security Controller has a register about all the NSFs that have IPsec SAs with the affected NSF. Therefore, it knows the affected IPsec SAs. In IKE case, the Security Controller will configure the affected NSF with the new IKEv2, SPD and PAD information. It has also to send new parameters (e.g. a new fresh PSK for authentication) to the NSFs which have IKEv2 SAs and IPsec SAs with the affected NSF.It can also instruct the affected NSF to send IKEv2 INITIAL_CONTACT.Finally, the Security Controller will instruct the affected NSF to start the IKEv2 negotiation with the new configuration. In IKE-less case, if the Security Controller detects that a NSF has lost the IPsec SAs(e.g. it reboots)it will delete the old IPsec SAsofon the non-failednodesnodes, established with the failed node (step 1). This prevents the non-failed nodes from leaking plaintext. If thefailedaffected node comes to live, the Security Controller will configure the new inbound IPsec SAs between thefailedaffected node and all the nodesthe failedit was talking to (step 2). After these inbound IPsec SAs have been established, the Security Controller can configure the outbound IPsec SAs in parallel (step 3). Nevertheless other more optimized options can be considered (e.g. making the IKEv2 configuration permanent between reboots). 5.3.3. NAT Traversal In the IKE case, IKEv2 alreadyownsprovides 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 encapsulationoffor ESP packets ([RFC3948], [RFC8229]). Note that the usage ofTRANSPORTIPsec transport mode when NAT is requiredis forbiddenMUST NOT be used in this specification. On the contrary, the IKE-less case does 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 networkit controls.under its control. This view is built either requesting information to the NSFs under its control, or because these NSFs informtothe 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.ietf-opsawg-nat-yang] a data model for NAT management. The Security Controller can use this NETCONF module with agatewayNSF to collect NAT information or even configure aNAT.NAT network. In any case, if this NETCONF module is not available in the NSF and the Security Controllercannotdoes not have a mechanism to knowifwhether a host is behind a NAT or not, then the IKE case should be the right choice and not theIKE-less.IKE-less case. 5.3.4. NSF Discovery The assumption in this document is that, for both cases, before a NSF can operate in this system, it MUST be registered in the Security Controller. In this way, when the NSF comes to live and establishes a connection to the Security Controller, it knows that the NSF is valid for joining the system. Either during this registration process or when the NSF connects with the Security Controller, the Security Controller MUST discover certain capabilities of this NSF, such as what is the cryptographic suite supported, authentication method, the support of the IKE case or the IKE-less case, etc. This discovery process is out of the scope of this document. 6. YANG configuration data models In order to support the IKEcaseand IKE-lesscasecases we havemodelledmodeled the different parameters and values that must be configured to manage IPsec SAs. Specifically, IKE requires modeling IKEv2, SPD andPADPAD, while IKE-less case requires configuration models for the SPD and SAD. We have defined three models: ietf-ipsec-common (Appendix A), ietf-ipsec-ike (Appendix B, IKE case), ietf-ipsec-ikeless (Appendix C, IKE-less case). Since the model ietf-ipsec-common has only typedef and groupings common to the other modules,in the followingwe only show a simplified view of the ietf-ipsec-ike and ietf-ipsec-ikeless models. 6.1. IKE case model The model related to IKEv2 has been extracted from reading IKEv2 standard in [RFC7296], and observing some open source implementations, such as Strongswan [strongswan] orLibreswan.Libreswan [libreswan]. The definition of the PAD model has been extracted from the specification in section 4.4.3 in [RFC4301] (NOTE: We have observed that many implementations integrate PAD configuration as part of the IKEv2configuration.)configuration). module: ietf-ipsec-ike +--rwikev2ipsec-ike +--rw pad | +--rw pad-entry*[pad-entry-id][name] | +--rwpad-entry-id uint64name string | +--rw(identity)?(identity) | | +--:(ipv4-address) | | | +--rw ipv4-address? inet:ipv4-address | | +--:(ipv6-address) | | | +--rw ipv6-address? inet:ipv6-address | | +--:(fqdn-string) | | | +--rw fqdn-string? inet:domain-name | | +--:(rfc822-address-string) | | | +--rw rfc822-address-string? string | |+--:(dnX509)+--:(dnx509) | | | +--rwdnX509?dnx509? string | |+--:(id_key)+--:(gnx509) | | | +--rwid_key?gnx509? string | |+--:(id_null)+--:(id-key) | | | +--rwid_null? empty |id-key? string |+--:(user_fqdn)| +--:(id-null) |+--rw user_fqdn? string| +--rwmy-identifier stringid-null? empty | +--rwpad-auth-protocol?auth-protocol? auth-protocol-type | +--rwauth-methodpeer-authentication | +--rwauth-m?auth-method? auth-method-type | +--rw eap-method | | +--rweap-type?eap-type uint8 | +--rw pre-shared | | +--rw secret? yang:hex-string | +--rw digital-signature | +--rw ds-algorithm?signature-algorithm-tuint8 | +--rwraw-public-key? yang:hex-string(public-key) |+--rw key-data? string|+--rw key-file? string+--:(raw-public-key) | |+--rw ca-data* string| +--rwca-file? stringraw-public-key? binary | | +--:(cert-data) | | +--rw cert-data?stringct:x509 | +--rwcert-file? stringprivate-key? binary | +--rw ca-data* ct:x509 | +--rw crl-data?stringct:crl | +--rwcrl-file? stringcrl-uri? inet:uri | +--rw oscp-uri? inet:uri +--rwike-conn-entry* [conn-name]conn-entry* [name] | +--rwconn-namename string | +--rwautostartup type-autostartupautostartup? autostartup-type | +--rw initial-contact? boolean | +--rw version?enumerationauth-protocol-type | +--rwike-fragmentation?fragmentation? boolean | +--rwike-sa-lifetime-hard | | +--rw time? yang:timestamp | | +--rw idle? yang:timestampike-sa-lifetime-soft | | +--rwbytes?rekey-time? uint32 | | +--rwpackets?reauth-time? uint32 | +--rwike-sa-lifetime-soft | | +--rw time? yang:timestamp | | +--rw idle? yang:timestamp | | +--rw bytes? uint32ike-sa-lifetime-hard | | +--rwpackets?over-time? uint32 || +--rw action? ic:lifetime-action |+--rwike-sa-authalg* ic:integrity-algorithm-tauthalg* ic:integrity-algorithm-type | +--rwike-sa-encalg* ic:encryption-algorithm-tencalg* ic:encryption-algorithm-type | +--rwdh_group uint32dh-group? pfs-group | +--rw half-open-ike-sa-timer? uint32 | +--rw half-open-ike-sa-cookie-threshold? uint32 | +--rw local | | +--rwlocal-pad-id? uint64local-pad-entry-name? string | +--rw remote | | +--rwremote-pad-id? uint64remote-pad-entry-name? string | +--rw encapsulation-type | | +--rw espencap? esp-encap | | +--rw sport? inet:port-number | | +--rw dport? inet:port-number | | +--rw oaddr* inet:ip-address | +--rw spd | | +--rw spd-entry*[spd-entry-id] | | +--rw spd-entry-id uint64 | | +--rw priority? uint32 | | +--rw anti-replay-window? uint16 | | +--rw names*[name] | || +--rw name-type? ipsec-spd-name | | |+--rw name string | | +--rwcondition | | | +--rw traffic-selector-list* [ts-number] |ipsec-policy-config | | +--rwts-number uint32 |anti-replay-window? uint64 | | +--rwdirection? ipsec-traffic-directiontraffic-selector | | | +--rwlocal-subnet?local-subnet inet:ip-prefix | | | +--rwremote-subnet?remote-subnet inet:ip-prefix | | | +--rwupper-layer-protocol* ipsec-upper-layer-protoinner-protocol? ipsec-inner-protocol | | | +--rw local-ports* [start end] | | | | +--rw start inet:port-number | | | | +--rw end inet:port-number | | | +--rw remote-ports* [start end] | | | +--rw start inet:port-number | | | +--rw end inet:port-number | | +--rw processing-info | | | +--rwaction ipsec-spd-operationaction? ipsec-spd-action | | | +--rw ipsec-sa-cfg | | | +--rw pfp-flag? boolean | | | +--rwextSeqNum?ext-seq-num? boolean | | | +--rwseqOverflow?seq-overflow? boolean | | | +--rwstatefulfragCheck?stateful-frag-check? boolean | | | +--rwsecurity-protocol? ipsec-protocolmode? ipsec-mode | | | +--rwmode? ipsec-mode | | | +--rw ah-algorithms | | | | +--rw ah-algorithm* integrity-algorithm-t | | | | +--rw trunc-length? uint32protocol-parameters? ipsec-protocol-parameters | | | +--rw esp-algorithms | | | | +--rwauthentication* integrity-algorithm-tintegrity* integrity-algorithm-type | | | | +--rw encryption*encryption-algorithm-tencryption-algorithm-type | | | | +--rwtfc_pad? uint32tfc-pad? boolean | | | +--rw tunnel | | | +--rwlocal?local inet:ip-address | | | +--rwremote?remote inet:ip-address | | | +--rwbypass-df? booleandf-bit? enumeration | | | +--rw bypass-dscp? boolean | | | +--rw dscp-mapping? yang:hex-string | | | +--rw ecn? boolean | | +--rwspd-lifetime-soft | | | +--rw time? yang:timestamp | | | +--rw idle? yang:timestamp |spd-mark | | +--rwbytes?mark? uint32 | ||+--rwpackets? uint32mask? yang:hex-string | +--rw child-sa-info | | +--rwaction? lifetime-actionpfs-groups* pfs-group | | +--rwspd-lifetime-hardchild-sa-lifetime-soft | | | +--rw time?yang:timestampuint32 | | | +--rwidle? yang:timestampbytes? uint32 | | | +--rwbytes?packets? uint32 | | | +--rwpackets?idle? uint32 | |+--ro spd-lifetime-current| +--rw action? ic:lifetime-action |+--ro time? yang:timestamp| +--rw child-sa-lifetime-hard |+--ro idle? yang:timestamp| +--rw time? uint32 | |+--ro+--rw bytes? uint32 | |+--ro+--rw packets? uint32 |+--ro ike-sa-state | +--ro uptime | | +--ro running? yang:date-and-time| +--rw idle? uint32 | +--rosince? yang:date-and-timestate | +--ro initiator? boolean | +--ro initiator-ikesa-spi?uint64ike-spi | +--ro responder-ikesa-spi?uint64ike-spi | +--ro nat-local? boolean | +--ro nat-remote? boolean | +--ronat-any? booleanencapsulation-type | | +--ro espencap? esp-encap | | +--ro sport? inet:port-number | | +--ro dport? inet:port-number | | +--ro oaddr* inet:ip-address | +--ro established? uint64 | +--rorekey-time?current-rekey-time? uint64 | +--roreauth-time?current-reauth-time? uint64| +--ro child-sas* [] | +--ro spis | +--ro spi-in? ic:ipsec-spi | +--ro spi-out? ic:ipsec-spi+--ro number-ike-sas +--ro total?uint32uint64 +--ro half-open?uint32uint64 +--ro half-open-cookies?uint32uint64 Appendix D shows an example of IKE case configuration for a NSF, in tunnel mode (gateway-to-gateway), with NSFs authentication based on X.509 certificates. 6.2. IKE-less case modelTheFor this case, the definition of the SPD model has been mainly extracted from the specification in section 4.4.1 and Appendix D in[RFC4301]. Unlike existing implementations (e.g. XFRM), it is worth mentioning that this model follows [RFC4301] and, consequently,[RFC4301], though with some simplications. For example, each IPsec policy(spd- entry) consists of(spd-entry) contains oneor moretrafficselectors.selector, instead a list of them. The reason is that we have observed real kernel implementations only admit a traffic selector per IPsec policy. The definition of the SAD model has been extracted from the specification in section 4.4.2 in [RFC4301]. Note that this model not onlyassociatesallows to associate an IPsec SA with its corresponding policy(spd- entry-id) but also indicatesthrough the specific traffic selectorthat caused its establishment. In other words, each traffic selector of a policy (spd-entry) generates a different IPsec SA (sad-entry).but also an identifier (reqid). The notifications model has been defined using as reference the PF_KEYv2 standard in [RFC2367]. module: ietf-ipsec-ikeless +--rwietf-ipsecipsec-ikeless +--rw spd | +--rw spd-entry*[spd-entry-id] | +--rw spd-entry-id uint64 | +--rw priority? uint32 | +--rw anti-replay-window? uint16 | +--rw names*[name] || +--rw name-type? ipsec-spd-name | |+--rw name string | +--rwcondition |direction? ic:ipsec-traffic-direction | +--rwtraffic-selector-list* [ts-number] |reqid? uint64 | +--rwts-number uint32ipsec-policy-config | +--rw anti-replay-window? uint64 | +--rwdirection? ipsec-traffic-directiontraffic-selector | | +--rwlocal-subnet?local-subnet inet:ip-prefix | | +--rwremote-subnet?remote-subnet inet:ip-prefix | | +--rwupper-layer-protocol* ipsec-upper-layer-protoinner-protocol? ipsec-inner-protocol | | +--rw local-ports* [start end] | | | +--rw start inet:port-number | | | +--rw end inet:port-number | | +--rw remote-ports* [start end] | | +--rw start inet:port-number | | +--rw end inet:port-number | +--rw processing-info | | +--rwaction ipsec-spd-operationaction? ipsec-spd-action | | +--rw ipsec-sa-cfg | | +--rw pfp-flag? boolean | | +--rwextSeqNum?ext-seq-num? boolean | | +--rwseqOverflow?seq-overflow? boolean | | +--rwstatefulfragCheck?stateful-frag-check? boolean | | +--rwsecurity-protocol? ipsec-protocol | | +--rwmode? ipsec-mode | | +--rwah-algorithms | | | +--rw ah-algorithm* integrity-algorithm-t | | | +--rw trunc-length? uint32protocol-parameters? | | +--rw esp-algorithms | | | +--rwauthentication* integrity-algorithm-tintegrity* integrity-algorithm-type | | | +--rw encryption*encryption-algorithm-tencryption-algorithm-type | | | +--rwtfc_pad? uint32tfc-pad? boolean | | +--rw tunnel | | +--rwlocal?local inet:ip-address | | +--rwremote?remote inet:ip-address | | +--rwbypass-df? booleandf-bit? enumeration | | +--rw bypass-dscp? boolean | | +--rw dscp-mapping? yang:hex-string | | +--rw ecn? boolean | +--rwspd-lifetime-soft |spd-mark | +--rwtime? yang:timestamp |mark? uint32 | +--rwidle? yang:timestamp | |mask? yang:hex-string +--rwbytes? uint32 | | +--rw packets? uint32 | |sad +--rwaction? lifetime-action |sad-entry* [name] +--rwspd-lifetime-hard | |name string +--rwtime? yang:timestamp | |reqid? uint64 +--rwidle? yang:timestamp |ipsec-sa-config | +--rwbytes?spi uint32 ||+--rwpackets? uint32 | +--ro spd-lifetime-current | +--ro time? yang:timestamp | +--ro idle? yang:timestamp | +--ro bytes? uint32ext-seq-num? boolean |+--ro packets? uint32 +--rw sad +--rw sad-entry* [sad-entry-id] +--rw sad-entry-id uint64 +--rw spi? ic:ipsec-spi+--rwseq-number?seq-number-counter? uint64 | +--rwseq-number-overflow-flag?seq-overflow? boolean | +--rw anti-replay-window?uint16uint32 | +--rwspd-entry-id? uint64traffic-selector | | +--rwlocal-subnet?local-subnet inet:ip-prefix | | +--rwremote-subnet?remote-subnet inet:ip-prefix | | +--rwupper-layer-protocol* ipsec-upper-layer-protoinner-protocol? ipsec-inner-protocol | | +--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 | +--rwsecurity-protocol? ic:ipsec-protocolprotocol-parameters? ic:ipsec-protocol-parameters | +--rwsad-lifetime-hardmode? ic:ipsec-mode | +--rwtime? yang:timestampesp-sa | | +--rwidle? yang:timestampencryption | | | +--rw encryption-algorithm? ic:encryption-algorithm-type | | | +--rw key? yang:hex-string | | | +--rw iv? yang:hex-string | | +--rw integrity | | +--rw integrity-algorithm? ic:integrity-algorithm-type | | +--rw key? yang:hex-string | +--rw sa-lifetime-hard | | +--rw time? uint32 | | +--rw bytes? uint32 | | +--rw packets? uint32 | | +--rwsad-lifetime-softidle? uint32 | +--rwtime? yang:timestampsa-lifetime-soft | | +--rwidle? yang:timestamptime? uint32 | | +--rw bytes? uint32 | | +--rw packets? uint32 | | +--rw idle? uint32 | | +--rw action? ic:lifetime-action+--rw mode? ic:ipsec-mode +--rw statefulfragCheck? boolean +--rw dscp? yang:hex-string +--rw path-mtu? uint16| +--rw tunnel | | +--rwlocal?local inet:ip-address | | +--rwremote?remote inet:ip-address | | +--rwbypass-df? booleandf-bit? enumeration | | +--rw bypass-dscp? boolean | | +--rw dscp-mapping? yang:hex-string | | +--rw ecn? boolean | +--rw encapsulation-type | +--rw espencap? esp-encap | +--rw sport? inet:port-number | +--rw dport? inet:port-number | +--rw oaddr* inet:ip-address +--rosad-lifetime-current |ipsec-sa-state +--rotime? yang:timestampsa-lifetime-current | +--roidle? yang:timestamptime? uint32 | +--ro bytes? uint32 | +--ro packets? uint32+--ro stats| +--roreplay-window?idle? uint32|+--roreplay? uint32 |replay-stats +--ro replay-window? uint64 +--ro packet-dropped? uint64 +--ro failed? uint32 +--roreplay_stateseq-number-counter? uint64 notifications: +---n sadb-acquire | +--roseq? uint32ipsec-policy-name string | +--rooseq? uint32traffic-selector | +--robitmap? uint32 +--ro replay_state_esnlocal-subnet inet:ip-prefix | +--robmp-len? uint32remote-subnet inet:ip-prefix | +--rooseq? uint32inner-protocol? ipsec-inner-protocol | +--rooseq-hi? uint32local-ports* [start end] | | +--roseq-hi? uint32start inet:port-number | | +--roreplay-window? uint32end inet:port-number | +--robmp* uint32 +--rw ah-saremote-ports* [start end] |+--rw integrity+--ro start inet:port-number |+--rw integrity-algorithm? ic:integrity-algorithm-t+--ro end inet:port-number +---n sadb-expire |+--rw key?+--ro ipsec-sa-name 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?+--ro soft-lifetime-expire? booleannotifications: +---n spdb_expire| +--roindex? uint64 +---n sadb_acquire | +--ro base-list* [version] | | +--ro version string | | +--ro msg_type? sadb-msg-type | | +--ro msg_satype? sadb-msg-satype | | +--ro msg_seq? uint32 | +--ro local-subnet? inet:ip-prefix | +--ro remote-subnet? inet:ip-prefix | +--ro upper-layer-protocol* ipsec-upper-layer-proto | +--ro local-ports* [start end] | | +--ro start inet:port-number | | +--ro end inet:port-number | +--ro remote-ports* [start end] | +--ro start inet:port-number | +--ro end inet:port-number +---n sadb_expire | +--ro base-list* [version] | | +--ro version string | | +--ro msg_type? sadb-msg-type | | +--ro msg_satype? sadb-msg-satype | | +--ro msg_seq? uint32 | +--ro spi? ic:ipsec-spi | +--ro anti-replay-window? uint16 | +--ro encryption-algorithm? ic:encryption-algorithm-t | +--ro authentication-algorithm? ic:integrity-algorithm-t | +--ro sad-lifetime-hard |lifetime-current | +--ro time?yang:timestamp | | +--ro idle? yang:timestamp | | +--ro bytes? uint32 | | +--ro packets?uint32 | +--rosad-lifetime-soft | | +--ro time? yang:timestamp | | +--ro idle? yang:timestamp | | +--robytes? uint32 ||+--ro packets? uint32 | +--rosad-lifetime-current | +--ro time? yang:timestamp | +--roidle?yang:timestamp | +--ro bytes?uint32 +---n sadb-seq-overflow | +--ropackets? uint32ipsec-sa-name string +---nsadb_bad-spisadb-bad-spi +--rostate ic:ipsec-spispi uint32 Appendix E shows an example of IKE-less case configuration for a NSF, in transport mode (host-to-host), with NSFs authentication based on shared secrets. For the IKE-less case, Appendix F shows examples of IPsec SA expire, acquire, sequence number overflow and bad SPI notifications. 7. Use cases examples This section explains how different traditional configurations, that is, host-to-host andgateway-to-gatewaygateway-to-gateway, are deployed using this SDN- based IPsec management service. In turn, these configurations will be typical in modern networks where, for example, virtualization will be key. 7.1. Host-to-host or gateway-to-gateway under the samecontrollerSecurity 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-host / gateway-to-gateway singlecontroller flowSecurity Controller for the IKE case. Figure 3 describes thecaseIKE 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 an IKEv2 configuration that include the SPD and PAD entries in both NSF1 and NSF2. 4. The flow is protectedwithby means of the IPsec SA established with IKEv2. +----------------------------------------+ | (1) Security Controller | Flow-based | | Security -----------| | Policy | V | | +---------------+ (2)+-------------+ | | |Translate into |--->| South. Prot.| | | |IPsec policies | | | | | +---------------+ +-------------+ | | | | | | | | | +-------------------------| --- |--------+ | | | (3) | |----------------------+ +--| V V +------------------+ +------------------+ | NSF1 |<=====>| NSF2 | |IPsec(SPD/SAD) | 4) |IPsec(SPD/SAD) | +------------------+ +------------------+ Figure 4: Host-to-host / gateway-to-gateway singlecontroller flowSecurity Controller for IKE-less case. In the IKE-less case, flow-based security policies defined by the administrator are translated into IPsec SPD entries and inserted into the corresponding NSFs. Besides, fresh SAD entries will be also generated by the Security Controller and enforced in the NSFs. In this case, thecontrollerSecurity Controller does not run any IKEv2implementation,implementation (neither the NSFs), and it provides the cryptographic material for the IPsec SAs. These keys will be also distributed securely through the southbound interface. Note that this is possible because both NSFs are managed by the samecontroller.Security Controller. Figure 4 describes theIKE-less,IKE-less case, when a data packet needs to be protected in the path between the NSF1 and NSF2: 1. The administrator establishes the flow-based securitypolicies. Thepolicies, and the Security Controller looks for the involved NSFs. 2. The Security Controller translates the flow-based security policies into IPsec SPD and SAD entries. 3. The Security Controller insertsthethese entries in both NSF1 and NSF2 IPsec databases. It associates a lifetime to the IPsec SAs. When this lifetime expires, the NSF will send asadb_expiresadb-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), for example, within an enterpriseIt is also possible thatneeds to protectthetraffic between, for example,Security Controller only installs thenetworks of two branch offices. Applicability of these configurations appearSPD entries incurrent and new networking scenarios. Forstep 2. In such a case, when a data packet requires to be protected with IPsec, the NSF that saw first the data packet will send a sadb-acquire notification that informs the Security Controller that SAD entries with the IPsec SAs required to process the data packet needs to be installed in the NSFs. Both NSFs could be two hosts that exchange traffic and require to establish an end-to-end security association to protect their communications (host-to-host) or two gateways (gateway-to-gateway), for example, within an enterprise that needs to protect the traffic between the networks of two branch offices. Applicability of these configurations appear in current and new networking scenarios. For example, SD-WAN technologies are providing dynamic and on-demand VPN connections between branch offices, or between branches and SaaS cloud services. Beside, IaaS services providing virtualization environments are deployments solutions based on IPsec to provide secure channels between virtual instances (host- to-host) and providing VPN solutions for virtualized networks (gateway-to-gateway). In general (for IKE and IKE-lesscase),cases), this system has various advantages: 1. It allows to create IPsec SAs among two NSFs,withbased only on the application ofmoregeneralflow-based security policiesFlow-based Security Policies at the application layer. Thus, administrators can manage all security associations in a centralized point with an abstracted view of the network. 2.All NSFsAny NSF deployedafter the application ofin thenew policies are NOT manually configured,system does not need manual configuration, therefore allowing its deployment in an automated manner. 7.2. Host-to-host or gateway-to-gateway under differentsecurity controllersSecurity 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) | +----------------------+|IKEv2/IPsec(SPD/PAD)| |IKEv2/IPsec(SPD/PAD)| +--------------------+ (5)+----------------------++--------------------+ Figure 5: Differentsecurity controllersSecurity Controllers in the IKEcasecase. Figure 5 describes IKE case when 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 IKEv2credentials andcredentials, 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| <---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) | +------------------+ +------------------+|IPsec(SPD/SAD)| |IPsec(SPD/SAD)| +--------------+ +--------------+ Figure 6: Differentsecurity controllersSecurity Controllers in the IKE-lesscasecase. Figure56 describes IKE-less case when 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 controllerit notices that NSF2 is under the control of another SecurityController,Controller B, so it starts negotiations with the other controller to agree on the IPsec SPD and SAD entries that define the IPsec SAs. NOTE: It would worth evaluating IKEv2 as the protocol for the East/West interface in this case. 4. Once the Security Controllers have agreed on the key material and the details of the IPsec SAs, they both enforce this information into their respective NSFs. 5. The flow is protected with the IPsec SAs established by both Security Controllers in their respective NSFs. 8. IANA Considerations TBD 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,ifwhen NETCONF is used as southbound protocol between the Security Controller and the NSFs, it is defined that TLS or SSH security association MUST be established between both entities. On the other hand,we have divided this section in two parts to analyze different security considerations for both cases: NSF with IKEv2 (IKE case) and NSF without IKEv2 (IKE-less case). In general, the Security Controller, as typically in the SDN paradigm,if encryption isa targetmandatory fordifferent typeall traffic ofattacks. As a consequence, the Security Controller isakey entity inNSF, its default policy MUST be to drop (DISCARD) packets to prevent cleartext packet leaks. This default policy MUST be in the startup configuration datastore in the NSF before the NSF contacts with the Security Controller. Moreover, the startup configuration datastore MUST be pre-configured with the required ALLOW policies that allow to communicate the NSF with the Security Controller once the NSF is deployed. This pre-configuration step is not carried out by the Security Controller but by some other entity before the NSF deployment. In this manner, when the NSF starts/reboots, it will always apply first the configuration in the startup configuration before contacting the Security Controller. Finally, we have divided this section in two parts in order to analyze different security considerations for both cases: NSF with IKEv2 (IKE case) and NSF without IKEv2 (IKE-less case). In general, the Security Controller, as typically in the SDN paradigm, is a target for different type of attacks. Thus, the Security Controller is a key entity in the infrastructure and MUST be protected accordingly. In particular,according to this document,the Security Controller will handle cryptographic material so that the attacker may try to access this information.Although,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 case the attack occurs. The impact is different depending on the IKE case or IKE-less case.8.1.9.1. IKE case In IKE case, the Security Controller sends IKE credentials (PSK, public/private keys, certificates,etc...)etc.) to the NSFs using the security association between Security Controller and NSFs. The general recommendation is that the Security ControllerSHOULD NEVERMUST NOT store the IKE credentials 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). One option is to return always the same value(all 0s).(i.e. all 0s) if a read operation is carried out. If the attacker has access to the Security Controller during the period of time that key material is generated, itmaymight have access tothese values.the key material. Since these values are used during NSF authentication in IKEv2, it may impersonate the affected NSFs. Several recommendations are important. If PSK authentication is used in IKEv2, the Security ControllerSHOULDMUST remove the PSK immediately after generating and distributing it. Moreover, the PSK MUST have a proper length (e.g.minimu,minimum 128 bit length) and strength.If raw publicWhen public/private keys are used, the Security ControllerSHOULDMAY generate both public key and private key. In such a case, the Security Controller MUST remove the associated private key immediately aftergenerating anddistributing them to the NSFs. Alternatively, the NSF could generate the private key and export only the public key to the Security Controller. If certificates are used, the NSFmayMAY generate the private key and exports the public key for certification to the Security Controller.8.2.How the NSF generates these cryptographic material (public key/private keys) and export the public key, or it is instructed to do so, it is out of the scope of this document. 9.2. IKE-less case In the IKE-less case, thecontrollerSecurity Controller sends the IPsec SA information to the NSF's SAD that includes the private session keys required for integrity andencryption (when ESP is used). That key material are symmetric keys to protect data traffic. The general recommendationencryption. The general recommendation is thatthe Security Controller SHOULD NEVER storesit MUST NOT store the keys after distributing them. Moreover, the NSFs receiving private key material MUST NOT allow the reading of these values by any other entity (including the Security Controller itself) once they have been appliedby the Security Controller(i.e. write onlyoperations).operations) into the NSFs. Nevertheless, if the attacker has access to the Security Controller during the period of time that key material is generated, it mayaccess toobtain these values. In other words,it may have access tothekey material used inattacker might be able to observe thedistributedIPsecSAstraffic andobservedecrypt, or even modify and re- encrypt the traffic between peers.In any case, some escenarios with special secure environments (e.g. physically isolated data centers) make this type of attack difficult. Moreover, some scenarios such as IoT networks with constrained devices, where reducing implementation and computation overhead is important, can apply IKE-less case as a tradeoff between security and low overhead at the constrained device, at the cost of assuming the security impact described above. 9.10. Acknowledgements Authors want to thank Paul Wouters, Sowmini Varadhan, David Carrel, Yoav Nir, Tero Kivinen, Graham Bartlett, Sandeep Kampati, Linda Dunbar, Carlos J. Bernardos, Alejandro Perez-Mendez, Alejandro Abad- Carrascosa, Ignacio Martinez and Ruben Ricart for their valuable comments.10.11. References10.1.11.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>. [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.11.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-07draft-ietf-i2nsf-terminology-08 (work in progress),JanuaryJuly 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.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. [libreswan] The Libreswan Project, "Libreswan VPN software", July 2019. [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>. [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- Defined Networking (SDN): Layers and Architecture Terminology", RFC 7426, DOI 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.July 2019. Appendix A. Appendix A: Common YANG model for IKE andIKElessIKE-less cases <CODE BEGINS> file"ietf-ipsec-common@2019-03-11.yang""ietf-ipsec-common@2019-07-07.yang" moduleietf-ipsec-common{ietf-ipsec-common { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec-common"; prefix "ipsec-common"; import ietf-inet-types { prefix inet; } import ietf-yang-types { prefix yang; }import ietf-crypto-types { prefix ct; reference "draft-ietf-netconf-crypto-types-01: Common YANG Dta Types for Cryptography"; }organization "IETF I2NSF(Interface to Network Security Functions)Working Group"; contact""WG Web: <https://datatracker.ietf.org/wg/i2nsf/about/> WG List: <mailto:i2nsf@ietf.org> Author: RafaelMarin Lopez Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 e-mail: rafa@um.esMarin-Lopez <mailto:rafa@um.es> Author: GabrielLopez Millan Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Tel: +34 868888504 email: gabilm@um.esLopez-Millan <mailto:gabilm@um.es> Author: FernandoPereniguez 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.esPereniguez-Garcia <mailto:fernando.pereniguez@cud.upct.es> "; description "Common Data model for the IKE and IKE-less cases defined by the SDN-basedIPSec configuration.";IPsec flow protection service. Copyright (c) 2019 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX;; see the RFC itself for full legal notices. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here."; revision"2019-03-11""2019-07-07" { description"Revision";"Revision 05"; reference"";"RFC XXXX: YANG Groupings and typedef for IKE and IKE-less case"; } typedefencryption-algorithm-tencryption-algorithm-type { typect:encryption-algorithm-ref;uint32; description"typedef";"The encryption algorithm is specified with a 32-bit number extracted from IANA Registry. The acceptable values MUST follow the requirement levels for encryption algorithms for ESP and IKEv2."; reference "IANA Registry- Transform Type 1 - Encryption Algorithm Transform IDs. RFC 8221 - Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) and RFC 8247 - Algorithm Implementation Requirements and Usage Guidance for the Internet Key Exchange Protocol Version 2 (IKEv2)."; } typedefintegrity-algorithm-tintegrity-algorithm-type { typect:mac-algorithm-ref;uint32; description"This typedef enables importing modules to easily define an identityref to"The integrity algorithm is specified with a 32-bit number extracted from IANA Registry. The acceptable values MUST follow the requirement levels for encryption algorithms for ESP and IKEv2."; reference "IANA Registry- Transform Type 3 - Integrity Algorithm Transform IDs. RFC 8221 - Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) and RFC 8247 - Algorithm Implementation Requirements and Usage Guidance for the'asymmetric-key-encryption-algorithm' base identity.";Internet Key Exchange Protocol Version 2 (IKEv2)."; } typedef ipsec-mode { type enumeration { enumTRANSPORTtransport { description"Transport"IPsec transport mode. NoNATNetwork Address Translation (NAT) support."; } enumTUNNELtunnel { description"Tunnel mode";"IPsec tunnel mode."; } } description "Type definition of IPsecmode";mode: transport or tunnel."; reference "Section 3.2 in RFC 4301."; } typedef esp-encap { type enumeration { enumESPINTCPespintcp { description "ESP in TCPencapulation.";} enum ESPINTLS { description "ESP inencapsulation."; reference "RFC 8229 - TCP Encapsulation of IKE and IPsec Packets."; } enum espintls { description "ESP in TCP encapsulation usingTLS.";}TLS."; reference "RFC 8229 - TCP Encapsulation of IKE and IPsec Packets."; } enumESPINUDPespinudp { description "ESP in UDPencapsulation. RFCencapsulation."; reference "RFC 3948";}- UDP Encapsulation of IPsec ESP Packets."; } enumNONEnone { description "NOT ESPencapsulation" ;encapsulation."; } } description"type defining types"Types of ESPencapsulation"; } grouping encap { /* Thisencapsulation when Network Address Translation (NAT) isdefined by XFRM */ description "Encapsulation container"; leaf espencap { type esp-encap; description "ESP in TCP, ESP inpresent between two NSFs."; reference "RFC 8229 - TCP Encapsulation of IKE and IPsec Packets and RFC 3948 - UDPorEncapsulation of IPsec ESPin TLS";} leaf sport {type inet:port-number; description "Encapsulation source port";} leaf dport {type inet:port-number; description "Encapsulation destination port"; } leaf-list oaddr {type inet:ip-address; description "Encapsulation Original Address ";}Packets."; } typedefipsec-protocolipsec-protocol-parameters { type enumeration { enumah { description "AH Protocol"; } enumesp { description"ESP Protocol"; } } description "type define of ipsec security protocol";"IPsec ESP protocol."; }typedef ipsec-spi { type uint32 { range "0..max";} description"SPI";"Only the Encapsulation Security Protocol (ESP) is supported but it could be extended in the future."; reference "RFC 4303- IP Encapsulating Security Payload (ESP)."; } typedef lifetime-action { type enumeration { enum terminate-clear{description "Terminate{ description "Terminates the IPsec SA andallowallows the packetsthrough";}through."; } enum terminate-hold{description "Terminate{ description "Terminates the IPsec SA anddropdrops thepackets";}packets."; } enum replace{description "Replace{ description "Replaces the IPsec SA with a newone";}one: rekey. "; } } description"Action when"When the lifetimeexpiration";of an IPsec SA expires an action needs to be performed over the IPsec SA that reached the lifetime. There are three posible options: terminate-clear, terminate-hold and replace."; reference "Section 4.5 in RFC 4301."; }/*################## SPD basic groupings ####################*/typedef ipsec-traffic-direction { type enumeration { enumINBOUNDinbound { description "Inboundtraffic";traffic."; } enumOUTBOUNDoutbound { description "Outboundtraffic";traffic."; } } description "IPsec trafficdirection";direction is defined in two directions: inbound and outbound. From a NSF perspective inbound means the traffic that enters the NSF and outbound is the traffic that is sent from the NSF."; reference "Section 5 in RFC 4301."; } typedefipsec-spd-operationipsec-spd-action { type enumeration { enumPROTECTprotect { description "PROTECT the traffic withIPsec";IPsec."; } enumBYPASSbypass { description "BYPASS thetraffic";traffic. The packet is forwarded without IPsec protection."; } enumDISCARDdiscard { description "DISCARD thetraffic";traffic. The IP packet is discarded."; } } description "Theoperationaction when traffic matches an IPsec securitypolicy";policy. According to RFC 4301 there are three possible values: BYPASS, PROTECT AND DISCARD"; reference "Section 4.4.1 in RFC 4301."; } typedefipsec-upper-layer-protoipsec-inner-protocol { type union { type uint8; type enumeration { enumTCPany { value 256; description"TCP traffic"; } enum UDP { description "UDP traffic";"Any IP protocol number value."; } }enum SCTP { description "SCTP traffic";} enum DCCP { description "DCCP traffic";} enum ICMP { description "ICMP traffic";} enum IPv6-ICMP { description "IPv6-ICMP traffic";} enum GRE {description "GRE traffic";}} default any; description"Next"IPsec protection can be applied to specific IP traffic and layerproto on top of IP";4 traffic (TCP, UDP, SCTP, etc.) or ANY protocol in the IP packet payload. We specify the IP protocol number with an uint8 or ANY defining an enumerate with value 256 to indicate the protocol number."; reference "Section 4.4.1.1 in RFC 4301. IANA Registry - Protocol Numbers."; }typedef ipsec-spd-namegrouping encap { description "This group of nodes allows to define the typeenumeration { enum id_rfc_822_addrof encapsulation in case NAT traversal is required and port information."; leaf espencap { type esp-encap; description"Fully qualified user name string.";"ESP in TCP, ESP in UDP or ESP in TLS."; }enum id_fqdnleaf sport { type inet:port-number; default 4500; description"Fully qualified DNS name.";"Encapsulation source port."; }enum id_der_asn1_dnleaf dport { type inet:port-number; default 4500; description"X.500 distinguished name.";"Encapsulation destination port."; }enum id_keyleaf-list oaddr { type inet:ip-address; description"IKEv2 Key ID."; }"If required, this is the original address that was used before NAT was applied over the Packet. "; }description "IPsec SPD name type";reference "RFC 3947 and RFC 8229."; } grouping lifetime { description"lifetime current state data";"Different lifetime values limited to an IPsec SA."; leaf time{type yang:timestamp;{ type uint32; default 0; description "Time in seconds since theelementIPsec SA was added. For example, if this value isadded";} leaf idle {type yang:timestamp; default 0; description "Time180 seconds it means theelement isIPsec SA expires inidle state";}180 seconds since it was added. The value 0 implies infinite."; } leaf bytes { type uint32; default 0; description"Lifetime in"If the IPsec SA processes the number of bytesnumber";}expressed in this leaf, the IPsec SA expires and should be rekeyed. The value 0 implies infinite."; } leaf packets{type{ type uint32; default 0; description"Lifetime in"If the IPsec SA processes the number of packetsnumber";} } /*################## SADexpressed in this leaf, the IPsec SA expires andSPD common basic groupings ####################*/ grouping port-range { description "Port range grouping"; leaf start { type inet:port-number; description "Start Port Number";should be rekeyed. The value 0 implies infinite."; } leafendidle { typeinet:port-number;uint32; default 0; description"End Port Number"; }"When a NSF stores an IPsec SA, it consumes system resources. In an idle NSF this is a waste of resources. If the IPsec SA is idle during this number of seconds the IPsec SA should be removed. The value 0 implies infinite."; } reference "Section 4.4.2.1 in RFC 4301."; } grouping port-range { description "This grouping defines a port range, such as expressed in RFC 4301. For example: 1500 (Start Port Number)-1600 (End Port Number). A port range is used in the Traffic Selector."; leaf start { type inet:port-number; description "Start port number."; } leaf end { type inet:port-number; description "End port number."; } reference "Section 4.4.1.2 in RFC 4301."; } grouping tunnel-grouping { description"Tunnel mode grouping";"The parameters required to define the IP tunnel endpoints when IPsec SA requires tunnel mode. The tunnel is defined by two endpoints: the local IP address and the remote IP address."; leaflocal{local { type inet:ip-address; mandatory true; description "Local IP address' tunnelendpoint";endpoint."; } leafremote{remote { type inet:ip-address; mandatory true; description "Remote IP address' tunnelenpoint";endpoint."; } leafbypass-dfdf-bit { typeboolean;enumeration { enum clear { description "Disable the DF (Don't Fragment) bit from the outer header. This is the default value."; } enum set { description "Enable the DF bit in the outer header."; } enum copy { description "Copy the DF bit to the outer header."; } } default clear; description"Bypass"Allow configuring the DF bit when encapsulating tunnel mode IPsec traffic. RFC 4301 describes three options to handle the DFbit";bit during tunnel encapsulation: clear, set and copy from the inner IP header."; reference "Section 8.1 in RFC 4301."; } leaf bypass-dscp { type boolean; default true; description"Bypass DSCP";"If DSCP (Differentiated Services Code Point) values in the inner header have to be used to select one IPsec SA among several that match the traffic selectors for an outbound packet"; reference "Section 4.4.2.1. in RFC 4301."; } leaf dscp-mapping { type yang:hex-string; description "DSCPmapping";values allowed for packets carried over this IPsec SA."; reference "Section 4.4.2.1. in RFC 4301."; } leaf ecn { type boolean; default false; description"Bit ECN"; } /* RFC 4301 ASN1 notation."Explicit Congestion Notification (ECN). If true copy CE bits to inner header."; reference "Section 5.2.1 and AnnexC*/C in RFC 4301."; } } grouping selector-grouping { description"Traffic selector grouping";"This grouping contains the definition of a Traffic Selector, which is used in the IPsec policies and IPsec SAs."; leaf local-subnet { type inet:ip-prefix;descriptionmandatory true; description "Local IP addresssubnet";subnet."; } leaf remote-subnet { type inet:ip-prefix; mandatory true; description "Remote IP addresssubnet";subnet."; }leaf-list upper-layer-protocolleaf inner-protocol { typeipsec-upper-layer-proto;ipsec-inner-protocol; default any; description"List of Upper Layer Protocol";}"Inner Protocol that is going to be protected with IPsec."; } list local-ports { key "start end"; uses port-range; description "List of local ports. When theupper-layer-protocolinner protocol is ICMP this 16 bit valuerespresentsrepresents code andtype as mentioned in RFC 4301";type."; } list remote-ports { key "start end"; uses port-range; description "List of remote ports. When theupper-layer-protocolupper layer protocol is ICMP this 16 bit valuerespresentsrepresents code andtype as mentionedtype."; } reference "Section 4.4.1.2 in RFC4301"; }4301."; }/*################## SPD ipsec-policy-grouping ####################*/grouping ipsec-policy-grouping { description "Holds configuration information for anIPSecIPsec SPD entry."; leafspd-entry-idanti-replay-window { type uint64;description "SPD entry id "; } leaf priority {type uint32;default0; description "Policy priority";} leaf anti-replay-window { type uint16 { range "0 | 32..1024"; } description "Anti replay window size"; } list names { key "name"; leaf name-type { type ipsec-spd-name; description "SPD name type."; } leaf name { type string;32; description"Policy name"; } description "List of policy names";"A 64-bit counter used to determine whether an inbound ESP packet is a replay."; reference "Section 4.4.2.1 in RFC 4301."; } containercondition { description "SPD condition - RFC4301"; list traffic-selector-list { key "ts-number"; leaf ts-number { type uint32; description "Traffic selector number"; } leaf directiontraffic-selector {type ipsec-traffic-direction;description"in/out"; }"Packets are selected for processing actions based on the IP and inner protocol header information, selectors, matched against entries in the SPD."; uses selector-grouping;ordered-by user; description "List of traffic selectors"; }reference "Section 4.4.4.1 in RFC 4301."; } container processing-info { description "SPD processing. If the required processing- RFC4301";action is protect, it contains the required information to process the packet."; leafaction{action { typeipsec-spd-operation; mandatory true;ipsec-spd-action; default discard; description"Bypass"If bypass or discard, container ipsec-sa-cfg isempty";}empty."; } container ipsec-sa-cfg { when "../action ='PROTECT'";'protect'"; description "IPSec SA configuration included in the SPD entry."; leaf pfp-flag { type boolean; default false; description "Each selector haswithapfp flag.";Populate From Packet (PFP) flag. If asserted for a given selector X, the flag indicates that the IPSec SA to be created should take its value (local IP address, remote IP address, Next Layer Protocol, etc.) for X from the value in the packet. Otherwise, the IPsec SA should take its value(s) for X from the value(s) in the SPD entry."; } leafextSeqNumext-seq-num { type boolean; default false; description"TRUE"True if this IPsec SA is using extended sequence numbers. True 64 bit counter,FALSEFalse 32bit"; } leaf seqOverflow { type boolean; description "TRUE rekey, FALSE terminare & audit";bit."; } leafstatefulfragCheckseq-overflow { type boolean; default false; description"Indicates"The flag indicating whether(TRUE) or not (FALSE) stateful fragment checking (RFC 4301) applies tooverflow of theSA to be created."; } leaf security-protocol { type ipsec-protocol; description "Security protocolsequence number counter should prevent transmission of additional packets on the IPsecSA: Either AHSA (false) and, therefore needs to be rekeyed, orESP.";whether rollover is permitted (true). If Authenticated Encryption with Associated Data (AEAD) is used this flag MUST BE false."; } leafmodestateful-frag-check { typeipsec-mode;boolean; default false; description"transport/tunnel";"Indicates whether (true) or not (false) stateful fragment checking applies to the IPsec SA to be created."; }container ah-algorithms { when "../security-protocol = 'ah'"; leaf-list ah-algorithmleaf mode { typeintegrity-algorithm-t;ipsec-mode; default transport; description"Configure Authentication Header (AH).";"IPsec SA has to be processed in transport or tunnel mode."; } leaftrunc-lengthprotocol-parameters { typeuint32; description "Truncation value for AH algorithm"; }ipsec-protocol-parameters; default esp; description"AH algoritms ";"Security protocol of the IPsec SA: Only ESP is supported but it could be extended in the future."; } container esp-algorithms { when"../security-protocol"../protocol-parameters = 'esp'"; description"Configure"Configuration of Encapsulating Security Payload(ESP).";(ESP) parameters and algorithms."; leaf-listauthenticationintegrity { typeintegrity-algorithm-t;integrity-algorithm-type; default 0; ordered-by user; description"Configure"Configuration of ESPauthentication"; } /*authentication based on the specified integrity algorithm. With AEAD algorithms, theauthenticationintegrity node is notused */used."; reference "Section 3.2 in RFC 4303."; } leaf-list encryption { typeencryption-algorithm-t;encryption-algorithm-type; default 20; ordered-by user; description"Configure"Configuration of ESPencryption";encryption algorithms. The default value is 20 (ENCR_AES_GCM_16)."; reference "Section 3.2 in RFC 4303."; } leaftfc_padtfc-pad { typeuint32;boolean; default0;false; description"TFC"If Traffic Flow Confidentiality (TFC) padding for ESPencryption";encryption can be used (true) or not (false)"; reference "Section 2.7 in RFC 4303."; } reference "RFC 4303."; } container tunnel { when "../mode ='TUNNEL'";'tunnel'"; uses tunnel-grouping; description"tunnel grouping container";"IPsec tunnel endpoints definition."; }description " IPSec SA configuration container";} reference "Section 4.4.1.2 in RFC 4301."; } containerspd-lifetime-softspd-mark { description"SPD lifetime hard state data"; uses lifetime;"The Mark to set for the IPsec SA of this connection. This option is only available on linux NETKEY/XFRM kernels. It can be used with iptables to create custom iptables rules using CONNMARK. It can also be used with Virtual Tunnel Interfaces (VTI) to direct marked traffic to specific vtiXX devices."; leafaction {type lifetime-action;mark { type uint32; default 0; description"Action lifetime";}"Mark used to match XFRM policies and states."; }container spd-lifetime-hardleaf mask { type yang:hex-string; default 00:00:00:00; description"SPD lifetime hard state data. The action after the lifetime is"Mask used toremove the SPD entry."; uses lifetime;match XFRM policies and states."; }// State data for an IPsec SPD entry container spd-lifetime-current { uses lifetime; config false; description "SPD lifetime current state data"; } } /* grouping ipsec-policy-grouping */ } <CODE ENDS> Appendix B. Appendix B: YANG model} } } <CODE ENDS> Appendix B. Appendix B: YANG model for IKE case <CODE BEGINS> file"ietf-ipsec-ike@2019-03-11.yang""ietf-ipsec-ike@2019-07-07.yang" module ietf-ipsec-ike { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec-ike"; prefix"ipsec-ike";"ike"; import ietf-inet-types { prefix inet; } import ietf-yang-types { prefix yang; } import ietf-crypto-types { prefix ct; reference"draft-ietf-netconf-crypto-types-01:"draft-ietf-netconf-crypto-types-09: Common YANG Data Types forCryptography";Cryptography."; } import ietf-ipsec-common { prefix ic; reference"Common Data model for SDN-based IPSec configuration";"RFC XXXX: module ietf-ipsec-common, revision 2019-07-07."; } import ietf-netconf-acm { prefix nacm; reference "RFC 8341: Network Configuration Access Control Model."; } organization "IETF I2NSF(Interface to Network Security Functions)Working Group"; contact""WG Web: <https://datatracker.ietf.org/wg/i2nsf/about/> WG List: <mailto:i2nsf@ietf.org> Author: RafaelMarin Lopez Dept. InformationMarin-Lopez <mailto:rafa@um.es> Author: Gabriel Lopez-Millan <mailto:gabilm@um.es> Author: Fernando Pereniguez-Garcia <mailto:fernando.pereniguez@cud.upct.es> "; description "This module contains IPSec IKE case model for the SDN-based IPsec flow protection service. An NSF will implement this module. Copyright (c) 2019 IETF Trust andCommunications Engineering (DIIC) Faculty of Computer Science-Universitythe persons identified as authors ofMurcia 30100 Murcia - Spain Telf: +34868888501 e-mail: rafa@um.es Gabriel Lopez Millan Dept. Informationthe code. All rights reserved. Redistribution andCommunications Engineering (DIIC) Facultyuse in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c ofComputer Science-Universitythe IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version ofMurcia 30100 Murcia - Spain Tel: +34 868888504 email: gabilm@um.es Fernando Pereniguez Garcia Departmentthis YANG module is part ofSciencesRFC XXXX; see the RFC itself for full legal notices. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', andInformatics University Defense Center (CUD), Spanish Air Force Academy, MDE-UPCT 30720 San Javier - Spain Tel: +34 968189946 email: fernando.pereniguez@cud.upct.es ";'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here."; revision "2019-07-07" { description"Data"Revision 5"; reference "RFC XXXX: YANG model for IKE case.";revision "2019-03-11"} typedef ike-spi { type uint64 { range "0..max"; } description"Revision 1.1";"Security Parameter Index (SPI)'s IKE SA."; reference"";"Section 2.6 in RFC 7296."; } typedeftype-autostartupautostartup-type { type enumeration { enumADD {description "IPsecadd { description "IKE/IPsec configuration is only loaded into IKE implementation but IKE/IPsec SA is notstarted.";}started."; } enumON-DEMAND {description "IPsecon-demand { description "IKE/IPsec configuration is loadedandinto IKE implementation. The IPsec policies are transferred to the NSF'skernel";}kernel but the IPsec SAs are not established immediately. The IKE implementation will negotiate the IPsec SAs when the NSF's kernel requests it (i.e. through an ACQUIRE notification)."; } enumSTARTstart { description"IPsec"IKE/IPsec configuration is loaded and transferred to the NSF's kernel, and the IKEv2 based IPsec SAs areestablished";}established immediately without waiting any packet."; } } description "Different policiesof whentostart an IKEv2 basedset IPsecSA"; } typedef auth-protocol-type { type enumeration { enumSA configuration into NSF's kernel when IKEv2{ description "Authentication protocol based on IKEv2"; }implementation has started."; } typedef pfs-group { type uint32; description"IKE authentication protocol version";"DH groups for IKE and IPsec SA rekey."; reference "Section 3.3.2 in RFC 7296. Transform Type 4 - Diffie-Hellman Group Transform IDs in IANA Registry - Internet Key Exchange Version 2 (IKEv2) Parameters."; } typedefpfs-groupauth-protocol-type { type enumeration { enumNONE {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";}ikev2 { value 2; description "IKEv2 authentication protocol. It is the only defined right now. An enum8192-bit-MODP {description "8192-bit MODP Group";}is used for further extensibility."; } } description"PFS group for IPsec rekey";"IKE authentication protocol version specified in the Peer Authorization Database (PAD). It is defined as enumerate to allow new IKE versions in the future."; reference "RFC 7296."; }/*################## PAD ####################*/typedef auth-method-type {/* Most implementations also provide XAUTH protocol, others used are: BLISS, P12, NTLM, PIN */type enumeration { enum pre-shared { description "Select pre-shared keymessageas the authenticationmethod";method."; reference "RFC 7296."; } enum eap { description "Select EAP as the authenticationmethod";method."; reference "RFC 7296."; } enum digital-signature { description "Select digital signaturemethod";}method."; reference "RFC 7296 and RFC 7427."; } enum null{description "null authentication";} } description "Peer authentication method"; } typedef signature-algorithm-t{type ct:signature-algorithm-ref; // We must reference to "signature-algorithm-ref" but we temporary use hash-algorithm-refdescription"This typedef enables referencing to any digital signature algorithm";"Null authentication."; reference "RFC 7619."; } }grouping auth-method-grouping { description "Peer authentication method data"; container auth-method {description "Peer authentication methodcontainer"; leaf auth-m { type auth-method-type; description "Type of authentication method (pre-shared, eap, digital signature, null)"; } container eap-method { when "../auth-m = 'eap'"; leaf eap-type { type uint8; description "EAP method type"; } description "EAP method description used when auth method is eap";specified in the Peer Authorization Database (PAD)."; } containerpre-shared { when "../auth-m[.='pre-shared' or .='eap']"; leaf secretipsec-ike {type yang:hex-string; description "Pre-shared secret value";}description"Shared secret value"; }"IKE configuration for a NSF. It includes PAD parameters, IKE connections information and state data."; containerdigital-signaturepad {when "../auth-m[.='digital-signature' or .='eap']"; leaf ds-algorithm {type signature-algorithm-t;description"Name"Configuration of Peer Authorization Database (PAD). The PAD contains information about IKE peer (local and remote). Therefore, thedigital signature algorithm";} leaf raw-public-key {type yang:hex-string; description "RSA raw public key" ;} leaf key-data { type string; description "RSA private key data - PEM"; } leaf key-fileSecurity Controller also stores authentication information for this NSF and can include several entries for the local NSF not only remote peers. Storing local and remote information makes possible to specify that this NSF with identity A will use some particular authentication with remote NSF with identity B and what are the authentication mechanisms allowed to B."; list pad-entry {type string; description "RSA privatekeyfile name "; } leaf-list ca-data { type string; description "List of trusted CA certs - PEM"; } leaf ca-file { type string;"name"; ordered-by user; description"List"Peer Authorization Database (PAD) entry. It is a list oftrusted CA certs file"; } leaf cert-data { type string; description "X.509 certificate data - PEM4"; } leaf cert-file { type string; description "X.509 certificate file"; } leaf crl-data { type string; description "X.509 CRL certificate data in base64"; }PAD entries ordered by the Security Controller."; leafcrl-filename { type string; description" X.509 CRL certificate file"; } leaf oscp-uri { type inet:uri; description "OCSP URI";} description "RSA signature container"; } }"PAD unique name to identify this entry."; }grouping identity-grouping { description "Identification type. It is an union identity";choice identity { mandatory true; description"Choice"A particular IKE peer will be identified by one ofidentity.";these identities. This peer can be a remote peer or local peer (this NSF)."; reference "Section 4.4.3.1 in RFC 4301."; case ipv4-address{ leaf ipv4-address { type inet:ipv4-address; description "Specifies the identity as a single four (4) octet IPv4address. An example is, 10.10.10.10. ";addressExample: 10.10.10.10."; } } case ipv6-address{ leaf ipv6-address { type inet:ipv6-address; description "Specifies the identity as a single sixteen (16) octet IPv6 address. An example isFF01::101, 2001:DB8:0:0:8:800:200C:417A .";2001:DB8:0:0:8:800:200C:417A."; } } case fqdn-string { leaf fqdn-string { type inet:domain-name; description "Specifies the identity as aFully-Qualified DomainFully-QualifiedDomain Name (FQDN) string. An example is: example.com. The string MUST not contain any terminators (e.g., NULL, CR, etc.)."; } } case rfc822-address-string { leaf rfc822-address-string { type string; description "Specifies the identity as a fully-qualified RFC822 email address string. An example is, jsmith@example.com. The string MUST not contain any terminators(e.g.,e.g., NULL, CR, etc.)."; reference "RFC 822."; } } case dnx509 { leafdnX509dnx509 { type string; description "Specifies the identity as adistinguished name in the X.509 tradition.";ASN.1 X.500 Distinguished Name. An example is C=US,O=Example Organisation,CN=John Smith."; reference "RFC 2247."; }leaf id_key { type string; description "Key id";}leaf id_nullcase gnx509 {type empty; description "RFC 7619" ; }leafuser_fqdngnx509 { type string; description"User FQDN";"ASN.1 X.509 GeneralName. RFC 3280."; } } case id-key { leafmy-identifierid-key { type string;mandatory true;description"id"Opaque octet stream that may be used to pass vendor-specific information forauthentication";proprietary types of identification."; reference "Section 3.5 in RFC 7296."; } }/*################ end PAD ##################*/ /*################## IKEv2-grouping ##################*/ grouping ike-proposalcase id-null {description "IKEv2 proposal grouping"; container ike-sa-lifetime-hard { description "IKE SA lifetime hard"; uses ic:lifetime; } container ike-sa-lifetime-soft { description "IPsec SA lifetime soft"; uses ic:lifetime;leafaction {type ic:lifetime-action; description "Action lifetime";} } leaf-list ike-sa-authalgid-null { typeic:integrity-algorithm-t;empty; description"Auth algorigthm for"ID_NULL identification used when IKESA";} leaf-list ike-sa-encalgidentification payload is not used." ; reference "RFC 7619."; } } } leaf auth-protocol { typeic:encryption-algorithm-t;auth-protocol-type; default ikev2; description"Auth algorigthm for IKE SAs";} leaf dh_group"Only IKEv2 is supported right now but other authentication protocols may be supported in the future."; } container peer-authentication {type uint32; mandatory true;description"Group number for Diffie Hellman Exponentiation";}"This container allows the Security Controller to configure the authentication method (pre-shared key, eap, digitial-signature, null) that will use a particular peer and the credentials, which will depend on the selected authentication method."; leafhalf-open-ike-sa-timerauth-method { typeuint32;auth-method-type; default pre-shared; description"Set the half-open IKE SA timeout duration" ;"Type of authentication method (pre-shared, eap, digital signature, null)."; reference "Section 2.15 in RFC 7296."; } container eap-method { when "../auth-method = 'eap'"; leafhalf-open-ike-sa-cookie-thresholdeap-type { typeuint32;uint8; mandatory true; description"Number of half-open IKE SAs that activate"EAP method type. This information provides thecookie mechanism." ; }particular EAP method to be used. Depending on the EAP method, pre-shared keys or certificates may be used."; }grouping ike-child-sa-info {description"IPsec SA Information"; leaf-list pfs_groups { type pfs-group;"EAP method description"If non-zero, require perfect forward secrecyused whenrequesting new SA. The non-zero valueauthentication method isthe required group number";'eap'."; reference "Section 2.16 in RFC 7296."; } containerchild-sa-lifetime-softpre-shared {description "IPsec SA lifetime soft"; uses ic:lifetime;when "../auth-method[.='pre-shared' or .='eap']"; leafaction {type ic:lifetime-action; description "action lifetime";} } container child-sa-lifetime-hardsecret { nacm:default-deny-all; type yang:hex-string; description"IPsec SA lifetime hard."Pre-shared secret value. Theaction will beNSF has toterminate the IPsec SA."; uses ic:lifetime;prevent read access to this value for security reasons."; } description "Shared secret value for PSK or EAP method authentication based on PSK."; }/*################## End IKEv2-grouping ##################*/containerikev2digital-signature {description "Configure the IKEv2 software"; container padwhen "../auth-method[.='digital-signature' or .='eap']"; leaf ds-algorithm { type uint8; description"Configure Peer Authorization Database (PAD)"; list pad-entry { key "pad-entry-id"; ordered-by user; description "Peer Authorization Database (PAD)"; leaf pad-entry-id { type uint64; description "SAD index. ";} uses identity-grouping;"The digital signature algorithm is specified with a value extracted from the IANA Registry. Depending on the algorithm, the following leafs must contain information. For example if digital signature involves a certificate then leafpad-auth-protocol { type auth-protocol-type; description "IKEv2, etc. ";} uses auth-method-grouping; }'cert-data' and 'private-key' will contain this information."; reference "IKEv2 Authentication Method - IANA Registry - Internet Key Exchange Version 2 (IKEv2) Parameters."; }list ike-conn-entry { key "conn-name"; description "IKE peer connection information"; leaf conn-namechoice public-key {type string;mandatory true;description "Name of IKE connection";}leafautostartupraw-public-key { typetype-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;binary; description"This IKE SA"A binary that contains the value of the public key. The interpretation of the content is defined by theonly currently active betweendigital signature algorithm. For example, an RSA key is represented as RSAPublicKey as defined in RFC 8017, and an Elliptic Curve Cryptography (ECC) key is represented using theauthenticated identities";} leaf version { type enumeration { enum ikev2 {value 2; description "IKE version 2";} } description "IKE version";'publicKey' described in RFC 5915."; reference "RFC XXX: Common YANG Data Types for Cryptography."; } leafike-fragmentationcert-data { typeboolean;ct:x509; description"Whether to use IKEv2 fragmentation as per RFC 7383 (TRUE or FALSE)";"X.509 certificate data - PEM4."; reference "RFC XXX: Common YANG Data Types for Cryptography."; }uses ike-proposal; container local {description"Local peer connection information";"If the Security Controller knows that the NSF already owns a private key associated to this public key (the NSF generated the pair public key/private key out of band), it will only configure one of the leaflocal-pad-id { type uint64; description " ";}of this choice. The NSF, based on the public key value can know the private key to be used."; }container remote { description "Remote peer connection information";leafremote-pad-idprivate-key { nacm:default-deny-all; typeuint64;binary; description" ";} } uses ic:encap; container spd { description "Configure"A binary that contains theSecurity Policy Database (SPD)"; list spd-entry {value of the private key. The interpretation of the content is defined by the digital signature algorithm. For example, an RSA key"spd-entry-id"; uses ic:ipsec-policy-grouping; ordered-by user;is represented as RSAPrivateKey as defined in RFC 8017, and an Elliptic Curve Cryptography (ECC) key is represented as ECPrivateKey as defined in RFC 5915."; reference "RFC XXX: Common YANG Data Types for Cryptography."; } leaf-list ca-data { type ct:x509; description "List ofSPD entries"; }trusted Certification Authorities (CA) certificates encoded using ASN.1 distinguished encoding rules (DER)."; reference "RFC XXX: Common YANG Data Types for Cryptography."; }container ike-sa-state { container uptime { description "IKE service uptime";leafrunningcrl-data { typeyang:date-and-time;ct:crl; description"Relative uptime";}"A CertificateList structure, as specified in RFC 5280, encoded using ASN.1 distinguished encoding rules (DER),as specified in ITU-T X.690."; reference "RFC XXX: Common YANG Data Types for Cryptography."; } leafsincecrl-uri { typeyang:date-and-time;inet:uri; description"Absolute uptime";}"X.509 CRL certificate URI."; } leafinitiatoroscp-uri { typeboolean;inet:uri; description"It is acting as initiator in"OCSP URI."; } description "Digital Signature container."; } /*container digital-signature*/ } /*container peer-authentication*/ } } list conn-entry { key "name"; description "IKE peer connection information. This list contains the IKE connection for thisconnection";}peer with other peers. This will be translated in real time by IKE Security Associations established with these nodes."; leafinitiator-ikesa-spi {type uint64;name { type string; mandatory true; description"Initiator's IKE SA SPI";}"Identifier for this connection entry."; } leafresponder-ikesa-spi {type uint64;autostartup { type autostartup-type; default add; description"Responsder's IKE SA SPI";}"By-default: Only add configuration without starting the security association."; } leafnat-local {typeinitial-contact { type boolean; default false; description"YES, if local endpoint"The goal of this value isbehind a NAT";}to deactivate the usage of INITIAL_CONTACT notification (true). If this flag remains to false it means the usage of the INITIAL_CONTACT notification will depend on the IKEv2 implementation."; } leafnat-remote {type boolean;version { type auth-protocol-type; default ikev2; description"YES, if remote endpoint"IKE version. Only version 2 isbehind a NAT";}supported so far."; } leafnat-any {typefragmentation { type boolean; default false; description"YES, if both local and remote endpoints are behind a NAT";} uses ic:encap; leaf established {type uint64;"Whether or not to enable IKE fragmentation as per RFC 7383 (true or false)."; reference "RFC 7383."; } container ike-sa-lifetime-soft { description"Seconds"IKE SA lifetime soft. Two lifetime values can be configured: either rekey time of the IKE SAhas been established";}or reauth time of the IKE SA. When the rekey lifetime expires a rekey of the IKE SA starts. When reauth lifetime expires a IKE SA reauthentication starts."; leaf rekey-time{type uint64;{ type uint32; default 0; description"Seconds before"Time in seconds between each IKE SAgets rekeyed";}rekey.The value 0 means infinite."; } leaf reauth-time{type uint64;{ type uint32; default 0; description"Seconds before"Time in seconds between each IKE SAgets re-authenticated";} list child-sas {reauthentication. The value 0 means infinite."; } reference "Section 2.8 in RFC 7296."; } containerspis{ description "IPsec SA's SPI '"; leaf spi-in {type ic:ipsec-spi;ike-sa-lifetime-hard { description"Security Parameter Index for inbound IPsec SA";}"Hard IKE SA lifetime. When this time is reached the IKE SA is removed."; leafspi-out {type ic:ipsec-spi;over-time { type uint32; default 0; description"Security Parameter Index for"Time in seconds before thecorresponding outbound IPsec SA";}IKE SA is removed. The value 0 means infinite."; } reference "RFC 7296."; } leaf-list authalg { type ic:integrity-algorithm-type; default 12; ordered-by user; description"State data about"Authentication algorithm for establishing the IKECHILD SAs";SA. This list is ordered following from the higher priority to lower priority. First node of the list will be the algorithm with higher priority. If this list is empty the default integrity algorithm value assumed is NONE."; }config false;leaf-list encalg { type ic:encryption-algorithm-type; default 12; ordered-by user; description"IKE state data"; } /* ike-sa-state */"Encryption or AEAD algorithm for the IKE SAs. This list is ordered following from the higher priority to lower priority. First node of the list will be the algorithm with higher priority. If this list is empty the default encryption value assumed is NULL."; }/* ike-conn-entries */ container number-ike-sas{leaftotal {type uint32;dh-group { type pfs-group; default 14; description"Total"Group numberof IKEv2 SAs";} leaf half-open {type uint32; description "Number offor Diffie-Hellman Exponentiation used during IKE_SA_INIT for the IKE SA key exchange."; } leaf half-open-ike-sa-timer { type uint32; description "Set the half-openIKEv2 SAs";}IKE SA timeout duration."; reference "Section 2 in RFC 7296."; } leafhalf-open-cookies {typehalf-open-ike-sa-cookie-threshold { type uint32; description "Number ofhalf openhalf-open IKE SAswiththat activate the cookieactivated" ;} config false; description "Number of IKE SAs"; } } /* container ikev2 */ } <CODE ENDS> Appendix C. Appendix C: YANG model for IKE-less case <CODE BEGINS> file "ietf-ipsec-ikeless@2019-03-11.yang" module ietf-ipsec-ikeless { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless"; prefix "ipsec-ikeless"; import ietf-yang-types { prefix yang; } import ietf-ipsec-common { prefix ic; reference "Common Data model for SDN-based IPSec configuration"; } organization "IETF I2NSF (Interface to Network Security Functions) Working Group"; contact " Rafael Marin Lopez Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 e-mail: rafa@um.es Gabriel Lopez Millan Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Tel: +34 868888504 email: gabilm@um.es Fernando Pereniguez Garcia Department of Sciences and Informatics University Defense Center (CUD), Spanish Air Force Academy, MDE-UPCT 30720 San Javier - Spain Tel: +34 968189946 email: fernando.pereniguez@cud.upct.es "; description "Data model for IKE-less case"; revision "2019-03-11" { description "Revision";mechanism." ; reference""; } /*################## SAD grouping ####################*/ grouping ipsec-sa-grouping { description "Configure Security Association (SA). Section 4.4.2.1"Section 2.6 in RFC4301";7296."; } container local { leafsad-entry-id {type uint64;local-pad-entry-name { type string; description"This value identifies"Local peer authentication information. This node points to a specific entry in theSAD";}PAD where the authorization information about this particular local peer is stored. It MUST match a pad-entry-name."; } description "Local peer authentication information."; } container remote { leafspiremote-pad-entry-name { typeic:ipsec-spi;string; description"Security Parameter Index."Remote peer authentication information. Thismay not be unique fornode points to a specific entry in the PAD where the authorization information about this particularSA";} leaf seq-number { type uint64;remote peer is stored. It MUST match a pad-entry-name."; } description"Current sequence number of IPsec packet.";"Remote peer authentication information."; }leaf seq-number-overflow-flagcontainer encapsulation-type {type boolean;uses ic:encap; description"The flag indicating whether overflow of"This container carries configuration information about thesequence number counter should prevent transmissionsource and destination ports ofadditional packets onencapsulation that IKE should use and theSA, or whether rollovertype of encapsulation that should use when NAT traversal is required. However, this ispermitted.";just a best effort since the IKE implementation may need to use a different encapsulation as described in RFC 8229."; reference "RFC 8229."; } container spd { description "Configuration of the Security Policy Database (SPD). This main information is placed in the grouping ipsec-policy-grouping."; list spd-entry { key "name"; ordered-by user; leafanti-replay-windowname { typeuint16 { range "0 | 32..1024"; }string; mandatory true; description"Anti replay window size";"SPD entry unique name to identify the IPsec policy."; }leaf spd-entry-id {type uint64;container ipsec-policy-config { description "Thisvalue links the SA withcontainer carries theSPD entry";}configuration of a IPsec policy."; usesic:selector-grouping; leaf security-protocol { type ic:ipsec-protocol;ic:ipsec-policy-grouping; } description"Security protocol"List of entries which will constitute the representation of the SPD. Since we have IKE in this case, it is only required to send a IPsecSA: Either AH or ESP.";policy from this NSF where 'local' is this NSF and remote the other NSF. The IKE implementation will install IPsec policies in the NSF's kernel in both directions (inbound and outbound) and their corresponding IPsec SAs based on the information in this SPD entry."; } reference "Section 2.9 in RFC 7296."; } containersad-lifetime-hardchild-sa-info { leaf-list pfs-groups { type pfs-group; default 0; ordered-by user; description"SAD lifetime hard state data."If non-zero, it is required perfect forward secrecy when requesting new IPsec SA. Theaction associatednon-zero value isterminate."; uses ic:lifetime;the required group number. This list is ordered following from the higher priority to lower priority. First node of the list will be the algorithm with higher priority."; } containersad-lifetime-softchild-sa-lifetime-soft { description"SAD"Soft IPsec SA lifetimehard state data";soft. After the lifetime the action is defined in this container in the leaf action."; uses ic:lifetime; leaf action{type ic:lifetime-action; description "action lifetime";} } leaf mode{ typeic:ipsec-mode;ic:lifetime-action; default replace; description "When the lifetime of an IPsec SA expires an action needs to be performed over the IPsec SA that reached the lifetime. There are three possible options: terminate-clear, terminate-hold and replace."; reference "Section 4.5 in RFC 4301 and Section 2.8 in RFC 7296."; } } container child-sa-lifetime-hard { description "IPsec SA lifetime hard. The action will be to terminate the IPsec SA."; uses ic:lifetime; reference "Section 2.8 in RFC 7296."; } description"SA Mode";"Specific information for IPsec SAs SAs. It includes PFS group and IPsec SAs rekey lifetimes."; } container state { config false; leafstatefulfragCheckinitiator { type boolean; description"Indicates whether (TRUE) or not (FALSE) stateful fragment checking (RFC 4301) applies to"It is acting as initiator for thisSA.";connection."; } leafdscpinitiator-ikesa-spi { typeyang:hex-string;ike-spi; description"DSCP value";"Initiator's IKE SA SPI."; } leafpath-mturesponder-ikesa-spi { typeuint16;ike-spi; description"Maximum size of an IPsec packet that can be transmitted without fragmentation";"Responder's IKE SA SPI."; }container tunnelleaf nat-local {when "../mode = 'TUNNEL'"; uses ic:tunnel-grouping;type boolean; description"Container for tunnel grouping";"True, if local endpoint is behind a NAT."; }uses ic:encap; // STATE DATA for SA container sad-lifetime-currentleaf nat-remote {uses ic:lifetime; config false;type boolean; description"SAD lifetime current state data";"True, if remote endpoint is behind a NAT."; } containerstatsencapsulation-type {// xfrm.h leaf replay-window {type uint32; default 0; description " "; } leaf replay {type uint32; default 0;uses ic:encap; description"packets detected out of"This container provides information about thereplay windowsource anddropped because they are replay packets";} leaf failed {type uint32; default 0; description "packets detected outdestination ports of encapsulation that IKE is using, and thereplay window ";} config false; description "SAD statistics";type of encapsulation when NAT traversal is required."; reference "RFC 8229."; }container replay_state { // xfrm.hleafseq {type uint32; default 0;established { type uint64; description"input traffic sequence number when anti-replay-window != 0";}"Seconds since this IKE SA has been established."; } leafoseq {type uint32; default 0;current-rekey-time { type uint64; description"output traffic sequence number";}"Seconds before IKE SA must be rekeyed."; } leafbitmap {type uint32; default 0;current-reauth-time { type uint64; description"";}"Seconds before IKE SA must be re-authenticated."; } description "IKE state data for a particular connection."; } /* ike-sa-state */ } /* ike-conn-entries */ container number-ike-sas { config false; leaf total { type uint64; description"Anti-replay Sequence Number state";"Total number of active IKE SAs."; } leaf half-open { type uint64; description "Number of half-open active IKE SAs."; } leaf half-open-cookies { type uint64; description "Number of half open active IKE SAs with cookie activated."; } description "General information about the IKE SAs. In particular, it provides the current number of IKE SAs."; } } /* container ipsec-ike */ } <CODE ENDS> Appendix C. Appendix C: YANG model for IKE-less case <CODE BEGINS> file "ietf-ipsec-ikeless@2019-07-07.yang" module ietf-ipsec-ikeless { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless"; prefix "ikeless"; import ietf-yang-types { prefix yang; } import ietf-ipsec-common { prefix ic; reference "Common Data model for SDN-based IPSec configuration."; } import ietf-netconf-acm { prefix nacm; reference "RFC 8341: Network Configuration Access Control Model."; } organization "IETF I2NSF Working Group"; contact "WG Web: <https://datatracker.ietf.org/wg/i2nsf/about/> WG List: <mailto:i2nsf@ietf.org> Author: Rafael Marin-Lopez <mailto:rafa@um.es> Author: Gabriel Lopez-Millan <mailto:gabilm@um.es> Author: Fernando Pereniguez-Garcia <mailto:fernando.pereniguez@cud.upct.es> "; description "Data model for IKE-less case in the SDN-base IPsec flow protection service. Copyright (c) 2019 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX;; see the RFC itself for full legal notices. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here."; revision "2019-07-07" { description "Revision 05"; reference "RFC XXXX: YANG model for IKE case."; } container ipsec-ikeless { description "Container for configuration of the IKE-less case. The container contains two additional containers: 'spd' and 'sad'. The first allows the Security Controller to configure IPsec policies in the Security Policy Database SPD, and the second allows to configure IPsec Security Associations (IPsec SAs) in the Security Association Database (SAD)."; reference "RFC 4301."; containerreplay_state_esnspd {// xfrm.h leaf bmp-len {type uint32; default 0;description"bitmap length for ESN"; }"Configuration of the Security Policy Database (SPD.)"; reference "Section 4.4.1.2 in RFC 4301."; list spd-entry { key "name"; ordered-by user; leafoseqname { typeuint32; default 0;string; mandatory true; description"output traffic sequence number";"SPD entry unique name to identify this entry."; } leafoseq-hidirection { typeuint32; default 0;ic:ipsec-traffic-direction; description"";"Inbound traffic or outbound traffic. In the IKE-less case the Security Controller needs to specify the policy direction to be applied in the NSF. In the IKE case this direction does not need to be specified since IKE will determine the direction that IPsec policy will require."; } leafseq-hireqid { typeuint32; default 0; description ""; } leaf replay-window {type uint32;uint64; default 0; description""; } leaf-list bmp { type uint32; description "bitmaps for ESN (depends on bmp-len) "; } config false; description "Anti-replay Extended Sequence Number (ESN) state"; } } /*################## end SAD grouping ##################*/ /*################# Register grouping #################*/ typedef sadb-msg-type { type enumeration { enum sadb_acquire { description "SADB_ACQUIRE"; } enum sadb_expire { description "SADB_EXPIRE"; } } description "Notifications (PF_KEY message types) that must be forwarded by the NSF"This value allows to link this IPsec policy with IPsec SAs with thecontrollersame reqid. It is only required in the IKE-lesscase";model since, in the IKE case this link is handled internally by IKE."; }typedef sadb-msg-satype { type enumeration { enum sadb_satype_unspeccontainer ipsec-policy-config { description"SADB_SATYPE_UNSPEC";"This container carries the configuration of a IPsec policy."; uses ic:ipsec-policy-grouping; }enum sadb_satype_ah {description"SADB_SATYPE_AH";"The SPD is represented as a list of SPD entries, where each SPD entry represents an IPsec policy."; }enum sadb_satype_esp/*list spd-entry*/ } /*container spd*/ container sad { description"SADB_SATYPE_ESP"; } enum sadb_satype_rsvp"Configuration of the IPSec Security Association Database (SAD)"; reference "Section 4.4.2.1 in RFC 4301."; list sad-entry { key "name"; ordered-by user; leaf name { type string; description"SADB_SATYPE_RSVP";"SAD entry unique name to identify this entry."; }enum sadb_satype_ospfv2leaf reqid { type uint64; default 0; description"SADB_SATYPE_OSPFv2";"This value allows to link this IPsec SA with an IPsec policy with the same reqid."; }enum sadb_satype_ripv2container ipsec-sa-config { description"SADB_SATYPE_RIPv2"; } enum sadb_satype_mip"This container allows configuring details of an IPsec SA."; leaf spi {description "SADB_SATYPE_MIP"; } enum sadb_satype_maxtype uint32 {description "SADB_SATYPE_MAX"; }range "0..max"; } mandatory true; description"PF_KEY Security Association types";"Security Parameter Index (SPI)'s IPsec SA."; }grouping base-grouping { description "Configuration for the message header format"; list base-list { key "version";leafversionext-seq-num { typestring;boolean; default true; description"Version of PF_KEY (MUST be PF_KEY_V2)";"True if this IPsec SA is using extended sequence numbers. True 64 bit counter, FALSE 32 bit."; } leafmsg_typeseq-number-counter { typesadb-msg-type;uint64; default 0; description"Identifies"A 64-bit counter when this IPsec SA is using Extended Sequence Number or 32-bit counter when it is not. It used to generate thetype of message";initial Sequence Number field in ESP headers."; } leafmsg_satypeseq-overflow { typesadb-msg-satype;boolean; default false; description"Defines"The flag indicating whether overflow of thetypesequence number counter should prevent transmission ofSecurity Association";additional packets on the IPsec SA (false) and, therefore needs to be rekeyed, or whether rollover is permitted (true). If Authenticated Encryption with Associated Data (AEAD) is used this flag MUST BE false."; } leafmsg_seqanti-replay-window { type uint32; default 32; description"Sequence number of this message."; } description "Configuration for"A 32-bit counter and aspecific message header format"; }bit-map (or equivalent) used to determine whether an inbound ESP packet is a replay. If set to 0 no anti-replay mechanism is performed."; }/*################# End Register grouping #################*/ /*################## IPsec configuration ##################*/ container ietf-ipsec { description "IPsec configuration";containerspd { description "Configure the Security Policy Database (SPD)"; list spd-entrytraffic-selector {key "spd-entry-id";usesic:ipsec-policy-grouping; ordered-by user;ic:selector-grouping; description"List of SPD entries"; }"The IPsec SA traffic selector."; }container sad { description "Configure the IPSec Security Association Database (SAD)"; list sad-entry { key "sad-entry-id"; uses ipsec-sa-grouping; container ah-sa { when "../security-protocol = 'ah'"; description "Configure Authentication Header (AH) for SA"; container integrity { description "Configure integrity for IPSec Authentication Header (AH)";leafintegrity-algorithmprotocol-parameters { typeic:integrity-algorithm-t;ic:ipsec-protocol-parameters; default esp; description"Configure Authentication Header (AH).";"Security protocol of IPsec SA: Only ESP so far."; } leafkeymode { typestring;ic:ipsec-mode; description"AH key value";} }"Tunnel or transport mode."; } container esp-sa { when"../security-protocol"../protocol-parameters = 'esp'";description "Set IPSecdescription "In case the IPsec SA is Encapsulation Security Payload(ESP)";(ESP), it is required to specify encryption and integrity algorithms, and key material."; container encryption { description"Configure"Configuration of encryption or AEAD algorithm for IPSec EncapsulationSecutirySecurity Payload(ESP)";(ESP)."; leaf encryption-algorithm { typeic:encryption-algorithm-t;ic:encryption-algorithm-type; description"Configure"Configuration of ESPencryption";encryption. With AEAD algorithms, the integrity node is not used."; } leaf key { nacm:default-deny-all; type yang:hex-string; description "ESP encryption keyvalue";}value."; } leaf iv{type{ nacm:default-deny-all; type yang:hex-string; description "ESP encryption IVvalue";value."; } } container integrity { description"Configure authentication"Configuration of integrity for IPSec EncapsulationSecutirySecurity Payload(ESP)";(ESP). This container allows to configure integrity algorithm when no AEAD algorithms are used, and integrity is required."; leaf integrity-algorithm { typeic:integrity-algorithm-t;ic:integrity-algorithm-type; description"Configure"Message AuthenticationHeader (AH).";Code (MAC) algorithm to provide integrity in ESP."; } leaf key { nacm:default-deny-all; type yang:hex-string; description "ESP integrity keyvalue";}value."; }/* With AEAD algorithms, the integrity node} } /*container esp-sa*/ container sa-lifetime-hard { description "IPsec SA hard lifetime. The action associated isnot used */terminate and hold."; uses ic:lifetime; } container sa-lifetime-soft { description "IPSec SA soft lifetime."; uses ic:lifetime; leafcombined-enc-intraction { typeboolean;ic:lifetime-action; description"ESP combined mode algorithms. The algorithm"Action lifetime: terminate-clear, terminate-hold or replace."; } } container tunnel { when "../mode = 'tunnel'"; uses ic:tunnel-grouping; description "Endpoints of the IPsec tunnel."; } container encapsulation-type { uses ic:encap; description "This container carries configuration information about the source and destination ports which will be used for ESP encapsulation that ESP packets the type of encapsulation when NAT traversal isspecifiedinencryption-algorithm";}place."; } } /*ipsec-sa-config*/ container ipsec-sa-state { config false; description "Container describing IPsec SA state data."; container sa-lifetime-current { uses ic:lifetime; description "SAD lifetime current."; } container replay-stats { description "State data about the anti-replay window."; leaf replay-window { type uint64; description "Current state of the replay window."; } leaf packet-dropped { type uint64; description "Packets detected out of the replay window and dropped because they are replay packets."; } leaf failed { type uint32; description "Number of packets detected out of the replay window."; } leaf seq-number-counter { type uint64; description "A 64-bit counter when this IPsec SA is using Extended Sequence Number or 32-bit counter when it is not. Current value of sequence number."; } } /* container replay-stats*/ } /*ipsec-sa-state*/ description "List of SADentries"; }entries that conforms the SAD."; } /*list sad-entry*/ } /*container sad*/ }/*container ipsec-ikeless*/ /*container ietf-ipsec */ /*################## RPC andNotifications##################*/ // These RPCs are needed by a Security Controller in IKEless case*/ notificationspdb_expiresadb-acquire { description"A SPD entry has expired";"An IPsec SA is required. The traffic-selector container contains information about the IP packet that triggers the acquire notification."; leafindexipsec-policy-name { typeuint64;string; mandatory true; description"SPD index. RFC4301 does not mention an index however real implementations (e.g. XFRM or PFKEY_v2 with KAME extensions provide a"It contains the SPD entry name (unique) of the IPsec policyindex to refer a policy. "; } } notification sadb_acquire { description "Athat hits the IP packet required IPsecSASA. It isrequired "; uses base-grouping; uses ic:selector-grouping; // To indicateassumed theconcrete traffic selectorSecurity Controller will have a copy of the information of this policy so it can extract all the information with this unique identifier. The type of IPsec SA is defined in the policy so the Security Controller can also know the type of IPsec SA that must be generated."; } container traffic-selector { description "The IP packet that triggeredthis acquire.the acquire and requires an IPsec SA. Specifically it will contain the IP source/mask and IP destination/mask; protocol (udp, tcp, etc...); and source and destination ports."; uses ic:selector-grouping; } } notificationsadb_expiresadb-expire { description"A"An IPsec SA expiration (soft orhard)"; uses base-grouping;hard)."; leafspi { type ic:ipsec-spi; description "Security Parameter Index";} leaf anti-replay-window { type uint16 { range "0 | 32..1024"; } description "Anti replay window"; } leaf encryption-algorithmipsec-sa-name { typeic:encryption-algorithm-t;string; mandatory true; description"encryption algorithm"It contains the SAD entry name (unique) of the IPsec SA that has expired. It is assumed the Security Controller will have a copy of the IPsec SA information (except the cryptographic material and state data) indexed by this name (unique identifier) so it can know all the information (crypto algorithms, etc.) about the IPsec SA that has expiredSA";in order to perform a rekey (soft lifetime) or delete it (hard lifetime) with this unique identifier."; } leafauthentication-algorithmsoft-lifetime-expire { typeic:integrity-algorithm-t;boolean; default true; description"authentication algorithm of"If this value is true the lifetime expiredSA";is soft. If it is false is hard."; } containersad-lifetime-hardlifetime-current { description"SAD lifetime hard state data"; uses ic:lifetime; }"IPsec SA current lifetime. If soft-lifetime-expired is true this containersad-lifetime-soft { description "SADis set with the lifetime information about current softstate data";lifetime."; uses ic:lifetime; }container sad-lifetime-current} notification sadb-seq-overflow { description"SAD lifetime current"Sequence overflow notification."; leaf ipsec-sa-name { type string; mandatory true; description "It contains the SAD entry name (unique) of the IPsec SA that is about to have sequence number overflow and rollover is not permitted. It is assumed the Security Controller will have a copy of the IPsec SA information (except the cryptographic material and statedata"; uses ic:lifetime;data) indexed by this name (unique identifier) so the it can know all the information (crypto algorithms, etc.) about the IPsec SA that has expired in order to perform a rekey of the IPsec SA."; } } notificationsadb_bad-spisadb-bad-spi { description"Notifiy"Notify when the NSF receives a packet with an incorrect SPI (i.e. not present in theSAD)";SAD)."; leafstatespi { typeic:ipsec-spi;uint32 { range "0..max"; } mandatory"true";true; description "SPI number contained in the erroneous IPsecpacket";packet."; } } }/*module ietf-ipsec*/ <CODE ENDS> Appendix D. Example of IKE case, tunnel mode (gateway-to-gateway) with X.509 certificate authentication. This example shows a XML configuration file sent by the Security Controller to establish a IPsec Security Association between two NSFs in tunnel mode (gateway-to-gateway) with ESP, and authentication based on X.509 certificates using IKEv2. Security Controller | /---- Southbound interface -----\ / \ / \ / \ / \ nsf_h1 nsf_h2 h1---- (:1/:100)===== IPsec_ESP_Tunnel_mode =====(:200/:1)-------h2 2001:DB8:1:/64 (2001:DB8:123:/64) 2001:DB8:2:/64 Figure 7: IKE case, tunnel mode , X.509 certicate authentication. <ipsec-ike xmlns="urn:ietf:params:xml:ns:yang:ietf-ipsec-ike" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"> <pad> <pad-entry> <name>nsf_h1_pad</name> <ipv6-address>2001:DB8:123::100</ipv6-address> <peer-authentication> <auth-method>digital-signature</auth-method> <digital-signature> <cert-data>base64encodedvalue==</cert-data> <private-key>base64encodedvalue==</private-key> <ca-data>base64encodedvalue==</ca-data> </digital-signature> </peer-authentication> </pad-entry> <pad-entry> <name>nsf_h2_pad</name> <ipv6-address>2001:DB8:123::200</ipv6-address> <auth-protocol>ikev2</auth-protocol> <peer-authentication> <auth-method>digital-signature</auth-method> <digital-signature> <!-- RSA Digital Signature --> <ds-algorithm>1</ds-algorithm> <cert-data>base64encodedvalue==</cert-data> <ca-data>base64encodedvalue==</ca-data> </digital-signature> </peer-authentication> </pad-entry> </pad> <conn-entry> <name>nsf_h1-nsf_h2</name> <autostartup>start</autostartup> <version>ikev2</version> <initial-contact>false</initial-contact> <fragmentation>true</fragmentation> <ike-sa-lifetime-soft> <rekey-time>60</rekey-time> <reauth-time>120</reauth-time> </ike-sa-lifetime-soft> <ike-sa-lifetime-hard> <over-time>3600</over-time> </ike-sa-lifetime-hard> <authalg>7</authalg> <!--AUTH_HMAC_SHA1_160--> <encalg>3</encalg> <!--ENCR_3DES --> <dh-group>18</dh-group> <!--8192-bit MODP Group--> <half-open-ike-sa-timer>30</half-open-ike-sa-timer> <half-open-ike-sa-cookie-threshold>15</half-open-ike-sa-cookie-threshold> <local> <local-pad-entry-name>nsf_h1_pad</local-pad-entry-name> </local> <remote> <remote-pad-entry-name>nsf_h2_pad</remote-pad-entry-name> </remote> <spd> <spd-entry> <name>nsf_h1-nsf_h2</name> <ipsec-policy-config> <anti-replay-window>32</anti-replay-window> <traffic-selector> <local-subnet>2001:DB8:1::0/64</local-subnet> <remote-subnet>2001:DB8:2::0/64</remote-subnet> <inner-protocol>any</inner-protocol> <local-ports> <start>0</start> <end>0</end> </local-ports> <remote-ports> <start>0</start> <end>0</end> </remote-ports> </traffic-selector> <processing-info> <action>protect</action> <ipsec-sa-cfg> <pfp-flag>false</pfp-flag> <ext-seq-num>true</ext-seq-num> <seq-overflow>false</seq-overflow> <stateful-frag-check>false</stateful-frag-check> <mode>tunnel</mode> <protocol-parameters>esp</protocol-parameters> <esp-algorithms> <!-- AUTH_HMAC_SHA1_96 --> <integrity>2</integrity> <!-- ENCR_AES_CBC --> <encryption>12</encryption> <tfc-pad>false</tfc-pad> </esp-algorithms> <tunnel> <local>2001:DB8:123::100</local> <remote>2001:DB8:123::200</remote> <df-bit>clear</df-bit> <bypass-dscp>true</bypass-dscp> <ecn>false</ecn> </tunnel> </ipsec-sa-cfg> </processing-info> </ipsec-policy-config> </spd-entry> </spd> <child-sa-info> <!--8192-bit MODP Group --> <pfs-groups>18</pfs-groups> <child-sa-lifetime-soft> <bytes>1000000</bytes> <packets>1000</packets> <time>30</time> <idle>60</idle> <action>replace</action> </child-sa-lifetime-soft> <child-sa-lifetime-hard> <bytes>2000000</bytes> <packets>2000</packets> <time>60</time> <idle>120</idle> </child-sa-lifetime-hard> </child-sa-info> </conn-entry> </ipsec-ike> Appendix E. Example of IKE-less case, transport mode (host-to-host). This example shows a XML configuration file sent by the Security Controller to establish a IPsec Security association between two NSFs in transport mode (host-to-host) with ESP. Security Controller | /---- Southbound interface -----\ / \ / \ / \ / \ nsf_h1 nsf_h2 (:100)===== IPsec_ESP_Transport_mode =====(:200) (2001:DB8:123:/64) Figure 8: IKE-less case, transport mode. <ipsec-ikeless xmlns="urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"> <spd> <spd-entry> <name> in/trans/2001:DB8:123::200/2001:DB8:123::100 </name> <direction>inbound</direction> <reqid>1</reqid> <ipsec-policy-config> <traffic-selector> <local-subnet>2001:DB8:123::200/128</local-subnet> <remote-subnet>2001:DB8:123::100/128</remote-subnet> <inner-protocol>any</inner-protocol> <local-ports> <start>0</start> <end>0</end> </local-ports> <remote-ports> <start>0</start> <end>0</end> </remote-ports> </traffic-selector> <processing-info> <action>protect</action> <ipsec-sa-cfg> <ext-seq-num>true</ext-seq-num> <seq-overflow>true</seq-overflow> <mode>transport</mode> <protocol-parameters>esp</protocol-parameters> <esp-algorithms> <!--AUTH_HMAC_SHA1_96--> <integrity>2</integrity> <!--ENCR_AES_CBC --> <encryption>12</encryption> </esp-algorithms> </ipsec-sa-cfg> </processing-info> </ipsec-policy-config> </spd-entry> <spd-entry> <name>out/trans/2001:DB8:123::100/2001:DB8:123::200</name> <direction>outbound</direction> <reqid>1</reqid> <ipsec-policy-config> <traffic-selector> <local-subnet>2001:DB8:123::100/128</local-subnet> <remote-subnet>2001:DB8:123::200/128</remote-subnet> <inner-protocol>any</inner-protocol> <local-ports> <start>0</start> <end>0</end> </local-ports> <remote-ports> <start>0</start> <end>0</end> </remote-ports> </traffic-selector> <processing-info> <action>protect</action> <ipsec-sa-cfg> <ext-seq-num>true</ext-seq-num> <seq-overflow>true</seq-overflow> <mode>transport</mode> <protocol-parameters>esp</protocol-parameters> <esp-algorithms> <!-- AUTH_HMAC_SHA1_96 --> <integrity>2</integrity> <!-- ENCR_AES_CBC --> <encryption>12</encryption> </esp-algorithms> </ipsec-sa-cfg> </processing-info> </ipsec-policy-config> </spd-entry> </spd> <sad> <sad-entry> <name>out/trans/2001:DB8:123::100/2001:DB8:123::200</name> <reqid>1</reqid> <ipsec-sa-config> <spi>34501</spi> <ext-seq-num>true</ext-seq-num> <seq-number-counter>100</seq-number-counter> <seq-overflow>true</seq-overflow> <anti-replay-window>32</anti-replay-window> <traffic-selector> <local-subnet>2001:DB8:123::100/128</local-subnet> <remote-subnet>2001:DB8:123::200/128</remote-subnet> <inner-protocol>any</inner-protocol> <local-ports> <start>0</start> <end>0</end> </local-ports> <remote-ports> <start>0</start> <end>0</end> </remote-ports> </traffic-selector> <protocol-parameters>esp</protocol-parameters> <mode>transport</mode> <esp-sa> <encryption> <!-- //ENCR_AES_CBC --> <encryption-algorithm>12</encryption-algorithm> <key>01:23:45:67:89:AB:CE:DF</key> <iv>01:23:45:67:89:AB:CE:DF</iv> </encryption> <integrity> <!-- //AUTH_HMAC_SHA1_96 --> <integrity-algorithm>2</integrity-algorithm> <key>01:23:45:67:89:AB:CE:DF</key> </integrity> </esp-sa> </ipsec-sa-config> </sad-entry> <sad-entry> <name>in/trans/2001:DB8:123::200/2001:DB8:123::100</name> <reqid>1</reqid> <ipsec-sa-config> <spi>34502</spi> <ext-seq-num>true</ext-seq-num> <seq-number-counter>100</seq-number-counter> <seq-overflow>true</seq-overflow> <anti-replay-window>32</anti-replay-window> <traffic-selector> <local-subnet>2001:DB8:123::200/128</local-subnet> <remote-subnet>2001:DB8:123::100/128</remote-subnet> <inner-protocol>any</inner-protocol> <local-ports> <start>0</start> <end>0</end> </local-ports> <remote-ports> <start>0</start> <end>0</end> </remote-ports> </traffic-selector> <protocol-parameters>esp</protocol-parameters> <mode>transport</mode> <esp-sa> <encryption> <!-- //ENCR_AES_CBC --> <encryption-algorithm>12</encryption-algorithm> <key>01:23:45:67:89:AB:CE:DF</key> <iv>01:23:45:67:89:AB:CE:DF</iv> </encryption> <integrity> <!-- //AUTH_HMAC_SHA1_96 --> <integrity-algorithm>2</integrity-algorithm> <key>01:23:45:67:89:AB:CE:DF</key> </integrity> </esp-sa> <sa-lifetime-hard> <bytes>2000000</bytes> <packets>2000</packets> <time>60</time> <idle>120</idle> </sa-lifetime-hard> <sa-lifetime-soft> <bytes>1000000</bytes> <packets>1000</packets> <time>30</time> <idle>60</idle> <action>replace</action> </sa-lifetime-soft> </ipsec-sa-config> </sad-entry> </sad> </ipsec-ikeless> Appendix F. Examples of notifications. Below we show several XML files that represent different types of notifications defined in the IKE-less YANG model, which are sent by the NSF to the Security Controller. The notifications happen in the IKE-less case. <sadb-expire xmlns="urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless"> <ipsec-sa-name>in/trans/2001:DB8:123::200/2001:DB8:123::100</ipsec-sa-name> <soft-lifetime-expire>true</soft-lifetime-expire> <lifetime-current> <bytes>1000000</bytes> <packets>1000</packets> <time>30</time> <idle>60</idle> </lifetime-current> </sadb-expire> Figure 9: Example of sadb-expire notification. <sadb-acquire xmlns="urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless"> <ipsec-policy-name>in/trans/2001:DB8:123::200/2001:DB8:123::100</ipsec-policy-name> <traffic-selector> <local-subnet>2001:DB8:123::200/128</local-subnet> <remote-subnet>2001:DB8:123::100/128</remote-subnet> <inner-protocol>any</inner-protocol> <local-ports> <start>0</start> <end>0</end> </local-ports> <remote-ports> <start>0</start> <end>0</end> </remote-ports> </traffic-selector> </sadb-acquire> Figure 10: Example of sadb-acquire notification. <sadb-seq-overflow xmlns="urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless"> <ipsec-sa-name>in/trans/2001:DB8:123::200/2001:DB8:123::100</ipsec-sa-name> </sadb-seq-overflow> Figure 11: Example of sadb-seq-overflow notification. <sadb-bad-spi xmlns="urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless"> <spi>666</spi> </sadb-bad-spi> Figure 12: Example of sadb-bad-spi notification. 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