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
24.4.2 Конфигурирование аутентификационной информации для сценария 1
Предположим, что компания XYZ имеет важный сервер с IP-адресом 130.15.20.2. В рамках работ по безопасности администратор сервера нумерует хосты клиентов и присваивает секретные ключи аутентификации каждому клиентскому IP-адресу.
Серверу нужно хранить информацию о безопасности. Для этого можно воспользоваться таблицей (например, 24.1). В ней индексируются все присвоенные клиентским хостам номера, называемые индексами параметров безопасности (Security Parameters Index — SPI). Если сервер имеет несколько IP-адресов, таблица индексируется и по адресам точек назначения.