相关申请案交叉申请本申请要求于2018年11月15日提交、申请号为in201831042955、发明名称为“对安全联盟sa进行密钥更新”的印度专利申请的优先权，其全部内容通过引用并入本文。本公开大体上涉及电信，更具体地，涉及因特网安全协议，再更具体地，涉及用于对例如功率、带宽和/或处理能力有限的移动设备的安全联盟进行密钥更新的方法、设备、系统。
背景技术：
：：因特网密钥交换版本2(internetkeyexchangeversion-2，ikev2)是由rfc7296定义的协议，该协议的全部内容通过引用结合在本申请中，除了与本文的明确公开内容相反的地方。本文使用的术语采用rfc7296给出的含义，除了与本文的明确公开内容相反的地方。ikev2用于ipsec在协议套件中建立安全联盟(securityassociation，sa)。安全联盟sa可以是ike隧道或ipsec隧道。因特网协议安全(internetprotocolsecurity，ipsec)是网络协议套件，其对通过网络发送的数据包进行认证和加密。ike消息流包括请求和响应。请求方有责任确保可靠性。如果在超时时间内没有接收到响应，则请求方需要重传请求(或放弃连接)。ike会话的请求方和响应方之间的一对第一请求/响应消息(ike_sa_init)协商ike_sa的安全参数，发送随机数，发送diffie-hellman值。一对第二请求/响应消息(ike_auth)传输身份，证明知道与两个身份对应的秘密，为第一(并且通常仅此一个)认证头(authenticationheader，ah)和/或封装安全载荷(encapsulatingsecuritypayload，esp)child_sa建立sa。rfc7296中定义了ikev2中的ike密钥更新过程，rfc7296的全部内容通过引用结合在本申请中，除了与本文的明确公开内容相反的地方。本文使用的术语采用rfc7296给出的含义，除了与本文的明确公开内容相反的地方。根据定义，密钥更新就是在sa到期前创建新sa来代替即将到期的sa。例如，请求方与响应方之间的ike密钥更新交换携带一个或多个sa载荷，sa载荷包括一个或多个提议载荷。每个提议包括一组加密套件(例如，一个或多个加密套件)。通常，这些套件在进行密钥更新时不会发生变化。sa载荷的最小大小(例如，对于单个加密套件集)通常为52字节。对于ike密钥更新，最小可能大小为44字节。这可以包括44字节的sa载荷大小和40字节的提议大小。最小值由在sa载荷中选择和发送的加密套件的类型和数量确定。sa载荷结构通常包括sa载荷、提议、转码和属性。对于sa载荷，有一个或多个包含协议id和spi的提议载荷；对于提议载荷，有包含加密算法的转码，以及可选地包含密钥长度的属性。通过指定属性等来进一步定义特定提议，这样会增加sa载荷大小。本领域技术人员可以理解，在rfc7296第3.3节中详细公开了传统sa载荷。例如，请求方与响应方之间的ipsec密钥更新交换还携带sa载荷，其包含加密套件(例如，单个或多个加密套件)以及ts载荷(例如tsi载荷和tsr载荷)。在大多数情况下，这些载荷在进行密钥更新时不会发生变化，类似于ike密钥更新过程。通常sa载荷最小大小为40字节，每个ts大小为24字节(2*24＝48字节)。图1a提供了传统sa载荷的结构的一些示例。第一sa载荷不包含任何属性，第二sa载荷包含属性，两个sa载荷中每一个sa载荷都包含一个提议。第三sa载荷包含两个提议，每个提议都包含属性。在对ikesa和/或ipsecsa进行密钥更新时，在有多个加密套件的情况下，载荷大小成比例增加。该密钥更新是周期性地触发的。每次密钥更新都需要消耗带宽和功率，以处理这些载荷。技术实现要素：本
发明内容旨在介绍与用于对安全联盟进行密钥更新的方法、设备和系统相关的概念。此外，修改已知sa密钥更新过程中所交换的现有消息类型。此外，还介绍了用于sa密钥更新过程的新消息。尽管参考ikev2描述了本公开，但应理解，本发明可以同等地应用于其它密钥更新机制。根据第一方面，本申请实施例提供了一种对包括第一网络设备和第二网络设备的网络系统中的安全联盟(securityassociation，sa)进行密钥更新的方法，其中，第一网络设备与第二网络设备之间建立有因特网密钥交换(internetkeyexchange，ike)隧道和因特网协议安全(internetprotocolsecurity，ipsec)隧道。该方法中，第一网络设备向第二网络设备发送用于对sa进行密钥更新的第一密钥更新请求。第一密钥更新请求中携带第一安全参数索引(securityparameterindex，spi)和与第一网络设备相关联的加密套件。此后，第一网络设备接收来自第二网络设备的第一密钥更新响应。当与第二网络设备相关联的加密套件没有发生变化时，第一密钥更新响应中携带第二spi且不携带与第二网络设备相关联的加密套件。然后，第一网络设备根据第一spi、与第一网络设备相关联的加密套件以及第二spi，对sa进行密钥更新。在上述技术方案中，当与第二网络设备相关联的加密套件没有发生变化时，通过在密钥更新响应中不携带该加密套件，以减小在密钥更新中的载荷的大小，从而在例如ikesa密钥更新和ipsecsa密钥更新的密钥更新过程中节省带宽、处理时间和功率。根据第二方面，本申请实施例提供了一种对包括第一网络设备和第二网络设备的网络系统中的安全联盟(securityassociation，sa)进行密钥更新的方法，其中，第一网络设备与第二网络设备之间建立有因特网密钥交换(internetkeyexchange，ike)隧道和因特网协议安全(internetprotocolsecurity，ipsec)隧道。在该方法中，第二网络设备接收来自第一网络设备的用于对sa进行密钥更新的第一密钥更新请求，其中，第一密钥更新请求中携带第一安全参数索引(securityparameterindex，spi)和与第一网络设备相关联的加密套件。此后，第二网络设备确定与第二网络设备相关联的加密套件是否发生变化。然后，第二网络设备向第一网络设备发送第一密钥更新响应；其中，当与第二网络设备相关联的加密套件没有发生变化时，第一密钥更新响应中携带第二spi，且不携带与第二网络设备相关联的加密套件。此后，第二网络设备根据第一spi和第二spi对sa进行密钥更新。具体地，与第二网络设备相关联的当前使用的加密套件未发生变化，其用于sa并且存在于第一密钥更新请求中携带的与第一网络设备相关联的加密套件中。还根据与第二网络设备相关联的当前使用的加密套件进行密钥更新。在上述技术方案中，当与第二网络设备相关联的加密套件没有发生变化时，通过在密钥更新响应中不携带该加密套件，以减小在密钥更新中的载荷的大小，从而在例如ikesa密钥更新和ipsecsa密钥更新的密钥更新过程中节省带宽、处理时间和功率。根据第三方面，本申请实施例提供了一种用于对包括第一网络设备和第二网络设备的网络系统中的安全联盟(securityassociation，sa)进行密钥更新的网络设备，第一网络设备与第二网络设备之间建立有因特网密钥交换(internetkeyexchange，ike)隧道和因特网协议安全(internetprotocolsecurity，ipsec)隧道。在本方面中，网络设备用作第一网络设备，并且包括发送模块、接收模块和密钥更新模块。发送单元用于向第二网络设备发送用于对sa进行密钥更新的第一密钥更新请求，其中，第一密钥更新请求中携带第一安全参数索引(securityparameterindex，spi)和与第一网络设备相关联的加密套件。接收模块用于接收来自第二网络设备的第一密钥更新响应，其中，当与第二网络设备相关联的加密套件没有发生变化时，第一密钥更新响应中携带第二spi且不携带与第二网络设备相关联的加密套件。密钥更新模块用于根据第一spi和第二spi对sa进行密钥更新。在上述技术方案中，密钥更新响应中不携带加密套件，以减小在密钥更新中的载荷的大小，从而在例如ikesa密钥更新和ipsecsa密钥更新的密钥更新过程中节省带宽、处理时间和功率。根据第四方面，本申请实施例提供了一种用于对包括第一网络设备和第二网络设备的网络系统中的安全联盟(securityassociation，sa)进行密钥更新的网络设备，第一网络设备与第二网络设备之间建立有因特网密钥交换(internetkeyexchange，ike)隧道和因特网协议安全(internetprotocolsecurity，ipsec)隧道。在本方面中，网络设备用作第二网络设备，并且包括接收模块、确定模块、发送模块和密钥更新模块。接收模块用于接收来自第一网络设备的用于对sa进行密钥更新的第一密钥更新请求，其中，第一密钥更新请求中携带第一安全参数索引(securityparameterindex，spi)和与第一网络设备相关联的加密套件。确定模块用于确定与第二网络设备相关联的加密套件是否发生变化。发送模块用于向第一网络设备发送第一密钥更新响应，当与第二网络设备相关联的加密套件没有发生变化时，第一密钥更新响应中携带第二spi且不携带与第二网络设备相关联的加密套件。密钥更新模块用于根据第一spi和第二spi对sa进行密钥更新。在上述技术方案中，密钥更新响应中不携带加密套件，以减小在密钥更新中的载荷的大小，从而在例如ikesa密钥更新和ipsecsa密钥更新的密钥更新过程中节省带宽、处理时间和功率。根据第五方面，本申请实施例提供了一种对包括第一网络设备和第二网络设备的网络系统中的安全联盟(securityassociation，sa)进行密钥更新的方法，其中，第一网络设备与第二网络设备之间建立有因特网密钥交换(internetkeyexchange，ike)隧道和因特网协议安全(internetprotocolsecurity，ipsec)隧道。该方法中，第一网络设备向第二网络设备发送用于对sa进行密钥更新的第一密钥更新请求。在与第一网络设备相关联的加密套件没有发生变化的情况下，第一密钥更新请求中携带第二安全参数索引(securityparameterindex，spi)且不携带与第一网络设备相关联的加密套件。第一网络设备接收来自第二网络设备的第一密钥更新响应。当与第二网络设备相关联的加密套件没有发生变化的情况下，第一密钥更新响应中携带第二spi且不携带与第二网络设备相关联的加密套件。第一网络设备根据第一spi和第二spi对sa进行密钥更新。在上述技术方案中，密钥更新响应中不携带加密套件，以减小在密钥更新中的载荷的大小，从而在例如ikesa密钥更新和ipsecsa密钥更新的密钥更新过程中节省带宽、处理时间和功率。根据第六方面，本申请实施例提供了一种对包括第一网络设备和第二网络设备的网络系统中的安全联盟(securityassociation，sa)进行密钥更新的方法，其中，第一网络设备与第二网络设备之间建立有因特网密钥交换(internetkeyexchange，ike)隧道和因特网协议安全(internetprotocolsecurity，ipsec)隧道。该方法中，第二网络设备接收来自第一网络设备的用于对sa进行密钥更新的第一密钥更新请求。在与第一网络设备相关联的加密套件没有发生变化的情况下，第一密钥更新请求中携带第二安全参数索引(securityparameterindex，spi)且不携带与第一网络设备相关联的加密套件。第二网络设备向第一网络设备发送第一密钥更新响应。当与第二网络设备相关联的加密套件没有发生变化的情况下，第一密钥更新响应中携带第二spi且不携带与第二网络设备相关联的加密套件。第二网络设备根据第一spi和第二spi对sa进行密钥更新。在上述技术方案中，密钥更新请求和密钥更新响应中不携带加密套件，以减小在密钥更新中的载荷的大小，从而在例如ikesa密钥更新和ipsecsa密钥更新的密钥更新过程中节省带宽、处理时间和功率。在ikesa密钥更新场景和ipsecsa密钥更新场景下，在密钥更新过程中，在有多个加密套件的场景下，载荷大小成比例地减小。根据第七方面，本申请实施例提供了一种用于对包括第一网络设备和第二网络设备的网络系统中的安全联盟(securityassociation，sa)进行密钥更新的网络设备，第一网络设备与第二网络设备之间建立有因特网密钥交换(internetkeyexchange，ike)隧道和因特网协议安全(internetprotocolsecurity，ipsec)隧道。在本方面中，网络设备用作第一网络设备，并且包括发送模块、接收模块和密钥更新模块。发送模块用于向第二网络设备发送用于对sa进行密钥更新的第一密钥更新请求，其中，在与第一网络设备相关联的加密套件没有发生变化的情况下，第一密钥更新请求中携带第一安全参数索引(securityparameterindex，spi)，且不携带与第一网络设备相关联的加密套件。接收模块用于从第二网络设备接收第一密钥更新响应，其中，在与第二网络设备相关联的加密套件没有发生变化的情况下，第一密钥更新响应中携带第二spi且不携带与第二网络设备相关联的加密套件。密钥更新模块用于根据第一spi和第二spi对sa进行密钥更新。在上述技术方案中，密钥更新响应中不携带加密套件，以减小在密钥更新中的载荷的大小，从而在例如ikesa密钥更新和ipsecsa密钥更新的密钥更新过程中节省带宽、处理时间和功率。根据第八方面，本申请实施例提供了一种用于对包括第一网络设备和第二网络设备的网络系统中的安全联盟(securityassociation，sa)进行密钥更新的网络设备，第一网络设备与第二网络设备之间建立有因特网密钥交换(internetkeyexchange，ike)隧道和因特网协议安全(internetprotocolsecurity，ipsec)隧道。在本实施例中，该网络设备用作第二网络设备，并且包括接收模块、发送模块和密钥更新模块。接收模块用于接收来自第一网络设备的用于对sa进行密钥更新的第一密钥更新请求。在与第一网络设备相关联的加密套件没有发生变化的情况下，第一密钥更新请求中携带第二安全参数索引(securityparameterindex，spi)且不携带与第一网络设备相关联的加密套件。发送模块用于向第一网络设备发送第一密钥更新响应。在与第二网络设备相关联的加密套件没有发生变化的情况下，第一密钥更新响应中携带第二spi且不携带与第二网络设备相关联的加密套件。密钥更新模块用于根据第一spi和第二spi对sa进行密钥更新。在上述技术方案中，密钥更新响应中不携带加密套件，以减小在密钥更新中的载荷的大小，从而在例如ikesa密钥更新和ipsecsa密钥更新的密钥更新过程中节省带宽、处理时间和功率。根据第九方面，本申请实施例提供一种用于对安全联盟(securityassociation，sa)进行密钥更新的网络系统，其中，该网络系统包括根据第三方面的第一网络设备和根据第四方面的第二网络设备。根据第十方面，本申请实施例提供一种用于对安全联盟(securityassociation，sa)进行密钥更新的网络系统，其中，该网络系统包括根据第七方面的第一网络设备和根据第八方面的第二网络设备。在上述技术方案中，密钥更新请求和密钥更新响应中不携带加密套件，以减小在密钥更新中的载荷的大小，从而在例如ikesa密钥更新和ipsecsa密钥更新的密钥更新过程中节省带宽、处理时间和功率。在ikesa密钥更新场景和ipsecsa密钥更新场景下，在密钥更新过程中，在有多个加密套件的场景下，载荷大小成比例地减小。根据第十一方面，本申请实施例提供一种网络设备，用于对包括第一网络设备和第二网络设备的网络系统中的安全联盟(securityassociation，sa)进行密钥更新。第一网络设备与第二网络设备之间建立有因特网密钥交换(internetkeyexchange，ike)隧道和因特网协议安全(internetprotocolsecurity，ipsec)隧道。在本方面中，网络设备用作第一网络设备。该网络设备包括处理器和存储器。存储器用于存储软件的指令。处理器用于执行存储器中的软件的指令，并使第二网络设备执行根据如上所述的第一方面或第五方面的方法。根据第十二方面，本申请实施例提供一种网络设备，用于对包括第一网络设备和第二网络设备的网络系统中的安全联盟(securityassociation，sa)进行密钥更新。第一网络设备与第二网络设备之间建立有因特网密钥交换(internetkeyexchange，ike)隧道和因特网协议安全(internetprotocolsecurity，ipsec)隧道。在本方面中，网络设备用作第二网络设备。该网络设备包括处理器和存储器。存储器用于存储软件的指令。处理器用于执行存储器中的软件的指令，并使第二网络设备执行根据如上所述的第二方面或第六方面的方法。在上述技术方案中，密钥更新请求和密钥更新响应中不携带加密套件，以减小在密钥更新中的载荷的大小，从而在例如ikesa密钥更新和ipsecsa密钥更新的密钥更新过程中节省带宽、处理时间和功率。在ikesa密钥更新场景和ipsecsa密钥更新场景下，在密钥更新过程中，在有多个加密套件的场景下，载荷大小成比例地减小。根据第十三方面，本申请实施例提供了一种计算机可读存储介质。该计算机可读存储介质用于存储用于执行根据如上所述的第一方面的方法、第二方面、第五方面和第六方面的方法的计算机软件指令。在上述技术方案中，密钥更新请求和密钥更新响应中不携带加密套件，以减小在密钥更新中的载荷的大小，从而在例如ikesa密钥更新和ipsecsa密钥更新的密钥更新过程中节省带宽、处理时间和功率。在ikesa密钥更新场景和ipsecsa密钥更新场景下，在密钥更新过程中，在有多个加密套件的场景下，载荷大小成比例地减小。在结合附图阅读本公开的以下特定实施例的描述后，本发明的其它方面和特征对于本领域普通技术人员将变得显而易见。附图说明该详细描述是参考附图进行描述的。在附图中附图标记最左边的数字表示该附图标记首次出现的附图。所有附图使用相同数字指代相同特征和部件。图1a示出了根据传统技术的一些sa载荷的结构。图1b为根据传统技术的ikesa密钥更新流程图。图1c示出了删除请求的结构的示例。图2示出了根据传统技术的ipsecsa密钥更新。图3a为根据本公开实施例的在发起方和响应方之间协商轻量级密钥更新的支持的流程图。图3b示出了通知载荷的结构的示例。图4为根据本公开实施例的在发起方和响应方之间协商轻量级密钥更新的支持的另一流程图。图5为根据本公开实施例的在发起方和响应方之间协商轻量级密钥更新的支持的另一流程图。图6为根据本公开的一个实施例的使用轻量级密钥更新方法对sa进行密钥更新的流程图。图7a为根据本公开的一个实施例的使用轻量级密钥更新方法对ikesa进行密钥更新的流程图。图7b示出了ikesa密钥更新请求报文格式的示例。图7c示出了ike的new_spi载荷的示例。图7d示出了ike的轻量级sa载荷的示例。图7e示出了没有被选提议通知载荷的结构的示例。图8为根据本公开的一个实施例的在特定场景下对ikesa进行密钥更新的流程图。图9为根据本公开的另一实施例的使用轻量级密钥更新方法对ikesa进行密钥更新的另一流程图。图10a为根据本公开的一个实施例的使用轻量级密钥更新方法对ipsecsa进行密钥更新的流程图。图10b示出了ipsecsa密钥更新请求报文格式的示例。图10c示出了ah的new_spi载荷的示例。图10d示出了轻量级sa的两个示例，它们是新定义的ipsecsa的载荷。图11为根据本公开的一个实施例的在特定场景下对ipsecsa进行密钥更新的流程图。图12为根据本公开的另一实施例的使用轻量级密钥更新方法对ipsecsa进行密钥更新的另一流程图。图13为根据本公开实施例的网络设备用作对sa进行密钥更新的发起方的示意图。图14为根据本公开实施例的网络设备用作对sa进行密钥更新的响应方的示意图。图15为根据本公开的另一实施例的网络设备用作对sa进行密钥更新的响应方的示意图。图16为根据本公开的实施例的网络设备用作对sa进行密钥更新的发起方或响应方的示意图。图17为根据本公开实施例的用于对sa进行密钥更新的网络系统的示意图。具体实施方式本发明可以以多种方式实现，例如过程、装置、系统、计算机可读介质(例如计算机可读存储介质)，或计算机网络，其中，程序指令通过各种类型的光学或电子通信链路进行发送。在本说明书中，这些实现方式或者本发明可以采取的任何其它形式可以称为技术。通常，所公开过程的步骤的顺序可以在本发明的范围内进行更改。下面提供本发明的一个或多个实施例的详细描述以及示出本发明的原理的附图。虽然本发明是结合这些实施例进行描述的，但本发明不限于任何实施例。本发明的范围仅由权利要求书限制，并且本发明包括许多替代方案、修改和等同物。以下描述中阐述了许多具体细节，以便透彻地理解本发明。提供这些细节是为了举例的目的，并且本发明可以在没有部分或者所有这些具体细节的情况下根据权利要求书进行实践。为清楚起见未详细描述有关本发明的
技术领域：
：中已知的技术资料以免对本发明产生不必要的混淆。以下详细描述中阐述了许多具体细节，以便透彻地理解本发明。但是，本领域的技术人员应理解，在没有这些特定细节的情况下，依然可以实践本公开。在其它情况下，未详细描述公知的方法、过程、组件、模块、单元和/或电路，以免混淆本发明。尽管本发明的实施例不限于此，但使用例如处理、计算、确定、建立、创建、检查等术语进行的讨论，可以指计算机、计算平台、计算系统或其它电子计算设备的操作和/或过程，该操作和/或过程将数据(该数据表示为计算机寄存器和/或存储器内的物理(例如，电子)量)操纵和/或转换成其它数据，该其它数据类似地表示为计算机寄存器和/或存储器，或可以存储指令以执行操作和/或过程的其它信息非暂时性存储介质内的物理量。图1为在第一网络设备(例如，请求方或某个时间称为发起方)与第二网络设备(例如，响应方)之间建立了ike和ipsecsa之后，进行密钥更新的流程图。在本公开实施例中，第一网络设备或第二网络设备可以包括计算机、移动设备(例如，移动电话)、远程健康监视设备、网关、路由器、服务器、嵌入传感器的接入点(accesspoint，ap)设备、具有ip堆栈的家庭或个人设备中的任一个。特别地，网络设备中的一个可以是电源、处理能力或带宽能力有限的设备。本发明对于这种情况特别有利，因为载荷的大小和/或数量可以整体减小，从而节省了处理功率、时间，并因此节省了功耗。同样，在本公开实施例中，网络设备中的另一个可以是安全网关/epdg或基于cran/cloud的设备，其可以支持多个ike/ipsec隧道。在这种情况下，通过减少传输的数据，可以减少带宽和数据包分片，从而降低处理要求。在执行包括ike_sa_init和ike_auth交换(操作102至108)的初始交换之后建立ikesa和ipsecsa(操作110)。这些初始交换通常包括四个消息，不过在某些场景下，这个数字会增加。第一对消息(ike_sa_init)协商加密套件、交换随机数和diffie-hellman(diffie-hellman，dh)。第二对消息(ike_auth)认证之前的消息，交换身份和证书，协商加密套件和流量选择器(trafficselector，ts)，建立第一子sa。使用通过ike_sa_init交换建立的密钥对这些消息的一部分进行加密和完整性保护。使用ike_sa_init交换中协商的加密算法和密钥对初始交换后的消息进行加密保护。对于ikesa和ipsecsa中的每一个，密钥的使用时间通常有限，这个时间可以称为sa的生命周期。当生命周期即将到期时，通过创建新sa并删除旧sa来对sa进行密钥更新。对于初始交换的详细过程，本领域技术人员参考rfc7296，rfc7296的全部内容通过引用结合在本申请中，除了与本文的明确公开内容相反的地方。在建立ikesa和ipsecsa之后(操作110)，如果ikesa的生命周期和ipsecsa的生命周期中的任一个即将到期，则第一网络设备和第二网络设备执行sa密钥更新过程。应理解，第一网络设备或第二网络设备都可以发起sa密钥更新请求，因为每个设备都可以在其自身侧维护生命周期策略，该生命周期策略管理sa的生命周期。在另一个实施例中，两侧所共享的sa可以具有相同的生命周期。第一网络设备或第二网络设备可以周期性地触发sa密钥更新。在其它场景下，设备可以检测到与该设备相关联的每个sa的到期时间，然后，如果该设备检测到ikesa或ipsecsa的密钥即将到期，则发起sa密钥更新过程。顾名思义，sa密钥更新是指创建一个具有与当前sa相同属性的新密钥的sa，除非策略发生变化。更改策略可以是，在子sa密钥更新的情况下，最终用户更改加密策略(也可以称为加密套件)和/或加密套件的生命周期，或最终用户更改流策略(也可以称为流信息)。流信息可以包括源和目的ip地址、端口范围或端口号等。对sa进行密钥更新包括重新创建该sa的密钥，即更改密钥，已建立的sa的其它元素可以更改，也可以不更改。以发起ikesa密钥更新的第一网络设备为例。第一网络设备向第二网络设备发送用于对ikesa进行密钥更新的密钥更新请求。在一个实施例中，create_child_sa交换用于对ikesa进行密钥更新。该交换包括一对请求/响应。sa密钥更新可以由ikesa的任一端(例如，第一网络设备或第二网络设备)在初始交换完成之后发起。发起sa密钥更新的一端可以看作是发起方，发起方的对端侧可以看作是响应方。根据一个实施例，对ikesa进行密钥更新可以包括至少如下操作：操作112：发起方向响应方发送用于对ikesa进行密钥更新的create_child_sa请求。create_child_sa请求包含hdr，hdr是ike头(不是载荷)和载荷。载荷包括sa载荷、ni载荷和kei载荷。sa载荷包括sa提供，例如发起方支持的一个或多个加密套件。加密套件可以包括用于密钥计算的认证算法、加密算法和/或dh组。此外，sa载荷还可以包括在sa载荷的spi字段中提供的新发起方安全参数索引(securityparameterindex，spi)。sa载荷中的新发起方spi将由响应方获取，并在响应方侧计算新密钥。ni载荷包括随机数，kei载荷包括diffie-hellman值。在本公开中，术语“加密套件”是指用于保护sa的一组算法。在ipsecsa或ikesa的情况下，加密套件在某些情况下也可以调用ipsec安全提议或ike安全提议。新发起方spi可以用于在发起方侧进行密钥更新之后标识新ikesa。操作114：响应方接收到用于对ikesa进行密钥更新的请求后，响应方向发起方发送用于对ikesa进行密钥更新的create_child_sa响应。create_child_sa响应包括hdr和载荷，载荷包括sa载荷、nr载荷和ker载荷。sa载荷在sa载荷的spi字段中包括新响应方spi。sa载荷还包括响应方从发起方的提供中选择的加密套件。nr载荷包括随机数，如果所选择的加密套件包括该组，则ker载荷包括diffie-hellman值。新响应方spi可以用于在响应方侧进行密钥更新之后标识新ikesa。因此，新响应方spi和新发起方spi的组合用于标识新ikesa。此外，sa载荷中的新响应方spi由发起方获取，并在发起方侧计算新密钥。操作116：建立新ikesa。新ikesa用于保护ike控制报文。新ikesa，即密钥更新后的ikesa，继承该ikesa的所有子sa，这意味着密钥更新成功之后，与旧ikesa链接的现有子sa将被移动到新ikesa中。在如操作112和114中所示的ikecreate_child_sa交换之后，用新密钥和所选择的加密套件创建新ikesa，并用新发起方spi和新响应方spi标识该新ikesa，如上所述，新发起方spi和新响应方spi是在sa载荷中交换的。操作118：发起方向响应方发送旧ikesa删除请求，以删除旧sa。其中，旧ike删除请求可以包括hdr和d载荷。d载荷可以包括指示待删除的sa的协议标识符(protocolidentifier，id)等信息。sa的删除可以根据rfc7296、通过发起方与响应方之间的informational交换实现。例如，图1c示出了根据rfc7296的删除请求的结构的示例。操作120：响应方接收到旧ikesa删除请求后，向发起方发送旧ikesa删除响应。旧ikesa删除响应可以包括hdr和d载荷。d载荷可以包括指示待删除的sa的协议id等信息。sa的删除可以根据rfc7296、通过发起方与响应方之间的informational交换实现。参考图2，提供了第一网络设备发起子sa或ipsecsa密钥更新的实施例。与ikesa密钥更新相同，create_child_sa交换也可以用于对子sa进行密钥更新。本实施例中，对ikesa进行密钥更新至少可以包括如下操作：操作202至210可以参考操作102至110。操作212：发起方向响应方发送用于对子sa进行密钥更新的create_child_sa请求。create_child_sa请求包括hdr(是ike头)和载荷。载荷包括n(rekey_sa)载荷、sa载荷、ni载荷、tsi和tsr载荷以及可选的kei载荷。rekey_sa载荷在rfc7296中进行了定义，用于通知其它对端正在对现有子sa进行密钥更新。rekey_sa载荷的spi字段中添加了正在被进行密钥更新的现有子sa的spi，响应方可以使用所包含的spi来标识sa。此外，rekey_sa载荷的协议id字段设置为与待进行密钥更新的sa的协议相匹配，例如esp设置为3，ah设置为2。sa载荷包括sa提供，例如发起方支持的一个或多个加密套件。sa载荷还可以包括在sa载荷的spi字段中提供的新发起方spi。新发起方spi可以用作密钥更新之后的新ipsecsa的发起方的入方向spi，并用作密钥更新之后的新ipsecsa的响应方的出方向spi。ni载荷包括随机数，可选的kei载荷包括diffie-hellman值。提出的子sa的提出的流量选择器包括在tsi载荷和tsr载荷中。流量选择器包括与待进行密钥更新的发起方相关联的流信息，流信息由发起方用于流量通信，例如地址范围(ipv4或ipv6)、端口范围和ip协议id。假设响应方接受该提议，则响应方发送回相同的ts载荷。在另一种情况下，允许响应方选择发起方所提出的流量的子集。例如，当两端的流配置正在更新，但只有一端接收到新信息时，可能会发生这种情况。由于两端可能是由不同的终端用户(例如网络管理员)配置的，所以，即使没有错误，不兼容也可能会持续很长时间。当响应方选择发起方所提出的流量的子集时，将流量选择器缩小到发起方的提议的某个子集(前提是该集没有变成空集)。操作214：响应方接收到用于对子sa进行密钥更新的请求后，响应方向发起方发送对子sa进行密钥更新的create_child_sa响应。create_child_sa响应包括hdr和载荷，载荷包括sa载荷、nr载荷、tsi和tsr载荷以及可选的ker载荷。sa载荷在sa载荷的spi字段中包括新响应方spi。新响应方spi可以用作密钥更新之后的新ipsecsa的响应方的入方向spi，并用作密钥更新之后的新ipsecsa的发起方的出方向spi。sa载荷还包括响应方从发起方的提供中选择的加密套件。nr载荷包括随机数，如果所选择的加密套件包括该组，则ker载荷包括diffie-hellman值。如上所述，响应方可以将相同的ts载荷发送回发起方，或者也可以选择发起方所提出的流量的子集，并将其发送回发起方。在一个实施例中，响应方如下所述执行缩小过程：如果响应方的策略不允许接受提出的流量选择器的任何部分，则响应ts_unacceptable通知消息。如果响应方的策略允许tsi和tsr覆盖的整个流量集，则不需要进行缩小，响应方可以返回相同的tsi和tsr值。如果响应方的策略允许接受tsi和tsr的第一选择器，则响应方将流量选择器缩小到包括发起方的第一选择的子集。如果响应方的策略不允许接受tsi和tsr的第一选择器，则响应方缩小到tsi和tsr的可接受的子集。操作216：创建新ipsecsa。建立新ipsecsa之后，新ipsecsa，即密钥更新之后的ipsecsa，被添加到ikesa中，待进行密钥更新的ipsecsa与该ikesa相关联，这意味着ikesa与其对应的子sa之间存在链接。因此，将密钥更新之后创建的子sa添加到ikesa中。在如操作212和214中所示的ikecreate_child_sa交换之后，用新密钥和所选择的加密套件创建新ipsecsa，并用新发起方spi和新响应方spi标识该新ipsecsa，如上所述，新发起方spi和新响应方spi是在sa载荷中交换的。操作218：发起方向响应方发送旧子sa删除请求以删除旧sa。旧子删除请求可以包括hdr和d载荷。d载荷可以包括指示待删除的sa的协议id等信息。sa的删除可以根据rfc7296、通过发起方与响应方之间的informational交换实现。操作220：响应方接收到旧子sa删除请求后，向发起方发送旧子sa删除响应。旧子sa删除响应可以包括hdr和d载荷。d载荷可以包括指示待删除的sa的协议id等信息。sa的删除可以根据rfc7296、通过发起方与响应方之间的informational交换实现。从上述图1和图2的现有技术方法中可知，在对ikesa进行密钥更新时，发起方与响应方之间的交换包括包含一个或多个加密套件的sa载荷，即使与对sa进行密钥更新相关联的加密策略(例如，加密套件)没有发生变化时也是如此。换言之，即使发起方和/或响应方更改与其相关联的加密套件，发起方与响应方之间的密钥更新交换仍然包括包含一个或多个加密套件的sa载荷。对于ipsecsa密钥更新，在进行密钥更新时，发起方与响应方之间的交换包括包含一个或多个加密套件的sa载荷，以及tsi和tsr载荷，即使与对sa进行密钥更新和流策略相关联的加密策略没有发生变化时也是如此。由于对sa进行密钥更新是周期性地触发的，因此需要消耗带宽和功率来处理这些载荷。在有多个加密套件的情况下，问题变得更加严重，因为在ikesa和ipsecsa中，在有多个加密套件的情况下，载荷大小成比例增加。例如，对于使用低功耗技术的物联网(internetofthings，iot)设备，减小ikev2消息的大小是非常理想的。对于某些此类设备，通过网络传输额外比特的功耗相当高。许多这样的设备都是由电池供电的，没有能力进行再充电，或没有能力对务于设备生命周期(通常是几年)的电池进行更换。因此，降低此类设备的功耗的任务非常重要。此外，大型udp消息也可能在ip层面造成分片，从而可能与网络地址转换器(networkaddresstranslator，nat)交互不良。特别是，某些nat会丢弃不包含tcp/udp端口号的ip分片(非初始ip分片)。大多数iot设备有单组套件，或者它们不希望在进行密钥更新时更改所选择的套件。在一个示例中，在用create_child_sa交换对ikesa进行密钥更新的情况下，sa载荷(单组加密套件)的最小大小为52字节。而在本发明实施例中，用通知载荷n(new_spi)替换这些载荷，以获得大小为16字节的spi。节省了36字节。在另一示例中，在用create_child_sa交换对子sa进行密钥更新的情况下，sa载荷的最小大小为40字节，每个ts大小为24字节(2*24＝48字节)，因此，总大小为88字节。而在本发明的实施例中，用通知载荷n(new_spi)替换这些载荷，以获得大小为12字节的spi，因此总共节省了76字节。本公开提供一种轻量级密钥更新方案来解决上述问题。在该方案中，在加密策略不变的情况下，ike密钥更新和ipsecsa密钥更新过程中，发起方与响应方之间的交换均不携带sa载荷。相反，例如在本文称为“new_spi通知”的新通知类型载荷(可以代替现有的sa载荷)中，或者在本文称为“轻量级sa载荷”的新载荷中，或者在用于发送spi的任何其它载荷中，传送该spi。new_spi通知使用的比特数比现有的sa载荷少。另一种节省传输比特的方式是，当流信息没有发生变化时，在对ipsecsa进行密钥更新时，发起方与响应方之间的交换也不带ts载荷。例如，“轻量级sa载荷”格式可以仅包含sa载荷头和提议载荷。因此，与传统载荷(例如在sai1和sar1中发送的那些载荷)相比，该载荷是被修整过的。为了实现轻量级密钥更新方法，两端可以交换它们各自执行轻量级密钥更新方法的能力。该交换可以在密钥更新过程之前执行，例如，在如上所述的建立ike或ipsecsa的初始交换期间执行。根据本公开的一个实施例，轻量级密钥更新的能力的交换可以包括两个对端之间的以下操作：发起方向第二网络设备发送通知，用于指示发起方支持轻量级密钥更新，例如支持密钥更新可选载荷。响应方发送响应，用于指示响应方也支持轻量级密钥更新，例如支持密钥更新可选载荷。通过这个初始支持过程，两端可以相互知道对端是否支持轻量级密钥更新方法。图3a至图5示出了在发起方与响应方之间协商轻量级密钥更新支持的三种不同方式。这三种方式都使用初始交换过程来实现轻量级的密钥更新协商。如上所述，本公开并不限定仅使用初始交换过程来实现轻量级密钥更新协商，本领域技术人员在阅读本公开之后可以设想到其它方式。在如图3a所示的实施例中，支持轻量级密钥更新通知携带在发起方发送给响应方的init请求(例如ike_sa_init请求消息)中的通知载荷中，相应地，支持轻量级密钥更新的确认携带在响应方发送给发起方的init响应(例如，ike_sa_init响应消息)的通知载荷中。例如，图3b示出了通知载荷的结构，其中，通知消息类型为ikev2_rekey_optional_payload_supported，它是一种不同于传统通知载荷的新通知消息类型。新通知消息类型(例如ikev2_rekey_optional_payload_supported)包含在通知载荷中，并指示发起方或响应方支持轻量级密钥更新。在如图4所示的实施例中，支持轻量级密钥更新的通知携带在发起方发送给响应方的auth请求(例如，ike_sa_auth请求消息)中的通知载荷中，相应地，在响应方发送给发起方的auth请求(例如ike_sa_auth响应消息)的通知载荷中携带支持轻量级密钥更新的通知。通知载荷的类型可以是ikev2_rekey_optional_payload_supported载荷。在如图5所示的实施例中，支持轻量级密钥更新的通知携带在发起方发送给响应方的init请求(例如，ike_sa_init请求消息)的通知载荷中，相应地，在响应方发送给发起方的auth响应(例如ike_sa_auth响应消息)的通知载荷中携带支持轻量级密钥更新的通知。通知载荷的类型可以是ikev2_rekey_optional_payload_supported载荷。应注意，可以不在密钥更新过程(例如在ikeinit或auth期间)之前进行轻量级密钥更新协商，这意味着双方未就此达成协议，那么，如果发起方或响应方中的任一方不被允许发送new_spi或轻量级sa载荷，则另一方可以丢弃并视为错误。图6为使用轻量级密钥更新方法对sa进行密钥更新的流程图。在发起方与响应方之间建立ikesa和ipsecsa之后，如果根据每端的sa生命周期策略，ikesa和ipsecsa中的任一个的生命周期接近到期，则发起方发起密钥更新过程，该过程可以包括如下操作：操作602：发起方确定与发起方相关联的加密套件是否发生变化。在本公开中，与发起方相关联的加密套件意味着加密套件受发起方支持并用于由发起方建立的特定sa，例如在sa密钥更新情况下密钥更新后的sa(即，新sa)。在建立与弱加密套件相关联的sa之后，如果任何一个sa的生命周期即将到期，则发起方希望通过创建新sa并删除待进行密钥更新的sa(也可以称为旧sa)来对sa进行密钥更新，可以更改或不更改用于旧sa的加密套件(也可以称为与旧sa相关联的加密套件)。换言之，与发起方相关联的加密套件未发生变化意味着旧sa所使用的加密套件仍然可用于密钥更新后的sa(即新sa)。与发起方相关联的加密套件发生了变化意味着将与旧sa相关联的加密套件更改为另一个加密套件，该另一个加密套件受发起方支持并用于新sa(即与新sa相关联)。下面提供一些与发起方相关联的加密套件发生变化的情况。一种情况是发起方支持的加密套件发生了发生变化。例如，发起方当前仅支持第一加密套件(例如，弱加密套件)。在建立旧sa之后，由于某些原因(例如，发起方扮演更重要的角色，具有更高的安全要求)，网络管理员通过用户界面配置发起方，将发起方对加密套件的支持更改为第二加密套件(强加密套件)。加密套件被更改之后，如果发起方希望对旧sa进行密钥更新，则需要更改新sa的加密套件，因为发起方目前只支持强加密套件。另一种情况是没有更改发起方支持的加密套件。例如，发起方当前支持两个或多个加密套件。在进行密钥更新时，出于某些原因，例如对sa的要求提高了(这需要更强的加密套件用于新sa)，发起方希望使用新sa的新加密套件，而不是使用与旧sa相关联的加密套件。在这种情况下，发起方向响应方发送的密钥更新请求需要携带新sa的第二加密套件，因为与旧sa相关联的第一加密套件不再与新sa相关联。图7a至图12的描述中公开了详细的实现方式。进一步，另一种情况是，如果发起方只支持第一加密套件，例如弱加密套件，并且发起方在对旧sa进行密钥更新时，出于某些原因，希望将第一加密套件更改为第二加密套件(例如，更改为强加密套件)。在这种情况下，需要重新配置发起方，因为发起方目前只支持第一加密套件。网络管理员可以选择重新配置发起方，使其支持第二加密套件，或者同时支持第一加密套件和第二加密套件。并且将该配置存储在发起方或一些其它数据库或设备中。例如，发起方与发起方所支持的加密套件之间存在对应关系，该对应关系可以存储在发起方或一些其它地方。响应方侧的配置过程与上面的配置过程类似。在重新配置之后，发起方可以选择支持的第二加密套件，并将第二加密套件放在用于sa密钥更新交换的密钥更新请求中。以下提供一些与发起方相关联的加密套件没有发生变化的情况。一种情况是，发起方只支持第一加密套件，例如弱加密套件，并且发起方希望在对旧sa进行密钥更新时能让第一加密套件发生变化(即第一加密套件仍然用于密钥更新后的sa)，发起方向响应方发送的密钥更新请求中不携带新sa的加密套件，因为与旧sa相关联的第一加密套件仍然与新sa相关联。另一种情况是发起方支持两个或多个加密套件，例如第一加密套件(例如，弱加密套件)和第二加密套件(例如，强加密套件)，并且发起方不希望在对旧sa进行密钥更新时将第一加密套件更改为第二加密套件。在这种情况下，发起方发送给响应方的密钥更新请求不需要携带新sa的加密套件，因为与旧sa相关联的第一加密套件仍然用于新sa。详细实现方式请参考图7a至图12的描述。操作604：当与发起方相关联的加密套件没有发生变化时，发起方向响应方发送用于对sa进行密钥更新的第一密钥更新请求。如上所述，与发起方相关联的加密套件没有发生变化意味着旧sa所使用的加密套件仍然可用于密钥更新后的sa(即，新sa)。发起方不需要携带新sa的加密套件。第一密钥更新请求中携带第一spi，且不携带与发起方相关联的加密套件，因为在建立sa之后，发起方不会更改加密套件；或者发起方更改过加密套件，更改后的加密套件恢复为原来的加密套件，且当前的加密套件与建立sa时的加密套件相同。ike密钥更新场景下，第一spi为新发起方spi。因为ikesa可以通过两端的一对spi来标识。因此，当一端发起密钥更新过程时，密钥更新请求中包含新spi，新spi用作密钥更新之后的新ikesa的发起方spi。当响应方在回应中响应ike密钥更新时，响应方在密钥更新响应中添加新spi，该spi用作密钥更新之后的新ikesa的响应方spi。在ipsecsa密钥更新场景下，第一spi用作密钥更新之后的新ipsecsa的发起方的入方向spi，并用作密钥更新之后的新ipsecsa的响应方的出方向spi。此外，如上所述，第一密钥更新请求中还携带n[rekey_sa]载荷的spi，以标识待进行密钥更新的sa。该操作的详细实现方式可以参考以下如图7至图9所示的ike密钥更新过程。操作606：响应方向发起方发送第一密钥更新响应。当与响应方相关联的加密套件没有发生变化时，第一密钥更新响应中携带第二spi且不携带与第二网络设备相关联的加密套件。如上所述，在ike密钥更新场景中，第二spi是新响应方spi。当响应方在回应中响应ike密钥更新时，响应方在密钥更新响应中添加新响应方spi，该响应方spi用作密钥更新之后的新ikesa的响应方spi。在ipsecsa密钥更新场景下，第二spi用作密钥更新之后的新ipsecsa的响应方的入方向spi，并用作密钥更新之后的新ipsecsa的发起方的出方向spi。该操作的详细实现方式可以参考以下如图8至图10所示的ike密钥更新过程。操作608：当与第一网络设备相关联的加密套件和与第二网络设备相关联的加密套件没有发生变化时，发起方根据第一spi和第二spi对sa进行密钥更新。进行密钥更新包括创建新sa并删除待进行密钥更新的旧sa。具体地，发起方使用发起方spi、响应方spi和未更改的加密套件对sa进行密钥更新，未更改的加密套件用于旧sa获取新sa的新密钥。详细实现方式可以参考以下如图7至图9所示的ike密钥更新过程。图7a为根据本公开实施例的对ikesa进行密钥更新的流程图。在本实施例中，发起方不更改建立待进行密钥更新的sa时所使用的加密套件，例如，具有较高加密算法集的较强的加密套件。在本实施例中，有两种场景，第一种场景是响应方也不更改加密套件。第二种场景是响应方希望更改加密套件。根据本实施例的第一种场景，ike密钥更新过程包括如下操作：操作702：发起方向响应方发送init请求。init请求中除了携带上述正常的hdr头和载荷之外，还携带通知载荷。在本实施例中，通知载荷为ikev2_rekey_optional_payload_supported载荷，其指示发起方支持轻量级密钥更新。操作704：响应方向发起方发送init响应。init响应中除了携带上述正常的hdr头和载荷之外，还携带通知载荷。在本实施例中，通知载荷为ikev2_rekey_optional_payload_supported载荷，其指示响应方支持轻量级密钥更新方法。根据所讨论的初始交换，执行操作706和708之后，在发起方和响应方之间建立ikesa和ipsecsa。应理解，图3至图5中所描述的协商轻量级密钥更新能力的其它方式也可以应用于本实施例。操作710：建立ikesa和ipsecsa，发起方周期性地触发ike密钥更新。发起方可以周期性地检测ikesa的生命周期是否即将到期。如上所述，发起方可以在发起方侧维护生命周期策略。生命周期策略可以针对不同的sa设置不同的生命周期。当发起方检测到ikesa的生命周期即将到期时，执行操作712。操作712：发起方向响应方发送用于对ikesa进行密钥更新的create_child_sa请求。create_child_sa请求包括hdr头、ni载荷和kei载荷。create_child_sa请求中不携带sa载荷(sa载荷中携带一个或多个加密套件)，而是携带通知载荷，例如new_spi通知。new_spi载荷的spi字段可以携带新发起方spi且不携带加密套件。图7b示出了密钥更新请求报文格式的示例。或者，可以使用轻量级sa载荷或其它载荷来携带新发起方spi。new_spi是新定义的通知载荷，其携带发起方spi，该发起方spi标识密钥更新之后的新ikesa。例如，图7c示出了用于ike的new_spi。例如，图7d示出了ike的轻量级sa载荷。在示例中，轻量级sa载荷包含单个提议载荷，且没有转码和属性。根据这种结构，在ike密钥更新的情况下，将“spi”中提到的值用作ikesa的发起方/响应方spi。操作714：响应方向发起方发送用于对ikesa进行密钥更新的create_child_sa响应。create_child_sa响应包括hdr头、nr载荷和ker载荷。create_child_sa响应中不携带sa载荷(sa载荷中携带一个或多个加密套件)，而是携带通知载荷，例如new_spi通知。new_spi载荷的spi字段可以携带新响应方spi且不携带加密套件。操作716：创建新ikesa。具体地，如上所述，在此场景中，发起方和响应方都不更改加密套件。根据发起方spi和响应方spi以及原始加密套件创建新ikesa，该原始加密套件用于对旧sa进行密钥更新。新ikesa用于保护ike控制报文。新ikesa，即密钥更新后的ikesa，继承该ikesa的所有子sa，这意味着密钥更新成功之后，与旧ikesa链接的现有子sa将被移动到新ikesa中。操作718：发起方向响应方发送旧ikesa删除请求，以删除旧ikesa。其中，旧ike删除请求可以包括hdr和d载荷。d载荷可以包括指示待删除的旧sa的协议标识符(protocolidentifier，id)等信息。详细实现方式可以参考操作216。操作718：响应方接收到旧ikesa删除请求后，向发起方发送旧ikesa删除响应。旧ikesa删除响应可以包括hdr和d载荷。d载荷可以包括指示待删除的sa的协议id等信息。详细实现方式可以参考操作218。例如，通过使用如本实施例所描述的轻量级密钥更新方法，该new_spi通知载荷可以节省最小36字节，并且对于多个加密套件的情况，所节省的字节数成比例增加，这减少了对复杂验证的处理，从而减少了ike密钥更新交换中对sa载荷的处理。例如，new_spi通知载荷的大小可以在12至16字节范围内。图8示出了第二场景，其中，响应方更改响应方当前使用的加密套件(例如，建立待进行密钥更新的sa时使用的加密套件)。在这种情况下，在操作814中，响应方可以在create_child_sa响应中将没有被选提议通知载荷发送给发起方，而不是new_spi通知或携带更改的加密套件的sa载荷。没有被选提议通知载荷可以是no_proposal_chosen载荷，用于指示create_child_sa请求中携带的加密套件中不存在匹配加密套件。然后，发起方接收到该指示之后，会重新发送create_child_sa请求，但这次携带sa载荷(该sa载荷中携带更新后的加密套件)，以与响应方重新协商加密套件，直到发起方和响应方就加密套件达成协议。加密套件的重新协商过程可以指本公开中所描述的任一场景。下面描述重新协商的一个示例。在本示例中，操作802-812与上述操作702至712相同。但是在操作814中，create_child_sa响应中携带hdr头、通知载荷。通知载荷可以是no_proposal_chosen类型载荷，用于指示create_child_sa请求中携带的加密套件中不存在匹配加密套件。例如，图7e示出了通知载荷的结构，其中，通知消息类型为no_proposal_chosen。因此，对于本文所公开的其它新通知，使用传统的通知结构，但具有新的通知类型。然后，发起方接收到该指示之后，会重新发送create_child_sa请求，该create_child_sa请求中携带sa载荷(该sa载荷中携带更新后的加密套件)，以与响应方重新协商加密套件，直到发起方和响应方就加密套件达成协议。加密套件的重新协商过程可以指本公开中所描述的任一场景。下面描述重新协商的一个示例。然后，在操作816中，发起方向响应方重新发送create_child_sa请求。第二create_child_sa请求包括hdr头、n(rekey_sa)载荷、sa载荷、ni载荷、可选的kei载荷。ni载荷和kei载荷的内容可以参考操作212和操作712。sa载荷中携带spi字段，该spi字段中携带新发起方spi和发起方提出的一个或多个加密套件。在操作818中，响应方向发起方发送create_child_sa响应。create_child_sa响应中携带hdr头、sa载荷、nr载荷、ker载荷。操作820：创建新ikesa。该操作的实现方式可以参考如上所述的操作716。操作820：发起方向响应方发送旧ikesa删除请求，以删除旧ikesa。其中，旧ike删除请求可以包括hdr和d载荷。d载荷可以包括指示待删除的sa的协议id等信息。详细实现方式可以参考如上所述的操作216和718。操作822：响应方接收到旧ikesa删除请求后，向发起方发送旧ikesa删除响应。旧子sa删除响应可以包括hdr和d载荷。d载荷可以包括指示待删除的sa的协议id等信息。详细实现方式可以参考如上所述的操作218和720。图9为根据本公开实施例的对ikesa进行密钥更新的流程图。在本实施例中，发起方更改加密套件。本实施例中有三种场景。第一种场景是响应方不更改加密套件。例如，在这种场景下，发起方可以有两种支持套件(例如弱加密套件和强加密套件)，且希望从弱加密套件更改为强加密套件，但是响应方只支持弱加密套件且不希望更改加密套件。在这种情况下，响应方可能不会与发起方协商加密套件，而使用轻量级密钥更新方法。例如，响应方可以使用new_spi通知或轻量级sa载荷或任何其它载荷来包含响应方spi。第二种场景是响应方更改加密套件。例如，在这种场景下，发起方有两种支持套件(例如弱加密套件和强加密套件)，且希望将弱加密套件更改为强加密套件，而响应方也希望将弱加密套件(首次建立待进行密钥更新的sa时所使用的弱加密套件)更改为强加密套件。在这种情况下，响应方可以在密钥更新响应中携带sa载荷(该sa载荷中携带强加密套件)。第三种场景是响应方更改加密套件。例如，在这种场景下，发起方只有一种支持套件(例如强加密套件)，且希望将弱加密套件改为强加密套件，而响应方只支持弱加密套件。在这种情况下，响应方发送通知载荷，用于指示发起方发送的密钥更新请求中携带的加密套件中没有匹配加密套件。然后，发起方接收到该指示之后，会重新发送密钥更新请求，但这次携带sa载荷(该sa载荷中携带更新后的加密套件)，以与响应方重新协商加密套件，直到发起方和响应方就加密套件达成协议。加密套件的重新协商过程可以指本公开中所描述的任一场景。根据本实施例，ike密钥更新过程包括如下操作：操作902至910的详细实现方式可以参考图7中描述的操作702至710。操作912：发起方向响应方发送用于对ikesa进行密钥更新的create_child_sa请求。create_child_sa请求包括hdr头、sa载荷、ni载荷和kei载荷。每个载荷中携带的信息可以参考操作112。在这种情况下，例如，sa载荷中携带两种加密套件，例如弱加密套件和强加密套件。操作914：响应方向发起方发送用于对ikesa进行密钥更新的create_child_sa响应。create_child_sa响应包括hdr头、nr载荷和ker载荷。create_child_sa请求中不携带sa载荷(sa载荷中携带加密套件)，而是携带通知载荷，例如new_spi通知。new_spi载荷的spi字段中携带新响应方spi且不携带加密套件。应理解，在操作914中，作为一种可选的方式，响应方可以发送携带sa载荷的create_child_sa响应，该sa载荷中携带当前使用的(即，在建立sa时使用的)加密套件和新响应方spi，即使响应方不希望更改当前使用的加密套件时也是如此。根据本实施例的第二种场景，当响应方希望更改当前使用的加密套件时，例如，将弱加密套件更改为强加密套件。create_child_sa响应中携带sa载荷，该sa载荷中携带更改的加密套件，即强加密套件，发起方支持该更改的加密套件。操作916至918的详细实现方式可以参考图8中所描述的操作716至718和图2中所描述的操作216至218。根据本实施例的第三种场景，其中，例如，发起方只支持一个加密套件(例如，强加密套件)，并更改加密套件，例如，将弱加密套件更改为强加密套件。响应方只支持弱加密套件。在这种场景下，响应方中的加密套件与发起方提出的加密套件不匹配。在操作914中，在确定响应方与发起方之间没有与加密套件的匹配之后，响应方可以在create_child_sa响应中向发起方发送没有被选提议通知载荷，而不是sa载荷。没有被选提议通知载荷可以是no_proposal_chosen载荷，用于指示create_child_sa请求中携带的加密套件中不存在匹配加密套件。然后，发起方接收到该指示之后，重新发送create_child_sa请求，该请求中携带sa载荷，sa载荷中携带更新后的加密套件，以与响应方重新协商加密套件，直到发起方和响应方就加密套件达成协议。加密套件的重新协商过程可以指本公开中所描述的任一场景。例如，通过在ike密钥更新中引入new_spi通知载荷，可以为每个ike密钥更新节省最小36字节，从而减少对复杂验证的处理以及对sa载荷的处理。图10为根据本公开实施例的对ipsecsa进行密钥更新的流程图。在本实施例中，发起方不更改建立待进行密钥更新的sa时所使用的加密套件，例如，具有较高加密算法集的强加密套件。对于流信息，发起方可以更改流信息，也可以不更改流信息。当发起方没有更改流信息时，密钥更新请求中不需要携带ts载荷，而当发起方更改流信息时，密钥更新请求中携带流信息，以反映更改的流信息，如地址范围、端口范围、ip协议id等。在本实施例中，有两种场景，第一种场景是响应方也不更改加密套件。第二种场景是响应方更改加密套件。应理解，在ikesa和ipsecsa同时进行密钥更新情况下，操作(即，ike_sa_init或auth请求消息中的ikev2_rekey_optional_payload_supported的协商，和/或“new_spi通知”或“轻量级sa载荷”或包含spi以对sa进行密钥更新的任何其它载荷的协商)与本公开中所描述的实施例保持类似。如果同时进行密钥更新，优选独立地执行密钥更新过程，而不合并消息。根据本实施例的第一种场景，ipsec钥更新过程包括如下操作：操作1002至1010的详细实现方式可以参考图8中描述的操作802至810。操作1012：发起方向响应方发送用于对子sa进行密钥更新的create_child_sa请求。当发起方不更改流信息时，该create_child_sa请求包括hdr头、n(rekey_sa)载荷、new_spi载荷、ni载荷和可选的kei载荷，但不包括ts载荷。n(rekey_sa)载荷中携带spi，用于指示待进行密钥更新的子sa。ni载荷和kei载荷的内容可以参考操作212。create_child_sa请求中不携带sa载荷(sa载荷中携带一个或多个加密套件)，而是携带通知载荷，例如new_spi通知载荷。new_spi载荷的spi字段中携带新发起方spi且不携带加密套件。或者，可以使用轻量级sa载荷或其它载荷来携带新发起方spi。new_spi是新定义的通知载荷，其携带发起方spi，该发起方spi标识密钥更新之后的新ipsecsa。图10b示出了密钥更新请求报文格式的示例，其中示出了ipsec密钥更新请求中的新字段(例如new_spi通知载荷)。例如，图10c示出了用于ah的new_spi。例如，图10d示出了两种轻量级sa，它们是为ipsecsa新定义的载荷。如图10d所示，最上面的轻量级sa载荷包含单个提议载荷，且没有转码和属性，而下面的轻量级sa载荷包含sa捆绑。有两种创建ipsec隧道的方法。一种是使用ah或esp，另一种是同时使用ah和esp，也称为sa捆绑。在用户希望同时使用ah和esp时，使用sa捆绑。在ipsec密钥更新的情况下，将“spi”字段中提到的值用作ah/espsa的入/出方向spi。或者，当发起方更改流配置时，例如当更改密钥更新之后的新sa的ip地址范围等流信息时，除了上面提到的载荷之外，create_child_sa请求中还可以携带ts载荷。ts载荷的内容可以参考操作212。操作1014：响应方向发起方发送用于对子sa进行密钥更新的create_child_sa响应。该create_child_sa响应包括hdr头、nr载荷和可选的ker载荷(取决于create_child_sa请求中是否携带kei载荷)。create_child_sa响应中不携带sa载荷(sa载荷中携带一个或多个加密套件)，而是携带通知载荷，例如new_spi通知。new_spi载荷的spi字段可以携带新响应方spi且不携带加密套件。由于create_child_sa请求中不携带ts载荷，该ts载荷中携带与发起方相关联的流信息，所以关于响应方在create_child_sa响应中是否携带ts载荷可以有以下两种选择：第一种选择是，当与响应方相关联的流信息没有发生变化，且当前使用的流信息在密钥更新之后仍然用于新ipsecsa时，create_child_sa响应中不携带与响应方相关联的ts载荷。第二种选择是，当与响应方相关联的流信息发生变化时，create_child_sa响应中携带ts不可接受的通知。ts不可接受的通知可以是ts_unacceptable通知载荷，用于指示发起方与响应方之间信息不匹配。然后，发起方接收到ts不可接受的通知之后，重新发送create_child_sa请求，该create_child_sa请求中这次携带ts载荷，该ts载荷中携带更新后的流信息，以与响应方重新协商流信息，直到发起方和响应方就流程信息达成协议。流信息的重新协商过程可以指如本公开中所描述的加密套件协商或流信息协商的任一场景。应注意，当加密套件协商和流信息协商中的任一个在第一轮协商中失败时，两端可以在第二轮协商中同时重新协商加密套件和流信息。在这种情况下，重新发送的create_child_sa请求中可以带有或不带sa载荷，以重新协商加密套件以及与响应方进行流信息协商。加密套件的细节可以参考本公开中所描述的ipsecsa加密套件的任一场景。应理解，可以独立地进行加密套件协商和流信息协商。在这种情况下，两端可以记录第一轮协商中已经达成的加密套件的协议。第二轮协商中重新发送的create_child_sa请求可以不通过携带或不携带sa载荷来重新协商加密套件。当发起方更改流信息，且相应地，create_child_sa请求中携带ts载荷(该ts载荷中携带更改的与发起方相关联的流信息)时，关于是否在create_child_sa响应中携带ts载荷，响应方可以有以下三种选择：第一种选择为，当与响应方相关联的流信息没有发生变化，且与响应方相关联的当前使用的流信息存在于create_child_sa请求中携带的与发起方相关联的流信息中时，create_child_sa响应中不携带ts载荷。第二种选择为，当与响应方相关联的流信息发生变化，且响应方选择create_child_sa请求中携带的与发起方相关联的流信息中的流信息作为与响应方相关联的流信息时，create_child_sa响应中携带ts载荷。如操作212中所述，响应方可以选择发起方所提出的流量的子集，即，将流量选择器缩小到发起方的提议的某个子集。响应方也可以向发起方发送相同的ts载荷。第三种选择是，当create_child_sa请求中携带的发起方提出的流信息与流信息支持之间没有匹配流信息时，create_child_sa响应中携带ts不可接受的通知，用于指示没有匹配流信息。然后，发起方接收到该通知之后，重新发送create_child_sa请求，该create_child_sa请求中携带ts载荷，该ts载荷中携带更新后的流信息，以与响应方重新协商流信息，直到发起方与响应方就流信息达成协议。如本公开中所述，如果需要的话，流信息的重新协商的过程可以指加密套件协商或流信息协商的任一场景。如上所述，重新协商过程可以将加密套件协商和流信息协商一起进行，或者可以仅在第一协商轮中执行失败的流信息协商，而不重新协商已经达成协议的加密套件。操作1016至1020的详细实现方式可以参考图8中所描述的操作716至720和图2中所描述的操作216至220。例如，在ipsec密钥更新中，该new_spi通知载荷可以节省最小76字节，并且在有多个加密套件和/或ts载荷的情况下，所节省的字节数成比例增加。这减少了对复杂验证的处理，从而减少了对sa、tsi和tsr载荷的处理。图11示出了本实施例的第二种场景，其中，响应方更改加密套件，例如，响应方更改建立待进行密钥更新的sa时响应方当前使用的加密套件。该场景下，操作1102至1112与以上操作相同。但是在操作1114中，create_child_sa响应中携带hdr头、没有被选提议通知载荷或ts不可接受的通知载荷。没有被选提议通知载荷可以是no_proposal_chosen载荷，用于指示create_child_sa请求中携带的加密套件中不存在匹配加密套件。ts不可接受的通知载荷可以是ts_unacceptable通知，用于指示create_child_sa请求中携带的流信息中不存在匹配流信息。然后，发起方接收到该指示之后，重新发送create_child_sa请求，该请求中携带sa载荷，sa载荷中携带更新后的加密套件，以与响应方重新协商加密套件，直到发起方和响应方就加密套件达成协议。加密套件的重新协商过程可以指本公开中所描述的任一场景。下面描述重新协商的一个示例。在操作1116中，发起方向响应方重新发送create_child_sa请求(可以称为第二create_child_sa请求)。第二create_child_sa请求包括hdr头、n(rekey_sa)载荷、sa载荷、ni载荷、可选的kei载荷、可选的ts载荷(取决于发起方是否更改流信息)。n(rekey_sa)载荷中携带spi，用于指示待进行密钥更新的子sa。ni载荷和kei载荷的内容可以参考操作212和操作1012。sa载荷中携带spi字段，该spi字段中携带新发起方spi和发起方提出的一个或多个加密套件。在操作1118中，响应方向发起方发送create_child_sa响应。create_child_sa响应中携带hdr头、n(rekey_sa)载荷、new_spi通知载荷或sa载荷、nr载荷、可选的ker响应(取决于create_child_sa请求中是否携带kei载荷)和可选的携带与响应方相关联的流信息的ts载荷(取决于响应方是否更改与响应方相关联的流信息)。应理解，在重新协商过程中，可以根据本公开中所描述的加密套件协商方法和流信息协商方法中的任一种执行加密套件协商和流信息协商。操作1120：该操作的实现方式可以参考如上所述的操作216。操作1122：发起方向响应方发送旧ipsecsa删除请求，以删除旧ipsecsa。旧子删除请求可以包括hdr和d载荷。d载荷可以包括标识待删除sa的spi。详细实现方式可以参考操作216。操作1124：响应方接收到旧ipsecsa删除请求后，向发起方发送旧ipsecsa删除响应。旧子sa删除响应可以包括hdr和d载荷。d载荷可以包括标识待删除sa的spi。详细实现方式可以参考操作218。上述重新协商过程将加密套件协商和流信息协商一起进行，其中，当加密套件协商和流信息协商中的任一个失败时，都会触发重新协商过程，重新协商过程将重新协商加密套件和流信息。如上所述，加密套件协商和流信息协商可以分别进行。下面描述第二种场景的流信息协商。在操作1112中，当create_child_sa请求中不携带ts载荷(ts载荷中携带与发起方相关联的流信息)时，在操作1114中，关于响应方在create_child_sa响应中是否携带ts载荷可以有以下两种选择：第一种选择是，当与响应方相关联的流信息没有发生变化，且当前使用的流信息在密钥更新之后仍然用于新ipsecsa时，create_child_sa响应中不携带与响应方相关联的ts载荷。第二种选择是，当与响应方相关联的流信息发生变化时，create_child_sa响应中携带ts不可接受的通知。ts不可接受的通知可以是ts_unacceptable通知载荷，用于指示发起方与响应方之间信息不匹配。然后，发起方接收到ts不可接受的通知之后，重新发送create_child_sa请求，该create_child_sa请求中携带ts载荷，该ts载荷中携带更新后的流信息，以与响应方重新协商流信息，直到发起方和响应方就流程信息达成协议。如本公开中所述，如果需要的话，流信息的重新协商的过程可以指加密套件协商或流信息协商的任一场景。应注意，当加密套件协商和流信息协商中的任一个在第一轮协商中失败时，两端可以在第二轮协商中同时重新协商加密套件和流信息。在这种情况下，重新发送的create_child_sa请求中可以带有或不带sa载荷，以重新协商加密套件以及与响应方进行流信息协商。如果需要的的话，加密套件的细节可以参考本公开中所描述的ipsecsa加密套件的任一场景。应理解，可以独立地进行加密套件协商和流信息协商。在这种情况下，两端可以记录第一轮协商中已经达成的加密套件的协议。第二轮协商中重新发送的create_child_sa请求可以不通过携带或不携带sa载荷来重新协商加密套件。应理解，在具有更新后的加密套件或ts的第二密钥更新请求期间，设备可以重用new_spi通知或轻量级sa载荷中的spi，或者在具有新加密套件的第二密钥更新请求期间，设备可以完全生成新spi。该方法可以应用于如本公开中所讨论的重新协商过程。当发起方更改流信息，且相应地，create_child_sa请求中携带ts载荷(该ts载荷中携带更改的与发起方相关联的流信息)时，关于是否在create_child_sa响应中携带ts载荷，响应方可以有以下三种选择：第一种选择为，当与响应方相关联的流信息没有发生变化，且与响应方相关联的当前使用的流信息存在于create_child_sa请求中携带的与发起方相关联的流信息中时，create_child_sa响应中不携带ts载荷。第二种选择为，当与响应方相关联的流信息发生变化，且响应方选择create_child_sa请求中携带的与发起方相关联的流信息中的流信息作为与响应方相关联的流信息时，create_child_sa响应中携带ts载荷。如操作212中所述，响应方可以选择发起方所提出的流量的子集，即，将流量选择器缩小到发起方的提议的某个子集。响应方也可以向发起方发送相同的ts载荷。第三种选择是，当create_child_sa请求中携带的发起方提出的流信息与流信息支持之间没有匹配流信息时，create_child_sa响应中携带ts不可接受的通知，用于指示没有匹配流信息。然后，发起方接收到该通知之后，重新发送create_child_sa请求，该create_child_sa请求中携带ts载荷，该ts载荷中携带更新后的流信息，以与响应方重新协商流信息，直到发起方和响应方就流程信息达成协议。如本公开中所述，如果需要的话，流信息的重新协商的过程可以指加密套件协商或流信息协商的任一场景。如上所述，重新协商过程可以将加密套件协商和流信息协商一起进行，或者可以仅在第一轮协商中执行失败的协商。图12为根据本公开实施例的对ipsecsa进行密钥更新的流程图。在本实施例中，发起方更改建立待进行密钥更新的sa时所使用的加密套件，例如将弱加密套件更改为较强的加密套件，例如，具有更高加密算法集的较强的加密套件。对于流信息，发起方可以更改流信息，也可以不更改流信息。当发起方没有更改流信息时，密钥更新请求不需要携带ts载荷。相反，当发起方更改流信息时，密钥更新请求将携带流信息，以反映更改的流信息，例如地址范围、端口范围、ip协议id等中的任一种。本实施例中有三种场景。第一种场景是响应方不更改加密套件，例如加密套件。在这种场景下，响应方可能不会与发起方协商加密套件，并使用轻量级密钥更新方法。例如，响应方可以使用new_spi通知或轻量级sa载荷或任何其它载荷来包含响应方spi。第二种场景是响应方更改加密套件。在这种情况下，响应方可以在密钥更新响应中携带sa载荷(该sa载荷中携带更改的加密套件)。第三种场景是密钥更新请求中携带的加密套件与响应方支持的加密套件不匹配。在这种情况下，响应方携带通知载荷，用于指示发起方发送的密钥更新请求中携带的加密套件中没有匹配加密套件。然后，两端重新协商加密套件，直到就加密套件达成协议。加密套件的详细协商可以参考对应于图9的详细描述。返回参考图12，该图为根据本实施例的流程图，包括以下操作。操作1202至1210的详细实现方式可以参考图8中描述的操作802至810。操作1212：发起方向响应方发送用于对ipsecsa进行密钥更新的create_child_sa请求。create_child_sa请求包括hdr头、n(rekey_sa)载荷(携带spi，用于指示待进行密钥更新的子sa)、sa载荷(携带一个或多个加密套件和新发起方spi)、ni载荷、可选的kei载荷，和可选的ts载荷(取决于发起方是否更改与发起方相关联的流信息)。每个载荷中携带的详细信息可以参考操作112。操作914：响应方向发起方发送用于对ipsecsa进行密钥更新的create_child_sa响应。create_child_sa响应包括hdr头、new_spi通知载荷或sa载荷(取决于响应方是否更改与响应方相关联的加密套件)、nr载荷、可选的ker载荷(取决于create_child_sa请求是否携带kei载荷)、可选的ts载荷(取决于响应方是否更改与响应方相关联的流信息)。new_spi载荷的spi字段可以携带新响应方spi且不携带加密套件。应理解，在操作1214中，作为一种可选的方式，响应方可以发送携带sa载荷的create_child_sa响应，该sa载荷中携带当前使用的(即，在建立sa时使用的)加密套件和新响应方spi，即使响应方不更改当前使用的加密套件时也是如此。根据本实施例的第二种场景，响应方更改当前使用的加密套件。create_child_sa响应中携带sa载荷，该sa载荷中携带更改的加密套件，发起方也支持该更改的加密套件。操作1216至1218的详细实现方式可以参考图8中所描述的操作816至818和图2中所描述的操作216至218。根据本实施例的第三种场景，create_child_sa请求中的加密套件与响应方希望更改的加密套件不匹配。在此场景中，在操作1214中，响应方可以在create_child_sa响应中将没有被选提议通知载荷发送给发起方，而不是sa载荷。没有被选提议通知载荷可以是no_proposal_chosen载荷，用于指示create_child_sa请求中携带的加密套件中不存在匹配加密套件。然后，发起方接收到该指示之后，重新发送create_child_sa请求，该请求中携带sa载荷，sa载荷中携带更新后的加密套件，以与响应方重新协商加密套件，直到发起方和响应方就加密套件达成协议。如果需要的话，加密套件的重新协商过程可以指本公开中所描述的任一场景。下面描述本实施例中的流信息协商。在操作1212中，当create_child_sa请求中不携带ts载荷(ts载荷中携带与发起方相关联的流信息)时，在操作1214中，关于响应方在create_child_sa响应中是否携带ts载荷可以有以下两种选择：第一种选择是，当与响应方相关联的流信息没有发生变化，且当前使用的流信息在密钥更新之后仍然用于新ipsecsa时，create_child_sa响应中不携带与响应方相关联的ts载荷。第二种选择是，当与响应方相关联的流信息发生变化时，create_child_sa响应中携带ts不可接受的通知。ts不可接受的通知可以是ts_unacceptable通知载荷，用于指示发起方与响应方之间信息不匹配。然后，发起方接收到ts不可接受的通知之后，重新发送create_child_sa请求，该create_child_sa请求中携带ts载荷，该ts载荷中携带更新后的流信息，以与响应方重新协商流信息，直到发起方和响应方就流程信息达成协议。如本公开中所述，如果需要的话，流信息的重新协商的过程可以指加密套件协商或流信息协商方法中的任一种。应注意，当加密套件协商和流信息协商中的任一个在第一轮协商中失败时，两端可以在第二轮协商中同时重新协商加密套件和流信息。在这种情况下，重新发送的create_child_sa请求中可以带有或不带sa载荷，以重新协商加密套件以及与响应方进行流信息协商。应理解，可以独立地进行加密套件协商和流信息协商。在这种情况下，两端可以记录第一轮协商中已经达成的加密套件的协议。第二轮协商中重新发送的create_child_sa请求可以不通过携带或不携带sa载荷来重新协商加密套件。当发起方更改流信息，且相应地，create_child_sa请求中携带ts载荷(该ts载荷中携带更改的与发起方相关联的流信息)时，关于是否在create_child_sa响应中携带ts载荷，响应方可以有以下三种选择：第一种选择为，当与响应方相关联的流信息没有发生变化，且与响应方相关联的当前使用的流信息存在于create_child_sa请求中携带的与发起方相关联的流信息中时，create_child_sa响应中不携带ts载荷。第二种选择为，当与响应方相关联的流信息发生变化，且响应方选择create_child_sa请求中携带的与发起方相关联的流信息中的流信息作为与响应方相关联的流信息时，create_child_sa响应中携带ts载荷。如操作212中所述，响应方可以选择发起方所提出的流量的子集，即，将流量选择器缩小到发起方的提议的某个子集。响应方也可以向发起方发送相同的ts载荷。第三种选择是，当create_child_sa请求中携带的发起方提出的流信息与流信息支持之间没有匹配流信息时，create_child_sa响应中携带ts不可接受的通知，用于指示没有匹配流信息。然后，发起方接收到该通知之后，重新发送create_child_sa请求，该create_child_sa请求中携带ts载荷，该ts载荷中携带更新后的流信息，以与响应方重新协商流信息，直到发起方和响应方就流程信息达成协议。如本公开中所述，如果需要的话，流信息的重新协商的过程可以指加密套件协商或流信息协商的任一场景。如上所述，重新协商过程可以将加密套件协商或流信息协商一起进行，或者可以仅在第一轮协商中执行失败的协商。例如，通过在ipsec密钥更新中引入new_spi通知载荷，或者不携带ts载荷，可以为每个ipsec密钥更新节省最小76字节，从而减少对复杂验证的处理以及对sa、tsi和tsr载荷的处理。图13为根据本公开实施例的网络设备1300的示意图。该网络设备用于对包括第一网络设备(例如，以上实施例中所描述的发起方)和第二网络设备(例如，以上实施例中所描述的响应方)的网络系统中的安全联盟(securityassociation，sa)进行密钥更新，第一网络设备与第二网络设备之间建立有ike隧道和ipsec隧道。在本实施例中，该网络设备用作第一网络设备，该网络设备包括确定模块1302、发送模块1304、接收模块1306和密钥更新模块1308。确定模块1302用于确定与第一网络设备相关联的加密套件是否发生变化。发送模块1304用于当与第一网络设备相关联的加密套件没有发生变化时，向第二网络设备发送用于对sa进行密钥更新的第一密钥更新请求，其中，第一密钥更新请求中携带第一spi且不携带与第一网络设备相关联的加密套件。接收模块1306用于接收来自第二网络设备的第一密钥更新响应，其中，当与第二网络设备相关联的加密套件没有发生变化时，第一密钥更新响应中携带第二spi且不携带与第二网络设备相关联的加密套件；密钥更新模块1308用于当与第一网络设备相关联的加密套件和与第二网络设备相关联的加密套件没有发生变化时，根据第一spi和第二spi对sa进行密钥更新。本实施例的网络设备的各个模块的实现方式的细节可以参考图7和图10的实施例中发起方的实现方式。在另一实施例中，该网络设备还包括：重新协商模块1310。当与第二网络设备相关联的加密套件发生变化时，第一密钥更新响应中携带来自第二网络设备的没有被选提议通知。重新协商模块1310用于与第二网络设备重新协商，直到获得协商的加密套件，密钥更新模块1308用于还根据重新协商的加密套件对sa进行密钥更新。应理解，重新协商模块1310用于确定在ipsecsa密钥更新的情况下是否重新协商加密套件或流信息，通过发送模块1304和接收模块1306进行重新协商过程。在一些实施例中，重新协商模块1310可以并入确定模块1302中。没有被选提议通知的示例可以是no_proposal_chosen通知载荷。本实施例的网络设备的重新协商实现方式的细节可以参考图8和图11的实施例中发起方的实现方式。应理解，网络设备1300可以实现以上图1至图12的实施例中由发起方执行的操作。详细实现方式可以参考如上所述的实施例。在此不再赘述。图14为根据本公开实施例的另一网络设备1400的示意图。网络设备1400用于对包括第一网络设备(例如，以上实施例中所描述的发起方)和第二网络设备(例如，以上实施例中所描述的响应方)的网络系统中的安全联盟(securityassociation，sa)进行密钥更新，第一网络设备与第二网络设备之间建立有ike隧道和ipsec隧道。在本实施例中，该网络设备用作第二网络设备，该网络设备包括接收模块1402、确定模块1404、发送模块1406和密钥更新模块1408。接收模块1402用于接收来自第一网络设备的用于对sa进行密钥更新的第一密钥更新请求，第一密钥更新请求中携带第一spi，且不携带与第一网络设备相关联的加密套件。确定模块1404用于确定与第二网络设备相关联的加密套件是否发生变化。发送模块1406用于向第一网络设备发送第一密钥更新响应，当与第二网络设备相关联的加密配置没有发生变化时，第一密钥更新响应中携带第二spi且不携带与第二网络设备相关联的加密套件。相应地，密钥更新模块1408用于根据第一spi和第二spi对sa进行密钥更新。本实施例的网络设备中各个模块的实现方式的细节可以参考图7和图10的描述。在网络设备1400的另一个实施例中，当与第二网络设备相关联的加密套件发生变化时，第一密钥更新响应中携带没有被选提议通知。这样，接收模块1402还用于接收来自第一网络设备的用于对sa进行密钥更新的第二密钥更新请求，第二密钥更新请求中携带第一spi和与第一网络设备相关联的加密套件。发送模块1406还用于发送第二密钥更新响应，第二密钥更新响应中携带另一个没有被选提议通知，用于指示第二密钥更新请求中携带的与第一网络设备相关联的加密套件中不存在匹配加密套件。该网络设备还包括重新协商模块1410，用于与第一网络设备重新协商，直到获得协商的加密套件。因此，还根据重新协商的加密套件对sa进行密钥更新。应理解，重新协商模块1410用于确定在ipsecsa密钥更新的情况下是否重新协商加密套件或流信息，通过发送模块1406和接收模块1402进行重新协商过程。在一些实施例中，重新协商模块1410可以并入确定模块1404中。本实施例的网络设备的重新协商实现方式的细节可以参考图8和图11的实施例中发起方的实现方式。应理解，网络设备1400可以实现以上图1至图12的实施例中由响应方执行的操作。详细实现方式可以参考如上所述的实施例。在此不再赘述。图15为根据本公开实施例的另一网络设备1500的示意图。网络设备1500用于对包括第一网络设备(例如，以上实施例中所描述的发起方)和第二网络设备(例如，以上实施例中所描述的响应方)的网络系统中的安全联盟(securityassociation，sa)进行密钥更新，第一网络设备与第二网络设备之间建立有ike隧道和ipsec隧道。在本实施例中，该网络设备用作第二网络设备，该网络设备包括接收模块1502、确定模块1504、发送模块1506和密钥更新模块1508。接收模块1502用于接收来自第一网络设备的用于对sa进行密钥更新的第一密钥更新请求，第一密钥更新请求中携带第一spi和与第一网络设备相关联的加密套件。确定模块1504用于确定与第二网络设备相关联的加密套件是否发生变化。发送模块1506用于向第一网络设备发送第一密钥更新响应，当与第二网络设备相关联的加密套件没有发生变化时，第一密钥更新响应中携带第二spi且不携带与第二网络设备相关联的加密套件。密钥更新模块用于根据第一spi和第二spi对sa进行密钥更新。密钥更新的实现方式可以参考以上图6至图12中的详细描述。在网络设备1500的另一个实施例中，第一密钥更新响应中携带没有被选提议通知，用于指示与第一密钥更新请求中携带的第一网络设备相关联的加密套件中不存在匹配加密套件。在这种情况下，网络设备1500还包括重新协商模块1510，用于与第一网络设备重新协商，直到获得协商的加密套件。因此，还根据协商的加密套件对sa进行密钥更新。本领域普通技术人员可以理解，重新协商模块1510用于确定在ipsecsa密钥更新的情况下是否重新协商加密套件或流信息，通过发送模块1506和接收模块1502进行重新协商过程。在一些实施例中，重新协商模块1510可以并入确定模块1504中。以上实施例的网络设备1500的重新协商实现方式的细节可以参考图9和图12的实施例中响应方的实现方式。本领域技术人员可以理解，网络设备1500可以实现以上图1至图12的实施例中由响应方执行的操作。详细实现方式可以参考如上所述的实施例。在此不再赘述。图16为根据本公开实施例的另一网络设备1600的示意图。网络设备1600用于对包括第一网络设备(例如，以上实施例中所描述的发起方)和第二网络设备(例如，以上实施例中所描述的响应方)的网络系统中的安全联盟(securityassociation，sa)进行密钥更新，第一网络设备与第二网络设备之间建立有ike隧道和ipsec隧道。在一些实施例中，网络设备1600可以用作如图1至图12的实施例中所描述的发起方，并执行图1至图12的实施例中所描述的发起方的操作。在其它实施例中，网络设备1600可以用作图1至图12的实施例中所描述的响应方，并执行图1至图12的实施例中所描述的响应方的操作。该网络设备包括处理器1602、耦合到处理器1602的存储器1604、收发器(tx/rx)1606以及耦合到tx/rx1606的端口1608。处理器1602可以实现为通用处理器，或者可以是一个或多个专用集成电路(applicationspecificintegratedcircuit，asic)和/或数字信号处理器(digitalsignalprocessor，dsp)的一部分。处理器1602可以指单个处理器，也可以指多个处理器。存储器1604可以包括用于临时存储内容的缓存，例如随机存取存储器(random-accessmemory，ram)。此外，存储器1604可以包括长期存储器，例如只读存储器(read-onlymemory，rom)。当处理器1602用作发起方时，用于执行图1至图12的实施例中所描述的发起方的操作。当处理器1602用作响应方时，用于执行图1至图12的实施例中所描述的响应方的操作。此外，在一个实施例中，存储器1604可以包括多个软件模块，例如图13实施例中所描述的模块。在另一实施例中，存储器1604可以包括多个软件模块，例如图14的实施例中所描述的模块。在另一实施例中，存储器1604可以包括多个软件模块，例如图15的实施例中所描述的模块。通过执行软件模块的指令，处理器1602可以执行多种操作。在一些实施例中，当模块用于执行操作时，实际上可以是指处理器1602用于执行模块中的指令以执行操作。通过执行存储器1604中的指令，处理器1602可以全部或部分执行由如图1至12中所描述的发起方或响应方所执行的所有操作。图17为网络系统1700的示意图。网络系统1700可以包括至少第一网络设备1702(即发起方)和第二网络设备1704(即响应方)。第一网络设备1702可以是如图13的实施例中所描述的网络设备1300。第二网络设备1704可以是如图14和图15的实施例中所描述的网络设备1400或网络设备1500。在另一实施例中，第一网络设备可以是网络设备1600，其用作如图1至图12的实施例中所描述的发起方，并执行图1至图12的实施例中所描述的发起方的操作。第二网络设备可以是网络设备1600，其用作如图1至图12的实施例中所描述的响应方，并执行如图1至图12的实施例中所描述的响应方的操作。本领域技术人员在阅读本公开之后可以理解，任何已知的或新算法都可以用于实现本公开。但是，应注意，本公开提供了一种实现上述益处和技术进步的方法，该方法中使用任何已知的算法或新算法。本领域普通技术人员在阅读本公开之后可以意识到，结合本说明书中所公开的实施例描述的各示例，单元及算法步骤能够以电子硬件，或者以计算机软件与电子硬件的组合来实现。功能是由硬件还是由软件执行取决于技术方案的特定应用和设计约束条件。本领域技术人员在阅读本公开之后可使用不同方法实现每个特定应用的所描述功能，但是不应认为该实现方式超出本公开的范围。应理解，在本公开中提供若干实施例中，所公开的系统和方法可以通过其它方式实现。例如，所描述的网络设备的实施例仅仅是示例性的。例如，单元分割仅仅是逻辑功能分割，在实际实现方式中可以是其它分割。例如，可以将多个单元或模块合并或集成到另一系统中，或可以忽略或不执行一些特征。此外，所显示或讨论的相互耦合或直接耦合或通信连接可以通过一些接口来实现。装置或单元之间的直接耦合或通信连接可通过电子、机械或其它形式实现。当这些功能以软件功能单元的形式实现并作为独立的产品销售或使用时，可以将这些功能存储在计算机可读存储介质中。这些功能可以用形成计算机程序产品的计算机代码来表示，计算机程序产品可以指示适当的硬件执行这些功能。基于这样的理解，本公开的技术方案本质上，或者对现有技术贡献的部分，或者技术方案的一部分，可以以软件产品的形式实现。计算机软件产品存储在存储介质中并包括若干指令，用于指示计算机节点(可为个人计算机、服务器或网络节点，即处理器)执行本公开实施例中所描述的方法的所有或部分步骤。前述存储介质包括：可以存储程序代码的任何介质，例如usb闪存驱动器、可移动硬盘、只读存储器(read-onlymemory，rom)、随机存取存储器(randomaccessmemory，ram)、磁盘或光盘。相互通信的设备之间不需要保持连续通信，除非另有明确规定。此外，相互通信的设备可以直接或通过一个或多个媒介间接地进行通信。当本文描述单个设备或物品时，很明显可以使用一个以上的设备/物品(不论它们是否协作)来代替单个设备/物品。类似地，对于本文描述的一个以上的设备或物品的情况(不论它们是否协作)，很明显可以使用单个设备/物品来代替一个以上的设备或物品，或者可以使用不同数量的设备/物品来代替所示数量的设备或程序。或者，设备的功能和/或特征可以由未明确描述为具有这种功能/特征的一个或多个其它设备实施。因此，本发明的其它实施例不需要包括设备本身。当前第1页12当前第1页12