Internet Engineering Task Force (IETF) F. Le Faucheur, Ed.
Request for Comments: 6398 Cisco
BCP: 168 October 2011
Updates: 2113, 2711
Category: Best Current Practice
ISSN: 2070-1721
Internet Engineering Task Force (IETF) F. Le Faucheur, Ed.
Request for Comments: 6398 Cisco
BCP: 168 October 2011
Updates: 2113, 2711
Category: Best Current Practice
ISSN: 2070-1721
IP Router Alert Considerations and Usage
IP路由器警报注意事项和使用
Abstract
摘要
The IP Router Alert Option is an IP option that alerts transit routers to more closely examine the contents of an IP packet. The Resource reSerVation Protocol (RSVP), Pragmatic General Multicast (PGM), the Internet Group Management Protocol (IGMP), Multicast Listener Discovery (MLD), Multicast Router Discovery (MRD), and General Internet Signaling Transport (GIST) are some of the protocols that make use of the IP Router Alert Option. This document discusses security aspects and usage guidelines around the use of the current IP Router Alert Option, thereby updating RFC 2113 and RFC 2711. Specifically, it provides recommendations against using the Router Alert in the end-to-end open Internet and identifies controlled environments where protocols depending on Router Alert can be used safely. It also provides recommendations about protection approaches for service providers. Finally, it provides brief guidelines for Router Alert implementation on routers.
IP路由器警报选项是一个IP选项，用于提醒传输路由器更仔细地检查IP数据包的内容。资源预留协议（RSVP）、实用通用多播（PGM）、Internet组管理协议（IGMP）、多播侦听器发现（MLD）、多播路由器发现（MRD）和通用Internet信令传输（GIST）是使用IP路由器警报选项的一些协议。本文档讨论了有关当前IP路由器警报选项使用的安全方面和使用指南，从而更新了RFC 2113和RFC 2711。具体而言，它提供了在端到端开放Internet中使用路由器警报的建议，并确定了可安全使用依赖于路由器警报的协议的受控环境。它还为服务提供商提供了有关保护方法的建议。最后，它提供了路由器警报在路由器上实现的简要指南。
Status of This Memo
关于下段备忘
This memo documents an Internet Best Current Practice.
本备忘录记录了互联网最佳实践。
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 BCPs is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关BCP的更多信息，请参见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/rfc6398.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6398.
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. Introduction ....................................................3
2. Terminology .....................................................4
2.1. Conventions Used in This Document ..........................4
3. Security Concerns of Router Alert ...............................5
4. Guidelines for Use of Router Alert ..............................7
4.1. Use of Router Alert End to End in the Internet
(Router Alert in Peer Model) ...............................7
4.2. Use of Router Alert in Controlled Environments .............9
4.2.1. Use of Router Alert within an Administrative
Domain ..............................................9
4.2.2. Use of Router Alert in Overlay Model ...............11
4.3. Router Alert Protection Approaches for Service Providers ..13
5. Guidelines for Router Alert Implementation .....................15
6. Security Considerations ........................................16
7. Contributors ...................................................16
8. Acknowledgments ................................................16
9. References .....................................................17
9.1. Normative References ......................................17
9.2. Informative References ....................................17
1. Introduction ....................................................3
2. Terminology .....................................................4
2.1. Conventions Used in This Document ..........................4
3. Security Concerns of Router Alert ...............................5
4. Guidelines for Use of Router Alert ..............................7
4.1. Use of Router Alert End to End in the Internet
(Router Alert in Peer Model) ...............................7
4.2. Use of Router Alert in Controlled Environments .............9
4.2.1. Use of Router Alert within an Administrative
Domain ..............................................9
4.2.2. Use of Router Alert in Overlay Model ...............11
4.3. Router Alert Protection Approaches for Service Providers ..13
5. Guidelines for Router Alert Implementation .....................15
6. Security Considerations ........................................16
7. Contributors ...................................................16
8. Acknowledgments ................................................16
9. References .....................................................17
9.1. Normative References ......................................17
9.2. Informative References ....................................17
[RFC2113] and [RFC2711] define the IPv4 and IPv6 Router Alert Options (RAOs), respectively. In this document, we collectively refer to those options as the IP Router Alert. The IP Router Alert Option is an IP option that alerts transit routers to more closely examine the contents of an IP packet.
[RFC2113]和[RFC2711]分别定义IPv4和IPv6路由器警报选项（RAO）。在本文档中，我们将这些选项统称为IP路由器警报。IP路由器警报选项是一个IP选项，用于提醒传输路由器更仔细地检查IP数据包的内容。
Some of the protocols that make use of the IP Router Alert are the Resource reSerVation Protocol (RSVP) ([RFC2205], [RFC3175], [RFC3209]), Pragmatic General Multicast (PGM) ([RFC3208]), the Internet Group Management Protocol (IGMP) ([RFC3376]), Multicast Listener Discovery (MLD) ([RFC2710], [RFC3810]), Multicast Router Discovery (MRD) ([RFC4286]), and Next Steps in Signaling (NSIS) General Internet Signaling Transport (GIST) ([RFC5971]).
使用IP路由器警报的一些协议包括资源保留协议（RSVP）（[RFC2205]、[RFC3175]、[RFC3209]）、实用通用多播（PGM）（[RFC3208]）、Internet组管理协议（IGMP）（[RFC3376]）、多播侦听器发现（MLD）（[RFC2710]、[RFC3810]）、多播路由器发现（MRD）（[RFC4286]），以及信令（NSIS）通用互联网信令传输（GIST）（[RFC5971]）的下一步。
Section 3 describes the security concerns associated with the use of the Router Alert Option.
第3节描述了与使用路由器警报选项相关的安全问题。
Section 4 provides guidelines for the use of Router Alert. More specifically, Section 4.1 recommends that Router Alert not be used for end-to-end applications over the Internet, while Section 4.2 presents controlled environments where applications/protocols relying on IP Router Alert can be deployed effectively and safely. Section 4.3 provides recommendations on protection approaches to be used by service providers in order to protect their network from Router-Alert-based attacks.
第4节提供了路由器警报的使用指南。更具体地说，第4.1节建议不要将路由器警报用于互联网上的端到端应用程序，而第4.2节介绍了受控环境，在这些环境中，可以有效和安全地部署依赖于IP路由器警报的应用程序/协议。第4.3节提供了关于服务提供商使用的保护方法的建议，以保护其网络免受基于路由器警报的攻击。
Finally, Section 5 provides generic recommendations for router implementation of Router Alert, aiming at increasing protection against attacks.
最后，第5节提供了路由器实施路由器警报的一般建议，旨在增强对攻击的保护。
This document discusses considerations and practices based on the current specifications of IP Router Alert ([RFC2113], [RFC2711]). Possible future enhancements to the specifications of IP Router Alert (in view of reducing the security risks associated with the use of IP Router Alert) are outside the scope of this document. One such proposal is discussed in [RAO-EXT], but at the time of this writing, the IETF has not adopted any extensions for this purpose.
本文档讨论了基于当前IP路由器警报规范（[RFC2113]、[RFC2711]）的注意事项和实践。未来可能对IP路由器警报规范进行的增强（以降低与使用IP路由器警报相关的安全风险）不在本文档范围内。[RAO-EXT]中讨论了一个此类提案，但在撰写本文时，IETF尚未为此目的采用任何扩展。
The IPv6 base specification [RFC2460] defines the hop-by-hop options extension header. The hop-by-hop options header is used to carry optional information that must be examined by every node along a packet's delivery path. The IPv6 Router Alert Option is one particular hop-by-hop option. Similar security concerns to those discussed in this document for the IPv6 Router Alert apply more generically to the concept of the IPv6 hop-by-hop options extension header. However, thoroughly addressing the broader concept of the
IPv6基本规范[RFC2460]定义了逐跳选项扩展标头。hop-by-hop-options报头用于携带可选信息，这些信息必须由每个节点沿着数据包的传递路径进行检查。IPv6路由器警报选项是一个特定的逐跳选项。与本文档中针对IPv6路由器警报讨论的安全问题类似的安全问题更一般地适用于IPv6逐跳选项扩展标头的概念。但是，要彻底解决
IPv6 hop-by-hop option would require additional material so as to cover additional considerations associated with it (e.g., the effectiveness of the attack could depend on how many options are included and on the range to which the option-type value belongs), so this is kept outside the scope of this document. A detailed discussion about security risks and proposed remedies associated with the IPv6 hop-by-hop option can be found in [IPv6-HOPBYHOP].
IPv6逐跳选项将需要额外的材料，以涵盖与之相关的其他考虑因素（例如，攻击的有效性可能取决于包含的选项数量以及选项类型值所属的范围），因此这不在本文档的范围内。有关与IPv6逐跳选项相关的安全风险和建议补救措施的详细讨论，请参见[IPv6 HOPBYHOP]。
The IPv4 base specification [RFC0791] defines a general notion of IPv4 options that can be included in the IPv4 header (without distinguishing between the hop-by-hop and end-to-end options). The IPv4 Router Alert Option is one particular IPv4 option. Security concerns similar to those discussed in this document for the IPv4 Router Alert apply more generically to the concept of the IPv4 option. However, thoroughly addressing the security concerns of the broader concept of the IPv4 option is kept outside the scope of this document, because it would require additional material so as to cover additional considerations associated with it (such as lack of option ordering, etc.), and because other IPv4 options are often blocked in firewalls and not very widely used, so the practical risks they present are largely nonexistent.
IPv4基本规范[RFC0791]定义了可以包含在IPv4标头中的IPv4选项的一般概念（不区分逐跳和端到端选项）。IPv4路由器警报选项是一个特定的IPv4选项。与本文档中讨论的IPv4路由器警报类似的安全问题更一般地适用于IPv4选项的概念。但是，彻底解决IPv4选项更广泛概念的安全问题不在本文件范围内，因为它需要额外的材料，以涵盖与之相关的额外考虑因素（如缺少选项排序等），而且，由于其他IPv4选项通常在防火墙中被阻止，并且没有得到广泛应用，因此它们所带来的实际风险基本上不存在。
For readability, this document uses the following loosely defined terms:
为了便于阅读，本文档使用了以下松散定义的术语：
o Fast path: Hardware or Application-Specific Integrated Circuit (ASIC) processing path for packets. This is the nominal processing path within a router for IP datagrams.
o 快速路径：用于数据包的硬件或专用集成电路（ASIC）处理路径。这是路由器内IP数据报的标称处理路径。
o Slow path: Software processing path for packets. This is a sub-nominal processing path for packets that require special processing or differ from assumptions made in fast-path heuristics.
o 慢路径：包的软件处理路径。这是需要特殊处理或不同于快速路径启发式中假设的数据包的次标称处理路径。
o Next level protocol: The protocol transported in the IP datagram. In IPv4 [RFC0791], the next level protocol is identified by the IANA protocol number conveyed in the 8-bit "Protocol" field in the IPv4 header. In IPv6 [RFC2460], the next level protocol is identified by the IANA protocol number conveyed in the 8-bit "Next Header" field in the IPv6 header.
o 下一级协议：在IP数据报中传输的协议。在IPv4[RFC0791]中，下一级协议由IPv4报头中8位“协议”字段中传输的IANA协议号标识。在IPv6[RFC2460]中，下一级协议由IPv6报头中8位“下一个报头”字段中传输的IANA协议号标识。
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]中所述进行解释。
The IP Router Alert Option is defined ([RFC2113], [RFC2711]) as a mechanism that alerts transit routers to more closely examine the contents of an IP packet. [RFC4081] and [RFC2711] mention the security risks associated with the use of the IP Router Alert: flooding a router with bogus (or simply undesired) IP datagrams that contain the IP Router Alert could impact operation of the router in undesirable ways. For example, if the router punts the datagrams containing the IP Router Alert Option to the slow path, such an attack could consume a significant share of the router's slow path and could also lead to packet drops in the slow path (affecting operation of all other applications and protocols operating in the slow path), thereby resulting in a denial of service (DoS) ([RFC4732]).
IP路由器警报选项被定义为一种机制（[RFC2113]、[RFC2711]），用于向传输路由器发出警报，以便更仔细地检查IP数据包的内容。[RFC4081]和[RFC2711]提到了与使用IP路由器警报相关的安全风险：用包含IP路由器警报的虚假（或根本不需要的）IP数据报淹没路由器可能会以不希望的方式影响路由器的运行。例如，如果路由器将包含IP路由器警报选项的数据报推送到慢路径，则此类攻击可能会消耗路由器慢路径的很大一部分，还可能导致慢路径中的数据包丢失（影响在慢路径中运行的所有其他应用程序和协议的运行），从而导致拒绝服务（DoS）（[RFC4732]）。
Furthermore, [RFC2113] specifies no (and [RFC2711] specifies a very limited) mechanism for identifying different users of IP Router Alert. As a result, many fast switching implementations of IP Router Alert punt most/all packets marked with IP Router Alert into the slow path (unless configured to systematically ignore or drop all Router Alert packets). However, some existing deployed IP routers can and do process IP packets containing the Router Alert Option inside the fast path.
此外，[RFC2113]没有指定（并且[RFC2711]指定了非常有限的）机制来识别IP路由器警报的不同用户。因此，许多IP路由器警报的快速交换实现将标记有IP路由器警报的大多数/所有数据包推送到慢速路径（除非配置为系统地忽略或丢弃所有路由器警报数据包）。但是，一些现有部署的IP路由器可以并且确实在快速路径中处理包含路由器警报选项的IP数据包。
Some IP Router Alert implementations are able to take into account the next level protocol as a discriminator for the punting decision for different protocols using IP Router Alert. However, this still only allows very coarse triage among various protocols using IP Router Alert, for two reasons. First, the next level protocol is the same when IP Router Alert is used for different applications of the same protocol (e.g., RSVP vs. RSVP - Traffic Engineering (RSVP-TE)), or when IP Router Alert is used for different contexts of the same application (e.g., different levels of RSVP aggregation [RFC3175]). Thus, it is not always possible to achieve the necessary triage in the fast path across IP Router Alert packets from different applications or from different contexts of an application. Secondly, some protocols requiring punting might be carried over a transport protocol (e.g., TCP or UDP), possibly because (1) they require the services of that transport protocol, (2) the protocol does not justify allocation of a scarce next level protocol value, or (3) not relying on a very widely deployed transport protocol is likely to result in deployment issues due to common middlebox behaviors (e.g., firewalls or NATs discarding packets of "unknown" protocols). Thus, considering the next level protocol alone in the fast path is not sufficient to allow triage in the fast path of IP Router Alert
一些IP路由器警报实现能够将下一级协议作为使用IP路由器警报的不同协议的下注决策的鉴别器考虑在内。然而，这仍然只允许使用IP路由器警报在各种协议之间进行非常粗略的分类，原因有二。首先，当IP路由器警报用于同一协议的不同应用程序时（例如，RSVP与RSVP-流量工程（RSVP-TE）），或者当IP路由器警报用于同一应用程序的不同上下文时（例如，不同级别的RSVP聚合[RFC3175]），下一级协议是相同的。因此，并非总是能够在来自不同应用程序或来自不同应用程序上下文的IP路由器警报数据包的快速路径中实现必要的分类。第二，一些需要punting的协议可能通过传输协议（例如TCP或UDP）进行传输，这可能是因为（1）它们需要该传输协议的服务，（2）该协议不支持分配稀缺的下一级协议值，或（3）由于常见的中间盒行为（例如，防火墙或NAT丢弃“未知”协议的数据包），不依赖广泛部署的传输协议可能会导致部署问题。因此，仅考虑快速路径中的下一级协议不足以允许在IP路由器警报的快速路径中进行分类
packets from different protocols sharing the same transport protocol. Therefore, it is generally not possible to ensure that only the IP Router Alert packets for next level protocols of interest are punted to the slow path while other IP Router Alert packets are efficiently forwarded (i.e., in the fast path).
来自不同协议的数据包共享相同的传输协议。因此，通常不可能确保只有下一级感兴趣协议的IP路由器警报包被推送到慢路径，而其他IP路由器警报包被有效地转发（即，在快路径中）。
Some IP Router Alert implementations are able to take into account the Value field inside the Router Alert Option. However, only one value (zero) was defined in [RFC2113], and no IANA registry for IPv4 Router Alert values was available until recently ([RFC5350]). So this did not allow most IPv4 Router Alert implementations to support useful classification based on the Value field in the fast path. Also, while [RFC2113] states that unknown values should be ignored (i.e., the packets should be forwarded as normal IP traffic), it has been reported that some existing implementations simply ignore the Value field completely (i.e., process any packet with an IPv4 Router Alert regardless of its option value). An IANA registry for further allocation of IPv4 Router Alert values has been introduced recently ([RFC5350]), but this would only allow coarse-grain classification, if supported by implementations. For IPv6, [RFC2711] states that "the Value field can be used by an implementation to speed processing of the datagram within the transit router" and defines an IANA registry for these values. But again, this only allows coarse-grain classification. Besides, some existing IPv6 Router Alert implementations are reported to depart from that behavior.
一些IP路由器警报实现能够考虑路由器警报选项内的值字段。但是，[RFC2113]中只定义了一个值（零），并且直到最近（[RFC5350]）才提供IPv4路由器警报值的IANA注册表。因此，这不允许大多数IPv4路由器警报实现支持基于快速路径中的值字段的有用分类。此外，尽管[RFC2113]指出应忽略未知值（即，数据包应作为正常IP流量转发），但据报道，一些现有实现完全忽略值字段（即，处理任何带有IPv4路由器警报的数据包，无论其选项值如何）。最近引入了用于进一步分配IPv4路由器警报值的IANA注册表（[RFC5350]），但如果实现支持，这将只允许粗粒度分类。对于IPv6，[RFC2711]声明“值字段可由实现用于加快传输路由器内数据报的处理”，并为这些值定义IANA注册表。但同样，这只允许粗粒度分类。此外，据报道，一些现有的IPv6路由器警报实现偏离了这种行为。
[RFC2711] mentions that limiting, by rate or some other means, the use of the IP Router Alert Option is a way of protecting against a potential attack. However, if rate limiting is used as a protection mechanism, but if the granularity of the rate limiting is not fine enough to distinguish IP Router Alert packets of interest from unwanted IP Router Alert packets, an IP Router Alert attack could still severely degrade operation of protocols of interest that depend on the use of IP Router Alert.
[RFC2711]提到，通过速率或其他方式限制IP路由器警报选项的使用是防止潜在攻击的一种方法。但是，如果将速率限制用作保护机制，但如果速率限制的粒度不足以区分感兴趣的IP路由器警报数据包和不需要的IP路由器警报数据包，则IP路由器警报攻击仍可能严重降低依赖于IP路由器警报使用的感兴趣协议的操作。
In a nutshell, the IP Router Alert Option does not provide a convenient universal mechanism to accurately and reliably distinguish between IP Router Alert packets of interest and unwanted IP Router Alert packets. This, in turn, creates a security concern when the IP Router Alert Option is used, because, short of appropriate router-implementation-specific mechanisms, the router slow path is at risk of being flooded by unwanted traffic.
简言之，IP路由器警报选项不提供方便的通用机制来准确可靠地区分感兴趣的IP路由器警报数据包和不需要的IP路由器警报数据包。这反过来又会在使用IP路由器警报选项时产生安全问题，因为如果没有适当的路由器实现特定机制，路由器慢路径有被不需要的流量淹没的风险。
Note that service providers commonly allow external parties to communicate with a control plane application in their routers, such as with BGP peering. Depending on the actual environment and BGP security practices, with BGP peering, the resulting DoS attack vector is similar to or somewhat less serious than it would be with the Router Alert Option for a number of reasons, including the following:
请注意，服务提供商通常允许外部各方在其路由器中与控制平面应用程序通信，例如使用BGP对等。根据实际环境和BGP安全实践，使用BGP对等，由于许多原因，所产生的DoS攻击向量与路由器警报选项相似或稍不严重，包括以下内容：
o With BGP, edge routers only exchange control plane information with pre-identified peers and can easily filter out any control plane traffic coming from other peers or non-authenticated peers, while the Router Alert Option can be received in a datagram with any source address and any destination address. However, we note that the effectiveness of such BGP filtering is dependent on proper security practices; poor BGP security practices (such as infrequent or nonexistent update of BGP peers' authentication keys) create vulnerabilities through which the BGP authentication mechanisms can be compromised.
o 使用BGP，边缘路由器仅与预先识别的对等方交换控制平面信息，并可轻松过滤来自其他对等方或未经认证的对等方的任何控制平面流量，而路由器警报选项可在具有任何源地址和任何目的地地址的数据报中接收。然而，我们注意到，这种BGP过滤的有效性取决于适当的安全实践；不良的BGP安全实践（例如，BGP对等方的身份验证密钥的更新不频繁或不存在）会造成漏洞，从而危及BGP身份验证机制。
o With BGP peering, the control plane hole is only open on the edge routers, and core routers are completely isolated from any direct control plane exchange with entities outside the administrative domain. Thus, with BGP, a DoS attack would only affect the edge routers, while with the Router Alert Option, the attack could propagate to core routers. However, in some BGP environments, the distinction between edge and core routers is not strict, and many/ most/all routers act as both edge and core routers; in such BGP environments, a large part of the network is exposed to direct control plane exchanges with entities outside the administrative domain (as it would be with Router Alert).
o 通过BGP对等，控制平面孔仅在边缘路由器上打开，核心路由器与任何与管理域外实体的直接控制平面交换完全隔离。因此，使用BGP时，DoS攻击只会影响边缘路由器，而使用路由器警报选项时，攻击可能会传播到核心路由器。然而，在某些BGP环境中，边缘路由器和核心路由器之间的区别并不严格，许多/大多数/所有路由器同时充当边缘路由器和核心路由器；在这种BGP环境中，网络的很大一部分暴露于与管理域之外的实体进行的直接控制平面交换（与路由器警报一样）。
o With BGP, the BGP policy control would typically prevent re-injection of undesirable information out of the attacked device, while with the Router Alert Option, the non-filtered attacking messages would typically be forwarded downstream. However, we note that there have been real-life occurrences of situations where incorrect information was propagated through the BGP system, causing widespread problems.
o 使用BGP时，BGP策略控制通常会防止不良信息从受攻击设备中重新注入，而使用路由器警报选项时，未过滤的攻击消息通常会转发到下游。然而，我们注意到，在现实生活中曾出现过通过BGP系统传播错误信息的情况，导致了广泛的问题。
4.1. Use of Router Alert End to End in the Internet (Router Alert in Peer Model)
4.1. 在Internet中端到端使用路由器警报（对等模型中的路由器警报）
Because of the security concerns associated with Router Alert discussed in Section 3, network operators SHOULD actively protect themselves against externally generated IP Router Alert packets. Because there are no convenient universal mechanisms to triage between desired and undesired Router Alert packets, network operators
由于第3节讨论了与路由器警报相关的安全问题，网络运营商应积极保护自己免受外部生成的IP路由器警报数据包的影响。由于没有方便的通用机制来区分所需和不需要的路由器警报数据包，网络运营商
currently often protect themselves in ways that isolate them from externally generated IP Router Alert packets. This might be achieved by tunneling IP Router Alert packets [RFC6178] so that the IP Router Alert Option is hidden through that network, or it might be achieved via mechanisms resulting in occasional (e.g., rate limiting) or systematic drop of IP Router Alert packets.
目前，通常通过将它们与外部生成的IP路由器警报数据包隔离的方式来保护它们自己。这可以通过隧道IP路由器警报数据包[RFC6178]来实现，以便通过该网络隐藏IP路由器警报选项，也可以通过导致IP路由器警报数据包偶尔（例如，速率限制）或系统性丢弃的机制来实现。
Thus, applications and protocols SHOULD NOT be deployed with a dependency on processing of the Router Alert Option (as currently specified) across independent administrative domains in the Internet. Figure 1 illustrates such a hypothetical use of Router Alert end to end in the Internet. We refer to such a model of Router Alert Option use as a "Peer Model" Router Alert Option use, since core routers in different administrative domains would partake in processing of Router Alert Option datagrams associated with the same signaling flow.
因此，部署应用程序和协议时，不应依赖于在Internet上跨独立管理域处理路由器警报选项（如当前指定的）。图1说明了路由器警报在Internet中端到端的假设使用。我们将这种路由器警报选项使用模型称为“对等模型”路由器警报选项使用，因为不同管理域中的核心路由器将参与处理与相同信令流相关联的路由器警报选项数据报。
-------- -------- -------- --------
/ A \ / B \ / C \ / D \
| (*) | | (*) | | (*) | | (*) |
| | |<============>| |<=============>| |<=============>| | |
| - | | - | | - | | - |
\ / \ / \ / \ /
-------- -------- -------- --------
-------- -------- -------- --------
/ A \ / B \ / C \ / D \
| (*) | | (*) | | (*) | | (*) |
| | |<============>| |<=============>| |<=============>| | |
| - | | - | | - | | - |
\ / \ / \ / \ /
-------- -------- -------- --------
(*) closer examination of Router Alert Option datagrams
（*）仔细检查路由器警报选项数据报
<==> flow of Router Alert Option datagrams
<==> flow of Router Alert Option datagrams
Figure 1: Use of Router Alert End to End in the Open Internet (Router Alert in Peer Model)
图1：在开放互联网中端到端使用路由器警报（对等模型中的路由器警报）
While this recommendation is framed here specifically in the context of Router Alert, the fundamental security risk that network operators want to preclude is to allow devices/protocols that are outside of their administrative domain (and therefore not controlled) to tap into the control plane of their core routers. Similar security concerns would probably result whether this control plane access is provided through the Router Alert Option or provided by any other mechanism (e.g., deep packet inspection). In other words, the fundamental security concern is associated with the notion of end-to-end signaling in a Peer Model across domains in the Internet. As a result, it is expected that network operators would typically not want to have their core routers partake in end-to-end signaling with external uncontrolled devices through the open Internet, and therefore prevent deployment of end-to-end signaling in a Peer Model through their network (regardless of whether that signaling uses Router Alert or not).
虽然本建议是在路由器警报的背景下提出的，但网络运营商希望排除的基本安全风险是允许其管理域之外（因此不受控制）的设备/协议接入其核心路由器的控制平面。无论此控制平面访问是通过路由器警报选项提供的，还是通过任何其他机制（例如，深度数据包检查）提供的，都可能导致类似的安全问题。换句话说，基本的安全问题与互联网中跨域对等模型中端到端信令的概念有关。因此，预计网络运营商通常不希望其核心路由器通过开放互联网与外部非受控设备一起参与端到端信令，从而阻止通过其网络在对等模型中部署端到端信令（无论该信令是否使用路由器警报）。
In some controlled environments, such as within a given administrative domain, the network administrator can determine that IP Router Alert packets will only be received from trusted well-behaved devices or can establish that specific protection mechanisms (e.g., RAO filtering and rate limiting) against the plausible RAO-based DoS attacks are sufficient. In that case, an application relying on exchange and handling of RAO packets (e.g., RSVP) can be safely deployed within the controlled network. A private enterprise network firewalled from the Internet and using RSVP reservations for voice and video flows might be an example of such a controlled environment. Such an environment is illustrated in Figure 2.
在某些受控环境中，例如在给定的管理域内，网络管理员可以确定IP路由器警报数据包将仅从受信任的行为良好的设备接收，或者可以建立特定的保护机制（例如RAO过滤和速率限制）针对看似合理的基于RAO的DoS攻击就足够了。在这种情况下，依赖于RAO数据包（例如，RSVP）的交换和处理的应用程序可以安全地部署在受控网络中。从互联网防火墙连接的私有企业网络，并使用语音和视频流的RSVP预约，可能就是这种受控环境的一个例子。这种环境如图2所示。
------------------------- -------- --------
/ A \ / B \ / C \
| (*) (*) | -- | | | |
| | |<============>| | |--|FW|--| |--------| |
| - - | -- | | | |
\ / \ / \ /
------------------------- -------- --------
------------------------- -------- --------
/ A \ / B \ / C \
| (*) (*) | -- | | | |
| | |<============>| | |--|FW|--| |--------| |
| - - | -- | | | |
\ / \ / \ /
------------------------- -------- --------
(*) closer examination of Router Alert Option datagrams
（*）仔细检查路由器警报选项数据报
<==> flow of Router Alert Option datagrams
<==> flow of Router Alert Option datagrams
FW: Firewall
防火墙
Figure 2: Use of Router Alert within an Administrative Domain - Private Enterprise Network Firewalled from the Internet and Using RSVP Reservations
图2：在管理域内使用路由器警报-从Internet通过防火墙连接并使用RSVP保留的私有企业网络
In some controlled environments, several administrative domains have a special relationship whereby they cooperate very tightly and effectively operate as a single trust domain. In that case, one domain is willing to trust another with respect to the traffic injected across the boundary. In other words, a downstream domain is willing to trust that the traffic injected at the boundary has been properly validated/filtered by the upstream domain. Where it has been established that such trust can be applied to Router Alert Option packets, an application relying on exchange and handling of RAO packets (e.g., RSVP) can be safely deployed within such a controlled environment. The entity within a company responsible for operating multimedia endpoints and the entity within the same company
在某些受控环境中，多个管理域具有特殊的关系，通过这种关系，它们可以紧密协作，并作为单个信任域有效地运行。在这种情况下，一个域愿意就跨边界注入的流量信任另一个域。换句话说，下游域愿意相信在边界注入的流量已经被上游域正确地验证/过滤。如果已经确定这种信任可以应用于路由器警报选项数据包，则依赖于RAO数据包（例如，RSVP）的交换和处理的应用程序可以安全地部署在这种受控环境中。公司内负责运营多媒体端点的实体和同一公司内的实体
responsible for operating the network might be an example of such a controlled environment. For example, they might collaborate so that RSVP reservations can be used for video flows from endpoints to endpoints through the network.
负责操作网络可能就是这种受控环境的一个例子。例如，他们可能会协作，以便RSVP保留可以用于通过网络从端点到端点的视频流。
In some environments, the network administrator can reliably ensure that Router Alert packets from any untrusted device (e.g., from external routers) are prevented from entering a trusted area (e.g., the internal routers). For example, this might be achieved by ensuring that routers straddling the trust boundary (e.g., edge routers) always encapsulate those packets (without setting IP Router Alert -or equivalent- in the encapsulating header) through the trusted area (as discussed in [RFC6178]). In such environments, the risks of DoS attacks through the IP Router Alert vector are removed (or greatly reduced) in the trusted area even if IP Router Alert is used inside the trusted area (say, for RSVP-TE). Thus, an application relying on IP Router Alert can be safely deployed within the trusted area. A service provider running RSVP-TE within its network might be an example of such a protected environment. Such an environment is illustrated in Figure 3.
在某些环境中，网络管理员可以可靠地确保防止来自任何不受信任设备（例如，来自外部路由器）的路由器警报数据包进入受信任区域（例如，内部路由器）。例如，这可以通过确保跨越信任边界的路由器（例如，边缘路由器）始终通过受信任区域（如[RFC6178]中所述）封装这些数据包（不在封装报头中设置IP路由器警报或等效警报）来实现。在这种环境中，通过IP路由器警报向量进行DoS攻击的风险在受信任区域内被消除（或大大降低），即使IP路由器警报在受信任区域内使用（例如，对于RSVP-TE）。因此，依赖IP路由器警报的应用程序可以安全地部署在受信任区域内。在其网络中运行RSVP-TE的服务提供商可能就是这种受保护环境的一个例子。这种环境如图3所示。
-------- -------------------------- --------
/ A \ / B \ / C \
| | | (*) (*) | | |
| |-------TT | |<=============>| | TT------- | |
| | | - - | | |
\ / \ / \ /
-------- -------------------------- --------
-------- -------------------------- --------
/ A \ / B \ / C \
| | | (*) (*) | | |
| |-------TT | |<=============>| | TT------- | |
| | | - - | | |
\ / \ / \ /
-------- -------------------------- --------
(*) closer examination of Router Alert Option datagrams
（*）仔细检查路由器警报选项数据报
<==> flow of Router Alert Option datagrams
<==> flow of Router Alert Option datagrams
TT: Tunneling of Router Alert Option datagrams
TT：路由器警报选项数据报的隧道
Figure 3: Use of Router Alert within an Administrative Domain - Service Provider Running RSVP-TE within Its Network
图3：在管理域中使用路由器警报-服务提供商在其网络中运行RSVP-TE
In some controlled environment:
在某些受控环境中：
o The sites of a network A are interconnected through a service provider network B.
o 网络a的站点通过服务提供商网络B互连。
o The service provider network B protects itself from IP Router Alert messages without dropping those messages when they transit over the network (for example, using mechanisms discussed in [RFC6178]).
o 服务提供商网络B保护自身免受IP路由器警报消息的影响，而不会在这些消息通过网络传输时丢弃这些消息（例如，使用[RFC6178]中讨论的机制）。
In such a controlled environment, an application relying on exchange and handling of RAO packets (e.g., RSVP) in the network A sites (but not inside network B) can be safely deployed. We refer to such a deployment as a use of Router Alert in a Water-Tight Overlay -- "Overlay", because Router Alert Option datagrams are used in network A on top of, and completely transparently to, network B; and "Water-Tight", because Router Alert Option datagrams from network A cannot leak inside network B. A private enterprise intranet realized as a Virtual Private Network (VPN) over a service provider network and using RSVP to perform reservations within the enterprise sites for voice and video flows might be an example of such a controlled environment. Such an environment is illustrated in Figure 4.
在这种受控环境中，可以安全地部署依赖于网络a站点（但不在网络B内）中的RAO分组（例如，RSVP）的交换和处理的应用程序。我们将这种部署称为在防水覆盖中使用路由器警报——“覆盖”，因为路由器警报选项数据报在网络B上的网络a中使用，并且对网络B完全透明；和“防水”，因为来自网络A的路由器警报选项数据报不能泄漏到网络B内部。作为虚拟专用网络（VPN）实现的私有企业内部网通过服务提供商网络并使用RSVP在企业站点内为语音和视频流执行预订可能是此类受控环境的一个示例。这种环境如图4所示。
-------- --------
/ A \ / A \
| (*) | | (*) |
| | |<=====================================>| | |
| - | | - |
\ / \ /
-------- --------
\ /
\ ------------------------- /
\ / B \ /
\| |/
TT TT
| |
\ /
-------------------------
-------- --------
/ A \ / A \
| (*) | | (*) |
| | |<=====================================>| | |
| - | | - |
\ / \ /
-------- --------
\ /
\ ------------------------- /
\ / B \ /
\| |/
TT TT
| |
\ /
-------------------------
(*) closer examination of Router Alert Option datagrams
（*）仔细检查路由器警报选项数据报
<==> flow of Router Alert Option datagrams
<==> flow of Router Alert Option datagrams
TT: Tunneling of Router Alert Option datagrams
TT：路由器警报选项数据报的隧道
Figure 4: Use of Router Alert in Water-Tight Overlay
图4：路由器警报在防水覆盖中的使用
In the controlled environment described above, an application relying on exchange and handling of RAO packets (e.g., RSVP-TE) in the service provider network B (but not in network A) can also be safely deployed simultaneously. Such an environment with independent, isolated deployment of Router Alert in overlay at two levels is illustrated in Figure 5.
在上述受控环境中，依赖于服务提供商网络B（但不在网络A）中的RAO分组（例如，RSVP-TE）的交换和处理的应用程序也可以同时安全部署。图5说明了这样一个环境，它在两个级别上独立、隔离地部署路由器警报。
-------- --------
/ A \ / A \
| (*) | | (*) |
| | |<=====================================>| | |
| - | | - |
\ / \ /
-------- --------
\ /
\ ------------------------- /
\ / B \ /
\| (*) (*) |/
TT | |<============>| | TT
| - - |
\ /
-------------------------
-------- --------
/ A \ / A \
| (*) | | (*) |
| | |<=====================================>| | |
| - | | - |
\ / \ /
-------- --------
\ /
\ ------------------------- /
\ / B \ /
\| (*) (*) |/
TT | |<============>| | TT
| - - |
\ /
-------------------------
(*) closer examination of Router Alert Option datagrams
（*）仔细检查路由器警报选项数据报
<==> flow of Router Alert Option datagrams
<==> flow of Router Alert Option datagrams
TT: Tunneling of Router Alert Option datagrams
TT：路由器警报选项数据报的隧道
Figure 5: Use of Router Alert in Water-Tight Overlay at Two Levels
图5：在两个级别的防水覆盖中使用路由器警报
In some controlled environment:
在某些受控环境中：
o The sites of a network A are interconnected through a service provider network B.
o 网络a的站点通过服务提供商网络B互连。
o The service provider B processes Router Alert packets on the edge routers and protects these edge routers against RAO-based attacks using mechanisms such as (possibly per port) RAO rate limiting and filtering.
o 服务提供商B处理边缘路由器上的路由器警报数据包，并使用诸如（可能是每个端口）RAO速率限制和过滤等机制保护这些边缘路由器免受基于RAO的攻击。
o The service provider network B protects its core routers from Router Alert messages without dropping those messages when they transit over the network (for example, using mechanisms discussed in [RFC6178]).
o 服务提供商网络B保护其核心路由器免受路由器警报消息的影响，而不会在通过网络传输时丢弃这些消息（例如，使用[RFC6178]中讨论的机制）。
In such a controlled environment, an application relying on exchange and handling of RAO packets (e.g., RSVP) in the network A sites and in network B's edges (but not in the core of network B) can be safely deployed. We refer to such a deployment as a use of Router Alert in a Leak-Controlled Overlay -- "Overlay", because Router Alert Option datagrams are used in network A on top of, and completely transparently to, network B's core; and "Leak-Controlled", because Router Alert Option datagrams from network A leak inside network B's edges but not inside network B's core. A private enterprise intranet, whose sites are interconnected through a service provider network, using RSVP for voice and video within network A sites as well as on network B's edge to extend the reservation onto the attachment links between networks A and B (as specified in [RFC6016]), might be an example of such a controlled environment. Such an environment is illustrated in Figure 6.
在这种受控环境中，可以安全地部署依赖于网络a站点和网络B的边缘（但不在网络B的核心）中的RAO分组（例如，RSVP）的交换和处理的应用程序。我们将这种部署称为在泄漏控制覆盖中使用路由器警报——“覆盖”，因为路由器警报选项数据报在网络B的核心之上的网络a中使用，并且对网络B的核心完全透明；和“泄漏控制”，因为来自网络A的路由器警报选项数据报泄漏在网络B的边缘内，而不是网络B的核心内。私有企业内部网（其站点通过服务提供商网络互连）可能是此类受控环境的一个示例，该内部网在网络A站点内以及网络B的边缘使用RSVP进行语音和视频传输，以将保留扩展到网络A和网络B之间的连接链路上（如[RFC6016]中所述）。这种环境如图6所示。
-------- --------
/ A \ / A \
| | | |
| | ------------------------ | |
| (*) | /(*) (*) \ | (*) |
| | |<======>| |<============>| |<=========>| | |
| - | | - - | | - |
\ / | \ - - / | \ /
-------- | TT-| | | |-TT | --------
| - - |
\ /
------------------------
-------- --------
/ A \ / A \
| | | |
| | ------------------------ | |
| (*) | /(*) (*) \ | (*) |
| | |<======>| |<============>| |<=========>| | |
| - | | - - | | - |
\ / | \ - - / | \ /
-------- | TT-| | | |-TT | --------
| - - |
\ /
------------------------
(*) closer examination of Router Alert Option datagrams
（*）仔细检查路由器警报选项数据报
<==> flow of Router Alert Option datagrams
<==> flow of Router Alert Option datagrams
TT: Tunneling of Router Alert Option datagrams
TT：路由器警报选项数据报的隧道
Figure 6: Use of Router Alert in Leak-Controlled Overlay
图6：在泄漏控制覆盖中使用路由器警报
Section 3 discusses the security risks associated with the use of the IP Router Alert and how it opens up a DoS vector in the router control plane. Thus, a service provider MUST implement strong protection of its network against attacks based on IP Router Alert.
第3节讨论与使用IP路由器警报相关的安全风险，以及它如何在路由器控制平面中打开DoS向量。因此，服务提供商必须基于IP路由器警报对其网络实施强大的攻击防护。
As discussed in Section 4.2.2, some applications can benefit from the use of IP Router Alert packets in an Overlay Model (i.e., where Router Alert packets are exchanged transparently on top of a service provider). Thus, a service provider protecting its network from
如第4.2.2节所述，一些应用程序可以受益于在覆盖模型中使用IP路由器警报数据包（即，路由器警报数据包在服务提供商之上透明交换）。因此，服务提供商保护其网络免受
attacks based on IP Router Alert SHOULD use mechanisms that avoid (or at least minimize) the dropping of end-to-end IP Router Alert packets (other than those involved in an attack).
基于IP路由器警报的攻击应使用避免（或至少最小化）端到端IP路由器警报数据包丢弃的机制（参与攻击的除外）。
For example, if the service provider does not run any protocol depending on IP Router Alert within its network, it might elect to simply turn off punting/processing of IP Router Alert packets on its routers; this will ensure that end-to-end IP Router Alert packets transit transparently and safely through its network.
例如，如果服务提供商在其网络内不运行任何依赖于IP路由器警报的协议，则其可能选择简单地关闭其路由器上的IP路由器警报数据包的推送/处理；这将确保端到端IP路由器警报数据包通过其网络透明安全地传输。
As another example, using protection mechanisms such as selective filtering and rate limiting (which Section 5 suggests be supported by IP Router Alert implementations), a service provider can protect the operation of a protocol depending on IP Router Alert within its network (e.g., RSVP-TE) while at the same time transporting IP Router Alert packets carrying another protocol that might be used end to end. Note that the service provider might additionally use protocol-specific mechanisms that reduce the dependency on Router Alert for operation of this protocol inside the service provider environment; use of RSVP refresh reduction mechanisms ([RFC2961]) would be an example of such mechanisms in the case where the service provider is running RSVP-TE within its network, since this allows the refresh of existing Path and Resv states without the use of the IP Router Alert Option.
作为另一个示例，使用诸如选择性过滤和速率限制（第5节建议由IP路由器警报实现支持）等保护机制，服务提供商可以根据其网络内的IP路由器警报（例如，RSVP-TE）保护协议的操作同时传输IP路由器警报数据包，其中包含另一个可能端到端使用的协议。请注意，服务提供商还可以使用特定于协议的机制，以减少对路由器警报的依赖，从而在服务提供商环境中操作该协议；在服务提供商在其网络内运行RSVP-TE的情况下，使用RSVP刷新减少机制（[RFC2961]）将是此类机制的一个示例，因为这允许在不使用IP路由器警报选项的情况下刷新现有路径和Resv状态。
As yet another example, using mechanisms such as those discussed in [RFC6178], a service provider can safely protect the operation of a protocol depending on IP Router Alert within its network (e.g., RSVP-TE) while at the same time safely transporting IP Router Alert packets carrying another protocol that might be used end to end (e.g., IPv4/IPv6 RSVP). We observe that while tunneling of Router Alert Option datagrams over an MPLS backbone as discussed in [RFC6178] is well understood, tunneling Router Alert Option datagrams over a non-MPLS IP backbone presents a number of issues (in particular, for determining where to forward the encapsulated datagram) and is not common practice at the time of writing this document.
作为又一个示例，使用[RFC6178]中讨论的机制，服务提供商可以根据其网络内的IP路由器警报（例如，RSVP-TE）安全地保护协议的操作，同时安全地传输承载可能端到端使用的另一协议的IP路由器警报包（例如，IPv4/IPv6 RSVP）。我们观察到，虽然[RFC6178]中讨论的通过MPLS主干传输路由器警报选项数据报已被充分理解，但通过非MPLS IP主干传输路由器警报选项数据报会带来许多问题（特别是在确定将封装数据报转发到何处时）在编写本文件时，这不是常见的做法。
As a last resort, if the service provider does not have any means to safely transport end-to-end IP Router Alert Option packets over its network, the service provider can drop those packets. It must be noted that this has the undesirable consequence of preventing the use of the Router Alert Option in the Overlay Model on top of that network, and therefore prevents users of that network from deploying a number of valid applications/protocols in their environment.
作为最后手段，如果服务提供商没有任何方法通过其网络安全传输端到端IP路由器警报选项数据包，则服务提供商可以丢弃这些数据包。必须注意的是，这会产生不良后果，即阻止在该网络顶部的覆盖模型中使用路由器警报选项，从而阻止该网络的用户在其环境中部署大量有效的应用程序/协议。
A router implementation of the IP Router Alert Option SHOULD include protection mechanisms against Router-Alert-based DoS attacks as appropriate for their targeted deployment environments. For example, this can include the ability of an edge router to "tunnel" received IP Router Alert Option packets when forwarding those packets over the core, as discussed in [RFC6178]. As another example, although not always available from current implementations, new implementations MAY include protection mechanisms such as selective (possibly dynamic) filtering and rate limiting of IP Router Alert Option packets.
IP路由器警报选项的路由器实现应包括针对基于路由器警报的DoS攻击的保护机制，以适合其目标部署环境。例如，如[RFC6178]中所述，这可以包括边缘路由器在通过核心转发接收到的IP路由器警报选项包时“隧道”这些包的能力。作为另一个示例，尽管当前的实现并不总是可用，但新的实现可能包括保护机制，例如选择性（可能是动态）过滤和IP路由器警报选项数据包的速率限制。
In particular, router implementations of the IP Router Alert Option SHOULD offer the configuration option to simply ignore the presence of "IP Router Alert" in IPv4 and IPv6 packets. As discussed in Section 4.3, that permits IP Router Alert packets to transit a network segment without presenting an adverse operational security risk to that particular network segment, provided the operator of that network segment does not ever use the IP Router Alert messages for any purpose.
特别是，IP路由器警报选项的路由器实现应提供配置选项，以忽略IPv4和IPv6数据包中存在的“IP路由器警报”。如第4.3节所述，允许IP路由器警报数据包传输网段，而不会对该网段造成不利的操作安全风险，前提是该网段的运营商从未将IP路由器警报消息用于任何目的。
If an IP packet contains the IP Router Alert Option, but the next level protocol is not explicitly identified as a protocol of interest by the router examining the packet, the behavior is not explicitly defined by [RFC2113]. However, the behavior is implied, and, for example, the definition of RSVP in [RFC2205] assumes that the packet will be forwarded using normal forwarding based on the destination IP address. Thus, a router implementation SHOULD forward within the "fast path" (subject to all normal policies and forwarding rules) a packet carrying the IP Router Alert Option containing a next level protocol that is not a protocol of interest to that router. The "not punting" behavior protects the router from DoS attacks using IP Router Alert packets of a protocol unknown to the router. The "forwarding" behavior contributes to transparent end-to-end transport of IP Router Alert packets (e.g., to facilitate their use by end-to-end applications).
如果IP数据包包含IP路由器警报选项，但检查数据包的路由器未明确将下一级协议标识为感兴趣的协议，则[RFC2113]未明确定义该行为。然而，该行为是隐含的，并且，例如，[RFC2205]中的RSVP定义假设将使用基于目的地IP地址的正常转发来转发分组。因此，路由器实现应在“快速路径”（符合所有正常策略和转发规则）内转发携带IP路由器警报选项的数据包，该选项包含下一级协议，该协议不是该路由器感兴趣的协议。“不下注”行为使用路由器未知协议的IP路由器警报数据包保护路由器免受DoS攻击。“转发”行为有助于IP路由器警报数据包的端到端透明传输（例如，便于端到端应用程序使用）。
Similarly, an implementation MAY support selective forwarding within the fast path (subject to all normal policies and forwarding rules) or punting of a packet with the IP Router Alert Option, based on the Value field of the Router Alert Option. This would allow router protection against DoS attacks using IP Router Alert packets with a value that is not relevant for that router (e.g., nesting levels of aggregated RSVP reservation [RFC5350]).
类似地，实现可以基于路由器警报选项的值字段，支持快速路径内的选择性转发（服从所有正常策略和转发规则）或使用IP路由器警报选项对分组进行推送。这将允许路由器使用与该路由器无关的值（例如，聚合RSVP保留的嵌套级别[RFC5350]）的IP路由器警报数据包来防止DoS攻击。
This document expands the security considerations of [RFC2113] and [RFC2711], which define the IPv4 and IPv6 RAOs, respectively, by discussing security risks associated with usage of the current IP Router Alert Option and associated practices. See [RFC4081] for additional security considerations.
本文档通过讨论与使用当前IP路由器警报选项和相关实践相关的安全风险，扩展了分别定义IPv4和IPv6 RAO的[RFC2113]和[RFC2711]的安全注意事项。有关其他安全注意事项，请参阅[RFC4081]。
The contributors to this document (in addition to the editor) are:
本文档的贡献者（除编辑器外）包括：
Reshad Rahman Cisco Systems rrahman@cisco.com
雷沙德·拉赫曼思科系统公司rrahman@cisco.com
David Ward Juniper Networks dward@juniper.net
David Ward Juniper网络dward@juniper.net
Ashok Narayanan Cisco Systems ashokn@cisco.com
Ashok Narayanan思科系统公司ashokn@cisco.com
Adrian Farrel OldDog Consulting adrian@olddog.co.uk
阿德里安·法雷尔老狗咨询公司adrian@olddog.co.uk
Tony Li Cisco Systems tony.li@tony.li
托尼·李思科系统公司托尼。li@tony.li
The editor and contributors would like to thank Dave Oran, Magnus Westerlund, John Scudder, Ron Bonica, Ross Callon, Alfred Hines, Carlos Pignataro, Roland Bless, Jari Arkko, and Ran Atkinson for their comments. This document also benefited from discussions with Jukka Manner and Suresh Krishnan. The discussion about use of the Value field in the IPv4 Router Alert is borrowed from a similar discussion in [RFC5971].
编辑和撰稿人要感谢戴夫·奥兰、马格努斯·维斯特隆德、约翰·斯卡德尔、罗恩·博尼卡、罗斯·卡隆、阿尔弗雷德·海因斯、卡洛斯·皮格纳塔罗、罗兰·布莱斯、贾里·阿克科和冉·阿特金森的评论。本文件还得益于与朱卡·韦德和苏雷什·克里希南的讨论。有关IPv4路由器警报中值字段使用的讨论借鉴了[RFC5971]中的类似讨论。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791]Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[RFC2113]Katz，D.，“IP路由器警报选项”，RFC 21131997年2月。
[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月。
[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月。
[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, October 1999.
[RFC2711]帕特里奇，C.和A.杰克逊，“IPv6路由器警报选项”，RFC27111999年10月。
[RFC5350] Manner, J. and A. McDonald, "IANA Considerations for the IPv4 and IPv6 Router Alert Options", RFC 5350, September 2008.
[RFC5350]Way，J.和A.McDonald，“IPv4和IPv6路由器警报选项的IANA注意事项”，RFC 5350，2008年9月。
[IPv6-HOPBYHOP] Krishnan, S., "The case against Hop-by-Hop options", Work in Progress, October 2010.
[IPv6 HOPBYHOP]Krishnan，S.，“反对逐跳选项的案例”，正在进行的工作，2010年10月。
[RAO-EXT] Narayanan, A., Le Faucheur, F., Ward, D., and R. Rahman, "IP Router Alert Option Extension", Work in Progress, March 2009.
[RAO-EXT]Narayanan，A.，Le Faucheur，F.，Ward，D.，和R.Rahman，“IP路由器警报选项扩展”，正在进行的工作，2009年3月。
[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月。
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[RFC2710]Deering，S.，Fenner，W.，和B.Haberman，“IPv6的多播侦听器发现（MLD）”，RFC 2710，1999年10月。
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., and S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, April 2001.
[RFC2961]Berger，L.，Gan，D.，Swallow，G.，Pan，P.，Tommasi，F.，和S.Molendini，“RSVP刷新开销减少扩展”，RFC 29612001年4月。
[RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001.
[RFC3175]Baker，F.，Iturralde，C.，Le Faucheur，F.，和B.Davie，“IPv4和IPv6保留的RSVP聚合”，RFC 3175，2001年9月。
[RFC3208] Speakman, T., Crowcroft, J., Gemmell, J., Farinacci, D., Lin, S., Leshchiner, D., Luby, M., Montgomery, T., Rizzo, L., Tweedly, A., Bhaskar, N., Edmonstone, R., Sumanasekera, R., and L. Vicisano, "PGM Reliable Transport Protocol Specification", RFC 3208, December 2001.
[RFC3208]Speakman，T.，Crowcroft，J.，Gemmell，J.，Farinaci，D.，Lin，S.，Leshchiner，D.，Luby，M.，Montgomery，T.，Rizzo，L.，Tweedy，A.，Bhaskar，N.，Edmonstone，R.，Sumanasekera，R.，和L.Vicisano，“PGM可靠传输协议规范”，RFC 32082001年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月。
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[RFC3376]Cain，B.，Deering，S.，Kouvelas，I.，Fenner，B.，和A.Thyagarajan，“互联网组管理协议，第3版”，RFC 3376，2002年10月。
[RFC3810] Vida, R., Ed., and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3810]Vida，R.，Ed.，和L.Costa，Ed.，“IPv6的多播侦听器发现版本2（MLDv2）”，RFC 38102004年6月。
[RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for Next Steps in Signaling (NSIS)", RFC 4081, June 2005.
[RFC4081]Tschofenig，H.和D.Kroeselberg，“信令（NSIS）下一步的安全威胁”，RFC 40812005年6月。
[RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery", RFC 4286, December 2005.
[RFC4286]Haberman，B.和J.Martin，“多播路由器发现”，RFC 4286，2005年12月。
[RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, December 2006.
[RFC4732]Handley，M.，Ed.，Rescorla，E.，Ed.，和IAB，“互联网拒绝服务注意事项”，RFC 47322006年12月。
[RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet Signalling Transport", RFC 5971, October 2010.
[RFC5971]Schulzrinne，H.和R.Hancock，“要点：通用互联网信号传输”，RFC 59712010年10月。
[RFC6016] Davie, B., Le Faucheur, F., and A. Narayanan, "Support for the Resource Reservation Protocol (RSVP) in Layer 3 VPNs", RFC 6016, October 2010.
[RFC6016]Davie，B.，Le Faucheur，F.，和A.Narayanan，“对第3层VPN中的资源预留协议（RSVP）的支持”，RFC 60162010年10月。
[RFC6178] Smith, D., Mullooly, J., Jaeger, W., and T. Scholl, "Label Edge Router Forwarding of IPv4 Option Packets", RFC 6178, March 2011.
[RFC6178]Smith，D.，Mullooly，J.，Jaeger，W.，和T.Scholl，“IPv4选项数据包的标签边缘路由器转发”，RFC 6178，2011年3月。
Author's Address
作者地址
Francois Le Faucheur (editor) Cisco Systems Greenside, 400 Avenue de Roumanille Sophia Antipolis 06410 France
Francois Le Faucheur（编辑）Cisco Systems Greenside，法国索菲亚安提波利斯路400号，邮编：06410
Phone: +33 4 97 23 26 19
EMail: flefauch@cisco.com
Phone: +33 4 97 23 26 19
EMail: flefauch@cisco.com