2. Radius Основные положения

Название протокола складывается из первых букв слов - Remote Authentication Dial In User Service (услуга удаленной ау­тентификации вызывающего пользователя). Это определение описывает скорее область, где чаще всего применяется протокол RADIUS: аутентификация подклю­чений пользователей к серверу для получения доступа у Оператора связи.

Разработка протокола была начата в далеком 1991 году фирмой Livingston, специализирующейся на производстве серверов удаленного доступа. Протокол оказался интересным и перспективным проектом, который заметили и взяли на доработку специалисты из Мичиганского университета. А уже оттуда документа­ция и все работы по описанию и оформлению технологии перешли в IETF. Работы по специфиации RADIUS увенчались успехом и были оформлены в виде двух базо­вых документов [65] и [66]. С этого времени RADIUS стал и продолжает оставаться открытым стандартом, что обеспечило ему популярность среди производителей оборудования и возможность его доработки и модернизации. Сегодня RADIUS является одним из самых распространенных AAA-протоколов, используемых в се­тях самых разных Операторов связи и провайдеров телекоммуникационных услуг. Рассмотрим архитектуру, структуру организации и особенности протокола RADIUS.

Архитектура radius

RADIUS представляет собой протокол, соответствующий архитектуре «кли­ент-сервер». Обмен сообщениями производится поверх протокола транспортного уровня UDP. Заметим, что использование UDP диктует необходимость реализа­ции схем контроля доставки и повторной передачи средствами самого протокола RADIUS. Общая схема взаимодействия элементов в архитектуре RADIUS пред­ставлена на рис. 2.1.

Рис. 2.1. Архитектура протокола RADIUS

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

• RADIUS-сервер - элемент, отвечающий за прием клиентских запросов, аутентификацию и авторизацию пользователей, и возврат клиенту всех параметров, необходимых для предоставления услуги. Кроме того, он может выступать в качестве посредника (прокси) для других RADIUS- серверов или серверов иного типа.

• Сервер доступа к сети NAS (Network Access Server) выступает в качест­ве клиента протокола RADIUS, отвечает за передачу информации о поль­зователе системы RADIUS-серверу и проведение дальнейших действий в соответствии с полученным ответом.

• Пользователь - не входит в архитектуру RADIUS, но является неотъемле­мой частью всей цепи взаимодействия. Подключается к NAS для переда­чи информации авторизации, аутентификации и учета.

В протоколе RADIUS реализована схема авторизации, со­гласно которой каждый из пользователей пытается получить доступ к услуге через NAS. При этом каждый из серверов доступа имеет связь не менее чем с одним сервером RADIUS. Однако их может быть и больше. В этом случае они объединяются в кластер из нескольких серверов, который обыч­но использует специальные средства для распределения нагрузки между ними, например, по дисциплине RR (Round Robin), или для резервирования оборудова­ния, на случай возникновения неисправностей. Кроме того, любой сервер может выступать посредником (прокси) по отношению к другим серверам.

Для своей работы протокол RADIUS использует стандартный порт 1812, а для протокола учета RADIUS - RADIUS Accounting - выделен порт 1813. Кроме того, для специального расширения RADIUS Dynamic Authorization Client при­нято использовать порт 3799. В качестве транспортного протокола, как уже было сказано, используется протокол UDP. Его выбор обосновывается следующими обстоятельствами:

• Необходимость повторной передачи запроса на резервный сервер тре­бует, чтобы реализация RADIUS-протокола сохраняла копию отправлен­ного запроса на прикладном уровне. При этом возникает необходимость добавления таймеров повторной посылки. Так как повторные посылки в таком случае контролируются выше транспортного уровня, RADIUS про­ще реализуется поверх протокола UDP.

• Временные характеристики протокола UDP в значительной степени от­личаются от временных характеристик TCP. С одной стороны, RADIUS не требует «мгновенного» детектирования проблемы на транспортном уровне (то есть детектирование за время порядка десятков или даже сотен миллисекунд не требуется). Время ожидания порядка одной-двух секунд вполне устроит пользователя, выполняющего аутентификацию. В этом отношении политика повторной передачи TCP с подтверждениями транспортного уровня является избыточной для задач, выполняемых про­токолом RADIUS. С другой стороны, проблемы в сети, вызывающие рост параметра Round Trip Time (Я7Т),‘могут стать причиной слишком долгой доставки информации поверх TCP, так как механизм повторных посылок TCP протокола базируется на параметре RTT. В подобной ситуации быс­трее переслать запрос на резервный сервер поверх ненадежного прото­кола UDP и получить ответ на запрос аутентификации.

• Протокол RADIUS, как протокол без сохранения состояния, гораздо про­ще реализовать поверх UDP. В условиях «живой» сети клиенты и серверы RADIUS могут появляться и исчезать - плановые или аварийные перезаг­рузки, сетевые проблемы и прочие обстоятельства приводят к тому, что транспортные соединения TCP-протокола по разным причинам будут требовать переустановки или полного закрытия соединения. Это не явля­ется серьезной проблемой при грамотном конфигурировании процедур проверки соединений и таймеров повторных посылок, однако проще вообще исключить необходимость контроля состояния узлов в сети, ис­пользуя UDP, в котором отсутствует понятие постоянного соединения.

• UDP упрощает реализацию сервера. Ранние реализации серверов RADIUS были однопоточными, что подразумевало последовательную об­работку запросов. При росте сетевой инфраструктуры стало понятно, что однопоточные серверы не могут выдерживать нагрузку, когда время об­работки одного запроса имеет порядок секунд (при выполнении поиска в базе данных или при DNS-запросе). Переполнение очереди на обработку запросов пользователей в таком случае приведет к тому, что процедура аутентификации будет продолжаться пол минуты и более, что является неприемлемым для конечного пользователя. Очевидным выходом из сложившейся ситуации стало использование многопоточных серверов, реализация которых проще выполнялась поверх UDP. Обработка запроса производится в рамках отдельного процесса, который отвечает на дан­ный запрос UDP пакетом без какого-либо контроля ТСР-соединений.

Следует отметить, что многие из перечисленных вопросов обеспечения надежной доставки AAA-информации обсуждались в процессе выбора протокола транспортного уровня для AAA-протокола нового поколения Diameter. При этом были подняты такие вопросы как переход на резервные серверы, повторная посылка информации, обнаружение дублирующихся данных, разделение нагрузки и др. Результаты данной работы в 2003 году были оформлены в виде отдельной RFC 3539 [22]. Кроме того, на момент стандартизации Diameter уже был разработан надежный протокол транспортного уровня SCTP (Stream Control Transmission Protocol), который включал в себя новые механизмы резерви­рования и проверки состояния соединений. В результате протокол Diameter стан­дартно работает поверх транспортных протоколов с надежной доставкой инфор­мации как SCTP, так и TCP, функционирование которых подразумевает установку и поддержание постоянного соединения.