--- 1/draft-ietf-i2nsf-sdn-ipsec-flow-protection-08.txt 2020-10-12 12:13:17.545090261 -0700 +++ 2/draft-ietf-i2nsf-sdn-ipsec-flow-protection-09.txt 2020-10-12 12:13:17.793096573 -0700 @@ -1,53 +1,54 @@ I2NSF R. Marin-Lopez Internet-Draft G. Lopez-Millan Intended status: Standards Track University of Murcia -Expires: December 19, 2020 F. Pereniguez-Garcia +Expires: April 15, 2021 F. Pereniguez-Garcia University Defense Center - June 17, 2020 + October 12, 2020 Software-Defined Networking (SDN)-based IPsec Flow Protection - draft-ietf-i2nsf-sdn-ipsec-flow-protection-08 + draft-ietf-i2nsf-sdn-ipsec-flow-protection-09 Abstract 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 + (integrity and confidentiality) by means of an Interface to Network + Security Function (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 Security Associations (SAs) from a I2NSF Controller to one or several flow-based Network Security - Function (NSF) that implement IPsec to protect data traffic. + Functions (NSFs) that rely on IPsec to protect data traffic. - 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. + The document focuses on the I2NSF NSF-facing interface by providing + YANG data models for configuring the IPsec databases (SPD, SAD, PAD) + and IKEv2. This allows IPsec SA establishment with minimal + intervention by the network administrator. It does not define any + new protocol. 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 December 19, 2020. + This Internet-Draft will expire on April 15, 2021. Copyright Notice 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 @@ -63,76 +64,77 @@ 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 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. YANG configuration data models . . . . . . . . . . . . . . . 12 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 + 6.2. IKE-less case model . . . . . . . . . . . . . . . . . . . 17 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 + 8.1. IKE case . . . . . . . . . . . . . . . . . . . . . . . . 23 + 8.2. IKE-less case . . . . . . . . . . . . . . . . . . . . . . 24 + 8.3. YANG modules . . . . . . . . . . . . . . . . . . . . . . 24 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 26 + 10.2. Informative References . . . . . . . . . . . . . . . . . 29 + Appendix A. Common YANG model for IKE and IKE-less cases . . . . 31 + Appendix B. YANG model for IKE case . . . . . . . . . . . . . . 46 + Appendix C. YANG model for IKE-less case . . . . . . . . . . . . 65 Appendix D. XML configuration example for IKE case (gateway-to- - gateway) . . . . . . . . . . . . . . . . . . . . . . 71 + gateway) . . . . . . . . . . . . . . . . . . . . . . 76 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 + to-host) . . . . . . . . . . . . . . . . . . . . . . 79 + Appendix F. XML notification examples . . . . . . . . . . . . . 84 + Appendix G. Operational use cases examples . . . . . . . . . . . 85 + G.1. Example of IPsec SA establishment . . . . . . . . . . . . 85 + G.1.1. IKE case . . . . . . . . . . . . . . . . . . . . . . 86 + G.1.2. IKE-less case . . . . . . . . . . . . . . . . . . . . 88 + G.2. Example of the rekeying process in IKE-less case . . . . 90 + G.3. Example of managing NSF state loss in IKE-less case . . . 91 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 91 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 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]. + SDN controllers configure and manage distributed network resources + and provide an abstracted view of the network resources to SDN + applications. SDN applications 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 demanding a centralized way - of managing different security aspects. For example, Software- - Defined WANs (SD-WAN), an SDN extension providing a software + Recently, several network scenarios now demand a centralized way of + managing different security aspects. For example, Software-Defined + WANs (SD-WANs). SD-WANs are an SDN extension providing a software abstraction to create secure network overlays over traditional WAN - 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. + and branch networks. SD-WANs utilize IPsec [RFC4301] as an + underlying security protocol. The goal of SD-WANs is to provide + flexible and automated deployment from a centralized point to enable + on-demand network security services such as IPsec Security + Association (IPsec SA) management. Additionally, Section 4.3.3 in + [RFC8192] describes another example use case for Cloud Data Center + Scenario titled "Client-Specific Security Policy in Cloud VPNs". The + use case in RFC 8192 states that "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 a scenario where the current + specification maybe applicable. Therefore, with the growth of SDN-based scenarios where network resources are deployed in an autonomous manner, a mechanism to manage 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 @@ -177,56 +179,59 @@ 2) IKE-less case. The NSF only implements the IPsec databases (no 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 key management functionality is moved to the I2NSF Controller. 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 + the I2NSF Controller and the NSF. Using YANG data modelling language + version 1.1 [RFC7950] and based on YANG models defined in + [netconf-vpn], [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 be found in Appendix D, Appendix E and - Appendix F. + (see Appendix A, Appendix B and Appendix C). The proposed YANG data + model conforms to the Network Management Datastore Architecture + (NMDA) defined in [RFC8342]. Examples of the usage of these models + can be found in Appendix D, Appendix E and Appendix F. In summary, the objetives of this I-D are: 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. + management through the I2NSF NSF-Facing interface. Thus, this I-D + does not define any new protocol. 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 [RFC8329], [RFC8192], - [RFC4301],[RFC7296], [RFC6241], [ITU-T.Y.3300], The following term is - defined in [ITU-T.Y.3300]: + [RFC4301],[RFC7296], [RFC6241], [ITU-T.Y.3300]. The following term + is defined in [ITU-T.Y.3300]: o Software-Defined Networking. The following terms are in defined in [RFC8192]: o NSF. o Flow-based NSF. The following terms are defined in [RFC4301]: @@ -253,34 +258,32 @@ 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. + whether the NSF implements IKEv2 or not: IKE case and IKE-less case. 4.1. IKE case: IKEv2/IPsec in the NSF - 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. + In this case, the NSF implements IPsec 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 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 traffic flow needs protection). Figure 1 shows the different layers and corresponding @@ -499,51 +502,44 @@ 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. - 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. - 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. + the network under its control. This view is built either by + requesting information from the NSFs under its control, or by + information pushed from the NSFs to 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. 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. + address, etc. This information is incorporated in 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 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 I2NSF Controller, the I2NSF Controller MUST discover certain capabilities of this NSF, such as what is the cryptographic suite @@ -553,39 +549,44 @@ 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, 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. + three models: ietf-i2nsf-ikec (Appendix A, common to both cases), + ietf-i2nsf-ike (Appendix B, IKE case), ietf-i2nsf-ikeless + (Appendix C, IKE-less case). Since the model ietf-i2nsf-ikec has + only typedef and groupings common to the other modules, we only show + a simplified view of the ietf-i2nsf-ike and ietf-i2nsf-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 that many implementations integrate PAD configuration as part of the IKEv2 configuration). - module: ietf-ipsec-ike + The data model for the IKE case is defined by YANG model "ietf-i2nsf- + ike". Its structure is depicted in the following diagram, using the + notation syntax for YANG tree diagrams ([RFC8340]). + + module: ietf-i2nsf-ike +--rw ipsec-ike +--rw pad | +--rw pad-entry* [name] | +--rw name string | +--rw (identity) | | +--:(ipv4-address) | | | +--rw ipv4-address? inet:ipv4-address | | +--:(ipv6-address) | | | +--rw ipv6-address? inet:ipv6-address | | +--:(fqdn-string) @@ -599,21 +600,21 @@ | | +--:(id-key) | | | +--rw id-key? string | | +--:(id-null) | | +--rw id-null? empty | +--rw auth-protocol? auth-protocol-type | +--rw peer-authentication | +--rw auth-method? auth-method-type | +--rw eap-method | | +--rw eap-type uint8 | +--rw pre-shared - | | +--rw secret? yang:hex-string + | | +--rw secret yang:hex-string | +--rw digital-signature | +--rw ds-algorithm? uint8 | +--rw (public-key) | | +--:(raw-public-key) | | | +--rw raw-public-key? binary | | +--:(cert-data) | | +--rw cert-data? ct:x509 | +--rw private-key? binary | +--rw ca-data* ct:x509 | +--rw crl-data? ct:crl @@ -624,28 +625,31 @@ | +--rw autostartup? autostartup-type | +--rw initial-contact? boolean | +--rw version? auth-protocol-type | +--rw fragmentation? boolean | +--rw ike-sa-lifetime-soft | | +--rw rekey-time? uint32 | | +--rw reauth-time? uint32 | +--rw ike-sa-lifetime-hard | | +--rw over-time? uint32 | +--rw authalg* ic:integrity-algorithm-type - | +--rw encalg* ic:encryption-algorithm-type + | +--rw encalg* [id] + | | +--rw id uint8 + | | +--rw algorithm-type? ic:encryption-algorithm-type + | | +--rw key-length? uint16 | +--rw dh-group? pfs-group | +--rw half-open-ike-sa-timer? uint32 | +--rw half-open-ike-sa-cookie-threshold? uint32 | +--rw local - | | +--rw local-pad-entry-name? string + | | +--rw local-pad-entry-name string | +--rw remote - | | +--rw remote-pad-entry-name? string + | | +--rw remote-pad-entry-name string | +--rw encapsulation-type | | +--rw espencap? esp-encap | | +--rw sport? inet:port-number | | +--rw dport? inet:port-number | | +--rw oaddr* inet:ip-address | +--rw spd | | +--rw spd-entry* [name] | | +--rw name string | | +--rw ipsec-policy-config | | +--rw anti-replay-window? uint64 @@ -663,21 +667,24 @@ | | | +--rw action? ipsec-spd-action | | | +--rw ipsec-sa-cfg | | | +--rw pfp-flag? boolean | | | +--rw ext-seq-num? boolean | | | +--rw seq-overflow? boolean | | | +--rw stateful-frag-check? boolean | | | +--rw mode? ipsec-mode | | | +--rw protocol-parameters? ipsec-protocol-parameters | | | +--rw esp-algorithms | | | | +--rw integrity* integrity-algorithm-type - | | | | +--rw encryption* encryption-algorithm-type + | | | | +--rw encryption* [id] + | | | | | +--rw id uint8 + | | | | | +--rw algorithm-type? ic:encryption-algorithm-type + | | | | | +--rw key-length? uint16 | | | | +--rw tfc-pad? boolean | | | +--rw tunnel | | | +--rw local inet:ip-address | | | +--rw remote inet:ip-address | | | +--rw df-bit? enumeration | | | +--rw bypass-dscp? boolean | | | +--rw dscp-mapping? yang:hex-string | | | +--rw ecn? boolean | | +--rw spd-mark | | +--rw mark? uint32 @@ -707,46 +714,72 @@ | | +--ro dport? inet:port-number | | +--ro oaddr* inet:ip-address | +--ro established? uint64 | +--ro current-rekey-time? uint64 | +--ro current-reauth-time? uint64 +--ro number-ike-sas +--ro total? uint64 +--ro half-open? uint64 +--ro half-open-cookies? uint64 + The data model consists of a unique "ipsec-ike" container defined as + follows. Firstly, it contains a "pad" container that serves to + configure the Peer Authentication Database with authentication + information about local and remote peers. More precisely, it + consists of a list of entries, each one indicating the identity, + authentication method and credentials that will use a particular + peer. + + Next, we find a list "conn-entry" with information about the + different IKE connections a peer can maintain with others. Each + connection entry is composed of a wide number of parameters to + configure different aspects of a particular IKE connection between + two peers: local and remote peer authentication information; IKE SA + configuration (soft and hard lifetimes, cryptographic algorithms, + etc.); list of IPsec policies describing the type of network traffic + to be secured (local/remote subnet and ports, etc.) and how must be + protected (AH/ESP, tunnel/transport, cryptographic algorithms, etc.); + CHILD SA configuration (soft and hard lifetimes); and, state + information of the IKE connection (SPIs, usage of NAT, current + expiration times, etc.). + + Lastly, the "ipsec-ike" container declares a "number-ike-sas" + container to specify state information reported by the IKE software + related to the amount of IKE connections established. + 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 changes, namely: 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 Combined algorithms have 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. + kernel implementations accept configuration 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. @@ -770,26 +803,30 @@ 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 + The data model for the IKE-less case is defined by YANG model "ietf- + i2nsf-ikeless". Its structure is depicted in the following diagram, + using the notation syntax for YANG tree diagrams ([RFC8340]). + + module: ietf-i2nsf-ikeless +--rw ipsec-ikeless +--rw spd | +--rw spd-entry* [name] | +--rw name string - | +--rw direction? ic:ipsec-traffic-direction + | +--rw direction ic:ipsec-traffic-direction | +--rw reqid? uint64 | +--rw ipsec-policy-config | +--rw anti-replay-window? uint64 | +--rw traffic-selector | | +--rw local-subnet inet:ip-prefix | | +--rw remote-subnet inet:ip-prefix | | +--rw inner-protocol? ipsec-inner-protocol | | +--rw local-ports* [start end] | | | +--rw start inet:port-number | | | +--rw end inet:port-number @@ -797,24 +834,27 @@ | | +--rw start inet:port-number | | +--rw end inet:port-number | +--rw processing-info | | +--rw action? ipsec-spd-action | | +--rw ipsec-sa-cfg | | +--rw pfp-flag? boolean | | +--rw ext-seq-num? boolean | | +--rw seq-overflow? boolean | | +--rw stateful-frag-check? boolean | | +--rw mode? ipsec-mode - | | +--rw protocol-parameters? + | | +--rw protocol-parameters? ipsec-protocol-parameters | | +--rw esp-algorithms | | | +--rw integrity* integrity-algorithm-type - | | | +--rw encryption* encryption-algorithm-type + | | | +--rw encryption* [id] + | | | | +--rw id uint8 + | | | | +--rw algorithm-type?ic:encryption-algorithm-type + | | | | +--rw key-length? uint16 | | | +--rw tfc-pad? boolean | | +--rw tunnel | | +--rw local inet:ip-address | | +--rw remote inet:ip-address | | +--rw df-bit? enumeration | | +--rw bypass-dscp? boolean | | +--rw dscp-mapping? yang:hex-string | | +--rw ecn? boolean | +--rw spd-mark | +--rw mark? uint32 @@ -903,100 +943,118 @@ | +--ro lifetime-current | +--ro time? uint32 | +--ro bytes? uint32 | +--ro packets? uint32 | +--ro idle? uint32 +---n sadb-seq-overflow | +--ro ipsec-sa-name string +---n sadb-bad-spi +--ro spi uint32 + The data model consists of a unique "ipsec-ikeless" container which, + in turn, is integrated by two additional containers: "spd" and "sad". + The "spd" container consists of a list of entries that conform the + Security Policy Database. Compared to the IKE case data model, this + part specifies a few additional parameters necessary due to the + absence of an IKE software in the NSF: traffic direction to apply the + IPsec policy, and a value to link an IPsec policy with its associated + IPsec SAs. The "sad" container is a list of entries that conform the + Security Association Database. In general, each entry allows to + specify both configuration information (SPI, traffic selectors, + tunnel/transport mode, cryptographic algorithms and keying material, + soft/hard lifetimes, etc.) as well as state information (time to + expire, replay statistics, etc.) of a concrete IPsec SA. + + In addition, the module defines a set of notifications to allow the + NSF inform I2NSF controller about relevant events such as IPsec SA + expiration, sequence number overflow or bad SPI in a received packet. + 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. 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. + URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikec + Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. - URI: urn:ietf:params:xml:ns:yang:ietf-ipsec-ike - Registrant Contact: The I2NSF WG of the IETF. + URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-ike + Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. - URI: urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless - Registrant Contact: The I2NSF WG of the IETF. + URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless + Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. This document registers three YANG modules in the "YANG Module Names" registry [RFC6020]. Following the format in [RFC6020], the following registrations are requested: - Name: ietf-ipsec-common - Namespace: urn:ietf:params:xml:ns:yang:ietf-ipsec-common + Name: ietf-i2nsf-ikec + Namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikec Prefix: ic Reference: RFC XXXX - Name: ietf-ipsec-ike - Namespace: urn:ietf:params:xml:ns:yang:ietf-ipsec-ike + Name: ietf-i2nsf-ike + Namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-ike Prefix: ike Reference: RFC XXXX - Name: ietf-ipsec-ikeless - Namespace: urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless + Name: ietf-i2nsf-ikeless + Namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless Prefix: ikeless Reference: RFC XXXX 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 [RFC7426]. 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 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 + policies that allow the NSF to communicate 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 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 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 + handle cryptographic material thus the attacker may try to access + this information. Although we can assume this attack is 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. + I2NSF Controller, it still deserves some analysis in the hypothetical + case that the attack occurs. The impact is different depending on + the IKE case or IKE-less case. 8.1. IKE case In the IKE case, the I2NSF Controller sends IKEv2 credentials (PSK, public/private keys, certificates, etc.) to the NSFs using the 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 @@ -1015,191 +1073,272 @@ 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. + export 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. + private keys) and exports the public key, 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 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. 8.3. YANG modules - The YANG module specified in this document defines a schema for data + The YANG modules 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] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. There are a number of data nodes defined in these YANG modules that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. These are the subtrees and data nodes and their sensitivity/vulnerability: - 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): + For the IKE case (ietf-i2nsf-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 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): + For the IKE-less case (ietf-i2nsf-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 NSF by means of /ipsec-ikeless/sad container and, in general changing any IPsec SAs and IPsec policies between any NSF. Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. These are the subtrees and data nodes and their sensitivity/vulnerability: - For the IKE case (ietf-ipsec-ike): + For the IKE case (ietf-i2nsf-ike): /ipsec-ike/pad: This container includes sensitive information to read operations. This information should never be returned to a client. For example, cryptographic material configured in the NSFs: peer-authentication/pre-shared/secret and peer- authentication/digital-signature/private-key are already protected by the NACM extension "default-deny-all" in this document. - For the IKE-less case (ietf-ipsec-ikeless): + For the IKE-less case (ietf-i2nsf-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. 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, - Ruben Ricart and Roman Danyliw for their valuable comments. + Bartlett, Sandeep Kampati, Linda Dunbar, Mohit Sethi, Martin + Bjorklund, Tom Petch, Christian Hopps, Rob Wilton, Carlos J. + Bernardos, Alejandro Perez-Mendez, Alejandro Abad-Carrascosa, Ignacio + Martinez, Ruben Ricart and Roman Danyliw for their valuable comments. 10. References 10.1. Normative References + [I-D.draft-ietf-netconf-crypto-types] + Watsen, K., "YANG Data Types and Groupings for + Cryptography", draft-ietf-netconf-crypto-types-18 (work in + progress), August 2020. + + [IKEv2-Parameters] + Internet Assigned Numbers Authority (IANA), "Internet Key + Exchange Version 2 (IKEv2) Parameters", August 2020. + + [ITU-T.X.690] + "Recommendation ITU-T X.690", August 2015. + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . + [RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R., and S. + Sataluri, "Using Domains in LDAP/X.500 Distinguished + Names", RFC 2247, DOI 10.17487/RFC2247, January 1998, + . + + [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, + "Negotiation of NAT-Traversal in the IKE", RFC 3947, + DOI 10.17487/RFC3947, January 2005, + . + [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, . + [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", + RFC 4303, DOI 10.17487/RFC4303, December 2005, + . + + [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., + Housley, R., and W. Polk, "Internet X.509 Public Key + Infrastructure Certificate and Certificate Revocation List + (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, + . + + [RFC5915] Turner, S. and D. Brown, "Elliptic Curve Private Key + Structure", RFC 5915, DOI 10.17487/RFC5915, June 2010, + . + [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, . + [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", + RFC 6991, DOI 10.17487/RFC6991, July 2013, + . + [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, . + [RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2 + (IKEv2) Message Fragmentation", RFC 7383, + DOI 10.17487/RFC7383, November 2014, + . + + [RFC7427] Kivinen, T. and J. Snyder, "Signature Authentication in + the Internet Key Exchange Version 2 (IKEv2)", RFC 7427, + DOI 10.17487/RFC7427, January 2015, + . + + [RFC7619] Smyslov, V. and P. Wouters, "The NULL Authentication + Method in the Internet Key Exchange Protocol Version 2 + (IKEv2)", RFC 7619, DOI 10.17487/RFC7619, August 2015, + . + + [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", + RFC 7950, DOI 10.17487/RFC7950, August 2016, + . + + [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, + "PKCS #1: RSA Cryptography Specifications Version 2.2", + RFC 8017, DOI 10.17487/RFC8017, November 2016, + . + [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + + [RFC8221] Wouters, P., Migault, D., Mattsson, J., Nir, Y., and T. + Kivinen, "Cryptographic Algorithm Implementation + Requirements and Usage Guidance for Encapsulating Security + Payload (ESP) and Authentication Header (AH)", RFC 8221, + DOI 10.17487/RFC8221, October 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, . + [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", + BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, + . + [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, . + [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., + and R. Wilton, "Network Management Datastore Architecture + (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, + . + [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . 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.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.Y.3300] "Recommendation ITU-T Y.3300", June 2014. [libreswan] - The Libreswan Project, "Libreswan VPN software", August - 2019. + The Libreswan Project, "Libreswan VPN software", September + 2020. [netconf-vpn] Stefan Wallin, "Tutorial: NETCONF and YANG", January 2014. [ONF-OpenFlow] ONF, "OpenFlow Switch Specification (Version 1.4.0)", October 2013. [ONF-SDN-Architecture] "SDN Architecture", June 2014. @@ -1257,77 +1396,92 @@ [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. + Solution", September 2020. Appendix A. Common YANG model for IKE and IKE-less cases - file "ietf-ipsec-common@2019-08-05.yang" + This Appendix is Normative. - module ietf-ipsec-common { + This YANG module has normative references to [RFC3947], [RFC4301], + [RFC4303], [RFC8174], [RFC8221] and [IKEv2-Parameters]. + + This YANG module has informative references to [RFC3948] and + [RFC8229]. + + file "ietf-i2nsf-ikec@2020-10-12.yang" + + module ietf-i2nsf-ikec { yang-version 1.1; - namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec-common"; - prefix "ipsec-common"; + namespace "urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikec"; + prefix "ic"; - import ietf-inet-types { prefix inet; } - import ietf-yang-types { prefix yang; } + import ietf-inet-types { + prefix inet; + reference "RFC 6991: Common YANG Data Types"; + } + + import ietf-yang-types { + prefix yang; + reference "RFC 6991: Common YANG Data Types"; + } organization "IETF I2NSF Working Group"; contact - "WG Web: + "WG Web: WG List: Author: Rafael Marin-Lopez Author: Gabriel Lopez-Millan Author: Fernando Pereniguez-Garcia "; description "Common Data model for the IKE and IKE-less cases defined by the SDN-based IPsec flow protection service. - Copyright (c) 2019 IETF Trust and the persons + Copyright (c) 2020 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX;; see the RFC itself for full legal notices. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here."; - revision "2019-08-05" { - description "Revision 06"; - reference "RFC XXXX: YANG Groupings and typedef - for IKE and IKE-less case"; + revision "2020-10-12" { + description "Initial version."; + reference "RFC XXXX: Software-Defined Networking + (SDN)-based IPsec Flow Protection."; } typedef encryption-algorithm-type { type uint16; description "The encryption algorithm is specified with a 16-bit number extracted from IANA Registry. The acceptable values MUST follow the requirement levels for encryption algorithms for ESP and IKEv2."; reference @@ -1524,20 +1680,21 @@ IANA Registry - Protocol Numbers."; } grouping encap { description "This group of nodes allows to define the type of encapsulation in case NAT traversal is required and port information."; leaf espencap { type esp-encap; + default none; description "ESP in TCP, ESP in UDP or ESP in TLS."; } leaf sport { type inet:port-number; default 4500; description "Encapsulation source port."; } leaf dport { @@ -1602,32 +1758,34 @@ } reference "Section 4.4.2.1 in RFC 4301."; } grouping port-range { description "This grouping defines a port range, such as expressed in RFC 4301. For example: 1500 (Start - Port Number)-1600 (End Port Number). A port range - is used in the Traffic Selector."; + Port Number)-1600 (End Port Number). + A port range is used in the Traffic Selector."; leaf start { type inet:port-number; - description - "Start port number."; + description "Start port number."; } leaf end { type inet:port-number; description - "End port number."; + "End port number. The assigned value must be + equal or greater than the start port number. + To express a single port, set the same value + as start and end."; } reference "Section 4.4.1.2 in RFC 4301."; } grouping tunnel-grouping { description "The parameters required to define the IP tunnel endpoints when IPsec SA requires tunnel mode. The tunnel is defined by two endpoints: the local IP address and the remote IP address."; @@ -1675,23 +1832,25 @@ leaf bypass-dscp { type boolean; default true; description "If DSCP (Differentiated Services Code Point) values in the inner header have to be used to select one IPsec SA among several that match the traffic selectors for an outbound packet"; reference "Section 4.4.2.1. in RFC 4301."; + } leaf dscp-mapping { type yang:hex-string; + default "00:00:00:00:00:00"; description "DSCP values allowed for packets carried over this IPsec SA."; reference "Section 4.4.2.1. in RFC 4301."; } leaf ecn { type boolean; default false; description @@ -1726,30 +1884,35 @@ default any; description "Inner Protocol that is going to be protected with IPsec."; } list local-ports { key "start end"; uses port-range; description "List of local ports. When the inner - protocol is ICMP this 16 bit value represents - code and type."; + protocol is ICMP this 16 bit value + represents code and type. + If this list is not defined + it is assumed that start and + end are 0 by default (any port)."; } list remote-ports { key "start end"; uses port-range; description "List of remote ports. When the upper layer protocol is ICMP this 16 bit value represents - code and type."; + code and type.If this list is not defined + it is assumed that start and end are 0 by + default (any port)"; } reference "Section 4.4.1.2 in RFC 4301."; } grouping ipsec-policy-grouping { description "Holds configuration information for an IPsec SPD entry."; @@ -1861,41 +2025,70 @@ default 0; ordered-by user; description "Configuration of ESP authentication based on the specified integrity algorithm. With AEAD algorithms, the integrity node is not used."; reference "Section 3.2 in RFC 4303."; + } - leaf-list encryption { - type encryption-algorithm-type; - default 20; + list encryption { + key id; ordered-by user; + leaf id { + type uint8; description - "Configuration of ESP encryption - algorithms. The default value is - 20 (ENCR_AES_GCM_16)."; + "The index of list with the + different encryption algorithms and + its key-length (if required)."; + } + leaf algorithm-type { + type ic:encryption-algorithm-type; + default 20; + description + "Default value 20 + (ENCR_AES_GCM_16)"; + } + leaf key-length { + type uint16; + default 128; + description + "By default key length is 128 + bits"; + } + description + "Encryption or AEAD algorithm for the + IPsec SAs. This list is ordered + following from the higher priority to + lower priority. First node of the + list will be the algorithm with + higher priority. In case the list + is empty, then + no encryption algorithm + is applied (NULL)."; reference "Section 3.2 in RFC 4303."; } + leaf tfc-pad { type boolean; default false; description "If Traffic Flow Confidentiality (TFC) padding for ESP encryption can be used (true) or not (false)"; reference "Section 2.7 in RFC 4303."; + } reference "RFC 4303."; } container tunnel { when "../mode = 'tunnel'"; uses tunnel-grouping; description "IPsec tunnel endpoints definition."; } @@ -1928,96 +2121,114 @@ states."; } } } } Appendix B. YANG model for IKE case - file "ietf-ipsec-ike@2019-08-05.yang" - module ietf-ipsec-ike { + This Appendix is Normative. + + This YANG module has normative references to [RFC2247], [RFC5280], + [RFC4301], [RFC5280], [RFC5915], [RFC6991], [RFC7296], [RFC7383], + [RFC7427], [RFC7619], [RFC8017], [RFC8174], [RFC8341], [ITU-T.X.690], + [I-D.draft-ietf-netconf-crypto-types] and [IKEv2-Parameters]. + + This YANG module has informative references to [RFC8229]. + + file "ietf-i2nsf-ike@2020-10-12.yang" + + module ietf-i2nsf-ike { yang-version 1.1; - namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec-ike"; - prefix "ike"; + namespace "urn:ietf:params:xml:ns:yang:ietf-i2nsf-ike"; + prefix "nsfike"; - import ietf-inet-types { prefix inet; } - import ietf-yang-types { prefix yang; } + import ietf-inet-types { + prefix inet; + reference "RFC 6991: Common YANG Data Types"; + } + + import ietf-yang-types { + prefix yang; + reference "RFC 6991: Common YANG Data Types"; + } import ietf-crypto-types { prefix ct; - reference - "draft-ietf-netconf-crypto-types-10: - Common YANG Data Types for Cryptography."; + reference "RFC XXXX: YANG Data Types and Groupings + for Cryptography."; } - import ietf-ipsec-common { + import ietf-i2nsf-ikec { prefix ic; reference - "RFC XXXX: module ietf-ipsec-common, revision - 2019-08-05."; + "Common Data model for SDN-based IPsec + configuration."; } import ietf-netconf-acm { prefix nacm; reference "RFC 8341: Network Configuration Access Control Model."; + } organization "IETF I2NSF Working Group"; contact - "WG Web: + "WG Web: WG List: Author: Rafael Marin-Lopez Author: Gabriel Lopez-Millan Author: Fernando Pereniguez-Garcia "; description "This module contains IPsec IKE case model for the SDN-based IPsec flow protection service. An NSF will implement this module. - Copyright (c) 2019 IETF Trust and the persons identified as + Copyright (c) 2020 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here."; - revision "2019-08-05" { - description "Revision 6"; - reference - "RFC XXXX: YANG model for IKE case."; + revision "2020-10-12" { + description "Initial version."; + reference "RFC XXXX: Software-Defined Networking + (SDN)-based IPsec Flow Protection."; + } typedef ike-spi { type uint64 { range "0..max"; } description "Security Parameter Index (SPI)'s IKE SA."; reference "Section 2.6 in RFC 7296."; } @@ -2214,21 +2425,21 @@ Organisation,CN=John Smith."; reference "RFC 2247."; } } case gnx509 { leaf gnx509 { type string; description "ASN.1 X.509 GeneralName. RFC - 3280."; + 5280."; } } case id-key { leaf id-key { type string; description "Opaque octet stream that may be used to pass vendor-specific information for proprietary types of identification."; @@ -2294,37 +2505,39 @@ reference "Section 2.16 in RFC 7296."; } container pre-shared { when "../auth-method[.='pre-shared' or .='eap']"; leaf secret { nacm:default-deny-all; type yang:hex-string; + mandatory true; description "Pre-shared secret value. The NSF has to prevent read access to this value for security reasons."; } description "Shared secret value for PSK or EAP method authentication based on PSK."; } container digital-signature { when "../auth-method[.='digital-signature' or .='eap']"; leaf ds-algorithm { type uint8; + default 1; description "The digital signature algorithm is specified with a value extracted from the IANA Registry. Depending on the algorithm, the following leafs must contain information. For example if digital signature involves a certificate then leaf 'cert-data' and 'private-key' @@ -2347,120 +2560,136 @@ is defined by the digital signature algorithm. For example, an RSA key is represented as RSAPublicKey as defined in RFC 8017, and an Elliptic Curve Cryptography (ECC) key is represented using the 'publicKey' described in RFC 5915."; reference - "RFC XXX: Common YANG Data - Types for Cryptography."; + "RFC XXXX: YANG Data Types and + Groupings for Cryptography."; } + leaf cert-data { type ct:x509; description "X.509 certificate data - - PEM4."; + PEM4. If raw-public-key + is defined this leaf is + empty."; reference - "RFC XXX: Common YANG Data - Types for Cryptography."; - + "RFC XXXX: YANG Data Types and + Groupings for Cryptography."; } + description "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 + choice but not the leaf + private-key. The NSF, based on + the public key value, can know the private key to be used."; } leaf private-key { nacm:default-deny-all; type binary; description "A binary that contains the value of the private key. The interpretation of the content is defined by the digital signature algorithm. For example, an RSA key is represented as RSAPrivateKey as defined in RFC 8017, and an Elliptic Curve Cryptography (ECC) key is represented as ECPrivateKey as defined in RFC - 5915."; + 5915. This value is set + if public-key is defined and + I2NSF controller is in charge + of configuring the + private-key. Otherwise, it is + not set and the value is + kept in secret."; reference - "RFC XXX: Common YANG Data - Types for Cryptography."; + "RFC XXXX: YANG Data Types and + Groupings for Cryptography."; } leaf-list ca-data { type ct:x509; description "List of trusted Certification Authorities (CA) certificates encoded using ASN.1 distinguished encoding rules - (DER)."; + (DER). If it is not defined + the default value is empty."; reference - "RFC XXX: Common YANG Data - Types for Cryptography."; + "RFC XXXX: YANG Data Types and + Groupings for Cryptography."; } leaf crl-data { type ct:crl; description "A CertificateList structure, as specified in RFC 5280, encoded using ASN.1 distinguished encoding rules (DER),as specified in ITU-T - X.690."; + X.690. If it is not defined + the default value is empty."; reference - "RFC XXX: Common YANG Data Types - for Cryptography."; + "RFC XXXX: YANG Data Types and + Groupings for Cryptography."; } leaf crl-uri { type inet:uri; description - "X.509 CRL certificate URI."; + "X.509 CRL certificate URI. + + If it is not defined + the default value is empty."; } leaf oscp-uri { type inet:uri; description - "OCSP URI."; + "OCSP URI. + If it is not defined + the default value is empty."; } description "Digital Signature container."; } /*container digital-signature*/ } /*container peer-authentication*/ } } list conn-entry { key "name"; description "IKE peer connection information. This list contains the IKE connection for this peer with other peers. This will be translated in real time by IKE Security Associations established with these nodes."; leaf name { type string; - mandatory true; description "Identifier for this connection entry."; } leaf autostartup { type autostartup-type; default add; description "By-default: Only add configuration without starting the security @@ -2536,65 +2765,85 @@ } leaf-list authalg { type ic:integrity-algorithm-type; default 12; ordered-by user; description "Authentication algorithm for establishing the IKE SA. This list is ordered following from the higher priority to lower priority. First node of the list will be the algorithm - with higher priority. If this list is empty - the default integrity algorithm value assumed - is NONE."; + with higher priority."; } - leaf-list encalg { + + list encalg { + key id; + min-elements 1; + ordered-by user; + leaf id { + type uint8; + description + "The index of the list with the + different encryption algorithms and its + key-length (if required). E.g. AES-CBC, + 128 bits"; + } + leaf algorithm-type { type ic:encryption-algorithm-type; default 12; - ordered-by user; + description + "Default value 12 (ENCR_AES_CBC)"; + } + leaf key-length { + type uint16; + default 128; + description + "By default key length is 128 bits"; + } description "Encryption or AEAD algorithm for the IKE SAs. This list is ordered following from the higher priority to lower priority. First node of the list will be the algorithm - with higher priority. If this list is empty - the default encryption value assumed is - NULL."; + with higher priority."; } leaf dh-group { type pfs-group; default 14; description "Group number for Diffie-Hellman Exponentiation used during IKE_SA_INIT for the IKE SA key exchange."; } leaf half-open-ike-sa-timer { type uint32; + default 0; description "Set the half-open IKE SA timeout duration."; reference "Section 2 in RFC 7296."; } leaf half-open-ike-sa-cookie-threshold { type uint32; + default 0; description "Number of half-open IKE SAs that activate the cookie mechanism." ; reference "Section 2.6 in RFC 7296."; } container local { leaf local-pad-entry-name { type string; + mandatory true; description "Local peer authentication information. This node points to a specific entry in the PAD where the authorization information about this particular local peer is stored. It MUST match a pad-entry-name."; } description "Local peer authentication information."; @@ -2591,24 +2840,26 @@ description "Local peer authentication information. This node points to a specific entry in the PAD where the authorization information about this particular local peer is stored. It MUST match a pad-entry-name."; } description "Local peer authentication information."; + } container remote { leaf remote-pad-entry-name { type string; + mandatory true; description "Remote peer authentication information. This node points to a specific entry in the PAD where the authorization information about this particular remote peer is stored. It MUST match a pad-entry-name."; } description "Remote peer authentication information."; @@ -2633,21 +2884,20 @@ description "Configuration of the Security Policy Database (SPD). This main information is placed in the grouping ipsec-policy-grouping."; list spd-entry { key "name"; ordered-by user; leaf name { type string; - mandatory true; description "SPD entry unique name to identify the IPsec policy."; } container ipsec-policy-config { description "This container carries the configuration of a IPsec policy."; uses ic:ipsec-policy-grouping; } @@ -2807,32 +3059,39 @@ particular, it provides the current number of IKE SAs."; } } /* container ipsec-ike */ } Appendix C. YANG model for IKE-less case - file "ietf-ipsec-ikeless@2019-08-05.yang" + This Appendix is Normative. - module ietf-ipsec-ikeless { + This YANG module has normative references to [RFC4301], [RFC6991], + [RFC8174] and [RFC8341]. - yang-version 1.1; - namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless"; + file "ietf-i2nsf-ikeless@2020-10-12.yang" - prefix "ikeless"; + module ietf-i2nsf-ikeless { - import ietf-yang-types { prefix yang; } + yang-version 1.1; + namespace "urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless"; - import ietf-ipsec-common { + prefix "nsfikels"; + + import ietf-yang-types { + prefix yang; + reference "RFC 6991: Common YANG Data Types"; + } + import ietf-i2nsf-ikec { prefix ic; reference "Common Data model for SDN-based IPsec configuration."; } import ietf-netconf-acm { prefix nacm; reference "RFC 8341: Network Configuration Access Control @@ -2833,60 +3092,62 @@ } import ietf-netconf-acm { prefix nacm; reference "RFC 8341: Network Configuration Access Control Model."; } organization "IETF I2NSF Working Group"; + contact - "WG Web: + "WG Web: WG List: Author: Rafael Marin-Lopez Author: Gabriel Lopez-Millan Author: Fernando Pereniguez-Garcia "; description "Data model for IKE-less case in the SDN-base IPsec flow protection service. - Copyright (c) 2019 IETF Trust and the persons + Copyright (c) 2020 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX;; see the RFC itself for full legal notices. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here."; - revision "2019-08-05" { - description "Revision 06"; - reference "RFC XXXX: YANG model for IKE case."; + revision "2020-10-12" { + description "Initial version."; + reference "RFC XXXX: Software-Defined Networking + (SDN)-based IPsec Flow Protection."; } 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 I2NSF Controller to configure IPsec policies in the Security Policy Database SPD, and the second allows to configure IPsec Security Associations @@ -2897,27 +3158,27 @@ description "Configuration of the Security Policy Database (SPD.)"; reference "Section 4.4.1.2 in RFC 4301."; list spd-entry { key "name"; ordered-by user; leaf name { type string; - mandatory true; description "SPD entry unique name to identify this entry."; } leaf direction { type ic:ipsec-traffic-direction; + mandatory true; description "Inbound traffic or outbound traffic. In the IKE-less case the 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."; @@ -3031,20 +3293,21 @@ } leaf protocol-parameters { type ic:ipsec-protocol-parameters; default esp; description "Security protocol of IPsec SA: Only ESP so far."; } leaf mode { type ic:ipsec-mode; + default transport; description "Tunnel or transport mode."; } container esp-sa { when "../protocol-parameters = 'esp'"; description "In case the IPsec SA is Encapsulation Security Payload (ESP), it is required to specify @@ -3053,61 +3316,86 @@ container encryption { description "Configuration of encryption or AEAD algorithm for IPsec Encapsulation Security Payload (ESP)."; leaf encryption-algorithm { type ic:encryption-algorithm-type; + default 12; description "Configuration of ESP encryption. With AEAD algorithms, the integrity - node is not used."; + leaf is not used."; } leaf key { nacm:default-deny-all; type yang:hex-string; description - "ESP encryption key value."; + "ESP encryption key value. + If this leaf is not defined + the key is not defined + (e.g. encryption is NULL). + The key length is + determined by the + length of the key set in + this leaf. By default is + 128 bits."; } leaf iv { nacm:default-deny-all; type yang:hex-string; description - "ESP encryption IV value."; + "ESP encryption IV value. If + this leaf is not defined the + IV is not defined (e.g. + encryption is NULL)"; } } container integrity { description "Configuration of integrity for 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; + default 12; description "Message Authentication Code (MAC) algorithm to provide - integrity in ESP."; + integrity in ESP + (default + AUTH_HMAC_SHA2_256_128). + With AEAD algorithms, + the integrity leaf is not + used."; } leaf key { nacm:default-deny-all; type yang:hex-string; description - "ESP integrity key value."; + "ESP integrity key value. + If this leaf is not defined + the key is not defined (e.g. + AEAD algorithm is chosen and + integrity algorithm is not + required). The key length is + determined by the length of + the key configured."; } } } /*container esp-sa*/ container sa-lifetime-hard { description "IPsec SA hard lifetime. The action associated is terminate and hold."; uses ic:lifetime; @@ -3286,21 +3575,21 @@ "Notify when the NSF receives a packet with an incorrect SPI (i.e. not present in the SAD)."; leaf spi { type uint32 { range "0..max"; } mandatory true; description "SPI number contained in the erroneous IPsec packet."; } } - }/*module ietf-ipsec*/ + } Appendix D. XML configuration example for IKE case (gateway-to-gateway) This example shows a XML configuration file sent by the I2NSF Controller to establish a IPsec Security Association between two NSFs (see Figure 3) in tunnel mode (gateway-to-gateway) with ESP, authentication based on X.509 certificates and applying the IKE case. @@ -3314,21 +3603,21 @@ / \ +----+ +--------+ +--------+ +----+ | h1 |--| nsf_h1 |== IPsec_ESP_Tunnel_mode == | nsf_h2 |--| h2 | +----+ +--------+ +--------+ +----+ :1 :100 :200 :1 (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 base64encodedvalue== base64encodedvalue== @@ -3358,26 +3646,29 @@ ikev2 false true 60 120 3600 - 7 - 3 - - 18 + 7 + + + 1 + + + 18 30 15 nsf_h1_pad nsf_h2_pad @@ -3404,22 +3695,32 @@ false true false false tunnel esp 2 + - 12 + 1 + 12 + 128 + + + + + 2 + 3 + false 2001:DB8:123::100 2001:DB8:123::200 clear true false @@ -3463,21 +3764,21 @@ / \ / \ +--------+ +--------+ | nsf_h1 |===== IPsec_ESP_Transport_mode =====| nsf_h2 | +--------+ +--------+ :100 (2001:DB8:123:/64) :200 Figure 4: IKE-less case, transport mode. in/trans/2001:DB8:123::200/2001:DB8:123::100 inbound 1 @@ -3498,21 +3798,29 @@ protect true true transport esp 2 - 12 + + 1 + 12 + 128 + + + 2 + 3 + out/trans/2001:DB8:123::100/2001:DB8:123::200 outbound 1 @@ -3533,21 +3841,29 @@ protect true true transport esp 2 - 12 + + 1 + 12 + 128 + + + 2 + 3 + out/trans/2001:DB8:123::100/2001:DB8:123::200 1 @@ -3643,64 +3958,64 @@ 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 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 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 6: Example of sadb-acquire notification. + xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless"> in/trans/2001:DB8:123::200/2001:DB8:123::100 Figure 7: Example of sadb-seq-overflow notification. + xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless"> 666 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 @@ -3708,22 +4023,22 @@ 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 + between branches and SaaS cloud services. Besides, IaaS services + providing virtualization environments are deployments that often rely 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 @@ -3842,26 +4157,27 @@ 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. + the new outbound IPsec SAs. Even though 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 + 4. If some of the operations described above fail (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 @@ -3870,29 +4186,25 @@ 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. + entries with the IPsec SAs to process the data packet. 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. @@ -3945,21 +4257,21 @@ 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 + potential packet loss. If this is not critical 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