Кратко

  • Автор RFC 7115 Randy Bush требует перед выпуском ROA на покрывающий блок проверить правильные ROA для всех субвыделений, объявляемых другими AS, в том числе клиентами. Пропущенное объявление может получить оценку Invalid.
  • Данные о разрешениях проходят через валидирующие кэши к маршрутизаторам; их дальнейшее применение задаёт локальная политика сети. Bush советует иметь несколько кэшей, включая локальный, и поддерживать их синхронность.

Чья подпись — чей красный индикатор

Между большой адресной сетью и её маленькими участками есть административная лестница. Владелец решает подписать ROA на весь блок. Клиент уже использует субвыделение и объявляет его через свой AS. После обновления данных RPKI маршрутизатор может поставить рядом с клиентским объявлением слово Invalid. Клиент не менял BGP-анонс. Изменилось разрешение над его префиксом.

Эту ловушку Bush описал в RFC 7115, документе Best Current Practice от января 2014 года. Перед ROA для суперблока оператор обязан убедиться, что у всех субвыделений, объявляемых другими автономными системами, есть правильные ROA. Иначе анонсы без собственных разрешений будут оцениваться как Invalid. На время оформления клиентских ROA документ допускает использовать живые данные BGP как основу для разрешений по доверенности. Сначала список участков и их AS, затем подпись сверху.

Результат вычисляется по правилам RFC 6811. Префикс и AS происхождения объявления сопоставляются с валидированными данными ROA; возможные состояния — Valid, NotFound и Invalid. Когда появляется покрывающий ROA, более конкретный маршрут может не совпасть с указанным происхождением или допустимой длиной. Дальше оператор применяет локальную политику. В сети, где Invalid отбрасывают, бумажная ошибка владельца затронет прохождение маршрута.

Путь данных до маршрутизатора описан в RFC 6810, написанном Bush вместе с Rob Austein. Валидирующий кэш передаёт проверенные сведения о происхождении. В RFC 7115 Bush рекомендует подключать маршрутизатор более чем к одному кэшу, с хотя бы одним локальным. Кэши внутри AS, если от них зависят маршрутные решения, следует синхронизировать не реже чем раз в четыре–шесть часов. Данные, полученные от кэша провайдера выше по цепочке, получателю следует проверить самому. Действие владельца блока проходит через несколько независимых операционных рук.

Биография Bush на сайте RIPE NCC описывает его долгую работу над безопасностью маршрутизации, RPKI и проверкой происхождения. В RFC чувствуется внимание к разнице между подписанной записью и поведением сети. Для редакционного портрета использована фотография с его именем на сайте RIPE NCC; два шкафа оборудования на заднем плане придуманы для статьи.

В этой истории важнее всего точность простой таблицы. Для каждого клиентского участка нужен префикс, AS объявления и подходящий ROA. Если одной строки нет, чужой маршрутизатор может получить иной результат проверки. Bush перенёс этот контроль на этап до публикации, когда исправление ещё находится в руках владельца.