目录
文章目录
- 目录
- IPSec 安全隧道协议族
- 封装协议
- Authentication Header
- Encapsulating Security Payload
- 封装模式
- 传输模式
- 隧道模式
- 安全偶联协商
- Security Association
- Internet Key Exchange
- IKE 的交换过程
- IPSec Virtual Private Network
- IPSec NAT-T
- Transport 模式
- Tunnel 模式
- NAT-Tranversal
- NAT-T 协商过程
- GRE over IPSec
IPSec 安全隧道协议族
IPSec(Internet Protocol Security,互联网协议安全)是一个基于 IP 网络的安全隧道协议族,包含了一系列认证、加密、隧道封装协议。
IPSec 通过以下 4 个方面的考量来实现安全通信:
- 机密性(Confidentiality):发送方对数据进行加密,以密文的形式在 IP 网络上传送,接收方对接收的加密数据进行解密后处理或直接转发。
- 完整性(Integrity):接收方对接收的数据进行校验,以判定报文是否被篡改。
- 身份认证(Data Authentication):接收方验证发送方身份是否合法。
- 防重放(Anti-Replay):接收方拒绝旧的或重复的数据包,防止恶意用户通过重复发送捕获到的数据包所进行的攻击。
IPSec 协议族主要由以下协议组成:
- 安全认证协议(Authentication Header,AH)
- 安全封装协议(Encapsulating Security Payload,ESP)
- 安全偶联协议(Security Association,SA)
- 安全密钥交换协议(Internet Key Exchange,IKE)
这些协议公共构建了 IPSec 的安全框架:
- 加密算法:
- 对称加密算法:AES、DES、3DES 等。
- 非对称加密算法:RSA、DH(Diffie-Hellman,交换及密钥分发)等。
- 验证算法:MD5、SHA-1、SHA-2 等 HASH 算法。
- 封装协议:ESP、AH 等协议。
- 封装模式:
- 传输模式(Transport):不改变 IP Header。
- 隧道模式(Tunnel):生成新的 IP Header。
封装协议
IPSec 具有 2 种封装协议,根据各自的特性被应用到不同的场景中。
Authentication Header
安全认证协议(Authentication Header,AH)本质是一种封装协议,对 IP 协议进行封装,会试图保护 IP 数据包的所有字段(包括:IP Header 和 Playload)。
AH 的 Header 封装格式如下图所示:
- 下一个头:标识被传送数据所属的协议。
- 载荷长度:认证头包的大小。
- 保留:为将来的应用保留,目前都置为 0。
- 安全参数索引:与 IP 地址一同用来标识安全参数。
- 串行号:单调递增的数值,用来防止重放攻击。
- 认证数据:包含了认证当前包所必须的数据。
Encapsulating Security Payload
安全封装协议(Encapsulating Security Payload,ESP)也是一种封装协议,与 AH 不同的是,ESP 会将 IP 数据包中的 Payload 进行加密后再封装到 IP 数据包,以保证数据的机密性,但 ESP 没有专门对 IP Header 的内容进行保护。
ESP 的 Header 封装格式如下图所示:ESP 处了在每一个 IP Header 后面添加一个 ESP Header 之外,还会在 IP 数据包末尾追加一个 ESP 尾部(包括:ESP Tail 和 ESP Auth data)。
- 安全参数索引:与 IP 地址一同用来标识安全参数。
- 串行号:单调递增的数值,用来防止重放攻击。
- 载荷数据:实际要传输的数据。
- 填充:某些块加密算法用此将数据填充至块的长度。
- 填充长度:以位为单位的填充数据的长度。
- 下一个头:标识被传送数据所属的协议。
- 认证数据:包含了认证当前包所必须的数据。
封装模式
IPSec 也提供了 2 种不同的封装模式,可以根据不同的应用场景进行选择:
- 安全性角度:Tunnel 优于 Transport。Tunnel 可以完全地对原始 IP 数据包进行验证和加密,所以 Tunnel 可以隐藏内部 IP 地址、协议类型和端口等信息。
- 性能角度:Tunnel 低于 Transport。因为 Tunnel 有一个额外的 IP 头,所以它会比 Transport 占用更多带宽。
传输模式
传输模式(Transport):不改变 IP Header。
隧道模式
隧道模式(Tunnel):生成新的 IP Header。
安全偶联协商
Security Association
IPSec 隧道需要在两端建立 Security Association(安全偶联),通过 SA 协议的交互流程来提供并保存两端约定好的加密协议、对称秘钥、对端 IP 地址等信息,这些信息是 AH 或 ESP 封装协议所需要使用到的参数。
SA 建立成功之后,就可以对原始的 IP 数据包进行安全传输了(认证和加密)。其中,对称秘钥要通过 IKE 协议来进行互换,然后通过在原始网络包外层添加 AH 或 ESP Header 来实现加密。
SA 由一个三元组来唯一标识,包括:
- SPI(Security Parameter Index,安全参数索引)
- 目的 IP 地址
- 安全协议号(AH 或 ESP)
SA 中的 SPI 是用于唯一标识一个 SA 的 32bits 数值,它在 AH 或 ESP Header 中传输。
- 手工(Manual)配置 SA 时,需要手工指定 SPI 的取值;
- 使用 IKE 自动协商(ISAKMP)SA 时,SPI 将随机生成。
另外,手工方式建立的 SA 永不老化,而通过 IKE 协商建立的 SA 具有生存周期,IKE 协商建立的 SA 的生存周期有两种定义方式:
- 基于时间的生存周期,定义了一个 SA 从建立到失效的时间;
- 基于流量的生存周期,定义了一个 SA 允许处理的最大流量。
生存周期到达指定的时间或指定的流量,SA 就会失效。SA 失效前,IKE 将为 IPsec 协商建立新的 SA。这样,在旧的 SA 失效前新的 SA 就已经准备好。
- 在新的 SA 开始协商而没有协商好之前,继续使用旧的 SA 保护通信。
- 在新的 SA 协商好之后,则立即采用新的 SA 保护通信。
Internet Key Exchange
安全密钥交换协议(Internet Key Exchange,IKE)建立在由 ISAKMP(Internet Security Association and Key Management Protocol,互联网安全联盟和密钥管理协议)定义的框架之上,用于安全的完成密钥交换,并提供了身份认证、分发密钥、自动建立 SA 等功能。
在 IPSec 场景中,IKE 为 IPSec 提供了自动协商交换密钥、建立 SA 的服务,能够减少了密钥协商的开销。通过 IKE 建立和维护 SA 的服务,还可以简化了 IPSec 的使用和管理,包括:
- 因为有了 IKE,IPsec 很多参数(e.g. 密钥)都可以自动建立,降低了手工配置的复杂度。
- IKE 协议中的 DH 交换过程,每次的计算和产生的结果都是不相关的。每次 SA 的建立都运行 DH 交换过程,保证了每个 SA 所使用的密钥互不相关。
- IPSec 使用 AH 或 ESP 报文头中的序列号实现防重放。此序列号是一个 32bits 的值,此数溢出后,为实现防重放,SA 需要重新建立,这个过程需要 IKE 协议的配合。
- 对安全通信的各方身份的认证和管理,将影响到 IPSec 的部署。IPSec 的大规模使用,必须有 CA(Certificate Authority,认证中心)或其他集中管理身份数据的机构的参与。
- IKE 提供端与端之间动态认证。
IKE 的交换过程
值得注意的是,IKE 不是简单的在网络上传输密钥,而是通过一系列数据的交换,最终计算出双方共享的密钥,并且即使第三者截获了双方用于计算密钥的所有交换数据,也不足以计算出真正的密钥。
IKE 使用了两个阶段为 IPsec 进行密钥协商并建立 SA:
-
通信各方彼此间建立了一个已通过身份认证和安全保护的通道,即:建立一个 ISAKMP SA。第一阶段有主模式(Main Mode)和野蛮模式(Aggressive Mode)两种 IKE 交换方法。
-
用在第一阶段建立的安全隧道为 IPSec 协商安全服务,即:为 IPsec 协商具体的 SA,建立用于最终的 IP 数据安全传输的 IPsec SA。
第一阶段主模式的 IKE 协商过程中包含三对消息:
- 第一对叫 SA 交换,是协商确认有关安全策略的过程;
- 第二对消息叫密钥交换,交换 Diffie-Hellman 公共值和辅助数据(如:随机数),密钥材料在这个阶段产生;
- 最后一对消息是 ID 信息和认证数据交换,进行身份认证和对整个第一阶段交换内容的认证。
野蛮模式交换与主模式交换的主要差别在于,野蛮模式不提供身份保护,只交换 3 条消息。在对身份保护要求不高的场合,使用交换报文较少的野蛮模式可以提高协商的速度;在对身份保护要求较高的场合,则应该使用主模式。
IPSec Virtual Private Network
IPSec 隧道常被作为 Virtual Private Network,有以下应用场景:
-
Site-to-Site(站点到站点,或者网关到网关):如企业的多个机构分布在互联网的多个不同的地方,各使用一个应用层网关相互建立 VPN 隧道,企业各分机构内网的用户之间的数据通过这些网关建立的 IPSec 隧道实现安全互联。
-
End-to-End(端到端,或者 PC 到 PC):两个位于不同网络的 PC 之间的通信由两个 PC 之间的 IPSec 会话保护,而不是由网关之间的 IPSec 会话保护。这种 IPSec VPN 是通过一些 IPSec VPN 客户端软件,如:Windows、Linux 桌面操作系统中自带的 IPSec VPN 客户功能,Huawei VPN Client 等客户端软件,结合 Window 或 Linux 服务器系统中自带的 IPSec VPN 服务器功能来实现的。
-
End-to-Site(端到站点,或者 PC 到网关):两个位于不同网络的 PC 之间的通信由网关和异地 PC 之间的 IPSec 进行保护。在IPSec VPN 客户端方面同样可利用 Windows、Linux 桌面操作系统中自带的 IPSec VPN 客户功能,通常是采用 L2TP over IPSec 方案来部署,即在 L2TP VPN 基础上采用 IPSec 来提供更好的安全保护。
IPSec NAT-T
IPSec 和 NAT 具有一定的冲突,包括:
- AH 传输模式和隧道模式都不支持 NAPT。
- ESP 传输模式都不支持 NAPT。
- ESP 隧道模式只支持一对一的 NAT,不支持 PAT。
Transport 模式
-
AH 封装协议的数据完整性校验(Authenticate)范围为整个 IP 报文,NAT 会修改 IP Header 的 Address,所以就会导致接收方 Authenticate 失败。而 PAT 会修改 TCP Header 的 Port,也会导致 Authenticate 失败。
-
ESP 封装协议的 Authenticate 范围为 ESP Header 和 ESP Tail(尾部)之间。因为 ESP 不校验 IP Header 所以 NAT 行为并不会导致接收方的 Authenticate 失败,但由于 NAT 修改了 IP Header 中的 Address,理论上后面的 TCP checksum 也会随之修改,而 TCP checksum 已经属于 ESP 校验范围之内了,NAT 设备无法进行修改,所以接收端在 TCP 层接收时会导致 checksum 校验失败。
Tunnel 模式
-
AH 协议的 Tunnel 模式的 Authenticate 范围会包含外层的 New IP Header,因此 NAT 同样会造成接收方 Authenticate 失败。
-
ESP 协议的 Tunnel 模式经过 NAT 设备后,内层 IP Header 并不会被改变,所以 TCP checksum 也不会改变,接收方也就不会再出现 checksum 失败了。但也存在着缺点:它只能支持一对一的 NAT,即:NAT 设备后面只有一台内网主机。如果考虑 PAT 来补充的话,又回因为 TCP Header 已经被加密而无法实现。
NAT-Tranversal
为了解决上述问题的技术就是 NAT-T,IPSec 的 NAT-T 解决方案是 ESP-UDP-Encapsulate(封装),即:在 ESP Header 前加上一个 New UDP Header,源和目的端口号均是 4500,使得 NAT 设备按照处理一个普通的 UDP 数据包的方式对它处理。这个方法同时适用于 ESP-Transport 和 ESP-Tunnel 模式,以及同时支持 PAT 和 NAT。
-
UDP-Encapsulated-Transport 模式
-
UDP-Encapsulated-Tunnel 模式
示例:NAT 设备后有两台内网主机,它们都与 Server 建立 IPSec 连接。
NAT-T 协商过程
IPSec 两端需要在 IKE 完成协商后才能使用 NAT-T。
阶段一:
- 探测出双方都支持 NAT-T。
- 探测出双方报文传输路径上存在 NAT 设备。
- 前 4 个 Msg 都是使用 Sport=Dport=500 进行通信。但当探测到 NAT 设备后,作为 Initiator 再发出第 5 个 Msg 就会将端口切换到 Sport=Dport=4500,Responder 收到该消息后,如果解密成功,后续也会使用新的 4500 端口。注意,RFC3948 规定了 New UDP Header 中的端口要使用和 IKE 协商时相同的端口号,这个端口号在 RFC3947 中规定为 4500。
阶段二:
- 双方协商 NAT-T 的封装模式,UDP-Encapsulated-Tunnel 还是 UDP-Encapsulated-Transport。
- 其中,UDP-Encapsulated-Transport 模式还会向对方发送自己的原始 IP 地址,让对方可以据此修正后续 TCP 报文的 checksum。要知道,经过 NAT 设备之后,报文的 IP 地址发生了变化,就会导致接收端校验失败。IPsec 采用的方法是在 IKE 协商时,就将自己原始 IP 地址信息发给对端,这样 Server 在解密出 TCP 报文后,可以根据这个信息修正 checksum。
GRE over IPSec
GRE over IPSec,首先通过 GRE 对报文进行封装,然后再由 IPSec 对封装后的报文进行加密和传输。协议栈结构如下:
这种做法实现了两个 Peer 之间安全,底层怎么路由,封装 IPsec 都不管。常见的 L2TP,譬如 IP over IP 等等,其实也都是属于这个范畴的。这种做法的缺点是两端需要单独再起一个服务来实现这些封装。