[go: up one dir, main page]

WO2008039506A2 - Deploiement de reseaux prives virtuels de groupe et de groupes de securite sur un reseau d'entreprise de bout en bout et cryptage ip pour rpv - Google Patents

Deploiement de reseaux prives virtuels de groupe et de groupes de securite sur un reseau d'entreprise de bout en bout et cryptage ip pour rpv Download PDF

Info

Publication number
WO2008039506A2
WO2008039506A2 PCT/US2007/020811 US2007020811W WO2008039506A2 WO 2008039506 A2 WO2008039506 A2 WO 2008039506A2 US 2007020811 W US2007020811 W US 2007020811W WO 2008039506 A2 WO2008039506 A2 WO 2008039506A2
Authority
WO
WIPO (PCT)
Prior art keywords
security
network
group
enterprise
ipsec
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/US2007/020811
Other languages
English (en)
Other versions
WO2008039506A3 (fr
WO2008039506B1 (fr
Inventor
Serge-Paul Carrasco
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
CipherOptics Inc
Original Assignee
CipherOptics Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US11/529,560 external-priority patent/US8607301B2/en
Priority claimed from US11/656,077 external-priority patent/US8284943B2/en
Application filed by CipherOptics Inc filed Critical CipherOptics Inc
Publication of WO2008039506A2 publication Critical patent/WO2008039506A2/fr
Publication of WO2008039506A3 publication Critical patent/WO2008039506A3/fr
Publication of WO2008039506B1 publication Critical patent/WO2008039506B1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4641—Virtual LANs, VLANs, e.g. virtual private networks [VPN]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/50—Routing or path finding of packets in data switching networks using label swapping, e.g. multi-protocol label switch [MPLS]
    • H04L45/502—Frame based
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0272—Virtual private networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/105—Multiple levels of security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/065—Network architectures or network communication protocols for network security for supporting key management in a packet data network for group communications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/164—Implementing security features at a particular protocol layer at the network layer

Definitions

  • 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.
  • VPNs Virtual Private Networks
  • IP Internet Protocol
  • SSL/TLS Security Socket Layer/Transport Layer Security
  • 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
  • PEPs Policy Enforcement Points
  • IKE Internet Engineering Task Force (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.
  • 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
  • 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.
  • the present invention further relates to how enterprise networks can secure their Internet
  • IP Security IP Security
  • MPLS Multi- Protocol Layer Switching
  • VPNs Virtual Private Networks
  • VPNs Private Networks
  • RRC Request For Comment
  • MPLS Multi-Protocol Layer Switching
  • CE routers can be redundant and/or service Providers Edge (PE) routers can also be redundant.
  • PE Service Providers Edge
  • PE provider edge
  • 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
  • IGP Interior Gateway Protocol
  • OSPF Open Shortest Path Protocol
  • OSPF Open Shortest Path Protocol
  • the service provider's PE propagates the VPN routes, called VPN routing and forwarding (VRF) to its PE peers using Interior BGP (iBGP).
  • VRF VPN routing and forwarding
  • iBGP Interior BGP
  • 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.
  • LSPs MPLS Label Switched Paths
  • 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
  • enterprise customers can also load balance their site traffic over two CEs to the service provider network.
  • service providers can load balance the enterprise traffic over two PEs.
  • 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.
  • 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.
  • VRRP Virtual Router Redundancy Protocol
  • PEPs Policy Enforcement Points
  • the two PEPs must establish the IPSec security services through a Security Association (SA) and in particular, the encryption keys.
  • SA Security Association
  • IKE Internet Key Exchange
  • RFC 2409 or 4206 for its version 2
  • 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.
  • IPSec secures IP traffic at the network layer
  • key exchange mechanisms create a number of practical limitations when IPSec is deployed in networks.
  • IKE is normally used for key exchange.
  • IKE is based on a secure connection only established between two
  • IKE 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.
  • 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.
  • 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 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.
  • IPSec D? Security
  • 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.
  • each group referred to as a security group, is defined by a 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).
  • IP Internet Protocol
  • 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
  • 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.
  • KAP Key Authority Point
  • KAP Key Authority Point
  • the 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.
  • MAP Management and Policy Server
  • 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.
  • ESP IPSec Encrypting Security Payload
  • 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);
  • a client or an application can belong to more than one security group.
  • 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.
  • EAP Extensible Authentication Protocols
  • the client accesses the remediation server.
  • the client 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.
  • DHCP Dynamic Host Configuration Protocol
  • 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?
  • IP Security IP Security
  • 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
  • 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.
  • 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.
  • 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).
  • KAP centralized entity
  • KAP Key Authority Point
  • MAP Management and Policy Server
  • 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.
  • ESP IPSec Encapsulating Security Payload
  • 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.
  • 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:
  • 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.
  • 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.
  • SLAs service provider service level agreements
  • 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.
  • 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.
  • FIG. 13 details the IP addresses and subnets of the remote enterprise sites with their associated
  • 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.
  • IP Security IP Security
  • 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.
  • IP Internet Protocol
  • IKE phase I provides authentication and a secure channel between the two endpoints.
  • IKE phase II negotiates the IPSec SAs between the two endpoints.
  • IKE Policy Enforcement Points
  • 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.
  • Another layer provides the encryption keys that can be viewed as the control plane. Encryption keys are generated according to the security policies.
  • the device providing the security policy is called a Management Authority Point (MAP) 200
  • the device providing the encryption keys is called a Key Authority Point (KAP) 210.
  • MAP Management Authority Point
  • KAP Key Authority Point
  • 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.
  • Each node (MAP, KAP and PEP) should be securely authenticated and authorized to accomplish its function.
  • FIG. 3 describes a preferred implementation of policies and key exchanges between remote PEPs 120.
  • a KAP 210-1 located at a first site such as in Menlo Park, California (site 310-1)
  • 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.
  • Park site's KAP 210-1 distributes its PEP outbound encryption keys to the New York site's KAP
  • the outbound PEP keys for the Menlo Park site 310-1 become the inbound keys for the New York site 310-2.
  • the outbound keys for the New York 310-2 site become the inbound keys for the Menlo Park site 310-1.
  • policies are defined by the MAP
  • 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.
  • 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
  • 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.
  • Group VPNs can scale quite well in networks with complex boundaries.
  • 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.
  • 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.
  • 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.
  • Ix requires a client software called supplicant.
  • Most 802. Ix implementations use RADIUS servers for authentication of user names and passwords.
  • 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.
  • NAC Network Access Control
  • the NAC server 410 routes that information to a RADIUS server (not shown) to check the user client credentials.
  • the RADIUS server authenticates the client, the NAC server 410 verifies that the client 140 is in sync with the security policies.
  • 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.
  • the RADIUS server and/or the enterprise LDAP directory server
  • Both the NAC server 410 and the MAP 200 are also linked to provide the same security group memberships.
  • the NAC server 410 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.
  • 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
  • security groups can be defined at various levels, using questions such as:
  • 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.
  • IP Internet Protocol
  • EPSec EP Security
  • 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
  • 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.
  • VPN Virtual Private Network
  • VRF virtual Private Network
  • Each site 110 wants to protect its IP traffic over the service provider networks 150 using
  • 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.
  • VPN sites 110 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:
  • 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.
  • IKE 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.
  • the device providing the security policy is called a Management Authority Point (MAP) 200
  • the device providing the encryption keys is called a Key Authority Point (KAP) 210.
  • MAP Management Authority Point
  • KAP Key Authority Point
  • 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.
  • 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).
  • 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).
  • 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)).
  • 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.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention concerne des réseaux privés virtuels de groupe (RPV de groupe) destinés à différents types de machines dans un réseau de traitement de données. Des groupes de sécurité sont définis par une politique de sécurité pour chaque membre, des politiques de sécurité et des clés de cryptage étant déployées pour les membres d'un groupe de sécurité au moyen d'une infrastructure de réseau de sécurité IP (IPSec) avec une authentification par l'intermédiaire de mécanismes RPV. Les RPV de groupe fournissent un réseau de protocole Internet (IP) sécurisé pouvant optimiser des technologies de contrôle d'accès sécurisé, telles que la sécurité de bout en bout qui contrôle l'accès au réseau client ou la sécurité d'applications qui contrôle l'accès utilisateur à des applications d'entreprise, et coexister avec celles-ci. De plus, l'application du protocole IPSec sur des paquets de données dans l'environnement réseau d'entreprise permet de sécuriser la transmission de paquets de données sur le réseau. Le cryptage du trafic IP au moyen d'IPSec à la périphérie du réseau d'entreprise supporte des conceptions de réseaux privés virtuels BGP/MPLS IP souples.
PCT/US2007/020811 2006-09-27 2007-09-27 Deploiement de reseaux prives virtuels de groupe et de groupes de securite sur un reseau d'entreprise de bout en bout et cryptage ip pour rpv Ceased WO2008039506A2 (fr)

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US52955906A 2006-09-27 2006-09-27
US11/529,560 2006-09-27
US11/529,559 2006-09-27
US11/529,560 US8607301B2 (en) 2006-09-27 2006-09-27 Deploying group VPNS and security groups over an end-to-end enterprise network
US11/656,077 US8284943B2 (en) 2006-09-27 2007-01-22 IP encryption over resilient BGP/MPLS IP VPN
US11/656,077 2007-01-22

Publications (3)

Publication Number Publication Date
WO2008039506A2 true WO2008039506A2 (fr) 2008-04-03
WO2008039506A3 WO2008039506A3 (fr) 2008-08-28
WO2008039506B1 WO2008039506B1 (fr) 2008-10-16

Family

ID=39230822

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2007/020811 Ceased WO2008039506A2 (fr) 2006-09-27 2007-09-27 Deploiement de reseaux prives virtuels de groupe et de groupes de securite sur un reseau d'entreprise de bout en bout et cryptage ip pour rpv

Country Status (1)

Country Link
WO (1) WO2008039506A2 (fr)

Cited By (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102792307A (zh) * 2010-03-15 2012-11-21 赛门铁克公司 在虚拟环境中提供网络访问控制的系统和方法
WO2014150567A1 (fr) * 2013-03-15 2014-09-25 Asguard Networks, Inc. Sécurité de réseau industriel
WO2015084878A1 (fr) * 2013-12-02 2015-06-11 Akamai Technologies, Inc. Réseau privé virtuel (vpn) en tant que service, avec optimisations des remises et maintien de la sécurité des données de bout en bout
US9300635B1 (en) 2015-06-15 2016-03-29 Tempered Networks, Inc. Overlay network with position independent insertion and tap points
CN106230793A (zh) * 2016-07-22 2016-12-14 安徽皖通邮电股份有限公司 一种实现mplsvpn运行在加密的ipvpn之上的方法
JP2017028740A (ja) * 2012-03-30 2017-02-02 ホアウェイ・テクノロジーズ・カンパニー・リミテッド 盗聴に対するＩＰｓｅｃ通信のパフォーマンス及びセキュリティの向上
US9729581B1 (en) 2016-07-01 2017-08-08 Tempered Networks, Inc. Horizontal switch scalability via load balancing
US9729580B2 (en) 2014-07-30 2017-08-08 Tempered Networks, Inc. Performing actions via devices that establish a secure, private network
CN107086958A (zh) * 2016-02-16 2017-08-22 中国移动通信集团江苏有限公司 一种数据传输方法、wap网关及系统
US10069726B1 (en) 2018-03-16 2018-09-04 Tempered Networks, Inc. Overlay network identity-based relay
US10116539B1 (en) 2018-05-23 2018-10-30 Tempered Networks, Inc. Multi-link network gateway with monitoring and dynamic failover
US10158545B1 (en) 2018-05-31 2018-12-18 Tempered Networks, Inc. Monitoring overlay networks
US10911418B1 (en) 2020-06-26 2021-02-02 Tempered Networks, Inc. Port level policy isolation in overlay networks
US10999154B1 (en) 2020-10-23 2021-05-04 Tempered Networks, Inc. Relay node management for overlay networks
US11070594B1 (en) 2020-10-16 2021-07-20 Tempered Networks, Inc. Applying overlay network policy based on users
CN113676469A (zh) * 2021-08-17 2021-11-19 盐城工学院 一种企业网安全管理方法
CN115987660A (zh) * 2022-12-28 2023-04-18 北京天融信网络安全技术有限公司 Vpn设备通信方法、装置、设备及存储介质
WO2024001885A1 (fr) * 2022-06-29 2024-01-04 深圳市中兴微电子技术有限公司 Procédé de transmission de données, dispositif électronique et support d'enregistrement informatique

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4225681B2 (ja) * 2000-12-06 2009-02-18 富士通株式会社 仮想閉域網構築方法及び装置並びに中継装置
JP4394590B2 (ja) * 2005-02-22 2010-01-06 株式会社日立コミュニケーションテクノロジー パケット中継装置および通信帯域制御方法
US7724732B2 (en) * 2005-03-04 2010-05-25 Cisco Technology, Inc. Secure multipoint internet protocol virtual private networks

Cited By (37)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102792307A (zh) * 2010-03-15 2012-11-21 赛门铁克公司 在虚拟环境中提供网络访问控制的系统和方法
CN102792307B (zh) * 2010-03-15 2015-09-02 赛门铁克公司 在虚拟环境中提供网络访问控制的系统和方法
JP2017028740A (ja) * 2012-03-30 2017-02-02 ホアウェイ・テクノロジーズ・カンパニー・リミテッド 盗聴に対するＩＰｓｅｃ通信のパフォーマンス及びセキュリティの向上
WO2014150567A1 (fr) * 2013-03-15 2014-09-25 Asguard Networks, Inc. Sécurité de réseau industriel
US9344403B2 (en) 2013-03-15 2016-05-17 Tempered Networks, Inc. Industrial network security
US10038725B2 (en) 2013-03-15 2018-07-31 Tempered Networks, Inc. Industrial network security
WO2015084878A1 (fr) * 2013-12-02 2015-06-11 Akamai Technologies, Inc. Réseau privé virtuel (vpn) en tant que service, avec optimisations des remises et maintien de la sécurité des données de bout en bout
US10270809B2 (en) 2013-12-02 2019-04-23 Akamai Technologies, Inc. Virtual private network (VPN)-as-a-service with delivery optimizations while maintaining end-to-end data security
US9729580B2 (en) 2014-07-30 2017-08-08 Tempered Networks, Inc. Performing actions via devices that establish a secure, private network
US10178133B2 (en) 2014-07-30 2019-01-08 Tempered Networks, Inc. Performing actions via devices that establish a secure, private network
US9621514B2 (en) 2015-06-15 2017-04-11 Tempered Networks, Inc. Overlay network with position independent insertion and tap points
US9300635B1 (en) 2015-06-15 2016-03-29 Tempered Networks, Inc. Overlay network with position independent insertion and tap points
CN107086958B (zh) * 2016-02-16 2020-02-18 中国移动通信集团江苏有限公司 一种数据传输方法、wap网关及系统
CN107086958A (zh) * 2016-02-16 2017-08-22 中国移动通信集团江苏有限公司 一种数据传输方法、wap网关及系统
US9729581B1 (en) 2016-07-01 2017-08-08 Tempered Networks, Inc. Horizontal switch scalability via load balancing
US10326799B2 (en) 2016-07-01 2019-06-18 Tempered Networks, Inc. Reel/Frame: 043222/0041 Horizontal switch scalability via load balancing
CN106230793A (zh) * 2016-07-22 2016-12-14 安徽皖通邮电股份有限公司 一种实现mplsvpn运行在加密的ipvpn之上的方法
US10200281B1 (en) 2018-03-16 2019-02-05 Tempered Networks, Inc. Overlay network identity-based relay
US10069726B1 (en) 2018-03-16 2018-09-04 Tempered Networks, Inc. Overlay network identity-based relay
US10797993B2 (en) 2018-03-16 2020-10-06 Tempered Networks, Inc. Overlay network identity-based relay
US10116539B1 (en) 2018-05-23 2018-10-30 Tempered Networks, Inc. Multi-link network gateway with monitoring and dynamic failover
US10797979B2 (en) 2018-05-23 2020-10-06 Tempered Networks, Inc. Multi-link network gateway with monitoring and dynamic failover
US11509559B2 (en) 2018-05-31 2022-11-22 Tempered Networks, Inc. Monitoring overlay networks
US10158545B1 (en) 2018-05-31 2018-12-18 Tempered Networks, Inc. Monitoring overlay networks
US11582129B2 (en) 2018-05-31 2023-02-14 Tempered Networks, Inc. Monitoring overlay networks
US11729152B2 (en) 2020-06-26 2023-08-15 Tempered Networks, Inc. Port level policy isolation in overlay networks
US10911418B1 (en) 2020-06-26 2021-02-02 Tempered Networks, Inc. Port level policy isolation in overlay networks
US12095743B2 (en) 2020-06-26 2024-09-17 Tyco Fire & Security Gmbh Port level policy isolation in overlay networks
US11070594B1 (en) 2020-10-16 2021-07-20 Tempered Networks, Inc. Applying overlay network policy based on users
US11824901B2 (en) 2020-10-16 2023-11-21 Tempered Networks, Inc. Applying overlay network policy based on users
US12407738B2 (en) 2020-10-16 2025-09-02 Tyco Fire & Security Gmbh Applying overlay network policy based on users
US10999154B1 (en) 2020-10-23 2021-05-04 Tempered Networks, Inc. Relay node management for overlay networks
US11831514B2 (en) 2020-10-23 2023-11-28 Tempered Networks, Inc. Relay node management for overlay networks
US12224912B2 (en) 2020-10-23 2025-02-11 Tyco Fire & Security Gmbh Relay node management for overlay networks
CN113676469A (zh) * 2021-08-17 2021-11-19 盐城工学院 一种企业网安全管理方法
WO2024001885A1 (fr) * 2022-06-29 2024-01-04 深圳市中兴微电子技术有限公司 Procédé de transmission de données, dispositif électronique et support d'enregistrement informatique
CN115987660A (zh) * 2022-12-28 2023-04-18 北京天融信网络安全技术有限公司 Vpn设备通信方法、装置、设备及存储介质

Also Published As

Publication number Publication date
WO2008039506A3 (fr) 2008-08-28
WO2008039506B1 (fr) 2008-10-16

Similar Documents

Publication Publication Date Title
US8284943B2 (en) IP encryption over resilient BGP/MPLS IP VPN
US8607301B2 (en) Deploying group VPNS and security groups over an end-to-end enterprise network
WO2008039506A2 (fr) Deploiement de reseaux prives virtuels de groupe et de groupes de securite sur un reseau d'entreprise de bout en bout et cryptage ip pour rpv
EP1657880B1 (fr) Croisements des réseaux privés virtuels basés sur des certificats
US7864762B2 (en) Ethernet encryption over resilient virtual private LAN services
Touch Dynamic Internet overlay deployment and management using the X-Bone
US9258282B2 (en) Simplified mechanism for multi-tenant encrypted virtual networks
Kompella et al. Virtual private LAN service (VPLS) using BGP for auto-discovery and signaling
US7373660B1 (en) Methods and apparatus to distribute policy information
US20040093492A1 (en) Virtual private network management with certificates
WO2008042318A2 (fr) Systèmes et procédés destinés à la gestion de réseaux sécurisés à l'aide de clés distribuées
Carthern et al. Advanced Routing
US12375463B2 (en) Internet protocol security and security parameter index summarization and data routing
Hills et al. IP virtual private networks
Thiara Enterprise Based VPN
Vitalii et al. MPLS VPN TECHNOLOGY
US20080082822A1 (en) Encrypting/decrypting units having symmetric keys and methods of using same
Hoogendoorn NSX-T VPN
WO2024156013A2 (fr) Ingénierie de trafic sd-wan
Sami DATA COMMUNICATION SECURITY AND VPN INSTALLATION: BANGLADESH PERSPECTIVES
Kompella et al. RFC 4761: Virtual Private LAN Service (VPLS) using BGP for auto-discovery and signaling
Singh et al. DIFFERENT SECURITY MECHANISMS FOR DIFFERENT TYPE OF SECURITY LAPSES IN WMN-A REVIEW
HK1088735A (en) Virtual private network crossovers based on certificates
HK1088740A (en) Virtual private network crossovers based on certificates
HK1088743A (en) Virtual private network crossovers based on certificates

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 07852436

Country of ref document: EP

Kind code of ref document: A2

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 07852436

Country of ref document: EP

Kind code of ref document: A2