定义

IPSec是Internet工程任务组（IETF）制定的一个开放的网络层安全框架协议。它并不是一个单独的协议，而是一系列为IP网络提供安全性的协议和服务的集合。IPSec主要包括安全协议AH（Authentication Header）和ESP（Encapsulating Security Payload），密钥管理交换协议IKE（Internet Key Exchange）以及用于网络认证及加密的一些算法等。

目的

在IPv4协议诞生之时，Internet网络的规模还非常小，Internet网络的安全完全可以通过物理隔离的方式来保证。另一方面，所有人都未预料到以后Internet网络会爆炸式的增长，所以在设计和开发IPv4协议时，没有考虑IPv4协议的安全保护手段。

由于IP报文本身并不集成任何安全特性，恶意用户很容易便可伪造IP报文的地址、修改报文内容、重播以前的IP数据包以及在传输途中拦截并查看数据包的内容。因此，传统IP层协议不能担保收到的IP数据包的安全。在应用层保证网络安全的方法只对特定的应用有效，不够通用。人们迫切需要能够在IP层提供安全服务的协议，这样可以使TCP/IP高层的所有协议受益。IPSec（Internet Protocol Security）正是用来解决IP层安全性问题的技术。

IPSec主要通过加密与验证等方式，为IP数据包提供安全服务。IPSec可以提供的安全服务包括：

• 数据加密通过数据加密提供数据私密性。
• 数据源验证通过对发送数据的源进行身份验证，保证数据来自真实的发送者。
• 防止数据重放通过在接收方拒绝重复的数据包防止恶意用户通过重复发送捕获到的数据包进行攻击。

受益

IPSec具有以下优点：

• 所有使用IP协议进行协议报文传输的应用系统和服务都可以使用IPsec，而不必对这些应用系统和服务本身做任何修改。
• 对协议报文的加密是以数据包为单位的，而不是以整个数据流为单位，这不仅灵活而且有助于进一步提高协议报文的安全性，可以有效防范网络攻击。

运营商场景

点到点VPN（Site-to-Site VPN）

IPSec可以为任何基于IP的通信提供安全保护，既可以保护传统的固定网络，也可以保护LTE等移动网络。

点到点VPN也称网关到网关VPN（Gateway to Gateway VPN），可以保证两个网关之间IP流量的安全性。典型组网如图1所示。图1 点到点VPN组网

点到点VPN部署非常灵活，而且当两个IPSec网关之间存在NAT设备时，支持IPSec NAT穿越。

企业场景

企业场景里IPSec主要用于公司之间通过IPSec VPN网络互连，典型应用是点到点VPN。企业场景里IPSec的组网更加灵活多样。

点到点VPN（Site-to-Site VPN）

点到点VPN主要用于公司总部与分支机构之间建立IPSec隧道，从而实现局域网之间互通。典型组网如图1所示。图1 点到点VPN组网

点到多点VPN（Hub-Spoke VPN）

实际组网中最常见的是公司总部与多个分支机构通过点到多点IPSec VPN互通，典型组网如图2所示。图2 Hub-Spoke VPN组网

在这种组网中，用户可以根据实际需求配置IPSec。

此时网络内数据流量可能存在如下两种情况：

• 各分支机构之间不需要通信只有总部和分支之间部署IPSec VPN，也只有总部和分支之间存在业务流量。如图3所示。图3 Hub-Spoke VPN组网应用一
• 各分支机构之间需要通信分支机构之间通过总部进行通信，如图4所示。图4 Hub-Spoke VPN组网应用二

分支机构用户上网控制

在点到点或点到多点VPN中，分支机构用户上网可以通过两种方式来实现。

• 分支机构用户通过总部接入Internet为进行统一管理和监控，分支机构用户不允许通过自身的网关接入Internet，只能通过VPN接入到总部，然后通过总部访问Internet。分支访问Internet的流量一般需要在总部做NAT才能到公网。如图5所示。图5 分支机构用户通过总部接入Internet
• 分支机构用户自行接入Internet对分支机构的上网流量不做控制，如图6所示。图6 分支机构用户自行接入Internet

安全协议

IPSec通过AH（Authentication Header，验证头）和ESP（Encapsulating Security Payload，封装安全载荷）两个安全协议实现IP报文的封装/解封装。

• AH是报文头验证协议，主要提供数据源验证、数据完整性验证和防报文重放功能，不提供加密功能。
• ESP是封装安全载荷协议，主要提供加密、数据源验证、数据完整性验证和防报文重放功能。

虽然AH协议和ESP协议都可以提供数据源验证和数据完整性校验服务，但是两者不能互相取代。两者之间的差别在于验证报文的范围不同，验证范围请参见封装模式。

AH和ESP协议的简单比较如表1所示。

从上表中可以看出两个协议各有优缺点，AH协议不提供数据加密功能，ESP的验证范围不包括IP头，其安全性不如AH，故在安全性要求较高的场景中可以考虑联合使用AH协议和ESP协议。AH协议和ESP协议联合使用时，需要先使用ESP，这是因为AH对整个IP数据报文进行认证，如果先使用AH再使用ESP，ESP的头和尾会改变数据报文的长度，而且ESP的填充字段也会改变数据报文的长度，造成AH认证失败。

封装模式

目前NE支持隧道模式。

隧道模式

隧道模式的报文格式如图1所示。在隧道模式下，原始IP数据报文被封装成一个新的IP数据报文，并在旧IP报文头（图1中的IP Header）和新IP报文头（图1中的New IP Header）之间插入一个IPSec报文头（AH或ESP），原IP地址被当作有效载荷的一部分受到IPSec的安全保护。图1 隧道模式的报文格式

隧道模式隐藏了原始IP报文头信息，因此主要应用于两台VPN网关之间或一台主机与一台VPN网关之间的通信。

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

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

加密算法

加密是一种将数据从明文转换成无法读懂的密文的过程，接收方只有在拥有正确的密钥的情况下才能对密文进行解密，从而保证了数据的私密性。

IPSec VPN工作过程中涉及数据加密（IP报文加密）和协议消息加密（ISAKMP消息加密）两种情况。

数据加密

ESP能够对IP报文内容进行加密保护，以防止IP报文内容在传输过程中被窥探。IPSec采用对称加密算法对数据进行加密和解密。对称加密算法是指数据发送方和接收方使用相同的密钥进行加密、解密。

采用对称加密算法进行数据加密和解密的过程如图1所示。图1 加密和解密的过程

用于加密的对称密钥可以手工配置，也可以通过DH算法生成并在两端设备共享。有关DH算法具体能够生成哪些密钥及密钥的作用请参见IKEv1 Phase-1 Negotiation。

一般来说IPSec使用以下加密算法：

• DES（Data Encryption Standard）：使用64bit的密钥对一个64bit的明文块进行加密。
• 3DES（Triple Data Encryption Standard）：使用三个64bit的DES密钥（共192bit密钥）对明文形式的IP报文进行加密。
• AES-CBC-128（Advanced Encryption Standard Cipher Block Chaining 128）：使用128bit加密算法对IP报文进行加密。
• AES-CBC-192（Advanced Encryption Standard Cipher Block Chaining 192）：使用192bit加密算法对IP报文进行加密。
• AES-CBC-256（Advanced Encryption Standard Cipher Block Chaining 256）：使用256bit加密算法对IP报文进行加密。

3DES比DES安全得多，但是其加密速度慢于DES。AES比3DES更安全。

协议消息加密

协议消息加密用于IKE协商阶段。协议消息加密所用的算法也是DES、3DES和AES。用于加密的对称密钥通过DH算法生成。有关DH算法具体能够生成哪些密钥及密钥的作用请参见IKEv1 Phase-1 Negotiation。

认证算法

IPSec采用Hmac（Keyed-Hash Message Authentication Code）功能进行认证。HMAC是HASH函数（单向散列函数）和消息认证码MAC（Message Authentication Code）的结合，HMAC利用Hash函数，以一个对称密钥和一个数据包作为输入，生成一个固定长度的输出，这个输出被称为完整性校验值ICV（Integrity Check Value）。接收方通过比较自身生成的ICV和对端发送的ICV来判断数据的完整性和真实性。

数据源验证和数据完整性验证统一被称为验证。因为这两种安全服务总是绑定在一起提供的。数据完整性验证是基于每个IP数据包进行计算；将完整性验证密钥同IPSec对端身份绑定的结果间接提供了数据源验证。

虽然加密后的数据只能通过原始的加密密钥进行解密，但是无法验证解密后的信息是否是原始发送的信息。另外加密和解密的过程非常的消耗CPU资源，恶意用户可能会通过发送欺骗数据包，占用CPU资源。HMAC功能通过比较数字签名进行数据包完整性和真实性验证，这个过程消耗的CPU资源非常少，效率非常高。

所以在IPSec VPN发送设备中，加密和验证通常配合使用。加密后的报文经HMAC生成数字签名，IP报文和数字签名同时发给对端（数字签名填写在AH和ESP报文头的完整性校验值ICV字段，请参见安全协议）；在接收设备中，通过比较数字签名进行数据完整性和真实性验证，验证不通过的报文直接丢弃，验证通过的报文再进行解密。

加密和HMAC验证配合使用的过程如图1所示。图1 HMAC验证过程

用于验证的对称密钥可以手工配置，也可以通过DH算法生成并在两端设备共享。有关DH算法具体能够生成哪些密钥及密钥的作用请参见IKEv1协商安全联盟的过程。

一般来说IPSec使用以下几种认证算法：

• MD5（Message Digest 5）：输入任意长度的消息，产生一个128比特的消息摘要。
• SHA-1（Secure Hash Algorithm）：输入长度小于264比特的消息，然后生成一个160比特的消息摘要。
• SHA2-256：通过输入长度小于264比特的消息，产生256比特的消息摘要。
• SHA2-384：通过输入长度小于2128比特的消息，产生384比特的消息摘要。
• SHA2-512：通过输入长度小于2128比特的消息，产生512比特的消息摘要。

SHA-2的消息摘要长于MD5和SHA-1，因此，SHA-2比MD5和SHA-1更安全。

密钥交换

IKEv1和IKEv2的协商过程中，隧道两端需要进行密钥材料的交换，以便使用相同密钥进行正确的加密和解密。

密钥交换方法

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

• 带外共享密钥在发送、接收设备上手工配置静态的加密、验证密钥。双方通过带外共享的方式（例如通过电话或邮件方式）保证密钥一致性。这种方式的缺点是可扩展性差，在点到多点组网中配置密钥的工作量成倍增加。另外，为提升网络安全性需要周期性修改密钥，这种方式下也很难实施。
• 使用一个安全的连接分发密钥IPSec使用IKE协议在发送、接收设备之间安全地协商密钥。IKE采用DH算法在不安全的网络上安全地交换密钥信息，并生成加密、验证密钥。这种方式配置简单，可扩展性好，特别是在大型动态的网络环境下此优点更加突出。

IKE提供密钥交换，自动协商建立安全联盟等服务。采用IKE协议可以使IPSec配置和管理更简单、更灵活。

• Internet安全联盟和密钥管理协议ISAKMP（Internet Security Association and Key Management Protocol）是IKE的基础，IKE使用ISAKMP协议定义密钥交换的过程。ISAKMP提供了对安全服务进行协商的方法，密钥交换时交换信息的方法，以及对对等体身份进行验证的方法。
• IKE的精髓在于它永远不在不安全的网络上传送密钥，而是通过一些数据的交换，通信双方最终计算出共享的密钥，并且即使第三方截获了双方用于计算密钥的所有交换数据，也无法计算出真正的密钥。其中的核心技术就是DH（Diffie Hellman）交换技术。

DH密钥交换

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

DH密钥交换过程如图1所示。图1 DH密钥交换过程

1. 进行DH交换的双方各自产生一个随机数，如a和b。
2. 使用双方确认的共享的公开的两个参数：底数g和模数p各自用随机数a和b进行幂和模运算，得到结果c和d，计算公式如下：c=gamod(p)d=gbmod(p)
3. 交换计算所得的结果c和d
4. 各自进一步计算，得到一个共同的DH公有值：damod(p)=cbmod(p)=gabmod(p)，此公式可以从数学上证明。DH公有值就是双方的密钥。

若网络上的第三方截获了双方的模c和d，那么要计算出DH公有值gabmod(p)还需要获得a或b，a和b始终没有直接在网络上传输过。如果想由模c和d计算a或b就需要进行离散对数运算，而p为素数，当p足够大时（一般为768位以上的二进制数），数学上已经证明，其计算复杂度非常高，从而认为是不可实现的。所以，DH交换技术可以保证双方能够安全地获得密钥信息。

DH使用密钥组来定义自己产生的密钥长度。密钥长度越长，产生的密钥就越安全，但所需的计算时间也依次递增。

IPSec安全联盟

IPSec在两个端点之间提供安全通信，这两个端点被称为IPSec对等体。

安全联盟（Security Association）是通信对等体间对某些要素的约定。它定义了保护IP报文安全的协议（AH或者ESP）、IP报文的封装模式、认证算法、保护IP报文的共享密钥等。通过安全联盟实现了IPSec对IP报文的保护。安全联盟是IPSec的基础，也是IPSec的本质。

SA是单向的，输入的IP报文和输出的IP报文由入方向安全联盟和出方向安全联盟分别处理。因此，如果有两个设备（DeviceA和DeviceB）使用ESP进行通信，则必须在DeviceA上设置两个SA，一个用于处理外发IP报文，另一用于处理接收IP报文。同样地，DeviceB也需要两个SA。如图1所示。图1 SA的单向逻辑连接

安全联盟还与协议相关。如果主机A和主机B同时使用AH和ESP进行安全通信，对于主机A就需要四个SA，AH协议的两个SA（入方向和出方向上各一个SA）和ESP协议的两个SA（入方向和出方向上各一个SA）。同样地，主机B也需要四个SA。

安全联盟由一个三元组来唯一标识。这个三元组包括：安全参数索引SPI（Security Parameter Index）、目的IP地址、安全协议号（AH或ESP）。SPI是为唯一标识SA而生成的一个32比特的数值，它在AH和ESP头中传输。

安全联盟建立方式

安全联盟可通过手工配置和自动协商两种方式建立。

• 手工建立安全联盟的方式是指用户通过在两端手工设置一些参数，在两端参数匹配和协商通过后建立IPSec安全联盟。手工方式配置比较复杂，创建IPSec安全联盟所需的全部信息都必须手工配置，而且不支持IPSec的一些高级特性（例如定时更新密钥），但优点是可以不依赖IKE而单独实现IPSec功能。手工方式目前主要用于协议报文的认证，例如RIPng、OSPFv3、IGMP、MLD、PIM和DHCPv6 Relay等。
• 自动协商方式由IKE生成和维护，通信双方基于各自的安全策略库经过匹配和协商，最终建立安全联盟而不需要用户的干预。IKE属于一种混合型协议，它建立在由Internet安全联盟和密钥管理协议ISAKMP（Internet Security Association and Key Management Protocol）定义的一个框架上。它能够为IPSec提供自动协商交换密钥、建立安全联盟的服务，以简化IPSec的使用和管理。IKE分为IKEv1和IKEv2两个版本，二者建立安全联盟的方式大体相同，具体请参考IKEv1协商安全联盟的过程和IKEv2协商安全联盟的过程。

IKE的安全机制

• DH密钥交换。
• 完善的前向安全性PFS（Perfect Forward Secrecy）：指一个密钥被破解，并不影响其他密钥的安全性，因为这些密钥间没有派生关系。PFS是由DH算法保障的。此特性是通过在IKE阶段2的协商中增加密钥交换来实现的。
• 身份验证：身份验证用于确认通信双方的身份。对于pre-shared key验证方法，验证字用来作为一个输入产生密钥，验证字不同是不可能在双方产生相同的密钥的。验证字是验证双方身份的关键。
• 身份保护：身份数据在密钥产生之后加密传送，实现了对身份数据的保护。

IKEv1协商安全联盟的过程

采用IKEv1协商安全联盟主要分为两个阶段。

1. IKEv1阶段1的目的是建立IKE SA。IKE SA建立后对等体间的所有ISAKMP消息都将通过加密和验证，这条安全通道可以保证IKEv1阶段2的协商能够安全进行。
2. IKEv1阶段2的目的就是建立用来传输数据的IPSec SA。

IKEv1协商阶段1

IKEv1阶段1主要协商下面三个任务：

1. 协商建立IKE SA所使用的参数。加密算法、完整性验证算法、身份认证方法和认证字、DH组、IKE SA生存周期等等。这些参数在IKE安全提议中定义。
2. 使用DH算法交换与密钥相关的信息（生成各种密钥的材料）。对等体双方设备能够使用这些密钥信息各自生成用于ISAKMP消息加密、验证的对称密钥。
3. 对等体之间验证彼此身份。使用预共享密钥或数字证书来验证设备身份。

这三个任务都协商成功后，IKE SA就建立成功了。

IKEv1阶段1支持两种协商模式：主模式（Main Mode）和野蛮模式（Aggressive Mode）

主模式

主模式采用三个步骤来完成上述三个任务。每个步骤需要2个ISAKMP报文，共6个ISAKMP报文。交换密钥相关信息的操作在身份认证之前完成，故设备的身份信息受到已生成的共享密钥的保护。

采用主模式时IKEv1阶段1的协商过程如图1所示。图1 主模式下IKEv1阶段1的协商过程

下面对这三个步骤进行详细说明：

1. 协商对等体之间使用的IKE安全提议。DeviceA发送ISAKMP消息，携带建立IKE SA所使用的参数（由IKE安全提议定义）。DeviceB对DeviceA的IKE安全提议进行协商。在协商时将从优先级最高的提议开始匹配，协商双方必须至少有一条匹配的IKE安全提议才能协商成功。匹配的原则为协商双方具有相同的加密算法、认证算法、认证方法和Diffie-Hellman组标识。DeviceB响应ISAKMP消息，携带经协商匹配的安全提议及参数。 如果没有匹配的安全提议，DeviceB将拒绝发起方的安全提议。
2. 使用DH算法交换与密钥相关的信息，并生成密钥。两个对等体通过两条ISAKMP消息（3、4）交换与密钥相关的信息。由获得的密钥信息推导出4个密钥。其中SKEYID为基础密钥，通过它可以推导出SKEYID_a，为ISAKMP消息完整性验证密钥；可以推导出SKEYID_e，为ISAKMP消息加密密钥；可以推导出SKEYID_d，用于衍生出IPSec报文加密、验证密钥。预共享密钥方式和数字证书方式下SKEYID的计算公式不同。图2 DH密钥生成
3. 对等体之间验证彼此身份。两个对等体通过两条ISAKMP消息（5、6）交换身份信息（预共享密钥方式下为IP地址或名称，数字证书方式下还需要传输证书的内容），身份信息通过SKEYID_e加密，故可以保证身份信息的安全性。两个对等体使用IKE安全提议中定义的加密算法、验证算法、身份验证方法和SKEYID_a、SKEYID_e对IKE消息进行加解密和验证。IKEv1支持如下身份验证方法：预共享密钥这种方法要求对等体双方必须要有相同的预共享密钥（该密钥直接参与SKEYID的生成计算）。对于设备数量较少的VPN网络来说易于配置，在大型VPN网络中，不建议采用预共享密钥来做身份验证。RSA签名（通常称为数字证书）数字证书需要由CA服务器来颁发。这种方法适用于大型动态的VPN网络。证书验证和预共享密钥验证的主要区别在于SKEYID的计算和交换的身份信息，其他的交换和计算过程和预共享密钥验证方式相同。数字信封认证在数字信封认证中，发起方采用对称密钥加密信息内容，并通过非对称密钥的公钥加密对称密钥，从而保证只有特定的对端才能阅读通信的内容，从而确定对端的身份。此认证方法只能在IKEv1的主模式协商过程中使用，不能在IKEv1野蛮模式协商过程中使用。

野蛮模式

野蛮模式仅交换3个消息就可以完成IKE SA的建立。

采用野蛮模式时IKEv1阶段1的协商过程如图3所示。图3 野蛮模式下IKEv1阶段1的协商过程

野蛮模式时IKEv1阶段1的协商过程：

1. DeviceA发送ISAKMP消息，携带建立IKE SA所使用的参数、与密钥生成相关的信息和身份验证信息。
2. DeviceB对收到的第一个数据包进行确认，查找并返回匹配的参数、密钥生成信息和身份验证信息。
3. DeviceA回应验证结果，并建立IKE SA。

与主模式相比，野蛮模式的优点是建立IKE SA的速度较快。但是由于密钥交换与身份认证一起进行，野蛮模式无法提供身份保护。

主模式与野蛮模式的区别

野蛮模式安全性比主模式差。但是野蛮模式可以满足某些特定场合的网络环境的需求。例如：

• 远程访问时，如果响应者（服务器端）无法预先知道发起者（终端用户）的地址、或者发起者的地址总在变化时，而双方都希望采用预共享密钥验证方法来创建IKE SA，此时可以采用野蛮模式。NE采用预共享认证方式，若是可以获取出口网关的代理IP，也可以在此种情形下采用主模式下配置代理IP的方式。
• 如果发起者已知响应者的策略，或者对响应者的策略有全面的了解，采用野蛮模式能够更快地创建IKE SA。

IKEv1协商阶段2

IKEv1阶段2的目的就是建立用来传输数据的IPSec SA。IPSec SA与IKE SA的关系如图4所示。图4 IPSec SA与IKE SA的关系

IKEv1阶段2通过快速交换模式完成。由于快速交换模式使用IKEv1阶段1中生成的密钥SKEYID_a对ISAKMP消息的完整性和身份进行验证，使用密钥SKEYID_e对ISAKMP消息进行加密，故保证了交换的安全性。

在快速交换模式中，对等体两端协商IPSec SA的各项参数，并为数据传输衍生出密钥。

快速模式的协商过程如图5所示。图5 IKEv1阶段2协商过程

快速模式共有3条消息完成双方IPSec SA的建立。

1. 消息1发送本端的安全参数和身份认证信息。安全参数包括被保护的数据流和IPSec安全提议等需要协商的参数。身份认证信息包括第一阶段计算出的密钥和第二阶段产生的密钥材料等，可以再次认证对等体。
2. 消息2响应消息1，发送响应方的安全参数和身份认证信息并生成新的密钥。对等体双方通过交换密钥材料生成新的共享密钥，并最终衍生出IPSec的加密密钥。此时响应者和发送者各有两个SA。IPSec SA数据传输需要的加密、验证密钥由SKEYID_d、SPI、协议等参数衍生得出，以保证每个IPSec SA都有自己独一无二的密钥。当启用PFS时，要再次应用DH算法计算出一个共享密钥，然后参与上述计算，因此在参数协商时要为PFS协商DH密钥组。
3. 消息3响应消息2，确认与响应方可以通信，协商结束。

IKEv2协商安全联盟的过程

要建立一对IPSec SA，IKEv1需要经历两个阶段：“主模式＋快速模式”或者“野蛮模式＋快速模式”。前者至少需要交换9条消息，后者也至少需要6条消息。而IKEv2，正常情况使用2次交换共4条消息就可以完成一个IKE SA和一对IPSec SA，如果要求建立的IPSec SA大于一对时，每一对SA只需额外增加1次交换，也就是2条消息就可以完成。这比IKEv1要简化很多。

IKEv2协商安全联盟的过程

IKEv2定义了三种交换：初始交换、创建子SA交换以及通知交换。

1. 初始交换IKE通信总是从IKE安全联盟初始交换（IKE_SA_INIT交换）和IKE认证交换（IKE_AUTH交换）开始。这2个交换通常由4条消息组成，在某些场景下消息数目可能会增加。所有使用IKE的通信都由请求/响应对组成。IKE安全联盟初始交换和IKE认证交换完成后可以建立一个IKE SA和第一对CHILD_SA（即IPSec SA）。具体如图1所示。图1 IKEv2初始阶段的协商过程
   详细说明如下：第一个消息对（IKE_SA_INIT）这个消息对负责进行IKE安全联盟参数的协商，包括协商加密和验证算法，交换临时随机数（nonces）和DH交换。IKE_SA_INIT交换后可以生成一个共享密钥材料。通过这个共享密钥材料可以生成其他相关密钥。第二个消息对（IKE_AUTH）从IKE_AUTH交换开始，所有报文都必须加密再交换。IKE_AUTH交换至少需要两个消息。在这两个报文的交互中完成了身份认证以及一个CHILD_SA的创建过程。IKEv2支持RSA签名认证、预共享密钥认证。RSA签名认证和预共享密钥认证方式下，认证载荷（AUTH载荷）的计算方式不同。在IKE_SA_INIT交换阶段，生成IPSec SA的密钥材料，并通过这个密钥材料衍生出IPSec SA的所有密钥。IKEv2除支持RSA签名和预共享密钥认证外，还支持扩展认证方法EAP（Extensible Authentication Protocol）。EAP认证是作为附加的IKE_AUTH交换在IKE中实现的。发起者通过在消息3中省去AUTH载荷来表明需要使用EAP认证。
2. 创建子SA交换当一个IKE SA需要创建多对IPSec SA时，需要使用创建子SA交换来协商多于一对的SA。另外创建子SA交换还可以用于进行IKE SA的重协商。创建子SA交换包含一个交换两个消息。在IKEv1中这个交换称为阶段2交换（快速模式交换）。这个交换必须在IKE初始交换完成之后才能进行，交换的发起者可以是IKE初始交换的发起者，也可以是IKE初始交换的响应者。在交换中的两个消息需要由IKE初始交换协商的密钥进行保护。类似于IKEv1的PFS，创建子SA交换阶段可以重新进行一次DH交换，生成新的密钥材料。生成密钥材料后，子SA的所有密钥都从这个密钥材料衍生出来。
3. 通知交换运行IKE协商的两端有时会传递一些控制信息，例如错误信息或者通告信息，这些信息在IKEv2中是通过通知交换完成的。通知交换必须在IKE SA保护下进行，也就是说通知交换只能发生在初始交换之后。

IPSec报文处理流程

IPSec安全联盟建立以后，可以对IP报文做加解密处理。与IPSec报文转发相关的概念如下：

• 安全策略数据库SPDB（Security Policy Database）：定义IP数据报文应使用何种安全服务，以及如何获得这些服务。SPDB是SA创建的前提，决定了SA的作用范围和相关属性。
• 安全联盟数据库SADB（Security Association Database）：存放与SA关联的所有状态数据的存储结构。因为一个网络实体可以创建多对SA，所以需要有个DB来做存储管理。
• SPI（安全参数索引）：一个携带在AH或ESP头部的一个32位数值，接收端通过SPI来判断接收到的数据流应该用SADB中的哪个SA来做安全保护。

IPSec对于发送报文的处理流程如图1所示。图1 IPSec发送报文处理流程

IPSec对于接收报文的处理流程如图2所示。图2 IPSec接收报文处理流程

IPSec DPD

DPD

当两个对等体之间采用IKE和IPSec进行通信时，对等体之间可能会由于路由问题、对等体重启或其他原因等导致连接断开。IKE协议本身没有提供对等体状态检测机制，一旦发生对等体不可达的情况，只能等待安全联盟的生存周期到期。生存周期到期之前，对等体之间的安全联盟将一直存在。安全联盟连接的对等体不可达将引发“黑洞”，导致数据流被丢弃。通常情况下，迫切需要识别和检测到这些“黑洞”，以便尽快的恢复IPSec通信。

Keepalive机制可以解决这个问题。Keepalive机制是指IKE对等体间通过周期性的交换Hello/Ack消息来告知对方自己处于活动状态。但是在设备上的IKE SA数量很大时，发送的Hello/Ack消息将会大量消耗设备的CPU资源，限制了这种机制的应用。

失效对等体检测DPD（Dead Peer Detect）是Keepalive机制的一种替代机制，它利用IPSec流量使对等体状态检测所需消息的数量达到最小化。DPD规定每个IKE peer的状态和对端状态是完全独立的，当IKE peer想知道对端是否在线时，随时请求，不需要等待间隔时间的到来。当peer之间有正常的IPSec流量时，证明对端肯定在线，此时没有必要去发送额外的消息探测对端是否在线。只有一段时间内没有流量发生，peer的活动状态才值得怀疑，那么本端在发送流量前应该发送一次DPD消息来检测对端的状态。

DPD有两种模式可以选择：interval和on-demand。

interval：表示DPD工作在轮询模式，在check-interval时间内，如果没有收到对端发过来的流量就会以check-interval为周期循环发送DPD检测报文。如果期间收到对端的响应报文，那么本次DPD流程结束，进入新的DPD检测周期。如果期间没有收到对端的响应报文，则会进行报文重传。重传结束后，如果依然没有收到响应则会删除本端SA表项，重新执行隧道新建流程。

on-demand：表示DPD工作在流量触发模式，如果本端没有加密流量发送，那么是不会发送DPD报文的，这是和轮询模式的最大区别。如果本端有加密流量需要发送，并且发送后在check-interval时间内没有收到对端发过来的流量，那么就会以check-interval为周期循环发送DPD检测报文。如果期间收到对端的响应报文，那么本次DPD流程结束，进入新的DPD检测周期。如果期间没有收到对端的响应报文，则会进行报文重传。重传结束后，如果依然没有收到响应则会删除本端SA表项，重新执行隧道新建流程。

IPSec安全性

IKEv2的安全性分析

此处着重分析IKEv2的安全性。

IKEv2对传统IKE存在的安全漏洞进行了修订，提高了密钥协商的安全性，并明确规定了所有的消息必须以请求/响应对的形式存在，有效的解决了使用UDP作为传输层协议的不可靠性问题。

以下从三方面来讨论IKEv2的安全性问题。

• 抵御中间人攻击中间人攻击（Man-in-the-middle Attack）是一种主动攻击，指攻击者对通信双方进行窃听，截获通信双方的消息并进行任意插入、删除或篡改消息，之后返回消息给发送者，或者重放旧消息以及重定向消息，是最危险的攻击。IKEv2中抵御中间人攻击的机制和方法：密钥材料生成方式与传统IKE相比，IKEv2的密钥材料发生了变化，双方用于后继交互使用的加密密钥与认证密钥都是不同的。这些密钥是从prf+输出流中依次提取，从而增加了攻击者猜测密钥的难度，减少了密钥泄漏的可能性，增强了传输的安全性，一定程度上可以抵御中间人攻击。身份认证IKEv2使用预共享密钥和数字签名方式进行身份认证。身份认证方式具有交互性，参与协商的实体彼此都对对方的身份进行认证；具有对称性，参与协商的双方都使用相同的机制或方法对对方的身份进行认证。双向的身份认证可以有效地抵御中间人攻击。同时IKEv2定义了扩展认证交互，即使用扩展认证协议（EAP）描述的方法对IKEv2协商进行身份认证，支持非对称双向认证，进一步加强了认证的灵活性和协商的可扩展性。消息交换IKEv2将传统IKE主模式交换的六条消息修订为四条消息，将SA载荷和KE载荷、nonce载荷一同发送，这样，消息中包含随机的nonce值，如果攻击者伪装成响应方进行应答，将收到的发起方的消息基本上不做改变，再发回给发起方，发起方可以根据消息内容判断消息的真假，在一定程度上可以抵御重放攻击。每个IKEv2消息的头都包含了一个消息ID，用于匹配对应的请求和响应消息以及识别消息重传。当发送和接收到请求时，必须对消息ID值顺序增加，且除了IKE_SA_INIT交互外其值受加密和完整性保护，使得它能够防重放攻击。同时IKEv2加入了滑动窗口机制，使交互能够更加有效地抵御重放攻击的威胁。
• 抵御DDoS（Distributed Denial of Service）攻击IKEv2中抵御DDoS攻击的机制和方法：SPI值IKEv2消息头部有发起方SPIi和响应方SPIr，它们是内核产生的8字节的随机数，用来标识SA，同时也可以标识进行消息交换的一对节点。具有相同SPI值的请求处理一次（重传消息除外），而把其他请求作为重复数据包丢弃，可以在一定程度上防止DDoS攻击。带Cookie交互IKEv2中使用N载荷携带Cookie的辅助交换来抵御拒绝服务攻击。在通信过程中，响应方认为自己正受到DDoS攻击时，可以向发起方请求回复一个无状态cookie。响应方收到对方发来的第一条消息后并不急于进行IKE_SA_INIT交互，而是再产生一个新的cookie，封装在通知载荷中发送给对方。如果发起方不是攻击者，就可以收到这条消息，然后重新开始协商，并将响应方的cookie封装在该消息中，其它载荷内容保持不变。重传约定IKEv2中所有消息都是成对出现，在每对消息中，发起方负责重传事件，响应方不必对其响应消息进行重传，除非收到对方的一个重传请求。避免了双方同时发起重传，造成资源的浪费，同时也可以防止攻击者截获消息后，伪装成协商者不断地发送重传消息，耗费协商双方的资源。丢弃半开（half-open）连接IKEv2只能通过两种情况判断对方是否失效：一种是重复尝试联系对方，直到应答时间过期；另一种是收到对方的不同IKE SA加密保护下的INITIAL CONTACT通知消息。IKEv2发起方允许多个响应方响应第一条消息，并把所有的响应方视为合法并作回应。发起方发送一些消息后，一旦收到一个有效的加密的响应消息，将其他的响应消息忽略，并将其他所有的无效的半连接丢弃。这样在协商开始时就可以避免受到DDoS攻击。
• 完善的前向安全性PFS（Perfect Forward Secrecy）IPSec SA数据传输需要的加密、验证密钥由SKEYID_d、SPI、协议等参数衍生得出，可以保证每个IPSec SA都有自己独一无二的密钥。但是由于所有IPSec SA密钥都是相同的来源产生的，所以这些IPSec SA密钥相互间都有关联，假如有攻击者能够根据IKE SA判断出SKEYID_d的值，那么就能非常容易的掌握从该SKEYID_d衍生出来的所有IPSec SA的密钥。IPSec专门提供PFS特性来解决这个问题，实现思路是：IKEv2初始交互的密钥衍生材料不被用于衍生供IPSec SA使用的相关密钥，而是通过在CREATE_IPSec_SA交互中引入可选的IKE载荷重新进行一次额外的DH交换来生成密钥材料。通过这种方式，IPSec密钥之间相互没有关联，即使攻击者攻克了一个密钥，也只能破解这个密钥保护的数据，而不能破解受其它密钥保护的数据。

防重放

IPSec中的重放攻击（Replay Attack）主要是指攻击者大量发送目的主机已接收过的数据包，大量消耗系统资源，可能导致系统CPU资源耗尽。

IPSec利用序列号和滑动窗口来实现防重放（Anti-Replay）。IPSec中AH和ESP协议报文头中有个序列号字段（Sequence Number）专门用于防重放攻击。

通信双方协商好IPSec SA之后，序列号字段被置为0，此后发送方每发出一个报文，该数值加1。接收方存在一个防重放滑动窗口和已接收报文的序列号数据库。

• 如果该序列号的报文从未被接收过，且在防重放窗口内，接收方就接收该报文。如果该序列号的报文已经被接收过，则认为是重放攻击，丢弃该报文。
• 如果该序列号在防重放窗口的左侧（小于防重放窗口的最小值），则认为是已经接收的报文，因而被丢弃。
• 如果该序列号在防重放窗口的右侧（大于防重放窗口的最大值），则认为未被接收的报文，会正常接收，同时触发防重放窗口向右滑动。

下面结合图1详细描述防重放的原理。图1 防重放示意图

• 如图1（a）所示，初始防重放窗口是[0–63]，序列号在此范围内的报文会被正常接收，接下来如果接收到序列号大于63的报文，也会正常接收，并且防重放窗口向右滑动。但是如果再次收到序列号在[0–63]范围内的报文，则认为是重放攻击，拒绝接收报文。
• 如果此时收到序列号为66的报文，则防重放窗口滑动到[3–66]，接下来如果接收到序列号大于66的报文，也会正常接收，具体如图1（b）所示。此时[0–2]这三个序列号已经不在防重放窗口范围内，如果再次收到此范围内的报文，则会认为是已经接收过的报文，所以会丢弃这些报文。
• 如图1（c）所示，假如报文发生乱序，接收端先接收到序列号为67的报文，则防重放窗口滑动到[4–67]。然后再接收到序列号为3的报文，虽然该报文之前从未接收过，但是因为其序列号已经在防重放窗口之外，因此也被丢弃。从这一点可以看出，在报文乱序情况下，防重放窗口设置越大，报文被错误丢弃的几率就越低，反之就越高。

安全联盟生存周期

为了防止密钥长期使用而带来的安全隐患，安全联盟存在生存周期。衡量生存周期有两种方式：基于时间的生存周期和基于流量的生存周期。

• 基于时间的生存周期是从安全联盟建立开始的时刻起，此安全联盟存活的时间。
• 基于流量的生存周期是此安全联盟允许处理的最大流量。

其中IPSec安全联盟两种方式都支持，IKE安全联盟并不传输IPSec流量，因此仅支持基于时间的生存周期。IPSec安全联盟和IKE安全联盟的生存周期可以分别配置，互不干扰。

对于IKE安全联盟的生存周期：

• 如果生存周期超时，IKE SA将自动更新。因为IKE协商需要进行DH计算，需要经过较长的时间，为使IKE SA的更新不影响安全通信，建议设置生存周期大于10分钟。
• SA在设定的生存周期超时前会提前协商另一个SA来替换旧的SA。在新的SA还没有协商完之前，依然使用旧的SA；在新的SA建立后，将立即使用新的SA，旧的SA会被自动清除。

对于IPSec安全联盟的生存周期：如果生存周期到达指定的时间或指定的流量，则IPSec安全联盟就会失效。IPSec安全联盟失效前，IKE将为IPSec协商建立新的IPSec安全联盟，这样在旧的IPSec安全联盟失效前新的IPSec安全联盟就已经准备好。在新的IPSec安全联盟开始协商而没有协商好之前，继续使用旧的IPSec安全联盟保护通信。在新的IPSec安全联盟协商好之后，则立即采用新的IPSec安全联盟保护通信。

此外，为了方便对于IPSec安全联盟的生存周期进行配置，系统支持局部超时和全局超时两种配置模式，局部超时时间是针对某个IPSec SA的超时时间。全局超时时间是针对系统中所有IPSec SA的超时时间。当IKE协商安全联盟时，如果采用的安全策略没有配置自己的超时时间，将采用全局超时时间与对端协商。如果安全策略配置了自己的超时时间，则系统使用安全策略自己的超时时间与对端协商。

IPSec QoS

IPSec QoS支持的功能点如表1所示。

IPSec NAT穿越

NAT技术主要用于解决IPv4地址紧缺问题，在目前网络中NAT应用非常广泛，特别是在企业网出口网关大都使用了NAT技术解决公网地址不足的问题。IPSec提供了端到端的IP通信的安全性，可以实现同一企业集团不同地域分支之间的低成本安全互连。但是IPSec和NAT技术本身存在不兼容的问题。

• 从NAT的角度上说，为了完成地址转换，势必会修改IP报文头中的IP地址。
• 从IPSec的角度上说，IPSec要保证数据的安全，因此它会加密和校验数据。AH主要用于保护消息的完整性，其验证范围包含IP报文头，而NAT修改IP报文头会导致AH检查失败，因此使用AH保护的IPSec隧道是不能穿越NAT网关的。但是ESP协议保护的报文不存在该问题，因为ESP保护的部分不包含IP报文头（对隧道方式而言是外层IP报文头）。

但是还是有新的不兼容问题，当NAT改变了某个包的IP地址和（或）端口号时，它通常要更新TCP或UDP校验和。当TCP或UDP校验和使用了ESP来加密时，它就无法更新这个校验和。

• ESP封装的隧道模式：ESP隧道模式将整个原始的IP包整个进行了加密，且在ESP的头部外面新加了一层IP头部，所以NAT如果只改变最前面的IP地址对后面受到保护的部分是不会有影响的。因此，IPSec采用ESP的隧道模式来封装数据时可以与NAT共存。

IPSec穿越NAT的处理

IPSec NAT穿越的流程是：

• NAT穿越（NAT-Traversal，简称NAT-T）能力检测：建立IPSec隧道的两端需要进行NAT穿越能力协商，这是在IKE协商的前两个消息中进行的，通过Vendor ID载荷指明的一组数据来标识。
• NAT网关发现：通过NAT-D（NAT-Discovery）载荷来实现的，该载荷用于在IKE Peer之间发现NAT网关的存在以及确定NAT设备在Peer的哪一侧。NAT侧的Peer作为发起者，需要定期发送NAT-Keepalive报文，以使NAT网关确保安全隧道处于激活状态。
• ESP报文正常穿越NAT网关：IPSec穿越NAT，简单来说就是在原报文的IP头和ESP头（不考虑AH方式）间增加一个标准的UDP报文头。这样，当ESP报文穿越NAT网关时，NAT对该报文的外层IP头和增加的UDP报头进行地址和端口号转换；转换后的报文到达IPSec隧道对端时，与普通IPSec处理方式相同，但在发送响应报文时也要在IP头和ESP头之间增加一个UDP报文头。。

IKEv2与NAT穿越

NAT-T能力检测

NAT-T能力检测在IKE协商的前两个消息中交换完成，通过在消息中插入一个标识NAT-T能力的Vendor ID载荷来告诉对方自己对该能力的支持。如果双方都在各自的消息中包含了该载荷，说明双方对NAT-T都是支持的。只有双方同时支持NAT-T能力，才能继续进行其他协商。

NAT网关发现

当存在NAT设备时必须使用UDP传输，所以在IKEv2中的第一阶段协商中必须先探测是否存在NAT设备，也就是NAT探测。

通过发送NAT-D载荷来实现NAT探测是目前比较流行的方法。

在传统IKE中NAT-D载荷包括在主模式的第三个和第四个信息中以及野蛮模式的第二个和第三个信息中。对于创建VPN连接的双方来说，发送的信息中一般要包括两个连续的NAT-D载荷，第一个是关于目的地址，第二个是关于源地址。如果发送方不知道自己的确切地址(发送方有多个接口，应用程序并不知道数据包从哪个接口出去)，则需要多个NAT-D载荷，从第二个载荷开始，每个载荷和发送方的一个地址相关。对方接收到NAT-D载荷后重新根据收到的包的实际地址端口来计算hash值后进行比较，就可以知道是否有NAT设备以及哪一方在NAT设备之后了。这种方法虽然能检测两个IKE对端之间NAT设备的存在，但存在着明显的缺陷。因为在主模式和野蛮模式中，NAT-D载荷没有被认证，这意味着入侵者可以删除、改变、增加这些载荷，这将导致DoS攻击。通过改变NAT-D载荷，攻击者可以使两方使用UDP封装的模式，而不是使用正常的模式，导致浪费带宽。

为了解决上述缺陷，探测通信链路中是否存在NAT设备，可在协商双方增加两个Notify载荷，一个包括NAT_DETECTION_SOURCE_IP，标识发起方的IP地址；一个包括NAT_DETECTION_DESTINATION_IP，标识目的方的IP地址。这两个载荷主要是为了探测通信双方是否存在NAT设备，并且确定哪一方处在NAT设备之后。

这一过程在IKEv2协商的第一组交换中进行。具体过程如下：

在IKEv2中，NAT_DETECTION_SOURCE_IP和NAT_DETECTION_DESTINATION_IP在Notify消息类型中的编号分别为：16388和16389。载荷使用通用的ISAKMP载荷头，载荷的值是SPIs、IP地址、发送数据包的端口号的hash值(IKEv2规定使用SHA-1)，hash值的计算如下：hash=SHA-1(SPIs|IP|Port)。其中：

• SPIs为HDR载荷中的安全索引参数。
• IP为数据包发出方或接收方的IP地址。
• Port为数据包发出方或接收方的端口号。

当接受方收到数据包后，对数据包中的SPIs、IP地址、端口号进行hash运算，并与Notify载荷进行比较，如果不匹配，则说明通信链路中存在NAT设备：如果与NAT_DETECTION_SOURCE_IP不匹配，则说明发起端在NAT设备之后；如果与NAT_DETECTION_DESTINATION_IP不匹配，则说明接受端在NAT设备之后。

NAT穿越的启用

在第一阶段协商完成之后，协商双方均已经明确是否存在NAT，以及NAT的位置。至于是否启用NAT穿越，则由快速模式协商决定。

NAT穿越的启用协商在快速模式的SA载荷中进行。

NAT-keepalive

在NAT网关上NAT会话有一定的存活时间，因此，隧道建立后如果中间长时间没有报文穿越，就会导致NAT会话被删除，这样将导致无法通过隧道传输数据。解决方法是在NAT会话超时前，发送一个NAT-keepalive给对端，维持NAT会话的存活。

IPSec增强功能

IPSec白名单

IPSec网关支持通过证书属性访问控制策略来认证IKE对端的证书，通过配置此功能也能达到类似白名单的效果。但是此方案存在以下不足：

1. 配置工作量较大，管理不方便。
2. 没有提供对证书通用名称CN（Common Name）的精确匹配。

IPSec白名单特性可以有效解决上述问题。IPSec白名单可以由用户自己定义，然后导入设备，IPSec白名单提供对证书通用名称CN（Common Name）的精确匹配。

IPSec白名单的具体实现过程是：在建立IPSec隧道之前进行IKE协商时，判断是否使能了白名单检验功能，如果使能，则检验接收到的对端证书的CN字段是否在IPSec网关的白名单列表内。

• 如果对端的证书的CN字段在IPSec网关的白名单列表里面，则验证通过，允许进行IKE协商并建立IPSec隧道。
• 如果对端的证书的CN字段不在IPSec网关的白名单列表里面，则验证失败，不允许进行IKE协商，最终IPSec隧道建立失败。

通过这种方式，可以有效保证只有在数字证书白名单内的设备才能接入网络，提高了网络安全性。

白名单文件一般是xml文件，其格式如下：

<SerialnumberList>
    <Serialnumber>CN-on-Certificate_of-RBS-1</Serialnumber>
    <Serialnumber>CN-on-Certificate_of-RBS-2</Serialnumber>
    …
    <Serialnumber>CN-on-Certificate_of-RBS-n</Serialnumber>
</SerialnumberList>

其中<Serialnumber></Serialnumber>之间的字符串即为与IPSec网关对接设备的证书的CN字段。

为了方便用户根据实际需要刷新白名单，IPSec白名单还支持如下功能：

• 支持导入白名单，如果导入过程失败，可以回退到导入之前的状态。
• 支持删除白名单。
• 支持增量添加白名单。
• 支持查看白名单内容。

如图1所示，为了保证eNodeB和IPSec网关之间的通信安全，eNodeB和IPSec网关之间建立了IPSec隧道。而为了防止非法设备与IPSec网关之间建立IPSec隧道，可以提前在IPSec网关上配置白名单特性，从而保证只有在白名单内的设备才能接入网络。

图1 IPSec白名单的应用

自动生成IPSec业务路由

自动生成IPSec业务路由的功能，主要有如下两种应用场景。

• 当使用安全策略模板方式建立IPSec隧道时，用户可能不知道对端隧道的IPSec业务路由信息（如对端的IP地址和接口等），因此无法手工配置静态路由，这时需要配置自动生成IPSec业务路由的功能。
• 当使用安全策略模板方式建立IPSec隧道时，会通过IPSec协商过程自动生成IPSec业务路由。当用户希望按照自己的网络规划，通过配置静态路由方式生成IPSec业务路由时，需要先去使能自动生成IPSec业务路由的功能。

IPSec扩展应用

GRE over IPSec

IPSec本身不支持封装组播、广播和非IP报文，GRE无法对报文进行认证加密，通过GRE over IPSec技术可以将组播、广播报文先封装GRE后，然后再进行IPSec加密处理。同时采用GRE的接口对接收到的加解密流量来进行统计。当网关之间采用GRE over IPSec连接时，先进行GRE封装，再进行IPSec封装。下面以ESP为例说明，报文的封装格式如图1所示。图1 GRE over IPSec封装模式（隧道模式）

IPSec封装过程中增加的IP头即源地址为IPSec网关应用IPSec策略的接口地址，目的地址即IPSec对等体中应用IPSec策略的接口地址。

IPSec需要保护的数据流为从GRE起点到GRE终点的数据流。GRE封装过程中增加的IP头即源地址为GRE隧道的源端地址，目的地址为GRE隧道的目的端地址。

基于GRE over IPSec的应用很多，比如BGP、LDP、OSPF、IS-IS和IPv6等协议，这些应用的原理相同，都是将协议报文使用GRE封装成IP报文，然后再在IPSec隧道里传输。

IPSec和GRE结合，还有一种IPSec over GRE方案，即先使用IPSec对报文进行封装，然后再使用GRE封装。但是，这种封装方式既没有充分利用IPSec和GRE的优势，也无法支持组播、广播和非IP报文，因此一般不推荐使用。

L2VPN/L3VPN场景IPSec应用

L2VPN CE作为IPSec安全网关

图1 报文封装转发流程

缺省情况下，指定安全策略视图的IPSec报文都是先加密再分片，对端收到所有报文后，才能进行解密。通过命令行ipsec df-bit clear和ipsec fragmentation before-encryption配合可以实现先分片后加密，这样对端的设备就可以收到一片就对一片报文解密，为了加快加密报文的解析速度。报文的实际净荷可能会增大。

图2 QoS方案

IPSec报文传输的过程中，原始报文IP头的DSCP值不会也不允许被改变。

报文加密后，原始IP报文头的DSCP值映射到IPSec头部的DSCP域；也可以单独设定外层IP头的DSCP值。

加密后的IPSec报文，经过加密MPLS网络传输后解密，原始IP报文头的DSCP值不变。MPLS网络传输过程，外层DSCP值也可以映射到MPLS EXP值中去。

如果按照DSCP优先级协商IPSec SA，就可以解决Qos带来的乱序问题。

L3VPN PE作为IPSec安全网关

图3 报文封装转发流程

图4 QoS方案

IPSec报文传输的过程中，原始报文IP头的DSCP值不会也不允许被改变。

报文加密后，原始IP报文头的DSCP值映射到IPSec头部的DSCP域；也可以单独设定外层IP头的DSCP值。

加密后的IPSec报文，经过加密MPLS网络传输后解密，原始IP报文头的DSCP值不变。MPLS网络传输过程，外层DSCP值也可以映射到MPLS EXP值中去。

如果按照DSCP优先级协商IPSec Sa，就可以解决Qos带来的乱序问题。

L3VPN CE作为IPSec安全网关

图5 报文封装转发流程

图6 QoS方案

报文加密后，原始IP报文头的DSCP值映射到IPSec头部的DSCP域；也可以单独设定外层IP头的DSCP值。

原始IP报文头的DSCP值映射到IPSec头部的DSCP值，经过加密MPLS网络传输后解密，原始IP报文头的DSCP值不变。MPLS网络传输过程，外层DSCP值也可以映射到MPLS EXP值中去，待解密之后，可以指定原始IP报文头的DSCP值。

如果按照DSCP优先级协商IPSec Sa，就可以解决Qos带来的乱序问题。

核心网设备根据DSCP值进行相应的QoS处理，承载网中，如果设备支持DSCP到802.1p的映射，在二层承载网中可根据802.1p进行QoS处理。