Кратко

  • KeyID обозначает Master Key Tuple, которым защищён отправляемый сегмент. RNextKeyID сообщает предпочтительный MKT для будущего приёма; он не переносит секрет, не подтверждает доставку и не доказывает смену исходящего ключа у peer.
  • Состояние направлено: на каждой стороне есть текущий исходящий и предпочтительный входящий ключ. Одно поле «активный ключ» стирает четыре факта, без которых готовность нельзя оценить.
  • Старый MKT удаляют только после нового KeyID и успешного MAC в обоих направлениях, стабильного BGP, проверенного reconnect, нулевой старой зависимости и полного rollback.

Авария возможна даже при одинаковых секретных байтах. Расхождение возникает в локальных именах. A создаёт новый MKT с SendID 42 и RecvID 42. B по своей схеме присваивает SendID и RecvID значение 43. В change ticket обе команды называют объект «ключ 42». TCP-AO опирается не на название в разговоре, а на направление и эффективный ID.

A выбирает новый MKT как предпочтительный для приёма. Его сегменты всё ещё аутентифицируются под KeyID=17, но объявляют RNextKeyID=42. B корректно проверяет их старым MKT, затем ищет для этой socket pair исходящий MKT с SendID 42. Если готового соответствия нет, RFC 5925 не требует переключения. Неудачный запрос относится к B→A: B продолжает отправлять под 17. Если B затем объявит RNextKeyID=43, A также не сможет перевести A→B без готового исходящего MKT с SendID 43.

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

Два идентификатора описывают два направления

TCP-AO — TCP option Kind 29 с полями Length, KeyID, RNextKeyID и MAC. Компактность соответствует узкой задаче: согласовывать уже доставленные контексты, а не распределять секреты.

KeyID описывает текущий сегмент. Отправитель помещает SendID действующего MKT; получатель сочетает байт с адресами и портами и находит MKT с соответствующим RecvID. SendID одной стороны должен встретить RecvID другой для данного направления.

RNextKeyID относится к будущему трафику в обратном направлении. Отправитель публикует RecvID MKT, которым готов проверять следующие входящие сегменты. Получившая сторона меняет исходящий current_key только при наличии совместимого локального MKT.

Числа не являются fingerprint или version. У них нет криптографических свойств, зарезервированного смысла, требования случайности или монотонности. Они могут различаться по направлениям. Две отметки 42 не доказывают одинаковые секрет, алгоритм, MAC length, lifetime или socket scope.

Точный смысл RNextKeyID=42: «я готов принимать под этим RecvID, если у тебя уже есть соответствующий исходящий MKT». Это не квитанция о доставке и не подтверждение активации.

Полномочие метки создаёт MKT

Master Key Tuple связывает секрет с TCP connection identifier: локальными и удалёнными адресами и портами; реализация может поддерживать ranges или wildcards. В него также входят SendID, RecvID, KDF, MAC algorithm и политика включения других TCP options. Управление может добавлять интервалы действия.

Входящий сегмент должен точно совпасть с одним MKT по socket pair и KeyID. Тот же секрет в другом VRF, address family, направлении, peer range или под другим RecvID — не та же рабочая способность.

Политика options тоже двусторонняя. TCP-AO всегда защищает собственные поля, временно обнуляя MAC при вычислении. Включение остальных options задаёт MKT. Несогласованные policy, algorithm или MAC length разрушают проверку даже при одинаковых master bytes.

Поэтому реестр обязан хранить адреса, порты, instance, SendID, RecvID, algorithm, длину, options policy, lifetime, роль current/rnext и TCP epoch. Запись «42 установлена» не даёт оснований удалить 17.

Master key не подписывает трафик напрямую

TCP-AO выводит traffic keys из MKT и контекста соединения: адресов, портов и после установления — Initial Sequence Numbers обоих направлений. Ключи однонаправлены, а SYN отделён от последующего трафика.

Один master secret создаёт разные traffic keys для разных peers, направлений и соединений. Reconnect меняет контекст, даже если адреса и порты повторились. Успех старого socket не доказывает следующий handshake.

Sequence Number Extensions добавляют старшее состояние при обороте 32-битного пространства TCP и поддерживают replay protection долгих сессий. Каждое направление ведёт собственный SNE с момента установления. Одиночный пакет без epoch не объясняет MAC failure.

Совпадение защищённого fingerprint необходимо, но расследование не заканчивает. Могут различаться IDs, scope, направление, algorithm, option policy, length или состояние соединения.

Одна сессия содержит две связанные ротации

Каждый endpoint имеет не более одного current_key для отправки и одного rnext_key для предпочтительного приёма. Между A и B существуют четыре существенных указателя.

Сначала новый MKT фактически становится доступен для приёма с обеих сторон, пока старый действует. Readback нужен из runtime socket state; сохранённая конфигурация не доказывает загрузку.

Затем A объявляет предпочтение. B разрешает RNextKeyID через локальную базу и при совпадении меняет исходящий ключ. Первый новый KeyID от B, успешно проверенный A, доказывает только B→A.

Обратное направление проходит независимо. B объявляет, A принимает локальное решение. Некоторое время одно направление может быть новым, второе старым. Это допустимое переходное состояние, которое интерфейс обязан показать.

В конце выдерживается ограниченный overlap для распространения, retransmit, задержки телеметрии, reconnect и rollback. Только при нулевой старой зависимости MKT удаляется. Одна session-level «active key» эту последовательность не представляет.

Отсутствие переключения сохраняет локальный контроль

Сегмент может быть корректно аутентифицирован ключом 17 и нести неизвестный RNextKeyID. Без подходящего MKT получатель не меняет исходящий контекст. Удалённый запрос не создаёт локальный объект, не продлевает validity и не обходит approval.

Общий стандарт определяет минимальный язык, а каждый участник принимает изменение только по собственному проверяемому состоянию. Объявление ещё не означает, что изменение действует.

Наблюдение должно фиксировать следствие. Изменился ли исходящий KeyID у peer? Растёт ли good-MAC counter нового MKT? Появились ли key-not-found, bad MAC или неразрешённые RNext events? Established под 17 доказывает лишь старую непрерывность.

Key management находится вне TCP-AO

RFC 5925 предполагает внешнюю процедуру или протокол для provision MKT. Он не определяет vault, API, канал, authority, custody или audit. Удаление старых MKTs тоже не координируется.

RFC 6518 сочетает ограниченный срок с осторожностью: частые ручные замены могут увеличить утечки и ошибки. Transport должен менять ключ без потери adjacency; key management делает freshness практичной. RFC 7211 рекомендует сначала разрешать приём, проверять согласованность key table и предупреждать об expiry.

Запись полномочий связывает уровни: кто создал секрет, где мог существовать plaintext, каким каналом он пришёл, какие local IDs получил, когда начинаются receive/send validity, когда заканчивается старая эпоха и кто вправе восстановить её.

Операционный контроль — это способность оператора видеть фактическое состояние, хранить доказательства, секрет и план отката, не завися от панели, которая не видит оба конца.

Удаление — необратимая граница

Установка добавляет вариант; удаление уничтожает путь назад. Пока старый MKT существует, он поддерживает отставшее направление или rollback. После удаления новый mismatch становится потерей TCP и BGP.

Бессрочное хранение тоже опасно. Скомпрометированный secret полезен, пока receiver его принимает; бесконечный overlap допускает тихую регрессию. Нужен ограниченный доказательствами вывод.

Период должен покрывать распространение, retransmit, telemetry lag, reconnect и rollback. По каждому направлению фиксируются последний старый и первый новый KeyID, рост good MAC, отсутствие bad/unknown, стабильность BGP и route baseline. Новый connection обязателен: выбор MKT при SYN может отличаться от унаследованного долгого socket.

Linux документирует good/bad, key-not-found и AO-required counters, MKT inspection и trace events. Также есть forced delete с назначением замены current/rnext; документация предупреждает, что связь может оборваться, если peer продолжает просить старый ключ. Repair не заменяет двустороннее доказательство.

Rollback восстанавливает scope, SendID, RecvID, algorithm, length, policy, lifetime и secret provenance. «Вернуть 17» — неполная инструкция.

Правильный MAC не разрешает маршрут

TCP-AO показывает соответствие сегмента ожидаемому key context. Он не доказывает право на prefix, корректность AS_PATH или честность удалённого оператора. Настоящий peer с ключом может отправить bogus route.

RFC 4272 отделяет внешние session attacks от ложной информации реального peer. RFC 7454 сохраняет отдельными TCP protection, GTSM, control-plane filters, prefix filters, max-prefix и path policy.

Диагностика должна делать то же. Bad MAC исчезает до BGP. Аутентифицированный, но запрещённый маршрут доходит до import policy и отклоняется там. Max-prefix может намеренно закрыть криптографически здоровую сессию. Зелёный статус одной колонки не сертифицирует другие.

Canary доказывает четыре границы

Сначала фиксируются instance, адреса, порты, peer, TCP epoch и route baseline. На A и B читаются все подходящие MKTs с IDs, algorithms, length, policy, validity и role. Secret сравнивают защищённым fingerprint или контролируемым тестом, не копируют в ticket.

Первое доказательство — готовность приёма обеих сторон. Затем A объявляет предпочтение; фиксируются первый новый KeyID B и первый MAC, принятый A. Третья граница проверяется независимо в обратную сторону.

После двустороннего перехода посылаются KEEPALIVEs и ограниченная BGP operation, сравниваются Adj-RIB, routes и retransmits. После overlap и reconnect доказывается нулевое старое использование, 17 удаляется на canary peer, проверки повторяются.

TCP-AO силён ограниченностью своей власти. Независимые системы координируют локальные labels, не превращая wire в доставщика secret. Эпоха 42 становится реальной, когда обе стороны разрешают её, оба направления создают и проверяют её, BGP выдерживает, старая зависимость равна нулю, а rollback остаётся. До этого это предложение.