摘要

  • RFC 9899 允许运维人员在不重写父 ACL 规则的情况下增删 defined set 成员；稳定的规则文本不等于稳定的有效匹配范围。
  • 可复核的历史必须连接变更身份、完整解析集合、逐设备 intended/operational 状态、挂载点、计数与最终业务结果。

变更单看上去很小：某个前缀集合增加了两个成员。审批页面没有显示任何 ACL 规则变化，规则名称、顺序和动作也都保持原样。事故发生后，团队调出父规则的版本记录，看到整段文本前后一致，便把“策略未变”写进结论。

真正改变策略含义的，恰恰是那两个没有出现在父规则 diff 里的成员。一台设备已经收到新集合，一台还在旧状态，第三台的 operational 读回缺了一部分。规则确实没有改；它所指向的对象变了。

这不是 RFC 9899 的缺陷，而是它带来的管理能力。基础 RFC 8519 把 ACL 描述为按用户顺序排列的 ACE。每条 ACE 组合匹配条件与动作，动作可以接受、丢弃、拒绝、计数或限速。只有当 ACL 被应用到接口等 attachment point 后，匹配与动作才进入数据包处理路径。

RFC 9899 在此基础上加入可命名、可复用的 IPv4/IPv6 前缀集、端口集、协议集与 ICMP 类型集，也允许 alias 同时组合地址、协议、端口或 VLAN。安全团队不必在许多规则里反复抄写同一批字面值。它可以维护一个集合，让多个 ACE 引用。

标准明确说明，这种设计把规则创建与集合管理解耦；集合可以增删成员，而父 ACL 规则无需重新定义。它还把 ACL 与 defined set 从单设备对象扩展为网络或管理域对象，再关联到多台设备。复用减少重复劳动，却也让一次很短的集合变更拥有跨规则、跨设备的语义半径。

因此，历史主键不能只有“规则名＋时间”。它至少要带上当时所有被引用集合与 alias 的完整成员、模块修订、解析顺序、目标设备和挂载点。否则，同一个名称在两个时刻可能代表不同流量，同一时刻在两台设备上也可能代表不同状态。

一个典型时序足以说明问题。10:00，集合有十个前缀；10:05，获授权的操作员替换其中一项；10:07，控制器收到成功响应；10:09，第一台设备已应用，第二台尚未应用；10:10，流量到达。父 ACE 在五个时点完全相同。只查 ACE 版本，无法回答两台设备各自匹配了什么。

RFC 8342 提供了必要的数据存储层次。<running>、<intended> 与 <operational> 不是同义词。intended 是经过转换后、系统尝试应用的配置；客户端可把它与 operational 中的配置部分比较，判断有多少意图正在使用。标准还承认 inactive 配置、remnant 配置、传播时间以及配置未能立即或成功应用的情况。

这要求审计同时保存中央意图与逐设备读回。模板展开、默认值、能力过滤、厂商 augmentation、失效分支都可能改变最终对象。控制器里“期望如此”是证据，但不是设备“当时确实如此”的替代品。

管理协议的成功也有边界。RFC 6241 中的 NETCONF <ok> 表示 RPC 处理时没有错误或警告且无数据返回；RFC 8040 用 201、204 等状态表示 RESTCONF 资源创建或修改成功。这些响应证明管理事务完成到某个范围，不是某个后来数据包的回执，更不是应用成功证明。

管理权限与报文过滤也不能混为一谈。RFC 8341 的 NACM 控制用户对 YANG 内容与操作的读、写、执行权限。RFC 9899 为敏感 defined set 使用 nacm:default-deny-write，因为未授权改写可能放行本应拒绝的流量，也可能拒绝本应放行的流量。NACM 能说明谁被允许改配置，不能说明后来的包是否命中 ACL。

运行计数比配置截图更接近事实。RFC 8519 提供 ACE 以及可选接口范围的只读 matched-packets 和 matched-octets。计数增长说明报告设备把流量归入某条 ACE；但它仍需要计数重置时间、采集范围、时钟、挂载点与当时解析集合。它通常不保存原始包、不识别用户，也不证明端到端业务结果。

零计数尤其危险。它可能意味着没有命中，也可能意味着设备不支持该计数、查询错了接口、计数刚重置、采集错过窗口、ACL 没有挂载，或该设备仍使用不含目标地址的旧集合。没有观测范围与失败路径，零只是一个数，不是无事件证明。

RFC 9899 还增加 payload pattern、MPLS、VLAN、I-SID、分片、TCP flags 与 rate-limit 等表达能力。payload matching 可指定 offset、长度、二进制 pattern 与 operator。标准指出，对未加密数据，pattern 过滤具有确定性；对加密流量，效果取决于是否仍存在不变且可见的 pattern。模型能表达条件，不表示网络一定暴露足够字节供它有效判断。

RFC 7950 让 YANG 能严谨描述配置、状态、RPC 与通知。它解决的是表示形状和语义约束，不会自动跨越到物理执行。schema 验证回答“对象是否符合模型”；operational 读回与流量证据回答“设备是否这样运行”。

可靠证据链应从获认证的操作者、会话、NACM 决定、请求正文、目标 datastore 与响应开始。随后冻结父 ACL、ACE 顺序、所有传递引用的集合与 alias、模块版本、设备能力、关联设备、挂载点、intended 和 operational 快照。再加入带重置 epoch 的计数、日志、必要时的 packet/flow 观察，最后由应用系统保存自身结果。

回滚也必须恢复“解析后的整体”。只恢复父规则而不恢复集合，不是回滚；只在控制器恢复对象而不确认每台设备的 operational 状态，也不是完成。last-known-good 应包含引用图、成员、模块修订、目标清单和验证探针，而不是一个熟悉的 ACL 名称。

Heng Lu 的运行代码优先在这里不是让设备吞并所有证据权，而是让每个系统只为直接执行的事实作证。配置服务证明它处理的事务；设备证明它暴露的运行状态和计数；探针证明它看到的包；应用证明它提交的结果。

现实层提醒我们，稳定的父规则只是一个符号，不能遮住其可变引用层。数据主权的技术与实践区别防止把技术控制夸大成全局结论。最小初始规范则允许公共模型保持薄而互通，把集合所有权、发布波次、保留与回滚交给能观察本地系统的人。

管理层真正要问的不是“ACL 有没有改”，而是：“这台设备在这个时刻运行的是哪一份完整解析策略，它报告哪些流量命中，又由哪套独立记录证明后续结果？”

Sources