[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03                                                   
Network Working Group                                   Jeremy De Clercq
INTERNET DRAFT                                         Olivier Paridaens
<draft-ietf-l3vpn-ce-based-00.txt>                               Alcatel

                                                        Andrew Krywaniuk
                                                              Cliff Wang

                                                              March 2003
                                                 Expires September, 2003

                         An Architecture for
        Provider Provisioned CE-based Virtual Private Networks
                              using IPsec

                  <draft-ietf-l3vpn-ce-based-00.txt>

Status of this Memo


   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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. Internet-Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet-
   Drafts as reference material or to cite them other than as a
   ``working draft'' or ``work in progress.''

   To view the entire list of current Internet-Drafts, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
   Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au(Pacific
   Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).

   Distribution of this memo is unlimited.

Abstract

   This document describes the procedures for a Service Provider to
   offer Virtual Private Network Services to its customers by
   provisioning the CE devices on behalf of the customer. The IPsec
   technology is used to protect the customer traffic.

0. SubIP-Area Section



De Clercq et al.        Expires September 2003                 [Page 1]


Internet Draft     draft-ietf-ppvpn-ce-based-03.txt           March 2003


   SUMMARY

   The PPVPN framework document [FRAMEWORK] identifies three basic
   provider provisioned VPN types : Provider Provisioned Network Based
   (or PE-based) Layer 3 VPNs, Provider Provisioned Layer 2 VPNs and
   Provider Provisioned CE-based VPNs.

   This document describes a method enabling a Service Provider to offer
   VPN services to its customers by provisioning the CE devices on
   behalf of the customer (Provider Provisioned CE-based VPNs).

   For a CE-based VPN to be set up under the SP's control, the VPN
   customer informs the Service Provider of which sites (identified by a
   set of CE devices) should become part of the considered VPN and what
   the requested topology of the VPN should look like. The SP then
   configures and maintains a VPN database and manages the Customer's
   VPN.

   The model proposed in this document uses the IPsec protocol suite for
   the purpose of securing the customer VPN traffic.

   When the model proposed is used, the addition of one VPN site only
   requires a minimum amount of configuration. This is obtained via a
   provisioning scheme using a network management protocol.

   RELATED DOCUMENTS

   See References section (especially [CE-SOL], [TOUCH]).

   WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK

   PPVPN box.

   WHY IS IT TARGETED AT THIS WG

   This document describes a mechanism for Provider Provisioned CE-based
   VPNs, which is clearly identified as an item within the scope of the
   PPVPN WG, as stated from the following WG charter extract: "This
   working group is responsible for defining and specifying a limited
   number of sets of solutions for supporting provider-provisioned
   virtual private networks (PPVPNs). The work effort will include the
   development of a framework document, a service requirements document
   and several individual technical approach documents that group
   technologies together to specify specific VPN service offerings. The
   framework will define the common components and pieces that are
   needed to build and deploy a PPVPN. Deployment scenarios will include
   provider-managed VPN components located on customer premises.".




De Clercq et al.        Expires September 2003                 [Page 2]


Internet Draft     draft-ietf-ppvpn-ce-based-03.txt           March 2003


   JUSTIFICATION

   This document is justified by the fact that it defines a solution for
   PP CE-based VPNs, which are identified as a specific type of PPVPNs
   both in the WG charter and the general framework I-D. As described in
   the general framework I-D, PP CE-based VPNs have specific
   characteristics compared to Network-Based VPNs especially with
   regards to management and security.

Changes since last version

   Proposed changes to version -02.txt of this document, based on
   comments received on the ppvpn exploder, have mostly been dealt with
   in [CE-SOL].

   This version -03.txt differs not significantly from the previous
   version (-02.txt); this allows this (architecture) document to be
   used for reference's purpose.

1. Introduction

   The PPVPN framework document [FRAMEWORK] identifies three basic
   provider provisioned VPN types : Provider Provisioned Network Based
   (also termed PE-based) Layer 3 VPNs, Provider Provisioned Layer 2
   VPNs and Provider Provisioned CE-based VPNs.

   This document describes a method enabling a Service Provider to offer
   VPN services to its customers by provisioning the CE devices on
   behalf of the customer (Provider Provisioned CE-based VPNs).

   For a CE-based VPN to be set up under the SP's control, the VPN
   customer informs the Service Provider of which sites (identified by a
   set of CE devices) should become part of the considered VPN and what
   the requested topology of the VPN should look like. The SP then
   configures and updates its VPN database, and then provisions and
   manages the Customer's VPN.

   The model proposed in this document uses the IPsec protocol suite for
   the purpose of securely tunneling the customer VPN traffic.

   This specification proposes some mechanisms that can be used to
   enhance the scalability of the VPN provisioning (e.g. the addition of
   a VPN site to an existing VPN).

2. Reference Model

   The reference model upon which the mechanisms and procedures
   described in this document are based, is taken from the CE-based VPN



De Clercq et al.        Expires September 2003                 [Page 3]


Internet Draft     draft-ietf-ppvpn-ce-based-03.txt           March 2003


   reference model described in [FRAMEWORK]. The most important aspects
   of that framework model and the restrictions that are relevant to
   this document are described in this section.



    +---------+  +------------------------------------+  +---------+
    |         |  |                                    |  |         |
    |         |  |                     +------+     +------+  : +------+
+------+ :    |  |                     |      |     |      |  : |  CE  |
|  CE  | :    |  |                     |   P  |     |  PE  |  : |device|
|device| :  +------+    VPN tunnel     |router|     |router|  : |  of  |
|  of  |=:====================================================:=|VPN  A|
|VPN  A| :  |      |                   +------+     +------+  : +------+
+------+ :  |  PE  |                                  |  |    :    |
+------+ :  |router|                                  |  |    :    |
|  CE  | :  |      |              VPN tunnel        +------+  : +------+
|device|=:====================================================:=|  CE  |
|  of  | :  +------+                                |  PE  |  : |device|
|VPN  B| :    |  |                                  |router|  : |  of  |
+------+ :    |  |  +------------+   +------------+ |      |  : |VPN  B|
    |    :    |  |  |  Customer  |   |   Network  | +------+  : +------+
    |Customer |  |  | management |   | management |   |  |    :    |
    |interface|  |  |  function  |   |  function  |   |  |Customer |
    |         |  |  +------------+   +------------+   |  |interface|
    |         |  |                                    |  |         |
    +---------+  +------------------------------------+  +---------+
    | Access  |  |<---------- SP network(s) --------->|  | Access  |
    | network |  |                                    |  | network |

   Figure 1: Reference model for provider provisioned CE-based VPNs

2.1 Entities in the reference model

   o Customer Edge (CE) device

      In the context of this solution, a CE device is a router located
      at the edge of a customer site, that has IP connectivity with a
      SP's PE device. A CE device maintains one or more VPN tunnel
      endpoints. The VPN-specific functions in the CE device are managed
      by the SP's management system. It is very common for the SP to
      manage the complete CE device, while it is also possible for the
      customer to self-manage part of the CE's functions. In such a
      situation, the separation of responsabilities is to be clearly
      defined in the SLA.

      Note that other functions that are normally applied by the PE
      router may need to be performed by the CE device in this context



De Clercq et al.        Expires September 2003                 [Page 4]


Internet Draft     draft-ietf-ppvpn-ce-based-03.txt           March 2003


      (e.g. NAT functionality, QoS classification, etc.).

      The CE device may also provide general (non VPN-oriented) Internet
      connectivity for the customer network. Such connectivity may be
      achieved via the SP's PE router that provides the VPN connectivity
      or some other router (of the same or another SP). In such a
      situation, the CE device must be able to distinguish between
      traffic to be sent through a VPN and traffic to be sent outside
      any VPN.

   o Provider Edge (PE) router

      In the context of Provider Provisioned CE-based VPNs, a PE router
      is a router, located at the edge of the Service Provider's
      network, that does not have any VPN-specific functionality. A PE
      router is attached via an access connection to one or more CE
      devices, and offers possibly limited or restricted IP connectivity
      over the access connections to these CE devices.

   o SP network

      A SP network is a network administrated by a single service
      provider. In the context of provider provisioned CE-based VPNs,
      the SP network consists of the Service Provider's IP (backbone)
      network and the Service Provider's management functions that
      manage both its own IP (backbone) network and the VPN customer's
      VPN functions on the CE devices.

   o Access connection

      An access connection represents an isolated layer 2 connectivity
      between a CE device and a PE router. This includes dedicated
      physical circuits, logical circuits (such as Frame Relay and ATM),
      IP tunnels (e.g., using IPsec, L2TP) and shared-medium access
      (such as Ethernet-based access). In the context of provider
      provisioned CE-based VPNs, the CE device and the PE router have
      layer 3 connectivity over the Access Connection.

   o VPN tunnel

      A VPN tunnel is a logical link between two entities which is
      created by encapsulating packets within an encapsulating header
      for purpose of transmission between those two entities for support
      of VPNs. In the context of provider provisioned CE-based VPNs, a
      VPN tunnel is an IP tunnel (e.g., using IPsec, L2TP, GRE, IP-in-
      IP) between two CE devices over the SP's network. In the context
      of this document, a VPN tunnel is achieved using IPsec in tunnel
      mode or via an IP-in-IP tunnel protected by IPsec in transport



De Clercq et al.        Expires September 2003                 [Page 5]


Internet Draft     draft-ietf-ppvpn-ce-based-03.txt           March 2003


      mode between two CE devices. [GRE-CE] describes how to use GRE
      encapsulation for CE to CE tunneling in a CE-based IPsec VPN
      scenario.

2.2 Assumed Reachability

   It is assumed in this specification that the CE devices have at least
   one IP address that is known to the SP network and that is routable
   within the SP's network. It is also assumed that every CE device
   knows how to reach the other CE devices attached to the common SP.
   This might be via a direct routing entry in the CE's routing table or
   alternatively via a default route towards the PE device it is
   attached to. These CE IP addresses will be known in the SP network,
   if not globally, then at least in the PE devices engaged in the VPN
   services.

   This means that either a routing protocol will be running between the
   CE and the PE device, exchanging routes belonging to the service
   provider's routing realm; or alternatively, the CE will have a
   configured default route or static route towards the PE, and the PE
   will have assigned an IP address to the CE device before or upon
   set-up of the IP service offered to the CE device.

   As some of the CE's interfaces are in the SP's routing space and some
   of the CE's interfaces are in the customer's routing space, CE
   devices will need to be able to operate in two distinct (separate and
   possibly overlapping) routing spaces.

   More details regarding the assumed CE's reachability are provided in
   [CE-SOL].

2.3 Assumed Service Provider's infrastructure

   It is assumed that the Service Provider has a secure provisioning
   channel to every attached CE device. This secure provisioning channel
   will be used to exchange VPN-specific configuration information
   between the SP's VPN database and the CE devices.

   The particular implementation of this provisioning channel is outside
   of the scope of this document. Some examples are: (i) manual
   configuration by a trusted party, directly on the considered network
   element; (ii) via a management protocol running over an IPsec-secured
   connection between the SP's management center and the considered
   network element; (iii) via a management protocol that has its own
   implicit security mechanisms. For scalability reasons, manual
   configuration is not recommended.

3. Configuring the CE-based VPN



De Clercq et al.        Expires September 2003                 [Page 6]


Internet Draft     draft-ietf-ppvpn-ce-based-03.txt           March 2003


   Note that [CE-SOL] proposes a detailed instantiation of the
   procedures described in this section.

   As a Service Provider that is offering VPN services over its backbone
   network will be responsible for the configuration and the management
   of a potential large amount of VPNs, it is required that the
   provisioning actions for the initial establishment and the
   maintenance of a PP CE-based VPN would be minimal.

   The minimal configuration required is to first configure the Service
   Provider's VPN database with the CE device to be part of a well-
   defined VPN. Further device provisioning can be achieved through the
   management channel.

   For the purpose of CE device configuration, the Service Provider will
   maintain a VPN database per VPN customer. The exchange of information
   between the SP's VPN database and the targeted CE-devices is achieved
   using an information exchange/configuration protocol such as LDAP,
   SNMP, COPS, XML/HTTP etc. We will call this protocol 'the management
   protocol' throughout the rest of this document.

   It is assumed for the scope of this document that the management
   channel used for the configuration information exchange by the chosen
   protocol is sufficiently secured (e.g. by using a specific IPsec
   protection for that purpose, or by using a SSL or SSH protected
   channel, etc.).

3.1 (Minimal) configuration needed at the CE device

   - 'Management channel' information : the information needed to access
   (or to exchange information with) the SP's VPN database ('database
   reachability information', authentication information for the VPN
   database, encryption information for the configuration management
   channel, necessary credentials, etc.). Note that this is assumed to
   be present, and that setting up a secure management channel is
   outside of the scope of this document.

   - Peer CE devices : the IP addresses (in the SP's realm) of the peer
   CE devices that belong to the same VPN and to which a direct peering
   relationship is required. This information can be one IP address
   (e.g. in the case that the considered CE device is a 'spoke' in a
   'hub&spoke' topology); this information can be the complete set of
   the IP addresses of all the other CE devices belonging to the same
   VPN (in the case of a 'fully meshed' topology); or this information
   can be a subset of the IP addresses of the CE devices belonging to
   the same VPN (for more complex topologies).

   - Security Information : the information needed to set up and



De Clercq et al.        Expires September 2003                 [Page 7]


Internet Draft     draft-ietf-ppvpn-ce-based-03.txt           March 2003


   maintain IPsec Security Associations with the Peer CE devices:

      - a set of transforms to use with IPsec (this information relates
      to the protection of the actual user data packets) for every
      Security Association.

      - tunnel property information for every SA that the considered CE
      participates in : traffic-driven tunnel or 'permanent' tunnel;
      tunnel mode or IPsec transport mode on an IP-in-IP tunnel; dynamic
      routing through the tunnel or not.

      - an IKE credential: (i) a pre-shared key or (ii) a private
      key/certificate pair and a certificate for a Certificate Authority
      (these are to be used to establish the IPsec security associations
      with the peer CE devices). This credential will be used for the
      generation of the keys for all the Security Associations the
      considered CE participates in.

   - VPN identifier: an identifier that uniquely identifies the VPN that
   the customer belongs to. The VPN identifier defined in [RFC2685] can
   be used for this purpose, or any unique identifier the PPVPN WG
   agrees upon. Note that the use of this VPN identifier will be
   necessary when one site is allowed to be part of more than one VPN,
   but that this specification does not currently specify that scenario.
   Another feature that may require the use of a unique VPN identifier
   is the IKE-based membership discovery mechanism described in section
   3.2.

   This means that the VPN database (identified by a VPN identifier) of
   the SP's management system contains a list of all the CE devices
   belonging to the specified VPN, a description of the topology (full
   mesh, hub&spoke, etc.) and some security-related information related
   to every CE-to-CE tunnel.

   Note that every CE also needs to be configured as to align the
   routing within the VPN with the tunneling between VPN sites. Section
   4 describes these issues in more detail.

3.2 Updating configuration information

   One of the most important requirements relating to scalability for
   PP-VPNs is that the addition/deletion of a certain site to/from an
   existing VPN should be possible with a minimal of configuration
   effort. Manual configuration of the information related to the new
   site into every existing CE in the particular VPN is not a scalable
   option. An automatic mechanism for membership discovery/distribution
   is therefor required.




De Clercq et al.        Expires September 2003                 [Page 8]


Internet Draft     draft-ietf-ppvpn-ce-based-03.txt           March 2003


   The CE's IP address in the SP's realm, the VPN-ID of the VPN it
   belongs to, the 'role' of the new site in the existing topology (hub,
   spoke, etc.), and the necessary security information need to be
   configured in the concerned VPN database.

   Different methods to achieve the requested 'automatic' behavior are
   possible. This section describes some possible approaches but does
   not claim to be exhaustive.

   o using the SP's management system

      In this approach, the customer notifies the SP of the site to be
      added (out of band), and the SP's management system takes care of
      configuring its VPN database, takes care of provisioning the new
      CE device and takes care of updating the other CE devices that
      belong to the considered VPN. This provisioning also initiates the
      IPsec signaling between the new CE device and the existing CE
      devices.

   o pushing information from the SP's VPN database

      This approach can be seen as a more detailed description of an
      example of the previous approach.

      The customer first notifies the SP of the site to be added. The SP
      then configures its VPN database with the new membership
      information. This updating of the VPN database will trigger an
      information exchange between the SP's VPN database and the
      concerned CE devices (the new CE device and all the CE devices it
      has to peer with). This distribution of the updated information
      happens over a secured 'management channel', via a configuration
      protocol (such as COPS, DHCP, LDAP, SNMP, etc.).

      This method implies that the protocol used for the distribution of
      the configuration information to the CE devices should be usable
      in a "PUSH" mode from 'server' to 'client' (the management system
      - server - pushes the updated information to the concerned parties
      - clients -). It is to be noted that some information distribution
      technologies such as LDAP are natively not PUSH oriented. If the
      VPN configuration is stored using such a technology, it is
      necessary to define a mechanism that enables the CE to be
      triggered so as to fetch VPN configuration from its repository.
      Such a mechanism could be based on the use of SNMP messages sent
      to the CE device, with specific variables that trigger the fetch
      operation.

      Note that a solution using this method should integrate it in a
      reliable architure.



De Clercq et al.        Expires September 2003                 [Page 9]


Internet Draft     draft-ietf-ppvpn-ce-based-03.txt           March 2003


   o using the SA signaling protocol (IKE)

      The customer first notifies the SP of the site to be added. The SP
      then configures the new CE device and its VPN database (this could
      eventually be done manually). When the new CE device is configured
      with the required configuration information, it will start the
      IPsec signaling (via IKE or its successor) with the peer CE
      devices it is configured with.

      When a peer CE device (that already belongs to the considered VPN)
      receives an initial IPsec signaling message, it MUST check whether
      the initiating CE device belongs to the set of CE devices the
      considered CE needs to peer with, by looking at its VPN
      configuration information. If the initiating CE device does not
      belong to that set according to its VPN configuration information,
      the CE device needs to update its VPN configuration information by
      fetching the 'latest' VPN configuration information from the SP's
      VPN database (e.g. using a protocol for database retrieval such as
      COPS, DHCP, FTP, HTTP, LDAP, etc.) over the secured management
      channel. If after the updating of the VPN configuration
      information, the initiating CE device is still not part of the CE
      devices the considered CE device has to peer with, then the
      considered CE device MUST reject the incoming IPsec SA
      establishment. If the initiating CE device belongs to the set of
      CE devices that the considered CE device must peer with, then the
      incoming IPsec SA establishment should be accepted and an IPsec
      'tunnel' should be established.

      The details of this procedure are outside of the scope of this
      document. See [CE-SOL] for a detailed example.

3.3 Setting up the VPN tunnels

   When one VPN site sends traffic to another VPN site belonging to the
   same VPN, these IP packets will be secured via IPsec. This means that
   an IPsec Security Association is needed between each pair of sites
   that directly exchange private VPN data with each other.

   The Internet Key Exchange protocol (IKE, [IKE]) or its successor will
   be used for the purpose of automatic setup of security associations
   between VPN sites within the same VPN.

   These dynamically established Security Associations can lead to
   'permanent' IPsec-secured tunnels. These tunnels are always available
   and not traffic-triggered. It is then required to frequently re-
   negotiate the SA (via IKE) before the IPsec timers of the connection
   time out. The set-up of a 'permanent' IPsec tunnel can be triggered
   by the configuration of a new peer CE device within the same VPN. An



De Clercq et al.        Expires September 2003                [Page 10]


Internet Draft     draft-ietf-ppvpn-ce-based-03.txt           March 2003


   advantage of this method is that the IPsec tunnel is always
   available, and that eventual traffic does not encounter an extra
   delay due to the setup time of a new SA. The use of 'permanent' IPsec
   tunnels is recommended for CE-based site-to-site VPNs.

   Provider provisioned CE-based IPsec VPNs as described by this
   document SHOULD use 'permanent' IPsec Security Associations when
   dynamic routing through IPsec-secured tunnels is used.

   Alternatively, the IPsec SA setup can be triggered by the effective
   (data) traffic flow going from one site to another. In this case, the
   arrival of data packets at the CE device, coming from within the VPN
   site and going to another VPN site, will be noticed by the CE's IPsec
   or routing database, and an IKE exchange will be initiated to set up
   an IPsec secured connection between both parties. Once the secure
   tunnel is set up, the data packets can flow from one site to the
   other in a secure way. When no traffic flows for a certain duration
   of time, the secure tunnel will be torn down again. An advantage of
   this method is that an IPsec tunnel is only to be maintained when
   there is effectively traffic flowing. A disadvantage is the extra
   delay introduced for the traffic during IKE signaling and the
   interaction with the tunneled inter-site VPN routing information
   distribution.

   Provider provisioned CE-based IPsec VPNs as described by this
   document MAY use traffic-driven IPsec SA establishment when static
   intra-VPN inter-site routing is used (no dynamic routing through the
   IPsec tunnels), see section 4.3. Provider provisioned CE-based IPsec
   VPNs as described by this document SHOULD NOT use traffic-driven
   IPsec SA establishment when dynamic site-to-site routing through the
   IPsec-secured tunnels is used.

   The CE configuration determines whether traffic-driven SA
   establishment is used or not, and whether dynamic routing through
   IPsec tunnels is used or not.

   Note that IPsec tunnels are unidirectional in nature, but that the
   set up of one direction is accompanied by the set up of the reverse
   direction IPsec tunnel.

   This document describes two possible ways to use IPsec in CE-based
   VPN scenarios (see section 5): in 'transport mode' or in 'tunnel
   mode'. The CE configuration, IKE exchange and resulting SA's must
   specify which mode will be used.

   Note that the number of peer CE devices with which a specific CE
   device must have an IPsec connection to secure the data traffic, is
   dependent on the specific 'role' of the site in the considered VPN. A



De Clercq et al.        Expires September 2003                [Page 11]


Internet Draft     draft-ietf-ppvpn-ce-based-03.txt           March 2003


   hub CE will for example have a larger number of tunnels to support
   than a spoke device.

3.4 VPN resilience

   When IPsec tunnels are used for VPN site-to-site connection, many
   times it is important for a SP to provide its customers with
   connection resilience. The site-to-site VPN could be broken due to
   either a VPN link failure or a VPN node failure. VPN resilience
   support would require both VPN node redundancy and VPN link
   redundancy.

   To support VPN node redundancy, extra CE routers can be placed. Two
   deployed CE routers can provide fail-over and potentially load
   balancing support. It is possible that only one end of a VPN link has
   redundancy. For example, in a hub-spoke topology, the hub node is
   more important than a spoke node. It is not unusual to provide
   redundancy just to the hub router.

   The VPN link resilience support comes from two levels: IPsec tunnel
   level and physical link level. To provide physical link redundancy, a
   customer may subscribe two links from the SP. At the IPsec tunnel
   level, a customer may set up more than one IPsec tunnel. If the
   remote site has only a single CE device, both tunnels will terminate
   at the same device. If the remote site has two CE devices, each
   tunnel may terminate at different CE devices.

   When the redundant VPN links connect to two separate CE devices at
   the remote site, the user (or the SP) must decide how to split the
   traffic between the two VPN links. One choice is to designate one
   link as the primary link which carries all the traffic and leave the
   other idle link as the backup. The other choice is to divide the
   traffic between the two links. When two links are used, the important
   issue is to detect any link failure and divert the traffic to the
   healthy link. One way to achieve this is to run routing keep-alive
   through both tunnels. When a link is down, the routing protocol is
   able to discover the link outage and reroute the traffic accordingly.

4. Exchanging and maintaining VPN routes

   One of the requirements for PP CE-based VPNs is that dynamic routing
   is not only supported within individual VPN sites, but also between
   the different VPN sites of a specific VPN. This means that when a
   change in the routing information in a specific site occurs, the
   other sites that belong to the same VPN must be notified of that
   change.

   This document assumes that the routing within a VPN site is



De Clercq et al.        Expires September 2003                [Page 12]


Internet Draft     draft-ietf-ppvpn-ce-based-03.txt           March 2003


   controlled by the VPN customer, and thus is outside of the scope of
   this specification.

   On the other hand, the role of the CE device with regards to routing,
   the interaction between the intra-site and inter-site routing and the
   relationship between routing and VPN tunnels are addressed in this
   specification. For more detailed aspects concerning issues with
   regards to routing and CE-based IPsec VPNs, we refer to [TOUCH],
   [DUFFY] and [KNIGHT].

4.1 The CE device and VPN routing

   On the customer network side, a CE router connects to internal
   networks of an enterprise, where one or more subnets can reside. Many
   times, the CE router may interact with another internal router.

   The CE is involved in (i) the intra-site routing, (ii) the VPN tunnel
   termination, and (iii) the inter-site VPN routing. The CE device
   could be an integrated device providing both routing and IPsec tunnel
   termination. Sometimes, a dedicated VPN terminator may be used.
   Implementations in which the VPN tunnel terminator resides on a
   firewall are also very common. For the sake of simplicity, we assume
   that the CE router is an integrated device that participates in the
   intra-site routing (e.g. via an IGP) and at the same time terminates
   VPN tunnels.

   In the context of this document, the routing aspects within a VPN
   site (intra-site routing information distribution) are controlled by
   the VPN customer. The role of the SP is either to completely manage
   the inter-site reachability distribution or to configure the CE
   devices in such a way that the customer may transparently run routing
   protocols (or configure static routes) through the VPN tunnels.

4.2 IPsec and routing

   IPsec is a layer 3 tunneling protocol, which operates purely at the
   IP layer. The IETF IPsec Working Group specifies the IPsec standards
   ([IPSEC], [RFC2402], [RFC2406], [RFC2407], [RFC2408], and [IKE]). The
   interaction between IPsec and layer 3 routing is often troublesome
   and has been described in [DUFFY], [TOUCH] and [KNIGHT]. Depending on
   individual implementations, difficulty may arise when an IPsec user
   wants to support robust routing across IPsec VPNs sites.

   Details regarding the problems of the interaction between VPN routing
   and VPN tunneling, and some proposed solutions to counter these
   issues, can be found in [DUFFY], [TOUCH] and [KNIGHT].

4.3 Mechanisms to exchange VPN routes between VPN sites



De Clercq et al.        Expires September 2003                [Page 13]


Internet Draft     draft-ietf-ppvpn-ce-based-03.txt           March 2003


   This document describes two alternative mechanisms for the purpose of
   exchanging VPN routes between VPN sites. The mechanism that is in use
   for a particular tunnel is identified by the CE configuration
   information.

4.3.1 Tunneling routing information between CE devices through the IPsec
   tunnels.

   In the first mechanism to exchange VPN reachability information,
   normal routing protocol messages are tunneled through the IPsec-
   secured tunnels between peering sites. The CE-to-CE IPsec-secured
   tunnels between VPN sites are then being seen as point-to-point links
   by the customer networks and are inserted as such in the routing
   protocol functions of the CE devices. This means that when a change
   in the reachability occurs in one particular site, a routing protocol
   (such as RIP, OSPF, etc.) will take care of the distribution of the
   new reachability information within the site, but also to all other
   sites, through the VPN tunnels that the considered CE is peering
   with.

   When routing protocol messages are tunneled through the IPsec-secured
   tunnels ('dynamic routing through IPsec-secured tunnels') as per this
   section, IPsec transport mode secured IP-in-IP tunnels as per [TOUCH]
   SHOULD be used (in contrast to IPsec tunnel mode tunnels).

   Note that other approaches may use a combination of dynamic routing
   and IPsec tunnel mode tunnels, though it is not clear how
   interoperability will then be assured.

   Another issue to consider is the fact that using a traffic-driven
   tunnel establishment mechanism and at the same time using an approach
   whereby a routing protocol (with a keep-alive mechanism) runs on top
   of the VPN tunnel, does not seem currently applicable: the delay
   introduced by the tunnel establishment phase could lead to a loss of
   routing updates and the routing protocol's keep-alive mechanism could
   interact with the tunnel establishment in an undesired way. Therefor,
   when dynamic routing is used through IPsec-secured CE-to-CE tunnels,
   traffic-driven SA establishment SHOULD NOT be used.

4.3.2 Exchanging VPN reachability information via SP's management

   In non-dynamic environments, SP's management can distribute static
   routes to the CE devices.

   When CE-to-CE IPsec tunnel mode tunnels are used (with the complete
   SPD-controlled filtering), a management-based inter-site reachability
   information distribution SHOULD be used.




De Clercq et al.        Expires September 2003                [Page 14]


Internet Draft     draft-ietf-ppvpn-ce-based-03.txt           March 2003


   When traffic-driven SA establishment is used, a management-based
   inter-site reachability information distribution SHOULD be used.

   Within the sites themselves, the CE device may then inject the
   updated reachability information into the local routing protocol
   function.

   Note that this method does not require the use of the same
   'management protocol' for the configuration of the CE device and for
   the dynamic exchange of reachability information. A dedicated
   protocol may be used for that purpose.

4.3.3 Applicability of the mechanisms to exchange VPN routes between the
   VPN sites

   The 'tunneling approach' (as described in section 4.3.1) does not
   require a new interaction between the customer and the SP and offers
   transparent routing features to the VPN customer. Existing routing
   protocols can be used and the SP is not involved with the propagation
   of routing information updates. It prohibits some specific IPsec
   features though (such as traffic-initiated SA establishment, and the
   complete use of SPD-based filtering).

   The 'management approach' (as described in section 4.3.2) allows for
   the full use of specific IPsec features, but requires a new
   interaction between the CE device and the SP, and breaks the VPN
   customer's routing transparency. The SP participates in the inter-
   domain distribution of routing information.

4.4 Relationship between VPN membership, VPN tunnel status and routing

   When VPN membership changes, VPN tunnels may need to be intentionally
   deleted, and this change needs to be reflected in the routing
   information of all sites belonging to the VPN (see section 6).

   But VPN tunnels can also un-intentionally break for a variety of
   reasons. The routing within the VPN will be affected and updated
   information must be distributed over all VPN sites.

5. Tunneling IP traffic (user data) among VPN sites

   This section describes the processes that an IP packet that is sent
   from one VPN site to another will go through. This is dependent on
   the way that IPsec is used. This document describes two possible ways
   to use IPsec in CE-based VPN implementations: IPsec in tunnel mode,
   and IPsec in transport mode.

   An IP packet that is sent by an IP device in a certain site and



De Clercq et al.        Expires September 2003                [Page 15]


Internet Draft     draft-ietf-ppvpn-ce-based-03.txt           March 2003


   destined for an IP device in another site belonging to the same VPN,
   will be forwarded as follows.

   The device in the sending site sends an IP packet (using a private
   address space) on its LAN network. The next hop for this destination
   IP address will (at some point in time) be the site's CE device
   (according to the routing/forwarding in the VPN site). The processing
   by the CE device now is dependent on the implemented mode for IPsec.

   The use of IPsec in tunnel mode has the advantage that the complete
   range of SPD-checks remain usuable, but has the disadvantage that
   dynamic routing through the tunnels is not supported. The use of
   IPsec in transport mode secured IP-in-IP tunnels has the advantage
   that dynamic routing through the tunnels is fully supported, but has
   the disadvantage that the complete range of SPD-checks is not
   supported.

   Note that the following description is not meant to specify an
   implementation strategy; any implementation procedure wich produces
   the same results is acceptable.

   o IPsec in tunnel mode

      When IPsec is used in tunnel mode in this context, the IPsec
      driver in the CE device must do the following:

      - analyze the private IP packets arriving from within the site and
      select/setup an appropriate SA with the appropriate destination CE
      device.

      - authenticate and/or encrypt the private IP packet according to
      the (tunnel mode-specific) rules described in the SA, AND
      encapsulate the packet in an IPsec header AND encapsulate the
      packet in a new 'outer' IP header. This 'outer' IP header has the
      CE's non-private (i.e. routable in the SP's realm) IP address in
      the source IP address field and the destination CE's non-private
      (i.e. routable in the SP's realm) IP address in the destination IP
      address field.

   o IPsec in transport mode (see also [TOUCH] for a detailed
      specification)

      When IPsec is used in transport mode in this context, the CE
      device must first analyze the private IP packets arriving from
      within the site and select the appropriate destination CE, based
      on the routing/forwarding information. The CE device then
      encapsulates the private IP packet into a new IP packet (IP-in-IP
      encapsulation/tunneling), with the own non-private (i.e. routable



De Clercq et al.        Expires September 2003                [Page 16]


Internet Draft     draft-ietf-ppvpn-ce-based-03.txt           March 2003


      in the SP's realm) IP address in the source address field of the
      new header and the destination CE's non-private (i.e. routable in
      the SP's realm) IP address in the destination address field of the
      new header. The CE device then processes this new IP packet to its
      IPsec driver.

      The IPsec driver in the CE device must then do the following:

      - analyze the IP packets that have been IP-in-IP encapsulated and
      select the appropriate SA (based on the packet's outer header
      destination address).

      - authenticate and/or encrypt the private IP packet according to
      the (transport mode-specific) rules described in the SA and insert
      an IPsec header (according to IPsec in transport mode).


   The CE device then sends the IPsec packet to the PE device, and the
   IPsec packet will then be forwarded using 'normal' IP forwarding
   across the SP's network, based on the outer header's IP destination
   address, that is the destination CE's 'global' (i.e. routable in the
   SP's realm) IP address. The egress PE device will also only examine
   the outer IP header and send the IP(sec) packet to the destined CE
   device. The egress CE device will recognize itself as the destination
   node (the IP packet has the CE's IP address in the outer IP
   destination address field). The destination CE's IPsec driver will
   then, based on the appropriate Security Association (identified by
   the packet's SPI field in the IPsec header), perform IPsec
   authentication and/or decryption. Dependent on whether tunnel mode or
   transport mode IPsec is used, the packet will be decapsulated by the
   IPsec driver itself or sent to the IP-in-IP decapsulation function.
   The resulting (private) IP packet will then be further processed in
   the CE's IP forwarding table and send on the LAN network to the
   appropriate destination IP device.

   Note that IPsec tunnels might unintentionally terminate or break.
   This may have serious consequences if VPN membership and VPN routing
   information is not changed accordingly within the VPN. Indeed, the
   unnoticed termination of a VPN tunnel can result in the creation of
   black holes.

   This means that a mechanism must exist to monitor the state of the
   VPN tunnels. The following possibilities are identified: (i) the use
   of an IPsec-specific keep-alive mechanism [IPSEC-DPD]; (ii) when a
   routing protocol runs on top of the IPsec VPN tunnel (see section
   4.3.1), the routing protocol's keep-alive mechanism can serve that
   purpose; and (iii) the SP's management system could directly control
   the state of the VPN tunnels.



De Clercq et al.        Expires September 2003                [Page 17]


Internet Draft     draft-ietf-ppvpn-ce-based-03.txt           March 2003


6. Deleting an existing VPN site

   When the VPN customer decides to delete an existing site from a
   certain VPN, the customer first needs to inform the SP. The SP will
   change the VPN's configuration information accordingly in its VPN
   database.

   In analogy with the configuration update mechanisms described in
   section 3.2, multiple approaches exist to delete a specific site from
   an existing VPN.

   The SP can gracefully tear down all the concerned IPsec tunnels at
   both ends via either manual configuration or via a re-provisioning of
   all impacted CE devices with the used management system. IKE will
   then be used to tear down the IPsec security associations.
   Alternatively, the IKE sessions could be just timed out.

   Alternatively, when IKE-based discovery is used, the SP will update
   its VPN database and will provision the to-be deleted CE to tear down
   its IPsec connections via IKE. The peering CE devices will then
   update their VPN configuration information as described in section
   3.2.

   In the meantime, if a routing protocol runs on top of the VPN tunnels
   (and keep-alives are used), it will discover the topology change and
   update the necessary routing information automatically. If on the
   other hand, the SP management takes care of the inter-site routing
   information distribution, it will have to update the routes in the
   affected CEs when VPN tunnels are deleted.

7. Provider provisioned CE-based VPNs and NAT

   NAT provides address translation between two realms, such as between
   the private address space and the public address space. For site-to-
   site intranet VPN, the tunneled data usually remain in the same
   customer network address space. NAT is usually not required, unless
   two sites have overlapping address spaces. In that case, NAT can be
   used to solve the address-overlapping problem.

   In normal IPsec tunnel mode operation, after the user data is
   encapsulated by IPsec, the resulted packets are protected by packet
   encryption and/or authentication. Any further NAT changes on the
   packets will be detected at the receiving tunnel end, resulting in
   the packets being dropped. Currently the IPsec Working Group is
   working on a new mechanism so that IPsec packet can be safely NATed.
   Before the IPsec WG finalizes the IPsec over NAT standards, this
   draft assumes that there is no NAT function performed between the two
   IPsec tunnel end points.



De Clercq et al.        Expires September 2003                [Page 18]


Internet Draft     draft-ietf-ppvpn-ce-based-03.txt           March 2003


   The scenario in which NAT applies is when the CE router serves a
   split stack function and provides both site-to-site VPN connection
   and direct Internet access. In this case, customer address space
   traffic is separated into two streams, one part for site-to-site
   private traffic and one part for direct Internet traffic. In this
   case the CE device performs NAT processing for the direct Internet
   traffic. The NAT function performed by the CE router takes care of
   the customer address space to public Internet address space
   conversion. Note that in the case that a certain site has both VPN
   and Internet access, a firewall should be configured at the site's CE
   device.

   See [CE-SOL] for more details concerning solutions for simultaneous
   VPN and Internet Access connectivity.

8. Extranet functionality with provider provisioned CE-based VPNs

   For the time being, this document deals mostly with intranet
   functionality provided by CE-based VPNs. The provisioning of an
   extranet service will affect the routing, tunnel topology and
   security features of the concepts described so far. The PP CE-based
   extranet VPN functionality is TBD.

9. Quality of Service

   TBD

10. Security Considerations

   The security aspects of what is presented in this document are
   implicitly discussed in most of the sections. This draft is for a
   large part focussing on security aspects.

   Note that the security of the mechanisms presented here is highly
   dependent on the following factors:

      - the security of the 'management channel', used by the management
      protocol to configure the VPN CE devices.

      - the security of the CE-device itself

      - the security aspects of the credentials: the IPsec credential
      must be generated, provisioned, updated, and stored securely

      - for a VPN with a complex topology, every tunnel must use the
      same grade of security strength, otherwise, a single weak link
      degrades the whole VPN




De Clercq et al.        Expires September 2003                [Page 19]


Internet Draft     draft-ietf-ppvpn-ce-based-03.txt           March 2003


11. Acknowledgements

   The authors would like to thank the following persons for their
   valuable contributions to this document: Mahadevan Iyer, Cheng-Yin
   Lee, Lars Eggert, Brian Gleeson, Archana Khetan, Paul Knight, Sankar
   Ramamoorthi, Eric Rosen, Michael Choung Shieh, Joe Touch, Eric
   Vyncke, S. Felix Wu, Yu-Shun Wang, Alex Zinin.

12. References

   [CE-SOL] De Clercq, J., Lee, C., Knight, P., "Provider Provisioned
   CE-based Virtual Private Network solution using IPsec and HTTP",
   draft-declercq-ppvpn-ce-based-sol-00.txt, Work in progress

   [DUFFY] Duffy, M., "Framework for IPsec Protected Virtual Links for
   PPVPNs", draft-duffy-ppvpn-ipsec-vlink-00.txt, Work in progress

   [FRAMEWORK] Callon, R. et al., "A Framework for Layer 3 Provider
   Provisioned Virtual Private Networks", draft-ietf-ppvpn-framework-
   0x.txt, Work in progress

   [GRE-CE] Khetan, A., et al., "Use of GRE for routing support in IPsec
   VPNs", draft-khetan-sp-greipsec, Work in progress

   [IKE] Harkins, D. and Carrel, D., "The Internet Key Exchange (IKE)",
   November 1998, RFC 2409

   [IPSEC] Kent, S., Atkinson, R., "Security Architecture for the
   Internet Protocol", November 1998, RFC 2401

   [IPSEC-DPD] Huang, G., Beaulieu, S., Rochefort, D., "A Traffic-Based
   Method of Detecting Dead IKE Peers", draft-ietf-ipsec-dpd-0x.txt,
   Work in progress

   [KNIGHT] Knight, P., Gleeson, B., "A Method to Signal and Provide
   Dynamic Routing in IPsec VPNs", draft-knight-ppvpn-ipsec-dynroute,
   Work in progress

   [LEE-DHCP] Lee, C.Y., "Customer Equipment Auto-configuration", March
   2002, work in progress

   [RFC2402] Kent, S., Atkinson, R., "IP Authentication Header",
   November 1998, RFC 2402

   [RFC2406] Kent, S., Atkinson, R., "IP Encapsulating Security Payload
   (ESP)", November 1998, RFC 2406

   [RFC2407] Piper, D., "The Internet IP Security Domain of



De Clercq et al.        Expires September 2003                [Page 20]


Internet Draft     draft-ietf-ppvpn-ce-based-03.txt           March 2003


   Interpretation for ISAKMP" November 1998, RFC 2407

   [RFC2408] Maughan, D., et al., "Internet Security Association and Key
   Management Protocol (ISAKMP)", November 1998, RFC 2408

   [TOUCH] Touch, J. and Eggert, L., "Use of IPSEC transport mode for
   Virtual Networks", draft-touch-ipsec-vpn-0x.txt, Work in progress


13. Authors' Addresses

   Jeremy De Clercq
   Alcatel
   Fr. Wellesplein 1, 2018 Antwerpen, Belgium
   E-mail: jeremy.de_clercq@alcatel.be

   Olivier Paridaens
   Alcatel
   Fr. Wellesplein 1, 2018 Antwerpen, Belgium
   E-mail: olivier.paridaens@alcatel.be

   Cliff Wang





























De Clercq et al.        Expires September 2003                [Page 21]