idnits 2.17.1 draft-ietf-i2nsf-sdn-ipsec-flow-protection-01.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 147 instances of too long lines in the document, the longest one being 157 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 460 has weird spacing: '...w start ine...' == Line 463 has weird spacing: '...w start ine...' == Line 467 has weird spacing: '...w start ine...' == Line 470 has weird spacing: '...w start ine...' == Line 517 has weird spacing: '...w start ine...' == (9 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: 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 (March 5, 2018) is 2241 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 1014, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2nsf-framework' is defined on line 1026, but no explicit reference was found in the text == Unused Reference: 'I-D.jeong-i2nsf-sdn-security-services-05' is defined on line 1044, 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-05 -- 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 (~~), 13 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: September 6, 2018 March 5, 2018 7 Software-Defined Networking (SDN)-based IPsec Flow Protection 8 draft-ietf-i2nsf-sdn-ipsec-flow-protection-01 10 Abstract 12 This document describes the use case of providing IPsec-based flow 13 protection by means of a Software-Defined Network (SDN) controller 14 (aka. Security Controller) and establishes the requirements to 15 support this service. It considers two main well-known scenarios in 16 IPsec: (i) gateway-to-gateway and (ii) host-to-host. This document 17 describes a mechanism based on the SDN paradigm to support the 18 distribution and monitoring of IPsec information from a Security 19 Controller to one or several flow-based Network Security Function 20 (NSF). The NSFs implement IPsec to protect data traffic between 21 network resources with IPsec. 23 The document focuses in the NSF Facing Interface by providing models 24 for Configuration and State data model required to allow the Security 25 Controller to configure the IPsec databases (SPD, SAD, PAD) and IKE 26 to establish security associations with a reduced intervention of the 27 network administrator. NOTE: State data model will be developed as 28 part of this work but it is still TBD. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on September 6, 2018. 47 Copyright Notice 49 Copyright (c) 2018 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 66 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 4. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 5. SDN-based IPsec management description . . . . . . . . . . . 6 69 5.1. Case 1: IKE/IPsec in the NSF . . . . . . . . . . . . . . 6 70 5.1.1. Interface Requirements for Case 1 . . . . . . . . . . 7 71 5.2. Case 2: IPsec (no IKE) in the NSF . . . . . . . . . . . . 7 72 5.2.1. Interface Requirements for Case 2 . . . . . . . . . . 8 73 5.3. Case 1 vs Case 2 . . . . . . . . . . . . . . . . . . . . 8 74 6. YANG configuration data models . . . . . . . . . . . . . . . 10 75 6.1. Security Policy Database (SPD) Model . . . . . . . . . . 10 76 6.2. Security Association Database (SAD) Model . . . . . . . . 12 77 6.3. Peer Authorization Database (PAD) Model . . . . . . . . . 14 78 6.4. Internet Key Exchange (IKE) Model . . . . . . . . . . . . 15 79 7. Use cases examples . . . . . . . . . . . . . . . . . . . . . 17 80 7.1. Host-to-Host or Gateway-to-gateway under the same 81 controller . . . . . . . . . . . . . . . . . . . . . . . 17 82 7.2. Host-to-Host or Gateway-to-gateway under different 83 Security controllers . . . . . . . . . . . . . . . . . . 19 84 8. Implementation notes . . . . . . . . . . . . . . . . . . . . 21 85 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 86 9.1. Case 1 . . . . . . . . . . . . . . . . . . . . . . . . . 23 87 9.2. Case 2 . . . . . . . . . . . . . . . . . . . . . . . . . 23 88 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 89 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 90 11.1. Normative References . . . . . . . . . . . . . . . . . . 24 91 11.2. Informative References . . . . . . . . . . . . . . . . . 24 92 Appendix A. Appendix A: YANG model IPsec Configuration data . . 27 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 95 1. Introduction 97 Software-Defined Networking (SDN) is an architecture that enables 98 users to directly program, orchestrate, control and manage network 99 resources through software. SDN paradigm relocates the control of 100 network resources to a dedicated network element, namely SDN 101 controller. The SDN controller manages and configures the 102 distributed network resources and provides an abstracted view of the 103 network resources to the SDN applications. The SDN application can 104 customize and automate the operations (including management) of the 105 abstracted network resources in a programmable manner via this 106 interface [RFC7149][ITU-T.Y.3300] 107 [ONF-SDN-Architecture][ONF-OpenFlow]. 109 Typically, traditional IPsec VPN concentrators and, in general, 110 entities (i.e. hosts or security gateways) supporting IKE/IPsec, must 111 be configured directly by the administrator. This makes the IPsec 112 security association (SA) management difficult and generates a lack 113 of flexibility, specially if the number of security policies and SAs 114 to handle is high. With the growth of SDN-based scenarios where 115 network resources are deployed in an autonomous manner, a mechanism 116 to manage IPsec SAs according to the SDN architecture becomes more 117 relevant. Thus, the SDN-based service described in this document 118 will autonomously deal with IPsec SAs management. 120 An example of usage can be the notion of Software Defined WAN (SD- 121 WAN), SDN extension providing a software abstraction to create secure 122 network overlays over traditional WAN and branch networks. SD-WAN is 123 based on IPsec as underlying security protocol and aims to provide 124 flexible, automated, fast deployment and on-demand security network 125 services. 127 IPsec architecture [RFC4301] defines a clear separation between the 128 processing to provide security services to IP packets and the key 129 management procedures to establish the IPsec security associations. 130 In this document, we define a service where the key management 131 procedures can be carried by an external entity: the Security 132 Controller. 134 First, this document exposes the requirements to support the 135 protection of data flows using IPsec [RFC4301]. We have considered 136 two general cases: 138 1) The Network Security Function (NSF) implements the Internet Key 139 Exchange (IKE) protocol and the IPsec databases: the Security 140 Policy Database (SPD), the Security Association Database (SAD) 141 and the Peer Authorization Database (PAD). The Security 142 Controller is in charge of provisioning the NSF with the required 143 information to IKE, the SPD and the PAD. 145 2) The NSF only implements the IPsec databases (no IKE 146 implementation). The Security Controller will provide the 147 required parameters to create valid entries in the SPD and the 148 SAD into the NSF. Therefore, the NSF will have only support for 149 IPsec while automated key management functionality is moved to 150 the controller. 152 In both cases, an interface/protocol is required to carry out this 153 provisioning in a secure manner between the Security Controller and 154 the NSF. In particular, Case 1 requires the provision of SPD and PAD 155 entries and the IKE credential and information related with the IKE 156 negotiation (e.g. IKE_SA_INIT); and Case 2 requires the management 157 of SPD and SAD entries. Based on YANG models in [netconf-vpn] and 158 [I-D.tran-ipsecme-yang], RFC 4301 [RFC4301] and RFC 7296 [RFC7296] 159 this document defines the required interfaces with a YANG model for 160 configuration data for IKE, PAD, SPD and SAD Appendix A . State data 161 is TBD. 163 This document considers two typical scenarios to manage autonomously 164 IPsec SAs: gateway-to-gateway and host-to-host [RFC6071]. The 165 analysis of the host-to-gateway (roadwarrior) scenario is TBD. In 166 these cases, host or gateways or both may act as NSFs. Finally, it 167 also discusses the situation where two NSFs are under the control of 168 two different Security Controllers. 170 NOTE: This work pays attention to the challenge "Lack of Mechanism 171 for Dynamic Key Distribution to NSFs" defined in 172 [I-D.ietf-i2nsf-problem-and-use-cases] in the particular case of the 173 establishment and management of IPsec SAs. In fact, this I-D could 174 be considered as a proper use case for this particular challenge in 175 [I-D.ietf-i2nsf-problem-and-use-cases]. 177 2. Requirements Language 179 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 180 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 181 document are to be interpreted as described in RFC 2119 [RFC2119]. 182 When these words appear in lower case, they have their natural 183 language meaning. 185 3. Terminology 187 This document uses the terminology described in [RFC7149], [RFC4301], 188 [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 our SDN-based solution. 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 IKE 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 IKE 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 IKE to establish the required 268 IPsec SA (when the data flow needs protection). Figure 1 shows the 269 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 IKE, SPD and PAD. 301 o A YANG data model for State data for IKE, SPD, PAD and SAD (Note 302 that SAD entries are created in runtime by IKE.) 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 IKE) in the NSF 312 In this case the NSF does not deploy IKE and, therefore, the Security 313 Controller has to perform the management of IPsec SAs by populating 314 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 IKE 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 IKE/IPsec implementation. Moreover hosts can 362 install easily an IKE implementation. As downside, the NSF needs 363 more resources to hold IKE. Moreover, the IKE implementation needs 364 to implement an interface so that the I2NSF Agent can interact with 365 them. 367 Alternatively, Case 2 allows lighter NSFs (no IKE implementation), 368 which benefits the deployment in constrained NSFs. Moreover, IKE 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 creation of fresh IPsec SA is shifted 372 to the Security Controller since IKE is not in the NSF. As a 373 consequence, this may result in a more complex implementation in the 374 controller side. 376 For example, the Security Controller needs to supervise the IPsec SAs 377 states and take care of the rekeying process so that, after some 378 period of time (e.g. IPsec SA soft lifetime), it has to create a new 379 IPsec SA and remove the old one. Or the Security Controller needs to 380 process events coming from the NSF when, for example, an IPsec SA is 381 requested (e.g. acquire or expire events). 383 Another example is the NAT traversal support. In general, the SDN 384 paradigm assumes the Security Controller has a view of the network it 385 controls. This view is built either requesting information to the 386 NSFs under its control or because these NSFs inform the Security 387 Controller. Based on this information, the Security Controller can 388 guess if there is a NAT configured between two hosts, apply the 389 required policies to both NSFs besides activating the usage of UDP or 390 TCP/TLS encapsulation of ESP packets ([RFC3948], [RFC8229]). 392 In those scenarios, the Controller could directly request the NSF for 393 specific data such as networking configuration, NAT support, etc. 394 Protocols such as NETCONF or SNMP can be used here. For example, RFC 395 7317 [RFC7317] provides a YANG data model for system management or 396 [I-D.sivakumar-yang-nat] a data model for NAT management. 398 Finally, if one of the NSF restarts, it may lose part or all the 399 IPsec state (affected NSF). By default, the Security Controller can 400 assume that all the state has been lost and therefore it will have to 401 send IKEv2, SPD and PAD information to the NSF in case 1 and SPD and 402 SAD information in case 2. 404 In both cases, the Security Controller MUST be aware of the affected 405 NSF (e.g. the NETCONF/TCP connection is broken with the affected NSF, 406 it is receiving bad_spi notification from a particular NSF, etc...). 407 Moreover, the SDN controller MUST have a register about all the NSFs 408 that have IPsec SAS with the affected NSF. Therefore, it can know 409 the affected IPsec SAs. 411 In Case 1, the SDN controller will configure the affected NSF with 412 the new IKEv2, SPD and PAD information. It has also to send new 413 parameters (e.g. a new fresh PSK) to the NSFs which have IKEv2 SAs 414 and IPsec SAs with the affected NSF. It can also instruct the 415 affected NSF to send INITIAL_CONTACT notification (It is TBD in the 416 model). Finally, the SDN controller will instruct the affected NSF 417 to start the IKEv2 negotiation with the new configuration. 419 In Case 2, the SDN controller will have to: 1) install new SAD 420 entries and remove old SAD entries (and SPD entries if it is needed) 421 in the NSFs that had IPsec SAs with the affected NSF; and 2) install 422 new SPD entries and new SAD entries in the affected NSF to match with 423 the rest of the peers. 425 Nevertheless other more optimized options can be considered (e.g. 426 making iKEv2 configuration permanent between reboots). 428 6. YANG configuration data models 430 In order to support case 1 and case 2 we have modelled the different 431 parameters and values that must be configured to manage IPsec SAs. 432 Specifically, case 1 requires modelling IKEv2, SPD and PAD while case 433 2 requires models for the SPD and SAD. A single YANG file represents 434 both cases though some part of the models are selectively activated 435 depending a feature defined in the YANG file. For example, the IKE 436 configuration is not enabled in case 2. 438 In the following, we summarize, by using a tree representation, the 439 different configuration data models (NOTE: State data models are TBD 440 though they are expected to be very similar to the model defined 441 here). The complete YANG configuration data model is in Appendix A 443 6.1. Security Policy Database (SPD) Model 445 The definition of this model has been extracted from the 446 specification in section 4.4.1 and Appendix D in [RFC4301] 448 +--rw spd 449 | +--rw spd-entry* [rule-number] 450 | +--rw rule-number uint64 451 | +--rw priority? uint32 452 | +--rw names* [name] 453 | | +--rw name-type? ipsec-spd-name 454 | | +--rw name string 455 | +--rw condition 456 | | +--rw traffic-selector-list* [ts-number] 457 | | +--rw ts-number uint32 458 | | +--rw direction? ipsec-traffic-direction 459 | | +--rw local-addresses* [start end] 460 | | | +--rw start inet:ip-address 461 | | | +--rw end inet:ip-address 462 | | +--rw remote-addresses* [start end] 463 | | | +--rw start inet:ip-address 464 | | | +--rw end inet:ip-address 465 | | +--rw next-layer-protocol* ipsec-next-layer-proto 466 | | +--rw local-ports* [start end] 467 | | | +--rw start inet:port-number 468 | | | +--rw end inet:port-number 469 | | +--rw remote-ports* [start end] 470 | | | +--rw start inet:port-number 471 | | | +--rw end inet:port-number 472 | | +--rw selector-priority? uint32 473 | +--rw processing-info 474 | | +--rw action ipsec-spd-operation 475 | | +--rw ipsec-sa-cfg 476 | | +--rw pfp-flag? boolean 477 | | +--rw extSeqNum? boolean 478 | | +--rw seqOverflow? boolean 479 | | +--rw statefulfragCheck? boolean 480 | | +--rw security-protocol? ipsec-protocol 481 | | +--rw mode? ipsec-mode 482 | | +--rw ah-algorithms 483 | | | +--rw ah-algorithm* integrity-algorithm-t 484 | | +--rw esp-algorithms 485 | | | +--rw authentication* integrity-algorithm-t 486 | | | +--rw encryption* encryption-algorithm-t 487 | | +--rw tunnel 488 | | +--rw local? inet:ip-address 489 | | +--rw remote? inet:ip-address 490 | | +--rw bypass-df? boolean 491 | | +--rw bypass-dscp? boolean 492 | | +--rw dscp-mapping? yang:hex-string 493 | | +--rw ecn? boolean 494 | +--rw spd-lifetime 495 | +--rw time-soft? uint32 496 | +--rw time-hard? uint32 497 | +--rw time-use-soft? uint32 498 | +--rw time-use-hard? uint32 499 | +--rw byte-soft? uint32 500 | +--rw byte-hard? uint32 501 | +--rw packet-soft? uint32 502 | +--rw packet-hard? uint32 504 6.2. Security Association Database (SAD) Model 506 The definition of this model has been extracted from the 507 specification in section 4.4.2 in [RFC4301] 509 +--rw sad {case2}? 510 | +--rw sad-entry* [spi] 511 | +--rw spi ipsec-spi 512 | +--rw seq-number? uint64 513 | +--rw seq-number-overflow-flag? boolean 514 | +--rw anti-replay-window? uint16 515 | +--rw rule-number? uint32 516 | +--rw local-addresses* [start end] 517 | | +--rw start inet:ip-address 518 | | +--rw end inet:ip-address 519 | +--rw remote-addresses* [start end] 520 | | +--rw start inet:ip-address 521 | | +--rw end inet:ip-address 522 | +--rw next-layer-protocol* ipsec-next-layer-proto 523 | +--rw local-ports* [start end] 524 | | +--rw start inet:port-number 525 | | +--rw end inet:port-number 526 | +--rw remote-ports* [start end] 527 | | +--rw start inet:port-number 528 | | +--rw end inet:port-number 529 | +--rw security-protocol? ipsec-protocol 530 | +--rw ah-sa 531 | | +--rw integrity 532 | | +--rw integrity-algorithm? integrity-algorithm-t 533 | | +--rw key? string 534 | +--rw esp-sa 535 | | +--rw encryption 536 | | | +--rw encryption-algorithm? encryption-algorithm-t 537 | | | +--rw key? string 538 | | | +--rw iv? string 539 | | +--rw integrity 540 | | | +--rw integrity-algorithm? integrity-algorithm-t 541 | | | +--rw key? string 542 | | +--rw combined-enc-intr? boolean 543 | +--rw sa-lifetime 544 | | +--rw time-soft? uint32 545 | | +--rw time-hard? uint32 546 | | +--rw time-use-soft? uint32 547 | | +--rw time-use-hard? uint32 548 | | +--rw byte-soft? uint32 549 | | +--rw byte-hard? uint32 550 | | +--rw packet-soft? uint32 551 | | +--rw packet-hard? uint32 552 | | +--rw action? lifetime-action 553 | +--rw mode? ipsec-mode 554 | +--rw statefulfragCheck? boolean 555 | +--rw dscp? yang:hex-string 556 | +--rw tunnel 557 | | +--rw local? inet:ip-address 558 | | +--rw remote? inet:ip-address 559 | | +--rw bypass-df? boolean 560 | | +--rw bypass-dscp? boolean 561 | | +--rw dscp-mapping? yang:hex-string 562 | | +--rw ecn? boolean 563 | +--rw path-mtu? uint16 564 | +--rw encap 565 | +--rw espencap? esp-encap 566 | +--rw sport? inet:port-number 567 | +--rw dport? inet:port-number 568 | +--rw oaddr? inet:ip-address 570 rpcs: 571 +---x sadb_register 572 +---w input 573 | +---w base-list* [version] 574 | +---w version string 575 | +---w msg_type? sadb-msg-type 576 | +---w msg_satype? sadb-msg-satype 577 | +---w msg_seq? uint32 578 +--ro output 579 +--ro base-list* [version] 580 | +--ro version string 581 | +--ro msg_type? sadb-msg-type 582 | +--ro msg_satype? sadb-msg-satype 583 | +--ro msg_seq? uint32 584 +--ro algorithm-supported* 585 +--ro authentication 586 | +--ro name? integrity-algorithm-t 587 | +--ro ivlen? uint8 588 | +--ro min-bits? uint16 589 | +--ro max-bits? uint16 590 +--ro encryption 591 +--ro name? encryption-algorithm-t 592 +--ro ivlen? uint8 593 +--ro min-bits? uint16 594 +--ro max-bits? uint16 596 notifications: 597 +---n spdb_expire 598 | +--ro index? uint64 599 +---n sadb_acquire 600 | +--ro state uint32 601 +---n sadb_expire 602 | +--ro state uint32 603 +---n sadb_bad-spi 604 +--ro state ipsec-spi 606 6.3. Peer Authorization Database (PAD) Model 608 The definition of this model has been extracted from the 609 specification in section 4.4.3 in [RFC4301] (NOTE: We have observed 610 that many implementations integrate PAD configuration as part of the 611 IKE configuration.) 612 +--rw pad {case1}? 613 +--rw pad-entries* [pad-entry-id] 614 +--rw pad-entry-id uint64 615 +--rw (identity)? 616 | +--:(ipv4-address) 617 | | +--rw ipv4-address? inet:ipv4-address 618 | +--:(ipv6-address) 619 | | +--rw ipv6-address? inet:ipv6-address 620 | +--:(fqdn-string) 621 | | +--rw fqdn-string? inet:domain-name 622 | +--:(rfc822-address-string) 623 | | +--rw rfc822-address-string? string 624 | +--:(dnX509) 625 | | +--rw dnX509? string 626 | +--:(id_key) 627 | +--rw id_key? string 628 +--rw pad-auth-protocol? auth-protocol-type 629 +--rw auth-method 630 +--rw auth-m? auth-method-type 631 +--rw pre-shared 632 | +--rw secret? string 633 +--rw rsa-signature 634 +--rw key-data? string 635 +--rw key-file? string 636 +--rw ca-data* string 637 +--rw ca-file? string 638 +--rw cert-data? string 639 +--rw cert-file? string 640 +--rw crl-data? string 641 +--rw crl-file? string 643 6.4. Internet Key Exchange (IKE) Model 645 The model related to IKEv2 has been extracted from reading IKEv2 646 standard in [RFC7296], and observing some open source 647 implementations, such as Strongswan or Libreswan. 649 +--rw ikev2 {case1}? 650 | +--rw ike-connection 651 | +--rw ike-conn-entries* [conn-name] 652 | +--rw conn-name string 653 | +--rw autostartup type-autostartup 654 | +--rw nat-traversal? boolean 655 | +--rw encap 656 | | +--rw espencap? esp-encap 657 | | +--rw sport? inet:port-number 658 | | +--rw dport? inet:port-number 659 | | +--rw oaddr? inet:ip-address 660 | +--rw version? enumeration 661 | +--rw phase1-lifetime uint32 662 | +--rw phase1-authalg* integrity-algorithm-t 663 | +--rw phase1-encalg* encryption-algorithm-t 664 | +--rw combined-enc-intr? boolean 665 | +--rw dh_group uint32 666 | +--rw local 667 | | +--rw (my-identifier-type)? 668 | | | +--:(ipv4) 669 | | | | +--rw ipv4? inet:ipv4-address 670 | | | +--:(ipv6) 671 | | | | +--rw ipv6? inet:ipv6-address 672 | | | +--:(fqdn) 673 | | | | +--rw fqdn? inet:domain-name 674 | | | +--:(dn) 675 | | | | +--rw dn? string 676 | | | +--:(user_fqdn) 677 | | | +--rw user_fqdn? string 678 | | +--rw my-identifier string 679 | +--rw remote 680 | | +--rw (my-identifier-type)? 681 | | | +--:(ipv4) 682 | | | | +--rw ipv4? inet:ipv4-address 683 | | | +--:(ipv6) 684 | | | | +--rw ipv6? inet:ipv6-address 685 | | | +--:(fqdn) 686 | | | | +--rw fqdn? inet:domain-name 687 | | | +--:(dn) 688 | | | | +--rw dn? string 689 | | | +--:(user_fqdn) 690 | | | +--rw user_fqdn? string 691 | | +--rw my-identifier string 692 | +--rw pfs_group* uint32 694 7. Use cases examples 696 This section explains how different traditional configurations, that 697 is, host-to-host and gateway-to-gateway are deployed using our SDN- 698 based IPsec management service. In turn, these configurations will 699 be typical in modern networks where, for example, virtualization will 700 be key. 702 7.1. Host-to-Host or Gateway-to-gateway under the same controller 704 +----------------------------------------+ 705 | Security Controller | 706 | | 707 (1)| +--------------+ (2)+--------------+ | 708 Flow-based ------> |Translate into|--->| South. Prot. | | 709 Security. Pol. | |IPsec Policies| | | | 710 | +--------------+ +--------------+ | 711 | | | | 712 | | | | 713 +--------------------------|-----|-------+ 714 | | 715 | (3) | 716 |-------------------------+ +---| 717 V V 718 +----------------------+ +----------------------+ 719 | NSF1 |<=======>| NSF2 | 720 |IKE/IPsec(SPD/PAD) | |IKE/IPsec(SPD/PAD) | 721 +----------------------+ (4) +----------------------+ 723 Figure 3: Host-to-Host / Gateway-to-Gateway single controller flow 724 for case 1 . 726 Figure 3 describes the case 1: 728 1. The administrator defines general flow-based security policies. 729 The controller looks for the NSFs involved (NSF1 and NSF2). 731 2. The controller generates IKE credentials for them and translates 732 the policies into SPD and PAD entries. 734 3. The controller inserts the SPD and PAD entries in both NSF1 and 735 NSF2. 737 4. The flow is protected with the IPsec SA established with IKEv2. 739 +----------------------------------------+ 740 | (1) Security Controller | 741 Flow-based | | 742 Security -----------| | 743 Policy | V | 744 | +---------------+ (2)+-------------+ | 745 | |Translate into |--->| South. Prot.| | 746 | |IPsec policies | | | | 747 | +---------------+ +-------------+ | 748 | | | | 749 | | | | 750 +-------------------------| --- |--------+ 751 | | 752 | (3) | 753 |----------------------+ +--| 754 V V 755 +------------------+ +------------------+ 756 | NSF1 |<=====>| NSF2 | 757 |IPsec(SPD/SAD) | 4) |IPsec(SPD/SAD) | 758 +------------------+ +------------------+ 760 Figure 4: Host-to-Host / Gateway-to-Gateway single controller flow 761 for case 2. 763 In case 2, flow-based security policies defined by the administrator 764 are also translated into IPsec SPD entries and inserted into the 765 corresponding NSFs. Besides, fresh SAD entries will be also 766 generated by the controller and enforced in the NSFs. In this case 767 the controller does not run any IKE implementation, and it provides 768 the cryptographic material for the IPsec SAs. These keys will be 769 also distributed securely through the southbound interface. Note 770 that this is possible because both NSFs are managed by the same 771 controller. 773 Figure 4 describes the case 2, when a data packet needs to be 774 protected in the path between the NSF1 and NSF2: 776 1. The administrator establishes the flow-based security policies. 777 The controller looks for the involved NSFs. 779 2. The controller translates the flow-based security policies into 780 IPsec SPD and SAD entries. 782 3. The controller inserts the these entries in both NSF1 and NSF2 783 IPsec databases. 785 4. The flow is protected with the IPsec SA established by the 786 Security Controller. 788 Both NSFs could be two hosts that exchange traffic and require to 789 establish an end-to-end security association to protect their 790 communications (host-to-host) or two gateways (gateway-to-gateway)), 791 for example, within an enterprise that needs to protect the traffic 792 between, for example, the networks of two branch offices. 794 Applicability of these configurations appear in current and new 795 networking scenarios. For example, SD-WAN technologies are providing 796 dynamic and on-demand VPN connections between branch offices or 797 between branches and SaaS cloud services. Beside, IaaS services 798 providing virtualization environments are deployments solutions based 799 on IPsec to provide secure channels between virtual instances (Host- 800 to-Host) and providing VPN solutions for virtualized networks 801 (Gateway-to-Gateway). 803 In general (for case 1 and case 2), this system presents various 804 advantages: 806 1. It allows to create a IPsec SA among two NSFs, with only the 807 application of more general flow-based security policies at the 808 application layer. Thus, administrators can manage all security 809 associations in a centralized point with an abstracted view of 810 the network; 812 2. All NSFs deployed after the application of the new policies are 813 NOT manually configured, therefore allowing its deployment in an 814 automated manner. 816 7.2. Host-to-Host or Gateway-to-gateway under different Security 817 controllers 819 It is also possible that two NSFs (i.e. NSF1 and NSF2) are under the 820 control of two different Security Controllers. This may happen, for 821 example, when two organizations, namely Enterprise A and Enterprise 822 B, have their headquarters interconnected through a WAN connection 823 and they both have deployed a SDN-based architecture to provide 824 connectivity to all their clients. 826 +-------------+ +-------------+ 827 | | | | 828 Flow-based| Security |<===============>| Security <--Flow-based 829 Sec. Pol.--> Controller | (3) | Controller | Sec. Pol. 830 (1) | A | | B | (2) 831 +-------------+ +-------------+ 832 | | 833 | (4) (4) | 834 V V 835 +----------------------+ +----------------------+ 836 | NSF1 |<========>| NSF2 | 837 |IKE/IPsec(SPD/PAD) | |IKE/IPsec(SPD/PAD) | 838 +----------------------+ (5) +----------------------+ 840 Figure 5: Different Security Controllers in Case 1 842 Figure 5 describes case 1 when two Security Controllers are involved 843 in the process. 845 1. The A's 'administrator establishes general Flow-based Security 846 Policies in Security Controller A. 848 2. The B's administrator establishes general Flow-based Security 849 Policies in Security Controller B. 851 3. The Security Controller A realizes that protection is required 852 between the NSF1 and NSF2, but the NSF2 is under the control of 853 another Security Controller (Security Controller B), so it starts 854 negotiations with the other controller to agree on the IPsec SPD 855 policies and IKE credentials for their respective NSFs. NOTE: 856 This may require extensions in the East/West interface. 858 4. Then, both Security Controllers enforce the IKE credentials and 859 related parameters and the SPD and PAD entries in their 860 respective NSFs. 862 5. The flow is protected with the IPsec SA established with IKEv2 863 between both NSFs. 865 +--------------+ +--------------+ 866 | | | | 867 Flow-based. ---> | <---- Flow-based 868 Prot. | Security |<=================>| Security |Sec. 869 Pol.(1)| Controller | (3) | Controller |Pol. (2) 870 | A | | B | 871 +--------------+ +--------------+ 872 | | 873 | (4) (4) | 874 V V 875 +------------------+ (5) +------------------+ 876 | NSF1 |<==============>| NSF2 | 877 |IPsec(SPD/SAD) | | IPsec(SPD/SAD) | 878 +------------------+ +------------------+ 880 Figure 6: Different Security Controllers in case 2 882 Figure 5 describes case 1 when two Security Controllers are involved 883 in the process. 885 1. The A's administrator establishes general Flow Protection 886 Policies in Security Controller A. 888 2. The B's administrator establishes general Flow Protection 889 Policies in Security Controller B. 891 3. The Security Controller A realizes that the flow between NSF1 and 892 NSF2 MUST be protected. Nevertheless, the controller notices 893 that NSF2 is under the control of another Security Controller, so 894 it starts negotiations with the other controller to agree on the 895 IPsec SPD and SAD entries that define the IPsec SAs. NOTE: It 896 would worth evaluating IKE as the protocol for the East/West 897 interface in this case. 899 4. Once the controllers have agreed on key material and the details 900 of the IPsec SA, they both enforce this information into their 901 respective NSFs. 903 5. The flow is protected with the IPsec SA established by both 904 Security Controllers in their respective NSFs. 906 8. Implementation notes 908 At the time of writing this document, we have implemented a proof-of- 909 concept using NETCONF as southbound protocol, and the YANG model 910 described in Appendix A. The netopeer implementation [netopeer] has 911 been used for both case 1 and case 2 using host-to-host and gateway- 912 to-gateway configuration. For the case 1, we have used Strongswan 913 [strongswan] distribution for the IKE implementation. 915 Note that the proposed YANG model provides the models for SPD, SAD, 916 PAD and IKE, but, as describe before, only part of them are required 917 depending of the case (1 or 2) been applied. The Controller should 918 be able to know the kind of case to be applied in the NSF and to 919 select the corresponding models based on the YANG features defines 920 for each one 922 Internally to the NSF, the NETCONF server (that implements the I2NSF 923 Agent) is able to apply the required configuration updating the 924 corresponding NETCONF datastores (running, startup, etc.). Besides, 925 it can deal with the SPD and SAD configuration at kernel level, 926 through different APIs. For example, the IETF RFC 2367 (PF_KEYv2) 927 [RFC2367] provides a generic key management API that can be used not 928 only for IPsec but also for other network security services to manage 929 the IPsec SAD. Besides, as an extension to this API, the document 930 [I-D.pfkey-spd] specifies some PF_KEY extensions to maintain the SPD. 931 This API is accessed using sockets. 933 An alternative key management API based on Netlink socket API 934 [RFC3549] is used to configure IPsec on the Linux Operating System. 936 To allow the NETCONF server implementation interacts with the IKE 937 daemon, we have used the Versatile IKE Configuration Interface (VICI) 938 in Strongswan. This allows changes in the IKE part of the 939 configuration data to be applied in the IKE daemon dynamically. 941 9. Security Considerations 943 First of all, this document shares all the security issues of SDN 944 that are specified in the "Security Considerations" section of 945 [ITU-T.Y.3300] and [RFC8192]. We have divided this section in two 946 parts to analyze different security considerations for both cases: 947 NSF with IKEv2 (case 1) and NSF without IKEv2 (case 2). In general, 948 the Security Controller, as typically in the SDN paradigm, is a 949 target for different type of attacks. As a consequence, the Security 950 Controller is a key entity in the infrastructure and MUST be 951 protected accordingly. In particular, according to this document, 952 the Security Controller will handle cryptographic material so that 953 the attacker may try to access this information. Although, we can 954 assume this attack will not likely to happen due to the assumed 955 security measurements to protect the Security Controller, some 956 analysis of the impact deserves some analysis in the hypothetical the 957 attack occurs. The impact is different depending on the case 1 or 958 case 2. 960 9.1. Case 1 962 In this case 1, the controller sends IKE credentials (PSK, public/ 963 private keys, certificates, etc...) to the NSFs. The general 964 recommendation is that the Security Controller NEVER stores the IKE 965 credentials after distributing them. Moreover the NSFs MUST NOT 966 allow the reading of these values once they have been applied by the 967 Security Controller (i.e. write only operations). If the attacker 968 has access to the Security Controller during the period of time that 969 key material is generated, it may access to these values. Since 970 these values are used during NSF authentication in IKEv2, it may 971 impersonate the affected NSFs. Several recommendations are 972 important. If PSK is used, immediately after generating and 973 distributing it, the Security Controller should remove it. If raw 974 public keys are used, the Security Controller should remove the 975 associate private key immediately after generating and distributing 976 them to the Security Controller. If certificates are used, the NSF 977 may generate the private key and exports the public key for 978 certification in the Security Controller. 980 9.2. Case 2 982 In the case 2, the controller sends the IPsec SA to the SAD that 983 includes the keys for integrity and encryption (when ESP is used). 984 That key material are symmetric keys to protect data traffic. The 985 general recommendation is that the Security Controller NEVER stores 986 the keys after distributing them. Moreover the NSFs MUST NOT allow 987 the reading of these values once they have been applied by the 988 Security Controller (i.e. write only operations). Nevertheless, if 989 the attacker has access to the Security Controller during the period 990 of time that key material is generated, it may access to these 991 values. In other words, it may have access to the key material used 992 in the distributed IPsec SAs. 994 10. Acknowledgements 996 Authors want to thank Sowmini Varadhan, David Carrel, Yoav Nir, Tero 997 Kivinen, Paul Wouters, Graham Bartlett, Sandeep Kampati, Linda 998 Dunbar, Carlos J. Bernardos, Alejandro Perez-Mendez, Fernando 999 Pereniguez-Garcia, Alejandro Abad-Carrascosa, Ignacio Martinez and 1000 Ruben Ricart for their valuable comments. 1002 11. References 1003 11.1. Normative References 1005 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1006 Requirement Levels", BCP 14, RFC 2119, 1007 DOI 10.17487/RFC2119, March 1997, 1008 . 1010 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1011 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 1012 December 2005, . 1014 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1015 IANA Considerations Section in RFCs", RFC 5226, 1016 DOI 10.17487/RFC5226, May 2008, 1017 . 1019 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 1020 Kivinen, "Internet Key Exchange Protocol Version 2 1021 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 1022 2014, . 1024 11.2. Informative References 1026 [I-D.ietf-i2nsf-framework] 1027 Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 1028 Kumar, "Framework for Interface to Network Security 1029 Functions", draft-ietf-i2nsf-framework-10 (work in 1030 progress), November 2017. 1032 [I-D.ietf-i2nsf-problem-and-use-cases] 1033 Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., 1034 and J. Jeong, "I2NSF Problem Statement and Use cases", 1035 draft-ietf-i2nsf-problem-and-use-cases-16 (work in 1036 progress), May 2017. 1038 [I-D.ietf-i2nsf-terminology] 1039 Hares, S., Strassner, J., Lopez, D., Xia, L., and H. 1040 Birkholz, "Interface to Network Security Functions (I2NSF) 1041 Terminology", draft-ietf-i2nsf-terminology-05 (work in 1042 progress), January 2018. 1044 [I-D.jeong-i2nsf-sdn-security-services-05] 1045 Jeong, J., Kim, H., Park, J., Ahn, T., and S. Lee, 1046 "Software-Defined Networking Based Security Services using 1047 Interface to Network Security Functions", draft-jeong- 1048 i2nsf-sdn-security-services-05 (work in progress), July 1049 2016. 1051 [I-D.pfkey-spd] 1052 Sakane, S., "PF_KEY Extensions for IPsec Policy Management 1053 in KAME Stack", October 2002. 1055 [I-D.sivakumar-yang-nat] 1056 Sivakumar, S., Boucadair, M., and S. Vinapamula, "YANG 1057 Data Model for Network Address Translation (NAT)", draft- 1058 sivakumar-yang-nat-07 (work in progress), July 2017. 1060 [I-D.tran-ipsecme-yang] 1061 Tran, K., Wang, H., Nagaraj, V., and X. Chen, "Yang Data 1062 Model for Internet Protocol Security (IPsec)", draft-tran- 1063 ipsecme-yang-01 (work in progress), June 2015. 1065 [ITU-T.X.1252] 1066 "Baseline Identity Management Terms and Definitions", 1067 April 2010. 1069 [ITU-T.X.800] 1070 "Security Architecture for Open Systems Interconnection 1071 for CCITT Applications", March 1991. 1073 [ITU-T.Y.3300] 1074 "Recommendation ITU-T Y.3300", June 2014. 1076 [netconf-vpn] 1077 Stefan Wallin, "Tutorial: NETCONF and YANG", January 2014. 1079 [netopeer] 1080 CESNET, CESNET., "NETCONF toolset Netopeer", November 1081 2016. 1083 [ONF-OpenFlow] 1084 ONF, "OpenFlow Switch Specification (Version 1.4.0)", 1085 October 2013. 1087 [ONF-SDN-Architecture] 1088 "SDN Architecture", June 2014. 1090 [RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key 1091 Management API, Version 2", RFC 2367, 1092 DOI 10.17487/RFC2367, July 1998, 1093 . 1095 [RFC3549] Salim, J., Khosravi, H., Kleen, A., and A. Kuznetsov, 1096 "Linux Netlink as an IP Services Protocol", RFC 3549, 1097 DOI 10.17487/RFC3549, July 2003, 1098 . 1100 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 1101 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 1102 RFC 3948, DOI 10.17487/RFC3948, January 2005, 1103 . 1105 [RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and 1106 Internet Key Exchange (IKE) Document Roadmap", RFC 6071, 1107 DOI 10.17487/RFC6071, February 2011, 1108 . 1110 [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined 1111 Networking: A Perspective from within a Service Provider 1112 Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, 1113 . 1115 [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for 1116 System Management", RFC 7317, DOI 10.17487/RFC7317, August 1117 2014, . 1119 [RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., 1120 and J. Jeong, "Interface to Network Security Functions 1121 (I2NSF): Problem Statement and Use Cases", RFC 8192, 1122 DOI 10.17487/RFC8192, July 2017, 1123 . 1125 [RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation 1126 of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229, 1127 August 2017, . 1129 [strongswan] 1130 CESNET, CESNET., "StrongSwan: the OpenSource IPsec-based 1131 VPN Solution", April 2017. 1133 Appendix A. Appendix A: YANG model IPsec Configuration data 1135 file "ietf-ipsec@2018-01-08.yang" 1136 module ietf-ipsec { 1138 namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec"; 1140 prefix "eipsec"; 1142 import ietf-inet-types { prefix inet; } 1143 import ietf-yang-types { prefix yang; } 1145 organization "University of Murcia"; 1147 contact 1148 " Rafael Marin Lopez 1149 Dept. Information and Communications Engineering (DIIC) 1150 Faculty of Computer Science-University of Murcia 1151 30100 Murcia - Spain 1152 Telf: +34868888501 1153 e-mail: rafa@um.es 1155 Gabriel Lopez Millan 1156 Dept. Information and Communications Engineering (DIIC) 1157 Faculty of Computer Science-University of Murcia 1158 30100 Murcia - Spain 1159 Tel: +34 868888504 1160 email: gabilm@um.es 1161 "; 1163 description "Data model for IPSec"; 1165 revision "2018-01-08" { 1166 description 1167 "Initial revision."; 1168 reference ""; 1169 } 1171 feature case1 { description "feature case 1: IKE SPD PAD"; } // IKE/IPSec in the NSFs 1172 feature case2 { description "feature case 2: SPD SAD"; } // Only IPSec in the NSFs 1173 typedef encryption-algorithm-t { 1175 type enumeration { 1176 enum reserved-0 {description "reserved";} 1177 enum des-iv4 { description "DES IV 4";} 1178 enum des { description "DES"; } 1179 enum 3des { description "3DES"; } 1180 enum rc5 { description "RC5"; } 1181 enum idea { description "IDEA"; } 1182 enum cast { description "CAST"; } 1183 enum blowfish { description "BlowFish"; } 1184 enum 3idea { description "3IDEA"; } 1185 enum des-iv32 { description "DES-IV32"; } 1186 enum reserved-10 { description "reserved-10"; } 1187 enum null { description "NULL"; } 1188 enum aes-cbc { description "AES-CBC"; } 1189 enum aes-ctr { description "AES-CTR"; } 1190 enum aes-ccm-8 { description "AES-CCM-8"; } 1191 enum aes-ccm-12 { description "AES-CCM-12"; } 1192 enum aes-ccm-16 { description "AES-CCM-16"; } 1193 enum reserved-17 { description "reserved-17"; } 1194 enum aes-gcm-8-icv { description "AES-GCM-8-ICV"; } 1195 enum aes-gcm-12-icv { description "AES-GCM-12-ICV"; } 1196 enum aes-gcm-16-icv { description "AES-GCM-16-ICV"; } 1197 enum null-auth-aes-gmac { description "Null-Auth-AES-GMAC"; } 1198 enum ieee-p1619-xts-aes { 1199 description 1200 "encr-ieee-p1619-xts-aes -> Reserved for IEEE P1619 XTS-AES."; 1201 } 1202 enum camellia-cbc { description "CAMELLIA-CBC"; } 1203 enum camellia-ctr { description "CAMELLIA.CTR"; } 1204 enum camellia-ccm-8-icv { description "CAMELLIA-CCM-8-ICV"; } 1205 enum camellia-ccm-12-icv { description "CAMELLIA-CCM-12-ICV"; } 1206 enum camellia-ccm-16-icv { description "CAMELLIA-CCM-16-ICV"; } 1207 enum aes-cbc-128 { description "AES-CBC-128"; } 1208 enum aes-cbc-192 { description "AES-CBC-192"; } 1209 enum aes-cbc-256 { description "AES-CBC-256"; } 1210 enum blowfish-128 { description "BlowFish-128"; } 1211 enum blowfish-192 { description "BlowFish-192"; } 1212 enum blowfish-256 { description "BlowFish-256"; } 1213 enum blowfish-448 { description "BlowFish-448"; } 1214 enum camellia-128 { description "CAMELLIA-128"; } 1215 enum camellia-192 { description "CAMELLIA-192"; } 1216 enum camellia-256 { description "CAMELLIA-256"; } 1217 enum AES-GCM-16-ICV { description "AES-GCM-16-ICV (AEAD)"; } 1218 enum AES-CCM { description "AES-CCM (AEAD)"; } 1219 } 1220 description "Encryption algorithms -> RFC_5996"; 1221 } 1223 typedef integrity-algorithm-t { 1225 type enumeration { 1226 enum none { description "NONE"; } 1227 enum hmac-md5-96 { description "HMAC-MD5-96"; } 1228 enum hmac-sha1-96 { description "HMAC-SHA1-96"; } 1229 enum des-mac { description "DES-MAC"; } 1230 enum kpdk-md5 {description "KPDK-MD5"; } 1231 enum aes-xcbc-96 { description "AES-XCBC-96"; } 1232 enum hmac-md5-128 { description "HMAC-MD5-128"; } 1233 enum hmac-sha1-160 { description "HMAC-SHA1-160"; } 1234 enum aes-cmac-96 { description "AES-CMAC-96"; } 1235 enum aes-128-gmac { description "AES-128-GMAC"; } 1236 enum aes-192-gmac { description "AES-192-GMAC"; } 1237 enum aes-256-gmac { description "AES-256-GMAC"; } 1238 enum hmac-sha2-256-128 { description "HMAC-SHA2-256-128"; } 1239 enum hmac-sha2-384-192 { description "HMAC-SHA2-384-192"; } 1240 enum hmac-sha2-512-256 { description "HMAC-SHA2-512-256"; } 1241 enum hmac-sha2-256-96 { description "HMAC-SHA2-256-096"; } 1242 } 1243 description "Integrity Algorithms -> RFC_5996"; 1244 } 1246 typedef type-autostartup 1247 { 1248 type enumeration { 1249 enum ALWAYSON { description " ";} 1250 enum INITIATE-ON-DEMAND {description " ";} 1251 enum RESPOND-ONLY {description " ";} 1252 } 1253 description "Different types of how IKEv2 starts the IPsec SAs"; 1254 } 1256 typedef auth-protocol-type { 1257 type enumeration { 1258 enum IKEv1 { // not supported by model 1259 description "Authentication protocol based on IKEv1"; 1260 } 1261 enum IKEv2 { 1262 description "Authentication protocol based on IKEv2"; 1263 } 1264 enum KINK { // not supported by model 1265 description "Authentication protocol based on KINK"; 1266 } 1267 } 1268 description "Peer authentication protocols"; 1269 } 1271 typedef ipsec-mode { 1273 type enumeration { 1274 enum TRANSPORT { description "Transport mode"; } 1275 enum TUNNEL { description "Tunnel mode"; } 1276 enum BEET { description "Bound End-to-End Tunnel (BEET) mode for ESP.";} 1277 enum RO { description "Route Optimization mode for Mobile IPv6";} 1278 enum IN_TRIGGER {description "In trigger mode for Mobile IPv6";} 1279 } 1280 description "type define of ipsec mode"; 1281 } 1283 typedef esp-encap { 1285 type enumeration { 1286 enum ESPINTCP { description "ESP in TCP encapulation.";} 1287 enum ESPINTLS { description "ESP in TCP encapsulation using TLS.";} 1288 enum ESPINUDP { description "ESP in UDP encapsulation. RFC 3948 ";} 1289 } 1290 description "type defining types of ESP encapsulation"; 1291 } 1293 typedef ipsec-protocol { 1295 type enumeration { 1296 enum ah { description "AH Protocol"; } 1297 enum esp { description "ESP Protocol"; } 1298 enum comp { description "IP Compression";} /*Supported by XFRM*/ 1299 enum route2 { description "Routing Header type 2. Mobile IPv6";} /*Supported by XFRM*/ 1300 enum hao {description "Home Agent Option";} /*Supported by XFRM*/ 1301 } 1302 description "type define of ipsec security protocol"; 1303 } 1305 typedef ipsec-spi { 1307 type uint32 { range "1..max"; } 1308 description "SPI"; 1309 } 1311 typedef lifetime-action { 1312 type enumeration { 1313 enum terminate {description "Terminate the IPsec SA";} 1314 enum replace {description "Replace the IPsec SA with a new one";} 1315 } 1316 description "Action when lifetime expiration"; 1317 } 1319 typedef ipsec-traffic-direction { 1321 type enumeration { 1322 enum INBOUND { description "Inbound traffic"; } 1323 enum OUTBOUND { description "Outbound traffic"; } 1324 enum FORWARD{ description "Forwarded traffic"; } 1325 } 1326 description "IPsec traffic direction"; 1327 } 1329 typedef ipsec-spd-operation { 1331 type enumeration { 1332 enum PROTECT { description "PROTECT the traffic with IPsec"; } 1333 enum BYPASS { description "BYPASS the traffic"; } 1334 enum DISCARD { description "DISCARD the traffic"; } 1335 } 1336 description "The operation when traffic matches IPsec security policy"; 1337 } 1339 typedef ipsec-next-layer-proto { 1341 type enumeration { 1342 enum TCP { description "PROTECT the traffic with IPsec"; } 1343 enum UDP { description "BYPASS the traffic"; } 1344 enum SCTP { description "PROTECT the traffic with IPsec";} 1345 enum DCCP { description "PROTECT the traffic with IPsec";} 1346 enum ICMP { description "PROTECT the traffic with IPsec";} 1347 enum IPv6-ICMP { description "PROTECT the traffic with IPsec";} 1348 enum MH {description "PROTECT the traffic with IPsec";} 1349 enum GRE {description "PROTECT the traffic with IPsec";} 1350 } 1351 description "Next layer proto on top of IP"; 1352 } 1354 typedef ipsec-spd-name { 1356 type enumeration { 1357 enum id_rfc_822_addr { 1358 description "Fully qualified user name string."; 1359 } 1360 enum id_fqdn { 1361 description "Fully qualified DNS name."; 1362 } 1363 enum id_der_asn1_dn { 1364 description "X.500 distinguished name."; 1365 } 1366 enum id_key { 1367 description "IKEv2 Key ID."; 1368 } 1369 } 1370 description "IPsec SPD name type"; 1371 } 1373 typedef auth-method-type { 1374 /* Most implementations also provide XAUTH protocol, others used are: BLISS, P12, NTLM, PIN */ 1376 type enumeration { 1377 enum pre-shared { 1378 description "Select pre-shared key message as the authentication method"; 1379 } 1380 enum rsa-signature { 1381 description "Select rsa digital signature as the authentication method"; 1382 } 1383 enum dss-signature { 1384 description "Select dss digital signature as the authentication method"; 1385 } 1386 enum eap { 1387 description "Select EAP as the authentication method"; 1388 } 1389 } 1390 description "Peer authentication method"; 1391 } 1393 /*################## PAD grouping ####################*/ 1395 grouping auth-method-grouping { 1396 description "Peer authentication method data"; 1398 container auth-method { 1399 description "Peer authentication method container"; 1401 leaf auth-m { 1402 type auth-method-type; 1403 description "Type of authentication method (preshared, rsa, etc.)"; 1404 } 1405 container pre-shared { 1406 when "../auth-m = 'pre-shared'"; 1407 leaf secret { type string; description "Pre-shared secret value";} 1408 description "Shared secret value"; 1409 } 1411 container rsa-signature { 1412 when "../auth-m = 'rsa-signature'"; 1413 leaf key-data { 1414 type string; 1415 description "RSA private key data - PEM"; 1416 } 1418 leaf key-file { 1419 type string; 1420 description "RSA private key file name "; 1421 } 1423 leaf-list ca-data { 1424 type string; 1425 description "List of trusted CA certs - PEM"; 1426 } 1427 leaf ca-file { 1428 type string; 1429 description "List of trusted CA certs file"; 1430 } 1431 leaf cert-data { 1432 type string; 1433 description "X.509 certificate data - PEM4"; 1434 } 1435 leaf cert-file { 1436 type string; 1437 description "X.509 certificate file"; 1438 } 1439 leaf crl-data { 1440 type string; 1441 description "X.509 CRL certificate data in base64"; 1442 } 1443 leaf crl-file { 1444 type string; 1445 description " X.509 CRL certificate file"; 1446 } 1447 description "RSA signature container"; 1448 } 1449 } 1450 } 1452 grouping identity-grouping { 1453 description "Identification type. It is an union identity"; 1454 choice identity { 1455 description "Choice of identity."; 1457 leaf ipv4-address { 1458 type inet:ipv4-address; 1459 description "Specifies the identity as a single four (4) octet IPv4 address. An example is, 10.10.10.10. "; 1460 } 1461 leaf ipv6-address { 1462 type inet:ipv6-address; 1463 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 ."; 1464 } 1465 leaf fqdn-string { 1466 type inet:domain-name; 1467 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.)."; 1468 } 1469 leaf rfc822-address-string { 1470 type string; 1471 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.)."; 1472 } 1473 leaf dnX509 { 1474 type string; 1475 description "Specifies the identity as a distinguished name in the X.509 tradition."; 1476 } 1477 leaf id_key { 1478 type string; 1479 description "Key id"; 1480 } /* From RFC4301 list of id types */ 1481 } 1482 } /* grouping identity-grouping */ 1484 /*################ end PAD grouping ##################*/ 1486 /*################## SAD and SPD grouping ####################*/ 1488 grouping ip-addr-range { 1489 description "IP address range grouping"; 1490 leaf start { 1491 type inet:ip-address; 1492 description "Start IP address"; 1493 } 1494 leaf end { 1495 type inet:ip-address; 1496 description "End IP address"; 1497 } 1498 } 1500 grouping port-range { 1501 description "Port range grouping"; 1502 leaf start { 1503 type inet:port-number; 1504 description "Start IP address"; 1505 } 1506 leaf end { 1507 type inet:port-number; 1508 description "End IP address"; 1509 } 1510 } 1512 grouping tunnel-grouping { 1513 description "Tunnel mode grouping"; 1514 leaf local{ type inet:ip-address; description "Local tunnel endpoint"; } 1515 leaf remote{ type inet:ip-address; description "Remote tunnel enpoint"; } 1516 leaf bypass-df { type boolean; description "bypass DF bit"; } 1517 leaf bypass-dscp { type boolean; description "bypass DSCP"; } 1518 leaf dscp-mapping { type yang:hex-string; description "DSCP mapping"; } 1519 leaf ecn { type boolean; description "Bit ECN"; } /* RFC 4301 ASN1 notation. Annex C*/ 1520 } 1522 grouping selector-grouping { 1523 description "Traffic selector grouping"; 1524 list local-addresses { 1525 key "start end"; 1526 uses ip-addr-range; 1527 description "List of local addresses"; 1528 } 1529 list remote-addresses { 1530 key "start end"; 1531 uses ip-addr-range; 1532 description "List of remote addresses"; 1533 } 1534 leaf-list next-layer-protocol { type ipsec-next-layer-proto; description "List of Next Layer Protocol";} 1535 list local-ports { 1536 key "start end"; 1537 uses port-range; 1538 description "List of local ports"; 1539 } 1541 list remote-ports { 1542 key "start end"; 1543 uses port-range; 1544 description "List of remote ports"; 1545 } 1546 } 1548 /*################## SAD grouping ####################*/ 1549 grouping ipsec-sa-grouping { 1550 description "Configure Security Association (SA). Section 4.4.2.1 in RFC 4301"; 1552 leaf spi { type ipsec-spi; description "Security Parameter Index";} 1553 leaf seq-number { type uint64; description "Current sequence number of IPsec packet."; } 1554 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."; } 1555 leaf anti-replay-window { type uint16 { range "0 | 32..1024"; } description "Anti replay window"; } 1556 leaf rule-number {type uint32; description "This value links the SA with the SPD entry";} 1558 uses selector-grouping; 1560 leaf security-protocol { type ipsec-protocol; description "Security protocol of IPsec SA: Either AH or ESP."; } 1562 container ah-sa { 1563 when "../security-protocol = 'ah'"; 1564 description "Configure Authentication Header (AH) for SA"; 1565 container integrity { 1566 description "Configure integrity for IPSec Authentication Header (AH)"; 1567 leaf integrity-algorithm { type integrity-algorithm-t; description "Configure Authentication Header (AH)."; } 1568 leaf key { type string; description "AH key value";} 1569 } 1570 } 1572 container esp-sa { 1573 when "../security-protocol = 'esp'"; 1574 description "Set IPSec Encapsulation Security Payload (ESP)"; 1576 container encryption { 1577 description "Configure encryption for IPSec Encapsulation Secutiry Payload (ESP)"; 1578 leaf encryption-algorithm { type encryption-algorithm-t; description "Configure ESP encryption"; } 1579 leaf key { type string; description "ESP encryption key value";} 1580 leaf iv {type string; description "ESP encryption IV value"; } 1581 } 1583 container integrity { 1584 description "Configure authentication for IPSec Encapsulation Secutiry Payload (ESP)"; 1585 leaf integrity-algorithm { type integrity-algorithm-t; description "Configure Authentication Header (AH)."; } 1586 leaf key { type string; description "ESP integrity key value";} 1587 } 1588 leaf combined-enc-intr { type boolean; description "ESP combined mode algorithms. The algorithm is specified in encryption-algorithm in the container encryption";} 1589 } 1591 container sa-lifetime { 1592 description "This may be expressed as a time or byte count, or a simultaneous use of both with the first lifetime to expire taking precedence"; 1593 leaf time-soft { type uint32; default 0; description "Soft time lifetime";} 1594 leaf time-hard { type uint32; default 0; description "Hard time lifetime"; } 1595 leaf time-use-soft { type uint32; default 0; description "Use Soft time lifetime";} 1596 leaf time-use-hard { type uint32; default 0; description "Use Hard time lifetime";} 1597 leaf byte-soft { type uint32; default 0;description "Byte soft lifetime"; } 1598 leaf byte-hard { type uint32; default 0; description "Byte hard lifetime";} 1599 leaf packet-soft {type uint32; default 0; description "Packet soft lifetime";} 1600 leaf packet-hard { type uint32; default 0; description "Packet hard lifetime";} 1601 leaf action {type lifetime-action; description "action lifetime";} 1602 } 1604 leaf mode { type ipsec-mode; description "SA Mode"; } 1605 leaf statefulfragCheck { type boolean; description "TRUE stateful fragment checking, FALSE no stateful fragment checking"; } 1606 leaf dscp { type yang:hex-string; description "DSCP value"; } 1608 container tunnel { 1609 when "../mode = 'TUNNEL'"; 1610 uses tunnel-grouping; 1611 description "Container for tunnel grouping"; 1612 } 1614 leaf path-mtu { type uint16; description "Maximum size of an IPsec packet that can be transmitted without fragmentation"; } 1616 container encap { /* This is defined by XFRM */ 1617 description "Encapsulation container"; 1618 leaf espencap { type esp-encap; description "ESP in TCP, ESP in UDP or ESP in TLS";} 1619 leaf sport {type inet:port-number; description "Encapsulation source port";} 1620 leaf dport {type inet:port-number; description "Encapsulation destination port"; } 1621 leaf oaddr {type inet:ip-address; description "Encapsulation Original Address ";} 1622 } 1624 } 1626 /*################## end SAD grouping ##################*/ 1628 /*################## SPD grouping ####################*/ 1630 grouping ipsec-policy-grouping { 1631 description "Holds configuration information for an IPSec SPD entry."; 1633 leaf rule-number { 1634 type uint64; 1635 description "SPD index. RFC4301 does not mention an index however real implementations provide a policy index/or id to refer a policy. "; 1636 } 1637 leaf priority {type uint32; default 0; description "Policy priority";} 1638 list names { 1639 key "name"; 1640 leaf name-type { 1641 type ipsec-spd-name; 1642 description "SPD name type."; 1643 } 1644 leaf name { 1645 type string; description "Policy name"; 1646 } 1647 description "List of policy names"; 1648 } 1650 container condition { 1651 description "SPD condition -> RFC4301"; 1653 list traffic-selector-list { 1655 key "ts-number"; 1657 leaf ts-number { type uint32; description "Traffic selector number"; } 1658 leaf direction { type ipsec-traffic-direction; description "in/fwd/out"; } 1660 uses selector-grouping; 1661 leaf selector-priority {type uint32; default 0; description "It establishes a priority to the traffic selector";} 1662 ordered-by user; 1664 description "List of traffic selectors"; 1665 } 1666 } 1668 container processing-info { 1669 description "SPD processing -> RFC4301"; 1670 leaf action{ type ipsec-spd-operation; mandatory true; description "If the action is bypass or discard processing container ipsec-sa-cfg is empty";} 1672 container ipsec-sa-cfg { 1673 when "../action = 'PROTECT'"; 1675 leaf pfp-flag { type boolean; description "Each selector has with a pfp flag."; } 1676 leaf extSeqNum { type boolean; description "TRUE 64 bit counter, FALSE 32 bit"; } 1677 leaf seqOverflow { type boolean; description "TRUE rekey, FALSE terminare & audit"; } 1678 leaf statefulfragCheck { type boolean; description "TRUE stateful fragment checking, FALSE no stateful fragment checking"; } 1679 leaf security-protocol { type ipsec-protocol; description "Security protocol of IPsec SA: Either AH or ESP."; } 1680 leaf mode { type ipsec-mode; description "transport/tunnel"; } 1682 container ah-algorithms { 1683 when "../security-protocol = 'ah'"; 1684 leaf-list ah-algorithm { 1685 type integrity-algorithm-t; 1686 description "Configure Authentication Header (AH)."; 1687 } 1688 description "AH algoritms "; 1689 } 1691 container esp-algorithms { 1692 when "../security-protocol = 'esp'"; 1693 description "Configure Encapsulating Security Payload (ESP)."; 1694 leaf-list authentication { type integrity-algorithm-t; description "Configure ESP authentication"; } 1695 leaf-list encryption { type encryption-algorithm-t; description "Configure ESP encryption"; } 1696 } 1698 container tunnel { 1699 when "../mode = 'TUNNEL'"; 1700 uses tunnel-grouping; 1701 description "tunnel grouping container"; 1702 } 1703 description " IPSec SA configuration container"; 1704 } 1705 } 1707 container spd-lifetime { 1708 description "SPD lifetime parameters"; 1709 leaf time-soft { type uint32; default 0; description "Soft time lifetime";} 1710 leaf time-hard { type uint32; default 0; description "Hard time lifetime";} 1711 leaf time-use-soft { type uint32; default 0; description "Use soft lifetime";} 1712 leaf time-use-hard { type uint32; default 0; description "Use hard lifetime";} 1713 leaf byte-soft { type uint32; default 0; description "Byte soft lifetime";} 1714 leaf byte-hard { type uint32; default 0; description "Hard soft lifetime";} 1715 leaf packet-soft {type uint32; default 0; description "Packet soft lifetime";} 1716 leaf packet-hard { type uint32; default 0; description "Packet hard lifetime";} 1717 } 1718 }/* grouping ipsec-policy-grouping */ 1720 /*################ end SPD grouping ##################*/ 1722 /*################## IKEv2-grouping ##################*/ 1724 grouping isakmp-proposal { 1725 description "ISAKMP proposal grouping"; 1726 leaf phase1-lifetime { 1727 type uint32; 1728 mandatory true; 1729 description "lifetime for IKE Phase 1 SAs"; 1730 } 1731 leaf-list phase1-authalg { 1732 type integrity-algorithm-t; 1733 description "Auth algorigthm for IKE Phase 1 SAs"; 1734 } 1735 leaf-list phase1-encalg { 1736 type encryption-algorithm-t; 1737 description "Auth algorigthm for IKE Phase 1 SAs"; 1738 } 1740 leaf combined-enc-intr { type boolean; description "Combined mode algorithms (encryption and integrity).";} 1742 leaf dh_group { 1743 type uint32; 1744 mandatory true; 1745 description "Group number for Diffie Hellman Exponentiation"; 1746 } 1747 } /* list isakmp-proposal */ 1749 grouping phase2-info { 1750 description "IKE Phase 2 Information"; 1752 leaf-list pfs_group { 1753 type uint32; 1754 description 1755 "If non-zero, require perfect forward secrecy 1756 when requesting new SA. The non-zero value is 1757 the required group number"; 1758 } 1760 } 1762 grouping local-grouping { 1763 description "Configure the local peer in an IKE connection"; 1765 container local { 1766 description "Local container"; 1767 choice my-identifier-type { 1768 default ipv4; 1769 case ipv4 { 1770 leaf ipv4 { 1771 type inet:ipv4-address; 1772 description "IPv4 dotted-decimal address"; 1773 } 1774 } 1775 case ipv6 { 1776 leaf ipv6 { 1777 type inet:ipv6-address; 1778 description "numerical IPv6 address"; 1779 } 1780 } 1781 case fqdn { 1782 leaf fqdn { 1783 type inet:domain-name; 1784 description "Fully Qualifed Domain name "; 1785 } 1786 } 1787 case dn { 1788 leaf dn { 1789 type string; 1790 description "Domain name"; 1791 } 1792 } 1793 case user_fqdn { 1794 leaf user_fqdn { 1795 type string; 1796 description "User FQDN"; 1797 } 1798 } 1799 description "Local ID type"; 1800 } 1801 leaf my-identifier { 1802 type string; 1803 mandatory true; 1804 description "Local id used for authentication"; 1805 } 1806 } 1807 } 1809 grouping remote-grouping { 1810 description "Configure the remote peer in an IKE connection"; 1811 container remote { 1812 description "Remote container"; 1813 choice my-identifier-type { 1814 default ipv4; 1815 case ipv4 { 1816 leaf ipv4 { 1817 type inet:ipv4-address; 1818 description "IPv4 dotted-decimal address"; 1819 } 1820 } 1821 case ipv6 { 1822 leaf ipv6 { 1823 type inet:ipv6-address; 1824 description "numerical IPv6 address"; 1825 } 1826 } 1827 case fqdn { 1828 leaf fqdn { 1829 type inet:domain-name; 1830 description "Fully Qualifed Domain name "; 1831 } 1832 } 1833 case dn { 1834 leaf dn { 1835 type string; 1836 description "Domain name"; 1837 } 1838 } 1839 case user_fqdn { 1840 leaf user_fqdn { 1841 type string; 1842 description "User FQDN"; 1843 } 1844 } 1845 description "Local ID type"; 1846 } 1847 leaf my-identifier { 1848 type string; 1849 mandatory true; 1850 description "Local id used for authentication"; 1851 } 1852 } 1853 } 1855 /*################## End IKEv2-groupingUMU ##################*/ 1857 /*################# Register grouping #################*/ 1859 typedef sadb-msg-type { 1861 type enumeration { 1862 enum sadb_reserved { description "SADB_RESERVED";} 1863 enum sadb_getspi { description "SADB_GETSPI";} 1864 enum sadb_update { description "SADB_UPDATE";} 1865 enum sadb_add { description "SADB_ADD";} 1866 enum sadb_delete { description "SADB_DELETE"; } 1867 enum sadb_get { description "SADB_GET"; } 1868 enum sadb_acquire { description "SADB_ACQUIRE"; } 1869 enum sadb_register { description "SADB_REGISTER"; } 1870 enum sadb_expire { description "SADB_EXPIRE"; } 1871 enum sadb_flush { description "SADB_FLUSH"; } 1872 enum sadb_dump { description "SADB_DUMP"; } 1873 enum sadb_x_promisc { description "SADB_X_PROMISC"; } 1874 enum sadb_x_pchange { description "SADB_X_PCHANGE"; } 1875 enum sadb_max{ description "SADB_MAX"; } 1876 } 1877 description "PF_KEY base message types"; 1878 } 1880 typedef sadb-msg-satype { 1882 type enumeration { 1883 enum sadb_satype_unspec { description "SADB_SATYPE_UNSPEC"; } 1884 enum sadb_satype_ah { description "SADB_SATYPE_AH"; } 1885 enum sadb_satype_esp { description "SADB_SATYPE_ESP"; } 1886 enum sadb_satype_rsvp { description "SADB_SATYPE_RSVP"; } 1887 enum sadb_satype_ospfv2 { description "SADB_SATYPE_OSPFv2"; } 1888 enum sadb_satype_ripv2 { description "SADB_SATYPE_RIPv2"; } 1889 enum sadb_satype_mip { description "SADB_SATYPE_MIP"; } 1890 enum sadb_satype_max { description "SADB_SATYPE_MAX"; } 1891 } 1892 description "PF_KEY Security Association types"; 1893 } 1895 grouping base-grouping { 1896 description "Configuration for the message header format"; 1897 list base-list { 1898 key "version"; 1899 leaf version { type string; description "Version of PF_KEY (MUST be PF_KEY_V2)"; } 1900 leaf msg_type { type sadb-msg-type; description "Identifies the type of message"; } 1901 leaf msg_satype { type sadb-msg-satype; description "Defines the type of Security Association"; } 1902 leaf msg_seq { type uint32; description "Sequence number of this message."; } 1903 description "Configuration for a specific message header format"; 1904 } 1905 } 1907 grouping algorithm-grouping { 1908 description "List of supported authentication and encryptation algorithms"; 1909 list algorithm-supported{ 1910 container authentication { 1911 description "Authentication algorithm supported"; 1912 leaf name { type integrity-algorithm-t; description "Name of authentication algorithm"; } 1913 leaf ivlen { type uint8; description "Length of the initialization vector to be used for the algorithm"; } 1914 leaf min-bits { type uint16; description "The minimun acceptable key length, in bits"; } 1915 leaf max-bits { type uint16; description "The maximun acceptable key length, in bits"; } 1916 } 1917 container encryption { 1918 description "Encryptation algorithm supported"; 1919 leaf name { type encryption-algorithm-t; description "Name of encryption algorithm"; } 1920 leaf ivlen { type uint8; description "Length of the initialization vector to be used for the algorithm"; } 1921 leaf min-bits { type uint16; description "The minimun acceptable key length, in bits"; } 1922 leaf max-bits { type uint16; description "The maximun acceptable key length, in bits"; } 1923 } 1924 description "List for a specific algorithm"; 1925 } 1926 } 1928 /*################# End Register grouping #################*/ 1930 /*################## ipsec ##################*/ 1932 container ietf-ipsec { 1933 description "Main IPsec container "; 1935 container ikev2 { 1936 if-feature case1; 1937 description "Configure the IKEv2"; 1939 container ike-connection { 1940 description "IKE connections configuration"; 1942 list ike-conn-entries { 1943 key "conn-name"; 1944 description "IKE peer connetion information"; 1945 leaf conn-name { 1946 type string; 1947 mandatory true; 1948 description "Name of IKE connection"; 1949 } 1950 leaf autostartup { 1951 type type-autostartup; 1952 mandatory true; 1953 description "if True: automatically start tunnel at startup; else we do lazy tunnel setup based on trigger from datapath"; 1954 } 1955 leaf nat-traversal { 1956 type boolean; 1957 default false; 1958 description "Enable/Disable NAT traversal"; 1959 } 1961 container encap { 1962 when "../nat-traversal = 'true'"; 1963 description "Encapsulation container"; 1964 leaf espencap { type esp-encap; description "ESP in TCP, ESP in UDP or ESP in TLS";} 1965 leaf sport {type inet:port-number; description "Encapsulation source port";} 1966 leaf dport {type inet:port-number; description "Encapsulation destination port"; } 1967 leaf oaddr {type inet:ip-address; description "Encapsulation Original Address ";} 1968 } 1970 leaf version { 1971 type enumeration { 1972 /* we only support ikev2 in this version */ 1973 enum ikev2 {value 2; description "IKE version 2";} 1974 } 1975 description "IKE version"; 1976 } 1978 uses isakmp-proposal; 1979 uses local-grouping; 1980 uses remote-grouping; 1981 uses phase2-info; 1983 } /* ike-conn-entries */ 1984 } /* container ike-connection */ 1985 } /* container ikev2 */ 1987 container ipsec { 1988 description "Configuration IPsec"; 1990 container spd { 1991 description "Configure the Security Policy Database (SPD)"; 1992 list spd-entry { 1993 key "rule-number"; 1994 uses ipsec-policy-grouping; 1995 ordered-by user; 1996 description "List of SPD entries"; 1997 } 1998 } 2000 container sad { 2001 if-feature case2; 2002 description "Configure the IPSec Security Association Database (SAD)"; 2003 list sad-entry { 2004 key "spi"; 2005 uses ipsec-sa-grouping; 2006 description "List of SAD entries"; 2007 } 2008 } 2010 container pad { 2011 if-feature case1; 2012 description "Configure Peer Authorization Database (PAD)"; 2013 list pad-entries { 2014 key "pad-entry-id"; 2015 ordered-by user; 2016 description "Peer Authorization Database (PAD)"; 2018 leaf pad-entry-id { 2019 type uint64; 2020 description "SAD index. "; 2021 } 2023 uses identity-grouping; 2025 leaf pad-auth-protocol { 2026 type auth-protocol-type; 2027 description "IKEv1, IKEv2, KINK, etc. "; 2028 } 2029 uses auth-method-grouping; 2030 } 2031 } 2032 } 2034 } /* container ietf-ipsec */ 2036 /*########## State Data ############*/ 2038 // TBD 2040 /*################## RPC and Notifications ##################*/ 2042 /* Note: not yet completed */ 2043 // Those RPCs are needed by a Security Controller in case 2 */ 2045 rpc sadb_register { 2046 description "Allows netconf to register its key socket as able to acquire new security associations for the kernel"; 2047 input { 2048 uses base-grouping; 2049 } 2050 output { 2051 uses base-grouping; 2052 uses algorithm-grouping; 2053 } 2054 } 2056 notification spdb_expire { 2057 description "A SPD entry has expired"; 2058 leaf index { 2059 type uint64; 2060 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. "; 2061 } 2062 } 2064 notification sadb_acquire { 2065 description "A IPsec SA is required "; 2066 leaf state { 2067 type uint32; 2068 mandatory "true"; 2069 description 2070 "Request the creation of a SADB entry"; 2071 } 2072 } 2074 notification sadb_expire { 2075 description "....."; 2076 leaf state { 2077 type uint32; 2078 mandatory "true"; 2079 description 2080 "Notify the expiration of a entry in the SADB"; 2081 } 2082 } 2084 notification sadb_bad-spi { 2085 description "....."; 2086 leaf state { 2087 type ipsec-spi; 2088 mandatory "true"; 2089 description "Notify when a SPI"; 2090 } 2092 } 2094 } /*module ietf-ipsec*/ 2096 2098 Authors' Addresses 2100 Rafa Marin-Lopez 2101 University of Murcia 2102 Campus de Espinardo S/N, Faculty of Computer Science 2103 Murcia 30100 2104 Spain 2106 Phone: +34 868 88 85 01 2107 EMail: rafa@um.es 2109 Gabriel Lopez-Millan 2110 University of Murcia 2111 Campus de Espinardo S/N, Faculty of Computer Science 2112 Murcia 30100 2113 Spain 2115 Phone: +34 868 88 85 04 2116 EMail: gabilm@um.es