摘要

  • RADEXT 的 RadSec 工作组草案第18版修改了错误处理：客户端遇到 Response Authenticator 校验失败的响应，必须丢弃该包，但保留 (D)TLS 连接；没有匹配待处理请求的响应也必须丢弃而不断连。文件正在 IESG 审查，尚非 RFC。
  • 原因之一是 RADIUS 的一字节 Identifier 在超时后可被重用。旧请求的响应若晚于新请求抵达，客户端可能拿新请求的认证材料去核旧响应而失败。新规则只避免把这种可能的竞态升级为整条连接故障，并不放行坏响应。

判断一条 RadSec 链路是否可信，不能从一个迟到包的命运直接推导。设想客户端已对请求 A 超时，回收其 Identifier 并发出请求 B；服务器对 A 的响应在 B 已经排队时才到达。客户端按当前待处理请求校验，Response Authenticator 不匹配。包应被扔掉，但它为什么不匹配？答案可能是对端作恶，也可能只是旧响应撞上了新请求的编号。第18版专门处理后一个可造成误断连的路径。

新修订的第3.12节把“拒包”和“断连”拆开。Response Authenticator 校验失败时，RadSec 客户端必须保持连接开放，同时丢弃该响应；找不到任何待处理请求的响应也一样。对照第17版，前一种故障原本列在需关闭连接的项目中，后一种则容许实现自行选择是否关闭。新增附录 A.1 说明了超时、编号重用、旧响应抢在新请求处理之前返回的次序。变化是错误处置权限的收窄，不是宣布认证检查已经无关紧要。

较早的 RFC 6613 为对照提供了基线。它在 RADIUS/TCP 的畸形包规则中要求 Response Authenticator 失败时关闭 TCP，对没有匹配请求的响应则允许保留或关闭连接。Identifier 只有八位，在一条连接上可表示的在途编号最多 256 个。第18版指出，高负载下超时后很快复用编号，能够造成对旧响应的误判。代理链中客户端和服务器的计时器不同，也可能让服务器响应在客户端放弃等待后抵达。文件并未给出某家运营商发生事故的证据。

保留连接绝不等于接纳响应。新规则要求丢弃该包；若 Response Authenticator 已经失败，该废弃包的 Message-Authenticator 不必再另作校验。但这个顺序条件不能扩张为“Message-Authenticator 错了也不断连”。若匹配请求本身有效而 Message-Authenticator 校验失败，关闭连接的边界仍在。服务器认定客户端不可接受时，也必须立即终止 (D)TLS；RADIUS/TLS 还要关闭 TCP。把这些情况混写成一种“认证失败”，会同时损伤可用性和安全性。

可操作的验收记录，应把请求是否仍待处理、编号是否复用、进入了哪一步校验、响应是否真正丢弃、连接随后是否继续处理有效请求分别记清。草案还建议记录触发规则的包代码和编号，并在不断连时限制被忽略包的日志速率，免得诊断本身耗尽资源。这份分层清单是本文的治理建议，不是 IETF 已规定的新遥测字段，也不能从一次复现实验推出所有失败都无害。

Datatracker 将第18版列为 RADEXT 工作组的活跃互联网草案，状态是 IESG Evaluation::AD Followup，拟议级别为 Proposed Standard。其“若获批准则废止 RFC 6614 与 RFC 7360”尚属条件性描述。新闻的重点是：某些包足以被判无效，却不足以让整条受保护连接背负同一个判决。

来源