Семейство протоколов IPSec

Разбить на страницы

Показывать лекцию целиком

Назначение семейства протоколов IPSec

Рассмотрим архитектуру семейства протоколов IPSec. Цель данного семейства протоколов состоит в том, чтобы обеспечить различные сервисы безопасности на уровне IP для протоколов IPv4 и IPv6. Рассмотрим серви-сы безопасности, предоставляемые протоколами IPSec, и использование этих протоколов в сетях ТСР/IP.

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

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

IPSec может быть реализован как в ОС, так и в маршрутизаторе или межсетевом экране.

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

Перечислим основные задачи протоколов IPSec:

Обеспечение криптографической защиты на уровне IP для протоколов IPv4 и IPv6, а именно обеспечение конфиденци-альности и целостности данных и целостности некоторой по-следовательности дейтаграмм.

Обеспечение прозрачности для IP-трафика, для которого не требуется использование протоколов IPSec.

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

IPSec предназначен для безопасного взаимодействия с использованием криптографии для протоколов IPv4 и IPv6. Сервисы безопасности включают управление доступом, целостность и конфиденциальность данных и защиту от replay-атак, которая обеспечивается гарантированием целостности некоторой последовательности дейтаграмм. Эти сервисы предоставляются на уровне IP, обеспечивая защиту для IP-протокола и протоколов более высокого уровня.

IPSec поддерживает две формы целостности: целостность данных и целостность определенной последовательности дейтаграмм. Целостность данных обнаруживает модификацию конкретной IP-дейтаграммы, безотносительно последовательности дейтаграмм в потоке трафика. Целостность последовательности дейтаграмм является анти-reply сервисом, с помощью которого определяется получение дубликатов IP-дейтаграмм. Это отлича-ется от обеспечения целостности соединения, для которого существуют более строгие требования к целостности трафика, а именно, возможность определения потерянных или переупорядоченных сообщений.

Рассмотрим выполнение протоколов IPSec, основные компоненты системы и их взаимодействие для обеспечения сервисов безопасности.

IPSec выполняется на хосте (Host – H) или шлюзе безопасности (Security Gateway – SG), обеспечивая защиту IP-трафика. Термин "шлюз безопасности" используется для обозначения маршрутизатора, который реализует IPsec-протоколы.

Защита основана на требованиях, определенных в базе данных политики безопасности (Security Policy Database - SPD), устанавливаемой и поддерживаемой администратором. В общем случае пакеты обрабатываются одним из трех способов, основанных на информации IP-заголовка и транспортного уровня в соответствии с записями в SPD. Каждый пакет либо отбрасывается, либо пропускается без обработки, либо обрабатывается в соответствии с записью SPD для данного пакета.

Возможные способы реализации IPSec

Существует несколько способов реализации IPSec на хосте или совместно с маршрутизатором или межсетевым экраном (для создания шлюза безопасности).

нтеграция IPSec в конкретную реализацию протокола IP. Это требует доступа к исходному коду IP и делается как на хостах, так и на шлюзах безопасности.

"Bump-in-the-stack" (BITS) реализации, когда IPSec реализован "внизу" существующей реализации стека IP-протоколов, встраивая свою реализацию между стандартной реализацией IP-протоколов и локальными сетевыми драйверами. Доступа к исходному коду стека IP в данном случае не требуется. Данный подход обычно реализуется на хостах, когда IPSec реализован в виде подключаемой библиотеки.

Использование внешнего криптопроцессора. Обычно это называется "Bump-in-the-wire" (BITW) реализацией. Такие реализации могут использоваться как на хостах, так и на шлюзах. Обычно BITW-устройства являются IP-адресуемыми.

Протоколы защиты трафика и понятие безопасной ассоциации

Предоставляемые IPSec сервисы по защите трафика реализуются с помощью двух протоколов обеспечения безопасного трафика: Authentication Header (AH) и Encapsulating Security Payload (ESP).

Для защиты трафика в IPSec определены следующие протоколы:

Протокол Encapsulating Security Payload (ESP) обеспечивает конфиденциальность и целостность протоколов, расположенных выше в стеке протоколов и дополнительно может обеспечиваться анти-replay сервис, т.е. целостность некоторой последовательности дейтаграмм.

Протокол Authentication Header (AH) обеспечивает целостность протоколов, расположенных выше в стеке протоколов и целостность отдельных полей IP-заголовка, которые не изменяются при пересылке от отправителя к получателю, дополнительно может обеспечиваться анти-replay сервис, т.е. целостность некоторой последовательности дейтаграмм. В IPSec v2 реализация данного протокола не является обязательной.

Параметры этих протоколов определяются в протоколе распределения ключей Internet Key Exchange (IKE).

С трафиком, безопасность которого обеспечивается IPSec, связано понятие безопасной ассоциации (Security Association – SA). SA содержит всю информацию, необходимую для выполнения различных сетевых сервисов безопасности.

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

Опишем различные аспекты управления SA, определим возможные способы управления политикой безопасности, способы обработки трафика и управления SA.

SA определяет параметры сервисов безопасности, которые применяются к трафику. В обычном случае при двунаправленном соединении между двумя хостами или между двумя шлюзами безопасности требуется две SA (по одной на каждое направление).

Будем рассматривать SA только для одноадресных соединений.

Определены два режима SA: режим транспорта и режим туннелирования. Транспортный режим используется для создания VPN между двумя хостами. В IPv4 заголовок протокола безопасности транспортного режима появляется сразу после IP-заголовка. В протоколе ESP транспортный ре-жим SA обеспечивает сервисы безопасности только для протоколов более высокого уровня, но не для IP-заголовка. В случае АН защита распространяется также и на отдельные части IP-заголовка.

Другим режимом SA является режим туннелирования. Если одним из концов соединения является шлюз безопасности, то по стандартам IPSec SA обязательно должна выполняться в туннельном режиме, но многие производители допускают в этом случае как туннельный, так и транспортный режимы. Заметим, что когда трафик предназначен для шлюза безопасности, например, в случае ping- или SNMP-команд, шлюз безопасности рассматривается как хост, и как правило используется транспортный режим. Два хоста могут при необходимости устанавливать туннельный режим.

В туннельном режиме добавляется внешний IP-заголовок, адресами в котором являются шлюзы безопасности. Внутренний IP-заголовок указывает на конечные хосты. Заголовок протокола безопасности расположен после внешнего IP-заголовка и перед внутренним IP-заголовком. Если АН используется в туннельном режиме, части внешнего IP-заголовка являются защищенными, как и весь туннелируемый IP-пакет, т.е. все внутренние заголовки защищены, как и все протоколы более высокого уровня. Если применяется ESP, защита обеспечивается только для туннелируемого пакета, а не для внешнего заголовка.

Кратко подытожим:

Хост может поддерживать оба режима, как транспортный, так и туннельный.

Шлюз безопасности как правило использует только туннель-ный режим. Если он поддерживает транспортный режим, то этот режим как правило используется только тогда, когда без-опасный шлюз является получателем трафика, например, для управления сетью.

Набор реализуемых SA сервисов безопасности зависит от выбранного протокола безопасности, режима SA, конечных точек SA и выбора дополнительных сервисов в протоколе. Например, АН обеспечивает целостность исходных данных и целостность соединения для IP-дейтаграмм. "Детализированность" сервиса определяется степенью детализованности SA, для которой используется протокол.

На каждом сетевом интерфейсе, поддерживающим IPSec, должны создаваться две базы данных: БД Политики Безопасности (SPD) и БД Безопасных Ассоциаций (Security Association Database – SAD). Первая определяет политики, которые применяются для обработки всего IP-трафика. Вторая БД содержит параметры, которые связаны с каждой активной безопасной ассоциацией. Для обработки трафика определяется понятие Селектора, который задает множества значений полей протоколов более высокого уровня, используемых для определения соответствия записи в SPD конкретному трафику.

Для широкого использования IPSec требуется стандартный, масштабируемый протокол создания и управления SA. Таким протоколом является протокол Internet Key Exchange – IKE. Протокол состоит из двух фаз – фаза I и фаза II. Каждая фаза состоит из обмена несколькими сообщениями. Каждое сообщение в свою очередь состоит из нескольких содержимых (payload). В результате выполнения фазы I создается IKE SA. В результате выполнения фазы II создается одна или несколько ESP SA или AH SA.

Для описания форматов передаваемых сообщений используется стандарт, называемый "Безопасная Ассоциация Интернет и Протокол Управления Ключом - Internet Security Association and Key Management Protocol (ISAKMP)". ISAKMP определяет форматы пакетов для ведения переговоров об установлении, изменении и удалении SA.

Понятие домена IPSec

Понятие домена IPSec (Domain of Interpretation - DOI) вводится для то-го, чтобы можно было сгруппировать относящиеся к IPSec протоколы, использующие IKE для ведения переговоров о SA. Протоколы безопасности, относящиеся к одному DOI-домену, выбирают протокол безопасности и криптографические преобразования из общего пространства имен и используют общие идентификаторы в протоколе создания SA. Они также одинаково интерпретирует данные, содержащиеся в различных сообщениях.

При описании домена определяются следующие понятия:

Схема именования идентификаторов протоколов.

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

Синтаксис атрибутов SA.

Синтаксис содержимого сообщений.

Возможные типы обмена ключа.

Возможные типы сообщений уведомлений (Notification).

Все идентификаторы, используемые в IPSec, зарегистрированы в IANA. Все данные хранятся в сетевом порядке байтов.

Определение условий, при которых выполняется

В заголовке сообщений существует поле Situation, в котором содержится информация, на основе которой Получатель может сделать вывод о требованиях политики по обработки входящего трафика SA. Для IPSec-домена DOI определены следующие значения:

Условие			Значение 
SIT_IDENTITY_ONLY	0х01
SIT_SECRECY		0x02
SIT_INTEGRETY		0x04

Условие SIT_IDENTITY_ONLY

Условие SIT_IDENTITY_ONLY указывает, что безопасная ассоциация определяется идентификационной информацией источника, которая находится в содержимом SA. Определены несколько типов идентификаций, пе-редаваемых в содержимом Identification, которое посылается в фазе I IKE.

Если Инициатор не поддерживает ни SIT_SECRECY, ни SIT_INTEGRETY, то метка DOI может не передаваться.

(рис 7.1) Пример поля Situation

Условие SIT_SECRECY

Условие SIT_SECRECY указывает, что SA устанавливается в окружении, в котором требуется защита. Поле Situation содержит значение требуемого уровня чувствительности.

Если Получатель не поддерживает SIT_SECRECY, то он должен передать SITUATION-NOT-SUPPORTED Notification. В этом случае SA установлено не будет.

Условие SIT_INTEGRETY

Условие SIT_INTEGRETY указывает, что SA устанавливается в окружении, в котором требуется обеспечение целостности. Поле Situation содержит значение требуемого уровня целостности.

Если Получатель не поддерживает SIT_INTEGRETY, то он должен передать SITUATION-NOT-SUPPORTED Notification. В этом случае SA установлено не будет.

Возможные топологии IPSec

С помощью протоколов IPSec можно реализовать различные топологии VPN. Основные топологии позволяют создавать следующие VPN:

Шлюз безопасности – шлюз безопасности.

Хост – шлюз безопасности.

Хост – хост.

Приведем четыре варианта топологий VPN, создаваемых между хостами и шлюзами безопасности, которые реализуют IPSec. Введем следующие обозначения:

Таблица 7.1

Рассматриваемые ниже безопасные ассоциации могут использовать как АН-, так и ESP-протоколы. Режим (туннельный или транспортный) определяется характером конечных точек. Для Host - Host SA режим может быть как транспортным, так и туннельным. Для SG - SG SA режим скорее всего будет туннельным.

Вариант 1. Создание безопасного соединения между двумя хостами через открытую публичную сеть.

(рис 7.2) Топология сети: VPN между двумя хостами

В данном случае между хостами может использоваться как транспортный, так и туннельный режим. Заголовки в пакете между Host 1 и Host 2 выглядят следующим образом:

(рис 7.3) . Вложенность заголовков при создании VPN между двумя хостами

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

В данной топологии маршрутизаторы (Rtr 1 и Rtr 2) не поддерживают IPSec, т.е. не являются шлюзами безопасности (SG), и не могут анализировать трафик, передаваемый междуHost 1 и Host 2. Если эти маршрутизаторы также выполняют функции межсетевого экрана, то они должны пропускать весь IPSec-трафик, как трафик управления SA, так и трафик протоколов АН или ESP.

Трафик между Host 1 и Host 2 защищен сервисами безопасности как в публичной сети, так и в обеих локальных сетях. IP-адреса хостов видны как в публичной сети, так и в обеих локальных сетях.

Вариант 2. Создание виртуальной частной сети между двумя удален-ными локальными сетями.

(рис 7.4) Топология сети: VPN между двумя локальными сетями

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

(рис 7.5) Вложенность заголовков при создании VPN между двумя локальными сетями

В данной топологии хосты в локальных сетях не поддерживают IPSec, и, как следствие, трафик в локальных сетях не защищен от внутренних (insider) атак. Трафик в публичной сети защищен. IP-адреса хостов в локальной сети не видны в публичной сети.

Вариант 3. Создание безопасного соединения между двумя хостами с возможностью частичного анализа и фильтрования трафика на шлюзах безопасности.

(рис 7.6) Топология сети: VPN с возможностью анализа трафика на шлюзе безопасности

Создаются две вложенные SA. Одна между хостами Host 1 и Host 2, другая между шлюзами безопасности SG 1 и SG 2. В этом случае трафик будет защищен как в публичной, так и в локальной сетях, и шлюзы безопасности смогут частично анализировать и фильтровать трафик, передаваемый в и из локальных сетей.

На шлюзах безопасности должен использоваться туннельный режим. На хостах правильнее использовать транспортный режим.

Вариант 4. Безопасное подключение удаленного пользователя к ло-кальной сети организации с возможностью частичного анализа и фильтро-вания трафика на шлюзе безопасности (рис. 7.7).

В этом случае создаются две вложенные SA: одна между удаленным хостом Host 1 и хостом в локальной сети Host 2 (SA 1), вторая между удаленным хостом Host 1 и шлюзом безопасности SG 2 (SA 2). В результате трафик защищен как в интернете (SA 2), так и в локальной сети (SA 1). Удаленный хост (Нost 1) использует интернет для достижения межсетевого экрана организации (SG 2) и затем получает доступ к некоторому хосту (Нost 2) в локальной сети. Между Нost 1 и SG 2 используется режим туннелирования. Для SA между SG 2 и Нost 2 возможен как транспортный, так и туннельный режимы.

(рис 7.7) Топология сети: защищенный доступ пользователя в локальную сеть

В данной топологии защищаемая конечная точка (обычно портативный переносной компьютер) соединяется со своей корпоративной сетью через IPSec-туннель. Конечная точка использует данный туннель для доступа в корпоративную сеть, после этого трафик может туннелироваться через локальную сеть, чтобы защитить его и в локальной сети. В этом случае существует возможность фильтрования трафика корпоративным межсетевым экраном. Конечная точка должна иметь IP-адрес, известный межсетевому экрану, чтобы он мог пропускать пакеты через межсетевой экран и туннелировать их далее. Данный IP-адрес может быть статический или может задаваться динамически какой-либо из технологий, аналогичных DHCP. Для поддержки второго варианта существует механизм, дающий возможность Инициатору запрашивать IP-адрес, принадлежащий межсетевому экрану для использования с SA, создаваемой в локальной сети.

Другие топологии

Возможны также другие топологии. Например, возможно использова-ние совместно с IPSec других протоколов туннелирования, таких как GRE или L2TP.

Степень детализации управления трафиком

IPSec позволяет управлять детализацией, с которой предоставляется сервис безопасности. Например, можно создать единственный зашифрованный туннель между двумя локальными сетями, или для каждого ТСР- и UDP-соединения может быть создан отдельный зашифрованный туннель между парой хостов. IPSec позволяет указывать следующие параметры:

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

(рис 7.8) Пример веб-интерфейса для указания степени детализации создания SA

Используемые алгоритмы в протоколах обеспечения безопасности IP-трафика.

(рис 7.9) Пример веб-интерфейса для указания требуемых алгоритмов в протоколах защиты трафика

Используемые алгоритмы в протоколах управления SA.

(рис 7.10) Пример веб-интерфейса для указания требуемых алгоритмов в протоколах управления SA

Протокол ESP

Обзор

Протокол ESP разработан для обеспечения возможности использования нескольких сервисов безопасности в IPv4 и IPv6.

ESP-заголовок вставляется после IP-заголовка и перед заголовком протокола более высокого уровня (транспортный режим) или перед инкапсулированным IP-заголовком (туннельный режим).

ESP используется для обеспечения конфиденциальности, аутентификации данных, целостности соединения и анти-replay сервиса (обеспечение целостности некоторой последовательности дейтаграмм).

Формат пакета ESP

Заголовок протокола (IPv4, IPv6 или Extension), непосредственно предшествующий ESP, содержит значение 50 в поле Protocol (IPv4) или Next Header (IPv6, Extension).

(рис 7.11) Пример вложенности ESP-пакета

(рис 7.12) Формат ESP-пакета

Данные (Payload Data)

Payload Data является полем переменной длины, содержащим данные протокола, расположенного выше в стеке, который указан в поле Next Header. Длина данного поля равна целому числу байтов. Если алгоритм, используемый для шифрования, требует криптографически синхронизованных данных, например инициализационный вектор IV, то эти данные также содержатся в этом поле.

Добавление (Padding)

Использование поля Padding объясняется несколькими факторами.

Если используемый алгоритм шифрования требует, чтобы незашифрованный текст был кратен определенному количеству байтов, например, размеру блока для блочных алгоритмов, то поле Padding используется для дополнения незашифрованных данных (состоящих из полей Payload Data, Pad Length и Next Header) до размера, требуемого алгоритмом.

Добавление может также требоваться независимо от алгоритма шифрования для гарантирования того, что полученные зашифрованные данные завершаются на 4-байтой границе. Поля Pad Length и Next Header должны быть таким образом расположены в 4-байтном слове, чтобы гарантировать, что поле Authentication Data привязано к 4-байтной границе.

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

Длина добавления (Pad Length)

Поле Pad Length указывает число байтов добавления, которые непосредственно следуют за ним.

Следующий заголовок (Next Header)

Next Header является 8-битовым полем, которое указывает тип данных, содержащихся в поле Payload Data, например, заголовок Extension в IPv6 или идентификатор протокола более высокого уровня. Значение данного поля выбирается из множества IP Protocol Number, определяемого IANA.

Аутентификационные данные (Authentication Data)

Authentication Data является полем переменной длины, содержащим значение проверки целостности (Integrity Check Value – ICV), вычисленное для ESP-пакета, за исключением самого поля Authentication Data. Длина поля определяется выбранным алгоритмом аутентификации. Поле Authentication Data является необязательным и включается в том случае, если используется сервис аутентификации.

Обработка трафика, выполняемая ESP

Рассмотрим расположение заголовка ESP относительно заголовков других протоколов.

Протокол ESP может использоваться в двух режимах: в транспортном режиме и туннельном. Первый режим применяется в основном для создания VPN между двумя хостами и обеспечивает защиту для протоколов более высокого уровня, но не для заголовка IP. Заметим, что в данном режиме для "bump-in-the-stack" и "bump-in-the-wire" реализаций может потребоваться реассемблирование входящих и исходящих IP-фрагментов.

В транспортном режиме ESP-заголовок расположен после IP-заголовка и перед заголовком протокола более высокого уровня, например, ТСР, UDP, ICMP и т.д. Следующие рисунки показывают добавление заголовков в транспортном режиме ESP для типичного IPv4 пакета.

(рис 7.13) Вложенность заголовков до применения ESP в транспортном режиме в IPv4

(рис 7.14) Вложенность заголовков после применения ESP в транспортном режиме в IPv4

В протоколе IPv6 ESP рассматривается как end-to-end содержимое, и таким образом оно должно появляться после hop-by-hop, routing и fragmentation заголовков расширения. Заголовки параметров назначе-ния могут появляться как до, так и после ESP заголовка, в зависимости от требуемой семантики. Однако, так как ESP защищает только поля после ESP-заголовка, обычно требуется размещение заголовков опций назначения после ESP-заголовка. Следующие рисунки иллюстрируют добавление заголовков в транспортном режиме ESP для типичного IPv6-пакета.

(рис 7.15) Вложенность заголовков до применения ESP в транспортном режиме в IPv6

(рис 7.16) Вложенность заголовков после применения ESP в транспортном режиме в IPv6

* - если присутствует, то может быть до ESP, после ESP или и так, и так.

Туннельный режим ESP может быть реализован как на хостах, так и на шлюзах безопасности. При использовании ESP на шлюзе безопасности для защиты транзитного трафика должен применяться туннельный режим. В туннельном режиме внутренний IP-заголовок содержит конечные адреса источника и получателя, а внешний IP-заголовок содержит IP-адреса шлю-зов безопасности. В туннельном режиме ESP защищает весь внутренний IP-пакет, включая весь внутренний IP-заголовок. Расположение ESP в тун-нельном режиме относительно внешнего IP-заголовка является тем же са-мым, что и для транспортного режима. Следующие рисунки иллюстрируют добавление заголовков в туннельном режиме ESP для типичных IPv4- и IPv6-пакетов.

(рис 7.17) Вложенность заголовков после применения ESP в туннельном режиме в IPv4

(рис 7.18) Вложенность заголовков после применения ESP в туннельном режиме в IPv6

Алгоритмы

Определены алгоритмы, обязательные для реализации. Кроме них дополнительно могут быть реализованы и другие алгоритмы.

1. Алгоритмы шифрования

Алгоритмы шифрования определяются при создании SA и применяются для шифрования данных, передаваемых по SA. В протоколе ESP используются симметричные алгоритмы шифрования. Так как IP-пакеты могут приходить в любом порядке, каждый пакет должен содержать всю инфор-мацию, необходимую Получателю для расшифрования. Эти данные, например инициализационный вектор (IV), могут передаваться явно в поле содержимого или они могут быть получены из заголовка пакета.

2. Алгоритмы аутентификации (обеспечения целостности)

Алгоритм аутентификации, используемый для вычисления Integrity Check Value (ICV), определяется при создании SA. Для вычислений точка-точка соответствующие алгоритмы аутентификации используют МАС с ключом, основанный на симметричных алгоритмах шифрования (например, DES) или на односторонних хэш-функциях (например, MD5 или SHA-1). Для многоадресных соединений односторонние хэш-функции используются вместе с асимметричными алгоритмами создания цифровой подписи.

Обработка исходящего пакета

В транспортном режиме Отправитель инкапсулирует информацию протокола верхнего уровня в ESP-заголовок и сохраняет без изменения IP-заголовок (и любые IP-заголовки расширения в протоколе IPv6). В туннельном режиме внешний и внутренний IP-заголовки могут по-разному соотноситься друг с другом.

1. Поиск подходящей SA

ESP применяется к исходящему пакету после того, как определено, какой SA принадлежит пакет.

2. Шифрование пакета

Отправитель выполняет следующие действия:

Инкапсуляция в поле ESP Payload:

Для транспортного режима – только исходная информация протокола верхнего уровня.

Для туннельного режима – вся исходная IP-дейтаграмма.

Добавление необходимого дополнения (поле Padding).

Шифрование полученных данных (Payload Data, Padding, Pad Length, Next Header), используя ключ, алгоритм шифрования, режим алгоритма, указанные в SA.

Первым выполняется шифрование, затем выполняется аутентификация (обеспечение целостности), поэтому поле Authentication Data не за-шифровано. Такой порядок обработки дает возможность Получателю быстро обнаружить и отбросить повторные или фиктивные пакеты, что потенциально снижает вероятность успешного выполнения DoS-атак. Это также допускает возможность параллельной обработки пакетов Получате-лем, например, расшифрование может выполняться одновременно с проверкой целостности. Заметим, что, так как Authentication Data не защищено шифрованием, для вычисления ICV должен применяться алгоритм обеспечения целостности с ключом.

3. Вычисление Sequence Number

Первый пакет, посылаемый по заново созданной SA, имеет Sequence Number, равный 1.

Если используется анти-replay сервис, отправитель проверяет, что значение счетчика не переполнилось перед созданием нового значения в поле Sequence Number. Другими словами, отправитель не должен посылать пакет по SA, если возникает переполнение Sequence Number.

Отправитель повторяет пакет, если он не получил уведомления о его получении. Если счетчик переполнился, отправитель должен установить новую SA и вычислить новые ключи.

4. Вычисление значения проверки целостности

Если для SA требуется обеспечение целостности, Отправитель вычисляет ICV для всего ESP-пакета, за исключением поля Authentication Data. Таким образом, для полей SPI, Sequence Number, Payload Data, Padding (если присутствует) и Next Header вычисляется ICV. Заметим, что последние четыре поля являются зашифрованными, так как шифрование выполняется до вычисления ICV.

Для некоторых алгоритмов обеспечения целостности строка байтов, для которой вычисляется ICV, должна быть кратна длине блока выбранного алгоритма. Если длина данной строки байтов не соответствует требуемой длине блока, то должно выполняться добавление в конец ESP-пакета (после поля Next Header) до вычисления ICV. Октеты добавления должны иметь нулевые значения. Длина блока (и, следовательно, длина добав-ления) определяются из спецификации алгоритма. Данное добавление не передается вместе с пакетом.

5. Фрагментация

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

Для транспортного режима bump-in-the-stack и bump-in-the-wire реализации могут, во-первых, реассемблировать пакет, фрагментированный локальным IP-уровнем, затем применять IPSec и затем снова фрагментировать получившейся пакет.

Обработка входящего пакета

Реассемблирование

Если требуется реассемблирование, то оно выполняется до ESP-обработки.

Поиск подходящей SA

При получении пакета, содержащего ESP-заголовок, Получатель определяет подходящую однонаправленную SA, просматривая SAD. Для одноадресных SA это определяется на основе значения SPI в заголовке. В записи SAD указано, следует ли проверять последовательный номер. Также в записи SAD указаны алгоритмы и ключи, используемые для расшифрования.

Если для данного пакета не существует SA, Получатель отбрасывает пакет. В этом случае данное событие записывается в лог с указанием SPI, даты и времени получения, адресов отправителя и получателя, последовательного номера и, возможно, другой информации.

Заметим, что трафик управления SA, такой как IKE-пакеты, не идентифицируются SPI.

Проверка последовательного номера

В основе анти-replay сервиса лежит проверка корректного значения последовательного номера. Получатель проверяет, что пакет содержит последовательный номер, который не является дубликатом последовательного номера другого пакета, полученного в данной SA. Такая проверка выполняется первой, после того как найдена соответствующая SA, чтобы как можно быстрее отбросить дублирующие пакеты.

Страницы: