IPSecVPN两个阶段协商过程分析-李心春 下载本文

报文中的组顺序和web页面上组顺序不一致,这个无所谓,只要能对上即可,因为实际中只要这三个组能匹配上即可。

消息2:由响应者(即对端设备)回应,内容基本一样,主要与发起者比较,是否

与发起者的IKE策略匹配,不匹配则进行下一组比较,如果最终都找不到匹配,隧道就停止建立;

(note:发起者将其所有IKE策略发给接受者,接受者则在自己的策略中寻找与之匹配的策略;对比顺序从优先级号小的到大的;默认策略实际就是个模板没作用,如果认证只配置预共享的话,其他参数就会copy默认策略里的) 报文如下:

由上图可知,接受端回应的消息中,匹配了发送端的一条策略,如果有一条匹配,则不需要匹配其他策略。

在消息1和消息2中报错可能出现的原因:

(a)peer路由不通(即,外层的IP地址不通,这里对应的是发送发10.1.1.3和接收方10.1.1.2这两个地址不通,这里配置简单属于直连,而实际大型组网中,中间会有很多其他网元,往往是通过配置动态路由);

(b)crypto iskmp key没有设置(即,没有配置预共享密钥);

(c)一阶段的策略不匹配(这时需要检查两端设备的策略有不一致地方么)

(3)3&4消息:密钥交换过程

消息3:由发起者(即,隧道建立的发起者)发出,但是在发出消息3之前,有个

过程必须要完成,就是Diffie-Hellman算法过程。

Diffie-Hellman算法过程目的:在消息1和消息2中所协商的算法,它们必须需要一个KEY(即,共享密钥中设置的密码),这个KEY在两个对等体上必须一样,但同时这个KEY不能在链路中传递,因为传递KEY是一个不安全的手段。所以,该过程的目的是分别在两个对等体间独立地生成一个DH公共值,该公共值有什么作用?因为两个对等体上都生成该DH公共值后,它们会在接下来的消息3和消息4中传送给对方,打个比方,A收到了B的DH公共值,B收到了A的DH公共值。当A、B都收到了对方的该公共值后,问题就好解决了。因为有一个公式在数学中被论证成立,那么现在借助公式,就可以在两个对等体上生成一个只有它们两个对等体知道的相同的KEY,该公式为:

发起者密钥=(Xb)amod p = (Xa)bmod p=响应者密钥 note:这个密钥不是最终算法中使用的KEY,但两个对等体通过该KEY材料来生成另外三个密钥,分别是:

SKEYID_d——此密钥被用于计算后续IPSec密钥资源;

SKEYID_a——此密钥被用于提供后续IKE消息的数据完整性以及认证; SKEYID_e——此密钥被用于对后续IKE消息进行加密;

所以,由发起者发起的第三条消息主要是向对等体发送自己的DH公共值和Nonce随机数;

实际报文如下:

由上述报文可知,发送方开始向接收方发送自己的DH公共值以及随机数;

对端收到后,可以根据“消息1&消息2”中协商的DH算法,以及发送端在消息3中给出的DH和nonce值来生成SKEYID_d、SKEYID_a、SKEYID_e三个密钥;

消息4:同消息3,告知发送端自己的DH公共值和Nonce随机数;

报文如下:

由上述报文可知,接受方开始向发送方发送自己的DH公共值以及随机数;

对端收到后,可以根据“消息1&消息2”中协商的DH算法,以及接受端在消息4

中给出的DH和nonce值来生成SKEYID_d、SKEYID_a、SKEYID_e三个密钥;

(3)5&6消息:用于双方彼此验证。由“于消息1&消息2”的算法,以及“消息3&消息4”生成的三个KEY,所以在后续的“消息5&消息6”就能被加密传送,这个过程是受SKEYID_e加密保护的。

预共享密钥的作用:为了正确生成密钥,每一个对等体必须找到与对方相对应的预共享密钥,当有许多对等体连接时,每一对对等体两端都需要配置预共享密钥,每一对等体都必须使用ISAKMP分组的源IP来查找与其对等体对应的预共享密钥(此时,由于ID还没到,彼此先用HASH来彼此验证对方)HASH认证成分——SKEYID_a、cookieA、cookieB、preshare_key、SA payload、转换集和策略。

消息5:由发起者向响应者发送,主要是为了验证对端自己就是自己想要与之通信

的对端。这可以通过预共享、数字签名、加密临时值来实现。

消息6:由响应者向发起者发送,主要目的和第五条一样: