Request for Comments: 4365 Cisco Systems, Inc.
Category: Informational February 2006
Applicability Statement for BGP/MPLS IP
Virtual Private Networks (VPNs)
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 (2006).
Abstract
This document provides an Applicability Statement for the Virtual
Private Network (VPN) solution described in RFC 4364 and other
documents listed in the References section.
Table of Contents
1. Introduction ....................................................2
2. SP Provisioning Model ...........................................4
3. Supported Topologies and Traffic Types ..........................6
4. Isolated Exchange of Data and Routing Information ...............7
5. Access Control and Authentication ...............................9
6. Security Considerations .........................................9
6.1. Protection of User Data ....................................9
6.2. SP Security Measures ......................................10
6.3. Security Framework Template ...............................12
7. Addressing .....................................................18
8. Interoperability and Interworking ..............................19
9. Network Access .................................................19
9.1. Physical/Link Layer Topology ..............................19
9.2. Temporary Access ..........................................19
9.3. Access Connectivity .......................................20
10. Service Access ................................................21
10.1. Internet Access ..........................................21
10.2. Other Services ...........................................21
11. SP Routing ....................................................22
12. Migration Impact ..............................................22
13. Scalability ...................................................23
14. QoS, SLA ......................................................26
15. Management ....................................................27
15.1. Management by the Provider ...............................27
15.2. Management by the Customer ...............................28
16. Acknowledgements ..............................................28
17. Normative References ..........................................29
18. Informative References ........................................29
1. Introduction
This document provides an Applicability Statement for the Virtual
Private Network (VPN) solution described in [BGP-MPLS-IP-VPN] and
other documents listed in the References section. We refer to these
as "BGP/MPLS IP VPNs", because Border Gateway Protocol (BGP) is used
to distribute the routes, and Multiprotocol Label Switching (MPLS) is
used to indicate that particular packets need to follow particular
routes. The characteristics of BGP/MPLS IP VPNs are compared with
the requirements specified in [L3VPN-REQS].
A VPN service is provided by a Service Provider (SP) to a customer
(sometimes referred to as an enterprise). BGP/MPLS IP VPNs are
intended for the situation in which:
- The customer:
* uses the VPN only for carrying IP packets.
* does not want to manage a routed backbone; the customer may
be using routing within his sites, but wishes to outsource
the inter-site routing to the SP.
* wants the SP to make the backbone and its routing completely
transparent to the customer’s own routing.
If the customer has a routed infrastructure at his sites, he
does not want his site routing algorithms to need to be aware
of any part of the SP backbone network, other than the
Provider Edge (PE) routers to which the sites are attached.
In particular, the customer does not want his routers to need
to be aware of either the native structure of the SP backbone
or an overlay topology of tunnels through the SP backbone.
- The Service Provider:
* has an IP backbone, with MPLS-enabled edge routers, and
possibly (though not necessarily) with MPLS-enabled core
routers.
* wants to provide a service that meets the customer
requirements above.
* does not want to maintain a distinct overlay topology of
tunnels for each customer.
The basic principle is to model each VPN as a self-contained
"internet", where each site makes one or more access connections to
an SP, sends the SP its routing information, and then relies on the
SP to distribute routing information to and from the other sites in
that same VPN. The service differs from Internet service, however,
in that the SP strictly controls the distribution of this routing
information so that routes from within a VPN are not sent outside the
VPN, unless that is explicitly authorized by the customer. In fact,
even within the VPN, the distribution of routes may be controlled by
the SP so as to meet some policy of the customer.
The routers at a given customer site need not be routing peers of the
routers at other customer sites, and indeed need not know anything
about the internal structure of other customer sites. In fact,
different routing protocols may run at the different sites, with each
site using whatever protocol is most appropriate for that particular
site.
If EBGP (the BGP procedures used between BGP speakers from different
Autonomous Systems) is used on the access links that connect a
Provider Edge router (PE router) to a Customer Edge router (CE
router), then the SP and the customer do NOT peer in any Interior
Gateway Protocol (IGP), i.e., intra-domain routing algorithm).
BGP/MPLS IP VPNs are optimized for the situation in which a customer
(an enterprise) expects a service provider to operate and maintain
the customer’s "backbone" (i.e., the customer’s inter-site routing).
As such, the service provider becomes a "business partner" of the
enterprise. The technical mechanisms accommodate the case in which a
number of closely cooperating SPs can jointly offer the VPN service
to a customer, in that the BGP-based route distribution mechanisms
can operate between different SPs. If a set of SPs has sufficient
agreements with respect to Quality of Service (QoS), Service Level
Agreement (SLA), etc., then the customer’s VPN could have sites
attached to different SPs from that set.
[BGP-MPLS-IP-VPN] specifies the inter-AS (Autonomous System)
mechanisms that allow a single VPN to have sites attached to
different SPs. However, the design center is not an environment
where a given VPN is spread among a very large number (e.g.,
hundreds) of SPs.
In cases where remote offices, individual telecommuters, etc., must
use the public Internet to access the VPN, it is possible to "tunnel"
the remote traffic to a PE router, and the PE router will treat the
traffic as if it had arrived over an interface connected to the PE.
Remote Point-to-Point Protocol (PPP) connections can be tunneled via
Layer 2 Tunneling Protocol (L2TP) to a PE router; IPsec tunnels can
also be used to tunnel traffic to a PE router across the public
Internet. Of course, when the public Internet is used, issues such
as QoS and SLAs must be carefully considered.
Some customers want to connect their sites over the public Internet,
creating a VPN "virtual backbone", purchasing connectivity for a
given site from whatever Internet Service Provider (ISP) offers the
best price for connecting that site. A BGP/MPLS IP VPN is not an
appropriate solution for such customers; they instead need to
consider solutions (either customer-managed or provider-managed) that
interconnect their sites via an overlay of secure tunnels across the
Internet. (See, for example, [IPSEC-VPN].)
Some customers who do not want to connect their sites via secure
site-to-site tunnels across the Internet may nevertheless want to
maintain complete control over the routing in their VPN backbone.
These customers will not want a "managed routing service" such as is
provided by BGP/MPLS IP VPNs, since that hides all details of the
backbone routing and topology from the customer. Rather, they may
prefer a "virtual router" service, in which the tunnels through the
SP networks are visible as links to the customer’s routing algorithm.
(See, for example, [VR-VPN].)
2. SP Provisioning Model
If a particular VPN attaches to a particular PE router, the SP must
configure that PE router with a VPN Routing and Forwarding table
(VRF), a routing table that is specific to the specified VPN. (This
is known as a VPN Forwarding Instance (VFI) in the language of
[L3VPN-REQS] and [L3VPN-FRMWRK].) Each interface or sub-interface at
that PE that attaches to a site in the specified VPN (i.e., each
local access link of that VPN) must be configured so as to be
associated with that VRF. Each such interface may be unnumbered or
may be assigned an address that is unique within the VPN’s address
space. In general, a routing algorithm needs to be run on each of
these links (though static routing can be used instead). The routing
algorithm can be EBGP, or an IGP such as Routing Information Protocol
(RIP) or Open Shortest Path First (OSPF). (IF OSPF is used, the
procedures of [VPN-OSPF] MUST be implemented.) If an IGP is run on
the access links, the IGP MUST be a separate IGP instance, different
than the IGP instance running among the backbone routers, and
different than the IGP instance running on the access links of any
other VPN. Static routing is also allowed.
The VRF is populated automatically with routes distributed from
locally attached CE routers via whatever routing algorithm is run on
the PE/CE links. It is also populated automatically with routes
distributed from other VRFs via BGP. Standard routing decision
processes are used to automatically select the proper routes. Static
configuration of routes in the VRF is optional.
Each PE router must run BGP, and must be pre-configured with the
identities of a small set of BGP Route Reflectors, with which it is
to peer via IBGP. ("IBGP" refers to the BGP procedures used between
BGP speakers from the same Autonomous System.)
In lieu of using Route Reflectors, one could configure each PE with
the identities of all the other PEs, and set up a full mesh of IBGP
connections. While this might be adequate for small networks, it
would not scale well to large networks; the use of Route Reflectors
is necessary to achieve scalability. See section 4.3.3 of
[BGP-MPLS-IP-VPN] for a more complete discussion of the use of Route
Reflectors, and related scalability mechanisms such as Outbound Route
Filtering.
Each VRF must be configured with three parameters:
- A Route Distinguisher. This is a globally unique 8-byte value.
Each VRF may have a unique Route Distinguisher (RD), or there may
be a single unique RD for an entire VPN. When BGP is used to
distribute VPN routing information across the SP backbone, this
value is prepended to the VPN’s IPv4 address prefixes, creating a
new address family, the VPN-IPv4 address family. Thus, even when
two VPNs have overlapping IPv4 address spaces, they have unique
VPN-IPv4 address spaces.
- One or more Export Route Targets. A Route Target (RT) is a
globally unique 8-byte value that BGP carries, as the Extended
Communities Route Target attribute, along with routes that are
exported form the VRF.
- One or more Import Route Targets. This RT is used to select
routes to be imported from other VRFs into this VRF.
In the simplest cases and most common cases, the Export RT, Import
RT, and RD can be identical, and all VRFs in the same VPN will
distribute routes to each other (a typical intranet). In more
complex cases, they can be set differently, allowing a very fine
degree of control over the distribution of routes among VRFs. This
can be used to create extranets or to enforce various customer
policies. In complicated cases, particular Export RTs can be
assigned to particular routes using router management mechanisms.
One advantage to not requiring the RD to be the same as any RT is
that this may allow an RD value to be automatically determined for
each VRF; RT values, on the other hand, must always be configured.
Adding a new site to a VPN is a matter of attaching the site’s CE
router to a PE router, configuring the interface, and, if a VRF for
that VPN already exists in the PE router, associating that interface
with the VRF. If a VRF for that VPN does not already exist in the
PE, then one must be configured as specified above. Changes to the
configuration of a PE are automatically reflected via BGP to the
other PEs.
The RTs and RDs are made unique by being structured as an SP
identifier followed by a number which is assigned by the identified
SP. SPs may be identified by their AS numbers, or by a registered IP
address owned by that SP.
Although RTs are encoded as BGP Extended Communities, the encoding
itself distinguishes them from any other kind of BGP Extended
Community.
3. Supported Topologies and Traffic Types
The scheme is optimized for full inter-site connectivity, in the
sense that this is what the simplest configurations provide.
However, the SP has full control, through the mechanism of Route
Targets, of the distribution of routing information among the set of
VRFs. This enables the SP to provide hub-and-spoke or partial mesh
connectivity as well as full mesh connectivity.
Note that, strictly speaking, the scheme does not create a topology,
as it does not create layer 2 connections among the sites. It does,
however, allow for control over the IP connectivity among the sites.
It is also possible to constrain the distribution of routing in
arbitrary ways, e.g., so that data from site A to site B must travel
through a third site C. (In fact, if it is desired to do so, this
level of control can be specified at the granularity of a single
route.)
It is possible for some of the routes from a particular customer site
A to be distributed to one set of remote sites, while other routes
from site A are distributed to a different set of remote sites. This
is done with the Route Target mechanism previously described.
Unicast IP traffic is fully supported. Customer IP packets are
passed transparently.
Multicast IP traffic is optionally supported, if the SP provides the
optional mechanisms of [BGP-MPLS-MCAST-VPN]. There are, however,
scaling implications to the use of these mechanisms. Discussion of
these implications is deferred.
Non-IP traffic is not supported. If support for non-IP traffic is
necessary, either the SP must additionally provide a layer 2
tunneling service or the customer must use IP tunneling.
In general, customer routers at different sites do not become routing
peers. However, a customer may, if he so desires, allow routers at
different sites to be routing peers over a link that is NOT part of
the VPN service. Such peering relationships are known as "IGP
backdoors". To ensure the proper operation of routing when IGP
backdoors are present, each VPN route that is distributed by the SP
is distributed along with a corresponding routing metric. This
enables the customer’s IGP to compare the "backdoor routes" properly
with the routes that use the SP backbone. In the particular case
where a customer running OSPF within his sites wishes to have IGP
backdoors, he should run OSPF on the PE/CE link, and the PEs should
run the procedures of [VPN-OSPF]. (The CEs do NOT require any
special OSPF procedures.)
4. Isolated Exchange of Data and Routing Information
The Route Target mechanism is used to control the distribution of
routing information, so that routes from one VPN do not get sent to
another. VPN routes are treated by BGP as a different address family
than general Internet routes. Routes from a VRF do not get leaked to
the Internet unless the VRF has been explicitly configured to allow
it (and this is NOT the default).
The way in which a particular VPN is divided into sites, or the
topology of any particular VPN site, is hidden from the Internet and
from other VPNs. (Of course, if a particular site can receive
Internet traffic, and if it responds to traceroute probes from the
Internet, then any user of the Internet can learn something about the
site topology. The fact that the site is in a VPN does not make this
any easier or any harder.)
Similarly, Internet routes do not get leaked into the VPN, unless a
VRF of that VPN is explicitly configured to import the Internet
routes.
Proper configuration is essential to maintaining the isolation. In
particular, each access link must be associated with the proper VRF
for that access link, and each VRF must be configured with the proper
set of RTs.
A number of means for exchanging reachability information between the
PE and CE devices are supported: static routing, EBGP, and RIP are
supported by the procedures of [BGP-MPLS-IP-VPN]. If the procedures
of [VPN-OSPF] and [OSPF-2547-DNBIT] are implemented, OSPF may be
used. If OSPF is used between two VPN sites that are in the same
OSPF area, and if it is desired for routes over the VPN backbone to
be preferred to the OSPF intra-site routes, then the "sham link"
procedures of [VPN-OSPF] must be used.
The routing protocols used among the customer routers are not in any
way restricted by the VPN scheme, as whatever IGP is used within the
VPN, the PE/CE access links may run EBGP, or may otherwise be in a
different routing domain than the site’s internal links.
BGP is used for passing routing information among SPs. BGP may be
authenticated by use of the TCP MD5 option, or by operating through
an IPsec tunnel.
Data traveling between two customer sites is encapsulated while in
transit through the backbone. The encapsulation contains sufficient
information to ensure that the packet is sent to the proper PE
router, and then, in conjunction with the VRF and related information
at that PE, to the proper CE routers.
If two VPNs attach to the same PE, there is strict separation of
forwarding at that PE, as well as strict separation of the routing
information.
Isolation of traffic is similar to that provided by classical L2 VPNs
which are based on Frame Relay or Asynchronous Transfer Mode (ATM).
As in classical L2 VPNs, the customer must rely on the SP to properly
configure the backbone network to ensure proper isolation and to
maintain the security of his communications gear.
5. Access Control and Authentication
No particular means of PE/CE authentication is specified for BGP/MPLS
IP VPNs. PE/CE mutual authentication may be done via any mechanism
supported by the routing protocol in which the CE and PE are peers
(e.g., use of the TCP MD5 authentication when the PE/CE protocol is
BGP), or by any other mechanism that may be desired. With such
mechanisms in place, a CE may not join a VPN until the CE
authenticates itself to the Service Provider.
There is, however, no standardized method that requires a CE to
authenticate itself to the customer network (rather than to the SP)
before the CE is allowed to join the VPN. This is for further study.
No particular means is specified for controlling which user data
packets can be forwarded by BGP/MPLS IP VPNs. BGP/MPLS IP VPNs are
compatible with Access Control Lists (ACLs) and any other filtering
features that are supported on the PE routers. Routing can be set up
so that extranet traffic is directly through a firewall, if that is
desired.
It is possible for various sorts of "tunnel interfaces" to be
associated with a VRF. In this case, whatever authentication is
natively used in the establishment of the tunnel interface may be
used. For example, an IPsec tunnel can be used as an "access link"
to attach a remote user or site to a VRF. The authentication
procedure in this case is part of IPsec, not part of the VPN scheme.
Where L2TP is used, each PPP session carried in an L2TP tunnel can be
associated with a VRF. The SP’s Authentication, Authorization, and
Accounting (AAA) server can be used to determine the VPN to which the
PPP session belongs, and then the customer’s AAA server can be given
the opportunity to authenticate that session as well.
6. Security Considerations
6.1. Protection of User Data
No particular means of ensuring user data security is specified for
BGP/MPLS IP VPNs.
The optional procedures of [MPLS/BGP-IPsec] may be used to provide
authentication and/or encryption of user data as it travels from the
ingress PE to the egress PE. However, the data is exposed at those
two PEs, as well as on the PE/CE access links.
The customer may provide his own user data security by using IPsec
tunnels that terminate within the customer sites. Such tunnels are
transparent to the VPN scheme. Schemes that discover the remote
tunnel endpoints automatically and then set up the tunnels
automatically as needed are the best fit with this VPN technology.
Note that there is no requirement in general that IPsec tunnels
between customer sites terminate at CE routers.
The use of end-to-end transport mode IPsec by the customer is also
transparent to the VPN scheme. In fact, the VPN scheme is compatible
with any use of security by the customer, as long as a cleartext IP
header is passed from CE to PE.
When data must cross the Internet to reach the ingress PE router,
IPsec tunnels between the end user and the PE router can be used; the
PE router must then associate each IPsec tunnel with the proper VRF.
This association would have to be based on user-specific information
provided by the Internet Key Exchange (IKE) protocol, such as a VPN-
id.
If data is going from one SP network to another, and must cross the
public Internet to get between those two networks, IPsec tunnels can
be used to secure the data. This would require bilateral agreement
between the two SPs. BGP connections can also be passed through an
IPsec tunnel if this is deemed necessary, in order to protect user
data, by a pair of SPs. QoS/SLA factors would have to be carefully
considered in this case.
6.2. SP Security Measures
The SP is responsible for preventing illegitimate traffic from
entering a VPN. VPN traffic is always encapsulated while traveling
on the backbone, so preventing illegitimate traffic is a matter of
ensuring that the PE routers to the encapsulation/decapsulation
correctly and that encapsulations have not been "spoofed", i.e., that
the encapsulated packets were actually encapsulated by PE routers.
This requires the SP to take various security measures. The PE and P
routers must themselves be secure against break-ins (either from
someone physically present or from the Internet), and neither P nor
PE routers should form routing adjacencies to other P or PE routers
without benefit of some kind of security. This may be authentication
in the IGP, or physical security.
The PE/CE access link should be secured in some manner, though the
provider may make it the responsibility of the customer to ensure
that the CE is secure from compromise. If the PE/CE access link is a
tunnel over the Internet, then of course some sort of authentication
protocol should always be used.
Label Distribution Protocol (LDP) sessions and BGP sessions between
PE and/or P routers should be authenticated. This can be done via
the TCP MD5 option or by use of IPsec.
If the SP is providing the VPN service over an MPLS backbone, it