摘要

  • 10 月 27 日提交的一份 IETF 个人草案要求跨域策略对象填写适用区域、所有者、作者、语言和规则内容，却把接收方核对发布者是否有权修改该区域策略写成 MAY。字段必填，授权核验可选。
  • 一份签名能把收到的对象绑定到签署者；能否把它装进另一家机构的决策系统，必须由接收方自己的授权记录回答。

把「所有者」写在包裹上，包裹就归他吗？

假设甲网络把一条策略交给乙网络。接收屏幕显示格式正确、签名有效、对象写明 owner。许多自动化流程会在这里亮绿灯。真正关乎权力的一步却在绿灯之后：甲所声称的所有者，是否获准改变乙网络所辖区域的规则？如果答案只来自甲写进包裹的字段，边界就成了自助盖章台。

10 月 27 日的 IETF 个人草案试图让不同策略语言共用一个 YANG 载体。模型要求 area、language、policy-content、owner、author 五项必填。规则正文对载体是不透明的；它可以运送 Rego，也可以运送另一种安全策略，却不负责解释两者执行后会产生什么效果。origin 和 policy-provenance 在示例模型中不是必填项。这样的设计解决了跨系统如何辨认和传递单件策略的问题，也使接收方不能偷懒：声明的责任人、实际的签署者、可授权的主体，可能是三个人或三个组织。

草案的引言直说了痛点：跨管理域交换时，系统常常不清楚来源是否有权为特定区域制定政策。它随后在第 6.1 节给策略管理点 PAP 一个选择：在接收或分发前，PAP MAY 查询策略决策点 PDP，判断所声明的所有者或提交者是否获准在该区域定义或修改策略。第 6.2 节的图里却摆着醒目的“治理授权检查”。图画得像一道固定关卡，规范用词却允许实施者不设这道关卡。读者不能拿图上的方框当作已经执行的授权判定。

签名检查与授权判定不是同一张回执

草案引用的 YANG 数据来源签名提案为来源和完整性提供技术基础。即便签名验证成功，仍要问接收方将哪个区域交给哪个主体、授权何时开始和终止、谁能撤销、更新版是否仍在授权范围内。owner 字段无法自己签发这些答案。运行时 PDP 后来正确执行规则，也不能倒推出安装规则的人有权下令。

一位草案作者在 NMOP 邮件列表 描述了计划中的双域演示：一边将 Rego 策略交给基于 OPA 的决策点，另一边接收基于 RFC 9061 的策略，让指定节点之间建立 IPsec 隧道。演示的卖点是同一套分发结构跨越异构语言和执行技术。若最终只展示两边都能执行，最关键的治理问题仍未被测量：每边是谁批准安装，批准依据记录在哪里？邮件讲的是将来要做的实验，不是完成后的证据。

IETF Datatracker将文本列为活跃的个人草案，状态为 I-D Exists。本文分析的是提案里现有的授权设计选择，不把它写成已经生效的行业标准或已经发生的跨域事故。

留住一条策略的入境档案

草案明确不规定具体分发协议；它也仅以 MAY 允许 PAP 在外部系统保存历史版本、把创建、更新、激活、回滚和撤销事件记入追加式账本。这些记录若要支持问责，必须再接上授权判定：接收对象的精确版本和哈希、签名密钥、声明的所有者、接收方承认的授权文件、适用区域、安装目标、撤销或回滚动作。缺了这条连接，日志能证明包裹来过，不能说明为什么放行。

RFC 2904早已把授权系统中的职能分开。跨域自动化的难题不在于再画一张职能图，而在于让乙网络在每一次策略变动时签下自己的决定。签字者可以来自甲；准许其行使权力的机构不能由甲假扮。

来源