要約

  • RFC 5213 はモビリティ信令を端末からネットワークへ移す。MAG が接続を検知し、端末の代理として PBU を送る。成功 PBA は、認証・認可された代理の申告を LMA が受理したことを示す。
  • それだけでは、接続検知が今も正しいこと、MAG 側トンネルと転送が完成したこと、端末が RA を受信してアドレスを利用できること、アプリケーション通信が継続したことは示せない。

発言しない端末を前提にした仕組み

Proxy Mobile IPv6 の特徴は、端末にモビリティ機能を要求しない点にある。管理されたドメインの中で、ネットワークが端末を識別し、プロファイルを取得し、移動に伴う登録を代行する。端末から見れば、新しいリンクでも通常の IPv6 手順を使っているだけでよい。

Local Mobility Anchor（LMA）はホームネットワークプレフィックスのトポロジ上の基点になる。Mobile Access Gateway（MAG）はアクセス端で端末の到着を検知する。MAG は端末識別子とポリシーを得ると Proxy Binding Update を送り、LMA は受理時にバインディングキャッシュを更新し、プレフィックスと MAG を結び付け、自分側のトンネルと経路を準備して Proxy Binding Acknowledgement を返す。

成功 PBA は重要な制御面証拠だ。LMA が所定の相手を認証し、その MAG に対象端末を代理する権限があると判断し、アンカー側状態を変更したことを表す。問題は、その証拠がしばしば端末の同意や現場の事実、さらには通信結果まで証明したかのように扱われることにある。

このプロトコルで端末は PBU に署名しない。接続を見た主体、識別子を割り当てた主体、代理権を決めた主体、状態を変更した主体が分かれている。これは欠陥ではなく、代理モデルそのものである。

正しい署名でも、観測内容まで正しいとは限らない

RFC 5213 は LMA と MAG の間に信頼関係を要求し、PBU/PBA の保護と IPsec の実装を求める。また LMA は、その MAG が特定の端末について更新を行えるかを確認しなければならない。これにより、送信者、メッセージ完全性、代理権の範囲を検証できる。

しかし接続検知そのものは仕様の外側にある。無線アソシエーション、回線イベント、アクセス認証など、技術ごとの仕組みが MAG に到着や離脱を知らせる。PBU はその観測結果を運ぶが、同じ現場を独立に再観測するわけではない。

RFC のセキュリティ考察は、この差を曖昧にしない。侵害された MAG が、実際には存在しない端末接続を申告できる。対策の一例は、信頼できる別の主体が実接続を確認してから LMA が更新を受け入れることだが、その方式は仕様範囲外とされる。代理の認証と、物理的前提の確認は別々の証拠である。

有効な資格情報は「誰が語ったか」を強くする。語られた情景を常時真実にするものではない。端末がすでに離れた、識別子の対応を誤った、古いイベントが遅れて届いた、といった可能性は、暗号だけでは除けない。

成功応答の後に MAG の仕事が始まる

LMA は PBU を受理すると、バインディングキャッシュ、プレフィックス、アンカー側トンネル、経路を設定し、成功 PBA を返す。MAG はその PBA を受信して認証した後、自分側のトンネルを作り、端末向け転送を設定し、アクセスリンクに Router Advertisement を送る。

したがって、LMA の成功ログは処理全体の中点に近い。新しい MAG が応答を受け取れなかったり、経路設定に失敗したりすれば、アンカー側の正しい状態だけが残る。監視画面がその時点でハンドオーバー完了を宣言すれば、送信側の約束を受信側の実行に置き換えてしまう。

さらに、端末側では RFC 4861 の近隣探索、RFC 4862 のアドレス自動設定と重複アドレス検出が動く。PMIPv6 は同じホームプレフィックスを保つことで移動を隠すが、RA の到達、アドレスの有効性、デフォルトルーター、双方向パケット、アプリケーションセッションは観測しなければ分からない。

GRE Key や後続拡張はトンネル識別や運用機能を高める。それでも「トンネルが定義された」と「端末が通信できた」は同義にならない。識別精度が上がっても、結果の証明は別に残る。

バインディングキャッシュは位置センサーではない

LMA のキャッシュは、パケットをどの MAG に送るかを決める。その意味で実行系の権威ある台帳である。存続時間があり、更新や登録解除によって状態が変わる。

だが存続時間内という事実は、受理済み申告がプロトコル上まだ失効していないことを示すだけだ。LMA が端末の電波や物理ポートを連続監視しているわけではない。旧 MAG の離脱と新 MAG の接続が前後し、メッセージ損失や遅延が起きれば、現在値の背後に競合する観測が残る。

障害時には、最終キャッシュ値だけを見るのではなく、証拠の切れ目を探すべきだ。接続イベントはいつ誰が観測したか。識別子はどう得たか。アクセス認証と代理認可は一致したか。PBA は新 MAG に届いたか。転送と RA は実行されたか。旧経路はいつ消えたか。最初に片方向通信が失敗した地点はどこか。

これらを一つの「完了時刻」に圧縮すると、責任を追える時系列が失われる。

代理ハンドオーバーの受領証を作る

運用受領証には、接続イベントの方式・観測者・時刻・確度、端末識別子の由来、アクセス認証、MAG の資格情報と端末ごとの権限、PBU のシーケンスと存続時間、独立確認、LMA のバインディング世代・プレフィックス・経路・トンネル、MAG が認証済み PBA を受領した時刻、MAG 側転送、RA の送受信、端末のアドレス/DAD 状態、双方向試験、アプリケーション結果、旧状態の撤去を結び付ける必要がある。

これは BTW の編集上の提案であり、RFC 5213 が要求する新しいメッセージではない。目的は、制御面、接続面、端末面の証拠所有者を一つの緑色ランプに潰さないことだ。

恒路の running-code 優先という考え方を適用すれば、記録は実行系を導くために重要だが、記録が現実全体になることはない。MAG の代理権は正当でも有限であり、LMA の受理は現実の一部であって全部ではない。次の事実は次の実行主体から受け取らなければならない。

優れたシステムは、端末が語らなかったことを隠さない。誰が代わりに語り、何を根拠に許され、どこから先はまだ証明されていないかを示す。

出典

  1. RFC 5213 HTML
  2. IETF Datatracker：RFC 5213
  3. RFC 5213 情報ページ
  4. RFC 5213 文書履歴
  5. RFC 6543：複数インターフェースの MAG 対応
  6. RFC 7864：PMIPv6 基本仕様の更新
  7. RFC 3775：IPv6 モビリティ
  8. RFC 4283：モバイルノード識別子オプション
  9. RFC 4832：モビリティ関連用語
  10. RFC 4861：IPv6 近隣探索
  11. RFC 4862：IPv6 ステートレスアドレス自動設定
  12. RFC 4301：IP セキュリティアーキテクチャ
  13. RFC 4303：Encapsulating Security Payload
  14. RFC 4306：Internet Key Exchange
  15. RFC 2473：汎用 IPv6 トンネル
  16. RFC 5845：PMIPv6 の GRE Key オプション
  17. RFC 6463：実行時 LMA 割当て
  18. RFC 8127：PMIPv6 QoS オプション
  19. Heng Lu：running-code の優先