跳到主要内容

2.5. 版本号与前向兼容性

2.5. 版本号与前向兼容性​

本文档描述了 IKE 的 2.0 版，即主版本号为 2，次版本号为 0。本文档是 [IKEV2] 的替代品。很可能一些实现会希望同时支持 1.0 版和 2.0 版，并且在未来支持其他版本。

主版本号只应在数据包格式或所需操作发生如此剧烈的变化，以致于较旧版本的节点如果只是忽略其不理解的字段并按照较旧规范中规定的操作执行，就无法与较新版本的节点互操作时，才应递增。次版本号指示新的能力，具有较小次版本号的节点必须忽略它，但具有较大次版本号的节点可将其用于信息目的。例如，它可能指示处理新定义的 Notify 消息类型的能力。具有较大次版本号的节点只需注意到其通信对端无法理解该消息，因此不会发送它。

如果一个端点收到一条具有较高主版本号的消息，它必须丢弃该消息，并且应该发送一条类型为 INVALID_MAJOR_VERSION 的未认证 Notify 消息，其中包含其支持的最高（最接近的）版本号。如果一个端点支持主版本号 n 和主版本号 m，它必须支持 n 和 m 之间的所有版本。如果它收到一条具有其支持的主版本号的消息，它必须以该版本号响应。为了防止两个节点被欺骗而使用比它们双方都支持的最大主版本号更低的主版本号进行通信，IKE 有一个标志，指示该节点能够使用更高的主版本号进行通信。

因此，IKE 头中的主版本号指示消息的版本号，而不是发送方支持的最高版本号。如果发起者能够使用版本 n、n+1 和 n+2，而响应者能够使用版本 n 和 n+1，那么它们将协商使用 n+1，其中发起者将设置一个标志，指示其能够使用更高版本的能力。如果它们错误地（也许通过一个发送错误消息的活跃攻击者）协商到版本 n，那么双方都会注意到另一端可以支持更高的版本号，并且它们必须断开连接并使用版本 n+1 重新连接。

请注意，IKEv1 不遵循这些规则，因为在 v1 中没有办法表明你能够使用更高的版本号。因此，一个活跃的攻击者可以诱骗两个能够使用 v2 的节点去使用 v1。当一个能够使用 v2 的节点协商下降到 v1 时，它应该在其日志中记录这一事实。

另外，为了前向兼容，所有标记为 RESERVED 的字段必须由运行 2.0 版的实现设置为零，并且运行 2.0 版的实现必须忽略其内容（"发送时保守，接收时宽容" [IP]）。通过这种方式，未来版本的协议可以使用这些字段，而这种方式可以保证会被不理解它们的实现所忽略。类似地，未定义的载荷类型保留供将来使用；载荷类型未定义的版本的实现必须跳过这些载荷并忽略其内容。

IKEv2 在每个载荷头中增加了一个"critical"（关键）标志，以提供更多的前向兼容灵活性。如果关键标志被设置且载荷类型无法识别，则必须拒绝该消息，并且包含该载荷的 IKE 请求的响应必须包含一个 UNSUPPORTED_CRITICAL_PAYLOAD Notify 载荷，指示其中包含一个不支持的临界载荷。在该 Notify 载荷中，通知数据包含一字节的载荷类型。如果关键标志未被设置且载荷类型不受支持，则必须忽略该载荷。在 IKE 响应消息中发送的载荷不得设置关键标志。请注意，关键标志仅适用于载荷类型，而不适用于内容。如果载荷类型被识别，但载荷包含某些无法识别的内容（例如 SA 载荷中的未知转换，或 Notify 载荷中的未知 Notify 消息类型），则忽略关键标志。

尽管未来可能会添加新的载荷类型，并且它们可能与本文档中定义的字段交错出现，但实现应该按照第 1 节和第 2 节图中的顺序发送本文档中定义的载荷；实现不得将任何其他顺序的具有这些载荷的消息视为无效而拒绝。