一种实现主机移动性和多家乡功能的密钥交换协议方法

1.一种实现主机移动性和多家乡功能的密钥交换协议方法，采用主机身份协议HIP时，在传输层和网络层之间加入一个主机身份协议层，为每台HIP主机设置至少一个主机身份以及与该主机身份相应的主机标识符，将每台HIP主机的传输层关联绑定到相应的主机标识符上；其特征在于：
使HIP主机至少知道其通信对端的一个可达的IP地址；所述的IP地址为HIP交换中最初使用的IP地址；
在所述HIP主机及其通信对端之间通过HIP交换建立互联网协议安全联盟；
将所述的互联网协议安全联盟绑定到所述HIP主机的主机标识符上，使所述的HIP主机能够从任何地址接收受由HIP建立的封装安全载荷安全联盟保护的数据包；所述的HIP主机也能够改变自己的IP地址并且继续向通信对端发送数据包。
2.根据权利要求1所述的方法，其特征在于，在建立互联网协议安全联盟之前，在通信对端之间进行相互认证，并建立一个包含共享机密信息的互联网密钥交换协议联盟，在所述的互联网密钥交换协议联盟中包含秘密信息和一系列加密算法；
其中，发起者采用混合/匹配方式，在所列出的可以支持的算法中建议一个或多个算法套件。
3.根据权利要求1所述的方法，其特征在于，在通信中对封装安全载荷和认证头部联盟使用IP压缩技术。
4.根据权利要求1所述的方法，其特征在于，在交换过程中，每一组交换均由一对报文组成，所述的一对报文包括请求和应答；其中：
在一定的时间间隔内如果请求方没有收到应答方的应答，则请求方需重传请求或放弃连接。
5.根据权利要求4所述的方法，其特征在于，在交换过程中完成的交换包括：
IKE_SA_INIT交换，协商包括加密算法、Nonces、Diffie-Hellman交换在内的值；
IKE_AUTH交换，认证前面的消息、交换身份和证书并建立第一个互联网协议安全联盟。
6.根据权利要求5所述的方法，其特征在于，在交换过程中完成的交换还包括：CREATE_IPSEC_SA交换，用来建立以后的互联网协议安全联盟。
7.根据权利要求5所述的方法，其特征在于，在交换过程中完成的交换还包括：INFORMATIONAL交换，用来删除联盟报告错误条件，并可以执行检查生存期的管理步骤。
8.根据权利要求5所述的方法，其特征在于，在交换过程中交换的顺序为：首先进行所述的IKE_SA_INIT交换，然后进行所述的IKE_AUTH交换；
接下来使用的任意数量的CREATE_IPSEC_SA和INFORMATIONAL交换，它们的顺序为任意。
9.根据权利要求8所述的方法，其特征在于，通过一次所述的IKE_SA_INIT交换和一次所述的IKE_AUTH交换完成初始交换，从而建立互联网密钥交换协议联盟和第一个互联网协议安全联盟。
10.根据权利要求5或8或9所述的方法，其特征在于，
所述的IKE_SA_INIT交换包括：
请求报文：HDR，SAil，KEi，Ni；
应答报文：HDR，SArl，KEr，Nr；
所述的IKE_AUTH交换包括：
请求报文：HDR，SK{IDi，[IDr，]AUTH，SAi2，TSi，TSr}；
应答报文：HDR，SK{IDr，AUTH，SAr2，TSi，TSr}；
其中，所述的HDR是每个交换消息的头部，其包括安全参数索引SPI、版本号以及各种类型的标志；
所述的SAil载荷规定了请求方为建立互联网密钥交换协议联盟所支持的加密算法，应答方从请求方提供的选项中选择一套加密算法并且在SArl载荷中表示出来；
所述的KEi载荷传送请求方的Diffie-Hellman值，通过应答方KEr载荷完成Diffie-Hellman交换；
所述的Ni和Nr载荷分别表示请求方和应答方的Nonce；
请求方在IDi载荷中声称自己的身份，使用AUTH载荷证明对IDi相关秘密信息的认识并保护第一个报文内容的完整性；
可选的IDr载荷使请求方能够指定与之通信的应答方众多身份中的一个，应答方使用SAr2载荷开始协商互联网协议安全联盟；
应答方在IDr载荷中声称自己的身份，用AUTH载荷认证其身份并保护第二个报文的完整性，并完成互联网协议安全联盟的协商。
11.根据权利要求10所述的方法，其特征在于，在初始交换的协商中每一端都会生成密钥种子，并从中生成互联网密钥交换协议联盟的所有密钥；
接下来的所有报文，除了头部全部被加密并受到完整性保护，且用来加密和进行完整性保护的所有密钥都来自于所述的密钥种子。
12.根据权利要求11所述的方法，其特征在于，所述的密钥包括：
SK_e，即完成加密；SK_a，即完成认证；和SK_d，以用来产生后面互联网协议安全联盟阶段需要的加密材料；
所述SK_e和SK_a为单向计算；
采用Diffie-Hellman值生成保护互联网密钥交换协议联盟的密钥SK_e和SK_a。
13.根据权利要求10所述的方法，其特征在于，所述的IKE_AUTH交换中的报文接收者必须验证所有签名和MAC的计算是否正确，以及ID载荷中的名称与产生AUTH载荷的密钥是否相符合。
14.根据权利要求6或8所述的方法，其特征在于，
所述的CREATE_IPSEC_SA交换只包含一对独立的请求/响应信息，即：
请求方报文：HDR，SK{[N]，SA，Ni，[KEi]，[TS i，TSr]}；
应答方报文：HDR，SK{SA，Nr，[KEr]，[TSi，TSr]}；其中：
请求方在SA载荷中发送SA提议，在Ni载荷中发送Nonce，在KEi载荷中选择地发送Diffie-Hellman值，在TSi和TSr载荷中选择地发送提议的流量选择器；如果SA提议中包含不同的Diffie-Hellman组，KEi必须是发起方希望响应方接受的组中的一个元素；如果猜测错误，则CREATE_IPSEC_SA交换失败，并不得不尝试一个新的KEi；头部之后的报文是加密的，报文使用为IKE SA协商的加密算法进行完整性保护；
应答方使用相同的消息ID来响应，并在SA载荷中答复接受的SA提议，并在KEr载荷中答复Diffie-Hellman值；如果响应方选择不同组的加密组件它必须拒绝请求，请求方重传请求，并且在请求中要包含应答方所选择组中的KEi载荷.
15.根据权利要求7或8所述的方法，其特征在于，所述的INFORMATIONAL交换只能在起始交换之后发生，并且用协商的密钥加密保护；
所述的INFORMATIONAL交换中的报文包含0个或多个通告，删除，和配置载荷；
所述的INFORMATIONAL交换请求的接收端必须发出响应。
16.根据权利要求15所述的方法，其特征在于，响应是没有载荷的报文；INFORMATIONAL交换的请求报文也可以不包括任何载荷。
17.根据权利要求15所述的方法，其特征在于，定义一种新的参数用来完成HIP主机交换关于IP地址和地址改变信息的功能：HIP_NOTIFY_REA；
当移动主机从一个IP地址切换到另一个IP地址时，会与对端断开连接一段很短的时间；一得到新IP地址，移动主机就通过所述的INFORMATIONAL交换向对端发送HIP_NOTIFY_REA参数并指出以下问题：新IP地址，与新IP地址相关的SPI，地址生存时间，和新地址是否为首选地址。
18.根据权利要求15所述的方法，其特征在于，定义一种新的参数用来完成HIP主机交换关于IP地址和地址改变信息的功能：HIP_NOTIFY_REA；
所述的主机具有多于一个的接口，该主机通过HIP_NOTIFY_REA参数通知对端主机附属的接口；主机需为每个用来从对端主机接收数据的接口使用不同的SA；当提供给对端主机多于一个的地址，主机需指出首选地址；
当处理建立新SA的入站HIP_NOTIFY_REA时，主机使用包含HIP_NOTIFY_REA的通告的目的地址作为HIP_NOTIFY_REA加NES指向的本地地址；
主机可以使用相同的IP地址向不同的对端地址发送HIP_NOTIFY_REA，这会同时建立有不同源地址的多个入站SA。
19.根据权利要求15所述的方法，其特征在于，定义一种新的参数用来完成HIP主机交换关于IP地址和地址改变信息的功能：HIP_NOTIFY_REA；
所述的主机包含一个具有多个全球IP地址的接口；该主机通过HIP_NOTIFY_REA参数通知对端主机附属的接口；主机需为每个用来从对端主机接收数据的接口使用不同的SA；当提供给对端主机多于一个的地址，主机需指出首选地址；
当处理建立新SA的入站HIP_NOTIFY_REA时，主机使用包含HIP_NOTIFY_REA的通告的目的地址作为HIP_NOTIFY_REA加NES指向的本地地址；
主机可以使用相同的IP地址向不同的对端地址发送HIP_NOTIFY_REA，这会同时建立有不同源地址的多个入站SA；
此外，当主机本身有多个接口时，单个接口也可能成为站点多家乡。
20.根据权利要求15所述的方法，其特征在于，定义一种新的参数用来完成HIP主机交换关于IP地址和地址改变信息的功能：HIP_NOTIFY_REA；
当交换完成之后两个主机同时需要添加额外的地址，其中：
主机1添加地址1b，并向位于地址2a的另一主机发送HIP_NOTIFY_REA，而且两个主机之间会加入一组新的SPI；
主机2添加地址2b，主机2选择向主机1的地址1a、地址1b、或地址1a和地址1b两者同时发送HIP_NOTIFY_REA；
如果选择向两个地址同时发送，那么两个主机之间会存在一个完整的SA网络。
21.根据权利要求15所述的方法，其特征在于，定义一种新的参数用来完成HIP主机交换关于IP地址和地址改变信息的功能：HIP_NOTIFY_REA；
所述主机可同时具有移动性和多家乡，也就是说有多个移动接口；
此外，如果接口使用不同的接入技术，则一个接口是稳定的而其它的接口是移动的；HIP_NOTIFY_REA加CREATE_IPSEC_SA足够灵活能够处理这样的场景。
22.根据权利要求1所述的方法，其特征在于，所述的主机包括：安全网关。

技术领域\n本发明涉及网络技术，其特别涉及利用基本主机身份协议(HIP)完成一些移动性和多家乡功能的方法，具体的讲是一种实现主机移动性和多家乡功能的密钥交换协议(IKE-H)方法。\n背景技术\n当前世界范围的Internet网络只存在两种名称空间：IP地址和域名服务器(DNS)。这两种名称空间在使用时还存在一些问题[1]，特别是IP地址。现在的IP地址同时代表网络实体的位置和接口，其中实体的位置是用来完成路由功能的，而实体通过接口连接到网络，也就是说IP地址还同时代表实体身份。这种情况在原先网络拓扑基本是固定不变的情况下并没有太多的问题。而随着人们对移动性的要求日益增长，网络中主机移动实体的不断增加，同时还会要求网络中的实体(特别是安全网关)具有安全多家乡的特点。这样就又从安全的角度对网络主机的移动性和多家乡性提出了更多的要求：如防止移动网络中出现中间人地址盗窃攻击和针对目标地址的DoS攻击等[2]。此时，IP地址同时代表网络实体的位置和接口的思想就必然会产生如地址管理、原有网络安全协议不能有效工作等问题[3]。\n现有技术一、在现有的移动IP技术中，移动IPv6是今天最有效地可用移动建议之一，所以这里主要介绍移动IPv6技术，并请参见移动IPv6的标准[4]以及移动性和安全协议IPSec的交互性讨论的另外一篇文档[5]。\n如图1所示为一个基本的移动IPv6组成，一个IPv6移动节点是一个多主机地址节点，它同时拥有一个转交地址和一个家乡地址，其中转交地址用来路由IP包，其前缀是所访问链路网络的前缀。转交地址是临时的，必须要对它进行一个返回路由能力检查之后才能使用该地址参与通信；家乡地址用来识别移动节点，其前缀是家乡链路网络的前缀。移动IPv6允许节点从一个链路移动到另一个链路而无须改变家乡地址。无论节点当前在哪个链路，都可以使用这个地址将数据包转发到移动节点。移动到新的链路后，移动节点仍然可以与其它节点继续通信。因此移动节点离开家乡链路的行为对于传输和高层协议来说是透明的。\n需要在家乡网络和移动节点之间建立一个“IPSec反向隧道”来保护家乡注册(即家乡地址与转交地址的绑定)以及后面经过家乡网络到达移动节点的数据流，要使用家乡地址和转交地址来建立隧道的安全联盟(SA)，用家乡地址作为流量选择器。\n家乡地址与转交地址之间的关系被称为“绑定”。当在外地链路时，移动节点会在作为家乡代理的路由器上注册当前的转交地址。移动节点通过向家乡代理发送“绑定更新”报文来执行绑定注册。家乡代理相应发送一个“绑定确认”报文。\n与移动节点通信的节点称为“通信对端”，它即可以是移动的也可以是固定的。移动节点通过对端注册向通信对端提供它当前的位置信息，通信对端返回一个返回可路由测试报文来认证绑定的建立。\n如图2所示为返回可路由测试基本过程，其中家乡初始测试和转交初始测试报文同时发送。该程序只需要通信节点对端作少量的处理，家乡测试和转交测试报文可以很快的返回(也可能几乎是同时的)。\n移动节点与通信对端之间有两种通信模式。第一种模式是双向隧道(如图3所示)，这种模式不需要通信对端支持移动IPv6，而且，即使移动节点没有在通信对端注册当前的绑定，这种模式仍然可以使用。从通信对端发出的数据包会路由到家乡代理，再通过隧道发往移动节点。从移动节点发出的数据包先通过隧道发往家乡代理，再以正常的方式路由到通信对端。在这种模式中，家乡代理在家乡链路上使用代理邻居发现协议截取指向移动节点家乡地址的数据包。被截取的数据包通过隧道发送到移动节点当前的转交地址。\n第二种模式是路由最佳化(如图4所示)，需要移动节点向通信对端绑定当前的转交地址。从通信对端发出的数据包可以直接路由到移动节点的转交地址。当发送到任意IPv6地址的数据包时，通信对端都会检查缓存的绑定条目。若找到匹配的条目，节点就使用新的IPv6路由头，将数据包路由到绑定条目指定的转交地址。\n将数据包直接发送到移动节点的转交地址可以得到最短的通信路径。同时也避免了家乡链路与家乡代理的阻塞。此外，还能减轻家乡代理和相关链路发生故障所引起的影响。\n当直接向移动节点发送数据包时，通信对端将目的地址设为移动节点的转交地址。同时在IPv6的扩展头中加入新型的路由头，包含所要求的家乡地址。类似的，移动节点将数据包的源地址设为当前的转交地址，在IPv6的扩展头中加入新的目的头，包含要求的家乡地址。在数据包中包含家乡地址，使得转交地址的使用对于IP层以上的协议来说是透明的。\n现有技术一的缺点在于：现有的移动IPv6协议虽然在移动节点和家乡网络之间强制要求使用网络安全协议IPSec，并可以采用IKEv1(或者IKEv2)密钥交换协议建立封装安全载荷安全联盟(ESP SA)来保护移动节点和家乡代理之间的绑定注册消息，以及此后的双向隧道模式通信流量数据[4]。但是，当移动节点再次发生移动或者由于其他原因使得与家乡网络建立连接的接口IP地址发生改变时，原先保护通信的ESP SA就不可使用了，这时要想继续保护流量只能采用重建SA的方式。而重新建立SA的过程建立代价比较大必然会对正常通信造成延时，并且会对无线信道造成带宽过多占用从而造成网络性能下降[6][7]。可以想象如果移动节点的位置在网络中不断的变化那么将会对网络通信造成“通信流量风暴”，并有可能造成网络的拥塞现象。这还只是移动节点变化的情况，如果家乡网络(主要是指家乡代理路由器)由于某种原因也要发生位置的改变那么除了以上情况外，由于双方可能同时发生移动还有可能正常的端到端IKE交换连接都无法完成[3]。\n此外，如果在移动环境中移动节点和通信节点之间同样想要建立各种IPSec连接，正常的连接建立之后如果双方之中任何一方或者双方同时要发生运动，那么同样会造成如上描述的情况，而且在通信双方都是移动体的时候发生“通信流量风暴”和正常的端到端IKE交换连接都无法完成的情况更为普遍。\n综上所述，移动IP这种目前比较为世界看好的解决IP移动性问题的方法，在自身的安全设计上还有包括但不限于以上的问题[8]，特别是在与网络层比较完善和成熟使用的IPSec协议协同使用时还有很多问题。虽然针对这些问题也有一些解决的方法[9][10]，但是从根本上看来现有的移动IP对于主机移动所带来的地址变化问题还不能最佳解决，此外移动IP对于移动环境下的安全网关多家乡问题也没有太多的考虑.\n现有技术二、这里介绍主机身份协议(HIP)技术，主要考虑IETF的HIP工作组有关基本HIP协议完成一些移动性和多家乡功能的建议和方案。主要内容在HIP的基本框架结构[11]以及有关移动性和多家乡具体解决办法的另一篇建议个人讨论文档[12]中。\n参考文献1\n(“Host Identity Protocol Architecture”，work in progress，Internet-Draft，IETF，June 2004)为IETF个人草案draft-moskowitz-hip-arch-06，其中提供了主机标识符名称空间，填补了IP名称空间和DNS名称空间的空白。主机标识符名称空间由主机标识符(Host Identifiers，HI)组成。主机标识符本质上具有密码特性，是不对称密钥对中的公钥。每台主机都有至少一个主机身份以及与该主机身份相应的主机标识符HI，该主机标识符既可以是公开的，也可以是不公开的(draft-moskowitz-hip-arch-06，2.Introduction)。\n使用主机身份需要其自己的协议层，即介于网络层协议和传输层协议之间的主机身份协议HIP层。主机标识符名称空间中的名称基于公钥密码学，用来对业务提供认证(draft-moskowitz-hip-arch-06，4.1 A desire for a Namespacefor Computing Platforms)。并且，HIP提供了传输层协议的不同绑定，即，传输层关联(transport layer associations，如TCP连接或者UDP关联)不再绑定到IP地址上，而是将传输层关联通过主机身份标记(Host Identity Tag，HIT)或本地范围标识(Local Scope Identifier，LSI)绑定到主机身份上，绑定示意图见图5b。它与传统的其他IP协议主要不同在于使Socket套接口不再和IP地址结合(如图5a、5b所示)，这样就可以为我们解决一般情况的地址变化以及多家乡等问题带来便利。一台物理设备可能会有不同的逻辑端点，根据HIP协议，这些不同的逻辑端点具有不同的主机身份。因为传输联盟是绑定到主机身份上的，因此，某个主机身份从一台物理设备切换到另一台物理设备上时，可以同时将所有的传输层关联进行切换而不会断开这些传输层关联(draft-moskowitz-hip-arch-06，6.1 Transport associations and endpoints)。\nHIP为了与IPv6协议兼容所提出的思想是：将IPv6一半的地址空间(64位)来代表HI，对HI进行hash运算之后为128位的HIT。对一个HIP主机DNS解析服务器将返回一个HIT以及一个IPv6地址。对于HIT在HI层将执行一个类似于网络地址转换(NAT)的进入/外出包处理。\n此外，为了在通信节点对等体地址改变时保证HIP协议端到端通信的安全性，如对端认证和地址源认证等，防止在HIP协议中出现拒绝服务(DoS)或者中间人(MitM)攻击，在HIP交换发起者和响应者之间需要一种高效、可靠的密钥交换协议。分析现有的HIP协议所定义的“基本交换”[2]，交换完成后生成一个IPSec SA来保护随后进行的IPSec ESP通信，其基本交换过程图6所示。在双方交换消息的过程中始终采用这对表示双方身份的公开HIT密钥来标记，由产生HIT的双方各自保存自己的私有密钥的安全，由基本密钥交换协议来完成身份认证的功能，这样HI公钥概念就构成了HIP协议的安全基础。\n在HIP消息基本交换完成之后就创建了一个主机身份安全内容HISC(其中包含IPSec ESP的安全联盟).之后，就可以继续交换由ESP传输模式来加密保护的消息(如检验端节点声明的IP地址是否实际可达).图7和图8是加入HIP层前后比较的报文格式，其中：图7为现有的使用ESP的报文的结构；图8为考虑HIP的新的报文结构.在图7、8中：\nHbH＝Hop-by-Hop逐跳选项头部；\nRH＝路由头部；\nD0＝目的选项头部。\n在IETF组织HIP工作组最新公布了使用标准HIP协议来完成移动性和多家乡功能的一篇个人草案[2]，通过将HI到IP地址的映射从静态的一对一扩展到动态的一对多映射来完成端主机移动和多家乡，允许HIP主机更新与对端相关的地址集。地址更新由新的HIP参数REA类型实现。以下是这种方案的具体内容：\n新定义的HIP REA参数，它允许主机交换关于IP地址和地址改变的信息。由REA建立的逻辑结构包含三级：主机，由安全参数索引(Security Paramet-ers Index，SPI)索引的IPSec SA，和地址。他们之间的关系如图9所示。\n在图9中，主机1和主机2协商两个单向IPSec SA，而且每个主机为入站SA选择SPI值。地址1a和地址2a是每个主机在基本HIP交换中使用的源地址。这些地址是每个SA向对端传递的首选地址(唯一的)；无论数据发送到主机的哪一个接口都能到达入站SPI，当主机通过出站SPI向对端发送数据时，它只知道与出站SPI相关的一个目的地址(对主机1，它通过SPI2a向地址2a发送数据，到达主机2)，除非通过其它的机制学习新的地址。当主机有多个地址和SPI时，对端主机必须决定使用哪一个作为目的地址。可能主机希望在一个特殊的入站接口接收数据。HIP允许指定一个特殊的地址作为首选地址，并且通知给对端。\n主机可以绑定多个进入或者外出SPI，此外，每个SPI有多个与它相关的地址。这些绑定到一个SPI的地址不是作为IPSec流量选择器使用的。而是提供给对端的地址，提示对端在那个SPI上用哪个地址到达主机。而REA参数用来改变对端与特定SPI相关的地址集。主机可以与一个对端建立任意数量的SA(或SPI)用来将相关的地址分组。比如，如果主机需要改变在一个SPI上的地址，那么和这个地址相关的地址都会同时作废。\n一个单独的REA参数只包含关于一个SPI的参数。为了同时表示几个SPI的改变，需要发送几个REA参数。数据包的结构支持这以点。如果REA参数在UPDATE报文中发送，那么接收端会响应一个UPDATE确认。如果REA参数在NOTIFY，I2或R2报文中发送，接收端可以将REA看作是状态通知，并且只须在需要激活新地址时作出反映。\n端主机的地址都可以用以下几种状态来表示：用来追踪地址的可达性：\n(1)UNVERIFIED：表示地址的可达性还没有经过证实。\n(2)ACTIVE：表示地址的可达性已经经过证实并且地址还没有过期。\n(3)DEPRECATED：表示地址的生存期已过。\n图10为个人建议草案中新定义的REA消息格式，其中：\n类型：目前还没有定义；\n长度：以字节为单位，包含类型和长度域；\nSPI：与地址相对应的SPI。\nSPI域标识了这个参数要应用的SPI.发送主机可以随意引入新的SPI.也就是说，如果接收的REA有新的SPI，它意味着所有指定给旧SPI的地址仍然工作，同时新接收的REA中的新地址是与新SPI相关联的.另一方面，如果接收的REA中有一个接收端已经知道的SPI，应该用新地址取代所有与这个SPI相关的地址.\nP：首选地址。如果REA中的第一个地址是新的首选地址，则置1；否则置0。\n保留：发送置1，接收忽略。\n地址生存时间：以秒为单位。\n地址：IPv6地址或IPv4-in-IPv6格式的IPv4地址。\n一、具体发送REA的过程\n发起端主机在发现IP地址改变时就发送REA(这里假设改变至少持续几秒钟的时间)并决定怎样组织不同的地址，以及是否将地址包含在多个SPI中。通常情况下，简单的基于实际物理和逻辑接口的分组是最好的组织策略。虚拟接口，如IPSec隧道接口或移动IP家乡地址，不应该被通告。此外，发起端应该避免快速发送相矛盾的REA。\n一旦主机决定了分组和SPI地址的分配，它为每个分组建立一个REA参数。如果有多个REA参数，这些参数应该进行排序，使得新的首选地址在第一个REA参数中。在REA参数中只有一个地址(第一个地址)可以被指定为首选地址。当地址被加入到现存的SPI中，REA参数会指出现存的SPI和一个或多个要加入SPI的地址。\n二、接收REA的处理\n主机可以在任何的HIP报文中接收REA参数，包括I1。当主机接收到一个REA参数，它首先执行以下操作：\n(1)主机检查列出的SPI是否是新的。如果是新的，就建立一个没有地址的SPI。如果是一个已有的，就准备向存在的SPI中加入地址。\n(2)对REA参数中列出的每个地址，检查地址是合法的单播或任意播地址。\n(3)对REA参数中列出的每个地址，检查地址是否已经绑定到SPI上。如果地址已经绑定，更新地址的生存期。如果地址的状态是DEPRECATED，状态转变为UNVERIFIED。如果地址没有绑定，将地址加入并且状态设置为UNVERIFIED。\n(4)如果REA与NES参数配对，NES参数要被处理。如果REA取代现存SPI的地址，要在NES参数指出，在它的旧SPI域包含现存的SPI，在新SPI域包含新的SPI，而且REA参数的SPI域要匹配NES的新SPI域。如果根据新SPI替换REA，NES的旧SPI域和新SPI域要包含相同的SPI。\n一旦主要更新了SPI，如果REA参数包含新的首选地址，主机应该开始改变首选地址。这通常要求主机首先证明地址的可达性，而且之后改变首选地址。\n相关技术一就这样通过将HI到IP地址的映射从静态的一对一扩展到动态的一对多映射来完成了端主机移动和多家乡，允许HIP主机更新与对端相关的地址集，并由新的HIP参数REA类型实现地址更新。\n现有技术二的缺点、现有技术HIP是基于公钥做为端主机名称的，身份认证是很容易解决的问题。但是现在定义的“基本交换”的安全性功能还比较单一，灵活性也不是很好，只能认为它是一个“轻量级的IKE交换协议”[13]，需要一个更好的密钥交换协议以及扩展提供更多的颗粒度和在一对HITs之间创造几个ESP SAs。此外，现有的HIP协议只是简单的提出用IPSec ESP来保护通信内容，对如何生成SA定义的不够明确和有效。\n此外，这种技术适用的具体环境也存在一定的限制：只能适用于端到端两个主机之间采用ESP传输模式的情况，对隧道模式和认证头部(AH)协议的支持没有(虽然这并不一定是必须的)；对站点多家乡(主机可能有一个具有多个全球IP地址的接口。这种情况可能是由于存在多个高层ISP的站点，或是因为站点为所有主机同时提供IPv4和IPv6地址等)，以及移动性和多家乡结合的情况没有考虑和相应的支持[12]。\n发明内容\n本发明的目的在于，提供一种实现主机移动性和多家乡功能的密钥交换协议方法。以通过对原有HIP协议的改进，来使通信节点对等体地址改变时保证HIP交换发起者和响应者之间端到端通信的安全性：为IP数据报提供机密性、数据完整性、接入控制、身份鉴别和数据源认证，防止在HIP协议中出现拒绝服务(DoS)或者中间人(MitM)等攻击。\n本发明可以在主机(或者安全网关)具有移动性、多家乡功能，以及同时多家乡及移动情况下维持原有IPSec SA不变，从而对数据进行保护；并支持一个同时有多个正在通信的通信协议连接的安全网关在地址之间切换即支持站点多家乡，而不用中断和重新建立高层协议连接。\n采用本发明，在原先只有端到端的HIP通信扩展后可以实现更多如同安全网关保护的内部子网主机通信等应用。并支持一般移动性、主机多家乡、站点多家乡、双主机多家乡、网络重编号、多家乡和移动性的结合等具体场景。\n本发明的技术方案为：\n一种实现主机移动性和多家乡功能的互联网密钥交换协议方法，采用主机身份协议(HIP)时，在传输层和网络层之间加入一个主机身份协议层，为每台HIP主机设置至少一个主机身份以及与该主机身份相应的主机标识符，将每台主机的传输层关联绑定到相应的主机标识符上；\n使HIP主机至少知道其通信对端的一个可达的IP地址；所述的IP地址为HIP交换中最初使用的IP地址；\n在所述HIP主机及其通信对端之间通过HIP交换建立互联网协议安全联盟；\n将所述的互联网协议安全联盟(IPsec SA)绑定到所述HIP主机的主机标识符(HI)上，使所述的HIP主机能够从任何地址接收受由HIP建立的封装安全载荷(ESP)安全联盟(SA)保护的数据包；所述的HIP主机也能够改变自己的IP地址并且继续向通信对端发送数据包。\n在建立互联网协议安全联盟之前，在通信对端之间进行相互认证，并建立一个包含共享机密信息的互联网密钥交换协议(IKE)联盟(SA)，在所述的互联网密钥交换协议联盟中包含秘密信息和一系列加密算法；其中，发起者采用混合/匹配方式，在所列出的可以支持的算法中建议一个或多个算法套件。\n在通信中对封装安全载荷(ESP)和认证头部(AH)联盟(SA)使用IP压缩(IPCOMP)技术。\n在交换过程中，每一组交换均由一对报文组成，所述的一对报文包括请求和应答；其中：在一定的时间间隔内如果请求方没有收到应答方的应答，则请求方需重传请求或放弃连接。\n在交换过程中完成的交换包括：\nIKE_SA_INIT交换，协商包括加密算法、Nonces、DH交换在内的值；\nIKE_AUTH交换，认证前面的消息、交换身份和证书并建立第一个互联网协议安全联盟(IPSec SA)。\n在交换过程中完成的交换还包括：CREATE_IPSEC_SA交换，用来建立以后的互联网协议安全联盟(IPSec SA)。\n在交换过程中完成的交换还包括：INFORMATIONAL交换，用来删除联盟(SA)报告错误条件，并可以执行检查生存期等其他管理步骤。\n在交换过程中交换的顺序为：首先进行所述的IKE_SA_INIT交换，然后进行所述的IKE_AUTH交换；接下来使用的任意数量的CREATE_IPSEC_SA和INFORMATIONAL交换，它们的顺序为任意。\n通过一次所述的IKE_SA_INIT交换和一次所述的IKE_AUTH交换完成初始交换，从而建立互联网密钥交换协议联盟(IKE SA)和第一个互联网协议安全联盟(IPSec SA)。\n所述的IKE_SA_INIT交换包括：\n请求报文：HDR，SAi1，KEi，Ni；\n应答报文：HDR，SAr1，KEr，Nr；\n所述的IKE_AUTH交换包括：\n请求报文：HDR，SK{IDi，[IDr，]AUTH，SAi2，TSi，TSr}；\n应答报文：HDR，SK{IDr，AUTH，SAr2，TSi，TSr}。\n所述的HDR是每个交换消息的头部，其包括SPI、版本号以及各种类型的标志；所述的SAi1载荷规定了请求方为建立互联网密钥交换协议联盟(IKE_SA)所支持的加密算法，应答方从请求方提供的选项中选择一套加密算法并且在SAr1载荷中表示出来；所述的KEi载荷传送请求方的Diffie-Hellman值，通过应答方KEr载荷完成Diffie-Hellman交换；所述的Ni和Nr载荷分别表示请求方和应答方的Nonce(一般填写当前时间)；请求方在IDi载荷中声称自己的身份，使用AUTH载荷证明对IDi相关秘密信息的认识并保护第一个报文内容的完整性；可选的IDr载荷使请求方能够指定与之通信的应答方众多身份中的一个，应答方使用SAi2载荷开始协商互联网协议安全联盟(IPSec SA)；应答方在IDr载荷中声称自己的身份，用AUTH载荷认证其身份并保护第二个报文的完整性，并完成互联网协议安全联盟(IPSec SA)的协商。\n在初始交换的协商中每一端都会生成密钥种子(SKEYSEED)，并从中生成互联网密钥交换协议联盟(IKE SA)的所有密钥；接下来的所有报文，除了头部全部被加密并受到完整性保护，且用来加密和进行完整性保护的所有密钥都来自于所述的密钥种子。\n所述的密钥包括：SK_e，即完成加密；SK_a，即完成认证；和SK_d，以用来产生后面互联网协议安全联盟(IPSec SA)阶段需要的加密材料；所述SK_e和SK_a为单向计算；采用DH值生成保护互联网密钥交换协议联盟(IKESA)的密钥SK_e和SK_a。\n所述的IKE_AUTH交换中的报文接收者必须验证所有签名和MAC的计算是否正确，以及ID载荷中的名称与产生AUTH载荷的密钥是否相符合。\n所述的CREATE_IPSEC_SA交换只包含一对独立的请求/响应信息，即：\n请求方报文：HDR，SK{[N]，SA，Ni，[KEi]，[TSi，TSr]}；\n应答方报文：HDR，SK{SA，Nr，[KEr]，[TSi，TSr]}；其中：\n请求方在SA载荷中发送SA提议，在Ni载荷中发送Nonce，在KEi载荷中选择地发送Diffie-Hellman值，在TSi和TSr载荷中选择地发送提议的流量选择器；如果SA提议中包含不同的Diffie-Hellman组，KEi必须是发起方希望响应方接受的组中的一个元素；如果猜测错误(既响应方不接受发起方推荐的KEi)，则CREATE_IPSEC_SA交换失败，并不得不尝试一个新的KEi；头部之后的报文是加密的，报文(包含头部)使用为IKE SA协商的加密算法进行完整性保护；应答方使用相同的消息ID来响应，并在SA载荷中答复接受的SA提议，并在KEr载荷中答复Diffie-Hellman值(如果请求中包含了KEi并且所选择的加密组件中包含请求中的DH组)；如果响应方选择不同组的加密组件它必须拒绝请求，请求方重传请求，并且在请求中要包含应答方所选择组中的KEi载荷。\n所述的INFORMATIONAL交换只能在起始交换之后发生，并且用协商的密钥加密保护；所述的INFORMATIONAL交换中的报文包含0个或多个通告，删除，和配置载荷；所述的INFORMATIONAL交换请求的接收端必须发出响应(否则发送者会认为报文在网络中丢失并且重发报文)。\n响应是没有载荷的报文；INFORMATIONAL交换的请求报文也可以不包括任何载荷。\n定义一种新的类型用来完成HIP主机交换关于IP地址和地址改变信息的功能：HIP_NOTIFY_REA；当移动主机从一个IP地址切换到另一个IP地址时，会与对端断开连接一段很短的时间；一得到新IP地址，移动主机就通过所述的INFORMATIONAL交换向对端发送HIP_NOTIFY_REA参数并指出以下问题：新IP地址，与新IP地址相关的SPI，地址生存时间，和新地址是否为首选地址。\n所述的主机(移动或静止的)具有多于一个的接口，该主机通过HIP_NOTIFY_REA参数通知对端主机附属的接口；主机需为每个用来从对端主机接收数据的接口使用不同的SA；当提供给对端主机多于一个的地址，主机需指出首选地址；当处理建立新SA的入站HIP_NOTIFY_REA时，主机使用包含HIP_NOTIFY_REA的通告的目的地址作为HIP_NOTIFY_REA加NES指向的本地地址；主机可以使用相同的IP地址向不同的对端地址发送HIP_NOTIFY_REA，这会同时建立有不同源地址的多个入站SA。\n所述的主机包含一个具有多个全球IP地址的接口；该主机通过HIP_NOTIFY_REA参数通知对端主机附属的接口；主机需为每个用来从对端主机接收数据的接口使用不同的SA；当提供给对端主机多于一个的地址，主机需指出首选地址；当处理建立新SA的入站HIP_NOTIFY_REA时，主机使用包含HIP_NOTIFY_REA的通告的目的地址作为HIP_NOTIFY_REA加NES指向的本地地址；主机可以使用相同的IP地址向不同的对端地址发送HIP_NOTIFY_REA，这会同时建立有不同源地址的多个入站SA。\n此外，当主机本身有多个接口时，单个接口也可能成为站点多家乡。\n当交换完成之后两个主机同时需要添加额外的地址，其中：\n主机1添加地址1b，并向位于地址2a的另一主机发送HIP_NOTIFY_REA，而且两个主机之间会加入一组新的SPI；\n主机2添加地址2b，主机2选择向主机1的地址1a、地址1b、或地址1a和地址1b两者同时发送HIP_NOTIFY_REA；\n如果选择向两个地址同时发送，那么两个主机之间会存在一个完整的SA网络(4对SA)。\n所述主机可同时具有移动性和多家乡，也就是说有多个移动接口；\n此外，如果接口使用不同的接入技术，则一个接口是稳定的(保持当前的地址)而其它的接口是移动的(IP地址的改变)；HIP_NOTIFY_REA加CREATE_IPSEC_SA足够灵活能够处理这样的场景。\n所述的主机包括：安全网关。\n本发明针对原有HIP协议规程设计了一种高效、灵活、可靠的改进IKEv2密钥交换协议——IKE-H，来使通信节点对等体地址改变时保证HIP交换发起者和响应者之间端到端通信的安全性：为IP数据报提供机密性、数据完整性、接入控制、身份鉴别和数据源认证，防止在HIP协议中出现DoS(拒绝服务)或者MitM(中间人)等攻击。\n本发明提供了一种可以在主机(或者安全网关)具有移动性、多家乡功能，以及同时多家乡及移动情况下提供维持原有IPSec SA不变来保护数据功能的方法。并支持一个同时有多个正在通信的IPv4/IPv6连接的安全网关在IPv4和IPv6地址之间切换即支持站点多家乡，而不用中断和重新建立高层协议连接。\n此外，采用本发明，在原先只有端到端的HIP通信扩展后可以实现更多如同安全网关保护的内部子网主机通信等应用。并支持一般移动性、主机多家乡、站点多家乡、双主机多家乡、网络重编号以及多家乡和移动性的结合等具体场景。\n附图说明\n图1是现有技术基本的移动IPv6组成示意图；\n图2是现有技术的返回可路由测试基本过程示意图；\n图3是现有技术中双向隧道通信模式示意图；\n图4是现有技术中路由最佳化通信模式示意图；\n图5是不同的绑定示意图；\n图6是HIP协议定义的基本交换过程示意图；\n图7是现有的使用ESP的报文的结构图；\n图8是现有的考虑HIP的新的报文的结构图；\n图9是主机、由SPI索引的IPSec SA、及地址之间的关系示意图；\n图10是REA消息格式；\n图11是本发明的初始交换过程示意图；\n图12是本发明的CREAT_IPSEC_SA交换过程示意图；\n图13是本发明的交换信息的头部格式；\n图14是本发明的SA载荷格式；\n图15是本发明的提议载荷格式；\n图16是本发明的转换载荷格式；\n图17是本发明的KE载荷格式；\n图18是本发明的AUTH载荷格式；\n图19是本发明的Nonce载荷格式；\n图20是本发明的ID载荷格式；\n图21是本发明的ID INFORMATION交换过程示意图；\n图22是本发明的通告载荷格式；\n图23是本发明的HIP_NOTIFY_REA通告数据格式；\n图24是本发明的双主机多家乡情况下各端使用HIP_NOTIFY_REA增加第二个地址时的主机、由SPI索引的IPSec SA、及地址之间的关系示意图。\n具体实施方式\n本发明提供了一种可以在主机(或者安全网关)具有移动性、多家乡功能，以及同时多家乡及移动情况下提供维持原有IPSec SA不变来保护数据功能的方法——IKE-H。并在原有HIP协议引入HI主机标示符解决终端识别问题的基础上，本发明支持一个同时有多个正在通信的IPv4/IPv6连接的安全网关在IPv4和IPv6地址之间切换即支持站点多家乡，而不用中断和重新建立高层协议连接。\n本发明针对原有HIP协议规程设计了一种高效、灵活、可靠的改进IKEv2密钥交换协议——IKE-H，来使通信节点对等体地址改变时保证HIP交换发起者和响应者之间端到端通信的安全性：为IP数据报提供机密性、数据完整性、接入控制、身份鉴别和数据源认证，防止在HIP协议中出现DoS(拒绝服务)或者MitM(中间人)等攻击。此外，采用本发明，在原先只有端到端的HIP通信扩展后可以实现更多如同安全网关保护的内部子网主机通信等应用。\n本发明是建立在本专利书第一部分提到的HIP协议，它的基本机制是在传输层和网络层之间加入了一个HI层，将传输层通过主机身份标记HIT或者本地范围标识LST绑定到标示主机身份的主机标识符HI上。它与传统的其他IP协议主要不同在于使Socket套接口不再和IP地址结合，这样就可以为我们解决一般情况的地址变化问题带来便利。其他基本协议规定这里我们不再重述，读者可参阅第一部分相关技术HIP部分。下面介绍本发明的具体技术方案以及几个使用情况：\n一、IKE-H方法基本概述\n本发明提议的IKE-H密钥交换交换方法可在HIP主机(或者安全网关)之间建立一对IPSec SA。这些SA不是绑定到IP地址，而是绑定到用来建立它们的HI(公共密钥)上。当然，主机(或者安全网关)至少需要知道它们对端的一个可达的IP地址。最初，这些IP地址就是HIP交换中使用的IP地址。既然SA不是绑定到IP地址的，主机就能够从任何地址接收受(由HIP建立的)ESPSA保护的数据包。因此，主机可以改变自己的IP地址并且继续向对端发送数据包。\n本发明提议的IKE-H方法的密钥交换过程可以同IETF组织的IKEv2密钥交换协议兼容，一些相同的协议细节和更多的说明可以参阅有关草案文档[14]。\n二、用IKE-H方法建立IPSec SA过程\nIKE-H密钥交换协议在通信对端之间进行相互认证并建立一个包含共享机密信息的IKE SA，IKE SA中包含秘密信息和一系列加密算法。发起者采用混合/匹配方式，在所列出的可以支持的算法中建议一个或多个算法套件。IKE-H还可以在通信中对ESP和AH SA协商使用IP压缩(IPCOMP)技术。在这里，通过IKE SA建立的ESP SA和AH SA被称为“IPSec SA”。\nIKE-H的交换过程都是由一对报文组成：请求和应答，这对报文称为一组“交换”。在一定的时间间隔内如果没有收到应答，请求方需要重传请求(或放弃连接)。第一组交换完成IKE_SA_INIT，协商包括加密算法、Nonces、DH交换在内的值。第二组交换完成IKE_AUTH，认证前面的消息、交换身份和证书并建立第一个IPSec SA。接下来的交换是CREATE_IPSEC_SA交换(用来建立以后的IPSec SA，它不是一定要进行)或者INFORMATIONAL交换(用来删除SA报告错误条件并可以做其他管理如检查生存期等)。\n如图11所示，通常情况下，建立IKE SA和第一个IPSec SA只需要一次IKE_SA_INIT交换和一次IKE_AUTH交换(一共四条报文)，我们称为初始交换。但在特殊情况中，可能需要不止一次的这两种交换。但是不管任何情况中，几种交换的顺序都是：首先IKE_SA_INIT交换，它结束之后是IKE_AUTH交换，接下来使用的任意数量的CREATE_IPSEC_SA和INFORMATIONAL交换，它们的顺序可以任意。\nHDR是每个IKE-H交换消息的头部，包括SPI、版本号以及各种类型的标志。SAi1载荷规定了发起方为建立IKE_SA所支持的加密算法，响应方从发起方提供的选项中选择一套加密算法并且在SAr1载荷中表示出来。KEi载荷传送发起方的Diffie-Hellman值，通过响应方KEr载荷完成Diffie-Hellman交换。Ni和Nr载荷分别表示发起方和响应方的Nonce(一般填写当前时间)。\n此外在初始交换的协商中每一端都会生成密钥种子(SKEYSEED)，并从中生成IKE SA的所有密钥。接下来的所有报文全部(除了头部)都会被加密并受到完整性保护。用来加密和进行完整性保护的所有密钥都来自于密钥种子，它们被称为SK_e(完成加密)和SK_a(完成认证，又名完整性保护)。SK_e和SK_a是单向计算的。使用DH值除了生成保护IKE SA的密钥SK_e和SK_a之外，还生成了其他密钥SK_d(用来产生后面IPSec SA阶段需要的加密材料)。SK{...}表明括号中的这些载荷是使用本方向的SK_e和SK_a进行加密和完整性保护的。\nSKEYEED及其派生值由以下方式计算：\nSKEYSEED＝prf(Ni|Nr，g^ir)\n{SK_d|SK_ai|SK_ar|SK_ei|SK_er|SK_pi|SK_pr}＝\n                  prf+(SKEYSEED，Ni|Nr|SPIi|SPIr)\nprf+用来产生伪随机数，prf+()的结果构成SK_d，SK_ai，SK_ar，SK_ei，SK_er，SK_pi和SK_pr值的串联。g^ir是来自D-H交换的共享密钥材料。g^ir如果需要将其长度与模一致，可用0填充。如果协商过的prf需要固定长度的密钥并且Ni和Nr与这个长度都不相等，则需要取它们最初的比特(一半来自Ni一半来自Nr)。\n发起方在IDi载荷中声称自己的身份，使用AUTH载荷证明对IDi相关秘密信息的认识并保护第一个报文内容的完整性。可选的IDr载荷使发起方能够指定她想与之通信的响应方众多身份中的一个。这对响应方在同一个IP地址上具有多个主机身份的情况下很有用。响应方使用SAi2载荷开始协商IPSec SA。\n响应方在IDr载荷中声称自己的身份，用AUTH载荷认证他的身份并保护第二个报文的完整性，并完成IPSec SA的协商。\n第3、4条报文的接收者必须验证所有签名和MAC的计算是否正确，以及ID载荷中的名称与产生AUTH载荷的密钥是否相符合.\n此时，已经完成了初始交换并建立IKE SA和第一对IPSec SA。接下来的交换是CREATE_IPSEC_SA交换，用来建立以后的IPSec SA或者INFORMATIONAL交换，用来删除SA报告错误条件并可以做其它管理。其中，有关INFORMATIONAL交换来完成移动性和多家乡的方案设计将在第四部分介绍。\nCREATE_IPSEC_SA交换只包含一对独立的请求/响应信息，相当于IKEv1的阶段2交换。在初始交换完成后，它可以由IKE SA的任意一端发起。初始交换之后的所有报文都受到加密保护，这里采用的是在IKE-H交换头两个报文中协商的加密算法和密钥。IPSec SA是通过发送CREATE_IPSEC_SA请求来创建的。为确保IPSec SA具有更强的向前加密保证，CREATE_IPSEC_SA请求可以选择性地包含KE载荷，来进行额外的Diffie-Hellman交换。IPSec SA的密钥材料是SK_d。在初始交换建立的部分IPSec SA中，不能发送第二个KE载荷和Nonce。初始交换中的Nonce被用来计算IPSec SA的密钥。\n如图12所示，发起方在SA载荷中发送SA提议，在Ni载荷中发送Nonce，在KEi载荷中可选地发送Diffie-Hellman值，在TSi和TSr载荷中可选地发送提议的流量选择器。如果SA提议中包含不同的Diffie-Hellman组，KEi必须是发起方希望响应方接受的组中的一个元素。如果猜测错误(既响应方不接受发起方推荐的KEi)，就意味着CREATE_IPSEC_SA交换失败并不得不尝试一个新的KEi。头部之后的报文是加密的，报文(包含头部)使用为IKE SA协商的加密算法进行完整性保护。\n响应方使用相同的消息ID来响应，并在SA载荷中答复接受的SA提议，并在KEr载荷中答复Diffie-Hellman值(如果请求中包含了KEi并且所选择的加密组件中包含请求中的DH组)。如果响应方选择不同组的加密组件它必须拒绝请求，发起方应该重传请求，并且在请求中要包含响应方所选择组中的KEi载荷。\n三、IKE-H载荷格式定义\n1、IKE-H头部载荷\nHDR是每个IKE-H交换消息的头部，它的载荷格式如图13所示。\n发起端SPI(8字节)：由起始端选择，标识一个唯一的SA。该值一定不能为0。\n响应端SPI(8字节)：由响应端选择，标识一个唯一的SA。在IKE-H起始交换的第一个报文中这个值必须为0，在其它报文中一定不能为0。\n下一个载荷(1字节)：指出紧接着头部的载荷的类型。\n主版本(4比特)：指出正在使用的IKE协议的主版本。这里的实现必须将主版本设置成2。基于IKEv1和ISAKMP的实现必须将主版本设置成1。\n副版本(4比特)：指出正在使用的IKE协议的副版本。这里的IKE实现可以将副版本设置成1。\n交换类型(1字节)：指出正在使用的交换的类型。这限制了报文中的载荷和交换中的报文顺序。\n交换类型                定义值\n保留                    0-33\nIKE_SA_INIT             34\nIKE_AUTH                35\nCREATE_IPSEC_SA         36\nINFORMATIONAL           37\n保留                    38-239\n为扩展保留              240-255\n标记(1字节)：指出报文设置的详细选项。选项的存在由设置标志域中对应的比特来指出。\nX(保留)(比特0-2)-这些比特必须在发送时清0，接收时忽略。\nI(起始端)(比特3)-该位在IKE SA的最初起始端发送的报文中必须置1，在最初响应端必须清0。接收端用它来判断哪8个字节的SPI是由接收端生成的。\nV(版本)(比特4)-这个比特指出，发送者能够处理比在主版本域中声明的更高的协议版本。这里的实现必须在发送时将这个比特清0，接收时忽略。\nR(响应)(比特5)-这个比特指出，该报文是响应包含同样ID的报文。这个比特必须在所有的请求报文中清0，在所有的响应报文中置1。IKE端点不能对标志位响应的报文作出响应。\nX(保留)(比特6-7)-这些比特必须在发送时清0，接收时忽略。\n消息ID(4字节)-消息ID用来控制丢失包的重传和请求与响应的匹配。它是协议安全的基础，因为它用来阻止报文的重播攻击。见2.1和2.2节。\n长度(4字节)-报文的总长度(头部+所有载荷)，以字节为单位。\n2 SA载荷\n安全联盟载荷，简称SA，用于协商SA的参数，它的载荷类型是33。一个SA载荷可以有多个提议载荷。如果有多个SA载荷，它们必须按照需要程度排序。一个提议载荷可能包含多个IPSec协议(这里指IKE，ESP或AH)，每个协议可能包括多个属性。这样就形成了提议载荷，转换载荷和属性的相互嵌套。这样SA的总载荷长度包括了SA载荷，提议载荷，转换载荷和属性信息的组合。提议载荷的长度包括了它所包含的所有转换载荷和属性的长度。转换载荷的长度包括了它所包含的所有属性的长度。这样的结构和IKEv1以及IKEv2协议都是保持一样的。图14SA载荷格式。\n如图15所示，提议载荷结构包括提议数目和IPSec协议ID。每个结构一定要与前一个相同或比前一个大1。如果两个连续的结构有相同的提议数，它意味着一个提议由这两个结构组成。\n0或者2(1字节)-说明这是否是SA的最后一个提议载荷。值0为最后一个。\n保留(1字节)-发送端清0；接收端忽略。\n提议长度(2字节)-提议的长度，包括接下来的所有转换和属性。\n提议数(1字节)-SA的第一个提议必须是数1，接下来的提议或者与前一个相同(意味着两个建议的与)或者比前一个大1(意味着两个提议的或)。\n协议ID(1字节)-当前协商的IPSec协议标识符。定义值如下：\n协议                协议ID\n保留                0\nIKE                 1\nAH                  2\nESP                 3\n为IANA保留          4-200\n私有使用            201-255\nSPI大小(1字节)-对起始的IKE SA协商，这个值必须为0；SPI从外部头得到。在接下来的协商中，它与对应协议的SPI大小相等(IKE是8字节，ESP和AH是4字节)。\n转换数(1字节)-这个提议中的转换数。\nSPI(变长)-发送实体的SPI。当SPI大小域是0时，这个域不在SA载荷中出现。\n转换(变长)-一个或多个转换结构。\n如图16所示，每个提议结构后跟着一个或多个转换结构。不同的转换数是由协议决定的。AH同常有一个转换：一个完整性检验算法。ESP通常有两个：一个加密算法和一个完整性检验算法。IKE通常有四个转换：一个Diffie-Hellman组，一个完整性检验算法，一个prf算法和一个加密算法。如果提议了一个加密和完整性保护的组合算法，它必须作为加密算法提议而不能提议完整性保护算法。对每个协议，允许的转换集合是由转换ID数分配的，它出现在转换的头部。\n0或者3(1字节)-说明这是否是建议的最后一个转换子结构。值0表示最后一个。\n保留(1字节)-发送端清0；接收端忽略。\n转换长度-转换子结构的长度，包括头部和属性，以字节为单位。\n转换类型(1字节)-说明的转换的类型。不同的协议支持不同的转换类型。对有些协议，一些转换是可选的。如果转换是可选的，而且起始者希望建议忽略那个转换，建议中就不要包含那个转换的类型。如果发起端希望响应端使用那个转换选项，就要包含一个转换ID＝0的转换子结构。\n              转换类型         使用场所\n加密算法      1                (IKE and ESP)\n伪随机功能            2        (IKE)\n完整性检查算法        3        (IKE，AH，在ESP可选)\nDiffie-Hellman组      4        (IKE，并在AH和ESP可选)\n扩展序列号            5        (在AH和ESP可选)\n为IANA保留            6-240\n私有使用              241-255\n转换ID(2字节)-被建议的转换类型的ID。\n如果多个转换有相同的转换类型，建议是这些转换的或关系。如果有多个不同类型的转换，提议是这些不同组的与关系。比如，如果提议(3DES或IDEA)和(HMAC_MD5或HMAC_SHA)的ESP，ESP提议应该包含两个转换类型1的候选(一个是3DES，另一个是IDEA)和两个转换类型2的候选(一个是HMAC_MD5，另一个是HMAC_SHA)。这实际上提议了四种算法的组合。如果发起者只想要提议那些的一个子集-比如(3DES和HMAC_MD5)或(IDEA或HMAC_SHA)，就不能把它作为一个提议中的多个转换来编码，发起者要构造两个不同的提议，每个有两个转换。\n给定的转换可以有一个或多个属性。转换说明算法，属性说明密钥大小。大多数的转换都没有属性。一个转换不能有相同类型的多个属性，每个转换一个属性。\n3KE载荷\n密钥交换载荷，简称KE，作为Diffie-Hellman交换的一部分用于交换Diffie-Hellman公共数字。密钥交换载荷由IKE通用头部和Diffie-Hellman公共值本身组成。KE密钥交换载荷格式如图17所示。\n密钥交换载荷是由复制Diffie-Hellman公共值到载荷的“密钥交换数据”域构成的。\nDiffie-Hellman公共值的长度必须与执行求幂运算的数模长度相同，如果需要可以在前面填0。\nDH组数标识了密钥交换数据计算所在的Diffie-Hellman组。\n密钥交换载荷的载荷类型是34。\n4认证载荷\n认证载荷，简称AUTH，包含用于认证目的的数据。认证数据的语法根据认证算法而不同。\n认证载荷的载荷类型是39。认证载荷定义如图18所示。\n认证算法(1字节)-定义了认证算法。值如下：\nRSA数字签名(1)-使用在PKCS#1填充散列上的RSA私有密钥。\n共享密钥消息(2)-使用与ID载荷的身份和协商的prf函数相关的共享密钥。\nDSS数字签名(3)-使用SHA-1散列上的DSS私有密钥。值0和4-200保留给IANA。值201-255用于私有使用。\n认证数据(变长)。\n5、Nonce载荷\nNonce载荷，起始端和响应端分别简称为Ni和Nr，包含随机数，分别表示发起方和响应方的nonce(一般填写当前时间)，用于在交换中保证存在性和抗重播攻击。Nonce载荷的载荷类型是40。它的载荷定义如图19所示。\nNonce数据(变长)-由传输实体产生的随机数，它的大小必须在16和256字节之间。Nonce值不能重复使用。\n以上这几种载荷的格式和IPSec工作组的IKEv2协议载荷格式相同[14]，不需要做过多的改变。但是由于加入了HIP的机制所以需要在身份认证的载荷中进行相应的扩展。由于在IKE_AUTH阶段，IDi和IDr身份载荷分别声明发起者和响应者的身份。现有的ID载荷定义如图20所示。\nID类型(1字节)-说明要使用的身份的类型。\n保留-发送端清0；接收端忽略。\n身份数据(变长)-由ID类型指出的值。“身份数据”域的长度从ID载荷头中计算。\nID类型         值       含义\n----------     ------   --------------------\n保留           0\nID_IPV4_ADDR   1        表示4字节的IPv4地址。\nID_FQDN        2        表示完全合格的域名字符串。\nID_RFC822_ADDR 3        表示完全合格的RFC822email地址字符串。\nID_IPV6_ADDR   5        表示16字节的IPv6地址。\nID_DER_ASN1_DN 9        表示二进制DER编码的[X.501]。\nID_DER_ASN1_GN 10       表示二进制DER编码的[X.509]。\nID_KEY_ID     11        表示不透明的字节流。\n为IANA保留    12-200\n私有使用保留  201-255   可用于我们扩展使用。\n我们可以在身份载荷中定义一个新的ID类型ID_HIT来标示HI，暂时定义它的值为202，然后在“身份数据”中放置HIT的具体值。这样的处理就可以使IKEv2中加入HI这种身份表示方法，并且它可以满足正常IKEv2身份验证的一致性和可扩展性：\n在图11“IKE-H起始交换”中起始端在IDi载荷中用HITi声称自己的身份，用AUTH载荷证明对与IDi的相关的秘密信息的认识和保护第一个报文的完整性。响应端在IDr载荷中用HITr声称自己的身份，用AUTH载荷认证他的身份和保护第二个报文的完整性，用附加的域完成IPSEC_SA的协商。\n四、IKE-H实现移动性和多家乡方案\n这部分文档详细说明了如何使用IKE-H的INFORMATION交换完成保持多IP地址同时通信以及不同的IP地址切换时的通信。换句话说，扩展对多家乡，移动，和同时的多家乡及移动等情况提供了支持。此外，完成多家乡和移动引起IP版本变化(IPv4与IPv6)时的扩展，并继续保持通信流量，而不用中断和重新建立高层协议连接。\n为了使IKE SA的对端可能希望传输一些关于错误或事件通知的控制信息，所以在IKEv2协议[14]定义了INFORMATIONAL交换。INFORMATIONAL交换只能在起始交换之后发生，并且用协商的密钥加密保护。INFORMATIONAL交换中的报文包含0个或多个通告，删除，和配置载荷。INFORMATIONAL交换请求的接收端必须发出响应(否则发送者会认为报文在网络中丢失并且重发报文)。响应可以是没有载荷的报文。INFORMATIONAL交换的请求报文也可以不包括任何载荷。通过这种方法，一个端点可以让另一个端点证明它还可用。\nINFORMATIONAL交换的基本定义如图21所示。\nINFORMATIONAL交换的处理由它的组成载荷决定。\n我们这里利用用通告载荷和配置载荷来完成移动性和多家乡的功能。\n通报载荷，简称N，用于在对端之间传输信息数据，像差错情况和状态传输。通报载荷可以出现在响应报文中(通常用来说明请求被拒绝的原因)，在INFORMATIONAL交换中(报告不是IKE请求的差错)，或在其它任意报文中(指出发送端的能力或修改请求的含义)。通告载荷的载荷类型是41。\n通报载荷的定义如图22所示。\n协议ID(1字节)-如果这个通告是关于一个现存的SA，这个域指出那个SA的类型。对IKE_SA通告，这个域是1。对于IPSec SA的通告，这个域是2(代表AH)或3(代表ESP)。对与现存SA无关的通告，这个域必须设置为0，必须在接收端忽略。这个域的其它值保留由IANA将来分配。\nSPI大小(1字节)-由IPSec协议ID定义的SPI长度或是0(如果没有SPI)，以字节为单位。关于IKE SA的通告，SPI大小必须为0。\n通告报文类型(2字节)-通告报文的类型。\nSPI(变长)-安全参数索引.SPI域标识了这个参数要应用的SPI.它被发送主机HI含蓄的认证.发送主机可以随意引入新的SPI.也就是说，如果接收的消息有新的SPI，它意味着所有指定给旧SPI的地址仍然工作，同时新接收的消息中的新地址是与新SPI相关联的.另一方面，如果接收的消息中有一个接收端已经知道的SPI，应该用新地址取代所有与这个SPI相关的地址.\n通告数据(变长)-除了通告报文类型以外，传输的信息或差错数据。这个域的值是基于类型的。\n通告信息可以是说明SA不能建立的原因的差错报文，也可以是管理SADB的程序想与另一个程序传输的状态信息。0-16383的类型用于报告差错。关于状态类型的通告载荷可以被加入任何报文中，而且，如果不能识别时必须忽略。它们用来指示性能，和协商非加密参数(作为SA协商的一部分)。具体的有关通告信息类型可参阅[14]。其中，8192-16383和40960-65535是供私有使用的，我们定义一种新的类型用来完成HIP主机交换关于IP地址和地址改变信息的功能：HIP_NOTIFY_REA，它的值为40960。\n此类型的通告数据格式如图23所示。\n保留(1比特)-发送端清0；接收端忽略。\n属性类型(7比特)-配置属性类型的唯一识别符，表明地址的类型。\n长度(2字节)-以字节为单位。\n值(0或多字节)-这个配置属性的变长值域。\nP：首选地址。如果HIP_NOTIFY_REA中的第一个地址是新的首选地址，则置1；否则置0。\n保留：发送置1，接收忽略。\n地址生存时间：以秒为单位。\n地址：IPv6地址或IPv4-in-IPv6格式的IPv4地址。\n定义了这样的通告载荷，我们就可以具体考虑了以下几种不同的移动性和多家乡情况中的INFORMATIONAL交换来通知地址的改变：\n1)使用一对SA的移动性；\n由于链路通告的IPv6前缀改变，PPP链路的重连接，新DHCP分配，或移动到其它子网移动主机有时必须改变绑定到接口的IP地址。此时，为了维护通信关系，主机必须通知对端新的IP地址。在这个部分只考虑了移动主机只有一个接口，IP地址和一对SA(一个入站，一个出战)的情况。\n当移动主机从一个IP地址切换到另一个时，会与对端断开连接一段很短的时间。一得到新IP地址，移动主机就通过INFORMATIONAL交换向对端发送HIP_NOTIFY_REA参数并指出以下问题：新IP地址，与新IP地址相关的SPI，地址生存时间，和新地址是否为首选地址。\n2)主机多家乡；\n一个主机(移动或静止的)可能有多于一个的接口。主机可能通过HIP_NOTIFY_REA参数通知对端主机附属的接口。为了避免ESP重排序窗口的问题，主机应该为每个用来从对端主机接收数据的接口使用不同的SA。当提供给对端主机多于一个的地址，主机应该指出哪个地址是首选的。默认的，IKE-H交换中使用的地址是首选的。\n当处理建立新SA的入站HIP_NOTIFY_REA时，主机使用包含HIP_NOTIFY_REA的通告的目的地址作为HIP_NOTIFY_REA加NES指向的本地地址.主机可以使用相同的IP地址向不同的对端地址发送HIP_NOTIFY_REA，这会同时的建立有不同源地址的多个入站SA.\n3)站点多家乡；\n主机可能有一个具有多个全球IP地址的接口。这种场景可能是由于有多个高层ISP的站点，或仅仅是因为站点为所有主机同时提供IPv4和IPv6地址。这种情况的处理就好像有不同IP地址一样，如上面主机多家乡所述。此外，当主机本身有多个接口时，单个接口也可能成为站点多家乡。\n4)双主机多家乡；\n如图24所示，考虑以下这种情况，当IKE-H交换完成之后两个主机都想要添加额外的地址。主机1想要添加地址地址1b。它会向位于地址2a的主机2发送HIP_NOTIFY_REA，而且主机1和2之间会加入一组新的SPI(称为SPI1b和SPI2b)。接下来，考虑主机2想要添加地址地址2b。主机2现在可以选择向主机1的哪个地址发送HIP_NOTIFY_REA。它可以选择向地址1a，地址1b，或两者同时发送HIP_NOTIFY_REA。如果它选择向两个地址同时发送，那么两个主机之间会存在一个完整的SA网络(4对SA)。这是最普遍的情况；经常是主机只与对端的首选地址建立新的SA。IKE-H地址重分配协议足够灵活，完全能够适应这种情况。\n5)移动性和多家乡的结合；\n许多主机可能同时具有移动性和多家乡，也就是说有多个移动接口。此外，如果接口使用不同的接入技术，可能一个接口是稳定的(保持当前的地址)而其它的接口是移动的(IP地址的改变)。HIP_NOTIFY_REA加CREATE_IPSEC_SA足够灵活能够处理多数这样的场景。\n6)网络重编号\nIPv6网络的重编号会比大多数IPv4的网络更频繁。从一个端主机的角度来看，网络重编号与移动性相似。\n五、有关IKE-H方法的一些考虑\nIKE-H方法主要是在原有HIP协议基本框架的基础上对HIP协议的密钥交换协议——基本交换作出了必要的改进。并为了实现主机(包括安全网关在内)的移动性和多家乡功能扩展定义了新的通告载荷报文类型以及HIP_NOTIFY_REA数据格式。考虑了不同环境下的具体使用。由于采用的是基于IKE的密钥交换协议，所以可以使适用范围由终端主机扩展到包括终端主机在内安全网关等不同的场所。\n本发明技术方案带来的有益效果为：本发明针对原有HIP协议规程设计了一种高效、灵活、可靠的改进IKEv2密钥交换协议——IKE-H，来使通信节点对等体地址改变时保证HIP交换发起者和响应者之间端到端通信的安全性：为IP数据报提供机密性、数据完整性、接入控制、身份鉴别和数据源认证，防止在HIP协议中出现DoS(拒绝服务)或者MitM(中间人)等攻击。\n本发明提供了一种可以在主机(或者安全网关)具有移动性、多家乡功能，以及同时多家乡及移动情况下提供维持原有IPSec SA不变来保护数据功能的方法。并支持一个同时有多个正在通信的IPv4/IPv6连接的安全网关在IPv4和IPv6地址之间切换即支持站点多家乡，而不用中断和重新建立高层协议连接。\n此外，采用本发明，在原先只有端到端的HIP通信扩展后可以实现更多如同安全网关保护的内部子网主机通信等应用。并支持一般移动性、主机多家乡、站点多家乡、双主机多家乡、网络重编号以及多家乡和移动性的结合等具体场景。\n以上具体实施方式仅用于说明而非用于限定本发明。\n参考文献(如专利/论文/标准)\n[1]R.Moskowitz and P.Nikander，“Host Identity Protocol Architecture”，work in progress，Internet-Draft，IETF，June 2004.\n[2]P.Nikander，J.Ylitalo，and J.Wall，“Integrating Security，Mobility，and Multi-Homingin a HIP Way，”in Proc.Network and Distributed Systems Security Symposium，February 6-7，2003，San Diego，CA，pp.87-99，Internet Society，February 2003.\n[3]T.Kivinen，“Design of the MOBIKE protocol，”work in progress，Internet-Draft，IETF，June 2004\n[4]D.Johnson，C.Perkins，J.Arkko，“Mobility Support in IPv6”，RFC 3775，IETF，June2004\n[5]F.Dupont，W.Haddad，“How to make IPsec more mobile IPv6 friendly”，work inprogress，Internet-Draft，IETF，February 2004.\n[6]D.Khatavkar，E.R.Hixon，R.Pendse，“Quantizing the throughput reduction of IPSecwith mobile IP”，Circuits and Systems，2002.MWSCAS-2002.The 2002 45th MidwestSymposium on，Volume：3，4-7 Aug.2002 Pages：III-505-III-508 vol.3\n[7]Yongguang Zhang，“A multilayer IP security protocol for TCP performanceenhancement in wireless networks”，Selected Areas in Communications，IEEE Journalon，Volume：22，Issue：4，May 2004 Pages：767-776.\n[8]Wang Haitao，Zheng Shaoren，“The security issues and countermeasures in Mobile IP”，Info-tech and Info-net，2001.Proceedings.ICII 2001-Beijing.2001 International Conferenceson，Volume：5，29 Oct.-1 Nov.2001 Pages：122-127 vol.5\n[9]T.Braun，M.Danzeisen，“Secure mobile IP communication”，Local ComputerNetworks，2001.Proceedings.LCN 2001.26th Annual IEEE Conference on，14-16 Nov.2001Pages：586-593\n[10]N.Assaf，J.Luo，M.Dillinger，L.Menendez，“Interworking between IP security andperformance enhancing proxies for mobile networks”，Communications Magazine，IEEE，Volume：40，Issue：5，May 2002 Pages：138-144\n[11]R.Moskowitz，P.Nikander，P.Jokela，T.Henderson，“Host Identity Protocol”，workin progress，Internet-Draft，IETF，June 11，2004\n[12]P.Nikander，J.Arkko，T.Henderson，“End-Host Mobility and Multi-Homing withHost Identity Protocol”，work in progress，Internet-Draft，IETF，July 13，2004\n[13]T.R.Henderson，J.M.Ahrenholz，J.H.Kim，“Experience with the host identityprotocol for secure host mobility and multihoming”，Wireless Communications and Networking，2003.WCNC 2003.2003 IEEE，Volume：3，16-20 March 2003 Pages：2120-2125 vol.3\n[14]Charlie Kaufman，“Internet Key Exchange(IKEv2)Protocol”，work in progress，Internet-Draft，IETF，May 29，2004\n[15]Francis Dupont，“Address Management for IKE version 2”，work in progress，Internet-Draft，IETF，February 2003\n[16]P.Eronen，H.Tschofenig“Simple Mobility and Multihoming Extensions for IKEv2(SMOBIKE)”，work in progress，Internet-Draft，IETF，March 29，2004\n[17]T.Kivinen，“MOBIKE protocol”，work in progress，Internet-Draft，IETF，February 24，2004.