One document matched: draft-casey-vpn-extns-00.txt
Internet Draft An extended IP VPN Architecture November 1998
VPN BOF L. Casey
Internet Draft Nortel Networks
Expiration Date: May 1999 November 1998
An extended IP VPN Architecture
<draft-casey-vpn-extns-00.txt>
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as "work
in progress."
To learn the current status of any Internet-Draft, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net
(Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
Coast), or ftp.isi.edu (US West Coast).
Abstract
This Internet Draft extends the framework for IP VPN's, as, for
example, described by Heinanen et al.[1] and Gleeson et al [2],
to include the concept of VPN Areas. VPN areas relate to the
scoping of the mechanisms (membership dissemination, tunneling
etc.) used to provide IP VPN service. VPN areas are a
partitioning of the shared service provider's network. In
general, all sites within a VPN area are one tunneled hop from
each other, but multiple tunneled hops will be required for
traffic between sites served by different VPN areas.
Two reasons why Service Providers might partition their IP
network into areas in support of VPN's are to achieve
scalability, and to match administrative domain. VPN areas also
Casey [Page 1]
Internet Draft An extended IP VPN Architecture November 1998
facilitate the use of different IP VPN mechanisms in different
parts of the network. There are multiple proposals for tunnel
technology and discovery mechanisms for IP VPN's. The VPN area
concept allows them to co-exist in one provider's network as
well as smoothing migration to new mechanisms.
This draft also examines the impact that VPN areas have on the
IP VPN framework mechanisms described in [2]. The conclusion
reached is that the best mechanism for intra-VPN reachability
dissemination is a full routing protocol run by Virtual Routers.
Table of Contents
1 Introduction 3
1.1 IP VPNs 3
1.2 IP VPN generic operations 4
1.3 VPN areas 4
1.4 Outline 5
1.5 Terminology and abbreviations 5
2 VPN Areas and VPN Border Routers 6
2.1 Motivation 6
2.2 VPN Border Routers - VBR's 8
2.2.1Types of VBR 9
3 Configuring VPN areas 10
3.1 Setting VPN-area scopes. 10
3.2 The VR mechansism 10
3.2.1Gateway VBR Forwarding Behavior 10
3.2.2Constructing and Maintaining Forwarding Tables 11
3.3 VPN-ID scope 12
4 Operation of multi-VPN area IP VPN's 12
4.1 VPN membership configuration and dissemination 12
4.1.1Automating gateway VBR configuration 13
4.2 Tunnel establishment 13
4.3 Stub Link Reachability information 14
4.4 Intra VPN reachability information 14
4.5 Summary of new IP VPN Configuration 15
5 Summary and Benefits of extended IP VPN's 15
5.1 Summary 15
5.2 Provider value to the enterprise 16
5.3 Provider network protection 17
5.4 VPN Isolation 17
5.5 Engineerable 17
5.6 Scaling Factors 17
6. Security Considerations 18
6.1 User Data Privacy 18
6.2 Service Provider Security 19
7. Intellectual Property Considerations 19
8. References 20
9. Author's Address 20
Casey [Page 2]
Internet Draft An extended IP VPN Architecture November 1998
1.Introduction
1.1 IP VPNs
An IP Virtual Private Network (IP VPN) is a service, offered by
a (service) provider to an enterprise customer. An IP VPN
interconnects geographically dispersed enterprise IP networks
over the provider's shared network facilities. The general goal
of a VPN is to offer equivalent privacy and performance to
leased line interconnectivity while realizing substantial
deployment efficiencies because the network infrastructure is
shared by many enterprises. In this draft we use the term
"provider" to cover the public carrier, network operator or ISP,
or consortiums thereof, who operate the shared network
infrastructure and offer the IP VPN service. We call the shared
network structure the base network of the VPN.
In [1] and [2], Heinanen and Gleeson et al. provide a definition
of a service, which they call an Virtual Private Routed Network
(VPRN) service. A quick summary of the properties of VPRN
service are:
1) data privacy
2) address isolation
3) intra VPN routing
4) implemented on IP based base networks
The first two of these properties are general to all VPN's. It
is the third of these properties, intra VPN routing, that makes
a VPN specifically an IP VPN. An IP VPN service includes the
routing of enterprise IP traffic by the provider, steering it
over the wide area based upon its IP destination address.
Benefits of using an IP VPN service include simplified
configuration of enterprise edge routers [2], and exploiting the
ubiquity of IP service for access to enterprise sites.
This draft does not assume the fourth property of VPRN's listed
above. While base networks based upon IP have unrivalled
geographical extent, one intent of introducing the VPN area
concept is to allow an IP VPN service to be supported over a
concatenated mixture of diverse base networks. In [2] two other
types of VPN that use an IP based network infrastructure are
also described. Virtual Private Dial Networks (VPDN's) offer, in
effect, a PPP transport service. In a Virtual Private LAN
Segment (VPLS) service, the provider offers a wide area
Casey [Page 3]
Internet Draft An extended IP VPN Architecture November 1998
emulation of a LAN segment, which may support multiple
enterprise network protocols. While this draft does not consider
the implementation of either of these services, it does consider
how a provider might augment an IP VPN service with VPDN or VPLS
service (see sec 2.2.1).
1.2 IP VPN generic operations
There are a number of generic operations that need to be
performed in order to provide IP VPN service.
1) VPN membership discovery is the process by which
provider nodes learn of the other nodes serving the
same VPN.
2) Tunnel establishment is the process of providing
private paths across the base network for each
enterprise customer's data.
3) Offering an IP Service means that the provider's
network must interact with the enterprise customer's
routing regime. The stub link reachability information
exchange is the operation where nodes in the
enterprise network exchange reachability information
with nodes in the provider's network.
4) The provider nodes serving a particular VPN need to
propagate the individual site reachability information
to each other, so that they can route the enterprise
packets across the providers network. This is the
Intra VPN reachability exchange.
[1] and [2] list a plethora of choices of mechanism to implement
the IP VPN operations. This Internet Draft assumes that reader
is familiar with [1] and/or [2]. Consideration of base networks
other than IP expands the set of choices even further. For a
particular IP VPN to be deployed each of these choices have to
be nailed down. This is a problem as IP VPN technology is
immature today. The market is likely to see different choices
deployed in different networks. A major motivation for
introducing the concept of VPN areas is to define how an IP VPN
can be constructed to operate over a mixture of base network
choices, tunneling mechanism choices and VPN generic operation
mechanism choices.
1.3 VPN areas
VPN Areas are a partitioning of Provider's network
infrastructure. Within a VPN Area the various VPN mechanisms
(base network, tunneling, VPN membership discovery etc.) are the
same. Between VPN areas the VPN mechanisms can be different. One
Casey [Page 4]
Internet Draft An extended IP VPN Architecture November 1998
goal of VPN areas is to allow an IP VPN Service Provider to
partition his base network based upon IP VPN implementation
choices. For example, an Service Provider may have MPLS in the
backbone part of his network but not in all regional networks.
He can operate a MPLS based IP VPN area in the backbone, as
described in this draft, while using other forms of IP VPN
technology (e.g. IP over LANE VLAN's) in the regional VPN areas.
The VPN area concept facilitates migration of VPN technologies.
It can also be used to reflect VPN service scoping rules into
the network, even when the same VPN mechanisms are deployed in
all areas. Service scoping can be based upon administrative
boundaries or can be introduced to address scaling problems.
1.4 Outline
The purpose of this Internet draft is to introduce and motivate
the concept of VPN areas and to show how the VPN generic
operations can be extended to multi VPN area networks.
Section 2 of this Internet Draft starts with the motivations for
deploying VPN areas. The concept of a VPN edge device is
generalized to VPN Border Router (VBR). Not only are VBR's
interposed between enterprise sites and the providers network
but they can also be situated between, and straddle, VPN areas.
Section 3 looks at how VPN areas might be configured and at the
scoping of VPN-ID's. As well, it introduces the Virtual Router
(VR) mechanism as the most straightforward way of managing the
forwarding of traffic between VPN areas.
Building on this, section 4 examines at how the operations of an
IP VPN are modified when there are multiple VPN areas. In
particular, the VPN membership discovery operation and the intra
VPN reachability exchange mechanism are impacted. For multi-VPN
deployments, this Internet Draft advocates the use of full
routing protocols for the exchange of intra VPN reachability
information. Section 5 summarizes the properties of multi-VPN
area IP VPN's and Section 6 addresses security considerations.
1.5 Terminology and abbreviations
In addition to the terminology of [1] and [2] the following
terms are introduced
Base network The provider's network upon which an IP VPN
service is built
Peer VR's VR's that serve the same IP VPN within the same
VPN area.
Casey [Page 5]
Internet Draft An extended IP VPN Architecture November 1998
Stub link Dedicated IP link between a VBR and an
enterprise site
VBR VPN Border Router
VR Virtual Router. An instantiation in a VBR of a
routing process dedicated to, and working within
the address space of, an IP VPN
VPN Area A partition of the base network. Within a VPN
Area the various VPN mechanisms (tunneling, VPN
membership discovery etc.) are the same.
2 VPN Areas and VPN Border Routers
2.1 Motivation
Just as the original Internet routing protocols were modified to
partition networks into areas (OSPF) and Autonomous Systems
(BGP), to cater for scalability and administrative boundaries
respectively, similar concerns motivate the partitioning of
networks that provide IP VPN service. Figure 1 shows a partition
of a network into 5 VPN areas. (Note that, for the time being at
least, we call all partitions "areas" irrespective of the
motivation that lead to their construction).
+---------------------------+----------------------------+
/ | \
/ | \
+ | VPN Area 2 +
| | |
| VPN Area 1 | |
| | |
| ------+------ |
| / \ |
| / \ |
| / \ |
+--------------------+ VPN Area 0 +---------------------+
| \ / |
| \ / |
| \ / |
| ------+------ |
| VPN Area 4 | |
| | VPN Area 3 |
+ | +
\ | /
\ | /
+---------------------------+----------------------------+
Figure 1: VPN Area
Casey [Page 6]
Internet Draft An extended IP VPN Architecture November 1998
One motivation for VPN Areas is to cater for administrative
boundaries. While a group of network operators may band together
to offer an IP VPN service, each may wish to retain control of
what enterprises they serve. Analogous to BGP, they may
instigate transit and peering agreements so as to offer a
seamless IP VPN service within their combined geographical area
of coverage. However, some enterprises may only want IP VPN
service in a single VPN area in return, presumably, the operator
of that area would provide the service for a lower tariff than a
wider scoped service. In addition to being a service scoping
mechanism, VPN areas are also a technology scoping mechanism.
The VPN area mechanism will allow each of the network operators
may operate different base networks, tunnel mechanisms, etc.
within their own VPN areas and still provide a homogeneous
combined IP VPN Service.
Geographic service scoping may also be the motivation for a
single provider to introduce VPN areas. For example, a
transnational service provider may establish a VPN area in each
country served to support charging enterprises more for
international traffic than traffic that stays inside the
country.
QoS Scoping is another motivation for VPN areas. A service
provider may wish to offer IP VPN service level agreements
relating to delay, packet loss etc., where the parameters are
different for different VPN Areas. A particularly important
instance of this is where the provider treats his own network as
one VPN area and the rest of the Internet as another area. For
IP VPN traffic confined to his own network, the provider may be
able to offer fairly tight service guarantees, by dint of the
technologies employed, network topology and traffic engineering.
An enterprise may have some remote sites that it would be
impractical to connect directly to the provider's network. The
provider can still make these sites part of an IP VPN, by
setting up tunnels (probably IPSec) to them over the Internet.
There cannot, of course, be any performance guarantees for the
traffic traversing the Internet.
VPN areas also provide a framework for addressing traffic
engineering and scalability concerns. This is elaborated upon in
section 5.
Finally, a major motivation for VPN areas is that they scope IP
VPN implementations. As noted above, to implement an IP VPN
service choices have to be made on base network technology,
tunnel mechanism, VPN membership dissemination mechanism and
Casey [Page 7]
Internet Draft An extended IP VPN Architecture November 1998
intra VPN reachability information exchange mechanism. At this
stage in IP VPN maturity, there are multiple proposals for each
mechanism even for the same base network. E.g. [3],[4],[5],[6]
and [7]are differing proposals for MPLS as a base network.
2.2 VPN Border Routers - VBR's
A VPN Border Router or VBR is a node at the border of a VPN
area. Each VPN area contains both VBR and plain (non-edge)
nodes, interconnected by links. All proposals for IP VPN's
distinguish the first IP device in the path between the
enterprise's network and the provider's shared network.
Unfortunately, there is no common term for it. In this draft we
use the term edge VBR. In multi-VPN area networks, VBR's also
are the gateway devices between VPN areas. VBR's serve as tunnel
ingress and egress points for enterprise IP traffic.
Figure 2 shows a path between two enterprise sites that
traverses two VPN areas. Each VPN area is bordered by VPN's and
contains other nodes that operate as part of the base network
but are unaware of the IP VPN service because enterprise traffic
is tunneled through them. (Note that we use tunnel in a very
loose sense here to mean any mechanism that encapsulates
enterprise IP packets and carries a demuliplexing identifier
with them. VBR's use the demuliplexing identifier to separate
out IP packets of the different VPN's. In our loose use of the
term, a layer 2 virtual circuit is a tunnel).
+----+ +---+ +---+ +---+ +---+ +---+ +---+ +----+
|EntR|----|VBR|---|BNN|--|BNN|---|VBR|---|BNN|---|VBR|----|EntR|
+----+ +---+ +---+ +---+ +---+ +---+ +---+ +----+
<Stb> <-----Tunnel------> <---Tunnel--> <Stb>
<--------VPN Area-------> <---VPN Area---->
EntR = Enterprise Router VBR = VPN Border Router
Stb = Stub Link BNN = Base Network Node
Figure 2: IP VPN Path over 2 VPN Areas
Enterprise sites interface to the provider's network over a stub
link from an enterprise router (EntR). (Very small sites may not
have an enterprise router but, rather, consist of a single LAN
subnet, i.e. an Ethernet, with a VBR serving as a default
router).
Some larger Enterprise sites may be "not so stubby". They may
have multiple links, from the same or different enterprise
routers, to the same VBR or to different VBR's. [2] contains a
discussion on the implications of this. An additional case
Casey [Page 8]
Internet Draft An extended IP VPN Architecture November 1998
arising from the introduction of VPN areas is when an enterprise
site has stub links to VBR's in different VPN areas
2.2.1 Types of VBR
One categorization of VBR's is whether they serve a single VPN
or multiple VPN's. Exclusive VBR's may be located at the
enterprise site or at a POP. Shared VBR's would always be
located at a provider POP. Note that a VPN area can contain both
shared and exclusive VBR's: it is entirely a provider's choice
as to whether he deploys all POP based shared VBR's, customer
located exclusive VBR's or a mixture of both.
A VBR can fulfill edge, gateway or special functions.
Edge VBR: First IP device between enterprise site and the
provider's network. It serves one or more sites of one
or more enterprises.
Gateway VBR: A VBR that are attached to two or more VPN
areas. It straddles the VPN areas and is able to
forward enterprise traffic between VPN areas. (In
general a gateway VBR's will de-encapsulate traffic
from the incoming tunnel and re-encapsulate in a
tunnel appropriate for the outgoing VPN area. If the
two VPN areas share the same VPN mechanisms the de-
encapsulation may not be necessary)
Special functions include:
Internet Attachment: Enterprise access to the Internet may be
offered as an extension of IP VPN service and be
implemented by a special VBR that has firewall (and,
if needed, NAT) functions.
VPDN Attachment: Enterprise dial-in users may be connected
directly to the IP VPN, instead of terminating on a
home gateway at a particular enterprise site. To
implement this service, special function VBR's may
provide a per enterprise RAS function, or a per
enterprise home gateway function.
VPLS Interworking: As noted in [2], there are many
similarities between Virtual Private LAN Subnet (VPLS)
service and IP VPN service. A provider may offer both;
in particular some enterprise sites may connect to a
VBR over virtual private LAN subnet (or even a real
LAN subnet). Minor changes in edge VBR functionality
are required to handle this kind of interworking.
A VBR need not be dedicated to only one of these functions. We
say that a VBR serves a particular VPN if it terminates one or
Casey [Page 9]
Internet Draft An extended IP VPN Architecture November 1998
more stub links to enterprise sites of that VPN. A gateway VBR
that straddles two or more VPN areas serves a particular VPN if
it forwards traffic for that VPN between the areas. It is a
generally desirable goal that other (internal) nodes in the
provider's network are not aware of individual VPN's.
3 Configuring VPN areas
This section addresses general configuration issues for IP VPNs
that span multiple VPN areas. It considers the necessary
uniqueness requirements for VPN-ID's and introduces Virtual
Routers as the mechanism for forwarding traffic between VPN
areas.
3.1 Setting VPN-area scopes.
A Provider or consortium wishing to offer IP VPN service using
multiple VPN areas has first to decide on the basis for
partitioning their network and then configure VBR's to realize
the desired VPN areas. If the basis for VPN areas relates to
base network technology then the partitioning process will be
straightforward: gateway VBR's will be deployed with separate
interfaces to two or more base networks.
If the deployment of multiple VPN areas is being driven by
scalability or administrative domain concerns, and if the base
network is common to all the VPN areas, then particular care
will be needed in configuring the interfaces of gateway VBR's.
An interface's type or network address will not be enough to
determine which VPN area it participates in. Introducing a VPN-
area Identifier to facilitate configuring gateway VBR's is an
area for further study.
3.2 The VR mechansism
Isolation of the IP addresses within a VPN is equivalent to each
VPN having its own independent IP Address space. Thus, we talk
about the address space of enterprise E1 being independent from
address space E2 (enterprise E2's address space). When the base
network is an IP network, one needs to be particularly clear
when talking about an IP address as to what address space it is
part of: that of the base network or that of an enterprise IP
network.
3.2.1 Gateway VBR Forwarding Behavior
Gateway VBR's are going to serve large numbers of VPN. Within
each VBR there needs to be an instance of a forwarding table for
each IP VPN supported by that VBR. The forwarding control
process operates in the enterprise address space. When packets
arrives at a gateway VBR the VBR will select the correct
Casey [Page 10]
Internet Draft An extended IP VPN Architecture November 1998
forwarding table based upon the identity of the incoming tunnel.
The forwarding table will determine on what tunnel packets
should be sent out (suitably encapsulated for the tunnel
selected).
3.2.2 Constructing and Maintaining Forwarding Tables
There has been basically two approaches advocated for
dynamically constructing and maintaining forwarding tables in IP
VPN's. [4] advocates that the Intra VPN reachability information
be piggy backed on routing exchanges taking place in the base
network, while [3] and [6] advocate the use of virtual routers.
A virtual router (VR) is simply a forwarding control process in
a VBR, dedicated to one IP VPN. It participates directly in
routing information exchanges with other VR's dedicated to the
same VPN, over tunnels of that VPN. The routing exchanges relate
only to the IP address space of the enterprise customer. The
routing regime used can be specific to individual VPN's (e.g.
small one might use RIP, while larger ones use OSPF).
Notes on VR's:
1) Static/default routing (i.e. administratively configured
forwarding tables) is considered an acceptable routing
regime, particularly appropriate for small VPN's.
2) The VR definition implies every link interface (stub or
tunnel end point) or the VR itself has an IP address in
the enterprise address space.
3) A VR may use different routing protocols on each of its
interfaces. It could end up exchanging routing
information with all of a customer's enterprise routers
(e.g. if the entire enterprise intranet was one OSPF
area). Alternatively the routing regime on stub links
could be isolated to just the edge VBR and the attached
Enterprise edge router, see [2].
4) When the tunnel topology within a VPN area is a full
mesh a VR sees the VR's of all other VBR's in its VPN
area as neighbors. From the perspective of the IP VPN
routing, all its VR's in a VPN area are a single hop
from each other. VR's in different VPN areas are two or
more hops away.
Because we want to support an arbitrary topology and
interconnect of VPN-areas, our preference is to use virtual
routers as the mechanism for constructing and maintaining
forwarding tables in VBR's. However the power of the VPN area
concept is such that, within one IP VPN service, it would permit
one VPN area to piggyback intra VPN reachability information on
base network routing exchanges and another area to use virtual
Casey [Page 11]
Internet Draft An extended IP VPN Architecture November 1998
routers. It should be noted though, that piggybacking may
require modifying routing protocols and that there are scoping
issues to address (see [2] again), while VR's run their routing
protocols unmodified and secure.
3.3 VPN-ID scope
There are two different reasons why an IP VPN needs to be
identified. The first of these relates to the administrative
identification an IP VPN service instantiation provided for an
enterprise. Generally speaking, it is desirable that this
identification be globally unique – we call it the global VPN-
ID. A global VPN ID will be 32 bits or more in size, see [2].
(Strictly speaking, this form of VPN-ID needs only to be unique
within the provider or group of carriers offering IP VPN service
but given the propensity of providers to merge it is wise to
make it globally unique.
The other use of a VPN-ID is in the VPN membership dissemination
operation. Typically, this form of VPN-ID, which we call the
local VPN-ID, has only to be unique within a VPN area. There
have been several proposals, [3][6], that this be a 16 bit
quantity. To facilitate re-engineering of VPN areas we propose
that all 16 bit VPN-ID's be unique within an AS. (Prepending the
AS number to a local VPN-ID of the first provider of a
particular IP VPN service instance is one way to generate a 32
bit global VPN-ID).
4 Operation of multi-VPN area IP VPN's
Section 1.2 outlined a number of generic operations that need to
be performed before an IP VPN can forward IP traffic between
enterprise sites. This section examines how these operations are
affected by the introduction of VPN areas.
4.1 VPN membership configuration and dissemination
A provider whose base network spans multiple VPN areas will need
to scope the IP VPN service offered a particular enterprise:
will it be confined to a single area or span multiple VPN areas?
Spanning multiple VPN areas is enabled by configuring VR's for
the new IP VPN in gateway VBR's. These VR's will be informed of
the routing regime they are to participate in and they will need
a router number and/or IP address assignment from the enterprise
IP space. If, as should be done, there is to be chain of trust
between the VR's dedicated to the VPN then appropriate
credentials have also to be administered. Finally, the VR will
be configured with a local VPN-ID for use in each VPN area in
which it is configured to operate.
Casey [Page 12]
Internet Draft An extended IP VPN Architecture November 1998
Once this configuration has been done, the gateway VBR is able
to participate in the VPN membership dissemination process with
the other VBR's in each of the VPN areas to which it is
attached. The VPN membership dissemination mechanism may be
different in each VPN area. Nevertheless, the end result is that
each VR dedicated to a particular VPN (i.e. assigned the same
VPN-ID) has enough information to establish tunnels to its peer
VR's in each of the VPN areas to which it is attached.
4.1.1 Automating gateway VBR configuration
At this stage in developing the VPN area concept, it is assumed
that the provider will use the required configuration of gateway
VBR's both as a policy mechanism (to scope a service) and as a
traffic engineering mechanism (splitting the load of multiple
VPN's over multiple gateway VBR's). The general automation of
the process is for further study. One special case stands out
though: a simple topology of a two level hierarchy of a core and
stub VPN areas. Each gateway VBR between stub and core could
cache the VPN membership announcements that it receives on its
stub side and relay them over the core. If there were a matching
VPN-ID from another gateway VBR then both would initiate a VR,
and establish a tunnel between them. The new VRs would also
announce their presence on the stub network to complete the VPN
tunnel connectivity.
4.2 Tunnel establishment
In this proposal, tunnels are only established between VR's
within a VPN area. A different tunneling mechanism choice may be
in effect in each VPN area, depending on the base network. See
[1] to [7] for some of the VPN membership dissemination
mechanisms and tunnel establishment mechanisms that could be
used. As an example, in one VPN area tunnels may be realized by
GRE over an IP base network, and in another tunnels may be
realized by ATM SVC's over an ATM base network.
In general, traffic travelling between VPN areas is forwarded at
the IP layer by VR's in gateway VBR's. However, for individual
base network/tunnel mechanisms, it may be possible to establish
tunnels right through VBR's. [6] provides an example of how this
could be done using the MPLS label distribution protocol for
MPLS tunnels and VPN areas corresponding to MPLS domains.
In the preceding, we have also assumed that within a VPN area
all VR's (for a particular VPN) are fully meshed connected by
tunnels. All enterprise traffic travels across VPN area in a
single tunnel hop. One of the advantages of VR's is that this
assumption can be relaxed, since the VR's are capable of
Casey [Page 13]
Internet Draft An extended IP VPN Architecture November 1998
exchanging routing information and calculating next (tunnel)
hops. Of course, establishing an arbitrary tunnel topology
within a VPN area would require administrative intervention.
4.3 Stub Link Reachability information
The existence of multiple VPN areas should not be directly
visible to the enterprise edge routers, nor should it affect
mechanism for exchanging reachability information between a (VR
in an) edge VBR and the enterprise site. As noted in [2] it is
beneficial for the protocol used to exchange of reachability
information across a stub link to be simple, and for it to be
alterable on an enterprise site by enterprise site basis.
However, VPN areas enable more complex stub link connectivities,
such as multiple links from an enterprise site to different VPN
areas. For "not so stubby" site connectivity, VBR's will have to
push routing hop information to the enterprise routers if loops
and sub optimal forwarding are to be avoided. The most general
mechanism for a VBR to learn the set of address prefixes that
reachable over its stub links, and for the enterprise site to
learn what addresses it should forward over which stub link, is
a full routing protocol. Our position is that, with the common
exception of sites connected by a single stub link and not
having routing backdoors (see [2]), enterprise edge routers and
the VPN VR's should participate in the same routing regime.
4.4 Intra VPN reachability information
VR's dedicated to each IP VPN exchange routing information
exchanges with each other across the entire scope of the IP VPN,
i.e. across multiple VPN areas. The routing exchanges relate
only to the IP address space of the enterprise customer. The
routing information will typically be exchanged over the same
tunnels between VR's used to carry enterprise traffic. The
routing regime used can be specific to individual VPN's (e.g.
small one might use RIP, while larger ones might use use OSPF).
Each VPN area may have a different mechanism for the
dissemination of VPN membership. In general, the existence of
new sites for a VPN is propagated only to the VBR's within an
VPN area. However, other VBR's will learn the reachability
information for the new site through the routing protocol
exchanges of the IP VPN. Information concerning a new enterprise
site will reach gateway VBR's using the mechanisms of the VPN
area to which the site is newly attached. A VR in the gateway
VBR will then convey the new routing information across the VPN
area boundary, to all of its neighbors in other VPN areas
connected to it.
Casey [Page 14]
Internet Draft An extended IP VPN Architecture November 1998
4.5 Summary of new IP VPN Configuration
This section reviews the processes that bring an new IP VPN into
service over a multi-VPN area network.
When a enterprise wants to obtain an IP VPN service from a
provider the provider must first do some configuration. The
provider needs to allocate a VPN-ID and then provision the stub
links between enterprise sites and one or more VBR's. The
provider must instantiate a VR at each VBR that has new IP VPN
stub links terminating on it. This involves assigning the VR an
IP address, or router number, out of the enterprises address
space, and assigning IP addresses for each stub link terminating
on the VR.
In a fully flexible system the VR could be configured to run
separate routing regimes on each stub link, and another one for
the tunnels to peer VR's. The VR would all need to be instructed
on how I should import information between routing regimes. The
choice of routing regime to be used for stub links will probably
have been spelt out in an SLA. For example, an enterprise with
one large corporate site and a modest number of smaller
satellite sites, each with its own /24 subnet, might use
static/default routing for all satellite site stub link
interfaces. RIP could be used between all VR's and between the
large corporate site and the VR(s) to which it is connected.
Assuming the IP VPN service scope is multiple VPN areas, the
provider must choose which gateway VBR's will be used and then
instantiate VR's on them. One this configuration has been
performed and the VR's serving the new IP VPN are in place,
automatic tunnel establishment can proceed in each VPN area.
This results in tunnel meshes within VPN areas and the provider
chosen connectivity between areas.
Assuming that the chosen intra VPN routing protocol links
permits auto-discovery of routers, then each of VR's can
establish a neighbor relationship with its peers and then
exchange enterprise routing information. After this, the VR's
are able to forward enterprise traffic between all sites in the
VPN.
5 Summary and Benefits of extended IP VPN's
5.1 Summary
This Internet Draft presents an extended IP VPN architecture.
The concept of VPN areas is introduced as a partitioning of the
service provider's base network. The definition of a provider
edge device is extended to that of a VPN Border Router (VBR). As
well as interposing between an enterprise site and the core of
Casey [Page 15]
Internet Draft An extended IP VPN Architecture November 1998
the provider's network, a VBR may straddle two or more VPN
areas. In the former usage a VBR is called an edge VBR while in
the latter usage it is a gateway VBR. Specialized VBR's may also
interface to modem pools for provider network support for dial-
in user access to the enterprise networks and firewalls for
network access to the Internet.
Two of the reasons why Service Providers might partition their
IP network into area's in support of VPN's are to achieve
scalability and to match administrative areas. VPN areas also
facilitate the use of different IP VPN technologies in different
parts of the network. There are multiple proposals for tunnel
technology and discovery mechanisms for IP VPN's. The VPN area
concept allows them to co-exist in one provider's network and
smoothes migration to new mechanisms.
VBR's that serve multiple VPN's have been described as
supporting multiple virtual routers (VR's). Each VR participates
in the routing regime of a single IP VPN, and is responsible for
forwarding packets for that VPN within the VBR.
The solution provides the following benefits:
5.2 Provider value to the enterprise
The provider provides IP service within its own network.
Specifically enterprise packets are routed at VBR's within the
carrier network. This reduces the capabilities needed of
enterprise edge routers. CPE based tunneled implementations of
VPN's confine packets to travel on tunnels between enterprise
routers. This requires the enterprise router to support multiple
tunnel interfaces. In very large VPN's the number of tunnel
interfaces may tax the capacity of the enterprise router. Often
though, even for small VPN's, the topology of tunnels is
compromised, from a mesh to a hub and spoke system. Sub optimal
routing is the usual result, with undesirable "hairpinning" of
packets over costly "last mile" links at the hub.
The use of specialized VBR's, as described in section 2.2.1,
permits the enterprise to outsource to the provider more of the
IP network services it needs, saving both capital and
operational costs. There are also potential traffic savings on
the "last mile" links to the sites that would otherwise host
home gateways and Internet firewalls. Traffic to or from the
external networks will travel straight from or to the
destination site, rather than be hairpinned through a hosting
site.
Casey [Page 16]
Internet Draft An extended IP VPN Architecture November 1998
5.3 Provider network protection
VR's protect the provider's base network from the customer
enterprise networks, particularly if the base network is an IP
network. Enterprise routers do not communicate any routing
information with the provider's internal routers. Thus, the
carrier's networks can be protected from many kinds of damage,
deliberate or accidental, that can occur in shared IP networks.
(Of course, if the carrier runs a public IP service over the
same network that is supporting the VPN's, then there is no
protection from the public IP network users). Other VPN
realizations require the difficult to manage BSP-4 routers be
deployed between customer and carrier to provide (imperfect)
isolation.
5.4 VPN Isolation
With tunnel connected VR's as the forwarding mechanism, an
enterprise has complete freedom in choice of IP addressing
schemes and can choose VPN routing protocols independent of
other enterprises. Non tunnel based implementations of VPN's
over IP networks require customers to use unique, registered, IP
addresses. However, such addresses are in short supply and
increasingly difficult to come by, so many customers want to use
private IP addresses in their enterprise networks.
Further, enterprise Topology changes (route flapping) in one VPN
network is transparent to other enterprises' VPN's. VR's provide
separation of fate.
5.5 Engineerable
VPN areas and gateway VBR's provide a basis for traffic
engineering to be applied to IP VPN's. The load of different
VPNs can be allocated to different VBR's. This can be looked
upon as a form of loose explicit routing. However it is superior
to IP's loose source routing in several respects:
1) If the routing regime being used for intra VPN routing
supports "equal cost path routing" then there can be load
sharing within a VPN through multiple gateways VBR's.
2) Multiple gateway VBRs provide automatic resilience.
3) While packets are in tunnels (i.e. they are encapsulated),
they don't have to carry the expensive to process source
route headers.
5.6 Scaling Factors
Few types of base network can support an unlimited number of
tunnels. For example, if the tunnel mechanism is Virtual
Casey [Page 17]
Internet Draft An extended IP VPN Architecture November 1998
Circuits on a base Frame Relay network the total number of
tunnels will depend of the number of DLCI's that can be
supported on shared Frame Relay links. Judicious use of VPN
areas can reduce the number of tunnels needed, permitting the
support of more VPN's, serving more sites.
Scalability concerns also arise in the exchange of reachability
information for VPN's. Simple reachability exchange mechanisms
do not scale to cover large VPN's with potentially more than a
single stub link per enterprise site. VR's address this by using
full routing protocols for reachability information exchange.
Also having a positive impact on scaling is the fact that VPN
areas significantly reduce the number of peers with which VR's
exchange intra VPN reachability information. This allows VBR's
to support more VPN's with less routing packet exchange
overhead.
On the negative side gateway VBR's may become bottlenecks.
However, this problem can be engineered away, since different
VPN's can be assigned to different gateway VBR's. The resulting
spreading of the load through multiple gateway VBR's will
actually be an improvement over many single area realizations.
Connectivity between geographic regions tends to be more sparse
that connectivity within a region. Without traffic engineering,
the base network routing regime of a single area VPN that
spanned regions, might send all traffic between two regions
through one router and/or over one link.
6.Security Considerations
One of the major functions of a VPN is to provide both data
privacy and addressing privacy for multiple customers over a
shared network infrastructure. At the same time, the provider of
the shared network infrastructure needs assurance that it can
not be compromised by a customer, to the detriment of the
provider or other customers.
6.1 User Data Privacy
A Service Provider may choose to deploy VBR's, each with a
single VR, at a customer's enterprise premise, or they may
deploy VBR's with multiple VR's at a Service Provider location.
In both cases, the only traffic that will enter a customers
premise is that of the customer's VPN. This is ensured by the
isolation of VR's within a VBR (i.e. no traffic passes between
them) and the use of tunnels dedicated to single VPN's.
Casey [Page 18]
Internet Draft An extended IP VPN Architecture November 1998
There is a threat from an intruder setting up a fake VBR and
persuading genuine VR's to send it traffic. This is little
different from threats today from hackers setting up routers
that advertise false routes. Solutions involve having network
nodes only exchange information with other network nodes that
are part of a chain of trust. VBR to VBR or VR to VR
authentication must be part of a full solution.
As provided here, there is no necessary confidentiality of
enterprise data from the Service Provider. I.e. enterprise data
is kept separate from other enterprises and is not readily
available to hackers, but the provider the Service Provider has
full access to the content of packets. An Enterprise that wants
to assure total confidentiality of its data must encrypt it. End
to end encryption will ensure total confidentiality over the
entire enterprise intranet. If the enterprise is not are worried
about internal threats, but perceives the service provider as a
threat then encryption should be performed on all traffic
crossing the WAN interface (i.e. before it reaches the providers
VBR).
6.2 Service Provider Security
Keeping user traffic in tunnels is the best way to ensure the
service provider's network is not compromised. While the VR's
participating in a particular IP VPN share IP address space with
the customer, the customer has no visibility of the IP addresses
used in the Service Providers base network. The service
provider's network is transparent to users. Even if a hacker
within an Enterprise knows some router address inside a service
provider's network, it can't be reached. Packets will either be
forwarded to an enterprise node that happens to have the same
address, or dropped, because the VR's don't have forwarding
entries for it.
The VR mechanism can actually provide extra security for service
providers whose base network is part of the Internet. They can
configure an IP VPN at all of their nodes that isolates all of
their legitimate management traffic from general user traffic.
VPN areas can also be used to enhance security. They provide a
mechanism to partition responsibilities in the provision of IP
VPN service, as well as internal boundaries where policies can
be enforced and auditing performed.
7.Intellectual Property Considerations
Nortel Networks may seek patent or other intellectual property
protection for some or all of the technologies disclosed in this
Casey [Page 19]
Internet Draft An extended IP VPN Architecture November 1998
document. If any standards arising from this document are, or
become, protected by one or more patents assigned to Nortel
Networks, Nortel Networks intends to disclose those patents and
license them on reasonable and non-discriminatory terms.
8.References
[1] Heinanen, et. al, "MPLS Mappings of Generic VPN Mechanisms",
<draft-heinanen-generic-vpn-mpls-00.txt>, August 1998.
[2] Gleeson et al. "A Framework for IP Based Virtual Private
Networks", <draft-gleeson-vpn-framework-00.txt>
[3] Muthukrishnan and Malis, "Core IP VPN Architecture", <draft-
muthukrishnan-corevpn-arch-00.txt>, Oct 1998.
[4] Heinanen et al., "VPN support with MPLS", <draft-heinanen-
mpls-vpn-01.txt>, March 1998.
[5] Jameiseson et al., "MPLS VPN Architecture", <draft-jamieson-
mpls-vpn-00.txt>, Aug 1998.
[6] Casey et al., "IP VPN Realization using MPLS Tunnels",
<draft-casey-vpn-mpls-00.txt>, Oct 1998.
[7] Li, "CPE based VPN's using MPLS", <draft-li-mpls-vpn-
00.txt>, Oct 1998.
9.Author's Address
Liam Casey
Nortel Networks.
PO Box 3511 Station C
Ottawa ON K1Y 4H7
Canada
EMail: liam@nortelnetworks.com
Casey [Page 20]
| PAFTECH AB 2003-2026 | 2026-04-23 05:46:27 |