Сидни Фейт - TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security)

■ MTU для связи, имеющей различные MTU

■ Значения для различных таймеров

Все эти операции выполняются через сообщения ICMPv6 Router Advertisement (объявления маршрутизатора), имеющие тип 134. Хосты слушают сообщения Router Advertisement по всем адресам многоадресных рассылок на всех узлах локальной связи.

Когда хост загружается, он может не дождаться Router Advertisement и отправить сообщение Router Solicitation (ходатайство маршрутизатору) с типом 133, чтобы вызвать объявление от маршрутизатора. Маршрутизатор отвечает сообщением Advertisement по адресу локальной связи хоста.

В настоящее время предлагается заменить запросы старого протокола Address Resolution Protocol (ARP) новыми многоадресными сообщениями протокола ICMP Neighbor Solicitation и Advertisement (ходатайство и объявление соседа). Сообщение Neighbor Advertisement является ответом на Neighbor Solicitation . Кроме исследования соседей по адресам уровня связи данных, сообщение Neighbor Solicitation применяется для:

■ Обнаружения дублированных IP-адресов

■ Тестирования, является ли маршрутизатор отключенным

■ Тестирования, является ли отключенным сосед, которому посылались пакеты

Для исследования адреса соседа на уровне связи данных сообщение Neighbor Solicitation отправляется на специальный адрес, называемый целевым адресом ходатайствующего узла для многоадресной рассылки (solicited-node multicast address). Этот адрес сформирован из младших 32 бит целевого IP-адреса и предопределенного 96-разрядного префикса FF02:0:0:0:0:1. Таким способом создается адрес многоадресной рассылки, вложенный в локальную связь. Отправитель включает в сообщение собственный адрес уровня связи данных.

Использование этой специализированной многоадресной рассылки существенно сокращает количество систем, слушающих запрос. Вполне вероятно, что только целевая система будет реагировать на такой запрос.

Перед использованием IP-адреса локальной связи или любого другого адреса, который не был построен путем добавления префикса к адресу локальной связи, узел должен послать сообщение Neighbor Solicitation с целью узнать, имеет ли кто-то из соседей выбранный IP-адрес. В качестве исходного адреса для сообщения узел применяет неспецифицированный адрес. Если адрес IP уже используется, его владелец пошлет ответ в многоадресной рассылке.

Обнаружение неисправного маршрутизатора было рискованным делом в IPv4. В версии 6, когда тайм-аут указывает на бездействующий маршрутизатор, система проверяет такой маршрутизатор одноадресным сообщением Neighbor Solicitation.

Такая же процедура выполняется, чтобы проверить недостижимость соседнего хоста.

Как и в версии 4, когда хост пересылает датаграмму на неправильный локальный маршрутизатор, он получает обратно сообщение Redirect (перенаправление), указывающее правильный узел для первого попадания. Сообщение Redirect может использоваться для уведомления отправителя о размещении точки назначения в локальной связи. Возможно, именно поэтому сообщение Redirect определено в спецификации Neighbor Discovery.

Ha рис. 23.5 показан предложенный формат для сообщения Redirect в ICMPv6. Целевой адрес — это адрес IP следующего попадания, который должен использоваться при пересылке пакета. Адрес назначения — это выбранная точка назначения. Поле выбора содержит адрес уровня связи данных целевой системы и может также включать сведения для перенаправления датаграммы.

Рис. 23.5.Формат сообщения Redirect

ICMPv6 описан в RFC 1885. На момент выхода книги протоколы Neighbor Discovery были еще на стадии обсуждения.

Необходимость разработки новой версии IP стала дополнительным стимулом для решения проблем безопасности TCP/IP. Предлагаемый механизм обеспечивает безопасность на уровне IP. Он разработан для совместимости как с версией 4, так и с версией 6. Для упрощения все сценарии этой главы предполагают использование версии 4.

Все признают необходимость средств защиты, но как обеспечить их на уровне IP? Почему не подходит уровень приложений? На практике множество приложений реализует собственные методы обеспечения безопасности. Однако в окружении, где очень легко "подглядеть" за проходящим трафиком и захватить его для дальнейшего анализа, или где есть возможность фальсификации IP-адресов, трудно обеспечить достоверность каждой датаграммы.

Почему не подходит физический уровень? Весь трафик связи должен шифроваться. Это позволит решить проблему с "подсматриванием", однако приведет к необходимости автоматического дешифрирования в каждом маршрутизаторе. Сегодня мы еще не можем доверять каждому маршрутизатору.

Кроме того, в этом случае не решается проблема с аутентификацией, равно как и с перегрузкой высокоскоростного трафика, когда шифрование/дешифрирование реализуется на аппаратном уровне. Более того, каждый интерфейс локальной сети должен быть способен шифровать и дешифрировать данные, а это серьезно увеличит стоимость оборудования.

В главе 3 мы уже отмечали три атрибута безопасности:

В той же главе представлены несколько механизмов реализации указанных атрибутов. В следующем разделе мы рассмотрим адаптацию этих механизмов для обеспечения безопасности на уровне IP..

Интеграция безопасности в IP стала одной из наиболее сложных работ, выполненных IETF. Аутентификация, целостность данных и конфиденциальность стали насущными и необходимыми. Стратегия безопасности предполагает:

■ Содействие совместной работе, начинающейся с уже известных и реализованных механизмов для аутентификации, целостности данных и конфиденциальности.

■ Разработку основ безопасности, позволяющих перейти на новые механизмы безопасности.

В качестве исходных были выбраны следующие механизмы:

■ MD5 для аутентификации и целостности данных (в настоящее время проявились проблемы с MD5 при реализации высокоскоростных коммуникаций, поскольку требуется большой объем вычислений).