RFC: 4303
Оригинал: IP Encapsulating Security Payload (ESP)
Предыдущие версии: RFC 1827, RFC 2406
Категория: Предложенный стандарт
Дата публикации:
Автор:
Перевод: Николай Малых
3.3.2.1. Раздельные алгоритмы конфиденциальности и целостности

При использовании раздельных алгоритмов шифрования и контроля целостности отправитель выполняет перечисленные ниже операции.

  1. Инкапсуляция (в поле ESP Payload Data):

    • для транспортного режима — исходная информация протокола следующего уровня;
    • для туннельного режима — исходная дейтаграмма IP.
  2. Добавление требуемого заполнения — необязательное заполнение TFC и заполнение для шифрования.

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

    • Если указаны явные данные криптографической синхронизации (например, IV), они являются входной информацией для алгоритма шифрования в соответствии с его спецификацией и помещаются в поле Payload.
    • Если используются неявные данные криптографической синхронизации, эти данные создаются и передаются на вход алгоритма шифрования в соответствии с его спецификацией.
    • Если выбран контроль целостности, сначала выполняется шифрование, которое не затрагивает поля ICV. Такой порядок обработки упрощает быстрое обнаружение и отбрасывание повторно используемых или фиктивных пакетов до их расшифровки, потенциально снижая влияние атак на службы (DoS). Это также обеспечивает возможность параллельной обработки пакетов на принимающей стороне (т. е., дешифровка может выполняться одновременно с контролем целостности). Отметим, что результатом отсутствия защиты поля ICV с помощью шифрования, является необходимость использования для расчета ICV алгоритма контроля целостности с поддержкой ключей.
  4. Расчет ICV для пакета ESP без учета самого поля ICV. Таким образом, при вычислении ICV принимаются во внимание поля SPI, Sequence Number, Payload Data, Padding (если используется), Pad Length и Next Header. Если для SA выбрана опция ESN, старшие 32 бита порядкового номера добавляются при расчете после поля Next Header, но не передаются в пакете.

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

2007 - 2018 © Русские переводы RFC, IETF, ISOC.