摘要

  • draft-ietf-radext-radiusdtls-bis-18 把 RadSec 健康状态限定在具体连接与相邻对端；RADIUS 代理会隐藏后续 realm、home server 与凭据后端的运行状态。
  • Status-Server、TLS/DTLS 状态和 keepalive 都是有价值的局部凭据，但 realm 路由、重传责任、授权决定、NAS 执行和用户结果必须另行取证。

把一条访问请求拆开，就能看出“正常”究竟少了什么。NAS 把带有用户 realm 的 Access-Request 交给 RadSec 代理。代理先作为服务器接收它，再作为客户端选择下一条路。后面可能还有另一个代理、某个 home server，以及按 realm 分开的凭据数据库。前一跳看不见这张拓扑图；它只能看到自己面对的代理是否回应。

因此，代理可以在三个层面同时呈现不同事实：连接层完全健康，realm 路由层发生故障，用户层没有得到服务。这不是悖论，而是不同现实层的并存。

修订版 18 的第 3.8 节明确写出这条边界。RadSec 实现判断连接存活时，既要使用 TCP、TLS 或 DTLS 所能提供的状态，也要使用 RFC 3539 的应用层 watchdog。只有网络栈认定连接不可用、D(TLS) 已无可用连接，或者 watchdog 将它标为 down，客户端才应把该连接判为故障。

判定单位是“连接”，不是笼统的“服务器”。同一客户端可能向一个代理开多条连接，其中一条落到失去状态的 DTLS 实例，另一条仍能工作。一条失败不得让所有连接一起下线。这个规则保护了未受影响的流量，也提醒运营者：一条成功连接同样不能替其他连接和后端背书。

Status-Server 的设计让范围更清楚。RFC 5997 要求代理或服务器不得转发这种请求。它只询问目标地址和端口上的那台对端。服务器也不会依据 User-Name 把 watchdog 路由到某个 realm，所以响应不能推导特定 realm 是否可达。

“不可转发”不是缺陷。它让 NAS 能区分相邻代理失效与代理之后的沉默。如果普通请求没有回答，而 Status-Server 有回答，至少可以排除一个过宽的结论：不能仅凭业务超时就说第一跳代理已经死亡。但它也只做到这里，无法指出下一跳链路、home server 或凭据库中哪一项出了问题。

草案要求 RadSec 客户端实现 Status-Server，服务器必须应答。RADIUS Identifier 只有 256 个可能值，因此文档建议每条连接为 watchdog 保留零号。TCP keepalive 和 DTLS heartbeat 可以更快触发连接故障通知；在应用层 watchdog 存在时，它们被称为基本冗余。无论速度多快，测到的仍是相邻连接。

若监控系统忽略范围，会产生两种方向相反的错误。

第一种是过早切换。某个 realm 后面的 home server 变慢，NAS 收不到回答，于是自动化把整个代理摘除。其他 realm 原本正常的流量被迁往备用站点，重新建连、队列升高，局部后端故障被放大成全局压力。RFC 3539 已指出，有代理存在时，客户端没有与 home server 的直接连接，不能从本地传输状态估计端到端重传与故障切换时机。

第二种是拒绝切换。因为代理持续回答 watchdog，系统反复把故障 realm 的请求送回同一条坏路。绿色状态是真实观测，却被赋予了它没有的权限。要决定 realm 级绕行，需要 realm 选择、路由规则、下游发送、home server 回答、凭据后端结果和 NAS 动作组成的另一条证据链。

草案对 Protocol-Error 的处理也遵循逐跳原则。它用于当前连接上不受支持或不可路由的包，客户端收到后停止在这条连接上重传原包，并可尝试别的路径。该错误不得被转发。它能说明这一跳如何处理了包，却不能预告更远的服务器会接受什么。

加密保护的管辖范围同样有限。TLS 或 DTLS 可认证相邻 RadSec 对端并保护这一段传输。但安全考虑章节明确指出，中间代理仍可能把包通过明文 RADIUS/UDP 发往后续节点。最初的客户端无法仅凭协议强制整条代理链都使用安全传输。如果业务要求全程保护，必须由组织控制每个中间节点的配置。第一段上的锁并不是全路径收据。

跨传输代理还会改变“谁负责重传”。RADIUS/TCP 与 RADIUS/TLS 借助可靠传输，在同一连接上不做 RADIUS 层重传；RADIUS/UDP 与 RADIUS/DTLS 则需要应用层重传。代理若从不可靠链路收包、再发往可靠链路，就必须吞掉上游重复包，不能继续转发。若从可靠链路收包、再发往不可靠链路，代理本身接管下游重传。

当上游连接关闭，或者客户端重用 Identifier 表示已经放弃旧请求，代理也必须终止对应的下游重传。于是一个 timeout 可能同时伴随多种状态：客户端已经放弃，代理仍保存计时器；代理连接在线，某个下游服务器过载；服务器已经处理，回答还没回来。一个“RADIUS 错误率”无法说明责任在哪一跳。

Accounting 场景展示了错误合并的成本。草案建议用固定的 Event-Timestamp 表示事件真正发生的时间，并规定重传时不得修改它。若不断更新 Acct-Delay-Time，同一事实会变成内容不同的新 RADIUS 包，常常还会获得新的 Identifier。TLS 到 UDP 的代理可能为每个新包分别启动下游重传，而慢服务器早已把第一份放入队列。

附录 A.2 的例子把一次记账事件扩成下游的 101、102、103 三个 ID。固定事件时间有助于识别重复，但它不是全局唯一事务号，更不保证业务只执行一次。审计记录仍要连接事件、包身份、hop、重传所有者、服务器决定与最终写入。

密码学验证失败也不能越权解释。附录 A.1 描述了 Identifier 超时后被复用的竞态：旧请求的迟到回答抵达时，客户端已经用同一 Identifier 等待新请求，Response Authenticator 因而校验失败。此时应丢弃该回答，但保持连接。单包失败、连接失败与对端恶意是三项不同结论。

这份文档仍是工作组 Internet-Draft。修订版 18 于 2026 年 9 月 30 日提交，拟议状态为 Proposed Standard，2027 年 4 月 3 日到期，尚无 RFC 编号。它只有在获批并发布后，才会真正取代实验性的 RFC 6614 和 RFC 7360。现有材料没有证明任何具名网络的部署、互操作性、故障率或事故。

因此，可靠的运行表述应当很窄：“这个 RadSec 对端在这个时间通过这条连接作出了回应。”若要说服务可用，还需补上用户 realm、所选路由、下游对端或凭据后端、授权结果、NAS 执行和用户侧结果。共同协议负责协调相邻层；它不应让一个真实的绿色符号获得整条隐藏路径的象征性权力。

来源