RFC 3882 - Configuring BGP to Block Denial-of-Service Attacks 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc3882
タイトル : RFC 3882 - サービス拒否攻撃をブロックするためにBGPを構成します
翻訳編集 : 自動生成

[要約] 要約：RFC 3882は、BGPを使用してDoS攻撃をブロックする方法についてのガイドラインです。目的：このRFCの目的は、BGPを使用してネットワークにおけるDoS攻撃を防ぐための設定方法を提供することです。

Network Working Group                                            D. Turk
Request for Comments: 3882                                   Bell Canada
Category: Informational                                   September 2004

Configuring BGP to Block Denial-of-Service Attacks

サービス拒否攻撃をブロックするためにBGPを構成します

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.

このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。

著作権表示

著作権（c）The Internet Society（2004）。

Abstract

概要

This document describes an operational technique that uses BGP communities to remotely trigger black-holing of a particular destination network to block denial-of-service attacks. Black-holing can be applied on a selection of routers rather than all BGP-speaking routers in the network. The document also describes a sinkhole tunnel technique using BGP communities and tunnels to pull traffic into a sinkhole router for analysis.

このドキュメントでは、BGPコミュニティを使用して特定の宛先ネットワークのブラックホーリングをリモートでトリガーし、サービス拒否攻撃をブロックする運用手法について説明します。ブラックホーリングは、ネットワーク内のすべてのBGP語を話すルーターではなく、ルーターの選択に適用できます。このドキュメントでは、BGPのコミュニティとトンネルを使用して、分析のためにトラフィックを陥没穴ルーターに引き込む陥没穴トンネル技術についても説明しています。

Table of Contents

   1.  Existing BGP-Triggered Black holing Techniques . . . . . . . .  2
   2.  Enhanced BGP-Triggered Black holing Technique. . . . . . . . .  3
   3.  Sinkhole Tunnels . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Security Considerations. . . . . . . . . . . . . . . . . . . .  7
   5.  Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . .  7
   6.  Informative References . . . . . . . . . . . . . . . . . . . .  7
   7.  Author's Addresses . . . . . . . . . . . . . . . . . . . . . .  7
   8.  Full Copyright Statement . . . . . . . . . . . . . . . . . . .  8

1. Existing BGP-Triggered Black-holing Techniques

1. 既存のBGPトリガーされたブラックホーリング技術

Current BGP-triggered black-holing techniques rely on altering the BGP next hop address of a network targeted by an attack throughout the iBGP network. A customized iBGP advertisement is generated from a router participating in the destination/attacked AS where the next hop address for the targeted network or host is modified to point to an RFC 1918 [RFC1918] (private internet) address. Most routers on the Internet, especially edge routers, have static routes pointing RFC 1918 addresses to the null interface. Those static routes drive all traffic destined to the network under attack to the null interface.

現在のBGPトリガーされたブラックホーリング技術は、IBGPネットワーク全体の攻撃によって標的とされたネットワークのBGP次のホップアドレスを変更することに依存しています。カスタマイズされたIBGP広告は、ターゲットネットワークまたはホストの次のホップアドレスがRFC 1918 [RFC1918]（プライベートインターネット）アドレスを指すように変更される場所として、宛先に参加するルーターから生成されます。インターネット上のほとんどのルーター、特にエッジルーターには、nullインターフェイスにRFC 1918アドレスを指す静的ルートがあります。これらの静的ルートは、nullインターフェイスに攻撃しているネットワークに運命づけられているすべてのトラフィックを駆動します。

When an iBGP-speaking router inside the destination AS receives the iBGP update, the advertised prefix will be added to the routing table with a next hop of one of the networks listed in RFC 1918. The router will then attempt to resolve the RFC 1918 next-hop in order to qualify the route and derive a forwarding interface. This process will return a valid next hop as the null interface. Assuming the router is properly configured to direct RFC 1918 destined traffic to a null interface, traffic destined to the attacked network gets dropped, making the attacked network unreachable to the attacker and everyone else.

IBGPアップデートを受信する宛先内のIBGPを話すルーターがIBGPアップデートを受信すると、RFC 1918にリストされているネットワークの次のホップで広告のプレフィックスがルーティングテーブルに追加されます。その後、ルーターはRFC 1918を解決しようとします。 - ルートを修飾し、転送インターフェイスを導き出すためにホップします。このプロセスは、nullインターフェイスとして有効な次のホップを返します。ルーターが適切に構成されていると仮定すると、RFC 1918の運命型トラフィックをヌルインターフェイスに導くように構成されているため、攻撃されたネットワークに運命づけられたトラフィックが削除され、攻撃されたネットワークが攻撃者や他のすべての人に到達できなくなります。

While this technique shields the internal infrastructure from the attack, protecting a large number of devices, it has the undesirable side effect of rendering the targeted/attacked network unreachable throughout the entire destination AS. Even if a static route pointing an RFC 1918 address to a null interface is not configured on all routers within the destination AS, the modified next hop makes the traffic un-routable to its legitimate destination.

この手法は、攻撃から内部インフラストラクチャを保護し、多数のデバイスを保護しますが、目的地全体でターゲット/攻撃されたネットワークを到達できないようにするという望ましくない副作用があります。RFC 1918アドレスをnullインターフェイスに向ける静的ルートが宛先内のすべてのルーターで構成されていない場合でも、変更された次のホップにより、トラフィックは合法的な宛先に不可能になります。

Network operators usually use the BGP-triggered black holes for a short period of time. The technique causes traffic drops on all ingress points of the AS for traffic destined to the attacked network. By default, routers dropping traffic into a null interface should send an "ICMP unreachable" message to the source address belonging to the origin/attacking AS.

ネットワークオペレーターは通常、BGPトリガーされたブラックホールを短時間使用します。この手法により、攻撃されたネットワークに向けられたトラフィックのすべての侵入ポイントのトラフィックがドロップされます。デフォルトでは、トラフィックをnullインターフェイスにドロップするルーターは、原点/攻撃ASに属するソースアドレスに「ICMP耐えられない」メッセージを送信するはずです。

Once the procedure reaches this point, one of the source addresses of the attack traffic is hijacked by introducing a device with the same source IP address into the BGP domain of the destination/attacked AS. The device hijacking the source address collects the ICMP unreachable packets. The source addresses of these ICMP unreachable packets reveal which edge routers within the destination/attacked AS the attack is coming from. The network operator may then opt to manually stop the traffic on the routers from which attack traffic is entering.

手順がこのポイントに到達すると、攻撃トラフィックのソースアドレスの1つは、同じソースIPアドレスを持つデバイスを宛先のBGPドメインに導入することにより、ハイジャックされます。ソースアドレスをハイジャックするデバイスは、ICMPの到達不可能なパケットを収集します。これらのICMPの到達不可能なパケットのソースアドレスは、攻撃が発生しているときに宛先内のどのエッジルーター/攻撃されたかを明らかにします。ネットワークオペレーターは、攻撃トラフィックが入っているルーターのトラフィックを手動で停止することを選択できます。

2. Enhanced BGP-Triggered Black-holing Technique

2. 強化されたBGPトリガーされたブラックホーリング技術

This paper describes a technique developed to instruct a selected set of routers to alter the next hop address of a particular prefix by use of the BGP protocol. The next hop can either be a null interface or, as discussed later on in this paper, a sinkhole tunnel interface. This technique does not invoke an access list or rate limiting statement to treat attack traffic, nor does it involve a network wide change of the attacked prefix next hop address. The next hop will only be changed on a selection of routers with the aid of BGP communities within the destination/attacked AS.

このペーパーでは、選択したルーターのセットに、BGPプロトコルを使用して特定のプレフィックスの次のホップアドレスを変更するように指示するために開発された手法について説明します。次のホップは、NULLインターフェイスになるか、このホワイトペーパーで後で説明したように、陥没トンネルインターフェイスのいずれかです。この手法では、攻撃トラフィックを処理するためのアクセスリストやレート制限ステートメントを呼び出すものではなく、攻撃されたプレフィックスの次のホップアドレスのネットワーク全体の変更も含まれません。次のホップは、目的地内/攻撃されたAS内のBGPコミュニティを使用して、ルーターの選択でのみ変更されます。

To prepare the network for this technique, the network operator needs to define a unique community value for each destination AS border router that could potentially drive attack traffic to the victim. For example, a network with a BGP autonomous system number 65001 has two border routers (R1 and R2). Community value 65001:1 is assigned to identify R1, community value 65001:2 is assigned to identify R2, and community value 65001:666 is assigned to identify both R1 and R2.

この手法のためにネットワークを準備するために、ネットワークオペレーターは、攻撃トラフィックを被害者に駆動する可能性のあるボーダールーターとして、各宛先のユニークなコミュニティ価値を定義する必要があります。たとえば、BGP自律システム番号65001を備えたネットワークには、2つの境界ルーター（R1とR2）があります。コミュニティ価値65001：1はR1を識別するために割り当てられ、コミュニティ価値65001：2はR2を識別するために割り当てられ、コミュニティ価値65001：666はR1とR2の両方を識別するために割り当てられます。

After the BGP community assignment, R1 and R2 must be configured with the following:

BGPコミュニティの割り当ての後、R1とR2は以下で構成する必要があります。

1. Static route pointing an RFC 1918 network to a null interface.

1. RFC 1918ネットワークをヌルインターフェイスに向ける静的ルート。

2. AS-Path access list that matches local BGP prefix advertisement.

2. ローカルBGPプレフィックス広告に一致するAs-Pathアクセスリスト。

3. BGP community access list to match the community value assigned by the network operator for the particular router (i.e., 65001:1 for R1).

3. 特定のルーターにネットワークオペレーターによって割り当てられたコミュニティ価値に一致するBGPコミュニティアクセスリスト（つまり、R1の場合は65001：1）。

4. BGP community access list to match the community value assigned by the network operator for all routers (i.e., 65001:666 for R1 and R2)

4. すべてのルーターにネットワークオペレーターによって割り当てられたコミュニティ価値に一致するBGPコミュニティアクセスリスト（つまり、R1およびR2の場合は65001：666）

5. Under the BGP process, an iBGP import route policy should be applied on received iBGP advertisements to do the following logic. (Statements are in a logical AND order)

5. BGPプロセスでは、IBGPインポートルートポリシーを受信したIBGP広告に適用して、次のロジックを実行する必要があります。（ステートメントは論理的で順序付けられています）

a. A policy statement to permit routes that match the following criteria and apply the following changes.

a. 次の基準に一致するルートを許可し、次の変更を適用するためのポリシーステートメント。

i. Match for a community specific to that router (i.e., 65001:1, for R1).

i. そのルーターに固有のコミュニティに一致します（つまり、65001：1、R1の場合）。

ii. Match the AS-Path to locally generated BGP advertisements.

ii。As-Pathをローカルで生成したBGP広告と一致させます。

iii. Set the BGP next hop to an RFC 1918 network.

iii。BGP次のホップをRFC 1918ネットワークに設定します。

iv. Overwrite the BGP community with the well-known community (no-advertise).

IV。BGPコミュニティに有名なコミュニティを上書きします（非advertise）。

b. A policy statement to permit routes that match the following criteria and apply the following changes.

b. 次の基準に一致するルートを許可し、次の変更を適用するためのポリシーステートメント。

i. Match for a community that covers all routers (i.e., 65001:666).

i. すべてのルーターをカバーするコミュニティに一致します（つまり、65001：666）。

ii. Match the AS-Path to locally generated BGP advertisements.

ii。As-Pathをローカルで生成したBGP広告と一致させます。

iii. Set the BGP next hop to an RFC 1918 network.

iii。BGP次のホップをRFC 1918ネットワークに設定します。

iv. Overwrite the BGP community with the well-known community (no-advertise).

IV。BGPコミュニティに有名なコミュニティを上書きします（非advertise）。

After the policies have been configured on R1 and R2, the network operator can, in the case of an attack, advertise the targeted network that could be one or more /32 "host" routes into iBGP of the destination/attacked AS. The advertisement must contain the community value associated with the router(s) where the attack is arriving in addition to the well-known community (no-export). Using BGP communities preserves the original next hop address of the targeted network on all routers where the special route policy configuration is not present. iBGP will then carry the prefix advertisement to all routers in the destination/attacked AS. All routers within the destination AS, except the ones that match the community stamped on the prefix, will be oblivious to the community value and will install the network route with the legitimate next hop address. Routers that match the community will also install the network route into their routing table but will alter the next hop address to an RFC 1918 network and then to a null interface as per the route policies configuration and recursive route lookup. The reason for matching locally announced networks is to make sure that no eBGP peer can misuse this community to drive any network to a null interface. Blackholing the targeted/attacked hosts is recommended, but not the entire address block they belong to so that the blackhole effect has the minimum impact on the attacked network.

ポリシーがR1とR2で構成された後、ネットワークオペレーターは、攻撃の場合、宛先 /攻撃されたIBGPへの1つ以上の /32「ホスト」ルートになる可能性のあるターゲットネットワークを宣伝することができます。広告には、有名なコミュニティ（登録なし）に加えて攻撃が到着しているルーターに関連するコミュニティ価値が含まれている必要があります。BGPコミュニティを使用すると、特別なルートポリシー構成が存在しないすべてのルーターのターゲットネットワークの元の次のホップアドレスを保存します。IBGPは、宛先/攻撃されたASのすべてのルーターにプレフィックス広告を携帯します。プレフィックスに刻印されたコミュニティに一致するものを除く、目的地内のすべてのルーターは、コミュニティの価値を忘れており、正当な次のホップアドレスでネットワークルートをインストールします。コミュニティに一致するルーターは、ネットワークルートをルーティングテーブルにインストールしますが、次のホップアドレスをRFC 1918ネットワークに変更し、ルートポリシーの構成と再帰ルートの検索に従ってnullインターフェイスに変更します。ローカルに発表されたネットワークを一致させる理由は、EBGPピアがこのコミュニティを誤用して、あらゆるネットワークをヌルインターフェイスに駆り立てないことを確認することです。ターゲット/攻撃されたホストをブラックホールすることをお勧めしますが、ブラックホール効果が攻撃されたネットワークに最小の影響を与えるように、それらが属するアドレスブロック全体ではありません。

This technique stops traffic from getting forwarded to the legitimate destination on routers identified as transit routers for attack traffic and that have route map matches for the community value associated with the network advertisement. All other traffic on the network will still get forwarded to the legitimate destination thus minimizing the impact on the targeted network.

この手法により、トラフィックは、攻撃トラフィックのトランジットルーターとして識別されたルーターの正当な目的地に転送されなくなり、ネットワーク広告に関連するコミュニティ価値のルートマップマッチがあります。ネットワーク上の他のすべてのトラフィックは、まだ正当な目的地に転送されるため、ターゲットネットワークへの影響を最小限に抑えます。

3. Sinkhole Tunnels

3. 陥没トンネル

Following the "Enhanced BGP-Triggered Black-holing Technique", it may become a requirement to take a look at the attack traffic for further analysis. This requirement adds to the complexity of the exercise. Usually with broadcast interfaces, network operators install network sniffers on a spanned port of a switch for analysis of traffic. Another method would be to announce a network prefix that covers the attack host address into iBGP, altering the next hop into a sinkhole device that can log traffic for analysis. The latter technique results in taking down the services offered on the targeted/attacked IP addresses. Inter-AS traffic will be sucked into the sinkhole, along with Intra-AS traffic. Packet level analysis involves redirecting traffic away from the destination host to a sniffer or a router. As a result, if the traffic being examined includes legitimate traffic, that legitimate traffic will never make it to the destination host. This will result in denial of service for the legitimate traffic.

「強化されたBGPトリガーされたブラックホーリング技術」に続いて、さらなる分析のために攻撃トラフィックを調べる要件になる可能性があります。この要件は、演習の複雑さを増します。通常、ブロードキャストインターフェイスを使用すると、ネットワークオペレーターは、トラフィックを分析するためにスイッチのスケンマイポートにネットワークスニファーをインストールします。別の方法は、攻撃ホストアドレスをIBGPにカバーするネットワークプレフィックスを発表し、次のホップを分析のためにログを記録できる陥没穴デバイスに変更することです。後者の手法により、ターゲット/攻撃されたIPアドレスで提供されるサービスを削除します。ASトラフィックは、トラフィック内とともに、陥没穴に吸い込まれます。パケットレベル分析には、宛先ホストからスニファーまたはルーターへのトラフィックをリダイレクトすることが含まれます。その結果、検査されているトラフィックに正当なトラフィックが含まれている場合、その合法的なトラフィックは目的地ホストに届かないでしょう。これにより、合法的なトラフィックのサービスが拒否されます。

A better alternative would be to use a sinkhole tunnel. A sinkhole tunnel is implemented at all possible entry points from which attacks can pass into the destination/attacked AS. Using the BGP community technique, traffic destined to the attacked/targeted host could be re-routed to a special path (tunnel) where a sniffer could capture the traffic for analysis. After being analyzed, traffic will exit the tunnel and be routed normally to the destination host. In other words, the traffic will pass through the network to a sniffer without altering the next hop information of the destination network. All routers within the destination/attacked AS iBGP domain will have the proper next hop address. Only the entry point router will have the altered next hop information.

より良い選択肢は、陥没トンネルを使用することです。シンクホールトンネルは、攻撃が目的地に入る/攻撃される可能性のあるすべてのエントリポイントで実装されます。BGPコミュニティのテクニックを使用して、攻撃/ターゲットを絞ったホストに運命づけられているトラフィックは、スニファーが分析のためにトラフィックをキャプチャできる特別なパス（トンネル）に再ルーティングできます。分析された後、トラフィックはトンネルを終了し、通常は宛先ホストにルーティングされます。言い換えれば、トラフィックは、宛先ネットワークの次のホップ情報を変更することなく、ネットワークを通過します。宛先内のすべてのルーター/IBGPドメインとして攻撃されます。適切な次のホップアドレスがあります。エントリポイントルーターのみが、次のホップ情報を変更します。

To detail the procedure, a sinkhole router with an optional sniffer attached to its interface is installed and configured to participate in the IGP and iBGP of the attacked AS. Next, a tunnel is created, using MPLS Traffic Engineering as an example, from all border routers attacks can potentially enter from (Inter-AS traffic) to the sinkhole router. When a host or network is under attack, a customized iBGP advertisement is sent to announce the network address of the attacked host(s) with the proper next hop that insures traffic will reach those hosts or networks. The customized advertisement will also have a community string value that matches the set of border routers the attack is entering from, as described in section 2. The new next hop address configured within the route policy section of all border routers should be the sinkhole IP address. This IP address belongs to the /30 subnet assigned to the tunnel connecting the border router to the sinkhole router.

手順を詳細に説明するために、そのインターフェイスにオプションのスニファーが取り付けられた陥没穴ルーターがインストールされ、攻撃されたASのIGPとIBGPに参加するように構成されています。次に、MPLSトラフィックエンジニアリングを例として使用してトンネルが作成され、すべての境界線ルーター攻撃から（トラフィック間）から陥没穴ルーターに入る可能性があります。ホストまたはネットワークが攻撃を受けている場合、カスタマイズされたIBGP広告が送信され、攻撃されたホストのネットワークアドレスを発表し、トラフィックがそれらのホストまたはネットワークに到達するように適切な次のホップを使用します。カスタマイズされた広告には、セクション2で説明されているように、攻撃が入力するボーダールーターのセットに一致するコミュニティ文字列値もあります。。このIPアドレスは、境界ルーターを陥没穴ルーターに接続するトンネルに割り当てられた /30サブネットに属します。

Routers that do not have a match for the community string will do regular routing. Lack of a community string match on these routers will insure that the special route policy does not change the next hop address. Traffic entering from border routers that do not have a match to the special community will pass through regular router interfaces to the legitimate destination. It might also be required to allow the traffic to reach its destination after being captured. In this case, a default network route is configured to point to any interface attached and configured on the iBGP network. This would also include the same physical interface the tunnel is built on. Since the next hop address is not changed on the sinkhole device, traffic entering this device from the tunnel will be sent back to the network due to the presence of the default route. Routing protocols will then take care of properly routing the traffic to its original destination (attacked network).

コミュニティ文字列に一致していないルーターは、定期的なルーティングを行います。これらのルーターにコミュニティ文字列の一致がないことにより、特別なルートポリシーが次のホップアドレスを変更しないことが保証されます。特別なコミュニティと一致していないボーダールーターから入るトラフィックは、通常のルーターインターフェイスを通過して正当な目的地に移動します。また、キャプチャされた後、トラフィックが目的地に到達できるようにする必要がある場合があります。この場合、IBGPネットワークで添付および構成されたインターフェイスを指すようにデフォルトのネットワークルートが構成されています。これには、トンネルが構築されているのと同じ物理インターフェイスも含まれます。シンクホールデバイスでは次のホップアドレスが変更されないため、デフォルトルートが存在するため、トンネルからこのデバイスを入力するトラフィックがネットワークに送り返されます。ルーティングプロトコルは、トラフィックを元の宛先（攻撃されたネットワーク）に適切にルーティングすることになります。

It becomes apparent that this technique can also be used for purposes other than analyzing attack traffic. Legitimate traffic could also be pulled out of normal routing into a tunnel and then reinserted into the backbone without altering the next hop addressing scheme throughout the iBGP network.

この手法は、攻撃トラフィックを分析する以外の目的にも使用できることが明らかになります。また、正当なトラフィックを通常のルーティングからトンネルに引き出してから、IBGPネットワーク全体の次のホップアドレス指定スキームを変更せずにバックボーンに再挿入することもできます。

MPLS Traffic Engineering with its many features, is a good method of sliding traffic to the sinkhole device. Features like QoS policies can be applied on the attack traffic, thus preventing it from competing on resources with legitimate traffic.

多くの機能を備えたMPLSトラフィックエンジニアリングは、シンクホールデバイスへのトラフィックをスライドさせる良い方法です。QoSポリシーなどの機能は、攻撃トラフィックに適用できるため、合法的なトラフィックでリソースと競合することができなくなります。

To be able to alter the next hop on the border router, a subnet of an RFC 1918 network is statically routed to the tunnel interface. An example of the static route is:

Border Routerの次のホップを変更できるように、RFC 1918ネットワークのサブネットは、トンネルインターフェイスに静的にルーティングされます。静的ルートの例は次のとおりです。

ip route 192.168.0.12 255.255.255.255 Tunnel0

IPルート192.168.0.12 255.255.255.255 Tunnel0

Setting the next hop of the target IP address to 192.168.0.12/32 will force the traffic to go through the tunnel.

ターゲットIPアドレスの次のホップを192.168.0.12/32に設定すると、トラフィックがトンネルを通過するようになります。

Traffic is received at the sinkhole interface via the TE tunnel. Subsequently, three methods could be installed, namely rate-limiting policies, QoS policies, and access lists. These policies could rate limit or drop traffic classified as attack traffic. This process would be completed on the interface of the sinkhole device. Another useful application for a sinkhole router is to pull in traffic via tunnels to an inbound interface and have a default route statement forwarding the traffic out to an Ethernet interface. The Ethernet interface is connected to the iBGP network and guarantees proper delivery of traffic however, it still allows the use of a packet sniffer to further analyze the attack traffic.

トラフィックは、TEトンネルを介して陥没穴インターフェイスで受信されます。その後、3つの方法をインストールできます。つまり、レート制限ポリシー、QOSポリシー、アクセスリストをインストールできます。これらのポリシーは、攻撃トラフィックとして分類されたトラフィックを制限またはドロップする可能性があります。このプロセスは、シンクホールデバイスのインターフェイスで完了します。陥没穴ルーターのもう1つの便利なアプリケーションは、トンネルを介してインバウンドインターフェイスにトラフィックを引き込み、デフォルトのルートステートメントでトラフィックをイーサネットインターフェイスに転送することです。イーサネットインターフェイスはIBGPネットワークに接続されており、トラフィックの適切な配信を保証しますが、パケットスニファーを使用して攻撃トラフィックをさらに分析することができます。

This becomes very useful when it is not feasible to apply an Access list or a rate limiting statement on the BGP border router or last hop router before the attacked host or network because of hardware or software limitations. Hence, instead of upgrading interfaces at the point of entry of attack traffic, the latter could be pulled into the sinkhole and treated on that device. Operational costs can be rendered minimal if the sinkhole router is a powerful device.

これは、ハードウェアまたはソフトウェアの制限のために、攻撃されたホストまたはネットワークの前に、BGPボーダールーターまたはラストホップルーターにアクセスリストまたはレート制限ステートメントを適用できない場合に非常に便利になります。したがって、攻撃トラフィックの入力時点でインターフェイスをアップグレードする代わりに、後者を陥没穴に引き込み、そのデバイスで処理することができます。シンクホールルーターが強力なデバイスである場合、運用コストを最小限に抑えることができます。

4. Security Considerations

4. セキュリティに関する考慮事項

It is very important to practice tight control over eBGP peering points before implementing the techniques described in this paper. eBGP customers might be able to blackhole a particular subnet using the Blackhole communities. To eliminate the risk, the match for locally generated BGP advertisements in the special route policy should not be neglected.

このペーパーで説明されている手法を実装する前に、EBGPピアリングポイントを厳密に制御することを実践することが非常に重要です。EBGPのお客様は、ブラックホールコミュニティを使用して特定のサブネットをブラックホールできる場合があります。リスクを排除するために、特別なルートポリシーでローカルに生成されたBGP広告の一致は無視すべきではありません。

5. Acknowledgments

5. 謝辞

The author of this document would like to acknowledge the developers of the remotely triggered black-holing technique and the developers of the backscatter technique for collecting backscatter traffic. The author would also like to thank all members of the IP Engineering department for their help in verifying the functionality of this technique.

このドキュメントの著者は、リモートトリガーされたブラックホーリング技術の開発者と、後方散乱トラフィックを収集するための後方散乱技術の開発者を認めたいと考えています。著者はまた、この手法の機能を検証する際にIPエンジニアリング部門のすべてのメンバーに感謝したいと思います。

6. Informative References

6. 参考引用

[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月。

7. Author's Addresses

7. 著者のアドレス

Doughan Turk Bell Canada 100 Wynford Drive

   EMail: doughan.turk@bell.ca

8. Full Copyright Statement

8. 完全な著作権声明

著作権（c）The Internet Society（2004）。

This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org, and except as set forth therein, the authors retain all their rights.

この文書は、BCP 78およびwww.rfc-editor.orgに含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持します。

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントとここに含まれる情報は、「現状のまま」と貢献者、彼が代表する組織（もしあれば）が後援する組織、インターネット社会、インターネットエンジニアリングタスクフォースがすべての保証を拒否し、表明または、ここでの情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。

Intellectual Property

知的財産

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the ISOC's procedures with respect to rights in ISOC Documents can be found in BCP 78 and BCP 79.

IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。ISOCドキュメントの権利に関するISOCの手順に関する情報は、BCP 78およびBCP 79に記載されています。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。

Acknowledgement

謝辞

Funding for the RFC Editor function is currently provided by the Internet Society.

RFCエディター機能の資金は現在、インターネット協会によって提供されています。