AAA

RFC 3846 — Расширение Mobile IPv4 для передачи идентификаторов доступа

Статус документа

Данный документ содержит стандарт протокола Internet, предложенного сообществу Internet, и является приглашением к дискуссии в целях развития этого протокола. Сведения о текущем состоянии стандартизации протокола вы найдете в документе «Internet Official Protocol Standards» (STD 1). Документ можно распространять без ограничений.

Тезисы

При перемещении мобильного узла из одной сети в другую требуется повторная аутентификация этого узла. Если в домашней сети используется множество серверов AAA (Authentication Authorization and Accounting — аутентификация, авторизация и учет) и агентов HA (Home Agent — домашний агент) у сервера Home AAA может отсутствовать достаточная для корректной повторной аутентификации узла информация, что может привести к необходимости смены HA для узла. В настоящем документе определено расширение Mobile IP, используемое для передачи идентификаторов серверам Home AAA и HA в форме NAI. Это расширение позволяет агентам HA передавать свою идентификационную информацию, а также данные о сервере Home AAA мобильному узлу, который может передать ее на локальный сервер AAA при изменении точки подключения. Это расширение может также использоваться в других ситуациях, требующих обмена NAI между узлами Mobile IP.

1. Введение

При создании сетей одним из требованием является обеспечение резервирования. Для решения этой задачи в одном домене может использоваться множество серверов AAA. Когда мобильный узел регистрируется в сети, процедура аутентификации выполняется с использованием одного из серверов AAA в домашнем домене пользователя. При последующей регистрации пользователя в другом домене процедура аутентификации должна повторяться. Однако избыточность, обеспечиваемая протоколом AAA, может привести к тому, что повторная аутентификация будет выполняться с использованием другого сервера AAAH, который может не иметь информации о присвоенной сессии HA. В этом документе определяется расширение протокола Mobile IP, которое может использоваться для распространения данных, позволяющих решить эту проблему. Более того, обычно единственной информацией о домашнем агенте (HA) в регистрационном запросе является адрес IP, как определено в RFC 3344 [5]. К сожалению этого может оказаться недостаточно для некоторых инфраструктур AAA (таких, как Diameter [6]), использующих маршрутизацию на базе областей (realm); таким инфраструктурам AAA требуется знать полное имя FQDN для домашнего агента, чтобы обеспечить корректную обработку. Просмотр reverse DNS lookup позволяет идентифицировать лишь интерфейс Mobile IP для IP-адреса HA, который может не обеспечивать взаимно-однозначного соответствия с именем FQDN данного домашнего агента. Это является для HA основанием включать свою идентификацию в регистрационный отклик. Определенное в этом документе расширение MIP v4 включает также субтип, показывающий как это можно сделать. Идентификация HA тогда может быть включена мобильным узлом в последующие регистрационные запросы через другие точки подключения.

2. Спецификация требований

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе должны интерпретироваться в соответствии с BCP 14, RFC 2119 [1].

Используемая в документе терминология, связанная с Mobile IP, описана в RFC 3344 [5]. В дополнение здесь определено еще несколько используемых в документе терминов:

3. Расширение для передачи NAI

В этом документе описывается расширение NAI Carrying Extension, которое может использоваться в запросах и откликах Mobile IP Registration, а также в анонсах Mobile IP Agent [5]. Расширение может быть использовано любым узлом, которых хочет передать идентификацию в форме NAI [4]. В этом документе определены также несколько номеров субтипов, которые идентифицируют конкретные типы передаваемых NAI (главы 4 и 5). Предполагается, что дополнительные типы NAI будут определяться в последующих документах.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |   Length      |   Sub-Type    |    NAI ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.1. Обработка NAI Carrying Extension

Когда мобильный узел или домашний агент добавляет NAI Carrying Extension в регистрационное сообщение, это расширение должно размещяться до любых расширений, связанных с аутентификацией.

Если чужой агент (FA, Foreign Agent) добавляет NAI Carrying Extension в регистрационное сообщение, это расширение должно появляться до любых связанных с аутентификацией расширений, добавляемых FA.

Если агент HA добавил NAI Carrying Extension в отклик Registration Reply для MN, и не получил расширение NAI в последующих сообщениях Registration Request от MN, этот агент HA может предполагать, что MN не понимает расширение NAI. В таких случаях агенту HA не нужно добавлять это расширение NAI в конце последующих сообщений Registration Reply, передаваемых MN.

4. Субтип HA Identity

Для HA Identity используется субтип 1 расширения NAI Carrying Extension. Идентификация содержит значение NAI для HA в форме hostname@realm. Имя хоста вместе с областью формируют полное имя FQDN (hostname.realm) для HA.

Домашний агент, использующий это расширение, должен обеспечить его присутствие в первом сообщении Registration Reply, передаваемом мобильному узлу MN (Mobile Node), который в настоящее время не зарегистрирован. Расширение требуется включать в последующие сообщения Registration Reply лишь в тех случаях, когда это же расширение включено в сообщение Registration Request, полученное от того же узла MN.

Мобильный узел, использующий это расширение, должен (если он получает это расширение в сообщении Registration Reply) включать его в каждый последующий регистрационный запрос, когда требуется повторная аутентификация. Отказ в повторной аутентификации (например, по причине недоступности AAAH), может приводить к прерыванию сеанса Mobile-IP. При инициировании новой сессии мобильному узлу может передаваться новое значение HA Identity NAI и приведенные выше требования будут относиться к полученному в этом случае NAI.

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

Чужому агенту, который получил Home Agent NAI с этим расширением в регистрационному запросу, следует включить Home Agent NAI при запросе аутентификации MN через инфраструктуру AAA, если используемый протокол AAA способен передать эту информацию.

5. Субтип AAAH Identity

Для AAAH Identity используется субтип 2 расширения NAI Carrying Extension. Идентификация содержит NAI домашнего сервера AAA в формате hostname@realm. Имя хоста вместе с областью формируют полное имя FQDN (hostname.realm) для домашнего сервера AAA.

Если в домашней сети имеется несколько серверов AAA, домашний агент, обеспечивающий поддержку выбора AAAH, в соответствии с данным документом должен обеспечивать AAAH identity в первом сообщении Registration Reply, передаваемом мобильному узлу MN. Расширение требуется включать в последующие сообщения Registration Reply лишь в тех случаях, когда это же расширение включено в сообщение Registration Request, полученное от того же узла MN.

Мобильному узлу следует сохранять последнюю идентификацию AAAH Identity, полученную в сообщении Registration Reply, а также следует включать AAAH Identity в каждое последующее сообщение Registration Request при повторной аутентификации в целях повышения эффективности. Невозможность доступа к указанному серверу AAAH при повторной аутентификации будет приводить к возврату нового значения AAAH Identity NAI (которое следует сохранить и включать в последующие регистрационные запросы). Отказ при аутентификации (например, в результате недоступности AAAH) будет приводить к разрыву сессии Mobile-IP; при инициировании нового сеанса мобильному узлу может указываться новое значение AAAH для его использования после новой регистрации.

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

6. Вопросы безопасности

Данная спецификация вводит новые расширения Mobile IP, используемые для передачи идентификации мобильного агента и сервера AAA в форме идентификаторов NAI. Сообщения Mobile IP, которые переносят такие расширения, должны аутентифицироваться, как указано в [4], если ранее не был согласован иной метод аутентификации. Следовательно, данная спецификация не снижает уровень защиты сообщений Mobile IP.

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

7. Согласование с IANA

В этом документе определены новое расширение Mobile IP и новое пространство кодов субтипа для расширений Mobile IP для управления IANA.

В главе 3 определено новое расширение Mobile IP — Mobile IP NAI Carrying Extension. Код типа для этого расширения — 136. Данное расширение добавляет новое пространство кодов субтипа, в котором значения 1 и 2 выделены настоящим документом. Рассмотрение новых кодов субтипа для Mobile IP NAI Carrying Extension выполняется в соответствии с процедурой Expert Review, и описывается при необходимости, как указано в документе [3].

Содержание и формат данного расширения не привязано к конкретным AAA NAI, поэтому при определении в будущем новых значений NAI, которые не будут относиться к категории AAA NAI, они могут, тем не менее, быть согласованы с пространством кодов субтипа, определенным в данном документе для NAI Carrying Extension.

Для расширений NAI Carrying Extension следует выделять значения кодов типа одновременно из пространства IANA для необязательных (skippable) расширений Mobile IPv4 и пространства IANA для анонсов Mobile IPv4. В идеальном случае выделяемые из этих пространств значения должны совпадать.

8. Благодарности

Спасибо авторам исходного документа GNAIE — Mohamed M Khalil, Emad Qaddoura, Haseeb Akhtar и Pat R. Calhoun. Исходный документ был удален из «сферы влияния» рабочей группы MIP, поскольку она не использовала данное расширение. Идеи этого документа использованы здесь. Благодарим также Henrik Levkowetz и Kevin Purser за их полезные отклики и помощь в написании этого документа.

9. Нормативные документы

  1. Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  2. Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999.
  3. Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
  4. Calhoun, P. and C. Perkins, "Mobile IP Network Access Identifier Extension for IPv4", RFC 2794, March 2000.
  5. Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
  6. Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.

10. Адреса авторов

Fredrik Johansson
ipUnplugged AB
Arenavagen 23
Stockholm S-121 28 SWEDEN
Phone: +46 8 725 5916
EMail: moc.deggulpnupi@kirderf

Tony Johansson
Bytemobile Inc
2029 Stierlin Court
Mountain View, CA 94043 USA
Phone: +1 650 862 0523
EMail: moc.elibometyb@nossnahoj.ynot

Перевод на русский язык

Николай Малых, moc.milib@hkylamn