Кратко

  • Версия 18 проекта рабочей группы RADEXT обязывает клиент RadSec отбросить ответ, не прошедший проверку Response Authenticator, и при этом сохранить соединение (D)TLS. Соединение также сохраняется, если ответу уже не соответствует ни один ожидаемый запрос. Документ находится на рассмотрении IESG, а не имеет статус утверждённого RFC.
  • Новый разбор показывает возможную гонку: после тайм-аута однобайтовый Identifier переходит новому запросу, затем приходит старый ответ и проверяется в чужом контексте. Отбрасывание ответа остаётся обязательным. Это не разрешение пропускать пакет и не исключение для настоящего сбоя Message-Authenticator.

Сервер мог отвечать правильно на запрос, которого клиент уже не ждёт. Клиент завершил ожидание запроса A, освободил его Identifier и назначил то же значение запросу B. Ответ A прибывает позже и встречает таблицу, где под этим номером записан B. Проверка Response Authenticator не сходится. На уровне пакета решение очевидно: не доставлять ответ как результат B. Но прекращение защищённой сессии затронуло бы и другие операции, поэтому для него нужен отдельный вывод.

Именно этот вывод пересматривает текст draft-ietf-radext-radiusdtls-bis-18 от 30 сентября. Раздел 3.12 предписывает клиенту при неудачной проверке Response Authenticator отбросить ответ, оставив соединение открытым. Для ответа без ожидаемого запроса установлено то же правило. В версии 17 первая ошибка относилась к основаниям закрытия, а во втором случае реализация могла выбирать между закрытием и сохранением. Появившееся приложение A.1 объясняет последовательность повторного использования идентификатора и запоздалого ответа. Новизна состоит в том, какое последствие приписывается конкретной ошибке, а не в отмене проверки подлинности.

Предыдущая нормативная отправная точка — RFC 6613 о RADIUS/TCP. Он требовал закрывать TCP при провале Response Authenticator и допускал выбор для ответа, который не совпадает ни с одним ожидаемым запросом. Поле Identifier занимает один октет: на одном соединении доступно 256 значений. При высокой нагрузке освободившийся после тайм-аута номер может быстро вернуться в оборот. Сервер способен отправить старый ответ до того, как получит новый запрос. В цепочке прокси несовпадающие тайм-ауты тоже приводят к ответам, опоздавшим относительно ожиданий клиента.

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

Граница исключения узкая. Неверный ответ не принимается. Если уже провалена проверка Response Authenticator, дальнейшая проверка Message-Authenticator у отбрасываемого пакета не меняет исход. Но если ответ корректно соотнесён с запросом, а Message-Authenticator не проходит проверку, правило о закрытии остаётся. Сервер, не признающий клиента допустимым, обязан сразу прекратить (D)TLS, а при RADIUS/TLS — и TCP. Сведение этих случаев к одному счётчику «ошибка аутентификации» лишило бы оператора понимания, где проходит действительная граница доверия.

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

Datatracker показывает действующий проект RADEXT со статусом IESG Evaluation::AD Followup, переданный для публикации с предполагаемым уровнем Proposed Standard. Замена RFC 6614 и RFC 7360 произойдёт лишь в случае одобрения. До этого речь идёт о предложенном разграничении: права отвергнуть отдельный ответ достаточно, чтобы защитить операцию, но его самого по себе может не хватать, чтобы отозвать доверие ко всему каналу.

Источники