Communication method and device

Abstract

The invention provides a communication method and device, the method is applied to a first node, and the method comprises the following steps: receiving a first SRv6 message; if the first SRv6 message comprises a first signature, performing decryption processing on 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, carrying out forwarding processing on the first SRv6 message; and if the first controller identifier is different from the second controller identifier, discarding the first SRv6 message.

Description

Technical Field

[0001] The present application relates to the field of communication technology, and in particular to a communication method and device. Background Art

[0002] The segment routing traffic engineering policy based on the IPv6 forwarding plane (English: Segment Routing IPv6 Traffic Engineering Policy, referred to as: SRv6 TE Policy) provides a flexible forwarding path selection method to meet the different forwarding requirements of users.

[0003] When there are multiple forwarding paths between the source node and the destination node in the SR network, the reasonable use of SRv6TEPolicy to select the forwarding path can not only facilitate the management personnel to manage and plan the network, but also effectively reduce the forwarding pressure of the network equipment.

[0004] In actual networking, the controller collects network topology and the segment identifier (SID) of each network device in the network through Border Gateway Protocol (BGP)-Link State (LS) messages. The network topology information includes link cost, latency, packet loss rate, etc. The controller establishes a BGP neighbor relationship of the BGP IPv6SR-Policy address family with the head node. At the same time, according to the network topology, the controller calculates the SRv6 TE Policy based on link cost, latency, packet loss rate and other dimensions. Through the BGP protocol, the controller sends the SRv6 TE Policy to the head node. The head node configures the SRv6 TE Policy locally and generates SRv6TE Policy-related table entries. Subsequently, the head node can forward the corresponding service packets through the SRv6 TE Policy.

[0005] However, when forwarding service packets, each node on the forwarding path indicated by the SRv6 TE Policy cannot perform security authentication on the service packets, which may lead to security risks such as traffic hijacking and make service transmission impossible to guarantee. Summary of the invention

[0006] In view of this, the present application provides a communication method and device to solve the problem that each node on the forwarding path indicated by the existing SRv6 TE Policy cannot perform security authentication on the service message, which is very likely to cause security risks such as traffic hijacking and cannot ensure service transmission.

[0007] In a first aspect, the present application provides a communication method, which is applied to a first node, and the method includes:

[0008] Receive a first SRv6 message;

[0009] If the first SRv6 message includes a first signature, decrypting the first signature according to the stored public key to obtain a first controller identifier;

[0010] If the first controller identifier is the same as the stored second controller identifier, forwarding the first SRv6 message;

[0011] If the first controller identifier is different from the second controller identifier, the first SRv6 message is discarded.

[0012] In a second aspect, the present application provides a communication method, which is applied to a controller, and the method includes:

[0013] Get the stored public key;

[0014] A first BGP message is sent to each node in the network, wherein the first BGP message includes the public key and the identifier of the controller, so that after receiving the message, each node 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 the security authentication result.

[0015] In a third aspect, the present application provides a communication device, which is applied to a first node, and includes:

[0016] A receiving unit, configured to receive a first SRv6 message;

[0017] a decryption unit, configured to, if the first SRv6 message includes a first signature, decrypt the first signature according to a stored public key to obtain a first controller identifier;

[0018] a sending unit, configured to forward the first SRv6 message if the first controller identifier is the same as the stored second controller identifier;

[0019] A discarding unit, configured to discard the first SRv6 message if the first controller identifier is different from the second controller identifier.

[0020] In a fourth aspect, the present application provides a communication device, which is applied to a controller, and includes:

[0021] An acquisition unit, used for acquiring a stored public key;

[0022] A sending unit is used to send a first BGP message to each node in the network, wherein the first BGP message includes the public key and the identifier of the controller, so that after receiving the message, each node 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 the security authentication result.

[0023] In a fifth aspect, the present application provides a network device, including a processor and a machine-readable storage medium, the machine-readable storage medium storing machine-executable instructions that can be executed by the processor, and the processor is prompted by the machine-executable instructions to execute the method provided in the first aspect of the present application.

[0024] In a sixth aspect, the present application provides a network device, including a processor and a machine-readable storage medium, the machine-readable storage medium storing machine-executable instructions that can be executed by the processor, and the processor is prompted by the machine-executable instructions to execute the method provided in the first aspect of the present application.

[0025] Therefore, by applying the communication method and device provided in the present application, the first node receives the first SRv6 message; if the first SRv6 message includes 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; if the first controller identifier is different from the second controller identifier, the first node discards the first SRv6 message.

[0026] In this way, by carrying the encrypted signature in the SRv6 message, each node on the forwarding path performs security authentication on the SRv6 message. After passing the security authentication, the SRv6 message continues to be forwarded, otherwise, the SRv6 message is discarded. End-to-end security authentication of each node is achieved to prevent the occurrence of events such as traffic hijacking. This solves the problem that each node on the forwarding path indicated by the existing SRv6 TE Policy cannot perform security authentication on the service message, which is very likely to cause security risks such as traffic hijacking and cannot guarantee service transmission. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] Figure 1 A flow chart of a communication method provided in an embodiment of the present application;

[0028] Figure 2 A schematic diagram of an extended TLV structure provided in an embodiment of the present application;

[0029] Figure 3 A schematic diagram of another extended TLV structure provided in an embodiment of the present application;

[0030] Figure 4A schematic diagram of another extended TLV structure provided in an embodiment of the present application;

[0031] Figure 5 A flowchart of another communication method provided in an embodiment of the present application;

[0032] Figure 6 A schematic diagram of an SRv6 network provided in an embodiment of the present application;

[0033] Figure 7 A structural diagram of a communication device provided in an embodiment of the present application;

[0034] Figure 8 A structural diagram of another communication device provided in an embodiment of the present application;

[0035] Fig. 9 The network device hardware structure provided in the embodiment of the present application. DETAILED DESCRIPTION

[0036] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application. Instead, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.

[0037] The terms used in this application are only for the purpose of describing specific embodiments and are not intended to limit this application. The singular forms of "a", "said" and "the" used in this application and the appended claims are also intended to include plural forms unless the context clearly indicates other meanings. It should also be understood that the term "and / or" used in this article refers to and includes any or all possible combinations of one or more corresponding listed items.

[0038] It should be understood that although the terms first, second, third, etc. may be used in the present application to describe various information, these information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of the present application, the first information may also be referred to as the second information, and similarly, the second information may also be referred to as the first information. Depending on the context, the word "if" as used herein may be interpreted as "at the time of" or "when" or "in response to determining".

[0039] The communication method provided in the embodiment of the present application is described in detail below. Figure 1 , Figure 1A flow chart of a communication method provided in an embodiment of the present application. The method is applied to a first node, the first node is on the forwarding path of SRv6, and serves as an intermediate node or tail node for forwarding SRv6 messages. The communication method provided in an embodiment of the present application may include the following steps.

[0040] Step 110: Receive a first SRv6 message;

[0041] Specifically, the first node is in an SRv6 network, and the SRv6 network also includes other nodes, for example, a second node. The first node and the second node form a forwarding path, and forward the service message (SRv6 message) on the forwarding path.

[0042] In an embodiment of the present application, the first node may be a transmission node or a tail node on the forwarding path.

[0043] During the forwarding process, the first node receives a first SRv6 message sent by a previous hop node, where the previous hop node may be a head node or other transmission node, wherein the head node may also be a second node.

[0044] After the second node generates the first SRv6 message, it sends the first SRv6 message to the first node in accordance with the existing SRv6 protocol provisions and forwarding rules (for example, searching the forwarding table); or, after any transmission node receives the first SRv6 message, it continues to send the first SRv6 message to the first node in accordance with the existing SRv6 protocol provisions and forwarding rules (for example, searching the forwarding table).

[0045] Step 120: If the first SRv6 message includes a first signature, decrypt the first signature according to the stored public key to obtain a first controller identifier;

[0046] Specifically, according to the description of step 110, after receiving the first SRv6 message, the first node updates the destination address and segments left (SL) of the first SRv6 message according to the existing SRv6 protocol provisions and forwarding rules (for example, searching the forwarding table).

[0047] If the first node recognizes that the first SRv6 message includes the first signature, the first node obtains the public key locally, and uses the public key to decrypt the first signature to obtain the first controller identifier.

[0048] Optionally, in an embodiment of the present application, before receiving the first SRv6 message, the first node also receives a second BGP message sent by the controller, the second BGP message including a public key and a second control identifier. The second controller identifier is an identifier of the controller (for example, a device ID, a MAC address, an IP address, etc., used to uniquely identify the controller). The second BGP message may specifically be a BGP update (UPDATE) message.

[0049] In an embodiment of the present application, the controller and each node use the xSEC authentication framework to exchange public keys. The public key can also be called an xSEC public key. Furthermore, the xSEC public key can be carried in the extended attributes included in the existing BGP message. Among them, "x" represents an unknown variable, indicating any place, any layer, and any topology, and "SEC" stands for security.

[0050] It is understandable that the controller sends the second BGP message to each node in the network respectively, so that each node stores the public key and the second controller identifier locally. The public key and the second controller identifier are used for each node to perform security authentication on the received service message later. In the subsequent embodiments, the process of each node performing security authentication on the received service message will be described separately, which will not be repeated here.

[0051] Optionally, the first signature is obtained after the controller encrypts its own identification using a private key. The controller carries the first signature in the configuration file of the SRv6 TE Policy and sends it to the second node. After receiving the service message, the second node determines that the service message is forwarded through the SRv6 TE Policy and performs security authentication on the service message. Then, the first signature is carried in the SRv6 message header (English: Segment Routing Header, abbreviated as: SRH) included in the service message, and continues to send it on the forwarding path. In subsequent embodiments, the process of the controller issuing the SRv6 TEPolicy configuration file, the second node performing security authentication on the service message, and carrying the first signature in the SRH header included in the service message will be described separately, and will not be repeated here.

[0052] Step 130: If the first controller identifier is the same as the stored second controller identifier, forwarding the first SRv6 message;

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

[0054] If the first controller identifier is the same as the second controller identifier, the first node determines that the first SRv6 message passes the security authentication. According to the existing SRv6 protocol provisions and forwarding rules (eg, searching the forwarding table), the first node continues to forward the first SRv6 message.

[0055] 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 to forward on the forwarding path. At this time, the first signature is still retained in the SRH header.

[0056] When the first node is a tail node, the first node may decapsulate the IPv6 header and the SRH header to obtain the original message, and the first node continues to forward the original message.

[0057] Step 140: If the first controller identifier is different from the second controller identifier, discard the first SRv6 message.

[0058] 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 SRv6 message has not passed the security authentication. At this time, continuing to forward the first SRv6 message will cause security risks. The first node discards the first SRv6 message.

[0059] Therefore, by applying the communication method provided in the present application, the first node receives the first SRv6 message; if the first SRv6 message includes 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; if the first controller identifier is different from the second controller identifier, the first node discards the first SRv6 message.

[0060] In this way, by carrying the encrypted signature in the SRv6 message, each node on the forwarding path performs security authentication on the SRv6 message. After passing the security authentication, the SRv6 message continues to be forwarded, otherwise, the SRv6 message is discarded. End-to-end security authentication of each node is achieved to prevent the occurrence of events such as traffic hijacking. This solves the problem that each node on the forwarding path indicated by the existing SRv6 TE Policy cannot perform security authentication on the service message, which is very likely to cause security risks such as traffic hijacking and cannot guarantee service transmission.

[0061] Optionally, in the embodiment of the present application, the following steps are also included:

[0062] Specifically, when the first node is a head node, a first BGP message sent by the controller is also received, and the first BGP message includes a configuration file of the SRv6 TE Policy. The configuration file includes a first signature. According to the configuration file, the first node locally configures the SRv6 TE Policy and generates a table entry corresponding to the SRv6 TE Policy. The above-mentioned first BGP message can be specifically a BGP UPDATE message, and further, specifically a BGPSRv6TE Policy address family message.

[0063] The first signature is obtained by the controller using the private key corresponding to the public key (also called the xSEC private key) to encrypt the controller's identifier (the same as the existing xSEC encryption process, which will not be repeated here), and the first signature is stored in the segment list (Segment List) in the configuration file; the first signature is stored in the SRv6 TE Policy configured locally on the first node. The first signature can be specifically in the format of a string.

[0064] It is understandable that each node in the SRv6 network reports a BGP-LS message to the controller. The BGP-LS message includes network topology information and the SID of the node. The controller collects the network topology and the SID of each node in the network through multiple BGP-LS messages. Among them, the network topology information includes link overhead, latency, packet loss rate, etc.

[0065] The controller and the head node establish a BGP neighbor relationship of the BGP IPv6 SR-Policy address family. At the same time, according to the network topology, the controller calculates the SRv6 TE Policy based on link cost, latency, packet loss rate and other dimensions. Through the BGP extension protocol, the controller transmits the SRv6 TE Policy to the head node, which is the first node. This is achieved through the newly defined sub-address family identifier (English: Subsequent Address Family Identifier, referred to as: SAFI) in the BGP extension protocol, namely the BGPSRv6TE Policy address family.

[0066] In the embodiment of the present application, the first BGP message includes a network layer reachability information (NLRI) field, and the NLRI field indicates the SR-MPLS TE Policy. The first BGP message also includes the mandatory attributes of the existing BGP protocol and the BGP extended protocol, and may also include any optional attributes.

[0067] The above NLRI fields include the NLRI length field, the distinguisher field, the policy color field, and the end point field. Among them, the NLRI length field occupies 1 byte and indicates the length of the NLRI; the distinguisher field occupies 4 bytes and indicates the identifier of the NLRI; the policy color field occupies 4 bytes and indicates the color attribute of the SR-MPLS TE Policy; the end point field occupies 4 or 16 bytes and indicates the end point attribute of the SR-MPLS TE Policy.

[0068] The first BGP message also includes an attribute field and a tunnel encapsulation attribute field, and the tunnel encapsulation attribute field is used to carry the configuration file of the SR-MPLS TE Policy, that is, the content of the SRv6 TE Policy. The tunnel encapsulation attribute field includes a tunnel type field, which is a TLV structure and includes multiple sub-TLV structures.

[0069] The format of an SRv6 TE Policy is as follows:

[0070]

[0071]

[0072] Among them, Binding SID, SRv6 Binding SID, Preference, Priority, Policy Name, Policy Candidate Path Name, Explicit NULL Label Policy (ENLP) ​​and Segment List are all sub-TLV structures. In the Segment List sub-TLV structure, a value field is included, and a sub-sub-TLV structure is extended in the value field to carry the first signature.

[0073] like Figure 2 As shown, Figure 2 A schematic diagram of an extended TLV structure provided in an embodiment of the present application. Figure 2 In the sub-sub-TLV structure, the sub-sub-TLV structure includes a type (Type) field, a length (Length) field, a flag (Flags) field, a reserved (RESERVED) field, and an Xsec signature (Xsec Signature) field.

[0074] Among them, the type field occupies 8 bits and its value is 1601 (can be set according to actual needs); the length field occupies 8 bits and indicates the message length, excluding the type field and the length field; the flag field occupies 8 bits and its value is all 0 (can be set according to actual needs); the reserved field occupies 8 bits and is reserved; the Xsec signature field occupies 8 bits according to actual conditions and is used to carry the first signature.

[0075] It is understandable that the SRv6 TE Policy may include multiple candidate paths, and each candidate path may include multiple segment lists. In the above example, a candidate path including a segment list is used as an example for explanation. In actual applications, each segment list included in each candidate path includes a sub-sub-TLV structure, which is the first signature.

[0076] It should be noted that, in the process of locally configuring the SRv6 TE Policy by the first node according to the configuration file, after the first node locally configures the SRv6 TE Policy according to the existing configuration process, the first node stores the first signature in the local SRv6 TE Policy.

[0077] The process of the first node generating a table entry corresponding to the SRv6 TE Policy is the same as the existing generation process and is not repeated here.

[0078] Optionally, in the embodiment of the present application, the following steps are also included:

[0079] Specifically, when the first node is a head node, before receiving the first BGP message, the first node also receives a second BGP message sent by the controller, the second BGP message including a public key and a second controller identifier; the second controller identifier is an identifier of the controller. The second BGP message may be specifically a BGP UPDATE message.

[0080] It is understandable that the first node stores the public key and the second controller identifier locally, wherein the public key and the second controller identifier are used by the first node to subsequently perform security authentication on the received service message. In subsequent embodiments, the process of each node performing security authentication on the received service message will be described separately, which will not be repeated here.

[0081] Optionally, in the embodiment of the present application, the following steps are also included:

[0082] Specifically, when the first node is a head node, the first node generates a third BGP message, and the third BGP message includes the first signature.

[0083] The first node sends a third BGP message to the controller. The third BGP message is sent after the first node obtains the first signature and needs to periodically notify the controller of its own link status and SID. Other nodes except the head node on the forwarding path do not send the third BGP message to the controller. Other nodes still periodically pass the link status to the controller in accordance with the existing BGP protocol, that is, send BGP-LS messages.

[0084] The third BGP message is specifically a BGP-LS message.

[0085] Furthermore, the third BGP message includes an NLRI field, and the NLRI field indicates the link state (Link-State). The third BGP message also includes mandatory attributes of the existing BGP protocol and the BGP extended protocol, and may also include any optional attributes.

[0086] In the embodiment of the present application, a TLV structure is extended in the NLRI field. Figure 3 As shown, Figure 3 A schematic diagram of an extended TLV structure provided in an embodiment of the present application. Figure 3 In the extended TLV structure, the type (Type) field, the length (Length) field, the flag (Flags) field and the Xsec signature (Xsec Signature) field.

[0087] Among them, the type field occupies 8 bits and its value is 1601 (can be set according to actual needs); the length field occupies 8 bits and indicates the message length, excluding the type field and the length field; the flag field occupies 8 bits and its value is all 0 (can be set according to actual needs); the Xsec signature field occupies a place according to actual conditions and is used to carry the first signature.

[0088] Optionally, in the embodiment of the present application, the following steps are also included:

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

[0090] After receiving the service message, the first node determines to forward the service message through the SRv6 TE Policy according to the existing forwarding rules (for example, searching the forwarding table). The first node first obtains the stored public key, and uses the public key to decrypt the first signature to obtain the first controller identifier.

[0091] The first node then obtains the stored second controller identifier, and identifies whether the first controller identifier is the same as the second controller identifier.

[0092] 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 SRv6 protocol, the first node encapsulates the SRH header in the outer layer of the service message to obtain a second SRv6 message, and the SRH header includes the first signature.

[0093] It can be understood that the first node further encapsulates the IPv6 basic header in the outer layer of the SRH header to obtain the second SRv6 message.

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

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

[0096] Furthermore, the SRH header includes an optional TLV object field (Optional Type Length Value objects). In the optional TLV object, a TLV structure is extended. Figure 4 As shown, Figure 4 Another extended TLV structure diagram provided in the embodiment of the present application. Figure 4 In the extended TLV structure, the type (Type) field, the length (Length) field, the reserved (RESERVED) field and the Xsec signature (Xsec Signature) field.

[0097] Among them, the type field occupies 8 bits and its value is 1601 (can be set according to actual needs); the length field occupies 8 bits and indicates the message length, excluding the type field and the length field; the reserved field occupies 8 bits and is reserved; the Xsec signature field occupies a place according to actual conditions and is used to carry the first signature.

[0098] In another manner, if the first controller identifier is different from the second controller identifier, the first node determines that the service message has not passed the security authentication, and at this time, continuing to forward the service message will cause a security risk. The first node discards the service message.

[0099] The communication method provided in the embodiment of the present application is described in detail below. Figure 5 , Figure 5 A flow chart of another communication method provided in an embodiment of the present application. The method is applied to a controller. The communication method provided in an embodiment of the present application may include the following steps.

[0100] Step 510: Obtain the stored public key;

[0101] Specifically, the controller and each node use the xSEC authentication framework to exchange public keys, which can also be called xSEC public keys.

[0102] The controller obtains the public key stored locally.

[0103] Step 520: Send a first BGP message to each node in the network, wherein the first BGP message includes the public key and the identifier of the controller, so that after receiving the message, each node uses the public key and the identifier of the controller to perform security authentication on the message, and forwards or discards the message based on the security authentication result.

[0104] Specifically, the controller generates a first BGP message, where the first BGP message includes a public key and an identifier of the controller.

[0105] The controller sends a first BGP message to each node in the SRv6 network. According to the above embodiment, each node stores the public key and the identifier of the controller locally. Subsequently, after receiving the message, each node 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 the security authentication result.

[0106] It is understandable that the first BGP message is the same as the second BGP message in the aforementioned embodiment, and will not be repeated here. In the aforementioned embodiment, the process of each node using the public key and the controller's identifier to perform security authentication on the received message and forwarding or discarding the message according to the security authentication result has been described in detail, and will not be repeated here.

[0107] Optionally, in the embodiment of the present application, the following steps are also included:

[0108] Specifically, the controller obtains a private key (also called an xSEC private key) corresponding to the public key locally, and uses the private key to encrypt the controller's identifier (the same as the existing xSEC encryption process, which will not be repeated here), to obtain a first signature.

[0109] Each node in the SRv6 network reports a BGP-LS message to the controller. The BGP-LS message includes network topology information and the SID of the node. The controller collects network topology and the SID of each node in the network through multiple BGP-LS messages. The network topology information includes link cost, latency, packet loss rate, etc.

[0110] The controller establishes a BGP neighbor relationship of the BGP IPv6 SR-Policy address family with the first node, which is also the head node. At the same time, according to the network topology, the controller calculates the SRv6 TEPolicy based on link cost, latency, packet loss rate and other dimensions. The controller stores the first signature in the segment list in the configuration file.

[0111] The controller generates a second BGP message, which includes a configuration file of the SRv6 TE Policy. The controller sends the second BGP message to the first node through the BGP extension protocol, so that the first node locally configures the SRv6 TE Policy according to the configuration file and generates a table item corresponding to the SRv6 TE Policy, wherein the first signature is stored in the SRv6 TE Policy locally configured by the first node. The first signature can be specifically in a string format.

[0112] It can be understood that the second BGP message is the same as the first BGP message in the aforementioned embodiment, and will not be repeated here.

[0113] Optionally, in the embodiment of the present application, the following steps are also included:

[0114] After obtaining the first signature, the first node generates a third BGP message, and the third BGP message includes the first signature. The first node sends the third BGP message to the controller. The controller receives the third BGP message sent by the first node. Among them, the third BGP message is sent after the first node obtains the first signature and needs to periodically notify the controller of its own link status and SID. Other nodes except the head node on the forwarding path do not send the third BGP message to the controller. Other nodes still periodically pass the link status to the controller in accordance with the existing BGP protocol, that is, send BGP-LS messages.

[0115] It should be noted that the third BGP message is specifically a BGP LS message.

[0116] It can be understood that the third BGP message is the same as the third BGP message in the aforementioned embodiment, and will not be repeated here.

[0117] Therefore, by applying the communication method provided in the present application, the controller obtains the stored public key; the controller sends a first BGP message to each node in the network, and the first BGP message includes the public key and the 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 based on the security authentication result.

[0118] In this way, by carrying the encrypted signature in the SRv6 message, each node on the forwarding path performs security authentication on the SRv6 message. After passing the security authentication, the SRv6 message continues to be forwarded, otherwise, the SRv6 message is discarded. End-to-end security authentication of each node is achieved to prevent the occurrence of events such as traffic hijacking. This solves the problem that each node on the forwarding path indicated by the existing SRv6 TE Policy cannot perform security authentication on the service message, which is very likely to cause security risks such as traffic hijacking and cannot guarantee service transmission.

[0119] The communication method provided in the embodiment of the present application is described in detail below. Figure 6 , Figure 6 A schematic diagram of SRv6 networking provided in an embodiment of the present application. Figure 6 In the figure, the SRv6 network includes a controller, node A, node B, node C, node D, node E, node F, node G, and node H. Node A is the head node, node B is the tail node, and nodes C to H are all transmission nodes.

[0120] Each node periodically generates a BGP-LS message 1, which includes network topology information and the SID of the node. The controller collects the network topology and the SID of each node in the network through multiple BGP-LS messages 1. The network topology information includes link cost, delay, packet loss rate, etc.

[0121] According to the network topology, the controller calculates SRv6 TEPolicy based on link overhead, latency, packet loss rate and other dimensions. In the embodiment of the present application, SRv6 TE Policy includes two candidate paths, namely, candidate path 1: node A-node C-node E-node G-node B; candidate path 2: node A-node D-node F-node H-node B. The segment list of each candidate path is, segment list 1:<C,E,G,B> ; Segment List 2:<D,F,H,B> .

[0122] The controller obtains its own identification 1 and public key, and generates BGP message 1. Using the xSEC authentication framework, the controller sends BGP message 1 to each node. After receiving BGP message 1, each node obtains the controller identification 1 and public key from it. Each node stores the controller identification 1 and public key locally.

[0123] After calculating the SRv6 TE Policy, the controller obtains the private key corresponding to the public key. Using the private key, the controller encrypts its own ID 1 to obtain a signature. The controller carries the signature in the SRv6 TE Policy configuration file.

[0124] According to the above embodiment, the controller carries the signature in the value field of the segment list in the TLV structure. In the embodiment of the present application, since the SRv6 TE Policy includes two candidate paths, the controller carries the signature in the value field of the segment list included in each candidate path.

[0125] It can be understood that the controller carries the signature in the value field of the segment list, and it can also be understood that the controller signs (or encrypts) the forwarding path represented by the segment list, so that when the business message is forwarded through the forwarding path, the business message needs to be securely authenticated. After the security authentication is passed, it can be forwarded through the forwarding path; otherwise, the business message is discarded.

[0126] The controller generates BGP message 2. BGP message 2 includes the SRv6 TE Policy configuration file, and the configuration file carries a signature.

[0127] The controller sends BGP message 2 to node A. After receiving BGP message 2, node A obtains the SRv6 TEPolicy configuration file from it. According to the configuration file, node A configures SRv6 TE Policy locally and generates a table entry corresponding to SRv6 TEPolicy. It can be understood that this table entry can be specifically used for subsequent forwarding of service messages.

[0128] It is understandable that when node A configures SRv6 TE Policy locally, it can obtain the signatures under the segment list included in each candidate path. When node A determines to forward a service message through a certain forwarding path, it needs to use the signature under the segment list included in the candidate path to perform security authentication on the service message. After the security authentication passes, it can be forwarded through the forwarding path; otherwise, the service message is discarded.

[0129] In the embodiment of the present application, each node also periodically generates BGP-LS message 2. Node B-node H still generates and sends BGP-LS message 2 to the controller in accordance with the existing BGP protocol. In the process of generating BGP-LS message 2, node A carries the above-mentioned signature obtained in BGP-LS message 2 and sends it to the controller, so that the controller performs security authentication on the service message when determining the two forwarding paths for service forwarding.

[0130] Node A receives service message 1 sent by the user side, and determines to forward service message 1 through forwarding path 1 in the SRv6 TE Policy according to the existing SRv6 protocol provisions and forwarding rules (for example, searching the forwarding table). Node A first obtains the stored public key, and uses the public key to decrypt the signature to obtain the controller identifier 2.

[0131] Node A then obtains the stored controller identification 1 and identifies whether the controller identification 1 is the same as the controller identification 2.

[0132] If controller identifier 1 is the same as controller identifier 2, node A determines that service message 1 passes security authentication. According to the existing SRv6 protocol, the node encapsulates the SRH header and the IPv6 basic header in the outer layer of service message 1 to obtain SRv6 message 1, which includes segment list 1 and signature.

[0133] On forwarding path 1, node A continues to send SRv6 message 1 to node C. After receiving SRv6 message 1, node C updates the IPv6 header and SRH header included in SRv6 message 1 according to existing SRv6 protocol regulations and forwarding rules (for example, searching the forwarding table).

[0134] If node C recognizes that SRv6 message 1 includes a signature, node C obtains the public key locally and uses the public key to decrypt the signature to obtain controller identification 2.

[0135] After node C obtains controller ID 2, it obtains controller ID 1 locally. Node C identifies whether controller ID 1 is the same as controller ID 2.

[0136] If the controller identifier 1 is the same as the controller identifier 2, the node C determines that the SRv6 message 1 passes the security authentication. According to the existing SRv6 protocol, the node C continues to forward the SRv6 message 1.

[0137] Node C updates the destination address included in the IPv6 header and the SL included in the SRH header, and continues to store the signature in the SRH header, thereby obtaining SRv6 message 2.

[0138] On forwarding path 1, node C continues to send SRv6 packet 2 to node E.

[0139] Similarly, nodes E, G, and B will also execute the process of node C above, and forward the SRv6 message after security authentication.

[0140] It can be understood that, since node B is, after determining that the SRv6 message passes the security authentication, node B decapsulates the IPv6 header and the SRH header to obtain service message 1. Node B continues to forward to the user side, which will not be repeated here.

[0141] Based on the same inventive concept, the present application embodiment also provides a communication device corresponding to the communication method. Figure 7 , Figure 7 A communication device provided in an embodiment of the present application is applied to a first node, and the device includes:

[0142] The receiving unit 710 is configured to receive a first SRv6 message;

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

[0144] The sending unit 730 is configured to forward the first SRv6 message if the first controller identifier is the same as the stored second controller identifier;

[0145] The discarding unit 740 is configured to discard the first SRv6 message if the first controller identifier is different from the second controller identifier.

[0146] Optionally, the receiving unit 710 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 configuration file of an SRv6 TE Policy, and the configuration file includes the first signature;

[0147] The apparatus further includes: a configuration unit (not shown in the figure), configured to locally configure the SRv6 TE Policy according to the configuration file and generate a table entry corresponding to the SRv6 TE Policy;

[0148] The first signature is obtained by the controller after encrypting the identifier of the controller using the private key corresponding to the public key, and the first signature is stored in the segment list in the configuration file;

[0149] The first signature is stored in the SRv6 TE Policy locally configured by the first node.

[0150] 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;

[0151] The second controller identifier is an identifier of the controller.

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

[0153] Optionally, the receiving unit 710 is further configured to, when the first node is a head node, receive a service message;

[0154] The device further includes: a decryption unit (not shown in the figure), configured to decrypt the first signature according to the public key to obtain the first controller identifier when it is determined that the service message is forwarded through the SRv6 TE Policy;

[0155] an encapsulation unit (not shown in the figure), configured to encapsulate an SRH header in an outer layer of the service message to obtain a second SRv6 message if the first controller identifier is the same as the second controller identifier, wherein the SRH header includes the first signature;

[0156] The sending unit 730 is further configured to send the second SRv6 message to the third node;

[0157] The third node is a transmission node or a tail node.

[0158] Therefore, by applying the communication device provided in the present application, the first node receives the first SRv6 message; if the first SRv6 message includes 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; if the first controller identifier is different from the second controller identifier, the first node discards the first SRv6 message.

[0159] In this way, by carrying the encrypted signature in the SRv6 message, each node on the forwarding path performs security authentication on the SRv6 message. After passing the security authentication, the SRv6 message continues to be forwarded, otherwise, the SRv6 message is discarded. End-to-end security authentication of each node is achieved to prevent the occurrence of events such as traffic hijacking. This solves the problem that each node on the forwarding path indicated by the existing SRv6 TE Policy cannot perform security authentication on the service message, which is very likely to cause security risks such as traffic hijacking and cannot guarantee service transmission.

[0160] Based on the same inventive concept, the present application embodiment also provides a communication device corresponding to the communication method. Figure 8 , Figure 8 Another communication device provided in an embodiment of the present application is applied to a controller, and the device includes:

[0161] An acquisition unit 810, configured to acquire a stored public key;

[0162] The sending unit 820 is used to send a first BGP message to each node in the network, wherein the first BGP message includes the public key and the identifier of the controller, so that after receiving the message, each node 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 the security authentication result.

[0163] Optionally, the device further comprises:

[0164] An acquisition unit (not shown in the figure), used to acquire a private key corresponding to the public key;

[0165] An encryption unit (not shown in the figure), used to encrypt the identifier of the controller using the private key to obtain a first signature;

[0166] A generating unit (not shown in the figure), configured to generate a configuration file of an SRv6 TE Policy, wherein the first signature is stored in a segment list in the configuration file of the SRv6TEPolicy;

[0167] 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 the SRv6 TE Policy, so that the first node locally configures the SRv6 TE Policy according to the configuration file and generates a table entry corresponding to the SRv6 TE Policy, wherein the first signature is stored in the SRv6 TE Policy locally configured by the first node.

[0168] Optionally, the device further comprises:

[0169] A receiving unit (not shown in the figure) is used to receive a third BGP message sent by the first node, where the third BGP message includes the first signature.

[0170] Therefore, by applying the communication device provided in the present application, the controller obtains the stored public key; the controller sends a first BGP message to each node in the network, and the first BGP message includes the public key and the 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 based on the security authentication result.

[0171] In this way, by carrying the encrypted signature in the SRv6 message, each node on the forwarding path performs security authentication on the SRv6 message. After passing the security authentication, the SRv6 message continues to be forwarded, otherwise, the SRv6 message is discarded. End-to-end security authentication of each node is achieved to prevent the occurrence of events such as traffic hijacking. This solves the problem that each node on the forwarding path indicated by the existing SRv6 TE Policy cannot perform security authentication on the service message, which is very likely to cause security risks such as traffic hijacking and cannot guarantee service transmission.

[0172] Based on the same inventive concept, the embodiment of the present application also provides a network device, such as Fig. 9 As shown, it includes a processor 910, a transceiver 920 and a machine-readable storage medium 930, the machine-readable storage medium 930 stores machine-executable instructions that can be executed by the processor 910, and the processor 910 is prompted by the machine-executable instructions to execute the communication method provided in the embodiment of the present application. Figure 7 , Figure 8 The communication device shown can be used as Fig. 9 The network device hardware structure shown is implemented.

[0173] The computer-readable storage medium 930 may include a random access memory (RAM) or a non-volatile memory (NVM), such as at least one disk storage. Optionally, the computer-readable storage medium 930 may also be at least one storage device located away from the processor 910.

[0174] The processor 910 may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it may also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gates or transistor logic devices, or discrete hardware components.

[0175] In the embodiment of the present application, the processor 910 reads the machine executable instructions stored in the machine readable storage medium 930, and the machine executable instructions enable the processor 910 itself and call the transceiver 920 to execute the communication method described in the aforementioned embodiment of the present application.

[0176] In addition, an embodiment of the present application provides a machine-readable storage medium 930, which stores machine-executable instructions. When called and executed by the processor 910, the machine-executable instructions prompt the processor 910 itself and the calling transceiver 920 to execute the communication method described in the aforementioned embodiment of the present application.

[0177] The implementation process of the functions and effects of each unit in the above-mentioned device is specifically described in the implementation process of the corresponding steps in the above-mentioned method, and will not be repeated here.

[0178] For the device embodiment, since it basically corresponds to the method embodiment, the relevant parts can refer to the partial description of the method embodiment. The device embodiment described above is only schematic, wherein the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the present application scheme. A person of ordinary skill in the art can understand and implement it without paying any creative work.

[0179] As for the communication device and machine-readable storage medium embodiments, since the method contents involved are basically similar to the aforementioned method embodiments, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiments.

[0180] The above description is only a preferred embodiment of the present application and is not intended to limit the present application. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present application shall be included in the scope of protection of the present application.

Claims

1. A communication method, characterized in that: The method is applied to a first node, and the method comprises: Receive a first SRv6 message; If the first SRv6 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 SRv6 message; If the first controller identifier is different from the second controller identifier, the first SRv6 message is discarded.

2. The method according to claim 1, characterized in that The method further comprises: When the first node is a head node, receiving a first BGP message sent by the controller, where the first BGP message includes a configuration file of an SRv6 TE Policy, and the configuration file includes the first signature; According to the configuration file, locally configure the SRv6 TE Policy and generate a table entry corresponding to the SRv6 TE Policy; The first signature is obtained by the controller after encrypting the identifier of the controller using the private key corresponding to the public key, and the first signature is stored in the segment list in the configuration file; The first signature is stored in the SRv6 TE Policy locally configured by the first node.

3. The method according to claim 1 or 2, characterized in that: Before receiving the first SRv6 message, or before receiving the first BGP message sent by the controller, the method further includes: receiving a second BGP message sent by the controller, where the second BGP message includes the public key and an identifier of the second controller; The second controller identifier is an identifier of the controller.

4. The method according to claim 2, characterized in that: The method further comprises: When the first node is the head node, a third BGP message is sent to the controller, where the third BGP message includes the first signature.

5. The method according to claim 2, characterized in that: The method further comprises: When the first node is a head node, receiving a service message; When it is determined that the service message is forwarded through the SRv6 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, encapsulating an SRH header in an outer layer of the service message to obtain a second SRv6 message, where the SRH header includes the first signature; Sending the second SRv6 message to the third node; The third node is a transmission node or a tail node.

6. A communication method, characterized in that: The method is applied to a controller, and the method comprises: Get the stored public key; A first BGP message is sent to each node in the network, wherein the first BGP message includes the public key and the identifier of the controller, so that after receiving the message, each node 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 the security authentication result.

7. The method according to claim 6, characterized in that The method further comprises: Obtaining a private key corresponding to the public key; Using the private key, encrypting the identifier of the controller to obtain a first signature; Generate a configuration file of an SRv6 TE Policy, wherein the first signature is stored in a segment list in the configuration file of the SRv6 TE Policy; Sending a second BGP message to the first node, where the second BGP message includes a configuration file of the SRv6 TE Policy, so that the first node locally configures the SRv6 TE Policy according to the configuration file and generates a table entry corresponding to the SRv6 TE Policy, wherein the first signature is stored in the SRv6 TE Policy locally configured by the first node.

8. The method according to claim 7, characterized in that The method further comprises: A third BGP message sent by the first node is received, where the third BGP message includes the first signature.

9. A communication device, characterized in that: The device is applied to a first node, and includes: A receiving unit, configured to receive a first SRv6 message; a decryption unit, configured to, if the first SRv6 message includes a first signature, decrypt the first signature according to a stored public key to obtain a first controller identifier; a sending unit, configured to forward the first SRv6 message if the first controller identifier is the same as the stored second controller identifier; A discarding unit, configured to discard the first SRv6 message if the first controller identifier is different from the second controller identifier.

10. A communication device, characterized in that: The device is applied to a controller, and the device comprises: An acquisition unit, used for acquiring a stored public key; A sending unit is used to send a first BGP message to each node in the network, wherein the first BGP message includes the public key and the identifier of the controller, so that after receiving the message, each node 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 the security authentication result.

Images