参考链接：https://support.huawei.com/enterprise/zh/doc/EDOC1000122878?section=j004

IPSec 特性全景

　　

1.介绍

　　由于IP报文本身并不集成任何安全特性，恶意用户很容易便可伪造IP报文的地址、修改报文内容、重播以前的IP数据包以及在传输途中拦截并查看数据包的内容。因此，传统IP层协议不能担保收到的IP数据包的安全。在应用层保证网络安全的方法只对特定的应用有效，不够通用。人们迫切需要能够在IP层提供安全服务的协议，这样可以使TCP/IP高层的所有协议受益。IPSec（Internet Protocol Security）正是用来解决IP层安全性问题的技术。IPSec是Internet工程任务组（IETF）制定的一个开放的网络层安全框架协议。它并不是一个单独的协议，而是一系列为IP网络提供安全性的协议和服务的集合。IPSec主要包括安全协议AH（Authentication Header）和ESP（Encapsulating Security Payload），密钥管理交换协议IKE（Internet Key Exchange）以及用于网络认证及加密的一些算法等。
　　IPSec主要通过加密与验证等方式，为IP数据包提供安全服务。IPSec可以提供的安全服务包括：
　　※ 用户数据加密：通过用户数据加密提供数据私密性。
　　※ 数据完整性验证：通过数据完整性验证确保数据在传输路径上未经过篡改。
　　※ 数据源验证：通过对发送数据的源进行身份验证，保证数据来自真实的发送者。
　　※ 防止数据重放：通过在接收方拒绝重复的数据包防止恶意用户通过重复发送捕获到的数据包进行攻击。

2.应用场景

　　1）运营商场景　　

　　a）点到点VPN（Site-to-Site VPN）
　　IPSec可以为任何基于IP的通信提供安全保护，既可以保护传统的固定网络，也可以保护LTE等移动网络。无论是针对固定网络还是移动网络，运营商场景里IPSec的应用大都可以归结为点到点VPN和基于GRE over IPSec这两种。点到点VPN也称网关到网关VPN（Gateway to Gateway VPN），可以保证两个网关之间IP流量的安全性。典型组网如图2-1所示。

　　

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

　　b）GRE over IPSec

　　IPSec本身不支持封装组播、广播和非IP报文。当需要在IPSec VPN上传输这些报文时，可以使用GRE先将其封装为IP报文，然后再进行IPSec封装。如图2-2所示。

　　

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

　　

　　2）企业场景

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

　　企业场景里IPSec主要用于公司之间通过IPSec VPN网络互连或者移动员工远程接入公司网络，典型应用除了前面提到的点到点VPN和GRE over IPSec，还有IPSec over L2TP。企业场景里IPSec的组网更加灵活多样。点到点VPN主要用于公司总部与分支机构之间建立IPSec隧道，从而实现局域网之间互通。

　　

　　b）GRE over IPSec

　　GRE over IPSec可以提供在总部和分支之间传送广播、组播的业务，例如视频会议或动态路由协议消息等等。

　　

　　c）IPSec over L2TP

　　IPSec over L2TP，即先用IPSec封装报文后再用L2TP封装，通过L2TP实现用户验证和地址分配，并利用IPSec保障安全性。如图2-8所示，DeviceA作为接入服务器，使用PPP拨号方式发起PPP会话，触发L2TP隧道创建。L2TP隧道建立成功后，LNS生成一条通往DeviceA的路由；DeviceA获取IP地址，并发起IPSec隧道创建。

　　

　　d）点到多点VPN（Hub-Spoke VPN）

　　实际组网中最常见的是公司总部与多个分支机构通过点到多点IPSec VPN互通。

　　

　　在这种组网中，用户可以根据实际需求配置IPSec、L2TP over IPSec或GRE over IPSec。此时网络内数据流量可能存在如下两种情况：

　　※各分支机构之间不需要通信只有总部和分支之间部署IPSec VPN，也只有总部和分支之间存在业务流量。如图2-10所示。

　　

　　※各分支机构之间需要通信分支机构之间通过总部进行通信，如图2-11所示。

　　

3.IPSec 协议框架

　　1）安全协议

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

　　※AH是报文头验证协议，主要提供数据源验证、数据完整性验证和防报文重放功能，不提供加密功能。

　　※ESP是封装安全载荷协议，主要提供加密、数据源验证、数据完整性验证和防报文重放功能。虽然AH协议和ESP协议都可以提供数据源验证和数据完整性校验服务，但是两者不能互相取代。两者之间的差别在于验证报文的范围不同，验证范围请参见封装模式。

安全特性

AH

ESP

IP协议号

51

50

数据完整性校验

支持（验证整个IP报文）

支持（不验证IP头）

数据源验证

支持

支持

数据加密

不支持

支持

防报文重放攻击

支持

支持

IPSec NAT-T（NAT穿越）

不支持

支持

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

　　2）封装模式

　　a）传输模式：在传输模式下，AH或ESP被插入到IP头之后但在所有传输层协议或者其他IPSec协议之前。

　　

　　传输模式不改变IP报文头，只是IP协议字段被改为AH或者ESP，并重新计算IP报文头校验和，故IPSec隧道的源和目的地址必须为IP报文头中的源和目的地址，所以只适用于两台主机之间的通讯。

　　传输模式下，AH协议的完整性验证范围为整个IP报文，IP报文内容改变会导致接收端AH认证失败，因此AH与必须改变IP报文头中的IP地址的NAT协议无法共存。ESP协议验证报文的完整性检查部分包括ESP头、传输层协议头、数据和ESP尾，但不包括IP报文头，因此ESP协议无法保证IP报文头的安全，却可以与NAT协议共存。ESP的加密部分包括传输层协议头、数据和ESP尾。

　　b）隧道模式

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

　　

　　隧道模式隐藏了原始IP报文头信息，因此主要应用于两台VPN网关之间或一台主机与一台VPN网关之间的通信。隧道模式下，AH协议的完整性验证范围为包括新增IP头在内的整个IP报文。ESP协议验证报文的完整性检查部分包括ESP头、原IP头、传输层协议头、数据和ESP尾，但不包括新IP头，因此ESP协议无法保证新IP头的安全。ESP的加密部分包括传输层协议头、数据和ESP尾。当安全协议同时采用AH和ESP时，AH和ESP协议必须采用相同的封装模式。

　　c）传输模式和隧道模式比较

　　※ 从安全性来讲，隧道模式优于传输模式。它可以完全地对原始IP数据包进行验证和加密。隧道模式下可以隐藏内部IP地址，协议类型和端口。

　　※从性能来讲，隧道模式因为有一个额外的IP头，所以它将比传输模式占用更多带宽。

　　3）加密算法

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

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

　　a）数据加密

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

　　

　　用于加密的对称密钥可以手工配置，也可以通过DH算法生成并在两端设备共享。

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

　　※DES（Data Encryption Standard）：使用56bit的密钥对一个64bit的明文块对IP报文进行加密。
　　※3DES（Triple Data Encryption Standard）：使用三个56bit的DES密钥（共168bit密钥）对明文形式的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报文进行加密。
　　※SM4：使用128比特的密钥对协议报文进行加密。
　　3DES比DES安全得多，但是其加密速度慢于DES。AES比3DES更安全。

　　b）协议消息加密协议消息加密用于IKE协商阶段。协议消息加密所用的算法也是DES、3DES和AES。用于加密的对称密钥通过DH算法生成。

　　4）认证算法　　

　　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验证配合使用的过程如图2-21所示。

　　

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

　　一般来说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比特的消息摘要。
　　※SM3：通过输入长度小于264比特的消息，产生256比特的消息摘要。
　　SHA-2的消息摘要长于MD5和SHA-1，因此，SHA-2比MD5和SHA-1更安全。

　　5）密钥算法

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

　　a）密钥交换方法

　　使用对称密钥进行加密、验证时，如何安全地共享密钥是一个很重要的问题。有两种方法解决这个问题：
　　※带外共享密钥
　　在发送、接收设备上手工配置静态的加密、验证密钥。双方通过带外共享的方式（例如通过电话或邮件方式）保证密钥一致性。这种方式的缺点是可扩展性差，在点到多点组网中配置密钥的工作量成倍增加。另外，为提升网络安全性需要周期性修改密钥，这种方式下也很难实施。
　　※使用一个安全的连接分发密钥

　　IPSec使用IKE协议在发送、接收设备之间安全地协商密钥。IKE采用DH算法在不安全的网络上安全地交换密钥信息，并生成加密、验证密钥。这种方式配置简单，可扩展性好，特别是在大型动态的网络环境下此优点更加突出。

　　IKE提供密钥交换，自动协商建立安全联盟等服务。采用IKE协议可以使IPSec配置和管理更简单、更灵活。l Internet安全联盟和密钥管理协议ISAKMP（Internet Security Association and Key Management Protocol）是IKE的基础，IKE使用ISAKMP协议定义密钥交换的过程。ISAKMP提供了对安全服务进行协商的方法，密钥交换时交换信息的方法，以及对对等体身份进行验证的方法。
　　※IKE的精髓在于它永远不在不安全的网络上传送密钥，而是通过一些数据的交换，通信双方最终计算出共享的密钥，并且即使第三方截获了双方用于计算密钥的所有交换数据，也无法计算出真正的密钥。其中的核心技术就是DH（Diffie Hellman）交换技术。
　　b）DH 密钥交换
　　DH用于产生密钥材料，并通过ISAKMP消息在发送和接收设备之间进行密钥材料交换。然后，两端设备各自计算出完全相同的对称密钥。该对称密钥用于加密和验证密钥的计算。在任何时候，双方都不交换真正的密钥。

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

4.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。

　　

　　安全联盟还与协议相关。如果主机A和主机B同时使用AH和ESP进行安全通信，对于主机A就需要四个SA，AH协议的两个SA（入方向和出方向上各一个SA）和ESP协议的两个SA（入方向和出方向上各一个SA）。同样地，主机B也需要四个SA。安全联盟由一个三元组来唯一标识。这个三元组包括：安全参数索引SPI（SecurityParameter 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两个版本，二者建立安全联盟的方式大体相同，

　　IKE 的安全机制

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

　　1）IKEv1 协商安全联盟的过程

　　采用IKEv1协商安全联盟主要分为两个阶段。
　　1. IKEv1阶段1的目的是建立IKE SA。IKE SA建立后对等体间的所有ISAKMP消息都将通过加密和验证，这条安全通道可以保证IKEv1阶段2的协商能够安全进行。
　　2. IKEv1阶段2的目的就是建立用来传输数据的IPSec SA。
　　a）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报文。交换密钥相关信息的操作在身份认证之前完成，故设备的身份信息受到已生成的共享密钥的保护。

　　

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

　　1. 协商对等体之间使用的IKE安全提议。

　　a. DeviceA发送ISAKMP消息，携带建立IKE SA所使用的参数（由IKE安全提议定义）。
　　b. DeviceB对DeviceA的IKE安全提议进行协商。在协商时将从优先级最高的提议开始匹配，协商双方必须至少有一条匹配的IKE安全提议才能协商成功。匹配的原则为协商双方具有相同的加密算法、认证算法、认证方法和Diffie-Hellman组标识。
　　c. DeviceB响应ISAKMP消息，携带经协商匹配的安全提议及参数。 如果没有匹配的安全提议，DeviceB将拒绝发起方的安全提议。
　　2. 使用DH算法交换与密钥相关的信息，并生成密钥。
　　a. 两个对等体通过两条ISAKMP消息（3、4）交换与密钥相关的信息。
　　b. 由获得的密钥信息推导出4个密钥。其中SKEYID为基础密钥，通过它可以推导出SKEYID_a，为ISAKMP消息完整性验证密钥；可以推导出SKEYID_e，为ISAKMP消息加密密钥；可以推导出SKEYID_d，用于衍生出IPSec报文加密、验证密钥。
　　预共享密钥方式和数字证书方式下SKEYID的计算公式不同。

　　3. 对等体之间验证彼此身份。

　　a. 两个对等体通过两条ISAKMP消息（5、6）交换身份信息（预共享密钥方式下为IP地址或名称，数字证书方式下还需要传输证书的内容），身份信息通过SKEYID_e加密，故可以保证身份信息的安全性。
　　b. 两个对等体使用IKE安全提议中定义的加密算法、验证算法、身份验证方法和SKEYID_a、SKEYID_e对IKE消息进行加解密和验证。
　　IKEv1支持如下身份验证方法：
　　– 预共享密钥
　　这种方法要求对等体双方必须要有相同的预共享密钥（该密钥直接参与SKEYID的生成计算）。对于设备数量较少的VPN网络来说易于配置，在大型VPN网络中，不建议采用预共享密钥来做身份验证。
　　– RSA签名（通常称为数字证书）
　　数字证书需要由CA服务器来颁发。这种方法适用于大型动态的VPN网络。证书验证和预共享密钥验证的主要区别在于SKEYID的计算和交换的身份信息，其他的交换和计算过程和预共享密钥验证方式相同。
　　– 数字信封认证
　　在数字信封认证中，发起方采用对称密钥加密信息内容，并通过非对称密钥的公钥加密对称密钥，从而保证只有特定的对端才能阅读通信的内容，从而确定对端的身份。
　　说明：此认证方法只能在IKEv1的主模式协商过程中使用，不能在IKEv1野蛮模式协商过程中使用。

　　野蛮模式

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

　　

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

　　1. DeviceA发送ISAKMP消息，携带建立IKE SA所使用的参数、与密钥生成相关的信息和身份验证信息。
　　2. DeviceB对收到的第一个数据包进行确认，查找并返回匹配的参数、密钥生成信息和身份验证信息。
　　3. DeviceA回应验证结果，并建立IKE SA。
　　与主模式相比，野蛮模式的优点是建立IKE SA的速度较快。但是由于密钥交换与身份认证一起进行，野蛮模式无法提供身份保护。
　　主模式与野蛮模式的区别
　　野蛮模式安全性比主模式差。但是野蛮模式可以满足某些特定场合的网络环境的需求。例如：l 远程访问时，如果响应者（服务器端）无法预先知道发起者（终端用户）的地址、或者发起者的地址总在变化时，而双方都希望采用预共享密钥验证方法来创
建IKE SA，此时可以采用野蛮模式。　　

　　如果发起者已知响应者的策略，或者对响应者的策略有全面的了解，采用野蛮模式能够更快地创建IKE SA。

　　IKEv1 协商阶段2

　　IKEv1阶段2的目的就是建立用来传输数据的IPSec SA。

　　

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

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

　　

　　快速模式共有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，确认与响应方可以通信，协商结束。

　　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）。

　　

　　详细说明如下：

　　a. 第一个消息对（IKE_SA_INIT）
　　这个消息对负责进行IKE安全联盟参数的协商，包括协商加密和验证算法，交换临时随机数（nonces）和DH交换。

　　IKE_SA_INIT交换后可以生成一个共享密钥材料。通过这个共享密钥材料可以生成其他相关密钥。

　　b. 第二个消息对（IKE_AUTH）
　　从IKE_AUTH交换开始，所有报文都必须加密再交换。IKE_AUTH交换至少需要两个消息。在这两个报文的交互中完成了身份认证以及一个CHILD_SA的创建过程。
　　IKEv2支持RSA签名认证、预共享密钥认证。RSA签名认证和预共享密钥认证方式下，认证载荷（AUTH载荷）的计算方式不同。在IKE_SA_INIT交换阶段，生成IPSec SA的密钥材料，并通过这个密钥材料衍生出IPSec SA的所有密钥。
　　IKEv2除支持RSA签名和预共享密钥认证外，还支持在RFC 3748中定义的扩展认证方法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保护下进行，也就是说通知交换只能发生在初始交换之后。

　　综上，有如下结论： 

　　第一阶段作用：对等体之间彼此验证对方，并协商出IKE SA，保护第二阶段中IPSec SA协商过程； 

　　第二阶段作用：协商IPSec单向SA，为保护IP数据流而创建；

5.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来做安全保护。

　　

　　

6.IPSec 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表项，重新执行隧道新建流程。

7.完善的前向安全性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密钥之间相互没有关联，即使攻击者攻克了一个密钥，也只能破解这个密钥保护的数据，而不能破解受其它密钥保护的数据。

8.安全联盟生存周期

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

　　※ 基于时间的生存周期是从安全联盟建立开始的时刻起，此安全联盟存活的时间。

　　※基于流量的生存周期是此安全联盟允许处理的最大流量。
　　其中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协商安全联盟时，如果采用的安全策略没有配置自己的超时时间，将采用全局超时时间与对端协商。如果安全策略配置了自己的超时时间，则系统使用安全策略自己的超时时间与对端协商。

9.IPSec NAT 穿越

　　1）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隧道模式的封装中，TCP或UDP报文头使用了ESP加密，从而无法更改校验和。由于IP地址或端口号已经被NAT更改，目的地的校验和检验就会失败。这就导致ESP封装的传输模式无法与NAT共存。
　　※ESP封装的隧道模式：ESP隧道模式将整个原始的IP包整个进行了加密，且在ESP的头部外面新加了一层IP头部，所以NAT如果只改变最前面的IP地址对后面受到保护的部分是不会有影响的。因此，IPSec采用ESP的隧道模式来封装数据时可以与NAT共存。
　　2）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报文头。采用上述方式，ESP封装的传输模式和隧道模式报文均可以穿越NAT。增加UDP报文头后传输模式和隧道模式的报文格式如图2-33所示。

　　

　　3）IKEv2 与NAT 穿越

　　NAT-T能力检测
　　NAT-T能力检测在IKE协商的前两个消息中交换完成，通过在消息中插入一个标识NATT能力的Vendor ID载荷来告诉对方自己对该能力的支持。如果双方都在各自的消息中包含了该载荷，说明双方对NAT-T都是支持的。只有双方同时支持NAT-T能力，才能继
续进行其他协商。
　　NAT网关发现
　　当存在NAT设备时必须使用UDP传输，所以在IKEv2中的第一阶段协商中必须先探测是否存在NAT设备，也就是NAT探测。通过发送NAT-D载荷来实现NAT探测是目前比较流行的方法。

　　NAT穿越的启用

　　在第一阶段协商完成之后，协商双方均已经明确是否存在NAT，以及NAT的位置。至于是否启用NAT穿越，则由快速模式协商决定。NAT穿越的启用协商在快速模式的SA载荷中进行。传输模式下，协商双方可向对端发送IPSec报文的原始地址，从而使对端有可能在NAT转换之后，对TCP/IP进行校验和修正。
　　NAT-keepalive
在NAT网关上NAT会话有一定的存活时间，因此，隧道建立后如果中间长时间没有报文穿越，就会导致NAT会话被删除，这样将导致无法通过隧道传输数据。解决方法是在NAT会话超时前，发送一个NAT-keepalive给对端，维持NAT会话的存活。