idnits 2.17.1 draft-ietf-i2nsf-sdn-ipsec-flow-protection-00.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 437 has weird spacing: '...w start ine...' == Line 440 has weird spacing: '...w start ine...' == Line 444 has weird spacing: '...w start ine...' == Line 447 has weird spacing: '...w start ine...' == Line 494 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 (October 28, 2017) is 2343 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 991, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2nsf-framework' is defined on line 1003, but no explicit reference was found in the text == Unused Reference: 'I-D.jeong-i2nsf-sdn-security-services-05' is defined on line 1021, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-10) exists of draft-ietf-i2nsf-framework-08 == Outdated reference: A later version (-08) exists of draft-ietf-i2nsf-terminology-04 -- 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: May 1, 2018 October 28, 2017 7 Software-Defined Networking (SDN)-based IPsec Flow Protection 8 draft-ietf-i2nsf-sdn-ipsec-flow-protection-00 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 May 1, 2018. 47 Copyright Notice 49 Copyright (c) 2017 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 . . . . . . . . . . . . . . . 9 75 6.1. Security Policy Database (SPD) Model . . . . . . . . . . 10 76 6.2. Security Association Database (SAD) Model . . . . . . . . 11 77 6.3. Peer Authorization Database (PAD) Model . . . . . . . . . 13 78 6.4. Internet Key Exchange (IKE) Model . . . . . . . . . . . . 14 79 7. Use cases examples . . . . . . . . . . . . . . . . . . . . . 16 80 7.1. Host-to-Host or Gateway-to-gateway under the same 81 controller . . . . . . . . . . . . . . . . . . . . . . . 16 82 7.2. Host-to-Host or Gateway-to-gateway under different 83 Security controllers . . . . . . . . . . . . . . . . . . 18 84 8. Implementation notes . . . . . . . . . . . . . . . . . . . . 20 85 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 86 9.1. Case 1: . . . . . . . . . . . . . . . . . . . . . . . . . 22 87 9.2. Case 2 . . . . . . . . . . . . . . . . . . . . . . . . . 22 88 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 89 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 90 11.1. Normative References . . . . . . . . . . . . . . . . . . 23 91 11.2. Informative References . . . . . . . . . . . . . . . . . 23 92 Appendix A. Appendix A: YANG model IPsec Configuration data . . 26 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 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 IPsec 399 state. By default, the Security Controller can assume that all the 400 state has been lost and therefore it will have to send IKEv2, SPD and 401 PAD information to the NSF in case 1 and SPD and SAD information in 402 case 2. Nevertheless other more optimized options can be considered 403 (e.g. making iKEv2 configuration permanent between reboots). 405 6. YANG configuration data models 407 In order to support case 1 and case 2 we have modelled the different 408 parameters and values that must be configured to manage IPsec SAs. 409 Specifically, case 1 requires modelling IKEv2, SPD and PAD while case 410 2 requires models for the SPD and SAD. A single YANG file represents 411 both cases though some part of the models are selectively activated 412 depending a feature defined in the YANG file. For example, the IKE 413 configuration is not enabled in case 2. 415 In the following, we summarize, by using a tree representation, the 416 different configuration data models (NOTE: State data models are TBD 417 though they are expected to be very similar to the model defined 418 here). The complete YANG configuration data model is in Appendix A 420 6.1. Security Policy Database (SPD) Model 422 The definition of this model has been extracted from the 423 specification in section 4.4.1 and Appendix D in [RFC4301] 425 +--rw spd 426 | +--rw spd-entry* [rule-number] 427 | +--rw rule-number uint64 428 | +--rw priority? uint32 429 | +--rw names* [name] 430 | | +--rw name-type? ipsec-spd-name 431 | | +--rw name string 432 | +--rw condition 433 | | +--rw traffic-selector-list* [ts-number] 434 | | +--rw ts-number uint32 435 | | +--rw direction? ipsec-traffic-direction 436 | | +--rw local-addresses* [start end] 437 | | | +--rw start inet:ip-address 438 | | | +--rw end inet:ip-address 439 | | +--rw remote-addresses* [start end] 440 | | | +--rw start inet:ip-address 441 | | | +--rw end inet:ip-address 442 | | +--rw next-layer-protocol* ipsec-next-layer-proto 443 | | +--rw local-ports* [start end] 444 | | | +--rw start inet:port-number 445 | | | +--rw end inet:port-number 446 | | +--rw remote-ports* [start end] 447 | | | +--rw start inet:port-number 448 | | | +--rw end inet:port-number 449 | | +--rw selector-priority? uint32 450 | +--rw processing-info 451 | | +--rw action ipsec-spd-operation 452 | | +--rw ipsec-sa-cfg 453 | | +--rw pfp-flag? boolean 454 | | +--rw extSeqNum? boolean 455 | | +--rw seqOverflow? boolean 456 | | +--rw statefulfragCheck? boolean 457 | | +--rw security-protocol? ipsec-protocol 458 | | +--rw mode? ipsec-mode 459 | | +--rw ah-algorithms 460 | | | +--rw ah-algorithm* integrity-algorithm-t 461 | | +--rw esp-algorithms 462 | | | +--rw authentication* integrity-algorithm-t 463 | | | +--rw encryption* encryption-algorithm-t 464 | | +--rw tunnel 465 | | +--rw local? inet:ip-address 466 | | +--rw remote? inet:ip-address 467 | | +--rw bypass-df? boolean 468 | | +--rw bypass-dscp? boolean 469 | | +--rw dscp-mapping? yang:hex-string 470 | | +--rw ecn? boolean 471 | +--rw spd-lifetime 472 | +--rw time-soft? uint32 473 | +--rw time-hard? uint32 474 | +--rw time-use-soft? uint32 475 | +--rw time-use-hard? uint32 476 | +--rw byte-soft? uint32 477 | +--rw byte-hard? uint32 478 | +--rw packet-soft? uint32 479 | +--rw packet-hard? uint32 481 6.2. Security Association Database (SAD) Model 483 The definition of this model has been extracted from the 484 specification in section 4.4.2 in [RFC4301] 486 +--rw sad {case2}? 487 | +--rw sad-entry* [spi] 488 | +--rw spi ipsec-spi 489 | +--rw seq-number? uint64 490 | +--rw seq-number-overflow-flag? boolean 491 | +--rw anti-replay-window? uint16 492 | +--rw rule-number? uint32 493 | +--rw local-addresses* [start end] 494 | | +--rw start inet:ip-address 495 | | +--rw end inet:ip-address 496 | +--rw remote-addresses* [start end] 497 | | +--rw start inet:ip-address 498 | | +--rw end inet:ip-address 499 | +--rw next-layer-protocol* ipsec-next-layer-proto 500 | +--rw local-ports* [start end] 501 | | +--rw start inet:port-number 502 | | +--rw end inet:port-number 503 | +--rw remote-ports* [start end] 504 | | +--rw start inet:port-number 505 | | +--rw end inet:port-number 506 | +--rw security-protocol? ipsec-protocol 507 | +--rw ah-sa 508 | | +--rw integrity 509 | | +--rw integrity-algorithm? integrity-algorithm-t 510 | | +--rw key? string 511 | +--rw esp-sa 512 | | +--rw encryption 513 | | | +--rw encryption-algorithm? encryption-algorithm-t 514 | | | +--rw key? string 515 | | | +--rw iv? string 516 | | +--rw integrity 517 | | | +--rw integrity-algorithm? integrity-algorithm-t 518 | | | +--rw key? string 519 | | +--rw combined-enc-intr? boolean 520 | +--rw sa-lifetime 521 | | +--rw time-soft? uint32 522 | | +--rw time-hard? uint32 523 | | +--rw time-use-soft? uint32 524 | | +--rw time-use-hard? uint32 525 | | +--rw byte-soft? uint32 526 | | +--rw byte-hard? uint32 527 | | +--rw packet-soft? uint32 528 | | +--rw packet-hard? uint32 529 | | +--rw action? lifetime-action 530 | +--rw mode? ipsec-mode 531 | +--rw statefulfragCheck? boolean 532 | +--rw dscp? yang:hex-string 533 | +--rw tunnel 534 | | +--rw local? inet:ip-address 535 | | +--rw remote? inet:ip-address 536 | | +--rw bypass-df? boolean 537 | | +--rw bypass-dscp? boolean 538 | | +--rw dscp-mapping? yang:hex-string 539 | | +--rw ecn? boolean 540 | +--rw path-mtu? uint16 541 | +--rw encap 542 | +--rw espencap? esp-encap 543 | +--rw sport? inet:port-number 544 | +--rw dport? inet:port-number 545 | +--rw oaddr? inet:ip-address 547 rpcs: 548 +---x sadb_register 549 +---w input 550 | +---w base-list* [version] 551 | +---w version string 552 | +---w msg_type? sadb-msg-type 553 | +---w msg_satype? sadb-msg-satype 554 | +---w msg_seq? uint32 555 +--ro output 556 +--ro base-list* [version] 557 | +--ro version string 558 | +--ro msg_type? sadb-msg-type 559 | +--ro msg_satype? sadb-msg-satype 560 | +--ro msg_seq? uint32 561 +--ro algorithm-supported* 562 +--ro authentication 563 | +--ro name? integrity-algorithm-t 564 | +--ro ivlen? uint8 565 | +--ro min-bits? uint16 566 | +--ro max-bits? uint16 567 +--ro encryption 568 +--ro name? encryption-algorithm-t 569 +--ro ivlen? uint8 570 +--ro min-bits? uint16 571 +--ro max-bits? uint16 573 notifications: 574 +---n spdb_expire 575 | +--ro index? uint64 576 +---n sadb_acquire 577 | +--ro state uint32 578 +---n sadb_expire 579 | +--ro state uint32 580 +---n sadb_bad-spi 581 +--ro state ipsec-spi 583 6.3. Peer Authorization Database (PAD) Model 585 The definition of this model has been extracted from the 586 specification in section 4.4.3 in [RFC4301] (NOTE: We have observed 587 that many implementations integrate PAD configuration as part of the 588 IKE configuration.) 589 +--rw pad {case1}? 590 +--rw pad-entries* [pad-entry-id] 591 +--rw pad-entry-id uint64 592 +--rw (identity)? 593 | +--:(ipv4-address) 594 | | +--rw ipv4-address? inet:ipv4-address 595 | +--:(ipv6-address) 596 | | +--rw ipv6-address? inet:ipv6-address 597 | +--:(fqdn-string) 598 | | +--rw fqdn-string? inet:domain-name 599 | +--:(rfc822-address-string) 600 | | +--rw rfc822-address-string? string 601 | +--:(dnX509) 602 | | +--rw dnX509? string 603 | +--:(id_key) 604 | +--rw id_key? string 605 +--rw pad-auth-protocol? auth-protocol-type 606 +--rw auth-method 607 +--rw auth-m? auth-method-type 608 +--rw pre-shared 609 | +--rw secret? string 610 +--rw rsa-signature 611 +--rw key-data? string 612 +--rw key-file? string 613 +--rw ca-data* string 614 +--rw ca-file? string 615 +--rw cert-data? string 616 +--rw cert-file? string 617 +--rw crl-data? string 618 +--rw crl-file? string 620 6.4. Internet Key Exchange (IKE) Model 622 The model related to IKEv2 has been extracted from reading IKEv2 623 standard in [RFC7296], and observing some open source 624 implementations, such as Strongswan or Libreswan. 626 +--rw ikev2 {case1}? 627 | +--rw ike-connection 628 | +--rw ike-conn-entries* [conn-name] 629 | +--rw conn-name string 630 | +--rw autostartup type-autostartup 631 | +--rw nat-traversal? boolean 632 | +--rw encap 633 | | +--rw espencap? esp-encap 634 | | +--rw sport? inet:port-number 635 | | +--rw dport? inet:port-number 636 | | +--rw oaddr? inet:ip-address 637 | +--rw version? enumeration 638 | +--rw phase1-lifetime uint32 639 | +--rw phase1-authalg* integrity-algorithm-t 640 | +--rw phase1-encalg* encryption-algorithm-t 641 | +--rw combined-enc-intr? boolean 642 | +--rw dh_group uint32 643 | +--rw local 644 | | +--rw (my-identifier-type)? 645 | | | +--:(ipv4) 646 | | | | +--rw ipv4? inet:ipv4-address 647 | | | +--:(ipv6) 648 | | | | +--rw ipv6? inet:ipv6-address 649 | | | +--:(fqdn) 650 | | | | +--rw fqdn? inet:domain-name 651 | | | +--:(dn) 652 | | | | +--rw dn? string 653 | | | +--:(user_fqdn) 654 | | | +--rw user_fqdn? string 655 | | +--rw my-identifier string 656 | +--rw remote 657 | | +--rw (my-identifier-type)? 658 | | | +--:(ipv4) 659 | | | | +--rw ipv4? inet:ipv4-address 660 | | | +--:(ipv6) 661 | | | | +--rw ipv6? inet:ipv6-address 662 | | | +--:(fqdn) 663 | | | | +--rw fqdn? inet:domain-name 664 | | | +--:(dn) 665 | | | | +--rw dn? string 666 | | | +--:(user_fqdn) 667 | | | +--rw user_fqdn? string 668 | | +--rw my-identifier string 669 | +--rw pfs_group* uint32 671 7. Use cases examples 673 This section explains how different traditional configurations, that 674 is, host-to-host and gateway-to-gateway are deployed using our SDN- 675 based IPsec management service. In turn, these configurations will 676 be typical in modern networks where, for example, virtualization will 677 be key. 679 7.1. Host-to-Host or Gateway-to-gateway under the same controller 681 +----------------------------------------+ 682 | Security Controller | 683 | | 684 (1)| +--------------+ (2)+--------------+ | 685 Flow-based ------> |Translate into|--->| South. Prot. | | 686 Security. Pol. | |IPsec Policies| | | | 687 | +--------------+ +--------------+ | 688 | | | | 689 | | | | 690 +--------------------------|-----|-------+ 691 | | 692 | (3) | 693 |-------------------------+ +---| 694 V V 695 +----------------------+ +----------------------+ 696 | NSF1 |<=======>| NSF2 | 697 |IKE/IPsec(SPD/PAD) | |IKE/IPsec(SPD/PAD) | 698 +----------------------+ (4) +----------------------+ 700 Figure 3: Host-to-Host / Gateway-to-Gateway single controller flow 701 for case 1 . 703 Figure 3 describes the case 1: 705 1. The administrator defines general flow-based security policies. 706 The controller looks for the NSFs involved (NSF1 and NSF2). 708 2. The controller generates IKE credentials for them and translates 709 the policies into SPD and PAD entries. 711 3. The controller inserts the SPD and PAD entries in both NSF1 and 712 NSF2. 714 4. The flow is protected with the IPsec SA established with IKEv2. 716 +----------------------------------------+ 717 | (1) Security Controller | 718 Flow-based | | 719 Security -----------| | 720 Policy | V | 721 | +---------------+ (2)+-------------+ | 722 | |Translate into |--->| South. Prot.| | 723 | |IPsec policies | | | | 724 | +---------------+ +-------------+ | 725 | | | | 726 | | | | 727 +-------------------------| --- |--------+ 728 | | 729 | (3) | 730 |----------------------+ +--| 731 V V 732 +------------------+ +------------------+ 733 | NSF1 |<=====>| NSF2 | 734 |IPsec(SPD/SAD) | 4) |IPsec(SPD/SAD) | 735 +------------------+ +------------------+ 737 Figure 4: Host-to-Host / Gateway-to-Gateway single controller flow 738 for case 2. 740 In case 2, flow-based security policies defined by the administrator 741 are also translated into IPsec SPD entries and inserted into the 742 corresponding NSFs. Besides, fresh SAD entries will be also 743 generated by the controller and enforced in the NSFs. In this case 744 the controller does not run any IKE implementation, and it provides 745 the cryptographic material for the IPsec SAs. These keys will be 746 also distributed securely through the southbound interface. Note 747 that this is possible because both NSFs are managed by the same 748 controller. 750 Figure 4 describes the case 2, when a data packet needs to be 751 protected in the path between the NSF1 and NSF2: 753 1. The administrator establishes the flow-based security policies. 754 The controller looks for the involved NSFs. 756 2. The controller translates the flow-based security policies into 757 IPsec SPD and SAD entries. 759 3. The controller inserts the these entries in both NSF1 and NSF2 760 IPsec databases. 762 4. The flow is protected with the IPsec SA established by the 763 Security Controller. 765 Both NSFs could be two hosts that exchange traffic and require to 766 establish an end-to-end security association to protect their 767 communications (host-to-host) or two gateways (gateway-to-gateway)), 768 for example, within an enterprise that needs to protect the traffic 769 between, for example, the networks of two branch offices. 771 Applicability of these configurations appear in current and new 772 networking scenarios. For example, SD-WAN technologies are providing 773 dynamic and on-demand VPN connections between branch offices or 774 between branches and SaaS cloud services. Beside, IaaS services 775 providing virtualization environments are deployments solutions based 776 on IPsec to provide secure channels between virtual instances (Host- 777 to-Host) and providing VPN solutions for virtualized networks 778 (Gateway-to-Gateway). 780 In general (for case 1 and case 2), this system presents various 781 advantages: 783 1. It allows to create a IPsec SA among two NSFs, with only the 784 application of more general flow-based security policies at the 785 application layer. Thus, administrators can manage all security 786 associations in a centralized point with an abstracted view of 787 the network; 789 2. All NSFs deployed after the application of the new policies are 790 NOT manually configured, therefore allowing its deployment in an 791 automated manner. 793 7.2. Host-to-Host or Gateway-to-gateway under different Security 794 controllers 796 It is also possible that two NSFs (i.e. NSF1 and NSF2) are under the 797 control of two different Security Controllers. This may happen, for 798 example, when two organizations, namely Enterprise A and Enterprise 799 B, have their headquarters interconnected through a WAN connection 800 and they both have deployed a SDN-based architecture to provide 801 connectivity to all their clients. 803 +-------------+ +-------------+ 804 | | | | 805 Flow-based| Security |<===============>| Security <--Flow-based 806 Sec. Pol.--> Controller | (3) | Controller | Sec. Pol. 807 (1) | A | | B | (2) 808 +-------------+ +-------------+ 809 | | 810 | (4) (4) | 811 V V 812 +----------------------+ +----------------------+ 813 | NSF1 |<========>| NSF2 | 814 |IKE/IPsec(SPD/PAD) | |IKE/IPsec(SPD/PAD) | 815 +----------------------+ (5) +----------------------+ 817 Figure 5: Different Security Controllers in Case 1 819 Figure 5 describes case 1 when two Security Controllers are involved 820 in the process. 822 1. The A's 'administrator establishes general Flow-based Security 823 Policies in Security Controller A. 825 2. The B's administrator establishes general Flow-based Security 826 Policies in Security Controller B. 828 3. The Security Controller A realizes that protection is required 829 between the NSF1 and NSF2, but the NSF2 is under the control of 830 another Security Controller (Security Controller B), so it starts 831 negotiations with the other controller to agree on the IPsec SPD 832 policies and IKE credentials for their respective NSFs. NOTE: 833 This may require extensions in the East/West interface. 835 4. Then, both Security Controllers enforce the IKE credentials and 836 related parameters and the SPD and PAD entries in their 837 respective NSFs. 839 5. The flow is protected with the IPsec SA established with IKEv2 840 between both NSFs. 842 +--------------+ +--------------+ 843 | | | | 844 Flow-based. ---> | <---- Flow-based 845 Prot. | Security |<=================>| Security |Sec. 846 Pol.(1)| Controller | (3) | Controller |Pol. (2) 847 | A | | B | 848 +--------------+ +--------------+ 849 | | 850 | (4) (4) | 851 V V 852 +------------------+ (5) +------------------+ 853 | NSF1 |<==============>| NSF2 | 854 |IPsec(SPD/SAD) | | IPsec(SPD/SAD) | 855 +------------------+ +------------------+ 857 Figure 6: Different Security Controllers in case 2 859 Figure 5 describes case 1 when two Security Controllers are involved 860 in the process. 862 1. The A's administrator establishes general Flow Protection 863 Policies in Security Controller A. 865 2. The B's administrator establishes general Flow Protection 866 Policies in Security Controller B. 868 3. The Security Controller A realizes that the flow between NSF1 and 869 NSF2 MUST be protected. Nevertheless, the controller notices 870 that NSF2 is under the control of another Security Controller, so 871 it starts negotiations with the other controller to agree on the 872 IPsec SPD and SAD entries that define the IPsec SAs. NOTE: It 873 would worth evaluating IKE as the protocol for the East/West 874 interface in this case. 876 4. Once the controllers have agreed on key material and the details 877 of the IPsec SA, they both enforce this information into their 878 respective NSFs. 880 5. The flow is protected with the IPsec SA established by both 881 Security Controllers in their respective NSFs. 883 8. Implementation notes 885 At the time of writing this document, we have implemented a proof-of- 886 concept using NETCONF as southbound protocol, and the YANG model 887 described in Appendix A. The netopeer implementation [netopeer] has 888 been used for both case 1 and case 2 using host-to-host and gateway- 889 to-gateway configuration. For the case 1, we have used Strongswan 890 [strongswan] distribution for the IKE implementation. 892 Note that the proposed YANG model provides the models for SPD, SAD, 893 PAD and IKE, but, as describe before, only part of them are required 894 depending of the case (1 or 2) been applied. The Controller should 895 be able to know the kind of case to be applied in the NSF and to 896 select the corresponding models based on the YANG features defines 897 for each one 899 Internally to the NSF, the NETCONF server (that implements the I2NSF 900 Agent) is able to apply the required configuration updating the 901 corresponding NETCONF datastores (running, startup, etc.). Besides, 902 it can deal with the SPD and SAD configuration at kernel level, 903 through different APIs. For example, the IETF RFC 2367 (PF_KEYv2) 904 [RFC2367] provides a generic key management API that can be used not 905 only for IPsec but also for other network security services to manage 906 the IPsec SAD. Besides, as an extension to this API, the document 907 [I-D.pfkey-spd] specifies some PF_KEY extensions to maintain the SPD. 908 This API is accessed using sockets. 910 An alternative key management API based on Netlink socket API 911 [RFC3549] is used to configure IPsec on the Linux Operating System. 913 To allow the NETCONF server implementation interacts with the IKE 914 daemon, we have used the Versatile IKE Configuration Interface (VICI) 915 in Strongswan. This allows changes in the IKE part of the 916 configuration data to be applied in the IKE daemon dynamically. 918 9. Security Considerations 920 First of all, this document shares all the security issues of SDN 921 that are specified in the "Security Considerations" section of 922 [ITU-T.Y.3300] and [RFC8192]. We have divided this section in two 923 parts to analyze different security considerations for both cases: 924 NSF with IKEv2 (case 1) and NSF without IKEv2 (case 2). In general, 925 the Security Controller, as typically in the SDN paradigm, is a 926 target for different type of attacks. As a consequence, the Security 927 Controller is a key entity in the infrastructure and MUST be 928 protected accordingly. In particular, according to this document, 929 the Security Controller will handle cryptographic material so that 930 the attacker may try to access this information. Although, we can 931 assume this attack will not likely to happen due to the assumed 932 security measurements to protect the Security Controller, some 933 analysis of the impact deserves some analysis in the hypothetical the 934 attack occurs. The impact is different depending on the case 1 or 935 case 2. 937 9.1. Case 1: 939 In this case 1, the controller sends IKE credentials (PSK, public/ 940 private keys, certificates, etc...) to the NSFs. The general 941 recommendation is that the Security Controller NEVER stores the IKE 942 credentials after distributing them. Moreover the NSFs MUST NOT 943 allow the reading of these values once they have been applied by the 944 Security Controller (i.e. write only operations). If the attacker 945 has access to the Security Controller during the period of time that 946 key material is generated, it may access to these values. Since 947 these values are used during NSF authentication in IKEv2, it may 948 impersonate the affected NSFs. Several recommendations are 949 important. If PSK is used, immediately after generating and 950 distributing it, the Security Controller should remove it. If raw 951 public keys are used, the Security Controller should remove the 952 associate private key immediately after generating and distributing 953 them to the Security Controller. If certificates are used, the NSF 954 may generate the private key and exports the public key for 955 certification in the Security Controller. 957 9.2. Case 2 959 In the case 2, the controller sends the IPsec SA to the SAD that 960 includes the keys for integrity and encryption (when ESP is used). 961 That key material are symmetric keys to protect data traffic. The 962 general recommendation is that the Security Controller NEVER stores 963 the keys after distributing them. Moreover the NSFs MUST NOT allow 964 the reading of these values once they have been applied by the 965 Security Controller (i.e. write only operations). Nevertheless, if 966 the attacker has access to the Security Controller during the period 967 of time that key material is generated, it may access to these 968 values. In other words, it may have access to the key material used 969 in the distributed IPsec SAs. 971 10. Acknowledgements 973 Authors want to thank Sowmini Varadhan, David Carrel, Yoav Nir, Tero 974 Kivinen, Paul Wouters, Graham Bartlett, Sandeep Kampati, Linda 975 Dunbar, Carlos J. Bernardos, Alejandro Perez-Mendez, Fernando 976 Pereniguez-Garcia, Alejandro Abad-Carrascosa, Ignacio Martinez and 977 Ruben Ricart for their valuable comments. 979 11. References 980 11.1. Normative References 982 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 983 Requirement Levels", BCP 14, RFC 2119, 984 DOI 10.17487/RFC2119, March 1997, 985 . 987 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 988 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 989 December 2005, . 991 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 992 IANA Considerations Section in RFCs", RFC 5226, 993 DOI 10.17487/RFC5226, May 2008, 994 . 996 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 997 Kivinen, "Internet Key Exchange Protocol Version 2 998 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 999 2014, . 1001 11.2. Informative References 1003 [I-D.ietf-i2nsf-framework] 1004 Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 1005 Kumar, "Framework for Interface to Network Security 1006 Functions", draft-ietf-i2nsf-framework-08 (work in 1007 progress), October 2017. 1009 [I-D.ietf-i2nsf-problem-and-use-cases] 1010 Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., 1011 and J. Jeong, "I2NSF Problem Statement and Use cases", 1012 draft-ietf-i2nsf-problem-and-use-cases-16 (work in 1013 progress), May 2017. 1015 [I-D.ietf-i2nsf-terminology] 1016 Hares, S., Strassner, J., Lopez, D., Xia, L., and H. 1017 Birkholz, "Interface to Network Security Functions (I2NSF) 1018 Terminology", draft-ietf-i2nsf-terminology-04 (work in 1019 progress), July 2017. 1021 [I-D.jeong-i2nsf-sdn-security-services-05] 1022 Jeong, J., Kim, H., Park, J., Ahn, T., and S. Lee, 1023 "Software-Defined Networking Based Security Services using 1024 Interface to Network Security Functions", draft-jeong- 1025 i2nsf-sdn-security-services-05 (work in progress), July 1026 2016. 1028 [I-D.pfkey-spd] 1029 Sakane, S., "PF_KEY Extensions for IPsec Policy Management 1030 in KAME Stack", October 2002. 1032 [I-D.sivakumar-yang-nat] 1033 Sivakumar, S., Boucadair, M., and S. Vinapamula, "YANG 1034 Data Model for Network Address Translation (NAT)", draft- 1035 sivakumar-yang-nat-07 (work in progress), July 2017. 1037 [I-D.tran-ipsecme-yang] 1038 Tran, K., Wang, H., Nagaraj, V., and X. Chen, "Yang Data 1039 Model for Internet Protocol Security (IPsec)", draft-tran- 1040 ipsecme-yang-01 (work in progress), June 2015. 1042 [ITU-T.X.1252] 1043 "Baseline Identity Management Terms and Definitions", 1044 April 2010. 1046 [ITU-T.X.800] 1047 "Security Architecture for Open Systems Interconnection 1048 for CCITT Applications", March 1991. 1050 [ITU-T.Y.3300] 1051 "Recommendation ITU-T Y.3300", June 2014. 1053 [netconf-vpn] 1054 Stefan Wallin, "Tutorial: NETCONF and YANG", January 2014. 1056 [netopeer] 1057 CESNET, CESNET., "NETCONF toolset Netopeer", November 1058 2016. 1060 [ONF-OpenFlow] 1061 ONF, "OpenFlow Switch Specification (Version 1.4.0)", 1062 October 2013. 1064 [ONF-SDN-Architecture] 1065 "SDN Architecture", June 2014. 1067 [RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key 1068 Management API, Version 2", RFC 2367, 1069 DOI 10.17487/RFC2367, July 1998, 1070 . 1072 [RFC3549] Salim, J., Khosravi, H., Kleen, A., and A. Kuznetsov, 1073 "Linux Netlink as an IP Services Protocol", RFC 3549, 1074 DOI 10.17487/RFC3549, July 2003, 1075 . 1077 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 1078 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 1079 RFC 3948, DOI 10.17487/RFC3948, January 2005, 1080 . 1082 [RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and 1083 Internet Key Exchange (IKE) Document Roadmap", RFC 6071, 1084 DOI 10.17487/RFC6071, February 2011, 1085 . 1087 [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined 1088 Networking: A Perspective from within a Service Provider 1089 Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, 1090 . 1092 [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for 1093 System Management", RFC 7317, DOI 10.17487/RFC7317, August 1094 2014, . 1096 [RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., 1097 and J. Jeong, "Interface to Network Security Functions 1098 (I2NSF): Problem Statement and Use Cases", RFC 8192, 1099 DOI 10.17487/RFC8192, July 2017, 1100 . 1102 [RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation 1103 of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229, 1104 August 2017, . 1106 [strongswan] 1107 CESNET, CESNET., "StrongSwan: the OpenSource IPsec-based 1108 VPN Solution", April 2017. 1110 Appendix A. Appendix A: YANG model IPsec Configuration data 1112 file "ietf-ipsec.yang" 1113 module ietf-ipsec { 1115 namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec"; 1117 prefix "eipsec"; 1119 import ietf-inet-types { prefix inet; } 1120 import ietf-yang-types { prefix yang; } 1122 organization "University of Murcia"; 1124 contact 1125 " Rafael Marin Lopez 1126 Dept. Information and Communications Engineering (DIIC) 1127 Faculty of Computer Science-University of Murcia 1128 30100 Murcia - Spain 1129 Telf: +34868888501 1130 e-mail: rafa@um.es 1132 Gabriel Lopez Millan 1133 Dept. Information and Communications Engineering (DIIC) 1134 Faculty of Computer Science-University of Murcia 1135 30100 Murcia - Spain 1136 Tel: +34 868888504 1137 email: gabilm@um.es 1138 "; 1140 description "Data model for IPSec"; 1142 revision "2017-05-02" { 1143 description 1144 "Initial revision."; 1145 reference ""; 1146 } 1148 feature case1 { description "feature case 1: IKE SPD PAD"; } // IKE/IPSec in the NSFs 1149 feature case2 { description "feature case 2: SPD SAD"; } // Only IPSec in the NSFs 1150 typedef encryption-algorithm-t { 1152 type enumeration { 1153 enum reserved-0 {description "reserved";} 1154 enum des-iv4 { description "DES IV 4";} 1155 enum des { description "DES"; } 1156 enum 3des { description "3DES"; } 1157 enum rc5 { description "RC5"; } 1158 enum idea { description "IDEA"; } 1159 enum cast { description "CAST"; } 1160 enum blowfish { description "BlowFish"; } 1161 enum 3idea { description "3IDEA"; } 1162 enum des-iv32 { description "DES-IV32"; } 1163 enum reserved-10 { description "reserved-10"; } 1164 enum null { description "NULL"; } 1165 enum aes-cbc { description "AES-CBC"; } 1166 enum aes-ctr { description "AES-CTR"; } 1167 enum aes-ccm-8 { description "AES-CCM-8"; } 1168 enum aes-ccm-12 { description "AES-CCM-12"; } 1169 enum aes-ccm-16 { description "AES-CCM-16"; } 1170 enum reserved-17 { description "reserved-17"; } 1171 enum aes-gcm-8-icv { description "AES-GCM-8-ICV"; } 1172 enum aes-gcm-12-icv { description "AES-GCM-12-ICV"; } 1173 enum aes-gcm-16-icv { description "AES-GCM-16-ICV"; } 1174 enum null-auth-aes-gmac { description "Null-Auth-AES-GMAC"; } 1175 enum ieee-p1619-xts-aes { 1176 description 1177 "encr-ieee-p1619-xts-aes -> Reserved for IEEE P1619 XTS-AES."; 1178 } 1179 enum camellia-cbc { description "CAMELLIA-CBC"; } 1180 enum camellia-ctr { description "CAMELLIA.CTR"; } 1181 enum camellia-ccm-8-icv { description "CAMELLIA-CCM-8-ICV"; } 1182 enum camellia-ccm-12-icv { description "CAMELLIA-CCM-12-ICV"; } 1183 enum camellia-ccm-16-icv { description "CAMELLIA-CCM-16-ICV"; } 1184 enum aes-cbc-128 { description "AES-CBC-128"; } 1185 enum aes-cbc-192 { description "AES-CBC-192"; } 1186 enum aes-cbc-256 { description "AES-CBC-256"; } 1187 enum blowfish-128 { description "BlowFish-128"; } 1188 enum blowfish-192 { description "BlowFish-192"; } 1189 enum blowfish-256 { description "BlowFish-256"; } 1190 enum blowfish-448 { description "BlowFish-448"; } 1191 enum camellia-128 { description "CAMELLIA-128"; } 1192 enum camellia-192 { description "CAMELLIA-192"; } 1193 enum camellia-256 { description "CAMELLIA-256"; } 1194 enum AES-GCM-16-ICV { description "AES-GCM-16-ICV (AEAD)"; } 1195 enum AES-CCM { description "AES-CCM (AEAD)"; } 1196 } 1197 description "Encryption algorithms -> RFC_5996"; 1198 } 1200 typedef integrity-algorithm-t { 1202 type enumeration { 1203 enum none { description "NONE"; } 1204 enum hmac-md5-96 { description "HMAC-MD5-96"; } 1205 enum hmac-sha1-96 { description "HMAC-SHA1-96"; } 1206 enum des-mac { description "DES-MAC"; } 1207 enum kpdk-md5 {description "KPDK-MD5"; } 1208 enum aes-xcbc-96 { description "AES-XCBC-96"; } 1209 enum hmac-md5-128 { description "HMAC-MD5-128"; } 1210 enum hmac-sha1-160 { description "HMAC-SHA1-160"; } 1211 enum aes-cmac-96 { description "AES-CMAC-96"; } 1212 enum aes-128-gmac { description "AES-128-GMAC"; } 1213 enum aes-192-gmac { description "AES-192-GMAC"; } 1214 enum aes-256-gmac { description "AES-256-GMAC"; } 1215 enum hmac-sha2-256-128 { description "HMAC-SHA2-256-128"; } 1216 enum hmac-sha2-384-192 { description "HMAC-SHA2-384-192"; } 1217 enum hmac-sha2-512-256 { description "HMAC-SHA2-512-256"; } 1218 enum hmac-sha2-256-96 { description "HMAC-SHA2-256-096"; } 1219 } 1220 description "Integrity Algorithms -> RFC_5996"; 1221 } 1223 typedef type-autostartup 1224 { 1225 type enumeration { 1226 enum ALWAYSON { description " ";} 1227 enum INITIATE-ON-DEMAND {description " ";} 1228 enum RESPOND-ONLY {description " ";} 1229 } 1230 description "Different types of how IKEv2 starts the IPsec SAs"; 1231 } 1233 typedef auth-protocol-type { 1234 type enumeration { 1235 enum IKEv1 { // not supported by model 1236 description "Authentication protocol based on IKEv1"; 1237 } 1238 enum IKEv2 { 1239 description "Authentication protocol based on IKEv2"; 1240 } 1241 enum KINK { // not supported by model 1242 description "Authentication protocol based on KINK"; 1243 } 1244 } 1245 description "Peer authentication protocols"; 1246 } 1248 typedef ipsec-mode { 1250 type enumeration { 1251 enum TRANSPORT { description "Transport mode"; } 1252 enum TUNNEL { description "Tunnel mode"; } 1253 enum BEET { description "Bound End-to-End Tunnel (BEET) mode for ESP.";} 1254 enum RO { description "Route Optimization mode for Mobile IPv6";} 1255 enum IN_TRIGGER {description "In trigger mode for Mobile IPv6";} 1256 } 1257 description "type define of ipsec mode"; 1258 } 1260 typedef esp-encap { 1262 type enumeration { 1263 enum ESPINTCP { description "ESP in TCP encapulation.";} 1264 enum ESPINTLS { description "ESP in TCP encapsulation using TLS.";} 1265 enum ESPINUDP { description "ESP in UDP encapsulation. RFC 3948 ";} 1266 } 1267 description "type defining types of ESP encapsulation"; 1268 } 1270 typedef ipsec-protocol { 1272 type enumeration { 1273 enum ah { description "AH Protocol"; } 1274 enum esp { description "ESP Protocol"; } 1275 enum comp { description "IP Compression";} /*Supported by XFRM*/ 1276 enum route2 { description "Routing Header type 2. Mobile IPv6";} /*Supported by XFRM*/ 1277 enum hao {description "Home Agent Option";} /*Supported by XFRM*/ 1278 } 1279 description "type define of ipsec security protocol"; 1280 } 1282 typedef ipsec-spi { 1284 type uint32 { range "1..max"; } 1285 description "SPI"; 1286 } 1288 typedef lifetime-action { 1289 type enumeration { 1290 enum terminate {description "Terminate the IPsec SA";} 1291 enum replace {description "Replace the IPsec SA with a new one";} 1292 } 1293 description "Action when lifetime expiration"; 1294 } 1296 typedef ipsec-traffic-direction { 1298 type enumeration { 1299 enum INBOUND { description "Inbound traffic"; } 1300 enum OUTBOUND { description "Outbound traffic"; } 1301 enum FORWARD{ description "Forwarded traffic"; } 1302 } 1303 description "IPsec traffic direction"; 1304 } 1306 typedef ipsec-spd-operation { 1308 type enumeration { 1309 enum PROTECT { description "PROTECT the traffic with IPsec"; } 1310 enum BYPASS { description "BYPASS the traffic"; } 1311 enum DISCARD { description "DISCARD the traffic"; } 1312 } 1313 description "The operation when traffic matches IPsec security policy"; 1314 } 1316 typedef ipsec-next-layer-proto { 1318 type enumeration { 1319 enum TCP { description "PROTECT the traffic with IPsec"; } 1320 enum UDP { description "BYPASS the traffic"; } 1321 enum SCTP { description "PROTECT the traffic with IPsec";} 1322 enum DCCP { description "PROTECT the traffic with IPsec";} 1323 enum ICMP { description "PROTECT the traffic with IPsec";} 1324 enum IPv6-ICMP { description "PROTECT the traffic with IPsec";} 1325 enum MH {description "PROTECT the traffic with IPsec";} 1326 enum GRE {description "PROTECT the traffic with IPsec";} 1327 } 1328 description "Next layer proto on top of IP"; 1329 } 1331 typedef ipsec-spd-name { 1333 type enumeration { 1334 enum id_rfc_822_addr { 1335 description "Fully qualified user name string."; 1336 } 1337 enum id_fqdn { 1338 description "Fully qualified DNS name."; 1339 } 1340 enum id_der_asn1_dn { 1341 description "X.500 distinguished name."; 1342 } 1343 enum id_key { 1344 description "IKEv2 Key ID."; 1345 } 1346 } 1347 description "IPsec SPD name type"; 1348 } 1350 typedef auth-method-type { 1351 /* Most implementations also provide XAUTH protocol, others used are: BLISS, P12, NTLM, PIN */ 1353 type enumeration { 1354 enum pre-shared { 1355 description "Select pre-shared key message as the authentication method"; 1356 } 1357 enum rsa-signature { 1358 description "Select rsa digital signature as the authentication method"; 1359 } 1360 enum dss-signature { 1361 description "Select dss digital signature as the authentication method"; 1362 } 1363 enum eap { 1364 description "Select EAP as the authentication method"; 1365 } 1366 } 1367 description "Peer authentication method"; 1368 } 1370 /*################## PAD grouping ####################*/ 1372 grouping auth-method-grouping { 1373 description "Peer authentication method data"; 1375 container auth-method { 1376 description "Peer authentication method container"; 1378 leaf auth-m { 1379 type auth-method-type; 1380 description "Type of authentication method (preshared, rsa, etc.)"; 1381 } 1382 container pre-shared { 1383 when "../auth-m = 'pre-shared'"; 1384 leaf secret { type string; description "Pre-shared secret value";} 1385 description "Shared secret value"; 1386 } 1388 container rsa-signature { 1389 when "../auth-m = 'rsa-signature'"; 1390 leaf key-data { 1391 type string; 1392 description "RSA private key data - PEM"; 1393 } 1395 leaf key-file { 1396 type string; 1397 description "RSA private key file name "; 1398 } 1400 leaf-list ca-data { 1401 type string; 1402 description "List of trusted CA certs - PEM"; 1403 } 1404 leaf ca-file { 1405 type string; 1406 description "List of trusted CA certs file"; 1407 } 1408 leaf cert-data { 1409 type string; 1410 description "X.509 certificate data - PEM4"; 1411 } 1412 leaf cert-file { 1413 type string; 1414 description "X.509 certificate file"; 1415 } 1416 leaf crl-data { 1417 type string; 1418 description "X.509 CRL certificate data in base64"; 1419 } 1420 leaf crl-file { 1421 type string; 1422 description " X.509 CRL certificate file"; 1423 } 1424 description "RSA signature container"; 1425 } 1426 } 1427 } 1429 grouping identity-grouping { 1430 description "Identification type. It is an union identity"; 1431 choice identity { 1432 description "Choice of identity."; 1434 leaf ipv4-address { 1435 type inet:ipv4-address; 1436 description "Specifies the identity as a single four (4) octet IPv4 address. An example is, 10.10.10.10. "; 1437 } 1438 leaf ipv6-address { 1439 type inet:ipv6-address; 1440 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 ."; 1441 } 1442 leaf fqdn-string { 1443 type inet:domain-name; 1444 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.)."; 1445 } 1446 leaf rfc822-address-string { 1447 type string; 1448 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.)."; 1449 } 1450 leaf dnX509 { 1451 type string; 1452 description "Specifies the identity as a distinguished name in the X.509 tradition."; 1453 } 1454 leaf id_key { 1455 type string; 1456 description "Key id"; 1457 } /* From RFC4301 list of id types */ 1458 } 1459 } /* grouping identity-grouping */ 1461 /*################ end PAD grouping ##################*/ 1463 /*################## SAD and SPD grouping ####################*/ 1465 grouping ip-addr-range { 1466 description "IP address range grouping"; 1467 leaf start { 1468 type inet:ip-address; 1469 description "Start IP address"; 1470 } 1471 leaf end { 1472 type inet:ip-address; 1473 description "End IP address"; 1474 } 1475 } 1477 grouping port-range { 1478 description "Port range grouping"; 1479 leaf start { 1480 type inet:port-number; 1481 description "Start IP address"; 1482 } 1483 leaf end { 1484 type inet:port-number; 1485 description "End IP address"; 1486 } 1487 } 1489 grouping tunnel-grouping { 1490 description "Tunnel mode grouping"; 1491 leaf local{ type inet:ip-address; description "Local tunnel endpoint"; } 1492 leaf remote{ type inet:ip-address; description "Remote tunnel enpoint"; } 1493 leaf bypass-df { type boolean; description "bypass DF bit"; } 1494 leaf bypass-dscp { type boolean; description "bypass DSCP"; } 1495 leaf dscp-mapping { type yang:hex-string; description "DSCP mapping"; } 1496 leaf ecn { type boolean; description "Bit ECN"; } /* RFC 4301 ASN1 notation. Annex C*/ 1497 } 1499 grouping selector-grouping { 1500 description "Traffic selector grouping"; 1501 list local-addresses { 1502 key "start end"; 1503 uses ip-addr-range; 1504 description "List of local addresses"; 1505 } 1506 list remote-addresses { 1507 key "start end"; 1508 uses ip-addr-range; 1509 description "List of remote addresses"; 1510 } 1511 leaf-list next-layer-protocol { type ipsec-next-layer-proto; description "List of Next Layer Protocol";} 1512 list local-ports { 1513 key "start end"; 1514 uses port-range; 1515 description "List of local ports"; 1516 } 1518 list remote-ports { 1519 key "start end"; 1520 uses port-range; 1521 description "List of remote ports"; 1522 } 1523 } 1525 /*################## SAD grouping ####################*/ 1526 grouping ipsec-sa-grouping { 1527 description "Configure Security Association (SA). Section 4.4.2.1 in RFC 4301"; 1529 leaf spi { type ipsec-spi; description "Security Parameter Index";} 1530 leaf seq-number { type uint64; description "Current sequence number of IPsec packet."; } 1531 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."; } 1532 leaf anti-replay-window { type uint16 { range "0 | 32..1024"; } description "Anti replay window"; } 1533 leaf rule-number {type uint32; description "This value links the SA with the SPD entry";} 1535 uses selector-grouping; 1537 leaf security-protocol { type ipsec-protocol; description "Security protocol of IPsec SA: Either AH or ESP."; } 1539 container ah-sa { 1540 when "../security-protocol = 'ah'"; 1541 description "Configure Authentication Header (AH) for SA"; 1542 container integrity { 1543 description "Configure integrity for IPSec Authentication Header (AH)"; 1544 leaf integrity-algorithm { type integrity-algorithm-t; description "Configure Authentication Header (AH)."; } 1545 leaf key { type string; description "AH key value";} 1546 } 1547 } 1549 container esp-sa { 1550 when "../security-protocol = 'esp'"; 1551 description "Set IPSec Encapsulation Security Payload (ESP)"; 1553 container encryption { 1554 description "Configure encryption for IPSec Encapsulation Secutiry Payload (ESP)"; 1555 leaf encryption-algorithm { type encryption-algorithm-t; description "Configure ESP encryption"; } 1556 leaf key { type string; description "ESP encryption key value";} 1557 leaf iv {type string; description "ESP encryption IV value"; } 1558 } 1560 container integrity { 1561 description "Configure authentication for IPSec Encapsulation Secutiry Payload (ESP)"; 1562 leaf integrity-algorithm { type integrity-algorithm-t; description "Configure Authentication Header (AH)."; } 1563 leaf key { type string; description "ESP integrity key value";} 1564 } 1565 leaf combined-enc-intr { type boolean; description "ESP combined mode algorithms. The algorithm is specified in encryption-algorithm in the container encryption";} 1566 } 1568 container sa-lifetime { 1569 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"; 1570 leaf time-soft { type uint32; default 0; description "Soft time lifetime";} 1571 leaf time-hard { type uint32; default 0; description "Hard time lifetime"; } 1572 leaf time-use-soft { type uint32; default 0; description "Use Soft time lifetime";} 1573 leaf time-use-hard { type uint32; default 0; description "Use Hard time lifetime";} 1574 leaf byte-soft { type uint32; default 0;description "Byte soft lifetime"; } 1575 leaf byte-hard { type uint32; default 0; description "Byte hard lifetime";} 1576 leaf packet-soft {type uint32; default 0; description "Packet soft lifetime";} 1577 leaf packet-hard { type uint32; default 0; description "Packet hard lifetime";} 1578 leaf action {type lifetime-action; description "action lifetime";} 1579 } 1581 leaf mode { type ipsec-mode; description "SA Mode"; } 1582 leaf statefulfragCheck { type boolean; description "TRUE stateful fragment checking, FALSE no stateful fragment checking"; } 1583 leaf dscp { type yang:hex-string; description "DSCP value"; } 1585 container tunnel { 1586 when "../mode = 'TUNNEL'"; 1587 uses tunnel-grouping; 1588 description "Container for tunnel grouping"; 1589 } 1591 leaf path-mtu { type uint16; description "Maximum size of an IPsec packet that can be transmitted without fragmentation"; } 1593 container encap { /* This is defined by XFRM */ 1594 description "Encapsulation container"; 1595 leaf espencap { type esp-encap; description "ESP in TCP, ESP in UDP or ESP in TLS";} 1596 leaf sport {type inet:port-number; description "Encapsulation source port";} 1597 leaf dport {type inet:port-number; description "Encapsulation destination port"; } 1598 leaf oaddr {type inet:ip-address; description "Encapsulation Original Address ";} 1599 } 1601 } 1603 /*################## end SAD grouping ##################*/ 1605 /*################## SPD grouping ####################*/ 1607 grouping ipsec-policy-grouping { 1608 description "Holds configuration information for an IPSec SPD entry."; 1610 leaf rule-number { 1611 type uint64; 1612 description "SPD index. RFC4301 does not mention an index however real implementations provide a policy index/or id to refer a policy. "; 1613 } 1614 leaf priority {type uint32; default 0; description "Policy priority";} 1615 list names { 1616 key "name"; 1617 leaf name-type { 1618 type ipsec-spd-name; 1619 description "SPD name type."; 1620 } 1621 leaf name { 1622 type string; description "Policy name"; 1623 } 1624 description "List of policy names"; 1625 } 1627 container condition { 1628 description "SPD condition -> RFC4301"; 1630 list traffic-selector-list { 1632 key "ts-number"; 1634 leaf ts-number { type uint32; description "Traffic selector number"; } 1635 leaf direction { type ipsec-traffic-direction; description "in/fwd/out"; } 1637 uses selector-grouping; 1638 leaf selector-priority {type uint32; default 0; description "It establishes a priority to the traffic selector";} 1639 ordered-by user; 1641 description "List of traffic selectors"; 1642 } 1643 } 1645 container processing-info { 1646 description "SPD processing -> RFC4301"; 1647 leaf action{ type ipsec-spd-operation; mandatory true; description "If the action is bypass or discard processing container ipsec-sa-cfg is empty";} 1649 container ipsec-sa-cfg { 1650 when "../action = 'PROTECT'"; 1652 leaf pfp-flag { type boolean; description "Each selector has with a pfp flag."; } 1653 leaf extSeqNum { type boolean; description "TRUE 64 bit counter, FALSE 32 bit"; } 1654 leaf seqOverflow { type boolean; description "TRUE rekey, FALSE terminare & audit"; } 1655 leaf statefulfragCheck { type boolean; description "TRUE stateful fragment checking, FALSE no stateful fragment checking"; } 1656 leaf security-protocol { type ipsec-protocol; description "Security protocol of IPsec SA: Either AH or ESP."; } 1657 leaf mode { type ipsec-mode; description "transport/tunnel"; } 1659 container ah-algorithms { 1660 when "../security-protocol = 'ah'"; 1661 leaf-list ah-algorithm { 1662 type integrity-algorithm-t; 1663 description "Configure Authentication Header (AH)."; 1664 } 1665 description "AH algoritms "; 1666 } 1668 container esp-algorithms { 1669 when "../security-protocol = 'esp'"; 1670 description "Configure Encapsulating Security Payload (ESP)."; 1671 leaf-list authentication { type integrity-algorithm-t; description "Configure ESP authentication"; } 1672 leaf-list encryption { type encryption-algorithm-t; description "Configure ESP encryption"; } 1673 } 1675 container tunnel { 1676 when "../mode = 'TUNNEL'"; 1677 uses tunnel-grouping; 1678 description "tunnel grouping container"; 1679 } 1680 description " IPSec SA configuration container"; 1681 } 1682 } 1684 container spd-lifetime { 1685 description "SPD lifetime parameters"; 1686 leaf time-soft { type uint32; default 0; description "Soft time lifetime";} 1687 leaf time-hard { type uint32; default 0; description "Hard time lifetime";} 1688 leaf time-use-soft { type uint32; default 0; description "Use soft lifetime";} 1689 leaf time-use-hard { type uint32; default 0; description "Use hard lifetime";} 1690 leaf byte-soft { type uint32; default 0; description "Byte soft lifetime";} 1691 leaf byte-hard { type uint32; default 0; description "Hard soft lifetime";} 1692 leaf packet-soft {type uint32; default 0; description "Packet soft lifetime";} 1693 leaf packet-hard { type uint32; default 0; description "Packet hard lifetime";} 1694 } 1695 }/* grouping ipsec-policy-grouping */ 1697 /*################ end SPD grouping ##################*/ 1699 /*################## IKEv2-grouping ##################*/ 1701 grouping isakmp-proposal { 1702 description "ISAKMP proposal grouping"; 1703 leaf phase1-lifetime { 1704 type uint32; 1705 mandatory true; 1706 description "lifetime for IKE Phase 1 SAs"; 1707 } 1708 leaf-list phase1-authalg { 1709 type integrity-algorithm-t; 1710 description "Auth algorigthm for IKE Phase 1 SAs"; 1711 } 1712 leaf-list phase1-encalg { 1713 type encryption-algorithm-t; 1714 description "Auth algorigthm for IKE Phase 1 SAs"; 1715 } 1717 leaf combined-enc-intr { type boolean; description "Combined mode algorithms (encryption and integrity).";} 1719 leaf dh_group { 1720 type uint32; 1721 mandatory true; 1722 description "Group number for Diffie Hellman Exponentiation"; 1723 } 1724 } /* list isakmp-proposal */ 1726 grouping phase2-info { 1727 description "IKE Phase 2 Information"; 1729 leaf-list pfs_group { 1730 type uint32; 1731 description 1732 "If non-zero, require perfect forward secrecy 1733 when requesting new SA. The non-zero value is 1734 the required group number"; 1735 } 1737 } 1739 grouping local-grouping { 1740 description "Configure the local peer in an IKE connection"; 1742 container local { 1743 description "Local container"; 1744 choice my-identifier-type { 1745 default ipv4; 1746 case ipv4 { 1747 leaf ipv4 { 1748 type inet:ipv4-address; 1749 description "IPv4 dotted-decimal address"; 1750 } 1751 } 1752 case ipv6 { 1753 leaf ipv6 { 1754 type inet:ipv6-address; 1755 description "numerical IPv6 address"; 1756 } 1757 } 1758 case fqdn { 1759 leaf fqdn { 1760 type inet:domain-name; 1761 description "Fully Qualifed Domain name "; 1762 } 1763 } 1764 case dn { 1765 leaf dn { 1766 type string; 1767 description "Domain name"; 1768 } 1769 } 1770 case user_fqdn { 1771 leaf user_fqdn { 1772 type string; 1773 description "User FQDN"; 1774 } 1775 } 1776 description "Local ID type"; 1777 } 1778 leaf my-identifier { 1779 type string; 1780 mandatory true; 1781 description "Local id used for authentication"; 1782 } 1783 } 1784 } 1786 grouping remote-grouping { 1787 description "Configure the remote peer in an IKE connection"; 1788 container remote { 1789 description "Remote container"; 1790 choice my-identifier-type { 1791 default ipv4; 1792 case ipv4 { 1793 leaf ipv4 { 1794 type inet:ipv4-address; 1795 description "IPv4 dotted-decimal address"; 1796 } 1797 } 1798 case ipv6 { 1799 leaf ipv6 { 1800 type inet:ipv6-address; 1801 description "numerical IPv6 address"; 1802 } 1803 } 1804 case fqdn { 1805 leaf fqdn { 1806 type inet:domain-name; 1807 description "Fully Qualifed Domain name "; 1808 } 1809 } 1810 case dn { 1811 leaf dn { 1812 type string; 1813 description "Domain name"; 1814 } 1815 } 1816 case user_fqdn { 1817 leaf user_fqdn { 1818 type string; 1819 description "User FQDN"; 1820 } 1821 } 1822 description "Local ID type"; 1823 } 1824 leaf my-identifier { 1825 type string; 1826 mandatory true; 1827 description "Local id used for authentication"; 1828 } 1829 } 1830 } 1832 /*################## End IKEv2-groupingUMU ##################*/ 1834 /*################# Register grouping #################*/ 1836 typedef sadb-msg-type { 1838 type enumeration { 1839 enum sadb_reserved { description "SADB_RESERVED";} 1840 enum sadb_getspi { description "SADB_GETSPI";} 1841 enum sadb_update { description "SADB_UPDATE";} 1842 enum sadb_add { description "SADB_ADD";} 1843 enum sadb_delete { description "SADB_DELETE"; } 1844 enum sadb_get { description "SADB_GET"; } 1845 enum sadb_acquire { description "SADB_ACQUIRE"; } 1846 enum sadb_register { description "SADB_REGISTER"; } 1847 enum sadb_expire { description "SADB_EXPIRE"; } 1848 enum sadb_flush { description "SADB_FLUSH"; } 1849 enum sadb_dump { description "SADB_DUMP"; } 1850 enum sadb_x_promisc { description "SADB_X_PROMISC"; } 1851 enum sadb_x_pchange { description "SADB_X_PCHANGE"; } 1852 enum sadb_max{ description "SADB_MAX"; } 1853 } 1854 description "PF_KEY base message types"; 1855 } 1857 typedef sadb-msg-satype { 1859 type enumeration { 1860 enum sadb_satype_unspec { description "SADB_SATYPE_UNSPEC"; } 1861 enum sadb_satype_ah { description "SADB_SATYPE_AH"; } 1862 enum sadb_satype_esp { description "SADB_SATYPE_ESP"; } 1863 enum sadb_satype_rsvp { description "SADB_SATYPE_RSVP"; } 1864 enum sadb_satype_ospfv2 { description "SADB_SATYPE_OSPFv2"; } 1865 enum sadb_satype_ripv2 { description "SADB_SATYPE_RIPv2"; } 1866 enum sadb_satype_mip { description "SADB_SATYPE_MIP"; } 1867 enum sadb_satype_max { description "SADB_SATYPE_MAX"; } 1868 } 1869 description "PF_KEY Security Association types"; 1870 } 1872 grouping base-grouping { 1873 description "Configuration for the message header format"; 1874 list base-list { 1875 key "version"; 1876 leaf version { type string; description "Version of PF_KEY (MUST be PF_KEY_V2)"; } 1877 leaf msg_type { type sadb-msg-type; description "Identifies the type of message"; } 1878 leaf msg_satype { type sadb-msg-satype; description "Defines the type of Security Association"; } 1879 leaf msg_seq { type uint32; description "Sequence number of this message."; } 1880 description "Configuration for a specific message header format"; 1881 } 1882 } 1884 grouping algorithm-grouping { 1885 description "List of supported authentication and encryptation algorithms"; 1886 list algorithm-supported{ 1887 container authentication { 1888 description "Authentication algorithm supported"; 1889 leaf name { type integrity-algorithm-t; description "Name of authentication algorithm"; } 1890 leaf ivlen { type uint8; description "Length of the initialization vector to be used for the algorithm"; } 1891 leaf min-bits { type uint16; description "The minimun acceptable key length, in bits"; } 1892 leaf max-bits { type uint16; description "The maximun acceptable key length, in bits"; } 1893 } 1894 container encryption { 1895 description "Encryptation algorithm supported"; 1896 leaf name { type encryption-algorithm-t; description "Name of encryption algorithm"; } 1897 leaf ivlen { type uint8; description "Length of the initialization vector to be used for the algorithm"; } 1898 leaf min-bits { type uint16; description "The minimun acceptable key length, in bits"; } 1899 leaf max-bits { type uint16; description "The maximun acceptable key length, in bits"; } 1900 } 1901 description "List for a specific algorithm"; 1902 } 1903 } 1905 /*################# End Register grouping #################*/ 1907 /*################## ipsec ##################*/ 1909 container ietf-ipsec { 1910 description "Main IPsec container "; 1912 container ikev2 { 1913 if-feature case1; 1914 description "Configure the IKEv2"; 1916 container ike-connection { 1917 description "IKE connections configuration"; 1919 list ike-conn-entries { 1920 key "conn-name"; 1921 description "IKE peer connetion information"; 1922 leaf conn-name { 1923 type string; 1924 mandatory true; 1925 description "Name of IKE connection"; 1926 } 1927 leaf autostartup { 1928 type type-autostartup; 1929 mandatory true; 1930 description "if True: automatically start tunnel at startup; else we do lazy tunnel setup based on trigger from datapath"; 1931 } 1932 leaf nat-traversal { 1933 type boolean; 1934 default false; 1935 description "Enable/Disable NAT traversal"; 1936 } 1938 container encap { 1939 when "../nat-traversal = 'true'"; 1940 description "Encapsulation container"; 1941 leaf espencap { type esp-encap; description "ESP in TCP, ESP in UDP or ESP in TLS";} 1942 leaf sport {type inet:port-number; description "Encapsulation source port";} 1943 leaf dport {type inet:port-number; description "Encapsulation destination port"; } 1944 leaf oaddr {type inet:ip-address; description "Encapsulation Original Address ";} 1945 } 1947 leaf version { 1948 type enumeration { 1949 /* we only support ikev2 in this version */ 1950 enum ikev2 {value 2; description "IKE version 2";} 1951 } 1952 description "IKE version"; 1953 } 1955 uses isakmp-proposal; 1956 uses local-grouping; 1957 uses remote-grouping; 1958 uses phase2-info; 1960 } /* ike-conn-entries */ 1961 } /* container ike-connection */ 1962 } /* container ikev2 */ 1964 container ipsec { 1965 description "Configuration IPsec"; 1967 container spd { 1968 description "Configure the Security Policy Database (SPD)"; 1969 list spd-entry { 1970 key "rule-number"; 1971 uses ipsec-policy-grouping; 1972 ordered-by user; 1973 description "List of SPD entries"; 1974 } 1975 } 1977 container sad { 1978 if-feature case2; 1979 description "Configure the IPSec Security Association Database (SAD)"; 1980 list sad-entry { 1981 key "spi"; 1982 uses ipsec-sa-grouping; 1983 description "List of SAD entries"; 1984 } 1985 } 1987 container pad { 1988 if-feature case1; 1989 description "Configure Peer Authorization Database (PAD)"; 1990 list pad-entries { 1991 key "pad-entry-id"; 1992 ordered-by user; 1993 description "Peer Authorization Database (PAD)"; 1995 leaf pad-entry-id { 1996 type uint64; 1997 description "SAD index. "; 1998 } 2000 uses identity-grouping; 2002 leaf pad-auth-protocol { 2003 type auth-protocol-type; 2004 description "IKEv1, IKEv2, KINK, etc. "; 2005 } 2006 uses auth-method-grouping; 2007 } 2008 } 2009 } 2011 } /* container ietf-ipsec */ 2013 /*########## State Data ############*/ 2015 // TBD 2017 /*################## RPC and Notifications ##################*/ 2019 /* Note: not yet completed */ 2020 // Those RPCs are needed by a Security Controller in case 2 */ 2022 rpc sadb_register { 2023 description "Allows netconf to register its key socket as able to acquire new security associations for the kernel"; 2024 input { 2025 uses base-grouping; 2026 } 2027 output { 2028 uses base-grouping; 2029 uses algorithm-grouping; 2030 } 2031 } 2033 notification spdb_expire { 2034 description "A SPD entry has expired"; 2035 leaf index { 2036 type uint64; 2037 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. "; 2038 } 2039 } 2041 notification sadb_acquire { 2042 description "A IPsec SA is required "; 2043 leaf state { 2044 type uint32; 2045 mandatory "true"; 2046 description 2047 "Request the creation of a SADB entry"; 2048 } 2049 } 2051 notification sadb_expire { 2052 description "....."; 2053 leaf state { 2054 type uint32; 2055 mandatory "true"; 2056 description 2057 "Notify the expiration of a entry in the SADB"; 2058 } 2059 } 2061 notification sadb_bad-spi { 2062 description "....."; 2063 leaf state { 2064 type ipsec-spi; 2065 mandatory "true"; 2066 description "Notify when a SPI"; 2067 } 2069 } 2071 } /*module ietf-ipsec*/ 2073 2075 Authors' Addresses 2077 Rafa Marin-Lopez 2078 University of Murcia 2079 Campus de Espinardo S/N, Faculty of Computer Science 2080 Murcia 30100 2081 Spain 2083 Phone: +34 868 88 85 01 2084 EMail: rafa@um.es 2086 Gabriel Lopez-Millan 2087 University of Murcia 2088 Campus de Espinardo S/N, Faculty of Computer Science 2089 Murcia 30100 2090 Spain 2092 Phone: +34 868 88 85 04 2093 EMail: gabilm@um.es