2. Формат пакетов ESP
В заголовок (внешний) протокола (IPv4, IPv6, Extension), непосредствен-но предшествующий заго-ловку ESP, следует включать значение 503 в поле Protocol (IPv4) или Next Header (IPv6, Extension). Рисунок 1 показывает верхний уровень формата пакетов ESP. Пакет начинается с двух 4-байтовых полей (SPI 4 и Sequence Number5). Вслед за ними размещается поле данных Payload Data, структура которого зависит от выбора алгоритма шифро-вания и режима, а также заполнения TFC, детально описанного ниже. Вслед за полем Payload Data размещается поле запол-нения (Padding), поле размера заполнения (Pad Length) и поле Next Header (следующий заголовок). Дополнительно в конце пакета может помещаться значение ICV.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---- | Security Parameters Index (SPI) | ^Int. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- | Sequence Number | |ered +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ---- | Payload Data* (variable) | | ^ ~ ~ | | | | |Conf. + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- | | Padding (0-255 bytes) | |ered* +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Pad Length | Next Header | v v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------ | Integrity Check Value-ICV (variable) | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * При наличии в поле Payload данных криптографической синхронизации (например, вектора инициализации - IV, описанного в параграфе 2.3) эти данные обычно не шифруются, хотя о них зачастую говорят, как о части шифрованных данных.
Трейлер (передаваемый) ESP содержит поля Padding, Pad Length и Next Header. В дополнение к этим полям включаются неявные данные трейлера ESP (не передаются), используемые для контроля целостности, как описано ниже.
При выборе контроля целостности контрольная сумма дополняет поля SPI, Sequence Number, Payload Data и трейлер ESP (явный и неявный).
При выборе услуг конфиденциальности шифруется поле Payload Data (за исключением данных криптографической синхронизации, которые могут быть включены, но не шифруются) и (явный) трейлер ESP.
Как отмечено выше, поле Payload Data может иметь дополнительную структуру. Алгоритмы шифрования, которым требуется явный вектор инициализации IV (например, CBC), часто используют эти данные в качестве префикса защищаемых данных (Payload Data). Некоторые алгоритмы объединяют шифрование и контроль целостности в одну операцию — здесь такие алгоритмы будут называться комбинированными. Приспособление таких алгоритмов требует от алгоритма явного описания структуры Payload Data, используемой для передачи данных контроля целостности.
Некоторые комбинированные алгоритмы обеспечивают целостность только для шифрованных данных, тогда как другие могут обеспечивать целостность неких дополнительных данных, которые не шифруются для передачи. Поскольку поля SPI и Sequence требуют контроля целостности и не шифруются, необходимо обеспечить их целостность, независимо от выбранных услуг и стиля работы комбинированного алгоритма.
При использовании комбинированного алгоритма предполагается, что этот алгоритм сам по себе будет возвращать шифрованные данные и результат проверки целостности. Для комбинированных алгоритмов значение ICVЭ обычно находящее в конце пакета ESP (когда выбран контроль целостности), можно опустить. Когда выбран контроль целостности и ICV опускается, ответственность за кодирование эквивалента ICV в поле Payload Data и проверку целостности пакета ложится на комбинированный алгоритм.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Parameters Index (SPI) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- | IV (optional) | ^ p +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | a | Rest of Payload Data (variable) | | y ~ ~ | l | | | o + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | a | | TFC Padding * (optional, variable) | v d +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- | | Padding (0-255 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Pad Length | Next Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Integrity Check Value-ICV (variable) | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * При использовании туннельного режима реализация IPsec может добавлять заполнение TFC (см. параграф 2.4) после поля Payload Data и перед полем Padding.
Если комбинированный алгоритм обеспечивает только целостность данных, которые уже зашифрованы, необходимо реплицировать значения полей SPI и Sequence Number, как часть Payload Data.
В заключение добавляются байты заполнения для сохранения конфиденциаль-ности потоков трафика после поля Payload Data и перед трейлером ESP. Рисунок 2 показывает структуру поля Payload Data для таких случаев.
При использовании комбини-рованного алгоритма явное поле ICV, показанное на рисунках 1 и 2, может отсутствовать (см. параграф 3.3.2.2). Поскольку алгоритмы и режимы задаются при организации SA, формат пакетов ESP для данной SA (включая структуру Payload Data) фиксирован для всего трафика данной SA.
Приведенные ниже таблицы описывают поля предшест-вующих рисунков и иллюстрируют, как несколько категорий опций алгоритмов с различными моделями обработки воздействуют на упомянутые выше поля. Детали обработки рассматриваются ниже.