RFC: 3775
Оригинал: Mobility Support in IPv6
Другие версии: RFC 6275
Категория: Предложенный стандарт
Дата публикации:
Авторы: , ,
Перевод: Шнитман Виктор Зиновьевич

11.3.2. Взаимодействие с исходящей обработкой IPsec

В данном разделе в общих чертах описано взаимодействие между исходящей обработкой мобильного IPv6 и исходящей обработкой IPsec для пакетов, посылаемых мобильным узлом, находящимся вне дома. Любая конкретная реализация может (MAY) использовать алгоритмы и структуры данных, отличные от предлагаемых здесь, однако ее обработка должна (MUST) быть согласованной с описанными здесь результатами работы и с соответствующими спецификациями IPsec. В описанных ниже шагах предполагается, что IPsec используется в транспортном режиме [4], и что мобильный узел использует свой домашний адрес, как источник пакета (с точки зрения протоколов более высоких уровней и приложений, как описано в разд. 11.3.1):

  • Пакет создается протоколами более высокого уровня и приложениями (например, TCP), как если бы мобильный узел находился дома, и протокол мобильного IPv6 не использовался.

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

  • Как часть исходящей обработки пакета в IP, пакет сравнивается с базой данных политики безопасности IPsec для того чтобы определить, какая обработка для него требуется [4].

  • Если требуется обработка IPsec, пакет либо сопоставляется с существующим контекстом безопасности SA (или со связкой контекстов безопасности), либо для пакета создается новый SA (или связка SA), в соответствии с процедурами, определенными для IPsec.

  • Поскольку мобильный узел находится вне дома, чтобы достичь узла-корреспондента, он использует либо туннелирование в обратном направлении, либо оптимизацию маршрута.

    Если используется туннелирование в обратном направлении, пакет конструируется обычным способом и затем туннелируется через домашнего агента. Если используется оптимизация маршрута, то мобильный узел вставляет в пакет опцию места назначения Home Address, заменяя поле Source Address в IP-заголовке пакета временным адресом, используемым совместно с данным узлом-корреспондентом, как описано в разд. 11.3.1. Заголовок Destination Options, в который вставляется опция места назначения Home Address, должен (MUST) появляться в пакете после заголовка маршрутизации, если таковой имеется, и до заголовка IPsec (AH [5] или ESP [6]), так что опция места назначения Home Address обрабатывается узлом места назначения до обработки заголовка IPsec.

    Наконец, когда пакет собран полностью, над ним выполняется необходимая аутентифицирующая IPsec-обработка (и, если требуется, шифрация), инициализирующая аутентификационные данные (Authentication Data) в заголовке IPsec.

    Обработка опций места назначения RFC 2402 расширяется следующим образом. Аутентификационные данные AH должны (MUST) вычисляться, как если бы истинными были следующие условия:

    • IPv6-адрес источника в заголовке IPv6 содержит домашний адрес мобильного узла,
    • поле Home Address в опции места назначения Home Address содержит новый временный адрес.
  • Это позволяет, но не требует, приемнику пакета, содержащего опцию места назначения Home Address, поменять местами эти два поля поступающего пакета, чтобы получить описанную выше ситуацию, упрощая обработку всех последующих заголовков пакета. Однако такой обмен не требуется до тех пор, пока результат аутентификационных вычислений остается тем же самым.

Если для создания новых контекстов безопасности для партнера используется протокол автоматического управления ключами, то важно гарантировать, чтобы партнер мог посылать мобильному узлу пакеты протокола управления ключами. Это может оказаться невозможным, если партнером является домашний агент мобильного узла и назначением контекстов безопасности является посылка домашнему агенту сообщения Binding Update. Пакеты, адресованные на домашний адрес мобильного узла, не могут использоваться до окончания обработки сообщения Binding Update. Для подразумеваемого случая использования IKE [9] в качестве протокола автоматического управления ключами (случая по умолчанию), таких проблем можно избежать с помощью выполнения следующих требований при обмене информацией со своим домашним агентом:

  • Когда мобильный узел находится вне дома, он должен (MUST) использовать свой временный адрес в качестве адреса источника всех пакетов, которые он посылает как часть протокола управления ключами (без использования для этих пакетов протокола мобильного IPv6, как предлагается в разд. 11.3.1).
  • Кроме того, для всех установленных IKE контекстов безопасности, привязанных к домашнему адресу мобильного узла, мобильный узел должен (MUST) включать в обмен фазы 2 IKE полезные данные идентификации (ISAKMP Identification Payload) [8], задающие домашний адрес мобильного узла как инициатора контекста безопасности [7].

Чтобы избежать необходимости повторного выполнения IKE после перемещений, в сообщениях Binding Update и Binding Acknowledgement может использоваться бит Key Management Mobility Capability (K).

Страница 84 из 120

2007 - 2022 © Русские переводы RFC, IETF, ISOC.