idnits 2.17.1 draft-ietf-i2nsf-sdn-ipsec-flow-protection-04.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 288 instances of too long lines in the document, the longest one being 194 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 662 has weird spacing: '...w start ine...' == Line 665 has weird spacing: '...w start ine...' == Line 768 has weird spacing: '...w start ine...' == Line 771 has weird spacing: '...w start ine...' == Line 824 has weird spacing: '...w start ine...' == (5 more instances...) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 1. The Security Controller chooses two random values as SPI for the new inbound SAs: for example, SPIa2 for A and SPIb2 for B. These numbers MUST not be in conflict with any IPsec SA in A or B. == 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: grouping identity-grouping { description "Identification type. It is an union identity"; choice identity { description "Choice of identity."; 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"; } leaf id_null { type empty; description "RFC 7619" ; } leaf user_fqdn { type string; description "User FQDN"; } } leaf my-identifier { type string; mandatory true; description "id used for authentication"; } } -- The document date (March 11, 2019) is 1872 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 1243, but no explicit reference was found in the text == Unused Reference: 'RFC8329' is defined on line 1259, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2nsf-framework' is defined on line 1271, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2nsf-problem-and-use-cases' is defined on line 1277, but no explicit reference was found in the text == Unused Reference: 'I-D.jeong-i2nsf-sdn-security-services-05' is defined on line 1296, but no explicit reference was found in the text == Unused Reference: 'I-D.pfkey-spd' is defined on line 1303, but no explicit reference was found in the text == Unused Reference: 'RFC3549' is defined on line 1342, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Downref: Normative reference to an Informational RFC: RFC 8192 ** Downref: Normative reference to an Informational RFC: RFC 8329 == Outdated reference: A later version (-08) exists of draft-ietf-i2nsf-terminology-07 -- No information found for draft-pfkey-spd - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 8229 (Obsoleted by RFC 9329) Summary: 5 errors (**), 0 flaws (~~), 18 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2NSF R. Marin-Lopez 3 Internet-Draft G. Lopez-Millan 4 Intended status: Standards Track University of Murcia 5 Expires: September 12, 2019 F. Pereniguez-Garcia 6 University Defense Center 7 March 11, 2019 9 Software-Defined Networking (SDN)-based IPsec Flow Protection 10 draft-ietf-i2nsf-sdn-ipsec-flow-protection-04 12 Abstract 14 This document describes how providing IPsec-based flow protection by 15 means of a Software-Defined Network (SDN) controller (aka. Security 16 Controller) and establishes the requirements to support this service. 17 It considers two main well-known scenarios in IPsec: (i) gateway-to- 18 gateway and (ii) host-to-host. The SDN-based service described in 19 this document allows the distribution and monitoring of IPsec 20 information from a Security Controller to one or several flow-based 21 Network Security Function (NSF). The NSFs implement IPsec to protect 22 data traffic between network resources with IPsec. 24 The document focuses in the NSF Facing Interface by providing models 25 for Configuration and State data model required to allow the Security 26 Controller to configure the IPsec databases (SPD, SAD, PAD) and IKEv2 27 to establish security associations with a reduced intervention of the 28 network administrator. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on September 12, 2019. 47 Copyright Notice 49 Copyright (c) 2019 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 66 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 4. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 5. SDN-based IPsec management description . . . . . . . . . . . 6 69 5.1. IKE case: IKE/IPsec in the NSF . . . . . . . . . . . . . 6 70 5.1.1. Interface Requirements for IKE case . . . . . . . . . 7 71 5.2. IKE-less case: IPsec (no IKEv2) in the NSF . . . . . . . 8 72 5.2.1. Interface Requirements for IKE-less case . . . . . . 8 73 5.3. IKE case vs IKE-less case . . . . . . . . . . . . . . . . 9 74 5.3.1. Rekeying process . . . . . . . . . . . . . . . . . . 10 75 5.3.2. NSF state loss . . . . . . . . . . . . . . . . . . . 11 76 5.3.3. NAT Traversal . . . . . . . . . . . . . . . . . . . . 12 77 6. YANG configuration data models . . . . . . . . . . . . . . . 12 78 6.1. IKE case model . . . . . . . . . . . . . . . . . . . . . 13 79 6.2. IKE-less case model . . . . . . . . . . . . . . . . . . . 16 80 7. Use cases examples . . . . . . . . . . . . . . . . . . . . . 21 81 7.1. Host-to-host or gateway-to-gateway under the same 82 controller . . . . . . . . . . . . . . . . . . . . . . . 21 83 7.2. Host-to-host or gateway-to-gateway under different 84 security controllers . . . . . . . . . . . . . . . . . . 23 85 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 86 8.1. IKE case . . . . . . . . . . . . . . . . . . . . . . . . 26 87 8.2. IKE-less case . . . . . . . . . . . . . . . . . . . . . . 26 88 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 89 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 90 10.1. Normative References . . . . . . . . . . . . . . . . . . 27 91 10.2. Informative References . . . . . . . . . . . . . . . . . 28 92 Appendix A. Appendix A: Common YANG model for IKE and IKEless 93 cases . . . . . . . . . . . . . . . . . . . . . . . 31 94 Appendix B. Appendix B: YANG model for IKE case . . . . . . . . 37 95 Appendix C. Appendix C: YANG model for IKE-less case . . . . . . 43 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 98 1. Introduction 100 Software-Defined Networking (SDN) is an architecture that enables 101 users to directly program, orchestrate, control and manage network 102 resources through software. SDN paradigm relocates the control of 103 network resources to a dedicated network element, namely SDN 104 controller. The SDN controller manages and configures the 105 distributed network resources and provides an abstracted view of the 106 network resources to the SDN applications. The SDN application can 107 customize and automate the operations (including management) of the 108 abstracted network resources in a programmable manner via this 109 interface [RFC7149][ITU-T.Y.3300] 110 [ONF-SDN-Architecture][ONF-OpenFlow]. 112 Recently, several network scenarios are considering a centralized way 113 of managing different security aspects. For example, Software- 114 Defined WANs (SD-WAN) advocates to manage IPsec SAs from a 115 centralized point. Therefore, with the growth of SDN-based scenarios 116 where network resources are deployed in an autonomous manner, a 117 mechanism to manage IPsec SAs according to the SDN architecture 118 becomes more relevant. Thus, the SDN-based service described in this 119 document will autonomously deal with IPsec SAs management following a 120 SDN paradigm. 122 An example of usage can be the notion of Software Defined WAN (SD- 123 WAN), SDN extension providing a software abstraction to create secure 124 network overlays over traditional WAN and branch networks. SD-WAN is 125 based on IPsec as underlying security protocol and aims to provide 126 flexible, automated, fast deployment and on-demand security network 127 services. 129 IPsec architecture [RFC4301] defines a clear separation between the 130 processing to provide security services to IP packets and the key 131 management procedures to establish the IPsec security associations. 132 In this document, we define a service where the key management 133 procedures can be carried by an external entity: the Security 134 Controller. 136 First, this document exposes the requirements to support the 137 protection of data flows using IPsec [RFC4301]. We have considered 138 two general cases: 140 1) IKE case. The Network Security Function (NSF) implements the 141 Internet Key Exchange (IKE) protocol and the IPsec databases: the 142 Security Policy Database (SPD), the Security Association Database 143 (SAD) and the Peer Authorization Database (PAD). The Security 144 Controller is in charge of provisioning the NSF with the required 145 information to IKE, the SPD and the PAD. 147 2) IKE-less case. The NSF only implements the IPsec databases (no 148 IKE implementation). The Security Controller will provide the 149 required parameters to create valid entries in the SPD and the 150 SAD into the NSF. Therefore, the NSF will have only support for 151 IPsec while automated key management functionality is moved to 152 the controller. 154 In both cases, an interface/protocol is required to carry out this 155 provisioning in a secure manner between the Security Controller and 156 the NSF. In particular, IKE case requires the provision of SPD and 157 PAD entries and the IKE credential and information related with the 158 IKE negotiation (e.g. IKE_SA_INIT), and IKE-less case requires the 159 management of SPD and SAD entries. Based on YANG models in 160 [netconf-vpn] and [I-D.tran-ipsecme-yang], RFC 4301 [RFC4301] and RFC 161 7296 [RFC7296] this document defines the required interfaces with a 162 YANG model for configuration and state data for IKE, PAD, SPD and SAD 163 (see Appendix A, Appendix B and Appendix C). 165 This document considers two typical scenarios to manage autonomously 166 IPsec SAs: gateway-to-gateway and host-to-host [RFC6071]. The 167 analysis of the host-to-gateway (roadwarrior) scenario is out of 168 scope of this document. In these cases, host or gateways or both may 169 act as NSFs. Finally, it also discusses the situation where two NSFs 170 are under the control of two different Security Controllers. 172 NOTE: This work pays attention to the challenge "Lack of Mechanism 173 for Dynamic Key Distribution to NSFs" defined in [RFC8192] in the 174 particular case of the establishment and management of IPsec SAs. In 175 fact, this I-D could be considered as a proper use case for this 176 particular challenge in [RFC8192]. 178 2. Requirements Language 180 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 181 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 182 document are to be interpreted as described in RFC 2119 [RFC2119]. 183 When these words appear in lower case, they have their natural 184 language meaning. 186 3. Terminology 188 This document uses the terminology described in [RFC7149], [RFC4301], 189 [ITU-T.Y.3300], [ONF-SDN-Architecture], [ONF-OpenFlow], 191 [ITU-T.X.1252], [ITU-T.X.800] and [I-D.ietf-i2nsf-terminology]. In 192 addition, the following terms are defined below: 194 o Software-Defined Networking. A set of techniques enabling to 195 directly program, orchestrate, control, and manage network 196 resources, which facilitates the design, delivery and operation of 197 network services in a dynamic and scalable manner [ITU-T.Y.3300]. 199 o Flow/Data Flow. Set of network packets sharing a set of 200 characteristics, for example IP dst/src values or QoS parameters. 202 o Security Controller. A Controller is a management component that 203 contains control plane functions to manage and facilitate 204 information sharing, as well as execute security functions. In 205 the context of this document, it provides IPsec management 206 information. 208 o Network Security Function (NSF). Software that provides a set of 209 security-related services. 211 o Flow-based NSF. A NSF that inspects network flows according to a 212 set of policies intended for enforcing security properties. The 213 NSFs considered in this document falls into this classification. 215 o Flow-based Protection Policy. The set of rules defining the 216 conditions under which a data flow MUST be protected with IPsec, 217 and the rules that MUST be applied to the specific flow. 219 o Internet Key Exchange (IKE) v2 Protocol to establish IPsec 220 Security Associations (SAs). It requires information about the 221 required authentication method (i.e. raw RSA/ECDSA keys or X.509 222 certificates), DH groups, modes and algorithms for IKE SA 223 negotiation, etc. 225 o Security Policy Database (SPD). It includes information about 226 IPsec policies direction (in, out), local and remote addresses, 227 inbound and outboud SAs, etc. 229 o Security Associations Database (SAD). It includes information 230 about IPsec SAs, such as SPI, destination addresses, 231 authentication and encryption algorithms and keys to protect IP 232 flows. 234 o Peer Authorization Database (PAD). It provides the link between 235 the SPD and a security association management protocol such as IKE 236 or the SDN-based solution described in this document. 238 4. Objectives 240 o To describe the architecture for the SDN-based IPsec management, 241 which implements a security service to allow the establishment and 242 management of IPsec security associations from a central point, in 243 order to protect specific data flows. 245 o To define the interfaces required to manage and monitor the IPsec 246 Security Associations in the NSF from a Security Controller. YANG 247 models are defined for configuration and state data for IPsec 248 management. 250 5. SDN-based IPsec management description 252 As mentioned in Section 1, two cases are considered: 254 5.1. IKE case: IKE/IPsec in the NSF 256 In this case the NSF ships an IKEv2 implementation besides the IPsec 257 support. The Security Controller is in charge of managing and 258 applying SPD and PAD entries (deriving and delivering IKE Credentials 259 such as a pre-shared key, certificates, etc.), and applying other IKE 260 configuration parameters (e.g. IKE_SA_INIT algorithms) to the NSF 261 for the IKE negotiation. 263 With these entries, the IKEv2 implementation can operate to establish 264 the IPsec SAs. The application (administrator) establishes the IPsec 265 requirements and information about the end points information 266 (through the Client Facing Interface, [RFC8192]), and the Security 267 Controller translates those requirements into IKE, SPD and PAD 268 entries that will be installed into the NSF (through the NSF Facing 269 Interface). With that information, the NSF can just run IKEv2 to 270 establish the required IPsec SA (when the data flow needs 271 protection). Figure 1 shows the different layers and corresponding 272 functionality. 274 +-------------------------------------------+ 275 |IPsec Management/Orchestration Application | Client or 276 | I2NSF Client | App Gateway 277 +-------------------------------------------+ 278 | Client Facing Interface 279 +-------------------------------------------+ 280 Vendor | Application Support | 281 Facing<->|-------------------------------------------| Security 282 Interface| IKE Credential,PAD and SPD entries Distr. | Controller 283 +-------------------------------------------+ 284 | NSF Facing Interface 285 +-------------------------------------------+ 286 | I2NSF Agent | 287 |-------------------------------------------| Network 288 | IKE | IPsec(SPD,PAD) | Security 289 |-------------------------------------------| Function 290 | Data Protection and Forwarding | 291 +-------------------------------------------+ 293 Figure 1: IKE case: IKE/IPsec in the NSF 295 5.1.1. Interface Requirements for IKE case 297 SDN-based IPsec flow protection services provide dynamic and flexible 298 management of IPsec SAs in flow-based NSF. In order to support this 299 capability in case IKE case, the following interface requirements are 300 to be met: 302 o A YANG data model for configuration data for IKEv2, SPD and PAD. 304 o A YANG data model for state data for IKE, PAD, SPD and SAD (NOTE: 305 the SAD entries are created in runtime by IKEv2.) 307 o In scenarios where multiple controllers are implicated, SDN-based 308 IPsec management services may require a mechanism to discover 309 which Security Controller is managing a specific NSF. Moreover, 310 an east-west interface [RFC7426] is required to exchange IPsec- 311 related information. For example, if two gateways need to 312 establish an IPsec SA and both are under the control of two 313 different controllers then both Security Controllers need to 314 exchange information to properly configure their own gateways. 315 That is, the may need to agree on whether IKEv2 authentication 316 will be based on raw public keys or pre-shared keys. In case of 317 using pre-shared keys they will have to agree in the PSK. 319 5.2. IKE-less case: IPsec (no IKEv2) in the NSF 321 In this case, the NSF does not deploy IKEv2 and, therefore, the 322 Security Controller has to perform the IKE security functions and 323 management of IPsec SAs by populating and managing the SPD and the 324 SAD. 326 +-----------------------------------------+ 327 | IPsec Management Application | Client or 328 | I2NSF Client | App Gateway 329 +-----------------------------------------+ 330 | Client Facing Interface 331 +-----------------------------------------+ 332 Vendor| Application Support | 333 Facing<->|-----------------------------------------| Security 334 Interface| SPD, SAD and PAD Entries Distr. | Controller 335 +-----------------------------------------+ 336 | NSF Facing Interface 337 +-----------------------------------------+ 338 | I2NSF Agent | Network 339 |-----------------------------------------| Security 340 | IPsec (SPD,SAD) | Function (NSF) 341 |-----------------------------------------| 342 | Data Protection and Forwarding | 343 +-----------------------------------------+ 345 Figure 2: IKE-less case: IPsec (no IKE) in the NSF 347 As shown in Figure 2, applications for flow protection run on the top 348 of the Security Controller. When an administrator enforces flow- 349 based protection policies through the Client Facing Interface, the 350 Security Controller translates those requirements into SPD and SAD 351 entries, which are installed in the NSF. PAD entries are not 352 required since there is no IKEv2 in the NSF. 354 5.2.1. Interface Requirements for IKE-less case 356 In order to support the IKE-less case, the following requirements are 357 to be met: 359 o A YANG data model for configuration data for SPD and SAD. 361 o A YANG data model for state data for SPD and SAD. 363 o In scenarios where multiple controllers are implicated, SDN-based 364 IPsec management services may require a mechanism to discover 365 which Security Controller is managing a specific NSF. Moreover, 366 an east-west interface [RFC7426] is required to exchange IPsec- 367 related information. NOTE: A possible east-west protocol for this 368 IKE-less case could be IKEv2. However, this needs to be explore 369 since the IKEv2 peers would be the Security Controllers. 371 Specifically, the IKE-less case assumes that the SDN controller has 372 to perform some security functions that IKEv2 typically does, namely 373 (non-exhaustive): 375 o IV generation. 377 o prevent counter resets for same key. 379 o Generation of pseudo-random cryptographic keys for the IPsec SAs. 381 o Rekey of the IPsec SAs based on notification from the NSF (i.e. 382 expire). 384 o Generation of the IPsec SAs when required based on notifications 385 (i.e. sadb_acquire). 387 o NAT Traversal discovery and management. 389 Additionally to these functions, another set of tasks must be 390 performed by the Controller (non-exhaustive list): 392 o SPI random generation. 394 o Cryptographic algorithm/s selection. 396 o Usage of extended sequence numbers. 398 o Establishment of proper traffic selectors. 400 5.3. IKE case vs IKE-less case 402 IKE case MAY be easier to deploy than IKE-less case because current 403 gateways typically have an IKEv2/IPsec implementation. Moreover 404 hosts can install easily an IKE implementation. As downside, the NSF 405 needs more resources to hold IKEv2. Moreover, the IKEv2 406 implementation needs to implement an interface so that the I2NSF 407 Agent can interact with them. 409 Alternatively, IKE-less case allows lighter NSFs (no IKEv2 410 implementation), which benefits the deployment in constrained NSFs. 411 Moreover, IKEv2 does not need to be performed in gateway-to-gateway 412 and host-to-host scenarios under the same Security Controller (see 413 Section 7.1). On the contrary, the overload of creating fresh IPsec 414 SAs is shifted to the Security Controller since IKEv2 is not in the 415 NSF. As a consequence, this may result in a more complex 416 implementation in the controller side. This overload may create some 417 scalability issues when the number of NSFs is high. 419 In general, literature around SDN-based network management using a 420 centralized SDN controller is aware about scalability issues and 421 solutions have been already provided (e.g. hierarchical SDN 422 controllers; having multiple replicated SDN controllers, etc). In 423 the context of IPsec management, one straight way to reduce the 424 overhead and the potential scalability issue in the Security 425 Controller is to apply IKE case, described in this document, since 426 the IPsec SAs are managed between NSFs without the involvement of the 427 Security Controller at all, except by the initial IKE configuration 428 provided by the Security Controller. Other option with IKE-less is 429 to use techniques already seen in SDN world such as, for example, 430 hierarchical SDN controllers. Other solutions, such as Controller- 431 IKE [I-D.carrel-ipsecme-controller-ike], have proposed that NSFs 432 provide their DH public keys to the Security Controller, so that the 433 Security Controller distributes all public keys to all peers. All 434 peers can calculate a unique pairwise secret for each other peer and 435 there is no inter-NSF messages. A re-key mechanism is further 436 described in [I-D.carrel-ipsecme-controller-ike]. 438 In terms of security, IKE case provides better security properties 439 than IKE-less case, as we discuss in section Section 8. The main 440 reason is that the Security Controller is not able to observe any 441 session keys generated for the IPsec SAs because IKEv2 is in charge 442 of negotiating the IPsec SAs. 444 5.3.1. Rekeying process 446 For IKE case, the rekeying process is carried out by IKEv2, following 447 the information defined in the SPD and SAD. 449 For IKE-less case, the Security Controller needs to take care of the 450 rekeying process. When the IPsec SA is going to expire (e.g. IPsec 451 SA soft lifetime), it has to create a new IPsec SA and remove the old 452 one. This rekeying process starts when the Security Controller 453 receives a sadb_expire notification or it decides so, based on 454 lifetime state data obtained from the NSF. 456 To explain the rekeying process between two IPsec peers A and B, let 457 assume that SPIa1 identifies the inbound SA in A and SPIb1 the 458 inbound SA in B. 460 1. The Security Controller chooses two random values as SPI for the 461 new inbound SAs: for example, SPIa2 for A and SPIb2 for B. These 462 numbers MUST not be in conflict with any IPsec SA in A or B. 464 Then, the Security Controller creates an inbound SA with SPIa2 in 465 A and another inbound SA in B with SPIb2. It can send this 466 information simultaneously to A and B. 468 2. Once the Security Controller receives confirmation from A and B, 469 inbound SA are correctly installed. Then it proceeds to send in 470 parallel to A and B the outbound SAs: it sends the outbound SA to 471 A with SPIb2 and the outbound SA to B with SPIa2. At this point 472 the new IPsec SA is ready. 474 3. Once the Security Controller receives confirmation from A and B, 475 that the outbound SAs have been installed, the Security 476 Controller deletes the old IPsec SAs from A (inbound SPIa1 and 477 outbound SPIb1) and B (outbound SPIa1 and inbound SPIb1) in 478 parallel. It is worth noting that if the IPsec implementation 479 can itself detect traffic on the new IPsec SA, and it can delete 480 the old IPsec SA itself without instruction from the Security 481 Controller, then this step 3 is not required. 483 5.3.2. NSF state loss 485 If one of the NSF restarts, it will lose the IPsec state (affected 486 NSF). By default, the Security Controller can assume that all the 487 state has been lost and therefore it will have to send IKEv2, SPD and 488 PAD information to the NSF in IKE case, and SPD and SAD information 489 in IKE-less case. 491 In both cases, the Security Controller is aware of the affected NSF 492 (e.g. the NETCONF/TCP connection is broken with the affected NSF, the 493 Security Controller is receiving sadb_bad-spi notification from a 494 particular NSF, etc.). Moreover, the Security Controller has a 495 register about all the NSFs that have IPsec SAs with the affected 496 NSF. Therefore, it knows the affected IPsec SAs. 498 In IKE case, the Security Controller will configure the affected NSF 499 with the new IKEv2, SPD and PAD information. It has also to send new 500 parameters (e.g. a new fresh PSK for authentication) to the NSFs 501 which have IKEv2 SAs and IPsec SAs with the affected NSF. It can 502 also instruct the affected NSF to send IKEv2 INITIAL_CONTACT. 503 Finally, the Security Controller will instruct the affected NSF to 504 start the IKEv2 negotiation with the new configuration. 506 In IKE-less case, if the Security Controller detects that a NSF has 507 lost the IPsec SAs (e.g. it reboots) it will delete the old IPsec SAs 508 of the non-failed nodes established with the failed node (step 1). 509 This prevents the non-failed nodes from leaking plaintext. If the 510 failed node comes to live, the Security Controller will configure the 511 new inbound IPsec SAs between the failed node and all the nodes the 512 failed was talking to (step 2). After these inbound IPsec SAs have 513 been established, the Security Controller can configure the outbound 514 IPsec SAs (step 3). 516 Nevertheless other more optimized options can be considered (e.g. 517 making IKEv2 configuration permanent between reboots). 519 5.3.3. NAT Traversal 521 In IKE case, IKEv2 already owns a mechanism to detect whether some of 522 the peers or both are located behind a NAT. If there is a NAT 523 network configured between two peers, it is required to activate the 524 usage of UDP or TCP/TLS encapsulation of ESP packets ([RFC3948], 525 [RFC8229]). Note that the usage of TRANSPORT mode when NAT is 526 required is forbidden in this specification. 528 On the contrary, IKE-less case does not have any protocol in the NSFs 529 to detect whether they are located behind a NAT or not. However, the 530 SDN paradigm generally assumes the Security Controller has a view of 531 the network it controls. This view is built either requesting 532 information to the NSFs under its control, or because these NSFs 533 inform to the Security Controller. Based on this information, the 534 Security Controller can guess if there is a NAT configured between 535 two hosts, and apply the required policies to both NSFs besides 536 activating the usage of UDP or TCP/TLS encapsulation of ESP packets 537 ([RFC3948], [RFC8229]). 539 For example, the Security Controller could directly request the NSF 540 for specific data such as networking configuration, NAT support, etc. 541 Protocols such as NETCONF or SNMP can be used here. For example, RFC 542 7317 [RFC7317] provides a YANG data model for system management or 543 [I-D.ietf-opsawg-nat-yang] a data model for NAT management. The 544 Security Controller can use this NETCONF module with a gateway to 545 collect NAT information or even configure a NAT. In any case, if 546 this NETCONF module is not available and the Security Controller 547 cannot know if a host is behind a NAT or not, then IKE case should be 548 the right choice and not the IKE-less. 550 6. YANG configuration data models 552 In order to support IKE case and IKE-less case we have modelled the 553 different parameters and values that must be configured to manage 554 IPsec SAs. Specifically, IKE requires modeling IKEv2, SPD and PAD 555 while IKE-less case requires configuration models for the SPD and 556 SAD. We have defined three models: ietf-ipsec-common (Appendix A), 557 ietf-ipsec-ike (Appendix B, IKE case), ietf-ipsec-ikeless 558 (Appendix C, IKE-less case). Since the model ietf-ipsec-common has 559 only typedef and groupings common to the other modules, in the 560 following we only show a simplified view of the ietf-ipsec-ike and 561 ietf-ipsec-ikeless models. 563 6.1. IKE case model 565 The model related to IKEv2 has been extracted from reading IKEv2 566 standard in [RFC7296], and observing some open source 567 implementations, such as Strongswan or Libreswan. 569 The definition of the PAD model has been extracted from the 570 specification in section 4.4.3 in [RFC4301] (NOTE: We have observed 571 that many implementations integrate PAD configuration as part of the 572 IKEv2 configuration.) 574 module: ietf-ipsec-ike 575 +--rw ikev2 576 +--rw pad 577 | +--rw pad-entry* [pad-entry-id] 578 | +--rw pad-entry-id uint64 579 | +--rw (identity)? 580 | | +--:(ipv4-address) 581 | | | +--rw ipv4-address? inet:ipv4-address 582 | | +--:(ipv6-address) 583 | | | +--rw ipv6-address? inet:ipv6-address 584 | | +--:(fqdn-string) 585 | | | +--rw fqdn-string? inet:domain-name 586 | | +--:(rfc822-address-string) 587 | | | +--rw rfc822-address-string? string 588 | | +--:(dnX509) 589 | | | +--rw dnX509? string 590 | | +--:(id_key) 591 | | | +--rw id_key? string 592 | | +--:(id_null) 593 | | | +--rw id_null? empty 594 | | +--:(user_fqdn) 595 | | +--rw user_fqdn? string 596 | +--rw my-identifier string 597 | +--rw pad-auth-protocol? auth-protocol-type 598 | +--rw auth-method 599 | +--rw auth-m? auth-method-type 600 | +--rw eap-method 601 | | +--rw eap-type? uint8 602 | +--rw pre-shared 603 | | +--rw secret? yang:hex-string 604 | +--rw digital-signature 605 | +--rw ds-algorithm? signature-algorithm-t 606 | +--rw raw-public-key? yang:hex-string 607 | +--rw key-data? string 608 | +--rw key-file? string 609 | +--rw ca-data* string 610 | +--rw ca-file? string 611 | +--rw cert-data? string 612 | +--rw cert-file? string 613 | +--rw crl-data? string 614 | +--rw crl-file? string 615 | +--rw oscp-uri? inet:uri 616 +--rw ike-conn-entry* [conn-name] 617 | +--rw conn-name string 618 | +--rw autostartup type-autostartup 619 | +--rw initial-contact? boolean 620 | +--rw version? enumeration 621 | +--rw ike-fragmentation? boolean 622 | +--rw ike-sa-lifetime-hard 623 | | +--rw time? yang:timestamp 624 | | +--rw idle? yang:timestamp 625 | | +--rw bytes? uint32 626 | | +--rw packets? uint32 627 | +--rw ike-sa-lifetime-soft 628 | | +--rw time? yang:timestamp 629 | | +--rw idle? yang:timestamp 630 | | +--rw bytes? uint32 631 | | +--rw packets? uint32 632 | | +--rw action? ic:lifetime-action 633 | +--rw ike-sa-authalg* ic:integrity-algorithm-t 634 | +--rw ike-sa-encalg* ic:encryption-algorithm-t 635 | +--rw dh_group uint32 636 | +--rw half-open-ike-sa-timer? uint32 637 | +--rw half-open-ike-sa-cookie-threshold? uint32 638 | +--rw local 639 | | +--rw local-pad-id? uint64 640 | +--rw remote 641 | | +--rw remote-pad-id? uint64 642 | +--rw espencap? esp-encap 643 | +--rw sport? inet:port-number 644 | +--rw dport? inet:port-number 645 | +--rw oaddr* inet:ip-address 646 | +--rw spd 647 | | +--rw spd-entry* [spd-entry-id] 648 | | +--rw spd-entry-id uint64 649 | | +--rw priority? uint32 650 | | +--rw anti-replay-window? uint16 651 | | +--rw names* [name] 652 | | | +--rw name-type? ipsec-spd-name 653 | | | +--rw name string 654 | | +--rw condition 655 | | | +--rw traffic-selector-list* [ts-number] 656 | | | +--rw ts-number uint32 657 | | | +--rw direction? ipsec-traffic-direction 658 | | | +--rw local-subnet? inet:ip-prefix 659 | | | +--rw remote-subnet? inet:ip-prefix 660 | | | +--rw upper-layer-protocol* ipsec-upper-layer-proto 661 | | | +--rw local-ports* [start end] 662 | | | | +--rw start inet:port-number 663 | | | | +--rw end inet:port-number 664 | | | +--rw remote-ports* [start end] 665 | | | +--rw start inet:port-number 666 | | | +--rw end inet:port-number 667 | | +--rw processing-info 668 | | | +--rw action ipsec-spd-operation 669 | | | +--rw ipsec-sa-cfg 670 | | | +--rw pfp-flag? boolean 671 | | | +--rw extSeqNum? boolean 672 | | | +--rw seqOverflow? boolean 673 | | | +--rw statefulfragCheck? boolean 674 | | | +--rw security-protocol? ipsec-protocol 675 | | | +--rw mode? ipsec-mode 676 | | | +--rw ah-algorithms 677 | | | | +--rw ah-algorithm* integrity-algorithm-t 678 | | | | +--rw trunc-length? uint32 679 | | | +--rw esp-algorithms 680 | | | | +--rw authentication* integrity-algorithm-t 681 | | | | +--rw encryption* encryption-algorithm-t 682 | | | | +--rw tfc_pad? uint32 683 | | | +--rw tunnel 684 | | | +--rw local? inet:ip-address 685 | | | +--rw remote? inet:ip-address 686 | | | +--rw bypass-df? boolean 687 | | | +--rw bypass-dscp? boolean 688 | | | +--rw dscp-mapping? yang:hex-string 689 | | | +--rw ecn? boolean 690 | | +--rw spd-lifetime-soft 691 | | | +--rw time? yang:timestamp 692 | | | +--rw idle? yang:timestamp 693 | | | +--rw bytes? uint32 694 | | | +--rw packets? uint32 695 | | | +--rw action? lifetime-action 696 | | +--rw spd-lifetime-hard 697 | | | +--rw time? yang:timestamp 698 | | | +--rw idle? yang:timestamp 699 | | | +--rw bytes? uint32 700 | | | +--rw packets? uint32 701 | | +--ro spd-lifetime-current 702 | | +--ro time? yang:timestamp 703 | | +--ro idle? yang:timestamp 704 | | +--ro bytes? uint32 705 | | +--ro packets? uint32 706 | +--ro ike-sa-state 707 | +--ro uptime 708 | | +--ro running? yang:date-and-time 709 | | +--ro since? yang:date-and-time 710 | +--ro initiator? boolean 711 | +--ro initiator-ikesa-spi? uint64 712 | +--ro responder-ikesa-spi? uint64 713 | +--ro nat-local? boolean 714 | +--ro nat-remote? boolean 715 | +--ro nat-any? boolean 716 | +--ro espencap? esp-encap 717 | +--ro sport? inet:port-number 718 | +--ro dport? inet:port-number 719 | +--ro oaddr* inet:ip-address 720 | +--ro established? uint64 721 | +--ro rekey-time? uint64 722 | +--ro reauth-time? uint64 723 | +--ro child-sas* [] 724 | +--ro spis 725 | +--ro spi-in? ic:ipsec-spi 726 | +--ro spi-out? ic:ipsec-spi 727 +--ro number-ike-sas 728 +--ro total? uint32 729 +--ro half-open? uint32 730 +--ro half-open-cookies? uint32 732 6.2. IKE-less case model 734 The definition of the SPD model has been mainly extracted from the 735 specification in section 4.4.1 and Appendix D in [RFC4301]. Unlike 736 existing implementations (e.g. XFRM), it is worth mentioning that 737 this model follows [RFC4301] and, consequently, each policy (spd- 738 entry) consists of one or more traffic selectors. 740 The definition of the SAD model has been extracted from the 741 specification in section 4.4.2 in [RFC4301]. Note that this model 742 not only associates an IPsec SA with its corresponding policy (spd- 743 entry-id) but also indicates the specific traffic selector that 744 caused its establishment. In other words, each traffic selector of a 745 policy (spd-entry) generates a different IPsec SA (sad-entry). 747 The notifications model has been defined using as reference the 748 PF_KEYv2 standard in [RFC2367]. 750 module: ietf-ipsec-ikeless 751 +--rw ietf-ipsec 752 +--rw spd 753 | +--rw spd-entry* [spd-entry-id] 754 | +--rw spd-entry-id uint64 755 | +--rw priority? uint32 756 | +--rw anti-replay-window? uint16 757 | +--rw names* [name] 758 | | +--rw name-type? ipsec-spd-name 759 | | +--rw name string 760 | +--rw condition 761 | | +--rw traffic-selector-list* [ts-number] 762 | | +--rw ts-number uint32 763 | | +--rw direction? ipsec-traffic-direction 764 | | +--rw local-subnet? inet:ip-prefix 765 | | +--rw remote-subnet? inet:ip-prefix 766 | | +--rw upper-layer-protocol* ipsec-upper-layer-proto 767 | | +--rw local-ports* [start end] 768 | | | +--rw start inet:port-number 769 | | | +--rw end inet:port-number 770 | | +--rw remote-ports* [start end] 771 | | +--rw start inet:port-number 772 | | +--rw end inet:port-number 773 | +--rw processing-info 774 | | +--rw action ipsec-spd-operation 775 | | +--rw ipsec-sa-cfg 776 | | +--rw pfp-flag? boolean 777 | | +--rw extSeqNum? boolean 778 | | +--rw seqOverflow? boolean 779 | | +--rw statefulfragCheck? boolean 780 | | +--rw security-protocol? ipsec-protocol 781 | | +--rw mode? ipsec-mode 782 | | +--rw ah-algorithms 783 | | | +--rw ah-algorithm* integrity-algorithm-t 784 | | | +--rw trunc-length? uint32 785 | | +--rw esp-algorithms 786 | | | +--rw authentication* integrity-algorithm-t 787 | | | +--rw encryption* encryption-algorithm-t 788 | | | +--rw tfc_pad? uint32 789 | | +--rw tunnel 790 | | +--rw local? inet:ip-address 791 | | +--rw remote? inet:ip-address 792 | | +--rw bypass-df? boolean 793 | | +--rw bypass-dscp? boolean 794 | | +--rw dscp-mapping? yang:hex-string 795 | | +--rw ecn? boolean 796 | +--rw spd-lifetime-soft 797 | | +--rw time? yang:timestamp 798 | | +--rw idle? yang:timestamp 799 | | +--rw bytes? uint32 800 | | +--rw packets? uint32 801 | | +--rw action? lifetime-action 802 | +--rw spd-lifetime-hard 803 | | +--rw time? yang:timestamp 804 | | +--rw idle? yang:timestamp 805 | | +--rw bytes? uint32 806 | | +--rw packets? uint32 807 | +--ro spd-lifetime-current 808 | +--ro time? yang:timestamp 809 | +--ro idle? yang:timestamp 810 | +--ro bytes? uint32 811 | +--ro packets? uint32 812 +--rw sad 813 +--rw sad-entry* [sad-entry-id] 814 +--rw sad-entry-id uint64 815 +--rw spi? ic:ipsec-spi 816 +--rw seq-number? uint64 817 +--rw seq-number-overflow-flag? boolean 818 +--rw anti-replay-window? uint16 819 +--rw spd-entry-id? uint64 820 +--rw local-subnet? inet:ip-prefix 821 +--rw remote-subnet? inet:ip-prefix 822 +--rw upper-layer-protocol* ipsec-upper-layer-proto 823 +--rw local-ports* [start end] 824 | +--rw start inet:port-number 825 | +--rw end inet:port-number 826 +--rw remote-ports* [start end] 827 | +--rw start inet:port-number 828 | +--rw end inet:port-number 829 +--rw security-protocol? ic:ipsec-protocol 830 +--rw sad-lifetime-hard 831 | +--rw time? yang:timestamp 832 | +--rw idle? yang:timestamp 833 | +--rw bytes? uint32 834 | +--rw packets? uint32 835 +--rw sad-lifetime-soft 836 | +--rw time? yang:timestamp 837 | +--rw idle? yang:timestamp 838 | +--rw bytes? uint32 839 | +--rw packets? uint32 840 | +--rw action? ic:lifetime-action 841 +--rw mode? ic:ipsec-mode 842 +--rw statefulfragCheck? boolean 843 +--rw dscp? yang:hex-string 844 +--rw path-mtu? uint16 845 +--rw tunnel 846 | +--rw local? inet:ip-address 847 | +--rw remote? inet:ip-address 848 | +--rw bypass-df? boolean 849 | +--rw bypass-dscp? boolean 850 | +--rw dscp-mapping? yang:hex-string 851 | +--rw ecn? boolean 852 +--rw espencap? esp-encap 853 +--rw sport? inet:port-number 854 +--rw dport? inet:port-number 855 +--rw oaddr* inet:ip-address 856 +--ro sad-lifetime-current 857 | +--ro time? yang:timestamp 858 | +--ro idle? yang:timestamp 859 | +--ro bytes? uint32 860 | +--ro packets? uint32 861 +--ro stats 862 | +--ro replay-window? uint32 863 | +--ro replay? uint32 864 | +--ro failed? uint32 865 +--ro replay_state 866 | +--ro seq? uint32 867 | +--ro oseq? uint32 868 | +--ro bitmap? uint32 869 +--ro replay_state_esn 870 | +--ro bmp-len? uint32 871 | +--ro oseq? uint32 872 | +--ro oseq-hi? uint32 873 | +--ro seq-hi? uint32 874 | +--ro replay-window? uint32 875 | +--ro bmp* uint32 876 +--rw ah-sa 877 | +--rw integrity 878 | +--rw integrity-algorithm? ic:integrity-algorithm-t 879 | +--rw key? string 880 +--rw esp-sa 881 +--rw encryption 882 | +--rw encryption-algorithm? ic:encryption-algorithm-t 883 | +--rw key? yang:hex-string 884 | +--rw iv? yang:hex-string 885 +--rw integrity 886 | +--rw integrity-algorithm? ic:integrity-algorithm-t 887 | +--rw key? yang:hex-string 888 +--rw combined-enc-intr? boolean 890 notifications: 891 +---n spdb_expire 892 | +--ro index? uint64 893 +---n sadb_acquire 894 | +--ro base-list* [version] 895 | | +--ro version string 896 | | +--ro msg_type? sadb-msg-type 897 | | +--ro msg_satype? sadb-msg-satype 898 | | +--ro msg_seq? uint32 899 | +--ro local-subnet? inet:ip-prefix 900 | +--ro remote-subnet? inet:ip-prefix 901 | +--ro upper-layer-protocol* ipsec-upper-layer-proto 902 | +--ro local-ports* [start end] 903 | | +--ro start inet:port-number 904 | | +--ro end inet:port-number 905 | +--ro remote-ports* [start end] 906 | +--ro start inet:port-number 907 | +--ro end inet:port-number 908 +---n sadb_expire 909 | +--ro base-list* [version] 910 | | +--ro version string 911 | | +--ro msg_type? sadb-msg-type 912 | | +--ro msg_satype? sadb-msg-satype 913 | | +--ro msg_seq? uint32 914 | +--ro spi? ic:ipsec-spi 915 | +--ro anti-replay-window? uint16 916 | +--ro encryption-algorithm? ic:encryption-algorithm-t 917 | +--ro authentication-algorithm? ic:integrity-algorithm-t 918 | +--ro sad-lifetime-hard 919 | | +--ro time? yang:timestamp 920 | | +--ro idle? yang:timestamp 921 | | +--ro bytes? uint32 922 | | +--ro packets? uint32 923 | +--ro sad-lifetime-soft 924 | | +--ro time? yang:timestamp 925 | | +--ro idle? yang:timestamp 926 | | +--ro bytes? uint32 927 | | +--ro packets? uint32 928 | +--ro sad-lifetime-current 929 | +--ro time? yang:timestamp 930 | +--ro idle? yang:timestamp 931 | +--ro bytes? uint32 932 | +--ro packets? uint32 933 +---n sadb_bad-spi 934 +--ro state ic:ipsec-spi 936 7. Use cases examples 938 This section explains how different traditional configurations, that 939 is, host-to-host and gateway-to-gateway are deployed using this SDN- 940 based IPsec management service. In turn, these configurations will 941 be typical in modern networks where, for example, virtualization will 942 be key. 944 7.1. Host-to-host or gateway-to-gateway under the same controller 946 +----------------------------------------+ 947 | Security Controller | 948 | | 949 (1)| +--------------+ (2)+--------------+ | 950 Flow-based ------> |Translate into|--->| South. Prot. | | 951 Security. Pol. | |IPsec Policies| | | | 952 | +--------------+ +--------------+ | 953 | | | | 954 | | | | 955 +--------------------------|-----|-------+ 956 | | 957 | (3) | 958 |-------------------------+ +---| 959 V V 960 +----------------------+ +----------------------+ 961 | NSF1 |<=======>| NSF2 | 962 |IKEv2/IPsec(SPD/PAD) | |IKEv2/IPsec(SPD/PAD) | 963 +----------------------+ (4) +----------------------+ 965 Figure 3: Host-to-host / gateway-to-gateway single controller flow 966 for the IKE case. 968 Figure 3 describes the case IKE case: 970 1. The administrator defines general flow-based security policies. 971 The Security Controller looks for the NSFs involved (NSF1 and 972 NSF2). 974 2. The Security Controller generates IKEv2 credentials for them and 975 translates the policies into SPD and PAD entries. 977 3. The Security Controller inserts the SPD and PAD entries in both 978 NSF1 and NSF2. 980 4. The flow is protected with the IPsec SA established with IKEv2. 982 +----------------------------------------+ 983 | (1) Security Controller | 984 Flow-based | | 985 Security -----------| | 986 Policy | V | 987 | +---------------+ (2)+-------------+ | 988 | |Translate into |--->| South. Prot.| | 989 | |IPsec policies | | | | 990 | +---------------+ +-------------+ | 991 | | | | 992 | | | | 993 +-------------------------| --- |--------+ 994 | | 995 | (3) | 996 |----------------------+ +--| 997 V V 998 +------------------+ +------------------+ 999 | NSF1 |<=====>| NSF2 | 1000 |IPsec(SPD/SAD) | 4) |IPsec(SPD/SAD) | 1001 +------------------+ +------------------+ 1003 Figure 4: Host-to-host / gateway-to-gateway single controller flow 1004 for IKE-less case. 1006 In IKE-less case, flow-based security policies defined by the 1007 administrator are translated into IPsec SPD entries and inserted into 1008 the corresponding NSFs. Besides, fresh SAD entries will be also 1009 generated by the Security Controller and enforced in the NSFs. In 1010 this case, the controller does not run any IKEv2 implementation, and 1011 it provides the cryptographic material for the IPsec SAs. These keys 1012 will be also distributed securely through the southbound interface. 1013 Note that this is possible because both NSFs are managed by the same 1014 controller. 1016 Figure 4 describes the IKE-less, when a data packet needs to be 1017 protected in the path between the NSF1 and NSF2: 1019 1. The administrator establishes the flow-based security policies. 1020 The Security Controller looks for the involved NSFs. 1022 2. The Security Controller translates the flow-based security 1023 policies into IPsec SPD and SAD entries. 1025 3. The Security Controller inserts the these entries in both NSF1 1026 and NSF2 IPsec databases. It associates a lifetime to the IPsec 1027 SAs. When this lifetime expires, the NSF will send a sadb_expire 1028 notification to the Security Controller in order to start the 1029 rekeying process. 1031 4. The flow is protected with the IPsec SA established by the 1032 Security Controller. 1034 Both NSFs could be two hosts that exchange traffic and require to 1035 establish an end-to-end security association to protect their 1036 communications (host-to-host) or two gateways (gateway-to-gateway), 1037 for example, within an enterprise that needs to protect the traffic 1038 between, for example, the networks of two branch offices. 1040 Applicability of these configurations appear in current and new 1041 networking scenarios. For example, SD-WAN technologies are providing 1042 dynamic and on-demand VPN connections between branch offices, or 1043 between branches and SaaS cloud services. Beside, IaaS services 1044 providing virtualization environments are deployments solutions based 1045 on IPsec to provide secure channels between virtual instances (host- 1046 to-host) and providing VPN solutions for virtualized networks 1047 (gateway-to-gateway). 1049 In general (for IKE and IKE-less case), this system has various 1050 advantages: 1052 1. It allows to create IPsec SAs among two NSFs, with only the 1053 application of more general flow-based security policies at the 1054 application layer. Thus, administrators can manage all security 1055 associations in a centralized point with an abstracted view of 1056 the network. 1058 2. All NSFs deployed after the application of the new policies are 1059 NOT manually configured, therefore allowing its deployment in an 1060 automated manner. 1062 7.2. Host-to-host or gateway-to-gateway under different security 1063 controllers 1065 It is also possible that two NSFs (i.e. NSF1 and NSF2) are under the 1066 control of two different Security Controllers. This may happen, for 1067 example, when two organizations, namely Enterprise A and Enterprise 1068 B, have their headquarters interconnected through a WAN connection 1069 and they both have deployed a SDN-based architecture to provide 1070 connectivity to all their clients. 1072 +-------------+ +-------------+ 1073 | | | | 1074 Flow-based| Security |<===============>| Security <--Flow-based 1075 Sec. Pol.--> Controller | (3) | Controller | Sec. Pol. 1076 (1) | A | | B | (2) 1077 +-------------+ +-------------+ 1078 | | 1079 | (4) (4) | 1080 V V 1081 +----------------------+ +----------------------+ 1082 | NSF1 |<========>| NSF2 | 1083 |IKEv2/IPsec(SPD/PAD) | |IKEv2/IPsec(SPD/PAD) | 1084 +----------------------+ (5) +----------------------+ 1086 Figure 5: Different security controllers in IKE case 1088 Figure 5 describes IKE case when two security controllers are 1089 involved in the process. 1091 1. The A's administrator establishes general Flow-based Security 1092 Policies in Security Controller A. 1094 2. The B's administrator establishes general Flow-based Security 1095 Policies in Security Controller B. 1097 3. The Security Controller A realizes that protection is required 1098 between the NSF1 and NSF2, but the NSF2 is under the control of 1099 another Security Controller (Security Controller B), so it starts 1100 negotiations with the other controller to agree on the IPsec SPD 1101 policies and IKEv2 credentials for their respective NSFs. NOTE: 1102 This may require extensions in the East/West interface. 1104 4. Then, both Security Controllers enforce the IKEv2 credentials and 1105 related parameters and the SPD and PAD entries in their 1106 respective NSFs. 1108 5. The flow is protected with the IPsec SAs established with IKEv2 1109 between both NSFs. 1111 +--------------+ +--------------+ 1112 | | | | 1113 Flow-based. ---> | <--- Flow-based 1114 Prot. | Security |<=================>| Security |Sec. 1115 Pol.(1)| Controller | (3) | Controller |Pol. (2) 1116 | A | | B | 1117 +--------------+ +--------------+ 1118 | | 1119 | (4) (4) | 1120 V V 1121 +------------------+ (5) +------------------+ 1122 | NSF1 |<==============>| NSF2 | 1123 |IPsec(SPD/SAD) | | IPsec(SPD/SAD) | 1124 +------------------+ +------------------+ 1126 Figure 6: Different security controllers in IKE-less case 1128 Figure 5 describes IKE-less case when two security controllers are 1129 involved in the process. 1131 1. The A's administrator establishes general Flow Protection 1132 Policies in Security Controller A. 1134 2. The B's administrator establishes general Flow Protection 1135 Policies in Security Controller B. 1137 3. The Security Controller A realizes that the flow between NSF1 and 1138 NSF2 MUST be protected. Nevertheless, the controller notices 1139 that NSF2 is under the control of another Security Controller, so 1140 it starts negotiations with the other controller to agree on the 1141 IPsec SPD and SAD entries that define the IPsec SAs. NOTE: It 1142 would worth evaluating IKEv2 as the protocol for the East/West 1143 interface in this case. 1145 4. Once the Security Controllers have agreed on key material and the 1146 details of the IPsec SAs, they both enforce this information into 1147 their respective NSFs. 1149 5. The flow is protected with the IPsec SAs established by both 1150 Security Controllers in their respective NSFs. 1152 8. Security Considerations 1154 First of all, this document shares all the security issues of SDN 1155 that are specified in the "Security Considerations" section of 1156 [ITU-T.Y.3300] and [RFC8192]. On the one hand, it is important to 1157 note that there MUST exit a security association between the Security 1158 Controller and the NSFs to protect of the critical information 1159 (cryptographic keys, configuration parameter, etc...) exchanged 1160 between these entities. For example, if NETCONF is used as 1161 southbound protocol between the Security Controller and the NSFs, it 1162 is defined that TLS or SSH security association MUST be established 1163 between both entities. On the other hand, we have divided this 1164 section in two parts to analyze different security considerations for 1165 both cases: NSF with IKEv2 (IKE case) and NSF without IKEv2 (IKE-less 1166 case). In general, the Security Controller, as typically in the SDN 1167 paradigm, is a target for different type of attacks. As a 1168 consequence, the Security Controller is a key entity in the 1169 infrastructure and MUST be protected accordingly. In particular, 1170 according to this document, the Security Controller will handle 1171 cryptographic material so that the attacker may try to access this 1172 information. Although, we can assume this attack will not likely to 1173 happen due to the assumed security measurements to protect the 1174 Security Controller, it deserves some analysis in the hypothetical 1175 the attack occurs. The impact is different depending on the IKE case 1176 or IKE-less case. 1178 8.1. IKE case 1180 In IKE case, the Security Controller sends IKE credentials (PSK, 1181 public/private keys, certificates, etc...) to the NSFs using the 1182 security association between Security Controller and NSFs. The 1183 general recommendation is that the Security Controller SHOULD NEVER 1184 store the IKE credentials after distributing them. Moreover the NSFs 1185 MUST NOT allow the reading of these values once they have been 1186 applied by the Security Controller (i.e. write only operations). One 1187 option is return always the same value (all 0s). If the attacker has 1188 access to the Security Controller during the period of time that key 1189 material is generated, it may access to these values. Since these 1190 values are used during NSF authentication in IKEv2, it may 1191 impersonate the affected NSFs. Several recommendations are 1192 important. If PSK authentication is used in IKEv2, the Security 1193 Controller SHOULD remove the PSK immediately after generating and 1194 distributing it. Moreover, the PSK MUST have a proper length (e.g. 1195 minimu, 128 bit length) and strength. If raw public keys are used, 1196 the Security Controller SHOULD remove the associated private key 1197 immediately after generating and distributing them to the NSFs. If 1198 certificates are used, the NSF may generate the private key and 1199 exports the public key for certification to the Security Controller. 1201 8.2. IKE-less case 1203 In the IKE-less case, the controller sends the IPsec SA information 1204 to the SAD that includes the keys for integrity and encryption (when 1205 ESP is used). That key material are symmetric keys to protect data 1206 traffic. The general recommendation is that the Security Controller 1207 SHOULD NEVER stores the keys after distributing them. Moreover, the 1208 NSFs MUST NOT allow the reading of these values once they have been 1209 applied by the Security Controller (i.e. write only operations). 1210 Nevertheless, if the attacker has access to the Security Controller 1211 during the period of time that key material is generated, it may 1212 access to these values. In other words, it may have access to the 1213 key material used in the distributed IPsec SAs and observe the 1214 traffic between peers. In any case, some escenarios with special 1215 secure environments (e.g. physically isolated data centers) make this 1216 type of attack difficult. Moreover, some scenarios such as IoT 1217 networks with constrained devices, where reducing implementation and 1218 computation overhead is important, can apply IKE-less case as a 1219 tradeoff between security and low overhead at the constrained device, 1220 at the cost of assuming the security impact described above. 1222 9. Acknowledgements 1224 Authors want to thank Paul Wouters, Sowmini Varadhan, David Carrel, 1225 Yoav Nir, Tero Kivinen, Graham Bartlett, Sandeep Kampati, Linda 1226 Dunbar, Carlos J. Bernardos, Alejandro Perez-Mendez, Alejandro Abad- 1227 Carrascosa, Ignacio Martinez and Ruben Ricart for their valuable 1228 comments. 1230 10. References 1232 10.1. Normative References 1234 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1235 Requirement Levels", BCP 14, RFC 2119, 1236 DOI 10.17487/RFC2119, March 1997, 1237 . 1239 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1240 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 1241 December 2005, . 1243 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1244 IANA Considerations Section in RFCs", RFC 5226, 1245 DOI 10.17487/RFC5226, May 2008, 1246 . 1248 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 1249 Kivinen, "Internet Key Exchange Protocol Version 2 1250 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 1251 2014, . 1253 [RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., 1254 and J. Jeong, "Interface to Network Security Functions 1255 (I2NSF): Problem Statement and Use Cases", RFC 8192, 1256 DOI 10.17487/RFC8192, July 2017, 1257 . 1259 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 1260 Kumar, "Framework for Interface to Network Security 1261 Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, 1262 . 1264 10.2. Informative References 1266 [I-D.carrel-ipsecme-controller-ike] 1267 Carrel, D. and B. Weiss, "IPsec Key Exchange using a 1268 Controller", draft-carrel-ipsecme-controller-ike-01 (work 1269 in progress), March 2019. 1271 [I-D.ietf-i2nsf-framework] 1272 Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 1273 Kumar, "Framework for Interface to Network Security 1274 Functions", draft-ietf-i2nsf-framework-10 (work in 1275 progress), November 2017. 1277 [I-D.ietf-i2nsf-problem-and-use-cases] 1278 Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., 1279 and J. Jeong, "I2NSF Problem Statement and Use cases", 1280 draft-ietf-i2nsf-problem-and-use-cases-16 (work in 1281 progress), May 2017. 1283 [I-D.ietf-i2nsf-terminology] 1284 Hares, S., Strassner, J., Lopez, D., Xia, L., and H. 1285 Birkholz, "Interface to Network Security Functions (I2NSF) 1286 Terminology", draft-ietf-i2nsf-terminology-07 (work in 1287 progress), January 2019. 1289 [I-D.ietf-opsawg-nat-yang] 1290 Boucadair, M., Sivakumar, S., Jacquenet, C., Vinapamula, 1291 S., and Q. Wu, "A YANG Module for Network Address 1292 Translation (NAT) and Network Prefix Translation (NPT)", 1293 draft-ietf-opsawg-nat-yang-17 (work in progress), 1294 September 2018. 1296 [I-D.jeong-i2nsf-sdn-security-services-05] 1297 Jeong, J., Kim, H., Park, J., Ahn, T., and S. Lee, 1298 "Software-Defined Networking Based Security Services using 1299 Interface to Network Security Functions", draft-jeong- 1300 i2nsf-sdn-security-services-05 (work in progress), July 1301 2016. 1303 [I-D.pfkey-spd] 1304 Sakane, S., "PF_KEY Extensions for IPsec Policy Management 1305 in KAME Stack", October 2002. 1307 [I-D.tran-ipsecme-yang] 1308 Tran, K., Wang, H., Nagaraj, V., and X. Chen, "Yang Data 1309 Model for Internet Protocol Security (IPsec)", draft-tran- 1310 ipsecme-yang-01 (work in progress), June 2015. 1312 [ITU-T.X.1252] 1313 "Baseline Identity Management Terms and Definitions", 1314 April 2010. 1316 [ITU-T.X.800] 1317 "Security Architecture for Open Systems Interconnection 1318 for CCITT Applications", March 1991. 1320 [ITU-T.Y.3300] 1321 "Recommendation ITU-T Y.3300", June 2014. 1323 [netconf-vpn] 1324 Stefan Wallin, "Tutorial: NETCONF and YANG", January 2014. 1326 [netopeer] 1327 CESNET, CESNET., "NETCONF toolset Netopeer", November 1328 2016. 1330 [ONF-OpenFlow] 1331 ONF, "OpenFlow Switch Specification (Version 1.4.0)", 1332 October 2013. 1334 [ONF-SDN-Architecture] 1335 "SDN Architecture", June 2014. 1337 [RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key 1338 Management API, Version 2", RFC 2367, 1339 DOI 10.17487/RFC2367, July 1998, 1340 . 1342 [RFC3549] Salim, J., Khosravi, H., Kleen, A., and A. Kuznetsov, 1343 "Linux Netlink as an IP Services Protocol", RFC 3549, 1344 DOI 10.17487/RFC3549, July 2003, 1345 . 1347 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 1348 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 1349 RFC 3948, DOI 10.17487/RFC3948, January 2005, 1350 . 1352 [RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and 1353 Internet Key Exchange (IKE) Document Roadmap", RFC 6071, 1354 DOI 10.17487/RFC6071, February 2011, 1355 . 1357 [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined 1358 Networking: A Perspective from within a Service Provider 1359 Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, 1360 . 1362 [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for 1363 System Management", RFC 7317, DOI 10.17487/RFC7317, August 1364 2014, . 1366 [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., 1367 Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- 1368 Defined Networking (SDN): Layers and Architecture 1369 Terminology", RFC 7426, DOI 10.17487/RFC7426, January 1370 2015, . 1372 [RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation 1373 of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229, 1374 August 2017, . 1376 [strongswan] 1377 CESNET, CESNET., "StrongSwan: the OpenSource IPsec-based 1378 VPN Solution", April 2017. 1380 Appendix A. Appendix A: Common YANG model for IKE and IKEless cases 1382 file "ietf-ipsec-common@2019-03-11.yang" 1384 module ietf-ipsec-common{ 1385 yang-version 1.1; 1386 namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec-common"; 1387 prefix "ipsec-common"; 1389 import ietf-inet-types { prefix inet; } 1390 import ietf-yang-types { prefix yang; } 1392 import ietf-crypto-types { 1393 prefix ct; 1394 reference "draft-ietf-netconf-crypto-types-01: Common YANG Dta Types for Cryptography"; 1395 } 1397 organization "IETF I2NSF (Interface to Network Security Functions) Working Group"; 1399 contact 1400 " Rafael Marin Lopez 1401 Dept. Information and Communications Engineering (DIIC) 1402 Faculty of Computer Science-University of Murcia 1403 30100 Murcia - Spain 1404 Telf: +34868888501 1405 e-mail: rafa@um.es 1407 Gabriel Lopez Millan 1408 Dept. Information and Communications Engineering (DIIC) 1409 Faculty of Computer Science-University of Murcia 1410 30100 Murcia - Spain 1411 Tel: +34 868888504 1412 email: gabilm@um.es 1414 Fernando Pereniguez Garcia 1415 Department of Sciences and Informatics 1416 University Defense Center (CUD), Spanish Air Force Academy, MDE-UPCT 1417 30720 San Javier - Spain 1418 Tel: +34 968189946 1419 email: fernando.pereniguez@cud.upct.es 1420 "; 1422 description "Common Data model for SDN-based IPSec configuration."; 1424 revision "2019-03-11" { 1425 description "Revision"; 1426 reference ""; 1427 } 1429 typedef encryption-algorithm-t { 1430 type ct:encryption-algorithm-ref; 1431 description "typedef"; 1432 } 1434 typedef integrity-algorithm-t { 1435 type ct:mac-algorithm-ref; 1436 description 1437 "This typedef enables importing modules to easily define an 1438 identityref to the 'asymmetric-key-encryption-algorithm' 1439 base identity."; 1440 } 1442 typedef ipsec-mode { 1443 type enumeration { 1444 enum TRANSPORT { description "Transport mode. No NAT support."; } 1445 enum TUNNEL { description "Tunnel mode"; } 1446 } 1447 description "Type definition of IPsec mode"; 1448 } 1450 typedef esp-encap { 1451 type enumeration { 1452 enum ESPINTCP { description "ESP in TCP encapulation.";} 1453 enum ESPINTLS { description "ESP in TCP encapsulation using TLS.";} 1454 enum ESPINUDP { description "ESP in UDP encapsulation. RFC 3948 ";} 1455 enum NONE { description "NOT ESP encapsulation" ; } 1456 } 1457 description "type defining types of ESP encapsulation"; 1458 } 1460 grouping encap { /* This is defined by XFRM */ 1461 description "Encapsulation container"; 1462 leaf espencap { type esp-encap; description "ESP in TCP, ESP in UDP or ESP in TLS";} 1463 leaf sport {type inet:port-number; description "Encapsulation source port";} 1464 leaf dport {type inet:port-number; description "Encapsulation destination port"; } 1465 leaf-list oaddr {type inet:ip-address; description "Encapsulation Original Address ";} 1466 } 1468 typedef ipsec-protocol { 1469 type enumeration { 1470 enum ah { description "AH Protocol"; } 1471 enum esp { description "ESP Protocol"; } 1472 } 1473 description "type define of ipsec security protocol"; 1475 } 1477 typedef ipsec-spi { 1478 type uint32 { range "0..max"; } 1479 description "SPI"; 1480 } 1482 typedef lifetime-action { 1483 type enumeration { 1484 enum terminate-clear {description "Terminate the IPsec SA and allow the packets through";} 1485 enum terminate-hold {description "Terminate the IPsec SA and drop the packets";} 1486 enum replace {description "Replace the IPsec SA with a new one";} 1487 } 1488 description "Action when lifetime expiration"; 1489 } 1491 /*################## SPD basic groupings ####################*/ 1493 typedef ipsec-traffic-direction { 1494 type enumeration { 1495 enum INBOUND { description "Inbound traffic"; } 1496 enum OUTBOUND { description "Outbound traffic"; } 1497 } 1498 description "IPsec traffic direction"; 1499 } 1501 typedef ipsec-spd-operation { 1502 type enumeration { 1503 enum PROTECT { description "PROTECT the traffic with IPsec"; } 1504 enum BYPASS { description "BYPASS the traffic"; } 1505 enum DISCARD { description "DISCARD the traffic"; } 1506 } 1507 description "The operation when traffic matches IPsec security policy"; 1508 } 1510 typedef ipsec-upper-layer-proto { 1511 type enumeration { 1512 enum TCP { description "TCP traffic"; } 1513 enum UDP { description "UDP traffic"; } 1514 enum SCTP { description "SCTP traffic";} 1515 enum DCCP { description "DCCP traffic";} 1516 enum ICMP { description "ICMP traffic";} 1517 enum IPv6-ICMP { description "IPv6-ICMP traffic";} 1518 enum GRE {description "GRE traffic";} 1519 } 1520 description "Next layer proto on top of IP"; 1521 } 1522 typedef ipsec-spd-name { 1523 type enumeration { 1524 enum id_rfc_822_addr { description "Fully qualified user name string."; } 1525 enum id_fqdn { description "Fully qualified DNS name."; } 1526 enum id_der_asn1_dn { description "X.500 distinguished name."; } 1527 enum id_key { description "IKEv2 Key ID."; } 1528 } 1529 description "IPsec SPD name type"; 1530 } 1532 grouping lifetime { 1533 description "lifetime current state data"; 1534 leaf time {type yang:timestamp; default 0; description "Time since the element is added";} 1535 leaf idle {type yang:timestamp; default 0; description "Time the element is in idle state";} 1536 leaf bytes { type uint32; default 0; description "Lifetime in bytes number";} 1537 leaf packets {type uint32; default 0; description "Lifetime in packets number";} 1538 } 1540 /*################## SAD and SPD common basic groupings ####################*/ 1542 grouping port-range { 1543 description "Port range grouping"; 1544 leaf start { type inet:port-number; description "Start Port Number"; } 1545 leaf end { type inet:port-number; description "End Port Number"; } 1546 } 1548 grouping tunnel-grouping { 1549 description "Tunnel mode grouping"; 1550 leaf local{ type inet:ip-address; description "Local tunnel endpoint"; } 1551 leaf remote{ type inet:ip-address; description "Remote tunnel enpoint"; } 1552 leaf bypass-df { type boolean; description "Bypass DF bit"; } 1553 leaf bypass-dscp { type boolean; description "Bypass DSCP"; } 1554 leaf dscp-mapping { type yang:hex-string; description "DSCP mapping"; } 1555 leaf ecn { type boolean; description "Bit ECN"; } /* RFC 4301 ASN1 notation. Annex C*/ 1556 } 1558 grouping selector-grouping { 1559 description "Traffic selector grouping"; 1561 leaf local-subnet { type inet:ip-prefix; description "Local IP address subnet"; } 1562 leaf remote-subnet { type inet:ip-prefix; description "Remote IP address subnet"; } 1564 leaf-list upper-layer-protocol { type ipsec-upper-layer-proto; description "List of Upper Layer Protocol";} 1566 list local-ports { 1567 key "start end"; 1568 uses port-range; 1569 description "List of local ports. When the upper-layer-protocol is ICMP this 16 bit value respresents code and type as mentioned in RFC 4301"; 1571 } 1573 list remote-ports { 1574 key "start end"; 1575 uses port-range; 1576 description "List of remote ports. When the upper-layer-protocol is ICMP this 16 bit value respresents code and type as mentioned in RFC 4301"; 1577 } 1578 } 1580 /*################## SPD ipsec-policy-grouping ####################*/ 1582 grouping ipsec-policy-grouping { 1584 description "Holds configuration information for an IPSec SPD entry."; 1586 leaf spd-entry-id { type uint64; description "SPD entry id "; } 1587 leaf priority {type uint32; default 0; description "Policy priority";} 1588 leaf anti-replay-window { type uint16 { range "0 | 32..1024"; } description "Anti replay window size"; } 1590 list names { 1591 key "name"; 1592 leaf name-type { type ipsec-spd-name; description "SPD name type."; } 1593 leaf name { type string; description "Policy name"; } 1594 description "List of policy names"; 1595 } 1597 container condition { 1598 description "SPD condition - RFC4301"; 1599 list traffic-selector-list { 1600 key "ts-number"; 1601 leaf ts-number { type uint32; description "Traffic selector number"; } 1602 leaf direction { type ipsec-traffic-direction; description "in/out"; } 1603 uses selector-grouping; 1604 ordered-by user; 1605 description "List of traffic selectors"; 1606 } 1607 } 1609 container processing-info { 1610 description "SPD processing - RFC4301"; 1611 leaf action{ type ipsec-spd-operation; mandatory true; description "Bypass or discard, container ipsec-sa-cfg is empty";} 1613 container ipsec-sa-cfg { 1614 when "../action = 'PROTECT'"; 1616 leaf pfp-flag { type boolean; description "Each selector has with a pfp flag."; } 1617 leaf extSeqNum { type boolean; description "TRUE 64 bit counter, FALSE 32 bit"; } 1618 leaf seqOverflow { type boolean; description "TRUE rekey, FALSE terminare & audit"; } 1619 leaf statefulfragCheck { type boolean; description "Indicates whether (TRUE) or not (FALSE) stateful fragment checking (RFC 4301) applies to the SA to be created."; } 1620 leaf security-protocol { type ipsec-protocol; description "Security protocol of IPsec SA: Either AH or ESP."; } 1621 leaf mode { type ipsec-mode; description "transport/tunnel"; } 1623 container ah-algorithms { 1624 when "../security-protocol = 'ah'"; 1625 leaf-list ah-algorithm { type integrity-algorithm-t; description "Configure Authentication Header (AH)."; } 1626 leaf trunc-length { type uint32; description "Truncation value for AH algorithm"; } 1627 description "AH algoritms "; 1628 } 1630 container esp-algorithms { 1631 when "../security-protocol = 'esp'"; 1632 description "Configure Encapsulating Security Payload (ESP)."; 1633 leaf-list authentication { type integrity-algorithm-t; description "Configure ESP authentication"; } 1634 /* With AEAD algorithms, the authentication node is not used */ 1635 leaf-list encryption { type encryption-algorithm-t; description "Configure ESP encryption"; } 1636 leaf tfc_pad { type uint32; default 0; description "TFC padding for ESP encryption"; } 1637 } 1639 container tunnel { 1640 when "../mode = 'TUNNEL'"; 1641 uses tunnel-grouping; 1642 description "tunnel grouping container"; 1643 } 1645 description " IPSec SA configuration container"; 1646 } 1647 } 1649 container spd-lifetime-soft { 1650 description "SPD lifetime hard state data"; 1651 uses lifetime; 1652 leaf action {type lifetime-action; description "Action lifetime";} 1653 } 1655 container spd-lifetime-hard { 1656 description "SPD lifetime hard state data. The action after the lifetime is to remove the SPD entry."; 1657 uses lifetime; 1658 } 1660 // State data for an IPsec SPD entry 1661 container spd-lifetime-current { 1662 uses lifetime; 1663 config false; 1664 description "SPD lifetime current state data"; 1665 } 1666 } /* grouping ipsec-policy-grouping */ 1668 } 1669 1671 Appendix B. Appendix B: YANG model for IKE case 1673 file "ietf-ipsec-ike@2019-03-11.yang" 1675 module ietf-ipsec-ike { 1676 yang-version 1.1; 1677 namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec-ike"; 1678 prefix "ipsec-ike"; 1680 import ietf-inet-types { prefix inet; } 1681 import ietf-yang-types { prefix yang; } 1683 import ietf-crypto-types { 1684 prefix ct; 1685 reference "draft-ietf-netconf-crypto-types-01: Common YANG Data Types for Cryptography"; 1686 } 1688 import ietf-ipsec-common { 1689 prefix ic; 1690 reference "Common Data model for SDN-based IPSec configuration"; 1691 } 1693 organization "IETF I2NSF (Interface to Network Security Functions) Working Group"; 1695 contact 1696 " Rafael Marin Lopez 1697 Dept. Information and Communications Engineering (DIIC) 1698 Faculty of Computer Science-University of Murcia 1699 30100 Murcia - Spain 1700 Telf: +34868888501 1701 e-mail: rafa@um.es 1703 Gabriel Lopez Millan 1704 Dept. Information and Communications Engineering (DIIC) 1705 Faculty of Computer Science-University of Murcia 1706 30100 Murcia - Spain 1707 Tel: +34 868888504 1708 email: gabilm@um.es 1710 Fernando Pereniguez Garcia 1711 Department of Sciences and Informatics 1712 University Defense Center (CUD), Spanish Air Force Academy, MDE-UPCT 1713 30720 San Javier - Spain 1714 Tel: +34 968189946 1715 email: fernando.pereniguez@cud.upct.es 1716 "; 1718 description "Data model for IKE case."; 1720 revision "2019-03-11" { 1721 description "Revision 1.1"; 1722 reference ""; 1723 } 1725 typedef type-autostartup { 1726 type enumeration { 1727 enum ADD {description "IPsec configuration is only loaded but not started.";} 1728 enum ON-DEMAND {description "IPsec configuration is loaded and transferred to the NSF's kernel";} 1729 enum START { description "IPsec configuration is loaded and transferred to the NSF's kernel, and the IKEv2 based IPsec SAs are established";} 1730 } 1731 description "Different policies of when to start an IKEv2 based IPsec SA"; 1732 } 1734 typedef auth-protocol-type { 1735 type enumeration { 1736 enum IKEv2 { description "Authentication protocol based on IKEv2"; } 1737 } 1738 description "IKE authentication protocol version"; 1739 } 1741 typedef pfs-group { 1742 type enumeration { 1743 enum NONE {description "NONE";} 1744 enum 768-bit-MODP {description "768-bit MODP Group";} 1745 enum 1024-bit-MODP {description "1024-bit MODP Group";} 1746 enum 1536-bit-MODP {description "1536-bit MODP Group";} 1747 enum 2048-bit-MODP {description "2048-bit MODP Group";} 1748 enum 3072-bit-MODP {description "3072-bit MODP Group";} 1749 enum 4096-bit-MODP {description "4096-bit MODP Group";} 1750 enum 6144-bit-MODP {description "6144-bit MODP Group";} 1751 enum 8192-bit-MODP {description "8192-bit MODP Group";} 1752 } 1753 description "PFS group for IPsec rekey"; 1754 } 1756 /*################## PAD ####################*/ 1758 typedef auth-method-type { 1759 /* Most implementations also provide XAUTH protocol, others used are: BLISS, P12, NTLM, PIN */ 1760 type enumeration { 1761 enum pre-shared { description "Select pre-shared key message as the authentication method"; } 1762 enum eap { description "Select EAP as the authentication method"; } 1763 enum digital-signature { description "Select digital signature method";} 1764 enum null {description "null authentication";} 1765 } 1766 description "Peer authentication method"; 1767 } 1769 typedef signature-algorithm-t { 1770 type ct:signature-algorithm-ref; // We must reference to "signature-algorithm-ref" but we temporary use hash-algorithm-ref 1771 description "This typedef enables referencing to any digital signature algorithm"; 1772 } 1774 grouping auth-method-grouping { 1775 description "Peer authentication method data"; 1777 container auth-method { 1778 description "Peer authentication method container"; 1780 leaf auth-m { type auth-method-type; description "Type of authentication method (pre-shared, eap, digital signature, null)"; } 1782 container eap-method { 1783 when "../auth-m = 'eap'"; 1784 leaf eap-type { type uint8; description "EAP method type"; } 1785 description "EAP method description used when auth method is eap"; 1786 } 1788 container pre-shared { 1789 when "../auth-m[.='pre-shared' or .='eap']"; 1790 leaf secret { type yang:hex-string; description "Pre-shared secret value";} 1791 description "Shared secret value"; 1792 } 1794 container digital-signature { 1795 when "../auth-m[.='digital-signature' or .='eap']"; 1796 leaf ds-algorithm {type signature-algorithm-t; description "Name of the digital signature algorithm";} 1797 leaf raw-public-key {type yang:hex-string; description "RSA raw public key" ;} 1798 leaf key-data { type string; description "RSA private key data - PEM"; } 1799 leaf key-file { type string; description "RSA private key file name "; } 1800 leaf-list ca-data { type string; description "List of trusted CA certs - PEM"; } 1801 leaf ca-file { type string; description "List of trusted CA certs file"; } 1802 leaf cert-data { type string; description "X.509 certificate data - PEM4"; } 1803 leaf cert-file { type string; description "X.509 certificate file"; } 1804 leaf crl-data { type string; description "X.509 CRL certificate data in base64"; } 1805 leaf crl-file { type string; description " X.509 CRL certificate file"; } 1806 leaf oscp-uri { type inet:uri; description "OCSP URI";} 1807 description "RSA signature container"; 1808 } 1809 } 1810 } 1812 grouping identity-grouping { 1813 description "Identification type. It is an union identity"; 1814 choice identity { 1815 description "Choice of identity."; 1816 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. "; } 1817 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 ."; } 1818 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.)."; } 1819 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.)."; } 1820 leaf dnX509 { type string; description "Specifies the identity as a distinguished name in the X.509 tradition."; } 1821 leaf id_key { type string; description "Key id"; } 1822 leaf id_null { type empty; description "RFC 7619" ; } 1823 leaf user_fqdn { type string; description "User FQDN"; } 1824 } 1825 leaf my-identifier { type string; mandatory true; description "id used for authentication"; } 1826 } 1828 /*################ end PAD ##################*/ 1830 /*################## IKEv2-grouping ##################*/ 1831 grouping ike-proposal { 1832 description "IKEv2 proposal grouping"; 1834 container ike-sa-lifetime-hard { 1835 description "IKE SA lifetime hard"; 1836 uses ic:lifetime; 1837 } 1839 container ike-sa-lifetime-soft { 1840 description "IPsec SA lifetime soft"; 1841 uses ic:lifetime; 1842 leaf action {type ic:lifetime-action; description "Action lifetime";} 1843 } 1845 leaf-list ike-sa-authalg { type ic:integrity-algorithm-t; description "Auth algorigthm for IKE SA";} 1846 leaf-list ike-sa-encalg { type ic:encryption-algorithm-t; description "Auth algorigthm for IKE SAs";} 1847 leaf dh_group { type uint32; mandatory true; description "Group number for Diffie Hellman Exponentiation";} 1848 leaf half-open-ike-sa-timer { type uint32; description "Set the half-open IKE SA timeout duration" ; } 1849 leaf half-open-ike-sa-cookie-threshold { type uint32; description "Number of half-open IKE SAs that activate the cookie mechanism." ; } 1850 } 1852 grouping ike-child-sa-info { 1853 description "IPsec SA Information"; 1854 leaf-list pfs_groups { type pfs-group; description "If non-zero, require perfect forward secrecy when requesting new SA. The non-zero value is the required group number"; } 1856 container child-sa-lifetime-soft { 1857 description "IPsec SA lifetime soft"; 1858 uses ic:lifetime; 1859 leaf action {type ic:lifetime-action; description "action lifetime";} 1860 } 1862 container child-sa-lifetime-hard { 1863 description "IPsec SA lifetime hard. The action will be to terminate the IPsec SA."; 1864 uses ic:lifetime; 1865 } 1866 } 1868 /*################## End IKEv2-grouping ##################*/ 1870 container ikev2 { 1872 description "Configure the IKEv2 software"; 1874 container pad { 1875 description "Configure Peer Authorization Database (PAD)"; 1876 list pad-entry { 1877 key "pad-entry-id"; 1878 ordered-by user; 1879 description "Peer Authorization Database (PAD)"; 1880 leaf pad-entry-id { type uint64; description "SAD index. ";} 1881 uses identity-grouping; 1882 leaf pad-auth-protocol { type auth-protocol-type; description "IKEv2, etc. ";} 1883 uses auth-method-grouping; 1884 } 1885 } 1887 list ike-conn-entry { 1888 key "conn-name"; 1889 description "IKE peer connection information"; 1890 leaf conn-name { type string; mandatory true; description "Name of IKE connection";} 1891 leaf autostartup { type type-autostartup; mandatory true; description "if True: automatically start tunnel at startup; else we do lazy tunnel setup based on trigger from datapath";} 1892 leaf initial-contact {type boolean; default false; description "This IKE SA is the only currently active between the authenticated identities";} 1893 leaf version { 1894 type enumeration { 1895 enum ikev2 {value 2; description "IKE version 2";} 1896 } 1897 description "IKE version"; 1898 } 1900 leaf ike-fragmentation { type boolean; description "Whether to use IKEv2 fragmentation as per RFC 7383 (TRUE or FALSE)"; } 1901 uses ike-proposal; 1903 container local { 1904 description "Local peer connection information"; 1905 leaf local-pad-id { type uint64; description " ";} 1906 } 1908 container remote { 1909 description "Remote peer connection information"; 1910 leaf remote-pad-id { type uint64; description " ";} 1911 } 1913 uses ic:encap; 1915 container spd { 1916 description "Configure the Security Policy Database (SPD)"; 1917 list spd-entry { 1918 key "spd-entry-id"; 1919 uses ic:ipsec-policy-grouping; 1920 ordered-by user; 1921 description "List of SPD entries"; 1922 } 1923 } 1925 container ike-sa-state { 1926 container uptime { 1927 description "IKE service uptime"; 1928 leaf running { type yang:date-and-time; description "Relative uptime";} 1929 leaf since { type yang:date-and-time; description "Absolute uptime";} 1930 } 1932 leaf initiator { type boolean; description "It is acting as initiator in this connection";} 1933 leaf initiator-ikesa-spi {type uint64; description "Initiator's IKE SA SPI";} 1934 leaf responder-ikesa-spi {type uint64; description "Responsder's IKE SA SPI";} 1935 leaf nat-local {type boolean; description "YES, if local endpoint is behind a NAT";} 1936 leaf nat-remote {type boolean; description "YES, if remote endpoint is behind a NAT";} 1937 leaf nat-any {type boolean; description "YES, if both local and remote endpoints are behind a NAT";} 1939 uses ic:encap; 1941 leaf established {type uint64; description "Seconds the IKE SA has been established";} 1942 leaf rekey-time {type uint64; description "Seconds before IKE SA gets rekeyed";} 1943 leaf reauth-time {type uint64; description "Seconds before IKE SA gets re-authenticated";} 1944 list child-sas { 1945 container spis{ 1946 description "IPsec SA's SPI '"; 1947 leaf spi-in {type ic:ipsec-spi; description "Security Parameter Index for inbound IPsec SA";} 1948 leaf spi-out {type ic:ipsec-spi; description "Security Parameter Index for the corresponding outbound IPsec SA";} 1950 } 1951 description "State data about IKE CHILD SAs"; 1952 } 1953 config false; 1954 description "IKE state data"; 1955 } /* ike-sa-state */ 1956 } /* ike-conn-entries */ 1958 container number-ike-sas{ 1959 leaf total {type uint32; description "Total number of IKEv2 SAs";} 1960 leaf half-open {type uint32; description "Number of half-open IKEv2 SAs";} 1961 leaf half-open-cookies {type uint32; description "Number of half open IKE SAs with cookie activated" ;} 1962 config false; 1963 description "Number of IKE SAs"; 1964 } 1965 } /* container ikev2 */ 1966 } 1968 1970 Appendix C. Appendix C: YANG model for IKE-less case 1972 file "ietf-ipsec-ikeless@2019-03-11.yang" 1974 module ietf-ipsec-ikeless { 1976 yang-version 1.1; 1977 namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless"; 1979 prefix "ipsec-ikeless"; 1981 import ietf-yang-types { prefix yang; } 1983 import ietf-ipsec-common { 1984 prefix ic; 1985 reference "Common Data model for SDN-based IPSec configuration"; 1986 } 1988 organization "IETF I2NSF (Interface to Network Security Functions) Working Group"; 1990 contact 1991 " Rafael Marin Lopez 1992 Dept. Information and Communications Engineering (DIIC) 1993 Faculty of Computer Science-University of Murcia 1994 30100 Murcia - Spain 1995 Telf: +34868888501 1996 e-mail: rafa@um.es 1998 Gabriel Lopez Millan 1999 Dept. Information and Communications Engineering (DIIC) 2000 Faculty of Computer Science-University of Murcia 2001 30100 Murcia - Spain 2002 Tel: +34 868888504 2003 email: gabilm@um.es 2005 Fernando Pereniguez Garcia 2006 Department of Sciences and Informatics 2007 University Defense Center (CUD), Spanish Air Force Academy, MDE-UPCT 2008 30720 San Javier - Spain 2009 Tel: +34 968189946 2010 email: fernando.pereniguez@cud.upct.es 2011 "; 2013 description "Data model for IKE-less case"; 2015 revision "2019-03-11" { 2016 description "Revision"; 2017 reference ""; 2018 } 2020 /*################## SAD grouping ####################*/ 2021 grouping ipsec-sa-grouping { 2022 description "Configure Security Association (SA). Section 4.4.2.1 in RFC 4301"; 2024 leaf sad-entry-id {type uint64; description "This value identifies a specific entry in the SAD";} 2025 leaf spi { type ic:ipsec-spi; description "Security Parameter Index. This may not be unique for a particular SA";} 2026 leaf seq-number { type uint64; description "Current sequence number of IPsec packet."; } 2027 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."; } 2028 leaf anti-replay-window { type uint16 { range "0 | 32..1024"; } description "Anti replay window size"; } 2029 leaf spd-entry-id {type uint64; description "This value links the SA with the SPD entry";} 2031 uses ic:selector-grouping; 2033 leaf security-protocol { type ic:ipsec-protocol; description "Security protocol of IPsec SA: Either AH or ESP."; } 2035 container sad-lifetime-hard { 2036 description "SAD lifetime hard state data. The action associated is terminate."; 2037 uses ic:lifetime; 2038 } 2039 container sad-lifetime-soft { 2040 description "SAD lifetime hard state data"; 2041 uses ic:lifetime; 2042 leaf action {type ic:lifetime-action; description "action lifetime";} 2043 } 2045 leaf mode { type ic:ipsec-mode; description "SA Mode"; } 2046 leaf statefulfragCheck { type boolean; description "Indicates whether (TRUE) or not (FALSE) stateful fragment checking (RFC 4301) applies to this SA."; } 2048 leaf dscp { type yang:hex-string; description "DSCP value"; } 2049 leaf path-mtu { type uint16; description "Maximum size of an IPsec packet that can be transmitted without fragmentation"; } 2051 container tunnel { 2052 when "../mode = 'TUNNEL'"; 2053 uses ic:tunnel-grouping; 2054 description "Container for tunnel grouping"; 2055 } 2057 uses ic:encap; 2059 // STATE DATA for SA 2060 container sad-lifetime-current { 2061 uses ic:lifetime; 2062 config false; 2063 description "SAD lifetime current state data"; 2064 } 2066 container stats { // xfrm.h 2067 leaf replay-window {type uint32; default 0; description " "; } 2068 leaf replay {type uint32; default 0; description "packets detected out of the replay window and dropped because they are replay packets";} 2069 leaf failed {type uint32; default 0; description "packets detected out of the replay window ";} 2070 config false; 2071 description "SAD statistics"; 2072 } 2074 container replay_state { // xfrm.h 2075 leaf seq {type uint32; default 0; description "input traffic sequence number when anti-replay-window != 0";} 2076 leaf oseq {type uint32; default 0; description "output traffic sequence number";} 2077 leaf bitmap {type uint32; default 0; description "";} 2078 config false; 2079 description "Anti-replay Sequence Number state"; 2080 } 2082 container replay_state_esn { // xfrm.h 2083 leaf bmp-len {type uint32; default 0; description "bitmap length for ESN"; } 2084 leaf oseq { type uint32; default 0; description "output traffic sequence number"; } 2085 leaf oseq-hi { type uint32; default 0; description ""; } 2086 leaf seq-hi { type uint32; default 0; description ""; } 2087 leaf replay-window {type uint32; default 0; description ""; } 2088 leaf-list bmp { type uint32; description "bitmaps for ESN (depends on bmp-len) "; } 2089 config false; 2090 description "Anti-replay Extended Sequence Number (ESN) state"; 2091 } 2093 } 2094 /*################## end SAD grouping ##################*/ 2096 /*################# Register grouping #################*/ 2097 typedef sadb-msg-type { 2098 type enumeration { 2099 enum sadb_acquire { description "SADB_ACQUIRE"; } 2100 enum sadb_expire { description "SADB_EXPIRE"; } 2101 } 2102 description "Notifications (PF_KEY message types) that must be forwarded by the NSF to the controller in IKE-less case"; 2103 } 2105 typedef sadb-msg-satype { 2106 type enumeration { 2107 enum sadb_satype_unspec { description "SADB_SATYPE_UNSPEC"; } 2108 enum sadb_satype_ah { description "SADB_SATYPE_AH"; } 2109 enum sadb_satype_esp { description "SADB_SATYPE_ESP"; } 2110 enum sadb_satype_rsvp { description "SADB_SATYPE_RSVP"; } 2111 enum sadb_satype_ospfv2 { description "SADB_SATYPE_OSPFv2"; } 2112 enum sadb_satype_ripv2 { description "SADB_SATYPE_RIPv2"; } 2113 enum sadb_satype_mip { description "SADB_SATYPE_MIP"; } 2114 enum sadb_satype_max { description "SADB_SATYPE_MAX"; } 2115 } 2116 description "PF_KEY Security Association types"; 2117 } 2119 grouping base-grouping { 2120 description "Configuration for the message header format"; 2121 list base-list { 2122 key "version"; 2123 leaf version { type string; description "Version of PF_KEY (MUST be PF_KEY_V2)"; } 2124 leaf msg_type { type sadb-msg-type; description "Identifies the type of message"; } 2125 leaf msg_satype { type sadb-msg-satype; description "Defines the type of Security Association"; } 2126 leaf msg_seq { type uint32; description "Sequence number of this message."; } 2127 description "Configuration for a specific message header format"; 2128 } 2129 } 2130 /*################# End Register grouping #################*/ 2132 /*################## IPsec configuration ##################*/ 2133 container ietf-ipsec { 2134 description "IPsec configuration"; 2136 container spd { 2137 description "Configure the Security Policy Database (SPD)"; 2138 list spd-entry { 2139 key "spd-entry-id"; 2140 uses ic:ipsec-policy-grouping; 2141 ordered-by user; 2142 description "List of SPD entries"; 2143 } 2144 } 2146 container sad { 2147 description "Configure the IPSec Security Association Database (SAD)"; 2149 list sad-entry { 2150 key "sad-entry-id"; 2152 uses ipsec-sa-grouping; 2154 container ah-sa { 2155 when "../security-protocol = 'ah'"; 2156 description "Configure Authentication Header (AH) for SA"; 2157 container integrity { 2158 description "Configure integrity for IPSec Authentication Header (AH)"; 2159 leaf integrity-algorithm { type ic:integrity-algorithm-t; description "Configure Authentication Header (AH)."; } 2160 leaf key { type string; description "AH key value";} 2161 } 2162 } 2164 container esp-sa { 2165 when "../security-protocol = 'esp'"; 2166 description "Set IPSec Encapsulation Security Payload (ESP)"; 2168 container encryption { 2169 description "Configure encryption for IPSec Encapsulation Secutiry Payload (ESP)"; 2170 leaf encryption-algorithm { type ic:encryption-algorithm-t; description "Configure ESP encryption"; } 2171 leaf key { type yang:hex-string; description "ESP encryption key value";} 2172 leaf iv {type yang:hex-string; description "ESP encryption IV value"; } 2173 } 2175 container integrity { 2176 description "Configure authentication for IPSec Encapsulation Secutiry Payload (ESP)"; 2177 leaf integrity-algorithm { type ic:integrity-algorithm-t; description "Configure Authentication Header (AH)."; } 2178 leaf key { type yang:hex-string; description "ESP integrity key value";} 2179 } 2180 /* With AEAD algorithms, the integrity node is not used */ 2182 leaf combined-enc-intr { type boolean; description "ESP combined mode algorithms. The algorithm is specified in encryption-algorithm";} 2183 } 2184 description "List of SAD entries"; 2185 } 2186 } 2187 } /* container ietf-ipsec */ 2189 /*################## RPC and Notifications ##################*/ 2191 // These RPCs are needed by a Security Controller in IKEless case 2193 notification spdb_expire { 2194 description "A SPD entry has expired"; 2195 leaf index { type uint64; description "SPD index. RFC4301 does not mention an index however real implementations (e.g. XFRM or PFKEY_v2 with KAME extensions provide a policy index to refer a policy. "; } 2196 } 2198 notification sadb_acquire { 2199 description "A IPsec SA is required "; 2200 uses base-grouping; 2201 uses ic:selector-grouping; // To indicate the concrete traffic selector of the policy that triggered this acquire. 2202 } 2204 notification sadb_expire { 2205 description "A IPsec SA expiration (soft or hard)"; 2207 uses base-grouping; 2208 leaf spi { type ic:ipsec-spi; description "Security Parameter Index";} 2209 leaf anti-replay-window { type uint16 { range "0 | 32..1024"; } description "Anti replay window"; } 2211 leaf encryption-algorithm { type ic:encryption-algorithm-t; description "encryption algorithm of the expired SA"; } 2212 leaf authentication-algorithm { type ic:integrity-algorithm-t; description "authentication algorithm of the expired SA"; } 2214 container sad-lifetime-hard { 2215 description "SAD lifetime hard state data"; 2216 uses ic:lifetime; 2217 } 2218 container sad-lifetime-soft { 2219 description "SAD lifetime soft state data"; 2220 uses ic:lifetime; 2221 } 2223 container sad-lifetime-current { 2224 description "SAD lifetime current state data"; 2225 uses ic:lifetime; 2226 } 2228 } 2230 notification sadb_bad-spi { 2231 description "Notifiy when the NSF receives a packet with an incorrect SPI (i.e. not present in the SAD)"; 2232 leaf state { type ic:ipsec-spi; mandatory "true"; description "SPI number contained in the erroneous IPsec packet"; } 2233 } 2235 }/*module ietf-ipsec*/ 2237 2239 Authors' Addresses 2241 Rafa Marin-Lopez 2242 University of Murcia 2243 Campus de Espinardo S/N, Faculty of Computer Science 2244 Murcia 30100 2245 Spain 2247 Phone: +34 868 88 85 01 2248 EMail: rafa@um.es 2250 Gabriel Lopez-Millan 2251 University of Murcia 2252 Campus de Espinardo S/N, Faculty of Computer Science 2253 Murcia 30100 2254 Spain 2256 Phone: +34 868 88 85 04 2257 EMail: gabilm@um.es 2259 Fernando Pereniguez-Garcia 2260 University Defense Center 2261 Spanish Air Force Academy, MDE-UPCT 2262 San Javier (Murcia) 30720 2263 Spain 2265 Phone: +34 968 18 99 46 2266 EMail: fernando.pereniguez@cud.upct.es