Кратко

  • RFC 5202 требует оставить ESP_INFO доступным для промежуточных систем, отслеживающих SPI при rekey; RFC 7402 сохраняет это решение. HMAC и подпись защищают целостность, а не секретность.
  • Эксплуатация должна раздельно доказывать шифрование payload, подлинность control message, наблюдаемость координат, активацию новой SA и удаление всех сохранённых связей.

Поле, необходимое до расшифровки

ESP не может сначала расшифровать пакет, а потом решить, каким состоянием его обрабатывать. Поэтому RFC 4303 помещает 32-битный Security Parameters Index и Sequence Number перед зашифрованной частью. Их целостность защищена, но в передаваемом заголовке они не шифруются.

В HIP значение приобретает дополнительную роль: это сжатое представление пары HIT, полезное посреднику для адресного отображения. Значение не глобально. Только сочетание destination и SPI указывает контекст получателя в конкретный момент. Другой хост может применять ту же цифру, а позднее тот же кортеж может означать иной контекст.

Следовательно, SPI — не ключ и не долговечная личность. Но для работающей системы это осмысленная координата, которую нельзя исключить из модели данных.

Почему подпись адресована middlebox

При ротации ESP_INFO передаёт старый SPI, новый SPI и KEYMAT Index. Инициирующий UPDATE включает SEQ, необязательный Diffie–Hellman, HMAC и HIP_SIGNATURE. Ответ добавляет свои параметры и ACK.

RFC 5202 говорит, что промежуточные системы, использующие SPI, должны проверять HIP-пакеты с rekey information. Пакет подписан в их интересах. Поскольку им могут понадобиться новые значения, содержимое нельзя зашифровать. RFC 7402 повторяет это в актуальной Standards Track спецификации.

Подпись здесь повышает качество видимой информации: устройство может проверить, что переход относится к ожидаемому криптографическому контексту. Она не создаёт непрозрачность. Это разные свойства одного сообщения.

Операционный интерфейс обязан одновременно показывать signature verified и ESP_INFO observable. Из первого нельзя выводить metadata privacy, установку SA или успешный трафик.

Возможная корреляция без преувеличения

HIP header содержит HIT отправителя и получателя, ESP_INFO связывает прежний и следующий селекторы, IP header сообщает locators, а сенсор — время. HIP-aware firewall или NAT с контекстом ассоциации способен обновить soft state по назначению. RFC 9063 прямо допускает пассивное наблюдение on-path traffic такими устройствами.

RFC 6973 определяет traffic analysis как вывод из наличия, направления, времени, размера, состава либо частоты, даже для шифрованных потоков. Видимый rekey становится структурированной временной отметкой.

Граница доказательства строга. Один SPI не раскрывает человека, организацию или payload. Долгая linkability зависит от истории HIT, адресов, дополнительных датчиков и retention. Здесь доказана наблюдаемая смена координат, а не универсальная деанонимизация.

Ротация не отзывается назад

Спецификации рекомендуют случайный SPI, новый вариант для каждого следующего exchange с тем же peer и обязательную смену при rekey. Это ограничивает повторное использование и replay.

Однако сохранённое отношение old → new не исчезает при следующем случайном выборе. Live-таблица может протухнуть быстро, а pcap, SIEM, flow storage, incident ticket и backup продолжают существовать.

RFC 9063 отдельно рекомендует часто менять непубличные Host Identities, чтобы мешать linkability и trackability. Такая endpoint policy не удаляет старые записи у посредников. Нужны независимые сроки для SPI, HIT и журнала.

Инвентаризация читателей ESP_INFO

Для каждого компонента фиксируются цель, читаемые поля, правило установки, роли доступа, адреса экспорта, expiry и способ доказать deletion. Требование краткой маршрутизации нельзя превращать в вечное разрешение на аналитику.

Минимальный receipt события включает observation point, направление, locators, защищённую ссылку на HIT, оба SPI, SEQ/ACK, алгоритмы и итоги HMAC/подписи, policy version и timeout. Отдельные receipts показывают создание SA на endpoint, первый аутентифицированный пакет на новом SPI, последний на старом и удаление состояния.

Очистка live-таблицы недостаточна, если копия осталась в packet capture, производном flow record, приложении к тикету или у внешнего processor. Конец должен быть проверен в каждом заявленном хранилище.

Исторический статус без подмены

RFC 5202 опубликована в 2008 году как Experimental и теперь obsolete. Единственная held errata исправляет слово о transform parameters и не влияет на тему. В 2015 году RFC 7402 заменила документ для HIPv2 и получила статус Standards Track.

Сохранение правила видимости в преемнике показывает, что это не случайность старого набора алгоритмов. RFC 6538 и RFC 9063 описывают более широкий компромисс: HIP способен улучшать аутентификацию и практики приватности, а middlebox всё же участвует в control plane. Управление обязано назвать обе стороны.

Решение для руководства

Разделить в договорах и dashboards пять утверждений: payload confidential, control authentic, metadata visible, new SA effective, retention ended. У каждого должна быть собственная проверка.

Минимальная общая спецификация вправе открыть лишь то, что нужно совместимости. Вторичная аналитика, объединение датчиков и долгий срок — локальные решения с владельцем и целью. Приоритет running code означает смотреть на фактический пакет и таблицу, а затем доказывать исчезновение их производных.

Источники

  1. RFC 5202 HTML
  2. Текст RFC 5202
  3. Информация RFC 5202
  4. IETF Datatracker: RFC 5202
  5. История RFC 5202
  6. Ссылки RFC 5202
  7. Errata RFC 5202
  8. RFC 7402 HTML
  9. Текст RFC 7402
  10. Информация RFC 7402
  11. IETF Datatracker: RFC 7402
  12. История RFC 7402
  13. Ссылки RFC 7402
  14. Errata RFC 7402
  15. RFC 4303 — ESP
  16. RFC 4301 — архитектура IPsec
  17. RFC 9063 — архитектура HIP
  18. RFC 6538 — отчёт эксперимента HIP
  19. RFC 6973 — соображения приватности
  20. Heng Lu — слои реальности и символическая власть
  21. Heng Lu — минимальная начальная спецификация
  22. Heng Lu — приоритет работающего кода