跳到主要内容

2. IKE Protocol Details and Variations (IKE 协议细节与变体)

2. IKE Protocol Details and Variations (IKE 协议细节与变体)

IKE 通常在 UDP 端口 500 上监听与发送, 不过 IKE 消息也可能在 UDP 端口 4500 上接收, 其格式略有不同 (见 2.23 节). 由于 UDP 是数据报 (不可靠) 协议, IKE 在其定义中包含对传输错误的恢复, 包括丢包, 重放与伪造. IKE 的设计目标是: 只要 (1) 一系列重传分组中至少有一个在超时前到达目的端; 且 (2) 信道中伪造与重放的分组不至于耗尽任一端点的网络或 CPU 容量, 即可正常工作. 即便不满足上述最低性能要求, IKE 也应能干净地失败 (如同网络中断).

尽管 IKEv2 消息意图保持短小, 但其中包含的结构没有硬性上限 (尤其是数字证书), 且 IKEv2 本身没有拆分超大消息的机制. IP 定义了对超大 UDP 消息的分片机制, 但各实现在所支持的最大消息长度上并不一致. 此外, 使用 IP 分片会使实现暴露于拒绝服务 (DoS) 攻击 [DOSUDPPROT]. 最后, 某些 NAT 与/或防火墙实现可能会阻止 IP 分片.

所有 IKEv2 实现必须能够发送, 接收并处理长度最多为 1280 字节的 IKE 消息, 且应该能够发送, 接收并处理长度最多为 3000 字节的消息. IKEv2 实现需要了解所支持的最大 UDP 消息长度, 若省略部分证书或密码套件提议可使消息低于该上限, 则可以这样做. 在可能的情况下使用 "Hash and URL" 格式而非在交换中包含证书, 可避免大多数问题. 但实现与配置须牢记, 若只有在 Child SA 建立之后才能进行 URL 查询, 则递归问题可能使该技术无法奏效.

在端口 4500 上发送的, 含 IKE 消息的所有分组的 UDP 载荷必须以四个零字节为前缀; 否则接收方将无法知道如何处理它们.

Contents