摘要

  • RFC 3182 把一个或多个 AUTH_DATA 元素放入 RSVP 的 POLICY_DATA。策略定位符告诉节点去哪里找规则，名字、Kerberos 票据或证书提供不同强度的身份材料；这些字段本身都不分配带宽。
  • 身份并非端到端不变。单播用户策略可保留前一跳的定位符，却改用当前网络节点的凭据；多播应用身份则可以取报文中的第一个，也可以由 PDP 选择。
  • 认证成功不等于获得资源授权，更不等于每跳安装、数据包待遇或应用结果。后来的安全分析明确指出保密、漫游授权和跨域信任仍有缺口。

名字终于能跟着预留请求走

RSVP 一开始就面对两个问题：节点有没有资源，以及请求者有没有资格。RFC 2205 把前者称为 admission control，把后者称为 policy control；两者都通过，预留才可能成立。RSVP 负责运送策略数据，却不理解其中全部语义。

RFC 3182 于 2001 年 10 月以 Proposed Standard 发布，为第二个问题补上结构化载体。用户或应用把 AUTH_DATA 放进 PATH 或 RESV 报文，路由器或策略服务器验证材料，再按本地规则作出判断。

它替代 RFC 2752，原因是修正策略元素类型码和错误字段宽度，而不是启动一代新的部署。Datatracker 在 2026 年的更新时间同样不能写成协议升级；那是因为文档带有已验证勘误。

勘误 2958 修正了一个关键动作。原文让验证者把 Kerberos 票据送到 KDC 取得会话密钥；正确做法是服务器从票据中提取会话密钥，再用它认证用户。历史文章若忽略这条勘误，就会把已承认的错误继续当作设计。

策略定位符不是通行证

AUTH_USER 表示用户身份，AUTH_APP 表示应用身份。元素内部仍有分工：POLICY_LOCATOR 用可区别名指向准入策略；CREDENTIAL 携带文本标识、Kerberos 票据或证书；数字签名保护之前的认证数据；策略错误对象返回不支持的凭据、权限不足、凭据过期或身份改变。

定位符回答“去哪里找规则”，凭据回答“验证者看什么”，签名回答“受保护的内容是否与密钥操作一致”。它们没有回答“谁有权给这条流多少资源”。RFC 2753 将 PDP 与 PEP 分开：前者可以查询目录、认证、计费和本地配置后作决定，后者在节点执行。容量不足仍可让策略上获准的请求失败。

因此，结构化名字不因格式正规就获得权力，证书不因签名有效就变成带宽。只有受授权的决策者把经过验证的主体映射到一条适用且当前的规则，身份才在特定范围内产生行动。

三种凭据不是同一个保证等级

最简单的方式只携带 ASCII 或 Unicode 登录名，应用例子甚至只是 vic.exe 文件名。RFC 3182 明说，这种方式没有可安全认证的凭据，安全性天然较低。文件名既不证明二进制内容、发布者、进程所有者，也不证明运行中程序未被替换。

Kerberos 方式要求请求者、下一 RSVP 节点或 PDP 处在兼容的票据与信任体系中。票据可以在相应 realm 里支持主体认证，却没有携带资源策略、实时容量或跨域通用权利。

公钥方式携带证书和签名，依赖私钥保护、受信 CA、证书验证以及相应的状态检查。签名成功说明某个密钥在特定验证上下文中控制了数据，不能独立证明该主体有权申请资源、证书尚符合本地政策或报文所称应用就是实际发流量的进程。

RFC 4230 后来指出，公钥材料会增加逐流信令的计算与带宽成本，撤销检查需要额外机制；Kerberos 也不能在此设计中完全隐藏用户身份。更强的凭据提升了一张收据的质量，没有把整条链折叠成一张收据。

每一跳都可能换一个发言者

RFC 3182 最值得留下的不是证书格式，而是身份在转发中的生成规则。

单播用户策略中，用户的策略定位符从前一跳复制，认证凭据却代表当前网络节点。被谈论的用户与正在为报文背书的节点可能来自不同阶段。多播用户策略更进一步：定位符和凭据都改为当前节点身份。

应用身份采用另一套规则。单播中可以复制前一跳的 AUTH_DATA；多播中，可以留下报文里的第一个应用元素，也可以由 PDP 选一个。最终字段不是全体贡献者的清单，而是顺序或策略选择的结果。

一个报文可以有多个认证元素，策略感知节点和 PDP 也可改写策略数据。若数据库只保存最后一个“已验证身份”，就不知道它来自端主机、上一跳定位符、当前路由器、先到者，还是 PDP 的选择。

这并非必然是篡改，而是跨节点、跨域和多播压缩的一部分。正因变换可以合法发生，记录才必须保留输入、输出、操作者、信任域、安全关联和选择理由。缺少来源链，“验证了身份”连验证的是谁都可能不清楚。

报文通过不代表身份被判断

并非每台 RSVP 节点都必须理解策略。RFC 2753 允许只在部分边界执行策略，让域内 policy-ignorant node 依赖受信的策略节点。RFC 3182 也说明，策略无知的路由器可忽略策略数据并继续处理 RSVP。

这种设计有利于渐进部署，却限制了成功通过的含义。报文穿过某节点，不证明该节点检查了用户、证书、群组或权利。某些跳上存在 RSVP 状态，也可与策略未被评估并存。

策略边界上的 PEP 可以等待 PDP。负面结果导致拒绝，正面结果只是继续普通 RSVP 处理。后续节点仍可能因容量或不同政策拒绝，调度器也可能未安装状态，应用更可能没有获得可用服务。

所以，系统中至少有四种不同状态：身份材料被携带、凭据被验证、策略被批准、资源被执行。把“没有错误”统一写成 authorized，会抹掉规范本身安排的分层。

错误码保存分歧，却没有保存后果

错误对象可以说明凭据类型不受支持、权限不足、凭据过期或身份已改变。PDP 无法验证时，必须向 PEP 返回策略控制失败，并应把更详细原因放入 RSVP 错误报文。

这些错误有价值，因为它们把失败限定在正确边界。EXPIRED_CREDENTIAL 不等于容量不足；INSUFFICIENT_PRIVILEGES 不等于签名损坏；IDENTITY_CHANGED 说明主体状态并非会话建立后永久冻结。

但错误仍不是执行结果。它不能证明所有旧预留已经撤销、数据流停止、每个多播分支收到相同结果、应用看见报错或重试使用了正确身份。错误收据必须链接到状态撤销、数据包观测和应用结果。

当前 IANA RSVP 参数表仍记录 POLICY_DATA 类和策略控制错误值。这证明编号受到协调，不证明每种认证子类型在现网部署，更不证明某台路由器实际作出判断。

完整性保护字节，不保护合法性

当整个 RSVP 报文没有完整性保护时，RFC 3182 建议对策略数据计算完整性。它能在某个安全关联内抵抗修改与重放，并把用户身份材料同始发节点的身份联系起来。

RFC 4230 后来区分了外层 RSVP 报文与内层 POLICY_DATA 的保护范围，也提醒策略节点可以按设计改写内容，用户和应用信息可能离开第一跳后泄露，路由器之间一般没有保密性。

审计因此要问三个问题：字节是否在保护范围内保持一致；哪个密钥或票据认证了哪个行为者；该行为者是否在当前政策下拥有决定权。前两个问题可以借助密码学，第三个不能由摘要值回答。

跨域时差距更大。RFC 2753 预期运营者边界会根据双边协议重写策略对象。RFC 4230 则指出，漫游场景缺少统一的授权数据格式，也没有获得一致同意的 QoS 预留授权办法。身份可以过境，授权仍是本地权力。

可辩护的历史记录是一条收据链

审计先保存原始用户或应用主张，再记录凭据子类型、票据或证书验证、密钥与 realm 范围、完整性和重放上下文，以及准确的认证主体。

下一步不是笼统的“成功”，而是策略定位符、策略版本、控制域、其他输入和 PDP 决定。此后才是 PEP 收到决定、本地容量、执行动作、RSVP 状态，以及沿途的替换、过期或身份变化。

控制面收据之后，还要分别观察调度状态、数据包待遇、路径行为和应用体验。授权可能因容量而失败，本地安装可能在别处失败，路径上存在预留也可能没有产生可用结果。

多播还需保留所有输入应用身份、次序、选择者和被丢弃的贡献者。“第一个”不是授权来源，“PDP 选择”也不代表所有参与者共享同一身份。

Lu Heng 关于符号层、权力层和执行层的区分，为这种审计提供了分析方法，但不能倒写成 RFC 作者的主张。RFC 3182 让名字进入报文；运行中的系统仍须证明谁能决定、决定在哪里生效，以及承诺是否发生。名字只能成为这条链的一项输入，从来不是整条链。

来源与限制

协议记录来自 RFC 3182 文本、RFC Editor 记录、IETF Datatracker、Datatracker API、已验证勘误 2958 及被替代的 RFC 2752。控制与安全语境来自 RFC 2205、RFC 2750、RFC 2753、RFC 2747、RFC 4230、RFC 4094 与后来的 RFC 4923。凭据历史取自 RFC 1510 和 RFC 2459，当前登记视图取自 IANA RSVP 参数表。

分析方法受到 Lu Heng 的现实层级与运行代码优先启发。18 个来源于 2026 年 10 月 2 日在 Asia/Shanghai 冻结。它们没有识别具名实现、运营者、用户、应用、预留、攻击、部署、互通测试、流量轨迹或服务结果。Proposed Standard、登记值、有效凭据、PDP 批准和本地 RSVP 状态都只能证明自己的层面。