IKE协议建立在 ISAKMP（Internet安全联盟和密钥管理协议）框架之上，是基于UDP的应用层协议，为IPSec提供了自动协商密钥、建立IPSec安全联盟的服务

IKE与IPSec的关系

IKE数据通过ISAKMP协议传输

IPSec数据通过ESP/AH协议传输

IKE版本

IKE协议分为IKEv1和IKEv2两个版本

IKE组件

IKE是一个复合协议，主要由三部分组成

IKE安全机制

IKE的安全机制可以实现在网络上安全地认证身份、分发密钥、建立IPSec SA

身份认证

确认双方的身份。

认证方式——预共享密钥认证、数字认证RSA认证、数字信封认证

认证算法——散列算法（MD5、SHA1、SHA2-256、SHA2-384、SHA2-512、SM3）

认证类型——IP地址，可识别名称-DN，设备序列号-ESN，名称-fqdn，用户域名-User-fqdn

认证方式与认证类型的关系

认证类型：配置IKE协商时本端和对端的ID类型
认证方式：对ID类型进行验证的方法
认证方式/认证类型 IP地址 可识别名称-DN 设备序列号-ESN 名称-fqdn 用户域名-User-fqdn
预共享密钥认证
（pre-share）支持不支持支持支持支持
RSA签名认证
（rsa-signature）支持支持不支持支持支持
RSA数字信封认证
（digital-envelope）支持支持不支持不支持不支持
SM2数字信封认证
（digital-envelope new）支持支持不支持不支持不支持

预共享密钥认证：双方采用共享的密钥对报文进行Hash计算，判断双方是否一致

数字签名认证、数字信封认证原理再加解密章节有讲解

数字签名认证是设备只需要上传本端证书，数字信封认证时需要上传本端和对端证书

注意事项

本端ID和对端ID类型无需一致，可以分别通过命令来指定本端、对端的ID类型

IKEv1使用主模式时，只可以通过IP地址来标识对等体

IKEv1使用野蛮模式时，支持IP地址和名称来标识对等体

身份保护

身份数据在密钥产生后加密传送，实现对身份数据的保护

加密算法——对称加密密钥（DES、3DES、AES-128、AES-192、AES-256、SM1、SM4）

DH密钥分发算法

产生密钥材料，并通过ISAKMP消息在发送和接收设备之间进行密钥材料交换

两端通过算法各自计算出完全相同的对称密钥（基础密钥SKEYID），然后通过基础密钥推导出相关的加密、验证密钥（a、e、d）

在任何时候，双方都不交换真正的密钥

注意事项

IKEv1在主模式的情况下，当两端的DH组不同时，会协商（例如A用DH1，B用DH1、DH2，经过协商就会使用DH1）
IKEv2在野蛮模式下，两端的DH组必须相同，他们不会进行DH组协商

PFS

通过执行一次额外的DH交换，保证IKE SA密钥的安全

IKEv1协商安全联盟

IKEv1协商SA分为两个阶段

阶段1——协商IKE SA建立安全通道

支持两种协商模式

主模式（Main Mode）

三次双向交换，使用六条ISAKMP信息

消息1到4 不加密，消息5、6加密

只支持采用IP地址来标识对等体，会协商DH算法

野蛮模式（Aggressive Mode）

使用3条ISAKMP消息

3条消息均没有加密

支持使用IP地址、Name来标识对等体，不会协商DH算法

阶段2——利用安全通道协商IPSec SA

只有一种模式-快速模式

快速模式

3条信息均加密，信息1、2、3通过skid-e进行加密

身份验证通过skid-a进行验证，通过skid-d生成的密钥用于IPSec传输数据加密（保证每个IPSec SA都有自己独一无二的密钥）。加密后的数据会通过安全协议进行传输。

IKEv1中DH算法生成密钥、IKE安全提议中的算法、IPSec安全提议中算法之间的关系

第一阶段中通过DH算法和IKE安全提议中的算法结合生成Skid-a、e密钥
第一阶段中通过DH算法和IPSec安全提议中的算法结合生成Skid-d密钥

IKEv2协商安全联盟的过程

建立IPSec SA正常情况下只需要 2次交换4条信息就可以完成一对IPSec SA的建立

IKEv2定义了三种交换

初始交换

正常情况下通过初始交换就可以完成IKE SA和IPSec SA的协商建立

创建子SA交换

2条消息建立一对IPSec SA

当一个IKE SA需要创建多对IPSec SA时，需要使用此交换来协商多于1对的IPSec SA

当需要进行重协商时，也可以使用此交换

必须在IKE初始交换完成后才能进行

通知交换

运行IKE协商的两端会传递一些控制信息（错误信息或者通告信息）

2条信息都加密

ISAKMP报文

UDP头部

正常情况下源目端口都是500

在NAT穿越情况下，会有报文使用4500端口

ISAKMP头部

Initiator Cookie：

IKEv1中表示发起方Cookie，验证对方身份是否真实。IKEv2中表示IKE的SPI，唯一标识一个IKE SA

Responder Cookie：

应答方，同上

Next Playload：

下一个载荷，表示ISAKMP后的第一个载荷是什么类型（目前13种）

一个ISAKMP报文中可以携带多个载荷，当字段为0表示是最后一个载荷

Version：

ISAKMP版本号，包括主版本号和次版本号

Exchange Type：

8位，目前只是用了3位

IKE定义的交换类型，定义了ISAKMP消息遵循的交换顺序

后面IKEv1中的主模式、野蛮模式、快速模式，IKEv2中的初始交换、子SA交换都属于IKE定义的交换类型

交换类型值
none 0
Base 1
Identity Protection 2
Authentication Only 3
Aggressive 4
Informational 5
ISAKMP Future Use 6-31
DOI Specific Use 32-239
Private Use 240-255

Message ID

报文ID，表示第二阶段的协议状态

Message Length

包围长度，头部+若干载荷的长度

IKEv1和IKEv2之间的区别

　 IKEv1 IKEv2
IPSec建立过程 两个阶段没有阶段
ISAKMP 二者支持的载荷类型不同
认证方法 预共享密钥
数字证书
数字信封预共享密钥
数字证书
EAP
数字信封
远程接入 通过L2TP over IPSec来实现支持
PFS 支持支持
IKE SA完整性算法 不支持（不准确）支持
IKEv1和v2对于“校验”都是支持的，通过验证算法来实现，
不过后来为了使我们产品的IPSec功能更符合RFC的规范要求，
于是我们在配置IKV2的时候，
把认证算法替换成了所谓的完整性算法，
其实两者的作用都是一样的，
都是通过算法提取摘要达到防篡改的目的

查看IKE隧道建立情况

ST表示是本端发起的协商

RD是指隧道建立成功

RL ：表示此通道已经被新的通道代替，一段时间后会被删除

v1:1或v2:1：

v1和v2表示IKE的版本；1表示建立安全通道进行通信的阶段，此阶段建立IKE SA

v1:2或v2:2：

v1和v2表示IKE的版本；2表示协商安全服务的阶段，此阶段建立IPSec SA

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/羊村懒王/article/detail/176519

认证类型：配置IKE协商时本端和对端的ID类型认证方式：对ID类型进行验证的方法
认证方式/认证类型	IP地址	可识别名称-DN	设备序列号-ESN	名称-fqdn	用户域名-User-fqdn
预共享密钥认证（pre-share）	支持	不支持	支持	支持	支持
RSA签名认证（rsa-signature）	支持	支持	不支持	支持	支持
RSA数字信封认证（digital-envelope）	支持	支持	不支持	不支持	不支持
SM2数字信封认证（digital-envelope new）	支持	支持	不支持	不支持	不支持