GB/T 36968-2018 信息安全技术 IPSec VPN技术规范

　　ICs 35 . 040 L 80

　　中 华 人 民 共 和 国 国 家 标 准

　　GB/T 36968—2018

　　信息安全技术 IPsecVPN技术规范

　　Informationsecuritytechnology—TechnicalspecificationforIPsecVPN

　　2018-12-28 发布 2019-07-01 实施

　　国家市场监督管理总局中国国家标准化管理委员会

　　发

　　布

　　GB/T 36968—2018

　　GB/T 36968—2018

　　前 言

　　本标准按照 GB/T 1 . 1—2009 给出的规则起草。

　　请注意本文件的某些内容可能涉及专利。 本文件的发布机构不承担识别这些专利的责任。

　　本标准由全国信息安全标准化技术委员会(SAC/TC 260)提出并归口 。

　　本标准起草单位：无锡江南信息安全工程技术中心、国家密码管理局商用密码检测中心、上海格尔软件股份有限公司、北京数字认证股份有限公司、山东得安信息技术有限公司、北京天融信网络安全技术有限公司、华为技术有限公司、深信服科技股份有限公司、深圳奥联信息安全技术有限公司、成都卫士通信息产业股份有限公司、北京三未信安科技发展有限公司。

　　本标准主要起草人：刘平、徐文耀、周国 良、郑强、李述胜、马洪富、罗鹏、李金国、王雨晨、林国强、但波、罗俊、许永欣。

　　GB/T 36968—2018

　　信息安全技术 IPsecVPN技术规范

　　1 范围

　　本标准规定了 IPSec VPN 的技术协议、产品要求和检测方法。

　　本标准适用于 IPSec VPN 产品的研制、检测、使用和管理。

　　2 规范性引用文件

　　下列文件对于本文件的应用是必不可少的。 凡是注 日期的引用文件，仅注 日期的版本适用于本文件 。凡是不注 日期的引用文件，其最新版本(包括所有的修改单)适用于本文件。

　　GB/T 20518 信息安全技术 公钥基础设施 数字证书格式

　　GB/T 25056 信息安全技术 证书认证系统密码及其相关安全技术规范

　　GB/T 32905 信息安全技术 SM3 密码杂凑算法

　　GB/T 32907 信息安全技术 SM4 分组密码算法

　　GB/T 32915 信息安全技术 二元序列随机性检测方法

　　GB/T 32918(所有部分) 信息安全技术 SM2 椭圆曲线公钥密码算法

　　GB/T 35276 信息安全技术 SM2 密码算法使用规范

　　RFC 2408 互联网安全联盟和密钥管理协议(Internet Security Association and Key Management

　　Protocol)

　　RFC 3947 密钥交换过程中 NAT穿越协商(Negotiation of NAT-Traversal in the IKE)

　　RFC 3948 IPSec ESP 包的 UDP 封装(UDP Encapsulation of IPsec ESP Packets)

　　3 术语和定义

　　下列术语和定义适用于本文件。

　　3.1

　　安全联盟 securityassociation

　　两个通信实体经协商建立起来的一种协定，它描述了实体如何利用安全服务来进行安全的通信。

　　注：安全联盟包括了执行各种网络安全服务所需要的所有信息，例如 IP 层服务(如头鉴别和载荷封装)、传输层和应用层服务或者协商通信的 自我保护。

　　3.2

　　互联网安全联盟和密钥管理协议 internetsecurityassociationandkeymanagementprotocol

　　一个在互联网环境中建立安全联盟和进行密钥管理的协议。 它定义了建立、协商、修改和删除安全联盟的过程和报文格式，以及交换密钥产生和鉴别数据的载荷格式。 这些格式为传输密钥和鉴别信息提供了一致的框架。

　　3.3

　　载荷 payload

　　ISAKMP 通信双方交换消息的数据格式，是构造 ISAKMP 消息的基本单位。

　　GB/T 36968—2018

　　3.4

　　Ipsec协议 Internetprotocolsecurity

　　一种开放标准的框架结构，通过使用加密的安全服务以确保在公开网络上进行保密而安全的通信，可以端至端的层面上提供数据完整性保护、数据源鉴别、载荷机密性和抗重放攻击等安全服务。

　　3.5

　　鉴别头 authenticationheader

　　IPSec 的一种协议，用于提供 IP 数据包的数据完整性、数据源鉴别以及抗重放攻击的功能，但不提

　　供数据机密性的功能。

　　3.6

　　封装安全载荷 encapsulatingsecuritypayload

　　IPSec 的一种协议，用于提供 IP 数据包的机密性、数据完整性以及对数据源鉴别以及抗重放攻击

　　的功能。

　　3.7

　　虚拟专用网 virtualprivatenetwork

　　使用密码技术在通信网络中构建安全通道的技术。

　　4 缩略语

　　下列缩略语适用于本文件。

　　AH：鉴别头(Authentication Header)

　　CBC：(密码分组的)密码分组链接(工作方式)(Cipher Block Chaining)

　　ESP：封装安全载荷(Encapsulating Security Payload)

　　HMAC：带密钥的杂凑运算(Keyed-Hash Message Authentication Code)

　　IPSec: IP 安全协议(Internet Protocol Security)

　　IPv4：互联网通信协议第四版(Internet Protocol version 4)

　　IPv6：互联网通信协议第六版(Internet Protocol version 6)

　　ISAKMP：互联网安全联盟和密钥管理协议(Internet Security Association and Key Management

　　Protocol)

　　IV：初始化向量(Initialization Vector)

　　MAC：消息认证码(Message Authentication Code)

　　NAT：网络地址转换(Network Adress Translation)

　　SA：安全联盟(Security Association)

　　UDP：用户数据报协议(User Datagram Protocol)

　　VPN：虚拟专用网(Virtual Private Network)

　　5 密码算法和密钥种类

　　5 . 1 密码算法

　　IPSec VPN应支持国家密码管理主管部门批准的非对称密码算法、对称密码算法、密码杂凑算法

　　和随机数生成算法。 各算法及使用要求如下：

　　— 非对称密码算法应当支持 SM2 椭圆曲线密码算法，用于实体鉴别、数字签名和数字信封等。 SM2 算法的使用要求见 GB/T 32918 。

　　— 对称密码算法应当支持 SM4 分组密码算法，用于密钥交换数据的加密保护和报文数据的加密

　　GB/T 36968—2018

　　保护。 算法的工作模式应当支持 CBC模式。 SM4 算法的使用要求见 GB/T 32907 。

　　— 密码杂凑算法应当支持 SM3 密码杂凑算法，用 于 完 整 性 校 验。 SM3 算 法 的 使 用 要 求 见GB/T 32905 。

　　— 随机数生成算法生成的随机数应能通过 GB/T 32915 规定的检测。

　　5 . 2 密钥种类

　　IPSec VPN 使用下列密钥：

　　— 设备密钥：非对称算法使用的公私钥对，包括签名密钥对和加密密钥对，用于实体验证、数字签名和数字信封等。

　　— 工作密钥：在密钥交换第一阶段得到的密钥，用于会话密钥交换过程的保护。

　　— 会话密钥：在密钥交换第二阶段得到的密钥，用于数据报文及报文 MAC 的加密。

　　6 协议

　　6 . 1 密钥交换协议

　　6 . 1 . 1 概述

　　密钥交换协议定义了协商、建立、修改、删除安全联盟的过程和报文格式。 协议报文使用 UDP 协议 500 端口进行传输。

　　本章用到的符号如下：

　　HDR：一个 ISAKMP 头 。

　　HDR *：表示 ISAKMP 头后面的载荷是加密的。

　　IDi：发起方的标识载荷。

　　IDr：响应方的标识载荷。

　　HASHi：发起方的杂凑载荷。

　　HASHr：响应方的杂凑载荷。

　　HASH_：双方进行协商交互时的中间 Hash 数据。

　　SIGi：发起方的签名载荷。

　　SIGr：响应方的签名载荷。

　　CERT_sig_r：签名证书载荷。

　　CERT__enc__r：加密证书载荷。

　　MsgID：消息标识号。

　　Ni：发起方的 Nonce 载荷。

　　Nr：响应方的 Nonce 载荷。

　　_b：载荷

　　的主体，就是没有 ISAKMP 通用头的载荷。

　　pub_i：发起方公钥。

　　pub_r：响应方公钥。

　　prv_i：发起方私钥。

　　prv_r：响应方私钥。

　　CKY-I: ISAKMP 头中的发起方 cookie。

　　CKY-R: ISAKMP 头中的响应方 cookie。

　　x | y: x 与 y 串接。

　　[ x] : x 为可选。

　　GB/T 36968—2018

　　Asymmetric_Encrypt(msg, pub_key)：使用非对称算法 Asymmetric, pub_key 作为密钥对输入信息 msg_b 进行加密，其输出为 msg 的通用载荷头和密文串接。如 SM2_Encrypt(Ski, pub_key)表示使用 SM2 算法，使用公钥 pub_key对 Ski_b 进行加密，其输出为 Ski 的通用载荷头和密文串接。

　　Asymmetric_Sign (msg, priv_key)：使用非对称算法 Asymmetric, priv_key 作为密钥对 msg 进行

　　数字签名。

　　Symmetric_Encrypt(msg, key)：使用对称算法 Symmetric, key 作为密钥对输入信息 msg_b 进行加密，其输出为 msg 的通用载荷头和密文串接。如 SM4_Encrypt(Ni, key)表示使用 SM4 算法，使用key作为密钥对 Ni_b 进行加密，其输出为 Ni 的通用载荷头和密文串接。

　　HASH(msg)：使用密码杂凑算法对 msg进行数据摘要运算。

　　PRF(key, msg)：使用密钥 key对消息 msg进行数据摘要运算。

　　6 . 1 . 2 交换阶段及模式

　　密钥交换协议包括第一阶段和第二阶段。

　　在第一阶段交换中，通信双方建立了一个 ISAKMP 安全联盟。 该安全联盟是协商双方为保护它们

　　之间的通信而使用的共享策略和密钥。用这个安全联盟来保护 IPSec 安全联盟的协商过程。一个ISAKMP 安全联盟可以用于建立多个 IPSec 安全联盟。该阶段使用主模式实现通信双方的身份鉴别

　　和密钥交换，得到工作密钥，该工作密钥用于保护第二阶段的协商过程。

　　在第二阶段交换中，通信双方使用第一阶段 ISAKMP 安全联盟协商建立 IPSec 安全联盟，IPSec 安

　　全联盟是为保护它们之间的数据通信而使用的共享策略和密钥。 该阶段使用快速模式实现通信双方

　　IPSec安全联盟的协商，确定通信双方的 IPSec安全策略及会话密钥。

　　6 . 1 . 3 交换

　　6 . 1 . 3 . 1 概述

　　交换使用标准 ISAKMP 载荷语法、属性编码、消息的超时和重传以及通知消息。

　　SA 载荷采用的载荷封装形式为：变换载荷封装在建议载荷中，建议载荷封装在 SA 载荷中。 本标准不限制发起方可以发给响应方的提议数量，如果第一阶段交换中有多个变换载荷，应将多个变换载荷封装在一个建议载荷中，然后再将它们封装在一个 SA 载荷中。 安全联盟的定义参见附录 A,有关变换载荷、建议载荷、SA 载荷等的具体定义见 6 . 1 . 5 。

　　在安全联盟的协商期间，响应方不能修改发起方发送的任何提议的属性。 否则，交换的发起方应终止协商。

　　6 . 1 . 3 . 2 第一阶段 — 主模式

　　主模式是一个身份保护的交换，其交换过程由 6 个消息组成。 双方身份的鉴别采用数字证书的方式。

　　本阶段涉及的消息头及载荷的具体内容见 6 . 1 . 5 。

　　主模式的交换过程如下：

　　GB/T 36968—2018

　　6 <---- HDR *，HASHr

　　消息 1：发起方向响应方发送一个封装有建议载荷的 SA 载荷，而建议载荷中又封装有变换载荷。

　　消息 2：响应方发送一个 SA 载荷以及响应方的签名证书和加密证书，该载荷表明它所接受的发起方发送的 SA 提议。 SA 载荷的具体内容见 6 . 1 . 5 . 6 。

　　消息 3 和消息 4：发起方和响应方交换数据，交换的数据内容包括 Nonce、身份标识(ID)等载荷。 Nonce是生成加密密钥和认证密钥所必需的参数;ID是发起方或响应方的标识。这些数据使用临时密钥 Sk进行加密保护，Sk 用对方加密证书中的公钥加密保护，并且，双方各 自对数据进行数字签名。使

　　用 SM2 算法进行加解密和数字签名验签的具体要求见 GB/T 35276 。

　　发起方交换的数据如下：

　　XCHi = Asymmetric_Encrypt(Ski, pub_r) | Symmetric_Encrypt(Ni, Ski) | Symmetric_Encrypt (IDi, Ski) | CERT_sig_i | CERT_enc_i

　　SIGi_b = Asymmetric_Sign(Ski_b | Ni_b | IDi_b | CERT_enc_i_b, priv_i)

　　响应方交换的数据如下：

　　XCHr = Asymmetric_ Encrypt ( Skr, pub_ i) | Symmetric_ Encrypt ( Nr, Skr) | Symmetric_ Encrypt(IDr, Skr)

　　SIGr_b = Asymmetric_Sign(Skr_b | Nr_b | IDr_b | CERT_enc_r_b, priv_r)

　　上述过程中使用的非对称密码算法、对称密码算法和密码杂凑算法均由消息 1 和消息 2 确定。 临

　　时密钥 Sk 由发起方和响应方各自随机生成，其长度应符合对称密码算法对密钥长度的要求。

　　对称密码运算使用 CBC模式，第一个载荷的 IV值为 0;后续的 IV使用前面载荷的最后一组密文。

　　加密前的交换数据应进行填充，使其长度等于对称密码算法分组长度的整数倍。 所有的填充字节的值除最后一个字节外都是 0,最后一个填充字节的值为不包括它自己的填充字节数。

　　IDi 和 IDr 的类型应使用 ID_DER_ASN1_DN。

　　如果对方证书已经在撤销列表中，系统应发送 INVALID_CERTIFICATE通知消息。

　　消息 3 和消息 4 交互完成后，参与通信的双方生成基本密钥参数 SKEYID, 以生成后续密钥SKEYID__d 、SKEYID_a 、SKEYID__e,计算方法分别如下 ：

　　SKEYID = PRF(HASH(Ni_b | Nr_b) , CKY-I | CKY-R)

　　SKEYID_d = PRF(SKEYID, CKY-I | CKY-R | 0)

　　SKEYID_a = PRF(SKEYID, SKEYID_d | CKY-I | CKY-R | 1)

　　SKEYID_e = PRF(SKEYID, SKEYID_a | CKY-I | CKY-R | 2)

　　上述计算公式中的值 0 , 1 , 2 是单个字节的数值。

　　SKEYID_e 是 ISAKMP SA 用来保护其消息机密性所使用的工作密钥。SKEYID_a 是 ISAKMP SA用来验证其消息完整性以及数据源身份所使用的工作密钥。SKEYID_d 用于会话密钥的产生。

　　所有 SKEYID 的长度都由 PRF 函数的输出长度决定。 如果 PRF 函数的输出长度太短，不能作为

　　一个密钥来使用，则 SKEYID_e应进行扩展。例如，HMAC 的一个 PRF 可产生 128 比特的输出，但密码算法要求用到大于 128 比特的密钥的时候，SKEYID_e 就需要利用反馈及连接方法加以扩展，直到满

　　足对密钥长度的要求为止。 反馈及连接方法如下：

　　K = K1 | K2 | K3 …

　　K1 = PRF( SKEYID__e, 0 )

　　K2 = PRF( SKEYID__e, K1)

　　K3 = PRF( SKEYID__e, K2)

　　…

　　最后从 K 的起始位置开始取密码算法的密钥所需要的位数。

　　消息 5 和消息 6 发起方和响应方鉴别前面的交换过程。 这两个消息中传递的信息使用对称密码算

　　GB/T 36968—2018

　　法加密。对称密码算法由消息 1 和消息 2 确定，密钥使用 SKEYID_e。对称密码运算使用 CBC 模式，初始化向量 IV是消息 3 中的 Ski 和消息 4 中的 Skr 串连起来经过 Hash 运算得到的，即：

　　IV= HASH(Ski_b | Skr_b)

　　Hash算法由消息 1 和消息 2 确定。

　　加密前的消息应进行填充，使其长度等于对称密码算法分组长度的整数倍。 所有的填充字节的值都是 0 。报头中的消息长度应包括填充字节的长度，因为这反映了密文的长度。

　　为了鉴别交换，发起方产生 HASHi,响应方产生 HASHr,计算公式如下：

　　HASHi = PRF(SKEYID, CKY-I | CKY-R | SAi_b | IDi_b)

　　HASHr = PRF(SKEYID, CKY-R | CKY-I | SAr_b | IDr_b)

　　6 . 1 . 3 . 3 第二阶段 — 快速模式

　　快速模式交换依赖于第一阶段主模式交换，作为 IPSec SA 协商过程的一部分协商 IPSec SA 的安

　　全策略并衍生会话密钥。 快速模式交换的信息由 ISAKMP SA来保护，即除了 ISAKMP 头外所有的载

　　荷都要加密。在快速模式中，一个 Hash 载荷应紧跟在 ISAKMP 头之后，这个 Hash 用于消息的完整性

　　校验以及数据源身份验证。

　　在第二阶段，载荷的加密使用对称密码算法的 CBC工作模式，第 1 个消息的 IV是第一阶段的最后

　　一组密文和第二阶段的 MsgID进行 Hash 运算所得到的，即：

　　IV=HASH(第一阶段的最后一组密文 | MsgID)

　　后续的 IV是前一个消息的最后一组密文。 消息的填充和第一阶段中的填充方式相同。

　　在 ISAKMP 头中的 MsgID 唯一标识了一个正在进行中的快速模式，而该 ISAKMP SA 本身又由ISAKMP 头中的 cookie来标识。因为快速模式的每个实例使用一个唯一的 IV,这就有可能基于一个

　　ISAKMP SA 的多个快速模式在任一时间内同时进行。

　　在快速模式协商中，身份标识 ID缺省定义为 ISAKMP 双方的 IP 地址，并且没有强制规定允许的

　　协议或端口号。如果协商双方需要指定 ID,则双方的身份应作为 IDi 和 IDr 被依次传递。响应方的本

　　地安全策略将决定是否接受对方的身份标识 ID。 如果发起方的身份标识 ID 由于安全策略或其他原因没有被响应方所接受，则响应方应该发送一个通知消息类型为 INVALID_ ID_ INFORMATION(18)的通知载荷。

　　在通信双方之间有多条隧道同时存在的情况下，身份标识 ID 为对应的 IPSec SA 标识并规定通信

　　数据流进入对应的隧道。

　　本阶段涉及的消息头及载荷的具体内容见 6 . 1 . 5 。

　　快速模式的交换过程如下：

　　消息 1：发起方向响应方发送一个杂凑载荷、一个 SA 载荷(其中封装了一个或多个建议载荷，而每

　　个建议载荷中又封装一个或多个变换载荷)、一个 Nonce 载荷和标识载荷。

　　杂凑载荷中消息摘要的计算方法如下：

　　HASH_1 = PRF(SKEYID_a, MsgID | Ni_b | SA [ | IDi | IDr])

　　消息 2：响应方向发起方发送一个杂凑载荷、一个 SA 载荷、一个 Nonce 载荷和标识载荷。

　　杂凑载荷中消息摘要的计算方法如下：

　　HASH_2 = PRF(SKEYID_a, MsgID | Ni_b | SA | Nr_b [ | IDi | IDr])

　　GB/T 36968—2018

　　消息 3：发起方向响应方发送一个杂凑载荷，用于对前面的交换进行鉴别。

　　杂凑载荷中消息摘要的计算方法如下：

　　HASH_3 = PRF(SKEYID_a, 0 | MsgID | Ni_b | Nr_b)

　　最后，会话密钥素材定义为：

　　KEYMAT = PRF(SKEYID_d, protocol | SPI | Ni_b | Nr_b)

　　其中，protocol 和 SPI从协商得到的 ISAKMP 建议载荷中选取。

　　用于加密的会话密钥和用于完整性校验的会话密钥按照算法要求的长度从 KEYMAT 中依次选取 。先选取用于加密的会话密钥，后选取用于完整性校验的会话密钥。

　　当 PRF 函数的输出长度小于 KEYMAT需要的密钥素材长度时，需要利用反馈及连接方法加以扩展，直到满足对密钥长度的要求为止。 即：

　　KEYMAT = K1 | K2 | K3 …

　　其中：

　　K1 = PRF(SKEYID_d, protocol | SPI | Ni_b | Nr_b)

　　K2 = PRF(SKEYID_d, K1 | protocol | SPI | Ni_b | Nr_b)

　　K3 = PRF(SKEYID_d, K2 | protocol | SPI | Ni_b | Nr_b)

　　…

　　单个 SA协商产生两个安全联盟— 一个入，一个出。 每个 SA(一个由发起方选择，另一个由响应方选择)的不同的 SPI保证了每个方向都有一个不同的 KEYMAT。 由 SA 的 目 的地选择的 SPI,被用于衍生该 SA 的 KEYMAT。

　　6 . 1 . 3 . 4 ISAKMP信息交换

　　如果安全联盟已经建立，则 ISAKMP 信息交换过程如下所示：

　　发起方 方向 响应方

　　HDR *，HASH_1, N/D ---->

　　其中，N/D是一个 ISAKMP 通知载荷，或是一个 ISAKMP 删除载荷。 HASH_ 1 的计算方法为：

　　HASH_1 = PRF(SKEYID_a, MsgID | N/D)

　　其中，MsgID不能与同一个 ISAKMP SA保护的其他第二阶段交换的 MsgID相同。

　　这个消息的加密使用对称密码算法的 CBC工作模式，其密钥使用 SKEYID_e,初始化向量 IV是第一阶段的最后一组密文和 MsgID进行 Hash 运算所得到的，即：

　　IV= HASH(第一阶段的最后一组密文 | MsgID)

　　消息的填充和第一阶段中的填充方式相同。

　　如果 ISAKMP 安全联盟在信息交换时还没有建立，则消息以明文发送，即：

　　发起方 方向 响应方

　　HDR, N ---->

　　6 . 1 . 4 NAT穿越

　　IPSec 穿越 NAT 特性让 IPSec数据流能够穿越网络中的 NAT设备。NAT 穿越由 3 个部分组成：

　　首先判断通信的双方是否支持 NAT 穿越，其次检测双方之间的路径上是否存在 NAT,最后决定如何使用 UDP 封装来处理 NAT 穿越。

　　实现 NAT 穿越的 NAT_D 载荷分别添加在第一阶段交换过程中消息 3 和消息 4 的载荷之后，这些载荷是独立的，不参与交换过程的所有密码运算。 支持 NAT 穿越的第一阶段交换过程如下：

　　GB/T 36968—2018

　　注：#标志说明如果 NAT存在，这些包将被发送到修改后的端口。

　　如果需要，NAT_ OA 载荷分别添加在第二阶段交换过程中消息 1 和消息 2 的载荷之后，同第二阶段的消息载荷一起参与密码运算。

　　实现 NAT 穿越的处理过程和消息格式按 RFC 3947 的规定执行。

　　6 . 1 . 5 密钥交换的载荷格式

　　6 . 1 . 5 . 1 消息头格式

　　密钥交换协议消息由一个定长的消息头和不定数量的载荷组成。 消息头包含密钥交换协议用来保持状态并处理载荷所必须的信息。

　　ISAKMP 的头格式如图 1 所示。

　　图 1 ISAKMP头格式

　　发起方 cookie：这个字段是一个唯一的 8 字节比特串，由发起方随机生成。

　　响应方 cookie：这个字段是一个唯一的 8 字节比特串，由响应方随机生成。

　　cookie 的生成方法应依据 RFC 2408 中 2.5.3 要求生成。

　　下一个载荷：这个字段为 1 个字节，说明消息中的第一个载荷的类型。 载荷类型的定义如表 1所示。

　　表 1 载荷类型的定义

　　GB/T 36968—2018

　　表 1(续)

　　版本号：这个字段为 1 个字节，其中 0~3 位表示主版本号，4~7 位表示次版本号。本标准规定主

　　版本号为 1,次版本号为 1 。

　　交换类型：这个字段为 1 个字节，说明组成消息的交换的类型。 交换类型的定义如表 2 所示。

　　表 2 交换类型的定义

　　本标准规定密钥交换第一阶段使用的交换类型为身份保护类型即主模式，其值为 2 。第二阶段交换使用的快速模式所分配的值为 32 。

　　标志：这个字段的长度为 1 个字节，说明为密钥交换协议设置的具体选项。 目前使用了这个域的前

　　3 个比特，其他比特在传输前被置为 0 。具体定义如下：

　　GB/T 36968—2018

　　— 加密比特：这是标志字段中的最低有效比特。 当这个比特被置为 1 时，该消息头后面所有的载荷都采用 ISAKMP SA 中指定的密码算法加密。 当这个比特被置为 0 时，载荷不加密。

　　— 提交比特：这是标志字段的第 2 个比特，本标准中其值为 0 。

　　— 仅鉴别比特：这是标志字段的第 3 个比特，本标准中其值为 0 。

　　消息 ID：这个字段的长度为 4 字节，第一阶段中该字段为 0,在第二阶段为发起方生成的随机数。它作为唯一的消息标志，用于在第二阶段的协商中标识协议状态。

　　长度：这个字段的长度为 4 字节，长度数值以字节为单位，计算范围包含消息头和载荷在内的整个消息。

　　6 . 1 . 5 . 2 通用载荷头

　　每个载荷由通用载荷头开始。 通用载荷头定义了载荷的边界，所以就可以联接不同的载荷。 通用载荷头的定义如图 2 所示。

　　图 2 通用载荷头格式

　　下一个载荷：这个字段的长度为 1 个字节，标识了本载荷后下一个载荷的类型。 如果当前载荷是最后一个，则该字段将被置为 0 。载荷类型由表 1 定义。

　　保留：这个字段的长度为 1 个字节，其值为 0 。

　　载荷长度：这个字段的长度为 2 个字节，长度数值以字节为单位，计算范围包含通用载荷头在内的整个载荷。

　　6 . 1 . 5 . 3 SA载荷

　　SA 载荷用于协商安全联盟，并且指定协商所基于的解释域 DOI。 载荷的格式依赖于它使用的DOI,本载荷的类型值为 1 。SA 载荷的格式如图 3 所示。

　　图 3 SA载荷格式

　　下一个载荷：这个字段的长度为 1 个字节，标识了本载荷后下一个载荷的类型。 如果当前载荷是最后一个，则该字段将被置为 0 。载荷类型由表 1 定义。

　　保留：这个字段的长度为 1 个字节，其值为 0 。

　　载荷长度：这个字段的长度为 2 个字节，长度数值以字节为单位，计算范围包括 SA 载荷、所有建议载荷和所有与被提议的安全联盟有关的变换载荷。

　　解释域(DOI) ：这个字段长度为 4 个字节，其值为无符号整数，它指定协商所基于的 DOI,这个字段的值为 1 。

　　情形：这个字段长度为 4 个字节，表明协商发生时的情形，用来决定需要的安全服务的信息。 定义

　　如下：

　　—SIT__IDENTITY_ ONLY：其值为 1 。 表明 SA 将由一个相关的标识载荷中的源标识信息来

　　GB/T 36968—2018

　　标识。

　　—SIT__SECRECY：其值为 2 。表明 SA 正在一个需经标记的秘密的环境中协商。

　　—SIT__INTEGRITY：其值是 4 。表明 SA 正在一个需经标记的完整性环境中协商。本标准默认采用 SIT__IDENTITY_ ONLY情形。

　　6 . 1 . 5 . 4 建议载荷

　　建议载荷用于密钥交换的发起方告知响应方它优先选择的安全协议以及希望协商中的 SA 采用的相关安全机制，本载荷的类型值为 2 。建议载荷的格式如图 4 所示。

　　图 4 建议载荷格式

　　下一个载荷：这个字段的长度为 1 个字节，如果后面还有建议载荷，其值为 2,否则应为 0 。

　　保留：这个字段的长度为 1 个字节，其值为 0 。

　　载荷长度：这个字段的长度为 2 个字节，长度数值以字节为单位，用于表示整个建议载荷的长度，计算范围包括通用载荷头、建议载荷所有与该建议有关的变换载荷，该长度仅用于标示本建议载荷的长度。

　　建议号：这个字段的长度为 1 个字节，用于表示本建议载荷的建议编号。 多个建议的建议号相同表示这些建议是“逻辑与”的关系，不同表示这些建议是“逻辑或”的关系;单调递增的建议号表示对建议的优先选择顺序，建议号越小优先权越高。

　　协议 ID：这个字段的长度为 1 个字节，用于表示协议标识符。 协议标识符的定义如表 3 所示。

　　表 3 协议标识符的定义

　　SPI 长度：这个字段的长度为 1 个字节，长度数值以字节为单位，用于表示 SPI 的长度。 在第一阶段该长度为 0,在第二阶段该长度为 4 。

　　变换数：这个字段的长度为 1 个字节，标示建议的变换载荷个数。

　　变长的 SPI：在第一阶段没有这个字段，在第二阶段这个字段的长度为 4 个字节，其内容是该建议的提出者产生的随机数。

　　6 . 1 . 5 . 5 变换载荷

　　变换载荷用于密钥交换的发起方告知响应方为一个指定的协议提供不同的安全机制，本载荷的类

　　GB/T 36968—2018

　　型值为 3 。变换载荷的格式如图 5 所示。

　　图 5 变换载荷格式

　　下一个载荷：这个字段的长度为 1 个字节，如果后面还有变换载荷，其值为 3,否则应为 0 。

　　保留：这个字段的长度为 1 个字节，其值为 0 。

　　载荷长度：这个字段的长度为 2 个字节，长度数值以字节为单位，用于表示本变换载荷的长度。 计算范围包括通用载荷头、变换载荷和所有的 SA 属性载荷。

　　变换号：这个字段的长度为 1 个字节，用于表示本变换载荷的变换编号。 单调递增的变换号表示对变换的优先选择顺序，变换号越小优先权越高。

　　变换 ID：这个字段的长度为 1 个字节，用于表示建议协议的变换标识符。 在第一阶段该字段的值为 1,在第二阶段根据不同的协议选用不同的变换 ID。 AH 协议的变换 ID 的定义如表 4 所示，ESP 协议的变换 ID 的定义如表 5 所示。

　　表 4 AH 协议的变换 ID的定义

　　表 5 ESP协议的变换 ID的定义

　　保留 2：这个字段的长度为 2 个字节，其值为 0 。

　　SA 属性：该字段的长度是可变的，用于表示本变换的 SA 属性。 该字段的具体定义见 6 . 1 . 5 . 6 。

　　6 . 1 . 5 . 6 SA属性载荷

　　SA属性载荷只能用于变换载荷之后，并且没有通用载荷头，用于描述 SA 属性的数据结构，本载荷的类型值为 14 。SA 属性载荷的格式如图 6 所示。

　　GB/T 36968—2018

　　图 6 SA属性载荷格式

　　属性类型：这个字段的长度为 2 个字节，用于表示属性类型。 该字段的最高有效比特(比特 0)如果为 0,属性值是变长的，并且本载荷有 3 个字段，分别是属性类型、属性长度和属性值。 如果属性类型最高有效比特为 1,属性值是定长的并且本载荷仅有 2 个字段，分别是属性类型和属性值。 如果属性类型是变长的，并且属性值能在两个字节中表示，那么变长的属性可以用定长表示。

　　第一阶段密钥交换属性类型的定义如表 6 所示。

　　表 6 第一阶段密钥交换属性类型的定义

　　第二阶段密钥交换属性类型的定义如表 7 所示。

　　GB/T 36968—2018

　　表 7 第二阶段密钥交换属性类型的定义

　　属性值：这个字段如果是定长的，其长度为 2 个字节。 如果是变长的，其长度由属性长度字段指定。

　　属性长度：当属性值是变长时，该字段用于表示属性值的长度。第一阶段加密算法属性值的定义如表 8 所示。

　　表 8 第一阶段加密算法属性值的定义

　　第一阶段密码杂凑算法属性值的定义如表 9 所示。

　　表 9 第一阶段密码杂凑算法属性值的定义

　　第一阶段鉴别方式属性值的定义如表 10 所示。

　　表 10 第一阶段鉴别方式属性值的定义

　　SA 生存期类型属性值的定义适用于第一阶段和第二阶段，如表 11 所示。

　　表 1 1 SA生存期类型属性值的定义

　　GB/T 36968—2018

　　第一阶段公钥算法类型属性值的定义如表 12 所示。

　　表 12 第一阶段公钥算法类型属性值的定义

　　第二阶段封装模式属性值的定义如表 13 所示。

　　表 13 第二阶段封装模式属性值的定义

　　第二阶段鉴别算法属性值的定义如表 14 所示。

　　表 14 第二阶段鉴别算法属性值的定义

　　6 . 1 . 5 . 7 标识载荷

　　标识载荷用于通信双方交换身份信息，该信息用于确认通信双方的身份，本载荷的类型值为 5 。标识载荷的格式如图 7 所示。

　　图 7 标识载荷格式

　　下一个载荷：这个字段的长度为 1 个字节，标识了本载荷后下一个载荷的类型。 如果当前载荷是最后一个，则该字段将被置为 0 。载荷类型由表 1 定义。

　　保留：这个字段的长度为 1 个字节，其值为 0 。

　　载荷长度：这个字段的长度为 2 个字节，长度数值以字节为单位，用于包含通用载荷头在内的整个载荷长度。

　　标识类型：这个字段的长度为 1 个字节，用于表示标识数据字段中的身份信息类型。 标识类型的定义如表 15 所示。

　　GB/T 36968—2018

　　表 15 标识类型的定义

　　在第一阶段可以使用的标识类型为：

　　ID_IPv4__ADDR

　　ID_IPv6__ADDR

　　ID_DER_ASN1_DN

　　ID_DER_ASN1__GN

　　ID_FQDN

　　ID_USER_FQDN

　　ID_KEY_ID

　　在第二阶段可以使用的标识类型为：

　　ID_IPv4__ADDR

　　ID_IPv6__ADDR

　　ID_IPv4__ADDR__SUBNET

　　ID_IPv6__ADDR__SUBNET

　　ID_IPv4__ADDR_RANGE

　　ID_IPv6__ADDR_RANGE

　　协议 ID：这个字段的长度为 1 个字节，用于表示一个 IP 协议的上层协议号。 值为 0 表明忽略这个字段，在第一阶段这个值应为 0 。在第二阶段是用户配置的安全策略五元组的协议，值为 0 表明忽略这个字段。

　　端 口：这个字段的长度为 2 个字节，用于表示一个上层协议的端 口 。值为 0 表明忽略这个字段，在第一阶段这个值应为 0 。在第二阶段是用户配置的安全策略五元组的端口，值为 0 表明忽略这个字段。

　　标识数据：这个字段是变长的，用于表示与 ID类型字段相对应的标识信息。

　　6 . 1 . 5 . 8 证书载荷

　　证书载荷用于通信双方交换证书以及证书相关信息，本载荷的类型值为 6 。

　　证书载荷的格式如图 8 所示。

　　GB/T 36968—2018

　　图 8 证书载荷格式

　　下一个载荷：这个字段的长度为 1 个字节，标识了本载荷后下一个载荷的类型。 如果当前载荷是最后一个，则该字段将被置为 0 。载荷类型由表 1 定义。

　　保留：这个字段的长度为 1 个字节，其值为 0 。

　　载荷长度：这个字段的长度为 2 个字节，长度数值以字节为单位，用于表示包含通用载荷头在内的整个载荷长度。

　　证书编码：这个字段的长度为 1 个字节，用于表示证书数据字段的证书编码类型。 证书编码类型定义如表 16 所示。

　　表 16 证书编码类型定义

　　在本标准中，只能使用 X. 509 格式的签名证书和加密证书。

　　证书数据：这个字段是变长字段，证书的结构及定义见 GB/T 20518 。

　　6 . 1 . 5 . 9 杂凑载荷

　　杂凑载荷的内容是在 SA协商过程中选定的密码杂凑算法生成的数据，本载荷的类型值为 8 。杂凑载荷的格式如图 9 所示。

　　图 9 杂凑载荷格式

　　下一个载荷：这个字段的长度为 1 个字节，标识了本载荷后下一个载荷的类型。 如果当前载荷是最后一个，则该字段将被置为 0 。载荷类型由表 1 定义。

　　保留：这个字段的长度为 1 个字节，其值为 0 。

　　载荷长度：这个字段的长度为 2 个字节，长度数值以字节为单位，用于表示包含通用载荷头在内的整个载荷长度。

　　杂凑数据：这个字段的长度是变长的，其内容为密码杂凑算法生成的数据。

　　6 . 1 . 5 . 10 签名载荷

　　签名载荷的内容是在 SA协商过程中的数字签名算法生成的数据，本载荷的类型值为 9 。签名载荷的格式如图 10 所示。

　　GB/T 36968—2018

　　图 10 签名载荷格式

　　下一个载荷：这个字段的长度为 1 个字节，标识了本载荷后下一个载荷的类型。 如果当前载荷是最后一个，则该字段将被置为 0 。载荷类型由表 1 定义。

　　保留：这个字段的长度为 1 个字节，其值为 0 。

　　载荷长度：这个字段的长度为 2 个字节，数值长度以字节为单位，用于表示包含通用载荷头在内的整个载荷长度。

　　签名数据：这个字段的长度是变长的，其内容为签名算法生成的数据。

　　6 . 1 . 5 . 1 1 Nonce载荷

　　Nonce 载荷的内容是用于保护交换数据的随机数据，本载荷的类型值为 10。Nonce 载荷的格式如

　　图 11 所示。

　　图 1 1 Nonce载荷格式

　　下一个载荷：这个字段的长度为 1 个字节，标识了本载荷后下一个载荷的类型。 如果当前载荷是最后一个，则该字段将被置为 0 。载荷类型由表 1 定义。

　　保留：这个字段的长度为 1 个字节，其值为 0 。

　　载荷长度：这个字段的长度为 2 个字节，数值长度以字节为单位，用于表示包含通用载荷头在内的整个载荷长度。

　　Nonce数据：这个字段的长度是变长的，其内容为随机数。

　　6 . 1 . 5 . 12 通知载荷

　　通知载荷用于传送通知数据，本载荷的类型值为 11,通知载荷的格式如图 12 所示。

　　图 12 通知载荷格式

　　GB/T 36968—2018

　　下一个载荷：这个字段的长度为 1 个字节，标识了本载荷后下一个载荷的类型。 如果当前载荷是最后一个，则该字段将被置为 0 。载荷类型由表 1 定义。

　　保留：这个字段的长度为 1 个字节，其值为 0 。

　　载荷长度：这个字段的长度为 2 个字节，长度数值以字节为单位，用于表示包含通用载荷头在内的整个载荷长度。

　　解释域(DOI) ：这个字段的长度为 4 个字节，这个字段的值为 1 。

　　协议 ID：这个字段的长度为 1 个字节，用于表示协议标识符。 协议标识符的定义如表 3 所示。

　　SPI 长度：这个字段的长度为 1 个字节，长度数值以字节为单位，用于表示 SPI 的长度。 在第一阶段该长度为 0,在第二阶段该长度为 4 。

　　通知消息类型：这个字段的长度为 2 个字节，用于表示通知消息类型。 通知消息的错误类型如表 17所示，通知消息的状态类型如表 18 所示。

　　表 17 通知消息的错误类型

　　GB/T 36968—2018

　　表 17(续)

　　表 18 通知消息的状态类型

　　SPI：在第一阶段没有这个字段。 在第二阶段这个字段的长度为 4 个字节，其内容是接收方建议载荷中的 SPI值。

　　通知数据：这个字段是变长的，用于传送通知消息类型对应的通知数据。

　　6 . 1 . 5 . 13 删除载荷

　　删除载荷用于通知对方某个 SA 已经取消，本载荷的类型值为 12 。删除载荷的格式如图 13 所示。

　　图 13 删除载荷格式

　　GB/T 36968—2018

　　下一个载荷：这个字段的长度为 1 个字节，标识了本载荷后下一个载荷的类型。 如果当前载荷是最后一个，则该字段将被置为 0 。载荷类型由表 1 定义。

　　保留：这个字段的长度为 1 个字节，其值为 0 。

　　载荷长度：这个字段的长度为 2 个字节，长度数值以字节为单位，用于表示包含通用载荷头在内的整个载荷长度。

　　解释域(DOI) ：这个字段的长度为 4 个字节，其值为 1 。

　　协议 ID：这个字段的长度为 1 个字节，用于表示要删除的 SA 的协议标识符。 协议标识符的定义如表 3 所示。

　　SPI 长度：这个字段的长度为 1 个字节，长度数值以字节为单位，用于表示 SPI 的长度。 删除第 一阶段的 SA 时该长度为 16,删除第二阶段的 SA 时该长度为 4 。

　　SPI 数目：这个字段的长度为 2 个字节，用于表示本载荷中包含的 SPI 数目。

　　安全参数索引(SPI) ：这个字段是变长的，用于表示被删除 SA 的 SPI。 这个字段的长度由 SPI 长度字段和 SPI数目字段的值决定。

　　6 . 1 . 5 . 14 厂商 ID载荷

　　厂商 ID 载荷用于传递厂商 自定义的常量，本载荷的类型值为 13 。 厂商 ID 载荷的格式如图 14所示。

　　图 14 厂商 ID载荷格式

　　下一个载荷：这个字段的长度为 1 个字节，标识了本载荷后下一个载荷的类型。 如果当前载荷是最后一个，则该字段将被置为 0 。载荷类型由表 1 定义。

　　保留：这个字段的长度为 1 个字节，其值为 0 。

　　载荷长度：这个字段的长度为 2 个字节，长度数值以字节为单位，用于表示包含通用载荷头在内的整个载荷长度。

　　厂商 ID(VID) ：这个字段是变长的，其内容为厂商 ID 串的杂凑值。

　　6 . 1 . 5 . 15 NAT_D 载荷

　　NAT_D 载荷用于检测两个密钥交换通信方之间是否存在 NAT 设备，以及检测 NAT 设备的确切位置，本载荷的类型值为 20 。NAT_D 载荷的格式如图 15 所示。

　　图 15 NAT_D 载荷格式

　　下一个载荷：这个字段的长度为 1 个字节，标识了本载荷后下一个载荷的类型。 如果当前载荷是最后一个，则该字段将被置为 0 。载荷类型由表 1 定义。

　　保留：这个字段的长度为 1 个字节，其值为 0 。

　　载荷长度：这个字段的长度为 2 个字节，长度数值以字节为单位，用于表示包含通用载荷头在内的

　　GB/T 36968—2018

　　整个载荷长度。

　　载荷内容：这个字段是变长的，其内容为：

　　HASH(CKY-I | CKY-R | IP | Port)

　　6 . 1 . 5 . 16 NAT_OA载荷

　　NAT_ OA 载荷用于密钥交换第二阶段中，当使用传输模式穿越 NAT 时需要传送这个载荷，本载荷的类型值为 21 。NAT_ OA 载荷的载荷格式如图 16 所示。

　　图 16 NAT_OA载荷格式

　　下一个载荷：这个字段的长度为 1 个字节，标识了本载荷后下一个载荷的类型。 如果当前载荷是最后一个，则该字段将被置为 0 。载荷类型由表 1 定义。

　　保留：这个字段的长度为 1 个字节，其值为 0 。

　　载荷长度：这个字段的长度为 2 个字节，长度数值以字节为单位，用于表示包含通用载荷头在内的整个载荷长度。

　　ID类型：这个字段的长度为 1 个字节，其值为表 15 中的 ID_IPV4_ADDR 的值或 ID_IPv6_ADDR

　　的值。

　　保留 2：这个字段的长度为 3 个字节，其值为 0 。

　　NAT_OA数据：这个字段的值是 4 字节 IPv4 地址或 16 字节 IPv6 地址。

　　6 . 1 . 5 . 17 对称密钥载荷

　　对称密钥载荷用于在密钥交换第一阶段时，传递数字信封中的对称密钥，本载荷的类型值为 128 。对称密钥载荷的格式如图 17 所示。

　　图 17 对称密钥载荷格式

　　下一个载荷：这个字段的长度为 1 个字节，标识了本载荷后下一个载荷的类型。 如果当前载荷是最后一个，则该字段将被置为 0 。载荷类型由表 1 定义。

　　保留：这个字段的长度为 1 个字节，其值为 0 。

　　载荷长度：这个字段的长度为 2 个字节，长度数值以字节为单位，用于表示包含通用载荷头在内的整个载荷长度。

　　对称密钥密文：这个字段的长度是可变的，其内容为由公钥加密的对称密钥。

　　GB/T 36968—2018

　　6 . 1 . 6 密钥交换的数据包格式

　　6 . 1 . 6 . 1 概述

　　密钥交换消息是基于 UDP传输的，使用 UDP 500 端口或者 4 500 端 口 。在 UDP 500 端口上发送的密钥交换消息直接跟在 UDP 报头后面。 在 UDP 4 500 端口上发送的密钥交换消息，需要在 UDP 头与密钥交换消息之间插入 4 个全 0 的字节。

　　每一条密钥交换消息以消息头 HDR 作为开始标志。 每个 HDR 后可以有一个或者多个载荷。 如果有多个载荷，则用每一个载荷内的“下一个载荷”字段进行标识，如果“下一个载荷”字段为 0,说明消息结束。

　　在本条的所有图中，“下一载荷”用“NP”来表示。

　　6 . 1 . 6 . 2 主模式消息 1 的数据包格式

　　主模式消息 1 的数据包的格式如图 18 所示，其中 SA 载荷中应当支持 SM4-SM3 变换载荷。

　　图 18 主模式消息 1 的数据包格式

　　GB/T 36968—2018

　　6 . 1 . 6 . 3 主模式消息 2 的数据包格式

　　主模式消息 2 的数据包的格式如图 19 所示。

　　图 19 主模式消息 2 的数据包格式

　　6 . 1 . 6 . 4 主模式消息 3 的数据包格式

　　使用证书鉴别的主模式消息 3 数据包的格式如图 20 所示。

　　GB/T 36968—2018

　　图 20 主模式消息 2 的数据包格式

　　6 . 1 . 6 . 5 主模式消息 4 的数据包格式

　　主模式消息 4 数据包的格式如图 21 所示。

　　GB/T 36968—2018

　　图 2 1 主模式消息 4 的数据包格式

　　6 . 1 . 6 . 6 主模式消息 5 的数据包的格式

　　主模式消息 5 的数据包的格式如图 22 所示。

　　图 22 主模式消息 5 的数据包格式

　　6 . 1 . 6 . 7 主模式消息 6 的数据的包格式

　　主模式消息 6 的数据包的格式如图 23 所示。

　　GB/T 36968—2018

　　图 23 主模式消息 6 的数据包格式

　　6 . 1 . 6 . 8 快速模式消息 1 的数据包格式

　　快速模式消息 1 的数据包的格式如图 24 所示，其中 SA 载荷中有一个 ESP 协议建议，建议中有两种变换。

　　GB/T 36968—2018

　　图 24 快速模式消息 1 的数据包格式

　　GB/T 36968—2018

　　6 . 1 . 6 . 9 快速模式消息 2 的数据包格式

　　快速模式消息 2 的数据包的格式如图 25 所示，其中选择了一种变换。

　　图 25 快速模式消息 2 的数据包格式

　　GB/T 36968—2018

　　6 . 1 . 6 . 10 快速模式消息 3 的数据包格式

　　快速模式消息 3 的数据包的格式如图 26 所示。

　　图 26 快速模式消息 3 的数据包格式

　　6 . 2 安全报文协议

　　6 . 2 . 1 鉴别头协议 AH

　　6 . 2 . 1 . 1 概述

　　鉴别头协议 AH 用于为 IP 数据报文提供无连接的完整性、数据源鉴别和抗重放攻击服务。 AH 为IP 头提供尽可能多的鉴别，同时为上层协议数据提供鉴别。 对于抗重放攻击服务，AH 依靠一个单调递增的抗重放攻击序列号来完成。 AH 不能提供机密性服务，因此本标准规定 AH 不能单独使用，而应和封装安全载荷协议 ESP嵌套使用。

　　6 . 2 . 1 . 2 AH 头格式

　　AH 头格式见图 27,该格式里的所有字段都是强制的，并且被包括在完整性校验值(ICV)计算中。

　　AH 头紧跟在 IP 协议头(IPv4、IPv6 ,或者扩展)之后，在 IP 协议头中的协议字段(IPv4)或者下一个头(IPv6、扩展)字段的值是 51。

　　图 27 AH 头格式

　　下一个头：下一个头是一个 1 字节的字段，该字段指定了鉴别头后面下一个载荷的类型。 这个字段

　　的值是由 Internet 分配数字机构(IANA) 的最新“分配数字”[STD-2] 中定义的 IP 协议数字集合分

　　配的。

　　GB/T 36968—2018

　　载荷长度：载荷长度是一个 1 字节的字段，该字段的值是 AH 头的长度减去 2,长度值以 4 字节为单位。

　　保留：保留字段是一个 2 字节的字段，留给将来使用。 该字段应被设置成 0,并且参与完整性校验值 ICV 的计算。

　　安全参数索引(SPI) ：安全参数索引 SPI 是一个 4 字节值，它与 目 的 IP地址和安全协议共同标识了这个数据报文的安全联盟。 从 1 至 255 范围内的 SPI 值是保留给将来使用的，0 值保留给本地的特定实现使用并且不能在网络上传送，通信协商得到的 SPI值不能小于 256 。

　　序列号：序列号是一个无符号的 4 字节单调递增计数器，发送方对使用该 SA 的每个数据报文进行计数，接收方应检测这个字段来实现 SA 的抗重放攻击服务。 发送方的计数器和接收方的计数器在建立一个 SA 时被初始化为 0,该序列号在一个 SA 生存期内不能循环使用，在这个计数器溢出之前，通信的双方应协商出一个新的 SA来使这个字段复位为 0 。

　　鉴别数据：鉴别数据是一个变长字段，它是一个完整性校验值 ICV,用于校验整个 IP 报文的完整性(可变字段除外)。该字段的长度应是 4 字节的整数倍，具体长度取决于所使用的完整性校验算法。

　　6 . 2 . 1 . 3 鉴别头 AH 的处理

　　6 . 2 . 1 . 3 . 1 AH 头的位置

　　AH 头在传输模式和隧道模式中分别有不同的放置位置。

　　在 IPv4 环境中使用传输模式，AH 头应放在原 IP 头之后，上层协议 ESP 之前，如图 28 所示。

　　图 28 IPv4 的 AH传输模式

　　在 IPv6 环境中使用传输模式，AH 头被看作是一个端到端的载荷，因而应该出现在逐跳(Hop- by-Hop)、路由 (Routing) 和 分 片 扩 展 头 (Fragmentation Extensionheaders) 之 后。目 的 选 项 扩 展 头 (Destination Options Extension Header) 既可 以 出现在 AH 头之前，也可以在 AH 头之后。如 图 29

　　所示。

　　GB/T 36968—2018

　　图 29 IPv6 的 AH传输模式

　　在隧道模式中，AH 头保护整个 IP 报文，包括整个原 IP 报文以及新建外部 IP 头的部分字段。

　　图 30和图 31 分别表示了隧道模式中典型的 IPv4 和 IPv6 报文的 AH 头的位置。

　　图 30 IPv4 的 AH 隧道模式

　　图 3 1 IPv6 的 AH 隧道模式

　　6 . 2 . 1 . 3 . 2 出站报文处理

　　6 . 2 . 1 . 3 . 2 . 1 概述

　　出站报文的处理包括查找 SA、产生序列号、计算完整性校验值、鉴别数据字段的填充和分片等

　　GB/T 36968—2018

　　过程。

　　6 . 2 . 1 . 3 . 2 . 2 查找 SA

　　应根据本地策略查找 SA,只有当一个 IPSec 实现确定了报文与该 SA 相关联后，AH 才应用于一

　　个出站报文。 否则应开始新的密钥交换过程，建立 SA。

　　6 . 2 . 1 . 3 . 2 . 3 产生序列号

　　当建立一个 SA 时，发送方的序列号计数器初始化为 0,每发送一个报文之前，该计数器加 1,并且把这个计数器值赋予序列号字段。 当该计数器计数达到最大值前，应生成新的 SA。

　　6 . 2 . 1 . 3 . 2 . 4 计算完整性校验值 ICV

　　接收方采用指定的完整性校验算法对报文计算 ICV。IPv4 和 IPv6 的 ICV计算方法分别如下所述：

　　a) IPv4 中的 ICV计算

　　IPv4 基本头字段、IPv4 头的选项、AH 头和上层协议数据都参与 ICV计算。

　　IPv4 基本头字段中，直接参与计算的字段为：版本(Version)、IPv4 头长度( Header Length)、总长度(Total Length)、标识(Identification)、协议(Protocol)、源地址(Source Address)、目的

　　地址(Destination Address) 。

　　IPv4 基本头字段中，在计算 ICV 之前设置为“0”的字段为：服务类型(TOS)、标志(Flags)、片偏移(Fragment Offset)、生存时间(TTL)、首部校验和(Header Checksum)。

　　IPv4 头的整个选项被看作一个单元，选项中的类型和长度字段在传送中是不变的，但如果有

　　一个字段是属于可变的，则整个选项用于计算 ICV 时都要清“0”。

　　整个 AH 头参与 ICV计算，其中完整性校验值字段在计算 ICV 之前置“0”,在计算后，将计算得到的值赋于该字段。

　　整个上层协议数据直接参与 ICV计算。

　　b ) IPv6 中的 ICV计算

　　IPv6 基本头字段、IPv6 扩展头、AH 头和上层协议数据都参与 ICV计算。

　　IPv6 基本头字段中，直接参与计算的字段为：版本(Version)、载荷长度(Payload Length)、下

　　一个头(Next Header)、源地址 ( Source Address)、没有路由扩展头的 目 的地址 ( Destination Address) 。

　　IPv6 基本头字段中，在计算 ICV之前设置为“0 ”的字段为：类别(Class)、流标签(Flow Label) 、跳极限(Hop Limit)。

　　IPv6 的扩展头中，在逐跳(Hop-by-Hop)和 目的扩展头(Destination Extension Headers) 中的IPv6 选项包含有一个比特，该比特指出选项在传送过程期间是否会改变。对于在路由过程中内容可能变换的任何选项，整个“选项数据(Option Data)”字段在计算和校验 ICV 时应被当作零值的字节串对待。选项类型(Option Type)和选项数据长度(Opt Data Len)被包括进 ICV

　　计算。 由比特位确定为不变的所有选项都被包括进 ICV计算。

　　整个 AH 头参与 ICV计算，其中鉴别数据字段在计算 ICV之前置“0”,在计算后，将计算得到的值赋于该字段。

　　整个上层协议数据直接参与 ICV计算。

　　6 . 2 . 1 . 3 . 2 . 5 鉴别数据的填充

　　鉴别数据字段应确保是 4 字节(IPv4)或 8 字节(IPv6)的整数倍，否则需要填充。填充应放在鉴别

　　数据字段的最末端，其内容由发送方任意选择，并且参与 ICV计算。

　　GB/T 36968—2018

　　6 . 2 . 1 . 3 . 2 . 6 分片

　　一个 IPSec 实现在 AH 处理之后，如果发现 IP 数据报文长度超过输出接 口的 MTU 值，则对处理

　　后的数据报文进行分片。

　　6 . 2 . 1 . 3 . 3 入站报文处理

　　6 . 2 . 1 . 3 . 3 . 1 概述

　　入站报文的处理包括重组、查找 SA、验证序列号和验证完整性校验值等过程。

　　6 . 2 . 1 . 3 . 3 . 2 重组

　　如果需要，在 AH 处理之前要进行 IP 数据报文重组。 AH 不处理分片报文，如果提供给 AH 处理的一个报文是一个分片的 IP 数据报文，接收方应丢弃该报文。

　　6 . 2 . 1 . 3 . 3 . 3 查找 SA

　　当收到一个包含 AH 头的报文时，接收方应根据 目 的 IP 地址、AH 和 SPI 来查找 SA,查找失败则丢弃该报文。

　　6 . 2 . 1 . 3 . 3 . 4 验证序列号

　　所有 AH 实现应支持抗重放攻击服务，在 SA建立时，接收方序列号计数器应初始化为 0 。对于每个接收到的报文，接收方应确认报文包含一个序列号，并且该序列号在这个 SA 生命期中不重复，否则应丢弃该报文。

　　如果该序列号超出接收窗口有效检查范围的高端值，则对报文进行完整性校验。 如果校验通过，接收窗口应相应调整;如果校验不通过则丢弃该报文。

　　接收窗口的大小默认为 64 。

　　6 . 2 . 1 . 3 . 3 . 5 验证完整性校验值

　　接收方采用指定的完整性校验算法对报文计算 ICV,计算方法和参与计算的内容与出站报文计算ICV 的一致。 计算的结果与报文中的 ICV 进行比较。 如果一致，则接收到的数据报文是有效的，否则接收方应将收到的数据报文丢弃。

　　6 . 2 . 1 . 3 . 3 . 6 匹配安全策略

　　检查数据包是否符合设置的安全策略要求。

　　6 . 2 . 2 封装安全载荷 ESP

　　6 . 2 . 2 . 1 概述

　　封装安全载荷 ESP 提供了机密性、数据源鉴别、无连接的完整性、抗重放攻击服务和有限信息流量的保护。 当 ESP单独使用时，应同时选择机密性和数据源鉴别服务，当 ESP 和 AH 结合使用时不应选择数据源鉴别服务。

　　6 . 2 . 2 . 2 ESP头

　　6 . 2 . 2 . 2 . 1 ESP头格式

　　ESP 头格式见图 32,其位置紧接在 IPv4、IPv6 或者扩展协议之后，在头中的协议(IPv4)字段或者

　　GB/T 36968—2018

　　下一个头(IPv6、扩展)字段的值是 50。

　　图 32 ESP头格式

　　6 . 2 . 2 . 2 . 2 安全参数索引 SPI

　　安全参数索引 SPI 是一个 4 字节值，它与 目 的 IP地址和安全协议共同标识了这个数据报文的安全联盟。 从 1 至 255 范围内的 SPI 值是保留给将来使用的，0 值保留给本地的特定实现使用并且不能在网络上传送，通信协商得到的 SPI值不能小于 256 。

　　6 . 2 . 2 . 2 . 3 序列号

　　序列号是一个无符号的 4 字节单调递增计数器，发送方对使用该 SA 的每个数据报文进行计数，接收方应检测这个字段来实现 SA 的抗重放攻击服务。 发送方的计数器和接收方的计数器在建立一个SA 时被初始化为 0,该序列号在一个 SA 生存期内不能循环使用，在这个计数器溢出之前，通信的双方应协商出一个新的 SA来使这个字段复位为 0 。

　　6 . 2 . 2 . 2 . 4 载荷数据

　　载荷数据是一个变长的字段，它包含初始化向量 IV 和下一个头字段所描述的数据，其长度单位为字节。

　　IV应置于载荷数据首部。

　　6 . 2 . 2 . 2 . 5 填充字段

　　如果载荷数据的长度不是加密算法的分组长度的整数倍，则需要对不足的部分进行填充，填充以字节为单位。 如果需要，也可以提供更多的填充数据，但应符合加密算法分组长度的要求。

　　填充的方法和内容应由指定的加密算法规定。 如果加密算法没有规定，则附加在报文之后的第 一个字节为 1,后续的填充字节按单调递增的顺序拼凑。

　　6 . 2 . 2 . 2 . 6 填充长度

　　填充长度字段指出了填充字节的个数。 有效值范围是 0 至 255,其中 0 表明没有填充字节。

　　6 . 2 . 2 . 2 . 7 下一个头

　　下一个头是一个 1 字节的字段，该字段指定了 ESP 头后面下一个载荷的类型。 这个字段的值是由

　　Internet分配数字机构(IANA)的最新“分配数字”[STD-2]中定义的 IP 协议数字集合分配的。

　　GB/T 36968—2018

　　6 . 2 . 2 . 2 . 8 鉴别数据

　　鉴别数据是一个变长字段，它是一个完整性校验值 ICV,是对 ESP 报文去掉 ICV 外的其余部分进行完整性校验计算所得的值。 该字段的长度由选择的完整性校验算法决定。 鉴别数据字段是可选的，只有当 SA选择了完整性校验服务时才包含鉴别数据字段。

　　6 .2 .2 .3 封装安全载荷 ESP的处理

　　6 . 2 . 2 . 3 . 1 ESP头的位置

　　ESP 头在传输模式和隧道模式中分别有不同的放置位置。

　　在 IPv4 环境中使用传输模式，ESP 应放在 IP 头和它包含的所有选项之后和上层协议之前，如图

　　33 所示，图中“数据”包含“载荷数据”和“填充”，“ESP尾”包含“填充长度”和“下一个头”字段。

　　图 33 IPv4 的 ESP传输模式

　　在 IPv6 环境中使用传输模式，ESP 被看作是一个端到端的载荷，因而应该出现在逐跳(Hop-by- Hop)、路由(Routing)和分片扩展头(Fragmentation Extensionheaders)之后，如图 34 所示，图中“数据”

　　包含“载荷数据”和“填充”，“ESP尾”包含“填充长度”和“下一个头”字段。

　　图 34 IPv6 的 ESP传输模式

　　在 IPv4 和 IPv6 中使用隧道模式，ESP 保护包括原内部 IP 头在内的整个原 IP 报文，分别如图 35

　　和图 36 所示，图中“数据”包含“载荷数据”和“填充”，“ESP尾”包含“填充长度”和“下一个头”字段。