Network Working Group Jeremy De Clercq
Internet Draft Yves T'Joens
Expiration Date: January 2001 Peter De Schrijver
Alcatel
July 2000
BGP/IPsec VPN
<draft-declercq-bgp-ipsec-vpn-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/ietf/1id-abstracts.txt
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
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 a method by which a Service Provider may use
an IP backbone to provide VPNs for its customers. IPsec tunnels are
deployed through the backbone, and the forwarding of packets over the
backbone relies on normal IP forwarding. BGP is used for
distributing (private) routes over the backbone.
This model is based on the model described in RFC 2547 [RFC2547], and
the internet-draft that obsoletes it [RFC2547bis]. The main
difference is that in this model IPsec is used as tunneling mechanism
instead of MPLS.
De Clercq, et al. Expires December 2000 [Page 1]
Internet Draft draft-declercq-bgp-ipsec-vpn-00 May 2000
The purpose of extending on the procedures defined in [RFC2547], is
to offer an increased level of security by building upon the
authentication and encryption services of IPsec, particularly for
interdomain VPN operation, while it has the added benefit that no PE
to PE MPLS backbone is required.
Note however that the model does not exclude the use of MPLS in
segments of the backbone to improve on traffic engineering and/or QoS
aspects.
De Clercq, et al. Expires December 2000 [Page 2]
Internet Draft draft-declercq-bgp-ipsec-vpn-00 May 2000
Table of Contents
1 Introduction .............................................. 4
1.1 Motivation ................................................ 4
1.2 Virtual Private Networks .................................. 4
1.3 Edge Devices .............................................. 5
1.4 Multiple Routing and Forwarding Instances in PEs .......... 5
1.5 VPNs with Overlapping Address Spaces ...................... 6
1.6 VPNs with Different Routes to the Same System ............. 6
1.7 SP Backbone Routers ....................................... 7
1.8 Security .................................................. 7
1.9 Using IPsec in the Backbone ............................... 7
2 Sites and CEs ............................................. 8
3 VPN Routing and Forwarding Instances ...................... 8
4 The VPN-SPI ............................................... 9
4.1 Introduction .............................................. 9
4.2 The VPN-SPI in the IKE negotiation ........................ 10
4.2.1 VPN-SPI format, V-flag = 1 ................................ 10
4.2.2 Non-VPN-SPI format, V-flag = 0 ............................ 12
4.2.3 Use of the VPN-SPI in the IKE negotiation ................. 13
4.3 The VPN-SPI in the IPsec processing ....................... 13
4.3.1 Format and Interpretation of the VPN-SPI
in the IPsec processing ................................... 14
4.3.2 Outbound IPsec processing ................................. 14
4.3.3 Inbound IPsec processing .................................. 15
4.4 Use of the VPN-SPI after the inbound IPsec processing ..... 15
4.5 Achievement ............................................... 15
5 VPN Route Distribution via BGP ............................ 16
5.1 The VPN-IPv4 Address Family ............................... 16
5.2 Controlling Route Distribution ............................ 16
5.2.1 The Route Target Attribute ................................ 17
5.2.2 The SPI-label Attribute ................................... 17
5.2.3 Route Distribution among PEs by BGP ....................... 19
5.2.4 How VPN-IPv4 NLRI is Carried by BGP ....................... 20
5.2.5 Building VPNs using Route Targets ......................... 21
6 Forwarding across the Backbone ............................ 21
7 How PEs learn Routes from CEs ............................. 21
8 How CEs learn Routes from PEs ............................. 22
9 Inter-Provider Backbones .................................. 23
10 Use of an MPLS Backbone ................................... 23
11 Security .................................................. 24
12 Scalability ............................................... 24
13 References ................................................ 25
14 Acknowledgements .......................................... 25
15 Authors' Addresses ........................................ 25
De Clercq, et al. Expires December 2000 [Page 3]
Internet Draft draft-declercq-bgp-ipsec-vpn-00 May 2000
Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
1.0 Introduction
Most of the definitions used in this introduction come from the model
presented in [RFC2547bis]. For the sake of completeness, we introduce
them in this document too.
1.1 Motivation
This document proposes a model to deploy VPNs that extends on the
model presented in [RFC2547bis]. The purpose of extending the VPN
procedures described in [RFC2547bis] is twofold:
a) The IPsec based VPN model does not require the presence of an
MPLS-aware backbone. Thereby allowing a wider deployment of
inter-provider backbone VPNs. Note that the usage of MPLS over
certain segments of the backbone is not excluded, and could be
used for traffic engineering and QoS purposes.
b) The IPsec based VPN model offers stronger security services
than the "layer-2" security offered by the model described in
[RFC2547bis]. Note that while "layer-2" security might be
sufficient for intra-domain VPN operation, it might be short in
providing security when building VPNs over multiple adjacent
backbones, some of which might not even be VPN aware.
This document proposes an IPsec based VPN model that is easy to
combine with [RFC2547bis] and that offers the additional advantages
stated before.
Note further that the procedures as described in this document do not
require any extensions to the IPsec framework, and as such can make
use of an existing implementation base.
1.2 Virtual Private Networks
Like in [RFC2547bis], we consider a set of "sites" which are attached
to a common network which we call the "backbone". On this topology we
apply some policy to create a number of subsets of that set of sites,
and we impose the following rule: two sites may have IP connectivity
over that backbone only if at least one of these subsets contains
them both.
De Clercq, et al. Expires December 2000 [Page 4]
Internet Draft draft-declercq-bgp-ipsec-vpn-00 May 2000
The subsets that we have created are "Virtual Private Networks"
(VPNs). Two sites have IP connectivity over the common backbone only
if there is some VPN that contains them both. Two sites which have no
VPN in common, have no connectivity over that backbone.
We consider the case where the owner and operator of the "backbone"
is a Service Provider (SP), and where the owners of the "sites" are
the customers of that SP. In this document, we discuss mechanisms
that may be used to implement the policies to determine whether a set
of sites belong to a certain VPN. We don't focus on the question
whether it is the SP or the customer that implements these policies,
though this model allows for both approaches.
The model presented in this document allows for the deployment of a
wide range of policies (leading to different communication
topologies: full mesh, hub and spoke, ...).
1.3 Edge Devices
We suppose that at each site, there are one or more Customer Edge
(CE) devices, each of which is attached via some sort of data link to
one or more Provider Edge (PE) routers. Routers in the Provider's
network backbone which do not attach to CE devices are known as "P
routers".
The CE device may be a single host, it may be a switch if the
considered site is a single subnet, and in general, the CE device may
be expected to be a router.
We will say that a PE router is 'attached to a VPN' if it is attached
to a CE device that is in that VPN.
When the CE device is a router, it is a routing peer of the PE(s) it
is attached to (by means of any routing protocol), but it is NOT a
routing peer of the other CE routers in the other sites, even if they
are in a common VPN. Routers at different sites do not directly
exchange routing information with each other, they even don't have to
know of each other's existence at all. Like in the BGP/MPLS VPN model
[RFC2547bis], in this document, a VPN is not an "overlay" on top of
the SP's network, and a VPN customer does not have to manage a
"virtual backbone" in the SP's backbone.
1.4 Multiple Routing and Forwarding Instances in PEs
Every PE router maintains a number of separate forwarding tables.
Every site to which the PE is attached must be mapped on one of these
forwarding tables. In the scope of this document, we will use the
De Clercq, et al. Expires December 2000 [Page 5]
Internet Draft draft-declercq-bgp-ipsec-vpn-00 May 2000
term VRF (VPN Routing and Forwarding Instance) to describe the
instances in the PE that do the forwarding and the routing in a
specific context and that contain a specific separate forwarding
table.
So this means that every site is mapped to a particular VRF.
When a packet is received by a PE router from a specific site, the
VRF associated with that site must be used to handle that packet. The
forwarding table in a VRF associated with a particular site must be
populated ONLY with routes that lead to sites that have at least a
VPN in common with the considered site. This prevents communication
between sites that are not in the same VPN.
The way this 'selective population' of routing tables is done, is
explained further in this document.
The relationship between sites and VRFs is a one-to-one or a multi-
to-one relationship. More than one site can be associated with the
same VRF only if they have access to the same set of routes (if they
have all their VPNs in common).
A PE router is "attached" to a site when it is the endpoint of an
interface or "sub-interface" (PVC, VLAN, etc.) whose other endpoint
is a CE device. It is the interface through which the PE received a
packet that identifies the VRF to send the packet to.
1.5 VPNs with Overlapping Address Spaces
An important requirement for VPNs is that different VPNs must be able
to use overlapping private address spaces. This model allows the
usage of overlapping address spaces, for VPNs that do not have sites
in common.
The fact that sites in different VPNs are mapped to different VRFs
(thus to different routing and forwarding contexts) in the PEs, makes
it possible for different VPNs to have overlapping address spaces.
The usage of the IPsec tunnel mode in the backbone network hides the
private addresses in that backbone, so that also there all possible
ambiguity disappears when using overlapping address spaces.
1.6 VPNs with Different Routes to the Same System
As it is stated in [RFC2547bis], the fact that routes are included
independently in the different VRFs makes it possible to introduce
(in different VRFs) different routes to the very same system, so that
De Clercq, et al. Expires December 2000 [Page 6]
Internet Draft draft-declercq-bgp-ipsec-vpn-00 May 2000
the route to a certain system is dependent of the VRF that handles
the packet (i.e. dependent of the origin of the packet). This can be
used to create (more) complex communication topologies.
1.7 SP Backbone Routers
The SP's backbone consists of the PE routers, as well as other
routers which are not attached to CE devices ("P routers").
The model presented in this document does not impose any VPN
knowledge on the P routers, nor does it request the use of e.g. MPLS
in the backbone network. The only requirement for the P routers is
that they are regular IP routers, and that they maintain /32
addresses for every PE participating in the BGP/IPsec VPN context.
The routing information about a particular VPN is only present in the
PE routers that attach to that VPN.
1.8 Security
The model to deploy VPNs described in this document, offers two kinds
of security measures. The first Security aspect is offered by the
IPsec Security Protocols. The IP traffic sent over the backbone(s)
is sent through IPsec tunnels, so that it can be encrypted and
authenticated. This allows for the deployment of VPNs over
untrusted, not participating backbones. This provides a PE to PE
end-to-end security service.
In addition, in the absence of misconfiguration or deliberate
interconnection of different VPNs, it is not possible for systems in
one VPN to gain access to systems in another VPN.
1.9 Using IPsec in the backbone
In the model presented in this document, the IP security protocol
[RFC2401] is used instead of MPLS to tunnel IP packets through the
backbone of the network.
Because there is no concept of "label-stacking" in IPsec, the
straightforward way of providing IPsec network-based VPNs would be to
deploy a full mesh of Security Associations between the VRFs among
the participating PEs. This would cause serious scalability problems
and is therefor not applicable for large networks.
The scalability problems arise because:
a) every VRF in a PE needs to maintain Security Associations with
every VRF from the peer PEs that are attached to the same VPN(s).
De Clercq, et al. Expires December 2000 [Page 7]
Internet Draft draft-declercq-bgp-ipsec-vpn-00 May 2000
b) the creation of a new VRF in a certain PE requires the creation of
new Security Associations via IKE-exchanges with all the
participating PEs.
The model presented in this document provides a way to deploy IPsec
network-based VPNs in a scaleable manner. There is only a full mesh
of SAs between participating PEs, not between VRFs. The selection of
the correct VRF when a packet arrives at the end of the IPsec tunnel
(the goal of the second label in the [RFC2547]-model) is based on the
Security Parameter Index. This means that a method must be provided
to link a pool of SPIs with a single Security Association instead of
the usual one-to-one relationship between a SA and a SPI.
This model resolves this by introducing the concepts of an SPI-prefix
and an SPI-label.
2.0 Sites and CEs
This document uses the same definitions and imposes the same global
behaviour on the sites and the CEs as [RFC2547bis].
From the perspective of a particular backbone network, a set of IP
systems constitutes a site if those systems have mutual IP
interconnectivity, and communication among them occurs without the
use of the backbone.
A CE device is always regarded as being in a single site (though a
site may consist of multiple "virtual sites", see later in this
section). A site may belong to multiple VPNs.
A PE router may attach to CE devices in any number of different
sites, whether those CE devices are in the same or in different VPNs.
A CE device may (for robustness for example) attach to multiple PEs,
of the same or of different SPs.
While we use the site as the basic unit of interconnection, the
architecture of [RFC2547bis] allows for a finer degree of granularity
in the control of interconnectivity. These techniques are also
applicable in this model. The customer itself may divide its site
into different "virtual sites", each belonging to a different set of
VPNs. The PE then needs to contain a separate VRF for each virtual
site. The way this can be done is explained in [RFC2547bis].
3.0 VPN Routing and Forwarding Instances
Each PE router maintains one or more "per-site-forwarding tables". As
stated before, these are known as VRFs, or "VPN Routing and
De Clercq, et al. Expires December 2000 [Page 8]
Internet Draft draft-declercq-bgp-ipsec-vpn-00 May 2000
Forwarding" instances. Every site to which the PE router is attached
is associated with one of these tables. A particular packet's
(private) IP destination address is looked up in a particular VRF
only if that packet has arrived directly from a site which is
associated with that table.
In a PE router, the following rules apply:
- sub-interfaces may be mapped to VRFs
- the mapping between sub-interfaces (sites) to VRFs is many-to-one
or one-to-one
- the VRF in which a packet's destination address is looked up is
determined by the sub-interface over which it is received
- two sub-interfaces (sites) may not be mapped to the same VRF unless
the same set of routes is meant to be available to packets received
over either sub-interface (both sub-interfaces "are in the same set
of VPNs").
The way by means of which VRFs are populated is explained further in
this document.
If a site is in multiple VPNs, the VRF associated with that site
contains the routes from the full set of VPNs of which the site is a
member.
[RFC2547bis] gives two basic methods for providing Internet access
over an interface that is associated with a VRF: the VRF may contain
a default route which leads to a firewall; or, if no entry in the VRF
matches the destination address, the packet's destination address may
be matched against the PE's Internet forwarding table.
When a PE receives a packet from a directly attached site, it always
looks up the packet's destination address in the VRF which is
associated with that site. However, when a PE receives a packet which
is destined to go to a particular directly attached site, it does not
necessarily need to look up the packet's destination address in the
appropriate VRF (although in some cases it will need to). The packet
may already be carrying enough information (in the form of a VPN-SPI,
see section 4.4) to determine the packet's outgoing sub-interface.
4.0 The VPN-SPI
4.1 Introduction
The Security Architecture for the Internet Protocol [RFC2401] defines
De Clercq, et al. Expires December 2000 [Page 9]
Internet Draft draft-declercq-bgp-ipsec-vpn-00 May 2000
a Security Association (SA) as a unidirectional "connection" that
affords security services to the traffic carried by it. It is a
relationship between two entities, represented by a set of
information that can be considered a contract between the entities. A
Security Association is identified by a triple consisting of a
Security Parameter Index (SPI), an IP Destination Address, and a
security protocol (AH or ESP). The SPI is used to differentiate
between different Security Associations to the same IP Destination
Address, using the same security protocol. The SPI is a pseudo-
random 32-bit number for which no formal format has been defined.
4.2 The VPN-SPI used in the IKE Negotiation
This document presently defines two SPI-formats and interpretations
to be used in the IKE negotiation phase: a VPN-SPI format (V-flag =
1), and a non-VPN-SPI format (V-flag = 0). The way to interpret the
SPI in IKE is dependent on the value of the first SPI bit: the V-
flag.
4.2.1 VPN-SPI format, V-flag = 1
It is assumed in this document that the peer PE that receives the
packets through an IPsec tunnel identified by a certain SPI, has
chosen this SPI associated with the considered tunnel during the
IKE-negotiation.
Provider Edge Routers that use IKE to establish IPsec tunnels between
them to be used in the BGP/IPsec VPN context, MUST interpret the
negotiated SPIs according to the format defined in this document.
This model assumes that for the inbound ("inbound" is used to denote
the process of handling packets coming out of the IPsec tunnel) IPsec
SA selection, the following identifiers are used: the Destination IP
address of the outer IP header, the Security Protocol (AH or ESP) in
the security header of the IPsec packet, the SPI, and eventually the
Source IP address of the outer IP header. Although the use of the
Source IP Address in the outer IP header during the inbound SA
selection process is not standardized, it is recommended to do so
when using this model.
In the model described by this document, every PE should define at
least one "SPI-prefix" per participating peer PE. If the source IP
address in the outer IP header of an incoming IPsec packet can not be
used to select the appropriate SA (next to the destination IP
address, the security protocol and the SPI), then these SPI-prefixes
must be different for every peer PE. But if the source IP address in
the outer IP header of an incoming IPsec packet can be used to select
the appropriate SA, then platform-wide SPI-prefixes can be assigned
De Clercq, et al. Expires December 2000 [Page 10]
Internet Draft draft-declercq-bgp-ipsec-vpn-00 May 2000
(this means the same SPI-prefix for every peer PE).
A reason to assign more than one SPI-prefix to a certain PE, could be
that two PEs could maintain multiple SAs, because some VPN traffic
needs stronger protection than other VPN traffic.
Every PE must choose a certain (platform-wide) SPI-prefix length.
Even if different SPI-prefixes are chosen by a certain PE (for its
different peer PEs for example), their length must be the same. The
length of the SPI-prefixes chosen by the other PEs may of course be
different. The length of any SPI-prefix MUST be shorter than 27 bits.
This means that every PE must do the following things (independently
of the other PEs):
- choose a fixed SPI-prefix length, shorter than 27 bits.
- if the Source IP address of the outer IP header can not be used by
the inbound IPsec process in the PE for the SA selection process:
associate at least one SPI-prefix (of the defined length) with every
peer PE. These SPI-prefixes must be unique within the context of a PE
(each one identifies a peer PE).
- if the Source IP address of the outer IP header can be used by the
inbound IPsec process in the PE: associate at least one SPI-prefix
(of the defined length) with every peer PE. These SPI-prefixes must
not be unique.
In the regular IKE specifications, the SPI is defined as a pseudo-
randomly generated number. This document imposes a formal format on
the SPI used in the IKE negotiation under the conditions applicable
in this section of the document. This allows the negotiating peers
to interpret the SPIs as belonging to a BGP/IPsec VPN-environment,
and to negotiate about SPI-pools instead of about single SPIs, so
that multiple SPIs can be associated with a single Security
Association.
The formal format for the VPN-SPI used in IKE-negotiations is the
following:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V| len | prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
V-flag:
De Clercq, et al. Expires December 2000 [Page 11]
Internet Draft draft-declercq-bgp-ipsec-vpn-00 May 2000
This flag is used to differentiate IKE-negotiations about IPsec
tunnels to be interpreted in the BGP/IPsec VPN context (V = 1) or
in another context (V = 0). In the VPN-SPI context, this flag MUST
be set to 1.
len:
This 5-bits field defines the length of the prefix included in the
prefix-field of the VPN-SPI.
prefix:
This 26-bit field contains the left-aligned SPI prefix. The length
of the SPI-prefix is defined by the len-field of the VPN-SPI. The
length of the SPI-prefix MUST be smaller than 27 bits. The other
(= 26 - length) bits must be set to 0 and should be ignored when
received.
The length of the VPN-SPI prefix may be chosen in an intelligent way:
the length of the prefix is proportional with the maximum number of
Security Associations with a peer PE in the BGP/IPsec VPN context and
- if the source IP address can not be used in the SA selection
process - with the number of PEs participating in the BGP/IPsec VPN
scenario; the length of the label (= 32 bits - length of the prefix)
is proportional with the number of VRFs to be implemented in the
considered PE.
This means for example that a PE may choose a prefix-length of 0 if
it is able to use the source IP address of the outer IP header in the
inbound SA selection process, and if it wants only one SA with every
peer PE in the BGP/IPsec VPN context (so that all the traffic
receives the same protection). In that example, the correct SA is
then selected solely based on the source IP address, the destination
IP address, the security header and the complete SPI (if the SPI does
not refer directly to a SA with the considered peer PE, but it is
assigned as a label, then the BGP/IPsec VPN SA with the peer PE must
be used). This prefix length of 0 allows for a 32-bit SPI-label space
and the deployment of a large number of VRFs in the considered PE.
4.2.2 non-VPN-SPI format, V-flag = 0
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V| pseudo-random value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The SPI format used in the IKE negotiation in the non-VPN-SPI context
De Clercq, et al. Expires December 2000 [Page 12]
Internet Draft draft-declercq-bgp-ipsec-vpn-00 May 2000
does differ from the normal SPI format (a pseudo-random 32-bit
number) on only one point: the first bit MUST be set to 0.
V-flag:
this flag is used to differentiate negotiations about IPsec
tunnels to be interpreted in the BGP/IPsec VPN context (V = 1)
from other contexts (V = 0). In the non-VPN-SPI context, this flag
MUST be set to 0.
pseudo-random value:
this 31-bit field contains a pseudo-random number.
4.2.3 Use of the VPN-SPI during the IKE negotiation
During a normal IKE negotiation, two SAs are being set-up. The SPIs
identifying these SAs are chosen by the receiving party.
Every PE participating in the BGP/IPsec VPN scenario MUST define a
VPN-SPI prefix per peer PE, with a certain length.
The receiving PE (i.e. the PE that will receive the IPsec packets)
must now form 32-bit VPN-SPIs as described in section 4.2.1 for the
BGP/IPsec VPN SA negotiation via IKE with every peer PE. To create
these VPN-SPIs, the PE sets the V-bit to 1, sets the length-field to
the correct value and inserts the correct SPI-prefix in the correct
field. A particular VPN-SPI must be used in all the IKE-exchanges
with the appropriate peer PE in the BGP/IPsec VPN context.
As a result of these IKE exchanges, every PE has at least 1 inbound
SA with every other PE for the BGP/IPsec VPN context. These SAs are
identified by:
- the destination IP address
- the security protocol (AH or ESP)
- the V-bit of the VPN-SPI
- the unique (i.e. different for every peer PE) SPI-prefix when the
Source IP Addresses are not used
- the SPI-prefix and the Source IP address when the Source address
may be used
4.3 The VPN-SPI in the IPsec processing
De Clercq, et al. Expires December 2000 [Page 13]
Internet Draft draft-declercq-bgp-ipsec-vpn-00 May 2000
4.3.1 Format and interpretation of the VPN-SPI in the IPsec processing
The SPI that will finally been inserted in the security headers of
the IPsec packets has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| prefix .. | .. label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
prefix:
This field identifies the SA to associate an IPsec packet with.
The length of this prefix-field was negotiated during the IKE-
negotiation.
label:
The length of the label field is: 32 bits - (length of the
prefix). This part of the VPN-SPI is not used to find the correct
SA during inbound processing, but it is used to identify the
correct outgoing interface or VRF after the IPsec processing in
the egress PE (see later in this document).
Note that every PE must take care not to assign SPI's for other IPsec
contexts (than the BGP/IPsec VPN context) that might be identical to
the combination of any distributed VPN-SPI prefix with any VPN-SPI
label.
4.3.2 Outbound IPsec processing
As described in [RFC2547bis], an IP packet coming from a customer
site will be handled in a dedicated VPN Routing and Forwarding
instance in the considered PE. The choice of the VRF is based on the
packet's incoming sub-interface. In that VRF, a routing lookup will
be done, based on the (private) destination address in the packet's
IP header. As a result of that lookup, the information associated
with a particular packet is: the next hop (PE) and the outgoing sub-
interface to send the packet to, and a specific SPI-label (with a
certain length) to associate with that packet (assigned to that route
by the next hop PE = BGP next hop). The mechanism by means of which
the routes in the VRFs are associated with the correct SPI-labels is
explained elsewhere in this document (section 5.0). If the outgoing
sub-interface is associated with a VRF, then the next hop is a CE
device attached to the same PE. The packet is then directly sent to
that outgoing interface (although a new lookup in a VRF is also
possible).
De Clercq, et al. Expires December 2000 [Page 14]
Internet Draft draft-declercq-bgp-ipsec-vpn-00 May 2000
If the next hop PE is another PE, then the outgoing interface is an
interface to the backbone, and the packet must be IPsec processed.
Within a PE, the VRF that handles the considered packet, together
with the 'next hop PE' found after the lookup (the 'selectors'),
uniquely identify a SA (= a certain security association for the
BGP/IPsec VPN context between this PE and the next hop-PE).
The packet will now be processed according to that SA and the packet
will be sent over the IPsec tunnel to the next hop PE, using the
appropriate VPN-SPI (constructed using the SPI-label found after the
lookup in the VRF and using the SPI-prefix associated with the
considered SA) in the SPI-field of the security header of the IPsec
packet.
4.3.3 Inbound IPsec processing
When a PE receives an IPsec packet from the core network that has
it's own IP address in the destination IP address field of the outer
IP header, the correct SA must be identified. This SA is identified
by means of: the Destination IP address (it's own IP address) in the
outer IP header, the security protocol (AH or ESP), the SPI (in fact
only the prefix-part of the SPI is enough to identify a BGP/IPsec VPN
SA), and eventually the Source IP address of the outer IP header.
Once the correct SA is identified, the packet will be handled
according to the IPsec inbound processing rules: decryption,
authentication, etc. The result of this is a regular IP packet with
-eventually- private IP addresses in the IP header.
4.4 Use of the VPN-SPI after the inbound IPsec processing
Now, instead of routing this IP packet according to the global IP
Routing table of the PE (which is not possible because of the use of
private addresses), the label-part of the VPN-SPI (that the
considered PE distributed with the VPN addresses via BGP) found in
the security header of the IPsec packet is used to direct the packet
immediately to the correct customer-side interface or to the correct
VRF for further processing in the right private address context. The
label-part of the VPN-SPI has the same role as the first label in the
BGP/MPLS VPN model [RFC2547bis].
4.5 Achievement
The introduction of the VPN-SPI does not affect the real IPsec
processing. The SPI still identifies a SA. Also the IKE-mechanism is
not changed radically: it is still two peers negotiating SAs, and
assigning SPIs to them. The only difference is that some structure in
these SPIs must be recognized. By introducing this structure to the
De Clercq, et al. Expires December 2000 [Page 15]
Internet Draft draft-declercq-bgp-ipsec-vpn-00 May 2000
SPI, and imposing the use of this structure on the participating PEs,
two goals have been achieved:
- IKE is able to negotiate about SPI-pools, so that multiple SPIs can
point to the same SA.
- the SPI (more precisely, a part of the SPI) can be used as a label
to identify the correct VPN context to process certain packets in (a
VRF), or the correct outgoing interface to send the packet to.
5.0 VPN Route Distribution via BGP
The distribution over the backbone of the (private) routes to the
different sites participating in the BGP/IPsec VPN model, uses the
same conceptual model as the BGP/MPLS VPN model [RFC2547bis]: PE
routers use BGP to distribute VPN routes to each other.
We allow each VPN to have its own address space, which means that a
given address may denote different physical systems in different VPNs
(concept of 'private addresses'). If two routes, to the same IP
address prefix, are actually routes leading to separate systems, we
must make sure that BGP treats them as two different routes.
Otherwise BGP might choose to install only one of them, making the
other system unreachable. Further, we must make sure that policy is
used to determine which packets get sent on which routes. Given that
several routes are installed by BGP, only one of them may appear in a
particular VRF.
These goals are met by the use of the VPN-IPv4 address family and by
the use of the Route Target attribute.
5.1 The VPN-IPv4 Address Family
The BGP Multiprotocol extensions [BGP-MP] allow BGP to carry routes
from multiple "address families". [RFC2547] introduces the notion of
"VPN-IPv4 address family". The model described in this document uses
the same address family (but does not use the "labeled"-version of
it). A VPN-IPv4 address is a 12-octet quantity, beginning with an 8-
octet "Route Distinguisher" (RD), and ending with a 4-octet IPv4
address. If two VPNs use the same IPv4 address prefix for a different
system, the PEs transform these into two different VPN-IPv4 address
prefixes (using two different RDs).
For the possible other uses of the RD and the structure and encoding
of the RD, we refer to [RFC2547bis].
5.2 Controlling Route Distribution
De Clercq, et al. Expires December 2000 [Page 16]
Internet Draft draft-declercq-bgp-ipsec-vpn-00 May 2000
In this section, we discuss the means by which the distribution of
the VPN-IPv4 routes is controlled.
5.2.1 The Route Target Attribute
The BGP/MPLS VPN model [RFC2547bis] introduces the concept of "Route
Target" attributes. These BGP attributes are encoded as BGP Extended
Community Route Targets [BGP-EXTCOMM].
Every VRF in a PE is associated with one or more Route Target
attributes (= the "import" Route Target attributes). Every site
attached to a PE is also associated with one or more Route Target
attributes (= the "export" Route Target attributes). These Export
Route Target attributes may be associated per route, per site or per
VRF (thus possibly associated with more than one site, as more than
one site may be served by the same VRF). The two sets of Route Target
attributes need not be identical, they are distinct.
When a PE learns a customer-route from one of his attached CEs, the
PE creates a VPN-IPv4 route to distribute with BGP. The PE then
associates one or more "Route Target" attributes with that route (the
"export" Route Targets associated with the considered site). These
Route Targets are carried in BGP as attributes of the route.
Any route associated with a certain Route Target T must be
distributed to every PE router that has at least one VRF associated
with Route Target T (an "import" Route Target of that VRF). When such
a route (carrying a Route Target attribute T) is received by a PE
router, it is eligible to be installed only in those VRFs that are
associated with an "import" Route Target T. Whether the route
actually gets installed is dependent on the outcome of the BGP
decision process.
A Route Target Attribute can be thought of as identifying a set of
sites or a set of VRFs. It is used to filter the appropriate routes
into the correct VRFs.
Several methods can be used to associate routes with Route Target
attributes: a PE can be configured to associate every route coming
from a certain site with a set of Route Targets; or to associate some
routes with one set of Route Targets and some routes with another
set; or alternatively, the control could be shifted to the CE: the CE
could specify every route it advertises to the PE with one or more
Route Targets.
5.2.2 The SPI-label Attribute
Every PE must create SPI-labels that uniquely (within its own PE
De Clercq, et al. Expires December 2000 [Page 17]
Internet Draft draft-declercq-bgp-ipsec-vpn-00 May 2000
context) identify how to handle (BGP/IPsec VPN)-packets coming from
the core after IPsec processing (i.e. with a private IPv4 address).
These labels can identify an outgoing CE (sub-)interface or a VRF for
further processing.
When PEs distribute VPN-IPv4 routes to each other in the BGP/IPsec
VPN context, they MUST associate every route with a single "SPI-label
Attribute". When a VPN-IPv4 route is inserted in certain VRFs in the
peer PEs that received the BGP message, the according SPI-label MUST
be associated with that route in the corresponding table.
When after a Routing lookup in a VRF (for a packet coming from a
customer interface) a match is found for the packet's destination IP
address, the considered VRF and the next hop PE associated with the
route uniquely indicate the appropriate SA (because they uniquely
identify a BGP/IPsec VPN context and a destination PE); the SPI-label
associated with the route in the routing table, together with the
SPI-prefix associated with the considered SA, are used to construct
the appropriate SPI (see section 4.3.2.1) to use in the security
headers of the resulting IPsec packets.
The BGP SPI-label Attribute has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|O|T|P|E| null | SPI-label type| length | length label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| label + padding bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Optional-bit (O):
This bit should be set to 0, because the SPI-label attribute is
well-known for VPN-IPv4 routes in the BGP/IPsec VPN model and MUST
be associated with every distributed BGP/IPsec VPN route.
Transitive-bit (T):
This bit should be set to 1, as the SPI-label attribute is well-
known.
Partial-bit (P):
This bit should be set to 0, as the SPI label attribute is well-
known.
Extended Length-bit (E):
De Clercq, et al. Expires December 2000 [Page 18]
Internet Draft draft-declercq-bgp-ipsec-vpn-00 May 2000
This bit should be set to 0, as the length field is only one octet
long.
null-field:
These bits are unused and must be set to zero (and ignored upon
receipt).
SPI-label type:
This field contains a one-octet number identifying the SPI-label
Attribute. This number should be assigned by IANA.
length:
This field contains the length of the Attribute data (= length
label + label + padding bits) in octets.
length label:
This 1-octet field contains the length (in bits) of the SPI-label
that is included in the label + padding bits field. This length is
dependent on the length of the SPI-prefixes that the PE has chosen
(length label = 32 - length prefix)
label + padding bits:
This 4-octet field contains the SPI-label associated with the
considered VPN-IPv4 route. The SPI-label is left-adjusted in the
label + padding bits field. The remaining bits in this field must
be set to zero and must be ignored when received.
5.2.3 Route Distribution among PEs by BGP
If two sites of a VPN attach to PEs that are in the same Autonomous
System, these PEs can distribute VPN-IPv4 routes to each other by
means of an IBGP connection between them. The way it is done for PEs
that do not belong to the same Autonomous System is explained later
in this document (section 10).
Like in the model described in [RFC2547bis], the use of route
reflectors [BGP-RR] is strongly recommended in order to scale the
number of BGP connections. The model described here allows for the
use of all the route reflector techniques to improve scalability. As
it is explained in [RFC2547bis], the set of VPN-IPv4 routes may be
partitioned among a set of route reflectors.
When a PE router distributes a VPN-IPv4 route via BGP, it uses its
De Clercq, et al. Expires December 2000 [Page 19]
Internet Draft draft-declercq-bgp-ipsec-vpn-00 May 2000
own address as the "BGP next hop". As BGP must use only one kind of
Address Family ([BGP-MP]), this address is encoded as a VPN-IPv4
address with a RD of 0. In addition, the PE assigns an appropriate
SPI-label Attribute (and a set of Route Target Attributes, see later)
to the route and distributes it. This SPI-label identifies the
destination within the PE (a certain customer-interface or a certain
VRF) of the packets coming from the backbone and following the
considered route.
When the PE processes a packet received from the core, it goes
through the following steps:
- identify the correct SA by means of the SPI, the destination
address and the security protocol.
- process the packet according to the IPsec process defined by the
SA.
- (if the SPI is a VPN-SPI) use the label-part of the VPN-SPI in the
security header of the IPsec packet (more precisely compare it to the
SPI-labels distributed via BGP in the SPI-label attribute) to direct
the packet to the correct outgoing interface or to a certain VRF for
further processing.
The use of the BGP refresh mechanism [BGP-RFSH] and the outbound
route filtering mechanism [BGP-ORF] is strongly recommended to assure
maximum scalability of the model.
In the BGP-point of view, the model described in this document has
the same advantages as the model described in [RFC2547bis]: a PE
router should not install VPN-IPv4 routes belonging to VPNs it is not
attached to; a router which is not attached to any VPN (a P router),
never installs any VPN-IPv4 routes at all. This also means that
there is no box that needs to know all the VPN-IPv4 routes that are
supported over the backbone.
5.2.4 How VPN-IPv4 NLRI is Carried by BGP
The BGP Multiprotocol Extensions [BGP-MP] are used to encode the
NLRI. In the model proposed here, the concept of labeled IPv4-routes
as it is introduced in [RFC2547bis] disappears. This requires the
assignment of a new SAFI value by IANA to identify UNlabeled VPN-IPv4
addresses. AFI 1 is used, because the network layer protocol
associated with the NLRI is still IP.
In order for two BGP peers to exchange unlabeled VPN-IPv4 NLRI, they
must use BGP Capabilities Negotiation to ensure that they are both
capable of processing such NLRI. This is done as specified in [BGP-
De Clercq, et al. Expires December 2000 [Page 20]
Internet Draft draft-declercq-bgp-ipsec-vpn-00 May 2000
MP], by using capability code 1 (multiprotocol BGP), with an AFI of 1
and a SAFI TBD.
The unlabeled VPN-IPv4 NLRI itself is encoded as specified in [BGP-
MP]: a 1-octet length field indicating the length of the prefix (96
bits for VPN-IPv4 addresses), followed by a 12-octet VPN-IPv4 prefix.
5.2.5 Building VPNs using Route Targets
By setting up the Import Route Targets and Export Route Targets
properly, one can construct different kinds of VPNs.
[RFC2547bis] gives two examples: a fully meshed closed user group
(i.e. a set of sites where each can send traffic directly to the
other, but where no communication is possible with other non-member
sites), and a hub and spoke model (i.e. a communication topology
where all the traffic between sites (the "spoke sites") must go
through a central site (the "hub site").
To form a fully meshed closed user group for example, a single Route
Target is needed. That Route Target is assigned to the VRFs
associated with the participating sites, as both the Import and the
Export Route Target.
The method for controlling the distribution of routing information
among various sets of sites are very flexible. This provides great
flexibility in constructing VPNs.
6.0 Forwarding Across the Backbone
As PE to PE IPsec tunnels are deployed across the backbone, the
forwarding in the backbone is based on regular IP forwarding, using
the destination addresses in the outer IP-headers. These outer IP
headers contain no VPN information. The addresses included in the
outer IP headers are PE global IP addresses. This means that no VPN
awareness is needed in the backbone at all, and that all the
forwarding relies on regular IP, so no non-IP tunneling mechanisms
are needed (such as MPLS). The only requirement is that PE routers
need to insert /32 address prefixes for themselves (the IPsec tunnel
endpoints) into the IGP routing tables of the backbone.
7.0 How PEs Learn Routes from CEs
The PE routers which attach to a particular VPN need to know, for
each of that VPN's sites, which addresses in that VPN are at each
site.
De Clercq, et al. Expires December 2000 [Page 21]
Internet Draft draft-declercq-bgp-ipsec-vpn-00 May 2000
If the CE device is a switch or a host, the set of addresses will
generally be configured into the PE router. If the CE is a user
dialing in, it will usually receive a temporary IP address from the
PE. In the case where the CE is a router, there are a number of
possible ways that a PE router can obtain this set of addresses.
The PE translates these private IPv4 addresses into VPN-IPv4
addresses, using a configured RD. The PE then treats these VPN-IPv4
routes as input to BGP. Routes from a site are NOT leaked into the
backbone's IGP.
We can imagine a lot of route distribution techniques from CE to PE.
However, the distinction must be made between CEs in a "transit VPN"
(= a VPN that contains a router that receives routes from another,
non-PE router that is not in the VPN) and CEs in a "stub VPN" (= a
VPN without "third party" routing exchanges).
The possible PE/CE distribution techniques are: static routing, RIP,
OSPF, EBGP, etc.
[RFC2547bis] gives a more detailed overview of the possible CE/PE
route distribution scenario's.
Once the CE-routes are learned by the PE, it distributes the
resulting VPN-IPv4 routes via BGP. These routes are associated with
the following attributes: an SPI-label attribute, one or more Route
Target attributes and eventually a Site of Origin attribute.
The Site of Origin attribute, if used, is encoded as a Route Origin
Extended Community [BGP-EXTCOMM]. The purpose of this attribute is to
uniquely identify the set of routes learned from a particular site.
This attribute is needed in some cases to ensure that a route learned
from a particular site via a particular PE/CE connection is not
distributed back to the site through a different PE/CE connection.
8.0 How CEs Learn Routes from PEs
In this section, it is assumed that the CE device is a router.
If the PE places a particular route in the VRF associated with a
certain site, then in general, the PE may distribute that route to
the CE. Of course, the PE may distribute that route to the CE only if
this is permitted by the rules of the PE/CE protocol. Note that
whatever procedure is used to distribute routes from CE to PE will
also be used to distribute routes from PE to CE.
One more restriction is added on the distribution of routes from PE
to CE: if a route's Site of Origin attribute identifies a particular
De Clercq, et al. Expires December 2000 [Page 22]
Internet Draft draft-declercq-bgp-ipsec-vpn-00 May 2000
site, that route must never be redistributed to any CE in that site.
Note also that in most cases, it will be sufficient for the PE to
simply distribute the default route to the CE.
9.0 Inter-Provider Backbones
A usual requirement for VPNs is that VPNs must be able to span across
multiple backbones. This allows sites that are connected to different
SPs to 'be in the same VPN'. This requirement introduces two main
issues:
- the PE routers participating in the VPN topology are not able to
establish IBGP connections with each other or with a common route
reflector
- the security aspect becomes an important issue
The latter issue is covered by the use of the PE-PE end to end IPsec
tunnels. For the first issue, [RFC2547bis] discusses 3 different
solutions.
The first two solutions ('VRF-to-VRF connections at the AS border
routers' and 'EBGP redistribution of labeled VPN IPv4 routes from AS
to neighboring AS') are not applicable in the model presented in this
document, because this model requires PE-PE end-to-end IPsec tunnels.
The third solution is perfectly applicable: multihop EBGP
redistribution of VPN-IPv4 routes (associated with VPN-SPI
attributes) between source and destination ASs. The participating PEs
still need to set up IPsec tunnels with each other (whether they are
in the same AS or not) via IKE. The /32 routes to all the
participating PEs must be known in all the participating ASs (PE and
P routers) to allow for normal end-to-end IP forwarding.
Now PE routers in different ASs can establish multi-hop EBGP
connections to each other, and can exchange VPN-IPv4 routes over
these connections.
To improve scalability, one can have multi-hop EBGP connections only
between a route reflector in one AS and an other route reflector in
an other AS. Care must then be taken that these route reflectors do
not change the BGP next hop attribute of the routes).
10.0 Use of an MPLS backbone
The model presented in this document does not in any way preclude the
existence of an MPLS core network. An MPLS network can carry IPsec
De Clercq, et al. Expires December 2000 [Page 23]
Internet Draft draft-declercq-bgp-ipsec-vpn-00 May 2000
packets as easily as it can carry IP packets. This means that if an
MPLS network is present in the backbone of the ISP network, all the
extra functionalities that MPLS offers (Traffic Engineering, QoS,
etc.) can still be used in the core of this BGP/IPsec VPN
architecture.
11.0 Security
The model described in this document offers a higher level of
security than [RFC2547bis]. The IPsec security mechanisms protect the
IP packets when traversing the backbone(s). This is an ingress PE to
egress PE end-to-end IPsec protection. Especially in the case when
non-participating ('transit') SPs are traversed, this is an important
requirement.
In addition, by introducing the VPN-SPI concept and formats, this
architecture in itself provides a security level that is virtually
identical to a 'layer-2' mechanism in the scope of an individual PE:
the PE can decide to accept or reject an IP packet based on the SPI
included in the security header of the IPsec packet, and the
directing of the packets within the PE relies on the label-part of
the VPN-SPI. If no misconfiguration occurs, the traffic from one VPN
is perfectly shielded from the traffic in another VPN within the same
PE.
12.0 Scalability
The model proposed in this document uses IPsec (tunnel mode) to
tunnel the (private address) IPv4 packets through the shared
backbone(s). As the model requires only one IPsec tunnel between
every two PEs (and not a full mesh between sites or between VRFs),
the solution remains scalable for large topologies.
All the scalability considerations that apply for [RFC2547bis] also
apply for the model described in this document.
P routers (which are neither PE routers nor Route Reflectors) do not
maintain any VPN routes. They only need to maintain global IP routes
to all the participating PEs.
PE routers maintain VPN routes only for the VPNs they are attached
to.
Route Reflectors can be partitioned among VPNs so that each partition
carries only routes for a subset of the VPNs supported by the Service
Provider.
These remarks apply also for the inter-provider VPNs, if multi-hop
De Clercq, et al. Expires December 2000 [Page 24]
Internet Draft draft-declercq-bgp-ipsec-vpn-00 May 2000
EBGP is used.
As a result, no single component within the SP network has to
maintain all the routes for all the VPNs. This means that the support
of an increasing number of VPNs is not limited by the capacity of an
individual component.
13.0 References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997
[RFC2547] Rosen, E. and Rekhter, Y., "BGP/MPLS VPN", RFC 2547, March
1999.
[RFC2547bis] Rosen E., Rekhter Y., et al., "BGP/MPLS VPN", Work in
Progress.
[RFC2401] Kent, S. and Atkinson R., "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[BGP-RR] Bates, T. and Chandrasekaran, R., "BGP Route Reflection: An
alternative to full mesh IBGP", RFC 1966, June 1996.
[BGP-EXTCOMM] Ramachandra, S. and Tappan, D., "BGP Extended
Communities Attribute", Work in Progress.
[BGP-MP] Bates, T., et al., "Multiprotocol Extensions for BGP4", RFC
2283, February 1998.
[BGP-RFSH] Chen, E., "Route Refresh Capability for BGP4", Work in
Progress.
[BGP-ORF] Chen, E. and Rekhter, Y., "Cooperative Route Filtering
Capability for BGP-4", Work in Progress.
14.0 Acknowledgements
The model presented in this document is based on a lot of ideas
presented in [RFC2547bis]. We would like therefor to thank all the
authors of "BGP/MPLS VPN" for their work that has been the basis for
the ideas presented in this document.
15.0 Authors' Addresses
Jeremy De Clercq
Alcatel
De Clercq, et al. Expires December 2000 [Page 25]
Internet Draft draft-declercq-bgp-ipsec-vpn-00 May 2000
Francis Wellesplein 1
2018 Antwerpen, Belgium
Phone: +32 3 240 4752
Email: jeremy.de_clercq@alcatel.be
Peter De Schrijver
Alcatel
Francis Wellesplein 1
2018 Antwerpen, Belgium
Phone : +32 3 240 8569
Email : peter.de_schrijver@alcatel.be
Yves T'joens
Alcatel
Francis Wellesplein 1
2018 Antwerpen, Belgium
Phone : +32 3 240 7890
Email : yves.tjoens@alcatel.be
De Clercq, et al. Expires December 2000 [Page 26]