要約

  • RFC 5224 は Command Code 314、Application-Id 16777243、OMA vendor space の Policy-Data AVP を登録する。これらは message を分類するが、入力の正しさや decision maker の権限までは認証しない。
  • OMA の PEEM architecture は evaluation only を明示的に認める。decision が requestor に返され、その requestor が後続 action を決める場合と、PEEM 自身が enforcement を行う場合は、同じ receipt を残さない。
  • request、policy version、input provenance、decision、enforcer receipt、installation、activation、supersession、observed effect を別状態として接続しなければ、applied は原因を消すラベルになる。

応答時刻と作用時刻を同じにしない

分散した制御系では、decision の返却と effect の発生が一致しない。ところが dashboard は、最初に観測できた成功を最終結果の色に変えたがる。

実事故ではない検証用の例を置く。12:00:00 に resource が Policy-Data-Request を送る。12:00:01、正しく correlate された Policy-Data-Answer が success result とともに戻る。画面は直ちに「適用済み」と表示する。しかし enforcement adapter は切断中で、復旧した時点では local policy の新しい version が古い decision を退ける。Diameter exchange は成功した。target state は変わらなかった。

RFC 5224 は Informational RFC であり、役割を限定している。PDR/PDA に code 314、Policy-Data に OMA vendor namespace の code 1、application に 16777243 を割り当てる。詳細な Diameter binding は OMA PEM-1 section 5.4.1 に委ねる。

この document structure 自体が evidence の境界を示す。RFC は namespace と carrier を調整する。個々の deployment が誰を policy authority としたか、どの input を使ったか、誰が action を実行したかは、running system 側が示さなければならない。

番号は parser を合わせるが、principal を任命しない

IANA AAA Parameters には現在も application と command が載る。OMA binding は Vendor-Id 30079 を使い、Diameter capability exchange で support を advertise する。これは interoperability のための正しい仕組みである。

ただし Application-Id は委任状ではない。Vendor-Id はこの session を決定する権利ではない。Realm や Host への routing 成功も、business authority の証明ではない。support を advertise した node が、対象 resource の policy を決めるべき node とは限らない。

RFC 5224 は RFC 3588 の security considerations を引き継ぎ、後の RFC 6733 は Diameter Base Protocol を置き換えた。protected peer communication は peer authentication と message integrity を与える。必要な control だが、Policy-Data の source freshness や decision mandate を自動的に与えない。

運用 record は、cryptographic peer、application relationship、specific policy principal を別に持つべきだ。三者を同一 node に束ねる設計なら、その binding の version と有効期間を保存する。

Template は構造を示す。事実の鮮度は示さない

PEM-1 technical specification は、policy ごとに異なる input/output を BLOB と standard/custom template で扱う。generic interface を維持しながら、位置、残高、認可、risk など別種の context を運べる。

Template ID と version は decoder contract である。field が complete か、value が current か、外部 source が正しいか、二つの domain が custom field を同じ意味で使うかは証明しない。

Specification はこの local boundary を隠していない。supported option の保存・公開・advertise mechanism は scope 外である。また PEEM implementation が input をどう処理するか、requesting resource が output をどう処理するかも interface specification の scope 外である。

したがって request receipt には raw Policy-Data、template/version、subject、resource、policy reference/version、各 input の source と observed time、delegated call を結合する必要がある。field presence を fact freshness に読み替えてはならない。

Policy processing には複数の終点がある

PEM-1 は policy processing を evaluation、または evaluation and enforcement と定義する。OMA PEEM architecture はこの差を具体化する。

一つの flow では PEEM が decision を requestor に返す。その後の扱いは requestor が control する。別の flow では PEEM が enforcement を実行し、value を返さない場合もある。さらに PEEM が action や enforcement を行わない evaluation-only model も図示される。

Component model でも PV と PF は分かれる。PV は評価して result を返す。PF は result を受けて action を行い、さらに別 resource に delegate できる。同じ process に実装されても、decision production と action completion は別々に観測すべき state である。

RFC 2753 は PDP で decision を作り PEP で実際に enforce する。RFC 3198 は policy enforcement を decision の execution と定義する。PEP が decision を enforce すべきという requirement は重要だ。しかし requirement は、その transaction で実行済みだったという receipt ではない。

Result という一語に三つの層がある

Diameter は Result-Code または Experimental-Result で protocol/application result を運ぶ。Experimental は vendor-specific result container の名称であり、実環境で effect を実験観測したという意味ではない。

PEM-1 には Output Status template があり、mandatory statusCode は policy processing の final status または PEEM error を表す。その上に、policy 自身の decision や output data がある。

Protocol が受理し、PEEM processing が完了し、decision が返却されても、requestor が拒否する、部分導入する、競合に負ける、activation 前に新しい decision に置き換わる可能性がある。反対に PEEM が内部 enforcement を済ませ、限定的な status だけを返すこともある。

状態名は evidence の粒度に合わせるべきだ。transported、protocol-accepted、evaluated、decision-returned、received-by-enforcer、installed、active、effect-observed、superseded、rolled-back。UI はまとめられるが、underlying record はまとめてはいけない。

NO_STATE_MAINTAINED は lifecycle ledger ではない

OMA binding は Auth-Session-State に NO_STATE_MAINTAINED を使う。Server は Diameter session state を保持せず、client は termination request を送らない。Callable exchange として合理的だが、policy installation の継続や replacement history まで protocol が保存するわけではない。

この論点は既存記事とも異なる。RFC 3539 は watchdog、failover、pending request、duplicate を扱う。Reply の到着や再処理を説明しても enforcement を証明しない。RFC 2989 は AAA capability requirements を扱う。Capability があることと instance action は別である。RFC 7683 と RFC 4006 も、load、application state、service outcome が異なる semantics を持つことを示す。

Control が移る場所で receipt を作る

Accountable chain は一つの巨大 database を要求しない。Join できる narrow fact を要求する。Raw request と route、secure peer、subject/resource、policy と template version、input provenance、evaluation dependency、protocol result、PEEM status、policy output、designated enforcer、その receipt、target と previous state、installation/readback、activation、partial failure、rollback、later decision、observed effect を同じ correlation に接続する。

History は上書きせず追加する。後で supersede された decision も、返却されたという事実は残る。Installation failure は initial answer を failure に書き換えず、次の stage の failure として残す。そうすれば原因と compensation を正しく扱える。

Lu Heng の reality-layer doctrine で言えば、identifier は分類し、answer は記録し、decision は指示する。Running system が受け入れ、導入し、実行し、observable state を公開して初めて次の reality が生まれる。一つの record に全ての authority を貸さないことが、分散制御の clarity である。

情報源

  1. RFC 5224
  2. RFC 5224 text
  3. IETF Datatracker: RFC 5224
  4. RFC 5224 status
  5. RFC 5224 history
  6. RFC 5224 errata
  7. RFC 3588
  8. RFC 6733
  9. RFC 3539
  10. RFC 2989
  11. RFC 2753
  12. RFC 2748
  13. RFC 3198
  14. RFC 3084
  15. RFC 2903
  16. RFC 2904
  17. RFC 4006
  18. RFC 7683
  19. RFC 5234
  20. IANA AAA Parameters
  21. OMA PEM-1 technical specification
  22. OMA PEEM architecture
  23. OMA PEEM requirements
  24. OMA private AVP registry
  25. Lu Heng — Reality Layers and Symbolic Power
  26. Lu Heng — Running-Code Primacy
  27. Lu Heng — The Agency Problem