神奇cpp

这个屌丝很懒，什么也没留下！

热门标签

IKEv1协商安全联盟过程_ikev1协商流程详解

作者：神奇cpp | 2024-06-28 06:52:55

踩

ikev1协商流程详解

主要分为两个阶段：

第一阶段，通信双方协商和建立IKE协议本身使用的安全通道，即建立一个IKE SA；
第二阶段，利用第一阶阶段已通过认证和安全保护的安全通道，建立一对用于数据安全传输的IPSec SA

IKEv1阶段1协商过程

IKEv1阶段2协商过程

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协商发起方。

协商失败时，执行该命令显示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])

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