draft-ietf-l3vpn-ipsec-2547-03.txt   draft-ietf-l3vpn-ipsec-2547-04.txt 
Network Working Group Eric C. Rosen Network Working Group Eric C. Rosen
Internet Draft Cisco Systems, Inc. Internet Draft Cisco Systems, Inc.
Expiration Date: March 2005 Expiration Date: December 2005
Jeremy De Clercq Jeremy De Clercq
Olivier Paridaens Olivier Paridaens
Yves T'Joens Yves T'Joens
Alcatel Alcatel
Chandru Sargor Chandru Sargor
Cosine Communications
September 2004 June 2005
Use of PE-PE IPsec in RFC2547 VPNs Architecture for the Use of PE-PE IPsec Tunnels in BGP/MPLS IP VPNs
draft-ietf-l3vpn-ipsec-2547-03.txt draft-ietf-l3vpn-ipsec-2547-04.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with RFC 3668. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
In BGP/MPLS IP Virtual Private Networks (VPNs), VPN data packets In BGP/MPLS IP Virtual Private Networks (VPNs), VPN data packets
traveling from one Provider Edge (PE) router to another generally traveling from one Provider Edge (PE) router to another generally
carry two MPLS labels, an inner label that corresponds to a VPN- carry two MPLS labels, an "inner" label that corresponds to a VPN-
specific route, and an outer label that corresponds to a Label specific route, and an "outer" label that corresponds to a Label
Switched Path (LSP) between the PE routers. In some circumstances, Switched Path (LSP) between the PE routers. In some circumstances,
it is desirable to support the same type of VPN architecture, but it is desirable to support the same type of VPN architecture, but
using an IPsec Security Association in place of that LSP. The outer using an IPsec Security Association in place of that LSP. The
MPLS label would thus be replaced by an IP/IPsec header. This "outer" MPLS label would thus be replaced by an IP/IPsec header.
enables the VPN packets to be carried securely over non-MPLS This enables the VPN packets to be carried securely over non-MPLS
networks, using standard IPsec authentication and/or encryption networks, using standard IPsec authentication and/or encryption
functions to protect them. This draft specifies the procedures which functions to protect them. This draft specifies the procedures which
are specific to support of BGP/MPLS IP VPNs using the IPsec are specific to support of BGP/MPLS IP VPNs using the IPsec
encapsulation. encapsulation.
Table of Contents Table of Contents
1 Introduction ........................................... 3 1 Introduction ........................................... 3
1.1 Issue: MPLS Infrastructure Required .................... 4 1.1 Issue: Protection Against Spoofed Packets .............. 4
1.2 Issue: Protection Against Misbehavior by Transit Nodes . 5 1.2 Issue: Protection Against Misbehavior by Transit Nodes . 5
1.3 Issue: Limitations on Multi-Provider Misconfigurations . 5 1.3 Issue: Limitations on Multi-Provider Misconfigurations . 5
1.4 Issue: Privacy for VPN Data ............................ 6 1.4 Issue: Privacy for VPN Data ............................ 6
1.5 Non-Issue: General Protection against Misconfiguration . 7 1.5 Non-Issue: General Protection against Misconfiguration . 7
1.6 Conclusion ............................................. 7 1.6 Conclusion ............................................. 7
2 Specification .......................................... 7 2 Specification .......................................... 7
2.1 Technical Approach ..................................... 7 2.1 Technical Approach ..................................... 7
2.2 Selecting the Security Policy .......................... 8 2.2 Selecting the Security Policy .......................... 8
2.3 BGP Label, Route, and Policy Distribution .............. 9 2.3 BGP Label, Route, and Policy Distribution .............. 9
2.4 MPLS-in-IP/GRE Encapsulation by Ingress PE ............. 10 2.4 MPLS-in-IP/GRE Encapsulation by Ingress PE ............. 10
2.5 MPLS-in-IP vs. MPLS-in-GRE ............................. 11 2.5 MPLS-in-IP vs. MPLS-in-GRE ............................. 11
2.6 PE-PE IPsec (Application of IPsec by Ingress PE) ....... 11 2.6 PE-PE IPsec (Application of IPsec by Ingress PE) ....... 11
2.7 Application of IPsec by Egress PE ...................... 13 2.7 Application of IPsec by Egress PE ...................... 13
3 Comparison with Using Part of SPI Field as a Label ..... 14 3 Comparison with Using Part of SPI Field as a Label ..... 15
4 Authors' Addresses ..................................... 15 4 Security Considerations ................................ 15
5 Normative References ................................... 16 5 IANA Considerations .................................... 16
6 Informative References ................................. 16 6 Acknowledgments ........................................ 16
7 Intellectual Property Statement ........................ 17 7 Authors' Addresses ..................................... 16
8 Full Copyright Statement ............................... 17 8 Normative References ................................... 17
9 Informative References ................................. 17
10 Full Copyright Statement ............................... 17
11 Intellectual Property .................................. 18
1. Introduction 1. Introduction
The present document uses terminology from [RFC2547bis], and The present document uses terminology from [RFC2547bis], and
presupposes familiarity with that document and its terminology. presupposes familiarity with that document and its terminology.
In BGP/MPLS IP VPNs, when an ingress PE router receives a packet from 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 a CE router, it looks up the packet's destination IP address in a VRF
VRF. As a result of this lookup, it learns the output interface on ("VPN Routing and Forwarding Table"). As a result of this lookup, it
which the packet must be sent, and it also learns the set of headers learns the output interface on which the packet must be sent, and it
which must be prepended to the packet before it is sent on that also learns the set of headers which must be prepended to the packet
interface. In "conventional" BGP/MPLS IP VPNs, this set of headers before it is sent on that interface. In "conventional" BGP/MPLS IP
consists of a data link layer header, possibly followed by an MPLS VPNs, this set of headers consists of a data link layer header
label stack. If the packet is going out an interface to a CE router followed by (possibly) an MPLS label stack. If the packet is going
(i.e. the ingress PE is the same as the egress PE), no MPLS label out an interface to a CE router (i.e. the ingress PE is the same as
stack is needed. If the packet's egress PE router is directly the egress PE), no MPLS label stack is needed. If the packet's
adjacent to the ingress PE, the MPLS label stack will have one or egress PE router is directly adjacent to the ingress PE, the MPLS
more entries. In other cases, the MPLS label stack has two or more label stack will have one or more entries. In other cases, the MPLS
entries. label stack has two or more entries.
The bottom label on the MPLS label stack is always a label which will Unless the packet goes directly to a CE router on the same PE, the
not be seen until the packet reaches its point of egress from the MPLS label stack will contain a label that will not be seen until the
network. This label represents a particular route within the packet's packet reaches its point of egress from the network. This label
VPN, and we will call it the "VPN route label". Directly above the represents a particular route within the packet's VPN, and we will
VPN route label is a label which represents a route across the call it the "VPN route label". Directly above the VPN route label is
backbone to the egress PE router. We will call this label the a label which represents a route across the backbone to the egress PE
"backbone route label". router. We will call this label the "backbone route label".
The backbone route label may or may not be the packet's top 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 entries may also be pushed on the label stack, if
additional MPLS services (e.g., traffic engineering) are used to additional MPLS services (e.g., traffic engineering) are used to
carry traffic to the egress PE. These additional labels may be 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 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, path.
however.
This document specifies procedures for replacing the backbone route This document specifies procedures for replacing the backbone route
label with an IPsec encapsulation. In effect, this creates an MPLS- label with an IPsec encapsulation. In effect, this creates an MPLS-
in-IPsec encapsulation, in which the VPN route label is carried in-IPsec encapsulation, in which the VPN route label is carried
across the network within an IPsec encapsulation. By "within an across the network within an IPsec encapsulation. By "within an
IPsec encapsulation", we mean "in a packet containing an IP header IPsec encapsulation", we mean "in a packet containing an IP header
and an IPsec header". This IPsec encapsulation corresponds to an and an IPsec header". This IPsec encapsulation corresponds to an
IPsec Security Association (SA) whose two endpoints are the ingress IPsec Security Association (SA) whose two endpoints are the ingress
PE router and the egress PE router. The payload of the IPsec PE router and the egress PE router. The payload of the IPsec
encapsulation is an authenticated and/or encrypted MPLS packet, whose encapsulation is an authenticated and/or encrypted MPLS packet, whose
label stack contains a single entry, viz., the VPN route label. The 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 payload of this MPLS packet is the user data packet being sent within
the VPN. the VPN.
The IP/IPsec encapsulation will be used even if the ingress PE and 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 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 backbone route label might not be used. However, no IP/IPsec
encapsulation is applied if the ingress PE is the same device as the encapsulation is applied if the ingress PE is the same device as the
egress PE. egress PE.
If additional MPLS services, such as traffic engineering, are used in If additional MPLS services, such as traffic engineering, are used in
the backbone network, an MPLS label stack will appear above the IP the backbone network, an MPLS label stack will appear above the IP
header. This is orthogonal to any issues discussed in the present header. This is orthogonal to any issues discussed in the present
document. This results in an MPLS packet containing an IP packet document. This results in an MPLS packet containing an IP packet
containing an IPsec packet containing an MPLS packet; the latter MPLS containing an IPsec packet containing an MPLS packet; the latter MPLS
packet has a single label, the VPN route label. packet may have only a single label, the VPN route label.
This document is inspired by [VPN-SPI], and originated as an attempt This document is inspired by [VPN-SPI], and originated as an attempt
to improve upon it. to improve upon it.
The remainder of section 1 outlines a number of issues which can be The remainder of section 1 outlines a number of issues which can be
addressed by the use of IPsec in this manner. addressed by the use of IPsec in this manner.
1.1. Issue: MPLS Infrastructure Required 1.1. Issue: Protection Against Spoofed Packets
"Conventional" BGP/MPLS IP VPNs require that there be an MPLS Label According to [RFC2547bis]:
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 "Before a customer data packet travels across the Service
are non-MPLS routers along the path between the ingress and egress PE Provider's backbone, it is encapsulated with the MPLS label that
routers, it is desirable to have an alternative which allows the corresponds, in the customer's VPN, to the route that is the best
backbone route label to be replaced with an IP header. This match to the packet's destination address. This MPLS packet is
encapsulating IP header would encapsulate an MPLS packet containing further encapsulated (e.g., with another MPLS label, or with an
only the VPN route label. The encapsulation header would have the IP or GRE ("Generic Routing Encapsulation" tunnel header [MPLS-
address of the egress PE in its destination IP address field; this in-IP-GRE]) so that it gets tunneled across the backbone to the
would cause the packet to be delivered to the egress PE. proper PE router."
It is possible to replace the backbone route label with an IP header, This explicitly allows the use of three different tunnel
possibly followed by a GRE header [MPLS-in-IP/GRE]. However, it then encapsulations: MPLS, MPLS-in-IP, and MPLS-in-GRE. [MPLS-in-L2TPv3]
allows a fourth. The latter three encapsulations all require the
packets to have an IP header in which the address of the egress PE
appears in the destination IP address field. However, it then
becomes quite difficult, in general, to protect the VPNs against becomes quite difficult, in general, to protect the VPNs against
spoofed packets. A Service Provider (SP) can protect against spoofed spoofed packets.
MPLS packets by the simple expedient of not accepting MPLS packets
from outside its own boundaries (or more generally by keeping track A Service Provider (SP) can protect against spoofed MPLS packets by
of which labels are validly received over which interfaces, and the simple expedient of not accepting MPLS packets from outside its
discarding packets which arrive with labels that are not valid for own boundaries (or more generally by keeping track of which labels
their incoming interfaces). Protection against spoofed IP packets are validly received over which interfaces, and discarding packets
requires having all the boundary routers perform filtering; either which arrive with labels that are not valid for their incoming
(a) filtering out packets from "outside" which are addressed to PE interfaces). However, this does depend on the assumption that the SP
routers, or (b) filtering out packets from "outside" which have network is not serving as a transit network for arbitrary MPLS
source addresses that belong "inside", and having PE routers refuse packets from other networks.
to accept packets addressed to them but with "outside" source
addresses. The maintenance of these filter lists can be management- Protection against spoofed IP packets requires having all the
intensive, and the their use at all border routers can affect the boundary routers perform filtering; either (a) filtering out packets
performance seen by all traffic entering the SP's network. Further, from "outside" which are addressed to PE routers, or (b) filtering
these filtering techniques may be difficult to apply in the case of out packets from "outside" which have source addresses that belong
multi-provider VPNs, because in multi-provider VPNs, packets from "inside", and having PE routers refuse to accept packets addressed to
outside an SP's network can legitimately be addressed to its PE them but with "outside" source addresses. The maintenance of these
routers. 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 If, on the other hand, the backbone route label is replaced by an
IPsec encapsulation, protection against spoofed packets does not rely IPsec encapsulation, protection against spoofed packets does not rely
on filtering at the border. The cryptographic authentication on any sort of filtering at the border. The cryptographic
features of IPsec enable an egress PE to detect and discard packets authentication features of IPsec enable an egress PE to detect and
for a particular VPN that were not generated by a valid ingress PE discard packets for a particular VPN that were not generated by a
for that VPN. Thus spoofing protection is managed entirely at the valid ingress PE for that VPN. Thus spoofing protection is managed
ingress and egress PE routers, transparently to the border routers. entirely at the ingress and egress PE routers, transparently to the
IPsec does have its own management and performance implications, of border routers. IPsec does have its own management and performance
course. implications, of course.
1.2. Issue: Protection Against Misbehavior by Transit Nodes 1.2. Issue: Protection Against Misbehavior by Transit Nodes
Cryptographic authentication applied by the ingress PE on a PE-to-PE Cryptographic authentication applied by the ingress PE on a PE-to-PE
basis can protect against the misrouting or modification (intentional basis can protect against the misrouting or modification (intentional
or accidental) of packets by the transit nodes. Packets which get or accidental) of packets by the transit nodes. Packets which get
forwarded to the "wrong" egress PE will not pass authentication, nor forwarded to the "wrong" egress PE will not pass authentication, nor
will packets which have been modified. As the VPN route label is 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 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. VPN route label was placed in the packet by a valid ingress PE.
skipping to change at page 6, line 39 skipping to change at page 6, line 41
PE-PE IPsec encryption within the network of a single SP will perhaps 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 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 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 transmission media used by the SP are not trusted, then PE-PE
encryption does provide a valuable measure of privacy. encryption does provide a valuable measure of privacy.
There may be a need for encryption if a VPN has sites attached to 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 different trusted SPs, but some of the transit traffic needs to go
through the "public Internet". In this case, it may be necessary to through the "public Internet". In this case, it may be necessary to
encrypt the VPN data traffic as it crosses the public Internet. 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 However, while PE-PE encryption is one way to handle this, it is not
not the only way. An alternative would be to use an encrypted tunnel the only way. An alternative would be to use an encrypted tunnel to
to connecting a border router of one trusted SP to a border router of connect a border router of one trusted SP to a border router of
another. Then the two trusted domains could be treated as immediate another. Then the two trusted domains could be treated as immediate
neighbors, adjacent over the tunnel. This would keep the neighbors, adjacent over the tunnel. This would keep the
encryption/decryption at the few locations where it is actually encryption/decryption at the few locations where it is actually
needed. On the other hand, there may be performance and scalability needed. On the other hand, there may be performance and scalability
advantages to spreading the cost of the cryptography among a larger advantages to spreading the cost of the cryptography among a larger
set of routers, viz., the ingress and egress PEs. set of routers, viz., the ingress and egress PEs.
The scenario of having VPN traffic go from a trusted domain through The scenario of having VPN traffic go from a trusted domain through
an untrusted domain to another trusted domain may not be completely an untrusted domain to another trusted domain may not be completely
realistic, though, due to the difficulty of supporting the necessary realistic, though, due to the difficulty of supporting the necessary
Service Level Agreements through the public Internet. Service Level Agreements through the public Internet.
1.5. Non-Issue: General Protection against Misconfiguration 1.5. Non-Issue: General Protection against Misconfiguration
In general, the integrity of an RFC2547 VPN depends upon the SP In general, the integrity of a BGP/MPLS IP VPN depends upon the SP
having properly configured the PE routers. There is no way of having properly configured the PE routers. The SP must be careful
preventing an SP from creating a bogus VPN that contains sites which not to incorrectly create a VPN containing sites that are not
aren't supposed to communicate with each other. It is the SP's supposed to communicate with each other.
responsibility to get this right.
It is sometimes thought one can obtain protection against It is sometimes thought one can obtain protection against
misconfigurations by having the PE routers apply cryptographic misconfigurations by having the PE routers apply cryptographic
authentication to the VPN packets. This is not the case. If an authentication to the VPN packets. This is not the case. If an
ingress PE router has been misconfigured so as to assign a particular 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 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. apply that VPN's authenticator to packets to/from that site.
Protection against misconfiguration on the part of the SP requires Protection against misconfiguration on the part of the SP requires
that the authentication procedure be applied before the ingress PE that the authentication procedure be applied before the ingress PE
skipping to change at page 8, line 30 skipping to change at page 8, line 30
One might think that a given SP (or set of cooperating SPs) will 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 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 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 nothing" strategy does not really capture the set of considerations
discussed in the Introduction. For example, a very reasonable policy discussed in the Introduction. For example, a very reasonable policy
might be to use IPsec only for inter-provider PE-PE tunnels, while 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 using MPLS for intra-provider PE-PE tunnels. Or one might decide to
use IPsec only for certain inter-provider tunnels. Or one might use IPsec only for certain inter-provider tunnels. Or one might
decide to use IPsec for certain intra-provider tunnels. decide to use IPsec for certain intra-provider tunnels.
In an RFC2547 VPN environment, it makes most sense to place control The architecture therefore supports more finely grained policies than
of the policies with the egress PE router. It is the egress PE which "all or nothing". However, in order to support the more finely
needs to know that it wants to process certain packets ONLY if they grained policies, an SP must, at its border routers, discard all
come through encrypted tunnels, and that it wants to discard those labeled packets that originate from outside its network. Otherwise
same packets if they don't come through encrypted tunnels. Thus one it is difficult, if not impossible, to know for sure that a packet
needs to be able to configure a policy into the egress PE, and have which is not protected by IPsec originated from a trusted PE within a
it signal that policy to the ingress PE. RFC2547 already provides an trusted area of the network. If it is not feasible or desirable to
egress-to-ingress signaling capability via BGP, and we specify below discard all labeled packets received at the border routers, then both
how to extend this to the signalling of security policy. intra-provider and inter-provider tunnels would have to be protected
by IPsec.
Of course, there is nothing to stop an ingress PE router from being In a BGP/MPLS IP VPN environment, if it is desired to use IPsec
configured to use IPsec even if the egress PE has not signalled its between a pair of PEs, one might expect that the ingress PE and the
desire for IPsec. This should work, as long as the necessary IPsec egress PE are each configured to ensure that traffic to the other is
infrastructure is in place. (However, in this sort of application sent via IPsec.
the ingress PE and the egress PE are NOT really independent entities
which might conceivably have different security policies.) If the ingress PE is configured to use IPsec but the egress PE is
not, then the ingress PE will attempt to set up an SA to the egress
PE, and the egress PE will either cooperate or not. In the former
case, the SA gets set up, and traffic can be sent from ingress to
egress in accord with the policy configured into the ingress.
If the egress PE is configured to use IPsec but the egress PE is not,
then successful transmission of the traffic cannot occur unless there
is some way for the egress to signal its policy to the ingress.
[RFC2547bis] already provides an egress-to-ingress signaling
capability via BGP, and we specify below how to extend this to the
signalling of security policy.
2.3. BGP Label, Route, and Policy Distribution 2.3. BGP Label, Route, and Policy Distribution
Distribution of labeled VPN-IP routes by BGP is done exactly as Distribution of labeled VPN-IP routes by BGP is done exactly as
specified in [RFC2547bis], except that some additional BGP attributes specified in [RFC2547bis], except that some additional BGP attributes
are needed for each distributed VPN-IP route. are needed for each distributed VPN-IP route.
A given egress PE will be configurable to indicate whether it expects 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- 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 secured IP or GRE tunnel. In general, an ingress PE will not have to
skipping to change at page 11, line 42 skipping to change at page 12, line 4
be a viable option. There will need to be a key distribution be a viable option. There will need to be a key distribution
infrastructure that supports multiple SPs, and IKE will need to be infrastructure that supports multiple SPs, and IKE will need to be
used. used.
A number of different VPNs might need to have traffic carried from a 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 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 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, 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 scalability is improved by having only a single SA for each pair of
PEs. So the question is whether there is a significant security PEs. So the question is whether there is a significant security
advantage to having a distinct SA for each VPN. There does not appear advantage to having a distinct SA for each VPN. Since the SA is PE-
to be any such advantage. Since the SA is PE-to-PE, NOT CE-to-CE, to-PE, NOT CE-to-CE, having a different SA for each VPN does not
having a different SA for each VPN does not provide any additional provide any additional privacy. On the other hand, when multiple
security. VPNs share an SA, the compromise of a key has a greater impact, and
an attack on the security of one VPN may become an attack on the
security of all the VPNs sharing the SA. Nevertheless, the use of
one SA for multiple VPNs seems to be a reasonable tradeoff of
additional overhead against additional security.
It is conceivable that there might need to be two (or more) SAs 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 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 one in which authentication but not encryption is used. But this is
not the same as having a separate SA for each VPN. not the same as having a separate SA for each VPN.
We assume that the PE router will contain an IPsec module (either a 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 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 exchange, for setting up the IPsec SAs as needed, and for doing the
cryptography. cryptography.
As discussed in section 2.2, the PE router creates an MPLS-in-IP or 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 MPLS-in-GRE encapsulated packet. It does not simply send that packet
to its next hop, rather, it delivers the packet, along with the to its next hop, rather, it delivers the packet to the IPsec module.
corresponding IPsec Extended Community value, to the IPsec module.
(As an implementation consideration, it is not really required to (As an implementation consideration, it is not really required to
deliver an MPLS-in-IP or MPLS-in-GRE encapsulated packet to the IPsec 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 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 information, or a pointer thereto, that would be needed to create
the IP encapsulation header.) the IP encapsulation header.)
The IPsec module will set up an IPsec SA to the packet's destination 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 address, if one does not already exist. It will then apply the
appropriate IPsec procedures, generating a packet with an IP header appropriate IPsec procedures, generating a packet with an IP header
followed by an IPsec header followed by an MPLS label stack followed followed by an IPsec header followed by an MPLS label stack followed
skipping to change at page 13, line 50 skipping to change at page 14, line 14
ii. The packet's top label corresponds to a VPN-IP route ii. The packet's top label corresponds to a VPN-IP route
which was exported with the value of the IPsec Extended which was exported with the value of the IPsec Extended
Community attribute which indicates that IPsec is to be Community attribute which indicates that IPsec is to be
used only when the ingress PE is in a different SP used only when the ingress PE is in a different SP
network. In this case, we assume that MPLS packets are network. In this case, we assume that MPLS packets are
not being accepted from other networks, so ordinary not being accepted from other networks, so ordinary
MPLS switching is applied. MPLS switching is applied.
iii. The packet's top label corresponds to a VPN-IP route iii. The packet's top label corresponds to a VPN-IP route
which was exported with an IPsec Extended Community, which was exported with an IPsec Extended Community
but case ii does not apply. In this case the packet indicating that IPsec is to be used in all cases. In
should be discarded; packets with this label are this case the packet should be discarded; packets with
supposed to be secured, but this packet was not this label are supposed to be secured, but this packet
properly secured. was not properly secured.
Providing this functionality requires the use of two separate label Providing this functionality requires the use of two separate label
lookup tables, one of which is used for packets that have been 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. 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 Labels which are only valid when they are carried within an IPsec
packet would only appear in the former lookup table. This does imply packet would only appear in the former lookup table. This does imply
that after a packet has been processed by the IPsec module, the that after a packet has been processed by the IPsec module, the
contained MPLS packet is not simply returned to the routing lookup contained MPLS packet is not simply returned to the routing lookup
path; rather it must carry some indication of which label lookup path; rather it must carry some indication of which label lookup
table must be used to switch that packet. This also presupposes that table must be used to switch that packet. This also presupposes that
skipping to change at page 14, line 42 skipping to change at page 15, line 13
properly populating the various lookup tables. properly populating the various lookup tables.
3. Comparison with Using Part of SPI Field as a Label 3. Comparison with Using Part of SPI Field as a Label
An alternative methodology that achieves similar results is the one An alternative methodology that achieves similar results is the one
described in [VPN-SPI]. The proposal described above was in fact described in [VPN-SPI]. The proposal described above was in fact
inspired by that draft, and arose as a proposed improvement to it. 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 the current proposal, IPsec transport mode is applied to an MPLS-
in-IP encapsulation, where the MPLS-in-IP encapsulation carries the in-IP encapsulation, where the MPLS-in-IP encapsulation carries the
BGP-distributed labels of RFC 2547. In [VPN-SPI], there is no MPLS- BGP-distributed labels of [RFC2547bis]. In [VPN-SPI], there is no
in-IP encapsulation. Rather: MPLS-in-IP encapsulation. Rather:
- IPsec tunnel mode is applied to the enduser's packet directly. - IPsec tunnel mode is applied to the enduser's packet directly.
- A subfield of the IPsec SPI field is used to provide the function - A subfield of the IPsec SPI (Security Parameters Index) field is
of the BGP-distributed MPLS label. This either requires that BGP used to provide the function of the BGP-distributed MPLS label.
distribute a different kind of label (one that can fit into the This either requires that BGP distribute a different kind of
SPI sub-field), or that an MPLS label be carried within the SPI label (one that can fit into the SPI sub-field), or that an MPLS
field. label be carried within the SPI field.
The [VPN-SPI] proposal does have the advantage of making each packet 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 4 bytes shorter, since an entire entry in the MPLS label stack is
eliminated (replaced by the SPI sub-field). eliminated (replaced by the SPI sub-field).
The current proposal, unlike that in [VPN-SPI], does not in any way 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 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 the IPsec or IKE protocols and procedures in any way. The current
proposal also better preserves the distinction between fields that proposal also better preserves the distinction between fields that
are meaningful to IPsec and fields that are meaningful to are meaningful to IPsec and fields that are meaningful to
routing/forwarding. Failure to preserve this layering could routing/forwarding. Failure to preserve this layering could
potentially lead to complications in the future (e.g., if BGP ever potentially lead to complications in the future (e.g., if BGP ever
needed to distribute a stack of two MPLS labels, or if some 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 enhancement to IPsec ever needed to reclaim the SPI sub-field used to
carry the label, etc., etc.). Failure to preserve the layering also carry the label, etc., etc.). Failure to preserve the layering also
complicates the situation in which the transport is sometimes IPsec complicates the situation in which the transport is sometimes IPsec
and sometimes MPLS. Keeping the MPLS VPN functionality in the MPLS and sometimes MPLS. Keeping the MPLS VPN functionality in the MPLS
layer and out of the IPsec layer certainly seems worthwhile. layer and out of the IPsec layer certainly seems worthwhile.
4. Authors' Addresses 4. Security Considerations
Security considerations are discussed throughout the document.
5. IANA Considerations
This document defines no encodings, hence there are no IANA
considerations.
6. Acknowledgments
The authors would like to thank Mark Duffy for his comments.
7. Authors' Addresses
Eric C. Rosen Eric C. Rosen
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusetts Avenue 1414 Massachusetts Avenue
Boxborough, MA 01719 Boxborough, MA 01719
Email: erosen@cisco.com Email: erosen@cisco.com
Jeremy De Clercq Jeremy De Clercq
Alcatel Alcatel
Francis Wellesplein 1 Francis Wellesplein 1
skipping to change at page 16, line 17 skipping to change at page 17, line 4
2018 Antwerpen, Belgium 2018 Antwerpen, Belgium
Phone: +32 3 240 9320 Phone: +32 3 240 9320
Email: olivier.paridaens@alcatel.be Email: olivier.paridaens@alcatel.be
Yves T'Joens Yves T'Joens
Alcatel Alcatel
Francis Wellesplein 1 Francis Wellesplein 1
2018 Antwerpen, Belgium 2018 Antwerpen, Belgium
Phone: +32 3 240 7890 Phone: +32 3 240 7890
Email: yves.tjoens@alcatel.be Email: yves.tjoens@alcatel.be
Chandru Sargor Chandru Sargor
CoSine Communications
1200 Bridge Parkway
Redwood City, CA 94065
Email: csargor@cosinecom.com
5. Normative References 8. Normative References
[RFC2547bis] BGP/MPLS IP VPNs, Rosen et. al., draft-ietf-l3vpn- [RFC2547bis] BGP/MPLS IP VPNs, Rosen et. al., draft-ietf-l3vpn-
rfc2547bis-02.txt, September 2004 rfc2547bis-03.txt, October 2004
6. Informative References 9. Informative References
[MPLS-in-IP/GRE] "Encapsulating MPLS in IP or GRE",, Worster et. al., [MPLS-in-IP/GRE] "Encapsulating MPLS in IP or GRE",, Worster et. al.,
draft-ietf-mpls-in-ip-or-gre-08.txt, June 2004 RFC 4023, March 2005
[VPN-SPI] BGP/IPsec VPN, De Clercq et. al., draft-declercq-bgp- [MPLS-in-L2TPv3] "Encapsulation of MPLS over Layer 2 Tunneling
ipsec-vpn-01.txt, February 2001 Protocol Version 3", draft-ietf-mpls-over-l2tpv3-00.txt, Townsley,
Seely, Young, October 2004
7. Intellectual Property Statement [VPN-SPI] BGP/IPsec VPN, J. De Clercq, O. Paridaens, Y. T'Joens, C.
Sargor, February 2001, expired internet-draft
10. Full Copyright Statement
Copyright (C) The Internet Society (2005).
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.
11. Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 17, line 28 skipping to change at line 772
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. 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.
 End of changes. 

This html diff was produced by rfcdiff 1.24, available from http://www.levkowetz.com/ietf/tools/rfcdiff/