Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
本页内容
 

IPsec 基础知识

阅读本主题，了解 IPsec 密钥管理、安全协议、隧道协商以及 IPsec 和 IKE 标准。

使用 功能资源管理器 确认平台和版本对特定功能的支持。

查看 特定于平台的 IPsec 隧道行为 部分，了解与您的平台相关的注意事项。

有关更多信息，请参阅 “其他平台信息” 部分。

IPsec 概述

IPsec 是一套相互关联的协议，用于在 IP 数据包层进行加密的安全通信。IPsec 可提供手册和自动安全关联 （SA） 协商和密钥分配方法。解释域 （DOI） 收集了所有相关属性。IPsec DOI 是一份定义成功 VPN 隧道协商所需的所有安全参数的文档，本质上是指 SA 和 IKE 协商所需的每个属性。有关详细信息，请参阅 RFC 2407 和 RFC 2408。

要使用 IPsec 安全服务，请在主机之间创建 SA。SA 是一种单工连接，允许两台主机通过 IPsec 安全地相互通信。IPsec 支持两种类型的 SA：手册和动态。

IPsec 支持两种安全模式（传输模式和隧道模式）。

安全性关联

安全关联 （SA） 是 VPN 参与方之间关于通信信道保护所用方法和参数的单向协议。全双向通信需要至少两个 SA，每个方向需要一个。通过 SA，IPsec 隧道可以提供以下安全功能：

  • 隐私功能（通过加密实现）

  • 内容完整性（通过数据身份验证实现）

  • 发件人身份验证和（如果使用证书）不可否认性（通过数据源身份验证）

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

IPsec 隧道由一对单向 SA 组成，隧道的每个方向一个 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 技术：

  • 手动密钥

  • 通过预共享密钥 （PSK） 或证书的 AutoKey IKE

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

本主题包含以下部分：

手动密钥

手册密钥，隧道两端的管理员可以配置所有安全参数。手动密钥是一种可行的技术，适用于密钥分配、维护和跟踪难度不大的小型静态网络。但是，远距离安全分发手册密钥配置会带来安全问题。除了面对面传递密钥外，您无法完全确定未获授权的各方是否在传输过程中破坏了密钥。此外，每当您需要更改密钥时，您都会面临与最初分发密钥时相同的问题。

AutoKey IKE

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

  • AutoKey IKE 与预共享密钥 — 使用带有预共享密钥的 AutoKey IKE 对 IKE 会话中的参与方进行身份验证，双方必须提前配置并安全地交换 PSK。在这方面，安全密钥分配问题与手册密钥相同。但是，与手册密钥不同，自动密钥可以使用 IKE 协议按预先确定的间隔自动更改其密钥。频繁变更密钥可以极大地提高安全性，而使这一过程自动化则大幅降低了密钥管理的工作负担。但是，更改密钥会增加流量开销;因此，过于频繁地更改密钥会降低数据传输效率。

    PSK 是用于加密和解密的密钥，发起通信前，通信参与双方都必须拥有该密钥。

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

Diffie-Hellman 交换

Diffie-hellman （DH） 交换允许参与方产生一个共享的密钥值。该技术的优势在于，它允许参与方通过不安全的介质创建密钥值，而不必通过有线网络传递密钥值。每个群组的计算中使用的素数模数大小不同，如下表所示。设备在软件或硬件中执行 DH 交换操作。下 表 1 列出了不同的 Diffie Hellman （DH） 组，并指定对该组执行的操作是在硬件中还是在软件中执行。

表 1：Diffie Hellman （DH） 组及其执行的交换操作

Diffie-Hellman （DH） 组

Prime 模块尺寸

DH 组 1

768 位

DH 组 2

102 位

DH 组 5

1536 位

DH 组 14

2048 位

DH 组 15

3072 位

DH 组 16

4096 位

DH 组 19

256 位椭圆曲线

DH 组 20

384 位椭圆曲线

DH 组 21

521 位椭圆曲线

DH 组 24

2048 位与 256 位素序子组

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

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

IPsec 安全性协议

IPsec 使用两种协议来保护 IP 层的通信：

  • 认证头 （AH） — 一种用于确定 IP 数据包来源并验证其内容完整性的安全协议

  • 封装安全性有效负载 （ESP） — 一种用于对整个 IP 数据包进行加密并对其内容进行验证的安全协议

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

对于每个 VPN 隧道，AH 和 ESP 隧道会话会安装在服务处理单元 （SPU） 和控制平面上。协商完成后，设备将使用协商后的协议更新隧道会话。 show security flow session 和 show security flow cp-session 操作模式命令可显示 ESP 和 AH 隧道会话的详细信息。

本主题包含以下部分：

IPsec 身份验证算法（AH 协议）

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

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

  • 安全散列算法 （SHA） — 一种从任意长度的消息和一个 20 字节密钥生成 160 位散列的算法。SHA 比 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 版本，其中原始 DES 算法使用 168 位密钥应用三轮。DES 可提供显著的性能节约，但许多分类或敏感的材料传输都会将其视为不可接受。

  • 高级加密标准 （AES） — 一种可实现与其他设备进行更强的互操作性的加密标准。Junos OS 支持带有 128 位、192 位和 256 位密钥的 AES。

  • ChaCha20-Poly1305 Authenticated Encryption with Associated Data—ChaCha20 流密码，支持使用 Poly1305 验证器的 Authenticated Encryption with Associated Data （AEAD）。

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

即使可以选择使用 NULL 进行加密，但研究表明，在这种情况下，IPsec 可能容易受到攻击。因此，我们建议您选择一种可以实现最大安全性的加密算法。

IPsec 隧道协商

以下两种不同模式决定了 VPN 交换流量的方式。

  • 隧道模式 — 通过将原始 IP 数据包封装在 VPN 隧道中的另一个数据包中来保护流量。此模式使用带有 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 7427， 互联网密钥交换第 2 版 （IKEv2） 中的签名验证

  • RFC 7634、 ChaCha20、Poly1305 及其在互联网密钥交换协议 （IKE） 和 IPsec 中的使用

  • 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 月到期）

也可以看看

特定于平台的 IPsec 隧道行为

使用 功能资源管理器 确认平台和版本对特定功能的支持。

使用下表查看平台的特定于平台的行为。

表 2：特定于平台的行为

平台

差异

SRX 系列

  • 在支持 IPsec VPN 的 SRX5400、SRX5600 和 SRX5800 设备上：

    • Junos OS 会更新锚点 SPU 上的隧道会话的协商协议。

    • 非锚点 SPU 将保留 ESP 和 AH 隧道会话。

其他平台信息

使用 功能资源管理器 确认平台和版本对特定功能的支持。可能支持其他平台。

表 3：其他平台信息

功能

SRX300 SRX320 SRX340 SRX345SRX380SRX550HM

SRX1500 SRX1600

SRX2300 SRX4120 SRX4100 SRX4200SRX4300 SRX4600SRX4700

SRX5400 、SRX5600 、SRX5800

vSRX 虚拟防火墙

支持第 15 组、第 16 组和第 21 组 DH

否

是

是

是

是，适用于带软件包的 junos-ike vSRX 3.0

变更历史表

是否支持某项功能取决于您使用的平台和版本。使用 功能资源管理器 确定您的平台是否支持某个功能。

发布
描述
24.2R1
Junos OS 24.2R1 版中的 SRX1600、SRX2300、SRX4300、SRX4600、SRX5400、SRX5600、SRX5800 和 vSRX 3.0 中添加了对 ChaCha20-Poly1305 算法的支持。
20.3R1
从 Junos OS 20.3R1 版开始，vSRX 虚拟防火墙可支持第 15 组、第 16 组和第 21 组 DH。
19.1R1
从 Junos OS 19.1R1 版开始，SRX 系列防火墙支持第 15 组、第 16 组和第 21 组 DH。