Способ, система и устройство для поддержки услуги hierarchical mobile ip
Изобретение относится к системам мобильной связи. Технический результат заключается в усовершенствовании поддержки услуги Hierarchical Mobile IP версии 6 (HMIPv6). Способ поддержки услуги HMIPv6 для мобильного узла содержит этап, на котором используют инфраструктуру аутентификации, авторизации и управления учетными записями (ААА), чтобы инициализировать услугу HMIPv6, при этом назначают посредством упомянутой инфраструктуры ААА надлежащую точку привязки мобильности (MAP) мобильному узлу для услуги HMIPv6; и передают по упомянутой инфраструктуре ААА относящуюся к HMIPv6 информацию для аутентификации и авторизации мобильного узла для услуги HMIPv6 в отношении назначенной MAP. 5 н. и 20 з.п. ф-лы, 11 ил., 3 табл.
Область техники, к которой относится изобретение
Настоящее изобретение, в общем, относится к мобильной связи и, в частности, предназначается для поддержки услуги протокола Mobile IP (реализация межсетевого протокола (IP) для мобильной связи), главным образом, услуги Hierarchical Mobile IP (иерархического Mobile IP) версии 6.
Предшествующий уровень техники
Mobile IP (MIP) дает возможность мобильному узлу (MN) изменять свою точку подключения к Интернету с минимальным нарушением предоставления услуг. MIP сам по себе не предоставляет никакой конкретной поддержки мобильности в различных административных доменах, что ограничивает применимость MIP при крупномасштабном коммерческом развертывании.
Протокол Mobile IP версии 6 (MIPv6) [1] дает возможность узлам перемещаться по топологии Интернета, одновременно поддерживая достижимость и выполняющиеся соединения с соответствующими узлами. В этом контексте каждый мобильный узел всегда идентифицируется своим опорным адресом вне зависимости от текущей точки подключения к Интернету IPv6. Будучи расположенным вне опорной сети, мобильный узел также ассоциирован с адресом обслуживания (CoA), который предоставляет информацию о текущем местоположении мобильных узлов. Пакеты IPv6, направляемые на опорный адрес мобильного узла, в большей или меньшей степени прозрачно направляются по адресу обслуживания. Протокол MIPv6 дает возможность узлам IPv6 кэшировать связывание опорного адреса мобильного узла к адресу обслуживания и затем отправлять любые пакеты, предназначаемые мобильному узлу, на адрес обслуживания. С этой целью мобильный узел отправляет так называемые обновления связывания своему опорному агенту (HA) и соответствующим узлам, с которыми он обменивается данными, каждый раз при перемещении. Аутентификация обновлений связывания требует некоторого количества двусторонних прохождений сигналов между мобильным узлом и каждым соответствующим узлом. Помимо этого одно двустороннее прохождение необходимо, чтобы обновить опорный агент, хотя это может быть выполнено одновременно с обновлением соответствующих узлов.
Эти задержки на двусторонние прохождения прерывают активные соединения каждый раз, когда выполняется эстафетная передача обслуживания на новый маршрутизатор доступа.
По этой и другим причинам предложен протокол Hierarchical Mobile IPv6 (HMIPv6) [2], чтобы поддерживать локальные или иерархические формы управления мобильностью. Иерархическое управление мобильностью для Mobile IPv6 уменьшает объем передачи сигналов между MN, его соответствующими узлами (CN) и его HA за счет введения так называемой точки привязки мобильности (MAP), размещенной в гостевой (посещаемой) сети. Введение MAP также может быть использовано, чтобы повышать производительность Mobile IPv6 в показателях скорости эстафетной передачи обслуживания.
Фиг. 1 схематично иллюстрирует пример домена HMIPv6 предшествующего уровня техники с MAP в гостевой сети. Общий вид системы включает в себя опорную сеть 10 с обычным опорным агентом (HA) 15, гостевую сеть 20 с MAP 25 и маршрутизаторами 27 доступа (AR). Мобильный узел (MN) 30, осуществляющий вход в домен MAP, принимает так называемые извещения маршрутизатора, содержащие информацию об одной или более локальных MAP. MN 30 может связывать свое текущее местоположение (адрес обслуживания в режиме соединения, LCoA) с адресом в подсети MAP, называемым региональным адресом обслуживания (RCoA). Выступая в качестве локального HA, MAP 25 принимает все пакеты от имени MN 30, который он обслуживает, и инкапсулирует и переадресует их непосредственно по LCoA этого MN.
MAP может помочь в предоставлении прозрачной мобильности для мобильного узла по мере того, как он перемещается от маршрутизатора 27-1 доступа 1 (AR1) к маршрутизатору 27-2 доступа 2 (AR2), обмениваясь данными с соответствующим узлом (CN) 40. После входа в гостевую сеть мобильный узел 30 обнаруживает глобальный адрес MAP 25. Этот адрес хранится в маршрутизаторах доступа и передается мобильному узлу посредством извещений маршрутизатора. Этот процесс называется обнаружением MAP и необходим, чтобы информировать мобильный узел о наличии MAP. Домен MAP обычно задается маршрутизаторами доступа, которые передают извещения со сведениями MAP подключенным мобильным узлам. Процесс обнаружения MAP продолжается по мере того, как мобильный узел перемещается из одной подсети в другую. До тех пор пока мобильный узел передвигается в рамках домена MAP, маршрутизаторы доступа сконфигурированы, чтобы передавать извещения с одним и тем же адресом или адресами MAP. Если принято изменение в передаваемом адресе MAP, мобильный узел должен выполнить распознавание перемещения и отправить необходимые обновления связывания своему опорному агенту и соответствующим узлам.
Если мобильный узел не поддерживает HMIPv6, то обнаружение MAP не выполняется и Mobile IPv6 не используется для управления мобильностью. С другой стороны, если мобильный узел поддерживает HMIPv6, он должен выбрать использование HMIPv6. В таком случае мобильный узел регистрируется в MAP 25 посредством отправки обновления связывания, содержащего его опорный адрес и адрес LCoA. Опорный адрес, используемый в обновлении связывания, - это адрес RCoA, и MAP 25 сохраняет эту информацию в своем кэше связывания, чтобы иметь возможность переадресовывать пакеты в их конечное место назначения, когда они принимаются от соответствующих узлов 40 или HA 15.
HMIPv6 сам по себе, как в случае MIP, не предоставляет никакой конкретной поддержки мобильности в различных административных доменах, что ограничивает применимость HMIPv6 при крупномасштабном коммерческом развертывании.
Обычно можно ожидать, что MN потребуется быть аутентифицированным перед санкционированием (авторизацией) использования услуг HMIPv6. Важно, чтобы отношение безопасности между мобильным узлом и MAP носило строгий характер; оно предпочтительно должно влечь за собой взаимную аутентификацию, защиту целостности и защиту от атак с повторением пакетов. С этой целью распространение относящихся к полномочиям данных, таких как ключи безопасности, между MN и MAP в настоящее время должно основываться на инфраструктурах открытого ключа (PKI) и других комплексных протоколах. Текущий проект HMIPv6 [2] также ограничивает местоположение MAP в гостевой сети.
Сущность изобретения
Настоящее изобретение преодолевает эти и другие недостатки структур предыдущего уровня техники.
Общая задача настоящего изобретения - предоставить усовершенствованную поддержку услуги HMIPv6 для мобильного узла. Решение должно предпочтительно включать в себя механизмы, которые облегчают развертывание HMIPv6.
В частности, желательно предоставить модернизированное, в то же время надежное решение по аутентификации и авторизации услуги HMIPv6, которое не должно основываться на инфраструктурах открытого ключа (PKI) и других комплексных протоколах.
Другая задача изобретения - обеспечить уменьшение общего времени на настройку HMIPv6.
Еще одна задача изобретения - предоставить способ и систему для поддержки услуги HMIPv6.
Еще одна задача изобретения - предоставить отдельные сетевые компоненты, которые поддерживают модернизированную аутентификацию и авторизацию услуги HMIPv6.
Эти и другие задачи решаются посредством изобретения, как задано в прилагаемой формуле изобретения.
Базовая идея изобретения заключается в том, что оно основывается на инфраструктуре AAA с целью инициализации услуги HMIPv6 для мобильного узла. В соответствии с предпочтительным вариантом осуществления изобретения инициализация услуги HMIPv6 задействует аутентификацию и авторизацию мобильного узла для услуги HMIPv6 на основе инфраструктуры AAA. В важном сценарии мобильный узел передвигается в гостевой сети, и инфраструктура AAA связывает гостевую сеть с опорной сетью мобильного узла. Тем не менее, изобретение также поддерживает сценарий, когда мобильный узел фактически расположен в опорной сети. В этом случае компонент инфраструктуры AAA опорной сети может предоставлять необходимую поддержку услуги HMIPv6 с помощью MAP в опорной сети.
Использование в качестве основы инфраструктуры AAA предпочтительно задействует передачу относящейся к HMIPv6 информации, необходимой для авторизации мобильного узла для услуги HMIPv6, по инфраструктуре AAA.
Инициализация HMIPv6 обычно основана на установлении ассоциации безопасности между соответствующей MAP и мобильным узлом, чтобы защищать соответствующий обмен данными, к примеру, предоставляя возможность аутентифицированного связывания MAP с HMIPv6.
В предпочтительном варианте осуществления изобретения совмещение процедур мобильности HMIPv6 в одном двустороннем прохождении сигнала с процедурой ассоциации безопасности HMIPv6 позволяет, вероятно, уменьшить общее время настройки посредством оптимизации аутентификации, авторизации и мобильности в общей процедуре.
Фаза авторизации, разумеется, включает в себя явную авторизацию, но может также включать в себя конфигурирование задействуемых узлов. Связанное с HMIPv6 конфигурирование, такое как конфигурирование мобильного узла и/или конфигурирование MAP, может, следовательно, обычно учитываться как часть общей процедуры авторизации. Это в типичном случае означает, что относящейся к HMIPv6 информацией может быть информация аутентификации, авторизации и/или конфигурирования HMIPv6.
Вместо традиционного процесса обнаружения MAP инфраструктура AAA предпочтительно используется для назначения надлежащей MAP мобильному узлу, либо в ответ на запрос на назначение MAP, инициированный мобильным узлом (инициированное мобильным узлом назначение MAP), либо в качестве инициированного сетью переназначения.
Также определено, что существуют случаи, когда выгодно иметь MAP, размещенную в опорной сети или других сетях, например, для случая, когда гостевая сеть не предоставляет поддержки MAP. MAP, расположенная в опорной сети, может быть использована, чтобы разрешать вопросы масштабируемости HA, разгрузки HA посредством уменьшения числа обновлений связывания, которые переходят к HA в ходе мобильности внутри домена MAP. Посредством выбора MAP так, чтобы она была топографически близкой к местоположению MN, могут быть реализованы быстрые эстафетные передачи обслуживания.
В случаях, когда MAP расположена в опорной сети, может быть подходящим использовать сервер AAA опорной сети (AAAh) в качестве надлежащего компонента инфраструктуры AAA для назначения MAP. С другой стороны, когда MAP расположена в гостевой сети, может быть подходящим использовать сервер AAA гостевой сети (AAAv) для назначения MAP. Фактически, местоположение MAP может быть в опорной сети, гостевой сети или других сетях. Больше нет никакой обязательной зависимости от извещений маршрутизатора, содержащих информацию о MAP в рамках заранее заданных доменов MAP.
Использование в качестве основы инфраструктуры AAA, в отличие от использования инфраструктуры PKI, предлагает различные возможности инициализации услуги HMIPv6. Например, можно предоставить расширение к общему протоколу аутентификации, переносимому по инфраструктуре AAA, и/или усовершенствовать приложение протокола архитектуры AAA.
Например, подтверждено, что достаточно выгодным будет передавать относящуюся к HMv6 информацию в рамках протокола аутентификации в процедуре сквозного обмена данными между мобильным узлом и сервером AAA опорной сети. Протоколом аутентификации может быть дополненный протокол аутентификации, основанный на существующем протоколе, или новый протокол.
Возможным протоколом аутентификации, который должен быть использован в качестве основы для инициализации HMIPv6, является расширяемый протокол аутентификации (EAP), создающий дополнения EAP, при этом предпочтительно не затрагивая более низкие уровни EAP. Это обычно означает, что относящаяся к HMIPv6 информация включается как дополнительные данные в стек протоколов EAP, например, в качестве атрибутов EAP в уровень способа EAP стека протоколов EAP или передается в общий контейнер на уровне EAP или уровне способа EAP.
Другой способ, который должен быть использован как дополняющий или альтернативный дополнениям EAP, может заключаться в том, чтобы усовершенствовать более низкие уровни EAP, например, созданием нового или расширенного приложения протокола структуры AAA, такого как приложение Diameter, адаптированное для HMIPv6, или приложение, основанное на протоколе Radius.
Когда MAP расположена в опорной сети, можно, например, использовать дополненный протокол аутентификации, переносимый по инфраструктуре AAA, или усовершенствованное приложение протокола архитектуры AAA. Тем не менее, когда MAP расположена в гостевой сети, дополненный протокол EAP предпочтительно используется в сочетании с усовершенствованным приложением протокола архитектуры AАA, либо усовершенствованное приложение протокола архитектуры структуры AAA используется без какой-либо поддержки дополнений EAP.
Например, дополненный протокол EAP может переноситься посредством PANA (протокола для переноса аутентификации при доступе к сети), PPP (протокола двухточечного соединения), IEEE 802.1X или даже по интерфейсам GPRS/UMTS между мобильным узлом и клиентом AAA в гостевой сети, а также посредством приложения Diameter или Radius в рамках инфраструктуры AAA.
В частности, использование в качестве основы дополнений EAP предоставляет модернизированное решение, которое управляемо и современно, с минимумом проблем обратной совместимости. Использование EAP дает возможность клиенту AAA (и AAAv) быть осведомленным о процедурах HMIPv6 (т.е. это снимает зависимость от поддержки HMIPv6 в гостевой сети) и выступать в качестве простого опосредованного агента(ов), по меньшей мере, когда MAP расположена в опорной сети. Это одно из основных преимуществ использования EAP.
Посредством также включения относящейся к MIPv6 информации в стек дополненных протоколов аутентификации либо в усовершенствованное приложение протокола инфраструктуры AAA можно одновременно предоставлять аутентификацию и авторизацию HMIPv6 и MIPv6 в одном двустороннем прохождении сигнала по инфраструктуре AAA. Разумеется, можно использовать эту сеть с поддержкой MIPv6/HMIPv6 и исполнять только аутентификацию и/или авторизацию HMIPv6 без участия MIPv6 и наоборот, в зависимости от конкретной потребности MN в конкретном случае. Это дает возможность гибкого использования одного дополненного протокола аутентификации и/или усовершенствованного приложения протокола архитектуры AAA в различных вариантах использования.
Изобретение предлагает следующие преимущества:
- эффективная инициализация услуги HMIPv6;
- эффективная передача относящейся к HMIPv6 информации для авторизации услуги HMIPv6;
- модернизированное решение по поддержке HMIPv6 на основе расширения EAP, которое управляемо и современно, с минимумом проблем обратной совместимости;
- уменьшение общего времени на настройку HMIPv6;
- оптимизация аутентификации, авторизации и мобильности в общей процедуре;
- основанное на AAA назначение MAP;
- размещение MAP не ограничено гостевой сетью;
- MAP может быть расположена в опорной сети, чтобы разрешать вопросы масштабируемости HA, разгружать HA посредством уменьшения числа обновлений связывания, которые переходят к HA в ходе мобильности внутри домена MAP;
- одновременное предоставление аутентификации и авторизации HMIPv6 и MIPv6 в одном двустороннем прохождении сигнала.
Другие преимущества, предлагаемые настоящим изобретением, будут приняты во внимание при прочтении нижеприведенного описания вариантов осуществления изобретения.
Перечень фигур чертежей
Изобретение вместе со своими дополнительными задачами и преимуществами лучше всего понимаемо посредством обращения к последующему описанию, рассматриваемому вместе с прилагаемыми чертежами, на которых:
Фиг.1 - схема, иллюстрирующая пример домена HMIPv6 предшествующего уровня техники с MAP в гостевой сети;
Фиг.2 - схема, иллюстрирующая новую архитектуру поддержки HMIPv6 для мобильного узла, передвигающегося в гостевой сети, согласно примерному варианту осуществления изобретения;
Фиг.3 - схема, иллюстрирующая новую архитектуру поддержки HMIPv6 для мобильного узла, передвигающегося в гостевой сети, согласно другому примерному варианту осуществления изобретения;
Фиг.4 - схема, иллюстрирующая новую архитектуру поддержки HMIPv6 для мобильного узла, работающего в собственной опорной сети, согласно примерному варианту осуществления изобретения;
Фиг.5 - блок-схема опорной сети AAA согласно предпочтительному примерному варианту осуществления изобретения;
Фиг.6 - блок-схема узла MAP согласно предпочтительному примерному варианту осуществления изобретения;
Фиг.7 - иллюстрация примерной последовательности обмена сигналами для AAA HMIPv6, использующей Diameter/EAP/HMIPv6, для случая, когда MAP расположена в опорной сети;
Фиг.8 - иллюстрация примерной последовательности обмена сигналами для AAA HMIPv6, использующей Diameter/EAP/HMIPv6, в сочетании с приложением Diameter HMIPv6, для случая, когда MAP расположена в гостевой сети;
Фиг.9 - иллюстрация примерной последовательности обмена сигналами для AAA HMIPv6, использующей приложение Diameter HMIPv6, для случая, когда MAP расположена в опорной сети;
Фиг.10 - иллюстрация примерной последовательности обмена сигналами для AAA HMIPv6, использующей приложение Diameter HMIPv6, для случая, когда MAP расположена в гостевой сети;
Фиг.11 - блок-схема последовательности операций иллюстративного примера способа поддержки услуги HMIPv6 для мобильного узла.
Подробное описание вариантов осуществления изобретения
На чертежах одинаковые символы ссылок используются для соответствующих или аналогичных элементов.
Основная идея согласно изобретению заключается в инициировании услуги HMIPv6 для мобильного узла на основе инфраструктуры AAA вместо использования в качестве основы сложной инфраструктуры PKI для цели аутентификации и авторизации HMIPv6. Инициирование HMIPv6 допустимо как для мобильного узла, работающего в опорной сети, так и мобильного узла, передвигающегося в гостевой сети, используя инфраструктуру AAA опорной сети в первом случае и общую инфраструктуру AAA, связывающую гостевую сеть с опорной сетью, во втором случае.
Вместо установления ассоциации безопасности и распространения ключей безопасности между MN и MAP посредством использования инфраструктуры открытых ключей (PKI) аутентификация и авторизация услуги HMIPv6 предпочтительно исполняются на основе инфраструктуры AAA, например, посредством передачи относящейся к HMIPv6 информации, необходимой для аутентификации и авторизации мобильного узла для услуги HMIPv6, по инфраструктуре AAA.
Вместо традиционного процесса обнаружения MAP инфраструктура AAA предпочтительно также используется для назначения надлежащей MAP мобильному узлу, либо в ответ на запрос на назначение MAP, инициированный мобильным узлом (инициированное мобильным узлом назначение MAP), либо в качестве инициированного сетью переназначения, как подробнее описано далее. Больше нет никакой обязательной зависимости от извещений маршрутизатора, содержащих информацию о MAP в рамках заранее заданных доменов MAP.
Инициализация AAA HMIPv6 обычно основана на установлении ассоциации безопасности, т.е. отношения безопасности между соответствующей MAP и мобильным узлом по инфраструктуре AAA, чтобы защищать соответствующий обмен данными, к примеру, предоставляя возможность аутентифицированного связывания MAP с HMIPv6.
В предпочтительной реализации процедуры мобильности HMIPv6, в том числе обновления связывания, совмещены в том же полном обходе, что и процедура ассоциации безопасности HMIPv6, тем самым допуская возможное уменьшение общего времени на настройку посредством оптимизации аутентификации, авторизации и мобильности в общей процедуре.
Термин "AAA" должен рассматриваться в рамках его общего смысла в проектах Интернет-документов, RFC и других определяющих стандарты документах. В типичном случае соглашение по аутентификации и ключам безопасности инфраструктуры AAA (авторизация, аутентификация, управление учетными записями) основано на симметричном шифровании, подразумевающем наличие первоначального секрета, совместно используемого мобильным узлом и оператором опорной сети или доверенной стороной. В некоторых сценариях или приложениях, например, функциональная возможность управления учетными записями инфраструктуры AAA может быть отключена или не реализована. Инфраструктура AAA, в общем, включает в себя один или более серверов AAA в опорной сети, промежуточные сети (если имеются) и/или гостевую сеть, а также может включать в себя один или более клиентов AAA.
В общем, протоколы AAA, такие как протокол Diameter, точно позволяют мобильным пользователям передвигаться и получать услугу в сетях, которые не обязательно принадлежат их собственному поставщику услуг. Поэтому, для того чтобы Mobile IP был развернут в коммерческих сетях, должна быть поддержка AAA для протокола. Для специального случая Mobile IPv6 (MIPv6) без какого-либо иерархического управления мобильностью предложен проект Интернет-документа [3], который задает новое приложение для Diameter, которое дает возможность роуминга MIPv6 в сетях, отличных от сети, администрируемой собственным оператором. В нашей Предварительной патентной заявке США номер 60/479156, поданной 18 июня 2003 года, а также в более новом проекте Интернет-документа [4], предложены архитектура и соответствующие протоколы для выполнения авторизации и конфигурирования Mobile IPv6 на основе инфраструктуры AAA. Необходимое взаимодействие между сервером AAA собственного поставщика услуг и мобильным узлом для MIPv6 реализовано с помощью EAP (расширяемого протокола аутентификации), который передает информацию для согласования Mobile IPv6 вместе с данными аутентификации.
Фиг. 2 - схема, иллюстрирующая новую архитектуру поддержки HMIPv6 согласно примерному варианту осуществления изобретения. Мобильный узел 130 передвигается в гостевой сети, и аутентификация и авторизация HMIPv6 выполняются посредством использования инфраструктуры AAA, связывающей гостевую сеть и опорную сеть мобильного узла. В данном примере инфраструктура AAA, по существу, задействует сервер 110 AAA опорной сети, сервер 120 ААА гостевой сети и клиент 122 AAA в гостевой сети.
Предпочтительно, сервер 120 AAA гостевой сети (AAAv) может быть использован как подходящий компонент инфраструктуры AAA для назначения MAP, принимая во внимание политику гостевого оператора при выборе MAP. Выбор MAP может быть, например, основан на текущей загрузке доступных MAP, местоположении мобильного узла и/или, возможно, предпочтениях, заданных мобильным узлом.
Основным компонентом инфраструктуры AAA является сервер 110 AAAh, который предпочтительно переадресует любой запрос на назначение MAP от мобильного узла серверу 120 AAAv и, кроме того, генерирует ключ безопасности или аналогичные реквизиты безопасности для немедленной или будущей ассоциации безопасности между заданным мобильным узлом 130 и назначенной MAP 125. После этого ключ безопасности в типичном случае передается из AAAh 110 в MAP 125 посредством AAAv 120, а MAP 125 предпочтительно отвечает информацией для завершения ассоциации безопасности с AAAh 110 посредством AAAv 120. В завершение сервер 110 AAAh отправляет сгенерированную и собранную информацию по авторизации HMIPv6 мобильному узлу 130 по инфраструктуре AAA. Предполагается, что защищенные туннели инфраструктуры AAA или другие меры безопасности, такие как шифрование и защита целостности источника, используются для передачи конфиденциальной информации, такой как ключи безопасности.
Использование в качестве основы инфраструктуры AAA предлагает различные возможности для инициализации услуги HMIPv6. Например, можно предоставить новый протокол аутентификации или предоставить дополнение к протоколу аутентификации, переносимому по инфраструктуре AAA, и/или усовершенствовать приложение протокола структуры AAA, чтобы переносить относящуюся к HMIPv6 информацию, как схематично показано на фиг. 2.
Предпочтительно, используется дополненный протокол аутентификации, такой как дополненный протокол EAP (расширяемый протокол аутентификации), адаптированный для HMIPv6, с добавлением усовершенствованного приложения протокола инфраструктуры AAA, такого как приложение HMIPv6 Diameter или Radius, для интерфейса между сервером AAAh и MAP гостевой сети посредством сервера AAAv.
Например, новый или дополненный протокол аутентификации может переноситься посредством PANA (протокола для переноса аутентификации при доступе к сети), PPP (протокола двухточечного соединения), IEEE 802.1X или даже по интерфейсам GPRS/UMTS между мобильным узлом и клиентом AAA в гостевой сети, а также посредством Diameter или аналогичного протокола структуры или поставщика услуг связи AAA в рамках инфраструктуры AAA.
Альтернативно, усовершенствованное приложение протокола структуры AAA, например новое или дополненное приложение Diameter или Radius, используется без поддержки каких-либо дополнений EAP. Для пути между мобильным узлом и клиентом AAA приложение Diameter или Radius может, например, переноситься посредством ICMP (протокола управляющих сообщений в Интернете).
Также определено, что существуют случаи, когда выгодно иметь MAP, размещенную в опорной сети или других сетях, например, для случая, когда гостевая сеть не предоставляет поддержки MAP. Примерная архитектура поддержки HMIPv6 в MAP, расположенной в опорной сети, проиллюстрирована на фиг. 3.
В данном случае для назначения MAP выгодно использовать сервер 110 ААА опорной сети (AAAh). Предпочтительно, сервер 110 AAA опорной сети (AAAh) также генерирует ключ безопасности или аналогичные параметры или полномочия для ассоциации безопасности между мобильным узлом и назначенной MAP 125 и отправляет упомянутый ключ безопасности в MAP 125. MAP 125 отвечает информацией для завершения ассоциации безопасности с AAAh 110, и AAAh 110 далее отправляет информацию авторизации HMIPv6 мобильному узлу 130 по инфраструктуре AAA.
Поскольку MAP 125 расположена в опорной сети, AAAv 120 не должен видеть транзакцию, и, таким образом, можно иметь "процедуру сквозного обмена данными" для аутентификации и авторизации HMIPv6. Это предпочтительно осуществляется посредством использования дополненного протокола аутентификации, такого как дополненный протокол EAP (расширяемый протокол аутентификации), адаптированного для HMIPv6. Альтернативно, может быть использовано усовершенствованное приложение протокола структуры AAA, например приложение HMIPv6 Diameter или Radius. MAP 125, расположенная в опорной сети, также может быть использована, чтобы разрешать вопросы масштабируемости HA, разгрузки HA 115 посредством уменьшения числа обновлений связывания, которые переходят к HA 115 в ходе мобильности внутри домена MAP. Посредством выбора MAP таким образом, чтобы она была топографически близкой к местоположению MN, могут быть реализованы быстрые эстафетные передачи обслуживания.
Следует понимать, что изобретение устранило ограничение предшествующего уровня техники, заключающееся в том, что MAP 125 должна быть расположена в гостевой сети. Теперь местоположение MAP может быть в опорной сети, гостевой сети или других сетях. Технически возможно связывать MN с любой MAP, покуда может быть получен RCoA в MAP с поддержкой AAA, если операторы разрешают это.
Переназначение MAP может произойти в ходе следующих примерных случаев.
- Истечение срока действия ключей безопасности между MN и MAP. В этом случае MN инициирует повторную аутентификацию/авторизацию HMIPv6, и сеть может назначить другую MAP, которая более подходит, на основе, к примеру, текущего топографического местоположения MN.
- При запросе мобильного узла (инициированном MN). В этом случае MN инициирует повторную аутентификацию/авторизацию HMIPv6, запрашивая переназначение MAP.
- При запросе сети (инициированном сетью). В этом случае либо AAAh, либо AAAv инициирует переназначение MAP и "проталкивает" ее MN, когда возникает необходимость, к примеру, когда MN перемещается к AR, который лучше покрывается новой MAP.
Ссылаясь на фиг. 2 и 3 снова, число возможных примеров различных комбинаций протоколов между сегментами "Клиент AAA-AAAh" и "AAAh-(AAAv)-MAP" обобщено ниже:
| Клиент AAA<->AAAh | AAAh<->(AAAv)<->MAP | |
| (i) | Приложение AAA HMIPv6 | Приложение AAA HMIPv6 |
| (ii) | Дополненный протокол аутентификации | Приложение AAA HMIPv6 |
| (iii) | Дополненный протокол аутентификации | Дополненный протокол аутентификации |
Сочетание (iii) главным образом применимо для случая, когда MAP расположена в опорной сети. Когда MAP расположена в гостевой сети, AAAv может быть задействован при выборе MAP на основе политики гостевой сети.
В другом сценарии, проиллюстрированном схематически на фиг.4, мобильный узел 130 фактически расположен в опорной сети, а компонент инфраструктуры AAA, такой как сервер 110 AAAh, предоставляет необходимую поддержку услуги HMIPv6 с помощью MAP 125 в опорной сети. Это означает, что только значимые части дополненного протокола аутентификации HMIPv6 и приложения AAA HMIPv6 должны быть использованы для обмена необходимой информацией аутентификации и авторизации.
Фиг.5 - блок-схема AAA сервера опорной сети согласно предпочтительному примерному варианту осуществления изобретения. В этом примере сервер 110 AAAh, по существу, содержит необязательный модуль 111 назначения MAP, модуль 112 ассоциации безопасности, средство 113 управления информацией авторизации и интерфейс 114 ввода-вывода. Для MAP в случае опорной сети сервер 110 AAAh включает в себя модуль 111 назначения MAP, которой выполнен с возможностью назначения и переназначения подходящей MAP мобильному узлу. Для MAP в случае гостевой сети сервер 110 AAAh в типичном случае принимает необходимую информацию по назначениям MAP посредством своего интерфейса 114 ввода-вывода. Сервер AAAh в типичном случае также принимает стартовое число ключа и обновление связывания (BU) от мобильного узла. Альтернативно, сервер AAAh сам генерирует стартовое число ключа и отправляет его мобильному узлу. Модуль 112 ассоциации безопасности предпочтительно генерирует требуемый ключ безопасности в ответ на стартовое число и защищенным образом передает этот ключ в MAP (непосредственно в MAP в опорной сети или посредством сервера AAAv в MAP в гостевой сети). Обновление связывания (BU) также переадресуется в MAP. Сервер 110 AAAh принимает адрес RCoA от MAP и сохраняет эти данные вместе с другой соответствующей информацией авторизации (и/или конфигурирования) в средстве 113 управления информацией авторизации. Сервер AAAh может также принимать информацию, например информацию IPSec от MAP, для завершения ассоциации безопасности. В завершение собранная информация авторизации (и/или конфигурирования) передается мобильному узлу.
Сервер AAAh также может отвечать за назначение опорного адреса (если только опорный адрес не сконфигурирован самим MN) и/или назначения опорного агента.
Фиг.6 - блок-схема узла MAP согласно предпочтительному примерному варианту осуществления изобретения. В этом примере MAP 125, по существу, содержит модуль 126 назначения RCoA, модуль 127 ассоциации безопасности и интерфейс 128 ввода-вывода. MAP предпочтительно взаимодействует с сервером AAA опорной сети для поддержки установления ассоциации безопасности с мобильным узлом. MAP принимает ключ безопасности от сервера AAA опорной сети по интерфейсу 128 ввода-вывода для защищенного хранения в модуле 127 ассоциации безопасности. MAP также подготавливает и отправляет информацию, необходимую для завершения ассоциации безопасности с мобильным узлом, обратно серверу AAA опорной сети, который, в свою очередь, переадресует информацию мобильному узлу по инфраструктуре AAA. Для связывания в MAP модуль 126 RCoA предпочтительно назначает адрес RCoA мобильному узлу, сохраняет этот адрес вместе с адресом LCoA мобильного узла в кэше связывания (не показан) MAP, а также отправляет назначенный адрес RCoA серверу AAA опорной сети для последующей переадресации мобильному узлу.
Для лучшего понимания изобретения далее описаны более подробные примеры дополненного протокола аутентификации для HMIPv6 и приложения протокола инфраструктуры AAA, адаптированного для HMIPv6.
Дополненный протокол аутентификации для HMIPv6
В предпочтительном примерном варианте осуществления задается дополненный протокол аутентификации для HMIPv6, проиллюстрированный в данном документе посредством нового или дополненного протокола аутентификации EAP (упоминаемого как "способ аутентификации HMIPv6" или "EAP/HMIPv6"), который переносит относящуюся к HMIPv6 информацию, облегчающую, например, обнаружение MAP, динамическое назначение MAP, динамическое назначение RCoA, распространение ключей безопасности между MN и MAP и/или возможное совмещение процедур мобильности HMIPv6.
Если требуется, аутентификация и/или авторизация HMIPv6 и MIPv6 может быть интегрирована в один протокол, к примеру, задающий EAP/HMIPv6 как расширенный набор протокола EAP/MIPv6, который в дополнение к конкретным для MIPv6 значениям длины/типа (TLV) также задает новые конкретные для HMIP TLV-атрибуты. Посредством включения TLV-атрибутов EAP/MIPv6 в качестве части EAP/HMIPv6 можно обеспечивать одновременные исполнения аутентификации и/или авторизации MIPv6 и HMIPv6 за один проход, что дает возможность сокращения времени настройки. Также можно исполнять только аутентификацию и/или авторизацию HMIPv6 без участия MIPv6 и наоборот, в зависимости от конкретной потребности MN в конкретном случае. Это дает возможность гибкого использования одного протокола аутентификации EAP, EAP/HMIPv6 в различных вариантах использования.
В частности, использование в качестве основы дополнений EAP предоставляет модернизированное решение, которое управляемо и современно, с минимумом проблем обратной совместимости. Использование EAP дает возможность клиенту AAA (и AAAv) быть осведомленным о процедурах HMIPv6 (т.е. это снимает зависимость от поддержки HMIPv6 в гостевой сети) и выступать в качестве простого опосредованного агента(ов), по меньшей мере, когда MAP расположена в опорной сети. Это одно из основных преимуществ использования EAP.
Как указывалось выше, EAP/HMIPv6 может, например, переноситься посредством PANA, PPP, ICMP, IEEE 802.1X или даже по интерфейсам GPRS/UMTS между мобильным узлом и клиентом AAA в гостевой сети. Хотя PANA может быть предпочтительным в некоторых случаях, другие протоколы поставщиков услуг связи, которые удовлетворяют требованиям EAP по гарантиям упорядочивания нижних уровней (например, PPP [6] и IEEE 802.1X [7]), могут быть использованы, чтобы переносить EAP/MIPv6 между MN и клиентом AAA. Конкретно для случая CDMA2000 3GPP2 можно переносить EAP/HMIPv6 между MN и клиентом AAA с помощью инкапсуляции протокола канального уровня PPP со значением поля протокола, равным C227 (шестнадцатеричная форма) для EAP [6].
Предпочтительный вариант осуществления использует Diameter, Radius или аналогичный протокол поставщика услуг связи или структуры AAA для обмена данными между клиентом AAA и сервером AAAh. Например, помимо клиента AAA в инфраструктуре AAA может быть использовано приложение Diameter EAP [5] для инкапсуляции EAP/HMIPv6 в Diameter, т.е. между клиентом PAA/AAA и AAAh. Протокол Diameter может быть использован AAAh для необязательного назначения фильтров пакетов MIP посредством правил фильтрации MIP для PAA/EP и HA, которые соответствуют точкам активации фильтров. Протокол Diameter также может быть использован AAAh для распространения ключей безопасности PAA для безопасности PANA и дополнительной сигнализации параметров QoS (качества обслуживания).
Следует заметить, что даже несмотря на то, что Diameter является предпочтительным выбором, в некоторых случаях может быть подходящим вместо него использовать другой протокол AAA, такой как Radius, с модификациями, очевидными для специалиста в данной области техники.
Более того, совмещение процедур мобильности HMIPv6 в EAP/HMIPv6 дает возможное сокращение общего времени на настройку посредством оптимизации аутентификации, авторизации и мобильности в общей процедуре.
Примерные подробности протокола EAP/HMIPv6
Далее предоставляются подробные сведения о протоколе EAP/HMIPv6, чтобы показать примеры общей последовательности обмена сигналами и жизнеспособности концепции.
TLV-атрибуты EAP
В первом примере реализации набор новых TLV-атрибутов EAP задан в рамках EAP/HMIPv6. Посредством этих атрибутов протокол EAP может, в дополнение к основной информации по аутентификации IPv6, переносить относящуюся к HMIPv6 информацию и, в необязательном порядке, также относящуюся к MIPv6 информацию.
Различные протоколы аутентификации возможны для EAP/HMIPv6. В предпочтительном варианте осуществления изобретение предлагает реализацию посредством аутентификации по запросу MD5, но другие протоколы также входят в объем изобретения.
Примерная сводная матрица TLV EAP/HMIPv6 приведена ниже в табл. 1.
| Значения длины/типа EAP/HMIPv6 | Источник | Адресат | Цель | Комментарий |
| Специфические для HMIPv6 TLV: | ||||
| - Атрибут RCoA Request EAP-TLV | MN | AAAh | Запрос к RCoA | |
| - Атрибут RCoA Response EAP-TLV | AAAh | MN | Назначение RCoA | MAP в опорной сети |
| AAAh | MN | Переадресация RCoA из AAAv | MAP в гостевой сети | |
| - Атрибут RCoA EAP-TLV | AAAh | MAP | Назначение RCoA | MAP в опорной сети |
| - Атрибут MAP Address Request EAP-TLV | MN | AAAh | Запрос адреса MAP | |
| - Атрибут MAP Address Response EAP-TLV | AAAh | MN | Назначение адреса MAP | MAP в опорной сети |
| AAAh | MN | Переадресация адреса MAP из AAAv | MAP в гостевой сети | |
| - Атрибут MAP-MN Pre-shared Key Generation Nonce EAP-TLV | MN | AAAh | Стартовое число ключа MN-MAP | |
| - Атрибут MAP-MN Pre-shared Key EAP-TLV | AAAh | MAP | Назначение ключа MN-MAP | MAP в опорной сети |
| - Атрибут MAP IKE KeyID EAP-TLV | AAAh | MN | Назначение IKE KeyID | MAP в опорной сети |
| - Атрибут MAP-MN IPSec SPI EAP-TLV | MAP | MN через AAAh | Назначение SPI | MAP в опорной сети |
| AAAh | MN | Переадресация из MAP | MAP в гостевой сети | |
| - Атрибут MAP-MN IPSec Protocol EAP-TLV | MAP | MN через AAAh | Назначение протокола IPSec | MAP в опорной сети |
| AAAh | MN | Переадресация из MAP | MAP в гостевой сети | |
| - Атрибут MAP-MN IPSec Crypto EAP-TLV | MAP | MN через AAAh | Назначение шифрования IPSec | MAP в опорной сети |
| AAAh | MN | Переадресация из MAP | MAP в гостевой сети | |
| - Атрибут MAP-MN IPSec Key Lifetime EAP-TLV | MAP | MN через AAAh | Назначение срока действия ключа IPSec | MAP в опорной сети |
| AAAh | MN | Переадресация из MAP | MAP в гостевой сети | |
| - Атрибут HMIP-Binding-Update EAP-TLV | MN | MAP через AAAh | Совмещение обновления связывания HMIP | MAP в опорной сети |
| MN | AAAh | Совмещение обновления связывания HMIP | MAP в гостевой сети | |
| - Атрибут HMIP-Binding-Acknowledgement EAP-TLV | MAP | MN через AAAh | Совмещение подтверждения связывания HMIP | MAP в опорной сети |
| AAAh | MN | Переадресация из MAP | MAP в гостевой сети | |
| Специфические для MIPv6 TLV (необязательные): | ||||
| - Атрибут MIPv6 Home Address EAP-TLV | AAAh | HA | Назначение опорного адреса MN | |
| - Атрибут HA-MN Pre-shared Key EAP-TLV | AAAh | HA | Назначение ключа HA-MN | |
| - Атрибут HA-MN IPSec Protocol EAP-TLV | HA | MN через AAAh | Назначение протокола IPSec | |
| - Атрибут HA-MN IPSec Crypto EAP-TLV | HA | MN через AAAh | Назначение шифрования IPSec | |
| - Атрибут MIP-Binding-Update EAP-TLV | MN | HA через AAAh | Совмещение обновления связывания MIP | |
| - Атрибут MIP-Binding-Acknowledgement EAP-TLV | HA | MN через AAAh | Совмещение подтверждения связывания MIP | |
| Базовые TLV MIPv6 (необязательные): | ||||
| - Атрибут MD5 Challenge EAP-TLV | AAAh | MN | Выдача запроса | |
| - Атрибут MD5 Response EAP-TLV | MN | AAAh | Предоставление ответа на запрос | |
| - Атрибут MIPv6 Home Address Request EAP-TLV | MN | AAAh | Запрос опорного адреса MN | |
| - Атрибут MIPv6 Home Address Response EAP-TLV | AAAh | MN | Назначение опорного адреса MN | |
| - Атрибут MIPv6 Home Agent Address Request EAP-TLV | MN | AAAh | Запрос адреса HA | |
| - Атрибут MIPv6 Home Agent Address Response EAP-TLV | AAAh | MN | Назначение адреса HA | |
| - Атрибут HA-MN Pre-shared Key Generation Nonce EAP-TLV | MN | AAAh | Стартовое число ключа HA-MN | |
| - Атрибут IKE KeyID EAP-TLV | AAAh | MN | Информация для получения предварительно предоставленного в совместное пользование ключа HA-MN от AAAh | |
| - Атрибут HA-MN IPSec SPI EAP-TLV | HA | MN через AAAh | Назначение SPI | |
| - Атрибут HA-MN IPSec Key Lifetime EAP-TLV | HA | MN через AAAh | Назначение срока службы ключа IPSec | |
| - Атрибут PAC-PAA Pre-shared Key Generation Nonce EAP-TLV | MN | AAAh | Стартовое число для ключа PAC-PAA | |
| Примечание. IKE KeyID включает в себя несколько октетов, которые информируют HA/MAP о том, как извлечь (или сгенерировать) предварительно предоставленный в совместное использование HA-MN ключ/предварительно предоставленный в совместное использование MAP-MN ключ от AAAh. |
Один или более следующих примерных атрибутов EAP-TLV могут быть заданы для целей HMIPv6:
- Атрибут RCoA Request EAP-TLV
Он представляет запрос на динамически назначаемый адрес RCoA для аутентифицированного MN. Он запрашивается MN у AAAh, когда MN запрашивает аутентификацию для предоставления услуги HMIPv6.
- Атрибут RCoA Response EAP-TLV
Он представляет динамически назначаемый адрес RCoA для аутентифицированного MN. Он предоставляется MN от AAAh, когда MN, запросивший адрес, успешно аутентифицирован.
- Атрибут RCoA EAP-TLV
Он представляет динамически назначаемый адрес RCoA для аутентифицированного MN. Он предоставляется MAP от AAAh, чтобы назначить адрес RCoA в MAP, когда MN, запросивший адрес, успешно аутентифицирован.
- Атрибут MAP Address Request EAP-TLV
Он представляет запрос на адрес динамически назначенной MAP для MN, когда успешно аутентифицирован. Он запрашивается MN у AAAh, когда MN запрашивает аутентификацию для предоставления услуги HMIPv6. Поскольку протокол HMIPv6 имеет способ динамического обнаружения MAP, чтобы назначать MAP, этот атрибут является необязательным.
- Атрибут MAP Address Response EAP-TLV
Он представляет адрес динамически назначаемой MAP для аутентифицированного MN. Он предоставляется MN от AAAh, когда MN запрашивает аутентификацию для предоставления услуги HMIPv6. Поскольку протокол HMIPv6 имеет способ динамического обнаружения MAP, чтобы назначать MAP, этот атрибут является необязательным.
- Атрибут MAP-MN Pre-shared Key Generation Nonce EAP-TLV
Он представляет октетную строку, произвольно генерируемую MN в качестве стартового числа для генерирования предварительно предоставленного в совместное использование между MAP-MN ключа. MN может внутренне сгенерировать предварительно предоставленный в совместное использование MAP-MN ключ посредством использования соответствующего алгоритма хеширования в отношении комбинации этого одноразового значения и предоставленного в совместное использование MN и AAAh ключа. Этот атрибут является необязательным, когда действительный предварительно предоставленный в совместное использование MAP-MN ключ уже существует.
- Атрибут MAP-MN Pre-shared Key EAP-TLV
Он представляет динамически генерируемый предварительно предоставленный в совместное использование между MAP-MN ключ. Он предоставляется MN от AAAh, когда MN запрашивает аутентификацию для предоставления услуги HMIPv6. AAAh может внутренне сгенерировать предварительно предоставленный в совместное использование MAP-MN ключ посредством использования соответствующего алгоритма хеширования в отношении комбинации одноразового значения, представленного атрибутом MAP-MN Pre-shared Key Generation Nonce EAP-TLV, и предоставленного в совместное использование между MN и AAAh ключом. Этот атрибут является необязательным, когда действительный предварительно предоставленный в совместное использование MAP-MN ключ уже существует.
- Атрибут MAP IKE KeyID EAP-TLV
Он представляет полезную нагрузку идентификатора CID, заданную в [8]. KeyID генерируется AAAh и отправляется MN после успешной аутентификации. KeyID включает в себя несколько октетов, которые информируют MAP о том, как извлекать (или генерировать) предварительно предоставленный в совместное использование MAP-MN ключ от AAAh. Этот атрибут является необязательным и, как правило, не требуется, если MN не предоставлял одноразовое значение генерирования предварительно предоставленного в совместное использование MAP-MN ключа, т.е. действительный предварительно предоставленный в совместное использование MAP-MN ключ уже существует, к примеру, при эстафетных передачах обслуживания MIPv6. Он также не требуется для случая, когда предварительно предоставленный в совместное использование MAP-MN ключ передается AAAh в MAP.
- Атрибут MAP-MN IPSec SPI EAP-TLV
Он представляет индекс параметра безопасности для IPSec между MAP-MN. Он предпочтительно генерируется MAP и сообщается MN для случая, когда предварительно предоставленный в совместное использование MAP-MN ключ передается AAAh в MAP. Этот атрибут является необязательным и, как правило, не требуется, если MN не предоставлял одноразовое значение генерирования предварительно предоставленного в совместное использование MAP-MN ключа, т.е. действительный предварительно предоставленный в совместное использование MAP-MN ключ уже существует, к примеру, при эстафетных передачах обслуживания MIPv6.
- Атрибут MAP-MN IPSec Protocol EAP-TLV
Он представляет протокол IPSec (к примеру, ESP или AH) между MAP-MN. Он сообщается MN для случая, когда предварительно предоставленный в совместное использование MAP-MN ключ передается AAAh в MAP. Этот атрибут является необязательным и, как правило, не требуется, если MN не предоставлял одноразовое значение генерирования предварительно предоставленного в совместное использование MAP-MN ключа, т.е. действительный предварительно предоставленный в совместное использование MAP-MN ключ уже существует, к примеру, при эстафетных передачах обслуживания MIPv6.
- Атрибут MAP-MN IPSec Crypto EAP-TLV
Он представляет криптографический алгоритм для IPSec между MAP-MN. Он сообщается MN для случая, когда предварительно предоставленный в совместное использование MAP-MN ключ передается AAAh в MAP. Этот атрибут является необязательным и, как правило, не требуется, если MN не предоставлял одноразовое значение генерирования предварительно предоставленного в совместное использование MAP-MN ключа, т.е. действительный предварительно предоставленный в совместное использование MAP-MN ключ уже существует, к примеру, при эстафетных передачах обслуживания MIPv6.
- Атрибут MAP-MN IPSec Key Lifetime EAP-TLV
Он представляет срок действия ключа для IPSec между MAP-MN. Он сообщается MN для случая, когда предварительно предоставленный в совместное использование MAP-MN ключ передается AAAh в MAP. Этот атрибут является необязательным и, как правило, не требуется, если MN не предоставлял одноразовое значение генерирования предварительно предоставленного в совместное использование MAP-MN ключа, т.е. действительный предварительно предоставленный в совместное использование MAP-MN ключ уже существует, к примеру, при эстафетных передачах обслуживания MIPv6.
- Атрибут HMIP-Binding-Update EAP-TLV
Он представляет пакет обновления связывания MAP, сгенерированный MN. Он переадресуется в MAP посредством AAAh от MN при обмене информацией при аутентификации и авторизации. Этот атрибут является необязательным и, как правило, не требуется, когда MN отправляет пакет обновления связывания MAP непосредственно MAP.
- Атрибут HMIP-Binding-Acknowledgement EAP-TLV
Он представляет пакет подтверждения связывания MAP, сгенерированный MAP. Он переадресуется в MN посредством AAAh от MAP при обмене информацией при аутентификации и авторизации. Этот атрибут является необязательным и, как правило, не требуется, когда MAP отправляет пакет обновления связывания MAP непосредственно MN.
Следующие необязательные атрибуты EAP-TLV могут быть заданы для специальных целей MIPv6.
- Атрибут MIPv6 Home Address EAP-TLV
Он представляет динамически назначаемый опорный адрес MIPv6 для аутентифицированного MN. Он предоставляется HA от AAAh для назначения опорного адреса MIPv6 в HA, когда MN, запросивший адрес, успешно аутентифицирован.
- Атрибут HA-MN Pre-shared Key EAP-TLV
Он представляет динамически генерируемый предварительно предоставленный в совместное использование между HA-MN ключ. Он предоставляется HA от AAAh, когда MN запрашивает аутентификацию для предоставление услуги MIPv6. AAAh может внутренне сгенерировать предварительно предоставленный в совместное использование HA-MN ключ посредством использования соответствующего алгоритма хеширования в отношении комбинации одноразового значения, представленного атрибутом HA-MN Pre-shared Key Generation Nonce EAP-TLV, и совместно используемого между MN и AAAh ключа. Этот атрибут является необязательным, когда действительный предварительно предоставленный в совместное использование HA-MN ключ уже существует.
- Атрибут HA-MN IPSec Protocol EAP-TLV
Он представляет протокол IPSec (к примеру, ESP или AH) между HA-MN. Он сообщается MN для случая, когда предварительно предоставленный в совместное использование HA-MN ключ передается AAAh в HA. Этот атрибут является необязательным и, как правило, не требуется, если MN не предоставлял одноразовое значение генерирования предварительно предоставленного в совместное использование HA-MN ключа, т.е. действительный предварительно предоставленный в совместное использование HA-MN ключ уже существует, к примеру, при эстафетных передачах обслуживания MIPv6.
- Атрибут HA-MN IPSec Crypto EAP-TLV
Он представляет криптографический алгоритм для IPSec между HA-MN. Он сообщается MN для случая, когда предварительно предоставленный в совместное использование HA-MN ключ передается AAAh в HA. Этот атрибут является необязательным и, как правило, не требуется, если MN не предоставлял одноразового значения генерирования предварительно предоставленного в совместное использование HA-MN ключа, т.е. действительный предварительно предоставленный в совместное использование HA-MN ключ уже существует, к примеру, при эстафетных передачах обслуживания MIPv6.
- Атрибут MIP-Binding-Update EAP-TLV
Он представляет пакет обновления связывания, сгенерированный MN. Он переадресуется в HA посредством AAAh от MN при обмене информацией по аутентификации и авторизации. Этот атрибут является необязательным и, как правило, не требуется, когда MN отправляет пакет обновления связывания непосредственно HA.
- Атрибут MIP-Binding-Acknowledgement EAP-TLV
Он представляет пакет подтверждения связывания, сгенерированный HA. Он переадресуется в MN посредством AAAh от HA при обмене информацией при аутентификации и авторизации. Этот атрибут является необязательным и, как правило, не требуется, когда HA отправляет пакет обновления связывания MAP непосредственно MN.
Следующие необязательные атрибуты EAP-TLV могут быть заданы для аутентификации HMIPv6/MIPv6.
- Атрибут MD5 Challenge EAP-TLV
Он представляет октетную строку, сгенерированную произвольно AAAh и отправленную MN для опознавательного запроса MD5.
- Атрибут MD5 Response EAP-TLV
Он представляет октетную строку, сгенерированную в качестве результата хеш-функции MD5 с помощью совместного используемого между AAAh и MN секретного ключа.
Следующие необязательные атрибуты EAP-TLV могут быть заданы для динамического назначения опорного адреса MN.
- Атрибут MIPv6 Home Address Request EAP-TLV
Он представляет запрос на динамически назначаемый опорный адрес MIPv6 для аутентифицированного MN. Он запрашивается MN у AAAh, когда MN первоначально запрашивает аутентификацию для предоставления услуги MIPv6. Этот атрибут является необязательным, когда MN уже имеет ранее назначенный опорный адрес, к примеру, при переадресациях вызовов MIPv6.
- Атрибут MIPv6 Home Address Response EAP-TLV
Он представляет динамически назначаемый опорный адрес MIPv6 для аутентифицированного MN. Он предоставляется MN от AAAh, когда MN, запросивший адрес, успешно аутентифицирован. Этот атрибут является необязательным, когда MN уже имеет ранее назначенный опорный адрес, к примеру, при переадресациях вызовов MIPv6.
Следующие необязательные атрибуты EAP-TLV могут быть заданы для динамического назначения HA.
- Атрибут MIPv6 Home Agent Address Request EAP-TLV
Он представляет запрос на адрес динамически назначенного HA для MN при успешной аутентификации. Он запрашивается MN у AAAh, когда MN первоначально запрашивает аутентификацию для предоставления услуги MIPv6. Поскольку протокол MIPv6 имеет способ динамического обнаружения HA, чтобы назначать HA, этот атрибут является необязательным. Это также имеет место в случае, когда MN уже имеет ранее назначенный HA, к примеру, при эстафетных передачах обслуживания MIPv6.
- Атрибут MIPv6 Home Agent Address Response EAP-TLV
Он представляет адрес динамически назначаемого HA для аутентифицированного MN. Он предоставляется MN от AAAh, когда MN первоначально запрашивает аутентификацию для предоставления услуги MIPv6. Поскольку протокол MIPv6 имеет способ динамического обнаружения опорного агента, чтобы назначать опорный агент, этот атрибут является необязательным. Это также имеет место в случае, когда MN уже имеет ранее назначенный HA, к примеру, при эстафетных передачах обслуживания MIPv6.
Следующие необязательные атрибуты EAP-TLV могут быть заданы для распространения ключей безопасности между HA и MN.
- Атрибут HA-MN Pre-shared Key Generation Nonce EAP-TLV
Он представляет октетную строку, произвольно генерируемую MN в качестве стартового числа для генерирования предварительно предоставленного в совместное использование между HA-MN ключа. MN может внутренне сгенерировать предварительно предоставленный в совместное использование HA-MN ключ посредством использования соответствующего алгоритма хеширования в отношении комбинации этого одноразового значения и предоставленного в совместное использование между MN и AAAh ключа. Этот атрибут является необязательным, когда действительный предварительно предоставленный в совместное использование HA-MN ключ уже существует, к примеру, при эстафетных передачах обслуживаниях MIPv6.
- Атрибут IKE KeyID EAP-TLV
Он представляет полезную нагрузку ID, заданную в [8]. KeyID генерируется AAAh и отправляется MN после успешной аутентификации. KeyID включает в себя несколько октетов, которые информируют HA о том, как извлекать (или генерировать) предварительно предоставленный в совместное использование HA-MN ключ от AAAh. Этот атрибут является необязательным и, как правило, не требуется, если MN не предоставлял одноразовое значение генерирования предварительно предоставленного в совместное использование HA-MN ключа, т.е. действительный предварительно предоставленный в совместное использование HA-MN ключ уже существует, к примеру, при эстафетных передачах обслуживания MIPv6. Он также не требуется для случая, когда предварительно предоставленный в совместное использование HA-MN ключ передается AAAh в MAP посредством интерфейса AAAh-HA, заданного в [9].
- Атрибут HA-MN IPSec SPI EAP-TLV
Он представляет индекс параметра безопасности для IPSec между HA и MN. Он генерируется HA и сообщается MN для случая, когда предварительно предоставленный в совместное использование HA-MN ключ передается AAAh в MAP посредством интерфейса AAAh-HA, заданного в [9]. Этот атрибут является необязательным и, как правило, не требуется, если MN не предоставлял одноразовое значение генерирования предварительно предоставленного в совместное использование HA-MN ключа, т.е. действительный предварительно предоставленный в совместное использование HA-MN ключ уже существует, к примеру, при переадресациях вызовов MIPv6. Он также не требуется для случая, когда интерфейс AAAh-HA, заданный в [9], не используется.
- Атрибут HA-MN IPSec Key Lifetime EAP-TLV
Он представляет срок действия ключа для IPSec между HA и MN. Он генерируется HA и сообщается MN для случая, когда предварительно предоставленный в совместное использование HA-MN ключ передается AAAh в MAP посредством интерфейса AAAh-HA, заданного в [9]. Этот атрибут является необязательным и, как правило, не требуется, если MN не представлял одноразовое значение генерирования предварительно предоставленного в совместное использование HA-MN ключа, т.е. действительный предварительно предоставленный в совместное использование HA-MN ключ уже существует, к примеру, при переадресациях вызовов MIPv6. Он также не требуется для случая, когда интерфейс AAAh-HA, заданный в [9], не используется.
В заключение, следующие необязательные атрибуты EAP-TLV могут быть заданы для распространения ключей безопасности между PAC и PAA для безопасности PANA.
- Атрибут PAC-PAA Pre-shared Key Generation Nonce EAP-TLV
Он представляет октетную строку, произвольно генерируемую MN/PAC в качестве стартового числа для генерирования предварительно предоставленного в совместное использование между PAC-PAA ключа. MN/PAC может внутренним образом сгенерировать предварительно предоставленный в совместное использование PAC-PAA ключ посредством использования соответствующего алгоритма хеширования в отношении комбинации этого одноразового значения и предоставленного в совместное использование между MN и AAAh ключа. Этот атрибут требуется для безопасности PANA.
Альтернативно, сервер AAAh может быть сконфигурирован для генерирования не только ключа безопасности MN-MAP, но также информации, требуемой для завершения ассоциации безопасности.
Как можно увидеть из вышеприведенных примеров, связанное с HMIPv6 конфигурирование обычно учитывается как часть общей процедуры авторизации.
Атрибут общего контейнера EAP (EAP GCA)
В альтернативной реализации EAP используется в качестве носителя относящейся к HMIPv6 информации (в необязательном порядке, также информации MIPv6) без создания нового, так называемого способа EAP, а вместо этого посредством переноса информации в атрибуте общего контейнера EAP, который может быть использован вместе с любым способом EAP.
В этой примерной реализации, которая основана на поддержке AAA в сети доступа, EAP дополнен атрибутом общего контейнера, который может быть использован, чтобы переносить любые (предположительно, не связанные с EAP) данные, к примеру специфические для HMIPv6 данные и, в необязательном порядке, также специфические для MIPv6 данные (если инициализация MIPv6 также требуется). Это дает возможность MN и AAAh обмениваться данным способом, который прозрачен для гостевого домена, включая сеть доступа, клиента AAA и AAAv, по меньшей мере, для MAP в случае опорной сети. EAP предпочтительно переносится в протоколе AAA, к примеру приложении Diameter EAP или даже Radius [10], [11], между клиентом AAA и AAAh.
Этот атрибут предпочтительно не должен быть доступен для всех способов EAP и может быть включен в любое сообщение EAP, в том числе сообщения EAP Success/Failure (Успех/Неудача). В этом решении новый атрибут общего контейнера используется, чтобы передавать специфические для HMIPv6 данные (в необязательном порядке, также данные MIPv6) между MN и AAAh. Решение также может включать в себя приложение Diameter или Radius, которое используется, чтобы обмениваться данными AAA и соответствующими данными между AAAh и HA.
Далее описывается возможная реализация атрибута общего контейнера (GCA) относительно текущего протокола EAP [12]. Как указано, атрибут общего контейнера должен предпочтительно быть доступен всем способам, и должно быть возможно включить его в любое сообщение EAP, в том числе сообщения EAP Success/Failure. Это подразумевает, что он должен являться частью уровня EAP, а не уровня способа EAP [12]. Важным вопросом для рассмотрения является обратная совместимость. Это относится к обратной совместимости относительно MN и средства аутентификации EAP (в типичном случае расположенного в NAS). Предполагается, что MN и сервер аутентификации EAP (т.е. AAAh) всегда совместимы. Применение GCA в данных примерах обычно предполагает, что новый атрибут введен в EAP путем, который обратно совместим и прозрачен для средства аутентификации EAP. Введение GCA с этими свойствами может потребовать некоторых специальных рассмотрений, описанных далее.
Например, форматом GCA может быть двухбайтный индикатор длины GCA, за которым следуют индикатор получателя GCA и полезная нагрузка GCA. Индикатор получателя GCA должен указывать, какой внутренней объектной сущности модуль EAP должен отправлять полезную нагрузку принятого GCA (т.е. этот индикатор должен соответствовать полю протокола/следующего заголовка в IP-заголовке или номеру порта в UDP- и TCP-заголовках). Полезная нагрузка GCA должна в таком случае быть общим участком данных, который не интерпретируется уровнем EAP. Отсутствие GCA предпочтительно должно указываться значением индикатора длины GCA, равным нулю.
Чтобы обеспечить обратную совместимость, GCA должен предпочтительно быть включен в пакеты EAP способом, прозрачным для средств опосредованной аутентификации EAP. Средство опосредованной аутентификации EAP - это средство аутентификации EAP (постоянно находящееся в NAS, в типичном случае точка доступа (AP) WLAN или маршрутизатор доступа), которое ретранслирует (почти все) пакеты EAP между MN и внутренним сервером аутентификации EAP (сервером AAA). В [12] указывается, что опосредованный режим работы средства аутентификации EAP заключается в том, чтобы ретранслировать пакеты EAP на основе заголовка уровня EAP, т.е. полей Code (код), Identifier (идентификатор) и Length (длина), в начале пакетов EAP. Это подразумевает, что требуемая прозрачность (и, следовательно, обратная совместимость) может, возможно, быть достигнута, если GCA помещен после заголовка уровня EAP (т.е. после полей Code, Identifier и Length).
Тем не менее, средство аутентификации EAP обычно также должно проверить поле Type (тип) (следующее за заголовком уровня EAP) пакетов EAP Response (ответ ЕАР), чтобы идентифицировать пакеты EAP Identity Response (ответ на запрос идентификационных данных ЕАР), из которых извлекается идентификатор доступа к сети (NAI), который необходим для маршрутизации AAA. Когда средство аутентификации EAP определяет пакет EAP Identity Response, оно извлекает NAI из поля Type-Data (Тип-Данные), следующего за полем Type. Следовательно, помещение GCA сразу после заголовка уровня EAP (путем, прозрачным для средства аутентификации EAP) возможно только в пакетах EAP Request (запрос ЕАР). Поэтому обычно предпочтительно размещать GCA после поля Type или даже после поля Type-Data (возможно, завершаемого NULL).
Помещение GCA сразу после поля Type позволяет использовать GCA во всех пакетах EAP Response кроме пакетов EAP Identity Response. Использование GCA в пакетах EAP Identity Response должно быть запрещено, поскольку из этих пакетов средство аутентификации EAP должно извлекать NAI из поля Type-Data, который наследуемое средство аутентификации EAP ожидает обнаружить сразу после поля Type. Это может быть ограничением на использование GCA при условии, что EAP обычно имеет достаточно небольшое число двусторонних прохождений. Возможно, GCA может быть помещен после завершаемого NULL поля Type-Data в пакете EAP Identity Response, одновременно сохраняя свою позицию после поля Type в других пакетах EAP.
Это часто желательно в случае позиции GCA, которая может быть использована согласованно во всех пакетах EAP. Из вышеприведенного описания складывается впечатление, что позиция, в которой может быть помещен GCA во всех пакетах EAP обратно-совместимым способом, располагается в конце пакета, в большей или меньшей степени как концевик. Тем не менее, это местоположение GCA может приводить к проблемам для тех пакетов EAP, которые не имеют явных индикаторов длины параметра Type-Data, но основываются на поле Length в заголовке уровня EAP. В этих пакетах он не сможет отличить GCA от поля Type-Data.
Чтобы устранить эту проблему, порядок индикатора длины GCA, индикатора получателя GCA и полезной нагрузки GCA должен быть развернут наоборот таким образом, чтобы индикатор длины GCA появлялся первым. Таким образом, при помещении GCA в конец пакета EAP последние два октета пакета EAP (длина которых указывается полем Length в заголовке уровня EAP) всегда будут индикатором длины GCA. Если индикатор длины GCA не равен нулю, индикатор получателя GCA располагается перед индикатором длины GCA, а полезная нагрузка GCA (размер которой определяется из индикатора длины GCA) должна быть размещена перед индикатором получателя GCA. Посредством этого принципа всегда можно определить GCA в пакете EAP и отличить GCA от поля Type-Data. Тем не менее, использование GCA будет прозрачным для средства опосредованной аутентификации EAP.
Обратная совместимость с этим решением GCA дополнительно требует, чтобы средство аутентификации EAP не пыталось извлекать информацию из пакетов EAP Request/Response (за исключением заголовка уровня EAP и NAI) и чтобы оно допускало, что поле Length в пакетах Success/Failure указывает значение больше 4.
Альтернативный способ справиться с проблемой обратной совместимости заключается в том, чтобы использовать пакеты EAP GCA Test Request/Response (Запрос/Ответ ЕАР теста на GCА) (т.е. новые пакеты EAP с новыми заданными значениями поля Type), чтобы определять, поддерживает ли MN GCA.
До или после первоначального обмена пакетами EAP Identity Request/Response средство аутентификации EAP, поддерживающее GCA, должно отправить пакет EAP GCA Test Request (т.е. пакет EAP Request со специальным значением Type) в MN (конечный автомат одноранговой связи EAP [13] указывает, что оба альтернативных значения времени отправки являются реализуемыми). Если MN поддерживает GCA, он отвечает с помощью пакета EAP GCA Test Response. В противном случае MN интерпретирует пакет EAP GCA Test Request как запрос, чтобы использовать неизвестный способ EAP, и поэтому MN отвечает пакетом EAP Nak (отрицательного квитирования). Из ответа от MN средство аутентификации EAP может определить, поддерживает ли MN GCA.
MN, поддерживающий GCA, может определить, поддерживает ли средство аутентификации EAP GCA, из наличия или отсутствия пакета EAP GCA Test Request. Если пакет GCA Test Request принят, когда ожидалось (т.е. до или после обмена сообщениями EAP Identity Request/Response), средство аутентификации EAP поддерживает GCA. В противном случае не поддерживает.
Если и MN, и средство аутентификации EAP поддерживают GCA, то он помещается после заголовка уровня EAP во все последующие пакеты EAP (с исходным порядком компонентов GCA). В противном случае GCA может по-прежнему включаться в пакеты EAP, которые дают ему возможность быть включенным обратно-совместимым способом (как описано выше).
Есть некоторые ограничения описанного альтернативного способа разрешения проблемы обратной совместимости. Во-первых, тратится одно двустороннее прохождение между MN и средством аутентификации EAP. Более того, если обмен пакетами EAP GCA Test Request/Response осуществляется после первоначального обмена пакетами EAP Identity Request/Response, GCA не может быть использован в пакете EAP Identity Response. Этот вариант осуществления также может требовать, чтобы средство аутентификации EAP (возможно, NAS) использовало модифицированную версию EAP, например EAPv2. Следовательно, хотя другие альтернативы возможны, предпочтительным способом размещения GCA в пакетах EAP в типичном случае является концевик в конце пакета с индикатором длины GCA последним, после полезной нагрузки GCA и индикатора получателя GCA.
Если число двусторонних прохождений недостаточно для данных, которыми обмениваются в GCA, AAAh может рассмотреть увеличение числа двусторонних прохождений EAP посредством обмена сообщениями EAP Notification Request/Response для целей передачи GCA.
Другой вариант - фактически ввести GCA в способ EAP на уровне способа стека протоколов EAP. Если GCA сделан специфическим для конкретного способа EAP, GCA не представляет никакой проблемы обратной совместимости, поскольку он в таком случае обычно является частью поля Type-Data.
Примерные последовательности обмена
сигналами для EAP/HMIPv6
Фиг. 7 иллюстрирует примерную последовательность обмена сигналами для EAP/HMIPv6 (Diameter) для случая, когда MAP расположена в опорной сети.
Клиент AAA запрашивает аутентификацию MN с помощью EAP (Request Identity), а MN отвечает с помощью EAP (Response Identity).
Ответ MN отправляется в AAAh через инфраструктуру AAA. AAAh определяет из идентификационных данных MN и на основе политики оператора то, что методология EAP/HMIPv6 подходит для аутентификации и авторизации MN (т.е. AAAh знает возможности MN). AAAh отправляет обозначение предложенной методологии EAP (к примеру, EAP/HMIPv6) вместе с запросом к MN через инфраструктуру AAA. Обозначение методологии или схемы EAP может быть реализовано посредством назначения нового номера EAP Type для дополненной схемы EAP (к примеру, EAP/HMIPv6). Таким образом мобильный узел узнает, какую схему EAP предлагает AAAh. Альтернативно, специально отформатированный запрос отправляется мобильному узлу, который распознает, что запрос обозначает заданную схему EAP.
MN требуется инициализировать HMIPv6, и он отвечает на предложение и опознавательный запрос AAAh с помощью ответа на опознавательный запрос, а также соответствующих атрибутов EAP (TLV), которые передают запрос, который должен быть назначен соответствующей MAP, вместе с необходимой информацией для ассоциации безопасности с назначенной MAP. В этом процессе MN также может инициализировать MIPv6, если это не было сделано ранее. Ответ MN отправляется в AAAh посредством инфраструктуры AAA. Хотя запрос на назначение MAP может фактически быть неявным, обычно рекомендуется использовать явный запрос на назначение MAP. Для случаев, когда мобильный узел уже знает адрес MAP и может, к примеру, просто обновить ассоциацию безопасности с MAP, не выдается запрос на назначение MAP, а только выполняется повторная аутентификация и/или авторизация.
AAAh проверяет действительность ответа на запрос MN, и успешное завершение означает, что MN является подлинным, а затем AAAh продолжает обрабатывать другие запросы MN.
Сначала AAAh выбирает MAP в опорной сети и отправляет MAP сообщение усовершенствованного EAP (заметим, что это отдельный сеанс EAP, который уже активирован между MN и AAAh), содержащее, к примеру, ключи безопасности, и MAP отвечает AAAh, предпочтительно посредством предоставления информации, если она необходима или иным образом назначена, для завершения ассоциации безопасности с MN. Например, для ассоциаций безопасности IPSec может быть необходимо использовать атрибуты EAP, такие как атрибуты IPSec Protocol, IPSec Crypto, IPSec Key Lifetime EAP TLV, заданные в табл. 1 выше.
В этом и последующих иллюстративных примерах предполагается, что мобильный узел (MN) и AAAh имеют общий предоставленный в совместное использование секрет. Это может быть, например, симметричный ключ, предоставленный в совместное использование идентификационному модулю, установленному в мобильном узле, и оператору опорной сети. Идентификационным модулем может быть любой идентификационный модуль, защищенный от несанкционированного вмешательства, известный в данной области техники, в том числе стандартные SIM-карты, используемые в мобильных телефонах GSM (Глобальной системы мобильной связи), универсальные SIM (USIM), WAP SIM, также известные как WIM, ISIM (идентификационный модуль мультимедийной подсистемы IP) и, более часто, модули UICC (Универсальная карта на основе интегральной микросхемы). Для ассоциации безопасности MN-MAP (MN-HA) стартовое число или одноразовое значение может быть передано по MN в AAAh (или другим способом, т.е. стартовое число создается AAAh и передается MN), из которого AAAh может создавать ключи безопасности MN-MAP (MN-HA) на основе предоставленного в совместное использование секрета. Мобильный узел может генерировать те же ключи безопасности самостоятельно, поскольку он создал стартовое число/одноразовое значение (или принимает стартовое число от AAAh) и также имеет предоставленный в совместное использование секрет. Альтернативно, AAAh сам может сгенерировать информацию безопасности и защищенным образом передать ее надлежащим узлам.
Во-вторых, если запрошена инициализация MIPv6, AAAh продолжает обслуживать этот запрос на инициализацию MIPv6 посредством выбора HA с помощью другого сеанса усовершенствованного EAP, и HA отвечает AAAh посредством предоставления информации, необходимой, чтобы создать ассоциацию безопасности с MN. В необязательном порядке можно совместить "обновления связывания MAP", а также "обновления связывания HA" в обмене информацией при аутентификации и авторизации. Это означает, что связывание HMIPv6 интегрируется в том же двустороннем прохождении, что и ассоциация безопасности MN-MAP (только LCoA необходим в обновлении связывания от мобильного узла). Для этого случая в отношении RCoA HMIPv6, полученного AAAh в ходе первой операции с MAP, автоматически выполняется обновление связывания MIPv6 с помощью HA во второй операции.
После того как AAAh обменялся данными с MAP и HA, как описано выше, AAAh отправляет информацию авторизации (и/или конфигурирования), такую как адрес MAP, RCoA, адрес HA, опорный адрес MN, и информацию ассоциации безопасности вместе с указанием успешного выполнения аутентификации обратно MN посредством дополненного EAP. Дополнительное последнее двустороннее прохождение обмена данными на фиг. 7 предназначено для того, чтобы гарантировать, что протокол EAP завершен гладко согласно текущей спецификации протокола EAP.
Фиг. 8 иллюстрирует примерную последовательность обмена сигналами для EAP/HMIPv6 (Diameter) для случая, когда MAP расположена в гостевой сети.
Клиент AAA запрашивает аутентификацию MN с помощью EAP (Request Identity), а MN отвечает с помощью EAP (Response Identity).
Ответ MN отправляется в AAAh через инфраструктуру AAA. AAAh определяет из идентификационных данных MN и на основе политики оператора то, что методология EAP/HMIPv6 подходит для аутентификации и авторизации MN (т.е. AAAh знает возможности MN). AAAh отправляет обозначение предложенной методологии EAP (к примеру, EAP/HMIPv6) вместе с запросом к MN через инфраструктуру AAA.
MN требуется инициализировать HMIPv6, и он отвечает на предложение и опознавательный запрос AAAh с помощью ответа на опознавательный запрос, а также соответствующих атрибутов EAP (TLV), которые передают запрос, который должен быть назначен соответствующей MAP вместе с необходимыми подробными сведениями для ассоциации безопасности с назначенной MAP. В этом процессе MN также может инициализировать MIPv6, если это не было сделано ранее. Ответ MN отправляется в AAAh посредством инфраструктуры AAA.
AAAh проверяет действительность ответа на запрос MN, и успешный результат проверки означает, что MN является подлинным, и затем AAAh продолжает обрабатывать другие запросы MN.
Во-первых, AAAh переадресует запрос для MAP в гостевой сети соответствующему AAAv, это предпочтительно выполняется посредством приложения Diameter, которое для простоты названо приложением Diameter HMIPv6. Причина этого состоит в том, что политика гостевого оператора должна быть принята во внимание при выборе MAP в гостевой сети, и AAAv, таким образом, должен иметь возможность видеть транзакцию (при использовании EAP обмен данными является сквозным, и это невозможно). AAAv выбирает MAP в гостевой сети и переадресует сообщение приложения Diameter HMIPv6, содержащее, к примеру, ключи безопасности, MAP. MAP отвечает AAAh посредством AAAv, предпочтительно посредством предоставления информации, если требуется или иным образом подходит, для завершения ассоциации безопасности с MN. Во-вторых, AAAh продолжает обслуживать запрос на инициализацию MIPv6, если он представлен, посредством выбора HA, использующего другой сеанс усовершенствованного EAP, и HA отвечает AAAh посредством предоставления информации, необходимой, чтобы создать ассоциации безопасности с MN. Обратите внимание, что можно совместить "обновления связывания MAP", а также "обновления связывания HA" в обмене информацией при аутентификации и авторизации. Для этого случая в отношении RCoA HMIPv6, полученного AAAh в ходе первой операции с MAP, автоматически выполняется обновление связывания MIPv6 с помощью HA во второй операции.
После того как AAAh обменялся данными с MAP и HA, как описано выше, AAAh отправляет информацию авторизации (и/или конфигурирования), такую как адрес MAP, RCoA, адрес HA, опорный адрес MN, и информацию ассоциации безопасности вместе с указанием успешного выполнения аутентификации обратно MN посредством дополненного EAP. Дополнительное последнее двустороннее прохождение обмена данными на фиг. 8 предназначено для того, чтобы гарантировать, что дополненный протокол EAP завершен гладко согласно текущей спецификации протокола EAP.
Хотя некоторые из подробных примерных вариантов осуществления описаны главным образом со ссылкой на текущую версию EAP, следует понимать, что изобретение очень хорошо применимо в других версиях EAP, таких как EAPv2, а также в других протоколах аутентификации, дополненных или сконфигурированных описанным способом. EAP - это просто пример возможной реализации, и изобретение, в целом, не ограничено им и может альтернативно задействовать схемы без EAP.
Приложение протокола структуры AAA для HMIPv6
В другом примерном варианте осуществления создается новое приложение протокола инфраструктуры AAA, проиллюстрированное в данном документе посредством приложения Diameter, адаптированного для HMIPv6 (упоминаемого как "Приложение Diameter HMIPv6"), которое переносит относящуюся к HMIPv6 информацию, облегчающую, например, обнаружение MAP, динамическое назначение MAP, динамическое назначение RCoA, распространение ключей безопасности между MN и MAP и/или возможное совмещение процедур мобильности HMIPv6. Хотя Diameter упоминается далее, следует понимать, что в качестве основы для нового или дополненного приложения HMIPv6 может быть использован Radius или другой аналогичный протокол инфраструктуры AAA.
Если требуется, аутентификация и/или авторизация HMIPv6 и MIPv6 могут быть интегрированы в одно и то же приложение протокола инфраструктуры AAA. Это может быть достигнуто посредством использования приложения Diameter MIPv6, описанного в [3], и в дополнение к этому задания новых специфических для HMIP кодов команд, AVP и/или флагов. Посредством включения командных кодов, AVP и флагов приложения Diameter MIPv6 в качестве части Diameter MIPv6 можно предоставлять одновременные исполнения аутентификации и/или авторизации MIPv6 и HMIPv6 за один проход, что дает возможность сокращения времени настройки. Также можно исполнять только аутентификацию и/или авторизацию HMIPv6 без участия MIPv6 и наоборот, в зависимости от конкретной потребности MN в конкретном случае. Это дает возможность гибкого использования одного приложения, приложения Diameter HMIPv6, в различных вариантах использования.
Более того, совмещение процедур мобильности HMIPv6 в Diameter HMIPv6 дает возможное сокращение общего времени на настройку посредством оптимизации аутентификации, авторизации и мобильности в общей процедуре.
Подробные сведения о приложении Diameter HMIPv6
Далее предоставляются подробные сведения о приложении Diameter HMIPv6, чтобы показать примеры общих последовательностей обмена сигналами и жизнеспособности концепции. Предпочтительно, заданы новые специфические для HMIP коды команд, AVP и/или флаги, которые переносят информацию, которая облегчает, например, обнаружение MAP, динамическое назначение MAP, динамическое назначение RCoA, распространение ключей безопасности между MN и MAP и/или возможное совмещение процедур мобильности HMIPv6. Коды команд, AVP и флаги приложения Diameter MIPv6 [3] могут необязательно быть включены как часть приложения Diameter HMIPv6.
Примерная сводная матрица кодов команд и AVP приложения Diameter HMIPv6 приведена ниже в табл. 2.
| Коды команд и AVP приложения Diameter HMIPv6 | Источник | Адресат | Цель | Комментарий |
| Специфические для HMIPv6 коды команд: | ||||
| Команда MAP-HMIPv6-Request (MAR) | AAAh | MAP | Обмен AVP HMIP | MAP в опорной сети |
| AAAh | MAP через AAAv | Обмен AVP HMIP | MAP в гостевой сети | |
| Команда MAP-HMIPv6-Answer (MAA) | MAP | AAAh через AAAv | Обмен AVP HMIP | MAP в опорной сети |
| MAP | AAAh | Обмен AVP HMIP | MAP в гостевой сети | |
| Специфические для HMIPv6 AVP: | ||||
| AVP HMIP-Binding-Update | Сообщение обновления связывания HMIP, отправленное MN в MAP | |||
| AVP HMIP-Binding-acknowledgement | Подтверждение связывания HMIP, отправленное MAP в MN | |||
| AVP RCoA | RCoA | |||
| AVP MAP Address | Адрес MAP | |||
| AVP HMIPv6-Feature-Vector | ||||
| Флаг MAP-Requested | Запросы на динамическое назначение MAP | |||
| AVP MAP-MN Pre-shared Key Generation Nonce | Стартовое число ключа MN-MAP | |||
| AVP MAP-MN Pre-shared Key | Назначение ключа MN-MAP | |||
| AVP MAP IKE KeyID | Назначение IKE KeyID | |||
| AVP MAP-MN IPSec SPI | Назначение SPI | |||
| AVP MAP-MN IPSec Protocol | Назначение протокола IPSec | |||
| AVP MAP-MN IPSec Crypto | Назначение шифрования IPSec | |||
| AVP MAP-MN IPSec Key Lifetime | Назначение срока действия ключа IPSec | |||
| Используемые коды команд приложения Diameter MIPv6: | ||||
| Команда AA-Registration-Request (ARR) | Клиент AAA | AAAh (через AAAv) | ||
| Команда AA-Registration-Answer (ARA) | AAAh | Клиент AAA (через AAAv) | ||
| Команда Home-Agent-MIPv6-Request (HOR) | AAAh | HA | ||
| Команда Home-Agent-MIPv6-Answer (HOA) | HA | AAAh | ||
| Используемые AVP приложения Diameter MIPv6: | ||||
| AVP MIP-Binding-Update | Сообщение обновления связывания Mobile IP, отправленное MN в HA | |||
| AVP MIP-Binding-acknowledgement | Подтверждение связывания Mobile IP, отправленное HA в MN | |||
| AVP MIPv6-Mobile-Node-Address | Опорный адрес мобильного узла | |||
| AVP MIPv6-Home-Agent-Address | Адрес опорного агента мобильного узла | |||
| AVP MIPv6-Feature-Vector | ||||
| Флаг Home-Agent-Requested | Запросы на динамическое назначение опорного агента |
Подробности см. в проекте Интернет-документа [5], который задает коды команд и AVP, необходимые, чтобы переносить пакеты EAP между сервером доступа к сети (NAS) и внутренним сервером аутентификации.
Примерные последовательности обмена сигналами
для приложения Diameter HMIPv6
Фиг. 9 иллюстрирует примерную последовательность обмена сигналами в приложении Diameter HMIPv6 для случая, когда MAP расположена в опорной сети.
Клиент AAA выдает опознавательный запрос к MN, чтобы быть аутентифицированным, например, посредством таких протоколов, как протокол управляющих сообщений в Интернете (ICMP), PANA и т.п. MN отвечает ответом на опознавательный запрос с запросами на инициализацию HMIPv6 и, возможно, также MIPv6.
Клиент AAA воспринимает запросы на инициализацию HMIPv6 и MIPv6 и переадресует ответ MN в AAAh через инфраструктуру AAA с помощью кода команды приложения Diameter HMIPv6 (ARR). В этот процесс клиент AAA также включает запрос на то, чтобы разрешить AAAh верифицировать подлинность MN.
AAAh проверяет действительность ответа на запрос MN, и успешный результат проверки означает, что MN является подлинным, и затем AAAh продолжает обрабатывать другие запросы MN.
Во-первых, AAAh выбирает MAP в опорной сети и отправляет MAP соответствующий код команды приложения Diameter HMTPv6 (MAR), содержащий, к примеру, ключи безопасности, и MAP отвечает AAAh, предпочтительно посредством предоставления информации, если требуется или иным образом подходит, для завершения ассоциации безопасности с MN посредством кода команды (MAA). Во-вторых, если запрошена инициализация MIPv6, AAAh продолжает обслуживать этот запрос на инициализацию MIPv6 посредством выбора HA с помощью кода команды приложения Diameter HMIPv6 (HOR), и HA отвечает AAAh посредством предоставления информации, необходимой, чтобы создать ассоциацию безопасности с MN посредством кода команды (HOA). Обратите внимание, что можно совместить "обновления связывания MAP", а также "обновления связывания HA" в обмене информацией при аутентификации и авторизации. Для этого случая в отношении RCoA HMIPv6, полученного AAAh в ходе первой операции с MAP, автоматически выполняется обновление связывания MIPv6 с помощью HA во второй операции.
После того как AAAh обменялся данными с MAP и HA, как описано выше, AAAh отправляет информацию авторизации (и/или конфигурирования), такую как адрес MAP, RCoA, адрес HA, опорный адрес MN, и информацию ассоциации безопасности вместе с указанием успешного выполнения аутентификации обратно MN посредством кода команды приложения Diameter HMIPv6 (ARA) и, например, ICMP, PANA и т.д.
Фиг. 10 иллюстрирует примерную последовательность обмена сигналами в приложении Diameter HMIPv6 для случая, когда MAP расположена в гостевой сети.
Клиент AAA выдает опознавательный запрос к MN, чтобы быть аутентифицированным, например, посредством ICMP или PANA. MN отвечает ответом на опознавательный запрос с HMIPv6 и, возможно, также запросами на инициализацию MIPv6.
Клиент AAA воспринимает запросы на инициализацию HMIPv6 и MIPv6 и переадресует ответ MN в AAAh через инфраструктуру AAA с помощью кода команды приложения Diameter HMIPv6 (ARR). В этот процесс клиент AAA также включает запрос на то, чтобы разрешить AAAh верифицировать подлинность MN.
AAAh проверяет действительность ответа на запрос MN, и успешный результат проверки означает, что MN является подлинным, и затем AAAh продолжает обрабатывать другие запросы MN.
Во-первых, AAAh переадресует запрос для MAP в гостевой сети к соответствующему AAAv, это выполняется посредством кода команды Diameter HMIPv6 (MAR). AAAh выбирает MAP в гостевой сети и переадресует MAP код команды (MAR), который включает в себя, например, ключи безопасности, и MAP отвечает AAAh посредством AAAv, предпочтительно посредством предоставления информации, если требуется или иным образом подходит, для завершения ассоциации связи безопасности с MN посредством кода команды (MAA). Во-вторых, если запрошено, AAAh продолжает обслуживать этот запрос на инициализацию MIPv6 посредством выбора HA с помощью кода команды приложения Diameter HMIPv6 (HOR), и HA отвечает AAAh посредством предоставления информации, необходимой, чтобы создать ассоциацию безопасности с MN посредством кода команды (HOA). Обратите внимание, что можно совместить "обновления связывания MAP", а также "обновления связывания HA" в обмене информацией при аутентификации и авторизации. Для этого случая в отношении RCoA HMIPv6, полученного AAAh в ходе первой операции с MAP, автоматически выполняется обновление связывания MIPv6 с помощью HA во второй операции.
После того как AAAh обменялся данными с MAP и HA, как описано выше, AAAh отправляет информацию авторизации (и/или конфигурирования), такую как адрес MAP, RCoA, адрес HA, опорный адрес MN, и информацию ассоциации безопасности вместе с указанием успешного выполнения аутентификации обратно MN посредством кода команды приложения Diameter HMIPv6 (ARA) и такого протокола, как ICMP или PANA.
Обобщая некоторые из вышеуказанных аспектов, можно видеть, что использование в качестве основы инфраструктуры AAA предлагает ряд возможностей для инициализации службы HMIPv6. Например, можно предоставить дополнение к общему протоколу аутентификации, такому как будущие версии EAP, переносимому по инфраструктуре AAA, и/или усовершенствовать приложение протокола архитектуры AAA, например приложения Diameter и Radius.
Фиг. 11 - это блок-схема последовательности операций базового примера способа поддержки службы HMIPv6 для мобильного узла. В этом примере перенос информации и действия, указанные на этапах S1-S4, относятся к аутентификации мобильного узла (S1), установлению ассоциации безопасности MN-MAP (S2), конфигурированию HMIPv6 (S3) и связыванию HMIPv6 (S4). Этапы S2-S3, как правило, упоминаются как фаза авторизации. Этапы S1-S4 при необходимости могут быть исполнены в большей или меньшей степени параллельно, например совмещение связывания HMIPv6 в одном двустороннем прохождении с процедурой ассоциации связи безопасности HMIPv6, чтобы обеспечить уменьшение общего времени на настройку. На этапе S1 информация передается по инфраструктуре AAA для аутентификации мобильного узла на стороне опорной сети. На этапе S2 относящаяся к HMIPv6 информация передается, чтобы сразу установить или чтобы обеспечить будущее установление ассоциации связи безопасности между MN и MAP. На этапе S3 выполняется дополнительное конфигурирование HMIPv6, например, посредством передачи конфигурационных параметров мобильному узлу для надлежащего хранения. На этапе S4 мобильный узел отправляет обновление связывания, и связывание HMIPv6 устанавливается в MAP.
Помимо прочих областей применения, изобретение применимо ко всем сетям доступа, таким как WLAN, CDMA2000, WCDMA и т.д., где может быть использован HMIPv6 и, в необязательном порядке, также MIPv6, включая технологии, такие как AAA и мобильность IPv6, системы, такие как системы CMS11, WCDMA и GSM, подсистемы, такие как подсистемы и терминалы служб/приложений, и продукты, такие как серверы AAA, серверы опорных агентов и терминальные узлы.
В качестве альтернативы вышеописанным примерным процедурам распространения ключей MN-HA может быть использован механизм, аналогичный текущему существующему решению 3GPP2 вместе со структурой IKE, чтобы распространять динамические предварительно предоставленные в совместное использование ключи для MN и HA.
Вышеописанные варианты осуществления даны просто в качестве примеров, и следует понимать, что настоящее изобретение не ограничено ими. Дополнительные модификации, изменения и усовершенствования, которые сохраняют основополагающие принципы, раскрытые и заявленные в данном документе, не выходят за рамки объема изобретения.
ССЫЛКИ
[l] Mobility Support in IPv6, D. Johnson, C. Perkins, J. Arkko, 30 июня 2003 года, <draft-ietf-mobileip-ipv6-24.txt>.
[2] Hierarchical Mobile IPv6 mobility management (HMIPv6), Heshani Soliman, Claude Castelluccia, Karim El-Malki, Ludovic Bellier, июнь 2003 года, <draft-ietf-mobileip-hniipv6-08.txt>.
[3] Diameter Mobile IPv6 Application, Stefano M. Faccin, Franck Le, Basavaraj Patil, Charles E. Perkins, апрель 2003 года, <draft-le-aaa-diameter-mobileipv6-03.txt>.
[4] MIPv6 Authorization and Configuration based on EAP, G. Giaretta, I. Guardini, E. Demaria, февраль 2004 года, <draft-giaretta-mip6-authorization-eap-OO.txt>.
[5] Diameter Extensible Authentication Protocol (EAP) Application, P. Eronen, T. Hiller, G. Zom, 16 февраля 2004 года, <draft-ietf-aaa-eap-04.txt>.
[6] PPP Extensible Authentication Protocol (EAP), RFC2284, L. Blunk, J. Vollbrecht, март 1998 года.
[7] IEEE Standard 802.1X, Local and metropolitan area networks - Port-Based Network Access Control.
[8] Internet Security Association and Key Management Protocol (ISAKMP), RFC2408, D. Maughan, M. Schertler, M. Schneider, J. Turner, ноябрь 1998 года.
[9] Diameter Mobile IPv4 Application, P. Calhoun, T. Johansson, C. Perkins, 2003, <draft-ietf-aaa-diameter-mobileip-14.txt>.
[10] Remote Authentication Dial In User Service (RADIUS) - RFC2865, C. Rigney, S. Willens, A. Rubens, W. Simpson, июнь 2000 года.
[11] RADIUS Extensions - RFC2869, C. Rigney, W. Willats, P. Calhoun, июнь 2000 года.
[12] Extensible Authentication Protocol (EAP) - RFC2284, L. Blunk, J. Vollbrecht, B. Aboba, J. Carlson, H. Levkowetz, сентябрь 2003 года, <draft-ietf-eap-rfc2284bis-06.txt>.
[13] State Machines for EAP Peer and Authenticator, J. Vollbrecht, P. Eronen, N. Petroni, Y. Ohba, октябрь 2003 года, <draft-ietf-eap-statemachine-01.pdf>.
1. Способ поддержки услуги Hierarchical Mobile IP версии 6 (HMIPv6) для мобильного узла, отличающийся тем, что содержит этап, на котором используют инфраструктуру аутентификации, авторизации и управления учетными записями (ААА), чтобы инициализировать услугу HMIPv6, при этом
назначают посредством упомянутой инфраструктуры ААА надлежащую точку привязки мобильности (MAP) мобильному узлу для услуги HMIPv6;
и
передают по упомянутой инфраструктуре ААА относящуюся к HMIPv6 информацию для аутентификации и авторизации мобильного узла для услуги HMIPv6 в отношении назначенной MAP.
2. Способ по п.1, отличающийся тем, что сервер ААА упомянутой инфраструктуры ААА назначает надлежащую MAP мобильному узлу для услуги HMIPv6.
3. Способ по п.2, отличающийся тем, что мобильный узел передвигается в гостевой сети, и сервер ААА гостевой сети (AAAv) назначает MAP в гостевой сети мобильному узлу на основе политики оператора гостевой сети.
4. Способ по п.1, отличающийся тем, что компонент инфраструктуры ААА опорной сети генерирует связанные с полномочиями данные для ассоциации безопасности между мобильным узлом и назначенной MAP и отправляет упомянутые связанные с полномочиями данные в MAP, компонент опорной сети инфраструктуры ААА генерирует информацию для завершения ассоциации безопасности или MAP отвечает информацией для завершения ассоциации безопасности компоненту опорной сети инфраструктуры ААА, который отправляет информацию авторизации HMIPv6 мобильному узлу по инфраструктуре ААА.
5. Способ по п.1, отличающийся тем, что содержит этап, на котором передают относящуюся к HMIPv6 информацию по упомянутой инфраструктуре ААА для установления ассоциации безопасности HMIPv6 между мобильным узлом и назначенной MAP и для установления связывания HMIPv6 для мобильного узла, и при этом относящаяся к HMIPv6 информация для связывания HMIPv6 передается за одно двустороннее прохождение сигнала с относящейся к HMIPv6 информацией для ассоциации безопасности HMIPv6.
6. Способ по п.1, отличающийся тем, что мобильный узел передвигается в гостевой сети, и относящаяся к HMIPv6 информация аутентификации и авторизации передается между мобильным узлом и сервером ААА опорной сети (AAAh) в рамках протокола аутентификации в сквозной процедуре, прозрачной для гостевой сети.
7. Способ по п.6, отличающийся тем, что упомянутым протоколом аутентификации является дополненный расширяемый протокол аутентификации (ЕАР), и упомянутая относящаяся к HMIPv6 информация включена в качестве дополнительных данных в стек протоколов ЕАР.
8. Способ по п.7, отличающийся тем, что упомянутая относящаяся к HMIPv6 информация передается в общем контейнере в стеке протоколов ЕАР.
9. Способ по п.6, отличающийся тем, что назначенная MAP расположена в гостевой сети, и относящаяся к HMIPv6 информация передается между мобильным узлом и сервером ААА опорной сети (AAAh) в рамках упомянутого протокола аутентификации, и относящаяся к HMIPv6 информация передается между AAAh и назначенной MAP в гостевой сети в рамках приложения протокола архитектуры ААА.
10. Система поддержки услуги Hierarchical Mobile IP версии 6 (HMIPv6) для мобильного узла, отличающаяся тем, что содержит
компонент инфраструктуры ААА, выполненный с возможностью назначения надлежащей точки привязки мобильности (MAP) мобильному узлу для услуги HMIPv6; и
средство передачи по упомянутой инфраструктуре ААА относящейся к HMIPv6 информации, необходимой для аутентификации и авторизации мобильного узла для услуги HMIPv6 в отношении назначенной MAP.
11. Система по п.10, отличающаяся тем, что упомянутый компонент инфраструктуры ААА является сервером, выполненным с возможностью назначения надлежащей MAP мобильному узлу для услуги HMIPv6.
12. Система по п.11, отличающаяся тем, что мобильный узел передвигается в гостевой сети, и сервер ААА гостевой сети (AAAv) выполнен с возможностью назначения MAP в гостевой сети мобильному узлу на основе политики оператора гостевой сети.
13. Система по п.10, отличающаяся тем, что компонент инфраструктуры ААА опорной сети содержит
средство генерирования связанных с полномочиями данных для ассоциации безопасности между мобильным узлом и назначенной MAP; и
средство отправки упомянутых связанных с полномочиями данных назначенной MAP;
средство приема информации от MAP для завершения ассоциации безопасности; и
средство отправки информации авторизации HMIPv6 мобильному узлу по инфраструктуре ААА.
14. Система по п.10, отличающаяся тем, что содержит средство передачи относящейся к HMIPv6 информации по упомянутой инфраструктуре ААА для установления ассоциации безопасности HMIPv6 между мобильным узлом и назначенной MAP и для установления связывания HMIPv6 для мобильного узла, и при этом относящаяся к HMIPv6 информация для связывания HMIPv6 передается за одно двустороннее прохождение сигнала с относящейся к HMIPv6 информацией для ассоциации безопасности HMIPv6.
15. Система по п.10, отличающаяся тем, что мобильный узел передвигается в гостевой сети, и относящаяся к HMIPv6 информация аутентификации и авторизации передается между мобильным узлом и сервером ААА опорной сети (AAAh) в рамках протокола аутентификации в сквозной процедуре, прозрачной для гостевой сети.
16. Система по п.15, отличающаяся тем, что упомянутым протоколом аутентификации является дополненный расширяемый протокол аутентификации (ЕАР), и упомянутая относящаяся к HMIPv6 информация включена в качестве дополнительных данных в стек протоколов ЕАР.
17. Система по п.16, отличающаяся тем, что упомянутая относящаяся к HMIPv6 информация передается в общем контейнере в стеке протоколов ЕАР.
18. Система по п.15, отличающаяся тем, что назначенная MAP расположена в гостевой сети, и относящаяся к HMIPv6 информация передается между мобильным узлом и сервером ААА опорной сети (AAAh) в рамках упомянутого протокола аутентификации, и относящаяся к HMIPv6 информация передается между AAAh и назначенной MAP в гостевой сети в рамках приложения протокола архитектуры ААА.
19. Сервер ААА для поддержки услуги Hierarchical Mobile IP версии 6 (HMIPv6) для мобильного узла, отличающийся тем, что содержит средство назначения надлежащей точки привязки мобильности (MAP) мобильному узлу для услуги HMIPv6.
20. Сервер ААА по п.19, отличающийся тем, что мобильный узел передвигается в гостевой сети, и упомянутым сервером ААА является сервер ААА гостевой сети (AAAv), выполненный с возможностью назначения MAP в гостевой сети.
21. Сервер ААА по п.19, отличающийся тем, что упомянутым сервером ААА является сервер ААА опорной сети (AAAv), выполненный с возможностью назначения MAP в опорной сети мобильного узла.
22. Сервер ААА опорной сети (AAAh) для поддержки услуги Hierarchical Mobile IP версии 6 (HMIPv6) для мобильного узла, отличающийся тем, что содержит
средство генерирования связанных с полномочиями данных для ассоциации безопасности между мобильным узлом и точкой привязки мобильности (MAP), назначенной компонентом инфраструктуры ААА;
средство отправки упомянутых связанных с полномочиями данных назначенной MAP;
средство приема информации от MAP для завершения ассоциации безопасности; и
средство отправки информации авторизации HMIPv6, в том числе информации ассоциации безопасности, мобильному узлу.
23. Сервер ААА опорной сети по п.22, отличающийся тем, что упомянутый мобильный узел передвигается в гостевой сети, и упомянутое средство отправки информации авторизации HMIPv6 выполнено с возможностью отправки информации по инфраструктуре ААА, связывающей гостевую сеть с опорной сетью мобильного узла.
24. Сервер ААА опорной сети по п.23, отличающийся тем, что сконфигурирован для приема от назначенной MAP информации для завершения ассоциации безопасности, а также информации об адресе связывания, и упомянутое средство отправки информации авторизации HMIPv6 по инфраструктуре ААА сконфигурировано для отправки информации авторизации HMIPv6, в том числе информации назначения MAP, информации об адресе связывания и информации ассоциации безопасности, мобильному узлу.
25. Система поддержки услуги Hierarchical Mobile IP версии 6 (HMIPv6) для мобильного узла, отличающаяся тем, что содержит средство передачи относящейся к HMIPv6 информации аутентификации и авторизации в рамках расширяемого протокола аутентификации (ЕАР) между мобильным узлом и сервером ААА опорной сети по инфраструктуре ААА для аутентификации и авторизации мобильного узла для услуги HMIPv6, причем упомянутая относящаяся к HMIPv6 информация включена в качестве дополнительных данных в стек протоколов ЕАР.
