IKE Vendor ID载荷处理方法优化IPSEC NAT穿越协商.pdfVIP

专利技术交底书

发明名称一种ikevendorid载荷处理方法

技术联系人部门

电子邮件

一、本发明或实用新型要解决的技术问题？

本方法解决IPSECIKE带多个NAT穿越版本载荷进行协商时，因

无法确认加密模式导致协商失败的问题。本方法通过在IPSEC响应

者系统上配置版本载荷选择方法，保证与发起者建立适当加密模式，

从而确保IKE协商成功。

二、详细描述背景技术，并描述已有的与本发明或实用新型最接近的

技术方案。

（包括两个部分：背景技术和现有技术方案）

为保证IPSEC隧道穿越NAT设备，在进行IPSecIKE野蛮模式第一

阶段协商时，发起者initiator发出的协商报文中vendorid载荷有时包

括多个nat穿越选项。响应者responder会根据收到的多个nat穿越选

项得到NAT穿越时UDP加密模式差。在IKE快速模式（第二阶段协

商）时，此时IKE生成IPSEC安全，将从发起者发送的加密模

式（encmode）载荷中提取加密模式，并用此加密模式减去NAT穿越

时的UDP加密模式差值，得到的结果就是IPSEC隧道流中的加密模

式。此时会出现如下问题，不同NAT穿越版本对加密模式的设置也

是不同的，发起者是根据最后一个NAT穿越版本设置加密模式，而

响应者却是根据最高一个NAT穿越版本设置加密模式，这两者对

NAT穿越版本选择不同，对UDP加密模式差计算结果就不一致，从

而导致二者的最终加密模式值不同，从而使得响应者无法正常理解发

起者的加密模式，导致协商失败。

例如

1IKE发起者在阶段一协商时，在协商报文中带上3个vendorid

2IKE响应者收到协商报文并回复。响应者认为RFC3947版本大于

draft-ietf-ipsec-nat-t-ike-02\n和draft-ietf-nat-t-ike-00,因而基于RFC

3947,认为安全的提议的加密模式是3，加密模式差是2.

3IKE发起者在阶段二快速模式时发送安全提议。发起者是按照

draft-ietf-nat-t-ike-00设定的提议，发起者认为自己将

draft-ietf-nat-t-ike-00排在阶段一协商的最后，因而应该基于最后这个

载荷做协商。发起者设置加密模式是61443，并将61443作为加密模

式载荷发送出去。

4IKE响应者在收到安全提议并后，发现加密模式是61443，

于是将61443，与在步骤2中的加密模式差2，减去得到结果是61441。

即加密模式是61441，而响应者并不认识61441这种，导致

协商失败。

本发明的方法实施如下，仍然以上面的为例子

1IKE发起者在阶段一协商时，在协商报文中带上3个vendorid

2IKE响应者收到协商报文并回复。本发明方法在响应者系统上配置

响应者对NAT穿越版本的判定方法，判定方法采用下面的配置命令，

如果是命令set-natt-priority-highest，那么就取版本最高的一个

如果是命令set-natt-priority-sequence,那么就去载荷最靠后的那个作

为判断基准。现设置为set-natt-priority-sequence

使用本发明方法，系统认为draft-ietf-nat-t-ike-00载荷最靠后,因而基

于这个版本,认为安全的提议的加密模式是61443，加密模式差

是61442.

3IKE发起者在阶段二快速模式时发送安全提议。发起者是按照

draft-ietf-nat-t-ike-00设定的提议，发起者认为