idnits 2.17.1 draft-abad-i2nsf-sdn-ipsec-flow-protection-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 13 instances of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 30, 2016) is 2735 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '2' on line 399 == Unused Reference: 'RFC5226' is defined on line 939, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2nsf-framework' is defined on line 946, but no explicit reference was found in the text == Unused Reference: 'I-D.jeong-i2nsf-sdn-security-services-05' is defined on line 965, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-10) exists of draft-ietf-i2nsf-framework-03 == Outdated reference: A later version (-16) exists of draft-ietf-i2nsf-problem-and-use-cases-02 == Outdated reference: A later version (-08) exists of draft-ietf-i2nsf-terminology-02 -- No information found for draft-pfkey-spd - is the name correct? Summary: 3 errors (**), 0 flaws (~~), 7 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: Experimental University of Murcia 5 Expires: May 3, 2017 S. Varadhan 6 Oracle 7 October 30, 2016 9 Software-Defined Networking (SDN)-based IPsec Flow Protection 10 draft-abad-i2nsf-sdn-ipsec-flow-protection-01 12 Abstract 14 This document describes the use case of providing IPsec-based flow 15 protection by means of a Software-Defined Network (SDN) controller 16 and raises the requirements to support this service. It considers 17 two main scenarios: (i) gateway-to-gateway and (ii) host-to-gateway 18 (Road Warrior). For the gateway-to-gateway scenario, this document 19 describes a mechanism to support the distribution of IPsec 20 information to flow-based Network Security Functions (NSFs) that 21 implements IPsec to protect data traffic. between network resources 22 to protect data traffic with IPsec and IKE, in intra and inter-SDN 23 cases. The host-to-gateway case defines a mechanism to distribute 24 IPsec information to the NSF to protect data with IPsec between an 25 end user's device (host) and a gateway. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on May 3, 2017. 44 Copyright Notice 46 Copyright (c) 2016 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 63 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 5. Case 1: IKE/IPsec in the NSF . . . . . . . . . . . . . . . . 5 66 5.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 6 67 6. Case 2: IPsec (no IKE) in the NSF . . . . . . . . . . . . . . 7 68 6.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 8 69 7. Abstract interface (NSF facing interface) . . . . . . . . . . 8 70 8. Data model . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 9. Scaling considerations . . . . . . . . . . . . . . . . . . . 13 72 10. Use cases examples . . . . . . . . . . . . . . . . . . . . . 13 73 10.1. Gateway-to-gateway under the same controller . . . . . . 13 74 10.2. Gateway-to-gateway under different SDN controllers . . . 16 75 10.3. Host-to-gateway . . . . . . . . . . . . . . . . . . . . 18 76 11. Security Considerations . . . . . . . . . . . . . . . . . . . 20 77 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 78 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 79 13.1. Normative References . . . . . . . . . . . . . . . . . . 20 80 13.2. Informative References . . . . . . . . . . . . . . . . . 21 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 83 1. Introduction 85 Software-Defined Networking (SDN) is an architecture that enables 86 users to directly program, orchestrate, control and manage network 87 resources through software. SDN paradigm relocates the control of 88 network resources to a dedicated network element, namely SDN 89 controller. The SDN controller manages and configures the 90 distributed network resources and provides an abstracted view of the 91 network resources to the SDN applications. The SDN application can 92 customize and automate the operations (including management) of the 93 abstracted network resources in a programmable manner via this 94 interface [RFC7149][ITU-T.Y.3300] 95 [ONF-SDN-Architecture][ONF-OpenFlow]. 97 Typically, traditional IPsec VPN concentrators and, in general, 98 gateways supporting IKE/IPsec, are configured manually. This makes 99 the IPsec security association (SA) management difficult and 100 generates a lack of flexibility, specially if the number of security 101 policies and SAs to handle is high. With the growth of SDN-based 102 scenarios where network resources are deployed in an autonomous 103 manner, a mechanism to manage IPsec SAs according to the SDN 104 architecture becomes more relevant. Thus, the SDN-based service 105 described in this document will autonomously deal with IPsec-based 106 data protection also in such as an autonomous manner. 108 IPsec architecture [RFC4301] defines a clear separation between the 109 processing to provide security services to IP packets and the key 110 management procedures to establish the IPsec security association. 111 In this document, we define a service where the key management 112 procedures can be carried by an external entity: the security 113 controller. 115 First, this document exposes the requirements to support the 116 protection of data flows using IPsec [RFC4301]. We consider two 117 cases: 119 1) The network resource (or Network Security Function, NSF) 120 implements the Internet Key Exchange (IKE) protocol and the IPsec 121 databases: the Security Policy Database (SPD), the Security 122 Association Database (SAD) and the Peer Authorization Database 123 (PAD). The controller is in charge of provisioning the NSF with 124 the required information about IKE, the SPD and the PAD. 126 2) The NSF only implements the IPsec databases (no IKE 127 implementation). The controller will provide the required 128 parameters to create valid entries in the PAD, the SPD and the 129 SAD in the NSF. Therefore, the NSF will have only support for 130 IPsec while automated key management functionality is moved to 131 the controller. 133 In both cases, an interface/protocol will be required to carry out 134 this provisioning between the security controller and the NSF. In 135 particular, it is required the provision of SPD and PAD entries and 136 the credentials and information related with the IKE negotiation 137 (case 1); or the required SPD, PAD and SAD entries with information 138 such as keys, cryptographic algorithms, IP addresses, IPsec protocol 139 (AH or ESP), IPsec protocol mode (tunnel or transport), lifetime of 140 the SA, etc (case 2). An example for case 1 using NETFCONF/YANG can 141 be found in [netconf-vpn]. A YANG model for IPsec can be found in 142 [I-D.tran-ipsecme-yang]. 144 Second, this document considers two scenarios to manage autonomously 145 IPsec SAs: gateway-to-gateway and host-to-gateway [RFC6071]. The 146 gateway-to-gateway scenario shows how flow protection services are 147 useful when data is to be protected across gateways in the network. 148 Each gateway will implement a flow-based NSF. The use case described 149 in Section 10.1 depicts how these services could be used to protect 150 IP traffic among various geographically distributed networks under 151 the domain of the same security controller. A variant of this 152 scenario is also covered in Section 10.2, where the NSFs involved are 153 under the control of different security controllers. 155 The host-to-gateway scenario described in Section 10.3 covers the 156 case where one end user belonging to a network wants to access 157 securely its network from another external network. In such a case, 158 an IPsec SA needs to be established between the end user's host and 159 the gateway, which is a flow-based NSF. In this document, we 160 describe how the security controller can still configure 161 automatically the IPsec SA in the NSF. 163 It is worth noting that this work pays attention to the challenge 164 "Lack of Mechanism for Dynamic Key Distribution to NSFs" defined in 165 [I-D.ietf-i2nsf-problem-and-use-cases] in the particular case of the 166 establishment and management of IPsec security associations. In 167 fact, this I-D could be considered as a proper use case for this 168 challenge in [I-D.ietf-i2nsf-problem-and-use-cases]. 170 2. Requirements Language 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 174 document are to be interpreted as described in RFC 2119 [RFC2119]. 175 When these words appear in lower case, they have their natural 176 language meaning. 178 3. Terminology 180 This document uses the terminology described in [RFC7149], [RFC4301], 181 [ITU-T.Y.3300], [ONF-SDN-Architecture], [ONF-OpenFlow], 182 [ITU-T.X.1252], [ITU-T.X.800] and [I-D.ietf-i2nsf-terminology]. In 183 addition, the following terms are defined below: 185 o Software-Defined Networking. A set of techniques enabling to 186 directly program, orchestrate, control, and manage network 187 resources, which facilitates the design, delivery and operation of 188 network services in a dynamic and scalable manner [ITU-T.Y.3300]. 190 o Flow/Data Flow. Set of network packets sharing a set of 191 characteristics, for example IP dst/src values or QoS parameters. 193 o Flow Protection Policy. The set of rules defining the conditions 194 under which a data flow MUST be protected with IPsec, and the 195 rules that MUST be applied to the specific flow. 197 o IKE. Protocol to establish IPsec Security Associations (SAs). It 198 requires information about the required authentication method 199 (i.e. preshared keys), DH groups, modes and algorithms for IKE 200 phase 1, etc. 202 o SPD. IPsec Security Policy Database. It includes information 203 about IPsec policies direction (in, out), local and remote 204 addresses, inbound and outboud SAs, etc. 206 o SAD. IPsec Security Associations Database. It includes 207 information about IPsec security associations, such as SPI, 208 destination addresses, authentication and encryption algorithms 209 and keys. 211 o PAD. Peer Authorization Database. It provides the link between 212 the SPD and a security association management protocol such as IKE 213 or our SDN-based solution. 215 4. Objectives 217 o Flow-based data protection: controller-based flow protection 218 services based on IPsec to allow the protection of specific data 219 flows based on defined security policies. 221 o Establishment and management of IPsec security associations: this 222 service allows the centralized management of IPsec SAs to protect 223 specific data flows. 225 5. Case 1: IKE/IPsec in the NSF 227 In this case, the security controller is in charge of controlling and 228 applying SPD and PAD entries in the NSF. It also has to apply IKE 229 configuration parameters and derive and deliver IKE credentials (e.g. 230 a pre-shared key) to the NSF for the IKE negotiation. In short, we 231 would call this IKE credential. 233 With these entries and credentials, the IKE implementation can 234 operate to establish the IPsec SAs. The application (administrator) 235 will send the IPsec requirements and end points information, and the 236 security controller will translate those requirements into SPD 237 entries that will be installed in the NSF. With that information 238 provisioned in the NSF, when the data flow needs to be protected, the 239 NSF can just run IKE to establish the required IPsec SA. Figure 1 240 shows the different layers and corresponding functionality. 242 Advantages: It is simple because current gateways typically have an 243 IKE/IPsec implementation. 245 Disadvantages: IKE implementations need to renegotiate IPsec SAs upon 246 SPD entries changes without restarting IKE daemon. 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | IPsec Management/Orchestration Application| Client or 250 | I2NSF Client | App Gateway 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Client Facing Interface 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 Vendor | Application Support | 255 Facing <--->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Security 256 Interface | IKE Credential and SPD Policies Distribution| Controller 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | NSF Facing Interface 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | I2NSF Agent | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Network 262 | IKE | IPsec(SPD,SAD,PAD) | Security 263 +-------------------------------------------- + Function (NSF) 264 | Data Protection and Forwarding | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 Figure 1: Case 1: IKE/IPsec in the NSF 269 5.1. Requirements 271 SDN-based IPsec flow protection services provide dynamic and flexible 272 network resource management to protect data flows among network 273 resources and end users. In order to support this capability in case 274 1, the following requirements are to be met: 276 o The NSF MUST implement IKE and IPsec databases: SPD, SAD and PAD. 277 It MUST provide an (southbound) interface to provision SPD and PAD 278 entries, IKE Credentials and to monitor the IPsec databases and 279 IKE implementation. Note that SAD entries are created in runtime 280 by IKE. 282 o A southbound protocol MUST support sending these SPD and PAD 283 entries, and IKE credentials to the NSF. 285 o It requires an (northbound) application interface in the security 286 controller allowing the management of IPsec SAs. 288 o In scenarios where multiple controllers are implicated, SDN-based 289 flow protection service may require a mechanism to discover which 290 security controller is managing a specific NSF. 292 6. Case 2: IPsec (no IKE) in the NSF 294 This section describes the referenced architecture to support SDN- 295 based IPsec flow protection where the security controller performs 296 automated key management tasks. 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | IPsec Management/Orchestration Application| Client or 300 | I2NSF Client | App Gateway 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | Client Facing Interface 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 Vendor | Application Support | 305 Facing <--->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Security 306 Interface | SPD, SAD and PAD Entries Distr. | Controller 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | Key Derivation and Distribution | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | NSF Facing Interface 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | I2NSF Agent | Network 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Security 314 | IPSec (SPD,SAD,PAD) | Function (NSF) 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | Data Protection and Forwarding | 317 +---------------------------------------------+ 319 Figure 2: Case 2: IPsec (no IKE) in the NSF 321 As shown in Figure 2, applications for flow protection run on the top 322 of the security controller. When an administrator enforces flow 323 protection policies through an application interface, the security 324 controller translates those requirements into SPD,PAD and SAD entries 325 that will be installed in the NSF. 327 Advantages: 1) It allows lighter NSFs (no IKE implementation), which 328 benefits the deployment in constrained NSFs. 2) IKE does not need to 329 be run in gateway-to-gateway scenario with a single controller (see 330 Section 10.1). 332 Disadvantages: The overload of IPsec SA establishment is shifted to 333 the security controller since IKE is not in the NSF. As a 334 consequence, this may result in a more complex implementation in the 335 SDN controller side. For example, the security controller needs to 336 supervise the IPsec SA rekeying so that, after some period of time 337 (e.g. IPsec SA soft lifetime), to create a new IPsec SA and remove 338 the old one. Another example is the NAT traversal support. In this 339 case, since the security controller has a complete view of the 340 network (as SDN paradigm assumes) it can determine tha there is a NAT 341 between two NSFs and apply the required policies to both NSFs besides 342 activating the usage of UDP encapsulation of ESP packets. 344 6.1. Requirements 346 In order to support case 2, the following requirements are to be met: 348 o It requires the provision of SPD, PAD and SAD entries into the 349 NSF. A southbound protocol MUST support sending this information 350 to the NSF. 352 o NSF MUST be capable to protect data flows with IPsec, such as the 353 capability to forward data through an IPsec tunnel. 355 o It requires an (northbound) application interface in the security 356 controller allowing the management of IPsec policies. 358 o In scenarios where multiple controllers are implicated, SDN-based 359 flow protection service may require a mechanism to discover which 360 security controller is managing a specific NSF. 362 7. Abstract interface (NSF facing interface) 364 The cases presented above require an analysis of the communication 365 channel between the IPSec stack and the security controller that is 366 performing the key management operations. 368 The IETF RFC 2367 (PF_KEYv2) [RFC2367] provides a generic key 369 management API that can be used not only for IPsec but also for other 370 network security services to manage the IPsec SAD. Besides, as an 371 extension to this API, the document [I-D.pfkey-spd] specifies some 372 PF_KEY extensions to maintain the SPD. This API is accessed using 373 sockets. 375 An I2NSF Agent implementation in the NSF can interact with both APIs 376 in a kernel and returns and provides the same information using the 377 NSF Facing Interface. In the following, we show a summary of these 378 messages just to show an example of what may provide the NSF Facing 379 Interface. The details and the accurate information is in RFC 2367 380 and [I-D.pfkey-spd]. 382 +---------------------+---------------------------------------------+ 383 | PF_KEY | PF_NETLINK | 384 +---------------------+---------------------------------------------+ 385 | SADB_ADD | XFRM_MSG_NEWSA | 386 | SADB_GETSPI | XFRM_MSG_ALLOCSPI | 387 | SADB_UPDATE | XFRM_MSG_UPDSA | 388 | SADB_DELETE | XFRM_MSG_DELSA | 389 | SADB_GET | XFRM_MSG_GETSA | 390 | SADB_ACQUIRE | XFRM_MSG_ACQUIRE | 391 | SADB_REGISTER | Subscribe to NETLINK_XFRM group via bind() | 392 | | on the PF_NETLINK socket | 393 | SADB_EXPIRE | XFRM_MSG_EXPIRE | 394 | SADB_FLUSH | XFRM_MSG_FLUSHSA | 395 | SADB_DUMP | NLM_F_DUMP message for XFRM_MSG_GETSA | 396 | SADB_X_SPDSETIDX | XFRM_MSG_NEWPOLICY | 397 | SADB_X_SPDUPDATE | XFRM_MSG_UPDPOLICY | 398 | SADB_X_SPDADD | XFRM_MSG_NEWPOLICY | 399 | SADB_X_SPDDELETE[2] | XFRM_MSG_DELPOLICY; may optionally specify | 400 | | policy id in the index of the xfrm_policy | 401 | SADB_X_SPDGET | XFRM_MSG_GETPOLICY | 402 | SADB_X_SPDACQUIRE | XFRM_MSG_ACQUIRE | 403 | SADB_X_SPDEXPIRE | XFRM_MSG_POLEXPIRE | 404 | SADB_X_SPDFLUSH | XFRM_MSG_FLUSHPOLICY | 405 +---------------------+---------------------------------------------+ 407 Table 1: PF_KEY to PF_NETLINK mappings 409 An alternative key management API based on Netlink socket API 410 [RFC3549] is used to configure IPsec on the Linux Operating System. 411 The mappings between the PF_KEY commands used in this document and 412 their PF_NETLINK equivalents is provided in Table 1 414 To manage the IPsec SAD we have the following messages in the 415 PF_KEYv2 API: 417 o The SADB_GETSPI message allows a process to obtain a unique SPI 418 value for given security association type, source address, and 419 destination address. This message followed by an SADB_UPDATE is 420 one way to create a security association (SADB_ADD is the other 421 method). 423 o The SADB_UPDATE message allows a process to update the information 424 in an existing Security Association. 426 o The SADB_ADD message is nearly identical to the SADB_UPDATE 427 message, except that it does not require a previous call to 428 SADB_GETSPI. 430 o The SADB_DELETE message causes the kernel to delete an IPsec SA 431 from the SAD. 433 o The SADB_GET message allows a process to retrieve a copy of a 434 Security Association from the SAD. 436 o The SADB_ACQUIRE message is typically triggered by an outbound 437 packet that needs security but for which there is no applicable 438 IPsec SA existing in the SAD. 440 o The SADB_REGISTER message allows (a socket) to receive 441 SADB_ACQUIRE messages for the type of IPsec SA. 443 o The SADB_EXPIRE message is issued when soft limit or hard limit 444 (lifetime) of a IPsec SA has expired. 446 o The SADB_FLUSH message causes the kernel to delete all entries in 447 its IPsec SAD. 449 o The SADB_DUMP message causes to dump the operating system's entire 450 IPsec SAD. 452 Although it is not a standard, KAME IPsec has defined a set of 453 extensions to PF_KEY in order to handle the SPD [I-D.pfkey-spd]. The 454 extended API offers the addtional extensions: 456 o The SADB_X_SPDSETIDX message allows a process to add only selector 457 of the security policy entry to the SPD. 459 o The SADB_X_SPDUPDATE message replaces the parameters of an 460 existing SPD entry. 462 o The SADB_X_SPDADD is message allows a process to add a new 463 security policy entry to the SPD. 465 o The SADB_X_SPDDELETE message causes the kernel to delete an entry 466 from the SPD. 468 o The SADB_X_SPDDELETE2 message nearly identical to the 469 SADB_X_SPDDELETE message, except that it specifies the policy id. 471 o The SADB_X_SPDGET message is allows a process to retrieve a copy 472 of a security policy entry from the SPD. 474 o The SADB_X_SPDACQUIRE message is triggered by an outbound packet 475 that needs security policy but for which there is no applicable 476 information existing in the SPD. 478 o The SADB_X_SPDEXPIRE message is issued when limit of a security 479 policy (SPD entry) has expired. 481 o The SADB_X_SPDFLUSH message causes the kernel to delete all 482 entries in the IPsec SPD. 484 o The SADB_DUMP causes the kernel to dump all entries in the IPsec 485 SPD. 487 Regarding PAD management, we have not found any related extension. 488 However, from the abstract data model defined in Section 8 for the 489 PAD an interface could be designed. 491 8. Data model 493 These cases assume a data model representing the information to be 494 exchanged between controller and network resource through the 495 southbound interface. As described before this data model has to 496 include the following information [RFC4301] (authors of this I-D are 497 working now on developing a YANG model for this draft): 499 Data model for the SDP entries: 501 o Name 503 o PFP flags 505 o Perfect forward secrecy 507 o Selector list: 509 Remote IP addresses(es) 511 Local IP addresses(es) 513 Flow direction 515 Next Layer Protocol 517 Local port 519 Remote port 521 Type code 523 o Processing: 525 Extended sequence number 526 Sequence overflow 528 Fragment checking 530 IP compression 532 DF bit 534 DSCP 536 IPsec protocool (AH/ESP) 538 Algorithms 540 Manual SPI 542 Local tunnel endpoint 544 Remote tunnel endpoint 546 Tunnel options 548 Data model for the SAD entries: 550 o SPI 552 o Local peer 554 o Remote peer 556 o SA mode (tunnel or transport) 558 o Security protocol 560 o Sequence number options 562 o Life-time 564 o Upper protocol 566 o Direction 568 o Tunnel source IP address and port 570 o Tunnel Destination IP address and port 572 o AH parameters 573 o ESP parameters 575 o IP compression 577 o NAT traversal flag 579 o Path MTU 581 o Anti-replay window 583 Data model for the PAD entries: 585 o Identifies the peers or groups of peers that are authorized to 586 communicate with this IPsec entity. 588 o The protocol and method used to authenticate each peer. 590 o Authentication data for each peer. 592 o Constraints about the types and values of IDs that can be asserted 593 by a peer with regard to child SA creation. 595 o Peer gateway location info (e.g., IP address(es) or DNS names). 597 Data model for the IKE configuration: 599 o TBD. (NOTE: It may depend on the IKE version) 601 9. Scaling considerations 603 For each new NSF that is added, the existing NSFs may need to be 604 updated with peering information to set up tunnel configuration state 605 to the new node. Setting up this state may need additional message 606 exchanges, and the complexity of this message exchange may merit 607 optimization. 609 10. Use cases examples 611 This section explains three use cases as examples for the SDN-based 612 IPsec Flow Protection Service. 614 10.1. Gateway-to-gateway under the same controller 616 Enterprise A has a headquarter office (HQ) and several branch offices 617 (BO) interconnected through an Internet connection provided by an 618 Internet Service Provider (ISP). This ISP has deployed a SDN-based 619 architecture to provide connectivity to all its clients, including HQ 620 and BOs, so the HQ is provided with a gateway that acts as a router 621 between Internet and each BO's internal network. The gateway 622 implements our Flow-based NSF. 624 Now, Enterprise A requires that certain traffic between the HQ and 625 BOs MUST be protected, for example, with confidentiality and 626 integrity. The Enterprise A's administrator has to configure flow 627 protection policies in the ISP's security controller, determining 628 that the traffic among Enterprise A's HQ (HQ A) and each BO MUST be 629 protected. 631 +----------------------------------------+ 632 | Security Controller | 633 | | 634 (1) | +--------------+ (2)+--------------+ | 635 Flow ----------> | Translate |--->| South. Prot. | | 636 Protect. Pol. | |IPsec Policies| | | | 637 | +--------------+ +--------------+ | 638 | | | | 639 | | | | 640 +--------------------------|-----|-------+ 641 | | 642 | (3) | 643 |-------------------------+ +---| 644 From V V To 645 HQ A +----------------------+ +----------------------+ BO 646 --->| NSF1 |<=======>| NSF2 |----> 647 |IKE/IPsec(SPD/SAD/PAD)| |IKE/IPsec(SPD/SAD/PAD)| 648 +----------------------+ (4) +----------------------+ 650 Figure 3: Gateway-to-Gateway single controller flow for case 1 . 652 Figure 3 describes the case 1: 654 1. The administrator establishes general Flow Protection Policies. 656 2. The controller generates IKE credentials and translates the 657 policies into SPD and PAD entries. 659 3. The controller looks for the NSFs involved (NSF1 and NSF2) and 660 inserts the SPD and PAD entries in both NSF1 and NSF2. 662 4. All packets belonging to the flow that matches the IPsec SPD 663 inserted by the security controller will trigger the IKE 664 negotiation in NSF1 and NSF2 by using the IKE credentials. 666 In case 2, Flow Protection Policies defined by the administrator are 667 also translated into IPsec SPD entries and inserted into the 668 corresponding NSFs. Besides, SAD entries will be also defined by the 669 controller and enforced in the NSFs. In this case the execution of 670 IKE is not necessary in the controller, and a Key Derivation function 671 can be used to provide the required cryptographic material for the 672 IPsec SAs. These keys will be also distributed through the 673 southbound interface. Note that it is possible because both NSFs are 674 managed by the same controller. 676 +----------------------------------------+ 677 | (1) Security Controller | 678 Flow Prot. ---------| | 679 Pol. | V | 680 | +-------------+(2)+---------------+ | 681 | | Key Deriv. &|-->| South. Prot. | | 682 | | Distribution| | | | 683 | +-------------+ +---------------+ | 684 | | | | 685 | | | | 686 +----------------------| --- |-----------+ 687 | | 688 | (3) | 689 |----------------------+ +--| 690 From V V To 691 HQ A +------------------+ +------------------+ BO 692 ------->| NSF1 |<=====>| NSF2 |-------> 693 |IPsec(SPD/SAD/PAD)| 4) |IPsec(SPD/SAD/PAD)| 694 +------------------+ +------------------+ 696 Figure 4: Gateway-to-Gateway single controller flow for case 2. 698 Figure 4 describes the case 2, when a data packet is sent from HQ A 699 with destination BO : 701 1. The administrator establishes Flow Protection Policies. 703 2. The controller translates these policies into IPsec SPD, PAD and 704 SAD entries. 706 3. The controller looks for the NSFs involved and inserts the these 707 entries in both NSF1 and NSF2 IPsec databases. 709 4. All packets belonging to the flow are tunneled between NSF1 and 710 NSF2 by using the enforced configuration keys and parameters. No 711 need to run IKE between NSF1 and NSF2. 713 In general (for case 1 and case 2), this system presents various 714 advantages to the ISP: (i) it allows to create a IPsec SA among two 715 NSFs, with only the application of specific security policies at the 716 application layer. Thus, the ISP can manage all security 717 associations in a centralized point and with an abstracted view of 718 the network; (ii) All NSFs deployed after the application of the new 719 policies will NOT need to be manually configured, thus allowing its 720 deployment in an automated manner. 722 10.2. Gateway-to-gateway under different SDN controllers 724 Two organizations, Enterprise A and Enterprise B, have its 725 headquarters interconnected through an Internet connection provided 726 by different ISPs, called ISP_A and ISP_B. They have deployed a SDN- 727 based architecture to provide Internet connectivity to all its 728 clients, so Enterprise A's headquarters is provisioned with a gateway 729 deployed by ISP_A and Enterprise B's headquarters is provisioned with 730 a gateway deployed by ISP_B. 732 Now, these organizations require that certain traffic among its 733 headquarters to be protected with confidentiality and integrity, so 734 the ISPs have to configure Flow Protection Policies in their security 735 controllers. Both administrators define Flow Protection Policies in 736 each Security Controller that will end with the translation into SPD 737 and PAD entries and IKE credentials in each NSF so that the specified 738 traffic exchanged among these headquarters will be protected. 740 +-------------+ +-------------+ 741 | ISP_A's | | ISP_B's | 742 Flow Prot. | Security |<=================>| Security <--- Flow Prot. 743 Pol. ---> Controller | (3) | Controller | Pol. 744 (1) | | | | (2) 745 +-------------+ +-------------+ 746 | | 747 | (4) (4) | 748 From V V To 749 HQ A +----------------------+ +----------------------+ BO 750 ------>| NSF1 |<========>| NSF2 |-------> 751 |IKE/IPsec(SPD/SAD/PAD)| |IKE/IPsec(SPD/SAD/PAD)| 752 +----------------------+ (5) +----------------------+ 754 Figure 5: Gateway-to-gateway multi controller flow in case 1 756 On the one hand, case 1, Figure 5 describes the data and control 757 plane communications required when a data packet is sent from 758 Enterprise A's HQ (HQ A) to destination Enterprise B's HQ (HQ B): 760 1. The administrator A establishes general Flow Protection Policies 761 in ISP_A's Security Controller 763 2. The administrator B establishes general Flow Protection Policies 764 in ISP_B's Security Controller 766 3. The ISP_A's security controller realizes that protection is 767 between the NSF1 and NSF2, which is under the control of another 768 security controller (ISP_B's security controller), so it starts 769 negotiations with the other controller to agree on the IPsec SPD 770 policies and IKE credentials for their respective NSFs. NOTE: 771 This may require extensions in the East/West interface. 773 4. Then, both security controllers enforce the IKE credentials and 774 related parameters and the SPD and PAD entries in their 775 respective NSFs. 777 5. All packets belonging to the flow that matches the IPsec SPD 778 inserted by the security controller triggers the IKE negotiation 779 between NSF1 and NSF2 by using the enforced configuration keys 780 and parameters. 782 +--------------+ +--------------+ 783 | ISP_A's | | ISP_B's | 784 Flow. ---> IKE? | <---- Flow 785 Prot. | Security |<=================>| Security | Prot. 786 Pol.(1)| Controller | (3) | Controller | Pol. (2) 787 | | | | 788 +--------------+ +--------------+ 789 | | 790 | (4) (4) | 791 From V V To 792 HQ A +------------------+ (5) +------------------+ HQ B 793 ------>| NSF1 |<==============>| NSF2 |----> 794 |IPsec(SPD/SAD/PAD)| |IPsec(SPD/SAD/PAD)| 795 +------------------+ +------------------+ 797 Figure 6: Gateway-to-gateway multi controller flow in case 2 799 On the other hand, case 2, Figure 6 describes the data and control 800 plane communications required when a data packet is sent from 801 Enterprise A's HQ (HQ A) to destination Enterprise B's HQ (HQ B): 803 1. The administrator A establishes general Flow Protection Policies 804 in ISP_A's Security Controller 806 2. The administrator B establishes general Flow Protection Policies 807 in ISP_B's Security Controller 809 3. The ISP_A's security controller realizes that traffic between 810 NSF1 and NSF2 MUST be protected. Nevertheless, the controller 811 notices that NSF2 is under the control of another security 812 controller, so it starts negotiations with the other controller 813 to agree on the IPsec SPD, PAD, SAD entries that define the IPsec 814 SAs. NOTE: It would worth evaluating IKE as the protocol for the 815 the East/West interface in this case. 817 4. Once the controllers have agreed on key material and the details 818 of the IPsec SA, they both enforce this information into their 819 respective NSFs. 821 5. Therefore, all packets belonging to the flow are protected 822 between NSF1 and NSF2 by using the enforced configuration keys 823 and parameters. 825 In general (case 1 and case 2), this system presents various 826 advantages to both ISPs: (i) it allows to create a security 827 association among two network resources across ISPs, from each ISP 828 point of view, only the application of specific Flow Protection 829 Policies at the application layer is needed, so they can manage all 830 security associations in a centralized point and with an abstracted 831 view of the network; (ii) All new resources deployed after the 832 application of the new policies will not need to be manually 833 configured, thus allowing its deployment in an automated manner. 835 10.3. Host-to-gateway 837 End user is a member of Enterprise A who needs to connect to the HQ's 838 internal network. Enterprise A has deployed a NSF acting as IPsec- 839 based VPN concentrator in its HQ to allow members of the organization 840 to connect to the HQ's internal network in a secure manner. 842 Traditionally, VPN concentrators are built as appliances, configured 843 manually to authenticate and establish secure associations with 844 incoming end users users, for example, by running IKE to establish an 845 IPsec tunnel. With the SDN-based management of IPsec we can 846 automatize these configurations. 848 In case 1, as we can see in Figure 7, the administrator configures a 849 Flow Protection Policy in the security controller (1). The 850 controller generates IKE credentials and translates that into SPD and 851 PAD entries and installs them in the corresponding NSF (2). With 852 those policies and IKE credentials, end user and gateway can 853 negotiate IKE. 855 +----------------------------------------+ 856 | Security Controller | 857 | | 858 (1) | +--------------+ +--------------+ | 859 Flow ---------->| Translate |--->| South. Prot. | | 860 Protect. Pol. |IPsec Policies| | | | 861 | +--------------+ +--------------+ | 862 | | | 863 | (2) | | 864 +--------------------------|-------------+ 865 | 866 V 867 +----------+ +-----------------------+ 868 | End user | | NSF | To HQ 869 | IKE/IPsec|<===================>| IKE/IPsec(SPD/SAD/PAD)|-------> 870 +----------+ (3) +-----------------------+ 872 Figure 7: Host-to-gateway flow protection in case 1. 874 In case 2, IKE implementation now resides in the security controller, 875 as we can see in Figure 8. Here, the NSF needs to forward IKE 876 packets to the controller. Therefore, the IKE negotiation is 877 performed by the end user and the security controller (1), being this 878 fact completely transparent for the end user. 880 Once the IKE negotiation has been successfully completed, the IPsec 881 SA is available in the end user and in the security controller. The 882 IPsec SA information is to be provisioned into the NSF's SAD, SPD and 883 PAD (2). Now the end user and the NSF share key material, thus being 884 able to establish an IPsec tunnel to protect all traffic among them 885 (3). 887 In general, this feature allows the configuration of network 888 resources such as VPN concentrators as a service, so these could be 889 deployed and disposed as required by policies, such as network load, 890 in an autonomous manner. 892 +----------------------------------+ 893 | Security Controller | 894 | | 895 | +----------+ +-------------+ | 896 | | IKE |-->| South. Prot.| | 897 | | | | | | 898 | +----------+ +-------------+ | 899 | ^ | | 900 | | | | 901 +--------|-------------|-----------+ 902 | | 903 (1) | | (2) 904 | V 905 +----------+ +--|----------------+ 906 | |<------------+ | 907 | End user | | Gateway | To HQ 908 | IKE/IPsec|<========>| IPsec(SPD/SAD/PAD)|-------> 909 +----------+ (3) +-------------------+ 911 Figure 8: Host-to-gateway flow protection in case 2. 913 One of the main problems of this scenario is that the security 914 controller has to implement IKE and negotiate with the end user. 915 Additionally, it is still unclear the security implications of 916 performing IKE with a different end point than the NSF. Finally, in 917 terms of implementation, the IKE packets should bypass IPsec 918 protection in the NSF and be forwarded to the security controller. 920 11. Security Considerations 922 TBD. 924 12. Acknowledgements 926 Authors want to thank David Carrel, Yoav Nir, Tero Kivinen, Linda 927 Dunbar, Carlos J. Bernardos, Alejandro Perez-Mendez and Alejandro 928 Abad-Carrascosa for their valuable comments. 930 13. References 932 13.1. Normative References 934 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 935 Requirement Levels", BCP 14, RFC 2119, 936 DOI 10.17487/RFC2119, March 1997, 937 . 939 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 940 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 941 DOI 10.17487/RFC5226, May 2008, 942 . 944 13.2. Informative References 946 [I-D.ietf-i2nsf-framework] 947 Lopez, E., Lopez, D., Dunbar, L., Strassner, J., Zhuang, 948 X., Parrott, J., Krishnan, R., Durbha, S., Kumar, R., and 949 A. Lohiya, "Framework for Interface to Network Security 950 Functions", draft-ietf-i2nsf-framework-03 (work in 951 progress), August 2016. 953 [I-D.ietf-i2nsf-problem-and-use-cases] 954 Hares, S., Dunbar, L., Lopez, D., Zarny, M., and C. 955 Jacquenet, "I2NSF Problem Statement and Use cases", draft- 956 ietf-i2nsf-problem-and-use-cases-02 (work in progress), 957 October 2016. 959 [I-D.ietf-i2nsf-terminology] 960 Hares, S., Strassner, J., Lopez, D., Xia, L., and H. 961 Birkholz, "Interface to Network Security Functions (I2NSF) 962 Terminology", draft-ietf-i2nsf-terminology-02 (work in 963 progress), October 2016. 965 [I-D.jeong-i2nsf-sdn-security-services-05] 966 Jeong, J., Kim, H., Park, J., Ahn, T., and S. Lee, 967 "Software-Defined Networking Based Security Services using 968 Interface to Network Security Functions", draft-jeong- 969 i2nsf-sdn-security-services-05 (work in progress), July 970 2016. 972 [I-D.pfkey-spd] 973 Sakane, S., "PF_KEY Extensions for IPsec Policy Management 974 in KAME Stack", October 2002. 976 [I-D.tran-ipsecme-yang] 977 Tran, K., Wang, H., Nagaraj, V., and X. Chen, "Yang Data 978 Model for Internet Protocol Security (IPsec)", draft-tran- 979 ipsecme-yang-01 (work in progress), June 2015. 981 [ITU-T.X.1252] 982 "Baseline Identity Management Terms and Definitions", 983 April 2010. 985 [ITU-T.X.800] 986 "Security Architecture for Open Systems Interconnection 987 for CCITT Applications", March 1991. 989 [ITU-T.Y.3300] 990 "Recommendation ITU-T Y.3300", June 2014. 992 [netconf-vpn] 993 Stefan Wallin, "Tutorial: NETCONF and YANG", January 2014. 995 [ONF-OpenFlow] 996 ONF, "OpenFlow Switch Specification (Version 1.4.0)", 997 October 2013. 999 [ONF-SDN-Architecture] 1000 "SDN Architecture", June 2014. 1002 [RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key 1003 Management API, Version 2", RFC 2367, 1004 DOI 10.17487/RFC2367, July 1998, 1005 . 1007 [RFC3549] Salim, J., Khosravi, H., Kleen, A., and A. Kuznetsov, 1008 "Linux Netlink as an IP Services Protocol", RFC 3549, 1009 DOI 10.17487/RFC3549, July 2003, 1010 . 1012 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1013 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 1014 December 2005, . 1016 [RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and 1017 Internet Key Exchange (IKE) Document Roadmap", RFC 6071, 1018 DOI 10.17487/RFC6071, February 2011, 1019 . 1021 [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined 1022 Networking: A Perspective from within a Service Provider 1023 Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, 1024 . 1026 Authors' Addresses 1027 Rafa Marin-Lopez 1028 University of Murcia 1029 Campus de Espinardo S/N, Faculty of Computer Science 1030 Murcia 30100 1031 Spain 1033 Phone: +34 868 88 85 01 1034 Email: rafa@um.es 1036 Gabriel Lopez-Millan 1037 University of Murcia 1038 Campus de Espinardo S/N, Faculty of Computer Science 1039 Murcia 30100 1040 Spain 1042 Phone: +34 868 88 85 04 1043 Email: gabilm@um.es 1045 Sowmini Varadhan 1046 Oracle 1047 Redwood Shores, CA 1048 USA 1050 Email: sowmini.varadhan@oracle.com