Кратко

  • RFC 8955 распространяет через BGP условия и действия, но по умолчанию сопоставляет источник правила с лучшим подходящим unicast-маршрутом и требует повторной проверки после изменения маршрута.
  • Susan Hares — соавтор RFC 8955 и один из редакторов IPv6-расширения RFC 8956. RFC 9117 написан другой группой и ослабляет проверку только для центральных контроллеров и route server внутри общей локальной области.

Анонс, который воздействует на пакеты

FlowSpec объединяет destination и source prefix, протокол, порты, ICMP, TCP flags, длину пакета, DSCP и фрагментацию. Extended communities задают действие: ограничить byte или packet rate, включить sampling, завершить обработку, перенаправить через route target или изменить marking. Нулевая скорость означает discard.

Во время DDoS это позволяет быстро разнести правило по пограничным роутерам. Но ошибка распространяется столь же быстро. Обычный маршрут меняет предпочтительный путь, а FlowSpec непосредственно меняет обработку совпавших пакетов. Синтаксически допустимое сообщение ещё не доказывает право соседа на такое действие.

Официальный профиль Susan Hares в IETF Datatracker показывает её участие в стандартизации. Для этой статьи существенна точная документальная цепочка. RFC 8955, Standards Track от декабря 2020 года, подписан Christoph Loibl, Susan Hares, Robert Raszuk, Danny McPherson и Martin Bacher; он заменил RFC 5575 и RFC 7674. Редакторами IPv6-расширения RFC 8956 указаны Loibl, Raszuk и Hares.

Это коллективная работа IETF, а не единоличное изобретение. Документы подтверждают участие Hares в обновлении спецификации. Они не подтверждают владение технологией, одинаковую реализацию у всех производителей или её повсеместное включение.

Основание берётся у текущего пути

RFC 8955 задаёт детерминированный порядок перекрывающихся правил. Если совпадение не имеет действия, по умолчанию пакет принимается. Одинаковая сортировка нужна для согласованности, но сама по себе не авторизует источник.

Стандартная проверка находит лучший unicast-маршрут для destination prefix. Originator FlowSpec должен совпадать с originator этого маршрута. More-specific от другого соседнего AS может лишить правило валидности. Для EBGP дополнительно сравнивается крайний левый AS в обоих путях.

Это не криптографическая гарантия честности, а ограничение scope. Соседний AS, являющийся непосредственным шагом к назначению, и так может отбросить трафик после получения. Его просьба сделать это раньше на upstream способна сохранить ёмкость атакуемого линка. Полномочие следует из текущего отношения к destination, а не только из наличия BGP-сеанса.

Основание меняется вместе с topology. RFC 8955 требует повторной проверки FlowSpec при изменении связанного unicast-маршрута. Новый origin или более специфичный путь от другого peer может отменить уже установленное правило. Проверка только в момент приёма превращает временное право в постоянную привилегию.

Контроллер не обязан форвардить

Центральный контроллер внутри собственной сети может быть легитимным источником mitigation, хотя не находится на лучшем forwarding path. Строгая проверка отвергнет его именно потому, что он управляет, а не передаёт пакеты.

RFC 9117, опубликованный в августе 2021 года, изменяет процедуру для этого случая. Авторы — Jeffrey Uttaro, Jorge Alcaide, Clarence Filsfils, David Smith и Pradosh Mohapatra; Susan Hares среди них нет. Этот RFC показывает более позднее уточнение границы, установленной RFC 8955.

Послабление действует внутри одной локальной административной области. Оператор явно доверяет своему route controller, не требуя от него origin лучшего unicast-маршрута. RFC 9117 также уточняет AS_PATH для route server. Он не выдаёт удалённым контроллерам общего междоменного права фильтрации и не отменяет local policy принимающей сети.

Программирование собственной сети собственным контроллером — внутренняя governance. Просьба другой организации изменить обработку пакетов — inter-domain coordination. Общий протокол не делает эти отношения одинаковыми.

Принято в BGP — не значит исполнено правильно

RFC 8955 предупреждает о нежелательной фильтрации, маркировке и перенаправлении при ослабленной проверке. Действия меняют forwarding, VPN context и queue. Неисправный или скомпрометированный контроллер способен создать слишком много updates, исчерпать capacity или установить чрезмерно широкое совпадение.

Import policy должна ограничивать actions, prefixes, ports, rates, redirect targets и число правил для каждого peer. Затем нужна проверка forwarding plane. Маршрут может быть принят BGP, но не попасть в ACL, FIB или ASIC. Установленная запись может затронуть не тот сервис.

Публикация RFC не доказывает поддержку в конкретной версии, включение функции, одинаковое поведение устройств или успешное подавление атаки. Стандарт задаёт общую семантику и защиту по умолчанию. Рабочая сеть должна подтвердить результат.

Небольшой общий язык, локальная ответственность

Эссе Lu Heng Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption помогает разделить уровни. Общими остаются match components, actions, порядок и unicast validation. Локально выбираются peers, controllers, разрешённые действия, лимиты, logging и withdrawal.

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

Running-Code Primacy переносит доказательство из BGP table в устройство: validation state, порядок, hardware installation, counters, реальное действие, влияние на сервис, withdrawal и recovery. Отдельно проверяется пересчёт полномочий при изменении unicast route. Эти поздние эссе — аналитическая рамка Sofia Ren, а не слова Hares или авторов RFC.

Для каждого правила сеть должна отвечать: кто его отправил, какой текущий routing fact даёт ему основание и какая local policy разрешила действие. Документированный вклад Hares важен тем, что мощность фильтра остаётся связанной с объяснимым и отзывным правом.

Источники