要約

  • revision 01 の三層の読み取り専用 leaf は、SCHC の変更範囲を表す。誰がその変更を実行できるかは、認証済み管理セッション側で別に決める必要がある。
  • 安全な変更には、主体認可と親から子までの SCHC 権限の両方に加え、旧版の一致、検証、対向側の有効化、監査可能な結果と復旧点が要る。

管理要求の送信者は認証済みだった。所属グループには設定更新権限があり、対象の Field Descriptor には change-tv が表示されている。自動化は二つの肯定を見て、変更を許可した。

ところが、二つの肯定は別の問いへの回答である。グループ権限は、このセッションがある種類の更新を要求できることを示す。change-tv は、このフィールドで許容される変更の形を示す。どちらも単独では、この主体がこの端末のこの Context を今変更してよいとは証明しない。旧ルールが読み取り後も現行か、対向側が同じ意味を有効化できるか、失敗時に戻せるかも分からない。

これは公表された障害ではなく、draft-ietf-schc-access-control-01 の境界から組み立てた状況である。圧縮技術の細部に見えるが、問われているのは権限設計の基本だ。可変な資源と、変更を委任された主体は同じものではない。

RuleID が運ぶものと、運ばないもの

RFC 8724 の SCHC は、端末間で共有する Context を使い、既知のヘッダー情報を毎回送らない。RuleID が圧縮・復元のルールを指し、Field Descriptor が Field Identifier、Target Value、Matching Operator、Compression/Decompression Action などを定める。

省略できるのは、両端が同じ意味を保持しているからだ。片側だけがルールを変えれば、短くなったパケットの中に不一致を直す材料はない。RFC 9363 は、アプリケーション IPv6 アドレスなどの改変が通信遮断や盗聴につながり得ると警告し、要求者の身元確認と、自分のルールだけを変更させる制約を求める。

revision 01 は、この危険に対して一般的な「書き込み可」より狭い表現を導入する。同一の圧縮ルールで Uri-Path の Target Value は更新できても、アプリケーション prefix は固定したい。YANG の一つの領域を更新できるというだけでは、その差を表せない。

子の許可は親の禁止を越えない

最上位の ac-modify-set-of-rules は、変更不可、既存要素の変更、要素の追加・削除を区別する。次の ac-modify-compression-rule は、圧縮ルール内の Field Description に同種の上限を置く。ac-modify-field は、変更不可、Target Value の変更、あるいは TV・MO・CDA の変更を区別する。

重要なのは値だけでなく評価順である。圧縮ルールの leaf は上位が変更を許す場合だけ有効で、フィールド leaf は二つの親が許す場合だけ有効になる。深い場所の change-tv を見つけても、上位の no-change を無視してはならない。leaf が存在しない情報は変更できない、と草案は述べる。

三つの leaf は config false である。遠隔の編集者が自分で変更して権限を作る設定項目ではなく、サーバーが示す状態だ。この方向性は妥当だが、その状態には user、group、credential、session、委任元が含まれない。表現しているのは変更の天井であって、変更者の名簿ではない。

NACM と SCHC leaf は競合せず、接続される

草案は NACM を退けていない。むしろ、NACM が user や group に操作を許す一方、その粒度が SCHC ルール内部には合わないと説明する。RFC 8341 は、トランスポートで認証された username と group をセッションに結び、protocol operation と data node ごとに許可を判定する。処理中に物差しが変わらないよう、一つのメッセージには開始時のアクセス規則を最後まで使う。

したがって二層は役割分担できる。NACM または同等機構は「誰が、どの要求を行えるか」を判定する。SCHC leaf は「対象要素に、どの形の変化が許されるか」を判定する。安全条件は OR ではなく AND だ。

NETCONF は接続認証を要求し、実装能力に応じて candidate datastore、validate、lock、rollback-on-error を使える。RESTCONF は YANG 資源への編集を HTTP に写し、ETag と If-Match で古い読み取りに基づく書き込みを拒否できる。CORECONF は制約端末向けに CoAP と CBOR を使い、未認可の読み書きを防ぐことをサーバーに要求する。

これらは有用な部品だが、組み立て済みの SCHC 変更手順ではない。NACM の CRUDX は主体の操作範囲を扱うが、同じ Rule 内の TV と prefix の意味差までは自然に表現しない。SCHC の change-tv はその意味差を扱うが、認証主体を選ばない。片方がもう片方を兼ねる設計は、広すぎる管理者権限か、主体のない変更券を作る。

データストアの成功と Context の成功

現在の文書には、読み取り専用 leaf を誰が設定するか、どの根拠から生成するか、取り消しを処理中要求にどう反映するかが書かれていない。主体と端末所有、Context、RuleID を結ぶ方式も定義していない。競合更新、複数フィールドの原子性、有効化時点、対向確認、監査、復旧も未定義だ。

未定義だから実装不可能という意味ではない。管理プロトコルの機能や配備固有の制御で補える。ただし、アクセス leaf を完全な変更ガバナンスと呼ぶこともできない。

たとえば RESTCONF の ETag は、読んだ版がまだ現行であることを If-Match で確認できる。NETCONF の lock は他のクライアントとの干渉を抑えられる。それでも、データストアが受理した瞬間に相手側の SCHC Context が同じ版へ切り替わるとは限らない。管理トランザクションの完了と、プロトコル上の意味の同期は別の証拠を要する。

このため、結果の receipt は単なる HTTP 204 や <ok/> で終わらせられない。どの Rule revision が、どの peer で、いつ有効になり、圧縮・復元の観測が一致したかを残す必要がある。

revision 01 を完成品として読まない

この文書は 2026 年 9 月 29 日更新の Working Group Internet-Draft で、Standards Track のヘッダーを持つが RFC ではない。Terminology には ToDo、Security Considerations と IANA Considerations には TBD が残る。YANG module の revision は 2023 年で、compound-ack と RFC YYYY の別テーマの記述が混在し、field access の enum 説明も Reserved slot number のままだ。

これは設計を否定する材料ではなく、安定性を過大評価しないための証拠である。2026 年 7 月の SCHC architecture 草案も、Context の完全性、管理者の認証・認可、変更の監査、既知の正常版への復元を求めながら、lifecycle と management が未整備だと明記する。

現時点の一次資料は、広範な実装、相互運用試験、性能や実事故を示していない。実験者は現在の階層を試せるが、製品や監査制度は改訂を前提に境界を記録すべきである。

残すべき変更記録

責任を負える最小記録は次の通りだ。

  1. 認証主体、group、session、transport protection。
  2. management operation、対象 Context、Set of Rules、RuleID。
  3. 変更前 revision または ETag と、前後の正確な値。
  4. 親から子までの全 SCHC access leaf。
  5. 判定に使った NACM または同等 policy の版。
  6. validate、collision、transaction の結果。
  7. peer ごとの activation 時刻と compatibility evidence。
  8. 運用観測、owner、rollback point と復旧試験。

権限を狭く保つとは、単に deny を増やすことではない。主体、対象、変更形、時点、結果を別々に証明し、それぞれを担当する層が他層の権限を借りないことである。

Sources