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） 交换操作可以在软件或硬件中执行。 下面 表 1 列出了不同的 Diffie Hellman （DH） 组，并指定为该组执行的操作是在硬件中还是在软件中。

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

Diffie-Hellman （DH） Group

素数模块尺寸

卫生署组 1

768 位

卫生署第2组

102 位

卫生署第5组

1536 位

卫生署第14组

2048 位

卫生署第15组

3072 位

卫生署第16组

4096 位

卫生署第19组

256 位椭圆曲线

卫生署第20组

384 位椭圆曲线

卫生署第21组

521 位椭圆曲线

卫生署第24组

具有 256 位素数阶子组的 2048 位

从 Junos OS 19.1R1 版开始，SRX 系列防火墙（SRX300、SRX320、SRX340、SRX345、SRX380 SRX550HM 系列防火墙除外）支持 DH 组 15、16 和 21。

从 Junos OS 20.3R1 版开始，安装了 junos-ike 软件包的 vSRX 虚拟防火墙 （vSRX 3.0） 实例支持 DH 组 15、16 和 21。

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

由于每个 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 session 和 show security flow cp-session 操作模式命令的输出信息中。

本主题包含以下部分：

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

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

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

  • 安全散列算法 （SHA） — 一种从任意长度的消息生成 160 位散列和一个 20 字节密钥的算法。由于其产生的散列更大，因此通常人们认为它比 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。

  • ChaCha20-Poly1305 使用关联数据进行身份验证的加密 — ChaCha20 流密码，支持使用 Poly1305 身份验证器对关联数据进行身份验证 （AEAD）。

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

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

IPsec 隧道协商

以下两种不同的模式决定了如何在 VPN 中交换流量。

  • 隧道模式 — 通过将原始 IP 数据包封装在 VPN 隧道中的另一个数据包中来保护流量。此模式使用带有 IKE 的预共享密钥对等方进行身份验证，或使用带有 IKE 的数字证书对等方进行身份验证。当不同专用网络中的主机希望通过公共网络进行通信时，最常使用此方法。VPN 客户端和 VPN 网关均可使用此模式，并保护来自非 IPsec 系统或发送到非 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） 中使用伽罗瓦/计数器模式 （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） 规范

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

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

另请参阅

变更历史表

是否支持某项功能取决于您使用的平台和版本。 使用 Feature Explorer 查看您使用的平台是否支持某项功能。

版本
说明
24.2R1
在 Junos OS 24.2R1 版的 SRX1600、SRX2300、SRX4300、SRX4600、SRX5400、SRX5600、SRX5800 和 vSRX 3.0 中添加了对 ChaCha20-Poly1305 算法的支持。
19.1R1
从 Junos OS 19.1R1 版开始，SRX 系列防火墙支持 DH 组 15、16 和 21。