Network Working Group Rahul Aggarwal
Internet Draft Kireeti Kompella
Expiration Date: April 2004 Juniper Networks
Use of PE-PE IP/GRE/IPSec for MPLS PWs
draft-raggarwa-pwe3-pw-over-ip-00.txt
1. 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.
2. Abstract
This document describes procedures for carrying MPLS PWs [PWARCH,
LDP-CONTROL] over IP, GRE or IPsec tunnels. The outermost PSN tunnel
encapsulation of the PW is IP, GRE or IPsec, instead of a MPLS label
when the PW is carried over an MPLS network. This enables the PW
packets to be carried over non-MPLS networks.
draft-raggarwa-pwe3-pw-over-ip-00.txt [Page 1]
Internet Draft draft-raggarwa-pwe3-pw-over-ip-00.txt October 2003
3. Summary for the PWE3 WG
This document describes procedures for carrying MPLS PWs [PWARCH,
PWREQ, LDP-CONTROL] when the PSN tunnel is IP, GRE or IPsec i.e. over
IP networks. In this case the outer PSN encapsulation is IP, GRE or
IPsec instead of an MPLS label, that would be used when the PSN is
MPLS. Hence this draft specifies procedures to allow MPLS PWs to run
on networks which do not implement MPLS in the core switches, and/or
in environments in which increased security is needed. [PWARCH]
mentions carrying MPLS PWs over IP or GRE PSNs. This draft describes
procedures for the same in detail. In addition it also describes the
procedures for carrying MPLS PWs over IPsec tunnels.
3.1. Why is it Targeted at this WG
PWE3 WG is chartered with considering MPLS PW setup and maintenance
over IP networks [PWARCH, PWREQ]. This draft specifies procedures
that allow a MPLS PW to be carried in an IP, GRE or IPsec tunnel.
Hence it meets requirements that are not met by existing
specifications. It is to be noted that this document does not concern
itself with IP, GRE or IPsec PSN setup.
3.2. Justification
The WG should consider this document as it extends a style of MPLS
PWs explicitly called out in the charter so that it becomes
applicable to a wider range of IP-based backbone environments.
4. Introduction
In "conventional" MPLS PWs, that run over a MPLS PSN, when a PE
router receives a packet from a CE router, it determines the packet's
input interface, and if needed looks up the packet's destination
layer 2 identifier. As a result, it obtains an MPLS label stack, a
data link header and an output interface. The label stack is
prepended to the packet, the data link header is prepended to that,
and the resulting frame is queued for the output interface.
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 PW, delivering packets to
an attachment circuit. The purpose of the upper labels is to cause
the packet to be delivered to the router which understands the bottom
label.
draft-raggarwa-pwe3-pw-over-ip-00.txt [Page 2]
Internet Draft draft-raggarwa-pwe3-pw-over-ip-00.txt October 2003
What we discuss here are procedures for creating an MPLS packet which
carries ONLY the bottom label, and then using either GRE, IP or IPsec
encapsulation to carry that MPLS packet across the network. That is,
the upper labels are replaced with an IP header for an IP tunnel; IP
and GRE header for GRE encapsulation; and in the case of IPsec
encapsulation an IP and IPsec header.
5. Motivations
5.1. Transit Routers May be Non-MPLS Routers
MPLS PWs over a MPLS PSN 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 a MPLS PW 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 MPLS PWs to be deployed even when there are non-
MPLS router along the path between the ingress and egress PE routers,
it is desirable to have an alternative which allows the upper labels
to be replaced with either IP or (IP + GRE) or (IP + IPsec) header.
This encapsulating header would encapsulate an MPLS packet containing
only a bottom label. The encapsulation header would have the address
of the egress PE in its destination IP address field, and this would
cause the packet to be delivered to the egress PE.
In this procedure, the ingress and egress PEs themselves must support
MPLS, but that is not an issue, as those routers must necessarily
have MPLS PW support [LDP-CONTROL], whereas the transit routers
arguably should be able to be "vanilla" routers with no special MPLS
or PW support.
5.2. IPsec Authentication and/or Encryption for Security
An IPsec security association, as the PSN, enables MPLS PW packets to
be carried securely over non-MPLS networks. An IP/IPsec encapsulation
replaces the upper MPLS labels, required when the PSN is MPLS. MPLS
PW packets can be protected using standard IPsec authentication
and/or encryption functions. The payload of the IPsec encapsulation
is an authenticated and/or encrypted MPLS packet with a single PW
label.
draft-raggarwa-pwe3-pw-over-ip-00.txt [Page 3]
Internet Draft draft-raggarwa-pwe3-pw-over-ip-00.txt October 2003
5.2.1. Protection Against Spoofed Packets
The use of IPsec as a PSN tunnel protects the PW against spoofed
packets in an easier manner compared to an IP or GRE PSN tunnel.
It should be noted that if the upper MPLS labels are replaced with an
unsecured IP encapsulation, like GRE or IP, it becomes more difficult
to protect the PWs 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 filtering out packets from
"outside" which are addressed to PE routers, or filtering out packets
from "outside" which have source addresses that belong "inside" and
filtering on each PE all packets which have source addresses that
belong "outside". 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.
Furthermore, these filtering techniques may be difficult to apply in
the case of multi-provider PWs, because in multi-provider PWs packets
from outside an SP's network can legitimately be addressed to its PE
routers.
If on the other hand, the upper MPLS labes are 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 PW that were not generated by a valid ingress PE for that
PW. Thus spoofing protection is managed entirely at the ingress and
egress PE routers, transparently to the border routers. The tradeoff
is the management and performance implications associated with the
use of IPsec.
5.2.2. Protection Against Transit Node Misbehavior
Cryptographic authentication applied by the ingress PE on MPLS PW
packets destined to an egress PE can protect in the event of
misrouting or modification of packets by transit nodes. The
authentication check at the egress PE will fail if the PW packets are
routed to the incorrect egress PE or are modified in transit.
draft-raggarwa-pwe3-pw-over-ip-00.txt [Page 4]
Internet Draft draft-raggarwa-pwe3-pw-over-ip-00.txt October 2003
5.2.3. Encryption of the PW Data
If a service provider's PSN uses a non-trusted network, IPsec data
encryption may be used to encrypt the payload. This can help in
providing privacy for PW data in some cases.
6. Specification
In short, the technical approach specified here is:
1. Continue to use MPLS to identify a PW, by continuing to add an
MPLS label stack to the PW packets. However, the label stack will
carry only one label, the current "bottom label."
2. An MPLS-in-GRE, or MPLS-in-IP [mpls-over-ip-gre] encapsulation
will be used to turn the above MPLS packet back into an IP packet.
This in effect creates an IP or GRE tunnel between the ingress PE
router and the egress PE router. The net effect is that an MPLS
packet gets sent through an IP or GRE tunnel.
3. If IPsec is desired the IPsec Transport Mode can be used to secure
the above-mentioned IP tunnels. In that case a MPLS PW packet gets
sent through an IPsec secured IP or GRE tunnel. An alternative is to
secure the MPLS PW packet directly using IPsec, without encapsulating
it in IP or GRE. This is for further study.
6.1. MPLS-in-IP/MPLS-in-GRE Encapsulation by Ingress PE
When a PE receives a packet from a CE, it determines the incoming
interface and if needed, looks up the packet's destination layer 2
address. This enables it to find a PW "route". The PW route will have
an associated MPLS label and an associated Next Hop. The label is
pushed on the packet. Then an IP (or IP+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 PW endpoint. This will be an 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.)
The effect is to dynamically create an IP or GRE tunnel between the
ingress and egress PE routers. No apriori configuration of the remote
draft-raggarwa-pwe3-pw-over-ip-00.txt [Page 5]
Internet Draft draft-raggarwa-pwe3-pw-over-ip-00.txt October 2003
tunnel endpoints is needed. Note that these tunnels are NOT IGP-
visible links, and routing adjacencies are not supported across these
tunnel. Note also that the set of remote tunnel endpoints may not be
known in advance, but is learned dynamically during PW signaling or
auto-discovery.
The above procedure is sufficient if the PSN tunnel is IP or GRE. If
the PE-PE PSN tunnel is using IPsec, the IP tunnelled packets will be
associated with an IPsec Security Association (SA) and transported
using IPsec transport mode.
This is descrbed in detail in the next section.
6.2. Application of IPsec by the Ingress PE
A given ingress PE needs to have an IPsec SA with each PE router with
which it maintains a PW. The set of egress PEs for a given ingress PE
may not be known in advance. It may be determined using a PW endpoint
auto-discovery procedure. 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.
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 6.1, the PE router creates an MPLS-in-IP or
MPLS-in-GRE encapsulated packet. It then delivers the packet to the
IPsec module. 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 IP or GRE
encapsulation 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. It is to be noted that it may be
possible to avoid encapulating the MPLS PW packet in IP or GRE,
before applying the IPsec encapsulation. This is for further study.
draft-raggarwa-pwe3-pw-over-ip-00.txt [Page 6]
Internet Draft draft-raggarwa-pwe3-pw-over-ip-00.txt October 2003
6.3. Application of IPsec by the Egress PE
We assume that every egress PE is also an ingress PE, and hence has
the IPsec module which is mentioned in section 6.2. This module will
handle the necessary IKE functions, SA and tunnel maintenance, 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.
It is to be noted that if a) A MPLS PW packet is received by an
egress PE, with no IPsec encapsulation and b) An IPsec encapsulation
was expected by the egress PE for that MPLS PW, the packet should be
discarded. How this is achieved depends on the implementation.
6.4. MPLS-in-IP/MPLS-in-GRE Decapsulation by Egress PE
We assume that every egress PE is also an ingress PE, and hence has
the ability to decapsulate MPLS-in-IP (or MPLS-in-GRE) packets.
After decapsulation, the packets should be delivered to the routing
function for ordinary MPLS switching.
6.5. IPsec Security Policy Selection and Distribution
It may be desirable to use IPsec selectively. For example IPsec
encapsulation may be desired only for inter-provider tunnels or for
tunnels to certain PEs or for certain PWs etc. This may require auto-
discovery of whether a PW endpoint desires to use IPsec for a given
PW. How this is done is beyond the scope of this document.
7. Security Considerations
Some of the security issues are discussed in the section 5. Rest of
the security considerations are for further study.
draft-raggarwa-pwe3-pw-over-ip-00.txt [Page 7]
Internet Draft draft-raggarwa-pwe3-pw-over-ip-00.txt October 2003
8. Acknowledgments
Lot of the text in this document is written using [2547GRE,
2547IPsec] We would like to thank the authors of these documents. We
would also like to thank Dave McDysan, Juzer Kopti and Erik Sherk for
their comments.
9. References
[LDP-CONTROL] "Pseudowire Setup and Maintenance using LDP", Martini L.,
El-Aawar N., Rosen E., draft-ietf-pwe3-control-protocol-03.txt
[PWARCH] "PWE3 Architecture", Bryant S., Pate P.,
draft-ietf-pwe3-arch-04.txt
[PWREQ] "Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)",
Xiao X., McPherson D., Pate P., draft-ietf-pwe3-requirements-06.txt
[mpls-over-ip-gre] "Encapsulating MPLS in IP or GRE", T. Worster,
Rekhter Y., Rosen E., draft-ietf-mpls-in-ip-or-gre-01.txt
[2547GRE] "Use of PE-PE GRE or IP in RFC2547 VPNs", Yakov Rekhter,
Eric Rosen, draft-ietf-l3vpn-gre-ip-2547-00.txt
[2547IPsec] "Use of PE-PE IPsec in RFC2547 VPNs", Rosen E., De Clercq
J., Pridaens O., T'Joens Y., Sargor C.,
draft-ietf-l3vpn-ipsec-2547-03.txt
10. Author Information
Rahul Aggarwal
Juniper Networks
1194 North Mathilda Ave.
Sunnyvale, CA 94089
Email: rahul@juniper.net
Kireeti Kompella
Juniper Networks
1194 North Mathilda Ave.
Sunnyvale, CA 94089
Email: kireeti@juniper.net
draft-raggarwa-pwe3-pw-over-ip-00.txt [Page 8]