[要約] RFC 5635は、Unicast Reverse Path Forwarding（uRPF）を使用したリモートトリガードブラックホールフィルタリングに関するものです。その目的は、ネットワーク攻撃からの保護を強化するために、不正なトラフィックをブラックホールに導く方法を提供することです。
Network Working Group W. Kumari
Request for Comments: 5635 Google
Category: Informational D. McPherson
Arbor Networks
August 2009
Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF)
ユニキャストリバースパス転送（URPF）を備えたリモートトリガーブラックホールフィルタリング
Abstract
概要
Remote Triggered Black Hole (RTBH) filtering is a popular and effective technique for the mitigation of denial-of-service attacks. This document expands upon destination-based RTBH filtering by outlining a method to enable filtering by source address as well.
リモートトリガーブラックホール（RTBH）フィルタリングは、サービス拒否攻撃の緩和に人気のある効果的な手法です。このドキュメントは、ソースアドレスによるフィルタリングも有効にするメソッドを概説することにより、宛先ベースのRTBHフィルタリングを拡張します。
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Destination Address RTBH Filtering ..............................3
3.1. Overview ...................................................3
3.2. Detail .....................................................4
4. Source Address RTBH Filtering ...................................7
4.1. Steps to Deploy RTBH Filtering with uRPF for Source
Filtering ..................................................8
5. Security Considerations .........................................9
6. Acknowledgments .................................................9
7. References ......................................................9
7.1. Normative References .......................................9
7.2. Informative References ....................................10
Appendix A. Cisco Router Configuration Sample .....................11
Appendix B. Juniper Configuration Sample ..........................12
Appendix C. A Brief History of RTBH ...............................14
This document expands upon the technique outlined in "Configuring BGP to Block Denial-of-Service Attacks" [RFC3882] to demonstrate a method that allows for filtering by source address(es).
このドキュメントは、「サービス拒否攻撃をブロックするようにBGPを構成する」[RFC3882]で概説されている手法に拡張され、ソースアドレスによるフィルタリングを可能にする方法を実証します。
Network operators have developed a variety of techniques for mitigating denial-of-service (DoS) attacks. While different techniques have varying strengths and weaknesses, from an implementation perspective, the selection of which method to use for each type of attack involves evaluating the tradeoffs associated with each method.
ネットワークオペレーターは、サービス拒否（DOS）攻撃を緩和するためのさまざまな手法を開発しました。さまざまな手法には、実装の観点からさまざまな長所と短所がありますが、各タイプの攻撃に使用する方法の選択には、各方法に関連付けられたトレードオフを評価することが含まれます。
A common DoS attack directed against a customer of a service provider involves generating a greater volume of attack traffic destined for the target than will fit down the links from the service provider(s) to the victim (customer). This traffic "starves out" legitimate traffic and often results in collateral damage or negative effects to other customers or the network infrastructure as well. Rather than having all destinations on their network be affected by the attack, the customer may ask their service provider to filter traffic destined to the target destination IP address(es), or the service provider may determine that this is necessary themselves, in order to preserve network availability.
サービスプロバイダーの顧客に対する一般的なDOS攻撃には、サービスプロバイダーから被害者（顧客）へのリンクに適合するよりも、ターゲット向けの攻撃トラフィックを大量に生成することが含まれます。このトラフィックは、合法的なトラフィックを「飢え」、他の顧客やネットワークインフラストラクチャにも担保損傷または悪影響をもたらすことがよくあります。ネットワーク上のすべての目的地を攻撃の影響を受けるのではなく、顧客はサービスプロバイダーにターゲットの宛先IPアドレスに運命づけられているトラフィックをフィルタリングするように依頼することができます。または、サービスプロバイダーは、これがそれ自体が必要であると判断することができます。ネットワークの可用性を保持します。
One method that the service provider can use to implement this filtering is to deploy access control lists on the edge of their network. While this technique provides a large amount of flexibility in the filtering, it runs into scalability issues, both in terms of the number of entries in the filter and the packet rate.
サービスプロバイダーがこのフィルタリングを実装するために使用できる1つの方法は、ネットワークの端にアクセス制御リストを展開することです。この手法はフィルタリングに大量の柔軟性を提供しますが、フィルターのエントリ数とパケットレートの両方の点で、スケーラビリティの問題になります。
Most routers are able to forward traffic at a much higher rate than they are able to filter, and they are able to hold many more forwarding table entries and routes than filter entries. RTBH filtering leverages the forwarding performance of modern routers to filter more entries and at a higher rate than access control lists would otherwise allow.
ほとんどのルーターは、フィルタリングできるよりもはるかに高いレートでトラフィックを転送することができ、フィルターエントリよりも多くの転送テーブルエントリとルートを保持することができます。RTBHフィルタリングは、最新のルーターの転送パフォーマンスを活用して、より多くのエントリをフィルタリングし、それ以外の場合はアクセス制御リストよりも高いレートでフィルタリングします。
However, with destination-based RTBH filtering, the impact of the attack on the target is complete. That is, destination-based RTBH filtering injects a discard route into the forwarding table for the target prefix. All packets towards that destination, attack traffic AND legitimate traffic, are then dropped by the participating routers,thereby taking the target completely offline. The benefit is that collateral damage to other systems or network availability at the customer location or in the ISP network is limited, but the negative impact to the target itself is arguably increased.
ただし、宛先ベースのRTBHフィルタリングでは、ターゲットに対する攻撃の影響が完了します。つまり、宛先ベースのRTBHフィルタリングは、ターゲットプレフィックスの転送テーブルに破棄ルートを注入します。その目的地に向かうすべてのパケット、攻撃トラフィック、および合法的なトラフィックは、参加するルーターによってドロップされ、それによりターゲットを完全にオフラインにします。利点は、顧客の場所またはISPネットワークでの他のシステムまたはネットワークの可用性への担保損害が限られているが、ターゲット自体へのマイナスの影響は間違いなく増加することです。
By coupling unicast Reverse Path Forwarding (uRPF) [RFC3704] techniques with RTBH filtering, BGP can be used to distribute discard routes that are based not on destination or target addresses, but on source addresses of unwanted traffic. Note that this will drop all traffic to/from the address, and not just the traffic to the victim.
ユニキャスト逆パス転送（URPF）[RFC3704] RTBHフィルタリングを使用した手法を結合することにより、BGPを使用して、宛先またはターゲットアドレスではなく、不要なトラフィックのソースアドレスに基づいた廃棄ルートを配布できます。これにより、被害者へのトラフィックだけでなく、住所からのすべてのトラフィックがドロップされることに注意してください。
This document is broken up into three logical parts: the first outlines how to configure destination-based RTBH, the second covers source-based RTBH, and the third part has examples and a history of the technique.
このドキュメントは3つの論理パーツに分割されています。1つ目は、宛先ベースのRTBHを構成する方法を概説します。2番目はソースベースのRTBHをカバーし、3番目の部分には例とテクニックの履歴があります。
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 RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
A discard route is installed on each edge router in the network with the destination set to the discard (or null) interface. In order to use RTBH filtering for a single IP address (or prefix), a BGP route for the address to be filtered is announced, with the next-hop set as the discard route. This causes traffic to the announced network prefix to be forwarded to the discard interface so that it does not transit the network wasting resources or triggering collateral damage to other resources along the path towards the target.
ネットワーク内の各エッジルーターに廃棄ルートが設置されており、宛先が破棄（またはnull）インターフェイスに設定されています。単一のIPアドレス（または接頭辞）にRTBHフィルタリングを使用するために、フィルタリングするアドレスのBGPルートが発表され、次のホップセットが破棄ルートとして設定されます。これにより、発表されたネットワークプレフィックスへのトラフィックが廃棄インターフェイスに転送されるため、ネットワークがリソースを浪費したり、ターゲットに向かって他のリソースに担保損傷を引き起こしたりすることができません。
While this does "complete" the attack in that the target address(es) are made unreachable, collateral damage is minimized. It may also be possible to move the host or service on the target IP address(es) to another address and keep the service up, for example, by updating associated DNS resource records.
これにより、ターゲットアドレスが到達できないという点で攻撃が「完了」しますが、付随的な損傷は最小限に抑えられます。また、ターゲットIPアドレスのホストまたはサービスを別のアドレスに移動し、関連するDNSリソースレコードを更新することにより、サービスを維持することもできます。
Before deploying RTBH filtering, there is some preparation and planning that needs to occur and decisions that need to be made. These include:
RTBHフィルタリングを展開する前に、発生する必要がある準備と計画があり、決定する必要がある決定があります。これらには以下が含まれます：
- What are the discard addresses?
- 破棄アドレスは何ですか？
- What are the discard BGP communities?
- 廃棄BGPコミュニティは何ですか？
- What is the largest prefix that can be black-holed?
- ブラックホールにできる最大の接頭辞は何ですか？
- What is the smallest advertisement that your provider will accept?
- プロバイダーが受け入れる最小の広告は何ですか？
Steps to configure destination-based RTBH filtering:
宛先ベースのRTBHフィルタリングを構成する手順：
Step 1. Select Your Discard Address Schema
ステップ1.廃棄アドレススキーマを選択します
An address is chosen to become the "discard address". This is often chosen from 192.0.2.0/24 (TEST-NET [RFC3330]), or from RFC 1918 [RFC1918] space. Multiple addresses allow an operator to configure multiple static routes, one for each incident:
住所が「廃棄アドレス」になるために選択されます。これは、多くの場合、192.0.2.0/24（test-net [rfc3330]）またはRFC 1918 [RFC1918]スペースから選択されます。複数のアドレスを使用すると、オペレーターは、インシデントごとに複数の静的ルートを構成できます。
192.0.2.1 = Incident #1
192.0.2.2 = Incident #2
192.0.2.3 = Incident #3
192.0.2.4 = Incident #4
192.0.2.5 = Incident #5
Customer #1, who has a DDoS (Distributed DoS) attack can be pointed to discard route 192.0.2.1. Customer #2 can be pointed to discard route 192.0.2.2. If capable, the router can then count the drops for each, providing some level of telemetry on the volume of drops as well as status of an ongoing attack. A consistent address schema facilitates operations.
DDOS（分散DOS）攻撃を持っている顧客＃1は、ルート192.0.2.1を破棄することを指摘できます。顧客＃2は、ルート192.0.2.2を破棄することを指摘できます。有能な場合、ルーターはそれぞれのドロップをカウントし、進行中の攻撃のステータスと同様に、ドロップのボリュームに関するある程度のテレメトリを提供できます。一貫したアドレススキーマは、操作を促進します。
Step 2. Configure the Discard Route(s) on Each Router
ステップ2.各ルーターの廃棄ルートを構成します
A route for the "discard address" is installed on the routers that form the edge/perimeter of the network in all routers in the network or some subset (e.g., peering, but not customer, etc.). The destination of the route is set to the "discard" or "null" interface. This route is called the "discard route". Implementation experience demonstrates the value of configuring each ingress router with a capability for dropping traffic via RTBH filtering.
「廃棄アドレス」のルートは、ネットワーク内のすべてのルーターまたは一部のサブセット（例えば、ピアリング、顧客などではなく）にネットワークのエッジ/境界線を形成するルーターに取り付けられています。ルートの宛先は、「破棄」または「null」インターフェイスに設定されています。このルートは「廃棄ルート」と呼ばれます。実装エクスペリエンスは、RTBHフィルタリングを介してトラフィックを削除する機能を使用して、各イングレスルーターを構成する価値を示しています。
Step 3. Configure the RTBH BGP Policy on Each Router
ステップ3.各ルーターでRTBH BGPポリシーを構成します
A BGP policy is configured on all routers that have the discard route so that routes announced with a chosen community will have their next-hop set to the discard address. The BGP policy should be made restrictive so that only BGP routes covering a defined number of hosts addresses will be accepted. That is, typically, only specific /32s are necessary. Shorter prefix blocks may also be required or desirable, for example, if larger numbers of attack targets are located within a single prefix, or the employment of this mechanism is to drop traffic bound for specific networks. When filtering based on shorter prefixes, extreme caution should be used as to avoid collateral damage to other hosts that reside within those address blocks. Full implementations will have multiple communities, with each community used for different parts of a provider's network and for different security incidents.
BGPポリシーは、廃棄ルートを持つすべてのルーターで構成されているため、選択されたコミュニティで発表されたルートが次のホップセットを破棄アドレスに設定します。BGPポリシーは、定義された数のホストアドレスをカバーするBGPルートのみが受け入れられるように制限する必要があります。つまり、通常、特定の /32のみが必要です。たとえば、より短いプレフィックスブロックも必要または望ましい場合があります。たとえば、単一のプレフィックス内に攻撃ターゲットの数が多い場合、またはこのメカニズムの雇用が特定のネットワークにバインドされたトラフィックをドロップする場合です。短いプレフィックスに基づいてフィルタリングする場合、それらのアドレスブロック内に存在する他のホストへの付随的な損傷を避けるために、極端な注意を払う必要があります。完全な実装には複数のコミュニティがあり、各コミュニティはプロバイダーのネットワークのさまざまな部分とさまざまなセキュリティインシデントに使用されます。
Step 4. Configure the Safety Egress Prefix Filters
ステップ4.安全出口プレフィックスフィルターを構成します
There is always a chance that the triggering BGP update could leak from the network and so egress prefix filters are strongly recommended. These egress prefix filter details may vary, but experience has demonstrated that the following works:
トリガーするBGPアップデートがネットワークから漏れている可能性があるため、出力プレフィックスフィルターが強く推奨される可能性があります。これらの出力プレフィックスフィルターの詳細はさまざまな場合がありますが、経験により、次の動作が実証されています。
- Deny all prefixes longer than the longest prefix that you expect to announce. For example, if the longest prefix that you expect to announce is /24, deny all prefixes of length /25 though /32. If your triggering BGP update is only /32s, then this egress prefix filter will add a safe measure in case the NO_EXPORT community does not work.
- 発表する予定の最長のプレフィックスよりも長いすべてのプレフィックスを拒否します。たとえば、発表する予定の最長のプレフィックスが /24の場合、長さ /25のすべてのプレフィックスを拒否しますが、 /32。BGPアップデートのトリガーが32Sのみである場合、NO_Exportコミュニティが機能しない場合に、この出力プレフィックスフィルターは安全な測定値を追加します。
- Deny all communities used for triggering RTBH filtering. This is also a "safety" measure in case the NO_EXPORT community does not work.
- RTBHフィルタリングのトリガーに使用されるすべてのコミュニティを拒否します。これは、NO_EXPORTコミュニティが機能しない場合の「安全性」尺度でもあります。
Step 5: Configure the Trigger Router
ステップ5：トリガールーターを構成します
Configure the trigger router, workstation, or other device so that adding and removing the triggers can be done easily and quickly. The BGP update should have the NO_EXPORT community as a mandatory attribute. An egress prefix filter or policy that prevents RTBH filtering prefixes in the /8 to /24 range is also recommended as a safety tool. The trigger router can be set up as an iBGP (Internal BGP) route reflector client that does not receive any prefixes from its BGP peer. This allows a low-cost router/workstation to be used as the trigger router.
トリガールーター、ワークステーション、またはその他のデバイスを構成して、トリガーを簡単かつ迅速に実行できるようにします。BGPアップデートには、NO_Exportコミュニティが必須属性として存在する必要があります。/8〜 /24範囲のRTBHフィルタリングのプレフィックスを防ぐEugressプレフィックスフィルターまたはポリシーも、安全ツールとして推奨されます。トリガールーターは、BGPピアからプレフィックスを受け取らないIBGP（内部BGP）ルートリフレクタークライアントとして設定できます。これにより、低コストのルーター/ワークステーションをトリガールーターとして使用できます。
Using the RTBH filtering:
RTBHフィルタリングの使用：
1: When RTBH filtering is desired for a specific address, that address is announced from a trigger router (or route server), tagged with the chosen "RTBH" community and with the NO_EXPORT community, and passed via iBGP. The receiving routers check the BGP policy, set the next-hop to be the discard route, resulting in a Forwarding Information Base (FIB) entry pointing to a discard address.
1：特定のアドレスに対してRTBHフィルタリングが必要な場合、そのアドレスはトリガールーター（またはルートサーバー）から発表され、選択した「RTBH」コミュニティとNO_EXPORTコミュニティでタグ付けされ、IBGP経由で通過します。受信ルーターは、BGPポリシーをチェックし、次のホップを破棄ルートに設定し、廃棄アドレスを指す転送情報ベース（FIB）エントリになります。
2: Traffic entering the network will now be forwarded to the discard interface on all edge routers and will therefore be dropped at the edge of the network, saving resources.
2：ネットワークに入るトラフィックは、すべてのエッジルーターの破棄インターフェイスに転送されるため、ネットワークの端にドロップされ、リソースが節約されます。
2.1: Multiple Discard Addresses for Incident Granularity. This technique can be expanded by having multiple discard addresses, routes, and communities to allow for monitoring of the discarded traffic volume on devices that support multiple discard interfaces. As mentioned earlier, each router can have a discard address schema to allow the operator to distinguish multiple incidents from each other -- making it easier to monitor the life-cycle of the incidents.
2.1：インシデントの粒度のための複数の破棄アドレス。この手法は、複数の廃棄アドレス、ルート、コミュニティを搭載して、複数の破棄インターフェイスをサポートするデバイス上の廃棄された交通量の監視を可能にすることで拡張できます。前述のように、各ルーターは、オペレーターが複数のインシデントを互いに区別できるようにするために、廃棄アドレススキーマを持つことができます。
2.2: Multiple "Trigger Communities" for Network-Wide Granularity. The network can be sectioned into multiple communities, providing the operator with an ability to drop in discrete parts of their network. For example, the network can be divided into the following communities (where XXX represents the operator's AS number):
2.2：ネットワーク全体の粒度のための複数の「トリガーコミュニティ」。ネットワークは複数のコミュニティにセクション化でき、オペレーターにネットワークの個別の部分を落とす機能を提供できます。たとえば、ネットワークは次のコミュニティに分けることができます（XXXはオペレーターのAS番号を表します）。
XXX:600 RTBH filtering on all routers XXX:601 RTBH filtering on only peering routers XXX:602 RTBH filtering on only customers who peer BGP XXX:603 RTBH filtering on data centers (to see if the data center is the source of attack)
XXX：すべてのルーターでの600 RTBHフィルタリングxxx：601 RTBHピアリングルーターのみのRTBHフィルタリングXXX：602 RTBH BGP XXX：603 RTBHフィルタリングデータセンターでのフィルタリング（データセンターが攻撃のソースであるかどうかを確認するため）
XXX:604 RTBH filtering on all customers (to see how many customers are being used by the attacker)
XXX：604 RTBHすべての顧客のフィルタリング（攻撃者が使用している顧客の数を確認するため）
Some diligent thinking is required to develop a community schema that provides flexibility while reflecting topological considerations.
トポロジカルな考慮事項を反映しながら柔軟性を提供するコミュニティスキーマを開発するには、いくつかの勤勉な思考が必要です。
2.3: "Customer-Triggered" RTBH filtering. The technique can also be expanded by relaxing the Autonomous System (AS) path rule to allow customers of a service provider to enable RTBH filtering without interacting with the service provider's trigger routers. If this is configured, an operator MUST only accept announcements from the customer for prefixes that the customer is authorized to advertise, in order to prevent the customer from accidentally (or intentionally) black-holing space that they are not allowed to advertise.
2.3：「顧客トリガー」RTBHフィルタリング。また、サービスプロバイダーの顧客がサービスプロバイダーのトリガールーターと対話せずにRTBHフィルタリングを有効にできるようにするために、自律システム（AS）パスルールを緩和することにより、この手法を拡張することもできます。これが構成されている場合、オペレーターは、顧客が誤って（または意図的に）宣伝することが許可されていないブラックホーリングスペースを誤って（または意図的に）防ぐために、顧客が宣伝する権限を与えられているプレフィックスについての顧客からの発表のみを受け入れる必要があります。
A common policy for this type of setup would first permit any longer prefix within an authorized prefix only if the black hole communities are attached, append NO_EXPORT, NO_ADVERTISE, or similar communities, and then also accept from the customer the original aggregate prefix that will be advertised as standard policy permits.
このタイプのセットアップの一般的なポリシーは、ブラックホールコミュニティが添付されている場合にのみ、認定プレフィックス内で最初に許可されます。標準的なポリシー許可として宣伝されています。
Extreme caution should be used in order to avoid leaking any more specifics beyond the local routing domain, unless policy explicitly aims at doing just that.
ポリシーが明示的にそれを行うことを目指していない限り、ローカルルーティングドメイン以外の詳細を漏らすことを避けるために、極端な注意を払う必要があります。
In many instances, denial-of-service attacks sourced from botnets are being configured to "follow DNS". (The attacking machines are instructed to attack www.example.com, and re-resolve this periodically. Historically, the attacks were aimed simply at an IP address and so renumbering www.example.com to a new address was an effective mitigation.) This makes it desirable to employ a technique that allows black-holing to be based on source address.
多くの場合、ボットネットから供給されたサービス拒否攻撃は、「DNSに従う」ように構成されています。（攻撃マシンはwww.example.comを攻撃し、これを定期的に再解決するように指示されます。歴史的に、攻撃は単にIPアドレスを目指していたため、www.example.comを新しいアドレスに変更することは効果的な緩和でした。）これにより、ブラックホーリングがソースアドレスに基づいていることを可能にする手法を採用することが望ましいものになります。
By combining traditional RTBH filtering with unicast Reverse Path Forwarding (uRPF), a network operator can filter based upon the source address. uRPF performs a route lookup of the source address of the packet and checks to see if the ingress interface of the packet is a valid egress interface for the packet source address (strict mode) or if any route to the source address of the packet exists (loose mode). If the check fails, the packet is typically dropped. In loose mode, some vendors also verify that the destination route does not point to an invalid next-hop -- this allows source-based RTBH filtering to be deployed in networks that cannot implement strict (or feasible path) mode uRPF. Before enabling uRPF (in any mode), it is vital that you fully understand the implications of doing so:
従来のRTBHフィルタリングとユニキャストリバースパス転送（URPF）を組み合わせることにより、ネットワークオペレーターはソースアドレスに基づいてフィルタリングできます。URPFは、パケットのソースアドレスのルート検索を実行し、パケットのイングレスインターフェイスがパケットソースアドレスの有効な出口インターフェイスであるかどうか（Strict Mode）か、パケットのソースアドレスへのルートが存在するかどうかを確認します。ルーズモード）。チェックが失敗した場合、パケットは通常削除されます。ルーズモードでは、一部のベンダーは、宛先ルートが無効なネクストホップを指していないことを確認します。これにより、ソースベースのRTBHフィルタリングを、厳格な（または実現可能なパス）モードURPFを実装できないネットワークに展開できます。（任意のモードで）URPFを有効にする前に、そうすることの意味を完全に理解することが重要です。
- Strict mode will cause the router to drop all ingress traffic if the best path back to the source address of the traffic is not the interface from which the traffic was received. Asymmetric routing will cause strict mode uRPF to drop legitimate traffic.
- 厳密なモードは、トラフィックのソースアドレスに最適なパスがトラフィックを受信したインターフェイスではない場合、ルーターがすべてのイングレストラフィックをドロップします。非対称ルーティングにより、厳密なモードURPFが合法的なトラフィックを削除します。
- Loose mode causes the router to check if a route for the source address of the traffic exists. This may also cause legitimate traffic to be discarded.
- ルーズモードにより、ルーターがトラフィックのソースアドレスのルートが存在するかどうかを確認します。これにより、合法的なトラフィックが破棄される可能性があります。
It is hoped that in the future, vendors will implement a "DoS-mitigation" mode in addition to the loose and strict modes -- in this mode, the uRPF check will only fail if the next-hop for the source of the packet is a discard interface.
将来的には、ベンダーはゆるくて厳格なモードに加えて「DOS緩和」モードを実装することが期待されています。このモードでは、パケットのソースの次のホップがある場合にのみURPFチェックが失敗することがあります。廃棄インターフェイス。
By enabling the uRPF feature on interfaces at predetermined points in their network and announcing the source address(es) of attack traffic, a network operator can effectively drop the identified attack traffic at specified devices (ideally ingress edge) of their network based on source address.
ネットワーク内の事前に決められたポイントでインターフェイス上のURPF機能を有効にし、攻撃トラフィックのソースアドレスを発表することにより、ネットワークオペレーターは、ソースアドレスに基づいてネットワークの指定されたデバイス（理想的には侵入エッジ）で特定された攻撃トラフィックを効果的にドロップできます。。
While administrators may choose to drop traffic from any prefix they wish, it is recommended when employing source-based RTBH filtering inter-domain that explicit policy be defined that enables peers to only announce source-based RTBH routes for prefixes that they originate.
管理者は、希望する任意のプレフィックスからトラフィックをドロップすることを選択できますが、ソースベースのRTBHフィルタリング間ドメインを使用する場合は、プリティが発生するプレフィックスのソースベースのRTBHルートのみを発表できるようにする明示的なポリシーを定義することをお勧めします。
The same steps that are required to implement destination address RTBH filtering are taken with the additional step of enabling unicast Reverse Path Forwarding on predetermined interfaces. When a source address (or network) needs to be blocked, that address (or network) is announced using BGP tagged with a community. This will cause the route to be installed with a next-hop of the discard interface, causing the uRPF check to fail and the packets to be discarded. The destination-based RTBH filtering community should not be used for source-based RTBH filtering, and the routes tagged with the selected community should be carefully filtered.
宛先アドレスRTBHフィルタリングを実装するために必要な同じ手順は、所定のインターフェイスでユニキャストリバースパス転送を可能にする追加のステップで実行されます。ソースアドレス（またはネットワーク）をブロックする必要がある場合、そのアドレス（またはネットワーク）がコミュニティでタグ付けされたBGPを使用して発表されます。これにより、廃棄インターフェイスの次のホップでルートがインストールされ、URPFチェックが故障し、パケットが破棄されます。宛先ベースのRTBHフィルタリングコミュニティは、ソースベースのRTBHフィルタリングに使用しないでください。選択したコミュニティでタグ付けされたルートは慎重にフィルタリングする必要があります。
The BGP policy will need to be relaxed to accept announcements tagged with this community to be accepted even though they contain addresses not controlled by the network announcing them. These announcements must NOT be propagated outside the local AS and should carry the NO_EXPORT community.
BGPポリシーは、ネットワークが発表するネットワークによって制御されていないアドレスが含まれていても、このコミュニティにタグ付けされたアナウンスを受け入れるためにリラックスする必要があります。これらの発表は、地元のASの外で伝播してはならず、NO_Exportコミュニティを運ぶべきです。
As a matter of policy, operators SHOULD NOT accept source-based RTBH announcements from their peers or customers, they should only be installed by local or attack management systems within their administrative domain.
ポリシーの問題として、オペレーターは、同僚や顧客からのソースベースのRTBH発表を受け入れるべきではありません。彼らは、管理領域内のローカルまたは攻撃管理システムによってのみインストールされるべきです。
The techniques presented here provide enough power to cause significant traffic forwarding loss if incorrectly deployed. It is imperative that the announcements that trigger the black-holing are carefully checked and that the BGP policy that accepts these announcements is implemented in such a manner that the announcements:
ここに掲載されている技術は、誤って展開された場合、大幅なトラフィック転送の損失を引き起こすのに十分な力を提供します。ブラックホーリングのトリガーが慎重にチェックされること、およびこれらのアナウンスを受け入れるBGPポリシーが、発表のような方法で実装されることを発表することが不可欠です。
- Are not propagated outside the AS (NO_EXPORT).
- As（no_export）の外で伝播されません。
- Are not accepted from outside the AS (except from customers).
- AS（顧客からを除く）の外部から受け入れられません。
- Except where source-based filtering is deployed, that the network contained in the announcement falls within the address ranges controlled by the announcing AS (i.e., for customers that the address falls within their space).
- ソースベースのフィルタリングが展開されている場合を除き、発表に含まれるネットワークは、アナウンスによって制御されるアドレス範囲内にあります（つまり、住所がスペース内に収まるという顧客向け）。
I would like to thank Joe Abley, Ron Bonica, Rodney Dunn, Alfred Hoenes, Donald Smith, Joel Jaeggli, and Steve Williams for their assistance, feedback and not laughing *too* much at the quality of the initial versions.
ジョー・イーブリー、ロン・ボニカ、ロドニー・ダン、アルフレッド・ホーネス、ドナルド・スミス、ジョエル・ジェグリ、スティーブ・ウィリアムズの援助、フィードバック、最初のバージョンの品質にあまりにも笑わないことに感謝します。
I would also like to thank all of the regular contributors to the OPSEC Working Group and Google for 20% time :-)
また、OPSECワーキンググループとGoogleへの通常の貢献者全員に20％の時間に感謝したいと思います:-)
The authors would also like to thank Steven L Johnson and Barry Greene for getting this implemented and Chris Morrow for publicizing the technique in multiple talks.
著者はまた、これを実装してくれたSteven L JohnsonとBarry Greeneと、複数の講演でテクニックを公表してくれたChris Morrowに感謝したいと思います。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、Moskowitz、B.、Karrenberg、D.、De Groot、G。、およびE. Lear、「Private Internetsのアドレス割り当て」、BCP 5、RFC 1918、1996年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月。
[RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002.
[RFC3330] IANA、「特別使用IPv4アドレス」、RFC 3330、2002年9月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704] Baker、F。およびP. Savola、「マルチホームネットワークのイングレスフィルタリング」、BCP 84、RFC 3704、2004年3月。
[RFC3882] Turk, D., "Configuring BGP to Block Denial-of-Service Attacks", RFC 3882, September 2004.
[RFC3882] Turk、D。、「サービス拒否攻撃をブロックするためにBGPの構成」、RFC 3882、2004年9月。
[Greene2001] Greene Barry Raveendran and Jarvis Neil, "Unicast Reverse Path Forwarding (uRPF) Enhancements for the ISP-ISP Edge", ftp://ftp-eng.cisco.com/ cons/isp/documents/uRPF_Enhancement.pdf, 2001.
[Greene2001] Greene Barry RaveendranとJarvis Neil、「ISP-ISP EdgeのUnicast Reverse Path Forwarding（URPF）強化」、ftp：//ftp-eng.cisco.com/ cons/isp/documents/urpf_enhancement.pdf、2001。
This section provides a partial configuration for configuring RTBH filtering on a Cisco router. This is not a complete configuration and should be customized before being used.
このセクションでは、CiscoルーターでRTBHフィルタリングを構成するための部分的な構成を提供します。これは完全な構成ではなく、使用する前にカスタマイズする必要があります。
Announcing router: ! The discard route ip route 192.0.2.1 255.255.255.255 Null0 ! ! Matches and empty AS-PATH only. ip as-path access-list 10 permit ^$ ! ! This route-map matches routes with tag 666 and sets the next-hop ! to be the discard route. route-map remote-trigger-black-hole permit 10 match tag 666 set ip next-hop 192.0.2.1 set local-preference 200 set community no-export ! The community used internally to tag RTBH announcements. set community 65505:666 set origin igp ! route-map remote-trigger-black-hole permit 20 ! router bgp 65505 no synchronization bgp log-neighbor-changes redistribute static route-map remote-trigger-black-hole no auto-summary ! ! An example IP that we are applying RTBH filtering to. ! All traffic destined to 10.0.0.1 will now be dropped! ip route 10.0.0.1 255.255.255.255 null0 tag 666 !
ルーターの発表：！破棄ルートIPルート192.0.2.1 255.255.255.255 null0！！マッチと空のように空のみ。IP As-Path Access-List 10許可 ^$！！このルートマップは、タグ666とルートと一致し、次のホップを設定します！廃棄ルートになること。ルートマップリモートトリガーブラックホール許可10マッチタグ666セットIPネクストホップ192.0.2.1セットローカルプレーファレンス200セットコミュニティNO-Export！コミュニティは、RTBHアナウンスにタグを付けるために内部で使用しました。コミュニティ65505を設定：666 SET ORIGIN IGP！ルートマップリモートトリガーブラックホール許可20！ルーターBGP 65505同期なしBGP log-neighbor-changes redistribute static route-map remote-trigger-black-hole no auto-summary！！RTBHフィルタリングを適用しているIPの例。！10.0.0.1に運命づけられているすべてのトラフィックが削除されます！IPルート10.0.0.1 255.255.255.255 Null0タグ666！
Filtering router: ! ! The discard route ip route 192.0.2.1 255.255.255.255 Null0 ! ! Matches and empty AS-PATH only. ip as-path access-list 10 permit ^$ ! route-map black-hole-filter permit 10 match ip address prefix-list only-host-routes match as-path 10 match community 65505:666 no-export ! ! Don't accept any other announcements with the RTBH community. route-map black-hole-filter deny 20 match community 65505:666 ! route-map black-hole-filter permit 30 ! ! An interface for source-based RTBH filtering with uRPF loose mode. interface FastEthernet 0/0 ip verify unicast source reachable-via any
ルーターのフィルタリング：！！破棄ルートIPルート192.0.2.1 255.255.255.255 null0！！マッチと空のように空のみ。IP As-Path Access-List 10許可 ^$！ルートマップブラックホールフィルター許可10マッチIPアドレスプレフィックスリストのみホストルートマッチAS-PATH 10マッチコミュニティ65505：666 no-export！！RTBHコミュニティで他の発表を受け入れないでください。ルートマップブラックホールフィルター拒否20マッチコミュニティ65505：666！ルートマップブラックホールフィルター許可30！！URPFルーズモードを使用したソースベースのRTBHフィルタリングのインターフェイス。インターフェイスFastEthernet 0/0 IP Unicast Source Reachable-Via Anyを検証します
This section provides a partial configuration for configuring RTBH filtering on a Juniper router. This is not a complete configuration and should be customized before being used.
このセクションでは、ジュニパールーターでRTBHフィルタリングを構成するための部分的な構成を提供します。これは完全な構成ではなく、使用する前にカスタマイズする必要があります。
Announcing router:
ルーターのアナウンス：
routing-options {
static {
/* EXAMPLE ATTACK SOURCE */
route 10.11.12.66/32 {
next-hop 192.0.2.1;
resolve;
tag 666;
}
/* EXAMPLE ATTACK DESTINATION */
route 10.128.0.2/32 {
next-hop 192.0.2.1;
resolve;
tag 666;
}
}
autonomous-system 100;
}
protocols {
bgp {
group ibgp {
type internal;
export rtbh;
neighbor 172.16.0.2;
}
}
}
policy-options {
policy-statement rtbh {
term black-hole-filter {
from {
tag 666;
route-filter 0.0.0.0/0 prefix-length-range /32-/32;
}
then {
local-preference 200;
origin igp;
community set black-hole;
community add no-export;
next-hop 192.0.2.1;
accept;
}
}
}
community black-hole members 100:666;
community no-export members no-export;
}
Filtering router:
ルーターのフィルタリング：
policy-statement black-hole-filter {
from {
protocol bgp;
as-path LocalOnly;
community black-hole;
route-filter 0.0.0.0/0 prefix-length-range /32-/32;
}
then {
community set no-export;
next-hop 192.0.2.1;
}
}
community black-hole members 100:666;
community no-export members no-export;
routing-options {
forwarding-table {
unicast-reverse-path feasible-paths;
}
static {
route 192.0.2.1/32 discard;
}
}
interfaces {
xe-1/0/0 {
vlan-tagging;
mtu 9192;
unit 201 {
vlan-id 201;
family inet {
rpf-check;
address 10.11.12.1/24;
}
}
}
}
Understanding the history and motivation behind the development of a technique often helps with understanding how to best utilize the technique. In this spirit, we present a history of unicast RPF and RTBH filtering.
テクニックの開発の背後にある歴史と動機を理解することは、多くの場合、テクニックを最大限に活用する方法を理解するのに役立ちます。この精神では、ユニキャストRPFとRTBHフィルタリングの歴史を提示します。
This section has been provided by Barry Raveendran Greene:
このセクションは、Barry Raveendran Greeneによって提供されています。
Unicast RPF Loose Check (uRPF Loose Check) was created by Neil Jarvis and Barry Greene to be used with destination-based RTBH as a rapid reaction tool to DDoS attacks. The requirements for this rapid reaction tool was based on post mortem conversation after the February 2000 attacks on several big content hosting companies. The summary of the requirement became the "Exodus Requirement" which stated:
ユニキャストRPFルーズチェック（URPFルーズチェック）は、Neil JarvisとBarry Greeneによって作成され、DDOS攻撃の迅速な反応ツールとして目的地ベースのRTBHとともに使用されました。この迅速な反応ツールの要件は、2000年2月にいくつかの大規模なコンテンツホスティング会社に対する攻撃後の死後会話に基づいていました。要件の概要は、次のように述べた「出エジプト記的要件」になりました。
We need a tool to drop packets based on source IP address that can be pushed out to over 60 routers within 60 seconds, be longer than a thousand lines, be modified on the fly, and work in all your platforms filtering at line rate.
ソースIPアドレスに基づいてパケットをドロップするツールが必要です。ソースIPアドレスは、60秒以内に60以上のルーターに押し出され、1,000回以上のラインよりも長くなり、その場で変更され、すべてのプラットフォームでラインレートでフィルタリングします。
A variety of options were looked at to meet this requirement, from reviving Common Open Policy Service (COPS), to pushing out Access Control Lists (ACLs) with BGP, creating a new protocol. In 2000, the quickest way to meet the "Exodus requirement" was to marry two functions. First, modify unicast RPF so that the interface check was no longer required and to make sure that a "null" or discard route would drop the packet (i.e., loose check). Second, the technique where BGP is used to trigger a distributed drop is dusted off and documented. Combining these two techniques was deemed a fast way to put a distributed capability to drop packets out into the industry.
Common Open Policy Service（COPS）の復活からBGPでアクセス制御リスト（ACL）を押し出し、新しいプロトコルを作成するまで、この要件を満たすために、さまざまなオプションが検討されました。2000年には、「出エジプト記録」を満たす最も迅速な方法は、2つの機能と結婚することでした。まず、ユニキャストRPFを変更して、インターフェイスチェックが不要になったように変更し、「null」または廃棄ルートがパケットをドロップすることを確認します（つまり、緩いチェック）。第二に、分散ドロップをトリガーするためにBGPを使用して使用される手法は、粉砕され、文書化されています。これらの2つの手法を組み合わせることで、分散型の機能を業界に落とすための分散機能を置くための迅速な方法と見なされました。
To clarify and restate, uRPF loose check was created as one part of a rapid reaction tool to DDoS attacks that "drop packets based on source IP address that can be pushed out to over 60 routers with in 60 seconds, be longer than a thousand lines, be modified on the fly, and work in all your platforms filtering at line rate". The secondary benefits of using uRPF Loose Check for other functions is a secondary benefit -- not the primary goal for its creation.
明確にして再定義するために、URPFルーズチェックは、「60秒以上で60回以上のルーターに押し出すことができるソースIPアドレスに基づいてパケットをドロップする」というDDOS攻撃の迅速な反応ツールの一部として作成されました。、その場で変更され、すべてのプラットフォームでラインレートでフィルタリングする」で動作します」。他の機能にURPFルーズチェックを使用することの二次的な利点は、その作成の主な目標ではなく、二次的な利点です。
To facilitate the adoption to the industry, uRPF Loose Check was not patented. It was publicly published and disclosed in "Unicast Reverse PathForwarding (uRPF) Enhancements for the ISP-ISP Edge" [Greene2001].
業界への採用を促進するために、URPFの緩いチェックは特許を取得していませんでした。「ISP-ISPエッジのユニキャスト逆パスフォーワード（URPF）強化」[Greene2001]で公開され、開示されました。
Authors' Addresses
著者のアドレス
Warren Kumari Google 1600 Amphitheatre Parkway Mountain View, CA 94043
ウォーレンクマリグーグル1600円形劇場パークウェイマウンテンビュー、カリフォルニア94043
EMail: warren@kumari.net
Danny McPherson Arbor Networks, Inc.
Danny McPherson Arbor Networks、Inc。
EMail: danny@arbor.net