要約

  • 10月27日付のIETF個人草案は、配布するポリシーに適用領域、所有者、作成者、言語、本文を必須とする。一方、受信側がその所有者に当該領域の規則を変える権限があるかを照会する手順は MAY だ。
  • 署名済みの荷物を受け取ることと、荷物の送り主に自分のネットワークの規則を決めさせることは別の決定である。後者の記録を残す主体は受信側だ。

到着印より先に見るべきもの

制御室に新しいポリシーが届く。形式は正しく、電子署名も検証できる。画面には所有者と適用領域が表示される。そこで「承認済み」と表示したくなる設計者は多い。しかし受信側の運用者が確認すべきなのは、送り主が名乗った肩書ではない。この領域の設定を変えてよいという権限を、受信側の誰が与えたかだ。

分散ポリシー共有モデルの個人草案は、単一のポリシーを運ぶYANGコンテナを定義する。area、language、policy-content、owner、author は必須の葉で、origin と来歴署名の葉は任意である。コンテナに入るルール本文は不透明だ。YANGの形式検査が通っても、受信先の評価エンジンがその文をどう実行するかまでは保証しない。所有者のURIも、受信先の権限台帳と照合されなければ自己申告にとどまる。

草案はこの問題を見落としていない。導入部は、複数の管理領域にまたがると発行元が対象領域のポリシーを定義する資格を持つか不明になりやすい、と記す。ところが第6.1節で、Policy Administration Point（PAP）が受け入れや配布の前にPolicy Decision Point（PDP）へ権限を照会するのは MAY とした。第6.2節の図には「Governance Authorization Check」が大きく描かれる。図面では常設の窓口に見えるが、本文では開設を実装側に委ねている。

運送状に書かれた所有者は、委任状を持っていない

PAPの役目はスキーマ検査、版管理、必要に応じた来歴確認だ。来歴の署名については関連するYANGデータ来歴草案が参照される。正しい鍵で署名されたデータなら改ざんを検出し、出所を調べられる。それでも「この鍵の持ち主が当社のこの領域を変更してよい」という許可は出てこない。受信先が管理する委任の範囲、期限、失効手段を見なければならない。

草案の著者はNMOPメーリングリストで、次のハッカソンに向けた二領域の実演を説明した。一方はRegoをOPA系PDPで評価し、もう一方はRFC 9061に基づくポリシーによって特定ノード間にIPsecトンネルを設ける計画だ。異なる言語と実行方式で同じ運搬枠組みが働けば、技術的な成果になる。各領域で誰が設置を許可したかを示さなければ、統治の成果にはならない。メールは計画を述べており、完了した実演の測定結果は載せていない。

IETF Datatrackerの状態は個人草案の I-D Exists。標準化団体が採用した規則でも、実運用で事故が起きたとの報告でもない。この限定は記事の勢いを弱めない。提案の設計段階こそ、受け入れ条件を曖昧なままコードへ落とし込む前に問いを立てられる。

撤回できる決定として残す

草案は配布プロトコルを指定しない。PAPが外部の版管理を使うことも、作成・更新・有効化・ロールバック・撤去の履歴を追記型台帳に残すことも MAY とする。受信側が実際に監査できる記録を作るなら、受領した版のハッシュ、署名鍵、所有者の申告、適用領域、地元の委任記録、許可の時刻、設置先、撤回の操作を一件として結ぶ必要がある。履歴の行数だけ増やしても、許可の根拠が欠ければ判断を再現できない。

RFC 2904は認可の機能を分けて考える足場を示す。ここで必要なのは新しい箱の名前ではなく、受信した側が自分の境界で下した決定だ。送り主の署名を、そのまま受信側の委任状として扱うことはできない。

出典