要約

  • RFC 2356 は、Mobile IP 端末の変動する気付アドレスではなく、NSID/MKID で指定される安定した SKIP 鍵の身元をファイアウォールの判断材料にした。
  • 最初の認証済みパケットから中継できても、信頼済み公開成分、nomadic ACL、現在のバインディング、往復の通過経路は事前または個別に成立していなければならない。

端末が社内にある間、アドレスと所属を重ねて考えるのは簡単だった。外へ持ち出すと、その近道が壊れる。新しいネットワークで得たアドレスは、現在の到達点については正しい。しかし、それだけでは昨日まで許可されていた端末だとは分からない。

RFC 2002 の Mobile IP は、この状況をホームアドレスと気付アドレスに分けた。前者は変わらない論理上の住所、後者は現在の接続点を示す一時的な住所である。ホームエージェントはホームアドレス宛ての通信を捕捉し、気付アドレスへ転送する。だが、私設網の境界にあるファイアウォールから見れば、外側に現れる送信元は移動のたびに変わる。

G. Montenegro と V. Gupta による RFC 2356 は、1998年6月に Informational として公表された。インターネット標準ではなく、適用範囲も限定される。対象は、保護された私設網に所属する端末が、公共インターネット上で自分のインターフェースに気付アドレスを得て、ホームエージェントや内部ホストへ接続する場面だった。別の私設網の内側から出ようとする端末は対象外である。

文書は SOCKS 5 によるアプリケーション中継と、SKIP を使う IP レベルの方式を比べた。SKIP はセッションレスな鍵管理として説明され、認証に必要な情報を各パケットに載せられた。そのため、別のセッション確立を往復してからでなく、最初の認証済みパケットを受けた時点でファイアウォールが中継を始められる。

ただし、これは「事前の信頼が不要」という意味ではない。移動端末、ファイアウォール、ホームエージェントは、認証された Diffie-Hellman 公開成分を必要とした。あらかじめ設定しておくか、証明書ディレクトリなどから取得する。省かれたのはデータ送信直前の往復であり、鍵と名前を結び付ける準備ではなかった。

提案の中心は、アドレスから鍵検索を切り離すことにある。SKIP ヘッダーの NSID が名前空間を示し、MKID がその中の身元を選ぶ。NSID 1 では、外側の送信元が気付アドレスでも、MKID に安定したホームアドレスを用いられる。NSID 8 は Unsigned Diffie-Hellman の公開成分から識別子を導けたが、認証局を使わない場合でも主体名は安全に伝える必要があった。

この識別子に対して、ファイアウォールは nomadic ACL を設定できる。意味は「どの送信元アドレスでも許す」ではない。送信元が変わっても、指定された鍵の身元として審査する、という入口である。AH、または認証機能を兼ねる ESP による検証が成功し、そのうえで宛先やサービスに対するローカルポリシーが許可しなければならない。

端末が内側へ通信を始めると、ファイアウォールは鍵の身元、ホームアドレス、観測した気付アドレスを動的に結び付ける。返信をどこへ保護して送るかが、そこで初めて分かる。単純な方式は最新の Registration Request を採用し、以前の関連付けを置き換えた。同時に複数の Mobile IP バインディングを維持するには、ファイアウォールが登録メッセージをより深く理解しなければならない。

学習した状態は経路にも依存する。要求を見てバインディングを作ったファイアウォールと、Registration Reply が通るファイアウォールが違えば、後者には判断材料がない。Mobile IP を解釈するファイアウォールなら返信から必要な身元を読み取って非対称経路に対応しやすい。しかしそれは、中継装置により大きなプロトコル上の権限を与える選択でもある。

そもそも端末が「内側」か「外側」かも自明ではなかった。アドレス範囲で推測できる場合はあるが、RFC は実環境では分類が難しいと認める。利用者の直接入力が役立つことさえ指摘した。利用者は現在の接続が社外だと知っていても、アドレス規則はそれを表せないことがある。ここで得られるのは運用上の判断であり、物理的な所在地の証明ではない。

ホームエージェント側には Traversal Extension が使われた。Registration Request と Reply に、端末からホームエージェントへ、またその逆方向へ通過すべきアドレスを載せる。複数のファイアウォールも表現できる。反対方向から届いた値の一部はヒントとして扱われる。通過点を指定することと、実際に認証・カプセル化・中継が成功したことは同じではない。

RFC は暗号チャネルの置き方も四つに分けた。公共側だけを暗号化する構成。端末とホームエージェントをエンドツーエンドで結び、ファイアウォールを中継にする構成。エンドツーエンド暗号を保ちつつ中間のファイアウォールにも認証させる構成。この場合は長期の Diffie-Hellman 共有秘密を中間ノードへ渡す必要がある。そして内外で別々の暗号関係を終端し、ファイアウォールが内容を検査できる構成である。

したがって、暗号化という一語だけでは可視性も権限も説明できない。RFC 2003 の IP-in-IP カプセル化はアドレス空間をまたいで運ぶための仕組みで、AH は認証、ESP は機密性や認証を担う。それぞれ別の問いに答える。正しく包まれたパケットが許可されるとは限らず、認証済みのパケットが最終アプリケーションまで届くとも限らない。

復路では、ホームエージェントがホームアドレス宛ての通信を捕捉し、現在の気付アドレスへカプセル化する。ファイアウォールは動的バインディングを参照し、公共側の通信を保護する。Registration Reply、バインディング、中継のログは有用だが、内部の相手が処理したことや利用者が結果を得たことまでは証明しない。

セキュリティ節はさらに、移動端末そのものを私設網の拡張境界と位置付けた。端末は DHCP や課金のために暗号化されていない公共通信も行い得るため、自らフィルタリング能力を持つ必要がある。端末が侵害されれば、正当な鍵を持つことが私設網への足場になり得る。移動しても身元を失わない設計は、侵害後の権限も失わせない危険を伴う。

RFC 2356 を現在読み返す価値は、採用状況を誇張することではない。外側アドレス、ホームアドレス、NSID/MKID、公開成分の入手元、認証結果、ACL 判断、バインディングの更新、内外分類、Traversal Extension、登録結果、中継、相手への配送、アプリケーション結果を、一つの「接続成功」に畳み込まなかった点にある。