要約

  • 顧客は許可済み CE 間の接続を要求できるが、PE 間の経路、収容資源、接続制限、コアの開示範囲はプロバイダーが管理する。
  • サービス契約に記載された CE、制御通信で認証された相手、装置に設定されたクロスコネクト、顧客が確認した通信結果は、同じ証拠ではない。

注文票に書かれていたのは二地点だけだった

顧客が「この CE とあの CE を結んでほしい」と要求する。画面上は顧客自身がネットワークを組み替えているように見える。だが、注文票にプロバイダーの内部経路まで指定する権利は含まれていない。

RFC 5253 はこの境界を明示する。L1VPN の接続トポロジー、つまりどの顧客端を結ぶかという要求は顧客側にある。一方、CE 間接続の中央にある PE-to-PE 区間はプロバイダーが完全に制御する。CE がプロバイダー網内の経路を ERO で指定しようとすれば、PE はそれを拒否する。

顧客側の制御が偽物なのではない。プロバイダー側の制御が無制限なのでもない。両者は対象が違う。顧客は許可された端点集合から意図を示し、プロバイダーは契約と内部方針に従って、その意図を実行可能な光パスへ変換する。

問題は、運用画面がこの二層を一つの「provisioned」に畳み込むときに起きる。要求を受け付けたこと、内部経路を選んだこと、資源を確保したこと、クロスコネクトが成立したこと、顧客通信が届いたことは、それぞれ別の出来事である。

Basic Mode は情報交換を減らすが、責任まで消さない

Basic Mode では CE と PE の間でルーティング情報を交換しない。CE は遠隔 CPI を設定やディレクトリなど L1VPN 固有の手段で知る。プロバイダー網内ではルーティングが動き、PE 間で VPN メンバー情報を交換することもある。

この設計は顧客とコアの結合を小さくする。顧客は内部 LSDB や経路表を持たなくてよい。プロバイダーも顧客ルーティングをサービス成立の前提にしなくてよい。しかし、見えないものの責任がなくなるわけではない。

入口 PE は、要求された端点が同じ L1VPN に属するか、どの PIT を使うか、どの接続制限が適用されるかを判断する。その後、オンデマンド計算、事前計算、事前設定済みセグメントのいずれかを選べる。PCE や管理システムが計算を担う場合もある。

顧客から見える「接続完了」は、これらの選択内容を示さない。だからこそプロバイダー内部では、顧客要求から最終装置状態までを結ぶ来歴が必要になる。秘匿すべき経路情報と、失敗時に説明できる監査証拠は両立する。

パスキーは秘密を守るが、稼働証明にはならない

同じ PE 対の間に複数の事前計算済み区間が存在し得る。プロバイダーは VPN 単位、あるいは接続単位で利用区間を割り当てられる。Path Key ID を CE に渡せば、内部の経路を見せずに特定の機密区間を参照させることもできる。

これは良い抽象化である。顧客は必要な結果を注文し、プロバイダーはコアを柔軟に設計できる。ただし、抽象化された識別子から推論できる範囲は狭い。

パスキーが正しいことは、その区間が現在も同じ物理資源を使っている証拠ではない。RSVP-TE の応答は、どの契約版と方針版で許可されたかを示さない。保護属性が付いていても、バックアップが共有リスクから独立しているとは限らない。顧客に返すべきなのは秘密の地図ではなく、購入した結果に対応する検証可能な測定である。

プロバイダー側では、要求 ID、方針版、計算結果、選択区間、予約、両端の設定読戻しを一つの証拠鎖にする。顧客側では、合意した端点、暗号学的な相手確認、品質測定、障害時の復旧観測を保つ。二つの記録は同じである必要はないが、同じ接続を指していなければならない。

秘密は左右対称ではない

プロバイダーはコアを顧客から隠しやすい。PE から CE へルーティング情報を配らず、RRO の内部情報をフィルターし、Notify の内部アドレスを PE のアドレスに置き換え、機密区間をパスキーで表現できる。

顧客側は同じ条件ではない。RFC 5253 は、プロバイダーが少なくとも CE のアドレスと場所を知ると記す。ポートを正しい VPN に所属させ、許可された組合せだけを結ぶには、その情報が必要だからだ。顧客網の残りの構造は隠せても、接続点を完全に隠すことはできない。

この非対称性を「仕様だから問題なし」で終えるべきではない。CE の所在地は、冗長性、重要拠点、事業活動の集中を推測させる場合がある。運用に必要な情報だからこそ、目的、閲覧者、保存期間、二次利用の制限を定める必要がある。

逆に、顧客はプロバイダーの内部地図を見る権利がなくても、契約結果を確かめる権利は失わない。経路を明かさずに、分離性、保護範囲、性能、障害復旧の証拠を提示できる。秘密と説明不能は同義ではない。

契約上の識別と信号ごとの認証を混ぜない

新しい CE をサービスへ追加するとき、その主体は契約の一部として識別され、制御チャネルが設定される。RFC 5253 は続けて、RSVP-TE の認証手続を使わなければ、その制御主体は認証されないと述べる。

この一文は運用モデルを分解する。契約は誰が利用すべきかを示す。設定はどのアドレスやチャネルがその CE を表すかを示す。認証は、あるメッセージを送った者が資格情報を保持していたかを示す。整合性は途中改変を検出する。認可は、正しい相手から来た要求でも実行可能かを決める。

「登録済み顧客」という一つの状態では足りない。契約終了後も古い鍵が生きているかもしれない。正しい CE が禁止された相手への接続を要求するかもしれない。認証された信号の後で、誤ったクロスコネクトが作られるかもしれない。

物理分離されたチャネルについても、仕様は慎重である。専用なら安全とみなし得るが、顧客は IPsec などを望む場合があり、その手段は利用可能でなければならない。共有チャネルでは保護を用意するだけでなく強制すべきである。配線図は暗号学的な受領証ではない。

拒否した場所まで測らなければ、制御コストは見えない

接続制限は入口 PE にも出口 PE にも置ける。どちらでも最終的な禁止は実現できる。しかし出口で初めて拒否すれば、許可されない要求がコアを横断し、各ノードで処理と一時状態を発生させる。RFC 5253 はその信号作業が無駄になると指摘する。

したがって、拒否件数だけをセキュリティ成果にしてはならない。何段目で拒否したか、どれだけの状態を作ったか、解放まで何秒かかったか、正規要求と競合したかを測る必要がある。

入口で判断できる安定した資格条件は入口へ寄せる。出口の検査は防御の重層化として残す。正しい拒否を、最も高価な拒否にしてはいけない。

「保護あり」には組合せの限界がある

Basic Mode は PE 間区間、リンク、制御チャネルに GMPLS の回復機能を使える。しかし、リンク保護要求で CE-PE 部分だけ、または PE-PE 部分だけを独立に保護することはできない。エッジはリンク回復、コアはセグメント回復という組合せも同じモデルでは表現できない。異なる PE への二重接続による CE 間回復は範囲外である。

販売上の「protected」は、故障単位に分解しなければならない。アクセス線、コア区間、装置、局舎、共有リスク、二重帰属のどこまでを含むのか。保護要求の受付、予備資源の独立性、切替処理、装置読戻し、顧客通信の復旧は別々に観測する。

信号が緑に戻った時刻と、顧客アプリケーションが回復した時刻が違うことは珍しくない。二つを同じ SLA 時計で測れば、誰の制御が遅れたのか分からなくなる。

専用の光でも宛先を間違えられる

光接続は共有パケット媒体より盗聴や挿入が難しく、一つの L1VPN に専用化された接続は有効な隔離をもたらす。それでも RFC 5253 は誤接続を明確な脅威として残す。間違ったクロスコネクトは、専用資源のままデータを誤った利用者へ届け得る。

同一 L1VPN の CE に接続先を限定する方針は重要である。しかし方針の判定は光の行き先を直接観測していない。機密性が高い顧客は、自らの層でも IPsec などを適用すべきだと RFC は述べる。

現実の証拠は両側から作る。プロバイダーは両端のクロスコネクト、資源、保護状態を読み戻す。顧客は遠端を認証し、実データを送って到達を確かめる。プロバイダーの ACK だけで顧客結果を認定せず、顧客の ping だけで内部経路の正当性を認定しない。

二つの権限を一つのランプに戻さない

接続記録には、契約版と対象 CE、制御チャネル資格情報、要求された端点と属性、入口方針、内部区間と計算版、資源許可、両境界の設定読戻し、保護範囲、開示・秘匿したトポロジー情報、顧客側の暗号と実通信結果を別欄で残す。

顧客はコア地図を持たなくても異議を申し立てられる。プロバイダーは地図を公開しなくても、顧客要求が内部経路権限へ拡張されなかったことを説明できる。必要なのは、障害前に合意した証拠の接点である。

RFC 5253 が守ったのは、曖昧な共同統治ではない。端点の意図と経路の実行を分ける境界である。その境界を見える形で運用することが、Basic Mode を単なる秘密の光路ではなく、説明可能なサービスにする。

Sources