Кратко

  • RFC 2385 допускала синхронную смену ключа, но не давала протокольного согласования или идентификаторов для её координации.
  • В TCP-AO KeyID указывает MKT отправленного сегмента, а RNextKeyID сообщает, какой MKT отправитель уже готов применять для будущих получаемых им сегментов.

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

RFC 2385 в 1998 году определила TCP MD5 Signature Option прежде всего для защиты BGP. Каждый сегмент получал 16-байтовый MD5-код на основе секрета, отдельно заданного на обоих концах. Ключ разрешалось менять во время соединения при условии синхронизации. Однако в опции не было номера текущего ключа, объявления следующего или механизма переговоров.

RFC 5925 заменила эту схему механизмом TCP-AO с явной моделью состояния. Master Key Tuple, MKT, объединяет селекторы соединения, идентификаторы, ключевой материал, алгоритмы и параметры. Из него выводятся односторонние ключи трафика для конкретного соединения. Все компоненты введённого в действие MKT остаются неизменными, но набор доступных MKT можно обновлять, а соединение может перейти на другой MKT.

Переход координируют два однобайтовых поля. KeyID указывает MKT, которым аутентифицирован отправленный сегмент. RNextKeyID объявляет входящий MKT, который отправитель уже готов применять для будущих получаемых им сегментов; партнёр использует этот сигнал и правила ротации, чтобы решить, когда сменить свой исходящий MKT и KeyID. Эти числа не являются секретами или глобальными именами; это локальные индексы общей настройки. Поскольку ключи направлены, отправка и готовность к приёму меняются отдельно.

Идеальная одновременность больше не нужна. Одна сторона устанавливает следующий входящий MKT и через RNextKeyID объявляет, что уже готова применять его. Партнёр видит этот сигнал и по правилам RFC решает, когда сменить KeyID своих исходящих сегментов; объявление не требует немедленного перехода в следующем TCP-сегменте. Управляемое перекрытие позволяет проверить старые сегменты, оставшиеся в пути. Прогресс виден в протоколе, а не угадывается только по времени и ошибкам MAC.

TCP-AO при этом не распределяет мастер-ключи. Он не договаривается о секретах и не решает, кто имеет право их выдавать. MKT поступают из статической настройки или внешнего канала. Протокол координирует уже разрешённый материал, не создавая полномочие.

Действующее соединение TCP MD5 нельзя превратить в TCP-AO на месте. Механизмы используют разные опции и запрещены вместе в одном соединении. TCP MD5 не умел менять алгоритм защиты после установления. Для миграции требуется новое соединение, хотя последующие ротации TCP-AO уже сохраняют его транспортное состояние.

RFC 5926 задаёт обязательные профили MAC и вывода ключей для совместимости, но не операционный секрет и не общий период ротации. TCP-AO защищает подлинность и целостность, усиливает защиту от повторов, однако не шифрует прикладные данные.

Первичные источники