--- 1/draft-ietf-i2nsf-sdn-ipsec-flow-protection-07.txt 2020-06-17 09:13:14.765252795 -0700 +++ 2/draft-ietf-i2nsf-sdn-ipsec-flow-protection-08.txt 2020-06-17 09:13:15.129262027 -0700 @@ -1,635 +1,577 @@ I2NSF R. Marin-Lopez Internet-Draft G. Lopez-Millan Intended status: Standards Track University of Murcia -Expires: February 6, 2020 F. Pereniguez-Garcia +Expires: December 19, 2020 F. Pereniguez-Garcia University Defense Center - August 5, 2019 + June 17, 2020 Software-Defined Networking (SDN)-based IPsec Flow Protection - draft-ietf-i2nsf-sdn-ipsec-flow-protection-07 + draft-ietf-i2nsf-sdn-ipsec-flow-protection-08 Abstract - This document describes how providing IPsec-based flow protection by - means of a Software-Defined Network (SDN) controller (aka. Security - Controller) and establishes the requirements to support this service. - It considers two main well-known scenarios in IPsec: (i) gateway-to- - gateway and (ii) host-to-host. The SDN-based service described in - this document allows the distribution and monitoring of IPsec - information from a Security Controller to one or several flow-based - Network Security Function (NSF). The NSFs implement IPsec to protect - data traffic between network resources. + This document describes how to provide IPsec-based flow protection + (integrity and confidentiality) by means of an I2NSF Controller. It + considers two main well-known scenarios in IPsec: (i) gateway-to- + gateway and (ii) host-to-host. The service described in this + document allows the configuration and monitoring of IPsec information + from a I2NSF Controller to one or several flow-based Network Security + Function (NSF) that implement IPsec to protect data traffic. - The document focuses on the NSF Facing Interface by providing models - for configuration and state data required to allow the Security - Controller to configure the IPsec databases (SPD, SAD, PAD) and IKEv2 - to establish Security Associations with a reduced intervention of the - network administrator. + The document focuses on the I2NSF NSF-Facing Interface by providing + YANG data models for configuration and state data required to allow + the I2NSF Controller to configure the IPsec databases (SPD, SAD, PAD) + and IKEv2 to establish IPsec Security Associations with a reduced + intervention of the network administrator. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on February 6, 2020. + This Internet-Draft will expire on December 19, 2020. Copyright Notice - Copyright (c) 2019 IETF Trust and the persons identified as the + Copyright (c) 2020 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 + 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 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 the NSF. . . . . . . . 7 - 5.2.1. Interface Requirements for IKE-less case . . . . . . 8 - 5.3. IKE case vs IKE-less case . . . . . . . . . . . . . . . . 9 - 5.3.1. Rekeying process. . . . . . . . . . . . . . . . . . . 10 - 5.3.2. NSF state loss. . . . . . . . . . . . . . . . . . . . 12 - 5.3.3. NAT Traversal . . . . . . . . . . . . . . . . . . . . 12 - 5.3.4. NSF Discovery . . . . . . . . . . . . . . . . . . . . 13 + 4. SDN-based IPsec management description . . . . . . . . . . . 6 + 4.1. IKE case: IKEv2/IPsec in the NSF . . . . . . . . . . . . 6 + 4.2. IKE-less case: IPsec (no IKEv2) in the NSF. . . . . . . . 7 + 5. IKE case vs IKE-less case . . . . . . . . . . . . . . . . . . 9 + 5.1. Rekeying process . . . . . . . . . . . . . . . . . . . . 10 + 5.2. NSF state loss. . . . . . . . . . . . . . . . . . . . . . 11 + 5.3. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 11 + 5.4. NSF registration and discovery . . . . . . . . . . . . . 12 6. YANG configuration data models . . . . . . . . . . . . . . . 13 - 6.1. IKE case model . . . . . . . . . . . . . . . . . . . . . 14 - 6.2. IKE-less case model . . . . . . . . . . . . . . . . . . . 17 - 7. Use cases examples . . . . . . . . . . . . . . . . . . . . . 20 - 7.1. Host-to-host or gateway-to-gateway under the same - Security Controller . . . . . . . . . . . . . . . . . . . 20 - 7.2. Host-to-host or gateway-to-gateway under different - Security Controllers . . . . . . . . . . . . . . . . . . 24 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 27 - 9.1. IKE case . . . . . . . . . . . . . . . . . . . . . . . . 28 - 9.2. IKE-less case . . . . . . . . . . . . . . . . . . . . . . 29 - 9.3. YANG modules . . . . . . . . . . . . . . . . . . . . . . 29 - 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 - 11.1. Normative References . . . . . . . . . . . . . . . . . . 31 - 11.2. Informative References . . . . . . . . . . . . . . . . . 32 - - Appendix A. Appendix A: Common YANG model for IKE and IKE-less - cases . . . . . . . . . . . . . . . . . . . . . . . 35 - Appendix B. Appendix B: YANG model for IKE case . . . . . . . . 48 - Appendix C. Appendix C: YANG model for IKE-less case . . . . . . 67 - Appendix D. Example of IKE case, tunnel mode (gateway-to- - gateway) with X.509 certificate authentication. . . 77 - Appendix E. Example of IKE-less case, transport mode (host-to- - host). . . . . . . . . . . . . . . . . . . . . . . . 81 - Appendix F. Examples of notifications. . . . . . . . . . . . . . 85 + 6.1. IKE case model . . . . . . . . . . . . . . . . . . . . . 13 + 6.2. IKE-less case model . . . . . . . . . . . . . . . . . . . 16 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 + 8.1. IKE case . . . . . . . . . . . . . . . . . . . . . . . . 22 + 8.2. IKE-less case . . . . . . . . . . . . . . . . . . . . . . 23 + 8.3. YANG modules . . . . . . . . . . . . . . . . . . . . . . 23 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 25 + 10.2. Informative References . . . . . . . . . . . . . . . . . 26 + Appendix A. Common YANG model for IKE and IKE-less cases . . . . 29 + Appendix B. YANG model for IKE case . . . . . . . . . . . . . . 42 + Appendix C. YANG model for IKE-less case . . . . . . . . . . . . 61 + Appendix D. XML configuration example for IKE case (gateway-to- + gateway) . . . . . . . . . . . . . . . . . . . . . . 71 + Appendix E. XML configuration example for IKE-less case (host- + to-host) . . . . . . . . . . . . . . . . . . . . . . 75 + Appendix F. XML notification examples . . . . . . . . . . . . . 79 + Appendix G. Operational use cases examples . . . . . . . . . . . 80 + G.1. Example of IPsec SA establishment . . . . . . . . . . . . 80 + G.1.1. IKE case . . . . . . . . . . . . . . . . . . . . . . 81 + G.1.2. IKE-less case . . . . . . . . . . . . . . . . . . . . 83 + G.2. Example of the rekeying process in IKE-less case . . . . 85 + G.3. Example of managing NSF state loss in IKE-less case . . . 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 86 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 SDN - 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]. + of network resources to a centralized entity, namely SDN Controller. + The SDN controller manages and configures the distributed network + resources and provides an abstracted view of the network resources to + the SDN applications. The SDN application can customize and automate + the operations (including management) of the abstracted network + resources in a programmable manner via this interface [RFC7149] + [ITU-T.Y.3300] [ONF-SDN-Architecture] [ONF-OpenFlow]. - Recently, several network scenarios are considering a centralized way + Recently, several network scenarios are demanding a centralized way of managing different security aspects. For example, Software- Defined WANs (SD-WAN), an SDN extension providing a software abstraction to create secure network overlays over traditional WAN - and branch networks. SD-WAN is based on IPsec as underlying security - protocol and aims to provide flexible, automated, fast deployment and - on-demand security network services such as IPsec SA management from - a centralized point. + and branch networks. SD-WAN is based on IPsec [RFC4301] as an + underlying security protocol and aims to provide flexible, automated, + and rapid deployment, enabling on-demand security network services, + such as IPsec Security Association (IPsec SA) management, from a + centralized point. Additionally, Section 4.3.3 in [RFC8192] + describes another example, a use case for Cloud Data Center Scenario, + entitled Client-Specific Security Policy in Cloud VPNs, where "the + dynamic key management is critical for securing the VPN and the + distribution of policies". These VPNs can be established using + IPsec. The management of IPsec SAs in data centers using a + centralized entity is also an scenario of interest. 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 following the SDN - paradigm. + IPsec SAs from a centralized entity becomes more relevant in the + industry. + + In response to this need, the Interface to Network Security Functions + (I2NSF) charter states that the goal of this working group is "to + define set of software interfaces and data models for controlling and + monitoring aspects of physical and virtual Network Security + Functions". As defined in [RFC8192] an NSF is "a function that is + used to ensure integrity, confidentiality, or availability of network + communication; to detect unwanted network activity; or to block, or + at least mitigate, the effects of unwanted activity". This document + pays special attention to flow-based NSFs that ensure integrity and + confidentiality by means of IPsec. + + In fact, as Section 3.1.9 in [RFC8192] states "there is a need for a + controller to create, manage, and distribute various keys to + distributed NSFs.", however "there is a lack of a standard interface + to provision and manage security associations". Inspired in the SDN + paradigm, the I2NSF framework [RFC8329] defines a centralized entity, + the I2NSF Controller, which manages one or multiple NSFs through a + I2NSF NSF-Facing interface. In this document we define a service + allowing the I2NSF Controller to carry out the key management + procedures. More specifically, we define YANG data models for I2NSF + NSF-Facing interface that allow the I2NSF Controller to configure and + monitor IPsec-enabled flow-based NSFs. IPsec architecture [RFC4301] defines clear separation between the processing to provide security services to IP packets and the key - management procedures to establish the IPsec Security Associations. - In this document, we define a service where the key management - procedures can be carried by an external and centralized entity: the - Security Controller. + management procedures to establish the IPsec Security Associations, + which allows to centralize the key management procedures in the I2NSF + Controller. This document considers two typical scenarios to + autonomously manage IPsec SAs: gateway-to-gateway and host-to-host + [RFC6071]. In these cases, hosts, gateways or both may act as NSFs. + Consideration for the host-to-gateway scenario is out of scope. - First, this document exposes the requirements to support the - protection of data flows using IPsec [RFC4301]. We have considered - two general cases: + For the definition of the YANG data model for I2NSF NSF-Facing + interface, this document considers two general cases, namely: - 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. + 1) IKE case. The NSF implements the Internet Key Exchange version 2 + (IKEv2) protocol and the IPsec databases: the Security Policy + Database (SPD), the Security Association Database (SAD) and the + Peer Authorization Database (PAD). The I2NSF Controller is in + charge of provisioning the NSF with the required information in + the SPD, PAD (e.g. IKE credential) and IKE protocol itself (e.g. + parameters for the IKE_SA_INIT negotiation). 2) IKE-less case. The NSF only implements the IPsec databases (no - IKE implementation). The Security Controller will provide the + IKE implementation). The I2NSF Controller will provide the required parameters to create valid entries in the SPD and the SAD into the NSF. Therefore, the NSF will have only support for - IPsec while automated key management functionality is moved to - the Security Controller. + IPsec while key management functionality is moved to the I2NSF + 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 - PAD entries, the IKE credential and information related with the IKE - negotiation (e.g. IKE_SA_INIT). IKE-less case requires the - management of SPD and SAD entries. Based on YANG models in + In both cases, a data model for the I2NSF NSF-Facing interface is + required to carry out this provisioning in a secure manner between + the I2NSF Controller and the NSF. Based on YANG models in [netconf-vpn] and [I-D.tran-ipsecme-yang], RFC 4301 [RFC4301] and RFC 7296 [RFC7296], this document defines the required interfaces with a YANG model for configuration and state data for IKE, PAD, SPD and SAD (see Appendix A, Appendix B and Appendix C). Examples of the usage - of these models can found in Appendix D, Appendix E and Appendix F. + of these models can be 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]. In these - cases, hosts, 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. The analysis of the host-to-gateway - (roadwarrior) scenario is out of scope of this document. + In summary, the objetives of this I-D are: - 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. In - fact,this I-D could be considered as a proper use case for this - particular challenge in [RFC8192]. + o To describe the architecture for the I2NSF-based IPsec management, + which allows the establishment and management of IPsec security + associations from the I2NSF Controller in order to protect + specific data flows between two flow-based NSFs implementing + IPsec. + + o To map this architecture to the I2NSF Framework. + + o To define the interfaces required to manage and monitor the IPsec + SAs in the NSF from a I2NSF Controller. YANG data models are + defined for configuration and state data for IPsec and IKEv2 + management through the I2NSF NSF-Facing interface. 2. Requirements Language 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 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: + This document uses the terminology described in [RFC8329], [RFC8192], + [RFC4301],[RFC7296], [RFC6241], [ITU-T.Y.3300], The following term is + defined in [ITU-T.Y.3300]: - 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 Software-Defined Networking. - o Flow/Data Flow. Set of network packets sharing a set of - characteristics, for example IP dst/src values or QoS parameters. + The following terms are in defined in [RFC8192]: - o Security Controller. An 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 NSF. - o Network Security Function (NSF). Software that provides a set of - security-related services. + o Flow-based NSF. - o Flow-based NSF. A NSF that inspects network flows according to a - set of policies intended for enforcing security properties. The - NSFs considered in this document fall into this classification. + The following terms are defined in [RFC4301]: - 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 Peer Authorization Database (PAD). - o Internet Key Exchange (IKE) v2. 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), Diffie-Hellman (DH) groups, IPsec SAs parameters - and algorithms for IKE SA negotiation, etc. + o Security Associations Database (SAD). - o Security Policy Database (SPD). It includes information about - IPsec policies direction (in, out), local and remote addresses - (traffic selectors information), inbound and outboud IPsec SAs, - etc. + o Security Policy Database (SPD). - 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. + The following term is defined in [RFC6437]: - o Peer Authorization Database (PAD). It provides the link between - the SPD and a security association management protocol. It is - used when the NSF deploys IKE implementation (IKE case). + o Flow/traffic flow. -4. Objectives + The following terms is defined in [RFC7296]: - 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 Internet Key Exchange version 2 (IKEv2). - 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. + The following terms are defined in [RFC6241]: -5. SDN-based IPsec management description + o Configuration data. + + o Configuration datastore. + + o State date. + + o Startup configuration datastore. + + o Running configuration datastore. + +4. SDN-based IPsec management description As mentioned in Section 1, two cases are considered, depending on whether the NSF ships an IKEv2 implementation or not: IKE case and IKE-less case. -5.1. IKE case: IKE/IPsec in the NSF +4.1. IKE case: IKEv2/IPsec in the NSF - In this case the NSF ships an IKEv2 implementation besides the IPsec - support. The Security Controller is in charge of managing and - applying IPsec 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. cryptographic - algorithms for establishing an IKE SA) to the NSF for the IKE + In this case, the NSF ships an IPsec implementation with IKEv2 + support. The I2NSF Controller is in charge of managing and applying + IPsec connection information (determining which nodes need to start + an IKEv2/IPsec session, identifying the type of traffic to be + protected, deriving and delivering IKEv2 Credentials such as a pre- + shared key, certificates, etc.), and applying other IKEv2 + configuration parameters (e.g. cryptographic algorithms for + establishing an IKEv2 SA) to the NSF necessary for the IKEv2 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 translates these requirements into IKE, SPD and PAD - entries that will be installed into the NSF (through the NSF Facing + the IPsec SAs. The I2NSF User establishes the IPsec requirements and + information about the end points information (through the I2NSF + Consumer-Facing Interface, [RFC8329]), and the I2NSF Controller + translates these requirements into IKEv2, SPD and PAD entries that + will be installed into the NSF (through the I2NSF NSF-Facing Interface). With that information, the NSF can just run IKEv2 to - establish the required IPsec SA (when the data flow needs + establish the required IPsec SA (when the traffic flow needs protection). Figure 1 shows the different layers and corresponding functionality. +-------------------------------------------+ - |IPsec Management/Orchestration Application | Client or - | I2NSF Client | App Gateway + | IPsec Management System | I2NSF User +-------------------------------------------+ - | Client Facing Interface + | + | I2NSF Consumer-Facing + | Interface +-------------------------------------------+ - Vendor | Application Support | - Facing<->|-------------------------------------------| Security - Interface| IKE Credential,PAD and SPD entries Distr. | Controller + | IKEv2 Configuration, PAD and SPD Entries | I2NSF + | Distribution | Controller +-------------------------------------------+ - | NSF Facing Interface + | + | I2NSF NSF-Facing + | Interface +-------------------------------------------+ - | I2NSF Agent | - |-------------------------------------------| Network - | IKE | IPsec(SPD,PAD) | Security - |-------------------------------------------| Function - | Data Protection and Forwarding | + | IKEv2 | IPsec(PAD, SPD) | Network + |-------------------------------------------| Security + | IPsec Data Protection and Forwarding | Function +-------------------------------------------+ 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-based NSFs. In order to support this - capability in IKE case, the following interface requirements need to - be met: - - o A YANG data model for IKEv2, SPD and PAD configuration data, and - for IKE state data. - - o In scenarios where multiple Security 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. For example, if two gateways need to - establish an IPsec SA and both are under the control of two - different controllers, then both Security Controllers need to - exchange information to properly configure their own NSFs. That - is, the may need to agree on whether IKEv2 authentication will be - based on raw public keys, pre-shared keys, etc. In case of using - pre-shared keys they will have to agree in the PSK. + I2NSF-based IPsec flow protection services provide dynamic and + flexible management of IPsec SAs in flow-based NSFs. In order to + support this capability in the IKE case, a YANG data model for IKEv2, + SPD and PAD configuration data, and for IKEv2 state data MUST be + defined for the I2NSF NSF-Facing Interface. -5.2. IKE-less case: IPsec (no IKEv2) in the NSF. +4.2. IKE-less case: IPsec (no IKEv2) in the NSF. - In this case, the NSF does not deploy IKEv2 and, therefore, the - Security Controller has to perform the IKE security functions and - management of IPsec SAs by populating and managing the SPD and the - SAD. + In this case, the NSF does not deploy IKEv2 and, therefore, the I2NSF + Controller has to perform the IKEv2 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 + | IPsec Management System | I2NSF User +-----------------------------------------+ - | Client Facing Interface + | + | I2NSF Consumer-Facing Interface + | +-----------------------------------------+ - Vendor| Application Support | - Facing<->|-----------------------------------------| Security - Interface| SPD, SAD and PAD Entries Distr. | Controller + | SPD and SAD Entries | I2NSF + | Distribution | Controller +-----------------------------------------+ - | NSF Facing Interface + | + | I2NSF NSF-Facing Interface + | +-----------------------------------------+ - | I2NSF Agent | Network + | IPsec (SPD, SAD) | Network |-----------------------------------------| Security - | IPsec (SPD,SAD) | Function (NSF) - |-----------------------------------------| - | Data Protection and Forwarding | + | IPsec Data Protection and Forwarding | Function +-----------------------------------------+ - 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 translates these 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 requirements - need to be met: + Figure 2: IKE-less case: IPsec (no IKEv2) in the NSF - o A YANG data model for configuration data for SPD and SAD and for - state data for SAD. + As shown in Figure 2, when an I2NSF User enforces flow-based + protection policies through the Consumer-Facing Interface, the I2NSF + Controller translates these 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. - 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. + In order to support the IKE-less case, a YANG data model for SPD and + SAD configuration data and SAD state data MUST be defined for the + NSF-Facing Interface. - Specifically, the IKE-less case assumes that the SDN controller has + Specifically, the IKE-less case assumes that the I2NSF Controller has to perform some security functions that IKEv2 typically does, namely (non-exhaustive): o IV generation. o Prevent counter resets for the same key. o Generation of pseudo-random cryptographic keys for the IPsec SAs. - o Rekey of the IPsec SAs based on notifications from the NSF (i.e. - expire). - o Generation of the IPsec SAs when required based on notifications (i.e. sadb-acquire) from the NSF. + o Rekey of the IPsec SAs based on notifications from the NSF (i.e. + expire). + o NAT Traversal discovery and management. Additionally to these functions, another set of tasks must be - performed by the Security Controller (non-exhaustive list): + performed by the I2NSF 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 +5. IKE case vs IKE-less case - In principle, IKE case is 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 - the IKE configuration sent by the Security Controller can be enforced - in runtime. + In principle, the IKE case is easier to deploy than the IKE-less case + because current flow-based NSFs (either hosts or gateways) have + access to IKEv2 implementations. While gateways typically deploy an + IKEv2/IPsec implementation, hosts can easily install it. As + downside, the NSF needs more resources to hold IKEv2 such as memory + for the IKEv2 implementation, and computation, since each IPsec + security association rekeying MAY involve a Diffie-Hellman exchange. - 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 and managing - 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 in comparison with IKE case. - For example, the Security Controller have to deal with the latency - existing in the path between the Security Controller and the NSF in - order to solve tasks such as, rekey or creation and installation of - new IPsec SAs. However, this is not specific to our contribution but - a general aspect in any SDN-based network. In summary, this overload - may create some scalability and performance issues when the number of - NSFs is high. + Alternatively, IKE-less case benefits the deployment in resource- + constrained NSFs. Moreover, IKEv2 does not need to be performed in + gateway-to-gateway and host-to-host scenarios under the same I2NSF + Controller (see Appendix G.1). On the contrary, the complexity of + creating and managing IPsec SAs is shifted to the I2NSF Controller + since IKEv2 is not in the NSF. As a consequence, this may result in + a more complex implementation in the controller side in comparison + with IKE case. For example, the I2NSF Controller has to deal with + the latency existing in the path between the I2NSF Controller and the + NSF, in order to solve tasks such as rekey, or creation and + installation of new IPsec SAs. However, this is not specific to this + contribution but a general aspect in any SDN-based network. In + summary, this complexity MAY create some scalability and performance + issues when the number of NSFs is high. Nevertheless, literature around SDN-based network management using a - centralized Security Controller is aware about scalability and - performance issues and solutions have been already provided and - discussed (e.g. hierarchical Security Controllers; having multiple - replicated Security Controllers, dedicated high-speed management - networks, etc). In the context of SDN-based IPsec management, one + centralized controller (like the I2NSF Controller) is aware about + scalability and performance issues and solutions have been already + provided and discussed (e.g. hierarchical controllers; having + multiple replicated controllers, dedicated high-speed management + networks, etc). In the context of I2SNF-based IPsec management, one way to reduce the latency and alleviate some performance issues can be the installation of the IPsec policies and IPsec SAs at the same - time (proactive mode, as described in Section 7.1) instead of waiting - for notifications (e.g. a notification sadb-acquire when a new IPsec - SA is required) to proceed with the IPsec SA installations (reactive - mode). Another way to reduce the overhead and the potential - scalability and performance issues in the Security Controller is to - apply the IKE case described in this document, since the IPsec SAs - are managed between NSFs without the involvement of the Security - Controller at all, except by the initial IKE configuration provided - by the Security Controller. Other solutions, such as Controller-IKE + time (proactive mode, as described in Appendix G.1) instead of + waiting for notifications (e.g. a notification sadb-acquire when a + new IPsec SA is required) to proceed with the IPsec SA installation + (reactive mode). Another way to reduce the overhead and the + potential scalability and performance issues in the I2NSF Controller + is to apply the IKE case described in this document, since the IPsec + SAs are managed between NSFs without the involvement of the I2NSF + Controller at all, except by the initial configuration (i.e. IKEv2, + PAD and SPD entries) provided by the I2NSF Controller. Other + solutions, such as Controller-IKE [I-D.carrel-ipsecme-controller-ike], have proposed that NSFs provide - their DH public keys to the Security Controller, so that the Security + their DH public keys to the I2NSF Controller, so that the I2NSF Controller distributes all public keys to all peers. All peers can calculate a unique pairwise secret for each other peer and there is no inter-NSF messages. A rekey mechanism is further described in [I-D.carrel-ipsecme-controller-ike]. In terms of security, IKE case provides better security properties - than IKE-less case, as we discuss in section Section 9. The main - reason is that the NSFs are generating the session keys and not the - Security Controller. - -5.3.1. Rekeying process. - - For IKE case, the rekeying process is carried out by IKEv2, following - the information defined in the SPD and SAD. 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 a sadb-expire notification or it decides - so, based on lifetime state data obtained from the NSF. - - To explain the rekeying process between two IPsec NSFs A and B, let - assume that SPIa1 identifies the inbound IPsec SA in A, and SPIb1 the - inbound IPsec SA in B. The rekeying process will take the following - steps: - - 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 inbound IPsec A are correctly - installed. Then it proceeds to send in parallel to A and B, 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 IPsec SAs are ready. + than IKE-less case, as we discuss in section Section 8. The main + reason is that the NSFs generate the session keys and not the I2NSF + Controller. - 3. Once the Security Controller receives confirmation from A and B - that the outbound IPsec SAs have been installed, the Security - Controller, in parallel, deletes the old IPsec SAs from A - (inbound SPIa1 and outbound SPIb1) and B (outbound SPIa1 and - inbound SPIb1). +5.1. Rekeying process - If some of the operations in step 1 fail (e.g. the NSF A reports an - error when the Security Controller is trying to install a new inbound - IPsec SA) the Security Controller must perform rollback operations by - removing any new inbound SA that had been successfully installed - during step 1. + Performing a rekey for IPsec SAs is an important operation during the + IPsec SAs management. With the YANG data models defined in this + document the I2NSF Controller can configure and conduct the rekey + process. Depending on the case, the rekey process is different. - If step 1 is successful but some of the operations in step 2 fails - (e.g. the NSF A reports an error when the Security Controller is - trying to install the new outbound IPsec SA), the Security Controller - must perform a rollback operation by deleting any new outbound SA - that had been successfully installed during step 2 and by deleting - the inbound SAs created in step 1. + For the IKE case, the rekeying process is carried out by IKEv2, + following the information defined in the SPD and SAD (i.e. based on + the IPsec SA lifetime established by the I2NSF Controller using the + YANG data model defined in this document). Therefore, IPsec + connections will live unless something different is required by the + I2NSF User or the I2NSF Controller detects something wrong. - If the steps 1 an 2 are successful and the step 3 fails the Security - Controller will avoid any rollback of the operations carried out in - step 1 and step 2 since new and valid IPsec SAs were created and are - functional. The Security Controller may reattempt to remove the old - inbound and outbound SAs in NSF A and NSF B several times until it - receives a success or it gives up. In the last case, the old IPsec - SAs will be removed when the hard lifetime is reached. + For the IKE-less case, the I2NSF Controller MUST take care of the + rekeying process. When the IPsec SA is going to expire (e.g. IPsec + SA soft lifetime), it MUST create a new IPsec SA and it MAY remove + the old one (if a IPsec SA lifetime has not been defined). This + rekeying process starts when the I2NSF Controller receives a sadb- + expire notification or it decides so, based on lifetime state data + obtained from the NSF. How the I2NSF Controller implements an + algorithm for the rekey process is out of the scope of this document. + Nevertheless, an example of how this rekey could be performed is in + Appendix G.2. -5.3.2. NSF state loss. +5.2. NSF state loss. If one of the NSF restarts, it will lose the IPsec state (affected - NSF). By default, the Security Controller can assume that all the - state has been lost and therefore it will have to send IKEv2, SPD and - PAD information to the NSF in the IKE case, and SPD and SAD - information in IKE-less case. + NSF). By default, the I2NSF 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 the IKE-less case. - In both cases, the Security Controller is aware of the affected NSF + In both cases, the I2NSF Controller is aware of the affected NSF (e.g. the NETCONF/TCP connection is broken with the affected NSF, the - Security Controller is receiving sadb-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. + I2NSF Controller is receiving sadb-bad-spi notification from a + particular NSF, etc.). Moreover, the I2NSF Controller keeps a list + of 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 + In the IKE case, the I2NSF 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. Finally, - the Security Controller will instruct the affected NSF to start the + the I2NSF 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 it will delete the old IPsec SAs on the non-failed - nodes, established with the failed node (step 1). This prevents the - non-failed nodes from leaking plaintext. If the affected node comes - to live, the Security Controller will configure the new inbound IPsec - SAs between the affected node and all the nodes it 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). + Alternatively, IKEv2 configuration MAY be made permanent between NSFs + reboots without compromising security by means of the startup + configuration datastore in the NSF. This way, each time a NSF + reboots it will use that configuration for each rebooting. It would + imply avoiding to contact with the I2NSF Controller. - Nevertheless other more optimized options can be considered (e.g. - making the IKEv2 configuration permanent between reboots). + In the IKE-less case, the I2NSF Controller SHOULD delete the old + IPsec SAs in the non-failed nodes established with the affected NSF. + Once the affected node restarts, the I2NSF Controller MUST take the + necessary actions to reestablish IPsec protected communication + between the failed node and those others having IPsec SAs with the + affected NSF. How the I2NSF Controller implements an algorithm for + managing a potential NSF state loss is out of the scope of this + document. Nevertheless, an example of how this could be performed is + described in Appendix G.3. -5.3.3. NAT Traversal +5.3. NAT Traversal In the IKE case, IKEv2 already provides a mechanism to detect whether some of the peers or both are located behind a NAT. If there is a NAT network configured between two peers, it is required to activate the usage of UDP or TCP/TLS encapsulation for ESP packets ([RFC3948], [RFC8229]). Note that the usage of IPsec transport mode when NAT is required MUST 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 network under its control. This view is built - either requesting information to the NSFs under its control, or - because these NSFs inform the Security Controller. Based on this - information, the Security Controller can guess if there is a NAT - configured between two hosts, and apply the required policies to both - NSFs besides activating the usage of UDP or TCP/TLS encapsulation of - ESP packets ([RFC3948], [RFC8229]). + In the IKE case, IKEv2 already provides a mechanism to detect whether + some of the peers or both are located behind a NAT. If there is a + NAT network configured between two peers, it is required to activate + the usage of UDP or TCP/TLS encapsulation for ESP packets ([RFC3948], + [RFC8229]). Note that the usage of IPsec transport mode when NAT is + required MUST NOT be used in this specification. - 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 - [RFC8512] a data model for NAT management. The Security Controller - can use this NETCONF module with a NSF to collect NAT information or - even configure a NAT network. In any case, if this NETCONF module is - not available in the NSF and the Security Controller does not have a - mechanism to know whether a host is behind a NAT or not, then the IKE - case should be the right choice and not the IKE-less case. + In the IKE-less case, the NSF does not have the assistance of the + IKEv2 implementation to detect if it is located behind a NAT. If the + NSF does not have any other mechanism to detect this situation, the + I2NSF Controller SHOULD implement a mechanism to detect that case. + The SDN paradigm generally assumes the I2NSF Controller has a view of + the network under its control. This view is built either requesting + information to the NSFs under its control, or because these NSFs + inform the I2NSF Controller. Based on this information, the I2NSF + Controller MAY 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]). The interface for discovering if the NSF is behind a NAT + is out of scope of this document. -5.3.4. NSF Discovery + If the I2NSF Controller does not have any mechanism to know whether a + host is behind a NAT or not, then the IKE-case MUST be used and not + the IKE-less case. + +5.4. NSF registration and discovery + + NSF registration refers to the process of facilitating the I2NSF + Controller information about a valid NSF such as certificate, IP + address, etc. This information is incorporated to a list of NSFs + under its control. 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. + can operate in this system, it MUST be registered in the I2NSF + Controller. In this way, when the NSF starts and establishes a + connection to the I2NSF 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. + the I2NSF Controller, the I2NSF Controller MUST discover certain + capabilities of this NSF, such as what is the cryptographic suite + supported, authentication method, the support of the IKE case and/or + the IKE-less case, etc. + + The registration and discovery processes are out of the scope of this + document. 6. YANG configuration data models In order to support the IKE and IKE-less cases we have modeled the different parameters and values that must be configured to manage - IPsec SAs. Specifically, IKE requires modeling IKEv2, SPD and PAD, - 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, we only show - a simplified view of the ietf-ipsec-ike and ietf-ipsec-ikeless - models. + IPsec SAs. Specifically, the IKE case requires modeling IKEv2 + configuration parameters, SPD and PAD, while the 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, we 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] or 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 @@ -773,30 +715,71 @@ +--ro half-open-cookies? uint64 Appendix D shows an example of IKE case configuration for a NSF, in tunnel mode (gateway-to-gateway), with NSFs authentication based on X.509 certificates. 6.2. IKE-less case model For 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], though with some simplications. For example, each IPsec - policy (spd-entry) contains one traffic selector, instead a list of - them. The reason is that we have observed real kernel - implementations only admit a traffic selector per IPsec policy. + [RFC4301], though with some changes, namely: - The definition of the SAD model has been extracted from the - specification in section 4.4.2 in [RFC4301]. Note that this model - not only allows to associate an IPsec SA with its corresponding - policy through the specific traffic selector but also an identifier - (reqid). + o Each IPsec policy (spd-entry) contains one traffic selector, + instead of a list of them. The reason is that we have observed + actual kernel implementations only admit a single traffic selector + per IPsec policy. + + o Each IPsec policy contains a identifier (reqid) to relate the + policy with the IPsec SA. This is common in Linux-based systems. + + o Each IPsec policy has only one name and not a list of names. + + o Combined algorithms has been removed because encryption algorithms + MAY include authenticated encryption with associated data (AEAD). + + o Tunnel information has been extended with information about DSCP + mapping and ECN bit. The reason is that we have observed real + kernel implementations admit the configurations of these values. + + The definition of the SAD model has been mainly extracted from the + specification in section 4.4.2 in [RFC4301] though with some changes, + namely: + + o Each IPsec SA (sad-entry) contains one traffic selector, instead + of a list of them. The reason is that we have observed actual + kernel implementations only admit a single traffic selector per + IPsec SA. + + o Each IPsec SA contains a identifier (reqid) to relate the policy + with the IPsec Policy. The reason is that we have observed real + kernel implementations allow to include this value. + + o Each IPsec SA has also a name in the same way as IPsec policies. + + o Combined algorithm has been removed because encryption algorithm + MAY include authenticated encryption with associated data (AEAD). + + o Tunnel information has been extended with information about + Differentiated Services Code Point (DSCP) mapping and Explicit + Congestion Notificsation (ECN) bit. The reason is that we have + observed actual kernel implementations admit the configurations of + these values. + + o Lifetime of the IPsec SAs also include idle time and number of IP + packets as threshold to trigger the lifetime. The reason is that + we have observed actual kernel implementations allow to set these + types of lifetimes. + + o Information to configure the type of encapsulation (encapsulation- + type) for IPsec ESP packets in UDP ([RFC3948]), TCP ([RFC8229]) or + TLS ([RFC8229]) has been included. The notifications model has been defined using as reference the PF_KEYv2 standard in [RFC2367]. module: ietf-ipsec-ikeless +--rw ipsec-ikeless +--rw spd | +--rw spd-entry* [name] | +--rw name string | +--rw direction? ic:ipsec-traffic-direction @@ -927,291 +909,21 @@ | +--ro ipsec-sa-name string +---n sadb-bad-spi +--ro spi uint32 Appendix E shows an example of IKE-less case configuration for a NSF, in transport mode (host-to-host), with NSFs authentication based on shared secrets. For the IKE-less case, Appendix F shows examples of IPsec SA expire, acquire, sequence number overflow and bad SPI notifications. -7. Use cases examples - - This section explains how different traditional configurations, that - is, host-to-host and gateway-to-gateway, are deployed using this SDN- - based IPsec management service. In turn, these configurations will - be typical in modern networks where, for example, virtualization will - be key. - -7.1. Host-to-host or gateway-to-gateway under the same Security - Controller - +----------------------------------------+ - | Security Controller | - | | - (1)| +--------------+ (2)+--------------+ | - Flow-based ------> |Translate into|--->| South. Prot. | | - Security. Pol. | |IPsec Policies| | | | - | +--------------+ +--------------+ | - | | | | - | | | | - +--------------------------|-----|-------+ - | | - | (3) | - |-------------------------+ +---| - V V - +----------------------+ +----------------------+ - | NSF A |<=======>| NSF B | - |IKEv2/IPsec(SPD/PAD) | |IKEv2/IPsec(SPD/PAD) | - +----------------------+ (4) +----------------------+ - - Figure 3: Host-to-host / gateway-to-gateway single Security - Controller for the IKE case. - - Figure 3 describes the IKE case: - - 1. The administrator defines general flow-based security policies. - The Security Controller looks for the NSFs involved (NSF A and - NSF B). - - 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 - includes the SPD and PAD entries in both NSF A and NSF B. If - some of operations with NSF A and NSF B fail the Security - Controller will stop the process and perform a rollback operation - by deleting any IKEv2, SPD and PAD configuration that had been - successfully installed in NSF A or B. - - 4. If the previous step is successful, the flow is protected by - 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 - +------------------+ +------------------+ - | NSF A |<=====>| NSF B | - |IPsec(SPD/SAD) | 4) |IPsec(SPD/SAD) | - +------------------+ +------------------+ - - Figure 4: Host-to-host / gateway-to-gateway single Security - 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, the Security Controller does not run any IKEv2 - 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 same Security - Controller. - - Figure 4 describes the IKE-less case, when a data packet needs to be - protected in the path between the NSF A and NSF B: - - 1. The administrator establishes the flow-based security policies, - 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 inserts these entries in both NSF A and - NSF B IPsec databases (SPD and SAD). The following text - describes how this happens between two NSFs A and B: - - * The Security Controller chooses two random values as SPIs: for - example, SPIa1 for NSF A and SPIb1 for NSF B. These numbers - MUST NOT be in conflict with any IPsec SA in NSF A or NSF B. - It also generates fresh cryptographic material for the new - inbound/outbound IPsec SAs and their parameters and send - simultaneously the new inbound IPsec SA with SPIa1 and new - outbound IPsec SAs with SPIb1 to NSF A; and the new inbound - IPsec SA with SPIb1 and new outbound IPsec SAs with SPIa1 to - B, together with the corresponding IPsec policies. - - * Once the Security Controller receives confirmation from NSF A - and NSF B, the controller knows that the IPsec SAs are - correctly installed and ready. - - If some of the operations described above fails (e.g. the NSF A - reports an error when the Security Controller is trying to - install the SPD entry, the new inbound and outbound IPsec SAs) - the Security Controller must perform rollback operations by - deleting any new inbound or outbound SA and SPD entry that had - been successfully installed in any of the NSFs (e.g NSF B) and - stop the process (NOTE: the Security Controller may retry several - times before giving up). Other alternative to this operation is: - the Security Controller sends first the IPsec policies and new - inbound IPsec SAs to A and B and once it obtains a successful - confirmation of these operations from NSF A and NSF B, it - proceeds with installing to the new outbound IPsec SAs. However, - this may increase the latency to complete the process. As an - advantage, no traffic is sent over the network until the IPsec - SAs are completely operative. In any case other alternatives may - be possible. Finally, it is worth mentioning that the Security - Controller associates a lifetime to the new IPsec SAs. When this - lifetime expires, the NSF will send a sadb-expire notification to - the Security Controller in order to start the rekeying process. - - 4. The flow is protected with the IPsec SA established by the - Security Controller. - - Instead of installing IPsec policies in the SPD and IPsec SAs in the - SAD in step 3 (proactive mode), it is also possible that the Security - Controller only installs the SPD entries in step 3 (reactive mode). - 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 needs - SAD entries with the IPsec SAs to process the data packet. In such - as reactive mode, since IPsec policies are already installed in the - SPD, the Security Controller installs first the new IPsec SAs in NSF - A and B with the operations described in step 3 but without sending - any IPsec policies. Again, if some of the operations installing the - new inbound/outbound IPsec SAs fail, the Security Controller stops - the process and performs a rollback operation by deleting any new - inbound/outbound SAs that had been successfully installed. - - 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-less cases), this system has various - advantages: - - 1. It allows to create IPsec SAs among two NSFs, based only on the - application of general Flow-based Security Policies at the - application layer. Thus, administrators can manage all security - associations in a centralized point with an abstracted view of - the network. - - 2. Any NSF deployed in the system does not need manual - configuration, therefore allowing its deployment in an automated - manner. - -7.2. Host-to-host or gateway-to-gateway under different Security - Controllers - - It is also possible that two NSFs (i.e. NSF A and NSF B) 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 - +--------------------+ +--------------------+ - | NSF A |<=======>| NSF B | - |IKEv2/IPsec(SPD/PAD)| |IKEv2/IPsec(SPD/PAD)| - +--------------------+ (5) +--------------------+ - - Figure 5: Different Security Controllers in the IKE case. - - Figure 5 describes IKE case when two Security 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 NSF A and NSF B, but the NSF B is under the control - of another Security Controller (Security Controller B), so it - starts negotiations with the other controller to agree on the - IPsec SPD policies and IKEv2 credentials for their respective - NSFs. NOTE: This may require extensions in the East/West - interface. - - 4. Then, both Security Controllers enforce the IKEv2 credentials, - related parameters and the SPD and PAD entries in their - respective NSFs. - - 5. The flow is protected with the IPsec SAs established with IKEv2 - between both NSFs. - - +--------------+ +--------------+ - | | | | - Flow-based. ---> | | <---Flow-based - Prot. | Security |<===========>| Security |Sec. - Pol.(1)| Controller | (3) | Controller |Pol. (2) - | A | | B | - +--------------+ +--------------+ - | | - | (4) (4) | - V V - +--------------+ (5) +--------------+ - | NSF A |<==============>| NSF B | - |IPsec(SPD/SAD)| |IPsec(SPD/SAD)| - +--------------+ +--------------+ - - Figure 6: Different Security Controllers in the IKE-less case. - - Figure 6 describes IKE-less case when two Security 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 NSF B - and NSF B MUST be protected. Nevertheless, it notices that NSF B - is under the control of another Security 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 +7. IANA Considerations This document registers three URIs in the "ns" subregistry of the IETF XML Registry [RFC3688]. Following the format in [RFC3688], the following registrations are requested: URI: urn:ietf:params:xml:ns:yang:ietf-ipsec-common Registrant Contact: The I2NSF WG of the IETF. XML: N/A, the requested URI is an XML namespace. URI: urn:ietf:params:xml:ns:yang:ietf-ipsec-ike @@ -1234,106 +946,110 @@ Name: ietf-ipsec-ike Namespace: urn:ietf:params:xml:ns:yang:ietf-ipsec-ike Prefix: ike Reference: RFC XXXX Name: ietf-ipsec-ikeless Namespace: urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless Prefix: ikeless Reference: RFC XXXX -9. Security Considerations +8. 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]. + [ITU-T.Y.3300] and [RFC7426]. - 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, when 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 one hand, it is important to note that there MUST exist a + security association between the I2NSF Controller and the NSFs to + protect the critical information (cryptographic keys, configuration + parameter, etc.) exchanged between these entities. On the other hand, if encryption is mandatory for all traffic of a NSF, 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 + cleartext packet leaks. This default policy MUST be pre-configured + in the startup configuration datastore in the NSF before the NSF + contacts the I2NSF Controller. Moreover, the startup configuration + datastore MUST be also pre-configured with the required ALLOW + policies that allow to communicate the NSF with the I2NSF Controller + once the NSF is deployed. This pre-configuration step is not carried + out by the I2NSF 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. + always first apply the configuration in the startup configuration + before contacting the I2NSF Controller. Finally, we have divided this section in two parts in order to analyze different security considerations for both cases: NSF with IKEv2 (IKE case) and NSF without IKEv2 (IKE-less case). In general, - the Security Controller, as typically in the SDN paradigm, is a - target for different type of attacks. Thus, the Security Controller - is a key entity in the infrastructure and MUST be protected - accordingly. In particular, the Security Controller will handle - cryptographic material so that the attacker may try to access this - information. Although we can assume this attack will not likely to - happen due to the assumed security measurements to protect the - Security Controller, it deserves some analysis in the hypothetical - case the attack occurs. The impact is different depending on the IKE - case or IKE-less case. + the I2NSF Controller, as typically in the SDN paradigm, is a target + for different type of attacks [SDNSecServ] and [SDNSecurity]. Thus, + the I2NSF Controller is a key entity in the infrastructure and MUST + be protected accordingly. In particular, the I2NSF Controller will + handle cryptographic material so that the attacker may try to access + this information. Although we can assume this attack will not likely + to happen due to the assumed security measurements to protect the + I2NSF 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. -9.1. IKE case +8.1. IKE case - In IKE case, the Security Controller sends IKE credentials (PSK, + In the IKE case, the I2NSF Controller sends IKEv2 credentials (PSK, public/private keys, certificates, etc.) to the NSFs using the - security association between Security Controller and NSFs. The - general recommendation is that the Security Controller MUST NOT store - the IKE credentials after distributing them. Moreover, the NSFs MUST - NOT allow the reading of these values once they have been applied by - the Security Controller (i.e. write only operations). One option is - to return always the same value (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, it might - have access to 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 Controller MUST remove the PSK immediately - after generating and distributing it. Moreover, the PSK MUST have a - proper length (e.g. minimum 128 bit length) and strength. When - public/private keys are used, the Security Controller MAY generate - both public key and private key. In such a case, the Security - Controller MUST remove the associated private key immediately after - distributing them to the NSFs. Alternatively, the NSF could generate - the private key and export only the public key to the Security - Controller. If certificates are used, the NSF MAY generate the - private key and exports the public key for certification to the - Security Controller. How the NSF generates these cryptographic - material (public key/private keys) and export the public key, or it - is instructed to do so, it is out of the scope of this document. + security association between I2NSF Controller and NSFs. The I2NSF + Controller MUST NOT store the IKEv2 credentials after distributing + them. Moreover, the NSFs MUST NOT allow the reading of these values + once they have been applied by the I2NSF Controller (i.e. write only + operations). One option is to always return the same value (i.e. all + 0s) if a read operation is carried out. -9.2. IKE-less case + If the attacker has access to the I2NSF Controller during the period + of time that key material is generated, it might have access to the + key material. Since these values are used during NSF authentication + in IKEv2, it may impersonate the affected NSFs. Several + recommendations are important. - In the IKE-less case, the Security Controller sends the IPsec SA + o IKEv2 configurations should adhere to the recommendations in + [RFC8247]. + + o If PSK authentication is used in IKEv2, the I2NSF Controller MUST + remove the PSK immediately after generating and distributing it. + + o When public/private keys are used, the I2NSF Controller MAY + generate both public key and private key. In such a case, the + I2NSF Controller MUST remove the associated private key + immediately after distributing them to the NSFs. Alternatively, + the NSF could generate the private key and export only the public + key to the I2NSF Controller. + + o If certificates are used, the NSF MAY generate the private key and + exports the public key for certification to the I2NSF Controller. + How the NSF generates these cryptographic material (public key/ + private keys) and exports the public key it is out of scope of + this document. + +8.2. IKE-less case + + In the IKE-less case, the I2NSF Controller sends the IPsec SA information to the NSF's SAD that includes the private session keys - required for integrity and encryption. The general recommendation is - that it 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 applied (i.e. write only 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 may obtain these values. In other words, the attacker might be - able to observe the IPsec traffic and decrypt, or even modify and re- - encrypt the traffic between peers. + required for integrity and encryption. The I2NSF Controller 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 I2NSF Controller itself) once they + have been applied (i.e. write only operations) into the NSFs. + Nevertheless, if the attacker has access to the I2NSF Controller + during the period of time that key material is generated, it may + obtain these values. In other words, the attacker might be able to + observe the IPsec traffic and decrypt, or even modify and re-encrypt, + the traffic between peers. -9.3. YANG modules +8.3. YANG modules The YANG module specified in this document defines a schema for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446]. The Network Configuration Access Control Model (NACM) [RFC8341] @@ -1351,23 +1067,23 @@ The YANG modules describe configuration data for the IKE case (ietf- ipsec-ike) and IKE-less case (ietf-ipsec-ikeless). There is a common module (ietf-ipsec-common) used in both cases. For the IKE case (ietf-ipsec-ike): /ipsec-ike: The entire container in this module is sensitive to write operations. An attacker may add/modify the credentials to be used for the authentication (e.g. to impersonate a NSF), - the trust root (e.g. changing the trusted CA certificates), - the cryptographic algorithms (allowing a downgrading attack), - the IPsec policies (e.g. by allowing leaking of data traffic by + the trust root (e.g. changing the trusted CA certificates), the + cryptographic algorithms (allowing a downgrading attack), the + IPsec policies (e.g. by allowing leaking of data traffic by changing to a allow policy), and in general changing the IKE SA conditions and credentials between any NSF. For the IKE-less case (ietf-ipsec-ikeless): /ipsec-ikeless: The entire container in this module is sensitive to write operations. An attacker may add/modify/ delete any IPsec policies (e.g. by allowing leaking of data traffic by changing to a allow policy) in the /ipsec-ikeless/ spd container, and add/modify/delete any IPsec SAs between two @@ -1393,31 +1109,31 @@ For the IKE-less case (ietf-ipsec-ikeless): /ipsec-ikeless/sad/ipsec-sa-config/esp-sa: This container includes symmetric keys for the IPsec SAs. For example, encryption/key contains a ESP encryption key value and encryption/iv contains a initialization vector value. Similarly, integrity/key has ESP integrity key value. Those values must not be read by anyone and are protected by the NACM extension "default-deny-all" in this document. -10. Acknowledgements +9. Acknowledgements Authors want to thank Paul Wouters, Valery Smyslov, Sowmini Varadhan, David Carrel, Yoav Nir, Tero Kivinen, Martin Bjorklund, Graham Bartlett, Sandeep Kampati, Linda Dunbar, Carlos J. Bernardos, - Alejandro Perez-Mendez, Alejandro Abad-Carrascosa, Ignacio Martinez - and Ruben Ricart for their valuable comments. + Alejandro Perez-Mendez, Alejandro Abad-Carrascosa, Ignacio Martinez, + Ruben Ricart and Roman Danyliw for their valuable comments. -11. References +10. References -11.1. Normative References +10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, . @@ -1437,55 +1153,47 @@ [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, . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . + [RFC8247] Nir, Y., Kivinen, T., Wouters, P., and D. Migault, + "Algorithm Implementation Requirements and Usage Guidance + for the Internet Key Exchange Protocol Version 2 (IKEv2)", + RFC 8247, DOI 10.17487/RFC8247, September 2017, + . + [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . -11.2. Informative References +10.2. Informative References [I-D.carrel-ipsecme-controller-ike] Carrel, D. and B. Weiss, "IPsec Key Exchange using a Controller", draft-carrel-ipsecme-controller-ike-01 (work in progress), March 2019. - [I-D.ietf-i2nsf-terminology] - Hares, S., Strassner, J., Lopez, D., Xia, L., and H. - Birkholz, "Interface to Network Security Functions (I2NSF) - Terminology", draft-ietf-i2nsf-terminology-08 (work in - progress), July 2019. - [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", August 2019. [netconf-vpn] Stefan Wallin, "Tutorial: NETCONF and YANG", January 2014. @@ -1508,56 +1216,64 @@ [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, . [RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap", RFC 6071, DOI 10.17487/RFC6071, February 2011, . + [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, + "IPv6 Flow Label Specification", RFC 6437, + DOI 10.17487/RFC6437, November 2011, + . + [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, . - [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for - System Management", RFC 7317, DOI 10.17487/RFC7317, August - 2014, . - [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, . [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, . [RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229, August 2017, . - [RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C., - Vinapamula, S., and Q. Wu, "A YANG Module for Network - Address Translation (NAT) and Network Prefix Translation - (NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019, - . + [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, + . + + [SDNSecServ] + Scott-Hayward, S., O'Callaghan, G., and P. Sezer, "SDN + Security: A Survey", 2013. + + [SDNSecurity] + Kreutz, D., Ramos, F., and P. Verissimo, "Towards Secure + and Dependable Software-Defined Networks", 2013. [strongswan] CESNET, "StrongSwan: the OpenSource IPsec-based VPN Solution", August 2019. -Appendix A. Appendix A: Common YANG model for IKE and IKE-less cases +Appendix A. Common YANG model for IKE and IKE-less cases file "ietf-ipsec-common@2019-08-05.yang" module ietf-ipsec-common { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec-common"; prefix "ipsec-common"; import ietf-inet-types { prefix inet; } import ietf-yang-types { prefix yang; } @@ -2064,30 +1780,30 @@ leaf action { type ipsec-spd-action; default discard; description "If bypass or discard, container ipsec-sa-cfg is empty."; } container ipsec-sa-cfg { when "../action = 'protect'"; description - "IPSec SA configuration included in the SPD + "IPsec SA configuration included in the SPD entry."; leaf pfp-flag { type boolean; default false; description "Each selector has a Populate From Packet (PFP) flag. If asserted for a given selector X, the flag indicates - that the IPSec SA to be created should + that the IPsec SA to be created should take its value (local IP address, remote IP address, Next Layer Protocol, etc.) for X from the value in the packet. Otherwise, the IPsec SA should take its value(s) for X from the value(s) in the SPD entry."; } leaf ext-seq-num { type boolean; default false; @@ -2210,21 +1926,21 @@ description "Mask used to match XFRM policies and states."; } } } } -Appendix B. Appendix B: YANG model for IKE case +Appendix B. YANG model for IKE case file "ietf-ipsec-ike@2019-08-05.yang" module ietf-ipsec-ike { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec-ike"; prefix "ike"; import ietf-inet-types { prefix inet; } import ietf-yang-types { prefix yang; } @@ -2260,21 +1976,21 @@ Author: Gabriel Lopez-Millan Author: Fernando Pereniguez-Garcia "; description - "This module contains IPSec IKE case model for the SDN-based + "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 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 @@ -2419,21 +2135,21 @@ NSF with identity A will use some particular authentication with remote NSF with identity B and what are the authentication mechanisms allowed to B."; list pad-entry { key "name"; ordered-by user; description "Peer Authorization Database (PAD) entry. It is a list of PAD entries ordered by the - Security Controller."; + I2NSF Controller."; leaf name { type string; description "PAD unique name to identify this entry."; } choice identity { mandatory true; description "A particular IKE peer will be @@ -2645,21 +2361,21 @@ type ct:x509; description "X.509 certificate data - PEM4."; reference "RFC XXX: Common YANG Data Types for Cryptography."; } description - "If the Security Controller + "If the I2NSF Controller knows that the NSF already owns a private key associated to this public key (the NSF generated the pair public key/private key out of band), it will only configure one of the leaf of this choice. The NSF, based on the public key value can know the private key to be used."; @@ -3089,48 +2805,48 @@ description "General information about the IKE SAs. In particular, it provides the current number of IKE SAs."; } } /* container ipsec-ike */ } -Appendix C. Appendix C: YANG model for IKE-less case +Appendix C. YANG model for IKE-less case file "ietf-ipsec-ikeless@2019-08-05.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 + "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"; + organization "IETF I2NSF Working Group"; contact "WG Web: WG List: Author: Rafael Marin-Lopez Author: Gabriel Lopez-Millan @@ -3164,21 +2880,21 @@ revision "2019-08-05" { description "Revision 06"; 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 + I2NSF Controller to configure IPsec policies in the Security Policy Database SPD, and the second allows to configure IPsec Security Associations (IPsec SAs) in the Security Association Database (SAD)."; reference "RFC 4301."; container spd { description "Configuration of the Security Policy Database (SPD.)"; reference "Section 4.4.1.2 in RFC 4301."; @@ -3191,21 +2907,21 @@ mandatory true; description "SPD entry unique name to identify this entry."; } leaf direction { type ic:ipsec-traffic-direction; description "Inbound traffic or outbound traffic. In the IKE-less case the - Security Controller needs to + I2NSF Controller needs to specify the policy direction to be applied in the NSF. In the IKE case this direction does not need to be specified since IKE will determine the direction that IPsec policy will require."; } leaf reqid { type uint64; default 0; @@ -3227,21 +2941,21 @@ } description "The SPD is represented as a list of SPD entries, where each SPD entry represents an IPsec policy."; } /*list spd-entry*/ } /*container spd*/ container sad { description - "Configuration of the IPSec Security Association + "Configuration of the IPsec Security Association Database (SAD)"; reference "Section 4.4.2.1 in RFC 4301."; list sad-entry { key "name"; ordered-by user; leaf name { type string; description "SAD entry unique name to identify this entry."; @@ -3334,21 +3047,21 @@ description "In case the IPsec SA is Encapsulation Security Payload (ESP), it is required to specify encryption and integrity algorithms, and key material."; container encryption { description "Configuration of encryption or - AEAD algorithm for IPSec + AEAD algorithm for IPsec Encapsulation Security Payload (ESP)."; leaf encryption-algorithm { type ic:encryption-algorithm-type; description "Configuration of ESP encryption. With AEAD algorithms, the integrity node is not used."; @@ -3363,21 +3076,21 @@ leaf iv { nacm:default-deny-all; type yang:hex-string; description "ESP encryption IV value."; } } container integrity { description "Configuration of integrity for - IPSec Encapsulation Security + IPsec Encapsulation Security Payload (ESP). This container allows to configure integrity algorithm when no AEAD algorithms are used, and integrity is required."; leaf integrity-algorithm { type ic:integrity-algorithm-type; description "Message Authentication Code (MAC) algorithm to provide @@ -3394,30 +3107,29 @@ container sa-lifetime-hard { description "IPsec SA hard lifetime. The action associated is terminate and hold."; uses ic:lifetime; } container sa-lifetime-soft { description - "IPSec SA soft lifetime."; + "IPsec SA soft lifetime."; uses ic:lifetime; leaf action { type ic:lifetime-action; description "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; @@ -3492,21 +3203,21 @@ "An IPsec SA is required. The traffic-selector container contains information about the IP packet that triggers the acquire notification."; leaf ipsec-policy-name { type string; mandatory true; description "It contains the SPD entry name (unique) of the IPsec policy that hits the IP packet required IPsec SA. It is assumed the - Security Controller will have a copy of the + I2NSF Controller will have a copy of the information of this policy so it can extract all the information with this unique identifier. The type of IPsec SA is defined in the policy so the Security Controller can also know the type of IPsec SA that must be generated."; } container traffic-selector { description "The IP packet that triggered the acquire @@ -3520,21 +3231,21 @@ } notification sadb-expire { description "An IPsec SA expiration (soft or hard)."; leaf ipsec-sa-name { type string; mandatory true; description "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 + the I2NSF Controller will have a copy of the IPsec SA information (except the cryptographic material and state data) indexed by this name (unique identifier) so it can know all the information (crypto algorithms, etc.) about the IPsec SA that has expired in order to perform a rekey (soft lifetime) or delete it (hard lifetime) with this unique identifier."; } leaf soft-lifetime-expire { type boolean; @@ -3554,21 +3265,21 @@ } notification sadb-seq-overflow { description "Sequence overflow notification."; leaf ipsec-sa-name { type string; mandatory true; description "It contains the SAD entry name (unique) of the IPsec SA that is about to have sequence number overflow and rollover is not permitted. - It is assumed the Security Controller will have + It is assumed the I2NSF Controller will have a copy of the IPsec SA information (except the cryptographic material and state data) indexed by this name (unique identifier) so the it can know all the information (crypto algorithms, etc.) about the IPsec SA that has expired in order to perform a rekey of the IPsec SA."; } } notification sadb-bad-spi { description @@ -3579,40 +3290,43 @@ mandatory true; description "SPI number contained in the erroneous IPsec packet."; } } }/*module ietf-ipsec*/ -Appendix D. Example of IKE case, tunnel mode (gateway-to-gateway) with - X.509 certificate authentication. +Appendix D. XML configuration example for IKE case (gateway-to-gateway) - This example shows a XML configuration file sent by the Security + This example shows a XML configuration file sent by the I2NSF 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. + (see Figure 3) in tunnel mode (gateway-to-gateway) with ESP, + authentication based on X.509 certificates and applying the IKE case. - Security Controller - | - /---- Southbound interface -----\ - / \ - / \ + +------------------+ + | I2NSF Controller | + +------------------+ + I2NSF NSF-Facing | + 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 + +----+ +--------+ +--------+ +----+ + | h1 |--| nsf_h1 |== IPsec_ESP_Tunnel_mode == | nsf_h2 |--| h2 | + +----+ +--------+ +--------+ +----+ + :1 :100 :200 :1 - Figure 7: IKE case, tunnel mode , X.509 certicate authentication. + (2001:DB8:1:/64) (2001:DB8:123:/64) (2001:DB8:2:/64) + + Figure 3: IKE case, tunnel mode , X.509 certificate authentication. nsf_h1_pad 2001:DB8:123::100 digital-signature @@ -3725,38 +3440,41 @@ 2000000 2000 120 -Appendix E. Example of IKE-less case, transport mode (host-to-host). +Appendix E. XML configuration example for IKE-less case (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. + This example shows a XML configuration file sent by the I2NSF + Controller to establish a IPsec Security Association between two NSFs + (see Figure 4) in transport mode (host-to-host) with ESP, and + applying the IKE-less case. - Security Controller - | - /---- Southbound interface -----\ - / \ - / \ + +------------------+ + | I2NSF Controller | + +------------------+ + I2NSF NSF-Facing | + Interface | + /--------------------+-------------------\ / \ / \ - nsf_h1 nsf_h2 - (:100)===== IPsec_ESP_Transport_mode =====(:200) - (2001:DB8:123:/64) + +--------+ +--------+ + | nsf_h1 |===== IPsec_ESP_Transport_mode =====| nsf_h2 | + +--------+ +--------+ + :100 (2001:DB8:123:/64) :200 - Figure 8: IKE-less case, transport mode. + Figure 4: IKE-less case, transport mode. in/trans/2001:DB8:123::200/2001:DB8:123::100 inbound @@ -3911,81 +3629,339 @@ 2000 120 1000000 1000 60 replace + -Appendix F. Examples of notifications. +Appendix F. XML notification examples 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 + the NSF to the I2NSF Controller. The notifications happen in the IKE-less case. in/trans/2001:DB8:123::200/2001:DB8:123::100 true 1000000 1000 60 - Figure 9: Example of sadb-expire notification. + Figure 5: Example of sadb-expire notification. in/trans/2001:DB8:123::200/2001:DB8:123::100 2001:DB8:123::200/128 2001:DB8:123::100/128 any 0 0 0 0 - Figure 10: Example of sadb-acquire notification. + Figure 6: Example of sadb-acquire notification. in/trans/2001:DB8:123::200/2001:DB8:123::100 - Figure 11: Example of sadb-seq-overflow notification. + Figure 7: Example of sadb-seq-overflow notification. 666 - Figure 12: Example of sadb-bad-spi notification. + Figure 8: Example of sadb-bad-spi notification. + +Appendix G. Operational use cases examples + +G.1. Example of IPsec SA establishment + + This appendix exemplifies the applicability of IKE case and IKE-less + case to traditional IPsec configurations, that is, host-to-host and + gateway-to-gateway. The examples we show in the following assume the + existence of two NSFs needing to establish an end-to-end IPsec SA to + protect their communications. Both NSFs could be two hosts that + exchange traffic (host-to-host) or 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). + + As we will show in the following, the I2NSF-based IPsec management + system (for IKE and IKE-less cases), exhibits various advantages: + + 1. It allows to create IPsec SAs among two NSFs, based only on the + application of general Flow-based Protection Policies at the + I2NSF User. Thus, administrators can manage all security + associations in a centralized point with an abstracted view of + the network. + + 2. Any NSF deployed in the system does not need manual + configuration, therefore allowing its deployment in an automated + manner. + +G.1.1. IKE case + +----------------------------------------+ + | I2NSF User (IPsec Management System) | + +----------------------------------------+ + | + (1) Flow-based I2NSF Consumer-Facing + Protection Policy Interface + | + +---------|------------------------------+ + | | | + | | I2NSF Controller | + | V | + | +--------------+ (2)+--------------+ | + | |Translate into|--->| NETCONF/ | | + | |IPsec Policies| | RESTCONF | | + | +--------------+ +--------------+ | + | | | | + | | | | + +--------------------------|-----|-------+ + | | + I2NSF NSF-Facing Interface | | + | (3) | + |-------------------------+ +---| + V V + +----------------------+ +----------------------+ + | NSF A | | NSF B | + | IKEv2/IPsec(SPD/PAD) | | IKEv2/IPsec(SPD/PAD) | + +----------------------+ +----------------------+ + + Figure 9: Host-to-host / gateway-to-gateway for the IKE case. + + Figure 9 describes the application of the IKE case when a data packet + needs to be protected in the path between the NSF A and NSF B: + + 1. The I2NSF User defines a general flow-based protection policy + (e.g. protect data traffic between NSF A and B). The I2NSF + Controller looks for the NSFs involved (NSF A and NSF B). + + 2. The I2NSF Controller generates IKEv2 credentials for them and + translates the policies into SPD and PAD entries. + + 3. The I2NSF Controller inserts an IKEv2 configuration that includes + the SPD and PAD entries in both NSF A and NSF B. If some of + operations with NSF A and NSF B fail the I2NSF Controller will + stop the process and perform a rollback operation by deleting any + IKEv2, SPD and PAD configuration that had been successfully + installed in NSF A or B. + + If the previous steps are successful, the flow is protected by means + of the IPsec SA established with IKEv2 between NSF A and NSF B. + +G.1.2. IKE-less case + + +----------------------------------------+ + | I2NSF User (IPsec Management System) | + +----------------------------------------+ + | + (1) Flow-based I2NSF Consumer-Facing + Protection Policy Interface + | + +---------|------------------------------+ + | | | + | | I2NSF Controller | + | V | + | +--------------+ (2) +--------------+ | + | |Translate into|---->| NETCONF/ | | + | |IPsec Policies| | RESTCONF | | + | +--------------+ +--------------+ | + | | | | + +-------------------------|-----|--------+ + | | + I2NSF NSF-Facing Interface | | + | (3) | + |----------------------+ +--| + V V + +----------------+ +----------------+ + | NSF A | | NSF B | + | IPsec(SPD/SAD) | | IPsec(SPD/SAD) | + +----------------+ +----------------+ + + Figure 10: Host-to-host / gateway-to-gateway for IKE-less case. + + Figure 10 describes the application of the IKE-less case when a data + packet needs to be protected in the path between the NSF A and NSF B: + + 1. The I2NSF User establishes a general Flow-based Protection Policy + and the I2NSF Controller looks for the involved NSFs. + + 2. The I2NSF Controller translates the flow-based security policies + into IPsec SPD and SAD entries. + + 3. The I2NSF Controller inserts these entries in both NSF A and NSF + B IPsec databases (SPD and SAD). The following text describes + how this would happen: + + * The I2NSF Controller chooses two random values as SPIs: for + example, SPIa1 for NSF A and SPIb1 for NSF B. These numbers + MUST NOT be in conflict with any IPsec SA in NSF A or NSF B. + It also generates fresh cryptographic material for the new + inbound/outbound IPsec SAs and their parameters. + + * After that, the I2NSF Controller sends simultaneously the new + inbound IPsec SA with SPIa1 and new outbound IPsec SA with + SPIb1 to NSF A; and the new inbound IPsec SA with SPIb1 and + new outbound IPsec SA with SPIa1 to B, together with the + corresponding IPsec policies. + + * Once the I2NSF Controller receives confirmation from NSF A and + NSF B, it knows that the IPsec SAs are correctly installed and + ready. + + Other alternative to this operation is: the I2NSF Controller + sends first the IPsec policies and new inbound IPsec SAs to A and + B and once it obtains a successful confirmation of these + operations from NSF A and NSF B, it proceeds with installing to + the new outbound IPsec SAs. Despite this procedure may increase + the latency to complete the process, no traffic is sent over the + network until the IPsec SAs are completely operative. In any + case other alternatives MAY be possible to implement step 3. + + 4. If some of the operations described above fails (e.g. the NSF A + reports an error when the I2NSF Controller is trying to install + the SPD entry, the new inbound or outbound IPsec SAs) the I2NSF + Controller must perform rollback operations by deleting any new + inbound or outbound SA and SPD entry that had been successfully + installed in any of the NSFs (e.g NSF B) and stop the process. + Note that the I2NSF Controller may retry several times before + giving up. + + 5. Otherwise, if the steps 1 to 3 are successful, the flow between + NSF A and NSF B is protected by means of the IPsec SAs + established by the I2NSF Controller. It is worth mentioning that + the I2NSF Controller associates a lifetime to the new IPsec SAs. + When this lifetime expires, the NSF will send a sadb-expire + notification to the I2NSF Controller in order to start the + rekeying process. + + Instead of installing IPsec policies (in the SPD) and IPsec SAs (in + the SAD) in step 3 (proactive mode), it is also possible that the + I2NSF Controller only installs the SPD entries in step 3 (reactive + mode). 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 I2NSF Controller that needs SAD + entries with the IPsec SAs to process the data packet. In such as + reactive mode, upon reception of the sadb-acquire notification, the + I2NSF Controller installs the new IPsec SAs in NSF A and B (following + the procedure previously described in step 3) but without sending any + IPsec policies, since IPsec policies are already installed in the + SPD. Again, if some of the operations installing the new inbound/ + outbound IPsec SAs fail, the I2NSF Controller stops the process and + performs a rollback operation by deleting any new inbound/outbound + SAs that had been successfully installed. + +G.2. Example of the rekeying process in IKE-less case + + To explain an example of the rekeying process between two IPsec NSFs + A and B, let assume that SPIa1 identifies the inbound IPsec SA in A, + and SPIb1 the inbound IPsec SA in B. The rekeying process will take + the following steps: + + 1. The I2NSF 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 I2NSF 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 I2NSF Controller receives confirmation from A and B, the + controller knows that the inbound IPsec SAs are correctly + installed. Then it proceeds to send in parallel to A and B, the + outbound IPsec SAs: the outbound IPsec SA to A with SPIb2, and + the outbound IPsec SA to B with SPIa2. At this point the new + IPsec SAs are ready. + + 3. Once the I2NSF Controller receives confirmation from A and B that + the outbound IPsec SAs have been installed, the I2NSF Controller, + in parallel, deletes the old IPsec SAs from A (inbound SPIa1 and + outbound SPIb1) and B (outbound SPIa1 and inbound SPIb1). + + If some of the operations in step 1 fail (e.g. the NSF A reports an + error when the I2NSF Controller is trying to install a new inbound + IPsec SA) the I2NSF Controller must perform rollback operations by + removing any new inbound SA that had been successfully installed + during step 1. + + If step 1 is successful but some of the operations in step 2 fails + (e.g. the NSF A reports an error when the I2NSF Controller is trying + to install the new outbound IPsec SA), the I2NSF Controller must + perform a rollback operation by deleting any new outbound SA that had + been successfully installed during step 2 and by deleting the inbound + SAs created in step 1. + + If the steps 1 an 2 are successful and the step 3 fails, the I2NSF + Controller will avoid any rollback of the operations carried out in + step 1 and step 2 since new and valid IPsec SAs were created and are + functional. The I2NSF Controller may reattempt to remove the old + inbound and outbound SAs in NSF A and NSF B several times until it + receives a success or it gives up. In the last case, the old IPsec + SAs will be removed when their corresponding hard lifetime is + reached. + +G.3. Example of managing NSF state loss in IKE-less case + + In the IKE-less case, if the I2NSF Controller detects that a NSF has + lost the IPsec state, it could follow the next steps: + + 1. The I2NSF Controller SHOULD delete the old IPsec SAs on the non- + failed nodes, established with the failed node. This prevents + the non-failed nodes from leaking plaintext. + + 2. If the affected node restarts, the I2NSF Controller configures + the new inbound IPsec SAs between the affected node and all the + nodes it was talking to. + + 3. After these inbound IPsec SAs have been established, the I2NSF + Controller configures the outbound IPsec SAs in parallel. + + Step 2 and step 3 can be performed at the same time at the cost of a + potential packet loss. If this is not critic then it is an + optimization since the number of exchanges between I2NSF Controller + and NSFs is lower. 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