Кратко

  • Cookie-пара выбирала ISAKMP SA, Message ID — незавершённые переговоры фазы 2, а SPI — предлагаемый или работающий контекст протокола. Эти значения коррелировали состояние, но не заменяли credential.
  • Сильная аутентификация, локальная policy, выбор предложения, установка, обработка пакетов и результат приложения оставались отдельными слоями. Даже защищённые CONNECTED и Delete имели ограниченную семантику.

Число может привести программу к правильной записи и всё же привести организацию к неправильному выводу.

В RFC 2408 два cookie находили ISAKMP Security Association. Message ID находил переговоры фазы 2 внутри неё. SPI из Proposal относился к создаваемой протокольной SA. Позже SPI в заголовке ESP или AH выбирал состояние для конкретного пакета.

Каждый ключ отвечал своему хранилищу. Пара cookie — какой родительский защищённый контекст. Message ID — какая дочерняя работа. Proposal SPI — какой результат предлагается создать. Runtime SPI — какое установленное состояние применить.

Такая иерархия нужна была для конкуренции. После фазы 1 обе стороны могли инициировать фазу 2. Почти одновременные переговоры получали независимо созданные Message ID и не смешивали ответы. В фазе 1 поле должно было оставаться нулём, поскольку контекст задавали cookie.

Но правильный поиск записи ничего не говорил о том, кто имел право её создать. RFC 2408 отдельно требовал сильную аутентификацию и предупреждал: без неё идентификации сущности доверять нельзя. Message ID был индексом протокола, не удостоверением субъекта.

Cookie тоже начинался не как имя. Документ называл его anti-clogging token. До дорогой операции с открытым ключом серверу требовалась дешёвая проверка запроса. Функция должна зависеть от конкретных сторон, использовать локальный секрет, недоступный другим, и быстро вычисляться.

Предлагалось хешировать адреса, UDP-порты, случайный локальный секрет и время. Для каждого установления SA требовалось уникальное восьмиоктетное значение, чтобы также мешать повторному воспроизведению старых сообщений.

Это доказывало ограниченный факт: эмитент узнаёт токен своей эпохи. Адрес в функции не становился личностью. Возвращённый cookie не доказывал владение закрытым ключом. Уникальность не доказывала устойчивость пути.

RFC не обещал абсолютной защиты от отказа в обслуживании. Поддельные адреса всё ещё могли создавать состояние, поэтому требовались garbage collection и строгая память. Корректный cookie мог сосуществовать с переполненной таблицей и недоступной службой.

В первом сообщении фазы 1 инициатор ставил свой cookie; Responder Cookie и Message ID были нулевыми. Ответ добавлял второй cookie. После фазы 1 пара присутствовала в последующих обменах и определяла ISAKMP SA.

В этот момент состояние было найдено, но доказательство личности могло ещё зависеть от hash, signature, certificate или другой согласованной схемы. Журнал, сохраняющий только cookie, не позволял восстановить credential binding.

Фиксированный заголовок задавал ещё один слой: грамматику. Exchange Type определял порядок сообщений и payload. Next Payload называл первый тип, а каждый общий заголовок — следующий. Version, Flags и Length имели отдельные ограничения.

Получатель проверял cookie, Next Payload, версию, Exchange Type, Flags и Message ID, затем разбирал цепочку. Успех cookie не гарантировал версию; правильная версия не гарантировала signature; правильная signature не гарантировала authorization; разрешение не гарантировало установку.

При ошибке сообщение отбрасывалось. Запись в audit и Informational notification часто оставались необязательными и определялись локальной policy. Общие коды INVALID-COOKIE и INVALID-MESSAGE-ID унифицировали название, но не наличие долговечного доказательства.

ISAKMP был намеренно отделён от конкретного key exchange. Он задавал процедуры и форматы для создания, переговоров, изменения и удаления SA, передавал материал ключей и аутентификации, но не навязывал одну технику. Framework организовывал доказательства, не создавая все их свойства.

Две фазы распределяли работу. Фаза 1 создавала ISAKMP SA, защищавшую последующее управление. Фаза 2 создавала SA других протоколов. Дорогой первый шаг можно было использовать для многих последующих переговоров.

Мог меняться и субъект. В фазе 1 могли аутентифицироваться серверы или хосты, во второй — пользователи или программы. Родительский cookie-контекст не давал дочерним субъектам одинаковые полномочия автоматически.

Поэтому acceptance receipt обязан назвать фазу, subject, credential, policy и Message ID. Иначе экономия от повторного использования канала превращается в скрытую передачу authority.

Предложения сохраняли местное решение. Инициатор мог послать одну альтернативу или несколько по убыванию предпочтения. При нескольких responder выбирал по своей policy. Message ID связывал ответ с работой, но не подтверждал качество или легитимность правила.

После выбора оставалась установка. Ответ с тем же Message ID и SPI показывал результат переговоров. Он не показывал, что интерфейс daemon–kernel сработал, что selectors захватили поток или что приложение получило полезный пакет.

Commit bit признавал этот разрыв. Другая сторона ждала защищённый Informational Exchange с CONNECTED, связанный исходным Message ID. Сигнал помогал синхронизировать готовность.

Последнее сообщение всё равно могло исчезнуть. RFC допускал вывод из проверяемого защищённого трафика или повтор последнего negotiation message, не стандартизируя единственное восстановление. CONNECTED был квитанцией внутри ненадёжной доставки, а не абсолютным состоянием мира.

Delete показал разные реальности ещё нагляднее. Sender сообщал, что удалил SA из собственной базы. Это не было запросом на удаление у responder и не требовало acknowledgment. Получатель должен был очистить локальную базу, но продолжение зависело от policy.

Перехваченный Delete не доказывает удаление на другой стороне. Нужны проверка защиты, локальное решение, мутация базы, SPI и selectors, результат следующих пакетов и восстановление. Один текстовый глагол не объединяет две базы данных.

В терминах слоёв реальности Lu Heng cookie принадлежит корреляции и ресурсам; Message ID — протокольному состоянию; payload chain — синтаксису; credential — связыванию личности; policy — разрешению; установленная SA — исполнимому состоянию; пакет и приложение — результату.

Agency problem проявляется, когда daemon говорит за всю цепочку. Credential authority, policy owner, процесс переговоров, kernel и application принимают разные решения. Единый зелёный статус скрывает границы ответственности.

Running-code primacy требует соединить точные поля с фактом: cookie-пара, Message ID, аутентификация, fingerprint credential, версия policy, выбор, установка, runtime SPI, selectors, counters, packet verdict и service observation. Число становится сильным доказательством, когда его область не расширяют.

RFC 2408 опубликован в ноябре 1998 года. RFC 4306 заменил отдельные 2407/2408/2409 на IKEv2 в 2005 году. В 2023 году IKEv1 стал Historic, а RFC 9395 закрыл связанные registries. RFC 7296 позже стал Internet Standard для IKEv2. Это исторический анализ, не рекомендация старых алгоритмов.

Пара cookie нашла состояние. Личность, полномочие, установка и эффект всё ещё требовали отдельных доказательств.

Источники