Internet DRAFT - draft-wang-cevpn-group


                                                                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-
   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 
   The list of Internet-Draft Shadow Directories can be accessed at 
   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 
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 
   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 
   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(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 
   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(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 
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 
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 
   "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 
   565 Metro Place South             Phone:  1-614-923-6241 
   Dublin, OH 43017, USA             Email: 
   Mark Beadles 
   565 Metro Place South             Phone:  1-614-923-5657 
   Dublin, OH 43017 USA              Email: