摘要

  • RFC 10065 为 YANG 访问控制列表加入按群组匹配与时间条件，并定义了通过 RADIUS 传递用户群组标识的属性。
  • 群组标识本身不能证明是谁分配了该群组、它如何映射到报文字段，也不能证明每个执行点都收到了正确规则。

分析

该模型首先要求把三件事分开记录：谁分配群组、控制面如何把它映射到规则、哪个执行点收到并落实了规则。一个可读的群组名不会自动串起这三项证据。

在移动用户、VPN、虚拟机迁移和临时 IPv6 地址并存的网络里，IP 地址很难长期代表一个人、设备或工作负载。按地址或五元组编写的 ACL 仍然有用，但它必须跟上端点变化。RFC 10065 试图降低这项维护成本：让一组共享同一访问策略的端点通过群组来关联规则。

该 RFC 扩展了 RFC 8519 定义的 YANG ACL 模型。ietf-ucl-acl 模块可以定义用户组、设备组和应用组，为每组配置标识，并允许 ACL 条目把源端或目的端群组作为匹配条件。它还加入 effective-schedule，可表示某个明确时段或重复周期，并复用 RFC 9922 的通用 YANG 时间计划模型。这里有个容易被忽略的默认值：没有配置计划时，ACL 条目会立即生效并持续应用。

在用户认证流程中，新的 RADIUS 属性 User-Access-Group-ID 用来携带群组标识。RFC 10065 将它分配为扩展属性 241.12，类型为字符串，群组标识值最多 64 个八位字节。认证成功后，Access-Accept 可以返回一个或多个群组标识。Access-Request 也可以带上偏好的标识，但服务器没有义务接受。该属性还可以出现在 Change-of-Authorization 请求或 Accounting-Request 中；后者可用于让 NAS 确认自己收到该属性并正在执行相关策略。

这条 RADIUS 消息只是更长控制链中的一环。AAA 服务器依据本地配置的条件给用户分配群组。控制器可以把群组标识映射到报文字段，再将普通的地址或五元组 ACL 下发到策略执行点。另一种方案让设备直接按群组标识匹配规则。集中式控制器能减少每台设备实现专用群组逻辑的需求，但必须及时同步变化。设备侧匹配可减少控制器反复介入，却可能要求升级软硬件；若 NAS 自己执行群组策略，转发性能也可能受到影响。

关键边界在于：RFC 定义的是接口，不是企业的身份权威。它没有规定采用哪种认证方式、用户凭什么被分入某个组，也没有定义在封装场景中群组标识如何映射到报文头字段。规范要求部署方建立适当的映射机制，并提醒在 RADIUS 等多套机制并存时维持一致。群组名称因此不是独立的身份或权限证明；它的含义取决于本地分配和解释它的系统。

配置面本身也很敏感。群组清单、ACL 匹配条件和时间计划都是可写的 YANG 数据。未授权修改可能创建或删除群组、放行本应拒绝的流量、阻断合法流量，或改变规则生效时间。读取计划数据也可能暴露规则的启用窗口。RFC 10065 要求通过安全传输并相互认证的 NETCONF 或 RESTCONF 管理设备，并指出 NACM 可限制每位操作者可执行的操作。对于 RADIUS，它假设客户端和服务器之间存在可信关系；IPsec 或 TLS 在本文中属于可选保护措施。

RFC 10065 的状态是 Proposed Standard，并不证明已有部署采用。它提供的是一套可共享的控制语言，用来应对端点变化和有时间条件的规则。真正的运营问题，是每个部署能否保留从认证、群组分配、策略映射、规则安装到实际流量验证的完整链条。

来源