Способ, система и устройства для поддержки услуг протокола ip мобильной связи, версии 6

Способ, система и устройства для поддержки услуг протокола ip мобильной связи, версии 6

Иллюстрации

Показать все

Реферат

Описание

Область техники, к которой относится изобретение

Настоящее изобретение в общем случае относится к мобильной связи и, в частности, касается поддержки услуг протокола IP мобильной связи, версии 6.

Уровень техники

Протокол IP мобильной связи (MIP) позволяет мобильному узлу изменять точку своего подключения к Интернету с минимальным нарушением процесса обслуживания. Сам по себе протокол MIP не обеспечивает какую-либо специальную поддержку мобильности на различных административных доменах, что ограничивает применимость протокола MIP в крупномасштабных коммерческих проектах.

Протокол MIP версии 6 (MIPv6)[1] позволяет узлам перемещаться в топологии Интернета при сохранении достижимости и текущих соединений с соответствующими узлами. В этом контексте каждый мобильный узел всегда идентифицирован своим адресом независимо от его текущей точки подключения к Интернету по протоколу IPv6. Если мобильный узел находится вне его собственной сети, ему придается временный адрес, который обеспечивает информацию о текущем местоположении этого мобильного узла. Пакеты IPv6, адресованные по собственному адресу мобильного узла, более или менее прозрачным образом направляются по их временному адресу. Протокол MIPv6 позволяет узлам IPv6 кэшировать привязку собственного адреса мобильного узла к его временному адресу, а затем посылать любые пакеты, предназначенные для этого мобильного узла, по временному адресу. С этой целью мобильный узел посылает своему собственному агенту (HA) обновления привязки, и корреспондентские узлы, с которыми он осуществляет связь, каждый раз, когда он перемещается.

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

Кроме того, хотя протокол IPv6 мобильной связи с Интернет может рассматриваться как протокол, обеспечивающий полную мобильность, все же необходимы дополнительные и/или улучшенные механизмы, облегчающие развертывание MIPv6 и открывающие возможность его крупномасштабного применения. Хотя эти механизмы не становятся частью действующего протокола MIPv6, эффективное разворачивание услуг MIPv6 сильно от них зависит. Механизмы, связанные с таким разворачиванием, имеют дело с такими вопросами, как начальная конфигурация мобильного узла (MN), способного действовать по протоколу MIPv6, включая данные конфигурации, такие как префикс собственной сети или собственный адрес, собственный адрес агента и требуемые ассоциации защиты (SA) протокола IPsec или параметры защиты, на которых могут базироваться динамически установленные SA протокола IPsec. Один подход к механизмам, связанным с разворачиванием услуг MIPv6, состоит в усовершенствовании существующей инфраструктуры ААА.

В [2], например, предпринята попытка найти новое применение протоколу Diameter, облегчающему роуминг по протоколу MIPv6 в сетях, отличных от собственного домена. Этот документ идентифицирует информацию, которой, как правило, необходимо обмениваться узлу MN и клиенту ААА в сети, а именно, данные функции MIP, данные EAP, данные о ключах защиты и вложенные данные. Также предлагается новое применение протокола Diameter при обменах этой информацией между клиентом ААА и гостевым сервером ААА (AAAv), между AAAv и гостевым сервером ААА (AAAh) и между узлом HA и инфраструктурой ААА. Хотя в [2] не определен конкретный механизм связи между мобильным узлом и клиентом ААА, упоминается возможность использования протокола PANA [3]. Однако WG протокола PANA определяет объем PANA, так что он не дает возможность передавать упомянутую информацию, относящуюся к MIPv6, что делает предложенное решение неудовлетворительным и неполным.

Другой недостаток решения, предложенного в [2], состоит в том, что в нем требуется, чтобы клиент ААА (и сервер AAAv) понимал способ аутентификации и был знаком с контентом обменов (данные функции MIP, данные EAP, данные о ключах защиты и вложенные данные) между узлом MN и сервером AAAh. При таком решении невозможно использовать известное шифрование между MN и AAAh, и указанные обмены будут открытыми по всему эфирному интерфейсу. Существует риск подслушивания, атаки «посредника» и атак других типов.

Еще один недостаток решения, предложенного в [2], состоит в необходимости поддержания указанных механизмов как в сети доступа, так и в сервере AAAv. Это может затруднить реализацию данного решения, поскольку оператор, который захочет его использовать, зависит от роуминга партнеров, обновляющих свои сети для поддержки этого решения.

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

Сущность изобретения

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

Эти задачи решаются в соответствии с прилагаемой формулой изобретения.

Короче говоря, способ согласно настоящему изобретению обеспечивает поддержку аутентификации и авторизации для MIPv6 путем пересылки информации, относящейся к MIPv6, в сквозной процедуре по всей инфраструктуре ААА между мобильным узлом, посещающим чужую сеть (совершающим роуминг в чужую сеть), и собственной сетью мобильного узла. Информация, относящаяся к MIPv6, как правило, содержит информацию об аутентификации, авторизации и/или конфигурации, пересылаемую по инфраструктуре ААА для упрощения конфигурации мобильного узла и собственного агента, или установления ассоциации защиты MIPv6 между мобильным узлом и собственным агентом, расположенным либо в собственной сети, либо в гостевой сети. Сквозная функция выполняется посредством протокола аутентификации, переносимого по инфраструктуре ААА. Целесообразно, чтобы протокол аутентификации представлял собой расширенный протокол аутентификации, но можно также использовать полностью обновленные протоколы.

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

С помощью настоящего изобретения впервые достигается полное решение для ААА по протоколу MIPv6, в то время как в известном уровне техники достигаются только частичные решения, не согласующиеся друг с другом. Кроме того, ставка на расширения протокола аутентификации типа расширений EAP обеспечивает сбалансированное решение, которое обеспечивает легкое управление и отличается изяществом при минимальных проблемах с обратной совместимостью. Использование протокола EAP делает клиента ААА (и сервер AAAv) недоступным для процедур MIPv6 (то есть это устраняет зависимость от поддержки MIPv6 в гостевой сети) и позволяет действовать просто в качестве транзитного агента (агентов), по меньшей мере, когда агент HA расположен в собственной сети. Другими словами, предложенное решение для аутентификации/авторизации по протоколу MIPv6 является прозрачным для гостевого домена, что является одним из главных преимуществ использования протокола типа EAP. Это открывает возможность применения известного шифрования между узлом MN и AAAh и обеспечить тем самым удовлетворительный уровень защиты при роуминге в чужих сетях с MIPv6. Кроме того, это открывает возможность оператору распространять данное решение, не полагаясь на апгрейды в сетях, где находятся партнеры при роуминге.

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

Согласно другим аспектам изобретения предлагаются система и сервер AAAh для поддержки MIPv6.

Краткое описание чертежей

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

Фиг. 1 - схематическое изображение системы связи для ААА по протоколу MIPv6, в которой можно использовать настоящее изобретение;

Фиг. 2 - диаграмма сигналов инициирования MIPv6 согласно первому примерному варианту настоящего изобретения;

Фиг. 3 - диаграмма сигналов инициирования MIPv6 согласно второму примерному варианту настоящего изобретения;

Фиг. 4 - диаграмма сигналов при плавной передаче управления от одной соты к другой по протоколу MIPv6 согласно примерному варианту настоящего изобретения;

Фиг. 5 - стандартные форматы пакетов EAP;

Фиг. 6 - местоположение и формат атрибута GCA согласно примерному варианту настоящего изобретения;

Фиг. 7 - схематическое изображение системы связи для ААА по протоколу MIPv6 согласно примерному варианту настоящего изобретения;

Фиг. 8 - блок-схема, иллюстрирующая сервер ААА собственной сети согласно примерному варианту настоящего изобретения; и

Фиг. 9 - блок-схема базового примера способа поддержки услуг MIPv6 для мобильного узла согласно настоящему изобретению.

Подробное описание изобретения

В конце этого раздела приведен список сокращений, использованных в данном документе.

Как упоминалось в разделе «Уровень техники», в настоящее время не существует полного решения для поддержки аутентификации и/или авторизации по протоколу MIPv6. Кроме того, стандартный механизм согласно [2] требует, чтобы клиент ААА и сервер AAAv понимали способ аутентификации и были осведомлены о содержимом изменений в данных, относящихся к MIPv6, понимали способ аутентификации и были осведомлены о содержимом изменений в данных, относящихся к MIPv6, между узлом MN и сервером AAAh. При указанном решении невозможно применить известное шифрование между MN и AAAh, и эти изменения оказываются доступными по всему эфирному интерфейсу. Это делает систему очень чувствительной к подслушиванию, атакам посредников и тому подобное.

Эти и другие недостатки преодолеваются настоящим изобретением, согласно которому поддержка аутентификации и авторизации для MIPv6 достигается путем пересылки информации, относящейся к MIPv6, в сквозной процедуре между мобильным узлом, посетившим чужую сеть, и собственной сетью этого мобильного узла через инфраструктуру ААА. Информация, относящаяся к MIPv6, предпочтительно содержит информацию об аутентификации, авторизации и/или конфигурации, которая пересылается через инфраструктуру ААА для немедленной установки или установки в будущем ассоциации защиты (т.е. зависимости защиты) или привязки между мобильным узлом и собственным агентом. Сквозная функция выполняется посредством нового или расширенного протокола аутентификации, который действует прозрачным образом по отношению к гостевому домену.

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

Благодаря использованию сквозного протокола между узлом MN и сервером ААА собственной сети в настоящем изобретении создается решение ААА по протоколу MIPv6, прозрачное для гостевого домена, включая сеть доступа, клиента ААА и сервер ААА в гостевой сети, и для других возможных промежуточных серверов ААА. Это открывает возможность клиенту ААА действовать, например, всего лишь в качестве транзитного агента, что дает существенное преимущество. Также открывается возможность применения известного шифрования между узлом MN и сервером AAAh (например, EAP/TTLS [4]), поскольку эти изменения недоступны через эфирный интерфейс. Это означает, что можно поддерживать удовлетворительный уровень защиты от подслушивания, атак посредников и других атак для мобильных узлов, осуществляющих роуминг в чужих сетях.

На фиг. 8 представлена блок-схема сервера ААА собственной сети согласно предпочтительному варианту изобретения. В этом примере сервер AAAh 34 в базовом варианте содержит модуль 51 присваивания собственного адреса, модуль 52 присваивания собственного агента (HA), администратор 54 информации об авторизации и интерфейс 55 ввода-вывода (I/O). Модуль 51 предпочтительно выполняет присваивание собственного адреса (если собственный адрес не сконфигурирован в мобильном узле и не послан в HA), а модуль 52 может присваивать и/или отменять присваивание подходящего собственного агента (HA). Сервер AAAh 34, как правило, принимает также начальное число ключа и обновление привязки (BU) от мобильного узла. В альтернативном варианте сервер AAAh 34 сам создает начальное число ключа и посылает его в мобильный узел. Модуль 53 ассоциации защиты предпочтительно создает необходимый ключ защиты в соответствии с упомянутым начальным числом и пересылает этот ключ защищенным образом в HA. Собственному агенту (HA) также направляется обновление привязки (BU), так что HA может кэшировать привязку собственного адреса вместе с временным адресом мобильного узла. Сервер AAAh может также принимать информацию, такую как информация протокола IPSec, от HA для окончательного создания ассоциации защиты. Эта информация вместе с другой собранной информацией об авторизации (и/или конфигурации) может затем запоминаться в опционном администраторе 54 информации об авторизации для последующей пересылки в мобильный узел.

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

Термин «ААА» следует рассматривать в его общем значении, принятом в проектах документов Интернет, RFC (запросов на комментарий) и других документах по стандартизации. Как правило, соглашение об аутентификации и ключах защиты для инфраструктуры ААА (авторизация, аутентификации и учет) основана на симметричной криптографии, подразумевающей существование начального «секрета», совместно используемого мобильным узлом и оператором собственной сети или доверенной стороной. В некоторых сценариях и приложениях функция учета в инфраструктуре ААА может, например, быть заблокирована или не реализована. В общем случае инфраструктура ААА включает в себя один или несколько серверов ААА в собственной сети и/или в гостевой сети, а также может включать в себя одного или нескольких клиентов ААА. Также, но не обязательно, возможно наличие одной или нескольких промежуточных сетей, включенных в инфраструктуру ААА.

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

В предпочтительном варианте изобретения используется расширенный протокол аутентификации на основе EAP, создающий расширения EAP, обычно не затрагивая более низкий уровень (уровни) EAP. Обычно это означает, что информация, относящаяся к MIPv6, включается в стек протокола EAP в качестве дополнительных данных, как правило, с помощью одного или нескольких новых атрибутов EAP. Другие решения для реализации указанных атрибутов EAP описаны ниже в разделах «Атрибуты EAP, специализированные применительно к способу» и «Атрибут группового контейнера». После этого в разделе «Примеры протоколов переноса» описываются некоторые примерные решения по протоколу для переноса расширенного протокола аутентификации через инфраструктуру ААА. Общие ссылки делаются на действующие узлы ААА и архитектуру протокола MIPv6, показанную на фиг. 1.

Примеры протоколов переноса

Расширенный протокол аутентификации (например, расширенный EAP) может переноситься, например, между MN (PAC) 10 и клиентом ААА (PAA) 22, то есть тракт (I) на фиг.1, с помощью протокола PANA. В альтернативном варианте для переноса расширенного протокола аутентификации между узлом MN и клиентом ААА можно использовать другие протоколы переноса, связанные с удовлетворительными гарантиями упорядочения на более низком уровне, такие как PPP и IEEE 802,1X [5]. Для систем CDMA2000 стандарта 3GPP2 можно вместо этого использовать инкапсуляцию протокола на уровне канала передачи данных PPP со значением поля протокола, установленным равным С227 (шестнадцатеричное значение) для EAP [6].

В предпочтительном варианте используется приложение протокола каркаса ААА, такое как приложение Diameter, для осуществления связи между клиентом ААА 22 и сервером AAAh 34 в собственной сети/домене 30 мобильного узла 10 через сервер AAAv 24 в гостевой сети/домене 20 (II, III). В одном примерном варианте здесь используется приложение EAP типа Diameter [7] для инкапсулирования расширенного протокола аутентификации в Diameter за клиентом ААА в направлении инфраструктуры ААА, как правило, между клиентом ААА и сервером AAAh. Кроме того, протокол Diameter может использоваться сервером AAAh для факультативного присваивания пакетных фильтров MIP с использованием правил фильтрации MIP для PAA/EP и HA, которые соответствуют точкам форсирования фильтрации, а также для распределения ключей защиты агенту PAA для защиты PANA, и факультативной сигнализации о параметрах качества обслуживания (QoS) и т.д.

Следует отметить, что, хотя приложение Diameter является предпочтительным выбором, иногда вместо него может оказаться целесообразным использовать другое приложение протокола каркаса ААА, такого как RADIUS [8,9], для переноса расширенного протокола аутентификации по тракту II и/или III.

Для осуществления связи между агентом HA 36 в собственной сети и инфраструктурой ААА (IV) для установления ассоциации защиты SA между HA и MN 10, например, посредством обмена ключами защиты, предлагаются две возможности. Во-первых, приложение протокола каркаса ААА можно использовать для пересылки данных MIPv6 через IV. Для этого можно использовать, например, протокол интерфейса AAAh-HA, заданный в приложении MIPv6 типа Diameter [10]. Как поясняется ниже, варианты, в которых для обмена данными ААА и MIPv6 между сервером AAAh 34 и агентом HA 36 используют расширенное или новое приложение Diameter или RADIUS, расширенный новыми атрибутами, также входят в объем настоящего изобретения. Во-вторых, для распределения заранее задаваемых коллективных динамических ключей между узлом MN 10 и агентом HA 36, можно использовать механизм, аналогичный существующему решению в 3GPP2 [11] в сочетании с каркасом IKE [12]. Затем агент HA использует идентификатор ключа KeyID для извлечения из AAAh 34 или создания заранее задаваемого коллективного ключа HA-MN. KeyID создается сервером AAAh и после успешной аутентификации посылается в узел MN, который, в свою очередь, посылает его агенту HA, используя IKE (тракт связи V на фиг. 1).

Примеры комбинаций протоколов между сегментами «мобильный узел MN - клиент ААА - сервер AAAv - сервер AAAh - агент HA» для поддержки MIPv6 согласно настоящему изобретению сведены в Таблицу 1 (см. фиг. 1).

Таблица 1
Тракт связи	Протокол, пересылающий данные MIPv6
(I) MN - клиент ААА	расширенный протокол аутентификации (например, переносимый протоколом PANA или IEEE 802.1X)
(II, III) клиент ААА - AAAv - AAAh	расширенный протокол аутентификации (например, переносимый приложением протокола ААА)
(IV) AAAh - HA	приложение протокола ААА или 3GPP/IKE

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

Атрибуты EAP, специализированные применительно к способу

Согласно одному конкретному варианту настоящего изобретения информацию, относящуюся к MIPv6, пересылают в виде атрибутов EAP на уровне способа EAP стека протокола EAP. Затем определяют новый (расширенный) протокол аутентификации EAP для переноса способа аутентификации MIPv6. Расширенный протокол EAP должен разрешить согласование/форсирование аутентификации MIPv6 и может также поддерживать некоторую вспомогательную информацию, которая облегчает, например, динамическое распределение собственных адресов MN, динамическое распределение HA, распределение ключей защиты между HA и MN и распределение ключей защиты между клиентом PAC и агентом PAA для защиты PANA.

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

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

i) атрибут EAP-TLV вызова MD5

ii) атрибут EAP-TLV ответа MD5

iii) атрибут EAP-TLV запроса собственного адреса MIPv6

iv) атрибут EAP-TLV ответа с собственным адресом MIPv6

v) атрибут EAP-TLV запроса адреса собственного агента MIPv6

vi) атрибут EAP-TLV ответа с адресом собственного агента MIPv6

vii) атрибут EAP-TLV единовременного числа для создания заранее задаваемого коллективного ключа HA-MN

viii) атрибут EAP-TLV идентификатора KeyID для IKE

ix) атрибут EAP-TLV индекса SPI защиты IPSec для HA-MN

x) атрибут EAP-TLV времени действия ключа IPSec для HA-MN

xi) атрибут EAP-TLV единовременного числа для создания заранее задаваемого коллективного ключа для PAC-PAA

xii) атрибут EAP-TLV собственного адреса MIPv6

xiii) атрибут EAP-TLV заранее задаваемого коллективного ключа для HA-MN

xiv) атрибут EAP-TLV протокола IPSec для HA-MN

xv) атрибут EAP-TLV криптографии IPSec для HA-MN

xvi) атрибут EAP-TLV для обновления-привязки-MIP

xvii) атрибут EAP-TLV для подтверждения-привязки-MIP

С помощью поднабора или всех этих атрибутов протокол EAP, вдобавок к основной информации об аутентификации IPv6, может нести вспомогательную информацию, относящуюся к MIPv6, что дает значительные преимущества. Вспомогательная информация, относящаяся к MIPv6, может, например, содержать запросы на динамическое распределение собственных адресов MN, динамическое распределение собственных агентов, а также единовременные числа/начальные числа для создания необходимых ключей защиты.

Механизм аутентификации расширенного протокола EAP согласно настоящему изобретению может использовать, например, аутентификацию вызова MD5-Challenge, но в объем изобретения входят также иные типы протоколов. Нижеследующие атрибуты EAP-TLV могут быть заданы для аутентификации MIPv6 в случае реализации через аутентификацию вызова MD5-Challenge:

i) Атрибут EAP-TLV вызова MD5

Он представляет восьмиразрядную строку, созданную случайным образом сервером AAAh и посланную в MN для вызова MD5.

ii) Атрибут EAP-TLV ответа MD5

Он представляет восьмиразрядную строку, созданную в результате действия хэш-функции MD5 с коллективным секретным ключом между сервером AAAh и узлом MN.

В случае, когда необходимо переслать информацию, относящуюся к MIPv6, которая облегчает динамическое распределение собственных адресов MN, то нижеследующие атрибуты EAP-TLV могут быть определены, например, следующим образом:

iii) Атрибут EAP-TLV запроса собственного адреса MIPv6

Он представляет запрос на динамически распределенный собственный адрес MIPv6 для аутентифицированного узла MN. Он запрашивается из AAAh узлом MN, когда MN первоначально запрашивает аутентификацию и данную услугу MIPv6. Этот атрибут EAP обычно определяется как необязательный атрибут, когда узел MN уже имеет присвоенный ранее собственный адрес, например, во время плавных передач управления от одной соты к другой.

iv) Атрибут EAP-TLV ответа с собственным адресом MIPv6

Он представляет динамически распределенный собственный адрес MIPv6 для аутентифицированного узла MN. Узел MN уведомляется о нем из AAAh, когда MN, запросивший собственный адрес, успешно аутентифицирован. Этот атрибут обычно является необязательным, когда узел MN уже имеет ранее присвоенный собственный адрес, например, во время плавных передач управления от одной соты к другой по протоколу MIPv6.

Для динамического распределения HA можно использовать следующие примерные атрибуты EAP-TLV:

v) Атрибут EAP-TLV запроса адреса собственного агента MIPv6

Он представляет запрос адреса динамически распределенного HA для узла MN при его успешной аутентификации. Запрос производится из AAAh узлом MN, когда MN первоначально запрашивает аутентификацию и данную услугу MIPv6. В случае, когда распределение HA вот-вот наступит, например, когда для распределения HA используется способ динамического обнаружения HA по протоколу MIPv6, или когда узел MN уже имеет ранее присвоенный HA (например, во время плавных передач управления от одной соты к другой по протоколу MIPv6), этот атрибут обычно задается в виде опции.

vi) Атрибут EAP-TLV ответа с адресом домашнего агента MIPv6

Он представляет адрес динамически распределенного агента HA для аутентифицированного MN. Узел MN уведомляется о нем из AAAh, когда MN первоначально запрашивает аутентификацию и данную услугу MIPv6. Поскольку в протоколе MIPv6 имеется способ динамического обнаружения собственного агента для распределения собственных агентов, этот атрибут обычно задается в виде опции. Это имеет место и в случае, когда MN уже имеет ранее присвоенный HA, например, во время плавных передач управления от одной соты к другой по протоколу MIPv6.

Последующие примерные атрибуты EAP-TLV могут быть определены для распределения ключей защиты между HA и MN:

vii) Атрибут EAP-TLV единовременного числа для создания заранее задаваемого коллективного ключа HA-MN

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

viii) Атрибут EAP-TLV идентификатора KeyID для IKE.

Он представляет полезную нагрузку ID, определенную в [13]. KeyID создается сервером AAAh и посылается в узел MN после успешной аутентификации. KeyID включает в себя несколько октетов, которые информируют HA о том, как извлечь из AAAh (или создать) заранее задаваемый коллективный ключ для HA-MN. Этот атрибут обычно определяется как необязательный, и в общем случае в нем нет необходимости, когда узел MN не представил единовременное число для создания ключа HA-MN, то есть действительный заранее задаваемый коллективный ключ для HA-MN уже существует, например, во время плавных передач управления от одной соты к другой по протоколу MIPv6. Обычно в нем нет необходимости в случае, когда заранее задаваемый коллективный ключ для HA-MN передается сервером AAAh агенту HA через интерфейс AAAh-HA, определенный в [10] (или при использовании, например, любого из других протоколов, упомянутых выше в разделе «Примеры протоколов переноса»).

ix) Атрибут EAP-TLV индекса SPI защиты IPSec для HA-MN

Он представляет индекс параметра защиты для IPSec между HA и MN. Этот атрибут создается агентом HA и передается в MN в том случае, когда заранее задаваемый коллективный ключ HA-MN передается сервером AAAh агенту HA через интерфейс AAAh-HA, определенный в [10] (или при использовании, например, любого из других протоколов, упомянутых выше в разделе «Примеры протоколов переноса»). Этот атрибут обычно является необязательным, и в нем, как правило, нет необходимости, когда узел MN не предоставил единовременное число для создания заранее задаваемого коллективного ключа для HA-MN, то есть действительный заранее задаваемый коллективный ключ для HA-MN уже существует, например, во время плавных передач управления от одной соты к другой по протоколу MIPv6. В нем также нет необходимости, когда интерфейс AAAh-HA не используется.

x) Атрибут EAP-TLV времени действия ключа IPSec для HA-MN

Он представляет время действия ключа для IPSec между HA и MN. Этот атрибут создается агентом HA и передается в MN в том случае, когда сервер AAAh пересылает агенту HA заранее задаваемый коллективный ключ HA-MN через интерфейс AAAh-HA, определенный в [10] (или при использовании, например, любого из других протоколов, упомянутых выше в разделе «Примеры протоколов переноса»). Этот атрибут обычно является необязательным, и в нем, как правило, нет необходимости, когда узел MN не предоставил единовременное число для создания заранее задаваемого коллективного ключа для HA-MN, то есть действительный заранее задаваемый коллективный ключ для HA-MN уже существует, например, во время плавных передач управления от одной соты к другой по протоколу MIPv6. В нем, как правило, также нет необходимости, когда интерфейс AAAh-HA не используется.

В случае использования протокола PANA для переноса протокола EAP между узлом MN и клиентом ААА, для распределения ключей защиты между MN/PAC и клиентом ААА/агентом PAA для защиты PANA может быть определен следующий примерный атрибут EAP-TLV:

xi) Атрибут EAP-TLV единовременного числа для создания заранее задаваемого коллективного ключа для PAC-PAA

Он представляет восьмиразрядную строку, созданную случайным образом узлом MN/клиентом PAC, как начальное число для создания заранее задаваемого коллективного ключа между MN/PAC и клиентом ААА/агентом PAA. Узел MN/клиент PAC может создать внутри заранее задаваемый коллективный ключ PAC-PAA, используя подходящий алгоритм хеширования на комбинации этого единовременного числа и коллективного ключа между MN и AAAh. С помощью этого атрибута может быть обеспечен удовлетворительный уровень защиты PANA.

Наконец, для специальных целей MIPv6 могут быть заданы следующие необязательные атрибуты EAP-TLV:

xii) Атрибут EAP-TLV собственного адреса MIPv6

Он представляет динамически распределенный собственный адрес MIPv6 для аутентифицированного узла MN. Агент HA уведомляется о нем из сервера AAAh, чтобы присвоить собственный адрес MIPv6 в НА, когда запросивший его узел MN успешно аутентифицирован.

xiii) Атрибут EAP-TLV заранее задаваемого коллективного ключа для HA-MN

Он представляет динамически созданный заранее задаваемый коллективный ключ между HA-MN. Агент HA уведомляется в нем из AAAh, когда узел MN запрашивает аутентификацию и данную услугу MIPv6. Сервер AAAh может создать внутри заранее задаваемый коллективный ключ для HA-MN, используя подходящий алгоритм хэширования на комбинации единовременного числа, заданного атрибутом EAP-TLV единовременного числа для создания заранее задаваемого коллективного ключа для HA-MN и коллективного ключа между MN и AAAh. Этот атрибут является необязательным, когда уже существует действительный заранее задаваемый коллективный ключ для HA-MN.

xiv) Атрибут EAP-TLV протокола IPSec для HA-MN

Он представляет протокол IPSec (например, ESP или AH) между HA-MN. Узел MN информируется о нем в случае, когда сервер AAAh пересылает агенту HA заранее задаваемый коллективный ключ для HA-MN. Этот атрибут не является обязательным, и обычно в нем нет необходимости, когда узел MN не представил единовременное число для создания заранее задаваемого коллективного ключа для HA-MN, то есть действительный заранее задаваемый коллективный ключ HA-MN уже существует, например, во время плавных передач управления от одной соты к другой по протоколу MIPv6.

xv) Атрибут EAP-TLV криптографии IPSec для HA-MN

Он представляет криптографический алгоритм для IPSec между HA-MN. Узел MN информируется об этом атрибуте в том случае, когда сервер AAAh пересылает агенту HA заранее задаваемый коллективный ключ HA-MN. Этот атрибут не является обязательным, и обычно в нем нет необходимости, когда узел MN не представил единовременное число для создания заранее задаваемого коллективного ключа для HA-MN, то есть действительный заранее задаваемый коллективный ключ HA-MN уже существует, например, во время плавных передач управления от одной соты к другой по протоколу MIPv6.

xvi) Атрибут EAP-TLV обновления-привязки-MIP

Он представляет пакет обновления привязки, созданный узлом MN. Он направляется агенту HA через сервер AAAh из узла MN в обменах данными по аутентификации и авторизации. Этот атрибут не является обязательным, и обычно в нем нет необходимости, когда узел MN посылает пакет обновления привязки непосредственно агенту HA.

xvii) Атрибут EAP-TLV подтверждения-привязки-MIP

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

В приведенной ниже Таблице 2 представлена сводная матрица описанных примерных значений EAP-TLV для пересылки информации, относящейся к MIPv6.

Таблица 2

Значения длины типа ЕАР, относящиеся к MIPv6	Источник	Адресат	Назначение
атрибут EAP-TLV вызова MD5	AAAh	MN	Вызов MN
атрибут EAP-TLV ответа MD5	MN	AAAh	обеспечение ответа на вызов
атрибут EAP-TLV запроса собственного адреса MIPv6	MN	AAAh	запрос собственного адреса MN
атрибут EAP-TLV ответа с собственным адресом MIPv6	AAAh	MN	присвоение собственного адреса MN
атрибут EAP-TLV запроса адреса собственного агента MIPv6	MN	AAAh	запрос адреса НА
атрибут EAP-TLV ответа с адресом собственного агента MIPv6	AAAh	MN	присвоение адреса НА
атрибут EAP-TLV единовременного числа для создания заранее задаваемого коллективного ключа HA-MN	MN	AAAh	начальное число для ключа HA-MN
атрибут EAP-TLV идентификатора KeyID для IKE	AAAh	MN	информация для получения от AAAh заранее задаваемого коллективного ключа HA-MN
атрибут EAP-TLV индекса SPI защиты IPSec для HA-MN	HA	MN через AAAh	присвоение SPI
атрибут EAP-TLV времени действия ключа IPSec для HA-MN	HA	MN через AAAh	присвоение времени действия ключа IPSec
атрибут EAP-TLV единовременного числа для создания заранее задаваемого коллективного ключа для PAC-PAA	MN	AAAh	начальное число для ключа PAC-PAA
атрибут EAP-TLV собственного адреса MIPv6	HA	HA	присвоение собственного адреса MN
атрибут EAP-TLV заранее задаваемого коллективного ключа для HA-MN	HA	HA	присвоение ключа HA-MN
атрибут EAP-TLV протокола IPSec для HA-MN	HA	MN через AAAh	присвоение протокола IPSec
атрибут EAP-TLV криптографии IPSec дл