[要約] RFC 6398は、IPルーターアラートの考慮事項と使用方法に関するガイドラインです。その目的は、ネットワークトラフィックの制御と管理を向上させるために、ルーターアラートの効果的な利用を促進することです。
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ルーターアラートオプションは、TransitルーターにIPパケットの内容をより詳細に調べるように警告するIPオプションです。リソース予約プロトコル（RSVP）、実用的な一般的なマルチキャスト（PGM）、インターネットグループ管理プロトコル（IGMP）、マルチキャストリスナーディスカバリー（MLD）、マルチキャストルーターディスカバリー（MRD）、および一般的なインターネットシグナル伝達輸送（GIST）は、その一部の一部です。IPルーターアラートオプションを使用するプロトコル。このドキュメントでは、現在のIPルーターアラートオプションの使用に関するセキュリティの側面と使用ガイドラインについて説明します。これにより、RFC 2113とRFC 2711を更新します。具体的には、エンドツーエンドのオープンインターネットでルーターアラートを使用し、制御された環境を識別します。ルーターアラートに応じてプロトコルを安全に使用できる場合。また、サービスプロバイダーの保護アプローチに関する推奨事項も提供します。最後に、ルーターでのルーターアラート実装の簡単なガイドラインを提供します。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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
[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ルーターアラートオプション（RAOS）を定義します。このドキュメントでは、これらのオプションを集合的にIPルーターアラートと呼びます。IPルーターアラートオプションは、Transitルーターに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]）、インターネットグループ管理のグループ管理です。プロトコル（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ルーターアラートの使用に関連するセキュリティリスクを減らすことを考慮して）は、このドキュメントの範囲外です。そのような提案の1つは[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]は、ホップバイホップオプションエクステンションヘッダーを定義します。ホップバイホップオプションヘッダーは、パケットの配信パスに沿ってすべてのノードで調べる必要があるオプションの情報を運ぶために使用されます。IPv6ルーターアラートオプションは、特定のホップバイホップオプションの1つです。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オプションの1つです。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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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ルーターアラートオプションは、トランジットルーターにIPパケットの内容をより詳細に調べるように警告するメカニズムとして定義されています（[RFC2113]、[RFC2711]）。[RFC4081]および[RFC2711]は、IPルーターアラートの使用に関連するセキュリティリスクについて言及しています。IPルーターアラートを含む偽の（または単に望ましくない）IPデータグラムをルーターにあふれている可能性があるRouterの動作は、望ましくない方法で影響を与える可能性があります。たとえば、ルーターが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]は、IPルーターアラートの異なるユーザーを識別するためのNO（および[RFC2711]が非常に限られている）メカニズムを指定します。その結果、IPルーターアラートパントの多くの高速スイッチング実装Most/すべてのパケットがスローパスにマークされたすべてのパケット（すべてのルーターアラートパケットを体系的に無視またはドロップするように構成されていない限り）。ただし、一部の既存の展開された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ルーターアラートを使用したさまざまなプロトコルのパンティング決定の識別器として、次のレベルのプロトコルを考慮することができます。ただし、これにより、2つの理由で、IPルーターアラートを使用して、さまざまなプロトコル間で非常に粗いトリアージのみが可能になります。まず、次のレベルのプロトコルは、同じプロトコルの異なるアプリケーション（RSVP対RSVP-トラフィックエンジニアリング（RSVP -TE））の異なるアプリケーションに使用される場合、またはIPルーターアラートが異なるコンテキストに使用される場合、次のレベルプロトコルは同じです。同じアプリケーション（例えば、RSVP集約の異なるレベル[RFC3175]）。したがって、さまざまなアプリケーションまたはアプリケーションのさまざまなコンテキストから、IPルーターアラートパケットを横断する高速パスで必要なトリアージを達成することは常に可能ではありません。第二に、パンティングを必要とする一部のプロトコルは、輸送プロトコル（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]で定義された値（ゼロ）のみが1つだけであり、最近までIPv4ルーターアラート値のIANAレジストリはありませんでした（[RFC5350]）。したがって、これにより、ほとんどの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. インターネットで終了するルーターアラートエンドの使用（ピアモデルのルーターアラート）
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.
したがって、アプリケーションとプロトコルは、インターネット内の独立した管理ドメイン全体でルーターアラートオプション（現在指定されている）の処理に依存して展開しないでください。図1は、インターネットで終了するルーターアラートエンドのこのような仮説的な使用を示しています。さまざまな管理ドメインのコアルーターが同じシグナル伝達フローに関連付けられたルーターアラートオプションデータグラムの処理に参加するため、このようなルーターアラートオプションの使用のモデルを「ピアモデル」ルーターアラートオプションの使用と呼びます。
-------- -------- -------- --------
/ A \ / B \ / C \ / D \
| (*) | | (*) | | (*) | | (*) |
| | |<============>| |<=============>| |<=============>| | |
| - | | - | | - | | - |
\ / \ / \ / \ /
-------- -------- -------- --------
(*) closer examination 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|--| |--------| |
| - - | -- | | | |
\ / \ / \ /
------------------------- -------- --------
(*) closer examination of Router Alert Option datagrams
（*）ルーターアラートオプションデータグラムの詳細な調査
<==> flow of Router Alert Option datagrams
FW: Firewall
FW：ファイアウォール
Figure 2: Use of Router Alert within an Administrative Domain - Private Enterprise Network Firewalled from the Internet and Using RSVP Reservations
図2：管理ドメイン内でのルーターアラートの使用 - インターネットからファイアウォールされ、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ルーターアラートベクトルを介したDOS攻撃のリスクは、信頼できるエリア内でIPルーターアラートが使用されていても（またはRSVP-TEなど）、信頼できるエリアで削除（または大幅に削減されます）。したがって、IPルーターアラートに依存するアプリケーションは、信頼できるエリア内に安全に展開できます。ネットワーク内でRSVP-TEを実行しているサービスプロバイダーは、そのような保護された環境の例かもしれません。このような環境を図3に示します。
-------- -------------------------- --------
/ A \ / B \ / C \
| | | (*) (*) | | |
| |-------TT | |<=============>| | TT------- | |
| | | - - | | |
\ / \ / \ /
-------- -------------------------- --------
(*) closer examination 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.
このような制御された環境では、ネットワーク内のRAOパケット（RSVPなど）の交換と取り扱いに依存するアプリケーション（ネットワークB内ではない）を安全に展開できます。ルーターアラートオプションデータグラムはネットワークAで使用され、ネットワークBに完全に透過的に使用されるため、このような展開を水密オーバーレイでのルーターアラートの使用と呼びます。ネットワークAからのルーターアラートオプションデータグラムがネットワークBを漏らすことができないため、「水道」Bがあります。B。サービスプロバイダーネットワーク上で仮想プライベートネットワーク（VPN）として実現し、RSVPを使用してエンタープライズサイト内の予約を実行するために、プライベートエンタープライズイントラネットが実現したため音声とビデオの流れは、このような制御された環境の例かもしれません。このような環境を図4に示します。
-------- --------
/ A \ / A \
| (*) | | (*) |
| | |<=====================================>| | |
| - | | - |
\ / \ /
-------- --------
\ /
\ ------------------------- /
\ / B \ /
\| |/
TT TT
| |
\ /
-------------------------
(*) closer examination 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など）に依存するアプリケーションも同時に安全に展開できます。2つのレベルのオーバーレイでのルーターアラートの独立した孤立した展開を伴うこのような環境を図5に示します。
-------- --------
/ A \ / A \
| (*) | | (*) |
| | |<=====================================>| | |
| - | | - |
\ / \ /
-------- --------
\ /
\ ------------------------- /
\ / B \ /
\| (*) (*) |/
TT | |<============>| | TT
| - - |
\ /
-------------------------
(*) closer examination 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：2つのレベルでの水密オーバーレイでのルーターアラートの使用
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など）に依存するアプリケーションを安全に展開できます。ルーターアラートオプションデータグラムがネットワークAで使用され、ネットワークBのコアに完全に透過的に使用されるため、このような展開をリーク制御オーバーレイでのルーターアラートの使用と呼びます。ネットワークBのエッジ内でリークAネットワークAの漏れがあるが、ネットワークBのコア内ではないため、「リーク制御」。ネットワーク内の音声とビデオにRSVPを使用して、ネットワークBのエッジでRSVPを使用して、[[ネットワーク]とBの間の添付ファイルリンクに予約を拡張するプライベートエンタープライズイントラネット。RFC6016]）は、そのような制御された環境の例かもしれません。このような環境を図6に示します。
-------- --------
/ A \ / A \
| | | |
| | ------------------------ | |
| (*) | /(*) (*) \ | (*) |
| | |<======>| |<============>| |<=========>| | |
| - | | - - | | - |
\ / | \ - - / | \ /
-------- | TT-| | | |-TT | --------
| - - |
\ /
------------------------
(*) closer examination 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リフレッシュ削減メカニズムの使用（[RFC2961]）は、サービスプロバイダーがネットワーク内でRSVP-TEを実行している場合のそのようなメカニズムの例です。IPルーターアラートオプション。
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]).
同様に、実装は、Routerアラートオプションの値フィールドに基づいて、高速パス内での選択的転送（すべての通常のポリシーと転送ルールの対象となる）またはIPルーターアラートオプションを使用したパケットのパンティングをサポートする場合があります。これにより、そのルーターに関連しない値を持つIPルーターアラートパケットを使用したDOS攻撃に対するルーター保護が可能になります（たとえば、集約されたRSVP予約[RFC5350]のネストレベル）。
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 RAOSを定義する[RFC2113]と[RFC2711]のセキュリティに関する考慮事項を拡張します。追加のセキュリティに関する考慮事項については、[RFC4081]を参照してください。
The contributors to this document (in addition to the editor) are:
このドキュメントへの貢献者（編集者に加えて）は次のとおりです。
Reshad Rahman Cisco Systems rrahman@cisco.com
Reshad Rahman Cisco Systems rrahman@cisco.com
David Ward Juniper Networks dward@juniper.net
David Ward Juniper Networks dward@juniper.net
Ashok Narayanan Cisco Systems ashokn@cisco.com
Ashok Narayanan Cisco Systems ashokn@cisco.com
Adrian Farrel OldDog Consulting adrian@olddog.co.uk
Adrian Farrel Olddog Consulting Adrian@olddog.co.uk
Tony Li Cisco Systems tony.li@tony.li
Tony Li Cisco Systems Tony.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].
編集者と貢献者は、デイブ・オラン、マグナス・ウェスターランド、ジョン・スカダー、ロン・ボニャ、ロス・カロン、アルフレッド・ハインズ、カルロス・ピニャータロ、ローランド・ブレッシー、ジャリ・アークコ、そして彼らのコメントに感謝します。この文書は、Jukka MatherとSuresh Krishnanとの議論の恩恵も受けました。IPv4ルーターアラートでの値フィールドの使用に関する議論は、[RFC5971]の同様の議論から借用されています。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[RFC2113] Katz、D。、「IPルーターアラートオプション」、RFC 2113、1997年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、「Internet Protocol、Version 6（IPv6）仕様」、RFC 2460、1998年12月。
[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, October 1999.
[RFC2711] Partridge、C。およびA. Jackson、「IPv6ルーターアラートオプション」、RFC 2711、1999年10月。
[RFC5350] Manner, J. and A. McDonald, "IANA Considerations for the IPv4 and IPv6 Router Alert Options", RFC 5350, September 2008.
[RFC5350] MANER、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 Router Alert Option Extension」、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 2205、9月1997年。
[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 Refrend Overhead Recotion Extensions」、RFC 2961、2001年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.、Farinacci、D.、Lin、S.、Leshchiner、D.、Luby、M.、Montgomery、T.、Rizzo、L.、Tweedly、A.、Bhaskar、N.、Edmonstone、R.、Sumanasekera、R。、およびL. Vicisano、「PGM信頼できる輸送プロトコル仕様」、RFC 3208、2001年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 TunnelsのRSVPへの拡張"、RFC 3209、12月2001年。
[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。、「Multicastリスナーディスカバリーバージョン2（MLDV2）のIPv6」、RFC 3810、2004年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 4081、2005年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 4732、2006年12月。
[RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet Signalling Transport", RFC 5971, October 2010.
[RFC5971] Schulzrinne、H。およびR. Hancock、「Gist：General Internet Signaling Transport」、RFC 5971、2010年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 VPNSのリソース予約プロトコル（RSVP）のサポート」、RFC 6016、2010年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 Avenue de Roumanille Sophia Antipolis 06410 France
Phone: +33 4 97 23 26 19
EMail: flefauch@cisco.com