Кратко

  • TCP-AO способен аутентифицировать сброс, пока оба конца сохраняют состояние соединения и ключи трафика.
  • После перезапуска непроверяемый сброс отклоняется, а устаревшее состояние удаляется средствами проверки доступности или восстановления приложения.

Перезапуск создаёт асимметрию состояния

До сбоя оба конца знают TCP-соединение, начальные номера последовательности и производные ключи для этого соединения. В таком общем контексте сброс можно аутентифицировать.

Перезапустившийся маршрутизатор может помнить настройку TCP-AO, но утратить состояние конкретного соединения. RFC 5925 указывает: если пара начальных номеров последовательности неизвестна, как при отправке сброса после перезапуска, сброс следует отправлять без аутентификации. Узел, требующий TCP-AO, не может проверить сегмент и отбрасывает его.

Один конец сообщает, что соединения больше нет, а другой всё ещё хранит старое соединение, не получив приемлемого доказательства его завершения.

Почему честный сброс всё равно отклоняется

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

Цена защиты — более медленная очистка. Оставшийся узел может хранить устаревшее состояние, пока его собственные механизмы проверки доступности не обнаружат отсутствие прогресса. RFC 5925 рекомендует TCP- или прикладные keepalive и требует, чтобы реализации обнаруживали и удаляли избыточное состояние TCP-соединений для защиты памяти.

Источники