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

2.4. Padding — заполнение (для шифрования)

Использование поля Padding обусловлено двумя основными факторами:

  • Если алгоритм шифрования требует, чтобы размер шифруемых данных был кратен некоторому целому числу байтов (например, размер блока при блочном шифровании), поле Padding используется для требуемого алгоритмом выравнивания нешифрованных данных (поля Payload Data, Padding, Pad Length и Next Header) до требуемого алгоритмом размера.
  • Заполнение может потребоваться и без связи с алгоритмом шифрования для обеспечения выравнивания зашифрованных данных по 4-байтовой границе. В частности, поля Pad Length и Next Header должны быть выравниваться по 4-байтовой границе, как показано выше на рисунке, описывающем формат пакетов ESP, для обеспечения выравнивания поля ICV (если оно используется) по 4-байтовой границе.

Независимо от приведенных выше требований заполнение может служить для сокрытия действительного размера зашифрованных данных с целью поддержки конфиденциальности потока трафика (TFC). Однако описываемое здесь поле Padding слишком мало для эффективной реализации TFC, поэтому его не следует использовать с такой целью. Для обеспечения конфиденциальности потока следет использовать специальный механизм, описанный ниже (см. параграф 2.7).

Отправитель может добавлять в поле заполнения от 0 до 255 байтов. Включение поля Padding в пакет ESP является необязательным (в соответствии с приведенными выше требованиями), но каждая реализация должна поддерживать генерацию и восприятие поля заполнения.

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

Если поле Padding требуется, но алгоритм шифрования не задает содержимого заполнения, должна использоваться описанная ниже обработка, принятая по умолчанию. Байты Padding инициализируются последовательностями целочисленных значений (1 байт, без знака). Первый байт заполнения, добавляемый в конце шифрованных данных, имеет номер 1, а номера последующих байтов монотонно возрастают на единицу, образуя последовательность 1, 2, 3, .... При использовании такой схемы заполнения получателю следует проверять поле Padding (эта схема была выбрана за ее относительную простоту, возможность аппаратной реализации и наличие некоторой защиты от ряда форм атак «cut and paste» в отсутствии механизмов контроля целостности, если получатель проверяет заполнение до расшифровки).

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

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