IPsec VPN协议框架

IPsec是IETF(Internet Engineering Task Force)制定的一组开放的网络安全协议。它并不是一个单独的协议,而是一系列为IP网络提供安全性的协议和服务的集合,包括认证头AH(Authentication Header)和封装安全载荷ESP(Encapsulating Security Payload)两个安全协议、密钥交换和用于验证及加密的一些算法等。

IPsec框架如下所示:

通过这些协议,在两个设备之间建立一条IPSec隧道。数据通过IPSec隧道进行转发,实现保护数据的安全性。从以下几个方面保障了用户业务数据在Internet中的安全传输:

数据真实性:接收方验证发送方身份是否合法。

数据机密性:发送方对数据进行加密,以密文的形式在Internet上传送,接收方对接收的加密数据进行解密后处理或直接转发。

数据完整性:接收方对接收的数据进行验证,以判定报文是否被篡改。

防重放:接收方拒绝旧的或重复的数据包,防止恶意用户通过重复发送捕获到的数据包所进行的攻击。

一、安全协议

IPSec使用认证头AH和封装安全载荷ESP两种安全协议来传输和封装数据,提供认证或加密等安全服务。

AH是报文头验证协议,主要提供的功能有数据源验证、数据完整性校验和防报文重放功能;然而,AH并不加密所保护的数据报文。AH协议对数据包以及认证密钥进行HASH计算,接收方接收带有计算结果的数据包后采用同样的HASH对原有数据进行计算,比较前后HASH结果,若一致则保证了数据来源认证和完整性校验,AH协议的数据完整性校验范围为整个IP报文。

ESP协议是封装安全载荷协议,主要提供的功能有加密、数据源验证、数据完整性校验和防报文重放功能。与AH不同的是,ESP协议将数据中有效载荷进行加密后再封装到数据包中,以保证数据机密性,但ESP没有对IP报文头内容进行保护,除非采用了隧道模式。

安全特性

AHESP

协议号

51

50

数据完整性校验

支持(验证整个IP报文)

支持(传输模式不验证IP头,隧道模式验证整个IP报文)

数据源验证

支持

支持

数据加密

不支持

支持

防报文重放攻击

支持

支持

IPSec NAT-T(NAT穿越)

不支持

支持

二、封装模式

1、传输模式

在传输模式下,AH头或ESP头被插入到IP头与传输层协议头之间,保护TCP/UDP/ICMP负载。由于传输模式未添加额外的IP头,所以原始报文中的IP地址在加密后报文的IP头中可见。

传输模式不改变报文头,故隧道的源和目的地址必须与IP报文头中的源和目的地址一致,所以只适合两台主机或一台主机和一台VPN网关之间通信。

2、隧道模式

隧道模式下,AH头或ESP头被插到原始IP头之前,另外生成一个新的报文头放到AH头或ESP头之前,保护IP头和负载。

隧道模式隐藏了原始IP报文头,采用了新的报文头,新报文头中的源地址、目的地址为隧道两端的公网IP地址,所以适用于两台VPN网关之间或一台主机与一台VPN网关之间的通信。

在隧道模式下,AH协议的完整性验证范围为包括新增IP头在内的整个IP报文。ESP协议验证报文的完整性检查部分包括ESP头、原IP头、传输层协议头、数据和ESP报尾但不包括新IP头,因此ESP协议无法保证新IP头的安全。ESP的加密部分包括原IP头传输层协议头、数据和ESP报尾。

3、传输模式和隧道模式比较

在安全性方面,隧道模式优于传输模式,隧道模式可以完全对原始IP数据包进行验证和加密,隧道模式可以隐藏内部IP地址以及协议类型端口等;

在性能方面,隧道模式由于有一个额外的报文头部,因此比传输模式要占用更多带宽;

在应用场景方面,传输模式主要用于两台主机或一台主机和一台VPN网关之间通信,隧道模式主要用于两台VPN网关之间或一台主机与一台VPN网关之间的通信。

三、加密和验证算法

IPsec为了保证数据传输的安全性,对数据进行了加密以及验证,加密可以保证数据的机密性,防止被窃取,验证可以保证数据的真实性,防止数据被篡改或仿冒。

1、加密

发送方采用加密算法和加密密钥对原始数据进行加密封装,接收方收到报文,使用相同的加密算法和加密密钥将报文逆向恢复,即解密。

对称密钥可以手工配置或者通过DH密钥交换算法生成,并在两端设备共享。

IPsec使用ESP协议对IP报文内容进行加密,主要包括DES、3DES、AES、SM4,其中DES、3DES安全性低,存在安全风险,不推荐使用。

对比项DES3DESAESSM4
密钥长度56位168位128、192、256位128位
安全级别

2、验证

IPsec通过HMAC功能,通过比较ICV验证数据包完整性和真实性。加密与验证通常是配合使用。

发送方将加密后的报文通过验证算法和对称密钥生成ICV,IP报文和ICV一起发给接收方,接收方将两者分离,通过一样的验证算法和对称密钥对加密报文进行处理,同样得到ICV,对比两个ICV是否相符,若相符则验证通过,否则丢弃。

验证的对称加密密钥可以手动配置,也可以通过DH算法生成并在两端设备共享。

常用的验证算法有MD5、SHA、SM3,其中MD5、SHA1安全性低,存在安全风险,不推荐使用。

对比项MD5SHA1SHA2SM3
签名长度128位160位

SHA2-256:256位

SHA2-384:384位

SHA2-512:512位

256位
安全级别

四、密钥交换

1、密钥交换方式

1.1、带外共享密钥

在IPsec两方手工配置静态的加密和验证密钥,双方通过带外共享方式(例如电话邮件方式)保证密钥的一致性,缺点是安全性低、可扩展性差,在点到多点组网中工作量大,为了提升网络安全性,还需周期更换密钥,工作量更复杂。

1.2、使用一个安全的连接分发密钥

通过IKE协议自动协商密钥。IKE采用DH算法在不安全的网络上安全地分发密钥。这种方式配置简单,可扩展性好,特别是在大型动态的网络环境下此优点更加突出。同时,通信双方通过交换密钥交换材料来计算共享的密钥,即使第三方截获了双方用于计算密钥的所有交换数据,也无法计算出真正的密钥。

2、IKE协议

IKE协议建立在ISAKMP(Internet Security Association and Key Management Protocol)定义框架上,是基于UDP的应用层协议。它为IPSec提供了自动协商密钥、建立IPSec安全联盟的服务,能够简化IPSec的使用和管理,大大简化IPSec的配置和维护工作。

IKE协议最厉害的地方莫过于其永远不会在不安全的网络上传送密钥,而是通过交换数据,双方再计算出共享密钥,核心计算是DH交换技术,即使被截获了交换数据也无法计算出来真正的密钥。

3、DH密钥交换

DH算法用于产生密钥材料,通信双方交换密钥材料,各自计算出完全相同的对称密钥,用于加密和验证,任何时候,不交换真正的密钥。

DH算法是用于密钥交换,而不是对IP报文加密解密。


参考资料:防火墙和VPN技术与实践——李学昭

  • 15
    点赞
  • 20
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值