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, . [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]