RFC3882 日本語訳

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

コメントを求めるワーキンググループD.トルコ人要求をネットワークでつないでください: 3882年のベルカナダCategory: 情報の2004年9月

           Configuring BGP to Block Denial-of-Service Attacks

サービス不能攻撃を妨げるためにBGPを構成します。

Status of this Memo

この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).

Copyright(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

1. 存在はBGP Techniques. . . . . . . . 2 2を掘るBlackの引き金となりました。 Techniqueを掘るBGPによって引き起こされたBlackを高めました。 . . . . . . . . 3 3. 下水落し口は.5 4にトンネルを堀ります。 セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 7 5. 承認。 . . . . . . . . . . . . . . . . . . . . . . . 7 6. 有益な参照. . . . . . . . . . . . . . . . . . . . 7 7。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 7 8。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 8

Turk                         Informational                      [Page 1]

RFC 3882          Configuring BGP to Block DoS Attacks    September 2004

2004年9月にDoS攻撃を妨げるためにBGPを構成するトルコ人の情報[1ページ]のRFC3882

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広告は狙っているネットワークかホストのための次のホップアドレスがRFC1918[RFC1918](個人的なインターネット)アドレスを示すように変更される目的地/攻撃されたASに参加するルータから作られます。 インターネットのほとんどのルータ(特に縁のルータ)で、スタティックルートはRFC1918アドレスをヌルインタフェースに向けます。 それらのスタティックルートはネットワークに攻撃で運命づけられたすべてのトラフィックをヌルインタフェースに追い立てます。

   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.

目的地ASの中のiBGP-話しルータがiBGPアップデートを受けるとき、ネットワークの1つの次のホップがRFC1918に記載されている状態で、広告を出している接頭語は経路指定テーブルに加えられるでしょう。 そして、ルータは、ルートに資格を与えて、推進インタフェースを引き出すために次のホップでRFC1918を決議するのを試みるでしょう。 このプロセスはヌルインタフェースとして次の有効なホップを返すでしょう。 ルータがRFC1918を指示するために適切に構成されると仮定するのがヌルインタフェースへのトラフィックを運命づけて、攻撃されたネットワークに運命づけられたトラフィックは下げられます、攻撃されたネットワークを攻撃者と他の人皆にとって手が届かなくして。

   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中に狙っているか攻撃されたネットワークを手が届かなく表す望ましくない副作用を持っています。 RFC1918アドレスをヌルインタフェースに向けるスタティックルートが目的地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のすべてのイングレス先で下げるテクニック原因は攻撃されたネットワークに運命づけられました。 デフォルトで、ヌルインタフェースにトラフィックを下げるルータは「ICMP手の届かない」メッセージを発生源/攻撃ASに属すソースアドレスに送るべきです。

   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アドレスで目的地/攻撃されたASのBGPドメインにデバイスを取り入れることによって、ハイジャックされます。 ソースアドレスをハイジャックするデバイスはICMPの手の届かないパケットを集めます。 これらのICMPの手の届かないパケットのソースアドレスは、攻撃が目的地/攻撃されたASの中のどの縁のルータから起こっているかを明らかにします。 そして、ネットワーク・オペレータは、攻撃トラフィックに入っているルータで手動で車の流れを止めるために選ぶかもしれません。

Turk                         Informational                      [Page 2]

RFC 3882          Configuring BGP to Block DoS Attacks    September 2004

2004年9月にDoS攻撃を妨げるためにBGPを構成するトルコ人の情報[2ページ]のRFC3882

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プロトコルの使用で特定の接頭語の次のホップアドレスを変更するよう選択されたセットのルータに命令するために見いだされた技術を説明します。 次のホップは、ヌルインタフェースか後でこの紙で議論するとき、下水落し口トンネルのインタフェースのどちらかであるかもしれません。 このテクニックは声明を御馳走の攻撃トラフィックに制限するアクセスリストかレートを呼び出しません、そして、それは次のホップが扱う攻撃された接頭語のネットワークの広い変化にかかわりません。 BGP共同体の援助に従って、目的地/攻撃されたASの中でいくつかのルータで次のホップを変えるだけでしょう。

   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自律システムNo.65001があるネットワークには、2つの境界ルータ(R1とR2)があります。 R2、および共同体値を特定してください。共同体値、65001:1 R1を特定するために割り当てられる、共同体値、65001:2、割り当てられる、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. RFC1918がヌルインタフェースにネットワークでつなぐスタティックルートの指すこと。

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

2. 地方のBGP接頭語広告に合っているAS-経路アクセスリスト。

   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共同体が特定のルータのためにネットワーク・オペレータによって割り当てられた共同体値を合わせるためにリストにアクセスする、(65001:1、R1)

   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).

i。 そのルータ(すなわち、65001: R1のための1)に特定の共同体に合ってください。

         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。 次のBGPがRFC1918ネットワークに飛び越すセット。

Turk                         Informational                      [Page 3]

RFC 3882          Configuring BGP to Block DoS Attacks    September 2004

2004年9月にDoS攻撃を妨げるためにBGPを構成するトルコ人の情報[3ページ]のRFC3882

         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).

i。 すべてのルータ(すなわち、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。 次のBGPがRFC1918ネットワークに飛び越すセット。

         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で構成された後に、攻撃の場合では、ネットワーク・オペレータは1以上/32の「ホスト」ルートであるかもしれない狙っているネットワークの目的地/攻撃されたASのiBGPに広告を出すことができます。 広告は攻撃がよく知られる共同体(輸出がない)に加えて到着しているルータに関連している共同体値を含まなければなりません。 BGP共同体を使用すると、すべてのルータの特別なルート方針構成が存在していない狙っているネットワークの次のオリジナルのホップアドレスは保存されます。次に、iBGPは目的地/攻撃されたASのすべてのルータまで接頭語広告を運ぶでしょう。 接頭語で押し込まれた共同体に合っているもの以外の目的地ASの中のすべてのルータが、共同体値に気づかなく、次の正統のホップアドレスでネットワークルートをインストールするでしょう。 共同体に合っているルータが、また、ネットワークルートをそれらの経路指定テーブルにインストールしますが、ルート方針構成と再帰的なルートルックアップに従ってRFC1918ネットワークと、そして、そして、ヌルインタフェースに次のホップアドレスを変更するでしょう。 合っている局所的に発表されたネットワークの理由はどんなeBGP同輩もヌルインタフェースまでどんなネットワークも運転するためにこの共同体を誤用できないのを確実にすることです。 blackhole効果は、狙っているか攻撃されたホストをBlackholingするのがお勧めであるのではなく彼らが属す全体のあて先ブロックがどんなお勧めであるのでも、攻撃されたネットワークに最小の影響力を持っています。

   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.

このテクニックは、トラフィックがネットワーク広告に関連している共同体値のために攻撃トラフィックとそれのためのトランジットルータには路線図マッチがあるので特定されたルータの正統の目的地に送られるのを止めます。 それでも、狙っているネットワークで影響を最小にしながら、このようにしてネットワークの他のすべてのトラフィックを正統の目的地に送るでしょう。

Turk                         Informational                      [Page 4]

RFC 3882          Configuring BGP to Block DoS Attacks    September 2004

2004年9月にDoS攻撃を妨げるためにBGPを構成するトルコ人の情報[4ページ]のRFC3882

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トラフィックはIntra-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.

より良い代替手段は下水落し口トンネルを使用するだろうことです。 下水落し口トンネルは攻撃が目的地/攻撃されたASに入ることができる全く可能なエントリー・ポイントであると実装されます。 BGP共同体のテクニックを使用して、パケット盗聴プログラムが分析のためにトラフィックを得ることができた特別な経路(トンネル)に攻撃されたか狙っているホストに運命づけられたトラフィックは別ルートで送ることができました。 分析された後に、トラフィックは、あて先ホストにトンネルを出て、通常、発送されるでしょう。 言い換えれば、送信先ネットワークの次のホップ情報を変更しないで、トラフィックはネットワークをパケット盗聴プログラムに通り抜けるでしょう。 目的地/攻撃されたAS 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 Traffic Engineeringを使用して、攻撃が(相互ASトラフィック)から下水落し口ルータまで潜在的に入ることができるすべての境界ルータから。 ホストかネットワークは攻撃されているとき、トラフィックがそれらのホストかネットワークに届くのを保障する次の適切なホップで攻撃されたホストのネットワーク・アドレスを発表するためにカスタマイズされたiBGP広告を送ります。 また、カスタマイズされた広告には、攻撃が入っている境界ルータのセットに合っている共同体ストリング価値があるでしょう、セクション2で説明されるように。 すべての境界ルータのルート方針部分の中で構成された次の新しいホップアドレスは下水落し口IPアドレスであるべきです。 このIPアドレスは下水落し口ルータに境界ルータを関連づけながらトンネルに割り当てられた/30サブネットに属します。

Turk                         Informational                      [Page 5]

RFC 3882          Configuring BGP to Block DoS Attacks    September 2004

2004年9月にDoS攻撃を妨げるためにBGPを構成するトルコ人の情報[5ページ]のRFC3882

   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 Traffic Engineeringは下水落し口デバイスにトラフィックを滑らせる良いメソッドです。 攻撃トラフィックで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:

境界ルータで次のホップを変更できるように、RFC1918ネットワークのサブネットは静的にトンネルのインタフェースに発送されます。 スタティックルートに関する例は以下の通りです。

      ip route 192.168.0.12 255.255.255.255 Tunnel0

ipルート192.168.0.12 255.255.255.255Tunnel0

   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の次のホップを設定して、トラフィックが.12/32によってトンネルを通ってやむを得ず行く.0を192.168に扱ってください。

   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ネットワークに関連づけられて、しかしながら、パケットスニッファーの使用がそれでまださらに攻撃トラフィックを分析できるのをトラフィックの適切な配送に保証します。

Turk                         Informational                      [Page 6]

RFC 3882          Configuring BGP to Block DoS Attacks    September 2004

2004年9月にDoS攻撃を妨げるためにBGPを構成するトルコ人の情報[6ページ]のRFC3882

   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.

ハードウェアかソフトウェア制限のために攻撃されたホストかネットワークの前でAccessリストか声明を制限するレートを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顧客がblackholeにできるかもしれない前に厳格な管理を練習するために、eBGPのじっと見る上では、Blackhole共同体を使用する特定のサブネットが指しているのは、非常に重要です。 危険を排除するために、特別なルート方針における局所的に生成している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 Engineering部のすべてのメンバーに感謝したがっています。

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.、マスコウィッツ、B.、Karrenberg、D.、deグルート、G.とE.リア、「個人的なインターネットのためのアドレス配分」BCP5、RFC1918(1996年2月)。

7.  Author's Addresses

7. 作者のアドレス

   Doughan Turk
   Bell Canada
   100 Wynford Drive

Doughanトルコ人ベル・カナダ100のWynfordドライブ

   EMail: doughan.turk@bell.ca

メール: doughan.turk@bell.ca

Turk                         Informational                      [Page 7]

RFC 3882          Configuring BGP to Block DoS Attacks    September 2004

2004年9月にDoS攻撃を妨げるためにBGPを構成するトルコ人の情報[7ページ]のRFC3882

8.  Full Copyright Statement

8. 完全な著作権宣言文

   Copyright (C) The Internet Society (2004).

Copyright(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.

このドキュメントはBCP78と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.

彼が代理をするか、または(もしあれば)後援される/S、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄して、急行か暗示していて、含んでいる他はあらゆる保証です。「そのままで」という基礎と貢献者の上でこのドキュメントとここに含まれた情報を提供して、組織が彼である、情報の使用はここにどんな権利か市場性のどんな黙示的な保証か特定目的への適合性も侵害しないでしょう。

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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でISOC Documentsの権利に関するISOCの手順に関する情報を見つけることができます。

   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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   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機能のための基金は現在、インターネット協会によって提供されます。

Turk                         Informational                      [Page 8]

トルコ人情報です。[8ページ]