Network Working Group                                   Jeremy De Clercq
INTERNET DRAFT                                         Olivier Paridaens
<draft-ietf-ppvpn-ce-based-00.txt>                        Mahadevan Iyer
                                                        Andrew Krywaniuk
                                                                 Alcatel

                                                               July 2001
                                                   Expires January, 2002

                            A Framework for
        Provider Provisioned CE-based Virtual Private Networks
                              using IPsec

                   <draft-ietf-ppvpn-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.''

     The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/1id-abstracts.html

     The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html.



   To view the entire list of current Internet-Drafts, please check  the
   "1id-abstracts.txt"  listing  contained in the Internet-Drafts Shadow
   Directorieson 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 a framework 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

   SUMMARY



De Clercq et al.          Expires January 2002                  [Page 1]

Internet Draft      draft-ietf-ppvpn-ce-based-00.txt           July 2001


   The PPVPN  framework  document  [FRAMEWORK]  identifies  three  basic
   provider  provisioned  VPN types : Provider Provisioned Network 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 adition of  one  VPN  site  only
   requires a minimum amount of configuration. This is obtained by using
   an automatic distribution scheme via a network management protocol.

   RELATED DOCUMENTS

   See References section.

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

   PPVPN box.

   WHY IS IT TARGETED AT THIS WG

   This document describes the framework 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.".

   JUSTIFICATION



De Clercq et al.          Expires January 2002                  [Page 2]

Internet Draft      draft-ietf-ppvpn-ce-based-00.txt           July 2001


   This document is justified by the fact that it  defines  a  framework
   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.

1. Introduction

   The PPVPN  framework  document  [FRAMEWORK]  identifies  three  basic
   provider  provisioned  VPN types : Provider Provisioned Network 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 adition of  one  VPN  site  only
   requires a minimum amount of configuration. This is obtained by using
   an automatic distribution scheme via a network management protocol.

2. Reference Model

   This section describes the reference model used. It is the purpose to
   allign  this section with the terminology and the reference model for
   CE-based PP-VPNs  that  will  be  described  in  future  versions  of
   [FRAMEWORK].













De Clercq et al.          Expires January 2002                  [Page 3]

Internet Draft      draft-ietf-ppvpn-ce-based-00.txt           July 2001


    +---------+  +------------------------------------+  +---------+
    |         |  |                                    |  |         |
    |         |  |                     +------+     +------+  : +------+
+------+ :    |  |                     |      |     |      |  : |  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

      A CE device is a router located at the edge of  a  customer  site,
      that  has IP connectivity with a SP's PE device. In the context of
      CE-based VPNs, a CE  device  maintains  one  or  more  VPN  tunnel
      endpoints.  In  the context of Provider-provisioned CE-based VPNs,
      the VPN functions in the CE device can  be  managed  by  the  SP's
      management system.

      Note that other functions that are  normally  applied  by  the  PE
      router  may  need to be performed by the CE device in this context
      (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



De Clercq et al.          Expires January 2002                  [Page 4]

Internet Draft      draft-ietf-ppvpn-ce-based-00.txt           July 2001


      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 IP connectivity over the access connections to
      these CE devices.

   o SP networks

      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),
      plus  IP  tunnels  (e.g.,  using  IPsec,  L2TP). 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 an  IP  tunnel  (IP-in-IP/IPsec)
      between two CE devices.


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. This implies that every CE device knows  how
   to  reach  the other CE devices attached to the common SP. This might



De Clercq et al.          Expires January 2002                  [Page 5]

Internet Draft      draft-ietf-ppvpn-ce-based-00.txt           July 2001


   be  via  a  direct  routing  entry  in  the  CE's  routing  table  or
   alternatively  (and  probably)  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 upon set-up of  the
   IP service offered to the CE device.

2.3 Assumed Service Provider's infrastructure

   It is assumed that the Service Provider has a secure control  channel
   to every attached CE device. This secure control 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 control  channel  is  currently
   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.

3. Configuring the CE-based VPN

   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 set up and the maintenance of a PP CE-
   based VPN would be minimal.

   The minimal configuration that is necessary is the  configuration  of
   the  Service Provider's VPN database with the CE device to be part of
   a well-defined VPN. Further  provisioning  can  be  achieved  via  an
   auto-discovery mechanism as is described in the sections below.

   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  targetted  CE-devices  is
   achieved using an information exchange/configuration protocol such as
   LDAP, SNMP, COPS etc. We will  call  this  protocol  'the  management
   protocol' throughout the rest of this document.




De Clercq et al.          Expires January 2002                  [Page 6]

Internet Draft      draft-ietf-ppvpn-ce-based-00.txt           July 2001


   It is assumed for the scope of this document that the control channel
   used  for  the  configuration  information  exchange  by  the  chosen
   protocol is sufficiently secured.

   This document will identify some  requirements  that  the  considered
   protocol  should satisfy for the purposes of applicability in the VPN
   autodiscovery phase.

3.1 (Minimal) configuration needed at the CE device

   - 'Control 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  control
   channel etc.). Note that this is assumed  to  be  present,  and  that
   setting  up  a secure control 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
   maintain  IPsec Security Associations with the Peer CE devices (a set
   of transforms for use with IPsec, etc.). This information relates  to
   the protection of the actual user data packets.

   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  topolgy  (full
   mesh,  hub&spoke,  etc) and some security-related information related
   to every CE-to-CE tunnel.

3.2 Updating configuration information (neighbor discovery)

   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 configuration  effort.
   Manual  configuration of the information related to the new site into
   every existing CE in the particular VPN is not an option.

   Different methods to achieve the requested  behaviour  are  possible.



De Clercq et al.          Expires January 2002                  [Page 7]

Internet Draft      draft-ietf-ppvpn-ce-based-00.txt           July 2001


   One such method is for the SP to configure the 'new site' in the SP's
   VPN database:

   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 topolgy (hub,
   spoke, etc.), and the necessary security information  are  configured
   in  the  concerned VPN database. This change in the database triggers
   the distribution (via a management protocol such as COPS, LDAP, SNMP,
   etc.)  of  the updated information over the secure control channel to
   the concerned CE devices only (the new  CE  device  and  all  the  CE
   devices it has to peer with).

   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 trigerred 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.

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 exchange private VPN data.

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

   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 initated 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 signalling.




De Clercq et al.          Expires January 2002                  [Page 8]

Internet Draft      draft-ietf-ppvpn-ce-based-00.txt           July 2001


   Alternatively, 'permanent' IPsec tunnels can be set up. 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 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. A disadvantage is the
   necessary frequent re-keying of the SA's.

   Note that IPsec  tunnels  are  unidirectional  in  nature,  but  that
   usually  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 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.
   In  the  case  of  traffic-driven  tunnel  setup,  the  'role' of the
   considered  site  has  an  impact  on  the  CE's   routing/forwarding
   databases.  In the case of 'permanent' IPsec tunnels, permanent IPsec
   tunnels will be set up only to a specific set  of  peer  CE  devices,
   conforming the VPN's topology.

4. Exchanging and maintaining VPN routes

   This document currently describes two alternative mechanisms for  the
   purpose of exchanging VPN routes between VPN sites.

4.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
   tunnels between peering sites. The CE-to-CE IPsec 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,
   IS-IS,   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 the considered CE is peering with.

   Note that when IPsec in tunnel mode is deployed, the routing protocol



De Clercq et al.          Expires January 2002                  [Page 9]

Internet Draft      draft-ietf-ppvpn-ce-based-00.txt           July 2001


   messages  need  to be carried on IP for this method to be applicable.
   When IPsec transport mode is deployed (see section  5),  the  routing
   protocol  messages  will  first be IP-in-IP encapsulated before IPsec
   handling.

   Another point to keep in mind is the fact that when the setup of  the
   VPN  tunnels  via  IKE is traffic-driven, the distribution of routing
   information over the tunnels will also trigger the setting up  of  an
   IPsec  tunnel,  even  when  no  data  traffic is flowing. Therefore a
   routing protocol that only distributes reachability information  upon
   changes  is  required.  Moreover,  in the specific case of link state
   routing protocols, the hello mechanism would also trigger  the  setup
   of IPsec tunnels.

4.2 Exchanging VPN reachability information via SP's management

   An alternative method to exchange reachability between sites within a
   VPN  is  by SP's management system involvement. When the reachability
   in a certain site changes, the considered  CE  device  will  need  to
   communicate  the  new  reachability  information  through  the secure
   control channel to the SP's VPN  database.  This  could  be  achieved
   either  by  having  the  CE device to push the new information to the
   SP's VPN database or by having the CE device to send some message (eg
   SNMP  trap) to the SP's management system, which in turn can pull the
   new reachability information from the CE device. Once  the  SP's  VPN
   database has been updated, this will trigger the distribution of this
   updated information from the SP's VPN database to all the appropriate
   CE  devices  by  the management system, using the management protocol
   over the secured control connections.

   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.

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 January 2002                 [Page 10]

Internet Draft      draft-ietf-ppvpn-ce-based-00.txt           July 2001


   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  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.

   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:

      - analyse 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])

      When IPsec is used in transport  mode  in  this  context,  the  CE
      device  must  first  analyse  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
      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:

      - analyse the IP packets that have been IP-in-IP encapsulated  and
      select  the  appropriate  SA  (based  on  the  packets destination
      address).

      - authenticate and/or encrypt the private IP packet  according  to



De Clercq et al.          Expires January 2002                 [Page 11]

Internet Draft      draft-ietf-ppvpn-ce-based-00.txt           July 2001


      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
   accross 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.


6. Deleting an existing VPN site

   When the VPN customer decides to  delete  an  existing  site  from  a
   certain VPN, the SP's VPN database must be changed accordingly:

   - either manually by the SP

   - or via a "PUSH" operation with the management protocol  by  the  CE
   device to the VPN database.

   This will then trigger the distribution of  the  updated  information
   from the SP's VPN database to the concerned CE devices.

   The CE device from the deleted site will then terminate the  existing
   Security  Associations  with  its  peer  CE's  using  IKE  signaling.
   (Alternatively, the IKE sessions could be just timed out).

   Note that the CE devices of a certain VPN need to delete the  routing
   entries  corresponding  with  a deleted CE device (i.e. a deleted VPN
   site)  from  their  corresponding  routing/forwarding   tables,   and
   announce this change within their site.

7. Quality of Service

   TBD



De Clercq et al.          Expires January 2002                 [Page 12]

Internet Draft      draft-ietf-ppvpn-ce-based-00.txt           July 2001


8. 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  mechanism  presented  here  is  highly
   dependent   on  the  security  of  'control  channel',  used  by  the
   management protocol to configure the VPN CE devices.

9. References

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

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

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

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

10. 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

   Mahadevan Iyer
   Alcatel Inc
   595 Yosemite Blvd, Milpitas, CA
   Phone: 408 586 7687
   E-Mail: mahadevan.iyer@ind.alcatel.com

   Andrew Krywaniuk
   Alcatel Networks Corporation
   600 March Road
   Kanata, ON
   Canada, K2K 2E6



De Clercq et al.          Expires January 2002                 [Page 13]

Internet Draft      draft-ietf-ppvpn-ce-based-00.txt           July 2001


   +1 (613) 784-4237
   E-mail: andrew.krywaniuk@alcatel.com

















































De Clercq et al.          Expires January 2002                 [Page 14]