IPSecVPN两个阶段协商过程分析李心春Word下载.docx
《IPSecVPN两个阶段协商过程分析李心春Word下载.docx》由会员分享，可在线阅读，更多相关《IPSecVPN两个阶段协商过程分析李心春Word下载.docx（16页珍藏版）》请在冰豆网上搜索。
即主模式对对端身份进行了保护，而野蛮模式则没有。
（二）两个阶段分别完成任务：
（1）第一个阶段IKE设置，有三个任务需要完成：
（a）协商一系列算法和参数（这些算法和参数用于保护隧道建立过程中的数据）；
（b）必须计算出两边使用的加密KEY值，例如，两边使用3DES算法加密，3DES算法则需要一个密码，这个密码两端必须一样，但又不能在链路上传递。
（c）对等体的验证，如何才能知道对端就是我要与之通信的对端。
这里验证有三种方法：
预共享、数字签名和加密临时值。
上面一系列过程都是IKE（Internet密钥交换协议，大多数厂商都把这个叫做VPNsGateway）这个协议来实现。
对于第一阶段需要注意以下几点：
（a1）只有remotevpn和easyvpn是积极模式的，其他都是用主模式来协商的；
（a2）让IKE对等体彼此验证对方并确定会话密钥，这个阶段用DH进行密钥交换，创建完IKESA后，所有后续的协商都将通过加密和完整性检查来保护。
（a3）第一阶段帮助在对等体之间创建了一条安全通道，使后面的第二阶段过程协商受到安全保护。
（2）第二阶段：
协商IPSecSA使用的安全参数，创建IPSecSA（SA可以加密两个对等体之间的数据，这才是真正的需要加密的用户数据），使用AH或ESP来加密IP数据流。
至此IPSecVPN隧道才真正建立起来。
（三）综上，有如下结论：
第一阶段作用：
对等体之间彼此验证对方，并协商出IKESA，保护第二阶段中IPSecSA协商过程；
第二阶段作用：
协商IPSec单向SA，为保护IP数据流而创建；
（四）举例验证：
以主模式，AH协议来简单分析一下IPSecVPN链接建立的过程（附带报文）：
第一个阶段三个任务，分别用6个消息来完成，每两个为一组，这些消息的具体格式取决于使用的对等体认证方法，使用预共享密钥进行验证的主模式（6条）协商过程使用ISAKMP消息格式来传递（基于UDP，端口号为500）。
6条消息如下：
（1）准备工作：
在前2条消息发送之前，发送者和接受者必须先计算出各自的cookie（可以防重放和DOS攻击），这些cookie用于标识每个单独的协商交换消息。
cookie——RFC建议将源目的IP、源目的端口、本地生成的随机数、日期和时间进行散列操作。
Cookie成为留在IKE协商中交换信息的唯一标识，实际上cookie是用来防止DOS攻击的，它把和其他设备建立IPSec所需要的连接信息不是以缓存的形式包存在路由器里，而是把这些信息HASH成个cookie值。
（2）1&
2消息：
消息1：
由发送方（协商发起端）发起，携带一些参数，发送方向接收方发送一条包含一组或多组策略提议（Raisecom工业路由器中是多组），在策略提议中包括5元组信息：
加密算法——DES；
散列算法——MD5-HMAC；
DH——Diffie-Hellman组-2；
认证方式——预共享；
IKESA寿命。
如下是Raisecom中高级选项配置的策略：
（认证方式采用“预共享”方式）
（对于DPD，具体作用不知道，默认是关闭）
下面简要介绍一下上述五元组信息：
（a）协商模式：
可以选择主模式（MainMode）或者野蛮模式（Aggressive）。
当选择主模式时，只能使用IP地址作为ID的类型。
当用户端设备的IP地址为动态获取的情况时，需要选择野蛮模式。
IKE野蛮模式相对于主模式来说更加灵活，可以选择根据协商发起端的IP地址或者ID来查找对应的身份验证字，并最终完成协商。
（b）验证方法AH（AuthenticationHeader）：
身份验证确认通信双方的身份。
目前在IKE提议中，仅可用pre-shared-key（预共享密钥）身份验证方法，使用该验证方法时必须配置身份验证字，并且两端的密钥要完全一致。
（c）加密算法：
包括DES和3DES加密算法；
DES算法采用56bits的密钥进行加密，3DES算法采用168bits的密钥进行加密；
AES128（AdvancedEncryptionStandard，即高级加密标准）采用Rijndael中的128bits的密钥进行加密；
AES192（AdvancedEncryptionStandard，即高级加密标准）采用Rijndael中的192bits的密钥进行加密；
AES256（AdvancedEncryptionStandard，即高级加密标准）采用Rijndael中的256bits的密钥进行加密；
一般来说，密钥越长的算法强度越高，受保护数据越难被破解，但消耗的计算资源会更多。
（d）Diffie-Hellman组标识（DH）：
用户可以选择Group1即768bit或Group2即1024bit。
（e）ISAKMP-SA生存周期：
IKE使用了两个阶段为IPSec进行密钥协商并建立安全联盟。
第一阶段，通信各方彼此间建立了一个已通过身份验证和安全保护的通道，即ISAKMP安全联盟（ISAKMPSA）；
第二阶段，用在第一阶段建立的安全通道为IPSec协商安全服务，即为IPSec协商具体的安全联盟，建立IPSecSA，IPSecSA用于最终的IP数据安全传送。
ISAKMP-SA生存周期可以设定为60-604800之间的一个整数。
（f）定时发送keepalive报文（不是必须携带）：
IKE通过ISAKMPSA向对端定时发送KeepAlive报文维护该条ISAKMPSA的链路状态。
当对端在配置的超时时间内未收到此KeepAlive报文时，如该ISAKMPSA带有timeout标记，则删除该ISAKMPSA及由其协商的IPSecSA；
否则，将其标记为timeout。
如下是抓包获取到的信息（设备为Raisecom工业路由器）：
由上图可知，模式为主模式，载荷类型为SA。
SA的数目和内容详见下图：
将载荷类型SA展开如下：
由下图可知，该SA中携带了三组策略，正好Raisecom中web页面配置的三组策略：
第一组TypePayload：
Transform（3）#0展开如下：
SA生存时间为10800；
加密机制为DES；
认证算法为SHA；
认证方法选择PSK（预共享密钥）；
DH为Group2；
第二组TypePayload：
Transform（3）#1展开如下：
第三组
TypePayload：
Transform（3）#2展开如下：
报文中的组顺序和web页面上组顺序不一致，这个无所谓，只要能对上即可，因为实际中只要这三个组能匹配上即可。
消息2：
由响应者（即对端设备）回应，内容基本一样，主要与发起者比较，是否与发起者的IKE策略匹配，不匹配则进行下一组比较，如果最终都找不到匹配，隧道就停止建立；
（note：
发起者将其所有IKE策略发给接受者，接受者则在自己的策略中寻找与之匹配的策略；
对比顺序从优先级号小的到大的；
默认策略实际就是个模板没作用，如果认证只配置预共享的话，其他参数就会copy默认策略里的）
报文如下：
由上图可知，接受端回应的消息中，匹配了发送端的一条策略，如果有一条匹配，则不需要匹配其他策略。
在消息1和消息2中报错可能出现的原因：
（a）peer路由不通（即，外层的IP地址不通，这里对应的是发送发10.1.1.3和接收方10.1.1.2这两个地址不通，这里配置简单属于直连，而实际大型组网中，中间会有很多其他网元，往往是通过配置动态路由）；
（b）cryptoiskmpkey没有设置（即，没有配置预共享密钥）；
（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）amodp=（Xa）bmodp=响应者密钥
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公共值以及随机数；
消息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、SApayload、转换集和策略。
消息5：
由发起者向响应者发送，主要是为了验证对端自己就是自己想要与之通信的对端。
这可以通过预共享、数字签名、加密临时值来实现。
消息6：
由响应者向发起者发送，主要目的和第五条一样：
在消息5和消息6中报错可能出现的原因：
（1）cryptoiskmpkey设置错了；
（即，两端的预共享密钥值设置的不一样）
（五）第二阶段：
第2阶段用三个消息来完成，目标是协商IPSecSA，而且只有一种模式，快速
升级会员 