Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

IPsec 基础知识

IPsec 概述

IPsec 是一套相关协议,用于在 IP 数据包层加密地保护通信。IPsec 还提供了手动和自动协商安全关联 (SA) 和密钥分配的方法,所有属性均聚合在解释域 (DOI) 中。IPsec DOI 是一个文档,其中包含成功协商 VPN 隧道所需的所有安全参数的定义 —本质上,即 SA 和 IKE 协商所需的所有属性。有关详细信息,请参阅 RFC 2407 和 RFC 2408。

要使用 IPsec 安全服务,请在主机之间创建 SA。SA 是一种简单的连接,允许两个主机通过 IPsec 安全地相互通信。有两种类型的 SA:手动和动态。

IPsec 支持两种安全模式(传输模式和隧道模式)。

安全关联

安全关联 (SA) 是 VPN 参与方之间关于在保护通信通道中使用的方法和参数的单向协议。全双向通信至少需要两个 SA,每个方向一个。通过 SA,IPsec 隧道可提供以下安全功能:

  • 隐私(通过加密)

  • 内容完整性(通过数据身份验证)

  • 发送方身份验证和 (如果使用证书) 不可否认(通过数据源身份验证)

您采用的安全功能取决于您的需求。如果您只需要验证 IP 数据包源和内容完整性,则可以在不应用任何加密的情况下对数据包进行身份验证。另一方面,如果您仅关心保护隐私,则可以在不应用任何认证机制的情况下对数据包进行加密。或者,您可以对数据包进行加密和身份验证。大多数网络安全设计人员选择对其 VPN 流量进行加密、身份验证和重放保护。

IPsec 隧道由一对单向 SA 组成,每个隧道方向一个 SA,用于指定安全参数索引 (SPI)、目标 IP 地址和安全协议(使用身份验证头 [AH] 或封装安全有效负载 [ESP])。SA 将以下用于保护通信的组件分组在一起:

  • 安全算法和密钥。

  • 协议模式,传输或通道。Junos OS 设备始终使用隧道模式。(请 参阅隧道模式下的数据包处理。

  • 密钥管理方法,手动密钥或 AutoKey IKE。

  • SA 生存期。

对于入站流量,Junos OS 使用以下三元查找 SA:

  • 目标 IP 地址。

  • AH 或 ESP 安全协议。

  • 安全参数索引 (SPI) 值。

对于出站 VPN 流量,策略会调用与 VPN 隧道关联的 SA。

IPsec 密钥管理

密钥的分配和管理对于成功使用 VPN 至关重要。Junos OS 支持使用三种密钥创建机制创建 VPN 隧道的 IPsec 技术:

  • 手动密钥

  • 使用预共享密钥或证书的 AutoKey IKE

在第 1 阶段和第 2 阶段提议配置期间,您可以选择密钥创建机制(也称为身份验证方法)。请参阅 互联网密钥交换

本主题包括以下部分:

手动密钥

使用手动密钥,隧道两端的管理员配置所有安全参数。这是一种可行的技术,适用于密钥分配、维护和跟踪难度不大的小型静态网络。但是,远距离安全分发手动密钥配置会带来安全问题。除了面对面传递密钥之外,您还不能完全确定密钥在传输过程中没有受到损害。此外,每当您想要更改密钥时,您都会面临与最初分发密钥时相同的安全问题。

AutoKey IKE

当您需要创建和管理多个隧道时,您需要一种无需您手动配置每个元素的方法。IPsec 支持使用互联网密钥交换 (IKE) 协议自动生成和协商密钥和安全关联。Junos OS 将此类自动化隧道协商称为 AutoKey IKE,并支持使用预共享密钥和带证书的 AutoKey IKE。

  • 使用预共享密钥的 AutoKey IKE — 使用带有预共享密钥的 AutoKey IKE 对 IKE 会话中的参与方进行身份验证,每一方都必须预先配置并安全地交换预共享密钥。在这方面,安全密钥分配的问题与手动密钥相同。但是,与手动密钥不同,自动密钥在预确定的间隔内可以使用 IKE 协议自动更改其密钥。频繁更改密钥可极大地提高安全性,自动更改密钥管理责任。但是,更改密钥会增加流量开销;因此,频繁更改密钥会降低数据传输效率。

    预共享密钥是加密和解密的密钥,两个参与方在开始通信之前都必须具有此密钥。

  • 带证书的 AutoKey IKE — 在 AutoKey IKE 协商期间使用证书对参与方进行身份验证时,每一方都会生成公钥-私钥对并获取证书。只要双方信任证书颁发机构 (CA),参与方就可以检索对等方的公钥并验证对等方的签名。无需跟踪密钥和 SA;IKE 会自动执行。

Diffie-Hellman 交换

Diffie-Hellman (DH) 交换允许参与方产生共享密钥值。该技术的优势在于,它允许参与方通过不安全的介质创建密钥值,而无需通过电线传递密钥值。每个组计算中使用的素数模数的大小各不相同,如下表所示。Diffie Hellman (DH) 交换操作可以在软件中或硬件中执行。当这些交换操作在硬件中执行时,我们使用 QuickAssist Technology (QAT) 加密。以下 表 1 列出了不同的 Diffie Hellman (DH) 组,并指定为该组执行的操作是在硬件还是软件中。

表 1: Diffie Hellman (DH) 组及其执行的交换操作

Diffie-Hellman (DH) 组

主模块尺寸

第 1 组 DH

768-bit

第 2 组 DH

102-bit

第 5 组 DH

1536-bit

第 14 组 DH

2048-bit

第 15 组 DH

3072-bit

第 16 组 DH

4096-bit

第 19 组 DH

256 位椭圆曲线

第 20 组 DH

384 位椭圆曲线

第 21 组 DH

521 位椭圆曲线

第 24 组 DH

2048 位,带 256 位素数顺序子组

从 Junos OS 19.1R1 版开始,SRX 系列设备支持 DH 组 15、16 和 21。

从 Junos OS 20.3R1 版开始,安装有 junos-ike 软件包的 vSRX 实例支持 DH 组 15、16 和 21。

我们不建议使用 DH 组 1、2 和 5。

由于每个 DH 组的模数大小不同,参与方必须同意使用同一组。

IPsec 安全协议

IPsec 使用两个协议来保护 IP 层的通信:

  • 认证头 (AH)— 用于验证 IP 数据包来源和验证其内容完整性的安全协议

  • 封装安全有效负载 (ESP)— 用于加密整个 IP 数据包(并对其内容进行身份验证)的安全协议

在第 2 阶段提议配置期间,您可以选择安全协议(也称为 authentication and encryption algorithms)。请参阅 互联网密钥交换

对于每个 VPN 隧道,AH 和 ESP 隧道会话均安装在服务处理单元 (SPU) 和控制平面上。协商完成后,隧道会话将随协商的协议一起更新。对于 SRX5400、SRX5600 和 SRX5800 设备,锚点 SPU 上的隧道会话将随协商的协议一起更新,而非锚点 SPU 将保留 ESP 和 AH 隧道会话。ESP 和 AH 隧道会话显示在和show security flow cp-session操作模式命令的输出show security flow session中。

本主题包括以下部分:

IPsec 身份验证算法(AH 协议)

认证头 (AH) 协议提供了验证数据包内容和来源真实性和完整性的方法。您可以使用密钥以及 MD5 或 SHA 散列功能,通过散列消息认证代码 (HMAC) 计算出的校验和来验证数据包。

  • 消息摘要 5 (MD5)—从任意长度和 16 字节密钥中生成 128 位散列(也称为 数字签名消息摘要)的算法。生成的散列与输入的指纹一样,用于验证内容和源的真实性和完整性。

  • 安全散列算法 (SHA)— 一种从任意长度消息和 20 字节密钥中生成 160 位散列的算法。它通常被认为比 MD5 更安全,因为它产生的散热更大。由于计算处理是在 ASIC 中完成的,因此性能成本可以忽略。

有关 MD5 散列算法的详细信息,请参阅 RFC 1321 和 RFC 2403。有关 SHA 散列算法的详细信息,请参阅 RFC 2404。有关 HMAC 的详细信息,请参阅 RFC 2104。

IPsec 加密算法(ESP 协议)

封装安全有效负载 (ESP) 协议提供了一种确保隐私(加密)和源身份验证及内容完整性(身份验证)的方法。隧道模式下的 ESP 可封装整个 IP 数据包(报头和有效负载),然后将新 IP 报头附加到现已加密的数据包。此新 IP 报头包含通过网络路由受保护数据所需的目标地址。(请 参阅隧道模式下的数据包处理。

借助 ESP,您既可以加密,也可以进行身份验证、仅加密或仅进行身份验证。对于加密,您可以选择以下一种加密算法:

  • 数据加密标准 (DES) — 带有 56 位密钥的加密块算法。

  • 三重 DES (3DES)— 更强大的 DES 版本,其中使用 168 位密钥在三轮中应用原始 DES 算法。DES 可显著节省性能,但许多分类或敏感的材料传输都被认为是不可接受的。

  • 高级加密标准 (AES) — 一种可与其他设备实现更大互操作性的加密标准。Junos OS 支持具有 128 位、192 位和 256 位密钥的 AES。

要进行身份验证,您可以使用 MD5 或 SHA 算法。

尽管可以选择 NULL 进行加密,但已经证明 IPsec 在这种情况下可能容易受到攻击。因此,我们建议您选择一种最高安全的加密算法。

IPsec 隧道协商

以下两种不同模式用于确定如何在 VPN 中交换信息流。

  • 隧道模式 — 通过在 VPN 隧道中将原始 IP 数据包封装到另一个数据包中来保护流量。此模式使用与 IKE 预共享密钥对对等方或使用 IKE 进行数字证书认证,以便对对等方进行身份验证。当独立专用网络中的主机希望通过公共网络进行通信时,最常使用这种方法。VPN 客户端和 VPN 网关均可使用此模式,并保护来自或进入非 IPsec 系统的通信。

  • 传输模式 — 通过在已建立 IPsec 隧道的两个主机之间直接发送数据包来保护流量。也就是说,当通信端点和加密端点相同时。IP 数据包的数据部分加密,但 IP 报头未加密。为受保护主机提供加密和解密服务的 VPN 网关不能对受保护的 VPN 通信使用传输模式。如果数据包被拦截,可以修改源或目标的 IP 地址。由于其构造,仅当通信端点和加密端点相同时,才能使用传输模式。

支持的 IPsec 和 IKE 标准

在配备一个或多个 MS-MPC、MS-MIC 或 DPC 的路由器上,加拿大和美国版本的 Junos OS 基本支持以下 RFC,这些 RFC 定义了 IP 安全 (IPsec) 和互联网密钥交换 (IKE) 标准。

  • RFC 2085, 带重放防御的 HMAC-MD5 IP 身份验证

  • RFC 2401, 互联网协议的安全架构 (因 RFC 4301 被淘汰)

  • RFC 2402, IP 认证头 (因 RFC 4302 被淘汰)

  • RFC 2403, HMAC-MD5-96 在 ESP 和 AH 中的使用

  • RFC 2404, HMAC-SHA-1-96 在 ESP 和 AH 中的使用 (因 RFC 4305 被淘汰)

  • RFC 2405, 带有显式 IV 的 ESP DES-CBC 密码算法

  • RFC 2406, IP 封装安全有效负载 (ESP) (因 RFC 4303 和 RFC 4305 被淘汰)

  • RFC 2407, ISAKMP 的互联网 IP 安全解释域 (因 RFC 4306 被淘汰)

  • RFC 2408, 互联网安全关联和密钥管理协议 (ISAKMP) (因 RFC 4306 被淘汰)

  • RFC 2409, 互联网密钥交换 (IKE) (因 RFC 4306 被淘汰)

  • RFC 2410, NULL 加密算法及其与 IPsec 的配合使用

  • RFC 2451, ESP CBC 模式密码算法

  • RFC 2560, X.509 互联网公钥基础架构在线证书状态协议 - OCSP

  • RFC 3193, 使用 IPsec 保护 L2TP 的安全

  • RFC 3280, 互联网 X.509 公钥基础架构证书和证书撤销列表 (CRL) 配置文件

  • RFC 3602, AES-CBC 密码算法及其与 IPsec 的配合使用

  • RFC 3948, IPsec ESP 数据包的 UDP 封装

  • RFC 4106, 在 IPsec 封装安全有效负载 (ESP) 中使用 Galois/计数器模式 (GCM)

  • RFC 4210, 互联网 X.509 公钥基础架构证书管理协议 (CMP)

  • RFC 4211, 互联网 X.509 公钥基础架构证书请求消息格式 (CRMF)

  • RFC 4301, 互联网协议的安全架构

  • RFC 4302, IP 认证头

  • RFC 4303, IP 封装安全有效负载 (ESP)

  • RFC 4305, 封装安全有效负载 (ESP) 和认证头 (AH) 的密码算法实施要求

  • RFC 4306, 互联网密钥交换 (IKEv2) 协议

  • RFC 4307, 互联网密钥交换版本 2 (IKEv2) 中使用的加密算法

  • RFC 4308, IPsec 加密套件

    Junos OS 中仅支持套件 VPN-A。

  • RFC 4754, 使用椭圆曲线数字签名算法 (ECDSA) 的 IKE 和 IKEv2 身份验证

  • RFC 4835, 封装安全有效负载 (ESP) 和认证头 (AH) 的密码算法实施要求

  • RFC 5996, 互联网密钥交换协议版本 2 (IKEv2) (因 RFC 7296 被淘汰)

  • RFC 7296, 互联网密钥交换协议版本 2 (IKEv2)

  • RFC 8200, 互联网协议,版本 6 (IPv6) 规范

Junos OS 部分支持以下用于 IPsec 和 IKE 的 RFC:

  • RFC 3526, 互联网密钥交换 (IKE) 的更多模块指数 (MODP) Diffie-Hellman 群组

  • RFC 5114, 用于使用 IETF 标准的附加 Diffie-Hellman 组

  • RFC 5903, 用于 IKE 和 IKEv2 的椭圆曲线组模数 (ECP 群组)

以下 RFC 和互联网草案不定义标准,而是提供有关 IPsec、IKE 和相关技术的信息。IETF 将其分类为“信息”。

  • RFC 2104, HMAC:用于消息认证的密钥散列

  • RFC 2412, OAKLEY 密钥确定协议

  • RFC 3706, 一种基于流量的不工作互联网密钥交换 (IKE) 对等方检测方法

  • 互联网草案 draft-eastlake-sha2-02.txt, 美国安全散列算法(SHA 和 HMAC-SHA)( 2006 年 7 月到期)

发布历史记录表
版本
说明
19.1R1
从 Junos OS 19.1R1 版开始,SRX 系列设备支持 DH 组 15、16 和 21。