要約

  • RFC 2267は、顧客に接続するプロバイダーの入力インターフェースで、パケットの送信元プレフィックスをその顧客が使える範囲と照合する案を示した。
  • BCP 38は2000年にこの方法を推奨慣行として定めた。通過したパケットから分かるのはネットワークの境界までで、発信端末や利用者の身元ではない。

宛先からは、アドレスを書いた人が見えない

サーバーに届く接続要求が、到達不能なアドレスから来たように見える。返信は行き先を失い、送信側はパケットの送信元欄を次々に変える。別の要求では、攻撃と無関係なネットワークの実在アドレスが使われることもある。被害を受けた側がそのアドレスを遮断すれば、無関係な組織の正規通信まで止めかねない。

RFC 2267が扱ったのは、こうした受信側の限界だった。受信者はパケットに書かれたアドレスを読めるが、誰がそれを選んだかは直接確かめられない。サーバー側の強化は大量の要求に耐える助けになる一方、遠くの被害者に送信元の真偽までは教えてくれない。同文書はホストの対策とネットワーク側の対策を併用し、送信元に近い場所で追加確認する案を示した。

プロバイダーは顧客の入口を把握していた

複数の下流ネットワークの経路を集約するプロバイダーを考えてみよう。特定顧客につながるルーターの入力側では、その回線から正当に出てよい送信元プレフィックスを管理できる。RFCの例では顧客のプレフィックスを使うパケットを通し、それ以外を拒否する。疑わしい活動を追えるよう、破棄したパケットの情報を記録することも勧めている。

これは全アドレスの所有者を世界共通の台帳で照会する仕組みではない。顧客回線と許可されたプレフィックス集合という、ネットワーク端で管理できる関係を使う。パケットがプロバイダーの広い網へ進む前に、インターフェースが送信元欄とその関係を照らし合わせる。許可範囲外なら、被害側に不確かな手掛かりを渡す前に入口近くで止められる。

場所を変えると、防御の役割も変わる。上流に確認がなければ、被害側は信用できないアドレス欄を手掛かりにし、無実のアドレス利用者を巻き込む可能性がある。プロバイダーが顧客側の入口で確認すれば、顧客の通信を運ぶネットワーク自身が、その回線に属さない送信元を拒否できる。許可範囲内のアドレスを偽装した攻撃が残っても、調査はインターネット全体ではなく、顧客につながるネットワークから始められる。

送信元の確認と戻り経路の確認は別物

RFC 2267は、同じ入口で実行できる別の確認方法とも線を引いた。送信元への戻り経路が、パケットの到着インターフェースから出ていくかを調べる案である。著者らは、インターネットに経路の非対称性があるため、これを一般要件にすると問題が生じると判断した。提案の中心は、送信元プレフィックスがそのインターフェースに接続された顧客ネットワークの範囲内かどうかだった。

両者は入口でパケットを見る点は似ているが、問いが異なる。戻り経路テストはルーティングテーブルが選ぶ方向を確認する。顧客プレフィックスフィルターは、そのネットワークが回線上で使える送信元範囲を照合する。RFC 3704は後にマルチホーム網での入口フィルターを取り上げ、RFC 2827を更新した。そこで扱う厳格・実行可能・緩やかなRPF方式とそのトレードオフは別の主題であり、ここでは掘り下げない。

モバイルIPは例外の所在を示した

モバイル端末にとって正当なアドレスでも、移動先の接続網では予想外の送信元になり得る。RFC 2267はMobile IPを例に挙げた。訪問先ネットワークから出るパケットが、端末のホームアドレスを送信元に使う場合、訪問先のプロバイダーが認めるプレフィックスから外れてしまう。文書はリバーストンネルに言及し、後のRFC 2344が、外部へ送る前にホームエージェントへパケットを運ぶ仕組みを記述した。

フィルターは利用者の意図を判定しているわけではない。特定の顧客インターフェースを通ってよいプレフィックスを照合している。別の送信元を必要とする正規サービスには、その境界と整合する経路か明示的なポリシーが要る。RFCはすべてのモバイル通信が失敗すると述べておらず、例外をすべて消せとも言っていない。例外を運用ルールと突き合わせる必要を示している。

情報メモからBCP 38へ

RFC 2267は1998年1月に情報文書として公開された。2000年5月、RFC 2827は同文書を廃止し、同じ「Network Ingress Filtering」という題名のまま、ベストカレントプラクティスのBCP 38として位置づけた。骨格は変わらない。プロバイダーは顧客のパケットを入口で確認し、そのネットワークが正当に使っていない送信元プレフィックスを通さない。

文書の位置づけが変わったことと、実際にどこで導入されたかは別だ。RFC 2827は推奨慣行であり、公開されたからといって、どのルーターや顧客回線にフィルターが載ったかは分からない。RFC 2267は導入を始めたプロバイダーがあると述べるが、件数や適用率は示していない。文書、プロバイダーの方針、インターフェースに設定されたルール、実際に破棄されたパケット、調査結果は、それぞれ別の証拠である。

フィルターが約束できることには限りがある。許可集合の外にある偽装プレフィックスなら止められる。一方、攻撃者が許可集合内の別の端末を名乗ることや、正当なアドレスを使う攻撃は止められない。端末や人物、動機を識別する機能もない。破棄ログはネットワーク境界での判断を記録し、調査の入口にはなるが、送信者の告白にはならない。

歴史的な変化は、控えめだが明確だった。偽装されたアドレスを解釈する役割を被害者だけに負わせず、顧客とプロバイダーの境界に検証可能な確認点を置いたのである。BCP 38はその運用上の提案を共有する名前にした。個々の回線で実際に機能したかは、ローカルのルールが正確で、装置に入り、動作中だったかにかかっていた。

出典

  1. RFC 2267 — Network Ingress Filtering
  2. RFC 2827 — Network Ingress Filtering（BCP 38）
  3. RFC 1812 — IPv4ルーターの要件
  4. RFC 2002 — IPモビリティサポート
  5. RFC 2344 — Mobile IPのリバーストンネル
  6. RFC 3704 — マルチホーム網の入口フィルター（BCP 84）