Internet Engineering Task Force Jieyun (Jessica) Yu
INTERNET DRAFT Lianghwa Jou
Expires in January, 2001 Abbie Matthews
Vijay Srinivasan
CoSine Communications
July, 2000
Criteria for Evaluating VPN Implementation Mechanisms
draft-yu-vpn-criteria-00.txt
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
A variety of mechanisms for implementing Virtual Private Network
(VPN) utilizing public IP network infrastructure have been proposed
in [1,2,3,4] and more may be emerging. This document attempts to
identify a set of criteria for evaluating such mechanisms. The
criteria could be used by IETF for evaluating a VPN proposal before
advancing it to standard track or by VPN Service Providers or
enterprise network administrators for choosing which mechanism to use
in order to implement their desired VPN networks. The mechanisms this
criteria addresses are exclusively for implementing IP based VPNs, as
oppose to non-IP based ones, such as Frame Relay based VPNs, etc.
1. Introduction
Yu, et al. [Page 1]
Internet Draft draft-yu-vpn-criteria-00.txt July, 2000
A Virtual Private Network (VPN), in general, can be described as an
emulated private communication infrastructure utilizing shared
communication facilities. It is usually built by utilizing public
Internet infrastructure or ISP backbone network. VPN is a cost-
effective alternative for enterprises conducting internal private
communications involving geographically diverse sites.
A variety of mechanisms for implementing VPN utilizing public IP
network infrastructure have been proposed [1,2,3,4] and more may be
emerging. This document attempts to identify a set of criteria for
evaluating such mechanisms. The criteria could be used by IETF for
evaluating a VPN proposal before advancing it to standard track or by
VPN Service Providers or enterprise network administrators for
choosing which mechanism to use in order to implement their desired
VPN networks.
It is worthy noting that the mechanisms this set of criteria
addresses are exclusively for implementing IP based VPNs as oppose to
non-IP based ones, such as Frame Relay or ATM based VPNs.
2. Basic Criteria
The very basic criteria of VPN are virtual and private. By Virtual,
we mean, the network has no correspondent physical network, rather is
an emulated infrastructure utilizing underlying public network
infrastructure. By Private, we mean, access to such network is
restricted only to a defined set of entities and the data transmitted
across the VPN should not be read by outside of the network.
In order to be characterized as a VPN implementation mechanism, a
mechanism must provide a means of implementing VPNs with these two
basic characteristics.
3. Other Criteria for Evaluating VPN Implementation Mechanisms
The basic components of a VPN implementation mechanism should include
mechanisms for a) membership identification, verification and
dissemination; b) Intra-VPN routing and routing interaction between
VPN and its underlying network(s); and c) forwarding. With these
basic components in mind, a VPN implementation mechanism can be
evaluated, in general, with the following aspects:
o Security
o Architecture
o Manageability
o Scalability
o Feature support
Yu, et al. [Page 2]
Internet Draft draft-yu-vpn-criteria-00.txt July, 2000
It is worthy noting that with security criteria, different degree of
requirement may vary with respect to different VPNs. For example,
while it is an absolute requirement for some VPNs to encrypt data
transmitted over the VPN, it may not be top consideration for others.
Therefore, specific requirement of a particular VPN should be taken
into consideration when such evaluation is taking place.
3.1. Security
A VPN implementation mechanism should provide means for data security
and network security.
3.1.1. Data Security
Data security includes data integrity, data confidentiality and data
origin authentication.
o Data integrity
One of the security concerns is that data could be altered or
tampered while transmitted across the Internet. A VPN mechanism needs
to provide mechanisms to ensure the integrity of data exchanged
within the VPN.
o Data confidentiality
A VPN mechanism should provide means for ensuring that no
unauthorized party reading or copy the VPN private data while
transmitting across the underlying public network. An example of such
mechanism is data encryption.
o Data origin authentication
A VPN mechanism should provide ways for authenticate the origin of
data to ensure that the source of the data is what it claims to be.
3.1.2. VPN Network Security
VPN network security provides the ability to guarantee that only
approved recipients receive the VPN's routing information and data.
o Site authorization and authentication
A VPN will suffer from undesirable security consequences when an
unauthorized site becomes part of the VPN network. To ensure a secure
VPN network, a VPN implementation mechanism should provide means of
establishing connections only with the authorized entities (sites) in
the initial VPN construction process as well as in the
Yu, et al. [Page 3]
Internet Draft draft-yu-vpn-criteria-00.txt July, 2000
reconfiguration process. To achieve the goal, a form of site
authentication prior to establishment of the connection is required
and should be provided.
o Access control
Access control involves policy of who can access the VPN network.
Access control mechanism should be provided by a VPN implementation
mechanism to restrict access thus to protect the privacy of the VPN
network.
o Routing Security
The goal of achieving routing security in a VPN is to prevent routers
of a VPN from interaction with unauthorized entities, to prevent
routes to VPN destinations from leaking to undesired entities, and to
avoid introducing undesired routing information to taint the VPN
routing information base.
o VPN Isolation
Certain VPN implementation mechanism provides capability of
supporting multiple VPNs utilizing the same set of devices (e.g. Edge
routers of a provider network.) Mechanisms, such as separate
forwarding table for each VPN on the device, must be provided to
prevent unintended traffic from one VPN entering another to ensure
privacy and security of the VPNs.
3.2. Architecture
3.2.1. Flexible Topology
A set of virtual links between sites belong to a VPN constitutes the
topology of the VPN network. A virtual link can be realized via the
construction of a tunnel such as IPsec VPN mechanism [2] or via
establishing direct routes as with BGP4/MPLS VPN mechanism [1].
Based on its requirement, an enterprise may desire the topology of
its VPN network as full-mesh, partial-mesh or hub-and-spoken. A VPN
implementation mechanism should be flexible to allow constructing VPN
topology based on the requirement accordingly.
3.2.2. Hierarchy
Different architecture may result in different scalability of its
correspondent VPN. For example, provider network-based VPN
architecture allows a provider edge router to connect many customer
premises equipment (CPE) routers in a region. The topology mesh will
Yu, et al. [Page 4]
Internet Draft draft-yu-vpn-criteria-00.txt July, 2000
be built among the Provider Edge routers. This architecture scales
better than CPE based VPN where the tunnel meshes are formed among
the CPE routers which has a lot more in numbers for large VPNs. In
addition, by introducing this hierarchy, configuration and management
complexity will be moved to a smaller set of Provider Edge routers
rather than large amount of CPE devices.
Therefore, it is desirable for a VPN implementation mechanism to
provide means for building VPN with hierarchy.
3.2.3. Independency
Although a VPN is a virtual infrastructure built on top of public
network infrastructure, maintaining as much independence from its
underlying network infrastructure as possible yields many advantages.
The advantages include fault isolation and operation transparency,
which would improve the stability of both VPN network as well as the
underlying network(s).
3.2.3.1. Backbone Technology Independence
An enterprise VPN network may span across multiple ISP network
domains. Two VPNs with different ISP network as underlying
infrastructure may need to merge into one VPN due to event such as
corporate merge. To facilitate the interconnection, it is desirable
that a VPN implementation mechanism be independent of underlying
network or backbone technology. It should avoid assuming or requiring
ISPs running certain protocols other than IP protocol.
For those VPNs that only cross one ISP network (which is the most
cases in today's implementation), this criterion is of less concern.
3.2.3.2. Addressing Independence
A VPN mechanism should not require the binding of IP address space of
the VPN to its underlying IP network. In another word, the IP
addresses assigned within a VPN network should be independent of that
assigned in its underlying IP network/backbone.
By assigning separate IP address space from its underlying network, a
VPN administrator is able to manage IP address within the VPN
independently since he/she is able to add, change and remove IP
addresses without coordinating with the administrator of the
underlying IP network.
By not tying VPN's IP address space with a particular underlying
network, the VPN can migrate to other underlying IP network without
changing the IP address, making such migration easier.
Yu, et al. [Page 5]
Internet Draft draft-yu-vpn-criteria-00.txt July, 2000
By using independent IP address space from its underlying network, a
VPN is able to use private IP address space. Using private IP address
space helps conserving scarce IPv4 address space.
It also makes it feasible for the use of overlapping IP address space
for VPNs that do not have common sites. This again will make the use
of private IP address space feasible.
3.2.3.3. Routing Independence
Overall, routing of a VPN can be viewed as composed of two parts: a)
obtaining routing knowledge to reach the private destinations
(prefixes reachable within the VPN.) and b) obtaining routing
information to VPN sites reachable via the underlying public network.
While for b), VPN routers have to participant the routing of the
underlying network, for a) they do not have to. That is, routing
technology used for reachability within a VPN can be completely
independent from that of the underlying network.
Having an independent routing system will enhance VPN network
security and minimize unnecessary outages due to routing instability
in the underlying network and vice versa. Routing associated outages
or instability in the VPN layer, caused by for example misbehaving
routing software or mis-configurations, will not impact the routing
and/or the stability in its underlying network. In addition, VPN
prefixes will not need to be advertised to the underlying public
network's routing table, which enhances the security of the VPN. Not
leaking VPN prefixes in the underlying network also reduces routes in
the underlying network, hence improving routing scalability of the
underlying provider network.
A VPN implementation mechanism should allow as much independent
routing of VPN from its underlying network as possible. Mechanism
should be provided to avoid the propagation of internal prefixes of a
VPN to its underlying network(s).
3.2.4. Extendibility
A VPN mechanism should allow easy extension of the VPNs while still
maintain the same level of privacy and security.
3.2.4.1. Extend to multiple provider's domains
Extending a VPN to different provider's domains requires that the VPN
mechanism assuming no uniform technology of the underlying network
infrastructure. The only common technology can be assumed is IP in
the underlying networks
Yu, et al. [Page 6]
Internet Draft draft-yu-vpn-criteria-00.txt July, 2000
3.2.4.2. Extend to Remote Dialup Users
Remote access or dialup is an essential part of enterprise networks
which usually adopting VPN solution for its Intranet. Therefore, a
VPN implementation mechanism should support this functionality.
3.2.4.3. Interconnection VPNs
There are many reasons why VPNs would need to be interconnected. For
example, the merge of two corporate would create a need for such
interconnection. A VPN implementation mechanism should make such
interconnection possible. It is also desirable that same mechanism
can be used for both inter-VPN and intra-VPN connection to avoid
introducing complexity in operation and management.
3.2.5. Redundancy
A VPN implementation mechanism should avoid relying on a central
system for operations such as routing or management. Such system will
introduce single point of failure, performance bottleneck and/or
capacity bottleneck such as routing table capacity.
3.2.6. Operation Transparency
Even though a VPN utilizes the underlying network for its
communication, logically, the two are separate networks. A VPN
implementation mechanism should help minimize the dependence and
interference between the two networks to optimize the performance.
Due to this reason, operation transparency of VPN from underlying
network is extremely desirable. Maximize the independency of a VPN
from its underlying network as described in section 3.2.3 is a key to
achieve operation transparency.
Operation transparency includes the following aspects:
o Technology change to either network will make the least impact on
the other
o VPN network administrators should be able to configure or
reconfigure the VPN without involving the administrators of the
underlying network
A category of VPN service model involves the administrator of the
underlying network also operate the VPN to which it provides service
due to service outsourcing arrangement. The above requirement may be
adjusted accordingly.
3.3. Manageability
Yu, et al. [Page 7]
Internet Draft draft-yu-vpn-criteria-00.txt July, 2000
The management of a VPN typically involves membership, policy and
security management. Reducing management complexity and manual
configuration will reduce network outages due to misconfiguration and
mismanagement. It is, therefore, desirable that VPN implementation
mechanisms facilitate the manageability of VPNs. We will exam the
management issues in the following aspects:
3.3.1. Membership Management
The key of building a VPN is to identify and disseminate members
belong to the VPN so connections can be established among the members
to form a virtual private communication network or reconstruction of
a VPN after its establishment. This information will have to be
configured or distributed to the VPN routers. It can be achieved by
manually configured all related information on the routers, install
all such information in a central repository and distributed to VPN
routers in a automated fashion, or propagate such information via
piggybacking in routing protocols as discussed in [2].
Regardless of what method chosen, it should keep manual management of
such information to the minimum, both in terms of establishment of
VPN or maintenance of VPN in terms of adding or deleting sites in a
VPN.
3.3.2. Access Management
Due to the private nature of VPNs in general, access of the networks
needs to be restricted and controlled. Access policies need to be
configured to the routers and in addition, need to be properly
maintained. Again, it's desirable that a VPN implementation requires
minimum manual management of policy information.
3.3.3. Key Management
For those VPNs with strong requirement of security and privacy,
security keys are used for the purpose of authentication and
encryption. Therefore, key management becomes an essential part of
the VPN management. Key management involves creation, exchange and
maintenance of keys. VPN implementation should select mechanisms
which meets the security requirement but also manageable.
3.3.4. Management Boundaries
Being able to identify problem quickly will no doubt enhance the
availability of a network. It can be critical to enterprises rely on
VPN for mission critical tasks. It is desirable that administrative
and management boundaries can be clearly defined. Building a VPN as
much independent as possible to its underlying network(s) as
Yu, et al. [Page 8]
Internet Draft draft-yu-vpn-criteria-00.txt July, 2000
described in section 3.2.3. Will help achieving the goal.
3.4. Scalability
A VPN can grow as large as to include hundreds of sites. Thus VPN
implementation mechanism should be able to scalable to build such a
large VPN network. This requires that the complexity of setup,
operation and management associated with a VPN does not increase
dramatically with the size of the VPN (e.g. number of VPN sites)
built with the mechanism.
3.4.1. Architecture Scalability
Different architecture would have immense impact on the scalability
of the VPN networks. For example, provider network based VPN
architecture scales much better than CPE based VPN architecture due
to the introduction of hierarchy thus removing the complexity of
configuration and management on large number of routers involved as
pointed out in section 3.2.2. in this document.
Allowing same set of devices (such as provider's Edge routers) to
support multiple VPNs is a scalable means for a VPN Service Provider
to provider large number of VPNs in its network.
When evaluating a VPN implementation mechanism, one need to consider
if the mechanism allows the implementation of VPN with architectures
that are more scalable.
3.4.2. Management Scalability
The key to a scalable VPN management is to minimize the manual tasks
in terms of configuration and maintenance of membership information
and policy information. A VPN implementation mechanism should provide
means of reducing manual tasks to minimum.
3.4.3. Routing Scalability
A large VPN network would have the same routing complexity than that
of a regular non-virtual network. Therefore, routing scalability
issues facing non-virtual large networks as described in [5] also
applies to routing in large VPN networks. A VPN implementation
mechanism should not be an obstacle for implementing scalable routing
in the VPNs.
It is desirable that VPN prefixes do not propagate to the public
network infrastructure, not only for security reason but also for
scalable routing table management reason. A VPN implementation
mechanism must not rely on public network routing system to carry
Yu, et al. [Page 9]
Internet Draft draft-yu-vpn-criteria-00.txt July, 2000
private VPN prefixes.
3.5. Feature Support
A VPN mechanism should not restrict VPN from supporting features
desired by an enterprise network. Examples of such features
including: QoS, Multicast and Multi-protocol support.
4. Conclusion
Aside from privacy and security, independence of a VPN from its
underlying network infrastructure is also a key criterion for
evaluating VPN mechanisms. In fact, when such independency is
achieved, it will improve the manageability of the VPN, which is also
a very important criterion.
5. Security Considerations
Security is an essential part of VPN implementation mechanisms.
Sections in this document are devoted to discussion of security
considerations.
6. References
[1] Rosen, et al, "BGP/MPLS VPNs", May 2000, Work in progress
[2] Gleeson, et al, "A Framework for IP Based Virtual Private
Networks", February 2000, RFC2764
[3] H. Ould-Brahim, B. Gleeson, "Network based IP VPN Architecture
Using Virtual Routers", March 2000, Work in progress
[4] K. Muthukrishnan, A., Malis, "A Core MPLS IP VPN Architecture",
May 2000, Work in progress
[5] J. Yu. "Scalable Routing Design Principles", Mar 2000, Work in
progress
7. Author Information
Jieyun (Jessica) Yu
CoSine Communications
jyy@cosinecom.com
Lianghwa Jou
CoSine Communications
ljou@cosinecom.com
Yu, et al. [Page 10]
Internet Draft draft-yu-vpn-criteria-00.txt July, 2000
Abbie Matthews
CoSine Communications
amatthews@cosinecom.com
Vijay Srinivasan
CoSine Communications
vsrinivasan@cosinecom.com
Yu, et al. [Page 11]