GDOI: 鍵サーバーがデータパス上にない理由

グループ鍵サーバーはポリシーと鍵をメンバーに配布し、メンバー自身がトラフィックを保護する。この一文は、設計がコントローラーを保護パケットごとの中継装置として扱うまでは単なる形式に見えるが、そうなるとトポロジーには不要なホップが増え、トラフィック経路は状態を配るだけの装置に依存してしまう。鍵サーバーがどこにあり、データがどこへ流れるかを述べることは二つの異なる図であり、GDOI はまさにその違いを中心に作られている。これを逆にすると監視する対象と拡張する対象が変わるため、小さなモデリング誤りでは済まない。以下の節はプロトコル自身の区分に従う。

二種類のセキュリティ状態

RFC 6407 は、メンバーがポリシーと鍵素材を要求するプル交換と、承認されたメンバーにポリシーと鍵更新を配布するプッシュ交換を定義している。どちらもセキュリティアソシエーションを管理する。どちらもアプリケーションのデータストリームではないため、交換の成功は制御チャネルが機能したことだけを示す。メンバーは正常に登録し、有効な鍵を持っていても、データポリシーが誤っていればトラフィックの保護や転送に失敗しうる。どちらの交換がどちらを運ぶかを知れば、この二つの障害はまったく別物に見える。

標準はまた、鍵更新メッセージを保護する再鍵セキュリティアソシエーションを、メンバーがトラフィックをどう保護するかを記述するデータセキュリティアソシエーションとは別に名付けている。

図ではなく交換を追う

各メッセージが何のためのものかを見る。登録はどのメンバーが問い合わせているかをコントローラーに伝えて状態を確立し、再鍵はポリシーや鍵が変わったことをメンバーに伝え、その後、保護されたアプリケーショントラフィックが導入済みのデータセキュリティアソシエーションを使ってメンバー間を流れる。コントローラーのアドレスは最初の二つに現れ、三つ目にはまったく現れる必要がない。

だからこそ 物理的な隣接で描いたインターフェース図はここでは誤解を招く。コントローラーのインターフェースは制御の源であり、暗号化パケットすべての次ホップでは自動的にはならない。

残す価値のある三つの記録

メンバーの認証済み登録と到達できる制御源、以降の鍵更新を届ける経路、保護されたアプリケーショントラフィックを運ぶルートと接続を書き留める。三つの記録、三人の所有者、そしてどれか一つが壊れても症状は異なる。両方の記録がなければ、登録しても更新を一度も受け取らないメンバーは、古いポリシーで登録したメンバーと見分けがつかない。

これらは誰かの記憶ではなく、設定のそばに置く。メンバーシップの変更はまれであり、必要になるころには理由はいつも失われている。

インターフェース、サービス接続、処理パス

サービスベースのゲートウェイには、物理アンダーレイのアドレスがローカルなサービス接続と同じではなく、トラフィックが IPsec 処理パスにどう到達するかをプラットフォームの実装が決めるという、さらなる違いがある。エラーメッセージがサービスインターフェースの規則に触れたからといってサービスを物理インターフェースへ移したり無関係な変換を加えたりするのは、修正の衣を着た推測である。

サービス接続がトラフィックをどう受け取るかはプラットフォーム自身の文書を読む。プロトコルが標準でも仕組みはベンダー固有である。

標準化されたプロトコルメッセージもベンダー間の互換性を確立しない。二つの実装が相互運用すると仮定する前に、必要な機能、ポリシーとアソシエーションの属性、認証方式、そして正確なプラットフォームとリリースを比較する。

制御の可用性とデータ転送は別々の確認

通常運用、メンバーシップ変更、鍵更新それぞれについてコントローラーへの到達性を計画する。導入済みの状態で成功するアプリケーション交換は、次の登録や再鍵がメンバーに届くことを証明せず、その差は通常、数時間後に新しいメンバーを受け付けなくなるトンネルとして現れる。動作しているセッションだけでなく、新しい登録を試す。

次にコントローラーを外した状態で転送を別々に試す。二つの確認、二つの結果、そしてどちらの半分が壊れているかについてのはるかに短い議論。