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

Таблица 1: Раздельные алгоритмы шифрования и контроля целостности

Число байтовТребуется [1]ШифруетсяУчитывается в ICVПередается
SPI4M+Без шифрования
Seq# (младшие биты)4M+Без шифрования
IVпеременноеO+cipher [3]Payload
IP datagram [2]переменноеM или D++cipher [3]
TFC padding [4]переменноеO++cipher [3]
Padding0-255M++cipher [3]
Pad Length1M++cipher [3]
Next Header1M++cipher [3]
Seq# (старшие биты)4При ESN [5]+Не передается
ICV PaddingпеременноеЕсли используется+Не передается
ICVпеременноеM [6]Без шифрования
  • [1] M = обязательно; O = опция; D = фикция
  • [2] В туннельном режиме дейтаграмма IP, в транспортном — следующий заголовок и данные.
  • [3] Ciphertext, если выбрано шифрование.
  • [4] Может использоваться только при указании реального размера данных (payload).
  • [5] См. параграф 2.1.1
  • [6] Обязательно при использовании отдельного механизма контроля целостности.

Таблица 2: Комбинированные алгоритмы шифрования и контроля целостности

Число байтовТребуется [1]ШифруетсяУчитывается в ICVПередается
SPI4M+Без шифрования
Seq# (младшие биты)4M+Без шифрования
IVпеременноеO+cipherPayload
IP datagram [2]переменноеM или D++cipher
TFC padding [3]переменноеO++cipher
Padding0-255M++cipher
Pad Length1M++cipher
Next Header1M++cipher
Seq# (старшие биты)4При ESN [4]+[5]
ICV PaddingпеременноеЕсли используется+[5]
ICVпеременноеO [6]Без шифрования
  • [1] M = обязательно; O = опция; D = фикция
  • [2] В туннельном режиме дейтаграмма IP, в транспортном — следующий заголовок и данные.
  • [3] Может использоваться только при указании реального размера данных (payload).
  • [4] См. параграф 2.1.1
  • [5] Передача этого поля определяется алгоритмом, но в любом случае поле является «невидимым» для ESP.
  • [6] Присутствие этого поля определяется спецификацией алгоритма.

На практике реализация может выбрать любой метод ускорения поиска, но наблюдаемое извне поведение должно соответствовать описанному выше поиску в SAD. Например, программные реализации могут индексировать хэш-таблицу SPI. Записи SAD в хэш-таблице сортируются в связный список, в котором записи для SA с большим соответствием располагаются ближе к началу, а с меньшим соответствием — ближе к концу списка. В аппаратных реализациях поиск максимального соответствия может ускоряться встроенными средствами с использованием общедоступной технологии TCAM.

Индикация использования адресов отправителя и получателя при поиске соответствия для отображения входящего трафика IPsec на SA должна выполняться при настройке конфигурации SA вручную или путем согласования параметров с использованием протокола управления SA (например, IKE или GDOI [RFC3547]). Обычно группы SSM [HC03] используют трехкомпонентный идентификатор SA, включающий SPI, групповой адрес получателей и адрес отправителя. SA группы Any-Source Multicast требует в качестве идентификатора только SPI и групповой адрес получателей.

Значения SPI в диапазоне от 1 до 255 зерезервированы IANA для использования в будущем. Эти значения не будут распределяться агентством IANA, пока их использование не будет оговорено в специальном RFC. Значение SPI = 0 зарезервировано для локального, связанного с реализацией, применения и его недопустимо передавать в сеть. Например, реализация управления ключами может использовать SPI=0 для идентификации отсутствия защищенных связей в период, когда реализация IPsec запрашивает новую SA для объекта управления ключами, но данная SA еще не организована.

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