Кратко

  • В draft-ietf-spring-srv6-security-16 доверенный домен — логическая и операционная конструкция, где действует пограничная фильтрация из RFC 8402, а не физическая территория.
  • Несколько экземпляров SR могут принадлежать одной административной структуре и всё же оставаться разными. Общий собственник, объект или бренд не подтверждает общие полномочия.
  • Ошибочное изменение правил или пределы оборудования могут открыть границу. Проверки только наличия SRH недостаточно: обработка SID возможна без него, а пакет с SRH может идти транзитом.
  • Манифест границы и квитанция исполнения должны связывать членство, диапазоны, ключи, задуманные и установленные правила, ёмкость и отрицательные тесты. Это предложение Daniel Kade, а не требование IETF.

Компания стала одной, периметры — нет

Два домена SRv6 создавались независимо. У каждого свои планы SID, контроллеры, ключевой материал, эксплуатационные роли и пограничные правила. После корпоративного объединения появляется новая карта, где всё называется единой сетью. Отсюда один шаг до решения убрать фильтр между площадками.

Но договор купли-продажи не разрешает узлу первого домена навязывать путь во втором. Он не согласует адресные диапазоны и не добавляет места в аппаратные таблицы. Если снять контроль до технического объединения полномочий, административная экономия превратится в расширение доверия без отдельного решения.

Редакция 16 Segment Routing IPv6 Security Considerations проводит нужную границу. Она следует RFC 8402: Segment Routing по умолчанию работает внутри доверенного домена, а трафик фильтруется на его границах. Сам домен назван логическим и операционным, но не физическим. Серверы в той же физической сети не считаются участниками, пока их явно не включили в систему контроля.

Документ отдельно допускает несколько экземпляров SR у одной административной организации, которые остаются логически или операционно разными. Источник в другом доверенном домене для этой модели является внешним. Принадлежность компании не служит пропуском.

Last Call не выносит вердикт заранее

IESG открыл Last Call по редакции 16 3 сентября 2026 года и запросил комментарии до 17 сентября. На дату исследования, 9 сентября, Datatracker показывал активный Internet-Draft группы SPRING с предполагаемым статусом Informational. Дата telechat отсутствовала, а состояние рабочей группы требовало новой редакции из-за вопроса, поднятого во время WGLC.

Значит, 17 сентября — срок обратной связи, не дата утверждения. Редакция 16 не является RFC, не сертифицирует сеть и не устанавливает новый протокол безопасности. Она полезна тем, что раскрывает операционные условия уже существующей архитектурной модели.

RFC 8402 предполагает: узел, добавляющий список сегментов или SRH, имеет право это делать. Членство в домене даёт реальное влияние на путь и обработку пакета. Поэтому перевод соединения из категории «внешнее» в «внутреннее» — решение о полномочиях, даже если его называют оптимизацией.

У доверия есть замысел и измеряемое состояние

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

Тогда возникает fail-open. Возможность, ранее доступная лишь внутреннему нарушителю, появляется у внешнего источника, потому что один из компонентов перестал применять правило, определявшее домен.

Нужно различать три доказательства. Заявленное членство перечисляет узлы, источники, контроллеры и роли. Утверждённый замысел описывает входы, выходы, диапазоны SID и источников, инкапсуляцию и исключения. Наблюдаемое исполнение показывает установленные правила, свободную ёмкость, счётчики и результаты тестов.

Успешный запрос настройки не доказывает исполнение. Он не показывает, что правило приняли все устройства, таблица не переполнена, состояние сохранилось после перезапуска и внешний тестовый пакет был действительно отброшен.

При слиянии различия особенно важны. Один домен может применять выделенный диапазон SID, другой — более сложное распределение. Один инкапсулирует трафик на входе, другой опирается на иные условия. Ресурсы ACL или TCAM могут конкурировать с VLAN и таблицами маршрутов. Общий владелец не меняет пределы микросхемы.

SRH не заменяет контекст источника и назначения

Фильтр по самому наличию SRH кажется удобным, но у него две проблемы. SRH не обязателен для обработки SID. Одновременно пакет с SRH может лишь проходить через домен, не адресуя ему функцию. Единичный признак способен пропустить существенное и повредить законному транзиту.

Важнее связь диапазонов. На входе отбрасывается внешний трафик к внутреннему SID. На каждом узле SRv6 отбрасывается пакет к локально созданному SID, если источник находится вне домена. Одновременная потеря двух уровней открывает путь, который модель считала внутренним.

Для этого нужны узнаваемые инфраструктурные диапазоны. RFC 9602 выделяет префикс для SID SRv6. Проект отмечает, что другие варианты усложняют фильтры и повышают вероятность утечки маршрутов либо человеческой ошибки. Политика должна знать реальную адресацию, а не новый корпоративный ярлык.

Инкапсуляция на входе создаёт внешний IPv6-заголовок и SRH на доверенном узле. Внутренние решения тогда не зависят от полей, переданных недоверенным источником. Но инкапсуляция лишь дополняет пограничную фильтрацию, а не отменяет её.

На одном узле возможны две области ключей

RFC 8754 задаёт необязательный HMAC TLV для защиты конкретных полей SRH. Редакция 16 предупреждает, что ручное управление заранее распределёнными ключами подталкивает к повторному использованию. Один ключ не следует применять в разных доверенных доменах, даже расположенных на одном узле.

Физическая коробка тем самым не определяет область полномочий. Два экземпляра на одном маршрутизаторе могут сохранять отдельные ключевые домены.

Успешный HMAC также не даёт полного вердикта. Скомпрометированный законный узел с ключом остаётся внутренним нарушителем. Внутренний участник без ключа может повторно отправить ранее перехваченные SRH и HMAC в период действия ключа. Криптография подтверждает ограниченное свойство целостности, но не решает, кто вправе задавать любой маршрут.

Единый ключ на всю компанию создаёт иллюзию готового объединения: проверка проходит, хотя полномочия никто не согласовал. Впоследствии разделить сети будет сложнее.

Записать существующую границу, а не желаемую

Оператору нужен версионируемый манифест границы доверенного домена и квитанция исполнения после каждого изменения. Это не изменение SRv6 и не норма IETF. Это способ не свести разные факты к одному флагу «внутренний».

Манифест содержит идентификатор домена, допущенные узлы и роли, входы и выходы, диапазоны SID и источников, полномочия контроллеров, точки инкапсуляции и идентификаторы ключевых доменов — без самих секретов. Каждый переход в другой домен получает владельца решения, причину и срок действия.

Квитанция соединяет замысел с результатом: правила, которые устройства сообщают как установленные, доступную ёмкость, счётчики, отрицательный тест извне, разрешённый тест изнутри и исключения. Изменение топологии, версии ПО, оборудования, префикса, роли или ключа делает старую квитанцию просроченной.

Такая запись не обещает неуязвимость. Она формулирует проверяемое утверждение: эта редакция домена проверена тогда-то, на этих границах, устройствах и диапазонах, при таких оставшихся ограничениях.

The Policy Mirror предлагает искать место, где правило приобретает силу. Здесь оно распределено между членством, адресами, фильтрами, инкапсуляцией и ключами. Running-Code Primacy требует доказать их совместную работу. Reality, Not Advocacy ограничивает вывод: проект не обвиняет оператора и не решает междоменный SRv6. Он показывает, почему единый собственник не создаёт единое доверие.

Источники