draft-ietf-mpls-over-l2tpv3-03.txt   rfc4817.txt 
Network Working Group M. Townsley Network Working Group M. Townsley
Internet-Draft C. Pignataro Request for Comments: 4817 C. Pignataro
Expiration Date: May 2007 S. Wainner Category: Standards Track S. Wainner
cisco Systems Cisco Systems
T. Seely T. Seely
Sprint Nextel Sprint Nextel
J. Young J. Young
November 2006
Encapsulation of MPLS over Layer 2 Tunneling Protocol Version 3 Encapsulation of MPLS over Layer 2 Tunneling Protocol Version 3
draft-ietf-mpls-over-l2tpv3-03.txt Status of This Memo
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 This document specifies an Internet standards track protocol for the
and may be updated, replaced, or obsoleted by other documents at any Internet community, and requests discussion and suggestions for
time. It is inappropriate to use Internet-Drafts as reference improvements. Please refer to the current edition of the "Internet
material or to cite them other than as "work in progress." Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The IETF Trust (2007).
http://www.ietf.org/shadow.html
Abstract Abstract
The Layer 2 Tunneling Protocol, Version 3, (L2TPv3) defines a The Layer 2 Tunneling Protocol, Version 3 (L2TPv3) defines a protocol
protocol for tunneling a variety of payload types over IP networks. for tunneling a variety of payload types over IP networks. This
This document defines how to carry an MPLS label stack and its document defines how to carry an MPLS label stack and its payload
payload over the L2TPv3 data encapsulation. This enables an over the L2TPv3 data encapsulation. This enables an application that
application which traditionally requires an MPLS-enabled core network traditionally requires an MPLS-enabled core network, to utilize an
to utilize an L2TPv3 encapsulation over an IP network instead. L2TPv3 encapsulation over an IP network instead.
Contents
Status of this Memo.......................................... 1
1. Introduction.............................................. 2
2. MPLS over L2TPv3 Encoding................................. 3
3. Assigning the L2TPv3 Session ID and Cookie................ 4
4. Applicability............................................. 4
5. Congestion Considerations................................. 6
6. Security Considerations................................... 6
6.1 In the Absence of IPsec............................... 7
6.2 Context Validation.................................... 7
6.3 Securing the Tunnel with IPsec........................ 8
7. IANA Considerations....................................... 9 Table of Contents
8. Acknowledgements.......................................... 9 1. Introduction ....................................................2
1.1. Specification of Requirements ..............................2
2. MPLS over L2TPv3 Encoding .......................................2
3. Assigning the L2TPv3 Session ID and Cookie ......................4
4. Applicability ...................................................4
5. Congestion Considerations .......................................6
6. Security Considerations .........................................6
6.1. In the Absence of IPsec ....................................7
6.2. Context Validation .........................................7
6.3. Securing the Tunnel with IPsec .............................8
7. Acknowledgements ................................................9
8. References .....................................................10
8.1. Normative References ......................................10
8.2. Informative References ....................................10
9. References................................................ 9 1. Introduction
9.1 Normative References.................................. 9
9.2 Informative References................................ 9
10. Authors' Addresses....................................... 11 This document defines how to encapsulate an MPLS label stack and its
payload inside the L2TPv3 tunnel payload. After defining the MPLS
over L2TPv3 encapsulation procedure, other MPLS over IP encapsulation
options, including IP, Generic Routing Encapsulation (GRE), and IPsec
are discussed in context with MPLS over L2TPv3 in an Applicability
section. This document only describes encapsulation and does not
concern itself with all possible MPLS-based applications that may be
enabled over L2TPv3.
Specification of Requirements 1.1. Specification of Requirements
In this document, several words are used to signify the requirements In this document, several words are used to signify the requirements
of the specification. These words are often capitalized. The key of the specification. These words are often capitalized. The key
words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
are to be interpreted as described in [RFC2119]. are to be interpreted as described in [RFC2119].
1. Introduction
This document defines how to encapsulate an MPLS label stack and its
payload inside the L2TPv3 tunnel payload. After defining the MPLS
over L2TPv3 encapsulation procedure, other MPLS over IP encapsulation
options including IP, GRE and IPsec are discussed in context with
MPLS over L2TPv3 in an Applicability section. This document only
describes encapsulation and does not concern itself with all possible
MPLS-based applications which may be enabled over L2TPv3.
2. MPLS over L2TPv3 Encoding 2. MPLS over L2TPv3 Encoding
MPLS over L2TPv3 allows tunneling of an MPLS stack [RFC3032] and its MPLS over L2TPv3 allows tunneling of an MPLS stack [RFC3032] and its
payload over an IP network utilizing the L2TPv3 encapsulation defined payload over an IP network, utilizing the L2TPv3 encapsulation
in [RFC3931]. The MPLS Label Stack and payload are carried in their defined in [RFC3931]. The MPLS Label Stack and payload are carried
entirety following IP (either IPv4 or IPv6) and L2TPv3 headers. in their entirety following IP (either IPv4 or IPv6) and L2TPv3
headers.
+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+
| IP | | IP |
+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+
| L2TPv3 | | L2TPv3 |
+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+
| MPLS Label Stack | | MPLS Label Stack |
+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+
| MPLS Payload | | MPLS Payload |
+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+
skipping to change at page 3, line 42 skipping to change at page 3, line 35
| Cookie (optional, maximum 64 bits)... | Cookie (optional, maximum 64 bits)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label
| Label | Exp |S| TTL | Stack | Label | Exp |S| TTL | Stack
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry
Figure 2.2 MPLS over L2TPv3 encapsulation Figure 2.2 MPLS over L2TPv3 encapsulation
When encapsulating MPLS over L2TPv3, the L2TPv3 L2-Specific Sublayer When encapsulating MPLS over L2TPv3, the L2TPv3 L2-Specific Sublayer
MAY be present. It is generally not present and hence not included MAY be present. It is generally not present; hence, it is not
in Figure 2.2. The L2TPv3 Session ID MUST be present. The Cookie MAY included in Figure 2.2. The L2TPv3 Session ID MUST be present. The
be present. Cookie MAY be present.
Session ID Session ID
The L2TPv3 Session ID is a 32-bit identifier field locally The L2TPv3 Session ID is a 32-bit identifier field locally
selected as a lookup key for the context of an L2TP Session. An selected as a lookup key for the context of an L2TP Session. An
L2TP Session contains necessary context for processing a received L2TP Session contains necessary context for processing a received
L2TP packet. At a minimum, such context contains whether the L2TP packet. At a minimum, such context contains whether the
Cookie (see description below) is present, the value it was Cookie (see description below) is present, the value it was
assigned, the presence and type of an L2TPv3 L2-Specific Sublayer, assigned, the presence and type of an L2TPv3 L2-Specific Sublayer,
as well as what type of tunneled encapsulation follows (i.e., as well as what type of tunneled encapsulation follows (i.e.,
skipping to change at page 4, line 7 skipping to change at page 4, line 4
Session ID Session ID
The L2TPv3 Session ID is a 32-bit identifier field locally The L2TPv3 Session ID is a 32-bit identifier field locally
selected as a lookup key for the context of an L2TP Session. An selected as a lookup key for the context of an L2TP Session. An
L2TP Session contains necessary context for processing a received L2TP Session contains necessary context for processing a received
L2TP packet. At a minimum, such context contains whether the L2TP packet. At a minimum, such context contains whether the
Cookie (see description below) is present, the value it was Cookie (see description below) is present, the value it was
assigned, the presence and type of an L2TPv3 L2-Specific Sublayer, assigned, the presence and type of an L2TPv3 L2-Specific Sublayer,
as well as what type of tunneled encapsulation follows (i.e., as well as what type of tunneled encapsulation follows (i.e.,
Frame Relay, Ethernet, MPLS, etc.) Frame Relay, Ethernet, MPLS, etc.)
Cookie Cookie
The L2TPv3 Cookie field contains a variable length (maximum 64 The L2TPv3 Cookie field contains a variable-length (maximum 64
bits) randomly assigned value. It is intended to provide an bits), randomly assigned value. It is intended to provide an
additional level of guarantee that a data packet has been directed additional level of guarantee that a data packet has been directed
to the proper L2TP session by the Session ID. While the Session to the proper L2TP session by the Session ID. While the Session
ID may be encoded and assigned any value (perhaps optimizing for ID may be encoded and assigned any value (perhaps optimizing for
local lookup capabilities, redirection in a distributed forwarding local lookup capabilities, redirection in a distributed forwarding
architecture, etc.), the Cookie MUST be selected as a architecture, etc.), the Cookie MUST be selected as a
cryptographically random value [RFC4086], with the added cryptographically random value [RFC4086], with the added
restriction that it not be the same as a recently used value for a restriction that it not be the same as a recently used value for a
given Session ID. A well-chosen Cookie will prevent inadvertent given Session ID. A well-chosen Cookie will prevent inadvertent
misdirection of a stray packet containing a recently reused misdirection of a stray packet containing a recently reused
Session ID, a Session ID that is subject to packet corruption, and Session ID, a Session ID that is subject to packet corruption, and
protection against some specific malicious packet insertion protection against some specific malicious packet insertion
attacks as described in more detail in Section 4 of this document. attacks, as described in more detail in Section 4 of this
document.
Label Stack Entry Label Stack Entry
An MPLS label stack entry as defined in [RFC3032]. An MPLS label stack entry as defined in [RFC3032].
The optional L2-Specific Sublayer defined in [RFC3931] is generally The optional L2-Specific Sublayer (defined in [RFC3931]) is generally
not present for MPLS over L2TPv3. not present for MPLS over L2TPv3.
Generic IP encapsulation procedures such as fragmentation and MTU Generic IP encapsulation procedures, such as fragmentation and MTU
considerations, handling of TTL, EXP and DSCP bits, etc. are the same considerations, handling of Time to Live (TTL), EXP, and
as the "Common Procedures" for IP encapsulation of MPLS defined in Differentiated Services Code Point (DSCP) bits, etc. are the same as
the "Common Procedures" for IP encapsulation of MPLS defined in
Section 5 of [RFC4023] and are not reiterated here. Section 5 of [RFC4023] and are not reiterated here.
3. Assigning the L2TPv3 Session ID and Cookie 3. Assigning the L2TPv3 Session ID and Cookie
Much like an MPLS label, the L2TPv3 Session ID and Cookie must be Much like an MPLS label, the L2TPv3 Session ID and Cookie must be
selected and exchanged between participating nodes before L2TPv3 can selected and exchanged between participating nodes before L2TPv3 can
operate. These values may be configured manually, or distributed via operate. These values may be configured manually, or distributed via
a signaling protocol. This document concerns itself only with the a signaling protocol. This document concerns itself only with the
encapsulation of MPLS over L2TPv3, thus the particular method of encapsulation of MPLS over L2TPv3; thus, the particular method of
assigning the Session ID and Cookie (if present) is out of scope. assigning the Session ID and Cookie (if present) is out of scope.
4. Applicability 4. Applicability
The methods defined [RFC4023], [MPLS-IPSEC] and this document all The methods defined in [RFC4023], [MPLS-IPSEC], and this document all
describe methods for carrying MPLS over an IP network. Cases where describe methods for carrying MPLS over an IP network. Cases where
MPLS over L2TPv3 is comparable to other alternatives are discussed in MPLS over L2TPv3 is comparable to other alternatives are discussed in
this section. this section.
It is generally simpler to have one's border routers refuse to accept It is generally simpler to have one's border routers refuse to accept
an MPLS packet than to configure a router to refuse to accept certain an MPLS packet than to configure a router to refuse to accept certain
MPLS packets carried in IP or GRE to or from certain IP sources or MPLS packets carried in IP or GRE to or from certain IP sources or
destinations. Thus, the use of IP or GRE to carry MPLS packets destinations. Thus, the use of IP or GRE to carry MPLS packets
increases the likelihood that an MPLS label spoofing attack will increases the likelihood that an MPLS label-spoofing attack will
succeed. L2TPv3 provides an additional level of protection against succeed. L2TPv3 provides an additional level of protection against
packet spoofing before allowing a packet to enter a VPN (much like packet spoofing before allowing a packet to enter a Virtual Private
IPsec provides an additional level of protection at a Provider Edge Network (VPN) (much like IPsec provides an additional level of
(PE) router rather than relying on Access Control List (ACL) protection at a Provider Edge (PE) router rather than relying on
filters). Checking the value of the L2TPv3 Cookie is similar to any Access Control List (ACL) filters). Checking the value of the L2TPv3
sort of ACL which inspects the contents of a packet header, except Cookie is similar to any sort of ACL that inspects the contents of a
that we give ourselves the luxury of "seeding" the L2TPv3 header with packet header, except that we give ourselves the luxury of "seeding"
a value that is very difficult to spoof. the L2TPv3 header with a value that is very difficult to spoof.
MPLS over L2TPv3 may be advantageous compared to [RFC4023], if: MPLS over L2TPv3 may be advantageous compared to [RFC4023], if:
Two routers are already "adjacent" over an L2TPv3 tunnel Two routers are already "adjacent" over an L2TPv3 tunnel
established for some other reason, and wish to exchange MPLS established for some other reason, and wish to exchange MPLS
packets over that adjacency. packets over that adjacency.
Implementation considerations dictate the use of MPLS over L2TPv3. Implementation considerations dictate the use of MPLS over L2TPv3.
For example, a hardware device may be able to take advantage of For example, a hardware device may be able to take advantage of
the L2TPv3 encapsulation for faster or distributed processing. the L2TPv3 encapsulation for faster or distributed processing.
Packet spoofing and insertion, service integrity and resource Packet spoofing and insertion, service integrity and resource
protection are of concern, especially given the fact that an IP protection are of concern, especially given the fact that an IP
tunnel potentially exposes the router to rogue or inappropriate IP tunnel potentially exposes the router to rogue or inappropriate IP
packets from unknown or untrusted sources. IP Access Control packets from unknown or untrusted sources. IP Access Control
Lists (ACLs) and numbering methods may be used to protect the Lists (ACLs) and numbering methods may be used to protect the PE
Provider Edge (PE) routers from rogue IP sources, but may be routers from rogue IP sources, but may be subject to error and
subject to error and cumbersome to maintain at all edge points at cumbersome to maintain at all edge points at all times. The
all times. The L2TPv3 Cookie provides a simple means of L2TPv3 Cookie provides a simple means of validating the source of
validating the source of an L2TPv3 packet before allowing an L2TPv3 packet before allowing processing to continue. This
processing to continue. This validation offers an additional level validation offers an additional level of protection over and above
of protection over and above IP ACLs, and a validation that the IP ACLs, and a validation that the Session ID was not corrupted in
Session ID was not corrupted in transit or suffered an internal transit or suffered an internal lookup error upon receipt and
lookup error upon receipt and processing. If the Cookie value is processing. If the Cookie value is assigned and distributed
assigned and distributed automatically, it is less subject to automatically, it is less subject to operator error, and if
operator error, and if selected in a cryptographically random selected in a cryptographically random nature, less subject to
nature, less subject to blind guesses than source IP addresses (in blind guesses than source IP addresses (in the event that a hacker
the event that a hacker can insert packets within a VPN core can insert packets within a core network).
network).
(The first two of the above applicability statements were adopted (The first two of the above applicability statements were adopted
from [RFC4023]) from [RFC4023].)
In summary, L2TPv3 can provide a balance between the limited security In summary, L2TPv3 can provide a balance between the limited security
against IP spoofing attacks offered by [RFC4023] vs. the greater against IP spoofing attacks offered by [RFC4023] vs. the greater
security and associated operational and processing overhead offered security and associated operational and processing overhead offered
by [MPLS-IPSEC]. Further, MPLS over L2TPv3 may be faster in some by [MPLS-IPSEC]. Further, MPLS over L2TPv3 may be faster in some
hardware, particularly if that hardware is already optimized to hardware, particularly if that hardware is already optimized to
classify incoming L2TPv3 packets carrying IP framed in a variety of classify incoming L2TPv3 packets carrying IP framed in a variety of
ways. For example, IP encapsulated by HDLC or Frame Relay over L2TPv3 ways. For example, IP encapsulated by High-Level Data Link Control
may be equivalent in complexity to IP encapsulated by MPLS over (HDLC) or Frame Relay over L2TPv3 may be equivalent in complexity to
L2TPv3. IP encapsulated by MPLS over L2TPv3.
5. Congestion Considerations 5. Congestion Considerations
This document specifies an encapsulation method for MPLS inside the This document specifies an encapsulation method for MPLS inside the
L2TPv3 tunnel payload. MPLS can carry a number of different protocols L2TPv3 tunnel payload. MPLS can carry a number of different
as payloads. When an MPLS/L2TPv3 flow carries IP-based traffic, the protocols as payloads. When an MPLS/L2TPv3 flow carries IP-based
aggregate traffic is assumed to be TCP friendly due to the congestion traffic, the aggregate traffic is assumed to be TCP friendly due to
control mechanisms used by the payload traffic. Packet loss will the congestion control mechanisms used by the payload traffic.
trigger the necessary reduction in offered load, and no additional Packet loss will trigger the necessary reduction in offered load, and
congestion avoidance action is necessary. no additional congestion avoidance action is necessary.
When an MPLS/L2TPv3 flow carries payload traffic that is not known to When an MPLS/L2TPv3 flow carries payload traffic that is not known to
be TCP friendly and the flow runs across an unprovisioned path that be TCP friendly and the flow runs across an unprovisioned path that
could potentially become congested, the application that uses the could potentially become congested, the application that uses the
encapsulation specified in this document MUST employ additional encapsulation specified in this document MUST employ additional
mechanisms to ensure that the offered load is reduced appropriately mechanisms to ensure that the offered load is reduced appropriately
during periods of congestion. The MPLS/L2TPv3 flow should not exceed during periods of congestion. The MPLS/L2TPv3 flow should not exceed
the average bandwidth that a TCP flow across the same network path the average bandwidth that a TCP flow across the same network path
and experiencing the same network conditions would achieve, measured and experiencing the same network conditions would achieve, measured
on a reasonable timescale. This is not necessary in the case of an on a reasonable timescale. This is not necessary in the case of an
unprovisioned path through an overprovisioned network, where the unprovisioned path through an over-provisioned network, where the
potential for congestion is avoided through the overprovisioning of potential for congestion is avoided through the over-provisioning of
the network. the network.
The comparison to TCP cannot be specified exactly but is intended as The comparison to TCP cannot be specified exactly but is intended as
an "order-of-magnitude" comparison in timescale and throughput. The an "order-of-magnitude" comparison in timescale and throughput. The
timescale on which TCP throughput is measured is the round-trip time timescale on which TCP throughput is measured is the roundtrip time
of the connection. In essence, this requirement states that it is not of the connection. In essence, this requirement states that it is
acceptable to deploy an application using the encapsulation specified not acceptable to deploy an application using the encapsulation
in this document on the best-effort Internet, which consumes specified in this document on the best-effort Internet, which
bandwidth arbitrarily and does not compete fairly with TCP within an consumes bandwidth arbitrarily and does not compete fairly with TCP
order of magnitude. One method of determining an acceptable bandwidth within an order of magnitude. One method of determining an
is described in [RFC3448]. Other methods exist, but are outside the acceptable bandwidth is described in [RFC3448]. Other methods exist,
scope of this document. but are outside the scope of this document.
6. Security Considerations 6. Security Considerations
There are three main concerns when transporting MPLS labeled traffic There are three main concerns when transporting MPLS-labeled traffic
between PEs using IP tunnels. The first is the possibility that a between PEs using IP tunnels. The first is the possibility that a
third party may insert packets into a packet stream between two PEs. third party may insert packets into a packet stream between two PEs.
The second is that a third party might view the packet stream between The second is that a third party might view the packet stream between
two PEs. The third is that a third party may alter packets in a two PEs. The third is that a third party may alter packets in a
stream between two PEs. The security requirements of the stream between two PEs. The security requirements of the
applications whose traffic is being sent through the tunnel applications whose traffic is being sent through the tunnel
characterizes how significant these issues are. Operators may use characterizes how significant these issues are. Operators may use
multiple methods to mitigate the risk including access lists, multiple methods to mitigate the risk, including access lists,
authentication, encryption, and context validation. Operators should authentication, encryption, and context validation. Operators should
consider the cost to mitigate the risk. consider the cost to mitigate the risk.
Security is also discussed as part of the applicability discussion in Security is also discussed as part of the applicability discussion in
section 4 of this document. Section 4 of this document.
6.1 In the Absence of IPsec 6.1. In the Absence of IPsec
If the tunnels are not secured with IPsec, then some other method If the tunnels are not secured with IPsec, then some other method
should be used to ensure that packets are decapsulated and processed should be used to ensure that packets are decapsulated and processed
by the tunnel tail only if those packets were encapsulated by the by the tunnel tail only if those packets were encapsulated by the
tunnel head. If the tunnel lies entirely within a single tunnel head. If the tunnel lies entirely within a single
administrative domain, address filtering at the boundaries can be administrative domain, address filtering at the boundaries can be
used to ensure that no packet with the IP source address of a tunnel used to ensure that no packet with the IP source address of a tunnel
endpoint or with the IP destination address of a tunnel endpoint can endpoint or with the IP destination address of a tunnel endpoint can
enter the domain from outside. enter the domain from outside.
However, when the tunnel head and the tunnel tail are not in the same However, when the tunnel head and the tunnel tail are not in the same
administrative domain, this may become difficult, and filtering based administrative domain, this may become difficult, and filtering based
on the destination address can even become impossible if the packets on the destination address can even become impossible if the packets
must traverse the public Internet. must traverse the public Internet.
Sometimes only source address filtering (but not destination address Sometimes, only source address filtering (but not destination address
filtering) is done at the boundaries of an administrative domain. If filtering) is done at the boundaries of an administrative domain. If
this is the case, the filtering does not provide effective protection this is the case, the filtering does not provide effective protection
at all unless the decapsulator of MPLS over L2TPv3 validates the IP at all unless the decapsulator of MPLS over L2TPv3 validates the IP
source address of the packet. source address of the packet.
Additionally, the "Data Packet Spoofing" considerations in Section Additionally, the "Data Packet Spoofing" considerations in Section
8.2. of [RFC3931] and the "Context Validation" considerations in 8.2 of [RFC3931] and the "Context Validation" considerations in
Section 5.2 of this document apply. Those two sections highlight the Section 6.2 of this document apply. Those two sections highlight the
benefits of the L2TPv3 Cookie. benefits of the L2TPv3 Cookie.
6.2 Context Validation 6.2. Context Validation
The L2TPv3 Cookie does not provide protection via encryption. The L2TPv3 Cookie does not provide protection via encryption.
However, when used with a sufficiently random 64-bit value which is However, when used with a sufficiently random, 64-bit value that is
kept secret from an off-path attacker, the L2TPv3 Cookie may be used kept secret from an off-path attacker, the L2TPv3 Cookie may be used
as a simple yet effective packet source authentication check which is as a simple yet effective packet source authentication check which is
quite resistant to brute force packet spoofing attacks. It also quite resistant to brute force packet-spoofing attacks. It also
alleviates the need to rely solely on filter lists based on a list of alleviates the need to rely solely on filter lists based on a list of
valid source IP addresses, and thwarts attacks which could benefit by valid source IP addresses, and thwarts attacks that could benefit by
spoofing a permitted source IP address. The L2TPv3 Cookie provides a spoofing a permitted source IP address. The L2TPv3 Cookie provides a
means of validating the currently assigned Session ID on the packet means of validating the currently assigned Session ID on the packet
flow, providing context protection, and may be deemed complimentary flow, providing context protection, and may be deemed complimentary
to securing the tunnel utilizing IPsec. In the absence of to securing the tunnel utilizing IPsec. In the absence of
cryptographic security on the data plane (such as that provided by cryptographic security on the data plane (such as that provided by
IPsec), the L2TPv3 Cookie provides a simple method of validating the IPsec), the L2TPv3 Cookie provides a simple method of validating the
Session ID lookup performed on each L2TPv3 packet. If the Cookie is Session ID lookup performed on each L2TPv3 packet. If the Cookie is
sufficiently random and remains unknown to an attacker (that is, the sufficiently random and remains unknown to an attacker (that is, the
attacker has no way to predict Cookie values or monitor traffic attacker has no way to predict Cookie values or monitor traffic
between PEs) then the Cookie provides an additional measure of between PEs), then the Cookie provides an additional measure of
protection against malicious spoofed packets inserted at the PE over protection against malicious spoofed packets inserted at the PE over
and above that of typical IP address and port ACLs. and above that of typical IP address and port ACLs.
6.3 Securing the Tunnel with IPsec 6.3. Securing the Tunnel with IPsec
L2TPv3 tunnels may also be secured using IPsec, as specified in L2TPv3 tunnels may also be secured using IPsec, as specified in
Section 4.1.3. of [RFC3931]. IPSec may provide authentication, Section 4.1.3 of [RFC3931]. IPSec may provide authentication,
privacy protection, integrity checking and replay protection. These privacy protection, integrity checking, and replay protection. These
functions may be deemed necessary by the operator. When using IPsec, functions may be deemed necessary by the operator. When using IPsec,
the tunnel head and the tunnel tail should be treated as the the tunnel head and the tunnel tail should be treated as the
endpoints of a Security Association. A single IP address of the endpoints of a Security Association. A single IP address of the
tunnel head is used as the source IP address, and a single IP address tunnel head is used as the source IP address, and a single IP address
of the tunnel tail is used as the destination IP address. The means of the tunnel tail is used as the destination IP address. The means
by which each node knows the proper address of the other is outside by which each node knows the proper address of the other is outside
the scope of this document. However, if a control protocol is used the scope of this document. However, if a control protocol is used
to set up the tunnels, such control protocol MUST have an to set up the tunnels, such control protocol MUST have an
authentication mechanism, and this MUST be used when the tunnel is authentication mechanism, and this MUST be used when the tunnel is
set up. If the tunnel is set up automatically as the result of, for set up. If the tunnel is set up automatically as the result of, for
example, information distributed by BGP, then the use of BGP's MD5- example, information distributed by BGP, then the use of BGP's
based authentication mechanism can serve this purpose. Message Digest 5 (MD5)-based authentication mechanism can serve this
purpose.
The MPLS over L2TPv3 encapsulated packets should be considered as The MPLS over L2TPv3 encapsulated packets should be considered as
originating at the tunnel head and as being destined for the tunnel originating at the tunnel head and being destined for the tunnel
tail; IPsec transport mode SHOULD thus be used. tail; IPsec transport mode SHOULD thus be used.
Note that the tunnel tail and the tunnel head are LSP adjacencies Note that the tunnel tail and the tunnel head are Label Switched Path
(label distribution adjacencies, see [RFC3031]), which means that the (LSP) adjacencies (for label distribution adjacencies, see
topmost label of any packet sent through the tunnel must be one that [RFC3031]), which means that the topmost label of any packet sent
was distributed by the tunnel tail to the tunnel head. The tunnel through the tunnel must be one that was distributed by the tunnel
tail MUST know precisely which labels it has distributed to the tail to the tunnel head. The tunnel tail MUST know precisely which
tunnel heads of IPsec-secured tunnels. Labels in this set MUST NOT labels it has distributed to the tunnel heads of IPsec-secured
be distributed by the tunnel tail to any LSP adjacencies other than tunnels. Labels in this set MUST NOT be distributed by the tunnel
those that are tunnel heads of IPsec-secured tunnels. If an MPLS tail to any LSP adjacencies other than those that are tunnel heads of
packet is received without an IPsec encapsulation, and if its topmost IPsec-secured tunnels. If an MPLS packet is received without an
label is in this set, then the packet MUST be discarded. IPsec encapsulation, and if its topmost label is in this set, then
the packet MUST be discarded.
Securing L2TPv3 using IPsec MUST provide authentication and Securing L2TPv3 using IPsec MUST provide authentication and
integrity. (Note that the authentication and integrity provided will integrity. (Note that the authentication and integrity provided will
apply to the entire MPLS packet, including the MPLS label stack.) apply to the entire MPLS packet, including the MPLS label stack.)
Consequently, the implementation MUST support ESP with null
encryption. ESP with encryption MAY be supported if a source Consequently, the implementation MUST support Encapsulating Security
requires confidentiality. If ESP is used, the tunnel tail MUST check Payload (ESP) with null encryption. ESP with encryption MAY be
that the source IP address of any packet received on a given SA is supported if a source requires confidentiality. If ESP is used, the
the one expected. tunnel tail MUST check that the source IP address of any packet
received on a given Security Association (SA) is the one expected.
Key distribution may be done either manually or automatically by Key distribution may be done either manually or automatically by
means of IKE [RFC2409] or IKEv2 [RFC4306]. Manual keying MUST be means of the Internet Key Exchange (IKE) Protocol [RFC2409] or IKEv2
supported. If automatic keying is implemented, IKE in main mode with [RFC4306]. Manual keying MUST be supported. If automatic keying is
preshared keys MUST be supported. A particular application may implemented, IKE in main mode with preshared keys MUST be supported.
escalate this requirement and request implementation of automatic A particular application may escalate this requirement and request
keying. Manual key distribution is much simpler, but also less implementation of automatic keying. Manual key distribution is much
scalable, than automatic key distribution. If replay protection is simpler, but also less scalable, than automatic key distribution. If
regarded as necessary for a particular tunnel, automatic key replay protection is regarded as necessary for a particular tunnel,
distribution should be configured. automatic key distribution should be configured.
7. IANA Considerations 7. Acknowledgements
There are no IANA considerations for this document. Thanks to Robert Raszuk, Clarence Filsfils, and Eric Rosen for their
review of this document. Some text was adopted from [RFC4023].
8. Acknowledgements 8. References
Thanks to Robert Raszuk, Clarence Filsfils and Eric Rosen for their 8.1. Normative References
review of this document. Some text was adopted from [RFC4023].
9. References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
9.1 Normative References [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001.
[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two
Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931,
March 2005. March 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating
MPLS in IP or Generic Routing Encapsulation (GRE)", MPLS in IP or Generic Routing Encapsulation (GRE)", RFC
RFC 4023, March 2005. 4023, March 2005.
9.2 Informative References
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., [RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack "Randomness Requirements for Security", BCP 106, RFC
Encoding", RFC 3032, January 2001. 4086, June 2005.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 8.2. Informative References
Requirements for Security", BCP 106, RFC 4086,
June 2005.
[MPLS-IPSEC] Rosen, E., "Architecture for the Use of PE-PE IPsec [MPLS-IPSEC] Rosen, E., De Clercq, J., Paridaens, O., T'Joens, Y.,
Tunnels in BGP/MPLS IP VPNs", and C. Sargor, "Architecture for the Use of PE-PE IPsec
draft-ietf-l3vpn-ipsec-2547-05 (work in progress), Tunnels in BGP/MPLS IP VPNs", Work in Progress, August
August 2005. 2005.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, [RFC3031] Rosen, E., Viswanathan, A., and R. Callon,
"Multiprotocol Label Switching Architecture", RFC 3031, "Multiprotocol Label Switching Architecture", RFC 3031,
January 2001. January 2001.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998. (IKE)", RFC 2409, November 1998.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005. RFC 4306, December 2005.
[RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP [RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP
Friendly Rate Control (TFRC): Protocol Specification", Friendly Rate Control (TFRC): Protocol Specification",
RFC 3448, January 2003. RFC 3448, January 2003.
10. Authors' Addresses Authors' Addresses
W. Mark Townsley W. Mark Townsley
cisco Systems Cisco Systems
USA
Phone: +1-919-392-3741 Phone: +1-919-392-3741
EMail: mark@townsley.net EMail: mark@townsley.net
Carlos Pignataro Carlos Pignataro
cisco Systems Cisco Systems
7025 Kit Creek Road 7025 Kit Creek Road
PO Box 14987 PO Box 14987
Research Triangle Park, NC 27709 Research Triangle Park, NC 27709
USA
Phone: +1-919-392-7428 Phone: +1-919-392-7428
EMail: cpignata@cisco.com EMail: cpignata@cisco.com
Scott Wainner Scott Wainner
cisco Systems Cisco Systems
13600 Dulles Technology Drive 13600 Dulles Technology Drive
Herndon, VA 20171 Herndon, VA 20171
USA
EMail: swainner@cisco.com EMail: swainner@cisco.com
Ted Seely Ted Seely
Sprint Nextel Sprint Nextel
12502 Sunrise Valley Dr 12502 Sunrise Valley Drive
Reston, VA 20196 Reston, VA 20196
USA
Phone: +1-703-689-6425 Phone: +1-703-689-6425
EMail: tseely@sprint.net EMail: tseely@sprint.net
Jeff Young Jeff Young
EMail: young@jsyoung.net EMail: young@jsyoung.net
Intellectual Property Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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, THE IETF TRUST 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.
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 12, line 29 skipping to change at page 12, line 45
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 this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity Acknowledgement
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, THE
IETF TRUST 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.
Copyright Statement
Copyright (C) The IETF Trust (2006).
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 69 change blocks. 
218 lines changed or deleted 192 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/