华为IPsec vpn
源随着Internet的发展，越来越多的企业直接通过Internet进行互联，但由于IP协议未考虑安全性，而且Internet上有大量的不可靠用户和网络设备，所以用户业务数据要穿越这些未知网络，根本无法保证数据的安全性，数据易被伪造、篡改或窃取。因此，迫切需要一种兼容IP协议的通用的网络安全方案。
为了解决上述问题，IPSec（Internet Protocol Security）应运而生。IPSec是对IP的安全性补充，其工作在IP层，为IP网络通信提供透明的安全服务。
定义
IPSec是IETF（Internet Engineering Task Force）制定的一组开放的网络安全协议。它并不是一个单独的协议，而是一系列为IP网络提供安全性的协议和服务的集合，包括认证头AH（Authentication Header）和封装安全载荷ESP（Encapsulating Security Payload）两个安全协议、密钥交换和用于验证及加密的一些算法等。
通过这些协议，在两个设备之间建立一条IPSec隧道。数据通过IPSec隧道进行转发，实现保护数据的安全性。
受益
IPSec通过加密与验证等方式，从以下几个方面保障了用户业务数据在Internet中的安全传输：
[*]数据来源验证：接收方验证发送方身份是否合法。
[*]数据加密：发送方对数据进行加密，以密文的形式在Internet上传送，接收方对接收的加密数据进行解密后处理或直接转发。
[*]数据完整性：接收方对接收的数据进行验证，以判定报文是否被篡改。
[*]抗重放：接收方拒绝旧的或重复的数据包，防止恶意用户通过重复发送捕获到的数据包所进行的攻击。
IPSec协议框架
安全联盟
安全联盟SA（Security Association）是通信对等体间对某些要素的协定，它描述了对等体间如何利用安全服务（例如加密）进行安全的通信。这些要素包括对等体间使用何种安全协议、需要保护的数据流特征、对等体间传输的数据的封装模式、协议采用的加密和验证算法，以及用于数据安全转换、传输的密钥和SA的生存周期等。
IPSec安全传输数据的前提是在IPSec对等体（即运行IPSec协议的两个端点）之间成功建立安全联盟。IPSec安全联盟简称IPSec SA，由一个三元组来唯一标识，这个三元组包括安全参数索引SPI（Security Parameter Index）、目的IP地址和使用的安全协议号（AH或ESP）。其中，SPI是为唯一标识SA而生成的一个32位比特的数值，它被封装在AH和ESP头中。
IPSec SA是单向的逻辑连接，通常成对建立（Inbound和Outbound）。因此两个IPSec对等体之间的双向通信，最少需要建立一对IPSec SA形成一个安全互通的IPSec隧道，分别对两个方向的数据流进行安全保护，如图22-13所示。
图22-13 IPSec安全联盟
另外，IPSec SA的个数还与安全协议相关。如果只使用AH或ESP来保护两个对等体之间的流量，则对等体之间就有两个SA，每个方向上一个。如果对等体同时使用了AH和ESP，那么对等体之间就需要四个SA，每个方向上两个，分别对应AH和ESP。
建立IPSec SA有两种方式：手工方式和IKE方式。二者的主要差异如表22-5所示。
表22-5 手工和IKE方式的差异对比项
手工方式建立IPSec SA
IKE方式自动建立IPSec SA
加密/验证密钥配置和刷新方式
手工配置、刷新，而且易出错
密钥管理成本很高
密钥通过DH算法生成、动态刷新
密钥管理成本低
SPI取值
手工配置
随机生成
生存周期
无生存周期限制，SA永久存在
由双方的生存周期参数控制，SA动态刷新
安全性
低
高
适用场景
小型网络
小型、中大型网络
安全协议
IPSec使用认证头AH（Authentication Header）和封装安全载荷ESP（Encapsulating Security Payload）两种IP传输层协议来提供认证或加密等安全服务。
[*]AH协议
AH仅支持认证功能，不支持加密功能。AH在每一个数据包的标准IP报头后面添加一个AH报文头，如封装模式所示。AH对数据包和认证密钥进行Hash计算，接收方收到带有计算结果的数据包后，执行同样的Hash计算并与原计算结果比较，传输过程中对数据的任何更改将使计算结果无效，这样就提供了数据来源认证和数据完整性校验。AH协议的完整性验证范围为整个IP报文。
[*]ESP协议
ESP支持认证和加密功能。ESP在每一个数据包的标准IP报头后面添加一个ESP报文头，并在数据包后面追加一个ESP尾（ESP Trailer和ESP Auth data），如封装模式所示。与AH不同的是，ESP将数据中的有效载荷进行加密后再封装到数据包中，以保证数据的机密性，但ESP没有对IP头的内容进行保护，除非IP头被封装在ESP内部（采用隧道模式）。
AH和ESP协议的简单比较如表22-6所示。
表22-6 AH协议与ESP协议比较安全特性
AH
ESP
协议号
51
50
数据完整性校验
支持（验证整个IP报文）
支持（传输模式：不验证IP头，隧道模式：验证整个IP报文）
数据源验证
支持
支持
数据加密
不支持
支持
防报文重放攻击
支持
支持
IPSec NAT-T（NAT穿越）
不支持
支持
从表中可以看出两个协议各有优缺点，在安全性要求较高的场景中可以考虑联合使用AH协议和ESP协议。
报文头结构
AH报文头结构
AH报文头结构如图22-14所示；AH报文头字段含义如表22-7所示。
图22-14 AH报文头结构
表22-7 AH报文头字段含义字段
长度
含义
下一头部
8比特
标识AH报文头后面的负载类型。传输模式下，是被保护的上层协议（TCP或UDP）或ESP协议的编号；隧道模式下，是IP协议或ESP协议的编号。
说明：当AH与ESP协议同时使用时，AH报文头的下一头部为ESP报文头。
负载长度
8比特
表示以32比特为单位的AH报文头长度减2，缺省为4。
保留字段
16比特
保留将来使用，缺省为0。
SPI
32比特
IPSec安全参数索引，用于唯一标识IPSec安全联盟。
序列号
32比特
是一个从1开始的单项递增的计数器，唯一地标识每一个数据包，用于防止重放攻击。
认证数据
一个变长字段，长度为32比特的整数倍，通常为96比特。
该字段包含数据完整性校验值 ICV（Integrity Check Value），用于接收方进行完整性校验。可选择的认证算法有MD5、SHA1、SHA2。
说明：MD5和SHA1验证算法存在安全隐患，建议优先使用SHA2算法。
ESP报文头结构
ESP报文头结构如图22-15所示；ESP报文头字段含义如表22-8所示。
图22-15 ESP报文头结构
表22-8 ESP报文头字段含义字段
长度
含义
SPI
32比特
IPSec安全参数索引，用于唯一标识IPSec安全联盟。
序列号
32比特
是一个从1开始的单项递增的计数器，唯一地标识每一个数据包，用于防止重放攻击。
负载数据
—
包含原始IP报文中可变长度数据内容。ESP保护的内容类型由下一头部字段标识。
填充字段
—
用于增加ESP报文头的位数。填充字段的长度与负载数据的长度和算法有关。当待加密报文的长度不是加密算法所要求的块长度时，需要进行填充补齐。
填充长度
8比特
给出前面填充字段的长度，置0时表示没有填充。
下一头部
8比特
标识ESP报文头后面的下一个负载类型。传输模式下，是被保护的上层协议（TCP或UDP）的编号；隧道模式下，是IP协议的编号。
认证数据
一个变长字段，长度为32比特的整数倍，通常为96比特。
该字段包含数据完整性校验值ICV，用于接收方进行完整性校验。可选择的认证算法与AH的相同。
ESP的验证功能是可选的，如果启动了数据包验证，会在加密数据的尾部添加一个ICV数值。
封装模式
封装模式是指将AH或ESP相关的字段插入到原始IP报文中，以实现对报文的认证和加密，封装模式有传输模式和隧道模式两种。
传输模式
在传输模式中，AH头或ESP头被插入到IP头与传输层协议头之间，保护TCP/UDP/ICMP负载。由于传输模式未添加额外的IP头，所以原始报文中的IP地址在加密后报文的IP头中可见。以TCP报文为例，原始报文经过传输模式封装后，报文格式如图22-16所示。
图22-16 传输模式下报文封装
传输模式下，与AH协议相比，ESP协议的完整性验证范围不包括IP头，无法保证IP头的安全。
隧道模式
在隧道模式下，AH头或ESP头被插到原始IP头之前，另外生成一个新的报文头放到AH头或ESP头之前，保护IP头和负载。以TCP报文为例，原始报文经隧道模式封装后的报文结构如图22-17所示。
图22-17 隧道模式下报文封装
隧道模式下，与AH协议相比，ESP协议的完整性验证范围不包括新IP头，无法保证新IP头的安全。
传输模式和隧道模式比较
传输模式和隧道模式的区别在于：
[*]从安全性来讲，隧道模式优于传输模式。它可以完全地对原始IP数据报进行验证和加密。隧道模式下可以隐藏内部IP地址，协议类型和端口。
[*]从性能来讲，隧道模式因为有一个额外的IP头，所以它将比传输模式占用更多带宽。
[*]从场景来讲，传输模式主要应用于两台主机或一台主机和一台VPN网关之间通信；隧道模式主要应用于两台VPN网关之间或一台主机与一台VPN网关之间的通信。
当安全协议同时采用AH和ESP时，AH和ESP协议必须采用相同的封装模式。
加密和验证
IPSec提供了两种安全机制：加密和验证。加密机制保证数据的机密性，防止数据在传输过程中被窃听；验证机制能保证数据真实可靠，防止数据在传输过程中被仿冒和篡改。
加密
IPSec采用对称加密算法对数据进行加密和解密。如图22-18所示，数据发送方和接收方使用相同的密钥进行加密、解密。
图22-18 加密和解密的过程
用于加密和解密的对称密钥可以手工配置，也可以通过IKE协议自动协商生成。
常用的对称加密算法包括：数据加密标准DES（Data Encryption Standard）、3DES（Triple Data Encryption Standard）、先进加密标准AES（Advanced Encryption Standard）。其中，DES和3DES算法安全性低，存在安全风险，不推荐使用。
验证
IPSec的加密功能，无法验证解密后的信息是否是原始发送的信息或完整。IPSec采用HMAC（Keyed-Hash Message Authentication Code）功能，比较完整性校验值ICV进行数据包完整性和真实性验证。
通常情况下，加密和验证通常配合使用。如图22-19所示，在IPSec发送方，加密后的报文通过验证算法和对称密钥生成完整性校验值ICV，IP报文和完整性校验值ICV同时发给对端；在IPSec接收方，使用相同的验证算法和对称密钥对加密报文进行处理，同样得到完整性校验值ICV，然后比较完整性校验值ICV进行数据完整性和真实性验证，验证不通过的报文直接丢弃，验证通过的报文再进行解密。
图22-19 验证过程
同加密一样，用于验证的对称密钥也可以手工配置，或者通过IKE协议自动协商生成。
常用的验证算法包括：消息摘要MD5（Message Digest 5）、安全散列算法SHA1（Secure Hash Algorithm 1）、SHA2。其中，MD5、SHA1算法安全性低，存在安全风险，不推荐使用。
密钥交换
使用对称密钥进行加密、验证时，如何安全地共享密钥是一个很重要的问题。有两种方法解决这个问题：
[*]带外共享密钥
在发送、接收设备上手工配置静态的加密、验证密钥。双方通过带外共享的方式（例如通过电话或邮件方式）保证密钥一致性。这种方式的缺点是安全性低，可扩展性差，在点到多点组网中配置密钥的工作量成倍增加。另外，为提升网络安全性需要周期性修改密钥，这种方式下也很难实施。
[*]使用一个安全的密钥分发协议
通过IKE协议自动协商密钥。IKE采用DH（Diffie-Hellman）算法在不安全的网络上安全地分发密钥。这种方式配置简单，可扩展性好，特别是在大型动态的网络环境下此优点更加突出。同时，通信双方通过交换密钥交换材料来计算共享的密钥，即使第三方截获了双方用于计算密钥的所有交换数据，也无法计算出真正的密钥，这样极大地提高了安全性。
IKE协议
因特网密钥交换IKE（Internet Key Exchange）协议建立在Internet安全联盟和密钥管理协议ISAKMP定义的框架上，是基于UDP（User Datagram Protocol）的应用层协议。它为IPSec提供了自动协商密钥、建立IPSec安全联盟的服务，能够简化IPSec的配置和维护工作。
IKE与IPSec的关系如图22-20所示，对等体之间建立一个IKE SA完成身份验证和密钥信息交换后，在IKE SA的保护下，根据配置的AH/ESP安全协议等参数协商出一对IPSec SA。此后，对等体间的数据将在IPSec隧道中加密传输。
IKE SA是一个双向的逻辑连接，两个对等体间只建立一个IKE SA。
图22-20 IKE与IPSec的关系图
IKE安全机制
IKE具有一套自保护机制，可以在网络上安全地认证身份、分发密钥、建立IPSec SA：
[*]身份认证
身份认证确认通信双方的身份（对等体的IP地址或名称），包括预共享密钥PSK（pre-shared key）认证、数字证书RSA（rsa-signature）认证。
[*]在预共享密钥认证中，通信双方采用共享的密钥对报文进行Hash计算，判断双方的计算结果是否相同。如果相同，则认证通过；否则认证失败。
当有1个对等体对应多个对等体时，需要为每个对等体配置预共享的密钥。该方法在小型网络中容易建立，但安全性较低。
[*]在数字证书认证中，通信双方使用CA证书进行数字证书合法性验证，双方各有自己的公钥（网络上传输）和私钥（自己持有）。发送方对原始报文进行Hash计算，并用自己的私钥对报文计算结果进行加密，生成数字签名。接收方使用发送方的公钥对数字签名进行解密，并对报文进行Hash计算，判断计算结果与解密后的结果是否相同。如果相同，则认证通过；否则认证失败。
使用数字证书安全性高，但需要CA来颁发数字证书，适合在大型网络中使用。
IKE支持的认证算法有：MD5、SHA1、SHA2-256、SHA2-384、SHA2-512。
[*]身份保护
身份数据在密钥产生之后加密传送，实现了对身份数据的保护。
IKE支持的加密算法有：DES、3DES、AES-128、AES-192、AES-256
[*]DH
DH是一种公共密钥交换方法，它用于产生密钥材料，并通过ISAKMP消息在发送和接收设备之间进行密钥材料交换。然后，两端设备各自计算出完全相同的对称密钥。该对称密钥用于计算加密和验证的密钥。在任何时候，通信双方都不交换真正的密钥。DH密钥交换是IKE的精髓所在。
[*]PFS
完善的前向安全性PFS（Perfect Forward Secrecy）通过执行一次额外的DH交换，确保即使IKE SA中使用的密钥被泄露，IPSec SA中使用的密钥也不会受到损害。
[*]MD5和SHA1认证算法不安全，建议使用SHA2-256、SHA2-384、SHA2-512算法。
[*]DES和3DES加密算法不安全，建议使用AES算法。
IKE版本
IKE协议分IKEv1和IKEv2两个版本。IKEv2与IKEv1相比有以下优点：
[*]简化了安全联盟的协商过程，提高了协商效率。
IKEv1使用两个阶段为IPSec进行密钥协商并建立IPSec SA：第一阶段，通信双方协商和建立IKE本身使用的安全通道，建立一个IKE SA；第二阶段，利用这个已通过了认证和安全保护的安全通道，建立一对IPSec SA。IKEv2则简化了协商过程，在一次协商中可直接生成IPSec的密钥并建立IPSec SA。IKEv1和IKEv2的具体协商过程请分别参见IKEv1协商安全联盟的过程和IKEv2协商安全联盟的过程。
[*]修复了多处公认的密码学方面的安全漏洞，提高了安全性能。
IPSec基本原理
IPSec通过在IPSec对等体间建立双向安全联盟形成一个安全互通的IPSec隧道，并通过定义IPSec保护的数据流将要保护的数据引入该IPSec隧道，然后对流经IPSec隧道的数据通过安全协议进行加密和验证，进而实现在Internet上安全传输指定的数据。
IPSec安全联盟可以手工建立，也可以通过IKEv1或IKEv2协议自动协商建立。本文重点介绍如何定义IPSec保护的数据流、IKE自动协商建立安全联盟的过程。
定义IPSec保护的数据流
IPSec是基于定义的感兴趣流触发对特定数据的保护，至于什么样的数据是需要IPSec保护的，可以通过以下两种方式定义。其中IPSec感兴趣流即需要IPSec保护的数据流。
[*]ACL方式
手工方式和IKE自动协商方式建立的IPSec隧道是由ACL来指定要保护的数据流范围，筛选出需要进入IPSec隧道的报文，ACL规则允许（permit）的报文将被保护，未匹配任何permit规则的报文将不被保护。这种方式可以利用ACL的丰富配置功能，根据IP地址、端口、协议类型等对报文进行过滤进而灵活制定IPSec的保护方法。
[*]路由方式
通过IPSec虚拟隧道接口建立IPSec隧道，将所有路由到IPSec虚拟隧道接口的报文都进行IPSec保护，根据该路由的目的地址确定哪些数据流需要IPSec保护。其中IPSec虚拟隧道接口是一种三层逻辑接口。
路由方式具有以下优点：
[*]通过路由将需要IPSec保护的数据流引到虚拟隧道接口，不需使用ACL定义待加/解密的流量特征，简化了IPSec配置的复杂性。
[*]支持动态路由协议。
[*]通过GRE over IPSec支持对组播流量的保护。
IKEv1协商安全联盟的过程
采用IKEv1协商安全联盟主要分为两个阶段：第一阶段，通信双方协商和建立IKE协议本身使用的安全通道，即建立一个IKE SA；第二阶段，利用第一阶段已通过认证和安全保护的安全通道，建立一对用于数据安全传输的IPSec安全联盟。
IKEv1协商阶段1
IKEv1协商阶段1的目的是建立IKE SA。IKE SA建立后对等体间的所有ISAKMP消息都将通过加密和验证，这条安全通道可以保证IKEv1第二阶段的协商能够安全进行。
IKEv1协商阶段1支持两种协商模式：主模式（Main Mode）和野蛮模式（Aggressive Mode）。
主模式包含三次双向交换，用到了六条ISAKMP信息，协商过程如图22-21所示。这三次交换分别是：
[*]消息①和②用于提议交换
发起方发送一个或多个IKE安全提议，响应方查找最先匹配的IKE安全提议，并将这个IKE安全提议回应给发起方。匹配的原则为协商双方具有相同的加密算法、认证算法、认证方法和Diffie-Hellman组标识。
[*]消息③和④用于密钥信息交换
双方交换Diffie-Hellman公共值和nonce值，用于IKE SA的认证和加密密钥在这个阶段产生。
[*]消息⑤和⑥用于身份和认证信息交换（双方使用生成的密钥发送信息），双方进行身份认证和对整个主模式交换内容的认证。
[*]IKE安全提议指IKE协商过程中用到的加密算法、认证算法、Diffie-Hellman组及认证方法等。
[*]nonce是个随机数，用于保证IKE SA存活和抗重放攻击。
野蛮模式只用到三条信息，前两条消息①和②用于协商IKE安全提议，交换Diffie-Hellman公共值、必需的辅助信息以及身份信息，并且消息②中还包括响应方发送身份信息供发起方认证，消息③用于响应方认证发起方。IKEv1协商阶段1的协商过程如图22-21所示。
图22-21 IKEv1协商阶段1的协商过程图
与主模式相比，野蛮模式减少了交换信息的数目，提高了协商的速度，但是没有对身份信息进行加密保护。
IKEv1协商阶段2
IKEv1协商阶段2的目的就是建立用来安全传输数据的IPSec SA，并为数据传输衍生出密钥。这一阶段采用快速模式（Quick Mode）。该模式使用IKEv1协商阶段1中生成的密钥对ISAKMP消息的完整性和身份进行验证，并对ISAKMP消息进行加密，故保证了交换的安全性。IKEv1协商阶段2的协商过程如图22-22所示。
图22-22 IKEv1协商阶段2的协商过程图
IKEv1协商阶段2通过三条ISAKMP消息完成双方IPSec SA的建立：
[*]协商发起方发送本端的安全参数和身份认证信息。
安全参数包括被保护的数据流和IPSec安全提议等需要协商的参数。身份认证信息包括第一阶段计算出的密钥和第二阶段产生的密钥材料等，可以再次认证对等体。
IPSec安全提议指IPSec协商过程中用到的安全协议、加密算法及认证算法等。
[*]协商响应方发送确认的安全参数和身份认证信息并生成新的密钥。
IPSec SA数据传输需要的加密、验证密钥由第一阶段产生的密钥、SPI、协议等参数衍生得出，以保证每个IPSec SA都有自己独一无二的密钥。
如果启用PFS，则需要再次应用DH算法计算出一个共享密钥，然后参与上述计算，因此在参数协商时要为PFS协商DH密钥组。
[*]发送方发送确认信息，确认与响应方可以通信，协商结束。
IKEv2协商安全联盟的过程
采用IKEv2协商安全联盟比IKEv1协商过程要简化的多。要建立一对IPSec SA，IKEv1需要经历两个阶段：“主模式＋快速模式”或者“野蛮模式＋快速模式”，前者至少需要交换9条消息，后者也至少需要6条消息。而IKEv2正常情况使用2次交换共4条消息就可以完成一对IPSec SA的建立，如果要求建立的IPSec SA大于一对时，每一对IPSec SA只需额外增加1次创建子SA交换，也就是2条消息就可以完成。
IKEv2定义了三种交换：初始交换（Initial Exchanges）、创建子SA交换（Create_Child_SA Exchange）以及通知交换（Informational Exchange）。
初始交换
正常情况下，IKEv2通过初始交换就可以完成第一对IPSec SA的协商建立。IKEv2初始交换对应IKEv1的第一阶段，初始交换包含两次交换四条消息，如图22-23所示。
图22-23 初始交换过程图
消息①和②属于第一次交换（称为IKE_SA_INIT交换），以明文方式完成IKE SA的参数协商，包括协商加密和验证算法，交换临时随机数和DH交换。IKE_SA_INIT交换后生成一个共享密钥材料，通过这个共享密钥材料可以衍生出IPSec SA的所有密钥。
消息③和④属于第二次交换（称为IKE_AUTH交换），以加密方式完成身份认证、对前两条信息的认证和IPSec SA的参数协商。IKEv2支持RSA签名认证、预共享密钥认证以及扩展认证方法EAP（Extensible Authentication Protocol）。发起者通过在消息3中省去认证载荷来表明需要使用EAP认证。
创建子SA交换
当一个IKE SA需要创建多对IPSec SA时，需要使用创建子SA交换来协商多于一对的IPSec SA。另外，创建子SA交换还可以用于IKE SA的重协商。
创建子SA交换包含一个交换两条消息，对应IKEv1协商阶段2，交换的发起者可以是初始交换的协商发起方，也可以是初始交换的协商响应方。创建子SA交换必须在初始交换完成后进行，交换消息由初始交换协商的密钥进行保护。
类似于IKEv1，如果启用PFS，创建子SA交换需要额外进行一次DH交换，生成新的密钥材料。生成密钥材料后，子SA的所有密钥都从这个密钥材料衍生出来。
通知交换
运行IKE协商的两端有时会传递一些控制信息，例如错误信息或者通告信息，这些信息在IKEv2中是通过通知交换完成的，如图22-24所示。
通知交换必须在IKE SA保护下进行，也就是说通知交换只能发生在初始交换之后。控制信息可能是IKE SA的，那么通知交换必须由该IKE SA来保护进行；也可能是某子SA的，那么该通知交换必须由生成该子SA的IKE SA来保护进行。
图22-24 通知交换过程图
IPSec增强原理
GRE over IPSec
GRE over IPSec可利用GRE和IPSec的优势，通过GRE将组播、广播和非IP报文封装成普通的IP报文，通过IPSec为封装后的IP报文提供安全地通信，进而可以提供在总部和分支之间安全地传送广播、组播的业务，例如视频会议或动态路由协议消息等。
当网关之间采用GRE over IPSec连接时，先进行GRE封装，再进行IPSec封装。GRE over IPSec使用的封装模式为可以是隧道模式也可以是传输模式。因为隧道模式跟传输模式相比增加了IPSec头，导致报文长度更长，更容易导致分片，所以推荐采用传输模式GRE over IPSec。
图22-25 GRE over IPSec报文封装和隧道协商过程
IPSec封装过程中增加的IP头即源地址为IPSec网关应用IPSec安全策略的接口地址，目的地址即IPSec对等体中应用IPSec安全策略的接口地址。
IPSec需要保护的数据流为从GRE起点到GRE终点的数据流。GRE封装过程中增加的IP头即源地址为GRE隧道的源端地址，目的地址为GRE隧道的目的端地址。
页:
[1]