Что такое RPKI? Руководство по безопасности маршрутизации для начинающих
Как RPKI проверяет источники маршрутов, что означают результаты проверки и почему Лу Хэн считает, что надёжная безопасность требует также ограничить власть регистратур.
Проверка того, кто может объявлять маршрут, похожа на проверку разрешения перевозчика обслуживать район. Она не гарантирует безопасность каждого участка пути.
Сайт может работать идеально и всё же стать недоступным. Где-то между его сетью и посетителями другая сеть может объявить неправильный маршрут. Тогда трафик направляется туда, где его не могут доставить, или к тому, кто пытается его перехватить.
RPKI, сокращение от Resource Public Key Infrastructure, помогает сетям проверить одно важное утверждение: уполномочена ли эта сеть объявлять эти IP-адреса? Понимание этой проверки также открывает более глубокий вопрос. Кто контролирует записи, от которых зависит проверка?
Начните с утверждения, которое делает сеть
Интернет — это сеть сетей. BGP, протокол пограничного шлюза, позволяет им обмениваться объявлениями о том, как достичь групп IP-адресов. Такая группа называется префиксом. Каждая независимо управляемая сеть маршрутизации обозначается номером автономной системы, или ASN.
Представьте, что служба доставки объявляет: «Мы можем доставлять в этот район». Другим компаниям нужен способ проверить это утверждение. В маршрутизации неправильное объявление может быть результатом опечатки или намеренного захвата маршрута. Одни только объявления BGP не доказывают, что сеть, указанная как источник маршрута, имеет право его объявлять.
Что делают RPKI, ROA и валидация
RPKI предоставляет инфраструктуру сертификатов для интернет-ресурсов. Владелец адресов может опубликовать подписанный Route Origin Authorization, или ROA. В нём указывается ASN, которому разрешено объявлять определённый префикс, а также, если это задано, насколько мелкие части этого диапазона можно указывать в объявлениях. Техническое определение приведено в RFC 9582.
Публикация ROA и проверка входящих маршрутов — разные задачи. Программное обеспечение валидации проверяет сертификаты и подписанные записи, а затем передаёт маршрутизаторам подтверждённые данные о разрешениях. Маршрутизаторы сравнивают объявления маршрутов с этими данными; операторы выбирают политику маршрутизации, которая будет применяться. Это сравнение называется Route Origin Validation, или ROV. Руководство RIPE NCC для операторов объясняет это разделение работы.
В примере со службой доставки одна сторона публикует сведения о том, кто может обслуживать район, а другие стороны проверяют это разрешение. Сертификат является доказательством внутри этой системы. Он не доказывает, что каждая последующая доставка будет безопасной.
Три результата, а не простое «да» или «нет»
Valid: как минимум одно подтверждённое разрешение охватывает объявленный префикс и допускает указанный ASN-источник и такую длину префикса. Invalid: имеются разрешения, охватывающие этот префикс, но ни одно не разрешает такую комбинацию. NotFound: в данных валидации нет охватывающего разрешения.
NotFound не означает, что обнаружен злоумышленник. Invalid сам по себе не объясняет, вызван ли результат атакой или ошибкой конфигурации. Эти состояния описывают результат сравнения, как определено в RFC 6811.
Что эта защита может и чего не может вам сообщить
Валидация источника может помочь сетям отклонять несанкционированные источники маршрутов. Она не аутентифицирует каждую сеть на пути, не шифрует соединение посетителя и не гарантирует доступность сайта. Утечка маршрута может сохранить разрешённый источник и пройти эту проверку. Фильтрация и мониторинг по-прежнему должны выполнять свою работу; RPKI — лишь часть безопасности маршрутизации.
Для операторов полезная подготовка начинается с их фактических объявлений: какие префиксы они объявляют, через какие ASN и совпадают ли опубликованные разрешения с этими данными. Поддерживать такие записи и валидаторы в рабочем состоянии не менее важно, чем включить настройку маршрутизатора. RFC 7115 рассматривает операционные аспекты.
Сами записи — источник власти
Обычно используемая иерархия доверия RPKI следует за распределением ресурсов, а в её основании находятся региональные интернет-регистратуры. Поэтому проверка зависит не только от надёжной математики: она также зависит от центров сертификации и систем публикации, поставляющих записи.
Изменение или отзыв записей может изменить результаты валидации. Это не означает автоматически отключение всего интернета: эффект зависит от других доступных разрешений и политик маршрутизации операторов. RFC 8211 рассматривает неблагоприятные действия и ошибки центров сертификации и администраторов репозиториев. Механизм безопасности может уменьшить один риск и одновременно создать зависимости, заслуживающие внимания.
Аргумент Лу Хэна: защищать сеть и ограничивать привратника
В Заметке 28 «Почему регистратуры никогда не должны становиться органами принуждения» Лу Хэн проводит чёткую границу: ведение адресной книги не должно превращаться во власть наказывать её пользователей. Его возражение касается полномочий, на которые претендуют администраторы, а не необходимости точных записей. Небольшая самоназначенная группа не получает мандат на управление сетями разных континентов лишь потому, что обслуживает их систему координации.
В Заметке 64 он развивает предлагаемую альтернативу: общие правила должны охватывать минимум, необходимый для уникальности и безопасности, а доказательства участники должны проверять самостоятельно. Записи и доказательства должны быть переносимыми; операторы должны иметь возможность заменить поставщика услуги, не отказываясь от идентичности своей сети. Будущие изменения должны распространяться благодаря своей полезности, а не благодаря постоянному административному контролю.
Это направление перестройки координации, а не утверждение, будто альтернативная система RPKI уже развёрнута повсеместно. Она всё равно должна сохранять совместимые записи и надёжную проверку. Самая сложная задача — добиться обоих результатов: защиты от ложных утверждений и защиты от неподотчётной власти над доказательствами.
Почему об этом нужно думать до сбоя
Клиенты сети каждый день зависят от привычных ей адресов. Если зависимость обнаруживается только в момент изменения или исчезновения записей, восстановление уже становится проблемой работающего сервиса. Аргумент Лу Хэна в пользу изменений начинается здесь: ещё до возникновения спора встроить в систему непрерывность, независимую проверку и возможность уйти.
Чтобы проследить этот аргумент от критики к проектированию, прочитайте Заметку 64 Лу Хэна о минимальных общих правилах, локальных решениях и добровольном принятии.