Кратко

  • RFC 5419 сохраняет историческое обоснование проверки Binding Update в Mobile IPv6 через домашнюю AAA-систему, однако приведённый пример не превращает передачу ключа от AAA домашнему агенту в универсальный контракт IETF.
  • В документе отдельно показан пример обмена через RADIUS и отдельно обозначено отсутствие стандартного способа создать ключ и ассоциацию MN–HA на основе ассоциации MN–AAA.
  • RFC 4877 позднее описал путь IKEv2/IPsec, ослабив часть прежних аргументов; обоснование 2009 года не говорит о том, что развёрнуто сегодня.

Одного запроса на привязку недостаточно для полной цепочки доверия

Mobile IPv6 позволяет узлу сохранять домашний адрес, находясь в другой сети. Мобильный узел (MN) отправляет домашнему агенту (HA) Binding Update (BU), сообщая адрес, по которому его сейчас можно достичь. HA сохраняет привязку и может направлять пакеты через туннель. В базовой архитектуре сигнальные сообщения между MN и HA защищает ассоциация безопасности IPsec. Пары взаимодействующих сторон определены; операционный вопрос остаётся: как им получить совместимые ключи, если система учёта абонентов находится отдельно?

Опубликованный в январе 2009 года RFC 5419 — информационный документ, сохраняющий причины появления аутентификационной опции RFC 4285. В нём прямо сказано, что альтернативный подход не отменяет IPsec. Примеры относятся к сетям CDMA2000 и WiMAX такими, какими их описывали авторы в тот период. Операторы хотели использовать домашнюю AAA-систему для проверки абонентов, повторно применять их профили и динамически назначать домашний адрес или HA. Это зафиксированные исторические требования, а не измерения нынешних сетей. (RFC 5419, разделы 1 и 5)

RFC 4285 задаёт две важные опции. Опция MN–AAA позволяет аутентифицировать BU на основе общей ассоциации безопасности между мобильным узлом и домашним сервером AAA. Но ответ HA — Binding Acknowledgement — должен использовать опцию MN–HA. RFC 4285 указывает, что HA полагается на внешнюю домашнюю AAA-сущность, которая проводит аутентификацию по защищённому каналу; детали взаимодействия HA и AAA находятся за пределами документа. Поэтому аутентификация запроса и состояние ключа, нужное для ответа, связаны, но не тождественны. (RFC 4285, раздел 5.2)

Пример RADIUS показывает место стыка

В примере CDMA2000 из RFC 5419 HA передаёт данные аутентификации серверу RADIUS. AAA проверяет BU, вычисляет ключ сеанса на основе общего секрета MN–AAA и временной метки, а затем отправляет его HA в Access-Accept с атрибутом поставщика, определённым 3GPP2. HA связывает ключ с ассоциацией безопасности MN–HA; в примере используется SPI 5. С этой ассоциацией агент аутентифицирует Binding Acknowledgement. Мобильный узел рассчитывает тот же ключ, проверяет ответ и использует его для следующих BU. (RFC 5419, раздел 6.2)

Этот поток обнаруживает границу контроля. Аутентификация абонента начинается с секрета, общего для MN и AAA. Последующая сигнализация HA требует ключа, которым смогут пользоваться MN и HA. Пример показывает, как конкретный сетевой профиль может передавать материал сеанса между этими ролями. Однако упомянутый RADIUS-атрибут определён 3GPP2, а не RFC 4285 как универсальный атрибут.

Затем RFC 5419 прямо называет ограничение: RFC 4285 не определяет способ создать общий ключ и ассоциацию MN–HA из ассоциации MN–AAA. Требуются механизмы конкретного развёртывания, не стандартизованные IETF. Для сравнения RFC 5419 приводит RFC 3957, где для Mobile IPv4 заданы nonce генерации ключа и шаги его выработки. Это не означает, что RFC 4285 не может работать; это определяет границу контракта совместимости. Схема может показать, как ключ попадает к HA, но сама по себе она не стандартизует выработку, привязку к личности, область действия и доставку между разными реализациями. (RFC 5419, раздел 7; RFC 3957, раздел 5)

Вывод не следует преувеличивать. Опция RFC 4285 не становится из-за этого заведомо ошибочной; профиль конкретного развёртывания может описать недостающие детали. Но если они локальны, оператору необходимо понимать, какие компоненты им следуют: мобильное устройство, служба AAA, атрибуты RADIUS, HA и механизм, который связывает абонента с динамически выбранным HA. Один формат сообщения не подтверждает согласованность всей цепочки.

К моменту публикации обоснование уже менялось

RFC 5419 отмечает изменение хронологии. Опубликованный в 2007 году RFC 4877 описал работу Mobile IPv6 с IKEv2 и пересмотренной архитектурой IPsec. RFC 5419 говорит, что IKEv2 улучшил интеграцию с AAA-бэкендом, из-за чего часть прежних аргументов за RFC 4285 потеряла актуальность. В документе также отмечено, что RFC 5026 и связанные работы решили вопросы начальной настройки динамических домашних адресов и HA. Поэтому текст 2009 года нельзя считать бессрочным выводом о единственно возможной архитектуре. (RFC 4877; RFC 5026; RFC 5419, разделы 1, 5 и 9)

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

У опции аутентификации есть и другие ограничения. RFC 5419 отмечает, что для оптимизации маршрута нужна дополнительная защита, в самой опции нет согласования криптографических алгоритмов, защита от повторного воспроизведения зависит от достаточно синхронизированных часов, а видимый постоянный Network Access Identifier создаёт риск для приватности. Ассоциация MN–AAA также устанавливается вне протокола. Это условия, которые должен учитывать профиль, а не самостоятельное доказательство непригодности подхода. (RFC 5419, раздел 7)

Документы, пример и работающая система — разные доказательства

Здесь важно различать три уровня. RFC 4285 задаёт форматы опций и их обработку. RFC 5419 сохраняет обоснование и пример RADIUS, привязанный к своему времени. RFC 3957 позволяет сравнить выработку ключей для Mobile IPv4, а RFC 4877 описывает другой путь — IKEv2/IPsec. Ни один из текстов не доказывает, какую реализацию поставили в конкретную сеть и какой профиль работает сейчас.

При аудите архитектуры стоит выяснить источник общего секрета; способ привязать ключ сеанса к абоненту и выбранному HA; атрибут RADIUS, который его переносит; согласование срока действия и защиты от повторов на обоих концах; поведение системы, если AAA разрешает запрос, а HA не создаёт ожидаемую ассоциацию. Если ответы записаны в профиле поставщика, это часть архитектуры безопасности: профиль должен иметь версию, тесты и план миграции. Если нужную SA обеспечивает IKEv2, его поддержку и интеграцию с AAA следует подтвердить для фактических версий устройств и HA, а не выводить из публикации RFC.

Долговременный вывод из RFC 5419 не в том, что одна опция победила. Централизованное решение по абоненту и криптографическая связь между MN и HA — разные элементы инфраструктуры. Их можно соединить стандартным обменом, явно описанным профилем или иным протоколом управления ключами. Но одно слово «аутентифицирован» не подтверждает, что ключ пришёл нужному узлу.

Источники