Кратко

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

Анализ

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

BCP 38 определил цель входной фильтрации: останавливать трафик с поддельным источником ближе к месту входа и улучшать отслеживаемость злоупотреблений. RFC 3704 описывает несколько способов. Строгий uRPF ищет источник в FIB и требует совпадения входного интерфейса с выбранным обратным. При симметрии это сильная проверка, но политика или multihoming могут создавать асимметрию и ложные отбрасывания.

Наиболее свободный режим uRPF проверяет лишь наличие любого маршрута к адресу отправителя. Это уменьшает число ошибочных отказов, но почти устраняет привязку к направлению: префикс, достижимый где-либо, может быть совершенно неуместен на конкретном входе.

RFC 8704 определяет для каждого интерфейса список RPF — перечень префиксов, с которыми пакеты разрешено принимать на этом входе. Алгоритм A учитывает не только единственный лучший путь, но и не открывает доступ всей таблице. Если через интерфейс получен маршрут, объявленный определённой автономной системой, другие должным образом проверенные префиксы той же AS также могут быть допущены на этом входе.

Расширение условно. RFC предполагает фильтрацию префиксов и, где применяется, проверку происхождения. Маршрут от неверной стороны не становится надёжным из-за включения в список. Качество границы зависит от входных маршрутов и верного понимания соседства.

Для сложной топологии «провайдер—клиент» алгоритм B позволяет охватить известный клиентский конус. Это покрывает косвенные легитимные источники, но сильнее зависит от точных коммерческих отношений. Устаревший конус или ошибочная классификация peer расширяют границу за пределы договора.

ROA и IRR могут дополнять список, улучшая сведения о префиксе и происхождении, но сами по себе не разрешают конкретный интерфейс. Разрешение происхождения и входа — разные утверждения.

Издержки включают больший объём RPF-состояния, обновления во время переходных процессов BGP, расследование отбрасываний и управление исключениями. Источники не подтверждают всеобщую поддержку, внедрение в названной сети или измеренный эффект. Работа SAVNET показывает, что задача точности остаётся открытой, но не доказывает доступность будущей архитектуры сегодня.

Источники