Индекс параметров защиты

Индекс параметров защиты

Следующий Заголовок: задает тип передаваемых данных, следующих после данных идентификации. Значение берется из списка протоколов IP, который можно найти по адресу www. ietf. org (перейти по ссылке IANA).
Длина передаваемых данных: задает длину АН.

Резервное: зарезервировано для будущего использования.
Индекс параметров защиты (SPI): значение этого поля, в комбинации с IP адресом. получателя и протоколом безопасности (АН), однозначно задает ассоциации безопасности для данной датаграммы. SPI обычно выбирается получающим узлом в процессе определения SA.

Конфиденциальность потока данных

Конфиденциальность потока данных

Конфиденциальность потока данных требует выбора туннельного режима.
Передаваемые данные ESP появляются после IP заголовка, но перед протоколом транспортного уровня. Протоколу ESP IANA назначила номер 50. ESP состоит из незашифрованного заголовка, за которым следуют зашифрованные данные.

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

Что и как делает ESP

Что и как делает ESP

Уже знакомый вам протокол «Вложенные защищенные передаваемые данные 1Р» (IP Encapsulating Security Payload — ESP) является механизмом обеспечения сохранности и конфиденциальности датаграмм IP.

Кроме того, ESP может быть использован для удостоверения происхождения данных, в зависимости от используемых алгоритмов. Безотказность работы и защита анализом данных не предусмотрены в ESP. Так же как и в АН, удостоверение происхождения данных и их сохранности совмещены и называются идентификацией.

Integrity Check Value — ICV

Integrity Check Value — ICV

Значение проверки сохранности (Integrity Check Value — ICV) для входящих пакетов Если пакет фрагментируется, то сборка такого пакета должна иметь место до обработки АН. Соответствующая SA определяется при помощи IP адреса получателя, номера протокола (АН) и SPI. Если подходящая SA не найдена, то такой пакет должен быть отвергнут. Поле Номер Последовательности применяется в защите от повторений пакетов, что требуется в АН. Однако если получатель не осуществляет такую защиту, то тогда значение поля Последовательный Номер игнорируется.

Получающий узел вычисляет ICV на основе соответствующих полей пакета и сравнивает результат со значением, переданным в поле Данные Идентификации. Если они совпадают, датаграмма пропускается. Алгоритм этой операции может варьироваться, но, как вы наверняка припоминаете, любая реализация АН должна поддерживать либо НМАС с MD5, либо НМАС с SHA 1.

Защищаемые данные в случае туннельного режима ESP

Защищаемые данные в случае туннельного режима ESP

Защищаемые данные в случае туннельного режима ESP показаны на 9.8. Туннельный режим может быть использован как хостами, так и шлюзами безопасности. Когда ESP применяется в реализации для шлюза безопасности (с целью защиты транзитного трафика пользователя), то должен использоваться тун нельный режим.

В туннельном режиме «внутренний» IP заголовок содержит адреса конечного получателя и отправителя, тогда как «внешний» IP заголовок может содержать другие IP адреса, например адреса шлюзов безопасности. В туннельном режиме ESP защищает весь внутренний IP пакет, включая весь внутренний IP заголовок. Позиция ESP в туннельном режиме относительно внешнего IP заголовка такая же, как и в случае ESP в транспортном режиме.

Защита ESP в транспортном режиме

Защита ESP в транспортном режиме

На 9.7 показана защита ESP в транспортном режиме в случае IPv6. ESP рассматривается как полезная нагрузка, доставляемая из конца в конец, и, таким образом, должна появиться после данных о пересылках, маршрутизации и заголовков расширения фрагментации.

Заголовок (заголовки) расширения настроек получателя могут появиться как до, так и после заголовка ESP, в зависимости от необходимости. Однако в силу того, что ESP защищает только поля после заголовка ESP, то в общем случае это может быть желательным — поместить заголовки настроек получателя после заголовка ESP.

Защита ESP

Защита ESP

Так же как и АН, ESP может быть использован в двух режимах: транспортном и туннельном. В первом случае ESP подходит только хостам и обеспечивает защиту протоколов верхнего уровня, но не IP заголовка. (В этом режиме, в случае вариантов запихнуть в стек и запихнуть в железо, входящие и исходящие IP фрагменты могут потребовать такую реализацию IPSec, которая выполняла бы дополнительную сборку/фрагментацию для того, чтобы соответствовать этой спецификации и обеспечить прозрачную поддержку IPSec.) На 9.6 , что защищает ESP в транспортном режиме.

ESP помещается после IP заголовка и пе 171 ред протоколами верхнего уровня, такими как TCP, UDP, ICMP и др., или перед любым другим уже вставленным заголовком IPSec. В контексте IPv4 это означает помещение ESP после IP заголовка (и любых содержащихся в нем настроек), но перед протоколом верхнего уровня. «Концевик ESP» содержит все заполняющие биты, их длину и поля следующего заголовка.

Последовательный Номер

Последовательный Номер

Последовательный Номер: это поле всегда присутствует, даже если получатель не собирается воспользоваться защитой от повторения в конкретном SA. Если же такая защита применяется (по умолчанию это так), передаваемый последовательный номер не может повторяться. Следовательно, счетчики получателя и отправителя сбрасываются (Путем установления новой SA и, таким образом, нового ключа) до того, как будет передано 232 пакетов с применением данной SA.

Передаваемые данные: содержит зашифрованные данные.
Заполнение: служит для обеспечения требования о длине открытого текста. Количество заполняющих байтов зависит от реализации.

RFC 2406

RFC 2406

RFC 2406 — это самая последняя спецификация ESP, и в этой главе мы сконцентрируем свое внимание именно на этой версии. На 9.10 показан формат заголовка ESP. Номер протокола ESP — 50. Все поля заголовка должны присутствовать и включаются в значение проверки сохранности (описываемом чуть ниже).

Эти поля выполняют следующие функции:
Индекс параметров безопасности: значение этого поля, в комбинации с IP адресом получателя и номером протокола (ESP), однозначно определяют ассоциацию безопасности данной датаграммы. SPI обычно выбирается получающим узлом в процессе определения.

ESP и две версии публикации

ESP и две версии публикации

ESP был опубликован в двух «версиях». Первая была описана в RFC 1827, и в этой части главы мы обсудим эту раннюю спецификацию.
RFC 1827 На 9.9 приведен формат заголовка ESP в соответствии с RFC 1827. Он состоит из поля SPI и непрозрачных данных. Поле SPI определяет соответствующую датаграмме ассоциацию безопасности, а если установлена в ноль, то это означает, что ассоциация безопасности не использовалась.

Поле Непрозрачные Данные и конкретные алгоритмы шифрации и идентификаций называются «преобразованиями». ESP не определяет эти преобразования — они задаются в других спецификациях. Читателю можно рекомендовать одну из таких.

Наверх