跳到主要内容

3.1 The IKE Header (IKE 首部)

3.1 The IKE Header (IKE 首部)​

IKE 消息使用 UDP 端口 500 和/或 4500, 每个 UDP 数据报承载一条 IKE 消息. 从分组起始到 UDP 首部为止的信息大体被忽略, 但会取出 IP 地址与 UDP 端口并反转后用于回程分组. 经 UDP 端口 500 发送时, IKE 消息紧跟在 UDP 首部之后. 经 UDP 端口 4500 发送时, IKE 消息前附加四个字节的零. 这四字节零不是 IKE 消息的一部分, 也不计入 IKE 所定义的任何长度字段或校验和. 每条 IKE 消息以 IKE 首部开始, 本文档中记为 HDR. 首部之后是一条或多条 IKE 载荷, 由前一条载荷中的 Next Payload 字段标识. 通过 IKE 首部中的 Next Payload 字段, 以及随后各 IKE 载荷自身的 Next Payload 字段, 按载荷在消息中出现的顺序进行识别, 直到 Next Payload 为零表示其后不再有载荷. 若遇到类型为 "Encrypted" 的载荷, 则对该载荷解密并将其内容按附加载荷解析. Encrypted 载荷必须是分组中的最后一条载荷, 且 Encrypted 载荷内部不得再包含另一条 Encrypted 载荷.

首部中的 responder SPI 标识一条 IKE 安全关联 (Security Association, SA) 实例. 因此, 单个 IKE 实例可以与多个对等方复用不同的会话, 包括对同一对等方的多条会话.

所有表示整数的多字节字段均按大端序 (big endian, 亦称 "最高有效字节在前" 或网络字节序) 排布.

IKE 首部的格式见图 4.

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       IKE SA Initiator's SPI                  |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       IKE SA Responder's SPI                  |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Next Payload | MjVer | MnVer | Exchange Type |     Flags     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Message ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Length                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 4: IKE Header Format

  • Initiator's SPI (8 字节) - 由发起方选取, 用于标识唯一的 IKE 安全关联. 该值绝对不能为零.

  • Responder's SPI (8 字节) - 由响应方选取, 用于标识唯一的 IKE 安全关联. 在 IKE 初始交换 (含带 cookie 的重传) 的第一条消息中, 该值必须为零.

  • Next Payload (1 字节) - 指明紧接在首部之后的载荷类型. 各载荷的格式与取值见下文.

  • Major Version (4 比特) - 指明所用 IKE 协议的主版本. 基于本版本 IKE 的实现必须将主版本设为 2. 基于 IKE 与 ISAKMP 先前版本的实现必须将主版本设为 1. 基于本文档版本 (版本 2) 的 IKE 实现必须拒收或忽略主版本号大于 2 的消息, 并按第 2.5 节所述以 INVALID_MAJOR_VERSION 通知回应.

  • Minor Version (4 比特) - 指明所用 IKE 协议的次版本. 基于本版本 IKE 的实现必须将次版本设为 0. 它们必须忽略所收消息中的次版本号.

  • Exchange Type (1 字节) - 指明所用交换类型, 从而约束交换中各消息可携带的载荷. 下表取值仅截至 RFC 4306 发布时有效. 此后可能已有新增, 或在本文档发布后还会继续增加. 读者应查阅 [IKEV2IANA] 获取最新取值.

Exchange TypeValue
IKE_SA_INIT34
IKE_AUTH35
CREATE_CHILD_SA36
INFORMATIONAL37
  • Flags (1 字节) - 指明为消息设置的特定选项. 某选项是否出现由 flags 字段中对应比特是否为 1 表示. 各比特如下:
        +-+-+-+-+-+-+-+-+
        |X|X|R|V|I|X|X|X|
        +-+-+-+-+-+-+-+-+

下文所述 "置位" 指值为 1, "清除" 指值为 0. X 比特在发送时必须清零, 接收时必须忽略.

  • R (Response) - 表示本消息是对具有相同 Message ID 的消息的响应. 该比特在所有请求消息中必须清除, 在所有响应消息中必须置位. IKE 端点不得对标记为响应的消息再生成响应 (第 2.21.2 节有一处例外).

  • V (Version) - 表示发送方能够使用比主版本字段所指更高的协议主版本. IKEv2 实现发送时必须清除该比特, 收到时必须忽略.

  • I (Initiator) - 在由 IKE SA 的原始发起方发送的消息中必须置位, 在由原始响应方发送的消息中必须清除. 接收方用它判断 SPI 的八个字节中哪一段由本端生成. 该比特会随最近一次 IKE SA 重密钥由谁发起而变化.

  • Message ID (4 字节, 无符号整数) - 用于控制丢包重传以及请求与响应的配对. 它对协议安全至关重要, 用于防止消息重放攻击. 见第 2.1 与 2.2 节.

  • Length (4 字节, 无符号整数) - 整条消息 (首部 + 载荷) 的长度, 以字节计.

最后于 更新