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

2.3. Payload Data — данные

Поле переменного размера Payload Data содержит данные (из исходного пакета IP), указываемые полем Next Header. Поле Payload Data является обязательным и размер его составляет целое число байтов. Если алгоритм, используемый для шифрования данных, требует данных криптографической синхронизации (например, вектор инициализации - - IV), эти данные явно передаются в поле Payload, но не рассматриваются в качестве отдельного поля в ESP (т. е., передача явного IV невидима для ESP — см. Рисунок 2). Любой алгоритм шифрования, требующий таких явных данных синхронизации для каждого пакета, должен указывать размер и структуру таких данных, а также их местоположение в RFC, содержащем спецификацию использования алгоритма с ESP. Обычно IV помещается непосредственно перед зашифрованным текстом (см. Рисунок 2). Если данные синхронизации передаются неявно, алгоритм их выделения должен быть описан в RFC с определением алгоритма шифрования. Если неявные данные криптографической синхронизации (например, вектор инициализации — IV) включаются в поле Payload, обычно эти данные не шифруются (см. таблицы 1 и 2), хотя в некоторых случаях о них говорят, как о части шифрованных данных.

Отметим, что начало заголовка протокола следующего уровня должно быть выровнено относительно заголовка ESP — для IPv4 выравнивание выполняется по 4-байтовой границе, для IPv6 — по 8-байтовой.

В части выравнивания (действительно) зашифрованных данных при наличии IV отметим следующее:

  • Для некоторых режимов работы на базе IV получатель трактует IV, как начало шифрованных данных, передавая вектор инициализации в алгоритм напрямую. В таких случаях идентификация начала (действительно) шифрованных данных не вызывает проблем на приемной стороне.
  • В некоторых случаях получатель считывает IV независимо от шифрованных данных. В таких случаях алгоритм должен указывать способ идентификации начала (действительно) шифрованных данных.
2007 - 2017 © Русские переводы RFC, IETF, ISOC.