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