Internet DRAFT - draft-declercq-ppvpn-ce-based-as
draft-declercq-ppvpn-ce-based-as
Network Working Group Jeremy De Clercq
INTERNET DRAFT Alcatel
<draft-declercq-ppvpn-ce-based-as-01.txt> Cliff Wang
SmartPipes
Dave McDysan
Worldcom
June 2002
Expires December, 2002
Applicability Statement for
Provider Provisioned CE-based Virtual Private Networks
using IPsec
<draft-declercq-ppvpn-ce-based-as-01.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.
This document is submitted to the IETF's Provider Provisioned Virtual
Private Network (ppvpn) working group. Comments should be addressed
to WG's mailing list at ppvpn@ppvpn.francetelecom.com. The charter
may be found at http://www.ietf.org/html.charters/ppvpn-charter.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
De Clercq et al. Expires December 2002 [Page 1]
Internet Draft draft-declercq-ppvpn-ce-based-as-01.txt June 2002
describes how provider provisioned CE-based approaches meet the key
requirements that are outlined in the PPVPN Applicability Statements
Guideline document [ASGUIDE].
Table of Contents
De Clercq et al. Expires December 2002 [Page 2]
Internet Draft draft-declercq-ppvpn-ce-based-as-01.txt June 2002
0. Sub-IP Area Summary ........................................ 3
1. Introduction ............................................... 4
2. SP Provisioning Model ...................................... 6
3. Supported Topologies and Traffic Types ..................... 7
4. Isolated Exchange of Data and Routing Information .......... 8
4.1 Isolated forwarding of VPN data ............................ 8
4.2 Constrained Distribution of Reachability Information ....... 8
4.3 Hiding the Internal VPN Topology ........................... 9
5. Security ................................................... 9
5.1 Protection of User Data .................................... 9
5.2 SP Security Measures ....................................... 10
6. Addressing ................................................. 10
7. Interoperability and Interworking .......................... 10
8. Network Access ............................................. 11
8.1 Access types supported ..................................... 11
8.2 Access QoS support ......................................... 11
8.3 Access security support .................................... 11
9. Service Access ............................................. 11
9.1 Internet Access ............................................ 11
9.2 Hosting, ASP, Other Services ............................... 12
10. SP Routing ................................................. 12
11. Migration Impact ........................................... 12
11.1 Functions to be added to the customer's CE device .......... 12
11.2 Functions to be added by the Service Provider .............. 13
12. Scalability ................................................ 13
12.1 Number of supported VPNs ................................... 13
12.2 Number of sites per VPN .................................... 14
12.3 Number of tunnels per VPN .................................. 15
12.4 Number of tunnels per CE ................................... 15
12.5 Number of routes per VPN ................................... 16
12.6 Impact of configuration changes ............................ 16
12.7 Performance impact ......................................... 16
13. QoS, SLA ................................................... 17
14. Management ................................................. 17
14.1 Configuration/provisioning ................................. 17
14.2 Monitoring ................................................. 18
14.3 Customer management ........................................ 18
14.4 SLA monitoring ............................................. 18
14.5 Security ................................................... 18
14.6 Fault handling ............................................. 18
15. Security considerations .................................... 19
16. Acknowledgements ........................................... 19
17. References ................................................. 19
18. Authors' Addresses ......................................... 20
0. Sub-IP area summary
De Clercq et al. Expires December 2002 [Page 3]
Internet Draft draft-declercq-ppvpn-ce-based-as-01.txt June 2002
This document is an output of the design team formed to develop
applicability statements for Layer 3 PPVPNs in the PPVPN working
group. As such this work fits within the scope of the PPVPN working
group. This document discusses the applicability of CE-based IPsec
approaches for PPVPNs.
1. Introduction
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;
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.
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
De Clercq et al. Expires December 2002 [Page 4]
Internet Draft draft-declercq-ppvpn-ce-based-as-01.txt June 2002
purposes.
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 tunnels, the (IPsec)
security aspects, 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 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.
(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.
When dynamic routing is used, and the customers are responsible for
De Clercq et al. Expires December 2002 [Page 5]
Internet Draft draft-declercq-ppvpn-ce-based-as-01.txt June 2002
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). Note that the CEs in different sites are
direct routing peers. The Service Provider does not interact in the
customer routing.
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).
Whether (IPsec) secured tunnels are used or not has a large impact on
the applicability of the offered VPN service. This version of the
applicability statements draft focusses on IPsec-secured CE-based
VPNs.
2. SP Provisioning model
In provider provisioned CE-based VPNs, the SP is responsible to
provision 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.
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
De Clercq et al. Expires December 2002 [Page 6]
Internet Draft draft-declercq-ppvpn-ce-based-as-01.txt June 2002
protect the inter-site traffic, need (long-term) secure credentials.
These credentials will be used by a key exchange protocol (such as
IKE) 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.
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).
3. Supported Topologies and Traffic Types
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 basis scenario
that CE devices need to be provisioned to be able to duplicate
multicast packets over the different VPN tunnels it maintains.
De Clercq et al. Expires December 2002 [Page 7]
Internet Draft draft-declercq-ppvpn-ce-based-as-01.txt June 2002
[note: whether the multicast functions are all performed at CE or PE,
and managed by SP or customer is TBD].
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).
Note that if IP unnumbered is used between CE and PE devices, this IP
address actually belongs to the PE.
Isolated exchange of data information is assured because :
(i) IP routing and forwarding takes care of forwarding the
encapsulated IP packets to the correct destination CEs in the
shared infrastructure, using the destination address in the IPsec
packets.
(ii) the customer IP packets are usually 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.
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 reachability
information only to those interfaces that are associated with the
particular VPN : that is, the intra-site interfaces and the IPsec-
protected interfaces that lead to the other sites that belong to the
same VPN.
De Clercq et al. Expires December 2002 [Page 8]
Internet Draft draft-declercq-ppvpn-ce-based-as-01.txt June 2002
As such, 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 (unless
this behavior is explicitly expected and provisioned).
Of course, configuration errors by the SP can compromise the
constrained distribution of reachability, and the overall security of
the VPN.
[Note: A more detailed analysis of the effect of mis-configuration
(how much must be mis-configured and what is the result or damage ?)
will be discussed in a next version of this applicability statements
draft.]
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
can also be carried in an encrypted form on the CE-to-CE part of the
network (by sending the routing information messages through the
provisioned CE-CE IPsec tunnels). This means that even when
misconfiguration, 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.
5. Security
[Note : A more detailed analysis of provider provisioned CE-based
IPsec VPNs with regards to security will be documented in a next
version of this applicability statements draft.]
CE-based VPNs using IPsec are specifically applicable in situations
where security is a very 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.
5.1 Protection of User Data
De Clercq et al. Expires December 2002 [Page 9]
Internet Draft draft-declercq-ppvpn-ce-based-as-01.txt June 2002
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. [Note : A more
detailed analysis of the customer data security will be documented in
a next version of this draft.]
5.2 SP Security Measures
A management channel exists between SP and the managed CE. It is
important for SP to build a secure management channel to prevent
attacks from the adversary (example: IPsec tunnel, SSH/TLS session).
[Note: A more detailed analysis of the SP security measures will be
documented in a next version of this draft (including the
implications of a key management system).]
6. Addressing
In CE-based IPsec VPNs, it is assumed that the CE devices have one 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.
Overlapping customer addresses are supported (meaning that different
VPN customers that are provisioned by the same (or different) SP may
use overlapping address spaces) in different VPNs. There is no
requirement that such addresses be in conformance with RFC 1918.
There is no requirement that customer VPN addresses be 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
Interoperability considerations will be detailed in a future version
of this applicability statements document.
De Clercq et al. Expires December 2002 [Page 10]
Internet Draft draft-declercq-ppvpn-ce-based-as-01.txt June 2002
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, ATM, Frame Relay, etc.).
8.2 Access QoS support
TBD.
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 may 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
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.
9. Service Access
9.1 Internet Access
[Note : this section will be completed in future versions of this
draft.]
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
De Clercq et al. Expires December 2002 [Page 11]
Internet Draft draft-declercq-ppvpn-ce-based-as-01.txt June 2002
from the IP addresses of the systems which must be reached via the
Internet. The required NAT and firewall functions are implemented in
one or more of the VPN's CE devices.
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, while such an attack can only come from
other VPN sites when the access connection is not shared with the
Internet. [note: incorrect statement? the site's CE address is at
least known by the SP, and possibly by other VPNs or even the
Internet ??]
9.2 Hosting, ASP, Other Services
TBD.
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:
- the customer's CE device needs to implement the IPsec
protocol suite and an IPsec key exchange functionality, such as
De Clercq et al. Expires December 2002 [Page 12]
Internet Draft draft-declercq-ppvpn-ce-based-as-01.txt June 2002
IKE.
- the CE device needs to support a highly secure management
channel from the SP's management system [note: example to be
added].
- the CE device's routing protocol(s) needs to treat the
different IPsec secured CE-to-CE tunnels as independent
interfaces.
- migration scenario (ii)
TBD. [note: including the key/certificate management]
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.
- 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 reach-ability 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 [note: such as?] 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
De Clercq et al. Expires December 2002 [Page 13]
Internet Draft draft-declercq-ppvpn-ce-based-as-01.txt June 2002
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
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 and on the SP's management 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
De Clercq et al. Expires December 2002 [Page 14]
Internet Draft draft-declercq-ppvpn-ce-based-as-01.txt June 2002
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.
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)).
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.
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. The increase of the processing is manyfold:
- packets that are sent over a specific tunnel will need to be
authenticated and/or encrypted
- 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
De Clercq et al. Expires December 2002 [Page 15]
Internet Draft draft-declercq-ppvpn-ce-based-as-01.txt June 2002
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.
The impact of the number of tunnels per CE on the customer's IGP is
TBD (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
TBD: impact of eg adding a site (how does this increase control
traffic; what is the convergence time ?); impact of the rate of
configuration changes; possible rate of configuration changes?
12.7 Performance impact
The deployment of a CE-based VPN will have a performance impact on
the system.
De Clercq et al. Expires December 2002 [Page 16]
Internet Draft draft-declercq-ppvpn-ce-based-as-01.txt June 2002
With regards to the control plane, the CE devices will need to
negotiate Security Associations and generate cryptographic key
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.
[Note : The scalability analysis of the SP's eventually provisioned
PKI will be discussed in further versions of this draft.]
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.
The CE-CE tunneling applied in Provider Provisioned CE-based IPsec
VPNs easily meets the DSCP transparency requirements of [REQS].
[Note: A more detailed discussion of QoS and SLAs will be provided in
a next version of this draft.]
14. Management
14.1 Configuration/provisioning
De Clercq et al. Expires December 2002 [Page 17]
Internet Draft draft-declercq-ppvpn-ce-based-as-01.txt June 2002
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 Monitoring
TBD.
14.3 Customer management
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.
14.4 SLA monitoring
TBD.
14.5 Security
TBD.
14.6 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
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
De Clercq et al. Expires December 2002 [Page 18]
Internet Draft draft-declercq-ppvpn-ce-based-as-01.txt June 2002
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 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 and Marco Carugi 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-ppvpn-ce-
based-02.txt, 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
Layer-3 Provider Provisioned Virtual Private Networks,"
work in progress
[TOUCH-VPN] Touch J., Eggert L., "Use of IPsec Transport Mode for
Dynamic Routing", work in progress
De Clercq et al. Expires December 2002 [Page 19]
Internet Draft draft-declercq-ppvpn-ce-based-as-01.txt June 2002
[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
SmartPipes
565 Metro Place South
Dublin, OH 43017, USA
Phone: 1-614-923-6241
E-mail: cwang@smartpipes.com
Dave McDysan
WorldCom
22001 Loudoun County Parkway
Ashburn VA 20147, USA
E-mail: dave.mcdysan@wcom.com
De Clercq et al. Expires December 2002 [Page 20]
