Кратко

  • Если истекли все применимые ассоциации безопасности RSVP, проект рекомендует уведомить управление и считать последнюю бессрочной, пока её не продлят, не удалят или не заменят.
  • Это не признание старого ключа безопасным: решение не допускает отката к сообщениям без аутентификации и одновременно избегает резкого разрушения резервирований, способного расширить аварию.
  • Ротация доказана лишь тогда, когда преемник действует в нужной области, период перекрытия достаточен, часы надёжны, а каждый получатель завершил handshake.

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

RSVP Cryptographic Authentication Version 2, редакция 02, опубликована 27 сентября 2026 года и проходит Working Group Last Call в TEAS. Это по-прежнему Internet-Draft, претендующий на Proposed Standard, а не RFC и не свидетельство внедрения. В случае принятия он заменит RFC 2747 и RFC 3097.

Сам документ называет ситуацию «Pathological Case». Все ассоциации, способные защитить обмен RSVP, истекли. Вернуться к режиму без аутентификации недопустимо. Но нарушение действующих резервирований может вызвать более широкую сетевую аварию. Поэтому система должна сообщить об истечении последней ассоциации и продолжить считать её бессрочной до продления, удаления средствами управления или настройки новой.

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

RSVP из RFC 2205, расширенный для traffic engineering в RFC 3209, сигнализирует резервирование ресурсов. Проект защищает сообщения на каждом hop объектом INTEGRITY. «Отправитель» и «получатель» здесь — соседние системы RSVP на данном участке, а не обязательно конечные приложения.

Объект несёт 48-битный Key Identifier, 64-битный номер последовательности и данные аутентификации. Получатель выбирает точную ассоциацию по идентификатору и адресу отправителя. В ней также заданы криптографическое преобразование, ключ, интерфейсы или соседи, время начала и окончания. Ассоциация однонаправленна.

Доказательство ограниченно: сосед, владеющий настроенным ключом, создал сообщение в позиции последовательности, которую получатель считает свежей. Конфиденциальности нет. Не доказаны полномочия приложения, решение admission control, прохождение данных или предоставление услуги. Подлинность сообщения — лишь один слой реальности.

Номер последовательности создаёт особый риск при перезапуске. Он должен быть уникальным и монотонно расти на протяжении жизни ключа. Потеряв текущее значение, получатель может принять старое сообщение за новое. Поэтому реализации обязаны поддерживать Integrity Handshake и должны включать его по умолчанию. Получатель отправляет непредсказуемый cookie, а отправитель возвращает его вместе с текущим номером в защищённом ответе.

Каждая сессия должна либо применять handshake, либо хранить последовательность в устойчивой памяти. RFC 4086 и RFC 8937 задают требования к случайности cookie, но не подтверждают, какие получатели действительно завершили обмен.

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

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

Время само становится частью доверенной поверхности. Проект требует достаточной синхронизации и рекомендует аутентифицировать распределение времени. RFC 5905 описывает NTPv4, однако строка NTP в конфигурации не доказывает текущий сдвиг и исправность источника.

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

Если преемника нет, результат меняется: истёкшая ассоциация проверяет пакет так, будто срок не закончился. Это fail-operational выбор. Он сохраняет последнюю известную аутентифицированную связь вместо перехода к незащищённым сообщениям или автоматического разрушения резервирований.

Слабость такого решения — внешнее благополучие. Сеть работает, ремонт теряет срочность, предупреждение может остаться без владельца. Слово «бессрочно» означает отсутствие второй автоматической границы: завершить исключение способно только управление.

Управление ключами находится вне проекта. Ручное распределение обязательно поддерживается; ручной ключ можно сделать вечным, хотя это не рекомендуется. Реестр IANA обеспечивает смену криптографических преобразований. Совместимость формата с HMAC-MD5 сохраняется, а RFC 6151 объясняет ограничения этого наследия. Выбор нового алгоритма сам по себе не доставляет секрет правильным соседям.

Минимальная запись должна следовать переходу: Key Identifier и адрес отправителя, область интерфейса и соседа, преобразование, заданные начало и конец, преемник, окно перекрытия, погрешность часов, ожидаемые получатели, handshake каждого, первое сообщение после истечения, доставка и подтверждение тревоги, действие, закрывшее исключение. Секрет в журнал не попадает; происхождение состояния — обязательно.

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

Приоритет работающего кода Хэна Лу предлагает точную дисциплину: дата — символ, обработка пакетов — состояние. Минимальная исходная спецификация позволяет общему протоколу обозначить границу, не присваивая локальное решение. Слои реальности не дают спутать слово «истёк» с фактом прекращения доверия.

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

Источники