Кратко

  • 3 сентября 2026 года IESG открыла финальное обсуждение редакции 16 Segment Routing IPv6 Security Considerations до 17 сентября. Документ рассматривают как Informational RFC; он ещё не одобрен и не опубликован.
  • Наличие SRH неверно классифицирует обе стороны: SID обрабатывается и без него, а пакет с SRH может проходить транзитом. Доверие создаёт согласованное исполнение адресных диапазонов, источников, пограничных и узловых фильтров.

Доверенный домен в редакции 16 — не физическая территория. Узел в той же сети остаётся внешним, если его не включили в контроль. Два экземпляра SR под одной администрацией также могут быть логически отдельными доменами и считаться внешними друг для друга.

Поиск заметного Routing Type 4 не доказывает эту границу. Один IPv6-адрес назначения может представлять полный сегмент, поэтому для SID не всегда нужен SRH. И наоборот, SRH может принадлежать пакету, который лишь пересекает сеть. Сплошная блокировка ломает законный транзит, а разрешение по отсутствию заголовка пропускает адресованную функцию.

Проект предлагает смотреть на адресный контракт. На входе отбрасывается внешний пакет к SID домена. На каждом узле SRv6 дополнительно отбрасывается пакет к локальному SID, если источник не входит во внутренний диапазон. Одна ступень страхует ошибку другой; отказ обеих создаёт fail-open и переносит часть внутренней угрозы наружу.

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

Инкапсуляция на доверенном входе даёт внешнему заголовку и необязательному SRH известного автора. Поля внутреннего маршрута уже не копируются прямо с недоверенного интерфейса. Но ошибочно допущенный пакет после упаковки остаётся ошибочно допущенным; инкапсуляция дополняет фильтр.

HMAC TLV также ограничен. Он защищает выбранные поля общим ключом, однако необязателен, допускает риск повторного использования ключа и replay в период действия. Segments Left не входит в покрытие. Успешная проверка не доказывает право источника, свежесть или итоговый путь.

Средства безопасности видят изменяющийся активный адрес. Не понимающий SRv6 firewall может принять сегмент за конечную цель и разорвать связь между направлениями потока. Отбрасывание всех extension headers ломает SRv6 внутри домена и не замечает SID без SRH.

Политика должна поместиться в оборудование. ACL и TCAM делят ресурс с VLAN, маршрутами и MAC-таблицами; глубина разбора также ограничена. Если невозможное правило принимается системой управления, а устройство при переполнении разрешает трафик, конфигурация выглядит правильной, но граница открыта.

По дисциплине Heng Lu следует отдельно хранить состояние процесса IETF, текст проекта, желаемую конфигурацию, загруженные таблицы, наблюдаемый пакет и результат услуги. Каждая запись имеет собственный предел доказательства.

Источники

  1. Объявление IESG о финальном обсуждении
  2. Редакция 16 проекта безопасности SRv6
  3. Запись Datatracker
  4. RFC 8402: архитектура Segment Routing
  5. RFC 8754: SRH
  6. RFC 8986: программирование сети SRv6
  7. RFC 9602: выделенный блок SID
  8. RFC 9288: фильтрация расширений IPv6
  9. RFC 7872: измерения потерь расширений
  10. RFC 8200: IPv6
  11. RFC 9098: безопасность расширений IPv6
  12. RFC 9099: эксплуатационная безопасность IPv6
  13. RFC 9259: OAM в SRH
  14. RFC 4381: практика доверенного домена
  15. RFC 3552: описание вопросов безопасности
  16. Heng Lu: приоритет работающего кода
  17. Heng Lu: минимальная начальная спецификация
  18. Heng Lu: уровни реальности