要約

  • RFC 3182はPOLICY_DATA内のAUTH_DATAに、ポリシー・ロケータ、資格情報、署名、エラーを分けて格納した。どのフィールドも単独では資源を許可しない。
  • 身元情報はエンドツーエンドで不変ではない。ユニキャストでは利用者ロケータを引き継ぎながら現在ノードの資格情報に替わり得る。マルチキャストのアプリケーション身元情報は最初の要素またはPDPが選んだ要素になり得た。
  • 認証済み主体にも、認可、PEPによる実行、容量、経路全体の状態、パケット処理、アプリケーション結果が別途必要だった。

ロケータから許可までは一足ではなかった

RSVPは「資源があるか」と「この要求者に使わせてよいか」を別々に扱った。RFC 2205では前者がadmission control、後者がpolicy controlであり、双方が肯定されなければ予約は成立しない。

2001年10月にProposed Standardとして公開されたRFC 3182は、後者へ渡す身元材料を構造化した。AUTH_USERは利用者、AUTH_APPはアプリケーションを表す。POLICY_LOCATORはポリシーの所在、CREDENTIALはテキスト識別子、Kerberosチケット、X.509またはPGP証明書を運び、署名は前段の属性を保護した。

RFC 2753では、判断を行うPDPと、判断を実行するPEPが分離される。PDPはディレクトリ、認証、会計、時刻、グループ、ローカル設定を参照できる。肯定されても、容量制御が失敗することはある。ロケータは規則への住所であって、帯域を割り当てる委任状ではなかった。

RFC 3182はRFC 2752のコードポイントとエラー・フィールド幅を訂正して置き換えた。二つの配備世代ではない。Datatrackerの2026年更新も新しい版を意味しない。検証済みerratumが記録されているためである。

Erratum 2958はKerberos処理を正す。サーバはチケットをKDCへ送ってセッション鍵を得るのではなく、チケットから鍵を取り出して利用者を認証する。この訂正を無視すれば、固定されたRFC本文の誤りを運用事実として再生産する。

三種類の資格情報は三種類の限界を持った

単純方式はASCIIまたはUnicodeのログイン名を運ぶ。アプリケーション例はvic.exeという実行ファイル名だった。RFC自身が、安全に認証可能な資格情報を含まず、より弱いと認めている。ファイル名は、実行中バイナリ、発行者、所有者、完全性を証明しない。

Kerberosは次のRSVPノードまたはPDP向けのチケットと、対応するrealmの仕組みを必要とした。そこで主体を認証できても、次の管理ドメインにおける資源利用権まで持ち運ぶわけではない。

公開鍵方式は証明書と署名を加えた。秘密鍵の保護、信頼するCA、証明書と署名の検証が必要である。署名が正しくても、失効状態、組織からの委任、ローカル・ポリシー、実際に送信するプロセスは別問題だった。

後のRFC 4230は、公開鍵処理の帯域・計算コスト、失効確認の追加機構、Kerberosで扱う身元の不完全な秘匿、認証だけでは認可に足りない場合を指摘した。強い資格情報は一つの受領証を強くするが、後続判断を代行しない。

ホップごとに話者が変わり得た

ユニキャストの利用者ポリシーでは、前ホップのロケータをコピーしながら、資格情報は現在のネットワーク・ノードの身元を表す。検索対象の利用者と、現在メッセージを保証する主体は同一とは限らない。

マルチキャストでは、利用者ロケータも資格情報も現在ノードを表す。アプリケーションの身元情報は、ユニキャストでは前ホップからコピーされる一方、マルチキャストではメッセージ内の最初の要素、またはPDPが選んだ要素になり得る。

したがって最終値は全参加者の名簿ではない。「最初」は順序であり、「PDPが選択」はポリシー判断である。どちらも集団代表の根拠ではない。

複数のAUTH_DATAが存在でき、ポリシー対応ノードは内容を変更できた。監査には入力、出力、変更者、信頼ドメイン、security association、理由が要る。最後の名前だけを保存すれば、合法な変換と不正な置換さえ区別できなくなる。

通過は認可の証拠ではなかった

すべてのRSVPノードがポリシーを理解する必要はなかった。RFC 2753は境界の一部だけでポリシーを実行できるとし、RFC 3182はpolicy-unaware routerがデータを無視して処理を続ける場合を示した。

段階導入には有効だが、通過した事実は評価済みを意味しない。ポリシー対応境界ではPEPがPDPへ問い合わせ、否定なら拒否、肯定ならRSVP処理を継続する。それでも後続ノードの容量、異なる規則、スケジューラの状態は未確定である。

「受信」「資格情報検証」「認可」「ローカル実行」「サービス観測」を一つのsuccessへ圧縮してはならない。policy-unaware nodeの沈黙は承認ではない。

エラーは失敗箇所を示した

定義された理由には、未対応資格情報、権限不足、資格情報期限切れ、身元変更がある。PDPが検証できなければpolicy control failureをPEPへ返し、可能なら詳細をエラー要素に入れる。

この区別は有用だが、EXPIRED_CREDENTIALは全予約状態の削除を証明しない。IDENTITY_CHANGEDはアプリケーションが通知を受けたことを証明しない。あるマルチキャスト枝のエラーは他枝の結果ではない。

現在のIANA RSVP ParametersはPOLICY_DATAクラスとpolicy-control errorを記録する。番号の調整は、実装、配備、個別ルータの判断を証明しない。

完全性は正当性を作らなかった

RFC 3182は、全体メッセージが保護されない場合にPOLICY_DATAのintegrityを推奨した。特定のsecurity association内で改変やreplayを検出できる。

RFC 4230は、外側のRSVPメッセージと内側のポリシー要素の保護範囲を分けた。ノードやPDPは設計上データを変更でき、第一ホップ以降に利用者情報が漏れ、ルータ間の一般的な機密性は提供されないとした。

検証すべきは、バイトが保護されたか、どの主体が認証されたか、その主体にどの委任があったか、の三つである。暗号は最初の二つを支援できるが、三つ目の正当性や現在性を決めない。

RFC 2753は事業者境界で双務契約に従ってポリシー・オブジェクトを置換する場面を想定した。RFC 4230はroamingの標準化された認可データと合意済みQoS認可方式の不足を指摘した。身元情報は越境できても、権限はローカルだった。

防御可能な記録は変換前後を残す

最初に、主張された身元と生の要素を保存する。次に資格情報種別、検証者、得られたprincipal、realmまたは証明書chain、integrity範囲を残す。その後でロケータ、ポリシー版、PDP判断、PEP実行、容量、RSVP状態を記録する。パケットとアプリケーションは別の観測を必要とする。

マルチキャストでは全入力の身元情報、順序、選択者、捨てられた要素を残す。最後の一件だけでは、それが最初だったのか、代表だったのか、都合よく選ばれたのか分からない。

Lu Hengの象徴・権力・実行を分ける視点は編集上の分析であり、RFC著者への帰属ではない。RFC 3182は名前をRSVPへ運んだ。誰が判断でき、どこで実行され、何が起きたかは、running systemが別に証明しなければならなかった。

出典と限界

中心資料はRFC 3182本文、RFC Editor記録、Datatracker、API記録、Erratum 2958、旧RFC 2752である。周辺仕様はRFC 2205、2750、2753、2747、4230、4094、後発の4923。歴史的資格情報はRFC 1510と2459、現在の登録表示はIANA RSVP Parametersによる。

分析はLu Hengのreality layersとrunning-code primacyを参照した。18資料は2026年10月2日Asia/Shanghaiで凍結された。名指しの実装、運用者、利用者、フロー、事故、配備、相互接続試験、サービス結果は示さない。標準状態、番号、資格情報、PDP承認、ローカル予約は各自の範囲しか証明しない。