WO2012040971A1 - 用于路由协议的密钥管理方法和系统 - Google Patents

用于路由协议的密钥管理方法和系统 Download PDF

Info

Publication number
WO2012040971A1
WO2012040971A1 PCT/CN2010/079296 CN2010079296W WO2012040971A1 WO 2012040971 A1 WO2012040971 A1 WO 2012040971A1 CN 2010079296 W CN2010079296 W CN 2010079296W WO 2012040971 A1 WO2012040971 A1 WO 2012040971A1
Authority
WO
WIPO (PCT)
Prior art keywords
routing protocol
ikev2
payload
field
module
Prior art date
Application number
PCT/CN2010/079296
Other languages
English (en)
French (fr)
Inventor
梁小萍
王鸿彦
韦银星
Original Assignee
中兴通讯股份有限公司
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by 中兴通讯股份有限公司 filed Critical 中兴通讯股份有限公司
Publication of WO2012040971A1 publication Critical patent/WO2012040971A1/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/164—Implementing security features at a particular protocol layer at the network layer

Definitions

  • the present invention relates to a route security technology in a communication network, and in particular to a key management method and system for a routing protocol.
  • a router is the most important and core component of a modern IP network, providing routing information for the transmission of data packets. Routers rely on routing protocols running on them to collect routing information and calculate and manage optimal routes. Since routing information is transmitted in plain text in the network, it is very easy to forge and tamper with routing message packets. If the router accepts such a routing message packet, it will generate an incorrect route, causing some or all network data packets to fail to reach the specified destination or receiver, and the data service cannot be performed normally. Therefore, integrity protection of routing messages is required.
  • SA security association
  • the routing protocols currently used mainly do not provide an SA negotiation mechanism, but are manually configured and updated by a person called an administrator.
  • the problem with manual configuration and update is that it is unreliable and error-prone on the one hand, and slow on the other hand, and is not suitable for modern large-scale networks.
  • the attacker's computing power increases and the attack technology emerges endlessly, the probability and frequency of attacks and damages on the network become higher and higher, and the modern network with rapidly growing business value pays more and more. Therefore, On the one hand, network operators should prevent network attacks and damages.
  • the present invention has been made in view of the problems of efficiency and correctness caused by the negotiation method of the SA for routing protocols in the prior art. To this end, the main object of the present invention is to provide a key for a routing protocol. Management methods and systems to address at least one of the above issues.
  • a key management method for a routing protocol including: an extended Internet Key Exchange Protocol version 2 IKEv2; using the extended IKEv2 negotiation generated above for generating The SA of the routing protocol; uses the generated SA to perform key management on the routing protocol, and protects the transmission of routing messages based on the above routing protocol.
  • the step of extending the Internet Key Exchange Protocol version 2 IKEv2 includes one of the following: adding a field related to the routing protocol to the original SA payload of the IKEv2; or adding an SA for the routing protocol in the IKEv2 The payload, where the SA payload used in the routing protocol carries a field related to the routing protocol.
  • adding a field related to the routing protocol in the original SA payload of the IKEv2 includes: adding a protocol identifier field and a key for the routing protocol in the Proposal Substructure in the original SA payload.
  • An identifier field; a transform type field and a transform identifier field for the routing protocol are added to the transform substructure in the original SA payload; and added to the attribute type in the transform substructure (Transform Substructure)
  • the key length field of the routing protocol and the time-to-live field of the SA further includes: adding a switching type for the routing protocol in the IKEv2, where the switching type is used to indicate that the usage in the exchange corresponding to the switching type is increased.
  • adding the SA payload for the routing protocol in the foregoing IKEv2 includes: constructing the same SA payload as that of the original SA payload; and adding the proposed substructure (Proposal Substructure) in the SA payload constructed above for The time-to-live field of the SA of the routing protocol and the above-mentioned lifetime length field; the SPI size field is replaced with the key identifier field for the routing protocol in the Proposal Substructure in the SA payload constructed above, and The SPI field is replaced with a key identifier field for the routing protocol.
  • the step of extending the Internet Key Exchange Protocol version 2 IKEv2 further includes: adding a switching type for the routing protocol in the IKEv2, wherein the switching type is used to indicate that the foregoing is used in the exchange corresponding to the switching type. Added SA payload for routing protocols.
  • the steps of the SA include: generating an SA for establishing a secure channel by using the above IKEv2 negotiation;
  • the established SA establishes a secure channel.
  • the extended IKEv2 negotiation is used on the secure channel to generate a SA for the routing protocol.
  • the step of the SA includes: the first router filling each of the one or more sets of the above-mentioned routing protocol-related fields that it supports into the corresponding field in the extended IKEv2;
  • the IKEv2 sends the above-mentioned one or more sets of the above-mentioned routing protocol-related fields to the second router peering with the first router;
  • the second router selects one or more groups of the routing protocol-related fields. a set of fields related to the routing protocol, and sent to the first router by using the extended IKEv2; the first router and the second router construct the selected one of the routing protocol-related fields for the foregoing
  • a key management system for a routing protocol comprising: an extension unit for extending an Internet Key Exchange Protocol version 2 IKEv2; a negotiation unit, The SA is used to generate the SA for the routing protocol, and the processing unit is configured to perform key management on the routing protocol by using the generated SA and protect the transmission of the routing message based on the routing protocol.
  • the foregoing expansion unit includes: a first expansion module, configured to add a field related to a routing protocol in the original SA payload of the IKEv2; and a second expansion module, configured to add an SA for the routing protocol in the IKEv2 The payload, where the SA payload used in the routing protocol carries a field related to the routing protocol.
  • the first expansion module includes: a first processing submodule, configured to add a protocol identifier field and a key identifier field for the routing protocol in the Proposal Substructure in the original SA payload. a second processing submodule, configured to add a transform type field and a transform identifier field for the routing protocol in the transform substructure in the original SA payload; the third processing submodule is used in the foregoing
  • the key length field for the routing protocol and the time-to-live field of the SA are added to the attribute type in the Transform Substructure.
  • the foregoing second expansion module includes: a construction submodule for constructing the same SA load as the structure of the original SA payload; and a third processing submodule for proposing the substructure in the SA load constructed above ( Proposal Substructure) adds the time-to-live field of the SA for the routing protocol and the above-mentioned lifetime length field; the fourth processing sub-module is used to build the above The Proposal Substructure in the SA payload replaces the SPI size field with the Key Identifier field for the routing protocol and replaces the SPI field with the Key Identifier field for the routing protocol.
  • the foregoing expansion unit includes: a third extension module, configured to add a switch type for the routing protocol in the IKEv2, where the switch type is used to indicate that the added route and the route are used in the exchange corresponding to the switch type The original SA payload of IKEv2 of the protocol-related field, or, using the SA load added for the routing protocol described above.
  • the foregoing negotiating unit includes: a first negotiation module, configured to generate an SA for establishing a secure channel by using the foregoing IKEv2 negotiation; a establishing module, configured to establish a secure channel by using the generated SA; and a second negotiation module, configured to be used in the foregoing The extended IKEv2 negotiation on the secure channel generates the SA for the routing protocol.
  • the negotiating unit includes: a third negotiating module located on the first router, and a fourth negotiating module located on the second router that is peered with the first router, where the third negotiating module is configured to use the foregoing
  • Each of the one or more sets of the above-mentioned routing protocol-related fields supported by the first router is filled in the corresponding field in the extended IKEv2, and the above-mentioned one or more groups are set by the extended IKEv2.
  • a field related to the routing protocol is sent to the fourth negotiation module, and a set of routing protocol-related fields selected by the fourth negotiation module is configured to be used for communication between the first router and the second router.
  • the SA of the routing protocol is used to select a group of the routing protocol-related fields from the one or more groups of the routing protocol-related fields, and send the IKEv2 to the third negotiation module by using the extended IKEv2. And constructing a selected one of the routing protocol-related fields for the first router and the second road SA communication between routing protocol used.
  • a key management system for a routing protocol including: a KMP unit, a routing protocol unit, and a keystore unit connected to each other, wherein
  • the KMP unit is configured to extend the Internet Key Exchange version 2 IKEv2, and use the extended IKEv2 negotiation to generate a security association SA for the routing protocol;
  • the foregoing routing protocol unit is used to run the routing protocol with the above KMP
  • the unit and the key pool unit provide interaction and interface functions; the key pool unit is configured to store the key material used by the KMP unit and the routing protocol unit.
  • the KMP unit includes: an SA generation module, an SA usage policy module, and an SA library module, where the SA generation module is configured to use an instruction of the policy module according to the foregoing SA
  • the IKEv2 is used to negotiate the generation of the SA for the routing protocol.
  • the SA library module is configured to store and manage the SA generated by the SA generation module.
  • the SA uses the policy module to guide the SA generation by using the command.
  • the module negotiates to generate the SA, and instructs the SA library module to access the SA through instructions.
  • the SA generation module includes: a first extension submodule, configured to add a field related to a routing protocol in the original SA payload of the IKEv2; and a second extension submodule, configured to add a route for the IKEv2
  • the SA payload of the protocol where the SA payload for the routing protocol carries a field related to the routing protocol.
  • the foregoing SA generating module further includes: a third expansion module, configured to add, in the IKEv2, an exchange type for the routing protocol, where the exchange type is used to indicate that the foregoing increase is used in the exchange corresponding to the exchange type
  • the original SA payload of IKEv2 of the field associated with the routing protocol or, using the SA payload added for the routing protocol described above.
  • the extended IKEv2 is used to negotiate and generate the SA for the routing protocol, which solves the problem of the efficiency and correctness caused by the negotiation method of the SA for the routing protocol in the prior art, thereby achieving the routing.
  • the transmission of messages is more secure and reliable.
  • FIG. 1 is a schematic diagram of a key management system for a routing protocol according to an embodiment of the present invention
  • FIG. 2 is a schematic structural diagram of a KMP unit in the system shown in FIG.
  • FIG. 4 is a preferred flow of a key management method for a routing protocol according to an embodiment of the present invention.
  • FIG. 5 is a schematic diagram of an SA payload and its substructure related fields in IKEv2 according to an embodiment of the present invention.
  • FIG. 6 is a diagram showing SA loading and its substructure related fields in IKEv2 according to an embodiment of the present invention;
  • FIG. 7 is a schematic diagram of an OSPFv2 SA negotiation process of two KMP peers based on IKEv2 SA payload extension according to an embodiment of the present invention;
  • FIG. 8 is a new IKEv2-based payload type extension according to an embodiment of the present invention;
  • In-band KMP uses the message packets of the routing protocol itself to manage and distribute the key material, and the key material is loaded by modifying certain fields of the routing message packet or by extending the reserved fields.
  • Out-band KMP provides key management for routing protocols in a way that is independent of a functional module or a set of software or an entity other than the routing protocol. The advantage is that its scale and function are scalable. It has strong operability and does not need to change existing routing protocols. It is an industry-recognized technology development direction and trend. There is currently a KMP method for data secure communication between the transport layer and the application layer at the IP layer or above, such as the second edition of Internet Key Exchange (IKEv2), which will be described below.
  • IKEv2 Internet Key Exchange
  • IKEv2 is a protocol for providing SA negotiation for the Data Security Transport Mechanism (IPsec) of the Internet Protocol Version 6 (IPv6) IP layer.
  • IPsec Data Security Transport Mechanism
  • IPv6 Internet Protocol Version 6
  • IPv4 Internet Protocol
  • a total of four types of exchanges can be involved before and after the IKEv2 SA negotiation process, namely IKE SA INIT exchange, IKE_AUTH exchange, CREATE CHILD SA exchange, and INFORMATIONAL exchange.
  • the first two types of exchanges are collectively referred to as the initial exchange (Initial Exchange)! exchange in IKEv2 ( Exchange ) consists of a request and a response, which occurs between two network peers.
  • the peer that initiates the request is called the initiator (initiator, usually denoted by i), and responds.
  • the peer is called the responder (responder, usually denoted by r).
  • IKE SA INIT exchanges crytographic algorithms, exchanges random numbers (nonces), performs Diffie-Hellman (D-H) exchange, negotiates security parameters for two peers to generate IKE_SA, and provides a secure channel for subsequent exchanges.
  • D-H Diffie-Hellman
  • the IKE AUTH exchange is performed under the protection of IKE_SA.
  • the peer identity is authenticated and the first CHILD_SA is negotiated to provide SA for the IPsec encapsulated payload (ESP) or / and the authentication header (AH).
  • ESP IPsec encapsulated payload
  • AH authentication header
  • CHILD S A CREATE CHILD SA generates a CHILD S A.
  • This generated CHILD S A can be used to update the IKE_SA or the first CHILD_SA generated by the above exchange, or it can be a new CHILD SA for ESP or / and AH.
  • the INFORMATIONAL exchange is used as transmission control information, including error reporting and event notification.
  • the INFORMATIONAL exchange can only occur after the Initial Exchange and under the key protection that has been negotiated.
  • An INFORMATIONAL exchange message contains zero to multiple notifications, deletions (deleting SAs), and configuration (referring to exchanging configuration information between peers) payloads.
  • the request and response messages containing zero payloads are used to confirm the peer's life and death.
  • IKEv2 provides a good SA negotiation mechanism for IPsec ESP and AH protocols at the IP layer, but does not provide SA negotiation and generation for other protocols such as routing protocols.
  • the SA of the routing protocol is different from the SA content of the ESP and AH.
  • the former mainly includes the key ID, the authentication algorithm, the authentication key, the life time, and the sequence number. Wait. Since the traditional IKEv2 cannot directly negotiate to generate an SA for a routing protocol, the present invention extends IKEv2 so that the extended IKEv2 can be used to negotiate and generate a path for use. SA negotiated by ten.
  • Embodiment 1 As shown in FIG. 1 , this embodiment provides a key management system for a routing protocol.
  • the system is an out-of-band KMP software or a combination of software and hardware based on the IKEv2 extended routing protocol SA. system.
  • the system specifically includes:
  • the KMP unit 102 which is used to manage the SA of the routing protocol, provides the routing protocol unit 104 with the negotiation generation and usage guidance of the SA.
  • the KMP unit 102 is configured to extend the Internet Key Exchange version 2 IKEv2 and use the extended IKEv2 negotiation to generate a security association SA for the routing protocol.
  • the KMP unit 102 includes an SA generating module 202, an SA library module 204, and
  • the S A uses a policy module 206, wherein the SA generating module 202, the SA library module 204, and the SA usage policy module 206 are connected to each other, and the specific connection relationship is as shown in FIG. 2.
  • the SA generating module 202 is configured to negotiate to generate an SA for the routing protocol according to the IKEv2 that is extended according to the instruction of the SA usage policy module 206, where the specific steps of the SA for the routing protocol are negotiated in the following description. A detailed description is given.
  • the SA library module 204 is configured to store and manage SAs negotiated by the SA generation module 202.
  • the SA usage policy module 206 is used for setting and implementing the SA usage policy, to guide the SA generation module 202 to negotiate to generate the SA, and to guide the SA library module 204 to access the SA and the like.
  • the function division of the foregoing KMP unit may have other various manners. It is to be understood that other division manners or non-departitions are also within the protection scope of the present invention.
  • a routing protocol unit 104 configured to provide interaction and interface functions with the KMP unit 102 and the keystore unit 106 for various routing protocols that are running;
  • a keystore unit 106 configured to store various key materials used by the KMP unit 102 and the routing protocol unit 104.
  • the key materials include various cryptographic algorithms, authentication materials, etc.; preferably,
  • the system in an embodiment may also include a manual configuration unit 108 for management
  • the manual configuration keystore unit provides interface functionality so that the present invention can support manual configuration.
  • the data processing procedure of the KMP unit in FIG. 1 is based on the number of adjacent links and the number of interfaces of each adjacent link, and may be included in the loop processing manner, and may include but not limited to the following.
  • Step 4 Step S302: Calling the corresponding detection program, the KMP unit determines the number of links N adjacent to the resident router and the number of interfaces M on each adjacent link; Step S304: Adjacent to each neighbor The KMP peer of the link negotiates the IKE SA of the link.
  • Step S3 10 The interface routing protocol SA negotiation is unsuccessful and has not been exhausted (ie,
  • FIG. 4 is a preferred flow of a key management method for a routing protocol according to an embodiment of the present invention. The process diagram includes the following steps:
  • S404 Generate an SA for the routing protocol by using the extended IKEv2 negotiation
  • the extended IKEv2 is used to negotiate and generate the SA for the routing protocol, which solves the problem of the efficiency and correctness caused by the negotiation method of the SA for the routing protocol in the prior art, and thus achieves the problem.
  • the transmission of routing messages is more secure and reliable.
  • the step of expanding the Internet Key Exchange Protocol version 2 IKEv2 includes one of the following: adding a field related to the routing protocol to the original SA payload of the IKEv2; or adding a route for routing in the IKEv2
  • adding a field related to the routing protocol in the original SA payload of the IKEv2 includes: adding a protocol identifier field and a key for the routing protocol in the Proposal Substructure of the original SA payload.
  • adding the SA payload for the routing protocol in the IKEv2 includes: Constructing the same SA load of the original SA payload; adding a time-to-live field of the SA for the routing protocol and the time-to-live length field in the proposed sub-structure Proposal Substructure in the constructed SA payload; The Proposal Substructure in the proposed SA payload replaces the SPI size field with the Key Identifier field for the routing protocol and replaces the SPI field with the Key Identifier field for the routing protocol.
  • the extension of the new SA mentioned in the preferred embodiment can better facilitate the identification of both parties of the SA negotiation and improve the efficiency of the negotiation.
  • the step of expanding the Internet Key Exchange Protocol version 2 IKEv2 further includes: adding, in the IKEv2, an exchange type for the routing protocol, where the exchange type is used to indicate the exchange type
  • the added SA payload for the routing protocol is used in the corresponding exchange.
  • the exchange type added to the SA for the routing protocol in the preferred embodiment is such that the two parties negotiated by the SA can negotiate the SA more easily, which improves the efficiency of the negotiation.
  • the step of generating an SA for the routing protocol by using the extended IKEv2 negotiation includes: generating an SA for establishing a secure channel by using IKEv2 negotiation; establishing security by using the generated SA Channel:
  • the extended IKEv2 negotiation is used on the secure channel to generate a SA for the routing protocol.
  • the step of generating an SA for the routing protocol using the extended IKEv2 negotiation comprises: the first router correlating one or more groups of the supported protocols with the routing protocol Each of the fields is filled in a corresponding field in the extended IKEv2; the first router uses the extended IKEv2 to group the one or more groups of the routing protocol-related fields Sending to a second router peering with the first router; the second router selecting a group of routing protocol related fields from the one or more groups of routing protocol related fields, and using the extension
  • the IKEv2 is sent to the first router; the first router and the second router construct the selected set of routing protocol related fields for the first router and the second router The communication protocol used between the SAs.
  • the negotiation of the SA for the routing protocol can be effectively completed.
  • the step of performing key management based on the routing protocol and protecting the transmission of the routing message by using the generated SA includes: using the generated SA update as a routing protocol of the sender The key material of the routing protocol, the authentication code is calculated and filled for the routing message to be sent; the routing protocol used as the receiving party uses the generated SA to update the way. The integrity of the received routing message is verified by the key material of the protocol.
  • the present invention proposes the following solutions to specifically implement the SA for routing ten applications by using the extended IKEv2 negotiation. These solutions can be applied to the system of Embodiment 1 and the method of Embodiment 2.
  • FIG. 5 is a schematic diagram of the SA payload and its substructure related fields in IKEv2 according to an embodiment of the present invention.
  • the SA payload in IKEv2 includes a Generic Payload Header and a Proposal Substructure, wherein the proposed substructure includes a Transform Substructure, and the Transform Substructure includes a Transform. Attributes (transform attributes).
  • the extension of the original field for SA in IKEv2 includes the following operations:
  • the (Attribute Type) field which allows it to load the key length required by the routing protocol SA and the time-to-live parameter of the SA.
  • the Protocol ID field and the SPI Size field of the Proposal Substructure of the IKEv2 SA payload, the Type 3 of the Transform Type field of the Transform Substructure, and the Attribute Type field of the Transform Attributes are extended to provide a route.
  • the protocol ID field extension includes a routing protocol
  • the SPI Size field extension includes the length of the Key ID
  • the Transform Type The field extension includes that it can be used in a routing protocol
  • the extension of the Transform ID field includes an Authentication Algorithm used by the routing protocol
  • the Attribute Type field extension includes a key length and a survival time required to route the SA to the SA.
  • the parameter, the extended field corresponding to the definition of the extension
  • the assignment of ID values can be a combination of one or more. Solution 2: Adding a new payload to the routing protocol security association.
  • the original SA payload of IKEv2 is extended (in order to distinguish from the original SA payload, the extended SA payload is represented by SAe, but not the new payload type), including but not limited to the following steps: (1) Extended SA load In the Proposal substructure (Substructure) in (Payload)
  • Protocol ID field and SPI Size field where the Protocol ID field adds a routing protocol such as RIPv2 (Routing Information Protocol version 2, corresponding to IANA value 4), OSPFv2 (Open Shortest Path First version 2, corresponding to IANA value 5), ISIS ( The Intermediate System-to-intermediate System, corresponding to the IANA value of 6), etc., defines that each routing protocol corresponds to an IANA reserved value (ranging from 4 to 200), where the SPI is mapped to the Key ID of the SA of the routing protocol. Field, because the length of the Key ID of the routing protocol is different, the SPI Size field is extended, and routing protocols such as RIPv2, OSPFv2, and ISIS are included;
  • the ratios RIPv2 and OSPFv2 where the Transform ID field adds definitions of the authentication algorithm used for the routing protocol, such as AUTH HMAC SHA 224 (corresponding to the IANA value of 7), AUTH HMAC SHA 256 (corresponding to the IANA value of 8), AUTH HMAC SHA 384 (corresponding to IANA value 9), AUTH HMAC SHA 512 (corresponding to IANA value 10), etc.
  • Each definition corresponds to an IANA reserved value (ranging from 6 to 1023);
  • the embodiment of the present invention is that the network type is point-to-point, non- OSPFv2, a routing protocol running under Non-Broadcast Multiaccess ( ⁇ ), Point-to-multipoint, and Virtual links, provides an implementation of SA negotiation based on IKEv2 extension.
  • the specific data of the OSPFv2 is used as an example.
  • the content of S A to be negotiated includes but is not limited to:
  • the Initiator provides optional AUTH HMAC SHA 256 (corresponding to Key ID is 1), AUTH HMAC SHA 384 (corresponding to Key ID is 2), and AUTH HMAC SHA 512 (corresponding to Key ID is 3), and the Responder chooses to use AUTH_HMAC_SHA_256 (corresponding to Key ID is 1);
  • the _set two parties use the exchanged random number nonce and the unified pre-shared key that has been configured by the route ten as the input, which is calculated by the DH algorithm.
  • the router is assumed to be used.
  • the authentication method is Pre-shared Key, which is generally set by the administrator before the start of the game;
  • Cryptographic sequence number 32-bit long non-decreasing unsigned number, depending on the specific implementation algorithm used by the routing protocol in generating the message packet, not negotiated by the method provided by the present invention;
  • Key Start Accept The router starts accepting Key IDs from ten businesses (ie
  • the time of the generated message packet is measured in units of 24 hours per day, which is assumed to be 6 hours.
  • (6) Key Start Generate The time when the router starts to use the negotiated Key ID to generate the message packet.
  • the cycle time is measured in units of 24 hours per day, and the branch is set to 8;
  • Key Stop Generate The time when the router stops using the negotiated Key ID to generate a message packet.
  • the cycle time is measured in units of 24 hours per day, which is assumed to be 20 hours.
  • the time of the message packet, in this example, the cycle time is measured in units of 24 hours per day, and is set to 23 hours.
  • OSPFv2 has five message types: Hello, Database Description, Link State Request, Link State Update, and Link State Acknowledgment.
  • This example assumes that the SA usage policy is: The five SAs on each OSPFv2 interface use the same SA.
  • Figure 7 shows the specific process of negotiating an SA on an interface. It is divided into two phases. The SA negotiation in the first phase generates IKE_SA, which is used to protect the subsequent negotiation channel. The CHILD SA generated in the second phase is used to The routing protocol provides the Key ID, Authentication Algorithm, Life Time, etc. required by its SA, and the Authentication Key is generated by the DH exchange algorithm. The specific contents of the exchange are shown in Table 1 below: Table 1
  • the contents of the message payload are all defined by IKEv2, where HDR is the IKE header, SAil is the initiator's first SA payload, and SAei2 is the initiator's second SA payload, which is extended by this embodiment.
  • KEi is the initiator's key exchange (ie DH exchange) payload;
  • Ni is the random number payload generated by the initiator;
  • SArl, KEr, Nr in turn represent the first SA payload responded by the responder, and the responder's secret Key exchange (ie DH exchange) payload and responder generated random number payload
  • SAer2 represents the second SA payload of the responder's response, which is extended by this embodiment;
  • IDi and IDr respectively represent the identity payload of the initiator and responder TSi and TSR represent the traffic selector payload of the initiator and the responder, respectively;
  • AUTH represents the authentication payload, which is obtained by the IKEv2 deterministic calculation method;
  • CERTREQ represents the certificate
  • this embodiment implements negotiation of an SA for a routing protocol by adding a new SA payload for a routing protocol in IKEv2.
  • a new payload is added to the routing protocol SA, which is labeled as SARP, that is, the Security Association for Routing Protocol, and the value of the Next Payload Type can be selected from any of 49-127 of RESERVED TO IANA, preferably, in the present
  • the value of £ is set to 49 to distinguish it from other loads, especially the original SA load (the value of its Next Payload Type is 33).
  • the structure of the SARP payload is similar to the original SA payload of IKEv2. The differences include, but are not limited to, the following:
  • the Transform Type of the transform substructure can be considered to define only the Pseudo-random Function (PRF, pseudo-random number function), Integrity Algorithm (INTEG, integrity algorithm), Sequence Numbers (SN) for the routing protocol SA. (series number), etc.;
  • PRF Pseudo-random Function
  • INTEG Integrity Algorithm
  • SN Sequence Numbers
  • transform type PRF of the transform substructure defines the Transform ID of the pseudo-random number function that may be used for the routing protocol SA
  • the transform type INTEG of the transform substructure defines a Transform ID of the authentication algorithm that may be used for the routing protocol SA;
  • the Data Attribute of the transformation substructure defines a pseudo-random number function of the routing protocol SA or the negotiation of the key length of the authentication algorithm, wherein the key length of the algorithm is not fixed length of.
  • the Authentication Key used by the routing protocol SA is calculated by the KE payload provided by IKEv2, the Ni payload, the Nr payload, and the PRF algorithm provided by the above SARP payload.
  • the SA negotiation process of the two KMP peers is similar to that in Embodiment 3, and the corpse is step 4, S204, and S206.
  • the SA load is divided into another. .
  • Embodiment 5 As shown in FIG.
  • this embodiment implements negotiation of an SA for a routing protocol by adding a new exchange type for a routing protocol in IKEv2.
  • a new exchange type (Exchange Type) is added for the negotiation of the routing protocol SA, which is marked as IKE RP AUTH
  • the value of the Exchange Type can be selected from any of 38-239 of RESERVED TO IANA, preferably,
  • the value of the support is 38, which is different from other exchange types, especially IKE_AUTH (the value of Exchange Type is 35).
  • the load involved in the IKE RP AUTH exchange is similar to IKE_AUTH except that the SA payload is different.
  • Embodiment 3 may be used, or the newly added SARP payload in Embodiment 4 may be used instead of the SA payload in IKE_AUTH to complete the negotiation of the routing protocol SA.
  • the content in the dotted line box is optional, and the content in the solid line box is mandatory.
  • Embodiment 6 FIG.
  • FIG. 10 is another preferred schematic diagram of a key management system for a routing protocol according to an embodiment of the present invention, including: an expansion unit 1002, configured to extend an Internet Key Exchange Protocol Second Edition IKEv2;
  • the negotiation unit 1004 is configured to generate a security association SA for the routing protocol by using the extended IKEv2 negotiation, and the processing unit 1006 is configured to perform key management on the routing protocol by using the generated SA, and perform a key management on the routing protocol by using the generated SA.
  • the transport implementation of the routing message is protected.
  • the extended IKEv2 is used to negotiate and generate an SA for the routing protocol. The problem of the efficiency and correctness caused by the negotiation method of the SA for the routing protocol in the prior art is solved, and the transmission of the routing message is more secure and reliable.
  • the extension unit 1002 includes: a first expansion module, configured to add a field related to a routing protocol to the original SA payload of the IKEv2; and a second expansion module, configured to add the IKEv2
  • the SA payload of the routing protocol where the SA payload for the routing protocol carries a field related to the routing protocol.
  • the IKEv2 can be flexibly extended so that the negotiation of the SA for the routing protocol can be implemented.
  • the first expansion module includes: a first processing submodule, configured to add a protocol identifier field and a key identifier field for the routing protocol in the proposal substructure Proposal Substructure in the original SA payload a second processing submodule, configured to add a transform type field and a transform identifier field for the routing protocol in the transform substructure in the original SA payload; a third processing submodule, configured to The key length field for the routing protocol and the time-to-live field of the SA are added to the attribute type in the transform substructure.
  • the sub-modules mentioned in the preferred embodiment are implemented to expand on the basis of the original SA load, so that the complexity corresponding to the expansion can be reduced, and the embodiment of the present invention can be easily implemented.
  • the second expansion module includes: a construction submodule for constructing the same SA payload as the original SA payload; and a third processing submodule for proposing in the constructed SA payload a sub-structure Proposal Substructure adds a time-to-live field of the SA for the routing protocol and the time-to-live length field; a fourth processing sub-module for SPI size in the proposed sub-structure Proposal Substructure in the constructed SA payload
  • the field is replaced with a key identifier field for the routing protocol, and the SPI field is replaced with a key identifier field for the routing protocol.
  • the extension unit 1002 includes: a third extension module, configured to add, in the IKEv2, an exchange type for a routing protocol, where the exchange type is used to indicate that the exchange type is used in an exchange corresponding to the exchange type.
  • the SA payload of the original IKEv2 of the field associated with the routing protocol is added, or the added SA payload for the routing protocol is used.
  • the exchange type added to the SA for the routing protocol in the preferred embodiment is such that the two parties negotiated by the SA can negotiate the SA more easily, which improves the efficiency of the negotiation.
  • the negotiating unit 1004 includes: a first negotiating module, configured to use the foregoing IKEv2 Negotiating to generate an SA for establishing a secure channel; establishing a module for establishing a secure channel by using the generated SA; and a second negotiation module, configured to generate a security association for the routing protocol by using the extended IKEv2 negotiation on the secure channel SA.
  • a first negotiating module configured to use the foregoing IKEv2 Negotiating to generate an SA for establishing a secure channel
  • establishing a module for establishing a secure channel by using the generated SA and a second negotiation module, configured to generate a security association for the routing protocol by using the extended IKEv2 negotiation on the secure channel SA.
  • the negotiating unit 1004 includes: a third negotiating module located on the first router, and a fourth negotiating module located on the second router that is peered with the first router, where the third negotiating module, And the group of the one or more groups of the routing protocol-related fields supported by the first router is used to fill in a corresponding field in the extended IKEv2, by using the extended IKEv2 Transmitting the one or more sets of the routing protocol related fields to the fourth negotiation module, and constructing, by the fourth negotiation module, a set of routing protocol related fields for the a routing protocol used by the first router to communicate with the second router
  • the fourth negotiation module is configured to select, from the one or more groups of the routing protocol-related fields, a group of the routing protocol-related fields, and send the third negotiation to the third negotiation by using the extended IKEv2 a module, and constructing the selected set of routing protocol related fields as an SA for a routing protocol used for communication between the first router and the second router.
  • the negotiation of the SA for the routing protocol can be effectively completed by the negotiating unit mentioned in the preferred embodiment.
  • the processing unit 1006 performs key management on the routing protocol using the generated SA and performs protection on the transmission of the routing message, including: using the generated SA as a router of the sender The key material of the routing protocol is updated, and the authentication code is calculated and filled for the routing message to be sent; the routing protocol used as the receiving party uses the generated SA to update the keying material of the routing protocol, and performs integrity authentication on the received routing message.
  • the embodiments of the present invention can solve the problems existing in the prior art, so that the routing protocol can negotiate and generate and manage the required SAs by using the out-of-band KMP IKEv2-based multiple extension manners to meet the routing security automatic key management and The need for updates to meet the need for secure transmission of routed messages.
  • the steps shown in the flowchart of the accompanying drawings may be performed in a computer system such as a set of computer executable instructions, and, although the logical order is shown in the flowchart, in some cases, The steps shown or described may be performed in an order different than that herein.
  • modules or steps of the present invention can be implemented by a general-purpose computing device, which can be concentrated on a single computing device or distributed over a network composed of multiple computing devices. Alternatively, they may be executed by a computing device
  • the program code is implemented so that they can be stored in the storage device by the computing device, or they can be separately fabricated into individual integrated circuit modules, or a plurality of modules or steps can be made into a single integrated circuit module.
  • the invention is not limited to any specific combination of hardware and software.
  • the above is only the preferred embodiment of the present invention, and is not intended to limit the present invention, and various modifications and changes can be made to the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the scope of the present invention are intended to be included within the scope of the present invention.

Abstract

本发明公开了一种用于路由协议的密钥管理方法和系统，其中，该方法包括：扩展互联网密钥交换协议第二版IKEv2；使用扩展后的上述IKEv2协商生成用于路由协议的安全联盟SA；使用生成的上述SA对路由协议进行密钥管理，并对基于上述路由协议的路由消息的传输实施保护。本发明解决了现有技术中用于路由协议的SA的协商方法导致的效率和正确性较低的问题，达到了路由消息的传送更为安全可靠的效果。

Description

用于路由协议的密钥管理方法和系统 技术领域 本发明涉及通信网络中的路由安全技术， 具体而言， 涉及一种用于路由 协议的密钥管理方法和系统。 背景技术 路由器是现代 IP网路最重要和核心的组成设备，为数据包的传输提供路 由信息。 路由器依靠在其上运行的路由协议进行路由信息的收集并计算和管 理最佳路由。 由于路由信息在网络中是明文传播的， 伪造和篡改路由消息包 非常容易。 如果路由器接受这种路由消息包， 将产生错误的路由， 导致部分 或全部网络数据包无法到达指定目的地或接收者， 数据业务无法正常进行。 因此， 需要对路由消息进行完整性保护。 目前绝大部分的路由协议都提供完整性保护机制， 而实施该机制需要一 套密钥材料， 被称之为安全联盟 （SA ), 对于路由协议而言， 主要包括完整 性算法和密钥。 当前主要使用的路由协议都没有提供 SA的协商机制， 而是 靠被称之为管理员 （administrator )的人进行手动配置和更新。 人手动配置和 更新存在的问题是， 一方面不可靠、 容易出错， 另一方面速度慢， 不适用于 现代大规模网络。 随着攻击者计算能力的提高和攻击技术的层出不穷， 网络 遭受攻击和破坏的概率和频率也越来越高， 而业务价值快速增长的现代网络 为此付出的代价也越来越大， 因此， 网络运营者一方面要预防网络攻击和破 坏， 另一方面在网络遭受攻击和破坏的情况下要快速恢复和修复， 这就需要 为路由器及路由协议提供自动密钥管理的功能， 实现密钥材料的自动配置、 更新和协商， 也即实现路由安全的密钥管理协议 （KMP )。 可见， 才艮据现有的技术， 无法通过由系统自动实现路由协议的 SA的协 商和生成， 从而降氏了配置 SA时的效率和正确性。 发明内容 针对现有技术中用于路由协议的 SA的协商方法导致的效率和正确性较 氐的问题而提出本发明， 为此， 本发明的主要目的在于提供一种用于路由协 议的密钥管理方法和系统， 以解决上述问题至少之一。 为了实现上述目的， 根据本发明的一个方面， 提供了一种用于路由协议 的密钥管理方法， 其包括： 扩展互联网密钥交换协议第二版 IKEv2; 使用扩 展后的上述 IKEv2协商生成用于路由协议的安全联盟 SA; 使用生成的上述 SA 对路由协议进行密钥管理， 并对基于上述路由协议的路由消息的传输实 施保护。 进一步地， 上述扩展互联网密钥交换协议第二版 IKEv2的步骤包括以下 之一： 在上述 IKEv2的原有 SA载荷中增加与路由协议相关的字段； 或者在 上述 IKEv2中增加用于路由协议的 SA载荷，其中， 上述用于路由协议的 SA 载荷中携带与路由协议相关的字段。 进一步地， 在上述 IKEv2的原有 SA载荷中增加与路由协议相关的字段 包括： 在上述原有 SA载荷中的提议子结构 （Proposal Substructure ) 中增加 用于路由协议的协议标识符字段和密钥标识符字段； 在上述原有 SA载荷中 的变换子结构 （Transform Substructure ) 中增加用于路由协议的变换类型字 段、 变换标识符字段； 在上述变换子结构 （Transform Substructure ) 中属性 类型中增加用于路由协议的密钥长度字段和 SA的生存时间字段。 进一步地， 上述扩展互联网密钥交换协议第二版 IKEv2的步骤还包括： 在上述 IKEv2中增加用于路由协议的交换类型， 其中， 上述交换类型用于指 示在上述交换类型对应的交换中使用增加了与路由协议相关的字段的上述原 有 SA载荷。 进一步地， 在上述 IKEv2中增加用于路由协议的 SA载荷包括： 构建与 上述原有 SA载荷的结构相同的 SA载荷；在上述构建的 SA载荷中的提议子 结构 （Proposal Substructure ) 中增加用于路由协议的 SA的生存时间字段以 及上述生存时间长度字段； 在上述构建的 SA载荷中的提议子结构（Proposal Substructure ) 中将 SPI大小字段替换成用于路由协议的密钥标识符字段， 并 将 SPI字段替换成用于路由协议的密钥标识符字段。 进一步地， 上述扩展互联网密钥交换协议第二版 IKEv2的步骤还包括： 在上述 IKEv2中增加用于路由协议的交换类型， 其中， 上述交换类型用于指 示在上述交换类型对应的交换中使用上述增加的用于路由协议的 SA载荷。 进一步地，
SA的步骤包括： 使用上述 IKEv2协商生成用于建立安全通道的 SA; 使用生 成的 SA建立安全通道； 在上述安全通道上使用扩展后的 IKEv2协商生成用 于路由协议的安全联盟 SA。
SA 的步骤包括： 第一路由器将其支持的一组或多组上述与路由协议相关的 字段中的每一组填入到上述扩展后的 IKEv2中对应的字段中； 上述第一路由 器通过上述扩展后的 IKEv2将上述一组或多组上述与路由协议相关的字段发 送给与上述第一路由器对等的第二路由器； 上述第二路由器从上述一组或多 组与路由协议相关的字段中选择一组与路由协议相关的字段， 并通过上述扩 展后的 IKEv2发送给上述第一路由器； 上述第一路由器与上述第二路由器将 上述选择的一组与路由协议相关的字段构建成用于上述第一路由器与上述第 二路由器之间通信使用的路由协议的 S A。 为了实现上述目的， 根据本发明的另一方面， 提供了一种用于路由协议 的密钥管理系统， 其包括： 扩展单元， 用于扩展互联网密钥交换协议第二版 IKEv2; 协商单元， 用于使用扩展后的上述 IKEv2协商生成用于路由协议的 安全联盟 SA;处理单元，用于使用生成的上述 SA对路由协议进行密钥管理， 并对基于上述路由协议的路由消息的传输实施保护。 进一步地， 上述扩展单元包括： 第一扩展模块， 用于在上述 IKEv2的原 有 SA载荷中增加与路由协议相关的字段；第二扩展模块，用于在上述 IKEv2 中增加用于路由协议的 SA载荷， 其中， 上述用于路由协议的 SA载荷中携 带与路由协议相关的字段。 进一步地， 上述第一扩展模块包括： 第一处理子模块， 用于在上述原有 SA载荷中的提议子结构（ Proposal Substructure )中增加用于路由协议的协议 标识符字段和密钥标识符字段； 第二处理子模块， 用于在上述原有 SA载荷 中的变换子结构 （Transform Substructure ) 中增加用于路由协议的变换类型 字段、变换标识符字段； 第三处理子模块，用于在上述变换子结构（Transform Substructure ) 中属性类型中增加用于路由协议的密钥长度字段和 SA的生存 时间字段。 进一步地， 上述第二扩展模块包括： 构建子模块， 用于构建与上述原有 SA载荷的结构相同的 SA载荷； 第三处理子模块， 用于在上述构建的 SA载 荷中的提议子结构 （ Proposal Substructure ) 中增加用于路由协议的 S A的生 存时间字段以及上述生存时间长度字段； 第四处理子模块， 用于在上述构建 的 SA载荷中的提议子结构 （Proposal Substructure ) 中将 SPI大小字段替换 成用于路由协议的密钥标识符字段， 并将 SPI字段替换成用于路由协议的密 钥标识符字段。 进一步地， 上述扩展单元包括： 第三扩展模块， 用于在上述 IKEv2中增 加用于路由协议的交换类型， 其中， 上述交换类型用于指示在上述交换类型 对应的交换中使用上述增加了与路由协议相关的字段的 IKEv2的原有 S A载 荷， 或者， 使用上述增加的用于路由协议的 SA载荷。 进一步地， 上述协商单元包括： 第一协商模块， 用于使用上述 IKEv2协 商生成用于建立安全通道的 SA; 建立模块， 用于使用生成的 SA建立安全通 道； 第二协商模块， 用于在上述安全通道上使用扩展后的 IKEv2协商生成用 于路由协议的安全联盟 SA。 进一步地， 上述协商单元包括： 位于第一路由器上的第三协商模块以及 位于与上述第一路由器对等的第二路由器上的第四协商模块， 其中， 上述第 三协商模块， 用于将上述第一路由器支持的一组或多组上述与路由协议相关 的字段中的每一组填入到上述扩展后的 IKEv2中对应的字段中， 通过上述扩 展后的 IKEv2将上述一组或多组上述与路由协议相关的字段发送给与上述第 四协商模块， 并将由上述第四协商模块选择的一组与路由协议相关的字段构 建成用于上述第一路由器与上述第二路由器之间通信使用的路由协议的 S A; 上述第四协商模块， 用于从上述一组或多组与路由协议相关的字段中选择一 组与路由协议相关的字段， 通过上述扩展后的 IKEv2发送给上述第三协商模 块， 并将上述选择的一组与路由协议相关的字段构建成用于上述第一路由器 与上述第二路由器之间通信使用的路由协议的 S A。 为了实现上述目的， 根据本发明的又一方面， 提供了另一种用于路由协 议的密钥管理系统， 其包括： 彼此两两相连的 KMP单元、 路由协议单元和 密钥库单元， 其中， 上述 KMP单元， 用于对互联网密钥交换第二版 IKEv2 进行扩展， 并使用扩展后的 IKEv2协商生成用于路由协议的安全联盟 SA; 上述路由协议单元， 用于为运行的路由协议与上述 KMP单元、 上述密钥库 单元提供交互和接口功能； 上述密钥库单元， 用于存储上述 KMP单元和上 述路由协议单元使用的密钥材料。 进一步地， 上述 KMP单元包括： SA生成模块、 SA使用策略模块和 SA 库模块， 其中， 上述 SA生成模块， 用于根据上述 SA使用策略模块的指令 调用上述扩展后的 IKEv2来协商生成用于路由协议的 S A; 上述 S A库模块， 用于存放并管理由上述 SA生成模块协商生成的 SA;上述 SA使用策略模块， 用于通过指令指导上述 SA生成模块协商生成 SA, 并通过指令指导上述 SA 库模块对 SA的存取。 进一步地， 上述 SA生成模块包括： 第一扩展子模块， 用于在上述 IKEv2 的原有 SA载荷中增加与路由协议相关的字段； 第二扩展子模块， 用于在上 述 IKEv2 中增加用于路由协议的 SA载荷， 其中， 上述用于路由协议的 SA 载荷中携带与路由协议相关的字段。 进一步地， 上述 SA生成模块还包括： 第三扩展模块， 用于在上述 IKEv2 中增加用于路由协议的交换类型， 其中， 上述交换类型用于指示在上述交换 类型对应的交换中使用上述增加了与路由协议相关的字段的 IKEv2 的原有 SA载荷， 或者， 使用上述增加的用于路由协议的 SA载荷。 通过本发明， 釆用扩展后的 IKEv2来协商生成用于路由协议的 SA, 解 决了现有技术中用于路由协议的 SA的协商方法导致的效率和正确性较氐的 问题， 进而达到了路由消息的传送更为安全可靠的效果。 本发明的其它特征和优点将在随后的说明书中阐述， 并且， 部分地从说 明书中变得显而易见， 或者通过实施本发明而了解。 本发明的目的和其他优 点可通过在所写的说明书、 权利要求书、 以及附图中所特别指出的结构来实 现和获得。 附图说明 此处所说明的附图用来提供对本发明的进一步理解， 构成本申请的一部 分， 本发明的示意性实施例及其说明用于解释本发明， 并不构成对本发明的 不当限定。 在附图中： 图 1是才艮据本发明实施例的用于路由协议的密钥管理系统的一种优选示 意图； 图 2是图 1所示的系统中的 KMP单元的结构示意图； 图 3是图 1所示的 KMP单元的数据处理流程示意图； 图 4是根据本发明实施例的用于路由协议的密钥管理方法的一种优选流 程图; 图 5是根据本发明实施例的 IKEv2中的 SA载荷及其子结构相关字段的 示意图； 图 6是才艮据本发明实施例的对 IKEv2中的 SA载荷及其子结构相关字段 的扩展的示意图； 图 7是根据本发明实施例的基于 IKEv2的 SA载荷扩展的两个 KMP对 等体的 OSPFv2 SA协商流程示意图； 图 8是根据本发明实施例的基于 IKEv2的载荷类型扩展的新增载荷及其 子结构示意图； 图 9是根据本发明实施例的基于 IKEv2的交换类型扩展的新增交换 SA 协商流程示意图； 图 10 是才艮据本发明实施例的用于路由协议的密钥管理系统的另一种优 选示意图。 具体实施方式 下文中将参考附图并结合实施例来详细说明本发明。 需要说明的是， 在 不冲突的情况下， 本申请中的实施例及实施例中的特征可以相互组合。 在描述本发明实施例之前， 首先对本发明使用到的 KMP以及 IKEv2进 行描述。 按照设计方式， 针对路由安全的 KMP 分为带内 （ in-band ) 和带外 ( out-band )两种。 In-band KMP使用路由协议本身的消息包来管理和分发密 钥材料， 通过修改路由消息包的某些字段， 或者扩展保留字段等手段来装载 密钥材料。 另一方面， Out-band KMP是以独立于路由协议之外的一个功能模 块或一套软件或一个实体的方式为路由协议提供密钥管理， 其优点是其规模 与功能的可扩展性好， 可操作性强， 无需改动现有的路由协议， 是被业界认 可的技术发展方向和趋势。 目前存在针对 IP层或以上的传输层和应用层的数 据安全通信的 KMP 方法， 比如下面将要描述的互联网密钥交换第二版 ( IKEv2 )„ IKEv2是为互联网协议第六版（ IPv6 ) IP层的数据安全传输机制（ IPsec ) 提供 SA协商的协议。 该协议也支持互联网协议第四版（ IPv4 )。 IKEv2的 SA 协商过程前后总共可涉及四类交换， 即 IKE SA INIT交换、 IKE_AUTH交 换、 CREATE CHILD S A交换和 INFORMATIONAL交换， 其中前两类交换 合称为初始交换 ( Initial Exchange )„ IKEv2中的交换 ( Exchange ) 由一个请 求 （request ) 和一个响应 ( response ) 组成， 发生在两个网络对等体 （peer ) 之间， 其中发起请求的 peer称为发起者 （Initiator, 通常用 i表示）， 回应的 peer称为回应者 ( Responder, 通常用 r表示）。
IKE SA INIT交换协商密码算法（ crytographic algorithms ), 交换随机数 (nonces)、 进行 Diffie-Hellman ( D-H ) 交换， 为两个 peer协商安全参数以生 成 IKE_SA, 为其后的交换提供安全通道。
IKE AUTH交换是在 IKE_SA的保护下进行的， 对 peer身份进行认证， 并协商生成第一个 CHILD_SA, 为 IPsec的封装安全载荷 （ ESP ) 或 /和认证 头 （ AH ) 提供 SA。 CREATE CHILD SA 交 换 生 成 其 他 的 CHILD S A , — 个
CREATE CHILD SA生成一个 CHILD S A, 这个生成的 CHILD S A可用来 更新上述交换生成的 IKE_SA 或第一个 CHILD_SA , 也可以是全新的 CHILD SA, 供给 ESP或 /和 AH使用。
INFORMATIONAL 交换用作传输控制信息， 包括报错和事件通知。 INFORMATIONAL交换只能发生在 Initial Exchange之后， 并在已经协商出 来的密钥保护下进行。一个 INFORMATIONAL交换消息包含零到多个通知、 删除 （指对 SA进行删除） 和配置 （指在 peer之间交换配置信息） 载荷。 包 含零个载荷的 request和 response消息用作确认 peer的生死情况。
IKEv2在 IP层为 IPsec的 ESP和 AH协议提供了很好的 SA协商机制， 但是并没有针对其他协议比如路由协议提供 SA的协商和生成。 路由协议的 SA 与 ESP 和 AH 的 SA 内容不同， 前者主要包括 key ID、 认证算法 ( Authentication Algorithm )、 认证密钥 (Authentication Key)、 生存时间 ( Life Time ) 和序歹 'J号 ( Sequence Number ) 等。 由于传统的 IKEv2无法直接用来协商生成用于路由协议的 SA, 因此本 发明对 IKEv2进行了扩展，从而能够使用扩展后的 IKEv2来协商生成用于路 由十办议的 SA。 实施例 1 如图 1所示， 本实施例提供了一种用于路由协议的密钥管理系统， 优选 的， 该系统是基于 IKEv2扩展的路由协议 SA的带外 KMP的软件或软硬件 结合的系统。 该系统具体包括：
1 ) KMP单元 102 , 用于管理路由协议的 SA, 为路由协议单元 104提供 SA的协商生成和使用指导。 具体的， KMP单元 102用于对互联网密钥交换 第二版 IKEv2进行扩展，并使用扩展后的 IKEv2协商生成用于路由协议的安 全联盟 SA。 优选的， 所述 KMP单元 102包括 SA生成模块 202、 SA库模块 204和
S A使用策略模块 206 , 其中， SA生成模块 202、 SA库模块 204和 SA使用 策略模块 206彼此连接， 具体连接关系如图 2所示。 所述 SA生成模块 202用于才艮据 SA使用策略模块 206的指导调用扩展 的 IKEv2来协商生成用于路由协议的 SA, 其中， 协商生成用于路由协议的 S A的具体步骤将在以下的说明书中进行详细的描述。 所述 SA库模块 204用于存放并管理由 SA生成模块 202协商生成的 SA。 所述 SA使用策略模块 206用于 SA使用策略的设定并实施， 以指导 SA 生成模块 202协商生成 SA, 并指导 SA库模块 204对 SA的存取等。 可选地， 除了上述功能模块划分方式之外， 上述 KMP单元的功能划分 还可以有其他多种方式， 可以理解的是， 其他划分方式或不划分也在本发明 的保护范围之内。
2 ) 路由协议单元 104 , 用于为运行的各种路由协议与 KMP单元 102、 密钥库单元 106提供交互和接口功能；
3 ) 密钥库单元 106 , 用于为 KMP单元 102和路由协议单元 104存放所 使用的各种密钥材料， 优选的， 这些密钥材料包括各种密码算法和认证材料 等； 优选的， 本实施例中的系统还可以包括手动配置单元 108 , 用于为管理 员手动配置密钥库单元提供接口功能， 从而使得本发明可以支持手动配置。 优选的， 如图 3所示， 图 1 中的 KMP单元的数据处理流程是基于相邻 链路数和每条相邻链路的接口数， 釆用循环处理的方式， 可以包括但不限于 以下步 4聚： 步骤 S302 : 调用相应的检测程序， KMP单元确定与所驻存的路由器相 邻的链路数 N和每条相邻链路上的接口数目 M; 步骤 S304 : 与每条相邻链路的 KMP对等体（ KMP Peer )协商该链路的 IKE SA, 无论协商成功与否， 当处理完一条相邻链路时， N值减 1 ; 步骤 S306: 如果链路 IKE_SA协商不成功， 并且还没有穷尽（即， N≠0 ), 则返回步骤 S304进行下一条链路的 IKE_SA的协商；如果链路 IKE SA协商 成功， 或者链路已经穷尽 （即， N=0 ), 则转至步骤 S308; 步骤 S308: 在步骤 S304建立起来的 IKE_SA安全通道上， 与 KMP对 等体为该链路上运行路由协议的接口协商路由协议所需的 SA , 无论协商成 功与否， 当处理完一个接口时， M值减 1 ; 步骤 S3 10 : 如果接口路由协议 SA协商不成功， 并且还没有穷尽（即，
M≠0 ), 则返回步骤 S308进行下一个接口的路由协议 SA的协商； 如果接口 路由协议 SA协商成功， 或者接口已经穷尽（即， M=0 ), 则转至下一个步骤 S312; 步骤 S3 12 : 如果链路还没有穷尽 （即， N≠0 ), 则返回步骤 S304; 否则 结束。 可选地， 根据 SA的使用策略周期性地或基于事件触发式地进行流程处 理， 如果是基于接口事件触发式地进行流程处理， 则上述数据流程改为至少 包含步骤 S304和 S308。 在本实施例中， 系统的 KMP单元与路由协议单元、 密钥库单元、 手动 配置单元互动， 从而完成对不同路由协议的不同 SA的协商生成和存取。 实施例 2 图 4是根据本发明实施例的用于路由协议的密钥管理方法的一种优选流 程图， 其包括如下步骤:
S402 , 扩展互联网密钥交换协议第二版 IKEv2;
S404, 使用扩展后的 IKEv2协商生成用于路由协议的安全联盟 SA;
S406, 使用生成的 SA对所述路由协议进行密钥管理， 并对基于所述路 由协议的路由消息的传输实施保护。 通过本实施例， 釆用扩展后的 IKEv2来协商生成用于路由协议的 SA, 解决了现有技术中用于路由协议的 SA的协商方法导致的效率和正确性较氐 的问题， 进而达到了路由消息的传送更为安全可靠的效果。 优选的， 对互联网密钥交换协议第二版 IKEv2进行扩展的步骤包括以下 之一： 在所述 IKEv2的原有 SA载荷中增加与路由协议相关的字段； 或者在 所述 IKEv2中增加用于路由协议的 SA载荷，其中， 所述用于路由协议的 SA 载荷中携带与路由协议相关的字段。 通过本优选实施例中提到的两种扩展方 式， 可以灵活地对 IKEv2进行扩展， 以便可以实现用于路由协议的 SA的协 商。 优选的， 在所述 IKEv2的原有 SA载荷中增加与路由协议相关的字段包 括： 在所述原有 SA载荷中的提议子结构 Proposal Substructure中增加用于路 由协议的协议标识符字段和密钥标识符字段； 在所述原有 SA载荷中的变换 子结构 Transform Substructure中增加用于路由协议的变换类型字段、 变换标 识符字段； 在所述变换子结构 Transform Substructure中属性类型中增加用于 路由协议的密钥长度字段和 SA的生存时间字段。 通过本优选实施例中提到 的在原有 SA载荷的基础上进行扩展的方式，可以降低扩展所对应的复杂度， 便于实现本发明实施例。 优选的， 所述对互联网密钥交换协议第二版 IKEv2进行扩展的步骤还包 括： 在所述 IKEv2中增加用于路由协议的交换类型， 其中， 所述交换类型用 于指示在所述交换类型对应的交换中使用增加了与路由协议相关的字段的所 述原有 SA载荷。 通过本优选实施例中特定为用于路由协议的 SA增加的交 换类型， 使得 SA协商的双方可以更容易进行 SA的协商， 提高了协商的效 率。 优选的， 在所述 IKEv2中增加用于路由协议的 SA载荷包括： 构建与所 述原有 SA载荷的结构相同的 SA载荷；在所述构建的 SA载荷中的提议子结 构 Proposal Substructure中增加用于路由协议的 SA的生存时间字段以及所述 生存时间长度字段； 在所述构建的 SA 载荷中的提议子结构 Proposal Substructure中将 SPI大小字段替换成用于路由协议的密钥标识符字段，并将 SPI 字段替换成用于路由协议的密钥标识符字段。 通过本优选实施例中提到 的新增 SA的扩展方式， 可以更好的便于 SA协商的双方进行识别， 提高了 协商的效率。 优选的， 所述对互联网密钥交换协议第二版 IKEv2进行扩展的步骤还包 括： 在所述 IKEv2中增加用于路由协议的交换类型， 其中， 所述交换类型用 于指示在所述交换类型对应的交换中使用所述增加的用于路由协议的 SA载 荷。 通过本优选实施例中特定为用于路由协议的 SA增加的交换类型， 使得 SA协商的双方可以更容易进行 SA的协商， 提高了协商的效率。 优选的， 在上述各个优选实施例的基础上， 使用扩展后的 IKEv2协商生 成用于路由协议的安全联盟 SA的步骤包括： 使用 IKEv2协商生成用于建立 安全通道的 SA; 使用生成的 SA建立安全通道； 在所述安全通道上使用扩展 后的 IKEv2协商生成用于路由协议的安全联盟 SA。 通过本优选实施例中提 到的安全通道， 可以进一步保证协商用于路由协议的 SA时的安全性。 优选的， 在上述各个优选实施例的基础上， 使用扩展后的 IKEv2协商生 成用于路由协议的安全联盟 SA的步骤包括： 第一路由器将其支持的一组或 多组所述与路由协议相关的字段中的每一组填入到所述扩展后的 IKEv2中对 应的字段中； 所述第一路由器通过所述扩展后的 IKEv2将所述一组或多组所 述与路由协议相关的字段发送给与所述第一路由器对等的第二路由器； 所述 第二路由器从所述一组或多组与路由协议相关的字段中选择一组与路由协议 相关的字段， 并通过所述扩展后的 IKEv2发送给所述第一路由器； 所述第一 路由器与所述第二路由器将所述选择的一组与路由协议相关的字段构建成用 于所述第一路由器与所述第二路由器之间通信使用的路由协议的 SA。 通过 本优选实施例中提到的 SA 协商过程， 可以有效的完成用于路由协议的 SA 的协商。 优选的， 在上述各个优选实施例的基础上， 使用生成的 SA对基于所述 路由协议进行密钥管理和对路由消息的传输实施保护的步骤包括： 作为发送 方的路由协议使用生成的 SA更新路由协议的密钥材料， 对将要发送的路由 消息进行认证码计算和填充； 作为接收方的路由协议使用生成的 SA更新路 由协议的密钥材料， 对接收到的路由消息进行完整性认证。 本发明提出来以下几种方案来具体实现使用扩展后的 IKEv2协商生成用 于路由十办议的 SA, 这些方案可以应用到实施例 1 的系统和实施例 2的方法 中。 方案一： 对于 IKEv2中原有的用于 SA的字段进行扩展 图 5是根据本发明实施例的 IKEv2中的 SA载荷及其子结构相关字段的 示意图。如图 5所示， IKEv2中的 SA载荷包括通用载荷头部（ Generic Payload Header )和提议子结构 (Proposal Substructure), 其中， 提议子结构包括变换子 结构 ( Transform Substructure ), 而变换子结构包括 Transform Attributes (变 换属性）。 对于 IKEv2中原有的用于 SA的字段进行扩展具体包括如下操作：
1 )扩展 IKEv2中原有的 SA载荷（ SA Payload )中的提议子结构 (Proposal Substructure)中的 Protocol ID (提议标识符 ) 字段和 SPI Size (安全参数索引 长度） 字段， 将路由协议包含进去； 2 ) 扩展提议子结构中的变换子结构 （ Transform Substructure ) 中的
Transform Type (变换类型） 字段及其 Transform ID (变换标识符） 字段， 使 之可用于路由协议用；
3 )扩展变换子结构中的 Transform Attributes(变换属性）的 Attribute Type
(属性类型） 字段， 使之可以装载路由协议 SA所需的密钥长度和 SA的生 存时间参数。 具体的， ^图 6所示， 对 IKEv2的 SA载荷的 Proposal Substructure的 Protocol ID字段和 SPI Size字段、 Transform Substructure的 Transform Type 字段的 3型和 Transform Attributes的 Attribute Type字段， 进行了扩展， 以提 供路由十办议 SA所需的 key ID、 Authentication Algorithm、 Authentication Key 和 Life Time等内容， 所述的 Protocol ID字段扩展包含路由协议， 所述的 SPI Size字段扩展包含 Key ID的长度，所述的 Transform Type字段扩展包含其可 以使用于路由协议中， 所述的 Transform ID字段的扩展包含路由协议使用的 Authentication Algorithm, 所述的 Attribute Type字段扩展包含路由十办议 SA 所需的密钥长度和的生存时间参数， 所述的扩展字段所扩展的定义所对应的 ID值的分配可以是一种或多种的组合。 方案二： 为路由协议安全联盟增加新的 payload 在本实施例中， 为路由协议安全联盟增加新的 payload, 标记为 SARP, 即 Security Association for Routing Protocol; SARP载荷的结构与 IKEv2的原 SA载荷相似， 不同的是， 在 Proposal子结构增加了 Length of Life Time (生 存时间长度 ) 字段及其装载具体参数的 Life Time字段， 用 Length of Key ID 字段取代 SPI Size字段， 相应的 Key ID字段取代 SPI ( variable ) 字段。 方案三：为路由协议安全联盟的协商增加新的交换类型（ Exchange Type ) 在本实施例中，为路由协议安全联盟的协商增加新的交换类型（ Exchange Type ), 标记为 IKE_RP_AUTH, 在该交换中， 可以使用上述方案一中的扩展 SA载荷， 也可以使用上述方案二中新增加的 SARP载荷， 以完成路由协议 SA的十办商。 为便于对本发明实施例的理解， 下面将结合附图对本发明实施例所提供 的使用扩展的 IKEv2来协商用于路由协议的 SA的方案进行详细说明。 实施例 3 如图 6所示， 本实施例通过在 IKEv2的原有 SA载荷中增加与路由协议 相关的字段来实现用于路由协议的 SA的协商。 其中， 对 IKEv2的原有 SA 载荷进行扩展 (为了和原 SA载荷区别， 扩展后的 SA载荷用 SAe表示， 但 是并不是新增的载荷类型） 包括但不限于以下步骤： ( 1 ) 扩展 SA载荷 （Payload ) 中的 Proposal子结构（Substructure)中的
Protocol ID字段和 SPI Size字段， 其中， Protocol ID字段增加路由协议比如 RIPv2 ( Routing Information Protocol version 2 , 对应于 IANA 值 4 )、 OSPFv2(Open Shortest Path First version 2 , 对应于 IANA 值 5) 、 ISIS(Intermediate System-to-intermediate System,对应于 IANA值 6)等 ό 定义， 每种路由协议对应于一个 IANA保留值 （取值范围是 4到 200 ), 其中， SPI 映射为路由协议的 SA的 Key ID字段， 由于路由协议的 Key ID长度不同， 因此对 SPI Size字段进行扩展， RIPv2, OSPFv2, ISIS等路由协议包含进 去；
( 2 )扩展 Proposal子结构中的 Transform子结构中的 Transform Type字 段的 3型 Integrity Algorithm(INEG)的 Transform ID字段，其中扩展 Transform Type字段的 3型 Integrity Algorithm(INEG) ,使之不但用于 IKE、 AH和 ESP, 还用于路由十办议（ Routing Protocols ),比 口 RIPv2和 OSPFv2,其中， Transform ID 字 段增 加 了 用 于 路 由 协议 的 认证 算 法 的 定 义 ， 比 如 AUTH HMAC SHA 224 (对应于 IANA值 7 )、 AUTH HMAC SHA 256 (对 应于 IANA 值 8 )、 AUTH HMAC SHA 384 (对应于 IANA 值 9 )、 AUTH HMAC SHA 512(对应于 IANA值 10 )等，每个定义对应于一个 IANA 保留值 （取值范围是 6到 1023 );
( 3 ) 扩展 Transform子结构中的 Transform Attributes的 Attribute Type 字段， 其中 Transform Attributes用于存放路由协议 SA用到的密钥长度 （该 密钥用于认证算法 ） 和 S A 的生存时间参数， 以三元组 TLV 的 Type/Length/Value格式或二元组 TV的 Type/Value格式表示， 具体包括：
( a )扩展 Attribute Type字段的 14型 Key Length ( in bits ), ^！夺其应用 范围从加密算法 （ Encryption Algorithm ) 扩大至包含认证算法， 如果认证算 法的密钥长度是固定的 （也即是， 认证算法的密钥长度是和算法捆绑的， 存 在 对应关系；)， 那么 Transform Attributes可省略， 如果认证算法的密钥长 度需要协商， 则使用经过扩展的 14型 Key Length ( in bits ), 釆用二元组 TV 格式；
( b )关于认证算法的密钥（ Authentication Key )的十办商， 两个 KMP Peer 通过 KE载荷相互交换随机数（应用 Diffie-Hellman交换， 简称 D-H算法） 并计算生成双方共享的 Authentication Key;
( c ) 关于 SA的生存时间参数， 通过对 Attribute Type字段的扩展来实 现，增加该字段对 Start Time (对应于 IANA值 18 ), Stop Time (对应于 IANA 值 19 )、 Key Start Accept (对应于 IANA值 20 )、 Key Start Generate (对应于 IANA值 21 )、 Key Stop Generate (对应于 IANA值 22 ) 和 Key Stop Accept (对应于 IANA值 23 )等的定义， 每个定义对应于一个 IANA保留值 (取值 范围是 18到 16383 ), 而每个定义的长度和取值分别由 Attribute Length和 Attribute Value字段表示。 以下描述具体的用于路由协议的 S A的协商过程。 如图 7所示， 本发明实施例为在网络类型为点到点 （Point-to-point ), 非 广播多 点传送 ( Nonbroadcast Multiaccess , ΝΒΜΑ )、 点 到 多 点 ( Point-to-multipoint )以及虚拟链路（ Virtual links )下运行的路由协议 OSPFv2 提供基于 IKEv2扩展的 SA协商的实现方案。
OSPFv2釆用 RFC 5709建议的完整性认证方式 （对应于 AuType=2, 即 Cryptographic authentication ), 釆用個—设的具体数据作为例子， 需要协商的 S A的内容包括但不限于：
( 1 ) Key ID: 长度为 8 bits(l octet), 本例子中^ _设的 Key ID见下面的 内容 2;
( 2 ) Authentication Algorithm: 本例子中 i设 Initiator提供可选用的有 AUTH HMAC SHA 256 (对应 Key ID为 1 )、 AUTH HMAC SHA 384 (对 应 Key ID为 2 )、 AUTH HMAC SHA 512 (对应 Key ID为 3 ), 而 Responder 选择釆用 AUTH_HMAC_SHA_256 (对应 Key ID为 1 );
( 3 ) Authentication Key: 本例子中個 _设双方釆用交换的随机数 nonce和 路由十办议已经配置的统一的 Pre-shared Key作为输入，经 D-H算法计算得到， 本例子中假设路由器釆用的身份认证方式为 Pre-shared Key,一般是在开局前 由 administrator统一手动 S己置的；
( 4 ) Cryptographic sequence number: 32位长的不递减的无符号数, 取 决于路由协议在生成消息包时釆用的具体实现算法， 不是由本发明所提供的 方法协商得到； ( 5 ) Key Start Accept: 路由器开始接受由十办商出来的 Key ID (即
Authentication Algorithm 和 Authentication Key ) 所生成的消息包的时间， 本 例子中使用以日即 24小时为单位的循环计时时间， 假设为 6时；
( 6 ) Key Start Generate: 路由器开始使用协商出来的 Key ID生成消息 包的时间， 本例子中使用以日即 24 小时为单位的循环计时时间， 支设为 8 时；
( 7 ) Key Stop Generate: 路由器停止使用协商出来的 Key ID生成消息 包的时间， 本例子中使用以日即 24小时为单位的循环计时时间， 假设为 20 时；
( 8 ) Key Stop Accept: 路由器停止接受由协商出来的 Key ID所生成的 消息包的时间， 本例子中使用以日即 24 小时为单位的循环计时时间， 设 为 23时。
OSPFv2 有五种消息类型： Hello , Database Description , Link State Request, Link State Update , Link State Acknowledgment。 本例子假设采用的 SA使用策略是： 每个 OSPFv2接口上的五种消息类型使用同一个 SA。 图 7所示是协商某个接口上的一个 SA的具体流程， 分为两个阶段， 第 一阶段的 SA协商产生 IKE_SA, 用于保护随后的协商通道， 第二阶段产生的 CHILD SA 用于为路由协议提供其 SA 所需的 Key ID , Authentication Algorithm和 Life Time等， 而 Authentication Key则由 D-H交换算法产生。 交换的具体内容如下表 1所示： 表 1
Figure imgf000018_0001
消息载荷中的内容都是来自 IKEv2的定义，其中 HDR是 IKE头部， SAil 是发起者的第一个 SA载荷， 而 SAei2则表示发起者的第二个 SA载荷， 是 经过本实施例扩展的； KEi 是发起者的密钥交换 （即 D-H 交换） 载荷； Ni 是发起者生成的随机数载荷； 相应地， SArl、 KEr、 Nr依次表示响应者回 应的第一个 SA载荷、 响应者的密钥交换 (即 D-H交换 ) 载荷和响应者生成 的随机数载荷， SAer2表示响应者回应的第二个 SA载荷， 是经过本实施例 扩展的； IDi和 IDr分别表示发起者和响应者的身份载荷， TSi和 TSr分别表 示发起者和响应者的流选择子（ traffic selector )载荷； AUTH表示认证载荷， 由 IKEv2定规的计算方法得到； CERTREQ表示证书请求载荷； []方括号表 示括号内的载荷是可选的， 不是必需的； SK{}表示花括号中的载荷都是使用 该方向 （图 7中箭头所指） 的 SA进行加密和完整性保护的。 其中， 本次 OSPFv2所协商的 SA包含在步骤 S704和 S706的 SA载荷 中， 主要内容如下表 2所示： 表 2
Figure imgf000019_0001
其中， KEYMAT表示密钥材料， {6,8,20,23 }表示 SA生存期的四个参数 取值。 实施例 4 如图 8所示， 本实施例通过在 IKEv2中增加新的用于路由协议的 SA载 荷来实现用于路由协议的 SA的协商。 具体的， 为路由协议 SA 增加新的载荷， 标记为 SARP , 即 Security Association for Routing Protocol , 其在 Next Payload Type 的取值可从 RESERVED TO IANA的 49-127中选取任一个， 优选的， 在本实施例中 £设 取值为 49,以和其他载荷区别，特别是和原有 SA载荷（其 Next Payload Type 的值为 33 ) 区别。 SARP载荷的结构与 IKEv2的原 SA载荷相似， 不同的地 方包括但不限于以下内容：
( 1 ) 在 Proposal子结构增力口了 Length of Life Time (生存时间长度 ) 字 段及其装载具体参数的 Life Time字段； ( 2 ) 用 Length of Key ID字段取代 SPI Size字段， 4目应的 Key ID字段 取代 SPI ( variable ) 字段；
( 3 ) 变换子结构的 Transform Type (变换类型）可以考虑只定义用于路由 协议 SA的 Pseudo-random Function (PRF,伪随机数函数)、 Integrity Algorithm (INTEG, 完整性算法）、 Sequence Numbers (SN, 系列号）等； ( 4 ) 变换子结构的变换类型 PRF定义可能用于路由协议 SA的伪随机 数函数的 Transform ID; ( 5 ) 变换子结构的变换类型 INTEG定义可能用于路由协议 SA的认证 算法的 Transform ID;
( 6 ) 变换子结构的数据属性部分 ( Data Attribute )定义可能用于路由协 议 SA的伪随机数函数或 \和认证算法的密钥长度的协商， 其中， 假设该算法 的密钥长度不是定长的。 而路由协议 SA用到的 Authentication Key则由 IKEv2提供的 KE载荷、 Ni载荷、 Nr载荷及上述 SARP载荷提供的 PRF算法经由计算得到。 在本实施例的扩展方式下，两个 KMP对等体的 SA协商流程类似实施例 3 ,尸、是步 4聚 S204和 S206 ^ SA载荷分另' J改为 ^口上所述 ό SARPi和 SARPr。 实施例 5 如图 9所示， 本实施例通过在 IKEv2中增加新的用于路由协议的交换类 型来实现用于路由协议的 SA的协商。 具体的， 为路由协议 S A的协商增加新的交换类型（ Exchange Type ) , 标 记为 IKE RP AUTH,其在 Exchange Type的取值可从 RESERVED TO IANA 的 38-239 中选取任一个， 优选的， 在本实施例中， 支设取值为 38, 以和其 他交换类型区别， 特别是 IKE_AUTH (其 Exchange Type的值为 35 ) 区别。 IKE RP AUTH交换涉及的载荷与 IKE_AUTH类似， 只是 SA载荷不同。 在 该交换中， 可以使用实施例 3 中经过扩展的 SA载荷， 也可以使用实施例 4 中的新增加的 SARP载荷， 来取代 IKE_AUTH中的 SA载荷， 以完成路由协 议 SA的协商， 具体流程见图 9, 虚线框内的内容表示可选， 实线框内的内 容表示必选， 图中其他相关内容可参考实施例 3、 实施例 4的说明， 在此不 再赘述。 实施例 6 图 10 是才艮据本发明实施例的用于路由协议的密钥管理系统的另一种优 选示意图， 其包括： 扩展单元 1002 , 用于扩展互联网密钥交换协议第二版 IKEv2; 协商单元 1004 , 用于使用扩展后的 IKEv2协商生成用于路由协议的 安全联盟 SA; 处理单元 1006 , 用于使用生成的 SA对所述路由协议进行密 钥管理， 并对基于所述路由协议的路由消息的传输实施保护。 通过本实施例， 釆用扩展后的 IKEv2来协商生成用于路由协议的 SA, 解决了现有技术中用于路由协议的 SA的协商方法导致的效率和正确性较氐 的问题， 进而达到了路由消息的传送更为安全可靠的效果。 优选的， 所述扩展单元 1002 包括： 第一扩展模块， 用于在所述 IKEv2 的原有 SA载荷中增加与路由协议相关的字段； 第二扩展模块， 用于在所述 IKEv2 中增加用于路由协议的 SA载荷， 其中， 所述用于路由协议的 SA载 荷中携带与路由协议相关的字段。通过本优选实施例中提到的两个扩展模块， 可以灵活地对 IKEv2进行扩展， 以便可以实现用于路由协议的 SA的协商。 优选的， 所述第一扩展模块包括： 第一处理子模块， 用于在所述原有 SA 载荷中的提议子结构 Proposal Substructure 中增加用于路由协议的协议标识 符字段和密钥标识符字段； 第二处理子模块， 用于在所述原有 S A载荷中的 变换子结构 Transform Substructure中增加用于路由协议的变换类型字段、 变 换标识符字段； 第三处理子模块， 用于在所述变换子结构 Transform Substructure中属性类型中增加用于路由协议的密钥长度字段和 SA的生存时 间字段。 通过本优选实施例中提到的各个子模块， 实现了在原有 SA载荷的 基础上进行扩展， 从而可以降低扩展所对应的复杂度， 便于实现本发明实施 例。 优选的， 所述第二扩展模块包括： 构建子模块， 用于构建与所述原有 SA 载荷的结构相同的 SA载荷； 第三处理子模块， 用于在所述构建的 SA载荷 中的提议子结构 Proposal Substructure中增加用于路由协议的 SA的生存时间 字段以及所述生存时间长度字段； 第四处理子模块， 用于在所述构建的 SA 载荷中的提议子结构 Proposal Substructure中将 SPI大小字段替换成用于路由 协议的密钥标识符字段， 并将 SPI字段替换成用于路由协议的密钥标识符字 段。 通过本优选实施例中提到的新增 SA 的扩展方式， 可以更好的便于 SA 协商的双方进行识别， 提高了协商的效率。 优选的， 所述扩展单元 1002 包括： 第三扩展模块， 用于在所述 IKEv2 中增加用于路由协议的交换类型， 其中， 所述交换类型用于指示在所述交换 类型对应的交换中使用所述增加了与路由协议相关的字段的原 IKEv2的 SA 载荷， 或者， 使用所述增加的用于路由协议的 SA载荷。 通过本优选实施例 中特定为用于路由协议的 SA增加的交换类型， 使得 SA协商的双方可以更 容易进行 SA的协商， 提高了协商的效率。 优选的， 所述协商单元 1004包括： 第一协商模块， 用于使用上述 IKEv2 协商生成用于建立安全通道的 SA; 建立模块， 用于使用生成的 SA建立安全 通道； 第二协商模块， 用于在所述安全通道上使用扩展后的 IKEv2协商生成 用于路由协议的安全联盟 SA。 通过本优选实施例中提到的各个模块， 可以 进一步保证协商用于路由协议的 SA时的安全性。 优选的， 所述协商单元 1004 包括： 位于第一路由器上的第三协商模块 以及位于与所述第一路由器对等的第二路由器上的第四协商模块， 其中， 所 述第三协商模块， 用于将所述第一路由器支持的一组或多组所述与路由协议 相关的字段中的每一组填入到所述扩展后的 IKEv2中对应的字段中， 通过所 述扩展后的 IKEv2将所述一组或多组所述与路由协议相关的字段发送给与所 述第四协商模块， 并将由所述第四协商模块选择的一组与路由协议相关的字 段构建成用于所述第一路由器与所述第二路由器之间通信使用的路由协议的
SA; 所述第四协商模块， 用于从所述一组或多组与路由协议相关的字段中选 择一组与路由协议相关的字段， 通过所述扩展后的 IKEv2发送给所述第三协 商模块， 并将所述选择的一组与路由协议相关的字段构建成用于所述第一路 由器与所述第二路由器之间通信使用的路由协议的 SA。 通过本优选实施例 中提到的协商单元， 可以有效的完成用于路由协议的 SA的协商。 优选的， 在上述各个优选实施例的基础上， 处理单元 1006 使用生成的 SA对所述路由协议进行密钥管理并对路由消息的传输实施保护的步骤包括： 作为发送方的路由器使用生成的 SA更新路由协议的密钥材料， 对要发送的 路由消息进行认证码计算与填充； 作为接收方的路由协议使用生成的 SA更 新路由协议的密钥材料， 对收到的路由消息进行完整性认证。 综上所述， 本发明实施例可以解决现有技术存在的问题， 使得路由协议 可以借助带外 KMP 基于 IKEv2 的多种扩展方式协商生成并管理所需要的 SA, 满足路由安全自动密钥管理和更新的需要， 从而满足路由消息安全传输 的需要。 需要说明的是， 在附图的流程图示出的步骤可以在诸如一组计算机可执 行指令的计算机系统中执行， 并且， 虽然在流程图中示出了逻辑顺序， 但是 在某些情况下， 可以以不同于此处的顺序执行所示出或描述的步骤。 显然， 本领域的技术人员应该明白， 上述的本发明的各模块或各步骤可 以用通用的计算装置来实现， 它们可以集中在单个的计算装置上， 或者分布 在多个计算装置所组成的网络上， 可选地， 它们可以用计算装置可执行的程 序代码来实现， 从而， 可以将它们存储在存储装置中由计算装置来执行， 或 者将它们分别制作成各个集成电路模块， 或者将它们中的多个模块或步骤制 作成单个集成电路模块来实现。 这样， 本发明不限制于任何特定的硬件和软 件结合。 以上所述仅为本发明的优选实施例而已， 并不用于限制本发明， 对于本 领域的技术人员来说， 本发明可以有各种更改和变化。 凡在本发明的 ^"神和 原则之内， 所作的任何修改、 等同替换、 改进等， 均应包含在本发明的保护 范围之内。

Claims

权 利 要 求 书 一种用于路由协议的密钥管理方法， 其特征在于， 包括：
扩展互联网密钥交换协议第二版 IKEv2;
使用生成的所述 SA对路由协议进行密钥管理， 并对基于所述路由 协议的路由消息的传输实施保护。 根据权利要求 1所述的方法， 其特征在于， 所述扩展互联网密钥交换协 议第二版 IKEv2的步骤包括以下之一：
在所述 IKEv2的原有 SA载荷中增加与路由协议相关的字段； 或者 在所述 IKEv2中增加用于路由协议的 SA载荷， 其中， 所述用于路 由协议的 SA载荷中携带与路由协议相关的字段。 根据权利要求 2所述的方法， 其特征在于， 在所述 IKEv2的原有 SA载 荷中增加与路由协议相关的字段包括：
在所述原有 S A载荷中的提议子结构中增加用于路由协议的协议标 识符字段和密钥标识符字段；
在所述原有 SA载荷中的变换子结构中增加用于路由协议的变换类 型字段、 变换标识符字段；
在所述变换子结构中属性类型中增加用于路由协议的密钥长度字段 和 SA的生存时间字段。 根据权利要求 3所述的方法， 其特征在于， 所述扩展互联网密钥交换协 议第二版 IKEv2的步骤还包括：
在所述 IKEv2中增加用于路由协议的交换类型， 其中， 所述交换类 型用于指示在所述交换类型对应的交换中使用增加了与路由协议相关的 字段的所述原有 SA载荷。 根据权利要求 2所述的方法， 其特征在于， 在所述 IKEv2中增加用于路 由十办议的 SA载荷包括：
构建与所述原有 SA载荷的结构相同的 SA载荷； 在所述构建的 SA载荷中的提议子结构中增加用于路由协议的 SA的 生存时间字段以及所述生存时间长度字段；
在所述构建的 SA载荷中的提议子结构中将 SPI大小字段替换成用 于路由协议的密钥标识符字段， 并将 SPI字段替换成用于路由协议的密 钥标识符字段。
6. 根据权利要求 5所述的方法， 其特征在于， 所述扩展互联网密钥交换协 议第二版 IKEv2的步骤还包括：
在所述 IKEv2中增加用于路由协议的交换类型， 其中， 所述交换类 型用于指示在所述交换类型对应的交换中使用所述增加的用于路由协议 的 SA载荷。
7. 根据权利要求 1至 6中任一项所述的方法， 其特征在于， 使用扩展后的 所述 IKEv2协商生成用于路由协议的安全联盟 SA的步骤包括：
使用所述 IKEv2协商生成用于建立安全通道的 SA;
使用生成的 SA建立安全通道；
在所述安全通道上使用扩展后的 IKEv2协商生成用于路由协议的安 全联盟 SA。
8. 根据权利要求 2至 6中任一项所述的方法， 其特征在于， 使用扩展后的 所述 IKEv2协商生成用于路由协议的安全联盟 SA的步骤包括：
第一路由器将其支持的一组或多组所述与路由协议相关的字段中的 每一组填入到所述扩展后的 IKEv2中对应的字段中；
所述第一路由器通过所述扩展后的 IKEv2将所述一组或多组所述与 路由协议相关的字段发送给与所述第一路由器对等的第二路由器； 所述第二路由器从所述一组或多组与路由协议相关的字段中选择一 组与路由协议相关的字段， 并通过所述扩展后的 IKEv2发送给所述第一 路由器；
所述第一路由器与所述第二路由器将所述选择的一组与路由协议相 关的字段构建成用于所述第一路由器与所述第二路由器之间通信使用的 路由十办议的 SA。
. 一种用于路由协议的密钥管理系统， 其特征在于， 包括： 扩展单元， 用于扩展互联网密钥交换协议第二版 IKEv2; 协商单元， 用于使用扩展后的所述 IKEv2协商生成用于路由协议的 安全联盟 SA;
处理单元， 用于使用生成的所述 SA对路由协议进行密钥管理， 并 对基于所述路由协议的路由消息的传输实施保护。
10. 根据权利要求 9所述的系统， 其特征在于， 所述扩展单元包括：
第一扩展模块， 用于在所述 IKEv2的原有 SA载荷中增加与路由协 议相关的字段；
第二扩展模块，用于在所述 IKEv2中增加用于路由协议的 SA载荷， 其中， 所述用于路由协议的 SA载荷中携带与路由协议相关的字段。
11. 根据权利要求 10所述的系统， 其特征在于， 所述第一扩展模块包括： 第一处理子模块， 用于在所述原有 SA载荷中的提议子结构中增加 用于路由协议的协议标识符字段和密钥标识符字段；
第二处理子模块， 用于在所述原有 SA载荷中的变换子结构中增加 用于路由协议的变换类型字段、 变换标识符字段；
第三处理子模块， 用于在所述变换子结构中属性类型中增加用于路 由协议的密钥长度字段和 S A的生存时间字段。
12. 根据权利要求 10所述的系统， 其特征在于， 所述第二扩展模块包括： 构建子模块， 用于构建与所述原有 SA载荷的结构相同的 SA载荷； 第三处理子模块， 用于在所述构建的 SA载荷中的提议子结构中增 加用于路由协议的 SA的生存时间字段以及所述生存时间长度字段； 第四处理子模块， 用于在所述构建的 SA载荷中的提议子结构中将 SPI 大小字段替换成用于路由协议的密钥标识符字段， 并将 SPI字段替 换成用于路由协议的密钥标识符字段。
13. 根据权利要求 10所述的系统， 其特征在于， 所述扩展单元包括：
第三扩展模块，用于在所述 IKEv2中增加用于路由协议的交换类型， 其中， 所述交换类型用于指示在所述交换类型对应的交换中使用所述增 加了与路由协议相关的字段的 iKEv2的原有 SA载荷， 或者， 使用所述 增加的用于路由协议的 SA载荷。
14. 根据权利要求 9所述的系统， 其特征在于， 所述协商单元包括：
第一协商模块， 用于使用所述 IKEv2协商生成用于建立安全通道的
SA;
建立模块， 用于使用生成的 SA建立安全通道；
第二协商模块， 用于在所述安全通道上使用扩展后的 IKEv2协商生 成用于路由协议的安全联盟 SA。
15. 根据权利要求 9所述的系统， 其特征在于， 所述协商单元包括： 位于第 一路由器上的第三协商模块以及位于与所述第一路由器对等的第二路由 器上的第四协商模块， 其中，
所述第三协商模块， 用于将所述第一路由器支持的一组或多组所述 与路由协议相关的字段中的每一组填入到所述扩展后的 IKEv2中对应的 字段中， 通过所述扩展后的 IKEv2将所述一组或多组所述与路由协议相 关的字段发送给与所述第四协商模块， 并将由所述第四协商模块选择的 一组与路由协议相关的字段构建成用于所述第一路由器与所述第二路由 器之间通信使用的路由协议的 S A;
所述第四协商模块， 用于从所述一组或多组与路由协议相关的字段 中选择一组与路由协议相关的字段， 通过所述扩展后的 IKEv2发送给所 述第三协商模块， 并将所述选择的一组与路由协议相关的字段构建成用 于所述第一路由器与所述第二路由器之间通信使用的路由协议的 SA。
16. —种用于路由协议的密钥管理系统， 其特征在于， 包括： 彼此两两相连 的 KMP单元、 路由协议单元和密钥库单元， 其中，
所述 KMP单元， 用于对互联网密钥交换第二版 IKEv2进行扩展， 并使用扩展后的 IKEv2协商生成用于路由协议的安全联盟 SA;
所述路由协议单元， 用于为运行的路由协议与所述 KMP 单元、 所 述密钥库单元提供交互和接口功能；
所述密钥库单元， 用于存储所述 KMP 单元和所述路由十办议单元使 用的密钥材料。
17. 根据权利要求 16 所述的系统， 其特征在于， 所述 KMP单元包括： SA 生成模块、 S A使用策略模块和 S A库模块， 其中，
所述 SA生成模块，用于根据所述 SA使用策略模块的指令调用所述 扩展后的 IKEv2来协商生成用于路由协议的 SA;
所述 SA库模块， 用于存放并管理由所述 SA生成模块协商生成的
SA;
所述 SA使用策略模块，用于通过指令指导所述 SA生成模块协商生 成 SA, 并通过指令指导所述 SA库模块对 SA的存取。
18. 根据权利要求 17所述的系统， 其特征在于， 所述 SA生成模块包括： 第一扩展子模块， 用于在所述 IKEv2的原有 SA载荷中增加与路由 协议相关的字段；
第二扩展子模块， 用于在所述 IKEv2中增加用于路由协议的 SA载 荷， 其中， 所述用于路由协议的 SA载荷中携带与路由协议相关的字段。
19. 根据权利要求 18所述的系统， 其特征在于， 所述 SA生成模块还包括： 第三扩展模块，用于在所述 IKEv2中增加用于路由协议的交换类型， 其中， 所述交换类型用于指示在所述交换类型对应的交换中使用所述增 加了与路由协议相关的字段的 iKEv2的原有 SA载荷， 或者， 使用所述 增加的用于路由协议的 SA载荷。
PCT/CN2010/079296 2010-09-28 2010-11-30 用于路由协议的密钥管理方法和系统 WO2012040971A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201010501334.9A CN102420740B (zh) 2010-09-28 2010-09-28 用于路由协议的密钥管理方法和系统
CN201010501334.9 2010-09-28

Publications (1)

Publication Number Publication Date
WO2012040971A1 true WO2012040971A1 (zh) 2012-04-05

Family

ID=45891841

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2010/079296 WO2012040971A1 (zh) 2010-09-28 2010-11-30 用于路由协议的密钥管理方法和系统

Country Status (2)

Country Link
CN (1) CN102420740B (zh)
WO (1) WO2012040971A1 (zh)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106161224B (zh) 2015-04-02 2019-09-17 阿里巴巴集团控股有限公司 数据交换方法、装置及设备
EP3565195A1 (en) * 2018-04-30 2019-11-06 Hewlett-Packard Enterprise Development LP Internet protocol security messages for subnetworks
JP7188855B2 (ja) * 2018-11-15 2022-12-13 ホアウェイ・テクノロジーズ・カンパニー・リミテッド セキュリティアソシエーションｓａのキー変更の方法、ネットワークデバイス、および、ネットワークシステム
CN117528502B (zh) * 2024-01-08 2024-03-29 易联科技(深圳)有限公司 一种无线路由器间加密通讯方法及系统

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1722689A (zh) * 2005-06-21 2006-01-18 中兴通讯股份有限公司 一种ip多媒体子系统接入安全的保护方法
CN1949705A (zh) * 2005-10-14 2007-04-18 上海贝尔阿尔卡特股份有限公司 一种用于安全访问专用局域网的动态隧道构建方法及用于该方法的装置
CN101510889A (zh) * 2009-04-03 2009-08-19 杭州华三通信技术有限公司 一种获取动态路由的方法和设备

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1722689A (zh) * 2005-06-21 2006-01-18 中兴通讯股份有限公司 一种ip多媒体子系统接入安全的保护方法
CN1949705A (zh) * 2005-10-14 2007-04-18 上海贝尔阿尔卡特股份有限公司 一种用于安全访问专用局域网的动态隧道构建方法及用于该方法的装置
CN101510889A (zh) * 2009-04-03 2009-08-19 杭州华三通信技术有限公司 一种获取动态路由的方法和设备

Also Published As

Publication number Publication date
CN102420740B (zh) 2015-06-10
CN102420740A (zh) 2012-04-18

Similar Documents

Publication Publication Date Title
ES2746044T3 (es) Protocolo de optimización de estratos cruzados
US7620041B2 (en) Authentication mechanisms for call control message integrity and origin verification
CN101379801B (zh) 用于eap扩展（eap-ext）的eap方法
US8606961B2 (en) Method and apparatus for link-state handshake for loop prevention
US20100138649A1 (en) Transmission of packet data over a network with security protocol
KR20120047911A (ko) 센서 네트워크에서 인증 및 비밀 키 관리 메커니즘을 결합하는 방법
US8069235B2 (en) Method and device for managing a peer relationship in a data communication network
WO2016096005A1 (en) Trusted routing between communication network systems
WO2009012670A1 (fr) Procédé, dispositif et système permettant d'enregistrer un nouveau membre de groupe lors d'une gestion de clé multidiffusion
KR20080075008A (ko) 무선 메쉬 네트워크에 이용하는 암호화 키 관리 방법
US8345878B2 (en) Method for distributing cryptographic keys in a communication network
Moreira et al. Security mechanisms to protect IEEE 1588 synchronization: State of the art and trends
Davoli et al. An anonymization protocol for the internet of things
WO2012040971A1 (zh) 用于路由协议的密钥管理方法和系统
CN114095423B (zh) 基于mpls的电力通信骨干网数据安全防护方法及系统
CN102469063B (zh) 路由协议安全联盟管理方法、装置及系统
Wyss et al. Secure and scalable QoS for critical applications
WO2014124561A1 (zh) 实现在wlan中的通信的方法和系统
US20230007710A1 (en) Security mechanism for connection establishment over multi-hop sidelinks
WO2012174901A1 (zh) Rsvp认证方法及装置
CN112235318B (zh) 实现量子安全加密的城域网系统
JP2018174550A (ja) 通信システム
CN110120907B (zh) 一种基于提议组的IPSec VPN隧道的通信方法及装置
CN114614984A (zh) 一种基于国密算法的时间敏感网络安全通信方法
CN102447616B (zh) 一种路由协议组密钥管理方法、系统及设备

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 10857734

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 10857734

Country of ref document: EP

Kind code of ref document: A1