C. Wang Internet Draft M. Beadles Document: draft-wang-cevpn-group-00.txt SmartPipes Expires: April 2002 October 2001 VPN Group Support for CE-based IPsec VPN Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract IPsec tunneling provides a site-to-site connection when building a CE-based IPsec VPN. In a large scale VPN deployment, especially when a service provider manages a large number VPNs, there is a need to manage IPsec tunnels on a group basis, instead of on a tunnel basis. This document describes the definition of a VPN group, its attributes, and usage of VPN group when managing IPsec tunnels. By grouping IPsec tunnels and sites into an IPsec VPN group, service providers can design, provision, and manage the IPsec-based CE VPN at both group level and tunnel/site level. This gives service providers more flexibility and provides more aggregation capability to reduce operation complexity. Wang, Beadles Expires May 2002 [Page 1]
VPN Group Support for CE-based IPsec VPN November, 2001 1.0 Introduction CE-based IPsec VPN has been one of the options for service providers to build VPN services. IPsec VPN can achieve a high level of data security and dramatically reduce cost in comparison with private leased lines. When IPsec tunnels are used to build a large-scale network, it provides a point-to-point connection linking two sites. To build a large scale VPN, many site-to-site tunnels need to be established. The IPsec Working Group has defined the standards for building IPsec tunnels. Another IETF working group, IPsec Policy working Group, focuses on providing guidelines for the provisioning of IPsec policies, at the IPsec tunnel level. So far, at the tunnel level, the definition and configuration of an IPsec tunnel is well understood and documented. However, from a service providerÆs standpoint, there is still a lack of clear mechanism to handle a large number IPsec tunnels and to handle a large number of IPsec VPNs on a group basis. This draft introduces the concept and definition of VPN group. The VPN groupÆs attributes are identified. In addition, VPN group topology and VPN connectivity issues are also discussed. The concept of an IPsec VPN group can be used to design a large VPN network consisting of many IPsec tunnels. A large network is usually designed and implemented using a layered approach. By decomposing a complex VPN network into smaller and manageable VPN groups, a service provider can build more manageable VPN networks. The use of a VPN group also provides a logical group of IPsec tunnels. IPsec tunnels can be provisioned on a group basis. The IPsec tunnels in the same group are set to the same attributes. The capability of provisioning IPsec tunnels on a group basis improves a service providerÆs operation efficiency, and provides a better control for VPN management. 2.0 Definitions 2.1 Definition of an IPsec VPN Group A VPN group consists of both VPN links (IPsec tunnels) and VPN nodes (IPsec device). The IPsec tunnels provide site-to-site connections. 2.2 Definition of a VPN Link An IPsec VPN link is an IPsec tunnel linking two VPN nodes and the sites behind the nodes. A VPN groupÆs networking connection is Wang, Beadles Expires May 2002 [Page 2]
VPN Group Support for CE-based IPsec VPN November, 2001 provided by these VPN links. So effectively, a VPN group can be thought of as a connection tree covering a whole user network, while each member link is a branch in the tree. The sites that a VPN tunnel connects to are the leaves of the tree. A VPN tunnel can only belong to one VPN group. 2.3 Definition of a VPN Node An IPsec VPN node is a CE router, which terminates IPsec tunnels and provides site-to-site routing function. It is the gateway for its network behind it to connect to other sites. A VPN link connects two nodes of the group. Although a VPN link can only belongs to one VPN group, a VPN node can participate in more than one VPN groups. Two VPN groups may inter-connect with each other via a VPN node. Under such a scenario, the VPN node provides the inter-group connection. 3.0 Attributes 3.1 VPN Group A VPN group has two types of attributes: 1) common attributes that apply to each member; 2) attributes that only affect the group as a whole, such as the group topology. 3.1.1 Group Topology Group topology is an important attribute of a group. Possible topology of a VPN group includes hub-and-spoke, full mesh, and partial mesh. 3.1.2 Security Grade A VPN group can be assigned to different security grade. A particular grade may determine things such as encryption strength, authentication type, key lifetime, etc. The security grade should be used as the default value for each VPN link in the group. 3.1.3 Group Lifetime A VPN group may have a lifetime associated with it. A static group has an indefinite lifetime. When a VPN group reaches its lifetime, the group needs to be terminated or extended. 3.1.4 Routing Support Another important attribute is how the group supports site-to-site routing among its nodes. Possible choices include running dynamic routing protocols across the tunnels, or using managed route update. Wang, Beadles Expires May 2002 [Page 3]
VPN Group Support for CE-based IPsec VPN November, 2001 Static route may be an option but it has a severe scalability issues. 3.1.5 Group Connectivity It is also important to determine whether the VPN group is open or closed. A closed VPN group will not exchange packets with other VPN groups. An open VPN group can potentially open data path to other VPN groups. 3.2 VPN Link A VPN link belongs to one and only one VPN group. All VPN links of a VPN group should inherit the common group attributes, in terms of security grade and lifetime, etc. However, a VPN link should not use a group key. Instead individual tunnel key should be used. A VPN link may override its local tunnel lifetime and key refreshing policy. Since a VPN link can potentially set its own lifetime, it can be more dynamic than the whole group. In other words, a link can potentially join and leave a VPN group on a short-term basis. In this case the link can be classified as a dynamic link. On the contrary, a static link has the same lifetime with the whole group. 3.3 VPN Group Node A VPN node serves as the IPsec tunnel end point and the gateway for the site network behind it. One VPN node can participate in one or more VPN groups. Under that scenario, the VPN node also provides routing for inter-group connection. The VPN node is the target for SP provisioning and management. When a VPN node participates in more than one VPN group, it is important to provision each groupÆs attributes correctly. It is also required to make sure that provisioning for different VPN groups doesnÆt affect each other. 4.0 Topology 4.1 Group Topology Comparison A VPN group can take the topology of a full mesh, a partial mesh, or a hub-spoke to link sites together. Each topology has its own strength and weakness in supporting key requirements. The following sections provide a comparison of each topology. a) Redundancy Wang, Beadles Expires May 2002 [Page 4]
VPN Group Support for CE-based IPsec VPN November, 2001 From the network reach-ability point of view, all three topologies offer the same support. Usually network redundancy is required in addition to connectivity. Obviously, a full mesh VPN provides the best tunnel level redundancy. For a partial mesh network, a single node of failure may exist. For a hub-spoke VPN, the hub node can be the single point of failure. b) Packet Processing Cost Since IPsec requires extensive packet processing at both tunnel ends, to minimize the cost to the network resources, a packet should traverse as fewer IPsec tunnels as possible between its source and destination. From that aspect, a full mesh VPN provides the best efficiency, since every packet can reach its destination via one IPsec tunnel. For other topology such as a hub-spoke VPN, a packet may have to traverse more than one IPsec tunnel to reach its destination. If a packet has to traverse two tunnels, it costs twice as much IPsec processing to reach the destination. The extra tunneling doesnÆt increase any level of security. Instead it adds unnecessary operation cost and increases the network latency. c) Node Capacity An IPsec node needs to have enough capacity to process all IPsec packets, including both its own traffic (which originates from or destined to the local site) and the pass-through traffic. Obviously, a node with IPsec traffic aggregation requires more IPsec capacity. In the case of a full mesh network, no traffic aggregation happens. Every node only needs to process its own traffic. In the case of a hub-spoke network, the hub node aggregates every spokeÆs traffic together. The node needs to have capacity to process the aggregated traffic. d) Scalability When a VPN group contains many nodes, scalability must be considered. Usually the scalability is constrained by a VPN nodeÆs capability in two factors: the number of tunnels a device can support and the maximum IPsec bandwidth it can support. For a full mesh VPN group, if the number of sites is large, the total number of tunnels will be large. This may raise scalability issue since every CE device needs to support the same number of tunnels. On the contrary, for a hub-spoke VPN group, only the hub needs to support a large number of tunnels. The constraint is also true for the maximum IPsec bandwidth support. A hub-spoke VPN will require the hub to have a larger bandwidth while a full mesh VPN places equal bandwidth requirements to each participating CE device. 4.2 Complex Topology Decomposition A small and simple network can be designed and managed using just one VPN group, in the form of a full mesh, a partial mesh or a hub- and-spoke topology. However, a user network can be fairly large and complex. In this case, a layered approach can be followed to design Wang, Beadles Expires May 2002 [Page 5]
VPN Group Support for CE-based IPsec VPN November, 2001 and manage network using VPN group. A complex VPN network can be decomposed into separate VPN groups. Each VPN group can be managed on a group level. For example, a popular topology uses a combination of full mesh and hub-spoke. In Figure 1, the core full mesh network consists of nodes CE(A), CE(B), CE(C), and CE(D). Each node then connects to a separate hub-spoke topology. So all together the user network is decomposed into five VPN groups, with one full mesh and four hub- spoke sub-networks. The SP can take full advantage of this layered VPN group solution. Provisioning, management, and monitoring can be based on a group level. This provides a much better scalability, compared with managing tunnels on an individual basis. For example, IPsec tunnels in a VPN group can be assigned a set of common attributes on a group basis. In addition, by using the VPN group, SP can make changes to network topology quickly. Instead of dealing individual tunnels, a group provisioning can be applied. In Figure 1, to support redundancy to Region A CE routers, a new VPN group can be provisioned, where CE(B) serves the hub and CE(a1)/CE(a2)/CE(a3) are the spokes. In this way, each CE router in region A will have a redundant connection. Group A Group B CE(a1) CE(a2) CE(a3) CE(b1) CE(b2) CE(b3) \ | / \ | / \ | / \ | / \ | / \ | / CE(A)----------------------CE(B) | \ / | | \ / | | \ / | | \ / | | \/ | | / \ | | / \ | | / \ | | / \| CE(C)----------------------CE(D) / | \ / | \ / | \ / | \ / | \ / | \ CE(c1) CE(c2) CE(c3) CE(d1) CE(d2) CE(d3) Group C Group D Figure 1. This picture displays a complex hybrid network where a full mesh VPN group and four hub-spoke VPN groups provide the connection. As a second example, a hypothetical hierarchy network can be broken down into several VPN groups. The top-level VPN group is a hub-spoke VPN group where the spoke router also participates in another Wang, Beadles Expires May 2002 [Page 6]
VPN Group Support for CE-based IPsec VPN November, 2001 second-level hub-spoke VPN. Each second-level VPN group can be provisioned and managed independently. The top-level VPN group may affect the connection between second level VPN groups. CE(T) / | \ / | \ / | \ / | \ / | \ / | \ CE(A) CE(B) CE(C) / | \ / | \ / | \ / | \ / | \ / | \ / | \ / | \ / | \ / | \ / | \ / | \ CE(a1)CE(a2)CE(a3) / | \ CE(c1) CE(c2) CE(c3) Group A / | \ Group C CE(b1) CE(b2) CE(b3) Group B Figure 2. This picture displays a hierarchy network where a top- level hub-spoke VPN group connects to three second-level hub-spoke VPN groups. 5.0 Connectivity Two levels of connectivity need to be supported: 1) within-group site-to-site connectivity and 2) inter-group site-to-site connectivity. Both within-group connectivity and inter-group connectivity are supported by tunneling and routing. This draft only specifies the connectivity requirement. The connectivity support by routing protocols is outside the scope of this draft. 5.1 Within-Group Connectivity Within a VPN group, site-to-site connection needs to be provided. This is usually arranged by tunneling and routing. Depends on the group topology, routing requirement may be different. For a full mesh VPN group, every node in the full mesh needs to be able to directly reach every other participating node and its connected site. For a hub-spoke topology, usually the spoke router selects the hub router as the default gateway and hub router provides inter- spoke connection. The within-group connectivity needs to reflect the VPN group membership changes. A VPN group can range from being static where the topology stays the same for a long time to being more dynamic Wang, Beadles Expires May 2002 [Page 7]
VPN Group Support for CE-based IPsec VPN November, 2001 when the VPN nodes can join and leave the group. The VPN group change such as a new member addition must result in network reach- ability update. Although by default sites within a group should be able to reach each other, a network operator can also impose route restrictions to prevent a particular site to reach certain other sites. This restriction should be handled at a case level. The default action should be universal reach-ability within a group. 5.2 Inter-group Connectivity 5.2.1 Relation between Two VPN Groups. The relation between two VPN groups can be classified as connected or disconnected. If two VPN groupsÆ member can reach each other, they are classified as connected. For example, in Figure 2, if we allow each member in Group A to reach every member of group B, then VPN Group A and Group B are connected. By definition, two VPN groups are not connected if a member of one group canÆt reach a member of a different group. It is quite possible for one VPN group to be separated from other VPN groups. For example, in an extra-net scenario, a supplier VPN is usually separated from the corporate VPNs. 5.2.2 Connectivity Support The relation between two groups discussed in the previous section is mapped to the underlying network connectivity between VPN groups. When a VPN group is first created, its relation with the rest of the VPN groups must first be determined. Based on this relationship, network operator can set up the proper connectivity. Two VPN groups become connected if inter-group site-to-site routing is enabled. On the contrary, two VPN groups are dis-connected if there is no route between a site from one group and a site from the second group. Each group can be considered as a routing sub-domain. At the group boundary, route aggregation as well as route filtering can be performed. 6.0 Security Issues 6.1 Tunnel Key Provisioning Wang, Beadles Expires May 2002 [Page 8]
VPN Group Support for CE-based IPsec VPN November, 2001 Although IPsec tunnels can be managed on a group basis, the key for each tunnel should be managed individually for security reasons. Using a group key for a VPN group may significantly weaken the security that IPsec standards can provide. 6.2 End-to-End Packet Security When a cross group connection is made, a packet has to traverse several VPN group links. It is possible that VPN groups may offer a much different level of security. In addition, there may exist multiple paths to the same destination, In that case, the end-to-end security is limited by the weakest link of the full path. It is important to make sure that the end-to-end security requirement is met when an end-to-end traffic may traverse different VPN groups and when multiple paths exist between the two ends. 7. Summary for Sub-IP Area 7.1 Summary The PPVPN WG currently supports three types of VPNs: Provider Provisioned Network Based Layer 3 VPNs, Provider Provisioned Layer 2 VPNs and Provider Provisioned CE-based VPNs. This draft discusses using VPN groups to design, provision, and manage CE-based IPsec VPN. 7.2 Where does it fit in the Picture of the Sub-IP Work This work fits squarely in the PPVPN box. 7.3 Why is it Targeted at this WG This draft describes definition of a VPN group, its attributes, and usage of VPN group when managing IPsec tunnels for CE-based IPsec- based VPNs. Under the current PPVPN WG charter, Provider Provisioned CE-based VPNs fits the scope of the WG, as stated from the following charter extract: "This working group is responsible for defining and specifying a limited number of sets of solutions for supporting provider- provisioned virtual private networks (PPVPNs). The work effort will include the development of a framework document, a service requirements document and several individual technical approach documents that group technologies together to specify specific VPN service offerings. The framework will define the common components and pieces that are needed to build and deploy a PPVPN. Deployment scenarios will include provider-managed VPN components located on customer premises." Wang, Beadles Expires May 2002 [Page 9]
VPN Group Support for CE-based IPsec VPN November, 2001 7.4 Justification This draft is justified since it introduces the concept and usage of VPN group, which aims to enhance the provisioning and management of CE-based VPNs identified as a specific type of PPVPNs both in the WG charter and the general framework I-D. CE-based VPN has its own characteristics and operation requirements, among which ease of management and provisioning is one. 8. Reference [FRAMEWORK] Callon, R. et al., A Framework for Provider Provisioned Virtual Private Networks, draft-ietf-ppvpn-framework-00.txt, Work in progress [CEFRAMEWORK] Jeremy De Clercq, Olivier Paridaens, Mahadevan Iyer, Andrew Krywaniuk , A Framework for Provider Provisioned CE-based Virtual Private Networks using IPsec, draft-ietf-ppvpn-ce-based-00.txt, Work in progress Author's Addresses Cliff Wang SmartPipes 565 Metro Place South Phone: 1-614-923-6241 Dublin, OH 43017, USA Email: cwang@smartpipes.com Mark Beadles SmartPipes 565 Metro Place South Phone: 1-614-923-5657 Dublin, OH 43017 USA Email: mbeadles@smartpipes.com