Кратко

  • Версия 05 архитектуры внутридоменной проверки адреса источника рабочей группы SAVNET датирована 1 октября. Она разводит данные, предоставленные оператором, и сведения, полученные из системы маршрутизации. Для BYOIP и префиксов другого поставщика оператору следует потребовать от клиента указать их и подтвердить право использовать их как источник, даже если маршрута для них нет в конфигурации или анонсе.
  • Документ остаётся действующим Internet-Draft с предполагаемым информационным статусом, а не утверждённым RFC или отчётом о внедрении. Он не вводит обязательный формат доказательства, новый междоменный протокол либо безусловное удаление всех пакетов, сочтённых неверными.

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

Июньская версия проекта уже описывала это ограничение, скрытые префиксы и функцию SAV Agent для подготовки правил. Версия 05 не открыла заново разницу между достижимостью и правом. Она точнее раскрыла источники данных для агента: оператор может использовать сведения о клиенте, выделении адресов и конфигурации, а маршрутизирующая система может дать соответствующие префиксы и привязки. Оба подхода допустимо совмещать. Но разрешение, которого в маршрутизации нет, должно попасть в систему через операторское предоставление данных.

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

В примере клиент C соединён с двумя маршрутизаторами через i1 и i2. Сведения о P1 и P2 доступны из подходящей маршрутной или эксплуатационной информации; H — скрытый префикс только для источника. Если клиенту разрешены все три, оба интерфейса должны получить согласованные разрешающие списки. Для H требуется явная запись разрешения. При изменении подключения, назначения либо права на H агент обновляет затронутые правила. Это учебная схема двух способов получения сведений, а не свидетельство работы сети в производстве.

Архитектура рекомендует правила по разрешающим спискам, но признаёт опасность неполной информации: можно ошибочно заблокировать допустимый трафик. Действие над пакетом, признанным неверным, задаёт местная политика; развёртывание может начинаться с наблюдения или записи событий. Алгоритм, новое междоменное сигнализирование и фиксированное место работы SAV Agent проект не определяет. В Datatracker он всё ещё значится как I-D Exists. Проверяемое управление здесь означает возможность ответить, на каком основании префикс разрешён на данном интерфейсе и какая версия правила действует сейчас.

Источники