idnits 2.17.1 draft-abad-sdnrg-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 22 instances of too long lines in the document, the longest one being 15 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 19, 2015) is 3111 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC5226' is defined on line 739, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-05) exists of draft-jeong-i2nsf-sdn-security-services-03 == Outdated reference: A later version (-05) exists of draft-merged-i2nsf-framework-02 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SDNRG A. Abad-Carrascosa 3 Internet-Draft R. Marin-Lopez 4 Intended status: Experimental G. Lopez-Millan 5 Expires: April 21, 2016 University of Murcia 6 October 19, 2015 8 Software-Defined Networking (SDN)-based IPsec Flow Protection 9 draft-abad-sdnrg-sdn-ipsec-flow-protection-01 11 Abstract 13 This document describes the use case for providing IPsec flow 14 protection by means of a Software-Defined Network (SDN) controller 15 and raises the requirements to support this service. It considers 16 two main scenarios: (i) gateway-to-gateway and (ii) host-to-gateway 17 (Road Warrior). For the gateway-to-gateway scenario, this document 18 describes a mechanism to support the bootstrapping of key material 19 between network resources to protect data traffic with IPsec and IKE, 20 both in intra and inter-SDN cases. The host-to-gateway case defines 21 a mechanism to bootstrap key material to protect data with IPsec 22 between an end user's device and a gateway. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 21, 2016. 41 Copyright Notice 43 Copyright (c) 2015 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 60 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 5. Case 1: IKE/IPsec in the network resource . . . . . . . . . . 5 63 5.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 6 64 6. Case 2: IKE and SPD in the SDN Controller . . . . . . . . . . 6 65 6.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 8 66 7. Relationship with I2NSF . . . . . . . . . . . . . . . . . . . 8 67 8. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 8.1. Gateway-to-gateway under the same controller . . . . . . 10 69 8.2. Gateway-to-gateway under different SDN controllers . . . 12 70 8.3. Host-to-gateway . . . . . . . . . . . . . . . . . . . . . 15 71 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 72 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 73 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 74 11.1. Normative References . . . . . . . . . . . . . . . . . . 17 75 11.2. Informative References . . . . . . . . . . . . . . . . . 17 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 78 1. Introduction 80 Software-Defined Networking (SDN) is an architecture that enables 81 users to directly program, orchestrate, control and manage network 82 resources through software. SDN paradigm relocates the control of 83 network resources to a dedicated network element, namely SDN 84 controller. The SDN controller manages and configures the 85 distributed network resources and provides an abstracted view of the 86 network resources to the SDN applications. The SDN application can 87 customize and automate the operations (including management) of the 88 abstracted network resources in a programmable manner via this 89 interface [RFC7149][ITU-T.Y.3300] 90 [ONF-SDN-Architecture][ONF-OpenFlow]. 92 Typically, traditional IPsec VPN concentrators and, in general, 93 gateways supporting IKE/IPsec, are configured manually. This makes 94 the IPsec security association (SA) management difficult and 95 generates a lack of flexibility, specially if the number of security 96 policies and SAs to handle is high. With the grow of SDN-based 97 scenarios where network resources are deployed in an autonomous 98 manner, a mechanism to manage IPsec SAs according to the SDN 99 architecture becomes more relevant. Thus, the SDN-based service 100 described in this document will autonomously deal with IPsec-based 101 data protection also in such as an autonomous manner. 103 First, this document exposes the requirements to support the 104 protection of data flows using IPsec [RFC4301]. We consider two 105 cases: 1) Where the network resource implements the IKE protocol, the 106 IPsec Security Policy Database (SPD) and the Security Association 107 Database (SAD), and the SDN controller is in charge of provisioning 108 with required information both IKE and the SPD in the network 109 resource; 2) Where the SDN controller handles the IPsec SPD and takes 110 the role of an Internet Key Exchange (IKE) entity in the IPsec 111 architecture. In this sense, it will provision the required 112 parameters to create valid entries in the Security Association 113 Database (SAD), which we assumed to be in the data plane. Therefore, 114 the data plane will have only support for IPsec while SPD and IKE 115 functionality is moved to the control plane. In both cases, to carry 116 out this provisioning, an interface/protocol will be required between 117 the SDN controller and the data plane to send: the policies to be 118 applied in the SPD and the credentials for the IKE negotiation (case 119 1); or the required IPsec SA parameters such as keys, cryptographic 120 algorithms, IP addresses, IPsec protocol (AH or ESP), IPsec protocol 121 mode (tunnel or transport), lifetime of the SA, etc (case 2). An 122 example for case 1 using NETFCONF/YANG can be found in [netconf-vpn]. 123 A YANG model for IPsec can be found in [I-D.wang-ipsecme-ipsec-yang]. 125 Second, this document considers two scenarios to manage autonomously 126 IPsec SAs: gateway-to-gateway and host-to-gateway [RFC6071]. The 127 gateway-to-gateway scenario shows how flow protection services are 128 useful when data is to be protected across gateways in the network. 129 More precisely, the use case described in Section 8.1 depicts how 130 these services could be used to protect IP traffic among various 131 geographically distributed networks under the domain of the same SDN 132 controller. A variant of this scenario is also covered in 133 Section 8.2, where the network devices are under different SDN 134 controllers. 136 The host-to-gateway scenario described in Section 8.3 covers the case 137 where one end user belonging to a network wants to access securely 138 its network from another external network. In such a case, an IPsec 139 SA needs to be established between the end user's host and the 140 gateway. In this document, we describe how the SDN controller can 141 still configure automatically the IPsec SA in the gateway but after 142 an IKE negotiation. 144 2. Requirements Language 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in RFC 2119 [RFC2119]. 149 When these words appear in lower case, they have their natural 150 language meaning. 152 3. Terminology 154 This document uses the terminology described in [RFC7149], [RFC4301], 155 [ITU-T.Y.3300], [ONF-SDN-Architecture], [ONF-OpenFlow], 156 [ITU-T.X.1252], and [ITU-T.X.800]. In addition, the following terms 157 are defined below: 159 o Software-Defined Networking: A set of techniques enabling to 160 directly program, orchestrate, control, and manage network 161 resources, which facilitates the design, delivery and operation of 162 network services in a dynamic and scalable manner [ITU-T.Y.3300]. 164 o Flow / Data Flow: Set of network packets sharing a set of 165 characteristics, for example IP dst/src values or QoS parameters. 167 o Network Resources: Network devices that can perform packet 168 forwarding in a network system. The network resources include 169 network switch, router, gateway, VPN concentrators, and similar 170 devices. This document makes no difference if these network 171 devices are physical or virtual. 173 o Flow Protection Policy: The set of rules defining the conditions 174 under which a data flow MUST be protected, and the rules that MUST 175 be applied to the specific flow. 177 o IKE: Protocol to establish IPsec Security Associations (SAs). It 178 requires information about the required authentication method 179 (i.e. preshared keys), DH groups, modes and algorithms for IKE 180 phase 1, etc. 182 o SPD: IPsec Security Policy Database. It includes information 183 about IPsec policies direction (in, out), local and remote 184 addresses, inbound and outboud SAs, etc. 186 o SAD: IPsec Security Associations Database. It includes 187 information about IPsec security associations, such as SPI, 188 destination addresses, authentication and encryption algorithms 189 and keys. 191 4. Objectives 193 o Flow-based data protection: SDN-based flow protection services 194 based on IPsec to allow the protection of specific data flows 195 based on defined security policies. 197 o Bootstrapping security associations: SDN-based flow protection 198 allow the centralized bootstrapping of IKE credentials (case 1) 199 and IPsec key material for AH and ESP (case 2) to eventually 200 protect specific data flows among network resources and end users. 202 5. Case 1: IKE/IPsec in the network resource 204 In this case, the SDN controller is in charge of controlling and 205 applying SPD entries in the network resource. It also has to derive 206 and deliver IKE credentials (for example a pre-shared key) to the 207 network resource for the IKE authentication. With these policies and 208 credentials, the IKE implementation runs to build the IPsec SAs. The 209 application (administrator) will send the IPsec requirements and end 210 points information, and the SDN controller will translate those 211 requirements into SPD Policies that will be installed in the network 212 resource. With that information, the network resources can just run 213 IKE to establish the IPsec SA. Figure 1 shows the different layers 214 and corresponding functionality. 216 Advantages: It is simple since network resources typically have and 217 IKE/IPsec implementations. 219 Disadvantages: 1) IKE implementations needs to renegotiate IPsec SAs 220 upon SPD entries changes without restarting IKE daemon. 2) Data plane 221 more complex. 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Security Application | Application 225 | (e.g., IKE/SPD Management/Orchestration) | Layer 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Application Support | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SDN Controller 231 | IKE Credential and SPD Policies Distribution| Layer 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Control Support | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Network 237 | IKEv2 | IPsec(SPD) | Resource 238 +-------------------------------------------- + Layer 239 | IPsec (SAD) Data Protection and Forwarding | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 Figure 1: Case 1) High-level Architecture for SDN-based IPsec Flow 243 Protection Services 245 5.1. Requirements 247 SDN-based IPsec flow protection services provide dynamic and flexible 248 network resource management to protect data flows among network 249 resources and end users. In order to support this capability in case 250 1, the following requirements are to be met: 252 o The network resource MUST implement IKE, IPsec, SPD and the SADs. 253 It MUST provide an (southbound) interface to configure SPD 254 policies and IKE credentials. 256 o A southbound protocol MUST support sending these SPD Policies and 257 IKE Credentials to the network resource. 259 o It requires an (northbound) application interface in the SDN 260 controller allowing the management of IPsec Policies. 262 o In scenarios where multiple controllers are implicated, SDN-based 263 flow protection service may require a mechanism to discover which 264 SDN controller is controlling a specific network resource. 266 6. Case 2: IKE and SPD in the SDN Controller 268 This section describes the referenced architecture to support SDN- 269 based IPsec flow protection where the SDN controller owns the SPD and 270 the IKE implementation. 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | Security Application | Application 274 | (e.g., IKE/SDP Management/Orchestration) | Layer 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Application Support | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SDN 280 | IKEv2 | IPsec (SPD) | Controller 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Layer 282 | Key Derivation and Distribution | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | Control Support | Network 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Resource 288 | IPsec (SAD) Data Protection and Forwarding | Layer 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 Figure 2: Case 2) SDN Controller holds the SPD and has IKE 292 implementation 294 As shown in Figure 2, applications for flow protection run on the top 295 of the SDN controller [ITU-T.Y.3300][ONF-SDN-Architecture]. When an 296 administrator enforces flow protection policies through an 297 application interface, the SDN controller inserts the corresponding 298 flow protection policies into its Security Policy Database (SPD) to 299 meet such flow protection policies in an autonomous manner. 301 According to these policies, when the controller decides that a flow 302 MUST be protected by means of IPsec, it inserts a new flow entry into 303 the corresponding network resources' flow tables, along with an entry 304 in the Security Associations Database (SAD) including all IPsec 305 parameters needed to protect the flow (keys, ESP or AH, transport or 306 tunnel, ...). This enforcement MAY be triggered by the network 307 resource when it does not know how to handle the IP packet. 308 Basically, it forwards the IP packet to the controller so that it can 309 take a decision based on the SPD. This allow network resources to 310 protect data flows based in rules dynamically enforced by the SDN 311 controller. 313 Advantages: 1) There is clear separation of data plane (IPsec 314 protection per flow) and control plane (IKE and SPD policies). 315 Hence, it allows less complex data planes. 2) IKE does not need to be 316 run in gateway-to-gateway scenario with a single controller (see 317 Section 8.1). 319 Disadvantages: 1) The overload of IKE negotiation is shifted to the 320 SDN controller. 2) IPSec SPD and SAD management need to be decoupled, 321 changing the traditional paradigm defined in IPsec where SPD and SAD 322 are placed in the network resource 324 6.1. Requirements 326 In order to support this capability in case 2, the following 327 requirements are to be met: 329 o It requires the provision of flow entries in network resources. 330 Flow entries may need to include fields such as AH or ESP 331 parameters, tunnel or transport mode and crypto material to 332 process an IP packet with IPsec (in the end, the Security 333 Association Database (SADs) is managed by the network resource). 334 In the same way a southbound protocol MUST support sending this 335 information to the network resource. 337 o Network resources MUST be capable to protect data flows with 338 IPsec, such as the capability to forward data through an IPsec 339 tunnel. 341 o It requires an (northbound) application interface in the SDN 342 controller allowing the management of IPsec policies. 344 o In scenarios where multiple controllers are implicated, SDN-based 345 flow protection service may require a mechanism to discover which 346 SDN controller is managing a specific network resource. 348 7. Relationship with I2NSF 350 According to [I-D.dunbar-i2nsf-problem-statement] a Network Security 351 Function (NSF) is a function that ensures "integrity, confidentiality 352 and availability of network communications" among other aspects. As 353 such, the network resource we describe in this document can be 354 considered as a NSF with IPsec support. Additionally, the SDN 355 controller can be considered as a Security controller. In 356 [I-D.merged-i2nsf-framework-02] a framework for Interface to Network 357 Security Functions is described. Three possible interfaces are 358 described: Client Facing (service layer) Interface; NSF Facing 359 (capability) Interface and Vendor Facing Interface. 361 Figure 3 and Figure 4 describe the mapping with our use case. In the 362 right side of the figure each entity follows the same terminology 363 than [I-D.merged-i2nsf-framework-02]. 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Security Application | Client or 367 | (e.g., IKE/SPD Management/Orchestration) | App Gateway 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Client Facing (service layer) Interface 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 Vendor | Application Support | 372 Facing <--->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Security 373 Interface | IKE Credential and SPD Policies Distribution| Controller 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | NSF Facing (capability) Interface 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | Control Support | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Network 379 | IKEv2 | IPsec(SPD) | Security 380 +-------------------------------------------- + Function (NSF) 381 | IPsec (SAD) Data Protection and Forwarding | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 Figure 3: Case 1) Mapping with I2NSF Framework 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | Security Application | Client or 388 | (e.g., IKE/SPD Management/Orchestration) | App Gateway 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Client Facing (service layer) Interface 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 Vendor | Application Support | 393 Facing <--->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Security 394 Interface | IKEv2 | IPsec (SPD) | Controller 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | Key Derivation and Distribution | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | NSF Facing (capability) Interface 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | Control Support | Network 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Security 402 | IPsec (SAD) Data Protection and Forwarding | Function (NSF) 403 +---------------------------------------------+ 405 Figure 4: Case 2) Mapping with I2NSF Framework 407 NOTE: We believe these use cases can be considered as additional uses 408 cases to the work proposed in 409 [I-D.jeong-i2nsf-sdn-security-services-03] though we have found some 410 differences between the mapping to I2NSF we show in this document and 411 that reference. That is something that we will have to analyze in 412 the future. 414 8. Scenarios 416 This section explains three use cases as examples for the SDN-based 417 IPsec Flow Protection Service. 419 8.1. Gateway-to-gateway under the same controller 421 Enterprise A has a headquarter office (HQ) and several branch offices 422 (BO) interconnected through an Internet connection provided by an 423 Internet Service Provicer (ISP). This ISP has deployed a SDN-based 424 architecture to provide connectivity to all its clients, including HQ 425 and BOs, so the HQ is provided with a gateway that acts as a router 426 between Internet and each BO's internal network. 428 Now, Enterprise A requires that all traffic between the HQ and BOs 429 MUST be protected, for example, with confidentiality and integrity. 430 The Entrepise A's administrator has to configure flow protection 431 policies in the ISP's SDN controller, determining that all traffic 432 among Enterprise A's HQ (HQ A) and each BO MUST be protected. Let us 433 assume, for example, with an IPsec ESP tunnel. 435 On the one hand, in case 1, these policies are translated into IPsec 436 SPD entries and the SDN controller enforces these entries in the 437 network resources. 439 +----------------------------------------+ 440 | SDN Controller | 441 | | 442 (1)| +--------------+ (2)+--------------+ | 443 Flow ---------->| Translate |--->| South. Prot. | | 444 Protect. Pol. |IPsec Policies| | | | 445 | +--------------+ +--------------+ | 446 | | | | 447 | | | | 448 +--------------------------|-----|-------+ 449 | | 450 | (3) | 451 |--------------------------+ +---| 452 From V V To 453 HQ A +------------------+ +------------------+ BO 454 ------>| GW1 |=============>| GW2 |-------> 455 |IKE/IPsec(SPD/SAD)| |IKE/IPsec(SPD/SAD)| 456 +------------------+ (4) +------------------+ 458 Figure 5: Gateway-to-Gateway single controller flow for case 1 . 460 Figure 5 describes the data and control communication planes in case 461 1, when a data packet is sent from HQ A with destination BO : 463 1. The administrator establishes a general Flow Protection Policies. 465 2. The SDN controller translates into IPsec Policies entries. 467 3. The SDN Controller looks for the network resources involved (GW1 468 and GW2) and inserts the IPsec SPD entries in both GW1 and GW2 469 IPsec SPDs and keys and configuration information related with 470 IKE. 472 4. All packets belonging to the flow that matches the IPsec SDP 473 inserted by the SDN controller triggers the IKE negotiation in 474 GW1 and GW2 by using the enforced configuration keys and 475 parameters. 477 On the other hand, in case 2, these Flow Protection Policies defined 478 by the administrator are translated into IPsec SPD entries and 479 inserted into the SDN controller that represents the IPsec SPD. 481 +----------------------------------------+ 482 | (0) SDN Controller | 483 Flow Prot. ---------| | 484 Pol. | V | 485 | +-------+ +----------------+ | 486 ------->| IPSec |------>| South. Prot. | | 487 | | | (SPD) | | | | 488 | | +-------+ (2) +----------------+ | 489 | | | | | 490 | | | | | 491 (1) | +------------------- | --- | ------------+ 492 | | | 493 | | (3) | 494 | |--------------------+ +---| 495 From | V V To 496 HQ A +----------+ +----------+ BO 497 ------->| GW1 |==================>| GW2 |-------> 498 |IPsec(SAD)| |IPsec(SAD)| 499 +----------+ (4) +----------+ 501 Figure 6: Gateway-to-Gateway single controller flow for case 2. 503 Assuming that configuration step has happened (0), Figure 6 describes 504 the data and control communication planes in case 2, when a data 505 packet is sent from HQ A with destination BO : 507 1. When the data packet arrives for first time to the gateway in HQ 508 A (GW1), it sends the packet to the SDN Controller. 510 2. The SDN Controller looks for security policies in its SPD table 511 and decides that the flow MUST be protected, for example, with 512 IPsec ESP in tunnel mode. 514 3. The SDN controller derives keys for the IPsec tunnel and enforces 515 them, along with other information required, such as IPsec mode 516 (ESP or AH), into both gateways' IPsec Security Association 517 Database (SAD). 519 4. All packets belonging to the flow are tunneled between GW1 and 520 GW2 by using the enforced configuration keys and parameters. No 521 need to run IKE between GW1 and GW2. 523 In general (for case 1 and case2), this system presents various 524 advantages to the ISP: (i) it allows to create a security association 525 among two network resources, with only the application of specific 526 security policies at the application layer. Thus, the ISP can manage 527 all security associations in a centralized point and with an 528 abstracted view of the network; (ii) All new resources deployed after 529 the application of the new policies will not need to be manually 530 configured, thus allowing its deployment in an automated manner. 532 8.2. Gateway-to-gateway under different SDN controllers 534 Two organizations, Enterprise A and Enterprise B, have its 535 headquarters interconnected through an Internet connection provided 536 by different ISPs, called ISP_A and ISP_B. They have deployed a SDN- 537 based architecture to provide Internet connectivity to all its 538 clients, so Enterprise A's headquarters is provisioned with a gateway 539 deployed by ISP_A and Enterprise B's headquarters is provisioned with 540 a gateway deployed by ISP_B. 542 Now, these organizations require that all traffic among its 543 headquarters to be protected with confidentiality and integrity, so 544 the ISPs have to configure Flow Protection Policies in their SDN 545 Controllers. Those policies are translated into flow protection 546 policy rules into the SDN Controller's of each ISP, so all traffic 547 exchanged among these headquarters will be protected, for example, by 548 means of an IPsec ESP tunnel. 550 +-------------+ +-------------+ 551 | ISP_A's | | ISP_B's | 552 Flow Prot. | SDN |<=================>| SDN | 553 Protect. ---> Controller | (2) | Controller | 554 (1) | | | | 555 +-------------+ +-------------+ 556 | | 557 | (3) (3) | 558 From V V To 559 HQ A +------------------+ +------------------+ BO 560 ------>| GW1 |=============>| GW2 |-------> 561 |IKE/IPsec(SPD/SAD)| |IKE/IPsec(SPD/SAD)| 562 +------------------+ (4) +------------------+ 564 Figure 7: Gateway-to-gateway multi controller flow in case 1 566 On the one hand, case 1, Figure 7 describes the data and control 567 plane communications required when a data packet is sent from 568 Enterprise A's HQ (HQ A) to destination Enterprise B's HQ (HQ B): 570 1. The administrator establishes a general Flow Protection Policies, 571 which the SDN controller translates into IPsec Policies. 573 2. The ISP_A's SDN Controller realizes that traffic between GW1 and 574 GW2 MUST be protected. Nevertheless, the controller notices that 575 GW2 is under the control of another SDN controller, so it starts 576 negotiations with the other controller to agree on the IPsec SPD 577 policies and IKE credentials for their respective gateway NOTE: 578 This may require extensions in the East/West interface. 580 3. Then, both SDN controllers enforce the IKE credentials and 581 related parameters and the IPsec SPD Policies entries in their 582 respective gateways. 584 4. All packets belonging to the flow that matches the IPsec SDP 585 inserted by the SDN controller triggers the IKE negotiation GW1 586 and GW2 by using the enforced configuration keys and parameters. 588 +--------------+ +--------------+ 589 | ISP_A's | | ISP_B's | 590 Flow. ---> 591 Prot. | SDN |<=================>| SDN | 592 Pol.(0)| Controller | (2) | Controller | 593 |IKE/IPsec(SPD)| |IKE/IPsec(SPD)| 594 +--------------+ +--------------+ 595 A | | 596 (1) | | (3) (3) | 597 From | V V To 598 HQ A +-----------+ (4) +-----------+ HQ B 599 --------->| GW1 |====================>| GW2 |-------> 600 |IPsec (SAD)| |IPsec (SAD)| 601 +-----------+ +-----------+ 603 Figure 8: Gateway-to-gateway multi controller flow in case 2 605 On the other hand, case 2, Figure 8 describes the data and control 606 plane communications required when a data packet is sent from 607 Enterprise A's HQ (HQ A) to destination Enterprise B's HQ (HQ B): 609 1. When the data packet arrives for first time to the gateway in 610 Enterprise A's headquarters (GW1), it sends the packet to its SDN 611 Controller. 613 2. The ISP_A's SDN Controller looks for security policies in its SPD 614 table and decides that the flow between GW1 and GW2 MUST be 615 protected, for example, with IPsec ESP in tunnel mode. 616 Nevertheless, the controller notices that GW2 is under the 617 control of another SDN controller, so it starts negotiations with 618 the other controller in order to generate key material. This 619 could be performed by running IKEv2 (NOTE:more discussion is 620 required). 622 3. Once the controllers have generated shared key material, both 623 enforce these keys into their respective gateways' Security 624 Association Databases (SAD) along with the IPsec mode and other 625 parameters that may be required. 627 4. Therefore, all packets belonging to the flow are protected 628 between GW1 and GW2 by using the enforced configuration keys and 629 parameters. 631 In general (case 1 and case 2), this system presents various 632 advantages to both ISPs: (i) it allows to create a security 633 association among two network resources across ISPs, from each ISP 634 point of view, only the application of specific Flow Protection 635 Policies at the application layer is needed, so they can manage all 636 security associations in a centralized point and with an abstracted 637 view of the network; (ii) All new resources deployed after the 638 application of the new policies will not need to be manually 639 configured, thus allowing its deployment in an automated manner. 641 8.3. Host-to-gateway 643 Alice is a member of Enterprise A who needs to connect to the HQ's 644 internal network. Enterprise A has deployed a IPsec-based VPN 645 concentrator in its HQ to allow members of the organization, like 646 Alice, to connect to the HQ's internal network in a secure manner. 648 Traditionally, VPN concentrators are built as appliances, configured 649 manually to authenticate and establish secure associations with 650 incoming users, for example, by running IKEv2 to establish an IPsec 651 tunnel. With the SDN-base management of IPsec protection service we 652 can automate these configuration. 654 In case 1, as we can see in Figure 10, the administrator configures a 655 Flow Protection Policy in the SDN controller (1). The SDN controller 656 translates that into IPsec Policies and installs those SPD entries 657 and IKE credentials in the corresponding gateway (VPN concentrator) 658 (2). With those policies and IKE credentials, end user and gateway 659 can negotiate IKE. 661 +----------------------------------------+ 662 | SDN Controller | 663 | | 664 (1)| +--------------+ +--------------+ | 665 Flow ---------->| Translate |--->| South. Prot. | | 666 Protect. Pol. |IPsec Policies| | | | 667 | +--------------+ +--------------+ | 668 | | | 669 | (2) | | 670 +--------------------------|-------------+ 671 |-------+ 672 V 673 +----------+ +-------------------+ 674 | End user | | Gateway | To 675 | (Alice) | | (VPN conc.) | HQ 676 | IKE/IPsec|====================>| IKE/IPsec(SPD/SAD)|-------> 677 +----------+ (3) +-------------------+ 679 Figure 9: Host-to-gateway flow protection in case 1. 681 In case 2, the role of running IKEv2 now resides in the SDN control 682 plane (i.e. the SDN controller), as we can see in Figure 10. Here, 683 the gateway forwards IKE packets to the controller. Therefore, the 684 IKEv2 negotiation is performed by the end user and the SDN controller 685 (1), being this fact completely transparent for the end user. 687 Once the IKEv2 negotiation has been successfully completed, new key 688 material is available in the end user and in the SDN controller. 689 This key material, along with other parameters like the IPsec mode, 690 are to be provisioned into the gateway's SAD (2). Now the end user 691 and the gateway share key material, thus being able to establish an 692 IPsec tunnel to protect all traffic among them (3). 694 In general, this feature allows the configuration of network 695 resources such as VPN concentrators as a service, so these could be 696 deployed and disposed as required by policies, such as network load, 697 in an autonomous manner. 699 +----------------------------------+ 700 | SDN Controller | 701 | | 702 | +----------+ +-------------+ | 703 | | IKE |-->| South. Prot.| | 704 | |IPsec(SPD)| | | | 705 | +---------- +-------------+ | 706 | A | | 707 | | | | 708 +------ | ----------- | -----------+ 709 | | 710 (1) | |----- (2) 711 | V 712 +----------+ (1) +---|-----------+ 713 | |<------------------------| | 714 | End user | | Gateway | To 715 | (Alice) | | (VPN conc.) | HQ 716 | IKE/IPsec|====================>| IPsec(SAD) |-------> 717 +----------+ (3) +---------------+ 719 Figure 10: Host-to-gateway flow in case 2. 721 9. Security Considerations 723 TBD. 725 10. Acknowledgements 727 Authors want to thank Carlos J. Bernardos and Alejandro Perez-Mendez 728 for their valuable comments. 730 11. References 732 11.1. Normative References 734 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 735 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 736 RFC2119, March 1997, 737 . 739 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 740 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 741 DOI 10.17487/RFC5226, May 2008, 742 . 744 11.2. Informative References 746 [I-D.dunbar-i2nsf-problem-statement] 747 Dunbar, L., Zarny, M., Jacquenet, C., Boucadair, M., and 748 S. Chakrabarty, "Interface to Network Security Functions 749 (I2NSF) Problem Statement", draft-dunbar-i2nsf-problem- 750 statement-05 (work in progress), May 2015. 752 [I-D.jeong-i2nsf-sdn-security-services-03] 753 Jeong, J. and J. Park, "Software-Defined Networking Based 754 Security Services using Interface to Network Security 755 Functions", draft-jeong-i2nsf-sdn-security-services-03 756 (work in progress), October 2015. 758 [I-D.merged-i2nsf-framework-02] 759 Lopez, E., Lopez, D., Zhuang, X., Dunbar, L., Parrott, J., 760 Krishnan, R., and SR. Durbha, "Framework for Interface to 761 Network Security Functions", draft-merged-i2nsf-framework- 762 02.txt (work in progress), June 2015. 764 [I-D.wang-ipsecme-ipsec-yang] 765 Wang, H., Nagaraj, V., and X. Chen, "Yang Data Model for 766 IPsec", draft-wang-ipsecme-ipsec-yang-00 (work in 767 progress), June 2015. 769 [ITU-T.X.1252] 770 "Baseline Identity Management Terms and Definitions", 771 April 2010. 773 [ITU-T.X.800] 774 "Security Architecture for Open Systems Interconnection 775 for CCITT Applications", March 1991. 777 [ITU-T.Y.3300] 778 "Recommendation ITU-T Y.3300", June 2014. 780 [netconf-vpn] 781 Stefan Wallin, "Tutorial: NETCONF and YANG", January 2014. 783 [ONF-OpenFlow] 784 ONF, "OpenFlow Switch Specification (Version 1.4.0)", 785 October 2013. 787 [ONF-SDN-Architecture] 788 "SDN Architecture", June 2014. 790 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 791 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 792 December 2005, . 794 [RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and 795 Internet Key Exchange (IKE) Document Roadmap", RFC 6071, 796 DOI 10.17487/RFC6071, February 2011, 797 . 799 [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined 800 Networking: A Perspective from within a Service Provider 801 Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, 802 . 804 Authors' Addresses 806 Alejandro Abad-Carrascosa 807 University of Murcia 808 Campus de Espinardo S/N, Faculty of Computer Science 809 Murcia 30100 810 Spain 812 Email: alejandroprimitivo.abad@um.es 814 Rafa Marin-Lopez 815 University of Murcia 816 Campus de Espinardo S/N, Faculty of Computer Science 817 Murcia 30100 818 Spain 820 Phone: +34 868 88 85 01 821 Email: rafa@um.es 822 Gabriel Lopez-Millan 823 University of Murcia 824 Campus de Espinardo S/N, Faculty of Computer Science 825 Murcia 30100 826 Spain 828 Phone: +34 868 88 85 04 829 Email: gabilm@um.es