idnits 2.17.1 draft-abad-i2nsf-sdn-ipsec-flow-protection-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 123 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 427 has weird spacing: '...w start ine...' == Line 430 has weird spacing: '...w start ine...' == Line 434 has weird spacing: '...w start ine...' == Line 437 has weird spacing: '...w start ine...' == Line 484 has weird spacing: '...w start ine...' == (10 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.)."; == 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 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 (May 4, 2017) is 2549 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC5226' is defined on line 930, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2nsf-framework' is defined on line 942, but no explicit reference was found in the text == Unused Reference: 'I-D.jeong-i2nsf-sdn-security-services-05' is defined on line 960, 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-04 == Outdated reference: A later version (-16) exists of draft-ietf-i2nsf-problem-and-use-cases-15 == Outdated reference: A later version (-08) exists of draft-ietf-i2nsf-terminology-03 -- No information found for draft-pfkey-spd - is the name correct? == Outdated reference: A later version (-07) exists of draft-sivakumar-yang-nat-06 Summary: 3 errors (**), 0 flaws (~~), 17 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2NSF R. Marin-Lopez 3 Internet-Draft G. Lopez-Millan 4 Intended status: Experimental University of Murcia 5 Expires: November 5, 2017 May 4, 2017 7 Software-Defined Networking (SDN)-based IPsec Flow Protection 8 draft-abad-i2nsf-sdn-ipsec-flow-protection-03 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 SDN 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 http://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 November 5, 2017. 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 (http://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 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 87 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 88 11.1. Normative References . . . . . . . . . . . . . . . . . . 21 89 11.2. Informative References . . . . . . . . . . . . . . . . . 22 90 Appendix A. Appendix A: YANG model IPsec Configuration data . . 25 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 93 1. Introduction 95 Software-Defined Networking (SDN) is an architecture that enables 96 users to directly program, orchestrate, control and manage network 97 resources through software. SDN paradigm relocates the control of 98 network resources to a dedicated network element, namely SDN 99 controller. The SDN controller manages and configures the 100 distributed network resources and provides an abstracted view of the 101 network resources to the SDN applications. The SDN application can 102 customize and automate the operations (including management) of the 103 abstracted network resources in a programmable manner via this 104 interface [RFC7149][ITU-T.Y.3300] 105 [ONF-SDN-Architecture][ONF-OpenFlow]. 107 Typically, traditional IPsec VPN concentrators and, in general, 108 entities (i.e. hosts or security gateways) supporting IKE/IPsec, must 109 be configured directly by the administrator. This makes the IPsec 110 security association (SA) management difficult and generates a lack 111 of flexibility, specially if the number of security policies and SAs 112 to handle is high. With the growth of SDN-based scenarios where 113 network resources are deployed in an autonomous manner, a mechanism 114 to manage IPsec SAs according to the SDN architecture becomes more 115 relevant. Thus, the SDN-based service described in this document 116 will autonomously deal with IPsec SAs management. 118 An example of usage can be the notion of Software Defined WAN (SD- 119 WAN), SDN extension providing a software abstraction to create secure 120 network overlays over traditional WAN and branch networks. SD-WAN is 121 based on IPsec as underlying security protocol and aims to provide 122 flexible, automated, fast deployment and on-demand security network 123 services. 125 IPsec architecture [RFC4301] defines a clear separation between the 126 processing to provide security services to IP packets and the key 127 management procedures to establish the IPsec security associations. 128 In this document, we define a service where the key management 129 procedures can be carried by an external entity: the Security 130 Controller. 132 First, this document exposes the requirements to support the 133 protection of data flows using IPsec [RFC4301]. We have considered 134 two general cases: 136 1) The Network Security Function (NSF) implements the Internet Key 137 Exchange (IKE) protocol and the IPsec databases: the Security 138 Policy Database (SPD), the Security Association Database (SAD) 139 and the Peer Authorization Database (PAD). The Security 140 Controller is in charge of provisioning the NSF with the required 141 information to IKE, the SPD and the PAD. 143 2) The NSF only implements the IPsec databases (no IKE 144 implementation). The Security Controller will provide the 145 required parameters to create valid entries in the SPD and the 146 SAD into the NSF. Therefore, the NSF will have only support for 147 IPsec while automated key management functionality is moved to 148 the controller. 150 In both cases, an interface/protocol is required to carry out this 151 provisioning between the Security Controller and the NSF. In 152 particular, Case 1 requires the provision of SPD and PAD entries and 153 the IKE credential and information related with the IKE negotiation 154 (e.g. IKE_SA_INIT); and Case 2 requires the management of SPD and 155 SAD entries. Based on YANG models in [netconf-vpn] and 156 [I-D.tran-ipsecme-yang], RFC 4301 [RFC4301] and RFC 7296 [RFC7296] 157 this document defines the required interfaces with a YANG model for 158 configuration data for IKE, PAD, SPD and SAD Appendix A . State data 159 is TBD. 161 This document considers two typical scenarios to manage autonomously 162 IPsec SAs: gateway-to-gateway and host-to-host [RFC6071]. The 163 analysis of the host-to-gateway (roadwarrior) scenario is TBD. In 164 these cases, host or gateways or both may act as NSFs. Finally, it 165 also discusses the situation where two NSFs are under the control of 166 two different Security Controllers. 168 NOTE: This work pays attention to the challenge "Lack of Mechanism 169 for Dynamic Key Distribution to NSFs" defined in 170 [I-D.ietf-i2nsf-problem-and-use-cases] in the particular case of the 171 establishment and management of IPsec SAs. In fact, this I-D could 172 be considered as a proper use case for this particular challenge in 173 [I-D.ietf-i2nsf-problem-and-use-cases]. 175 2. Requirements Language 177 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 178 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 179 document are to be interpreted as described in RFC 2119 [RFC2119]. 180 When these words appear in lower case, they have their natural 181 language meaning. 183 3. Terminology 185 This document uses the terminology described in [RFC7149], [RFC4301], 186 [ITU-T.Y.3300], [ONF-SDN-Architecture], [ONF-OpenFlow], 188 [ITU-T.X.1252], [ITU-T.X.800] and [I-D.ietf-i2nsf-terminology]. In 189 addition, the following terms are defined below: 191 o Software-Defined Networking. A set of techniques enabling to 192 directly program, orchestrate, control, and manage network 193 resources, which facilitates the design, delivery and operation of 194 network services in a dynamic and scalable manner [ITU-T.Y.3300]. 196 o Flow/Data Flow. Set of network packets sharing a set of 197 characteristics, for example IP dst/src values or QoS parameters. 199 o Security Controller. A Controller is a management Component that 200 contains control plane functions to manage and facilitate 201 information sharing, as well as execute security functions. In 202 the context of this document, it provides IPsec management 203 information. 205 o Network Security Function (NSF). Software that provides a set of 206 security-related services. 208 o Flow-based NSF. A NSF that inspects network flows according to a 209 set of policies intended for enforcing security properties. The 210 NSFs considered in this document falls into this classification. 212 o Flow-based Protection Policy. The set of rules defining the 213 conditions under which a data flow MUST be protected with IPsec, 214 and the rules that MUST be applied to the specific flow. 216 o Internet Key Exchange (IKE) v2 Protocol to establish IPsec 217 Security Associations (SAs). It requires information about the 218 required authentication method (i.e. preshared keys), DH groups, 219 modes and algorithms for IKE SA negotiation, etc. 221 o Security Policy Database (SPD). It includes information about 222 IPsec policies direction (in, out), local and remote addresses, 223 inbound and outboud SAs, etc. 225 o Security Associations Database (SAD). It includes information 226 about IPsec SAs, such as SPI, destination addresses, 227 authentication and encryption algorithms and keys to protect IP 228 flow. 230 o Peer Authorization Database (PAD). It provides the link between 231 the SPD and a security association management protocol such as IKE 232 or our SDN-based solution. 234 4. Objectives 236 o To describe the architecture for the SDN-based IPsec management, 237 which implements a security service to allow the establishment and 238 management of IPsec security associations from a central point to 239 protect specific data flows. 241 o To define the interfaces required to manage and monitor the IPsec 242 Security Associations in the NSF from a Security Controller. YANG 243 models are defined for configuration and state data for IPsec 244 management. 246 5. SDN-based IPsec management description 248 As mentioned in Section 1, two cases are considered: 250 5.1. Case 1: IKE/IPsec in the NSF 252 In this case the NSF ships an IKE implementation besides the IPsec 253 support. The Security Controller is in charge of managing and 254 applying SPD and PAD entries (deriving and delivering IKE Credentials 255 such as a pre-shared key, certificates, etc.), and applying other IKE 256 configuration parameters (e.g. IKE_SA_INIT algorithms) to the NSF 257 for the IKE negotiation. 259 With these entries, the IKE implementation can operate to establish 260 the IPsec SAs. The application (administrator) establishes the IPsec 261 requirements and information about the end points information 262 (through the Client Facing Interface), and the Security Controller 263 translates those requirements into SPD and PAD entries that will be 264 installed into the NSF (through the NSF Facing Interface). With that 265 information, the NSF can just run IKE to establish the required IPsec 266 SA (when the data flow needs protection). Figure 1 shows the 267 different layers and corresponding functionality. 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | IPsec Management/Orchestration Application| Client or 271 | I2NSF Client | App Gateway 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | Client Facing Interface 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 Vendor | Application Support | 276 Facing <--->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Security 277 Interface | IKE Credential, PAD and SPD entries Distr. | Controller 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | NSF Facing Interface 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | I2NSF Agent | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Network 283 | IKE | IPsec(SPD,SPD,PAD) | Security 284 +-------------------------------------------- + Function (NSF) 285 | Data Protection and Forwarding | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 Figure 1: Case 1: IKE/IPsec in the NSF 290 5.1.1. Interface Requirements for Case 1 292 SDN-based IPsec flow protection services provide dynamic and flexible 293 management of IPsec SAs in flow-based NSF. In order to support this 294 capability in case 1, the following interface requirements are to be 295 met: 297 o A YANG data model for Configuration data for IKE, SPD and PAD. 299 o A YANG data model for State data for IKE, SPD, PAD and SAD (Note 300 that SAD entries are created in runtime by IKE.) 302 o In scenarios where multiple controllers are implicated, SDN-based 303 IPsec management services may require a mechanism to discover 304 which Security Controller is managing a specific NSF. Moreover, 305 an east-west interface is required to exchange IPsec-related 306 information. 308 5.2. Case 2: IPsec (no IKE) in the NSF 310 In this case the NSF does not deploy IKE and, therefore, the Security 311 Controller has to perform the management of IPsec SAs by populating 312 and monitoring the SPD and the SAD. 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | IPsec Management/Orchestration Application| Client or 316 | I2NSF Client | App Gateway 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Client Facing Interface 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 Vendor | Application Support | 321 Facing <--->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Security 322 Interface | SPD, SAD and PAD Entries Distr. | Controller 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | NSF Facing Interface 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | I2NSF Agent | Network 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Security 328 | IPsec (SPD,SAD) | Function (NSF) 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Data Protection and Forwarding | 331 +---------------------------------------------+ 333 Figure 2: Case 2: IPsec (no IKE) in the NSF 335 As shown in Figure 2, applications for flow protection run on the top 336 of the Security Controller. When an administrator enforces flow- 337 based protection policies through the Client Facing Interface, the 338 Security Controller translates those requirements into SPD and SAD 339 entries, which are installed in the NSF. PAD entries are not 340 required since there is no IKE in the NSF. 342 5.2.1. Interface Requirements for Case 2 344 In order to support case 2, the following requirements are to be met: 346 o A YANG data model for Configuration data for SPD and SAD. 348 o A YANG data model for State data for SPD and SAD. 350 o In scenarios where multiple controllers are implicated, SDN-based 351 IPsec management services may require a mechanism to discover 352 which Security Controller is managing a specific NSF. Moreover, 353 an east-west interface is required to exchange IPsec-related 354 information. 356 5.3. Case 1 vs Case 2 358 Case 1 MAY be easier to deploy than Case 2 because current gateways 359 typically have an IKE/IPsec implementation. Moreover hosts can 360 install easily an IKE implemention. As downside, the NSF needs more 361 resources to hold IKE. Moreover, the IKE implementation needs to 362 implement an interface so that the I2NSF Agent can interact with 363 them. 365 Alternatively, Case 2 allows lighter NSFs (no IKE implementation), 366 which benefits the deployment in constrained NSFs. Moreover, IKE 367 does not need to be performed in gateway-to-gateway and host-to-host 368 scenarios under the same Security Controller (see Section 7.1). On 369 the contrary, the overload of creation of fresh IPsec SA is shifted 370 to the Security Controller since IKE is not in the NSF. As a 371 consequence, this may result in a more complex implementation in the 372 controller side. 374 For example, the Security Controller needs to supervise the IPsec SAs 375 states and take care of the rekeying process so that, after some 376 period of time (e.g. IPsec SA soft lifetime), it has to create a new 377 IPsec SA and remove the old one. Or the Security Controller needs to 378 process events coming from the I2NSF when for example an IPsec SA is 379 requested (e.g. acquire or expire events). Another example is the 380 NAT traversal support. In general, the SDN paradigm assumes the SDN 381 controller has a view of the network it controls. This view is built 382 either requesting information to the NSFs under its control or 383 because these NSFs inform the SDN controller. Based on this 384 information, the SDN/security controller can guess if there is a NAT 385 configured between two hosts, apply the required policies to both 386 NSFs besides activating the usage of UDP encapsulation of ESP packets 387 [RFC3948]. 389 In those scenarios, the Controller could directly request the NSF for 390 specific data such as networking configuration, NAT support, etc. 391 Protocols such as NETCONF or SNMP can be used here. For example, RFC 392 7317 [RFC7317] provides a YANG data model for system management or 393 [I-D.sivakumar-yang-nat] a data model for NAT management. 395 6. YANG configuration data models 397 In order to support case 1 and case 2 we have modelled the different 398 parameters and values that must be configured to manage IPsec SAs. 399 Specifically, case 1 requires modelling IKEv2, SPD and PAD while case 400 2 requires models for the SPD and SAD. A single YANG file represents 401 both cases though some part of the models are selectively activated 402 depending a feature defined in the YANG file. For example, the IKE 403 configuration is not enabled in case 2. 405 In the following, we summarize, by using a tree representation, the 406 different configuration data models (NOTE: State data models are TBD 407 though they are expected to be very similar to the model defined 408 here). The complete YANG configuration data model is in Appendix A 410 6.1. Security Policy Database (SPD) Model 412 The definition of this model has been extracted from the 413 specification in section 4.4.1 and Appendix D in [RFC4301] 415 +--rw spd 416 | +--rw spd-entry* [rule-number] 417 | +--rw rule-number uint64 418 | +--rw priority? uint32 419 | +--rw names* [name] 420 | | +--rw name-type? ipsec-spd-name 421 | | +--rw name string 422 | +--rw condition 423 | | +--rw traffic-selector-list* [ts-number] 424 | | +--rw ts-number uint32 425 | | +--rw direction? ipsec-traffic-direction 426 | | +--rw local-addresses* [start end] 427 | | | +--rw start inet:ip-address 428 | | | +--rw end inet:ip-address 429 | | +--rw remote-addresses* [start end] 430 | | | +--rw start inet:ip-address 431 | | | +--rw end inet:ip-address 432 | | +--rw next-layer-protocol* ipsec-next-layer-proto 433 | | +--rw local-ports* [start end] 434 | | | +--rw start inet:port-number 435 | | | +--rw end inet:port-number 436 | | +--rw remote-ports* [start end] 437 | | | +--rw start inet:port-number 438 | | | +--rw end inet:port-number 439 | | +--rw selector-priority? uint32 440 | +--rw processing-info 441 | | +--rw action ipsec-spd-operation 442 | | +--rw ipsec-sa-cfg 443 | | +--rw pfp-flag? boolean 444 | | +--rw extSeqNum? boolean 445 | | +--rw seqOverflow? boolean 446 | | +--rw statefulfragCheck? boolean 447 | | +--rw security-protocol? ipsec-protocol 448 | | +--rw mode? ipsec-mode 449 | | +--rw ah-algorithms 450 | | | +--rw ah-algorithm* integrity-algorithm-t 451 | | +--rw esp-algorithms 452 | | | +--rw authentication* integrity-algorithm-t 453 | | | +--rw encryption* encryption-algorithm-t 454 | | +--rw tunnel 455 | | +--rw local? inet:ip-address 456 | | +--rw remote? inet:ip-address 457 | | +--rw bypass-df? boolean 458 | | +--rw bypass-dscp? boolean 459 | | +--rw dscp-mapping? yang:hex-string 460 | | +--rw ecn? boolean 461 | +--rw spd-lifetime 462 | +--rw time-soft? uint32 463 | +--rw time-hard? uint32 464 | +--rw time-use-soft? uint32 465 | +--rw time-use-hard? uint32 466 | +--rw byte-soft? uint32 467 | +--rw byte-hard? uint32 468 | +--rw packet-soft? uint32 469 | +--rw packet-hard? uint32 471 6.2. Security Association Database (SAD) Model 473 The definition of this model has been extracted from the 474 specification in section 4.4.2 in [RFC4301] 476 +--rw sad {case2}? 477 | +--rw sad-entry* [spi] 478 | +--rw spi ipsec-spi 479 | +--rw seq-number? uint64 480 | +--rw seq-number-overflow-flag? boolean 481 | +--rw anti-replay-window? uint16 482 | +--rw rule-number? uint32 483 | +--rw local-addresses* [start end] 484 | | +--rw start inet:ip-address 485 | | +--rw end inet:ip-address 486 | +--rw remote-addresses* [start end] 487 | | +--rw start inet:ip-address 488 | | +--rw end inet:ip-address 489 | +--rw next-layer-protocol* ipsec-next-layer-proto 490 | +--rw local-ports* [start end] 491 | | +--rw start inet:port-number 492 | | +--rw end inet:port-number 493 | +--rw remote-ports* [start end] 494 | | +--rw start inet:port-number 495 | | +--rw end inet:port-number 496 | +--rw security-protocol? ipsec-protocol 497 | +--rw ah-sa 498 | | +--rw integrity-algorithm? integrity-algorithm-t 499 | | +--rw key? string 500 | +--rw esp-sa 501 | | +--rw encryption 502 | | | +--rw encryption-algorithm? encryption-algorithm-t 503 | | | +--rw key? string 504 | | | +--rw iv? string 505 | | +--rw integrity 506 | | | +--rw integrity-algorithm? integrity-algorithm-t 507 | | | +--rw key? string 508 | | +--rw combined 509 | | +--rw combined-algorithm? combined-algorithm-t 510 | +--rw sa-lifetime 511 | | +--rw time-soft? uint32 512 | | +--rw time-hard? uint32 513 | | +--rw time-use-soft? uint32 514 | | +--rw time-use-hard? uint32 515 | | +--rw byte-soft? uint32 516 | | +--rw byte-hard? uint32 517 | | +--rw packet-soft? uint32 518 | | +--rw packet-hard? uint32 519 | | +--rw action? lifetime-action 520 | +--rw mode? ipsec-mode 521 | +--rw statefulfragCheck? boolean 522 | +--rw dscp? yang:hex-string 523 | +--rw tunnel 524 | | +--rw local? inet:ip-address 525 | | +--rw remote? inet:ip-address 526 | | +--rw bypass-df? boolean 527 | | +--rw bypass-dscp? boolean 528 | | +--rw dscp-mapping? yang:hex-string 529 | | +--rw ecn? boolean 530 | +--rw path-mtu? uint16 531 | +--rw encap 532 | +--rw espinudp? boolean 533 | +--rw sport? inet:port-number 534 | +--rw dport? inet:port-number 535 | +--rw oaddr? inet:ip-address 537 rpcs: 538 +---x sadb_register 539 +---w input 540 | +---w base-list* [version] 541 | +---w version string 542 | +---w msg_type? sadb-msg-type 543 | +---w msg_satype? sadb-msg-satype 544 | +---w msg_seq? uint32 545 +--ro output 546 +--ro base-list* [version] 547 | +--ro version string 548 | +--ro msg_type? sadb-msg-type 549 | +--ro msg_satype? sadb-msg-satype 550 | +--ro msg_seq? uint32 551 +--ro algorithm-supported* 552 +--ro authentication 553 | +--ro name? integrity-algorithm-t 554 | +--ro ivlen? uint8 555 | +--ro min-bits? uint16 556 | +--ro max-bits? uint16 557 +--ro encryption 558 +--ro name? encryption-algorithm-t 559 +--ro ivlen? uint8 560 +--ro min-bits? uint16 561 +--ro max-bits? uint16 563 notifications: 564 +---n spd-expire 565 | +--ro index? uint64 566 +---n sadb_acquire 567 | +--ro state uint32 568 +---n sadb_expire 569 +--ro state uint32 571 6.3. Peer Authorization Database (PAD) Model 573 The definition of this model has been extracted from the 574 specification in section 4.4.3 in [RFC4301] (NOTE: We have observed 575 that many implementations integrate PAD configuration as part of the 576 IKE configuration.) 577 +--rw pad {case1}? 578 +--rw pad-entries* [pad-entry-id] 579 +--rw pad-entry-id uint64 580 +--rw (identity)? 581 | +--:(ipv4-address) 582 | | +--rw ipv4-address? inet:ipv4-address 583 | +--:(ipv6-address) 584 | | +--rw ipv6-address? inet:ipv6-address 585 | +--:(fqdn-string) 586 | | +--rw fqdn-string? inet:domain-name 587 | +--:(rfc822-address-string) 588 | | +--rw rfc822-address-string? string 589 | +--:(dnX509) 590 | | +--rw dnX509? string 591 | +--:(id_key) 592 | +--rw id_key? string 593 +--rw pad-auth-protocol? auth-protocol-type 594 +--rw auth-method 595 +--rw auth-m? auth-method-type 596 +--rw pre-shared 597 | +--rw secret? string 598 +--rw rsa-signature 599 +--rw key-data? string 600 +--rw key-file? string 601 +--rw ca-data* string 602 +--rw ca-file? string 603 +--rw cert-data? string 604 +--rw cert-file? string 605 +--rw crl-data? string 606 +--rw crl-file? string 608 6.4. Internet Key Exchange (IKE) Model 610 The model related to IKEv2 has been extracted from reading IKEv2 611 standard in [RFC7296], and observing some open source 612 implementations, such as Strongswan or Libreswan. 614 +--rw ikev2 {case1}? 615 | +--rw ike-connection 616 | +--rw ike-conn-entries* [conn-name] 617 | +--rw conn-name string 618 | +--rw autostartup boolean 619 | +--rw nat-traversal? boolean 620 | +--rw version? enumeration 621 | +--rw phase1-lifetime uint32 622 | +--rw phase1-authby auth-method-type 623 | +--rw phase1-authalg* integrity-algorithm-t 624 | +--rw phase1-encalg* encryption-algorithm-t 625 | +--rw dh_group uint32 626 | +--rw local 627 | | +--rw (my-identifier-type)? 628 | | | +--:(ipv4) 629 | | | | +--rw ipv4? inet:ipv4-address 630 | | | +--:(ipv6) 631 | | | | +--rw ipv6? inet:ipv6-address 632 | | | +--:(fqdn) 633 | | | | +--rw fqdn? inet:domain-name 634 | | | +--:(dn) 635 | | | | +--rw dn? string 636 | | | +--:(user_fqdn) 637 | | | +--rw user_fqdn? string 638 | | +--rw my-identifier string 639 | +--rw remote 640 | | +--rw (my-identifier-type)? 641 | | | +--:(ipv4) 642 | | | | +--rw ipv4? inet:ipv4-address 643 | | | +--:(ipv6) 644 | | | | +--rw ipv6? inet:ipv6-address 645 | | | +--:(fqdn) 646 | | | | +--rw fqdn? inet:domain-name 647 | | | +--:(dn) 648 | | | | +--rw dn? string 649 | | | +--:(user_fqdn) 650 | | | +--rw user_fqdn? string 651 | | +--rw my-identifier string 652 | +--rw local-addrs inet:ip-address 653 | +--rw remote-addr inet:ip-address 654 | +--rw pfs_group? uint32 655 | +--rw phase2-lifetime uint32 656 | +--rw phase2-authalg* integrity-algorithm-t 657 | +--rw phase2-encalg* encryption-algorithm-t 659 7. Use cases examples 661 This section explains how different traditional configurations, that 662 is, host-to-host and gateway-to-gateway are deployed using our SDN- 663 based IPsec management service. In turn, these configurations will 664 be typical in modern networks where, for example, virtualization will 665 be key. 667 7.1. Host-to-Host or Gateway-to-gateway under the same controller 669 +----------------------------------------+ 670 | Security Controller | 671 | | 672 (1)| +--------------+ (2)+--------------+ | 673 Flow-based ------> |Translate into|--->| South. Prot. | | 674 Security. Pol. | |IPsec Policies| | | | 675 | +--------------+ +--------------+ | 676 | | | | 677 | | | | 678 +--------------------------|-----|-------+ 679 | | 680 | (3) | 681 |-------------------------+ +---| 682 V V 683 +----------------------+ +----------------------+ 684 | NSF1 |<=======>| NSF2 | 685 |IKE/IPsec(SPD/SAD/PAD)| |IKE/IPsec(SPD/SAD/PAD)| 686 +----------------------+ (4) +----------------------+ 688 Figure 3: Gateway-to-Gateway single controller flow for case 1 . 690 Figure 3 describes the case 1: 692 1. The administrator defines general flow-based security policies. 693 The controller looks for the NSFs involved (NSF1 and NSF2). 695 2. The controller generates IKE credentials for them and translates 696 the policies into SPD and PAD entries. 698 3. The controller inserts the SPD and PAD entries in both NSF1 and 699 NSF2. 701 4. The flow is protected with the IPsec SA established with IKEv2. 703 +----------------------------------------+ 704 | (1) Security Controller | 705 Flow-based | | 706 Security -----------| | 707 Policy | V | 708 | +---------------+ (2)+-------------+ | 709 | |Translate into |--->| South. Prot.| | 710 | |IPsec policies | | | | 711 | +---------------+ +-------------+ | 712 | | | | 713 | | | | 714 +-------------------------| --- |--------+ 715 | | 716 | (3) | 717 |----------------------+ +--| 718 V V 719 +------------------+ +------------------+ 720 | NSF1 |<=====>| NSF2 | 721 |IPsec(SPD/SAD) | 4) |IPsec(SPD/SAD) | 722 +------------------+ +------------------+ 724 Figure 4: Host-to-Host / Gateway-to-Gateway single controller flow 725 for case 2. 727 In case 2, flow-based security policies defined by the administrator 728 are also translated into IPsec SPD entries and inserted into the 729 corresponding NSFs. Besides, fresh SAD entries will be also 730 genereated by the controller and enforced in the NSFs. In this case 731 the execution of IKE is not necessary in the controller, and it 732 provides the cryptographic material for the IPsec SAs. These keys 733 will be also distributed securely through the southbound interface. 734 Note that this is possible because both NSFs are managed by the same 735 controller. 737 Figure 4 describes the case 2, when a data packet needs to be 738 protected in the path between the NSF1 and NSF2: 740 1. The administrator establishes the flow-based security policies. 741 The controller looks for the involved NSFs. 743 2. The controller translates the flow-based security policies into 744 IPsec SPD and SAD entries. 746 3. The controller inserts the these entries in both NSF1 and NSF2 747 IPsec databases. 749 4. The flow is protected with the IPsec SA established by the 750 Security Controller. 752 Both NSFs could be two hosts that exchange traffic and require to 753 establish an end-to-end security association to protect their 754 communications (host-to-host) or two gateways (gateway-to-gateway)), 755 for example, within an enterprise that needs to protect the traffic 756 between, for example, the networks of two branch offices. 758 Applicability of these configurations appear in current and new 759 networking scenarios. For example, SD-WAN technologies are providing 760 dynamic and on-demand VPN connections between branch offices or 761 between branches and SaaS cloud services. Beside, IaaS services 762 providing virtualization environments are deployments solutions based 763 on IPsec to provide secure channels between virtual instances (Host- 764 to-Host) and providing VPN solutions for virtualized networks 765 (Gateway-to-Gateway). 767 In general (for case 1 and case 2), this system presents various 768 advantages: 770 1. It allows to create a IPsec SA among two NSFs, with only the 771 application of more general flow-based security policies at the 772 application layer. Thus, an administrator/s can manage all 773 security associations in a centralized point with an abstracted 774 view of the network; 776 2. All NSFs deployed after the application of the new policies are 777 NOT manually configured, therefore allowing its deployment in an 778 automated manner. 780 7.2. Host-to-Host or Gateway-to-gateway under different Security 781 controllers 783 It is also possible that two NSFs (i.e. NSF1 and NSF2) are under the 784 control of two different security controllers. This may happen, for 785 example, when two organizations, namely Enterprise A and Enterprise 786 B, have their headquarters interconnected through a WAN connection 787 and they both have deployed a SDN-based architecture to provide 788 connectivity to all their clients. 790 +-------------+ +-------------+ 791 | | | | 792 Flow-based| Security |<===============>| Security <--Flow-based 793 Sec. Pol.--> Controller | (3) | Controller | Sec. Pol. 794 (1) | A | | B | (2) 795 +-------------+ +-------------+ 796 | | 797 | (4) (4) | 798 V V 799 +----------------------+ +----------------------+ 800 | NSF1 |<========>| NSF2 | 801 |IKE/IPsec(SPD/SAD/PAD)| |IKE/IPsec(SPD/SAD/PAD)| 802 +----------------------+ (5) +----------------------+ 804 Figure 5: Different security controllers in Case 1 806 Figure 5 describes case 1 when two Security Controllers are involved 807 in the process. 809 1. The A's 'administrator establishes general Flow-based Security 810 Policies in Security Controller A. 812 2. The B's administrator establishes general Flow-based Security 813 Policies in Security Controller B. 815 3. The Security Controller A realizes that protection is required 816 between the NSF1 and NSF2, but the NSF2 is under the control of 817 another Security Controller (Security Controller B), so it starts 818 negotiations with the other controller to agree on the IPsec SPD 819 policies and IKE credentials for their respective NSFs. NOTE: 820 This may require extensions in the East/West interface. 822 4. Then, both Security Controllers enforce the IKE credentials and 823 related parameters and the SPD and PAD entries in their 824 respective NSFs. 826 5. The flow is protected with the IPsec SA established with IKEv2 827 between both NSFs. 829 +--------------+ +--------------+ 830 | | | | 831 Flow-based. ---> IKE? | <---- Flow-based 832 Prot. | Security |<=================>| Security | Sec. 833 Pol.(1)| Controller | (3) | Controller | Pol. (2) 834 | A | | B | 835 +--------------+ +--------------+ 836 | | 837 | (4) (4) | 838 V V 839 +------------------+ (5) +------------------+ 840 | NSF1 |<==============>| NSF2 | 841 |IPsec(SPD/SAD/PAD)| |IPsec(SPD/SAD/PAD)| 842 +------------------+ +------------------+ 844 Figure 6: Different security controllers in case 2 846 Figure 5 describes case 1 when two Security Controllers are involved 847 in the process. 849 1. The A's administrator establishes general Flow Protection 850 Policies in Security Controller A. 852 2. The B's administrator establishes general Flow Protection 853 Policies in Security Controller B. 855 3. The Security Controller A realizes that the flow between NSF1 and 856 NSF2 MUST be protected. Nevertheless, the controller notices 857 that NSF2 is under the control of another Security Controller, so 858 it starts negotiations with the other controller to agree on the 859 IPsec SPD and SAD entries that define the IPsec SAs. NOTE: It 860 would worth evaluating IKE as the protocol for the the East/West 861 interface in this case. 863 4. Once the controllers have agreed on key material and the details 864 of the IPsec SA, they both enforce this information into their 865 respective NSFs. 867 5. The flow is protected with the IPsec SA established by both 868 Security Controllers in their respective NSFs. 870 8. Implementation notes 872 At the time of writing this document, we have implemented a proof-of- 873 concept using NETCONF as southbound protocol, and the YANG model 874 described in Appendix A. The netopeer implementation [netopeer] has 875 been used for both case 1 and case 2 using host-to-host and gateway- 876 to-gateway configuration. For the case 1, we have used Strongswan 877 [strongswan] distribution for the IKE implementation. 879 Note that the proposed YANG model provides the models for SPD, SAD, 880 PAD and IKE, but, as describe before, only part of them are required 881 depending of the case (1 or 2) been applied. The Controller should 882 be able to know the kind of case to be applied in the NSF and to 883 select the corresponding models based on the YANG features defines 884 for each one 886 Internally to the NSF, the NETCONF server (that implements the I2NSF 887 Agent) is able to apply the required configuration updating the 888 corresponding NETCONF datastores (running, startup, etc.). Besides, 889 it can deal with the SPD and SAD configuration at kernel level, 890 through different APIs. For example, the IETF RFC 2367 (PF_KEYv2) 891 [RFC2367] provides a generic key management API that can be used not 892 only for IPsec but also for other network security services to manage 893 the IPsec SAD. Besides, as an extension to this API, the document 894 [I-D.pfkey-spd] specifies some PF_KEY extensions to maintain the SPD. 895 This API is accessed using sockets. 897 An alternative key management API based on Netlink socket API 898 [RFC3549] is used to configure IPsec on the Linux Operating System. 900 To allow the NETCONF server implementation interacts with the IKE 901 daemon, we have used the Versatile IKE Configuration Interface (VICI) 902 in Strongswan. This allows changes in the IKE part of the 903 configuration data to be applied in the IKE daemon dynamically. 905 9. Security Considerations 907 TBD. 909 10. Acknowledgements 911 Authors want to thank Sowmini Varadhan, David Carrel, Yoav Nir, Tero 912 Kivinen, Paul Wouters, Graham Bartlett, Sandeep Kampati, Linda 913 Dunbar, Carlos J. Bernardos, Alejandro Perez-Mendez, Alejandro Abad- 914 Carrascosa, Ignacio Martinez and Ruben Ricart for their valuable 915 comments. 917 11. References 919 11.1. Normative References 921 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 922 Requirement Levels", BCP 14, RFC 2119, 923 DOI 10.17487/RFC2119, March 1997, 924 . 926 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 927 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 928 December 2005, . 930 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 931 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 932 DOI 10.17487/RFC5226, May 2008, 933 . 935 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 936 Kivinen, "Internet Key Exchange Protocol Version 2 937 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 938 2014, . 940 11.2. Informative References 942 [I-D.ietf-i2nsf-framework] 943 Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 944 Kumar, "Framework for Interface to Network Security 945 Functions", draft-ietf-i2nsf-framework-04 (work in 946 progress), October 2016. 948 [I-D.ietf-i2nsf-problem-and-use-cases] 949 Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., 950 and J. Jeong, "I2NSF Problem Statement and Use cases", 951 draft-ietf-i2nsf-problem-and-use-cases-15 (work in 952 progress), April 2017. 954 [I-D.ietf-i2nsf-terminology] 955 Hares, S., Strassner, J., Lopez, D., Xia, L., and H. 956 Birkholz, "Interface to Network Security Functions (I2NSF) 957 Terminology", draft-ietf-i2nsf-terminology-03 (work in 958 progress), March 2017. 960 [I-D.jeong-i2nsf-sdn-security-services-05] 961 Jeong, J., Kim, H., Park, J., Ahn, T., and S. Lee, 962 "Software-Defined Networking Based Security Services using 963 Interface to Network Security Functions", draft-jeong- 964 i2nsf-sdn-security-services-05 (work in progress), July 965 2016. 967 [I-D.pfkey-spd] 968 Sakane, S., "PF_KEY Extensions for IPsec Policy Management 969 in KAME Stack", October 2002. 971 [I-D.sivakumar-yang-nat] 972 Sivakumar, S., Boucadair, M., and S. <>, "YANG Data Model 973 for Network Address Translation (NAT)", draft-sivakumar- 974 yang-nat-06 (work in progress), March 2017. 976 [I-D.tran-ipsecme-yang] 977 Tran, K., Wang, H., Nagaraj, V., and X. Chen, "Yang Data 978 Model for Internet Protocol Security (IPsec)", draft-tran- 979 ipsecme-yang-01 (work in progress), June 2015. 981 [ITU-T.X.1252] 982 "Baseline Identity Management Terms and Definitions", 983 April 2010. 985 [ITU-T.X.800] 986 "Security Architecture for Open Systems Interconnection 987 for CCITT Applications", March 1991. 989 [ITU-T.Y.3300] 990 "Recommendation ITU-T Y.3300", June 2014. 992 [netconf-vpn] 993 Stefan Wallin, "Tutorial: NETCONF and YANG", January 2014. 995 [netopeer] 996 CESNET, CESNET., "NETCONF toolset Netopeer", November 997 2016. 999 [ONF-OpenFlow] 1000 ONF, "OpenFlow Switch Specification (Version 1.4.0)", 1001 October 2013. 1003 [ONF-SDN-Architecture] 1004 "SDN Architecture", June 2014. 1006 [RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key 1007 Management API, Version 2", RFC 2367, 1008 DOI 10.17487/RFC2367, July 1998, 1009 . 1011 [RFC3549] Salim, J., Khosravi, H., Kleen, A., and A. Kuznetsov, 1012 "Linux Netlink as an IP Services Protocol", RFC 3549, 1013 DOI 10.17487/RFC3549, July 2003, 1014 . 1016 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 1017 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 1018 RFC 3948, DOI 10.17487/RFC3948, January 2005, 1019 . 1021 [RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and 1022 Internet Key Exchange (IKE) Document Roadmap", RFC 6071, 1023 DOI 10.17487/RFC6071, February 2011, 1024 . 1026 [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined 1027 Networking: A Perspective from within a Service Provider 1028 Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, 1029 . 1031 [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for 1032 System Management", RFC 7317, DOI 10.17487/RFC7317, August 1033 2014, . 1035 [strongswan] 1036 CESNET, CESNET., "StrongSwan: the OpenSource IPsec-based 1037 VPN Solution", April 2017. 1039 Appendix A. Appendix A: YANG model IPsec Configuration data 1041 file "ietf-ipsec.yang" 1042 module ietf-ipsec { 1044 namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec"; 1046 prefix "eipsec"; 1048 import ietf-inet-types { prefix inet; } 1049 import ietf-yang-types { prefix yang; } 1051 organization "University of Murcia"; 1053 contact 1054 " Rafael Marin Lopez 1055 Dept. Information and Communications Engineering (DIIC) 1056 Faculty of Computer Science-University of Murcia 1057 30100 Murcia - Spain 1058 Telf: +34868888501 1059 e-mail: rafa@um.es 1061 Gabriel Lopez Millan 1062 Dept. Information and Communications Engineering (DIIC) 1063 Faculty of Computer Science-University of Murcia 1064 30100 Murcia - Spain 1065 Tel: +34 868888504 1066 email: gabilm@um.es 1067 "; 1069 description "Data model for IPSec"; 1071 revision "2017-05-02" { 1072 description 1073 "Initial revision."; 1074 reference ""; 1075 } 1077 feature case1 { description "feature case 1: IKE SPD PAD"; } // IKE/IPSec in the NSFs 1078 feature case2 { description "feature case 2: SPD SAD"; } // Only IPSec in the NSFs 1079 typedef encryption-algorithm-t { 1081 type enumeration { 1082 enum reserved-0 {description "reserved";} 1083 enum des-iv4 { description "DES IV 4";} 1084 enum des { description "DES"; } 1085 enum 3des { description "3DES"; } 1086 enum rc5 { description "RC5"; } 1087 enum idea { description "IDEA"; } 1088 enum cast { description "CAST"; } 1089 enum blowfish { description "BlowFish"; } 1090 enum 3idea { description "3IDEA"; } 1091 enum des-iv32 { description "DES-IV32"; } 1092 enum reserved-10 { description "reserved-10"; } 1093 enum null { description "NULL"; } 1094 enum aes-cbc { description "AES-CBC"; } 1095 enum aes-ctr { description "AES-CTR"; } 1096 enum aes-ccm-8 { description "AES-CCM-8"; } 1097 enum aes-ccm-12 { description "AES-CCM-12"; } 1098 enum aes-ccm-16 { description "AES-CCM-16"; } 1099 enum reserved-17 { description "reserved-17"; } 1100 enum aes-gcm-8-icv { description "AES-GCM-8-ICV"; } 1101 enum aes-gcm-12-icv { description "AES-GCM-12-ICV"; } 1102 enum aes-gcm-16-icv { description "AES-GCM-16-ICV"; } 1103 enum null-auth-aes-gmac { description "Null-Auth-AES-GMAC"; } 1104 enum ieee-p1619-xts-aes { 1105 description 1106 "encr-ieee-p1619-xts-aes --> Reserved for IEEE P1619 XTS-AES."; 1107 } 1108 enum camellia-cbc { description "CAMELLIA-CBC"; } 1109 enum camellia-ctr { description "CAMELLIA.CTR"; } 1110 enum camellia-ccm-8-icv { description "CAMELLIA-CCM-8-ICV"; } 1111 enum camellia-ccm-12-icv { description "CAMELLIA-CCM-12-ICV"; } 1112 enum camellia-ccm-16-icv { description "CAMELLIA-CCM-16-ICV"; } 1113 enum aes-cbc-128 { description "AES-CBC-128"; } 1114 enum aes-cbc-192 { description "AES-CBC-192"; } 1115 enum aes-cbc-256 { description "AES-CBC-256"; } 1116 enum blowfish-128 { description "BlowFish-128"; } 1117 enum blowfish-192 { description "BlowFish-192"; } 1118 enum blowfish-256 { description "BlowFish-256"; } 1119 enum blowfish-448 { description "BlowFish-448"; } 1120 enum camellia-128 { description "CAMELLIA-128"; } 1121 enum camellia-192 { description "CAMELLIA-192"; } 1122 enum camellia-256 { description "CAMELLIA-256"; } 1123 } 1124 description "Encryption algorithms --> RFC_5996"; 1125 } 1126 typedef integrity-algorithm-t { 1128 type enumeration { 1129 enum none { description "NONE"; } 1130 enum hmac-md5-96 { description "HMAC-MD5-96"; } 1131 enum hmac-sha1-96 { description "HMAC-SHA1-96"; } 1132 enum des-mac { description "DES-MAC"; } 1133 enum kpdk-md5 {description "KPDK-MD5"; } 1134 enum aes-xcbc-96 { description "AES-XCBC-96"; } 1135 enum hmac-md5-128 { description "HMAC-MD5-128"; } 1136 enum hmac-sha1-160 { description "HMAC-SHA1-160"; } 1137 enum aes-cmac-96 { description "AES-CMAC-96"; } 1138 enum aes-128-gmac { description "AES-128-GMAC"; } 1139 enum aes-192-gmac { description "AES-192-GMAC"; } 1140 enum aes-256-gmac { description "AES-256-GMAC"; } 1141 enum hmac-sha2-256-128 { description "HMAC-SHA2-256-128"; } 1142 enum hmac-sha2-384-192 { description "HMAC-SHA2-384-192"; } 1143 enum hmac-sha2-512-256 { description "HMAC-SHA2-512-256"; } 1144 enum hmac-sha2-256-96 { description "HMAC-SHA2-256-096"; } 1145 } 1146 description "Integrity Algorithms --> RFC_5996"; 1147 } 1149 typedef combined-algorithm-t { 1151 type enumeration { 1152 enum AES-GCM-16-ICV { description "AES-GCM-16-ICV"; } 1153 enum AES-CCM { description "AES-CCM"; } 1154 } 1155 description "Combined Algorithms --> RFC 7321"; 1156 } 1158 typedef auth-protocol-type { 1159 type enumeration { 1160 enum IKEv1 { // not supported by model 1161 description "Authentication protocol based on IKEv1"; 1162 } 1163 enum IKEv2 { 1164 description "Authentication protocol based on IKEv2"; 1165 } 1166 enum KINK { // not supported by model 1167 description "Authentication protocol based on KINK"; 1168 } 1169 } 1170 description "Peer authentication protocols"; 1171 } 1173 typedef ipsec-mode { 1174 type enumeration { 1175 enum TRANSPORT { description "Transport mode"; } 1176 enum TUNNEL { description "Tunnel mode"; } 1177 enum BEET { description "Bound End-to-End Tunnel (BEET) mode for ESP.";} /*Supported by XFRM*/ 1178 enum RO { description "Route Optimization mode for Mobile IPv6";} /*Supported by XFRM*/ 1179 enum IN_TRIGGER {description "In trigger mode for Mobile IPv6";} /*Supported by XFRM*/ 1180 } 1181 description "type define of ipsec mode"; 1182 } 1184 typedef ipsec-protocol { 1186 type enumeration { 1187 enum ah { description "AH Protocol"; } 1188 enum esp { description "ESP Protocol"; } 1189 enum comp { description "IP Compression";} /*Supported by XFRM*/ 1190 enum route2 { description "Routing Header type 2. Mobile IPv6";} /*Supported by XFRM*/ 1191 enum hao {description "Home Agent Option";} /*Supported by XFRM*/ 1192 } 1193 description "type define of ipsec security protocol"; 1194 } 1196 typedef ipsec-spi { 1198 type uint32 { range "1..max"; } 1199 description "SPI"; 1200 } 1202 typedef lifetime-action { 1203 type enumeration { 1204 enum terminate {description "Terminate the IPsec SA";} 1205 enum replace {description "Replace the IPsec SA with a new one";} 1206 } 1207 description "Action when lifetime expiration"; 1208 } 1210 typedef ipsec-traffic-direction { 1212 type enumeration { 1213 enum INBOUND { description "Inbound traffic"; } 1214 enum OUTBOUND { description "Outbound traffic"; } 1215 enum FORWARD{ description "Forwarded traffic"; } 1216 } 1217 description "IPsec traffic direction"; 1218 } 1219 typedef ipsec-spd-operation { 1221 type enumeration { 1222 enum PROTECT { description "PROTECT the traffic with IPsec"; } 1223 enum BYPASS { description "BYPASS the traffic"; } 1224 enum DISCARD { description "DISCARD the traffic"; } 1225 } 1226 description "The operation when traffic matches IPsec security policy"; 1227 } 1229 typedef ipsec-next-layer-proto { 1231 type enumeration { 1232 enum TCP { description "PROTECT the traffic with IPsec"; } 1233 enum UDP { description "BYPASS the traffic"; } 1234 enum SCTP { description "PROTECT the traffic with IPsec";} 1235 enum DCCP { description "PROTECT the traffic with IPsec";} 1236 enum ICMP { description "PROTECT the traffic with IPsec";} 1237 enum IPv6-ICMP { description "PROTECT the traffic with IPsec";} 1238 enum MH {description "PROTECT the traffic with IPsec";} 1239 enum GRE {description "PROTECT the traffic with IPsec";} 1240 } 1241 description "Next layer proto on top of IP"; 1242 } 1244 typedef ipsec-spd-name { 1246 type enumeration { 1247 enum id_rfc_822_addr { 1248 description "Fully qualified user name string."; 1249 } 1250 enum id_fqdn { 1251 description "Fully qualified DNS name."; 1252 } 1253 enum id_der_asn1_dn { 1254 description "X.500 distinguished name."; 1255 } 1256 enum id_key { 1257 description "IKEv2 Key ID."; 1258 } 1259 } 1260 description "IPsec SPD name type"; 1261 } 1262 typedef auth-method-type { 1263 /* Most implementations also provide XAUTH protocol, others used are: BLISS, P12, NTLM, PIN */ 1265 type enumeration { 1266 enum pre-shared { 1267 description "Select pre-shared key message as the authentication method"; 1268 } 1269 enum rsa-signature { 1270 description "Select rsa digital signature as the authentication method"; 1271 } 1272 enum dss-signature { 1273 description "Select dss digital signature as the authentication method"; 1274 } 1275 enum eap { 1276 description "Select EAP as the authentication method"; 1277 } 1278 } 1279 description "Peer authentication method"; 1280 } 1282 /*################## PAD grouping ####################*/ 1284 grouping auth-method-grouping { 1285 description "Peer authentication method data"; 1287 container auth-method { 1288 description "Peer authentication method container"; 1290 leaf auth-m { 1291 type auth-method-type; 1292 description "Type of authentication method (preshared, rsa, etc.)"; 1293 } 1295 container pre-shared { 1296 when "../auth-m = 'pre-shared'"; 1297 leaf secret { type string; description "Pre-shared secret value";} 1298 description "Shared secret value"; 1299 } 1301 container rsa-signature { 1302 when "../auth-m = 'rsa-signature'"; 1303 leaf key-data { 1304 type string; 1305 description "RSA private key data - PEM"; 1306 } 1308 leaf key-file { 1309 type string; 1310 description "RSA private key file name "; 1311 } 1313 leaf-list ca-data { 1314 type string; 1315 description "List of trusted CA certs - PEM"; 1316 } 1317 leaf ca-file { 1318 type string; 1319 description "List of trusted CA certs file"; 1320 } 1321 leaf cert-data { 1322 type string; 1323 description "X.509 certificate data - PEM4"; 1324 } 1325 leaf cert-file { 1326 type string; 1327 description "X.509 certificate file"; 1328 } 1329 leaf crl-data { 1330 type string; 1331 description "X.509 CRL certificate data in base64"; 1332 } 1333 leaf crl-file { 1334 type string; 1335 description " X.509 CRL certificate file"; 1336 } 1337 description "RSA signature container"; 1338 } 1339 } 1340 } 1342 grouping identity-grouping { 1343 description "Identification type. It is an union identity"; 1344 choice identity { 1345 description "Choice of identity."; 1347 leaf ipv4-address { 1348 type inet:ipv4-address; 1349 description "Specifies the identity as a single four (4) octet IPv4 address. An example is, 10.10.10.10. "; 1350 } 1351 leaf ipv6-address { 1352 type inet:ipv6-address; 1353 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 ."; 1354 } 1355 leaf fqdn-string { 1356 type inet:domain-name; 1357 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.)."; 1359 } 1360 leaf rfc822-address-string { 1361 type string; 1362 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.)."; 1363 } 1364 leaf dnX509 { 1365 type string; 1366 description "Specifies the identity as a distinguished name in the X.509 tradition."; 1367 } 1368 leaf id_key { 1369 type string; 1370 description "Key id"; 1371 } /* From RFC4301 list of id types */ 1372 } 1373 } /* grouping identity-grouping */ 1375 /*################ end PAD grouping ##################*/ 1377 /*################## SAD and SPD grouping ####################*/ 1379 grouping ip-addr-range { 1380 description "IP address range grouping"; 1381 leaf start { 1382 type inet:ip-address; 1383 description "Start IP address"; 1384 } 1385 leaf end { 1386 type inet:ip-address; 1387 description "End IP address"; 1388 } 1389 } 1391 grouping port-range { 1392 description "Port range grouping"; 1393 leaf start { 1394 type inet:port-number; 1395 description "Start IP address"; 1396 } 1397 leaf end { 1398 type inet:port-number; 1399 description "End IP address"; 1400 } 1401 } 1403 grouping tunnel-grouping { 1404 description "Tunnel mode grouping"; 1405 leaf local{ type inet:ip-address; description "Local tunnel endpoint"; } 1406 leaf remote{ type inet:ip-address; description "Remote tunnel enpoint"; } 1407 leaf bypass-df { type boolean; description "bypass DF bit"; } 1408 leaf bypass-dscp { type boolean; description "bypass DSCP"; } 1409 leaf dscp-mapping { type yang:hex-string; description "DSCP mapping"; } 1410 leaf ecn { type boolean; description "Bit ECN"; } /* RFC 4301 ASN1 notation. Annex C*/ 1411 } 1413 grouping selector-grouping { 1414 description "Traffic selector grouping"; 1415 list local-addresses { 1416 key "start end"; 1417 uses ip-addr-range; 1418 description "List of local addresses"; 1419 } 1420 list remote-addresses { 1421 key "start end"; 1422 uses ip-addr-range; 1423 description "List of remote addresses"; 1424 } 1425 leaf-list next-layer-protocol { type ipsec-next-layer-proto; description "List of Next Layer Protocol";} 1426 list local-ports { 1427 key "start end"; 1428 uses port-range; 1429 description "List of local ports"; 1430 } 1432 list remote-ports { 1433 key "start end"; 1434 uses port-range; 1435 description "List of remote ports"; 1436 } 1437 } 1439 /*################## SAD grouping ####################*/ 1441 grouping ipsec-sa-grouping { 1442 description "Configure Security Association (SA). Section 4.4.2.1 in RFC 4301"; 1444 leaf spi { type ipsec-spi; description "Security Parameter Index";} 1445 leaf seq-number { type uint64; description "Current sequence number of IPsec packet."; } 1446 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."; } 1447 leaf anti-replay-window { type uint16 { range "0 | 32..1024"; } description "Anti replay window"; } 1448 leaf rule-number {type uint32; description "This value links the SA with the SPD entry";} 1450 uses selector-grouping; 1452 leaf security-protocol { type ipsec-protocol; description "Security protocol of IPsec SA: Either AH or ESP."; } 1454 container ah-sa { 1455 when "../security-protocol = 'ah'"; 1456 description "Configure Authentication Header (AH) for SA"; 1457 leaf integrity-algorithm { type integrity-algorithm-t; description "Configure Authentication Header (AH)."; } 1458 leaf key { type string; description "AH key value";} 1459 } 1461 container esp-sa { 1462 when "../security-protocol = 'esp'"; 1463 description "Set IPSec Encapsulation Security Payload (ESP)"; 1465 container encryption { 1466 description "Configure encryption for IPSec Encapsulation Secutiry Payload (ESP)"; 1467 leaf encryption-algorithm { type encryption-algorithm-t; description "Configure ESP encryption"; } 1468 leaf key { type string; description "ESP encryption key value";} 1469 leaf iv {type string; description "ESP encryption IV value"; } 1470 } 1472 container integrity { 1473 description "Configure authentication for IPSec Encapsulation Secutiry Payload (ESP)"; 1474 leaf integrity-algorithm { type integrity-algorithm-t; description "Configure Authentication Header (AH)."; } 1475 leaf key { type string; description "ESP integrity key value";} 1476 } 1478 container combined { 1479 description "ESP combined mode algorithms (encryption and integrity)"; 1480 leaf combined-algorithm { type combined-algorithm-t; description "Combined algorithm AEAD";} 1481 } 1482 } 1484 container sa-lifetime { 1485 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"; 1486 leaf time-soft { type uint32; default 0; description "Soft time lifetime";} 1487 leaf time-hard { type uint32; default 0; description "Hard time lifetime"; } 1488 leaf time-use-soft { type uint32; default 0; description "Use Soft time lifetime";} 1489 leaf time-use-hard { type uint32; default 0; description "Use Hard time lifetime";} 1490 leaf byte-soft { type uint32; default 0;description "Byte soft lifetime"; } 1491 leaf byte-hard { type uint32; default 0; description "Byte hard lifetime";} 1492 leaf packet-soft {type uint32; default 0; description "Packet soft lifetime";} 1493 leaf packet-hard { type uint32; default 0; description "Packet hard lifetime";} 1494 leaf action {type lifetime-action; description "action lifetime";} 1495 } 1497 leaf mode { type ipsec-mode; description "SA Mode"; } 1498 leaf statefulfragCheck { type boolean; description "TRUE stateful fragment checking, FALSE no stateful fragment checking"; } 1499 leaf dscp { type yang:hex-string; description "DSCP value"; } 1500 container tunnel { 1501 when "../mode = 'TUNNEL'"; 1502 uses tunnel-grouping; 1503 description "Container for tunnel grouping"; 1504 } 1506 leaf path-mtu { type uint16; description "Maximum size of an IPsec packet that can be transmitted without fragmentation"; } 1508 container encap { /* This is defined by XFRM */ 1509 description "Encapsulation container"; 1510 leaf espinudp {type boolean; description "TRUE espinudp; FALSE espindup-nonike";} 1511 leaf sport {type inet:port-number; description "Encapsulation source port";} 1512 leaf dport {type inet:port-number; description "Encapsulation destination port"; } 1513 leaf oaddr {type inet:ip-address; description "Encapsulation Original Address ";} 1514 } 1516 } 1518 /*################## end SAD grouping ##################*/ 1520 /*################## SPD grouping ####################*/ 1522 grouping ipsec-policy-grouping { 1523 description "Holds configuration information for an IPSec SPD entry."; 1525 leaf rule-number { 1526 type uint64; 1527 description "SPD index. RFC4301 does not mention an index however real implementations provide a policy index/or id to refer a policy. "; 1528 } 1529 leaf priority {type uint32; default 0; description "Policy priority";} 1530 list names { 1531 key "name"; 1532 leaf name-type { 1533 type ipsec-spd-name; 1534 description "SPD name type."; 1535 } 1536 leaf name { 1537 type string; description "Policy name"; 1538 } 1539 description "List of policy names"; 1540 } 1542 container condition { 1543 description "SPD condition --> RFC4301"; 1544 list traffic-selector-list { 1546 key "ts-number"; 1548 leaf ts-number { type uint32; description "Traffic selector number"; } 1549 leaf direction { type ipsec-traffic-direction; description "in/fwd/out"; } 1551 uses selector-grouping; 1552 leaf selector-priority {type uint32; default 0; description "It establishes a priority to the traffic selector";} 1553 ordered-by user; 1555 description "List of traffic selectors"; 1556 } 1557 } 1559 container processing-info { 1560 description "SPD processing --> RFC4301"; 1561 leaf action{ type ipsec-spd-operation; mandatory true; description "If the action is bypass or discard processing container ipsec-sa-cfg is empty";} 1563 container ipsec-sa-cfg { 1564 when "../action = 'PROTECT'"; 1566 leaf pfp-flag { type boolean; description "Each selector has with a pfp flag."; } 1567 leaf extSeqNum { type boolean; description "TRUE 64 bit counter, FALSE 32 bit"; } 1568 leaf seqOverflow { type boolean; description "TRUE rekey, FALSE terminare & audit"; } 1569 leaf statefulfragCheck { type boolean; description "TRUE stateful fragment checking, FALSE no stateful fragment checking"; } 1570 leaf security-protocol { type ipsec-protocol; description "Security protocol of IPsec SA: Either AH or ESP."; } 1571 leaf mode { type ipsec-mode; description "transport/tunnel"; } 1573 container ah-algorithms { 1574 when "../security-protocol = 'ah'"; 1575 leaf-list ah-algorithm { 1576 type integrity-algorithm-t; 1577 description "Configure Authentication Header (AH)."; 1578 } 1579 description "AH algoritms "; 1580 } 1582 container esp-algorithms { 1583 when "../security-protocol = 'esp'"; 1584 description "Configure Encapsulating Security Payload (ESP)."; 1585 leaf-list authentication { type integrity-algorithm-t; description "Configure ESP authentication"; } 1586 leaf-list encryption { type encryption-algorithm-t; description "Configure ESP encryption"; } 1587 } 1589 container tunnel { 1590 when "../mode = 'TUNNEL'"; 1591 uses tunnel-grouping; 1592 description "tunnel grouping container"; 1593 } 1594 description " IPSec SA configuration container"; 1595 } 1596 } 1598 container spd-lifetime { 1599 description "SPD lifetime parameters"; 1600 leaf time-soft { type uint32; default 0; description "Soft time lifetime";} 1601 leaf time-hard { type uint32; default 0; description "Hard time lifetime";} 1602 leaf time-use-soft { type uint32; default 0; description "Use soft lifetime";} 1603 leaf time-use-hard { type uint32; default 0; description "Use hard lifetime";} 1604 leaf byte-soft { type uint32; default 0; description "Byte soft lifetime";} 1605 leaf byte-hard { type uint32; default 0; description "Hard soft lifetime";} 1606 leaf packet-soft {type uint32; default 0; description "Packet soft lifetime";} 1607 leaf packet-hard { type uint32; default 0; description "Packet hard lifetime";} 1608 } 1609 }/* grouping ipsec-policy-grouping */ 1611 /*################ end SPD grouping ##################*/ 1613 /*################## IKEv2-grouping ##################*/ 1615 grouping isakmp-proposal { 1616 description "ISAKMP proposal grouping"; 1617 leaf phase1-lifetime { 1618 type uint32; 1619 mandatory true; 1620 description "lifetime for IKE Phase 1 SAs"; 1621 } 1622 leaf phase1-authby { 1623 type auth-method-type; 1624 mandatory true; 1625 description "Auth method for IKE Phase 1 SAs"; 1626 } 1627 leaf-list phase1-authalg { 1628 type integrity-algorithm-t; 1629 description "Auth algorigthm for IKE Phase 1 SAs"; 1630 } 1631 leaf-list phase1-encalg { 1632 type encryption-algorithm-t; 1633 description "Auth algorigthm for IKE Phase 1 SAs"; 1634 } 1635 leaf dh_group { 1636 type uint32; 1637 mandatory true; 1638 description "Group number for Diffie Hellman Exponentiation"; 1639 } 1640 } /* list isakmp-proposal */ 1642 grouping phase2-info { 1643 description "IKE Phase 2 Information"; 1644 leaf local-addrs { 1645 type inet:ip-address; 1646 mandatory true; 1647 description "IKEv2 Local address"; 1648 } 1649 leaf remote-addr { 1650 type inet:ip-address; 1651 mandatory true; 1652 description "IKEv2 Remote address"; 1653 } 1654 leaf pfs_group { 1655 type uint32; 1656 description 1657 "If non-zero, require perfect forward secrecy 1658 when requesting new SA. The non-zero value is 1659 the required group number"; 1660 } 1661 leaf phase2-lifetime { 1662 type uint32; 1663 mandatory true; 1664 description "lifetime for IKE Phase 2 SAs"; 1665 } 1666 leaf-list phase2-authalg { 1667 type integrity-algorithm-t; 1668 description "Auth algorigthm for IKE Phase 2 SAs"; 1669 } 1670 leaf-list phase2-encalg { 1671 type encryption-algorithm-t; 1672 description "Auth algorithm for IKE Phase 2 SAs"; 1673 } 1674 } 1676 grouping local-grouping { 1677 description "Configure the local peer in an IKE connection"; 1679 container local { 1680 description "Local container"; 1681 choice my-identifier-type { 1682 default ipv4; 1683 case ipv4 { 1684 leaf ipv4 { 1685 type inet:ipv4-address; 1686 description "IPv4 dotted-decimal address"; 1687 } 1688 } 1689 case ipv6 { 1690 leaf ipv6 { 1691 type inet:ipv6-address; 1692 description "numerical IPv6 address"; 1693 } 1694 } 1695 case fqdn { 1696 leaf fqdn { 1697 type inet:domain-name; 1698 description "Fully Qualifed Domain name "; 1699 } 1700 } 1701 case dn { 1702 leaf dn { 1703 type string; 1704 description "Domain name"; 1705 } 1706 } 1707 case user_fqdn { 1708 leaf user_fqdn { 1709 type string; 1710 description "User FQDN"; 1711 } 1712 } 1713 description "Local ID type"; 1714 } 1715 leaf my-identifier { 1716 type string; 1717 mandatory true; 1718 description "Local id used for authentication"; 1719 } 1720 } 1721 } 1723 grouping remote-grouping { 1724 description "Configure the remote peer in an IKE connection"; 1725 container remote { 1726 description "Remote container"; 1727 choice my-identifier-type { 1728 default ipv4; 1729 case ipv4 { 1730 leaf ipv4 { 1731 type inet:ipv4-address; 1732 description "IPv4 dotted-decimal address"; 1733 } 1734 } 1735 case ipv6 { 1736 leaf ipv6 { 1737 type inet:ipv6-address; 1738 description "numerical IPv6 address"; 1739 } 1740 } 1741 case fqdn { 1742 leaf fqdn { 1743 type inet:domain-name; 1744 description "Fully Qualifed Domain name "; 1745 } 1746 } 1747 case dn { 1748 leaf dn { 1749 type string; 1750 description "Domain name"; 1751 } 1752 } 1753 case user_fqdn { 1754 leaf user_fqdn { 1755 type string; 1756 description "User FQDN"; 1757 } 1758 } 1759 description "Local ID type"; 1760 } 1761 leaf my-identifier { 1762 type string; 1763 mandatory true; 1764 description "Local id used for authentication"; 1765 } 1766 } 1767 } 1769 /*################## End IKEv2-groupingUMU ##################*/ 1771 /*################# Register grouping #################*/ 1773 typedef sadb-msg-type { 1775 type enumeration { 1776 enum sadb_reserved { description "SADB_RESERVED";} 1777 enum sadb_getspi { description "SADB_GETSPI";} 1778 enum sadb_update { description "SADB_UPDATE";} 1779 enum sadb_add { description "SADB_ADD";} 1780 enum sadb_delete { description "SADB_DELETE"; } 1781 enum sadb_get { description "SADB_GET"; } 1782 enum sadb_acquire { description "SADB_ACQUIRE"; } 1783 enum sadb_register { description "SADB_REGISTER"; } 1784 enum sadb_expire { description "SADB_EXPIRE"; } 1785 enum sadb_flush { description "SADB_FLUSH"; } 1786 enum sadb_dump { description "SADB_DUMP"; } 1787 enum sadb_x_promisc { description "SADB_X_PROMISC"; } 1788 enum sadb_x_pchange { description "SADB_X_PCHANGE"; } 1789 enum sadb_max{ description "SADB_MAX"; } 1790 } 1791 description "PF_KEY base message types"; 1792 } 1794 typedef sadb-msg-satype { 1796 type enumeration { 1797 enum sadb_satype_unspec { description "SADB_SATYPE_UNSPEC"; } 1798 enum sadb_satype_ah { description "SADB_SATYPE_AH"; } 1799 enum sadb_satype_esp { description "SADB_SATYPE_ESP"; } 1800 enum sadb_satype_rsvp { description "SADB_SATYPE_RSVP"; } 1801 enum sadb_satype_ospfv2 { description "SADB_SATYPE_OSPFv2"; } 1802 enum sadb_satype_ripv2 { description "SADB_SATYPE_RIPv2"; } 1803 enum sadb_satype_mip { description "SADB_SATYPE_MIP"; } 1804 enum sadb_satype_max { description "SADB_SATYPE_MAX"; } 1805 } 1806 description "PF_KEY Security Association types"; 1807 } 1809 grouping base-grouping { 1810 description "Configuration for the message header format"; 1811 list base-list { 1812 key "version"; 1813 leaf version { type string; description "Version of PF_KEY (MUST be PF_KEY_V2)"; } 1814 leaf msg_type { type sadb-msg-type; description "Identifies the type of message"; } 1815 leaf msg_satype { type sadb-msg-satype; description "Defines the type of Security Association"; } 1816 leaf msg_seq { type uint32; description "Sequence number of this message."; } 1817 description "Configuration for a specific message header format"; 1818 } 1819 } 1821 grouping algorithm-grouping { 1822 description "List of supported authentication and encryptation algorithms"; 1823 list algorithm-supported{ 1824 container authentication { 1825 description "Authentication algorithm supported"; 1826 leaf name { type integrity-algorithm-t; description "Name of authentication algorithm"; } 1827 leaf ivlen { type uint8; description "Length of the initialization vector to be used for the algorithm"; } 1828 leaf min-bits { type uint16; description "The minimun acceptable key length, in bits"; } 1829 leaf max-bits { type uint16; description "The maximun acceptable key length, in bits"; } 1830 } 1831 container encryption { 1832 description "Encryptation algorithm supported"; 1833 leaf name { type encryption-algorithm-t; description "Name of encryption algorithm"; } 1834 leaf ivlen { type uint8; description "Length of the initialization vector to be used for the algorithm"; } 1835 leaf min-bits { type uint16; description "The minimun acceptable key length, in bits"; } 1836 leaf max-bits { type uint16; description "The maximun acceptable key length, in bits"; } 1837 } 1838 description "List for a specific algorithm"; 1839 } 1840 } 1842 /*################# End Register grouping #################*/ 1844 /*################## ipsec ##################*/ 1846 container ietf-ipsec { 1847 description "Main IPsec container "; 1849 container ikev2 { 1850 if-feature case1; 1851 description "Configure the IKEv2"; 1853 container ike-connection { 1854 description "IKE connections configuration"; 1856 list ike-conn-entries { 1857 key "conn-name"; 1858 description "IKE peer connetion information"; 1859 leaf conn-name { 1860 type string; 1861 mandatory true; 1862 description "Name of IKE connection"; 1863 } 1864 leaf autostartup { 1865 type boolean; 1866 mandatory true; 1867 description "if True: automatically start tunnel at startup; else we do lazy tunnel setup based on trigger from datapath"; 1868 } 1869 leaf nat-traversal { 1870 type boolean; 1871 default false; 1872 description "Enable/Disable NAT traversal"; 1873 } 1874 leaf version { 1876 type enumeration { 1877 /* we only support ikev2 in this version */ 1878 enum ikev2 {value 2; description "IKE version 2";} 1879 } 1880 description "IKE version"; 1881 } 1883 uses isakmp-proposal; 1884 uses local-grouping; 1885 uses remote-grouping; 1886 uses phase2-info; 1888 } /* ike-conn-entries */ 1889 } /* container ike-connection */ 1890 } /* container ikev2 */ 1892 container ipsec { 1893 description "Configuration IPsec"; 1895 container spd { 1896 description "Configure the Security Policy Database (SPD)"; 1897 list spd-entry { 1898 key "rule-number"; 1899 uses ipsec-policy-grouping; 1900 ordered-by user; 1901 description "List of SPD entries"; 1902 } 1903 } 1905 container sad { 1906 if-feature case2; 1907 description "Configure the IPSec Security Association Database (SAD)"; 1908 list sad-entry { 1909 key "spi"; 1910 uses ipsec-sa-grouping; 1911 description "List of SAD entries"; 1912 } 1913 } 1915 container pad { 1916 if-feature case1; 1917 description "Configure Peer Authorization Database (PAD)"; 1919 list pad-entries { 1920 key "pad-entry-id"; 1921 ordered-by user; 1922 description "Peer Authorization Database (PAD)"; 1923 leaf pad-entry-id { 1924 type uint64; 1925 description "SAD index. "; 1926 } 1928 uses identity-grouping; 1930 leaf pad-auth-protocol { 1931 type auth-protocol-type; 1932 description "IKEv1, IKEv2, KINK, etc. "; 1933 } 1934 uses auth-method-grouping; 1935 } 1936 } 1937 } 1939 } /* container ietf-ipsec */ 1941 /*########## State Data ############*/ 1943 // TBD 1945 /*################## RPC and Notifications ##################*/ 1947 /* Note: not yet completed */ 1948 // Those RPCs are needed by a Security Controller in case 2 */ 1950 rpc sadb_register { 1951 description "Allows netconf to register its key socket as able to acquire new security associations for the kernel"; 1952 input { 1953 uses base-grouping; 1954 } 1955 output { 1956 uses base-grouping; 1957 uses algorithm-grouping; 1958 } 1959 } 1961 notification spd-expire { 1962 description "A SPD entry has expired"; 1963 leaf index { 1964 type uint64; 1965 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. "; 1966 } 1967 } 1968 notification sadb_acquire { 1969 description "A IPsec SA is required "; 1970 leaf state { 1971 type uint32; 1972 mandatory "true"; 1973 description 1974 "Request the creation of a SADB entry"; 1975 } 1976 } 1978 notification sadb_expire { 1979 description "....."; 1980 leaf state { 1981 type uint32; 1982 mandatory "true"; 1983 description 1984 "Notify the expiration of a entry in the SADB"; 1985 } 1986 } 1988 } /*module ietf-ipsec*/ 1990 1992 Authors' Addresses 1994 Rafa Marin-Lopez 1995 University of Murcia 1996 Campus de Espinardo S/N, Faculty of Computer Science 1997 Murcia 30100 1998 Spain 2000 Phone: +34 868 88 85 01 2001 EMail: rafa@um.es 2003 Gabriel Lopez-Millan 2004 University of Murcia 2005 Campus de Espinardo S/N, Faculty of Computer Science 2006 Murcia 30100 2007 Spain 2009 Phone: +34 868 88 85 04 2010 EMail: gabilm@um.es