Кратко

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

После обновления зеркала генератор фильтров выдаёт тот же объём данных, что и вчера. Проверка количества проходит. Через час другой генератор возвращает список той же длины, но не того же состава. В журнале остался только корневой набор и готовый файл. Между ними исчезли решения о том, в каком реестре брать каждый одноимённый объект.

draft-ietf-grow-rpsl-registry-scoped-members-00 делает одно из таких решений явным. Проект добавляет src-members к классам RPSL as-set и route-set. Запись RIPE::AS-EXAMPLE содержит и первичный ключ набора, и имя реестра, где его надо искать.

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

Одно имя в нескольких источниках

Набор RPSL может непосредственно содержать номера автономных систем или префиксы, а может ссылаться на другие наборы. Ссылки раскрываются рекурсивно. Реестры IRR независимы, и глобальная уникальность первичных ключей между ними не гарантирована. На сервере, зеркалирующем несколько источников, могут находиться одноимённые объекты.

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

Резолвер с поддержкой src-members обязан сопоставлять имя реестра и ключ вместе. Если названный реестр ему неизвестен, подходящего набора нет. Тихая замена на неквалифицированную копию отменила бы явное решение автора.

После выбора дочернего объекта действие префикса заканчивается. Его собственные ссылки рассматриваются по его атрибутам. Следующий src-members может назвать другой реестр. Старые members или mp-members возвращают поиск к прежнему алгоритму выбора источника. Область родителя не наследуется потомками.

Начальный параметр запроса имеет ту же границу. Программа должна позволять ограничить поиск корня реестром, но не должна переносить ограничение на последующее раскрытие. Запуск от RIPE::RS-FIRST не доказывает, что каждый объект результата получен из RIPE.

Совместимость оставляет второе исполнение

Переход задуман постепенным. Старые программы не знают src-members, а существующие объекты будут обновляться не одновременно. Поэтому members и mp-members сохраняются. Авторитетный реестр должен проверить, что каждая новая ссылка после удаления префикса присутствует и в старых атрибутах.

Если пользователь передал только src-members, авторитетной программе рекомендуется автоматически заполнить старое поле значениями без префиксов. Если старые поля переданы самим пользователем, менять их нельзя. Неавторитетный сервер не должен создавать такую проекцию.

В обратную сторону преобразование запрещено. Из RS-SECOND невозможно надёжно вывести RIPE::RS-SECOND: отсутствует как раз источник. Выдумывать его при миграции означает вернуть скрытый выбор под видом восстановленных данных.

Один прошедший проверку объект получает два законных прочтения. Современный резолвер выбирает RIPE::RS-SECOND. Старый видит RS-SECOND и применяет собственный порядок реестров. Проверка устанавливает совпадение имён после удаления области, но не тождество извлечённых объектов.

Чтобы не разрушить старую проекцию, проект запрещает совместно указывать RIPE::AS-OTHER и ARIN::AS-OTHER. В новом поле это разные ссылки, а в старом обе становятся AS-OTHER. Совместимость ограничивает более точный язык, потому что прежнее представление не способно сохранить различие.

Такой компромисс облегчает внедрение. Он же не позволяет считать приём объекта реестром доказательством одинакового результата у всех потребителей.

Протокол происхождения раскрытия

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

Daniel Kade предлагает операторский протокол происхождения раскрытия. Это не поле IETF и не требование проекта. В начале протокол фиксирует корневой ключ, ограничение исходного запроса, реализацию и версию резолвера, включённую поддержку src-members, доступные реестры и проверяемый серийный номер, снимок или хеш каждой копии.

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

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

В конце результат связывается с версией компилятора политики, фильтрацией, нормализацией, хешем конфигурации, заявкой на изменение и целью развёртывания. Иначе доказательство корректного запроса не подтверждает, что на устройства попал проверенный артефакт.

Известный источник ещё не делает данные истинными

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

Публиковать секреты не требуется. Хеши объектов и результатов, идентификаторы источников, роли, разницы и номера изменений сохраняют последовательность без раскрытия учётных данных и полной политики.

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

Проект требует обнаруживать циклические ссылки и рекомендует ограничивать глубину или размер раскрытия. Изменение таких пределов способно изменить политику без изменения RPSL. Поэтому они входят в доказательство и повторную проверку.

src-members раскрывает один ранее невидимый выбор источника. Нельзя позволить итоговому экспорту снова его стереть. Префикс действует один шаг; ответственность заканчивается только после прослеженного развёртывания.

Источники

  1. Карточка проекта о членах RPSL с областью реестра
  2. История текущего проекта
  3. Редакция 00 в HTML
  4. Редакция 00 в тексте
  5. XML редакции 00
  6. Карточка предшествующего проекта
  7. История предшественника
  8. Редакция 01 предшественника
  9. Устав рабочей группы GROW
  10. Документы GROW
  11. Сообщение о принятии проекта GROW
  12. Исходный репозиторий авторов
  13. RFC 2622: Routing Policy Specification Language
  14. RFC 4012: следующее поколение RPSL
  15. RFC 2725: безопасность системы политик маршрутизации
  16. RFC 2650: применение RPSL на практике
  17. RFC 7682: соображения по IRR и конфигурации политик
  18. RFC 7909: постановка задачи и RPKI для проверки источника
  19. Lu Heng: минимальная начальная спецификация, локализованное будущее решение и добровольное внедрение
  20. Lu Heng: The Policy Mirror