Роль RPKI в укреплении безопасности глобальной маршрутизации

Общие подтверждающие данные проверяются каждой сетью отдельно. Их действие зависит от получаемых данных и применяемых политик.

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

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

Что именно проверяется?

Сети обмениваются информацией о достижимости с помощью BGP. Префикс — это блок IP-адресов; ASN идентифицирует автономную систему. Разрешение на источник маршрута, или ROA, указывает, какому ASN держатель разрешает быть источником маршрутов для заданных префиксов.

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

Три результата с разным смыслом

• Valid: хотя бы одно разрешение, охватывающее префикс, допускает заявленный источник и длину префикса.
• Invalid: данные о разрешениях, охватывающих префикс, существуют, но ни одна запись не допускает такое сочетание.
• NotFound: в используемых данных нет разрешения, охватывающего префикс маршрута.

Эти правила определены в RFC 6811. В частности, отсутствие охватывающего ROA — не то же самое, что маршрут со статусом Invalid. И статус Valid не означает, что подлинность всего объявленного пути подтверждена.

Где защита вступает в действие

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

RFC 8481 прямо определяет роль оператора: присвоение статуса проверки отделено от действий на его основе. Единого глобального переключателя, который заставил бы все сети одновременно следовать одной политике, не существует.

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

Система подтверждающих данных тоже требует внимания

Разрешение с неверным ASN или без предусмотренной длины префикса может привести к тому, что правомерный анонс маршрута получит статус Invalid. Проблемы с репозиторием, сертификатом или валидатором также могут изменить данные, доступные маршрутизаторам. Разные кэши и сроки обновления означают, что разные сети не обязательно получат одну и ту же картину одновременно.

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

Защита не должна превращаться в постоянную зависимость

Это также вопрос устройства институтов. Организация, контролирующая необходимые подтверждающие данные, может влиять на сети, которыми она не управляет и интересы которых политически не представляет. В заметке 28 Лу Хэн утверждает, что функция регистратуры должна оставаться точным администрированием, а не становиться средством принуждения.

Его заметка 64 задаёт более требовательную цель проектирования: общие правила должны быть минимальными и проверяемыми локально, записи — переносимыми, а будущие изменения должны зависеть от добровольного принятия участниками. Безопасность и возможность заменить координатора, который не справляется со своими функциями, нужно закладывать в систему вместе.

Срочность здесь вполне конкретна. Когда пользователи уже потеряли доступ, выяснение того, кто контролирует необходимую запись, становится чрезвычайной задачей. Проследите эти зависимости, пока сети работают. Затем разберитесь, как изменение записи может привести к отклонению маршрута.