Reverse path forwarding

ウィキペディアから無料の百科事典

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

マルチキャストRPF[編集]

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

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

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

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

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

リンクが片方向（uni-directional）である場合、リバースパスアプローチは完全に失敗する。

ユニキャストRPF （uRPF）[編集]

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

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

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

  1. インタフェースに到達したパケットは、（おそらく）有効なホストから届いたものである。なぜなら、対応するエントリがルーティングテーブルに存在するからである。
  2. 入力インタフェースを経由して到達できない送信元アドレスをセットされたパケットは、通常利用に影響を与えることなく捨てられる。これは、当該パケットが設定ミスがあるか悪意ある送信元からのものであると思われるためである。

以下に示すような「対称的なルーティング」では、uRPFは大きな懸念なく実装できるだろう。

  1. パケットが転送される前向経路と逆行経路は同じであるはずだ。
  2. ネットワークエッジへのリンクがただ1つである。

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

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

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

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

Strictモード（Strictチェックモード）[編集]

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

Feasibleモード[編集]

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

Looseモード[編集]

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

uRPFのFを「フィルタリング」とする誤解[編集]

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

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

脚注[編集]

  1. ^ http://www.cisco.com/web/JP/product/hs/ios/multicast/tech/mcst_ovr.html#a24
  2. ^ http://www.juniper.net/techpubs/en_US/junos11.4/topics/concept/multicast-reverse-path-forwarding.html
  3. ^ http://jp.yamaha.com/products/network/solution/advanced/multicast/
  4. ^ http://www.allied-telesis.co.jp/info/news/2008/nr080722.html

参考文献[編集]

Dave Kosiur『マスタリングTCP/IP　IPマルチキャスト編』苅田幸雄 （監訳）、オーム社、1999年。ISBN 978-4274063381。 
Gene『詳解IPマルチキャスト 概念からCisco製品での設定例まで』ソフトバンククリエイティブ、2009年。ISBN 978-4797356052。 

外部リンク[編集]

「https://ja.wikipedia.org/w/index.php?title=Reverse_path_forwarding&oldid=97693118」から取得