Кратко

  • В базовой последовательности forward access control из RFC 9838 изменение состава сначала создаёт новую KEK; последующий rekey доставляет политику и ключи TEK уже под её защитой.
  • Multicast-GSA_REKEY не подтверждается и может потеряться. Идентичные зашифрованные повторы и GSA_NEXT_SPI помогают восстановлению, но не доказывают установку у каждого участника.
  • ATD откладывает использование новых SA, DTD — удаление старых. Реальный срок исключения проходит через это перекрытие, а не заканчивается временем закрытия заявки.

В журнале доступа участника уже нет. В памяти устройства старый групповой ключ ещё может быть. Между этими фактами находится вся задача исключения.

RFC 9838 описывает Group Key Management Using IKEv2 — G-IKEv2. Карточка RFC Editor указывает ноябрь 2025 года, Standards Track и замену RFC 6407. Она удостоверяет спецификацию, но не внедрение или успешный отзыв.

Протокол продолжает архитектуру MSEC из RFC 3740, RFC 4046 и RFC 5374. GCKS аутентифицирует и авторизует Group Members, после чего раздаёт Group Security Association с политиками и ключами Data-Security SA и, при необходимости, multicast Rekey SA.

Регистрация создаёт начальное состояние, rekey изменяет его. IKEv2 даёт двусторонний защищённый канал; IPsec, AH и ESP определяют SA и защиту пакетов. В группе один отправитель не получает совокупного ответа от всех адресатов.

Первая команда исключения всё ещё опирается на старую KEK

Forward access control лишает удалённого участника нового группового ключа. Backward access control не даёт новому участнику старый ключ. RFC 9838 отдельно подчёркивает, что это не Perfect Forward Secrecy из IKEv2.

Сообщение, меняющее членство, защищено текущей KEK. Если поместить в него новую политику TEK и ключи, уходящий участник сможет их прочитать. Поэтому при требовании forward access control первое сообщение не должно нести новый TEK. Второй rekey доставляет его под новой KEK.

Если от исключённого нужно скрыть и изменение политики, GCKS отправляет два последовательных rekey, каждый со сменой KEK. Первый создаёт KEK, которую исключённый не получает; второй вновь меняет KEK и несёт новую политику. Менять политику без новой KEK запрещено.

Будущие методы могут снять требование нескольких сообщений, если опишут сохранение свойства в одном rekey. Истоки Logical Key Hierarchy показаны в RFC 2627. Значит, две смены — проверяемая базовая процедура, а не утверждение обо всех возможных алгоритмах.

Повтор передачи не превращается в квитанцию

GCKS может выполнить unicast in-band rekey или односторонний multicast-GSA_REKEY. Multicast не подтверждается. Потеря оставляет законного участника на старой политике.

Сервер может в течение нескольких секунд послать несколько зашифрованных, побитно одинаковых копий. GSA_NEXT_SPI позволяет объявить будущий SPI, чтобы слушатель заметил пропуск и восстановился. Это повышает вероятность доставки, но не сообщает состояние молчащего endpoint.

Ограничение проявляется и при фрагментации. RFC 7383 позволяет дробить большие IKE-сообщения, однако multicast не может сначала попробовать целое сообщение или узнать PMTU по ответу. Нужен заранее заданный порог. Размер группы и дерева ключей становится частью риска доставки.

Два таймера создают честную, но рискованную зону

ATD определяет ожидание перед использованием новых SA отправителями. DTD определяет ожидание перед удалением старых Data-Security SA участниками. Перекрытие сохраняет доступность, но не даёт считать административное удаление моментальным криптографическим фактом.

Надёжная запись различает отзыв авторизации, создание новой KEK, установку новой TEK, активацию новой SA и удаление старой. Проверка трафика со старым удостоверением добавляет момент последнего фактического доступа.

Режимы со счётчиком требуют Sender-ID и учёта nonce. Следуя RFC 6054, RFC 9838 выдаёт уникальный ID каждому отправителю и новый ID при каждой регистрации, поскольку GCKS не знает достоверно, какие nonce уже использованы. При исчерпании пространства сервер обязан исключить всех и провести регистрацию с новыми Data-Security SA. RFC 8221 и RFC 8750 не отменяют этот журнал состояния.

Replay protection тоже не является общей галочкой. Несколько отправителей в одной SA независимо увеличивают sequence number, и единое окно может стать невозможным. Получатель решает локально, проверять ли повторы. GCKS может разнести отправителей по отдельным SA, заплатив дополнительным масштабом.

Реестр IANA для IKEv2 фиксирует значения, RFC 8174 — силу MUST, RFC 6407 — прежний протокол. Ни один источник не наблюдает установленное состояние организации.

Принцип Heng Lu о минимальной начальной спецификации и локальных будущих решениях оставляет стандарту семантику, а оператору — допустимый срок и доказательства. Приоритет работающего кода ставит установленный ключ и трафик выше статуса заявки. Реальность вместо пропаганды не превращает Standards Track в гарантию эксплуатации.

Источники