摘要
- RFC 5191 中的 PANA Security Association 用于保护 PaC 与 PAA 之间的 PANA 头部、载荷和承载的 EAP 消息。它没有自动为普通用户数据建立逐包加密。
- 数据面保护、PAA 到 Enforcement Point 的策略投影、过滤规则安装和端到端交付分别属于不同控制面。把一个成功的 AUTH 校验扩写成“安全接入完成”，会把未发生的执行藏在可信信令之后。
这类误判最危险的地方，是最早的证据确实是真的。攻击者没有篡改 PANA 消息，Key-Id 没有错位，AUTH 也没有失败。错误发生在解释层：系统把“控制消息得到认证”改写成“此客户端的每个数据包已经得到同样保护”。
PANA 是 EAP 的 UDP 下层。PaC 与 PAA 通过它完成认证与授权相关的会话。当 EAP 方法导出 MSK 时，双方可以派生 PANA_AUTH_KEY，由 AUTH AVP 保护后续 PANA 信令。RFC 5191 将这项保护的对象写得很清楚：双向 PANA signaling traffic。
同一份 RFC 随后单独讨论逐包 ciphering。若底层网络没有提供保护，可以从 PANA SA 派生材料，再通过链路层机制或 IPsec 一类 secure association protocol 保护数据。如何派生并使用这些密钥不在 RFC 5191 的协议范围内。
“可以作为后续密钥来源”与“后续保护已经建立”不是同一个事实。
两个安全关联，两种权威
PANA SA 的证据对象应包含 Session ID、Key-Id、MSK 代际、AUTH 验证结果、覆盖的消息、创建时间和会话寿命。它回答的是：这条 PANA 控制消息是否来自拥有相应密钥的一方，内容是否保持完整，序列是否可接受。
数据面安全关联则需要另一组字段：两端标识、流量 selector、算法、密钥标识、安装节点、replay window、收发计数、到期时间和协商结果。它回答的是：哪些用户数据包受到怎样的保护。
两者之间可以有派生关系，但不能合并为一个布尔值。PANA SA 存在而数据 SA 缺失，可能是政策允许底层保护，也可能是后续建立失败。只有明确记录政策与执行结果，才能区分二者。
若运营平台只保留“secure=true”，它既无法证明保护对象，也无法在故障后判断应检查 EAP 密钥、PANA 会话、IPsec、链路层还是执行点。
认证成功仍可能没有授权
信令保护也不能取代授权。RFC 5191 明确描述 EAP 发出 Success、但 AAA 或 PAA 本地策略拒绝网络访问的情况。PAA 必须返回 PANA_AUTHORIZATION_REJECTED，最终交换即使有 MSK 也可由 AUTH 保护，随后会话终止。
这意味着一个被正确认证的拒绝消息仍然是拒绝。密钥存在不能把拒绝改成许可，EAP Success 也不能越权替 PAA 做访问决定。
证据链必须分别保留 EAP 方法结果、主体、是否导出 MSK、授权决定、决定来源、服务范围、寿命与会话结局。若只保留 EAP Success，调查人员会去修复一个已经正常工作的身份系统；若只保留 AUTH 通过，则会把受保护的拒绝误读成受保护的接入。
真正的安全不是让所有状态变绿，而是保留每个决定的控制者。
Complete 也没有读取执行点
最终 PANA-Auth request 与 answer 使用 Complete 位结束认证和授权阶段。成功时，PAA 还给出 Session-Lifetime；密钥型 EAP 则带有 Key-Id 与 AUTH。
但 PAA 与 Enforcement Point 可以是不同节点。EP 才在接入设备流量上实施逐包过滤。RFC 5191 把 PAA–EP 协议和 access-control filter creation 列在 PANA 协议范围之外，并要求这条投影通道具备认证、完整性和防重放保护。
要求通道安全，不等于证明策略已经送达，更不等于证明规则已经安装。运营证据必须列出目标 EP、策略版本、PaC 与接口绑定、投影事务、每个 EP 的确认、实际规则指纹和读取时间。
一个 PAA 给四个 EP 下发授权时，“三台已安装、一台未知”是准确状态。“PANA 成功”无法替代它。尤其在入口、出口或多路径分别经过不同 EP 时，部分收敛可能让同一客户端只在某些方向可用。
成功后还可能要换地址
RFC 5191 允许 PaC 在认证与授权成功后重新配置 IP 地址。PAA 通过 IP Reconfiguration 位表明：执行 PANA 时使用的地址，未必是穿过 EP 交换普通数据的可用地址。具体重配机制不在文档范围内。
因此最终控制消息并不是 DHCP、邻居发现、路由与过滤状态的共同回执。应记录认证前地址、接口、重配指令、新地址与租约来源、邻居状态、路由、EP 规则更新和第一份数据包证据。
若数据库只保留“当前 IP”，旧地址会从历史中消失，PANA 日志和数据面 capture 便像属于两个不同客户端。若 EP 仍绑定旧 tuple，则面板可能显示授权成功，而新地址仍被阻断。
地址变化不是杂音。它是从控制接入过渡到可用服务的一段必须保留的因果链。
发现地址不是发现权威
RFC 5192 定义 DHCP 选项，用于告知 PAA 地址；RFC 6345 又提供 PANA Relay Element。它们帮助客户端找到消息应该发往哪里，却没有把发现结果自动升级为已经认证的权威。
应保留 DHCP server、选项内容、租约、接口、relay 与候选 PAA，然后用后续 PANA/EAP 证据建立信任。伪造或错误的发现、PAA 不可达、认证拒绝、授权拒绝和 EP 未安装，都可能在终端上表现为“无法上网”，但控制者完全不同。
发现层只能声明候选目的地。认证层说明对端与主体。授权层决定许可。执行层改变包过滤。观测层才说明服务是否发生。
Ping 只证明 PANA peer 活着
进入 access phase 后，双方可以使用带 Ping 位的 PANA Notification request/answer 测试 liveness。对近期请求返回有效 answer，是 PANA peer 存活的证据。
这项测试没有读取独立 EP 的过滤表，没有验证新地址的路由，没有检查数据 SA，也没有访问远端应用。PAA 可以正常回答，而 EP 已经丢失规则；控制路径可以畅通，而数据路径仍在拥塞或被丢弃。
RFC 5191 还提醒，周期性使用这类 keepalive 需要谨慎，因为它可能制造拥塞与误报。准确表述应是“PAA 在 T 时刻回应了受保护的 PANA ping”，而不是“用户业务健康”。
监测项必须写出 probe 的真正目标。最便宜的 probe 不应因为方便，就取得最昂贵路径的证明权。
Session lifetime 不是可用性承诺
PANA 会话寿命受当前授权寿命约束，重新认证可以在到期前延长它。PANA SA 与会话同寿命，终止后删除。
这个计时器管理许可与控制状态，不保证过滤规则、新地址、路由、数据加密或应用在整个区间内持续有效。下层断开提示可以帮助更早发现问题，但 RFC 指出其可用性和可靠性依赖拓扑，应被视为 hint 并在需要时以 PANA ping 核验 peer。
运营记录应分别保存授权寿命、PANA 会话寿命、控制密钥寿命、地址租约、EP 规则期限、数据 SA 期限与服务观测窗口。它们发生偏差时，偏差正是诊断依据。
把一个小时的 Session-Lifetime 写成“一小时服务正常”，是把控制许可伪造成从未测量的 SLA。
终止消息也要跨越执行边界
PaC 或 PAA 可以提前终止会话。框架预期它删除 PANA 状态、停止 accounting，并移除 EP 上按客户端安装的状态。若 PAA 与 EP 分离，经过 AUTH 保护的终止消息仍是一条控制命令，而不是每台 EP 删除后的读回。
残留 allow rule 会扩大访问，残留 deny rule 会阻断下一次合法连接。两者都需要目标 EP 列表、删除事务、确认与事后查询。仅从 PAA 数据库看到会话消失，不能证明所有投影都已消失。
同样，超时与 liveness failure 的关闭原因也要和执行面实际清理分开保存。原因说明为什么应该结束，执行证据说明是否真的结束。
一份不越权的接入回执
完整记录从 PaC、接口、PAA 发现来源和请求服务开始。每条 PANA 消息保留 Session ID、序列、重传和验证。EAP 结果作为认证证据，授权结果作为独立决定。
最终阶段保存 Result-Code、Complete、Key-Id、AUTH 与 lifetime。需要换地址时，旧地址与新地址同时进入时间线。之后连接 PAA–EP 投影、每个 EP 的规则读回、独立数据 SA，以及包 capture、远端 receipt 和应用 outcome。
每一层都可能为绿，而下一层仍未知。这不是协议复杂度造成的麻烦，而是现实本来就由不同控制者组成。Heng Lu 的现实层方法要求我们拒绝用符号替代执行：受保护的声明仍然只是它所声明的那件事。
PANA AUTH 是强证据。正因为它强，才更不能让它替没有发生的逐包保护和交付作证。
来源
会员简报
档案背景详情
使用相应会员等级登录，即可解锁完整简报与来源注释。
仅限 Strategic Circle
Strategic Circle
所有读者均可浏览。加入并登录后可解锁档案简报。
加入 Strategic Circle仅限 Leadership Alliance
Leadership Alliance
符合条件的 IP 资产所有者和管理层可登录查看 Leadership Alliance 简报。
加入 Leadership Alliance