idnits 2.17.1 draft-ietf-i2nsf-sdn-ipsec-flow-protection-10.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 608 has weird spacing: '...ap-type uin...' == Line 610 has weird spacing: '... secret yan...' == Line 643 has weird spacing: '...ry-name str...' == Line 645 has weird spacing: '...ry-name str...' == Line 661 has weird spacing: '...w start ine...' == (10 more instances...) -- The document date (October 21, 2020) is 1254 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) == Outdated reference: A later version (-34) exists of draft-ietf-netconf-crypto-types-18 -- Possible downref: Non-RFC (?) normative reference: ref. 'IKEv2-Parameters' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU-T.X.690' ** Downref: Normative reference to an Informational RFC: RFC 5915 ** Downref: Normative reference to an Informational RFC: RFC 8017 -- Obsolete informational reference (is this intentional?): RFC 8229 (Obsoleted by RFC 9329) Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 4 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: April 24, 2021 F. Pereniguez-Garcia 6 University Defense Center 7 October 21, 2020 9 Software-Defined Networking (SDN)-based IPsec Flow Protection 10 draft-ietf-i2nsf-sdn-ipsec-flow-protection-10 12 Abstract 14 This document describes how to provide IPsec-based flow protection 15 (integrity and confidentiality) by means of an Interface to Network 16 Security Function (I2NSF) controller. It considers two main well- 17 known scenarios in IPsec: (i) gateway-to-gateway and (ii) host-to- 18 host. The service described in this document allows the 19 configuration and monitoring of IPsec Security Associations (SAs) 20 from a I2NSF Controller to one or several flow-based Network Security 21 Functions (NSFs) that rely on IPsec to protect data traffic. 23 The document focuses on the I2NSF NSF-facing interface by providing 24 YANG data models for configuring the IPsec databases (SPD, SAD, PAD) 25 and IKEv2. This allows IPsec SA establishment with minimal 26 intervention by the network administrator. It does not define any 27 new protocol. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on April 24, 2021. 46 Copyright Notice 48 Copyright (c) 2020 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 65 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 4. SDN-based IPsec management description . . . . . . . . . . . 6 67 4.1. IKE case: IKEv2/IPsec in the NSF . . . . . . . . . . . . 6 68 4.2. IKE-less case: IPsec (no IKEv2) in the NSF. . . . . . . . 7 69 5. IKE case vs IKE-less case . . . . . . . . . . . . . . . . . . 9 70 5.1. Rekeying process . . . . . . . . . . . . . . . . . . . . 10 71 5.2. NSF state loss. . . . . . . . . . . . . . . . . . . . . . 11 72 5.3. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 11 73 5.4. NSF registration and discovery . . . . . . . . . . . . . 12 74 6. YANG configuration data models . . . . . . . . . . . . . . . 12 75 6.1. IKE case model . . . . . . . . . . . . . . . . . . . . . 13 76 6.2. IKE-less case model . . . . . . . . . . . . . . . . . . . 17 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 78 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 79 8.1. IKE case . . . . . . . . . . . . . . . . . . . . . . . . 23 80 8.2. IKE-less case . . . . . . . . . . . . . . . . . . . . . . 24 81 8.3. YANG modules . . . . . . . . . . . . . . . . . . . . . . 24 82 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 84 10.1. Normative References . . . . . . . . . . . . . . . . . . 26 85 10.2. Informative References . . . . . . . . . . . . . . . . . 29 86 Appendix A. Common YANG model for IKE and IKE-less cases . . . . 31 87 Appendix B. YANG model for IKE case . . . . . . . . . . . . . . 46 88 Appendix C. YANG model for IKE-less case . . . . . . . . . . . . 65 89 Appendix D. XML configuration example for IKE case (gateway-to- 90 gateway) . . . . . . . . . . . . . . . . . . . . . . 76 91 Appendix E. XML configuration example for IKE-less case (host- 92 to-host) . . . . . . . . . . . . . . . . . . . . . . 80 93 Appendix F. XML notification examples . . . . . . . . . . . . . 84 94 Appendix G. Operational use cases examples . . . . . . . . . . . 86 95 G.1. Example of IPsec SA establishment . . . . . . . . . . . . 86 96 G.1.1. IKE case . . . . . . . . . . . . . . . . . . . . . . 86 97 G.1.2. IKE-less case . . . . . . . . . . . . . . . . . . . . 88 98 G.2. Example of the rekeying process in IKE-less case . . . . 90 99 G.3. Example of managing NSF state loss in IKE-less case . . . 91 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 91 102 1. Introduction 104 Software-Defined Networking (SDN) is an architecture that enables 105 users to directly program, orchestrate, control and manage network 106 resources through software. The SDN paradigm relocates the control 107 of network resources to a centralized entity, namely SDN Controller. 108 SDN controllers configure and manage distributed network resources 109 and provide an abstracted view of the network resources to SDN 110 applications. SDN applications can customize and automate the 111 operations (including management) of the abstracted network resources 112 in a programmable manner via this interface [RFC7149] [ITU-T.Y.3300] 113 [ONF-SDN-Architecture] [ONF-OpenFlow]. 115 Recently, several network scenarios now demand a centralized way of 116 managing different security aspects. For example, Software-Defined 117 WANs (SD-WANs). SD-WANs are an SDN extension providing a software 118 abstraction to create secure network overlays over traditional WAN 119 and branch networks. SD-WANs utilize IPsec [RFC4301] as an 120 underlying security protocol. The goal of SD-WANs is to provide 121 flexible and automated deployment from a centralized point to enable 122 on-demand network security services such as IPsec Security 123 Association (IPsec SA) management. Additionally, Section 4.3.3 in 124 [RFC8192] describes another example use case for Cloud Data Center 125 Scenario titled "Client-Specific Security Policy in Cloud VPNs". The 126 use case in RFC 8192 states that "dynamic key management is critical 127 for securing the VPN and the distribution of policies". These VPNs 128 can be established using IPsec. The management of IPsec SAs in data 129 centers using a centralized entity is a scenario where the current 130 specification maybe applicable. 132 Therefore, with the growth of SDN-based scenarios where network 133 resources are deployed in an autonomous manner, a mechanism to manage 134 IPsec SAs from a centralized entity becomes more relevant in the 135 industry. 137 In response to this need, the Interface to Network Security Functions 138 (I2NSF) charter states that the goal of this working group is "to 139 define set of software interfaces and data models for controlling and 140 monitoring aspects of physical and virtual Network Security 141 Functions". As defined in [RFC8192] an NSF is "a function that is 142 used to ensure integrity, confidentiality, or availability of network 143 communication; to detect unwanted network activity; or to block, or 144 at least mitigate, the effects of unwanted activity". This document 145 pays special attention to flow-based NSFs that ensure integrity and 146 confidentiality by means of IPsec. 148 In fact, as Section 3.1.9 in [RFC8192] states "there is a need for a 149 controller to create, manage, and distribute various keys to 150 distributed NSFs.", however "there is a lack of a standard interface 151 to provision and manage security associations". Inspired in the SDN 152 paradigm, the I2NSF framework [RFC8329] defines a centralized entity, 153 the I2NSF Controller, which manages one or multiple NSFs through a 154 I2NSF NSF-Facing interface. In this document we define a service 155 allowing the I2NSF Controller to carry out the key management 156 procedures. More specifically, we define YANG data models for I2NSF 157 NSF-Facing interface that allow the I2NSF Controller to configure and 158 monitor IPsec-enabled flow-based NSFs. 160 IPsec architecture [RFC4301] defines clear separation between the 161 processing to provide security services to IP packets and the key 162 management procedures to establish the IPsec Security Associations, 163 which allows to centralize the key management procedures in the I2NSF 164 Controller. This document considers two typical scenarios to 165 autonomously manage IPsec SAs: gateway-to-gateway and host-to-host 166 [RFC6071]. In these cases, hosts, gateways or both may act as NSFs. 167 Consideration for the host-to-gateway scenario is out of scope. 169 For the definition of the YANG data model for I2NSF NSF-Facing 170 interface, this document considers two general cases, namely: 172 1) IKE case. The NSF implements the Internet Key Exchange version 2 173 (IKEv2) protocol and the IPsec databases: the Security Policy 174 Database (SPD), the Security Association Database (SAD) and the 175 Peer Authorization Database (PAD). The I2NSF Controller is in 176 charge of provisioning the NSF with the required information in 177 the SPD, PAD (e.g. IKE credential) and IKE protocol itself (e.g. 178 parameters for the IKE_SA_INIT negotiation). 180 2) IKE-less case. The NSF only implements the IPsec databases (no 181 IKE implementation). The I2NSF Controller will provide the 182 required parameters to create valid entries in the SPD and the 183 SAD into the NSF. Therefore, the NSF will have only support for 184 IPsec while key management functionality is moved to the I2NSF 185 Controller. 187 In both cases, a data model for the I2NSF NSF-Facing interface is 188 required to carry out this provisioning in a secure manner between 189 the I2NSF Controller and the NSF. Using YANG data modelling language 190 version 1.1 [RFC7950] and based on YANG models defined in 191 [netconf-vpn], [I-D.tran-ipsecme-yang], RFC 4301 [RFC4301] and RFC 192 7296 [RFC7296], this document defines the required interfaces with a 193 YANG model for configuration and state data for IKE, PAD, SPD and SAD 194 (see Appendix A, Appendix B and Appendix C). The proposed YANG data 195 model conforms to the Network Management Datastore Architecture 196 (NMDA) defined in [RFC8342]. Examples of the usage of these models 197 can be found in Appendix D, Appendix E and Appendix F. 199 In summary, the objetives of this I-D are: 201 o To describe the architecture for the I2NSF-based IPsec management, 202 which allows the establishment and management of IPsec security 203 associations from the I2NSF Controller in order to protect 204 specific data flows between two flow-based NSFs implementing 205 IPsec. 207 o To map this architecture to the I2NSF Framework. 209 o To define the interfaces required to manage and monitor the IPsec 210 SAs in the NSF from a I2NSF Controller. YANG data models are 211 defined for configuration and state data for IPsec and IKEv2 212 management through the I2NSF NSF-Facing interface. Thus, this I-D 213 does not define any new protocol. 215 2. Requirements Language 217 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 218 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 219 "OPTIONAL" in this document are to be interpreted as described in RFC 220 2119 [RFC2119]. When these words appear in lower case, they have 221 their natural language meaning. 223 3. Terminology 225 This document uses the terminology described in [RFC8329], [RFC8192], 226 [RFC4301],[RFC7296], [RFC6241], [ITU-T.Y.3300]. The following term 227 is defined in [ITU-T.Y.3300]: 229 o Software-Defined Networking. 231 The following terms are in defined in [RFC8192]: 233 o NSF. 235 o Flow-based NSF. 237 The following terms are defined in [RFC4301]: 239 o Peer Authorization Database (PAD). 241 o Security Associations Database (SAD). 243 o Security Policy Database (SPD). 245 The following term is defined in [RFC6437]: 247 o Flow/traffic flow. 249 The following terms is defined in [RFC7296]: 251 o Internet Key Exchange version 2 (IKEv2). 253 The following terms are defined in [RFC6241]: 255 o Configuration data. 257 o Configuration datastore. 259 o State date. 261 o Startup configuration datastore. 263 o Running configuration datastore. 265 4. SDN-based IPsec management description 267 As mentioned in Section 1, two cases are considered, depending on 268 whether the NSF implements IKEv2 or not: IKE case and IKE-less case. 270 4.1. IKE case: IKEv2/IPsec in the NSF 272 In this case, the NSF implements IPsec with IKEv2 support. The I2NSF 273 Controller is in charge of managing and applying IPsec connection 274 information (determining which nodes need to start an IKEv2/IPsec 275 session, identifying the type of traffic to be protected, deriving 276 and delivering IKEv2 Credentials such as a pre-shared key, 277 certificates, etc.), and applying other IKEv2 configuration 278 parameters (e.g. cryptographic algorithms for establishing an IKEv2 279 SA) to the NSF necessary for the IKEv2 negotiation. 281 With these entries, the IKEv2 implementation can operate to establish 282 the IPsec SAs. The I2NSF User establishes the IPsec requirements and 283 information about the end points information (through the I2NSF 284 Consumer-Facing Interface, [RFC8329]), and the I2NSF Controller 285 translates these requirements into IKEv2, SPD and PAD entries that 286 will be installed into the NSF (through the I2NSF NSF-Facing 287 Interface). With that information, the NSF can just run IKEv2 to 288 establish the required IPsec SA (when the traffic flow needs 289 protection). Figure 1 shows the different layers and corresponding 290 functionality. 292 +-------------------------------------------+ 293 | IPsec Management System | I2NSF User 294 +-------------------------------------------+ 295 | 296 | I2NSF Consumer-Facing 297 | Interface 298 +-------------------------------------------+ 299 | IKEv2 Configuration, PAD and SPD Entries | I2NSF 300 | Distribution | Controller 301 +-------------------------------------------+ 302 | 303 | I2NSF NSF-Facing 304 | Interface 305 +-------------------------------------------+ 306 | IKEv2 | IPsec(PAD, SPD) | Network 307 |-------------------------------------------| Security 308 | IPsec Data Protection and Forwarding | Function 309 +-------------------------------------------+ 311 Figure 1: IKE case: IKE/IPsec in the NSF 313 I2NSF-based IPsec flow protection services provide dynamic and 314 flexible management of IPsec SAs in flow-based NSFs. In order to 315 support this capability in the IKE case, a YANG data model for IKEv2, 316 SPD and PAD configuration data, and for IKEv2 state data MUST be 317 defined for the I2NSF NSF-Facing Interface. 319 4.2. IKE-less case: IPsec (no IKEv2) in the NSF. 321 In this case, the NSF does not deploy IKEv2 and, therefore, the I2NSF 322 Controller has to perform the IKEv2 security functions and management 323 of IPsec SAs by populating and managing the SPD and the SAD. 325 +-----------------------------------------+ 326 | IPsec Management System | I2NSF User 327 +-----------------------------------------+ 328 | 329 | I2NSF Consumer-Facing Interface 330 | 331 +-----------------------------------------+ 332 | SPD and SAD Entries | I2NSF 333 | Distribution | Controller 334 +-----------------------------------------+ 335 | 336 | I2NSF NSF-Facing Interface 337 | 338 +-----------------------------------------+ 339 | IPsec (SPD, SAD) | Network 340 |-----------------------------------------| Security 341 | IPsec Data Protection and Forwarding | Function 342 +-----------------------------------------+ 344 Figure 2: IKE-less case: IPsec (no IKEv2) in the NSF 346 As shown in Figure 2, when an I2NSF User enforces flow-based 347 protection policies through the Consumer-Facing Interface, the I2NSF 348 Controller translates these requirements into SPD and SAD entries, 349 which are installed in the NSF. PAD entries are not required since 350 there is no IKEv2 in the NSF. 352 In order to support the IKE-less case, a YANG data model for SPD and 353 SAD configuration data and SAD state data MUST be defined for the 354 NSF-Facing Interface. 356 Specifically, the IKE-less case assumes that the I2NSF Controller has 357 to perform some security functions that IKEv2 typically does, namely 358 (non-exhaustive): 360 o IV generation. 362 o Prevent counter resets for the same key. 364 o Generation of pseudo-random cryptographic keys for the IPsec SAs. 366 o Generation of the IPsec SAs when required based on notifications 367 (i.e. sadb-acquire) from the NSF. 369 o Rekey of the IPsec SAs based on notifications from the NSF (i.e. 370 expire). 372 o NAT Traversal discovery and management. 374 Additionally to these functions, another set of tasks must be 375 performed by the I2NSF Controller (non-exhaustive list): 377 o IPsec SA's SPI random generation. 379 o Cryptographic algorithm/s selection. 381 o Usage of extended sequence numbers. 383 o Establishment of proper traffic selectors. 385 5. IKE case vs IKE-less case 387 In principle, the IKE case is easier to deploy than the IKE-less case 388 because current flow-based NSFs (either hosts or gateways) have 389 access to IKEv2 implementations. While gateways typically deploy an 390 IKEv2/IPsec implementation, hosts can easily install it. As 391 downside, the NSF needs more resources to hold IKEv2 such as memory 392 for the IKEv2 implementation, and computation, since each IPsec 393 security association rekeying MAY involve a Diffie-Hellman exchange. 395 Alternatively, IKE-less case benefits the deployment in resource- 396 constrained NSFs. Moreover, IKEv2 does not need to be performed in 397 gateway-to-gateway and host-to-host scenarios under the same I2NSF 398 Controller (see Appendix G.1). On the contrary, the complexity of 399 creating and managing IPsec SAs is shifted to the I2NSF Controller 400 since IKEv2 is not in the NSF. As a consequence, this may result in 401 a more complex implementation in the controller side in comparison 402 with IKE case. For example, the I2NSF Controller has to deal with 403 the latency existing in the path between the I2NSF Controller and the 404 NSF, in order to solve tasks such as rekey, or creation and 405 installation of new IPsec SAs. However, this is not specific to this 406 contribution but a general aspect in any SDN-based network. In 407 summary, this complexity MAY create some scalability and performance 408 issues when the number of NSFs is high. 410 Nevertheless, literature around SDN-based network management using a 411 centralized controller (like the I2NSF Controller) is aware about 412 scalability and performance issues and solutions have been already 413 provided and discussed (e.g. hierarchical controllers; having 414 multiple replicated controllers, dedicated high-speed management 415 networks, etc). In the context of I2SNF-based IPsec management, one 416 way to reduce the latency and alleviate some performance issues can 417 be the installation of the IPsec policies and IPsec SAs at the same 418 time (proactive mode, as described in Appendix G.1) instead of 419 waiting for notifications (e.g. a notification sadb-acquire when a 420 new IPsec SA is required) to proceed with the IPsec SA installation 421 (reactive mode). Another way to reduce the overhead and the 422 potential scalability and performance issues in the I2NSF Controller 423 is to apply the IKE case described in this document, since the IPsec 424 SAs are managed between NSFs without the involvement of the I2NSF 425 Controller at all, except by the initial configuration (i.e. IKEv2, 426 PAD and SPD entries) provided by the I2NSF Controller. Other 427 solutions, such as Controller-IKE 428 [I-D.carrel-ipsecme-controller-ike], have proposed that NSFs provide 429 their DH public keys to the I2NSF Controller, so that the I2NSF 430 Controller distributes all public keys to all peers. All peers can 431 calculate a unique pairwise secret for each other peer and there is 432 no inter-NSF messages. A rekey mechanism is further described in 433 [I-D.carrel-ipsecme-controller-ike]. 435 In terms of security, IKE case provides better security properties 436 than IKE-less case, as we discuss in section Section 8. The main 437 reason is that the NSFs generate the session keys and not the I2NSF 438 Controller. 440 5.1. Rekeying process 442 Performing a rekey for IPsec SAs is an important operation during the 443 IPsec SAs management. With the YANG data models defined in this 444 document the I2NSF Controller can configure and conduct the rekey 445 process. Depending on the case, the rekey process is different. 447 For the IKE case, the rekeying process is carried out by IKEv2, 448 following the information defined in the SPD and SAD (i.e. based on 449 the IPsec SA lifetime established by the I2NSF Controller using the 450 YANG data model defined in this document). Therefore, IPsec 451 connections will live unless something different is required by the 452 I2NSF User or the I2NSF Controller detects something wrong. 454 For the IKE-less case, the I2NSF Controller MUST take care of the 455 rekeying process. When the IPsec SA is going to expire (e.g. IPsec 456 SA soft lifetime), it MUST create a new IPsec SA and it MAY remove 457 the old one (if a IPsec SA lifetime has not been defined). This 458 rekeying process starts when the I2NSF Controller receives a sadb- 459 expire notification or it decides so, based on lifetime state data 460 obtained from the NSF. How the I2NSF Controller implements an 461 algorithm for the rekey process is out of the scope of this document. 462 Nevertheless, an example of how this rekey could be performed is in 463 Appendix G.2. 465 5.2. NSF state loss. 467 If one of the NSF restarts, it will lose the IPsec state (affected 468 NSF). By default, the I2NSF Controller can assume that all the state 469 has been lost and therefore it will have to send IKEv2, SPD and PAD 470 information to the NSF in the IKE case, and SPD and SAD information 471 in the IKE-less case. 473 In both cases, the I2NSF Controller is aware of the affected NSF 474 (e.g. the NETCONF/TCP connection is broken with the affected NSF, the 475 I2NSF Controller is receiving sadb-bad-spi notification from a 476 particular NSF, etc.). Moreover, the I2NSF Controller keeps a list 477 of NSFs that have IPsec SAs with the affected NSF. Therefore, it 478 knows the affected IPsec SAs. 480 In the IKE case, the I2NSF Controller will configure the affected NSF 481 with the new IKEv2, SPD and PAD information. It has also to send new 482 parameters (e.g. a new fresh PSK for authentication) to the NSFs 483 which have IKEv2 SAs and IPsec SAs with the affected NSF. Finally, 484 the I2NSF Controller will instruct the affected NSF to start the 485 IKEv2 negotiation with the new configuration. 487 Alternatively, IKEv2 configuration MAY be made permanent between NSFs 488 reboots without compromising security by means of the startup 489 configuration datastore in the NSF. This way, each time a NSF 490 reboots it will use that configuration for each rebooting. It would 491 imply avoiding to contact with the I2NSF Controller. 493 In the IKE-less case, the I2NSF Controller SHOULD delete the old 494 IPsec SAs in the non-failed nodes established with the affected NSF. 495 Once the affected node restarts, the I2NSF Controller MUST take the 496 necessary actions to reestablish IPsec protected communication 497 between the failed node and those others having IPsec SAs with the 498 affected NSF. How the I2NSF Controller implements an algorithm for 499 managing a potential NSF state loss is out of the scope of this 500 document. Nevertheless, an example of how this could be performed is 501 described in Appendix G.3. 503 5.3. NAT Traversal 505 In the IKE case, IKEv2 already provides a mechanism to detect whether 506 some of the peers or both are located behind a NAT. If there is a 507 NAT network configured between two peers, it is required to activate 508 the usage of UDP or TCP/TLS encapsulation for ESP packets ([RFC3948], 509 [RFC8229]). Note that the usage of IPsec transport mode when NAT is 510 required MUST NOT be used in this specification. 512 In the IKE-less case, the NSF does not have the assistance of the 513 IKEv2 implementation to detect if it is located behind a NAT. If the 514 NSF does not have any other mechanism to detect this situation, the 515 I2NSF Controller SHOULD implement a mechanism to detect that case. 516 The SDN paradigm generally assumes the I2NSF Controller has a view of 517 the network under its control. This view is built either by 518 requesting information from the NSFs under its control, or by 519 information pushed from the NSFs to the I2NSF Controller. Based on 520 this information, the I2NSF Controller MAY guess if there is a NAT 521 configured between two hosts, and apply the required policies to both 522 NSFs besides activating the usage of UDP or TCP/TLS encapsulation of 523 ESP packets ([RFC3948], [RFC8229]). The interface for discovering if 524 the NSF is behind a NAT is out of scope of this document. 526 If the I2NSF Controller does not have any mechanism to know whether a 527 host is behind a NAT or not, then the IKE-case MUST be used and not 528 the IKE-less case. 530 5.4. NSF registration and discovery 532 NSF registration refers to the process of facilitating the I2NSF 533 Controller information about a valid NSF such as certificate, IP 534 address, etc. This information is incorporated in a list of NSFs 535 under its control 537 The assumption in this document is that, for both cases, before a NSF 538 can operate in this system, it MUST be registered in the I2NSF 539 Controller. In this way, when the NSF starts and establishes a 540 connection to the I2NSF Controller, it knows that the NSF is valid 541 for joining the system. 543 Either during this registration process or when the NSF connects with 544 the I2NSF Controller, the I2NSF Controller MUST discover certain 545 capabilities of this NSF, such as what is the cryptographic suite 546 supported, authentication method, the support of the IKE case and/or 547 the IKE-less case, etc. 549 The registration and discovery processes are out of the scope of this 550 document. 552 6. YANG configuration data models 554 In order to support the IKE and IKE-less cases we have modeled the 555 different parameters and values that must be configured to manage 556 IPsec SAs. Specifically, the IKE case requires modeling IKEv2 557 configuration parameters, SPD and PAD, while the IKE-less case 558 requires configuration models for the SPD and SAD. We have defined 559 three models: ietf-i2nsf-ikec (Appendix A, common to both cases), 560 ietf-i2nsf-ike (Appendix B, IKE case), ietf-i2nsf-ikeless 561 (Appendix C, IKE-less case). Since the model ietf-i2nsf-ikec has 562 only typedef and groupings common to the other modules, we only show 563 a simplified view of the ietf-i2nsf-ike and ietf-i2nsf-ikeless 564 models. 566 6.1. IKE case model 568 The model related to IKEv2 has been extracted from reading IKEv2 569 standard in [RFC7296], and observing some open source 570 implementations, such as Strongswan [strongswan] or Libreswan 571 [libreswan]. 573 The definition of the PAD model has been extracted from the 574 specification in section 4.4.3 in [RFC4301] (NOTE: We have observed 575 that many implementations integrate PAD configuration as part of the 576 IKEv2 configuration). 578 The data model for the IKE case is defined by YANG model "ietf-i2nsf- 579 ike". Its structure is depicted in the following diagram, using the 580 notation syntax for YANG tree diagrams ([RFC8340]). 582 module: ietf-i2nsf-ike 583 +--rw ipsec-ike 584 +--rw pad 585 | +--rw pad-entry* [name] 586 | +--rw name string 587 | +--rw (identity) 588 | | +--:(ipv4-address) 589 | | | +--rw ipv4-address? inet:ipv4-address 590 | | +--:(ipv6-address) 591 | | | +--rw ipv6-address? inet:ipv6-address 592 | | +--:(fqdn-string) 593 | | | +--rw fqdn-string? inet:domain-name 594 | | +--:(rfc822-address-string) 595 | | | +--rw rfc822-address-string? string 596 | | +--:(dnx509) 597 | | | +--rw dnx509? string 598 | | +--:(gnx509) 599 | | | +--rw gnx509? string 600 | | +--:(id-key) 601 | | | +--rw id-key? string 602 | | +--:(id-null) 603 | | +--rw id-null? empty 604 | +--rw auth-protocol? auth-protocol-type 605 | +--rw peer-authentication 606 | +--rw auth-method? auth-method-type 607 | +--rw eap-method 608 | | +--rw eap-type uint8 609 | +--rw pre-shared 610 | | +--rw secret yang:hex-string 611 | +--rw digital-signature 612 | +--rw ds-algorithm? uint8 613 | +--rw (public-key) 614 | | +--:(raw-public-key) 615 | | | +--rw raw-public-key? binary 616 | | +--:(cert-data) 617 | | +--rw cert-data? ct:x509 618 | +--rw private-key? binary 619 | +--rw ca-data* ct:x509 620 | +--rw crl-data? ct:crl 621 | +--rw crl-uri? inet:uri 622 | +--rw oscp-uri? inet:uri 623 +--rw conn-entry* [name] 624 | +--rw name string 625 | +--rw autostartup? autostartup-type 626 | +--rw initial-contact? boolean 627 | +--rw version? auth-protocol-type 628 | +--rw fragmentation? boolean 629 | +--rw ike-sa-lifetime-soft 630 | | +--rw rekey-time? uint32 631 | | +--rw reauth-time? uint32 632 | +--rw ike-sa-lifetime-hard 633 | | +--rw over-time? uint32 634 | +--rw authalg* nsfikec:integrity-algorithm-type 635 | +--rw encalg* [id] 636 | | +--rw id uint8 637 | | +--rw algorithm-type? nsfikec:encryption-algorithm-type 638 | | +--rw key-length? uint16 639 | +--rw dh-group? pfs-group 640 | +--rw half-open-ike-sa-timer? uint32 641 | +--rw half-open-ike-sa-cookie-threshold? uint32 642 | +--rw local 643 | | +--rw local-pad-entry-name string 644 | +--rw remote 645 | | +--rw remote-pad-entry-name string 646 | +--rw encapsulation-type 647 | | +--rw espencap? esp-encap 648 | | +--rw sport? inet:port-number 649 | | +--rw dport? inet:port-number 650 | | +--rw oaddr* inet:ip-address 651 | +--rw spd 652 | | +--rw spd-entry* [name] 653 | | +--rw name string 654 | | +--rw ipsec-policy-config 655 | | +--rw anti-replay-window? uint64 656 | | +--rw traffic-selector 657 | | | +--rw local-subnet inet:ip-prefix 658 | | | +--rw remote-subnet inet:ip-prefix 659 | | | +--rw inner-protocol? ipsec-inner-protocol 660 | | | +--rw local-ports* [start end] 661 | | | | +--rw start inet:port-number 662 | | | | +--rw end inet:port-number 663 | | | +--rw remote-ports* [start end] 664 | | | +--rw start inet:port-number 665 | | | +--rw end inet:port-number 666 | | +--rw processing-info 667 | | |+--rw action? ipsec-spd-action 668 | | |+--rw ipsec-sa-cfg 669 | | | +--rw pfp-flag? boolean 670 | | | +--rw ext-seq-num? boolean 671 | | | +--rw seq-overflow? boolean 672 | | | +--rw stateful-frag-check? boolean 673 | | | +--rw mode? ipsec-mode 674 | | | +--rw protocol-parameters? ipsec-protocol-parameters 675 | | | +--rw esp-algorithms 676 | | | | +--rw integrity* integrity-algorithm-type 677 | | | | +--rw encryption* [id] 678 | | | | | +--rw id uint8 679 | | | | | +--rw algorithm-type? nsfikec:encryption-algorithm-type 680 | | | | | +--rw key-length? uint16 681 | | | | +--rw tfc-pad? boolean 682 | | | +--rw tunnel 683 | | | +--rw local inet:ip-address 684 | | | +--rw remote inet:ip-address 685 | | | +--rw df-bit? enumeration 686 | | | +--rw bypass-dscp? boolean 687 | | | +--rw dscp-mapping? yang:hex-string 688 | | | +--rw ecn? boolean 689 | | +--rw spd-mark 690 | | +--rw mark? uint32 691 | | +--rw mask? yang:hex-string 692 | +--rw child-sa-info 693 | | +--rw pfs-groups* pfs-group 694 | | +--rw child-sa-lifetime-soft 695 | | | +--rw time? uint32 696 | | | +--rw bytes? uint32 697 | | | +--rw packets? uint32 698 | | | +--rw idle? uint32 699 | | | +--rw action? nsfikec:lifetime-action 700 | | +--rw child-sa-lifetime-hard 701 | | +--rw time? uint32 702 | | +--rw bytes? uint32 703 | | +--rw packets? uint32 704 | | +--rw idle? uint32 705 | +--ro state 706 | +--ro initiator? boolean 707 | +--ro initiator-ikesa-spi? ike-spi 708 | +--ro responder-ikesa-spi? ike-spi 709 | +--ro nat-local? boolean 710 | +--ro nat-remote? boolean 711 | +--ro encapsulation-type 712 | | +--ro espencap? esp-encap 713 | | +--ro sport? inet:port-number 714 | | +--ro dport? inet:port-number 715 | | +--ro oaddr* inet:ip-address 716 | +--ro established? uint64 717 | +--ro current-rekey-time? uint64 718 | +--ro current-reauth-time? uint64 719 +--ro number-ike-sas 720 +--ro total? uint64 721 +--ro half-open? uint64 722 +--ro half-open-cookies? uint64 724 The data model consists of a unique "ipsec-ike" container defined as 725 follows. Firstly, it contains a "pad" container that serves to 726 configure the Peer Authentication Database with authentication 727 information about local and remote peers. More precisely, it 728 consists of a list of entries, each one indicating the identity, 729 authentication method and credentials that will use a particular 730 peer. 732 Next, we find a list "conn-entry" with information about the 733 different IKE connections a peer can maintain with others. Each 734 connection entry is composed of a wide number of parameters to 735 configure different aspects of a particular IKE connection between 736 two peers: local and remote peer authentication information; IKE SA 737 configuration (soft and hard lifetimes, cryptographic algorithms, 738 etc.); list of IPsec policies describing the type of network traffic 739 to be secured (local/remote subnet and ports, etc.) and how must be 740 protected (AH/ESP, tunnel/transport, cryptographic algorithms, etc.); 741 CHILD SA configuration (soft and hard lifetimes); and, state 742 information of the IKE connection (SPIs, usage of NAT, current 743 expiration times, etc.). 745 Lastly, the "ipsec-ike" container declares a "number-ike-sas" 746 container to specify state information reported by the IKE software 747 related to the amount of IKE connections established. 749 Appendix D shows an example of IKE case configuration for a NSF, in 750 tunnel mode (gateway-to-gateway), with NSFs authentication based on 751 X.509 certificates. 753 6.2. IKE-less case model 755 For this case, the definition of the SPD model has been mainly 756 extracted from the specification in section 4.4.1 and Appendix D in 757 [RFC4301], though with some changes, namely: 759 o Each IPsec policy (spd-entry) contains one traffic selector, 760 instead of a list of them. The reason is that we have observed 761 actual kernel implementations only admit a single traffic selector 762 per IPsec policy. 764 o Each IPsec policy contains a identifier (reqid) to relate the 765 policy with the IPsec SA. This is common in Linux-based systems. 767 o Each IPsec policy has only one name and not a list of names. 769 o Combined algorithms have been removed because encryption 770 algorithms MAY include authenticated encryption with associated 771 data (AEAD). 773 o Tunnel information has been extended with information about DSCP 774 mapping and ECN bit. The reason is that we have observed real 775 kernel implementations accept configuration of these values. 777 The definition of the SAD model has been mainly extracted from the 778 specification in section 4.4.2 in [RFC4301] though with some changes, 779 namely: 781 o Each IPsec SA (sad-entry) contains one traffic selector, instead 782 of a list of them. The reason is that we have observed actual 783 kernel implementations only admit a single traffic selector per 784 IPsec SA. 786 o Each IPsec SA contains a identifier (reqid) to relate the IPsec SA 787 with the IPsec Policy. The reason is that we have observed real 788 kernel implementations allow to include this value. 790 o Each IPsec SA has also a name in the same way as IPsec policies. 792 o Combined algorithm has been removed because encryption algorithm 793 MAY include authenticated encryption with associated data (AEAD). 795 o Tunnel information has been extended with information about 796 Differentiated Services Code Point (DSCP) mapping and Explicit 797 Congestion Notificsation (ECN) bit. The reason is that we have 798 observed actual kernel implementations admit the configurations of 799 these values. 801 o Lifetime of the IPsec SAs also include idle time and number of IP 802 packets as threshold to trigger the lifetime. The reason is that 803 we have observed actual kernel implementations allow to set these 804 types of lifetimes. 806 o Information to configure the type of encapsulation (encapsulation- 807 type) for IPsec ESP packets in UDP ([RFC3948]), TCP ([RFC8229]) or 808 TLS ([RFC8229]) has been included. 810 The notifications model has been defined using as reference the 811 PF_KEYv2 standard in [RFC2367]. 813 The data model for the IKE-less case is defined by YANG model "ietf- 814 i2nsf-ikeless". Its structure is depicted in the following diagram, 815 using the notation syntax for YANG tree diagrams ([RFC8340]). 817 module: ietf-i2nsf-ikeless 818 +--rw ipsec-ikeless 819 +--rw spd 820 | +--rw spd-entry* [name] 821 | +--rw name string 822 | +--rw direction nsfikec:ipsec-traffic-direction 823 | +--rw reqid? uint64 824 | +--rw ipsec-policy-config 825 | +--rw anti-replay-window? uint64 826 | +--rw traffic-selector 827 | | +--rw local-subnet inet:ip-prefix 828 | | +--rw remote-subnet inet:ip-prefix 829 | | +--rw inner-protocol? ipsec-inner-protocol 830 | | +--rw local-ports* [start end] 831 | | | +--rw start inet:port-number 832 | | | +--rw end inet:port-number 833 | | +--rw remote-ports* [start end] 834 | | +--rw start inet:port-number 835 | | +--rw end inet:port-number 836 | +--rw processing-info 837 | | +--rw action? ipsec-spd-action 838 | | +--rw ipsec-sa-cfg 839 | | +--rw pfp-flag? boolean 840 | | +--rw ext-seq-num? boolean 841 | | +--rw seq-overflow? boolean 842 | | +--rw stateful-frag-check? boolean 843 | | +--rw mode? ipsec-mode 844 | | +--rw protocol-parameters? ipsec-protocol-parameters 845 | | +--rw esp-algorithms 846 | | | +--rw integrity* integrity-algorithm-type 847 | | | +--rw encryption* [id] 848 | | | |+--rw id uint8 849 | | | |+--rw algorithm-type? nsfikec:encryption-algorithm-type 850 | | | |+--rw key-length? uint16 851 | | | +--rw tfc-pad? boolean 852 | | +--rw tunnel 853 | | +--rw local inet:ip-address 854 | | +--rw remote inet:ip-address 855 | | +--rw df-bit? enumeration 856 | | +--rw bypass-dscp? boolean 857 | | +--rw dscp-mapping? yang:hex-string 858 | | +--rw ecn? boolean 859 | +--rw spd-mark 860 | +--rw mark? uint32 861 | +--rw mask? yang:hex-string 862 +--rw sad 863 +--rw sad-entry* [name] 864 +--rw name string 865 +--rw reqid? uint64 866 +--rw ipsec-sa-config 867 | +--rw spi uint32 868 | +--rw ext-seq-num? boolean 869 | +--rw seq-number-counter? uint64 870 | +--rw seq-overflow? boolean 871 | +--rw anti-replay-window? uint32 872 | +--rw traffic-selector 873 | | +--rw local-subnet inet:ip-prefix 874 | | +--rw remote-subnet inet:ip-prefix 875 | | +--rw inner-protocol? ipsec-inner-protocol 876 | | +--rw local-ports* [start end] 877 | | | +--rw start inet:port-number 878 | | | +--rw end inet:port-number 879 | | +--rw remote-ports* [start end] 880 | | +--rw start inet:port-number 881 | | +--rw end inet:port-number 882 | +--rw protocol-parameters? nsfikec:ipsec-protocol-parameters 883 | +--rw mode? nsfikec:ipsec-mode 884 | +--rw esp-sa 885 | | +--rw encryption 886 | | |+--rw encryption-algorithm? nsfikec:encryption-algorithm-type 887 | | |+--rw key? yang:hex-string 888 | | |+--rw iv? yang:hex-string 889 | | +--rw integrity 890 | | +--rw integrity-algorithm? nsfikec:integrity-algorithm-type 891 | | +--rw key? yang:hex-string 892 | +--rw sa-lifetime-hard 893 | | +--rw time? uint32 894 | | +--rw bytes? uint32 895 | | +--rw packets? uint32 896 | | +--rw idle? uint32 897 | +--rw sa-lifetime-soft 898 | | +--rw time? uint32 899 | | +--rw bytes? uint32 900 | | +--rw packets? uint32 901 | | +--rw idle? uint32 902 | | +--rw action? nsfikec:lifetime-action 903 | +--rw tunnel 904 | | +--rw local inet:ip-address 905 | | +--rw remote inet:ip-address 906 | | +--rw df-bit? enumeration 907 | | +--rw bypass-dscp? boolean 908 | | +--rw dscp-mapping? yang:hex-string 909 | | +--rw ecn? boolean 910 | +--rw encapsulation-type 911 | +--rw espencap? esp-encap 912 | +--rw sport? inet:port-number 913 | +--rw dport? inet:port-number 914 | +--rw oaddr* inet:ip-address 915 +--ro ipsec-sa-state 916 +--ro sa-lifetime-current 917 | +--ro time? uint32 918 | +--ro bytes? uint32 919 | +--ro packets? uint32 920 | +--ro idle? uint32 921 +--ro replay-stats 922 +--ro replay-window? uint64 923 +--ro packet-dropped? uint64 924 +--ro failed? uint32 925 +--ro seq-number-counter? uint64 927 notifications: 928 +---n sadb-acquire {ikeless-notification}? 929 | +--ro ipsec-policy-name string 930 | +--ro traffic-selector 931 | +--ro local-subnet inet:ip-prefix 932 | +--ro remote-subnet inet:ip-prefix 933 | +--ro inner-protocol? ipsec-inner-protocol 934 | +--ro local-ports* [start end] 935 | | +--ro start inet:port-number 936 | | +--ro end inet:port-number 937 | +--ro remote-ports* [start end] 938 | +--ro start inet:port-number 939 | +--ro end inet:port-number 940 +---n sadb-expire {ikeless-notification}? 941 | +--ro ipsec-sa-name string 942 | +--ro soft-lifetime-expire? boolean 943 | +--ro lifetime-current 944 | +--ro time? uint32 945 | +--ro bytes? uint32 946 | +--ro packets? uint32 947 | +--ro idle? uint32 948 +---n sadb-seq-overflow {ikeless-notification}? 949 | +--ro ipsec-sa-name string 950 +---n sadb-bad-spi {ikeless-notification}? 951 +--ro spi uint32 953 The data model consists of a unique "ipsec-ikeless" container which, 954 in turn, is integrated by two additional containers: "spd" and "sad". 955 The "spd" container consists of a list of entries that conform the 956 Security Policy Database. Compared to the IKE case data model, this 957 part specifies a few additional parameters necessary due to the 958 absence of an IKE software in the NSF: traffic direction to apply the 959 IPsec policy, and a value to link an IPsec policy with its associated 960 IPsec SAs. The "sad" container is a list of entries that conform the 961 Security Association Database. In general, each entry allows to 962 specify both configuration information (SPI, traffic selectors, 963 tunnel/transport mode, cryptographic algorithms and keying material, 964 soft/hard lifetimes, etc.) as well as state information (time to 965 expire, replay statistics, etc.) of a concrete IPsec SA. 967 In addition, the module defines a set of notifications to allow the 968 NSF inform I2NSF controller about relevant events such as IPsec SA 969 expiration, sequence number overflow or bad SPI in a received packet. 971 Appendix E shows an example of IKE-less case configuration for a NSF, 972 in transport mode (host-to-host), with NSFs authentication based on 973 shared secrets. For the IKE-less case, Appendix F shows examples of 974 IPsec SA expire, acquire, sequence number overflow and bad SPI 975 notifications. 977 7. IANA Considerations 979 This document registers three URIs in the "ns" subregistry of the 980 IETF XML Registry [RFC3688]. Following the format in [RFC3688], the 981 following registrations are requested: 983 URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikec 984 Registrant Contact: The IESG. 985 XML: N/A, the requested URI is an XML namespace. 987 URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-ike 988 Registrant Contact: The IESG. 989 XML: N/A, the requested URI is an XML namespace. 991 URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless 992 Registrant Contact: The IESG. 993 XML: N/A, the requested URI is an XML namespace. 995 This document registers three YANG modules in the "YANG Module Names" 996 registry [RFC6020]. Following the format in [RFC6020], the following 997 registrations are requested: 999 Name: ietf-i2nsf-ikec 1000 Namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikec 1001 Prefix: nsfikec 1002 Reference: RFC XXXX 1004 Name: ietf-i2nsf-ike 1005 Namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-ike 1006 Prefix: nsfike 1007 Reference: RFC XXXX 1009 Name: ietf-i2nsf-ikeless 1010 Namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless 1011 Prefix: nsfikels 1012 Reference: RFC XXXX 1014 8. Security Considerations 1016 First of all, this document shares all the security issues of SDN 1017 that are specified in the "Security Considerations" section of 1018 [ITU-T.Y.3300] and [RFC7426]. 1020 On the one hand, it is important to note that there MUST exist a 1021 security association between the I2NSF Controller and the NSFs to 1022 protect the critical information (cryptographic keys, configuration 1023 parameter, etc.) exchanged between these entities. 1025 On the other hand, if encryption is mandatory for all traffic of a 1026 NSF, its default policy MUST be to drop (DISCARD) packets to prevent 1027 cleartext packet leaks. This default policy MUST be pre-configured 1028 in the startup configuration datastore in the NSF before the NSF 1029 contacts the I2NSF Controller. Moreover, the startup configuration 1030 datastore MUST be also pre-configured with the required ALLOW 1031 policies that allow the NSF to communicate with the I2NSF Controller 1032 once the NSF is deployed. This pre-configuration step is not carried 1033 out by the I2NSF Controller but by some other entity before the NSF 1034 deployment. In this manner, when the NSF starts/reboots, it will 1035 always first apply the configuration in the startup configuration 1036 before contacting the I2NSF Controller. 1038 Finally, we have divided this section in two parts in order to 1039 analyze different security considerations for both cases: NSF with 1040 IKEv2 (IKE case) and NSF without IKEv2 (IKE-less case). In general, 1041 the I2NSF Controller, as typically in the SDN paradigm, is a target 1042 for different type of attacks [SDNSecServ] and [SDNSecurity]. Thus, 1043 the I2NSF Controller is a key entity in the infrastructure and MUST 1044 be protected accordingly. In particular, the I2NSF Controller will 1045 handle cryptographic material thus the attacker may try to access 1046 this information. Although we can assume this attack is not likely 1047 to happen due to the assumed security measurements to protect the 1048 I2NSF Controller, it still deserves some analysis in the hypothetical 1049 case that the attack occurs. The impact is different depending on 1050 the IKE case or IKE-less case. 1052 8.1. IKE case 1054 In the IKE case, the I2NSF Controller sends IKEv2 credentials (PSK, 1055 public/private keys, certificates, etc.) to the NSFs using the 1056 security association between I2NSF Controller and NSFs. The I2NSF 1057 Controller MUST NOT store the IKEv2 credentials after distributing 1058 them. Moreover, the NSFs MUST NOT allow the reading of these values 1059 once they have been applied by the I2NSF Controller (i.e. write only 1060 operations). One option is to always return the same value (i.e. all 1061 0s) if a read operation is carried out. 1063 If the attacker has access to the I2NSF Controller during the period 1064 of time that key material is generated, it might have access to the 1065 key material. Since these values are used during NSF authentication 1066 in IKEv2, it may impersonate the affected NSFs. Several 1067 recommendations are important. 1069 o IKEv2 configurations should adhere to the recommendations in 1070 [RFC8247]. 1072 o If PSK authentication is used in IKEv2, the I2NSF Controller MUST 1073 remove the PSK immediately after generating and distributing it. 1075 o When public/private keys are used, the I2NSF Controller MAY 1076 generate both public key and private key. In such a case, the 1077 I2NSF Controller MUST remove the associated private key 1078 immediately after distributing them to the NSFs. Alternatively, 1079 the NSF could generate the private key and export only the public 1080 key to the I2NSF Controller. 1082 o If certificates are used, the NSF MAY generate the private key and 1083 export the public key for certification to the I2NSF Controller. 1084 How the NSF generates these cryptographic material (public key/ 1085 private keys) and exports the public key, is out of scope of this 1086 document. 1088 8.2. IKE-less case 1090 In the IKE-less case, the I2NSF Controller sends the IPsec SA 1091 information to the NSF's SAD that includes the private session keys 1092 required for integrity and encryption. The I2NSF Controller MUST NOT 1093 store the keys after distributing them. Moreover, the NSFs receiving 1094 private key material MUST NOT allow the reading of these values by 1095 any other entity (including the I2NSF Controller itself) once they 1096 have been applied (i.e. write only operations) into the NSFs. 1097 Nevertheless, if the attacker has access to the I2NSF Controller 1098 during the period of time that key material is generated, it may 1099 obtain these values. In other words, the attacker might be able to 1100 observe the IPsec traffic and decrypt, or even modify and re-encrypt, 1101 the traffic between peers. 1103 8.3. YANG modules 1105 The YANG modules specified in this document define a schema for data 1106 that is designed to be accessed via network management protocols such 1107 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 1108 is the secure transport layer, and the mandatory-to-implement secure 1109 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 1110 is HTTPS, and the mandatory-to-implement secure transport is TLS 1111 [RFC8446]. 1113 The Network Configuration Access Control Model (NACM) [RFC8341] 1114 provides the means to restrict access for particular NETCONF or 1115 RESTCONF users to a preconfigured subset of all available NETCONF or 1116 RESTCONF protocol operations and content. 1118 There are a number of data nodes defined in these YANG modules that 1119 are writable/creatable/deletable (i.e., config true, which is the 1120 default). These data nodes may be considered sensitive or vulnerable 1121 in some network environments. Write operations (e.g., edit-config) 1122 to these data nodes without proper protection can have a negative 1123 effect on network operations. These are the subtrees and data nodes 1124 and their sensitivity/vulnerability: 1126 For the IKE case (ietf-i2nsf-ike): 1128 /ipsec-ike: The entire container in this module is sensitive to 1129 write operations. An attacker may add/modify the credentials 1130 to be used for the authentication (e.g. to impersonate a NSF), 1131 the trust root (e.g. changing the trusted CA certificates), the 1132 cryptographic algorithms (allowing a downgrading attack), the 1133 IPsec policies (e.g. by allowing leaking of data traffic by 1134 changing to a allow policy), and in general changing the IKE SA 1135 conditions and credentials between any NSF. 1137 For the IKE-less case (ietf-i2nsf-ikeless): 1139 /ipsec-ikeless: The entire container in this module is 1140 sensitive to write operations. An attacker may add/modify/ 1141 delete any IPsec policies (e.g. by allowing leaking of data 1142 traffic by changing to a allow policy) in the /ipsec-ikeless/ 1143 spd container, and add/modify/delete any IPsec SAs between two 1144 NSF by means of /ipsec-ikeless/sad container and, in general 1145 changing any IPsec SAs and IPsec policies between any NSF. 1147 Some of the readable data nodes in this YANG module may be considered 1148 sensitive or vulnerable in some network environments. It is thus 1149 important to control read access (e.g., via get, get-config, or 1150 notification) to these data nodes. These are the subtrees and data 1151 nodes and their sensitivity/vulnerability: 1153 For the IKE case (ietf-i2nsf-ike): 1155 /ipsec-ike/pad: This container includes sensitive information 1156 to read operations. This information should never be returned 1157 to a client. For example, cryptographic material configured in 1158 the NSFs: peer-authentication/pre-shared/secret and peer- 1159 authentication/digital-signature/private-key are already 1160 protected by the NACM extension "default-deny-all" in this 1161 document. 1163 For the IKE-less case (ietf-i2nsf-ikeless): 1165 /ipsec-ikeless/sad/sad-entry/ipsec-sa-config/esp-sa: This 1166 container includes symmetric keys for the IPsec SAs. For 1167 example, encryption/key contains a ESP encryption key value and 1168 encryption/iv contains a initialization vector value. 1169 Similarly, integrity/key has ESP integrity key value. Those 1170 values must not be read by anyone and are protected by the NACM 1171 extension "default-deny-all" in this document. 1173 9. Acknowledgements 1175 Authors want to thank Paul Wouters, Valery Smyslov, Sowmini Varadhan, 1176 David Carrel, Yoav Nir, Tero Kivinen, Martin Bjorklund, Graham 1177 Bartlett, Sandeep Kampati, Linda Dunbar, Mohit Sethi, Martin 1178 Bjorklund, Tom Petch, Christian Hopps, Rob Wilton, Carlos J. 1179 Bernardos, Alejandro Perez-Mendez, Alejandro Abad-Carrascosa, Ignacio 1180 Martinez, Ruben Ricart and Roman Danyliw for their valuable comments. 1182 10. References 1184 10.1. Normative References 1186 [I-D.draft-ietf-netconf-crypto-types] 1187 Watsen, K., "YANG Data Types and Groupings for 1188 Cryptography", draft-ietf-netconf-crypto-types-18 (work in 1189 progress), August 2020. 1191 [IKEv2-Parameters] 1192 Internet Assigned Numbers Authority (IANA), "Internet Key 1193 Exchange Version 2 (IKEv2) Parameters", August 2020. 1195 [ITU-T.X.690] 1196 "Recommendation ITU-T X.690", August 2015. 1198 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1199 Requirement Levels", BCP 14, RFC 2119, 1200 DOI 10.17487/RFC2119, March 1997, 1201 . 1203 [RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R., and S. 1204 Sataluri, "Using Domains in LDAP/X.500 Distinguished 1205 Names", RFC 2247, DOI 10.17487/RFC2247, January 1998, 1206 . 1208 [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, 1209 "Negotiation of NAT-Traversal in the IKE", RFC 3947, 1210 DOI 10.17487/RFC3947, January 2005, 1211 . 1213 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1214 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 1215 December 2005, . 1217 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1218 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1219 . 1221 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1222 Housley, R., and W. Polk, "Internet X.509 Public Key 1223 Infrastructure Certificate and Certificate Revocation List 1224 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1225 . 1227 [RFC5915] Turner, S. and D. Brown, "Elliptic Curve Private Key 1228 Structure", RFC 5915, DOI 10.17487/RFC5915, June 2010, 1229 . 1231 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1232 the Network Configuration Protocol (NETCONF)", RFC 6020, 1233 DOI 10.17487/RFC6020, October 2010, 1234 . 1236 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1237 and A. Bierman, Ed., "Network Configuration Protocol 1238 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1239 . 1241 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1242 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1243 . 1245 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1246 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1247 . 1249 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 1250 Kivinen, "Internet Key Exchange Protocol Version 2 1251 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 1252 2014, . 1254 [RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2 1255 (IKEv2) Message Fragmentation", RFC 7383, 1256 DOI 10.17487/RFC7383, November 2014, 1257 . 1259 [RFC7427] Kivinen, T. and J. Snyder, "Signature Authentication in 1260 the Internet Key Exchange Version 2 (IKEv2)", RFC 7427, 1261 DOI 10.17487/RFC7427, January 2015, 1262 . 1264 [RFC7619] Smyslov, V. and P. Wouters, "The NULL Authentication 1265 Method in the Internet Key Exchange Protocol Version 2 1266 (IKEv2)", RFC 7619, DOI 10.17487/RFC7619, August 2015, 1267 . 1269 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1270 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1271 . 1273 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 1274 "PKCS #1: RSA Cryptography Specifications Version 2.2", 1275 RFC 8017, DOI 10.17487/RFC8017, November 2016, 1276 . 1278 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1279 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1280 . 1282 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1283 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1284 May 2017, . 1286 [RFC8221] Wouters, P., Migault, D., Mattsson, J., Nir, Y., and T. 1287 Kivinen, "Cryptographic Algorithm Implementation 1288 Requirements and Usage Guidance for Encapsulating Security 1289 Payload (ESP) and Authentication Header (AH)", RFC 8221, 1290 DOI 10.17487/RFC8221, October 2017, 1291 . 1293 [RFC8247] Nir, Y., Kivinen, T., Wouters, P., and D. Migault, 1294 "Algorithm Implementation Requirements and Usage Guidance 1295 for the Internet Key Exchange Protocol Version 2 (IKEv2)", 1296 RFC 8247, DOI 10.17487/RFC8247, September 2017, 1297 . 1299 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1300 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1301 . 1303 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1304 Access Control Model", STD 91, RFC 8341, 1305 DOI 10.17487/RFC8341, March 2018, 1306 . 1308 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1309 and R. Wilton, "Network Management Datastore Architecture 1310 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1311 . 1313 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1314 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1315 . 1317 10.2. Informative References 1319 [I-D.carrel-ipsecme-controller-ike] 1320 Carrel, D. and B. Weiss, "IPsec Key Exchange using a 1321 Controller", draft-carrel-ipsecme-controller-ike-01 (work 1322 in progress), March 2019. 1324 [I-D.tran-ipsecme-yang] 1325 Tran, K., Wang, H., Nagaraj, V., and X. Chen, "Yang Data 1326 Model for Internet Protocol Security (IPsec)", draft-tran- 1327 ipsecme-yang-01 (work in progress), June 2015. 1329 [ITU-T.Y.3300] 1330 "Recommendation ITU-T Y.3300", June 2014. 1332 [libreswan] 1333 The Libreswan Project, "Libreswan VPN software", September 1334 2020. 1336 [netconf-vpn] 1337 Stefan Wallin, "Tutorial: NETCONF and YANG", January 2014. 1339 [ONF-OpenFlow] 1340 ONF, "OpenFlow Switch Specification (Version 1.4.0)", 1341 October 2013. 1343 [ONF-SDN-Architecture] 1344 "SDN Architecture", June 2014. 1346 [RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key 1347 Management API, Version 2", RFC 2367, 1348 DOI 10.17487/RFC2367, July 1998, 1349 . 1351 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1352 DOI 10.17487/RFC3688, January 2004, 1353 . 1355 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 1356 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 1357 RFC 3948, DOI 10.17487/RFC3948, January 2005, 1358 . 1360 [RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and 1361 Internet Key Exchange (IKE) Document Roadmap", RFC 6071, 1362 DOI 10.17487/RFC6071, February 2011, 1363 . 1365 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 1366 "IPv6 Flow Label Specification", RFC 6437, 1367 DOI 10.17487/RFC6437, November 2011, 1368 . 1370 [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined 1371 Networking: A Perspective from within a Service Provider 1372 Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, 1373 . 1375 [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., 1376 Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- 1377 Defined Networking (SDN): Layers and Architecture 1378 Terminology", RFC 7426, DOI 10.17487/RFC7426, January 1379 2015, . 1381 [RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., 1382 and J. Jeong, "Interface to Network Security Functions 1383 (I2NSF): Problem Statement and Use Cases", RFC 8192, 1384 DOI 10.17487/RFC8192, July 2017, 1385 . 1387 [RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation 1388 of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229, 1389 August 2017, . 1391 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 1392 Kumar, "Framework for Interface to Network Security 1393 Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, 1394 . 1396 [SDNSecServ] 1397 Scott-Hayward, S., O'Callaghan, G., and P. Sezer, "SDN 1398 Security: A Survey", 2013. 1400 [SDNSecurity] 1401 Kreutz, D., Ramos, F., and P. Verissimo, "Towards Secure 1402 and Dependable Software-Defined Networks", 2013. 1404 [strongswan] 1405 CESNET, "StrongSwan: the OpenSource IPsec-based VPN 1406 Solution", September 2020. 1408 Appendix A. Common YANG model for IKE and IKE-less cases 1410 This Appendix is Normative. 1412 This YANG module has normative references to [RFC3947], [RFC4301], 1413 [RFC4303], [RFC8174], [RFC8221] and [IKEv2-Parameters]. 1415 This YANG module has informative references to [RFC3948] and 1416 [RFC8229]. 1418 file "ietf-i2nsf-ikec@2020-10-21.yang" 1420 module ietf-i2nsf-ikec { 1421 yang-version 1.1; 1422 namespace "urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikec"; 1423 prefix "nsfikec"; 1425 import ietf-inet-types { 1426 prefix inet; 1427 reference "RFC 6991: Common YANG Data Types"; 1428 } 1430 import ietf-yang-types { 1431 prefix yang; 1432 reference "RFC 6991: Common YANG Data Types"; 1433 } 1435 organization "IETF I2NSF Working Group"; 1437 contact 1438 "WG Web: 1439 WG List: 1441 Author: Rafael Marin-Lopez 1442 1444 Author: Gabriel Lopez-Millan 1445 1447 Author: Fernando Pereniguez-Garcia 1448 1449 "; 1451 description 1452 "Common Data model for the IKE and IKE-less cases 1453 defined by the SDN-based IPsec flow protection service. 1455 Copyright (c) 2020 IETF Trust and the persons 1456 identified as authors of the code. All rights reserved. 1457 Redistribution and use in source and binary forms, with 1458 or without modification, is permitted pursuant to, and 1459 subject to the license terms contained in, the 1460 Simplified BSD License set forth in Section 4.c of the 1461 IETF Trust's Legal Provisions Relating to IETF Documents 1462 (https://trustee.ietf.org/license-info). 1464 This version of this YANG module is part of RFC XXXX;; 1465 see the RFC itself for full legal notices. 1467 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 1468 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 1469 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this 1470 document are to be interpreted as described in BCP 14 1471 (RFC 2119) (RFC 8174) when, and only when, they appear 1472 in all capitals, as shown here."; 1474 revision "2020-10-21" { 1475 description "Initial version."; 1476 reference "RFC XXXX: Software-Defined Networking 1477 (SDN)-based IPsec Flow Protection."; 1478 } 1480 typedef encryption-algorithm-type { 1481 type uint16; 1482 description 1483 "The encryption algorithm is specified with a 16-bit 1484 number extracted from IANA Registry. The acceptable 1485 values MUST follow the requirement levels for 1486 encryption algorithms for ESP and IKEv2."; 1487 reference 1488 "IANA Registry- Transform Type 1 - Encryption 1489 Algorithm Transform IDs. RFC 8221 - Cryptographic 1490 Algorithm Implementation Requirements and Usage 1491 Guidance for Encapsulating Security Payload (ESP) 1492 and Authentication Header (AH) and RFC 8247 - 1493 Algorithm Implementation Requirements and Usage 1494 Guidance for the Internet Key Exchange Protocol 1495 Version 2 (IKEv2)."; 1496 } 1498 typedef integrity-algorithm-type { 1499 type uint16; 1500 description 1501 "The integrity algorithm is specified with a 16-bit 1502 number extracted from IANA Registry. 1504 The acceptable values MUST follow the requirement 1505 levels for encryption algorithms for ESP and IKEv2."; 1506 reference 1507 "IANA Registry- Transform Type 3 - Integrity 1508 Algorithm Transform IDs. RFC 8221 - Cryptographic 1509 Algorithm Implementation Requirements and Usage 1510 Guidance for Encapsulating Security Payload (ESP) 1511 and Authentication Header (AH) and RFC 8247 - 1512 Algorithm Implementation Requirements and Usage 1513 Guidance for the Internet Key Exchange Protocol 1514 Version 2 (IKEv2)."; 1515 } 1517 typedef ipsec-mode { 1518 type enumeration { 1519 enum transport { 1520 description 1521 "IPsec transport mode. No Network Address 1522 Translation (NAT) support."; 1523 } 1524 enum tunnel { 1525 description "IPsec tunnel mode."; 1526 } 1527 } 1528 description 1529 "Type definition of IPsec mode: transport or 1530 tunnel."; 1531 reference 1532 "Section 3.2 in RFC 4301."; 1533 } 1535 typedef esp-encap { 1536 type enumeration { 1537 enum espintcp { 1538 description 1539 "ESP in TCP encapsulation."; 1540 reference 1541 "RFC 8229 - TCP Encapsulation of IKE and 1542 IPsec Packets."; 1543 } 1544 enum espintls { 1545 description 1546 "ESP in TCP encapsulation using TLS."; 1547 reference 1548 "RFC 8229 - TCP Encapsulation of IKE and 1549 IPsec Packets."; 1550 } 1551 enum espinudp { 1552 description 1553 "ESP in UDP encapsulation."; 1554 reference 1555 "RFC 3948 - UDP Encapsulation of IPsec ESP 1556 Packets."; 1557 } 1558 enum none { 1559 description 1560 "NOT ESP encapsulation."; 1561 } 1562 } 1563 description 1564 "Types of ESP encapsulation when Network Address 1565 Translation (NAT) is present between two NSFs."; 1566 reference 1567 "RFC 8229 - TCP Encapsulation of IKE and IPsec 1568 Packets and RFC 3948 - UDP Encapsulation of IPsec 1569 ESP Packets."; 1570 } 1572 typedef ipsec-protocol-parameters { 1573 type enumeration { 1574 enum esp { description "IPsec ESP protocol."; } 1575 } 1576 description 1577 "Only the Encapsulation Security Protocol (ESP) is 1578 supported but it could be extended in the future."; 1579 reference 1580 "RFC 4303- IP Encapsulating Security Payload 1581 (ESP)."; 1583 } 1585 typedef lifetime-action { 1586 type enumeration { 1587 enum terminate-clear { 1588 description 1589 "Terminates the IPsec SA and allows the 1590 packets through."; 1591 } 1592 enum terminate-hold { 1593 description 1594 "Terminates the IPsec SA and drops the 1595 packets."; 1596 } 1597 enum replace { 1598 description 1599 "Replaces the IPsec SA with a new one: 1601 rekey. "; 1602 } 1603 } 1604 description 1605 "When the lifetime of an IPsec SA expires an action 1606 needs to be performed over the IPsec SA that 1607 reached the lifetime. There are three posible 1608 options: terminate-clear, terminate-hold and 1609 replace."; 1610 reference 1611 "Section 4.5 in RFC 4301."; 1612 } 1614 typedef ipsec-traffic-direction { 1615 type enumeration { 1616 enum inbound { 1617 description "Inbound traffic."; 1618 } 1619 enum outbound { 1620 description "Outbound traffic."; 1621 } 1622 } 1623 description 1624 "IPsec traffic direction is defined in two 1625 directions: inbound and outbound. From a NSF 1626 perspective inbound means the traffic that enters 1627 the NSF and outbound is the traffic that is sent 1628 from the NSF."; 1629 reference 1630 "Section 5 in RFC 4301."; 1631 } 1633 typedef ipsec-spd-action { 1634 type enumeration { 1635 enum protect { 1636 description 1637 "PROTECT the traffic with IPsec."; 1638 } 1639 enum bypass { 1640 description 1641 "BYPASS the traffic. The packet is forwarded 1642 without IPsec protection."; 1643 } 1644 enum discard { 1645 description 1646 "DISCARD the traffic. The IP packet is 1647 discarded."; 1648 } 1650 } 1651 description 1652 "The action when traffic matches an IPsec security 1653 policy. According to RFC 4301 there are three 1654 possible values: BYPASS, PROTECT AND DISCARD"; 1655 reference 1656 "Section 4.4.1 in RFC 4301."; 1657 } 1659 typedef ipsec-inner-protocol { 1660 type union { 1661 type uint8; 1662 type enumeration { 1663 enum any { 1664 value 256; 1665 description 1666 "Any IP protocol number value."; 1667 } 1668 } 1669 } 1670 default any; 1671 description 1672 "IPsec protection can be applied to specific IP 1673 traffic and layer 4 traffic (TCP, UDP, SCTP, etc.) 1674 or ANY protocol in the IP packet payload. We 1675 specify the IP protocol number with an uint8 or 1676 ANY defining an enumerate with value 256 to 1677 indicate the protocol number."; 1678 reference 1679 "Section 4.4.1.1 in RFC 4301. 1680 IANA Registry - Protocol Numbers."; 1681 } 1683 grouping encap { 1684 description 1685 "This group of nodes allows to define the type of 1686 encapsulation in case NAT traversal is 1687 required and port information."; 1688 leaf espencap { 1689 type esp-encap; 1690 default none; 1691 description 1692 "ESP in TCP, ESP in UDP or ESP in TLS."; 1693 } 1694 leaf sport { 1695 type inet:port-number; 1696 default 4500; 1697 description 1698 "Encapsulation source port."; 1699 } 1700 leaf dport { 1701 type inet:port-number; 1702 default 4500; 1703 description 1704 "Encapsulation destination port."; 1705 } 1707 leaf-list oaddr { 1708 type inet:ip-address; 1709 description 1710 "If required, this is the original address that 1711 was used before NAT was applied over the Packet. 1712 "; 1713 } 1714 reference 1715 "RFC 3947 and RFC 8229."; 1716 } 1718 grouping lifetime { 1719 description 1720 "Different lifetime values limited to an IPsec SA."; 1721 leaf time { 1722 type uint32; 1723 default 0; 1724 description 1725 "Time in seconds since the IPsec SA was added. 1726 For example, if this value is 180 seconds it 1727 means the IPsec SA expires in 180 seconds since 1728 it was added. The value 0 implies infinite."; 1729 } 1730 leaf bytes { 1731 type uint32; 1732 default 0; 1733 description 1734 "If the IPsec SA processes the number of bytes 1735 expressed in this leaf, the IPsec SA expires and 1736 should be rekeyed. The value 0 implies 1737 infinite."; 1738 } 1739 leaf packets { 1740 type uint32; 1741 default 0; 1742 description 1743 "If the IPsec SA processes the number of packets 1744 expressed in this leaf, the IPsec SA expires and 1745 should be rekeyed. The value 0 implies 1746 infinite."; 1747 } 1748 leaf idle { 1749 type uint32; 1750 default 0; 1751 description 1752 "When a NSF stores an IPsec SA, it 1753 consumes system resources. In an idle NSF this 1754 is a waste of resources. If the IPsec SA is idle 1755 during this number of seconds the IPsec SA 1756 should be removed. The value 0 implies 1757 infinite."; 1758 } 1759 reference 1760 "Section 4.4.2.1 in RFC 4301."; 1762 } 1764 grouping port-range { 1765 description 1766 "This grouping defines a port range, such as 1767 expressed in RFC 4301. For example: 1500 (Start 1768 Port Number)-1600 (End Port Number). 1769 A port range is used in the Traffic Selector."; 1771 leaf start { 1772 type inet:port-number; 1773 description "Start port number."; 1774 } 1775 leaf end { 1776 type inet:port-number; 1777 description 1778 "End port number. The assigned value must be 1779 equal or greater than the start port number. 1780 To express a single port, set the same value 1781 as start and end."; 1782 } 1783 reference "Section 4.4.1.2 in RFC 4301."; 1784 } 1786 grouping tunnel-grouping { 1787 description 1788 "The parameters required to define the IP tunnel 1789 endpoints when IPsec SA requires tunnel mode. The 1790 tunnel is defined by two endpoints: the local IP 1791 address and the remote IP address."; 1793 leaf local { 1794 type inet:ip-address; 1795 mandatory true; 1796 description 1797 "Local IP address' tunnel endpoint."; 1798 } 1799 leaf remote { 1800 type inet:ip-address; 1801 mandatory true; 1802 description 1803 "Remote IP address' tunnel endpoint."; 1804 } 1805 leaf df-bit { 1806 type enumeration { 1807 enum clear { 1808 description 1809 "Disable the DF (Don't Fragment) bit 1810 from the outer header. This is the 1811 default value."; 1812 } 1813 enum set { 1814 description 1815 "Enable the DF bit in the outer header."; 1816 } 1817 enum copy { 1818 description 1819 "Copy the DF bit to the outer header."; 1820 } 1821 } 1822 default clear; 1823 description 1824 "Allow configuring the DF bit when encapsulating 1825 tunnel mode IPsec traffic. RFC 4301 describes 1826 three options to handle the DF bit during 1827 tunnel encapsulation: clear, set and copy from 1828 the inner IP header."; 1829 reference 1830 "Section 8.1 in RFC 4301."; 1831 } 1832 leaf bypass-dscp { 1833 type boolean; 1834 default true; 1835 description 1836 "If DSCP (Differentiated Services Code Point) 1837 values in the inner header have to be used to 1838 select one IPsec SA among several that match 1839 the traffic selectors for an outbound packet"; 1840 reference 1841 "Section 4.4.2.1. in RFC 4301."; 1843 } 1844 leaf dscp-mapping { 1845 type yang:hex-string; 1846 default "00:00:00:00:00:00"; 1847 description 1848 "DSCP values allowed for packets carried over 1849 this IPsec SA."; 1850 reference 1851 "Section 4.4.2.1. in RFC 4301."; 1852 } 1853 leaf ecn { 1854 type boolean; 1855 default false; 1856 description 1857 "Explicit Congestion Notification (ECN). If true 1858 copy CE bits to inner header."; 1859 reference 1860 "Section 5.1.2 and Annex C in RFC 4301."; 1861 } 1862 } 1864 grouping selector-grouping { 1865 description 1866 "This grouping contains the definition of a Traffic 1867 Selector, which is used in the IPsec policies and 1868 IPsec SAs."; 1870 leaf local-subnet { 1871 type inet:ip-prefix; 1872 mandatory true; 1873 description 1874 "Local IP address subnet."; 1875 } 1876 leaf remote-subnet { 1877 type inet:ip-prefix; 1878 mandatory true; 1879 description 1880 "Remote IP address subnet."; 1881 } 1882 leaf inner-protocol { 1883 type ipsec-inner-protocol; 1884 default any; 1885 description 1886 "Inner Protocol that is going to be 1887 protected with IPsec."; 1888 } 1889 list local-ports { 1890 key "start end"; 1891 uses port-range; 1892 description 1893 "List of local ports. When the inner 1894 protocol is ICMP this 16 bit value 1895 represents code and type. 1896 If this list is not defined 1897 it is assumed that start and 1898 end are 0 by default (any port)."; 1899 } 1900 list remote-ports { 1901 key "start end"; 1902 uses port-range; 1903 description 1904 "List of remote ports. When the upper layer 1905 protocol is ICMP this 16 bit value represents 1906 code and type.If this list is not defined 1907 it is assumed that start and end are 0 by 1908 default (any port)"; 1909 } 1910 reference 1911 "Section 4.4.1.2 in RFC 4301."; 1912 } 1914 grouping ipsec-policy-grouping { 1915 description 1916 "Holds configuration information for an IPsec SPD 1917 entry."; 1919 leaf anti-replay-window { 1920 type uint64; 1921 default 32; 1922 description 1923 "A 64-bit counter used to determine whether an 1924 inbound ESP packet is a replay."; 1925 reference 1926 "Section 4.4.2.1 in RFC 4301."; 1927 } 1928 container traffic-selector { 1929 description 1930 "Packets are selected for 1931 processing actions based on the IP and inner 1932 protocol header information, selectors, 1933 matched against entries in the SPD."; 1934 uses selector-grouping; 1935 reference 1936 "Section 4.4.4.1 in RFC 4301."; 1937 } 1938 container processing-info { 1939 description 1940 "SPD processing. If the required processing 1941 action is protect, it contains the required 1942 information to process the packet."; 1943 leaf action { 1944 type ipsec-spd-action; 1945 default discard; 1946 description 1947 "If bypass or discard, container 1948 ipsec-sa-cfg is empty."; 1949 } 1950 container ipsec-sa-cfg { 1951 when "../action = 'protect'"; 1952 description 1953 "IPsec SA configuration included in the SPD 1954 entry."; 1955 leaf pfp-flag { 1956 type boolean; 1957 default false; 1958 description 1959 "Each selector has a Populate From 1960 Packet (PFP) flag. If asserted for a 1961 given selector X, the flag indicates 1962 that the IPsec SA to be created should 1963 take its value (local IP address, 1964 remote IP address, Next Layer 1965 Protocol, etc.) for X from the value 1966 in the packet. Otherwise, the IPsec SA 1967 should take its value(s) for X from 1968 the value(s) in the SPD entry."; 1969 } 1970 leaf ext-seq-num { 1971 type boolean; 1972 default false; 1973 description 1974 "True if this IPsec SA is using extended 1975 sequence numbers. True 64 bit counter, 1976 False 32 bit."; 1977 } 1978 leaf seq-overflow { 1979 type boolean; 1980 default false; 1981 description 1982 "The flag indicating whether 1983 overflow of the sequence number 1984 counter should prevent transmission 1985 of additional packets on the IPsec 1986 SA (false) and, therefore needs to 1987 be rekeyed, or whether rollover is 1988 permitted (true). If Authenticated 1989 Encryption with Associated Data 1990 (AEAD) is used this flag MUST be 1991 false."; 1992 } 1993 leaf stateful-frag-check { 1994 type boolean; 1995 default false; 1996 description 1997 "Indicates whether (true) or not (false) 1998 stateful fragment checking applies to 1999 the IPsec SA to be created."; 2000 } 2001 leaf mode { 2002 type ipsec-mode; 2003 default transport; 2004 description 2005 "IPsec SA has to be processed in 2006 transport or tunnel mode."; 2007 } 2008 leaf protocol-parameters { 2009 type ipsec-protocol-parameters; 2010 default esp; 2011 description 2012 "Security protocol of the IPsec SA: 2013 Only ESP is supported but it could be 2014 extended in the future."; 2015 } 2016 container esp-algorithms { 2017 when "../protocol-parameters = 'esp'"; 2018 description 2019 "Configuration of Encapsulating 2020 Security Payload (ESP) parameters and 2021 algorithms."; 2023 leaf-list integrity { 2024 type integrity-algorithm-type; 2025 default 0; 2026 ordered-by user; 2027 description 2028 "Configuration of ESP authentication 2029 based on the specified integrity 2030 algorithm. With AEAD algorithms, 2031 the integrity node is not 2032 used."; 2033 reference 2034 "Section 3.2 in RFC 4303."; 2036 } 2037 list encryption { 2038 key id; 2039 ordered-by user; 2040 leaf id { 2041 type uint8; 2042 description 2043 "The index of list with the 2044 different encryption algorithms and 2045 its key-length (if required)."; 2046 } 2047 leaf algorithm-type { 2048 type nsfikec:encryption-algorithm-type; 2049 default 20; 2050 description 2051 "Default value 20 (ENCR_AES_GCM_16)"; 2052 } 2053 leaf key-length { 2054 type uint16; 2055 default 128; 2056 description 2057 "By default key length is 128 2058 bits"; 2059 } 2060 description 2061 "Encryption or AEAD algorithm for the 2062 IPsec SAs. This list is ordered 2063 following from the higher priority to 2064 lower priority. First node of the 2065 list will be the algorithm with 2066 higher priority. In case the list 2067 is empty, then 2068 no encryption algorithm 2069 is applied (NULL)."; 2070 reference 2071 "Section 3.2 in RFC 4303."; 2072 } 2074 leaf tfc-pad { 2075 type boolean; 2076 default false; 2077 description 2078 "If Traffic Flow Confidentiality 2079 (TFC) padding for ESP encryption 2080 can be used (true) or not (false)"; 2081 reference 2082 "Section 2.7 in RFC 4303."; 2083 } 2084 reference 2085 "RFC 4303."; 2086 } 2087 container tunnel { 2088 when "../mode = 'tunnel'"; 2089 uses tunnel-grouping; 2090 description 2091 "IPsec tunnel endpoints definition."; 2092 } 2093 } 2094 reference 2095 "Section 4.4.1.2 in RFC 4301."; 2096 } 2097 container spd-mark { 2098 description 2099 "The Mark to set for the IPsec SA of this 2100 connection. This option is only available 2101 on linux NETKEY/XFRM kernels. It can be 2102 used with iptables to create custom 2103 iptables rules using CONNMARK. It can also 2104 be used with Virtual Tunnel Interfaces 2105 (VTI) to direct marked traffic to 2106 specific vtiXX devices."; 2107 leaf mark { 2108 type uint32; 2109 default 0; 2110 description 2111 "Mark used to match XFRM policies and 2112 states."; 2113 } 2114 leaf mask { 2115 type yang:hex-string; 2116 default 00:00:00:00; 2117 description 2118 "Mask used to match XFRM policies and 2119 states."; 2120 } 2121 } 2122 } 2123 } 2125 2127 Appendix B. YANG model for IKE case 2129 This Appendix is Normative. 2131 This YANG module has normative references to [RFC2247], [RFC5280], 2132 [RFC4301], [RFC5280], [RFC5915], [RFC6991], [RFC7296], [RFC7383], 2133 [RFC7427], [RFC7619], [RFC8017], [RFC8174], [RFC8341], [ITU-T.X.690], 2134 [I-D.draft-ietf-netconf-crypto-types] and [IKEv2-Parameters]. 2136 This YANG module has informative references to [RFC8229]. 2138 file "ietf-i2nsf-ike@2020-10-21.yang" 2140 module ietf-i2nsf-ike { 2141 yang-version 1.1; 2142 namespace "urn:ietf:params:xml:ns:yang:ietf-i2nsf-ike"; 2143 prefix "nsfike"; 2145 import ietf-inet-types { 2146 prefix inet; 2147 reference "RFC 6991: Common YANG Data Types"; 2148 } 2150 import ietf-yang-types { 2151 prefix yang; 2152 reference "RFC 6991: Common YANG Data Types"; 2153 } 2155 import ietf-crypto-types { 2156 prefix ct; 2157 reference "RFC XXXX: YANG Data Types and Groupings 2158 for Cryptography."; 2159 } 2161 import ietf-i2nsf-ikec { 2162 prefix nsfikec; 2163 reference 2164 "Common Data model for SDN-based IPsec 2165 configuration."; 2166 } 2168 import ietf-netconf-acm { 2169 prefix nacm; 2170 reference 2171 "RFC 8341: Network Configuration Access Control 2172 Model."; 2174 } 2176 organization "IETF I2NSF Working Group"; 2178 contact 2179 "WG Web: 2180 WG List: 2182 Author: Rafael Marin-Lopez 2183 2185 Author: Gabriel Lopez-Millan 2186 2188 Author: Fernando Pereniguez-Garcia 2189 2190 "; 2192 description 2194 "This module contains IPsec IKE case model for the SDN-based 2195 IPsec flow protection service. An NSF will implement this 2196 module. 2198 Copyright (c) 2020 IETF Trust and the persons identified as 2199 authors of the code. All rights reserved. 2201 Redistribution and use in source and binary forms, with or 2202 without modification, is permitted pursuant to, and subject 2203 to the license terms contained in, the Simplified BSD License 2204 set forth in Section 4.c of the IETF Trust's Legal Provisions 2205 Relating to IETF Documents 2206 (http://trustee.ietf.org/license-info). 2208 This version of this YANG module is part of RFC XXXX; see 2209 the RFC itself for full legal notices. 2211 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 2212 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 2213 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this 2214 document are to be interpreted as described in BCP 14 2215 (RFC 2119) (RFC 8174) when, and only when, they appear 2216 in all capitals, as shown here."; 2218 revision "2020-10-21" { 2219 description "Initial version."; 2220 reference "RFC XXXX: Software-Defined Networking 2221 (SDN)-based IPsec Flow Protection."; 2223 } 2225 typedef ike-spi { 2226 type uint64 { range "0..max"; } 2227 description 2228 "Security Parameter Index (SPI)'s IKE SA."; 2229 reference 2230 "Section 2.6 in RFC 7296."; 2231 } 2233 typedef autostartup-type { 2234 type enumeration { 2235 enum add { 2236 description 2237 "IKE/IPsec configuration is only loaded into 2238 IKE implementation but IKE/IPsec SA is not 2239 started."; 2240 } 2241 enum on-demand { 2242 description 2243 "IKE/IPsec configuration is loaded 2244 into IKE implementation. The IPsec policies 2245 are transferred to the NSF's kernel but the 2246 IPsec SAs are not established immediately. 2247 The IKE implementation will negotiate the 2248 IPsec SAs when the NSF's kernel requests it 2249 (i.e. through an ACQUIRE notification)."; 2250 } 2251 enum start { 2252 description "IKE/IPsec configuration is loaded 2253 and transferred to the NSF's kernel, and the 2254 IKEv2 based IPsec SAs are established 2255 immediately without waiting any packet."; 2256 } 2257 } 2258 description 2259 "Different policies to set IPsec SA configuration 2260 into NSF's kernel when IKEv2 implementation has 2261 started."; 2262 } 2264 typedef pfs-group { 2265 type uint16; 2266 description 2267 "DH groups for IKE and IPsec SA rekey."; 2268 reference 2269 "Section 3.3.2 in RFC 7296. Transform Type 4 - 2270 Diffie-Hellman Group Transform IDs in IANA Registry 2271 - Internet Key Exchange Version 2 (IKEv2) 2272 Parameters."; 2273 } 2275 typedef auth-protocol-type { 2276 type enumeration { 2277 enum ikev2 { 2278 value 2; 2279 description 2280 "IKEv2 authentication protocol. It is the 2281 only defined right now. An enum is used for 2282 further extensibility."; 2283 } 2284 } 2285 description 2286 "IKE authentication protocol version specified in the 2287 Peer Authorization Database (PAD). It is defined as 2288 enumerate to allow new IKE versions in the 2289 future."; 2290 reference 2291 "RFC 7296."; 2292 } 2294 typedef auth-method-type { 2295 type enumeration { 2296 enum pre-shared { 2297 description 2298 "Select pre-shared key as the 2299 authentication method."; 2300 reference 2301 "RFC 7296."; 2302 } 2303 enum eap { 2304 description 2305 "Select EAP as the authentication method."; 2306 reference 2307 "RFC 7296."; 2308 } 2309 enum digital-signature { 2310 description 2311 "Select digital signature method."; 2312 reference 2313 "RFC 7296 and RFC 7427."; 2314 } 2315 enum null { 2316 description 2317 "Null authentication."; 2318 reference 2319 "RFC 7619."; 2320 } 2322 } 2323 description 2324 "Peer authentication method specified in the Peer 2325 Authorization Database (PAD)."; 2326 } 2328 container ipsec-ike { 2329 description 2330 "IKE configuration for a NSF. It includes PAD 2331 parameters, IKE connections information and state 2332 data."; 2334 container pad { 2335 description 2336 "Configuration of Peer Authorization Database 2337 (PAD). The PAD contains information about IKE 2338 peer (local and remote). Therefore, the Security 2339 Controller also stores authentication 2340 information for this NSF and can include 2341 several entries for the local NSF not only 2342 remote peers. Storing local and remote 2343 information makes possible to specify that this 2344 NSF with identity A will use some particular 2345 authentication with remote NSF with identity B 2346 and what are the authentication mechanisms 2347 allowed to B."; 2348 list pad-entry { 2349 key "name"; 2350 ordered-by user; 2351 description 2352 "Peer Authorization Database (PAD) entry. It 2353 is a list of PAD entries ordered by the 2354 I2NSF Controller."; 2355 leaf name { 2356 type string; 2357 description 2358 "PAD unique name to identify this 2359 entry."; 2360 } 2361 choice identity { 2362 mandatory true; 2363 description 2364 "A particular IKE peer will be 2365 identified by one of these identities. 2366 This peer can be a remote peer or local 2367 peer (this NSF)."; 2368 reference 2369 "Section 4.4.3.1 in RFC 4301."; 2370 case ipv4-address{ 2371 leaf ipv4-address { 2372 type inet:ipv4-address; 2373 description 2374 "Specifies the identity as a 2375 single four (4) octet."; 2376 } 2377 } 2378 case ipv6-address{ 2379 leaf ipv6-address { 2380 type inet:ipv6-address; 2381 description 2382 "Specifies the identity as a 2383 single sixteen (16) octet IPv6 2384 address. An example is 2385 2001:DB8:0:0:8:800:200C:417A."; 2386 } 2387 } 2388 case fqdn-string { 2389 leaf fqdn-string { 2390 type inet:domain-name; 2391 description 2392 "Specifies the identity as a 2393 Fully-QualifiedDomain Name 2394 (FQDN) string. An example is: 2395 example.com. The string MUST 2396 NOT contain any terminators 2397 (e.g., NULL, CR, etc.)."; 2398 } 2399 } 2400 case rfc822-address-string { 2401 leaf rfc822-address-string { 2402 type string; 2403 description 2404 "Specifies the identity as a 2405 fully-qualified RFC822 email 2406 address string. An example is, 2407 jsmith@example.com. The string 2408 MUST NOT contain any 2409 terminators e.g., NULL, CR, 2410 etc.)."; 2411 reference 2412 "RFC 822."; 2413 } 2414 } 2415 case dnx509 { 2416 leaf dnx509 { 2417 type string; 2418 description 2419 "Specifies the identity as a 2420 ASN.1 X.500 Distinguished 2421 Name. An example is 2422 C=US,O=Example 2423 Organisation,CN=John Smith."; 2424 reference 2425 "RFC 2247."; 2426 } 2427 } 2428 case gnx509 { 2429 leaf gnx509 { 2430 type string; 2431 description 2432 "ASN.1 X.509 GeneralName. RFC 2433 5280."; 2434 } 2435 } 2436 case id-key { 2437 leaf id-key { 2438 type string; 2439 description 2440 "Opaque octet stream that may be 2441 used to pass vendor-specific 2442 information for proprietary 2443 types of identification."; 2444 reference 2445 "Section 3.5 in RFC 7296."; 2446 } 2447 } 2448 case id-null { 2449 leaf id-null { 2450 type empty; 2451 description 2452 "ID_NULL identification used 2453 when IKE identification payload 2454 is not used." ; 2455 reference 2456 "RFC 7619."; 2457 } 2458 } 2459 } 2460 leaf auth-protocol { 2461 type auth-protocol-type; 2462 default ikev2; 2463 description 2464 "Only IKEv2 is supported right now but 2465 other authentication protocols may be 2466 supported in the future."; 2467 } 2468 container peer-authentication { 2469 description 2470 "This container allows the Security 2471 Controller to configure the 2472 authentication method (pre-shared key, 2473 eap, digitial-signature, null) that 2474 will use a particular peer and the 2475 credentials, which will depend on the 2476 selected authentication method."; 2477 leaf auth-method { 2478 type auth-method-type; 2479 default pre-shared; 2480 description 2481 "Type of authentication method 2482 (pre-shared, eap, digital signature, 2483 null)."; 2484 reference 2485 "Section 2.15 in RFC 7296."; 2486 } 2487 container eap-method { 2488 when "../auth-method = 'eap'"; 2489 leaf eap-type { 2490 type uint8; 2491 mandatory true; 2492 description 2493 "EAP method type. This 2494 information provides the 2495 particular EAP method to be 2496 used. Depending on the EAP 2497 method, pre-shared keys or 2498 certificates may be used."; 2499 } 2500 description 2501 "EAP method description used when 2502 authentication method is 'eap'."; 2503 reference 2504 "Section 2.16 in RFC 7296."; 2505 } 2506 container pre-shared { 2507 when 2508 "../auth-method[.='pre-shared' or 2509 .='eap']"; 2510 leaf secret { 2511 nacm:default-deny-all; 2512 type yang:hex-string; 2513 mandatory true; 2514 description 2515 "Pre-shared secret value. The 2516 NSF has to prevent read access 2517 to this value for security 2518 reasons."; 2519 } 2520 description 2521 "Shared secret value for PSK or 2522 EAP method authentication based on 2523 PSK."; 2524 } 2525 container digital-signature { 2526 when 2527 "../auth-method[.='digital-signature' 2528 or .='eap']"; 2529 leaf ds-algorithm { 2530 type uint8; 2531 default 1; 2532 description 2533 "The digital signature 2534 algorithm is specified with a 2535 value extracted from the IANA 2536 Registry. Depending on the 2537 algorithm, the following leafs 2538 must contain information. For 2539 example if digital signature 2540 involves a certificate then leaf 2541 'cert-data' and 'private-key' 2542 will contain this information."; 2543 reference 2544 "IKEv2 Authentication Method - 2545 IANA Registry - Internet Key 2546 Exchange Version 2 (IKEv2) 2547 Parameters."; 2548 } 2550 choice public-key { 2551 mandatory true; 2552 leaf raw-public-key { 2553 type binary; 2554 description 2555 "A binary that contains the 2556 value of the public key. The 2557 interpretation of the content 2558 is defined by the digital 2559 signature algorithm. For 2560 example, an RSA key is 2561 represented as RSAPublicKey as 2562 defined in RFC 8017, and an 2563 Elliptic Curve Cryptography 2564 (ECC) key is represented 2565 using the 'publicKey' 2566 described in RFC 5915."; 2567 reference 2568 "RFC XXXX: YANG Data Types and 2569 Groupings for Cryptography."; 2570 } 2572 leaf cert-data { 2573 type ct:x509; 2574 description 2575 "X.509 certificate data - 2576 PEM4. If raw-public-key 2577 is defined this leaf is 2578 empty."; 2579 reference 2580 "RFC XXXX: YANG Data Types and 2581 Groupings for Cryptography."; 2582 } 2584 description 2585 "If the I2NSF Controller 2586 knows that the NSF 2587 already owns a private key 2588 associated to this public key 2589 (the NSF generated the pair 2590 public key/private key out of 2591 band), it will only configure 2592 one of the leaf of this 2593 choice but not the leaf 2594 private-key. The NSF, based on 2595 the public key value, can know 2596 the private key to be used."; 2597 } 2598 leaf private-key { 2599 nacm:default-deny-all; 2600 type binary; 2601 description 2602 "A binary that contains the 2603 value of the private key. The 2604 interpretation of the content 2605 is defined by the digital 2606 signature algorithm. For 2607 example, an RSA key is 2608 represented as RSAPrivateKey as 2609 defined in RFC 8017, and an 2610 Elliptic Curve Cryptography 2611 (ECC) key is represented as 2612 ECPrivateKey as defined in RFC 2613 5915. This value is set 2614 if public-key is defined and 2615 I2NSF controller is in charge 2616 of configuring the 2617 private-key. Otherwise, it is 2618 not set and the value is 2619 kept in secret."; 2620 reference 2621 "RFC XXXX: YANG Data Types and 2622 Groupings for Cryptography."; 2623 } 2624 leaf-list ca-data { 2625 type ct:x509; 2626 description 2627 "List of trusted Certification 2628 Authorities (CA) certificates 2629 encoded using ASN.1 2630 distinguished encoding rules 2631 (DER). If it is not defined 2632 the default value is empty."; 2633 reference 2634 "RFC XXXX: YANG Data Types and 2635 Groupings for Cryptography."; 2636 } 2637 leaf crl-data { 2638 type ct:crl; 2639 description 2640 "A CertificateList structure, as 2641 specified in RFC 5280, 2642 encoded using ASN.1 2643 distinguished encoding rules 2644 (DER),as specified in ITU-T 2645 X.690. If it is not defined 2646 the default value is empty."; 2647 reference 2648 "RFC XXXX: YANG Data Types and 2649 Groupings for Cryptography."; 2650 } 2651 leaf crl-uri { 2652 type inet:uri; 2653 description 2654 "X.509 CRL certificate URI. 2656 If it is not defined 2657 the default value is empty."; 2658 } 2659 leaf oscp-uri { 2660 type inet:uri; 2661 description 2662 "OCSP URI. 2663 If it is not defined 2664 the default value is empty."; 2665 } 2666 description 2667 "Digital Signature container."; 2669 } /*container digital-signature*/ 2670 } /*container peer-authentication*/ 2671 } 2672 } 2674 list conn-entry { 2675 key "name"; 2676 description 2677 "IKE peer connection information. This list 2678 contains the IKE connection for this peer 2679 with other peers. This will be translated in 2680 real time by IKE Security Associations 2681 established with these nodes."; 2682 leaf name { 2683 type string; 2684 description 2685 "Identifier for this connection 2686 entry."; 2687 } 2688 leaf autostartup { 2689 type autostartup-type; 2690 default add; 2691 description 2692 "By-default: Only add configuration 2693 without starting the security 2694 association."; 2695 } 2696 leaf initial-contact { 2697 type boolean; 2698 default false; 2699 description 2700 "The goal of this value is to deactivate the 2701 usage of INITIAL_CONTACT notification 2702 (true). If this flag remains to false it 2703 means the usage of the INITIAL_CONTACT 2704 notification will depend on the IKEv2 2705 implementation."; 2706 } 2707 leaf version { 2708 type auth-protocol-type; 2709 default ikev2; 2710 description 2711 "IKE version. Only version 2 is supported 2712 so far."; 2713 } 2714 leaf fragmentation { 2715 type boolean; 2716 default false; 2717 description 2718 "Whether or not to enable IKE 2719 fragmentation as per RFC 7383 (true or 2720 false)."; 2721 reference 2722 "RFC 7383."; 2723 } 2724 container ike-sa-lifetime-soft { 2725 description 2726 "IKE SA lifetime soft. Two lifetime values 2727 can be configured: either rekey time of the 2728 IKE SA or reauth time of the IKE SA. When 2729 the rekey lifetime expires a rekey of the 2730 IKE SA starts. When reauth lifetime 2731 expires a IKE SA reauthentication starts."; 2732 leaf rekey-time { 2733 type uint32; 2734 default 0; 2735 description 2736 "Time in seconds between each IKE SA 2737 rekey.The value 0 means infinite."; 2738 } 2739 leaf reauth-time { 2740 type uint32; 2741 default 0; 2742 description 2743 "Time in seconds between each IKE SA 2744 reauthentication. The value 0 means 2745 infinite."; 2746 } 2747 reference 2748 "Section 2.8 in RFC 7296."; 2749 } 2750 container ike-sa-lifetime-hard { 2751 description 2752 "Hard IKE SA lifetime. When this 2753 time is reached the IKE SA is removed."; 2754 leaf over-time { 2755 type uint32; 2756 default 0; 2757 description 2758 "Time in seconds before the IKE SA is 2759 removed. The value 0 means infinite."; 2760 } 2761 reference 2762 "RFC 7296."; 2763 } 2764 leaf-list authalg { 2765 type nsfikec:integrity-algorithm-type; 2766 default 12; 2767 ordered-by user; 2768 description 2769 "Authentication algorithm for establishing 2770 the IKE SA. This list is ordered following 2771 from the higher priority to lower priority. 2772 First node of the list will be the algorithm 2773 with higher priority."; 2774 } 2776 list encalg { 2777 key id; 2778 min-elements 1; 2779 ordered-by user; 2780 leaf id { 2781 type uint8; 2782 description 2783 "The index of the list with the 2784 different encryption algorithms and its 2785 key-length (if required). E.g. AES-CBC, 2786 128 bits"; 2787 } 2788 leaf algorithm-type { 2789 type nsfikec:encryption-algorithm-type; 2790 default 12; 2791 description 2792 "Default value 12 (ENCR_AES_CBC)"; 2793 } 2794 leaf key-length { 2795 type uint16; 2796 default 128; 2797 description 2798 "By default key length is 128 bits"; 2799 } 2800 description 2801 "Encryption or AEAD algorithm for the IKE 2802 SAs. This list is ordered following 2803 from the higher priority to lower priority. 2804 First node of the list will be the algorithm 2805 with higher priority."; 2806 } 2807 leaf dh-group { 2808 type pfs-group; 2809 default 14; 2810 description 2811 "Group number for Diffie-Hellman 2812 Exponentiation used during IKE_SA_INIT 2813 for the IKE SA key exchange."; 2814 } 2815 leaf half-open-ike-sa-timer { 2816 type uint32; 2817 default 0; 2818 description 2819 "Set the half-open IKE SA timeout 2820 duration."; 2821 reference 2822 "Section 2 in RFC 7296."; 2823 } 2825 leaf half-open-ike-sa-cookie-threshold { 2826 type uint32; 2827 default 0; 2828 description 2829 "Number of half-open IKE SAs that activate 2830 the cookie mechanism." ; 2831 reference 2832 "Section 2.6 in RFC 7296."; 2833 } 2834 container local { 2835 leaf local-pad-entry-name { 2836 type string; 2837 mandatory true; 2838 description 2839 "Local peer authentication information. 2840 This node points to a specific entry in 2841 the PAD where the authorization 2842 information about this particular local 2843 peer is stored. It MUST match a 2844 pad-entry-name."; 2845 } 2846 description 2847 "Local peer authentication information."; 2849 } 2850 container remote { 2851 leaf remote-pad-entry-name { 2852 type string; 2853 mandatory true; 2854 description 2855 "Remote peer authentication information. 2856 This node points to a specific entry in 2857 the PAD where the authorization 2858 information about this particular 2859 remote peer is stored. It MUST match a 2860 pad-entry-name."; 2861 } 2862 description 2863 "Remote peer authentication information."; 2864 } 2865 container encapsulation-type 2866 { 2867 uses nsfikec:encap; 2868 description 2869 "This container carries configuration 2870 information about the source and destination 2871 ports of encapsulation that IKE should use 2872 and the type of encapsulation that 2873 should use when NAT traversal is required. 2874 However, this is just a best effort since 2875 the IKE implementation may need to use a 2876 different encapsulation as 2877 described in RFC 8229."; 2878 reference 2879 "RFC 8229."; 2880 } 2881 container spd { 2882 description 2883 "Configuration of the Security Policy 2884 Database (SPD). This main information is 2885 placed in the grouping 2886 ipsec-policy-grouping."; 2887 list spd-entry { 2888 key "name"; 2889 ordered-by user; 2890 leaf name { 2891 type string; 2892 description 2893 "SPD entry unique name to identify 2894 the IPsec policy."; 2895 } 2896 container ipsec-policy-config { 2897 description 2898 "This container carries the 2899 configuration of a IPsec policy."; 2900 uses nsfikec:ipsec-policy-grouping; 2901 } 2902 description 2903 "List of entries which will constitute 2904 the representation of the SPD. Since we 2905 have IKE in this case, it is only 2906 required to send a IPsec policy from 2907 this NSF where 'local' is this NSF and 2908 'remote' the other NSF. The IKE 2909 implementation will install IPsec 2910 policies in the NSF's kernel in both 2911 directions (inbound and outbound) and 2912 their corresponding IPsec SAs based on 2913 the information in this SPD entry."; 2914 } 2915 reference 2916 "Section 2.9 in RFC 7296."; 2917 } 2918 container child-sa-info { 2919 leaf-list pfs-groups { 2920 type pfs-group; 2921 default 0; 2922 ordered-by user; 2923 description 2924 "If non-zero, it is required perfect 2925 forward secrecy when requesting new 2926 IPsec SA. The non-zero value is 2927 the required group number. This list is 2928 ordered following from the higher 2929 priority to lower priority. First node 2930 of the list will be the algorithm 2931 with higher priority."; 2932 } 2933 container child-sa-lifetime-soft { 2934 description 2935 "Soft IPsec SA lifetime soft. 2936 After the lifetime the action is 2937 defined in this container 2938 in the leaf action."; 2939 uses nsfikec:lifetime; 2940 leaf action { 2941 type nsfikec:lifetime-action; 2942 default replace; 2943 description 2944 "When the lifetime of an IPsec SA 2945 expires an action needs to be 2946 performed over the IPsec SA that 2947 reached the lifetime. There are 2948 three possible options: 2949 terminate-clear, terminate-hold and 2950 replace."; 2951 reference 2952 "Section 4.5 in RFC 4301 and Section 2.8 2953 in RFC 7296."; 2954 } 2955 } 2956 container child-sa-lifetime-hard { 2957 description 2958 "IPsec SA lifetime hard. The action will 2959 be to terminate the IPsec SA."; 2960 uses nsfikec:lifetime; 2961 reference 2962 "Section 2.8 in RFC 7296."; 2963 } 2964 description 2965 "Specific information for IPsec SAs 2966 SAs. It includes PFS group and IPsec SAs 2967 rekey lifetimes."; 2968 } 2969 container state { 2970 config false; 2972 leaf initiator { 2973 type boolean; 2974 description 2975 "It is acting as initiator for this 2976 connection."; 2977 } 2978 leaf initiator-ikesa-spi { 2979 type ike-spi; 2980 description 2981 "Initiator's IKE SA SPI."; 2982 } 2983 leaf responder-ikesa-spi { 2984 type ike-spi; 2985 description 2986 "Responder's IKE SA SPI."; 2987 } 2988 leaf nat-local { 2989 type boolean; 2990 description 2991 "True, if local endpoint is behind a 2992 NAT."; 2994 } 2995 leaf nat-remote { 2996 type boolean; 2997 description 2998 "True, if remote endpoint is behind 2999 a NAT."; 3000 } 3002 container encapsulation-type 3003 { 3004 uses nsfikec:encap; 3005 description 3006 "This container provides information 3007 about the source and destination 3008 ports of encapsulation that IKE is 3009 using, and the type of encapsulation 3010 when NAT traversal is required."; 3011 reference 3012 "RFC 8229."; 3013 } 3014 leaf established { 3015 type uint64; 3016 description 3017 "Seconds since this IKE SA has been 3018 established."; 3019 } 3020 leaf current-rekey-time { 3021 type uint64; 3022 description 3023 "Seconds before IKE SA must be rekeyed."; 3024 } 3025 leaf current-reauth-time { 3026 type uint64; 3027 description 3028 "Seconds before IKE SA must be 3029 re-authenticated."; 3030 } 3031 description 3032 "IKE state data for a particular 3033 connection."; 3034 } /* ike-sa-state */ 3035 } /* ike-conn-entries */ 3037 container number-ike-sas { 3038 config false; 3039 leaf total { 3040 type uint64; 3041 description 3042 "Total number of active IKE SAs."; 3043 } 3044 leaf half-open { 3045 type uint64; 3046 description 3047 "Number of half-open active IKE SAs."; 3048 } 3049 leaf half-open-cookies { 3050 type uint64; 3051 description 3052 "Number of half open active IKE SAs with 3053 cookie activated."; 3054 } 3055 description 3056 "General information about the IKE SAs. In 3057 particular, it provides the current number of 3058 IKE SAs."; 3059 } 3060 } /* container ipsec-ike */ 3061 } 3063 3065 Appendix C. YANG model for IKE-less case 3067 This Appendix is Normative. 3069 This YANG module has normative references to [RFC4301], [RFC6991], 3070 [RFC8174] and [RFC8341]. 3072 file "ietf-i2nsf-ikeless@2020-10-21.yang" 3074 module ietf-i2nsf-ikeless { 3076 yang-version 1.1; 3077 namespace "urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless"; 3079 prefix "nsfikels"; 3081 import ietf-yang-types { 3082 prefix yang; 3083 reference "RFC 6991: Common YANG Data Types"; 3084 } 3085 import ietf-i2nsf-ikec { 3086 prefix nsfikec; 3087 reference 3088 "Common Data model for SDN-based IPsec 3089 configuration."; 3090 } 3092 import ietf-netconf-acm { 3093 prefix nacm; 3094 reference 3095 "RFC 8341: Network Configuration Access Control 3096 Model."; 3097 } 3099 organization "IETF I2NSF Working Group"; 3101 contact 3102 "WG Web: 3103 WG List: 3105 Author: Rafael Marin-Lopez 3106 3108 Author: Gabriel Lopez-Millan 3109 3111 Author: Fernando Pereniguez-Garcia 3112 3113 "; 3115 description 3116 "Data model for IKE-less case in the SDN-base IPsec flow 3117 protection service. 3119 Copyright (c) 2020 IETF Trust and the persons 3120 identified as authors of the code. All rights reserved. 3121 Redistribution and use in source and binary forms, with 3122 or without modification, is permitted pursuant to, and 3123 subject to the license terms contained in, the 3124 Simplified BSD License set forth in Section 4.c of the 3125 IETF Trust's Legal Provisions Relating to IETF Documents 3126 (https://trustee.ietf.org/license-info). 3128 This version of this YANG module is part of RFC XXXX;; 3129 see the RFC itself for full legal notices. 3131 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 3132 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 3133 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this 3134 document are to be interpreted as described in BCP 14 3135 (RFC 2119) (RFC 8174) when, and only when, they appear 3136 in all capitals, as shown here."; 3138 revision "2020-10-21" { 3139 description "Initial version."; 3140 reference "RFC XXXX: Software-Defined Networking 3141 (SDN)-based IPsec Flow Protection."; 3142 } 3144 feature ikeless-notification { 3145 description 3146 "To ensure broader applicability of this module, 3147 the notifications are marked as a feature. 3148 For the implementation of ikeless case, 3149 the NSF is expected to implement this 3150 feature."; 3151 } 3153 container ipsec-ikeless { 3154 description 3155 "Container for configuration of the IKE-less 3156 case. The container contains two additional 3157 containers: 'spd' and 'sad'. The first allows the 3158 I2NSF Controller to configure IPsec policies in 3159 the Security Policy Database SPD, and the second 3160 allows to configure IPsec Security Associations 3161 (IPsec SAs) in the Security Association Database 3162 (SAD)."; 3163 reference "RFC 4301."; 3164 container spd { 3165 description 3166 "Configuration of the Security Policy Database 3167 (SPD.)"; 3168 reference "Section 4.4.1.2 in RFC 4301."; 3170 list spd-entry { 3171 key "name"; 3172 ordered-by user; 3173 leaf name { 3174 type string; 3175 description 3176 "SPD entry unique name to identify this 3177 entry."; 3178 } 3179 leaf direction { 3180 type nsfikec:ipsec-traffic-direction; 3181 mandatory true; 3182 description 3183 "Inbound traffic or outbound 3184 traffic. In the IKE-less case the 3185 I2NSF Controller needs to 3186 specify the policy direction to be 3187 applied in the NSF. In the IKE case 3188 this direction does not need to be 3189 specified since IKE 3190 will determine the direction that 3191 IPsec policy will require."; 3192 } 3193 leaf reqid { 3194 type uint64; 3195 default 0; 3196 description 3197 "This value allows to link this 3198 IPsec policy with IPsec SAs with the 3199 same reqid. It is only required in 3200 the IKE-less model since, in the IKE 3201 case this link is handled internally 3202 by IKE."; 3203 } 3205 container ipsec-policy-config { 3206 description 3207 "This container carries the 3208 configuration of a IPsec policy."; 3209 uses nsfikec:ipsec-policy-grouping; 3210 } 3211 description 3212 "The SPD is represented as a list of SPD 3213 entries, where each SPD entry represents an 3214 IPsec policy."; 3215 } /*list spd-entry*/ 3216 } /*container spd*/ 3218 container sad { 3219 description 3220 "Configuration of the IPsec Security Association 3221 Database (SAD)"; 3222 reference "Section 4.4.2.1 in RFC 4301."; 3223 list sad-entry { 3224 key "name"; 3225 ordered-by user; 3226 leaf name { 3227 type string; 3228 description 3229 "SAD entry unique name to identify this 3230 entry."; 3231 } 3232 leaf reqid { 3233 type uint64; 3234 default 0; 3235 description 3236 "This value allows to link this 3237 IPsec SA with an IPsec policy with 3238 the same reqid."; 3239 } 3241 container ipsec-sa-config { 3242 description 3243 "This container allows configuring 3244 details of an IPsec SA."; 3245 leaf spi { 3246 type uint32 { range "0..max"; } 3247 mandatory true; 3248 description 3249 "Security Parameter Index (SPI)'s 3250 IPsec SA."; 3251 } 3252 leaf ext-seq-num { 3253 type boolean; 3254 default true; 3255 description 3256 "True if this IPsec SA is using 3257 extended sequence numbers. True 64 3258 bit counter, FALSE 32 bit."; 3259 } 3260 leaf seq-number-counter { 3261 type uint64; 3262 default 0; 3263 description 3264 "A 64-bit counter when this IPsec 3265 SA is using Extended Sequence 3266 Number or 32-bit counter when it 3267 is not. It used to generate the 3268 initial Sequence Number field 3269 in ESP headers."; 3270 } 3271 leaf seq-overflow { 3272 type boolean; 3273 default false; 3274 description 3275 "The flag indicating whether 3276 overflow of the sequence number 3277 counter should prevent transmission 3278 of additional packets on the IPsec 3279 SA (false) and, therefore needs to 3280 be rekeyed, or whether rollover is 3281 permitted (true). If Authenticated 3282 Encryption with Associated Data 3283 (AEAD) is used this flag MUST BE 3284 false."; 3285 } 3286 leaf anti-replay-window { 3287 type uint32; 3288 default 32; 3289 description 3290 "A 32-bit counter and a bit-map (or 3291 equivalent) used to determine 3292 whether an inbound ESP packet is a 3293 replay. If set to 0 no anti-replay 3294 mechanism is performed."; 3295 } 3296 container traffic-selector { 3297 uses nsfikec:selector-grouping; 3298 description 3299 "The IPsec SA traffic selector."; 3300 } 3301 leaf protocol-parameters { 3302 type nsfikec:ipsec-protocol-parameters; 3303 default esp; 3304 description 3305 "Security protocol of IPsec SA: Only 3306 ESP so far."; 3307 } 3308 leaf mode { 3309 type nsfikec:ipsec-mode; 3310 default transport; 3311 description 3312 "Tunnel or transport mode."; 3313 } 3314 container esp-sa { 3315 when "../protocol-parameters = 3316 'esp'"; 3317 description 3318 "In case the IPsec SA is 3319 Encapsulation Security Payload 3320 (ESP), it is required to specify 3321 encryption and integrity 3322 algorithms, and key material."; 3324 container encryption { 3325 description 3326 "Configuration of encryption or 3327 AEAD algorithm for IPsec 3328 Encapsulation Security Payload 3329 (ESP)."; 3331 leaf encryption-algorithm { 3332 type nsfikec:encryption-algorithm-type; 3333 default 12; 3334 description 3335 "Configuration of ESP 3336 encryption. With AEAD 3337 algorithms, the integrity 3338 leaf is not used."; 3339 } 3341 leaf key { 3342 nacm:default-deny-all; 3343 type yang:hex-string; 3344 description 3345 "ESP encryption key value. 3346 If this leaf is not defined 3347 the key is not defined 3348 (e.g. encryption is NULL). 3349 The key length is 3350 determined by the 3351 length of the key set in 3352 this leaf. By default is 3353 128 bits."; 3354 } 3355 leaf iv { 3356 nacm:default-deny-all; 3357 type yang:hex-string; 3358 description 3359 "ESP encryption IV value. If 3360 this leaf is not defined the 3361 IV is not defined (e.g. 3362 encryption is NULL)"; 3363 } 3364 } 3366 container integrity { 3367 description 3368 "Configuration of integrity for 3369 IPsec Encapsulation Security 3370 Payload (ESP). This container 3371 allows to configure integrity 3372 algorithm when no AEAD 3373 algorithms are used, and 3374 integrity is required."; 3375 leaf integrity-algorithm { 3376 type nsfikec:integrity-algorithm-type; 3377 default 12; 3378 description 3379 "Message Authentication Code 3380 (MAC) algorithm to provide 3381 integrity in ESP 3382 (default 3383 AUTH_HMAC_SHA2_256_128). 3384 With AEAD algorithms, 3385 the integrity leaf is not 3386 used."; 3387 } 3388 leaf key { 3389 nacm:default-deny-all; 3390 type yang:hex-string; 3391 description 3392 "ESP integrity key value. 3393 If this leaf is not defined 3394 the key is not defined (e.g. 3395 AEAD algorithm is chosen and 3396 integrity algorithm is not 3397 required). The key length is 3398 determined by the length of 3399 the key configured."; 3400 } 3401 } 3402 } /*container esp-sa*/ 3404 container sa-lifetime-hard { 3405 description 3406 "IPsec SA hard lifetime. The action 3407 associated is terminate and 3408 hold."; 3409 uses nsfikec:lifetime; 3410 } 3411 container sa-lifetime-soft { 3412 description 3413 "IPsec SA soft lifetime."; 3414 uses nsfikec:lifetime; 3415 leaf action { 3416 type nsfikec:lifetime-action; 3417 description 3418 "Action lifetime: 3419 terminate-clear, 3420 terminate-hold or replace."; 3422 } 3423 } 3424 container tunnel { 3425 when "../mode = 'tunnel'"; 3426 uses nsfikec:tunnel-grouping; 3427 description 3428 "Endpoints of the IPsec tunnel."; 3429 } 3430 container encapsulation-type 3431 { 3432 uses nsfikec:encap; 3433 description 3434 "This container carries 3435 configuration information about 3436 the source and destination ports 3437 which will be used for ESP 3438 encapsulation that ESP packets the 3439 type of encapsulation when NAT 3440 traversal is in place."; 3441 } 3442 } /*ipsec-sa-config*/ 3444 container ipsec-sa-state { 3445 config false; 3446 description 3447 "Container describing IPsec SA state 3448 data."; 3449 container sa-lifetime-current { 3450 uses nsfikec:lifetime; 3451 description 3452 "SAD lifetime current."; 3453 } 3454 container replay-stats { 3455 description 3456 "State data about the anti-replay 3457 window."; 3458 leaf replay-window { 3459 type uint64; 3460 description 3461 "Current state of the replay 3462 window."; 3463 } 3464 leaf packet-dropped { 3465 type uint64; 3466 description 3467 "Packets detected out of the 3468 replay window and dropped 3469 because they are replay 3470 packets."; 3471 } 3472 leaf failed { 3473 type uint32; 3474 description 3475 "Number of packets detected out 3476 of the replay window."; 3477 } 3478 leaf seq-number-counter { 3479 type uint64; 3480 description 3481 "A 64-bit counter when this 3482 IPsec SA is using Extended 3483 Sequence Number or 32-bit 3484 counter when it is not. 3485 Current value of sequence 3486 number."; 3487 } 3488 } /* container replay-stats*/ 3489 } /*ipsec-sa-state*/ 3491 description 3492 "List of SAD entries that conforms the SAD."; 3493 } /*list sad-entry*/ 3494 } /*container sad*/ 3495 }/*container ipsec-ikeless*/ 3497 /* Notifications */ 3498 notification sadb-acquire { 3499 if-feature ikeless-notification; 3500 description 3501 "An IPsec SA is required. The traffic-selector 3502 container contains information about the IP packet 3503 that triggers the acquire notification."; 3504 leaf ipsec-policy-name { 3505 type string; 3506 mandatory true; 3507 description 3508 "It contains the SPD entry name (unique) of 3509 the IPsec policy that hits the IP packet 3510 required IPsec SA. It is assumed the 3511 I2NSF Controller will have a copy of the 3512 information of this policy so it can 3513 extract all the information with this 3514 unique identifier. The type of IPsec SA is 3515 defined in the policy so the Security 3516 Controller can also know the type of IPsec 3517 SA that must be generated."; 3519 } 3520 container traffic-selector { 3521 description 3522 "The IP packet that triggered the acquire 3523 and requires an IPsec SA. Specifically it 3524 will contain the IP source/mask and IP 3525 destination/mask; protocol (udp, tcp, 3526 etc...); and source and destination 3527 ports."; 3528 uses nsfikec:selector-grouping; 3529 } 3530 } 3532 notification sadb-expire { 3533 if-feature ikeless-notification; 3534 description "An IPsec SA expiration (soft or hard)."; 3535 leaf ipsec-sa-name { 3536 type string; 3537 mandatory true; 3538 description 3539 "It contains the SAD entry name (unique) of 3540 the IPsec SA that has expired. It is assumed 3541 the I2NSF Controller will have a copy of the 3542 IPsec SA information (except the cryptographic 3543 material and state data) indexed by this name 3544 (unique identifier) so it can know all the 3545 information (crypto algorithms, etc.) about 3546 the IPsec SA that has expired in order to 3547 perform a rekey (soft lifetime) or delete it 3548 (hard lifetime) with this unique identifier."; 3549 } 3550 leaf soft-lifetime-expire { 3551 type boolean; 3552 default true; 3553 description 3554 "If this value is true the lifetime expired is 3555 soft. If it is false is hard."; 3556 } 3557 container lifetime-current { 3558 description 3559 "IPsec SA current lifetime. If 3560 soft-lifetime-expired is true this container is 3561 set with the lifetime information about current 3562 soft lifetime."; 3563 uses nsfikec:lifetime; 3564 } 3565 } 3566 notification sadb-seq-overflow { 3567 if-feature ikeless-notification; 3568 description "Sequence overflow notification."; 3569 leaf ipsec-sa-name { 3570 type string; 3571 mandatory true; 3572 description 3573 "It contains the SAD entry name (unique) of 3574 the IPsec SA that is about to have sequence 3575 number overflow and rollover is not permitted. 3576 It is assumed the I2NSF Controller will have 3577 a copy of the IPsec SA information (except the 3578 cryptographic material and state data) indexed 3579 by this name (unique identifier) so the it can 3580 know all the information (crypto algorithms, 3581 etc.) about the IPsec SA that has expired in 3582 order to perform a rekey of the IPsec SA."; 3583 } 3584 } 3585 notification sadb-bad-spi { 3586 if-feature ikeless-notification; 3587 description 3588 "Notify when the NSF receives a packet with an 3589 incorrect SPI (i.e. not present in the SAD)."; 3590 leaf spi { 3591 type uint32 { range "0..max"; } 3592 mandatory true; 3593 description 3594 "SPI number contained in the erroneous IPsec 3595 packet."; 3596 } 3597 } 3598 } 3600 3602 Appendix D. XML configuration example for IKE case (gateway-to-gateway) 3604 This example shows a XML configuration file sent by the I2NSF 3605 Controller to establish a IPsec Security Association between two NSFs 3606 (see Figure 3) in tunnel mode (gateway-to-gateway) with ESP, 3607 authentication based on X.509 certificates and applying the IKE case. 3609 +------------------+ 3610 | I2NSF Controller | 3611 +------------------+ 3612 I2NSF NSF-Facing | 3613 Interface | 3614 /------------------+-----------------\ 3615 / \ 3616 / \ 3617 +----+ +--------+ +--------+ +----+ 3618 | h1 |--| nsf_h1 |== IPsec_ESP_Tunnel_mode == | nsf_h2 |--| h2 | 3619 +----+ +--------+ +--------+ +----+ 3620 :1 :100 :200 :1 3622 (2001:DB8:1:/64) (2001:DB8:123:/64) (2001:DB8:2:/64) 3624 Figure 3: IKE case, tunnel mode , X.509 certificate authentication. 3626 3628 3629 3630 nsf_h1_pad 3631 2001:DB8:123::100 3632 3633 digital-signature 3634 3635 base64encodedvalue== 3636 base64encodedvalue== 3637 base64encodedvalue== 3638 3639 3640 3641 3642 nsf_h2_pad 3643 2001:DB8:123::200 3644 ikev2 3645 3646 digital-signature 3647 3648 3649 1 3650 base64encodedvalue== 3651 base64encodedvalue== 3652 3653 3654 3656 3657 3658 nsf_h1-nsf_h2 3659 start 3660 ikev2 3661 false 3662 true 3663 3664 60 3665 120 3666 3667 3668 3600 3669 3670 3671 7 3672 3673 3674 1 3675 3676 3677 18 3678 30 3679 3680 15 3681 3682 3683 nsf_h1_pad 3684 3685 3686 nsf_h2_pad 3687 3688 3689 3690 nsf_h1-nsf_h2 3691 3692 32 3693 3694 2001:DB8:1::0/64 3695 2001:DB8:2::0/64 3696 any 3697 3698 0 3699 0 3700 3701 3702 0 3703 0 3705 3706 3707 3708 protect 3709 3710 false 3711 true 3712 false 3713 false 3714 tunnel 3715 esp 3716 3717 3718 2 3719 3720 3721 1 3722 12 3723 128 3724 3725 3726 3727 2 3728 3 3729 3730 false 3731 3732 3733 2001:DB8:123::100 3734 2001:DB8:123::200 3735 clear 3736 true 3737 false 3738 3739 3740 3741 3742 3743 3744 3745 3746 18 3747 3748 1000000 3749 1000 3750 3751 60 3752 replace 3754 3755 3756 2000000 3757 2000 3758 3759 120 3760 3761 3762 3763 3765 Appendix E. XML configuration example for IKE-less case (host-to-host) 3767 This example shows a XML configuration file sent by the I2NSF 3768 Controller to establish a IPsec Security Association between two NSFs 3769 (see Figure 4) in transport mode (host-to-host) with ESP, and 3770 applying the IKE-less case. 3772 +------------------+ 3773 | I2NSF Controller | 3774 +------------------+ 3775 I2NSF NSF-Facing | 3776 Interface | 3777 /--------------------+-------------------\ 3778 / \ 3779 / \ 3780 +--------+ +--------+ 3781 | nsf_h1 |===== IPsec_ESP_Transport_mode =====| nsf_h2 | 3782 +--------+ +--------+ 3783 :100 (2001:DB8:123:/64) :200 3785 Figure 4: IKE-less case, transport mode. 3787 3790 3791 3792 3793 in/trans/2001:DB8:123::200/2001:DB8:123::100 3794 3795 inbound 3796 1 3797 3798 3799 2001:DB8:123::200/128 3800 2001:DB8:123::100/128 3801 any 3802 3803 0 3804 0 3805 3806 3807 0 3808 0 3809 3810 3811 3812 protect 3813 3814 true 3815 true 3816 transport 3817 esp 3818 3819 3820 2 3821 3822 3823 1 3824 12 3825 128 3826 3827 3828 2 3829 3 3830 3831 3832 3833 3834 3835 3836 3837 out/trans/2001:DB8:123::100/2001:DB8:123::200 3838 outbound 3839 1 3840 3841 3842 2001:DB8:123::100/128 3843 2001:DB8:123::200/128 3844 any 3845 3846 0 3847 0 3848 3849 3850 0 3851 0 3852 3853 3854 3855 protect 3856 3857 true 3858 true 3859 transport 3860 esp 3861 3862 3863 2 3864 3865 3866 1 3867 12 3868 128 3869 3870 3871 2 3872 3 3873 3874 3875 3876 3877 3878 3879 3880 3881 3882 out/trans/2001:DB8:123::100/2001:DB8:123::200 3883 1 3884 3885 34501 3886 true 3887 100 3888 true 3889 32 3890 3891 2001:DB8:123::100/128 3892 2001:DB8:123::200/128 3893 any 3894 3895 0 3896 0 3897 3898 3899 0 3900 0 3901 3902 3903 esp 3904 transport 3905 3906 3907 3908 12 3909 01:23:45:67:89:AB:CE:DF 3910 01:23:45:67:89:AB:CE:DF 3911 3912 3913 3914 2 3915 01:23:45:67:89:AB:CE:DF 3916 3917 3918 3919 3920 3921 in/trans/2001:DB8:123::200/2001:DB8:123::100 3922 1 3923 3924 34502 3925 true 3926 100 3927 true 3928 32 3929 3930 2001:DB8:123::200/128 3931 2001:DB8:123::100/128 3932 any 3933 3934 0 3935 0 3936 3937 3938 0 3939 0 3940 3942 3943 esp 3944 transport 3945 3946 3947 3948 12 3949 01:23:45:67:89:AB:CE:DF 3950 01:23:45:67:89:AB:CE:DF 3951 3952 3953 3954 2 3955 01:23:45:67:89:AB:CE:DF 3956 3957 3958 3959 2000000 3960 2000 3961 3962 120 3963 3964 3965 1000000 3966 1000 3967 3968 60 3969 replace 3970 3971 3972 3973 3974 3976 Appendix F. XML notification examples 3978 Below we show several XML files that represent different types of 3979 notifications defined in the IKE-less YANG model, which are sent by 3980 the NSF to the I2NSF Controller. The notifications happen in the 3981 IKE-less case. 3983 3984 in/trans/2001:DB8:123::200/2001:DB8:123::100 3985 3986 true 3987 3988 1000000 3989 1000 3990 3991 60 3992 3993 3995 Figure 5: Example of sadb-expire notification. 3997 3998 in/trans/2001:DB8:123::200/2001:DB8:123::100 3999 4000 4001 2001:DB8:123::200/128 4002 2001:DB8:123::100/128 4003 any 4004 4005 0 4006 0 4007 4008 4009 0 4010 0 4011 4012 4013 4015 Figure 6: Example of sadb-acquire notification. 4017 4019 in/trans/2001:DB8:123::200/2001:DB8:123::100 4020 4021 4023 Figure 7: Example of sadb-seq-overflow notification. 4025 4027 666 4028 4030 Figure 8: Example of sadb-bad-spi notification. 4032 Appendix G. Operational use cases examples 4034 G.1. Example of IPsec SA establishment 4036 This appendix exemplifies the applicability of IKE case and IKE-less 4037 case to traditional IPsec configurations, that is, host-to-host and 4038 gateway-to-gateway. The examples we show in the following assume the 4039 existence of two NSFs needing to establish an end-to-end IPsec SA to 4040 protect their communications. Both NSFs could be two hosts that 4041 exchange traffic (host-to-host) or gateways (gateway-to-gateway), for 4042 example, within an enterprise that needs to protect the traffic 4043 between the networks of two branch offices. 4045 Applicability of these configurations appear in current and new 4046 networking scenarios. For example, SD-WAN technologies are providing 4047 dynamic and on-demand VPN connections between branch offices, or 4048 between branches and SaaS cloud services. Besides, IaaS services 4049 providing virtualization environments are deployments that often rely 4050 on IPsec to provide secure channels between virtual instances (host- 4051 to-host) and providing VPN solutions for virtualized networks 4052 (gateway-to-gateway). 4054 As we will show in the following, the I2NSF-based IPsec management 4055 system (for IKE and IKE-less cases), exhibits various advantages: 4057 1. It allows to create IPsec SAs among two NSFs, based only on the 4058 application of general Flow-based Protection Policies at the 4059 I2NSF User. Thus, administrators can manage all security 4060 associations in a centralized point with an abstracted view of 4061 the network. 4063 2. Any NSF deployed in the system does not need manual 4064 configuration, therefore allowing its deployment in an automated 4065 manner. 4067 G.1.1. IKE case 4068 +----------------------------------------+ 4069 | I2NSF User (IPsec Management System) | 4070 +----------------------------------------+ 4071 | 4072 (1) Flow-based I2NSF Consumer-Facing 4073 Protection Policy Interface 4074 | 4075 +---------|------------------------------+ 4076 | | | 4077 | | I2NSF Controller | 4078 | V | 4079 | +--------------+ (2)+--------------+ | 4080 | |Translate into|--->| NETCONF/ | | 4081 | |IPsec Policies| | RESTCONF | | 4082 | +--------------+ +--------------+ | 4083 | | | | 4084 | | | | 4085 +--------------------------|-----|-------+ 4086 | | 4087 I2NSF NSF-Facing Interface | | 4088 | (3) | 4089 |-------------------------+ +---| 4090 V V 4091 +----------------------+ +----------------------+ 4092 | NSF A | | NSF B | 4093 | IKEv2/IPsec(SPD/PAD) | | IKEv2/IPsec(SPD/PAD) | 4094 +----------------------+ +----------------------+ 4096 Figure 9: Host-to-host / gateway-to-gateway for the IKE case. 4098 Figure 9 describes the application of the IKE case when a data packet 4099 needs to be protected in the path between the NSF A and NSF B: 4101 1. The I2NSF User defines a general flow-based protection policy 4102 (e.g. protect data traffic between NSF A and B). The I2NSF 4103 Controller looks for the NSFs involved (NSF A and NSF B). 4105 2. The I2NSF Controller generates IKEv2 credentials for them and 4106 translates the policies into SPD and PAD entries. 4108 3. The I2NSF Controller inserts an IKEv2 configuration that includes 4109 the SPD and PAD entries in both NSF A and NSF B. If some of 4110 operations with NSF A and NSF B fail the I2NSF Controller will 4111 stop the process and perform a rollback operation by deleting any 4112 IKEv2, SPD and PAD configuration that had been successfully 4113 installed in NSF A or B. 4115 If the previous steps are successful, the flow is protected by means 4116 of the IPsec SA established with IKEv2 between NSF A and NSF B. 4118 G.1.2. IKE-less case 4120 +----------------------------------------+ 4121 | I2NSF User (IPsec Management System) | 4122 +----------------------------------------+ 4123 | 4124 (1) Flow-based I2NSF Consumer-Facing 4125 Protection Policy Interface 4126 | 4127 +---------|------------------------------+ 4128 | | | 4129 | | I2NSF Controller | 4130 | V | 4131 | +--------------+ (2) +--------------+ | 4132 | |Translate into|---->| NETCONF/ | | 4133 | |IPsec Policies| | RESTCONF | | 4134 | +--------------+ +--------------+ | 4135 | | | | 4136 +-------------------------|-----|--------+ 4137 | | 4138 I2NSF NSF-Facing Interface | | 4139 | (3) | 4140 |----------------------+ +--| 4141 V V 4142 +----------------+ +----------------+ 4143 | NSF A | | NSF B | 4144 | IPsec(SPD/SAD) | | IPsec(SPD/SAD) | 4145 +----------------+ +----------------+ 4147 Figure 10: Host-to-host / gateway-to-gateway for IKE-less case. 4149 Figure 10 describes the application of the IKE-less case when a data 4150 packet needs to be protected in the path between the NSF A and NSF B: 4152 1. The I2NSF User establishes a general Flow-based Protection Policy 4153 and the I2NSF Controller looks for the involved NSFs. 4155 2. The I2NSF Controller translates the flow-based security policies 4156 into IPsec SPD and SAD entries. 4158 3. The I2NSF Controller inserts these entries in both NSF A and NSF 4159 B IPsec databases (SPD and SAD). The following text describes 4160 how this would happen: 4162 * The I2NSF Controller chooses two random values as SPIs: for 4163 example, SPIa1 for NSF A and SPIb1 for NSF B. These numbers 4164 MUST NOT be in conflict with any IPsec SA in NSF A or NSF B. 4165 It also generates fresh cryptographic material for the new 4166 inbound/outbound IPsec SAs and their parameters. 4168 * After that, the I2NSF Controller sends simultaneously the new 4169 inbound IPsec SA with SPIa1 and new outbound IPsec SA with 4170 SPIb1 to NSF A; and the new inbound IPsec SA with SPIb1 and 4171 new outbound IPsec SA with SPIa1 to B, together with the 4172 corresponding IPsec policies. 4174 * Once the I2NSF Controller receives confirmation from NSF A and 4175 NSF B, it knows that the IPsec SAs are correctly installed and 4176 ready. 4178 Other alternative to this operation is: the I2NSF Controller 4179 sends first the IPsec policies and new inbound IPsec SAs to A and 4180 B and once it obtains a successful confirmation of these 4181 operations from NSF A and NSF B, it proceeds with installing to 4182 the new outbound IPsec SAs. Even though this procedure may 4183 increase the latency to complete the process, no traffic is sent 4184 over the network until the IPsec SAs are completely operative. 4185 In any case other alternatives MAY be possible to implement step 4186 3. 4188 4. If some of the operations described above fail (e.g. the NSF A 4189 reports an error when the I2NSF Controller is trying to install 4190 the SPD entry, the new inbound or outbound IPsec SAs) the I2NSF 4191 Controller must perform rollback operations by deleting any new 4192 inbound or outbound SA and SPD entry that had been successfully 4193 installed in any of the NSFs (e.g NSF B) and stop the process. 4194 Note that the I2NSF Controller may retry several times before 4195 giving up. 4197 5. Otherwise, if the steps 1 to 3 are successful, the flow between 4198 NSF A and NSF B is protected by means of the IPsec SAs 4199 established by the I2NSF Controller. It is worth mentioning that 4200 the I2NSF Controller associates a lifetime to the new IPsec SAs. 4201 When this lifetime expires, the NSF will send a sadb-expire 4202 notification to the I2NSF Controller in order to start the 4203 rekeying process. 4205 Instead of installing IPsec policies (in the SPD) and IPsec SAs (in 4206 the SAD) in step 3 (proactive mode), it is also possible that the 4207 I2NSF Controller only installs the SPD entries in step 3 (reactive 4208 mode). In such a case, when a data packet requires to be protected 4209 with IPsec, the NSF that saw first the data packet will send a sadb- 4210 acquire notification that informs the I2NSF Controller that needs SAD 4211 entries with the IPsec SAs to process the data packet. Again, if 4212 some of the operations installing the new inbound/outbound IPsec SAs 4213 fail, the I2NSF Controller stops the process and performs a rollback 4214 operation by deleting any new inbound/outbound SAs that had been 4215 successfully installed. 4217 G.2. Example of the rekeying process in IKE-less case 4219 To explain an example of the rekeying process between two IPsec NSFs 4220 A and B, let assume that SPIa1 identifies the inbound IPsec SA in A, 4221 and SPIb1 the inbound IPsec SA in B. The rekeying process will take 4222 the following steps: 4224 1. The I2NSF Controller chooses two random values as SPI for the new 4225 inbound IPsec SAs: for example, SPIa2 for A and SPIb2 for B. 4226 These numbers MUST NOT be in conflict with any IPsec SA in A or 4227 B. Then, the I2NSF Controller creates an inbound IPsec SA with 4228 SPIa2 in A and another inbound IPsec SA in B with SPIb2. It can 4229 send this information simultaneously to A and B. 4231 2. Once the I2NSF Controller receives confirmation from A and B, the 4232 controller knows that the inbound IPsec SAs are correctly 4233 installed. Then it proceeds to send in parallel to A and B, the 4234 outbound IPsec SAs: the outbound IPsec SA to A with SPIb2, and 4235 the outbound IPsec SA to B with SPIa2. At this point the new 4236 IPsec SAs are ready. 4238 3. Once the I2NSF Controller receives confirmation from A and B that 4239 the outbound IPsec SAs have been installed, the I2NSF Controller, 4240 in parallel, deletes the old IPsec SAs from A (inbound SPIa1 and 4241 outbound SPIb1) and B (outbound SPIa1 and inbound SPIb1). 4243 If some of the operations in step 1 fail (e.g. the NSF A reports an 4244 error when the I2NSF Controller is trying to install a new inbound 4245 IPsec SA) the I2NSF Controller must perform rollback operations by 4246 removing any new inbound SA that had been successfully installed 4247 during step 1. 4249 If step 1 is successful but some of the operations in step 2 fails 4250 (e.g. the NSF A reports an error when the I2NSF Controller is trying 4251 to install the new outbound IPsec SA), the I2NSF Controller must 4252 perform a rollback operation by deleting any new outbound SA that had 4253 been successfully installed during step 2 and by deleting the inbound 4254 SAs created in step 1. 4256 If the steps 1 and 2 are successful but the step 3 fails, the I2NSF 4257 Controller will avoid any rollback of the operations carried out in 4258 step 1 and step 2 since new and valid IPsec SAs were created and are 4259 functional. The I2NSF Controller may reattempt to remove the old 4260 inbound and outbound SAs in NSF A and NSF B several times until it 4261 receives a success or it gives up. In the last case, the old IPsec 4262 SAs will be removed when their corresponding hard lifetime is 4263 reached. 4265 G.3. Example of managing NSF state loss in IKE-less case 4267 In the IKE-less case, if the I2NSF Controller detects that a NSF has 4268 lost the IPsec state, it could follow the next steps: 4270 1. The I2NSF Controller SHOULD delete the old IPsec SAs on the non- 4271 failed nodes, established with the failed node. This prevents 4272 the non-failed nodes from leaking plaintext. 4274 2. If the affected node restarts, the I2NSF Controller configures 4275 the new inbound IPsec SAs between the affected node and all the 4276 nodes it was talking to. 4278 3. After these inbound IPsec SAs have been established, the I2NSF 4279 Controller configures the outbound IPsec SAs in parallel. 4281 Step 2 and step 3 can be performed at the same time at the cost of a 4282 potential packet loss. If this is not critical then it is an 4283 optimization since the number of exchanges between I2NSF Controller 4284 and NSFs is lower. 4286 Authors' Addresses 4288 Rafa Marin-Lopez 4289 University of Murcia 4290 Campus de Espinardo S/N, Faculty of Computer Science 4291 Murcia 30100 4292 Spain 4294 Phone: +34 868 88 85 01 4295 EMail: rafa@um.es 4297 Gabriel Lopez-Millan 4298 University of Murcia 4299 Campus de Espinardo S/N, Faculty of Computer Science 4300 Murcia 30100 4301 Spain 4303 Phone: +34 868 88 85 04 4304 EMail: gabilm@um.es 4305 Fernando Pereniguez-Garcia 4306 University Defense Center 4307 Spanish Air Force Academy, MDE-UPCT 4308 San Javier (Murcia) 30720 4309 Spain 4311 Phone: +34 968 18 99 46 4312 EMail: fernando.pereniguez@cud.upct.es