Internet DRAFT - draft-wang-cevpn-group
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-
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
