Использование IKEv1 в мобильном IPv6 более подробно документировано в [21]. Относительно использования IKEv1 необходимо обратить внимание на следующее:
Необходимо не допускать того, чтобы мобильный узел предъявлял домашний адрес другого мобильного узла. Домашний агент должен проверить, что мобильный узел, пытающийся согласовать SA для конкретного домашнего адреса, авторизован для этого домашнего адреса. Это предполагает, что даже с использованием IKE элемент политики должен быть сконфигурирован для каждого домашнего адреса, обслуживаемого домашним агентом.
Чтобы этого избежать, может оказаться возможным включить домашние адреса в поле Subject AltName сертификата. Однако реализациям не гарантируется поддержка использования конкретного IP-адреса (временного адреса), тогда как в сертификате появляется другой адрес (домашний адрес). В любом случае даже этот подход потребует решения специфических для пользователя задач в полномочном органе сертификации.
Если применяется аутентификация с предварительно сформированным секретом, то основной режим IKEv1 использоваться не может. Вместо этого необходимо использовать агрессивный режим или групповые предварительно формируемые секреты с соответствующими последствиями для системы безопасности.
Заметим, что подобно многим другим проблемам, это общая проблема IKEv1, связанная со способностью использования разных IP-адресов, а не специфическая проблема мобильного IPv6. Дополнительную информацию см. в разд. 4.4 в [21].
В связи с проблемами, отмеченными в разд. 11.3.2, фаза 1 IKE между мобильным узлом и его домашним агентом устанавливается с помощью текущего временного адреса мобильного узла. Это предполагает, что когда мобильный узел переходит на новое местоположение, возможно, он должен переустановить фазу 1. Для реализаций, которые могут обновить оконечные точки фазы 1 IKE без переустановления фазы 1, предоставляется флаг Key Management Mobility Capability (K), но поддержка такого поведения является факультативной.
Как обсуждалось в разд. 7 в [21], когда используются сертификаты, может произойти фрагментация IKE.
Тем не менее, если требуется конфигурирование каждого мобильного узла даже для IKE, важное преимущество протокола IKE заключается в том, что он автоматизирует согласование криптографических параметров, включая индексы SPI, криптографические алгоритмы и т.д. Таким образом, требуется меньше конфигурационной информации.
Если используется ручное управление ключами, то частота перемещений в некоторых канальных уровнях или сценариях развертывания может оказаться достаточно высокой для того, чтобы сделать возможными атаки воспроизведения и переупорядочивания. В этих случаях протокол IKE должен (SHOULD) использоваться. Потенциально уязвимые сценарии включают непрерывное перемещение через небольшие ячейки, или неконтролируемое чередование между доступными точками подключения к сети.
Подобным образом, при некоторых сценариях развертывания количество мобильных узлов может быть очень большим. В этих случаях, возможно, необходимо использовать автоматические механизмы для сокращения усилий по управлению администрированием криптографических параметров, даже если некоторое конфигурирование каждого мобильного узла всегда необходимо. В этих случаях протокол IKE также должен (SHOULD) использоваться.
Кроме IKEv1 существуют другие механизмы автоматического управления ключами, но данный документ не рассматривает связанных с ними проблем. Однако заметим, что большая часть приведенных выше соображений применима также и к IKEv2 [30], по крайней мере, к его текущей спецификации.
15.4. Сообщения Binding Update, посылаемые узлу-корреспонденту
Мотивацией разработки процедуры обратной маршрутизируемости (return routability procedure) было создание для мобильного IPv6 достаточной поддержки без порождения новых значительных проблем безопасности. Целью этой процедуры не была защита от атак, которые уже были возможны и до введения мобильного IPv6.
В следующих разделах будут описаны особенности системы безопасности, построенной на основе используемого метода, как с точки зрения злоумышленников, которые находятся на пути пакетов и могут видеть криптографические значения, посылаемые открыто (разд. 15.4.2 и разд. 15.4.3), так и с точки зрения других злоумышленников (разд. 15.4.6).