Internet DRAFT - draft-ietf-ppvpn-ce-based
draft-ietf-ppvpn-ce-based
Network Working Group Jeremy De Clercq
INTERNET DRAFT Olivier Paridaens
<draft-ietf-ppvpn-ce-based-03.txt> Alcatel
Andrew Krywaniuk
Cliff Wang
March 2003
Expires September, 2003
An Architecture for
Provider Provisioned CE-based Virtual Private Networks
using IPsec
<draft-ietf-ppvpn-ce-based-03.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months. Internet-Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet-
Drafts as reference material or to cite them other than as a
``working draft'' or ``work in progress.''
To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au(Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Distribution of this memo is unlimited.
Abstract
This document describes the procedures for a Service Provider to
offer Virtual Private Network Services to its customers by
provisioning the CE devices on behalf of the customer. The IPsec
technology is used to protect the customer traffic.
0. SubIP-Area Section
De Clercq et al. Expires September 2003 [Page 1]
Internet Draft draft-ietf-ppvpn-ce-based-03.txt March 2003
SUMMARY
The PPVPN framework document [FRAMEWORK] identifies three basic
provider provisioned VPN types : Provider Provisioned Network Based
(or PE-based) Layer 3 VPNs, Provider Provisioned Layer 2 VPNs and
Provider Provisioned CE-based VPNs.
This document describes a method enabling a Service Provider to offer
VPN services to its customers by provisioning the CE devices on
behalf of the customer (Provider Provisioned CE-based VPNs).
For a CE-based VPN to be set up under the SP's control, the VPN
customer informs the Service Provider of which sites (identified by a
set of CE devices) should become part of the considered VPN and what
the requested topology of the VPN should look like. The SP then
configures and maintains a VPN database and manages the Customer's
VPN.
The model proposed in this document uses the IPsec protocol suite for
the purpose of securing the customer VPN traffic.
When the model proposed is used, the addition of one VPN site only
requires a minimum amount of configuration. This is obtained via a
provisioning scheme using a network management protocol.
RELATED DOCUMENTS
See References section (especially [CE-SOL], [TOUCH]).
WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK
PPVPN box.
WHY IS IT TARGETED AT THIS WG
This document describes a mechanism for Provider Provisioned CE-based
VPNs, which is clearly identified as an item within the scope of the
PPVPN WG, as stated from the following WG charter extract: "This
working group is responsible for defining and specifying a limited
number of sets of solutions for supporting provider-provisioned
virtual private networks (PPVPNs). The work effort will include the
development of a framework document, a service requirements document
and several individual technical approach documents that group
technologies together to specify specific VPN service offerings. The
framework will define the common components and pieces that are
needed to build and deploy a PPVPN. Deployment scenarios will include
provider-managed VPN components located on customer premises.".
De Clercq et al. Expires September 2003 [Page 2]
Internet Draft draft-ietf-ppvpn-ce-based-03.txt March 2003
JUSTIFICATION
This document is justified by the fact that it defines a solution for
PP CE-based VPNs, which are identified as a specific type of PPVPNs
both in the WG charter and the general framework I-D. As described in
the general framework I-D, PP CE-based VPNs have specific
characteristics compared to Network-Based VPNs especially with
regards to management and security.
Changes since last version
Proposed changes to version -02.txt of this document, based on
comments received on the ppvpn exploder, have mostly been dealt with
in [CE-SOL].
This version -03.txt differs not significantly from the previous
version (-02.txt); this allows this (architecture) document to be
used for reference's purpose.
1. Introduction
The PPVPN framework document [FRAMEWORK] identifies three basic
provider provisioned VPN types : Provider Provisioned Network Based
(also termed PE-based) Layer 3 VPNs, Provider Provisioned Layer 2
VPNs and Provider Provisioned CE-based VPNs.
This document describes a method enabling a Service Provider to offer
VPN services to its customers by provisioning the CE devices on
behalf of the customer (Provider Provisioned CE-based VPNs).
For a CE-based VPN to be set up under the SP's control, the VPN
customer informs the Service Provider of which sites (identified by a
set of CE devices) should become part of the considered VPN and what
the requested topology of the VPN should look like. The SP then
configures and updates its VPN database, and then provisions and
manages the Customer's VPN.
The model proposed in this document uses the IPsec protocol suite for
the purpose of securely tunneling the customer VPN traffic.
This specification proposes some mechanisms that can be used to
enhance the scalability of the VPN provisioning (e.g. the addition of
a VPN site to an existing VPN).
2. Reference Model
The reference model upon which the mechanisms and procedures
described in this document are based, is taken from the CE-based VPN
De Clercq et al. Expires September 2003 [Page 3]
Internet Draft draft-ietf-ppvpn-ce-based-03.txt March 2003
reference model described in [FRAMEWORK]. The most important aspects
of that framework model and the restrictions that are relevant to
this document are described in this section.
+---------+ +------------------------------------+ +---------+
| | | | | |
| | | +------+ +------+ : +------+
+------+ : | | | | | | : | CE |
| CE | : | | | P | | PE | : |device|
|device| : +------+ VPN tunnel |router| |router| : | of |
| of |=:====================================================:=|VPN A|
|VPN A| : | | +------+ +------+ : +------+
+------+ : | PE | | | : |
+------+ : |router| | | : |
| CE | : | | VPN tunnel +------+ : +------+
|device|=:====================================================:=| CE |
| of | : +------+ | PE | : |device|
|VPN B| : | | |router| : | of |
+------+ : | | +------------+ +------------+ | | : |VPN B|
| : | | | Customer | | Network | +------+ : +------+
|Customer | | | management | | management | | | : |
|interface| | | function | | function | | |Customer |
| | | +------------+ +------------+ | |interface|
| | | | | |
+---------+ +------------------------------------+ +---------+
| Access | |<---------- SP network(s) --------->| | Access |
| network | | | | network |
Figure 1: Reference model for provider provisioned CE-based VPNs
2.1 Entities in the reference model
o Customer Edge (CE) device
In the context of this solution, a CE device is a router located
at the edge of a customer site, that has IP connectivity with a
SP's PE device. A CE device maintains one or more VPN tunnel
endpoints. The VPN-specific functions in the CE device are managed
by the SP's management system. It is very common for the SP to
manage the complete CE device, while it is also possible for the
customer to self-manage part of the CE's functions. In such a
situation, the separation of responsabilities is to be clearly
defined in the SLA.
Note that other functions that are normally applied by the PE
router may need to be performed by the CE device in this context
De Clercq et al. Expires September 2003 [Page 4]
Internet Draft draft-ietf-ppvpn-ce-based-03.txt March 2003
(e.g. NAT functionality, QoS classification, etc.).
The CE device may also provide general (non VPN-oriented) Internet
connectivity for the customer network. Such connectivity may be
achieved via the SP's PE router that provides the VPN connectivity
or some other router (of the same or another SP). In such a
situation, the CE device must be able to distinguish between
traffic to be sent through a VPN and traffic to be sent outside
any VPN.
o Provider Edge (PE) router
In the context of Provider Provisioned CE-based VPNs, a PE router
is a router, located at the edge of the Service Provider's
network, that does not have any VPN-specific functionality. A PE
router is attached via an access connection to one or more CE
devices, and offers possibly limited or restricted IP connectivity
over the access connections to these CE devices.
o SP network
A SP network is a network administrated by a single service
provider. In the context of provider provisioned CE-based VPNs,
the SP network consists of the Service Provider's IP (backbone)
network and the Service Provider's management functions that
manage both its own IP (backbone) network and the VPN customer's
VPN functions on the CE devices.
o Access connection
An access connection represents an isolated layer 2 connectivity
between a CE device and a PE router. This includes dedicated
physical circuits, logical circuits (such as Frame Relay and ATM),
IP tunnels (e.g., using IPsec, L2TP) and shared-medium access
(such as Ethernet-based access). In the context of provider
provisioned CE-based VPNs, the CE device and the PE router have
layer 3 connectivity over the Access Connection.
o VPN tunnel
A VPN tunnel is a logical link between two entities which is
created by encapsulating packets within an encapsulating header
for purpose of transmission between those two entities for support
of VPNs. In the context of provider provisioned CE-based VPNs, a
VPN tunnel is an IP tunnel (e.g., using IPsec, L2TP, GRE, IP-in-
IP) between two CE devices over the SP's network. In the context
of this document, a VPN tunnel is achieved using IPsec in tunnel
mode or via an IP-in-IP tunnel protected by IPsec in transport
De Clercq et al. Expires September 2003 [Page 5]
Internet Draft draft-ietf-ppvpn-ce-based-03.txt March 2003
mode between two CE devices. [GRE-CE] describes how to use GRE
encapsulation for CE to CE tunneling in a CE-based IPsec VPN
scenario.
2.2 Assumed Reachability
It is assumed in this specification that the CE devices have at least
one IP address that is known to the SP network and that is routable
within the SP's network. It is also assumed that every CE device
knows how to reach the other CE devices attached to the common SP.
This might be via a direct routing entry in the CE's routing table or
alternatively via a default route towards the PE device it is
attached to. These CE IP addresses will be known in the SP network,
if not globally, then at least in the PE devices engaged in the VPN
services.
This means that either a routing protocol will be running between the
CE and the PE device, exchanging routes belonging to the service
provider's routing realm; or alternatively, the CE will have a
configured default route or static route towards the PE, and the PE
will have assigned an IP address to the CE device before or upon
set-up of the IP service offered to the CE device.
As some of the CE's interfaces are in the SP's routing space and some
of the CE's interfaces are in the customer's routing space, CE
devices will need to be able to operate in two distinct (separate and
possibly overlapping) routing spaces.
More details regarding the assumed CE's reachability are provided in
[CE-SOL].
2.3 Assumed Service Provider's infrastructure
It is assumed that the Service Provider has a secure provisioning
channel to every attached CE device. This secure provisioning channel
will be used to exchange VPN-specific configuration information
between the SP's VPN database and the CE devices.
The particular implementation of this provisioning channel is outside
of the scope of this document. Some examples are: (i) manual
configuration by a trusted party, directly on the considered network
element; (ii) via a management protocol running over an IPsec-secured
connection between the SP's management center and the considered
network element; (iii) via a management protocol that has its own
implicit security mechanisms. For scalability reasons, manual
configuration is not recommended.
3. Configuring the CE-based VPN
De Clercq et al. Expires September 2003 [Page 6]
Internet Draft draft-ietf-ppvpn-ce-based-03.txt March 2003
Note that [CE-SOL] proposes a detailed instantiation of the
procedures described in this section.
As a Service Provider that is offering VPN services over its backbone
network will be responsible for the configuration and the management
of a potential large amount of VPNs, it is required that the
provisioning actions for the initial establishment and the
maintenance of a PP CE-based VPN would be minimal.
The minimal configuration required is to first configure the Service
Provider's VPN database with the CE device to be part of a well-
defined VPN. Further device provisioning can be achieved through the
management channel.
For the purpose of CE device configuration, the Service Provider will
maintain a VPN database per VPN customer. The exchange of information
between the SP's VPN database and the targeted CE-devices is achieved
using an information exchange/configuration protocol such as LDAP,
SNMP, COPS, XML/HTTP etc. We will call this protocol 'the management
protocol' throughout the rest of this document.
It is assumed for the scope of this document that the management
channel used for the configuration information exchange by the chosen
protocol is sufficiently secured (e.g. by using a specific IPsec
protection for that purpose, or by using a SSL or SSH protected
channel, etc.).
3.1 (Minimal) configuration needed at the CE device
- 'Management channel' information : the information needed to access
(or to exchange information with) the SP's VPN database ('database
reachability information', authentication information for the VPN
database, encryption information for the configuration management
channel, necessary credentials, etc.). Note that this is assumed to
be present, and that setting up a secure management channel is
outside of the scope of this document.
- Peer CE devices : the IP addresses (in the SP's realm) of the peer
CE devices that belong to the same VPN and to which a direct peering
relationship is required. This information can be one IP address
(e.g. in the case that the considered CE device is a 'spoke' in a
'hub&spoke' topology); this information can be the complete set of
the IP addresses of all the other CE devices belonging to the same
VPN (in the case of a 'fully meshed' topology); or this information
can be a subset of the IP addresses of the CE devices belonging to
the same VPN (for more complex topologies).
- Security Information : the information needed to set up and
De Clercq et al. Expires September 2003 [Page 7]
Internet Draft draft-ietf-ppvpn-ce-based-03.txt March 2003
maintain IPsec Security Associations with the Peer CE devices:
- a set of transforms to use with IPsec (this information relates
to the protection of the actual user data packets) for every
Security Association.
- tunnel property information for every SA that the considered CE
participates in : traffic-driven tunnel or 'permanent' tunnel;
tunnel mode or IPsec transport mode on an IP-in-IP tunnel; dynamic
routing through the tunnel or not.
- an IKE credential: (i) a pre-shared key or (ii) a private
key/certificate pair and a certificate for a Certificate Authority
(these are to be used to establish the IPsec security associations
with the peer CE devices). This credential will be used for the
generation of the keys for all the Security Associations the
considered CE participates in.
- VPN identifier: an identifier that uniquely identifies the VPN that
the customer belongs to. The VPN identifier defined in [RFC2685] can
be used for this purpose, or any unique identifier the PPVPN WG
agrees upon. Note that the use of this VPN identifier will be
necessary when one site is allowed to be part of more than one VPN,
but that this specification does not currently specify that scenario.
Another feature that may require the use of a unique VPN identifier
is the IKE-based membership discovery mechanism described in section
3.2.
This means that the VPN database (identified by a VPN identifier) of
the SP's management system contains a list of all the CE devices
belonging to the specified VPN, a description of the topology (full
mesh, hub&spoke, etc.) and some security-related information related
to every CE-to-CE tunnel.
Note that every CE also needs to be configured as to align the
routing within the VPN with the tunneling between VPN sites. Section
4 describes these issues in more detail.
3.2 Updating configuration information
One of the most important requirements relating to scalability for
PP-VPNs is that the addition/deletion of a certain site to/from an
existing VPN should be possible with a minimal of configuration
effort. Manual configuration of the information related to the new
site into every existing CE in the particular VPN is not a scalable
option. An automatic mechanism for membership discovery/distribution
is therefor required.
De Clercq et al. Expires September 2003 [Page 8]
Internet Draft draft-ietf-ppvpn-ce-based-03.txt March 2003
The CE's IP address in the SP's realm, the VPN-ID of the VPN it
belongs to, the 'role' of the new site in the existing topology (hub,
spoke, etc.), and the necessary security information need to be
configured in the concerned VPN database.
Different methods to achieve the requested 'automatic' behavior are
possible. This section describes some possible approaches but does
not claim to be exhaustive.
o using the SP's management system
In this approach, the customer notifies the SP of the site to be
added (out of band), and the SP's management system takes care of
configuring its VPN database, takes care of provisioning the new
CE device and takes care of updating the other CE devices that
belong to the considered VPN. This provisioning also initiates the
IPsec signaling between the new CE device and the existing CE
devices.
o pushing information from the SP's VPN database
This approach can be seen as a more detailed description of an
example of the previous approach.
The customer first notifies the SP of the site to be added. The SP
then configures its VPN database with the new membership
information. This updating of the VPN database will trigger an
information exchange between the SP's VPN database and the
concerned CE devices (the new CE device and all the CE devices it
has to peer with). This distribution of the updated information
happens over a secured 'management channel', via a configuration
protocol (such as COPS, DHCP, LDAP, SNMP, etc.).
This method implies that the protocol used for the distribution of
the configuration information to the CE devices should be usable
in a "PUSH" mode from 'server' to 'client' (the management system
- server - pushes the updated information to the concerned parties
- clients -). It is to be noted that some information distribution
technologies such as LDAP are natively not PUSH oriented. If the
VPN configuration is stored using such a technology, it is
necessary to define a mechanism that enables the CE to be
triggered so as to fetch VPN configuration from its repository.
Such a mechanism could be based on the use of SNMP messages sent
to the CE device, with specific variables that trigger the fetch
operation.
Note that a solution using this method should integrate it in a
reliable architure.
De Clercq et al. Expires September 2003 [Page 9]
Internet Draft draft-ietf-ppvpn-ce-based-03.txt March 2003
o using the SA signaling protocol (IKE)
The customer first notifies the SP of the site to be added. The SP
then configures the new CE device and its VPN database (this could
eventually be done manually). When the new CE device is configured
with the required configuration information, it will start the
IPsec signaling (via IKE or its successor) with the peer CE
devices it is configured with.
When a peer CE device (that already belongs to the considered VPN)
receives an initial IPsec signaling message, it MUST check whether
the initiating CE device belongs to the set of CE devices the
considered CE needs to peer with, by looking at its VPN
configuration information. If the initiating CE device does not
belong to that set according to its VPN configuration information,
the CE device needs to update its VPN configuration information by
fetching the 'latest' VPN configuration information from the SP's
VPN database (e.g. using a protocol for database retrieval such as
COPS, DHCP, FTP, HTTP, LDAP, etc.) over the secured management
channel. If after the updating of the VPN configuration
information, the initiating CE device is still not part of the CE
devices the considered CE device has to peer with, then the
considered CE device MUST reject the incoming IPsec SA
establishment. If the initiating CE device belongs to the set of
CE devices that the considered CE device must peer with, then the
incoming IPsec SA establishment should be accepted and an IPsec
'tunnel' should be established.
The details of this procedure are outside of the scope of this
document. See [CE-SOL] for a detailed example.
3.3 Setting up the VPN tunnels
When one VPN site sends traffic to another VPN site belonging to the
same VPN, these IP packets will be secured via IPsec. This means that
an IPsec Security Association is needed between each pair of sites
that directly exchange private VPN data with each other.
The Internet Key Exchange protocol (IKE, [IKE]) or its successor will
be used for the purpose of automatic setup of security associations
between VPN sites within the same VPN.
These dynamically established Security Associations can lead to
'permanent' IPsec-secured tunnels. These tunnels are always available
and not traffic-triggered. It is then required to frequently re-
negotiate the SA (via IKE) before the IPsec timers of the connection
time out. The set-up of a 'permanent' IPsec tunnel can be triggered
by the configuration of a new peer CE device within the same VPN. An
De Clercq et al. Expires September 2003 [Page 10]
Internet Draft draft-ietf-ppvpn-ce-based-03.txt March 2003
advantage of this method is that the IPsec tunnel is always
available, and that eventual traffic does not encounter an extra
delay due to the setup time of a new SA. The use of 'permanent' IPsec
tunnels is recommended for CE-based site-to-site VPNs.
Provider provisioned CE-based IPsec VPNs as described by this
document SHOULD use 'permanent' IPsec Security Associations when
dynamic routing through IPsec-secured tunnels is used.
Alternatively, the IPsec SA setup can be triggered by the effective
(data) traffic flow going from one site to another. In this case, the
arrival of data packets at the CE device, coming from within the VPN
site and going to another VPN site, will be noticed by the CE's IPsec
or routing database, and an IKE exchange will be initiated to set up
an IPsec secured connection between both parties. Once the secure
tunnel is set up, the data packets can flow from one site to the
other in a secure way. When no traffic flows for a certain duration
of time, the secure tunnel will be torn down again. An advantage of
this method is that an IPsec tunnel is only to be maintained when
there is effectively traffic flowing. A disadvantage is the extra
delay introduced for the traffic during IKE signaling and the
interaction with the tunneled inter-site VPN routing information
distribution.
Provider provisioned CE-based IPsec VPNs as described by this
document MAY use traffic-driven IPsec SA establishment when static
intra-VPN inter-site routing is used (no dynamic routing through the
IPsec tunnels), see section 4.3. Provider provisioned CE-based IPsec
VPNs as described by this document SHOULD NOT use traffic-driven
IPsec SA establishment when dynamic site-to-site routing through the
IPsec-secured tunnels is used.
The CE configuration determines whether traffic-driven SA
establishment is used or not, and whether dynamic routing through
IPsec tunnels is used or not.
Note that IPsec tunnels are unidirectional in nature, but that the
set up of one direction is accompanied by the set up of the reverse
direction IPsec tunnel.
This document describes two possible ways to use IPsec in CE-based
VPN scenarios (see section 5): in 'transport mode' or in 'tunnel
mode'. The CE configuration, IKE exchange and resulting SA's must
specify which mode will be used.
Note that the number of peer CE devices with which a specific CE
device must have an IPsec connection to secure the data traffic, is
dependent on the specific 'role' of the site in the considered VPN. A
De Clercq et al. Expires September 2003 [Page 11]
Internet Draft draft-ietf-ppvpn-ce-based-03.txt March 2003
hub CE will for example have a larger number of tunnels to support
than a spoke device.
3.4 VPN resilience
When IPsec tunnels are used for VPN site-to-site connection, many
times it is important for a SP to provide its customers with
connection resilience. The site-to-site VPN could be broken due to
either a VPN link failure or a VPN node failure. VPN resilience
support would require both VPN node redundancy and VPN link
redundancy.
To support VPN node redundancy, extra CE routers can be placed. Two
deployed CE routers can provide fail-over and potentially load
balancing support. It is possible that only one end of a VPN link has
redundancy. For example, in a hub-spoke topology, the hub node is
more important than a spoke node. It is not unusual to provide
redundancy just to the hub router.
The VPN link resilience support comes from two levels: IPsec tunnel
level and physical link level. To provide physical link redundancy, a
customer may subscribe two links from the SP. At the IPsec tunnel
level, a customer may set up more than one IPsec tunnel. If the
remote site has only a single CE device, both tunnels will terminate
at the same device. If the remote site has two CE devices, each
tunnel may terminate at different CE devices.
When the redundant VPN links connect to two separate CE devices at
the remote site, the user (or the SP) must decide how to split the
traffic between the two VPN links. One choice is to designate one
link as the primary link which carries all the traffic and leave the
other idle link as the backup. The other choice is to divide the
traffic between the two links. When two links are used, the important
issue is to detect any link failure and divert the traffic to the
healthy link. One way to achieve this is to run routing keep-alive
through both tunnels. When a link is down, the routing protocol is
able to discover the link outage and reroute the traffic accordingly.
4. Exchanging and maintaining VPN routes
One of the requirements for PP CE-based VPNs is that dynamic routing
is not only supported within individual VPN sites, but also between
the different VPN sites of a specific VPN. This means that when a
change in the routing information in a specific site occurs, the
other sites that belong to the same VPN must be notified of that
change.
This document assumes that the routing within a VPN site is
De Clercq et al. Expires September 2003 [Page 12]
Internet Draft draft-ietf-ppvpn-ce-based-03.txt March 2003
controlled by the VPN customer, and thus is outside of the scope of
this specification.
On the other hand, the role of the CE device with regards to routing,
the interaction between the intra-site and inter-site routing and the
relationship between routing and VPN tunnels are addressed in this
specification. For more detailed aspects concerning issues with
regards to routing and CE-based IPsec VPNs, we refer to [TOUCH],
[DUFFY] and [KNIGHT].
4.1 The CE device and VPN routing
On the customer network side, a CE router connects to internal
networks of an enterprise, where one or more subnets can reside. Many
times, the CE router may interact with another internal router.
The CE is involved in (i) the intra-site routing, (ii) the VPN tunnel
termination, and (iii) the inter-site VPN routing. The CE device
could be an integrated device providing both routing and IPsec tunnel
termination. Sometimes, a dedicated VPN terminator may be used.
Implementations in which the VPN tunnel terminator resides on a
firewall are also very common. For the sake of simplicity, we assume
that the CE router is an integrated device that participates in the
intra-site routing (e.g. via an IGP) and at the same time terminates
VPN tunnels.
In the context of this document, the routing aspects within a VPN
site (intra-site routing information distribution) are controlled by
the VPN customer. The role of the SP is either to completely manage
the inter-site reachability distribution or to configure the CE
devices in such a way that the customer may transparently run routing
protocols (or configure static routes) through the VPN tunnels.
4.2 IPsec and routing
IPsec is a layer 3 tunneling protocol, which operates purely at the
IP layer. The IETF IPsec Working Group specifies the IPsec standards
([IPSEC], [RFC2402], [RFC2406], [RFC2407], [RFC2408], and [IKE]). The
interaction between IPsec and layer 3 routing is often troublesome
and has been described in [DUFFY], [TOUCH] and [KNIGHT]. Depending on
individual implementations, difficulty may arise when an IPsec user
wants to support robust routing across IPsec VPNs sites.
Details regarding the problems of the interaction between VPN routing
and VPN tunneling, and some proposed solutions to counter these
issues, can be found in [DUFFY], [TOUCH] and [KNIGHT].
4.3 Mechanisms to exchange VPN routes between VPN sites
De Clercq et al. Expires September 2003 [Page 13]
Internet Draft draft-ietf-ppvpn-ce-based-03.txt March 2003
This document describes two alternative mechanisms for the purpose of
exchanging VPN routes between VPN sites. The mechanism that is in use
for a particular tunnel is identified by the CE configuration
information.
4.3.1 Tunneling routing information between CE devices through the IPsec
tunnels.
In the first mechanism to exchange VPN reachability information,
normal routing protocol messages are tunneled through the IPsec-
secured tunnels between peering sites. The CE-to-CE IPsec-secured
tunnels between VPN sites are then being seen as point-to-point links
by the customer networks and are inserted as such in the routing
protocol functions of the CE devices. This means that when a change
in the reachability occurs in one particular site, a routing protocol
(such as RIP, OSPF, etc.) will take care of the distribution of the
new reachability information within the site, but also to all other
sites, through the VPN tunnels that the considered CE is peering
with.
When routing protocol messages are tunneled through the IPsec-secured
tunnels ('dynamic routing through IPsec-secured tunnels') as per this
section, IPsec transport mode secured IP-in-IP tunnels as per [TOUCH]
SHOULD be used (in contrast to IPsec tunnel mode tunnels).
Note that other approaches may use a combination of dynamic routing
and IPsec tunnel mode tunnels, though it is not clear how
interoperability will then be assured.
Another issue to consider is the fact that using a traffic-driven
tunnel establishment mechanism and at the same time using an approach
whereby a routing protocol (with a keep-alive mechanism) runs on top
of the VPN tunnel, does not seem currently applicable: the delay
introduced by the tunnel establishment phase could lead to a loss of
routing updates and the routing protocol's keep-alive mechanism could
interact with the tunnel establishment in an undesired way. Therefor,
when dynamic routing is used through IPsec-secured CE-to-CE tunnels,
traffic-driven SA establishment SHOULD NOT be used.
4.3.2 Exchanging VPN reachability information via SP's management
In non-dynamic environments, SP's management can distribute static
routes to the CE devices.
When CE-to-CE IPsec tunnel mode tunnels are used (with the complete
SPD-controlled filtering), a management-based inter-site reachability
information distribution SHOULD be used.
De Clercq et al. Expires September 2003 [Page 14]
Internet Draft draft-ietf-ppvpn-ce-based-03.txt March 2003
When traffic-driven SA establishment is used, a management-based
inter-site reachability information distribution SHOULD be used.
Within the sites themselves, the CE device may then inject the
updated reachability information into the local routing protocol
function.
Note that this method does not require the use of the same
'management protocol' for the configuration of the CE device and for
the dynamic exchange of reachability information. A dedicated
protocol may be used for that purpose.
4.3.3 Applicability of the mechanisms to exchange VPN routes between the
VPN sites
The 'tunneling approach' (as described in section 4.3.1) does not
require a new interaction between the customer and the SP and offers
transparent routing features to the VPN customer. Existing routing
protocols can be used and the SP is not involved with the propagation
of routing information updates. It prohibits some specific IPsec
features though (such as traffic-initiated SA establishment, and the
complete use of SPD-based filtering).
The 'management approach' (as described in section 4.3.2) allows for
the full use of specific IPsec features, but requires a new
interaction between the CE device and the SP, and breaks the VPN
customer's routing transparency. The SP participates in the inter-
domain distribution of routing information.
4.4 Relationship between VPN membership, VPN tunnel status and routing
When VPN membership changes, VPN tunnels may need to be intentionally
deleted, and this change needs to be reflected in the routing
information of all sites belonging to the VPN (see section 6).
But VPN tunnels can also un-intentionally break for a variety of
reasons. The routing within the VPN will be affected and updated
information must be distributed over all VPN sites.
5. Tunneling IP traffic (user data) among VPN sites
This section describes the processes that an IP packet that is sent
from one VPN site to another will go through. This is dependent on
the way that IPsec is used. This document describes two possible ways
to use IPsec in CE-based VPN implementations: IPsec in tunnel mode,
and IPsec in transport mode.
An IP packet that is sent by an IP device in a certain site and
De Clercq et al. Expires September 2003 [Page 15]
Internet Draft draft-ietf-ppvpn-ce-based-03.txt March 2003
destined for an IP device in another site belonging to the same VPN,
will be forwarded as follows.
The device in the sending site sends an IP packet (using a private
address space) on its LAN network. The next hop for this destination
IP address will (at some point in time) be the site's CE device
(according to the routing/forwarding in the VPN site). The processing
by the CE device now is dependent on the implemented mode for IPsec.
The use of IPsec in tunnel mode has the advantage that the complete
range of SPD-checks remain usuable, but has the disadvantage that
dynamic routing through the tunnels is not supported. The use of
IPsec in transport mode secured IP-in-IP tunnels has the advantage
that dynamic routing through the tunnels is fully supported, but has
the disadvantage that the complete range of SPD-checks is not
supported.
Note that the following description is not meant to specify an
implementation strategy; any implementation procedure wich produces
the same results is acceptable.
o IPsec in tunnel mode
When IPsec is used in tunnel mode in this context, the IPsec
driver in the CE device must do the following:
- analyze the private IP packets arriving from within the site and
select/setup an appropriate SA with the appropriate destination CE
device.
- authenticate and/or encrypt the private IP packet according to
the (tunnel mode-specific) rules described in the SA, AND
encapsulate the packet in an IPsec header AND encapsulate the
packet in a new 'outer' IP header. This 'outer' IP header has the
CE's non-private (i.e. routable in the SP's realm) IP address in
the source IP address field and the destination CE's non-private
(i.e. routable in the SP's realm) IP address in the destination IP
address field.
o IPsec in transport mode (see also [TOUCH] for a detailed
specification)
When IPsec is used in transport mode in this context, the CE
device must first analyze the private IP packets arriving from
within the site and select the appropriate destination CE, based
on the routing/forwarding information. The CE device then
encapsulates the private IP packet into a new IP packet (IP-in-IP
encapsulation/tunneling), with the own non-private (i.e. routable
De Clercq et al. Expires September 2003 [Page 16]
Internet Draft draft-ietf-ppvpn-ce-based-03.txt March 2003
in the SP's realm) IP address in the source address field of the
new header and the destination CE's non-private (i.e. routable in
the SP's realm) IP address in the destination address field of the
new header. The CE device then processes this new IP packet to its
IPsec driver.
The IPsec driver in the CE device must then do the following:
- analyze the IP packets that have been IP-in-IP encapsulated and
select the appropriate SA (based on the packet's outer header
destination address).
- authenticate and/or encrypt the private IP packet according to
the (transport mode-specific) rules described in the SA and insert
an IPsec header (according to IPsec in transport mode).
The CE device then sends the IPsec packet to the PE device, and the
IPsec packet will then be forwarded using 'normal' IP forwarding
across the SP's network, based on the outer header's IP destination
address, that is the destination CE's 'global' (i.e. routable in the
SP's realm) IP address. The egress PE device will also only examine
the outer IP header and send the IP(sec) packet to the destined CE
device. The egress CE device will recognize itself as the destination
node (the IP packet has the CE's IP address in the outer IP
destination address field). The destination CE's IPsec driver will
then, based on the appropriate Security Association (identified by
the packet's SPI field in the IPsec header), perform IPsec
authentication and/or decryption. Dependent on whether tunnel mode or
transport mode IPsec is used, the packet will be decapsulated by the
IPsec driver itself or sent to the IP-in-IP decapsulation function.
The resulting (private) IP packet will then be further processed in
the CE's IP forwarding table and send on the LAN network to the
appropriate destination IP device.
Note that IPsec tunnels might unintentionally terminate or break.
This may have serious consequences if VPN membership and VPN routing
information is not changed accordingly within the VPN. Indeed, the
unnoticed termination of a VPN tunnel can result in the creation of
black holes.
This means that a mechanism must exist to monitor the state of the
VPN tunnels. The following possibilities are identified: (i) the use
of an IPsec-specific keep-alive mechanism [IPSEC-DPD]; (ii) when a
routing protocol runs on top of the IPsec VPN tunnel (see section
4.3.1), the routing protocol's keep-alive mechanism can serve that
purpose; and (iii) the SP's management system could directly control
the state of the VPN tunnels.
De Clercq et al. Expires September 2003 [Page 17]
Internet Draft draft-ietf-ppvpn-ce-based-03.txt March 2003
6. Deleting an existing VPN site
When the VPN customer decides to delete an existing site from a
certain VPN, the customer first needs to inform the SP. The SP will
change the VPN's configuration information accordingly in its VPN
database.
In analogy with the configuration update mechanisms described in
section 3.2, multiple approaches exist to delete a specific site from
an existing VPN.
The SP can gracefully tear down all the concerned IPsec tunnels at
both ends via either manual configuration or via a re-provisioning of
all impacted CE devices with the used management system. IKE will
then be used to tear down the IPsec security associations.
Alternatively, the IKE sessions could be just timed out.
Alternatively, when IKE-based discovery is used, the SP will update
its VPN database and will provision the to-be deleted CE to tear down
its IPsec connections via IKE. The peering CE devices will then
update their VPN configuration information as described in section
3.2.
In the meantime, if a routing protocol runs on top of the VPN tunnels
(and keep-alives are used), it will discover the topology change and
update the necessary routing information automatically. If on the
other hand, the SP management takes care of the inter-site routing
information distribution, it will have to update the routes in the
affected CEs when VPN tunnels are deleted.
7. Provider provisioned CE-based VPNs and NAT
NAT provides address translation between two realms, such as between
the private address space and the public address space. For site-to-
site intranet VPN, the tunneled data usually remain in the same
customer network address space. NAT is usually not required, unless
two sites have overlapping address spaces. In that case, NAT can be
used to solve the address-overlapping problem.
In normal IPsec tunnel mode operation, after the user data is
encapsulated by IPsec, the resulted packets are protected by packet
encryption and/or authentication. Any further NAT changes on the
packets will be detected at the receiving tunnel end, resulting in
the packets being dropped. Currently the IPsec Working Group is
working on a new mechanism so that IPsec packet can be safely NATed.
Before the IPsec WG finalizes the IPsec over NAT standards, this
draft assumes that there is no NAT function performed between the two
IPsec tunnel end points.
De Clercq et al. Expires September 2003 [Page 18]
Internet Draft draft-ietf-ppvpn-ce-based-03.txt March 2003
The scenario in which NAT applies is when the CE router serves a
split stack function and provides both site-to-site VPN connection
and direct Internet access. In this case, customer address space
traffic is separated into two streams, one part for site-to-site
private traffic and one part for direct Internet traffic. In this
case the CE device performs NAT processing for the direct Internet
traffic. The NAT function performed by the CE router takes care of
the customer address space to public Internet address space
conversion. Note that in the case that a certain site has both VPN
and Internet access, a firewall should be configured at the site's CE
device.
See [CE-SOL] for more details concerning solutions for simultaneous
VPN and Internet Access connectivity.
8. Extranet functionality with provider provisioned CE-based VPNs
For the time being, this document deals mostly with intranet
functionality provided by CE-based VPNs. The provisioning of an
extranet service will affect the routing, tunnel topology and
security features of the concepts described so far. The PP CE-based
extranet VPN functionality is TBD.
9. Quality of Service
TBD
10. Security Considerations
The security aspects of what is presented in this document are
implicitly discussed in most of the sections. This draft is for a
large part focussing on security aspects.
Note that the security of the mechanisms presented here is highly
dependent on the following factors:
- the security of the 'management channel', used by the management
protocol to configure the VPN CE devices.
- the security of the CE-device itself
- the security aspects of the credentials: the IPsec credential
must be generated, provisioned, updated, and stored securely
- for a VPN with a complex topology, every tunnel must use the
same grade of security strength, otherwise, a single weak link
degrades the whole VPN
De Clercq et al. Expires September 2003 [Page 19]
Internet Draft draft-ietf-ppvpn-ce-based-03.txt March 2003
11. Acknowledgements
The authors would like to thank the following persons for their
valuable contributions to this document: Mahadevan Iyer, Cheng-Yin
Lee, Lars Eggert, Brian Gleeson, Archana Khetan, Paul Knight, Sankar
Ramamoorthi, Eric Rosen, Michael Choung Shieh, Joe Touch, Eric
Vyncke, S. Felix Wu, Yu-Shun Wang, Alex Zinin.
12. References
[CE-SOL] De Clercq, J., Lee, C., Knight, P., "Provider Provisioned
CE-based Virtual Private Network solution using IPsec and HTTP",
draft-declercq-ppvpn-ce-based-sol-00.txt, Work in progress
[DUFFY] Duffy, M., "Framework for IPsec Protected Virtual Links for
PPVPNs", draft-duffy-ppvpn-ipsec-vlink-00.txt, Work in progress
[FRAMEWORK] Callon, R. et al., "A Framework for Layer 3 Provider
Provisioned Virtual Private Networks", draft-ietf-ppvpn-framework-
0x.txt, Work in progress
[GRE-CE] Khetan, A., et al., "Use of GRE for routing support in IPsec
VPNs", draft-khetan-sp-greipsec, Work in progress
[IKE] Harkins, D. and Carrel, D., "The Internet Key Exchange (IKE)",
November 1998, RFC 2409
[IPSEC] Kent, S., Atkinson, R., "Security Architecture for the
Internet Protocol", November 1998, RFC 2401
[IPSEC-DPD] Huang, G., Beaulieu, S., Rochefort, D., "A Traffic-Based
Method of Detecting Dead IKE Peers", draft-ietf-ipsec-dpd-0x.txt,
Work in progress
[KNIGHT] Knight, P., Gleeson, B., "A Method to Signal and Provide
Dynamic Routing in IPsec VPNs", draft-knight-ppvpn-ipsec-dynroute,
Work in progress
[LEE-DHCP] Lee, C.Y., "Customer Equipment Auto-configuration", March
2002, work in progress
[RFC2402] Kent, S., Atkinson, R., "IP Authentication Header",
November 1998, RFC 2402
[RFC2406] Kent, S., Atkinson, R., "IP Encapsulating Security Payload
(ESP)", November 1998, RFC 2406
[RFC2407] Piper, D., "The Internet IP Security Domain of
De Clercq et al. Expires September 2003 [Page 20]
Internet Draft draft-ietf-ppvpn-ce-based-03.txt March 2003
Interpretation for ISAKMP" November 1998, RFC 2407
[RFC2408] Maughan, D., et al., "Internet Security Association and Key
Management Protocol (ISAKMP)", November 1998, RFC 2408
[TOUCH] Touch, J. and Eggert, L., "Use of IPSEC transport mode for
Virtual Networks", draft-touch-ipsec-vpn-0x.txt, Work in progress
13. Authors' Addresses
Jeremy De Clercq
Alcatel
Fr. Wellesplein 1, 2018 Antwerpen, Belgium
E-mail: jeremy.de_clercq@alcatel.be
Olivier Paridaens
Alcatel
Fr. Wellesplein 1, 2018 Antwerpen, Belgium
E-mail: olivier.paridaens@alcatel.be
Cliff Wang
De Clercq et al. Expires September 2003 [Page 21]
