| SDNRG | A. Abad-Carrascosa |
| Internet-Draft | R. Marin-Lopez |
| Intended status: Experimental | G. Lopez-Millan |
| Expires: April 21, 2016 | University of Murcia |
| October 19, 2015 |
Software-Defined Networking (SDN)-based IPsec Flow Protection
draft-abad-sdnrg-sdn-ipsec-flow-protection-01
This document describes the use case for providing IPsec flow protection by means of a Software-Defined Network (SDN) controller and raises the requirements to support this service. It considers two main scenarios: (i) gateway-to-gateway and (ii) host-to-gateway (Road Warrior). For the gateway-to-gateway scenario, this document describes a mechanism to support the bootstrapping of key material between network resources to protect data traffic with IPsec and IKE, both in intra and inter-SDN cases. The host-to-gateway case defines a mechanism to bootstrap key material to protect data with IPsec between an end user's device and a gateway.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 21, 2016.
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Software-Defined Networking (SDN) is an architecture that enables users to directly program, orchestrate, control and manage network resources through software. SDN paradigm relocates the control of network resources to a dedicated network element, namely SDN controller. The SDN controller manages and configures the distributed network resources and provides an abstracted view of the network resources to the SDN applications. The SDN application can customize and automate the operations (including management) of the abstracted network resources in a programmable manner via this interface [RFC7149][ITU-T.Y.3300] [ONF-SDN-Architecture][ONF-OpenFlow].
Typically, traditional IPsec VPN concentrators and, in general, gateways supporting IKE/IPsec, are configured manually. This makes the IPsec security association (SA) management difficult and generates a lack of flexibility, specially if the number of security policies and SAs to handle is high. With the grow of SDN-based scenarios where network resources are deployed in an autonomous manner, a mechanism to manage IPsec SAs according to the SDN architecture becomes more relevant. Thus, the SDN-based service described in this document will autonomously deal with IPsec-based data protection also in such as an autonomous manner.
First, this document exposes the requirements to support the protection of data flows using IPsec [RFC4301]. We consider two cases: 1) Where the network resource implements the IKE protocol, the IPsec Security Policy Database (SPD) and the Security Association Database (SAD), and the SDN controller is in charge of provisioning with required information both IKE and the SPD in the network resource; 2) Where the SDN controller handles the IPsec SPD and takes the role of an Internet Key Exchange (IKE) entity in the IPsec architecture. In this sense, it will provision the required parameters to create valid entries in the Security Association Database (SAD), which we assumed to be in the data plane. Therefore, the data plane will have only support for IPsec while SPD and IKE functionality is moved to the control plane. In both cases, to carry out this provisioning, an interface/protocol will be required between the SDN controller and the data plane to send: the policies to be applied in the SPD and the credentials for the IKE negotiation (case 1); or the required IPsec SA parameters such as keys, cryptographic algorithms, IP addresses, IPsec protocol (AH or ESP), IPsec protocol mode (tunnel or transport), lifetime of the SA, etc (case 2). An example for case 1 using NETFCONF/YANG can be found in [netconf-vpn]. A YANG model for IPsec can be found in [I-D.wang-ipsecme-ipsec-yang].
Second, this document considers two scenarios to manage autonomously IPsec SAs: gateway-to-gateway and host-to-gateway [RFC6071]. The gateway-to-gateway scenario shows how flow protection services are useful when data is to be protected across gateways in the network. More precisely, the use case described in Section 8.1 depicts how these services could be used to protect IP traffic among various geographically distributed networks under the domain of the same SDN controller. A variant of this scenario is also covered in Section 8.2, where the network devices are under different SDN controllers.
The host-to-gateway scenario described in Section 8.3 covers the case where one end user belonging to a network wants to access securely its network from another external network. In such a case, an IPsec SA needs to be established between the end user's host and the gateway. In this document, we describe how the SDN controller can still configure automatically the IPsec SA in the gateway but after an IKE negotiation.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. When these words appear in lower case, they have their natural language meaning.
This document uses the terminology described in [RFC7149], [RFC4301], [ITU-T.Y.3300], [ONF-SDN-Architecture], [ONF-OpenFlow], [ITU-T.X.1252], and [ITU-T.X.800]. In addition, the following terms are defined below:
In this case, the SDN controller is in charge of controlling and applying SPD entries in the network resource. It also has to derive and deliver IKE credentials (for example a pre-shared key) to the network resource for the IKE authentication. With these policies and credentials, the IKE implementation runs to build the IPsec SAs. The application (administrator) will send the IPsec requirements and end points information, and the SDN controller will translate those requirements into SPD Policies that will be installed in the network resource. With that information, the network resources can just run IKE to establish the IPsec SA. Figure 1 shows the different layers and corresponding functionality.
Advantages: It is simple since network resources typically have and IKE/IPsec implementations.
Disadvantages: 1) IKE implementations needs to renegotiate IPsec SAs upon SPD entries changes without restarting IKE daemon. 2) Data plane more complex.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Application | Application
| (e.g., IKE/SPD Management/Orchestration) | Layer
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Application Support |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SDN Controller
| IKE Credential and SPD Policies Distribution| Layer
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Support |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Network
| IKEv2 | IPsec(SPD) | Resource
+-------------------------------------------- + Layer
| IPsec (SAD) Data Protection and Forwarding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Case 1) High-level Architecture for SDN-based IPsec Flow Protection Services
SDN-based IPsec flow protection services provide dynamic and flexible network resource management to protect data flows among network resources and end users. In order to support this capability in case 1, the following requirements are to be met:
This section describes the referenced architecture to support SDN- based IPsec flow protection where the SDN controller owns the SPD and the IKE implementation.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Application | Application
| (e.g., IKE/SDP Management/Orchestration) | Layer
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Application Support |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SDN
| IKEv2 | IPsec (SPD) | Controller
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Layer
| Key Derivation and Distribution |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Support | Network
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Resource
| IPsec (SAD) Data Protection and Forwarding | Layer
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Case 2) SDN Controller holds the SPD and has IKE implementation
As shown in Figure 2, applications for flow protection run on the top of the SDN controller [ITU-T.Y.3300][ONF-SDN-Architecture]. When an administrator enforces flow protection policies through an application interface, the SDN controller inserts the corresponding flow protection policies into its Security Policy Database (SPD) to meet such flow protection policies in an autonomous manner.
According to these policies, when the controller decides that a flow MUST be protected by means of IPsec, it inserts a new flow entry into the corresponding network resources' flow tables, along with an entry in the Security Associations Database (SAD) including all IPsec parameters needed to protect the flow (keys, ESP or AH, transport or tunnel, ...). This enforcement MAY be triggered by the network resource when it does not know how to handle the IP packet. Basically, it forwards the IP packet to the controller so that it can take a decision based on the SPD. This allow network resources to protect data flows based in rules dynamically enforced by the SDN controller.
Advantages: 1) There is clear separation of data plane (IPsec protection per flow) and control plane (IKE and SPD policies). Hence, it allows less complex data planes. 2) IKE does not need to be run in gateway-to-gateway scenario with a single controller (see Section 8.1).
Disadvantages: 1) The overload of IKE negotiation is shifted to the SDN controller. 2) IPSec SPD and SAD management need to be decoupled, changing the traditional paradigm defined in IPsec where SPD and SAD are placed in the network resource
In order to support this capability in case 2, the following requirements are to be met:
According to [I-D.dunbar-i2nsf-problem-statement] a Network Security Function (NSF) is a function that ensures "integrity, confidentiality and availability of network communications" among other aspects. As such, the network resource we describe in this document can be considered as a NSF with IPsec support. Additionally, the SDN controller can be considered as a Security controller. In [I-D.merged-i2nsf-framework-02] a framework for Interface to Network Security Functions is described. Three possible interfaces are described: Client Facing (service layer) Interface; NSF Facing (capability) Interface and Vendor Facing Interface.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Application | Client or
| (e.g., IKE/SPD Management/Orchestration) | App Gateway
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client Facing (service layer) Interface
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor | Application Support |
Facing <--->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Security
Interface | IKE Credential and SPD Policies Distribution| Controller
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSF Facing (capability) Interface
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Support |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Network
| IKEv2 | IPsec(SPD) | Security
+-------------------------------------------- + Function (NSF)
| IPsec (SAD) Data Protection and Forwarding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Case 1) Mapping with I2NSF Framework
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Application | Client or
| (e.g., IKE/SPD Management/Orchestration) | App Gateway
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client Facing (service layer) Interface
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor | Application Support |
Facing <--->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Security
Interface | IKEv2 | IPsec (SPD) | Controller
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Derivation and Distribution |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSF Facing (capability) Interface
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Support | Network
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Security
| IPsec (SAD) Data Protection and Forwarding | Function (NSF)
+---------------------------------------------+
Figure 4: Case 2) Mapping with I2NSF Framework
Figure 3 and Figure 4 describe the mapping with our use case. In the right side of the figure each entity follows the same terminology than [I-D.merged-i2nsf-framework-02]. [I-D.jeong-i2nsf-sdn-security-services-03] though we have found some differences between the mapping to I2NSF we show in this document and that reference. That is something that we will have to analyze in the future.
This section explains three use cases as examples for the SDN-based IPsec Flow Protection Service.
Enterprise A has a headquarter office (HQ) and several branch offices (BO) interconnected through an Internet connection provided by an Internet Service Provicer (ISP). This ISP has deployed a SDN-based architecture to provide connectivity to all its clients, including HQ and BOs, so the HQ is provided with a gateway that acts as a router between Internet and each BO's internal network.
Now, Enterprise A requires that all traffic between the HQ and BOs MUST be protected, for example, with confidentiality and integrity. The Entrepise A's administrator has to configure flow protection policies in the ISP's SDN controller, determining that all traffic among Enterprise A's HQ (HQ A) and each BO MUST be protected. Let us assume, for example, with an IPsec ESP tunnel.
On the one hand, in case 1, these policies are translated into IPsec SPD entries and the SDN controller enforces these entries in the network resources.
+----------------------------------------+
| SDN Controller |
| |
(1)| +--------------+ (2)+--------------+ |
Flow ---------->| Translate |--->| South. Prot. | |
Protect. Pol. |IPsec Policies| | | |
| +--------------+ +--------------+ |
| | | |
| | | |
+--------------------------|-----|-------+
| |
| (3) |
|--------------------------+ +---|
From V V To
HQ A +------------------+ +------------------+ BO
------>| GW1 |=============>| GW2 |------->
|IKE/IPsec(SPD/SAD)| |IKE/IPsec(SPD/SAD)|
+------------------+ (4) +------------------+
Figure 5: Gateway-to-Gateway single controller flow for case 1 .
Figure 5 describes the data and control communication planes in case 1, when a data packet is sent from HQ A with destination BO :
On the other hand, in case 2, these Flow Protection Policies defined by the administrator are translated into IPsec SPD entries and inserted into the SDN controller that represents the IPsec SPD.
+----------------------------------------+
| (0) SDN Controller |
Flow Prot. ---------| |
Pol. | V |
| +-------+ +----------------+ |
------->| IPSec |------>| South. Prot. | |
| | | (SPD) | | | |
| | +-------+ (2) +----------------+ |
| | | | |
| | | | |
(1) | +------------------- | --- | ------------+
| | |
| | (3) |
| |--------------------+ +---|
From | V V To
HQ A +----------+ +----------+ BO
------->| GW1 |==================>| GW2 |------->
|IPsec(SAD)| |IPsec(SAD)|
+----------+ (4) +----------+
Figure 6: Gateway-to-Gateway single controller flow for case 2.
Assuming that configuration step has happened (0), Figure 6 describes the data and control communication planes in case 2, when a data packet is sent from HQ A with destination BO :
In general (for case 1 and case2), this system presents various advantages to the ISP: (i) it allows to create a security association among two network resources, with only the application of specific security policies at the application layer. Thus, the ISP can manage all security associations in a centralized point and with an abstracted view of the network; (ii) All new resources deployed after the application of the new policies will not need to be manually configured, thus allowing its deployment in an automated manner.
Two organizations, Enterprise A and Enterprise B, have its headquarters interconnected through an Internet connection provided by different ISPs, called ISP_A and ISP_B. They have deployed a SDN-based architecture to provide Internet connectivity to all its clients, so Enterprise A's headquarters is provisioned with a gateway deployed by ISP_A and Enterprise B's headquarters is provisioned with a gateway deployed by ISP_B.
Now, these organizations require that all traffic among its headquarters to be protected with confidentiality and integrity, so the ISPs have to configure Flow Protection Policies in their SDN Controllers. Those policies are translated into flow protection policy rules into the SDN Controller's of each ISP, so all traffic exchanged among these headquarters will be protected, for example, by means of an IPsec ESP tunnel.
+-------------+ +-------------+
| ISP_A's | | ISP_B's |
Flow Prot. | SDN |<=================>| SDN |
Protect. ---> Controller | (2) | Controller |
(1) | | | |
+-------------+ +-------------+
| |
| (3) (3) |
From V V To
HQ A +------------------+ +------------------+ BO
------>| GW1 |=============>| GW2 |------->
|IKE/IPsec(SPD/SAD)| |IKE/IPsec(SPD/SAD)|
+------------------+ (4) +------------------+
Figure 7: Gateway-to-gateway multi controller flow in case 1
On the one hand, case 1, Figure 7 describes the data and control plane communications required when a data packet is sent from Enterprise A's HQ (HQ A) to destination Enterprise B's HQ (HQ B):
+--------------+ +--------------+
| ISP_A's | | ISP_B's |
Flow. --->
Prot. | SDN |<=================>| SDN |
Pol.(0)| Controller | (2) | Controller |
|IKE/IPsec(SPD)| |IKE/IPsec(SPD)|
+--------------+ +--------------+
A | |
(1) | | (3) (3) |
From | V V To
HQ A +-----------+ (4) +-----------+ HQ B
--------->| GW1 |====================>| GW2 |------->
|IPsec (SAD)| |IPsec (SAD)|
+-----------+ +-----------+
Figure 8: Gateway-to-gateway multi controller flow in case 2
On the other hand, case 2, Figure 8 describes the data and control plane communications required when a data packet is sent from Enterprise A's HQ (HQ A) to destination Enterprise B's HQ (HQ B):
In general (case 1 and case 2), this system presents various advantages to both ISPs: (i) it allows to create a security association among two network resources across ISPs, from each ISP point of view, only the application of specific Flow Protection Policies at the application layer is needed, so they can manage all security associations in a centralized point and with an abstracted view of the network; (ii) All new resources deployed after the application of the new policies will not need to be manually configured, thus allowing its deployment in an automated manner.
Alice is a member of Enterprise A who needs to connect to the HQ's internal network. Enterprise A has deployed a IPsec-based VPN concentrator in its HQ to allow members of the organization, like Alice, to connect to the HQ's internal network in a secure manner.
Traditionally, VPN concentrators are built as appliances, configured manually to authenticate and establish secure associations with incoming users, for example, by running IKEv2 to establish an IPsec tunnel. With the SDN-base management of IPsec protection service we can automate these configuration.
In case 1, as we can see in Figure 10, the administrator configures a Flow Protection Policy in the SDN controller (1). The SDN controller translates that into IPsec Policies and installs those SPD entries and IKE credentials in the corresponding gateway (VPN concentrator) (2). With those policies and IKE credentials, end user and gateway can negotiate IKE.
+----------------------------------------+
| SDN Controller |
| |
(1)| +--------------+ +--------------+ |
Flow ---------->| Translate |--->| South. Prot. | |
Protect. Pol. |IPsec Policies| | | |
| +--------------+ +--------------+ |
| | |
| (2) | |
+--------------------------|-------------+
|-------+
V
+----------+ +-------------------+
| End user | | Gateway | To
| (Alice) | | (VPN conc.) | HQ
| IKE/IPsec|====================>| IKE/IPsec(SPD/SAD)|------->
+----------+ (3) +-------------------+
Figure 9: Host-to-gateway flow protection in case 1.
In case 2, the role of running IKEv2 now resides in the SDN control plane (i.e. the SDN controller), as we can see in Figure 10. Here, the gateway forwards IKE packets to the controller. Therefore, the IKEv2 negotiation is performed by the end user and the SDN controller (1), being this fact completely transparent for the end user.
Once the IKEv2 negotiation has been successfully completed, new key material is available in the end user and in the SDN controller. This key material, along with other parameters like the IPsec mode, are to be provisioned into the gateway's SAD (2). Now the end user and the gateway share key material, thus being able to establish an IPsec tunnel to protect all traffic among them (3).
In general, this feature allows the configuration of network resources such as VPN concentrators as a service, so these could be deployed and disposed as required by policies, such as network load, in an autonomous manner.
+----------------------------------+
| SDN Controller |
| |
| +----------+ +-------------+ |
| | IKE |-->| South. Prot.| |
| |IPsec(SPD)| | | |
| +---------- +-------------+ |
| A | |
| | | |
+------ | ----------- | -----------+
| |
(1) | |----- (2)
| V
+----------+ (1) +---|-----------+
| |<------------------------| |
| End user | | Gateway | To
| (Alice) | | (VPN conc.) | HQ
| IKE/IPsec|====================>| IPsec(SAD) |------->
+----------+ (3) +---------------+
Figure 10: Host-to-gateway flow in case 2.
TBD.
Authors want to thank Carlos J. Bernardos and Alejandro Perez-Mendez for their valuable comments.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC5226] | Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008. |