IPsec协议总结

1、IPsec 基本介绍

1.1 ipsec基本数据

1.2 ipsec 封装模式

• 传输模式
  传输模式在AH、ESP处理前后IP头部保持不变，主要用于End-to-End的应用场景。
  
• 隧道模式
  隧道模式则在AH、ESP处理之后再封装了一个外网IP头，主要用于Site-to-Site的应用场景
  

  1.3 主动模式交互流程

2 隧道模式下基本的封装和姐封装流程

2.1 封装流程

• 在原IP报文中找到TCP报文部分，在其后添加相应的ESP trailer信息。
  ESP trailer 包含三部分：Padding，Pad length 和 Next header。Padding 即使用块加密时，最后一个数据块长度不足时所做的填充。Pad length 指填充的长度，方便拆包时找到用来填充的数据段。Next header 标明被封装的原报文的协议类型，例如 6 = TCP。
• 将原 TCP 报文和第1步得到的 ESP trailer 作为一个整体进行加密封装。具体的加密算法和**由SA给出。
• 为第2步得到的密文添加 ESP 头。ESP 头由 SPI (Security Parameter Index) 和 Seq #
  两部分组成。密文和 ESP头合起来称为"enchilada"，构成认证部分。
• 附加完整性度量结果（ICV）。对第3步生成的"enchilada"认证部分做摘要（ESP Authentication
  Data），得到一个32位整数倍的 ICV，附在"enchilada"之后。ICV 生成算法和验证**由 SA 给出。
• 将原始的 IP 报文头中的协议号改为50（代表 ESP），然后将 IP 报文头加到第4步的结果之前构成 IPsec 报文。

2.2 解封装流程

• 接收方收到 IP 报文后，发现协议类型是50，标明这是一个 ESP 包。首先查看 ESP 头，通过安全参数索引号 SPI
  决定数据报文所对应的 SA，获得对应的模式（隧道或传输模式）以及安全规范。
• 根据 SA 指定的摘要算法和验证**计算"enchilada"的摘要值，与附在 IP 报文最后的 ICV
  进行对比，二者相同则数据完整性未被破坏。
• 检查 ESP 头中的 Seq # 里的***，保证数据是新的，避免重放攻击
• 根据 SA 所指定的加密算法和**，解密密文段，得到原来的 TCP 报文和 ESP trailer。
• 根据 ESP trailer 的填充长度信息，找出填充字段的长度，删除填充字段得到原来的 TCP 报文。 根据 TCP
• 报文头信息将报文交付给传输层。

ipsec 在穿透NAT的特殊处理

这个IPsec过程分两类报文，一类是IKE报文，一类是ESP报文。然后我们抛开ESP报文不讨论。现在，这个现象是这样的。除了第一次交互（也就是前两个包）使用500端口之外。之后的所以报文都使用4500端口进行通信。
即使是在发送IKE的rekey或reauth时，也使用4500端口。也就是说500端口，后续的报文序列里再也不会使用了。

当使用4500承载的时候，IKE报文头与UDP报文头之间，会插入4个字节的0，用来区分ESP报文和IKE报文。

1. 由UDP4500承载的ESP报文。2. 由UDP4500承载的IKE报文。3.由UDP500承载的IKE报文。
   然后我们假设不使用4500端口，而全部使用500端口来承载。之后会发生什么？ 首先，NAT设备是没有问题的，对于我们这里讨论或假设的任何场景。
   它都可以处理，而且NAT设备也不关心500是不是知名端口，也不对其进行特殊处理。
   好，然后，这三种报文都由UDP 500端口来承载。这个时候操作系统收到了udp 500的包的时候是没有办法区分出它到底是IKE还是ESP的。
   于是，我们面临一个选择。
   A：让操作系统首先进入IKE报文的处理流程，然后为ESP报文加一个特殊的MARK，从而进行区分，识别到ESP报文。
   B：让操作系统首先进入ESP报文的处理流程，然后为IKE报文加一个特殊的MARK，从而进行区分，识别到IKE报文。
   最终，这个选择里，RFC们选择了B。理由是ESP报文的数量远远多余IKE报文。在每一个包上加mark（也就是四个字节的0）作为一种资源消耗。两种陷害择其轻，自然便选择了IKE。
   参考资料：
2. IPSec v*n基本原理
3. IPSec方案部署
4. IPSec穿越NAT
5. IPSec拆包及封包流程（重要）
6. PSec NAT-T技术实现nat穿越
7. IPsec在NAT环境中应用
8. 华为ipsec配置介绍