idnits 2.17.1 draft-abad-i2nsf-sdn-ipsec-flow-protection-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 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 (July 8, 2016) is 2820 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC5226' is defined on line 881, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2nsf-framework' is defined on line 888, but no explicit reference was found in the text == Unused Reference: 'I-D.jeong-i2nsf-sdn-security-services-05' is defined on line 901, 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-02 == Outdated reference: A later version (-08) exists of draft-ietf-i2nsf-terminology-00 -- No information found for draft-pfkey-spd - is the name correct? Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2NSF R. Marin-Lopez 3 Internet-Draft G. Lopez-Millan 4 Intended status: Experimental University of Murcia 5 Expires: January 9, 2017 July 8, 2016 7 Software-Defined Networking (SDN)-based IPsec Flow Protection 8 draft-abad-i2nsf-sdn-ipsec-flow-protection-00 10 Abstract 12 This document describes the use case of providing IPsec-based flow 13 protection by means of a Software-Defined Network (SDN) controller 14 and raises the requirements to support this service. It considers 15 two main scenarios: (i) gateway-to-gateway and (ii) host-to-gateway 16 (Road Warrior). For the gateway-to-gateway scenario, this document 17 describes a mechanism to support the distribution of IPsec 18 information to flow-based Network Security Functions (NSFs) that 19 implements IPsec to protect data traffic. between network resources 20 to protect data traffic with IPsec and IKE, in intra and inter-SDN 21 cases. The host-to-gateway case defines a mechanism to distribute 22 IPsec information to the NSF to protect data with IPsec between an 23 end user's device (host) and a gateway. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 9, 2017. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 61 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 5. Case 1: IKE/IPsec in the NSF . . . . . . . . . . . . . . . . 5 64 5.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 6 65 6. Case 2: IPsec (no IKE) in the NSF . . . . . . . . . . . . . . 7 66 6.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 7 67 7. Abstract interfaces . . . . . . . . . . . . . . . . . . . . . 8 68 8. Data model . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 9. Use cases examples . . . . . . . . . . . . . . . . . . . . . 12 70 9.1. Gateway-to-gateway under the same controller . . . . . . 12 71 9.2. Gateway-to-gateway under different SDN controllers . . . 15 72 9.3. Host-to-gateway . . . . . . . . . . . . . . . . . . . . . 17 73 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 74 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 75 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 76 12.1. Normative References . . . . . . . . . . . . . . . . . . 19 77 12.2. Informative References . . . . . . . . . . . . . . . . . 20 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 80 1. Introduction 82 Software-Defined Networking (SDN) is an architecture that enables 83 users to directly program, orchestrate, control and manage network 84 resources through software. SDN paradigm relocates the control of 85 network resources to a dedicated network element, namely SDN 86 controller. The SDN controller manages and configures the 87 distributed network resources and provides an abstracted view of the 88 network resources to the SDN applications. The SDN application can 89 customize and automate the operations (including management) of the 90 abstracted network resources in a programmable manner via this 91 interface [RFC7149][ITU-T.Y.3300] 92 [ONF-SDN-Architecture][ONF-OpenFlow]. 94 Typically, traditional IPsec VPN concentrators and, in general, 95 gateways supporting IKE/IPsec, are configured manually. This makes 96 the IPsec security association (SA) management difficult and 97 generates a lack of flexibility, specially if the number of security 98 policies and SAs to handle is high. With the grow of SDN-based 99 scenarios where network resources are deployed in an autonomous 100 manner, a mechanism to manage IPsec SAs according to the SDN 101 architecture becomes more relevant. Thus, the SDN-based service 102 described in this document will autonomously deal with IPsec-based 103 data protection also in such as an autonomous manner. 105 IPsec architecture [RFC4301] defines a clear separation between the 106 processing to provide security services to IP packets and the key 107 management procedures to establish the IPsec security association. 108 In this document, we defined that a service where the key management 109 procedures can be carried by an external entity: the security 110 controller. 112 First, this document exposes the requirements to support the 113 protection of data flows using IPsec [RFC4301]. We consider two 114 cases: 116 1) The network resource (or Network Security Function, NSF) 117 implements the Internet Key Exchange (IKE) protocol and the IPsec 118 databases: the Security Policy Database (SPD), the Security 119 Association Database (SAD) and the Peer Authorization Database 120 (PAD). The controller is in charge of provisioning the NSF with 121 the required information about IKE, the SPD and the PAD. 123 2) The NSF only implements the IPsec databases (no IKE 124 implementation). The controller will provide the required 125 parameters to create valid entries in the PAD, the SPD and the 126 SAD in the NSF. Therefore, the NSF will have only support for 127 IPsec while automated key management functionality is moved to 128 the controller. 130 In both cases, an interface/protocol will be required to carry out 131 this provisioning between the security controller and the NSF. In 132 particular, it is required the provision of SPD and PAD entries and 133 the credentials and information related with the IKE negotiation 134 (case 1); or the required SPD, PAD and SAD entries with information 135 such as keys, cryptographic algorithms, IP addresses, IPsec protocol 136 (AH or ESP), IPsec protocol mode (tunnel or transport), lifetime of 137 the SA, etc (case 2). An example for case 1 using NETFCONF/YANG can 138 be found in [netconf-vpn]. A YANG model for IPsec can be found in 139 [I-D.tran-ipsecme-yang]. 141 Second, this document considers two scenarios to manage autonomously 142 IPsec SAs: gateway-to-gateway and host-to-gateway [RFC6071]. The 143 gateway-to-gateway scenario shows how flow protection services are 144 useful when data is to be protected across gateways in the network. 146 Each gateway will implement a flow-based NSF. The use case described 147 in Section 9.1 depicts how these services could be used to protect IP 148 traffic among various geographically distributed networks under the 149 domain of the same security controller. A variant of this scenario 150 is also covered in Section 9.2, where the NSFs involved are under the 151 control of different security controllers. 153 The host-to-gateway scenario described in Section 9.3 covers the case 154 where one end user belonging to a network wants to access securely 155 its network from another external network. In such a case, an IPsec 156 SA needs to be established between the end user's host and the 157 gateway, which is a flow-based NSF. In this document, we describe 158 how the security controller can still configure automatically the 159 IPsec SA in the NSF. 161 2. Requirements Language 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 165 document are to be interpreted as described in RFC 2119 [RFC2119]. 166 When these words appear in lower case, they have their natural 167 language meaning. 169 3. Terminology 171 This document uses the terminology described in [RFC7149], [RFC4301], 172 [ITU-T.Y.3300], [ONF-SDN-Architecture], [ONF-OpenFlow], 173 [ITU-T.X.1252], [ITU-T.X.800] and [I-D.ietf-i2nsf-terminology]. In 174 addition, the following terms are defined below: 176 o Software-Defined Networking. A set of techniques enabling to 177 directly program, orchestrate, control, and manage network 178 resources, which facilitates the design, delivery and operation of 179 network services in a dynamic and scalable manner [ITU-T.Y.3300]. 181 o Flow/Data Flow. Set of network packets sharing a set of 182 characteristics, for example IP dst/src values or QoS parameters. 184 o Flow Protection Policy. The set of rules defining the conditions 185 under which a data flow MUST be protected with IPsec, and the 186 rules that MUST be applied to the specific flow. 188 o IKE. Protocol to establish IPsec Security Associations (SAs). It 189 requires information about the required authentication method 190 (i.e. preshared keys), DH groups, modes and algorithms for IKE 191 phase 1, etc. 193 o SPD. IPsec Security Policy Database. It includes information 194 about IPsec policies direction (in, out), local and remote 195 addresses, inbound and outboud SAs, etc. 197 o SAD. IPsec Security Associations Database. It includes 198 information about IPsec security associations, such as SPI, 199 destination addresses, authentication and encryption algorithms 200 and keys. 202 o PAD. Peer Authorization Database. It provides the link between 203 the SPD and a security association management protocol such as IKE 204 or our SDN-based solution. 206 4. Objectives 208 o Flow-based data protection: controller-based flow protection 209 services based on IPsec to allow the protection of specific data 210 flows based on defined security policies. 212 o Establishment and management of IPsec security associations: this 213 service allows the centralized management of IPsec SAs to protect 214 specific data flows. 216 5. Case 1: IKE/IPsec in the NSF 218 In this case, the security controller is in charge of controlling and 219 applying SPD and PAD entries in the NSF. It also has to apply IKE 220 configuration parameters and derive and deliver IKE credentials (e.g. 221 a pre-shared key) to the NSF for the IKE negotiation. In short, we 222 would call this IKE credential. 224 With these entries and credentials, the IKE implementation can 225 operate to establish the IPsec SAs. The application (administrator) 226 will send the IPsec requirements and end points information, and the 227 security controller will translate those requirements into SPD 228 entries that will be installed in the NSF. With that information 229 provisioned in the NSF, when the data flow needs to be protected, the 230 NSF can just run IKE to establish the required IPsec SA. Figure 1 231 shows the different layers and corresponding functionality. 233 Advantages: It is simple because current gateways typically have an 234 IKE/IPsec implementation. 236 Disadvantages: IKE implementations need to renegotiate IPsec SAs upon 237 SPD entries changes without restarting IKE daemon. 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | IPsec Management/Orchestration Application| Client or 241 | I2NSF Client | App Gateway 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Client Facing Interface 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 Vendor | Application Support | 246 Facing <--->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Security 247 Interface | IKE Credential and SPD Policies Distribution| Controller 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | NSF Facing Interface 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | I2NSF Agent | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Network 253 | IKE | IPsec(SPD,SAD,PAD) | Security 254 +-------------------------------------------- + Function (NSF) 255 | Data Protection and Forwarding | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 Figure 1: Case 1: IKE/IPsec in the NSF 260 5.1. Requirements 262 SDN-based IPsec flow protection services provide dynamic and flexible 263 network resource management to protect data flows among network 264 resources and end users. In order to support this capability in case 265 1, the following requirements are to be met: 267 o The NSF MUST implement IKE and IPsec databases: SPD, SAD and PAD. 268 It MUST provide an (southbound) interface to provision SPD and PAD 269 entries, IKE Credentials and to monitor the IPsec databases and 270 IKE implementation. Note that SAD entries are created in runtime 271 by IKE. 273 o A southbound protocol MUST support sending these SPD and PAD 274 entries, and IKE credentials to the NSF. 276 o It requires an (northbound) application interface in the security 277 controller allowing the management of IPsec SAs. 279 o In scenarios where multiple controllers are implicated, SDN-based 280 flow protection service may require a mechanism to discover which 281 security controller is managing a specific NSF. 283 6. Case 2: IPsec (no IKE) in the NSF 285 This section describes the referenced architecture to support SDN- 286 based IPsec flow protection where the security controller performs 287 automated key management tasks. 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | IPsec Management/Orchestration Application| Client or 291 | I2NSF Client | App Gateway 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Client Facing Interface 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 Vendor | Application Support | 296 Facing <--->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Security 297 Interface | SPD, SAD and PAD Entries Distr. | Controller 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Key Derivation and Distribution | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | NSF Facing Interface 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | I2NSF Agent | Network 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Security 305 | IPSec (SPD,SAD,PAD) | Function (NSF) 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Data Protection and Forwarding | 308 +---------------------------------------------+ 310 Figure 2: Case 2: IPsec (no IKE) in the NSF 312 As shown in Figure 2, applications for flow protection run on the top 313 of the security controller. When an administrator enforces flow 314 protection policies through an application interface, the security 315 controller translates those requirements into SPD,PAD and SAD entries 316 that will be installed in the NSF. 318 Advantages: 1) It allows lighter NSFs (no IKE implementation). 2) IKE 319 does not need to be run in gateway-to-gateway scenario with a single 320 controller (see Section 9.1). 322 Disadvantages: The overload of IPsec SA establishment is shifted to 323 the security controller since IKE is not required in the NSF. 325 6.1. Requirements 327 In order to support case 2, the following requirements are to be met: 329 o It requires the provision of SPD, PAD and SAD entries into the 330 NSF. A southbound protocol MUST support sending this information 331 to the NSF. 333 o NSF MUST be capable to protect data flows with IPsec, such as the 334 capability to forward data through an IPsec tunnel. 336 o It requires an (northbound) application interface in the security 337 controller allowing the management of IPsec policies. 339 o In scenarios where multiple controllers are implicated, SDN-based 340 flow protection service may require a mechanism to discover which 341 security controller is managing a specific NSF. 343 7. Abstract interfaces 345 The cases presented above require an analysis of the communication 346 channel between the IPSec stack and the security controller that is 347 performing the key management operations. 349 The IETF RFC 2367 (PF_KEYv2) [RFC2367] provides a generic key 350 management API that can be used not only for IPsec but also for other 351 network security services to manage the IPsec SAD. Besides, as an 352 extension to this API, the document [I-D.pfkey-spd] specifies some 353 PF_KEY extensions to maintain the SPD. This API is accessed using 354 sockets. 356 An I2NSF Agent implementation in the NSF can interact with both APIs 357 in a kernel and returns and provides the same information using the 358 NSF Facing Interface. In the following, we show a summary of these 359 messages just to show an example of what may provide the NSF Facing 360 Interface. The details and the accurate information is in RFC 2367 361 and [I-D.pfkey-spd]. 363 To manage the IPsec SAD we have the following messages in the 364 PF_KEYv2 API: 366 o The SADB_GETSPI message allows a process to obtain a unique SPI 367 value for given security association type, source address, and 368 destination address. This message followed by an SADB_UPDATE is 369 one way to create a security association (SADB_ADD is the other 370 method). 372 o The SADB_UPDATE message allows a process to update the information 373 in an existing Security Association. 375 o The SADB_ADD message is nearly identical to the SADB_UPDATE 376 message, except that it does not require a previous call to 377 SADB_GETSPI. 379 o The SADB_DELETE message causes the kernel to delete an IPsec SA 380 from the SAD. 382 o The SADB_GET message allows a process to retrieve a copy of a 383 Security Association from the SAD. 385 o The SADB_ACQUIRE message is typically triggered by an outbound 386 packet that needs security but for which there is no applicable 387 IPsec SA existing in the SAD. 389 o The SADB_REGISTER message allows (a socket) to receive 390 SADB_ACQUIRE messages for the type of IPsec SA. 392 o The SADB_EXPIRE message is issued when soft limit or hard limit 393 (lifetime) of a IPsec SA has expired. 395 o The SADB_FLUSH message causes the kernel to delete all entries in 396 its IPsec SAD. 398 o The SADB_DUMP message causes to dump the operating system's entire 399 IPsec SAD. 401 Although it is not a standard, KAME IPsec has defined a set of 402 extensions to PF_KEY in order to handle the SPD [I-D.pfkey-spd]. The 403 extended API offers the addtional extensions: 405 o The SADB_X_SPDSETIDX message allows a process to add only selector 406 of the security policy entry to the SPD. 408 o The SADB_X_SPDUPDATE message replaces the parameters of an 409 existing SPD entry. 411 o The SADB_X_SPDADD is message allows a process to add a new 412 security policy entry to the SPD. 414 o The SADB_X_SPDDELETE message causes the kernel to delete an entry 415 from the SPD. 417 o The SADB_X_SPDDELETE2 message nearly identical to the 418 SADB_X_SPDDELETE message, except that it specifies the policy id. 420 o The SADB_X_SPDGET message is allows a process to retrieve a copy 421 of a security policy entry from the SPD. 423 o The SADB_X_SPDACQUIRE message is triggered by an outbound packet 424 that needs security policy but for which there is no applicable 425 information existing in the SPD. 427 o The SADB_X_SPDEXPIRE message is issued when limit of a security 428 policy (SPD entry) has expired. 430 o The SADB_X_SPDFLUSH message causes the kernel to delete all 431 entries in the IPsec SPD. 433 o The SADB_DUMP causes the kernel to dump all entries in the IPsec 434 SPD. 436 Regarding PAD management, we have not found any related extension. 437 However, from the abstract data model defined in Section 8 for the 438 PAD an interface could be designed. 440 8. Data model 442 These cases assume a data model representing the information to be 443 exchanged between controller and network resource through the 444 southbound interface. As described before this data model has to 445 include the following information [RFC4301] (sketch that needs to be 446 developed): 448 Data model for the SDP entries: 450 o Name 452 o PFP flags 454 o Perfect forward secrecy 456 o Selector list: 458 Remote IP addresses(es) 460 Local IP addresses(es) 462 Flow direction 464 Next Layer Protocol 466 Local port 468 Remote port 470 Type code 472 o Processing: 474 Extended sequence number 476 Sequence overflow 478 Fragment checking 480 IP compression 482 DF bit 484 DSCP 486 IPsec protocool (AH/ESP) 488 Algorithms 490 Manual SPI 492 Local tunnel endpoint 494 Remote tunnel endpoint 496 Tunnel options 498 Data model for the SAD entries: 500 o SPI 502 o Local peer 504 o Remote peer 506 o SA mode (tunnel or transport) 508 o Security protocol 510 o Sequence number options 512 o Life-time 514 o Upper protocol 516 o Direction 518 o Tunnel source IP address and port 519 o Tunnel Destination IP address and port 521 o AH parameters 523 o ESP parameters 525 o IP compression 527 o NAT traversal flag 529 o Path MTU 531 o Anti-replay window 533 Data model for the PAD entries: 535 o Identifies the peers or groups of peers that are authorized to 536 communicate with this IPsec entity. 538 o The protocol and method used to authenticate each peer. 540 o Authentication data for each peer. 542 o Constraints about the types and values of IDs that can be asserted 543 by a peer with regard to child SA creation. 545 o Peer gateway location info (e.g., IP address(es) or DNS names). 547 Data model for the IKE configuration: 549 o TBD. (NOTE: It may depend on the IKE version) 551 9. Use cases examples 553 This section explains three use cases as examples for the SDN-based 554 IPsec Flow Protection Service. 556 9.1. Gateway-to-gateway under the same controller 558 Enterprise A has a headquarter office (HQ) and several branch offices 559 (BO) interconnected through an Internet connection provided by an 560 Internet Service Provider (ISP). This ISP has deployed a SDN-based 561 architecture to provide connectivity to all its clients, including HQ 562 and BOs, so the HQ is provided with a gateway that acts as a router 563 between Internet and each BO's internal network. The gateway 564 implements our Flow-based NSF. 566 Now, Enterprise A requires that certain traffic between the HQ and 567 BOs MUST be protected, for example, with confidentiality and 568 integrity. The Enterprise A's administrator has to configure flow 569 protection policies in the ISP's security controller, determining 570 that the traffic among Enterprise A's HQ (HQ A) and each BO MUST be 571 protected. 573 +----------------------------------------+ 574 | Security Controller | 575 | | 576 (1) | +--------------+ (2)+--------------+ | 577 Flow ----------> | Translate |--->| South. Prot. | | 578 Protect. Pol. | |IPsec Policies| | | | 579 | +--------------+ +--------------+ | 580 | | | | 581 | | | | 582 +--------------------------|-----|-------+ 583 | | 584 | (3) | 585 |-------------------------+ +---| 586 From V V To 587 HQ A +----------------------+ +----------------------+ BO 588 --->| NSF1 |<=======>| NSF2 |----> 589 |IKE/IPsec(SPD/SAD/PAD)| |IKE/IPsec(SPD/SAD/PAD)| 590 +----------------------+ (4) +----------------------+ 592 Figure 3: Gateway-to-Gateway single controller flow for case 1 . 594 Figure 3 describes the case 1: 596 1. The administrator establishes general Flow Protection Policies. 598 2. The controller generates IKE credentials and translates the 599 policies into SPD and PAD entries. 601 3. The controller looks for the NSFs involved (NSF1 and NSF2) and 602 inserts the SPD and PAD entries in both NSF1 and NSF2. 604 4. All packets belonging to the flow that matches the IPsec SPD 605 inserted by the security controller will trigger the IKE 606 negotiation in NSF1 and NSF2 by using the IKE credentials. 608 In case 2, Flow Protection Policies defined by the administrator are 609 also translated into IPsec SPD entries and inserted into the 610 corresponding NSFs. Besides, SAD entries will be also defined by the 611 controller and enforced in the NSFs. In this case the execution of 612 IKE is not necessary in the controller, and a Key Derivation function 613 can be used to provide the required cryptographic material for the 614 IPsec SAs. These keys will be also distributed through the 615 southbound interface. Note that it is possible because both NSFs are 616 managed by the same controller. 618 +----------------------------------------+ 619 | (1) Security Controller | 620 Flow Prot. ---------| | 621 Pol. | V | 622 | +-------------+(2)+---------------+ | 623 | | Key Deriv. &|-->| South. Prot. | | 624 | | Distribution| | | | 625 | +-------------+ +---------------+ | 626 | | | | 627 | | | | 628 +----------------------| --- |-----------+ 629 | | 630 | (3) | 631 |----------------------+ +--| 632 From V V To 633 HQ A +------------------+ +------------------+ BO 634 ------->| NSF1 |<=====>| NSF2 |-------> 635 |IPsec(SPD/SAD/PAD)| 4) |IPsec(SPD/SAD/PAD)| 636 +------------------+ +------------------+ 638 Figure 4: Gateway-to-Gateway single controller flow for case 2. 640 Figure 4 describes the case 2, when a data packet is sent from HQ A 641 with destination BO : 643 1. The administrator establishes Flow Protection Policies. 645 2. The controller translates these policies into IPsec SPD, PAD and 646 SAD entries. 648 3. The controller looks for the NSFs involved and inserts the these 649 entries in both NSF1 and NSF2 IPsec databases. 651 4. All packets belonging to the flow are tunneled between NSF1 and 652 NSF2 by using the enforced configuration keys and parameters. No 653 need to run IKE between NSF1 and NSF2. 655 In general (for case 1 and case 2), this system presents various 656 advantages to the ISP: (i) it allows to create a IPsec SA among two 657 NSFs, with only the application of specific security policies at the 658 application layer. Thus, the ISP can manage all security 659 associations in a centralized point and with an abstracted view of 660 the network; (ii) All NSFs deployed after the application of the new 661 policies will NOT need to be manually configured, thus allowing its 662 deployment in an automated manner. 664 9.2. Gateway-to-gateway under different SDN controllers 666 Two organizations, Enterprise A and Enterprise B, have its 667 headquarters interconnected through an Internet connection provided 668 by different ISPs, called ISP_A and ISP_B. They have deployed a SDN- 669 based architecture to provide Internet connectivity to all its 670 clients, so Enterprise A's headquarters is provisioned with a gateway 671 deployed by ISP_A and Enterprise B's headquarters is provisioned with 672 a gateway deployed by ISP_B. 674 Now, these organizations require that certain traffic among its 675 headquarters to be protected with confidentiality and integrity, so 676 the ISPs have to configure Flow Protection Policies in their security 677 controllers. Both administrators define Flow Protection Policies in 678 each Security Controller that will end with the translation into SPD 679 and PAD entries and IKE credentials in each NSF so that the specified 680 traffic exchanged among these headquarters will be protected. 682 +-------------+ +-------------+ 683 | ISP_A's | | ISP_B's | 684 Flow Prot. | Security |<=================>| Security <--- Flow Prot. 685 Pol. ---> Controller | (3) | Controller | Pol. 686 (1) | | | | (2) 687 +-------------+ +-------------+ 688 | | 689 | (4) (4) | 690 From V V To 691 HQ A +----------------------+ +----------------------+ BO 692 ------>| NSF1 |<========>| NSF2 |-------> 693 |IKE/IPsec(SPD/SAD/PAD)| |IKE/IPsec(SPD/SAD/PAD)| 694 +----------------------+ (5) +----------------------+ 696 Figure 5: Gateway-to-gateway multi controller flow in case 1 698 On the one hand, case 1, Figure 5 describes the data and control 699 plane communications required when a data packet is sent from 700 Enterprise A's HQ (HQ A) to destination Enterprise B's HQ (HQ B): 702 1. The administrator A establishes general Flow Protection Policies 703 in ISP_A's Security Controller 705 2. The administrator B establishes general Flow Protection Policies 706 in ISP_B's Security Controller 708 3. The ISP_A's security controller realizes that protection is 709 between the NSF1 and NSF2, which is under the control of another 710 security controller (ISP_B's security controller), so it starts 711 negotiations with the other controller to agree on the IPsec SPD 712 policies and IKE credentials for their respective NSFs. NOTE: 713 This may require extensions in the East/West interface. 715 4. Then, both security controllers enforce the IKE credentials and 716 related parameters and the SPD and PAD entries in their 717 respective NSFs. 719 5. All packets belonging to the flow that matches the IPsec SPD 720 inserted by the security controller triggers the IKE negotiation 721 between NSF1 and NSF2 by using the enforced configuration keys 722 and parameters. 724 +--------------+ +--------------+ 725 | ISP_A's | | ISP_B's | 726 Flow. ---> IKE? | <---- Flow 727 Prot. | Security |<=================>| Security | Prot. 728 Pol.(1)| Controller | (3) | Controller | Pol. (2) 729 | | | | 730 +--------------+ +--------------+ 731 | | 732 | (4) (4) | 733 From V V To 734 HQ A +------------------+ (5) +------------------+ HQ B 735 ------>| NSF1 |<==============>| NSF2 |----> 736 |IPsec(SPD/SAD/PAD)| |IPsec(SPD/SAD/PAD)| 737 +------------------+ +------------------+ 739 Figure 6: Gateway-to-gateway multi controller flow in case 2 741 On the other hand, case 2, Figure 6 describes the data and control 742 plane communications required when a data packet is sent from 743 Enterprise A's HQ (HQ A) to destination Enterprise B's HQ (HQ B): 745 1. The administrator A establishes general Flow Protection Policies 746 in ISP_A's Security Controller 748 2. The administrator B establishes general Flow Protection Policies 749 in ISP_B's Security Controller 751 3. The ISP_A's security controller realizes that traffic between 752 NSF1 and NSF2 MUST be protected. Nevertheless, the controller 753 notices that NSF2 is under the control of another security 754 controller, so it starts negotiations with the other controller 755 to agree on the IPsec SPD, PAD, SAD entries that define the IPsec 756 SAs. NOTE: It would worth evaluating IKE as the protocol for the 757 the East/West interface in this case. 759 4. Once the controllers have agreed on key material and the details 760 of the IPsec SA, they both enforce this information into their 761 respective NSFs. 763 5. Therefore, all packets belonging to the flow are protected 764 between NSF1 and NSF2 by using the enforced configuration keys 765 and parameters. 767 In general (case 1 and case 2), this system presents various 768 advantages to both ISPs: (i) it allows to create a security 769 association among two network resources across ISPs, from each ISP 770 point of view, only the application of specific Flow Protection 771 Policies at the application layer is needed, so they can manage all 772 security associations in a centralized point and with an abstracted 773 view of the network; (ii) All new resources deployed after the 774 application of the new policies will not need to be manually 775 configured, thus allowing its deployment in an automated manner. 777 9.3. Host-to-gateway 779 End user is a member of Enterprise A who needs to connect to the HQ's 780 internal network. Enterprise A has deployed a NSF acting as IPsec- 781 based VPN concentrator in its HQ to allow members of the organization 782 to connect to the HQ's internal network in a secure manner. 784 Traditionally, VPN concentrators are built as appliances, configured 785 manually to authenticate and establish secure associations with 786 incoming end users users, for example, by running IKE to establish an 787 IPsec tunnel. With the SDN-based management of IPsec we can 788 automatize these configurations. 790 In case 1, as we can see in Figure 7, the administrator configures a 791 Flow Protection Policy in the security controller (1). The 792 controller generates IKE credentials and translates that into SPD and 793 PAD entries and installs them in the corresponding NSF (2). With 794 those policies and IKE credentials, end user and gateway can 795 negotiate IKE. 797 +----------------------------------------+ 798 | Security Controller | 799 | | 800 (1) | +--------------+ +--------------+ | 801 Flow ---------->| Translate |--->| South. Prot. | | 802 Protect. Pol. |IPsec Policies| | | | 803 | +--------------+ +--------------+ | 804 | | | 805 | (2) | | 806 +--------------------------|-------------+ 807 | 808 V 809 +----------+ +-----------------------+ 810 | End user | | NSF | To HQ 811 | IKE/IPsec|<===================>| IKE/IPsec(SPD/SAD/PAD)|-------> 812 +----------+ (3) +-----------------------+ 814 Figure 7: Host-to-gateway flow protection in case 1. 816 In case 2, IKE implementation now resides in the security controller, 817 as we can see in Figure 8. Here, the NSF needs to forward IKE 818 packets to the controller. Therefore, the IKE negotiation is 819 performed by the end user and the security controller (1), being this 820 fact completely transparent for the end user. 822 Once the IKE negotiation has been successfully completed, the IPsec 823 SA is available in the end user and in the security controller. The 824 IPsec SA information is to be provisioned into the NSF's SAD, SPD and 825 PAD (2). Now the end user and the NSF share key material, thus being 826 able to establish an IPsec tunnel to protect all traffic among them 827 (3). 829 In general, this feature allows the configuration of network 830 resources such as VPN concentrators as a service, so these could be 831 deployed and disposed as required by policies, such as network load, 832 in an autonomous manner. 834 +----------------------------------+ 835 | Security Controller | 836 | | 837 | +----------+ +-------------+ | 838 | | IKE |-->| South. Prot.| | 839 | | | | | | 840 | +----------+ +-------------+ | 841 | ^ | | 842 | | | | 843 +--------|-------------|-----------+ 844 | | 845 (1) | | (2) 846 | V 847 +----------+ +--|----------------+ 848 | |<------------+ | 849 | End user | | Gateway | To HQ 850 | IKE/IPsec|<========>| IPsec(SPD/SAD/PAD)|-------> 851 +----------+ (3) +-------------------+ 853 Figure 8: Host-to-gateway flow protection in case 2. 855 One of the main problems of this scenario is that the security 856 controller has to implement IKE and negotiate with the end user. 857 Additionally, it is still unclear the security implications of 858 performing IKE with a different end point than the NSF. Finally, in 859 terms of implementation, the IKE packets should bypass IPsec 860 protection in the NSF and be forwarded to the security controller. 862 10. Security Considerations 864 TBD. 866 11. Acknowledgements 868 Authors want to thank Sowmini Varadhan, Linda Dunbar, Carlos J. 869 Bernardos, Alejandro Perez-Mendez and Alejandro Abad-Carrascosa for 870 their valuable comments. 872 12. References 874 12.1. Normative References 876 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 877 Requirement Levels", BCP 14, RFC 2119, 878 DOI 10.17487/RFC2119, March 1997, 879 . 881 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 882 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 883 DOI 10.17487/RFC5226, May 2008, 884 . 886 12.2. Informative References 888 [I-D.ietf-i2nsf-framework] 889 elopez@fortinet.com, e., Lopez, D., Dunbar, L., Strassner, 890 J., Zhuang, X., Parrott, J., Krishnan, R., and S. Durbha, 891 "Framework for Interface to Network Security Functions", 892 draft-ietf-i2nsf-framework-02 (work in progress), July 893 2016. 895 [I-D.ietf-i2nsf-terminology] 896 Hares, S., Strassner, J., Lopez, D., and L. Xia, 897 "Interface to Network Security Functions (I2NSF) 898 Terminology", draft-ietf-i2nsf-terminology-00 (work in 899 progress), May 2016. 901 [I-D.jeong-i2nsf-sdn-security-services-05] 902 Jeong, J., Kim, H., Park, J., Ahn, T., and S. Lee, 903 "Software-Defined Networking Based Security Services using 904 Interface to Network Security Functions", draft-jeong- 905 i2nsf-sdn-security-services-05 (work in progress), July 906 2016. 908 [I-D.pfkey-spd] 909 Sakane, S., "PF_KEY Extensions for IPsec Policy Management 910 in KAME Stack", October 2002. 912 [I-D.tran-ipsecme-yang] 913 Tran, K., Wang, H., Nagaraj, V., and X. Chen, "Yang Data 914 Model for Internet Protocol Security (IPsec)", draft-tran- 915 ipsecme-yang-01 (work in progress), June 2015. 917 [ITU-T.X.1252] 918 "Baseline Identity Management Terms and Definitions", 919 April 2010. 921 [ITU-T.X.800] 922 "Security Architecture for Open Systems Interconnection 923 for CCITT Applications", March 1991. 925 [ITU-T.Y.3300] 926 "Recommendation ITU-T Y.3300", June 2014. 928 [netconf-vpn] 929 Stefan Wallin, "Tutorial: NETCONF and YANG", January 2014. 931 [ONF-OpenFlow] 932 ONF, "OpenFlow Switch Specification (Version 1.4.0)", 933 October 2013. 935 [ONF-SDN-Architecture] 936 "SDN Architecture", June 2014. 938 [RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key 939 Management API, Version 2", RFC 2367, 940 DOI 10.17487/RFC2367, July 1998, 941 . 943 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 944 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 945 December 2005, . 947 [RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and 948 Internet Key Exchange (IKE) Document Roadmap", RFC 6071, 949 DOI 10.17487/RFC6071, February 2011, 950 . 952 [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined 953 Networking: A Perspective from within a Service Provider 954 Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, 955 . 957 Authors' Addresses 959 Rafa Marin-Lopez 960 University of Murcia 961 Campus de Espinardo S/N, Faculty of Computer Science 962 Murcia 30100 963 Spain 965 Phone: +34 868 88 85 01 966 Email: rafa@um.es 967 Gabriel Lopez-Millan 968 University of Murcia 969 Campus de Espinardo S/N, Faculty of Computer Science 970 Murcia 30100 971 Spain 973 Phone: +34 868 88 85 04 974 Email: gabilm@um.es