2.5. Version Numbers and Forward Compatibility (版本号与前向兼容性)

2.5. Version Numbers and Forward Compatibility (版本号与前向兼容性)

本文档描述 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" (关键) 标志以增强前向兼容性. 若设置了 critical 标志且载荷类型无法识别, 必须拒绝该消息, 对包含该载荷的 IKE 请求的响应必须包含 Notify 载荷 UNSUPPORTED_CRITICAL_PAYLOAD, 表示包含了不支持的关键载荷. 该 Notify 的 Notification Data 含一字节的载荷类型. 若未设置 critical 标志且不支持该载荷类型, 必须忽略该载荷. IKE 响应消息中发送的载荷绝对不能设置 critical 标志. 注意 critical 标志仅适用于载荷类型, 不适用于内容. 若载荷类型可识别, 但载荷内含无法识别之物 (例如 SA 载荷中的未知变换, 或 Notify 载荷中的未知 Notify Message Type), 则忽略 critical 标志.

虽然将来可能新增载荷类型并可能与本文档定义的字段交错出现, 实现应该按第 1 与 2 节图中顺序发送本文档定义的载荷; 实现绝对不能仅因载荷顺序不同而将消息判为无效.