Кратко

  • 17 сентября IESG открыла последний приём замечаний по версии 21 междоменного документа SAVNET; содержательные комментарии ждут до 1 октября.
  • Ошибочная блокировка законных пакетов и пропуск подменённых источников возникают по-разному на стыках с клиентом, пиром и провайдером.
  • Согласие рабочей группы, решение IESG, будущий механизм, настройка оператора и измеренный эффект не являются одним событием.

Сеть клиента может анонсировать префикс только через часть своих связей, но передавать законный трафик с этого адреса иным путём. При прямом возврате от пограничного сервера ответ иногда использует anycast-адрес, который анонсируется в другой точке. В проекте SAVNET версии 21 эти ситуации служат проверкой допущений о видимости BGP. Строгий обратный поиск маршрута способен ошибочно отсеять пакет. Приведённые схемы — модели для анализа, не сообщения о производственных авариях.

Но широкое разрешение адресов тоже имеет цену. Если проверка внутри клиентского конуса введена лишь частично, один сосед может подменить источник другого, а более удалённый узел не отличит их по общему разрешённому префиксу. На пиринговом стыке асимметрия маршрутов делает узкое правило ещё менее надёжным. Со стороны вышестоящего провайдера Loose uRPF пропустит пакет с подменённым адресом, если маршрут к такому префиксу просто имеется в FIB. Более точные ACL требуют постоянного обновления при изменении сетевых связей. Документ не предлагает свести все эти отношения к одному безусловному тесту.

Объявление IESG от 17 сентября запрашивает отзывы о публикации анализа проблемы и требований в качестве информационного RFC. Datatracker всё ещё показывает действующий Internet-Draft на стадии запроса публикации. Для будущих решений текст ставит задачи точности, снижения нагрузки на эксплуатацию, пользы при частичном внедрении, защиты сведений, предназначенных специально для SAV, и правильной сходимости таблиц. Никакого утверждённого протокола или доказанного сокращения подделок из такого статуса не следует.

Сопроводительный отчёт фиксирует две стадии обсуждения внутри рабочей группы и широкую поддержку, но отдельно отмечает: это не протокольная спецификация и не расширение BGP либо определение нового объекта RPKI. Ранняя рецензия на версию 20 просила уточнить, является ли стремление к нулю ошибочных блокировок жёстким требованием, и развести модели доверия к разным данным. Речь шла о прежней версии; её нельзя выдавать за нерешённый окончательный вердикт по версии 21. Зато она показывает, почему слова о целях и гарантиях важны в последнем отзыве.

Источники