|
ネットワーク WG Request for Comments： 3704 更新： 2827 BCP： 84 分類： ベストカレントプラクティス |
F. Baker Cisco Systems P. Savola CSC/FUNET 2004年3月 |
(準備中)
この文書は、 インターネットの「現時点における最善の実践(ベストカレントプラクティス)」を示すものであり、 改善するために議論と示唆を求めるものです。 このメモの配布に制限はありません。
Copyright (C) The Internet Society (2004). All Rights Reserved.
BCP 38, RFC 2827は、 偽装されたアドレスでネットワークにアクセスするトラフィックを拒否することによって、 分散型サービス妨害攻撃の影響を制限し、「トラフィックについて、 その正しい発信元ネットワークを追跡可能であること」を確保し易くすることを意図しています。 インターネットをこのような攻撃から防護することの副次的効果として、 この解決策を実装しているネットワークは、また、この攻撃や、 ネットワーク機器に対する偽装されたマネジメントアクセスのような他の攻撃からも自身を護ります。 これが問題を生む可能性があるときがあります。 (例：マルチホーミングによる場合) 本書は、現在のイングレスフィルタリングの運用的メカニズムを記述し、 イングレスフィルタリングに関する一般的な論点を吟味し、特に、 マルチホーミングの影響について探求します。このメモは、RFC 2827を更新します。
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が、 インターネットから受信したパケットにおいて発信元アドレス中に使われていないこと」を検証することによって正しいフィルタリングによって自身を護ることができます。 他の攻撃において、その発信元アドレスは、32bitの乱数として書かれ、 攻撃元が追跡困難になります。 エッジネットワークを出て、 あるISPに入るトラフィックが正規に送信されているトラフィックに制限できる場合、 攻撃は、なんとか緩和できます。：
乱雑な、あるいは、偽りの発信元アドレスをもつトラフィックは、 甚大な被害をもたらす前に抑制することができ、攻撃は、いつでも、 少なくとも攻撃者の発信元ネットワークまで辿ることができます。
本書は、下記のような ISP やエッジネットワークの運用者を対象としています。
2章において、イングレスフィルタリングを実装するための、 いくつかの異なる方法 が、一般的な文脈において、記述され、吟味されます。 3章において、 イングレスフィルタリング手法の適用可能性について、 いくつかの明確化が行われます。 4章において、イングレスフィルタリングが、 マルチホーミングの観点から詳細に分析されます。 5章において、結論と、潜在的な将来の作業項目が識別されます。
この章では、このメモ執筆時点におけるイングレスフィルタリングを実装するために使われる 多様な運用的テクニックへの導入の役割を果たします。 そのメカニズムが、一般的な用語で記述、分析されており、 マルチホーミング固有の論点が4章に記述されています。
RFC 2827を実装するには、少なくとも、多様な影響をともなう5つの方法があります。 これらは、下記の事項を含みます。(その名前は、比較的卑近な用法で記しています。)：
他のメカニズムも、可能であり、実際、さらなる調査、仕様化、実装、 かつ／または、配備から得るものがある可能性がある数多くのテクニックがあります。 (6章参照。) しかし、これらは、範囲外です。
イングレスアクセスリストは、ネットワークインターフェイスにおいて受信した、 すべてのメッセージの発信元アドレスを受容可能なprefixのリストに照らしてチェックし、 そのフィルタに適合しないあらゆるパケットを棄却するフィルタです。 これは、(決して)イングレスフィルタを実装する唯一の方法ではないのですが、 これは、RFC 2827 [1] によって提案されたものであり、 ある意味で、最も決定論的なものです。
しかし、イングレスアクセスリストは、典型的には、 マニュアルで維持管理されています。 例えば、prefixのセットが変化する場合(例：マルチホーミングの結果として)、 ISPにおけるリストを更新することを忘れることは、 それらがそのイングレスフィルタを通過しない場合、 そのパケットを捨てることをもたらす可能性があります。
当然、この問題は、イングレスアクセスリストに限られません。 (これは、そのイングレスフィルタが不完全なとき、 イングレスフィルタリングに内在します。) しかし、通常、イングレスアクセスリストは、 他のメカニズムよりも維持管理が困難であり、陳腐化したリストをもつことは、 正規のアクセスを妨げる可能性があります。
「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に対するマルチホーミングに適用されたとき、 この想定は、 失敗する可能性があります。
(準備中)
「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」は、 一定の種類の非対称ルーティングのシナリオにおいて、非常に強力なツールですが、 その運用的役割と適用可能性をよく理解することが重要です。
「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 のアドレス空間。)
(準備中)
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 ネットワーク
を制限する能力を失います。
なぜなら、これは、方向性を犠牲にするからです。
既に明らかなことは、「イングレスフィルタリングは、 ISPとエンドユーザの間の『最後の(last-mile)』インターフェイスにのみ適用されるわけではないこと」です。 適切である限り、ISPのエッジ (のエンタープライズネットワーク等のLANに接続しているルーター) においてもイングレスフィルタリングを行うことは、完全に良いことであり、 推奨されます。こ れは、防護を厚くします。
(準備中)
より広範なイングレスフィルタリングの配備によって、この論点は、再帰的になります。
イングレスフィルタリングは、最初の2者の間だけではなく、
それが使われているあらゆるところで動作する必要があります。
すなわち、ユーザが特別なイングレスフィルタリングの合意を彼のISPと交渉する場合、
ユーザは、
「同一の合意は、ISP のアップストリームと、ピアとなるリンクにも適用されること」
も確認する(あるいは、その ISP が確保するようにする)必要があります,
if イングレスフィルタリング is being used there -- or will get used,
at some point in the future。
similarly with the アップストリーム ISP とピア。
結果として、マニュアルモデルは、限られた一般的な有用性しかもちません。 これは、「どこにそのパケットは行くのか？」や「どこにイングレスフィルタリングが適用される可能性があるか？」という情報をすべての主体宛に自動的には伝えないものです。
より広範なイングレスフィルタリングの配備に立脚するその他の機能は 、まだ、明らかではない可能性があります。 そのルーターや他のISPインフラストラクチャは、 いくつかの種類の攻撃に対して可変です。その 脅威は、典型的には、「誰が、 これらのシステムにアクセスできるか？」を制限することによって緩和されます。
しかし、イングレスフィルタリング(あるいは、少なくとも、 その制限されたサブネット)が、 (あなた自身のアドレスを発信元アドレスとして使うことをブロックして)すべての境界(顧客、 ピアおよびアップストリームとの境界)に配備されていない限り、その攻撃者は、 インフラストラクチャの要素の防護の裏をかくことができる可能性があります。
それゆえ、イングレスフィルタリングを配備することによって、人は、 単にインターネット全体を助けるのみならず、 あなた自身のインフラストラクチャに対するいくつかの脅威のクラスからも防護します。
ピアになっているリンクにおけるイングレスフィルタリングは、 (ISPによるものであれ、エンドサイトによるものであれ)実際には、 より典型的な「ダウンストリーム」もしくは「アップストリーム」のイングレスフィルタリングと大差ないものです。
しかし、「混合されたアップストリーム／ダウンストリームや、 ピアとなるリンクをもつ異なるリンクは、 異なる属性をもつ可能性があること(例：契約、信用、 イングレスフィルタリングメカニズムの実行可能性等に関連する。)」に注意することが重要です。 大部分の典型的な場合において、 ピアに対するイングレスフィルタリングのメカニズム(例：Strict RPF)の単純な利用は、 そのピア間のルーティングが合理的に対称的に保たれている限り、うまく働きます。 「相手となるリンク越しに来る必要があるアップストリームリンクから来る発信元アドレスをフィルタできることは有用である」と考えることさえもできます。 (Strict RPFのようなものが、アップストリームについて使われることを意味します。) しかし、これは、より複雑な論点であり、 範囲外であると考えられています。 (6章参照。)
まず、人は、「なぜ、サイトは、 マルチホームするのか？」を尋ねなければなりません。 例えば、そのエッジネットワークは、下記のようである可能性があります。：
マルチホームされたネットワーク用のイングレスフィルタの制約を回避するために、 数多くのアプローチを想像することができます。 オプションには、下記事項が含まれます。：
これらの最初の3つは、明らかに、完全性について言及しています。 これらは、実行不能であり、実行可能であるはずがありません。 最後の3つは、以下において検討されます。
4番目と5番目は、アップストリームISPにおいても、 3.1節に記述されたように確認されなければなりません。
次に、我々は、イングレスフィルタの副次的効果を扱う多様な方法を見ます。
(準備中)
対称的ルーティングが選好される場合、あるいは、不可避である場合、
イングレスフィルタリングは、「パスが対称的であること」を要求する「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』、もしくは、 他の経路制御されないアドレスが使われているか否か？」を測定する方法として以外は、 推奨できません。
(準備中)
そのエッジネットワークについて、マルチホーミングが堅牢さのため、もしくは、
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」、もしくは、 そのようなデータベースから自動的に生成されたイングレスアクセスリストで、 最も容易に確保し、最新状態に保つことができます。
プロバイダーに基づくアドレス割り当てを使っていおり、 その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宛てに送る代わりに、即座に捨てることができます。
イングレスフィルタリングは、典型的には、 「あるネットワークインターフェイスに到着するトラフィックが、正規に、 そのインターフェイスを通じて到達可能なネットワーク上にあるコンピュータから来ること」を確保するために行われます。
より近くで実際の発信元のイングレスフィルタリングが行われるほど、 より効果的になります。 「最初のホップのルーターは、 『近隣のエンドシステムから経路制御されているトラフィックは、 正しく宛てられていたこと』を確認すること」が望まれる可能性があります。 遠くのルーターは、 「そのようなシステムが示されたprefix内にある可能性があること」のみを確認できます。 それゆえ、イングレスフィルタリングは、複数のレベルにおいて、 異なる粒度のレベルで行われる必要があります。
「イングレスフィルタリングの目標のひとつは、 攻撃を追跡可能にすることですが、 『インターネットのどこかに居る特定の攻撃者が、 イングレスフィルタされるか否か？』を知ることは、 不可能であること」を認識しておく価値があります。 それゆえ、「その発信元アドレスが偽装されているか否か？」のみを推測できます。： あらゆる場合において、 可能性ある先行情報を得ること(例：潜在的な発信元に「theyは、 攻撃を観察しているか否か？」と訪ねるために接続すること)は、 なおも有用であり、 イングレスフィルタリングがより広範に配備されるとき、より有用です。
結果として、すべての運用管理的ドメインは、その境界において、 十分なレベルのイングレスフィルタリングを確保することを試す必要があります。
異なるイングレスフィルタリング種別のセキュリティ属性と適用可能性は、多様です。
(準備中)
多様なイングレスフィルタリングのメカニズムの二律背反性を重みづけるとき、 より緩和されたアプローチのセキュリティ属性は、それを適用する前に、 注意深く考慮される必要があります。 特に、あるISPによって、エッジネットワークに対して適用されるとき、「なぜ、 厳密な形態のイングレスフィルタリングが不適切であるのか？」について、 多くの理由があるようには考えられません。
このメモは、イングレスフィルタリングのテクニック一般と、特に、 マルチホームされたネットワークについてのオプションについて記述します。
ISPが、偽装されたアドレスが使われることを防ぐために、(DoS攻撃を短縮し、 それらをより追跡可能にするためと、 ISP自身のインフラストラクチャを防護するための両方のために)イングレスフィルタリングを実装することは、重要です。 このメモは、その効果を得るのに使えるメカニズムと、 それらのメカニズムのトレードオフを記述します。
要約すると、下記のとおり。：
このメモは、 「イングレスフィルタリングが実装困難である」と一般に信じられてきたイングレスフィルタリングの採用について、 バーの高さを低くし、特に、 非対称な／マルチホームされたネットワークのようなシナリオにおいて、 バーの高さを低くします。
追加的な作業が有用である複数の領域を識別できます。：
Rob Austein, Barry Greene, Christoph Reichert, Daniel Senie, Pedro Roque, Iljitsch van Beijnumは、本書をレビューし、改善する支援をしてくれました。 Thomas Narten, Ted Hardie, Russ Housleyは、 本書の標準化の最終工程において加速した良いフィードバックを提供してくれました。
| [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月. |
| [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月. |
Fred Baker
Cisco Systems
Santa Barbara, CA 93117
US
EMail： fred＠cisco.com
Pekka Savola
CSC/FUNET
Espoo
Finland
EMail： psavola＠funet.fi
独立行政法人 情報処理推進機構
セキュリティセンター
(準備中)
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.