IPsec不同安全协议的报文封装结构对比
发布时间:2021-07-21 17:04:57作者:铁军哥阅读:0
传输模式 SA 是两个主机之间的安全联盟。在 ESP 的情况下,传输模式 SA 仅为这些更高层协议提供安全服务,而不是为 IP 标头或 ESP 标头之前的任何扩展标头提供安全服务。在 AH 的情况下,保护还扩展到 IP 标头的选定部分、扩展标头的选定部分和选定的选项。
隧道模式SA本质上是应用于IP隧道的SA。每当SA的任一端是安全网关时,SA 必须是隧道模式。因此,两个安全网关之间的 SA 始终是隧道模式 SA,主机和安全网关之间的 SA 也是如此。
对于隧道模式 SA,有一个“外部”IP 标头指定 IPsec 处理目的地,加上一个“内部”IP 标头,指定数据包的(表面)最终目的地。安全协议头出现在外部 IP 头之后,内部 IP 头之前。如果在隧道模式下使用 AH,则外部 IP 报头的部分将受到保护(如上所述),以及所有隧道传输的 IP 数据包(即,所有内部 IP 报头都受到保护,以及更高层协议)。如果采用 ESP,则仅对隧道数据包提供保护,而不对外部报头提供保护。
总之,主机必须同时支持传输和隧道模式;要求安全网关仅支持隧道模式,如果安全网关支持传输模式,则应仅在安全网关充当主机时使用。
组网图
采用和第一次实验(IPsec小实验:手工方式建立保护IPv4报文的IPsec-ESP隧道)相同的组网图。
设备配置
IPsec这个实验我是在H3C模拟器HCL中做的,主要配置任务包括以下几点:
1、配置IPsec保护的数据流量。一般也称为感兴趣流,用ACL来进行匹配;
2、配置IPsec安全提议。指定对IP报文的封装形式为传输模式或隧道模式,选择安全协议为AH或ESP或AH-ESP,并配置与之对应的加密算法及认证算法;
3、配置IPsec安全策略。包含配置应用感兴趣流,应用IPsec安全提议,指定IPsec隧道地址,配置安全协议的SPI(Security Parameter Index,安全参数索引)和SA(Security Association,安全联盟)密钥;
4、在接口上应用IPsec安全策略。
所以,今天,我们将主要通过调整安全协议、加密算法和认证算法来验证一下。
IPsec安全提议支持的安全协议有AH、ESP和AH-ESP,相关协议介绍请参照相关RFC文档,不同安全协议的数据封装格式如下图所示:
HCL模拟器支持的安全协议:
缺省情况下,采用ESP安全协议,那就延用上个实验的环境,先测一下ESP安全协议。
使用ESP安全协议的报文结构
已知使用ESP封装的报文,MTU值为1400字节。从RFC2406我们得知,ESP封装报文头格式如下:
虽然抓包的可读性比较差,但还是要做一下分析。
将标准的封装格式和实际报文进行对比,可以得出:
1、SPI字段长度为4字节;
2、序列号字段长度为4字节;
3、加密填充内容字段长度可变,长度为0-255字节;
4、填充长度字段长度为1字节;
5、下一个头部字段长度为1字节;
6、认证数据字段长度可变,并且是可选的。
所以上面1和2为ESP头,3-6位ESP-T(校验尾),初步推算ESP-T长度为44字节。
所以使用ESP封装的完整报文结构如下图所示:
使用AH安全协议的报文结构
修改安全协议在IPsec的安全提议transform-set中,重新配置安全协议为AH。并在IPsec策略中修改SA的SPI和密钥。
#
ipsec transform-set tran1
protocol ah
ah authentication-algorithm sha1
#
ipsec policy ipsec 10 manual
sa spi inbound ah 123321
sa string-key inbound ah simple 123321
sa spi outbound ah 123321
sa string-key outbound ah simple 123321
查看SA信息,发现协议已经是AH了,并且没有加密算法。
测试封装后的MTU为1428字节。
抓包进行分析,发现仅仅是在原始报文头部加了一个认证头,没有对报文进行加密,原始报文数据一目了然。
对比RFC2402中的报文结构,AH头部封装和协议中完全一致。RFC2402中AH ICV字段为可变长度,此处该字段长度为12字节。
所以使用ESP封装的完整报文结构如下图所示:
组合使用AH-ESP安全协议的报文结构
再从IPsec的安全提议transform-set中,配置安全协议为AH-ESP。并在IPsec策略中添加SA的SPI和密钥。需要注意,AH和ESP的SPI值不能重复,否则无法配置。
#
ipsec transform-set tran1
esp encryption-algorithm aes-cbc-128
esp authentication-algorithm sha1
#
ipsec policy ipsec 10 manual
sa spi inbound ah 123321
sa spi inbound esp 321123
sa string-key inbound ah simple 123321
sa string-key inbound esp simple 123321
sa spi outbound ah 123321
sa spi outbound esp 321123
sa string-key outbound ah simple 123321
sa string-key outbound esp simple 123321
查看SA信息,能发现SA中同时包含AH和ESP,加密算法和认证算法均有体现。
测得封装后的链路MTU为1376字节。
抓包进行分析,发现报文封装结构和之前学习的一样,先封装ESP,再加一个AH认证头。
所以组合使用AH和ESP封装的完整报文结构如下图所示:
修改ESP加密算法
验证完了安全协议,那加密算法会不会对报文封装有影响呢?
这个验证还是比较简单的,仅需要在IPsec安全提议transform-set中修改加密算法即可,此处将原来的aes-cbc-128算法修改为aes-ctr-256。
#
ipsec transform-set tran1
protocol ah-esp
esp encryption-algorithm aes-ctr-256
esp authentication-algorithm sha1
ah authentication-algorithm sha1
修改之后查看SA信息,验证加密算法修改成功。
测试修改加密算法之后的MTU值为1384字节,比使用aes-cbc-128的1376字节增加8字节。
总结
1、使用不同安全协议的报文封装结构如下图所示:
2、使用的加密算法和认证算法在SA中均可查看;
3、ESP使用的加密算法不同,ESP校验尾部填充报文长度不同;
4、同时使用AH和ESP封装时,需要在IPsec策略中分别配置SA的AH-SPI值和ESP-SPI值,并且两个值不可以相同。
填坑成功,具体不同算法检验长度分别是多少,有待各位去验证了,方法已经告诉你们了
以上就是
IPsec不同安全协议的报文封装结构对比
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:shawn.lee@vecloud.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。
标题:IPsec不同安全协议的报文封装结构对比
TAG标签:
地址:http://www.vecloud.com.cn/article/315.html