互联网密钥交换
IKE 简介
互联网密钥交换 （IKE） 是一种安全的密钥管理协议，用于在两台设备之间建立安全、经过身份验证的通信通道。
IKE 执行以下操作：
协商和管理 IKE 和 IPsec 参数
验证安全密钥交换
通过共享密钥（非密码）和公钥提供相互对等身份验证
提供身份保护（在主模式下）
采用 Diffie-Hellman 方法，在 IPsec 中是可选的（可以在端点手动输入共享密钥）。
IKE 版本
有两个版本的 IKE 标准可用：
IKE 版本 1 - RFC 2409 中定义的 IKE 协议。
IKE 版本 2 - IKE 版本 2 （IKEv2） 是 RFC 7296 中定义的 IKE 协议的最新版本。
互联网密钥交换版本 2 （IKEv2） 是 RFC 7296 中定义的互联网密钥交换 （IKE） 协议的最新版本。VPN 对等方配置为 IKEv1 或 IKEv2。将对等方配置为 IKEv2 时，如果其远程对等方发起 IKEv1 协商，则无法回退到 IKEv1。
与 IKEv1 相比，使用 IKEv2 的优势如下：
用一次四条消息交换替换八个初始交换。
减少 IPsec SA 设置的延迟并提高连接建立速度。
提高对 DOS 攻击的鲁棒性。
通过使用序列号、确认和纠错来提高可靠性。
提高了可靠性，因为所有消息都是请求或响应。如果发起方未收到响应，则负责重新传输。
IKE 与 IPSec 之间的交互
IPsec 可以通过以下任一方式建立 VPN：
互联网密钥交换 （IKE） 协议 — IPsec 支持使用 IKE 协议自动生成和协商密钥和安全关联。与手动密钥交换相比，使用 IKE 在两个端点之间协商 VPN 可提供更高的安全性。
手动密钥交换 — IPsec 支持手动使用和交换密钥（例如：电话或电子邮件）在双方建立VPN。
IKEv1 消息交换
IKE 协商包括两个阶段：
第 1 阶段 - 协商 有关如何对通道进行身份验证和保护的建议交换。
第 2 阶段 - 协商安全关联 （SA） 以保护遍历 IPsec 隧道的数据。
IKE 隧道协商的第 1 阶段
AutoKey 互联网密钥交换 （IKE） 隧道协商的第 1 阶段包括交换有关如何对通道进行身份验证和保护的建议。参与方交换提议，以便获得可接受的安全服务，例如：
加密算法 - 数据加密标准 （DES）、三重数据加密标准 （3DES） 和高级加密标准 （AES）。（请参阅IPsec 概述。）
身份验证算法 — 消息摘要 5 （MD5） 和安全散列算法 （SHA）。（请参阅IPsec 概述。）
Diffie-Hellman (DH) 群组。（请参阅IPsec 概述。）
预共享密钥或 RSA/DSA 证书。（请参阅IPsec 概述。）
当隧道的两端都同意接受至少一组提议的第 1 阶段安全参数，然后对其进行处理时，第 1 阶段协商就会成功结束。瞻博网络设备最多支持四个第 1 阶段协商提议，允许您定义您将接受的一系列密钥协商安全参数的限制。Junos OS 可提供预定义的标准、兼容和基本的第 1 阶段提议集。您还可以定义自定义第 1 阶段提议。
第 1 阶段交换可以在主模式或积极模式下进行。您可以在 IKE 策略配置期间选择模式。
本主题包含以下部分：
主模式
在主模式下，发起方和接收方发送三次双向交换（共六条消息），以完成以下服务：
第一次交换（消息 1 和 2）— 建议并接受加密和身份验证算法。
第二次交换（消息 3 和 4）— 执行 DH 交换，发起方和接收方各提供一个伪随机数。
第三次交换（消息 5 和 6）— 发送并验证发起方和接收方的身份。
第三次消息交换中传输的信息受在前两次交换中建立的加密算法的保护。因此，参与者的身份是加密的，因此不会“以明文方式”传输。
积极模式
在积极模式下，发起方和接收方可以完成与主模式相同的目标，但仅进行两次交换，共使用三条消息：
第一条消息 — 发起方提出安全关联 （SA），发起 DH 交换，并发送伪随机数及其 IKE 身份。
对具有多个第 1 阶段协商提议的积极模式进行配置时，请在所有提议中使用相同的 DH 组，因为无法对 DH 组进行协商。最多可配置四个提议。
第二条消息 — 收件人接受 SA;对启动器进行身份验证;并发送一个伪随机数、其 IKE 身份，以及接收方的证书（如果使用证书）。
第三条消息 — 发起方对接收方进行身份验证，确认交换，如果使用证书，则发送发起方的证书。
由于参与者的身份以明文方式交换（在前两条消息中），因此主动模式不提供身份保护。
主模式和积极模式仅适用于 IKEv1 协议。IKEv2 协议不会使用主模式和积极模式进行协商。
另请参阅
IKE 隧道协商的第 2 阶段
参与者建立安全且经过身份验证的通道后，将继续进入第 2 阶段，在该阶段中协商安全关联 （SA），以保护要通过 IPsec 隧道传输的数据。
与第 1 阶段的过程类似，参与者交换建议以确定要在 SA 中使用的安全参数。第 2 阶段提议还包括一个安全协议（封装安全有效负载 （ESP） 或身份验证标头 （AH））以及选定的加密和身份验证算法。如果需要完全向前保密 (PFS)，提议还可以指定 Diffie-Hellman (DH) 组。
无论第 1 阶段中使用何种模式，第 2 阶段始终在快速模式下运行，并涉及三条消息的交换。
本主题包含以下部分：
代理 ID
在第 2 阶段，对等方交换代理 ID。代理 ID 由本地和远程 IP 地址前缀组成。两个对等方的代理 ID 必须匹配，这意味着，为一个对等方指定的本地 IP 地址必须与为另一个对等方指定的远程 IP 地址相同。
完全向前保密
PFS 是一种派生第 2 阶段密钥的方法，该方法独立于上述密钥且与上述密钥无关。或者，第 1 阶段提议创建一个密钥（SKEYID_d 密钥），所有第 2 阶段密钥都从中派生。SKEYID_d密钥可以用最少的 CPU 处理生成第 2 阶段密钥。遗憾的是，如果未获授权的一方获得对 SKEYID_d 密钥的访问权，则所有加密密钥都将受到影响。
PFS 通过强制为每个第 2 阶段隧道进行新的 DH 密钥交换来解决此安全风险。因此，使用 PFS 更安全，尽管启用 PFS 后，第 2 阶段中的密钥更新过程可能需要稍长的时间。
重放保护
如果未经授权的人员拦截一系列数据包并在随后使用它们进行系统泛洪，进而导致拒绝服务 (DoS) 或进入可信网络，就会发生重放攻击。Junos OS 可提供重放保护功能，进而让设备能够检查每个 IPsec 数据包，确定之前是否曾收到过此数据包。如果收到的数据包超出指定序列范围，Junos OS 就会拒绝这些数据包。使用此功能不需要协商，因为数据包始终使用序列号发送。您只需选择检查或不检查序列号即可。
另请参阅
IKEv2 消息交换
IKE 版本 2 是 IKEv1 方法的后继版本。它在对等 VPN 设备之间提供安全的 VPN 通信通道，并以受保护的方式定义 IPsec 安全关联 （SA） 的协商和身份验证。
IKEv2 不包括类似于 IKEv1 的第 1 阶段和第 2 阶段，但会发生四种消息交换来与 IKEv2 协商 IPsec 隧道。IKEv2 中的消息交换包括：
协商安全属性以建立 IPsec 隧道。这包括交换使用的协议/参数和Diffie-Hellman组。
在建立 IPsec 隧道时，每个对等方建立或验证其身份。
对等方，以在彼此之间创建其他安全关联。
对等方执行实时检测、删除 SA 关系和报告错误消息。
IKEv2 配置有效负载
配置有效负载是一个 IKEv2 选项，用于将调配信息从响应方传播到发起方。IKEv2 配置有效负载仅支持基于路由的 VPN。
RFC 5996， 互联网密钥交换协议版本 2 （IKEv2），定义了 15 个不同的配置属性，响应方可以将其返回给发起方。
IKEv2 重新生成密钥和重新验证
对于 IKEv2，密钥重新生成和重新验证是单独的过程。
重新生成密钥会为 IKE 安全关联 （SA） 建立新密钥并重置消息 ID 计数器，但不会重新对等方进行身份验证。
重新身份验证验证 VPN 对等方是否保留其对身份验证凭据的访问权限。重新身份验证为 IKE SA 和子 SA 建立新密钥;不再需要任何挂起的 IKE SA 或子 SA 的重新密钥。创建新的 IKE 和子 SA 后，将删除旧的 IKE 和子 SA。
默认情况下，IKEv2 重新身份验证处于禁用状态。可以通过配置介于 1 和 100 之间的重新身份验证频率值来启用重新身份验证。重新验证频率是在重新验证之前发生的 IKE 重新密钥数。例如，如果配置的重新验证频率为 1，则每次进行 IKE 重新生成密钥时都会发生重新验证。如果配置的重新验证频率为 2，则每隔一次 IKE 重新生成密钥时进行重新验证。如果配置的重新验证频率为 3，则每三次 IKE 重新生成密钥时就会重新进行身份验证，依此类推。
IKEv2 分段
使用基于证书的身份验证时，如果传输多个证书，IKEv2 数据包可能会超过路径 MTU。如果 IKE 消息大小超过路径 MTU，则会在 IP 级别对消息进行分段。某些网络设备（如 NAT 设备）不允许 IP 片段通过，从而阻止了 IPsec 隧道的建立。
如 RFC 7383《互联网密钥交换协议第 2 版 （IKEv2） 消息分段》中所述，IKEv2 消息分段允许 IKEv2 在 IP 分段可能被阻止且对等方无法建立 IPsec 安全关联 （SA） 的环境中运行。IKEv2 分段将大型 IKEv2 消息拆分为一组较小的消息，以便在 IP 级别不存在分段。分段发生在对原始消息进行加密和身份验证之前，以便对每个片段进行单独加密和身份验证。在接收方上，片段被收集、验证、解密并合并到原始消息中。
IKEv2 的流量选择器
您可以在 IKEv2 中配置 IKE 协商期间使用的流量选择器。流量选择器是 IKE 对等方之间的协议，如果流量与指定的本地和远程地址对匹配，则允许流量通过 VPN 隧道。仅允许符合流量选择器的流量通过关联的安全关联 （SA）。流量选择器在隧道创建期间用于设置隧道并确定允许哪些流量通过隧道。
代理 ID
代理 ID 在互联网密钥交换 （IKE） 虚拟专用网络 （VPN） 协商的第 2 阶段使用。VPN 隧道的两端要么手动配置代理 ID（基于路由的 VPN），要么只在隧道策略中使用源 IP、目标 IP 和服务的组合。协商 IKE 第 2 阶段时，每一端都会将配置的本地和远程代理 ID 与实际接收的内容进行比较。
流量选择器
基于路由和基于策略的 VPN 都支持代理 ID。但是，多代理 ID 仅支持基于路由的 VPN。多代理 ID 也称为流量选择器。流量选择器是 IKE 对等方之间的协议，如果流量与指定的本地和远程地址对匹配，则允许流量通过隧道。您可以在基于路由的特定 VPN 中定义流量选择器，这可能会导致多个第 2 阶段 IPsec SA。仅允许符合流量选择器的流量通过 SA。当远程网关设备是非瞻博网络设备时，通常需要流量选择器。
网络地址转换遍历 （NAT-T）
网络地址转换遍历 （NAT-T） 是一种解决受 IPsec 保护的数据通过 NAT 设备进行地址转换时遇到的 IP 地址转换问题的方法。
对 IP 寻址（NAT 的功能）的任何更改都会导致 IKE 丢弃数据包。在第 1 阶段交换期间沿数据路径检测到一个或多个 NAT 设备后，NAT-T 会向 IPsec 数据包添加一层用户数据报协议 （UDP） 封装，以便在地址转换后不会丢弃这些设备。NAT-T 将 IKE 和 ESP 流量封装在 UDP 中，端口 4500 同时用作源端口和目标端口。由于 NAT 设备会老化过时的 UDP 转换，因此对等方之间需要保持连接消息。
NAT 设备的位置可以是：
只有 IKEv1 或 IKEv2 启动器位于 NAT 设备后面。多个启动器可以位于单独的 NAT 设备后面。发起方还可以通过多个 NAT 设备连接到响应方。
只有 IKEv1 或 IKEv2 响应程序位于 NAT 设备后面。
IKEv1 或 IKEv2 发起方和响应方都位于 NAT 设备后面。
Suite B 和 PRIME 加密套件
Suite B 是美国国家安全局指定的一组加密算法，允许商业产品保护机密或绝密级别的流量。Suite B 协议在 RFC 6379 Suite B IPsec 加密套件中定义。Suite B 加密套件提供封装安全有效负载 （ESP） 完整性和机密性，应在同时需要 ESP 完整性保护和加密时使用。IP 模块化加密 （PRIME） 的协议要求是为英国公共部门网络定义的 IPsec 配置文件，它基于 Suite B 加密套件，但使用 AES-GCM 而不是 AES-CBC 进行 IKEv2 协商。
支持以下加密套件：
Suite-B-GCM-128
Esp：高级加密标准 （AES） 加密，在伽罗瓦计数器模式 （GCM） 下使用 128 位密钥和 16 个八位字节完整性检查值 （ICV）。
艾克：在密码块链接 （CBC） 模式下使用 128 位密钥进行 AES 加密，使用 SHA-256 身份验证进行完整性，使用 Diffie-Hellman （DH） 组 19 建立密钥，以及使用椭圆曲线数字签名算法 （ECDSA） 256 位椭圆曲线签名进行身份验证。
Suite-B-GCM-256
Esp：在 GCM 中使用 256 位密钥和 16 个八位字节 ICV 进行 AES 加密，用于 ESP。
艾克：在 CBC 模式下使用 256 位密钥进行 AES 加密，使用 SHA-384 身份验证进行完整性，使用 DH 组 20 建立密钥，使用 ECDSA 384 位椭圆曲线签名进行身份验证。
PRIME-128
Esp：在 GCM 中使用 128 位密钥和 16 个八位字节 ICV 进行 AES 加密。
艾克：在 GCM 中使用 128 位密钥进行 AES 加密，使用 DH 组 19 建立密钥，并使用 ECDSA 256 位椭圆曲线签名进行身份验证。
PRIME-256
Esp：在 GCM 中使用 256 位密钥和 16 个八位字节 ICV 进行 AES 加密，用于 ESP。
艾克：在 GCM 中使用 256 位密钥进行 AES 加密，使用 DH 组 20 建立密钥，并使用 ECDSA 384 位椭圆曲线签名进行身份验证。
Suite-B 加密套件支持 IKEv1 和 IKEv2。PRIME 加密套件仅支持 IKEv2。