WO2012174901A1 - Procédé et dispositif d'authentification de protocole de réservation de ressources (rsvp) - Google Patents

Procédé et dispositif d'authentification de protocole de réservation de ressources (rsvp) Download PDF

Info

Publication number
WO2012174901A1
WO2012174901A1 PCT/CN2012/072717 CN2012072717W WO2012174901A1 WO 2012174901 A1 WO2012174901 A1 WO 2012174901A1 CN 2012072717 W CN2012072717 W CN 2012072717W WO 2012174901 A1 WO2012174901 A1 WO 2012174901A1
Authority
WO
WIPO (PCT)
Prior art keywords
authentication information
packet
next hop
authentication
address
Prior art date
Application number
PCT/CN2012/072717
Other languages
English (en)
Chinese (zh)
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 WO2012174901A1 publication Critical patent/WO2012174901A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/72—Admission control; Resource allocation using reservation actions during connection setup
    • H04L47/724—Admission control; Resource allocation using reservation actions during connection setup at intermediate nodes, e.g. resource reservation protocol [RSVP]
    • 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/08—Network architectures or network communication protocols for network security for authentication of entities

Definitions

  • the present invention relates to the field of communications, and in particular to a RSVP (Resource Reservation Protocol) authentication method and apparatus.
  • RSVP Resource Reservation Protocol
  • BACKGROUND OF THE INVENTION Traffic engineering authentication technology is a password authentication mechanism for making RSVP messages not maliciously tampering.
  • RSVP Cryptographic Authentication is a password authentication mechanism for making RSVP messages not maliciously tampering.
  • 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.
  • FIG. 1 shows the node protection topology of TE-FRR.
  • 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.
  • 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.
  • 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.
  • 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.
  • the two authentication parties refer to two parties in one hop.
  • 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.
  • the link L23 fails, the TE-FRR switch occurs on the primary tunnel on R2.
  • 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. .
  • the switched RESV message should be fei2/l after R4, R1 and R2. mouth.
  • 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.
  • the packet is discarded.
  • 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.
  • an RSVP authentication method 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.
  • 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.
  • an RS VP authentication apparatus 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.
  • 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.
  • 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 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
  • the RSVP authentication method 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the foregoing authentication information may include: a HASH algorithm, a key, and a challenge negotiation.
  • 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).
  • 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.).
  • next hop 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.
  • the interface fei3/2 of R3 is also AUTH23 based on the fei2/2 configuration authentication information of the next hop R2.
  • Table 1 The authentication relationship between the corresponding interface and the next hop is as shown in Table 1: Table 1
  • 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.
  • 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.
  • 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.
  • 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 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.
  • FIG. 7 is a structural block diagram of an RSVP authentication apparatus according to an embodiment of the present invention.
  • the RSVP authentication apparatus 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.
  • 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.
  • 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 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.
  • 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.
  • the foregoing authentication information may include: a HASH algorithm, a key, and a challenge negotiation.
  • 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.

Abstract

L'invention concerne un procédé et un dispositif d'authentification de protocole de réservation de ressources (RSVP). Le procédé consiste à : en correspondance avec chaque adresse de saut suivant d'une interface de nœud, configurer un ensemble d'informations d'authentification pour l'interface de nœud, les informations d'authentification dans l'ensemble d'informations d'authentification étant en correspondance une à une avec toutes les adresses de saut suivant de l'interface de nœud; durant la transmission d'un message, sélectionner les informations d'authentification correspondant à l'adresse de saut suivant qui sont envoyées par le message à partir de l'ensemble d'informations d'authentification, pour remplir des informations d'authentification de contenu de message du message; et durant la réception du message, sélectionner les informations d'authentification correspondant à une adresse d'envoi du message à partir de l'ensemble d'informations d'authentification, pour authentifier le message. Au moyen des solutions techniques fournies par la présente invention, le problème d'échec de protection provoqué par un échec d'authentification après qu'un FRR est commuté dans l'état antérieur de la technique est résolu, et un effet consistant à empêcher un service de données porté sur un tunnel d'être perdu est en outre obtenu.
PCT/CN2012/072717 2011-06-21 2012-03-21 Procédé et dispositif d'authentification de protocole de réservation de ressources (rsvp) WO2012174901A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201110167285.4 2011-06-21
CN2011101672854A CN102223372A (zh) 2011-06-21 2011-06-21 Rsvp认证方法及装置

Publications (1)

Publication Number Publication Date
WO2012174901A1 true WO2012174901A1 (fr) 2012-12-27

Family

ID=44779801

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2012/072717 WO2012174901A1 (fr) 2011-06-21 2012-03-21 Procédé et dispositif d'authentification de protocole de réservation de ressources (rsvp)

Country Status (2)

Country Link
CN (1) CN102223372A (fr)
WO (1) WO2012174901A1 (fr)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102223372A (zh) * 2011-06-21 2011-10-19 中兴通讯股份有限公司 Rsvp认证方法及装置
CN103023821B (zh) * 2012-12-04 2016-06-08 杭州华三通信技术有限公司 一种rsvp中认证关系的维护方法和设备
CN109257110A (zh) * 2018-08-27 2019-01-22 国网山西省电力公司阳泉供电公司 面向广域能源互联网的光网络轻量级安全信令交互方法

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1841999A (zh) * 2005-03-30 2006-10-04 华为技术有限公司 独立承载控制层网络中实体间信息交互的实现方法
CN101635648A (zh) * 2009-08-05 2010-01-27 中兴通讯股份有限公司 一种对虚拟冗余路由协议组进行管理及快速切换的方法
CN101640888A (zh) * 2009-09-07 2010-02-03 华为技术有限公司 快速重路由资源预留认证方法、装置及系统
CN101820425A (zh) * 2010-04-16 2010-09-01 杭州华三通信技术有限公司 Rsvp认证的方法和系统
CN102223372A (zh) * 2011-06-21 2011-10-19 中兴通讯股份有限公司 Rsvp认证方法及装置

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101369958A (zh) * 2007-08-15 2009-02-18 华为技术有限公司 一种快速重路由方法及标签交换路由器

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1841999A (zh) * 2005-03-30 2006-10-04 华为技术有限公司 独立承载控制层网络中实体间信息交互的实现方法
CN101635648A (zh) * 2009-08-05 2010-01-27 中兴通讯股份有限公司 一种对虚拟冗余路由协议组进行管理及快速切换的方法
CN101640888A (zh) * 2009-09-07 2010-02-03 华为技术有限公司 快速重路由资源预留认证方法、装置及系统
CN101820425A (zh) * 2010-04-16 2010-09-01 杭州华三通信技术有限公司 Rsvp认证的方法和系统
CN102223372A (zh) * 2011-06-21 2011-10-19 中兴通讯股份有限公司 Rsvp认证方法及装置

Also Published As

Publication number Publication date
CN102223372A (zh) 2011-10-19

Similar Documents

Publication Publication Date Title
US10616379B2 (en) Seamless mobility and session continuity with TCP mobility option
US8281383B2 (en) Secured IPv6 traffic preemption
ES2746044T3 (es) Protocolo de optimización de estratos cruzados
CN106209897B (zh) 一种基于代理的软件定义网络分布式多粒度控制器安全通信方法
EP2329621B1 (fr) Distribution de clé à un ensemble de routeurs
US20050021946A1 (en) System and method for nodes communicating in a shared network segment
US20130205025A1 (en) Optimized Virtual Private Network Routing Through Multiple Gateways
EP1133132A1 (fr) Procédé pour effectuer authentification de bout en bout, équipement local d'abonné termination de réseau, et serveur d'accès au réseau
WO2013182059A1 (fr) Procédé et dispositif pour établir un tunnel d'ingénierie de trafic de commutation multiprotocole par étiquette
TW201134151A (en) RSVP-TE graceful restart under fast re-route conditions
US9288686B2 (en) Topology discovery based on SCTP/X2 snooping
CN101515859B (zh) 一种因特网协议安全隧道传输组播的方法及设备
CN101572644B (zh) 一种数据封装方法和设备
US20210288803A1 (en) Secured protection of advertisement parameters in a zero trust low power and lossy network
Pana et al. A Survey on the Evolution of RSVP
WO2010054542A1 (fr) Procédé, système et dispositif d'identification de clé publique cga et de détermination de clé publique cga
CN114095423B (zh) 基于mpls的电力通信骨干网数据安全防护方法及系统
WO2012174901A1 (fr) Procédé et dispositif d'authentification de protocole de réservation de ressources (rsvp)
Liyanage et al. Secure hierarchical virtual private LAN services for provider provisioned networks
Wyss et al. Secure and scalable QoS for critical applications
WO2012040971A1 (fr) Procédé de gestion de clé et système de routage de protocole
EP3713185B1 (fr) Procédé, dispositif et système d'authentification
Goodrich Efficient and secure network routing algorithms
CN111866865B (zh) 一种数据传输方法、5g专网建立方法及系统
Hohendorf et al. Secure End-to-End Transport Over SCTP.

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: 12802068

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: 12802068

Country of ref document: EP

Kind code of ref document: A1