| I2NSF | R. Marin-Lopez |
| Internet-Draft | G. Lopez-Millan |
| Intended status: Experimental | University of Murcia |
| Expires: January 9, 2017 | July 8, 2016 |
Software-Defined Networking (SDN)-based IPsec Flow Protection
draft-abad-i2nsf-sdn-ipsec-flow-protection-00
This document describes the use case of providing IPsec-based 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 distribution of IPsec information to flow-based Network Security Functions (NSFs) that implements IPsec to protect data traffic. between network resources to protect data traffic with IPsec and IKE, in intra and inter-SDN cases. The host-to-gateway case defines a mechanism to distribute IPsec information to the NSF to protect data with IPsec between an end user's device (host) 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 January 9, 2017.
Copyright (c) 2016 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.
IPsec architecture [RFC4301] defines a clear separation between the processing to provide security services to IP packets and the key management procedures to establish the IPsec security association. In this document, we defined that a service where the key management procedures can be carried by an external entity: the security controller.
First, this document exposes the requirements to support the protection of data flows using IPsec [RFC4301]. We consider two cases:
In both cases, an interface/protocol will be required to carry out this provisioning between the security controller and the NSF. In particular, it is required the provision of SPD and PAD entries and the credentials and information related with the IKE negotiation (case 1); or the required SPD, PAD and SAD entries with information 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.tran-ipsecme-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. Each gateway will implement a flow-based NSF. The use case described in Section 9.1 depicts how these services could be used to protect IP traffic among various geographically distributed networks under the domain of the same security controller. A variant of this scenario is also covered in Section 9.2, where the NSFs involved are under the control of different security controllers.
The host-to-gateway scenario described in Section 9.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, which is a flow-based NSF. In this document, we describe how the security controller can still configure automatically the IPsec SA in the NSF.
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], [ITU-T.X.800] and [I-D.ietf-i2nsf-terminology]. In addition, the following terms are defined below:
In this case, the security controller is in charge of controlling and applying SPD and PAD entries in the NSF. It also has to apply IKE configuration parameters and derive and deliver IKE credentials (e.g. a pre-shared key) to the NSF for the IKE negotiation. In short, we would call this IKE credential.
With these entries and credentials, the IKE implementation can operate to establish the IPsec SAs. The application (administrator) will send the IPsec requirements and end points information, and the security controller will translate those requirements into SPD entries that will be installed in the NSF. With that information provisioned in the NSF, when the data flow needs to be protected, the NSF can just run IKE to establish the required IPsec SA. Figure 1 shows the different layers and corresponding functionality.
Advantages: It is simple because current gateways typically have an IKE/IPsec implementation.
Disadvantages: IKE implementations need to renegotiate IPsec SAs upon SPD entries changes without restarting IKE daemon.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPsec Management/Orchestration Application| Client or
| I2NSF Client | App Gateway
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client Facing Interface
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor | Application Support |
Facing <--->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Security
Interface | IKE Credential and SPD Policies Distribution| Controller
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSF Facing Interface
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| I2NSF Agent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Network
| IKE | IPsec(SPD,SAD,PAD) | Security
+-------------------------------------------- + Function (NSF)
| Data Protection and Forwarding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Case 1: IKE/IPsec in the NSF
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 security controller performs automated key management tasks.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPsec Management/Orchestration Application| Client or
| I2NSF Client | App Gateway
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client Facing Interface
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor | Application Support |
Facing <--->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Security
Interface | SPD, SAD and PAD Entries Distr. | Controller
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Derivation and Distribution |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSF Facing Interface
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| I2NSF Agent | Network
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Security
| IPSec (SPD,SAD,PAD) | Function (NSF)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Protection and Forwarding |
+---------------------------------------------+
Figure 2: Case 2: IPsec (no IKE) in the NSF
As shown in Figure 2, applications for flow protection run on the top of the security controller. When an administrator enforces flow protection policies through an application interface, the security controller translates those requirements into SPD,PAD and SAD entries that will be installed in the NSF.
Advantages: 1) It allows lighter NSFs (no IKE implementation). 2) IKE does not need to be run in gateway-to-gateway scenario with a single controller (see Section 9.1).
Disadvantages: The overload of IPsec SA establishment is shifted to the security controller since IKE is not required in the NSF.
In order to support case 2, the following requirements are to be met:
The cases presented above require an analysis of the communication channel between the IPSec stack and the security controller that is performing the key management operations.
The IETF RFC 2367 (PF_KEYv2) [RFC2367] provides a generic key management API that can be used not only for IPsec but also for other network security services to manage the IPsec SAD. Besides, as an extension to this API, the document [I-D.pfkey-spd] specifies some PF_KEY extensions to maintain the SPD. This API is accessed using sockets.
An I2NSF Agent implementation in the NSF can interact with both APIs in a kernel and returns and provides the same information using the NSF Facing Interface. In the following, we show a summary of these messages just to show an example of what may provide the NSF Facing Interface. The details and the accurate information is in RFC 2367 and [I-D.pfkey-spd].
To manage the IPsec SAD we have the following messages in the PF_KEYv2 API:
Although it is not a standard, KAME IPsec has defined a set of extensions to PF_KEY in order to handle the SPD [I-D.pfkey-spd]. The extended API offers the addtional extensions:
Regarding PAD management, we have not found any related extension. However, from the abstract data model defined in Section 8 for the PAD an interface could be designed.
These cases assume a data model representing the information to be exchanged between controller and network resource through the southbound interface. As described before this data model has to include the following information [RFC4301] (sketch that needs to be developed):
Data model for the SDP entries:
Data model for the SAD entries:
Data model for the PAD entries:
Data model for the IKE configuration:
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 Provider (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. The gateway implements our Flow-based NSF.
Now, Enterprise A requires that certain traffic between the HQ and BOs MUST be protected, for example, with confidentiality and integrity. The Enterprise A's administrator has to configure flow protection policies in the ISP's security controller, determining that the traffic among Enterprise A's HQ (HQ A) and each BO MUST be protected.
+----------------------------------------+
| Security Controller |
| |
(1) | +--------------+ (2)+--------------+ |
Flow ----------> | Translate |--->| South. Prot. | |
Protect. Pol. | |IPsec Policies| | | |
| +--------------+ +--------------+ |
| | | |
| | | |
+--------------------------|-----|-------+
| |
| (3) |
|-------------------------+ +---|
From V V To
HQ A +----------------------+ +----------------------+ BO
--->| NSF1 |<=======>| NSF2 |---->
|IKE/IPsec(SPD/SAD/PAD)| |IKE/IPsec(SPD/SAD/PAD)|
+----------------------+ (4) +----------------------+
Figure 3: Gateway-to-Gateway single controller flow for case 1 .
Figure 3 describes the case 1:
In case 2, Flow Protection Policies defined by the administrator are also translated into IPsec SPD entries and inserted into the corresponding NSFs. Besides, SAD entries will be also defined by the controller and enforced in the NSFs. In this case the execution of IKE is not necessary in the controller, and a Key Derivation function can be used to provide the required cryptographic material for the IPsec SAs. These keys will be also distributed through the southbound interface. Note that it is possible because both NSFs are managed by the same controller.
+----------------------------------------+
| (1) Security Controller |
Flow Prot. ---------| |
Pol. | V |
| +-------------+(2)+---------------+ |
| | Key Deriv. &|-->| South. Prot. | |
| | Distribution| | | |
| +-------------+ +---------------+ |
| | | |
| | | |
+----------------------| --- |-----------+
| |
| (3) |
|----------------------+ +--|
From V V To
HQ A +------------------+ +------------------+ BO
------->| NSF1 |<=====>| NSF2 |------->
|IPsec(SPD/SAD/PAD)| 4) |IPsec(SPD/SAD/PAD)|
+------------------+ +------------------+
Figure 4: Gateway-to-Gateway single controller flow for case 2.
Figure 4 describes the case 2, when a data packet is sent from HQ A with destination BO :
In general (for case 1 and case 2), this system presents various advantages to the ISP: (i) it allows to create a IPsec SA among two NSFs, 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 NSFs 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 certain traffic among its headquarters to be protected with confidentiality and integrity, so the ISPs have to configure Flow Protection Policies in their security controllers. Both administrators define Flow Protection Policies in each Security Controller that will end with the translation into SPD and PAD entries and IKE credentials in each NSF so that the specified traffic exchanged among these headquarters will be protected.
+-------------+ +-------------+
| ISP_A's | | ISP_B's |
Flow Prot. | Security |<=================>| Security <--- Flow Prot.
Pol. ---> Controller | (3) | Controller | Pol.
(1) | | | | (2)
+-------------+ +-------------+
| |
| (4) (4) |
From V V To
HQ A +----------------------+ +----------------------+ BO
------>| NSF1 |<========>| NSF2 |------->
|IKE/IPsec(SPD/SAD/PAD)| |IKE/IPsec(SPD/SAD/PAD)|
+----------------------+ (5) +----------------------+
Figure 5: Gateway-to-gateway multi controller flow in case 1
On the one hand, case 1, Figure 5 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. ---> IKE? | <---- Flow
Prot. | Security |<=================>| Security | Prot.
Pol.(1)| Controller | (3) | Controller | Pol. (2)
| | | |
+--------------+ +--------------+
| |
| (4) (4) |
From V V To
HQ A +------------------+ (5) +------------------+ HQ B
------>| NSF1 |<==============>| NSF2 |---->
|IPsec(SPD/SAD/PAD)| |IPsec(SPD/SAD/PAD)|
+------------------+ +------------------+
Figure 6: Gateway-to-gateway multi controller flow in case 2
On the other hand, case 2, Figure 6 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.
End user is a member of Enterprise A who needs to connect to the HQ's internal network. Enterprise A has deployed a NSF acting as IPsec-based VPN concentrator in its HQ to allow members of the organization 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 end users users, for example, by running IKE to establish an IPsec tunnel. With the SDN-based management of IPsec we can automatize these configurations.
In case 1, as we can see in Figure 7, the administrator configures a Flow Protection Policy in the security controller (1). The controller generates IKE credentials and translates that into SPD and PAD entries and installs them in the corresponding NSF (2). With those policies and IKE credentials, end user and gateway can negotiate IKE.
+----------------------------------------+
| Security Controller |
| |
(1) | +--------------+ +--------------+ |
Flow ---------->| Translate |--->| South. Prot. | |
Protect. Pol. |IPsec Policies| | | |
| +--------------+ +--------------+ |
| | |
| (2) | |
+--------------------------|-------------+
|
V
+----------+ +-----------------------+
| End user | | NSF | To HQ
| IKE/IPsec|<===================>| IKE/IPsec(SPD/SAD/PAD)|------->
+----------+ (3) +-----------------------+
Figure 7: Host-to-gateway flow protection in case 1.
In case 2, IKE implementation now resides in the security controller, as we can see in Figure 8. Here, the NSF needs to forward IKE packets to the controller. Therefore, the IKE negotiation is performed by the end user and the security controller (1), being this fact completely transparent for the end user.
Once the IKE negotiation has been successfully completed, the IPsec SA is available in the end user and in the security controller. The IPsec SA information is to be provisioned into the NSF's SAD, SPD and PAD (2). Now the end user and the NSF 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.
+----------------------------------+
| Security Controller |
| |
| +----------+ +-------------+ |
| | IKE |-->| South. Prot.| |
| | | | | |
| +----------+ +-------------+ |
| ^ | |
| | | |
+--------|-------------|-----------+
| |
(1) | | (2)
| V
+----------+ +--|----------------+
| |<------------+ |
| End user | | Gateway | To HQ
| IKE/IPsec|<========>| IPsec(SPD/SAD/PAD)|------->
+----------+ (3) +-------------------+
Figure 8: Host-to-gateway flow protection in case 2.
One of the main problems of this scenario is that the security controller has to implement IKE and negotiate with the end user. Additionally, it is still unclear the security implications of performing IKE with a different end point than the NSF. Finally, in terms of implementation, the IKE packets should bypass IPsec protection in the NSF and be forwarded to the security controller.
TBD.
Authors want to thank Sowmini Varadhan, Linda Dunbar, Carlos J. Bernardos, Alejandro Perez-Mendez and Alejandro Abad-Carrascosa 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. |