Network Working Group David J. Smith
Internet Draft John Mullooly
Intended status: Proposed Standard Cisco Systems, Inc.
Expiration Date: December 2008
William Jaeger
Tom Scholl
AT&T
June 30, 2008
Requirements for Label Edge Router Forwarding of IPv4 Option Packets
draft-dasmith-mpls-ip-options-00.txt
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
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document imposes a new requirement on Label Edge Routers (LER)
specifying that when determining whether to MPLS encapsulate an IP
packet, the determination is made independent of any IP options that
may be carried in the IP packet header. Lack of a formal standard
may result in a different forwarding behavior for different IP
packets associated with the same prefix-based Forwarding Equivalence
Class (FEC). While an IP packet with either a specific option type
Smith, et al. [Page 1]
Internet Draft draft-dasmith-mpls-ip-options-00.txt June 2008
or no header option may follow the MPLS label switched path (LSP)
associated with a prefix-based FEC, an IP packet with a different
option type but associated with the same prefix-based FEC may bypass
MPLS encapsulation and instead be IP routed downstream. IP option
packets that inadvertently bypass MPLS encapsulation present an
increased security risk against the MPLS infrastructure.
Table of Contents
1 Specification of Requirements ...................... 2
2 Motivation ......................................... 2
3 Introduction ....................................... 3
4 Ingress Label Edge Router Requirement .............. 4
5 Security Considerations ............................ 5
5.1 IP Option Packets that Bypass MPLS Encapsulation ... 5
5.2 Router Alert Label Imposition ...................... 6
6 IANA Considerations ................................ 7
7 Conclusion ......................................... 7
8 Acknowledgements ................................... 7
9 Normative References ............................... 7
10 Informational References ........................... 8
11 Authors' Addresses ................................. 8
12 Full Copyright Statement ........................... 9
13 Intellectual Property .............................. 10
1.0 Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2.0 Motivation
This document is motivated by the need to formalize MPLS
encapsulation processing of IP packets with header options transiting
an MPLS network. We believe that this document adds details that
have not been fully addressed in [RFC3031] and [RFC3032], and that
the methods presented in this document update [RFC3031] as well as
complement [RFC3443] and [RFC4950].
Smith, et al. [Page 2]
Internet Draft draft-dasmith-mpls-ip-options-00.txt June 2008
3.0 Introduction
The IP packet header provides for various IP options as originally
specified in [RFC791]. IP header options are used to enable control
functions within the IP data forwarding plane that are required in
some specific situations but not necessary for most common IP
communications. Typical IP header options include provisions for
timestamps, security, and special routing. Example IP header options
& applications include but are not limited to:
o Strict & Loose Source Route Options: Used to IP route the IP
packet based on information supplied by the source.
o Record Route Option: Used to trace the route an IP packet takes.
o Router Alert Option: Indicates to downstream IP routers to
examine these IP packets more closely.
The list of current IP header options can be accessed at [IANA].
IP packets may or may not use IP header options (they are optional)
but IP header option handling mechanisms must be implemented by all
IP protocol stacks (hosts and routers). Each IP header option has
distinct header fields and lengths. IP options extend the IP packet
header length beyond the minimum of 20 octets. As a result, IP
packets received with header options are typically handled as
exceptions and in a less efficient manner due to their variable
length and complex processing requirements. Many router
implementations, for example, punt such packets from the hardware
forwarding (fast) path into the software forwarding (slow) path.
Multi-Protocol Label Switching (MPLS) [RFC3031] is primarily a
service provider (SP) technology where IP traffic can be encapsulated
with a label stack and then label switched across a network via Label
Switched Paths (LSPs) and Routers (LSRs). MPLS forwarding will
follow either hop-by-hop routing or source-routing as determined by
IP routing policies. MPLS provides SPs with the control plane
intelligence of IP while at the same time enabling layer 3
transparency much like ATM switches are transparent at layer 2. That
is, when a MPLS label stack is imposed at a ingress Label Edge Router
(LER), downstream LSRs generally use the MPLS label information for
their forwarding decision instead of the encapsulated IP header
information. In this way, except when ICMP processing is required per
[RFC3032] LSRs can avoid processing the IP network layer headers of
transit traffic.
Even though MPLS encapsulation seems to offer a viable solution to
protect downstream LSRs from being adversely impacted by customer
packets with IP header options, there is currently no formal standard
for encapsulation of IP packets with header options in MPLS networks.
When MPLS encapsulated, IP option packets are processed by downstream
LSRs as native MPLS packets within their forwarding paths. In this
Smith, et al. [Page 3]
Internet Draft draft-dasmith-mpls-ip-options-00.txt June 2008
way, the IP header options are effectively ignored by downstream LSRs
when encapsulated with a MPLS label stack. However, for many LER
implementations not all IP packets with header options are MPLS
encapsulated by the ingress LER.
Lack of a formal standard has resulted in inconsistent forwarding
behaviors by ingress LERs. Namely, IP packets with different types
of IP header options are handled differently by an ingress LER
despite being associated with the same prefix-based FEC as defined in
Section 4.1.1 of [RFC3031]. For instance, some IP header options may
inadvertently bypass MPLS encapsulation and the associated LSPs, and
are instead IP routed downstream on a per-hop basis by downstream
LSRs within the MPLS core. The different forwarding behaviors not
only vary across IP option types but also across ingress LER
implementations given no formal standard for IP header option
processing in MPLS networks. This document imposes a new requirement
on ingress LERs in order to reduce the risk of IP options-based
security attacks against LSRs as well as to minimize the IP routing
information carried by LSRs.
4.0 Ingress Label Edge Router Requirement
An ingress LER MUST implement the following policy, and the policy
MUST be enabled by default:
o When determining whether to push an MPLS label stack onto an IP
packet, the determination is made without considering any IP
options that may be carried in the IP packet header. Further, the
label values that appear in the label stack are determined
without considering any such IP options.
Further, how an ingress LER processes IP header options before MPLS
encapsulation is out of scope as it is not relevant to MPLS.
Similarly, an egress LER SHOULD only process IP options in those
cases where the egress LER forwarding decision is based on the native
IP packet. When the egress LER forwarding decision is based on a
popped label, the MPLS encapsulated IP header information including
IP options should be ignored with the exception of the IP TTL per
[RFC3443] and the Tunneled Diff-Serv information per [RFC3270].
Implementation of the above policy prevents IP packets from
inadvertently bypassing MPLS encapsulation due to header options. The
policy also prevents specific option types such as Router Alert
(value 148), for example, from forcing MPLS imposition of the MPLS
Router Alert Label (value 1) at ingress LERs. Without this policy,
the MPLS infrastructure is exposed to security attacks using
legitimate IP packets crafted with header options.
Smith, et al. [Page 4]
Internet Draft draft-dasmith-mpls-ip-options-00.txt June 2008
5.0 Security Considerations
There are two potential categories of attacks using crafted IP option
packets that threaten the MPLS infrastructure. Both are described
below.
5.1. IP Option Packets that Bypass MPLS Encapsulation
Given that a router's exception handling process (i.e., CPU,
processor line-card bandwidth, etc.) used for IP header option
processing is often shared with IP control and management protocol
router resources, a flood of IP packets with header options may
adversely affect a router's control and management protocols,
thereby, triggering a denial-of- service (DoS) condition. Note, IP
packets with header options may be valid transit IP packets with
legitimate sources and destinations. Hence, a DoS-like condition may
be triggered on downstream transit IP routers that lack protection
mechanisms even in the case of legitimate IP option packets.
IP option packets that bypass MPLS encapsulation at a ingress LER may
be inadvertently IP routed downstream across the MPLS core network
(not label switched). This allows an external attacker the
opportunity to maliciously craft seemingly legitimate IP packets with
specific IP header options in order to intentionally bypass MPLS
encapsulation at the MPLS edge (i.e., ingress LER) and trigger a DoS
condition on downstream LSRs. Some of the specific types of IP
option-based security attacks that may be leveraged against MPLS
networks include:
o Crafted IP option packets that bypass MPLS encapsulation at a
ingress LER may allow an attacker to DoS downstream LSRs by
saturating their software forwarding paths. By targeting a LSR's
exception path, control and management protocols may be adversely
affected and, thereby, a LSR's availability. This assumes, of
course, that downstream LSRs lack protection mechanisms.
o Crafted IP option packets that bypass MPLS encapsulation at a
ingress LER may allow for IP TTL expiry-based DoS attacks against
downstream LSRs. MPLS enables IP core hiding whereby transit IP
customers see the MPLS network as a single router hop [RFC3443].
However, MPLS core hiding does not apply to packets that bypass
MPLS encapsulation and, therefore, IP option packets may be
crafted to expire on downstream LSRs which may trigger a DoS
condition. This assumes, of course, that downstream LSRs lack
protection mechanisms. Bypassing MPLS core hiding is an
additional security consideration since it exposes the network
topology.
Smith, et al. [Page 5]
Internet Draft draft-dasmith-mpls-ip-options-00.txt June 2008
o Crafted IP option packets that bypass MPLS encapsulation at a
ingress LER may allow an attacker to bypass LSP Diff-Serv tunnels
[RFC3270] and any associated MPLS CoS field [MPLSCOS] marking
policies at ingress LERs and, thereby, adversely affect (i.e.,
DoS) high-priority traffic classes within the MPLS core. Further,
this could also lead to theft of high-priority services by
unauthorized parties. This assumes, of course, that the
[RFC3270] Pipe model is deployed within the MPLS core.
o Crafted IP strict and loose source route option packets that
bypass MPLS encapsulation at a ingress LER may allow an attacker
to specify explicit IP forwarding path(s) across an MPLS network
and, thereby, target specific LSRs with any of the DoS attacks
outlined above. This assumes, of course, that the MPLS network
is enabled to process IP strict and loose source route options.
o Crafted RSVP packets that bypass MPLS encapsulation at a ingress
LER may allow an attacker to build RSVP soft-states [RFC2205] on
downstream LSRs which could lead to theft of service by
unauthorized parties or to a DoS condition caused by locking up
LSR resources. This assumes, of course, that the MPLS network is
enabled to process RSVP packets.
The security attacks outlined above specifically apply to IP option
packets that bypass ingress LER label stack imposition. Additionally,
these attacks apply to IP option packets forwarded using the global
routing table (i.e., IPv4 address family) of a ingress LER. IP
option packets associated with a BGP/MPLS IP VPN service are always
MPLS encapsulated by the LER per [RFC4364] given that packet
forwarding uses a Virtual Forwarding/Routing (VRF) instance.
Therefore, BGP/MPLS IP VPN services are not subject to the threats
outlined above [RFC4381]. Further, IPv6 [RFC2460] makes use of
extension headers not header options and is therefore outside the
scope of this document. A separate security threat that does apply
to both BGP/MPLS IP VPNs and an IPv4 address family makes use of the
Router Alert Label. This is described directly below.
5.2. Router Alert Label Imposition
[RFC3032] defines a "Router Alert Label" (value of 1) which is
analogous to the "Router Alert" IP header option. The MPLS Router
Alert Label (when exposed and processed only) indicates to downstream
LSRs to examine these MPLS packets more closely. MPLS packets with
the MPLS Router Alert Label are also handled as an exception by LSRs
and, again, in a less efficient manner. At the time of this writing,
the only legitimate use of the Router Alert Label is for LSP
ping/trace [RFC4379]. Since there is also no formal standard for
Router Alert Label imposition at ingress LERs:
Smith, et al. [Page 6]
Internet Draft draft-dasmith-mpls-ip-options-00.txt June 2008
o Crafted IP packets with specific IP header options (e.g., Router
Alert) may allow an attacker to force MPLS imposition of the
Router Alert Label at ingress LERs and, thereby, trigger a DoS
condition on downstream LSRs. This assumes, of course, that
downstream LSRs lack protection mechanisms.
6.0 IANA Considerations
This document has no actions for IANA.
7.0 Conclusion
This document imposes a new requirement on ingress LERs that helps to
mitigate the risk of crafted security attacks using IP option packets
against MPLS infrastructures. The security threats were described
and exist as a result of no formal ingress LER specification for MPLS
encapsulation of IP packets with header options. Adoption of this
requirement will also eliminate the variability among ingress LER
implementations.
8.0 Acknowledgements
The authors would like to thank Pradosh Mohapatra, Carlos Pignataro,
Eric Rosen and Mark Szczesniak for their valuable comments and
suggestions.
9.0 Normative References
[RFC791] Postel, J., "Internet Protocol Specification," RFC791,
September 1981.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," March 1997.
[RFC3031] Rosen, E., Viswanathan, A., and Callon, R., "MPLS Label
Switching Architecture," RFC3031, January 2001.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and Conta, A., "MPLS Label Stack Encoding,"
RFC3032, January 2001.
Smith, et al. [Page 7]
Internet Draft draft-dasmith-mpls-ip-options-00.txt June 2008
10.0 Informational References
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., Jamin, S.,
"Resource ReSerVation Protocol -- Version 1 Functional
Specification," RFC2205, September 1997.
[RFC2460] Deering, S., Hinden, R. "Internet Protocol, Version 6
Specification," RFC2460, December 1998.
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen,
P., Krishnan, R., Cheval, P., Heinanen, J., "Multi-Protocol Label
Switching Support of Differentiated Services," RFC3270, May 2002.
[RFC3443] Agarwal, P., Akyol, B., "Time To Live (TTL) Processing in
Multi-Protocol Label Switching (MPLS) Networks," RFC3443, January
2003.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)," RFC4364, February 2006.
[RFC4379] "Kompella, K., Swallow, G., "Detecting Multi-Protocol Label
Switched (MPLS) Data Plane Failures," RFC4379, February 2006.
[RFC4381] Behringer, M., "Analysis of the Security of BGP/MPLS IP
Virtual Private Networks (VPNs)," RFC4381, February 2006.
[RFC4950] Bonica, R., Gan, D., Tappan, D., and Pignataro, C., "ICMP
Extensions for Multiprotocol Label Switching," RFC4950, August 2007.
[IANA] "IP Option Numbers," IANA, February 15, 2007,
<www.iana.org/assignments/ip-parameters>.
[MPLSCOS] Andersson, L., "EXP Field Renamed to CoS Field," IETF
draft-ietf-mpls-cosfield-def-02.txt, June 11, 2008.
11.0 Authors' Addresses
William Jaeger
AT&T
200 S. Laurel Avenue
Middletown, NJ 07748
Email: wjaeger@att.com
Smith, et al. [Page 8]
Internet Draft draft-dasmith-mpls-ip-options-00.txt June 2008
John Mullooly
Cisco Systems, Inc.
111 Wood Avenue
Iselin, NJ 08837
E-mail: jmullool@cisco.com
Tom Scholl
AT&T
200 S. Laurel Avenue
Middletown, NJ 07748
Email: ts3127@att.com
David J. Smith
Cisco Systems, Inc.
111 Wood Avenue
Iselin, NJ 08837
E-mail: dasmith@cisco.com
12.0 Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
Smith, et al. [Page 9]
Internet Draft draft-dasmith-mpls-ip-options-00.txt June 2008
13.0 Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Smith, et al. [Page 10]