Communication method and apparatus

Abstract

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

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of communication, and particularly relates to a communication method and device. BACKGROUND

[0002] Segment Routing IPv6 Traffic Engineering Policy (SRv6 TE Policy) based on an IPv6 forwarding plane provides a flexible forwarding path selection method, which can meet different forwarding requirements of users.

[0003] When there are multiple forwarding paths between a source node and a destination node in an SR network, reasonably utilizing SRv6 TE Policy to select a forwarding path can not only facilitate network management and planning of management personnel, but also effectively reduce the forwarding pressure of network equipment.

[0004] In actual networking, a controller collects network topology and a Segment Identifier (SID) of each network device in the networking through a Border Gateway Protocol (BGP)-Link State (LS) message. The network topology information includes link cost, delay, packet loss rate, etc. The controller establishes a BGP neighbor of a BGP IPv6 SR-Policy address family with a head node. Meanwhile, according to the network topology, the controller calculates SRv6 TE Policy based on dimensions such as link cost, delay, packet loss rate, etc. Through the BGP protocol, the controller issues the SRv6 TE Policy to the head node. The head node locally configures the SRv6 TE Policy and generates an SRv6 TE Policy related table item. Subsequently, the head node can forward corresponding service messages through the SRv6 TE Policy.

[0005] However, when forwarding service messages, each node on the forwarding path indicated by the SRv6 TE Policy cannot perform security authentication on the service messages, and security risks such as traffic hijacking are likely to occur, which cannot guarantee service transmission. SUMMARY

[0006] Therefore, 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 service messages, security risks such as traffic hijacking are likely to occur, and service transmission cannot be guaranteed.

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

[0008] receiving a first SRv6 packet;

[0009] if the first SRv6 packet comprises a first signature, performing decryption processing on the first signature according to a stored public key to obtain a first controller identifier;

[0010] if the first controller identifier is the same as a stored second controller identifier, performing forwarding processing on the first SRv6 packet;

[0011] if the first controller identifier is different from the second controller identifier, discarding the first SRv6 packet.

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

[0013] obtaining a stored public key;

[0014] sending a first BGP packet to each node in a network, the first BGP packet comprising the public key and an identifier of the controller, so that each node performs security authentication on the packet by using the public key and the identifier of the controller after receiving the packet, and forwards or discards the packet according to a security authentication result.

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

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

[0017] a decryption unit, configured to, if the first SRv6 packet comprises a first signature, perform decryption processing on the first signature according to a stored public key to obtain a first controller identifier;

[0018] a sending unit, configured to, if the first controller identifier is the same as a stored second controller identifier, perform forwarding processing on the first SRv6 packet;

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

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

[0021] an obtaining unit, configured to obtain a stored public key;

[0022] The sending unit is configured to send 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.

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

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

[0025] Therefore, by applying the communication method and device provided in the present application, the first node receives a first SRv6 message; if the first SRv6 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; 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 can perform security authentication on the SRv6 message. After security authentication, the SRv6 message is continued to be forwarded, otherwise, the SRv6 message is discarded. The end-to-end security authentication of each node is realized, and the occurrence of events such as traffic hijacking is prevented. The problem that the existing SRv6 TE Policy indication cannot perform security authentication on the service message by each node on the forwarding path, and the security risks such as traffic hijacking are extremely likely to occur, and the service transmission cannot be guaranteed, is solved. BRIEF DESCRIPTION OF DRAWINGS

[0027] Figure 1 A flowchart of a communication method provided by an embodiment of the present application;

[0028] Figure 2 An extension TLV structure diagram provided by an embodiment of the present application;

[0029] Figure 3 Another extension TLV structure diagram provided by an embodiment of the present application;

[0030] Figure 4Another extended TLV structure diagram provided by the embodiment of the present application is shown in FIG. 6.

[0031] Figure 5 A flow chart of another communication method provided by the embodiment of the present application is shown in FIG. 7.

[0032] Figure 6 A SRv6 networking diagram provided by the embodiment of the present application is shown in FIG. 8.

[0033] Figure 7 A communication device structure diagram provided by the embodiment of the present application is shown in FIG. 9.

[0034] Figure 8 Another communication device structure diagram provided by the embodiment of the present application is shown in FIG. 10.

[0035] Figure 9 A network device hardware structure provided by the embodiment of the present application is shown in FIG. 11. DETAILED DESCRIPTION

[0036] The exemplary embodiments will be described in detail herein with reference to the attached drawings. The following description is made with reference to the accompanying drawings in which like reference numerals represent like elements or similar elements, unless context dictates otherwise. The following exemplary embodiments described herein represent only examples of the devices and methods in accordance with aspects of the present application as detailed in the appended claims. No limitation on the scope of the present application is intended by reference to the exemplary embodiments.

[0037] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the present application. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" and / or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0038] It is to be understood that the singular forms "a", "an", and "the" include plural referents unless the context clearly dictates otherwise. It is to be further understood that the terms "comprise", "comprising", "comprises", "including", "includes" or "contain" or "containing" when used in this specification, specify the presence of stated features, integers, steps, operations, elements, or components but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, or groups thereof. It is to be understood that the terms "if' and "as long as" when used in this specification, can be interpreted either way - that is, either as "if' or "when".

[0039] The communication method provided by the embodiment of the present application will be described in detail below. Referring to Figure 1 , Figure 1A flowchart of a communication method provided by an embodiment of the present application. The method is applied to a first node, which is on a forwarding path of SRv6 and serves as an intermediate node or a tail node for forwarding an SRv6 packet. The communication method provided by the embodiment of the present application can include the following steps.

[0040] Step 110: receiving a first SRv6 packet.

[0041] Specifically, the first node is in an SRv6 network, which further includes other nodes, for example, a second node. The first node and the second node constitute a forwarding path, and the forwarding path is used to forward a service packet (SRv6 packet).

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

[0043] In the forwarding process, the first node receives the first SRv6 packet sent by a previous hop node, which can be specifically a head node or another transmission node. The head node can also be the second node.

[0044] After the second node generates the first SRv6 packet, the second node sends the first SRv6 packet to the first node according to the existing SRv6 protocol and forwarding rules (for example, searching a forwarding table). Alternatively, after any transmission node receives the first SRv6 packet, the transmission node continues to send the first SRv6 packet to the first node according to the existing SRv6 protocol and forwarding rules (for example, searching a forwarding table).

[0045] Step 120: if the first SRv6 packet includes a first signature, decrypting the first signature according to a stored public key to obtain a first controller identifier.

[0046] Specifically, according to the description of step 110, after the first node receives the first SRv6 packet, the first node updates the destination address and the segment remaining (English: Segments Left, abbreviated as: SL) of the first SRv6 packet according to the existing SRv6 protocol and forwarding rules (for example, searching a forwarding table).

[0047] If the first node identifies that the first SRv6 packet includes the first signature, the first node obtains a public key from the local and decrypts the first signature by using the public key to obtain the first controller identifier.

[0048] Optionally, in the embodiment of the present application, the first node further receives a second BGP message sent by the controller before receiving the first SRv6 message, the second BGP message comprising the public key and a second controller 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 can be a BGP UPDATE message.

[0049] In the embodiment of the present application, the controller and each node interact with each other using the xSEC authentication framework to exchange the public key. The public key can also be referred to as an xSEC public key. Further, the xSEC public key can be carried in an extension attribute included in an existing BGP message. The "x" in "xSEC" represents an unknown variable, indicating any place, any layer, and any topology, and "SEC" represents security.

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

[0051] Optionally, the first signature is obtained by the controller by encrypting the identifier of the controller using a private key. The controller carries the first signature in a 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, carries the first signature in a Segment Routing Header (SRH) header included in the SRv6 message header of the service message, and continues to send on the forwarding path. In subsequent embodiments, the process of the controller issuing the configuration file of the SRv6 TE Policy, the second node performing security authentication on the service message, and carrying the first signature in the SRH header included in the SRv6 message header of the service message will be described respectively, and will not be repeated here.

[0052] Step 130, if the first controller identifier is the same as the stored second controller identifier, performing forwarding processing on the first SRv6 message;

[0053] Specifically, according to the description of step 120, the first node obtains the first controller identifier and acquires the second controller identifier from the local. 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 packet passes the security authentication. According to the existing SRv6 protocol and forwarding rules (for example, looking up a forwarding table), the first node continues to perform the forwarding processing on the first SRv6 packet.

[0055] For example, when the first node is a transmission node, the first node continues to forward on the forwarding path after updating the destination address included in the IPv6 header and the SL included in the SRH header. 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 can obtain an original packet after decapsulating the IPv6 header and the SRH header. The first node continues to forward the original packet.

[0057] In step 140, if the first controller identifier is different from the second controller identifier, the first SRv6 packet is discarded.

[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 packet does not pass the security authentication, and at this time, if the first SRv6 packet continues to be forwarded, a security risk will occur. The first node discards the first SRv6 packet.

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

[0060] In this way, by carrying the encrypted signature in the SRv6 packet, each node on the forwarding path performs security authentication on the SRv6 packet. After passing the security authentication, the SRv6 packet continues to be forwarded, otherwise, the SRv6 packet is discarded. The end-to-end security authentication of each node is realized, and the occurrence of events such as traffic hijacking is prevented. The problem that the existing SRv6 TE Policy indication cannot perform security authentication on the service packet by each node on the forwarding path, and the security risk such as traffic hijacking is extremely likely to occur, and the service transmission cannot be guaranteed, is solved.

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

[0062] Specifically, when the first node is the 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 the first signature. According to the configuration file, the first node locally configures the SRv6 TE Policy and generates a table item corresponding to the SRv6 TE Policy. The first BGP message can be a BGP UPDATE message, and further, a BGP SRv6 TE Policy address family message.

[0063] The first signature is obtained by encrypting the identifier of the controller by using a private key corresponding to the public key (also referred to as an xSEC private key) and is stored in a Segment List in the configuration file. The first signature is stored in the SRv6 TE Policy locally configured by the first node. The first signature can be a string format.

[0064] It can be understood that each node in the SRv6 network reports a BGP-LS message to the controller. The BGP-LS message includes network topology information and a SID of the node. The controller collects the network topology and the SID of each node in the network by using a plurality of BGP-LS messages. The network topology information includes link cost, delay, packet loss rate, and the like.

[0065] The controller and the head node establish a BGP neighbor of a BGP IPv6 SR-Policy address family. Meanwhile, according to the network topology, the controller calculates the SRv6 TE Policy based on the link cost, the delay, the packet loss rate, and the like. The controller transmits the SRv6 TE Policy to the head node, that is, the first node, by using a BGP extension protocol. The transmission is implemented by using a newly defined sub-address family identifier (English: Subsequent Address Family Identifier, abbreviated as: SAFI), that is, a BGP SRv6 TE Policy address family.

[0066] In the embodiment of the present application, the first BGP message includes a network layer reachability information (English: Network Layer Reachability Information, abbreviated as: NLRI) field, and the SR-MPLS TE Policy is indicated by the NLRI field. The first BGP message also includes mandatory attributes of the existing BGP protocol and the BGP extension protocol, and can also include any optional attribute.

[0067] The aforementioned NLRI fields include an NLRI Length field, a Distinguisher field, a Policy Color field, and an Endpoint field. The NLRI Length field, occupying 1 byte, represents the length of the NLRI; the Distinguisher field, occupying 4 bytes, represents the identifier of the NLRI; the Policy Color field, occupying 4 bytes, represents the Color attribute of the SR-MPLSTE Policy; and the Endpoint field, occupying 4 or 16 bytes, represents the Endpoint attribute of the SR-MPLSTE Policy.

[0068] The first BGP message also includes an Attributes field and a TunnelEncapsulation Attribute field. The TunnelEncapsulation Attribute field carries the configuration file for the SR-MPLS TE Policy, which is the content of the SRv6 TE Policy. The TunnelEncapsulation Attribute field includes a Tunnel-Type field, which is a TLV structure and includes multiple Sub-TLV structures.

[0069] The SRv6 TE Policy format 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. The Segment List sub-TLV structure includes a Value field, which expands into a Sub-sub-TLV structure to carry the initial signature.

[0073] like Figure 2 As shown, Figure 2 This is a schematic diagram of an extended TLV structure provided in an embodiment of this application. Figure 2 In the TLV structure, the sub-sub-TLV includes a Type field, a Length field, a Flags field, a Reserved field, and an Xsec Signature field.

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

[0075] It can be understood that the SRv6 TE Policy can include multiple candidate paths, and each candidate path can include multiple segment lists. In the foregoing example, a candidate path is taken as an example for description, and the candidate path includes one segment list. In actual application, each segment list included in each candidate path includes a sub-sub-TLV structure, that is, the first signature.

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

[0077] The process of generating the table item corresponding to the SRv6 TE Policy by the first node is the same as the existing generation process, and will not be repeated here.

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

[0079] Specifically, when the first node is the head node, before the first node receives the first BGP message, the first node further receives a second BGP message sent by the controller, and the second BGP message includes the public key and the second controller identifier; the second controller identifier is the identifier of the controller. The second BGP message can be a BGP UPDATE message.

[0080] It can be understood that the first node locally stores the public key and the second controller identifier, wherein the public key and the second controller identifier are used for subsequent security authentication of the first node on the received service message. In subsequent embodiments, the process of security authentication of each node on the received service message will be described, and will not be repeated here.

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

[0082] Specifically, when the first node is the 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. This third BGP message is sent by the first node after obtaining the first signature, and when it needs to periodically report its link status and SID to the controller. Other nodes on the forwarding path, except for the head node, do not send this third BGP message to the controller; instead, they continue to periodically send BGP-LS messages to the controller according to the existing BGP protocol, reporting link status.

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

[0085] Furthermore, the third BGP message includes an NLRI field, which indicates the link-state. The third BGP message also includes mandatory attributes for existing BGP protocols and BGP extension protocols, and may also include any optional attributes.

[0086] In this embodiment of the application, a TLV structure is extended within the NLRI field. For example... Figure 3 As shown, Figure 3 This is a schematic diagram of an extended TLV structure provided in an embodiment of this application. Figure 3 In this context, the extended TLV structure includes a Type field, a Length field, a Flags field, and an Xsec Signature field.

[0087] The data structure includes: Type field (8 bits, value 1601, can be set according to actual needs); Length field (8 bits, representing message length, excluding Type field and Length field); Flag field (8 bits, value all 0, can be set according to actual needs); and Xsec signature field (occupied according to actual needs, used to carry the first signature).

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

[0089] Specifically, when the first node is the head node, the first node receives service messages, which may be sent by user-side network devices.

[0090] After receiving the service message, the first node determines whether to forward the service message through the SRv6 TE Policy according to the existing forwarding rules (e.g., looking up 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 retrieves the stored second controller identifier and identifies whether the first controller identifier is the same as the second controller identifier.

[0092] In an implementation, if the first controller identity is the same as the second controller identity, the first node determines that the service packet passes the security authentication. According to the existing SRv6 protocol, the first node encapsulates an SRH header outside the service packet to obtain a second SRv6 packet, and the SRH header includes the first signature.

[0093] It can be understood that the first node further encapsulates an IPv6 basic header outside the SRH header to obtain the second SRv6 packet.

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

[0095] 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 is not repeated here.

[0096] Further, the SRH header includes an optional TLV object field. In the optional TLV object, a TLV structure is extended. As shown in Figure 4 , Figure 4 Another extension TLV structure diagram provided by an embodiment of the application is shown in Figure 4 . In , the extended TLV structure includes a type field, a length field, a reserved field, and an Xsec signature field.

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

[0098] In another way, if the first controller identity is different from the second controller identity, the first node determines that the service packet does not pass the security authentication, and at this time, the service packet is continued to be forwarded, and a security risk will occur. The first node discards the service packet.

[0099] Figure 5 The communication method provided by an embodiment of the application is described in detail below. Referring to Figure 5 , Another flowchart of a communication method provided by an embodiment of the application is shown in . The method is applied to a controller. The communication method provided by an embodiment of the application can include the steps shown below.

[0100] Step 510, obtaining a stored public key.

[0101] Specifically, the controller and each node interact with each other using the xSEC authentication framework to exchange public keys. The public key can also be referred to as an xSEC public key.

[0102] The controller obtains the stored public key from the local device.

[0103] Step 520: A first BGP packet is sent to each node in the network, and the first BGP packet includes the public key and the identifier of the controller, so that each node, after receiving the packet, performs security authentication on the packet using the public key and the identifier of the controller, and forwards or discards the packet according to the security authentication result.

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

[0105] The controller sends the first BGP packet to each node in the SRv6 network. According to the foregoing embodiment, each node stores the public key and the identifier of the controller locally. Subsequently, each node, after receiving the packet, performs security authentication on the packet using the public key and the identifier of the controller, and forwards or discards the packet according to the security authentication result.

[0106] It can be understood that the first BGP packet is the same as the second BGP packet in the foregoing embodiment, and will not be repeated here. In the foregoing embodiment, the process in which each node performs security authentication on the received packet using the public key and the identifier of the controller, and forwards or discards the packet 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 further included:

[0108] Specifically, the controller obtains a private key (also referred to as an xSEC private key) corresponding to the public key from the local device. After the identifier of the controller is encrypted (the same as the existing xSEC encryption process, and will not be repeated here) using the private key, a first signature is obtained.

[0109] Each node in the SRv6 network reports a BGP-LS packet to the controller. The BGP-LS packet includes network topology information and a SID of the node. The controller collects the network topology and the SID of each node in the network through a plurality of BGP-LS packets. The network topology information includes link cost, delay, packet loss rate, and the like.

[0110] The controller establishes a BGP neighbor of a BGP IPv6 SR-Policy address family between the controller and a first node, i.e., a head node. Meanwhile, according to a network topology, the controller calculates an SRv6 TE Policy based on dimensions such as link cost, delay, and packet loss rate. The controller stores the first signature in a Segment List in a configuration file of the SRv6 TE Policy.

[0111] The controller generates a second BGP message including the configuration file of the SRv6 TE Policy. The controller sends the second BGP message to the first node through a 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, where the first signature is stored in the SRv6 TE Policy locally configured by the first node. The first signature can be a string format.

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

[0113] Optionally, in the embodiments of the present application, the following steps are further included:

[0114] After obtaining the first signature, the first node generates a third BGP message including 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. The third BGP message is sent by the first node after obtaining the first signature, and needs to be periodically sent to the controller to announce a link state and a SID of the first node. The third BGP message is not sent by other nodes on the forwarding path to the controller, and the other nodes still periodically send a BGP-LS message to the controller according to the existing BGP protocol.

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

[0116] It can be understood that the third BGP message is the same as the third BGP message in the foregoing embodiments, 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, the first BGP message including 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.

[0118] Thus, by carrying the encrypted signature in the SRv6 packet, each node on the forwarding path performs security authentication on the SRv6 packet. After security authentication, the SRv6 packet is forwarded, otherwise, the SRv6 packet is discarded. End-to-end security authentication of each node is realized, preventing traffic hijacking and other events. The problem that the existing SRv6 TE Policy indication cannot perform security authentication on the service packet on each node on the forwarding path, which may cause security risks such as traffic hijacking, and cannot guarantee service transmission is solved.

[0119] The communication method provided by the embodiments of the present application will be described in detail below. Referring to Figure 6 , Figure 6 An SRv6 networking schematic diagram is provided for the embodiments of the present application. In Figure 6 , the SRv6 networking includes a controller, a node A, a node B, a node C, a node D, a node E, a node F, a node G, and a node H. The node A is a head node, the node B is a tail node, and the nodes C-H are transmission nodes.

[0120] Each node periodically generates a BGP-LS packet 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 networking through multiple BGP-LS packets 1. The network topology information includes link cost, delay, packet loss rate, etc.

[0121] According to the network topology, the controller calculates an SRv6 TE Policy based on the dimensions of link cost, delay, and packet loss rate. In the embodiments of the present application, the SRv6 TE Policy includes two candidate paths, which are candidate path 1: node A-node C-node E-node G-node B; and 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>; and segment list 2: <D, F, H, B>.

[0122] The controller obtains its own identifier 1 and public key, and generates a BGP packet 1. Using the xSEC authentication framework, the controller sends the BGP packet 1 to each node. After each node receives the BGP packet 1, it obtains the controller identifier 1 and the public key therefrom. Each node stores the controller identifier 1 and the public key locally.

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

[0124] According to the foregoing 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 service message is forwarded through the forwarding path, the service message needs to be securely authenticated. After the security authentication is passed, the service message can be forwarded through the forwarding path; otherwise, the service message is discarded.

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

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

[0128] It can be understood that during the local configuration of the SRv6 TE Policy by node A, the signature under the segment list included in each candidate path can be obtained. When node A determines to forward the service message through a forwarding path, the signature under the segment list included in the candidate path is used to securely authenticate the service message. After the security authentication is passed, the service message 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 to node H still generates and sends the BGP-LS message 2 to the controller according to the existing BGP protocol. Node A carries the obtained signature in the BGP-LS message 2 during the generation of the BGP-LS message 2, and sends it to the controller, so that the controller determines that the service message is securely authenticated when the two forwarding paths are used for service forwarding.

[0130] Node A receives the service message 1 sent by the user side, and determines to forward the service message 1 through the forwarding path 1 in the SRv6 TE Policy according to the existing SRv6 protocol and the forwarding rule (for example, looking up 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] The node A obtains the stored controller identifier 1 again, and identifies whether the controller identifier 1 is same as the controller identifier 2.

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

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

[0134] If the node C identifies that the SRv6 message 1 includes the signature, the node C obtains a public key from the local device, and decrypts the signature by using the public key to obtain the controller identifier 2.

[0135] After obtaining the controller identifier 2, the node C obtains the controller identifier 1 from the local device. The node C identifies whether the controller identifier 1 is same as the controller identifier 2.

[0136] If the controller identifier 1 is 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 perform the forwarding processing on the SRv6 message 1.

[0137] The node C updates the destination address included in the IPv6 header, the SL included in the SRH header, and continues to store the signature in the SRH header to obtain an SRv6 message 2.

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

[0139] Similarly, the node E, the node G, and the node B also perform the process of the node C to perform the security authentication on the SRv6 message and then perform the forwarding.

[0140] It can be understood that, since the node B is the last node, after determining that the SRv6 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 perform the forwarding to the user side, which is not repeated here.

[0141] Based on the same inventive concept, the embodiments of the present application also provide a communication method and a corresponding communication device. Referring to Figure 7 , Figure 7 A communication device provided by the embodiments 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 packet.

[0143] The decryption unit 720 is configured to, if the first SRv6 packet includes a first signature, perform decryption processing on the first signature according to the stored public key, to obtain a first controller identifier.

[0144] The sending unit 730 is configured to, if the first controller identifier is the same as a stored second controller identifier, perform forwarding processing on the first SRv6 packet.

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

[0146] 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, the first BGP packet including a configuration file of an SRv6 TE Policy, and the configuration file including 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 item corresponding to the SRv6 TE Policy.

[0148] The first signature is obtained by the controller performing encryption processing on an identifier of the controller by using a private key corresponding to the public key, and the first signature is stored in a configuration file segment list.

[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 packet sent by the controller, the second BGP packet including 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 packet to the controller, the third BGP packet including the first signature.

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

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

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

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

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

[0158] Therefore, by applying the communication apparatus provided in the present application, the first node receives a first SRv6 message; if the first SRv6 message includes a first signature, the first node decrypts 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, 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 SRv6 message.

[0159] In this way, by carrying the encrypted signature in the SRv6 message, each node on the forwarding path can perform security authentication on the SRv6 message. After security authentication, the SRv6 message is continued to be forwarded, otherwise, the SRv6 message is discarded. This realizes end-to-end security authentication of each node, prevents traffic hijacking and other events, and 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 may cause security risks such as traffic hijacking and cannot guarantee service transmission.

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

[0161] The obtaining unit 810 is configured to obtain a stored public key.

[0162] The sending unit 820 is configured to send a first BGP message to each node in the network, where 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.

[0163] Optionally, the apparatus further comprises:

[0164] The obtaining unit (not shown in the figure) is configured to obtain a private key corresponding to the public key.

[0165] The encryption unit (not shown in the figure) is configured to perform encryption processing on the identifier of the controller by using the private key to obtain a first signature.

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

[0167] The sending unit 820 is further configured to send a second BGP message to the first node, where the second BGP message comprises the configuration file of the SRv6 TE Policy, so that the first node configures the SRv6 TE Policy locally and generates a table item corresponding to the SRv6 TE Policy according to the configuration file, and the first signature is stored in the SRv6 TE Policy configured locally by the first node.

[0168] Optionally, the apparatus further comprises:

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

[0170] Therefore, by applying the communication apparatus 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, where 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.

[0171] In this way, by carrying an encrypted signature in the SRv6 message, each node on the forwarding path performs security authentication on the SRv6 message. Only after successful authentication is the SRv6 message forwarded; otherwise, it is dropped. This achieves end-to-end security authentication for each node, preventing events such as traffic hijacking. It also solves the problem that existing SRv6 TE Policy-indicated forwarding paths cannot perform security authentication on service messages, potentially leading to traffic hijacking and other security vulnerabilities, thus compromising service transmission.

[0172] Based on the same inventive concept, embodiments of this application also provide a network device, such as... Figure 9 As shown, the system 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. The processor 910 is prompted by the machine-executable instructions to execute the communication method provided in the embodiments of this application. (The foregoing...) Figure 7 , Figure 8 The communication device shown can be used as follows: Figure 9 The hardware structure of the network device shown is implemented.

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

[0174] The processor 910 mentioned above can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can 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 gate or transistor logic devices, or discrete hardware components.

[0175] In the embodiments of the present application, the processor 910 is enabled to implement the communication method described in the foregoing embodiments of the present application by reading the machine-executable instructions stored in the machine-readable storage medium 930 and by the machine-executable instructions prompting the processor 910 itself and the transceiver 920 to execute the communication method.

[0176] In addition, the embodiments of the present application provide a machine-readable storage medium 930, which stores machine-executable instructions. When the machine-executable instructions are invoked and executed by the processor 910, the machine-executable instructions prompt the processor 910 itself and the transceiver 920 to execute the communication method described in the foregoing embodiments of the present application.

[0177] The implementation processes of the functions and roles of the units in the above apparatus are specifically described in the implementation processes of the corresponding steps in the above method, and will not be described here.

[0178] For the apparatus embodiments, since they basically correspond to the method embodiments, the related parts can be referred to the parts of the method embodiments. The apparatus embodiments described above are merely illustrative, and the units described as separate components can or can not be physically separated, and the components displayed as units can or can not be physical units, that is, they can be located in one place or distributed on multiple network units. According to actual needs, some or all of the modules can be selected to achieve the purposes of the present application. Those skilled in the art can understand and implement without creative labor.

[0179] For the communication apparatus and the machine-readable storage medium embodiments, since the method contents involved are basically similar to the foregoing method embodiments, the description is relatively simple, and the related parts can be referred to the parts of the method embodiments.

[0180] The above only describes the preferred embodiments of the present application and does not limit the present application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle 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 the first node, and the method includes: Receive the first SRv6 message; If the first SRv6 message includes the first signature, then the first signature is decrypted 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, then the first SRv6 message is forwarded. If the first controller identifier is different from the second controller identifier, then the first SRv6 message is discarded; The method further includes: When the first node is the head node, it receives the first BGP message sent by the controller. The first BGP message includes the configuration file of the SRv6 TE Policy, and the configuration file includes the first signature. According to the configuration file, configure the SRv6 TE Policy locally and generate table entries corresponding to the SRv6 TE Policy; The first signature is obtained by the controller encrypting the controller's identifier using the private key corresponding to the public key, and the first signature is stored in the segment list of the configuration file. The first signature is stored in the SRv6 TE Policy configured locally on the first node.

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

3. The method according to claim 1, characterized in that, The method further includes: When the first node is the head node, a third BGP message is sent to the controller, the third BGP message including the first signature.

4. The method according to claim 1, characterized in that, The method further includes: When the first node is the head node, it receives service messages; When it is determined that the service message is forwarded through the SRv6 TE Policy, the first signature is decrypted according to the public key to obtain the first controller identifier; If the first controller identifier is the same as the second controller identifier, then an SRH header is encapsulated in the outer layer of the service message to obtain a second SRv6 message, wherein the SRH header includes the first signature; Send the second SRv6 message to the third node; The third node is either a transmission node or a tail node.

5. A communication method, characterized in that, The method is applied to a controller, and the method includes: Retrieve the stored public key; A first BGP message is sent to each node in the network. The first BGP message includes the public key and the identifier of the controller, so that each node, after receiving the message, 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. The method further includes: Obtain the private key corresponding to the public key; Using the private key, the identifier of the controller is encrypted to obtain the first signature; Generate a configuration file for the SRv6 TE Policy, wherein the first signature is stored in the segment list of the configuration file for the SRv6 TE Policy; A second BGP message is sent to the first node. The second BGP message includes a configuration file of the SRv6 TE Policy, so that the first node configures the SRv6 TE Policy locally according to the configuration file and generates an entry corresponding to the SRv6 TE Policy. The first signature is stored in the SRv6 TE Policy configured locally by the first node.

6. The method according to claim 5, characterized in that, The method further includes: Receive a third BGP message sent by the first node, the third BGP message including the first signature.

7. A communication device, characterized in that, The device is applied to the first node, and the device includes: The receiving unit is used to receive the first SRv6 message; The decryption unit is configured to, if the first SRv6 message includes a first signature, decrypt the first signature using a stored public key to obtain a first controller identifier. The sending unit is configured to forward the first SRv6 message if the first controller identifier is the same as the stored second controller identifier. A discarding unit is used to discard the first SRv6 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, the first BGP message including a configuration file of the SRv6 TE Policy, the configuration file including the first signature; The device further includes: a configuration unit, configured to configure the SRv6 TE Policy locally according to the configuration file and generate entries corresponding to the SRv6 TE Policy; The first signature is obtained by the controller encrypting the controller's identifier using the private key corresponding to the public key, and the first signature is stored in the segment list of the configuration file. The first signature is stored in the SRv6 TE Policy configured locally on the first node.

8. A communication device, characterized in that, The device is used in a controller, and the device includes: The retrieval unit is used to retrieve the stored public key; The sending unit is used to send a first BGP message to each node in the network. The first BGP message includes the public key and the identifier of the controller, so that each node, after receiving the message, 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. The device further includes: The acquisition unit is used to acquire the private key corresponding to the public key; An encryption unit is used to encrypt the identifier of the controller using the private key to obtain a first signature; A generation unit is used to generate a configuration file for an SRv6 TE Policy, wherein the first signature is stored in a segment list within the configuration file of the SRv6 TE Policy. The sending unit is further configured to send a second BGP message to the first node, the second BGP message including a configuration file of SRv6 TEPolicy, so that the first node configures the SRv6 TEPolicy locally according to the configuration file and generates an entry corresponding to the SRv6 TEPolicy, wherein the first signature is stored in the SRv6 TEPolicy configured locally by the first node.

Images