Internet Engineering Task Force (IETF) D. Smith
Request for Comments: 6178 J. Mullooly
Updates: 3031 Cisco Systems
Category: Standards Track W. Jaeger
ISSN: 2070-1721 AT&T
T. Scholl
nLayer Communications
March 2011
Internet Engineering Task Force (IETF) D. Smith
Request for Comments: 6178 J. Mullooly
Updates: 3031 Cisco Systems
Category: Standards Track W. Jaeger
ISSN: 2070-1721 AT&T
T. Scholl
nLayer Communications
March 2011
Label Edge Router Forwarding of IPv4 Option Packets
标签边缘路由器转发IPv4选项数据包
Abstract
摘要
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.
本文档指定了标签边缘路由器（LER）在确定MPLS是否使用报头选项封装IPv4数据包时的行为。尽管与基于前缀的转发等价类（FEC）关联，但由于缺乏正式标准，导致具有报头选项的IPv4数据包具有不同的LER转发行为。IPv4选项数据包属于基于前缀的FEC，但在未进行MPLS封装的情况下转发到IPv4/MPLS网络中，会对MPLS基础设施造成安全风险。此外，无法使用报头选项MPLS封装IPv4数据包的LER无法在某些MPLS环境中运行。虽然这个新定义的LER行为是必须实现的，但是调用它是可选的。
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 RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问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.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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 ......................................................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
This document is motivated by the need to formalize MPLS encapsulation processing of IPv4 packets with header options in order to mitigate the existing risks of IPv4 options-based security attacks against MPLS infrastructures. 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 [RFC3270], [RFC3443], and [RFC4950].
本文档的动机是需要使用报头选项对IPv4数据包的MPLS封装处理进行形式化，以减轻针对MPLS基础设施的基于IPv4选项的安全攻击的现有风险。我们认为，本文件增加了[RFC3031]和[RFC3032]中未完全解决的细节，本文件中介绍的方法更新了[RFC3031]以及补充[RFC3270]、[RFC3443]和[RFC4950]。
The IPv4 packet header provides for various IPv4 options as originally specified in [RFC791]. IPv4 header options are used to enable control functions within the IPv4 data forwarding plane that are required in some specific situations but not necessary for most common IPv4 communications. Typical IPv4 header options include
IPv4数据包头提供了[RFC791]中最初指定的各种IPv4选项。IPv4标头选项用于启用IPv4数据转发平面内的控制功能，这些功能在某些特定情况下是必需的，但对于大多数常见的IPv4通信来说不是必需的。典型的IPv4头选项包括
provisions for timestamps, security, and special routing. Example IPv4 header options and applications include but are not limited to the following:
时间戳、安全性和特殊路由的规定。示例IPv4标头选项和应用程序包括但不限于以下内容：
o Strict and Loose Source Route Options: Used to IPv4 route the IPv4 packet based on information supplied by the source.
o 严格和松散源路由选项：用于根据源提供的信息对IPv4数据包进行IPv4路由。
o Record Route Option: Used to trace the route an IPv4 packet takes.
o 记录路由选项：用于跟踪IPv4数据包采用的路由。
o Router Alert Option: Indicates to downstream IPv4 routers to examine these IPv4 packets more closely.
o 路由器警报选项：指示下游IPv4路由器更仔细地检查这些IPv4数据包。
The list of current IPv4 header options can be accessed at [IANA].
当前IPv4标头选项列表可在[IANA]访问。
IPv4 packets may or may not use IPv4 header options (they are optional), but IPv4 header option handling mechanisms must be implemented by all IPv4 protocol stacks (hosts and routers). Each IPv4 header option has distinct header fields and lengths. IPv4 options extend the IPv4 packet header length beyond the minimum of 20 octets. As a result, IPv4 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. For example, many router implementations punt such IPv4 option packets from the hardware forwarding (fast) path into the software forwarding (slow) path causing 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 required to process the header option.
IPv4数据包可以使用也可以不使用IPv4报头选项（它们是可选的），但IPv4报头选项处理机制必须由所有IPv4协议栈（主机和路由器）实现。每个IPv4标头选项都有不同的标头字段和长度。IPv4选项将IPv4数据包标头长度扩展到至少20个八位字节之外。因此，使用报头选项接收的IPv4数据包通常作为例外处理，由于其长度可变且处理要求复杂，因此效率较低。例如，许多路由器实现将这样的IPv4选项数据包从硬件转发（快速）路径推送到软件转发（慢速）路径，从而导致高CPU利用率。即使当转发平面可以解析可变长度的报头时，它可能仍然需要跳转到控制平面，因为转发平面可能没有处理报头选项所需的时钟周期或智能。
Multi-Protocol Label Switching (MPLS) [RFC3031] is a technology in which packets associated with a prefix-based Forwarding Equivalence Class (FEC) are 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 do not generally perform any processing of the IPv4 header as packets are forwarded. (There are some exceptions to this rule, such as ICMP processing and LSP ping, as described in [RFC3032] and [RFC4379], respectively.) Many MPLS deployments rely on LSRs to provide layer 3 transparency much like ATM switches are transparent at layer 2. Such deployments often minimize the IPv4 routing information (e.g., no BGP transit routes) carried by LSRs since it is not necessary for MPLS forwarding of transit packets.
多协议标签交换（MPLS）[RFC3031]是一种技术，在该技术中，与基于前缀的转发等价类（FEC）相关联的数据包用标签堆栈封装，然后通过一系列标签交换路由器（LSR）沿标签交换路径（LSP）进行交换。这些中间LSR通常不会在转发数据包时对IPv4报头执行任何处理。（此规则有一些例外情况，如[RFC3032]和[RFC4379]中分别描述的ICMP处理和LSP ping。）许多MPLS部署依赖LSR提供第3层透明度，就像ATM交换机在第2层是透明的一样。这种部署通常会最小化LSR携带的IPv4路由信息（例如，无BGP传输路由），因为它对于传输数据包的MPLS转发不是必需的。
Even though MPLS encapsulation seems to offer a viable solution to provide layer 3 transparency, there is currently no formal standard for MPLS encapsulation of IPv4 packets with header options that belong to a prefix-based FEC. Lack of a formal standard has resulted
尽管MPLS封装似乎提供了一个可行的解决方案来提供第3层的透明度，但目前还没有针对IPv4数据包的MPLS封装的正式标准，这些数据包具有属于基于前缀的FEC的报头选项。结果是缺乏正式的标准
in inconsistent forwarding behaviors by ingress Label Edge Routers (LERs). When IPv4 packets are MPLS encapsulated by an ingress LER, for example, the IPv4 header including option fields of transit packets are not acted upon by downstream LSRs that forward based on the MPLS label(s). Conversely, when a packet is IPv4 forwarded by an ingress LER two undesirable behaviors can result. First, a downstream LSR may not have sufficient IPv4 routing information to forward the packet resulting in packet loss. Second, downstream LSRs must apply IPv4 forwarding rules that may expose them to IPv4 security attacks.
入口标签边缘路由器（LER）的不一致转发行为。例如，当IPv4数据包是由入口LER封装的MPLS时，包括传输数据包选项字段的IPv4报头不受基于MPLS标签转发的下游LSR的作用。相反，当数据包由入口LER通过IPv4转发时，可能会导致两种不良行为。首先，下游LSR可能没有足够的IPv4路由信息来转发分组，从而导致分组丢失。其次，下游LSR必须应用IPv4转发规则，这些规则可能使它们面临IPv4安全攻击。
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 as an LER in certain MPLS environments. This new requirement will reduce the risk of IPv4 options-based security attacks against LSRs as well as assist LER operation across MPLS networks that minimize the IPv4 routing information (e.g., no BGP transit routes) carried by LSRs.
IPv4选项数据包属于基于前缀的FEC，但在未进行MPLS封装的情况下转发到IPv4/MPLS网络中，会对MPLS基础设施造成安全风险。此外，在某些MPLS环境中，无法使用报头选项封装IPv4数据包的LER不能作为LER运行。这一新要求将降低针对LSR的基于IPv4选项的安全攻击的风险，并帮助跨MPLS网络的LER操作，以最小化LSR携带的IPv4路由信息（例如，无BGP传输路由）。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
An ingress LER MUST implement the following policy:
入口LER必须实施以下策略：
o 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.
o 在确定是否将MPLS标签堆栈推送到IPv4数据包上时，不考虑IPv4数据包报头中可能携带的任何IPv4选项。此外，标签堆栈中出现的标签值是在不考虑任何此类IPv4选项的情况下确定的。
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 is not limited to, Resource Reservation Protocol (RSVP) as per [RFC2205], source routing as per [RFC791], as well as other FEC elements defined by future specifications. Further, how an ingress LER processes the IPv4 header options of packets before MPLS encapsulation is out of scope since these are processed before they enter the MPLS domain.
此策略可以在入口LER上配置，但默认情况下应启用。当使用更具体的转发规则处理信令消息或数据包时，此策略不应改变具体的处理规则。这适用于但不限于符合[RFC2205]的资源预留协议（RSVP）、符合[RFC791]的源路由以及未来规范定义的其他FEC元素。此外，入口LER在MPLS封装之前如何处理数据包的IPv4报头选项超出范围，因为这些选项是在数据包进入MPLS域之前处理的。
Implementation of the above policy prevents IPv4 packets that belong to a prefix-based FEC from bypassing MPLS encapsulation due to header options. The policy also prevents specific option types such as 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 exposed to security attacks using legitimate IPv4 packets crafted with header options. Further, LERs that are unable to MPLS encapsulate IPv4 packets with header options cannot operate as an LER in certain MPLS environments as described in Section 2.
上述策略的实现可防止属于基于前缀的FEC的IPv4数据包由于报头选项而绕过MPLS封装。该策略还防止诸如路由器警报（选项值148）之类的特定选项类型在入口LER强制MPLS施加MPLS路由器警报标签（标签值1）。如果没有此策略，MPLS基础结构将面临使用头选项精心编制的合法IPv4数据包的安全攻击。此外，如第2节所述，在某些MPLS环境中，无法使用报头选项封装IPv4数据包的LER不能作为LER运行。
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.
使用精心编制的IPv4选项数据包的攻击可能有两类，它们威胁到现有MPLS基础设施。下文对这两种情况进行了说明。为了降低这些特定攻击的风险，需要使用上面指定的入口LER策略。
Given that a router's exception handling process (i.e., CPU, processor line-card bandwidth, etc.) used for IPv4 header option processing is often shared with IPv4 control and management protocol router resources, a flood of IPv4 packets with header options may adversely affect a router's control and management protocols, thereby, triggering a denial-of-service (DoS) condition. Note, IPv4 packets with header options may be valid transit IPv4 packets with legitimate sources and destinations. Hence, a DoS-like condition may be triggered on downstream transit IPv4 routers that lack protection mechanisms even in the case of legitimate IPv4 option packets.
鉴于用于IPv4报头选项处理的路由器异常处理过程（即CPU、处理器线路卡带宽等）通常与IPv4控制和管理协议路由器资源共享，具有报头选项的IPv4数据包的泛滥可能会对路由器的控制和管理协议产生不利影响，因此，触发拒绝服务（DoS）条件。注意，具有标头选项的IPv4数据包可能是具有合法来源和目的地的有效传输IPv4数据包。因此，即使在合法IPv4选项数据包的情况下，也可能在缺乏保护机制的下游传输IPv4路由器上触发类似DoS的条件。
IPv4 option packets that belong to a prefix-based FEC yet bypass MPLS encapsulation at an ingress LER may be inadvertently IPv4 routed downstream across the MPLS core network (not label switched). This allows an external attacker the opportunity to maliciously craft seemingly legitimate IPv4 packets with specific IPv4 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 IPv4 option-based security attacks that may be leveraged against MPLS networks include the following:
属于基于前缀的FEC但在入口LER绕过MPLS封装的IPv4选项数据包可能无意中跨MPLS核心网络（非标签交换）向下游路由IPv4。这使外部攻击者有机会利用特定的IPv4报头选项恶意创建看似合法的IPv4数据包，以便故意绕过MPLS边缘（即入口LER）处的MPLS封装，并在下游LSR上触发DoS条件。针对MPLS网络可能利用的某些特定类型的基于IPv4选项的安全攻击包括：
o 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 a 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.
o 精心编制的IPv4选项数据包属于基于前缀的FEC，但在入口LER处绕过MPLS封装，这可能允许攻击者通过饱和其软件转发路径拒绝下游LSR。通过针对LSR的异常路径，控制和管理协议可能受到不利影响，从而影响LSR的可用性。当然，这是假设下游LSR缺乏保护机制。
o 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 whereby transit IPv4 traffic flows 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, IPv4 option packets may be crafted to expire on downstream LSRs which may trigger a DoS condition. Bypassing MPLS core hiding is an additional security consideration since it exposes the network topology.
o 属于基于前缀的FEC但在入口LER绕过MPLS封装的特制IPv4选项数据包可能允许针对下游LSR的基于IPv4生存时间（TTL）到期的DoS攻击。MPLS支持IPv4核心隐藏，通过此功能，传输IPv4流量将MPLS网络视为单个路由器跃点[RFC3443]。然而，MPLS核心隐藏不适用于绕过MPLS封装的数据包，因此，IPv4选项数据包可能被精心设计为在下游LSR上过期，这可能会触发DoS条件。绕过MPLS核心隐藏是一个额外的安全考虑，因为它公开了网络拓扑。
o 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 do not carry the IPv4 routing information required to forward transit IPv4 traffic. Lack of such IPv4 routing information may prevent legitimate IPv4 option packets from transiting the MPLS network and, further, 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 do not carry the IPv4 routing information required to forward transit traffic.
o 精心编制的IPv4选项数据包属于基于前缀的FEC，但在入口LER处绕过MPLS封装，可能会允许针对下游LSR的DoS攻击，这些LSR不携带转发传输IPv4流量所需的IPv4路由信息。缺少此类IPv4路由信息可能会阻止合法的IPv4选项数据包通过MPLS网络，并且可能会触发ICMP目的地不可访问消息的生成，这可能导致DoS情况。当然，这假设下游LSR缺乏保护机制，并且不携带转发传输流量所需的IPv4路由信息。
o 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 (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 属于基于前缀的FEC但在入口LER绕过MPLS封装的特制IPv4选项数据包可能允许攻击者绕过LSP Diffserv隧道[RFC3270]和入口LER上任何相关的MPLS服务类别（CoS）字段[RFC5462]标记策略，从而对（即DoS）产生不利影响MPLS核心内的高优先级流量类别。此外，这还可能导致未经授权方窃取高优先级服务。当然，这假设[RFC3270]管道模型部署在MPLS核心内。
o 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.
o 属于基于前缀的FEC但在入口LER处绕过MPLS封装的特制RSVP数据包可能允许攻击者在下游LSR上构建RSVP软状态[RFC2205][RFC3209]，这可能导致未经授权方窃取服务或锁定LSR资源导致DoS情况。当然，这假设MPLS网络能够处理RSVP数据包。
The security attacks outlined above specifically apply to IPv4 option packets that belong to a prefix-based FEC yet bypass ingress LER label stack imposition. Additionally, these attacks only apply to IPv4 option packets forwarded using the global routing table (i.e., IPv4 address family) of a ingress LER. IPv4 option packets associated with a BGP/MPLS IPv4 VPN service are always MPLS
上述安全攻击特别适用于属于基于前缀的FEC但绕过入口LER标签堆栈的IPv4选项数据包。此外，这些攻击仅适用于使用入口LER的全局路由表（即IPv4地址系列）转发的IPv4选项数据包。与BGP/MPLS IPv4 VPN服务关联的IPv4选项数据包始终为MPLS
encapsulated by the ingress LER per [RFC4364] given that packet forwarding uses a Virtual Forwarding/Routing (VRF) instance. Therefore, BGP/MPLS IPv4 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 IPv4 VPNs and the IPv4 address family makes use of the Router Alert Label. This is described directly below.
如果包转发使用虚拟转发/路由（VRF）实例，则根据[RFC4364]由入口LER封装。因此，BGP/MPLS IPv4 VPN服务不受上述威胁的影响[RFC4381]。此外，IPv6[RFC2460]使用扩展头而不是头选项，因此不在本文档的范围内。一个单独的安全威胁使用路由器警报标签，该威胁同时适用于BGP/MPLS IPv4 VPN和IPv4地址系列。这将在下面直接描述。
[RFC3032] defines a Router Alert Label (label value of 1), which is analogous to the Router Alert IPv4 header option (option value of 148). 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:
[RFC3032]定义路由器警报标签（标签值为1），类似于路由器警报IPv4标头选项（选项值为148）。MPLS路由器警报标签（仅在公开和处理时）指示下游LSR更仔细地检查这些MPLS数据包。带有MPLS路由器警报标签的MPLS数据包也被LSR作为例外处理，并且同样以效率较低的方式处理。在撰写本文时，路由器警报标签的唯一合法用途是LSP ping/trace[RFC4379]。由于也没有正式的标准用于路由器警报标签的输入：
o Crafted IPv4 packets with specific IPv4 header options (e.g., Router Alert) and 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.
o 具有特定IPv4报头选项（例如，路由器警报）且属于基于前缀的FEC的特制IPv4数据包可能允许攻击者在入口LER强制MPLS施加路由器警报标签，从而在下游LSR上触发DoS条件。当然，这是假设下游LSR缺乏保护机制。
The authors would like 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.
作者要感谢Adrian Ceplenu、Bruce Davie、Rick Huber、Chris Metz、Pradosh Mohapatra、Ashok Narayanan、Carlos Pignataro、Eric Rosen、Mark Szczesniak和Yung Yu提出的宝贵意见和建议。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]Postel，J.，“互联网协议”，标准5，RFC7911981年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]Rosen，E.，Viswanathan，A.，和R.Callon，“多协议标签交换体系结构”，RFC 30312001年1月。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[RFC3032]Rosen，E.，Tappan，D.，Fedorkow，G.，Rekhter，Y.，Farinaci，D.，Li，T.，和A.Conta，“MPLS标签堆栈编码”，RFC 3032，2001年1月。
[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.
[RFC2205]Braden，R.，Ed.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源预留协议（RSVP）——版本1功能规范”，RFC 22052997年9月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[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.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[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.
[RFC3270]Le Faucheur，F.，Wu，L.，Davie，B.，Davari，S.，Vaananen，P.，Krishnan，R.，Cheval，P.，和J.Heinanen，“区分服务的多协议标签交换（MPLS）支持”，RFC 32702002年5月。
[RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, January 2003.
[RFC3443]Agarwal，P.和B.Akyol，“多协议标签交换（MPLS）网络中的生存时间（TTL）处理”，RFC 3443，2003年1月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364]Rosen，E.和Y.Rekhter，“BGP/MPLS IP虚拟专用网络（VPN）”，RFC 4364，2006年2月。
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[RFC4379]Kompella，K.和G.Swallow，“检测多协议标签交换（MPLS）数据平面故障”，RFC 4379，2006年2月。
[RFC4381] Behringer, M., "Analysis of the Security of BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4381, February 2006.
[RFC4381]Behringer，M.，“BGP/MPLS IP虚拟专用网络（VPN）的安全性分析”，RFC 4381，2006年2月。
[RFC4950] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "ICMP Extensions for Multiprotocol Label Switching", RFC 4950, August 2007.
[RFC4950]Bonica，R.，Gan，D.，Tappan，D.，和C.Pignataro，“多协议标签交换的ICMP扩展”，RFC 49502007年8月。
[IANA] "IP Option Numbers," IANA, February 15, 2007, <www.iana.org>.
[IANA]“IP选项编号”，IANA，2007年2月15日，<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.
[RFC5462]Andersson，L.和R.Asati，“多协议标签交换（MPLS）标签堆栈条目：“EXP”字段重命名为“流量类”字段”，RFC 5462，2009年2月。
Authors' Addresses
作者地址
David J. Smith Cisco Systems 111 Wood Avenue South Iselin, NJ 08830 EMail: djsmith@cisco.com
David J.Smith思科系统公司，地址：新泽西州伊塞林南伍德大道111号，邮编：08830电子邮件：djsmith@cisco.com
John Mullooly Cisco Systems 111 Wood Avenue South Iselin, NJ 08830 EMail: jmullool@cisco.com
约翰·穆鲁利思科系统公司，地址：新泽西州伊塞林南伍德大道111号，邮编：08830电子邮件：jmullool@cisco.com
William Jaeger AT&T 200 S. Laurel Avenue Middletown, NJ 07748 EMail: wjaeger@att.com
William Jaeger AT&T 200 S.Laurel Avenue Middletown，NJ 07748电子邮件：wjaeger@att.com
Tom Scholl nLayer Communications 209 West Jackson, Suite 700 Chicago, IL 60606 EMail: tscholl@nlayer.net
Tom Scholl nLayer Communications 209 West Jackson，伊利诺伊州芝加哥700套房60606电子邮件：tscholl@nlayer.net