如前所述，规范于RFC 2402的AH是IPSec的两种安全协议之一，能够提供数据的完整性校验和源验证功能，同时也能提供一些有限的抗重播服务。
AH不能提供数据加密功能，因此不能保证机密性。
1.AH头格式
紧贴在AH头之前的IP头，以协议号51标识AH头。例如对IPV4来说，其protocol字段值将为51。而对IPV6来说，其Next Header字段值将为51。
其中各字段含义如下：
（1）Next Header 长度为8位。用于指示AH头后面的载荷协议头类型。该字段值属于IANA定义的IP协议号集合。
（2）Payload Length 长度为8位。用于指示AH的长度减少2，单位是“32位”。这是因为AH也是一个IPV6扩展头，而据RFC2460规定，所有IPV6扩展头必须把负载长度值减去一个“64位”。
（3）Reserved 长度16位，为将来的应用保留。目前必须设置为0。
（4）Security Parameters Indes（SPI） SPI是一个长度32位的任意数值。SPI与目的IP地址和安全协议标识（AH／ESP）结合，可以唯一地标识一个SA。
（5）Sequence Number 一个32位无符号整型数值。在一个SA刚刚建立时，此数值被初始化为0，并随数据包的发送而递增，即使不执行抗重播服务，发送方仍然建发送序列号。接收方可以利用此数值确认一系列数据包的正确序列。
Authentication Data包含了这个数据包的完整性校验值（integrity check value，ICV）。这个字段是变长的。但必须为32位的整数倍。为了兼容性考虑，AH强制实现HMACMD5 -96和HMAC-SHA -1 -96两种验证算法。
AH使用HMAC算法计算Authentication Data数值。为了确保包括IP头、AH头和载荷在内的整个包的完整性和正确来源，AH的HMAC以IP头、AH头、软件以及共享密钥作为算法的输入，并将其ICV埋入Authentication Data字段。
由于在转发过程中，IP头的一些部分会变化（如ToS，Flags，Fragment Offset，TTL，Header Checksum等），因此在计算ICV的之前，必从把这终字段设置成0，Authentication Data字段本身也加入了ICV计算，所以在计算时，这个字段的位设置为0。
2.AH封装
在传输模式中，AH保护了整个原始IP包。两个需要通信的终端计算机在彼此之间直接运行IPSec协议，通信连接的端点就是IPSec协议的端点，中间设备不做出任何IPSec处理。(www.xing528.com)
在建立好AH头并填充了各个字段之后，AH头被插入原始IP头和原始载荷之间。传输模式AH封装如图5.64所示。
图5.64 传输模式AH封装
而在隧道模式中，AH保护的是整个新IP包。整个原始IP包将会以AH载荷的方式加入新建的隧道数据包。同时，系统根据隧道起点和终点等参数，建立一个隧道IP头，作为隧道数据包的IP头。AH头夹在隧道IP头和原始IP之间。隧道模式AH封装如图5.65所示。
图5.65 隧道模式AH封装
3.AH处理机制
AH的处理流程如下：
（1）出站包处理 当系统通过SPD了解到一个IP包要获得AH服务时，就开始寻找一个相应的SA。如果这个SA不存在，就呼叫IKE建立一个SA；如果这个SA存在，就利用这个SA提供AH安全服务。
系统首先把IP包头中的可变字段修改为0，并把AH头的Authentication Data字段置0，然后把IP包头、载荷、AH头以及密钥输入HMAC单向散列算法，得到ICV数值。如果这个数值不符合32位的整数倍，还要进行填充，并且填充也必须加入ICV的计算。
计算完成后，根据相应的工作模式，封闭好数据包，就可以发送出去了。
（2）入站包处理 IPSec包在网络上传输时，可能遭到分段。因此，有必要首先重组被分段的数据包。
接收方根据入站IP包的目的IP地址、安全协议类型（AH）和SPI查找SA。如果没有SA，就丢弃之；如果有SA，就可以了解到所使用的算法，以及是否验证序列号，并根据这些信息做相应处理。如果需要验证序列号，就进行序列号的核查。
首先把IP头的可变字段清零，并把Authentication Data消零，重新计算ICV。如果结果与收到的ICV相等，则验证通过，反之则丢弃该数据包。
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
