Overlay network for security policies

Here a few tips to get around the deployment limitations of IPSec and Internet Key Exchange protocol

One way to ensure the security of business transactions, customer data and intellectual property is to use IPSec to provide data encryption and authentication services. However, the management of IPSec policies and the Internet Key Exchange protocol -- which is used for the authentication of end nodes and the creation of the IPSec security associations -- present some practical deployment limitations. These constraints can be addressed using a three-layer approach to security.

IKE is complex because it requires a connection between two endpoints and completion of a key negotiation. IKE cannot be used if the network traffic is sent from point to multipoint or multipoint to multipoint, because there is no single pair of points that can perform key negotiation. As a result, IKE does not enable the scale of IPSec policies for large networks. For example, if a network has 100 IPSec nodes with 20 subnets at each node, the number of security associationscould reach 79,200.

Recently, the IETF Multicast Security (MSEC) working group proposed two new protocols for key distribution: Group Domain of Interpretation (GDOI) RFC 3547 and Group Secure Association Group Management Protocol (GSAKMP) RFC 4534. These efforts are limited to multicast. While securing multicast communications is essential, data privacy must be provided over any network topology, including point to multipoint, mesh, and hub-and-spoke, any kind of IP traffic, including unicast, multicast and broadcast.

There is, however, a way to get around the limitations of the proposed IETF protocols and IPSec with IKE: By dividing policy and key management into components (a management plane and a control plane) separate from the IPSec Encapsulation Security Payload (ESP) data plane, we can change the fundamental connection-oriented nature of IPSec for encryption of data in motion. The resulting three-layer approach includes the following components:

Policy enforcement point: PEP devices still exist in the network to protect traffic, but rather than exchanging keys on a one-to-one basis using IKE, they receive their own policies, keys and security associations externally from a centralized entity.

Key authority point: The KAP generates encryption keys and security associatesassociated with policies that it then distributes to the PEP units and peer KAP devices.

Management and policy server: The MAP provides network policy management and policy distribution to the KAP servers . It also can interface with existing network-based AAA services to provide authentication of the endpoints, enabling the enforcement of user entitlement through security policies and encryption keys.

The management plane or policies are not defined for a device, but for an end-to-end network. Multiple PEPs can be grouped together over the same policy in order to encrypt data for point-to-point, mesh, and hub-and-spoke networks. The control plane or keys are shared by multiple PEP devices in multiple paths on a resilient network, or by many endpoints in a multicast application.

This network security overlay for the generation of policies and keys can accommodate all data-privacy requirements for resilient, multicast and MPLS networks, and is transparent to the network routing and switching infrastructure.

However, to provide universal data protection, it must be designed as a secure, resilient and scalable system; security must be implemented at the unit, system and communication layer; resilient key operations must be provided; and, the overlay must scale to serve hundreds of endpoints.

Join the newsletter!

Error: Please check your email address.

More about EndPointsIETFMotion

Show Comments

Market Place