IPSecVPN两个阶段协商过程分析-李心春

《IPSecVPN两个阶段协商过程分析-李心春》由会员分享，可在线阅读，更多相关《IPSecVPN两个阶段协商过程分析-李心春（14页珍藏版）》请在金锄头文库上搜索。

1、（一） IPSec VPN隧道的建立过程分为两个阶段 ：第一个阶段： 分为两种模式主模式 （ Main Mode 和野蛮模式 （又称主动模式 Aggressive）第二个阶段：快速模式（ Quick Mode ）区别：主模式与野蛮模式的区别：（ 1）野蛮模式协商比主模式协商更快。因为主模式需要交互 6 个消息，而野蛮模式只需要交互 3 个消息；（ 2）主模式协商比野蛮模式协商更严谨、更安全。因为主模式在 “消息 5& 消息 6” 中对 ID 信息进行了加密。 而野蛮模式由于受到交换次数的限制， ID 消息在“消息 1&消息 2”中以明文的方式发送给对端。即主模式对对端身份进行了保护，而野蛮模式

2、则没有。（二） 两个阶段分别完成任务 ：（ 1）第一个阶段 IKE设置，有三个任务需要完成：（ a） 协商一系列算法和参数 （这些算法和参数用于保护隧道建立过程中的数据） ；（ b） 必须计算出两边使用的加密 KEY值， 例如， 两边使用 3DES算法加密， 3DES算法则需要一个密码，这个密码两端必须一样，但又不能在链路上传递。（ c）对等体的验证，如何才能知道对端就是我要与之通信的对端。这里验证有三种方法：预共享、数字签名和加密临时值。上面一系列过程都是 IKE（ Internet 密钥交换协议，大多数厂商都把这个叫做 VPNs Gateway ）这个协议来实现。对于第一阶段需要注意以下几

3、点：（ a1） 只有 remote vpn 和 easy vpn 是积极模式的， 其他都是用主模式来协商的；（ a2）让 IKE对等体彼此验证对方并确定会话密钥，这个阶段用 DH 进行密钥交换，创建完 IKE SA后，所有后续的协商都将通过加密和完整性检查来保护。（ a3） 第一阶段帮助在对等体之间创建了一条安全通道， 使后面的第二阶段过程协商受到安全保护。（ 2）第二阶段：协商 IPSec SA使用的安全参数， 创建 IPSec SA（ SA可以加密两个对等体之间的数据，这才是真正的需要加密的用户数据） ， 使用 AH或 ESP来加密 IP数据流。 至此 IPSec VPN隧道才真正建立起来

4、。（三） 综上，有如下结论：第一阶段作用：对等体之间彼此验证对方，并协商出 IKE SA，保护第二阶段中 IPSec SA协商过程；第二阶段作用：协商 IPSec单向 SA， 为保护 IP 数据流而创建 ；（四） 举例验证：以主模式， AH 协议来简单分析一下 IPSec VPN链接建立的过程（附带报文） ：第一个阶段 三个任务，分别用 6 个消息来完成，每两个为一组，这些消息的具体格式取决于使用的对等体认证方法，使用预共享密钥进行验证的主模式（ 6 条）协商过程使用 ISAKMP消息格式来传递（基于 UDP，端口号为 500） 。 6 条消息如下：（ 1）准备工作：在前 2 条消息发送之前，

5、发送者和接受者必须先计算出各自的 cookie（可以防重放和 DOS攻击） ，这些 cookie 用于标识每个单独的协商交换消息。cookie RFC建议将源目的 IP、源目的端口、本地生成的随机数、日期和时间进行散列操作。 Cookie 成为留在 IKE 协商中交换信息的唯一标识，实际上 cookie 是用来防止 DOS攻击的，它把和其他设备建立 IPSec所需要的连接信息不是以缓存的形式包存在路由器里，而是把这些信息 HASH成个 cookie 值。（ 2） 1&2 消息：消息 1：由发送方（协商发起端）发起，携带一些参数，发送方向接收方发送一条包含一组或多组策略提议 （ Raisecom

6、 工业路由器中是多组） ，在 策略提议中包括 5元组信息 ：加密算法 DES；散列算法 MD5-HMAC；DH Diffie-Hellman 组 -2；认证方式预共享；IKE SA寿命。如下是 Raisecom 中高级选项配置的策略：（认证方式采用“预共享”方式）（对于 DPD，具体作用不知道，默认是关闭）下面简要介绍一下上述五元组信息：（ a）协商模式：可以选择主模式（ Main Mode ）或者野蛮模式（ Aggressive） 。当选择主模式时，只能使用 IP 地址作为 ID 的类型。当用户端设备的 IP 地址为动态获取的情况时， 需要选择野蛮模式。 IKE野蛮模式相对于主模式来说更加灵

7、活， 可以选择根据协商发起端的 IP 地址或者 ID 来查找对应的身份验证字，并最终完成协商。（ b）验证方法 AH（ Authentication Header ） ：身份验证确认通信双方的身份。目前在 IKE提议中，仅可用 pre-shared-key（预共享密钥）身份验证方法，使用该验证方法时必须配置身份验证字，并且两端的密钥要完全一致。（ c）加密算法：包括 DES和 3DES加密算法； DES算法 采用 56bits 的密钥进行加密， 3DES算法 采用168bits 的密钥进行加密； AES128（ Advanced Encryption Standard ， 即高级加密标准）采用

8、 Rijndael 中的 128bits 的密钥进行加密； AES192（ Advanced Encryption Standard ，即高级加密标准）采用 Rijndael 中的 192bits 的密钥进行加密； AES256（ Advanced Encryption Standard ，即高级加密标准）采用 Rijndael 中的 256bits 的密钥进行加密；一般来说，密钥越长的算法强度越高，受保护数据越难被破解，但消耗的计算资源会更多。（ d） Diffie-Hellman 组标识（ DH） ：用户可以选择 Group 1 即 768bit 或 Group 2 即 1024bit 。

9、（ e） ISAKMP-SA生存周期：IKE使用了两个阶段为 IPSec进行密钥协商并建立安全联盟。第一阶段，通信各方彼此间建立了一个已通过身份验证和安全保护的通道，即 ISAKMP 安全联盟（ ISAKMP SA） ；第二阶段，用在第一阶段建立的安全通道为 IPSec 协商安全服务，即为 IPSec协商具体的安全联盟， 建立 IPSec SA， IPSec SA用于最终的 IP数据安全传送。 ISAKMP-SA生存周期可以设定为 60-604800 之间的一个整数。（ f）定时发送 keepalive 报文（不是必须携带） ：IKE通过 ISAKMP SA向对端定时发送 KeepAlive报

10、文维护该条 ISAKMP SA的链路状态。当对端在配置的超时时间内未收到此 KeepAlive 报文时， 如该 ISAKMP SA带有 timeout标记，则删除该 ISAKMP SA及由其协商的 IPSec SA；否则，将其标记为 timeout 。如下是抓包获取到的信息（设备为 Raisecom工业路由器） ：由上图可知，模式为主模式，载荷类型为 SA。 SA的数目和内容详见下图：将载荷类型 SA 展开如下：由下图可知， 该 SA中携带了三组策略， 正好 Raisecom 中 web 页面配置的三组策略：第一组 Type Payload： Transform（ 3） # 0 展开如下：SA

11、生存时间为 10800；加密机制为 DES；认证算法为 SHA；认证方法选择 PSK（预共享密钥） ； DH 为 Group 2；第二组 Type Payload： Transform（ 3） # 1 展开如下：第三组Type Payload： Transform（ 3） # 2 展开如下：报文中的组顺序和 web 页面上组顺序不一致，这个无所谓，只要能对上即可，因为实际中只要这三个组能匹配上即可。消息 2：由响应者（即对端设备）回应，内容基本一样，主要与发起者比较，是否与发起者的 IKE 策略匹配，不匹配则进行下一组比较，如果最终都找不到匹配，隧道就停止建立；（ note ：发起者将其所有

12、IKE 策略发给接受者，接受者则在自己的策略中寻找与之匹配的策略；对比顺序从优先级号小的到大的；默认策略实际就是个模板没作用，如果认证只配置预共享的话，其他参数就会 copy 默认策略里的）报文如下：由上图可知，接受端回应的消息中，匹配了发送端的一条策略，如果有一条匹配，则不需要匹配其他策略。在消息 1 和消息 2 中报错可能出现的原因 ：（ a） peer 路由不通（即，外层的 IP 地址不通，这里对应的是发送发 10.1.1.3 和接收方 10.1.1.2 这两个地址不通，这里配置简单属于直连，而实际大型组网中，中间会有很多其他网元，往往是通过配置动态路由） ；（ b） crypto is

13、kmp key 没有设置（即，没有配置预共享密钥） ；（ c）一阶段的策略不匹配（这时需要检查两端设备的策略有不一致地方么）（ 3） 3&4 消息：密钥交换过程消息 3：由发起者（即，隧道建立的发起者）发出，但是在发出消息 3 之前，有个过程必须要完成，就是 Diffie-Hellman 算法过程。Diffie-Hellman 算法过程目的：在消息 1 和消息 2 中所协商的算法，它们必须需要一个 KEY（即，共享密钥中设置的密码） ，这个 KEY在两个对等体上必须一样，但同时这个 KEY不能在链路中传递，因为传递 KEY是一个不安全的手段。所以，该过程的目的是分别在两个对等体间独立地生成一个

14、 DH 公共值，该公共值有什么作用？因为两个对等体上都生成该 DH 公共值后，它们会在接下来的消息 3 和消息 4 中传送给对方，打个比方， A 收到了 B 的 DH 公共值， B 收到了 A 的 DH 公共值。当 A、 B都收到了对方的该公共值后，问题就好解决了。因为有一个公式在数学中被论证成立，那么现在借助公式，就可以在两个对等体上生成一个只有它们两个对等体知道的相同的 KEY，该公式为：发起者密钥 =(Xb)amod p = (Xa)bmod p=响应者密钥note： 这个密钥不是最终算法中使用的 KEY， 但两个对等体通过该 KEY材料来生成另外三个密钥，分别是：SKEYID_d此密钥

15、被用于计算后续 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 随机

16、数；报文如下：由上述报文可知，接受方开始向发送方发送自己的 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