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

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

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

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

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

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

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

Учет

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• опрос;

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

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

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

Опрос

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

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

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

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

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

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

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

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

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

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

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

Обобщенная архитектура ААА

Сервер аутентификации, авторизации и учета (AAA-сервер) является тем единым сетевым элементом, в котором выполняются указанные процедуры ААА.

Элементы обобщенной архитектуры ААА

На рис. 1.5 представлен центральный элемент ААА-архитектуры - обоб­щенный AAA-сервер, обрабатывающий запросы аутентификации, выполняющий авторизацию и накапливающий информацию учета. Обобщенный сервер ААА взаи­модействует со следующими элементами общей инфраструктуры ААА:

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

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

Рис. 1.5. Элементы обобщенной архитектуры ААА

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

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

Типичная последовательность обслуживания запроса авторизации в рамках обобщенной архитектуры ААА будет выглядеть следующим образом:

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

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

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

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