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