IPsec 概述
IPsec 是一组可用于保护设备之间传输的协议。
使用 功能浏览器 确认平台和版本对 IPsec 的支持。
安全关联概述
要使用 IPsec 安全服务,您需要在主机之间创建 SA。SA 是一种单工连接,允许两台主机通过 IPsec 安全地相互通信。有两种类型的 SA:手动 SA 和动态 SA。
手动 SA 无需协商;所有值(包括密钥)都是静态的,并在配置中指定。手动 SA 静态定义要使用的安全参数索引 (SPI) 值、算法和密钥,并要求隧道两端都有匹配的配置。每个对等方必须具有相同的配置选项才能进行通信。
动态 SA 需要额外配置。使用动态 SA,您可以先配置 IKE ,然后再配置 SA。IKE 创建动态安全关联;它会协商 IPsec 的 SA。IKE 配置定义用于与对等安全网关建立安全 IKE 连接的算法和密钥。然后,此连接可用于动态就动态 IPsec SA 使用的密钥和其他数据达成动态协议。首先对 IKE SA 进行协商,然后用于保护确定动态 IPsec SA 的协商。
设置用户级隧道或 SA,包括隧道属性协商和密钥管理。这些隧道也可以在同一安全通道上刷新和终止。
IPsec 的 Junos OS 实施支持两种安全模式(传输模式 和 隧道模式)。
另见
IKE 密钥管理协议概述
IKE 是一种密钥管理协议,用于创建动态 SA;它会协商 IPsec 的 SA。IKE 配置定义用于与对等安全网关建立安全连接的算法和密钥。
IKE 执行以下作:
协商和管理 IKE 和 IPsec 参数
验证安全密钥交换
通过共享密钥(而非密码)和公钥提供相互对等方身份验证
提供身份保护(在主模式下)
IKE 分两个阶段进行。在第一阶段,协商安全属性并建立共享密钥以形成双向 IKE SA。在第二阶段,建立入站和出站 IPsec SA。IKE SA 在第二阶段保护交换。IKE 还会生成密钥材料,提供完全向前保密,并交换身份。
从 Junos OS 14.2 版开始,对 jnxIkeTunnelTable 表中的 jnxIkeTunnelEntry 对象执行 SNMP 遍历时, Request failed: OID not increasing 可能会生成错误消息。仅当创建同步互联网密钥交换安全关联 (IKE SA) 时,才会发生此问题,此时 SA 的两端同时启动 IKE SA 协商时。执行 SNMP MIB 遍历以显示 IKE SA 时,snmp遍历工具期望对象标识符 (OID) 按递增顺序排列。但是,对于同步 IKE SA,SNMP 表中的 OID 可能不会按递增顺序排列。出现此现象的原因是,隧道 ID (OID 的一部分)是根据 IKE SA 的发起方分配的,IKE SA 可以位于 IKE 隧道的任一端。
以下是在 IKE 同步 SA 上执行的 SNMP MIB 遍历示例:
jnxIkeTunLocalRole."ipsec_ss_cust554".ipv4."192.0.2.41".47885 = INTEGER: responder(2) >>> This is Initiator SA jnxIkeTunLocalRole."ipsec_ss_cust554".ipv4."192.0.2.41".47392 = INTEGER: initiator(1) >>> This is Responder's SA
当 SNMP 遍历为隧道 ID(47885 和 47392)时,OID 比较将失败。执行 SNMP 遍历时,无法确保隧道 ID 的顺序递增,因为隧道可能从任一端启动。
要变通解决此问题,SNMP MIB 遍历包含一个选项 -Cc,用于禁用对增加 OID 的检查。以下是使用 -Cc 选项在 jnxIkeTunnelEntry 表上执行的 MIB 遍历示例:
snmpwalk -Os -Cc -c public -v 1 vira jnxIkeTunnelEntry
另见
Junos-FIPS 的 IPsec 要求
在 Junos-FIPS 环境中,必须将具有两个 路由引擎的硬件配置配置为使用 IPsec 和一个专用路由实例进行路由引擎之间的所有通信。还需要路由引擎与 AS II FIPS PIC之间的 IPsec 通信。
另见
IPsec 概述
IP 安全 (IPsec) 是基于标准的框架,用于确保 IP 网络上的安全专用通信。IPsec 提供了一种安全的方式来验证发送方身份验证,并对网络设备(如路由器和主机)之间的 IP 版本 4 (IPv4) 和版本 6 (IPv6) 流量进行加密。IPsec 包括数据完整性、发送方身份验证、源数据机密性和数据重放保护。
您需要了解的主要概念如下:
支持 IPsec 的线卡
在基于 Junos OS 的路由器上实施 IPsec 时,您首先需要选择要使用的线卡类型。术语线卡包括物理接口卡 (PIC)、模块化接口卡 (MIC)、密集端口集中器 (DPC) 和模块化端口集中器 (MPC)。以下线卡支持 IPsec 实施。
请参阅路由器的特定硬件文档,以确定该路由器上的线卡是否支持 IPsec。
以下线卡支持 IPsec:
加密服务 (ES) PIC 为 IPsec 提供加密服务和软件支持。
自适应服务 (AS) PIC 和自适应服务 (AS) II PIC 提供 IPsec 服务和其他服务,例如网络地址转换 (NAT) 和状态防火墙。
AS II 联邦信息处理标准 (FIPS) PIC 是 AS PIC 的特殊版本,可使用内部 IPsec 与路由引擎安全通信。在路由器上启用 FIPS 模式时,必须在 AS II FIPS PIC 上配置 IPsec。有关在以 FIPS 模式配置的路由器中安装的 AS II FIPS PIC 上实施 IPsec 的详细信息,请参阅 通用标准和 Junos-FIPS 安全配置指南。
多服务 PIC 为一系列数据包处理密集型服务提供硬件加速。这些服务包括 IPsec 服务和其他服务,例如状态防火墙、NAT、IPsec、异常检测和隧道服务。
多服务密集端口集中器 (DPC) 提供 IPsec 服务。
多服务模块化端口集中器 (MS-MPC) 支持 IPsec 服务。
多服务模块化接口卡 (MS-MIC) 支持 IPsec 服务。
Junos OS 扩展提供程序包(包括 IPsec 服务包)预安装在 MS-MPC 和 MS-MIC 上。
另见
身份验证算法
身份验证是验证发件人身份的过程。身份验证算法使用共享密钥来验证 IPsec 设备的真实性。Junos OS 使用以下身份验证算法:
消息摘要 5 (MD5) 使用单向哈希函数将任意长度的消息转换为 128 位的固定长度消息摘要。由于转换过程,通过从生成的消息摘要向后计算原始消息来计算原始消息在数学上是不可行的。同样,更改消息中的单个字符将导致它生成非常不同的消息摘要编号。
为了验证消息是否未被篡改,Junos OS 会将计算的消息摘要与使用共享密钥解密的消息摘要进行比较。Junos OS 使用 MD5 散列消息验证代码 (HMAC) 变体,该变体提供额外级别的散列。MD5 可与认证头 (AH)、封装安全有效负载 (ESP) 和互联网密钥交换 (IKE) 一起使用。
安全散列算法 1 (SHA-1) 使用比 MD5 更强的算法。SHA-1 接收长度小于 264 位的消息,并生成 160 位的消息摘要。大型消息摘要可确保数据未更改,并且数据源自正确的源。Junos OS 使用 SHA-1 HMAC 变体,可提供额外的散列级别。SHA-1 可与 AH、ESP 和 IKE 配合使用。
SHA-256、SHA-384 和 SHA-512(有时以 SHA-2 的名称分组)是 SHA-1 的变体,使用更长的消息摘要。Junos OS 支持 SHA-256 版本的 SHA-2,可以处理所有版本的高级加密标准 (AES)、数据加密标准 (DES) 和三重 DES (3DES) 加密。
加密算法
加密将数据编码为安全格式,以便未经授权的用户无法破译。与身份验证算法一样,共享密钥与加密算法一起使用,以验证 IPsec 设备的真实性。Junos OS 使用以下加密算法:
数据加密标准密码-密钥链接 (DES-CBC) 是一种对称密钥密钥块算法。DES 使用 64 位的密钥大小,其中 8 位用于错误检测,其余 56 位提供加密。DES 对共享密钥执行一系列简单的逻辑运算,包括排列和替换。CBC 从 DES 获取第一个 64 位输出块,将此块与第二个块合并,将其反馈回 DES 算法,并对所有后续块重复此过程。
三重 DES-CBC (3DES-CBC) 是一种类似于 DES-CBC 的加密算法,但它使用三个密钥进行 168 位(3 x 56 位)加密,因此提供更强大的加密结果。3DES 的工作原理是使用第一个密钥对块进行加密,使用第二个密钥对块进行解密,并使用第三个密钥重新加密块。
高级加密标准 (AES) 是基于比利时密码学家 Joan Daemen 博士和 Vincent Rijmen 博士开发的 Rijndael 算法的下一代加密方法。它使用一个 128 位块和三种不同的密钥大小(128、192 和 256 位)。根据密钥大小,该算法会执行一系列计算(10、12 或 14 轮),包括字节替换、列混合、行移动和密钥添加。RFC 3602 AES-CBC 密码算法及其与 IPsec 的配合使用中定义了 AES 与 IPsec 结合使用的方法。
从 Junos OS 17.3R1 版开始,MS-MPC 和 MS-MIC 支持 Galois/计数器模式高级加密标准 (AES-GCM)。但是,在 Junos FIPS 模式下,Junos OS 17.3R1 版不支持 AES-GCM。从 Junos OS 17.4R1 版开始,Junos FIPS 模式支持 AES-GCM。AES-GCM 是一种经过身份验证的加密算法,旨在提供身份验证和隐私。AES-GCM 对二进制伽罗瓦字段使用通用散列来提供经过身份验证的加密,并允许以数十 Gbps 的数据速率进行经过验证的加密。
另见
IPsec 协议
IPsec 协议确定应用于路由器保护的数据包的身份验证和加密类型。Junos OS 支持以下 IPsec 协议:
AH — 在 RFC 2402 中定义,AH 为 IPv4 和 IPv6 数据包提供无连接完整性和数据源身份验证。它还提供防止重播的保护。AH 对尽可能多的 IP 报头以及上层协议数据进行身份验证。但是,某些 IP 报头字段可能会在传输过程中发生变化。由于发送方可能无法预测这些字段的值,因此无法对其进行 AH 保护。在 IP 报头中,AH 可以通过 IPv4 数据包字段和
Next HeaderIPv6 数据包字段中的值51Protocol来识别。AH 提供的 IPsec 保护示例如图 1 所示。注意:T Series、M120 和 M320 路由器不支持 AH。
ESP - 在 RFC 2406 中定义,ESP 可以提供加密和受限流量机密性、无连接完整性、数据源身份验证和防重放服务。在 IP 报头中,可以在 IPv4 数据包字段和
Next HeaderIPv6 数据包字段中标识 ESP 的值。50ProtocolESP 提供的 IPsec 保护示例如图 2 所示。
捆绑包 — 将 AH 与 ESP 进行比较时,两种协议都有一些优点和缺点。ESP 提供了相当程度的身份验证和加密级别,但仅对部分 IP 数据包有效。相反,虽然 AH 不提供加密,但会为整个 IP 数据包提供身份验证。因此,Junos OS 提供了第三种形式的 IPsec 协议,称为协议包。捆绑选项提供 AH 身份验证与 ESP 加密的混合组合。
另见
SRX 系列设备支持的 IKE 和 IPsec 密码
使用下表查看 SRX 系列平台上支持的密码。
| 密码 (IKE) |
SRX1500 |
SRX1600 |
SRX2300,SRX4120 |
SRX4100、SRX4200和SRX4300 |
SRX4600和SRX4700 |
SRX5400、SRX5600和SRX5800 |
|---|---|---|---|---|---|---|
| AES-128-GCM |
是的 |
是的 |
是的 |
是的 |
是的 |
是的 |
| AES-192-GCM |
不 |
不 |
不 |
不 |
不 |
不 |
| AES-256-GCM |
是的 |
是的 |
是的 |
是的 |
是的 |
是的 |
| 密码 (IPSec) |
SRX1500 |
SRX1600 |
SRX2300,SRX4120 |
SRX4100、SRX4200和SRX4300 |
SRX4600和SRX4700 |
SRX5400、SRX5600和SRX5800 |
|---|---|---|---|---|---|---|
| AES-128-GCM |
是的 |
是的 |
是的 |
是的 |
是的 |
是的 |
| AES-192-GCM |
是的 |
是的 |
是的 |
是的 |
是的 |
是的 |
| AES-256-GCM |
是的 |
是的 |
是的 |
是的 |
是的 |
是的 |
变更历史表
是否支持某项功能取决于您使用的平台和版本。使用 功能浏览器 查看您使用的平台是否支持某项功能。
Request failed: OID not increasing 可能会生成错误消息。