[要約] RFC 5095は、IPv6のタイプ0ルーティングヘッダーの非推奨化に関するものです。その目的は、セキュリティ上の懸念とパフォーマンスの問題を解決し、より安全で効率的なIPv6ネットワークを実現することです。
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
[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]は、「Routing Header」と呼ばれる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].
2001年にRH0の潜在的な問題が特定されました[セキュリティ]。2002年には、ホスト[ホスト]のルーティングヘッダー処理を制限する提案が行われました。これらの取り組みにより、モバイルIPv6仕様が変更され、RH0 [RFC3775]の代わりにタイプ2ルーティングヘッダーを使用しました。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年バンクーバーで開催されたCansecwest ConferenceでPhilippe BiondiとArnaud Ebalardによって提示されました[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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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:
宛先アドレスが割り当てられたパケットを受信するIPv6ノードは、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.
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].
RH0のサポートを削除するためにすべてのIPv6ノードが更新されるまでに時間がかかることが予想されます。[cansecwest07]に記載されているRH0の使用の一部は、[RFC2827]および[RFC3704]で推奨されるように、イングレスフィルタリングを使用して軽減できます。
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.
ルーティングヘッダーを運ぶすべてのIPv6パケットをブロックすると（タイプ0を具体的にブロックして他のタイプを許可するのではなく）、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ヘッダータイプ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.
このドキュメントは、Jari Arkko、Arnaud Ebalard、Tim Enos、Brian Haberman、Jun-Ithiro Itojun Hagino、Bob Hinden、Thomas Narten、Jinmei Tatuya、David Malone、Jeroen Massar、Dave Massarなど、Jari Arkko、Arnaud Ebalard、Tim Enos、Brian Haberman、Jun-Itojun Hagino、Jun-kiro Itojun Hagino、Dave Massarなど、多くのIPv6およびV6opsワーキンググループの参加者の貢献から恩恵を受けます。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 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] Biondi、P。and A. Ebalard、「IPv6ルーティングヘッダーセキュリティ」、Cansecwest Security Conference 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] 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 3704、2004年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 3775、2004年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 Transition/Co-Existence Security Scomationations」、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
Joeabley Afilias Canada Corp. Suite 204、4141 Yonge Street Toronto、M2P 2A8 Canada
Phone: +1 416 673 4176
EMail: jabley@ca.afilias.info
Pekka Savola CSC/FUNET Espoo, Finland
Pekka Savola CSC/Funet Espoo、フィンランド
EMail: psavola@funet.fi
George Neville-Neil Neville-Neil Consulting 2261 Market St. #239 San Francisco, CA 94114 USA
George Neville-Neil Neville-Neil Consulting 2261 Market St.＃239 San Francisco、CA 94114 USA
EMail: gnn@neville-neil.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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への情報をお問い合わせください。