CN119603000B

CN119603000B - Communication methods and devices

Info

Publication number: CN119603000B
Application number: CN202411593692.5A
Authority: CN
Inventors: 洪涛; 苏平
Original assignee: New H3C Technologies Co Ltd
Current assignee: New H3C Technologies Co Ltd
Priority date: 2024-11-08
Filing date: 2024-11-08
Publication date: 2025-11-04
Anticipated expiration: 2044-11-08
Also published as: CN119603000A

Abstract

This application provides a communication method and apparatus. The method is applied to a first node and includes: receiving a first SRv6 message; if the first SRv6 message includes a first signature, then decrypting the first signature according to a stored public key to obtain a first controller identifier; if the first controller identifier is the same as a stored second controller identifier, then forwarding the first SRv6 message; if the first controller identifier is different from the second controller identifier, then discarding the first SRv6 message.

Description

Communication method and device

Technical Field

The present application relates to the field of communications technologies, and in particular, to a communications method and apparatus.

Background

The segment routing traffic engineering strategy (English: segment Routing IPv: TRAFFIC ENGINEERING Policy, abbreviated: SRv TE Policy) based on the IPv6 forwarding plane provides a flexible forwarding path selection method, and can meet different forwarding demands of users.

When a plurality of forwarding paths exist between a source node and a destination node in the SR network, SRv TE Policy is reasonably utilized to select the forwarding paths, so that management and planning of a network by a manager can be facilitated, and forwarding pressure of network equipment can be effectively reduced.

In actual networking, the controller collects network topology and segment identification (English: SEGMENT IDENTIFIER, SID) of each network device in the networking through border gateway protocol (English: border Gateway Protocol, BGP, for short) and link state (English: LINK STATE, LS, for short) messages. The network topology information comprises link overhead, time delay, packet loss rate and the like. And establishing BGP neighbors of a BGP IPv6SR-Policy address family between the controller and the head node. Meanwhile, according to the network topology, the controller calculates SRv TE Policy based on the dimensions of link overhead, time delay, packet loss rate and the like. The controller issues SRv TE Policy to the head node via BGP protocol. The head node configures SRv TE Policy locally and generates SRv TE Policy related entries. Subsequently, the head node may forward the corresponding service message through SRv TE Policy.

However, when forwarding the service message, each node on the forwarding path indicated by SRv TE Policy cannot perform security authentication on the service message, so that potential safety hazards such as traffic hijacking are likely to occur, and service transmission cannot be guaranteed.

Disclosure of Invention

In view of this, the application provides a communication method and device, which are used for solving the problems that all nodes on the forwarding path indicated by the existing SRv TE Policy cannot perform security authentication on service messages, potential safety hazards such as traffic hijacking are likely to occur, and service transmission cannot be guaranteed.

In a first aspect, the present application provides a communication method, the method being applied to a first node, the method comprising:

receiving a first SRv message;

If the first SRv message includes a first signature, decrypting the first signature according to the stored public key to obtain a first controller identifier;

if the first controller identifier is the same as the stored second controller identifier, forwarding the first SRv message;

and if the first controller identifier is different from the second controller identifier, discarding the first SRv message.

In a second aspect, the present application provides a communication method, the method being applied to a controller, the method comprising:

Acquiring a stored public key;

And sending a first BGP message to each node in the network, wherein the first BGP message comprises the public key and the identifier of the controller, so that each node performs security authentication on the message by using the public key and the identifier of the controller after receiving the message, and forwards or discards the message according to the security authentication result.

In a third aspect, the present application provides a communications apparatus for use with a first node, the apparatus comprising:

the receiving unit is used for receiving the first SRv message;

A decryption unit, configured to decrypt, if the first SRv packet includes a first signature, the first signature according to the stored public key, to obtain a first controller identifier;

A sending unit, configured to forward the first SRv message if the first controller identifier is the same as the stored second controller identifier;

And the discarding unit is used for discarding the first SRv message if the first controller identifier is different from the second controller identifier.

In a fourth aspect, the present application provides a communication apparatus for use in a controller, the apparatus comprising:

An acquisition unit configured to acquire a stored public key;

And the sending unit is used for sending a first BGP message to each node in the networking, wherein the first BGP message comprises the public key and the identifier of the controller, so that each node performs security authentication on the message by using the public key and the identifier of the controller after receiving the message, and forwards or discards the message according to the security authentication result.

In a fifth aspect, the application provides a network device comprising a processor and a machine-readable storage medium storing machine-executable instructions executable by the processor to cause the processor to perform the method provided by the first aspect of the application.

In a sixth aspect, the application provides a network device comprising a processor and a machine-readable storage medium storing machine-executable instructions executable by the processor to cause the processor to perform the method provided by the first aspect of the application.

Therefore, by applying the communication method and the communication device provided by the application, the first node receives the first SRv message, if the first SRv message comprises a first signature, the first node decrypts the first signature according to the stored public key to obtain the first controller identifier, if the first controller identifier is the same as the stored second controller identifier, the first node forwards the first SRv6 message, and if the first controller identifier is different from the second controller identifier, the first node discards the first SRv message.

Thus, by carrying the encrypted signature in SRv messages, each node on the forwarding path performs security authentication on SRv messages. And after passing the security authentication, continuing to forward SRv the SRv message, otherwise, discarding the SRv message. The end-to-end safety authentication of each node is realized, and the occurrence of traffic hijacking and other events is prevented. The method solves the problems that each node on the forwarding path indicated by the conventional SRv TE Policy cannot carry out security authentication on the service message, potential safety hazards such as flow hijacking are likely to occur, and service transmission cannot be guaranteed.

Drawings

Fig. 1 is a flowchart of a communication method according to an embodiment of the present application;

fig. 2 is a schematic diagram of an extended TLV structure according to an embodiment of the present application;

fig. 3 is a schematic diagram of another extended TLV structure according to an embodiment of the present application;

Fig. 4 is a schematic diagram of still another extended TLV structure according to an embodiment of the present application;

FIG. 5 is a flow chart of another communication method according to an embodiment of the present application;

Fig. 6 is a SRv networking schematic diagram according to an embodiment of the present application;

fig. 7 is a block diagram of a communication device according to an embodiment of the present application;

Fig. 8 is a block diagram of another communication device according to an embodiment of the present application;

fig. 9 is a hardware structure of a network device according to an embodiment of the present application.

Detailed Description

Reference will now be made in detail to exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, the same numbers in different drawings refer to the same or similar elements, unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with aspects of the application as detailed in the accompanying claims.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. As used in this specification and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that the term "and/or" as used herein refers to and encompasses any or all possible combinations of one or more of the corresponding listed items.

It should be understood that although the terms first, second, third, etc. may be used herein to describe various information, these information should not be limited by these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of the application. The term "if" as used herein may be interpreted as "at..once" or "when..once" or "in response to a determination", depending on the context.

The communication method provided by the embodiment of the application is described in detail below. Referring to fig. 1, fig. 1 is a flowchart of a communication method according to an embodiment of the present application. The method is applied to a first node which is positioned on a forward path of SRv and serves as an intermediate node or a tail node for forwarding SRv messages. The communication method provided by the embodiment of the application can comprise the following steps.

Step 110, receiving a first SRv message;

Specifically, the first node is in SRv to 6 networks, and other nodes, such as a second node, are also included in SRv to 6 networks. The first node and the second node form a forwarding path, and forward the service message (SRv message) on the forwarding path.

In the embodiment of the application, the first node may be a transmission node or a tail node on the forwarding path.

In the forwarding process, the first node receives a first SRv message sent by a previous-hop node, where the previous-hop node may be specifically a head node or another transmission node. Wherein the head node may also be the second node.

After the second node generates the first SRv message, the first SRv message is sent to the first node according to the rules of the existing SRv protocol and forwarding (e.g. searching for a forwarding table), or after any transmitting node receives the first SRv message, the second node continues to send the first SRv message to the first node according to the rules of the existing SRv protocol and forwarding (e.g. searching for a forwarding table).

Step 120, if the first SRv message includes a first signature, decrypting the first signature according to the stored public key to obtain a first controller identifier;

Specifically, according to the description of step 110, after receiving the first SRv message, the first node updates the destination address and the segment surplus (english: SEGMENTS LEFT, abbreviated: SL) of the first SRv message according to the existing SRv protocol rule and forwarding rules (e.g., searching for forwarding tables).

If the first node identifies that the first SRv message includes the first signature, the first node obtains the public key from the local, and decrypts the first signature by using the public key to obtain the first controller identifier.

Optionally, in the embodiment of the present application, before receiving the first SRv message, the first node further receives a second BGP message sent by the controller, where the second BGP message includes the public key and the second control identifier. Wherein the second controller identification is an identification of the controller (e.g., device ID, MAC address, IP address, etc., for uniquely identifying the controller). The second BGP message may be specifically a BGP UPDATE (UPDATE) message.

In the embodiment of the application, a xSEC authentication framework is utilized between the controller and each node to interact with the public key. This public key may also be referred to as xSEC public keys. Further, the public key xSEC may be carried in an extended attribute included in the existing BGP message. Where "x" represents an unknown variable, represents any location (any place), any level (any Layer), any topology (any topology), and "SEC" represents security.

It will be appreciated that the controller transmits the second BGP message described above to each node within the network separately, such that each node stores the public key and the second controller identification locally. The public key and the second controller identifier are used for carrying out security authentication on the received service message by each subsequent node. In the following embodiments, a procedure of performing security authentication on the received service message by each node will be described separately, and will not be described again.

Optionally, the first signature is obtained after the controller encrypts the identifier of the controller by using a private key. The controller carries the first signature in a SRv TE Policy profile and sends it to the second node. After receiving the service message, the second node carries the first signature in a SRv message header (English: segment Routing Header, abbreviated: SRH) header included in the service message after determining that the service message is forwarded through SRv TE Policy and performing security authentication on the service message, and continues to send on a forwarding path. In the following embodiments, the process of issuing SRv TE Policy configuration file by the controller, performing security authentication on the service message by the second node, and carrying the first signature in the SRH header included in the service message will be described separately, and will not be described again here.

130, If the first controller identifier is the same as the stored second controller identifier, forwarding the first SRv message;

Specifically, according to the description of step 120, after the first node obtains the first controller identifier, the second controller identifier is obtained locally. The first node identifies whether the first controller identification is the same as the second controller identification.

If the first controller identifier is the same as the second controller identifier, the first node determines that the first SRv message passes the security authentication. The first node continues forwarding the first SRv message according to the existing SRv protocol specifications and forwarding rules (e.g., lookup of forwarding tables).

For example, when the first node is a transmission node, the first node updates the destination address included in the IPv6 header and the SL included in the SRH header, and then continues forwarding on the forwarding path. At this point, the first signature is still retained within the SRH header.

When the first node is the tail node, the first node can unpack the IPv6 header and the SRH header to obtain the original message. The first node continues forwarding the original message.

Step 140, discarding the first SRv message if the first controller identifier is different from the second controller identifier.

Specifically, according to the description of step 130, if the first controller identifier is different from the second controller identifier, the first node determines that the first SRv message does not pass the security authentication, and at this time, the first SRv message is continuously forwarded, so that a potential safety hazard will occur. The first node discards the first SRv message.

Therefore, by applying the communication method provided by the application, the first node receives the first SRv message, if the first SRv message comprises a first signature, the first node decrypts the first signature according to the stored public key to obtain a first controller identifier, if the first controller identifier is the same as the stored second controller identifier, the first node forwards the first SRv6 message, and if the first controller identifier is different from the second controller identifier, the first node discards the first SRv message.

Optionally, in an embodiment of the present application, the method further includes the following steps:

specifically, when the first node is a head node, a first BGP message sent by the controller is further received, where the first BGP message includes a SRv TE Policy configuration file. Wherein the configuration file includes a first signature. According to the configuration file, the first node configures SRv TE Policy locally and generates an entry corresponding to SRv TE Policy. The first BGP message may be a BGP UPDATE message, and further, specifically, a BGPSRv TE Policy address group message.

The first signature is obtained after the controller encrypts the identifier of the controller by using a private key (also referred to as xSEC private key) corresponding to the public key (the encryption process is the same as that of the conventional xSEC, and is not repeated here), and the first signature is stored in a configuration file middle section list (SEGMENT LIST), and SRv TE Policy locally configured by the first node stores the first signature. The first signature may be embodied in a segment string format.

It is understood that each node within SRv's network reports BGP-LS messages to the controller. The BGP-LS message includes network topology information and the SID of the node. The controller collects the network topology and SIDs of each node in the network by a plurality of BGP-LS messages. The network topology information comprises link overhead, time delay, packet loss rate and the like.

And establishing BGP neighbors of a BGP IPv6 SR-Policy address family between the controller and the head node. Meanwhile, according to the network topology, the controller calculates SRv TE Policy based on the dimensions of link overhead, time delay, packet loss rate and the like. The controller delivers SRv TE Policy to the head node, i.e., the first node, via BGP extension protocol. The method is realized through newly defined sub-address family identification (English: sub-sequence ADDRESS FAMILY IDENTIFIER, SAFI for short) in BGP extension protocol, namely BGPSRv TE Policy address family.

In the embodiment of the application, the first BGP message comprises a network layer reachability information (English: network Layer Reachability Information, abbreviated: NLRI) field, and the NLRI field indicates SR-MPLS TE Policy. The first BGP message also includes optional attributes of the existing BGP protocol and BGP extension protocol, and may also include any optional attributes.

The NLRI field includes an NLRI Length (Length) field, a Distinguisher field, a Policy Color field, and an end field. The NLRI length field occupies 1 byte to represent the NLRI length, the distinguishing field occupies 4 bytes to represent the NLRI identification, the strategy Color field occupies 4 bytes to represent the Color attribute of the SR-MPLS TE Policy, and the tail end field occupies 4 or 16 bytes to represent the tail end attribute of the SR-MPLS TE Policy.

The first BGP message also includes an attribute (Attributes) field and a tunnel encapsulation attribute (Tunnel Encapsulation Attribute) field, where the tunnel encapsulation attribute field is used to carry the configuration file of SR-MPLS TE Policy, that is, the content of SRv TE Policy. The Tunnel encapsulation attribute field includes a Tunnel Type (Tunnel-Type) field, which is a TLV structure and includes a plurality of Sub-TLV (Sub-TLV) structures.

SRv6 TE Policy format is as follows:

Wherein ,Binding SID、SRv6 Binding SID、Preference、Priority、Policy Name、Policy Candidate Path Name、Explicit NULL Label Policy(ENLP) and SEGMENT LIST are both sub-TLV structures. In the SEGMENT LIST Sub-TLV structure, a Value (Value) field is included, and a Sub-TLV (Sub-TLV) structure is extended in the Value field, for carrying the first signature.

As shown in fig. 2, fig. 2 is a schematic diagram of an extended TLV structure according to an embodiment of the present application. In fig. 2, the sub-TLV structure includes a Type (Type) field, a Length (Length) field, a Flags (Flags) field, a RESERVED (RESERVED) field, and a Xsec signature (Xsec Signature) field.

The system comprises a type field, a length field, a mark field, a reserved field and a Xsec signature field, wherein the type field occupies 8 bits and has a value of 1601 (which can be set according to actual needs), the length field occupies 8 bits and represents the message length, the type field and the length field are not included, the mark field occupies 8 bits and has a value of all 0 (which can be set according to actual needs), the reserved field occupies 8 bits and has a reserved value, and the Xsec signature field occupies the space according to actual conditions and is used for bearing a first signature.

It is to be appreciated that SRv TE Policy may include multiple candidate paths, each of which may in turn include multiple segment lists. In the foregoing example, a candidate path including a segment list therein is illustrated as an example. In practical applications, each segment list included under each candidate path includes a Sub-TLV (Sub-TLV) structure, that is, a first signature.

It should be noted that, according to the configuration file, the first node stores the first signature in the local SRv TE Policy after the first node configures the SRv TE Policy locally according to the existing configuration process in the local configuration SRv TE Policy process.

The procedure of the first node for generating the table entry corresponding to SRv TE Policy is the same as the existing generation procedure, and will not be repeated.

Specifically, when the first node is a head node, the first node receives a second BGP message sent by the controller before receiving the first BGP message, where the second BGP message includes a public key and a second controller identifier, and the second controller identifier is an identifier of the controller. The second BGP message may be specifically a BGP UPDATE message.

It can be appreciated that the first node locally stores the public key and the second controller identifier, where the public key and the second controller identifier are used for security authentication of the received service message by the subsequent first node. In the following embodiments, a procedure of performing security authentication on the received service message by each node will be described separately, and will not be described again.

Specifically, when the first node is a head node, the first node generates a third BGP message, where the third BGP message includes the first signature.

The first node sends a third BGP message to the controller. The third BGP message is sent when the first node acquires the first signature and periodically notifies the controller of the self-link state and SID. And other nodes except the head node on the forwarding path do not send the third BGP message to the controller, and the other nodes periodically send BGP-LS messages to the controller through the link state according to the rule of the existing BGP protocol.

The third BGP message is specifically a BGP-LS message.

Further, the third BGP message includes an NLRI field, and a Link-State (Link-State) is indicated by the NLRI field. The third BGP message also includes optional attributes of the existing BGP protocol and BGP extension protocol, and may also include any optional attributes.

In the embodiment of the application, a TLV structure is extended in the NLRI field. As shown in fig. 3, fig. 3 is a schematic structural diagram of an extended TLV according to an embodiment of the present application. In fig. 3, the extended TLV structure includes a Type (Type) field, a Length (Length) field, a Flags (Flags) field, and Xsec signature (Xsec Signature) field.

The system comprises a type field, a length field, a mark field, a Xsec signature field and a Xsec signature field, wherein the type field occupies 8 bits and has a value of 1601 (which can be set according to actual needs), the length field occupies 8 bits and represents the length of a message, the type field and the length field are not included, the mark field occupies 8 bits and has a value of all 0 (which can be set according to actual needs), and the Xsec signature field occupies according to actual conditions and is used for bearing a first signature.

specifically, when the first node is the head node, the first node receives a service message, and the service message may be specifically sent by the user side network device.

After receiving the service message, the first node determines to forward the service message through SRv TE Policy according to the existing forwarding rule (e.g., searching for a forwarding table). The first node firstly acquires the stored public key, and decrypts the first signature by using the public key to acquire the first controller identifier.

The first node re-obtains the stored second controller identification and identifies whether the first controller identification is the same as the second controller identification.

In one implementation, if the first controller identifier is the same as the second controller identifier, the first node determines that the service message passes the security authentication. According to the existing SRv protocol, the first node encapsulates an SRH header on the outer layer of the service message, and obtains a second SRv message, where the SRH header includes a first signature.

It can be understood that the first node further encapsulates the IPv6 base header on the outer layer of the SRH header, to obtain a second SRv message.

On the forwarding path, the first node continues to send the second SRv message to the third node. The third node is a transmission node or a tail node.

The process of encapsulating the SRH header and the IPv6 basic header by the first node is the same as the existing encapsulation process, and will not be repeated here.

Further, the SRH header includes an optional TLV object field (Optional TYPE LENGTH Value objects). Within the optional TLV object, a TLV structure is extended. As shown in fig. 4, fig. 4 is a schematic diagram of another extended TLV structure according to an embodiment of the present application. In fig. 4, the extended TLV structure includes a Type (Type) field, a Length (Length) field, a RESERVED (RESERVED) field, and Xsec signature (Xsec Signature) field.

The system comprises a type field, a length field, a reserved field and a Xsec signature field, wherein the type field occupies 8 bits and has a value 1601 (which can be set according to actual needs), the length field occupies 8 bits and is used for representing the length of a message, the type field and the length field are not included, the reserved field occupies 8 bits and is reserved, and the Xsec signature field occupies according to actual conditions and is used for bearing a first signature.

In another manner, if the first controller identifier is different from the second controller identifier, the first node determines that the service message fails the security authentication, and at this time, the service message is continuously forwarded, so that a potential safety hazard occurs. The first node discards the service message.

The communication method provided by the embodiment of the application is described in detail below. Referring to fig. 5, fig. 5 is a flowchart of another communication method according to an embodiment of the present application. The method is applied to a controller. The communication method provided by the embodiment of the application can comprise the following steps.

Step 510, obtaining a stored public key;

specifically, a xSEC authentication framework is utilized between the controller and each node to interact with the public key. This public key may also be referred to as xSEC public keys.

The controller obtains the stored public key from the local.

Step 520, a first BGP message is sent to each node in the network, where the first BGP message includes the public key and an identifier of the controller, so that after each node receives the message, it uses the public key and the identifier of the controller to perform security authentication on the message, and forwards or discards the message according to a security authentication result.

Specifically, the controller generates a first BGP message that includes the public key and an identity of the controller.

The controller sends a first BGP message to each node within SRv's network. From the foregoing embodiments, each node stores the public key and the identity of the controller locally. Subsequently, after each node receives the message, the public key and the identifier of the controller are utilized to carry out security authentication on the message, and the message is forwarded or discarded according to the security authentication result.

It can be appreciated that the first BGP message is the same as the second BGP message in the foregoing embodiment, which is not repeated herein. In the foregoing embodiments, the process of performing security authentication on the received message by each node using the public key and the identifier of the controller, and forwarding or discarding the message according to the security authentication result has been described in detail, which will not be repeated here.

Specifically, the controller obtains a private key (also referred to as xSEC private key) corresponding to the public key from the local. The first signature is obtained after the controller's identity is encrypted using the private key (the same encryption process as that of the prior xSEC is not repeated here).

And SRv, each node in the network is used for reporting BGP-LS messages to the controller. The BGP-LS message includes network topology information and the SID of the node. The controller collects the network topology and SIDs of each node in the network by a plurality of BGP-LS messages. The network topology information comprises link overhead, time delay, packet loss rate and the like.

BGP neighbors of BGP IPv6 SR-Policy address family are established between the controller and the first node, i.e., the head node. Meanwhile, according to the network topology, the controller calculates SRv TE Policy based on the dimensions of link overhead, time delay, packet loss rate and the like. The controller stores the first signature in a profile middle list (SEGMENT LIST).

The controller generates a second BGP message that includes a SRv TE Policy configuration file. And through a BGP extension protocol, the controller sends a second BGP message to the first node, so that the first node configures SRv TE Policy locally and generates an entry corresponding to SRv TE Policy according to the configuration file, wherein a first signature is stored in SRv TE Policy locally configured by the first node. The first signature may be embodied in a segment string format.

It will be appreciated that the second BGP message is the same as the first BGP message in the foregoing embodiment, and will not be repeated here.

After the first node obtains the first signature, a third BGP message is generated, and the third BGP message comprises the first signature. The first node sends a third BGP message to the controller. And the controller receives a third BGP message sent by the first node. The third BGP message is sent when the first node acquires the first signature and periodically notifies the controller of the self-link state and SID. And other nodes except the head node on the forwarding path do not send the third BGP message to the controller, and the other nodes periodically send BGP-LS messages to the controller through the link state according to the rule of the existing BGP protocol.

It should be noted that, the third BGP message is specifically a BGP LS message.

It is to be understood that the third BGP message is the same as the third BGP message in the foregoing embodiment, and will not be repeated here.

The controller acquires the stored public key, and sends a first BGP message to each node in the network, wherein the first BGP message comprises the public key and the identifier of the controller, so that each node carries out security authentication on the message by using the public key and the identifier of the controller after receiving the message, and forwards or discards the message according to the security authentication result.

The communication method provided by the embodiment of the application is described in detail below. Referring to fig. 6, fig. 6 is a schematic diagram illustrating SRv to network according to an embodiment of the present application. In fig. 6, SRv a network includes a controller, node a, node B, node C, node D, node E, node F, node G, node H. Node A is the head node, node B is the tail node, and nodes C-H are all transmission nodes.

Each node periodically generates a BGP-LS message 1, where the BGP-LS message 1 includes network topology information and a SID of the node. The controller collects the network topology and the SIDs of each node in the network by a plurality of BGP-LS messages 1. The network topology information comprises link overhead, time delay, packet loss rate and the like.

According to the network topology, the controller calculates SRv TE Policy based on the dimensions of link overhead, time delay, packet loss rate and the like. In the embodiment of the application, SRv TE Policy comprises 2 candidate paths, namely a candidate path 1, namely a node A-a node C-a node E-a node G-a node B, and a candidate path 2, namely a node A-a node D-a node F-a node H-B. The segment list of each candidate path is segment list 1: < C, E, G, B >, and segment list 2: < D, F, H, B >.

The controller acquires the self identifier 1 and the public key and generates a BGP message 1. Using xSEC authentication framework, the controller sends BGP message 1 to each node separately. After each node receives BGP message 1, it obtains controller identifier 1 and the public key from the BGP message. Each node stores the controller identification 1 and the public key locally.

After the controller calculates SRv TE Policy, the controller obtains the private key corresponding to the public key. And (5) using the private key, the controller encrypts the self identifier 1 to obtain a signature. The controller carries the signature in the SRv TE Policy's configuration file.

From the foregoing embodiments, the controller carries the signature in a TLV structure within the value field of the segment list. In the embodiment of the present application, since SRv TE Policy includes 2 candidate paths, the controller carries the signature in the value field of the segment list included in each candidate path, respectively.

It can be understood that the controller carries the signature in the value field of the segment list, or it can be understood that the controller signs (or encrypts) the forwarding path represented by the segment list, so that when forwarding the service message through the forwarding path, security authentication needs to be performed on the service message. And after the safety authentication is passed, forwarding through the forwarding path, otherwise, discarding the service message.

The controller generates BGP message 2. The BGP message 2 includes a SRv TE Policy configuration file, and carries a signature in the configuration file.

The controller sends BGP message 2 to node a. After receiving BGP message 2, node a obtains SRv TE Policy configuration file from the BGP message 2. According to the configuration file, node A configures SRv TE Policy locally and generates an entry corresponding to SRv TE Policy. It will be appreciated that the entry may be specifically used in the subsequent forwarding of the service message.

It will be appreciated that in the local configuration SRv TE Policy process, node a may obtain the signature under the segment list included in each candidate path, respectively. When the node A determines that the service message is forwarded through a certain forwarding path, the signature under the segment list included in the candidate path is required to be utilized to carry out security authentication on the service message. And after the safety authentication is passed, forwarding through the forwarding path, otherwise, discarding the service message.

In the embodiment of the application, each node also periodically generates BGP-LS message 2. Node B-node H still generates and transmits BGP-LS message 2 to the controller as specified by the existing BGP protocol. In the process of generating the BGP-LS message 2, the node A carries the obtained signature in the BGP-LS message 2 and sends the signature to the controller, so that the controller can carry out security authentication on the service message when determining that the two forwarding paths forward the service.

The node a receives the service packet 1 sent by the user side, and determines to forward the service packet 1 through the forwarding path 1 in SRv TE Policy according to the existing SRv protocol specification and forwarding rules (e.g., find forwarding table). The node a first obtains the stored public key, and decrypts the signature by using the public key, thereby obtaining the controller identifier 2.

Node a again retrieves the stored controller identification 1 and identifies whether the controller identification 1 is identical to the controller identification 2.

If the controller identifier 1 is the same as the controller identifier 2, the node A determines that the service message 1 passes the security authentication. According to the existing SRv protocol, the node encapsulates an SRH header and an IPv6 basic header on the outer layer of the service message 1 to obtain a SRv6 message 1, wherein the SRH header comprises a segment list 1 and a signature.

On forwarding path 1, node a continues to send SRv message 1 to node C. After receiving SRv message 1, node C updates the IPv6 header and SRH header included in SRv message 1 according to the existing SRv6 protocol specification and forwarding rules (e.g., lookup of forwarding tables).

If the node C recognizes SRv that the message 1 includes a signature, the node C obtains a public key from the local and decrypts the signature by using the public key to obtain the controller identifier 2.

After the node C obtains the controller identifier 2, the controller identifier 1 is obtained locally. Node C identifies whether controller identification 1 is identical to controller identification 2.

If the controller identifier 1 is the same as the controller identifier 2, the node C determines SRv that the message 1 passes the security authentication. Node C continues forwarding SRv message 1 as specified by the existing SRv protocol.

And the node C updates the destination address included in the IPv6 header and the SL included in the SRH header, and continues to speak the signature and store the signature in the SRH header to obtain SRv message 2.

On forwarding path 1, node C continues to send SRv message 2 to node E.

Similarly, the node E, the node G, and the node B will also execute the process of the node C, and forward the SRv message after performing security authentication.

It can be understood that, when the node B is yes, after determining SRv that the message passes the security authentication, the node B decapsulates the IPv6 header and the SRH header to obtain the service message 1. The node B continues to forward to the user side and will not be repeated here.

Based on the same inventive concept, the embodiment of the application also provides a communication device corresponding to the communication method. Referring to fig. 7, fig. 7 is a communication device provided in an embodiment of the present application, where the device is applied to a first node, and the device includes:

A receiving unit 710, configured to receive a first SRv message;

a decryption unit 720, configured to decrypt, if the first SRv message includes a first signature, the first signature according to the stored public key, to obtain a first controller identifier;

A sending unit 730, configured to forward the first SRv message if the first controller identifier is the same as the stored second controller identifier;

And a discarding unit 740, configured to discard the first SRv message if the first controller identifier is different from the second controller identifier.

Optionally, the receiving unit 710 is further configured to, when the first node is a head node, receive a first BGP packet sent by the controller, where the first BGP packet includes a SRv TE Policy configuration file, and the configuration file includes the first signature;

The device also comprises a configuration unit (not shown in the figure) for locally configuring the SRv TE Policy and generating an entry corresponding to the SRv TE Policy according to the configuration file;

the first signature is obtained by the controller through encryption processing of the identifier of the controller by utilizing a private key corresponding to the public key, and the first signature is stored in the middle section list of the configuration file;

and storing the first signature in the SRv TE Policy locally configured by the first node.

Optionally, the receiving unit 710 is further configured to receive a second BGP message sent by the controller, where the second BGP message includes the public key and the second controller identifier;

wherein the second controller identifier is an identifier of the controller.

Optionally, the sending unit 730 is further configured to send a third BGP packet to the controller when the first node is the head node, where the third BGP packet includes the first signature.

Optionally, the receiving unit 710 is further configured to receive a service packet when the first node is a head node;

The device further comprises a decryption unit (not shown in the figure) for decrypting the first signature according to the public key to obtain the first controller identifier when the service message is determined to be forwarded through the SRv TE Policy;

An encapsulation unit (not shown in the figure) configured to encapsulate an SRH header in an outer layer of the service packet if the first controller identifier is the same as the second controller identifier, to obtain a second SRv packet, where the SRH header includes the first signature;

the sending unit 730 is further configured to send the second SRv to a third node;

The third node is a transmission node or a tail node.

Therefore, by applying the communication device provided by the application, the first node receives the first SRv message, if the first SRv message comprises the first signature, the first node decrypts the first signature according to the stored public key to obtain the first controller identifier, if the first controller identifier is the same as the stored second controller identifier, the first node forwards the first SRv6 message, and if the first controller identifier is different from the second controller identifier, the first node discards the first SRv message.

Based on the same inventive concept, the embodiment of the application also provides a communication device corresponding to the communication method. Referring to fig. 8, fig. 8 is another communication device provided in an embodiment of the present application, where the device is applied to a controller, and the device includes:

an obtaining unit 810 for obtaining a stored public key;

And the sending unit 820 is configured to send a first BGP message to each node in the network, where the first BGP message includes the public key and an identifier of the controller, so that after each node receives the message, it uses the public key and the identifier of the controller to perform security authentication on the message, and forwards or discards the message according to a security authentication result.

Optionally, the apparatus further comprises:

An acquisition unit (not shown in the figure) for acquiring a private key corresponding to the public key;

an encryption unit (not shown in the figure) for encrypting the identifier of the controller by using the private key to obtain a first signature;

a generating unit (not shown in the figure) configured to generate a SRv TE Policy configuration file, where the first signature is stored in a middle section list of the SRv TE Policy configuration file;

The sending unit 820 is further configured to send a second BGP message to the first node, where the second BGP message includes a configuration file of SRv TE Policy, so that the first node configures the SRv TE Policy locally and generates an entry corresponding to the SRv TE Policy according to the configuration file, where the SRv TE Policy configured locally by the first node stores the first signature.

Optionally, the apparatus further comprises:

and a receiving unit (not shown in the figure) configured to receive a third BGP message sent by the first node, where the third BGP message includes the first signature.

The controller sends the first BGP message to each node in the network, wherein the first BGP message comprises the public key and the identifier of the controller, so that each node carries out safety authentication on the message by utilizing the public key and the identifier of the controller after receiving the message, and forwards or discards the message according to the safety authentication result.

Based on the same inventive concept, the embodiment of the present application also provides a network device, as shown in fig. 9, including a processor 910, a transceiver 920, and a machine-readable storage medium 930, where the machine-readable storage medium 930 stores machine-executable instructions capable of being executed by the processor 910, and the processor 910 is caused to perform the communication method provided by the embodiment of the present application. The communication devices shown in fig. 7 and 8 may be implemented by using the hardware configuration of the network device shown in fig. 9.

The computer readable storage medium 930 may include a random access Memory (english: random Access Memory, abbreviated as RAM) or a nonvolatile Memory (english: non-volatile Memory, abbreviated as NVM), such as at least one magnetic disk Memory. Optionally, the computer readable storage medium 930 may also be at least one storage device located remotely from the processor 910.

The Processor 910 may be a general-purpose Processor, including a central processing unit (Central Processing Unit, abbreviated as CPU), a network Processor (Network Processor, abbreviated as NP), a digital signal Processor (DIGITAL SIGNAL Processor, abbreviated as DSP), an Application-specific integrated Circuit (ASIC), a Field-Programmable gate array (GATE ARRAY, abbreviated as FPGA), or other Programmable logic device, discrete gate or transistor logic device, or discrete hardware components.

In an embodiment of the present application, processor 910, by reading machine-executable instructions stored in machine-readable storage medium 930, is caused by the machine-executable instructions to implement processor 910 itself and invoke transceiver 920 to perform the communication methods described in the previous embodiments of the present application.

Additionally, embodiments of the present application provide a machine-readable storage medium 930, the machine-readable storage medium 930 storing machine-executable instructions that, when invoked and executed by the processor 910, cause the processor 910 itself and the invoking transceiver 920 to perform the communication methods described in the foregoing embodiments of the present application.

The implementation process of the functions and roles of each unit in the above device is specifically shown in the implementation process of the corresponding steps in the above method, and will not be described herein again.

For the device embodiments, reference is made to the description of the method embodiments for the relevant points, since they essentially correspond to the method embodiments. The apparatus embodiments described above are merely illustrative, wherein the elements illustrated as separate elements may or may not be physically separate, and the elements shown as elements may or may not be physical elements, may be located in one place, or may be distributed over a plurality of network elements. Some or all of the modules may be selected according to actual needs to achieve the purposes of the present application. Those of ordinary skill in the art will understand and implement the present application without undue burden.

For the communication device and the machine-readable storage medium embodiments, since the method content involved is substantially similar to the method embodiments described above, the description is relatively simple, and reference will only be made to part of the description of the method embodiments.

The foregoing description of the preferred embodiments of the application is not intended to be limiting, but rather to enable any modification, equivalent replacement, improvement or the like to be made within the spirit and principles of the application.

Claims

1. A method of communication, the method being applied to a first node, the method comprising:

receiving a first SRv message;

Discarding the first SRv message if the first controller identifier is different from the second controller identifier;

The method further comprises the steps of:

When the first node is a head node, receiving a first BGP message sent by the controller, wherein the first BGP message comprises a SRv TE Policy configuration file, and the configuration file comprises the first signature;

according to the configuration file, the SRv TE Policy is configured locally and a table entry corresponding to the SRv TE Policy is generated;

2. The method of claim 1, wherein the method further comprises, prior to receiving the first SRv message or prior to receiving the first BGP message sent by the controller:

Receiving a second BGP message sent by the controller, wherein the second BGP message comprises the public key and the second controller identifier;

wherein the second controller identifier is an identifier of the controller.

3. The method according to claim 1, wherein the method further comprises:

And when the first node is the head node, sending a third BGP message to the controller, wherein the third BGP message comprises the first signature.

4. The method according to claim 1, wherein the method further comprises:

When the first node is a head node, receiving a service message;

when the service message is determined to be forwarded through the SRv TE Policy, decrypting the first signature according to the public key to obtain the first controller identifier;

If the first controller identifier is the same as the second controller identifier, packaging an SRH header on the outer layer of the service message to obtain a second SRv message, wherein the SRH header comprises the first signature;

Sending the second SRv message to a third node;

The third node is a transmission node or a tail node.

5. A method of communication, the method being applied to a controller, the method comprising:

Acquiring a stored public key;

Sending a first BGP message to each node in a networking, wherein the first BGP message comprises the public key and the identifier of the controller, so that each node performs security authentication on the message by using the public key and the identifier of the controller after receiving the message, and forwards or discards the message according to a security authentication result;

The method further comprises the steps of:

acquiring a private key corresponding to the public key;

encrypting the identifier of the controller by using the private key to obtain a first signature;

Generating SRv a configuration file of the TE Policy, wherein the first signature is stored in a middle section list of the configuration file of the SRv TE Policy;

And sending a second BGP message to the first node, wherein the second BGP message comprises a SRv TE Policy configuration file, so that the first node configures the SRv TE Policy locally and generates a table entry corresponding to the SRv TE Policy according to the configuration file, and the first signature is stored in the SRv TE Policy locally configured by the first node.

6. The method of claim 5, wherein the method further comprises:

And receiving a third BGP message sent by the first node, wherein the third BGP message comprises the first signature.

7. A communication apparatus, the apparatus being applied to a first node, the apparatus comprising:

the receiving unit is used for receiving the first SRv message;

A discarding unit, configured to discard the first SRv message if the first controller identifier is different from the second controller identifier;

the receiving unit is further configured to, when the first node is a head node, receive a first BGP message sent by the controller, where the first BGP message includes a SRv TE Policy configuration file, and the configuration file includes the first signature;

The device also comprises a configuration unit, a configuration unit and a processing unit, wherein the configuration unit is used for locally configuring the SRv TE Policy and generating an entry corresponding to the SRv TE Policy according to the configuration file;

8. A communication device, the device being applied to a controller, the device comprising:

An acquisition unit configured to acquire a stored public key;

a sending unit, configured to send a first BGP message to each node in a network, where the first BGP message includes the public key and an identifier of the controller, so that after each node receives a message, perform security authentication on the message by using the public key and the identifier of the controller, and forward or discard the message according to a security authentication result;

The apparatus further comprises:

an obtaining unit, configured to obtain a private key corresponding to the public key;

The encryption unit is used for encrypting the identifier of the controller by using the private key to obtain a first signature;

The generating unit is used for generating SRv TE Policy configuration files, and the first signature is stored in a SRv TE Policy configuration file middle section list;

the sending unit is further configured to send a second BGP message to the first node, where the second BGP message includes a configuration file of SRv TE Policy, so that the first node configures the SRv TE Policy locally and generates an entry corresponding to the SRv TE Policy according to the configuration file, where the first signature is stored in the SRv TE Policy configured locally by the first node.