三、IPSec（Internet Protocol Security，互联网安全协议）_esp协议端口

3 IPSec（Internet Protocol Security，互联网安全协议）

3.1 概念

IPSec（Internet Protocol Security，互联网安全协议），是一组基于网络层的，应用密码学的安全通信协议族。IPSec协议族包含内容如图3.1所示。

图3.1 IPSec协议族

3.2 加密和验证

3.2.1 加密

在发送报文之前，源地址采用加密算法和加密密钥对报文进行加密，目的地址在收到加密IP报文之后，采用相同的加密算法和加密密钥进行解密，从而保证报文以加密形式进行传递，其实现过程如图3.2所示

图3.2 报文加密和验证

3.2.2 验证

验证过程如下：
（1）源地址在发送报文时，使用验证算法和验证密钥对消息进行先处理，得到签名，随后报文随签名一并发送。
（2）目的地址在接受到报文后使用相同的验证算法和验证密钥对消息进行处理，同样得到签名，然后对比报文中携带的签名，从而验证报文在传输过程中是否被篡改。详细验证过程如图3.3所示。

图3.3 报文验证过程

3.3 两个通信保护协议

IPSec融合了AH（Authentication Header，验证头）和ESP（Encapsulating Security Payload，封装安全载荷）。

3.3.1 AH协议

AH是报文头验证协议。AH对数据包和认证密钥进行Hash计算，接收方收到带有计算结果的数据包后，执行同样的Hash计算并与原计算结果比较，传输过程中对数据的任何更改将使计算结果无效，这样就提供了数据来源认证和数据完整性校验。AH协议的完整性验证范围为整个IP报文。
（1）AH提供的安全服务：
1）无连接数据完整性：通过哈希函数产生的校验来保证。
2）数据源认证：通过在计算验证码时加入一个共享秘钥来实现。
3）抗重放服务：AH报头中的序列号可以防止重放攻击。
（2）AH不提供任何保密性服务：不加密所保护的数据包。

3.3.2 ESP协议

ESP是封装安全载荷协议。ESP提供加密服务，所以原始IP包和ESP尾以密文的形式出现。ESP在验证过程中，只对ESP头部、原始数据包IP包头、原始数据包数据进行验证；只对原始的整个数据包进行加密，而不加密验证数据。
ESP提供的安全服务：
1）无连接数据完整性。
2）数据源认证。
3）抗重放服务。
4）数据保密。
5）有限的数据流保护

3.3.3 AH vs. ESP

AH只能验证，不能加密，ESP既能验证又能加密。二者可单独使用也可配合使用。

3.4 两种工作模式

3.4.1 隧道模式

隧道模式下，AH头或ESP头被插入到原始IP头之前并生成新的IP头，新IP头中的源/目的地址为隧道两端公网IP地址，隧道模式下报文封装形式如图3.4所示。

图3.4 隧道模式下报文封装形式
主要应用场景：经常用于私网与私网之间通过公网进行通信，建立安全VPN通道。

3.4.2 传输模式

传输模式下，AH头或ESP头被插入到IP头和传输层协议之间，其封装形式如图3.5所示。

图3.5 传输模式下报文封装形式
主要应用场景：经常用于主机和主机之间端到端通信的数据保护。

3.5 网络密钥交换协议（IKE）

3.5.1 概念

IKE（Internet key exchange，网络密钥交换协议），由ISAKMP（Internet Security Association and Key Management Protocol，Internet安全关联和密钥管理协议）和两种密钥交换协议OAKLEY与SKEME组成。

3.5.2 背景

（1）用IPSec保护一个IP包之前，必须先建立SA（Security Association，安全联盟）。
SA是两个IPSec通信实体之间经协商建立起来的一种共同协定，它规定了通信双方使用哪种IPSec协议保护数据安全、应用的算法标识、加密和验证的密钥取值以及密钥的生存周期等等安全属性值。通过使用安全联盟，IPSec能够区分对不同的数据流提供的安全服务。
（2）IPSec的安全联盟可以通过手工配置的方式建立。但是当网络中节点较多时，手工配置将非常困难，而且难以保证安全性。这时就可以使用IKE自动进行安全联盟建立与密钥交换的过程，IKE就用于动态建立SA，代表IPSec对SA进行协商。

3.5.3 用途

（1）IKE为IPSec协商生成密钥，供AH/ESP加解密和验证使用。
（2）在IPSec通信双方之间，动态地建立SA，对SA进行管理和维护。

3.6 IKEv1协商

IKEv1的协商过程包含两个阶段。

3.6.1第一阶段交换

通信各方彼此间建立了一个已通过身份验证和安全保护的通道，此阶段的交换建立了一个ISAKMP安全联盟，即ISAKMP SA（也可称为IKE SA）。第一阶段交换有主模式和野蛮模式两种协商模式。
（1）主模式协商（6个包）
IKEv1的主模式协商包含了三次双向交换，用到了六条ISAKMP信息。协商过程如下图3.6所示。

图3.6 IKEv1主模式协商过程
1）消息①和②用于策略交换
发起方发送一个或多个IKE安全提议，响应方查找最先匹配的IKE安全提议，并将这个IKE安全提议回应给发起方。匹配的原则为协商双方具有相同的加密算法、认证算法、认证方法和Diffie-Hellman组标识。
2）消息③和④用于密钥信息交换
双方交换Diffie-Hellman公共值和nonce值，用于IKE SA的认证和加密密钥在这个阶段产生。
3）消息⑤和⑥用于身份和
认证信息交换（双方使用生成的密钥发送信息），双方进行身份认证和对整个主模式交换内容的认证。
（2）野蛮模式协商（3个包）
野蛮模式只用到三个交互包，协商过程如图3.7所示。

图3.7 IKEv1野蛮模式协商过程
图7中，前两条消息①和②用于协商IKE安全提议，交换Diffie-Hellman公共值、必需的辅助信息以及身份信息，并且消息②中还包括响应方发送身份信息供发起方认证，消息③用于响应方认证发起方。

3.6.2 第二阶段交换

IKEv1协商的第二阶段的目的就是建立用来安全传输数据的IPSec SA，并为数据传输衍生出密钥。这一阶段采用快速模式（Quick Mode）。该模式使用IKEv1协商第一阶段中生成的密钥对ISAKMP消息的完整性和身份进行验证，并对ISAKMP消息进行加密，故保证了交换的安全性。其协商过程如图3.8所示。

图3.8 IKEv1第二阶段协商过程

3.6.3 主模式 vs. 野蛮模式

（1）区别

（2）应用场景
a）野蛮模式的场景：与主模式相比，野蛮模式减少了交换信息的数目，提高了协商的速度，但是没有对身份信息进行加密保护。虽然野蛮模式不提供身份保护，但它可以满足某些特定的网络环境需求：
①当IPSec隧道中存在NAT设备时，需要启动NAT穿越功能，而NAT转化会改变对等体的IP地址，由于野蛮模式不依赖于IP地址标识身份，使得采用预共享密钥验证方式时，NAT穿越只能在野蛮模式中实现。
②如果发起方的IP地址不固定或者无法预知，而双方都希望采用预共享密钥验证方法来创建IKE SA，则只能采用野蛮模式。
③如果发起方已知响应方的策略，或者对响应者的策略有全面的了解，采用野蛮模式能够更快地创建IKE SA。
b）主模式场景：
要求两端都是固定IP地址

3.7 IKEv2协商

3.7.1 背景

IKEv1存在以下缺陷，IKEv2在IKEv1的基础上进行了改进。
（1）IKEv1协商建立IPSec SA的时间太长
IKEv1主模式协商一对IPSec SA，需要6（协商IKE SA）+3（协商IPSec SA） =9条消息
IKEv1野蛮模式协商一对IPSec SA，需要3（协商IKE SA）+3（协商IPSec SA）=6条消息
IKEv2协商一对IPSec SA只需要2（协商IKE SA）+2（协商IPSec SA）=4条消息。后续每建立一对IPSec SA只会增加两条消息。协商建立IPSec SA的速度大大提升
（2）IKEv1不支持远程用户接入
IKEv1只能借助L2TP，通过PPP来对远程用户进行AAA认证。
（3）IKEv2增加了EAP方式的身份认证

3.7.2 IKEv2协商过程

IKEv2正常情况使用2次交换共4条消息就可以完成一对IPSec SA的建立，如果要求建立的IPSec SA大于一对时，每一对IPSec SA只需额外增加1次创建子SA交换，也就是2条消息就可以完成。
IKEv2定义了三种交换：初始交换（Initial Exchanges）、创建子SA交换（Create_Child_SA Exchange）以及通知交换（Informational Exchange）。
在IKEv2中将IKEv1中的主模式和野蛮模式换成了Inital Exchange，将快速模式阶段换成了CRATE_Child_SA。
（1）初始交换
初始交换过程图如图3.9所示。

图3.9 初始交换过程图
1）消息①和②属于第一次交换（称为IKE_SA_INIT交换），以明文方式完成IKE SA的参数协商，包括协商加密和验证算法，交换临时随机数和DH交换。IKE_SA_INIT交换后生成一个共享密钥材料，通过这个共享密钥材料可以衍生出IPSec SA的所有密钥。相当于IKEv1的主模式的第1、3个包。
2）消息③和④属于第二次交换（称为IKE_AUTH交换），以加密方式完成身份认证、对前两条信息的认证和IPSec SA的参数协商。IKEv2支持RSA签名认证、预共享密钥认证以及扩展认证方法EAP（Extensible Authentication Protocol）。EAP认证是作为附加的IKE_AUTH交换在IKE中实现的，发起者通过在消息3中省去认证载荷来表明需要使用EAP认证。
（2）创建子 SA 交换
当一个 IKE SA 需要创建多个 IPsec SA 时，使用创建子 SA 交换来协商多于一个的 SA，另外还可用于进行 IKE SA 的重协商功能。
（3）通知交换
用于传递控制信息，例如错误信息或通告信息。

3.8 IKEv1 vs. IKEv2

3.9 NAT穿越

3.9.1 NAT穿越场景

如图3.10所示场景，假设分舵没有公网IP，只能先由NAT设备进行地址转换，然后才能访问Internet，但是NAT会修改报文中的IP地址。而IPSec用于建立分部与总部之间的隧道，保护报文不被修改，并且FW_B防火墙上一般都配置了IPSec和NAT，那么分舵如何与总舵完成通信？这就需要在建立IPSec隧道的两个防火墙上同时开启NAT穿越（NAT Traversal）功能。

图3.10 NAT穿越场景

3.9.2 IPSec封装协议分析

观察图3.11（a）中传输模式下AH和ESP的封装可知，AH认证整个IP报文，当经过NAT转化后，肯定会认证不成功。在ESP封装下，虽然认证访问不包括IP头，但是因为通过NAT后，NAT修改了外层IP地址，由于TCP/UDP校验和的计算包含IP源目地址，所以TCP/UDP的校验和需要更新，但是现在TCP/UDP已经被ESP加密，中间路由器无法更新TCP/UDP的校验和，所以TCP的校验和检查最终会失败。
观察图3.11（b）中隧道模式下AH和ESP的封装可知，AH认证整个IP头部，包括新生成的IP头，这种情况当经过NAT后，IP地址发送变化，也肯定不能认证成功。在ESP的封装下，ESP的认证范围是从ESP头部到ESP尾部。当通过NAT时，改变的仅仅是外层IP头部，而内层TCP校验和因为内层IP头不变，所以校验会成功。但是也仅仅是可以通过NAT的一对一的转化，即不能转化端口号。因为端口是加密的。

（a）传输模式

（b）隧道模式
图3.11 传输模式和隧道模式下AH和ESP的封装
总结：
（1）AH的传输模式和隧道模式都不支持NAT穿越
（2）ESP传输模式也是不支持的
（3）ESP隧道模式默认只支持一对一NAT转换，不支持PAT

3.9.3 解决方案：NAT穿越

NAT-T技术，即在IP和ESP报文之间（AH协议不支持NAT穿越，故只能封装ESP报文）插入一个8个字节UDP头部（端口号默认为4500），如图3.12所示。有了这个UDP头IPSec报文就不怕被NAT设备修改IP地址和端口了。

图3.12 NAT-T技术原理

3.9.4 IKEv1的NAT穿越协商过程

IKEv1主模式下的NAT穿越过程为：
（1）IKEv1使用标识NAT穿越能力的VID载荷来确定通信双方是否支持NAT穿越，当双方在各自的消息中包含了VID载荷时，才会进行NAT-T协商。
（2）IKEv1使用NAT-D载荷探测两个IKE对等体之间是否存在NAT网关以及存在的位置（即谁在NAT网关的后面）。
（3）发现NAT网关后，后续ISAKMP消息的端口号转换为4500。
（4）在IKEv1第二阶段会协商是否使用NAT-T以及NAT-T时IPSec报文的封装模式：UDP封装隧道模式报文和UDP封装传输模式报文。
IKEv1为ESP报文封装UDP头，UDP报文端口号为4500。当封装报文通过NAT设备时，NAT设备对该报文的外层IP头和增加的UDP头进行地址和端口号转换，后续传输的ESP报文将都采用UDP封装

3.9.5 IKEv2的NAT穿越协商过程

IKEv2的NAT穿越协商过程为：
（1）IKEv2的NAT穿越场景中，IKE协商的发起方和响应方在IKE_SA_INIT交换中增加两个N载荷（在Ni和Nr载荷之后），一个消息类型为NAT_DETECTION_SOURCE_IP，标识发起方的IP地址；另一个消息类型为NAT_DETECTION_DESTINATION_IP，标识响应方的IP地址。这两个通知载荷用于检测在将要建立IPSec隧道的两个防火墙之间是否存在NAT，哪个防火墙位于NAT之后。
如果接收到NAT_DETECTION_SOURCE_IP通知载荷没有匹配数据包IP头中的源IP和端口的HASH值，则说明对端位于NAT网关之后。如果接受到的NAT_DETECTION_DESTINATION_IPIKE通知载荷没有匹配数据包IP头中的源IP和端口的HASH值，则说明本端位于NAT网关之后。IKEv2的NAT穿越协商过程如图3.13。

图3.13 IKEv2的NAT穿越协商过程
（1）检测到NAT网关后，从IKE_AUTH消息开始ISAKMP报文端口号改为4500，报文标识“Non-ESP Marker”。

3.10 GRE over IPSec

3.10.1 概念

IPSec将GRE隧道视为受保护对象，及报文先进行GRE封装，再进行IPSec封装，这种方式相当于两种不同类型的隧道叠加，称为GRE over IPSec。

3.10.2 两种模式下的GRE over IPSec封装

IPSec有两种封装模式：传输模式和隧道模式。IPSec对GRE隧道进行封装时，两种模式的封装效果也不相同。
（1）传输模式
传输模式下，AH头或ESP头被插入到新的IP头和GRE头之间，封装结果如图3.14所示。

图3.14 传输模式下GRE over IPSec封装
传输模式不改变GRE封装后的报文头，IPSec隧道的源地址和目的地址就是GRE封装后的源地址和目的地址。
（2）隧道模式
隧道模式下，AH头或ESP头被插入到新的新的IP头之前，另外再生成一个新的报文头放到AH头或ESP头之前，封装结果如图3.15所示。

图3.15 隧道模式下GRE over IPSec封装
隧道模式使用新的IPSec报文头来封装经过GRE封装后的消息。封装后的消息共有3个报文头：原始报文头、GRE报文头和IPSec报文头，Internet根据设备最外层的IPsec报文头来转发该消息。
在GRE over IPSec中，无论IPSec采用传输模式还是隧道模式，都可以保护两个网络之间的通信，这是因为GRE已经进行了一次封装，原始报文就可以是两个网络之间的报文。但是隧道模式跟传输模式相比增加了IPSec头，导致报文长度更长，更容易导致分片，所以推荐采用传输模式GRE over IPSec。