ネットワーク WG
Request for Comments: 3704
更新: 2827
BCP: 84
分類: ベストカレントプラクティス

F. Baker
Cisco Systems
 P. Savola
CSC/FUNET
2004年 3月

English

(準備中)

マルチホームされたネットワークのためのイングレスフィルタリング
(Ingress Filtering for Multihomed Networks)

このメモの位置づけ

この文書は、インターネットの「現時点における最善の実践(ベストカレントプラクティス)」を示すものであり、改善するために議論と示唆を求めるものです。このメモの配布に制限はありません。

 

著作権表記

Copyright (C) The Internet Society (2004).  All Rights Reserved.

 

要旨

BCP 38, RFC 2827 は、 偽装されたアドレスでネットワークにアクセスするトラフィックを拒否することによって、分散型サービス妨害攻撃の影響を制限し、「トラフィックについて、その正しい発信元ネットワークを追跡可能であること」を確保し易くすることを意図しています。インターネットをこのような攻撃から防護することの副次的効果として、この解決策を実装しているネットワークは、また、この攻撃や、ネットワーク機器に対する偽装されたマネジメントアクセスのような他の攻撃からも自身を護ります。これが問題を生む可能性があるときがあります。(例: マルチホーミングによる場合) 本書は、現在のイングレスフィルタリングの運用的メカニズムを記述し、イングレスフィルタリングに関する一般的な論点を吟味し、特に、マルチホーミングの影響について探求します。このメモは、RFC 2827 を更新します。

 

目次

1.  はじめに

2.  イングレスフィルタリングを実装する多様な方法

2.1 イングレスアクセスリスト
2.2 Strict RPF
2.3 Feasible Path RPF
2.4 Loose RPF
2.5 デフォルト経路を無視する Loose RPF

3.  イングレスフィルタリングの適用可能性を明確にする

3.1 複数レベルにおけるイングレスフィルタリング
3.2 あなたのインフラストラクチャを防護するためのイングレスフィルタリング
3.3 ピアになっているリンクにおけるイングレスフィルタリング

4.  マルチホームされたイングレスフィルタリングについての解決策

4.1 適切である限り Loose RPF を使う
4.2 各 ISP のイングレスフィルタが完璧であることを確保する
4.3 トラフィックをプロバイダー Prefix を使ってそのプロバイダーのみに宛てて送る

5.  セキュリティについての考慮事項

6.  結論と将来の作業

7.  謝辞

8.  参考文献

8.1.  規範的参考文献
8.2.  参考情報

9.  著者のアドレス

10. 著作権表記全文

 

1.  はじめに English

BCP 38, RFC 2827 は、 偽装されたアドレスでネットワークにアクセスするトラフィックを拒否することによって、分散型サービス妨害攻撃の影響を制限し、「トラフィックについて、その正しい発信元ネットワークを追跡可能であること」を確保し易くすることを意図しています。インターネットをこのような攻撃から防護することの副次的効果として、この解決策を実装しているネットワークは、また、この攻撃や、ネットワーク機器 に対する偽装されたマネジメントアクセスのような他の攻撃からも自身を護ります。 これが問題を生む可能性があるときがあります。(例: マルチホーミングによる場合) 本書は、現在のイングレスフィルタリングの運用的メカニズムを記述し、イングレスフィルタリングに関する一般的な論点を吟味し、特に、マルチホーミングの影響について探求します。このメモは、RFC 2827 を更新します。

RFC 2827 は、「ISP が、顧客ネットワークによって正規に使われていない発信元アドレスから彼らのネットワークに流入してくるトラフィックを棄却することによって、その顧客のトラフィックを警備すること」を推奨します。そのフィルタリングは、その発信元アドレスが、いわゆる「Martian アドレス(0.0.0.0/8, 10.0.0.0/8, 127.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 224.0.0.0/4, 240.0.0.0/4 中のあらゆるアドレスを含む予約されたアドレス [3])」であるトラフィックを含みますが、これに限られません。

イングレスフィルタリング手順の背後にある推論は、「分散型サービス妨害攻撃は、頻繁に、フィールド中に乱数をおいて他のシステムの発信元アドレスを偽装すること」です。ある種の攻撃においては、この乱数は、標的ネットワーク中を当てているとともに、ひとつか複数のマシンを同時に攻撃し、それらのマシンが他のマシンを ICMP メッセージや他のトラフィックで攻撃するようにします。この場合、攻撃されたサイトは、「それらの prefix が、インターネットから受信したパケットにおいて 発信元アドレス中に使われていないこと」を検証することによって正しいフィルタリングによって自身を護ることができます。他の攻撃において、その発信元アドレスは、32 bit の乱数として書かれ、攻撃元が追跡困難になります。エッジネットワークを出て、ある ISP に入るトラフィックが正規に送信されているトラフィックに制限できる場合、攻撃は、なんとか緩和できます。:
乱雑な、あるいは、偽りの発信元アドレスをもつトラフィックは、甚大な被害をもたらす前に抑制することができ、攻撃は、いつでも、少なくとも攻撃者の発信元ネットワークまで辿ることができます。

本書は、下記のような ISP やエッジネットワークの運用者を対象としています。
1) イングレスフィルタリング手法一般について、もっと学びたい者
2) 既にある程度、イングレスフィルタリングを使っているが、その利用を拡大しようとしており、マルチホームされた/非対称なシナリオにおいて、イングレスフィルタリングの落とし穴を避けようとしている者

2 章において、イングレスフィルタリングを実装するための、いくつかの異なる方法 が、一般的な文脈において、記述され、吟味されます。 3章において、イングレスフィルタリング手法の適用可能性について、いくつかの明確化が行われます。4章において、イングレスフィルタリングが、マルチホーミングの観点から詳細に分析されます。 5章において、結論と、潜在的な将来の作業項目が識別されます。

 

2.  イングレスフィルタリングを実装する多様な方法 English

この章では、このメモ執筆時点におけるイングレスフィルタリングを実装するために使われる 多様な運用的テクニックへの導入の役割を果たします。そのメカニズムが、一般的な用語で記述、分析されており、マルチホーミング固有の論点が4章に記述されています。

RFC 2827 を実装するには、少なくとも、多様な影響をともなう 5 つの方法があります。これらは、下記の事項を含みます。(その名前は、比較的卑近な用法で記しています。):

他のメカニズムも、可能であり、実際、さらなる調査、仕様化、実装、かつ/または、配備から得るものがある可能性がある数多くのテクニックがあります。( 6 章 参照。)しかし、これらは、範囲外です。

2.1.  イングレスアクセスリスト English

イングレスアクセスリストは、ネットワークインターフェイスにおいて受信した、すべてのメッセージの発信元アドレスを受容可能な prefix のリストに照らしてチェックし、そのフィルタに適合しないあらゆるパケットを棄却するフィルタです。これは、(決して)イングレスフィルタを実装する唯一の方法ではないのでが、これは、RFC 2827 [1] によって提案されたものであり、ある意味で、最も決定論的なものです。

しかし、イングレスアクセスリストは、典型的には、マニュアルで維持管理されています。例えば、prefix のセットが変化する場合 (例: マルチホーミングの結果として)、ISP におけるリストを更新することを忘れることは、それらがそのイングレスフィルタを通過しない場合、そのパケットを捨てることをもたらす可能性があります。

当然、この問題は、イングレスアクセスリストに限られません。(これは、そのイングレスフィルタが不完全なとき、イングレスフィルタリングに内在します。)しかし、通常、イングレスアクセスリストは、他のメカニズムよりも維持管理が困難であり、陳腐化したリストをもつことは、正規のアクセスを妨げる可能性があります。

2.2.  「Strict RPF」 English

「Strict RPF(Strict Reverse Path Forwarding)」は、イングレスフィルタを実装する単純な方法です。これは、概念的には、 「アクセスリストが動的であること」以外は、イングレスフィルタリングのためにアクセスリストを使うことと同じです。これは、重複した設定を避けるためにも使える可能性があります。(例: 固定的な経路、もしくは、BGP prefix リストフィルタと、インターフェイス アクセスリストの両方の維持管理。)この手順は、「その発信元アドレスは、FIB(Forwarding Information Base)中をルックアップされ、そのパケットが、そのトラフィックを、そのパケットの発信元宛てに転送するのに使われるインターフェイスで受信された場合、そのチェックを合格する」というものです。

「Strict RPF」は、あらゆる種類のエッジネットワークの前において、非常に合理的なアプローチです。特に、そのネットワーク エッジが BGP を使って、複数の prefix を公告しているとき、これは、イングレスアクセスリストよりはるかに優れています。これは、シンプルで、安価で、速く、動的なフィルタを構築します。

しかし、「Strict RPF」は、それ自体、いくつかの問題をもっています。まず、そのテストは、ルーティングが対称的である場合にのみ適用可能です。(ここで、一方向の IP データグラムと、多方向のレスポンスは、必ず同じパスを通ります。)これは、彼らの ISP に対するエッジネットワーク インターフェイスにおいて、普及していますが、通常、非対称的な「ホットポテト(hot potato)」ルーティングを使う ISP 間においては、まったく普及していません。また、BGP が prefix を運んでおり、いくつかの正規の prefix が公告されていない場合、あるいは、その ISP のポリシーによって許可されていない場合、その影響は、不完全なアクセスリストを使っているイングレスフィルタリングと同様です。: 正規の トラフィックには、そのフィルタリングルーター の FIB(Forwarding Information Base)中の経路の欠如によって、フィルタされてしまうものがあります。

(準備中)

特に、BGP について、非対称な、あるいは、マルチホームされたトラフィックの場合に「strict RPF」を、よりうまく動作させる(ただし、他のルーティングプロトコルにも何とか適用可能な)運用的テクニックがあります。その ISP は、
which is not propagated outside of the ルーター,
either a ベンダー固有の「weight」
or a プロトコル distance to prefer the directly received routes
より良い計量を割り当てます。BGP と十分なマシンがあれば、性能を設定することは、BGP コミュニティ [2] を使って、自動化される可能性さえあります。そのようにして、その経路は、主要な接続のみが使われるようなシナリオにおいても、常に、その FIB において最善のものとなります。そして、典型的には、そのインターフェイスを通るパケットはありません。この手法は、「プライマリとセカンダリのエッジルーターの間に strict RPF フィルタリングが無いこと」を想定します。 特に、異なる ISP に対するマルチホーミングに適用されたとき、 この想定は、失敗する可能性があります。

2.3.  「Feasible Path RPF」 English

(準備中)

「Feasible RPF(Feasible Path Reverse Path Forwarding)」は、「Strict RPF」の拡張です。その発信元アドレスは、FIB(もしくは、同等の RPF 固有テーブル)中をルックアップされますが、
instead of just inserting one best route there,
the alternative paths (if any) have been added as well,
and are valid for 考慮。
そのリストは、ルーティングプロトコル固有の手法
(例: すべての、もしくは、N (ここで N は、すべてよりも少ない)の feasible BGP パスを RIB(Routing Information Base)に含めることによる手法。)を使って公知のものとされます。しばしば、この手法は、「Strict RPF」実装の一部として実装されてきました。

当該ネットワークのエッジにおける非対称ルーティング、および/または、マルチホーミングの場合、このアプローチは、「Strict RPF」の最大の問題に、比較的容易に対応する方法を提供します。

「Feasible RPF」が運用される状況を理解することは、極めて重要です。そのメカニズムは、構成する経路の公告
(すなわち、
同一の prefix(es),
through all the paths propagating to all the ルーターs performing 「Feasible RPF」チェックing)
に依存します。例えば、これは、
may not hold 例: in the case where a secondary ISP does not propagate the BGP の公告 to the 主要な ISP 例: route-maps or 他のルーティングポリシーs not being up-to-date
に起因します。その失敗モードは、典型的には、上記のように、「運用的に拡張された Strict RPF」と同様です。

一般的なガイドラインとして、公告がフィルタされる場合、そのパケットも、フィルタされます。

結果として、正しく定義された「Feasible RPF」は、一定の種類の非対称ルーティングのシナリオにおいて、非常に強力なツールですが、その運用的役割と適用可能性をよく理解することが重要です。

2.4.  「Loose RPF」 English

「Loose RPF(Loose Reverse Path Forwarding)」は、アルゴリズム的には、「Strict RPF」と同様ですが、「経路の存在のみを(適用可能な場合、たとえデフォルト経路も)チェックし、その経路が指し示す場所はチェックしないこと」において異なります。実際に、これは、「経路の存在チェック」と見なすことができます。(Loose RPF は、ある意味で誤称です。なぜなら、最初に、「逆(reverse)パス」チェックが無いからです。)

「Loose RPF」の懐疑的な恩恵は、非対称ルーティングの状況にあります。: パケットは、「Martian アドレス」宛て、あるいは、正しく経路制御されていないアドレス宛てのように、経路が全く無い場合、棄却されますが、経路が存在する場合、棄却されません。

(準備中)

しかし、「Loose RPF」には問題があります。これは、方向を規定するので、これは、エッジネットワークのトラフィックを
to トラフィック legitimately sourced from that ネットワーク
に制限する能力を失う大部分の場合において,
rendering the メカニズム useless as an イングレスフィルタリングのメカニズム。

また、多くの ISP は、
such as collecting 不正なトラフィック at いわゆる「ハニーポット」システムs or discarding any トラフィック they do not have a 「本当の」経路 to
様々な目的のためにデフォルト経路を使っており、また、より小さな ISP も、より大きなプロバイダーから
transit capabilities を買って、デフォルトの経路を使う可能性があります。少なくとも、「Loose RPF」のいくつかの実装は、デフォルトの経路が指し示すところをチェックします。その経路が「Loose RPF」を実行可能にしているインターフェイスを指す場合、あらゆるパケットがそのインターフェイスから許容されます。それが、どこも指さないか、あるいは、どこか他のインターフェイスを指す場合、偽りの発信元アドレスをもつパケットは、たとえデフォルト経路があったとしても、その Loose RPF インターフェイスに記述されます。そのような細かいチェック機能が実装されていない場合、デフォルト経路の存在は、「Loose RPF」の効果を完全に帳消しにします。

「Loose RPF」がうまく適合する可能性があるひとつの事例には、
「an ISP フィルタリングパケットs from its アップストリームプロバイダーs,
to get rid of パケットs with "Martian" or other non-routed アドレスes」
があります。

他のアプローチが利用不能な場合、「Loose RPF」は、中身の検証の形態として、使われる可能性があります。:
他方のネットワークは、
is presumably certifying that
「it has provided 適切なイングレスフィルタリングのルール」,
そのフィルタリングを行うネットワークは、契約違反を示すパケットが検出された場合、
verify the fact and react
必要があるのみです。当然ながら、このメカニズムは、「使われている発信元アドレスが「martian」、もしくは、他の経路制御されないアドレスであるか否か」を示すのみです。
(not if they are from someone else のアドレス空間。)

2.5.  デフォルト経路を無視する「Loose RPF」 English

(準備中)

5 番目の実装テクニックは、デフォルト経路を無視する Loose RPF(すなわち、「明示的な経路の存在チェック」)として、特徴づけられる可能性があります。このアプローチにおいて、そのルーターは、経路テーブル中の発信元アドレスをルックアップし、経路が発見された場合、そのパケットを保持します。しかし、そのルックアップにおいて、デフォルトの経路は、除外されています。それゆえ、そのテクニックは、概ね、
is usable in シナリオs where デフォルト経路 are used only to catch トラフィック with bogus 発信元アドレスes,
with an extensive (or even full)リスト of explicit routes to cover 正規のトラフィック。

「Loose RPF」のように、これは、ISP リンク間上のような非対称ルーティングが有る場所には有用です。しかし、「Loose RPF」のように、これは、エッジネットワークのトラフィックが
to トラフィック legitimately sourced from that ネットワーク
を制限する能力を失います。なぜなら、これは、方向性を犠牲にするからです。

 

3.  イングレスフィルタリングの適用可能性を明確にする English

既に明らかなことは、「イングレスフィルタリングは、ISP とエンドユーザの間の『最後の(last-mile)』インターフェイスにのみ適用されるわけではないこと」です。適切である限り、ISP のエッジ(のエンタープライズネットワーク等の LAN に接続しているルーター)においてもイングレスフィルタリングを行うことは、完全に良いことであり、推奨されます。これは、防護を厚くします。

3.1.  複数レベルにおけるイングレスフィルタリング English

(準備中)

より広範なイングレスフィルタリングの配備によって、この論点は、再帰的になります。イングレスフィルタリングは、最初の 2 者の間だけではなく、それが使われているあらゆるところで動作する必要があります。すなわち、ユーザが特別なイングレスフィルタリングの合意を彼の ISP と交渉する場合、ユーザは、
「同一の合意は、ISP のアップストリームと、ピアとなるリンクにも適用されること」
も確認する(あるいは、その ISP が確保するようにする)必要があります,
if イングレスフィルタリング is being used there -- or will get used,
at some point in the future。
similarly with the アップストリーム ISP とピア。

結果として、マニュアルモデルは、限られた一般的な有用性しかもちません。これは、「どこにそのパケットは行くのか?」や「どこにイングレスフィルタリングが適用される可能性があるか?」という情報をすべての主体宛に自動的には伝えないものです。

3.2.  あなたのインフラストラクチャを防護するためのイングレスフィルタリング English

より広範なイングレスフィルタリングの配備に立脚するその他の機能は、まだ、明らかではない可能性があります。そのルーターや他の ISP インフラストラクチャは、いくつかの種類の攻撃に対して可変です。その脅威は、典型的には、「誰が、これらのシステムにアクセスできるか?」を制限することによって緩和されます。

しかし、イングレスフィルタリング(あるいは、少なくとも、その制限されたサブネット)が、(あなた自身のアドレスを発信元アドレスとして使うことをブロックして)すべての境界(顧客、ピアおよびアップストリームとの境界)に配備されていない限り、その攻撃者は、インフラストラクチャの要素の防護の裏をかくことができる可能性があります。

それゆえ、イングレスフィルタリングを配備することによって、人は、単にインターネット全体を助けるのみならず、あなた自身のインフラストラクチャに対するいくつかの脅威のクラスからも防護します。

3.3.  ピアになっているリンクにおけるイングレスフィルタリング English

ピアになっているリンクにおけるイングレスフィルタリングは、(ISP によるものであれ、エンドサイトによるものであれ)実際には、より典型的な「ダウンストリーム」もしくは「アップストリーム」のイングレスフィルタリングと大差ないものです。

しかし、「混合されたアップストリーム/ダウンストリームや、ピアとなるリンクをもつ異なるリンクは、異なる属性をもつ可能性があること(例: 契約、信用、イングレスフィルタリングメカニズムの実行可能性等に関連する。)」に注意することが重要です。大部分の典型的な場合において、ピアに対するイングレスフィルタリングのメカニズム(例:Strict RPF)の単純な利用は、そのピア間のルーティングが合理的に対称的に保たれている限り、うまく働きます。「相手となるリンク越しに来る必要があるアップストリームリンクから来る発信元アドレスをフィルタできることは有用である」と考えることさえもできます。(Strict RPF のようなものが、アップストリームについて使われることを意味します。)しかし、これは、より複雑な論点であり、範囲外であると考えられています。(6章 参照。)

 

4.  マルチホームされたイングレスフィルタリングについての解決策 English

まず、人は、「なぜ、サイトは、マルチホームするのか?」を尋ねなければなりません。例えば、そのエッジネットワークは、下記のようである可能性があります。:

マルチホームされたネットワーク用のイングレスフィルタの制約を回避するために、数多くのアプローチを想像することができます。オプションには、下記事項が含まれます。:

  1. マルチホームしない。
     
  2. イングレスフィルタを使わない。
     
  3. 「サービスが不完全であること」を受容する。
     
  4. いくつかのインターフェイスにおいて、4.1 節 に記述したような適切な形態の「Loose RPF」チェックを使うことによって、イングレスフィルタリングを弱める。
     
  5. BGP によって、あるいは契約によって、「各 ISP のイングレスフィルタが 4.2 節 に記述したように完全であること」
    を確認する。
     
  6. 4.3 節 に記述されているように、「エッジネットワークは、実際にそのイングレスフィルタを通過する、その ISP 宛てのトラフィックのみを配信すること」を確認する。

これらの最初の 3 つは、明らかに、完全性について言及しています。これらは、実行不能であり、実行可能であるはずがありません。最後の 3 つは、以下において検討されます。

4 番目と 5 番目は、アップストリーム ISP においても、3.1 節 に記述されたように確認されなければなりません。

次に、我々は、イングレスフィルタの副次的効果を扱う多様な方法を見ます。

4.1.  適切である限り「Loose RPF」を使う English

(準備中)

対称的ルーティングが選好される場合、あるいは、不可避である場合、イングレスフィルタリングは、「パスが対称的であること」を要求する「Strict RPF」のようなメカニズムを使って配備するのが困難である可能性があります。多くの場合において、オプションとしての手法、もしくは、「Feasible RPF」を使うことは、下記のように、イングレスフィルタが完璧であることを確認することができます。
Failing that,
唯一の現実の選択肢は、イングレスフィルタリングを行わずに,
use a マニュアルのアクセスリスト(possibly in addition to 何らかの他のメカニズムs)
か、あるいは、何らかの形態の「Loose RPF」チェックを使うことです。

「イングレスフィルタをまったく提供できない」ということは、要するに、
the ダウンストリームネットワークが
to behave itself,
which is not the wisest course of action
を信用するということです。しかし、特に、数百から数千もの prefix をもつ非常に大きなネットワークの場合、手作業のアクセスリストに維持管理は、頼むにはあまりにきつい可能性があります。

「Loose RPF」の利用は、エッジネットワークと、その ISP の間において、良い選択ではないようです。なぜなら、これは、テストの方向性を失うからです。これは、
argues in favor of either using a complete フィルタ in the アップストリームネットワーク or ensuring in the ダウンストリーム ネットワーク that パケットs the アップストリームネットワーク will reject will never reach it。

それゆえ、「Loose RPF」の利用は、「『martian』、もしくは、他の経路制御されないアドレスが使われているか否か?」を測定する方法として以外は、推奨できません。

4.2.  各 ISP のイングレスフィルタが完璧であることを確保する English

(準備中)

そのエッジネットワークについて、マルチホーミングが堅牢さのため、もしくは、
from time to time depending on measured ISP behavior
ルーティングを変更するために使われている場合、最も単純なアプローチは、「その ISP が実際に、そのアドレスを、ルーティングの際に運んでいること」を確認することです。これは、しばしば、「その prefix が主要な transit ISP 宛にアップストリームに運ばれていること」を確認するために、エッジネットワークに
プロバイダーに依存しない prefix と exchange routes with its ISPs with BGP
を使うことを要求します。必然的に、これは、
「そのエッジネットワークは、
to qualify for a 分離されたアドレス割り当てと AS(Autonomous System)番号 from its RIR
大きさになり、技術的に準拠するものとなること」
を意味します。

「ISP のイングレスフィルタが完全であること」を確認することを容易にするテクニックが数多くあります。運用的テクニックを伴って、「Feasible RPF」と「Strict RPF」の両方は、ISP とエッジネットワーク間のマルチホームされた、あるいは、非対称的シナリオについて、極めてうまく動作します。

ルーティングプロトコルは使われていませんが、その顧客情報が Radius、TACACS あるいは Diameter のようなデータベースから生成されているとき、そのイングレスフィルタリングは、「Strict RPF」、もしくは、そのようなデータベースから自動的に生成されたイングレスアクセスリストで、最も容易に確保し、最新状態に保つことができます。

4.3.  トラフィックをプロバイダー Prefix を使ってそのプロバイダーのみに宛てて送る English

プロバイダーに基づくアドレス割り当てを使っていおり、その ISP が(実装すべき)イングレスフィルタを実装している、より小さなエッジネットワーク用の 3 番目のオプションは、一定のプロバイダーのアドレス空間から発信されたトラフィックを、そのプロバイダー宛てに経路制御することです。

(準備中)

これは、複雑な手順ではありませんが、注意深い計画と設定を要求します。堅牢さを確保するために、エッジネットワークは、
複数の異なる POP(Points of Presence)を通じて、
so that if one POP or line experiences an outage,
その他のリンク to the same ISP can be used
その ISP の各に接続することを選択する可能性があります。代わりに、一式のトンネルが、同一の ISP に対する複数の接続の代わりに、設定される可能性があります。[4][5] このようにして、そのエッジルーターは、
to 1st inspect the 発信元アドレス of a パケット destined to an ISP,
and shunt it into the 適切なトンネル or インターフェイス toward the ISP
設定されます。

このようなシナリオが網羅的に適用される場合、そのネットワークが使うすべての prefix について、エッジネットワークにおいて出口(exit)ルーターが選択されるようにするために、いかなる他の prefix を起点とするトラフィックを、ISP 宛てに送る代わりに、即座に捨てることができます。

 

5.  セキュリティについての考慮事項 English

イングレスフィルタリングは、典型的には、「あるネットワークインターフェイスに到着するトラフィックが、正規に、そのインターフェイスを通じて到達可能なネットワーク上にあるコンピュータから来ること」を確保するために行われます。

より近くで実際の発信元のイングレスフィルタリングが行われるほど、より効果的になります。「最初のホップのルーターは、『近隣のエンドシステムから経路制御されているトラフィックは、正しく宛てられていたこと』を確認すること」が望まれる可能性があります。遠くのルーターは、「そのようなシステムが示された prefix 内にある可能性があること」 のみを確認できます。それゆえ、イングレスフィルタリングは、複数のレベルにおいて、異なる粒度のレベルで行われる必要があります。

「イングレスフィルタリングの目標のひとつは、攻撃を追跡可能にすることですが、『インターネットのどこかに居る特定の攻撃者が、イングレスフィルタされるか否か?』を知ることは、不可能であること」を認識しておく価値があります。それゆえ、「その発信元アドレスが偽装されているか否か?」のみを推測できます。: あらゆる場合において、可能性ある先行情報を得ること(例: 潜在的な発信元に「they は、攻撃を観察しているか否か?」と訪ねるために接続すること)は、なおも有用であり、イングレスフィルタリングがより広範に配備されるとき、より有用です。

結果として、すべての運用管理的ドメインは、その境界において、十分なレベルのイングレスフィルタリングを確保することを試す必要があります。

異なるイングレスフィルタリング種別のセキュリティ属性と適用可能性は、多様です。

(準備中)

多様なイングレスフィルタリングのメカニズムの二律背反性を重みづけるとき、より緩和されたアプローチのセキュリティ属性は、それを適用する前に、注意深く考慮される必要があります。特に、ある ISP によって、エッジネットワークに対して適用されるとき、「なぜ、厳密な形態のイングレスフィルタリングが不適切であるのか?」について、多くの理由があるようには考えられません。

 

6.  結論と将来の作業 English

このメモは、イングレスフィルタリングのテクニック一般と、特に、マルチホームされたネットワークについてのオプションについて記述します。

ISP が、偽装されたアドレスが使われることを防ぐために、(DoS 攻撃を短縮し、それらをより追跡可能にするためと、ISP 自身のインフラストラクチャを防護するための両方のために)イングレスフィルタリングを実装することは、重要です。このメモは、その効果を得るのに使えるメカニズムと、それらのメカニズムのトレードオフ を記述します。

要約すると、下記のとおり。:

このメモは、「イングレスフィルタリングが実装困難である」と一般に信じられてきたイングレスフィルタリングの採用について、バーの高さを低くし、特に、非対称な/マルチホームされたネットワークのようなシナリオにおいて、バーの高さを低くします。

追加的な作業が有用である複数の領域を識別できます。:

 

7.  謝辞 English

Rob Austein, Barry Greene, Christoph Reichert, Daniel Senie, Pedro Roque, Iljitsch van Beijnum は、本書をレビューし、改善する支援をしてくれました。Thomas Narten, Ted Hardie, Russ Housley は、本書の標準化の最終工程において加速した良いフィードバックを提供してくれました。

 

8.  参考文献

8.1.  規範的参考文献

[1]  Ferguson, P. and D. Senie,
「ネットワークのイングレスフィルタリング:発信元 IP アドレスを偽ったサービス妨害攻撃をくじく(Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing)」,
BCP 38
, RFC 2827, 2000年 5月.

 

8.2.  参考資料

[2]   Chandrasekeran, R., Traina, P. and T. Li,
"BGP Communities Attribute",
RFC 1997, 1996年 8月
.
[3]  IANA,
"Special-Use IPv4 Addresses",
RFC 3330, 2002年 9月.
 
[4]  Bates, T. and Y. Rekhter,
"Scalable Support for Multi-homed Multi-provider Connectivity",
RFC 2260, 1998年 1月.
 
[5]  萩野いとぢゅん純一郎 and H. Snyder,
"IPv6 Multihoming Support at Site Exit Routers",
RFC 3178, 2001年10月.

 

9.  著者のアドレス

Fred Baker
Cisco Systems
Santa Barbara, CA  93117
US

EMail: fred@cisco.com

Pekka Savola
CSC/FUNET
Espoo
Finland

EMail: psavola@funet.fi

翻訳者のアドレス

独立行政法人 情報処理推進機構
セキュリティセンター

(準備中)

 

10.  著作権表記全文

Copyright (C) The Internet Society (2004).  This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 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.

知的財産権

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 procedures with respect to rights in RFC documents can be found in BCP 78 and 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.

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.

謝辞

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