Описание
Область техники, к которой относится изобретение
Настоящее изобретение в общем случае относится к мобильной связи и, в частности, касается поддержки услуг протокола 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).
Предполагается, что при пересылке чувствительной информации, такой как ключ (ключи) защиты, используют такие меры защиты, как шифрование или защита целостности источника.
Атрибуты 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
На блок-схемах передачи сигналов (фиг.2, 3 и 4) представлены примерные схемы обработки инициирования MIPv6 и плавной передаче управления от одной соты к другой согласно изобретению.
На этих схемах показана пересылка информации, относящейся к MIPv6, реализованная с использованием вышеописанных примерных атрибутов EAP-TLV между MN, клиентом ААА, AAAh и HA. Здесь термин «EAP/MIPv6» относится к новому расширенному протоколу EAP, который используют для пересылки информации, относящейся к MIPv6, через инфраструктуру ААА в предпочтительных вариантах изобретения. Показанные примеры относятся к ААА для MIPv6, где в качестве протоколов переноса используется комбинация протоколов PANA и Diameter. На блок-схеме по фиг. 2 показано инициирование MIPv6 с использованием интерфейса AAAh-HA согласно [10] для обмена заранее задаваемым коллективным ключом для HA-MN. На фиг. 3 показан другой вариант механизма инициирования MIPv6, где для обмена заранее задаваемым коллективным ключом HA-MN используется KeyID для IKE. Потоки сигнализации на фиг. 4 описывают плавную передачу управления от одной соты к другой по протоколу MIPv6 согласно примерному варианту изобретения.
Атрибут группового контейнера
В другом варианте настоящего изобретения информация, относящаяся к MIPv6, переносится в атрибуте EAP группового контейнера, который целесообразно использовать вместе с любым методом EAP, включенным в какой-либо пакет EAP. Таким образом, протокол EAP дополняется атрибутом группового контейнера (называемым также GCA), который можно использовать для переноса данных, не относящихся к EAP, в частности, данных, относящихся к MIPv6, между MN 10 и AAAh 34. Это позволяет узлу MN и серверу AAAh осуществлять связь, прозрачную для гостевого домена 20, включая сеть доступа, клиента ААА и сервер AAAv 24. Таким образом, как и в вышеописанном случае с атрибутами EAP-TLV, специализированными применительно к способу, инфраструктура ААА используется для поддержки функций, относящихся к MIPv6, с обеспечением прозрачности для гостевого домена. Такое решение может, например, поддерживать динамическое присваивание HA в собственной сети (включая префикс собственной сети); распределение мандатов MN-HA; инкапсулирование сообщений MIPv6; единый аутентифицирующий объект для доступа к сети и MIPv6; и/или динамическое присваивание собственных адресов с их хранением.
При использовании атрибута группового контейнера протокол EAP целесообразно использовать в качестве переносчика данных, относящихся к MIPv6, без создания нового способа EAP. Однако в другом варианте вводится атрибут группового контейнера в одном или нескольких способах EAP на уровне способа стека протокола. Тем самым определяется новый способ EAP для пересылки данных, относящихся к MIPv6, и атрибут группового контейнера используется только в этом новом способе EAP. Другими словами, атрибут группового контейнера может представлять собой специфичный способ, в некотором смысле аналогичный тому, который описан в связи с атрибутами EAP-TLV. Как и раньше, EAP переносится в протоколе каркаса ААА, таком как приложение EAP Diameter [7] или RADIUS [8,9] между клиентом ААА 22 и сервером AAAh 34. Однако также предлагается использовать новое/расширенное приложение Diameter (или RADIUS, дополненное новыми атрибутами) для обмена данными ААА и MIPv6 между сервером AAAh 34 и агентом HA 36. Это приложение Diameter может представлять собой расширенную версию существующего приложения Diameter, например, приложение EAP Diameter [7] или новое приложение Diameter. Это новое/расширенное новое приложение Diameter (или расширенное приложение RADIUS) называется далее «приложение Diameter MIPv6». Следует подчеркнуть, что эта ссылка используется только для упрощения и не исключает использование расширенного приложения RADIUS или других способов для связи AAAh-HA, включая механизмы, упомянутые выше в разделе «Примеры протоколов переноса».
Далее главным образом с использованием в качестве примера протокола EAP и со ссылками на фиг. 1 описываются предпочтительные способы выполнения процедуры аутентификации, включая присваивание собственных агентов и собственных адресов, с использованием атрибутов группового контейнера согласно настоящему изобретению.
В ходе процедуры аутентификации узел MN 10 указывает серверу AAAh 34 посредством атрибута группового контейнера, что ему необходимо иметь HA 36, присвоенный в собственной сети 30. Далее рассматриваются три следующих случая.
А) Узел MN уже имеет действительный собственный адрес.
В) Используется динамическое присваивание собственных адресов с поддержкой их хранения.
С) Используется автоматическая конфигурация собственных адресов без поддержки их хранения.
Если узел MN 10 уже имеет собственный адрес (А), он посылает его в AAAh 34 вместе с запросом адреса собственного агента. Если AAAh определяет, что собственный адрес действителен, он выбирает HA 36 и создает мандаты MN-HA, например, заранее задаваемый коллективный ключ или данные, из которых можно получить заранее задаваемый коллективный ключ. Собственный адрес узла MN и созданные мандаты MN-HA могут быть посланы, например, выбранному HA через приложение Diameter MIPv6. Адрес выбранного HA и созданные мандаты (или данные, из которых могут быть получены созданные мандаты) посылают в узел MN через расширенный протокол аутентификации, например, расширенный протокол EAP. Если, например, заранее задаваемый коллективный ключ послан в узел MN, он должен быть защищен (зашифрован и обеспечен защитой целостности) ключами, полученными из зависимости защиты между AAAh и MN (например, сеансовыми ключами, созданными в ходе процедуры аутентификации). В противном случае, заранее задаваемый коллективный ключ не должен пересылаться в явном виде. Вместо этого, можно послать фрагмент данных, из которого можно получить заранее задаваемый коллективный ключ (или другие мандаты) на основе зависимости защиты MN-AAAh, например, единовременное число, (например, параметр RAND, который вводится в алгоритм аутентификации AKA или GSM, если используется EAP AKA [14] или EAP SIM [15]). Если для мандатов применяется криптографическая защита, то возможно будет удобнее использовать аналогичную защиту для адреса HA и собственного адреса.
Когда заканчивается аутентификация доступа к сети, и узлу MN разрешается доступ к сети после сервера доступа (например, WLAN AP или маршрутизатор доступа) узел MN может установить SA для протокола IPSec к присвоенному HA через процедуры IKEv1 или IREv2 на основе полученных мандатов. Эта процедура и последующий обмен обновление-привязка/подтверждение (BU/BA) выполняется с использованием стандартных механизмов IKE MIPv6. Если узел MN либо вообще не содержит собственный адрес, либо содержит собственный адрес, который больше не действителен (например, из-за изменения нумерации собственной сети MIPv6) в запросе собственного агента, то узлу MN должен быть присвоен собственный адрес. Для этого в настоящем изобретении предлагаются механизмы для динамического присваивания собственных адресов с поддержкой хранения (В) или для автоматической конфигурации собственных адресов (С).
Настоящее изобретение разрешает динамическое распределение собственных адресов (В) с поддержкой их хранения, в результате которого сервер AAAh 34 присваивает узлу MN 10 собственный адрес. Сервер AAAh также создает мандаты MN-HA, которые он предпочтительно посылает выбранному агенту HA 36 вместе с присвоенным собственным адресом через приложение Diameter MIPv6. Сервер AAAh также посылает присвоенный собственный адрес вместе с адресом присвоенного HA и созданные мандаты (или данные, из которых можно получить созданные мандаты) в узел MN через расширенный протокол аутентификации по изобретению, например, используя расширенный протокол EAP. Как и в случае (А), мандаты MN-HA либо защищаются перед посылкой по расширенному протоколу аутентификации, либо, в альтернативном варианте, вместо действительных мандатов посылаются данные, из которых эти мандаты могут быть получены (например, единовременное число). После завершения аутентификации доступа узел MN может установить SA для IPSec и выполнить обмен BU/BA c присвоенным HA, используя стандартные механизмы IKE и MIPv6.
В случае, когда используется автоматическая конфигурация собственных адресов без поддержки их хранения, процедура зависит от количества полных обходов выбранного способа EAP. В ответ на запрос на HA 36 сервер AAAh 34 возвращает адрес HA вместе с мандатами (или данными, из которых могут быть получены мандаты) в узел MN 10. Узел MN, как правило, использует префикс принятого адреса HA для построения собственного адреса. Если процедура EAP не закончена, то есть, если адрес HA был переправлен в пакете запроса EAP, а не в пакете успешного выполнения EAP, то узел MN посылает на сервер AAAh свой собственный адрес. Затем AAAh посылает присвоенному агенту HA принятый собственный адрес вместе с мандатами. После этого агент HA должен выполнить DAD для принятого собственного адреса в своей подсети. Если обнаружение дублированного адреса (DAD) оказалось успешным, узел MN и агент HA смогут впоследствии установить SA для IPSec и обменяться пакетами BU/BA, используя стандартные механизмы IKE и MIPv6.
Если вместо этого узел MN принимает адрес HA в конечном пакете процедуры EAP (т.е. в пакете успешного выполнения EAP), он не сможет переслать на сервер AAAh вновь созданный собственный адрес. Решить эту проблему недостаточного количества полных обходов EAP можно, дав указание серверу AAAh увеличить количество полных обходов EAP с использованием пакетов запроса/ответа с уведомлением EAP для разрешения пересылки атрибута группового контейнера.
Главным преимуществом описанных механизмов является то, что они упрощают конфигурацию как узла MN 10, так и агента HA 36. Узел MN может улучшить свои параметры конфигурации доступа к сети (идентификатор NAI и зависимость защиты MN-AAAh), и тогда специальная конфигурация MIPv6 не потребуется. Агент HA не будет нуждаться в конфигурации, привязанной к MN, поскольку достаточно иметь зависимость защиты для HA-AAAh. Сервер AAAh 34 может эффективно сформировать единый аутентифицирующий объект как для доступа к сети, так и для MIPv6 (хотя в HA может еще выполняться аутентификация IKE на основе данных, полученных от сервера AAAh).
Если действительные ассоциации защиты MN-HA (например, SA для IPSec) уже имеются, то узлу MN 10 нет необходимости запрашивать адрес HA у сервера AAAh 34. Вместо этого он может уменьшить общую задержку доступа путем инкапсулирования BU в атрибуте группового контейнера и послать его на сервер AAAh посредством расширенного протокола аутентификации. Сервер AAAh предпочтительно инкапсулирует BU в сообщении приложения Diameter MIPv6 и посылает его агенту HA 36, указанному адресом места назначения BU.
Агент HA реагирует, выдавая подтверждение BA, и сервер AAAh передает ответ в узел MN. Инкапсулированные BU и BA защищены связями SA для IPSec для MN-HA. Согласно предпочтительному варианту сервер AAAh проверяет действительность адреса HA и отсутствие изменения нумерации в собственной сети MIPv6 перед посылкой BU агенту HA. Если адрес HA недействителен, то сервер AAAh обычно сообщает узлу MN об ошибке и присваивает HA, как было описано выше, то есть сервер AAAh посылает в узел MN адрес HA, мандаты (или данные, из которых можно получить мандаты) и возможно собственный адрес и т.д.
Приложение Diameter MIPv6 также можно иногда использовать для пересылки данных учета, созданных в HA 36. Это может оказаться полезным, например, когда используется обратное туннелирование (т.е. когда весь трафик в и от узла MN пересылается через HA и направляется между MN и HA), и оператор собственной сети хочет иметь возможность проверки данных учета, полученных от сервера AAAv 24.
Далее более подробно описываются некоторые примерные варианты реализации атрибута группового контейнера (GCA) согласно настоящему изобретению.
Целесообразно, чтобы атрибут GCA был доступен для всех способов и мог быть включен в любое сообщение EAP, в том числе сообщения об успешном выполнении/отказе EAP. Это подразумевает, что он должен являться частью уровня EAP, а не уровня способа EAP (см. [16]). В связи с этим важным вопросом для рассмотрения является обратная совместимость применительно к узлу MN и аутентификатору EAP (обычно это объект EAP в сервере доступа к сети (NAS)). Использование атрибута группового контейнера в вышеуказанных примерах предполагает, что в протокол EAP введен новый атрибут таким образом, что он оказывается обратно совместимым и прозрачным для аутентификатора EAP. Введение GCA с этими свойствами требует ряда специальных соображений, которые приведены в последующих параграфах.
Обратимся к фиг. 5, где показаны текущие форматы пакета EAP [6,16]. На фиг. 5А показан общий формат пакета EAP, причем заголовок уровня EAP содержит поля кода, идентификатора и длины, а также поле необязательных данных. Присвоенные коды EAP определены в виде: 1 = Запрос, 2 = Ответ, 3 = Успешное выполнение и 4 = Отказ. Формат пакетов Успешное выполнение/Отказ EAP (код = 3/4) и пакетов Запрос/Ответ EAP (код = 1/2) соответственно показаны на фиг. 5В. Присвоенные типы EAP: 1 = Идентичность, 2 = Уведомление, 3 = Нет подтверждения, 4-...= Способы аутентификации.
Формат GCA может, например, представлять собой двухбайтовый индикатор длины GCA, за которым следует индикатор получателя GCA и полезная нагрузка GCA. Индикатор получателя GCA указывает, на какой внутренний объект должен послать полезную нагрузку принятого GCA модуль EAP (то есть этот индикатор соответствует полю следующего заголовка/протокола в заголовке IP или номеру порта в заголовках UDP и TCP). Полезная нагрузка GCA представляет собой групповую часть данных, не интерпретированных уровнем EAP. Отсутствие GCA может быть указано, например, путем установки в ноль индикатора длины GCA.
Для обеспечения обратной совместимости атрибут GCA следует включить в пакеты EAP таким образом, чтобы он был прозрачным для транзитных аутентификаторов EAP. Транзитный аутентификатор EAP является аутентификатором EAP, находящимся в сервере NAS, который передает пакеты EAP между узлом MN и внутренним сервером аутентификации EAP (сервер ААА). Транзитное свойство аутентикатора EAP выражается в передаче пакетов EAP на основе заголовка уровня EAP, то есть полей кода, идентификатора и длины в начале пакетов EAP. Это подразумевает, что требуемая прозрачность и, следовательно, обратная совместимость может быть достигнута, если поместить GCA после заголовка уровня EAP, то есть после полей кода, идентификатора и длины.
Однако аутентификатор EAP, как правило, должен также проверять поле типа (следующим за заголовком уровня EAP) пакетов ответа EAP, чтобы идентифицировать ответные пакеты EAP с данными по идентичности, из которых можно извлечь идентификатор NAI, необходимый для маршрутизации ААА. Когда аутентификатор EAP идентифицирует ответный пакет EAP с данными идентичности, он выделяет идентификатор NAI из поля данные-тип, следующем за полем типа. Таким образом, размещение атрибута GCA непосредственно после заголовка уровня EAP (чтобы он был прозрачен для аутентификатора EAP) допустимо только в пакетах запроса EAP. Следовательно, целесообразно располагать атрибут GCA после поля типа или даже после поля данные-тип (возможно с завершающим нулем).
Размещение атрибута GCA непосредственно после поля типа позволяет использовать GCA во всех пакетах ответа EAP, но не в ответных пакетах EAP с данными идентичности. Использование атрибута GCA в ответных пакетах EAP с данными идентичности запрещено, поскольку аутентификатору EAP необходимо выделить NAI из поля данные-тип этих пакетов, причем предполагается, что существующий аутентификатор EAP обнаружит это поле непосредственно после поля типа. Это может ограничить использование GCA, учитывая, что EAP, как правило, имеет совсем немного полных обходов. Возможно размещение атрибута GCA после поля данные-тип, завершающегося нулем, в ответном пакете EAP с данными идентичности, при сохранении его положения после поля типа в других пакетах EAP.
Однако часто желательно, чтобы положение атрибута GCA можно было использовать согласованно во всех пакетах EAP. Это следует из вышеизложенного обсуждения, касающегося того, что положение, в котором может находиться атрибут GCA во всех пакетах EAP с обеспечением обратной совместимости, соответствует концу пакета, как бы, в виде трейлера. Однако такое положение GCA может вызвать проблемы для тех пакетов EAP, которые не имеют индикаторов длины в явном виде для параметра (параметров) данные-тип, а полагаются на поле длины в заголовке уровня EAP. Для таких пакетов в общем случае невозможно различить атрибут GCA и поле данные-тип.
Для решения этой проблемы согласно конкретному предпочтительному варианту GCA предлагается изменить на противоположный порядок следования индикатора длины GCA, индикатора получателя GCA и полезной нагрузки GCA, так чтобы индикатор длины GCA появлялся последним. Благодаря размещению атрибута GCA в конце пакета EAP два последних октета пакета EAP (чья длина указана в поле длины в заголовке уровня EAP) всегда будут в индикаторе длины GCA. Если индикатор длины GCA установлен равным нулю, то индикатор получателя GCA появляется перед индикатором длины GCA, а полезная нагрузка GCA (размер которой определяется индикатором длины GCA) располагается перед индикатором получателя GCA. Таким путем можно всегда идентифицировать атрибут GCA пакета EAP и отличить GCA от поля данные-тип, когда использование GCA еще остается прозрачным для транзитного аутентификатора EAP. Местоположение и форма предпочтительного GCA согласно настоящему изобретению показано на фиг. 6. Местоположение атрибута GCA в пакете EAP общего формата показано на фиг. 6А. Атрибут GCA установлен в виде трейлера в конце пакета. Предложенный формат GCA с индикатором длины GCA, расположенным последним, после полезной нагрузки GCA и индикатора получателя GCA, показан на фиг. 6В.
Обратная совместимость с вариантом GCA по фиг. 6 дополнительно предполагает, что аутентификатор EAP не пытается извлечь информацию из пакетов запрос/ответ EAP (кроме заголовка уровня EAP и идентификатора NAI) и что он допускает, что поле длины в пакетах «успешное выполнение/отказ» указывает значение, большее 4.
Альтернативным вариантом решения проблемы обратной совместимости является использование пакетов тестового запроса/ответа GCA, то есть новых пакетов EAP с заново определенными значениями поля типа, для определения того, поддерживает ли узел MN атрибут GCA. До или после начального обмена пакетами EAP запроса/ответа по данным идентичности аутентификатор EAP, поддерживающий GCA, посылает в узел MN пакет тестового запроса GCA протокола EAP, то есть пакет запроса EAP с выделенным значением типа (Равноправный конечный автомат EAP в [17] указывает, что возможны оба альтернативных варианта времени посылки). Если узел MN поддерживает атрибут GCA, он реагирует, выдавая пакет тестового ответа GCA протокола EAP. В противном случае, MN интерпретирует пакет тестового запроса GCA протокола EAP как запрос на использование неизвестного способа EAP, и поэтому узел MN выдает в ответ пакет «Нет подтверждения» EAP. На основе ответа от MN аутентификатор EAP определяет, поддерживает ли MN атрибут GCA.
Узел MN, поддерживающий GCA, может определить, поддерживает ли аутентификатор EAP атрибут GCA, исходя из наличия или отсутствия пакета тестового запроса теста GCA протокола EAP. Если пакет тестового запроса GCA протокола EAP принят, когда это ожидалось, то есть до или после обмена запросом/ответом с данными идентичности EAP, то предполагается, что аутентификатор EAP поддерживает атрибут GCA. В противном случае, узел MN делает вывод, что аутентификатор EAP не поддерживает атрибут GCA.
Если как узел MN, так и аутентификатор EAP поддерживают атрибут GCA, он может быть размещен после заголовка уровня EAP во всех последующих пакетах EAP (при исходном порядке компонентов GCA). В противном случае, GCA может все еще содержаться в пакетах EAP, что позволяет поддерживать обратную совместимость так, как было описано выше.
Имеется ряд ограничений для описанного альтернативного варианта решения проблемы обратной совместимости. Во-первых, один полный обход аутентификатора MN-EAP тратится впустую. Кроме того, если обмен пакетами тестового запроса/ответа GCA протокола EAP осуществляется после начального обмена пакетами запроса/ответа с данными идентичности EAP, то атрибут GCA нельзя использовать в пакете ответа с данными идентичности EAP. Для этого варианта также может потребоваться, чтобы аутентификатор EAP (возможно сервер NAS) использовал модифицированную версию EAP, такую как EAPv2. Соответственно, хотя возможны и другие альтернативные варианты, предпочтительным, как правило, является расположение атрибута GCA в пакетах EAP, показанное на фиг. 6, что открывает возможность обеспечения обратной совместимости с аутентификаторами EAP для всех пакетов EAP.
Если количество полных обходов EAP недостаточно для данных, которыми обмениваются в GCA, то сервер AAAh может увеличить количество полных обходов EAP посредством обменов запросом/ответом для уведомления EAP в целях пересылки атрибута GCA.
Если атрибут GCA специализирован применительно к способу, то GCA не вызывает каких-либо проблем, связанных с обратной совместимостью, поскольку в этом случае он обычно является частью поля данные-тип. В проекте Интернет [18] от февраля 2004 года предложена авторизация и конфигурация по протоколу MIPv6 на основе инфраструктуры ААА. Необходимое взаимодействие между сервером ААА собственного провайдера и мобильным узлом для протокола MIPv6 реализуется путем использования защищенного протокола EAP для пересылки информации для согласования протокола MIPv6 вместе с данными аутентификации. Однако, в то время как описанный атрибут группового контейнера согласно настоящему изобретению может быть интегрирован в процедуры EAP, данные MIPv6 согласно [18] добавляются на второй фазе. Другое преимущество описанного здесь решения относится к механизмам защиты. Согласно настоящему изобретению можно улучшить зависимость защиты MN-AAAh для обеспечения нераскрываемости мандатов. С другой стороны, в [18] для защиты мандатов полагаются на защищенный EAP. Кроме того, из работы [18] вытекает, что добавляется количество полных обходов и увеличивается общее время задержки при доступе к сети, в то время как предложенный здесь механизм дает возможность даже уменьшить общее время задержки при доступе к сети.
Расширенное решение - локальный собственный агент
На фиг. 7 схематически показан другой примерный вариант механизма поддержки мобильности по настоящему изобретению, в котором в гостевой сети 20 устанавливается так называемый «локальный собственный агент» 26. Как будет видно из последующего описания, локальный HA 26 можно использовать как дополнение к HA 36 в собственной сети 30 наиболее выгодным образом. Агент HA в собственной сети и локальный агент HA в гостевой сети, как правило, используют не одновременно, а по одному в любой момент времени.
Этот вариант является расширением решения, описанного со ссылками на фиг. 1 (далее это решение также называют «базовое решение»), где могут использоваться, например, атрибуты EAP, специализированные применительно к способу, или атрибут группового контейнера, причем требуется поддержка MIPv6 в сервере AAAv 24. Целевым сценарием для этого расширенного решения является случай, когда в собственной сети 30 нет HA 36. Вместо этого узлу MN 10 с роумингом динамически присваивается локальный HA 26 в гостевом домене 20. Базовое решение вновь используется (за исключением того, что не используется связь (IV) AAAh-HA в случае, когда в собственной сети нет HA), и, кроме того, расширяется приложение Diameter MIPv6, так чтобы его можно было использовать между AAAh 34 и AAAv 24 (VI) для разрешения присваивания локального HA 26 в гостевом домене 20. Приложение Diameter MIPv6 также используется между AAAv 24 и локальным HA 26 (VII).
Таким образом, тракт между MN 10 и локальным HA 26 будет представлять собой тракт «с двусторонним движением» (тракт проходит ветвь AAAv-AAAh в обоих направлениях): MN ↔ клиент ААА ↔ AAAv ↔ AAAh ↔ AAAv ↔ локальный HA (I, II, III, VI, VII). Однако передача сигналов по протоколу MIPv6, которая не интегрирована с передачей сигналов ААА, например, последующий обмен BU/BA пойдет по прямому тракту MN - локальный HA (VIII).
Поскольку вышеописанные функциональные возможности трактов I, II, III, IV используются повторно (за исключением тракта IV, когда в собственной сети нет HA) из базового решения, подробного описания требуют только дополнительные функциональные возможности для присваивания локального HA.
Присваивание локального HA 26 по существу означает, что связь AAAh-HA, описанная в базовом решении, преобразуется в связь AAAh-AAAv-локальный HA. Следовательно, общий тракт MN-локальный HA имеет следующую структуру: MN - клиент ААА - AAAv -AAAh - AAAv - локальный HA. В этом тракте используется расширенный протокол аутентификации, такой как расширенный EAP, из узла MN и к AAAh. Часть тракта EAP, имеющая вид: клиент ААА - AAAv - AAAh, переносится в существующем протоколе ААА, например, приложение EAP Diameter или RADIUS. В части AAAh - AAAv - локальный HA тракта используется приложение Diameter MIPv6. Пересылаемая информация по существу такая же, как в базовом решении.
Обратимся к фиг. 7, где примеры комбинаций протоколов между сегментами MN - клиент ААА - AAAv - AAAh - HA и AAAh - AAAv - локальный HA для расширенного протокола MIPv6 поддерживаются согласно настоящему изобретению и сведены в таблицу 3. В случае с локальным HA 26 сервер AAAh 34 направляет запрос на HA в соответствующий сервер AAAv 24 через приложение протокола ААА, предпочтительно приложение Diameter, например, приложение Diameter MIPv6 (но можно также использовать, например, расширенную версию RADIUS). Приложением (приложениями) протокола каркаса ААА, выполняющим перенос нового/расширенного протокола аутентификации по трактам (II, III) и пересылку данных MIPv6 по трактам (IV, VI, VII), может быть, например, приложение (приложения) Diameter.
Предположим сначала, что в собственной сети 30 нет агента HA 36. В этом сценарии единственным способом обеспечения поддержки MIPv6 для узла MN 10 является присвоение локального HA 26 в гостевом домене 20. Таким образом, когда в сервере AAAh 34 получен запрос на адрес HA, сервер AAAh направляет этот запрос на сервер AAAv 24 через приложение Diameter MIPv6. Сервер AAAh также создает мандаты MN-HA, и, если это необходимо, собственный адрес для MN. Мандаты и собственный адрес (или идентификатор NAI, если собственный адрес не имеется) посылаются на сервер AAAv вместе с запросом адреса локального HA.
При приеме запроса адреса локального HA сервер AAAv 24 выбирает локальный HA 26 и посылает мандаты и домашний адрес (или NAI) выбранному HA, используя приложение Diameter MIPv6. Затем сервер AAAv возвращает адрес локального HA серверу AAAh 34. Сервер AAAv может также создать индексы SPI для связей SA протокола IPSec для MN-HA (которые в этом расширенном решении не создаются сервером AAAh). В указанном случае сервер AAAv посылает один из индексов SPI локальному агенту HA и возвращает другой индекс SPI на сервер AAAh вместе с адресом локального HA. Если сервер AAAh последовательно принимает сконфигурированный без поддержки хранения (т.е. автоматически сконфигурированный) собственный адрес от MN 10, то для пересылки собственного адреса на сервер AAAv и локальному агенту HA можно использовать приложение Diameter MIPv6.
Последующие процедура IKE (IKEv1 или IKEv2) (если она используется) и процедура MIPv6 аналогичны описанным в базовом решении за исключением того, что узел MN 10 осуществляет связь непосредственно с локальным HA 26 вместо HA 36 в собственной сети 30.
Предположим теперь, что в собственной сети 30 имеется HA 36. В таком случае локальный агент HA 26 присваиваться не должен, пока узел MN 10 имеет действительную привязку в HA в собственной сети. Если MN не имеет действительную привязку в HA в собственной сети и посылает запрос адреса HA на сервер AAAh 34, то он может содержать индикацию о том, что предпочтительней иметь в собственной сети: локальный HA или HA. Сервер AAAh может учесть эту индикацию, но в конечном счете именно сервер AAAh решает, что присваивать узлу MN: локальный HA или HA в собственной сети. Если AAAh решает присвоить локальный HA, то такая процедура аналогична описанной выше в связи со случаем, когда в собственной сети отсутствует HA.
Последующие процедура IKE (IKEv1 или IKEv2) (если она используется) и процедура MIPv6 аналогичны описанным в базовом решении за исключением того, что узел MN 10 осуществляет связь непосредственно с локальным HA 26 вместо HA 36 в собственной сети 30.
В альтернативном варианте узлу MN 10 предоставляется возможность указать серверу AAAh 34, что он предпочитает локальный HA 26 даже в том случае, когда он имеет действительную привязку в HA 36 в собственной сети 30. В указанном случае сервер AAAh обычно дает команду агенту HA собственной сети удалить привязку до или после присваивания локального HA. Если привязка остается, и локальный HA и HA в собственной сети должны использоваться одновременно, то потребуются дополнительные функциональные возможности, например, в виде иерархического протокола MIPv6.
Инкапсулирование пакетов BU/BA возможно в случаях, когда используется локальный HA 26 при условии, что требуемые связи SA протокола IPSec для пары MN-локальный HA существуют. Отличие от базового решения состоит в том, что инкапсулированные пакеты BU/BA будут пересылаться по тракту (VI+VII) вместо (IV). Суммируя некоторые из вышеприведенных аспектов, можно видеть, что фиг. 9 представляет собой блок-схему базового примера способа для поддержки услуг MIPv6 для мобильного узла. В этом примере пересылка информации и действия, указанные на шагах S1-S4, относятся к аутентификации мобильного узла (S1), установке ассоциации защиты MN-HA (S2), конфигурации MIPv6 (S3) и привязке MIPv6 (S4). Шаги S2-S3 относятся обычно к фазе авторизации. Шаги S1-S4 могут, если это потребуется, выполняться в той или иной степени параллельно, что позволяет сократить общее время установки. На шаге S1 информация пересылается по инфраструктуре ААА для аутентификации мобильного узла на стороне собственной сети. На шаге S2 пересылается информация, относящаяся к MIPv6, для немедленной установки, или разрешения установки в будущем, ассоциации защиты между MN и HA. На шаге S3 выполняется дополнительная конфигурация MIPv6, например, путем пересылки параметров конфигурации на мобильный узел и/или собственному агенту для хранения подходящим образом. На шаге S4 мобильный узел посылает обновление привязки, и в HA устанавливается привязка MIPv6.
Подробные примерные варианты настоящего изобретения в основном обсуждались со ссылками на существующий протокол EAP [6,16]. Однако необходимо понимать, что изобретение прекрасно применимо к другим версиям EAP, такой как EAPv2, а также другим протоколам аутентификации, расширенным описанным образом. Протокол EAP является просто примером возможной реализации, и изобретение в общем случае к нему не сводится и может в качестве альтернативных вариантов охватывать схемы, не относящиеся к EAP.
В вышеуказанных примерах предполагалось, что мобильный узел (MN) и сервер AAAh имеют общий совместно используемый «секрет». Это может быть, например, симметричный ключ, совместно используемый идентификационным модулем, установленным в мобильном узле, и собственной сетью. Идентификационный модуль может представлять собой любой известный идентификационный модуль, защищенный от несанкционированного вмешательства, в том числе: стандартные SIM-карты, используемые в мобильных телефонах GSM; универсальный модуль SIM (USIM); модуль WAP SIM, известный также как WIM; модуль ISIM и, в более общем виде, модули UICC. Для зависимости защиты MN-HA начальное число или единовременное число может переноситься узлом MN на сервер AAAh (или другим, обратным путем, то есть начальное число создается в сервере AAAh и пересылается в MN), на основе которого сервер AAAh может создать ключ (ключи) защиты MN-HA, например, заранее задаваемый коллективный ключ, на основе общего секрета. Мобильный узел способен создавать тот же самый ключ защиты сам, поскольку он породил начальное число/единовременное число (или принимает начальное число от сервера AAAh) и также имеет совместно используемый «секрет». В альтернативном варианте сервер AAAh может один создавать ключ (ключи) защиты MN-HA и пересылать их в MN (криптографически защищенный) и HA.
Хотя изобретение было описано со ссылками на конкретные иллюстративные варианты, следует подчеркнуть, что оно также распространяется на эквиваленты раскрытых признаков, а также модификации и варианты, очевидные специалистам в данной области техники. Таким образом, объем изобретения ограничен только прилагаемой формулой изобретения. Сокращения
ААА - Аутентификация, авторизация и учет
AAAh - Собственный сервер ААА
AAAv - Гостевой сервер ААА
АКА - Соглашение об аутентификации и ключах
АР - Точка доступа
ВА - Подтверждение привязки
BU - Обновление привязки
DAD - Обнаружение дубликата адреса
ЕАР - Расширяемый протокол аутентификации
ЕР - Точка форсирования
GCA - Атрибут группового контейнера
GSM - Глобальная система мобильной связи
НА - Собственный агент
IKE - Обмен ключами Интернет (протокол)
IP - Протокол Интернет
IPSec - Защита IP
ISAKMP - Протокол ассоциации защиты и управления ключами Интернет
ISIM - Модуль идентификации услуг IM
MD5 - Дайджест сообщений (алгоритм)
MIPv6 - Протокол IP мобильной связи, версия 6
MN - Мобильный узел
NAI - Идентификатор доступа к сети
NAS - Сервер доступа к сети
РАА - Агент аутентификации PANA
РАС - Клиент PANA
PANA - Протокол для переноса аутентификации для доступа к сети
РРР - Протокол двухточечного соединения
SA - Ассоциация защиты
SIM - Модуль идентификации абонента
SPI - Индекс параметра защиты
TLS - Защита транспортного уровня
TLV - Значение длины типа
TTLS - Туннелированный TLS
UICC - Универсальная смарт-карта
WAP - Протокол беспроводных приложений
WLAN - Беспроводная локальная сеть Ссылки
Источники информации
1. Mobility support in IPv6, D. Johnson, C. Perkins, J. Arkko. June 30, 2003.
2. Diameter Mobile IPv6 Application, Stefano M. Faccin, Franck Le, Basavaraj Patil, Charles E. Perkins, April 2003.
3. Protocol for Carrying Authentication for Network Access (PANA), D. Forsberg, Y. Ohba, B. Patil, H. Tschofenig, A. Yegin, April 2003.
4. EAP Tunneled TLS Authentication Protocol, Paul Funk, Simon Blake-Wilson, November 2002.
5. IEEE Standard 802.1X, Local and metropolitan area networks - Port-Based Network Access Control.
6. PPP Extensible Authentication Protocol (EAP), RFC2284, L. Blunk, J. Vollbrecht, March 1998.
7. Diameter Extensible Authentication Protocol (EAP) Application, T. Hiller, G. Zorn, March 2003.
8. Remote Authentication Dial In User Service (RADIUS), RFC2865, C. Rigney, S. Willens, A. Rubens, W. Simpson, June 2000
9. RADIUS Extensions, RFC 2869, C. Rigney, W. Willats, P. Calhoun, June 2000.
10. Diameter Mobile IPv4 Application, P. Calhoun, T. Johansson, C. Perkins, APRIL 29, 2003.
11. 3Gpp2 X.P0011 Ver.1.0-9, 3Gpp2 Wireless IP Network Standard, February, 2003.
12 The Internet Key Exchange (IKE), RFC 2409, D. Harkins, D. Carrel, November 1998.
13. Internet Security Association and Key Management Protocol (ISAKMP), RFC2408, D. Maughan, M. Schertler, M. Schneider, J. Turner, November 1998.
14. EAP AKA Authentication, J. Arkko, H. Haverinen, October 2003.
15. EAP SIM Authentication, H. Haverinen, J. Salowey, October 2003.
16. Extensible Authentication Protocol (EAP), L. Blunk, J. Vollbrecht, B. Aboba, J. Carlson, H. Levkowetz, September 2003.
17. State3 Machines for EAP Peer and Authentication J. Vollbrecht, P. Eronen, N. Petroni, Y. Ohba, October 2003.
18. MIPv6 Authorization and Configuration based on EAP, G. Giaretta, I. Guardini, E. Demaria, February 2004.
| название | год | авторы | номер документа |
|---|---|---|---|
| СПОСОБ, СИСТЕМА И УСТРОЙСТВО ДЛЯ ПОДДЕРЖКИ УСЛУГИ HIERARCHICAL MOBILE IP | 2004 |
|
RU2368086C2 |
| СПОСОБЫ И УСТРОЙСТВА ДЛЯ РОУМИНГА CDMA2000/GPRS | 2004 |
|
RU2368089C2 |
| СПОСОБ И УСТРОЙСТВО ДЛЯ ПРЕДОСТАВЛЕНИЯ ВОЗМОЖНОСТИ ОБМЕНА ДАННЫМИ МЕЖДУ СЕТЯМИ CDMA2000 И GPRS | 2009 |
|
RU2497297C2 |
| СПОСОБЫ И УСТРОЙСТВА ДЛЯ ОСУЩЕСТВЛЕНИЯ ПОСРЕДНИКА МОБИЛЬНОГО IP В РЕЖИМЕ СARE-OF-АДРЕСА ВНЕШНЕГО АГЕНТА | 2007 |
|
RU2420905C2 |
| СПОСОБ И СИСТЕМА, ПРЕДНАЗНАЧЕННЫЕ ДЛЯ УСТАНОВЛЕНИЯ СОЕДИНЕНИЯ ЧЕРЕЗ СЕТЬ ДОСТУПА | 2003 |
|
RU2304856C2 |
| СПОСОБЫ И УСТРОЙСТВА ДЛЯ РОУМИНГА CDМА2000/GPRS | 2004 |
|
RU2480965C2 |
| ПОДДЕРЖКА ВЫЗОВОВ БЕЗ UICC | 2008 |
|
RU2428809C2 |
| СПОСОБ ПЕРЕДАЧИ СООБЩЕНИЙ DHCP | 2007 |
|
RU2447603C2 |
| СПОСОБЫ И УСТРОЙСТВА ДЛЯ РОУМИНГА CDMA2000/GPRS | 2004 |
|
RU2349057C2 |
| РЕАЛИЗУЕМЫЕ БАЗОВОЙ СТАНЦИЕЙ СПОСОБЫ И УСТРОЙСТВО ДЛЯ УСТАНОВЛЕНИЯ СОЕДИНЕНИЙ | 2006 |
|
RU2395921C2 |
Изобретение относится в общем случае к мобильной связи и, в частности, касается поддержки услуг протокола IP мобильной связи, версия. Сущность изобретения состоит в том, что информацию, относящуюся к MIPv6, пересылают в сквозной процедуре через инфраструктуру ААА посредством предпочтительно расширенного протокола аутентификации, причем в качестве основы для расширенного протокола аутентификации используют протокол ЕАР с созданием расширений ЕАР путем включения в стек протокола ЕАР в качестве дополнительных данных информации, относящейся к MIPv6, например, атрибутов ЕАР на уровне способа ЕАР стека протокола ЕАР или информации, пересылаемой в атрибуте группового контейнера на уровне ЕАР или уровне способа ЕАР. Главным преимуществом предложенного механизма аутентификации/авторизации MIPv6 является его прозрачность для гостевого домена (20), позволяющая клиенту ААА (22) и серверу AAAv (24) действовать просто в качестве транзитных агентов во время выполнения упомянутой процедуры. Технический результат - установка ассоциации защиты MIPv6 между мобильным узлом (10), перемещающимся в чужой сети (20), и собственным агентом (36) и упрощение конфигурации, относящейся к протоколу MIPv6. 2 н. и 17 з.п. ф-лы, 9 ил., 3 табл.
Приоритеты:
| US 6445922 A, 03.09.2002 | |||
| СПОСОБ ОБСЛУЖИВАНИЯ ТЕРМИНАЛОВ С ОПРЕДЕЛЕНИЕМ ИХ МЕСТОПОЛОЖЕНИЯ В КОММУНИКАЦИОННЫХ СЕТЯХ | 2000 |
|
RU2172076C1 |
| РАСПРЕДЕЛЕНИЕ КЛЮЧЕЙ АУТЕНТИФИКАЦИИ ДЛЯ МОБИЛЬНЫХ СТАНЦИЙ | 1997 |
|
RU2190310C2 |
| Переносная печь для варки пищи и отопления в окопах, походных помещениях и т.п. | 1921 |
|
SU3A1 |
