Кратко

  • draft-ietf-ippm-ioam-data-integrity-20 позволяет доверенному Validator повторить накопительную цепочку AES-GMAC и обнаружить изменение включённых неизменяемых полей.
  • Действительный ICV не доказывает наличие всех ожидаемых Option-Type, правдивость собственного измерения узла, целостность экспорта, отсутствие задержки или охват всего трафика.
  • Автоматизации нужен составной чек: ожидаемое и наблюдаемое множество, решение replay, происхождение Validator, цепочка экспорта, знаменатель охвата и независимая проверка сервиса.

Финальная операция — сравнение двух значений. Если пересчитанный ICV совпал с полученным, можно утверждать, что Validator не обнаружил изменения в заявленном защищённом наборе. Нельзя без дополнительной работы утверждать, что «путь доказан».

Revision 20 от 19 июля 2026 года остаётся Internet-Draft рабочей группы IPPM, хотя уже находится в очереди RFC Editor и ожидает первого редактора. IANA помечает изменённую версию как требующую проверки. Стадия процесса не подтверждает развёртывание или корректную реализацию.

Метод создаёт защищённые варианты pre-allocated trace, incremental trace, Proof of Transit и edge-to-edge. Каждый узел, обновляющий цепочку, имеет отдельный симметричный ключ. Nonce содержит Key ID, идентификатор инкапсулирующего узла и 64-битный счётчик. Начальный узел вычисляет ICV по неизменяемым полям, затем участники включают предыдущий ICV и собственный неизменяемый вклад.

Пакет несёт только последнее значение. Validator должен определить участников, получить их ключи и воспроизвести порядок. Привязка идентификатора узла к ключу вынесена за рамки документа. Решение зависит от локального реестра личности.

Настоящий ключ может защитить ложь

Скомпрометированный узел не должен незаметно выдать себя за другой или изменить чужой защищённый вклад. Но он способен отбросить пакет либо сообщить ложное значение о собственном состоянии под своим законным ключом.

ICV сохраняет происхождение утверждения и неизменность байтов. Он не калибрует датчик и не делает программу честной. Поэтому вклад аутентичен и измерение правдоподобно — разные поля. Второму нужны build, конфигурация, attestation, независимые счётчики и сопоставление с другими наблюдателями.

Validator — это центр полномочий

Проект называет Validator доверенным субъектом: он имеет ключевой материал и принимает окончательное решение. В документе также сказано, что скомпрометированный Validator может подделать данные или результат, а сам метод не предотвращает это.

Если одна система определяет ожидаемое множество, владеет картой ключей, выносит вердикт и запускает исправление, она объединяет наблюдение, суд и исполнение. GMAC не делает такой вердикт независимым.

В чеке должны быть идентичность Validator, версия ПО, hash конфигурации, эпоха ключей, версия карты и политика. Опасное действие требует второй плоскости наблюдения или отдельного разрешения.

Удалённая опция не участвует в проверке

Атакующий на пути может удалить весь заголовок IOAM Option-Type. Метод не смягчает эту угрозу; защита возлагается на инкапсулирующий протокол. Защищённую опцию можно заменить обычной, если Validator не знает обязательной политики.

Сначала нужен перечень ожидаемого: Namespace-ID, инкапсулирующий узел, Option-Type и участники. Затем он сравнивается с наблюдаемым. Только после этого ICV имеет полный контекст.

Отсутствующая опция не означает успех. Она могла не попасть в выборку, не быть включена, быть удалена или потеряться при экспорте. Эти причины нельзя сводить к одному пустому полю.

Валидная выборка не равна полному охвату

Защищённые и обычные IOAM-опции могут сосуществовать. Разные namespaces могут иметь разные режимы. Для ограничения нагрузки механизм можно применять лишь к части трафика.

Количество успешных проверок не показывает знаменатель. Критический поток может не попасть ни в одну из тысячи валидных записей. Охват фиксируется по классу трафика, namespace, типу опции, окну и версии политики.

Изменяемые поля заголовка также не защищаются. Результат обязан перечислять поля и masks, а не заявлять о целостности IOAM вообще.

После экспорта начинается новая цепочка

Управляющая плоскость и целостность экспортированных данных находятся вне области метода. Direct Export не несёт IOAM-Data-Fields и не должен использовать эту защиту.

После валидного ICV парсинг, нормализация, передача, хранение и агрегация ещё могут изменить смысл. Следует сохранять исходную опцию, чек Validator и hash каждого преобразования. При разрыве состояние — целостность экспорта не доказана.

Подлинные байты могут опоздать

Выборочная задержка не предотвращается. Атакующий способен задержать IOAM-пакеты и создать иллюзию перегрузки без изменения защищённого бита.

Свежесть требует времени захвата и проверки, допустимого возраста, качества часов и независимых показателей delay/loss. Anti-replay выявляет повтор nonce, но не делает уникальный пакет своевременным.

После перезапуска без сохранённого счётчика старый ключ нельзя использовать снова; нужна ротация. Replay window определяет допустимое легитимное переупорядочение.

Чек для решения

Записываются Domain, Namespace-ID, Option-Type, метод, mask, пакет, правило выборки, ожидаемые и наблюдаемые участники/опции. Затем nonce, открытые идентификаторы, эпоха ключа, версия карты, replay-решение и происхождение Validator.

Декapsulation, экспорт и хранение соединяются hashes. В конце добавляются delay, loss, подтверждение пути, метрики сервиса, действие, полномочие, rollback и результат.

Полезные состояния: валиден для заявленного набора, ожидаемая опция отсутствует, карта личности неизвестна, происхождение Validator не проверено, охват частичный, экспорт не доказан, результат сервиса ожидается.