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 安全服务,您可以在主机之间创建 SLA。SA 是一种单工连接,允许两台主机通过 IPsec 安全地相互通信。有两种类型的 SLA:手动和动态。

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预共享密钥 — 使用预共享密钥的 AutoKey IKE 在 IKE 会话中验证参与方,每一方都必须预先配置并安全地交换预共享密钥。在这方面,安全密钥分配的问题与手动密钥相同。但是,一旦分发后,与手动密钥不同的 autokey 可使用 IKE 协议按预先确定的间隔自动更改其密钥。频繁变化的密钥极大地提高了安全性,并且自动做到了这一点,大大减少了关键管理责任。但是,更改密钥会增加流量开销;因此,经常更改密钥会降低数据传输效率。

    预共享密钥是加密和解密的密钥,两个参与者都必须在发起通信之前拥有。

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

Diffie-hellman 交换

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

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

Diffie-Hellman (DH) 组

Prime 模块尺寸

第 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

带 256 位全数顺序子组的 2048 位

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

从Junos OS版本20.3R1,vSRX junos-ike 软件包的一些实例支持第 15 组、第 16 组和 21 组 DH。

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

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

IPsec 安全协议

IPsec 在 IP 层使用两种协议来保护通信:

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

  • 封装安全有效负载 (ESP) — 一种用于加密整个 IP 数据包(并认证其内容)的安全协议

在第 2 阶段提议配置期间,您可以选择安全协议(也称为身份验证和加密算法)。请参阅 互联网密钥交换

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

本主题包括以下几节:

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

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

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

  • 安全散列算法 (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。

对于身份验证,您可以使用 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,其中定义了 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 2460, 互联网协议版本 6 (IPv6)

  • 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,IKE椭圆曲线数字签名算法 (ECDSA) 的加密和 IKEv2 身份验证

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

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

Junos OS 部分支持针对 IPsec 和 IKE 的以下 Rfc:

  • RFC 3526,用于构建数据中心架构的更多模块化指数 (MODP) Diffie-Hellman 群组(互联网密钥交换(IKE)

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

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

以下 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 系列设备支持第 15 组、第 16 组和 21 组 DH。