Internet DRAFT - draft-gleeson-ipsec-ppvpn
draft-gleeson-ipsec-ppvpn
Internet Engineering Task Force B. Gleeson
INTERNET DRAFT Nortel Networks
Expires August 2001
Uses of IPsec with Provider Provisioned VPNs
<draft-gleeson-ipsec-ppvpn-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
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.
Abstract
This draft gives a brief overview of some scenarios where IPsec [1]
can be used as a tunneling mechanism in the context of provider
provisioned virtual private networks (PPVPNs). It also suggests some
areas where extensions to IPsec could be considered.
Table of Contents
1.0 Introduction ................................................ 2
2.0 VPN Reference Model ......................................... 2
2.1 CE to PE IPsec tunnels ...................................... 3
2.2 PE to PE IPsec tunnels ...................................... 4
2.3 CE to CE IPsec tunnels ...................................... 5
3.0 Extensions to IPsec ......................................... 6
3.1 Routing over IPsec tunnels .................................. 6
3.2 Associating an IPsec tunnel with a VPN ...................... 8
Gleeson [Page 1]
INTERNET DRAFT Uses of IPsec with PPVPNs February, 2001
4.0 References .................................................. 9
5.0 Author Information .......................................... 10
6.0 Full Copyright Statement .................................... 10
1.0 Introduction
This draft gives a brief overview of some scenarios where IPsec can
be used as a tunneling mechanism in the context of provider
provisioned virtual private networks (PPVPNs). It also suggests some
areas where extensions to IPsec could be considered.
In this draft IPsec tunnels are viewed as a tunneling mechanism that
can be used in a variety of different types of VPNs, either by
themselves or in combination with other tunneling mechanisms. Thus
there is no single type of VPN that is called an "IPsec VPN", and
this term is not used.
2.0 VPN Reference Diagram
The following diagram shows the VPN reference model used in this
draft. A more detailed description of this reference model, and more
information on the use of PPVPNs and the mechanisms that can be used
to implement PPVPNs can be found in [2]. Details on the service
requirements for PPVPNs can be found in [3].
Gleeson [Page 2]
INTERNET DRAFT Uses of IPsec with PPVPNs February, 2001
+---+ +---+
| P |....| P |
+---+ +---+
| |
+----+ +----+ +----+ +---+
| CE |----| PE | | PE |--|CE |
+----+ +----+ +----+ +---+
| |
+---+ +---+
| P |....| P |
+---+ +---+
<=========>
CE to PE
<======================>
PE to PE
<========================================>
CE to CE
PE - provider edge device
P - VPN unaware provider core device
CE - customer edge device (may be managed by provider)
Figure 1 - VPN Reference Model
The following scenarios are considered for use of IPsec tunnels:
- between CE and PE
- between PE and PE
- between CE and CE
Note that the options are not mutually exclusive, instead they may be
combined as necessary.
2.1 CE to PE IPsec tunnels
The primary use of CE to PE IPsec tunnels is where the customer site
is connected to the provider backbone via an insecure access network
(e.g. the Internet). Different deployment scenarios are possible,
for example the CE device could be a router in a customer network, or
could be a host computer performing voluntary tunneling with IPsec
alone, or could be a host computer running IPsec to secure a PPP/L2TP
session. All the standard IPsec features for authentication and
Gleeson [Page 3]
INTERNET DRAFT Uses of IPsec with PPVPNs February, 2001
encryption can be used without modification in this scenario. Note
that the initial IPsec specifications did not fully specify the use
of Diffserv with IPsec tunnels, but this issue has subsequently been
addressed in [8].
CE to PE IPsec tunnels can be used with network based layer-3 VPNs
and (some types of) network based layer-2 VPNs. In either case the PE
router terminates the IPsec tunnel, and for traffic received over the
tunnel extracts a packet or frame to be forwarded. For a layer-3 VPN
this will be an IP packet and will be forwarded according to a per-
VPN IP forwarding table using IP address information in the packet.
For a layer-2 transparent LAN VPN service, an ethernet frame (perhaps
encapsulated in GRE / IP / IPsec) can be extracted and forwarded
according to a per-VPN bridge forwarding table using MAC address
information in the frame. Similarly traffic in the reverse direction
is sent to the customer site across the IPsec tunnel as a result of a
lookup on the per-VPN IP or bridge forwarding table (or when MPLS is
used as the backbone technology the outgoing IPsec interface may be
identified by means of an MPLS label, avoiding any forwarding table
lookup).
One area that may benefit from standardization is the case where a
routing protocol is run over the IPsec tunnel, in order to support
multi-homing of CE devices for the purpose of redundancy. This is
discussed further in section 3.1 below.
2.2 PE to PE IPsec tunnels
PE to PE IPsec tunnels may be used by a provider to provide strong
security in deployment scenarios where untrusted equipment or links
lie in the path between two PEs. For example if a service provider
owns and administers the PE routers, but does not own and administer
all of the P routers and the layer-2 and layer-1 infrastructure that
interconnects the PE routers, the VPN service provider may wish to
employ strong security for the PE to PE tunnels. The VPN service
provider is then solely responsible for the security of the customer
traffic, no matter if parts of the network infrastructure have been
outsourced to other providers.
Where a service provider views the PE to PE paths as inherently
secure, either because the provider owns all the backbone
infrastructure and the entire network is deemed secure, or where the
pieces of the backbone outsourced to another provider are viewed as
secure (perhaps SONET/SDH circuits, wavelengths or fibers, then there
is no need to additionally secure the PE to PE traffic via IPsec.
Independently of the issue of securing customer data traffic between
two PEs, is the need for one PE to know that a PE with which it is
Gleeson [Page 4]
INTERNET DRAFT Uses of IPsec with PPVPNs February, 2001
establishing tunnels is a valid PE. The set of valid peer PEs may be
configured via a secure network management channel in which case
there is no need to dynamically authenticate a remote PE. However in
some cases it may be useful to be dynamically authenticate a remote
PE using IKE [4]. For example if a dynamic VPN membership protocol is
being used in a scenario where a VPN may span two or more service
providers, the use of dynamic PE authentication removes the need for
each provider to maintain lists of valid PEs in all the other
provider domains.
Another aspect of the use PE to PE IPsec tunnels is that with certain
VPN approaches it is useful to be able to use IPsec solely as a
signaling protocol for IP tunnels, and not to provide any security.
For example if an IPsec tunnel is established that uses the null
encryption algorithm and no authentication, then no security is being
provided, but such a mechanism may still be useful as it allows the
dynamic establishment of an IP tunnel with an authenticated peer, and
allows that tunnel to be associated with a specific VPN. The IPsec
specifications expressly prohibit the establishment of an IPsec
tunnel that uses neither encryption or authentication, as in the
classical use of IPsec this mode makes little sense, but in the
context of VPNs this restriction is unnecessary.
PE to PE IPsec tunnels can be used with any type of network based
VPN. With a layer-3 VPN IP packets are forwarded between PEs over the
IPsec tunnels, and with a layer-2 VPN frames can be encapsulated
(e.g. using GRE) and then sent over the IPsec tunnels. An IPsec
tunnel itself could be nested on top of an MPLS LSP.
One area that may benefit from standardization is a mechanism to
allow an IPsec tunnel to be associated with a particular VPN. This is
discussed further below in section 3.2.
2.3 CE to CE IPsec tunnels
CE to CE IPsec tunnels can always be used between IPsec capable CE
devices, independently of the method used to interconnect the two
CEs. For example the intervening network could be the Internet, a
provider IP backbone, a layer-2 network based VPN or a layer-3
network based VPN. Standard IPsec can be used with no modifications
to provide strong security across the intervening network.
From an administrative point of view, the CE devices can be managed
either by the customer or by the provider on behalf of the customer,
but from a technical point of view the operation of the devices is
the same in either case.
Gleeson [Page 5]
INTERNET DRAFT Uses of IPsec with PPVPNs February, 2001
In order for a CE device to use IPsec tunnels, it is necessary for
the CE to maintain a mapping between a set of IP destinations and a
remote IPsec tunnel endpoint along with a set of security attributes
(e.g. encryption algorithm to use) for the tunnel.
If configuration is done at the device level this is a significant
amount of configuration, as any time a new CE is added to the network
the mapping tables need to be updated such that all the old CEs learn
about the mappings needed for the IP destinations behind the new CE,
and the new CE learns about the mappings needed for the IP
destinations behind all the existing CEs. Where all the CEs are made
by the same vendor, vendor-specific network management systems are
commonly used to reduce the configuration burden, as such an NMS can
take a network-wide view and configure each CE appropriately. Work is
progressing in the IPSP WG of the IETF on standard ways of
configuring IPsec on devices using a policy or management information
base [5] and work is also being done in this area by the Distributed
Management Task Force (DMTF) [9].
In some cases it is possible to simplify or automate the maintenance
of the IPsec mapping tables by gathering information from any routing
protocols running on the CE. For example for CE to CE IPsec tunnels
running over a layer-2 VPN, the necessary mappings can be gleaned
from route table information (i.e. IP destinations and their
associated next-hops).
3.0 Extensions to IPsec
This section looks at areas where extensions to IPsec may be useful
within the context of PPVPNs.
3.1 Routing over IPsec tunnels
Consider the case where a customer site is multi-homed to the
provider network as follows:
Gleeson [Page 6]
INTERNET DRAFT Uses of IPsec with PPVPNs February, 2001
+----+ +----+ +---+
--- | CE |----| PE |-----| P |....
| +----+ +----+ +---+
| | |
+---+ | +----------+
| C |--| | |
+---+ | +-------+ |
| | |
| +----+ +----+ +---+
--- | CE |----| PE |-----| P |....
+----+ +----+ +---+
Figure 2 - Routing over IPsec tunnels
The customer host C is reachable via two CE devices, each of which is
attached to two PEs. This provides for redundancy and allows for
connectivity to host C despite any single point of failure of a PE,
CE, or CE to PE link. A typical scenario would be to run routing
across the PE to CE links. This allows the failure of any device or
link to be dynamically detected, and for rerouting to occur onto a
new path. This capability is needed independently of the type of PE
to CE link, which could be an ATM or FR circuit, for example, or in
the case considered here, an IPsec tunnel.
In classical IPsec when an IPsec tunnel is created the set of IP
packets that will subsequently traverse the tunnel are specified when
the security association (SA) is created. This is done via the
optional client identifier payloads in a Quick Mode message. However
in general when routing is run over a link the set of IP packets that
will subsequently traverse the link is not known at SA establishment
time. Instead this is determined by the operation of the routing
protocol itself. There is thus a need to be able to represent the
semantics of 'wildcard' when establishing an SA. There is no standard
way of specifying this. If the client identifiers are omitted this
has the semantics of specifying that only packets that originate or
terminate on the CE or PE will be carried over the tunnel, and that
no transit traffic will be carried. Different proprietary solutions
have been implemented to solve this issue.
In classical IPsec, the process of deciding which packets get sent
over an IPsec tunnel is modeled as applying an IPsec-specific packet
filter to all packets that traverse a given IP interface. In contrast
in the scenario described above the IPsec tunnel itself is modeled as
an IP interface that is visible to routing, just like any other
interface. The process of deciding which packets get sent over an
IPsec tunnel is the result of standard IP forwarding, typically in
Gleeson [Page 7]
INTERNET DRAFT Uses of IPsec with PPVPNs February, 2001
association with service independent packet classification (which may
be application specific), and firewall and route filtering
functionality.
As the IPsec architecture specification [6] itself states, the model
described in that document is a nominal model, not a specification of
the internal structure of an implementation. Other models, such as
the one described above are equally valid, but in the past this has
caused confusion due to too literal an interpretation of the model
described in [6].
3.2 Associating an IPsec tunnel with a VPN
Consider the case where a layer-3 VPN service is being provided and
IPsec tunnels are being used between two PEs, as in the following
diagram.
10.0.1.1 10.0.2.1
+----+ +----+
| CE1|====== ======| CE2|
+----+ | | +----+
| SA for VPN A |
+----+===============+----+
| PE1| | PE2|
+----+\\\\\\\\\\\\\\\+----+
| SA for VPN B |
+----+ | | +----+
| CE3|\\\\\\ \\\\\\| CE4|
+----+ +----+
10.0.1.1 10.0.2.1
CE1 and CE2 are in VPN A
CE3 and CE4 are in VPN B
Figure 3 - VPN specific SAs
The PEs need to establish two IPsec tunnels, one for VPN A and one
for VPN B. VPN A and VPN B use the same private address space of
10.0.0.0/8. In this case it is necessary to be able to associate an
IPsec tunnel, and associated SAs, with a particular VPN. An
identification of the VPN needs to be included as part of IKE
signaling, such that an incoming SA establishment request can be
matched with the appropriate VPN.
Gleeson [Page 8]
INTERNET DRAFT Uses of IPsec with PPVPNs February, 2001
One method of doing this has been described in [7], which defined a
new Domain of Interpretation (DOI) for VPNs. Another scheme is to
define a new ISAKMP payload - a VPN identifier payload - and to
include this as an additional payload in the first and second
messages of a Quick Mode exchange. This allows the Quick Mode
messages, and the SAs created as a result, to be associated with a
particular VPN.
4.0 References
[1] The set of RFCs 2401-2412, 2085, 2104 and 2451.
[2] Callon, R. et al, "A Framework for Provider Provisioned Virtual
Private Networks", <draft-ietf-ppvpn-framework-00.txt>,
February 2001.
[3] <reference to PPVPN service requirements document needed>
[4] Harkins, D. and C. Carrel, "The Internet Key Exchange (IKE)", RFC
2409, November 1998.
[5] Li, M. et al, "IPSec Policy Information Base", <draft-ietf-ipsp-
ipsecpib-01.txt>, November 2000.
[6] Kent, S. and R. Atkinson, "Security Architecture for the Internet
Protocol", RFC 2401, November 1998.
[7] Lordello, C. et al, "VPN-ID-Enhanced IPSec-VPN DOI for ISAKMP",
<draft-lordello-ipsec-vpn-doi-00.txt>, August, 2000
[8] Black, D. "Differentiated Services and Tunnels", RFC 2983,
October 2000
[9] Lortz, V. et al, "IPsec Policy Model",
http://www.dmtf.org/spec/Whitepapers/DSP0118.doc, November 2000
Gleeson [Page 9]
INTERNET DRAFT Uses of IPsec with PPVPNs February, 2001
5.0 Author Information
Bryan Gleeson
Nortel Networks
2305 Mission College Blvd
Santa Clara CA 95054
USA
Tel: +1 (408) 565-2625
Email: bgleeson@nortelnetworks.com
6.0 Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Gleeson [Page 10]
