idnits 2.17.1 draft-ietf-i2nsf-sdn-ipsec-flow-protection-03.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 208 instances of too long lines in the document, the longest one being 171 characters in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 497 has weird spacing: '...w start ine...' == Line 500 has weird spacing: '...w start ine...' == Line 504 has weird spacing: '...w start ine...' == Line 507 has weird spacing: '...w start ine...' == Line 565 has weird spacing: '...w start ine...' == (7 more instances...) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 1. The Security Controller chooses two random values as SPI for the new inbound SAs: for example, SPIa2 for A and SPIb2 for B. These numbers MUST not be in conflict with any IPsec SA in A or B. Then,the Security Controller creates an inbound SA with SPIa2 in A and another inbound SA in B with SPIb2. It can send this information simultenously to A and B. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: leaf ipv4-address { type inet:ipv4-address; description "Specifies the identity as a single four (4) octet IPv4 address. An example is, 10.10.10.10. "; } leaf ipv6-address { type inet:ipv6-address; description "Specifies the identity as a single sixteen (16) octet IPv6 address. An example is FF01::101, 2001:DB8:0:0:8:800:200C:417A ."; } leaf fqdn-string { type inet:domain-name; description "Specifies the identity as a Fully-Qualified Domain Name (FQDN) string. An example is: example.com. The string MUST not contain any terminators (e.g., NULL, CR, etc.)."; } leaf rfc822-address-string { type string; description "Specifies the identity as a fully-qualified RFC822 email address string. An example is, jsmith@example.com. The string MUST not contain any terminators (e.g., NULL, CR, etc.)."; } leaf dnX509 { type string; description "Specifies the identity as a distinguished name in the X.509 tradition."; } leaf id_key { type string; description "Key id"; } /* From RFC4301 list of id types */ } } /* grouping identity-grouping */ -- The document date (October 22, 2018) is 1985 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) == Unused Reference: 'RFC5226' is defined on line 1162, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2nsf-framework' is defined on line 1174, but no explicit reference was found in the text == Unused Reference: 'I-D.jeong-i2nsf-sdn-security-services-05' is defined on line 1192, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-08) exists of draft-ietf-i2nsf-terminology-06 -- No information found for draft-pfkey-spd - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 8229 (Obsoleted by RFC 9329) Summary: 3 errors (**), 0 flaws (~~), 14 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2NSF R. Marin-Lopez 3 Internet-Draft G. Lopez-Millan 4 Intended status: Standards Track University of Murcia 5 Expires: April 25, 2019 October 22, 2018 7 Software-Defined Networking (SDN)-based IPsec Flow Protection 8 draft-ietf-i2nsf-sdn-ipsec-flow-protection-03 10 Abstract 12 This document describes how providing IPsec-based flow protection by 13 means of a Software-Defined Network (SDN) controller (aka. Security 14 Controller) and establishes the requirements to support this service. 15 It considers two main well-known scenarios in IPsec: (i) gateway-to- 16 gateway and (ii) host-to-host. The SDN-based service described in 17 this document allows the distribution and monitoring of IPsec 18 information from a Security Controller to one or several flow-based 19 Network Security Function (NSF). The NSFs implement IPsec to protect 20 data traffic between network resources with IPsec. 22 The document focuses in the NSF Facing Interface by providing models 23 for Configuration and State data model required to allow the Security 24 Controller to configure the IPsec databases (SPD, SAD, PAD) and IKEv2 25 to establish security associations with a reduced intervention of the 26 network administrator. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on April 25, 2019. 45 Copyright Notice 47 Copyright (c) 2018 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 64 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 4. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 5. SDN-based IPsec management description . . . . . . . . . . . 6 67 5.1. Case 1: IKE/IPsec in the NSF . . . . . . . . . . . . . . 6 68 5.1.1. Interface Requirements for Case 1 . . . . . . . . . . 7 69 5.2. Case 2: IPsec (no IKEv2) in the NSF . . . . . . . . . . . 7 70 5.2.1. Interface Requirements for Case 2 . . . . . . . . . . 8 71 5.3. Case 1 vs Case 2 . . . . . . . . . . . . . . . . . . . . 8 72 5.3.1. Rekeying process . . . . . . . . . . . . . . . . . . 9 73 5.3.2. NSF state loss . . . . . . . . . . . . . . . . . . . 10 74 5.3.3. NAT Traversal . . . . . . . . . . . . . . . . . . . . 10 75 6. YANG configuration data models . . . . . . . . . . . . . . . 11 76 6.1. Security Policy Database (SPD) Model . . . . . . . . . . 11 77 6.2. Security Association Database (SAD) Model . . . . . . . . 13 78 6.3. Peer Authorization Database (PAD) Model . . . . . . . . . 16 79 6.4. Internet Key Exchange (IKEv2) Model . . . . . . . . . . . 17 80 7. Use cases examples . . . . . . . . . . . . . . . . . . . . . 19 81 7.1. Host-to-Host or Gateway-to-gateway under the same 82 controller . . . . . . . . . . . . . . . . . . . . . . . 19 83 7.2. Host-to-Host or Gateway-to-gateway under different 84 Security controllers . . . . . . . . . . . . . . . . . . 22 85 8. Implementation notes . . . . . . . . . . . . . . . . . . . . 24 86 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 87 9.1. Case 1 . . . . . . . . . . . . . . . . . . . . . . . . . 26 88 9.2. Case 2 . . . . . . . . . . . . . . . . . . . . . . . . . 26 89 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 90 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 91 11.1. Normative References . . . . . . . . . . . . . . . . . . 27 92 11.2. Informative References . . . . . . . . . . . . . . . . . 27 94 Appendix A. Appendix A: YANG model IPsec Configuration data . . 30 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 97 1. Introduction 99 Software-Defined Networking (SDN) is an architecture that enables 100 users to directly program, orchestrate, control and manage network 101 resources through software. SDN paradigm relocates the control of 102 network resources to a dedicated network element, namely SDN 103 controller. The SDN controller manages and configures the 104 distributed network resources and provides an abstracted view of the 105 network resources to the SDN applications. The SDN application can 106 customize and automate the operations (including management) of the 107 abstracted network resources in a programmable manner via this 108 interface [RFC7149][ITU-T.Y.3300] 109 [ONF-SDN-Architecture][ONF-OpenFlow]. 111 Typically, traditional IPsec VPN concentrators and, in general, 112 entities (i.e. hosts or security gateways) supporting IKE/IPsec, must 113 be configured directly by the administrator. This makes the IPsec 114 security association (SA) management difficult and generates a lack 115 of flexibility, specially if the number of security policies and SAs 116 to handle is high. With the growth of SDN-based scenarios where 117 network resources are deployed in an autonomous manner, a mechanism 118 to manage IPsec SAs according to the SDN architecture becomes more 119 relevant. Thus, the SDN-based service described in this document 120 will autonomously deal with IPsec SAs management. 122 An example of usage can be the notion of Software Defined WAN (SD- 123 WAN), SDN extension providing a software abstraction to create secure 124 network overlays over traditional WAN and branch networks. SD-WAN is 125 based on IPsec as underlying security protocol and aims to provide 126 flexible, automated, fast deployment and on-demand security network 127 services. 129 IPsec architecture [RFC4301] defines a clear separation between the 130 processing to provide security services to IP packets and the key 131 management procedures to establish the IPsec security associations. 132 In this document, we define a service where the key management 133 procedures can be carried by an external entity: the Security 134 Controller. 136 First, this document exposes the requirements to support the 137 protection of data flows using IPsec [RFC4301]. We have considered 138 two general cases: 140 1) The Network Security Function (NSF) implements the Internet Key 141 Exchange (IKE) protocol and the IPsec databases: the Security 142 Policy Database (SPD), the Security Association Database (SAD) 143 and the Peer Authorization Database (PAD). The Security 144 Controller is in charge of provisioning the NSF with the required 145 information to IKE, the SPD and the PAD. 147 2) The NSF only implements the IPsec databases (no IKE 148 implementation). The Security Controller will provide the 149 required parameters to create valid entries in the SPD and the 150 SAD into the NSF. Therefore, the NSF will have only support for 151 IPsec while automated key management functionality is moved to 152 the controller. 154 In both cases, an interface/protocol is required to carry out this 155 provisioning in a secure manner between the Security Controller and 156 the NSF. In particular, Case 1 requires the provision of SPD and PAD 157 entries and the IKE credential and information related with the IKE 158 negotiation (e.g. IKE_SA_INIT); and Case 2 requires the management 159 of SPD and SAD entries. Based on YANG models in [netconf-vpn] and 160 [I-D.tran-ipsecme-yang], RFC 4301 [RFC4301] and RFC 7296 [RFC7296] 161 this document defines the required interfaces with a YANG model for 162 configuration and state data for IKE, PAD, SPD and SAD Appendix A. 164 This document considers two typical scenarios to manage autonomously 165 IPsec SAs: gateway-to-gateway and host-to-host [RFC6071]. The 166 analysis of the host-to-gateway (roadwarrior) scenario is TBD. In 167 these cases, host or gateways or both may act as NSFs. Finally, it 168 also discusses the situation where two NSFs are under the control of 169 two different Security Controllers. 171 NOTE: This work pays attention to the challenge "Lack of Mechanism 172 for Dynamic Key Distribution to NSFs" defined in 173 [I-D.ietf-i2nsf-problem-and-use-cases] in the particular case of the 174 establishment and management of IPsec SAs. In fact, this I-D could 175 be considered as a proper use case for this particular challenge in 176 [I-D.ietf-i2nsf-problem-and-use-cases]. 178 2. Requirements Language 180 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 181 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 182 document are to be interpreted as described in RFC 2119 [RFC2119]. 183 When these words appear in lower case, they have their natural 184 language meaning. 186 3. Terminology 188 This document uses the terminology described in [RFC7149], [RFC4301], 189 [ITU-T.Y.3300], [ONF-SDN-Architecture], [ONF-OpenFlow], 190 [ITU-T.X.1252], [ITU-T.X.800] and [I-D.ietf-i2nsf-terminology]. In 191 addition, the following terms are defined below: 193 o Software-Defined Networking. A set of techniques enabling to 194 directly program, orchestrate, control, and manage network 195 resources, which facilitates the design, delivery and operation of 196 network services in a dynamic and scalable manner [ITU-T.Y.3300]. 198 o Flow/Data Flow. Set of network packets sharing a set of 199 characteristics, for example IP dst/src values or QoS parameters. 201 o Security Controller. A Controller is a management Component that 202 contains control plane functions to manage and facilitate 203 information sharing, as well as execute security functions. In 204 the context of this document, it provides IPsec management 205 information. 207 o Network Security Function (NSF). Software that provides a set of 208 security-related services. 210 o Flow-based NSF. A NSF that inspects network flows according to a 211 set of policies intended for enforcing security properties. The 212 NSFs considered in this document falls into this classification. 214 o Flow-based Protection Policy. The set of rules defining the 215 conditions under which a data flow MUST be protected with IPsec, 216 and the rules that MUST be applied to the specific flow. 218 o Internet Key Exchange (IKE) v2 Protocol to establish IPsec 219 Security Associations (SAs). It requires information about the 220 required authentication method (i.e. preshared keys), DH groups, 221 modes and algorithms for IKE SA negotiation, etc. 223 o Security Policy Database (SPD). It includes information about 224 IPsec policies direction (in, out), local and remote addresses, 225 inbound and outboud SAs, etc. 227 o Security Associations Database (SAD). It includes information 228 about IPsec SAs, such as SPI, destination addresses, 229 authentication and encryption algorithms and keys to protect IP 230 flow. 232 o Peer Authorization Database (PAD). It provides the link between 233 the SPD and a security association management protocol such as IKE 234 or the SDN-based solution described in this document. 236 4. Objectives 238 o To describe the architecture for the SDN-based IPsec management, 239 which implements a security service to allow the establishment and 240 management of IPsec security associations from a central point to 241 protect specific data flows. 243 o To define the interfaces required to manage and monitor the IPsec 244 Security Associations in the NSF from a Security Controller. YANG 245 models are defined for configuration and state data for IPsec 246 management. 248 5. SDN-based IPsec management description 250 As mentioned in Section 1, two cases are considered: 252 5.1. Case 1: IKE/IPsec in the NSF 254 In this case the NSF ships an IKEv2 implementation besides the IPsec 255 support. The Security Controller is in charge of managing and 256 applying SPD and PAD entries (deriving and delivering IKE Credentials 257 such as a pre-shared key, certificates, etc.), and applying other IKE 258 configuration parameters (e.g. IKE_SA_INIT algorithms) to the NSF 259 for the IKE negotiation. 261 With these entries, the IKEv2 implementation can operate to establish 262 the IPsec SAs. The application (administrator) establishes the IPsec 263 requirements and information about the end points information 264 (through the Client Facing Interface), and the Security Controller 265 translates those requirements into IKE, SPD and PAD entries that will 266 be installed into the NSF (through the NSF Facing Interface). With 267 that information, the NSF can just run IKEv2 to establish the 268 required IPsec SA (when the data flow needs protection). Figure 1 269 shows the different layers and corresponding functionality. 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 |IPsec Management/Orchestration Application | Client or 273 | I2NSF Client | App Gateway 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | Client Facing Interface 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 Vendor | Application Support | 278 Facing<->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Security 279 Interface| IKE Credential,PAD and SPD entries Distr. | Controller 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | NSF Facing Interface 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | I2NSF Agent | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Network 285 | IKE | IPsec(SPD,PAD) | Security 286 +-------------------------------------------+ Function 287 | Data Protection and Forwarding | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 Figure 1: Case 1: IKE/IPsec in the NSF 292 5.1.1. Interface Requirements for Case 1 294 SDN-based IPsec flow protection services provide dynamic and flexible 295 management of IPsec SAs in flow-based NSF. In order to support this 296 capability in case 1, the following interface requirements are to be 297 met: 299 o A YANG data model for Configuration data for IKEv2, SPD and PAD. 301 o A YANG data model for State data for IKE, SPD, PAD and SAD (NOTE: 302 the SAD entries are created in runtime by IKEv2.) 304 o In scenarios where multiple controllers are implicated, SDN-based 305 IPsec management services may require a mechanism to discover 306 which Security Controller is managing a specific NSF. Moreover, 307 an east-west interface is required to exchange IPsec-related 308 information. 310 5.2. Case 2: IPsec (no IKEv2) in the NSF 312 In this case, the NSF does not deploy IKEv2 and, therefore, the 313 Security Controller has to perform the management of IPsec SAs by 314 populating and monitoring the SPD and the SAD. 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | IPsec Management Application | Client or 318 | I2NSF Client | App Gateway 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Client Facing Interface 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 Vendor| Application Support | 323 Facing<->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Security 324 Interface| SPD, SAD and PAD Entries Distr. | Controller 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | NSF Facing Interface 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | I2NSF Agent | Network 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Security 330 | IPsec (SPD,SAD) | Function (NSF) 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Data Protection and Forwarding | 333 +-----------------------------------------+ 335 Figure 2: Case 2: IPsec (no IKE) in the NSF 337 As shown in Figure 2, applications for flow protection run on the top 338 of the Security Controller. When an administrator enforces flow- 339 based protection policies through the Client Facing Interface, the 340 Security Controller translates those requirements into SPD and SAD 341 entries, which are installed in the NSF. PAD entries are not 342 required since there is no IKEv2 in the NSF. 344 5.2.1. Interface Requirements for Case 2 346 In order to support case 2, the following requirements are to be met: 348 o A YANG data model for Configuration data for SPD and SAD. 350 o A YANG data model for State data for SPD and SAD. 352 o In scenarios where multiple controllers are implicated, SDN-based 353 IPsec management services may require a mechanism to discover 354 which Security Controller is managing a specific NSF. Moreover, 355 an east-west interface is required to exchange IPsec-related 356 information. 358 5.3. Case 1 vs Case 2 360 Case 1 MAY be easier to deploy than Case 2 because current gateways 361 typically have an IKEv2/IPsec implementation. Moreover hosts can 362 install easily an IKE implementation. As downside, the NSF needs 363 more resources to hold IKEv2. Moreover, the IKEv2 implementation 364 needs to implement an interface so that the I2NSF Agent can interact 365 with them. 367 Alternatively, Case 2 allows lighter NSFs (no IKEv2 implementation), 368 which benefits the deployment in constrained NSFs. Moreover, IKEv2 369 does not need to be performed in gateway-to-gateway and host-to-host 370 scenarios under the same Security Controller (see Section 7.1). On 371 the contrary, the overload of creating fresh IPsec SAs is shifted to 372 the Security Controller since IKEv2 is not in the NSF. As a 373 consequence, this may result in a more complex implementation in the 374 controller side. 376 5.3.1. Rekeying process 378 For case 1, the rekeying process is carried out by IKEv2, following 379 the configuration defined in the SPD. 381 For case 2, the Security Controller needs to take care of the 382 rekeying process. When the IPsec SA is going to expire (e.g. IPsec 383 SA soft lifetime), it has to create a new IPsec SA and remove the old 384 one. This rekeying process starts when the Security Controller 385 receives a sadb_expire notification or it decides so, based on 386 lifetime state data obtained from the NSF. 388 To explain the rekeying process between two IPsec peers A and B, let 389 assume that SPIa1 identifies the inbound SA in A and SPIb1 the 390 inbound SA in B. 392 1. The Security Controller chooses two random values as SPI for the 393 new inbound SAs: for example, SPIa2 for A and SPIb2 for B. These 394 numbers MUST not be in conflict with any IPsec SA in A or B. 395 Then,the Security Controller creates an inbound SA with SPIa2 in 396 A and another inbound SA in B with SPIb2. It can send this 397 information simultenously to A and B. 399 2. Once the Security Controller receives confirmation from A and B, 400 inbound SA are correctly installed. Then it proceeds to send in 401 parallel to A and B the outbound SAs: it sends the outbound SA to 402 A with SPIb2 and the outbound SA to B with SPIa2. At this point 403 the new IPsec SA is ready. 405 3. The Security Controller deletes the old IPsec SAs from A (inbound 406 SPIa1 and outbound SPIb1) and B (outbound SPIa1 and inbound 407 SPIb1) in parallel. 409 5.3.2. NSF state loss 411 If one of the NSF restarts, it may lose part or all the IPsec state 412 (affected NSF). By default, the Security Controller can assume that 413 all the state has been lost and therefore it will have to send IKEv2, 414 SPD and PAD information to the NSF in case 1 and SPD and SAD 415 information in case 2. 417 In both cases, the Security Controller MUST be aware of the affected 418 NSF (e.g. the NETCONF/TCP connection is broken with the affected NSF, 419 it is receiving bad_spi notification from a particular NSF, etc...). 420 Moreover, the Security Controller MUST have a register about all the 421 NSFs that have IPsec SAs with the affected NSF. Therefore, it knows 422 the affected IPsec SAs. 424 In Case 1, the Security Controller will configure the affected NSF 425 with the new IKEv2, SPD and PAD information. It has also to send new 426 parameters (e.g. a new fresh PSK) to the NSFs which have IKEv2 SAs 427 and IPsec SAs with the affected NSF. It can also instruct the 428 affected NSF to send IKEv2 INITIAL_CONTACT (It is TBD in the model). 429 Finally, the Security Controller will instruct the affected NSF to 430 start the IKEv2 negotiation with the new configuration. 432 In Case 2, if the Security Controller detects that a NSF has lost the 433 IPsec SAs (e.g. it reboots) it will follow similar steps to rekey: 434 the steps 1 and 2 remain equal but the step 3 will be slightly 435 different. For example, if we assume that NSF B has lost its state, 436 the Security Controller MUST only delete the old IPsec SAs from A in 437 step 3. 439 Nevertheless other more optimized options can be considered (e.g. 440 making iKEv2 configuration permanent between reboots). 442 5.3.3. NAT Traversal 444 In case 1, IKEv2 already owns a mechanism to detect whether some of 445 the peers or both are behind a NAT. If there is a NAT network 446 configured between two peers, it is required to activate the usage of 447 UDP or TCP/TLS encapsulation of ESP packets ([RFC3948], [RFC8229]) 449 On the contrary, case 2 does not have any protocol in the NSFs to 450 detect whether they are behind a NAT or not. However, the SDN 451 paradigm generally assumes the Security Controller has a view of the 452 network it controls. This view is built either requesting 453 information to the NSFs under its control, or because these NSFs 454 inform to the Security Controller. Based on this information, the 455 Security Controller can guess if there is a NAT configured between 456 two hosts, apply the required policies to both NSFs besides 457 activating the usage of UDP or TCP/TLS encapsulation of ESP packets 458 ([RFC3948], [RFC8229]). 460 For example, the Security Controller could directly request the NSF 461 for specific data such as networking configuration, NAT support, etc. 462 Protocols such as NETCONF or SNMP can be used here. For example, RFC 463 7317 [RFC7317] provides a YANG data model for system management or 464 [I-D.sivakumar-yang-nat] a data model for NAT management. 466 6. YANG configuration data models 468 In order to support case 1 and case 2 we have modelled the different 469 parameters and values that must be configured to manage IPsec SAs. 470 Specifically, case 1 requires modelling IKEv2, SPD and PAD while case 471 2 requires models for the SPD and SAD. A single YANG file represents 472 both cases though some part of the models are selectively activated 473 depending a feature defined in the YANG file. For example, the IKE 474 configuration is not enabled in case 2. 476 In the following, we summarize, by using a tree representation, the 477 different configuration and state data models. The complete YANG 478 configuration data model is in Appendix A 480 6.1. Security Policy Database (SPD) Model 482 The definition of this model has been extracted from the 483 specification in section 4.4.1 and Appendix D in [RFC4301] 485 +--rw spd 486 | +--rw spd-entry* [rule-number] 487 | +--rw rule-number uint64 488 | +--rw priority? uint32 489 | +--rw names* [name] 490 | | +--rw name-type? ipsec-spd-name 491 | | +--rw name string 492 | +--rw condition 493 | | +--rw traffic-selector-list* [ts-number] 494 | | +--rw ts-number uint32 495 | | +--rw direction? ipsec-traffic-direction 496 | | +--rw local-addresses* [start end] 497 | | | +--rw start inet:ip-address 498 | | | +--rw end inet:ip-address 499 | | +--rw remote-addresses* [start end] 500 | | | +--rw start inet:ip-address 501 | | | +--rw end inet:ip-address 502 | | +--rw next-layer-protocol* ipsec-next-layer-proto 503 | | +--rw local-ports* [start end] 504 | | | +--rw start inet:port-number 505 | | | +--rw end inet:port-number 506 | | +--rw remote-ports* [start end] 507 | | | +--rw start inet:port-number 508 | | | +--rw end inet:port-number 509 | | +--rw selector-priority? uint32 510 | +--rw processing-info 511 | | +--rw action ipsec-spd-operation 512 | | +--rw ipsec-sa-cfg 513 | | +--rw pfp-flag? boolean 514 | | +--rw extSeqNum? boolean 515 | | +--rw seqOverflow? boolean 516 | | +--rw statefulfragCheck? boolean 517 | | +--rw security-protocol? ipsec-protocol 518 | | +--rw mode? ipsec-mode 519 | | +--rw ah-algorithms 520 | | | +--rw ah-algorithm* integrity-algorithm-t 521 | | +--rw esp-algorithms 522 | | | +--rw authentication* integrity-algorithm-t 523 | | | +--rw encryption* encryption-algorithm-t 524 | | +--rw tunnel 525 | | +--rw local? inet:ip-address 526 | | +--rw remote? inet:ip-address 527 | | +--rw bypass-df? boolean 528 | | +--rw bypass-dscp? boolean 529 | | +--rw dscp-mapping? yang:hex-string 530 | | +--rw ecn? boolean 531 | +--rw spd-mark 532 | | +--rw mark? uint32 533 | | +--rw mask? yang:hex-string 534 | +--rw spd-lifetime-hard 535 | | +--rw added? uint64 536 | | +--rw used? uint64 537 | | +--rw bytes? uint32 538 | | +--rw packets? uint32 539 | | +--rw action? lifetime-action 540 | +--rw spd-lifetime-soft 541 | | +--rw added? uint64 542 | | +--rw used? uint64 543 | | +--rw bytes? uint32 544 | | +--rw packets? uint32 545 | | +--rw action? lifetime-action 546 | +--ro spd-lifetime-current 547 | +--ro added? uint64 548 | +--ro used? uint64 549 | +--ro bytes? uint32 550 | +--ro packets? uint32 552 6.2. Security Association Database (SAD) Model 554 The definition of this model has been extracted from the 555 specification in section 4.4.2 in [RFC4301] 557 +--rw sad 558 | +--rw sad-entry* [spi] 559 | +--rw spi ipsec-spi 560 | +--rw seq-number? uint64 561 | +--rw seq-number-overflow-flag? boolean 562 | +--rw anti-replay-window? uint16 563 | +--rw rule-number? uint32 564 | +--rw local-addresses* [start end] 565 | | +--rw start inet:ip-address 566 | | +--rw end inet:ip-address 567 | +--rw remote-addresses* [start end] 568 | | +--rw start inet:ip-address 569 | | +--rw end inet:ip-address 570 | +--rw next-layer-protocol* ipsec-next-layer-proto 571 | +--rw local-ports* [start end] 572 | | +--rw start inet:port-number 573 | | +--rw end inet:port-number 574 | +--rw remote-ports* [start end] 575 | | +--rw start inet:port-number 576 | | +--rw end inet:port-number 577 | +--rw security-protocol? ipsec-protocol 578 | +--rw ah-sa 579 | | +--rw integrity 580 | | +--rw integrity-algorithm? integrity-algorithm-t 581 | | +--rw key? string 582 | +--rw esp-sa 583 | | +--rw encryption 584 | | | +--rw encryption-algorithm? encryption-algorithm-t 585 | | | +--rw key? string 586 | | | +--rw iv? string 587 | | +--rw integrity 588 | | | +--rw integrity-algorithm? integrity-algorithm-t 589 | | | +--rw key? string 590 | | +--rw combined-enc-intr? boolean 591 | +--rw sad-lifetime-hard 592 | | +--rw added? uint64 593 | | +--rw used? uint64 594 | | +--rw bytes? uint32 595 | | +--rw packets? uint32 596 | | +--rw action? lifetime-action 597 | +--rw sad-lifetime-soft 598 | | +--rw added? uint64 599 | | +--rw used? uint64 600 | | +--rw bytes? uint32 601 | | +--rw packets? uint32 602 | | +--rw action? lifetime-action 603 | +--rw mode? ipsec-mode 604 | +--rw statefulfragCheck? boolean 605 | +--rw dscp? yang:hex-string 606 | +--rw path-mtu? uint16 607 | +--rw tunnel 608 | | +--rw local? inet:ip-address 609 | | +--rw remote? inet:ip-address 610 | | +--rw bypass-df? boolean 611 | | +--rw bypass-dscp? boolean 612 | | +--rw dscp-mapping? yang:hex-string 613 | | +--rw ecn? boolean 614 | +--rw encap 615 | | +--rw espencap? esp-encap 616 | | +--rw sport? inet:port-number 617 | | +--rw dport? inet:port-number 618 | | +--rw oaddr? inet:ip-address 619 | +--ro sad-lifetime-current 620 | | +--ro added? uint64 621 | | +--ro used? uint64 622 | | +--ro bytes? uint32 623 | | +--ro packets? uint32 624 | +--ro state? sa-state 625 | +--ro stats 626 | | +--ro replay-window? uint32 627 | | +--ro replay? uint32 628 | | +--ro failed? uint32 629 | +--ro replay_state 630 | | +--ro seq? uint32 631 | | +--ro oseq? uint32 632 | | +--ro bitmap? uint32 633 | +--ro replay_state_esn 634 | +--ro bmp-len? uint32 635 | +--ro oseq? uint32 636 | +--ro oseq-hi? uint32 637 | +--ro seq-hi? uint32 638 | +--ro replay-window? uint32 639 | +--ro bmp* uint32 641 rpcs: 642 +---x sadb_register 643 +---w input 644 | +---w base-list* [version] 645 | +---w version string 646 | +---w msg_type? sadb-msg-type 647 | +---w msg_satype? sadb-msg-satype 648 | +---w msg_seq? uint32 649 +--ro output 650 +--ro base-list* [version] 651 | +--ro version string 652 | +--ro msg_type? sadb-msg-type 653 | +--ro msg_satype? sadb-msg-satype 654 | +--ro msg_seq? uint32 655 +--ro algorithm-supported* 656 +--ro authentication 657 | +--ro name? integrity-algorithm-t 658 | +--ro ivlen? uint8 659 | +--ro min-bits? uint16 660 | +--ro max-bits? uint16 661 +--ro encryption 662 +--ro name? encryption-algorithm-t 663 +--ro ivlen? uint8 664 +--ro min-bits? uint16 665 +--ro max-bits? uint16 667 notifications: 668 +---n spdb_expire 669 | +--ro index? uint64 670 +---n sadb_acquire 671 | +--ro base-list* [version] 672 | +--ro version string 673 | +--ro msg_type? sadb-msg-type 674 | +--ro msg_satype? sadb-msg-satype 675 | +--ro msg_seq? uint32 676 +---n sadb_expire 677 | +--ro base-list* [version] 678 | | +--ro version string 679 | | +--ro msg_type? sadb-msg-type 680 | | +--ro msg_satype? sadb-msg-satype 681 | | +--ro msg_seq? uint32 682 | +--ro spi? ipsec-spi 683 | +--ro anti-replay-window? uint16 684 | +--ro state? sa-state 685 | +--ro encryption-algorithm? encryption-algorithm-t 686 | +--ro authentication-algorithm? integrity-algorithm-t 687 | +--ro sad-lifetime-hard 688 | | +--ro added? uint64 689 | | +--ro used? uint64 690 | | +--ro bytes? uint32 691 | | +--ro packets? uint32 692 | +--ro sad-lifetime-soft 693 | | +--ro added? uint64 694 | | +--ro used? uint64 695 | | +--ro bytes? uint32 696 | | +--ro packets? uint32 697 | +--ro sad-lifetime-current 698 | +--ro added? uint64 699 | +--ro used? uint64 700 | +--ro bytes? uint32 701 | +--ro packets? uint32 702 +---n sadb_bad-spi 703 +--ro state ipsec-spi 705 6.3. Peer Authorization Database (PAD) Model 707 The definition of this model has been extracted from the 708 specification in section 4.4.3 in [RFC4301] (NOTE: We have observed 709 that many implementations integrate PAD configuration as part of the 710 IKEv2 configuration.) 711 +--rw pad {case1}? 712 +--rw pad-entries* [pad-entry-id] 713 +--rw pad-entry-id uint64 714 +--rw (identity)? 715 | +--:(ipv4-address) 716 | | +--rw ipv4-address? inet:ipv4-address 717 | +--:(ipv6-address) 718 | | +--rw ipv6-address? inet:ipv6-address 719 | +--:(fqdn-string) 720 | | +--rw fqdn-string? inet:domain-name 721 | +--:(rfc822-address-string) 722 | | +--rw rfc822-address-string? string 723 | +--:(dnX509) 724 | | +--rw dnX509? string 725 | +--:(id_key) 726 | +--rw id_key? string 727 +--rw pad-auth-protocol? auth-protocol-type 728 +--rw auth-method 729 +--rw auth-m? auth-method-type 730 +--rw pre-shared 731 | +--rw secret? string 732 +--rw rsa-signature 733 +--rw key-data? string 734 +--rw key-file? string 735 +--rw ca-data* string 736 +--rw ca-file? string 737 +--rw cert-data? string 738 +--rw cert-file? string 739 +--rw crl-data? string 740 +--rw crl-file? string 742 6.4. Internet Key Exchange (IKEv2) Model 744 The model related to IKEv2 has been extracted from reading IKEv2 745 standard in [RFC7296], and observing some open source 746 implementations, such as Strongswan or Libreswan. 748 +--rw ikev2 {case1}? 749 | +--rw ike-connection 750 | | +--rw ike-conn-entries* [conn-name] 751 | | +--rw conn-name string 752 | | +--rw autostartup type-autostartup 753 | | +--rw nat-traversal? boolean 754 | | +--rw initial-contact? boolean 755 | | +--rw encap 756 | | | +--rw espencap? esp-encap 757 | | | +--rw sport? inet:port-number 758 | | | +--rw dport? inet:port-number 759 | | | +--rw oaddr? inet:ip-address 760 | | +--rw version? enumeration 761 | | +--rw phase1-lifetime uint32 762 | | +--rw phase1-authalg* integrity-algorithm-t 763 | | +--rw phase1-encalg* encryption-algorithm-t 764 | | +--rw combined-enc-intr? boolean 765 | | +--rw dh_group uint32 766 | | +--rw local 767 | | | +--rw (my-identifier-type)? 768 | | | | +--:(ipv4) 769 | | | | | +--rw ipv4? inet:ipv4-address 770 | | | | +--:(ipv6) 771 | | | | | +--rw ipv6? inet:ipv6-address 772 | | | | +--:(fqdn) 773 | | | | | +--rw fqdn? inet:domain-name 774 | | | | +--:(dn) 775 | | | | | +--rw dn? string 776 | | | | +--:(user_fqdn) 777 | | | | +--rw user_fqdn? string 778 | | | +--rw my-identifier string 779 | | +--rw remote 780 | | | +--rw (my-identifier-type)? 781 | | | | +--:(ipv4) 782 | | | | | +--rw ipv4? inet:ipv4-address 783 | | | | +--:(ipv6) 784 | | | | | +--rw ipv6? inet:ipv6-address 785 | | | | +--:(fqdn) 786 | | | | | +--rw fqdn? inet:domain-name 787 | | | | +--:(dn) 788 | | | | | +--rw dn? string 789 | | | | +--:(user_fqdn) 790 | | | | +--rw user_fqdn? string 791 | | | +--rw my-identifier string 792 | | +--rw pfs_group* uint32 793 | | +--rw ipsec-sad-lifetime-hard 794 | | | +--rw added? uint64 795 | | | +--rw used? uint64 796 | | | +--rw bytes? uint32 797 | | | +--rw packets? uint32 798 | | | +--rw action? lifetime-action 799 | | +--rw ipsec-sad-lifetime-soft 800 | | | +--rw added? uint64 801 | | | +--rw used? uint64 802 | | | +--rw bytes? uint32 803 | | | +--rw packets? uint32 804 | | | +--rw action? lifetime-action 805 | | +--ro ike-stats 806 | | +--ro uptime 807 | | | +--ro running? yang:date-and-time 808 | | | +--ro since? yang:date-and-time 809 | | +--ro initiator? boolean 810 | | +--ro initiator-spi? uint64 811 | | +--ro responder-spi? uint64 812 | | +--ro nat-local? boolean 813 | | +--ro nat-remote? boolean 814 | | +--ro nat-any? boolean 815 | | +--ro established? uint64 816 | | +--ro rekey-time? uint64 817 | | +--ro reauth-time? uint64 818 | | +--ro child-sas* 819 | | +--ro spis 820 | | +--ro spi-in? ipsec-spi 821 | | +--ro spi-out? ipsec-spi 822 | +--ro number-ike-sas 823 | +--ro total? uint32 824 | +--ro half-open? uint32 826 7. Use cases examples 828 This section explains how different traditional configurations, that 829 is, host-to-host and gateway-to-gateway are deployed using this SDN- 830 based IPsec management service. In turn, these configurations will 831 be typical in modern networks where, for example, virtualization will 832 be key. 834 7.1. Host-to-Host or Gateway-to-gateway under the same controller 835 +----------------------------------------+ 836 | Security Controller | 837 | | 838 (1)| +--------------+ (2)+--------------+ | 839 Flow-based ------> |Translate into|--->| South. Prot. | | 840 Security. Pol. | |IPsec Policies| | | | 841 | +--------------+ +--------------+ | 842 | | | | 843 | | | | 844 +--------------------------|-----|-------+ 845 | | 846 | (3) | 847 |-------------------------+ +---| 848 V V 849 +----------------------+ +----------------------+ 850 | NSF1 |<=======>| NSF2 | 851 |IKEv2/IPsec(SPD/PAD) | |IKEv2/IPsec(SPD/PAD) | 852 +----------------------+ (4) +----------------------+ 854 Figure 3: Host-to-Host / Gateway-to-Gateway single controller flow 855 for case 1 . 857 Figure 3 describes the case 1: 859 1. The administrator defines general flow-based security policies. 860 The Security Controller looks for the NSFs involved (NSF1 and 861 NSF2). 863 2. The Security Controller generates IKEv2 credentials for them and 864 translates the policies into SPD and PAD entries. 866 3. The Security Controller inserts the SPD and PAD entries in both 867 NSF1 and NSF2. 869 4. The flow is protected with the IPsec SA established with IKEv2. 871 +----------------------------------------+ 872 | (1) Security Controller | 873 Flow-based | | 874 Security -----------| | 875 Policy | V | 876 | +---------------+ (2)+-------------+ | 877 | |Translate into |--->| South. Prot.| | 878 | |IPsec policies | | | | 879 | +---------------+ +-------------+ | 880 | | | | 881 | | | | 882 +-------------------------| --- |--------+ 883 | | 884 | (3) | 885 |----------------------+ +--| 886 V V 887 +------------------+ +------------------+ 888 | NSF1 |<=====>| NSF2 | 889 |IPsec(SPD/SAD) | 4) |IPsec(SPD/SAD) | 890 +------------------+ +------------------+ 892 Figure 4: Host-to-Host / Gateway-to-Gateway single controller flow 893 for case 2. 895 In case 2, flow-based security policies defined by the administrator 896 are also translated into IPsec SPD entries and inserted into the 897 corresponding NSFs. Besides, fresh SAD entries will be also 898 generated by the Security Controller and enforced in the NSFs. In 899 this case the controller does not run any IKE implementation, and it 900 provides the cryptographic material for the IPsec SAs. These keys 901 will be also distributed securely through the southbound interface. 902 Note that this is possible because both NSFs are managed by the same 903 controller. 905 Figure 4 describes the case 2, when a data packet needs to be 906 protected in the path between the NSF1 and NSF2: 908 1. The administrator establishes the flow-based security policies. 909 The Security Controller looks for the involved NSFs. 911 2. The Security Controller translates the flow-based security 912 policies into IPsec SPD and SAD entries. 914 3. The Security Controller inserts the these entries in both NSF1 915 and NSF2 IPsec databases. 917 4. The flow is protected with the IPsec SA established by the 918 Security Controller. 920 Both NSFs could be two hosts that exchange traffic and require to 921 establish an end-to-end security association to protect their 922 communications (host-to-host) or two gateways (gateway-to-gateway)), 923 for example, within an enterprise that needs to protect the traffic 924 between, for example, the networks of two branch offices. 926 Applicability of these configurations appear in current and new 927 networking scenarios. For example, SD-WAN technologies are providing 928 dynamic and on-demand VPN connections between branch offices or 929 between branches and SaaS cloud services. Beside, IaaS services 930 providing virtualization environments are deployments solutions based 931 on IPsec to provide secure channels between virtual instances (Host- 932 to-Host) and providing VPN solutions for virtualized networks 933 (Gateway-to-Gateway). 935 In general (for case 1 and case 2), this system presents various 936 advantages: 938 1. It allows to create IPsec SAs among two NSFs, with only the 939 application of more general flow-based security policies at the 940 application layer. Thus, administrators can manage all security 941 associations in a centralized point with an abstracted view of 942 the network; 944 2. All NSFs deployed after the application of the new policies are 945 NOT manually configured, therefore allowing its deployment in an 946 automated manner. 948 7.2. Host-to-Host or Gateway-to-gateway under different Security 949 controllers 951 It is also possible that two NSFs (i.e. NSF1 and NSF2) are under the 952 control of two different Security Controllers. This may happen, for 953 example, when two organizations, namely Enterprise A and Enterprise 954 B, have their headquarters interconnected through a WAN connection 955 and they both have deployed a SDN-based architecture to provide 956 connectivity to all their clients. 958 +-------------+ +-------------+ 959 | | | | 960 Flow-based| Security |<===============>| Security <--Flow-based 961 Sec. Pol.--> Controller | (3) | Controller | Sec. Pol. 962 (1) | A | | B | (2) 963 +-------------+ +-------------+ 964 | | 965 | (4) (4) | 966 V V 967 +----------------------+ +----------------------+ 968 | NSF1 |<========>| NSF2 | 969 |IKEv2/IPsec(SPD/PAD) | |IKEv2/IPsec(SPD/PAD) | 970 +----------------------+ (5) +----------------------+ 972 Figure 5: Different Security Controllers in Case 1 974 Figure 5 describes case 1 when two Security Controllers are involved 975 in the process. 977 1. The A's administrator establishes general Flow-based Security 978 Policies in Security Controller A. 980 2. The B's administrator establishes general Flow-based Security 981 Policies in Security Controller B. 983 3. The Security Controller A realizes that protection is required 984 between the NSF1 and NSF2, but the NSF2 is under the control of 985 another Security Controller (Security Controller B), so it starts 986 negotiations with the other controller to agree on the IPsec SPD 987 policies and IKEv2 credentials for their respective NSFs. NOTE: 988 This may require extensions in the East/West interface. 990 4. Then, both Security Controllers enforce the IKEv2 credentials and 991 related parameters and the SPD and PAD entries in their 992 respective NSFs. 994 5. The flow is protected with the IPsec SAs established with IKEv2 995 between both NSFs. 997 +--------------+ +--------------+ 998 | | | | 999 Flow-based. ---> | <--- Flow-based 1000 Prot. | Security |<=================>| Security |Sec. 1001 Pol.(1)| Controller | (3) | Controller |Pol. (2) 1002 | A | | B | 1003 +--------------+ +--------------+ 1004 | | 1005 | (4) (4) | 1006 V V 1007 +------------------+ (5) +------------------+ 1008 | NSF1 |<==============>| NSF2 | 1009 |IPsec(SPD/SAD) | | IPsec(SPD/SAD) | 1010 +------------------+ +------------------+ 1012 Figure 6: Different Security Controllers in case 2 1014 Figure 5 describes case 2 when two Security Controllers are involved 1015 in the process. 1017 1. The A's administrator establishes general Flow Protection 1018 Policies in Security Controller A. 1020 2. The B's administrator establishes general Flow Protection 1021 Policies in Security Controller B. 1023 3. The Security Controller A realizes that the flow between NSF1 and 1024 NSF2 MUST be protected. Nevertheless, the controller notices 1025 that NSF2 is under the control of another Security Controller, so 1026 it starts negotiations with the other controller to agree on the 1027 IPsec SPD and SAD entries that define the IPsec SAs. NOTE: It 1028 would worth evaluating IKEv2 as the protocol for the East/West 1029 interface in this case. 1031 4. Once the Security Controllers have agreed on key material and the 1032 details of the IPsec SAs, they both enforce this information into 1033 their respective NSFs. 1035 5. The flow is protected with the IPsec SAs established by both 1036 Security Controllers in their respective NSFs. 1038 8. Implementation notes 1040 At the time of writing this document, we have implemented a proof-of- 1041 concept using NETCONF as southbound protocol, and the YANG model 1042 described in Appendix A. The netopeer implementation [netopeer] has 1043 been used for both case 1 and case 2 using host-to-host and gateway- 1044 to-gateway configuration. For the case 1, we have used Strongswan 1045 [strongswan] distribution for the IKE implementation. 1047 Note that the proposed YANG model provides the models for SPD, SAD, 1048 PAD and IKE, but, as describe before, only part of them are required 1049 depending of the case (1 or 2) been applied. The Security Controller 1050 should be able to know the kind of case to be applied in the NSF and 1051 to select the corresponding models based on the YANG features defines 1052 for each one. 1054 Internally to the NSF, the NETCONF server (that implements the I2NSF 1055 Agent) is able to apply the required configuration updating the 1056 corresponding NETCONF datastores (running, startup, etc.). Besides, 1057 it can deal with the SPD and SAD configuration at kernel level, 1058 through different APIs. For example, the IETF RFC 2367 (PF_KEYv2) 1059 [RFC2367] provides a generic key management API that can be used not 1060 only for IPsec but also for other network security services to manage 1061 the IPsec SAD. Besides, as an extension to this API, the document 1062 [I-D.pfkey-spd] specifies some PF_KEY extensions to maintain the SPD. 1063 This API is accessed using sockets. 1065 An alternative key management API based on Netlink socket API 1066 [RFC3549] is used to configure IPsec on the Linux Operating System. 1068 To allow the NETCONF server implementation interacts with the IKE 1069 daemon, we have used the Versatile IKE Configuration Interface (VICI) 1070 in Strongswan. This allows changes in the IKE part of the 1071 configuration data to be applied in the IKE daemon dynamically. 1073 9. Security Considerations 1075 First of all, this document shares all the security issues of SDN 1076 that are specified in the "Security Considerations" section of 1077 [ITU-T.Y.3300] and [RFC8192]. On the one hand, it is important to 1078 note that there must exit a security association between the Security 1079 Controller and the NSFs to protect of the critical information 1080 (cryptographic keys, configuration parameter, etc...) exchanged 1081 between these entities. For example, if NETCONF is used as 1082 southbound protocol between the Security Controller and the NSFs, it 1083 is defined that TLS or SSH security assocation must be established 1084 between both entities. On the other hand, we have divided this 1085 section in two parts to analyze different security considerations for 1086 both cases: NSF with IKEv2 (case 1) and NSF without IKEv2 (case 2). 1087 In general, the Security Controller, as typically in the SDN 1088 paradigm, is a target for different type of attacks. As a 1089 consequence, the Security Controller is a key entity in the 1090 infrastructure and MUST be protected accordingly. In particular, 1091 according to this document, the Security Controller will handle 1092 cryptographic material so that the attacker may try to access this 1093 information. Although, we can assume this attack will not likely to 1094 happen due to the assumed security measurements to protect the 1095 Security Controller, it deserves some analysis in the hypothetical 1096 the attack occurs. The impact is different depending on the case 1 1097 or case 2. 1099 9.1. Case 1 1101 In this case 1, the Security Controller sends IKE credentials (PSK, 1102 public/private keys, certificates, etc...) to the NSFs using the 1103 security association between Security Controller and NSFs. The 1104 general recommendation is that the Security Controller SHOULD NEVER 1105 store the IKE credentials after distributing them. Moreover the NSFs 1106 MUST NOT allow the reading of these values once they have been 1107 applied by the Security Controller (i.e. write only operations). If 1108 the attacker has access to the Security Controller during the period 1109 of time that key material is generated, it may access to these 1110 values. Since these values are used during NSF authentication in 1111 IKEv2, it may impersonate the affected NSFs. Several recommendations 1112 are important. If PSK authentication is used in IKEv2, the Security 1113 Controller SHOULD remove the PSK immediately after generating and 1114 distributing it. If raw public keys are used, the Security 1115 Controller SHOULD remove the associated private key immediately after 1116 generating and distributing them to the NSFs. If certificates are 1117 used, the NSF may generate the private key and exports the public key 1118 for certification in the Security Controller. 1120 9.2. Case 2 1122 In the case 2, the controller sends the IPsec SA information to the 1123 SAD that includes the keys for integrity and encryption (when ESP is 1124 used). That key material are symmetric keys to protect data traffic. 1125 The general recommendation is that the Security Controller SHOULD 1126 NEVER stores the keys after distributing them. Moreover the NSFs 1127 MUST NOT allow the reading of these values once they have been 1128 applied by the Security Controller (i.e. write only operations). 1129 Nevertheless, if the attacker has access to the Security Controller 1130 during the period of time that key material is generated, it may 1131 access to these values. In other words, it may have access to the 1132 key material used in the distributed IPsec SAs and observe the 1133 traffic between peers. In any case, some escenarios with special 1134 secure enviroments (e.g. physically isolated data centers) make this 1135 type of attack difficult. Moreover, some scenarios such as IoT 1136 networks with constrained devices, where reducing implementation and 1137 computation overhead is important, can apply case 2 as a tradeoff 1138 between security and low overhead at the constrained device, at the 1139 cost of assuming the security impact described above. 1141 10. Acknowledgements 1143 Authors want to thank Sowmini Varadhan, David Carrel, Yoav Nir, Tero 1144 Kivinen, Paul Wouters, Graham Bartlett, Sandeep Kampati, Linda 1145 Dunbar, Carlos J. Bernardos, Alejandro Perez-Mendez, Fernando 1146 Pereniguez-Garcia, Alejandro Abad-Carrascosa, Ignacio Martinez and 1147 Ruben Ricart for their valuable comments. 1149 11. References 1151 11.1. Normative References 1153 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1154 Requirement Levels", BCP 14, RFC 2119, 1155 DOI 10.17487/RFC2119, March 1997, 1156 . 1158 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1159 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 1160 December 2005, . 1162 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1163 IANA Considerations Section in RFCs", RFC 5226, 1164 DOI 10.17487/RFC5226, May 2008, 1165 . 1167 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 1168 Kivinen, "Internet Key Exchange Protocol Version 2 1169 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 1170 2014, . 1172 11.2. Informative References 1174 [I-D.ietf-i2nsf-framework] 1175 Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 1176 Kumar, "Framework for Interface to Network Security 1177 Functions", draft-ietf-i2nsf-framework-10 (work in 1178 progress), November 2017. 1180 [I-D.ietf-i2nsf-problem-and-use-cases] 1181 Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., 1182 and J. Jeong, "I2NSF Problem Statement and Use cases", 1183 draft-ietf-i2nsf-problem-and-use-cases-16 (work in 1184 progress), May 2017. 1186 [I-D.ietf-i2nsf-terminology] 1187 Hares, S., Strassner, J., Lopez, D., Xia, L., and H. 1188 Birkholz, "Interface to Network Security Functions (I2NSF) 1189 Terminology", draft-ietf-i2nsf-terminology-06 (work in 1190 progress), July 2018. 1192 [I-D.jeong-i2nsf-sdn-security-services-05] 1193 Jeong, J., Kim, H., Park, J., Ahn, T., and S. Lee, 1194 "Software-Defined Networking Based Security Services using 1195 Interface to Network Security Functions", draft-jeong- 1196 i2nsf-sdn-security-services-05 (work in progress), July 1197 2016. 1199 [I-D.pfkey-spd] 1200 Sakane, S., "PF_KEY Extensions for IPsec Policy Management 1201 in KAME Stack", October 2002. 1203 [I-D.sivakumar-yang-nat] 1204 Sivakumar, S., Boucadair, M., and S. Vinapamula, "YANG 1205 Data Model for Network Address Translation (NAT)", draft- 1206 sivakumar-yang-nat-07 (work in progress), July 2017. 1208 [I-D.tran-ipsecme-yang] 1209 Tran, K., Wang, H., Nagaraj, V., and X. Chen, "Yang Data 1210 Model for Internet Protocol Security (IPsec)", draft-tran- 1211 ipsecme-yang-01 (work in progress), June 2015. 1213 [ITU-T.X.1252] 1214 "Baseline Identity Management Terms and Definitions", 1215 April 2010. 1217 [ITU-T.X.800] 1218 "Security Architecture for Open Systems Interconnection 1219 for CCITT Applications", March 1991. 1221 [ITU-T.Y.3300] 1222 "Recommendation ITU-T Y.3300", June 2014. 1224 [netconf-vpn] 1225 Stefan Wallin, "Tutorial: NETCONF and YANG", January 2014. 1227 [netopeer] 1228 CESNET, CESNET., "NETCONF toolset Netopeer", November 1229 2016. 1231 [ONF-OpenFlow] 1232 ONF, "OpenFlow Switch Specification (Version 1.4.0)", 1233 October 2013. 1235 [ONF-SDN-Architecture] 1236 "SDN Architecture", June 2014. 1238 [RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key 1239 Management API, Version 2", RFC 2367, 1240 DOI 10.17487/RFC2367, July 1998, 1241 . 1243 [RFC3549] Salim, J., Khosravi, H., Kleen, A., and A. Kuznetsov, 1244 "Linux Netlink as an IP Services Protocol", RFC 3549, 1245 DOI 10.17487/RFC3549, July 2003, 1246 . 1248 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 1249 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 1250 RFC 3948, DOI 10.17487/RFC3948, January 2005, 1251 . 1253 [RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and 1254 Internet Key Exchange (IKE) Document Roadmap", RFC 6071, 1255 DOI 10.17487/RFC6071, February 2011, 1256 . 1258 [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined 1259 Networking: A Perspective from within a Service Provider 1260 Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, 1261 . 1263 [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for 1264 System Management", RFC 7317, DOI 10.17487/RFC7317, August 1265 2014, . 1267 [RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., 1268 and J. Jeong, "Interface to Network Security Functions 1269 (I2NSF): Problem Statement and Use Cases", RFC 8192, 1270 DOI 10.17487/RFC8192, July 2017, 1271 . 1273 [RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation 1274 of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229, 1275 August 2017, . 1277 [strongswan] 1278 CESNET, CESNET., "StrongSwan: the OpenSource IPsec-based 1279 VPN Solution", April 2017. 1281 Appendix A. Appendix A: YANG model IPsec Configuration data 1283 file "ietf-ipsec@2018-10-20.yang" 1284 module ietf-ipsec { 1286 namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec"; 1288 prefix "eipsec"; 1290 import ietf-inet-types { prefix inet; } 1291 import ietf-yang-types { prefix yang; } 1293 organization "University of Murcia"; 1295 contact 1296 " Rafael Marin Lopez 1297 Dept. Information and Communications Engineering (DIIC) 1298 Faculty of Computer Science-University of Murcia 1299 30100 Murcia - Spain 1300 Telf: +34868888501 1301 e-mail: rafa@um.es 1303 Gabriel Lopez Millan 1304 Dept. Information and Communications Engineering (DIIC) 1305 Faculty of Computer Science-University of Murcia 1306 30100 Murcia - Spain 1307 Tel: +34 868888504 1308 email: gabilm@um.es 1309 "; 1311 description "Data model for IPSec"; 1313 revision "2018-10-20" { 1314 description 1315 "Revision"; 1316 reference ""; 1317 } 1319 feature case1 { description "feature case 1: IKE SPD PAD"; } // IKE/IPSec in the NSFs 1320 feature case2 { description "feature case 2: SPD SAD"; } // Only IPSec in the NSFs 1322 typedef encryption-algorithm-t { 1324 type enumeration { 1325 enum reserved-0 {description "reserved";} 1326 enum des-iv4 { description "DES IV 4";} 1327 enum des { description "DES"; } 1328 enum 3des { description "3DES"; } 1329 enum rc5 { description "RC5"; } 1330 enum idea { description "IDEA"; } 1331 enum cast { description "CAST"; } 1332 enum blowfish { description "BlowFish"; } 1333 enum 3idea { description "3IDEA"; } 1334 enum des-iv32 { description "DES-IV32"; } 1335 enum reserved-10 { description "reserved-10"; } 1336 enum null { description "NULL"; } 1337 enum aes-cbc { description "AES-CBC"; } 1338 enum aes-ctr { description "AES-CTR"; } 1339 enum aes-ccm-8 { description "AES-CCM-8"; } 1340 enum aes-ccm-12 { description "AES-CCM-12"; } 1341 enum aes-ccm-16 { description "AES-CCM-16"; } 1342 enum reserved-17 { description "reserved-17"; } 1343 enum aes-gcm-8-icv { description "AES-GCM-8-ICV"; } 1344 enum aes-gcm-12-icv { description "AES-GCM-12-ICV"; } 1345 enum aes-gcm-16-icv { description "AES-GCM-16-ICV"; } 1346 enum null-auth-aes-gmac { description "Null-Auth-AES-GMAC"; } 1347 enum ieee-p1619-xts-aes { description "encr-ieee-p1619-xts-aes -> Reserved for IEEE P1619 XTS-AES.";} 1348 enum camellia-cbc { description "CAMELLIA-CBC"; } 1349 enum camellia-ctr { description "CAMELLIA.CTR"; } 1350 enum camellia-ccm-8-icv { description "CAMELLIA-CCM-8-ICV"; } 1351 enum camellia-ccm-12-icv { description "CAMELLIA-CCM-12-ICV"; } 1352 enum camellia-ccm-16-icv { description "CAMELLIA-CCM-16-ICV"; } 1353 enum aes-cbc-128 { description "AES-CBC-128"; } 1354 enum aes-cbc-192 { description "AES-CBC-192"; } 1355 enum aes-cbc-256 { description "AES-CBC-256"; } 1356 enum blowfish-128 { description "BlowFish-128"; } 1357 enum blowfish-192 { description "BlowFish-192"; } 1358 enum blowfish-256 { description "BlowFish-256"; } 1359 enum blowfish-448 { description "BlowFish-448"; } 1360 enum camellia-128 { description "CAMELLIA-128"; } 1361 enum camellia-192 { description "CAMELLIA-192"; } 1362 enum camellia-256 { description "CAMELLIA-256"; } 1363 } 1364 description "Encryption algorithms -> RFC_5996"; 1365 } 1367 typedef integrity-algorithm-t { 1369 type enumeration { 1370 enum none { description "NONE"; } 1371 enum hmac-md5-96 { description "HMAC-MD5-96"; } 1372 enum hmac-sha1-96 { description "HMAC-SHA1-96"; } 1373 enum des-mac { description "DES-MAC"; } 1374 enum kpdk-md5 {description "KPDK-MD5"; } 1375 enum aes-xcbc-96 { description "AES-XCBC-96"; } 1376 enum hmac-md5-128 { description "HMAC-MD5-128"; } 1377 enum hmac-sha1-160 { description "HMAC-SHA1-160"; } 1378 enum aes-cmac-96 { description "AES-CMAC-96"; } 1379 enum aes-128-gmac { description "AES-128-GMAC"; } 1380 enum aes-192-gmac { description "AES-192-GMAC"; } 1381 enum aes-256-gmac { description "AES-256-GMAC"; } 1382 enum hmac-sha2-256-128 { description "HMAC-SHA2-256-128"; } 1383 enum hmac-sha2-384-192 { description "HMAC-SHA2-384-192"; } 1384 enum hmac-sha2-512-256 { description "HMAC-SHA2-512-256"; } 1385 enum hmac-sha2-256-96 { description "HMAC-SHA2-256-096"; } 1386 } 1387 description "Integrity Algorithms -> RFC_5996"; 1388 } 1390 typedef type-autostartup { 1391 type enumeration { 1392 enum ALWAYSON { description " ";} 1393 enum INITIATE-ON-DEMAND {description " ";} 1394 enum RESPOND-ONLY {description " ";} 1395 } 1396 description "Different types of how IKEv2 starts the IPsec SAs"; 1397 } 1399 typedef auth-protocol-type { 1400 type enumeration { 1401 enum IKEv1 { description "Authentication protocol based on IKEv1"; } 1402 enum IKEv2 { description "Authentication protocol based on IKEv2"; } 1403 enum KINK { description "Authentication protocol based on KINK"; } 1404 } 1405 description "Peer authentication protocols"; 1406 } 1408 typedef ipsec-mode { 1409 type enumeration { 1410 enum TRANSPORT { description "Transport mode"; } 1411 enum TUNNEL { description "Tunnel mode"; } 1412 enum BEET { description "Bound End-to-End Tunnel (BEET) mode for ESP.";} 1413 enum RO { description "Route Optimization mode for Mobile IPv6";} 1414 enum IN_TRIGGER {description "In trigger mode for Mobile IPv6";} 1415 } 1416 description "type define of ipsec mode"; 1417 } 1419 typedef esp-encap { 1420 type enumeration { 1421 enum ESPINTCP { description "ESP in TCP encapulation.";} 1422 enum ESPINTLS { description "ESP in TCP encapsulation using TLS.";} 1423 enum ESPINUDP { description "ESP in UDP encapsulation. RFC 3948 ";} 1424 } 1425 description "type defining types of ESP encapsulation"; 1426 } 1428 typedef ipsec-protocol { 1429 type enumeration { 1430 enum ah { description "AH Protocol"; } 1431 enum esp { description "ESP Protocol"; } 1432 enum comp { description "IP Compression";} /*Supported by XFRM*/ 1433 enum route2 { description "Routing Header type 2. Mobile IPv6";} /*Supported by XFRM*/ 1434 enum hao {description "Home Agent Option";} /*Supported by XFRM*/ 1435 } 1436 description "type define of ipsec security protocol"; 1437 } 1439 typedef ipsec-spi { 1440 type uint32 { range "0..max"; } 1441 description "SPI"; 1442 } 1444 typedef lifetime-action { 1445 type enumeration { 1446 enum terminate {description "Terminate the IPsec SA";} 1447 enum replace {description "Replace the IPsec SA with a new one";} 1448 } 1449 description "Action when lifetime expiration"; 1450 } 1452 typedef ipsec-traffic-direction { 1453 type enumeration { 1454 enum INBOUND { description "Inbound traffic"; } 1455 enum OUTBOUND { description "Outbound traffic"; } 1456 enum FORWARD{ description "Forwarded traffic"; } 1457 } 1458 description "IPsec traffic direction"; 1459 } 1461 typedef ipsec-spd-operation { 1462 type enumeration { 1463 enum PROTECT { description "PROTECT the traffic with IPsec"; } 1464 enum BYPASS { description "BYPASS the traffic"; } 1465 enum DISCARD { description "DISCARD the traffic"; } 1466 } 1467 description "The operation when traffic matches IPsec security policy"; 1469 } 1471 typedef ipsec-next-layer-proto { 1472 type enumeration { 1473 enum TCP { description "PROTECT the traffic with IPsec"; } 1474 enum UDP { description "BYPASS the traffic"; } 1475 enum SCTP { description "PROTECT the traffic with IPsec";} 1476 enum DCCP { description "PROTECT the traffic with IPsec";} 1477 enum ICMP { description "PROTECT the traffic with IPsec";} 1478 enum IPv6-ICMP { description "PROTECT the traffic with IPsec";} 1479 enum MH {description "PROTECT the traffic with IPsec";} 1480 enum GRE {description "PROTECT the traffic with IPsec";} 1481 } 1482 description "Next layer proto on top of IP"; 1483 } 1485 typedef ipsec-spd-name { 1486 type enumeration { 1487 enum id_rfc_822_addr { description "Fully qualified user name string."; } 1488 enum id_fqdn { description "Fully qualified DNS name."; } 1489 enum id_der_asn1_dn { description "X.500 distinguished name."; } 1490 enum id_key { description "IKEv2 Key ID."; } 1491 } 1492 description "IPsec SPD name type"; 1493 } 1495 typedef auth-method-type { 1496 /* Most implementations also provide XAUTH protocol, others used are: BLISS, P12, NTLM, PIN */ 1497 type enumeration { 1498 enum pre-shared { description "Select pre-shared key message as the authentication method"; } 1499 enum rsa-signature { description "Select rsa digital signature as the authentication method"; } 1500 enum dss-signature { description "Select dss digital signature as the authentication method"; } 1501 enum eap { description "Select EAP as the authentication method"; } 1502 } 1503 description "Peer authentication method"; 1504 } 1506 typedef sa-state { 1507 type enumeration { 1508 enum Larval { description "SA larval state";} 1509 enum Mature { description "SA mature state";} 1510 enum Dying { description "SA dying state";} 1511 enum Dead { description "SA dead state";} 1512 } 1513 description "Security Association state"; 1514 } 1516 grouping lifetime { 1517 description "lifetime current state data"; 1518 leaf added {type uint64; default 0; description "added time and date";} 1519 leaf used {type uint64; default 0; description "used time and date";} 1520 leaf bytes { type uint32; default 0; description "current lifetime bytes";} 1521 leaf packets {type uint32; default 0; description "current lifetime packets";} 1522 } 1524 /*################## PAD grouping ####################*/ 1526 grouping auth-method-grouping { 1527 description "Peer authentication method data"; 1529 container auth-method { 1530 description "Peer authentication method container"; 1532 leaf auth-m { type auth-method-type; description "Type of authentication method (preshared, rsa, etc.)"; } 1534 container pre-shared { 1535 when "../auth-m = 'pre-shared'"; 1536 leaf secret { type string; description "Pre-shared secret value";} 1537 description "Shared secret value"; 1538 } 1540 container rsa-signature { 1541 when "../auth-m = 'rsa-signature'"; 1542 leaf key-data { type string; description "RSA private key data - PEM"; } 1543 leaf key-file { type string; description "RSA private key file name "; } 1544 leaf-list ca-data { type string; description "List of trusted CA certs - PEM"; } 1545 leaf ca-file { type string; description "List of trusted CA certs file"; } 1546 leaf cert-data { type string; description "X.509 certificate data - PEM4"; } 1547 leaf cert-file { type string; description "X.509 certificate file"; } 1548 leaf crl-data { type string; description "X.509 CRL certificate data in base64"; } 1549 leaf crl-file { type string; description " X.509 CRL certificate file"; } 1550 description "RSA signature container"; 1551 } 1552 } 1553 } 1555 grouping identity-grouping { 1556 description "Identification type. It is an union identity"; 1557 choice identity { 1558 description "Choice of identity."; 1560 leaf ipv4-address { type inet:ipv4-address; description "Specifies the identity as a single four (4) octet IPv4 address. An example is, 10.10.10.10. "; } 1561 leaf ipv6-address { type inet:ipv6-address; description "Specifies the identity as a single sixteen (16) octet IPv6 address. An example is FF01::101, 2001:DB8:0:0:8:800:200C:417A ."; } 1562 leaf fqdn-string { type inet:domain-name; description "Specifies the identity as a Fully-Qualified Domain Name (FQDN) string. An example is: example.com. The string MUST not contain any terminators (e.g., NULL, CR, etc.)."; } 1563 leaf rfc822-address-string { type string; description "Specifies the identity as a fully-qualified RFC822 email address string. An example is, jsmith@example.com. The string MUST not contain any terminators (e.g., NULL, CR, etc.)."; } 1564 leaf dnX509 { type string; description "Specifies the identity as a distinguished name in the X.509 tradition."; } 1565 leaf id_key { type string; description "Key id"; 1566 } /* From RFC4301 list of id types */ 1567 } 1568 } /* grouping identity-grouping */ 1570 /*################ end PAD grouping ##################*/ 1572 /*################## SAD and SPD grouping ####################*/ 1574 grouping ip-addr-range { 1575 description "IP address range grouping"; 1576 leaf start { type inet:ip-address; description "Start IP address"; } 1577 leaf end { type inet:ip-address; description "End IP address"; } 1578 } 1580 grouping port-range { 1581 description "Port range grouping"; 1582 leaf start { type inet:port-number; description "Start IP address"; } 1583 leaf end { type inet:port-number; description "End IP address"; } 1584 } 1586 grouping tunnel-grouping { 1587 description "Tunnel mode grouping"; 1588 leaf local{ type inet:ip-address; description "Local tunnel endpoint"; } 1589 leaf remote{ type inet:ip-address; description "Remote tunnel enpoint"; } 1590 leaf bypass-df { type boolean; description "bypass DF bit"; } 1591 leaf bypass-dscp { type boolean; description "bypass DSCP"; } 1592 leaf dscp-mapping { type yang:hex-string; description "DSCP mapping"; } 1593 leaf ecn { type boolean; description "Bit ECN"; } /* RFC 4301 ASN1 notation. Annex C*/ 1594 } 1596 grouping selector-grouping { 1597 description "Traffic selector grouping"; 1598 list local-addresses { 1599 key "start end"; 1600 uses ip-addr-range; 1601 description "List of local addresses"; 1602 } 1603 list remote-addresses { 1604 key "start end"; 1605 uses ip-addr-range; 1606 description "List of remote addresses"; 1607 } 1608 leaf-list next-layer-protocol { type ipsec-next-layer-proto; description "List of Next Layer Protocol";} 1609 list local-ports { 1610 key "start end"; 1611 uses port-range; 1612 description "List of local ports"; 1613 } 1614 list remote-ports { 1615 key "start end"; 1616 uses port-range; 1617 description "List of remote ports"; 1618 } 1619 } 1621 /*################## SAD grouping ####################*/ 1622 grouping ipsec-sa-grouping { 1623 description "Configure Security Association (SA). Section 4.4.2.1 in RFC 4301"; 1625 leaf spi { type ipsec-spi; description "Security Parameter Index";} 1626 leaf seq-number { type uint64; description "Current sequence number of IPsec packet."; } 1627 leaf seq-number-overflow-flag { type boolean; description "The flag indicating whether overflow of the sequence number counter should prevent transmission of additional packets on the SA, or whether rollover is permitted."; } 1628 leaf anti-replay-window { type uint16 { range "0 | 32..1024"; } description "Anti replay window size"; } 1629 leaf rule-number {type uint32; description "This value links the SA with the SPD entry";} 1631 uses selector-grouping; 1633 leaf security-protocol { type ipsec-protocol; description "Security protocol of IPsec SA: Either AH or ESP."; } 1635 container ah-sa { 1636 when "../security-protocol = 'ah'"; 1637 description "Configure Authentication Header (AH) for SA"; 1638 container integrity { 1639 description "Configure integrity for IPSec Authentication Header (AH)"; 1640 leaf integrity-algorithm { type integrity-algorithm-t; description "Configure Authentication Header (AH)."; } 1641 leaf key { type string; description "AH key value";} 1642 } 1643 } 1645 container esp-sa { 1646 when "../security-protocol = 'esp'"; 1647 description "Set IPSec Encapsulation Security Payload (ESP)"; 1649 container encryption { 1650 description "Configure encryption for IPSec Encapsulation Secutiry Payload (ESP)"; 1651 leaf encryption-algorithm { type encryption-algorithm-t; description "Configure ESP encryption"; } 1652 leaf key { type string; description "ESP encryption key value";} 1653 leaf iv {type string; description "ESP encryption IV value"; } 1654 } 1656 container integrity { 1657 description "Configure authentication for IPSec Encapsulation Secutiry Payload (ESP)"; 1658 leaf integrity-algorithm { type integrity-algorithm-t; description "Configure Authentication Header (AH)."; } 1659 leaf key { type string; description "ESP integrity key value";} 1660 } 1662 leaf combined-enc-intr { type boolean; description "ESP combined mode algorithms. The algorithm is specified in encryption-algorithm in the container encryption";} 1663 } 1665 container sad-lifetime-hard { 1666 description "SAD lifetime hard state data"; 1667 uses lifetime; 1668 leaf action {type lifetime-action; description "action lifetime";} 1669 } 1671 container sad-lifetime-soft { 1672 description "SAD lifetime hard state data"; 1673 uses lifetime; 1674 leaf action {type lifetime-action; description "action lifetime";} 1675 } 1677 leaf mode { type ipsec-mode; description "SA Mode"; } 1678 leaf statefulfragCheck { type boolean; description "TRUE stateful fragment checking, FALSE no stateful fragment checking"; } 1679 leaf dscp { type yang:hex-string; description "DSCP value"; } 1680 leaf path-mtu { type uint16; description "Maximum size of an IPsec packet that can be transmitted without fragmentation"; } 1682 container tunnel { 1683 when "../mode = 'TUNNEL'"; 1684 uses tunnel-grouping; 1685 description "Container for tunnel grouping"; 1686 } 1688 container encap { /* This is defined by XFRM */ 1689 description "Encapsulation container"; 1690 leaf espencap { type esp-encap; description "ESP in TCP, ESP in UDP or ESP in TLS";} 1691 leaf sport {type inet:port-number; description "Encapsulation source port";} 1692 leaf dport {type inet:port-number; description "Encapsulation destination port"; } 1693 leaf oaddr {type inet:ip-address; description "Encapsulation Original Address ";} 1694 } 1696 // STATE DATA for SA 1697 container sad-lifetime-current { 1698 uses lifetime; 1699 config false; 1700 description "SAD lifetime current state data"; 1701 } 1703 leaf state {type sa-state; config false; description "current state of SA (mature, larval, dying or dead)"; } 1705 container stats { // xfrm.h 1706 leaf replay-window {type uint32; default 0; description " "; } 1707 leaf replay {type uint32; default 0; description "packets detected out of the replay window and dropped because they are replay packets";} 1708 leaf failed {type uint32; default 0; description "packets detected out of the replay window ";} 1709 config false; 1710 description "SAD statistics"; 1711 } 1713 container replay_state { // xfrm.h 1715 leaf seq {type uint32; default 0; description "input traffic sequence number when anti-replay-window != 0";} 1716 leaf oseq {type uint32; default 0; description "output traffic sequence number";} 1717 leaf bitmap {type uint32; default 0; description "";} 1718 config false; 1719 description "Anti-replay Sequence Number state"; 1720 } 1722 container replay_state_esn { // xfrm.h 1723 leaf bmp-len {type uint32; default 0; description "bitmap length for ESN"; } 1724 leaf oseq { type uint32; default 0; description "output traffic sequence number"; } 1725 leaf oseq-hi { type uint32; default 0; description ""; } 1726 leaf seq-hi { type uint32; default 0; description ""; } 1727 leaf replay-window {type uint32; default 0; description ""; } 1728 leaf-list bmp { type uint32; description "bitmaps for ESN (depends on bmp-len) "; } 1729 config false; 1730 description "Anti-replay Extended Sequence Number (ESN) state"; 1731 } 1733 } 1735 /*################## end SAD grouping ##################*/ 1737 /*################## SPD grouping ####################*/ 1739 grouping ipsec-policy-grouping { 1740 description "Holds configuration information for an IPSec SPD entry."; 1742 leaf rule-number { type uint64; description "SPD index. RFC4301 does not mention an index however real implementations provide a policy index/or id to refer a policy. "; } 1743 leaf priority {type uint32; default 0; description "Policy priority";} 1745 list names { 1746 key "name"; 1747 leaf name-type { type ipsec-spd-name; description "SPD name type."; } 1748 leaf name { type string; description "Policy name"; } 1749 description "List of policy names"; 1750 } 1752 container condition { 1753 description "SPD condition -> RFC4301"; 1754 list traffic-selector-list { 1755 key "ts-number"; 1756 leaf ts-number { type uint32; description "Traffic selector number"; } 1757 leaf direction { type ipsec-traffic-direction; description "in/fwd/out"; } 1758 uses selector-grouping; 1759 leaf selector-priority {type uint32; default 0; description "It establishes a priority to the traffic selector";} 1760 ordered-by user; 1761 description "List of traffic selectors"; 1762 } 1763 } 1765 container processing-info { 1766 description "SPD processing -> RFC4301"; 1767 leaf action{ type ipsec-spd-operation; mandatory true; description "If the action is bypass or discard processing container ipsec-sa-cfg is empty";} 1769 container ipsec-sa-cfg { 1770 when "../action = 'PROTECT'"; 1771 leaf pfp-flag { type boolean; description "Each selector has with a pfp flag."; } 1772 leaf extSeqNum { type boolean; description "TRUE 64 bit counter, FALSE 32 bit"; } 1773 leaf seqOverflow { type boolean; description "TRUE rekey, FALSE terminare & audit"; } 1774 leaf statefulfragCheck { type boolean; description "TRUE stateful fragment checking, FALSE no stateful fragment checking"; } 1775 leaf security-protocol { type ipsec-protocol; description "Security protocol of IPsec SA: Either AH or ESP."; } 1776 leaf mode { type ipsec-mode; description "transport/tunnel"; } 1778 container ah-algorithms { 1779 when "../security-protocol = 'ah'"; 1780 leaf-list ah-algorithm { type integrity-algorithm-t; description "Configure Authentication Header (AH)."; } 1781 description "AH algoritms "; 1782 } 1784 container esp-algorithms { 1785 when "../security-protocol = 'esp'"; 1786 description "Configure Encapsulating Security Payload (ESP)."; 1787 leaf-list authentication { type integrity-algorithm-t; description "Configure ESP authentication"; } 1788 leaf-list encryption { type encryption-algorithm-t; description "Configure ESP encryption"; } 1789 } 1791 container tunnel { 1792 when "../mode = 'TUNNEL'"; 1793 uses tunnel-grouping; 1794 description "tunnel grouping container"; 1795 } 1796 description " IPSec SA configuration container"; 1798 } 1799 } 1801 container spd-mark { 1802 description "policy: mark MARK mask MASK "; 1803 leaf mark { type uint32; default 0; description "mark value";} 1804 leaf mask { type yang:hex-string; default 00:00:00:00; description "mask value 0x00000000";} 1805 } 1807 container spd-lifetime-hard { 1808 description "SPD lifetime hard state data"; 1809 uses lifetime; 1810 leaf action {type lifetime-action; description "action lifetime";} 1811 } 1813 container spd-lifetime-soft { 1814 description "SPD lifetime hard state data"; 1815 uses lifetime; 1816 leaf action {type lifetime-action; description "action lifetime";} 1817 } 1819 // State data 1820 container spd-lifetime-current { 1821 uses lifetime; 1822 config false; 1823 description "SPD lifetime current state data"; 1824 } 1826 } /* grouping ipsec-policy-grouping */ 1828 /*################ end SPD grouping ##################*/ 1830 /*################## IKEv2-grouping ##################*/ 1832 grouping isakmp-proposal { 1833 description "ISAKMP proposal grouping"; 1834 leaf phase1-lifetime { type uint32; mandatory true; description "lifetime for IKE Phase 1 SAs";} 1835 leaf-list phase1-authalg { type integrity-algorithm-t; description "Auth algorigthm for IKE Phase 1 SAs";} 1836 leaf-list phase1-encalg { type encryption-algorithm-t; description "Auth algorigthm for IKE Phase 1 SAs";} 1837 leaf combined-enc-intr { type boolean; description "Combined mode algorithms (encryption and integrity).";} 1838 leaf dh_group { type uint32; mandatory true; description "Group number for Diffie Hellman Exponentiation";} 1839 } /* list isakmp-proposal */ 1841 grouping phase2-info { 1842 description "IKE Phase 2 Information"; 1843 leaf-list pfs_group { type uint32; description "If non-zero, require perfect forward secrecy when requesting new SA. The non-zero value is the required group number"; } 1845 container ipsec-sad-lifetime-hard { 1846 description "IPsec SA lifetime hard"; 1847 uses lifetime; 1848 leaf action {type lifetime-action; description "action lifetime";} 1849 } 1851 container ipsec-sad-lifetime-soft { 1852 description "IPsec SA lifetime soft"; 1853 uses lifetime; 1854 leaf action {type lifetime-action; description "action lifetime";} 1855 } 1857 } 1859 grouping local-grouping { 1860 description "Configure the local peer in an IKE connection"; 1862 container local { 1863 description "Local container"; 1864 choice my-identifier-type { 1865 default ipv4; 1866 case ipv4 { 1867 leaf ipv4 { type inet:ipv4-address; description "IPv4 dotted-decimal address"; } 1868 } 1869 case ipv6 { 1870 leaf ipv6 { type inet:ipv6-address; description "numerical IPv6 address"; } 1871 } 1872 case fqdn { 1873 leaf fqdn { type inet:domain-name; description "Fully Qualifed Domain name "; } 1874 } 1875 case dn { 1876 leaf dn { type string; description "Domain name"; } 1877 } 1878 case user_fqdn { 1879 leaf user_fqdn { type string; description "User FQDN"; } 1880 } 1881 description "Local ID type"; 1882 } 1883 leaf my-identifier { type string; mandatory true; description "Local id used for authentication";} 1884 } 1885 } // local-grouping 1887 grouping remote-grouping { 1888 description "Configure the remote peer in an IKE connection"; 1890 container remote { 1891 description "Remote container"; 1892 choice my-identifier-type { 1893 default ipv4; 1894 case ipv4 { 1895 leaf ipv4 { type inet:ipv4-address; description "IPv4 dotted-decimal address"; } 1896 } 1897 case ipv6 { 1898 leaf ipv6 { type inet:ipv6-address; description "numerical IPv6 address"; } 1899 } 1900 case fqdn { 1901 leaf fqdn { type inet:domain-name; description "Fully Qualifed Domain name "; } 1902 } 1903 case dn { 1904 leaf dn { type string; description "Domain name"; } 1905 } 1906 case user_fqdn { 1907 leaf user_fqdn { type string; description "User FQDN"; } 1908 } 1909 description "Local ID type"; 1910 } 1911 leaf my-identifier { type string; mandatory true; description "Local id used for authentication"; } 1912 } 1913 } // remote-grouping 1915 /*################## End IKEv2-groupingUMU ##################*/ 1917 /*################# Register grouping #################*/ 1919 typedef sadb-msg-type { 1921 type enumeration { 1922 enum sadb_reserved { description "SADB_RESERVED";} 1923 enum sadb_getspi { description "SADB_GETSPI";} 1924 enum sadb_update { description "SADB_UPDATE";} 1925 enum sadb_add { description "SADB_ADD";} 1926 enum sadb_delete { description "SADB_DELETE"; } 1927 enum sadb_get { description "SADB_GET"; } 1928 enum sadb_acquire { description "SADB_ACQUIRE"; } 1929 enum sadb_register { description "SADB_REGISTER"; } 1930 enum sadb_expire { description "SADB_EXPIRE"; } 1931 enum sadb_flush { description "SADB_FLUSH"; } 1932 enum sadb_dump { description "SADB_DUMP"; } 1933 enum sadb_x_promisc { description "SADB_X_PROMISC"; } 1934 enum sadb_x_pchange { description "SADB_X_PCHANGE"; } 1935 enum sadb_max{ description "SADB_MAX"; } 1936 } 1937 description "PF_KEY base message types"; 1938 } 1940 typedef sadb-msg-satype { 1941 type enumeration { 1942 enum sadb_satype_unspec { description "SADB_SATYPE_UNSPEC"; } 1943 enum sadb_satype_ah { description "SADB_SATYPE_AH"; } 1944 enum sadb_satype_esp { description "SADB_SATYPE_ESP"; } 1945 enum sadb_satype_rsvp { description "SADB_SATYPE_RSVP"; } 1946 enum sadb_satype_ospfv2 { description "SADB_SATYPE_OSPFv2"; } 1947 enum sadb_satype_ripv2 { description "SADB_SATYPE_RIPv2"; } 1948 enum sadb_satype_mip { description "SADB_SATYPE_MIP"; } 1949 enum sadb_satype_max { description "SADB_SATYPE_MAX"; } 1950 } 1951 description "PF_KEY Security Association types"; 1952 } 1954 grouping base-grouping { 1955 description "Configuration for the message header format"; 1956 list base-list { 1957 key "version"; 1958 leaf version { type string; description "Version of PF_KEY (MUST be PF_KEY_V2)"; } 1959 leaf msg_type { type sadb-msg-type; description "Identifies the type of message"; } 1960 leaf msg_satype { type sadb-msg-satype; description "Defines the type of Security Association"; } 1961 leaf msg_seq { type uint32; description "Sequence number of this message."; } 1962 description "Configuration for a specific message header format"; 1963 } 1964 } 1966 grouping algorithm-grouping { 1967 description "List of supported authentication and encryptation algorithms"; 1969 container algorithm-supported { 1970 description "lists of encryption and authentication algorithms"; 1971 list enc-algs { 1972 key "name"; 1973 leaf name { type encryption-algorithm-t; description "Name of encryption algorithm"; } 1974 leaf ivlen { type uint8; description "Length of the initialization vector to be used for the algorithm"; } 1975 leaf min-bits { type uint16; description "The minimun acceptable key length, in bits"; } 1976 leaf max-bits { type uint16; description "The maximun acceptable key length, in bits"; } 1977 description "list of encryption algorithm supported "; 1978 } 1979 list auth-algs { 1980 key "name"; 1981 leaf name { type integrity-algorithm-t; description "Name of authentication algorithm";} 1982 leaf ivlen { type uint8; description "Length of the initialization vector to be used for the algorithm"; } 1983 leaf min-bits { type uint16; description "The minimun acceptable key length, in bits"; } 1984 leaf max-bits { type uint16; description "The maximun acceptable key length, in bits"; } 1985 description "list of authentication algorithm supported "; 1986 } 1987 } 1988 } 1989 /*################# End Register grouping #################*/ 1991 /*################## ipsec ##################*/ 1993 container ietf-ipsec { 1994 description "Main IPsec container "; 1996 container ikev2 { 1997 if-feature case1; 1998 description "Configure the IKEv2"; 2000 container ike-connection { 2001 description "IKE connections configuration"; 2003 list ike-conn-entries { 2004 key "conn-name"; 2005 description "IKE peer connetion information"; 2006 leaf conn-name { type string; mandatory true; description "Name of IKE connection";} 2007 leaf autostartup { type type-autostartup; mandatory true; description "if True: automatically start tunnel at startup; else we do lazy tunnel setup based on trigger from datapath";} 2008 leaf nat-traversal { type boolean; default false; description "Enable/Disable NAT traversal"; } 2009 leaf initial-contact {type boolean; default false; description "This IKE SA is the only currently active between the authenticated identities";} 2011 container encap { 2012 when "../nat-traversal = 'true'"; 2013 description "Encapsulation container"; 2014 leaf espencap { type esp-encap; description "ESP in TCP, ESP in UDP or ESP in TLS";} 2015 leaf sport {type inet:port-number; description "Encapsulation source port";} 2016 leaf dport {type inet:port-number; description "Encapsulation destination port"; } 2017 leaf oaddr {type inet:ip-address; description "Encapsulation Original Address ";} 2018 } 2020 leaf version { 2021 type enumeration { 2022 enum ikev2 {value 2; description "IKE version 2";} 2023 } 2024 description "IKE version"; 2025 } 2027 uses isakmp-proposal; 2028 uses local-grouping; 2029 uses remote-grouping; 2030 uses phase2-info; 2032 container ike-stats { 2033 container uptime { 2034 description "IKE service uptime"; 2035 leaf running { type yang:date-and-time; description "Relative uptime";} 2036 leaf since { type yang:date-and-time; description "Absolute uptime";} 2038 } 2039 leaf initiator { type boolean; description "It is acting as initiator in this connection";} 2040 leaf initiator-spi {type uint64; description "Initiator's IKE SA SPI";} 2041 leaf responder-spi {type uint64; description "Responsder's IKE SA SPI";} 2042 leaf nat-local {type boolean; description "YES, if local endpoint is behind a NAT";} 2043 leaf nat-remote {type boolean; description "YES, if remote endpoint is behind a NAT";} 2044 leaf nat-any {type boolean; description "YES, if both local and remote endpoints are behind a NAT";} 2045 leaf established {type uint64; description "Seconds the IKE SA has been established";} 2046 leaf rekey-time {type uint64; description "Seconds before IKE SA gets rekeyed";} 2047 leaf reauth-time {type uint64; description "Seconds before IKE SA gets re-authenticated";} 2048 list child-sas { 2049 container spis{ 2050 description "IKE active SA's SPI '"; 2051 leaf spi-in {type ipsec-spi; description "Security Parameter Index for Inbound IPsec SA";} 2052 leaf spi-out {type ipsec-spi; description "Security Parameter Index for the corresponding outbound IPsec SA";} 2053 } 2054 description "State data about IKE CHILD SAs"; 2055 } 2056 config false; 2057 description "IKE state data"; 2058 } /* ike-stats */ 2060 } /* ike-conn-entries */ 2061 } /* container ike-connection */ 2063 container number-ike-sas{ 2064 leaf total {type uint32; description "Total number of IKEv2 SAs";} 2065 leaf half-open {type uint32; description "Total number of half-open IKEv2 SAs";} 2066 config false; 2067 description "Number of IKE SAs"; 2068 } 2070 } /* container ikev2 */ 2072 container ipsec { 2073 description "Configuration IPsec"; 2075 container spd { 2076 description "Configure the Security Policy Database (SPD)"; 2077 list spd-entry { 2078 key "rule-number"; 2079 uses ipsec-policy-grouping; 2080 ordered-by user; 2081 description "List of SPD entries"; 2082 } 2083 } 2084 container sad { 2086 description "Configure the IPSec Security Association Database (SAD)"; 2087 list sad-entry { 2088 key "spi"; 2089 uses ipsec-sa-grouping; 2090 description "List of SAD entries"; 2091 } 2092 } 2094 container pad { 2095 if-feature case1; 2096 description "Configure Peer Authorization Database (PAD)"; 2098 list pad-entries { 2099 key "pad-entry-id"; 2100 ordered-by user; 2101 description "Peer Authorization Database (PAD)"; 2102 leaf pad-entry-id { type uint64; description "SAD index. ";} 2103 uses identity-grouping; 2104 leaf pad-auth-protocol { type auth-protocol-type; description "IKEv1, IKEv2, KINK, etc. ";} 2105 uses auth-method-grouping; 2106 } 2107 } 2108 } 2110 } /* container ietf-ipsec */ 2112 /*################## RPC and Notifications ##################*/ 2114 /* Note: not yet completed */ 2115 // Those RPCs are needed by a Security Controller in case 2 */ 2117 rpc sadb_register { 2118 description "Allows netconf to register its key socket as able to acquire new security associations for the kernel"; 2119 input { 2120 uses base-grouping; 2121 } 2122 output { 2123 uses base-grouping; 2124 uses algorithm-grouping; 2125 } 2126 } 2128 notification spdb_expire { 2129 description "A SPD entry has expired"; 2130 leaf index { type uint64; description "SPD index. RFC4301 does not mention an index however real implementations (e.g. XFRM or PFKEY_v2 with KAME extensions provide a policy index to refer a policy. "; } 2132 } 2134 notification sadb_acquire { 2135 description "A IPsec SA is required "; 2136 uses base-grouping; 2137 } 2139 notification sadb_expire { 2140 description "A IPsec SA expiration (soft or hard)"; 2142 uses base-grouping; 2143 leaf spi { type ipsec-spi; description "Security Parameter Index";} 2144 leaf anti-replay-window { type uint16 { range "0 | 32..1024"; } description "Anti replay window"; } 2145 leaf state {type sa-state; description "current state of SA (mature, larval, dying or dead)"; } 2147 leaf encryption-algorithm { type encryption-algorithm-t; description "encryption algorithm of the expired SA"; } 2148 leaf authentication-algorithm { type integrity-algorithm-t; description "authentication algorithm of the expired SA"; } 2150 container sad-lifetime-hard { 2151 description "SAD lifetime hard state data"; 2152 uses lifetime; 2153 } 2154 container sad-lifetime-soft { 2155 description "SAD lifetime hard state data"; 2156 uses lifetime; 2157 } 2158 container sad-lifetime-current { 2159 description "SAD lifetime current state data"; 2160 uses lifetime; 2161 } 2162 } 2164 notification sadb_bad-spi { 2165 description "....."; 2166 leaf state { type ipsec-spi; mandatory "true"; description "Notify when a SPI"; } 2167 } 2168 } /*module ietf-ipsec*/ 2170 2172 Authors' Addresses 2173 Rafa Marin-Lopez 2174 University of Murcia 2175 Campus de Espinardo S/N, Faculty of Computer Science 2176 Murcia 30100 2177 Spain 2179 Phone: +34 868 88 85 01 2180 EMail: rafa@um.es 2182 Gabriel Lopez-Millan 2183 University of Murcia 2184 Campus de Espinardo S/N, Faculty of Computer Science 2185 Murcia 30100 2186 Spain 2188 Phone: +34 868 88 85 04 2189 EMail: gabilm@um.es