RFC 5224：策略结果不是执行凭证

摘要

RFC 5224 登记了命令码 314、OMA 厂商空间中的 Policy-Data AVP 以及应用标识 16777243。它们让两端知道消息属于哪一种交换，却不会自动证明消息中的事实完整、当前或来自有权决定的人。
OMA 架构明文允许“只评估”的路径：策略决定可以返回给请求资源，由后者决定如何处理；另一个执行组件才负责动作。因此，成功答案不能天然充当执行回执。
成熟的自动化应当把请求、策略版本、输入来源、决定、执行点接收、安装、启用、后续覆盖和观察到的效果串成可核对的链，而不是把整条链压成一个 policy applied。

一个过早变绿的控制台

设想一段用于审计推演的时间线，而不是现实事故。10:20:00，业务资源发出 Policy-Data-Request。10:20:01，Policy-Data-Answer 返回：应用标识正确，请求与答案能够关联，结果码落在成功区间。控制台随即把该资源显示为“策略已应用”。

然而 10:20:02，负责落地策略的适配器还未连接。10:20:03，本地保护规则拒绝了答案中的一项动作。10:20:04，目标会话已经更换。10:20:05，一条更新的策略决定覆盖了旧决定。审计系统里唯一稳定保存的，只是 10:20:01 收到过答案。

那个答案并不虚假。问题在于，控制台借用了它尚未拥有的过去时。

RFC 5224 是一份篇幅很短的 Informational RFC。它为 Diameter 策略处理应用登记命令码与标识，并概述输入和结果如何承载。它把详细规范明确交给 OMA PEM-1 技术规范第 5.4.1 节。这个分工决定了文章的证据边界：RFC 可以证明命名空间和消息类型已经协调，却不能替部署回答是谁选中了策略、输入是否可靠、请求者如何解释结果、执行点是否采取动作，以及服务状态最终是否改变。

号码让解析器达成一致，不会任命决策主体

命令码 314 同时用于 PDR 与 PDA；Policy-Data 在 OMA 厂商 AVP 空间使用代码 1；策略处理应用的 Application Identifier 是 16777243。IANA AAA 参数登记表仍保留这些分配。OMA 的绑定还使用厂商标识 30079，并在 Diameter 能力交换中声明应用支持。

这些都是重要的互操作事实。没有共同编号，节点甚至无法可靠地判断应使用哪一套语法。但编号回答的是“这是什么消息”，不是“谁有权为这个主体、这个资源、这个时点作出决定”。

Application-Id 不是委托书。Vendor-Id 不是业务授权。能力声明说明一个节点声称支持应用，却不说明它应当成为本次请求的政策权威。Realm 和 Host 可以把消息送往某个节点；路由成功不等于权力来源正确。

安全传输也应保持它自己的准确名称。RFC 5224 继承 RFC 3588 的安全考虑；后来取代它的 RFC 6733完善了 Diameter 基础协议与受保护的对等通信。经过保护的连接能够认证对端并维护消息完整性，这是必要证据。但它不会证明 Policy-Data 中每个输入都来自正确系统，也不会证明已认证对端对目标资源具有业务决策权。

一次审计至少要把三层“可信”分开记录：密码学对端、获准使用该应用的关系、对具体政策决定具有权限的主体。部署可以把三者绑定起来，但绑定本身也是需要配置与记录来证明的事实。

可扩展容器扩大了责任，而不是扩大了证明力

OMA PEM-1 技术规范解释了为什么接口需要 BLOB 和模板。不同政策需要不同输入，也会产生不同输出；标准模板和自定义模板让同一调用框架容纳这些差异。

模板标识与版本可以告诉接收方怎样解析字段，却不能证明发送方提供了全部必需事实。字段存在，不代表事实新鲜；格式正确，不代表来源可靠；双方都能解码自定义模板，也不代表双方对字段的业务含义完全一致。

规范对自己的界面范围非常坦率。如何存储、发布或宣传所支持的 PEM-1 选项，不在其范围内；PEEM 实现如何处理输入参数，以及请求资源如何处理输出参数，也不由该接口规范决定。这里没有一块需要由乐观推断填满的空白。这里是本地控制开始的地方。

如果策略依赖账户余额、位置、订阅状态或风险评分，审计记录就应保存每项事实的来源、观测时间和有效期，并把它们绑定到原始 Policy-Data、模板版本、请求标识、主体、资源与策略版本。策略引擎若调用其他资源，还应保存从属请求与结果的关联。否则“策略评估成功”只能证明一个不透明函数返回了值。

“策略处理”可能走向不同终点

PEM-1 将 policy processing 定义为策略评估，或策略评估加执行。同一个词组覆盖两条路径，因此任何只记录“processed”的系统都丢失了关键分支。

OMA PEEM 架构把差异画得很清楚。PEEM 可以把决定返回给请求资源，由那个资源控制如何处理；也可以自己执行，甚至可能不返回值。文档还专门展示了只做评估、不由 PEEM 执行动作的模型。

组件分工同样明确：评估组件识别政策、读取上下文并返回结果；执行组件依据结果采取动作，还可能继续委托其他资源。两个组件可以部署在同一个进程，但共址只缩短了交接距离，并没有把“决定”和“动作”变成同一个事实。

IETF 自己的政策术语保持了相同纪律。RFC 2753把决定放在 PDP，把真正执行放在 PEP；RFC 3198把 policy enforcement 定义为执行政策决定。规范要求正确工作的 PEP 执行 PDP 的决定。可是“必须执行”属于行为要求，“本次已经执行”属于事务证据。把前者抄进审计报告，不能生成后者。

一个答案里至少有三种“结果”

Diameter 有协议结果：Result-Code 或 Experimental-Result 表达应用或厂商定义的成功与失败类别。这里的 Experimental 是 AVP 名称的一部分，不表示网络已经完成某种实验并观察到效果。

PEM-1 还有 Output Status 模板，其必填 statusCode 表示策略处理的最终状态或 PEEM 识别的错误。与此同时，政策本身还可能输出决定或数据，交给请求资源解释。

这三层可以同时成功，却仍停在执行之前：Diameter 消息被接受，PEEM 完成处理，决定被送回，而请求资源随后拒绝、无法安装、只安装一部分，或在启用之前收到更新决定。反过来，PEEM 也可能在内部完成执行，只返回有限状态。一个通用绿灯无法告诉读者发生了哪条路径。

因此，状态名称必须服从证据：已传输、协议接受、处理完成、决定返回、执行方接收、已安装、已启用、效果已观察、已被覆盖、已回滚。并非每个系统都需要全部状态，但任何系统都不应让一个状态冒充全部状态。

无状态会话不会替你保存政策生命周期

OMA 的 Diameter 绑定把 Auth-Session-State 设为 NO_STATE_MAINTAINED。服务端不维护该 Diameter 会话状态，客户端也不需要发送会话终止请求。这适合一次可调用交换，却也提醒运营者：协议没有承诺保存的历史，不能在事后凭空出现。

匹配的答案能证明某项请求收到了响应。它不会创建持久政策租约，不会说明安装保持了多久，也不会记录本地执行器何时替换旧决定。需要这些事实的系统，必须在应用层和执行层自行记录。

这也把本文与相邻文章分开。RFC 3539处理 AAA 传输的看门狗、故障转移、待处理请求和重复问题；它可以解释答案是否重试或重复，却不会把接收答案变成执行。RFC 2989列出 AAA 能力要求；具备某项能力仍不等于一次具体动作已经发生。RFC 7683的过载控制与 RFC 4006的信用控制则从不同方向说明：消息交换、应用状态和服务效果需要各自语义，不能用“成功”一词全部吞并。

在控制权交接处生成回执

可问责链条不要求一座无所不知的中央数据库，但要求各组件留下可以连接的窄事实：

原始请求、相关标识、客户端、Realm/Host 路径与安全对端；
主体、资源、策略标识和版本、每项输入的来源与时间；
评估依赖、从属调用与返回决定；
协议结果、PEEM 状态和政策输出的独立字段；
被指定的执行组件以及它对决定的接收回执；
安装目标、旧状态、期望状态与冲突检查；
启用时间、局部失败和回滚路径；
覆盖旧决定的后续政策或本地状态；
能看见真实效果的系统所做的观测；
把效果或失败连接回原始请求的对账记录。

记录应当累积证据，而不是重写过去。后来被覆盖的决定，仍然曾经返回；安装失败不应把先前答案改写成失败，而应新增“未安装”这一层。只有保留因果链，系统才能准确补偿，也才能把责任放回真正控制该环节的组件。

Lu Heng 对现实层与符号权力的区分，为这一协议问题提供了严格而朴素的检验。应用标识是符号，答案是记录，政策决定是指令。只有运行中的系统接受、安装、执行并暴露可观测状态，后续现实才出现。最可靠的链条不是让每一层都宣称最终成功，而是让每个事实保留它真正获得的窄名称。

策略引擎给出了结果，执行仍是另一件事

为何重要

摘要

一个过早变绿的控制台

号码让解析器达成一致，不会任命决策主体

可扩展容器扩大了责任，而不是扩大了证明力

“策略处理”可能走向不同终点

一个答案里至少有三种“结果”

无状态会话不会替你保存政策生命周期

在控制权交接处生成回执

来源

档案背景详情

Strategic Circle

Leadership Alliance

Strategic Circle 专属简报

Leadership Alliance 简报