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
Abstract
抽象
The IP Router Alert Option is an IP option that alerts transit routers to more closely examine the contents of an IP packet. The Resource reSerVation Protocol (RSVP), Pragmatic General Multicast (PGM), the Internet Group Management Protocol (IGMP), Multicast Listener Discovery (MLD), Multicast Router Discovery (MRD), and General Internet Signaling Transport (GIST) are some of the protocols that make use of the IP Router Alert Option. This document discusses security aspects and usage guidelines around the use of the current IP Router Alert Option, thereby updating RFC 2113 and RFC 2711. Specifically, it provides recommendations against using the Router Alert in the end-to-end open Internet and identifies controlled environments where protocols depending on Router Alert can be used safely. It also provides recommendations about protection approaches for service providers. Finally, it provides brief guidelines for Router Alert implementation on routers.
IPルータアラートオプションは、より密接にIPパケットの内容を調べるために中継ルータに警告IPオプションです。リソース予約プロトコル（RSVP）、実用的な一般的なマルチキャスト（PGM）、インターネットグループ管理プロトコル（IGMP）、マルチキャストリスナ発見（MLD）、マルチキャストルータディスカバリー（MRD）、および一般的なインターネットシグナリングトランスポート（GISTは）の一部ですIPルータアラートオプションを利用するプロトコル。このドキュメントは、それによって、RFC 2113および2711は、具体的には、エンド・ツー・エンドのオープンインターネットにルータアラートを使用に対する勧告を提供し、制御された環境を特定するRFCを更新し、現在のIPルータアラートオプションの使用を中心にセキュリティ面および使用上の注意事項について説明しますルータアラートに応じて、プロトコルが安全に使用することができる場所。また、サービスプロバイダの保護アプローチに関する推奨事項を提供します。最後に、それはルータのルータアラートの実装のための簡単なガイドラインを提供します。
Status of This Memo
このメモのステータス
This memo documents an Internet Best Current Practice.
このメモはインターネット最も良い現在の練習を説明します。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 BCPの詳細については、RFC 5741のセクション2で利用可能です。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6398.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6398で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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ルータアラートオプションは、より密接に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ルータアラートの仕様に将来の機能拡張は、この文書の範囲外です。そのような提案は[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ルーターアラートオプションは、ある特定のホップバイホップオプションです。 IPv6ルーターアラートがIPv6ホップバイホップオプション拡張ヘッダの概念をより一般的に適用するために、この文書で説明したものと同様にセキュリティ上の懸念。しかし、徹底的の上位概念に対処
IPv6 hop-by-hop option would require additional material so as to cover additional considerations associated with it (e.g., the effectiveness of the attack could depend on how many options are included and on the range to which the option-type value belongs), so this is kept outside the scope of this document. A detailed discussion about security risks and proposed remedies associated with the IPv6 hop-by-hop option can be found in [IPv6-HOPBYHOP].
（例えば、攻撃の有効性が含まれているどのように多くのオプションにし、オプション型の値が属する範囲に依存できる）、それに関連した追加の考慮事項を覆うように、IPv6のホップバイホップオプションが追加の材料を必要とします、これはこの文書の範囲外に保たれています。セキュリティリスクとIPv6のホップバイホップオプションに関連した提案の救済に関する詳細な議論は、[IPv6の-HOPBYHOP]で見つけることができます。
The IPv4 base specification [RFC0791] defines a general notion of IPv4 options that can be included in the IPv4 header (without distinguishing between the hop-by-hop and end-to-end options). The IPv4 Router Alert Option is one particular IPv4 option. Security concerns similar to those discussed in this document for the IPv4 Router Alert apply more generically to the concept of the IPv4 option. However, thoroughly addressing the security concerns of the broader concept of the IPv4 option is kept outside the scope of this document, because it would require additional material so as to cover additional considerations associated with it (such as lack of option ordering, etc.), and because other IPv4 options are often blocked in firewalls and not very widely used, so the practical risks they present are largely nonexistent.
IPv4の基本仕様[RFC0791]は（ホップバイホップとエンド・ツー・エンドのオプションを区別せずに）、IPv4ヘッダに含めることができるIPv4オプションの一般的な概念を定義します。 IPv4のルータアラートオプションは、ある特定のIPv4オプションです。 IPv4ルーターの警告は、この文書で説明したものと同様のセキュリティ上の懸念は、IPv4オプションの概念をより一般的に適用されます。 （などのオプション発注の不足、など）それに関連する追加の考慮事項を覆うように、それは追加の材料を必要とするので、しかし、徹底的に、この文書の範囲外に保たれているIPv4のオプションの上位概念のセキュリティ上の懸念に対処します、およびその他のIPv4のオプションは、多くの場合、ファイアウォールでブロックされ、非常に広く使用されていないので、彼らが提示する実用的なリスクが大きく存在しませんされているので。
For readability, this document uses the following loosely defined terms:
読みやすくするために、このドキュメントは以下の緩く定義された用語を使用しています。
o Fast path: Hardware or Application-Specific Integrated Circuit (ASIC) processing path for packets. This is the nominal processing path within a router for IP datagrams.
Oファストパス：ハードウェアまたは特定用途向け集積回路（ASIC）パケットのためのパスを処理します。これは、IPデータグラムのためのルータ内の名目上の処理パスです。
o Slow path: Software processing path for packets. This is a sub-nominal processing path for packets that require special processing or differ from assumptions made in fast-path heuristics.
Oスローパス：パケットのソフトウェア処理パス。これは、特別な処理を必要とするか、ファストパスヒューリスティックに仮定異なるパケットのサブ公称処理経路です。
o Next level protocol: The protocol transported in the IP datagram. In IPv4 [RFC0791], the next level protocol is identified by the IANA protocol number conveyed in the 8-bit "Protocol" field in the IPv4 header. In IPv6 [RFC2460], the next level protocol is identified by the IANA protocol number conveyed in the 8-bit "Next Header" field in the IPv6 header.
O次のレベルのプロトコル：IPデータグラムで輸送プロトコル。 IPv4の[RFC0791]で、次のレベルのプロトコルは、IPv4ヘッダ内の8ビットの「プロトコル」フィールドで搬送IANAプロトコル番号によって識別されます。 IPv6 [RFC2460]は、次のレベルのプロトコルは、IPv6ヘッダーの8ビットの「次ヘッダ」フィールドで搬送IANAプロトコル番号によって識別されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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データグラムとルータをあふれさせます。ルータは、低速パスに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ルータ警告の異なるユーザを識別するための機構（および[RFC2711]は非常に限られたを指定する）を指定していません。結果として、IPルータ警告の多くの高速スイッチングの実装では、（系統的に無視する、またはすべてのルータ警告パケットをドロップするように構成されていない限り）遅いパスにIPルータ警告付いほとんど/すべてのパケットをパント。しかし、いくつかの既存の展開IPルータは、ファストパス内のルータアラートオプションを含むプロセスIPパケットを行うことができます。
Some IP Router Alert implementations are able to take into account the next level protocol as a discriminator for the punting decision for different protocols using IP Router Alert. However, this still only allows very coarse triage among various protocols using IP Router Alert, for two reasons. First, the next level protocol is the same when IP Router Alert is used for different applications of the same protocol (e.g., RSVP vs. RSVP - Traffic Engineering (RSVP-TE)), or when IP Router Alert is used for different contexts of the same application (e.g., different levels of RSVP aggregation [RFC3175]). Thus, it is not always possible to achieve the necessary triage in the fast path across IP Router Alert packets from different applications or from different contexts of an application. Secondly, some protocols requiring punting might be carried over a transport protocol (e.g., TCP or UDP), possibly because (1) they require the services of that transport protocol, (2) the protocol does not justify allocation of a scarce next level protocol value, or (3) not relying on a very widely deployed transport protocol is likely to result in deployment issues due to common middlebox behaviors (e.g., firewalls or NATs discarding packets of "unknown" protocols). Thus, considering the next level protocol alone in the fast path is not sufficient to allow triage in the fast path of IP Router Alert 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ルータアラートを使用して、異なるプロトコルのためのパントの決定のための弁別として考慮に入れ、次のレベルのプロトコルを取ることができます。しかし、これはまだ2つのだけの理由で、IPルータアラートを使用して、さまざまなプロトコルの間で非常に粗いトリアージすることができます。まず、次のレベルのプロトコルは、IPルータアラートが同じプロトコル（RSVP対例えば、RSVP - トラフィックエンジニアリング（RSVP-TE））の異なる用途に使用する場合と同じである、またはIPルータアラートは別の文脈で使用されるとき同じアプリケーション（例えば、RSVP集約の異なるレベル[RFC3175]）。したがって、異なるアプリケーションから、またはアプリケーションの異なるコンテキストからのIPルータアラートパケット間高速パスで必要なトリアージを実現することができるとは限りません。第二に、パントを必要とするいくつかのプロトコルは、（2）プロトコルが不足し、次のレベルのプロトコルの割り当てを正当化しない、（1）彼らはそのトランスポートプロトコルのサービスを必要とする可能性があるため、トランスポートプロトコル（例えば、TCPやUDP）上で実施される可能性があります値、または（3）非常に広く展開されているトランスポートプロトコルに依存しない（例えば、ファイアウォールやNATのが「不明」のプロトコルのパケットを廃棄）、共通のミドル行動による展開の問題が発生する可能性があります。したがって、高速パスにのみ、次のレベルのプロトコルを考慮すると、同じトランスポートプロトコルを共有する異なるプロトコルからIPルータ警告パケットの高速パスでトリアージを可能にするのに十分ではありません。したがって、他の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ルータアラートの実装では、ルータアラートオプション内のアカウントにValueフィールドを取ることができます。しかし、唯一の値（ゼロ）[RFC2113]で定義された、とIPv4ルータ警告値のためのIANAレジストリが最近まで入手できなかった（[RFC5350]）。これは、ほとんどのIPv4ルーターアラートの実装は高速パスでのValueフィールドに基づいて便利な分類をサポートすることはできませんでした。また、一方で[RFC2113]は、未知の値が、いくつかの既存の実装は、単純にはIPv4と（すなわち、プロセスの任意のパケットを完全Valueフィールドを無視することが報告されている、（すなわち、パケットは通常のIPトラフィックとして転送されなければならない）無視されるべきであると述べていますかかわらず、そのオプションの値のルータアラート）。 IPv4ルーター警告値の更なる割り当てのためのIANAレジストリは、（[RFC5350]）が最近導入されているが、実装によってサポートされている場合にのみ、粗粒の分類を可能にします。 IPv6の場合、[RFC2711]は、「Valueフィールドがトランジットルータ内のデータグラムの処理を高速化するために実装して使用することができる」と述べて、これらの値のための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.
BGPによりO、エッジルータ予め同定ピアとだけ交換制御プレーン情報とルータ警告オプションは、任意の送信元アドレスとデータグラムで受信することができるが、容易に、他のピア又は非認証ピアからの任意の制御プレーントラフィックをフィルタリングすることができそして、任意の宛先アドレス。しかし、我々は、このような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).
BGPピアリングによりO、制御プレーンの穴は、エッジルータにのみ開放され、コア・ルータは、管理ドメインの外部のエンティティと直接制御プレーン交換から完全に分離されています。ルータアラートオプションで、攻撃はコアルータに伝播できつつ、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.
ルータ警告オプションで、非濾過攻撃メッセージは、典型的には、下流側に転送されるであろうしながらBGPによりO、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 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.
そのため、ルータアラートに関連付けられているセキュリティ上の懸念の第3節で説明し、ネットワーク事業者は、積極的に外部で生成されたIPルータアラートパケットから身を守るべきです。希望と望ましくないルータアラートパケット間トリアージへの便利な普遍的な仕組みがないため、ネットワーク事業者は、現在、多くの場合、外部で生成されたIPルータアラートパケットからそれらを分離する方法で自分自身を守ります。これは、IPルータアラートオプションは、そのネットワークを介して、隠されているように、IPルータアラートパケット[RFC6178]をトンネリングすることによって達成されるかもしれない、またはそれは時折（例えば、レート制限）が得られメカニズムや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 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.
彼らは非常に緊密に協力し、効果的に、単一の信頼ドメインとして動作することにより、いくつかの管理された環境では、複数の管理ドメインには、特別な関係を持っています。その場合、1つのドメインが境界を越えて注入されたトラフィックに対して相互に信頼しても構わないと思っています。換言すれば、下流のドメイン境界で注入されたトラフィックが正しく上流領域によってフィルタリング/検証されたことを信頼しても構わないと思っています。そのような信頼は、ルータ警告オプションパケットに適用できることが確立されている場合、RAOパケット（例えば、RSVP）の交換や取り扱いに依存するアプリケーションが安全にそのような制御された環境内に展開することができます。運転マルチメディアエンドポイントを担当する会社やネットワークの運用を担当する同一企業内のエンティティ内のエンティティは、そのような制御された環境の一例であるかもしれません。例えば、彼らは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.
一部の環境では、ネットワーク管理者が確実に任意の信頼できないデバイス（例えば、外部のルータから）からルータ警告パケットが信頼できる領域（例えば、内部ルータ）に入ることが防止されていることを確認することができます。例えば、これは、信頼境界（例えば、エッジルータ）を跨いルータは常に信頼できる領域を通って（カプセル化ヘッダ内のIPルータ警告-OR equivalent-を設定せずに）これらのパケットをカプセル化することを保証することによって達成され得る（[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.
ネットワークAのサイトOサービスプロバイダーネットワーク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]).
サービス・プロバイダ・ネットワークB oを、それらがネットワークを介して通過（例えば、[RFC6178]で説明したメカニズムを使用する）場合、これらのメッセージを削除せずにIPルータ警告メッセージから自身を保護します。
In such a controlled environment, an application relying on exchange and handling of RAO packets (e.g., RSVP) in the network A sites (but not inside network B) can be safely deployed. We refer to such a deployment as a use of Router Alert in a Water-Tight Overlay -- "Overlay", because Router Alert Option datagrams are used in network A on top of, and completely transparently to, network B; and "Water-Tight", because Router Alert Option datagrams from network A cannot leak inside network B. A private enterprise intranet realized as a Virtual Private Network (VPN) over a service provider network and using RSVP to perform reservations within the enterprise sites for voice and video flows might be an example of such a controlled environment. Such an environment is illustrated in Figure 4.
そのような制御された環境で、ネットワークAサイトにおけるRAOパケット（例えば、RSVP）（ただし、ネットワークB内）の交換や取り扱いに依存するアプリケーションを安全に展開することができます。 ;ルータアラートオプションデータグラムは、ネットワークBに完全に透過的の上にネットワークAに使用される、とされているので、「オーバーレイ」 - 私たちは、水密オーバーレイにおけるルータアラートの使用のような展開を参照してください。そして「水密」、ネットワークAからルータアラートオプションデータグラムがネットワーク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.
上述の制御された環境で、RAOパケットの交換や取り扱いに依存する（例えば、RSVP-TE）サービスプロバイダネットワークB内（ただし、ネットワークA内の）アプリケーションも安全に同時に展開することができます。二つのレベルでのオーバーレイのルータアラートの独立した、単離されたデプロイメントこのような環境は、図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：二つのレベルで水密オーバーレイにおけるルータアラートの使用
In some controlled environment:
いくつかの制御された環境で：
o The sites of a network A are interconnected through a service provider network B.
ネットワークAのサイトOサービスプロバイダーネットワーク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.
サービスプロバイダB oをエッジルータにルータ警告パケットを処理し、そのような（おそらくポートごと）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]).
サービス・プロバイダ・ネットワークB oを、それらがネットワークを介して通過（例えば、[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.
そのような制御された環境では、（例えば、RSVP）ネットワークAサイト及びBネットワークのエッジで（ただし、ネットワークBのコア内）RAOパケットの交換や取り扱いに依存するアプリケーションを安全に展開することができます。 、ルータ警告オプションデータグラムは、ネットワークBのコアに完全に透過的の上にネットワークAに使用される、とされているので、「オーバーレイ」 - 我々は、漏れ制御オーバーレイのルータアラートの使用などの展開を参照しますそして、「リーク制御された」、ネットワークからルータ警告オプションデータグラムネットワークBの縁内部漏れはなく、内部ネットワークBのコアからです。そのサイトのネットワークBの縁に、ならびにネットワークAサイト内の音声およびビデオのためのRSVPを使用して、サービスプロバイダのネットワークを介して相互に接続されているで指定されるように（ネットワークAと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 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).
セクション4.2.2で説明したように、いくつかのアプリケーションは、（ルータ警告パケットがサービスプロバイダーの上に透過的に交換される、すなわち、）オーバーレイモデルにおけるIPルータ警告パケットの使用から利益を得ることができます。したがって、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.
別の例として、サービスプロバイダは、そのネットワーク内のIPルータ・アラートに応じてプロトコルの動作を保護することができ、そのような（セクション5は、IPルータ警告実装によってサポートされることを示唆している）は、選択フィルタリングおよびレート制限などの保護メカニズムを使用して（例えば、RSVP -TE）が同時に終了するために、エンドを使用されるかもしれない別のプロトコルを運ぶIPルータアラートパケットを搬送しながら。サービスプロバイダは、さらに、サービスプロバイダ環境内で、このプロトコルの動作のためのルータアラートの依存を減らし、プロトコル固有のメカニズムを使用するかもしれないことに注意してください。これを使用することなく、既存のパスとのResv状態のリフレッシュを可能にするので、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ルータアラート」の存在を無視する設定オプションを提供する必要があります。その特定のネットワークセグメントに不利な運用上のセキュリティリスクを提示せずに遷移するネットワークセグメントをIPルータアラートパケットを許可し、4.3節で述べたように、これまでどのような目的のためにIPルータアラートメッセージを使用しないネットワークセグメントのオペレータを提供しました。
If an IP packet contains the IP Router Alert Option, but the next level protocol is not explicitly identified as a protocol of interest by the router examining the packet, the behavior is not explicitly defined by [RFC2113]. However, the behavior is implied, and, for example, the definition of RSVP in [RFC2205] assumes that the packet will be forwarded using normal forwarding based on the destination IP address. Thus, a router implementation SHOULD forward within the "fast path" (subject to all normal policies and forwarding rules) a packet carrying the IP Router Alert Option containing a next level protocol that is not a protocol of interest to that router. The "not punting" behavior protects the router from DoS attacks using IP Router Alert packets of a protocol unknown to the router. The "forwarding" behavior contributes to transparent end-to-end transport of IP Router Alert packets (e.g., to facilitate their use by end-to-end applications).
IPパケットは、IPルータアラートオプションが含まれていますが、次のレベルのプロトコルを明示的にパケットを調べるルータによって関心のプロトコルとして識別されない場合、動作が明示的に[RFC2113]で定義されていません。しかし、挙動が暗示され、そして、例えば、[RFC2205]でRSVPの定義は、パケットが宛先IPアドレスに基づいて通常の転送を使用して転送されることを想定しています。したがって、ルータの実装は、「高速パス」（すべての正常なポリシーおよび転送ルールに従う）内にそのルータへの関心のプロトコルではありません次のレベルのプロトコルを含むIPルータ警告オプションを運ぶパケットを転送すべきです。 「パントない」行動は、ルータに、未知のプロトコルのIPルータアラートパケットを使用してDoS攻撃からルータを保護します。 「転送」動作は、IPルータ警告パケット（例えば、エンド・ツー・エンドのアプリケーションでの使用を容易にする）の透明なエンドツーエンドの輸送に寄与する。
Similarly, an implementation MAY support selective forwarding within the fast path (subject to all normal policies and forwarding rules) or punting of a packet with the IP Router Alert Option, based on the Value field of the Router Alert Option. This would allow router protection against DoS attacks using IP Router Alert packets with a value that is not relevant for that router (e.g., nesting levels of aggregated RSVP reservation [RFC5350]).
同様に、インプリメンテーションは、ルータ警告オプションの値フィールドに基づいて、またはIPルータ警告オプション付きパケットのパント、（すべての正常ポリシーおよび転送ルールに従う）ファストパス内の選択的な転送をサポートするかもしれません。これは、ルータ（集約RSVP予約[RFC5350]の例えば、ネスティングレベル）に関連しない値でIPルータ警告パケットを使用してDoS攻撃に対するルータの保護を可能にするであろう。
This document expands the security considerations of [RFC2113] and [RFC2711], which define the IPv4 and IPv6 RAOs, respectively, by discussing security risks associated with usage of the current IP Router Alert Option and associated practices. See [RFC4081] for additional security considerations.
この文書は、現在のIPルータ警告オプションと関連する慣行の使用に関連するセキュリティリスクを議論することによって、それぞれ、IPv4およびIPv6 RAOsを定義[RFC2113]及び[RFC2711]のセキュリティ問題を拡張します。追加のセキュリティの考慮事項については、[RFC4081]を参照してください。
The contributors to this document (in addition to the editor) are:
（エディタに加えて）この文書への貢献者は、次のとおりです。
Reshad Rahman Cisco Systems rrahman@cisco.com
Reshadラーマンシスコシステムズररहमान@सिस्को.कॉम
David Ward Juniper Networks dward@juniper.net
デビッド・ウォードジュニパーネットワークスdward@juniper.net
Ashok Narayanan Cisco Systems ashokn@cisco.com
アショク・ナラヤナンシスコシステムズashokn@cisco.com
Adrian Farrel OldDog Consulting adrian@olddog.co.uk
エードリアンファレルOldDogコンサルティングadrian@olddog.co.uk
Tony Li Cisco Systems tony.li@tony.li
トニー・リーシスコシステムズ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].
エディタと貢献者はデイブ・オラン、マグヌスウェスター、ジョン・スカダー、ロンBonica、ロスCallon、アルフレッド・ハインズ、カルロスPignataro、ローランド祝福、ヤリArkko、そして彼らのコメントのためのアトキンソン蘭に感謝したいと思います。この文書はまた、ユッカマナーやスレシュクリシュナンとの議論の恩恵を受けました。 IPv4ルーター警告におけるValueフィールドの使用についての議論は[RFC5971]で同様の議論から借用されます。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[RFC2113]カッツ、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]ブラドナーの、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月。
[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, October 1999.
[RFC2711]ウズラ、C.とA.ジャクソン、 "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]マナー、J.およびA.マクドナルド、 "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]クリシュナン、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]ナラヤナン、A.、ルFaucheur、F.、ウォード、D.、およびR.ラーマン、 "IPルータアラートオプション拡張"、進歩、2009年3月での作業。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]ブレーデン、R.、エド、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（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]デアリング、S.、フェナー、W.、およびB.ハーバーマン、 "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]バーガー、L.、ガン、D.、ツバメ、G.、パン、P.、Tommasi、F.、及びS. Molendini、 "RSVPリフレッシュオーバーヘッド削減拡張"、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]ベーカー、F.、Iturralde、C.、ルFaucheur、F.、およびB.デイビー、 "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]スピークマン、T.、クロウクロフト、J.、Gemmell、J.、ファリナッチ、D.、リン、S.、Leshchiner、D.、ルビー、M.、モンゴメリー、T.、リゾー、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.、バーガー、L.、ガン、D.、李、T.、スリニヴァサン、V.、およびG.ツバメ、 "RSVP-TE：LSPトンネルのための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]カイン、B.、デアリング、S.、Kouvelas、I.、フェナー、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]ビダ、R.、エド。、およびL.コスタ、エド。、 "IPv6のマルチキャストリスナ発見バージョン2（MLDv2の）"、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]ハーバーマン、B.及びJ.マーチン、 "マルチキャストルータ発見"、RFC 4286、2005年12月。
[RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, December 2006.
[RFC4732]ハンドリー、M.、エド。、レスコラ、E.、エド。、およびIAB、 "インターネットサービス拒否の注意事項"、RFC 4732、2006年12月。
[RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet Signalling Transport", RFC 5971, October 2010.
[RFC5971] Schulzrinneと、H.とR.ハンコック、 "GIST：一般的なインターネットシグナリング交通"、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]デイビー、B.、ルFaucheur、F.、及びA.ナラヤナン、 "レイヤ3つのVPNをにリソース予約プロトコル（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]、RFC 6178、2011年3月 "IPv4のオプションパケットのラベルエッジルータフォワーディング" スミス、D.、Mullooly、J.、ジャガールクルト、W.、およびT.ショル、。
Author's Address
著者のアドレス
Francois Le Faucheur (editor) Cisco Systems Greenside, 400 Avenue de Roumanille Sophia Antipolis 06410 France
フランソワ・ル・Faucheur（エディタ）シスコシステムズグリーンサイド、400アベニュー・ド・Roumanilleソフィアアンティポリス、フランス06410
Phone: +33 4 97 23 26 19 EMail: flefauch@cisco.com
電話：+33 4 97 23 26 19 Eメール：flefauch@cisco.com