主要分为两个阶段:
- 第一阶段,通信双方协商和建立IKE协议本身使用的安全通道,即建立一个IKE SA;
- 第二阶段,利用第一阶阶段已通过认证和安全保护的安全通道,建立一对用于数据安全传输的IPSec SA
目录
IKEv1阶段1协商过程
IKEv1阶段1的目的是建立IKE SA。IKE SA建立后对等体间的所有ISAKMP消息都将进行加密和验证,这条安全通道可以保证IKEv1阶段2的协商能够安全进行。
IKEv1阶段1支持两种协商模式:
主模式协商过程
主模式包含三次双向交换,用到了六条信息,交换过程如图1所示。
- 策略交换:对应消息①和②。
- 密钥信息交换:对应消息③和④。
- 身份和认证信息交换:对应消息⑤和⑥。
图1 主模式协商过程(预共享密钥认证)
策略交换
消息①:发起方发送封装有IKE安全提议的SA载荷进行安全提议协商,SA中参数包括加密算法、认证算法、身份认证算法、DH组、IKE SA生存周期等。
消息②:响应方查找最先匹配的IKE安全提议,发送一个SA载荷,表明接受协商的IKE安全提议。
图2 消息①、②
密钥信息交换
消息③、④:发起者和接受者交换DH公开值(KE载荷)和临时随机数(Ni、Nr)。Ni、Nr是计算共享密钥(用来生成加密密钥和认证密钥)所必须的。
图3 消息③、④
身份和认证信息交换
消息⑤、⑥:双方交换身份ID(ID载荷)和验证Hash值(AUTH载荷)。这两个消息中传递的信息是加密的,加密的密钥由消息③、④中交换的密钥信息生成,所以身份信息受到保护。由于主模式下ID载荷经加密,所以获取报文头中无法看到。
图4 消息⑤、⑥
野蛮模式协商过程
野蛮模式只用到三条信息,交换过程如图5所示。
前两条消息①和②用于协商提议,交换Diffie-Hellma公共值、必需的辅助信息以及身份信息,并且消息②中还包括响应方发送身份信息供发起方认证,消息③用于响应方认证发起方。
图5 野蛮模式协商过程(预共享密钥认证)
消息①:发起端发送封装有IKE安全提议的SA载荷。在野蛮模式中,只带有一个安全提议(加密算法、认证算法、身份认证算法、DH组、IKE SA生存周期等),响应者可以选择接受或拒绝该安全提议。DH公开值(KE载荷)、临时随机数(Ni载荷)和身份ID(ID载荷)也在其中发送。野蛮模式下,身份信息未经加密,故获取报文头能够看到。
图6 消息①
消息②:响应者发送SA载荷,包含推荐的安全提议。DH公开值(KE载荷)、临时随机数(Nr载荷)和身份ID(ID载荷)、验证Hash值(AUTH载荷)也在其中发送。
图7 消息②
消息③:发起端发送验证Hash值确认协商成功。
图8 消息③
总结
IKEv1阶段1协商完成后,可以执行命令display ike sa,查看第一阶段的SA建立情况。当Flag参数为RD或RD|ST表示IKE SA已建立成功。其中,ST表示本端是SA协商发起方。
<sysname> display ike sa
IKE SA information :
Conn-ID Peer VPN Flag(s) Phase
------------------------------------------------------------------
16 2.1.1.1:500 RD|ST v1:2
14 2.1.1.1:500 RD|ST v1:1
Number of IKE SA : 2
-------------------------------------------------------------------
RD--READY ST--STAYALIVE RL--REPLACED FD--FADING TO--TIMEOUT
HRT--HEARTBEAT LKG--LAST KNOWN GOOD SEQ NO. BCK--BACKED UP
M--ACTIVE S--STANDBY A--ALONE NEG--NEGOTIATING
协商失败时,执行该命令显示可能为空、Flag参数为空或者Peer参数为0.0.0.0。
隧道两端IKE安全提议、预共享密钥等参数不匹配都将导致IKE SA无法建立。当隧道两端配置的IKE参数不一致时,常出现的debug信息如下。
- 两端的IKE安全提议不一致
<sysname> debugging ikev1 error
Aug 17 2017 14:29:15.800.1 sysname IKE/7/IKE_Debug:
IKE_ERROR 17:5773 Message from peer 2.1.1.1: Got NOTIFY of type NO_PROPOSAL_CHOS
EN
Aug 17 2017 14:29:15.800.3 sysname IKE/7/IKE_Debug:
IKE_ERROR 0:9946 Ikev1 error-info record(peer address: 2.1.1.1, error reason: ph
ase1 proposal mismatch,list number: 11). - 两端的预共享密钥不一致
<sysname> debugging ikev1 error
Aug 17 2017 15:18:09.800.1 sysname IKE/7/IKE_Debug:
IKE_ERROR 17:5773 Message from peer 2.1.1.1: Got NOTIFY of type PAYLOAD_MALFORME
D
<sysname> debugging ikev1 error
Aug 17 2017 15:24:53.940.2 sysname IKE/7/IKE_Debug:
IKE_ERROR 17:1053 Message from peer 1.1.1.1: Invalid Next Payload of Type 60 in
Payload Type 5
Aug 17 2017 15:24:53.940.3 sysname IKE/7/IKE_Debug:
IKE_ERROR 17:6847 Message from peer 1.1.1.1: dropping Message due to notificatio
n type INVALID_PAYLOAD_TYPE
Aug 17 2017 15:24:53.940.4 sysname IKE/7/IKE_Debug:
IKE_ERROR 17:4538 Message from peer 1.1.1.1: Message Sort Error Occurred
Aug 17 2017 15:24:53.940.5 sysname IKE/7/IKE_Debug:
IKE_ERROR 0:9946 Ikev1 error-info record(peer address: 1.1.1.1, error reason: ma
lformed payload,list number: 200). - 一端未配置remote-address
<sysname> debugging ikev1 error
Aug 17 2017 16:13:33.940.3 sysname IKE/7/IKE_Debug:
IKE_ERROR 0:9946 Ikev1 error-info record(peer address: 1.1.1.1, error reason: pe
er address mismatch,list number: 200).
Aug 17 2017 16:13:33.940.4 sysname IKE/7/IKE_Debug:
IKE_ERROR 0:3595 Phase 1 Exchange: ike peer configuration not found for peer "1.
1.1.1" - 本端remote-id与对端名称不一致
<sysname> debugging ikev1 error
Aug 17 2017 16:25:01.850.2 sysname IKE/7/IKE_Debug:
IKE_ERROR 25:6956 ERROR - Received remote-name(fw2) does not match with peer rem
ote-name(fw3)
Aug 17 2017 16:25:01.850.3 sysname IKE/7/IKE_Debug:
IKE_ERROR 0:9946 Ikev1 error-info record(peer address: 2.1.1.1, error reason: co
nfig ID mismatch,list number: 148).
IKEv1阶段2协商过程
IKEv1阶段2的目的就是建立用来传输数据的IPSec SA。阶段2的交换模式是快速模式,交换的载荷都是加密的。
协商过程
快速模式交换过程图如图1所示。
图1 IKEv1阶段2协商过程
消息①、②:协商IPSec安全提议(SA载荷),为PFS功能协商DH密钥组(KE载荷)。交换身份ID(ID载荷为可选)和完整性验证Hash值(AUTH载荷)。
IDi和IDr属于ID载荷,这里是在交换流量选择符,确定双方保护的流量一致(相当于IKEv2的TS载荷的作用)。
图2 消息①、②
消息③:发送完整性验证Hash值确认协商成功。其报文格式类似消息①。
总结
IKEv1阶段2协商完成后,可以执行命令display ike sa,查看第二阶段的IPSec SA建立情况。当Flag参数为RD或RD|ST表示SA已建立成功。其中,ST表示本端是SA协商发起方。
<sysname> display ike sa
IKE SA information :
Conn-ID Peer VPN Flag(s) Phase
------------------------------------------------------------------
16 2.1.1.1:500 RD|ST v1:2
14 2.1.1.1:500 RD|ST v1:1
Number of IKE SA : 2
-------------------------------------------------------------------
RD--READY ST--STAYALIVE RL--REPLACED FD--FADING TO--TIMEOUT
HRT--HEARTBEAT LKG--LAST KNOWN GOOD SEQ NO. BCK--BACKED UP
M--ACTIVE S--STANDBY A--ALONE NEG--NEGOTIATING
协商失败时,执行该命令显示Flag参数为空。
两端IPSec安全提议、PFS、ACL规则不匹配都将导致IPSec SA建立失败。阶段2报文是加密的,所以无法通过获取报文头检查IPSec安全提议配置。
当隧道两端配置的IPSec参数不一致时,常出现的debug信息如下。
- 两端的ACL规则不匹配
<sysname> debugging ikev1 error
Aug 17 2017 17:35:52.350.1 sysname IKE/7/IKE_Debug:
IKE_ERROR 17:5773 Message from peer 1.1.1.1: Got NOTIFY of type INVALID_ID_INFOR
MATION
Aug 17 2017 17:35:52.350.2 sysname IKE/7/IKE_Debug:
IKE_ERROR 0:9946 Ikev1 error-info record(peer address: 1.1.1.1, error reason: fl
ow mismatch,list number: 200).
<sysname> debugging ipsec error
Aug 17 2017 17:35:17.800.1 sysname IPSEC/7/IPSEC-DEBUG:
[IPSEC-Error] acl mismatch.(Ifindex=[7], SeqNum=[10],PeerAddress=[2.1.1.1], Peer
Port=[500]) - 两端的IPSec安全提议或PFS算法不一致
<sysname> debugging ikev1 error
Aug 18 2017 09:28:45.350.2 sysname IKE/7/IKE_Debug:
IKE_ERROR 0:9946 Ikev1 error-info record(peer address: 2.1.1.1, error reason: ph
ase2 proposal or pfs mismatch,list number: 200).
Aug 18 2017 09:28:45.350.3 sysname IKE/7/IKE_Debug:
IKE_ERROR 17:6847 Message from peer 2.1.1.1: dropping Message due to notificatio
n type NO_PROPOSAL_CHOSEN
<sysname> debugging ipsec error
Aug 18 2017 09:29:26.800.1 sysname IPSEC/7/IPSEC-DEBUG:
[IPSEC-Error] ipsec proposal or pfs mismatch.(Ifindex=[7], SeqNum=[10],PeerAddre
ss=[2.1.1.1], PeerPort=[500])