Кратко

  • RFC 2407 назначил общие значения DOI 1, Situation, типов идентичности, протоколов, transforms, атрибутов SA и уведомлений. Эти значения объясняли байты, но не доказывали полномочие или выполненный результат.
  • Документ явно вынес конкретную security policy за свой предел. Полная квитанция должна была соединить аутентифицированную идентичность, локальное правило, выбор, установку SA, решение получателя и фактический трафик.

В 1998 году число решало больше проблем, чем кажется. Если два производителя одинаково понимали значение DOI 1 и код ESP, они могли продолжить переговоры без частного словаря. Но число не отвечало, кто имел право предложить соединение и что система сделала после выбора.

RFC 2407 опубликовал Internet IP Security Domain of Interpretation для общего каркаса ISAKMP. ISAKMP определял обмены и формы payload, DOI — пространство имён и правила чтения IPsec-специфичных данных. Вместе они делали сообщения совместимыми.

В общий реестр вошли Situation, protocol IDs, transforms AH/ESP/IPComp, атрибуты SA, label domains, Identity Types и Notify Types. Для сотрудничающих частных систем оставлялись отдельные диапазоны. Уникальность была централизована, эксплуатационная политика — нет.

Situation содержал SIT_IDENTITY_ONLY, SIT_SECRECY и SIT_INTEGRITY. Идентичность была обязательной: полное отсутствие Identification Payload требовало прекратить установление ассоциации. Маркированная секретность и целостность добавляли domain, level и category bitmap.

Labeled Domain Identifier указывал namespace, в котором существовали уровни и категории. Он не перевозил весь свод правил. RFC позволял выдавать такие номера по запросу без обязательной документации. Реестр гарантировал различимость доменов, но не одинаковое толкование или исполнение.

Следующий раздел устанавливал принцип: IPsec DOI не навязывал конкретных требований security policy, политика хоста была вне области документа. Варианты могли начинаться со списка адресов и масок и доходить до wildcard-имён, направления и адреса proxy firewall.

Identification Payload поддерживал адреса, подсети, диапазоны, FQDN, user FQDN, ASN.1 names и opaque Key ID. Получатель мог использовать заявленную идентичность для выбора правила. Однако тип не являлся аутентификацией.

При сертификатной аутентификации ID, участвующие в policy decision, должны были присутствовать в сертификате. Это соединяло сообщение и credential. ID_KEY_ID, напротив, мог быть непрозрачным vendor-specific селектором заранее разделённого ключа. Его общий код не раскрывал локальную семантику.

Proposal Payload переносил несколько возможных Phase II suites. RFC называл ISAKMP, AH, ESP и IPComp, но их совместимость в одной сделке оставлял политике хоста. Transform ID тоже зависел от атрибутов: authentication algorithm, key length, rounds, group, mode, lifetime и параметры compression.

Некоторые сочетания были определены, другие — нет. Поэтому запись «выбран ESP» не содержала достаточной точности. Нужны были весь набор атрибутов, ответ получателя и результат установки.

После переговоров существовали ещё key manager, интерфейс к kernel, база SA, selectors и packet processing. Успешный обмен мог закончиться ошибкой установки. Установленная SA могла не захватить ожидаемый поток. Защищённый пакет мог не быть принят приложением. Каждый переход создавал отдельную реальность.

Уведомления фиксировали часть расхождений. RESPONDER-LIFETIME сообщал фактическую продолжительность, выбранную получателем. REPLAY-STATUS сообщал его решение включить или выключить anti-replay. Счётчик отправителя не был доказательством окна получателя.

INITIAL-CONTACT передавал утверждение, что это первая SA с удалённой системой. Получатель мог предположить reboot и удалить старые ассоциации. Аутентификация сообщения доказывала говорящего внутри обмена, не внешний факт перезапуска. Решение удалить состояние нуждалось в собственной политике и rollback.

Место уведомления меняло его защиту. Aggressive Mode был запрещён из-за недостаточной привязки. Main Mode мог защищать лишь часть, Quick Mode включал payload целиком в hash. Смысл кода и сила доказательства были разными измерениями.

Так проявляются слои реальности Lu Heng. Регистрационная запись говорит о символе. Payload — о заявлении. Аутентификация — о связи. Policy — о разрешении. SA — об исполнимом состоянии. Packet и application — о результате. Нельзя использовать квитанцию верхнего слоя вместо нижнего.

Running-code primacy превращает эту схему в аудит: какая версия правила совпала, какая SA была установлена, какие selectors сработали, что решил replay engine, какой пакет прошёл и что сделало приложение. DOI 1 остаётся важным, но только как начало трассы.

RFC 4306 объединил и заменил RFC 2407, 2408 и 2409 в 2005 году. В 2023 году IESG перевёл старый комплект IKEv1 в Historic, указав на широкое внедрение IKEv2, многолетнее отсутствие развития и проблемы вроде amplification attacks. RFC 7296 стал последующим Internet Standard.

История RFC 2407 полезна не как каталог старых алгоритмов. Она показывает дисциплину границ. Словарь был общим. Истина оставалась распределённой между связыванием идентичности, локальной политикой, выбором, установкой и наблюдаемым эффектом.

Источники