IPSec协议框架

1. IPSec简介

1.1 起源

随着Internet的发展，越来越多的企业直接通过Internet进行互联，但由于IP协议未考虑安全性，而Internet上有大量的不可靠用户和网络设备，所以用户业务数据要穿越这些未知网络，根本无法保证数据的安全性，数据易被伪造、篡改或窃取。因此，迫切需要一种兼容IP协议的通用的网络安全方案。

为了解决上述问题，IPSec（Internet Protocol Security）应运而生。IPSec是对IP的安全性补充，其工作在IP层，为IP网络通信提供透明的安全服务。

1.2 定义

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

通过这些协议，在两个设备之间建立一条IPSec隧道。数据通过IPSec隧道进行转发，实现保护数据的安全性。

1.3 受益

IPSec通过加密与验证等方式，从以下几个方面保障了用户业务数据在Internet中的安全传输：

• 数据来源验证：接收方验证发送方身份是否合法。
• 数据加密：发送方对数据进行加密，以密文的形式在Internet上传送，接收方对接收的加密数据进行解密后处理或直接转发。
• 数据完整性：接收方对接收的数据进行验证，以判定报文是否被篡改。
• 抗重放：接收方拒绝旧的或重复的数据包，防止恶意用户通过重复发送捕获到的数据包所进行的攻击。

2. IPSec原理描述

• IPSec协议框架

• IPSec基本原理

• IPSec增强原理

2.1 IPSec协议框架

• 安全联盟

• 安全协议

• 封装模式

• 加密和验证

• 密钥交换

2.1.1 安全联盟

安全联盟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隧道，分别对两个方向的数据流进行安全保护，如下图所示。

另外，IPSec SA的个数还与安全协议相关。如果只使用AH或ESP来保护两个对等体之间的流量，则对等体之间就有两个SA，每个方向上一个。如果对等体同时使用了AH和ESP，那么对等体之间就需要四个SA，每个方向上两个，分别对应AH和ESP。

建立IPSec SA有两种方式：手工方式和IKE方式。二者的主要差异如表1所示。

对比项	手工方式建立IPSec SA	IKE方式自动建立IPSec SA
加密/验证密钥配置和刷新方式	手工配置、刷新，而且易出错密钥管理成本很高	密钥通过DH算法生成、动态刷新密钥管理成本低
SPI取值	手工配置	随机生成
生存周期	无生存周期限制，SA永久存在	由双方的生存周期参数控制，SA动态刷新
安全性	低	高
适用场景	小型网络	小型、中大型网络

2.1.2 安全协议

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协议的简单比较如表1所示。

安全特性	AH	ESP
协议号	51	50
数据完整性校验	支持（验证整个IP报文）	支持（传输模式：不验证IP头，隧道模式：验证整个IP报文）
数据源验证	支持	支持
数据加密	不支持	支持
防报文重放攻击	支持	支持
IPSec NAT-T（NAT穿越）	不支持	支持

从表中可以看出两个协议各有优缺点，在安全性要求较高的场景中可以考虑联合使用AH协议和ESP协议。

报文头结构

AH报文头结构

AH报文头结构如图1所示；AH报文头字段含义如表2所示。

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报文头结构如图2所示；ESP报文头字段含义如表3所示。

ESP报文头字段含义

字段	长度	含义
SPI	32比特	IPSec安全参数索引，用于唯一标识IPSec安全联盟。
序列号	32比特	是一个从1开始的单项递增的计数器，唯一地标识每一个数据包，用于防止重放攻击。
负载数据	—	包含原始IP报文中可变长度数据内容。ESP保护的内容类型由下一头部字段标识。
填充字段	—	用于增加ESP报文头的位数。填充字段的长度与负载数据的长度和算法有关。当待加密报文的长度不是加密算法所要求的块长度时，需要进行填充补齐。
填充长度	8比特	给出前面填充字段的长度，置0时表示没有填充。
下一头部	8比特	标识ESP报文头后面的下一个负载类型。传输模式下，是被保护的上层协议（TCP或UDP）的编号；隧道模式下，是IP协议的编号。
认证数据	一个变长字段，长度为32比特的整数倍，通常为96比特。	该字段包含数据完整性校验值ICV，用于接收方进行完整性校验。可选择的认证算法与AH的相同。ESP的验证功能是可选的，如果启动了数据包验证，会在加密数据的尾部添加一个ICV数值。

2.1.3 封装模式

封装模式是指将AH或ESP相关的字段插入到原始IP报文中，以实现对报文的认证和加密，封装模式有传输模式和隧道模式两种。

传输模式

在传输模式中，AH头或ESP头被插入到IP头与传输层协议头之间，保护TCP/UDP/ICMP负载。由于传输模式未添加额外的IP头，所以原始报文中的IP地址在加密后报文的IP头中可见。以TCP报文为例，原始报文经过传输模式封装后，报文格式如图1所示。

图1 传输模式下报文封装

传输模式下，与AH协议相比，ESP协议的完整性验证范围不包括IP头，无法保证IP头的安全。

隧道模式

在隧道模式下，AH头或ESP头被插到原始IP头之前，另外生成一个新的报文头放到AH头或ESP头之前，保护IP头和负载。以TCP报文为例，原始报文经隧道模式封装后的报文结构如[图2](mk:@MSITStore:G:\download\S600-E V200R019C10 产品文档(chm)\S600-E V200R019C10 产品文档.chm::/dc/dc_fd_ipsec_0025.html#ZH-CN_CONCEPT_0176374239__fig3)所示。

图2 隧道模式下报文封装

隧道模式下，与AH协议相比，ESP协议的完整性验证范围不包括新IP头，无法保证新IP头的安全。

传输模式和隧道模式比较

传输模式和隧道模式的区别在于：

• 从安全性来讲，隧道模式优于传输模式。它可以完全地对原始IP数据报进行验证和加密。隧道模式下可以隐藏内部IP地址，协议类型和端口。
• 从性能来讲，隧道模式因为有一个额外的IP头，所以它将比传输模式占用更多带宽。
• 从场景来讲，传输模式主要应用于两台主机或一台主机和一台VPN网关之间通信；隧道模式主要应用于两台VPN网关之间或一台主机与一台VPN网关之间的通信。

当安全协议同时采用AH和ESP时，AH和ESP协议必须采用相同的封装模式。

2.1.4 加密和验证

IPSec提供了两种安全机制：加密和验证。加密机制保证数据的机密性，防止数据在传输过程中被窃听；验证机制能保证数据真实可靠，防止数据在传输过程中被仿冒和篡改。

加密

IPSec采用对称加密算法对数据进行加密和解密。如图1所示，数据发送方和接收方使用相同的密钥进行加密、解密。

图1 加密和解密的过程

用于加密和解密的对称密钥可以手工配置，也可以通过IKE协议自动协商生成。

常用的对称加密算法包括：数据加密标准DES（Data Encryption Standard）、3DES（Triple Data Encryption Standard）、先进加密标准AES（Advanced Encryption Standard）。其中，DES和3DES算法安全性低，存在安全风险，不推荐使用。

验证

IPSec的加密功能，无法验证解密后的信息是否是原始发送的信息或完整。IPSec采用HMAC（Keyed-Hash Message Authentication Code）功能，比较数字签名进行数据包完整性和真实性验证。

通常情况下，加密和验证通常配合使用。如图2所示，在IPSec发送方，加密后的报文通过验证算法和对称密钥生成数字签名，IP报文和数字签名同时发给对端（数字签名填写在AH和ESP报文头的完整性校验值ICV字段，请参见安全协议）；在IPSec接收方，使用相同的验证算法和对称密钥对加密报文进行处理，同样得到签名，然后比较数字签名进行数据完整性和真实性验证，验证不通过的报文直接丢弃，验证通过的报文再进行解密。

图2 验证过程

同加密一样，用于验证的对称密钥也可以手工配置，或者通过IKE协议自动协商生成。

常用的验证算法包括：消息摘要MD5（Message Digest 5）、安全散列算法SHA1（Secure Hash Algorithm 1）、SHA2。其中，MD5、SHA1算法安全性低，存在安全风险，不推荐使用。

2.1.5密钥交换

使用对称密钥进行加密、验证时，如何安全地共享密钥是一个很重要的问题。有两种方法解决这个问题：

• 带外共享密钥

  在发送、接收设备上手工配置静态的加密、验证密钥。双方通过带外共享的方式（例如通过电话或邮件方式）保证密钥一致性。这种方式的缺点是安全性低，可扩展性差，在点到多点组网中配置密钥的工作量成倍增加。另外，为提升网络安全性需要周期性修改密钥，这种方式下也很难实施。

• 使用一个安全的密钥分发协议

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

IKE协议

因特网密钥交换IKE（Internet Key Exchange）协议建立在Internet安全联盟和密钥管理协议ISAKMP定义的框架上，是基于UDP（User Datagram Protocol）的应用层协议。它为IPSec提供了自动协商密钥、建立IPSec安全联盟的服务，能够简化IPSec的配置和维护工作。

IKE与IPSec的关系如图1所示，对等体之间建立一个IKE SA完成身份验证和密钥信息交换后，在IKE SA的保护下，根据配置的AH/ESP安全协议等参数协商出一对IPSec SA。此后，对等体间的数据将在IPSec隧道中加密传输。

IKE SA是一个双向的逻辑连接，两个对等体间只建立一个IKE SA。

图1 IKE与IPSec的关系图

IKE安全机制

IKE具有一套自保护机制，可以在网络上安全地认证身份、分发密钥、建立IPSec SA：

• 身份认证

  身份认证确认通信双方的身份（对等体的IP地址或名称），包括预共享密钥PSK（pre-shared key）认证、数字证书RSA（rsa-signature）认证。

  Efficient VPN仅支持预共享密钥认证。

  • 在预共享密钥认证中，通信双方采用共享的密钥对报文进行Hash计算，判断双方的计算结果是否相同。如果相同，则认证通过；否则认证失败。

    当有1个对等体对应多个对等体时，需要为每个对等体配置预共享的密钥。该方法在小型网络中容易建立，但安全性较低。

  • 在数字证书认证中，通信双方使用CA证书进行数字证书合法性验证，双方各有自己的公钥（网络上传输）和私钥（自己持有）。发送方对原始报文进行Hash计算，并用自己的私钥对报文计算结果进行加密，生成数字签名。接收方使用发送方的公钥对数字签名进行解密，并对报文进行Hash计算，判断计算结果与解密后的结果是否相同。如果相同，则认证通过；否则认证失败。

    使用数字证书安全性高，但需要CA来颁发数字证书，适合在大型网络中使用。

  IKE支持的认证算法有：SHA2-256。

• 身份保护

  身份数据在密钥产生之后加密传送，实现了对身份数据的保护。

  IKE支持的加密算法有：3DES、AES-128、AES-192、AES-256。

• DH

  DH是一种公共密钥交换方法，它用于产生密钥材料，并通过ISAKMP消息在发送和接收设备之间进行密钥材料交换。然后，两端设备各自计算出完全相同的对称密钥。该对称密钥用于计算加密和验证的密钥。在任何时候，通信双方都不交换真正的密钥。DH密钥交换是IKE的精髓所在。

• PFS

  完善的前向安全性PFS（Perfect Forward Secrecy）通过执行一次额外的DH交换，确保即使IKE SA中使用的密钥被泄露，IPSec SA中使用的密钥也不会受到损害。

为了保证更好的安全性，建议使用SHA2-256认证算法和AES加密算法。

IKE版本

IKE协议分IKEv1和IKEv2两个版本。IKEv2与IKEv1相比有以下优点：

• 简化了安全联盟的协商过程，提高了协商效率。

  IKEv1使用两个阶段为IPSec进行密钥协商并建立IPSec SA：第一阶段，通信双方协商和建立IKE本身使用的安全通道，建立一个IKE SA；第二阶段，利用这个已通过了认证和安全保护的安全通道，建立一对IPSec SA。IKEv2则简化了协商过程，在一次协商中可直接生成IPSec的密钥并建立IPSec SA。IKEv1和IKEv2的具体协商过程请分别参见IKEv1协商安全联盟的过程和IKEv2协商安全联盟的过程。

• 修复了多处公认的密码学方面的安全漏洞，提高了安全性能。