Кратко

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

Клиент отправляет пакет с адреса, который ему разрешено использовать. Маршрутизатор смотрит в базу пересылки (FIB), видит, что префикс указывает на другой интерфейс или вообще отсутствует, и отбрасывает пакет. На настоящий вопрос маршрутизатор ответил. Только вопрос был не тот.

В этом состоит проблема RFC 10078 — информационного документа IETF, опубликованного в октябре 2026 года. Он рассматривает проверку адресов источника (SAV) внутри автономной системы, на внешних интерфейсах к хостам и клиентским сетям, которые не являются соседними AS. У клиента может не быть собственного ASN. Он может использовать адреса, выделенные оператором, или принести свой адресный блок.

Строгий режим одноадресной проверки обратного пути (uRPF) проверяет, есть ли в FIB маршрут, покрывающий адрес источника, и совпадает ли выходной интерфейс этого маршрута с интерфейсом входа пакета. Проверка проста; маршруты — не всегда. Клиент с несколькими подключениями может отправить пакет через маршрутизатор 1, хотя сеть оператора ожидает возврат для этого префикса через маршрутизатор 2. Строгий uRPF принимает неожиданный интерфейс за признак подделки. В примере RFC в итоге отбрасывается легитимный трафик клиента.

Свободный режим убирает сравнение интерфейсов. Достаточно, чтобы в локальной FIB был покрывающий префикс. Так проходит часть асимметричного трафика, но появляется другая слабость: поддельный пакет тоже пройдёт, если его адрес относится к любому префиксу из таблицы. Строгий режим путает обратный путь с разрешением; свободный — общую достижимость с разрешением.

Скрытые префиксы усложняют задачу. Хост или клиент может законно отправлять трафик с адреса, о котором внутренний протокол маршрутизации оператора ничего не знает. RFC приводит Direct Server Return (DSR): запрос приходит на один узел anycast-сервиса, а другой пограничный сервер отвечает напрямую, используя адрес самого сервиса как источник. Такой же разрыв возникает, если клиентский префикс не объявлен внутри сети оператора. Если его нет в FIB, оба режима uRPF могут отбросить пакет. Список контроля доступа может явно перечислить разрешённые префиксы, но кто-то должен отследить смену разрешений клиента и обновить правило.

Для новых механизмов RFC задаёт пять свойств: более точная проверка; автоматический сбор и обновление SAV-данных; постепенное внедрение хотя бы на части подходящих интерфейсов; отсутствие вреда для сходимости маршрутизации и быстрого обхода при распространении данных через протокол; использование аутентифицированной или доверенной информации. Не хватает записи о разрешении использовать адрес источника, которой маршрутизатор мог бы доверять и которую можно поддерживать актуальной. FIB описывает достижимость. Использовать её ещё и как реестр клиентских разрешений удобно, пока эти два ответа не расходятся.

RFC 10078 не задаёт такой реестр, протокол его распространения или готовый механизм. Документ формулирует проблему и требования. Практический тест понятен: отправить легитимный трафик по асимметричному маршруту и со скрытого префикса, затем проверить поддельные источники с префиксами, которые есть и которых нет в FIB. Записать, какое правило приняло решение, кто предоставил разрешение, как обновление доходит до края сети и что происходит при смене маршрута.

Источники