Reverse path forwarding

Reverse path forwarding は、IPネットワークでマルチキャストパケットを転送するためのアルゴリズムのひとつである。 マルチキャストルーティングではパケットをルーティング・ループを起こすことなく転送でき、ユニキャストルーティングではIPアドレススプーフィングを防止できる。2012年2月現在、シスコシステムズ、ジュニパーネットワークス、ヤマハ、アライドテレシスがRPFに対応するルーターを発売している。

1. マルチキャストRPF
-------------

マルチキャストRPFは、ルーティング・ループを起こすことなくマルチキャストパケットを転送するため、Multicast Source Discovery Protocol やSparse multicast といったマルチキャストルーティングプロトコルとともに利用する。マルチキャストルーティングでは、トラフィックを転送するかどうかの判断は送信元アドレスを基に行う。これは、ユニキャストルーティングでは宛先アドレスを基に転送可否の判断を行うことと対称的である。ルーティングにはマルチキャスト専用のルーティングテーブルか、ユニキャスト用のルーティングテーブルを利用する。

マルチキャストパケットがルーターのインタフェースに入ると、ルーターは当該インタフェースから到達可能なネットワークのリストを検索する。ルーターが「マルチキャストパケットの送信元IPアドレス」が「自らのルーティングテーブルに」存在することを発見すると、パケットはマルチキャストグループに参加しているその他のインタフェースにマルチキャストで転送される。ルーティングテーブルに送信元IPアドレスが存在しない場合、パケットは捨てられる。結果として、パケットが転送されるか否かはパケットの前向経路ではなく、//逆行経路//によって決まる。RPFルーターはルーターのインタフェースに到達するパケットでパケットの送信元についてルーティングエントリがあるものだけを転送するため、ルーティングループを形成しない。このチェックのことをRPFチェックと言う。

冗長構成のマルチキャストトポロジーでは、同一のマルチキャストパケットが同一のルーターの別々のインタフェースに到達する可能性があるため、パケットを転送するか否かの判断にRPFチェックが必須となる。仮に2つのインタフェースを持つルーターが、インタフェースAに到達した全てのパケットをインタフェースBに転送するとする。インタフェースBに到達した全てのパケットは同様にインタフェースAに転送するとする。この場合、両方のインタフェースが同一のパケットを受信すると、古典的なルーティングループが発生し、IPの生存時間 が尽きるまで両方向に向けてパケットが転送され続けてしまうだろう。いつかはTTLが尽きるとしても、ルーティングループが発生すると、少なくとも一時的にはネットワークの速度低下を招く。ルーティングループが起きる可能性はできる限り最小にしなければならない。

RPFチェックの前提条件は以下の2点である。

//ユニキャストルーティングテーブルが正確、かつ収束していること。//RPFチェックの正常動作はユニキャストルーティングテーブルに依存する。
//送信者がルーターに到達するための経路とルーターから送信者を逆にたどった経路が対称的であること。//この前提が成立しない場合、RPFチェックは送信者からルーターまでの最短経路上のマルチキャストトラフィックを拒否する。このため、マルチキャストツリーが最適状態とならない。リンクが片方向である場合、リバースパスアプローチは完全に失敗する。

2. ユニキャストRPF
------------

3704}}に定義されているユニキャストRPF は、「既知の『無効なネットワーク』からのトラフィックは、インタフェースで受け付けられるべきでない。そもそもそのようなトラフィックが生成されていないはずだから」とした点が発展的である。2827}}で見られる原案は「プライベートアドレスを送信元とするトラフィックをインタフェース上でブロックする」というものであった。多くの組織にとってプライベートアドレスを伝播する必要はないはずであるから、送信元をプライベートアドレスとしたトラフィックを無効としてブロックするのは合理的である。

サービス拒否攻撃、分散型サービス拒否攻撃、ネットワークスキャンでスキャン元を隠すなどのために、IPアドレススプーフィングが一般的に利用される。しかしuRPFを利用すれば、偽の送信元アドレスであることが明らかなパケットをブロックできる。これでIPアドレススプーフィングを阻止することができるので、インターネットバックボーンにとって多大な恩恵となる。

uRPFは、「全てのルーターは、各自が保持しているルーティング情報ベース か転送情報ベース を利用して、インタフェースに到達するであろう送信者アドレスをより厳しく制限すべきである」という基本思想を劇的に押し広げた。送信元アドレスからルーターへの最善ルートを通って到着した場合にのみパケットが転送されるので、以下が成り立つ。

インタフェースに到達したパケットは、有効なホストから届いたものである。なぜなら、対応するエントリがルーティングテーブルに存在するからである。
入力インタフェースを経由して到達//できない//送信元アドレスをセットされたパケットは、通常利用に影響を与えることなく捨てられる。これは、当該パケットが設定ミスがあるか悪意ある送信元からのものであると思われるためである。以下に示すような「対称的なルーティング」では、uRPFは大きな懸念なく実装できるだろう。

パケットが転送される前向経路と逆行経路は同じであるはずだ。
ネットワークエッジへのリンクがただ1つである。ルーターのインタフェースが「シングルホームのネットワーク」と「端末の存在するサブネット」に接続されていて、ルーティングが確実に対称的である場合、当該インタフェースにRPFを実装すれば特に有益である。できる限り送信者に近い場所でuRPFを利用すれば、スプーフィングされたトラフィックがインターネット接続の帯域を利用したり、RPFが構成されていないルーターに到達して転送されてしまったりすることを防げるからである。

しかし、比較的大きなインターネットバックボーンではルーティングが非対称な場合がある。この場合、送信者がルーターに到達するための最善ルートをルーティングテーブルが保持していることを期待できないことがある。ルーティングテーブルは最善なフォワードパスを規定するが、それを逆行すれば最善なリバースパスになるのはルーティングが対称的な場合だけだ。ルーティングが非対称なケースは一般的なだけに、問題のないトラフィックが誤ってフィルタリングされることを防ぐため、uRPFを実装する際はルーティングが非対称になる可能性について十分な注意が必要である。

なお、デフォルトルートを使用中のデバイスは、デフォルトルートが指し示すインタフェース上ではuRPFを利用できない。送信元にかかわらずすべてのパケットが当該インタフェースで許可されてしまうことが理由である。uRPFは2827}}で定義される水準すら達成できないであろう。

3704}}は「この送信元アドレスは入力インタフェースに対応するルーティングテーブルに必ず記録されているはずだ」というこの基本概念を拡張してStrict Reverse Path Forwarding とした。ある程度経路が非対称な場合でもStrict RPFを利用するメリットがある例も挙げられている。

2.1. Strictモード
--------------

Strictモードでは、受信するパケットはFIBと照査され、パケットを//受信した//インタフェースが最適のリバースパスでない場合、チェックは失敗する。既定ではチェックを通過しなかったパケットは捨てられる。

2.2. Feasibleモード
----------------

FeasibleモードではFIBが任意のIPアドレスに対するオルタネートルートを複数保持する。パケットを//受信した//インタフェースが当該IPアドレスに関連づけられた経路と一致する場合、パケットは転送される。一致しない場合はパケットは捨てられる。

2.3. Looseモード
-------------

Looseモードでは受信するパケットの送信元アドレスがFIBと照査される。ルーター上の//どの//インタフェースからも送信元アドレスに到達できない場合にのみ、パケットは捨てられる。

3. uRPFのFを「フィルタリング」とする誤解
------------------------

ユニキャストルーティングにおいては特に、RPFをReverse Path Filteringの略とする誤った定義が流布している。RPFが3704}}で示されるようにユニキャストルーティングとともに使われる場合、トラフィックの転送可否はRPFチェックに通過するか否かを基に決まる。これを「RPFチェックに失敗したので、パケットがフィルタリングされた」と受け取ったために生じた誤解であろう。3704}}によれば、正しくは「RPFチェックを通過すればトラフィックがForwardingされる」である。[1]、[2]、[3]は、この点を正しく述べている。ユニキャストでのRPFの利用について定義した3704}}が最も重要である。

uRPFは受信トラフィックにフィルタリング機構を用いるが、リバースパスフォワーディングの影響を受けるのである。

4. 脚注
-----

5. 参考文献
-------

6. 外部リンク
--------

[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]カテゴリ:ネットワーク層プロトコル