IPsec/IKEv2、WireGuard 与网络 AAA（RADIUS/Diameter）

• IKEv2 两阶段协商流程（IKE_SA_INIT + IKE_AUTH）
• 四消息交换的职责划分
• CHILD_SA 与 IKE_SA 的关系

IKEv2 协商分为两个阶段。第一阶段 IKE_SA_INIT 用两条消息（IKE_SA_INIT 请求/响应）完成 DH 密钥交换、协商加密/完整性/PRF 算法，并生成 SKEYSEED 及后续派生密钥，从而建立加密的 IKE_SA。第二阶段 IKE_AUTH 也用两条消息（请求/响应），在已加密的 IKE_SA 中完成身份认证（证书或 EAP）、交换 SA 负载，并同时创建第一个 CHILD_SA（即用于 ESP 的 IPsec SA）。也就是说，四消息完成 IKE_SA 建立的同时也建立了首条 CHILD_SA。后续如需更多数据流，可用 CREATE_CHILD_SA 或 IKE_AUTH 中携带的附加 SA 提议创建新的 CHILD_SA。

IKE_SA_INIT 阶段无需认证即可完成密钥交换，因为 DH 交换本身不依赖身份；IKE_AUTH 阶段在受保护通道内认证身份，避免身份泄露并保证密钥绑定到认证实体。CHILD_SA 才是真正承载流量加密的 SA，IKE_SA 只是控制平面。

• 四消息架构（INIT 2 条 + AUTH 2 条）
• IKE_SA_INIT 的 DH 与算法协商
• IKE_AUTH 的认证与 CHILD_SA 创建合一

IKEv2 将第一阶段缩减为一次双消息交换（IKE_SA_INIT），用于交换 SA 提议、DH 共享值、随机数（nonce），并派生密钥。第二阶段的 IKE_AUTH 双消息在受保护通道内完成认证，且把第一个 CHILD_SA 的创建合并进同一交换，从而"四消息 + 一次握手"即可同时建立 IKE_SA 和承载流量的 ESP SA。工程语义上，这减少了往返次数、简化状态机，并消除了 IKEv1 中"主模式/野蛮模式"的复杂性，同时把创建额外子 SA 的职责统一交给 CREATE_CHILD_SA。

将 CHILD_SA 创建合并进 IKE_AUTH 使常见场景只需一次往返即可开始加密数据，显著降低建连连时延，这也是 IKEv2 统一 AH/ESP 与多隧道场景的基础。

• CREATE_CHILD_SA 的双重用途
• 子 SA 的 rekey（量受限时更新密钥）
• PFS 选项（新 DH 交换）

CREATE_CHILD_SA 在 IKEv2 中承担两个职责：一是当需创建新 CHILD_SA 时，通过该交换协商新的 SA 参数并建立子 SA；二是对现有 CHILD_SA 或 IKE_SA 进行 rekey，即用新的密钥材料替换到期或即将到期的 SA。它可在需要时携带新的 Diffie-Hellman 交换以提供完美前向保密（PFS）。工程语义上，它把"新增流量通道"和"密钥轮换"统一为一种可重用的交换机制，使隧道生命周期管理（创建、更新、删除）清晰且可扩展。

通过 CREATE_CHILD_SA 实现 rekey，可避免长期使用同一密钥带来的泄露风险，并支持按需启用 PFS，从而在安全性与性能之间灵活权衡。

• IKEv1 的 NAT-T 扩展地位
• IKEv2 对 NAT-T 的强制支持
• NAT 检测与 UDP 封装

IKEv1 中 NAT-Traversal 是后续通过 RFC 3948 等附加的扩展，需要额外协商 NAT-* 通知并实现 UDP 封装，不同厂商支持程度不一，互操作困难。IKEv2 则把 NAT-T 检测（NAT_DETECTION_SOURCE_IP、NAT_DETECTION_DESTINATION_IP 等通知）和 UDP 封装（UDP 4500）内建为协议强制功能，任何实现都必须支持。工程语义上，IKEv2 将 NAT 穿越作为第一等公民，简化了远程接入和站点间穿越 NAT 的部署，减少了对厂商私有扩展的依赖。

强制 NAT-T 支持使 v2 在互联网特别是运营商级 NAT 环境下更可靠，是 v2 相比 v1 的重要工程改进之一。

• 内核态 vs 用户态数据路径
• 上下文切换与内存拷贝开销
• boringtun 的跨平台与开发便利性

内核态 WireGuard 模块直接在协议栈内处理数据包，避免用户态与内核态之间的上下文切换和多次内存拷贝，吞吐与延迟表现更优，CPU 利用率更低，适合高吞吐网关场景。用户态实现 boringtun（Rust 编写）通过 TUN 设备与内核交互，每次数据包都要在用户态与内核态之间往返，性能有所下降，但跨平台能力强、便于快速迭代和维护，且内存安全优势明显。工程取舍上，生产高负载场景优先内核模块，而需要跨平台、可移植或功能扩展时选 boringtun。

数据路径的位置（内核态 vs 用户态）决定了性能上限，TUN 往返是用户态实现的主要开销来源；两者本质是"性能"与"可移植性/可维护性"的权衡。

• cookie 机制的触发条件
• cookie 的 MAC 计算
• 防伪造与防放大攻击

WireGuard 的 cookie 机制用于缓解针对未建立会话的新发的 DoS/反射攻击。当服务器一段时间内未收到来自某 IP 的合法响应（或负载过高）时，会进入受限模式，要求后续首个消息必须携带 cookie。cookie 由服务器用一组密钥（server key）对客户端的源 IP 计算 HMAC 生成，客户端收到 cookie 后需在下一条消息中携带该 cookie 及其 MAC，以证明其真实性。这样攻击者无法伪造 cookie MAC，从而无法触发服务器为其分配大量计算资源，也防止了源地址伪造的流量放大。

cookie 本质是"工作证明"——要求客户端证明自己确实收到了服务器的 cookie，从而阻断伪造源 IP 的 DoS 注入，同时保持性能（正常流量在非受限模式无需 cookie）。

• RADIUS attribute 的 Type-Length-Value 结构
• 关键标准 attribute 含义
• 长度限制（255 字节）

RADIUS 报文由 20 字节头部（Code、Identifier、Length、Authenticator）后跟若干 attributes 组成。每个 attribute 是 TLV 格式：Type 占 1 字节标识属性类型（如 1=User-Name、2=User-Password、4=NAS-IP-Address、6=Service-Type、8=Framed-IP-Address），Length 占 1 字节表示整个 attribute 长度（含 Type 和 Length 字段），Value 占剩余字节。User-Name 标识用户名，User-Password 存放加密后的密码（用 MD5 与 shared secret 加密），NAS-IP-Address 标识发送请求的 NAS 设备地址。TLV 结构使扩展属性轻而易举，标准定义了 40 多个基础 attribute 及大量厂商专有（VSA）attribute。

TLV 的可扩展性让 RADIUS 能承载丰富会话与计费信息，并支持厂商自定义字段，是其在 AAA 领域广泛应用的基础。

• TCP 传输保证可靠性与控制
• Start/Continue/Reply 报文职责
• 与 RADIUS UDP 的差异

TACACS+ 使用 TCP（默认端口 49），相比 RADIUS 的 UDP，TCP 提供可靠有序传输、流量控制和连接管理，适合资源受限的设备管理场景。TACACS+ 的报文类型中，Start 由客户端发起认证/授权请求并携带初始参数；Continue 用于在多轮交互（如密码提示、挑战）中继续请求；Reply 由服务器返回结果（成功/失败/继续）。这种"一问一答"的交互模型适合需要逐步提示密码、OTP 等交互式认证，也便于逐命令授权。

TCP 传输使 TACACS+ 能可靠承载多轮交互且避免 UDP 的丢包与重传复杂性，其 Start/Continue/Reply 结构天然支持交互式认证与命令级授权。

• privilege level 0-15 的划分
• 命令级授权机制
• 基于 TACACS+ 的逐命令决策

在 TACACS+ 中，privilege level 从 0 到 15 表示用户权限等级，越高级别能执行的命令越多（如 level 0 只有基础命令，level 15 拥有全部特权）。TACACS+ 的授权机制支持"逐命令授权"：当管理员在设备上输入命令时，设备可将该命令发给 TACACS+ 服务器，由服务器根据用户名、权限级别和命令内容决定允许或拒绝，实现命令级颗粒度控制。这在审计和多管理员场景下尤为重要，可精细限定每个管理员能执行哪些命令。

privilege level 提供了本地基线，TACACS+ 命令级授权则让服务器能按"每个命令"动态决策，两者结合实现细粒度、可审计的权限管理。

• ESP 报文格式
• SPI 与 SA 查找
• 序列号与防重放、ICV 完整性

ESP 报文由头部、载荷、尾部组成。SPI（Security Parameters Index）标识接收方应使用哪个 SA 来解密和验证数据，接收方通过 SPI + 目的 IP 查找 SA；Sequence Number 是单调递增的计数器，用于抗重放（配合滑动窗口）；IV 是加密所需的初始向量（如 AES-GCM 中的 nonce）；Payload 是加密后的数据；Trailer 包含 Padding（用于对齐块大小）、Pad Length（填充长度）、Next Header（指示载荷原始协议类型，如 TCP/UDP）；ICV（Integrity Check Value）用于完整性校验。理解这些字段是抓包分析 IPsec 和排查问题的基础。

SPI 让无状态地定位 SA，序列号实现抗重放，IV 保证加密随机性，ICV 保证完整性，各字段协同完成 ESP 的机密性、完整性与防重放。

• 各密码学原语的角色
• 现代密码套件选择
• 密钥派生流程

WireGuard 采用一套现代且经过仔细选择的密码学栈：Curve25519 用于 ECDH 密钥交换，提供前向保密并生成共享密钥；ChaCha20-Poly1305 作为 AEAD 加密，同时提供机密性和完整性；BLAKE2s 作为哈希函数，用于各种哈希与密钥派生；HKDF 用于从 ECDH 共享密钥派生出加/解密密钥和认证密钥。整套栈无专利、实现简单、性能优秀且易于正确实现，是 WireGuard 简洁设计的核心。密钥管理遵循 Noise Protocol，通过多种 HKDF 链生成会话密钥。

每个原语都承担明确职责（交换、加密认证、哈希、派生），且均选用性能好、难出错的现代算法，这是 WireGuard 安全与简洁并重的关键。

• 定时重新握手机制
• PFS 与密钥轮换
• 性能与安全权衡

WireGuard 默认每两分钟进行一次重新握手（rekey），每次重握手都会执行新的 Curve25519 ECDH 交换，从而生成新的会话密钥，确保前向安全（即使某个会话密钥泄露，也无法解密历史流量）。频繁轮换使单个密钥暴露窗口极小，但也会带来额外的 CPU 开销和握手消息。工程权衡在于：重握手间隔足够短以保证 PFS 和密钥新鲜度，又不过短以免造成不必要的开销；同时通过静态公钥认证保证握手不被中间人伪造。

定时重握手实际上是"自动 PFS 再协商"，让密钥生命周期短于攻击窗口，这是 WireGuard 无需人工管理密钥轮换的工程优势。

• Notification 消息与 error type
• INTERNAL_ADDRESS_EXPIRY（配置载荷）
• MOBIKE 移动性扩展

IKEv2 的 Notification 消息用于在协商中传递状态或错误信息，通过 Notify 载荷携带一个 16 位的通知类型（Notify Message Type），其中一部分是错误类型（如 INVALID_KE_PAYLOAD、AUTHENTICATION_FAILED），用于报告协商失败；另一部分是状态通知（如 SA_UP、MOBIKE_SUPPORTED）。IKEv2 的配置载荷（Configuration Payload）通过 INTERNAL_IP4_ADDRESS / INTERNAL_IP6_ADDRESS 等属性（如 DNS、地址租期 INTERNAL_ADDRESS_EXPIRY）向客户端分配内网 IP、DNS 等，是远程接入 VPN 分配虚拟地址的基础。MOBIKE（RFC 4555）扩展通过 IKE_SA 的 address update 支持移动设备在 IP 地址变化时保持隧道不断，是移动 VPN 的关键扩展。

Notification 的 error type 让协商失败可被诊断；配置载荷实现远程地址分配；MOBIKE 解决移动场景 IP 变化问题，三者共同支撑 IKEv2 的远程接入与移动能力。

• EAP 与 IKEv2 的集成
• 多种认证方法（EAP-TLS、EAP-TTLS、EAP-MSCHAPv2）
• 与后端 RADIUS 协同

IKEv2 EAP 扩展允许在 IKE_AUTH 阶段使用 EAP 协议进行认证，从而支持多种认证方法（EAP-TLS 证书认证、EAP-TTLS、EAP-MSCHAPv2、EAP-PEAP 等），并可与后端的 RADIUS 服务器协同完成用户名/密码或证书认证。工程价值在于：它把客户端认证从"基于 IKE 层证书"扩展到"基于任意 EAP 方法"，使企业能复用现有的认证基础设施（如 RADIUS、LDAP、MFA），实现从设备证书到用户名密码的灵活认证，并支持多因素认证，是远程接入 VPN 大规模部署的关键。

EAP 扩展解耦了认证方法与传输层，使 IKEv2 能复用成熟 EAP 生态，显著提升远程接入 VPN 的认证灵活性与企业兼容性。

• ESP 提供加密 + 完整性
• AH 只提供完整性（无加密）
• 覆盖范围与 NAT 兼容性

ESP 提供机密性（通过加密）和完整性（通过 ICV），可同时加密和认证载荷，且支持认证但不加密（ESP-null）模式。AH 只提供完整性（通过校验和 ICV）和认证，不提供加密，其完整性覆盖范围包括外层 IP 头部分字段（不可变字段），因此会因 NAT 修改 IP 地址而失效。ESP 的完整性通常不覆盖外层 IP 头，因此更兼容 NAT。工程上，ESP 是数学上更完整的方案并广泛使用，AH 由于无加密且 NAT 不兼容，实际部署较少。

两者区别核心是"加密 + 完整性"（ESP）vs"仅完整性并覆盖外层头"（AH）；ESP 因兼顾机密性与 NAT 兼容性成为事实标准。

• transport mode 保留内层 IP 头
• tunnel mode 新增外层 IP 头
• 适用场景

传输模式（transport mode）保留原始 IP 头，只加密载荷，通常用于主机到主机（端到端）保护，如两台主机之间的直接 IPSec，开销小、保持原 IP 头不变。隧道模式（tunnel mode）新增一个外层 IP 头，将整个原始 IP 包封装加密，用于网关到网关（站点到站点）或远程访问场景，如 VPN 网关间。工程取舍上，运输模式更高效但只适合直接通信，隧道模式虽增加开销但能隐藏内网拓扑、支持任意端点组合，是 VPN 网关的默认选择。

选择依据是数据流是端到端（transport）还是经网关中转（tunnel），tunnel 模式的新外层头带来封装与拓扑隐藏能力。

• AH 完整性覆盖外层 IP 头
• 抗 IP 欺骗
• NAT 兼容性代价

AH 的完整性校验覆盖外层 IP 头中不可变字段（如源/目的地址、TTL 除外），因此能检测 IP 地址被篡改，提供更强的抗 IP 欺骗能力——任何在传输途中修改 IP 头的行为都会被 AH 校验和拒绝。ESP 的完整性（ICV）默认不覆盖外层 IP 头，因此不强抗 IP 欺骗。工程价值上，AH 的抗欺骗能力以牺牲 NAT 兼容性为代价（NAT 会改 IP 破坏校验），而 ESP 更适合穿越 NAT 的场景。实际中多数场景用 ESP + 其它层防护，AH 因 NAT 兼容性问题较少部署。

"覆盖外层 IP 头"是 AH 抗欺骗的关键，但也是其 NAT 不兼容的根源，工程上需在抗欺骗与 NAT 兼容间取舍。

• 序列号与滑动窗口
• 抗重放原理
• RFC 6479 的大窗口扩展

ESP 使用单调递增的序列号配合接收方的滑动窗口实现抗重放。接收方维护一个窗口（标准为 64 包），只接受序列号在窗口内且未重复的包；序列号小于窗口下界的包被丢弃，窗口内的重复包也被丢弃。窗口随合法包到达向前滑动。RFC 6479 将窗口从 64 扩展到更大（如 8192 或更高），通过位图/计数器优化实现高吞吐下的抗重放，适用于高速链路。抗重放机制防止攻击者重放已捕获的合法加密包。

滑动窗口在不要求严格有序接收的前提下检测并丢弃重放包，是 ESP 抗重放的核心；RFC 6479 用更大窗口兼顾高带宽与安全性。

• Noise IKpsk2 握手模式
• 1-RTT 数据已开始
• 静态预共享 key（PSK）的作用

WireGuard 使用 Noise Protocol 的 IKpsk2 握手模式，其中"IK"表示发起方在第一条消息中即发送静态公钥（identity），"psk2"表示在第 2 条消息中引入一个预共享密钥（PSK）。该握手共三条消息（发起方发送首条、响应方应答、发起方再发最终确认），约 1-RTT 后即可开始加密数据传输。静态预共享 key 在握手早期参与密钥派生，提供额外的认证层（在静态公钥之外），可抵御某些已知密钥攻击，并增强对量子攻击的预备防御。工程语义上，IKpsk2 让 WireGuard 快速建立安全隧道且无需额外证书基础设施。

1-RTT 使建连低时延，PSK 加强认证与抗量子储备，IKpsk2 是 WireGuard 简洁、快速且安全的关键设计。

• 密码学密钥路由模型
• 密钥与 IP 绑定
• 无需虚拟 IP 地址协商

WireGuard 采用"cryptography-key routing"模型：每个 peer 以其公钥作为唯一标识，配置中把对端公钥与允许的 IP 范围（AllowedIPs）直接对应，从而在同一个隧道内根据目标 IP 决定使用哪个对端公钥加密，并根据源公钥验证入站包。这种设计避免了传统 IPsec 中复杂的 SA/SPD 协商与虚拟地址分配，只要把公钥和 IP 绑定即可完成路由决策。工程简化体现在：配置极简、天然支持同一隧道内多个对端、无需集中管理 SA，且每个 peer 的预共享密钥可额外绑定。

用"公钥↔IP"映射代替传统 SA 数据库，使路由与加密一体，是 WireGuard 简洁性与易配置性的核心。

• 往返次数对比
• 状态维护复杂度
• 配置与协议栈复杂度

WireGuard 的 Noise IK 握手约 1-RTT 即可完成身份认证与密钥协商并开始加密通信，状态机极为简单，每个 peer 仅需维护静态公钥、私钥和少量会话状态，无需独立的控制协议处理复杂协商。IPsec IKEv2 需要在 IKE_SA_INIT 和 IKE_AUTH 两阶段交换（各 2 条消息，共 4 条）完成协商，需要维护 IKE_SA、CHILD_SA、DPD、重协商等多种状态，协议和实现复杂度显著更高。工程对比上，WireGuard 更轻量、更易配置排障，但可扩展的协商能力（算法协商、证书、EAP）不如 IKEv2 丰富。

WireGuard 以固定、精简的握手换取极低的复杂度与快速建连；IKEv2 以更复杂状态机换取更灵活的协商与认证能力。

• Diameter 对等架构与 TCP/SCTP 传输
• CER/CEA 能力交换
• 多消息/多会话支持

Diameter 采用 peer-to-peer 架构，节点以对等关系连接，通常基于 TCP 或 SCTP 传输，保证可靠性与有序性。建立连接后，节点通过 Capability-Exchange-Request（CER）和 Capability-Exchange-Answer（CEA）交换能力信息（支持的协议版本、应用、厂商 ID、安全级别等），双方据此确认可用的应用与功能，确保互操作。工程价值在于：能力交换使不同厂商节点在开放前明确兼容能力，peer-to-peer 架构支持多对多连接与故障转移，为 4G/5G 网络中 AAA、计费、策略等关键服务提供可靠基础。

CER/CEA 是 Diameter 连接建立的"握手"，确保双方应用能力一致；对等架构与可靠传输使其比 RADIUS 更适合承载关键电信信令。

• NASREQ 网络访问认证
• Credit-Control 在线计费
• 3GPP Cx/Dx/Sh 接口

NASREQ（Network Access Server Requirements）应用用于网络访问认证、授权与计费，是 RADIUS 在 Diameter 上的对应，用于 VPN、Wi-Fi 等接入认证。Diameter Credit-Control Application（RFC 4006）用于在线计费（OCS），支持实时余额检查、配额管理与信用控制，是电信预付费计费的核心。3GPP 的 Cx/Dx 接口用于 IMS 中 HSS 与 S-CSCF 之间的用户注册与订阅信息查询，Sh 接口用于 HSS 与应用服务器（AS）之间的用户数据交换。这些应用共同支撑了电信网络中的认证、计费与用户数据管理。

Diameter 以"应用"形式扩展不同业务（认证、计费、IMS 信令），是 4G/5G 网络核心控制平面（HSS、PCRF/PCF、OCS）的关键协议。

• DWR/DWA 消息
• 故障检测与传输层判断
• 对等连接健康管理

Diameter 使用 Device-Watchdog-Request（DWR）和 Device-Watchdog-Answer（DWA）消息作为看门狗机制，用于检测对等节点是否存活。当传输层（TCP/SCTP）空闲一段时间后，节点周期性地发送 DWR，若对端正常则回复 DWA；若在超时时间内未收到 DWA，则判定对端不可达，将其标记为故障并触发 failover（向备选对等节点重发请求）。工程价值在于 DWR/DWA 独立于业务消息，能在数据流量稀疏时仍保持连接健康监测，是实现高可用与故障转移的基础。

看门狗消息在传输层空闲时主动探测，确保对等连接常青，是 Diameter 可靠性与 failover 机制的关键组成部分。

• UDP 传输与重传机制
• 认证报文（Access-*）
• 计费报文（Accounting-*）

RADIUS 基于 UDP（认证与计费默认端口 1812/1813），因此在传输层不保证可靠，需由客户端自行实现重传与超时。主要报文类型：Access-Request 由 NAS 发送认证/授权请求，Access-Accept 表示认证成功并返回授权属性，Access-Reject 表示认证失败，此外还有 Access-Challenge 用于多轮交互。计费方面，Accounting-Request 由 NAS 上报开始/停止/更新计费信息，Accounting-Response 是服务器确认。工程语义上，UDP 使 RADIUS 轻量、无状态、易扩展，适合高并发认证场景，但可靠性依赖应用层重传。

RADIUS 的 UDP 轻量与报文类型划分（认证/授权/计费）使其成为最广泛部署的 AAA 协议，但无连接特性也遗留了重传与安全性问题。

• shared secret 的共享密钥
• request/response authenticator
• MD5 校验与密码加密

RADIUS 使用客户端与服务器之间预共享的 shared secret 进行验证。请求报文中的 Request Authenticator 是 16 字节随机数，用于防止重放并参与密码加密；服务器计算 response authenticator = MD5(Code + Identifier + Length + Request Authenticator + Attributes + Secret)，并校验之，从而验证请求来源。密码加密采用 MD5(Secret + Request Authenticator) 与密码异或。Response Authenticator 同样用 MD5 和 shared secret 计算，供客户端验证响应真实性。工程语义上，这套基于 MD5 的机制在无加密传输下提供基本验证，但 MD5 已知安全弱点，是 RADIUS 需要过渡到 RADIUS with TLS/Rekey 的原因。

shared secret 与 authenticator 使 RADIUS 在 UDP 上实现轻量验证与防重放，但基于 MD5 与现代安全标准相比已过时。

• 传输模式与隧道模式差异
• SPI 标识 SA
• 序列号抗重放

ESP 传输模式保留原始 IP 头，仅加密载荷，适用于端到端主机通信；隧道模式新增外层 IP 头，将整个原始包封装，适用于网关间的站点到站点或远程访问。无论哪种模式，ESP 都包含 SPI 字段用于标识接收方应使用的 SA，以及单调递增的序列号用于抗重放（配合滑动窗口）。两种模式下 SPI 和序列号都内置于 ESP 头部，接收方据此定位 SA 并验证防重放。两者差异主要在"保护对象"（负载 vs 完整 IP 包）导致的封装层次不同。

模式决定封装层次，SPI/序列号是两种模式共有的安全机制，前者定位 SA，后者防重放。

• IKE SA 生命周期
• 重协商（rekey）
• DPD 对端存活检测

IPsec 的密钥管理由 IKE 负责。IKE SA 有生命周期（lifetime），到期后需要重协商（rekey）以更新密钥，保证前向安全与密钥新鲜度；CHILD SA 同样有生命周期并可独立重协商。DPD（Dead Peer Detection）通过发送 R-U-THERE 消息定期探测对端是否存活，若对端无响应则判定隧道失效并触发重协商或拆除，从而避免长时间的无响应废旧隧道。工程语义上，生命周期与重协商保证密钥不过期使用，DPD 保证隧道状态实时可信，二者共同构成 IPsec 密钥与隧道的高可用管理。

生命周期规定密钥使用时长，重协商自动更新密钥，DPD 检测对端失效，三者协同维护 IPsec 隧道的安全与可用性。

• TCP/SCTP 可靠传输
• AVP 32-bit 长度
• failover 与 peer 管理

Diameter 相比 RADIUS 的主要改进：传输层使用 TCP 或 SCTP 提供可靠、有序、面向连接的数据传输（RADIUS 用 UDP）；AVP 使用 32-bit 长度字段，可承载超过 255 字节的大数据（RADIUS attribute 长度仅 1 字节）；支持能力交换（CER/CEA）、watchdog 与 peer 管理，内置 failover 机制（对等节点不可达时自动切换到备选），并支持多跳路由与端到端信令。工程上，Diameter 更适合对可靠性、大数据量与故障转移要求高的电信网络（4G/5G 控制面）。

Diameter 从"UDP 轻量"升级为"TCP/SCTP 可靠 + 大 AVP + failover"，解决了 RADIUS 在可靠性、规模和故障恢复上的不足。

• AVP 头部字段
• AVPFlags 与 VendorID
• Data 长度与 32-bit 对齐

Diameter AVP 由头部和 Data 组成。AVPCode 标识 AVP 类型（如 1=User-Name、456=Host-IP-Address）；AVPFlags 是 1 字节标志位，含 V/P/M 位（V 表示有 VendorID，M 表示必需，P 表示受保护）；AVPLength 是 32-bit 长度字段，表示整个 AVP 长度（含头），支持大 AVP；VendorID 仅在 V 位设置时出现，标识厂商（用于厂商专有 AVP）；Data 承载实际数据值。工程语义上，AVP 的 32-bit 长度与 V 位支持厂商扩展和大数据，使 Diameter 能灵活承载多种信息，是其后 RADIUS 的重要扩展。

AVP 的 TLV-ish 结构（Code+Flags+Length+VendorID+Data）是 Diameter 数据承载的基础，32-bit 长度与 VendorID 提供了可扩展性。

• 802.1X 与 RADIUS 的 EAP 透传
• WPA2-Enterprise 认证流程
• VPN 集中 AAA

在 802.1X / WPA2-Enterprise 中，客户端通过 EAPOL（EAP over LAN）与认证器（交换机/AP）通信，认证器将 EAP 报文封装为 RADIUS Access-Request 转发给 RADIUS 服务器，RADIUS 服务器完成 EAP 认证（如 EAP-TLS、PEAP）后返回 Access-Accept，认证器据此放行端口。这样 RADIUS 作为后端 AAA 中枢，将 EAP 认证与后端身份库（LDAP、证书）协同起来。在 VPN 集中场景，RADIUS 同样作为认证后端，为远程访问 VPN 提供集中认证、授权与计费。工程价值在于统一的 AAA 中枢，支持多种接入方式共享同一认证策略。

RADIUS 以"EAP 透传 + 后端认证"的方式统一了有线（802.1X）、无线（WPA2-Enterprise）与 VPN 的认证，实现集中式 AAA。

• RADIUS 到 Diameter 的演进
• HSS/PCRF 中的 Diameter 角色
• 迁移与互操作

在 2G/3G 时代，AAA 多依赖 RADIUS（如 WAP、WLAN 接入）。进入 4G 后，核心网控制面（HSS 用户数据、PCRF 策略与计费）采用 Diameter 作为信令协议，因为 Diameter 的可靠传输、大 AVP 与 failover 满足电信级要求。过渡工程中，RADIUS 与 Diameter 常需共存与互操作：企业/接入侧仍用 RADIUS，通过网关（如 RADIUS-to-Diameter 转换器）接入 Diameter 核心网；5G 中部分 RAT 又引入基于 HTTP/2 的 N5/N7 等接口，但 Diameter 仍在存量网络中广泛存在。工程上需要处理协议转换、属性映射与计费一致性。

从 RADIUS 到 Diameter 的演进是"轻量 UDP 到电信级可靠信令"的升级，5G 又引入 HTTP 接口，多种协议并存的过渡是工程现实。

• TACACS+ 三功能分离
• RADIUS 认证与授权混合
• 密码加密范围差异

TACACS+ 将认证、授权、计费分为三个独立流程，可分别配置使用不同服务器，且报文中认证与授权分离，密码采用加密（非明文）传输，授权可逐命令进行。RADIUS 将认证和授权合并在一个 Access-Request/Accept 流程中，认证和授权属性一起返回，且通常只加密密码（User-Password），其他属性明文。工程取舍上，TACACS+ 更适合设备管理（如 Cisco 设备管理，需逐命令授权与详尽审计），RADIUS 更适合网络访问认证（如用户拨号、Wi-Fi 接入），因其轻量高效。三功能分离 vs 混合决定了各自的适用场景。

TACACS+ 的分离设计利于设备管理场景的细粒度授权与审计，RADIUS 的混合设计利于高并发接入认证的简单高效。

• 逐命令授权（per-command authorization）
• 命令记账（command accounting）
• 设备管理场景适配

TACACS+ 相比 RADIUS 在设备管理（如交换机/路由器管理）上的核心优势是支持逐命令授权与命令记账。逐命令授权允许设备将管理员输入的每条命令发送给 TACACS+ 服务器，由服务器根据命令、用户与权限决定是否允许执行，实现命令级权限控制；命令记账则记录每条命令的执行结果，形成完整审计日志。RADIUS 主要面向网络访问授权，不具备这种逐命令粒度。工程上，TACACS+ 更适合多管理员、需细粒度权限与完整审计的 NAS 设备管理场景。

命令级授权与记账使 TACACS+ 成为设备管理 AAA 的首选，而 RADIUS 更侧重访问控制，二者定位不同。

• TACACS+ 整包加密
• RADIUS 仅加密 User-Password
• 完整性校验差异

TACACS+ 使用 shared secret 与 MD5（或 MD5 变体）对整包负载进行加密，包括用户名、密码、命令等所有内容，且报文带完整性校验，因此通信中泄露的信息较少。RADIUS 只对 User-Password 属性用 MD5 加密，其余属性（用户名、计费数据等）以明文传输，因此存在信息泄露风险。工程边界上，TACACS+ 更适合对机密性要求高的设备管理场景，RADIUS 的轻量加密适合网络访问认证，但明文属性在不可信网络上可能泄露。两者都基于 MD5，均建议在可信网络或配合 TLS 使用。

加密范围（整包 vs 仅密码）是两者安全边界的核心差异，TACACS+ 更安全但更重，RADIUS 更轻但泄露更多。

• IPsec 网络层加密
• TLS 传输层/应用层加密
• 适用场景与差异

IPsec 工作在网络层（IP 层），对进程透明，能保护 IP 流量，适合站点到站点（网关到网关）或远程访问 VPN，因为所有进出站点的流量统一加密，无需修改应用。TLS 工作在传输层之上（通常保护 TCP 应用），需应用显式支持，适合端到端（应用客户端到服务器）保护，如 HTTPS、邮件、数据库连接。工程取舍上，IPsec 对所有应用透明、适合网关集中加密，但配置复杂；TLS 粒度细、适合应用级加密，但需逐应用集成。现实中站点到站点常用 IPsec，应用间通信用 TLS。

"网络层大而全 vs 应用层精准"的定位决定了 IPsec 适合站点到站点、TLS 适合端到端应用保护。