RPKI и безопасность BGP
BGP обменивается маршрутами, а RPKI предоставляет данные для проверки их источников. Разбираемся, что защищает эта проверка, какие риски остаются и кто контролирует подтверждающие данные.
BGP передаёт анонсы маршрутов. Проверка источника маршрута сопоставляет заявленный источник с отдельными данными о разрешениях.
Сеть заявляет, что через неё доступен блок интернет-адресов. Должны ли другие сети ей верить? Именно этот вопрос стоит за сравнением BGP и RPKI. Они выполняют разные задачи: один обеспечивает обмен маршрутами, а другая предоставляет подтверждающие данные, которые помогают оценить заявленный источник маршрута.
Маршрут и данные, которые его подтверждают
BGP — протокол, с помощью которого независимо управляемые сети обмениваются информацией о достижимости. Блок адресов называется IP-префиксом; сеть, участвующая в этом обмене, идентифицируется номером автономной системы, или ASN. Для выбора маршрутов операторы используют анонсы и собственные политики. Этот обмен определён в RFC 4271.
Полученный анонс сам по себе не доказывает, что указанный в нём источник был разрешён держателем адресов. Неверный источник может появиться из-за ошибки конфигурации или попытки перехвата маршрута. На практике это может привести к тому, что сервис внезапно станет недоступен для пользователей, хотя его серверы продолжают работать.
RPKI добавляет систему сертификатов и подписанных записей. Разрешение на источник маршрута, или ROA, указывает ASN, которому разрешено анонсировать маршруты для заданных префиксов от своего имени. Программное обеспечение проверки проверяет подписанные материалы и предоставляет маршрутизаторам пригодные к использованию данные о разрешениях. Проверка источника маршрута, или ROV, сопоставляет анонсы с этими данными.
Проверка с определёнными границами
При сопоставлении проверяется, соответствуют ли ASN источника и длина анонсируемого префикса разрешению, охватывающему этот префикс. При этом не анализируется содержимое трафика и не подтверждается подлинность каждой сети в объявленном пути. Маршрут может пройти проверку источника и всё же распространиться туда, куда не должен.
RFC 6811 определяет три результата. Valid означает, что подходящее разрешение существует. Invalid означает, что охватывающие префикс данные есть, но ни одна запись не разрешает такое сочетание источника и длины префикса. NotFound означает, что в используемых данных нет разрешения, охватывающего префикс. Это состояния подтверждающих данных, а не окончательный вердикт о безопасности или вредоносности маршрута.
Дальнейшие действия зависят от политики, настроенной принимающим оператором. Сеть может отклонять анонсы со статусом Invalid; одна лишь публикация ROA не заставляет все остальные сети выполнять такую проверку. Механизмом обмена маршрутами остаётся BGP.
Почему это различие важно при сбое
Представьте перенос сервиса на новый ASN источника, когда в разрешении всё ещё указан только прежний. Новый анонс может получить статус Invalid. Исправление начинается с сопоставления задуманного анонса, фактически используемых данных о разрешениях и политики, которая его отклонила. Покупка другого маршрутизатора или предположение о повреждении кабеля не устраняют причину.
Операторам по-прежнему нужны подходящие фильтры, надёжное ПО проверки, мониторинг и согласованное внесение изменений. Проверка источника — один из полезных инструментов этой работы; если воспринимать её как универсальную печать безопасности, оставшиеся зависимости окажутся скрыты.
Кто контролирует подтверждающие данные?
В заметке 28 Лу Хэн проводит границу между ведением записей и их использованием для наказания участников. Тот, кто ведёт реестр, может влиять на работающие сети, если другие полагаются на его записи. Само по себе это влияние не даёт полномочий управлять всеми затронутыми участниками в разных странах.
В заметке 64 он предлагает общие правила, ограниченные тем, что необходимо для уникальности, совместимости и безопасности, с локальной проверкой и добровольным принятием последующих изменений. Замысел состоит в том, чтобы сделать надёжную координацию заменяемой, а не навсегда превратить одного администратора в незаменимого.
Для оператора ближайший вопрос носит практический характер: может ли ваша команда проследить путь от разрешения на маршрут до решения, принятого принимающей сетью? Начните с этого, а затем прочитайте, как подготовить и поддерживать разрешение на источник маршрута. Разобраться в этих связях проще, пока сервис ещё работает.