Семейство протоколов IPSec
Алгоритмы
Определены алгоритмы, обязательные для реализации. Кроме них дополнительно могут быть реализованы и другие алгоритмы.
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, чтобы как можно быстрее отбросить дублирующие пакеты.