I2NSF R. Marin-Lopez
Internet-Draft G. Lopez-Millan
Intended status: Experimental University of Murcia
Expires: May 3, 2017 S. Varadhan
October 30, 2016

Software-Defined Networking (SDN)-based IPsec Flow Protection


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.

Status of This Memo

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 May 3, 2017.

Copyright Notice

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.

Table of Contents

1. Introduction

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 growth 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 define 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:

The network resource (or Network Security Function, NSF) implements the Internet Key Exchange (IKE) protocol and the IPsec databases: the Security Policy Database (SPD), the Security Association Database (SAD) and the Peer Authorization Database (PAD). The controller is in charge of provisioning the NSF with the required information about IKE, the SPD and the PAD.
The NSF only implements the IPsec databases (no IKE implementation). The controller will provide the required parameters to create valid entries in the PAD, the SPD and the SAD in the NSF. Therefore, the NSF will have only support for IPsec while automated key management functionality is moved to the controller.

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 10.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 10.2, where the NSFs involved are under the control of different security controllers.

The host-to-gateway scenario described in Section 10.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.

It is worth noting that this work pays attention to the challenge "Lack of Mechanism for Dynamic Key Distribution to NSFs" defined in [I-D.ietf-i2nsf-problem-and-use-cases] in the particular case of the establishment and management of IPsec security associations. In fact, this I-D could be considered as a proper use case for this challenge in [I-D.ietf-i2nsf-problem-and-use-cases].

2. Requirements Language

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.

3. Terminology

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:

4. Objectives

5. Case 1: IKE/IPsec in the NSF

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

5.1. Requirements

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:

6. Case 2: IPsec (no IKE) in the NSF

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), which benefits the deployment in constrained NSFs. 2) IKE does not need to be run in gateway-to-gateway scenario with a single controller (see Section 10.1).

Disadvantages: The overload of IPsec SA establishment is shifted to the security controller since IKE is not in the NSF. As a consequence, this may result in a more complex implementation in the SDN controller side. For example, the security controller needs to supervise the IPsec SA rekeying so that, after some period of time (e.g. IPsec SA soft lifetime), to create a new IPsec SA and remove the old one. Another example is the NAT traversal support. In this case, since the security controller has a complete view of the network (as SDN paradigm assumes) it can determine tha there is a NAT between two NSFs and apply the required policies to both NSFs besides activating the usage of UDP encapsulation of ESP packets.

6.1. Requirements

In order to support case 2, the following requirements are to be met:

  • It requires the provision of SPD, PAD and SAD entries into the NSF. A southbound protocol MUST support sending this information to the NSF.
  • NSF MUST be capable to protect data flows with IPsec, such as the capability to forward data through an IPsec tunnel.
  • It requires an (northbound) application interface in the security controller allowing the management of IPsec policies.
  • In scenarios where multiple controllers are implicated, SDN-based flow protection service may require a mechanism to discover which security controller is managing a specific NSF.

7. Abstract interface (NSF facing interface)

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].