Кратко

  • draft-smyslov-ipsecme-ikev2-psp-02 предлагает сначала аутентифицировать стороны в IKEv2 SA без Child SA, а затем обменяться в модифицированном CREATE_CHILD_SA ключами PSP, которые каждый получатель выбрал для входящего к нему трафика.
  • Ответ связывает аутентифицированную сторону, Traffic Selectors, SPI, параметры PSP и обёрнутый ключ. Он не наблюдает установку ключа в передающую NIC, вывод ключа на приёмнике, успешный ICV или доставку пакета.
  • PSP не умеет отдельно отзывать производный ключ и передаёт replay-защиту другому уровню. Переключение SA, двойная ротация мастер-ключа, отказ повтору и результат приложения требуют отдельных квитанций.

SPI несёт выбор, но не историю исполнения

Получатель PSP хранит два 256-битных мастер-ключа. При входе пакета старший бит SPI указывает, какой из них использовать, а оставшаяся часть участвует в выводе ключа SA. Эта схема позволяет не хранить отдельный приёмный ключ для каждой ассоциации.

PSP Architecture Specification делает из SPI важный элемент custody. Получатель знает активный мастер-ключ и должен выбрать SPI; повторное использование SPI под тем же мастер-ключом недопустимо. Затем он передаёт соответствующий производный ключ удалённому отправителю.

Из этого не следует, что появление SPI в контрольном сообщении или пакете подтверждает всю цепочку. SPI может быть правильно выбран, а команда установки на отправителе — задержаться. Пакет может выйти через другой egress object. Получатель может находиться в иной эпохе. ICV может не пройти. Верхний уровень может отклонить SPI.

Новый draft-smyslov-ipsecme-ikev2-psp-02 описывает доставку ключа через IKEv2. Версии HTML и XML не добавляют телеметрию данных. Раздел Security Considerations остаётся «To be added». Поэтому границы доказательства особенно важны.

Ключ отправляет тот, кто будет принимать

PSP SA однонаправленна. Сторона A выбирает SPI и ключ для трафика, который она будет принимать от B, и отправляет материал B. B устанавливает его в свой transmit path. Для обратного направления B делает симметричный выбор и отправляет его A.

Фраза «A отправила ключ B» может вводить в заблуждение: ключ не предназначен для исходящего трафика A. Он нужен B, чтобы шифровать пакеты к A. Журнал должен хранить направление «key originator/receiver → remote sender → traffic destination», иначе одна рабочая половина будет маскировать вторую.

RFC 7296 обычно выводит Child-SA keying material из IKE-секретов и nonce. PSP требует материал под контролем получателя. Проект повторно использует Key Download из RFC 9838, переводя возможность передачи произвольного ключа в unicast-контекст.

Так решается безопасная доставка. Удалённая установка остаётся локальным действием, которого отправитель Key Download не видит.

Сначала идентичность, затем чувствительный материал

В IKE_SA_INIT согласуется Key Wrap Algorithm. Поддерживающий responder возвращает CHILDLESS_IKEV2_SUPPORTED. RFC 6023 позволяет завершить IKE SA без немедленного создания Child SA.

PSP Child SA нельзя создавать в IKE_AUTH: инициатору пришлось бы выдать свой приёмный ключ до завершения аутентификации responder. Проект требует закончить аутентификацию, а затем выполнить модифицированный CREATE_CHILD_SA.

Это сильная последовательность, но не аттестация устройства. IKE identity может принадлежать контроллеру, за которым находятся несколько NIC, VF, VM или accelerator. Она подтверждает сторону управления, не конкретный egress object.

Согласованный KWA тоже не означает, что IKE SA посвящена PSP. Она может создавать и ESP, и PSP SA. Capability, authenticated peer, requested association, key delivery и local install должны иметь разные состояния.

Связанный Key Bag не является записью в таблице NIC

В модифицированном CREATE_CHILD_SA используются PSP Protocol ID и PSP Parameters transform, пока обозначенные <TBA>, Traffic Selectors, SPI и ровно один KD payload с каждой стороны. SPI в Key Bag соответствует proposal; SA_KEY защищён SK_w = prf+(SK_d, "Key Wrap for PSP").

Это даёт хороший контрольный след: кто, для какого трафика, с каким SPI и параметром передал материал. Но проект не определяет API от IKE daemon к host/NIC.

Архивный репозиторий Google PSP содержит reference implementation и тесты. Архитектура допускает on-chip flow table, SA database в RAM либо ключ/указатель в transmit descriptor. У каждого варианта свой предел, задержка и ack. Наличие кода не является доказательством продукта, deployment или атомарности программирования.

Локальная квитанция должна связать SPI, направление, алгоритм и epoch с NIC/VF, queue или SA object и результатом driver. Сам ключ в журнале не нужен; нужна проверяемая ссылка на правильный объект исполнения.

Stateless меняет размещение состояния, а не отменяет его

Приёмник сохраняет мастер-ключи, active state, SPI allocation, lifetime и rotation. Отправитель сохраняет или передаёт per-SA transmit key. Верхний уровень может поддерживать approved SPI list.

RFC 4301 разделяет SA management, policy и packet processing. RFC 4303 не превращает наличие ESP SA в доказательство каждого пакета. PSP экономит память приёма, но не сливает control plane с data plane.

И заявленный масштаб остаётся design consideration. Миллионы SA и высокие key-update rates в документе не являются benchmark конкретной NIC. IKE может быть здоров, пока transmit table заполнена или programming queue растёт.

Первый защищённый пакет должен оставить собственный след

PSP требует counters для успешных TX/RX packet и bytes, authentication/encryption failures, framing errors и неверного master-key selection. Также предусматриваются флаг успешной аутентификации/дешифрования и SPI metadata для upper layer.

После Key Download можно отправить ограниченный canary. Сохранить IKE transaction и device ack; на sender — SPI, IV и TX increment; на receiver — master-key epoch, derivation, ICV verdict и RX increment; выше — receipt ожидаемого содержимого.

Такой тест доказывает один путь в один момент, а не вечную защиту. Но он разделяет причины. TX без authenticated RX указывает на route, encapsulation, version, epoch или ICV. RX без application receipt переносит расследование к SPI policy, transport или application.

Оба направления проверяются независимо. Два Key Download не гарантируют два установленного пути.

Rekey оставляет период, когда старое и новое истинны одновременно

REKEY_SA указывает заменяемую PSP SA. В общей модели IKEv2 новая SA создаётся, traffic переключается, старая удаляется. Положительный response подтверждает создание, не cutover и не delete.

Rekey ledger должен хранить установку нового SPI, первый принятый пакет, последний пакет на старом SPI, смену classifier, delete acknowledgements и loss/reordering. Если новый object существует, но egress продолжает выбирать старый, migration не завершена.

Master-key rotation добавляет ещё одно перекрытие. После переключения active key старый нужен существующим SA. PSP говорит, что только «double rotation» окончательно вытесняет его. До следующего шага все старые соединения должны пройти rekey.

Индивидуального отзыва производного ключа PSP не даёт. Статус «revoked» в control database — административное решение. Криптографический эффект требует migration, прекращения старого traffic и eviction соответствующего master key.

Replay нельзя вывести из SPI или ICV

PSP не предоставляет replay protection и ожидает её от layer 4, например TCP. Новый IKE key delivery этого не меняет. Валидный ICV говорит об аутентичности пакета в SA, но не о том, видели ли его раньше.

Это не утверждение, что конкретный deployment беззащитен. Это требование назвать owner: какая layer, какой state, какое observation и какой verdict обеспечили отказ повтору. SPI и IV не могут подменить этот документ.

Application duplicate — ещё одна граница. Transport может принять packet один раз, но повторённая операция всё равно дать второй бизнес-эффект. Cryptographic authenticity, replay rejection и idempotency остаются разными.

Revision 02 обновляет срок, не протокол

Datatracker API датирует revision 02 30 сентября 2026 года и expiry 3 апреля 2027 года. Страница документа называет его active individual Internet-Draft; history показывает три версии.

Diff с 01 меняет дату, revision, expiry и headers, не технический текст. В заголовке указан intended status Experimental, но Datatracker не показывает RFC, stream, responsible AD или standards level. Новая дата не означает adoption, security review, implementation или deployment.

Запрашиваемые PSP values остаются <TBA>. IANA IKEv2 Parameters registry является источником назначений. Request в draft ещё не allocation.

Источники и пределы

Материал основан на revision 02 text/HTML/XML, Datatracker, RFC 7296, RFC 6023, RFC 9838, RFC 4301, RFC 4303, IANA и PSP repository/specification. Источники не доказывают production adoption, performance, conformance, vulnerability, incident или service outcome.