Кратко

  • Проект RSVP Cryptographic Authentication v2 проходит заключительное обсуждение в рабочей группе TEAS до 30 сентября 2026 года. Редакция 02 появилась 27 сентября, но документ остаётся Internet-Draft, а не утверждённым RFC.
  • Если старая ассоциация безопасности истекла и существует другая действующая, сообщение со старой следует отбросить. Если истекли все применимые ассоциации, проект допускает проверку последней и особый режим непрерывности.
  • Это не разрешение принимать сообщения без аутентификации. Операторам предстоит заметить исключение, установить замену и подтвердить, когда старую ассоциацию перестали использовать.

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

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

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

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

Важно не переоценивать ход работы над стандартом. TEAS начал заключительное обсуждение 16 сентября с окончанием 30-го. 21 сентября ранний рецензент направления безопасности оценил редакцию 01 как Ready, сочтя объяснение управления ключами и крайнего случая достаточным. 27 сентября вышла редакция 02. Сопоставление официальных текстов показывает в основном ссылки, редакторские правки и примечание для предлагаемого реестра: правило последнего истёкшего ключа уже существовало. Оценка одного рецензента не равна решению IESG и ничего не сообщает о состоянии конкретных сетей.

Не следует смешивать этот механизм и выбор алгоритма. Базовый проект намеренно не требует одного обязательного криптографического преобразования. В предлагаемом реестре IANA HMAC-MD5 указан как SHOULD, одновременно помечен устаревшим и предназначенным к будущему выводу. Отдельный проект TEAS посвящён HMAC-SHA2. Эти документы не раскрывают алгоритм работающего маршрутизатора и не удостоверяют своевременную смену его ключей.

Практичным местным доказательством был бы журнал: время первого предупреждения, затронутые соседи, принятые в исключительном режиме аутентифицированные сообщения, ответственное лицо и успешное включение новой ассоциации. Это редакционная рекомендация Daniel Kade, а не обязательное правило TEAS. Без такой записи «связь сохранилась» легко превращается в ошибочное «сроки больше не имеют значения».

Источники