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
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のタイプ0のルーティングヘッダの使用を廃止したIPv6の仕様が更新されます。
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
[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]は、直前のヘッダ43の次ヘッダ値によって識別される「ルーティングヘッダ」と呼ばれるIPv6拡張ヘッダを定義します。 「タイプ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に複数回含まれていてもよいです。このパケットは、2つRH0処理ホストまたはルータ間で何度も振動するように構成されることを可能にします。これは、攻撃者からのパケットのストリームは、任意のリモートパスに沿って輻輳を引き起こすために使用され、したがって、サービス拒否のメカニズムとして機能することができる2つのリモートルータ間の経路に沿って増幅されることを可能にします。 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.
この攻撃は、2つの悪用のノード間のパス全体だけでなく、ノード自身や自分のローカルネットワークに影響を与えることで特に深刻です。類似の機能は、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].
RH0の潜在的な問題は、2001年[セキュリティ]で同定されました。 2002年に提案は、ホスト[ホスト]でルーティングヘッダ処理を制限するためになされました。これらの努力は、代わりにRH0のタイプ2ルーティングヘッダ[RFC3775]を使用するモバイルIPv6仕様の変更をもたらしました。 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.
RH0の運用上のセキュリティへの影響の治療は2007 [CanSecWest07]、バンクーバーたCanSecWest会議でフィリップ・ビオンディとアルノーEbalardによって発表されました。このプレゼンテーションでは、RH0に関連するリスクのために広範囲に宣伝しました。
This document updates [RFC2460] and [RFC4294].
このドキュメントの更新[RFC 2460]と[RFC 4294]。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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拡張ヘッダは、RH0のために[RFC2460]の4.4節の後半で指定されたアルゴリズムを実行してはいけません含まIPv6ノード。代わりに、そのようなパケット、すなわち、認識されていないルーティングタイプ値を含むデータグラムのために[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.
IPv6実装は、もはやどのような方法でRH0を実装する必要はありません。
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 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.
ルーティングヘッダ（というよりも、具体的タイプ0を遮断し、他の種類を許可する）を運ぶすべてのIPv6パケットをブロックすると、IPv6の将来の発展のために非常に深刻な影響を持っています。展開ファイアウォールの小さな割合は、デフォルトではルーティングヘッダの他の種類をブロックする場合は、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の機能を廃止することです。 RH0の利用可能性によって促進される脆弱性の具体例としては、[CanSecWest07]に見出すことができます。特に、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レジストリ「インターネットプロトコルバージョン6（IPv6）のパラメータは、」IPv6ヘッダー型の0 43（「ルーティングヘッダ」）が廃止されている変異体を反映するように更新されるべきです。
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の貢献からの恩恵とヤリArkko、アルノーEbalard、ティム・エノス、ブライアンハーバーマン、Jun-ichiro itojun Haginoは、ボブHindenとトーマスNarten氏、神明達也、デビッド・マローン、イェルーンMassar、デイブを含むワーキンググループ参加者を、V6OPSターラー、およびギヨームヴァラドン。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, April 2006.
[RFC4294] Loughney、J.、 "IPv6のノードの要件"、RFC 4294、2006年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]ビオンディ、P.およびA. Ebalard、 "IPv6ルーティングヘッダのセキュリティ"、たCanSecWestセキュリティ会議2007、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]ファーガソン、P.およびD. Senie、 "ネットワーク入力フィルタリング：IP Source Address Spoofingを使うサービス攻撃の敗北拒否"、BCP 38、RFC 2827、2000年5月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]ベイカー、F.およびP. Savola、 "マルチホームネットワークの入力フィルタリング"、BCP 84、RFC 3704、2004年3月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775]ジョンソン、D.、パーキンス、C.、およびJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 3775、2004年6月。
[RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/Co-existence Security Considerations", RFC 4942, September 2007.
[RFC4942]デイヴィス、E.、クリシュナン、S.、およびP. Savola、 "IPv6移行/共存のセキュリティの考慮事項"、RFC 4942、2007年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
ジョーAbley Afiliasカナダ社M2P 2A8カナダONスイート204、4141ヤングストリートトロント、
Phone: +1 416 673 4176 EMail: jabley@ca.afilias.info
電話：+1 416 673 4176 Eメール：jabley@ca.afilias.info
Pekka Savola CSC/FUNET Espoo, Finland
ペッカSavola CSC / FUNETエスポー、フィンランド
EMail: psavola@funet.fi
メールアドレス：psavola@funet.fi
George Neville-Neil Neville-Neil Consulting 2261 Market St. #239 San Francisco, CA 94114 USA
ジョージ・ネヴィル - ニール・ネヴィル・ニール・コンサルティング2261年の市場セント第239位サンフランシスコ、CA 94114 USA
EMail: gnn@neville-neil.com
メールアドレス：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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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-ipr@ietf.orgのIETFに情報を記述してください。