要約

  • RFC 5164 はサービス固有の意味を上層に残し、共通層には不透明なペイロードの発見・運搬・保護を担わせた。
  • 信頼済みピアから完全なバイト列が届いても、そのピアが対象端末へ当該コマンドを出す権限や、ハンドオーバーの成功までは証明されない。

受信側が見たのは、正しい鍵で保護され、改変されず、リプレイ窓にも抵触しないメッセージだった。トランスポートの台帳は閉じている。だが中身が「近隣ネットワークの情報」ではなく「無線動作を変えよ」という指示なら、必要な台帳はもう一冊ある。

RFC 5164 は 2008 年の Informational 文書であり、MSTP という完成した線上プロトコルを定めたものではない。IEEE 802.21 の Media Independent Handover を動機に、異なるリンク技術をまたぐ支援情報の交換に共通する問題を整理した。

設計図では、Information、Event、Command などのサービス固有シグナリングが上にあり、IP の上に共通の Mobility Service Transport Layer が置かれる。トランスポート・ヘッダーの後ろは不透明なサービス・ペイロードで、MSTP はその意味を検査しない。必要な情報は利用者が与え、内容の定義は IETF 以外の標準化主体が担う場合もある。

これは責任の空白ではない。意味を知る層へ判断を残すための境界である。

共通化すべきものと、共通化してはいけないもの

共通層に向くのは、ピア発見、セキュリティ関連付け、完全性、機密性、リプレイ対策、配送、断片化・再構成、多重リンク受信といった、サービス意味を読まずに検証できる機能だ。

一方、コマンドの対象、発行者の権限、適用可能な状態、期限、競合する命令の優先順位、実行後の成功条件はサービス固有である。これらをトランスポートへ吸い上げれば、共通層が全サービスの政策エンジンになる。逆に何も検査せず上へ渡せば、保護された誤命令が最短経路で実行面へ届く。

適切なのは二段階の拒否だ。意味に依存しない安価な検査を共通層で行い、意味と権限を理解する検査をサービス境界で行う。どの層が何を拒否したかを別々に記録する。

三サービスは同じ SLA を持たない

RFC 5164 は Information Service、Event Service、Command Service を例示する。Event と Command は環境変化や指示を扱うため数百ミリ秒間隔が想定された。Information は新しいネットワークを訪れたときに交換され、時間や日単位の間隔もあり得る。

サイズも違う。能力発見要求は約 30 バイト、典型的な Event/Command は 50〜100 バイト、Information 応答は通常 64 KB 未満だが超えることもある。小さく期限の厳しい命令と、大きく分割が必要な情報を一つの平均遅延で管理すれば、どちらの失敗も見えなくなる。

短命の信頼できる接続は確立遅延を払う。長命接続は事前準備と状態維持を払い、関係の安定を仮定する。コネクションレス方式は準備を減らすが、信頼性との組合せを設計し直す。サービス側で受領確認する案と、下位トランスポートの信頼性へ任せる案は、どちらもサービス権限を証明しない。

発見結果は権限証明書ではない

ノードは端末へ固定設定できる。DHCP や Router Discovery のような別の設定交換で通知できる。端末が動的に探索することもできる。RFC 5164 はサービス・ノードの場所を仮定せず、管理境界を越える発見を要求する。

そのため速度だけでなく、なりすまし防止、実行時点、情報の有効期間が問題になる。固定値は古くなる。プッシュ元は対象サービスの権限主体とは限らない。動的探索で見つかった相手は、あるサービスを提供できても、別の Command を発行する権限を持たないかもしれない。

文書は AAA や SEND に由来する既存の信頼関係を再利用する考えを示す。同時に、訪問端末へサービスを提供するネットワーク側主体は通常、権限を証明すべきだと述べる。相互認証は鍵の保有者を示す。サービス権限は、その保有者に許された動作を示す。両者を一つにしてはならない。

経路が変わっても取引を見失わない

要求が現在のリンクから出て、応答が新しいリンクへ届く場合がある。トランスポートは複数リンクから受け取り、MSTP 利用者が同じセッションや取引に属する情報をまとめる。必要なら IP モビリティ機構がセッション継続を支える。

従って、同じインターフェースや同じ送信元アドレスは取引の条件ではない。反対に、見慣れた経路も正しい応答の証拠ではない。期限付き取引 ID、サービス ID、信頼コンテキスト、要求・応答リンク、認可判断、処理結果を一続きに残す必要がある。

匿名性は障害解析と両立できる

移動支援メッセージはセル間の移動を暴露し、将来位置の予測にも使われ得る。RFC 5164 は機密性と完全性、セキュリティ関連付け時の可能な限りのアイデンティティ保護を求める。加入資格だけを知るローカルネットワークに、真の身元を追加開示する必要はないという例も示す。

共通 ID はログ結合を簡単にするが、異なる訪問ネットワークを恒久的な行動履歴へ変える。短期取引を結ぶ鍵と、人を長期追跡する鍵は別物である。保存期限まで含めて設計しなければならない。

文書化は採用ではない

RFC 5164 は既存プロトコルの転用と新規開発のどちらも選ばなかった。現実的な性能目標を、過去の IETF 経験と実現可能な配備から作るべきだとした。問題を定義した事実は、実装、採用、運用権限の証明ではない。

共通仕様は相互運用に必要な最小事実にとどめ、意味と実行判断は結果を負うローカル境界に残す。この節度こそ、不透明なペイロードを安全に扱う条件である。

出典