Network Working Group D. Turk
Request for Comments: 3882 Bell Canada
Category: Informational September 2004
Configuring BGP to Block Denial-of-Service Attacks
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) The Internet Society (2004).
著作権（C）インターネット協会（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
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]（プライベートインターネット）アドレスを指すように変更された場合など、攻撃先/参加ルータから生成されます。インターネット上のほとんどのルータ、特にエッジルータは、ヌルインターフェイスにRFC 1918のアドレスを指し示すスタティックルートを持っています。これらのスタティックルートは、ヌルインターフェイスへの攻撃を受けたネットワーク宛てのすべてのトラフィックを駆動します。
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の更新を受信する場合、アドバタイズプレフィックスはRFC 1918に記載されているルータをネットワークのいずれかの次のホップでルーティングテーブルに追加され、その後RFC 1918次の解決しようとしルートを修飾し、転送インタフェースを導出するために-hop。このプロセスは、ヌルインターフェイスとして有効なネクストホップを返します。ルータが適切に直接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.
この技術は、攻撃から内部インフラストラクチャを保護しながら、多数のデバイスを保護し、それが目標をレンダリングするのは望ましくない副作用を持っている/ AS全体先を通じて到達不能のネットワークを攻撃しました。ヌルインターフェイスにRFC 1918アドレスを指すスタティックルートを宛先AS内のすべてのルータに設定されていない場合でも、修飾次のホップは、その正当な宛先への非ルーティング可能なトラフィックになります。
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トリガブラックホールを使用します。この技術は、トラフィックが攻撃ネットワーク宛てのトラフィックのためのASのすべての入力ポイントに落ちる原因となります。デフォルトでは、ヌルインターフェイスにトラフィックをドロップするルータは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.
手順は、この点に到達すると、攻撃トラフィックの送信元アドレスのいずれかが先のBGPドメインに同じ送信元IPアドレスを持つデバイスを導入することにより、ハイジャックされた/ ASが攻撃しました。送信元アドレスをハイジャックデバイスは、ICMP到達不能パケットを収集します。これらのICMP到達不能パケットの送信元アドレスは、攻撃として攻撃宛先内のエッジルータが/から来ている明らかにする。ネットワークオペレータは、手動で攻撃トラフィックが入っているから、ルータ上のトラフィックを停止することを選ぶことがあります。
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プロトコルを使用することによって、特定のプレフィックスの次ホップアドレスを変更するためにルータの選択されたセットを指示するために開発された技術が記載されています。次のホップは、いずれかのこの論文の後半で説明したようにヌルインターフェイスまたは、シンクホールトンネルインターフェースとすることができます。この手法は、攻撃トラフィックを処理するために、アクセスリストやレート制限声明を起動しません。また、攻撃プレフィックスネクストホップアドレスのネットワーク全体の変更を伴いません。ネクストホップとしてのみ攻撃先/内の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.
この技術のためにネットワークを準備するために、ネットワークオペレータは、潜在的被害者への攻撃トラフィックを運転できる境界ルータAS宛先ごとに独自のコミュニティ値を定義する必要があります。例えば、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は、次のように設定する必要があります。
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).
（：R 1、すなわち、65001）3. BGPコミュニティアクセスリストは、特定のルータのネットワークオペレータによって割り当てられたコミュニティ値と一致します。
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コミュニティアクセスリスト（すなわち、65001：R1とR2の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広告に適用されるべきです。 （ステートメントは、論理AND順序です）
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).
私。そのルータに特定のコミュニティのためのマッチ（すなわち、65001：1、R1用）。
ii. Match the AS-Path to locally generated BGP advertisements.
II。ローカルで生成されたBGPアドバタイズメントにASパスに一致します。
iii. Set the BGP next hop to an RFC 1918 network.
III。 RFC 1918ネットワークにBGPネクストホップを設定します。
iv. Overwrite the BGP community with the well-known community (no-advertise).
IV。既知のコミュニティ（無宣伝）でBGPコミュニティを上書きします。
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).
私。すべてのルータをカバーし、コミュニティのためのマッチ（すなわち、65001：666）。
ii. Match the AS-Path to locally generated BGP advertisements.
II。ローカルで生成されたBGPアドバタイズメントにASパスに一致します。
iii. Set the BGP next hop to an RFC 1918 network.
III。 RFC 1918ネットワークにBGPネクストホップを設定します。
iv. Overwrite the BGP community with the well-known community (no-advertise).
IV。既知のコミュニティ（無宣伝）でBGPコミュニティを上書きします。
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上で設定された後、ネットワークオペレータは、攻撃の場合には、AS攻撃先/ののiBGPに一つ以上/ 32「ホスト」のルートかもしれない目標ネットワークを宣伝することができます。広告は、攻撃が既知のコミュニティ（無エクスポート）に加えて、到着しているルータ（複数可）に関連付けられたコミュニティ値が含まれている必要があります。 BGPコミュニティを使用すると、特別なルートポリシーの設定が存在しないすべてのルータ上の目標とネットワークの本来のネクストホップアドレスを保持します。 iBGPのは、その後、先にすべてのルータにプレフィックス広告を運ぶ/ ASが攻撃しました。プレフィックスに刻印コミュニティと一致するものを除いて、宛先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.
この手法は、攻撃トラフィックのための中継ルータとして特定のルータ上の合法的な宛先に転送取得からのトラフィックを停止し、その持っているルートマップは、ネットワーク広告に関連付けられたコミュニティ値のために一致しました。ネットワーク上の他のすべてのトラフィックはまだので、対象のネットワークへの影響を最小限に抑え、正当な宛先に転送されます。
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間のトラフィックはイントラ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に参加するためにインストールされ、構成されています。次に、トンネルは、潜在的シンクホールルータに（AS間トラフィック）から入力することができ、すべての境界ルータの攻撃から、一例として、MPLSトラフィックエンジニアリングを使用して、作成されます。ホストまたはネットワークが攻撃を受けている場合は、カスタマイズされたのiBGP広告はトラフィックがそれらのホストまたはネットワークに到達します保証適切なネクストホップで攻撃されたホスト（複数可）のネットワークアドレスを発表するために送信されます。カスタマイズされた広告も、国境のセットは、すべての境界ルータのルートポリシーセクション内に設定された新しいネクストホップアドレスが陥没IPアドレスでなければなりませ部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:
ボーダールータ上の次のホップを変更することができるように、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.
192.168.0.12/32にターゲットIPアドレスのネクストホップを設定すると、トンネルを通過するトラフィックを強制します。
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ポリシー、およびアクセスリストをインストールすることができます。これらの政策は限界にレートまたは攻撃トラフィックとして分類されたトラフィックをドロップすることができます。このプロセスは、シンクホールデバイスのインターフェイス上で完成されるだろう。シンクホールルータのための別の有用な用途は、着信インターフェイスにトンネルを経由してトラフィックに引っ張るとイーサネットインターフェイスに出入りするトラフィックを転送するデフォルトルート文を持つことです。イーサネットインターフェイスはの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境界ルータまたは最後のホップルータ上で声明をレート制限を適用することは不可能であるとき、これは非常に便利になります。したがって、代わりに攻撃トラフィックのエントリポイントでインターフェイスをアップグレードする、後者は、陥没穴に引き込むことができ、そのデバイス上で処理しました。シンクホールルータが強力なデバイスであれば、運用コストを最小限にすることができます。
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広告の一致は無視すべきではありません。
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エンジニアリング部門のすべてのメンバーに感謝したいと思います。
[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月。
Doughan Turk Bell Canada 100 Wynford Drive
Doughanトルコベル・カナダ100 Wynfordドライブ
EMail: doughan.turk@bell.ca
メールアドレス：doughan.turk@bell.ca
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とHEが表すCONTRIBUTOR、ORGANIZATION HE / S OR（もしあれば）後援されており、インターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示、「そのまま」で提供されていますOR情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証を含むがこれらに限定されないで、黙示。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。