Internet DRAFT - draft-declercq-ppvpn-ce-based
draft-declercq-ppvpn-ce-based
Network Working Group Jeremy De Clercq
INTERNET DRAFT Olivier Paridaens
<draft-declercq-ppvpn-ce-based-00.txt> Mahadevan Iyer
Andrew Krywaniuk
Alcatel
July 2001
Expires January, 2002
A Framework for
Provider Provisioned CE-based Virtual Private Networks
using IPsec
<draft-declercq-ppvpn-ce-based-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months. Internet-Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet-
Drafts as reference material or to cite them other than as a
``working draft'' or ``work in progress.''
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directorieson ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe),
ftp.nis.garr.it (Southern Europe), munnari.oz.au(Pacific Rim),
ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Distribution of this memo is unlimited.
Abstract
This document describes a framework for a Service Provider to offer
Virtual Private Network Services to its customers by provisioning
network elements that are located at the customer premises. The IPsec
technology is used to protect the Customer traffic.
0. SubIP-Area Section
SUMMARY
De Clercq et al. Expires January 2002 [Page 1]
Internet Draft draft-declercq-ppvpn-ce-based-00.txt July 2001
The PPVPN framework document [FRAMEWORK] identifies three basic
provider provisioned VPN types : Provider Provisioned Network Based
Layer 3 VPNs, Provider Provisioned Layer 2 VPNs and Provider
Provisioned CE-based VPNs.
This document describes a method enabling a Service Provider to offer
VPN services to its customers by provisioning network elements that
are located at the customer premises (Provider Provisioned CE-based
VPNs).
For a CE-based VPN to be set up under the SP's control, the VPN
customer informs the Service Provider of which sites (identified by a
set of CE devices) should become part of the considered VPN and what
the requested topology of the VPN should look like. The SP then
configures and maintains a VPN database and manages the Customer's
VPN.
The model proposed in this document uses the IPsec protocol suite for
the purpose of securing the customer VPN traffic.
When the model proposed is used, the adition of one VPN site only
requires a minimum amount of configuration. This is obtained by using
an automatic distribution scheme via a network management protocol.
RELATED DOCUMENTS
See References section.
WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK
PPVPN box.
WHY IS IT TARGETED AT THIS WG
This document describes the framework for Provider Provisioned CPE-
based VPNs, which is clearly identified as an item within the scope
of the PPVPN WG, as stated from the following WG charter extract:
"This working group is responsible for defining and specifying a
limited number of sets of solutions for supporting provider-
provisioned virtual private networks (PPVPNs). The work effort will
include the development of a framework document, a service
requirements document and several individual technical approach
documents that group technologies together to specify specific VPN
service offerings. The framework will define the common components
and pieces that are needed to build and deploy a PPVPN. Deployment
scenarios will include provider-managed VPN components located on
customer premises.".
De Clercq et al. Expires January 2002 [Page 2]
Internet Draft draft-declercq-ppvpn-ce-based-00.txt July 2001
JUSTIFICATION
This document is justified by the fact that it defines a framework
for PP CPE-based VPNs, which are identified as a specific type of
PPVPNs both in the WG charter and the general framework I-D. As
described in the general framework I-D, PP CPE-based VPNs have
specific characteristics compared to Network-Based VPNs especially
with regards to management and security.
1. Introduction
The PPVPN framework document [FRAMEWORK] identifies three basic
provider provisioned VPN types : Provider Provisioned Network Based
Layer 3 VPNs, Provider Provisioned Layer 2 VPNs and Provider
Provisioned CE-based VPNs.
This document describes a method enabling a Service Provider to offer
VPN services to its customers by provisioning network elements that
are located at the customer premises (Provider Provisioned CE-based
VPNs).
For a CE-based VPN to be set up under the SP's control, the VPN
customer informs the Service Provider of which sites (identified by a
set of CE devices) should become part of the considered VPN and what
the requested topology of the VPN should look like. The SP then
configures and maintains a VPN database and manages the Customer's
VPN.
The model proposed in this document uses the IPsec protocol suite for
the purpose of securing the customer VPN traffic.
When the model proposed is used, the adition of one VPN site only
requires a minimum amount of configuration. This is obtained by using
an automatic distribution scheme via a network management protocol.
2. Reference Model
This section describes the reference model used. It is the purpose to
allign this section with the terminology and the reference model for
CE-based PP-VPNs that will be described in future versions of
[FRAMEWORK].
De Clercq et al. Expires January 2002 [Page 3]
Internet Draft draft-declercq-ppvpn-ce-based-00.txt July 2001
+---------+ +------------------------------------+ +---------+
| | | | | |
| | | +------+ +------+ : +------+
+------+ : | | | | | | : | CE |
| CE | : | | | P | | PE | : |device|
|device| : +------+ VPN tunnel |router| |router| : | of |
| of |=:====================================================:=|VPN A|
|VPN A| : | | +------+ +------+ : +------+
+------+ : | PE | | | : |
+------+ : |router| | | : |
| CE | : | | VPN tunnel +------+ : +------+
|device|=:====================================================:=| CE |
| of | : +------+ | PE | : |device|
|VPN B| : | | |router| : | of |
+------+ : | | +------------+ +------------+ | | : |VPN B|
| : | | | Customer | | Network | +------+ : +------+
|Customer | | | management | | management | | | : |
|interface| | | function | | function | | |Customer |
| | | +------------+ +------------+ | |interface|
| | | | | |
+---------+ +------------------------------------+ +---------+
| Access | |<---------- SP network(s) --------->| | Access |
| network | | | | network |
Figure 1: Reference model for provider provisioned CE-based VPNs
2.1 Entities in the reference model
o Customer Edge (CE) device
A CE device is a router located at the customer premises, that has
IP connectivity with a SP's PE device. In the context of CE-based
VPNs, a CE device maintains one or more VPN tunnel endpoints. In
the context of Provider-provisioned CE-based VPNs, the VPN
functions in the CE device can be managed by the SP's management
system.
Note that other functions that are normally applied by the PE
router may need to be performed by the CE device in this context
(e.g. NAT functionality, QoS classification, etc.).
The CE device may also provide general (non VPN-oriented) Internet
connectivity for the customer network. Such connectivity may be
achieved via the SP's PE router that provides the VPN connectivity
or some other router (of the same or another SP). In such a
situation, the CE device must be able to distinguish between
De Clercq et al. Expires January 2002 [Page 4]
Internet Draft draft-declercq-ppvpn-ce-based-00.txt July 2001
traffic to be sent through a VPN and traffic to be sent outside
any VPN.
o Provider Edge (PE) router
In the context of Provider Provisioned CE-based VPNs, a PE router
is a router, located at the edge of the Service Provider's
network, that does not have any VPN-specific functionality. A PE
router is attached via an access connection to one or more CE
devices, and offers IP connectivity over the access connections to
these CE devices.
o SP networks
A SP network is a network administrated by a single service
provider. In the context of provider provisioned CE-based VPNs,
the SP network consists of the Service Provider's IP (backbone)
network and the Service Provider's management functions that
manage both its own IP (backbone) network and the VPN customer's
VPN functions on the CE devices.
o Access connection
An access connection represents an isolated layer 2 connectivity
between a CE device and a PE router. This includes dedicated
physical circuits, logical circuits (such as Frame Relay and ATM),
plus IP tunnels (e.g., using IPsec, L2TP). In the context of
provider provisioned CE-based VPNs, the CE device and the PE
router have layer 3 connectivity over the Access Connection.
o VPN tunnel
A VPN tunnel is a logical link between two entities which is
created by encapsulating packets within an encapsulating header
for purpose of transmission between those two entities for support
of VPNs. In the context of provider provisioned CE-based VPNs, a
VPN tunnel is an IP tunnel (e.g., using IPsec, L2TP, GRE, IP-in-
IP) between two CE devices over the SP's network. In the context
of this document, a VPN tunnel is an IP tunnel (IP-in-IP/IPsec)
between two CE devices.
2.2 Assumed Reachability
It is assumed in this specification that the CE devices have at least
one IP address that is known to the SP network and that is routable
within the SP's network. This implies that every CE device knows how
to reach the other CE devices attached to the common SP. This might
De Clercq et al. Expires January 2002 [Page 5]
Internet Draft draft-declercq-ppvpn-ce-based-00.txt July 2001
be via a direct routing entry in the CE's routing table or
alternatively (and probably) via a default route towards the PE
device it is attached to. These CE IP addresses will be known in the
SP network, if not globally, then at least in the PE devices engaged
in the VPN services.
This means that either a routing protocol will be running between the
CE and the PE device, exchanging routes belonging to the service
provider's routing realm; or alternatively, the CE will have a
configured default route or static route towards the PE, and the PE
will have assigned an IP address to the CE device upon set-up of the
IP service offered to the CE device.
2.3 Assumed Service Provider's infrastructure
It is assumed that the Service Provider has a secure control channel
to every attached CE device. This secure control channel will be used
to exchange VPN-specific configuration information between the SP's
VPN database and the CE devices.
The particular implementation of this control channel is currently
outside of the scope of this document. Some examples are: (i) manual
configuration by a trusted party, directly on the considered network
element; (ii) via a management protocol running over an IPsec-secured
connection between the SP's management center and the considered
network element; (iii) via a management protocol that has its own
implicit security mechanisms.
3. Configuring the CE-based VPN
As a Service Provider that is offering VPN services over its backbone
network will be responsible for the configuration and the management
of a potential large amount of VPNs, it is required that the
provisioning actions for the set up and the maintenance of a PP CE-
based VPN would be minimal.
The minimal configuration that is necessary is the configuration of
the Service Provider's VPN database with the CE device to be part of
a well-defined VPN. Further provisioning can be achieved via an
auto-discovery mechanism as is described in the sections below.
For the purpose of CE device configuration, the Service Provider will
maintain a VPN database per VPN customer. The exchange of information
between the SP's VPN database and the targetted CE-devices is
achieved using an information exchange/configuration protocol such as
LDAP, SNMP, COPS etc. We will call this protocol 'the management
protocol' throughout the rest of this document.
De Clercq et al. Expires January 2002 [Page 6]
Internet Draft draft-declercq-ppvpn-ce-based-00.txt July 2001
It is assumed for the scope of this document that the control channel
used for the configuration information exchange by the chosen
protocol is sufficiently secured.
This document will identify some requirements that the considered
protocol should satisfy for the purposes of applicability in the VPN
autodiscovery phase.
3.1 (Minimal) configuration needed at the CE device
- 'Control channel' information : the information needed to access
(or to exchange information with) the SP's VPN database ('database
reachability information', authentication information for the VPN
database, encryption information for the configuration control
channel etc.). Note that this is assumed to be present, and that
setting up a secure control channel is outside of the scope of this
document.
- Peer CE devices : the IP addresses (in the SP's realm) of the peer
CE devices that belong to the same VPN and to which a direct peering
relationship is required. This information can be one IP address
(e.g. in the case that the considered CE device is a 'spoke' in a
'hub&spoke' topology); this information can be the complete set of
the IP addresses of all the other CE devices belonging to the same
VPN (in the case of a 'fully meshed' topology); or this information
can be a subset of the IP addresses of the CE devices belonging to
the same VPN (for more complex topologies).
- Security Information : the information needed to set up and
maintain IPsec Security Associations with the Peer CE devices (a set
of transforms for use with IPsec, etc.). This information relates to
the protection of the actual user data packets.
This means that the VPN database (identified by a VPN identifier) of
the SP's management system contains a list of all the CE devices
belonging to the specified VPN, a description of the topolgy (full
mesh, hub&spoke, etc) and some security-related information related
to every CE-to-CE tunnel.
3.2 Updating configuration information (neighbor discovery)
One of the most important requirements relating to scalability for
PP-VPNs is that the addition/deletion of a certain site to/from an
existing VPN should be possible with a minimal configuration effort.
Manual configuration of the information related to the new site into
every existing CE in the particular VPN is not an option.
Different methods to achieve the requested behaviour are possible.
De Clercq et al. Expires January 2002 [Page 7]
Internet Draft draft-declercq-ppvpn-ce-based-00.txt July 2001
One such method is for the SP to configure the 'new site' in the SP's
VPN database:
The CE's IP address in the SP's realm, the VPN-ID of the VPN it
belongs to, the 'role' of the new site in the existing topolgy (hub,
spoke, etc.), and the necessary security information are configured
in the concerned VPN database. This change in the database triggers
the distribution (via a management protocol such as COPS, LDAP, SNMP,
etc.) of the updated information over the secure control channel to
the concerned CE devices only (the new CE device and all the CE
devices it has to peer with).
This method implies that the protocol used for the distribution of
the configuration information to the CE devices should be usable in a
"PUSH" mode from 'server' to 'client' (the management system - server
- pushes the updated information to the concerned parties - clients-
). It is to be noted that some information distribution technologies
such as LDAP are natively not PUSH oriented. If the VPN configuration
is stored using such a technology, it is necessary to define a
mechanism that enables the CE to be trigerred so as to fetch VPN
configuration from its repository. Such a mechanism could be based on
the use of SNMP messages sent to the CE device, with specific
variables that trigger the fetch operation.
3.3 Setting up the VPN tunnels
When one VPN site sends traffic to another VPN site belonging to the
same VPN, these IP packets will be secured via IPsec. This means that
an IPsec Security Association is needed between each pair of sites
that exchange private VPN data.
The Internet Key Exchange protocol (IKE, [IKE]) will be used for the
purpose of automatic setup of security associations between VPN sites
within the same VPN.
The IPsec SA setup can be triggered by the effective (data) traffic
flow going from one site to another. In this case, the arrival of
data packets at the CE device, coming from within the VPN site and
going to another VPN site, will be noticed by the CE's IPsec or
routing database, and an IKE exchange will be initated to set up an
IPsec secured connection between both parties. Once the secure tunnel
is set up, the data packets can flow from one site to the other in a
secure way. When no traffic flows for a certain duration of time, the
secure tunnel will be torn down again. An advantage of this method is
that an IPsec tunnel is only to be maintained when there is
effectively traffic flowing. A disadvantage is the extra delay
introduced for the traffic during IKE signalling.
De Clercq et al. Expires January 2002 [Page 8]
Internet Draft draft-declercq-ppvpn-ce-based-00.txt July 2001
Alternatively, 'permanent' IPsec tunnels can be set up. These tunnels
are always available and not traffic-triggered. It is then required
to frequently re-negotiate the SA (via IKE) before the IPsec timers
of the connection time out. The set-up of a 'permanent' IPsec tunnel
can be triggered by the configuration of a new peer CE device within
the same VPN. An advantage of this method is that the IPsec tunnel is
always available, and that eventual traffic does not encounter an
extra delay due to the setup time of a new SA. A disadvantage is the
necessary frequent re-keying of the SA's.
Note that IPsec tunnels are unidirectional in nature, but that
usually the set up of one direction is accompanied by the set up of
the reverse direction IPsec tunnel.
This document describes two possible ways to use IPsec in CE-based
VPN scenarios (see section 5): in 'transport mode' or in 'tunnel
mode'. The IKE exchange and resulting SA's must specify which mode
will be used.
Note that the number of peer CE devices with which a specific CE
device must have an IPsec connection to secure the data traffic, is
dependent on the specific 'role' of the site in the considered VPN.
In the case of traffic-driven tunnel setup, the 'role' of the
considered site has an impact on the CE's routing/forwarding
databases. In the case of 'permanent' IPsec tunnels, permanent IPsec
tunnels will be set up only to a specific set of peer CE devices,
conforming the VPN's topology.
4. Exchanging and maintaining VPN routes
This document currently describes two alternative mechanisms for the
purpose of exchanging VPN routes between VPN sites.
4.1 Tunneling routing information between CE devices through the IPsec
tunnels.
In the first mechanism to exchange VPN reachability information,
normal routing protocol messages are tunneled through the IPsec
tunnels between peering sites. The CE-to-CE IPsec tunnels between VPN
sites are then being seen as point-to-point links by the customer
networks and are inserted as such in the routing protocol functions
of the CE devices. This means that when a change in the reachability
occurs in one particular site, a routing protocol (such as RIP, OSPF,
IS-IS, etc.) will take care of the distribution of the new
reachability information within the site, but also to all other
sites, through the VPN tunnels the considered CE is peering with.
Note that when IPsec in tunnel mode is deployed, the routing protocol
De Clercq et al. Expires January 2002 [Page 9]
Internet Draft draft-declercq-ppvpn-ce-based-00.txt July 2001
messages need to be carried on IP for this method to be applicable.
When IPsec transport mode is deployed (see section 5), the routing
protocol messages will first be IP-in-IP encapsulated before IPsec
handling.
Another point to keep in mind is the fact that when the setup of the
VPN tunnels via IKE is traffic-driven, the distribution of routing
information over the tunnels will also trigger the setting up of an
IPsec tunnel, even when no data traffic is flowing. Therefore a
routing protocol that only distributes reachability information upon
changes is required. Moreover, in the specific case of link state
routing protocols, the hello mechanism will also trigger the setup of
IPsec tunnels.
4.2 Exchanging VPN reachability information via SP's management
An alternative method to exchange reachability between sites within a
VPN is by SP's management system involvement. When the reachability
in a certain site changes, the considered CE device will need to
communicate the new reachability information through the secure
control channel to the SP's VPN database. This could be achieved
either by having the CE device to push the new information to the
SP's VPN database or by having the CE device to send some message (eg
SNMP trap) to the SP's management system, which in turn can pull the
new reachability information from the CE device. Once the SP's VPN
database has been updated, this will trigger the distribution of this
updated information from the SP's VPN database to all the appropriate
CE devices by the management system, using the management protocol
over the secured control connections.
Within the sites themselves, the CE device may then inject the
updated reachability information into the local routing protocol
function.
Note that this method does not require the use of the same
'management protocol' for the configuration of the CE device and for
the dynamic exchange of reachability information. A dedicated
protocol may be used for that purpose.
5. Tunneling IP traffic (user data) among VPN sites
This section describes the processes that an IP packet that is sent
from one VPN site to another will go through. This is dependent on
the way that IPsec is used. This document describes two possible ways
to use IPsec in CE-based VPN implementations: IPsec in tunnel mode,
and IPsec in transport mode.
An IP packet that is sent by an IP device in a certain site and
De Clercq et al. Expires January 2002 [Page 10]
Internet Draft draft-declercq-ppvpn-ce-based-00.txt July 2001
destined for an IP device in another site belonging to the same VPN,
will be forwarded as follows.
The device in the sending site sends an IP packet (using a private
address space) on its LAN network. The next hop for this destination
IP address will be the site's CE device (according to the
routing/forwarding in the VPN site). The processing by the CE device
now is dependent on the implemented mode for IPsec.
o IPsec in tunnel mode
When IPsec is used in tunnel mode in this context, the IPsec
driver in the CE device must do the following:
- analyse the private IP packets arriving from within the site and
select/setup an appropriate SA with the appropriate destination CE
device.
- authenticate and/or encrypt the private IP packet according to
the (tunnel mode-specific) rules described in the SA, AND
encapsulate the packet in an IPsec header AND encapsulate the
packet in a new 'outer' IP header. This 'outer' IP header has the
CE's non-private (i.e. routable in the SP's realm) IP address in
the source IP address field and the destination CE's non-private
(i.e. routable in the SP's realm) IP address in the destination IP
address field.
o IPsec in transport mode (see also [TOUCH])
When IPsec is used in transport mode in this context, the CE
device must first analyse the private IP packets arriving from
within the site and select the appropriate destination CE, based
on the routing/forwarding information. The CE device then
encapsulates the private IP packet into a new IP packet (IP-in-IP
encapsulation/tunneling), with the own non-private (i.e. routable
in the SP's realm) IP address in the source address field of the
new header and the destination CE's non-private (i.e. routable in
the SP's realm) IP address in the destination address field of the
new header. The CE device then processes this new IP packet to its
IPsec driver.
The IPsec driver in the CE device must then do the following:
- analyse the IP packets that have been IP-in-IP encapsulated and
select the appropriate SA (based on the packets destination
address).
- authenticate and/or encrypt the private IP packet according to
De Clercq et al. Expires January 2002 [Page 11]
Internet Draft draft-declercq-ppvpn-ce-based-00.txt July 2001
the (transport mode-specific) rules described in the SA and insert
an IPsec header (according to IPsec in transport mode).
The CE device then sends the IPsec packet to the PE device, and the
IPsec packet will then be forwarded using 'normal' IP forwarding
accross the SP's network, based on the outer header's IP destination
address, that is the destination CE's 'global' (i.e. routable in the
SP's realm) IP address. The egress PE device will also only examine
the outer IP header and send the IP(sec) packet to the destined CE
device. The egress CE device will recognize itself as the destination
node (the IP packet has the CE's IP address in the outer IP
destination address field). The destination CE's IPsec driver will
then, based on the appropriate Security Association (identified by
the packet's SPI field in the IPsec header), perform IPsec
authentication and/or decryption. Dependent on whether tunnel mode or
transport mode IPsec is used, the packet will be decapsulated by the
IPsec driver itself or sent to the IP-in-IP decapsulation function.
The resulting (private) IP packet will then be further processed in
the CE's IP forwarding table and send on the LAN network to the
appropriate destination IP device.
6. Deleting an existing VPN site
When the VPN customer decides to delete an existing site from a
certain VPN, the SP's VPN database must be changed accordingly:
- either manually by the SP
- or via a "PUSH" operation with the management protocol by the CE
device to the VPN database.
This will then trigger the distribution of the updated information
from the SP's VPN database to the concerned CE devices.
The CE device from the deleted site will then terminate the existing
Security Associations with its peer CE's using IKE signaling.
(Alternatively, the IKE sessions could be just timed out).
Note that the CE devices of a certain VPN need to delete the routing
entries corresponding with a deleted CE device (i.e. a deleted VPN
site) from their corresponding routing/forwarding tables, and
announce this change within their site.
7. Quality of Service
TBD
De Clercq et al. Expires January 2002 [Page 12]
Internet Draft draft-declercq-ppvpn-ce-based-00.txt July 2001
8. Security Considerations
The security aspects of what is presented in this document are
implicitly discussed in most of the sections. This draft is for a
large part focussing on security aspects.
Note that the security of the mechanism presented here is highly
dependent on the security of 'control channel', used by the
management protocol to configure the VPN CE devices.
9. References
[FRAMEWORK] Callon, R. et al., "A Framework for Provider Provisioned
Virtual Private Networks", draft-ietf-ppvpn-framework-00.txt, Work in
progress
[IKE] Harkins, D. and Carrel, D., "The Internet Key Exchange (IKE)",
November 1998, RFC 2409
[IPSEC] Kent and Atkinson, "Security Architecture for the Internet
Protocol", November 1998, RFC 2401
[TOUCH] Touch, J. and Eggert, L., "Use of IPSEC transport mode for
Virtual Networks", draft-touch-ipsec-vpn-01.txt, Work in progress
10. Authors' Addresses
Jeremy De Clercq
Alcatel
Fr. Wellesplein 1, 2018 Antwerpen, Belgium
E-mail: jeremy.de_clercq@alcatel.be
Olivier Paridaens
Alcatel
Fr. Wellesplein 1, 2018 Antwerpen, Belgium
E-mail: olivier.paridaens@alcatel.be
Mahadevan Iyer
Alcatel Inc
595 Yosemite Blvd, Milpitas, CA
Phone: 408 586 7687
E-Mail: mahadevan.iyer@ind.alcatel.com
Andrew Krywaniuk
Alcatel Networks Corporation
600 March Road
Kanata, ON
Canada, K2K 2E6
De Clercq et al. Expires January 2002 [Page 13]
Internet Draft draft-declercq-ppvpn-ce-based-00.txt July 2001
+1 (613) 784-4237
E-mail: andrew.krywaniuk@alcatel.com
De Clercq et al. Expires January 2002 [Page 14]
