Кратко

  • 28 августа IESG открыл Last Call по draft-ietf-sidrops-publication-server-bcp-10; документ предназначен для статуса Best Current Practice, а Datatracker указывает окончание обсуждения 11 сентября.
  • Проект использует MUST, SHOULD и RECOMMENDED по BCP 14, но прямо говорит, что эти слова подчёркивают эксплуатационную важность и не являются формальными требованиями к реализации.
  • Если документ станет BCP, он зафиксирует прошедшую рассмотрение практику IETF. Он не подтвердит автоматически, что конкретный оператор внедрил контроль или соблюдал его во время сбоя.
  • Для этого нужен версионный отчёт о реализации: точные разделы, архитектура, заявленное состояние, исключения, метод и окно измерения, восстановление, смена сессии RRDP, уведомления и завершение повторной синхронизации.
  • Источники не позволяют объявить какой-либо RIR, NIR, удостоверяющий центр, сервис публикации или CDN соответствующим либо не соответствующим проекту.

Подпись заканчивается раньше, чем эксплуатационная цепочка

Удостоверяющий центр создаёт подписанный объект RPKI. Механизм публикации принимает изменения по RFC 8181. Публичные репозитории RRDP и rsync предоставляют получившееся состояние. Relying parties загружают и проверяют данные, после чего каждая сеть решает, как использовать результат в своей политике. Между первым и последним шагом несколько владельцев, часов и наблюдаемых состояний.

Корректно подписанный ROA может ещё не появиться на публичной стороне. Механизм может принять изменение, пока один из узлов чтения показывает предыдущий набор. Восстановление из резервной копии может вернуть целостное, но более старое состояние. Файл уведомления RRDP может стать видимым раньше указанных в нём snapshot и delta. Ни один из этих случаев не означает, что криптография RPKI бесполезна. Они означают, что подпись не является журналом доставки и восстановления.

Именно этой промежуточной системой занимается версия 10 проекта Best Practices for Operating Resource Public Key Infrastructure (RPKI) Publication Services. В ней собран опыт разделения функций, обеспечения доступности, восстановления после потери данных, синхронизации, DNS- и маршрутных зависимостей, двух семейств адресов, CDN, балансировки и согласованности выдаваемых представлений. Новый формат объекта не вводится; документ систематизирует более десяти лет эксплуатации.

Оговорка после заглавных букв меняет тип утверждения

RFC 2119 определяет силу ключевых слов требований, а RFC 8174 уточняет, что особый смысл BCP 14 относится к написанию заглавными буквами. Раздел 2.1 проекта ссылается на эти правила, а затем добавляет собственную оговорку: термины используются для подчёркивания важности операций и не требуются в качестве формальных требований к реализации.

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

Будущий статус BCP имел бы реальный вес, но не отменил бы границу. RFC 7841 описывает категории и сведения о происхождении документов в серии RFC. Рассмотрение и консенсус объясняют, почему рекомендация заслуживает доверия. Они не отвечают на вопросы о том, какая система была проверена, за какой период, по какой методике и что произошло при последнем восстановлении.

Консенсус создаёт эталон практики. Данные о реализации описывают конкретную установку.

Одному проценту доступности здесь тесно

Проект требует высокой доступности как публичного содержимого, так и механизма публикации. Но последствия различны. При недоступности RRDP или rsync relying parties не могут штатно получить текущее состояние. При недоступности механизма удостоверяющий центр не может распространить новые выдачи и отзывы. Длительный перерыв способен привести к устареванию manifests, списков отзыва и подписанных объектов.

Общий процент скрывает различие. Полезный отчёт раздельно измеряет механизм для издателей, RRDP и rsync, указывает знаменатель, окно, исключения и запас времени до устаревания валидных данных. Успешный HTTP-ответ не показывает, появился ли ожидаемый объект.

Проект рекомендует размещать механизм публикации отдельно от машин, обслуживающих публичные запросы RRDP и rsync. Это разделяет судьбу канала изменений и внешней нагрузки чтения. В открытом отчёте можно описать логическое разграничение и домены отказа, не раскрывая адреса, ключи или опасные детали топологии.

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

Восстановление проверяет не обещание, а последовательность

Если восстановление приводит к регрессии содержимого, сервер, согласно проекту, обязан сбросить сессию RRDP. Зависимые удостоверяющие центры следует уведомить, чтобы они начали полную повторную синхронизацию.

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

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

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

Serial и manifest доказывают разное и не доказывают всё

RRDP использует идентификатор сессии и серийный номер, delta для отдельных событий и snapshot для полного текущего представления. Рост serial показывает, что в этой сессии опубликованы более поздние ревизии. Сам по себе он не подтверждает, что желаемый набор издателя принят, все узлы балансировки показывают одинаковые файлы или каждая relying party увидела изменение.

Поэтому проект требует, чтобы файл уведомления не становился видимым раньше указанных в нём snapshot и delta. В системе с несколькими backend каждый должен предоставлять согласованное представление. Порядок доступности — часть корректности, а не косметика доставки.

RFC 9286 даёт другой ограниченный вид доказательства. Manifest перечисляет имена файлов и хеши, помогая выявлять определённые случаи подмены старой версией, удаления или изменения при передаче. Но он не измеряет срок уведомления о работах, возраст резервной копии, согласованность балансировки, доступность IPv4/IPv6, настройки CDN и поддержку издателей.

Объединить все эти факты в ярлык соответствует BCP — значит скрыть пределы проверок, а не провести проверку.

Консолидация не делает поставщика регулятором

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

Это эксплуатационный довод в пользу консолидации, а не исключительная политическая или юридическая франшиза для RIR, NIR либо коммерческой компании. Тот же проект признаёт, что небольшой редко меняющийся репозиторий может обеспечить высокую доступность скромными средствами, и описывает несколько схем для последующих уровней CA.

Отчёт о реализации должен сохранить этот выбор. Сначала он называет архитектуру — собственная, родительская, сторонняя или через посредника, — а затем применяет относящиеся к ней меры. Статус не применимо допустим с ограниченным объяснением. Молчание недопустимо, поскольку побуждает читателя предположить самый сильный вариант.

Как должен выглядеть версионный отчёт

Первый блок определяет объект заявления: оператор, сервис, архитектура, публичные идентификаторы репозитория, класс клиентов и точная версия проекта либо RFC. Ссылка только на «BCP IETF» становится двусмысленной после изменения текста.

Во втором блоке находится реестр мер. Каждый существенный раздел получает устойчивую строку и статус: реализовано, не применимо, запланировано, исключение или неизвестно. Указываются автор заявления, дата проверки и причина исключения. Исправления добавляют новую версию, а не стирают старое состояние.

Третий блок определяет доказательства. Для задержки публикации нужны класс объекта, начальное событие, конечное наблюдение, точки, период, процентили, сбои и исключения. Доступность разделяется по механизму, RRDP и rsync. Свежесть CDN получает правило кеширования и наблюдаемую проверку. Для балансировки нужен безопасный тест на расхождение представлений.

Четвёртый блок описывает изменения и восстановление: обслуживание, регрессия, сброс RRDP, уведомление, запрос синхронизации, завершение и неустранённые расхождения. Пятый ограничивает вывод: заявление оператора, независимое измерение, договорной аудит или разбор инцидента, а также период и системы.

Такой отчёт менее эффектен, чем знак соответствия. В этом его достоинство: каждую строку можно проверить, оспорить и обновить.

Чего источники пока не устанавливают

Last Call не означает принятия и не гарантирует неизменность текста. IESG может получить замечания, запросить доработку, рассматривать следующую версию или отказаться от публикации. Номер RFC или BCP ещё не присвоен.

Организации авторов — среди них RIPE NCC, ARIN, APNIC и BSD — не являются аудиторской выборкой. Авторство не подтверждает внедрение каждой рекомендации. Проект также не называет оператора, который неправильно восстановил данные, выдавал несогласованное содержимое или скрывал перерыв.

Нет оснований считать, что будущий BCP заменит договор, закупочное условие, регулятора, судебное решение или локальную политику маршрутизации. RFC 8181 определяет обмен при публикации, RFC 8182 — распространение репозитория, RFC 9286 — manifests. Это важные технические состояния, но не свидетельства работы организации.

Корректный вывод уже: IETF рассматривает подробный кандидат на описание эксплуатации сервисов публикации. Если он станет BCP, документальный авторитет усилится. Конкретному оператору всё равно придётся показать ограниченные доказательства того, какие разделы он действительно выполняет.

Источники

  1. IESG — Last Call по проекту о сервисах публикации RPKI
  2. IETF Datatracker — карточка проекта BCP
  3. IETF Datatracker — версия 10 проекта
  4. RFC 2119 — ключевые слова уровней требований
  5. RFC 8174 — уточнение регистра букв
  6. RFC 7841 — потоки, категории и шаблоны RFC
  7. RFC 8181 — протокол публикации RPKI
  8. RFC 8182 — RPKI Repository Delta Protocol
  9. RFC 9286 — manifests RPKI
  10. RFC 7115 — эксплуатация проверки происхождения на основе RPKI