Host Identity Protocol RFC 7401: уроки для IPvX-адресов

Host Identity Protocol RFC 7401 полезен для нас как опубликованный IETF-пример протокола, который отделяет роль идентификатора от роли локатора у IP-адресов и устанавливает общее состояние IP-уровня между согласными хостами.² HIP использует публичные ключевые идентификаторы из пространства Host Identity для взаимной аутентификации участников и основан на обмене Diffie-Hellman.² Для проектирования IPvX-адресов это не готовый чертёж, а набор архитектурных вопросов, которые уже были явно сформулированы в IETF-документах о HIP.¹

Почему разделение идентификатора и локатора важно

RFC 7401 описывает HIP как альтернативу двойному использованию IP-адресов: IP-адреса могут выступать и как locators, то есть метки маршрутизации, и как identifiers, то есть идентификаторы хостов или конечных точек.³ В HIP публичные криптографические ключи из пары public/private key используются как идентификаторы хостов, а протоколы более высоких уровней привязываются к этим идентификаторам вместо привязки к IP-адресу.³

RFC 9063 формулирует ту же проблему шире: Интернет имеет два важных глобальных пространства имён — IP-адреса и DNS-имена, и оба пространства стали семантически перегруженными из-за попытки делать с ними слишком многое.¹ В архитектуре HIP пространство Host Identity добавляется между IP- и DNS-пространствами, а соответствующий протокольный слой расположен между internetworking и transport layers.¹

Для IPvX мы извлекаем из этого осторожный урок: адресация по ключам не должна автоматически смешивать криптографическую идентичность, представление этой идентичности в пакетах и текущий путь доставки.³ Это именно наша проектная интерпретация HIP, а не требование RFC 7401 к IPvX.³

Ключ, идентичность и компактный тег — разные сущности

RFC 9063 различает Host Identity и Host Identifier: Identity относится к абстрактной сущности, которая идентифицируется, а Identifier является конкретным битовым шаблоном, используемым в процессе идентификации.¹ В фокусном случае архитектуры HIP Host Identifier является публичным ключом асимметричной пары.¹

HIP также определяет Host Identity Tag, или HIT, как 128-битное значение, полученное криптографическим хешированием Host Identifier с добавлением битов, указывающих использованный хеш.¹ В терминологии RFC 9063 Host Identity Hash — это криптографический хеш, используемый при создании HIT из Host Identifier.¹ Документ также определяет Local Scope Identifier как 32-битное значение, обозначающее Host Identity в локальной области.¹

Эти определения дают нам полезную дисциплину словаря для IPvX: «ключ», «абстрактная идентичность», «компактный тег» и «локальный идентификатор области» не являются одним и тем же понятием в HIP.¹ Мы можем использовать эту дисциплину при описании IPvX-адресов, но не должны выдавать её за прямое предписание RFC 9063 для IPvX.¹

История HIT также показывает, что формат компактного представления может эволюционировать.⁶ В RFC 4423 HIT описывался как 128-битное значение, созданное хешированием Host Identifier.⁶ В RFC 9063 определение HIT уже включает биты, которые указывают использованный хеш.¹ Это не доказывает, каким должен быть формат IPvX-адреса, но показывает, что в HIP алгоритмический контекст компактного тега стал частью архитектурного описания.¹

Base Exchange как модель установления состояния

RFC 7401 определяет base HIP protocol, или base exchange, используемый между хостами для установления IP-layer communications context, называемого HIP association, до коммуникации.³ В содержании RFC 7401 отдельно перечислены создание HIP Association, HIP Puzzle Mechanism, обмен puzzle, аутентифицированный Diffie-Hellman с согласованием DH-группы, защита от повторов, отказ от base exchange, прерывание base exchange, downgrade protection и opportunistic mode.²

Спецификация RFC 7401 также перечисляет управляющие пакеты I1, R1, I2, R2, UPDATE, NOTIFY, CLOSE и CLOSE_ACK.² В том же документе есть разделы об обновлении HIP association, обработке ошибок, HIP state machine, обработке UPDATE с SEQ и ACK, обработке CLOSE и CLOSE_ACK, а также handling state loss.²

Для IPvX этот набор тем полезен как чек-лист проектирования соединения, но не как доказательство, что IPvX обязан повторить state machine HIP.² Мы можем проверять собственный дизайн на те же классы вопросов: как создаётся ассоциация, как согласуются параметры, как обнаруживаются ошибки, как обновляется состояние и как закрывается связь.² При этом утверждение о «дешёвом старте» не следует выводить из одного только RFC 7401; источник прямо подтверждает наличие puzzle mechanism и защитных разделов, но не формулирует универсальное требование к любому протоколу адресации по ключам.²

Безопасность полезной нагрузки и ассоциации — отдельные слои

RFC 7401 говорит, что HIP designed to be resistant to denial-of-service and man-in-the-middle attacks.² Документ также указывает, что при использовании с подходящим протоколом безопасности, например ESP, HIP предоставляет integrity protection и optional encryption для верхнеуровневых протоколов, таких как TCP и UDP.²

RFC 9063 уточняет архитектурную роль: при использовании HIP полезная нагрузка между HIP-хостами обычно, но не обязательно, защищается Encapsulating Security Payload, а Host Identities используются для создания нужных ESP Security Associations и аутентификации хостов.¹ Это важная граница для IPvX: ключевая адресация может быть частью аутентификации, но защита полезной нагрузки, параметры security association и жизненный цикл таких ассоциаций требуют отдельного описания.¹

Документы HIP также показывают, что криптографическая гибкость была предметом явной корректировки.² RFC 7401 сообщает, что документ обрабатывает замечания IESG, в частности по crypto agility, и включает уроки реализаций RFC 5201.² RFC 9063 также говорит, что он учитывает concerns raised by the IESG, particularly crypto agility.¹ Для IPvX это не готовое правило о конкретных хешах или типах ключей, но веская причина явно документировать алгоритмический контекст адресов и процедуру эволюции форматов.¹

Rendezvous, мобильность и изменение адресов

Одно из центральных свойств HIP в RFC 7401 — поддержание непрерывности коммуникации при изменении IP-адресов за счёт разделения ролей identifier и locator.² RFC 9063 описывает HIP-слой как поддерживающий end-host mobility, multihoming и NAT traversal.¹

В терминологии RFC 9063 Rendezvous Mechanism — это механизм поиска мобильных хостов по их HIT.¹ В RFC 4423 rendezvous mechanism также определялся как механизм, используемый для поиска мобильных хостов по Host Identity Tag.⁶

Для IPvX отсюда следует осторожная формулировка урока: стабильный ключевой идентификатор сам по себе не описывает, где сейчас находится получатель.¹ Если протокол хочет сохранять идентичность при изменении пути доставки, ему нужен отдельный способ связать идентификатор с актуальным локатором или маршрутом; HIP называет такой класс задачи rendezvous mechanism.¹

Важно не преувеличивать этот вывод.² RFC 7401 подтверждает наличие процедур UPDATE, SEQ и ACK для обработки обновлений HIP association, но из этого не следует автоматическое правило масштабирования для IPvX.² Мы можем использовать HIP как пример того, что изменение состояния ассоциации выделено в отдельные процедуры, однако параметры отказоустойчивости и масштабирования IPvX должны проверяться собственными экспериментами.²

Сертификаты: расширяемость без перегрузки первого пакета

RFC 8002 обновляет RFC 7401 и определяет CERT parameter как контейнер для цифровых сертификатов в управляющих пакетах HIP.⁵ Тот же документ подчёркивает, что CERT parameter не задаёт семантику сертификатов, а конкретные сценарии использования должны определяться документами, которые применяют этот параметр.⁵

Это хороший пример разделения механизма и политики доверия.⁵ Базовый протокол может описывать перенос сертификатов, группировку связанных CERT parameters и сигнализацию ошибок при неудачной проверке, не встраивая все сценарные решения в один универсальный формат.⁵

RFC 8002 содержит и отрицательный урок: использование CERT в первом Initiator packet I1 не рекомендуется, потому что это может увеличить время обработки I1 и стать проблемой при processing storms of I1s.⁵ Для IPvX мы можем сформулировать это как проектную гипотезу: доказательства, сертификаты и аттестации не стоит автоматически помещать в самый ранний и наиболее массовый пакет handshake.⁵ Это именно вывод для нашего дизайна, а не цитируемое требование RFC 8002 к IPvX.⁵

RFC 8002 также описывает варианты передачи указателей вместо самих сертификатов: Hash and URL, LDAP URL и Distinguished Name могут уменьшать HIP control packets, но требуют от получателя разрешить URL, получить сертификат или проверить локальный кэш.⁸ Поэтому при проектировании IPvX-handshake нужно отдельно учитывать компромисс между самодостаточным сообщением и зависимостью от внешнего получения доверительных данных.⁸

Документирование зрелости и ограничений

RFC 4423 был информационным документом и прямо описывал себя как снимок рассуждений об архитектуре HIP на осень 2003 года.⁶ В RFC 4423 также сказано, что архитектура могла измениться и что документ представляет одну стабильную точку в эволюции понимания.⁶ Этот пример важен для исследовательского протокола: статус документа и степень зрелости архитектуры должны быть видны читателю.⁶

RFC 9063 заменил RFC 4423 и остался документом категории Informational, а RFC 7401 является документом Standards Track со статусом Proposed Standard.⁴ Это показывает, что архитектурное описание и базовая спецификация протокола могут иметь разные статусы в процессе IETF.⁴

Security Considerations в RFC 9063 включают flooding attacks, использование identities в access control lists, weaker types of identifiers и trust on first use.¹ Приложения RFC 9063 также включают design considerations, benefits, drawbacks, deployment and adoption considerations, deployment analysis, infrastructure applications и management of identities in a commercial product.⁴ Для наших проектов RFC по IPvX это поддерживает практику явно отделять формат пакета от ограничений, эксплуатационных предположений и известных компромиссов.⁴

История RFC 7401 в Datatracker фиксирует публикацию RFC 9 апреля 2015 года и обновление реестров IANA 10 апреля 2015 года.⁷ Та же история показывает более поздние синхронизации метаданных RFC Editor, включая изменения abstract в 2018 году, добавление тега Verified Errata в 2020 году и обновления метаданных в 2026 году.⁷ Это не доказывает наличие всех последующих обновляющих RFC, но показывает, что публичная запись о документе продолжает поддерживаться после публикации.⁷

Что мы берём в IPvX

Первый урок: при описании IPvX-адресов по ключам полезно явно различать абстрактную идентичность, публичный ключ как идентификатор, компактное хешированное представление и текущий локатор, потому что HIP проводит различие между Host Identity, Host Identifier, HIT и locator role IP address.¹³

Второй урок: установление соединения стоит проектировать как жизненный цикл состояния, а не как один обмен ключами, потому что RFC 7401 описывает HIP association, base exchange, state machine, UPDATE, NOTIFY, CLOSE, CLOSE_ACK и handling state loss.²

Третий урок: rendezvous нужно считать отдельной задачей control plane, потому что RFC 9063 определяет механизм поиска мобильных хостов по HIT и связывает архитектуру HIP с мобильностью, multihoming и NAT traversal.¹

Четвёртый урок: сертификаты и дополнительные доказательства полезно отделять от базовой семантики адреса, потому что RFC 8002 задаёт CERT parameter как контейнер и оставляет сценарную семантику документам, которые используют этот параметр.⁵

Пятый урок: ограничения, отрицательные результаты и история решений должны быть частью наших черновиков, потому что документы HIP явно показывают статус зрелости, security considerations, drawbacks и deployment considerations.⁴⁶

Итог для нас осторожный: HIP не определяет IPvX и не снимает с нас обязанность проверять маршрутизацию, отказы и масштабирование в собственных воспроизводимых экспериментах.² Но HIP даёт опубликованный язык для обсуждения ключевых адресов, ассоциаций безопасности, rendezvous, мобильности и границ между архитектурой, спецификацией и эксплуатационными ограничениями.¹²

Источники

1. RFC 9063: Host Identity Protocol Architecture, rfc-editor.org, 1 июл. 2021 г.
2. RFC 7401: Host Identity Protocol Version 2 (HIPv2), datatracker.ietf.org
3. RFC 7401: Host Identity Protocol Version 2 (HIPv2), datatracker.ietf.org
4. RFC 9063: Host Identity Protocol Architecture, datatracker.ietf.org
5. RFC 8002: Host Identity Protocol Certificates, datatracker.ietf.org
6. RFC 4423: Host Identity Protocol (HIP) Architecture, datatracker.ietf.org
7. History for rfc7401, datatracker.ietf.org
8. RFC 8002: Host Identity Protocol Certificates | RFC Editor, rfc-editor.org