Теоретические основы и архитектура

Безопасность внешней межоператорской маршрутизации BGP опирается на три механизма: фильтры на входе и выходе (prefix-list, AS-path), лимиты префиксов (Maximum-Prefix) и проверку происхождения маршрута RPKI ROV (Route Origin Validation, RFC 6811). 1. RPKI ROV: ROA (Route Origin Authorization, RFC 6482) - подписанная запись «префикс, допустимый Origin ASN, maxLength»; её подписывает владелец ресурсов сертификатом, выданным по иерархии RIR (RIPE NCC, ARIN, APNIC и другие trust anchors). Валидатор (Routinator, rpki-client, FORT) скачивает репозитории, проверяет подписи и передаёт маршрутизатору валидные связки по протоколу RTR (RFC 6810, версия 1 - RFC 8210; зарегистрированный порт TCP 323, многие валидаторы слушают непривилегированный порт, например 3323). Krill - это ПО удостоверяющего центра, а не валидатор. Маршрутизатор классифицирует каждый маршрут: Valid, Invalid (чужой Origin ASN или длина маски больше maxLength) или NotFound (ROA не найден). Политика оператора: Invalid отклоняется на входе, Valid можно предпочесть, NotFound принимается. ROV проверяет только Origin ASN: он не ловит подделанный AS-path (forged-origin) и утечки маршрутов, а при потере RTR-сессии дольше интервала expire кэш очищается и все маршруты становятся NotFound (fail-open). 2. Maximum-Prefix: защита памяти RIB. Если клиент или пир анонсирует больше префиксов, чем согласовано (например, более 100), маршрутизатор выводит предупреждение на пороге 75-90% и сбрасывает сессию при превышении лимита.

Почему BGP нужна внешняя защита

BGP не проверяет, имеет ли соседний AS право анонсировать префикс: любой пир может объявить чужую сеть (hijack) или передать дальше маршрут, который не должен был покидать его границу (route leak). Классические примеры: анонс подсети YouTube из AS Pakistan Telecom в 2008 году и утечка маршрутов через провайдеров в 2019 году. Защита строится в три слоя: фильтры префиксов и AS-path на входе и выходе (кого и что мы слушаем и анонсируем), лимиты на число префиксов (защита ресурсов) и проверка происхождения маршрута через RPKI (ROV, RFC 6811).

Фильтры на входе: что отбрасывать всегда

  • Bogon-префиксы: 0.0.0.0/8, 10.0.0.0/8, 100.64.0.0/10, 127.0.0.0/8, 169.254.0.0/16, 172.16.0.0/12, 192.0.2.0/24, 192.168.0.0/16, 198.18.0.0/15, 224.0.0.0/3 и их более длинные части (в списке используется le 32). Для IPv6 аналогично (::/8, fc00::/7, fe80::/10, ff00::/8, 2001:db8::/32).
  • Слишком длинные префиксы: в публичной сети обычно допускают не длиннее /24 (IPv4) и /48 (IPv6). Более длинные маршруты не распространяются и забивают таблицы.
  • Default route от пира, если он не договаривался о нём.
  • Bogon-AS в пути: AS 0 (RFC 7607), AS_TRANS 23456, зарезервированные для документации 64496-64511, частные 64512-65534 и 4200000000-4294967294 в пути, пришедшем из внешнего мира.
  • Клиентские фильтры строгие: список допустимых префиксов клиента строят по записям IRR/AS-SET (генераторы вроде bgpq4) и обновляют автоматически; клиентский трафик не должен иметь возможность стать транзитом между провайдерами.
  • Выход (egress): оператор анонсирует только собственные и клиентские префиксы. Маршруты, полученные от пиров и upstream, дальше пирам и upstream не передаются.

Лимит префиксов

maximum-prefix (Cisco), route-limit (Huawei) и prefix-limit (Junos) защищают память RIB/FIB и ломают сессию соседа, который внезапно отдаёт слишком много. Значение выбирают как реальное число плюс запас (на публичных пирах ориентируются на данные PeeringDB), порог предупреждения - 75-90%, после срабатывания сессию можно перезапускать автоматически (restart N минут / idle-timeout) либо держать в падении до ручного вмешательства. Счёт ведётся по-разному на разных платформах: часть учитывает все полученные префиксы, часть - принятые политикой. Это нужно проверить на целевом релизе, иначе фильтр на входе не даст достичь лимита.

RPKI и ROV: компоненты

  • ROA (Route Origin Authorization, RFC 6482) - подписанная запись: префикс, допустимый origin AS и maxLength. Подписывается ресурсным сертификатом RIR (RIPE NCC, ARIN, APNIC и другие trust anchor).
  • Relying party / validator (Routinator, rpki-client, FORT, OctoRPKI) скачивает репозитории, проверяет подписи и выдаёт список валидных связок (префикс, maxLength, ASN). Krill - это ПО удостоверяющего центра, а не валидатор.
  • RTR (RPKI-to-Router, RFC 6810, версия 1 в RFC 8210) - протокол, по которому роутер получает эти связки от валидатора. Зарегистрированный порт TCP 323; многие валидаторы по умолчанию слушают непривилегированный порт (например, Routinator - 3323). RTR может идти поверх SSH или TLS, но в лабораториях обычно открытый TCP.

Алгоритм ROV (RFC 6811)

Для маршрута (префикс P, origin AS - последний в AS-path) ищутся все ROA, покрывающие P. Если покрывающих ROA нет - состояние NotFound. Если есть ROA с тем же ASN и длиной P не больше maxLength - Valid. Иначе - Invalid (чужой ASN или слишком длинный префикс). ROA с ASN 0 (RFC 6483) делает префикс всегда Invalid. Политика оператора такова: Invalid отбрасывается, Valid можно предпочесть (например, Local-Pref 120), NotFound принимается с обычным приоритетом: для значительной части префиксов ROA ещё не создан, и их отказ нанёс бы ущерб трафику.

Как это работает на платформах

  • Cisco IOS-XE: bgp rpki server tcp задаёт валидатор, route-map получает условия match rpki valid|invalid|not-found. bgp bestpath prefix-validate allow-invalid оставляет Invalid-маршруты кандидатами на лучший путь, чтобы ими управляла политика (по умолчанию состояние само влияет на выбор). Состояние пересчитывается при каждом обновлении кэша, поэтому нужна возможность пересчёта (route refresh или хранение Adj-RIB-In).
  • Juniper Junos: routing-options validation group ... session подключает валидатор, политика использует from validation-database valid|invalid|unknown; состояние видно в show route ... detail (Validation State).
  • Huawei VRP: фильтры префиксов, AS-path и route-policy описаны в коде урока; настройка ROV зависит от релиза и вынесена в review.
  • MikroTik RouterOS v7: в уроке используются фильтры маршрутов (/routing/filter/rule) и лимит на соединении; ROV на RouterOS проверяйте по документации установленной версии.

Отказ валидатора: fail-open

Если RTR-сессия недоступна дольше интервала expire (по RFC 8210 по умолчанию 7200 секунд), роутер удаляет записи кэша, и все маршруты становятся NotFound: защита молча отключается. Поэтому держат минимум два валидатора в разных местах, следят за серийным номером кэша и за временем последнего обновления и поднимают тревогу при потере сессии. Локальные исключения (SLURM, RFC 8416) позволяют вручную добавить или отменить ROA.

Предотвращение route leak

Обычный приём - маркировка community по источнику: клиентские маршруты получают 65000:100, пиринговые 65000:200, upstream 65000:300, а исходящая политика к пирам и upstream разрешает только метку 65000:100 (и собственные). Новый подход - роли BGP и атрибут Only-to-Customer (RFC 9234): стороны объявляют роли (provider, customer, peer, rs-server, rs-client), а маршруты, нарушающие модель, отбрасываются автоматически. Поддержка зависит от релиза.

Защита самой сессии

Фильтры не помогают, если соседа можно подделать: аутентификация TCP MD5 или TCP-AO (RFC 5925) и GTSM (RFC 5082) настраиваются в лабораторной работе по hardening. Здесь важно помнить, что RPKI и фильтры проверяют содержимое анонса, а не то, кто на самом деле отправил TCP-сегмент.