Network Working Group Eric C. Rosen
Internet Draft Cisco Systems, Inc.
Expiration Date: September 2004
Jeremy De Clercq
Olivier Paridaens
Yves T'Joens
Alcatel
Chandru Sargor
Cosine Communications
March 2004
Use of PE-PE IPsec in RFC2547 VPNs
draft-ietf-l3vpn-ipsec-2547-02.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
In BGP/MPLS IP Virtual Private Networks (VPNs), VPN data packets
traveling from one Provider Edge (PE) router to another generally
carry two MPLS labels, an inner label that corresponds to a VPN-
specific route, and an outer label that corresponds to a Label
Switched Path (LSP) between the PE routers. In some circumstances,
Rosen, et al. [Page 1]
Internet Draft draft-ietf-l3vpn-ipsec-2547-02.txt March 2004
it is desirable to support the same type of VPN architecture, but
using an IPsec Security Association in place of that LSP. The outer
MPLS label would thus be replaced by an IP/IPsec header. This
enables the VPN packets to be carried securely over non-MPLS
networks, using standard IPsec authentication and/or encryption
functions to protect them. This draft specifies the procedures which
are specific to support of BGP/MPLS IP VPNs using the IPsec
encapsulation.
Table of Contents
1 Introduction ........................................... 3
1.1 Issue: MPLS Infrastructure Required .................... 4
1.2 Issue: Protection Against Misbehavior by Transit Nodes . 5
1.3 Issue: Limitations on Multi-Provider Misconfigurations . 5
1.4 Issue: Privacy for VPN Data ............................ 6
1.5 Non-Issue: General Protection against Misconfiguration . 7
1.6 Conclusion ............................................. 7
2 Specification .......................................... 7
2.1 Technical Approach ..................................... 7
2.2 Selecting the Security Policy .......................... 8
2.3 BGP Label, Route, and Policy Distribution .............. 9
2.4 MPLS-in-IP/GRE Encapsulation by Ingress PE ............. 10
2.5 MPLS-in-IP vs. MPLS-in-GRE ............................. 11
2.6 PE-PE IPsec (Application of IPsec by Ingress PE) ....... 11
2.7 Application of IPsec by Egress PE ...................... 13
3 Comparison with Using Part of SPI Field as a Label ..... 14
4 Authors' Addresses ..................................... 15
5 Normative References ................................... 16
6 Informative References ................................. 16
7 Intellectual Property Statement ........................ 17
8 Full Copyright Statement ............................... 17
Rosen, et al. [Page 2]
Internet Draft draft-ietf-l3vpn-ipsec-2547-02.txt March 2004
1. Introduction
The present document uses terminology from [RFC2547bis], and
presupposes familiarity with that document and its terminology.
In BGP/MPLS IP VPNs, when an ingress PE router receives a packet from
a CE router, it looks up the packet's destination IP address in a
VRF. As a result of this lookup, it learns the output interface on
which the packet must be sent, and it also learns the set of headers
which must be prepended to the packet before it is sent on that
interface. In "conventional" BGP/MPLS IP VPNs, this set of headers
consists of a data link layer header, possibly followed by an MPLS
label stack. If the packet is going out an interface to a CE router
(i.e. the ingress PE is the same as the egress PE), no MPLS label
stack is needed. If the packet's egress PE router is directly
adjacent to the ingress PE, the MPLS label stack will have one or
more entries. In other cases, the MPLS label stack has two or more
entries.
The bottom label on the MPLS label stack is always a label which will
not be seen until the packet reaches its point of egress from the
network. This label represents a particular route within the packet's
VPN, and we will call it the "VPN route label". Directly above the
VPN route label is a label which represents a route across the
backbone to the egress PE router. We will call this label the
"backbone route label".
The backbone route label may or may not be the packet's top label;
additional entries may also be pushed on the label stack, if
additional MPLS services (e.g., traffic engineering) are used to
carry traffic to the egress PE. These additional labels may be
pushed on by the ingress PE, or by a P router somewhere along the
path. The VPN route label is always the packet's bottom label,
however.
This document specifies procedures for replacing the backbone route
label with an IPsec encapsulation. In effect, this creates an MPLS-
in-IPsec encapsulation, in which the VPN route label is carried
across the network within an IPsec encapsulation. By "within an
IPsec encapsulation", we mean "in a packet containing an IP header
and an IPsec header". This IPsec encapsulation corresponds to an
IPsec Security Association (SA) whose two endpoints are the ingress
PE router and the egress PE router. The payload of the IPsec
encapsulation is an authenticated and/or encrypted MPLS packet, whose
label stack contains a single entry, viz., the VPN route label. The
payload of this MPLS packet is the user data packet being sent within
the VPN.
Rosen, et al. [Page 3]
Internet Draft draft-ietf-l3vpn-ipsec-2547-02.txt March 2004
The IP/IPsec encapsulation will be used even if the ingress PE and
the egress PE are directly adjacent, i.e., even in the case where a
backbone route label would not be used. However, no IP/IPsec
encapsulation is applied if the ingress PE is the same device as the
egress PE.
If additional MPLS services, such as traffic engineering, are used in
the backbone network, an MPLS label stack will appear above the IP
header. This is orthogonal to any issues discussed in the present
document. This results in an MPLS packet containing an IP packet
containing an IPsec packet containing an MPLS packet; the latter MPLS
packet has a single label, the VPN route label.
This document is inspired by [VPN-SPI], and originated as an attempt
to improve upon it.
The remainder of section 1 outlines a number of issues which can be
addressed by the use of IPsec in this manner.
1.1. Issue: MPLS Infrastructure Required
"Conventional" BGP/MPLS IP VPNs require that there be an MPLS Label
Switched Path (LSP) between a packet's ingress PE router and its
egress PE router. This means that an RFC2547 VPN cannot be
implemented if there is a part of the path between the ingress and
egress PE routers which does not support MPLS.
In order to enable BGP/MPLS IP VPNs to be deployed even when there
are non-MPLS routers along the path between the ingress and egress PE
routers, it is desirable to have an alternative which allows the
backbone route label to be replaced with an IP header. This
encapsulating IP header would encapsulate an MPLS packet containing
only the VPN route label. The encapsulation header would have the
address of the egress PE in its destination IP address field; this
would cause the packet to be delivered to the egress PE.
It is possible to replace the backbone route label with an IP header,
possibly followed by a GRE header [MPLS-in-IP/GRE]. However, it then
becomes quite difficult, in general, to protect the VPNs against
spoofed packets. A Service Provider (SP) can protect against spoofed
MPLS packets by the simple expedient of not accepting MPLS packets
from outside its own boundaries (or more generally by keeping track
of which labels are validly received over which interfaces, and
discarding packets which arrive with labels that are not valid for
their incoming interfaces). Protection against spoofed IP packets
requires having all the boundary routers perform filtering; either
Rosen, et al. [Page 4]
Internet Draft draft-ietf-l3vpn-ipsec-2547-02.txt March 2004
(a) filtering out packets from "outside" which are addressed to PE
routers, or (b) filtering out packets from "outside" which have
source addresses that belong "inside", and having PE routers refuse
to accept packets addressed to them but with "outside" source
addresses. The maintenance of these filter lists can be management-
intensive, and the their use at all border routers can affect the
performance seen by all traffic entering the SP's network. Further,
these filtering techniques may be difficult to apply in the case of
multi-provider VPNs, because in multi-provider VPNs, packets from
outside an SP's network can legitimately be addressed to its PE
routers.
If, on the other hand, the backbone route label is replaced by an
IPsec encapsulation, protection against spoofed packets does not rely
on filtering at the border. The cryptographic authentication
features of IPsec enable an egress PE to detect and discard packets
for a particular VPN that were not generated by a valid ingress PE
for that VPN. Thus spoofing protection is managed entirely at the
ingress and egress PE routers, transparently to the border routers.
IPsec does have its own management and performance implications, of
course.
1.2. Issue: Protection Against Misbehavior by Transit Nodes
Cryptographic authentication applied by the ingress PE on a PE-to-PE
basis can protect against the misrouting or modification (intentional
or accidental) of packets by the transit nodes. Packets which get
forwarded to the "wrong" egress PE will not pass authentication, nor
will packets which have been modified. As the VPN route label is
part of the IPsec packet payload, the egress PE will know that the
VPN route label was placed in the packet by a valid ingress PE.
1.3. Issue: Limitations on Multi-Provider Misconfigurations
Sometimes a VPN will have some sites which connect to one SP (SP1),
and some other sites which connect to another SP (SP2).
Consider a case in which VPN V1 has sites attaching to SP1 and SP2,
but VPN V2 has all of its sites attaching only to SP2.
SP2 would like to ensure that nothing done by SP1 can cause V1 to get
illegitimately cross-connected to V2. Since V2 has no sites in SP1,
it should be immune to the effects of any misconfigurations within
SP1.
This assurance can be achieved if the egress PE (in SP2) can
Rosen, et al. [Page 5]
Internet Draft draft-ietf-l3vpn-ipsec-2547-02.txt March 2004
determine, for each VPN packet, whether that packet came from SP1,
and if so, whether it carries an MPLS label which corresponds to a
VPN route that was actually distributed to SP1. (That is, packets
originating from SP1 destined for VPNs in SP2 would be checked if
they are for VPNs which really have sites in SP1.) SP2's egress PEs
could be configured with the knowledge of which VPNs have sites
attached to SP1. Cryptographic authentication could then be used to
determine that a particular packet did indeed originate in SP1.
In general, if an egress PE knows which labels may be validly applied
by which ingress PEs, IPsec authentication can be used to ensure that
a given ingress PE has not applied a label that it has no right to
use. However, the scalability of the VPN scheme would be severely
compromised if an egress PE had to distribute a different set of
labels to each ingress PE. Therefore we will not pursue this general
case, but will only pursue label authentication in the inter-provider
case.
1.4. Issue: Privacy for VPN Data
IPsec Security Associations that associate ingress PE routes with
egress PE routers do not ensure privacy for VPN data. The data is
exposed on the PE-CE access links, and is exposed in the PE routers
themselves. Complete privacy requires that the encryption/decryption
be performed within the enterprise, not by the SP. So the use of
PE-PE IPsec encryption within the network of a single SP will perhaps
be of less import than the use of IPsec authentication. On the other
hand, if an SP is trusted to properly secure its routers, but the
transmission media used by the SP are not trusted, then PE-PE
encryption does provide a valuable measure of privacy.
There may be a need for encryption if a VPN has sites attached to
different trusted SPs, but some of the transit traffic needs to go
through the "public Internet". In this case, it may be necessary to
encrypt the VPN data traffic as it crosses the public Internet.
However, while PE-PE encryption is the one way to handle this, it is
not the only way. An alternative would be to use an encrypted tunnel
to connecting a border router of one trusted SP to a border router of
another. Then the two trusted domains could be treated as immediate
neighbors, adjacent over the tunnel. This would keep the
encryption/decryption at the few locations where it is actually
needed. On the other hand, there may be performance and scalability
advantages to spreading the cost of the cryptography among a larger
set of routers, viz., the ingress and egress PEs.
The scenario of having VPN traffic go from a trusted domain through
an untrusted domain to another trusted domain may not be completely
Rosen, et al. [Page 6]
Internet Draft draft-ietf-l3vpn-ipsec-2547-02.txt March 2004
realistic, though, due to the difficulty of supporting the necessary
Service Level Agreements through the public Internet.
1.5. Non-Issue: General Protection against Misconfiguration
In general, the integrity of an RFC2547 VPN depends upon the SP
having properly configured the PE routers. There is no way of
preventing an SP from creating a bogus VPN that contains sites which
aren't supposed to communicate with each other. It is the SP's
responsibility to get this right.
It is sometimes thought one can obtain protection against
misconfigurations by having the PE routers apply cryptographic
authentication to the VPN packets. This is not the case. If an
ingress PE router has been misconfigured so as to assign a particular
site to the wrong VPN, likely as not the PE has been misconfigured to
apply that VPN's authenticator to packets to/from that site.
Protection against misconfiguration on the part of the SP requires
that the authentication procedure be applied before the ingress PE
router sees the packets, and after the egress PE router forwards
them, and cannot be dealt with by PE-PE IPsec.
1.6. Conclusion
Taken together, the above set of issues suggest that there are
situations in which using PE-PE IPsec as the tunneling protocol for
BGP/MPLS IP VPNs does have value. In the next section, we specify
the necessary procedures for incorporating PE-PE IPsec as a tunneling
option for BGP/MPLS IP VPNs.
2. Specification
2.1. Technical Approach
In short, the technical approach specified here is:
1. Use the standard technique [RFC2547bis] of using an MPLS label
to represent a VPN route, by prepending an MPLS label stack to
the VPN packets. However, the label stack will contain only one
label, the VPN route label.
Rosen, et al. [Page 7]
Internet Draft draft-ietf-l3vpn-ipsec-2547-02.txt March 2004
2. Use an MPLS-in-IP or MPLS-in-GRE encapsulation to turn the
above MPLS packet back into an IP packet. This in effect
creates an "IP tunnel" or a "GRE tunnel" between the ingress PE
router and the egress PE router.
3. Use IPsec Transport Mode to secure the above-mentioned IP
tunnels.
The net effect is that an MPLS packet gets sent through an IPsec-
secured IP or GRE tunnel.
The following sub-sections specify this procedure in greater detail.
2.2. Selecting the Security Policy
One might think that a given SP (or set of cooperating SPs) will
decide either that they need to use IPsec for ALL PE-PE tunnels, or
else that PE-PE IPsec is not needed at all. But this simple "all or
nothing" strategy does not really capture the set of considerations
discussed in the Introduction. For example, a very reasonable policy
might be to use IPsec only for inter-provider PE-PE tunnels, while
using MPLS for intra-provider PE-PE tunnels. Or one might decide to
use IPsec only for certain inter-provider tunnels. Or one might
decide to use IPsec for certain intra-provider tunnels.
In an RFC2547 VPN environment, it makes most sense to place control
of the policies with the egress PE router. It is the egress PE which
needs to know that it wants to process certain packets ONLY if they
come through encrypted tunnels, and that it wants to discard those
same packets if they don't come through encrypted tunnels. Thus one
needs to be able to configure a policy into the egress PE, and have
it signal that policy to the ingress PE. RFC2547 already provides an
egress-to-ingress signaling capability via BGP, and we specify below
how to extend this to the signalling of security policy.
Of course, there is nothing to stop an ingress PE router from being
configured to use IPsec even if the egress PE has not signalled its
desire for IPsec. This should work, as long as the necessary IPsec
infrastructure is in place. (However, in this sort of application
the ingress PE and the egress PE are NOT really independent entities
which might conceivably have different security policies.)
Rosen, et al. [Page 8]
Internet Draft draft-ietf-l3vpn-ipsec-2547-02.txt March 2004
2.3. BGP Label, Route, and Policy Distribution
Distribution of labeled VPN-IP routes by BGP is done exactly as
specified in [RFC2547bis], except that some additional BGP attributes
are needed for each distributed VPN-IP route.
A given egress PE will be configurable to indicate whether it expects
to receive all, some, or none of its VPN traffic through an IPsec-
secured IP or GRE tunnel. In general, an ingress PE will not have to
know in advance whether any of the egress PEs for its VPNs require
their VPN traffic to be sent through an IPsec-secured IP tunnel; this
will be signaled from the egress PE. If an egress PE wants to receive
traffic for a particular VPN-IP route through an IPsec-secured IP
tunnel, it adds a new BGP Extended Community attribute to the route.
This attribute will then get distributed along with the route to the
ingress PEs.
We call this attribute the "IPsec Extended Community". (It is
possible that this will actually be encoded as a particular value or
set of values of a more general "Tunnel Type Extended Community"; for
the purposes of this draft, however, we will continue to refer to it
as the "IPsec Extended Community".)
It is conceivable that an egress PE in a particular SP's network will
only want to receive IPsec-secured IP-tunneled traffic for those VPNs
which have sites that are attached to other SPs. In this case, one
would want to be able to configure, on a per-VRF basis, whether
routes exported from that VRF should have an IPsec Extended Community
attribute or not.
A more complex situation would arise if it were only desired to
receive IPsec-secured IP-tunneled traffic for a particular VPN if
that traffic has originated from a site which is attached to a
different SP's network. That is, one might want to receive inter-
provider traffic through an IPsec-secured IP tunnel, but to receive
intra-provider traffic through an unsecured MPLS LSP. As long as an
SP has a policy of never accepting MPLS packets from other SPs, this
may provide the necessary security while minimizing the amount of
cryptography that actually has to be used.
One way to do this would be to map each exportable IP address prefix
into two different VPN-IP prefixes, using two different RDs (say RD1
and RD2). Then two different RTs (say RT1 and RT2) would be used,
one of which causes intra-provider distribution, and one of which
causes inter-provider distribution. The prefixes with RD1 would be
given RT1 as a route target; the prefixes with RD2 would be given RT2
as a route target. If RT2 is the route target that causes inter-
provider distribution, then only the routes with RT2 would carry the
Rosen, et al. [Page 9]
Internet Draft draft-ietf-l3vpn-ipsec-2547-02.txt March 2004
IPsec Extended Community.
A simpler approach, perhaps, would be to use only a single set of
VPN-IP prefixes, but to have a value of the IPsec Extended Community
which encodes an SP identifier, and which means "only use IPsec if
the ingress PE is in a different SP network than the one which is
identified here". (Again, the assumption is that MPLS packets are not
accepted from other SPs.)
It is conceivable that an egress PE will want some of its IPsec-
secured IP-tunneled VPN traffic to be encrypted, but will want some
to be authenticated and not encrypted. It is even conceivable that it
will want some traffic to arrive through an IPsec tunnel without
being either encrypted or authenticated. The IPsec Extended Community
attribute should have a value which specifies which of these are
required.
It may be desirable to allow the IPsec Extended Community to specify
a set of policies, so that the ingress PE can choose from among them.
2.4. MPLS-in-IP/GRE Encapsulation by Ingress PE
When a PE receives a packet from a CE, it looks up the packet's IP
destination address in the VRF corresponding to that CE. This enables
it to find a VPN-IP route. The VPN-IP route will have an associated
MPLS label and an associated BGP Next Hop. The label is pushed on the
packet. Then, if (and only if) the VPN-IP route has an IPsec Extended
Community attribute, an IP or GRE encapsulation header is prepended
to the packet, creating an MPLS-in-IP or MPLS-in-GRE encapsulated
packet. The IP source address field of the encapsulation header will
be an address of the ingress PE itself. The IP destination address
field of the encapsulation header will contain the value of the
associated BGP Next Hop attribute; this will be an IP address of the
egress PE.
(This description is not meant to specify an implementation strategy;
any implementation procedure which produces the same result is
acceptable.)
N.B.: If the ingress PE and the egress PE are not in the same
autonomous system, this requires that there be an EBGP connection
between a router in one autonomous system and a router in another. If
the two autonomous systems are not adjacent, this will need to be a
multi-hop EBGP connection.
The effect is to dynamically create an IP tunnel between the ingress
and egress PE routers. No apriori configuration of the remote tunnel
Rosen, et al. [Page 10]
Internet Draft draft-ietf-l3vpn-ipsec-2547-02.txt March 2004
endpoints is needed. Note that these IP tunnels are NOT IGP-visible
links, and routing adjacencies are NOT supported across these tunnel.
Note also that the set of remote tunnel endpoints is NOT known in
advance, but is learned dynamically via the BGP distribution of VPN-
IP routes.
These IP tunneled packets will then be associated with an IPsec
Security Association (SA), and transported using IPsec transport
mode. This is described in more detail in the next sub-section.
2.5. MPLS-in-IP vs. MPLS-in-GRE
The MPLS-in-IP encapsulation header is shorter than the MPLS-in-GRE
encapsulation header, and, in theory at least, the latter offers no
advantages to compensate for its use of a longer header.
In practice, implementation considerations of various sorts may make
the MPLS-in-GRE encapsulation preferable.
2.6. PE-PE IPsec (Application of IPsec by Ingress PE)
A given ingress PE needs to have an IPsec SA with each PE router that
is an egress PE for traffic which the ingress PE receives from a CE.
In general, the set of egress PEs for a given ingress PE is not known
in advance. This is determined dynamically by the BGP distribution of
VPN-IP routes. This suggests that it will be very important to be
able to set up IPsec SAs dynamically, and that static keying will not
be a viable option. There will need to be a key distribution
infrastructure that supports multiple SPs, and IKE will need to be
used.
A number of different VPNs might need to have traffic carried from a
particular ingress PE to a particular egress PE. It is thus natural
to ask whether there should be one SA between the pair of PEs, or n
SAs between the pair of PEs, where n is the number of VPNs. Clearly,
scalability is improved by having only a single SA for each pair of
PEs. So the question is whether there is a significant security
advantage to having a distinct SA for each VPN. There does not appear
to be any such advantage. Since the SA is PE-to-PE, NOT CE-to-CE,
having a different SA for each VPN does not provide any additional
security.
It is conceivable that there might need to be two (or more) SAs
between a pair of PEs, e.g., one in which data encryption is used and
one in which authentication but not encryption is used. But this is
Rosen, et al. [Page 11]
Internet Draft draft-ietf-l3vpn-ipsec-2547-02.txt March 2004
not the same as having a separate SA for each VPN.
We assume that the PE router will contain an IPsec module (either a
hardware or a software module) which is responsible for doing the key
exchange, for setting up the IPsec SAs as needed, and for doing the
cryptography.
As discussed in section 2.2, the PE router creates an MPLS-in-IP or
MPLS-in-GRE encapsulated packet. It does not simply send that packet
to its next hop, rather, it delivers the packet, along with the
corresponding IPsec Extended Community value, to the IPsec module.
(As an implementation consideration, it is not really required to
deliver an MPLS-in-IP or MPLS-in-GRE encapsulated packet to the IPsec
module; all that really needs to be delivered is the MPLS packet and
the information, or a pointer thereto, that would be needed to create
the IP encapsulation header.)
The IPsec module will set up an IPsec SA to the packet's destination
address, if one does not already exist. It will then apply the
appropriate IPsec procedures, generating a packet with an IP header
followed by an IPsec header followed by an MPLS label stack followed
by the original data packet. The IPsec module then delivers this
packet, as if it were a brand new packet, to the routing module. The
routing module forwards it as an IP packet.
While the IPsec SA is being set up, packets cannot be delivered
through it. Packets may be dropped during this time, though a
sensible policy might be to queue the first packet and drop the rest
(as is commonly done in ARP implementations while awaiting an ARP
resolution).
We do assume here that the IPsec module is subsidiary to the PE
router, and does not function itself as an independent router in the
network. A solution could be designed to support the latter case, but
at a considerable increment in complexity.
The procedure as specified above requires two routing lookups. Before
IPsec processing, The original packet's destination address is looked
up in a VRF. After IPsec processing, the IPsec packet's destination
address is looked up in the default routing table. It is worth
noting that the information obtained from the second lookup is really
available at the time of the first lookup. In some routers, it might
be advantageous to forward this information, along with the packet,
to the IPsec module; possibly this can be used to avoid the need for
the second lookup. However, in some routers, it will be impossible to
avoid the second lookup.
Rosen, et al. [Page 12]
Internet Draft draft-ietf-l3vpn-ipsec-2547-02.txt March 2004
2.7. Application of IPsec by Egress PE
We assume that every egress PE is also an ingress PE, and hence has
the IPsec module which is mentioned in section 2.2. This module will
handle the necessary IKE functions, SA and tunnel maintenance, etc.,
etc, as well as handling arriving IPsec packets. The IPsec module
will apply the necessary IPsec procedures to arriving IPsec packets,
and will hence recover the contained MPLS-in-IP or MPLS-in-GRE
packets. The IPsec module should then strip off the encapsulating IP
header to recover the MPLS packet, and should then deliver the
resulting MPLS packet to the routing function for ordinary MPLS
switching. (Of course, as an implementation matter, there is probably
no need to put the encapsulating IP header on only to then take it
off immediately.)
There are subtle issues having to do with the proper handling of MPLS
packets (rather than IPsec packets) which the PE router receives from
P routers or from other PE routers. If the top label on a received
MPLS packet corresponds to an IP route in the "default" routing
table, "ordinary" MPLS switching is done. But if the top label on a
received MPLS packet corresponds to a VPN-IP route, there are a
number of different cases to consider:
a. The packet has just been removed from an IPsec SA by the IPsec
module. In this case, ordinary MPLS switching should be done.
(though see below for further qualifications.)
b. The packet arrived from a neighboring P or PE router as an MPLS
packet, with no IPsec encapsulation. There are a number of
sub-cases:
i. The packet's top label corresponds to a VPN-IP route
which was not exported with the IPsec Extended
Community attribute. In this case, ordinary MPLS
switching is applied.
ii. The packet's top label corresponds to a VPN-IP route
which was exported with the value of the IPsec Extended
Community attribute which indicates that IPsec is to be
used only when the ingress PE is in a different SP
network. In this case, we assume that MPLS packets are
not being accepted from other networks, so ordinary
MPLS switching is applied.
iii. The packet's top label corresponds to a VPN-IP route
which was exported with an IPsec Extended Community,
but case ii does not apply. In this case the packet
should be discarded; packets with this label are
Rosen, et al. [Page 13]
Internet Draft draft-ietf-l3vpn-ipsec-2547-02.txt March 2004
supposed to be secured, but this packet was not
properly secured.
Providing this functionality requires the use of two separate label
lookup tables, one of which is used for packets that have been
removed from IPsec SAs, and one of which is used for other packets.
Labels which are only valid when they are carried within an IPsec
packet would only appear in the former lookup table. This does imply
that after a packet has been processed by the IPsec module, the
contained MPLS packet is not simply returned to the routing lookup
path; rather it must carry some indication of which label lookup
table must be used to switch that packet. This also presupposes that
there will be MPLS VPN code to properly populate the two different
lookup tables. Perhaps packets removed from IPsec SAs should appear,
to the routing module, to be arriving on a particular virtual
interface, rather than on the actual sub-interface over which they
really arrived. Then interface-specific label lookup tables could be
used.
In fact, it may be advantageous to have more than one label lookup
table that is used for packets that have been removed from IPsec SAs.
Certain VPN-IP routes will be exported to certain SPs, but not to
others. Security can thus be improved by having one label lookup
table for each such SP. The IPsec module would then have to say, for
each packet, which SP it came from. Given a proper certificate
authority infrastructure this can be inferred by the IPsec module
from the information which the IKE procedure makes available to it.
Of course, all this presupposes that the VPN code is capable of
properly populating the various lookup tables.
3. Comparison with Using Part of SPI Field as a Label
An alternative methodology that achieves similar results is the one
described in [VPN-SPI]. The proposal described above was in fact
inspired by that draft, and arose as a proposed improvement to it.
In the current proposal, IPsec transport mode is applied to an MPLS-
in-IP encapsulation, where the MPLS-in-IP encapsulation carries the
BGP-distributed labels of RFC 2547. In [VPN-SPI], there is no MPLS-
in-IP encapsulation. Rather:
- IPsec tunnel mode is applied to the enduser's packet directly.
- A subfield of the IPsec SPI field is used to provide the function
of the BGP-distributed MPLS label. This either requires that BGP
distribute a different kind of label (one that can fit into the
SPI sub-field), or that an MPLS label be carried within the SPI
Rosen, et al. [Page 14]
Internet Draft draft-ietf-l3vpn-ipsec-2547-02.txt March 2004
field.
The [VPN-SPI] proposal does have the advantage of making each packet
4 bytes shorter, since an entire entry in the MPLS label stack is
eliminated (replaced by the SPI sub-field).
The current proposal, unlike that in [VPN-SPI], does not in any way
alter the use or interpretation of the SPI field, and does not impact
the IPsec or IKE protocols and procedures in any way. The current
proposal also better preserves the distinction between fields that
are meaningful to IPsec and fields that are meaningful to
routing/forwarding. Failure to preserve this layering could
potentially lead to complications in the future (e.g., if BGP ever
needed to distribute a stack of two MPLS labels, or if some
enhancement to IPsec ever needed to reclaim the SPI sub-field used to
carry the label, etc., etc.). Failure to preserve the layering also
complicates the situation in which the transport is sometimes IPsec
and sometimes MPLS. Keeping the MPLS VPN functionality in the MPLS
layer and out of the IPsec layer certainly seems worthwhile.
4. Authors' Addresses
Eric C. Rosen
Cisco Systems, Inc.
1414 Massachusetts Avenue
Boxborough, MA 01719
Email: erosen@cisco.com
Jeremy De Clercq
Alcatel
Francis Wellesplein 1
2018 Antwerpen, Belgium
Phone: +32 3 240 4752
Email: jeremy.de_clercq@alcatel.be
Rosen, et al. [Page 15]
Internet Draft draft-ietf-l3vpn-ipsec-2547-02.txt March 2004
Olivier Paridaens
Alcatel
Francis Wellesplein 1
2018 Antwerpen, Belgium
Phone: +32 3 240 9320
Email: olivier.paridaens@alcatel.be
Yves T'Joens
Alcatel
Francis Wellesplein 1
2018 Antwerpen, Belgium
Phone: +32 3 240 7890
Email: yves.tjoens@alcatel.be
Chandru Sargor
CoSine Communications
1200 Bridge Parkway
Redwood City, CA 94065
Email: csargor@cosinecom.com
5. Normative References
[RFC2547bis] BGP/MPLS IP VPNs, Rosen et. al., draft-ietf-l3vpn-
rfc2547bis-01.txt, September 2003
6. Informative References
[MPLS-in-IP/GRE] "Encapsulating MPLS in IP or GRE",, Worster et. al.,
draft-ietf-mpls-in-ip-or-gre-05.txt, February 2004
[VPN-SPI] BGP/IPsec VPN, De Clercq et. al., draft-declercq-bgp-
ipsec-vpn-01.txt, February 2001
Rosen, et al. [Page 16]
Internet Draft draft-ietf-l3vpn-ipsec-2547-02.txt March 2004
7. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
8. Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78 and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Rosen, et al. [Page 17]
Rebecca F. Bunch
Network Working Group Eric C. Rosen
Internet Draft Cisco Systems, Inc.
Expiration Date: September 2004
Jeremy De Clercq
Olivier Paridaens
Yves T'Joens
Alcatel
Chandru Sargor
Cosine Communications
March 2004
Use of PE-PE IPsec in RFC2547 VPNs
draft-ietf-l3vpn-ipsec-2547-02.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
In BGP/MPLS IP Virtual Private Networks (VPNs), VPN data packets
traveling from one Provider Edge (PE) router to another generally
carry two MPLS labels, an inner label that corresponds to a VPN-
specific route, and an outer label that corresponds to a Label
Switched Path (LSP) between the PE routers. In some circumstances,
Rosen, et al. [Page 1]
Internet Draft draft-ietf-l3vpn-ipsec-2547-02.txt March 2004
it is desirable to support the same type of VPN architecture, but
using an IPsec Security Association in place of that LSP. The outer
MPLS label would thus be replaced by an IP/IPsec header. This
enables the VPN packets to be carried securely over non-MPLS
networks, using standard IPsec authentication and/or encryption
functions to protect them. This draft specifies the procedures which
are specific to support of BGP/MPLS IP VPNs using the IPsec
encapsulation.
Table of Contents
1 Introduction ........................................... 3
1.1 Issue: MPLS Infrastructure Required .................... 4
1.2 Issue: Protection Against Misbehavior by Transit Nodes . 5
1.3 Issue: Limitations on Multi-Provider Misconfigurations . 5
1.4 Issue: Privacy for VPN Data ............................ 6
1.5 Non-Issue: General Protection against Misconfiguration . 7
1.6 Conclusion ............................................. 7
2 Specification .......................................... 7
2.1 Technical Approach ..................................... 7
2.2 Selecting the Security Policy .......................... 8
2.3 BGP Label, Route, and Policy Distribution .............. 9
2.4 MPLS-in-IP/GRE Encapsulation by Ingress PE ............. 10
2.5 MPLS-in-IP vs. MPLS-in-GRE ............................. 11
2.6 PE-PE IPsec (Application of IPsec by Ingress PE) ....... 11
2.7 Application of IPsec by Egress PE ...................... 13
3 Comparison with Using Part of SPI Field as a Label ..... 14
4 Authors' Addresses ..................................... 15
5 Normative References ................................... 16
6 Informative References ................................. 16
7 Intellectual Property Statement ........................ 17
8 Full Copyright Statement ............................... 17
Rosen, et al. [Page 2]
Internet Draft draft-ietf-l3vpn-ipsec-2547-02.txt March 2004
1. Introduction
The present document uses terminology from [RFC2547bis], and
presupposes familiarity with that document and its terminology.
In BGP/MPLS IP VPNs, when an ingress PE router receives a packet from
a CE router, it looks up the packet's destination IP address in a
VRF. As a result of this lookup, it learns the output interface on
which the packet must be sent, and it also learns the set of headers
which must be prepended to the packet before it is sent on that
interface. In "conventional" BGP/MPLS IP VPNs, this set of headers
consists of a data link layer header, possibly followed by an MPLS
label stack. If the packet is going out an interface to a CE router
(i.e. the ingress PE is the same as the egress PE), no MPLS label
stack is needed. If the packet's egress PE router is directly
adjacent to the ingress PE, the MPLS label stack will have one or
more entries. In other cases, the MPLS label stack has two or more
entries.
The bottom label on the MPLS label stack is always a label which will
not be seen until the packet reaches its point of egress from the
network. This label represents a particular route within the packet's
VPN, and we will call it the "VPN route label". Directly above the
VPN route label is a label which represents a route across the
backbone to the egress PE router. We will call this label the
"backbone route label".
The backbone route label may or may not be the packet's top label;
additional entries may also be pushed on the label stack, if
additional MPLS services (e.g., traffic engineering) are used to
carry traffic to the egress PE. These additional labels may be
pushed on by the ingress PE, or by a P router somewhere along the
path. The VPN route label is always the packet's bottom label,
however.
This document specifies procedures for replacing the backbone route
label with an IPsec encapsulation. In effect, this creates an MPLS-
in-IPsec encapsulation, in which the VPN route label is carried
across the network within an IPsec encapsulation. By "within an
IPsec encapsulation", we mean "in a packet containing an IP header
and an IPsec header". This IPsec encapsulation corresponds to an
IPsec Security Association (SA) whose two endpoints are the ingress
PE router and the egress PE router. The payload of the IPsec
encapsulation is an authenticated and/or encrypted MPLS packet, whose
label stack contains a single entry, viz., the VPN route label. The
payload of this MPLS packet is the user data packet being sent within
the VPN.
Rosen, et al. [Page 3]
Internet Draft draft-ietf-l3vpn-ipsec-2547-02.txt March 2004
The IP/IPsec encapsulation will be used even if the ingress PE and
the egress PE are directly adjacent, i.e., even in the case where a
backbone route label would not be used. However, no IP/IPsec
encapsulation is applied if the ingress PE is the same device as the
egress PE.
If additional MPLS services, such as traffic engineering, are used in
the backbone network, an MPLS label stack will appear above the IP
header. This is orthogonal to any issues discussed in the present
document. This results in an MPLS packet containing an IP packet
containing an IPsec packet containing an MPLS packet; the latter MPLS
packet has a single label, the VPN route label.
This document is inspired by [VPN-SPI], and originated as an attempt
to improve upon it.
The remainder of section 1 outlines a number of issues which can be
addressed by the use of IPsec in this manner.
1.1. Issue: MPLS Infrastructure Required
"Conventional" BGP/MPLS IP VPNs require that there be an MPLS Label
Switched Path (LSP) between a packet's ingress PE router and its
egress PE router. This means that an RFC2547 VPN cannot be
implemented if there is a part of the path between the ingress and
egress PE routers which does not support MPLS.
In order to enable BGP/MPLS IP VPNs to be deployed even when there
are non-MPLS routers along the path between the ingress and egress PE
routers, it is desirable to have an alternative which allows the
backbone route label to be replaced with an IP header. This
encapsulating IP header would encapsulate an MPLS packet containing
only the VPN route label. The encapsulation header would have the
address of the egress PE in its destination IP address field; this
would cause the packet to be delivered to the egress PE.
It is possible to replace the backbone route label with an IP header,
possibly followed by a GRE header [MPLS-in-IP/GRE]. However, it then
becomes quite difficult, in general, to protect the VPNs against
spoofed packets. A Service Provider (SP) can protect against spoofed
MPLS packets by the simple expedient of not accepting MPLS packets
from outside its own boundaries (or more generally by keeping track
of which labels are validly received over which interfaces, and
discarding packets which arrive with labels that are not valid for
their incoming interfaces). Protection against spoofed IP packets
requires having all the boundary routers perform filtering; either
Rosen, et al. [Page 4]
Internet Draft draft-ietf-l3vpn-ipsec-2547-02.txt March 2004
(a) filtering out packets from "outside" which are addressed to PE
routers, or (b) filtering out packets from "outside" which have
source addresses that belong "inside", and having PE routers refuse
to accept packets addressed to them but with "outside" source
addresses. The maintenance of these filter lists can be management-
intensive, and the their use at all border routers can affect the
performance seen by all traffic entering the SP's network. Further,
these filtering techniques may be difficult to apply in the case of
multi-provider VPNs, because in multi-provider VPNs, packets from
outside an SP's network can legitimately be addressed to its PE
routers.
If, on the other hand, the backbone route label is replaced by an
IPsec encapsulation, protection against spoofed packets does not rely
on filtering at the border. The cryptographic authentication
features of IPsec enable an egress PE to detect and discard packets
for a particular VPN that were not generated by a valid ingress PE
for that VPN. Thus spoofing protection is managed entirely at the
ingress and egress PE routers, transparently to the border routers.
IPsec does have its own management and performance implications, of
course.
1.2. Issue: Protection Against Misbehavior by Transit Nodes
Cryptographic authentication applied by the ingress PE on a PE-to-PE
basis can protect against the misrouting or modification (intentional
or accidental) of packets by the transit nodes. Packets which get
forwarded to the "wrong" egress PE will not pass authentication, nor
will packets which have been modified. As the VPN route label is
part of the IPsec packet payload, the egress PE will know that the
VPN route label was placed in the packet by a valid ingress PE.
1.3. Issue: Limitations on Multi-Provider Misconfigurations
Sometimes a VPN will have some sites which connect to one SP (SP1),
and some other sites which connect to another SP (SP2).
Consider a case in which VPN V1 has sites attaching to SP1 and SP2,
but VPN V2 has all of its sites attaching only to SP2.
SP2 would like to ensure that nothing done by SP1 can cause V1 to get
illegitimately cross-connected to V2. Since V2 has no sites in SP1,
it should be immune to the effects of any misconfigurations within
SP1.
This assurance can be achieved if the egress PE (in SP2) can
Rosen, et al. [Page 5]
Internet Draft draft-ietf-l3vpn-ipsec-2547-02.txt March 2004
determine, for each VPN packet, whether that packet came from SP1,
and if so, whether it carries an MPLS label which corresponds to a
VPN route that was actually distributed to SP1. (That is, packets
originating from SP1 destined for VPNs in SP2 would be checked if
they are for VPNs which really have sites in SP1.) SP2's egress PEs
could be configured with the knowledge of which VPNs have sites
attached to SP1. Cryptographic authentication could then be used to
determine that a particular packet did indeed originate in SP1.
In general, if an egress PE knows which labels may be validly applied
by which ingress PEs, IPsec authentication can be used to ensure that
a given ingress PE has not applied a label that it has no right to
use. However, the scalability of the VPN scheme would be severely
compromised if an egress PE had to distribute a different set of
labels to each ingress PE. Therefore we will not pursue this general
case, but will only pursue label authentication in the inter-provider
case.
1.4. Issue: Privacy for VPN Data
IPsec Security Associations that associate ingress PE routes with
egress PE routers do not ensure privacy for VPN data. The data is
exposed on the PE-CE access links, and is exposed in the PE routers
themselves. Complete privacy requires that the encryption/decryption
be performed within the enterprise, not by the SP. So the use of
PE-PE IPsec encryption within the network of a single SP will perhaps
be of less import than the use of IPsec authentication. On the other
hand, if an SP is trusted to properly secure its routers, but the
transmission media used by the SP are not trusted, then PE-PE
encryption does provide a valuable measure of privacy.
There may be a need for encryption if a VPN has sites attached to
different trusted SPs, but some of the transit traffic needs to go
through the "public Internet". In this case, it may be necessary to
encrypt the VPN data traffic as it crosses the public Internet.
However, while PE-PE encryption is the one way to handle this, it is
not the only way. An alternative would be to use an encrypted tunnel
to connecting a border router of one trusted SP to a border router of
another. Then the two trusted domains could be treated as immediate
neighbors, adjacent over the tunnel. This would keep the
encryption/decryption at the few locations where it is actually
needed. On the other hand, there may be performance and scalability
advantages to spreading the cost of the cryptography among a larger
set of routers, viz., the ingress and egress PEs.
The scenario of having VPN traffic go from a trusted domain through
an untrusted domain to another trusted domain may not be completely
Rosen, et al. [Page 6]
Internet Draft draft-ietf-l3vpn-ipsec-2547-02.txt March 2004
realistic, though, due to the difficulty of supporting the necessary
Service Level Agreements through the public Internet.
1.5. Non-Issue: General Protection against Misconfiguration
In general, the integrity of an RFC2547 VPN depends upon the SP
having properly configured the PE routers. There is no way of
preventing an SP from creating a bogus VPN that contains sites which
aren't supposed to communicate with each other. It is the SP's
responsibility to get this right.
It is sometimes thought one can obtain protection against
misconfigurations by having the PE routers apply cryptographic
authentication to the VPN packets. This is not the case. If an
ingress PE router has been misconfigured so as to assign a particular
site to the wrong VPN, likely as not the PE has been misconfigured to
apply that VPN's authenticator to packets to/from that site.
Protection against misconfiguration on the part of the SP requires
that the authentication procedure be applied before the ingress PE
router sees the packets, and after the egress PE router forwards
them, and cannot be dealt with by PE-PE IPsec.
1.6. Conclusion
Taken together, the above set of issues suggest that there are
situations in which using PE-PE IPsec as the tunneling protocol for
BGP/MPLS IP VPNs does have value. In the next section, we specify
the necessary procedures for incorporating PE-PE IPsec as a tunneling
option for BGP/MPLS IP VPNs.
2. Specification
2.1. Technical Approach
In short, the technical approach specified here is:
1. Use the standard technique [RFC2547bis] of using an MPLS label
to represent a VPN route, by prepending an MPLS label stack to
the VPN packets. However, the label stack will contain only one
label, the VPN route label.
Rosen, et al. [Page 7]
Internet Draft draft-ietf-l3vpn-ipsec-2547-02.txt March 2004
2. Use an MPLS-in-IP or MPLS-in-GRE encapsulation to turn the
above MPLS packet back into an IP packet. This in effect
creates an "IP tunnel" or a "GRE tunnel" between the ingress PE
router and the egress PE router.
3. Use IPsec Transport Mode to secure the above-mentioned IP
tunnels.
The net effect is that an MPLS packet gets sent through an IPsec-
secured IP or GRE tunnel.
The following sub-sections specify this procedure in greater detail.
2.2. Selecting the Security Policy
One might think that a given SP (or set of cooperating SPs) will
decide either that they need to use IPsec for ALL PE-PE tunnels, or
else that PE-PE IPsec is not needed at all. But this simple "all or
nothing" strategy does not really capture the set of considerations
discussed in the Introduction. For example, a very reasonable policy
might be to use IPsec only for inter-provider PE-PE tunnels, while
using MPLS for intra-provider PE-PE tunnels. Or one might decide to
use IPsec only for certain inter-provider tunnels. Or one might
decide to use IPsec for certain intra-provider tunnels.
In an RFC2547 VPN environment, it makes most sense to place control
of the policies with the egress PE router. It is the egress PE which
needs to know that it wants to process certain packets ONLY if they
come through encrypted tunnels, and that it wants to discard those
same packets if they don't come through encrypted tunnels. Thus one
needs to be able to configure a policy into the egress PE, and have
it signal that policy to the ingress PE. RFC2547 already provides an
egress-to-ingress signaling capability via BGP, and we specify below
how to extend this to the signalling of security policy.
Of course, there is nothing to stop an ingress PE router from being
configured to use IPsec even if the egress PE has not signalled its
desire for IPsec. This should work, as long as the necessary IPsec
infrastructure is in place. (However, in this sort of application
the ingress PE and the egress PE are NOT really independent entities
which might conceivably have different security policies.)
Rosen, et al. [Page 8]
Internet Draft draft-ietf-l3vpn-ipsec-2547-02.txt March 2004
2.3. BGP Label, Route, and Policy Distribution
Distribution of labeled VPN-IP routes by BGP is done exactly as
specified in [RFC2547bis], except that some additional BGP attributes
are needed for each distributed VPN-IP route.
A given egress PE will be configurable to indicate whether it expects
to receive all, some, or none of its VPN traffic through an IPsec-
secured IP or GRE tunnel. In general, an ingress PE will not have to
know in advance whether any of the egress PEs for its VPNs require
their VPN traffic to be sent through an IPsec-secured IP tunnel; this
will be signaled from the egress PE. If an egress PE wants to receive
traffic for a particular VPN-IP route through an IPsec-secured IP
tunnel, it adds a new BGP Extended Community attribute to the route.
This attribute will then get distributed along with the route to the
ingress PEs.
We call this attribute the "IPsec Extended Community". (It is
possible that this will actually be encoded as a particular value or
set of values of a more general "Tunnel Type Extended Community"; for
the purposes of this draft, however, we will continue to refer to it
as the "IPsec Extended Community".)
It is conceivable that an egress PE in a particular SP's network will
only want to receive IPsec-secured IP-tunneled traffic for those VPNs
which have sites that are attached to other SPs. In this case, one
would want to be able to configure, on a per-VRF basis, whether
routes exported from that VRF should have an IPsec Extended Community
attribute or not.
A more complex situation would arise if it were only desired to
receive IPsec-secured IP-tunneled traffic for a particular VPN if
that traffic has originated from a site which is attached to a
different SP's network. That is, one might want to receive inter-
provider traffic through an IPsec-secured IP tunnel, but to receive
intra-provider traffic through an unsecured MPLS LSP. As long as an
SP has a policy of never accepting MPLS packets from other SPs, this
may provide the necessary security while minimizing the amount of
cryptography that actually has to be used.
One way to do this would be to map each exportable IP address prefix
into two different VPN-IP prefixes, using two different RDs (say RD1
and RD2). Then two different RTs (say RT1 and RT2) would be used,
one of which causes intra-provider distribution, and one of which
causes inter-provider distribution. The prefixes with RD1 would be
given RT1 as a route target; the prefixes with RD2 would be given RT2
as a route target. If RT2 is the route target that causes inter-
provider distribution, then only the routes with RT2 would carry the
Rosen, et al. [Page 9]
Internet Draft draft-ietf-l3vpn-ipsec-2547-02.txt March 2004
IPsec Extended Community.
A simpler approach, perhaps, would be to use only a single set of
VPN-IP prefixes, but to have a value of the IPsec Extended Community
which encodes an SP identifier, and which means "only use IPsec if
the ingress PE is in a different SP network than the one which is
identified here". (Again, the assumption is that MPLS packets are not
accepted from other SPs.)
It is conceivable that an egress PE will want some of its IPsec-
secured IP-tunneled VPN traffic to be encrypted, but will want some
to be authenticated and not encrypted. It is even conceivable that it
will want some traffic to arrive through an IPsec tunnel without
being either encrypted or authenticated. The IPsec Extended Community
attribute should have a value which specifies which of these are
required.
It may be desirable to allow the IPsec Extended Community to specify
a set of policies, so that the ingress PE can choose from among them.
2.4. MPLS-in-IP/GRE Encapsulation by Ingress PE
When a PE receives a packet from a CE, it looks up the packet's IP
destination address in the VRF corresponding to that CE. This enables
it to find a VPN-IP route. The VPN-IP route will have an associated
MPLS label and an associated BGP Next Hop. The label is pushed on the
packet. Then, if (and only if) the VPN-IP route has an IPsec Extended
Community attribute, an IP or GRE encapsulation header is prepended
to the packet, creating an MPLS-in-IP or MPLS-in-GRE encapsulated
packet. The IP source address field of the encapsulation header will
be an address of the ingress PE itself. The IP destination address
field of the encapsulation header will contain the value of the
associated BGP Next Hop attribute; this will be an IP address of the
egress PE.
(This description is not meant to specify an implementation strategy;
any implementation procedure which produces the same result is
acceptable.)
N.B.: If the ingress PE and the egress PE are not in the same
autonomous system, this requires that there be an EBGP connection
between a router in one autonomous system and a router in another. If
the two autonomous systems are not adjacent, this will need to be a
multi-hop EBGP connection.
The effect is to dynamically create an IP tunnel between the ingress
and egress PE routers. No apriori configuration of the remote tunnel
Rosen, et al. [Page 10]
Internet Draft draft-ietf-l3vpn-ipsec-2547-02.txt March 2004
endpoints is needed. Note that these IP tunnels are NOT IGP-visible
links, and routing adjacencies are NOT supported across these tunnel.
Note also that the set of remote tunnel endpoints is NOT known in
advance, but is learned dynamically via the BGP distribution of VPN-
IP routes.
These IP tunneled packets will then be associated with an IPsec
Security Association (SA), and transported using IPsec transport
mode. This is described in more detail in the next sub-section.
2.5. MPLS-in-IP vs. MPLS-in-GRE
The MPLS-in-IP encapsulation header is shorter than the MPLS-in-GRE
encapsulation header, and, in theory at least, the latter offers no
advantages to compensate for its use of a longer header.
In practice, implementation considerations of various sorts may make
the MPLS-in-GRE encapsulation preferable.
2.6. PE-PE IPsec (Application of IPsec by Ingress PE)
A given ingress PE needs to have an IPsec SA with each PE router that
is an egress PE for traffic which the ingress PE receives from a CE.
In general, the set of egress PEs for a given ingress PE is not known
in advance. This is determined dynamically by the BGP distribution of
VPN-IP routes. This suggests that it will be very important to be
able to set up IPsec SAs dynamically, and that static keying will not
be a viable option. There will need to be a key distribution
infrastructure that supports multiple SPs, and IKE will need to be
used.
A number of different VPNs might need to have traffic carried from a
particular ingress PE to a particular egress PE. It is thus natural
to ask whether there should be one SA between the pair of PEs, or n
SAs between the pair of PEs, where n is the number of VPNs. Clearly,
scalability is improved by having only a single SA for each pair of
PEs. So the question is whether there is a significant security
advantage to having a distinct SA for each VPN. There does not appear
to be any such advantage. Since the SA is PE-to-PE, NOT CE-to-CE,
having a different SA for each VPN does not provide any additional
security.
It is conceivable that there might need to be two (or more) SAs
between a pair of PEs, e.g., one in which data encryption is used and
one in which authentication but not encryption is used. But this is
Rosen, et al. [Page 11]
Internet Draft draft-ietf-l3vpn-ipsec-2547-02.txt March 2004
not the same as having a separate SA for each VPN.
We assume that the PE router will contain an IPsec module (either a
hardware or a software module) which is responsible for doing the key
exchange, for setting up the IPsec SAs as needed, and for doing the
cryptography.
As discussed in section 2.2, the PE router creates an MPLS-in-IP or
MPLS-in-GRE encapsulated packet. It does not simply send that packet
to its next hop, rather, it delivers the packet, along with the
corresponding IPsec Extended Community value, to the IPsec module.
(As an implementation consideration, it is not really required to
deliver an MPLS-in-IP or MPLS-in-GRE encapsulated packet to the IPsec
module; all that really needs to be delivered is the MPLS packet and
the information, or a pointer thereto, that would be needed to create
the IP encapsulation header.)
The IPsec module will set up an IPsec SA to the packet's destination
address, if one does not already exist. It will then apply the
appropriate IPsec procedures, generating a packet with an IP header
followed by an IPsec header followed by an MPLS label stack followed
by the original data packet. The IPsec module then delivers this
packet, as if it were a brand new packet, to the routing module. The
routing module forwards it as an IP packet.
While the IPsec SA is being set up, packets cannot be delivered
through it. Packets may be dropped during this time, though a
sensible policy might be to queue the first packet and drop the rest
(as is commonly done in ARP implementations while awaiting an ARP
resolution).
We do assume here that the IPsec module is subsidiary to the PE
router, and does not function itself as an independent router in the
network. A solution could be designed to support the latter case, but
at a considerable increment in complexity.
The procedure as specified above requires two routing lookups. Before
IPsec processing, The original packet's destination address is looked
up in a VRF. After IPsec processing, the IPsec packet's destination
address is looked up in the default routing table. It is worth
noting that the information obtained from the second lookup is really
available at the time of the first lookup. In some routers, it might
be advantageous to forward this information, along with the packet,
to the IPsec module; possibly this can be used to avoid the need for
the second lookup. However, in some routers, it will be impossible to
avoid the second lookup.
Rosen, et al. [Page 12]
Internet Draft draft-ietf-l3vpn-ipsec-2547-02.txt March 2004
2.7. Application of IPsec by Egress PE
We assume that every egress PE is also an ingress PE, and hence has
the IPsec module which is mentioned in section 2.2. This module will
handle the necessary IKE functions, SA and tunnel maintenance, etc.,
etc, as well as handling arriving IPsec packets. The IPsec module
will apply the necessary IPsec procedures to arriving IPsec packets,
and will hence recover the contained MPLS-in-IP or MPLS-in-GRE
packets. The IPsec module should then strip off the encapsulating IP
header to recover the MPLS packet, and should then deliver the
resulting MPLS packet to the routing function for ordinary MPLS
switching. (Of course, as an implementation matter, there is probably
no need to put the encapsulating IP header on only to then take it
off immediately.)
There are subtle issues having to do with the proper handling of MPLS
packets (rather than IPsec packets) which the PE router receives from
P routers or from other PE routers. If the top label on a received
MPLS packet corresponds to an IP route in the "default" routing
table, "ordinary" MPLS switching is done. But if the top label on a
received MPLS packet corresponds to a VPN-IP route, there are a
number of different cases to consider:
a. The packet has just been removed from an IPsec SA by the IPsec
module. In this case, ordinary MPLS switching should be done.
(though see below for further qualifications.)
b. The packet arrived from a neighboring P or PE router as an MPLS
packet, with no IPsec encapsulation. There are a number of
sub-cases:
i. The packet's top label corresponds to a VPN-IP route
which was not exported with the IPsec Extended
Community attribute. In this case, ordinary MPLS
switching is applied.
ii. The packet's top label corresponds to a VPN-IP route
which was exported with the value of the IPsec Extended
Community attribute which indicates that IPsec is to be
used only when the ingress PE is in a different SP
network. In this case, we assume that MPLS packets are
not being accepted from other networks, so ordinary
MPLS switching is applied.
iii. The packet's top label corresponds to a VPN-IP route
which was exported with an IPsec Extended Community,
but case ii does not apply. In this case the packet
should be discarded; packets with this label are
Rosen, et al. [Page 13]
Internet Draft draft-ietf-l3vpn-ipsec-2547-02.txt March 2004
supposed to be secured, but this packet was not
properly secured.
Providing this functionality requires the use of two separate label
lookup tables, one of which is used for packets that have been
removed from IPsec SAs, and one of which is used for other packets.
Labels which are only valid when they are carried within an IPsec
packet would only appear in the former lookup table. This does imply
that after a packet has been processed by the IPsec module, the
contained MPLS packet is not simply returned to the routing lookup
path; rather it must carry some indication of which label lookup
table must be used to switch that packet. This also presupposes that
there will be MPLS VPN code to properly populate the two different
lookup tables. Perhaps packets removed from IPsec SAs should appear,
to the routing module, to be arriving on a particular virtual
interface, rather than on the actual sub-interface over which they
really arrived. Then interface-specific label lookup tables could be
used.
In fact, it may be advantageous to have more than one label lookup
table that is used for packets that have been removed from IPsec SAs.
Certain VPN-IP routes will be exported to certain SPs, but not to
others. Security can thus be improved by having one label lookup
table for each such SP. The IPsec module would then have to say, for
each packet, which SP it came from. Given a proper certificate
authority infrastructure this can be inferred by the IPsec module
from the information which the IKE procedure makes available to it.
Of course, all this presupposes that the VPN code is capable of
properly populating the various lookup tables.
3. Comparison with Using Part of SPI Field as a Label
An alternative methodology that achieves similar results is the one
described in [VPN-SPI]. The proposal described above was in fact
inspired by that draft, and arose as a proposed improvement to it.
In the current proposal, IPsec transport mode is applied to an MPLS-
in-IP encapsulation, where the MPLS-in-IP encapsulation carries the
BGP-distributed labels of RFC 2547. In [VPN-SPI], there is no MPLS-
in-IP encapsulation. Rather:
- IPsec tunnel mode is applied to the enduser's packet directly.
- A subfield of the IPsec SPI field is used to provide the function
of the BGP-distributed MPLS label. This either requires that BGP
distribute a different kind of label (one that can fit into the
SPI sub-field), or that an MPLS label be carried within the SPI
Rosen, et al. [Page 14]
Internet Draft draft-ietf-l3vpn-ipsec-2547-02.txt March 2004
field.
The [VPN-SPI] proposal does have the advantage of making each packet
4 bytes shorter, since an entire entry in the MPLS label stack is
eliminated (replaced by the SPI sub-field).
The current proposal, unlike that in [VPN-SPI], does not in any way
alter the use or interpretation of the SPI field, and does not impact
the IPsec or IKE protocols and procedures in any way. The current
proposal also better preserves the distinction between fields that
are meaningful to IPsec and fields that are meaningful to
routing/forwarding. Failure to preserve this layering could
potentially lead to complications in the future (e.g., if BGP ever
needed to distribute a stack of two MPLS labels, or if some
enhancement to IPsec ever needed to reclaim the SPI sub-field used to
carry the label, etc., etc.). Failure to preserve the layering also
complicates the situation in which the transport is sometimes IPsec
and sometimes MPLS. Keeping the MPLS VPN functionality in the MPLS
layer and out of the IPsec layer certainly seems worthwhile.
4. Authors' Addresses
Eric C. Rosen
Cisco Systems, Inc.
1414 Massachusetts Avenue
Boxborough, MA 01719
Email: erosen@cisco.com
Jeremy De Clercq
Alcatel
Francis Wellesplein 1
2018 Antwerpen, Belgium
Phone: +32 3 240 4752
Email: jeremy.de_clercq@alcatel.be
Rosen, et al. [Page 15]
Internet Draft draft-ietf-l3vpn-ipsec-2547-02.txt March 2004
Olivier Paridaens
Alcatel
Francis Wellesplein 1
2018 Antwerpen, Belgium
Phone: +32 3 240 9320
Email: olivier.paridaens@alcatel.be
Yves T'Joens
Alcatel
Francis Wellesplein 1
2018 Antwerpen, Belgium
Phone: +32 3 240 7890
Email: yves.tjoens@alcatel.be
Chandru Sargor
CoSine Communications
1200 Bridge Parkway
Redwood City, CA 94065
Email: csargor@cosinecom.com
5. Normative References
[RFC2547bis] BGP/MPLS IP VPNs, Rosen et. al., draft-ietf-l3vpn-
rfc2547bis-01.txt, September 2003
6. Informative References
[MPLS-in-IP/GRE] "Encapsulating MPLS in IP or GRE",, Worster et. al.,
draft-ietf-mpls-in-ip-or-gre-05.txt, February 2004
[VPN-SPI] BGP/IPsec VPN, De Clercq et. al., draft-declercq-bgp-
ipsec-vpn-01.txt, February 2001
Rosen, et al. [Page 16]
Internet Draft draft-ietf-l3vpn-ipsec-2547-02.txt March 2004
7. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
8. Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78 and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Rosen, et al. [Page 17]
