< draft-rosen-rfc2547bis-02.txt   draft-rosen-rfc2547bis-03.txt >
Network Working Group Eric C. Rosen Network Working Group Eric C. Rosen
Internet Draft Yakov Rekhter Internet Draft Cisco Systems, Inc.
Expiration Date: January 2001 Cisco Systems, Inc. Expiration Date: August 2001 Yakov Rekhter
Juniper Networks, Inc.
Tony Bogovic Stephen John Brannon Tony Bogovic Stephen John Brannon
Ravichander Vaidyanathan Monique Jeanne Morrow Ravichander Vaidyanathan Monique Jeanne Morrow
Telcordia Technologies Swisscom AG Telcordia Technologies Swisscom AG
Marco Carugi Christopher J. Chase Marco Carugi Christopher J. Chase
France Telecom ATT France Telecom Luyuan Fang
ATT
Ting Wo Chung Jeremy De Clercq Ting Wo Chung Jeremy De Clercq
Bell Nexxia Alcatel Bell Nexxia Alcatel
Eric Dean Paul Hitchin Eric Dean Paul Hitchin
Global One Adrian Smith Global One Adrian Smith
BT BT
Manoj Leelanivas Dave Marshall Manoj Leelanivas Dave Marshall
Juniper Networks, Inc. Worldcom Juniper Networks, Inc. Worldcom
Luca Martini Vijay Srinivasan Luca Martini Vijay Srinivasan
Level 3 Communications, LLC CoSine Communications Level 3 Communications, LLC CoSine Communications
Alain Vedrenne Alain Vedrenne
SITA EQUANT SITA EQUANT
July 2000 February 2001
BGP/MPLS VPNs BGP/MPLS VPNs
draft-rosen-rfc2547bis-02.txt draft-rosen-rfc2547bis-03.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 3, line 19 skipping to change at page 3, line 19
1.2 Edge Devices ....................................... 5 1.2 Edge Devices ....................................... 5
1.3 Multiple Forwarding Tables in PEs .................. 6 1.3 Multiple Forwarding Tables in PEs .................. 6
1.4 VPNs with Overlapping Address Spaces ............... 6 1.4 VPNs with Overlapping Address Spaces ............... 6
1.5 VPNs with Different Routes to the Same System ...... 7 1.5 VPNs with Different Routes to the Same System ...... 7
1.6 SP Backbone Routers ................................ 7 1.6 SP Backbone Routers ................................ 7
1.7 Security ........................................... 8 1.7 Security ........................................... 8
2 Sites and CEs ...................................... 8 2 Sites and CEs ...................................... 8
3 VRFs: Per-Site Forwarding Tables in the PEs ........ 9 3 VRFs: Per-Site Forwarding Tables in the PEs ........ 9
4 VPN Route Distribution via BGP ..................... 11 4 VPN Route Distribution via BGP ..................... 11
4.1 The VPN-IPv4 Address Family ........................ 11 4.1 The VPN-IPv4 Address Family ........................ 11
4.2 Encoding of Route Distinguishers ................... 12 4.2 Encoding of Route Distinguishers ................... 13
4.3 Controlling Route Distribution ..................... 13 4.3 Controlling Route Distribution ..................... 13
4.3.1 The Route Target Attribute ......................... 13 4.3.1 The Route Target Attribute ......................... 14
4.3.2 Route Distribution Among PEs by BGP ................ 15 4.3.2 Route Distribution Among PEs by BGP ................ 15
4.3.3 Use of Route Reflectors ............................ 16 4.3.3 Use of Route Reflectors ............................ 17
4.3.4 How VPN-IPv4 NLRI is Carried in BGP ................ 19 4.3.4 How VPN-IPv4 NLRI is Carried in BGP ................ 19
4.3.5 Building VPNs using Route Targets .................. 19 4.3.5 Building VPNs using Route Targets .................. 19
4.3.6 Route Distribution Among VRFs in a Single PE ....... 20
5 Forwarding Across the Backbone ..................... 20 5 Forwarding Across the Backbone ..................... 20
6 Maintaining Proper Isolation of VPNs ............... 21 6 Maintaining Proper Isolation of VPNs ............... 22
7 How PEs Learn Routes from CEs ...................... 22 7 How PEs Learn Routes from CEs ...................... 22
8 How CEs learn Routes from PEs ...................... 25 8 How CEs learn Routes from PEs ...................... 25
9 Carriers' Carriers ................................. 25 9 Carriers' Carriers ................................. 26
10 Inter-Provider Backbones ........................... 26 10 Inter-Provider Backbones ........................... 27
11 Accessing the Internet from a VPN .................. 28 11 Accessing the Internet from a VPN .................. 29
12 Management VPNs .................................... 30 12 Management VPNs .................................... 31
13 Security ........................................... 31 13 Security ........................................... 32
14 Quality of Service ................................. 31 13.1 Data Plane ......................................... 32
15 Scalability ........................................ 32 13.2 Control Plane ...................................... 34
16 Intellectual Property Considerations ............... 32 13.3 Security of P and PE devices ....................... 34
17 Acknowledgments .................................... 33 14 Quality of Service ................................. 34
18 Authors' Addresses ................................. 33 15 Scalability ........................................ 34
19 References ......................................... 36 16 Intellectual Property Considerations ............... 35
20 Full Copyright Statement ........................... 37 17 Acknowledgments .................................... 35
18 Authors' Addresses ................................. 36
19 References ......................................... 39
20 Full Copyright Statement ........................... 40
1. Introduction 1. Introduction
1.1. Virtual Private Networks 1.1. Virtual Private Networks
Consider a set of "sites" which are attached to a common network Consider a set of "sites" which are attached to a common network
which we may call the "backbone". Let's apply some policy to create a which we may call the "backbone". Let's apply some policy to create a
number of subsets of that set, and let's impose the following rule: number of subsets of that set, and let's impose the following rule:
two sites may have IP interconnectivity over that backbone only if at two sites may have IP interconnectivity over that backbone only if at
least one of these subsets contains them both. least one of these subsets contains them both.
skipping to change at page 4, line 50 skipping to change at page 4, line 50
The mechanisms discussed in this document allow the implementation of The mechanisms discussed in this document allow the implementation of
a wide range of policies. For example, within a given VPN, we can a wide range of policies. For example, within a given VPN, we can
allow every site to have a direct route to every other site ("full allow every site to have a direct route to every other site ("full
mesh"), or we can restrict certain pairs of sites from having direct mesh"), or we can restrict certain pairs of sites from having direct
routes to each other ("partial mesh"). routes to each other ("partial mesh").
In this document, we are interested in the case where the common In this document, we are interested in the case where the common
backbone offers an IP service. We are NOT focused on the case where backbone offers an IP service. We are NOT focused on the case where
the common backbone is part of the public Internet, but rather on the the common backbone is part of the public Internet, but rather on the
case where it the backbone network of an SP or set of SPs with which case where it is the backbone network of an SP or set of SPs with
the customer maintains contractual relationships. That is, the which the customer maintains contractual relationships. That is, the
customer is explicitly purchasing VPN service from the SP, rather customer is explicitly purchasing VPN service from the SP, rather
than purchasing Internet access from it. (The customer may or may than purchasing Internet access from it. (The customer may or may
not be purchasing Internet access from the same SP as well.) not be purchasing Internet access from the same SP as well.)
The customer itself may be a single enterprise, a set of enterprises The customer itself may be a single enterprise, a set of enterprises
needing an extranet, an Internet Service Provider, an application needing an extranet, an Internet Service Provider, an application
service provider, or even another SP which offers the same kind of service provider, or even another SP which offers the same kind of
VPN service to its own customers. VPN service to its own customers.
In the rest of this introduction, we specify some properties which In the rest of this introduction, we specify some properties which
VPNs should have. The remainder of this document outlines a VPN VPNs should have. The remainder of this document outlines a VPN
skipping to change at page 6, line 18 skipping to change at page 6, line 18
Every site to which the PE is attached must be mapped to one of those Every site to which the PE is attached must be mapped to one of those
forwarding tables. When a packet is received from a particular site, forwarding tables. When a packet is received from a particular site,
the forwarding table associated with that site is consulted in order the forwarding table associated with that site is consulted in order
to determine how to route the packet. The forwarding table to determine how to route the packet. The forwarding table
associated with a particular site S is populated ONLY with routes associated with a particular site S is populated ONLY with routes
that lead to other sites which have at least one VPN in common with that lead to other sites which have at least one VPN in common with
S. This prevents communication between sites which have no VPN in S. This prevents communication between sites which have no VPN in
common. common.
A PE router is attached to a site by virtue of being the endpoint of A PE router is attached to a site by virtue of being the endpoint of
an interface or "sub-interface" (PVC, VLAN, GRE tunnel, etc.) whose an interface or "sub-interface" (e.g., PVC, VLAN, GRE tunnel, etc.)
other endpoint is a CE device. If there are multiple attachments whose other endpoint is a CE device. If there are multiple
between a site and a PE router, all the attachments may be mapped to attachments between a site and a PE router, all the attachments may
the same forwarding table, or different attachments may be mapped to be mapped to the same forwarding table, or different attachments may
different forwarding tables. When a PE router receives a packet from be mapped to different forwarding tables. When a PE router receives
a CE device, it knows the interface or sub-interface over which the a packet from a CE device, it knows the interface or sub-interface
packet arrived, and this determines the forwarding table used for over which the packet arrived, and this determines the forwarding
processing that packet. The choice of forwarding table is NOT table used for processing that packet. The choice of forwarding
determined by the user content of the packet. table is NOT determined by the user content of the packet.
Different sites can be mapped to the same forwarding table, but ONLY Different sites can be mapped to the same forwarding table, but ONLY
if they have all their VPNs in common. if they have all their VPNs in common.
A PE router will also have a "default forwarding table," which is not
associated with any particular VPN site or sites. The default
forwarding table is used for handling traffic which is not VPN
traffic, as well as for VPN traffic which is simply transiting this
router (i.e., traffic which was not received over a sub-interface
whose other endpoint is a CE device, and which is not being sent over
a sub-interface whose other endpoint is a CE device.
1.4. VPNs with Overlapping Address Spaces 1.4. VPNs with Overlapping Address Spaces
If two VPNs have no sites in common, then they may have overlapping If two VPNs have no sites in common, then they may have overlapping
address spaces. That is, a given address might be used in VPN V1 as address spaces. That is, a given address might be used in VPN V1 as
the address of system S1, but in VPN V2 as the address of a the address of system S1, but in VPN V2 as the address of a
completely different system S2. This is a common situation when the completely different system S2. This is a common situation when the
VPNs each use an RFC1918 private address space. (In fact, two VPNs VPNs each use an RFC1918 private address space. (In fact, two VPNs
which do have sites in common may have overlapping address spaces, as which do have sites in common may have overlapping address spaces, as
long as the overlapping part of the address space does not belong to long as the overlapping part of the address space does not belong to
any of the sites which the two VPNs have in common.) any of the sites which the two VPNs have in common.)
skipping to change at page 8, line 9 skipping to change at page 8, line 12
the policies used to form the VPNs), and is not constrained in any the policies used to form the VPNs), and is not constrained in any
way by an artificial "virtual topology" of tunnels. way by an artificial "virtual topology" of tunnels.
VPNs may span multiple service providers. There are a number of VPNs may span multiple service providers. There are a number of
possible methods for implementing this, which shall be discussed possible methods for implementing this, which shall be discussed
later. later.
1.7. Security 1.7. Security
VPNs of the sort being discussed here, even without making use of VPNs of the sort being discussed here, even without making use of
cryptographic security measures, provide a level of security cryptographic security measures, are intended to provide a level of
equivalent to that obtainable when a level 2 backbone (e.g., Frame security equivalent to that obtainable when a level 2 backbone (e.g.,
Relay) is used. In the absence of misconfiguration or deliberate Frame Relay) is used. That is, in the absence of misconfiguration or
interconnection of different VPNs, it is not possible for systems in deliberate interconnection of different VPNs, it is not possible for
one VPN to gain access to systems in another VPN. systems in one VPN to gain access to systems in another VPN. This is
discussed in more detail in section 13.
2. Sites and CEs 2. Sites and CEs
From the perspective of a particular backbone network, a set of IP From the perspective of a particular backbone network, a set of IP
systems constitutes a site if those systems have mutual IP systems constitutes a site if those systems have mutual IP
interconnectivity, and communication among them occurs without use of interconnectivity, and communication among them occurs without use of
the backbone. In general, a site will consist of a set of systems the backbone. In general, a site will consist of a set of systems
which are in geographic proximity. However, this is not universally which are in geographic proximity. However, this is not universally
true. If two geographic locations are connected via a leased line, true. If two geographic locations are connected via a leased line,
over which OSPF is running, and if that line is the preferred way of over which OSPF is running, and if that line is the preferred way of
skipping to change at page 9, line 30 skipping to change at page 9, line 32
different CE router could be used for each virtual site, if that is different CE router could be used for each virtual site, if that is
desired. desired.
Note that in all these cases, the mechanisms, as well as the policy, Note that in all these cases, the mechanisms, as well as the policy,
for controlling which traffic is in which VPN are in the hand of the for controlling which traffic is in which VPN are in the hand of the
customer. customer.
If it is desired to have a particular host be in multiple virtual If it is desired to have a particular host be in multiple virtual
sites, then that host must determine, for each packet, which virtual sites, then that host must determine, for each packet, which virtual
site the packet is associated with. It can do this, e.g., by sending site the packet is associated with. It can do this, e.g., by sending
packets from different virtual sites on different VLANs, our out packets from different virtual sites on different VLANs, or out
different network interfaces. different network interfaces.
3. VRFs: Per-Site Forwarding Tables in the PEs 3. VRFs: Per-Site Forwarding Tables in the PEs
Each PE router maintains one or more "per-site forwarding tables." Each PE router maintains one or more "per-site forwarding tables."
These are known as VRFs, or "VPN Routing and Forwarding" tables. These are known as VRFs, or "VPN Routing and Forwarding" tables.
Every site to which the PE router is attached is associated with one Every site to which the PE router is attached is associated with one
of these tables. A particular packet's IP destination address is of these tables. A particular packet's IP destination address is
looked up in a particular VRF only if that packet has arrived looked up in a particular VRF only if that packet has arrived
directly from a site which is associated with that table. directly from a site which is associated with that table.
skipping to change at page 11, line 5 skipping to change at page 11, line 5
backbone. backbone.
This allows the backbone to support multiple different routes to the This allows the backbone to support multiple different routes to the
same system, where the route followed by a given packet is determined same system, where the route followed by a given packet is determined
by the site from which the packet enters the backbone. E.g., one may by the site from which the packet enters the backbone. E.g., one may
have one route to a given system for packets from the extranet (where have one route to a given system for packets from the extranet (where
the route leads to a firewall), and a different route to the same the route leads to a firewall), and a different route to the same
system for packets from the intranet (including packets that have system for packets from the intranet (including packets that have
already passed through the firewall). already passed through the firewall).
A PE router also contains a "default forwarding table", which is not
a VRF. The default forwarding table is used for forwarding packets
that arrive on sub-interfaces which are not associated with any VRF,
and which are not destined to be sent on sub-interfaces associated
with a VRF. The default forwarding table is populated in the normal
way by the routing algorithm of the SP network; it does not contain
routes from the VPNs.
4. VPN Route Distribution via BGP 4. VPN Route Distribution via BGP
PE routers use BGP to distribute VPN routes to each other (more PE routers use BGP to distribute VPN routes to each other (more
accurately, to cause VPN routes to be distributed to each other). accurately, to cause VPN routes to be distributed to each other).
We allow each VPN to have its own address space, which means that a We allow each VPN to have its own address space, which means that a
given address may denote different systems in different VPNs. If two given address may denote different systems in different VPNs. If two
routes, to the same IP address prefix, are actually routes to routes, to the same IP address prefix, are actually routes to
different systems, it is important to ensure that BGP not treat them different systems, it is important to ensure that BGP not treat them
as comparable. Otherwise BGP might choose to install only one of as comparable. Otherwise BGP might choose to install only one of
skipping to change at page 12, line 15 skipping to change at page 12, line 24
RDs), without conflicting with the RD assignments made by any other RDs), without conflicting with the RD assignments made by any other
service provider. An RD consists of a two-byte type field, an service provider. An RD consists of a two-byte type field, an
administrator field, and an assigned number field. The value of the administrator field, and an assigned number field. The value of the
type field determines the lengths of the other two fields, as well as type field determines the lengths of the other two fields, as well as
the semantics of the administrator field. The administrator field the semantics of the administrator field. The administrator field
identifies an assigned number authority, and the assigned number identifies an assigned number authority, and the assigned number
field contains a number which has been assigned, by the identified field contains a number which has been assigned, by the identified
authority, for a particular purpose. For example, one could have an authority, for a particular purpose. For example, one could have an
RD whose administrator field contains an Autonomous System number RD whose administrator field contains an Autonomous System number
(ASN), and whose (4-byte) number field contains a number assigned by (ASN), and whose (4-byte) number field contains a number assigned by
the SP to whom IANA has assigned that ASN. the SP to whom that ASN belongs (having been assigned to that SP by
the appropriate authority).
RDs are given this structure in order to ensure that an SP which RDs are given this structure in order to ensure that an SP which
provides VPN backbone service can always create a unique RD when it provides VPN backbone service can always create a unique RD when it
needs to do so. However, the structuring provides no semantics. When needs to do so. However, the structuring provides no semantics. When
BGP compares two such address prefixes, it ignores the structure BGP compares two such address prefixes, it ignores the structure
entirely. entirely.
Note that VPN-IPv4 addresses and IPv4 addresses are always Note that VPN-IPv4 addresses and IPv4 addresses are always
considered by BGP to be incomparable. considered by BGP to be incomparable.
skipping to change at page 13, line 12 skipping to change at page 13, line 25
Type field. At the present time, two values of the type field are Type field. At the present time, two values of the type field are
defined: 0 and 1. defined: 0 and 1.
- Type 0: The Value field consists of two subfields: - Type 0: The Value field consists of two subfields:
* Administrator subfield: 2 bytes * Administrator subfield: 2 bytes
* Assigned Number subfield: 4 bytes * Assigned Number subfield: 4 bytes
The Administrator subfield must contain an Autonomous System The Administrator subfield must contain an Autonomous System
number. If this ASN is from the public ASN space, it must have number. If this ASN is from the public ASN space, it must have
been assigned by IANA (use of ASN values from the private ASN been assigned by the appropriate authority (use of ASN values
space is strongly discouraged). The Assigned Number subfield from the private ASN space is strongly discouraged). The
contains a number from a numbering space which is administered by Assigned Number subfield contains a number from a numbering space
the enterprise to which the ASN has been assigned by IANA. which is administered by the enterprise to which the ASN has been
assigned by an appropriate authority.
- Type 1: The Value field consists of two subfields: - Type 1: The Value field consists of two subfields:
* Administrator subfield: 4 bytes * Administrator subfield: 4 bytes
* Assigned Number subfield: 2 bytes * Assigned Number subfield: 2 bytes
The Administrator subfield must contain an IP address. If this IP The Administrator subfield must contain an IP address. If this IP
address is from the public IP address space, it must have been address is from the public IP address space, it must have been
assigned by IANA (use of addresses from the private IP address assigned by an appropriate authority (use of addresses from the
space is strongly discouraged). The Assigned Number sub-field private IP address space is strongly discouraged). The Assigned
contains a number from a numbering space which is administered by Number sub-field contains a number from a numbering space which
the enterprise to which the IP address has been assigned. is administered by the enterprise to which the IP address has
been assigned.
4.3. Controlling Route Distribution 4.3. Controlling Route Distribution
In this section, we discuss the way in which the distribution of the In this section, we discuss the way in which the distribution of the
VPN-IPv4 routes is controlled. VPN-IPv4 routes is controlled.
4.3.1. The Route Target Attribute 4.3.1. The Route Target Attribute
Every VRF is associated with one or more "Route Target" attributes. Every VRF is associated with one or more "Route Target" attributes.
skipping to change at page 16, line 36 skipping to change at page 17, line 6
of a PE's VRFs (as a result of one or more "VPN Prune" operations), of a PE's VRFs (as a result of one or more "VPN Prune" operations),
the PE may discard all routes which, as a result, no longer have any the PE may discard all routes which, as a result, no longer have any
of the PE's VRF's Import Targets as one of their Route Target of the PE's VRF's Import Targets as one of their Route Target
Attributes. Attributes.
A router which is not attached to any VPN, and which is not a Route A router which is not attached to any VPN, and which is not a Route
Reflector (i.e., a P router), never installs any VPN-IPv4 routes at Reflector (i.e., a P router), never installs any VPN-IPv4 routes at
all. all.
Note that VPN Join and Prune operations are non-disruptive, and do Note that VPN Join and Prune operations are non-disruptive, and do
not require any BGP connections to be brought down. not require any BGP connections to be brought down, as long as the
refresh mechanism of [BGP-RFSH] is used.
As a result of these distribution rules, no one PE ever needs to As a result of these distribution rules, no one PE ever needs to
maintain all routes for all VPNs; this is an important scalability maintain all routes for all VPNs; this is an important scalability
consideration. consideration.
4.3.3. Use of Route Reflectors 4.3.3. Use of Route Reflectors
Rather than having a complete IBGP mesh among the PEs, it is Rather than having a complete IBGP mesh among the PEs, it is
advantageous to make use of BGP Route Reflectors [BGP-RR] to improve advantageous to make use of BGP Route Reflectors [BGP-RR] to improve
scalability. All the usual techniques for using route reflectors to scalability. All the usual techniques for using route reflectors to
skipping to change at page 17, line 40 skipping to change at page 18, line 11
Target is needed for a new VPN, there is already one or more Target is needed for a new VPN, there is already one or more
route reflectors that are (pre)configured with this Route route reflectors that are (pre)configured with this Route
Target. Target.
Unless a given PE is a client of all route reflectors, when a Unless a given PE is a client of all route reflectors, when a
new VPN is added to the PE ("VPN Join"), it will need to become new VPN is added to the PE ("VPN Join"), it will need to become
a client of the route reflector(s) that maintain routes for a client of the route reflector(s) that maintain routes for
that VPN. Likewise, deleting an existing VPN from the PE ("VPN that VPN. Likewise, deleting an existing VPN from the PE ("VPN
Prune") may result in a situation where the PE no longer need Prune") may result in a situation where the PE no longer need
to be a client of some route reflector(s). In either case, the to be a client of some route reflector(s). In either case, the
Join or Prune operation is non-disruptive, and never requires a Join or Prune operation is non-disruptive (as long as [BGP-
BGP connection to be brought down, only to be brought right RFSH] is used, and never requires a BGP connection to be
back up. brought down, only to be brought right back up.
(By "adding a new VPN to a PE", we really mean adding a new (By "adding a new VPN to a PE", we really mean adding a new
import Route Target to one of its VRFs, or adding a new VRF import Route Target to one of its VRFs, or adding a new VRF
with an import Route Target not had by any of the PE's other with an import Route Target not had by any of the PE's other
VRFs.) VRFs.)
2. Another method is to have each PE be a client of some subset of 2. Another method is to have each PE be a client of some subset of
the route reflectors. A route reflector is not preconfigured the route reflectors. A route reflector is not preconfigured
with the list of Route Targets, and does not perform inbound with the list of Route Targets, and does not perform inbound
route filtering of routes received from its clients (PEs); route filtering of routes received from its clients (PEs);
skipping to change at page 18, line 34 skipping to change at page 18, line 49
reflector should accept ORFs from other route reflectors. To reflector should accept ORFs from other route reflectors. To
accomplish this, a route reflector advertises ORF capability to accomplish this, a route reflector advertises ORF capability to
other route reflectors. other route reflectors.
When the route reflector changes the set, it should immediately When the route reflector changes the set, it should immediately
change its inbound route filtering. In addition, if the route change its inbound route filtering. In addition, if the route
reflector uses ORFs, then the ORFs have to be immediately reflector uses ORFs, then the ORFs have to be immediately
changed to reflect the changes in the set. If the route changed to reflect the changes in the set. If the route
reflector doesn't use ORFs, and a new Route Target is added to reflector doesn't use ORFs, and a new Route Target is added to
the set, the route reflector, after changing its inbound route the set, the route reflector, after changing its inbound route
filtering, must issue BGP Refresh to other router reflectors. filtering, must issue BGP Refresh to other route reflectors.
The delay of "a few hours" mentioned above allows a route
reflector to hold onto routes with a given RT, even after it
loses the last of its clients which are interested in such
routes. This protects against the need to reacquire all such
routes if the clients' "disappearance" is only temporary.
With this procedure, VPN Join and Prune operations are also With this procedure, VPN Join and Prune operations are also
non-disruptive. non-disruptive.
In both of these procedures, a PE router which attaches to a
particular VPN "auto-discovers" the other PEs which attach to the
same VPN. When a new PE router is added, or when an existing PE
router attaches to a new VPN, no reconfiguration of other PE routers
is needed.
Just as there is no one PE router that needs to know all the VPN-IPv4 Just as there is no one PE router that needs to know all the VPN-IPv4
routes that are supported over the backbone, these distribution rules routes that are supported over the backbone, these distribution rules
ensure that there is no one RR which needs to know all the VPN-IPv4 ensure that there is no one RR which needs to know all the VPN-IPv4
routes that are supported over the backbone. As a result, the total routes that are supported over the backbone. As a result, the total
number of such routes that can be supported over the backbone is not number of such routes that can be supported over the backbone is not
bounded by the capacity of any single device, and therefore can bounded by the capacity of any single device, and therefore can
increase virtually without bound. increase virtually without bound.
4.3.4. How VPN-IPv4 NLRI is Carried in BGP 4.3.4. How VPN-IPv4 NLRI is Carried in BGP
skipping to change at page 20, line 5 skipping to change at page 20, line 23
"hub and spoke" kind of VPN. This could be done by the use of two "hub and spoke" kind of VPN. This could be done by the use of two
Route Target values, one meaning "Hub" and one meaning "Spoke". At Route Target values, one meaning "Hub" and one meaning "Spoke". At
the VRFs attached to the hub sites, "Hub" is the Export Target and the VRFs attached to the hub sites, "Hub" is the Export Target and
"Spoke" is the Import Target. At the VRFs attached to the spoke "Spoke" is the Import Target. At the VRFs attached to the spoke
site, "Hub" is the Import Target and "Spoke" is the Export Target. site, "Hub" is the Import Target and "Spoke" is the Export Target.
Thus the methods for controlling the distribution of routing Thus the methods for controlling the distribution of routing
information among various sets of sites are very flexible, which in information among various sets of sites are very flexible, which in
turn provides great flexibility in constructing VPNs. turn provides great flexibility in constructing VPNs.
4.3.6. Route Distribution Among VRFs in a Single PE
It is possible to distribute routes from one VRF to another, even if
both VRFs are in the same PE, even though in this case one cannot say
that the route has been distributed by BGP. Nevertheless, the
decision to distribute a particular route from one VRF to another
within a single PE is the same decision that would be made if the
VRFs were on different PEs. That is, it depends on the route target
attribute which is assigned to the route (or would be assigned if the
route were distributed by BGP), and the import target of the second
VRF.
5. Forwarding Across the Backbone 5. Forwarding Across the Backbone
If the intermediate routers in the backbone do not have any If the intermediate routers in the backbone do not have any
information about the routes to the VPNs, how are packets forwarded information about the routes to the VPNs, how are packets forwarded
from one VPN site to another? from one VPN site to another?
This is done by means of MPLS with a two-level label stack. This is done by means of MPLS with a two-level label stack.
PE routers (and ASBRs which redistribute VPN-IPv4 addresses) need to PE routers (and ASBRs which redistribute VPN-IPv4 addresses) need to
insert /32 address prefixes for themselves into the IGP routing insert /32 address prefixes for themselves into the IGP routing
skipping to change at page 21, line 4 skipping to change at page 21, line 36
assigned a label for the route which best matches the packet's assigned a label for the route which best matches the packet's
destination address. This label is pushed onto the packet's label destination address. This label is pushed onto the packet's label
stack, and becomes the bottom label. The packet will also have an stack, and becomes the bottom label. The packet will also have an
"IGP Next Hop", which is the next hop along the IGP route to the BGP "IGP Next Hop", which is the next hop along the IGP route to the BGP
Next Hop. The IGP Next Hop will have assigned a label for the route Next Hop. The IGP Next Hop will have assigned a label for the route
which best matches the address of the BGP Next Hop. This label gets which best matches the address of the BGP Next Hop. This label gets
pushed on as the packet's top label. The packet is then forwarded to pushed on as the packet's top label. The packet is then forwarded to
the IGP next hop. (Of course, if the BGP Next Hop and the IGP Next the IGP next hop. (Of course, if the BGP Next Hop and the IGP Next
Hop are the same, and if penultimate hop popping is used, the packet Hop are the same, and if penultimate hop popping is used, the packet
may be sent with only the BGP-supplied label.) may be sent with only the BGP-supplied label.)
MPLS will then carry the packet across the backbone. The egress PE MPLS will then carry the packet across the backbone. The egress PE
router's treatment of the packet will depend on the label that was router's treatment of the packet will depend on the label that was
first pushed on by the ingress PE. In many cases, the PE will be first pushed on by the ingress PE. In many cases, the PE will be
able to determine, from this label, the sub-interface over which the able to determine, from this label, the sub-interface over which the
packet should be transmitted (to a CE device), as well as the proper packet should be transmitted (to a CE device), as well as the proper
data link layer header for that interface. In other cases, the PE data link layer header for that interface. In other cases, the PE
may only be able to determine that the packet's destination address may only be able to determine that the packet's destination address
needs to be looked up in a particular VRF before being forwarded to a needs to be looked up in a particular VRF before being forwarded to a
CE device. Information in the MPLS header itself, and/or information CE device. Information in the MPLS header itself, and/or information
associated with the label, may also be used to provide QoS on the associated with the label, may also be used to provide QoS on the
interface to the CE. In any event, when the packet finally gets to a interface to the CE. In any event, when the packet finally gets to a
CE device, it will again be an ordinary unlabeled IP packet. CE device, it will again be an ordinary unlabeled IP packet.
Note that it is the two-level labeling that makes it possible to keep Note that it is the two-level labeling that makes it possible to keep
all the VPN routes out of the P routers, and this in turn is crucial all the VPN routes out of the P routers, and this in turn is crucial
to ensuring the scalability of the model. The backbone does not even to ensuring the scalability of the model. The backbone does not even
need to have routes to the CEs, only to the PEs. need to have routes to the CEs, only to the PEs.
If it is necessary to carry VPN packets through a sequence of P
routers which do not support MPLS, the top label (which represents a
route to the BGP next hop) could in theory be replaced with an "MPLS
in IP (or in GRE or in IPsec, etc.)" encapsulation, where the IP
destination address is the address of the BGP next hop. The use of
such techniques is for further study.
6. Maintaining Proper Isolation of VPNs 6. Maintaining Proper Isolation of VPNs
To maintain proper isolation of one VPN from another, it is important To maintain proper isolation of one VPN from another, it is important
that no router in the backbone accept a labeled packet from any that no router in the backbone accept a labeled packet from any
adjacent non-backbone device unless the following two conditions adjacent non-backbone device unless the following two conditions
hold: hold:
1. the label at the top of the label stack was actually 1. the label at the top of the label stack was actually
distributed by that backbone router to that non-backbone distributed by that backbone router to that non-backbone
device, and device, and
skipping to change at page 23, line 15 skipping to change at page 23, line 52
IPv4 routes which the PE learns from the CE via OSPF are IPv4 routes which the PE learns from the CE via OSPF are
redistributed into BGP as VPN-IPv4 routes. Extended community redistributed into BGP as VPN-IPv4 routes. Extended community
attributes are used to carry, along with the route, all the attributes are used to carry, along with the route, all the
information needed to enable the route to be distributed to information needed to enable the route to be distributed to
other CE routers in the VPN in the proper type of OSPF LSA. other CE routers in the VPN in the proper type of OSPF LSA.
OSPF route tagging is used to ensure that routes received from OSPF route tagging is used to ensure that routes received from
the MPLS/BGP backbone are not sent back into the backbone. the MPLS/BGP backbone are not sent back into the backbone.
Specification of the complete set of procedures for the use of Specification of the complete set of procedures for the use of
OSPF between PE and CE must be left to another document. OSPF between PE and CE can be found in [VPN-OSPF].
4. The PE and CE routers may be BGP peers, and the CE router may 4. The PE and CE routers may be BGP peers, and the CE router may
use BGP (in particular, EBGP to tell the PE router the set of use BGP (in particular, EBGP to tell the PE router the set of
address prefixes which are at the CE router's site. (This address prefixes which are at the CE router's site. (This
technique can be used in stub VPNs or transit VPNs.) technique can be used in stub VPNs or transit VPNs.)
From a purely technical perspective, this is by far the best This technique has a number of advantages over the others:
technique:
a) Unlike the IGP alternatives, this does not require the PE a) Unlike the IGP alternatives, this does not require the PE
to run multiple routing algorithm instances in order to to run multiple routing algorithm instances in order to
talk to multiple CEs talk to multiple CEs
b) BGP is explicitly designed for just this function: b) BGP is explicitly designed for just this function:
passing routing information between systems run by passing routing information between systems run by
different administrations different administrations
c) If the site contains "BGP backdoors", i.e., routers with c) If the site contains "BGP backdoors", i.e., routers with
skipping to change at page 24, line 7 skipping to change at page 24, line 42
- The CE may suggest a particular Route Target for each - The CE may suggest a particular Route Target for each
route, from among the Route Targets that the PE is route, from among the Route Targets that the PE is
authorized to attach to the route. The PE would then authorized to attach to the route. The PE would then
attach only the suggested Route Target, rather than attach only the suggested Route Target, rather than
the full set. This gives the CE administrator some the full set. This gives the CE administrator some
dynamic control of the distribution of routes from dynamic control of the distribution of routes from
the CE. the CE.
- Additional types of Extended Community attributes may - Additional types of Extended Community attributes may
be defined, where the intention is to have those be defined, where the intention is to have those
attributes passed transparently from CE to CE. This attributes passed transparently (i.e., without being
would allow CE administrators to implement additional changed by the PE routers) from CE to CE. This would
route filtering, beyond that which is done by the allow CE administrators to implement additional route
PEs. This additional filtering would not require filtering, beyond that which is done by the PEs.
This additional filtering would not require
coordination with the SP. coordination with the SP.
On the other hand, using BGP is likely to be something new for On the other hand, using BGP is likely to be something new for
the CE administrators, except in the case where the customer the CE administrators, except in the case where the customer
itself is already an Internet Service Provider (ISP), or where itself is already an Internet Service Provider (ISP), or where
the CE devices are managed by the SP. the CE devices are managed by the SP.
If a site is not in a transit VPN, note that it need not have a If a site is not in a transit VPN, note that it need not have a
unique Autonomous System Number (ASN). Every CE whose site unique Autonomous System Number (ASN). Every CE whose site
which is not in a transit VPN can use the same ASN. This can which is not in a transit VPN can use the same ASN. This can
skipping to change at page 25, line 9 skipping to change at page 25, line 43
learned from a particular site via a particular PE/CE connection is learned from a particular site via a particular PE/CE connection is
not distributed back to the site through a different PE/CE not distributed back to the site through a different PE/CE
connection. It is particularly useful if BGP is being used as the connection. It is particularly useful if BGP is being used as the
PE/CE protocol, but different sites have not been assigned distinct PE/CE protocol, but different sites have not been assigned distinct
ASNs. ASNs.
8. How CEs learn Routes from PEs 8. How CEs learn Routes from PEs
In this section, we assume that the CE device is a router. In this section, we assume that the CE device is a router.
If the PE places a particular route in the VRF is uses to route If the PE places a particular route in the VRF it uses to route
packets received from a particular CE, then in general, the PE may packets received from a particular CE, then in general, the PE may
distribute that route to the CE. Of course the PE may distribute distribute that route to the CE. Of course the PE may distribute
that route to the CE only if this is permitted by the rules of the that route to the CE only if this is permitted by the rules of the
PE/CE protocol. (For example, if a particular PE/CE protocol has PE/CE protocol. (For example, if a particular PE/CE protocol has
"split horizon", certain routes in the VRF cannot be redistributed "split horizon", certain routes in the VRF cannot be redistributed
back to the CE.) We add one more restriction on the distribution of back to the CE.) We add one more restriction on the distribution of
routes from PE to CE: if a route's Site of Origin attribute routes from PE to CE: if a route's Site of Origin attribute
identifies a particular site, that route must never be redistributed identifies a particular site, that route must never be redistributed
to any CE at that site. to any CE at that site.
skipping to change at page 26, line 9 skipping to change at page 26, line 42
- The CE routers should support MPLS, in that they should be able - The CE routers should support MPLS, in that they should be able
to receive labels from the PE routers, and send labeled packets to receive labels from the PE routers, and send labeled packets
to the PE routers. They do not need to distribute labels of to the PE routers. They do not need to distribute labels of
their own though. their own though.
- The PE routers should distribute, to the CE routers, labels for - The PE routers should distribute, to the CE routers, labels for
the routes they distribute to the CE routers. the routes they distribute to the CE routers.
- Routers at the different sites should establish BGP connections - Routers at the different sites should establish BGP connections
among themselves for the purpose of exchanging external routes. among themselves for the purpose of exchanging external routes
(i.e., routes which lead outside of the VPN).
- All the external routes must be known to the CE routers. - All the external routes must be known to the CE routers.
Then when a CE router looks up a packet's destination address, the Then when a CE router looks up a packet's destination address, the
routing lookup will resolve to an internal address, usually the routing lookup will resolve to an internal address, usually the
address of the packet's BGP next hop. The CE labels the packet address of the packet's BGP next hop. The CE labels the packet
appropriately and sends the packet to the PE. appropriately and sends the packet to the PE.
In the above procedure, the CE routers are the only routers in the In the above procedure, the CE routers are the only routers in the
VPN which need to support MPLS. If, on the other hand, all the VPN which need to support MPLS. If, on the other hand, all the
skipping to change at page 27, line 44 skipping to change at page 28, line 31
appropriate trust relationships must exist between and among appropriate trust relationships must exist between and among
the set of ASes along the path. Also, there must be agreement the set of ASes along the path. Also, there must be agreement
among the set of SPs as to which border routers need to receive among the set of SPs as to which border routers need to receive
routes with which Route Targets. routes with which Route Targets.
c) Multihop EBGP redistribution of labeled VPN-IPv4 routes between c) Multihop EBGP redistribution of labeled VPN-IPv4 routes between
source and destination ASes, with EBGP redistribution of source and destination ASes, with EBGP redistribution of
labeled IPv4 routes from AS to neighboring AS. labeled IPv4 routes from AS to neighboring AS.
In this procedure, VPN-IPv4 routes are neither maintained nor In this procedure, VPN-IPv4 routes are neither maintained nor
distributed by the ASBRs. However, an ASBR does use EBGP to distributed by the ASBRs. An ASBR must maintain labeled IPv4
distribute labeled IPv4 /32 routes to the PE routers within its /32 routes to the PE routers within its AS. It uses EBGP to
AS. ASBRs in any transit ASes will also have to use EBGP to distribute these routes to other ASes. ASBRs in any transit
pass along the labeled /32 routes. This results in the ASes will also have to use EBGP to pass along the labeled /32
creation of a label switched path from the ingress PE router to routes. This results in the creation of a label switched path
the egress PE router. Now PE routers in different ASes can from the ingress PE router to the egress PE router. Now PE
establish multi-hop EBGP connections to each other, and can routers in different ASes can establish multi-hop EBGP
exchange VPN-IPv4 routes over those connections. connections to each other, and can exchange VPN-IPv4 routes
over those connections.
If the /32 routes for the PE routers are made known to the P If the /32 routes for the PE routers are made known to the P
routers of each AS, everything works normally. If the /32 routers of each AS, everything works normally. If the /32
routes for the PE routers are NOT made known to the P routers routes for the PE routers are NOT made known to the P routers
(other than the ASBRs), then this procedure requires a packet's (other than the ASBRs), then this procedure requires a packet's
ingress PE to put a three label stack on it. The bottom label ingress PE to put a three label stack on it. The bottom label
is assigned by the egress PE, corresponding to the packet's is assigned by the egress PE, corresponding to the packet's
destination address in a particular VRF. The middle label is destination address in a particular VRF. The middle label is
assigned by the ASBR, corresponding to the /32 route to the assigned by the ASBR, corresponding to the /32 route to the
egress PE. The top label is assigned by the ingress PE's IGP egress PE. The top label is assigned by the ingress PE's IGP
skipping to change at page 28, line 32 skipping to change at page 29, line 19
reflectors in their own AS. reflectors in their own AS.
This procedure is very similar to the "Carrier's Carrier" This procedure is very similar to the "Carrier's Carrier"
procedures described in section 9. Like the previous procedure, procedures described in section 9. Like the previous procedure,
it requires that there be a label switched path leading from a it requires that there be a label switched path leading from a
packet's ingress PE to its egress PE. packet's ingress PE to its egress PE.
11. Accessing the Internet from a VPN 11. Accessing the Internet from a VPN
Many VPN sites will need to be able to access the public Internet, as Many VPN sites will need to be able to access the public Internet, as
well as to access other VPN sites. There are a number of ways to do well as to access other VPN sites. The following describes some of
this. the alternative ways of doing this.
1. In some VPNs, one or more of the sites will obtain Internet 1. In some VPNs, one or more of the sites will obtain Internet
Access by means of an "Internet gateway" (perhaps a firewall) Access by means of an "Internet gateway" (perhaps a firewall)
attached to a non-VRF interface to an ISP. The ISP may or may attached to a non-VRF interface to an ISP. The ISP may or may
not be the same organization as the SP which is providing the not be the same organization as the SP which is providing the
VPN service. VPN service. Traffic to/from the Internet gateway would then
be routed according to the PE router's default forwarding
table.
In this case, the sites which have Internet Access may be In this case, the sites which have Internet Access may be
distributing a default route to their PEs, which in turn distributing a default route to their PEs, which in turn
redistribute it to other PEs and hence into other sites of the redistribute it to other PEs and hence into other sites of the
VPN. This provides Internet Access for all of the VPN's sites. VPN. This provides Internet Access for all of the VPN's sites.
In order to properly handle traffic from the Internet, the ISP In order to properly handle traffic from the Internet, the ISP
must distribute, to the Internet, routes leading to addresses must distribute, to the Internet, routes leading to addresses
that are within the VPN. This is completely independent of any that are within the VPN. This is completely independent of any
of the route distribution procedures described in this of the route distribution procedures described in this
document. The internal structure of the VPN will in general document. The internal structure of the VPN will in general
not be visible from the Internet. not be visible from the Internet; such routes would simply lead
to the non-VRF interface that attaches to the VPN's Internet
gateway.
In this model, there is no exchange of routes between a PE In this model, there is no exchange of routes between a PE
router's Internet forwarding table and any of its VRFs. VPN router's default forwarding table and any of its VRFs. VPN
route distribution procedures and Internet route distribution route distribution procedures and Internet route distribution
procedures are completely independent. procedures are completely independent.
Note that although some sites of the VPN use a VRF interface to Note that although some sites of the VPN use a VRF interface to
communicate with the Internet, ultimately all packets to/from communicate with the Internet, ultimately all packets to/from
the Internet traverse a non-VRF interface before the Internet traverse a non-VRF interface before
leaving/entering the VPN, so we refer to this as "non-VRF leaving/entering the VPN, so we refer to this as "non-VRF
Internet Access". Internet Access".
Note that the PE router to which the non-VRF interface attaches
does not necessarily need to maintain all the Internet routes
in its default forwarding table. The default forwarding table
could have as few as one route, "default", which leads to
another router (probably an adjacent one) which has the
Internet routes. A variation of this scheme is to tunnel
packets received over the non-VRF interface from the PE router
to another router, where this other router maintains the full
set of Internet routes.
2. Some VPNs may obtain Internet access via a VRF interface ("VRF 2. Some VPNs may obtain Internet access via a VRF interface ("VRF
Internet Access"). If a packet is received by a PE over a VRF Internet Access"). If a packet is received by a PE over a VRF
interface, and if the packet's destination address does not interface, and if the packet's destination address does not
match any route in the VRF, then it may be matched against the match any route in the VRF, then it may be matched against the
PE's Internet forwarding table. If a match is made there, the PE's default forwarding table. If a match is made there, the
packet can be forwarded natively through the backbone to the packet can be forwarded natively through the backbone to the
Internet, instead of being forwarded by MPLS. Internet, instead of being forwarded by MPLS.
In order for traffic to flow natively in the opposite direction In order for traffic to flow natively in the opposite direction
(from Internet to VRF interface), some of the routes from the (from Internet to VRF interface), some of the routes from the
VRF must be exported to the Internet forwarding table. VRF must be exported to the Internet forwarding table.
Needless to say, any such routes must correspond to globally Needless to say, any such routes must correspond to globally
unique addresses. unique addresses.
In this scheme, the default forwarding table might have the
full set of Internet routes, or it might have a little as a
single default route leading to another router which does have
the full set of Internet routes in its default forwarding
table.
3. Suppose the PE has the capability to store "non-VPN routes" in 3. Suppose the PE has the capability to store "non-VPN routes" in
a VRF. If a packet's destination address matches a "non-VPN a VRF. If a packet's destination address matches a "non-VPN
route", then the packet is transmitted natively, rather than route", then the packet is transmitted natively, rather than
being transmitted via MPLS. If the VRF contains a non-VPN being transmitted via MPLS. If the VRF contains a non-VPN
default route, all packets for the public Internet will match default route, all packets for the public Internet will match
it, and be forwarded natively to the default route's next hop. it, and be forwarded natively to the default route's next hop.
At that next hop, the packets' destination addresses will be At that next hop, the packets' destination addresses will be
lookup up in the Internet forwarding table, and may match more looked up in the default forwarding table, and may match more
specific routes. specific routes.
This technique would only be available if none of the CE This technique would only be available if none of the CE
routers is distributing a default route. routers is distributing a default route.
4. It is also possible to obtain Internet access via a VRF 4. It is also possible to obtain Internet access via a VRF
interface by having the VRF contain the Internet routes. interface by having the VRF contain the Internet routes.
Compared with model 2, this eliminates the second lookup, but Compared with model 2, this eliminates the second lookup, but
it has the disadvantage of requiring the Internet routes to be it has the disadvantage of requiring the Internet routes to be
replicated in each such VRF. replicated in each such VRF.
If this technique is used, the SP may want to make its If this technique is used, the SP may want to make its
interface to the Internet be a VRF interface, and to use the interface to the Internet be a VRF interface, and to use the
techniques of section 4 to distribute Internet routes, as VPN- techniques of section 4 to distribute Internet routes, as VPN-
IPv4 routes, to other VRFs. IPv4 routes, to other VRFs.
It should be clearly understood that by default, there is no exchange It should be clearly understood that by default, there is no exchange
of routes between a VRF and an Internet forwarding table. This is of routes between a VRF and the default forwarding table. This is
done ONLY upon agreement between a customer and a SP, and only if it done ONLY upon agreement between a customer and a SP, and only if it
suits the customer's policies. suits the customer's policies.
12. Management VPNs 12. Management VPNs
This specification does not require that the sub-interface connecting This specification does not require that the sub-interface connecting
a PE router and a CE router be a "numbered" interface. If it is a a PE router and a CE router be a "numbered" interface. If it is a
numbered interface, this specification allows the addresses assigned numbered interface, this specification allows the addresses assigned
to the interface to come from either the address space of the VPN or to the interface to come from either the address space of the VPN or
the address space of the SP. the address space of the SP.
skipping to change at page 31, line 7 skipping to change at page 32, line 16
- attach T2 to addresses assigned to each end of its VRF - attach T2 to addresses assigned to each end of its VRF
interfaces. interfaces.
If a particular VRF interface attaches to the SP's Network Management If a particular VRF interface attaches to the SP's Network Management
system, then that VRF is configured to attach T1 to the address of system, then that VRF is configured to attach T1 to the address of
that system, and to import routes that have T2 attached to them. that system, and to import routes that have T2 attached to them.
13. Security 13. Security
13.1. Data Plane
By security in the "data plane", we mean protection against the
following possibilities:
- Packets from within a VPN travel to a site outside the VPN, other
than in a manner consistent with the policies of the VPN.
- Packets from outside a VPN enter one of the VPN's sites, other
than in a manner consistent with the policies of the VPN.
Under the following conditions: Under the following conditions:
1. labeled packets are not accepted by backbone routers from 1. a backbone router does not accept labeled packets over a
untrusted or unreliable sources, unless it is known that such particular data link, unless it is known that that data link
packets will leave the backbone before the IP header or any attaches only to trusted systems, or unless it is known that
labels lower in the stack will be inspected, and such packets will leave the backbone before the IP header or
any labels lower in the stack will be inspected, and
2. labeled VPN-IPv4 routes are not accepted from untrusted or 2. labeled VPN-IPv4 routes are not accepted from untrusted or
unreliable sources, unreliable routing peers,
the security provided by this architecture is virtually identical to 3. no successful attacks have been mounted on the control plane,
that provided to VPNs by Frame Relay or ATM backbones.
the data plane security provided by this architecture is virtually
identical to that provided to VPNs by Frame Relay or ATM backbones.
If the devices under the control of the SP are properly configured,
data will not enter or leave a VPN unless authorized to do so.
Condition 1 above can be stated more precisely. One should discard a
labeled packet received from a particular neighbor unless one of the
following two conditions holds:
- the packet's top label has a label value which the receiving
system has distributed to that neighbor, or
- the packet's top label has a label value which the receiving
system has distributed to a system beyond that neighbor (i.e.,
when it is known that the path from the system to which the label
was distributed to the receiving system may be via that
neighbor).
Condition 2 above is of most interest in the case of inter-provider
VPNs (see section 10). For inter-provider VPNs constructed according
to scheme b) of section 10, condition 2 is easily checked. (The
issue of security when scheme c) of section 10 is used is for further
study.)
It is worth noting that the use of MPLS makes it much simpler to It is worth noting that the use of MPLS makes it much simpler to
provide this level of security than would be possible if one provide data plane security than might be possible if one attempted
attempted to use some form of IP tunneling in place of the MPLS outer to use some form of IP tunneling in place of the MPLS outer label.
label. It is a simple matter to refuse to accept a labeled packet It is a simple matter to have one's border routers refuse to accept a
unless the first of the above conditions applies to it. It is rather labeled packet unless the first of the above conditions applies to
more difficult to configure a router to refuse to accept an IP packet it. It is rather more difficult to configure a router to refuse to
if that packet is an IP tunnelled packet which is going to a "wrong" accept an IP packet if that packet is an IP tunnelled packet whose
place. destination address is that of a PE router; certainly this is not
impossible to do, but it has both management and performance
implications.
Note that if the PE routers support any "MPLS in IP" or "MPLS in GRE"
or similar encapsulations, security is compromised unless either any
such packets are filtered at the borders, or else some acceptable
means of authentication (e.g., IPsec authentication) is carried in
the packet itself.
In the case where a number of CE routers attach to a PE router via a
LAN interface, to ensure proper security, one of the following
conditions must hold:
1. All the CE routers on the LAN belong to the same VPN, or
2. A trusted and secured LAN switch divides the LAN into multiple
VLANs, with each VLAN containing only systems of a single VPN;
in this case the switch will attach the appropriate VLAN tag to
any packet before forwarding it to the PE router.
Cryptographic privacy is not provided by this architecture, nor by
Frame Relay or ATM VPNs. These architectures are all compatible with
the use of cryptography on a CE-CE basis, if that is desired.
The use of cryptography on a PE-PE basis is for further study.
13.2. Control Plane
The data plane security of the previous section depends on the
security of the control plane. To ensure security, neither BGP nor
LDP connections should be made with untrusted peers. The TCP/IP MD5
authentication option should be used with both these protocols. The
routing protocol within the SP's network should also be secured in a
similar manner.
13.3. Security of P and PE devices
If the physical security of these devices is compromised, data plane
security may also be compromised.
The usual steps should be take to ensure that IP traffic from the
public Internet cannot be used to modify the configuration of these
devices, or to mount Denial of Service attacks on them.
14. Quality of Service 14. Quality of Service
Although not the focus of this paper, Quality of Service is a key Although not the focus of this paper, Quality of Service is a key
component of any VPN service. In MPLS/BGP VPNs, existing L3 QoS component of any VPN service. In MPLS/BGP VPNs, existing L3 QoS
capabilities can be applied to labeled packets through the use of the capabilities can be applied to labeled packets through the use of the
"experimental" bits in the shim header [MPLS-ENCAPS], or, where ATM "experimental" bits in the shim header [MPLS-ENCAPS], or, where ATM
is used as the backbone, through the use of ATM QoS capabilities. is used as the backbone, through the use of ATM QoS capabilities.
The traffic engineering work discussed in [MPLS-RSVP] is also The traffic engineering work discussed in [MPLS-RSVP] is also
directly applicable to MPLS/BGP VPNs. Traffic engineering could even directly applicable to MPLS/BGP VPNs. Traffic engineering could even
skipping to change at page 33, line 22 skipping to change at page 36, line 14
18. Authors' Addresses 18. Authors' Addresses
Eric C. Rosen Eric C. Rosen
Cisco Systems, Inc. Cisco Systems, Inc.
250 Apollo Drive 250 Apollo Drive
Chelmsford, MA, 01824 Chelmsford, MA, 01824
E-mail: erosen@cisco.com E-mail: erosen@cisco.com
Yakov Rekhter Yakov Rekhter
Cisco Systems, Inc. Juniper Networks
170 Tasman Drive 1194 N. Mathilda Avenue
San Jose, CA, 95134 Sunnyvale, CA 94089
E-mail: yakov@cisco.com E-mail: yakov@juniper.net
Tony Bogovic Tony Bogovic
Telcordia Technologies Telcordia Technologies
445 South Street, Room 1A264B 445 South Street, Room 1A264B
Morristown, NJ 07960 Morristown, NJ 07960
E-mail: tjb@research.telcordia.com E-mail: tjb@research.telcordia.com
Stephen John Brannon Stephen John Brannon
Swisscom AG Swisscom AG
Postfach 1570 Postfach 1570
skipping to change at page 34, line 19 skipping to change at page 37, line 4
2, av. P. Marzin 2, av. P. Marzin
22307 Lannion 22307 Lannion
E-mail: marco.carugi@cnet.francetelecom.fr E-mail: marco.carugi@cnet.francetelecom.fr
Christopher J. Chase Christopher J. Chase
AT&T AT&T
200 Laurel Ave 200 Laurel Ave
Middletown, NJ 07748 Middletown, NJ 07748
USA USA
E-mail: chase@att.com E-mail: chase@att.com
Ting Wo Chung Ting Wo Chung
Bell Nexxia Bell Nexxia
181 Bay Street 181 Bay Street
Suite 350 Suite 350
Toronto, Ontario Toronto, Ontario
M5J2T3 M5J2T3
E-mail: ting_wo.chung@bellnexxia.com E-mail: ting_wo.chung@bellnexxia.com
Eric Dean Eric Dean
Global One Global One
12490 Sunrise Valley Dr. 12490 Sunrise Valley Dr.
Reston, VA 20170 USA Reston, VA 20170 USA
E-mail: edean@gip.net E-mail: edean@gip.net
Jeremy De Clercq Jeremy De Clercq
Alcatel Network Strategy Group Alcatel Network Strategy Group
Francis Wellesplein 1 Francis Wellesplein 1
2018 Antwerp, Belgium 2018 Antwerp, Belgium
E-mail: jeremy.declercq@alcatel.be E-mail: jeremy.de_clercq@alcatel.be
Luyuan Fang
AT&T
IP Backbone Architecture
200 Laurel Ave.
Middletown, NJ 07748
E-mail: luyuanfang@att.com
Paul Hitchin Paul Hitchin
BT BT
BT Adastral Park BT Adastral Park
Martlesham Heath, Martlesham Heath,
Ipswich IP5 3RE Ipswich IP5 3RE
UK UK
E-mail: paul.hitchen@bt.com E-mail: paul.hitchen@bt.com
Manoj Leelanivas Manoj Leelanivas
Juniper Networks, Inc. Juniper Networks, Inc.
skipping to change at page 36, line 16 skipping to change at page 39, line 4
BT Adastral Park BT Adastral Park
Martlesham Heath, Martlesham Heath,
Ipswich IP5 3RE Ipswich IP5 3RE
UK UK
E-mail: adrian.ca.smith@bt.com E-mail: adrian.ca.smith@bt.com
Vijay Srinivasan Vijay Srinivasan
1200 Bridge Parkway 1200 Bridge Parkway
Redwood City, CA 94065 Redwood City, CA 94065
E-mail: vsriniva@cosinecom.com E-mail: vsriniva@cosinecom.com
Alain Vedrenne Alain Vedrenne
SITA EQUANT SITA EQUANT
3100 Cumberland Blvd, Suite 200 3100 Cumberland Blvd, Suite 200
Atlanta, GA, 30339 USA Atlanta, GA, 30339 USA
Email:Alain.Vedrenne@sita.int Email:Alain.Vedrenne@sita.int
Alain.Vedrenne@equant.com Alain.Vedrenne@equant.com
19. References 19. References
[BGP-MP] Bates, Chandra, Katz, and Rekhter, "Multiprotocol Extensions [BGP-MP] Bates, Chandra, Katz, and Rekhter, "Multiprotocol Extensions
for BGP4", June 2000, RFC 2858 for BGP4", June 2000, RFC 2858
[BGP-EXTCOMM] Ramachandra, Tappan, "BGP Extended Communities [BGP-EXTCOMM] Ramachandra, Tappan, "BGP Extended Communities
Attribute", February 2000, work in progress Attribute", January 2001, work in progress
[BGP-ORF] Chen, Rekhter, "Cooperative Route Filtering Capability for [BGP-ORF] Chen, Rekhter, "Cooperative Route Filtering Capability for
BGP-4", March 2000, work in progress BGP-4", November 2000, work in progress
[BGP-RFSH] Chen, "Route Refresh Capability for BGP-4", March 2000, [BGP-RFSH] Chen, "Route Refresh Capability for BGP-4", March 2000,
work in progress RFC 2918
[BGP-RR] Bates and Chandrasekaran, "BGP Route Reflection: An [BGP-RR] Bates and Chandrasekaran, "BGP Route Reflection: An
alternative to full mesh IBGP", RFC 2796, April 2000 alternative to full mesh IBGP", RFC 2796, April 2000
[IPSEC] Kent and Atkinson, "Security Architecture for the Internet [IPSEC] Kent and Atkinson, "Security Architecture for the Internet
Protocol", November 1998, RFC 2401 Protocol", November 1998, RFC 2401
[MPLS-ARCH] Rosen, Viswanathan, and Callon, "Multiprotocol Label [MPLS-ARCH] Rosen, Viswanathan, and Callon, "Multiprotocol Label
Switching Architecture", August 1999, work in progress Switching Architecture", RFC 3031, January 2001
[MPLS-BGP] Rekhter and Rosen, "Carrying Label Information in BGP4", [MPLS-BGP] Rekhter and Rosen, "Carrying Label Information in BGP4",
January 2000, work in progress January 2001, work in progress
[MPLS-LDP] Andersson, Doolan, Feldman, Fredette, Thomas, "LDP [MPLS-LDP] Andersson, Doolan, Feldman, Fredette, Thomas, "LDP
Specification", October 1999, work in progress Specification", RFC 3036, January 2001
[MPLS-ENCAPS] Rosen, Rekhter, Tappan, Farinacci, Fedorkow, Li, and [MPLS-ENCAPS] Rosen, Rekhter, Tappan, Farinacci, Fedorkow, Li, and
Conta, "MPLS Label Stack Encoding", October 1999, work in progress Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001
[MPLS-RSVP] Awduche, Gan, Li, Swallow, and Srinavasan, "Extensions to [MPLS-RSVP] Awduche, Berger, Gan, Li, Srinavasan, Swallow,
RSVP for LSP Tunnels", March 2000, work in progress "Extensions to RSVP for LSP Tunnels", August 2000, work in progress
[PASTE] Li and Rekhter, "A Provider Architecture for Differentiated [PASTE] Li and Rekhter, "A Provider Architecture for Differentiated
Services and Traffic Engineering (PASTE)", RFC 2430, October 1998. Services and Traffic Engineering (PASTE)", RFC 2430, October 1998.
[VPN-OSPF] Rosen and Psenak, "OSPF as the PE/CE Protocol in BGP/MPLS
VPNs", February 2001, work in progress
20. Full Copyright Statement 20. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
 End of changes. 60 change blocks. 
108 lines changed or deleted 277 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/