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

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 . 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 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 . 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 . A YANG model for IPsec can be found in . Second, this document considers two scenarios to manage autonomously IPsec SAs: gateway-to-gateway and host-to-gateway . 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 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 , where the NSFs involved are under the control of different security controllers. The host-to-gateway scenario described in 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. When these words appear in lower case, they have their natural language meaning.

This document uses the terminology described in , , , , , , and . In addition, the following terms are defined below: Software-Defined Networking. A set of techniques enabling to directly program, orchestrate, control, and manage network resources, which facilitates the design, delivery and operation of network services in a dynamic and scalable manner . Flow/Data Flow. Set of network packets sharing a set of characteristics, for example IP dst/src values or QoS parameters. Flow Protection Policy. The set of rules defining the conditions under which a data flow MUST be protected with IPsec, and the rules that MUST be applied to the specific flow. IKE. Protocol to establish IPsec Security Associations (SAs). It requires information about the required authentication method (i.e. preshared keys), DH groups, modes and algorithms for IKE phase 1, etc. SPD. IPsec Security Policy Database. It includes information about IPsec policies direction (in, out), local and remote addresses, inbound and outboud SAs, etc. SAD. IPsec Security Associations Database. It includes information about IPsec security associations, such as SPI, destination addresses, authentication and encryption algorithms and keys. PAD. Peer Authorization Database. It provides the link between the SPD and a security association management protocol such as IKE or our SDN-based solution.

Flow-based data protection: controller-based flow protection services based on IPsec to allow the protection of specific data flows based on defined security policies. Establishment and management of IPsec security associations: this service allows the centralized management of IPsec SAs to protect specific data flows.

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

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

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: The NSF MUST implement IKE and IPsec databases: SPD, SAD and PAD. It MUST provide an (southbound) interface to provision SPD and PAD entries, IKE Credentials and to monitor the IPsec databases and IKE implementation. Note that SAD entries are created in runtime by IKE. A southbound protocol MUST support sending these SPD and PAD entries, and IKE credentials to the NSF. It requires an (northbound) application interface in the security controller allowing the management of IPsec SAs. 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.

This section describes the referenced architecture to support SDN- based IPsec flow protection where the security controller performs automated key management tasks.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 | +---------------------------------------------+ ]]> As shown in , 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 ). 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: 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.

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) 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 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 . To manage the IPsec SAD we have the following messages in the PF_KEYv2 API: The SADB_GETSPI message allows a process to obtain a unique SPI value for given security association type, source address, and destination address. This message followed by an SADB_UPDATE is one way to create a security association (SADB_ADD is the other method). The SADB_UPDATE message allows a process to update the information in an existing Security Association. The SADB_ADD message is nearly identical to the SADB_UPDATE message, except that it does not require a previous call to SADB_GETSPI. The SADB_DELETE message causes the kernel to delete an IPsec SA from the SAD. The SADB_GET message allows a process to retrieve a copy of a Security Association from the SAD. The SADB_ACQUIRE message is typically triggered by an outbound packet that needs security but for which there is no applicable IPsec SA existing in the SAD. The SADB_REGISTER message allows (a socket) to receive SADB_ACQUIRE messages for the type of IPsec SA. The SADB_EXPIRE message is issued when soft limit or hard limit (lifetime) of a IPsec SA has expired. The SADB_FLUSH message causes the kernel to delete all entries in its IPsec SAD. The SADB_DUMP message causes to dump the operating system's entire IPsec SAD. Although it is not a standard, KAME IPsec has defined a set of extensions to PF_KEY in order to handle the SPD . The extended API offers the addtional extensions: The SADB_X_SPDSETIDX message allows a process to add only selector of the security policy entry to the SPD. The SADB_X_SPDUPDATE message replaces the parameters of an existing SPD entry. The SADB_X_SPDADD is message allows a process to add a new security policy entry to the SPD. The SADB_X_SPDDELETE message causes the kernel to delete an entry from the SPD. The SADB_X_SPDDELETE2 message nearly identical to the SADB_X_SPDDELETE message, except that it specifies the policy id. The SADB_X_SPDGET message is allows a process to retrieve a copy of a security policy entry from the SPD. The SADB_X_SPDACQUIRE message is triggered by an outbound packet that needs security policy but for which there is no applicable information existing in the SPD. The SADB_X_SPDEXPIRE message is issued when limit of a security policy (SPD entry) has expired. The SADB_X_SPDFLUSH message causes the kernel to delete all entries in the IPsec SPD. The SADB_DUMP causes the kernel to dump all entries in the IPsec SPD. Regarding PAD management, we have not found any related extension. However, from the abstract data model defined in 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 (sketch that needs to be developed): Data model for the SDP entries: Name PFP flags Perfect forward secrecy Selector list: Remote IP addresses(es) Local IP addresses(es) Flow direction Next Layer Protocol Local port Remote port Type code Processing: Extended sequence number Sequence overflow Fragment checking IP compression DF bit DSCP IPsec protocool (AH/ESP) Algorithms Manual SPI Local tunnel endpoint Remote tunnel endpoint Tunnel options Data model for the SAD entries: SPI Local peer Remote peer SA mode (tunnel or transport) Security protocol Sequence number options Life-time Upper protocol Direction Tunnel source IP address and port Tunnel Destination IP address and port AH parameters ESP parameters IP compression NAT traversal flag Path MTU Anti-replay window Data model for the PAD entries: Identifies the peers or groups of peers that are authorized to communicate with this IPsec entity. The protocol and method used to authenticate each peer. Authentication data for each peer. Constraints about the types and values of IDs that can be asserted by a peer with regard to child SA creation. Peer gateway location info (e.g., IP address(es) or DNS names). Data model for the IKE configuration: TBD. (NOTE: It may depend on the IKE version)

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.

| 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) +----------------------+ ]]> describes the case 1: The administrator establishes general Flow Protection Policies. The controller generates IKE credentials and translates the policies into SPD and PAD entries. The controller looks for the NSFs involved (NSF1 and NSF2) and inserts the SPD and PAD entries in both NSF1 and NSF2. All packets belonging to the flow that matches the IPsec SPD inserted by the security controller will trigger the IKE negotiation in NSF1 and NSF2 by using the IKE credentials. 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.

| South. Prot. | | | | Distribution| | | | | +-------------+ +---------------+ | | | | | | | | | +----------------------| --- |-----------+ | | | (3) | |----------------------+ +--| From V V To HQ A +------------------+ +------------------+ BO ------->| NSF1 |<=====>| NSF2 |-------> |IPsec(SPD/SAD/PAD)| 4) |IPsec(SPD/SAD/PAD)| +------------------+ +------------------+ ]]> describes the case 2, when a data packet is sent from HQ A with destination BO : The administrator establishes Flow Protection Policies. The controller translates these policies into IPsec SPD, PAD and SAD entries. The controller looks for the NSFs involved and inserts the these entries in both NSF1 and NSF2 IPsec databases. All packets belonging to the flow are tunneled between NSF1 and NSF2 by using the enforced configuration keys and parameters. No need to run IKE between NSF1 and NSF2. 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.

| 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) +----------------------+ ]]> On the one hand, case 1, 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): The administrator A establishes general Flow Protection Policies in ISP_A's Security Controller The administrator B establishes general Flow Protection Policies in ISP_B's Security Controller The ISP_A's security controller realizes that protection is between the NSF1 and NSF2, which is under the control of another security controller (ISP_B's security controller), so it starts negotiations with the other controller to agree on the IPsec SPD policies and IKE credentials for their respective NSFs. NOTE: This may require extensions in the East/West interface. Then, both security controllers enforce the IKE credentials and related parameters and the SPD and PAD entries in their respective NSFs. All packets belonging to the flow that matches the IPsec SPD inserted by the security controller triggers the IKE negotiation between NSF1 and NSF2 by using the enforced configuration keys and parameters.

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)| +------------------+ +------------------+ ]]> On the other hand, case 2, 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): The administrator A establishes general Flow Protection Policies in ISP_A's Security Controller The administrator B establishes general Flow Protection Policies in ISP_B's Security Controller The ISP_A's security controller realizes that traffic between NSF1 and NSF2 MUST be protected. Nevertheless, the controller notices that NSF2 is under the control of another security controller, so it starts negotiations with the other controller to agree on the IPsec SPD, PAD, SAD entries that define the IPsec SAs. NOTE: It would worth evaluating IKE as the protocol for the the East/West interface in this case. Once the controllers have agreed on key material and the details of the IPsec SA, they both enforce this information into their respective NSFs. Therefore, all packets belonging to the flow are protected between NSF1 and NSF2 by using the enforced configuration keys and parameters. 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 , 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.

| Translate |--->| South. Prot. | | Protect. Pol. |IPsec Policies| | | | | +--------------+ +--------------+ | | | | | (2) | | +--------------------------|-------------+ | V +----------+ +-----------------------+ | End user | | NSF | To HQ | IKE/IPsec|<===================>| IKE/IPsec(SPD/SAD/PAD)|-------> +----------+ (3) +-----------------------+ ]]> In case 2, IKE implementation now resides in the security controller, as we can see in . 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.

| South. Prot.| | | | | | | | | +----------+ +-------------+ | | ^ | | | | | | +--------|-------------|-----------+ | | (1) | | (2) | V +----------+ +--|----------------+ | |<------------+ | | End user | | Gateway | To HQ | IKE/IPsec|<========>| IPsec(SPD/SAD/PAD)|-------> +----------+ (3) +-------------------+ ]]> 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.