Кратко

  • RFC 8206 требует, чтобы PE, локально настроенный с двумя ASN, имел действующие ключи для обоих и сохранял старый, пока не мигрируют относящиеся к нему eBGP-сессии. Это условие аутентификации пути, а не корпоративный акт.
  • Параллельные ROA, две подписи и сегмент pCount=0 являются ограниченными фактами маршрутизации. Они не доказывают поглощение, контроль, перенос всех сессий, согласие партнёра, доставку пакетов или успех сервиса.

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

RFC 8206 рассматривает возможную миграцию автономной системы. Провайдер может объединить AS, сохранять старые ASN на переходный период и заставить PE выглядеть для соседа как старая ASN. Это инженерный сценарий, а не сообщение о конкретном слиянии. Миграция может быть долгой; документ не требует одновременной смены всех маршрутизаторов и не требует координировать её с каждым клиентом. Старая ASN может быть нужна потому, что одна локальная eBGP-смежность ещё ожидает именно её.

Параллельные ROA не меняют границы вывода. Новая ASN может нуждаться в ROA для префикса, который старые PE продолжают анонсировать. RFC допускает две авторизации происхождения. ROA говорит о разрешении ASN быть origin для целей проверки происхождения в RPKI. Он не является правоустанавливающим документом, записью о передаче в реестре, согласием клиента, результатом выбора маршрута или свидетельством завершённой миграции.

По RFC 8205 RPKI-сертификаты удостоверяют выделения номеров AS и IP-пространства. Отправитель подписывает соответствующим закрытым ключом, а валидатор не нуждается в самом ключе. Поэтому положительная проверка относится к Secure_Path и к локально настроенной доверительной и коммерческой политике проверяющего. Она не доказывает выбор FIB, прохождение пакета, работу приложения, выполнение договора или смену корпоративного контроля.

Решение RFC 8206 имеет ещё более узкий контур: PE локально настроен с новым и старым ASN и уже имеет eBGP-соседа. На выходе PE подписывает от имени обоих ASN, а переходная часть старой ASN получает pCount=0. Для соседа без BGPsec реконструированный AS_PATH этой части не показывает, хотя она остаётся в Secure_Path. На входе PE добавляет сегмент в указанном условии, если CE всё ещё ожидает старую ASN. Этот приём сохраняет корректную семантику на известной границе, а не рассылает по сети заявление о слиянии.

RFC прямо не принимает предположение, что нескоординированный клиентский домен согласится с pCount=0. Она не требует удалённой перенастройки CE, глобальной синхронизации или видимо более длинного пути. В этом и состоит ценность минимального общего правила: оно работает для совместимого локального набора. Но по нему нельзя судить, что сделали, приняли или завершили участники за пределами этой границы.

Требование хранить старый ключ до миграции всех релевантных eBGP-сессий также является обязанностью оператора PE, а не опубликованным счётчиком готовности. Один подписанный update не сообщает, что неперенесённых сессий больше нет. Для этого нужны инвентарь сессий, конфигурация PE, сроки действия ключей, журналы валидатора и независимые измерения forwarding и сервиса. Каждый удалённый валидатор принимает решение по своей политике.

Принцип Heng Lu о минимальной исходной спецификации объясняет эту сдержанность. Общий слой устанавливает лишь детерминированный минимум для интероперабельности и безопасности. Сроки, хранение ключей, политика соседей, согласование с клиентами и действительное добровольное принятие остаются локальными решениями. Принятие становится операционным фактом там, где совместимые стороны реализуют, проверяют и принимают; публикация RFC или видимый ключ этого не заменяют.

Поэтому доказательства следует хранить ступенями: правило RFC, ROA, состояние ключа, подписанный путь, решение валидатора, статус сессии, наблюдаемые forwarding и сервис, а затем отдельно реестровые и корпоративные документы. Wesley George — соавтор технической спецификации. Спецификация не делает старый ключ объявлением о слиянии.

Источники