3.4.4. Проверка ICV
Как и при обработке исходящих пакетов, имеется несколько вариантов, зависящих от используемого алгоритма.
3.4.4.1. Раздельные алгоритмы конфиденциальности и целостности
При использовании раздельных алгоритмов конфиденциальности и целостности выполняются перечисленные ниже операции.
- 1. Если выбрана функция контроля целостности, получатель рассчитывает значение ICV для пакета ESP без самого поля ICV, используя заданный алгоритм контроля целостности и сравнивает полученное значение со значением поля ICV а пакете. Подробное описание расчета приведено ниже. Если рассчитанное значение ICV совпадает с полученным в пакете, это говорит о корректности дейтагараммы и она принимается. При отрицательном результате проверки получатель должен отбросить полученную дейтаграмму IP, как некорректную, и внести запись в журнал аудита. В запись следует включать значение SPI, дату и время получения пакета, адреса получателя и отправителя, порядковый номер и незашифрованное значение Flow ID (для IPv6).
Примечание для разработчиков: Разработчики могут использовать любую последовательность действий, которая дает такой же результат, как перечисленные здесь операции. Сначала значение ICV из принятого пакета сохраняется и заменяется нулем. После этого проверяется общий размер пакета ESP без учета ICV. Если требуется неявное заполнение по размеру блока алгоритма контроля целостности, добавляются нулевые байты в конце пакета ESP ESP ESP ESP сразу же вслед за полем Next Header или после старших 32 битов порядкового номера в случае использования ESN. Выполняется расчет ICV и полученный результат сравнивается с сохраненным значением. Правила сравнения задаются спецификацией алгоритма контроля целостности.
- 2. Получатель дешифрует в пакете ESP поля Payload Data, Padding, Pad Length и Next Header, используя ключ, алгоритм, режим и данные криптографической синхронизации (если они нужны) в соответствии с SA. Как и в параграфе 3.3.2, мы говорим о том, что шифрование применяется всегда, поскольку оно влияет на формат. При этом предполагается, что может использоваться режим «без шифрования» с пустым (NULL) алгоритмом шифрования (RFC 2410).
- – Если явно указаны данные криптографической синхронизации (например, IV), эти данные берутся из поля Payload и передаются на вход алгоритма дешифровки в соответствии со спецификацией алгоритма.
- – Если указаны неявные данные криптографической синхронизации, создается локальная версия IV и передается на вход алгоритма дешифровки в соответствии со спецификацией алгоритма.
- 3. Получатель обрабатывает поля заполнения (Padding) в соответствии со спецификацией алгоритма шифрования. Если используется принятая по умолчанию схема заполнения (смю параграф 2.4, получателю следует проверить поле Padding до удаления заполнения перед передачей расшифрованных данных на следующий уровень.
- 4. Получатель проверяет поле Next Header. Если значение поля расно 59 (нет следующего заголовка), (фиктивный) пакет отбрасывается без дальнейшей обработки.
- 5. Получатель восстанавливает исходную дейтаграмму IP:
- – для транспортного режима — внешний заголовок IP плюс исходная информация протокола следующего уровня в поле ESP Payload;
- – для туннельного режима — вся дейтаграмма IP в поле ESP Payload.
- Конкретные действия по восстановлению исходной дейтаграммы зависят от режима (транспортный или туннельный) и описаны в документе по архитектуре защиты. По минимуму в контексте IPv6 получателю следует обеспечить для расшифрованных данных выравнивание по 8-байтовой границе для упрощения обработки протокола, указанного в поле Next Header. При этой обработке «отбрасывается» все (необязательное) заполнение TFC, которое было добавлено для обеспечения конфиденциальности потока трафика.
Если проверка целостности выполняется параллельно с дешифровкой, контроль целостности должен быть завершен до передачи расшифрованного пакета на дальнейшую обработку. Такой порядок упрощает быстрое детектирование и отбрасывание повторных или обманных пакетов до их дешифровки, что потенциально может снижать воздействие атак на службы.