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