Таблица 1: Раздельные алгоритмы шифрования и контроля целостности
| Число байтов | Требуется [1] | Шифруется | Учитывается в ICV | Передается | ||
| SPI | 4 | M | + | Без шифрования | ||
| Seq# (младшие биты) | 4 | M | + | Без шифрования | ||
| IV | переменное | O | + | cipher [3] | Payload | |
| IP datagram [2] | переменное | M или D | + | + | cipher [3] | |
| TFC padding [4] | переменное | O | + | + | cipher [3] | |
| Padding | 0-255 | M | + | + | cipher [3] | |
| Pad Length | 1 | M | + | + | cipher [3] | |
| Next Header | 1 | M | + | + | 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 | Передается | ||
| SPI | 4 | M | + | Без шифрования | ||
| Seq# (младшие биты) | 4 | M | + | Без шифрования | ||
| IV | переменное | O | + | cipher | Payload | |
| IP datagram [2] | переменное | M или D | + | + | cipher | |
| TFC padding [3] | переменное | O | + | + | cipher | |
| Padding | 0-255 | M | + | + | cipher | |
| Pad Length | 1 | M | + | + | cipher | |
| Next Header | 1 | M | + | + | 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 еще не организована.