ietf-corpus

rfc-6178

Label Edge Router Forwarding of IPv4 Option Packets

D. Smith, J. Mullooly, W. Jaeger, T. Scholl
date2011-03 streamIETF areartg wgmpls statusPROPOSED STANDARD pages9 canonicalhttps://www.rfc-editor.org/rfc/rfc6178 doi10.17487/RFC6178
This document specifies how Label Edge Routers (LERs) should behave when determining whether to MPLS encapsulate an IPv4 packet with header options. Lack of a formal standard has resulted in different LER forwarding behaviors for IPv4 packets with header options despite being associated with a prefix-based Forwarding Equivalence Class (FEC). IPv4 option packets that belong to a prefix-based FEC, yet are forwarded into an IPv4/MPLS network without being MPLS- encapsulated, present a security risk against the MPLS infrastructure. Further, LERs that are unable to MPLS encapsulate IPv4 packets with header options cannot operate in certain MPLS environments. While this newly defined LER behavior is mandatory to implement, it is optional to invoke. [STANDARDS-TRACK]

updates

Extracted elements (15)

design-rationale §2

IPv4 option packets are processed as exceptions and routed through the software forwarding (slow) path rather than the hardware fast path, due to variable header length and complex processing requirements. Many router implementations punt such packets to the CPU, causing high CPU utilization.

mpls, ip

design-rationale §4

MPLS encapsulation of IPv4 option packets prevents the Router Alert IPv4 header option (option value 148) from forcing imposition of the MPLS Router Alert Label (label value 1) at ingress LERs, which could otherwise be exploited to trigger DoS conditions on downstream LSRs.

mpls, ip, security

design-rationale §2

Prior to this document, no formal standard governed MPLS encapsulation of IPv4 packets with header options belonging to a prefix-based FEC, resulting in inconsistent ingress LER behaviors. Unencapsulated IPv4 option packets forwarded into an MPLS core risk packet loss (downstream LSRs may lack IPv4 routing info) and expose LSRs to IPv4 security attacks.

mpls, ip, security

interoperability-note §5.1

BGP/MPLS IPv4 VPN services (RFC 4364) are not subject to the bypass-encapsulation attacks described here because such packets always use a VRF instance and are always MPLS encapsulated by the ingress LER. The Router Alert Label threat, however, applies to both VPN and global IPv4 address families.

mpls, ip, security

interoperability-note §5.1

IPv6 (RFC 2460) uses extension headers rather than header options and is therefore outside the scope of this document. The LER encapsulation policy defined here applies only to IPv4 option packets.

mpls, ip

normative-requirement §4 MUST

An ingress LER MUST implement a policy whereby, when determining whether to push an MPLS label stack onto an IPv4 packet, the determination is made without considering any IPv4 options carried in the packet header. The label values in the stack are also determined without considering any IPv4 options.

mpls, ip, security

normative-requirement §4 SHOULD

The ingress LER encapsulation policy MAY be configurable, but it SHOULD be enabled by default. This policy SHOULD NOT alter more specific forwarding rules such as those for RSVP or source routing.

mpls, ip

normative-requirement §4 SHOULD NOT

When processing of signaling messages or data packets with more specific forwarding rules is enabled (e.g., RSVP per RFC 2205, source routing per RFC 791), the ingress LER SHOULD NOT alter those specific processing rules.

mpls, ip

protocol-element §5.2

The MPLS Router Alert Label has label value 1 and is analogous to the IPv4 Router Alert header option (option value 148). When exposed and processed, it signals downstream LSRs to examine MPLS packets more closely. At the time of writing, its only legitimate use is LSP ping/trace (RFC 4379).

mpls, ip

security-consideration §5.1

Crafted IPv4 option packets bypassing MPLS encapsulation may target downstream LSRs that do not carry full IPv4 routing information, causing packet drops and ICMP destination unreachable storms that trigger a DoS condition.

mpls, ip, security

security-consideration §5.1

Crafted IPv4 option packets that bypass MPLS encapsulation enable TTL expiry-based DoS attacks against downstream LSRs. MPLS core hiding (RFC 3443) does not apply to non-encapsulated packets, so attackers can craft packets to expire on specific LSRs and expose network topology.

mpls, ip, security

security-consideration §5.2

Crafted IPv4 packets with the Router Alert header option (option value 148) that belong to a prefix-based FEC can force MPLS imposition of the Router Alert Label (label value 1) at ingress LERs, triggering DoS conditions on downstream LSRs that process Router Alert Label packets as exceptions.

mpls, ip, security

security-consideration §5.1

Crafted RSVP packets belonging to a prefix-based FEC that bypass MPLS encapsulation can allow an attacker to build RSVP soft-states on downstream LSRs, leading to theft of service or DoS caused by locking up LSR resources.

mpls, ip, security

security-consideration §5.1

IPv4 option packets belonging to a prefix-based FEC that bypass MPLS encapsulation at an ingress LER allow attackers to DoS downstream LSRs by saturating their software exception forwarding paths, adversely affecting control and management protocols and LSR availability.

mpls, ip, security

security-consideration §5.1

IPv4 option packets bypassing MPLS encapsulation can circumvent LSP DiffServ tunnels (RFC 3270) and MPLS CoS marking policies at ingress LERs, enabling DoS against high-priority traffic classes within the MPLS core and potential theft of high-priority services.

mpls, ip, security, diffserv