Кратко

  • RFC 4014 разрешила сетевому серверу доступа сохранять часть атрибутов из успешного RADIUS Access-Accept, а затем включать их в сообщение DHCP, пересылаемое ретранслятором.
  • DHCP-сервер использовал эти данные при выборе параметров конфигурации. Авторизация RADIUS, передача через ретранслятор и назначение адреса оставались разными функциями.

Доступ разрешён, адреса ещё нет

Устройство подключается к корпоративному Wi-Fi или к порту коммутатора. Аутентификация 802.1X проходит успешно, и точка доступа или коммутатор допускает сессию в сеть. Однако для обычного IP-обмена устройству ещё нужна конфигурация DHCP. Получается, что разрешение войти уже выдано, а решение о параметрах адресации впереди.

RADIUS и DHCP отвечают на разные вопросы. RADIUS аутентифицирует пользователя или устройство и возвращает атрибуты, связанные с доступом к услуге. DHCP выбирает параметры, которые сервер предложит клиенту. RFC 3580 прямо поясняет: сам IEEE 802.1X не предоставляет механизма назначения IP-адреса. Атрибут Framed-Pool полезен лишь там, где аутентификатор способен участвовать в такой выдаче.

В сетях эти функции могли принадлежать разным системам. Централизованный сервер RADIUS проверял сессию, отдельный сервер DHCP управлял пулами адресов, а сетевой сервер доступа (NAS) видел только что разрешённое подключение и мог одновременно работать DHCP-ретранслятором. Требовался способ передать контекст между сервисами, не сводя их решения к одному и не заставляя каждую сторону угадывать сведения другой.

В феврале 2005 года Ralph Droms и John Schnizlein описали такой переход в RFC 4014. После успешного Access-Accept NAS сохранял атрибуты локально. Когда позднее приходил запрос DHCP, тот же узел мог добавить выбранные атрибуты при пересылке сообщения серверу. RFC связала два обмена, но не превратила авторизацию RADIUS в аренду DHCP.

У ретранслятора уже был контейнер для контекста

Механизм использовал Relay Agent Information Option, определённую RFC 3046 и часто называемую Option 82. Этот контейнер передаёт сведения, известные ретранслятору лучше, чем клиенту: например, через какой канал пришёл запрос или какое удалённое устройство с ним связано. DHCP-сервер может использовать такие сведения при выборе адреса или других параметров.

В ответе сервер возвращает Option 82 ретранслятору, а тот удаляет её перед доставкой ответа клиенту. Устройство не должно разбираться во внутренних идентификаторах каналов и оборудования оператора.

RFC 4014 добавила в этот контейнер подопцию 7 — «RADIUS Attributes». Ретранслятор мог поместить туда октеты атрибутов из Access-Accept, а DHCP-сервер извлекал их для выбора конфигурационных параметров. Ретранслятор переносил контекст, но не принимал за сервер решение о выдаче адреса.

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

Короткий список задавал предел

В одном сообщении могла находиться не более чем одна подопция RADIUS Attributes. Если были доступны User-Name и Framed-Pool, ретранслятор должен был включить их; остальные атрибуты были необязательны. Чтобы выбор адреса не зависел от другого состояния, хранимого только на сервере RADIUS, RFC рекомендовала ограничить набор шестью атрибутами: User-Name, Service-Type, Vendor-Specific, Session-Timeout, Framed-Pool и Framed-IPv6-Pool.

DHCP-сервер использовал полученные значения при выборе параметров и должен был игнорировать атрибуты за пределами списка. Название пула могло повлиять на ветвь локальной политики, но не обязывало сервер выдать адрес из пула, которым он не управлял. Авторизация добавляла контекст; управление адресами оставалось у DHCP.

Был и физический предел: подопция не бесконечна. RFC 4014 говорит, что ретранслятор обрезает атрибуты, чтобы они поместились, но не определяет универсальную очередность при сокращении. Поэтому наличие значения в Access-Accept не доказывает, что DHCP-сервер увидел его полностью. Важны фактический набор и байты переданного сообщения.

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

Доверие проходит по тому же пути

Поскольку DHCP-сервер может принимать решение по значениям от ретранслятора, доверие между ними становится частью контура управления. RFC 4014 опирается на модель RFC 3046 и рекомендует не только пропускать Option 82 от доверенных ретрансляторов, но и применять более глубокую защиту: аутентификацию опций ретранслятора или IPsec.

Клиент обычно не видит Option 82, но скрытость не подтверждает подлинность. DHCP-серверу необходимо понимать, кто отправил сообщение и каким образом защищён путь. Поддельное или устаревшее значение может повлиять на выбор политики, если доверительные проверки не сработают. Это возможное следствие архитектуры, а не свидетельство известного инцидента.

Поэтому на вопрос «кто выбрал адрес?» нельзя указать одного участника. RADIUS разрешает сессию и предоставляет контекст; NAS решает, что передать; DHCP-сервер выбирает конфигурацию и управляет своими пулами. RFC определяет канал передачи, но не доказывает, что состояние NAS актуально, ретранслятор доверен, а локальная политика верна. Результат показывает только работающая система.

Расширение 2023 года сохранило разные механизмы

В 2023 году RFC 9445 вернулась к этой границе: новым услугам понадобились параметры DHCP, которых не было в фиксированном списке RFC 4014. RFC 9445 обновила прежний документ и перенесла допустимые атрибуты в реестр IANA, который можно расширять через экспертную проверку. Подопция 7 осталась прежним путём передачи RADIUS-атрибутов.

Отдельно RFC 9445 определила два других атрибута RADIUS для передачи DHCP-опций: DHCPv6-Options (245.3) и DHCPv4-Options (245.4). Пример с зашифрованным DNS показывает возможную настройку услуги, но не её распространённость. Эти атрибуты не являются подопцией 7. Реестр IANA фиксирует разрешённые значения, а не фактическую установку у операторов.

История не сводится к тому, что RADIUS начал назначать адреса. Она показывает, как контекст авторизации прошёл через границу сервисов, не стирая их ответственность: один сервис разрешает доступ, ретранслятор переносит данные, другой применяет конфигурационную политику. Новые потребности расширили допустимый набор, но доверие и решение оставались локальными.

В качестве более поздней аналитической рамки Note 64 Лу Хэна обращает внимание на минимальный общий стандарт и локальный выбор внутри административной области. Note 65 напоминает, что публикация документа не равна поведению запущенного кода. Эти заметки не были причиной RFC 4014 и не служат историческими источниками о её создании. Практический ответ зависит от того, что реально делают NAS, ретранслятор и DHCP-сервер.

Источники