Network Working Group                                                 Tony Li
INTERNET DRAFT                                               Juniper Networks


                       CPE based VPNs using MPLS

                       <draft-li-mpls-vpn-00.txt>


Status

    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 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 a "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), ftp.ietf.org (US East Coast), or
   ftp.isi.edu (US West Coast).


1.0 Abstract

   This document describes a proposed architecture for the construction
   of Virtual Private Networks (VPNs).  This proposal differs from [1]
   and [2] in that the functionality of the VPN is shared by the
   Customer Premises Equipment (CPE).  Multi-Protocol Label Switching
   (MPLS) is used as a tunneling mechanism across the ISP network.



2.0 Introduction

   A VPN is a mechanism that allows one or more sites to exchange
   packets.  It differs from traditional Internet connectivity in that:

   - The address space used by the VPN sites might not be global

   - The VPN sites require secure communications, possibly including
     payload privacy and protocol level privacy

   - Sites might interact with multiple VPNs and with the Internet
     simultaneously

   - The ISP might perform traffic engineering on the structure of the VPN
     to ensure consistent service to the VPN participants

   This proposal differs from those found in [1] and [2] in that it
   allows the VPN site to maintain physical security over the
   cryptographic equipment used to encrypt its data.  This security
   level is likely to be necessary for any site with a serious interest
   in security.  The implication is that a VPN site need not trust the
   Internet Service Provider (ISP) to ensure data privacy, only to
   provide data transit.

   This proposal uses BGP as the primary mechanism for information
   distribution and assumes that RSVP or LDP is used as the signaling
   mechanism for the MPLS domain.

3.0 Theory of Operation

   In this architecture, BGP information is exchanged between the CPE
   and the ISP's border router so that the CPE can indicate (a) its
   presence in the network and (b) the set of VPNs that the CPE would
   like to participate in.

   This information is possibly (but not necessarily) filtered by the
   ISP and then passed on to other sites.  Sites wishing to connect to
   the VPN initiate an MPLS label-switched path (LSP) with other members
   of the VPN.

   If the creation of the LSP is allowable according to the policies
   established for the VPN, the connection is established and the sites
   that initiated the LSP have connectivity through the LSP.  Transit
   service is provided by encapsulating packets in an MPLS tunnel.  The
   ISP is responsible for delivering the packets to the designated site
   within the network.  The ISP is not responsible for providing
   security for the VPN, but it might provide access control information
   on the distribution of information about the VPN itself.

   The specification of the policies for VPN membership and the
   mechanisms for determining policy compliance are beyond the scope of
   this document.

   Because an LSP can be modeled as a (half-duplex) point-to-point link,
   the topology of the VPN can be a full mesh between sites.
   Alternately, a sparse topology can be constructed based on the policy
   established by the CPE.  This allows the participants in the VPN to
   determine the optimal tradeoff between administrative overhead and
   optimized routing between sites.

   For scalability reasons, providing VPN services is done at the site
   level.  Individual users wishing to access the VPN must do so through
   a VPN member site.  Users not physically present at a VPN member site
   may access the VPN by first accessing a VPN member site using a
   mechanism such as Mobile IP [3].


4.0 VPN advertisement

   To advertise membership in the VPN, the CPE uses BGP.  The CPE
   advertises a host route (/32 prefix) in BGP.  The address that is
   advertised is the IP address of the CPE equipment itself.  This
   address is taken from the ISP's address space and can be globally
   unique.  The remainder of the address space within a site can be
   local, and the CPE can provide NAT functionality to separate the
   address space of the site from the global Internet and/or the
   remainder of the VPN.  [4]

   To identify the VPN, each VPN is given a unique identifier.  This
   identifier is a 16-bit number, assigned by the ISP.  The CPE
   advertises this number as part of the BGP communities attribute by
   advertising a community in which the most significant 16 bits are the
   ISP's Autonomous System (AS) number and the least significant 16 bits
   are the VPN identifier.  This BGP community number is already
   allocated to the ISP for local use by the ISP.  Additional VPN
   identifiers can be allocated either by acquiring another AS number or
   by use of one of the locally scoped communities.

   The ISP's border router is the first router to receive the VPN
   advertisement from the CPE.  At this point, the ISP can filter or
   otherwise examine the advertisement to ensure that it complies with
   the ISP's policies.  For example, the ISP might wish to sell VPN
   services at an extra charge.  The ISP could discard VPN
   advertisements from customers that had not subscribed to the VPN
   service.  Further, if the ISP helps to administer membership in the
   VPN, the ISP optionally could discard advertised communities that the
   site did not actually participate in.

   For VPN advertisements that are accepted by the ISP, BGP naturally
   propagates them to other BGP speakers attached to the ISP and thus to
   other CPE devices.  Note that the ISP can easily construct policy
   such that a CPE receives only the BGP advertisements that the ISP
   selects, such as those from other members of the VPN and the default
   route.  This would avoid having the CPE carry full routing.  Further,
   the ISP can easily filter out VPN advertisements, thus protecting the
   default-free Internet routing table from the introduction of
   unnecessary routes.

   The receiving CPE can authenticate the BGP advertisements that it
   receives, discarding any that fail the authentication test.

5.0 Establishing LSPs

   When a CPE receives a VPN advertisement, it can decide to create a
   VPN connection to the advertiser.  The CPE is under no obligation to
   connect to all possible members of the VPN.  The creation of VPN LSPs
   is a function of the VPN participants and the ISP.  For example, a
   common topology today is a star, in which an enterprise has a central
   site and many remote sites.  In general, the remote sites communicate
   only with the central site.  Thus, it makes sense for the remote
   sites to establish an LSP only back to the central site rather than
   forming a full mesh of LSPs between VPN participants.  Such a policy
   could be configured into the remote site's CPE.

   If a site does decide to initiate a VPN LSP to another VPN
   participant, it does so by using an MPLS signaling protocol to set up
   the LSP.  Currently, both RSVP and LDP are possible candidate
   signaling protocols for MPLS.  The modifications discussed in this
   document could reasonably be applied to both protocols.

   When a site is establishing an LSP, it uses its signaling protocol to
   indicate that it would like an LSP.  It uses the address of the CPE
   device at the opposite end of the LSP to indicate the destination of
   the LSP.  In addition, the CPE attaches the VPN identifier, a time
   stamp, and a signature for security purposes.

   Because the ISP participates in the signaling protocol, it has the
   ability to filter out setup requests for the VPN that do not coincide
   with the ISP's policies.  This helps to ensure that access to VPN
   services is enforced at the LSP level.  In addition, the ISP has the
   ability to perform traffic engineering on the LSP setup request.
   Work on traffic engineering is currently in progress, but it is
   reasonable to expect that an explicit route could be computed by the
   ISP's border router and attached to the setup request.  This allows
   the ISP to place VPN traffic on appropriate facilities to ensure
   appropriate service levels for the VPN.

   After passing the entry border router, the LSP setup propagates
   through the ISP's network in a manner similar to any other traffic-
   engineered LSP.

   When the LSP setup request is received by the destination CPE, it is
   again authenticated and can be rejected (using the appropriate
   signaling protocol mechanisms) if it fails the authentication check
   or violates the destination CPE's configured policies.  If it is
   accepted, the CPE completes the setup request as it normally would
   within the signaling protocol.  As part of the acknowledgment of the
   setup, the destination CPE also can attach a series of prefixes to
   its acknowledgment.  These prefixes represent reachability
   information that the destination CPE allows the originating CPE to
   reach using that LSP.

   When the originating CPE system receives the acknowledgment, it can,
   depending on its configured policies, install the prefixes in its
   forwarding table and it also can inject those prefixes into its local
   routing.  Note that these prefixes are determined by configuration
   and do not constitute a routing protocol in and of themselves.  No
   mechanisms are provided here to ensure loop freedom or optimality of
   route computation for prefixes exchanged using the signaling
   protocol.  Sites wishing to have a routing protocol run on top of the
   VPN are not precluded by this architecture, but no special provisions
   are made for (or are required by) such situations.  Similarly,
   multicast can be supported on the VPN by running normal multicast
   routing protocols across the VPN.

6.0 Acknowledgments

   The author would like to thank Johna Johnson, Aviva Garrett, and Lisa
   Bourgeault for her comments and Yakov Rekhter for his generous
   contributions to this work.

7.0 References

   [] J. Heinanen, et. al, "VPN support with MPLS," <draft-heinanen-
   mpls-vpn-01.txt>, March 1998.

   [] D. Jamieson, et. al, "MPLS VPN Architecture," <draft-jamieson-
   mpls-vpn-00.txt>, August 1998.

   [] C. Perkins, "IP Mobility Support," RFC 2002, October 1996.

   [] K. Egevang & P. Francis, "The IP Network Address Translator
   (NAT)," RFC 1631, May 1994.


8.0 Author's Address

   Tony Li
   Juniper Networks, Inc.
   385 Ravendale Dr.
   Mountain View, CA 94043
   Email: tli@juniper.net
   Fax: +1 650 526 8001
   Voice: +1 650 526 8006