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