Host Identity Protocol RFC 7401：给 IPvX 地址的启示

Host Identity Protocol RFC 7401 对我们有价值，因为它是 IETF 已发布的一个协议示例：它将 IP 地址中“标识符”的角色与“定位符”的角色分离，并在相互同意的主机之间建立共同的 IP 层状态。² HIP 使用来自 Host Identity 空间的公钥标识符，对参与方进行相互认证，并基于 Diffie-Hellman 交换。² 对 IPvX 地址设计而言，这不是现成的蓝图，而是一组已经在关于 HIP 的 IETF 文档中被明确提出过的架构问题。¹

为什么标识符与定位符的分离很重要

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 是从 Host Identifier 生成 HIT 时使用的加密哈希。¹ 该文档还将 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 交换、带有 DH 组协商的认证 Diffie-Hellman、防重放、放弃 base exchange、中断 base exchange、downgrade protection 以及 opportunistic mode。²

RFC 7401 规范还列出了控制包 I1、R1、I2、R2、UPDATE、NOTIFY、CLOSE 和 CLOSE_ACK。² 同一文档中还包括关于更新 HIP association、错误处理、HIP state machine、使用 SEQ 和 ACK 处理 UPDATE、处理 CLOSE 和 CLOSE_ACK，以及 handling state loss 的章节。²

对 IPvX 来说，这组主题作为连接设计的检查清单很有用，但不能证明 IPvX 必须重复 HIP 的 state machine。² 我们可以用同一类问题来检查自己的设计：关联如何创建，参数如何协商，错误如何发现，状态如何更新，通信如何关闭。² 同时，不应仅凭 RFC 7401 就推出关于“低成本启动”的断言；该来源确实直接确认了 puzzle mechanism 和防护性章节的存在，但并未为任何基于密钥寻址的协议提出通用要求。²

有效载荷安全与关联是不同层次

RFC 7401 表示，HIP designed to be resistant to denial-of-service and man-in-the-middle attacks。² 该文档还指出，在与合适的安全协议一起使用时，例如 ESP，HIP 为 TCP 和 UDP 等上层协议提供 integrity protection 和 optional encryption。²

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、移动性与地址变化

RFC 7401 中 HIP 的一个核心属性，是通过分离 identifier 和 locator 的角色，在 IP 地址变化时保持通信连续性。² 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 确认存在用于处理 HIP association 更新的 UPDATE、SEQ 和 ACK 流程，但这并不自动推出适用于 IPvX 的扩展性规则。² 我们可以把 HIP 作为一个例子，说明关联状态变化被放入独立流程中处理；但 IPvX 的容错性和扩展性参数必须通过我们自己的实验来验证。²

证书：在不压垮首个数据包的前提下实现可扩展性

RFC 8002 更新了 RFC 7401，并将 CERT parameter 定义为 HIP 控制包中数字证书的容器。⁵ 同一文档强调，CERT parameter 并不规定证书的语义；具体使用场景应由应用该参数的文档来定义。⁵

这是机制与信任策略相分离的一个好例子。⁵ 基础协议可以描述证书的承载、相关 CERT parameters 的分组以及验证失败时的错误信令，而不必把所有场景化决策都嵌入一个通用格式中。⁵

RFC 8002 还包含一条反面经验：不建议在第一个 Initiator packet I1 中使用 CERT，因为这可能增加 I1 的处理时间，并在 processing storms of I1s 场景下成为问题。⁵ 对 IPvX 来说，我们可以把它表述为一条设计假设：证明、证书和 attestations 不应自动放入 handshake 中最早、也是最容易大量出现的数据包。⁵ 这正是面向我们设计的结论，而不是 RFC 8002 对 IPvX 提出的被引用要求。⁵

RFC 8002 还描述了传递指针而非证书本身的选项：Hash and URL、LDAP URL 和 Distinguished Name 可以减小 HIP control packets，但要求接收方解析 URL、获取证书或检查本地缓存。⁸ 因此，在设计 IPvX-handshake 时，需要单独权衡自包含消息与依赖外部获取信任数据之间的取舍。⁸

记录成熟度与限制

RFC 4423 是一份信息性文档，并明确将自身描述为截至 2003 年秋季对 HIP 架构思考的快照。⁶ RFC 4423 还表示，该架构可能已经发生变化，而该文档代表理解演进过程中的一个稳定点。⁶ 对研究性协议来说，这个例子很重要：文档状态和架构成熟度应当对读者可见。⁶

RFC 9063 取代了 RFC 4423，并仍然属于 Informational 类文档，而 RFC 7401 是 Standards Track 文档，状态为 Proposed Standard。⁴ 这表明，在 IETF 流程中，架构描述与基础协议规范可以拥有不同状态。⁴

RFC 9063 的 Security Considerations 包括 flooding attacks、在 access control lists 中使用 identities、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。⁴ 对我们的 IPvX RFC 项目而言，这支持了这样一种实践：明确把数据包格式与限制、运行假设和已知取舍分开。⁴

Datatracker 中的 RFC 7401 历史记录了该 RFC 于 2015 年 4 月 9 日发布，并于 2015 年 4 月 10 日更新 IANA 注册表。⁷ 同一历史还显示了之后的 RFC Editor 元数据同步，包括 2018 年对 abstract 的修改、2020 年添加 Verified Errata 标签，以及 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, 2021年7月1日
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