WO2008039506A2

WO2008039506A2 - Deploying group vpns and security groups over an end-to-end enterprise network and ip encryption for vpns

Info

Publication number: WO2008039506A2
Application number: PCT/US2007/020811
Authority: WO
Inventors: Serge-Paul Carrasco
Original assignee: Cipheroptics, Inc.
Priority date: 2006-09-27
Filing date: 2007-09-27
Publication date: 2008-04-03
Also published as: WO2008039506B1; WO2008039506A3

Abstract

Group Virtual Private Networks (Group VPNs) are provided for different types of machines in a data processing network Security groups are defined by a security policy for each member, wherein security policies and encryption keys are deployed to members of a security group using an IP Security (IPSec) network infrastructure with authentication via VPN mechanisms The group VPNs provide a trusted Internet Protocol (IP) network that can leverage and co-exist with security access control technologies, such as endpoint security that controls client network access or application security that controls user access to enterprise applications Additionally, IPSec protocol application to data packets on the enterprise network environment provide security for the data packet forwarding through the network Encryption of IP traffic using IPSec at the edge of the enterprise network supports resilient BGP/MPLS IP VPN network designs In the system a network A (100A, 101 A, 170A) communicates with network B (100, 101 A, 170A) through a network (150).

Description

DEPLOYING GROUP VPNS AND SECURITY GROUPS OVER AN END-TO-END ENTERPRISE NETWORK AND IP ENCRYPTION FOR VPNS

BACKGROUND OF THE INVENTION The present invention relates to how enterprise networks can create (internally or with their external service provider partners) Virtual Private Networks (VPNs) for different groups of clients and/or host applications, referred to herein as Group VPNs.

Enterprise networks often require different types of functional and/or organizational groups of users. Within the enterprise network, those groups have different privacy requirements for their Internet Protocol (IP) communication between their client users and/or between their client users and their host applications.

Present Network Data Protection Solutions

Most of the time, network traffic is sent "in the clear", unsecured without encryption or authentication of the sender and receiver. In order to allow private traffic to be sent in a secure manner, a number of security schemes have been proposed and are in use today. Some are application dependent, such as a specific program performing password authentication. Others, such as Security Socket Layer/Transport Layer Security (SSL/TLS), are designed to provide comprehensive security to specific classes of traffic such as Web traffic.

IPSec, as defined in RFC 2401, can work in tunnel mode by encrypting a data packet (if encryption is required since IPSec can be used for authentication only), performing a secure hash

(or authentication) on the packet, then wrapping the resulting packet in a new IP packet with a new header indicating it has been secured using IPSec.

The two endpoints where data protection through encryption is enforced are called Policy

Enforcement Points (PEPs). The two PEPs must establish the IPSec security services through a Security Association

(SA) and in particular, the encryption keys. This is can be accomplished using the Internet Key

Exchange (IKE) protocol, as defined in RFC 2409 (or RFC 4206 for its version 2), that negotiates keys in two phases: the first phase is used to secure a communication channel between the two PEPs; the second phase is used to create two unidirectional IPSec SAs. Traffic can now be encrypted based on the IPSec policy that defines the type of traffic to be protected between two identified IP addresses or subnets.

Limitations When Securing Networks with IPSec

While IPSec secures IP traffic at the network layer, key exchange mechanisms create a number of practical limitations when IPSec is deployed in networks. Manual keys are not generally used because of the configuration challenges and re-key requirements to implement them in large networks. For those reasons, IKE is normally used for key exchange. However, IKE is based on a secure connection being established between two

PEPs and a resulting key negotiation being completed between those two PEPs. As a result, this connection-oriented nature of IKE has a few drawbacks.

If the traffic needs to be sent and/or received through multiple paths, as would be the case in a resilient network, there is no single pair of points that can be identified to perform key negotiation and no single PEP that can be selected as the ultimate destination in the IPSec tunnel header. Finding a Balance Between Data Protection and Access Control

In an enterprise network, data availability enables business productivity. However, the availability of enterprise data requires managing the business risks associated with that availability. Data that is secured, but not available to users is worthless. Data that is accessed by users, but is unsecured is at risk. The challenge is to find the right balance between data protection and data availability.

Generally in an enterprise, different types of data are accessed by different types of users or groups. For example, users of the same business unit or the same organizational group such as engineering or finance might need to access the same data concurrently. Different business units or different organizational groups have different security requirements. Generally, protection of data for a financial or a legal department is somewhat different than data protection for a marketing or engineering department. In addition, some group transactions such as financial transactions might be secure, while other group transactions such as administrative information might be in the clear.

Connectivity in Networks with Complex Boundaries If organizational flow charts are usually informally or formally known within an enterprise, the various network links that establishes the data communication paths between client users and application data are generally more difficult to establish for network administrators.

Large enterprise networks have more and more complex physical and logical boundaries inside a building or across remote buildings, campuses or countries. Large enterprise networks also have complex physical and logical boundaries between internal, remote and external users of enterprise applications.

Therefore, provisioning any management functions, in particular security functions, that might affect various users of the same group is somewhat challenging. Even if it is easy to identify the members of the group, it is much more difficult to discover their physical communication paths for large scale networks.

The present invention further relates to how enterprise networks can secure their Internet

Protocol (EP) traffic using IP Security (IPSec) when that BP traffic is routed over resilient Multi- Protocol Layer Switching (MPLS) Layer 3 Virtual Private Networks (VPNs), also called IP

VPNs.

Enterprise networks have been connecting their remote sites using BGP/MPLS DP Virtual

Private Networks (VPNs) as defined in the DETF Request For Comment (RFC) 4364, as provided to them by service providers. Enterprise networks have been using those Multi-Protocol Layer Switching (MPLS) networks with different network redundancy scenarios, where Customer

Edge (CE) routers can be redundant and/or service Providers Edge (PE) routers can also be redundant.

Problems with the prior art

D? VPNs or MPLS BGP VPN (RFC 4364) Service providers have been supplying D? VPNs to their commercial enterprise customers using MPLS backbones. Enterprise networks are connected to their service provider networks through their edge routers called customer edge (CE) routers. Service providers offer the MPLS

VPN through their provider edge (PE) routers.

RFC 4364 describes the network architecture for a service provider to route the enterprise VPN traffic between its PEs.

Enterprise VPN routes are typically communicated from the CE to the PE using an

Interior Gateway Protocol (IGP) such as the Open Shortest Path Protocol (OSPF) or an Exterior

Gateway Protocol such as Exterior Border Gateway Protocol (eBGP). The service provider's PE propagates the VPN routes, called VPN routing and forwarding (VRF) to its PE peers using Interior BGP (iBGP). The enterprise VPN traffic is forwarded between the PEs connected to the enterprise site of the customer's VPN using MPLS Label Switched Paths (LSPs) in a mesh topology.

Since enterprise networks can use private addresses that cannot be routed over the service provider Internet network, PE routers need to create a new address format using a route distinguisher and the end-user IPv4 prefix address. Multi -Protocol Extensions to iBGP (MP-

BGP) can be used to carry those created addresses with BGP Extended Communities Attribute to simplify BGP routing of the VRFs. Deploying Resilient IP Core Networks

In order to ensure resilient network operations, enterprise customers can also load balance their site traffic over two CEs to the service provider network. Similarly, in order to ensure resilient network operations, service providers can load balance the enterprise traffic over two PEs. Additionally, enterprise customers can choose to use the services of two or more service providers, therefore ensuring that their CEs communicate to different PEs belonging to different service provider networks.

To multi-home the enterprise network to one or multiple service provider networks, paths from the CEs to the PEs must be redundant. Resilient network operations can be implemented through the use of resilient routing protocols such as Virtual Router Redundancy Protocol (VRRP) as defined in RFC 2338, and through the use of load balancing routing configurations such as eBGP load balancing. Deploying IPSec in the Network IPSec, as defined in RFC 2401, can work in tunnel mode by encrypting a data packet (if encryption is required since EPSec can be used for authentication only), performing a secure hash (or authentication) on the packet then wrapping the resulting packet in a new IP packet with a new header indicating it has been secured using IPSec.

The two endpoints where data protection through encryption is enforced are called Policy Enforcement Points (PEPs).

The two PEPs must establish the IPSec security services through a Security Association (SA) and in particular, the encryption keys. This is accomplished using the Internet Key Exchange (IKE) protocol, as defined in RFC 2409 (or 4206 for its version 2), which negotiates keys in two phases: the first phase is used to secure a communication channel between the two PEPs and the second phase is used to create two unidirectional IPSec SAs. Traffic can now be encrypted based on the IPSec policy that defines the type of traffic to be protected between two identified IP addresses or subnets. Limitations when Securing Networks with IPSec

While IPSec secures IP traffic at the network layer, key exchange mechanisms create a number of practical limitations when IPSec is deployed in networks.

Manual keys are generally not used because of the configuration challenges and re-key requirements to implement them in large networks. For those reasons, IKE is normally used for key exchange. However, IKE is based on a secure connection only established between two

PEPs, and a resulting key negotiation being completed between those two PEPs. As a result, the connection-oriented nature of IKE has a few drawbacks. If the traffic needs to be sent and/or received through multiple paths, as would be the case in a resilient network, there is no single pair of points that can be identified to perform key negotiation and no single PEP that can be selected as the ultimate destination in the IPSec tunnel header.

With the present state of the art, there is no way to enable redundant network designs for enterprise networks when securing traffic using IPSec with EKE.

IKE does not allow the design of the MPLS VPN network to be point-to-multipoint, one CE connected to multiple PEs, or multipoint-to-multipoint, multiple CEs connected to multiple PEs.

SUMMARY OF THE INVENTION

With the present state of the art, there is no way to enable different IPSec encryption of data between two given D? addresses. Currently there is no solution for an enterprise network to implement different network data protection schemes needed for different types of user clients or application hosts.

Furthermore, enterprise networks would prefer to leverage the same security infrastructure across different types of users and applications to lower their capital and operating expenses and across their various network boundaries. The present invention gives precedence to the deployment over an enterprise network of

Group Virtual Private Networks (VPNs) for different types of groups, called security groups, defined by a security policy for the members of a group. Group VPN enables the deployment of security policies and encryption keys to members of a security group using the same D? Security (IPSec) VPN network infrastructure. With Group VPN, enterprises are able to securely partition an enterprise network from end-to-end. Group VPN also provides an internal trusted network that can leverage and co-exist with network access control technologies. Access control technologies only allow trusted users and clients access to the applications.

In particular, each group, referred to as a security group, is defined by a security policy. According to that security policy, encryption keys are generated and distributed among the various members of the group. The Virtual Private Network (VPN) or enterprise data protected network secures Internet Protocol (IP) payload generated by the clients and/or host applications using D? Security (IPSec). Security groups are allowed over the same data protection infrastructure. Security groups provide a trusted IP network that can leverage and co-exist with security access control technologies, such as endpoint security that controls client network access or application security that controls user access to enterprise applications. Network Overlay of Security Policies and Encryption Keys to the Data Plane

More particularly, by dividing the generation and distribution of security policies and encryption keys into separate components and combining them in new ways across multiple devices, the fundamental connection-oriented approach of IPSec using IKE can be changed while maintaining most of its present features and all of its security capabilities. This approach can solve the present IPSec/IKE point-to-point limitations to completely secure network traffic over point-to-multipoint and multipoint-to-multipoint networks that are the ways that IP networks are designed.

This new three-layer approach to the deployment of the IPSec includes the following functional components:

PEP: The PEP devices still exist in the network to protect traffic, but rather than exchanging keys on a one-to-one basis using IKE with other PEPs, they receive their SAs externally from a centralized Key Authority Point (KAP) entity.

Key Authority Point (KAP): According to the security policies, the KAP generates SAs and encryption keys and then distributes them to the PEP units and peer KAP devices.

Management and Policy Server (MAP): The MAP generates the security policies and distributes them to the KAP servers. Generation and Distribution of Security Policies and Encryption Keys

The PEPs are deployed at various points in the enterprise networks that need secure tunnels. Each PEP is associated with a number of network sets that define a collection of networks identified by their IP addresses and their subnets. A policy can be defined for the network sets associated with each PEP that protects those networks. The KAP could be configured with the policies from the MAP and distributes those policies and SAs to the PEPs. The KAP generates a single outbound key for each PEP policy and its associated network sets and distributes it securely to the PEPs. For those remote peer PEPs that key would become the inbound key. A KAP on each site can share its outbound keys with each KAP on the other sites for each policy. Each PEP network set can receive its pair of inbound and outbound keys per policy from its associated KAP. PEPs encrypt traffic using IPSec Encrypting Security Payload (ESP) from network to network. Traffic through the PEPs is essentially the same as traffic through any other IPSec gateways except that on outbound traffic, the source and destination IP addresses are maintained from the original and unencrypted packet. In other words, the initial IP address is preserved from encryption.

Additional information about the details of the generation and distribution of security policies and encryption keys are incorporated by the following co-pending U. S. Patent Applications, all of which are assigned to CiperOptics, Inc., the assignee of the present application, and all of which are hereby incorporated by reference in their entirety:

United States Provisional Patent Application No. 60/756,765 entitled SECURING

NETWORK TRAFFIC USING DISTRIBUTED KEY GENERATION AND DISSEMINATION OVER SECURE TUNNELS, filed January 6, 2006, which describes how an IP header of an outgoing packet is copied into an outer header of an IPsec tunnel mode packet;

United States Provisional Patent Application No. 60/813,766 entitled SECURING NETWORK TRAFFIC BY DISTRIBUTING POLICIES IN A HIERARCHY OVER SECURE TUNNELS, filed June 14, 2006, which describes how to distribute security policies using tunnels; and

United States Provisional Patent Application No. 60/837,410 entitled ENFORCING SECURITY GROUPS IN A NETWORK OF DATA PROCESSORS filed August 11, 2006, which describes a service layer approach to implementing group security functions.

Deploying Group VPNs and Creating Security Groups

Leveraging this architecture for the generation and distribution of security policies and encryption keys, enterprise networks can deploy multiple Group VPNs inside their boundaries. A Group VPN provides a secure virtualized network for a given security group. Internal and/or external enterprise users and resources are logically partitioned based on their memberships to a security group. Network traffic within corporate LANs and between sites/hubs is protected within virtualized security groups. A security group defines networks that can be accessed by a certain type of clients and/or applications. Security group types can include: User clients to user clients (defined by subnets/IP addresses to subnets/IP addresses for the BPSec encryption);

Clients to host applications/datacenters (defined by subnets/IP addresses to IP addresses); and,

Applications/datacenters to applications/datacenters (defined by IP addresses to IP addresses).

A client or an application can belong to more than one security group.

When identification of the security groups is established, security policies can be created, "per group," by the MAP and distributed to the KAPs. Each KAP negotiates the encryption keys associated with the security group policies with its peer KAP. The KAP then distributes the keys to its associated PEPs. Large enterprise networks covering multiple remote sites and/or distributed over multiple countries can use a network of distributed MAPs, such as one per site, instead of implementing a centralized MAP. In that case, administrator knowledge of the security group requirements can be limited to his or her site administration responsibilities. Additional information about the details of the generation and distribution of security policies and encryption keys are contained in the patents incorporated by reference above. Integrating Group VPN with Endpoint and Application Security

Network access of the members of a security group can leverage endpoint access control solutions. The client is authenticated via the LAN switching infrastructure, implementing the BEEE 802. Ix and the Extensible Authentication Protocols (EAP) by the access control server using RADIUS or any other server authentication method.

If remediation is required, the client accesses the remediation server. When the client is allowed to access the network, its PEP receives its security group membership with its security policies and encryption keys from the MAP through the KAP. The PEP may be integrated to the client or be an external device.

A number of emerging technologies that does not require software agents at the client, such as virtual machines that can isolate clients, or extensions to Dynamic Host Configuration Protocol (DHCP) that can re-route client access to an isolated LAN, are other alternatives to client authentication using 802. Ix and EAP. Whether the authentication mechanism for the client requires a software agent for the client, as in the case with 802. Ix and EAP, or no software agent, security groups can be used in both cases after client authentication has been performed to deliver its security policies and encryption keys to its PEP.

Security groups can also leverage other existing types of enterprise security policies for users, applications and any organizational groups that can be stored, for instance into LDAP servers. In that case, the MAP will just have to input the various members and their associations from that source.

The Group VPN infrastructure can be designed in conjunction with application access, client security access and any types of enterprise security policies defined for users and applications.

The present invention gives precedence to the encryption of the Internet Protocol (D?) traffic using IP Security (IPSec) at the edge of the enterprise network for resilient BGP/MPLS D?

VPN network designs. All IP traffic from the enterprise network is protected using IPSec between the distributed enterprise sites over the MPLS network provided by the service provider. The enterprise network manages its own IPSec site-to-site VPN. The service provider independently manages its MPLS network, providing an IP VPN or Layer 3 MPLS VPN to the enterprise. The enterprise IPSec network can thus be seen as an overlay to the MPLS service provider network.

The enterprise network can have a redundant MPLS VPN network provided by one or multiple service providers and the enterprise network can be redundant as well. Because the enterprise IPSec network can be seen as an overlay network to the MPLS network, both the

IPSec network and the MPLS network can operate independently. The IP traffic is securely tunneled within IPSec tunnels from the edge to the edge of the enterprise network. The IPSec traffic is also tunneled within MPLS tunnels from the edge to the edge of the service provider network.

Network Overlay of Security Policies and Encryption Keys to the Data Plane

By dividing the generation and distribution of security policies and encryption keys into separate components and combining them in new ways across multiple devices, the fundamental connection-oriented approach of IPSec using IKE can be changed while maintaining most of its present features and all of its security capabilities. This approach can solve the present

IPSec/IKE point-to-point limitations to completely secure network traffic over resilient networks and in particular point-to-multipoint and multipoint-to-multipoint networks.

This new three-layer approach to the deployment of IPSec includes the following functional components: PEP: The PEP devices still exist in the network to protect traffic, but rather than exchanging keys on a one-to-one basis using IKE with other PEPs, they receive their SAs externally from a centralized entity (KAP).

Key Authority Point (KAP): According to the security policies, the KAP generates SAs and encryption keys, and then distributes them to the PEP units and peer KAP devices. Management and Policy Server (MAP): The MAP generates the security policies and distributes them to the KAP servers.

The result is that common keys can be used by multiple PEP devices for data transmission over multiple paths in a resilient network.

Generation and Distribution of Security Policies and Encryption Keys Implementing this three-layer approach, PEPs are deployed between the remote enterprise VPN sites that need secure tunnels.

Each PEP is associated with a number of network sets that defines a collection of networks identified by their IP addresses and their subnets. A policy will be defined for the network sets associated with each PEP protecting those networks. The KAP can be configured with the policies from the MAP, and can distribute those policies and SAs to the PEPs. The KAP can generate a single outbound key for each PEP policy and its associated network sets and distribute it securely to the PEP, as well as its peers. For those remote peer PEPs, that key can become the inbound key. Each PEP network set then receives a pair of inbound and outbound keys per policy from the KAP. PEPs then encrypt the IP traffic using IPSec Encapsulating Security Payload (ESP) from network to network.

Traffic through the PEPs is essentially the same as traffic through any other IPSec gateway except that on outbound traffic the source and destination IP addresses are maintained from the original and unencrypted packet. In other words, the initial IP address is preserved from encryption.

Depending on the capability of the system, policies can be defined by network topologies such as point-to-point between two sites, mesh-of-sites, and hub-and-spoke site topologies. Policies may also be defined by multicast application if multicast is enabled between the sites. Multiple policies can be applied to the same network set. Additional information about the details of the generation and distribution of security policies and encryption keys are incorporated by the following co-pending U. S. Patent Applications, all of which are assigned to CiperOptics, Inc., the assignee of the present application, and all of which are hereby incorporated by reference in their entirety:

United States Provisional Patent Application No. 60/756,765 entitled SECURING NETWORK TRAFFIC USING DISTRIBUTED KEY GENERATION AND

DISSEMINATION OVER SECURE TUNNELS, filed January 6, 2006, which describes how an IP header of an outgoing packet is copied into an outer header of an IPsec tunnel mode packet;

United States Provisional Patent Application No. 60/813,766 entitled SECURING NETWORK TRAFFIC BY DISTRIBUTING POLICIES IN A HIERARCHY OVER

SECURE TUNNELS, filed June 14, 2006, which describes how to distribute security policies using tunnels; and Data Protection Implementation Over the 4364 Network

The IPSec data protection network is an overlay to the MPLS Layer 3 VPN redundant network, so no change is required to the service provider MPLS network. Enterprise traffic from

CE to CE is protected. The original IP header is maintained and in the clear as the packet IP address and the entire original packet including both its header and its payload is encrypted using IPSec ESP. This enables the enterprise customer to leverage the service provider service level agreements (SLAs) and network operations management capabilities. VPN routes between CE and PE are in the clear. The MAP provides polices for each network to communicate through the MPLS network and protect traffic between CE sites. The KAP provides a single outbound key for each PEP of the MPLS VPN and distributes it securely to the PEP, as well as its peers. And, the KAP can be redundant. Security policies can be additionally tailored to the topology of the MPLS cloud such as full-mesh, partial-mesh, and hub-and-spoke. Policies can also support unicast and multicast IP traffic.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing will be apparent from the following more particular description of example embodiments of the invention, as illustrated in the accompanying drawings in which like reference characters refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead is placed upon illustrating embodiments of the present invention.

FIG. 1 illustrates the set-up of IPSec tunnels and SAs for two networks, network A and network B, for a case of there being two PEPs (one for each network) and a case where the PEPs for each network need to be redundant.

FIG. 2 illustrates a network overlay of the management and control plane to the data plane for the generation of the security policies and encryption keys.

FIG. 3 illustrates how a KAP for a security group, whose policy is defined by a MAP, generates each key and distributes the key to its PEP and its peer KAPs.

FIG. 4 illustrates a Group VPN network reference design for multiple security groups disseminated over multiple enterprise sites.

FIG. 5 illustrates how security groups can be linked to existing organizational groups from a

LDAP server. It also demonstrates how security policies and encryption keys can be given to a client after control of its access and remediation procedure has been performed.

FIG. 6 illustrates the three layers (network, endpoint and application), that need to be trusted in order to establish a secure communication.

FIG. 7 illustrates group management concepts.

FIG. 8 illustrates a use case of an enterprise network with four remote sites connected over an MPLS network provided by one or multiple service providers and providing a 4364 service to the enterprise.

FIG. 9 describes the various network resiliency scenarios possible between CEs and PEs for an enterprise network and its service providers.

FIG. 10 describes the set-up of IPSec tunnels and SAs for two networks, network A and network B, between two PEPs and when those PEPs are redundant. FIG. 11 describes the network overlay of the management and control plane to the data plane for the generation of the security policies and encryption keys.

FIG. 12 describes how a KAP with the security policies defined by the MAP generates each outbound key for each PEP of the enterprise site. f FIG. 13 details the IP addresses and subnets of the remote enterprise sites with their associated

PEPs connected to the service provider MPLS network.

DETAILED DESCRIPTION OF THE INVENTION

The present invention provides for Group Virtual Private Networks (Group VPNs) for different types of machines in a data processing network. Security groups are defined by a security policy for each member, wherein security policies and encryption keys are deployed to members of a security group using an IP Security (IPSec) network infrastructure with authentication via VPN mechanisms. The group VPNs provide a trusted Internet Protocol (IP) network that can leverage and co-exist with security access control technologies, such as endpoint security that controls client network access or application security that controls user access to enterprise applications. A description of example embodiments of the invention follows.

The diagram in the top half of FIG. 1 illustrates a typical scenario of IPSec using IKE for key generation. IKE phase I provides authentication and a secure channel between the two endpoints. IKE phase II negotiates the IPSec SAs between the two endpoints.

These are intended to only operate between two endpoints (Policy Enforcement Points) 120. In other words, IKE is a connection-oriented protocol between two endpoints.

Therefore, using IPSec with IKE for key generation alone does not enable a network 150 to be load- balanced or redundant. In other words, IKE cannot be used between four endpoints if the traffic is expected to be routed equally between each possible pair of endpoints as illustrated in the bottom half of FIG. 1.

The only way to encrypt traffic between two networks, network A (100-A) and network B (100-B) as in FIG. 1, using the point-to-point IPSec Encrypting Security Payload (ESP) would be to establish IPSec SAs that can be used between each possible pair of endpoints 120. The same security policies and encryption keys would be used between each pair of endpoints.

This could lead to the solution provided in FIG 2, where security policies and encryption keys overlay the data plane 204 for the encryption. In other words, in this approach, the management and control plane 202 does not physically coexist with the data plane 204. One layer provides the security policies that can be viewed as the management plane.

Another layer provides the encryption keys that can be viewed as the control plane. Encryption keys are generated according to the security policies.

In the preferred architecture, the device providing the security policy is called a Management Authority Point (MAP) 200, whereas the device providing the encryption keys is called a Key Authority Point (KAP) 210.

The MAP 200 interfaces to the KAP 210 that interfaces itself to the PEP 120.

The KAP 210 can be redundant. All policies and keys can be securely stored and distributed.

Policies for re-key can be clearly enabled. Each node (MAP, KAP and PEP) should be securely authenticated and authorized to accomplish its function.

Applying the concepts developed in FIG. 2 leads us to FIG. 3 which describes a preferred implementation of policies and key exchanges between remote PEPs 120.

In FIG. 3, a KAP 210-1 located at a first site, such as in Menlo Park, California (site 310-1), generates the outbound encryption keys for the PEPs (120-1, 120-2, 120-3) located at the Menlo Park site. The KAP 210-2 located at a site in New York 310-2 generates the outbound encryption keys for the PEPs (120-2-1, 120-2-2, 120-2-3) located at the New York site 310-2. The Menlo

Park site's KAP 210-1 distributes its PEP outbound encryption keys to the New York site's KAP

210-2 which then distributes them to the New York site PEPs (120-2). The New York site's KAP

210-2 does the same for the Menlo Park KAP 210-1. The outbound PEP keys for the Menlo Park site 310-1 become the inbound keys for the New York site 310-2. Similarly, the outbound keys for the New York 310-2 site become the inbound keys for the Menlo Park site 310-1.

For each IP address or subnet connected to a PEP 120, policies are defined by the MAP

200 and distributed to the KAP 210. As defined in the IPSec standard, policies can be encryption, clear or drop policies. Traffic through a PEP 120 is essentially the same as traffic through any other IPSec appliance, except that on outbound traffic the source and destination IP addresses can be copied from the original, unencrypted packet.

Now, assume that different remote IP addresses and subnets belong to one security group, and for that group, policies and keys are specific. As an example, FIG. 4 defines three groups, group A, group B and group C. Two members of group VPN A exist in the Menlo Park campus (site) 310-1, and one group A member exist in the New York site 310-2 and one member of group A in the Raleigh campus site

310-3. Other groups (group B and group C) also have various members at the different sites. Each member of a group uses the same outbound encryption keys generated and distributed by its local KAP 210. KAPs 210 exchange outbound keys between themselves, and distribute them to their PEPs 120 as described previously in FIG. 3.

Security group knowledge is defined in the MAP 200 (which may be distributed or not) and shared between MAPs 200. Each MAP 200 knows in its site domain, the IP addresses and/or subnets that are part of a given security group. Therefore, each MAP 200 can trigger its associated KAPs 210 to exchange keys for any given security group with other KAPs 210 that have group members of the same security group.

Since encryption keys can be exchanged without knowledge of the physical location of group members, these Group VPNs scale quite well in networks with complex boundaries. In particular, Group VPNs can scale well for large enterprise networks with numerous remote sites and/or international sites where group member locations can change often, but where group membership changes less frequently.

Therefore, Group VPNs significantly reduce the complexity of the network design and management.

Security groups can accommodate various types of users, such as remote and external users, without any change to the overall architecture. Remote users can connect to their respective PEP 120 as if they were connected to their LANs. For instance, a KAP 210 could be dedicated to remote access clients. External users can be prevented to have full network access inside the enterprise.

External users can be a specific group and can have a protected connection to the Internet.

Ideally when deploying Group VPNs, network access are enforced since security policies and encryption keys must be giving to trusted points in the network. As shown in FIG. 5, certain switching software allows managers to authenticate users and devices as they attempt to connect to a local network. One common mechanism is IEEE 802. Ix with the EAP protocol.

801. Ix requires a client software called supplicant. Most 802. Ix implementations use RADIUS servers for authentication of user names and passwords. Generally, RADIUS servers communicate with enterprise LDAP directory servers 430 to allow the same user names and passwords to be used both for desktop and network access. When a client user logs into an Ethernet switch, via 802. Ix, the switch 270 communicates with the Network Access Control (NAC) server 410. The NAC server 410 routes that information to a RADIUS server (not shown) to check the user client credentials. When the RADIUS server authenticates the client, the NAC server 410 verifies that the client 140 is in sync with the security policies. If not, the client 140 is routed to the remediation server 420 to get the required software upgrades to meet the security policies. The client user PEP 120 will need to acquire its security policies and encryption keys from its associated KAP 210 after the client 140 is given permission to access the network and acquire its IP address from a DHCP server (not shown). This is before they can send or receive data that needs encryption. In order to achieve that, the RADIUS server and/or the enterprise LDAP directory server

430 will share the client security group user memberships. Both the NAC server 410 and the MAP 200 are also linked to provide the same security group memberships.

When the NAC server 410 allows the client 140 network access, it shall inform the MAP 200 so that the MAP 200 can trigger the KAP 210 to provide to the PEP 120 associated with the client user 140 the necessary encryption keys and the security policies.

Security groups can leverage other existing types of enterprise security policies for user and application access control for any functional and/or organizational groups that can be stored in enterprise LDAP directory servers 430. In that case, the MAP 200 will just have to input the various members and their associations for the application access control from the source, as its does for client network access control.

As shown in FIG. 6, one preferred security approach is to have a trusted network that provides end-to-end data protection with:

Endpoint network access control that provides a trusted client; and,

Application security that provides a trusted user. As shown in FIG. 7, security groups can be defined at various levels, using questions such as:

Who needs data protection?

Users, applications and/or organizations.

What needs to be protected? Data, networks, applications and/or datacenters.

When does data protection need to be triggered?

What are the conditions and the life cycle?

How to provide who, what and when?

What are the enterprise policies associated with functional and/or organizational roles and/or privileges.

The Group VPN infrastructure can be designed in conjunction with application and client security access and any type of enterprise security policies defined for users and applications as proposed.

While this invention has been particularly shown and described with references to example embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the scope of the invention encompassed by the appended claims.

Regarding Encryption of Internet Protocol (IP) traffic using EP Security (EPSec) at the edge of the enterprise network, the present invention further provides this in such a way as to support resilient BGP/MPLS EP VPN network designs. The IP traffic is securely tunneled within

EPSec tunnels from the edge to the edge of the enterprise network. The EPSec traffic is also tunneled within MPLS tunnels from the edge to the edge of the service provider network. The enterprise network thus manages its own EPSec site-to-site VPN. The service provider thus independently manages its own MPLS network. The result provides an EP VPN or Layer 3 MPLS VPN to the enterprise; the enterprise EPSec network can thus be considered as an overlay to the MPLS service provider network.

FIG. 8 is a typical use case of an enterprise network 100. That enterprise network 100 has four remote sites located in four different cities over the United States: Menlo Park, California

110-1, San Francisco, California 110-2, New York, New Yorkll0-3 and Raleigh, North Carolina 110-4.

Each site 110 might include a number of users 120, datacenters 130 and/or storage area networks 140. Sites can be considered as fairly large considering their number of subnets and as hubs to smaller branch offices that are not represented in this figure.

Each site 110 is called a VPN site and runs an EP network. Each VPN site is connected to one or more service provider MPLS networks 150, providing a BGP/MPLS EP VPN using enterprise network Virtual Private Network (VPN) routing and forwarding (VRF) functions, as defined in RFC 4364, to the enterprise.

Each site 110 wants to protect its IP traffic over the service provider networks 150 using

EPSec encryption. To that end, each site edge router in RFC 4364 (called a CE) is connected to a PEP 170 that provides EPSec encryption and decryption of EP packets. That PEP 170 can be external to the CE 160 or integrated to it as a blade.

The EP traffic for the enterprise is of high value to its business and therefore must be encrypted. But besides encryption, in order to provide that traffic reliably between each site, the enterprise also needs to provide a resilient network. Three case scenarios are possible for a resilient network, as represented in FIG. 9; the CE at each site 110 can be redundant; the service provider edge routers (called PEs in RFC 4364) inside the MPLS network 150 can be redundant; or, the PE can belong to one or more service providers. The minimum resiliency scenario is two PEs 180. The maximum resiliency scenario involves multiple CEs 160 and multiple PEs 180 belonging to multiple service providers. Full mesh connectivity would thus require maintaining 6 tunnels between the 4 endpoints. Different network protocols can be used to multi-home a CE 160 to a PE 180. CEs 160 can load balance their routing traffic across the PEs 180 using so-called eBGP load balancing. CE and PEs can also provide resilient routing. In other words, if a particular CE or PE is unable to route traffic anymore, a back-up router can take ownership of routing traffic. In that case, the CEs 160 or the PEs 180 must be running another routing protocol such as VRRP as defined in RFC 2338.

Let's assume that instead of having four VPN sites 110, the enterprise has n (n>2) VPN sites 110, with full mesh connections between the sites. Let's also assume that for each site, the enterprise has multiple policies (such as an encrypted, clear and drop policy for protocol pairs). If IPSec is operated between each PEP 170, and IKE is used for authentication of the nodes and encryption of the traffic, then the total number of tunnels between the sites 110 is calculated with binomial coefficients:

(n 2) = n! / (2! (n-2)! ) = ((n-1) x n) / 2

And the total number of IPSec SAs for those tunnels would be: 2 x (n 2) = (n-1) x n

The consequence of this large number is that network management, as well as network performance, becomes quite a challenge, especially if each site has multiple subnets to protect. The PEPs 170 must provide encryption at wire speed, therefore operating with high throughput and low latency capabilities. Furthermore, IPSec using IKE for key generation can only operate between two endpoints. In other words, IKE is a connection-oriented protocol between two endpoints. IKE phase I provides authentication and a secure channel between the two endpoints and IKE phase II negotiates the IPSec SAs between the two endpoints.

Therefore, using IPSec with IKE for key generation does not allow the network design to be redundant and load-balanced. In other words, IKE cannot be used between four PEPs at the same time, if the traffic is load-balanced or redundant between each pair of PEPs, as illustrated in FIG. 10.

One way to encrypt traffic between two networks, network A and network B using IPSec ESP, as in FIG 10, would be to establish two IPSec SAs that can be used between each pair of PEPs 170. The same security policies and encryption keys would be used between each pair of PEPs 170.

This can lead to the solution provided in FIG. 11, where security policies and encryption keys overlay the data plane for the encryption. In other words, the management and control plane 202 does not coexist with the data plane 204. One layer provides the security policies that can be viewed as the management plane and another layer provides the encryption keys that can be viewed as the control plane. Encryption keys are generated according to the security policies.

In the illustrated architecture, the device providing the security policy is called a Management Authority Point (MAP) 200, whereas the device providing the encryption keys is called a Key Authority Point (KAP) 210.

The MAP 200 interfaces to the KAP 210, which interfaces itself to the PEPs 170. The KAP 210 can be redundant. All policies and keys shall be securely stored and distributed. Policies for re-key should be enabled, and each node (MAP, KAP and PEP) should be securely authenticated and authorized to accomplish its function. Applying the concepts developed in FIG. 4 leads to FIG. 5, which describes a preferred implementation of key exchanges between multiple PEPs 170.

In FIG. 12, the primary PEP 170-1 located at the Menlo Park VPN site 110-1, will receive its outbound encryption key "kl" from the KAP 210. The KAP 210 itself would generate kl. The Menlo Park PEP 170-1 uses that key to encrypt its traffic. That key is also used by the PEPs (170-2, 170-3, 170-4) located at other sites 110 as inbound keys for traffic coming from the Menlo Park PEP 170-1. The KAP 210 thus also distributes kl to the PEPs (170-2, 170-3, 170-4) located at the San Francisco, New York and Raleigh sites (110-2, 110-3, 110-4, respectively).

When a redundant or secondary PEP 170-1-r is used at the Menlo Park site 110-1, the same security policy and encryption keys will apply both to the primary PEP 170-1 and secondary PEP 170-1-r.

Applying the concepts of FIG. 12, with the resiliency scenarios defined in FIG. 9 to the use case provided in FIG. 8, gives an overall solution as illustrated in FIG 13.

For example, the MAP 200 and KAP 210 are located in the San Francisco site 110-2 and provide policy and key generation and distribution for the four sites. Each site (110-1, 110-2, 110-3, 110-4) has a redundant PEP (120-1-r, 120-2-r, 120-3-r, 120-4-r). For each subnet per site, the MAP 200 needs to create four sets of policies and keys, and four mesh encryption tunnels.

Encryption of each site's VPN traffic at a PEP 120 is tunneled into the MPLS tunnel. IPSec tunnels are tunneled into MPLS tunnels giving the following packet frame:

MPLS VPN label (unmodified IP header IPSec (IP header and payload)). The initial IP header is maintained and in the clear as the packet EP address. The entire initial packet including both its header and its payload coming from the CE 160 is encrypted using IPSec tunnel mode. VPN routes communicated by the CE 160 to the PE 180 are in the clear.

Generalizing now our solution to a number of n sites, the total number of tunnels is reduced: (n n-1) = n! / ((n-1)! (n-n+1)! ) = n And the total number of SAs is:

2 x (n n-l)= 2 n , reducing the number of SAs by a factor of: 2/(n-l).

Therefore, this solution significantly reduces the complexity of the network design and network operations management, while allowing the enterprise network to use IPSec encryption with a resilient MPLS network design.

While the present invention set forth in the foregoing has been particularly shown and described with references to example embodiments thereof, it will be understood by those skilled in the art that .various changes in form and details may be made therein without departing from the scope of the invention encompassed by the appended claims.

Claims

CLAIMSWhat is claimed is:

1. A method for providing secure communication among members in a virtual private network comprising: defining a security group, the security group comprising identification of two or more members to be enabled to securely communicate with one another; upon request by a group member to communicate with other members of a security group, determining if the group member is authenticated using a virtual private network (VPN) authentication function; if the group member is authenticated by the VPN authentication function; then, presenting the group member with a security association to enable the member to carry out secure communication within the group.

2. The method of claim 1 wherein the security association comprises at least one of a security policy and an encryption key.

3. The method of claim 1 wherein the security association is provided by a network overlay that provides security policies and encryption keys to members of the security group.

4. A method for operating on a data packet to provide an enterprise networking environment over a service provider network, comprising: a customer edge (CE) router function, located within the enterprise network, for: providing the data packet; a Policy Enforcement Point (PEP) function, for: applying an IPSec protocol to the data packet; and applying a security association policy to the data packet; a provider edge router function, located within the service provider network, for: applying an MPLS protocol to the data packet; and forwarding the data packet according to the enterprise network Virtual Private Network (VPN) routing and forwarding (VRF).

5. The method of claim 4, additionally comprising: receiving the security association from a network overlay that is responsible for distributing at least one of security policies and encryption keys to the PEPs.

6. The method of claim 1 or 5, wherein the network overlay additionally comprises: a security policy layer; and an encryption key layer.

7. The method of claim 1 wherein security groups are defined across physically distributed network sites without restriction on group members' physical locations.

8. The method of claim 1 wherein secure communication between group members uses an IPSec protocol.

9. The method of claim 8 wherein communication between group members uses IPsec packets where an original IP packet header is sent in the clear and an IP packet payload is sent in encrypted form.

10. The method of claim 6 wherein the security policy layer is provided by a Management And Policy (MAP) server and the encryption key layer is provided by a Key Authority Point (KAP) server.

11. The method of claim 1 wherein security group members are defined by a method selected from a group consisting of user clients to user clients, as defined by subnets/IP addresses to subnets/IP addresses; clients to host applications/datacenters, as defined by subnets/IP addresses to IP addresses; or host applications/datacenters to applications/datacenters, as defined by IP addresses to IP addresses.

12. The method of claim 1 wherein security groups are defined as internal, external or remote.

13. The method of claim 1 wherein a group member can belong to more than one security group.

14. The method of claim 1 wherein the step of determining if the user is authenticated is additionally integrated with Group VPN access control.

15. The method of claim 10 additionally comprising, by the KAP: generating outbound keys; and distributing pairs of inbound and outbound keys for each associated PEP.

16. The method of claim 4, additionally comprising: maintaining the original IP header in the data packet in the clear as the IP address; and encrypting the entire IP packet both its header and its payload of the data packet using IPSec ESP;

17. The method of claim 1, additionally comprising: providing resiliency, by connecting two or more CEs to two or more PEs.

18. The method of claim 17 wherein full mesh connectivity between n, where n is greater than 2, enterprise sites is provided by no more than n tunnels and no more than 2n security associations.

19. The method of claim 1 wherein security groups are integrated with enterprise security policies for users and applications, for organizational, or for functional groups.

20. The method of claim 1 wherein the step of determining if the group member is authenticated further comprises: forwarding an authentication request to a Network Access Control (NAC) server.

21. An apparatus for providing secure communication among members in a virtual private network (VPN) comprising: a security group storage device, for storing a definition of a security group, the security group comprising an identification of two or more members of the VPN to be enabled to securely communicate with one another; a receiver, for receiving a request by a group member to communicate with other members of a security group, a virtual private network (VPN) authentication server, for determining if the group member is authenticated; a security association interface, for receiving a security association to enable an authenticated member to carry out secure communication with other group members.

22. The apparatus of claim 21 wherein the security association comprises at least one of a security policy and an encryption key.

23. The apparatus of claim 21 wherein the security association interface is connected to a network overlay that provides security policies and encryption keys to members of the security group.

24. The apparatus of claim 21 wherein security groups are defined across physically distributed network sites without restriction on group members' physical locations.

25. The apparatus of claim 21 wherein secure communication between group members uses an IPSec protocol.

26. The apparatus of claim 25 wherein communication between group members uses IPsec packets where an original IP packet header is sent in the clear and an IP packet payload is sent in encrypted form.

27. An apparatus for operating on a data packet to provide an enterprise networking environment over a service provider network, comprising: a customer edge (CE) router within the enterprise network for providing the data packet; a Policy Enforcement Point (PEP) function arranged to: apply an IPSec protocol to the data packet; apply a security association policy to the data packet; and within the service provider network, a provider edge (PE) router arranged to: apply an MPLS protocol to the data packet; forward the data packet according to enterprise network Virtual Private Network (VPN) routing and forwarding (VRF) tables.

28. The apparatus of claim 27, wherein the PEP is additionally for receiving the security association from a network overlay that is responsible for distributing at least one of security policies and encryption keys to the PEPs.

29. The apparatus of claim 28 wherein the network overlay additionally comprises: a security policy layer provided by a Management And Policy (MAP) server; and an encryption key layer provided by a Key Authority Point (KAP).

30. The apparatus of claim 28 wherein full mesh connectivity between n enterprise sites, where n is greater than 2, is provided by no more than n tunnels and no more than 2n security associations.