Network Working Group J. Abley
Request for Comments: 5095 Afilias
Updates: 2460, 4294 P. Savola
Category: Standards Track CSC/FUNET
G. Neville-Neil
Neville-Neil Consulting
December 2007
Network Working Group J. Abley
Request for Comments: 5095 Afilias
Updates: 2460, 4294 P. Savola
Category: Standards Track CSC/FUNET
G. Neville-Neil
Neville-Neil Consulting
December 2007
Deprecation of Type 0 Routing Headers in IPv6
IPv6中类型0路由头的弃用
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Abstract
摘要
The functionality provided by IPv6's Type 0 Routing Header can be exploited in order to achieve traffic amplification over a remote path for the purposes of generating denial-of-service traffic. This document updates the IPv6 specification to deprecate the use of IPv6 Type 0 Routing Headers, in light of this security concern.
可以利用IPv6的0型路由报头提供的功能，通过远程路径实现流量放大，以生成拒绝服务流量。鉴于此安全问题，本文档更新了IPv6规范，以禁止使用IPv6类型0路由头。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Deprecation of RH0 . . . . . . . . . . . . . . . . . . . . . . 3
4. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4.1. Ingress Filtering . . . . . . . . . . . . . . . . . . . . . 3
4.2. Firewall Policy . . . . . . . . . . . . . . . . . . . . . . 3
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.1. Normative References . . . . . . . . . . . . . . . . . . . 5
8.2. Informative References . . . . . . . . . . . . . . . . . . 5
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Deprecation of RH0 . . . . . . . . . . . . . . . . . . . . . . 3
4. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4.1. Ingress Filtering . . . . . . . . . . . . . . . . . . . . . 3
4.2. Firewall Policy . . . . . . . . . . . . . . . . . . . . . . 3
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.1. Normative References . . . . . . . . . . . . . . . . . . . 5
8.2. Informative References . . . . . . . . . . . . . . . . . . 5
[RFC2460] defines an IPv6 extension header called "Routing Header", identified by a Next Header value of 43 in the immediately preceding header. A particular Routing Header subtype denoted as "Type 0" is also defined. Type 0 Routing Headers are referred to as "RH0" in this document.
[RFC2460]定义了一个名为“路由头”的IPv6扩展头，由前一个头中的下一个头值43标识。还定义了表示为“类型0”的特定路由标头子类型。类型0路由标头在本文档中称为“RH0”。
A single RH0 may contain multiple intermediate node addresses, and the same address may be included more than once in the same RH0. This allows a packet to be constructed such that it will oscillate between two RH0-processing hosts or routers many times. This allows a stream of packets from an attacker to be amplified along the path between two remote routers, which could be used to cause congestion along arbitrary remote paths and hence act as a denial-of-service mechanism. An 88-fold amplification has been demonstrated using this technique [CanSecWest07].
单个RH0可以包含多个中间节点地址，同一地址可以在同一RH0中包含多次。这使得数据包能够在两个RH0处理主机或路由器之间多次振荡。这使得来自攻击者的数据包流沿着两个远程路由器之间的路径被放大，这可用于沿任意远程路径造成拥塞，从而充当拒绝服务机制。使用这种技术已经证明了88倍的扩增[CanSecWest07]。
This attack is particularly serious in that it affects the entire path between the two exploited nodes, not only the nodes themselves or their local networks. Analogous functionality may be found in the IPv4 source route option, but the opportunities for abuse are greater with RH0 due to the ability to specify many more intermediate node addresses in each packet.
这种攻击特别严重，因为它影响两个受攻击节点之间的整个路径，而不仅仅是节点本身或其本地网络。类似的功能可以在IPv4源路由选项中找到，但由于RH0能够在每个数据包中指定更多的中间节点地址，因此滥用的机会更大。
The severity of this threat is considered to be sufficient to warrant deprecation of RH0 entirely. A side effect is that this also eliminates benign RH0 use-cases; however, such applications may be facilitated by future Routing Header specifications.
这种威胁的严重性被认为足以保证RH0完全被弃用。一个副作用是，这也消除了良性RH0用例；然而，将来的路由报头规范可能会促进此类应用。
Potential problems with RH0 were identified in 2001 [Security]. In 2002 a proposal was made to restrict Routing Header processing in hosts [Hosts]. These efforts resulted in the modification of the Mobile IPv6 specification to use the type 2 Routing Header instead of RH0 [RFC3775]. Vishwas Manral identified various risks associated with RH0 in 2006 including the amplification attack; several of these vulnerabilities (together with other issues) were later documented in [RFC4942].
2001年发现了RH0的潜在问题[安全性]。2002年，有人提议限制主机[hosts]中的路由报头处理。这些努力导致移动IPv6规范修改为使用类型2路由报头而不是RH0[RFC3775]。Vishwas Manral在2006年确定了与RH0相关的各种风险，包括放大攻击；其中几个漏洞（以及其他问题）后来记录在[RFC4942]中。
A treatment of the operational security implications of RH0 was presented by Philippe Biondi and Arnaud Ebalard at the CanSecWest conference in Vancouver, 2007 [CanSecWest07]. This presentation resulted in widespread publicity for the risks associated with RH0.
Philippe Biondi和Arnaud Ebalard在2007年温哥华举行的CanSecWest会议上介绍了RH0对运营安全的影响[CanSecWest07]。该演示导致了RH0相关风险的广泛宣传。
This document updates [RFC2460] and [RFC4294].
本文件更新了[RFC2460]和[RFC4294]。
RH0 in this document denotes the IPv6 Extension Header type 43 ("Routing Header") variant 0 ("Type 0 Routing Header"), as defined in [RFC2460].
本文档中的RH0表示[RFC2460]中定义的IPv6扩展头类型43（“路由头”）变体0（“类型0路由头”）。
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 IPv6 node that receives a packet with a destination address assigned to it and that contains an RH0 extension header MUST NOT execute the algorithm specified in the latter part of Section 4.4 of [RFC2460] for RH0. Instead, such packets MUST be processed according to the behaviour specified in Section 4.4 of [RFC2460] for a datagram that includes an unrecognised Routing Type value, namely:
接收到目的地址为其分配且包含RH0扩展头的数据包的IPv6节点不得执行[RFC2460]第4.4节后半部分为RH0指定的算法。相反，对于包含未识别路由类型值的数据报，必须按照[RFC2460]第4.4节中规定的行为处理此类数据包，即：
If Segments Left is zero, the node must ignore the Routing header and proceed to process the next header in the packet, whose type is identified by the Next Header field in the Routing header.
如果剩余段为零，则节点必须忽略路由报头并继续处理数据包中的下一个报头，其类型由路由报头中的下一个报头字段标识。
If Segments Left is non-zero, the node must discard the packet and send an ICMP Parameter Problem, Code 0, message to the packet's Source Address, pointing to the unrecognized Routing Type.
如果剩余段不为零，则节点必须丢弃数据包，并向数据包的源地址发送ICMP参数问题代码0消息，指向无法识别的路由类型。
IPv6 implementations are no longer required to implement RH0 in any way.
以任何方式实现RH0不再需要IPv6实现。
It is to be expected that it will take some time before all IPv6 nodes are updated to remove support for RH0. Some of the uses of RH0 described in [CanSecWest07] can be mitigated using ingress filtering, as recommended in [RFC2827] and [RFC3704].
预计需要一段时间才能更新所有IPv6节点以取消对RH0的支持。如[RFC2827]和[RFC3704]中所建议的，可以使用入口过滤来缓解[CanSecWest07]中描述的RH0的一些使用。
A site security policy intended to protect against attacks using RH0 SHOULD include the implementation of ingress filtering at the site border.
旨在防止使用RH0攻击的站点安全策略应包括在站点边界实施入口过滤。
Blocking all IPv6 packets that carry Routing Headers (rather than specifically blocking Type 0 and permitting other types) has very serious implications for the future development of IPv6. If even a
阻止所有携带路由头的IPv6数据包（而不是专门阻止类型0并允许其他类型）对IPv6的未来发展具有非常严重的影响。即使是一个
small percentage of deployed firewalls block other types of Routing Headers by default, it will become impossible in practice to extend IPv6 Routing Headers. For example, Mobile IPv6 [RFC3775] relies upon a Type 2 Routing Header; wide-scale, indiscriminate blocking of Routing Headers will make Mobile IPv6 undeployable.
部署的防火墙中有一小部分会阻止其他类型的路由头。默认情况下，扩展IPv6路由头在实践中是不可能的。例如，移动IPv6[RFC3775]依赖于类型2路由报头；大规模、不加区分地阻塞路由头将使移动IPv6无法部署。
Firewall policy intended to protect against packets containing RH0 MUST NOT simply filter all traffic with a Routing Header; it must be possible to disable forwarding of Type 0 traffic without blocking other types of Routing Headers. In addition, the default configuration MUST permit forwarding of traffic using a Routing Header other than 0.
旨在防止包含RH0的数据包的防火墙策略不能简单地使用路由报头过滤所有流量；必须能够在不阻塞其他类型路由头的情况下禁用类型0流量的转发。此外，默认配置必须允许使用非0的路由标头转发流量。
The purpose of this document is to deprecate a feature of IPv6 that has been shown to have undesirable security implications. Specific examples of vulnerabilities that are facilitated by the availability of RH0 can be found in [CanSecWest07]. In particular, RH0 provides a mechanism for traffic amplification, which might be used as a denial-of-service attack. A description of this functionality can be found in Section 1.
本文档的目的是反对IPv6的一项功能，该功能已被证明具有不良的安全影响。可在[CanSecWest07]中找到RH0可用性促进的漏洞的具体示例。特别是，RH0提供了一种流量放大机制，可以用作拒绝服务攻击。有关此功能的说明，请参见第1节。
The IANA registry "Internet Protocol Version 6 (IPv6) Parameters" should be updated to reflect that variant 0 of IPv6 header-type 43 ("Routing Header") is deprecated.
IANA注册表“Internet协议版本6（IPv6）参数”应更新，以反映IPv6标头类型43（“路由标头”）的变体0已被弃用。
This document benefits from the contributions of many IPV6 and V6OPS working group participants, including Jari Arkko, Arnaud Ebalard, Tim Enos, Brian Haberman, Jun-ichiro itojun Hagino, Bob Hinden, Thomas Narten, Jinmei Tatuya, David Malone, Jeroen Massar, Dave Thaler, and Guillaume Valadon.
本文档得益于许多IPV6和V6OPS工作组参与者的贡献，包括Jari Arkko、Arnaud Ebalard、Tim Enos、Brian Haberman、Jun ichiro itojun Hagino、Bob Hinden、Thomas Narten、Jinmei Tatuya、David Malone、Jeroen Massar、Dave Thaler和Guillaume Valadon。
[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月。
[RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, April 2006.
[RFC4294]Loughney，J.，“IPv6节点要求”，RFC 42942006年4月。
[CanSecWest07] Biondi, P. and A. Ebalard, "IPv6 Routing Header Security", CanSecWest Security Conference 2007, April 2007. http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf
[CanSecWest07]Biondi，P.和A.Ebalard，“IPv6路由头安全”，2007年CanSecWest安全会议，2007年4月。http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf
[Hosts] Savola, P., "Note about Routing Header Processing on IPv6 Hosts", Work in Progress, February 2002.
[主机]Savola，P.，“关于IPv6主机上路由头处理的注意事项”，正在进行的工作，2002年2月。
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2827]Ferguson，P.和D.Senie，“网络入口过滤：击败利用IP源地址欺骗的拒绝服务攻击”，BCP 38，RFC 2827，2000年5月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]Baker，F.和P.Savola，“多宿网络的入口过滤”，BCP 84，RFC 37042004年3月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775]Johnson，D.，Perkins，C.，和J.Arkko，“IPv6中的移动支持”，RFC 37752004年6月。
[RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/Co-existence Security Considerations", RFC 4942, September 2007.
[RFC4942]Davies，E.，Krishnan，S.，和P.Savola，“IPv6过渡/共存安全考虑”，RFC 49422007年9月。
[Security] Savola, P., "Security of IPv6 Routing Header and Home Address Options", Work in Progress, March 2002.
[安全]Savola，P.，“IPv6路由头和家庭地址选项的安全”，正在进行的工作，2002年3月。
Authors' Addresses
作者地址
Joe Abley Afilias Canada Corp. Suite 204, 4141 Yonge Street Toronto, ON M2P 2A8 Canada
Joe Abley Afilias Canada Corp.加拿大多伦多Yonge街4141号204室，M2P 2A8
Phone: +1 416 673 4176
EMail: jabley@ca.afilias.info
Phone: +1 416 673 4176
EMail: jabley@ca.afilias.info
Pekka Savola CSC/FUNET Espoo, Finland
佩卡·萨沃拉CSC/FUNET Espoo，芬兰
EMail: psavola@funet.fi
EMail: psavola@funet.fi
George Neville-Neil Neville-Neil Consulting 2261 Market St. #239 San Francisco, CA 94114 USA
乔治·内维尔·尼尔·内维尔·尼尔咨询2261市场239旧金山CA美国94114
EMail: gnn@neville-neil.com
EMail: gnn@neville-neil.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.