要約

  • RFC 3318では、インストールされるポリシーのロール組合せに*を置き、必須ロールを共有しながら追加ロールが異なる複数のインターフェースを一つの規則で扱えた。
  • ただし複数一致の優先順位は自動ではない。競合はPDPが解決し、未解決のまま届いた場合はPEPが拒否すべきで、装置が独自に合成してはならなかった。

ネットワーク設定を眺めると、重複はすぐ見つかる。同じ処理を多数のポートに書けば、行数も更新作業も増える。そこで共通部分を一度だけ記述する抽象化が求められる。ところが抽象化によって生じる重なりは、行数ほど目立たない。RFC 3318は、その見えにくい負債をアスタリスク一文字に集約した。

この文書はCOPS-PRで共通に使うFramework Policy Information Baseを定義した。Policy Decision Point（PDP）がポリシーを決め、Policy Enforcement Point（PEP）が装置側で受け入れ、SPPIがProvisioning Classとそのインスタンスを表現する。RFC 3318はロール、能力セット、状態の版、制限、エラーという共通語彙を与えた。

ロールはインターフェースの機能や性質を表す文字列だった。financeやmanager、バックボーン用、ファイアウォール用といった名前を付けられ、一つのインターフェースが複数のロールを持てた。ポリシー側のRoleCombinationと装置側のロール集合が一致すれば、そのポリシーが適用対象になる。これにより中央側は、ベンダー固有のポート名を直接知らずに済んだ。

集合の表現には厳密な形があった。比較は大文字と小文字を区別し、組合せはUS-ASCIIの辞書順で並べる。a+bは正しいが、b+aは別の集合ではなく、同じ集合の不正な表記である。ロールを持たない場合はnullを使う。正規形があるから、両端は同じ集合を同じバイト列として扱えた。

再利用を大きくしたのが*だった。installまたはinstall-notifyのクラスで*+a+bと書けば、aとbを含み、それ以外のロールをゼロ個以上持つインターフェースに一致する。星印そのものをインターフェースのロールとして報告することはできず、ロール名の途中で文字列を曖昧検索する記号でもない。RFCの例では*+b+e+gがa+b+c+e+f+gに一致する。

三つのインターフェースが共通してAとBを持ち、さらにR1、R2、R3をそれぞれ持つなら、*+A+Bの一行で三つを覆える。余分なロールだけが違う同一ポリシーを三回送らずに済む。運用意図も「AとBを持つものすべて」と短く表せる。

しかし、包含関係は優先順位ではない。RFC 3318は、一つのインターフェースに複数のワイルドカード付き組合せが一致し得ると明記した。複数一致が必ず競合するわけではない。別の属性を扱う規則なら共存できる。問題は、同じ処理に両立しない値を与える場合である。

その裁定者はPDPだった。PDPは送信前に競合を解消するよう努める。PDPの誤り、あるいは装置固有の制約によって競合する複数ポリシーがPEPへ届いたなら、PEPはインストールを拒否し、エラーを返さなければならない。装置が近道として勝手に優先順位を作る余地は残されなかった。

文書中のfinanceとmanagerの例は、責任の所在を具体化する。最初は二つのインターフェースがfinance、一つがmanagerである。財務担当者が管理職になれば、対象インターフェースはfinance+managerという新しい組合せを報告する。PDPはmanagerを優先してもよいし、財務管理職向けにDSCP 7という第三のポリシーを作ってもよい。

重要なのは、既存二つのポリシーからPEPが新しい答えを合成してはいけない点だ。装置側に任せれば、同じ入力でもメーカーごとに異なる結果になり得る。PDPは最終処理を説明できなくなる。明示的な拒否なら失敗を調査できるが、暗黙の合成は成功したように見える権限移動になる。

ロール変更にも時間順序があった。PEPは最初のfull stateでロール組合せとインターフェースの関連を報告する。PDPがunsolicited decisionで関連を変えた場合、PEPは処理成功を報告してから、開いている各contextの更新full stateを送る。失敗したなら失敗報告だけを返す。PDPは成功前に新状態を前提にできない。

その移行中には、古いロール関連に基づくポリシーが届く可能性もRFC自身が認めている。つまり「managerになった」という属性変更と、「managerを含む全ポリシーが再計算・受理・実行された」という事実は別である。RFC 3084のrequest、decision、reportと、RFC 3159のPIBモデルが、その間に複数の受領証を置いた。

通信の保護だけでは意味の競合は解けない。RFC 3318は設定可能な情報の誤設定が深刻な結果を生み得ると警告し、PDPとPEP間の保護を求めた。認証は二つのポリシーを誰が送ったか示し、暗号化は内容を隠せる。それでもfinanceとmanagerのどちらを優先するかは決められない。

2016年、IESGはRFC 3318、COPS-PR、SPPIをHistoricへ移した。理由には導入の限定性と、ネットワーク管理作業がNETCONFとYANGへ移ったことが挙げられた。したがって、この仕組みが広く運用されたと断言することはできない。しかし、抽象化と裁定を分離した教訓は残る。

ワイルドカードは規則数を減らせるが、判断数までは減らさない。複数一致を意味に変える権限はPDPにあり、意味が確定しないときのPEPの正しい行動は拒否だった。RFC 3318の歴史的価値は、短い設定を「決定済みの設定」と取り違えなかった点にある。

出典：RFC 3318、RFC 3084、RFC 3159、2016年のIESGステータス変更。