Request for Comments: 3809 Juniper Networks
Category: Informational June 2004
Generic Requirements for Provider Provisioned
Virtual Private Networks (PPVPN)
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This document describes generic requirements for Provider Provisioned
Virtual Private Networks (PPVPN). The requirements are categorized
into service requirements, provider requirements and engineering
requirements. These requirements are not specific to any particular
type of PPVPN technology, but rather apply to all PPVPN technologies.
All PPVPN technologies are expected to meet the umbrella set of
requirements described in this document.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3
1.2. Deployment Scenarios. . . . . . . . . . . . . . . . . . . 4
1.3. Outline of this document. . . . . . . . . . . . . . . . . 5
2. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 6
3. Definitions and Taxonomy . . . . . . . . . . . . . . . . . . . 7
4. Service Requirements . . . . . . . . . . . . . . . . . . . . . 7
4.1. Availability . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Stability . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3. Traffic types . . . . . . . . . . . . . . . . . . . . . . 8
4.4. Data Isolation. . . . . . . . . . . . . . . . . . . . . . 9
4.5. Security . . . . . . . . . . . . . . . . . . . . . . . . 9
4.5.1. User data security . . . . . . . . . . . . . . . . 10
4.5.2. Access Control . . . . . . . . . . . . . . . . . . 10
4.5.3. Site authentication and authorization. . . . . . . 10
4.5.4. Inter domain security. . . . . . . . . . . . . . . 10
4.6. Topology . . . . . . . . . . . . . . . . . . . . . . . . 11
4.7. Addressing. . . . . . . . . . . . . . . . . . . . . . . . 11
4.8. Quality of Service . . . . . . . . . . . . . . . . . . . 11
4.9. Service Level Agreement and Service Level Specification
Monitoring and Reporting. . . . . . . . . . . . . . . . . 13
4.10.Network Resource Partitioning and Sharing between VPNs. . 14
5. Provider requirements. . . . . . . . . . . . . . . . . . . . . 14
5.1. Scalability . . . . . . . . . . . . . . . . . . . . . . . 14
5.1.1. Service Provider Capacity Sizing Projections . . . 15
5.1.2. VPN Scalability aspects. . . . . . . . . . . . . . 15
5.1.3. Solution-Specific Metrics. . . . . . . . . . . . . 17
5.2. Management . . . . . . . . . . . . . . . . . . . . . . . 18
5.2.1. Customer Management of a VPN . . . . . . . . . . . 18
6. Engineering requirements . . . . . . . . . . . . . . . . . . . 19
6.1. Forwarding plane requirements . . . . . . . . . . . . . . 19
6.2. Control plane requirements. . . . . . . . . . . . . . . . 20
6.3. Control Plane Containment . . . . . . . . . . . . . . . . 20
6.4. Requirements related to commonality of PPVPN mechanisms
with each other and with generic Internet mechanisms. . . 21
6.5. Interoperability . . . . . . . . . . . . . . . . . . . . 21
7. Security Considerations. . . . . . . . . . . . . . . . . . . . 22
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.1. Normative References. . . . . . . . . . . . . . . . . . . 23
8.2. Informative References. . . . . . . . . . . . . . . . . . 23
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
10. Editor’s Address . . . . . . . . . . . . . . . . . . . . . . . 24
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 25
1. Introduction
This document is an output of the design team formed to develop
requirements for PPVPNs in the Provider Provisioned Virtual Private
Networks (PPVPN) working group and provides requirements that are
generic to both Layer 2 Virtual Private Networks (L2VPN) and Layer 3
Virtual Private Networks (L3VPN). This document discusses generic
PPVPN requirements categorized as service, provider and engineering
requirements. These are independent of any particular type of PPVPN
technology. In other words, all PPVPN technologies are expected to
meet the umbrella set of requirements described in this document.
PPVPNs may be constructed across single or multiple provider networks
and/or Autonomous Systems (ASes). In most cases the generic
requirements described in this document are independent of the
deployment scenario. However, specific requirements that differ
based on whether the PPVPN is deployed across single or multiple
providers (and/or ASes) will be pointed out in the document.
Specific requirements related to Layer 3 PPVPNs are described in
[L3REQTS]. Similarly, requirements that are specific to layer 2
PPVPNs are described in [L2REQTS].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
1.1. Problem Statement
Corporations and other organizations have become increasingly
dependent on their networks for telecommunications and data
communication. The data communication networks were originally built
as Local Area Networks (LAN). Over time the possibility to
interconnect the networks on different sites has become more and more
important. The connectivity for corporate networks has been supplied
by service providers, mainly as Frame Relay (FR) or Asynchronous
Transfer Mode (ATM) connections, and more recently as Ethernet and
IP-based tunnels. This type of network, interconnecting a number of
sites over a shared network infrastructure is called Virtual Private
Network (VPN). If the sites belong to the same organization, the VPN
is called an Intranet. If the sites belong to different
organizations that share a common interest, the VPN is called an
Extranet.
Customers are looking for service providers to deliver data and
telecom connectivity over one or more shared networks, with service
level assurances in the form of security, QoS and other parameters.
In order to provide isolation between the traffic belonging to
different customers, mechanisms such as Layer 2 connections or Layer
2/3 tunnels are necessary. When the shared infrastructure is an IP
network, the tunneling technologies that are typically used are
IPsec, MPLS, L2TP, GRE, IP-in-IP etc.
Traditional Internet VPNs have been based on IPsec to provide
security over the Internet. Service providers are now beginning to
deploy enhanced VPN services that provide features such as service
differentiation, traffic management, Layer 2 and Layer 3
connectivity, etc. in addition to security. Newer tunneling
mechanisms have certain features that allow the service providers to
provide these enhanced VPN services.
The VPN solutions we define now MUST be able to accommodate the
traditional types of VPNs as well as the enhanced services now being
deployed. They need to be able to run in a single service provider’s
network, as well as between a set of service providers and across the
Internet. In doing so the VPNs SHOULD NOT be allowed to violate
basic Internet design principles or overload the Internet core
routers or accelerate the growths of the Internet routing tables.
Specifically, Internet core routers SHALL NOT be required to maintain
VPN-related information, regardless of whether the Internet routing
protocols are used to distribute this information or not. In order
to achieve this, the mechanisms used to develop various PPVPN
solutions SHALL be as common as possible with generic Internet
infrastructure mechanisms like discovery, signaling, routing and
management. At the same time, existing Internet infrastructure
mechanisms SHALL NOT be overloaded.
Another generic requirement from a standardization perspective is to
limit the number of different solution approaches. For example, for
service providers that need to support multiple types of VPN
services, it may be undesirable to require a completely different
solution approach for each type of VPN service.
1.2. Deployment Scenarios
There are three different deployment scenarios that need to be
considered for PPVPN services:
1. Single-provider, single-AS: This is the least complex scenario,
where the PPVPN service is offered across a single service
provider network spanning a single Autonomous System.
2. Single-provider, multi-AS: In this scenario, a single provider may
have multiple Autonomous Systems (for e.g., a global Tier-1 ISP
with different ASes depending on the global location, or an ISP
that has been created by mergers and acquisitions of multiple
networks). This scenario involves the constrained distribution of
routing information across multiple Autonomous Systems.
3. Multi-provider: This scenario is the most complex, wherein trust
negotiations need to be made across multiple service provider
backbones in order to meet the security and service level
agreements for the PPVPN customer. This scenario can be
generalized to cover the Internet, which comprises of multiple
service provider networks. It should be noted that customers can
construct their own VPNs across multiple providers. However such
VPNs are not considered here as they would not be "Provider-
provisioned".
A fourth scenario, "Carrier’s carrier" VPN may also be considered.
In this scenario, a service provider (for example, a Tier 1 service
provider) provides VPN service to another service provider (for
example, a Tier 2 service provider), which in turn provides VPN
service on its VPN to its customers. In the example given above, the
Tier 2 provider’s customers are contained within the Tier 2
provider’s network, and the Tier 2 provider itself is a customer of
the Tier 1 provider’s network. Thus, this scenario is not treated
separately in the document, because all of the single provider
requirements would apply equally to this case.
It is expected that many of the generic requirements described in
this document are independent of the three deployment scenarios
listed above. However, specific requirements that are indeed
dependent on the deployment scenario will be pointed out in this
document.
1.3. Outline of this document
This document describes generic requirements for Provider Provisioned
Virtual Private Networks (PPVPN). The document contains several
sections, with each set representing a significant aspect of PPVPN
requirements.
Section 2 lists authors who contributed to this document. Section 3
defines terminology and presents a taxonomy of PPVPN technologies.
The taxonomy contains two broad classes, representing Layer 2 and
Layer 3 VPNs. Each top level VPN class contains subordinate classes.
For example, the Layer 3 VPN class contains a subordinate class of
PE-based Layer 3 VPNs.
Sections 4, 5, 6 describe generic PPVPN requirements.
The requirements are broadly classified under the following
categories:
1) Service requirements - Service attributes that the customer can
observe or measure. For example, does the service forward frames
or route datagrams? What security guarantees does the service
provide? Availability and stability are key requirements in this
category.
2) Provider requirements - Characteristics that Service Providers use
to determine the cost-effectiveness of a PPVPN service. Scaling
and management are examples of Provider requirements.
3) Engineering requirements - Implementation characteristics that
make service and provider requirements achievable. These can be
further classified as:
3a) Forwarding plane requirements - e.g., requirements related to
router forwarding behavior.
3b) Control plane requirements - e.g., requirements related to
reachability and distribution of reachability information.
3c) Requirements related to the commonality of PPVPN mechanisms
with each other and with generic Internet mechanisms.
2. Contributing Authors
This document was the combined effort of several individuals that
were part of the Service Provider focus group whose intentions were
to present Service Provider view on the general requirements for
PPVPN. A significant set of requirements were directly taken from
previous work by the PPVPN WG to develop requirements for Layer 3
PPVPN [L3REQTS]. The existing work in the L2 requirements area has
also influenced the contents of this document [L2REQTS].
Besides the editor, the following are the authors that contributed to
this document:
Loa Andersson (loa@pi.se)
Ron Bonica (ronald.p.bonica@mci.com)
Dave McDysan (dave.mcdysan@mci.com)
Junichi Sumimoto (j.sumimoto@ntt.com)
Muneyoshi Suzuki (suzuki.muneyoshi@lab.ntt.co.jp)
David Meyer (dmm@1-4-5.net)
Marco Carugi (marco.carugi@nortelnetworks.com)
Yetik Serbest (yetik_serbest@labs.sbc.com)
Luyuan Fang (luyuanfang@att.com)
Javier Achirica (achirica@telefonica.net)
3. Definitions and Taxonomy
The terminology used in this document is defined in [TERMINOLOGY].
In addition the following terminology is used:
Site: a geographical location with one or more users or one or more
servers or a combination of servers and users.
User: the end user equipment (hosts), e.g., a workstation.
PPVPN
________________|__________________
| |
Layer 2 (L2) Layer 3 (L3)
______|_____ ______|________
| | | |
PE-based CE-based PE-based CE-based
|__________|
______|_____
| |
P2P P2MP
The figure above presents a taxonomy of PPVPN technologies. PE-based
and CE-based Layer 2 VPNs may also be further classified as point-to-
point (P2P) or point-to-multipoint (P2MP). It is also the intention
of the working group to have a limited number of solutions, and this
goal must be kept in mind when proposing solutions that meet the
requirements specified in this document. Definitions for CE-based
and PE-based PPVPNs can be obtained from [L3FRAMEWORK]. Layer 2
specific definitions can be obtained from [L2FRAMEWORK].
4. Service requirements
These are the requirements that a customer can observe or measure, in
order to verify if the PPVPN service that the Service Provider (SP)
provides is satisfactory. As mentioned before, each of these
requirements apply equally across each of the three deployment
scenarios unless stated otherwise.
4.1. Availability
VPN services MUST have high availability. VPNs that are distributed
over several sites require connectivity to be maintained even in the
event of network failures or degraded service.
This can be achieved via various redundancy techniques such as:
1. Physical Diversity
A single site connected to multiple CEs (for CE-based PPVPNs) or
PEs (for PE-based PPVPNs), or different POPs, or even different
service providers.
2. Tunnel redundancy
Redundant tunnels may be set up between the PEs (in a PE-based
PPVPN) or the CEs (in a CE-based PPVPN) so that if one tunnel
fails, VPN traffic can continue to flow across the other tunnel
that has already been set-up in advance.
Tunnel redundancy may be provided over and above physical
diversity. For example, a single site may be connected to two CEs
(for CE-based PPVPNs) or two PEs (for PE-based PPVPNs). Tunnels
may be set up between each of the CEs (or PEs as the case may be)
across different sites.
Of course, redundancy means additional resources being used, and
consequently, management of additional resources, which would
impact the overall scaling of the service.
It should be noted that it is difficult to guarantee high
availability when the VPN service is across multiple providers,
unless there is a negotiation between the different service
providers to maintain the service level agreement for the VPN
customer.
4.2. Stability
In addition to availability, VPN services MUST also be stable.
Stability is a function of several components such as VPN routing,
signaling and discovery mechanisms, in addition to tunnel stability.
For example, in the case of routing, route flapping or routing loops
MUST be avoided in order to ensure stability. Stability of the VPN
service is directly related to the stability of the mechanisms and
protocols used to establish the service. It SHOULD also be possible
to allow network upgrades and maintenance procedures without
impacting the VPN service.
4.3. Traffic types
VPN services MUST support unicast (or point to point) traffic and
SHOULD support any-to-any or point-to-multipoint traffic including
multicast and broadcast traffic. In the broadcast model, the network
delivers a stream to all members of a subnetwork, regardless of their
interest in that stream. In the multicast model, the network
delivers a stream to a set of destinations that have registered
interest in the stream. All destinations need not belong to the same
subnetwork. Multicast is more applicable to L3 VPNs while broadcast
is more applicable to L2VPNs. It is desirable to support multicast
limited in scope to an intranet or extranet. The solution SHOULD be
able to support a large number of such intranet or extranet specific
multicast groups in a scalable manner.
All PPVPN approaches SHALL support both IPv4 and IPv6 traffic.
Specific L2 traffic types (e.g., ATM, Frame Relay and Ethernet) SHALL
be supported via encapsulation in IP or MPLS tunnels in the case of
L2VPNs.
4.4. Data isolation
The PPVPN MUST support forwarding plane isolation. The network MUST
never deliver user data across VPN boundaries unless the two VPNs
participate in an intranet or extranet.
Furthermore, if the provider network receives signaling or routing
information from one VPN, it MUST NOT reveal that information to
another VPN unless the two VPNs participate in an intranet or
extranet. It should be noted that the disclosure of any
signaling/routing information across an extranet MUST be filtered per
the extranet agreement between the organizations participating in the
extranet.
4.5. Security
A range of security features SHOULD be supported by the suite of
PPVPN solutions in the form of securing customer flows, providing
authentication services for temporary, remote or mobile users, and
the need to protect service provider resources involved in supporting
a PPVPN. These security features SHOULD be implemented based on the
framework outlined in [VPN-SEC]. Each PPVPN solution SHOULD state
which security features it supports and how such features can be
configured on a per customer basis. Protection against Denial of
Service (DoS) attacks is a key component of security mechanisms.
Examples of DoS attacks include attacks to the PE or CE CPUs, access
connection congestion, TCP SYN attacks and ping attacks.
Some security mechanisms (such as use of IPsec on a CE-to-CE basis)
may be equally useful regardless of the scope of the VPN. Other
mechanisms may be more applicable in some scopes than in others. For
example, in some cases of single-provider single-AS VPNs, the VPN
service may be isolated from some forms of attack by isolating the
infrastructure used for supporting VPNs from the infrastructure used
for other services. However, the requirements for security are
common regardless of the scope of the VPN service.
4.5.1. User data security
PPVPN solutions that support user data security SHOULD use standard
methods (e.g., IPsec) to achieve confidentiality, integrity,
authentication and replay attack prevention. Such security methods
MUST be configurable between different end points, such as CE-CE,
PE-PE, and CE-PE. It is also desirable to configure security on a
per-route or per-VPN basis. User data security using encryption is
especially desirable in the multi-provider scenario.
4.5.2. Access control
A PPVPN solution may also have the ability to activate the
appropriate filtering capabilities upon request of a customer. A
filter provides a mechanism so that access control can be invoked at
the point(s) of communication between different organizations
involved in an extranet. Access control can be implemented by a
firewall, access control lists on routers, cryptographic mechanisms
or similar mechanisms to apply policy-based access control. Access
control MUST also be applicable between CE-CE, PE-PE and CE-PE. Such
access control mechanisms are desirable in the multi-provider
scenario.
4.5.3. Site authentication and authorization
A PPVPN solution requires authentication and authorization of the
following:
- temporary and permanent access for users connecting to sites
(authentication and authorization BY the site)
- the site itself (authentication and authorization FOR the site)
4.5.4. Inter domain security
The VPN solution MUST have appropriate security mechanisms to prevent
the different kinds of Distributed Denial of Service (DDoS) attacks
mentioned earlier, misconfiguration or unauthorized accesses in inter
domain PPVPN connections. This is particularly important for multi-
service provider deployment scenarios. However, this will also be
important in single-provider multi-AS scenarios.
4.6. Topology
A VPN SHOULD support arbitrary, customer-defined inter-site
connectivity, ranging, for example, from hub-and-spoke, partial mesh
to full mesh topology. These can actually be different from the
topology used by the service provider. To the extent possible, a
PPVPN service SHOULD be independent of the geographic extent of the
deployment.
Multiple VPNs per customer site SHOULD be supported without requiring
additional hardware resources per VPN. This SHOULD also include a
free mix of L2 and L3 VPNs.
To the extent possible, the PPVPN services SHOULD be independent of