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

Versions: 00                                               Informational
Network Working Group                                   Jeremy De Clercq
INTERNET DRAFT                                                   Alcatel
<draft-declercq-l3vpn-ce-based-as-00.txt>                   Dave McDysan
                                                                Worldcom
                                                              Cliff Wang

                                                            January 2004
                                                      Expires July, 2004

                      Applicability Statement for
        Provider Provisioned CE-based Virtual Private Networks
                              using IPsec

               <draft-declercq-l3vpn-ce-based-as-00.txt>

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026 ([RFC-2026]).

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

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

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

   Copyright (C) The Internet Society (2000). All Rights Reserved.
   Distribution of this memo is unlimited.

Abstract

   This document is an applicability statement for Provider Provisioned
   CE-based IPsec VPNs, as discribed in [CEVPN].  This document
   describes how provider provisioned CE-based approaches meet the key
   requirements that are outlined in the PPVPN Applicability Statements
   Guideline document [ASGUIDE] and the key security requirements
   according to the template in section 8 of the VPN security framework
   document [SEC-FW].




De Clercq et al.           Expires July 2004                   [Page 1]


Internet Draft  draft-declercq-l3vpn-ce-based-as-00.txt    January 2004


Table of Contents

   1.   Introduction ...............................................  2
   2.   SP Provisioning Model ......................................  5
   3.   Supported Topologies and Traffic Types .....................  6
   4.   Isolated Exchange of Data and Routing Information ..........  7
   4.1  Isolated forwarding of VPN data ............................  7
   4.2  Constrained Distribution of Reachability Information .......  8
   4.3  Hiding the Internal VPN Topology ...........................  8
   5.   Security ...................................................  9
   5.1  Protection of User Data ....................................  9
   5.2  SP Security Measures ....................................... 10
   5.3  Security Framework Template ................................ 10
   6.   Addressing ................................................. 17
   7.   Interoperability and Interworking .......................... 18
   8.   Network Access ............................................. 18
   8.1  Access types supported ..................................... 18
   8.2  Access QoS support ......................................... 18
   8.3  Access security support .................................... 18
   9.   Service Access ............................................. 19
   9.1  Internet Access ............................................ 19
   9.2  Hosting, ASP, Other Services ............................... 20
   10.  SP Routing ................................................. 20
   11.  Migration Impact ........................................... 20
   11.1 Functions to be added to the customer's CE device .......... 20
   11.2 Functions to be added by the Service Provider .............. 21
   12.  Scalability ................................................ 22
   12.1 Number of supported VPNs ................................... 22
   12.2 Number of sites per VPN .................................... 23
   12.3 Number of tunnels per VPN .................................. 23
   12.4 Number of tunnels per CE ................................... 24
   12.5 Number of routes per VPN ................................... 25
   12.6 Impact of configuration changes ............................ 25
   12.7 Performance impact ......................................... 25
   12.8 Scalability of key distribution infrastructure ............. 26
   13.  QoS, SLA ................................................... 27
   14.  Management ................................................. 27
   14.1 Configuration/provisioning ................................. 27
   14.2 Customer management ........................................ 27
   14.3 SLA monitoring ............................................. 28
   14.4 Security ................................................... 28
   14.5 Fault handling ............................................. 28
   15.  Security considerations .................................... 29
   16.  Acknowledgements ........................................... 29
   17.  References ................................................. 29
   18.  Authors' Addresses ......................................... 30

1. Introduction



De Clercq et al.           Expires July 2004                   [Page 2]


Internet Draft  draft-declercq-l3vpn-ce-based-as-00.txt    January 2004


   This document provides an Applicability Statement for the VPN
   solution described in [CEVPN]. We refer to these VPNs as "provider
   provisioned CE-based IPsec VPNs".

   A VPN service is provided by a Service Provider to a Customer.
   Provider provisioned CE-based IPsec VPNs are intended for the
   situation in which (one or more of the following apply):

      - a SP wants to offer VPN services to its customers without
      implementing VPN specific functions in its edge (PE) or backbone
      (P) routers;

      - the customer does not trust the access network and the backbone
      networks that are used to interconnect the customer's sites;

      - CE-to-CE VPN data might need to be forwarded through the
      Internet or across multiple SPs;

      - the customer does not want to configure and manage the VPN-
      specific functions of its edge equipment;

      - the customer trusts its SP to properly and securely configure
      and manage its CE devices, and trusts the SP to take care of the
      security of its VPN and of the VPN's key management; the customer
      is not concerned with hiding the data from the SP;

   There are different business scenarios wherein PP CE-based IPsec VPNs
   can be offered to a customer.

   The first case is where the different sites of a customer attach to
   the network of a particular SP, and where this SP is offering VPN
   services to its customers. In that case the SP is both the managed
   VPN provider and the network provider.

   This case can be extended to a multi-SP scenario, where the SP,
   offering the VPN service and the network service, has trust
   agreements with other SPs to enable customer sites that are not
   attached to the former SP to belong to the same VPN. In this last
   scenario, the 'other SP' will make sure that the CE device that is
   attached to its backbone will be reachable by the original (primary)
   VPN Service Provider. This means that the VPN Service Provider will
   end up managing CE devices that are attached to its backbone, and CE
   devices that are not direclty attached to its backbone.

   The second case is where the different sites of a customer have
   access to the Internet via the (I)SP of their choice and where a
   (VPN) SP ('the SP') manages the customer's CE devices for VPN
   purposes.



De Clercq et al.           Expires July 2004                   [Page 3]


Internet Draft  draft-declercq-l3vpn-ce-based-as-00.txt    January 2004


   The basic scenario is the following. Every CE device has IP
   connectivity with the other CE devices that will belong to the same
   VPN (this can be via a ''SP's backbone network'' that is owned by one
   SP and that may internally use private addressing, via a set of
   cooperating SPs' PE-based VPNs or via the Internet). The SP's
   management system provisions the site's CE devices with the necessary
   topology and security information. The CE devices establish IPsec
   protected tunnels to the appropriate peering CE devices (according to
   the VPN's topology). The VPN sites start exchanging reachability
   information by tunneling routing protocol messages through the IPsec
   protected tunnels. Alternatively, the SP may provision static routes
   or tunnel traffic policy to the CEs, for example for small-sized,
   'static' VPNs. Under the latter scenario, dynamic routing protocol
   tunneling is not required.

   In provider provisioned CE-based IPsec VPNs, VPN tunnels are
   initiated and terminated at the CE devices, and it is assumed that
   the PE devices receive IP packets from the CE-PE links. This limits
   the supported tunneling techniques to IP-in-IP, L2TP, GRE and IPsec
   (tunnel mode). [CEVPN] uses IPsec (transport mode) protected IP-in-IP
   or GRE tunnels, or IPsec tunnel mode tunnels.

   Note that the tunnel termination points are always the CE devices.

   In CE-based VPNs, there are different aspects that need to be
   provisioned on the customers' CE devices: the VPN tunnels, the
   (IPsec) security policies and parameters, the intra- and inter-site
   routing aspects. Now, depending on what aspects are provisioned by
   the SP and what aspects are provisioned by the customer, different
   scenarios can be considered, and these scenarios may have a different
   applicability.

   In this document, that considers VPNs in the provider-provisioned
   scope, we consider the following scenarios :

      (a) the SP provisions the VPN tunnels and the security aspects.
      The intra-VPN routing aspects are under control of the VPN
      customer: the customer treats the provisioned tunnels as logical
      interfaces to CE devices at other VPN sites with a topology
      configured by the SP. It is clear that in this scenario, a very
      clear separation of management responsibilities between the
      customer and the service provider must be agreed upon (by
      specifying who gets to manage which specific parameters).

      (b) the SP provisions the VPN tunnels, the security aspects and
      the routing aspects in the CE devices. This means that the SP has
      complete control of the CE device which has most likely been
      provided to the customer by that SP.



De Clercq et al.           Expires July 2004                   [Page 4]


Internet Draft  draft-declercq-l3vpn-ce-based-as-00.txt    January 2004


   When dynamic routing is used, and the customers are responsible for
   the routing aspects on the CE devices (scenario (a)), the customers
   are free to choose the routing protocol(s) they want to use to
   distribute the reachability information (as long as these can be
   tunneled over IP or GRE, and as long as the peering CE devices
   support the subject routing protocols). Note that the CEs in
   different sites are direct routing peers. The Service Provider's PE
   (and P) devices do not interact with the CE devices (or any other
   devices in the customer network) for the purpose of distributing the
   routes of the customer's VPN.

   In the case that the SP manages all aspects on the CE device
   (scenario (b)), the customers are limited in the choice of their IGP
   to the IGPs that the SP provides on the CE devices.

   For provider provisioned CE-based IPsec VPNs, the topology of the VPN
   has an important impact on the scalability and the performance of the
   solution. All kinds of VPN topologies are supported by PP CE-based
   IPsec VPNs: hub and spoke topology, partial mesh topology, full mesh
   topology.

   Note that the use of the IPsec protocol suite is not a requirement
   per se with regards to provider provisioned CE-based VPNs. A SP could
   offer a VPN service that uses non-encrypted or authenticated site-
   to-site tunnels (using e.g. IP-in-IP, GRE, L2TP). This use of non-
   secured CE-to-CE tunnels is not recommended for security reasons
   though, and is not discussed in [CEVPN].

2. SP Provisioning model

   In provider provisioned CE-based VPNs, the SP is responsible for
   provisioning the CE devices with the VPN-specific configuration
   information.

   The SP will install a secure management 'channel' towards every CE
   device, over which it can securely provision that CE device. This can
   for example be a specific IPsec tunnel, a secured Layer-4 channel,
   etc.

   Note that [CEVPN] does not impose the use of a specific management
   protocol, as such allowing the described tunnel establishment, VPN
   routing distribution and data-plane security aspects to be de-coupled
   from the remote management and auto-discovery aspects. This allows
   different SPs to choose from their preferred remote management and
   auto-discovery solution, and for example to start with a manually
   (CLI-based) configured approach and finally migrate to a more
   scalable automatic approach. A complete 'vertical' solution would
   require the description of one (or some) remote management



De Clercq et al.           Expires July 2004                   [Page 5]


Internet Draft  draft-declercq-l3vpn-ce-based-as-00.txt    January 2004


   architectures: set of protocols, security of the management channel,
   definition of the transported object models, protocol dynamics and
   interaction with for example the tunneling establishment to
   accomplish complete auto-discovery.

   The SP will provision every CE device with the IP addresses of the
   peer CE devices the considered CE has to maintain a VPN tunnel with.
   The number of these peer CE devices depends on the number of sites
   the VPN contains and on the topology of the VPN.

   In [CEVPN], the SP is responsible for provisioning the CE-devices
   with the necessary 'security information' that is needed to establish
   and maintain IPsec Security Associations with the peer CE devices: a
   set of transforms to use with IPsec, tunnel property information and
   IKE credentials. Indeed, the CE devices that will use IPsec to
   protect the inter-site traffic, need (long-term) secure credentials.
   These credentials will be used by a key exchange protocol (such as
   IKE(v2)) to generate the actual (short-term) keys that will be used
   to protect the data traffic.

   One option for the (long-term) credentials is for the SP to directly
   configure them in the CE devices in the form of pre-shared keys
   (PSK). Alternatively, the SP can provide a public key infrastructure
   (PKI) to its VPN customers.

   When this key distribution system provides the CE devices with pre-
   shared keys, then this key distribution can be done together with the
   configuration of the CE devices by the SP management system. If
   alternatively, the SP provides its VPNs with a Public Key
   Infrastructure, this adds extra complexity, but also supports the
   potential for multi-SP CE-based VPNs. Both the pre-shared key
   approach and the PKI approach have their scalability implications
   (see section 12.8).

   For scalability purposes, the SP should use an 'automatic update'
   scheme such that the addition of a VPN site to an existing VPN
   requires the provisioning of only that new CE device (in contrast to
   the need to manually provision every existing CE device in the
   considered VPN). [CEVPN] does not describe such an 'automatic update'
   scheme, but the use of the mechanisms described in [CEVPN] is
   compatible with the use of any specific auto-discovery scheme. There
   currently is no IETF document describing a remote management protocol
   for CE-based IPsec VPNs, and describing a mechanism for CE-based
   IPsec VPN auto-discovery, but SPs commonly use remote management
   protocols such as for example CLI/Telnet/SSH or SOAP/XML/HTTP/SSH.

3. Supported Topologies and Traffic Types




De Clercq et al.           Expires July 2004                   [Page 6]


Internet Draft  draft-declercq-l3vpn-ce-based-as-00.txt    January 2004


   Provider provisioned CE-based IPsec VPNs allow for all desired
   topologies: fully meshed VPNs, hub and spoke VPNs, partially meshed
   VPNs, etc. Configuring a specific required VPN topology is a matter
   for the SP of provisioning every member CE device with the IP
   addresses of the appropriate peer CE devices the considered CE device
   has to maintain a VPN tunnel with.

   The customer VPN may carry both user data and control data. User data
   is the site-to-site traffic that carries user applications. The
   control data may contain site-to-site reachability information,
   keep-alives, etc.

   Provider provisioned CE-based IPsec VPNs are not targeted at
   providing Layer-2 services. By (GRE- or IP-) encapsulating Layer-2
   datagrams at the CE devices first, this traffic-type can be
   transported with CE-based IPsec VPNs.

   Carrying multicast traffic with CE-based IPsec VPNs will require the
   (GRE- or IP-) encapsulation of multicast-packets at the CE devices
   first. Multicast support in CE-based VPNs means for a basic scenario
   that CE devices need to be provisioned as to be able to duplicate
   multicast packets over the different VPN tunnels it maintains (which
   makes CE-based VPNs less resource efficient for Multicast traffic
   than e.g. PE-based VPNs).

4. Isolated Exchange of Data and Routing Information

4.1 Isolated forwarding of VPN data

   With CE-based IPsec VPNs, tunnels are deployed between CE devices.
   These tunnels are either IP-in-IP (or GRE) tunnels that are protected
   via IPsec in transport mode [TOUCH-VPN], or IPsec tunnel mode
   tunnels.

   In both cases, the forwarding in the shared infrastructure (access
   network and SP network(s)) is based on the IP addresses in the
   packets' outer IP header. These IP addresses can be public IP
   addresses (e.g. when the Internet is used for the CE-to-CE
   forwarding), or more generally IP addresses that belong the SP's
   addressing realm (these might be private or non-unique addresses when
   the interconnectivity between CEs is offered by one particular SP).

   Isolated exchange of data information is assured because IP routing
   and forwarding in the shared infrastructure takes care of forwarding
   the encapsulated IP packets to the correct destination CEs, using the
   destination address in the IPsec packets' outer headers. Indeed, the
   IP addresses in the outer headers are always IP addresses that belong
   to the CE devices and that are unique and routable in the SP backbone



De Clercq et al.           Expires July 2004                   [Page 7]


Internet Draft  draft-declercq-l3vpn-ce-based-as-00.txt    January 2004


   network(s).

   In addition, the customer IP packets are encrypted on every CE-to-CE
   part of the network; as such, no intermediate router or other device
   that does not belong to the same VPN can read the customer traffic,
   even if mis-routing or intercept occurs. This is particularly
   applicable in the case that the Internet is used for forwarding the
   CE-to-CE traffic, as the SP then doesn't have control on the actual
   path of the customer traffic.

   Encrypting the data packets also makes sure that packets that would
   arrive at a wrong destination CE, would not be visible by the
   receiving device: a CE device that receives a packet that it cannot
   decrypt using its existing Security Associations, will drop that
   packet. This makes sure that packets that don't belong to the
   considered VPN cannot (un)intentionally enter that VPN.

4.2 Constrained Distribution of Reachability Information

   The distribution of VPN IP reachability information among devices at
   the VPN sites is achieved by tunneling the reachability information
   (in the form of routing protocol messages) through the CE-to-CE VPN
   tunnels. CE devices must be configured to forward VPN reachability
   information only to those interfaces that are associated with the
   particular VPN : that is, the intra-site interfaces and the IPsec-
   protected interfaces (tunnels) that lead to the other sites that
   belong to the same VPN.

   As a CE only maintains VPN tunnels with CE devices that belong to the
   same VPN, the reachability information of one VPN site will only be
   distributed to other sites that belong to the same VPN. This also
   ensures that VPN routes will not be distributed into the Internet,
   and that Internet routes will not be distributed to VPN sites.

   One special case and exception to the above is when a CE device also
   provides Internet Access to the VPN. In this case, a firewall should
   take care of the Internet Gateway function.

   Of course, configuration errors by the SP can compromise the
   constrained distribution of reachability, and the overall security of
   the VPN (as discussed in section 5.2).

4.3 Hiding the Internal VPN Topology

   Note that in addition to the fact that the VPN reachability
   information distribution is isolated, the reachability information is
   also carried in an encrypted form on the CE-to-CE part of the network
   (by sending the routing information messages through the provisioned



De Clercq et al.           Expires July 2004                   [Page 8]


Internet Draft  draft-declercq-l3vpn-ce-based-as-00.txt    January 2004


   CE-CE IPsec tunnels). This means that even when misrouting or
   malicious snooping occurs, the global VPN topology and the internal
   topology of the VPN sites is not visible outside of the considered
   VPN.

   The SP should take care not to configure a CE device such that it
   distributes its VPN routes directly to the PE device (instead of to
   the peer CE devices through the tunnels). Unless this is required for
   specific Internet Access scenarios.

5. Security

   CE-based VPNs using IPsec are specifically applicable in situations
   where security is an important requirement and where the outsourcing
   of the complexity that comes with it is an important requirement.
   This type of VPNs allows the customer's data and control traffic to
   be secured (via encryption) on every shared part of the network,
   using the very secure and reliable IPsec protocol suite. The result
   of this is that the customer traffic is not only isolated (via
   tunnelling) from the other traffic that uses the same backbone, but
   that the customer traffic is also unreadable (because encrypted) and
   as such protected against e.g. malicious eavesdropping.

   IPsec encryption with optional authentication and replay attack
   prevention directly meet all of the security requirements in [REQS],
   as long as key distribution is not compromised.

   Note that the provider provisioned CE-based VPNs using IPsec do not
   protect against accidental or malicious mis-configuration by the
   service provider, as the SP manages the CE device, which in the most
   common operation sends and receives VPN traffic in the clear with
   other customer-premise equipment.

5.1 Protection of User Data

   Customer data, both control plane data and user plane data are
   encapsulated by IPsec before sent to the shared SP backbone. The
   customer data is protected until it reaches the peer CE. When the
   customer data is encrypted by IPsec, it is considered secure when it
   is being transferred through the shared IP backbone.

   As such, VPN user data traffic that is intercepted by an entity that
   was not meant to receive it (e.g. a CE device from an other VPN),
   will not be visible by that entity because it is encrypted. And
   traffic that doesn't belong to a particular VPN will not be able to
   enter that VPN because the traffic will not be recognized as
   belonging to one of the Security Associations the CE device
   maintains, and as such will be dropped by IPsec.



De Clercq et al.           Expires July 2004                   [Page 9]


Internet Draft  draft-declercq-l3vpn-ce-based-as-00.txt    January 2004


5.2 SP Security Measures

   The SP is responsible for preventing illegitimate traffic from
   entering a VPN. Preventing illegitimate traffic is a matter of
   ensuring that the CE devices are provisioned with the correct set of
   peer CE device IP addresses and with the correct security policies
   and parameters. An intentional or unintential misconfiguration by the
   SP whereby two CE devices that do not belong to the same VPN are
   configured as tunnel and IPsec peers, would make communication
   between two different VPNs possible in an undesired manner.

   The CE device should be secured against break-in, both from someone
   having physical access to the CE device as from the Internet. As the
   CE device is physically located at the customer's premises, securing
   the CE from compromise by someone physically present is a customer
   responsibility. Securing the CE device from breakins via the Internet
   is accomplished at the CE device by configuring it (by the SP) to
   limit the types of traffic that are accepted. Indeed, CE devices that
   do not provide Internet Access to the VPN over the CE-PE link must
   only accept traffic that is authenticated by this CE device as being
   either SP management traffic (carried by a secure and authenticated
   management channel) or intra-VPN traffic (carried by an IPsec secured
   tunnel). All other traffic must be dropped. CE devices that do
   provide Internet Access to the VPN over the CE-PE link should accept
   traffic that is authenticated by this CE device as being either SP
   management traffic or intra-VPN traffic; all other traffic should be
   sent to a firewall before accepting it into the VPN.

   A management channel exists between SP and the managed CE. It is
   important for SP to build a secure (authenticated and encrypted)
   management channel to prevent attacks from the adversary.

   The SP must make sure that breaking in into it's VPN management
   system is prohibited (both from someone physically present in the
   provider's premises, as via the Internet) in order not to compromise
   the secrecy of e.g. the VPN tunnel security parameters that the SP
   maintains.

   The SP must ensure the security of its key management infrastructure.

5.3 Security Framework Template

   Section 8 of [SEC-FW] provides ''a brief template that may be used to
   evaluate and summarize how a given PPVPN approach (solution) measures
   up against the PPVPN Security Framework.'' It further states ''an
   evaluation of a given PPVPN approach using this template should
   appear in the applicability statement for each PPVPN approach.'' The
   purpose of this subsection is to provide the information in the form



De Clercq et al.           Expires July 2004                  [Page 10]


Internet Draft  draft-declercq-l3vpn-ce-based-as-00.txt    January 2004


   required by this template.


     1. The approach provides complete IP address space separation for
      each L3 VPN.

      The base VPN approach completely addresses the requirement by
      maintaining and handling the VPN IP address prefixes only in the
      routing tables of devices that are specific to the particular VPN.
      They are distributed through encrypted tunnels between devices
      that are specific to the particular VPN.

     2. The approach provides complete L2 address space separation for
      each L2 VPN.

      The requirement is not applicable to the VPN approach because it
      is applicable only for L2VPN approaches while the discussed VPN
      approach is a L3VPN approach.

     3. The approach provides complete VLAN ID space separation for each
      L2 VPN.

      The requirement is not applicable to the VPN approach because it
      is applicable only for L2VPN approaches while the discussed VPN
      approach is a L3VPN approach.

     4. The approach provides complete IP route separation for each L3
      VPN.

      The base VPN approach completely addresses the requirement by
      having the CE devices distribute the VPN routes through CE-to-CE
      secure tunnels only.

     5. The approach provides complete L2 forwarding separation for each
      L2 VPN.

      The requirement is not applicable to the VPN approach because it
      is applicable only for L2VPN approaches while the discussed VPN
      approach is a L3VPN approach.

     6. The approach provides a means to prevent improper cross-
      connection of sites in separate VPNs.

      In the VPN approach, the requirement is addressed in a way that is
      beyond the scope of the VPN mechanisms. In PP CE-based IPsec VPNs,
      a site is made part of a particular VPN by configuring the CE
      device with the correct peer CE IP addresses, security policies
      and IPsec parameters. It's the SP's management function that is



De Clercq et al.           Expires July 2004                  [Page 11]


Internet Draft  draft-declercq-l3vpn-ce-based-as-00.txt    January 2004


      responsible not to provision certain CE devices as being part of
      the wrong VPN.

     7. The approach provides a means to detect improper cross-
      connection of sites in separate VPNs.

      If a routing algorithm is run on a particular CE-to-CE (tunnel)
      interface, any security procedures which the routing algorithm
      provides (e.g. MD5 authentication) can be used; this is outside of
      the scope of the VPN scheme. This does not help however if it is
      the SP who manages the routing aspects on both CE devices and
      misconfigures the routing aspects too.

     8. The approach protects against the introduction of unauthorized
      packets into each VPN.

      The base VPN approach completely addresses the requirement by
      authenticating all packets that are received at the CE device from
      a PE-CE link. Packets will only be accepted by the CE device if
      any the following conditions apply:

        - the packet is authenticated as an IPsec protected packet that
        comes from a peer CE device that belongs to the same VPN;

        - the packet is authenticated as belonging to the SP's
        management traffic manageing the considered CE device.

        - the CE device is configured to provide Internet Access to the
        VPN over the considered CE-PE link, and is configured to direct
        all packets to a firewall if they don't fullfil one of the two
        previous conditions;

      The described protection applies for unauthorized packets
      introduced in any of the following scenarios:

        a. In the CE-PE link
        b. In a single- or multi- provider PPVPN backbone
        c. In the Internet used as PPVPN backbone

     9. The approach provides confidentiality (secrecy) protection for
      PPVPN user data.

      The base VPN approach partially addresses the requirement by
      encrypting any PPVPN user data that leaves a particular site (at a
      CE device) and by only decrypting the PPVPN user data when it
      enters a particular site (at a CE device). This means that the
      user data secrecy is assured by encryption in every part of the
      network that is not in the customer's premises. The only reason



De Clercq et al.           Expires July 2004                  [Page 12]


Internet Draft  draft-declercq-l3vpn-ce-based-as-00.txt    January 2004


      why the requirement is only partially addressed is because the SP
      has access to the CE devices where the PPVPN user data appears in
      an unencrypted form.

      Confidentiality protection of user data within the customer
      premises is outside of the scope of PPVPN approaches.

      The described protection applies for PPVPN user data travelling in
      any of the following conditions:

        a. In the CE-PE link
        b. In a single- or multi- provider PPVPN backbone
        c. In the Internet used as PPVPN backbone

     10. The approach provides sender authentication for PPVPN user
      data.

      The base VPN approach partially addresses the requirement by IPsec
      processing any PPVPN user data that leaves and enters a particular
      site (at the CE device). The requirement is only partially
      addressed as the PPVPN user data is not authenticated as coming
      from a specific sender, but only as coming from a specific VPN
      site.

      The discussed protection applies for PPVPN user data travelling in
      any of the following conditions:

        a. In the CE-PE link
        b. In a single- or multi- provider PPVPN backbone
        c. In the Internet used as PPVPN backbone

     11. The approach provides integrity protection for PPVPN user data.

      The base VPN approach partially addresses the requirement by
      encrypting any PPVPN user data that leaves a particular site (at a
      CE device) and by only decrypting the PPVPN user data when it
      enters a particular site (at a CE device). This means that the
      user data integrity is assured by encryption in every part of the
      network that is not in the customer's premises. The only reason
      why the requirement is only partially addressed is because the SP
      has access to the CE devices where the PPVPN user data appears in
      an unencrypted form so that nothing prevents the SP from touching
      the PPVPN user data.

      Integrity protection of user data within the customer premises is
      outside of the scope of PPVPN approaches.

      The described protection applies for PPVPN user data travelling in



De Clercq et al.           Expires July 2004                  [Page 13]


Internet Draft  draft-declercq-l3vpn-ce-based-as-00.txt    January 2004


      any of the following conditions:

        a. In the CE-PE link
        b. In a single- or multi- provider PPVPN backbone
        c. In the Internet used as PPVPN backbone

     12. The approach provides protection against replay attacks for
      PPVPN user data.

      The base VPN approach completely addresses the requirement by
      IPsec processing any PPVPN user data that leaves and enters a
      particular site (at the CE device).

      The described protection applies for PPVPN user data travelling in
      any of the following conditions:

        a. In the CE-PE link
        b. In a single- or multi- provider PPVPN backbone
        c. In the Internet used as PPVPN backbone

     13. The approach provides protection against unauthorized traffic
      pattern analysis for PPVPN user data.

      The VPN approach does not meet the requirement. Even though the
      PPVPN user data is encrypted over every public or SP's network
      part, nothing prevents a third party from examining the outer IP
      header's IP addresses (the CE WAN addresses), the traffic timing,
      volume etc. Preventing against this threat is outside of the scope
      of the discussed VPN approach.

     14. The control protocol(s) used for each of the following
      functions provide for message integrity and peer authentication:

       a. VPN membership discovery

         The [CEVPN] approach requires any VPN membership discovery
         scheme to fulfil the above requirements, though [CEVPN]
         currently does not specify a membership discovery mechanism.

       b. Tunnel establishment

         The base VPN approach completely addresses the requirement by
         using the IKE(v2) protocol for the tunnel establishment.

       c. VPN topology and reachability advertisement

         The base VPN approach partially addresses the requirement
         because the advertisement of VPN topology and reachability is



De Clercq et al.           Expires July 2004                  [Page 14]


Internet Draft  draft-declercq-l3vpn-ce-based-as-00.txt    January 2004


         done through the IPsec protected CE-to-CE tunnels. The only
         reason why the requirement is only partially addressed is
         because the Service Provider has access to the CE device and as
         such could influence topology advertisements.

         i.  PE-PE

            The requirement is not applicable to the VPN approach
            because the PE devices are not participating in the VPN
            topology and reachability advertisement.

         ii. PE-CE

            The requirement is not applicable to the VPN approach
            because the PE devices are not participating in the VPN
            topology and reachability advertisement.

       d. VPN provisioning and management

         The [CEVPN] approach requires the VPN provisioning and
         management function to fulfil the above requirements, though
         [CEVPN] currently does not specify a provisioning and
         management approach.

       e. VPN monitoring and attack detection and reporting

         The VPN approach itself does not meet the requirement: the
         protocols and procedures for monitoring the VPNs are outside
         the scope of the VPN scheme.

     15. Describe the protection, if any, the approach provides against
         PPVPN-specific DOS attacks (i.e. Inter-trusted-zone DOS
         attacks):

       a. Protection of the service provider infrastructure against Data
         Plane or Control Plane DOS attacks originated in a private
         (PPVPN user) network and aimed at PPVPN mechanisms.

         For the SP's network infrastructure (PE and P routers), there
         is no difference between a DOS attack originated in a PPVPN
         user network using CE-based IPsec VPNs as compared to a DOS
         attack originated in any other user network.

         The matter in which the SP's network is protected against DOS
         attacks originated in a user network is outside of the scope of
         the CE-based IPsec VPN architecture.

       b. Protection of the service provider infrastructure against Data



De Clercq et al.           Expires July 2004                  [Page 15]


Internet Draft  draft-declercq-l3vpn-ce-based-as-00.txt    January 2004


         Plane or Control Plane DOS attacks originated in the Internet
         and aimed at PPVPN mechanisms.

         The protection of the SP's VPN management infrastructure
         against DOS attacks originating from the Internet is not
         different than the protection of any other SP's management
         infrastructure against DOS attacks originating from the
         Internet.

       c. Protection of PPVPN users against Data Plane or Control Plane
         DOS attacks originated from the Internet or from other PPVPN
         users and aimed at PPVPN mechanisms.

         As the CE device's WAN IP address is routable in the SP's
         backbone network (and possibly in the Internet), nothing
         prevents other PPVPN users (and possibly Internet users) to
         send excessive amounts of traffic to a particular CE device.
         The effect of such an attack would be the same as the effect of
         a DOS attack on any device that uses IPsec secured connections.

         Extra protection against such DOS attacks could be achieved by
         having the PE devices implement VPN-specific access control
         lists. At first glance this appears to be in contradiction with
         one of the CE-based VPN characteristics that PE devices be VPN
         unaware. However, in this case the knowlege required at PE
         devices would be limited to knowledge of which other devices in
         the Internet are permitted to send traffic to the CE. This does
         not, for example, require any PE knowledge of the private
         network address space nor of the private network routing.

     16. Describe the protection, if any, the approach provides against
         unstable or malicious operation of a PPVPN user network:

       a. Protection against high levels of, or malicious design of,
         routing traffic from PPVPN user networks to the service
         provider network.

         Intra-VPN reachability information is never distributed to SP's
         P or PE devices. Dynamic routing between CE and PE devices may
         however be used in the SP's routing space for the purpose of
         distributing the CE's WAN IP address into the SP's backbone
         network. This is not different however from any non-VPN
         (customer) access router peering with a SP's edge router, and
         the same protection mechanisms may be used (such as limiting
         the amount of PE resources dedicated for the considered routing
         peer).

       b. Protection against high levels of, or malicious design of,



De Clercq et al.           Expires July 2004                  [Page 16]


Internet Draft  draft-declercq-l3vpn-ce-based-as-00.txt    January 2004


         network management traffic from PPVPN user networks to the
         service provider network.

         The discussed CE-based IPsec VPN approach partially protects
         the service provider network from excessive or malicious
         network management traffic originated in the PPVPN user
         networks. Indeed, except for the CE devices, no other devices
         in the customer's private network have the ability to send
         traffic to service provider devices. However, for attacks from
         the CE device itself, the situation is no different from
         attacks from devices with normal Internet access. In addition,
         for attacks originated by other devices in the customer network
         that have Internet access via some CE device, the situation is
         no different than for other  user devices (not belonging to a
         CE-based IPsec VPN) that have Internet access. Protection
         against such attacks is out of the scope of CE-based IPsec
         VPNs.

       c. Protection against worms and probes originated in the PPVPN
         user networks, sent towards the service provider network.

         With CE-based VPNs, the same protection mechanisms against
         worms and probes originated in the PPVPN user networks apply as
         against worms and probes originated from e.g. the Internet;
         these mechanisms are outside of the scope of the considered VPN
         approach.

6. Addressing

   In CE-based IPsec VPNs, it is assumed that the CE devices have one IP
   address (their 'WAN' IP address) that is public or that belongs to
   the SP's routing realm. These are the IP addresses that will be used
   in the encapsulating (outer) IP headers of the tunneled packets that
   will be sent on the CE-PE link. Beyond use of this CE IP address
   (that will never be used by the customer's IGP for intra-site routing
   and forwarding), there is no constraint on the IP addresses that are
   internally used within the VPN. In summary, every CE device has to
   have one WAN IP address that is routable in the SP's IGP and that
   doesn't need to be routable in the customer's IGP. In order to
   achieve this, the CE devices will operate in two distinct routing
   spaces (that they need to keep separate in the CE): the VPN routing
   space, and the SP's routing space.

   Overlapping customer addresses are supported in different VPNs
   (meaning that different VPN customers that are provisioned by the
   same (or different) SP may use overlapping address spaces). There is
   no requirement that such addresses be in conformance with RFC 1918.
   There is no requirement that customer VPN-internal addresses be



De Clercq et al.           Expires July 2004                  [Page 17]


Internet Draft  draft-declercq-l3vpn-ce-based-as-00.txt    January 2004


   distinct from addresses in the SP network.

   Any set of addresses used in the VPN can be supported, irrespective
   of how they are assigned, how well they aggregate, whether they are
   public or private. However, the set of addresses which are reachable
   from a given VPN site must be unique.

   Network address translation for packets leaving/entering a VPN is
   possible, and is transparent to the VPN scheme.

7. Interoperability and Interworking

   As all the different types of Layer-3 VPNs are IP networks, they can
   of course interwork in the same way that any two IP networks can
   interwork. For example, a single site can contain a CE router that
   participates in one VPN scheme (e.g. a Provider Provisioned CE-based
   VPN solution) and a CE router of another VPN scheme (e.g. a CE that
   is attached to a 2547bis PE's VRF), and these CE routers could be IGP
   peers, or they might even be the same CE router. This would result in
   the redistribution of routes from one type of VPN to the other,
   providing the necessary interwoking.

8. Network Access

8.1 Access types supported

   CE-based IPsec VPNs are applicable in every access scenario where the
   CE device has IP connectivity with the PE device. Every CE device
   only needs one IP address that is routable in the shared backbone.
   This CE-PE IP connectivity may be provided over any Layer-1 and
   Layer-2 infrastructure (PPP, Ethernet, ATM, Frame Relay, etc.).

8.2 Access QoS support

   Providing QoS in the access network is a non VPN-specific feature.
   Any existing layer-2 QoS mechanism could for example be used for this
   purpose. General QoS aspects are discussed in section 13.

8.3 Access security support

   CE-based IPsec VPNs have the additional advantage that the security
   of the VPN is not dependent on the security of the access network.
   Customer data packets traverse the access network in an encrypted
   way.

   Note however that, as IP packets that are sent from CE to PE are not
   authenticated by the PE devices, the CE-based IPsec VPN model does
   not protect against resource spoofing and Denial of Service Attacks



De Clercq et al.           Expires July 2004                  [Page 18]


Internet Draft  draft-declercq-l3vpn-ce-based-as-00.txt    January 2004


   by invalid users. An intruder can still inject traffic on the access
   link, which will be forwarded by the PE device towards the destined
   CE device.

   When a CE device that is configured for a certain VPN would be moved
   and placed in a different location (e.g. in a different VPN's
   premises), the following scenarios are possible:

   - the CE device would receive a new WAN IP address, and as the other
   CE devices belonging to the original VPN will not recognise this new
   IP address, this would prevent the establishment of VPN tunnels from
   this new location; in addition, the SP's management system would
   detect this connectivity loss from the old IP address;

   - the CE device would keep its own WAN IP address but without
   distributing this outside of its new location via a routing protocol;
   this would make the CE device unreachable and would prevent the
   establishment of VPN tunnels from this new location;

   - the CE device would keep its own WAN IP address and distribute it
   via a routing protocol via its new location into the SP's backbone;
   in this situation, the CE device will be able to access the other VPN
   from within its new location. This situation should not be allowed by
   prohibiting the movement of the CE devices outside of the VPN
   customer's premises.

   When the configuration of a CE device, located at the VPN customer's
   premises, is deliberately or unintentionally changed without prior
   agreement of the SP, access to the VPN from the Internet or from
   sites belonging to different VPNs may become possible, and VPN data
   may leak out of the VPN. As such, the customer must make sure that
   access to the CE device is restricted to the VPN SP, or to authorized
   and knowledgeable people from the customer's IT department.

   Note that it is not possible for a particular customer to
   intentionally misconfigure its CE device in an attempt to access some
   other VPN. Indeed, there is no way for this particular customer to
   know the necessary keys and authentication credentials that are
   specific to every VPN tunnel.

9. Service Access

9.1 Internet Access

   Internet access and VPN access are possible from the same site.
   Different ways to accomplish this service are possible. One
   restriction is that the VPN's internal addresses must be distinct
   from the IP addresses of the systems which must be reached via the



De Clercq et al.           Expires July 2004                  [Page 19]


Internet Draft  draft-declercq-l3vpn-ce-based-as-00.txt    January 2004


   Internet. The required NAT and firewall functions are implemented in
   one or more of the VPN's CE devices or dedicated gateways.

   A typical scenario is that the CE would have to direct all non-IPsec
   traffic to a firewall.

   When the CE-based VPN traffic shares the access (CE-PE part of the
   network) with Internet-traffic, a denial of service attack from sites
   outside the VPN is possible.

9.2 Hosting, ASP, Other Services

   Externally provided services can be accessed from the VPN through a
   firewall located at a VPN site, provided that it can be addressed
   with an IP address that is not otherwise in use within the VPN. If
   the considered service is offered by the same server for a number of
   VPNs, and a certain client with a non-unique IP address is accessing
   the server, NAT has to be performed at the client's CE device.

10. SP Routing

   Routing through the backbone(s) is independent of the VPN scheme, and
   is unaffected by the presence or absence of VPNs. The only impact is
   that the backbone routing (or Internet routing) must carry the routes
   to the CE devices.

   The use of CE-CE IP tunnels is not impacted by (and is thus
   complementary with) any PE-PE tunneling that the Network Provider
   might deploy in its backbone network (e.g. PE-PE MPLS LSPs for
   Traffic Engineering reasons).

11. Migration Impact

   The migration impacts that are discussed here deal with :

      (i) a customer who migrates from a legacy (frame-relay type) IP
      over Layer-2 VPN to a provider provisioned CE-based IPsec VPN, or

      (ii) a customer who migrates from a customer provisioned CE-based
      IPsec VPN to a provider provisioned CE-based IPsec VPN.

11.1 Functions to be added to the customer's CE device

   - migration scenario (i)

      Assuming that the customer CE router has IP connectivity with the
      PE router, the following functionality needs to be added on the
      customer equipment:



De Clercq et al.           Expires July 2004                  [Page 20]


Internet Draft  draft-declercq-l3vpn-ce-based-as-00.txt    January 2004


         - the customer's CE device needs to implement the IPsec
         protocol suite and an IPsec key exchange functionality, such as
         IKE.

         - the CE device needs to support the secure management protocol
         that is used by the SP's management system.

         - the CE device's routing protocol(s) needs to treat the
         different IPsec secured CE-to-CE tunnels as independent
         interfaces.

         - in the scenario where both the customer and the Service
         Provider have management responsibilities on the CE device, the
         CE device must support a management security infrastructure
         that allows for the separation of management responsibilities
         according to specified rules

         - the CE device must have its frame relay port replaced with
         whatever is needed to access the SP's network (unless this is
         FR)

         - the customer's virtual topology may need to be redesigned,
         including a study of the impact of this design on the
         customer's IGP. Note that it is not necessarily the case that
         the FR DLCI's should be replaced one by one with IPsec SAs.

   - migration scenario (ii)

      - the customer's CE device needs to implement the IPsec key
      exchange functionality (IKE(v2))

      - the CE device needs to support the secure management protocol
      that is used by the SP's management system.

      - if a public key infrastructure is provided by the SP, the CE
      device needs to support this infrastructure

      - in the scenario where both the customer and the Service Provider
      have management responsibilities on the CE device, the CE device
      must support a management security infrastructure that allows for
      the separation of management responsibilities according to
      specified rules

11.2 functions to be added by the Service Provider

   - The SP needs to deploy a secure management system that is able to
   configure and manage a large amount of CE devices per VPN customer.




De Clercq et al.           Expires July 2004                  [Page 21]


Internet Draft  draft-declercq-l3vpn-ce-based-as-00.txt    January 2004


   - In the case that the SP is also the backbone network provider, the
   SP needs to provide IP connectivity between CE devices.

   - The SP needs to be able to define topology, security protection,
   and reachability attributes for each customer VPN it manages.

   - The SP needs to be able to configure each managed CE, based on the
   attributes of the VPN that the CE belongs to.

   - The SP needs to be able to update each VPN, based on customer needs
   from time to time. Changes such as adding or deleting VPN sites,
   upgrading VPN functions are common.

   - The SP may need to have the capability of managing and monitoring
   the SLA of the cusomer's VPN.

   - The SP needs to be able to gather and create appropriate usage and
   accounting report for each VPN it manages.

12. Scalability

   This section discusses how certain specific VPN-metrics affect the
   scalability of the VPN-solution.

12.1 Number of supported VPNs

   It is assumed that a certain site is only part of one VPN.
   Architectures that allow sites to be a member of multiple VPNs will
   have impact on the CE devices and on the supported addressing
   schemes.

   When a site can be a member of only one VPN, the number of VPNs that
   a SP can support has an impact on the SP's management system.

   For every supported VPN, the SP's management system will need to be
   able to provision every site's CE device that belongs to that VPN.
   The management system will need to maintain information that is
   specific for every VPN site (IP addresses of the other peering sites
   in the considered VPN, security information, etc.).

   The number of VPNs that a SP can support is dependent on the number
   of sites per VPN and is limited by the number of management sessions
   the SP's VPN management system can support and the amount of VPN
   information the SP's VPN database can maintain.

   Note however that when the number of VPNs increases, the SP can
   deploy additional management systems with their own VPN databases :
   the SP can use multiple independent management systems as there is no



De Clercq et al.           Expires July 2004                  [Page 22]


Internet Draft  draft-declercq-l3vpn-ce-based-as-00.txt    January 2004


   interaction between different VPNs.

12.2 Number of sites per VPN

   In a fully-meshed VPN, the number of sites per VPN has an impact on
   the CE devices within that VPN, on the SP's management system and on
   the SP's key distribution system.

   In one particular fully-meshed VPN, for every additional site, a
   certain CE router needs to maintain an additional VPN tunnel (in the
   form of an additional IPsec Security Association) and additional
   reachability information.

   For every VPN site, the SP's management system will need to maintain
   some information and will need to be able to establish a management
   connection to the site's CE device.

   The number of sites per VPN (n) has an impact of O(n) on the CE
   devices, and has an impact of O(n^2) on the number of tunnels that
   the SP management system needs to provision (in a fully-meshed VPN).

   In VPNs that are not fully meshed (partial mesh or hub and spoke
   topology), the impact of the number of sites per VPN on the
   scalability of the system is reduced.

   In a hub and spoke VPN, the CE of the hub site still needs to
   maintain as many tunnels as there are other sites (n-1), and will
   still need to maintain the complete set of VPN routes. The CEs of the
   spoke sites on the other hand, need only to maintain one tunnel
   towards the hub CE. Moreover, in a hub and spoke topology, the spoke
   CEs may not need to maintain the other CE's routes: a default route
   towards the hub CE may suffice. The SP's management system needs to
   maintain O(n) tunnels in a hub and spoke VPN.

   Note that the total number of CE devices to support may prove to be
   the most critical scalability factor for the SP's management system,
   especially in terms of automatically updating the CE devices'
   configuration upon a certain change. The reliability mechanism
   involved may have a per-CE scaling component.

12.3 Number of tunnels per VPN

   The number of tunnels per VPN depends on the number of sites per VPN
   and on the VPN topology.

   The hub-and-spoke topology requires the least amount of tunnels to
   provide inter-connection among all participating sites (O(n)), while
   a fully meshed VPN requires the most tunnels (O(n^2)).



De Clercq et al.           Expires July 2004                  [Page 23]


Internet Draft  draft-declercq-l3vpn-ce-based-as-00.txt    January 2004


   Aside from the number of tunnels, the VPN security attributes also
   affect the scalability of a VPN. For example, when a VPN uses 3DES as
   the tunnel encryption scheme, the total number of tunnels that a hub
   may support may be smaller than the case when e.g. DES is selected.

   The number of tunnels that are required specifies the number of SAs
   that need to be maintained, and this has an impact on the number of
   keys to be supported and thus on the SP's key distribution system.

12.4 Number of tunnels per CE

   The number of tunnels to be supported by a CE device has implications
   on the performance of that CE device : every supported tunnel
   represents a new interface; every tunnel is protected by a specific
   Security Association.

   The overall CE performace will decline when the number of tunnels
   increases as the memory consumption increases and the processing
   increases: every Security Association that protects a tunnel needs to
   be frequently re-negotiated. This (frequent) re-keying of existing
   (permanent) tunnels requires a certain amount of processing (key
   generation) and of control protocol message exchanges (via IKE or an
   alternative key exchange protocol).

   The number of tunnels a CE will need to support at a given time can
   be dependent on whether 'traffic-driven' tunnel set-up or 'traffic-
   independent' tunnel set-up is used.

   Note that the use of traffic-driven tunnel set-up has important
   implications. In traffic-driven tunnel establishment, if a certain
   tunnel does not carry traffic during a certain amount of time, the
   IPsec SA will be removed. When traffic starts flowing again, a new
   Security Association will need to be established first. The two
   tunnel endpoints will re-negotiate the necessary SAs, and will
   generate the necessary key material. This not only introduces control
   protocol message exchanges but also delay in the forwarding of the
   user packets.

   Note also that the inter-site reachability distribution interacts
   with traffic-driven tunnel establishment : routing protocols send
   routing updates and keep-alive messages, even when no actual user
   traffic is flowing.

   As such, traffic-driven tunnel set-up may be applicable in CE-based
   IPsec PPVPNs that use statically provisioned routing information. The
   use in an environment that dynamically distributes inter-site
   reachability is much more complicated and not advised.




De Clercq et al.           Expires July 2004                  [Page 24]


Internet Draft  draft-declercq-l3vpn-ce-based-as-00.txt    January 2004


   Note that the number of tunnels per CE has a scalability impact on
   the customer's IGP, as every tunnel is seen as an interface from the
   IGP point of view.

12.5 Number of routes per VPN

   The number of routes per VPN has only an impact on the CE devices.
   The SP network and management system are not affected by the number
   of routes per VPN (except when static routes are configured by the
   SP).

   In a fully-meshed VPN, the number of routes a VPN can support is
   limited by the maximum number of routes that the 'smallest' CE can
   maintain.

   In a VPN with a hub and spoke topology, the number of routes a VPN
   can support is limited by the maximum number of routes that the hub
   CE can maintain (as the spoke CEs can be provisioned with a default
   route towards the hub CE).

   Independent of the VPN topology, the number of routes that a PE
   device needs to maintain is limited to one per CE interface.

12.6 Impact of configuration changes

   The impact of configuration changes (e.g. the addition of a new site
   to an existing VPN) highly depends on the 'auto-discovery' mechanism
   used by the SP. The specifics of the autodiscovery mechanism used
   (reliability etc.) may have an impact on:

   - the number of devices to separately provision,

   - the increase of control traffic,

   - the convergence time, etc.

   Note that [CEVPN] does not specify an auto-discovery mechanism.

   Note also that other factors such as the rate of configuration
   changes may have an impact on the scalability of the VPN service.

12.7 Performance impact

   The deployment of a CE-based VPN will have a performance impact on
   the system.

   With regards to the control plane, the CE devices will need to
   negotiate Security Associations and generate cryptographic key



De Clercq et al.           Expires July 2004                  [Page 25]


Internet Draft  draft-declercq-l3vpn-ce-based-as-00.txt    January 2004


   material. The initial SA negotiations are triggered by SP
   provisioning or by traffic flowing (traffic-driven SA setup).
   Established SA's need to be frequently 'refreshed' : new key material
   needs to be generated and exchanged. As such, the maintenance of SA's
   introduces a constant load on the CE's control plane.

   In the data-plane, the use of IPsec protected CE-to-CE tunnels means
   that every IP packet that is sent from one CE to another needs to be
   encrypted and/or authenticated by IPsec. This affects the performance
   as it requires additional processing and introduces some delay.

   Note that in a hub and spoke topology, this impact is doubled: a
   packet that flows from one spoke site to an other spoke site will be
   encrypted at the first spoke's CE, decrypted at the hub CE, routed at
   the hub CE, encrypted at the hub CE and finally decrypted at the
   destination spoke's CE router.

12.8 Scalability of Key Distribution Infrastructure

   In the case where pre-shared keys are used by IPsec for the CE-to-CE
   SA, the Service Provider needs to maintain pre-shared keys for every
   CE-CE pair of the same VPN that need to protect a VPN tunnel.
   Securely storing these pre-shared keys, and more or less frequently
   generating and distributing fresh pre-shared keys for all established
   SAs may become a scalability concern when the number of SAs grows and
   when the rate of site addition/deletion grows.

   In the case where private/public keys are used in combination with
   digital certificates, the Service Provider must install/use a public
   key infrastructure (PKI). This has a number of implications for the
   SP. The SP needs to maintain a database that contains the digitally
   signed public keys of every participating CE device. The SP also
   needs to maintain a revocation database that contains the digitally
   signed public keys that are no longer valid (e.g. for removed VPN
   sites). The SP needs for every CE device to verify the integrity of
   the <CE-device, public Key> association. The SP must make sure that
   the CE device's private keys are (more or less frequently) re-
   generated, and must as a result of this re-keying generate a new
   certificate and distribute this. The SP must (more or less
   frequently) refresh its own private and public key that it uses to
   sign the necessary certificates, and as a result of this sign all
   existing certificates with its new keying material.

   These procedures are not different from any other PKI, and the
   scalability is dependent of the number of end-nodes (CE devices), of
   the number of secure connections to maintain and on the dynamicity of
   end node creation/deletion (VPN join and leave operations.)




De Clercq et al.           Expires July 2004                  [Page 26]


Internet Draft  draft-declercq-l3vpn-ce-based-as-00.txt    January 2004


13. QoS, SLA

   In addition to the VPN service (reachability and security) from the
   SP, the VPN customer may want to acquire QoS features for its VPN.
   Dependent on the business scenario, the SLA will be provided by the
   VPN SP or by the Network Provider.

   Note that the fact that customer IP packets are encapsulated (and
   possibly encrypted) at the CE devices has an impact on the QoS
   treatment of the IP packets: QoS-related information inside the
   customer IP packets may become invisible.

   An eventual translation of QoS-related fields (e.g. DSCP) in the
   inner IP header to QoS-related fields in the outer IP headers need to
   be done at the CE-level and configured as such by the SP. Also the
   'policing' rules (e.g. certain customers not being allowed to use
   certain QoS values, etc.) need to be configured by the SP in the CE
   devices. The security infrastructure of the CE device must prevent
   the customer from messing with this provider-controlled
   configuration.

   The CE-CE tunneling applied in Provider Provisioned CE-based IPsec
   VPNs easily meets the DSCP transparency requirements of [REQS].

14. Management

14.1 Configuration/provisioning

   Configuration by the SP comes in at two levels: VPN level and CE
   level.

   At the VPN level, the topology and security requirements must be
   determined. Common topologies include hub and spoke and full mesh.
   For large VPNs, a combination of simple topologies may be used, such
   as a full mesh core that connects individual hub and spoke
   topologies. A given VPN must have a general security grade selected,
   since every link of the VPN is expected to meet this security grade.
   In addition to the topology and security information, at the VPN
   level, when no inter-site tunneled dynamic routing is required, the
   reachability information may also be determined.

   At the CE level, each CE must know all of its CE peers in the same
   VPN, the security parameters, the tunnel attributes, the device or
   tunnel authentication credentials, and any associated routing setups.


14.2 Customer management




De Clercq et al.           Expires July 2004                  [Page 27]


Internet Draft  draft-declercq-l3vpn-ce-based-as-00.txt    January 2004


   Since a customer outsources the VPN provisioning and management, it
   may not have the permission to change any of the VPN parameters in
   its CE devices.

   In a scenario where both the customer and the provider have VPN
   management responsabilities, the provider's management protocol will
   need to specify which parameters can be customer managed and which
   parameters cannot. An agreement between the customer and the service
   provider will need to specify which of the parameters that can be
   managed by the customer will be managed by the customer.

   It must be possible for the SP to retrieve the CE's actual
   configuration state, in order to verify whether the customer has not
   violated the agreement (e.g. an unintentional misconfiguration, or an
   intentional theft of QoS service).

14.3 SLA monitoring

   It must be possible for the SP to retrieve the CE's actual
   configuration state, in order to verify whether the customer has not
   violated the agreement (e.g. an unintentional misconfiguration, or an
   intentional theft of QoS service). In addition to this, the SP may
   want to collect statistics by retrieving specific files from the CE
   devices.

14.4 Security

   The security aspects of the VPN management system are extremely
   important.

   De SP's management system itself needs to be secured against
   misconfiguration, intrusion and denial-of-service attacks.

   De management protocol that is used to remotely provision the CE
   devices needs to provide for mutual authentication, encryption of the
   transported data, etc.

   The CE device must support the necessary security architecture,
   allowing for eventual dual-management, firewall support etc.

14.5 Fault handling

   The faults that occur in the network(s) that interconnect CEs have an
   impact on the CE-to-CE routing.

   If the timers used for the CE-to-CE routing peering are shorter than
   the timers used for the routing peering within the service
   provider(s) network, then a single failure within a service provider



De Clercq et al.           Expires July 2004                  [Page 28]


Internet Draft  draft-declercq-l3vpn-ce-based-as-00.txt    January 2004


   network may look like a collection of uncorrelated failures in the
   VPN.

   Moreover, since a CE doesn't really "know" what causes the failure,
   the CE may react to such a failure by re-routing along some other
   tunnel, while this other tunnel may be also affected by the same
   failure. As a result, this would slow down routing convergence within
   the VPN.

   To avoid the problems mentioned above one may consider making the
   timers used for the CE-to-CE peering longer than the timers used for
   the routing peering within the service provider network (so that
   failures within the service provider network would be "invisible" to
   the CE-CE tunnels). But that has its own set of problems.  While this
   may be possible to accomplish within a single routing domain (one
   needs to appropriately set the IGP timers within the domain), doing
   this in a network that includes more than one routing domain may be
   fairly problematic (as timers include both IGP and BGP timers, and
   moreover, timers include IGP timers in several routing domains).
   Moreover, making the timers used for the CE-to-CE peering over the
   tunnels longer than the timers used for the routing peering within
   the service provider network would increase the amount of traffic
   that will be "black holed" in the case of CE failures.

15. Security considerations

   This draft contains sections that discuss in detail the security of
   provider provisioned CE-based IPsec VPNs.

16. Acknowledgements

   The authors of this draft would like to thank Eric Rosen, Yakov
   Rekhter, Tom Nadeau, Marco Carugi and Ross Callon for their valuable
   comments and suggestions.

17. References

   [ASGUIDE]   Sumimoto J., et al., "Guidelines of Applicability State-
               ments for PPVPNs," work in progress.

   [CEVPN]     De Clercq J., et al., "Provider Provisioned CE-based Vir-
               tual Private Networks using IPsec", draft-ietf-l3vpn-ce-
               based, work in progress.

   [FRMWORK]   Callon R., et al., "A Framework for Layer-3 Provider Pro-
               visioned Virtual Private Networks," work in progress.

   [REQS]      Carugi M., McDysan D., et al., "Service Requirements for



De Clercq et al.           Expires July 2004                  [Page 29]


Internet Draft  draft-declercq-l3vpn-ce-based-as-00.txt    January 2004


               Layer-3 Provider Provisioned Virtual Private Networks,"
               work in progress

   [SEC-FW]    Fang L., et al., "PPVPN Security Framework", work in pro-
               gress

   [TOUCH-VPN] Touch J., Eggert L., "Use of IPsec Transport Mode for
               Dynamic Routing", work in progress

   [1918]      Rekhter Y., et al., "Address Allocation for Private
               Internets," RFC 1918, February 1996.

   [2026]      Bradner S., "The Internet Standards Process - Revision
               3," RFC 2026, October 1996.


18. Authors' Addresses

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

   Cliff Wang
   E-mail: cliff.wang@us.army.mil

   Dave McDysan
   WorldCom
   22001 Loudoun County Parkway
   Ashburn VA 20147, USA
   E-mail: dave.mcdysan@wcom.com




















De Clercq et al.           Expires July 2004                  [Page 30]