Рис 1.2 Агентская последовательность

2. Последовательность с опросом

Последовательность с опросом (рис. 1.3) используется в приложениях удаленного доступа, в Mobile-IP окружении и в некоторых приложениях, обеспечивающих качество обслуживания. Пользователь отправляет запрос на оборудование услуги (шаг 1), которое перенаправляет его на AAA-сервер сервис-провайдера (шаг 2). AAA-сервер выполняет обработку запроса и передает соответствующий ответ на оборудование услуги (шаг 3), которое устанавливает услугу и уведомляет пользователя о готовности (шаг 4).

Рис. 1.3 Последовательность с опросом

3. Последовательность с билетом

Последовательность с билетом (рис. 1.4) подразумевает получение пользователем билета от AAA-сервера сервис-провайдера, подтверждающего его право пользования услугой (шаги 1,2). Пользователь прикладывает к запросу, отправляемому на оборудование услуги, полученный билет (шаг 3). Оборудование услуги на основе этого билета выполняет верификацию запроса и отвечает подтверждени­ем пользователю (шаг 4).

Рис. 1.4 Последовательность с билетом

4. Процедуры учета

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

RFC 2975, специфицирующая основные понятия процедур учета, а также формулирующая определения основных относящихся к учету терминов, была утверждена IETF в 2000 году. Целью ее создания была выработка универсальных требований к приложениям учета, которые можно было бы использовать при последующем создании универсального протокола учета и разработке универсальных механизмов обеспечения защиты информации.

Согласно RFC 2975:

Биллинг - совокупность действий, нужных для приготовления счета.

Аудит-акт верификации корректности этой совокупности действий.

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

Учет в пределах одного домена - сбор информации об использовании ресурса в пределах административного домена при пользовании ресурсом в рамках этого домена. В процессе учета в пределах одного домена информация учета, как правило, не пересекает административных границ.

Междоменный учет - сбор в рамках одного домена информации об использовании ресурса в рамках другого домена. В случае междоменного учета информация учета, как правило, пересекает административные границы.

Учет в режиме реального времени - обработка информации учета использования ресурса внутри определенного временного окна. Временные ограничения накладываются, как правило, для ограничения финансового риска.

Сервер учета - получает информацию учета от устройств и преобразует ее в сессионные записи. Сервер учета может также отвечать за доставку сессионных записей заинтересованным сторонам.

1. Архитектура системы управления учетом

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

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

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

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

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

Принятие решения о маршрутизации событий учета часто возлагается на прокси-сервер. Устройства сети обычно передают события учета на такой прокси, который либо трансформирует их в сессионные записи, либо перенаправляет пакеты в другие домены. В случае если прокси-сервер не является доверенным устройством, на него возлагаются только функции пересылки записей учета без генерации сессионных записей. В силу того, что протоколы учета, как правило, поддерживают функции обеспечения защиты дата-обьекта, это позволяет получателям удостовериться, что пакет не был модифицирован, и его содержимое не попало в руки злоумышленников, и генерировать сессионные записи самостоятельно.

Рис. 1.5 Внутридоменный и междоменный учет

2. Модели передачи информации учета

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

• опрос;

• передача по событию без агрегирования;

• передача по событию с агрегированием;

• опрос по событию.

1. Опрос

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

Модель подразумевает агрегированную отправку информации учета, так как она успевает накопиться с момента предыдущего опроса, и часто требует существенных сетевых ресурсов для ее передачи. Понятно, что модель с опросом очень плохо масштабируется, так как в случае крупной распределенной сети требует опроса всех устройств во избежание потери информации учета. Особенно плохо такая модель будет работать в условиях роуминга, так как получение информации о пользователях своего домена потребует выполнения запросов ко всем устройствам всех доменов, с которыми данный сервис-провайдер имеет соглашения о сотрудничестве. Следствием необходимости опрашивать большое количество устройств является также большое значение интервала опроса, что делает эту модель непригодной в сценариях, где требуется оперативная доставка информации учета.

2. Передача по событию без агрегирования

Метод передачи информации учета по событию лишен недостатков предыдущего метода. Его суть заключается в том, что устройство, обладающее информацией учета, передает ее на сервер учета сразу же, как только эта информация готова к отправке. Так как передача выполняется без агрегирования информации учета, то есть в одном пакете передается информация об одном событии, задержка передачи информации является минимальной.

Вследствие этого такая модель распространена в распределенных сетях и в сетях с функциями роуминга. Именно эта модель учета применяется в протоколе кредитного контроля Diameter, а также в протоколе учета RADIUS и в функциях учета базового протокола Diameter. Понятно, что при передаче по событию без агрегирования объем сигнального трафика будет пропорционален количеству событий, подлежащих учету, так как передача каждого события требует отдельного пакета протокола учета.

3. Передача по событию с агрегированием

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

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

4. Опрос по событию

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

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

2. Исследование функций протокола RADIUS

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

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

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

2. Архитектура 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 (RTT), могут стать причиной слишком долгой доставки информации поверх TCP, так как механизм повторных посылок TCP протокола базируется на параметре RTT. В подобной ситуации быстрее переслать запрос на резервный сервер поверх ненадежного протокола UDP и получить ответ на запрос аутентификации.

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

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

3. Общая схема взаимодействия при использовании протокола RADIUS

В ситуации, когда пользователи используют протокол RADIUS, каждый из них должен предоставить клиенту свою аутентификационную информацию. Это может выполняться в форме приглашения на вход в систему (login prompt), где пользователь должен ввести свое регистрационное имя и пароль. Другим вариантом может быть использование канальных протоколов типа РРР, в которых поддерживаются специальные пакеты идентификации для передачи сведений о пользователе.

После того как клиент получит идентификационные данные пользователя, он имеет право провести процесс аутентификации с использованием RADIUS. Для этого клиент создает пакет Access-Request, содержащий такие атрибуты, как регистрационное имя пользователя, пароль, идентификатор клиента и порта (Port ID), через который регистрируется в системе данный пользователь. При наличии пароля он кодируется с использованием алгоритма RSA MD5.

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

Пользовательская запись в базе данных содержит список требований, которым пользователь должен удовлетворять для получения доступа в сеть. К таким требованиям относится, в первую очередь, совпадение пароля, но в базе данных может также указываться клиент (клиенты) и порт (порты), через которые пользователю разрешен доступ.

При невыполнении какого-либо из условий при обработке сообщений RADIUS-сервер передает отклик Access-Reject, показывающий некорректность пользовательского запроса. При желании сервер может включать в Access-Reject текстовое сообщение. Никакие иные атрибуты (за исключением Proxy-State) не могут включаться в Access-Reject. Если все условия выполнены, и RADIUS-сервер хочет узнать дополнительную информацию, то он передает отклик Access- Challenge. Этот отклик может включать текстовое сообщение, выводимое клиентом для пользователя с приглашением ответить на вопросы сервера. Если клиент получает отклик Access-Challenge и поддерживает режим challenge/response, он может вывести текстовое сообщение (если таковое имеется в пакете отклика) для пользователя. После этого клиент снова передает первоначальный запрос Access-Request с новым идентификатором (request ID), атрибутом User-Password и атрибутом State из Access-Challenge (если этот атрибут присутствовал в отклике). Сервер может передать в ответ на новый запрос Access-Request отклик типа Access-Accept, Access-Reject или Access-Challenge.

При выполнении всех условий в отклик Access-Accept включается список конфигурационных параметров для данного пользователя. К таким параметрам относятся тип сервиса, например, SLIP, РРР, Login User, и все требуемые для предоставления этого сервиса значения. Для протоколов SLIP и РРР могут включаться параметры IP-адреса, маски подсети, MTU и другие. Для терминальных пользователей эти параметры могут указывать желаемый протокол и хост.

При использовании режима challenge/response пользователю передается случайное число и ожидается возврат зашифрованного отклика на это число. У легитимных пользователей имеется специальное устройство (например, смарт-карта) или программа для вычисления корректного отклика. Пользователь, не имеющий нужного устройства или программы и не знающий секретного ключа, который позволит эмулировать устройство/программу, может лишь попытаться угадать правильный отклик.

Пакет Access-Challenge обычно содержит атрибут Reply-Message, содержащий передаваемый пользователю запрос (challenge), в качестве которого могут использоваться редко повторяющиеся числа. Обычно запрос получают от внешнего сервера, которому известен тип аутентификатора, доступного авторизованному пользователю и который, следовательно, может выбрать случайное или редко повторяющееся число с подходящим основанием и длиной. Пользователь вводит это число в свое устройство (или программу), вычисляющее отклик, которого ожидает сервер RADIUS во втором запросе Access-Request. Если полученное от пользователя значение соответствует ожидаемому, RADIUS-сервер возвращает отклик Access-Accept, а при несоответствии - отклик Access-Reject.

4. Алгоритмы аутентификации, авторизации и учета RADIUS

1. Базовая схема работы протокола

При использовании протокола RADIUS-клиентом (NAS-сервером) пользователь должен передать ему свою аутентификационную информацию. Это может производиться посредством приглашения в систему (login promt) или при помощи встроенных механизмов передачи данной информации канальным протоколом (например, РРР). На участке «пользователь - NAS» используются различные технологии передачи необходимых данных. Обобщенные схемы обмена сообщениями при входе пользователя в систему приведены на рис. 2.2 и рис. 2.3

Рис. 2.2. Процесс обмена сообщениями по протоколу RADIUS, успешный исход

Рис. 2.3. Процесс обмена сообщениями по протоколу RADIUS, неуспешный исход

После получения аутентификационных данных NAS-сервер проводит аутентификацию с использованием протокола RADIUS. При этом NAS формирует пакет Access-Request.

Пакет Access-Request передается по сети серверу. Если через некоторое время ответ на него не приходит, то запрос передается повторно.

Защита паролей при передаче по сети обеспечивается благодаря шифрованию RSA MD5 с использованием разделяемого ключа (shared secret).

Для каждой пары клиент-сервер имеется свой разделяемый ключ. Он конфигурируется администратором и по сети никогда не передается. После получения клиентского запроса RADIUS-сервер проверяет, имеется ли для этого клиента (NAS-сервера) разделяемый ключ. Если он не находит ключа, то пакеты отбрасываются без уведомления. Если проверка завершается успешно, то сервер приступает к поиску профиля пользователя в базе данных.

RADIUS-сервер в некоторых ситуациях может выступать в качестве посредника и пересылать запросы другим серверам. При невыполнении любого из условий, приведенных в запросе, NAS-серверу, передается сообщение Access-Reject, показывающее некорректность запроса пользователя. В сообщение может включаться атрибут или вложенное сообщение, которое должно быть передано пользователю от NAS-сер­вера. При выполнении всех условий NAS-серверу передается сообщение Access- Accept, включая список необходимых конфигурационных параметров.

2. Схема Challenge/Response

Режим Challenge/Response необходим для проверки прав доступа или запроса дополнительной информации у пользователя. В случае использования схемы Challenge/Response процедура аутентификации пользователя несколько усложняется по сравнению с базовой и выглядит следующим образом. Сервер NAS передает RADIUS-серверу пакет Access-Request с заданными атрибутами, на что тот возвращает ответ - сообщение Access-Challenge. Обычно оно содержит поле Reply-Message, включающее запрос (challenge), который необходимо передать конечному пользователю; это поле заполняется случайным числом специального вида. Запрос обычно получают от внешнего сервера, которому известен идентификатор, используемый пользователем, и который сможет генерировать случайное число с подходящим основанием и длиной.

У пользователя, в свою очередь, установлено приложение, которое позволяет по имеющемуся запросу вычислить ответ по определенному алгоритму. Этот ответ (вычисленное число) включается в повторный пакет Access-Request наряду с атрибутом State, взятым из запроса. Так делается для того, чтобы сервер смог правильно интерпретировать полученное сообщение. Если отклик совпадает с ожидаемым сервером, то в ответ посылается пакет Access-Accept, иначе передается Access-Reject. В случае необходимости допускается также повторная посылка сервером пакета Access-Challenge. Схематично процедура Challenge/Response изображена на рис. 2.4.

Рис. 2.4. Общая схема реализации режима Challenge/Response для протокола RADIUS

3. Взаимодействие с технологиями РАР и CHAP

Механизмы аутентификации PAP (Password Authentication Protocol), CHAP (Challenge Handshake Authentication Protocol), а позже - EAP (Extensible Authentication Protocol), были специально разработаны для проведения процедуры аутентификации на участке «пользователь - NAS- сервер». При этом в протокол RADIUS были включены специальные атрибуты, которые позволяют прозрачно передавать пользовательские параметры от NAS-сервера на RADIUS-сервер.

При использовании протокола РАР сервер доступа NAS принимает PAP ID и пароль, передавая их в запросе Access-Request на RADIUS-сервер в полях атрибутов User-Name и User-Password.

Использование протокола CHAP считается более безопасным методом аутентификации, в силу того, что пароль пользователя не передается в этом случае по сети. Для его реализации NAS-сервер генерирует случайное число - challenge (предпочтительно длиной - 16 байтов) и отправляет его пользователю, который генерирует и возвращает СНАР-отклик вместе с CHAP ID и CHAP username.

После этого NAS-сервер передает запрос Access-Request к RADIUS-серверу с атрибутом User-Name, содержащим значение CHAP username, и атрибут CHAP-Password с параметрами CHAP ID и СНАР-отклик.

На основании атрибута User-Name сервер RADIUS определяет пароль для пользователя, шифрует значение Challenge, применяя алгоритм MD5 к октету CHAP ID, найденному паролю и CHAP Challenge (из атрибута CHAP-Challenge) и сравнивает полученные результаты с атрибутом CHAP-Password. При совпадении сервер возвращает на NAS-сервер сообщение Access-Accept, в противном случае - Access-Reject. Если сервер RADIUS не способен выполнить запрошенную аутентификацию, он отправляет пакет Access-Reject. Например, требуется, чтобы пользовательский пароль был доступен серверу в открытом виде для шифрования CHAP challenge и сравнения с откликом CHAP. Если правила защиты, установленные в сети, не позволяют использовать незашифрованный пароль, то сервер RADIUS возвращает клиенту сообщение Access-Reject.

Рис. 2.5 Аутентификация при работе технологии CHAP

4. Протокол учета RADIUS (RADIUS Accounting)

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

Общая схема реализации процедуры учета приведена на рис. 2.7. В слу­чае, когда клиент (NAS-сервер) настроен на использование процедуры RADIUS accounting на начальном этапе, он передает пакет Accounting-Request Start (т.е. Acct-Status-Type = start), описывающий тип предоставляемой услуги. RADIUS-сервер должен сформировать и отправить соответствующий отклик на него.

При завершении пользовательского сеанса NAS-сервер генерирует пакет Accounting-Request Stop, который может содержать статистические данные о сессии - продолжительность сеанса, число пакетов и байтов, принятых и переданных пользователем. В ответ RADIUS-сервер также должен отправить необходимый отклик. В случае отсутствия ответного сообщения клиенту (NAS-серверу) рекомендуется повторять передачу пакета Accounting-Request до тех пор, пока не будет получен ответ от RADIUS-сервера.

Клиент может также переслать запрос резервным RADIUS-серверам, если основной сервер не работает или недоступен. Если RADIUS-сервер не может записать пакет учета, то он не должен посылать отклик. В механизме учета предусмотрена возможность использования RADIUS-серверов в режиме прокси.

Рис. .2.7. Обмен сообщениями по протоколу RADIUS Accounting

Алгоритм работы сервера-посредника RADIUS в режиме accounting приведен ниже:

Шаг 1. NAS передает пакеты Accounting-Request пересылающему RADIUS- серверу (прокси).

Шаг 2. Пересылающий сервер, в свою очередь, протоколирует пакет Accounting-Request, добавляет атрибут Proxy-State (если в этом есть необходимость) после имеющихся в пакете атрибутов Proxy-State, обновляет значение Request Authenticator и пересылает запрос удаленному серверу.

Шаг 3. Удаленный сервер протоколирует пакет Accounting-Request, копирует все атрибуты Proxy-State, не изменяя их порядка, в пакет отклика и передает отклик Accounting-Response прокси-серверу.

Шаг 4. Пересылающий прокси-сервер удаляет из пакета последний атрибут Proxy-State (если он был добавлен на шаге 2), обновляет значение Response Authenticator и передает пакет Accounting-Response NAS-серверу.

Для прокси-сервера недопустимо изменение присутствующих в пакете атрибутов Proxy-State или Class. Прокси-сервер может прозрачно пересылать пакеты, передавая повторные пакеты по мере их получения, или принять на себя ответственность за передачу повторных пакетов (это удобно в тех случаях, когда сетевое соединение между посредником и удаленным сервером по своим характеристикам существенно отличается отсоединения между посредником и NAS).

3. Протокол Diameter

1. Предпосылки появления нового протокола ААА

На основе документов [23], [28] и [50], описывающих, соответственно, критерии оценки роуминговых протоколов, критерии оценки протоколов доступа к сети и требования к ААА в сетях Mobile IP, рабочая группа IETF подготовила документ RFC 2989 «Критерии оценки AAA-протоколов сетевого доступа», в котором были сформулированы требования к протоколам ААА нового поколения. В их числе масштабируемость, резервирование, взаимная аутентификация клиента и сервера, защита уровня передачи, конфиденциальность дата-объекта, целость дата-объекта, возможность передачи сертификатов, надежный механизм транспортировки AAA-сообщений, возможность работы поверх как IPv4, так и IPv6, поддержка прокси и брокеров маршрутизации, контролируемость, возможность передачи специфических для услуги атрибутов.

Руководствуясь этими критериями, сформированная в июне 2000 года группа специалистов IETF выполнила сравнение четырех протоколов-претендентов, заявленных на участие в конкурсе: SNMP, RADIUS++, Diameter и COPS. В результате продолжавшегося в течение шести недель исследования наиболее соответствующим требованиям RFC 2989 протоколом был признан протокол Diameter, за ним с небольшим отставанием следовал COPS.

1. Резервирование

В отличие от RADIUS, протокол Diameter предусматривает подтверждения уровня приложений, а также определяет алгоритмы перехода на резервный узел и соответствующий автомат состояний.

2. Защита уровня передачи

Для предоставления универсального средства обеспечения защиты уровня передачи, использование IPsec в протоколе Diameter является обязательным, а поддержка TLS (Transport Layer Security) опциональна.

3. Надежный транспорт

Гарантированная доставка сообщений играет решающую роль в обеспечении процедур учета, так как прямым следствием потери пакета может стать потеря дохода или даже убытки Оператора. Для обеспечения гарантированной доставки сообщений протокол Diameter работает поверх надежных транспортных протоколов, таких как TCP и SCTP .

4. Поддержка функций агентов

Протокол RADIUS не определяет явно механизм работы агентов, таких как прокси, серверы переадресации и ретрансляции, в результате чего их поведение различается в разных реализациях протокола. В отличие от RADIUS, в протоколе Diameter учтены четкие требования к функционированию такого рода агентов.

5. Поддержка сообщений, инициируемых сервером

Поддержка сообщений, инициируемых сервером, специфицирована для протокола RADIUS и является опциональной. Это создает определенные сложности при реализации таких функций, как разъединение по требованию сервера или повторная аутентификация/авторизация по требованию сервера в разнородном окружении. В протоколе Diameter поддержка сообщений, инициируемых сервером, является обязательной.

6. Улучшение контролируемости на уровне дата-обьекта

RADIUS не определяет механизмов обеспечения защиты информации на уровне дата-объекта, в результате чего прокси-серверы, не входящие в число уполномоченных, могут изменять атрибуты или даже заголовки пакетов без риска быть обнаруженными. В совокупности с отсутствием механизма согласования возможностей, этот недостаток делает очень сложной диагностику ошибок в случае какого-либо несовпадения информации во взаимодействующих системах. Несмотря на то, что поддержка безопасности на уровне дата-обьекта не обязательна, она определена для протокола Diameter.

7. Взаимодействие с RADIUS-совместимыми устройствами

В силу того что Diameter имеет отличный от используемого в RADIUS набор сообщений, в RFC 4005 описаны процедуры преобразования протоколов, позволяющие организовать взаимодействие с Diameter-агентами в устаревших системах, работающих по протоколу RADIUS.

8. Согласование возможностей

В отличие от RADIUS, протокол Diameter поддерживает механизм обработки ошибок, механизм согласования возможностей, а также флаг, определяющий обязательность/опциональность пар атрибут-значение.

9. Динамическое обнаружение узлов

Большинство реализаций протокола RADIUS требует предварительного конфигурирования имени или адреса сервера/клиента, а также соответствующих секретных слов. В результате существенно усложняются задачи администратора системы, который в целях ускорения ввода в эксплуатацию новых или перенастройки существующих узлов может начать использовать для разных серверов одно и то же секретное слово. Это, в свою очередь, влечет за собой угрозы защите, так как нарушается уникальность Request Authenticator, требуемая в RADIUS. Протокол Diameter поддерживает динамическое обнаружение узлов посредством DNS. Получение динамических ключей сессий реализуется механизмами защиты уровня передачи.

10. Поддержка роуминга

Рабочая группа ROAMOPS (Roaming Operations) провела исследование реализаций функций роуминга, сформулировала подробные требования к организации роуминга, определила понятие идентификатора сетевого доступа NAI (Network Access Identifier) и документировала существующие реализации роуминговых процедур, основанных на протоколе RADIUS. В целях достижения масштабируемости определяет концепцию проксирования через промежуточный сервер, обеспечивающий функции роуминга между провайдерами.

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

11. Расширяемость протокола

Отличительной особенностью протокола Diameter являются его большие возможности расширения, которое осуществляется за счет использования следующих механизмов:

• определение новых значений пар атрибут-значение (AVP);

• создание новых пар AVP;

• создание новых приложений аутентификации/авторизации;

• создание новых приложений учета;

• добавление новых механизмов аутентификации.

Повторное использование существующих значений AVP, существующих AVP и существующих приложений Diameter упрощает стандартизацию и реализацию протокола, а также снижает вероятность появления проблем взаимодействия, поэтому является наиболее предпочтительной стратегией. Новые коды команд могут быть зарегистрированы только IETF

12. Спецификации Diameter

В отличии от RADIUS структура протокола Diameter, представленная не единым документом, а группой спецификаций. В основе спецификаций Diameter лежат RFC 3588 «Базовый протокол Diameter» и RFC 3539 «Транспортный профиль аутентификации, авторизации и учета». Базовый протокол Diameter включает в себя описание формата сообщений, формата пар атрибут-значение, процедуры обработки и маршрутизации сообщений, описание агентов Diameter и правил их функционирования, порядок обработки ошибок. В базовый протокол Diameter включена также спецификация процедур учета, выделенная для протокола RADIUS в отдельный RFC. Как результат, поддержка функциональных возможностей учета является обязательной для всех реализаций протокола.

Базовый протокол Diameter определяет также концепцию приложений Diameter - протоколов, работающих на основе базового протокола. В состав специфицированных IETF входят следующие приложения Diameter:

• RFC 4004 «приложение Diameter для мобильного IPv4». Это приложе­ние позволяет серверу Diameter выполнять процедуры аутентификации, авторизации и учета в окружении Mobile IPv4.

• RFC 4005 «Diameter-приложение сервера доступа к сети» содержится описание формата сообщений и пар атрибут-значение, предназначен- ных для использования в рамках взаимодействия с сервером доступа к сети (NAS). В отличие от RADIUS, в котором функции управления досту­пом включены в спецификацию протокола, в случае Diameter процедуры работы сервера доступа к сети описаны в виде отдельного приложения.

• RFC 4006 «Приложение кредитного контроля Diameter» специфици­рует протокол взаимодействия с сервером кредитного контроля, поз­воляющий контролировать в реальном времени процесс расходования средств предоплаты пользователя. Необходимость создания отдельного приложения кредитного контроля Diameter связана с тем, что функции учета базового протокола не предусматривают авторизацию кредита до начала предоставления услуги.

И еще другие приложения.

2. Основы базового протокола Diameter

Базовый протокол Diameter обеспечивает поддержку следующих функциональных возможностей:

• доставка пар атрибут-значение (AVP);

• согласование возможностей;

• уведомление об ошибках;

• расширяемость за счет добавления новых команд и AVP;

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

Информация, переносимая протоколом Diameter, передается в форме пар AVP. Подробнее об этом - в п. 3.4. Некоторые AVP используются самим прото­колом, другие передают информацию, относящуюся к некому приложению, ис­пользующему базовый протокол Diameter. Заметим, что AVP могут добавляться в Diameter-сообщение в произвольном порядке, но с тем условием, что обязатель­ные AVP должны быть включены в сообщение, а явно запрещенные к использова­нию в сообщении данного типа - исключены из него.

1. Используемый транспорт

Базовый протокол Diameter использует порт 3868 как принимающий при работе по протоколам TCP и SCTP. Клиенты Diameter должны поддерживать либо протокол TCP, либо SCTP, а агенты и серверы Diameter должны поддерживать оба протокола согласно соответствующим спецификациям.

2. Роль Diameter-агентов

В дополнение к понятиям клиента и сервера протокол Diameter определяет понятия агента: агента прокси, агента ретрансляции, агента переадресации и агента преобразования. Использование агентов целесообразно в силу следующих причин:

• агенты позволяют администрировать системы в конфигурируемых группах;

• агенты обеспечивают возможность концентрации запросов от совместно расположенных или распределенных групп серверов доступа к сети;

• агенты могут выполнять обработку запросов или ответов;

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

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

Протокол Diameter требует, чтобы агенты сохраняли состояние транзакции в целях обеспечения функций резервирования. Состояние транзакции подразумевает, что при перенаправлении запроса сохраняется его идентификатор от-узла-к-узлу. Данное поле заполняется уникальным в пределах сервера идентификатором, который восстанавливается впоследствии в исходное значение при получении соответствующего ответа.

3. Заголовок сообщения Diameter

   1. Структура заголовка

Каждое сообщение протокола Diameter состоит из заголовка и пар атрибут-значение, переносящих «полезную» информацию приложения (рис. 3.1). Ниже представлена информация о заголовке сообщения Diameter. Поля передаются в сетевом порядке байтов.

Рис. 3.1 Заголовок протокола Diameter

Версия. Значение поля версии должно быть равно единице, что свидетельствует о протоколе Diameter версии 1.

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

Флаги команды. Поле флагов команды занимает восемь битов. Биты используются следующим образом(рис3.2)

Рис 3.2

R (запрос) - если бит установлен, данное сообщение является запросом. Если бит не установлен, - ответом.

Р (прокси) - если бит установлен, сообщение может быть проксировано, ретранслировано или переадресовано. Если бит не установлен, сообщение должно обрабатываться только локально.

Е (ошибка) - если бит установлен, сообщение содержит ошибку протокола и не будет соответствовать ABNF для данной команды. Сообщения с установленным битом «Е» называются ошибочными. Этот бит не может быть установлен в запросах.

Т (потенциально дублирующееся сообщение) - этот флаг устанавлива­ется после процедуры перехода на резервное соединение для обнаружения дублирующихся запросов. Бит «Т» устанавливается при повторной отправке неподтвержденного сообщения для индикации потенциально дублирующегося сообщения. Этот бит не должен быть установлен при первичной отправке. Агенты Diameter должны контролировать только количество сообщений, которое они отправляют на основе однократно полученного запроса. Повторные отправки, выполняемые другими элементами, не должны отслеживаться. Агенты Diameter, получившие сообщение с установленным флагом «Т», должны сохранить этот флаг в перенаправ­ленном сообщении. Флаг «Т» не должен устанавливаться, если при предыдущей посылке сообщения был получен ответ, содержащий информацию об ошибке. Он должен устанавливаться только в том случае, если от сервера не было получено ответного сообщения на переданный запрос, и запрос отправляется повторно. В ответных сообщениях флаг устанавливаться не должен.

r (резервировано) - биты резервированы для будущего использования и должны иметь значение ноль, а также игнорироваться получателем.

Код команды. Поле кода команды состоит из трех октетов и используется для передачи информации о типе команды, связанной с отправляемым сообщением. Использование 24-битового адресного пространства контролирует IANA. Коды 16777214 и 16777215 (шестнадцатеричные значения FFFFFE -FFFFFF) резервированы для экспериментального использования.

Идентификатор приложения. Поле идентификатора приложения состоит из четырех байтов и используется для идентификации приложения, к которому относится передаваемое сообщение. Приложением в данном случае может быть приложение аутентификации, приложение учета, или приложение, специфическое для производителя. Значение поля идентификатора приложения в заголовке должно совпадать со значением, передаваемым в соответствующей AVP этого сообщения.

Идентификатор от-узла-к-узлу. Идентификатор от-узла-к-узлу является 32-битовым числом типа unsigned (в сетевом порядке байтов) и служит для сопоставления запросов и ответов. Отправитель запроса должен удостовериться, что идентификатор от-узла-к-узлу является уникальным в пределах перезагрузки.

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

Идентификатор из-конца-в-конец. Этот идентификатор является 32-битовым числом типа unsigned (в сетевом порядке байтов) и используется для определения дублирующихся сообщений. В зависимости от реализации процедуры перезагрузки, старшие 12 битов идентификатора могут содержать младшие 12 битов текущего времени, а младшие 20 битов идентификатора могут быть случайным числом.

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

Идентификатор не должен модифицироваться агентами никакого типа. Комбинация этого идентификатора и Origin-Host AVP используется для обнаружения дублирующихся сообщений. На дублирующееся сообщение должен быть отправлен точно такой же ответ, причем состояние, возникшее в результате обработки первичного сообщения, не должно модифицироваться. Дублирующиеся сообщения об ошибках должны отбрасываться без уведомлений.

Пары атрибут-значение (AVP). Пары атрибут-значение (AVP) - это ме­тод инкапсуляции информации в соответствующее сообщение Diameter.

2. Коды команд

Каждое сообщение Diameter должно содержать код команды в поле заголовка с целью определения действия, которое должно быть выполнено для определенного сообщения. Базовый протокол Diameter определяет следующие значения кодов команд (табл. 3.1).

Таблица 3.1. Значение кодов команд

Название команды	Аббрев	Код	Ссылка на RFC 3588
Abort-Session-Request	ASR	274	8.5.1
Abort-Session -Answer	ASA	274	8.5.2
Accounting-Request	ACR	271	9.7.1
Accou n ting -Answer	АСА	271	9.7.2
Capabilities-Exchanae -Request	CER	257	5.3.1
Capabilities-Exchanae- Answer	CEA	257	5.3.2
Device-Watchdog-Request	DWR	280	5.5.1
Device-Watchdog-Answer	DWA	280	5.5.2
Disconnect- Peer- Request	DPR	282	5.4.1
Disconnect-Peer-Answer	DPA	282	5.4.2
Re-Auth-Request	RAR	258	8.3.1
Re-Auth-Answer	RAA	258	8.3.2
Session-Termination-Request	STR	275	8.4.1
Session-Termination-Answer	STA	275	8.4.2

4. Пары атрибут-значение базового протокола Diameter

Пары атрибут-значение AVP (Attribute Value Pairs) протокола Diameter переносят информацию, относящуюся к процедурам аутентификации, авторизации, учета, маршрутизации и обеспечения защиты, а также параметры конфигурации.

Некоторые AVP могут встречаться в сообщении более одного раза. Обработка таких ситуаций зависит от вида AVP. Каждая пара атрибут-значение типа OctetString должна дополняться до границы 32 битов, остальные AVP автоматически удовлетворяют этому требованию. Для достижения границы слова в конец поля информации AVP добавляются нули. Длина битов заполнения не отображается в поле длины AVP.

В этом параграфе описываются структура пар атрибут-значение и их формат.

1. Заголовок AVP

Заголовок является обязательной частью любой пары атрибут-значение протокола Diameter - в нем содержится информация о передаваемых в AVP данных. Поля заголовка AVP должны передаваться в сетевом порядке байтов. Ниже представлен формат заголовка: (рис. 3.3)

Рисунок 3.3

1. Код AVP

Код AVP в совокупности с полем идентификатора производителя уникально идентифицирует пару атрибут-значение. Пространство номеров от 1 до 255 резервировано для поддержки обратной совместимости с протоколом RADIUS. Номера 256 и выше используются в протоколе Diameter согласно распределению IANA.

2. Флаги AVP

Поле флагов AVP информирует получателя о том, как должен обрабатываться атрибут. Биты «r» (резервировано) не используются и имеют нулевые значения Необходимо отметить, что последующие приложения Diameter могут определить дополнительные биты в заголовке AVP, нераспознаваемый бит должен считаться ошибкой. Бит «Р» является индикатором необходимости использовать шифрование для обеспечения защиты из-конца-в-конец.

Бит «М», называемый битом обязательности, показывает, является ли поддержка данной AVP обязательной. Если AVP с установленным битом «М» получена клиентом, сервером, прокси или агентом преобразования, и либо AVP, либо ее значение не распознается, сообщение должно быть отклонено.

Агенты ретрансляции и агенты переадресации не должны отклонять сообщения с нераспознаваемыми AVP.

Бит «М» должен устанавливаться в соответствии с правилами, определенными для пары AVP, в которой он содержится. В целях поддержки взаимной совместимости реализация Diameter должна быть способна исключить из сообщения любую обязательную AVP, которая не определена ни в базовом протоколе Diameter, ни в какой-либо спецификации Diameter-приложения. Это должно выполняться одним из следующих способов:

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

• для узлов, определенных административных доменов или в масш­табах всей системы может быть добавлена конфигурационная опция, которая будет разрешать/запрещать отправку обязательных пар атрибут-значение. Используя такую опцию, администратор может изменить конфигурацию системы в случае возникновения проблем.

Реализации протокола Diameter должны поддерживать все обязательные AVP, разрешенные синтаксисом сообщения, а также определенные либо в базовом протоколе Diameter, либо в одной из спецификаций приложения Diameter, задающей формат сообщения. Пары AVP с неустановленным битом «М» являются информационными, и если получатель не поддерживает определенную AVP без этого бита или не поддерживает значение такой AVP, она может быть просто игнорирована. Бит «V», называемый также специфическим для производителя, является индикатором опционального поля, присутствующего в заголовке AVP. Если этот бит установлен, код данной AVP принадлежит адресному пространству, определяемому производителем. Если не определено иначе, AVP будут иметь следующие поля флагов: бит «М» должен быть установлен, бит «V» не должен быть установлен. «Бит установлен» означает присвоение этому биту значения 1, а «бит не установлен» - значения 0.

3. Длина AVP

Поле длины AVP занимает три байта и является индикатором количества байтов AVP, включая поля кода AVP, длины AVP, флагов AVP, поле идентификатора производителя (при наличии) и собственно информацию в AVP. Заголовок AVP содержит только одно опциональное поле. Это поле присутствует в случае, если соответствующий бит-флаг установлен.

4. Идентификатор производителя

Поле идентификатора производителя присутствует в случае, если в поле флагов AVP установлен бит «V». Это опциональное поле занимает четыре октета и содержит назначенный IANA идентификатор, закодированный в сетевом порядке байтов. Производитель, желающий использовать специфическую AVP, должен использовать собственный идентификатор и управляемое этим производите­лем пространство адресов, гарантирующие, что код AVP не совпадет ни с любой другой специфической для производителя AVP, ни с AVP, определенными для будущих IETF-приложений. Значение 0 в поле идентификатора производителя соответствует адаптированным IETF значениям, управляемым IANA. Поскольку отсутствие поля идентификатора производителя подразумевает использование не специфической для производителя AVP, значение 0 использоваться не должно.

5. Управление учетом в протоколе DIAMETER

В отличие от протокола RADIUS, для которого функциональные возможности учета специфицированы в отдельной RFC, описание протокола учета входит в базовую версию Diameter, так что его поддержка обязательна для всех Diameter-узлов. Этот протокол основан на модели управляющего сервера с возможностями доставки информации в реальном времени.

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

Сервер авторизации определяет выбор стратегии передачи на основе информации о пользователе и об отношениях роуминговых партнеров. Сервер (или агенты) использует пары атрибут-значение Accounting-lnterim-lnterval и Accounting-Realtime-Required для управления способом работы узла Diameter, выступающего в роли клиента. Пара Acct-lnterim-lnterval AVP указывает клиенту Diameter на необходимость периодической генерации записей учета во время сессии. Пара Accounting-Realtime-Required AVP позволяет управлять поведением клиента в случае, если передача информации учета от этого клиента отложена или неуспешна. Сервер Diameter может изменить требования к генерации промежуточных записей учета или о необходимости поддержки реального времени, включив Acct-Interim-Interval или Accounting-Realtime-Required AVP в сообщение Accounting-Answer. При получении этих AVP во время сессии для последующей обработки информации учета, относящейся к этой сессии, должны применяться значения AVP, полученные последними.

1. Сообщения протокола учета

Узел Diameter, получивший успешное сообщение аутентификации и/или авторизации от домашнего AAA-сервера, должен сохранять относящуюся к сессии информацию учета. Сообщение Accounting-Request используется в целях передачи информации учета на домашний AAA-сервер, который, в свою очередь, должен отправить ответное сообщение Accounting-Answer для подтверждения получения. Сообщение Accounting-Answer включает в себя пару атрибут-значение Result-Code, которая может содержать описание ошибки, произошедшей при обработке запроса. Если запрос Accounting-Request отклоняется сервером, пре­доставление услуги абоненту может быть остановлено в зависимости от значения Accounting-Realtime-Required AVP, полученного ранее для данной сессии.

2. Записи учета

В зависимости от параметров услуги, для которой выполняются процедуры учета, а также от директив сервера авторизации, касающихся промежуточной рассылки информации, используются различные типы записей учета. Если услуга, в отношении которой проводится учет, предоставляется пользователям единовременно в том смысле, что момент начала и момент окончания предоставления услуги совпадают, обязательным является использование Accounting-Record-Type AVP (п. 3.4.5.22), имеющей в значение EVENT_RECORD.

Если предоставление услуги продолжительно по времени, эта AVP должна содержать значения START_RECORD, STOP_RECORD, и, возможно, INTERIM_RECORD. Если сервер авторизации не запрашивает промежуточных записей учета, для каждой услуги-сессии должно быть генерировано две записи. При первой отправке Accounting-Request для данной сессии Accounting-Record-Type AVP должно быть присвоено значение START_RECORD. В последнем запросе Accounting-Request эта AVP должна содержать значение STOP_RECORD.

Если сервер авторизации указывает на необходимость выполнения промежуточного учета, Diameter-клиент должен генерировать дополнительные записи учета между START_RECORD и STOP_RECORD, отмечая их как INTERIM_RECORD. Период генерации промежуточных записей указывается Diameter-сервером в паре атрибут-значение Acct-lnterim-lnterval. Diameter-клиент должен перезаписы­вать старую запись учета, сохраненную локально для отправки на сервер в случае, если для той же самой сессии была генерирована новая промежуточная запись. Такой порядок работы позволяет гарантировать наличие только одной промежу­точной записи учета, ожидающей отправки на сервер.

6. Diameter-сервер доступа к сети и преобразование протоколов RADIUS/Diameter

   1. Приложение сервера доступа к сети Diameter

Утверждая, что протокол Diameter является преемником протокола RADIUS, следует отметить, что рассмотренный базовый протокол Diameter описывает лишь основу для приложений ААА, которые, используя предоставляемые базовым протоколом функции, реализуют логику услуги. Фактически прямым преемником RADIUS является не базовая версия протокола Diameter, специфицированная в RFC 3588, а разработанное на ее основе приложение NAS, описанное в RFC 4005. Именно этот документ содержит описание протокола обращения сервера NAS к серверу ААА в целях выполнения процедур аутентификации, авторизации и учета.

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

2. Преобразование протоколов RADIUS в Diameter

В этом параграфе следует строго различать понятия «пара атрибут-значение» (AVP) и «атрибут». Первое используется для идентификации пары атрибут- значение Diameter, в то время как второе - атрибута RADIUS. Несмотря на то, что функции протокола Diameter фактически представляют собой расширение функций RADIUS, некоторые механизмы RADIUS запрещены к использованию во избежание возможных проблем.

Существует две основные ситуации обрабатываемые RADIUS/Diameter конвертером: получение запроса RADIUS и его преобразование в запрос Diameter, и получение запроса Diameter и его преобразование в RADIUS.

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

1. Преобразование RADIUS-запроса в Diameter-запрос

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

При получении конвертером протокола RADIUS сообщения необходимо выполнить следующие операции:

• если в сообщении присутствует атрибут Message-Authenticator, значение атрибута должно быть проверено, но не должно отображаться в сообщении Diameter. Если этот атрибут содержит некорректное значение, сообщение должно отбрасываться без уведомления. В ответном RADIUS-сообщении значение атрибута Message-Authenticator должно генерироваться конвертером протоколов;

• адрес транспортного уровня отправителя должен быть проверен на соответствие атрибутам, идентифицирующим NAS;

• конвертер протоколов должен сохранять информацию о состоянии транзакции, относящуюся к RADIUS-запросу, такую как поле Identifier RADIUS-заголовка, атрибуты Proxy-State, если они присутствуют в запросе, а также IP-адрес и порт источника UDP-пакета. Такая информация может храниться локально в таблице состояний или в паре атрибут-значение Proxy-Info. Идентификатор сессии Diameter Session-ld должен создаваться на основе информа­ции о состоянии сессии;

• если запрос RADIUS содержит атрибут State с префиксом «Diameter/», информация, идущая после префикса, содержит Diameter Origin-Host/ Origin-Realm/Session-ld. Если этот атрибут в запросе отсутствует, конвер­тер протоколов должен создать новый Session-ld;

• AVP Diameter Origin-Host и Origin-Realm должны создаваться на основе информации FQDN атрибута NAS-IP-Address (предпочтительно) и/или атрибута NAS-identifier. Следует отметить, что NAS-identifier не обязательно представляет собой FQDN;

• ответное сообщение должно включать в себя пару атрибут-значение Origin-AAA-Protocol, указывающую протокол-источник сообщения;

• в сообщение должна быть добавлена Proxy-info с идентификатором локального сервера, указанным в паре атрибут-значение Proxy-Host, для обеспечения пересылки ответного сообщения через данный узел;

• AVP Destination-Realm создается на основе информации, содержащейся в атрибуте RADIUS User-Name;

• при наличии RADIUS-атрибута User-Password пароль должен быть дешифрован с использованием общего секретного слова (RADIUS secret). Дешифрованный пароль должен быть перенаправлен в паре атрибут-значение User-Password с использованием механизмов обеспечения защиты информации Diameter;

• если в запросе присутствует атрибут RADIUS С НАР-Password, для создания групповой пары атрибут-значение CHAP-Auth используется Ident и Data-части RADIUS-атрибута;

• если сообщение RADIUS содержит атрибут адреса, он должен быть преобразован в соответствующую пару атрибут-значение Diameter;

• если сообщение RADIUS содержит информацию о туннеле, атрибуты должны быть преобразованы в Diameter Tunneling Grouped набор пар атрибут-значение. Если информация о туннеле включает в себя атрибут Tunnel-Password, он должен быть дешифрован и отправлен далее с использованием методов обеспечения защиты Diameter;

• если полученное сообщение RADIUS является сообщением учета Accounting-Request, атрибут Acct-Status-Type должен быть преобра­зован в пару атрибут-значение Accounting-Record-Type. Если атрибут Acct-Status-Type содержит значение STOP, сервер должен иницииро­вать Session-Termination-Request, как только будет получено сообщение Accounting-Answer;

• если сообщение учета содержит атрибут Acct-Termination-Cause, он должен быть преобразован в пару атрибут-значение Termination-Cause;

• если сообщение RADIUS содержит атрибуты Accounting-Input-Octets, Accounting-Input-Packets, Accounting-Output-Octets или Accounting-Output-Packets, они должны быть преобразованы в соответствующие эквиваленты Diameter.

Соответствующий ответ Diameter будет гарантированно передаваться через конвертер протоколов, инициировавший запрос, благодаря содержимому AVP Proxy-Info, передаваемой в запросе. При обработке ответного сообщения выпол­няются следующие операции:

• если код команды Diameter имеет значение AA-Answer, и AVP Result-Code-значение DIAMETER_MULTI_ROUND_AUTH, конвертер протоколов должен отправить сообщение RADIUS Access-Challenge, которое содержит пары атрибут-значение Origin-Host, Origin-Realm и Diameter Session-ld, инкапсулированные в RADIUS-атрибут State с префиксом «Diameter/» в указанном порядке, разделенные символом «/» в кодировке UTF-8. Такие действия выполняются для гарантии того, что при получении последующего сообщения RADIUS Access-Request конвертер протокола получит идентификатор сессии Session Identifier и сможет присвоить Destination-Host корректное значение;

• если код команды установлен в AA-Answer, AVP Diameter Session-ld сохраняется в новом атрибуте RADIUS Class, формат которого состоит из строки «Diameter/», за которой следует идентификатор сессии Diameter. Это позволяет гарантировать, что последующие сообщения учета, которые могут быть получены на любом конвертере протоколов, будут иметь доступ к исходному идентификатору сессии Diameter;

• если в запросе RADIUS присутствовал атрибут Proxy-State, такой же атрибут должен быть добавлен в ответное сообщение. Эта информация может быть получена из AVP Proxy-Info или из локальной таблицы состояний;

• если информация о запросе RADIUS была сохранена в AVP Proxy-Info или в локальной таблице состояний, из нее извлекаются RADIUS Identifier, IP-адрес и номер порта и используются при генерации RADIUS-ответа.

При преобразовании Diameter AA-ответа с успешным статусом выполнения, включающего в себя пару атрибут-значение Session-Timeout или Authorization-Lifetime, в сообщение RADIUS Access-Accept выполняются следующие действия:

• если сообщение Diameter содержит AVP Session-Timeout, но не содержит AVP Authorization-Lifetime, необходимо преобразовать эту AVP в атрибут Session-Timeout;

• если сообщение Diameter содержит AVP Authorization-Lifetime, но не содержит AVP Session-Timeout, необходимо преобразовать AVP в атрибут Session-Timeout и присвоить Termination-Action значение AA-REQUEST;

• если сообщение Diameter содержит обе AVP, Session-Timeout должна быть больше или равна Authorization-Lifetime (согласно требованию базового протокола Diameter). Меньшее из значений - AVP Authorization-Lifetime - должно быть преобразовано в Session-Timeout, Termination-Action должна получить значение AA-REQUEST.

4. Реализация, расчет и тестирование протоколов ААА

1. Вопросы совместимости оборудования ААА

Рассмотренный протокол RADIUS практически повсеместно реализован в современном оборудовании сетевого доступа. Задачи аутентификации, авторизации и учета в сетях Операторов в подавляющем большинстве случаев реализуются путем обмена RADIUS-сообщениями с сервером ААА домашней сети пользователя. Обмен сообщениями RADIUS используется также для авторизации доступа к ресурсам сетей гостевых пользователей, то есть протокол RADIUS, фактически, является стандартом взаимодействия роуминговых партнеров - Операторов WLAN сетей.

Некоторые трудности при взаимодействии RADIUS-совместимого оборудования разных производителей могут возникать при обработке Vendor-Specific атрибутов, которые вводятся производителями для реализации тех или иных функциональных возможностей, отсутствующих в стандартном протоколе, однако проблема совместимости решается либо путем использования промежуточных устройств-конвертеров, либо доработкой протокола одним из производителей для поддержки атрибутов другого. В остальном же различные реализации протоколов достаточно хорошо взаимодействуют в силу того, что для реализации основных функций доступа к сетевым ресурсам и базового учета требуется всего несколько стандартных сообщений с простым синтаксисом, передающихся поверх простого транспорта UDR

Рассмотренный протокол Diameter, в свою очередь, также успел получить достаточную популярность, однако он появляется в сети Оператора связи чаще всего в виде протокола кредитного контроля в процессе обновления биллинговой системы для обеспечения функций учета по предоплатным тарифным планам. Этот протокол в последние годы приходит на смену частным протоколам, которые разрабатывались производителями под «свои» биллинговые системы для выполнения тех же функций тарификации абонентов по принципу предоплаты. Таким образом, сегодня сложилась ситуация, когда практически все оборудование доступа выполняет функции ААА в общем (и учета - в частности) с помощью протокола RADIUS, в то время как все большее число биллинговых систем взаимодействует с оборудованием по протоколу Diameter.

В условиях сосуществования в единой сети двух AAA-протоколов актуальной является задача реализации двух стеков протоколов RADIUS и Diameter в одном функциональном устройстве, выполняющем преобразование протоколов для обеспечения взаимодействия оборудования доступа к сети и систем тарификации в режиме реального времени как части биллинговой системы Оператора.

2. Пример реализации ААА в сети NGN/IMS

Использование архитектуры и технологий ААА в сетях следующего поколения, например, на базе платформы Протей, позволило значительно расширить возможности предоставления современных сервисов абонентам и учета деятельности пользователей в сети. Можно выделить основные линейки оборудования:

• mAccess - продукт, предназначенный для обеспечения мультисервисно- го абонентского доступа;

• imSwitch5 - программные коммутаторы Softswitch класса 5;

• mGate - семейство медиашлюзов/конвертеров операторского класса.

В представленной сети программный коммутатор imSwitch5 с точки зрения процедур ААА выполняет три основные задачи:

• аутентифицирует абонента при регистрации в сети;

• выполняет процедуру авторизации в момент запроса абонентом услуги: проверяет возможность получения запрашиваемой услуги и параметры ее предоставления в соответствии с соглашением SLA;

• для предоплатного (pre-paid) абонента выполняет резервирование ре­сурсов в биллинговой системе в соответствии политикой кредитного контроля Оператора. В случае абонента, получающего услуги на основе постоплаты (post-paid), imSwitch5 выполняет процедуры учета.

Решение описанных задач в NGN/IMS-окружении требует поддержки интерфейсов Diameter к системе тарификации абонентов (как в режиме реального времени, так и в автономном режиме), к системе хранения профилей абонентов и параметров аутентификации. В целях совместимости с RADIUS- оборудованием imSwitch5 поддерживает также протокол RADIUS с его расширениями для выполнения кредитного контроля и возможности принудительного прекращения сессии сервером ААА.

В наши дни в условиях, когда стеки протоколов разных производителей могут существенно различаться и содержать проприетарные разработки, одним из решающих критериев возможности и скорости интеграции является наличие собственных стеков протоколов RADIUS и Diameter. Именно наличие собственных стеков протоколов ААА позволяет выполнять стыковку оборудования «НТЦ Протей» с сетевыми элементами практически любых вендоров, представленных сегодня на телекоммуникационном рынке.

3. Протоколы ААА в интеллектуальной платформе Протей

Предоставление интеллектуальных услуг корпоративным клиентам и «физическим» абонентам сети подразумевает необходимость контроля и учета потребления такого рода услуг в реальном времени. Например, одна из наиболее востребованных сегодня интеллектуальных услуг - «Виртуальный офис», в которой клиентам предоставляются возможности организации речевого меню на едином номере компании, переадресация входящих вызовов на мобильные номера сотрудников компании в зависимости от времени суток, дня недели, номера вызывающего абонента и других параметров, организация речевой почты, услуги fax-to-email и проч. Каждый клиент услуги получает счет в биллинговой системе Оператора, откуда в реальном времени списываются средства за пользование услугой.

Режим «в реальном времени» интеллектуальной платформы связан с тем, что большинство Операторов предоставляют услуги на основе предоплаты, минимизируя риск возникающий при кредитовании клиентов. Поэтому одним из главных требований к современной интеллектуальной платформе является поддержка AAA-протоколов RADIUS и Diameter, а также возможность их оперативной доработки в соответствии с требованиями производителя биллинговой системы.

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

Рис. 4.1 Взаимодействие интеллектуальной платформы Протей с биллинговой системой Оператора

4. Реализация функций ААА в конвергентной WLAN/UMTS-сети

В качестве еще одного примера взаимодействия протоколов RADIUS и Diameter рассмотрим конвергентные сети типа WLAN/UMTS (Wireless Local Area Network/Universal Mobile Telecommunications System), получающие сегодня все более широкое распространение. На рис. 4.2 представлена архитектура такой сети, образованной слиянием двух доменов - домена WLAN и домена UMTS, использующих единую биллинговую систему. Система учета WLAN-домена построена на основе протокола кредитного контроля Diameter, работающего по принципу резервирования ресурсов, система учета домена UMTS использует тот же принцип, реализуемый, однако, протоколом САР по технологии CAMEL.

Рис. 4.2. Архитектура конвергентной WLAN/UMTS-сети

Устройством, выполняющим в такой сети взаимодействие с оборудованием доступа по протоколу RADIUS, а с системой тарификации - в режиме реального времени - по протоколу Diameter, будет 3GPP ААА-сервер, определяемый спецификацией. На рис. 4.3 представлен программно-аппаратный комплекс WiX разработки НТЦ Протей, позволяющий провести интеграцию доменов UMTS и WLAN с учетом особенностей сети Оператора и с той степенью конвергенции, которую Оператор желает получить на текущем этапе развития сети.

Рис. 4.3 Ядро конвергентной сети типа WLAN/UMTS на базе оборудования Протей

Начальный уровень конвергенции не подразумевает интеграции оборудования доступа домена WLAN и биллинговой системы сети UMTS. Вместо этого в сеть Оператора внедряется база данных абонентов домена WLAN, в которой содержатся параметры услуг абонента, а также отдельный счет для оплаты эти услуг. Пополнение счета выполняется по каналам SMS или IVR, для чего комплекс WiX оснащен интерфейсами к SMSC и MSC Оператора. Наличие у комплекса WiX интерфейсов к платежным системам, системам оплаты банковскими картами и/или системам скрэтч-карт дает возможность пополнять счет практически всеми известными способами.

Более глубокая степень конвергенции достигается путем переноса профилей абонентов из отдельной базы данных пользователей WLAN в общую базу данных абонентов Оператора, такую как GUP-сервер. При этом WLAN-счета абонентов по- прежнему остаются в отдельной базе данных, то есть объединения на уровне функций биллинга в части тарификации в режиме реального времени не происходит.

Описанные способы интеграции подразумевают взаимодействие с биллинговой системой домена UMTS только в режиме offline, то есть посредством обмена записями тарификационной информации (charging data records, CDR). Дальнейшее увеличение степени конвергенции WLAN/UMTS-сети будет заключаться в использовании общей системы тарификации в режиме реального времени без выделения счетов абонентов WLAN в отдельную базу.

С точки зрения абонентов сети такой сценарий наиболее удобен, так как списание средств за пользование услугами сети WLAN будет выполняться с основного счета абонента без каких-либо дополнительных действий с его стороны (звонок или SMS на короткий номер или оплата скретч-картой и т.п.). То есть с точки зрения биллинга домен WLAN будет неотличим для абонента от домена UMTS, что, по сути, является высшей степенью объединения сетей. Именно на этом уровне конвергенции появляется задача интеграции оборудования доступа сети WLAN и системы тарификации в режиме реального времени сети UMTS, которая в большинстве случаев подразумевает конвертацию протоколов ААА, осуществляющих в этих доменах функции учета.

Ниже рассматривается сценарий обмена сигнальными сообщениями в такой сети при обслуживании абонента предоплатного тарифного плана, одновременно потребляющего несколько услуг в домене WLAN.

Этот сценарий показан на рис. 4.4 в виде диаграммы обмена сообщениями между оборудованием доступа, 3GPP AAA-сервером и системой тарификации в реальном времени при предоставлении услуг абоненту домашней сети.

Рис. 4.4 Схема обмена сообщениями при тарификации предоплатных абонентов в WLAN/UMTS-сети

Представленный на рис. 4.4 сценарий содержит следующие шаги.

Шаг 1. Абонент запрашивает услугу 1 на устройстве доступа WLAN/UMTS-сети.

Шаг 2. Устройство доступа выполняет аутентификацию и авторизацию абонента путем отправки на сервер ААА запроса RADIUS Access-Request (п. 2.3). Сервер ААА выполняет проверку параметров аутентификации и авторизации в системе управления профилями абонентов. Если эта процедура проходит успешно, сервер ААА выполняет резервирование средств на счете абонента с помощью Diameter-сообщения CCR (initial), в системе тарификации в режиме реального времени и передает резервированную квоту в сообщении RADIUS Access-Accept (п. 2.3) на устройство доступа сети.

Шаг 3. Получив квоту, устройство доступа открывает абоненту доступ к услуге 1 и начинает учет ресурсов, потребленных абонентом в рамках услуги 1.

Шаг 4. Абонент запрашивает на устройстве доступа услугу 2.

Шаг 5. Так как аутентификация и авторизация этого абонента уже выполнены, устройство доступа выполняет запрос для него квоты на сервере ААА в сообщении Access-request. Устройство доступа обращается в биллинговую систему для резервирования средств на счете абонента с помощью запроса Diameter CCR (update). Если средства для резервирования доступны, квота на услугу 2 передается на устройство доступа в сообщении RADIUS Access-Accept.

Шаг 6. Устройство доступа открывает абоненту доступ к услуге 2 и начинает учет средств, потребленных абонентом в рамках этой услуги.

Шаг 7. Абонент потребляет всю квоту на услугу 1. Для продолжения пользования услугой необходимо резервировать в системе тарификации дополнительные ресурсы, для чего устройство доступа отправляет на ААА-сервер сообщение RADIUS Access-Request. Сервер ААА отправляет запрос Diameter CCR (update) в систему тарификации для резервирования средств, после чего возвращает резервированную квоту на устройство доступа в сообщении RADIUS Access-Accept. Предоставление услуги 1 продолжается.

Шаг 8. Предположим, что в результате шага 7 были резервированы все доступные на счете абонента средства. Абонент потребляет всю квоту, доступную в рамках услуги 2. Устройство доступа выполняет запрос RADIUS Access-Request на сервер ААА для резервирования дополнительной квоты на счете абонента в биллинговой системе. Сервер ААА выполняет запрос Diameter CCR (update) в систему тарификации в режиме реального времени для резервирования квоты, но на счете абонента нет доступных средств, поэтому система тарификации возвращает серверу ААА отказ. Сервер ААА передает на устройство доступа сообщение Access-Reject, в котором указывает, что абонент не имеет достаточно средств для резервирования счета.

Шаг 9. Устройство доступа останавливает предоставление услуги 2 абоненту.

Шаг 10. Абонент потребляет доступную квоту в рамках услуги 1. Устройство доступа пытается резервировать дополнительные средства для продолжения предоставления услуги, для чего отправляет запрос RADIUS Access-Request на сервер ААА. Сервер ААА обращается к системе тари­фикации в режиме реального времени запросом Diameter CCR (update) и выполняет попытку резервирования средств. Так как абонент не имеет доступных средств на счете, система тарификации возвращает отказ. Сервер ААА отправляет сообщение Access-Reject на устройство доступа, информирующее о том, что у абонента не хватает средств на счете для продолжения пользования услугой 1.

Шаг 11. Устройство доступа останавливает предоставление услуги 1 абоненту.

Следует отметить, что помимо поддержки RADIUS- и Diameter-протоколов ААА-сервер должен быть оснащен интерфейсом в сторону HLR/HSS (Ноте Location Register/Home Subscriber Server), либо какого-либо другого сетевого элемента, выполняющего функцию хранения профилей абонентов.

В профилях абонентов содержится информация о подключенных услугах и параметрах их предоставления, а также параметры, необходимые серверу ААA для проведения процедуры аутентификации.

Одним из наиболее распространенных протоколов взаимодействия сервер ААА с хранилищем такого рода является http/XML.

5. Расчет нагрузки биллинговой системы конвергентной WLAN/UMTS-сети

Присоединение WLAN-домена к UMTS-сети, изображенное на рис. 6.3, соответствующей интеграцией 3GPP AAA-сервера с биллинговой системой Оператора будет создавать дополнительную сигнальную нагрузку на систему та­рификации в режиме реального времени.

Очевидно, что эту нагрузку следует учитывать при проектировании конвергентной сети, а также при дальнейшем ее расширении, так как ее интенсивность будет возрастать пропорционально количеству абонентов, пользующихся услуга­ми WLAN-домена.

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

Наиболее востребованной на первых этапах развития конвергентных WLAN/UMTS-сетей услугой, потребляемой через WLAN-домен, будет Интернет-навигация. Объем передаваемой информации в рамках этой услуги согласно ряду исследований распределен по логнормальному закону.

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

В - сумма средств на смете абонента, расходуемых внутри WLAN-домена сети за рассматриваемый промежуток времени;

I - сумма средств, резервируемых на одно обращение к системе тарифика­ции;

, - параметрылогнормального распределения, опреде­ляющего распределение количества информации, передаваемой в одной Интернет-сессии.

Среднее количество E[N] запросов в биллинговую систему при обслуживании одного абонента определяется выражением

где

Умножив эту величину на математическое ожидание количества абонентов пользующихся в данный временной интервал услугами WLAN-домена сети, получим полное количество запросов к биллинговой системе за рассматриваемый временной интервал.

Заключение

В данной дипломной работе были рассмотрены протоколы, созданные и повсеместно используемые для обеспечения функций AAA. Благодаря своей простоте, разработанный ранее протокол RADIUS получил широкое распространение, но оказался недостаточно эффективен. Эволюция сетей связи, выражающаяся в усложнении сетевого и пользовательского оборудования, в увеличении количества услуг, в новом уровне угроз защите информации, а также в необходимости обеспечения согласованного качества обслуживания, побудила рабочую группу IETF подготовить документ, в котором были сформулированы требования к протоколам ААА нового поколения. В их числе масштабируемость, резервирование, взаимная аутентификация клиента и сервера, защита уровня передачи, конфиденциальность дата-объекта, целость дата-объекта, возможность передачи сертификатов, надежный механизм транспортировки AAA-сообщений. Протокол DIAMETR соответствует всем предъявляемым требованиям. В настоящее время в сетях сотовой связи используются оба протокола. Представлены примеры реализации функций AAA в конвергентной WLAN/UMTS-сети.

Список литературы

1. Гольдштейн Б.С. Пинчук А.В. Суховицкий A.Л. IP - телефония. 3-е изд. М.: Радио и связь, 2006.

2. Гольдштейн Б.С. Протоколы сети доступа. Том 2. 3-е изд., перераб, доп. М.: Радио и связь, 2005.

3. Гольдштейн Б.С. Сигнализация в сетях связи. Том 1. 4-е изд. , перераб, доп. М.: Радио и связь, 2005.

4. Гольдштейн Б.С., Ехриель И.М., Рерле Р.Д. Стек ОКС7: Подсистема ISUP. 2-е изд. Серия «Телекоммуникационные протоколы»//СПб.: BHV-2003.

5. Гольдштейн Б.С., Ехриель И.М., Рерле Р.Д. Стек ОКС-7. Подсистема МТР. Серия «Телекоммуникационные протоколы»//СПб.: BHV-2003.

6. Гольдштейн Б.С., Ехриель И.М., Кадыков В.Б., Рерле Р.Д. Протоколы V5.1 и V5.2. Серия «Телекоммуникационные протоколы»//СПб.: BHV-2003.

7. Гольдштейн Б.С., Сибирякова Н.Г., Соколов А.В. Сигнализация R1.5. Серия «Телекоммуникационные протоколы»//СПб.: BHV-2004.

8. Гольдштейн Б.С., Крюков Ю.С., Пинчук А.В., Хегай И. П., Шляпоберский В.Э. Интерфейсы СОРМ. Серия «Телекоммуникационные протоколы»// СПб.: BHV- 2006.

9. Aboba В., Arkko J., Harrington D., Introduction to Accounting Management, RFC 2975, October 2000.

10. Aboba В., Beadless M., The Network Access Identifier, RFC 2486, January 1999.

11. Aboba B., Blunk L, Carlson J , Levkowetz H., Ed., Vollbrecht J., Extensible Authentication Protocol (EAP), RFC 3748, June 2004.

12. Aboba B., Booth S., Dixon W., Patel B., Zorn G Securing L2TP using IPsec, RFC 3193, November 2001.

13. Aboba B., Calhoun R, RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP), RFC 3579, September 2003.

14. Aboba B., Chiba М., Dommety iff Eklund М., Mitton D., Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS), RFC 5176, January 2008.

15. Aboba В., Congdon Р., Sanchez М., RADIUS Attributes for Virtual LAN and Priority Support, RFC I 4675, September 2006.

16. Aboba B., Congdon P., Sanchez М., RADIUS Filter Rule Attribute, RFC 4849, April 2007.

17. Aboba B., Eronen P., Simon D., Extensible Authentication Protocol (EAP) Key Management Framework, RFC 5247, August 2008.

18. Aboba B. et al, Criteria for Evaluating AAA Protocols for Network Access, RFC 2989, November 2000.

19. Aboba, B., Lu, J., Alsop, J., Ding, J., Wang W., Review of Roaming Implementations, RFC 2194.September 1997.

20. Aboba B., Mitton D., Zorn G., RADIUS and IPv6, RFC 3162, August 2001.

21. Aboba, B., Vollbrecht J., Proxy Chaining and Policy Implementation in Roaming, RFC 2607, June 1999.

22. Aboba B., Wood J., Authentication, Authorization and Accounting (AAA) Transport Profile, RFS 3539, June 2003.

23. Aboba B., Zorn G., Criteria for Evaluating Roaming Protocols, RFC 2477, January 1999.

24. Allen C., Dierks Т., The TLS Protocol, RFC 2246, January 1999.

25. Arkko J., Calhoun P., Guttman E., Loughney J., Zorn G., Diameter Base Protocol, RFC 3588 September 2003.

26. Atkinson R., Kent S., Security Architecture for the Internet Protocol, RFC 2401, November

27. Barkley S., Mitton D., Nelson D., Patil B., Stevens М., St.Jones М., Wolff B., Authentication, Authorization and Accounting: Protocol Evaluation, RFC 3127, June 2001.

28. Beadles М., Mitton D., Criteria for Evaluating Network Access Server, Protocols, RFC 3169, September 2000.

29. Beck W., Sadolevsky D., Schwartz D., B. Sterman, D. Williams, RADIUS Extension tor Digest Authentication, RFC 4590, July 2006.

30. Beck W., Sadolevsky D., Schwartz D., B. Sterman, D. Williams, RADIUS Extension for Digest Authentication, RFC 5090, February 2008.

31. Belinchon М., Canales-ValenzuelaC., Garcia-Martin M , Pallares-LopezМ.,Tarrvmi K.,_; Diameter Session Initiation Protocol (SIP) Application, RFC 4740, November 2006.

32. Blount A., Brownlee N., Accounting Attributes and Record Formats, RFC 2924, September 2000.

33. de Bruijn B., Calhoun P., Farrell S., Gommans L., Gross G., Holdrege М., de Laat C., Spence D., Vollbrecht J., AAA Authorization Application Examples, RFC 2905, August 2000.

34. de Bruijn B., Calhoun P., Farrell S., Gommans L_M Gross G., Holdrege М., de Laat C., Spence D., Vollbrecht J., AAA Authorization Framework, RFC 2904, August 2000.

35. de Bruijn B., Calhoun P., Farrell S., Gommans L., Gross G., Holdrege М., de Laat C., Spence D., Vollbrecht J., AAA Authorization Requirements, RFC 2906, August 2000.

36. Bulley W., Calhoun P. Farrell S., Diameter CMS Security Application, draft-ietf-aaa-diameter- cms*sec-04, March 2002.

37. Calhoun P., Hiller Т., Johansson Т., McCann P., Perkins C., Diameter Mobile IPv4 АррНсЙйёШ RFC 4004, August 2005.

38. Calhoun P., Mitton D., Spence D., Zorn G., Diameter Network Access Server Application, RFC . 4005, August 2005.

39. Calhoun P., Loughney J., Guttman E., Zorn G., Arkko J. Diameter Base Protocol, RFC 358S, Sept. 2003.

40. Calhoun P., Rigney C., Willats W., RADIUS Extensions, RFC 2869, June 2000.

41. Chowdhury K., Leung K., Lior A., Nakhjiri М., Ed, Mobile IPv4 RADIUS Requirements, RFC 5030 October 2007.

42. Deering S.,Hinden R. Internet Protocol, Version6 (IPv6) Specification, RFC2460, Dec. 1998.

43. Downey A., Lognormal and Pareto Distributions in the Internet , Computer Communications 2005. №7. C. 790-801.

44. Eronen P., Hiller Т., Zorn G., Diameter Extensible Authentication Protocol (EAP) Application, RFS 4072, August 2005.

45. ETSI ES 201 158 Telecommunications security; Lawful Interception (LI); Requirements _; network functions.

46. ETSI ES-201 -671 Handover Interface for the Lawful Interception of Telecommunications Тraffic under Lawful Interception, Telecommunications Security, version 2.1.1, September 2001.

47. ETSI TR 101 943. Lawful Interception (LI); Concepts of Interception in a Generic Network Architecture, version V2.1.1, October 2004

48. ETSI TR-101-944 Issues on IP Interception under Lawful Interception; Telecommunications Security, version 1.1.2, December 2001.

49. ETSI TS 101 671. Telecommunications security; Lawful Interception (LI); Handover interface for the lawful interception of telecommunications traffic. Version 2.10.1, September, 2004.

50. Glass S., Hiller Т., Jacobs S., Perkins C., Mobile IP Authentication, Authorization and Accounting Requirements, RFC 2977, October 2000.

51. Gommans L., Gross G. De Laat C., Spence D., Vollbrecht J., Generic AAA Architecture, RFC 2903, August 2000.

52. Graveman R., Parthasarathy М., Savola P., Tschofenig H., Using IPsec to Secure IPv6-'in-IPv4 Tunnels, RFC 4891, May 2007.

53. Hakala H., Koskinen J-Р., Loughney J., MattilaL., SturaМ., DiameterCredit-ControlApplication, RFC 4006, August 2005.

54. IANA; «Address Family Numbers», http://wwwjana.org/assignments/address-family-numbers.

55. IANA, «RADIUS Types», http://www.iana.org/assignments/radius-types.

56. Institute Of Electrical and Electronics Engineers, «IEEE Standard for Binary Floating-Point Arithmetic», ANSI/IEEE Standard 754-1985, August 1985.

57. Johnson D., Perkins C., Arkko J. MobilitySupportinlPv6, draft-ietf-mobikip-ipv6-4.txt, June

58. Kalla М., Morneault K., Paxson V., Rytina I., Schwarzbauer H., Sharp C., Stewart R., Taylor Т., Xie Q., Zhang L., Stream Control Transmission Protocol, RFC 2960, October 2000.

59. Klemm A., Lindemann C., Lohmann M. Traffic Modeling and Characterization for UMTS Networks, Global Telecommunications Conference, 2001. 2001. №3 C. 1741 - 1746.

60. Lloyd B., Simpson W., PPP Authentication Protocols, RFC 1334, October 1992.

61. Mitton D. Network Access Servers Requirements: Extended RADIUS Practices, RFC 2882, July 2000.

62. Nelson D., Weber G., Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management, RFC 5607, July 2009.

63. PKT-SP-ESP1.5-101-050128 Electronic Surveillance. PacketCable Electronic Surveillance Specification. Cable Television Laboratories, Inc., January 28, 2005

64. PKT-SP-EM-И 2-050812 PacketCable™ Event Messages Specification, Cable Television Laboratories, Inc., August 12, 2005.

65. Rigney C., Rubens A., Simpson W., Willens S. Remote Authentication Dial In User Service (RADIUS), RFC 2058, January 1997.

66. Rigney C., RADIUS Accounting, RFC 2059, January 1997.

67. Rigney C., Rubens A., Simpson W., Remote Authentication Dial In User Service (RADIUS), RFC 2865, June 2000.

68. Rigney C., RADIUS Accounting, RFC 2866, June 2000.

69. Simpson, W., «РРР Challenge Handshake Authentication Protocol (CHAP)»,RFC 1994, August 1996.

70. Staehle D., Leibnitz K., Tran-Gia P., Source Traffic Modeling for Wireless Applications, International Journal of Electronics and Comminications. 2001. №1. C. 27 - 36.

71. Technical Specification. 3^rd Generation Partnership Progect. 3GPP TS 23.234. 3GPP system to Wireless Local Area Network (WLAN). Interworking; System Description.

72. Zorn G. | Microsoft PPP CHAP Extensions, Version 2, RFC 2759, January 2000.