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)
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.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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).
この文書は、送信元アドレス（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.
サービスプロバイダは、このフィルタリングを実装するために使用できる一つの方法は、ネットワークのエッジ上のアクセス制御リストを展開することです。この技術は、フィルタリングの柔軟性を大量に提供するが、それは、フィルタ内のエントリの数及びパケットレートの両面、スケーラビリティの問題に実行されます。
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つの論理部分に分割される：第一は、宛先ベースのRTBHを設定する方法を概説し、第二は、ソースベースのRTBHを覆い、第三の部分は実施例と技術の歴史を有しています。
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.
これは、そのターゲットアドレス（複数可）での攻撃が到達不能に作られて「完了」んが、担保の損傷が最小限に抑えられます。また、関連するDNSリソースレコードを更新することにより、例えば、別のアドレスにターゲットIPアドレス（複数可）上のホストやサービスを移動し、サービスアップを維持することが可能です。
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
192.0.2.1 =インシデント＃1 192.0.2.2 =インシデント＃2 192.0.2.3 =インシデント＃3 192.0.2.4 =インシデント＃4 192.0.2.5 =インシデント＃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.
「廃棄アドレス」のルートは、ネットワーク内のすべてのルータにおけるネットワークのエッジ/境界またはいくつかの部分集合（例えば、ピアリングではなく、顧客、等）を形成するルータにインストールされています。ルートの宛先を「破棄」または「ヌル」インターフェイスに設定されています。このルートは、「廃棄ルート」と呼ばれています。実装経験は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ポリシーに限定されるべきです。つまり、一般的に、唯一の特定/ 32Sが必要です。短いプレフィクスブロックも必要又は望ましい、例えば、攻撃対象のより大きな数は、単一のプレフィックス内に配置されている場合、またはこの機構の採用は、特定のネットワークに向かうトラフィックをドロップすることができます。短いプレフィックスに基づいてフィルタリングする場合、細心の注意は、これらのアドレスブロック内に存在する他のホストへの巻き添え被害を避けるために使用されるべきです。完全な実装は、プロバイダのネットワークのさまざまな部分のために、異なるセキュリティインシデントのために使用される各コミュニティで、複数のコミュニティを持っています。
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.
- あなたが発表することを期待最長プレフィックスよりも長いすべての接頭辞を拒否します。たとえば、あなたが発表すると予想される場合、最長プレフィックスが/ 32かかわらず、長さ/ 25のすべてのプレフィックスを拒否し、/ 24です。あなたのトリガ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フィルタリングプレフィックスを防止する出口プレフィックスフィルタまたはポリシーも安全ツールとして推奨されます。トリガルータは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: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:
ユニキャストRPF（uRPFの）伝統的なRTBHフィルタリングを組み合わせることによって、ネットワークオペレータは、送信元アドレスに基づいてフィルタリングすることができます。 uRPFのは、パケットの送信元アドレスのルートルックアップを実行し、（パケットの入力インターフェイスは、パケットの送信元アドレス（strictモード）の有効なイグレスインタフェースがあるかどうかをチェックし、またはパケットの送信元アドレスへのルートが存在する場合looseモード）。チェックに失敗した場合、パケットは一般的にドロップされます。これは、ソースベースの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.
パケットの送信元のネクストホップがある場合は、このモードでは、uRPFチェックのみが失敗します - 将来的には、ベンダーが緩いと厳格なモードに加えて、「DoS攻撃-緩和」モードを実装することが期待されています廃棄インターフェース。
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).
- 除くソース・ベースのフィルタリングが配備されている場合、アナウンスに含まれているネットワークが発表AS（すなわち、顧客のためのアドレスは、その空間内に入ること）によって制御されるアドレス範囲内にあること。
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.
私は彼らの支援、フィードバックと初期バージョンの品質で*あまりにも*ずっと笑っていないためにジョー・Abley、ロンBonica、ロドニー・ダン、アルフレッドHoenes、ドナルド・スミス、ジョエルJaeggli、とスティーブ・ウィリアムズに感謝したいと思います。
I would also like to thank all of the regular contributors to the OPSEC Working Group and Google for 20% time :-)
また、私は:-) 20％の時間のためにOPSECワーキンググループやGoogleへの定期的な貢献者のすべてに感謝したいと思います
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.
著者はまた、複数の会談で技術を宣伝するために、これは実装取得とクリス・モローのためのスティーブン・L・ジョンソンとバリー・グリーンに感謝したいと思います。
[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.、モスコウィッツ、B.、Karrenberg、D.、グルート、G.、およびE.リアド、 "個人的なインターネットのための配分"、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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]ベイカー、F.およびP. Savola、 "マルチホームネットワークの入力フィルタリング"、BCP 84、RFC 3704、2004年3月。
[RFC3882] Turk, D., "Configuring BGP to Block Denial-of-Service Attacks", RFC 3882, September 2004.
、RFC 3882、2004年9月 "ブロックサービス拒否攻撃へのBGPの設定" [RFC3882]トルコ人、D.、。
[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.
、ftp://ftp-eng.cisco.com/短所/ ISP /文書/ uRPF_Enhancement.pdf、2001 [Greene2001]グリーンバリー・レイブエンドランとジャービスニール、 "ISP-ISPエッジのためのユニキャストRPF（uRPFの）拡張" 。
Appendix A. Cisco Router Configuration Sample
付録A.シスコルータの設定サンプル
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ヌル0！ ！マッチや空のAS-PATHのみ。 IPなどのパスアクセスリスト10の許可^ $！ ！このルートマップは、タグ666とのルートに一致し、ネクストホップを設定します！廃棄ルートであることを。ルートマップのリモート・トリガ・ブラックホール許可証10試合タグ666セットのIPネクストホップ192.0.2.1設定されたローカル・プ200のセットコミュニティ無輸出！コミュニティはRTBHアナウンスをタグ付けするために内部で使用されます。設定コミュニティ65505：666セット原点IGP！ルートマップのリモート・トリガ・ブラックホール許可証20！ 65505 BGPルータには、同期のBGPログ近隣の変更は、スタティックルートマップのリモート・トリガ・ブラックホールなしの自動要約を再配布しません！ ！我々はRTBHフィルタリングを適用している例のIP。 ！ 10.0.0.1宛てのすべてのトラフィックはドロップされます！ IPルート10.0.0.1 255.255.255.255のヌル0タグ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ヌル0！ ！マッチや空のAS-PATHのみ。 IPなどのパスアクセスリスト10の許可^ $！ルートマップのブラックホール・フィルタ許可10試合のIPアドレスプレフィクスリストのみ - ホストルートの試合として、パス10試合コミュニティ65505：666ノー輸出！ ！ RTBHコミュニティと他のアナウンスを受け入れないでください。ルートマップのブラックホールフィルタ20試合コミュニティ65505拒否：666！ルートマップのブラックホール・フィルタ許可証30！ ！ uRPFのルーズモードとソースベースのRTBHフィルタリングするためのインターフェース。インタフェースファストイーサネット0/0 IP到達可能ビア任意のユニキャスト送信元を確認
Appendix B. Juniper Configuration Sample
付録B.ジュニパーの設定例
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;
}
}
}
}
Appendix C. A Brief History of RTBH Filtering
付録C. A RTBHフィルタリングの小史
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:
このセクションでは、バリー・レイブエンドラングリーンによって提供されています。
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ルーズチェック）が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.
私たちは、ラインレートでのフィルタリングすべてのプラットフォームでその場で修正し、作業すること、1000行よりも長く、60秒以内に60以上のルータに押し出すことができる送信元IPアドレスに基づいてパケットをドロップするツールが必要です。
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.
さまざまなオプションは、新しいプロトコルを作成し、BGPとアクセス制御リスト（ACL）を押し出すには、一般的なオープンポリシーサービス（COPS）を復活させるから、この要件を満たすために見ました。 2000年には、「出エジプト記の要件」を満たすための最も簡単な方法は、2つの機能を結婚することでした。まず、インタフェースのチェックが必要なくなったように、ユニキャストRPFを変更しないと、「ヌル」または破棄ルートがパケット（すなわち、緩いチェックを）落とすだろうことを確認します。第二に、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.
DDoS攻撃への迅速な反応ツールの一部は、60秒にして60以上のルータに押し出すことができる送信元IPアドレスに基づいて、ドロップパケットは、1000行よりも長く」という攻撃として明確にし、修正再表示するには、uRPFの緩やかなチェックが作成されました、「ラインレートでのフィルタリングすべてのプラットフォームでのフライ、そして仕事上で修正すること。その作成のための第一の目標ではない - 他の機能のためにルーズチェックを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エッジのためのユニキャストリバースPathForwarding（uRPFの）拡張」[Greene2001]に開示されました。
Authors' Addresses
著者のアドレス
Warren Kumari Google 1600 Amphitheatre Parkway Mountain View, CA 94043
ウォーレン・クマリGoogleの1600アンフィシアターパークウェイマウンテンビュー、CA 94043
EMail: warren@kumari.net
メールアドレス：warren@kumari.net
Danny McPherson Arbor Networks, Inc.
ダニー・マクファーソンアーバーネットワークス株式会社
EMail: danny@arbor.net
メールアドレス：danny@arbor.net