IPSec下隧道模式和传输模式的装包与拆包
隧道模式下的ESP协议运作过程
装包过程
对原始IP报文的处理:
- 添加ESP尾部
- Padding:加密算法是块加密的话,就需要填充
- Pad length:补上填充长度
- Next header:用于标明原报文的协议类型,IPv4 or IPv6。
- 对ESP尾部和原始IP数据报文进行加密:由SA给出加密算法和**。
- 插入新的ESP头:SPI和一个Seq#,与加密数据部分构成认证部分"enchilada"。
- 插入ESP MAc到数据报尾部:完整性的度量结果,对认证部分"enchilada"做消息摘要,得到一个32位整数倍的完整性度量值。完整性度量算法和验证**由SA给出。
- 生成新的IP数据报头。新IP地址路由器和安全网关解释。协议类型50,封装ESP。
拆包过程
- 接受IP报文,解析报头,确定协议类型50为ESP报文。
- 解析ESP header,通过SPI确定数据报文以及所对应的SA,得到安全规范。
- 计算"enchilada"部分摘要和尾部摘要进行比对,验证数据的完整性
- 检查***Seq#保证数据的“新鲜”,防止重放攻击。
- 根据SA提供的加密算法和**,解密数据,得到原IP报文和ESP tailer。
- 根据ESPtrailer的填充长度信息,找出填充字段的长度,删除得到原始IP报文。
- 最后根据原IP报文的目的地址进行转发。
传输模式下的ESP协议运作过程-装包和拆包
与隧道模式不同,传输模式下的ESP报文只对IP数据报的有效载荷进行加密。以下对IPSec传输模式装包拆包进行阐述。
装包过程
- 在原 IP 报文末尾添加尾部信息(ESP trailer)。
尾部包含三部分。分别是 Padding,Pad length, Next header。各部分的作用如下:
- Padding: 由于加密算法可能是块加密算法,如果最后一个块长度不够时,需要进行填充,填充数据就是Padding 的内容。
- Pad length: 标识填充数据的长度,方便解析。
- Next header:用来表明被加密的数据报文类型,如TCP = 6。
- 封装密文。
将原 IP 数据报中的原 TCP 报文和第一步得到的尾部信息作为一个整体进行加密封装得到密文。具体的加密算法和**由 SA 给出。 - 添加 ESP 头。
第 2 步得到的密文头部需要添加一个 ESP 头,ESP 头由 SPI 和 Seq# 两部分组成。其中 SPI 为安全参数索引,用于关联 IPSec 数据和 SA;而 Seq# 则是用于保证数据报的唯一性,作为数据包的标识。 - 认证部分。
密文和第 3 步的 ESP header 合起来称为 “enchilada”, 构成认证部分。 - 附件完整性度量结果 (ICV)
对认证部分做摘要,得到一个 32 位整数倍的 ICV,附在认证部分之后。 ICV 摘要算法和验证**由 SA给出。 - 将原始 IP 数据报头的协议号改为 50,得到新的 IP 数据头,表明该数据包为 ESP 协议的报文,然后将该 IP 报文头添加到第5步的结果之前构成传输模式下的 IPSec 报文。
装包的示意图如下:
拆包过程
- 接收方收到 IP 报文,判断报文的协议类型,如果是 50, 则表明该数据包被封装为一个 ESP 包。下一步按照解析ESP的规则,对 ESP 包进行解析。
- 首先查看 ESP header 部分。获取 ESP头部的 SPI 安全参数索引号,通过该索引号查询 SAD (安全关连数据库)得到该数据报文对应的SA。并检查 Seq# 字段判断报文是否“新鲜”,防止重放攻击。
- 解析 SA 数据。获得对应的 IPSec 模式以及相关的安全规范。若 IPSec 模式为传输模式,则按下述方式解包。
- 根据 SA 中的摘要算法和验证**计算认证部分 “enchilada” 的摘要值。与附在 IP 报文最后的完整性度量值 ICV 进行对比,二者相同则数据完整。
- 根据 SA 指定的加密算法和**,解密密文段,得到原来的 TCP 报文和 ESP 尾部信息。
- 根据 ESP trailer 的填充长度信息,找到填充字段的长度,删除填充字段得到原来的 TCP 报文。
- 根据 TCP 报文头的信息将报文交付给传输层。