Summary

  • RFC 5221 要求地址选择机制既能动态更新和集中控制，又能按节点、应用和接口区分策略，并与下一跳选择协调。因此，控制器发布、主机安装与实际通信是三类不同证据。
  • 管理层需要一张“策略状态收据”，分别记录控制器权限、策略完整性、交付、适用范围、安装状态、路由同步、最终地址对、对端可达性和应用结果，不能让前一步替后一步作证。

一张全绿面板回答不了最重要的问题

版本 47 在九点发布。几分钟后，所有受管主机都报告下载完成，签名校验通过，配置代理没有错误。若审计只看分发系统，这次变更已经成功。

但主机并不是同一种抽象终端。有的节点承担固定服务，有的节点频繁切换网络；同一台机器上的应用可能有不同的连续性要求；两个接口可能通往不同的管理域，也可能接收不同的下一跳信息。中央表格完全一致，不代表每个现场条件都一致。

RFC 5221 的价值正在这里。它没有指定一套唯一的策略分发协议，而是列出更新默认地址选择规则的机制应满足的要求。除了动态更新与集中控制，它明确要求支持节点特定、应用特定和接口特定的行为，还要求地址选择与下一跳选择相协调。

集中管理追求一致性，通信决定需要情境正确性。这两者不能用同一个安装百分比来证明。

“已部署”至少包含九个状态

第一，发布策略的控制器必须对目标群体拥有权限。第二，策略对象在传输中必须保持完整。第三，它要到达正确节点。第四，节点安装的必须是预期版本。第五，规则必须适用于当前应用。第六，它还要适用于实际使用的接口。第七，策略假设必须与当时的路由和下一跳状态一致。第八，协议栈选出的源地址与目的地址组合必须符合预期。第九，对端应当可达，应用也应获得发布策略所要实现的结果。

每一步都可能在前一步成功后失败。有效签名不能证明签发者对所有应用都拥有授权。安装回执不能证明接口例外没有被抹掉。规则命中不能证明下一跳没有改变。选出地址组合不能证明对端会回应。连接建立也不能证明用户任务完成。

因此，审计记录不应只有“部署率”。它应保存逐步证据、观察时间、版本、范围与责任人。任何一步缺失，都只能报告缺失，不能借用上一层的绿色状态。

中央模型与本地现场会发生时间差

控制器看到的是经过采集、计算和发布形成的全局模型。主机面对的是此刻的接口、路由、应用调用和连接状态。即使双方都没有软件故障，两份事实也可能来自不同时间。

移动节点刚刚切换接入点，新的接口已经出现，控制器尚未收到变化。路由器发布了新的偏好，主机已经采用，策略版本却仍依据上一份拓扑。长连接跨越策略切换，而新连接使用另一套规则。统一表格在发布时可能合理，到达现场时却已经失去适用条件。

这不是反对集中控制。恰恰相反，可靠的集中控制必须保留决定适用性的维度。若发布记录只写“全站”，却不写节点类型、应用类别、接口状态和有效时间，那么它传播的是缺少主语的判断。重复得越一致，错误反而越难定位。

地址偏好与下一跳共同产生一个结果

RFC 5221 要求地址选择与下一跳选择协调。RFC 4191 则说明主机可以接收路由器偏好与更具体路由信息。两份文件都不能证明某个现实产品已经正确同步这两个平面，但它们足以说明：把地址策略和路由状态分开审计是不完整的。

地址规则依据某种拓扑和管理意图偏好源地址或目的地址；路由状态决定数据包实际交给哪个下一跳。若策略快照与路由快照不是同一接口、同一时间或同一管理范围，两个子系统各自都可能“健康”，组合后的决定却是错误的。

真正可审计的对象不是策略文件，而是一次决定。抽样记录应包含节点、应用、接口、策略版本、命中规则、候选地址、选中组合、路由、下一跳、时间、对端回应和应用结果。只有这样，“策略已安装”才会变成可验证的具体命题。

签名有效仍不等于策略可用

RFC 5221 指出三类安全问题：策略信息可能泄露；恶意注入或修改策略可能重定向流量；策略控制器遭遇拒绝服务，会阻止节点获得恰当通信所需的策略。

这意味着传输认证与完整性是必要条件，却不是终点。系统还要限定授权范围，防止旧版本重放，记录签发和审批来源，设置过期与回滚条件，定义控制器不可用时的安全行为，并证明本地例外没有在中央归一化过程中被静默扩大或删除。

“签名有效”和“当前适用”回答的是不同问题。一份旧策略可以保持真实签名；一名真实控制器也可能无权为某类应用发布规则。安全审计若止于主机接受对象，就没有审计这个对象实际造成的通信决定。

证据边界

RFC 5221 是需求文件，不是部署报告。它没有证明某个机制满足所有要求，没有证明某个厂商发布了危险策略，也没有记录当前网络中的策略劫持事件。RFC 3484 提供历史默认规则背景，后来由 RFC 6724 取代；本文不建议恢复旧排序表。

本文也不重复 RFC 5220 已讨论的半封闭网络与回程失败，不提出 Happy Eyeballs 式连接竞速，更不重新定义地址族排序。结论只针对管理链：中央送达不能证明规则范围正确、与下一跳同步或通信成功。

给每次策略变更留下一张状态收据

每个重要版本应保存：控制器身份与授权、审批人、策略哈希与版本、目标节点类别、应用类别和接口条件、签发与过期时间、交付和安装计数、本地覆盖项、路由假设、抽样决定轨迹、控制器不可用时的行为、回滚阈值及实际应用结果。

失败与例外不能被当作噪声丢弃。拒绝版本的节点、仍运行旧版的主机、没有匹配规则的接口、绕过预期接口的应用调用、比策略更新的路由状态、没有回应的对端以及回退路径，共同划定策略真正生效的边界。

Lu Heng 强调运行事实、可归责主体以及现实而非机构叙事。控制器团队能够证明发布，终端团队能够证明安装，网络团队能够证明路由状态，应用负责人能够证明结果。没有任何一方可以借用另一方的证明。领导责任，是让这些证据连接起来而不被压成一个百分比。

Sources

补充标准记录

  1. RFC 5221 纯文本
  2. RFC 5221 信息页
  3. RFC 5221 Datatracker 记录
  4. RFC 5221 勘误记录
  5. RFC 3484 信息页
  6. RFC 6724 信息页
  7. RFC 4191 信息页