Кратко

  • RFC 3169 считал сведения, переданные Network Access Server (NAS) серверу AAA, доказательством или «подсказкой», но не распоряжением; окончательное решение о доступе оставалось за сервером AAA.
  • Решение всё равно должен был применить NAS. Состояние ресурсов, учетные записи и фактически предоставленная услуга требуют отдельных подтверждений.

Это распределение ролей изложено в документе, который легко принять за стандарт. RFC 3169 опубликован в сентябре 2001 года как Informational и прямо сообщает, что не устанавливает интернет-стандарт. Его название — «Критерии оценки протоколов сетевого сервера доступа» — обещает проверочный список, а не новый формат пакета. Документ делит пространства протоколов NAS на доступ, сеть, AAA и управление устройствами, сосредотачиваясь на AAA. Модель включает оборудование, объединяющее телефонные, широкополосные и туннельные сеансы, вплоть до тысяч одновременных соединений.

Важнее всего не длина перечня, а распределение полномочий. В разделе об авторизации RFC 3169 говорит, что сведения, отправленные NAS серверу AAA, следует трактовать как «информацию или подсказки», а не указания. Окончательное решение принимает сервер; он не должен полагаться на состояние, которое NAS лишь ожидает увидеть. Пограничное устройство может сообщить о сеансе, но само сообщение не разрешает доступ.

Но решение на сервере ещё не означает, что политика уже применяется. RFC 3169 описывает профили доступа, которые передаются для исполнения на NAS. Сервер AAA определяет, что разрешает политика; NAS должен установить или применить профиль в своей рабочей среде. Поэтому корректный Access-Accept, ответ политики или сообщение динамической авторизации подтверждает решение либо запрос, но само по себе не доказывает смену состояния интерфейса, действие фильтра или получение пользователем работающей услуги.

Требования к управлению ресурсами делают этот разрыв наглядным. RFC 3169 предусматривает выделение и освобождение общих ресурсов в течение сеанса: адресов, лимитов одновременного использования, портов и туннелей. Документ указывает, что это прежде всего ресурсы, локальные для NAS. В прокси-схемах и между административными доменами сервер, выделивший удалённый ресурс, а возможно и его резервные узлы, должен хранить сведения о выделении. Удалённые изменения авторизации следует проводить с помощью динамической авторизации. Кто решает вопрос о доступе и кто владеет актуальным реестром для возврата или восстановления ресурса — разные роли.

При сбое это различие становится практическим. Переключение на резервный сервер может сохранить политику доступа, но не восстановить лимит туннелей или адресный пул, который ведёт выделившая ресурс сторона. После перезапуска локальное состояние NAS может разойтись с записью владельца ресурса. Запрос на отключение может дойти, но остаться невыполненным. Поэтому RFC 3169 требует синхронизации и восстановления и предостерегает от зависимости управления ресурсами от потока учетных сообщений. Этот поток может регистрировать использование, но не становится автоматически авторитетной таблицей активных выделений.

Учет — отдельный путь доказательств, а не замена трём предыдущим. RFC 3169 требует механизм надёжной доставки, определяет начало доставки в течение одной секунды после события как реальное время и требует однозначных временных отметок. Это критерии для оценки протокола, а не результаты наблюдений в сети. Своевременно полученная запись не доказывает доставку пакета, полный учёт событий или верное восстановление сеанса последующими системами. Получение в реальном времени не тождественно реальной картине происходящего.

История соседних протоколов поясняет контекст, но не доказывает полного соответствия какого-либо преемника всему перечню. У RADIUS уже были отдельные спецификации для аутентификации/авторизации и учета. RFC 3169 требует, чтобы кандидаты в AAA-протоколы поддерживали эти наборы атрибутов, совместимость, расширяемость, несколько серверов и связи между доменами. Позднее RFC 6733 описал Diameter как базовый протокол для AAA-приложений; динамическая авторизация, перенос EAP и защита транспорта развивались также в отдельных документах. Их появление — не аудит каждого требования RFC 3169.

Более поздние рекомендации по проектированию RADIUS признают ограничения размера пакетов и модели данных, а не считают большой диапазон атрибутов гарантией неограниченных возможностей реализации.

В истории Интернета RFC 3169 очерчивает границы контроля. NAS предоставляет сведения о сеансе; сервер AAA принимает окончательное решение о доступе; NAS исполняет политику; владелец ресурса хранит актуальное состояние; учет формирует отдельную запись. Эти участники могут обмениваться данными в рамках одного семейства протоколов, однако ни одно сообщение не подтверждает прохождение всей цепочки. Статья не утверждает долю внедрения, поведение продуктов или нынешнюю распространённость. Она сохраняет более узкий урок документа: в распределённой операции центральное решение — лишь одно из подтверждений.

Источники: RFC 3169; текущая запись RFC 3169; запись RFC 3169 в Datatracker; модель NAS в RFC 2881; RADIUS, RFC 2865; учёт RADIUS, RFC 2866; расширения RADIUS, RFC 2869; оценка AAA-протоколов, RFC 2989; EAP в RADIUS, RFC 3579; динамическая авторизация, RFC 5176; рекомендации по RADIUS, RFC 6158; RADIUS поверх TLS, RFC 6614; базовый протокол Diameter, RFC 6733; RADIUS/1.1, RFC 9765; Лу Хэн, «Когда счетовод метит на Олимп».