Как работает инфраструктура открытых ключей для адресных ресурсов
Проследим путь разрешения RPKI от держателя адресов до маршрутизатора и разберём доводы Лу Хэна в пользу надёжного сервиса со сменяемым администратором.
Для проверки нужны актуальные подтверждения: при изменениях в сетях сертификаты, разрешения и системы публикации должны оставаться согласованными.
Вы переносите сервис в другую сеть. Серверы исправны, адреса не изменились, но часть посетителей больше не может до него добраться. Одна из возможных причин удивительно проста: записи, используемые для маршрутизации в Интернете, по-прежнему разрешают анонсировать эти адреса старой сети.
RPKI придаёт такому разрешению форму, которую могут проверить другие сети. Посмотрим, как оно проходит путь от держателя адресов до маршрутизатора и почему Лу Хэн считает, что работа этого механизма никогда не должна зависеть от сохранения власти одного администратора. Для краткого знакомства с темой начните с материала о том, что защищает RPKI.
1. Установить, кто вправе выдавать разрешения для адресов
Группа IP-адресов называется префиксом. Сеть, анонсирующая этот префикс, обозначает себя номером автономной системы — ASN. RPKI, инфраструктура открытых ключей для адресных ресурсов, с помощью сертификатов устанавливает, кто может выдавать разрешения для определённых диапазонов адресов.
Эти сертификаты образуют цепочку, ведущую к доверенному корневому сертификату. Её иерархия следует системе распределения номерных ресурсов Интернета, описанной в RFC 6480. Она подтверждает сведения о ресурсах внутри этой системы, но не наделяет удостоверяющий центр политическими полномочиями в отношении людей, пользующихся Интернетом.
2. Опубликовать подписанное разрешение
Держатель адресов публикует разрешение на объявление источника маршрута — Route Origin Authorisation, или ROA. Его содержание конкретно: этот ASN может быть источником анонса этого префикса. Быть источником означает быть сетью в начале объявленного маршрута; разрешение не относится ко всем сетям, которые затем передают трафик.
В ROA можно также задать максимальную длину префикса: насколько мелкими могут быть объявляемые части исходного диапазона адресов. Без этого необязательного параметра разрешена только указанная длина префикса. Так «разрешение для этого диапазона» не превращается незаметно в разрешение для любого возможного его разбиения. Формат подписанной записи определён в RFC 9582.
3. Превратить опубликованные записи в проверенные данные
Подписанные записи размещаются в репозиториях публикации. Программа-валидатор собирает их и проверяет цепочку сертификатов, подписи, сроки действия и сведения об отзыве, а также манифесты с описанием опубликованных объектов. Одного доступного для чтения файла недостаточно: подтверждающие его данные тоже должны пройти проверку.
Валидатор формирует пригодные для использования данные о разрешениях, которые часто называют Validated ROA Payloads, или VRP, — проверенными данными ROA. Они содержат префикс, разрешённый ASN источника и максимальную длину. Маршрутизаторы получают результаты из доверенного кэша по протоколу RPKI-to-Router, описанному в RFC 8210. Им не приходится запрашивать разрешение у регистратора каждый раз, когда посетитель открывает страницу.
4. Сопоставить маршрут с разрешением
BGP — протокол, с помощью которого сети объявляют маршруты. Получающий объявление маршрутизатор сопоставляет префикс маршрута и ASN его источника с проверенными разрешениями. Это и есть проверка источника маршрута — Route Origin Validation, или ROV.
Valid — действительный: разрешение, охватывающее префикс, допускает и указанный источник, и длину префикса. Invalid — недействительный: разрешения, охватывающие префикс, существуют, но ни одно не допускает такого сочетания. NotFound — не найдено: ни одно разрешение не охватывает префикс. Это результаты сопоставления, а не суждения о чьих-либо намерениях. Оператор решает, как использовать их в своей политике маршрутизации. См. RFC 6811.
Вернёмся к переносу сервиса. Если разрешение по-прежнему выдано старому ASN, а новому — нет, новый анонс может получить статус Invalid. Сети, отфильтровывающие маршруты со статусом Invalid, могут его отклонить. Решение — согласовать изменение разрешений с переносом, в том числе предусмотреть период, когда разрешения нужны обеим сетям, а не считать исправность серверов гарантией доступности. Эксплуатационные меры предосторожности рассматриваются в RFC 7115.
5. Поддерживать работу всей цепочки
Проверка источника помогает отклонять ложные заявления об источнике маршрута. Она не проверяет каждый переход, не шифрует трафик и не выявляет все утечки маршрутов. При утечке разрешённый источник может сохраняться. Поэтому другие средства защиты маршрутизации по-прежнему необходимы.
Подтверждающие данные тоже требуют сопровождения. Сроки действия сертификатов истекают; разрешения и публикуемые данные меняются. Удаление ROA не обязательно вызывает немедленное отключение: итоговый результат проверки зависит от других доступных записей, а последствия для маршрутизации — от локальной политики. В RFC 8211 рассматривается, как ошибки или неблагоприятные действия удостоверяющих центров и операторов репозиториев могут повлиять на систему.
Предложение Лу Хэна: сохранить сервис, обеспечить смену администратора
В заметке 70 Лу Хэн оспаривает привычный скачок в рассуждении: раз сервис регистрации необходим, его нынешний оператор должен быть незаменимым. Сетям нужны точные записи и работающая защита. Из этого не следует вечное право какого-либо учреждения контролировать их.
Предлагаемая им альтернатива делает непрерывность свойством самой системы: записи, доступные для независимого аудита, проверенная передача функций квалифицированному преемнику и возможность сменить администратора, не заставляя сети менять адреса. Он прямо признаёт, что RPKI нельзя передать простым копированием каталога. Ключи, сертификаты, публикация и доверие должны оставаться согласованными на всём протяжении перехода.
Это требование к устройству системы, которое он отстаивает, а не утверждение, будто такая переносимость уже доступна повсеместно. Оно учитывает обе стороны проблемы: неосторожная замена может нарушить проверку, а незаменимый распорядитель доступа способен превратить зависимость от него во власть. Надёжность сервиса и сменяемость его администратора необходимо проектировать вместе.
Почему эту возможность нужно создать до кризиса?
Когда спор затрагивает цепочку сертификатов, его последствия могут выйти далеко за круг спорящих сторон. Клиенты не выбирали этот конфликт, но могут расплачиваться за него нарушением связи. Если порядок передачи функций начинают придумывать во время сбоя, защитить клиентов от этой неопределённости уже не успели.
Лу Хэн предлагает заранее обеспечить непрерывность работы и право уйти, не позволяя превращать административные споры в оружие против работающих сетей. Полная аргументация изложена в заметке 70: защищать реестр, а не распорядителя доступа.