Протоколы ААА: RADIUS и Diameter. Серия «Телекоммуникационные протоколы». Книга 9

Б. С. Гольдштейн, В. С. Елагин, Ю. Л. Сенченко.

СПб.: БХВ – Санкт-Петербург, 2011.

Девятая книга серии «Телекоммуникационные протоколы».

Рассматриваются протоколы и процедуры аутентификации, авторизации и учета AAA (Authentication, Authorization, Accounting) в современных сетях мобильной и фиксированной связи. AAA обеспечивают управление доступом к любым сетям связи и играют ключевую роль всюду, где требуется представить конечному пользователю счет за предоставленные инфокоммуникационные услуги, включая традиционную телефонию, широкополосный доступ, услуги маршрутизации, услуги шлюза и т.п. Важность ААА-операций все более возрастает по мере распространения сетей NGN/IMS. Книга содержит подробные сведения о двух наиболее распространенных сегодня AAA-протоколах.

Журнал «Вестник связи», №12, 2006

ПРОБЛЕМЫ И РЕШЕНИЯ

СОРМ-2

Б.С. ГОЛЬДШТЕЙН, заведующий кафедрой СПбГУТ,

Ю.А. КРЮКОВ, научный сотрудник ЛОНИИС,

В.И. ПОЛЯНЦЕВ, главный специалист ФАС

Информационная безопасность и инженерные проблемы СОРМ-2

Характерная для всех бурно развивающихся отраслей ситуация сложилась с

современными телекоммуникациями: их развитие происходит сегодня с заметным

опережением формирования необходимых стандартов и апробированных механизмов и

подходов. Это в полной мере справедливо для стандартизации функций СОРМ

(системы оперативно-розыскных мероприятий) или законного перехвата сообщений LI

(Lawful Interception) в терминах Европейского института стандартизации ETSI. И если

для традиционной телефонии с коммутацией каналов ситуация со стандартизацией

СОРМ [1] обстоит относительно благополучно (не без некоторого участия и авторов

этой статьи), то для СОРМ-2 в современных IP-сетях пока гораздо больше открытых

вопросов, чем стандартизованных решений. В статье рассмотрены некоторые

технические проблемы известных сегодня подходов к СОРМ-2 для IP-сетей, варианты

их решений, как апробированные на практике, например, в используемой

американским ФБР системе Carnivore/DCS1000 [2], так и предлагаемых пока

исключительно на идейном уровне.

Принцип функционирования систем законного перехвата сообщений СОРМ-2

заключается в обнаружении в реальном времени попыток контролируемого объекта

получить доступ к услугам своего Интернет-провайдера (ISP – Internet Service Provider)

и последующем перехвате этой информации. Перехваченная таким образом

информация форматируется и передается правоохранительным органам – LEA (Law

Enforcement Agency) в терминах ETSI или ПУ (пункт управления) в терминах

российского СОРМ. Во всех случаях фактическая процедура реализации функций

СОРМ-2 (как, впрочем, и СОРМ-1) определяется двумя составляющими –

организационным решением на осуществление перехвата информации от

уполномоченного органа и наличием технологии, делающей осуществимым этот

перехват.

Здесь, как и в телефонных сетях с коммутацией каналов, оператор и/или провайдер

услуг юридически обязан развертывать архитектуру СОРМ и рассматривать ее как

часть собственной сетевой инфраструктуры.

Процедуры законного перехвата сообщений СОРМ-2 начинаются с выделения логина

объекта наблюдения в динамически распределяемых IP-адресах. Для этого обычно

используется протокол RADIUS (Remote Authentication Dial In User Service),

выполняющий функции аутентификации, авторизации и учета ААА (Authentication,

Authorization and Accounting). После того, как становится известен IP-адрес

контролируемого объекта, механизм СОРМ-2 автоматически реконфигурируется для

захвата всего IP-трафика к/от контролируемого IP-адреса так, чтобы иметь

возможность интерпретировать, трансформировать и передать перехваченные данные в

ПУ. Другой пример – протокол DIAMETER [3], поддерживающий функциональностьЖурнал «Вестник связи», №12, 2006

ААА как для существующих сетей, так и для сетей связи следующего поколения NGN

(Next Generation Network).

Еще раз подчеркнем, что процедуры СОРМ-2 в IP-сетях пока не имеют

стандартизованных решений. Более того, IETF – организация, которая анализирует

развитие Интернета и выпускает соответствующие стандарты по используемым

протоколам, фактически отклонила идею включения функциональности СОРМ в свои

разработки. В то же время современный Интернет состоит из очень большого числа

протоколов, каждый из которых обеспечивает предоставление пользователям

разнообразных Интернет-услуг. К тому же стремительный, непрогнозируемый рост

популярности услуг Интернета еще более осложняет задачу, так как первоначальные

академические цели Интернета были весьма далеки от нынешней проблематики

глобальной сети общего пользования.

Кроме того, чрезвычайно важное для дальнейшего материала статьи понятие

информационной безопасности де-факто было внесено в архитектуру Интернета

значительно позже, а на начальном этапе развития, характеризующегося

университетской открытостью, ранние протоколы стека TCP/IP основывались на

предположении о правильности информации IP-адреса в IP-заголовке и передаче

пользовательских имен и паролей в явном виде. Последующее развитие концепции

безопасности нашло выражение в принятии спецификации IPSecurity – IPsec,

представляющей собой комплект протоколов шифрования, аутентификации и

обеспечения защиты при транспортировке IP-пакетов.

Обеспечение безопасности актуально в IP-сетях в целом, а в контексте данной статьи

создает значительные проблемы для СОРМ-2. Дело в том, что защита пользовательских

соединений осуществляется, в частности, с помощью анонимности информации об

отправителе и получателе сообщений. При этом подходе не только злоумышленник, но

и система СОРМ-2 не смогут перехватывать пользовательский трафик. Не говоря уже о

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

непосредственно конечными пользователями.

Вместе с тем, новые Интернет-протоколы поддерживают новые возможности и

средства законного перехвата IP-трафика. Речь идет о протоколах RADIUS и

DIAMETER.

Возможности RADIUS

Критериями для законного перехвата IP-трафика, циркулирующего в Интернете, могут

выступать IP-адрес, МАС-адрес или ID кабельного модема (по аналогии со списочным

номером абонента, используемым в качестве критерия в ТфОП). Кроме того, критерием

СОРМ-2 могут являться данные прикладного уровня, например, адреса электронной

почты или Instant Messaging ID, пользовательские имена RADIUS.

Наиболее полными с точки зрения получаемых возможностей СОРМ-2 являются

системы, построенные на основе анализа протокола RADIUS (Remote Authentication

Dial In User Service), с помощью которого происходит аутентификация, авторизация и

учет ААА (Authentication, Authorization and Accounting) пользователя при попытке

доступа в сеть. Журнал «Вестник связи», №12, 2006

Для доступа dial-up в роли пользовательского оборудования выступает компьютер и

модем, которые обеспечивают соединение с сетевым сервером доступа MAS (Network

Access Server), используя его телефонный номер ТфОП, и получают доступ к ресурсам

сети провайдера услуг Интернета. После установления соединения с сетевым сервером

доступа пользователь проходит процедуру аутентификации, которая заключается в

предоставлении уникального пользовательского имени и пароля.

Прежде чем разрешить доступ пользователя к сети провайдера, NAS проверяет

правильность предоставленной пользователем информации. Эта процедура

аутентификации проводится RADIUS-сервером, который может взаимодействовать со

множеством NAS-серверов различных Интернет-провайдеров, использующих протокол

RADIUS.

Рис. 1. Диаграмма взаимодействия участников СОРМ-2 в IP-сети с RADIUS

Среди определенных протоколом RADIUS сообщений наибольший интерес с точки

зрения реализации функций СОРМ-2 представляют два – это сообщения запроса

доступа Access-Request и разрешения доступа Access-Accept. Сообщение AccessRequest посылается от сетевого сервера доступа к RADIUS-серверу и содержит в своем

формате поля, соответствующие имени пользователя и его паролю. Информация о

пользовательском имени и пароле представляется в определенной форме – в атрибутах

RADIUS User-Name и User-Password.

В сети провайдера RADIUS-сервер, выступающий в роли централизованной службы

аутентификации, авторизации и учета, после получения от сетевого сервера доступа

сообщения Access-Request проверяет пользовательское имя и пользовательский пароль.

По результатам проверки пользователь либо получает доступ к сетевым ресурсам, либо

ему дается отказ. В первом случае RADIUS-сервер посылает в обратном направлении

сообщение Access-Accept, содержащее присвоенный пользователю IP-адрес (Framed-IPAddress), который указывает сетевому серверу доступа IP-адрес, присвоенный

пользователю для запрашиваемого доступа. Журнал «Вестник связи», №12, 2006

Процедура прохождения аутентификации предполагает, что специальное устройство –

медиатор СОРМ типа XSM – будет анализировать весь трафик, проходящий между

сетевым сервером доступа и RADIUS-сервером, с целью распознавания в поле имя

пользователя соответствующего критерия СОРМ – пользовательского имени объекта

контроля. В случае совпадения этих параметров медиатор СОРМ будет ожидать

сообщения Access-Accept от RADIUS-сервера. Соответствие между сообщениями

Access-Request и Access-Accept устанавливается с помощью служебных

идентификационных полей.

Как только медиатор СОРМ получает сообщение Access-Accept, соответствующее

критерию СОРМ, происходит процесс его реконфигурации с целью обеспечить

перехват всего пользовательского трафика к/от контролируемого объекта,

определяемого IP-адресом, указанным в сообщении Access-Accept. Получаемый таким

образом пользовательский трафик через соответствующие интерфейсы (в терминах

ETSI для этих целей используется интерфейс HI3) передается к ПУ

правоохранительных органов. Информация, связанная с перехватом, формируется на

основе сообщений Access-Request и Access-Accept и в специальном формате,

оговоренном национальным стандартом, через интерфейс HI2 также передается к ПУ.

На рис. 1 представлена упрощенная диаграмма взаимодействия всех участников

процесса реализации функции СОРМ-2 в сети провайдера Интернет-услуг. В качестве

сервера, реализующего функции аутентификации, авторизации и учета, используется

RADIUS-сервер. Применение других протоколов для аутентификации, авторизации и

учета не будет вносить серьезных изменений в представленный механизм,

определяющий общий порядок взаимодействия.

Механизм взаимодействия медиатора СОРМ и ПУ при вышеописанной организации

функций СОРМ в сети Интернет-провайдера в целом незначительно отличается от уже

функционирующего в сетях доступа. Основные отличия будут наблюдаться на участке

взаимодействия медиатор СОРМ – ПУ в форматах информации, передаваемой через

интерфейсы HI2 и HI3, что нисколько не нарушит сложившуюся практику и

методологию СОРМ.

Заметим, что текущая версия протокола RADIUS ориентируется на аутентификацию

пользователей по версии Интернет-протокола IPv4. Для обеспечения процедуры

аутентификации пользователей Интернет-услугами следующей версии Интернет-

протокола IPv6 в протокол RADIUS добавляются некоторые сообщения, например,

Framed-Interface-Id и Framed-IPv6-Prefix, определяющие для сетевого сервера доступа

идентификатор интерфейса и префикс, которые были предоставлены сервером RADIUS

пользователю, запрашивающему услугу IPv6. Помимо вышеупомянутых сообщений,

новая спецификация определяет, что если RADIUS-сервер полностью поддерживает

архитектуру аутентификации для IPv6, то он должен также поддерживать возможность

использования IPsec, о чем говорилось в предыдущем разделе статьи.

Из этого следует, что сообщение Access-Request, передаваемое от сетевого сервера

доступа к RADIUS-серверу, и сообщение Access-Accept от RADIUS-сервера к сетевому

серверу доступа будут содержать информацию (имя пользователя и IP-адрес) в

зашифрованном виде. Таким образом, для медиатора СОРМ исключается возможность

определить IP-адрес контролируемого объекта. Журнал «Вестник связи», №12, 2006

Для решения этой проблемы возможно использование двух путей – доступность

медиатору СОРМ ключей шифрования или реализация сценария взаимодействия

пользователь – сетевой сервер доступа – RADIUS-сервер – медиатор СОРМ, при

котором последнему информация передается в незашифрованном виде.

Рис. 2. ESP расширение заголовка для IPv6

Возможности DIAMETER

Протокол DIAMETER был разработан рабочей группой IETF, занимающейся

вопросами аутентификации, авторизации и учета, для поддержания этой архитектуры в

сетях связи следующего поколения. Этот протокол предназначен для использования в

существующей инфраструктуре, а также мобильных IP-сетях, для поддержки роуминга

и пр. В добавление к этому отметим, что DIAMETER полностью поддерживает

вышеупомянутую функциональность RADIUS, также выполняя задачи

аутентификации, авторизации и учета.

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

DIAMETER, которое определяет специфические детали, используемые этим

приложением, например, приложение DIAMETER Mobile IPv4 или DIAMETER для

сетей доступа. В этом случае DIAMETER-клиент, поддерживающий определенное

приложение DIAMETER, связывается с DIAMETER-сервером, который также

поддерживает определенную спецификацию приложения DIAMETER.

Для передачи в DIAMETER-сервер необходимой для аутентификации, авторизации и

учета информации протоколом DIAMETER используется модель данных AVP

(Attribute-Value Pair), т. е. представления вида < имя атрибута, величинах>. В данном

случае AVP состоит из специального AVP-кода и идентификатора отправителя для

определения уникальных признаков, а также их оценки. Формат DIAMETER-

сообщений разрешает использование множества AVP в сообщении.

В качестве примера использования протокола DIAMETER рассмотрим DIAMETER-

приложение для сетей доступа, которое используется ISP для предоставления сервисов

доступа. Литература [4] определяет команды AA-Request и AA-Answer, которые

посылаются к и от сервера DIAMETER, соответственно, и обеспечивают процедуру

аутентификации пользователя, запрашивающего доступ. Хотя [4] определяет оба этих

сообщения, тип данных, формат заголовка и механизмы безопасности, которые

используются этим частным приложением, полностью данные определяются базовым

протоколом DIAMETER [3]. Подобно числу сетей доступа в вышеупомянутыхЖурнал «Вестник связи», №12, 2006

сообщениях используются специфические AVR также отличающиеся на уровне

приложений.

Проблема ESP

Выше в статье уже упоминалась разработанная IETF архитектура IPsec для безопасной

передачи IP-трафика, определяющая, в частности, контроль доступа, целостность

данных, аутентификацию и шифрование. Применение процедур IPsec на хосте или

маршрутизаторе призвано защитить принимаемый и передаваемый пользовательский

трафик и затрудняет осуществление мероприятий СОРМ-2.

Дело в том, что ключевым компонентом этой архитектуры, определяющим как

поддерживается шифрование, является расширение заголовка данных для безопасной

инкапсуляции данных ESP (Encapsulating Security Payload) [5]. Расширение ESP

определено как для трафика IPv4, так и IPv6. Применение ESP может быть

осуществлено двумя способами: транспортным и туннельным.

Транспортный вариант осуществляет защиту информации на уровнях вышестоящих

уровню IP, но не защищает сам IP-заголовок. Туннельный вариант защищает весь IP-

пакет и подразумевает инкапсуляцию зашифрованных данных, т. е. в этом случае

исходный зашифрованный IP-пакет находится внутри другого пакета.

На приведенном в качестве примера рис. 2 заголовок верхнего уровня и данные (в этом

случае TCP) могут быть зашифрованы и аутентифицированы с помощью ESP.

Расширение заголовка ESP размещается до и после внутренних защищаемых полей.

Проблемы IPv6

Теперь рассмотрим сценарий развертывания сети, в которой ISP предоставляет сервис

IPv6 с реализацией функций ААА на основе протокола DIAMETER. Указанные

специальные приложения DIAMETER, расширяющие базовый протокол DIAMETER

для данного сценария, определены в [3, 4]. Например, после того, как пользователь

набирает номер к сетевому серверу доступа, NAS посылает серверу DIAMETER запрос

аутентификации и/или авторизации AA-Request, а в AVP указывает такую

информацию, как User-Name и User-Password, соответствующие имени и паролю

пользователя. В этом случае сервер DIAMETER отвечает сетевому серверу доступа с

помощью сообщения AA-Answer, содержащего соответствующую AVP.

В случае предоставления услуг IPv6 в AVP определяются Framed-Interface-Id и FramedIPv6-Prefix, которые сообщают сетевому серверу доступа об идентификаторе

интерфейса IPv6 и префиксах, сформированных сервером для пользователя. Эти AVP

присутствуют в сообщении AA-Answer, посылаемом от сервера к сетевому серверу

доступа, и используются сетевым сервером доступа для информирования пользователя

о сформированном IPv6-адресе.

В этом случае применимы определенные в базовом протоколе DIAMETER

спецификации безопасности. Поэтому связь между сетевым сервером доступа и

сервером DIAMETER организуется с использованием ESP IPsec с " ненулевым"

алгоритмом шифрования. Журнал «Вестник связи», №12, 2006

Как и в случае использования сервисов IPv6 на основе аутентификации RADIUS,

рассматриваемый случай не позволит системе СОРМ-2 определить попытку

контролируемого объекта получить доступ к сети Интернет-провайдера или

обнаружить, что пользователю были назначены идентификатор интерфейса IPv6 и

префикс. Все последующие действия контролируемого объекта, проводимые им на

основе выделенного адреса, также не смогут быть перехвачены.

Депонирование ключей шифрования

Возможным решением вышеизложенных проблем является предоставление системе

СОРМ-2 ключей шифрования, используемых ААА-инфраструктурой. Это вариант

предоставления ключей в виде их депонирования, т. е. сохранения ключей шифрования

в некоей доверенной системе, например, у того же ISP. Это решение депонирования

ключей отчасти противоречит желанию обеспечить конфиденциальность передаваемой

через IP-сеть информации.

Более того, для обеспечения конфиденциальности связи необходимо обеспечить и

защиту ISP от возможных внешних вторжений с целью доступа к ключам шифрования.

Внешние атаки могут быть инициированы как с целью получения доступа к ключам,

используемым для шифрования ААА-сообщений, так и получения ААА-информации,

например, такой как присвоенный пользователю IP-адрес, что позволит

злоумышленнику совершать несанкционированные перехваты.

Протокол законного перехвата информации

Другим возможным решением проблем СОРМ-2 в IP-сетях может служить создание

специального протокола прикладного уровня, который бы позволял ПУ СОРМ

определять моменты начала и окончания использования контролируемым

пользователем услуг сети и осуществлять перехват пользовательской информации,

циркулирующей к/от определенного IP-адреса.

Рис. 3. Диаграмма взаимодействия участников СОРМ-2 в IP-сети с DIAMETERЖурнал «Вестник связи», №12, 2006

С помощью такого протокола СОРМ может информировать ААА-сервер, что она

нуждается в перехвате пользовательского контента передаваемого/получаемого

контролируемым объектом с определенным идентификатором, например, < имя

пользователя> @< домен>. В этом случае ААА-сервер, используя тот же самый

протокол, информировал бы систему СОРМ о пользовательском логине и

используемом объектом контроля IP-адресе для перехвата информации.

По окончании пользовательской сессии ААА-сервер или устройство доступа сообщили

бы системе СОРМ об окончании сессии для прекращения процедуры перехвата. С

использованием такого протокола система законного перехвата могла бы также

информировать ААА-сервер об окончании необходимости перехвата информации

конкретного объекта контроля.

Рис. 3 иллюстрирует сообщения для описанного выше гипотетического случая,

представляющего возможное решение изложенной выше проблемы IPv6 и протокола

DIAMETER. Показанные на рис. 3 сообщения DIAMETER (между сетевым сервером

доступа и ААА-сервером) определены в [3, 4].

Вместо заключения

Появляющиеся в сетях Интернет-провайдеров системы законного перехвата IP-

сообщений строятся на основе медиаторов СОРМ, ориентированных на обработку

сообщений протокола RADIUS для определения присвоенного объекту контроля IP-

адреса и последующего перехвата всей циркулирующей к нему/от него информации.

Такие медиаторы существуют и для российских стандартов СОРМ, но для будущих

сетевых структур СОРМ-2 сетей связи с IPv6 и мобильным IPv6 с ориентированной на

DIAMETER архитектурой ААА и с использованием шифрования.

Причем, в соответствующем RFC оговаривается использование IPsec с ESP и

" ненулевого" алгоритма шифрования. В этом случае критическим для реализации

СОРМ-2 будет точная идентификация адресов и местоположения объекта наблюдения,

а также использование шифрования информации объекта наблюдения при попытке

доступа в сеть. Эти факторы требуют расширения функциональности и сетевых

конфигураций систем СОРМ, описанных в этой статье. Разумеется, описанные в

качестве примеров возможные решения должны быть развиты и тщательно

проанализированы соответствующими специалистами.

В целом же выполнение функций СОРМ-2 для IP-сетей является сложной и

относительно новой задачей, требующей анализа и обсуждения спецификаций и

инженерных решений. Конечной целью посвященных данной тематике исследований

является нахождение компромисса между безопасностью связи и ее открытостью для

средств СОРМ-2, также обеспечивающих безопасность граждан и государства. Журнал «Вестник связи», №12, 2006

Литература

1. Гольдштейн Б.С., Крюков Ю.А., Хегай И.П. Инженерные аспекты СОРМ/ Вестник

связи. - 2005. № 9.

2. Lawful Interception for IP Networks. White Paper, Aqsacom Inc., Tech. Rep., 2004.

3. P. Calhoun, J. Loughney, E. Gutman, G. Zorn, J. Arkko. Diameter Base Protocol, RFC

3588, September 2003.

4. P. Calhoun, G. Zorn, D. Spence, D. Mitton. Diameter Network Access Server Application.

5. S. Kentand, R. Atkinson. IP Encapsulating Security Payload (ESP), RFC2406, November

1998.

6. Крюков Ю.С., Ярыгин А.Г. Процедура законного перехвата IP трафика.

Международный опыт, INSIDE, № 6 2005.

7. D. Johnson, С. Perkins, J. Arkko. MobilitySupportinIPv6.

Bog BOS: IOS: AAA (authentication, authorization, accounting), tacacs+, RADIUS

Сервер доступа (tacacs+, RADIUS) - это программа, которая крутится на UNIX-компьютере и отвечает на запросы киски типа: есть ли такой пользователь, какие у него права и ведет журнал посещений. AAA расшифровывается как authentication (установление личности пользователя), authorization (проверка полномочий) и accounting (учет использования ресурсов). Для каждой из трех функций используется поименованный список методов, примененный к интерфейсу. При необходимости использования любой функции AAA IOS " пробегает" по этому списку пытаясь соединиться с соответствующим сервером. Если соединиться не удается (локальная БД отвечает всегда), то IOS переходит к следующему методу из списка. Если методов в списке не осталось, то регистрируется отказ. По умолчанию, к каждому интерфейсу применяется список методов по имени default. Если не требуется что-то необычное, то рекомендуется определить ровно один свой список методов с именем default и пусть он применяется ко всем интерфейсам.

Как конфигурировать сервер TACACS+ смотри отдельную главу, для конфигурирования RADIUS глава еще(?) не написана. Cisco позволяет использовать все атрибуты TACACS+ при работе с RADIUS при помощи vendor specific attribut (cisco-avpair= " shell: priv-lvl=15"). NAS привязывается к серверу так (надо включить AAA и определить параметры серверов, можно определить несколько TACACS+ или RADIUS серверов - в этом случае NAS будет пробовать их по очереди):
═ ═ aaa new-model # будем использовать tacacs+, а не старые варианты
═ ═ aaa processes число # количество параллельных процессов, обслуживающих AAA (количество одновременно заходящих пользователей). У меня загрузка второго процесса составляет 10% от загрузки 1го, так что, думаю, что двух достаточно.
═ ═ show ppp queues # показывает, сколько AAA процессов запущено и их статистику (странное название и странные числа он показывает)
═ ═ tacacs-server host IP-адрес-tacacs+-сервера [ single-connection ] [ port порт(49) ] [ timeout секунд ] [ key ключ-шифровки ] # tac_plus 4.0.2 не поддерживает single-connection; можно указывать несколько серверов, они будут пробоваться по очереди
═ ═ tacacs-server key key < пароль> # ключ, с помощью которого шифруются сообщения между киской и tacacs+ сервером
═ tacacs-server retransmit retries # число попыток достучаться до сервера (по умолчанию - 2)
═ tacacs-server timeout seconds # сколько ждать, чтобы убедиться, что сервер не работает (по умолчанию - 5 секунд)
═ ip tacacs source-interface subinterface-name # задать исходный IP-адрес TACACS пакетов
═ tacacs-server directed-request # включен по умолчанию; управляет использованием имен пользователей в виде: имя@сервер; если включен, то на указанный сервер (проверяется, что он указан в конфигурации, иначе вся строка посылается на сервер по умолчанию) посылается короткое имя пользователя, если выключен - вся строка на сервер по умолчанию. В документации не описано действие ключа restricted.
═ radius-server host IP-address [auth-port порт ] [acct-port порт ] non-standard # non-standard означает реализацию ciscoи обеспечивает работу ключей key и configure-nas
═ radius-server key ключ
═ radius-server configure-nas # радиус сервер будет снабжать информацией о статических маршрутах и пулах IP адресов
═ radius-server retransmit retries
═ radius-server timeout seconds
═ radius-server dead-time minutes
═ radius-server vsa send [accounting | authentication] # позволять использовать VSA (vendor specific attribut)
═ ip identd # поднять ident сервер