Когда хост загружается, он может не дождаться Router Advertisement и отправить сообщение Router Solicitation (ходатайство маршрутизатору) с типом 133, чтобы вызвать объявление от маршрутизатора. Маршрутизатор отвечает сообщением Advertisement по адресу локальной связи хоста.
23.3.2 Сообщения Neighbor Solicitation и Advertisement
В настоящее время предлагается заменить запросы старого протокола Address Resolution Protocol (ARP) новыми многоадресными сообщениями протокола ICMP Neighbor Solicitation и Advertisement (ходатайство и объявление соседа). Сообщение Neighbor Advertisement является ответом на Neighbor Solicitation. Кроме исследования соседей по адресам уровня связи данных, сообщение Neighbor Solicitation применяется для:
■ Обнаружения дублированных IP-адресов
■ Тестирования, является ли маршрутизатор отключенным
■ Тестирования, является ли отключенным сосед, которому посылались пакеты
23.3.3 Address Resolution
Для исследования адреса соседа на уровне связи данных сообщение Neighbor Solicitation отправляется на специальный адрес, называемый целевым адресом ходатайствующего узла для многоадресной рассылки (solicited-node multicast address). Этот адрес сформирован из младших 32 бит целевого IP-адреса и предопределенного 96-разрядного префикса FF02:0:0:0:0:1. Таким способом создается адрес многоадресной рассылки, вложенный в локальную связь. Отправитель включает в сообщение собственный адрес уровня связи данных.
Использование этой специализированной многоадресной рассылки существенно сокращает количество систем, слушающих запрос. Вполне вероятно, что только целевая система будет реагировать на такой запрос.
23.3.4 Обнаружение дублирования IP-адресов
Перед использованием IP-адреса локальной связи или любого другого адреса, который не был построен путем добавления префикса к адресу локальной связи, узел должен послать сообщение Neighbor Solicitation с целью узнать, имеет ли кто-то из соседей выбранный IP-адрес. В качестве исходного адреса для сообщения узел применяет неспецифицированный адрес. Если адрес IP уже используется, его владелец пошлет ответ в многоадресной рассылке.
23.3.5 Обнаружение непостижимости соседа
Обнаружение неисправного маршрутизатора было рискованным делом в IPv4. В версии 6, когда тайм-аут указывает на бездействующий маршрутизатор, система проверяет такой маршрутизатор одноадресным сообщением Neighbor Solicitation.
Такая же процедура выполняется, чтобы проверить недостижимость соседнего хоста.
23.3.6 Сообщение Redirect
Как и в версии 4, когда хост пересылает датаграмму на неправильный локальный маршрутизатор, он получает обратно сообщение Redirect (перенаправление), указывающее правильный узел для первого попадания. Сообщение Redirect может использоваться для уведомления отправителя о размещении точки назначения в локальной связи. Возможно, именно поэтому сообщение Redirect определено в спецификации Neighbor Discovery.
Ha рис. 23.5 показан предложенный формат для сообщения Redirect в ICMPv6. Целевой адрес — это адрес IP следующего попадания, который должен использоваться при пересылке пакета. Адрес назначения — это выбранная точка назначения. Поле выбора содержит адрес уровня связи данных целевой системы и может также включать сведения для перенаправления датаграммы.
Рис. 23.5. Формат сообщения Redirect
23.4 Дополнительная литература
ICMPv6 описан в RFC 1885. На момент выхода книги протоколы Neighbor Discovery были еще на стадии обсуждения.
Глава 24
Безопасность в IP
24.1 Введение
Необходимость разработки новой версии IP стала дополнительным стимулом для решения проблем безопасности TCP/IP. Предлагаемый механизм обеспечивает безопасность на уровне IP. Он разработан для совместимости как с версией 4, так и с версией 6. Для упрощения все сценарии этой главы предполагают использование версии 4.
Все признают необходимость средств защиты, но как обеспечить их на уровне IP? Почему не подходит уровень приложений? На практике множество приложений реализует собственные методы обеспечения безопасности. Однако в окружении, где очень легко "подглядеть" за проходящим трафиком и захватить его для дальнейшего анализа, или где есть возможность фальсификации IP-адресов, трудно обеспечить достоверность каждой датаграммы.
Почему не подходит физический уровень? Весь трафик связи должен шифроваться. Это позволит решить проблему с "подсматриванием", однако приведет к необходимости автоматического дешифрирования в каждом маршрутизаторе. Сегодня мы еще не можем доверять каждому маршрутизатору.
Кроме того, в этом случае не решается проблема с аутентификацией, равно как и с перегрузкой высокоскоростного трафика, когда шифрование/дешифрирование реализуется на аппаратном уровне. Более того, каждый интерфейс локальной сети должен быть способен шифровать и дешифрировать данные, а это серьезно увеличит стоимость оборудования.
24.2 Безопасность
В главе 3 мы уже отмечали три атрибута безопасности:
Аутентификация Проверка подлинности пользователя, клиентского процесса или серверного приложения
Целостность Проверка отсутствия изменений в данных
Конфиденциальность Предотвращение несанкционированного доступа к информации
В той же главе представлены несколько механизмов реализации указанных атрибутов. В следующем разделе мы рассмотрим адаптацию этих механизмов для обеспечения безопасности на уровне IP..
24.3 Стратегия безопасности
Интеграция безопасности в IP стала одной из наиболее сложных работ, выполненных IETF. Аутентификация, целостность данных и конфиденциальность стали насущными и необходимыми. Стратегия безопасности предполагает:
■ Содействие совместной работе, начинающейся с уже известных и реализованных механизмов для аутентификации, целостности данных и конфиденциальности.
■ Разработку основ безопасности, позволяющих перейти на новые механизмы безопасности.
В качестве исходных были выбраны следующие механизмы:
■ MD5 для аутентификации и целостности данных (в настоящее время проявились проблемы с MD5 при реализации высокоскоростных коммуникаций, поскольку требуется большой объем вычислений).
■ Симметричное шифрование в режиме Cipher Block Chaining американского стандарта Data Encryption Standard (CBC-DES) для обеспечения конфиденциальности.
Для распространения информации используется шифрование общедоступными ключами.
24.4 Сценарии обеспечения безопасности
Существует множество способов использования различных вариантов безопасности (они описаны ниже), но сначала мы познакомимся с несколькими сценариями для разъяснения причин выбора некоторых вариантов.
Сценарий 1. Компания XYZ хочет обезопасить свои внешние коммуникации клиент/сервер. Ей нужно устранить возможность фальсификации своих данных при подделке исходного IP-адреса или изменения данных при пересылке.
Сценарий 2. Администратор компании XYZ копирует очень важные файлы между хостами. Эту операцию должен выполнять только этот администратор и никто другой. Кроме того, важно предотвратить "подглядывание", т.е. захват и несанкционированное использование данных из файлов.
Сценарий 3. Компания XYZ соединила по Интернету свои производственные подразделения с удаленным главным офисом. Она хочет скрыть все свои коммуникации от остального мира.
Для простоты можно считать, что каждый клиентский или серверный хост имеет единственный IP-адрес и один интерфейс. Однако механизмы безопасности должны работать и для систем с несколькими интерфейсами и несколькими IP-адресами.
24.4.1 Сценарий 1
Технология Message Digest (резюме сообщения) подойдет для сценария 1 — аутентифицировать отправителя и определить изменения в данных. Рассмотрим, как работает этот механизм (см. рис. 24.1):
■ Источник и назначение знают секретный ключ.
■ Источник выполняет вычисление, используя данные и секретный ключ.
■ Источник отправляет в сообщении результат вместе с данными.
■ В точке назначения выполняются те же самые вычисления и сравниваются результаты.
Рис. 24.1. Использование Message Digest
