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