CN1770761A - 一种基于网络密钥交换协议的地址更新方法 - Google Patents
一种基于网络密钥交换协议的地址更新方法 Download PDFInfo
- Publication number
- CN1770761A CN1770761A CN 200410087132 CN200410087132A CN1770761A CN 1770761 A CN1770761 A CN 1770761A CN 200410087132 CN200410087132 CN 200410087132 CN 200410087132 A CN200410087132 A CN 200410087132A CN 1770761 A CN1770761 A CN 1770761A
- Authority
- CN
- China
- Prior art keywords
- address
- update
- list
- host
- binding
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明涉及网络技术，为了解决IKEv2的地址更新问题，提供了一种基于网络密钥交换协议的地址更新方法，在起始端主机和响应端主机中绑定包括起始端主机私有地址及公开地址的地址列表，当起始端主机获得新的私有地址或公开地址则在该端主机地址列表中建立新的条目，并请求更新响应端主机地址列表，响应端返回确认更新信息完成地址更新。保证了更新地址的物理可达性，防止了“第三方轰炸”和“透明的伪NAT攻击”。
Description
技术领域
本发明涉及网络技术，尤其涉及一种虚拟专用网络(VPN)，具体的讲是一种基于网络密钥交换协议的地址更新方法。
背景技术
随着Internet的不断发展，由于其方便快捷，很多大公司和政府部门或民间组织都用它来传输数据，这些单位的各个部门往往都是跨地区的，相隔很远，如果全部用自己的专线，其价格非常昂贵。于是利用Internet这样的公共网络来传输私有数据就可以节省大量费用。但是这样的后果就是非常不安全，在Internet上，数据随时可能会被不怀好意的网络入侵者窃取或修改，因此，数据在传输过程中必须被加密，接收方和发送方通过一个虚拟的安全隧道来传输信息，这就是虚拟专用网技术。如果是在TCP或UDP层加密，那么通过截取IP层的数据同样可以获得机密信息，在IP层使用加密和认证就非常安全了，这就是IPsec(IP安全体系结构)技术。目前利用IPsec来实现VPN(虚拟专用网)成为一种发展趋势。
同时，随着IPv4地址日益不足希望允许专用网络上的多台PC共享单个、全局路由的IPv4地址。这是部署NAT的一个主要原因，网络地址转换(NAT)是一个Internet工程任务组(Internet Engineering Task Force，IETF)标准，能够实现IPv4地址耗费问题(在IPv6部署中却没必要)。
在很多情况下，用户与公司之间的VPN连接时的IP地址可能随时变化，例如在笔记本漫游场景中移动设备是笔记本，它可以有多种方法连接到互联网上。比如，使用固定的以太网，WLAN和GPRS联网，并且这些方式可以在不同的时间使用。人们总是尝试使用最有效的连接，但是这些连接可能会经常改变，比如，一台笔记本断开了以太网连接开始使用公司的WLAN，之后，它又离开了公司，在回家的路上断开WLAN连接开始使用GPRS。回家之后它可能又开始使用WLAN连接(但是用不同的IP地址，而且该用户可能是在NAT设备之后的)。
这台设备并没有使用移动IPv6或类似的协议，它只是想与公司的安全网关保持VPN连接。即使接口或IP地址改变了，例如该设备位于NAT设备之后，但仍然能够使用原来的安全联盟，这样就需要某种地址更新机制，使得安全联盟能够自动更新改变后的IP地址。
另一个可能使用MOBIKE(IETF所属的工作组，致力于扩展网络密钥交换协议，使其适应主机移动性和多家乡)的场景是安全网关，网关的另一端是可以漫游的笔记本。也就是说，安全网关可以对不同的ISP提供不同的接口，而且即使这些连接发生故障了也要能够提供新的连接。安全网关可以预先知道它将使用的IP地址组，但是它需要动态的通知客户端使用哪些地址。
但是当前的IPsec和网络密钥交换协议(IKEv2：Internet Key ExchangeVersion 2)文档明确的指出，安全联盟是建立在IP地址之上的，并且IPsec安全联盟使用与IKE安全联盟相同的IP地址。这意味着在IKEv2安全联盟上只有一对IP地址，也就是只有一对IP地址作为隧道模式IPsec安全联盟的网关地址，而且安全联盟建立之后就不能改变这些地址。但是有一些场景却需要IP地址的快速改变，如主机的移动、漫游或VPN场景等。有的时候，可以在IP地址改变后，通过重加密所有的IPsec和IKE安全联盟来解决问题。但重加密技术在有些场景中是不适合的，比如，可能因为设备太慢了不能那么频繁的重加密安全联盟，或者重加密和(IKEv2要求的)认证需要使用者的参与(如Secur ID cards等)。由于这些原因，就需要一种机制更新绑定在IPsec和IKEv2安全联盟上的IP地址。
MOBIKE工作组的主要任务就是扩展IKEv2，使之适用于主机移动性和多家乡的情况。该工作组目前已经提出了几个草案，如IKEv2的地址管理(Address Management for IKE version 2)和IKEv2的简单移动性和多家乡扩展(Simple Mobil ity and Multihoming Extens ions for IKEv2，SMOBIKE)这两个草案。第一个草案在原IKEv2的基础上定义了新的地址通知载荷和地址更新载荷，通过地址通知和地址更新的方式实现地址管理，以此来解决移动性和多家乡问题。第二个草案扩展了IKEv2的NAT机制，强制其在没有NAT设备时执行，实现了动态的地址更新。这两个草案通过不同的方式在一定程度上解决了移动性和多家乡问题，但是它们都不全面，存在某些方面的问题，并不是理想的解决方案。
SMOBIKE协议扩展了现有的IKEv2，使得它能够支持主机移动和多家乡。SMOBIKE协议修改了基于IKEv2的NAT穿越机制，允许在没有检测到NAT的情况下，使用动态地址更新和UDP封装。SMOBIKE协议定义了USE_DYNAMIC_ADDRESS_UPDATES通知载荷(使用动态地址更新，它是NOTIFY载荷的一个状态信息，是smobike自己定义的)，通过发送这个通知载荷，主机可以在没有NAT的情况下使能对端的地址更新功能。
SMOBIKE协议并没有定义地址更新载荷，它是从接收报文的源地址来判断对端地址是否改变的。也就是说，IKEv2和ESP数据包发送到最后一次合法数据的源地址。其地址更新程序取决于UDP封装是怎样使用的。
1.如果主机不支持UDP封装，则直接使用新地址。
2.如果主机正在使用UDP封装，并且准备一直使用下去，则直接使用新地址。
3.如果主机不能确定当前的UDP配置情况与新地址的要求是否符合，则开始NAT检测。即根据NAT检测的结果判断是否使用UDP封装。如果当前的UDP封装配置是正确的，则直接使用新地址。
对端收到被认证的数据包后就会进行地址更新。如果没有要发送的ESP(安全负载报头)数据包，主机可以发送空的IKEv2信息交换。
有时需要在没有NAT的情况下使用UDP封装。典型的例子是执行过滤功能的防火墙，因为它不改变数据包的IP地址，所以不能被NAT_DETECTION(是NAT-DETECTION-DESTINATION-IP和NAT-DETECTION-SOURCE-IP的简写)发现。
主机可以配置成总是使用UDP封装，或者是，可以根据没有收到ESP报文来推测使用UDP封装。在某些移动网络中，应该配置成总是使用UDP封装的，因为网络中路由的改变可能引起数据包穿越NAT，即使端主机没有移动。
主机可以在NAT_DETECTION中包含USE_UDP_ENCAPSULATION通知载荷，强制使用UDP封装。
而SMOBIKE协议容易受到“透明的伪NAT攻击”。因为在SMOBIKE协议中，地址信息位于外部IP头中，并没有受到认证和完整性保护，攻击者可以截获数据包并且修改它们的源IP地址(和端口号)。结果使得接收者开始使用不正确的对端地址，并且向这个地址发送受IPsec保护的数据流量。如果攻击者提供的地址是个“黑洞”，那么发送到这个地址的流量都会被丢失掉。这表现为DoS攻击。
草案Address Management for IKE version 2(以下简称addrmgmt)提供了地址管理功能，完善了现有的IKEv2，使得它能够支持主机移动性和多家乡。
当前的IKEv2草案总是假设IP地址能够标识一个节点，当节点位于NAT之后时，就可能出现很多的节点共用同一个IP地址(公开地址)的情况，而且一个节点可以有多个不同的IP地址。这些问题在应用时必须予以考虑。因此，addrmgmt协议引入了地址通知和更新的功能。
对端地址通知采用了现有的NAT-DETECTION-SOURCE-IP(由NOTIFY载荷携带，这个状态信息由它的接收端使用，判断源地址是否在NAT之后)和NAT-DETECTION-DESTINATION-IP(由NOTIFY载荷携带，这个状态信息由它的接收端使用，判断自己是否在NAT之后)，该两个状态信息是NOTIFY载荷(NOTIFY载荷是IKEv2定义的载荷之一，用于在对端之间传输信息数据，如差错情况和状态转换)的一部分载荷。它们包含了对端源地址或目的地址，以及和这些地址的相关协议簇和操作码。这些载荷必须是被加密的。这里的操作指的是修改优先级，增加和删除。
这些报文属于IKE_AUTH(IKE起始交换的四条报文中的第三和第四条报文，它的功能是认证前面的报文，交换身份和证书，和建立第一个IPsec SA)或CREATE_CHILD_SA(在起始交换完成后，用来建立更多的IPsec SA)交换，它们或者是承载对端地址更新载荷，或者纯粹是对对端地址组的管理(增加/删除)。这些加密的载荷能够证明，在路由过程中对端地址没有被改变，并且使能了对地址组的操作，也就是说，改变对端的主要地址，或是在对端地址组中增加和删除一个地址。
Addrmgmt协议为地址更新机制定义了新的地址更新载荷，新载荷的定义参照了IKEv2原有的DELETE载荷。
Addrmgmt协议为地址更新机制只适用于没有NAT存在的场合。
更新请求的接收端需要检查新IP地址的合法性，它可以使用返回可路由检查，向新地址发送带有NONCE载荷(是IKEv2定义的载荷之一，包含随机数，用于在交换中保证活跃性和抗重播攻击)的信息交换请求并且等待响应。因为信息交换是受保护的，所以不需要其它的措施了。
Addrmgmt协议定义的返回可路由检查程序如图1所示，起始端向响应端发送地址更新请求报文(Request)，报文中的地址更新载荷包含要更新的地址。响应端收到请求后要检验更新地址的合法性，即开始返回可路由检查。响应端向起始端发送的报文中包含NONCE载荷，里面是一个随机数。起始端将该NONCE值返回，以证明它在更新地址上是可达的。最后，响应端发送地址更新应答报文(Reply)，表示地址更新完成。
但是Addrmgmt协议并没有考虑与NAT兼容使用的问题，当前文档的规定是，避免出现一端使用NAT穿越而另一端使用MOBIKE的情况。当这种情况出现时，就必须强制两端都使用NAT穿越，这显然限制了MOBIKE的使用范围。
在当前的IKEv2文档中，安全联盟是建立在IP地址之上的，该地址是唯一的并且是不变的。当主机的IP地址改变时(如主机移动性或多家乡)，就只能重加密或重新建立安全联盟。但这样做会加重主机的负担，并且当重加密需要人工参与时也显得不够简便。有时MOBIKE和NAT穿越是不兼容的。NAT穿越试图以与IP地址无关的方式工作，也就是不管是不是有人修改了它的IP地址。MOBIKE的一个目的是认证IP地址的改变，也就是，当IP地址改变时，我们要证明这个改变是其它节点进行的合法改变，而不是路径上攻击者做的。这是MOBIKE与NAT之间的主要矛盾。因此需要一种机制能够动态的更新安全联盟的IP地址。
发明内容
本发明的目的在于提供一种基于网络密钥交换协议的地址更新方法，解决基于网络密钥交换协议的地址更新问题，通过返回可路由机制同时对公开地址(应用于NAT场景，指数据包被NAT修改过的IP地址。可以多个私有地址公用一个公开地址)和私有地址(应用于NAT场景，指主机本身的IP地址)进行了确认，认证了地址的改变，在安全方面满足了MOBIKE的要求，使得NAT能够符合MOBIKE标准工作。
一种基于网络密钥交换协议的地址更新方法，在起始端主机和响应端主机中绑定包括起始端主机私有地址及公开地址的地址列表，当起始端主机获得新的私有地址则在该端主机地址列表中建立新的条目，并请求更新响应端主机地址列表，确定两端连接使用的私有地址与公开地址，响应端返回确认更新信息完成地址更新。
还包括如下步骤，当响应端接收到更新地址请求时，比较数据包的源地址与该请求报文中绑定条目的公开地址是否一样，若相同则直接更新响应端地址绑定地址列表并向起始端发送更新确认信息完成地址更新，如果不同则向起始端发送验证信息和该起始端的源地址载荷；
起始端如果接收到验证信息和该起始端的源地址载荷，则根据该源地址载荷的内容更新该起始端绑定地址列表中对应条目的公开地址，并在返回验证信息的同时返回更新公开地址后的绑定条目；
响应端接收起始端发送的数据包，判断验证信息，如果不相同则丢弃该数据包，如果验证信息相同则接着处理新的绑定条目，用新的绑定条目更新响应端地址列表。
在响应端接收到更新地址请求判断数据包的源地址与该请求报文中绑定条目的公开地址相同时向数据包的源地址发送验证信息，起始端若仅接收到该验证信息则向响应端返回该信息，响应端判断该验证信息是否与发出的验证信息相同则用起始端发送的地址列表条目更新该响应端相应的地址列表条目，更新完成后向起始端发送更新确认信息，完成地址更新。
当起始端主机获得新的私有地址或公开地址在该端主机地址列表中建立新的条目中的私有地址和公开地址是相同的。
在起始端与响应端都更新完地址列表后，起始端向其他节点发送的地址更新列表为更新后的地址列表。
所述的验证信息为一随机数，用于防止攻击者伪造数据。
旧的绑定条目会在IP地址无用或超出生存期后自动删除。
所述的更新地址所采用的操作参数为IKEv2的NAT-DETECTION-SOURCE-IP和NAT-DETECTION-DESTINATION-IP状态信息。
所述的地址更新载荷由ESP封装。
本发明解决了IPsec安全联盟的地址更新问题。使得安全联盟不再局限于唯一的IP地址，当IP地址改变时安全联盟也可以自动更新，其过程不需要人工的参与，也不会像重加密一样的消耗系统资源。并且提供了足够多的安全保护，地址更新载荷被ESP封装，受到加密和完整性保护，可以保证报文不会在传输中被窜改。对地址更新采用了返回可路由检查的程序，保证了更新地址的物理可达性，防止了“第三方轰炸”和“透明的伪NAT攻击”。
附图说明
图1是现有Addrmgmt协议定义的返回可路由检查工作图；
图2是本发明报文交换工作图。
具体实施方式
下面结合附图说明本发明的具体实施方式：
本发明提供了一种基于网络密钥交换协议的地址更新方法，在起始端和响应端主机需要维护一个私有地址和公开地址的绑定地址列表。私有地址是起始端主机本身的IP地址，该IP地址可能是某个子网内的私有地址，用于标识安全联盟；公开地址是数据包经过NAT后被改变的地址，该公开地址是Internet上真实的IP地址，该地址加上传输层端口号就可以完成NAT穿越。绑定地址列表分为两部分：
一部分是起始端主机绑定地址列表，列表条目是起始端主机私有IP地址及其公开地址。当起始端主机获得新的私有IP地址后(如果在没有NAT的情况下为获得新的公开地址)，就自动在起始端主机绑定地址列表中建立新的条目，并向响应端主机发送地址更新请求，旧的绑定条目会在IP地址无用或超出生存期后自动删除，若起始端主机不在NAT之后，则公开地址与私有地址相同，无论起始端主机得到的是新私有地址还是新公开地址，默认情况都是将公开地址设置成与私有地址相同的地址。列表内容根据响应端主机的返回信息自动更新。
另一部分是响应端主机绑定地址列表，列表条目是起始端主机IP地址及其公开地址。绑定地址列表的内容根据响应端主机的通知自动更新。每个绑定条目都有一个生存期，超出生存期的条目会被自动删除。
其中，起始端主机绑定地址列表主要用于地址更新，而相应端主机绑定地址列表主要用于安全联盟的标识和NAT穿越。
当移动设备是笔记本，它可以有多种方法连接到互联网上。比如，使用固定的以太网，WLAN和GPRS联网，并且这些方式可以在不同的时间使用。人们总是尝试使用最有效的连接，但是这些连接可能会经常改变，比如，一台笔记本断开了以太网连接开始使用公司的WLAN，之后，它又离开了公司，在回家的路上断开WLAN连接开始使用GPRS。回家之后它可能又开始使用WLAN连接(但是用不同的IP地址)。
这台设备并没有使用移动IPv6或类似的协议，它只是想与公司的安全网关保持VPN连接。这里用户笔记本计算机为起始端，公司的VPN安全网关为响应端，地址更新过程包括四条报文的交换，具体过程如图2所示。
当起始端获得新的私有IP地址时，就在本主机绑定地址列表里建立一个新的条目(此时将公开地址与私有地址设置为相同的)，并向响应端发送地址更新请求。
响应端收到地址更新请求时，会比较数据包的源地址与该请求数据包绑定条目中的公开地址。若相同，则向数据包的源地址发送NONCE载荷；若不同，则向数据包的源地址发送NONCE载荷和NAT-DETECTION-DESTINATION-IP状态信息，其中，NAT-DETECTION-DESTINATION-IP状态信息中的数据是第一条报文的源地址。
起始端收到第二条报文后会根据报文的内容选择处理的方式。若报文中只有NONCE载荷，则起始端将该NONCE值返回。若报文中有NAT-DETECTION-DESTINATION-IP状态信息，则根据NAT-DETECTION-DESTINATION-IP状态信息的内容更新起始端主机绑定地址列表中对应条目的公开地址，此时发送的第三条报文中除了NONCE载荷外还要包含更新后的绑定条目，即更新了公开地址的绑定条目。
响应端收到第三条报文后，首先比较NONCE值，若返回的NONCE值与发出的相同，在接着处理报文的其它内容；若NONCE不同，则直接丢弃该报文。报文被接受以后则查看其它内容，若报文中有新的绑定条目，则用新的绑定条目更新绑定地址列表；若没有新的绑定条目在用第一条报文中的绑定条目更新绑定地址列表。处理完绑定列表后，响应端还要发送地址更新确认报文，以表示地址更新完成。
起始端收到地址更新确认后整个地址更新过程结束。
地址更新结束后，响应端得到了起始端的新的IP地址(包括私有地址和公开地址)，起始端也更新了自己的绑定更新列表，即知道自己的公开地址。这样，当起始端向第二个节点发送地址更新时，可以直接使用更新后的绑定条目。当应用于最小系统时，就可以避免返回可路由程序，将交换的报文从四条减少为两条，减轻了系统的负担，简化了更新程序。
在以上的四条报文交换中，第二和第三条报文就完成了返回可路由检查的功能。第二条报文被发送到第一条报文的源地址，如果能够收到第三条响应报文，就说明该源地址是可靠的。加入的NONCE值是一个随机数，为了防止攻击者随意的伪造响应报文。这样即使接口或IP地址改变了，但仍然能够使用原来的安全联盟，使得安全联盟能够自动更新改变后的IP地址。
另一个可能使用MOBIKE的场景是安全网关，网关的另一端是可以漫游的笔记本。也就是说，安全网关可以对不同的ISP提供不同的接口，而且即使这些连接发生故障了也要能够提供新的连接。安全网关可以预先知道它将使用的IP地址组，但是它需要动态的通知客户端使用哪些地址。
当起始端获得新的私有IP地址时，就在本主机绑定地址列表里建立一个新的条目(此时将公开地址与私有地址设置为相同的)，并向响应端发送地址更新请求。
响应端收到地址更新请求时，假设本场合中，通信双方的身份是可以完全信任的，只有在通信双方具有足够高的信任等级时才能去掉返回可路由程序，或者是应用于最小系统，这就排除了第三方轰炸的可能，这时可以配置成不需要返回可路由检查程序。当响应端收到第一条报文后，仍然比较数据包的源地址与请求报文中绑定条目的公开地址，若相同，则可以直接更新响应端的绑定地址列表相应条目并发送更新确认报文。若不同，则向数据包的源地址发送NONCE载荷和NAT-DETECTION-DESTINATION-IP状态信息，其中，NAT-DETECTION-DESTINATION-IP状态信息中的数据是第一条报文的源地址。
起始端收到第二条报文后会根据报文的内容选择处理的方式。报文中包括NONCE载荷和NAT-DETECTION-DESTINATION-IP状态信息，根据NAT-DETECTION-DESTINATION-IP状态信息的内容更新起始端主机绑定地址列表中对应条目的公开地址，此时发送的第三条报文中除了NONCE载荷外还要包含更新后的绑定条目，即更新了公开地址的绑定条目。
响应端收到第三条报文后，首先比较NONCE值，若返回的NINCE值与发出的相同，在接着处理报文的其它内容；若NONCE不同，则直接丢弃该报文。报文被接受以后则查看其它内容，用报文中新的绑定条目，则用新的绑定条目更新绑定地址列表；处理完绑定列表后，响应端还要发送地址更新确认报文，以表示地址更新完成。
起始端收到地址更新确认后整个地址更新过程结束。
本发明并没有定义新的载荷，地址更新是使用的原IKEv2的NAT-DETECTION-SOURCE-IP和NAT-DETECTION-DESTINATION-IP状态信息。其中，NAT-DETECTION-SOURCE-IP状态信息对应私有地址，NAT-DETECTION-DESTINATION-IP状态信息对应公开地址。
本发明的有益效果在于解决了IPsec安全联盟的地址更新问题。使得安全联盟不再局限于唯一的IP地址，当IP地址改变时安全联盟也可以自动更新，其过程不需要人工的参与，也不会像重加密一样的消耗系统资源。提供了足够多的安全保护。地址更新载荷被ESP封装，受到加密和完整性保护，可以保证报文不会在传输中被窜改。对地址更新采用了返回可路由检查的程序，保证了更新地址的物理可达性，防止了“第三方轰炸”和“透明的伪NAT攻击”。解决了MOBIKE和NAT的兼容问题。通过建立绑定更新列表和对地址改变的及时更新，可以及时发现NAT设备并完成NAT穿越，在完成地址更新的同时也验证了起始端主机在新地址的可达性。
以上具体实施方式仅用于说明本发明，而非用于限定本发明。
Claims (9)
1.一种基于网络密钥交换协议的地址更新方法，其特征在于，在起始端主机和响应端主机中绑定包括起始端主机私有地址及公开地址的地址列表，当起始端主机获得新的私有地址则在该端主机地址列表中建立新的条目，并请求更新响应端主机地址列表，确定两端连接使用的私有地址与公开地址，响应端返回确认更新信息完成地址更新。
2.根据权利要求1所述的一种基于网络密钥交换协议的地址更新方法，其特征在于还包括如下步骤，当响应端接收到更新地址请求时，比较数据包的源地址与该请求报文中绑定条目的公开地址是否一样，若相同则直接更新响应端地址绑定地址列表并向起始端发送更新确认信息完成地址更新，如果不同则向起始端发送验证信息和该起始端的源地址载荷；
起始端如果接收到验证信息和该起始端的源地址载荷，则根据该源地址载荷的内容更新该起始端绑定地址列表中对应条目的公开地址，并在返回验证信息的同时返回更新公开地址后的绑定条目；
响应端接收起始端发送的数据包，判断验证信息，如果不相同则丢弃该数据包，如果验证信息相同则接着处理新的绑定条目，用新的绑定条目更新响应端地址列表。
3.根据权利要求2所述的一种基于网络密钥交换协议的地址更新方法，其特征在于，在响应端接收到更新地址请求判断数据包的源地址与该请求报文中绑定条目的公开地址相同时向数据包的源地址发送验证信息，起始端若仅接收到该验证信息则向响应端返回该信息，响应端判断该验证信息是否与发出的验证信息相同则用起始端发送的地址列表条目更新该响应端相应的地址列表条目，更新完成后向起始端发送更新确认信息，完成地址更新。
4.根据权利要求1所述的一种基于网络密钥交换协议的地址更新方法，其特征在于，当起始端主机获得新的私有地址或公开地址在该端主机地址列表中建立新的条目中的私有地址和公开地址是相同的。
5.根据权利要求1所述的一种基于网络密钥交换协议的地址更新方法，其特征在于，在起始端与响应端都更新完地址列表后，起始端向其他节点发送的地址更新列表为更新后的地址列表。
6.根据权利要求2、3所述的一种基于网络密钥交换协议的地址更新方法，其特征在于，所述的验证信息为一随机数，用于防止攻击者伪造数据。
7.根据权利要求2、3所述的一种基于网络密钥交换协议的地址更新方法，其特征在于，旧的绑定条目会在IP地址无用或超出生存期后自动删除。
8.根据权利要求2、3所述的一种基于网络密钥交换协议的地址更新方法，其特征在于，所述的更新地址所采用的操作参数为网络密钥交换协议的NAT-DETECTION-SOURCE-IP和NAT-DETECTION-DESTINATION-IP状态信息。
9.根据权利要求1、2、3、8所述的一种基于网络密钥交换协议的地址更新方法，其特征在于，所述的地址更新载荷由ESP封装。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNB2004100871329A CN100556027C (zh) | 2004-11-01 | 2004-11-01 | 一种基于网络密钥交换协议的地址更新方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNB2004100871329A CN100556027C (zh) | 2004-11-01 | 2004-11-01 | 一种基于网络密钥交换协议的地址更新方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN1770761A true CN1770761A (zh) | 2006-05-10 |
| CN100556027C CN100556027C (zh) | 2009-10-28 |
Family
ID=36751753
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CNB2004100871329A Expired - Fee Related CN100556027C (zh) | 2004-11-01 | 2004-11-01 | 一种基于网络密钥交换协议的地址更新方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN100556027C (zh) |
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2008080275A1 (en) * | 2006-12-28 | 2008-07-10 | Beijing Jiaotong University | Integrated network construction method and integrated network generalized exchange route device |
| CN101217482B (zh) * | 2008-01-18 | 2010-09-08 | 杭州华三通信技术有限公司 | 一种穿越nat下发策略的方法和一种通信装置 |
| CN101197664B (zh) * | 2008-01-03 | 2010-12-08 | 杭州华三通信技术有限公司 | 一种密钥管理协议协商的方法、系统和装置 |
| CN101461214B (zh) * | 2006-06-07 | 2012-02-01 | 高通股份有限公司 | 用于无线通信的高效寻址方法、计算机可读介质和装置 |
| CN101426030B (zh) * | 2008-12-09 | 2012-06-27 | 华为技术有限公司 | 一种获取网络地址的方法和终端 |
| CN101617516B (zh) * | 2006-12-28 | 2012-10-10 | 意大利电信股份公司 | 控制客户端和具有私有网络地址的服务器之间的应用消息的方法和设备 |
| CN104410728A (zh) * | 2014-11-27 | 2015-03-11 | 中国科学院计算机网络信息中心 | 一种MIPv6中基于网络的DNS安全更新方法 |
-
2004
- 2004-11-01 CN CNB2004100871329A patent/CN100556027C/zh not_active Expired - Fee Related
Cited By (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101461214B (zh) * | 2006-06-07 | 2012-02-01 | 高通股份有限公司 | 用于无线通信的高效寻址方法、计算机可读介质和装置 |
| WO2008080275A1 (en) * | 2006-12-28 | 2008-07-10 | Beijing Jiaotong University | Integrated network construction method and integrated network generalized exchange route device |
| CN101617516B (zh) * | 2006-12-28 | 2012-10-10 | 意大利电信股份公司 | 控制客户端和具有私有网络地址的服务器之间的应用消息的方法和设备 |
| CN101197664B (zh) * | 2008-01-03 | 2010-12-08 | 杭州华三通信技术有限公司 | 一种密钥管理协议协商的方法、系统和装置 |
| CN101217482B (zh) * | 2008-01-18 | 2010-09-08 | 杭州华三通信技术有限公司 | 一种穿越nat下发策略的方法和一种通信装置 |
| CN101426030B (zh) * | 2008-12-09 | 2012-06-27 | 华为技术有限公司 | 一种获取网络地址的方法和终端 |
| CN104410728A (zh) * | 2014-11-27 | 2015-03-11 | 中国科学院计算机网络信息中心 | 一种MIPv6中基于网络的DNS安全更新方法 |
| CN104410728B (zh) * | 2014-11-27 | 2017-10-10 | 中国科学院计算机网络信息中心 | 一种MIPv6中基于网络的DNS安全更新方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN100556027C (zh) | 2009-10-28 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Moskowitz et al. | Host identity protocol (HIP) architecture | |
| Frankel et al. | Ip security (ipsec) and internet key exchange (ike) document roadmap | |
| Durdağı et al. | IPV4/IPV6 security and threat comparisons | |
| US6976177B2 (en) | Virtual private networks | |
| US8800024B2 (en) | System and method for host-initiated firewall discovery in a network environment | |
| US8897299B2 (en) | Method and systems for routing packets from a gateway to an endpoint | |
| KR101568713B1 (ko) | 호스트 및 게이트웨이를 인터로킹하기 위한 시스템 및 방법 | |
| US7480794B2 (en) | System and methods for transparent encryption | |
| CN1968272B (zh) | 通信网络中用于缓解拒绝服务攻击的方法和系统 | |
| CN102377524B (zh) | 分片处理的方法和系统 | |
| CN107231336A (zh) | 一种局域网内网资源的访问控制方法、装置及网关设备 | |
| JP4468453B2 (ja) | 往復経路確認の最適化 | |
| Nowaczewski et al. | Securing Future Internet and 5G using Customer Edge Switching using DNSCrypt and DNSSEC. | |
| Richardson et al. | Opportunistic encryption using the internet key exchange (ike) | |
| CN1770761A (zh) | 一种基于网络密钥交换协议的地址更新方法 | |
| JP2011054182A (ja) | ディジタルバトンを使用するシステムおよび方法、メッセージを認証するためのファイアウォール、装置、および、コンピュータ読み取り可能な媒体 | |
| JP2018074395A (ja) | データ通信システム、キャッシュｄｎｓ装置及び通信攻撃防止方法 | |
| Rubino | An open system for transparent firewall authentication and user traffic identification within corporate intranets | |
| Shanmugaraja et al. | Accessible methods to mitigate security attacks on ipv4 to ipv6 transitions | |
| Yoo et al. | A study on the connectivity of ipv6 to ipv4 domains and its security issues | |
| Tschofenig et al. | Traversing middleboxes with the host identity protocol | |
| Pahlevan | Signaling and policy enforcement for co-operative firewalls | |
| Radwan | Using IPSec in IPv6 Security | |
| Sameeha | Look at IPV6 Security advantages over IPV4 | |
| Sarma | Securing IPv6’s neighbour and router discovery using locally authentication process |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant | ||
| TR01 | Transfer of patent right | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20171205 Address after: Tiefu iron rich street Pizhou city 221331 Jiangsu city of Xuzhou province (Cultural Center) Patentee after: Pan Rongqiong Address before: 510640 Guangdong City, Tianhe District Province, No. five, road, public education building, unit 371-1, unit 2401 Patentee before: GUANGDONG GAOHANG INTELLECTUAL PROPERTY OPERATION Co.,Ltd. Effective date of registration: 20171205 Address after: 510640 Guangdong City, Tianhe District Province, No. five, road, public education building, unit 371-1, unit 2401 Patentee after: GUANGDONG GAOHANG INTELLECTUAL PROPERTY OPERATION Co.,Ltd. Address before: 518129 Bantian HUAWEI headquarters office building, Longgang District, Guangdong, Shenzhen Patentee before: HUAWEI TECHNOLOGIES Co.,Ltd. |
|
| CB03 | Change of inventor or designer information | ||
| CB03 | Change of inventor or designer information |
Inventor after: Qian Shuanghua Inventor before: Miao Fuyou Inventor before: Wang Jianglin Inventor before: Gao Shuai Inventor before: Qin Yajuan Inventor before: Liu Ying Inventor before: Zhang Hongke Inventor before: Zhang Sidong Inventor before: Yang Shen Inventor before: Su Wei Inventor before: Ren Yan Inventor before: Yang He Inventor before: Zheng Zuzhou Inventor before: Chen Jian |
|
| TR01 | Transfer of patent right | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20180124 Address after: Qidong City, Jiangsu province 226200 Nantong lvsigang Lu Bei Cun Fisheries Group No. 54 Patentee after: Qian Shuanghua Address before: Tiefu iron rich street Pizhou city 221331 Jiangsu city of Xuzhou province (Cultural Center) Patentee before: Pan Rongqiong |
|
| TR01 | Transfer of patent right | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20181102 Address after: 221300 Liu Gou Village, Zou Zhuang Town, Pizhou City, Xuzhou, Jiangsu Patentee after: Xuzhou Yong Wei Wood Industry Co.,Ltd. Address before: 226200 No. 54 fishing group, Lubei village, Lusi Gang Town, Qidong, Nantong, Jiangsu Patentee before: Qian Shuanghua |
|
| CF01 | Termination of patent right due to non-payment of annual fee | ||
| CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20091028 Termination date: 20181101 |