AH协议与ESP协议简析

2023-11-02

AH

AH可对整个数据包（IP 报头与数据包中的数据负载）提供身份验证、完整性与抗重播保护。但是它不提供保密性，即它不对数据进行加密。数据可以读取，但是禁止修改。AH 使用加密哈希算法签名数据包以求得完整性。

例如，使用计算机 A 的 Alice 将数据发送给使用计算机 B 的 Bob。IP 报头、AH 报头和数据的完整性都得到保护。这意味着 Bob 可以确定确实是 Alice 发送的数据并且数据未被修改。

完整性与身份验证是通过在 IP 报头与 IP 负载之间置入的 AH 报头提供的。

在 IP 报头中使用 IP 协议 ID 51 来标识 AH。AH 可以独立使用，也可以与ESP协议组合使用。

AH报头

AH 报头包含下列字段：

next hdr 下一个报头：使用 IP 协议 ID来标识 IP 负载,。从下图可知，表示被AH协议包含的那一个协议的类型。例如，TCP数据中，传输模式值 6 表示 TCP，隧道模式表示下一个报头为IP报头。

AH len 长度：表示 AH 报头的长度。

Reserved 保留字段

SPI 安全参数索引：与目标地址及安全协议（AH 或 ESP）组合使用，以确保通信的正确安全关联。接收方使用该值确定数据包是使用哪一安全关联标识的。

Sequence Number 序数：为该数据包提供抗重播保护。序数是 32 位、递增的数字（从 1 开始），它表示通过通信的安全关联所发送的数据包数。在快速模式安全关联的生存期内序列号不能重复。接收方将检查该字段，以确认使用该数字的安全关联数据包还没有被接收过。如果一个已经被接收，则数据包被拒绝。

Authentication Data 身份验证数据：包含完整性校验值 (ICV)，也称为消息身份验证码，用于验证消息身份验证与完整性。接收方计算 ICV 值并对照发送方计算的值校验它，以验证完整性。ICV 是通过 IP 报头、AH 报头与 IP 负载来计算的。AH可对整个数据包（IP 报头与数据包中的数据负载）提供身份验证、完整性与抗重播保护。所以不论是传输模式还是隧道模式，AH协议都不能穿越nat设备。

使用 AH 报头进行数据包签名

AH 为了完整性而对整个数据包进行签名，除了在传输过程中可能更改的 IP 报头中的某些字段之外（例如，“生存时间”与“服务类型”字段）。如果除了 AH 外还在使用另一个 IPSec 报头，则会在所有其他 IPSec 报头前插入 AH 报头。

下图中黄色部分表示被AH协议签名保护的部分。

ipsec协议的操作模式

在传输模式下，AH或 ESP被插入到IP头之后但在所有传输层协议之前，或所有其他 IPSec协议之前。

在隧道模式下，AH或 ESP插在原始 IP头之前，另外生成一个新IP头放到 AH或 ESP之前。不同安全协议在传输模式和隧道模式下的数据封装形式（传输协议以 TCP为例）如下图所示：

ESP

IPsec 封装安全负载（IPsec Encapsulating Security Payload）是 IPsec 体系结构中的一种主要协议，其主要设计来在 IPv4 和 IPv6 中提供安全服务的混合应用。IPsec ESP 通过加密需要保护的数据以及在 IPsec ESP 的数据部分放置这些加密的数据来提供机密性和完整性。且ESP加密采用的是对称密钥加密算法，能够提供无连接的数据完整性验证、数据来源验证和抗重放攻击服务。根据用户安全要求，这个机制 既可以用于加密一个传输层的段（如：TCP、UDP、ICMP、IGMP），也可以用于加密一整个的 IP 数据报。封装受保护数据是非常必要的，这样就可以为整个原始数据报提供机密性。

ESP 头可以放置在 IP 头之后、上层协议头之前（传输层），或者在被封装的 IP 头之前（隧道模式）。IANA 分配给 ESP 一个协议数值 50，在 ESP 头前的协议头总是在“next head”字段（IPv6）或“协议”（IPv4）字段里包含该值 50。 ESP 包含一个非加密协议头，后面是加密数据。该加密数据既包括了受保护的 ESP 头字段也包括了受保护的用户数据，这个用户数据可以是整个 IP 数据报，也可以是 IP 的上层协议帧（如：TCP 或 UDP）。

封闭安全载荷ESP包格式

ESP不仅为IP 负载提供身份验证、完整性和抗重播保护，还提供机密性。传输模式中的 ESP 不对整个数据包进行签名。只对IP 负载（而不对IP 报头）进行保护。ESP 可以独立使用，也可与 AH 组合使用。

ESP属于IPSec的一种协议，ESP提供机密性、数据起源验证、无连接的完整性、抗重播服务和有限业务流机密性。ESP本身是一个IP协议，协议号是50。

ESP头

ESP头包含下面一些字段：

SPI 安全参数索引（32位）：这个值，和IP头之前的目标地址以及协议结合在一起，用来标识用于处理数据包的特定的那个安全关联。SPI本身是个任意数，一般是在IKE交换过程中由目标主机选定的。

Sequence Number 序列号（32位）：序列号是一个独一无二的、单向递增的、并由发送端插在ESP头的一个号码。发送方的计数器和接收方的计数器在一个SA建立时被初始化为0，使用给定SA发送的第一个分组的序列号为1，如果激活抗重播服务（默认地），传送的序列号不允许循环。因此，在SA上传送第2³²个分组之前，发送方计数器和接收方计数器必须重新置位（通过建立新SA和获取新密钥），序列号使ESP具有了抵抗重播攻击的能力。

受保护数据（可变）：通过加密保护的传输层协议内容（传输模式）或IP包（隧道模式）。如果受保护数据需要加密同步数据，那么初始化向量IV可以在受保护数据字段的开头携带，并且IV通常不加密，但经常被看作是密文的一部分。

填充（0~255字节）：主要用于加密算法要求明文使某个数目字节的倍数、保证填充长度字段和下一个头字段排列在32位字的右边、提供部分业务流机密性。

填充长度（8位）：指出填充字节的数目。

下一个头（8位）：标识受保护数据的第一个协议头。例如，IPv6中的扩展头或者上层协议标识符。

验证数据（可变）：完整性检查值。验证数据是可变长字段，它包含一个完整性校验值（ICV），ESP分组中该值的计算不包含验证数据本身。字段长度由选择的验证函数指定。验证数据字段是可选的，只有SA选择验证服务，才包含验证数据字段。验证算法规范必须指定ICV长度、验证的比较规则和处理步骤。

ESP 验证尾端（即上面的验证数据）包含下列字段：

身份验证数据：包含完整性校验值 (ICV)，也称为消息身份验证码，用于验证消息身份验证与完整性。接收方计算 ICV 值并对照发送方计算的值校验它，以验证完整性。ICV 是通过 ESP 报头、负载数据与 ESP 尾端计算的。

数据包签名与加密：ESP 可为 IP 负载提供保护。数据包的签名部分表示数据包的完整性和身份验证签名是在哪里进行的。数据包的加密部分表示什么信息受到机密性保护。

ESP在传输模式时会保护TCP/UDP头，但是并不保护IP 头，因此修改IP 地址并不会破坏整个数据包的完整性。但是如果数据包是TCP/UDP数据包，NAT设备就需要修改数据包的校验值，而这个校验值是被ESP 所保护的，这样却会导致完整性校验失败。所以ESP在传输模式不能用于NAT穿越。

ESP在隧道模式下， NAT会修改新增的IP头，新增IP协议的数据时ESP，就不需要想TCP/UDP一样修改ESP的验证，所以最终能和NAT一起工作的只能是隧道模式下的ESP。

封闭安全协议处理

传输模式与通道模式下受ESP保护的一个IP包。见下图。

由于ESP同时提供了机密性以及身份验证机制，所以在其SA中必须同时定义两套算法用来确保机密性的算法叫作一个cipher（加密器），ESP使用对称加密算法。负责身份验证的叫作authenticator（验证器），验证算法包括基于对称加密算法（例如DES）的或者基于单向散列函数（例如MD5或SHA-1）的消息鉴别码（MAC）。注意因为加密、验证是可选的，算法可以为“NULL”。

（1）外出分组的处理。

对在IPv4上运行的传送模式应用来说，ESP头紧跟IP头，IP头的协议字段被复制到ESP头的下一个头字段中，ESP头的其余字段则被填满。SPI字段分配到的是来自SAD的、用来对这个包进行处理的特定SA的SPI；填充序列号字段的是序列中的下一个值；填充数据会被插入，其值被分配；同时分配的还有填充长度值。随后，IP头的协议字段得到的是ESP的值50。

除了头插入位置不同之外，IPv6处理规则基本上类似于IPv4。ESP头可插在任意一个扩展头之后。对通道模式应用来说，ESP头是加在IP包前面的。如果封装的是一个IPv4包，那么ESP头的下一个头字段分配到值4；如果封装的是一个IPv6包，则分配到值41。其他字段的填充方式和在传送模式中一样。随后，在ESP头的前面新增了一个IP头，并对相应的字段进行填充（赋值）—源地址对应于应用ESP的那个设备本身；目标地址取自于用来应用ESP的SA；协议设为50；其他字段的值则参照本地的IP处理加以填充。

不管哪种模式下，接下去的步骤都是相同的。从恰当的SA中选择加密器（加密算法），对包进行加密（从载荷数据的开头，一直到下一个头字段）。随后，使用恰当的SA中的验证器，对包进行验证（自ESP头开始，中间经过加密的密文，一直到ESP尾）。随后，将验证器的结果插入ESP尾的验证数据字段中。

对外出数据包进行处理的最后一步是：重新计算位于ESP前面的IP头的校验和。

注意在添加ESP头时，不必进行分段检查。如果结果包（在已采用ESP之后）大于它流经的那个接口的MTU，只好对它进行分段。这和一个完整的ESP包离开该设备，并在网络中的某个地方被分成段没有什么区别。

（2）进入分组的处理

接收端在收到一个ESP包之后，若不对这个包进行处理，就无法得知它究竟处于通道模式，还是传送模式。根据对这个包进行处理的SA，便可知道它到底处在什么模式下。但除非完成了对它的解密，实际上不可能知道ESP保护的是什么。

如果收到的IPSec包是一个分段，必须把它保留下来，直到这个包的其他部分收完为止。即在ESP处理之前进行重组。

收到一个（已重组的）包含ESP头的包时，根据目的IP地址、安全协议（ESP）和SPI，接收方确定适当的SA。SA指出序列号字段是否被校验，验证数据字段是否存在，它将指定解密和ICV计算（如果适用）使用的算法和密钥。如果本次会话没有有效的SA存在（例如接收方没有密钥），接收方必须丢弃分组；这是可审核事件。该事件的核查日志表项应该包含SPI的值、接收的日期/时间、源地址、目的地址、序列号和（IPv6）明文信息流ID。

一旦验证通过了一个有效的SA，就可用它开始包的处理。

检查序列号：如果接收的包落入窗口内且是新的，或者包落在窗口的右边，那么接收方进行ICV确认。

完整性校验值确认：如果选择验证，接收方采用指定的验证算法对ESP包计算ICV但不包含验证数据字段，确认它与验证数据字段中包含的ICV相同。如果计算得来的与接收的ICV匹配，那么数据包有效，可以被接收。如果测试失败，接收方必须作为非法而将接收的IP数据包丢弃；这是可审核事件。

分组解密：通过取自SA的密钥和密码算法，对ESP包进行解密，从这个ESP包载荷数据开始之处到下一个头之间。

本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)

ipsec与openswan