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

5.1. Обновления привязки, посылаемые домашним агентам

Для защиты целостности и аутентичности сообщений Binding Update и Binding Acknowledgement мобильный узел и домашний агент должны (MUST)использовать контекст безопасности (security association) IPsec. Для обеспечения аутентификации источника данных, целостности в режиме без установления соединения и дополнительной защиты от воспроизведения, как мобильные узлы, так и домашние агенты должны (MUST) поддерживать и должны (SHOULD) использовать заголовок ESP (Encapsulating Security Payload) [6] и должны (MUST) использовать ненулевой алгоритм аутентификации полезных данных. Заметим, что заголовок аутентификации AH (Authentication Header) [5] также возможен, но для краткости в данной спецификации не обсуждается.

Чтобы с помощью IPsec защитить сообщения, которыми обмениваются мобильный узел и домашний агент, должны быть созданы соответствующие элементы базы данных политики безопасности. Мобильный узел не должен допускать применение своего контекста безопасности для посылки сообщения Binding Update от лица другого мобильного узла, используя того же самого домашнего агента. Это должно (MUST) достигаться путем проверки домашним агентом того факта, что данный домашний адрес использовался с правильным контекстом безопасности. Такая проверка предусматривается обработкой IPsec в предположении, что элементы базы данных политики безопасности недвусмысленно определяют единственный контекст безопасности для защиты сообщений Binding Update между любым данным домашним адресом и домашним агентом. Чтобы это оказалось возможным, необходимо, чтобы домашний адрес мобильного узла был виден в сообщениях Binding Update и Binding Acknowledgement. В этих пакетах домашний адрес используется в качестве источника или места назначения, или в опции места назначения Home Address, или в заголовке маршрутизации типа 2.

Как и со всеми контекстами безопасности IPsec в данной спецификации, ручное конфигурирование контекстов безопасности должно (MUST) поддерживаться. Используемые общие секреты для разных мобильных узлов должны (MUST) быть случайными и уникальными и должны (MUST) раздаваться мобильным узлам автономно.

Автоматическое управление ключами IKE [9] может (MAY) поддерживаться. Когда используется IKE, либо элементы базы данных политики безопасности, либо обработка MIPv6 должны (MUST) недвусмысленно определять мандаты IKE фазы 1, которые могут использоваться для авторизации создания контекста безопасности для защиты сообщений Binding Update для конкретного домашнего адреса. Как реально такие отображения поддерживаются, находится вне рамок данной спецификации, но они могут поддерживаться, например, в виде локально администрируемой таблицы в домашнем агенте. Если идентификатор личности в фазе 1 определяется по полностью квалифицированному доменному имени FQDN (Fully Qualified Domain Name), то могут использоваться также безопасные разновидности DNS.

В разд. 11.3.2 обсуждается, насколько тщательная проверка адресов, используемых для транспортировки IKE, необходима для соединений IKE с домашним агентом. Такая тщательная проверка необходима для обеспечения того, чтобы сообщение Binding Update не потребовалось до обмена IKE, который необходим для защиты этого сообщения Binding Update.

Когда между мобильным узлом и домашним агентом используется IKE версии 1 с аутентификацией на основе предварительно распределенного секрета, должен (MUST) использоваться агрессивный режим.

В фазе 1 IKEv1 в качестве полезных данных идентификации личности (Identity Payload) не должен (MUST NOT) использоваться ID_IPV6_ADDR.

Ссылка [21] содержит более подробное описание и примеры использования IPsec для защиты обменов информацией между мобильным узлом и домашним агентом.

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

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