2.4. Security Parameters Index (SPI) — список параметров защиты
SPI представляет собой произвольное 32-битовое значение, используемое получателем для идентификации SA, с которой связан входящий пакет. Для индивидуальных SA, значение SPI может само по себе идентифицировать SA или использоваться в комбинации с типом протокола IPsec (в данном случае AH). Поскольку для индивидуальных SA значение SPI генерируется получателем, решение вопроса о достаточности этого значения для идентификации SA или необходимости использования в комбинации с типом протокола IPsec определяется локальными условиями. Поле SPI является обязательным и упомянутый выше механизм отображения входящего трафика на индивидуальные SA должен поддерживаться всеми реализациями AH.
В реализациях IPsec, поддерживающих групповую адресацию, должны поддерживаться групповые SA с использованием описанного ниже алгоритма отображения входящих дейтаграмм IPsec на SA. Разработчикам, поддерживающим только индивидуальный трафик, не обязательно реализовать механизм демультиплексирования.
Во многих защищенных multicast-архитектурах (например, [RFC3740]) центральный контроллер группы/сервер ключей сам выделяет для группы значение SPI. Выделение SPI не согласуется и не координируется с подсистемами управления ключами (например, IKE) на конечных узлах группы. Следовательно, возникает возможность совпадения значений SPI для групповой и индивидуальной SASA. Поддерживающие групповую адресацию реализации IPsec должны корректно демультиплексировать входящий трафик даже в случаях совпадения значений SPI.
Каждая запись в базе данных защищенных связей (SAD — Security Association Database) [Ken-Arch] должна указывать, по каким критериям в дополнение к SPI SPI SPI SPI отыскивается SA — получатель, получатель и отправитель. Для групповых SA поле протокола не используется при поиске SA. Для каждого входящего пакета с защитой IPsec реализация должна произвести поиск в SAD и найти запись, наиболее точно соответствующую идентификатору SA. Если обнаруживается более одной записи SAD, соответствующей значению SPI, выбирается запись по наиболее точному соответствию получателя или получателя и отправителя (как указано в записи SAD). Таким образом, логический порядок поиска в SAD имеет вид:
Поиск в базе SAD соответствия {SPI, адрес получателя, адрес отправителя}. Если запись SAD найдена, входящий пакет AH обрабатывается с найденной записью SAD. В противном случае выполняется п. 2.
Поиск в базе SAD соответствия {SPI, адрес получателя}. Если запись SAD найдена, входящий пакет AH обрабатывается с найденной записью SAD. В противном случае выполняется п. 3.
Поиск в базе SAD соответствия {SPI}, если получатель выбрал поддержку одного пространства SPI для AH и ESP, или {SPI, протокол} в противном случае. Если запись SAD найдена, входящий пакет AH обрабатывается с найденной записью SAD. В противном случае пакет отбрасывается с записью в журнал аудита.
На практике реализация может выбрать любой метод ускорения поиска, но наблюдаемое извне поведение должно соответствовать описанному выше поиску в SAD. Например, программные реализации могут индексировать хэш-таблицу SPI. Записи SAD в хэш-таблице сортируются в связный список, в котором записи для SA с большим соответствием располагаются ближе к началу, а с меньшим соответствием — ближе к концу списка. В аппаратных реализациях поиск максимального соответствия может ускоряться встроенными средствами с использованием общедоступной технологии TCAM (Ternary Content-Addressable Memory — ассоциативная память).
Индикация использования адресов отправителя и получателя при поиске соответствия для отображения входящего трафика IPsec на SA должна выполняться при настройке конфигурации SA вручную или путем согласования параметров с использованием протокола управления SA (например, IKE или GDOI [RFC3547]). Обычно группы SSM (Source-Specific Multicast) [HC03] используют трехкомпонентный идентификатор SA, включающий SPI, групповой адрес получателей и адрес отправителя. SA группы Any-Source Multicast требует в качестве идентификатора только SPI и групповой адрес получателей.
Значения SPI в диапазоне от 1 до 255 зерезервированы IANA для использования в будущем. Эти значения не будут распределяться агентством IANA, пока их использование не будет оговорено в специальном RFC. Значение SPI = 0 зарезервировано для локального, связанного с реализацией, применения и его недопустимо передавать в сеть. Например, реализация управления ключами может использовать SPI=0 для идентификации отсутствия защищенных связей в период, когда реализация IPsec запрашивает новую SA для объекта управления ключами, но данная SA еще не организована.