Кратко

  • Read-only листья revision 01 описывают иерархический предел мутации SCHC-правила, но не содержат пользователя, группу, сессию или устройство, которому разрешено этим пределом воспользоваться.
  • Безопасное изменение требует одновременно полномочия субъекта и полного пути SCHC-разрешений, а затем проверки исходной версии, валидации, активации у peer и доказуемого отката.

Система управления получает запрос от аутентифицированной сессии. Группе разрешена запись конфигурации. В описании нужного поля виден change-tv. Два независимых механизма ответили «да», и контроллер принимает это за единое полномочие.

На самом деле ответы относятся к разным утверждениям. Группа допускает определённую management operation. SCHC-лист допускает определённый вид преобразования Field Descriptor. Они ещё не доказывают, что данный субъект вправе менять данный RuleID в данном Context именно сейчас. Они также не доказывают, что исходная версия не устарела и что второй конец активирует тот же смысл.

Это реконструированная ситуация, а не сообщение о реальном инциденте. Она показывает центральную границу draft-ietf-schc-access-control-01: свойство объекта «его можно изменить» не является учётной записью и не создаёт мандат.

Короткий пакет опирается на длинное соглашение

RFC 8724 позволяет SCHC не передавать известные значения заголовка, потому что стороны заранее разделяют Context. RuleID выбирает правило, а Field Descriptor задаёт Field Identifier, Target Value, Matching Operator, Compression/Decompression Action и другие параметры.

Экономия возможна только при одинаковом понимании правила. Если один узел изменит смысл RuleID, сокращённый пакет не содержит полного заголовка, который мог бы исправить расхождение. RFC 9363 прямо предупреждает: изменение адреса приложения может блокировать связь или способствовать перехвату. Идентичность requester следует проверять, а устройство должно менять только собственные правила.

Проект access control решает задачу, которой недостаточно обычного права на запись YANG-дерева. В одной rule Target Value для Uri-Path может быть изменяемой, тогда как application prefix рядом должен оставаться неизменным. Широкое «update разрешён» теряет эту разницу.

Три уровня формируют один потолок

ac-modify-set-of-rules определяет права на уровне набора: запрет, изменение существующего элемента или добавление и удаление. ac-modify-compression-rule ограничивает Field Descriptions внутри compression rule. ac-modify-field различает запрет, изменение Target Value и изменение TV вместе с MO и CDA.

Глубокий лист нельзя читать отдельно. Уровень compression rule активен только при разрешающем родителе. Уровень field требует разрешения обоих родителей. change-tv под no-change не открывает обход. Если листа нет, информация, согласно проекту, изменяться не может.

Листы объявлены config false: удалённый клиент их видит, но не может сначала записать себе разрешение, а затем использовать его. Это правильное направление доверия.

Однако в этих значениях нет principal. Они не несут username, group, credential, session, owner, delegation или revision политики. Это описание формы допустимого действия, а не личности действующего.

Субъект появляется в NACM и транспортной аутентификации

Авторы не предлагают заменить NACM. Проект говорит, что NACM разрешает действия пользователям и группам, но его гранулярность не подходит для внутренней структуры SCHC-правила. RFC 8341 получает от transport layer аутентифицированное имя пользователя и группы, сопоставляет operation и data node с правилами и возвращает access-denied при отказе. Для всей обработки одного сообщения используется один снимок access rules.

Поэтому безопасная модель состоит из пересечения:

этот principal вправе выполнить этот запрос и этот SCHC-элемент допускает такой вид мутации.

NETCONF требует аутентификации соединения и при наличии capabilities поддерживает candidate datastore, validate, lock и rollback-on-error. RESTCONF может использовать ETag и If-Match, чтобы отклонить запись поверх уже изменённого ресурса. CORECONF переносит YANG-management в компактный CoAP-обмен и требует защищать ресурсы от неавторизованного чтения и записи.

Инструменты взаимно дополняются. NACM CRUDX не объясняет семантическую разницу между разрешённой TV и защищённым prefix. change-tv не устанавливает принадлежность к группе. Если оставить только NACM, широкая роль способна проглотить объектную границу. Если оставить только SCHC-листы, разрешение не будет связано с субъектом.

Успех транзакции не равен смене протокольного состояния

Даже правильный субъект может писать поверх устаревшего состояния. ETag позволяет RESTCONF обнаружить это. Lock или candidate datastore дают NETCONF другие способы изоляции и проверки. Но revision 01 не задаёт обязательный механизм контроля конкуренции.

Ещё важнее переход между сторонами. Datastore может принять update, в то время как peer продолжает декодировать пакеты по старому Context. Ответ 204 или <ok/> свидетельствует об успехе management transaction. Он не является доказательством, что оба участника одновременно используют новую Rule.

Нужны как минимум ожидаемая старая revision, новая revision, граница activation, список затронутых peers, compatibility check и известная точка rollback. Иначе зелёный результат control plane способен породить скрытое расхождение data plane.

Сам проект пока не объясняет, кто формирует read-only листья, как права выводятся и отзываются, как principal связывается с Context или ownership устройства. Не определены multi-field atomicity, конкурентные writers, audit receipt и restoration. Это можно реализовать рядом с моделью, но нельзя приписывать отсутствующие функции самим листьям.

Незавершённость документа — часть оценки

Revision 01 обновлена 29 сентября 2026 года. Это активный 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.

Эти следы не опровергают полезность иерархии. Они означают, что автоматизация не должна считать имена, значения и security composition окончательно стабильными. SCHC architecture draft от июля 2026 года требует аутентификации и авторизации managers, audit изменений и восстановления known-good Context, одновременно признавая незавершённость lifecycle и management.

Зафиксированные источники не доказывают широкое развёртывание, interoperability, производительность или известный инцидент. Эксперимент должен явно хранить точную revision и допускать изменение контракта.

Запись, способная пережить спор

Для существенной мутации следует сохранить:

  1. аутентифицированный principal, группы, session и transport protection;
  2. operation, Context, Set of Rules и RuleID;
  3. предыдущую revision или ETag и точные значения до/после;
  4. все применимые SCHC-листы вместе с родителями;
  5. revision NACM или эквивалентной политики;
  6. validation, collision check и transaction result;
  7. activation time и compatibility evidence для каждого peer;
  8. наблюдаемый результат, владельца и проверенную rollback point.

Так выглядит узкое полномочие в технической системе. Identity layer подтверждает субъекта, SCHC-модель ограничивает объект, transaction layer защищает запись, operator решает момент активации. Совпадение этих действий в одном API не даёт одному слою власть другого.

Sources