WO2012174901A1

WO2012174901A1 - Rsvp authentication method and device

Info

Publication number: WO2012174901A1
Application number: PCT/CN2012/072717
Authority: WO
Inventors: 付志涛; 许浩
Original assignee: 中兴通讯股份有限公司
Priority date: 2011-06-21
Filing date: 2012-03-21
Publication date: 2012-12-27
Also published as: CN102223372A

Abstract

Disclosed are an RSVP authentication method and device. The method comprises: in correspondence with each next-hop address of a node interface, setting a set of authentication information for the node interface, the authentication information in the set of authentication information being in one-to-one correspondence with all next-hop addresses of the node interface; during transmission of a message, selecting the authentication information corresponding to the next-hop address which is sent by the message from the set of authentication information, to fill message content authentication information of the message; and during reception of the message, selecting the authentication information corresponding to a sending address of the message from the set of authentication information, to authenticate the message. By means of the technical solutions provided by the present invention, the problem of protection failure caused by authentication failure after FRR is switched in the prior art is solved, and an effect of preventing a data service borne on a tunnel from being lost is further achieved.

Description

TECHNICAL FIELD The present invention relates to the field of communications, and in particular to a RSVP (Resource Reservation Protocol) authentication method and apparatus. BACKGROUND OF THE INVENTION Traffic engineering authentication technology (RSVP Cryptographic Authentication) is a password authentication mechanism for making RSVP messages not maliciously tampering. In RFC2747 (the end-to-end authentication protocol standard), a hop-by-hop mechanism for protecting RSVP message integrity is defined. The sender and receiver of the message need to configure an identical key and the same HASH algorithm to generate For the same summary information, the sender of the message needs to carry the summary information as an object (INTEGRITY) in the message, and the receiver receives the message and authenticates the message integrity by carrying the summary information. The RSVP authentication interface is called the RSVP authentication interface. The RSVP authentication interface needs to encapsulate the authentication object (INTEGRITY) when sending packets. The packets that do not contain the authentication object must be discarded. The interface that does not enable RSVP authentication is called. Non-RSVP authentication interface. When a non-RSVP authentication interface sends a packet, it does not need to encapsulate the authentication object. Packets that contain the authentication object must be discarded. Traffic Engineering-Fast Re-Route (TE-FRR) technology is a local protection technology that performs local repair when local links or nodes fail. In RFC4090 (the end-to-end authentication protocol standard), two types of local protection, link protection and node protection, are defined. Two special node types in the protection process are also defined: Local Repair Point (Point Local) Repair, referred to as PLR) node and Merge Point (MP) node. Figure 1 shows the node protection topology of TE-FRR. As shown in FIG. 1, the topology diagram includes: nodes R1, R2, and R3 (R1 as a PLR node and R3 as an MP node), links L12, L23, and L13, wherein when the link L12 fails, the path is switched to L13, forming node protection. Figure 2 shows the link protection topology of TE-FRR. As shown in FIG. 2, the topology diagram includes: nodes R1, R2, and R3 (R2 as a PLR node and R3 as an MP node), links L12, L23, and L32, where when the link L23 fails, the path is switched to L32, forming link protection. After the switchover, the MP node processes the PATH (path packet) and PATH-TEAR (a type of teardown packet in the RSVP-TE protocol) sent from the backup tunnel inbound interface (that is, the start entry of the backup tunnel). The protocol packet does not process the protocol packets of the original tunnel. In the actual project deployment, as shown in Figure 3, the primary tunnel passes R1, R2, and R3, and the same RSVP authentication information is configured on the fei2/l of R1 and fei2/l of R2. The backup tunnel passes through R2 and R1. R4 and R3 perform link protection on the link L23 between R2 and R3 in the primary tunnel. According to the definition in RFC2747 (End-to-End Authentication Protocol Standard), the two authentication parties refer to two parties in one hop. After FRR switching, fei2/l on R2 and fei3/3 on R3 in the primary tunnel are also in one hop. Both sides of the certification. After the link L23 fails, the TE-FRR switch occurs on the primary tunnel on R2. After the switchover, the RESV message sent by the primary tunnel on R3 is sent through the fei3/3 port, and the destination is the fei2/l port of R2. . Since the RESV message does not carry the alarm option, the message will not be sent to the protocol for processing along the way, and the route will be forwarded directly. According to the above topology, the switched RESV message should be fei2/l after R4, R1 and R2. mouth. After the switchover, the RESV packet received by R2 from the fei2/l port is constructed on R3. The authentication information is not configured on the outgoing interface fei3/3 of R3. Therefore, there is no need for fei2/l on R2 in the packet. After the authentication summary information is discarded, the packet is discarded. After several cycles, the tunnel is removed due to aging, which causes the protection to fail. In response to the above problems, no effective solution has been proposed yet. SUMMARY OF THE INVENTION The present invention provides an RSVP authentication method and apparatus to solve the above problems. According to an aspect of the present invention, an RSVP authentication method is provided, including: setting a group of authentication information for a node interface corresponding to each next hop address of a node interface, where the authentication information in the group of authentication information is All the next hop addresses of the node interface are one-to-one correspondence. When the packet is sent, the authentication information corresponding to the next hop address sent by the packet is selected in the group of authentication information to fill the packet content of the packet. Authentication information: When receiving a message, the authentication information corresponding to the sending address of the packet is selected from the group of authentication information to perform packet authentication on the packet. Each of the next hop addresses of the node interface includes: an address of a next hop directly connected to the node interface, and an address of a next hop that is not directly connected to the node interface. The authentication information set for the peer is the same for the two node ports of the directly connected next hop or the indirectly connected next hop. The receiving interface address of the packet is obtained through the RSVP_HOP (ie, the next address) object when receiving the packet. The above authentication information includes: HASH (hash, also transliterated as hash) algorithm, key, challenge (challenge) negotiation. According to another aspect of the present invention, an RS VP authentication apparatus is provided, including: an authentication setting module, configured to correspond to each next hop address of a node interface, and set a set of authentication information for the node interface, where the foregoing one The authentication information in the group authentication information is in one-to-one correspondence with all the next hop addresses of the node interface. The message sending module is configured to select and send the message in the group of authentication information when the message is sent. The authentication information corresponding to the one-hop address is filled with the packet content authentication information of the packet. The packet receiving module is configured to: when receiving the packet, select the authentication information corresponding to the sending address of the packet in the group of authentication information. Perform packet authentication on the packet. Each of the next hop addresses of the node interface includes: an address of a next hop directly connected to the node interface, and an address of a next hop that is not directly connected to the node interface. The authentication setting module corresponding to the two node ports of the directly connected next hop or the indirectly connected next hop is the same for the authentication information set by the peer. The packet receiving module is configured to obtain the sending interface address of the packet through the RSVP_H0P object when receiving the packet. The above authentication information includes: a hash HASH algorithm, a key, and a challenge negotiation. According to the present invention, a group of authentication messages are set for the node port, and when the packet is sent to a different next hop address, the authentication information of the authentication message corresponding to the address is selected, and when the message is received, the message is selected. A scheme for authenticating the packet by the authentication information corresponding to the address of the packet, which solves the problem that the protection fails due to the authentication failure after the FRR switch in the prior art, thereby preventing the loss of the data service carried on the tunnel. effect. BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings, which are set to illustrate,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, In the drawings: FIG. 1 is a schematic diagram of a topology of a TE-FRR node protection; FIG. 2 is a topology diagram of a TE-FRR link protection; FIG. 3 is a topology diagram of TE-FRR link protection and RSVP authentication; A flowchart of an RSVP authentication method according to an embodiment of the present invention; 5 is a flowchart of a sender constructing an RSVP message according to an example of the present invention; FIG. 6 is a flowchart of a receiver processing an RSVP message according to an example of the present invention; FIG. 7 is a structure of an RSVP authentication apparatus according to an embodiment of the present invention; block diagram. BEST MODE FOR CARRYING OUT THE INVENTION Hereinafter, the present invention will be described in detail with reference to the accompanying drawings. It should be noted that the embodiments in the present application and the features in the embodiments may be combined with each other without conflict. 4 is a flow chart of an RSVP authentication method according to an embodiment of the present invention. As shown in FIG. 4, the RSVP authentication method according to the embodiment of the present invention includes: Step S402: Set a group of authentication information for a node interface corresponding to each next hop address of the node interface, where The authentication information is in one-to-one correspondence with all the next hop addresses of the node interface. In step S404, when the packet is sent, the authentication information corresponding to the next hop address sent by the packet is selected in the set of authentication information. The packet content authentication information of the packet is sent. In step S406, when the packet is received, the authentication information corresponding to the sending address of the packet is selected in the group of authentication information to perform packet authentication on the packet. Through the above method, a set of authentication messages corresponding to all the next hop addresses of the node port are set for the node port, and the authentication information corresponding to the address is selected according to the corresponding address when sending and receiving the message. Subsequent processing. In this way, even if the protection switchover occurs, the next hop address is changed, and the authentication fails. This prevents the TE-FRR switch from being invalidated due to the authentication failure in the network, and the data service carried on the tunnel is lost. The problem arises. Preferably, each next hop address of the node interface may include: an address of a next hop directly connected to the node interface, and an address of a next hop not directly connected to the node interface. Each next hop address of the node interface shall include all possible next hop addresses, including the address of the next hop directly connected to the node interface and the address of the next hop that is not directly connected to the node interface. Preferably, the two node ports of the directly connected next hop or the indirectly connected next hop are the same for the authentication information set by the opposite end. Currently, the entire authentication process can be successfully completed only when both parties (sending interface and receiving interface) in the first hop use the same authentication information. Therefore, when setting the authentication information of the interface, the authentication information set for each other must be the same whether it is both the directly connected next hop or the indirectly connected next hop. Preferably, the sending interface address of the packet can be obtained through the RSVP_HOP object when receiving the packet. The RSVP_HOP object contains the IP address of the previous node. Therefore, the address of the sending interface of the received packet can be obtained through the RSVP_HOP object, which is convenient to implement. Preferably, the foregoing authentication information may include: a HASH algorithm, a key, and a challenge negotiation. In the specific implementation process, the authentication information may be extended according to specific conditions, including but not limited to the above three items. The above preferred embodiments will be described in detail below with reference to examples. Take the topology shown in Figure 3 as an example. As shown in Figure 3, the direct hop of the interface feil/1 on the primary tunnel path R1 is (fei2/l of R2), and the authentication information based on this next hop is AUTH21 (including HASH algorithm, key, challenge). Negotiation, etc.). The interface fei2/l of the primary tunnel path R2 has a direct next hop (feil/1 of R1) and a potential indirect next hop (fei3/3 of R3). The corresponding interface authentication information is based on the configuration of the next hop. Therefore, two sets of authentication information are configured, one group is based on the related authentication information AUTH21 of the feil/1 with the next hop R1 (including the HASH algorithm, the key, the challenge negotiation, etc.), and the other group is based on the next hop R3. Related authentication information AUTH243 of fei3/3 (including HASH algorithm, key, challenge negotiation, etc.). For the interface fei3/3 of R3, there is a direct next hop (fei4/3 of R4) and a non-direct next hop (fei2/l of R2). Similarly, two groups are configured according to two different next hops. Authentication information, based on the authentication information AUTH43 of the next hop R4fei4/3 (including HASH algorithm, key, challenge negotiation, etc.), based on the authentication information AUTH243 of the non-direct next hop R2fei2/1 (including the HASH algorithm, the key, Challenge negotiation, etc.). The two sides of the next-hop or non-directly connected next-hop mutual configuration authentication information must be the same. In this example, "AUTH21", "AUTH43", "AUTH243", etc. are used to identify the authentication information, for example, the interface of R2. Fei2/2 Based on the next hop R3 fei3/2 configuration authentication information AUTH23, the interface fei3/2 of R3 is also AUTH23 based on the fei2/2 configuration authentication information of the next hop R2. The authentication relationship between the corresponding interface and the next hop is as shown in Table 1: Table 1

When there is no FRR switchover, the outbound interface of the PATH packet sent by the primary tunnel on R2 is fei2/2, and the corresponding next hop information is fei3/2 of R3. Therefore, the AUTH23 in the R2fei2/2 interface is used to generate the PATH packet. The summary information, the fei3/2 of the peer R3 receives the PATH packet, and the corresponding next hop authentication information in the fei3/2 interface of the interface is matched by the RSVP_HOP object (the interface address carrying the fei2/2). Certification, certification passed.

After the FRR switchover, the PATH packet sent by the primary tunnel R2, the outgoing interface is fei2/l, and the corresponding next hop information is fei3/3 of R3. Therefore, AUTH243 is used to generate the summary information of the PATH packet, and the fei3/ of the opposite end R3/ After receiving the PATH packet, the RSVP_HOP object (the address of the fei2/l interface) matches the next hop authentication information in the fei3/3 interface, and the AUTH 243 authenticates the authentication.

After the FRR switchover, the RESV packet sent by the primary tunnel on R3, the outgoing interface is fei3/3, and the fei2/l interface of the next hop information R2 that needs to be sent to the packet is sent, so the RESV packet uses AUTH243 to generate RESV. Summary information of the packet. When the packet is received from the fei2/l interface, the RSVP_HOP object (the address of the interface carrying fei3/3) matches the next hop authentication information in the fei2/l interface, and is authenticated by AUTH243. , the certification passed. As shown in FIG. 5, the process of constructing an RSVP packet is as follows: Step S502: Configure next hop authentication information; Step S504, construct a sending packet; Step S506, determine whether it is necessary to generate packet digest information, if necessary, Go to step S508, if not, end; step S508, generate summary information according to the authentication information of the next hop of the interface, and end. The process of processing the received RSVP packet, as shown in Figure 6, includes: Step S602, receiving an RSVP message; Step S604, storing an address in the RSVP_HOP object in the message; Step S606, determining whether there is an INTEGRITY object in the message, if yes, proceeding to step S608, if not, then transferring Step S612; Step S608, authenticating the message according to the authentication information of the next hop of the interface; Step S610, determining whether the authentication is passed, if yes, proceeding to step S614, if not, proceeding to step S616; Step S612 Check whether the corresponding RSVP_HOP address in the inbound interface of the packet (that is, the interface that receives the packet) has an authentication configuration. If yes, go to step S616. If not, go to step S614. Step S614, continue processing the packet, and end. Step S616, discarding the message, and ending. FIG. 7 is a structural block diagram of an RSVP authentication apparatus according to an embodiment of the present invention. As shown in FIG. 7, the RSVP authentication apparatus according to the embodiment of the present invention includes: an authentication setting module 702, configured to correspond to each next hop address of the node interface, and set a group of authentication information for the node interface, where the foregoing group The authentication information in the authentication information is in one-to-one correspondence with all the next hop addresses of the node interface. The message sending module 704 is connected to the authentication setting module 702, and is configured to select one of the foregoing group of authentication information when sending the message. The authentication information corresponding to the next hop address sent by the packet is filled with the packet content authentication information of the packet. The packet receiving module 706 is connected to the authentication setting module 702, and is configured to receive the packet when the packet is received. The authentication information corresponding to the sending address of the packet is selected in the authentication information to perform packet authentication on the packet. The device sets a set of authentication messages corresponding to all the next hop addresses of the node port for the node port, and selects the authentication information corresponding to the address according to the corresponding address to send and receive the message. Processing. In this way, even if the protection switchover occurs, the next hop address is changed, and the authentication fails. This prevents the TE-FRR switch from being invalidated due to the authentication failure in the network, and the data service carried on the tunnel is lost. The problem arises. Preferably, each next hop address of the node interface may include: an address of a next hop directly connected to the node interface, and an address of a next hop not directly connected to the node interface. Each next hop address of the node interface shall include all possible next hop addresses, including the address of the next hop directly connected to the node interface and the address of the next hop that is not directly connected to the node interface. Preferably, the authentication setting module corresponding to the two node ports of the directly connected next hop or the indirectly connected next hop is the same for the authentication information set by the peer. In order to complete the authentication process successfully, when setting the authentication information of the interface, the authentication information set for each other must be the same whether it is the two sides of the directly connected next hop or the non-directly connected next hop. . Preferably, the message receiving module 706 is configured to obtain the sending interface address of the message through the RSVP_H0P object when receiving the message.

The RSVP_H0P object includes the IP address of the previous node. Therefore, the packet receiving module 706 can obtain the sending interface address of the received packet through the RSVP_H0P object. Preferably, the foregoing authentication information may include: a HASH algorithm, a key, and a challenge negotiation. In the specific implementation process, the authentication information may be extended according to a specific situation, including but not limited to the above three items. From the above description, it can be seen that the technical solution provided by the present invention can implement an interface management based on a group of next hops. Authentication information, when sending and receiving packets, the packets are authenticated by matching the authentication information of the directly connected or indirectly connected next hops. This solves the authentication problem when the packets are received across nodes and the authentication fails after the FRR switchover. The problem of protection failure caused by the failure of the authentication failure in the network causes the TE-FRR handover to fail, which in turn causes the loss of data services carried on the tunnel. Obviously, those skilled in the art should understand that the above 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 implemented by program code executable by the computing device, such that they may be stored in the storage device by the computing device and, in some cases, may be different from the order herein. The steps shown or described are performed, or they are separately fabricated into individual integrated circuit modules, or a plurality of modules or steps are fabricated as a single integrated circuit module. Thus, 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 spirit and scope of the present invention are intended to be included within the scope of the present invention.

Claims

1. A resource reservation protocol RSVP authentication method, including:

Corresponding to each next hop address of the node interface, a set of authentication information is set for the node interface, where the authentication information in the set of authentication information is in one-to-one correspondence with all next hop addresses of the node interface. of;

When the packet is sent, the authentication information corresponding to the next hop address sent by the packet is selected in the set of authentication information to fill the packet content authentication information of the packet.

When the packet is received, the authentication information corresponding to the sending address of the packet is selected from the set of authentication information to perform packet authentication on the packet.

2. The method according to claim 1, wherein each next hop address of the node interface comprises: an address of a next hop directly connected to the node interface, and a non-direct connection with the node interface One hop address.

The method according to claim 2, wherein the two node ports of the directly connected next hop or the indirectly connected next hop are the same for the authentication information set by the peer end.

The method according to any one of claims 1 to 3, wherein the sending interface address of the message is obtained by the next hop address RSVP_H0P object when receiving the message.

The method according to any one of claims 1 to 3, wherein the authentication information comprises: a hash HASH algorithm, a key, and a challenge challenge negotiation.

6. A resource reservation protocol RSVP authentication device, including:

An authentication setting module, configured to correspond to each next hop address of the node interface, and set a set of authentication information for the node interface, where the authentication information in the set of authentication information and all the next interfaces of the node interface The hop addresses are one-to-one correspondence;

a packet sending module, configured to: when the packet is sent, select, in the set of authentication information, the authentication information corresponding to the next hop address sent by the packet to fill the packet content authentication information of the packet;

The message receiving module is configured to: when receiving the message, select the authentication information corresponding to the sending address of the message in the set of authentication information to perform packet authentication on the packet.

The device according to claim 6, wherein each next hop address of the node interface comprises: an address of a next hop directly connected to the node interface, and an interface directly connected to the node interface One hop address. The device according to claim 7, wherein the authentication setting module corresponding to the two node ports of the directly connected next hop or the indirectly connected next hop is the same for the authentication information set by the peer. The device according to any one of claims 6 to 8, wherein the message receiving module is configured to obtain a sending interface address of the message by using a next hop address RSVP_HOP object when receiving the message. The apparatus according to any one of claims 6 to 8, wherein the authentication information comprises: a hash HASH algorithm, a key, a challenge challenge negotiation.