RFC 6178

Label Edge Router Forwarding of IPv4 Option Packets 🎀

Okay bestie, this is RFC 6178 💖. The header says it's an IETF document from March 2011 with the category Standards Track, so it's a real Internet standard, not just a suggestion 💅. The authors are D. Smith and J. Mullooly from Cisco Systems, W. Jaeger from AT&T, and T. Scholl from nLayer Communications. The ISSN is 2070-1721. It updates [RFC3031], and the header doesn't list anything it obsoletes ✨.

Abstract ✨

Okay so this document is all about how Label Edge Routers (LERs) should decide whether to MPLS encapsulate an IPv4 packet that has header options 🦋. There hasn't been a formal standard for this, so different LERs were doing different things with IPv4 option packets, even when those packets belonged to the same prefix-based Forwarding Equivalence Class (FEC) 😭. If an IPv4 option packet in a prefix-based FEC gets pushed into an IPv4/MPLS network without MPLS encapsulation, that's a security risk for the MPLS infrastructure 💀. LERs that can't MPLS encapsulate IPv4 packets with header options also can't work in certain MPLS environments 🙈. This new LER behavior is mandatory to implement, but it's optional to invoke 🫶.

Status of This Memo 🌸

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of [RFC5741].

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6178.

Copyright Notice 🍓

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents 🧚

1. Motivation ......................................................2
2. Introduction ....................................................2
3. Specification of Requirements ...................................4
4. Ingress Label Edge Router Requirement ...........................4
5. Security Considerations .........................................5
   5.1. IPv4 Option Packets That Bypass MPLS Encapsulation .........5
   5.2. Router Alert Label Imposition ..............................7
6. Acknowledgements ................................................7
7. References ......................................................7
   7.1. Normative References .......................................7
   7.2. Informative References .....................................8

1. Motivation 💜

Okay so the whole point here is that we need to formalize how MPLS encapsulation works for IPv4 packets with header options 🎀. The goal is to reduce the existing risk of IPv4 options-based security attacks against MPLS infrastructures ✨. The authors feel this document fills in details that [RFC3031] and [RFC3032] didn't fully cover, and that it updates [RFC3031] while also complementing [RFC3270], [RFC3443], and [RFC4950] 💅.

2. Introduction 🦋

The IPv4 packet header supports various IPv4 options, as originally specified in [RFC791] 🌈. IPv4 header options are used for control functions inside the IPv4 data forwarding plane. They're needed in some specific situations, but most common IPv4 communications don't need them 💖. Typical IPv4 header options cover things like timestamps, security, and special routing. Example IPv4 header options and their applications include, but aren't limited to, the following:

• Strict and Loose Source Route Options: Used to IPv4 route the IPv4 packet based on information supplied by the source.
• Record Route Option: Used to trace the route an IPv4 packet takes.
• Router Alert Option: Indicates to downstream IPv4 routers to examine these IPv4 packets more closely.

The list of current IPv4 header options can be accessed at [IANA] 🔥.

IPv4 packets may or may not use IPv4 header options, since they're optional. However, IPv4 header option handling mechanisms must be implemented by all IPv4 protocol stacks (hosts and routers) 👑. Each IPv4 header option has its own distinct header fields and lengths. IPv4 options make the IPv4 packet header longer than the minimum of 20 octets. Because of that variable length and complex processing, IPv4 packets with header options are usually handled as exceptions, which makes them less efficient 😭. For example, many router implementations punt these IPv4 option packets from the hardware forwarding (fast) path into the software forwarding (slow) path, and that causes high CPU utilization 💀. Even when the forwarding plane can parse a variable-length header, it may still need to punt to the control plane, because the forwarding plane may not have the clock cycles or intelligence needed to process the header option 🙈.

Multi-Protocol Label Switching (MPLS) [RFC3031] is a technology where packets in a prefix-based Forwarding Equivalence Class (FEC) get encapsulated with a label stack and then switched along a label switched path (LSP) by a sequence of label switch routers (LSRs) ✨. These intermediate LSRs generally don't process the IPv4 header as packets are forwarded. (There are some exceptions to this rule, like ICMP processing and LSP ping, as described in [RFC3032] and [RFC4379], respectively.) Lots of MPLS deployments rely on LSRs to provide layer 3 transparency, kind of like how ATM switches are transparent at layer 2 🦋. These deployments often minimize the IPv4 routing information carried by LSRs (for example, no BGP transit routes), since it isn't needed for MPLS forwarding of transit packets 🌸.

MPLS encapsulation seems like a solid way to get layer 3 transparency, but there's currently no formal standard for MPLS encapsulating IPv4 packets with header options that belong to a prefix-based FEC 😭. Without a formal standard, ingress Label Edge Routers (LERs) behave inconsistently 💅. When an ingress LER MPLS encapsulates IPv4 packets, the IPv4 header, including the option fields of transit packets, isn't acted upon by the downstream LSRs that forward based on the MPLS label(s) ✨. If an ingress LER IPv4 forwards a packet instead, two bad things can happen 💀. First, a downstream LSR might not have enough IPv4 routing information to forward the packet, so the packet gets lost. Second, downstream LSRs have to apply IPv4 forwarding rules that may expose them to IPv4 security attacks 🙈.

IPv4 option packets that belong to a prefix-based FEC, yet get forwarded into an IPv4/MPLS network without being MPLS-encapsulated, present a security risk against the MPLS infrastructure 🔥. LERs that can't MPLS encapsulate IPv4 packets with header options also can't operate as an LER in certain MPLS environments 😭. This new requirement cuts down the risk of IPv4 options-based security attacks against LSRs, and it helps LERs work across MPLS networks that minimize the IPv4 routing information (for example, no BGP transit routes) carried by LSRs 🫶.

3. 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] ✨.

4. Ingress Label Edge Router Requirement 👑

An ingress LER MUST implement the following policy:

• When determining whether to push an MPLS label stack onto an IPv4 packet, the determination is made without considering any IPv4 options that may be carried in the IPv4 packet header. Further, the label values that appear in the label stack are determined without considering any such IPv4 options.

This policy MAY be configurable on an ingress LER, however, it SHOULD be enabled by default 💖. When processing of signaling messages or data packets with more specific forwarding rules is enabled, this policy SHOULD NOT alter the specific processing rules 🦋. This applies to, but isn't limited to, Resource Reservation Protocol (RSVP) as per [RFC2205], source routing as per [RFC791], and other FEC elements defined by future specifications 🌈. Also, how an ingress LER processes the IPv4 header options of packets before MPLS encapsulation is out of scope, since those options are processed before the packets enter the MPLS domain 🧚.

Implementing the above policy stops IPv4 packets that belong to a prefix-based FEC from bypassing MPLS encapsulation because of header options 🔥. The policy also stops specific option types, like Router Alert (option value 148), from forcing MPLS imposition of the MPLS Router Alert Label (label value 1) at ingress LERs 💀. Without this policy, the MPLS infrastructure is open to security attacks using legitimate IPv4 packets crafted with header options 😭. And LERs that can't MPLS encapsulate IPv4 packets with header options still can't operate as an LER in certain MPLS environments, as described in Section 2 🙈.

5. Security Considerations 💀

Okay this section is serious, bestie 😭

There are two potential categories of attacks using crafted IPv4 option packets that threaten existing MPLS infrastructures 🚨. Both are described below. To mitigate the risk of these specific attacks, the ingress LER policy specified above is required 🛡️.

5.1. IPv4 Option Packets That Bypass MPLS Encapsulation ✨

okay so, the exception handling process on a router (CPU, processor line-card bandwidth, etc.) that handles IPv4 header options is often shared with the router's IPv4 control and management protocols 🫠 which means a flood of IPv4 packets with header options can hurt those control and management protocols and trigger a denial-of-service (DoS) condition 💀. ngl this is lowkey scary. And the tea is that IPv4 packets with header options can be totally valid transit packets with legit sources and destinations 🍵 so a DoS-like condition can hit downstream transit IPv4 routers that lack protection mechanisms, even when the option packets are legitimate 😭

now the spicier part 🌶️ IPv4 option packets that belong to a prefix-based FEC but bypass MPLS encapsulation at an ingress LER can get IPv4 routed downstream across the MPLS core instead of being label switched 🛣️ which means an external attacker can craft seemingly legit IPv4 packets with specific header options to intentionally bypass MPLS encapsulation at the MPLS edge (the ingress LER) and trigger a DoS condition on downstream LSRs. bestie that is NOT it 🙅‍♀️ here are the specific types of IPv4 option-based attacks that can be used against MPLS networks:

• Crafted IPv4 option packets that belong to a prefix-based FEC yet bypass MPLS encapsulation at an ingress LER may allow an attacker to DoS downstream LSRs by saturating their software forwarding paths. By targeting an LSR's exception path, control and management protocols may be adversely affected and, thereby, an LSR's availability 🥀. This assumes, of course, that downstream LSRs lack protection mechanisms.
• Crafted IPv4 option packets that belong to a prefix-based FEC yet bypass MPLS encapsulation at an ingress LER may allow for IPv4 Time to Live (TTL) expiry-based DoS attacks against downstream LSRs 🕰️ MPLS enables IPv4 core hiding, where transit IPv4 traffic sees the MPLS network as a single router hop [RFC3443]. But MPLS core hiding does NOT apply to packets that bypass MPLS encapsulation, so IPv4 option packets can be crafted to expire on downstream LSRs and trigger a DoS condition 😱 Bypassing MPLS core hiding is an extra security concern too, since it exposes the network topology 👀
• Crafted IPv4 option packets that belong to a prefix-based FEC yet bypass MPLS encapsulation at an ingress LER may allow for DoS attacks against downstream LSRs that don't carry the IPv4 routing information needed to forward transit IPv4 traffic 🗺️ Without that routing information, legit IPv4 option packets may be unable to transit the MPLS network, and they may trigger generation of ICMP destination unreachable messages, which could lead to a DoS condition. This assumes, of course, that downstream LSRs lack protection mechanisms AND don't carry the IPv4 routing information needed to forward transit traffic.
• Crafted IPv4 option packets that belong to a prefix-based FEC yet bypass MPLS encapsulation at an ingress LER may allow an attacker to bypass LSP Diffserv tunnels [RFC3270] and any associated MPLS Class of Service (CoS) field [RFC5462] marking policies at ingress LERs 🏷️ and, thereby, adversely affect (aka DoS) high-priority traffic classes within the MPLS core. 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.
• Crafted RSVP packets that belong to a prefix-based FEC yet bypass MPLS encapsulation at an ingress LER may allow an attacker to build RSVP soft-states [RFC2205] [RFC3209] 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 attacks above specifically apply to IPv4 option packets that belong to a prefix-based FEC yet bypass ingress LER label stack imposition 🎯 they ALSO only apply to IPv4 option packets forwarded using the global routing table (aka the IPv4 address family) of an ingress LER. IPv4 option packets tied to a BGP/MPLS IPv4 VPN service are always MPLS encapsulated by the ingress LER per [RFC4364], since packet forwarding uses a Virtual Forwarding/Routing (VRF) instance 💜 So BGP/MPLS IPv4 VPN services are not subject to the threats outlined above [RFC4381]. Also, IPv6 [RFC2460] uses extension headers, NOT header options, so it's outside the scope of this document 🙅‍♀️ There's a separate security threat that applies to BOTH BGP/MPLS IPv4 VPNs and the IPv4 address family, and it uses the Router Alert Label. Here's that one, directly below 👇

5.2. Router Alert Label Imposition 🚨

ok this one is giving "sneaky" energy 🕵️‍♀️ [RFC3032] defines a Router Alert Label (label value of 1), which is analogous to the Router Alert IPv4 header option (option value of 148). When it's exposed and processed only, the MPLS Router Alert Label tells 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, again in a less efficient manner 🐢 As of this writing, the only legit use of the Router Alert Label is for LSP ping/trace [RFC4379]. And since there's ALSO no formal standard for Router Alert Label imposition at ingress LERs... 🫣

• Crafted IPv4 packets with specific IPv4 header options (e.g., Router Alert) that belong to a prefix-based FEC 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. Acknowledgements 💖

the authors want to thank Adrian Cepleanu, Bruce Davie, Rick Huber, Chris Metz, Pradosh Mohapatra, Ashok Narayanan, Carlos Pignataro, Eric Rosen, Mark Szczesniak, and Yung Yu for their valuable comments and suggestions 🫶 the people really showed up for this one, iconic ✨

7. References 📚

7.1. Normative References

[RFC791]    Postel, J., "Internet Protocol", STD 5, RFC 791,
            September 1981.

[RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC3031]   Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
            Label Switching Architecture", RFC 3031, January 2001.

[RFC3032]   Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
            Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
            Encoding", RFC 3032, January 2001.

7.2. Informative References

[RFC2205]   Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and
            S. Jamin, "Resource ReSerVation Protocol (RSVP) --
            Version 1 Functional Specification", RFC 2205, September
            1997.

[RFC2460]   Deering, S. and R. Hinden, "Internet Protocol, Version 6
            (IPv6) Specification", RFC 2460, December 1998.

[RFC3209]   Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
            and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
            Tunnels", RFC 3209, December 2001.

[RFC3270]   Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen,
            P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-
            Protocol Label Switching (MPLS) Support of Differentiated
            Services", RFC 3270, May 2002.

[RFC3443]   Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing
            in Multi-Protocol Label Switching (MPLS) Networks", RFC
            3443, January 2003.

[RFC4364]   Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
            Networks (VPNs)", RFC 4364, February 2006.

[RFC4379]   Kompella, K. and G. Swallow, "Detecting Multi-Protocol
            Label Switched (MPLS) Data Plane Failures", RFC 4379,
            February 2006.

[RFC4381]   Behringer, M., "Analysis of the Security of BGP/MPLS IP
            Virtual Private Networks (VPNs)", RFC 4381, February
            2006.

[RFC4950]   Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "ICMP
            Extensions for Multiprotocol Label Switching", RFC 4950,
            August 2007.

[IANA]      "IP Option Numbers," IANA, February 15, 2007,
            <www.iana.org>.

[RFC5462]   Andersson, L. and R. Asati, "Multiprotocol Label
            Switching (MPLS) Label Stack Entry: "EXP" Field Renamed
            to "Traffic Class" Field", RFC 5462, February 2009.

Authors' Addresses 🎀

David J. Smith
Cisco Systems
111 Wood Avenue South
Iselin, NJ  08830
EMail: djsmith@cisco.com

John Mullooly
Cisco Systems
111 Wood Avenue South
Iselin, NJ  08830
EMail: jmullool@cisco.com

William Jaeger
AT&T
200 S. Laurel Avenue
Middletown, NJ  07748
EMail: wjaeger@att.com

Tom Scholl
nLayer Communications
209 West Jackson, Suite 700
Chicago, IL  60606
EMail: tscholl@nlayer.net

that's the whole RFC, bestie 🌈👑 go touch some grass and then come back and let's talk about the Router Alert Label 🦋