摘要

  • RFC 2989 评估的是 AAA 协议提案的能力；某项能力是 MUST，不代表每次交换都必须或已经启用它。
  • NASREQ、ROAMOPS 与 Mobile IP 各自保留一列，说明共同表格并没有把不同场景压成一套通用运行政策。
  • 传输确认、句法解析、语义决定、计费责任、授权执行与最终服务是不同回执。

这张表管到哪里

RFC 2989 没有发明一套新的 AAA 线缆协议。它做的是归纳：把不同工作组对认证、授权与计费的要求整理成可比较的矩阵。

表格分为通用要求、认证要求、授权要求、计费要求与 Mobile IP 特有要求。横向仍保留 NASREQ、ROAMOPS 和 MOBILEIP 三列；单元格用 M、S、O、N、B 表示 MUST、SHOULD、MAY、MUST NOT 与 SHOULD NOT。

共同格式让提案可以被比较，独立列则保存要求的出处。某项能力在接入服务器环境中是 MUST，不会因此自动成为漫游体系每个部署的同一条命令。

第 1.1 节划定了矩阵的管辖范围：这些规范词用于评价协议能力。提案若对自己实现的能力违反 MUST 或 MUST NOT，就不合规；满足强制项但没有满足全部建议项，叫“有条件合规”；连建议项也满足，叫“无条件合规”。

这些结论描述提案，不描述现场。

文档用保密性直接举例：要求协议支持保密，不等于要求所有协议流量都加密。能力存在，只能证明设计提供了一个合规手段。要证明一次交换，还需要版本、配置、密钥、对端、协商结果、受保护对象与验证结果。

清单审查候选者，运行环境决定是否使用。

MUST 不是遥测数据

RFC 2119 让规范词在既定范围内具有约束力，却不会悄悄扩大主语。RFC 2989 的主语是协议提案的能力。

三列要求本来就不完全相同。可扩展性在三个环境中都是强制项；故障切换在 NASREQ 与 Mobile IP 中被明确要求；IPv4 普遍为 MUST，而 IPv6、证书传输和可审计性的力度各异。空白单元格不等于禁止，M 也不等于每个数据包都必须触发该机制。

后来的证据越权通常沿着一条顺滑的链发生：产品宣称支持，采购文件写成保障，配置面显示已连接，报表便写成用户获得服务。每一步都增加了上一层没有观察到的事实。

最小初始规范的价值，恰恰是只协调必要的比较面，不替各运营者预先决定所有本地策略。

两种安全边界

RFC 2989 把传输层安全与对象层安全放在相邻要求中，却为它们规定不同的保管范围。

传输层安全是逐跳的。相邻 AAA 实体可以认证彼此、保护完整性并加密连接；接收实体处理消息时，这层安全被移除。下一跳要建立新的关系。

对象层保密可以让某些属性只由最终目标解密，即使消息经过代理或 broker。对象层认证与完整性应穿过中间实体持续存在，被覆盖的数据不能由代理修改。

协议同时支持两者，不证明一次运行把它们正确组合。代码可能存在而功能未配置；代理可能终止外层安全而保留内层对象；重要字段可能不在保护范围；密钥可能过期；验证失败后还可能进入本地回退。

能力说明“可以做”。运行证据才说明“这次做了什么”。

送达不等于理解

可靠 AAA 传输要求不仅依赖单跳传输重试，还包括逐跳重传与切换、由 AAA 应用控制重传、及时返回以及可搭载在 AAA 消息里的确认。

RFC 2989 还专门写到传输层确认：它表示消息已经成功送达，并明确说这与消息的语义或句法评价分开。

接收端可以先确认收到，随后拒绝编码或属性。代理可以完成当前一跳，下一跳仍失败。备用服务器可以可达，却没有同步最近的会话状态。及时到达的响应也可能是拒绝。

因此，一个“成功”位无法承担整条链。可审计记录至少要保留尝试身份、跳点、重传、切换目标、传输回执、解析结果、语义决定与 NAS 动作。

把边界分开，不是削弱可靠性，而是不给传输层它没有观察过的决定权。

计费回执接手了责任

计费表中的“保证送达”使用另一种确认。它是应用层确认，只有在接收服务器愿意对消息数据承担责任时才发送。

这比字节到达更强，却仍不等于持久化、副本完成、冲突消解、费率计算、开票或付款。RFC 2989 把 accounting 定义为为趋势、审计、billing 或成本分摊而收集资源使用信息，又把 billing 单独定义为准备发票。

动态再授权还可能让一个会话产生多条计费记录。接手责任只是关闭一个环节；存储、对账、计价和客户结果仍需各自回执。

可审计不等于正确

RFC 2989 把可审计过程定义为：能够明确判断 AAA 数据包从 home AAA server 到网络设备再返回的途中，经历了哪些动作。

这很重要，因为中间角色权限不同。本地代理可以执行本地政策；透明代理按定义不应添加、删除或修改转发信息；代理型 broker 留在消息路径中，路由型 broker 则可以在路径外返回建立直接联系所需的信息。

日志能够证明发生了某种变换，却不能仅凭日志存在就证明变换被授权、身份正确、政策合理、NAS 执行了回复，或用户得到服务。

可审计性描述保管与变换。正确性和结果仍要另验。

三个 A 不能相互代签

认证验证声明的身份是不是消息发起者或信道端点；授权决定是否授予某项权利；计费收集资源使用信息。

RFC 2989 甚至要求协议支持“授权时不强制再次提供用户凭据”，可以凭标识或断言完成授权交换。这不表示断言会自证真实性，而是承认证明可能在另一条关系中已经建立。

拒绝能力、访问规则、再授权、状态对账与断开请求都是控制面。它们不能单独证明设备已经执行，更不能证明业务结果。

清单留下的纪律

RFC 2989 的历史价值不在于表格很大，而在于它没有让表格越权。

能力不是启用。送达不是理解。责任接手不是账单。可审计不是正确。授权不是可用服务。

用 Lu Heng 的现实层次观察，这条链依次是：要求来源、RFC 文本、协议能力、实现、配置、消息、中间处理、决定、设备效果和用户结果。前一层为真，不代表它可以替后一层作证。

运行代码要补上缺失的回执：实际选择了什么机制、在哪个边界确认、什么政策生效、什么状态改变、最终观察到什么。

清单给候选协议打分。网络仍要提交证据。

来源