idnits 2.17.1 draft-ietf-i2nsf-sdn-ipsec-flow-protection-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 8 instances of too long lines in the document, the longest one being 15 characters in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 667 has weird spacing: '...ap-type uin...' == Line 717 has weird spacing: '...w start ine...' == Line 720 has weird spacing: '...w start ine...' == Line 813 has weird spacing: '...w start ine...' == Line 816 has weird spacing: '...w start ine...' == (10 more instances...) == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 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. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: * 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. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: container pad { description "Configuration of Peer Authorization Database (PAD). The PAD contains information about IKE peer (local and remote). Therefore, the Security Controller also stores authentication information for this NSF and can include several entries for the local NSF not only remote peers. Storing local and remote information makes possible to specify that this NSF with identity A will use some particular authentication with remote NSF with identity B and what are the authentication mechanisms allowed to B."; list pad-entry { key "name"; ordered-by user; description "Peer Authorization Database (PAD) entry. It is a list of PAD entries ordered by the Security Controller."; leaf name { type string; description "PAD unique name to identify this entry."; } choice identity { mandatory true; description "A particular IKE peer will be identified by one of these identities. This peer can be a remote peer or local peer (this NSF)."; reference "Section 4.4.3.1 in RFC 4301."; case ipv4-address{ leaf ipv4-address { type inet:ipv4-address; description "Specifies the identity as a single four (4) octet IPv4 addressExample: 10.10.10.10."; } } case ipv6-address{ leaf ipv6-address { type inet:ipv6-address; description "Specifies the identity as a single sixteen (16) octet IPv6 address. An example is 2001:DB8:0:0:8:800:200C:417A."; } } case fqdn-string { leaf fqdn-string { type inet:domain-name; description "Specifies the identity as a Fully-QualifiedDomain Name (FQDN) string. An example is: example.com. The string MUST not contain any terminators (e.g., NULL, CR, etc.)."; } } case rfc822-address-string { leaf rfc822-address-string { type string; description "Specifies the identity as a fully-qualified RFC822 email address string. An example is, jsmith@example.com. The string MUST not contain any terminators e.g., NULL, CR, etc.)."; reference "RFC 822."; } } case dnx509 { leaf dnx509 { type string; description "Specifies the identity as a ASN.1 X.500 Distinguished Name. An example is C=US,O=Example Organisation,CN=John Smith."; reference "RFC 2247."; } } case gnx509 { leaf gnx509 { type string; description "ASN.1 X.509 GeneralName. RFC 3280."; } } 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."; reference "Section 3.5 in RFC 7296."; } } case id-null { leaf id-null { type empty; description "ID_NULL identification used when IKE identification payload is not used." ; reference "RFC 7619."; } } } leaf auth-protocol { type auth-protocol-type; default ikev2; description "Only IKEv2 is supported right now but other authentication protocols may be supported in the future."; } container peer-authentication { description "This container allows the Security Controller to configure the authentication method (pre-shared key, eap, digitial-signature, null) that will use a particular peer and the credentials, which will depend on the selected authentication method."; leaf auth-method { type auth-method-type; default pre-shared; description "Type of authentication method (pre-shared, eap, digital signature, null)."; reference "Section 2.15 in RFC 7296."; } container eap-method { when "../auth-method = 'eap'"; leaf eap-type { type uint8; mandatory true; description "EAP method type. This information provides the particular EAP method to be used. Depending on the EAP method, pre-shared keys or certificates may be used."; } description "EAP method description used when authentication method is 'eap'."; 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; 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; 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' will contain this information."; reference "IKEv2 Authentication Method -IANA Registry - Internet Key Exchange Version 2 (IKEv2) Parameters."; } -- The document date (July 28, 2019) is 1733 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC8341' is defined on line 1454, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 8192 -- Obsolete informational reference (is this intentional?): RFC 8229 (Obsoleted by RFC 9329) Summary: 2 errors (**), 0 flaws (~~), 13 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2NSF R. Marin-Lopez 3 Internet-Draft G. Lopez-Millan 4 Intended status: Standards Track University of Murcia 5 Expires: January 29, 2020 F. Pereniguez-Garcia 6 University Defense Center 7 July 28, 2019 9 Software-Defined Networking (SDN)-based IPsec Flow Protection 10 draft-ietf-i2nsf-sdn-ipsec-flow-protection-06 12 Abstract 14 This document describes how providing IPsec-based flow protection by 15 means of a Software-Defined Network (SDN) controller (aka. Security 16 Controller) and establishes the requirements to support this service. 17 It considers two main well-known scenarios in IPsec: (i) gateway-to- 18 gateway and (ii) host-to-host. The SDN-based service described in 19 this document allows the distribution and monitoring of IPsec 20 information from a Security Controller to one or several flow-based 21 Network Security Function (NSF). The NSFs implement IPsec to protect 22 data traffic between network resources. 24 The document focuses on the NSF Facing Interface by providing models 25 for configuration and state data required to allow the Security 26 Controller to configure the IPsec databases (SPD, SAD, PAD) and IKEv2 27 to establish Security Associations with a reduced intervention of the 28 network administrator. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on January 29, 2020. 47 Copyright Notice 49 Copyright (c) 2019 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 66 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 4. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 5. SDN-based IPsec management description . . . . . . . . . . . 6 69 5.1. IKE case: IKE/IPsec in the NSF . . . . . . . . . . . . . 6 70 5.1.1. Interface Requirements for IKE case . . . . . . . . . 7 71 5.2. IKE-less case: IPsec (no IKEv2) in the NSF. . . . . . . . 7 72 5.2.1. Interface Requirements for IKE-less case . . . . . . 8 73 5.3. IKE case vs IKE-less case . . . . . . . . . . . . . . . . 9 74 5.3.1. Rekeying process. . . . . . . . . . . . . . . . . . . 10 75 5.3.2. NSF state loss. . . . . . . . . . . . . . . . . . . . 12 76 5.3.3. NAT Traversal . . . . . . . . . . . . . . . . . . . . 12 77 5.3.4. NSF Discovery . . . . . . . . . . . . . . . . . . . . 13 78 6. YANG configuration data models . . . . . . . . . . . . . . . 13 79 6.1. IKE case model . . . . . . . . . . . . . . . . . . . . . 14 80 6.2. IKE-less case model . . . . . . . . . . . . . . . . . . . 17 81 7. Use cases examples . . . . . . . . . . . . . . . . . . . . . 20 82 7.1. Host-to-host or gateway-to-gateway under the same 83 Security Controller . . . . . . . . . . . . . . . . . . . 20 84 7.2. Host-to-host or gateway-to-gateway under different 85 Security Controllers . . . . . . . . . . . . . . . . . . 24 86 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 87 9. Security Considerations . . . . . . . . . . . . . . . . . . . 27 88 9.1. IKE case . . . . . . . . . . . . . . . . . . . . . . . . 28 89 9.2. IKE-less case . . . . . . . . . . . . . . . . . . . . . . 29 90 9.3. YANG modules . . . . . . . . . . . . . . . . . . . . . . 29 91 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 92 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 93 11.1. Normative References . . . . . . . . . . . . . . . . . . 31 94 11.2. Informative References . . . . . . . . . . . . . . . . . 32 96 Appendix A. Appendix A: Common YANG model for IKE and IKE-less 97 cases . . . . . . . . . . . . . . . . . . . . . . . 35 98 Appendix B. Appendix B: YANG model for IKE case . . . . . . . . 48 99 Appendix C. Appendix C: YANG model for IKE-less case . . . . . . 67 100 Appendix D. Example of IKE case, tunnel mode (gateway-to- 101 gateway) with X.509 certificate authentication. . . 77 102 Appendix E. Example of IKE-less case, transport mode (host-to- 103 host). . . . . . . . . . . . . . . . . . . . . . . . 80 104 Appendix F. Examples of notifications. . . . . . . . . . . . . . 84 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 86 107 1. Introduction 109 Software-Defined Networking (SDN) is an architecture that enables 110 users to directly program, orchestrate, control and manage network 111 resources through software. The SDN paradigm relocates the control 112 of network resources to a dedicated network element, namely SDN 113 Controller. The SDN controller (or Security Controller in the 114 context of this document) manages and configures the distributed 115 network resources and provides an abstracted view of the network 116 resources to the SDN applications. The SDN application can customize 117 and automate the operations (including management) of the abstracted 118 network resources in a programmable manner via this interface 119 [RFC7149] [ITU-T.Y.3300] [ONF-SDN-Architecture] [ONF-OpenFlow]. 121 Recently, several network scenarios are considering a centralized way 122 of managing different security aspects. For example, Software- 123 Defined WANs (SD-WAN), an SDN extension providing a software 124 abstraction to create secure network overlays over traditional WAN 125 and branch networks. SD-WAN is based on IPsec as underlying security 126 protocol and aims to provide flexible, automated, fast deployment and 127 on-demand security network services such as IPsec SA management from 128 a centralized point. 130 Therefore, with the growth of SDN-based scenarios where network 131 resources are deployed in an autonomous manner, a mechanism to manage 132 IPsec SAs according to the SDN architecture becomes more relevant. 133 Thus, the SDN-based service described in this document will 134 autonomously deal with IPsec SAs management following the SDN 135 paradigm. 137 IPsec architecture [RFC4301] defines clear separation between the 138 processing to provide security services to IP packets and the key 139 management procedures to establish the IPsec Security Associations. 140 In this document, we define a service where the key management 141 procedures can be carried by an external and centralized entity: the 142 Security Controller. 144 First, this document exposes the requirements to support the 145 protection of data flows using IPsec [RFC4301]. We have considered 146 two general cases: 148 1) IKE case. The Network Security Function (NSF) implements the 149 Internet Key Exchange (IKE) protocol and the IPsec databases: the 150 Security Policy Database (SPD), the Security Association Database 151 (SAD) and the Peer Authorization Database (PAD). The Security 152 Controller is in charge of provisioning the NSF with the required 153 information to IKE, the SPD and the PAD. 155 2) IKE-less case. The NSF only implements the IPsec databases (no 156 IKE implementation). The Security Controller will provide the 157 required parameters to create valid entries in the SPD and the 158 SAD into the NSF. Therefore, the NSF will have only support for 159 IPsec while automated key management functionality is moved to 160 the Security Controller. 162 In both cases, an interface/protocol is required to carry out this 163 provisioning in a secure manner between the Security Controller and 164 the NSF. In particular, IKE case requires the provision of SPD and 165 PAD entries, the IKE credential and information related with the IKE 166 negotiation (e.g. IKE_SA_INIT). IKE-less case requires the 167 management of SPD and SAD entries. Based on YANG models in 168 [netconf-vpn] and [I-D.tran-ipsecme-yang], RFC 4301 [RFC4301] and RFC 169 7296 [RFC7296], this document defines the required interfaces with a 170 YANG model for configuration and state data for IKE, PAD, SPD and SAD 171 (see Appendix A, Appendix B and Appendix C). Examples of the usage 172 of these models can found in Appendix D, Appendix E and Appendix F. 174 This document considers two typical scenarios to manage autonomously 175 IPsec SAs: gateway-to-gateway and host-to-host [RFC6071]. In these 176 cases, hosts, gateways or both may act as NSFs. Finally, it also 177 discusses the situation where two NSFs are under the control of two 178 different Security Controllers. The analysis of the host-to-gateway 179 (roadwarrior) scenario is out of scope of this document. 181 Finally, this work pays attention to the challenge "Lack of Mechanism 182 for Dynamic Key Distribution to NSFs" defined in [RFC8192] in the 183 particular case of the establishment and management of IPsec SAs. In 184 fact,this I-D could be considered as a proper use case for this 185 particular challenge in [RFC8192]. 187 2. Requirements Language 189 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 190 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 191 document are to be interpreted as described in RFC 2119 [RFC2119]. 193 When these words appear in lower case, they have their natural 194 language meaning. 196 3. Terminology 198 This document uses the terminology described in [RFC7149], [RFC4301], 199 [ITU-T.Y.3300], [ONF-SDN-Architecture], [ONF-OpenFlow], 200 [ITU-T.X.1252], [ITU-T.X.800] and [I-D.ietf-i2nsf-terminology]. In 201 addition, the following terms are defined below: 203 o Software-Defined Networking. A set of techniques enabling to 204 directly program, orchestrate, control, and manage network 205 resources, which facilitates the design, delivery and operation of 206 network services in a dynamic and scalable manner [ITU-T.Y.3300]. 208 o Flow/Data Flow. Set of network packets sharing a set of 209 characteristics, for example IP dst/src values or QoS parameters. 211 o Security Controller. An entity that contains control plane 212 functions to manage and facilitate information sharing, as well as 213 execute security functions. In the context of this document, it 214 provides IPsec management information. 216 o Network Security Function (NSF). Software that provides a set of 217 security-related services. 219 o Flow-based NSF. A NSF that inspects network flows according to a 220 set of policies intended for enforcing security properties. The 221 NSFs considered in this document fall into this classification. 223 o Flow-based Protection Policy. The set of rules defining the 224 conditions under which a data flow MUST be protected with IPsec, 225 and the rules that MUST be applied to the specific flow. 227 o Internet Key Exchange (IKE) v2. Protocol to establish IPsec 228 Security Associations (SAs). It requires information about the 229 required authentication method (i.e. raw RSA/ECDSA keys or X.509 230 certificates), Diffie-Hellman (DH) groups, IPsec SAs parameters 231 and algorithms for IKE SA negotiation, etc. 233 o Security Policy Database (SPD). It includes information about 234 IPsec policies direction (in, out), local and remote addresses 235 (traffic selectors information), inbound and outboud IPsec SAs, 236 etc. 238 o Security Associations Database (SAD). It includes information 239 about IPsec SAs, such as SPI, destination addresses, 240 authentication and encryption algorithms and keys to protect IP 241 flows. 243 o Peer Authorization Database (PAD). It provides the link between 244 the SPD and a security association management protocol. It is 245 used when the NSF deploys IKE implementation (IKE case). 247 4. Objectives 249 o To describe the architecture for the SDN-based IPsec management, 250 which implements a security service to allow the establishment and 251 management of IPsec security associations from a central point, in 252 order to protect specific data flows. 254 o To define the interfaces required to manage and monitor the IPsec 255 Security Associations (SA) in the NSF from a Security Controller. 256 YANG models are defined for configuration and state data for IPsec 257 management. 259 5. SDN-based IPsec management description 261 As mentioned in Section 1, two cases are considered, depending on 262 whether the NSF ships an IKEv2 implementation or not: IKE case and 263 IKE-less case. 265 5.1. IKE case: IKE/IPsec in the NSF 267 In this case the NSF ships an IKEv2 implementation besides the IPsec 268 support. The Security Controller is in charge of managing and 269 applying IPsec connection information (determining which nodes need 270 to start an IKE/IPsec session, deriving and delivering IKE 271 Credentials such as a pre-shared key, certificates, etc.), and 272 applying other IKE configuration parameters (e.g. cryptographic 273 algorithms for establishing an IKE SA) to the NSF for the IKE 274 negotiation. 276 With these entries, the IKEv2 implementation can operate to establish 277 the IPsec SAs. The application (administrator) establishes the IPsec 278 requirements and information about the end points information 279 (through the Client Facing Interface, [RFC8192]), and the Security 280 Controller translates these requirements into IKE, SPD and PAD 281 entries that will be installed into the NSF (through the NSF Facing 282 Interface). With that information, the NSF can just run IKEv2 to 283 establish the required IPsec SA (when the data flow needs 284 protection). Figure 1 shows the different layers and corresponding 285 functionality. 287 +-------------------------------------------+ 288 |IPsec Management/Orchestration Application | Client or 289 | I2NSF Client | App Gateway 290 +-------------------------------------------+ 291 | Client Facing Interface 292 +-------------------------------------------+ 293 Vendor | Application Support | 294 Facing<->|-------------------------------------------| Security 295 Interface| IKE Credential,PAD and SPD entries Distr. | Controller 296 +-------------------------------------------+ 297 | NSF Facing Interface 298 +-------------------------------------------+ 299 | I2NSF Agent | 300 |-------------------------------------------| Network 301 | IKE | IPsec(SPD,PAD) | Security 302 |-------------------------------------------| Function 303 | Data Protection and Forwarding | 304 +-------------------------------------------+ 306 Figure 1: IKE case: IKE/IPsec in the NSF 308 5.1.1. Interface Requirements for IKE case 310 SDN-based IPsec flow protection services provide dynamic and flexible 311 management of IPsec SAs in flow-based NSFs. In order to support this 312 capability in IKE case, the following interface requirements need to 313 be met: 315 o A YANG data model for IKEv2, SPD and PAD configuration data, and 316 for IKE state data. 318 o In scenarios where multiple Security Controllers are implicated, 319 SDN-based IPsec management services may require a mechanism to 320 discover which Security Controller is managing a specific NSF. 321 Moreover, an east-west interface [RFC7426] is required to exchange 322 IPsec-related information. For example, if two gateways need to 323 establish an IPsec SA and both are under the control of two 324 different controllers, then both Security Controllers need to 325 exchange information to properly configure their own NSFs. That 326 is, the may need to agree on whether IKEv2 authentication will be 327 based on raw public keys, pre-shared keys, etc. In case of using 328 pre-shared keys they will have to agree in the PSK. 330 5.2. IKE-less case: IPsec (no IKEv2) in the NSF. 332 In this case, the NSF does not deploy IKEv2 and, therefore, the 333 Security Controller has to perform the IKE security functions and 334 management of IPsec SAs by populating and managing the SPD and the 335 SAD. 337 +-----------------------------------------+ 338 | IPsec Management Application | Client or 339 | I2NSF Client | App Gateway 340 +-----------------------------------------+ 341 | Client Facing Interface 342 +-----------------------------------------+ 343 Vendor| Application Support | 344 Facing<->|-----------------------------------------| Security 345 Interface| SPD, SAD and PAD Entries Distr. | Controller 346 +-----------------------------------------+ 347 | NSF Facing Interface 348 +-----------------------------------------+ 349 | I2NSF Agent | Network 350 |-----------------------------------------| Security 351 | IPsec (SPD,SAD) | Function (NSF) 352 |-----------------------------------------| 353 | Data Protection and Forwarding | 354 +-----------------------------------------+ 356 Figure 2: IKE-less case: IPsec (no IKE) in the NSF 358 As shown in Figure 2, applications for flow protection run on the top 359 of the Security Controller. When an administrator enforces flow- 360 based protection policies through the Client Facing Interface, the 361 Security Controller translates these requirements into SPD and SAD 362 entries, which are installed in the NSF. PAD entries are not 363 required since there is no IKEv2 in the NSF. 365 5.2.1. Interface Requirements for IKE-less case 367 In order to support the IKE-less case, the following requirements 368 need to be met: 370 o A YANG data model for configuration data for SPD and SAD and for 371 state data for SAD. 373 o In scenarios where multiple controllers are implicated, SDN-based 374 IPsec management services may require a mechanism to discover 375 which Security Controller is managing a specific NSF. Moreover, 376 an east-west interface [RFC7426] is required to exchange IPsec- 377 related information. NOTE: A possible east-west protocol for this 378 IKE-less case could be IKEv2. However, this needs to be explore 379 since the IKEv2 peers would be the Security Controllers. 381 Specifically, the IKE-less case assumes that the SDN controller has 382 to perform some security functions that IKEv2 typically does, namely 383 (non-exhaustive): 385 o IV generation. 387 o Prevent counter resets for the same key. 389 o Generation of pseudo-random cryptographic keys for the IPsec SAs. 391 o Rekey of the IPsec SAs based on notifications from the NSF (i.e. 392 expire). 394 o Generation of the IPsec SAs when required based on notifications 395 (i.e. sadb-acquire) from the NSF. 397 o NAT Traversal discovery and management. 399 Additionally to these functions, another set of tasks must be 400 performed by the Security Controller (non-exhaustive list): 402 o IPsec SA's SPI random generation. 404 o Cryptographic algorithm/s selection. 406 o Usage of extended sequence numbers. 408 o Establishment of proper traffic selectors. 410 5.3. IKE case vs IKE-less case 412 In principle, IKE case is easier to deploy than IKE-less case because 413 current gateways typically have an IKEv2/IPsec implementation. 414 Moreover hosts can install easily an IKE implementation. As 415 downside, the NSF needs more resources to hold IKEv2. Moreover, the 416 IKEv2 implementation needs to implement an internal interface so that 417 the IKE configuration sent by the Security Controller can be enforced 418 in runtime. 420 Alternatively, IKE-less case allows lighter NSFs (no IKEv2 421 implementation), which benefits the deployment in constrained NSFs. 422 Moreover, IKEv2 does not need to be performed in gateway-to-gateway 423 and host-to-host scenarios under the same Security Controller (see 424 Section 7.1). On the contrary, the overload of creating and managing 425 IPsec SAs is shifted to the Security Controller since IKEv2 is not in 426 the NSF. As a consequence, this may result in a more complex 427 implementation in the controller side in comparison with IKE case. 428 For example, the Security Controller have to deal with the latency 429 existing in the path between the Security Controller and the NSF in 430 order to solve tasks such as, rekey or creation and installation of 431 new IPsec SAs. However, this is not specific to our contribution but 432 a general aspect in any SDN-based network. In summary, this overload 433 may create some scalability and performance issues when the number of 434 NSFs is high. 436 Nevertheless, literature around SDN-based network management using a 437 centralized Security Controller is aware about scalability and 438 performance issues and solutions have been already provided and 439 discussed (e.g. hierarchical Security Controllers; having multiple 440 replicated Security Controllers, dedicated high-speed management 441 networks, etc). In the context of SDN-based IPsec management, one 442 way to reduce the latency and alleviate some performance issues can 443 be the installation of the IPsec policies and IPsec SAs at the same 444 time (proactive mode, as described in Section 7.1) instead of waiting 445 for notifications (e.g. a notification sadb-acquire when a new IPsec 446 SA is required) to proceed with the IPsec SA installations (reactive 447 mode). Another way to reduce the overhead and the potential 448 scalability and performance issues in the Security Controller is to 449 apply the IKE case described in this document, since the IPsec SAs 450 are managed between NSFs without the involvement of the Security 451 Controller at all, except by the initial IKE configuration provided 452 by the Security Controller. Other solutions, such as Controller-IKE 453 [I-D.carrel-ipsecme-controller-ike], have proposed that NSFs provide 454 their DH public keys to the Security Controller, so that the Security 455 Controller distributes all public keys to all peers. All peers can 456 calculate a unique pairwise secret for each other peer and there is 457 no inter-NSF messages. A rekey mechanism is further described in 458 [I-D.carrel-ipsecme-controller-ike]. 460 In terms of security, IKE case provides better security properties 461 than IKE-less case, as we discuss in section Section 9. The main 462 reason is that the NSFs are generating the session keys and not the 463 Security Controller. 465 5.3.1. Rekeying process. 467 For IKE case, the rekeying process is carried out by IKEv2, following 468 the information defined in the SPD and SAD. Therefore, connections 469 will live unless something different is required by the administrator 470 or the Security Controller detects something wrong. 472 Traditionally, during a rekey process of the IPSec SA using IKE, a 473 bundle of inbound and outbound IPsec SAs is taken into account from 474 the perspective of one of the NSFs. For example, if the inbound 475 IPsec SA expires both the inbound and outbound IPsec SA are rekeyed 476 at the same time in that NSF. However, when IKE is not used, we have 477 followed a different approach to avoid any packet loss during rekey: 478 the Security Controller installs first the new inbound SAs in both 479 NSFs and then, the outbound IPsec SAs. 481 In other words, for the IKE-less case, the Security Controller needs 482 to take care of the rekeying process. When the IPsec SA is going to 483 expire (e.g. IPsec SA soft lifetime), it has to create a new IPsec 484 SA and remove the old one. This rekeying process starts when the 485 Security Controller receives a sadb-expire notification or it decides 486 so, based on lifetime state data obtained from the NSF. 488 To explain the rekeying process between two IPsec NSFs A and B, let 489 assume that SPIa1 identifies the inbound IPsec SA in A, and SPIb1 the 490 inbound IPsec SA in B. The rekeying process will take the following 491 steps: 493 1. The Security Controller chooses two random values as SPI for the 494 new inbound IPsec SAs: for example, SPIa2 for A and SPIb2 for B. 495 These numbers MUST not be in conflict with any IPsec SA in A or 496 B. Then, the Security Controller creates an inbound IPsec SA 497 with SPIa2 in A and another inbound IPsec SA in B with SPIb2. It 498 can send this information simultaneously to A and B. 500 2. Once the Security Controller receives confirmation from A and B, 501 the controller knows that the inbound IPsec A are correctly 502 installed. Then it proceeds to send in parallel to A and B, the 503 outbound IPsec SAs: it sends the outbound IPsec SA to A with 504 SPIb2 and the outbound IPsec SA to B with SPIa2. At this point 505 the new IPsec SAs are ready. 507 3. Once the Security Controller receives confirmation from A and B 508 that the outbound IPsec SAs have been installed, the Security 509 Controller, in parallel, deletes the old IPsec SAs from A 510 (inbound SPIa1 and outbound SPIb1) and B (outbound SPIa1 and 511 inbound SPIb1). 513 If some of the operations in step 1 fail (e.g. the NSF A reports an 514 error when the Security Controller is trying to install a new inbound 515 IPsec SA) the Security Controller must perform rollback operations by 516 removing any new inbound SA that had been successfully installed 517 during step 1. 519 If step 1 is successful but some of the operations in step 2 fails 520 (e.g. the NSF A reports an error when the Security Controller is 521 trying to install the new outbound IPsec SA), the Security Controller 522 must perform a rollback operation by deleting any new outbound SA 523 that had been successfully installed during step 2 and by deleting 524 the inbound SAs created in step 1. 526 If the steps 1 an 2 are successful and the step 3 fails the Security 527 Controller will avoid any rollback of the operations carried out in 528 step 1 and step 2 since new and valid IPsec SAs were created and are 529 functional. The Security Controller may reattempt to remove the old 530 inbound and outbound SAs in NSF A and NSF B several times until it 531 receives a success or it gives up. In the last case, the old IPsec 532 SAs will be removed when the hard lifetime is reached. 534 5.3.2. NSF state loss. 536 If one of the NSF restarts, it will lose the IPsec state (affected 537 NSF). By default, the Security Controller can assume that all the 538 state has been lost and therefore it will have to send IKEv2, SPD and 539 PAD information to the NSF in the IKE case, and SPD and SAD 540 information in IKE-less case. 542 In both cases, the Security Controller is aware of the affected NSF 543 (e.g. the NETCONF/TCP connection is broken with the affected NSF, the 544 Security Controller is receiving sadb-bad-spi notification from a 545 particular NSF, etc.). Moreover, the Security Controller has a 546 register about all the NSFs that have IPsec SAs with the affected 547 NSF. Therefore, it knows the affected IPsec SAs. 549 In IKE case, the Security Controller will configure the affected NSF 550 with the new IKEv2, SPD and PAD information. It has also to send new 551 parameters (e.g. a new fresh PSK for authentication) to the NSFs 552 which have IKEv2 SAs and IPsec SAs with the affected NSF. Finally, 553 the Security Controller will instruct the affected NSF to start the 554 IKEv2 negotiation with the new configuration. 556 In IKE-less case, if the Security Controller detects that a NSF has 557 lost the IPsec SAs it will delete the old IPsec SAs on the non-failed 558 nodes, established with the failed node (step 1). This prevents the 559 non-failed nodes from leaking plaintext. If the affected node comes 560 to live, the Security Controller will configure the new inbound IPsec 561 SAs between the affected node and all the nodes it was talking to 562 (step 2). After these inbound IPsec SAs have been established, the 563 Security Controller can configure the outbound IPsec SAs in parallel 564 (step 3). 566 Nevertheless other more optimized options can be considered (e.g. 567 making the IKEv2 configuration permanent between reboots). 569 5.3.3. NAT Traversal 571 In the IKE case, IKEv2 already provides a mechanism to detect whether 572 some of the peers or both are located behind a NAT. If there is a 573 NAT network configured between two peers, it is required to activate 574 the usage of UDP or TCP/TLS encapsulation for ESP packets ([RFC3948], 575 [RFC8229]). Note that the usage of IPsec transport mode when NAT is 576 required MUST NOT be used in this specification. 578 On the contrary, the IKE-less case does not have any protocol in the 579 NSFs to detect whether they are located behind a NAT or not. 580 However, the SDN paradigm generally assumes the Security Controller 581 has a view of the network under its control. This view is built 582 either requesting information to the NSFs under its control, or 583 because these NSFs inform the Security Controller. Based on this 584 information, the Security Controller can guess if there is a NAT 585 configured between two hosts, and apply the required policies to both 586 NSFs besides activating the usage of UDP or TCP/TLS encapsulation of 587 ESP packets ([RFC3948], [RFC8229]). 589 For example, the Security Controller could directly request the NSF 590 for specific data such as networking configuration, NAT support, etc. 591 Protocols such as NETCONF or SNMP can be used here. For example, RFC 592 7317 [RFC7317] provides a YANG data model for system management or 593 [I-D.ietf-opsawg-nat-yang] a data model for NAT management. The 594 Security Controller can use this NETCONF module with a NSF to collect 595 NAT information or even configure a NAT network. In any case, if 596 this NETCONF module is not available in the NSF and the Security 597 Controller does not have a mechanism to know whether a host is behind 598 a NAT or not, then the IKE case should be the right choice and not 599 the IKE-less case. 601 5.3.4. NSF Discovery 603 The assumption in this document is that, for both cases, before a NSF 604 can operate in this system, it MUST be registered in the Security 605 Controller. In this way, when the NSF comes to live and establishes 606 a connection to the Security Controller, it knows that the NSF is 607 valid for joining the system. 609 Either during this registration process or when the NSF connects with 610 the Security Controller, the Security Controller MUST discover 611 certain capabilities of this NSF, such as what is the cryptographic 612 suite supported, authentication method, the support of the IKE case 613 or the IKE-less case, etc. This discovery process is out of the 614 scope of this document. 616 6. YANG configuration data models 618 In order to support the IKE and IKE-less cases we have modeled the 619 different parameters and values that must be configured to manage 620 IPsec SAs. Specifically, IKE requires modeling IKEv2, SPD and PAD, 621 while IKE-less case requires configuration models for the SPD and 622 SAD. We have defined three models: ietf-ipsec-common (Appendix A), 623 ietf-ipsec-ike (Appendix B, IKE case), ietf-ipsec-ikeless 624 (Appendix C, IKE-less case). Since the model ietf-ipsec-common has 625 only typedef and groupings common to the other modules, we only show 626 a simplified view of the ietf-ipsec-ike and ietf-ipsec-ikeless 627 models. 629 6.1. IKE case model 631 The model related to IKEv2 has been extracted from reading IKEv2 632 standard in [RFC7296], and observing some open source 633 implementations, such as Strongswan [strongswan] or Libreswan 634 [libreswan]. 636 The definition of the PAD model has been extracted from the 637 specification in section 4.4.3 in [RFC4301] (NOTE: We have observed 638 that many implementations integrate PAD configuration as part of the 639 IKEv2 configuration). 641 module: ietf-ipsec-ike 642 +--rw ipsec-ike 643 +--rw pad 644 | +--rw pad-entry* [name] 645 | +--rw name string 646 | +--rw (identity) 647 | | +--:(ipv4-address) 648 | | | +--rw ipv4-address? inet:ipv4-address 649 | | +--:(ipv6-address) 650 | | | +--rw ipv6-address? inet:ipv6-address 651 | | +--:(fqdn-string) 652 | | | +--rw fqdn-string? inet:domain-name 653 | | +--:(rfc822-address-string) 654 | | | +--rw rfc822-address-string? string 655 | | +--:(dnx509) 656 | | | +--rw dnx509? string 657 | | +--:(gnx509) 658 | | | +--rw gnx509? string 659 | | +--:(id-key) 660 | | | +--rw id-key? string 661 | | +--:(id-null) 662 | | +--rw id-null? empty 663 | +--rw auth-protocol? auth-protocol-type 664 | +--rw peer-authentication 665 | +--rw auth-method? auth-method-type 666 | +--rw eap-method 667 | | +--rw eap-type uint8 668 | +--rw pre-shared 669 | | +--rw secret? yang:hex-string 670 | +--rw digital-signature 671 | +--rw ds-algorithm? uint8 672 | +--rw (public-key) 673 | | +--:(raw-public-key) 674 | | | +--rw raw-public-key? binary 675 | | +--:(cert-data) 676 | | +--rw cert-data? ct:x509 677 | +--rw private-key? binary 678 | +--rw ca-data* ct:x509 679 | +--rw crl-data? ct:crl 680 | +--rw crl-uri? inet:uri 681 | +--rw oscp-uri? inet:uri 682 +--rw conn-entry* [name] 683 | +--rw name string 684 | +--rw autostartup? autostartup-type 685 | +--rw initial-contact? boolean 686 | +--rw version? auth-protocol-type 687 | +--rw fragmentation? boolean 688 | +--rw ike-sa-lifetime-soft 689 | | +--rw rekey-time? uint32 690 | | +--rw reauth-time? uint32 691 | +--rw ike-sa-lifetime-hard 692 | | +--rw over-time? uint32 693 | +--rw authalg* ic:integrity-algorithm-type 694 | +--rw encalg* ic:encryption-algorithm-type 695 | +--rw dh-group? pfs-group 696 | +--rw half-open-ike-sa-timer? uint32 697 | +--rw half-open-ike-sa-cookie-threshold? uint32 698 | +--rw local 699 | | +--rw local-pad-entry-name? string 700 | +--rw remote 701 | | +--rw remote-pad-entry-name? string 702 | +--rw encapsulation-type 703 | | +--rw espencap? esp-encap 704 | | +--rw sport? inet:port-number 705 | | +--rw dport? inet:port-number 706 | | +--rw oaddr* inet:ip-address 707 | +--rw spd 708 | | +--rw spd-entry* [name] 709 | | +--rw name string 710 | | +--rw ipsec-policy-config 711 | | +--rw anti-replay-window? uint64 712 | | +--rw traffic-selector 713 | | | +--rw local-subnet inet:ip-prefix 714 | | | +--rw remote-subnet inet:ip-prefix 715 | | | +--rw inner-protocol? ipsec-inner-protocol 716 | | | +--rw local-ports* [start end] 717 | | | | +--rw start inet:port-number 718 | | | | +--rw end inet:port-number 719 | | | +--rw remote-ports* [start end] 720 | | | +--rw start inet:port-number 721 | | | +--rw end inet:port-number 722 | | +--rw processing-info 723 | | | +--rw action? ipsec-spd-action 724 | | | +--rw ipsec-sa-cfg 725 | | | +--rw pfp-flag? boolean 726 | | | +--rw ext-seq-num? boolean 727 | | | +--rw seq-overflow? boolean 728 | | | +--rw stateful-frag-check? boolean 729 | | | +--rw mode? ipsec-mode 730 | | | +--rw protocol-parameters? ipsec-protocol-parameters 731 | | | +--rw esp-algorithms 732 | | | | +--rw integrity* integrity-algorithm-type 733 | | | | +--rw encryption* encryption-algorithm-type 734 | | | | +--rw tfc-pad? boolean 735 | | | +--rw tunnel 736 | | | +--rw local inet:ip-address 737 | | | +--rw remote inet:ip-address 738 | | | +--rw df-bit? enumeration 739 | | | +--rw bypass-dscp? boolean 740 | | | +--rw dscp-mapping? yang:hex-string 741 | | | +--rw ecn? boolean 742 | | +--rw spd-mark 743 | | +--rw mark? uint32 744 | | +--rw mask? yang:hex-string 745 | +--rw child-sa-info 746 | | +--rw pfs-groups* pfs-group 747 | | +--rw child-sa-lifetime-soft 748 | | | +--rw time? uint32 749 | | | +--rw bytes? uint32 750 | | | +--rw packets? uint32 751 | | | +--rw idle? uint32 752 | | | +--rw action? ic:lifetime-action 753 | | +--rw child-sa-lifetime-hard 754 | | +--rw time? uint32 755 | | +--rw bytes? uint32 756 | | +--rw packets? uint32 757 | | +--rw idle? uint32 758 | +--ro state 759 | +--ro initiator? boolean 760 | +--ro initiator-ikesa-spi? ike-spi 761 | +--ro responder-ikesa-spi? ike-spi 762 | +--ro nat-local? boolean 763 | +--ro nat-remote? boolean 764 | +--ro encapsulation-type 765 | | +--ro espencap? esp-encap 766 | | +--ro sport? inet:port-number 767 | | +--ro dport? inet:port-number 768 | | +--ro oaddr* inet:ip-address 769 | +--ro established? uint64 770 | +--ro current-rekey-time? uint64 771 | +--ro current-reauth-time? uint64 772 +--ro number-ike-sas 773 +--ro total? uint64 774 +--ro half-open? uint64 775 +--ro half-open-cookies? uint64 777 Appendix D shows an example of IKE case configuration for a NSF, in 778 tunnel mode (gateway-to-gateway), with NSFs authentication based on 779 X.509 certificates. 781 6.2. IKE-less case model 783 For this case, the definition of the SPD model has been mainly 784 extracted from the specification in section 4.4.1 and Appendix D in 785 [RFC4301], though with some simplications. For example, each IPsec 786 policy (spd-entry) contains one traffic selector, instead a list of 787 them. The reason is that we have observed real kernel 788 implementations only admit a traffic selector per IPsec policy. 790 The definition of the SAD model has been extracted from the 791 specification in section 4.4.2 in [RFC4301]. Note that this model 792 not only allows to associate an IPsec SA with its corresponding 793 policy through the specific traffic selector but also an identifier 794 (reqid). 796 The notifications model has been defined using as reference the 797 PF_KEYv2 standard in [RFC2367]. 799 module: ietf-ipsec-ikeless 800 +--rw ipsec-ikeless 801 +--rw spd 802 | +--rw spd-entry* [name] 803 | +--rw name string 804 | +--rw direction? ic:ipsec-traffic-direction 805 | +--rw reqid? uint64 806 | +--rw ipsec-policy-config 807 | +--rw anti-replay-window? uint64 808 | +--rw traffic-selector 809 | | +--rw local-subnet inet:ip-prefix 810 | | +--rw remote-subnet inet:ip-prefix 811 | | +--rw inner-protocol? ipsec-inner-protocol 812 | | +--rw local-ports* [start end] 813 | | | +--rw start inet:port-number 814 | | | +--rw end inet:port-number 815 | | +--rw remote-ports* [start end] 816 | | +--rw start inet:port-number 817 | | +--rw end inet:port-number 818 | +--rw processing-info 819 | | +--rw action? ipsec-spd-action 820 | | +--rw ipsec-sa-cfg 821 | | +--rw pfp-flag? boolean 822 | | +--rw ext-seq-num? boolean 823 | | +--rw seq-overflow? boolean 824 | | +--rw stateful-frag-check? boolean 825 | | +--rw mode? ipsec-mode 826 | | +--rw protocol-parameters? 827 | | +--rw esp-algorithms 828 | | | +--rw integrity* integrity-algorithm-type 829 | | | +--rw encryption* encryption-algorithm-type 830 | | | +--rw tfc-pad? boolean 831 | | +--rw tunnel 832 | | +--rw local inet:ip-address 833 | | +--rw remote inet:ip-address 834 | | +--rw df-bit? enumeration 835 | | +--rw bypass-dscp? boolean 836 | | +--rw dscp-mapping? yang:hex-string 837 | | +--rw ecn? boolean 838 | +--rw spd-mark 839 | +--rw mark? uint32 840 | +--rw mask? yang:hex-string 841 +--rw sad 842 +--rw sad-entry* [name] 843 +--rw name string 844 +--rw reqid? uint64 845 +--rw ipsec-sa-config 846 | +--rw spi uint32 847 | +--rw ext-seq-num? boolean 848 | +--rw seq-number-counter? uint64 849 | +--rw seq-overflow? boolean 850 | +--rw anti-replay-window? uint32 851 | +--rw traffic-selector 852 | | +--rw local-subnet inet:ip-prefix 853 | | +--rw remote-subnet inet:ip-prefix 854 | | +--rw inner-protocol? ipsec-inner-protocol 855 | | +--rw local-ports* [start end] 856 | | | +--rw start inet:port-number 857 | | | +--rw end inet:port-number 858 | | +--rw remote-ports* [start end] 859 | | +--rw start inet:port-number 860 | | +--rw end inet:port-number 861 | +--rw protocol-parameters? ic:ipsec-protocol-parameters 862 | +--rw mode? ic:ipsec-mode 863 | +--rw esp-sa 864 | | +--rw encryption 865 | | | +--rw encryption-algorithm? ic:encryption-algorithm-type 866 | | | +--rw key? yang:hex-string 867 | | | +--rw iv? yang:hex-string 868 | | +--rw integrity 869 | | +--rw integrity-algorithm? ic:integrity-algorithm-type 870 | | +--rw key? yang:hex-string 871 | +--rw sa-lifetime-hard 872 | | +--rw time? uint32 873 | | +--rw bytes? uint32 874 | | +--rw packets? uint32 875 | | +--rw idle? uint32 876 | +--rw sa-lifetime-soft 877 | | +--rw time? uint32 878 | | +--rw bytes? uint32 879 | | +--rw packets? uint32 880 | | +--rw idle? uint32 881 | | +--rw action? ic:lifetime-action 882 | +--rw tunnel 883 | | +--rw local inet:ip-address 884 | | +--rw remote inet:ip-address 885 | | +--rw df-bit? enumeration 886 | | +--rw bypass-dscp? boolean 887 | | +--rw dscp-mapping? yang:hex-string 888 | | +--rw ecn? boolean 889 | +--rw encapsulation-type 890 | +--rw espencap? esp-encap 891 | +--rw sport? inet:port-number 892 | +--rw dport? inet:port-number 893 | +--rw oaddr* inet:ip-address 894 +--ro ipsec-sa-state 895 +--ro sa-lifetime-current 896 | +--ro time? uint32 897 | +--ro bytes? uint32 898 | +--ro packets? uint32 899 | +--ro idle? uint32 900 +--ro replay-stats 901 +--ro replay-window? uint64 902 +--ro packet-dropped? uint64 903 +--ro failed? uint32 904 +--ro seq-number-counter? uint64 906 notifications: 907 +---n sadb-acquire 908 | +--ro ipsec-policy-name string 909 | +--ro traffic-selector 910 | +--ro local-subnet inet:ip-prefix 911 | +--ro remote-subnet inet:ip-prefix 912 | +--ro inner-protocol? ipsec-inner-protocol 913 | +--ro local-ports* [start end] 914 | | +--ro start inet:port-number 915 | | +--ro end inet:port-number 916 | +--ro remote-ports* [start end] 917 | +--ro start inet:port-number 918 | +--ro end inet:port-number 919 +---n sadb-expire 920 | +--ro ipsec-sa-name string 921 | +--ro soft-lifetime-expire? boolean 922 | +--ro lifetime-current 923 | +--ro time? uint32 924 | +--ro bytes? uint32 925 | +--ro packets? uint32 926 | +--ro idle? uint32 927 +---n sadb-seq-overflow 928 | +--ro ipsec-sa-name string 929 +---n sadb-bad-spi 930 +--ro spi uint32 932 Appendix E shows an example of IKE-less case configuration for a NSF, 933 in transport mode (host-to-host), with NSFs authentication based on 934 shared secrets. For the IKE-less case, Appendix F shows examples of 935 IPsec SA expire, acquire, sequence number overflow and bad SPI 936 notifications. 938 7. Use cases examples 940 This section explains how different traditional configurations, that 941 is, host-to-host and gateway-to-gateway, are deployed using this SDN- 942 based IPsec management service. In turn, these configurations will 943 be typical in modern networks where, for example, virtualization will 944 be key. 946 7.1. Host-to-host or gateway-to-gateway under the same Security 947 Controller 948 +----------------------------------------+ 949 | Security Controller | 950 | | 951 (1)| +--------------+ (2)+--------------+ | 952 Flow-based ------> |Translate into|--->| South. Prot. | | 953 Security. Pol. | |IPsec Policies| | | | 954 | +--------------+ +--------------+ | 955 | | | | 956 | | | | 957 +--------------------------|-----|-------+ 958 | | 959 | (3) | 960 |-------------------------+ +---| 961 V V 962 +----------------------+ +----------------------+ 963 | NSF A |<=======>| NSF B | 964 |IKEv2/IPsec(SPD/PAD) | |IKEv2/IPsec(SPD/PAD) | 965 +----------------------+ (4) +----------------------+ 967 Figure 3: Host-to-host / gateway-to-gateway single Security 968 Controller for the IKE case. 970 Figure 3 describes the IKE case: 972 1. The administrator defines general flow-based security policies. 973 The Security Controller looks for the NSFs involved (NSF A and 974 NSF B). 976 2. The Security Controller generates IKEv2 credentials for them and 977 translates the policies into SPD and PAD entries. 979 3. The Security Controller inserts an IKEv2 configuration that 980 includes the SPD and PAD entries in both NSF A and NSF B. If 981 some of operations with NSF A and NSF B fail the Security 982 Controller will stop the process and perform a rollback operation 983 by deleting any IKEv2, SPD and PAD configuration that had been 984 successfully installed in NSF A or B. 986 4. If the previous step is successful, the flow is protected by 987 means of the IPsec SA established with IKEv2. 989 +----------------------------------------+ 990 | (1) Security Controller | 991 Flow-based | | 992 Security -----------| | 993 Policy | V | 994 | +---------------+ (2)+-------------+ | 995 | |Translate into |--->| South. Prot.| | 996 | |IPsec policies | | | | 997 | +---------------+ +-------------+ | 998 | | | | 999 | | | | 1000 +-------------------------| --- |--------+ 1001 | | 1002 | (3) | 1003 |----------------------+ +--| 1004 V V 1005 +------------------+ +------------------+ 1006 | NSF A |<=====>| NSF B | 1007 |IPsec(SPD/SAD) | 4) |IPsec(SPD/SAD) | 1008 +------------------+ +------------------+ 1010 Figure 4: Host-to-host / gateway-to-gateway single Security 1011 Controller for IKE-less case. 1013 In the IKE-less case, flow-based security policies defined by the 1014 administrator are translated into IPsec SPD entries and inserted into 1015 the corresponding NSFs. Besides, fresh SAD entries will be also 1016 generated by the Security Controller and enforced in the NSFs. In 1017 this case, the Security Controller does not run any IKEv2 1018 implementation (neither the NSFs), and it provides the cryptographic 1019 material for the IPsec SAs. These keys will be also distributed 1020 securely through the southbound interface. Note that this is 1021 possible because both NSFs are managed by the same Security 1022 Controller. 1024 Figure 4 describes the IKE-less case, when a data packet needs to be 1025 protected in the path between the NSF A and NSF B: 1027 1. The administrator establishes the flow-based security policies, 1028 and the Security Controller looks for the involved NSFs. 1030 2. The Security Controller translates the flow-based security 1031 policies into IPsec SPD and SAD entries. 1033 3. The Security Controller inserts these entries in both NSF A and 1034 NSF B IPsec databases (SPD and SAD). The following text 1035 describes how this happens between two NSFs A and B: 1037 * The Security Controller chooses two random values as SPIs: for 1038 example, SPIa1 for NSF A and SPIb1 for NSF B. These numbers 1039 MUST not be in conflict with any IPsec SA in NSF A or NSF B. 1040 It also generates fresh cryptographic material for the new 1041 inbound/outbound IPsec SAs and their parameters and send 1042 simultaneously the new inbound IPsec SA with SPIa1 and new 1043 outbound IPsec SAs with SPIb1 to NSF A; and the new inbound 1044 IPsec SA with SPIb1 and new outbound IPsec SAs with SPIa1 to 1045 B, together with the corresponding IPsec policies. 1047 * Once the Security Controller receives confirmation from NSF A 1048 and NSF B, the controller knows that the IPsec SAs are 1049 correctly installed and ready. 1051 If some of the operations described above fails (e.g. the NSF A 1052 reports an error when the Security Controller is trying to 1053 install the SPD entry, the new inbound and outbound IPsec SAs) 1054 the Security Controller must perform rollback operations by 1055 deleting any new inbound or outbound SA and SPD entry that had 1056 been successfully installed in any of the NSFs (e.g NSF B) and 1057 stop the process (NOTE: the Security Controller may retry several 1058 times before giving up). Other alternative to this operation is: 1059 the Security Controller sends first the IPsec policies and new 1060 inbound IPsec SAs to A and B and once it obtains a successful 1061 confirmation of these operations from NSF A and NSF B, it 1062 proceeds with installing to the new outbound IPsec SAs. However, 1063 this may increase the latency to complete the process. As an 1064 advantage, no traffic is sent over the network until the IPsec 1065 SAs are completely operative. In any case other alternatives may 1066 be possible. Finally, it is worth mentioning that the Security 1067 Controller associates a lifetime to the new IPsec SAs. When this 1068 lifetime expires, the NSF will send a sadb-expire notification to 1069 the Security Controller in order to start the rekeying process. 1071 4. The flow is protected with the IPsec SA established by the 1072 Security Controller. 1074 Instead of installing IPsec policies in the SPD and IPsec SAs in the 1075 SAD in step 3 (proactive mode), it is also possible that the Security 1076 Controller only installs the SPD entries in step 3 (reactive mode). 1077 In such a case, when a data packet requires to be protected with 1078 IPsec, the NSF that saw first the data packet will send a sadb- 1079 acquire notification that informs the Security Controller that needs 1080 SAD entries with the IPsec SAs to process the data packet. In such 1081 as reactive mode, since IPsec policies are already installed in the 1082 SPD, the Security Controller installs first the new IPsec SAs in NSF 1083 A and B with the operations described in step 3 but without sending 1084 any IPsec policies. Again, if some of the operations installing the 1085 new inbound/outbound IPsec SAs fail, the Security Controller stops 1086 the process and performs a rollback operation by deleting any new 1087 inbound/outbound SAs that had been successfully installed. 1089 Both NSFs could be two hosts that exchange traffic and require to 1090 establish an end-to-end security association to protect their 1091 communications (host-to-host) or two gateways (gateway-to-gateway), 1092 for example, within an enterprise that needs to protect the traffic 1093 between the networks of two branch offices. 1095 Applicability of these configurations appear in current and new 1096 networking scenarios. For example, SD-WAN technologies are providing 1097 dynamic and on-demand VPN connections between branch offices, or 1098 between branches and SaaS cloud services. Beside, IaaS services 1099 providing virtualization environments are deployments solutions based 1100 on IPsec to provide secure channels between virtual instances (host- 1101 to-host) and providing VPN solutions for virtualized networks 1102 (gateway-to-gateway). 1104 In general (for IKE and IKE-less cases), this system has various 1105 advantages: 1107 1. It allows to create IPsec SAs among two NSFs, based only on the 1108 application of general Flow-based Security Policies at the 1109 application layer. Thus, administrators can manage all security 1110 associations in a centralized point with an abstracted view of 1111 the network. 1113 2. Any NSF deployed in the system does not need manual 1114 configuration, therefore allowing its deployment in an automated 1115 manner. 1117 7.2. Host-to-host or gateway-to-gateway under different Security 1118 Controllers 1120 It is also possible that two NSFs (i.e. NSF A and NSF B) are under 1121 the control of two different Security Controllers. This may happen, 1122 for example, when two organizations, namely Enterprise A and 1123 Enterprise B, have their headquarters interconnected through a WAN 1124 connection and they both have deployed a SDN-based architecture to 1125 provide connectivity to all their clients. 1127 +-------------+ +-------------+ 1128 | | | | 1129 Flow-based| Security |<=========>| Security <--Flow-based 1130 Sec. Pol.--> Controller | (3) | Controller | Sec. Pol. 1131 (1) | A | | B | (2) 1132 +-------------+ +-------------+ 1133 | | 1134 | (4) (4) | 1135 V V 1136 +--------------------+ +--------------------+ 1137 | NSF A |<=======>| NSF B | 1138 |IKEv2/IPsec(SPD/PAD)| |IKEv2/IPsec(SPD/PAD)| 1139 +--------------------+ (5) +--------------------+ 1141 Figure 5: Different Security Controllers in the IKE case. 1143 Figure 5 describes IKE case when two Security Controllers are 1144 involved in the process. 1146 1. The A's administrator establishes general Flow-based Security 1147 Policies in Security Controller A. 1149 2. The B's administrator establishes general Flow-based Security 1150 Policies in Security Controller B. 1152 3. The Security Controller A realizes that protection is required 1153 between the NSF A and NSF B, but the NSF B is under the control 1154 of another Security Controller (Security Controller B), so it 1155 starts negotiations with the other controller to agree on the 1156 IPsec SPD policies and IKEv2 credentials for their respective 1157 NSFs. NOTE: This may require extensions in the East/West 1158 interface. 1160 4. Then, both Security Controllers enforce the IKEv2 credentials, 1161 related parameters and the SPD and PAD entries in their 1162 respective NSFs. 1164 5. The flow is protected with the IPsec SAs established with IKEv2 1165 between both NSFs. 1167 +--------------+ +--------------+ 1168 | | | | 1169 Flow-based. ---> | | <---Flow-based 1170 Prot. | Security |<===========>| Security |Sec. 1171 Pol.(1)| Controller | (3) | Controller |Pol. (2) 1172 | A | | B | 1173 +--------------+ +--------------+ 1174 | | 1175 | (4) (4) | 1176 V V 1177 +--------------+ (5) +--------------+ 1178 | NSF A |<==============>| NSF B | 1179 |IPsec(SPD/SAD)| |IPsec(SPD/SAD)| 1180 +--------------+ +--------------+ 1182 Figure 6: Different Security Controllers in the IKE-less case. 1184 Figure 6 describes IKE-less case when two Security Controllers are 1185 involved in the process. 1187 1. The A's administrator establishes general Flow Protection 1188 Policies in Security Controller A. 1190 2. The B's administrator establishes general Flow Protection 1191 Policies in Security Controller B. 1193 3. The Security Controller A realizes that the flow between NSF B 1194 and NSF B MUST be protected. Nevertheless, it notices that NSF B 1195 is under the control of another Security Controller B, so it 1196 starts negotiations with the other controller to agree on the 1197 IPsec SPD and SAD entries that define the IPsec SAs. NOTE: It 1198 would worth evaluating IKEv2 as the protocol for the East/West 1199 interface in this case. 1201 4. Once the Security Controllers have agreed on the key material and 1202 the details of the IPsec SAs, they both enforce this information 1203 into their respective NSFs. 1205 5. The flow is protected with the IPsec SAs established by both 1206 Security Controllers in their respective NSFs. 1208 8. IANA Considerations 1210 This document registers three URIs in the "ns" subregistry of the 1211 IETF XML Registry [RFC3688]. Following the format in [RFC3688], the 1212 following registrations are requested: 1214 URI: urn:ietf:params:xml:ns:yang:ietf-ipsec-common 1215 Registrant Contact: The I2NSF WG of the IETF. 1216 XML: N/A, the requested URI is an XML namespace. 1218 URI: urn:ietf:params:xml:ns:yang:ietf-ipsec-ike 1219 Registrant Contact: The I2NSF WG of the IETF. 1220 XML: N/A, the requested URI is an XML namespace. 1222 URI: urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless 1223 Registrant Contact: The I2NSF WG of the IETF. 1224 XML: N/A, the requested URI is an XML namespace. 1226 This document registers three YANG modules in the "YANG Module Names" 1227 registry [RFC6020]. Following the format in [RFC6020], the following 1228 registrations are requested: 1230 Name: ietf-ipsec-common 1231 Namespace: urn:ietf:params:xml:ns:yang:ietf-ipsec-common 1232 Prefix: ic 1233 Reference: RFC XXXX 1235 Name: ietf-ipsec-ike 1236 Namespace: urn:ietf:params:xml:ns:yang:ietf-ipsec-ike 1237 Prefix: ike 1238 Reference: RFC XXXX 1240 Name: ietf-ipsec-ikeless 1241 Namespace: urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless 1242 Prefix: ikeless 1243 Reference: RFC XXXX 1245 9. Security Considerations 1247 First of all, this document shares all the security issues of SDN 1248 that are specified in the "Security Considerations" section of 1249 [ITU-T.Y.3300] and [RFC8192]. 1251 On the one hand, it is important to note that there MUST exit a 1252 security association between the Security Controller and the NSFs to 1253 protect of the critical information (cryptographic keys, 1254 configuration parameter, etc...) exchanged between these entities. 1255 For example, when NETCONF is used as southbound protocol between the 1256 Security Controller and the NSFs, it is defined that TLS or SSH 1257 security association MUST be established between both entities. 1259 On the other hand, if encryption is mandatory for all traffic of a 1260 NSF, its default policy MUST be to drop (DISCARD) packets to prevent 1261 cleartext packet leaks. This default policy MUST be in the startup 1262 configuration datastore in the NSF before the NSF contacts with the 1263 Security Controller. Moreover, the startup configuration datastore 1264 MUST be pre-configured with the required ALLOW policies that allow to 1265 communicate the NSF with the Security Controller once the NSF is 1266 deployed. This pre-configuration step is not carried out by the 1267 Security Controller but by some other entity before the NSF 1268 deployment. In this manner, when the NSF starts/reboots, it will 1269 always apply first the configuration in the startup configuration 1270 before contacting the Security Controller. 1272 Finally, we have divided this section in two parts in order to 1273 analyze different security considerations for both cases: NSF with 1274 IKEv2 (IKE case) and NSF without IKEv2 (IKE-less case). In general, 1275 the Security Controller, as typically in the SDN paradigm, is a 1276 target for different type of attacks. Thus, the Security Controller 1277 is a key entity in the infrastructure and MUST be protected 1278 accordingly. In particular, the Security Controller will handle 1279 cryptographic material so that the attacker may try to access this 1280 information. Although we can assume this attack will not likely to 1281 happen due to the assumed security measurements to protect the 1282 Security Controller, it deserves some analysis in the hypothetical 1283 case the attack occurs. The impact is different depending on the IKE 1284 case or IKE-less case. 1286 9.1. IKE case 1288 In IKE case, the Security Controller sends IKE credentials (PSK, 1289 public/private keys, certificates, etc.) to the NSFs using the 1290 security association between Security Controller and NSFs. The 1291 general recommendation is that the Security Controller MUST NOT store 1292 the IKE credentials after distributing them. Moreover, the NSFs MUST 1293 NOT allow the reading of these values once they have been applied by 1294 the Security Controller (i.e. write only operations). One option is 1295 to return always the same value (i.e. all 0s) if a read operation is 1296 carried out. If the attacker has access to the Security Controller 1297 during the period of time that key material is generated, it might 1298 have access to the key material. Since these values are used during 1299 NSF authentication in IKEv2, it may impersonate the affected NSFs. 1300 Several recommendations are important. If PSK authentication is used 1301 in IKEv2, the Security Controller MUST remove the PSK immediately 1302 after generating and distributing it. Moreover, the PSK MUST have a 1303 proper length (e.g. minimum 128 bit length) and strength. When 1304 public/private keys are used, the Security Controller MAY generate 1305 both public key and private key. In such a case, the Security 1306 Controller MUST remove the associated private key immediately after 1307 distributing them to the NSFs. Alternatively, the NSF could generate 1308 the private key and export only the public key to the Security 1309 Controller. If certificates are used, the NSF MAY generate the 1310 private key and exports the public key for certification to the 1311 Security Controller. How the NSF generates these cryptographic 1312 material (public key/private keys) and export the public key, or it 1313 is instructed to do so, it is out of the scope of this document. 1315 9.2. IKE-less case 1317 In the IKE-less case, the Security Controller sends the IPsec SA 1318 information to the NSF's SAD that includes the private session keys 1319 required for integrity and encryption. The general recommendation is 1320 that it MUST NOT store the keys after distributing them. Moreover, 1321 the NSFs receiving private key material MUST NOT allow the reading of 1322 these values by any other entity (including the Security Controller 1323 itself) once they have been applied (i.e. write only operations) into 1324 the NSFs. Nevertheless, if the attacker has access to the Security 1325 Controller during the period of time that key material is generated, 1326 it may obtain these values. In other words, the attacker might be 1327 able to observe the IPsec traffic and decrypt, or even modify and re- 1328 encrypt the traffic between peers. 1330 9.3. YANG modules 1332 The YANG module specified in this document defines a schema for data 1333 that is designed to be accessed via network management protocols such 1334 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 1335 is the secure transport layer, and the mandatory-to-implement secure 1336 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 1337 is HTTPS, and the mandatory-to-implement secure transport is TLS 1338 [RFC8446]. 1340 The Network Configuration Access Control Model (NACM) [RFC8446] 1341 provides the means to restrict access for particular NETCONF or 1342 RESTCONF users to a preconfigured subset of all available NETCONF or 1343 RESTCONF protocol operations and content. 1345 There are a number of data nodes defined in these YANG modules that 1346 are writable/creatable/deletable (i.e., config true, which is the 1347 default). These data nodes may be considered sensitive or vulnerable 1348 in some network environments. Write operations (e.g., edit-config) 1349 to these data nodes without proper protection can have a negative 1350 effect on network operations. These are the subtrees and data nodes 1351 and their sensitivity/vulnerability: 1353 The YANG modules describe configuration data for the IKE case (ietf- 1354 ipsec-ike) and IKE-less case (ietf-ipsec-ikeless). There is a common 1355 module (ietf-ipsec-common) used in both cases. 1357 For the IKE case (ietf-ipsec-ike): 1359 /ipsec-ike: The entire container in this module is sensitive to 1360 write operations. An attacker may add/modify the credentials 1361 to be used for the authentication (e.g. to impersonate a NSF), 1362 the trust root (e.g. changing the trusted CA certificates), 1363 the cryptographic algorithms (allowing a downgrading attack), 1364 the IPsec policies (e.g. by allowing leaking of data traffic by 1365 changing to a allow policy), and in general changing the IKE SA 1366 conditions and credentials between any NSF. 1368 For the IKE-less case (ietf-ipsec-ikeless): 1370 /ipsec-ikeless: The entire container in this module is 1371 sensitive to write operations. An attacker may add/modify/ 1372 delete any IPsec policies (e.g. by allowing leaking of data 1373 traffic by changing to a allow policy) in the /ipsec-ikeless/ 1374 spd container, and add/modify/delete any IPsec SAs between two 1375 NSF by means of /ipsec-ikeless/sad container and, in general 1376 changing any IPsec SAs and IPsec policies between any NSF. 1378 Some of the readable data nodes in this YANG module may be considered 1379 sensitive or vulnerable in some network environments. It is thus 1380 important to control read access (e.g., via get, get-config, or 1381 notification) to these data nodes. These are the subtrees and data 1382 nodes and their sensitivity/vulnerability: 1384 For the IKE case (ietf-ipsec-ike): 1386 /ipsec-ike/pad: This container includes sensitive information 1387 to read operations. This information should never be returned 1388 to a client. For example, cryptographic material configured in 1389 the NSFs: peer-authentication/pre-shared/secret and peer- 1390 authentication/digital-signature/private-key are already 1391 protected by the NACM extension "default-deny-all" in this 1392 document. 1394 For the IKE-less case (ietf-ipsec-ikeless): 1396 /ipsec-ikeless/sad/ipsec-sa-config/esp-sa: This container 1397 includes symmetric keys for the IPsec SAs. For example, 1398 encryption/key contains a ESP encryption key value and 1399 encryption/iv contains a initialization vector value. 1400 Similarly, integrity/key has ESP integrity key value. Those 1401 values must not be read by anyone and are protected by the NACM 1402 extension "default-deny-all" in this document. 1404 10. Acknowledgements 1406 Authors want to thank Paul Wouters, Valery Smyslov, Sowmini Varadhan, 1407 David Carrel, Yoav Nir, Tero Kivinen, Martin Bjorklund, Graham 1408 Bartlett, Sandeep Kampati, Linda Dunbar, Carlos J. Bernardos, 1409 Alejandro Perez-Mendez, Alejandro Abad-Carrascosa, Ignacio Martinez 1410 and Ruben Ricart for their valuable comments. 1412 11. References 1414 11.1. Normative References 1416 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1417 Requirement Levels", BCP 14, RFC 2119, 1418 DOI 10.17487/RFC2119, March 1997, 1419 . 1421 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1422 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 1423 December 2005, . 1425 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1426 the Network Configuration Protocol (NETCONF)", RFC 6020, 1427 DOI 10.17487/RFC6020, October 2010, 1428 . 1430 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1431 and A. Bierman, Ed., "Network Configuration Protocol 1432 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1433 . 1435 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1436 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1437 . 1439 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 1440 Kivinen, "Internet Key Exchange Protocol Version 2 1441 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 1442 2014, . 1444 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1445 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1446 . 1448 [RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., 1449 and J. Jeong, "Interface to Network Security Functions 1450 (I2NSF): Problem Statement and Use Cases", RFC 8192, 1451 DOI 10.17487/RFC8192, July 2017, 1452 . 1454 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1455 Access Control Model", STD 91, RFC 8341, 1456 DOI 10.17487/RFC8341, March 2018, 1457 . 1459 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1460 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1461 . 1463 11.2. Informative References 1465 [I-D.carrel-ipsecme-controller-ike] 1466 Carrel, D. and B. Weiss, "IPsec Key Exchange using a 1467 Controller", draft-carrel-ipsecme-controller-ike-01 (work 1468 in progress), March 2019. 1470 [I-D.ietf-i2nsf-terminology] 1471 Hares, S., Strassner, J., Lopez, D., Xia, L., and H. 1472 Birkholz, "Interface to Network Security Functions (I2NSF) 1473 Terminology", draft-ietf-i2nsf-terminology-08 (work in 1474 progress), July 2019. 1476 [I-D.ietf-opsawg-nat-yang] 1477 Boucadair, M., Sivakumar, S., Jacquenet, C., Vinapamula, 1478 S., and Q. Wu, "A YANG Module for Network Address 1479 Translation (NAT) and Network Prefix Translation (NPT)", 1480 draft-ietf-opsawg-nat-yang-17 (work in progress), 1481 September 2018. 1483 [I-D.tran-ipsecme-yang] 1484 Tran, K., Wang, H., Nagaraj, V., and X. Chen, "Yang Data 1485 Model for Internet Protocol Security (IPsec)", draft-tran- 1486 ipsecme-yang-01 (work in progress), June 2015. 1488 [ITU-T.X.1252] 1489 "Baseline Identity Management Terms and Definitions", 1490 April 2010. 1492 [ITU-T.X.800] 1493 "Security Architecture for Open Systems Interconnection 1494 for CCITT Applications", March 1991. 1496 [ITU-T.Y.3300] 1497 "Recommendation ITU-T Y.3300", June 2014. 1499 [libreswan] 1500 The Libreswan Project, "Libreswan VPN software", July 1501 2019. 1503 [netconf-vpn] 1504 Stefan Wallin, "Tutorial: NETCONF and YANG", January 2014. 1506 [ONF-OpenFlow] 1507 ONF, "OpenFlow Switch Specification (Version 1.4.0)", 1508 October 2013. 1510 [ONF-SDN-Architecture] 1511 "SDN Architecture", June 2014. 1513 [RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key 1514 Management API, Version 2", RFC 2367, 1515 DOI 10.17487/RFC2367, July 1998, 1516 . 1518 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1519 DOI 10.17487/RFC3688, January 2004, 1520 . 1522 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 1523 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 1524 RFC 3948, DOI 10.17487/RFC3948, January 2005, 1525 . 1527 [RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and 1528 Internet Key Exchange (IKE) Document Roadmap", RFC 6071, 1529 DOI 10.17487/RFC6071, February 2011, 1530 . 1532 [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined 1533 Networking: A Perspective from within a Service Provider 1534 Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, 1535 . 1537 [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for 1538 System Management", RFC 7317, DOI 10.17487/RFC7317, August 1539 2014, . 1541 [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., 1542 Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- 1543 Defined Networking (SDN): Layers and Architecture 1544 Terminology", RFC 7426, DOI 10.17487/RFC7426, January 1545 2015, . 1547 [RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation 1548 of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229, 1549 August 2017, . 1551 [strongswan] 1552 CESNET, "StrongSwan: the OpenSource IPsec-based VPN 1553 Solution", July 2019. 1555 Appendix A. Appendix A: Common YANG model for IKE and IKE-less cases 1557 file "ietf-ipsec-common@2019-07-07.yang" 1559 module ietf-ipsec-common { 1560 yang-version 1.1; 1561 namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec-common"; 1562 prefix "ipsec-common"; 1564 import ietf-inet-types { prefix inet; } 1565 import ietf-yang-types { prefix yang; } 1567 organization "IETF I2NSF Working Group"; 1569 contact 1570 "WG Web: 1571 WG List: 1573 Author: Rafael Marin-Lopez 1574 1576 Author: Gabriel Lopez-Millan 1577 1579 Author: Fernando Pereniguez-Garcia 1580 1581 "; 1583 description 1584 "Common Data model for the IKE and IKE-less cases 1585 defined by the SDN-based IPsec flow protection service. 1587 Copyright (c) 2019 IETF Trust and the persons 1588 identified as authors of the code. All rights reserved. 1589 Redistribution and use in source and binary forms, with 1590 or without modification, is permitted pursuant to, and 1591 subject to the license terms contained in, the 1592 Simplified BSD License set forth in Section 4.c of the 1593 IETF Trust's Legal Provisions Relating to IETF Documents 1594 (https://trustee.ietf.org/license-info). 1596 This version of this YANG module is part of RFC XXXX;; 1597 see the RFC itself for full legal notices. 1599 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 1600 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 1601 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this 1602 document are to be interpreted as described in BCP 14 1603 (RFC 2119) (RFC 8174) when, and only when, they appear 1604 in all capitals, as shown here."; 1606 revision "2019-07-07" { 1607 description "Revision 05"; 1608 reference "RFC XXXX: YANG Groupings and typedef 1609 for IKE and IKE-less case"; 1610 } 1612 typedef encryption-algorithm-type { 1613 type uint16; 1614 description 1615 "The encryption algorithm is specified with a 16-bit 1616 number extracted from IANA Registry. The acceptable 1617 values MUST follow the requirement levels for 1618 encryption algorithms for ESP and IKEv2."; 1619 reference 1620 "IANA Registry- Transform Type 1 - Encryption 1621 Algorithm Transform IDs. RFC 8221 - Cryptographic 1622 Algorithm Implementation Requirements and Usage 1623 Guidance for Encapsulating Security Payload (ESP) 1624 and Authentication Header (AH) and RFC 8247 - 1625 Algorithm Implementation Requirements and Usage 1626 Guidance for the Internet Key Exchange Protocol 1627 Version 2 (IKEv2)."; 1628 } 1630 typedef integrity-algorithm-type { 1631 type uint16; 1632 description 1633 "The integrity algorithm is specified with a 16-bit 1634 number extracted from IANA Registry. 1635 The acceptable values MUST follow the requirement 1636 levels for encryption algorithms for ESP and IKEv2."; 1637 reference 1638 "IANA Registry- Transform Type 3 - Integrity 1639 Algorithm Transform IDs. RFC 8221 - Cryptographic 1640 Algorithm Implementation Requirements and Usage 1641 Guidance for Encapsulating Security Payload (ESP) 1642 and Authentication Header (AH) and RFC 8247 - 1643 Algorithm Implementation Requirements and Usage 1644 Guidance for the Internet Key Exchange Protocol 1645 Version 2 (IKEv2)."; 1646 } 1648 typedef ipsec-mode { 1649 type enumeration { 1650 enum transport { 1651 description 1652 "IPsec transport mode. No Network Address 1653 Translation (NAT) support."; 1654 } 1655 enum tunnel { 1656 description "IPsec tunnel mode."; 1657 } 1658 } 1659 description 1660 "Type definition of IPsec mode: transport or 1661 tunnel."; 1662 reference 1663 "Section 3.2 in RFC 4301."; 1664 } 1666 typedef esp-encap { 1667 type enumeration { 1668 enum espintcp { 1669 description 1670 "ESP in TCP encapsulation."; 1671 reference 1672 "RFC 8229 - TCP Encapsulation of IKE and 1673 IPsec Packets."; 1674 } 1675 enum espintls { 1676 description 1677 "ESP in TCP encapsulation using TLS."; 1678 reference 1679 "RFC 8229 - TCP Encapsulation of IKE and 1680 IPsec Packets."; 1681 } 1682 enum espinudp { 1683 description 1684 "ESP in UDP encapsulation."; 1685 reference 1686 "RFC 3948 - UDP Encapsulation of IPsec ESP 1687 Packets."; 1688 } 1689 enum none { 1690 description 1691 "NOT ESP encapsulation."; 1692 } 1693 } 1694 description 1695 "Types of ESP encapsulation when Network Address 1696 Translation (NAT) is present between two NSFs."; 1698 reference 1699 "RFC 8229 - TCP Encapsulation of IKE and IPsec 1700 Packets and RFC 3948 - UDP Encapsulation of IPsec 1701 ESP Packets."; 1702 } 1704 typedef ipsec-protocol-parameters { 1705 type enumeration { 1706 enum esp { description "IPsec ESP protocol."; } 1707 } 1708 description 1709 "Only the Encapsulation Security Protocol (ESP) is 1710 supported but it could be extended in the future."; 1711 reference 1712 "RFC 4303- IP Encapsulating Security Payload 1713 (ESP)."; 1715 } 1717 typedef lifetime-action { 1718 type enumeration { 1719 enum terminate-clear { 1720 description 1721 "Terminates the IPsec SA and allows the 1722 packets through."; 1723 } 1724 enum terminate-hold { 1725 description 1726 "Terminates the IPsec SA and drops the 1727 packets."; 1728 } 1729 enum replace { 1730 description 1731 "Replaces the IPsec SA with a new one: 1732 rekey. "; 1733 } 1734 } 1735 description 1736 "When the lifetime of an IPsec SA expires an action 1737 needs to be performed over the IPsec SA that 1738 reached the lifetime. There are three posible 1739 options: terminate-clear, terminate-hold and 1740 replace."; 1741 reference 1742 "Section 4.5 in RFC 4301."; 1743 } 1745 typedef ipsec-traffic-direction { 1746 type enumeration { 1747 enum inbound { 1748 description "Inbound traffic."; 1749 } 1750 enum outbound { 1751 description "Outbound traffic."; 1752 } 1753 } 1754 description 1755 "IPsec traffic direction is defined in two 1756 directions: inbound and outbound. From a NSF 1757 perspective inbound means the traffic that enters 1758 the NSF and outbound is the traffic that is sent 1759 from the NSF."; 1760 reference 1761 "Section 5 in RFC 4301."; 1762 } 1764 typedef ipsec-spd-action { 1765 type enumeration { 1766 enum protect { 1767 description 1768 "PROTECT the traffic with IPsec."; 1769 } 1770 enum bypass { 1771 description 1772 "BYPASS the traffic. The packet is forwarded 1773 without IPsec protection."; 1774 } 1775 enum discard { 1776 description 1777 "DISCARD the traffic. The IP packet is 1778 discarded."; 1779 } 1780 } 1781 description 1782 "The action when traffic matches an IPsec security 1783 policy. According to RFC 4301 there are three 1784 possible values: BYPASS, PROTECT AND DISCARD"; 1785 reference 1786 "Section 4.4.1 in RFC 4301."; 1787 } 1789 typedef ipsec-inner-protocol { 1790 type union { 1791 type uint8; 1792 type enumeration { 1793 enum any { 1794 value 256; 1795 description 1796 "Any IP protocol number value."; 1797 } 1798 } 1799 } 1800 default any; 1801 description 1802 "IPsec protection can be applied to specific IP 1803 traffic and layer 4 traffic (TCP, UDP, SCTP, etc.) 1804 or ANY protocol in the IP packet payload. We 1805 specify the IP protocol number with an uint8 or 1806 ANY defining an enumerate with value 256 to 1807 indicate the protocol number."; 1808 reference 1809 "Section 4.4.1.1 in RFC 4301. 1810 IANA Registry - Protocol Numbers."; 1811 } 1813 grouping encap { 1814 description 1815 "This group of nodes allows to define the type of 1816 encapsulation in case NAT traversal is 1817 required and port information."; 1818 leaf espencap { 1819 type esp-encap; 1820 description 1821 "ESP in TCP, ESP in UDP or ESP in TLS."; 1822 } 1823 leaf sport { 1824 type inet:port-number; 1825 default 4500; 1826 description 1827 "Encapsulation source port."; 1828 } 1829 leaf dport { 1830 type inet:port-number; 1831 default 4500; 1832 description 1833 "Encapsulation destination port."; 1834 } 1836 leaf-list oaddr { 1837 type inet:ip-address; 1838 description 1839 "If required, this is the original address that 1840 was used before NAT was applied over the Packet. 1841 "; 1843 } 1844 reference 1845 "RFC 3947 and RFC 8229."; 1846 } 1848 grouping lifetime { 1849 description 1850 "Different lifetime values limited to an IPsec SA."; 1851 leaf time { 1852 type uint32; 1853 default 0; 1854 description 1855 "Time in seconds since the IPsec SA was added. 1856 For example, if this value is 180 seconds it 1857 means the IPsec SA expires in 180 seconds since 1858 it was added. The value 0 implies infinite."; 1859 } 1860 leaf bytes { 1861 type uint32; 1862 default 0; 1863 description 1864 "If the IPsec SA processes the number of bytes 1865 expressed in this leaf, the IPsec SA expires and 1866 should be rekeyed. The value 0 implies 1867 infinite."; 1868 } 1869 leaf packets { 1870 type uint32; 1871 default 0; 1872 description 1873 "If the IPsec SA processes the number of packets 1874 expressed in this leaf, the IPsec SA expires and 1875 should be rekeyed. The value 0 implies 1876 infinite."; 1877 } 1878 leaf idle { 1879 type uint32; 1880 default 0; 1881 description 1882 "When a NSF stores an IPsec SA, it 1883 consumes system resources. In an idle NSF this 1884 is a waste of resources. If the IPsec SA is idle 1885 during this number of seconds the IPsec SA 1886 should be removed. The value 0 implies 1887 infinite."; 1888 } 1889 reference 1890 "Section 4.4.2.1 in RFC 4301."; 1892 } 1894 grouping port-range { 1895 description 1896 "This grouping defines a port range, such as 1897 expressed in RFC 4301. For example: 1500 (Start 1898 Port Number)-1600 (End Port Number). A port range 1899 is used in the Traffic Selector."; 1901 leaf start { 1902 type inet:port-number; 1903 description 1904 "Start port number."; 1905 } 1906 leaf end { 1907 type inet:port-number; 1908 description 1909 "End port number."; 1910 } 1911 reference "Section 4.4.1.2 in RFC 4301."; 1912 } 1914 grouping tunnel-grouping { 1915 description 1916 "The parameters required to define the IP tunnel 1917 endpoints when IPsec SA requires tunnel mode. The 1918 tunnel is defined by two endpoints: the local IP 1919 address and the remote IP address."; 1921 leaf local { 1922 type inet:ip-address; 1923 mandatory true; 1924 description 1925 "Local IP address' tunnel endpoint."; 1926 } 1927 leaf remote { 1928 type inet:ip-address; 1929 mandatory true; 1930 description 1931 "Remote IP address' tunnel endpoint."; 1932 } 1933 leaf df-bit { 1934 type enumeration { 1935 enum clear { 1936 description 1937 "Disable the DF (Don't Fragment) bit 1938 from the outer header. This is the 1939 default value."; 1941 } 1942 enum set { 1943 description 1944 "Enable the DF bit in the outer header."; 1945 } 1946 enum copy { 1947 description 1948 "Copy the DF bit to the outer header."; 1949 } 1950 } 1951 default clear; 1952 description 1953 "Allow configuring the DF bit when encapsulating 1954 tunnel mode IPsec traffic. RFC 4301 describes 1955 three options to handle the DF bit during 1956 tunnel encapsulation: clear, set and copy from 1957 the inner IP header."; 1958 reference 1959 "Section 8.1 in RFC 4301."; 1960 } 1961 leaf bypass-dscp { 1962 type boolean; 1963 default true; 1964 description 1965 "If DSCP (Differentiated Services Code Point) 1966 values in the inner header have to be used to 1967 select one IPsec SA among several that match 1968 the traffic selectors for an outbound packet"; 1969 reference 1970 "Section 4.4.2.1. in RFC 4301."; 1971 } 1972 leaf dscp-mapping { 1973 type yang:hex-string; 1974 description 1975 "DSCP values allowed for packets carried over 1976 this IPsec SA."; 1977 reference 1978 "Section 4.4.2.1. in RFC 4301."; 1979 } 1980 leaf ecn { 1981 type boolean; 1982 default false; 1983 description 1984 "Explicit Congestion Notification (ECN). If true 1985 copy CE bits to inner header."; 1986 reference 1987 "Section 5.1.2 and Annex C in RFC 4301."; 1988 } 1990 } 1992 grouping selector-grouping { 1993 description 1994 "This grouping contains the definition of a Traffic 1995 Selector, which is used in the IPsec policies and 1996 IPsec SAs."; 1998 leaf local-subnet { 1999 type inet:ip-prefix; 2000 mandatory true; 2001 description 2002 "Local IP address subnet."; 2003 } 2004 leaf remote-subnet { 2005 type inet:ip-prefix; 2006 mandatory true; 2007 description 2008 "Remote IP address subnet."; 2009 } 2010 leaf inner-protocol { 2011 type ipsec-inner-protocol; 2012 default any; 2013 description 2014 "Inner Protocol that is going to be 2015 protected with IPsec."; 2016 } 2017 list local-ports { 2018 key "start end"; 2019 uses port-range; 2020 description 2021 "List of local ports. When the inner 2022 protocol is ICMP this 16 bit value represents 2023 code and type."; 2024 } 2025 list remote-ports { 2026 key "start end"; 2027 uses port-range; 2028 description 2029 "List of remote ports. When the upper layer 2030 protocol is ICMP this 16 bit value represents 2031 code and type."; 2032 } 2033 reference 2034 "Section 4.4.1.2 in RFC 4301."; 2035 } 2037 grouping ipsec-policy-grouping { 2038 description 2039 "Holds configuration information for an IPsec SPD 2040 entry."; 2042 leaf anti-replay-window { 2043 type uint64; 2044 default 32; 2045 description 2046 "A 64-bit counter used to determine whether an 2047 inbound ESP packet is a replay."; 2048 reference 2049 "Section 4.4.2.1 in RFC 4301."; 2050 } 2051 container traffic-selector { 2052 description 2053 "Packets are selected for 2054 processing actions based on the IP and inner 2055 protocol header information, selectors, 2056 matched against entries in the SPD."; 2057 uses selector-grouping; 2058 reference 2059 "Section 4.4.4.1 in RFC 4301."; 2060 } 2061 container processing-info { 2062 description 2063 "SPD processing. If the required processing 2064 action is protect, it contains the required 2065 information to process the packet."; 2066 leaf action { 2067 type ipsec-spd-action; 2068 default discard; 2069 description 2070 "If bypass or discard, container 2071 ipsec-sa-cfg is empty."; 2072 } 2073 container ipsec-sa-cfg { 2074 when "../action = 'protect'"; 2075 description 2076 "IPSec SA configuration included in the SPD 2077 entry."; 2078 leaf pfp-flag { 2079 type boolean; 2080 default false; 2081 description 2082 "Each selector has a Populate From 2083 Packet (PFP) flag. If asserted for a 2084 given selector X, the flag indicates 2085 that the IPSec SA to be created should 2086 take its value (local IP address, 2087 remote IP address, Next Layer 2088 Protocol, etc.) for X from the value 2089 in the packet. Otherwise, the IPsec SA 2090 should take its value(s) for X from 2091 the value(s) in the SPD entry."; 2092 } 2093 leaf ext-seq-num { 2094 type boolean; 2095 default false; 2096 description 2097 "True if this IPsec SA is using extended 2098 sequence numbers. True 64 bit counter, 2099 False 32 bit."; 2100 } 2101 leaf seq-overflow { 2102 type boolean; 2103 default false; 2104 description 2105 "The flag indicating whether 2106 overflow of the sequence number 2107 counter should prevent transmission 2108 of additional packets on the IPsec 2109 SA (false) and, therefore needs to 2110 be rekeyed, or whether rollover is 2111 permitted (true). If Authenticated 2112 Encryption with Associated Data 2113 (AEAD) is used this flag MUST BE 2114 false."; 2115 } 2116 leaf stateful-frag-check { 2117 type boolean; 2118 default false; 2119 description 2120 "Indicates whether (true) or not (false) 2121 stateful fragment checking applies to 2122 the IPsec SA to be created."; 2123 } 2124 leaf mode { 2125 type ipsec-mode; 2126 default transport; 2127 description 2128 "IPsec SA has to be processed in 2129 transport or tunnel mode."; 2130 } 2131 leaf protocol-parameters { 2132 type ipsec-protocol-parameters; 2133 default esp; 2134 description 2135 "Security protocol of the IPsec SA: 2136 Only ESP is supported but it could be 2137 extended in the future."; 2138 } 2139 container esp-algorithms { 2140 when "../protocol-parameters = 'esp'"; 2141 description 2142 "Configuration of Encapsulating 2143 Security Payload (ESP) parameters and 2144 algorithms."; 2145 leaf-list integrity { 2146 type integrity-algorithm-type; 2147 default 0; 2148 ordered-by user; 2149 description 2150 "Configuration of ESP authentication 2151 based on the specified integrity 2152 algorithm. With AEAD algorithms, 2153 the integrity node is not 2154 used."; 2155 reference 2156 "Section 3.2 in RFC 4303."; 2157 } 2158 leaf-list encryption { 2159 type encryption-algorithm-type; 2160 default 20; 2161 ordered-by user; 2162 description 2163 "Configuration of ESP encryption 2164 algorithms. The default value is 2165 20 (ENCR_AES_GCM_16)."; 2166 reference 2167 "Section 3.2 in RFC 4303."; 2168 } 2169 leaf tfc-pad { 2170 type boolean; 2171 default false; 2172 description 2173 "If Traffic Flow Confidentiality 2174 (TFC) padding for ESP encryption 2175 can be used (true) or not (false)"; 2176 reference 2177 "Section 2.7 in RFC 4303."; 2178 } 2179 reference 2180 "RFC 4303."; 2181 } 2182 container tunnel { 2183 when "../mode = 'tunnel'"; 2184 uses tunnel-grouping; 2185 description 2186 "IPsec tunnel endpoints definition."; 2187 } 2188 } 2189 reference 2190 "Section 4.4.1.2 in RFC 4301."; 2191 } 2192 container spd-mark { 2193 description 2194 "The Mark to set for the IPsec SA of this 2195 connection. This option is only available 2196 on linux NETKEY/XFRM kernels. It can be 2197 used with iptables to create custom 2198 iptables rules using CONNMARK. It can also 2199 be used with Virtual Tunnel Interfaces 2200 (VTI) to direct marked traffic to 2201 specific vtiXX devices."; 2202 leaf mark { 2203 type uint32; 2204 default 0; 2205 description 2206 "Mark used to match XFRM policies and 2207 states."; 2208 } 2209 leaf mask { 2210 type yang:hex-string; 2211 default 00:00:00:00; 2212 description 2213 "Mask used to match XFRM policies and 2214 states."; 2215 } 2216 } 2217 } 2218 } 2220 2222 Appendix B. Appendix B: YANG model for IKE case 2224 file "ietf-ipsec-ike@2019-07-07.yang" 2225 module ietf-ipsec-ike { 2226 yang-version 1.1; 2227 namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec-ike"; 2228 prefix "ike"; 2230 import ietf-inet-types { prefix inet; } 2231 import ietf-yang-types { prefix yang; } 2233 import ietf-crypto-types { 2234 prefix ct; 2235 reference 2236 "draft-ietf-netconf-crypto-types-09: 2237 Common YANG Data Types for Cryptography."; 2238 } 2240 import ietf-ipsec-common { 2241 prefix ic; 2242 reference 2243 "RFC XXXX: module ietf-ipsec-common, revision 2244 2019-07-07."; 2245 } 2247 import ietf-netconf-acm { 2248 prefix nacm; 2249 reference 2250 "RFC 8341: Network Configuration Access Control 2251 Model."; 2252 } 2254 organization "IETF I2NSF Working Group"; 2256 contact 2257 "WG Web: 2258 WG List: 2260 Author: Rafael Marin-Lopez 2261 2263 Author: Gabriel Lopez-Millan 2264 2266 Author: Fernando Pereniguez-Garcia 2267 2268 "; 2270 description 2272 "This module contains IPSec IKE case model for the SDN-based 2273 IPsec flow protection service. An NSF will implement this 2274 module. 2276 Copyright (c) 2019 IETF Trust and the persons identified as 2277 authors of the code. All rights reserved. 2279 Redistribution and use in source and binary forms, with or 2280 without modification, is permitted pursuant to, and subject 2281 to the license terms contained in, the Simplified BSD License 2282 set forth in Section 4.c of the IETF Trust's Legal Provisions 2283 Relating to IETF Documents 2284 (http://trustee.ietf.org/license-info). 2286 This version of this YANG module is part of RFC XXXX; see 2287 the RFC itself for full legal notices. 2289 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 2290 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 2291 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this 2292 document are to be interpreted as described in BCP 14 2293 (RFC 2119) (RFC 8174) when, and only when, they appear 2294 in all capitals, as shown here."; 2296 revision "2019-07-07" { 2297 description "Revision 5"; 2298 reference 2299 "RFC XXXX: YANG model for IKE case."; 2300 } 2302 typedef ike-spi { 2303 type uint64 { range "0..max"; } 2304 description 2305 "Security Parameter Index (SPI)'s IKE SA."; 2306 reference 2307 "Section 2.6 in RFC 7296."; 2308 } 2310 typedef autostartup-type { 2311 type enumeration { 2312 enum add { 2313 description 2314 "IKE/IPsec configuration is only loaded into 2315 IKE implementation but IKE/IPsec SA is not 2316 started."; 2317 } 2318 enum on-demand { 2319 description 2320 "IKE/IPsec configuration is loaded 2321 into IKE implementation. The IPsec policies 2322 are transferred to the NSF's kernel but the 2323 IPsec SAs are not established immediately. 2324 The IKE implementation will negotiate the 2325 IPsec SAs when the NSF's kernel requests it 2326 (i.e. through an ACQUIRE notification)."; 2327 } 2328 enum start { 2329 description "IKE/IPsec configuration is loaded 2330 and transferred to the NSF's kernel, and the 2331 IKEv2 based IPsec SAs are established 2332 immediately without waiting any packet."; 2333 } 2334 } 2335 description 2336 "Different policies to set IPsec SA configuration 2337 into NSF's kernel when IKEv2 implementation has 2338 started."; 2339 } 2341 typedef pfs-group { 2342 type uint16; 2343 description 2344 "DH groups for IKE and IPsec SA rekey."; 2345 reference 2346 "Section 3.3.2 in RFC 7296. Transform Type 4 - 2347 Diffie-Hellman Group Transform IDs in IANA Registry 2348 - Internet Key Exchange Version 2 (IKEv2) 2349 Parameters."; 2350 } 2352 typedef auth-protocol-type { 2353 type enumeration { 2354 enum ikev2 { 2355 value 2; 2356 description 2357 "IKEv2 authentication protocol. It is the 2358 only defined right now. An enum is used for 2359 further extensibility."; 2360 } 2361 } 2362 description 2363 "IKE authentication protocol version specified in the 2364 Peer Authorization Database (PAD). It is defined as 2365 enumerate to allow new IKE versions in the 2366 future."; 2367 reference 2368 "RFC 7296."; 2369 } 2371 typedef auth-method-type { 2372 type enumeration { 2373 enum pre-shared { 2374 description 2375 "Select pre-shared key as the 2376 authentication method."; 2377 reference 2378 "RFC 7296."; 2379 } 2380 enum eap { 2381 description 2382 "Select EAP as the authentication method."; 2383 reference 2384 "RFC 7296."; 2385 } 2386 enum digital-signature { 2387 description 2388 "Select digital signature method."; 2389 reference 2390 "RFC 7296 and RFC 7427."; 2391 } 2392 enum null { 2393 description 2394 "Null authentication."; 2395 reference 2396 "RFC 7619."; 2397 } 2399 } 2400 description 2401 "Peer authentication method specified in the Peer 2402 Authorization Database (PAD)."; 2403 } 2405 container ipsec-ike { 2406 description 2407 "IKE configuration for a NSF. It includes PAD 2408 parameters, IKE connections information and state 2409 data."; 2411 container pad { 2412 description 2413 "Configuration of Peer Authorization Database 2414 (PAD). The PAD contains information about IKE 2415 peer (local and remote). Therefore, the Security 2416 Controller also stores authentication 2417 information for this NSF and can include 2418 several entries for the local NSF not only 2419 remote peers. Storing local and remote 2420 information makes possible to specify that this 2421 NSF with identity A will use some particular 2422 authentication with remote NSF with identity B 2423 and what are the authentication mechanisms 2424 allowed to B."; 2425 list pad-entry { 2426 key "name"; 2427 ordered-by user; 2428 description 2429 "Peer Authorization Database (PAD) entry. It 2430 is a list of PAD entries ordered by the 2431 Security Controller."; 2432 leaf name { 2433 type string; 2434 description 2435 "PAD unique name to identify this 2436 entry."; 2437 } 2438 choice identity { 2439 mandatory true; 2440 description 2441 "A particular IKE peer will be 2442 identified by one of these identities. 2443 This peer can be a remote peer or local 2444 peer (this NSF)."; 2445 reference 2446 "Section 4.4.3.1 in RFC 4301."; 2447 case ipv4-address{ 2448 leaf ipv4-address { 2449 type inet:ipv4-address; 2450 description 2451 "Specifies the identity as a 2452 single four (4) octet IPv4 2453 addressExample: 10.10.10.10."; 2454 } 2455 } 2456 case ipv6-address{ 2457 leaf ipv6-address { 2458 type inet:ipv6-address; 2459 description 2460 "Specifies the identity as a 2461 single sixteen (16) octet IPv6 2462 address. An example is 2463 2001:DB8:0:0:8:800:200C:417A."; 2464 } 2465 } 2466 case fqdn-string { 2467 leaf fqdn-string { 2468 type inet:domain-name; 2469 description 2470 "Specifies the identity as a 2471 Fully-QualifiedDomain Name 2472 (FQDN) string. An example is: 2473 example.com. The string MUST 2474 not contain any terminators 2475 (e.g., NULL, CR, etc.)."; 2476 } 2477 } 2478 case rfc822-address-string { 2479 leaf rfc822-address-string { 2480 type string; 2481 description 2482 "Specifies the identity as a 2483 fully-qualified RFC822 email 2484 address string. An example is, 2485 jsmith@example.com. The string 2486 MUST not contain any 2487 terminators e.g., NULL, CR, 2488 etc.)."; 2489 reference 2490 "RFC 822."; 2491 } 2492 } 2493 case dnx509 { 2494 leaf dnx509 { 2495 type string; 2496 description 2497 "Specifies the identity as a 2498 ASN.1 X.500 Distinguished 2499 Name. An example is 2500 C=US,O=Example 2501 Organisation,CN=John Smith."; 2502 reference 2503 "RFC 2247."; 2504 } 2505 } 2506 case gnx509 { 2507 leaf gnx509 { 2508 type string; 2509 description 2510 "ASN.1 X.509 GeneralName. RFC 2511 3280."; 2512 } 2513 } 2514 case id-key { 2515 leaf id-key { 2516 type string; 2517 description 2518 "Opaque octet stream that may be 2519 used to pass vendor-specific 2520 information for proprietary 2521 types of identification."; 2522 reference 2523 "Section 3.5 in RFC 7296."; 2524 } 2525 } 2526 case id-null { 2527 leaf id-null { 2528 type empty; 2529 description 2530 "ID_NULL identification used 2531 when IKE identification payload 2532 is not used." ; 2533 reference 2534 "RFC 7619."; 2535 } 2536 } 2537 } 2538 leaf auth-protocol { 2539 type auth-protocol-type; 2540 default ikev2; 2541 description 2542 "Only IKEv2 is supported right now but 2543 other authentication protocols may be 2544 supported in the future."; 2545 } 2546 container peer-authentication { 2547 description 2548 "This container allows the Security 2549 Controller to configure the 2550 authentication method (pre-shared key, 2551 eap, digitial-signature, null) that 2552 will use a particular peer and the 2553 credentials, which will depend on the 2554 selected authentication method."; 2555 leaf auth-method { 2556 type auth-method-type; 2557 default pre-shared; 2558 description 2559 "Type of authentication method 2560 (pre-shared, eap, digital signature, 2561 null)."; 2562 reference 2563 "Section 2.15 in RFC 7296."; 2564 } 2565 container eap-method { 2566 when "../auth-method = 'eap'"; 2567 leaf eap-type { 2568 type uint8; 2569 mandatory true; 2570 description 2571 "EAP method type. This 2572 information provides the 2573 particular EAP method to be 2574 used. Depending on the EAP 2575 method, pre-shared keys or 2576 certificates may be used."; 2577 } 2578 description 2579 "EAP method description used when 2580 authentication method is 'eap'."; 2581 reference 2582 "Section 2.16 in RFC 7296."; 2583 } 2584 container pre-shared { 2585 when 2586 "../auth-method[.='pre-shared' or 2587 .='eap']"; 2588 leaf secret { 2589 nacm:default-deny-all; 2590 type yang:hex-string; 2591 description 2592 "Pre-shared secret value. The 2593 NSF has to prevent read access 2594 to this value for security 2595 reasons."; 2596 } 2597 description 2598 "Shared secret value for PSK or 2599 EAP method authentication based on 2600 PSK."; 2601 } 2602 container digital-signature { 2603 when 2604 "../auth-method[.='digital-signature' 2605 or .='eap']"; 2606 leaf ds-algorithm { 2607 type uint8; 2608 description 2609 "The digital signature 2610 algorithm is specified with a 2611 value extracted from the IANA 2612 Registry. Depending on the 2613 algorithm, the following leafs 2614 must contain information. For 2615 example if digital signature 2616 involves a certificate then leaf 2617 'cert-data' and 'private-key' 2618 will contain this information."; 2619 reference 2620 "IKEv2 Authentication Method - 2621 IANA Registry - Internet Key 2622 Exchange Version 2 (IKEv2) 2623 Parameters."; 2624 } 2626 choice public-key { 2627 mandatory true; 2628 leaf raw-public-key { 2629 type binary; 2630 description 2631 "A binary that contains the 2632 value of the public key. The 2633 interpretation of the content 2634 is defined by the digital 2635 signature algorithm. For 2636 example, an RSA key is 2637 represented as RSAPublicKey as 2638 defined in RFC 8017, and an 2639 Elliptic Curve Cryptography 2640 (ECC) key is represented 2641 using the 'publicKey' 2642 described in RFC 5915."; 2643 reference 2644 "RFC XXX: Common YANG Data 2645 Types for Cryptography."; 2646 } 2647 leaf cert-data { 2648 type ct:x509; 2649 description 2650 "X.509 certificate data - 2651 PEM4."; 2652 reference 2653 "RFC XXX: Common YANG Data 2654 Types for Cryptography."; 2655 } 2656 description 2657 "If the Security Controller 2658 knows that the NSF 2659 already owns a private key 2660 associated to this public key 2661 (the NSF generated the pair 2662 public key/private key out of 2663 band), it will only configure 2664 one of the leaf of this 2665 choice. The NSF, based on 2666 the public key value can know 2667 the private key to be used."; 2668 } 2669 leaf private-key { 2670 nacm:default-deny-all; 2671 type binary; 2672 description 2673 "A binary that contains the 2674 value of the private key. The 2675 interpretation of the content 2676 is defined by the digital 2677 signature algorithm. For 2678 example, an RSA key is 2679 represented as RSAPrivateKey as 2680 defined in RFC 8017, and an 2681 Elliptic Curve Cryptography 2682 (ECC) key is represented as 2683 ECPrivateKey as defined in RFC 2684 5915."; 2685 reference 2686 "RFC XXX: Common YANG Data 2687 Types for Cryptography."; 2688 } 2689 leaf-list ca-data { 2690 type ct:x509; 2691 description 2692 "List of trusted Certification 2693 Authorities (CA) certificates 2694 encoded using ASN.1 2695 distinguished encoding rules 2696 (DER)."; 2697 reference 2698 "RFC XXX: Common YANG Data 2699 Types for Cryptography."; 2700 } 2701 leaf crl-data { 2702 type ct:crl; 2703 description 2704 "A CertificateList structure, as 2705 specified in RFC 5280, 2706 encoded using ASN.1 2707 distinguished encoding rules 2708 (DER),as specified in ITU-T 2709 X.690."; 2710 reference 2711 "RFC XXX: Common YANG Data Types 2712 for Cryptography."; 2713 } 2714 leaf crl-uri { 2715 type inet:uri; 2716 description 2717 "X.509 CRL certificate URI."; 2718 } 2719 leaf oscp-uri { 2720 type inet:uri; 2721 description 2722 "OCSP URI."; 2723 } 2724 description 2725 "Digital Signature container."; 2727 } /*container digital-signature*/ 2728 } /*container peer-authentication*/ 2729 } 2730 } 2732 list conn-entry { 2733 key "name"; 2734 description 2735 "IKE peer connection information. This list 2736 contains the IKE connection for this peer 2737 with other peers. This will be translated in 2738 real time by IKE Security Associations 2739 established with these nodes."; 2740 leaf name { 2741 type string; 2742 mandatory true; 2743 description 2744 "Identifier for this connection 2745 entry."; 2746 } 2747 leaf autostartup { 2748 type autostartup-type; 2749 default add; 2750 description 2751 "By-default: Only add configuration 2752 without starting the security 2753 association."; 2754 } 2755 leaf initial-contact { 2756 type boolean; 2757 default false; 2758 description 2759 "The goal of this value is to deactivate the 2760 usage of INITIAL_CONTACT notification 2761 (true). If this flag remains to false it 2762 means the usage of the INITIAL_CONTACT 2763 notification will depend on the IKEv2 2764 implementation."; 2765 } 2766 leaf version { 2767 type auth-protocol-type; 2768 default ikev2; 2769 description 2770 "IKE version. Only version 2 is supported 2771 so far."; 2772 } 2773 leaf fragmentation { 2774 type boolean; 2775 default false; 2776 description 2777 "Whether or not to enable IKE 2778 fragmentation as per RFC 7383 (true or 2779 false)."; 2780 reference 2781 "RFC 7383."; 2782 } 2783 container ike-sa-lifetime-soft { 2784 description 2785 "IKE SA lifetime soft. Two lifetime values 2786 can be configured: either rekey time of the 2787 IKE SA or reauth time of the IKE SA. When 2788 the rekey lifetime expires a rekey of the 2789 IKE SA starts. When reauth lifetime 2790 expires a IKE SA reauthentication starts."; 2791 leaf rekey-time { 2792 type uint32; 2793 default 0; 2794 description 2795 "Time in seconds between each IKE SA 2796 rekey.The value 0 means infinite."; 2797 } 2798 leaf reauth-time { 2799 type uint32; 2800 default 0; 2801 description 2802 "Time in seconds between each IKE SA 2803 reauthentication. The value 0 means 2804 infinite."; 2805 } 2806 reference 2807 "Section 2.8 in RFC 7296."; 2808 } 2809 container ike-sa-lifetime-hard { 2810 description 2811 "Hard IKE SA lifetime. When this 2812 time is reached the IKE SA is removed."; 2813 leaf over-time { 2814 type uint32; 2815 default 0; 2816 description 2817 "Time in seconds before the IKE SA is 2818 removed. The value 0 means infinite."; 2819 } 2820 reference 2821 "RFC 7296."; 2822 } 2823 leaf-list authalg { 2824 type ic:integrity-algorithm-type; 2825 default 12; 2826 ordered-by user; 2827 description 2828 "Authentication algorithm for establishing 2829 the IKE SA. This list is ordered following 2830 from the higher priority to lower priority. 2831 First node of the list will be the algorithm 2832 with higher priority. If this list is empty 2833 the default integrity algorithm value assumed 2834 is NONE."; 2835 } 2836 leaf-list encalg { 2837 type ic:encryption-algorithm-type; 2838 default 12; 2839 ordered-by user; 2840 description 2841 "Encryption or AEAD algorithm for the IKE 2842 SAs. This list is ordered following 2843 from the higher priority to lower priority. 2844 First node of the list will be the algorithm 2845 with higher priority. If this list is empty 2846 the default encryption value assumed is 2847 NULL."; 2848 } 2849 leaf dh-group { 2850 type pfs-group; 2851 default 14; 2852 description 2853 "Group number for Diffie-Hellman 2854 Exponentiation used during IKE_SA_INIT 2855 for the IKE SA key exchange."; 2856 } 2857 leaf half-open-ike-sa-timer { 2858 type uint32; 2859 description 2860 "Set the half-open IKE SA timeout 2861 duration."; 2862 reference 2863 "Section 2 in RFC 7296."; 2864 } 2866 leaf half-open-ike-sa-cookie-threshold { 2867 type uint32; 2868 description 2869 "Number of half-open IKE SAs that activate 2870 the cookie mechanism." ; 2871 reference 2872 "Section 2.6 in RFC 7296."; 2873 } 2874 container local { 2875 leaf local-pad-entry-name { 2876 type string; 2877 description 2878 "Local peer authentication information. 2879 This node points to a specific entry in 2880 the PAD where the authorization 2881 information about this particular local 2882 peer is stored. It MUST match a 2883 pad-entry-name."; 2884 } 2885 description 2886 "Local peer authentication information."; 2887 } 2888 container remote { 2889 leaf remote-pad-entry-name { 2890 type string; 2891 description 2892 "Remote peer authentication information. 2893 This node points to a specific entry in 2894 the PAD where the authorization 2895 information about this particular 2896 remote peer is stored. It MUST match a 2897 pad-entry-name."; 2898 } 2899 description 2900 "Remote peer authentication information."; 2901 } 2902 container encapsulation-type 2903 { 2904 uses ic:encap; 2905 description 2906 "This container carries configuration 2907 information about the source and destination 2908 ports of encapsulation that IKE should use 2909 and the type of encapsulation that 2910 should use when NAT traversal is required. 2911 However, this is just a best effort since 2912 the IKE implementation may need to use a 2913 different encapsulation as 2914 described in RFC 8229."; 2915 reference 2916 "RFC 8229."; 2917 } 2918 container spd { 2919 description 2920 "Configuration of the Security Policy 2921 Database (SPD). This main information is 2922 placed in the grouping 2923 ipsec-policy-grouping."; 2924 list spd-entry { 2925 key "name"; 2926 ordered-by user; 2927 leaf name { 2928 type string; 2929 mandatory true; 2930 description 2931 "SPD entry unique name to identify 2932 the IPsec policy."; 2933 } 2934 container ipsec-policy-config { 2935 description 2936 "This container carries the 2937 configuration of a IPsec policy."; 2938 uses ic:ipsec-policy-grouping; 2939 } 2940 description 2941 "List of entries which will constitute 2942 the representation of the SPD. Since we 2943 have IKE in this case, it is only 2944 required to send a IPsec policy from 2945 this NSF where 'local' is this NSF and 2946 'remote' the other NSF. The IKE 2947 implementation will install IPsec 2948 policies in the NSF's kernel in both 2949 directions (inbound and outbound) and 2950 their corresponding IPsec SAs based on 2951 the information in this SPD entry."; 2952 } 2953 reference 2954 "Section 2.9 in RFC 7296."; 2955 } 2956 container child-sa-info { 2957 leaf-list pfs-groups { 2958 type pfs-group; 2959 default 0; 2960 ordered-by user; 2961 description 2962 "If non-zero, it is required perfect 2963 forward secrecy when requesting new 2964 IPsec SA. The non-zero value is 2965 the required group number. This list is 2966 ordered following from the higher 2967 priority to lower priority. First node 2968 of the list will be the algorithm 2969 with higher priority."; 2970 } 2971 container child-sa-lifetime-soft { 2972 description 2973 "Soft IPsec SA lifetime soft. 2974 After the lifetime the action is 2975 defined in this container 2976 in the leaf action."; 2977 uses ic:lifetime; 2978 leaf action { 2979 type ic:lifetime-action; 2980 default replace; 2981 description 2982 "When the lifetime of an IPsec SA 2983 expires an action needs to be 2984 performed over the IPsec SA that 2985 reached the lifetime. There are 2986 three possible options: 2987 terminate-clear, terminate-hold and 2988 replace."; 2989 reference 2990 "Section 4.5 in RFC 4301 and Section 2.8 2991 in RFC 7296."; 2992 } 2993 } 2994 container child-sa-lifetime-hard { 2995 description 2996 "IPsec SA lifetime hard. The action will 2997 be to terminate the IPsec SA."; 2998 uses ic:lifetime; 2999 reference 3000 "Section 2.8 in RFC 7296."; 3001 } 3002 description 3003 "Specific information for IPsec SAs 3004 SAs. It includes PFS group and IPsec SAs 3005 rekey lifetimes."; 3006 } 3007 container state { 3008 config false; 3010 leaf initiator { 3011 type boolean; 3012 description 3013 "It is acting as initiator for this 3014 connection."; 3015 } 3016 leaf initiator-ikesa-spi { 3017 type ike-spi; 3018 description 3019 "Initiator's IKE SA SPI."; 3020 } 3021 leaf responder-ikesa-spi { 3022 type ike-spi; 3023 description 3024 "Responder's IKE SA SPI."; 3025 } 3026 leaf nat-local { 3027 type boolean; 3028 description 3029 "True, if local endpoint is behind a 3030 NAT."; 3031 } 3032 leaf nat-remote { 3033 type boolean; 3034 description 3035 "True, if remote endpoint is behind 3036 a NAT."; 3037 } 3038 container encapsulation-type 3039 { 3040 uses ic:encap; 3041 description 3042 "This container provides information 3043 about the source and destination 3044 ports of encapsulation that IKE is 3045 using, and the type of encapsulation 3046 when NAT traversal is required."; 3047 reference 3048 "RFC 8229."; 3049 } 3050 leaf established { 3051 type uint64; 3052 description 3053 "Seconds since this IKE SA has been 3054 established."; 3055 } 3056 leaf current-rekey-time { 3057 type uint64; 3058 description 3059 "Seconds before IKE SA must be rekeyed."; 3060 } 3061 leaf current-reauth-time { 3062 type uint64; 3063 description 3064 "Seconds before IKE SA must be 3065 re-authenticated."; 3066 } 3067 description 3068 "IKE state data for a particular 3069 connection."; 3070 } /* ike-sa-state */ 3071 } /* ike-conn-entries */ 3073 container number-ike-sas { 3074 config false; 3075 leaf total { 3076 type uint64; 3077 description 3078 "Total number of active IKE SAs."; 3079 } 3080 leaf half-open { 3081 type uint64; 3082 description 3083 "Number of half-open active IKE SAs."; 3084 } 3085 leaf half-open-cookies { 3086 type uint64; 3087 description 3088 "Number of half open active IKE SAs with 3089 cookie activated."; 3090 } 3091 description 3092 "General information about the IKE SAs. In 3093 particular, it provides the current number of 3094 IKE SAs."; 3095 } 3096 } /* container ipsec-ike */ 3097 } 3099 3101 Appendix C. Appendix C: YANG model for IKE-less case 3103 file "ietf-ipsec-ikeless@2019-07-07.yang" 3105 module ietf-ipsec-ikeless { 3107 yang-version 1.1; 3108 namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless"; 3110 prefix "ikeless"; 3112 import ietf-yang-types { prefix yang; } 3114 import ietf-ipsec-common { 3115 prefix ic; 3116 reference 3117 "Common Data model for SDN-based IPSec 3118 configuration."; 3119 } 3121 import ietf-netconf-acm { 3122 prefix nacm; 3123 reference 3124 "RFC 8341: Network Configuration Access Control 3125 Model."; 3126 } 3127 organization "IETF I2NSF Working Group"; 3129 contact 3130 "WG Web: 3131 WG List: 3133 Author: Rafael Marin-Lopez 3134 3136 Author: Gabriel Lopez-Millan 3137 3139 Author: Fernando Pereniguez-Garcia 3140 3141 "; 3143 description 3144 "Data model for IKE-less case in the SDN-base IPsec flow 3145 protection service. 3147 Copyright (c) 2019 IETF Trust and the persons 3148 identified as authors of the code. All rights reserved. 3149 Redistribution and use in source and binary forms, with 3150 or without modification, is permitted pursuant to, and 3151 subject to the license terms contained in, the 3152 Simplified BSD License set forth in Section 4.c of the 3153 IETF Trust's Legal Provisions Relating to IETF Documents 3154 (https://trustee.ietf.org/license-info). 3156 This version of this YANG module is part of RFC XXXX;; 3157 see the RFC itself for full legal notices. 3159 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 3160 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 3161 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this 3162 document are to be interpreted as described in BCP 14 3163 (RFC 2119) (RFC 8174) when, and only when, they appear 3164 in all capitals, as shown here."; 3166 revision "2019-07-07" { 3167 description "Revision 05"; 3168 reference "RFC XXXX: YANG model for IKE case."; 3169 } 3171 container ipsec-ikeless { 3172 description 3173 "Container for configuration of the IKE-less 3174 case. The container contains two additional 3175 containers: 'spd' and 'sad'. The first allows the 3176 Security Controller to configure IPsec policies in 3177 the Security Policy Database SPD, and the second 3178 allows to configure IPsec Security Associations 3179 (IPsec SAs) in the Security Association Database 3180 (SAD)."; 3181 reference "RFC 4301."; 3182 container spd { 3183 description 3184 "Configuration of the Security Policy Database 3185 (SPD.)"; 3186 reference "Section 4.4.1.2 in RFC 4301."; 3188 list spd-entry { 3189 key "name"; 3190 ordered-by user; 3191 leaf name { 3192 type string; 3193 mandatory true; 3194 description 3195 "SPD entry unique name to identify this 3196 entry."; 3197 } 3198 leaf direction { 3199 type ic:ipsec-traffic-direction; 3200 description 3201 "Inbound traffic or outbound 3202 traffic. In the IKE-less case the 3203 Security Controller needs to 3204 specify the policy direction to be 3205 applied in the NSF. In the IKE case 3206 this direction does not need to be 3207 specified since IKE 3208 will determine the direction that 3209 IPsec policy will require."; 3210 } 3211 leaf reqid { 3212 type uint64; 3213 default 0; 3214 description 3215 "This value allows to link this 3216 IPsec policy with IPsec SAs with the 3217 same reqid. It is only required in 3218 the IKE-less model since, in the IKE 3219 case this link is handled internally 3220 by IKE."; 3222 } 3224 container ipsec-policy-config { 3225 description 3226 "This container carries the 3227 configuration of a IPsec policy."; 3228 uses ic:ipsec-policy-grouping; 3229 } 3230 description 3231 "The SPD is represented as a list of SPD 3232 entries, where each SPD entry represents an 3233 IPsec policy."; 3234 } /*list spd-entry*/ 3235 } /*container spd*/ 3237 container sad { 3238 description 3239 "Configuration of the IPSec Security Association 3240 Database (SAD)"; 3241 reference "Section 4.4.2.1 in RFC 4301."; 3242 list sad-entry { 3243 key "name"; 3244 ordered-by user; 3245 leaf name { 3246 type string; 3247 description 3248 "SAD entry unique name to identify this 3249 entry."; 3250 } 3251 leaf reqid { 3252 type uint64; 3253 default 0; 3254 description 3255 "This value allows to link this 3256 IPsec SA with an IPsec policy with 3257 the same reqid."; 3258 } 3260 container ipsec-sa-config { 3261 description 3262 "This container allows configuring 3263 details of an IPsec SA."; 3264 leaf spi { 3265 type uint32 { range "0..max"; } 3266 mandatory true; 3267 description 3268 "Security Parameter Index (SPI)'s 3269 IPsec SA."; 3271 } 3272 leaf ext-seq-num { 3273 type boolean; 3274 default true; 3275 description 3276 "True if this IPsec SA is using 3277 extended sequence numbers. True 64 3278 bit counter, FALSE 32 bit."; 3279 } 3280 leaf seq-number-counter { 3281 type uint64; 3282 default 0; 3283 description 3284 "A 64-bit counter when this IPsec 3285 SA is using Extended Sequence 3286 Number or 32-bit counter when it 3287 is not. It used to generate the 3288 initial Sequence Number field 3289 in ESP headers."; 3290 } 3291 leaf seq-overflow { 3292 type boolean; 3293 default false; 3294 description 3295 "The flag indicating whether 3296 overflow of the sequence number 3297 counter should prevent transmission 3298 of additional packets on the IPsec 3299 SA (false) and, therefore needs to 3300 be rekeyed, or whether rollover is 3301 permitted (true). If Authenticated 3302 Encryption with Associated Data 3303 (AEAD) is used this flag MUST BE 3304 false."; 3305 } 3306 leaf anti-replay-window { 3307 type uint32; 3308 default 32; 3309 description 3310 "A 32-bit counter and a bit-map (or 3311 equivalent) used to determine 3312 whether an inbound ESP packet is a 3313 replay. If set to 0 no anti-replay 3314 mechanism is performed."; 3315 } 3316 container traffic-selector { 3317 uses ic:selector-grouping; 3318 description 3319 "The IPsec SA traffic selector."; 3320 } 3321 leaf protocol-parameters { 3322 type ic:ipsec-protocol-parameters; 3323 default esp; 3324 description 3325 "Security protocol of IPsec SA: Only 3326 ESP so far."; 3327 } 3328 leaf mode { 3329 type ic:ipsec-mode; 3330 description 3331 "Tunnel or transport mode."; 3332 } 3333 container esp-sa { 3334 when "../protocol-parameters = 3335 'esp'"; 3336 description 3337 "In case the IPsec SA is 3338 Encapsulation Security Payload 3339 (ESP), it is required to specify 3340 encryption and integrity 3341 algorithms, and key material."; 3343 container encryption { 3344 description 3345 "Configuration of encryption or 3346 AEAD algorithm for IPSec 3347 Encapsulation Security Payload 3348 (ESP)."; 3350 leaf encryption-algorithm { 3351 type ic:encryption-algorithm-type; 3352 description 3353 "Configuration of ESP 3354 encryption. With AEAD 3355 algorithms, the integrity 3356 node is not used."; 3357 } 3359 leaf key { 3360 nacm:default-deny-all; 3361 type yang:hex-string; 3362 description 3363 "ESP encryption key value."; 3364 } 3365 leaf iv { 3366 nacm:default-deny-all; 3367 type yang:hex-string; 3368 description 3369 "ESP encryption IV value."; 3370 } 3371 } 3372 container integrity { 3373 description 3374 "Configuration of integrity for 3375 IPSec Encapsulation Security 3376 Payload (ESP). This container 3377 allows to configure integrity 3378 algorithm when no AEAD 3379 algorithms are used, and 3380 integrity is required."; 3381 leaf integrity-algorithm { 3382 type ic:integrity-algorithm-type; 3383 description 3384 "Message Authentication Code 3385 (MAC) algorithm to provide 3386 integrity in ESP."; 3387 } 3388 leaf key { 3389 nacm:default-deny-all; 3390 type yang:hex-string; 3391 description 3392 "ESP integrity key value."; 3393 } 3394 } 3395 } /*container esp-sa*/ 3397 container sa-lifetime-hard { 3398 description 3399 "IPsec SA hard lifetime. The action 3400 associated is terminate and 3401 hold."; 3402 uses ic:lifetime; 3403 } 3404 container sa-lifetime-soft { 3405 description 3406 "IPSec SA soft lifetime."; 3407 uses ic:lifetime; 3408 leaf action { 3409 type ic:lifetime-action; 3410 description 3411 "Action lifetime: 3412 terminate-clear, 3413 terminate-hold or replace."; 3414 } 3416 } 3417 container tunnel { 3418 when "../mode = 'tunnel'"; 3419 uses ic:tunnel-grouping; 3420 description 3421 "Endpoints of the IPsec tunnel."; 3422 } 3423 container encapsulation-type 3424 { 3425 uses ic:encap; 3426 description 3427 "This container carries 3428 configuration information about 3429 the source and destination ports 3430 which will be used for ESP 3431 encapsulation that ESP packets the 3432 type of encapsulation when NAT 3433 traversal is in place."; 3434 } 3435 } /*ipsec-sa-config*/ 3437 container ipsec-sa-state { 3438 config false; 3439 description 3440 "Container describing IPsec SA state 3441 data."; 3442 container sa-lifetime-current { 3443 uses ic:lifetime; 3444 description 3445 "SAD lifetime current."; 3446 } 3447 container replay-stats { 3448 description 3449 "State data about the anti-replay 3450 window."; 3451 leaf replay-window { 3452 type uint64; 3453 description 3454 "Current state of the replay 3455 window."; 3456 } 3457 leaf packet-dropped { 3458 type uint64; 3459 description 3460 "Packets detected out of the 3461 replay window and dropped 3462 because they are replay 3463 packets."; 3465 } 3466 leaf failed { 3467 type uint32; 3468 description 3469 "Number of packets detected out 3470 of the replay window."; 3471 } 3472 leaf seq-number-counter { 3473 type uint64; 3474 description 3475 "A 64-bit counter when this 3476 IPsec SA is using Extended 3477 Sequence Number or 32-bit 3478 counter when it is not. 3479 Current value of sequence 3480 number."; 3481 } 3482 } /* container replay-stats*/ 3483 } /*ipsec-sa-state*/ 3485 description 3486 "List of SAD entries that conforms the SAD."; 3487 } /*list sad-entry*/ 3488 } /*container sad*/ 3489 }/*container ipsec-ikeless*/ 3491 /* Notifications */ 3492 notification sadb-acquire { 3493 description 3494 "An IPsec SA is required. The traffic-selector 3495 container contains information about the IP packet 3496 that triggers the acquire notification."; 3497 leaf ipsec-policy-name { 3498 type string; 3499 mandatory true; 3500 description 3501 "It contains the SPD entry name (unique) of 3502 the IPsec policy that hits the IP packet 3503 required IPsec SA. It is assumed the 3504 Security Controller will have a copy of the 3505 information of this policy so it can 3506 extract all the information with this 3507 unique identifier. The type of IPsec SA is 3508 defined in the policy so the Security 3509 Controller can also know the type of IPsec 3510 SA that must be generated."; 3511 } 3512 container traffic-selector { 3513 description 3514 "The IP packet that triggered the acquire 3515 and requires an IPsec SA. Specifically it 3516 will contain the IP source/mask and IP 3517 destination/mask; protocol (udp, tcp, 3518 etc...); and source and destination 3519 ports."; 3520 uses ic:selector-grouping; 3521 } 3522 } 3524 notification sadb-expire { 3525 description "An IPsec SA expiration (soft or hard)."; 3526 leaf ipsec-sa-name { 3527 type string; 3528 mandatory true; 3529 description 3530 "It contains the SAD entry name (unique) of 3531 the IPsec SA that has expired. It is assumed 3532 the Security Controller will have a copy of the 3533 IPsec SA information (except the cryptographic 3534 material and state data) indexed by this name 3535 (unique identifier) so it can know all the 3536 information (crypto algorithms, etc.) about 3537 the IPsec SA that has expired in order to 3538 perform a rekey (soft lifetime) or delete it 3539 (hard lifetime) with this unique identifier."; 3540 } 3541 leaf soft-lifetime-expire { 3542 type boolean; 3543 default true; 3544 description 3545 "If this value is true the lifetime expired is 3546 soft. If it is false is hard."; 3547 } 3548 container lifetime-current { 3549 description 3550 "IPsec SA current lifetime. If 3551 soft-lifetime-expired is true this container is 3552 set with the lifetime information about current 3553 soft lifetime."; 3554 uses ic:lifetime; 3555 } 3556 } 3557 notification sadb-seq-overflow { 3558 description "Sequence overflow notification."; 3559 leaf ipsec-sa-name { 3560 type string; 3561 mandatory true; 3562 description 3563 "It contains the SAD entry name (unique) of 3564 the IPsec SA that is about to have sequence 3565 number overflow and rollover is not permitted. 3566 It is assumed the Security Controller will have 3567 a copy of the IPsec SA information (except the 3568 cryptographic material and state data) indexed 3569 by this name (unique identifier) so the it can 3570 know all the information (crypto algorithms, 3571 etc.) about the IPsec SA that has expired in 3572 order to perform a rekey of the IPsec SA."; 3573 } 3574 } 3575 notification sadb-bad-spi { 3576 description 3577 "Notify when the NSF receives a packet with an 3578 incorrect SPI (i.e. not present in the SAD)."; 3579 leaf spi { 3580 type uint32 { range "0..max"; } 3581 mandatory true; 3582 description 3583 "SPI number contained in the erroneous IPsec 3584 packet."; 3585 } 3586 } 3587 }/*module ietf-ipsec*/ 3589 3591 Appendix D. Example of IKE case, tunnel mode (gateway-to-gateway) with 3592 X.509 certificate authentication. 3594 This example shows a XML configuration file sent by the Security 3595 Controller to establish a IPsec Security Association between two NSFs 3596 in tunnel mode (gateway-to-gateway) with ESP, and authentication 3597 based on X.509 certificates using IKEv2. 3599 Security Controller 3600 | 3601 /---- Southbound interface -----\ 3602 / \ 3603 / \ 3604 / \ 3605 / \ 3606 nsf_h1 nsf_h2 3607 h1---- (:1/:100)===== IPsec_ESP_Tunnel_mode =====(:200/:1)-------h2 3608 2001:DB8:1:/64 (2001:DB8:123:/64) 2001:DB8:2:/64 3610 Figure 7: IKE case, tunnel mode , X.509 certicate authentication. 3612 3614 3615 3616 nsf_h1_pad 3617 2001:DB8:123::100 3618 3619 digital-signature 3620 3621 base64encodedvalue== 3622 base64encodedvalue== 3623 base64encodedvalue== 3624 3625 3626 3627 3628 nsf_h2_pad 3629 2001:DB8:123::200 3630 ikev2 3631 3632 digital-signature 3633 3634 3635 1 3636 base64encodedvalue== 3637 base64encodedvalue== 3638 3639 3640 3641 3642 3643 nsf_h1-nsf_h2 3644 start 3645 ikev2 3646 false 3647 true 3648 3649 60 3650 120 3651 3652 3653 3600 3654 3655 7 3656 3657 3 3658 3659 18 3660 3661 30 3662 15 3663 3664 nsf_h1_pad 3665 3666 3667 nsf_h2_pad 3668 3669 3670 3671 nsf_h1-nsf_h2 3672 3673 32 3674 3675 2001:DB8:1::0/64 3676 2001:DB8:2::0/64 3677 any 3678 3679 0 3680 0 3681 3682 3683 0 3684 0 3685 3686 3687 3688 protect 3689 3690 false 3691 true 3692 false 3693 false 3694 tunnel 3695 esp 3696 3697 3698 2 3699 3700 12 3701 false 3702 3703 3704 2001:DB8:123::100 3705 2001:DB8:123::200 3706 clear 3707 true 3708 false 3709 3710 3711 3712 3713 3714 3715 3716 3717 18 3718 3719 1000000 3720 1000 3721 3722 60 3723 replace 3724 3725 3726 2000000 3727 2000 3728 3729 120 3730 3731 3732 3733 3735 Appendix E. Example of IKE-less case, transport mode (host-to-host). 3737 This example shows a XML configuration file sent by the Security 3738 Controller to establish a IPsec Security association between two NSFs 3739 in transport mode (host-to-host) with ESP. 3741 Security Controller 3742 | 3743 /---- Southbound interface -----\ 3744 / \ 3745 / \ 3746 / \ 3747 / \ 3748 nsf_h1 nsf_h2 3749 (:100)===== IPsec_ESP_Transport_mode =====(:200) 3750 (2001:DB8:123:/64) 3752 Figure 8: IKE-less case, transport mode. 3754 3757 3758 3759 3760 in/trans/2001:DB8:123::200/2001:DB8:123::100 3761 3762 inbound 3763 1 3764 3765 3766 2001:DB8:123::200/128 3767 2001:DB8:123::100/128 3768 any 3769 3770 0 3771 0 3772 3773 3774 0 3775 0 3776 3777 3778 3779 protect 3780 3781 true 3782 true 3783 transport 3784 esp 3785 3786 3787 2 3788 3789 12 3790 3791 3792 3793 3794 3795 3796 out/trans/2001:DB8:123::100/2001:DB8:123::200 3797 outbound 3798 1 3799 3800 3801 2001:DB8:123::100/128 3802 2001:DB8:123::200/128 3803 any 3804 3805 0 3806 0 3807 3808 3809 0 3810 0 3811 3812 3813 3814 protect 3815 3816 true 3817 true 3818 transport 3819 esp 3820 3821 3822 2 3823 3824 12 3825 3826 3827 3828 3829 3830 3831 3832 3833 out/trans/2001:DB8:123::100/2001:DB8:123::200 3834 1 3835 3836 34501 3837 true 3838 100 3839 true 3840 32 3841 3842 2001:DB8:123::100/128 3843 2001:DB8:123::200/128 3844 any 3845 3846 0 3847 0 3848 3849 3850 0 3851 0 3852 3853 3854 esp 3855 transport 3856 3857 3858 3859 12 3860 01:23:45:67:89:AB:CE:DF 3861 01:23:45:67:89:AB:CE:DF 3862 3863 3864 3865 2 3866 01:23:45:67:89:AB:CE:DF 3867 3868 3869 3870 3871 3872 in/trans/2001:DB8:123::200/2001:DB8:123::100 3873 1 3874 3875 34502 3876 true 3877 100 3878 true 3879 32 3880 3881 2001:DB8:123::200/128 3882 2001:DB8:123::100/128 3883 any 3884 3885 0 3886 0 3887 3888 3889 0 3890 0 3891 3892 3893 esp 3894 transport 3895 3896 3897 3898 12 3899 01:23:45:67:89:AB:CE:DF 3900 01:23:45:67:89:AB:CE:DF 3901 3902 3903 3904 2 3905 01:23:45:67:89:AB:CE:DF 3906 3907 3908 3909 2000000 3910 2000 3911 3912 120 3913 3914 3915 1000000 3916 1000 3917 3918 60 3919 replace 3920 3921 3922 3923 3924 3926 Appendix F. Examples of notifications. 3928 Below we show several XML files that represent different types of 3929 notifications defined in the IKE-less YANG model, which are sent by 3930 the NSF to the Security Controller. The notifications happen in the 3931 IKE-less case. 3933 3934 in/trans/2001:DB8:123::200/2001:DB8:123::100 3935 true 3936 3937 1000000 3938 1000 3939 3940 60 3941 3942 3944 Figure 9: Example of sadb-expire notification. 3946 3947 in/trans/2001:DB8:123::200/2001:DB8:123::100 3948 3949 2001:DB8:123::200/128 3950 2001:DB8:123::100/128 3951 any 3952 3953 0 3954 0 3955 3956 3957 0 3958 0 3959 3960 3961 3963 Figure 10: Example of sadb-acquire notification. 3965 3966 in/trans/2001:DB8:123::200/2001:DB8:123::100 3967 3969 Figure 11: Example of sadb-seq-overflow notification. 3971 3973 666 3974 3976 Figure 12: Example of sadb-bad-spi notification. 3978 Authors' Addresses 3980 Rafa Marin-Lopez 3981 University of Murcia 3982 Campus de Espinardo S/N, Faculty of Computer Science 3983 Murcia 30100 3984 Spain 3986 Phone: +34 868 88 85 01 3987 EMail: rafa@um.es 3989 Gabriel Lopez-Millan 3990 University of Murcia 3991 Campus de Espinardo S/N, Faculty of Computer Science 3992 Murcia 30100 3993 Spain 3995 Phone: +34 868 88 85 04 3996 EMail: gabilm@um.es 3998 Fernando Pereniguez-Garcia 3999 University Defense Center 4000 Spanish Air Force Academy, MDE-UPCT 4001 San Javier (Murcia) 30720 4002 Spain 4004 Phone: +34 968 18 99 46 4005 EMail: fernando.pereniguez@cud.upct.es