A Boundary Filtering Method and Device for SRv6 Trust Domain

Abstract

Embodiments of this application disclose a method and device for boundary filtering of the SRv6 trust domain. The method includes: after an edge node of the trust domain receives an SRv6 packet with the destination address being the BSID, it can verify the packet according to the BSID in the packet and the target field in the SRH of the packet. When the packet passes the verification, the packet is forwarded; when the packet fails to pass the verification, the packet is discarded. In the embodiments of this application, not only is it required that nodes outside the trust domain access the trust domain using the BSID, but also, the packets entering the trust domain are verified in combination with the target field in the segment routing header. Using the solution of the embodiments of this application can effectively reduce the occupancy of network resources by attack packets compared with only using the BSID for SRv6 boundary filtering of packets. Therefore, the security risks brought by packet forwarding using the SRv6 technology can be reduced.

Description

[0001] This application claims the priority of the Chinese patent application filed with the China Patent Office on April 2, 2020, with application number 202010256371.1 and invention name “A boundary filtering method and device based on SRv6 trust domain”, the entire contents of which are incorporated by reference in this application. Technical Field

[0002] The present application relates to the field of communications, and in particular to a message forwarding method and device. Background Art

[0003] Segment Routing Internet Protocol Version 6 (SRv6) technology can apply segment routing (SR) technology to the forwarding of Internet Protocol Version 6 (IPv6) messages.

[0004] At present, there are certain security risks when using SRv6 technology to forward messages. Summary of the invention

[0005] The embodiment of the present application provides a message forwarding method, which can greatly reduce the occupation of SRv6 trust domain network resources by attack messages.

[0006] In the first aspect, an embodiment of the present application provides a message forwarding method, which can be executed by an edge node of an SRv6 trust domain. When the edge node of the trust domain receives an SRv6 message from outside the trust domain, the SRv6 message can be verified, and the first message can be forwarded if the first message passes the verification. The method includes: the edge node of the trust domain receives a first message, the first message is an SRv6 message, and the destination address of the first message is a binding segment identifier (bindingsegment ID, BSID). After the edge node of the trust domain receives the first message, the first message can be verified according to the BSID in the first message and the target field in the segment routing header (segment routing header, SRH) of the first message, and the first message is discarded if the first message fails to pass the verification. In an embodiment of the present application, not only is it required that nodes outside the trust domain access the trust domain using the BSID, but also the first message must be verified in combination with the target field in the segment routing header. By utilizing the solution of the embodiment of the present application, compared with the edge source node of the trust domain only using BSID to perform boundary filtering on the first message, it is possible to effectively identify attack messages, and by promptly discarding a large number of attack messages that have not passed verification, the occupation of trust domain network resources by attack messages is effectively reduced, and the security risks caused by message forwarding using SRv6 technology are effectively reduced.

[0007] The SRv6 trust domain described in this application may also be referred to as an SRv6 security domain.

[0008] In one implementation, the edge node may verify the first message according to the BSID and the target field in the SRH of the first message based on the instruction of the control management device. Specifically, the edge node may receive a security protection policy from the control management device, and the security protection policy is used to instruct the edge node to verify the first message according to the BSID and the target field in the SRH.

[0009] In one implementation, considering that when an SRv6 message needs to be forwarded across a trust domain, the trust domain can provide a BSID to indicate the forwarding path of the SRv6 message within the trust domain. Therefore, the next hop SID of the BSID is theoretically used to indicate an out-of-domain node that the trust domain directly interacts with. Therefore, the target field may include the next hop SID of the BSID. The edge node can use the next hop SID of the BSID to determine whether the first message is forwarded to a legitimate destination node, or the edge node can use the BSID to determine whether the first message will cause an attack on the trust domain.

[0010] In one implementation, it is considered that the first SID list composed of the BSID and the N SIDs in the SID list can be used to indicate the forwarding path of the first message from the edge node to the destination node, or the first SID list is used to indicate the forwarding path of the first message from the edge node to the first node, wherein the first node is a node between the edge node and the destination node. Therefore, the target field can include the N SIDs in the SID list. In this way, the edge node can verify the first SID list to ensure that the path indicated by the first SID list is a legal path before forwarding the first message, thereby ensuring that the nodes included in the path indicated by the SID list are not attacked by the network.

[0011] In one implementation, when a node outside the trust domain needs to forward an SRv6 message to the trust domain, the trust domain can provide a BSID to indicate the forwarding path of the SRv6 message in the trust domain. In this case, the next hop SID of the BSID should not exist in the SRH of the SRv6 message, or in other words, the BSID is the last SID indicating the forwarding path of the SRv6 message. In this case, the value of the SL field of the SRv6 message is 0. Therefore, the target field may include a segment remaining SL field to ensure that the SRv6 message forwarded to the trust domain can be forwarded to the trust domain normally.

[0012] In one implementation, when the target field includes the next hop SID of the BSID, the edge node verifies the first message according to the BSID in the first message and the target field in the segment routing header SRH. In a specific implementation, the edge node can determine that the BSID is a BSID in the trust domain; and determine whether the target field is in a legal network segment, wherein the legal network segment is the network segment where the legal destination node of the first message is located. If the next hop SID of the BSID is in a legal network segment, it means that the node indicated by the next hop SID of the BSID is the legal destination node of the first message. That is, the first message is forwarded to the legal destination node of the first message after being forwarded by the path indicated by the BSID. For this case, it can be considered that the first message passes the verification. Correspondingly, if the next hop SID of the BSID is not in a legal network segment, it means that the first message is not forwarded to the legal destination node of the first message after being forwarded by the path indicated by the BSID, but is forwarded to other nodes. For this case, the next hop SID of the BSID is likely to have been tampered with. Therefore, the first message is likely to cause an attack to other nodes. Therefore, if the next hop SID of the BSID is not in the legal network segment, the first message fails to pass the verification.

[0013] In one implementation, considering that when an SRv6 message is forwarded, the SID indicating the destination node of the message may be a node SID or the SID of a VPN instance deployed on the node, referred to as VPN SID. The SID list of the SRH may include both the SID of the destination node and the VPN SID deployed on the destination node. For a node, whether it is the node SID or the VPN SID of the node, it is within the network segment indicated by the locator route of the node. Among them, the locator route of the node refers to the network segment route to which the node SID of the node belongs. Therefore, the aforementioned legal network segment may be the network segment indicated by the locator route of the legal destination node. In this way, regardless of whether the next-hop SID of the BSID is a node SID or a VPNSID, the legal network segment can be used to determine whether the first message has been tampered with.

[0014] In one implementation, the aforementioned legal network segment may be carried in a security protection policy by the control management device and sent to the edge node.

[0015] In one implementation, the aforementioned legal network segment is statically configured on the edge node.

[0016] In one implementation, when the target field includes the next hop SID of the BSID, in order to prevent the first message from attacking the trust domain, the edge node can, for example, determine whether the BSID is a BSID in the trust domain. Then, the edge node determines whether the next hop SID of the BSID is in the first network segment, and the first network segment refers to the network segment to which the node in the trust domain belongs. If the next hop SID of the BSID is in the first network segment, it means that the node indicated by the next hop SID of the BSID is a node in the trust domain. That is, after the first message is forwarded by the path indicated by the BSID, it does not leave the trust domain, but continues to be forwarded in the trust domain. For this case, the next hop SID of the BSID is likely to have been tampered with. Therefore, the first message is likely to cause a network attack on the node in the trust domain. Therefore, if the next hop SID of the BSID is in the first network segment, the first message fails to pass the verification. Correspondingly, if the next hop SID of the BSID is not in the first network segment, it means that after the first message is forwarded by the path indicated by the BSID, it leaves the trust domain and is forwarded to other nodes outside the trust domain. In this case, it can be considered that the first message has passed the verification.

[0017] In one implementation, the aforementioned first network segment may be carried in a security protection policy by the control management device and sent to the edge node.

[0018] In one implementation, the first network segment is statically configured on the edge node.

[0019] In one implementation, when the target field includes the next hop SID of the BSID, a SID list may be pre-stored in the edge node, and the SID list stored in the edge node is used to indicate a legal path. Specifically, one or more SID lists may be pre-stored in the edge node, and one SID list indicates a legal path. The edge node may compare the aforementioned first SID list with the locally stored SID list. If the locally stored SID list includes the aforementioned first SID list, it means that the path indicated by the aforementioned first SID list is a legal path, so the edge node can determine that the first message has passed the verification. On the contrary, if the locally stored SID list does not include the aforementioned first SID list, it is determined that the first message has not passed the verification.

[0020] In one implementation, the SID list stored in the edge node may be sent to the edge node by the control management device through a security protection policy.

[0021] In one implementation, the SID list stored in the edge node may be statically configured on the edge node.

[0022] In one implementation, when the target field includes the next-hop SID of the BSID, several hash values ​​may be pre-stored in the edge node. The hash value stored in the edge node is obtained by performing a hash operation on the SID list corresponding to the legal path. In this case, the edge node may perform a hash operation on the first SID list to obtain a first hash value. After the edge node obtains the first hash value, it may search for several hash values ​​stored locally to determine whether the locally stored hash values ​​include the calculated first hash value. If the locally stored hash values ​​include the first hash value, it indicates that the path indicated by the first SID list is a legal path, and therefore, it may be determined that the first message has passed the verification. Conversely, if the locally stored hash values ​​do not include the first hash value, it is determined that the first message has not passed the verification.

[0023] In one implementation, the first message may include a first field, and the first field may be used to indicate the number of SIDs to be verified. After receiving the first message, the edge node may parse the first message to obtain the value of the first field, thereby further obtaining the N SIDs in the aforementioned BSID and SRH, and verify the first message according to the N SIDs in the BSID and SRH.

[0024] In one implementation, when the target field includes the SL field, the edge node verifies the first message according to the BSID in the first message and the target field in the segment routing header SRH. In a specific implementation, the edge node can determine that the BSID is the BSID in the trust domain, and determine whether the value of the target field is 0. When the value of the target field is 0, it indicates that the first message is a legitimate message forwarded from outside the trust domain to within the trust domain, so it can be determined that the first message has passed the verification. When the value of the target field is not 0, it can be determined that the first message has not passed the verification.

[0025] In one implementation, the edge node may also receive a second message, which is similar to the first message, and is also an SRv6 message, and the destination address of the second message is the BSID. After receiving the second message, the edge node may verify the second message. Similar to the way the edge node verifies the first message, the edge node may verify the second message based on the BSID in the second message and the target field in the SRH of the second message, and forward the second message if the second message is verified. Since not only the BSID but also the target field is verified when verifying the second message, the second message that passes the verification can be considered a legitimate message, so forwarding the second message across the trust domain will not bring security risks. By using the solution provided in the embodiment of the present application, the security risks brought by message forwarding using SRv6 technology can be reduced.

[0026] In the second aspect, an embodiment of the present application provides a message forwarding method, the method comprising: an edge node of a trust domain receives a first message, the first message is an SRv6 message, and the destination address of the first message is a binding segment identifier BSID; the edge node verifies the first message according to the BSID in the first message and the target field in the segment routing header SRH of the first message; the edge node forwards the first message that passes the verification. In an embodiment of the present application, not only are nodes outside the trust domain required to access the trust domain using the BSID, but the first message is also required to be verified in combination with the target field in the segment routing header. Compared with verifying the first message using only the BSID, more factors are combined when verifying the first message, that is, the verification standard for allowing SRv6 messages to be forwarded across trust domains is stricter. This reduces the security risks brought about by message forwarding using SRv6 technology.

[0027] In the third aspect, an embodiment of the present application provides a forwarding control method, the method comprising: a control management device obtains a security protection policy, the security protection policy is used to instruct the edge node of the trust domain to verify the received SRv6 message according to the BSID and the target field in the SRH; the control management device sends the security protection policy to the edge node of the trust domain. In an embodiment of the present application, the control management device instructs the edge node of the trust domain to verify the received SRv6 message based on the BSID and the target field in the SRH by issuing a security protection policy. Compared with verifying the first message only by using the BSID, more factors are combined when verifying the first message, that is, the verification standard for allowing the SRv6 message to be forwarded across the trust domain is more stringent, so the security risks caused by forwarding messages using SRv6 technology can be reduced.

[0028] In one implementation, the control management device may send the security protection policy to the edge node of the trust domain via a path computation unit communication protocol PCEP message, for example, by extending a new object object in the PCEP message or extending a new TLV field in an existing object to carry the security protection policy.

[0029] In one implementation, the control management device may send the security protection policy to the edge node of the trust domain via a Border Gateway Protocol (BGP) message. For example, an extended attribute may be added to the BGP message or a new TLV field may be extended to an existing attribute to carry the security protection policy. The existing attribute may be, for example, a Border Gateway Protocol Flow Specification (BGP FS) attribute.

[0030] In one implementation, the control management device may send the security protection policy to the edge node of the trust domain via a network configuration protocol NETCONF message.

[0031] In one implementation, the control management device may send the security protection policy to the edge node of the trust domain via a Simple Network Management Protocol (SNMP) message.

[0032] In one implementation, the target field includes the next-hop SID of the BSID; or, the target field includes N SIDs in a segment identification SID list, the first SID of the N SIDs is the next-hop SID of the BSID, and N is greater than or equal to 1; or, the target field includes a segment remaining SL field.

[0033] In one implementation, when the N is greater than 1, the N SIDs are consecutive N SIDs in the SID list.

[0034] In one implementation, if the target field includes the next hop SID of the BSID, the security protection policy carries a legal BSID and a legal network segment within the trust domain.

[0035] In one implementation, the legal BSID and legal network segment in the trust domain may be carried in the extended attributes of BGP FS. For example, the legal BSID in the trust domain is carried in the extended attribute type17 of BGP FS, and the legal network segment is carried in the extended attribute type18 of BGP FS.

[0036] In one implementation, if the target field includes the next hop SID of the BSID, the security protection policy carries the legal BSID and the first network segment in the trust domain.

[0037] In one implementation, the legal BSID and the first network segment in the trust domain may be carried in the extended attributes of BGP FS. For example, the legal BSID in the trust domain is carried in the extended attribute type17 of BGP FS, and the first network segment is carried in the extended attribute type18 of BGP FS.

[0038] In one implementation, if the target field includes N SIDs in a segment identifier SID list, the security protection policy carries a SID list indicating a legitimate path, and the SID list includes a legitimate BSID in the trust domain.

[0039] In one implementation, the SID list indicating the legal path may be carried in an extended attribute of the BGP FS message. For example, the SID list indicating the legal path may be carried in an extended attribute type19 of the BGP FS message.

[0040] In a fourth aspect, an embodiment of the present application provides an edge node, comprising: a communication interface; and a processor connected to the communication interface; according to the communication interface and the processor, the edge node is used to execute the method described in any one of the first aspect, or execute the method described in any one of the second aspect.

[0041] In the fifth aspect, an embodiment of the present application provides a control management device, comprising: a communication interface; and a processor connected to the communication interface; according to the communication interface and the processor, the control management device is used to execute the method described in any one of the aforementioned third aspects.

[0042] In a sixth aspect, an embodiment of the present application provides an edge node, comprising a memory and a processor; the memory is used to store program code; the processor is used to run instructions in the program code, so that the edge node executes the method described in any one of the first aspect above, or the edge node executes the method described in any one of the second aspect above.

[0043] In the seventh aspect, an embodiment of the present application provides a control management device, which includes a memory and a processor; the memory is used to store program code; the processor is used to run instructions in the program code, so that the control management device executes any one of the methods described in the third aspect above.

[0044] In an eighth aspect, an embodiment of the present application provides a computer-readable storage medium, wherein instructions are stored in the computer-readable storage medium, which, when executed on a computer, enables the computer to execute the method described in any one of the first aspect above, or enables the computer to execute the method described in any one of the second aspect above, or enables the computer to execute the method described in any one of the third aspect above.

[0045] In a ninth aspect, an embodiment of the present application provides a communication system, which includes an edge node and a control management device, wherein the control management device is used to execute the method described in any one of the third aspects above.

[0046] In the tenth aspect, an embodiment of the present application provides a communication system, which includes an edge node and a control management device, wherein the edge node is used to execute the method described in any one of the first aspect above, or the edge node is used to execute the method described in any one of the second aspect above. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0048] Figure 1 A schematic diagram of the structure of an SRv6 message provided in an embodiment of the present application;

[0049] Figure 2 A schematic diagram of a message forwarding method provided in an embodiment of the present application;

[0050] Figure 3a A schematic diagram of a network structure provided for an embodiment of the present application;

[0051] Figure 3b Another schematic diagram of a network structure provided for an embodiment of the present application;

[0052] Figure 3c A network structure diagram is provided for the embodiment of the present application;

[0053] Figure 4 A schematic diagram of the structure of another SRv6 message provided in an embodiment of the present application;

[0054] Figure 5 A flowchart of a message forwarding method provided in an embodiment of the present application;

[0055] Figure 6 A flowchart of a message forwarding method provided in an embodiment of the present application;

[0056] Figure 7 A flowchart of a message forwarding method provided in an embodiment of the present application;

[0057] Figure 8 A flowchart of a forwarding control method provided in an embodiment of the present application;

[0058] Fig. 9 A schematic diagram of the structure of an edge node provided in an embodiment of the present application;

[0059] Fig.10 A schematic diagram of the structure of a control management device provided in an embodiment of the present application;

[0060] Fig.11 A schematic diagram of the structure of an edge node provided in an embodiment of the present application;

[0061] Fig.12 A schematic diagram of the structure of a control management device provided in an embodiment of the present application;

[0062] Fig.13 A schematic diagram of the structure of an edge node provided in an embodiment of the present application;

[0063] Fig.14 A schematic diagram of the structure of a control management device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0064] The embodiment of the present application provides a message forwarding method, which can reduce the security risks when using SRv6 technology to forward messages.

[0065] To facilitate understanding, we first briefly introduce the use of SRv6 technology for message forwarding.

[0066] When forwarding messages using SRv6 technology, the head node specifies the message forwarding path, and the intermediate nodes guide the message forwarding according to the forwarding path indicated by the head node until the message is forwarded to the destination node. Among them: the message forwarded using SRv6 technology can also be called SRv6 message. For details, please refer to Figure 1 To understand, Figure 1 A schematic diagram of the structure of an SRv6 message provided in an embodiment of the present application. Figure 1 As shown, the SRv6 message includes an IPv6 header 101, a segment routing header 102 and a payload 103. Among them, the segment routing header 102 includes a segment identifier list (SID list) indicating the message forwarding path. In one implementation, the SID list can be composed of several node SIDs, for example, composed of several IPv6 addresses, and the node SID is used to indicate the nodes passed during the message forwarding process. In another implementation, the SID list can be composed of several adjacent link SIDs, and the adjacent link SID is used to indicate the adjacent link through which the message is forwarded. The so-called adjacent link refers to a link directly connected between two nodes. In another implementation, the SID list can also be composed of a node SID and an adjacent link SID.

[0067] The IPv6 header 101 includes a destination address (DA) field ( Figure 1 The value of the DA field may change during the SRv6 message forwarding process. SRH 102 includes a segment left (SL) field ( Figure 1(not shown). The SL field is used to indicate the number of SIDs that have not been processed in the SID list. SL is numbered from 0. When the value of SL is equal to m, it means that the number of SIDs that have not been processed in the SID list is (m+1), and the currently being processed is segment list[m]. The so-called processing of the SID in the SID list refers to forwarding the message to the node indicated by the SID. When the value of SL is equal to m, when the destination address in the IPv6 header 101 is segment list[m]. When the head node and the intermediate node forward the SRv6 message, they can determine the next-hop destination node for message forwarding based on the value of the SL field and the SID list. Specifically: after the intermediate node receives the SRv6 message, if the destination address in the SRv6 message is the address of the intermediate node itself, the intermediate node can subtract 1 from the value of the SL field, and determine the next-hop destination node of the forwarded message based on the value of the SL field obtained by performing the subtraction operation as an index, and after determining the next-hop destination node of the forwarded message, modify the value of the destination address field to the IPv6 address of the determined next-hop destination node.

[0068] The following combination Figure 2 This section describes how the head node and each intermediate node forward packets when using SRv6 technology to forward packets. Figure 2 A schematic diagram of a message forwarding method provided in an embodiment of the present application. Figure 2As shown, the head node 201 determines that the message is forwarded to the destination node 204 through the nodes 202 and 203 in sequence. The SRH of the SRv6 message obtained by the head node 201 carries a SID list, and the SID list includes three IPv6 addresses, namely address 2 carried by segment list[2], address 3 carried by segment list[1], and address 4 carried by segment list[0], where: address 2 is the address of node 202, address 3 is the address of node 203, and address 4 is the address of node 204. After the head node 201 obtains the SRv6 message, it modifies the destination address of the SRv6 message to address 2, and modifies the value of the SL field to 2. Then, node 201 forwards the modified SRv6 message to node 202. The SRv6 message received by node 202 includes the aforementioned SID list, and the value of the SL field is equal to 2. After receiving the SRv6 message, node 202 determines that the destination address is its own address, so node 202 subtracts 1 from the value of SL to obtain 1, and uses 1 as the index to determine that the next hop destination node for message forwarding is node 203 indicated by address 3 carried by segment list[1]. Node 202 modifies the destination address of the SRv6 message to address 3. Then, node 202 forwards the SRv6 message to node 203. By analogy, the SRv6 message received by node 203 includes the aforementioned SID list, and the value of the SL field is equal to 1. After receiving the SRv6 message, node 203 determines that the destination address is its own address, so node 203 subtracts 1 from the value of SL to obtain 0, and uses 0 as the index to determine that the next hop destination node for message forwarding is node 204 indicated by address 3 carried by segment list[0]. Node 203 modifies the destination address of the SRv6 message to address 4, and forwards the SRv6 message to node 204, thereby completing message forwarding.

[0069] The aforementioned nodes 201, 202, 203 and 204 are all nodes supporting SRv6 technology. Figure 2 Although not shown in the figure, node 201 may also pass through several other nodes in the process of forwarding the SRv6 message to node 202. Figure 2 The example of carrying the node SID in SRH 102 is used for description, however, SRH 102 carries the adjacent link SID, or SRH 102 carries the node SID and the adjacent link SID. The specific message forwarding method is the same as the forwarding method of carrying the node SID in SRH 102, which is not repeated here.

[0070] In some embodiments, considering that the length of the Ethernet message needs to be within a reasonable range, if the amount of data occupied by the SID list is relatively large, it will affect the amount of data in the payload 103. The smaller the amount of data in the payload 103, the more it will affect the network performance of the entire network. Therefore, the SID list in the SRv6 message obtained by the aforementioned node 201 may not include address 2, thereby reducing the amount of data occupied by the SID list. In this scenario, the value of the SL field in the SRv6 message obtained by node 201 is still 2. When forwarding an SRv6 message, if the aforementioned SID list does not include address 2, this mode of forwarding the SRv6 message can also be referred to as a reduce mode. Correspondingly, if the aforementioned SID list includes address 2, this mode of forwarding the SRv6 message can also be referred to as a normal mode.

[0071] From the above description, it can be seen that when using SRv6 technology to forward messages, the intermediate node forwards messages based on the SID list, and does not verify the SID list. Therefore, network hackers can maliciously tamper with the SID list to launch network attacks and affect network security.

[0072] At present, the aforementioned network attacks can be prevented by defining an SRv6 trust domain. Among them, the trust domain is used to indicate the network range to prevent the aforementioned network attacks. The trust domain can be determined based on a variety of methods, for example, it can be determined based on the network scenario, such as specifying the core network part in the network as the trust domain; or, it can be determined based on the service type, such as determining the network range for transmitting a specific service message as the trust domain, and so on. Specifically, to ensure that the trust domain is not attacked, an access control list (ACL) traffic filtering policy can be configured on the edge node or intermediate node of the trust domain. For example, the edge node of the trust domain verifies the received SRv6 message, and if the destination address of the SRv6 message is the address of a node in the trust domain, the SRv6 message is discarded. For another example, the intermediate node of the trust domain verifies the received SRv6 message, and if the source address of the SRv6 message is the address of a node outside the trust domain, the SRv6 message is discarded. In the above manner, the transmission of SRv6 messages outside the trust domain to the trust domain can be avoided. Only SRv6 messages generated within the trust domain are forwarded to avoid attacks on the trust domain. The edge node of the trust domain refers to a node that directly communicates with nodes outside the trust domain, and the intermediate node of the trust domain refers to other nodes except the edge node.

[0073] In some embodiments, SRv6 messages need to be forwarded across trust domains. For example, SRv6 messages outside the trust domain need to be forwarded to the trust domain, or SRv6 messages generated in a first domain need to be forwarded to a second domain via the trust domain, and the first domain and the second domain are different from the trust domain. In this case, how to ensure network security is an issue that needs to be urgently addressed.

[0074] The inventor of the present application has found that in order to ensure the security of the trust domain and prevent the network topology of the trust domain from being leaked, thereby reducing the possibility of the trust domain being attacked, when the SRv6 message needs to be forwarded across the trust domain, the SRv6 message can access the trust domain through the BSID. Among them, the BSID can be used to identify a forwarding path.

[0075] Specifically, in one example, a BSID that identifies a forwarding path within a trust domain may be generated by a control and management device. Accordingly, when calculating the forwarding path of an SRv6 message, the control and management device may obtain a SIDlist including the BSID. In addition, after the control and management device generates the BSID, the correspondence between the BSID and the forwarding path indicated by the BSID may be sent to the edge node of the trust domain, so that the edge node of the trust domain can verify the SRv6 message, and forward the message within the trust domain if the SRv6 message passes the verification. In another example, a BSID may be generated by an edge node of the trust domain, and the correspondence between the BSID and the forwarding path indicated by the BSID may be sent to the control and management device, so that when calculating the forwarding path of an SRv6 message, the control and management device may obtain a SIDlist including the BSID. The control and management device mentioned in the embodiments of the present application may be, for example, a device running network management software, or may be a controller, which is not specifically limited in the embodiments of the present application.

[0076] Regarding the correspondence between the BSID and the forwarding path indicated by the BSID, an example is given below: BSID 1 indicates forwarding path 1 in the trust domain, and the correspondence can be, for example, the correspondence between BSID 1 and the SID list indicating forwarding path 1. This can be understood in conjunction with the following Table 1:

[0077] Table 1

[0078]

[0079] As shown in Table 1, the forwarding path indicated by BSID 1 is a path that sequentially passes through node 1, node 2, and node 3. Table 1 is only shown for ease of understanding and does not constitute a limitation on the embodiments of the present application.

[0080] Next, combine Figure 3a, a specific implementation method of verifying the SRv6 message based on the BSID of the edge node of the trust domain, and forwarding the verified SRv6 message by the edge node of the trust domain within the trust domain.

[0081] Figure 3a A schematic diagram of a network structure provided in an embodiment of the present application. Figure 3a As shown, node R1 is a node in the first domain 100, node R2 and node R4 are edge nodes of the trust domain 200, node R5 is a node in the second domain 300, node R2 can communicate directly with node R1, and node R4 can communicate directly with node R5. Node R6, node R7, and node R8 are all nodes in the trust domain 200. In some embodiments, the first domain 100 and the second domain 300 can also be defined as trust domains.

[0082] In the embodiment of the present application, the trust domain 200 may belong to an access network, a bearer network, a core network, an operator network or a campus network, which is not specifically limited in the embodiment of the present application. In one example, the aforementioned trust domain 200 may belong to an operator network, and the node R2 is deployed in the customer's room as a cell site gateway (CSG) device, the first domain 100 belongs to an enterprise network, and the node R1 is a customer premise equipment (CPE) device.

[0083] exist Figure 3a In the scenario shown, the head node R1 obtains an SRv6 message including a BSID. When the node R1 forwards the SRv6 message, it modifies the destination address of the SRv6 message to the BSID, and forwards the modified message to the node R2 in the trust domain 200. After receiving the SRv6 message, the node R2 verifies the SRv6 message by the destination address of the SRv6 message. If the destination address is a legal BSID in the trust domain 200, it is determined that the SRv6 message has passed the verification. Specifically, assuming that the destination address in the SRv6 message is address A, the node R2 can, for example, check whether the locally stored BSID list includes address A. If so, it indicates that address A is a legal BSID in the trust domain. At this time, the node R2 forwards the SRv6 message in the trust domain. Among them, the BSID list stored locally by the node R2 includes legal BSIDs in the trust domain.

[0084] When forwarding the SRv6 message, node R2 may re-encapsulate the SRv6 message, convert the aforementioned BSID into the aforementioned SID list indicating the forwarding path, and encapsulate the SID list into the SID list of the SRH of the SRv6 message, thereby forwarding the SRv6 message within the trust domain.

[0085] In an embodiment of the present application, node R2 may re-encapsulate the SRv6 message in a variety of ways. The specific encapsulation method depends on the forwarding method of the SRv6 message. Two possible implementation methods of node R2 re-encapsulating the SRv6 message are described below.

[0086] In one implementation, if the SRv6 message is forwarded based on a tunnel, when node R2 re-encapsulates the SRv6 message, a new IPv6 header and a new SRH can be added on the basis of the original IPv6 header and SRH. The update of the destination address field in the original IPv6 header and SRH and the update of the SL field are the same as the traditional technology. The source address in the newly added IPv6 header is the address of node R2, and the destination address is the next hop SID in the SID list corresponding to the BSID.

[0087] Can be combined Figure 3b To understand, Figure 3b Another network structure diagram provided in the embodiment of the present application. Figure 3b As shown, the SRv6 message obtained by node R1, the source address carried in the IPv6 header 301 is the address of node R1, and the destination address is the address of node R2. The SID list field in SRH 302 includes (R5, R2, ...), where R2 is the BSID in the trust domain, and the path indicated by the BSID is the forwarding path that passes through nodes R2, R3 and R4 in sequence. The ellipsis in the SID list field is valid when the SRv6 message is received by node R1 from other nodes, and is used to indicate the forwarding path of the SRv6 message before node R1. R5 in the SID list field is the SID of node R5. When node R1 obtains the SRv6 message, the value of the SL field is equal to 2. After node R1 modifies the value of the SL field to 1, it sends the SRv6 message to node R2. After receiving the SRv6 message, node R2 searches for the SID list corresponding to the BSID locally, and the SID list obtained is (R3, R4), where R3 in the SID list is the SID of node R3, and R4 in the SID list is the SID of node R4. Node R2 encapsulates the SID list obtained by searching into the newly added SRH 303, as shown in FIG. Figure 3bAs shown, the value of the SL field in SRH 303 is equal to 1. Node R2 determines that the destination address is R3 based on the value of the SL. Therefore, node R2 modifies the destination address in the newly added IPv6 header 304 to R3, and modifies the source address in the message header 304 to R2. In the original IPv6 header 301, the source address is R1 and the destination address is R5. The value of the SL field in the original SRH 302 is 0. When the SRv6 message is forwarded within the trust domain 200, the contents of the source address and destination address fields in the IPv6 header 301 remain unchanged, and the value of the SL field in SRH 302 also remains unchanged. After the SRv6 message is forwarded to the R4 node, the R4 node strips the IPv6 header 304 and SRH 303, and the node R4 continues to forward the SRv6 message based on SRH 302.

[0088] In another implementation manner, if the SRv6 message is not forwarded based on a tunnel, the node R2 directly adds the SID list corresponding to the BSID to the original SRH when re-encapsulating the SRv6 message.

[0089] Can be combined Figure 3c To understand, Figure 3c Another network structure diagram provided for an embodiment of the present application. Figure 3c and Figure 3b The same parts can be referred to above for Figure 3b The description of , will not be described in detail here. Figure 3c As shown, node R2 directly adds the SID list (R3, R4) corresponding to the BSID to SRH 302, the source address in the IPv6 header 301 is R1, and the destination address is R3. After the SRv6 message is forwarded to node R4, it is further forwarded to node R5 through R4.

[0090] The above head node uses BSID to access the trust domain. Although it can ensure that the network topology of the trust domain is not leaked to a certain extent, the edge node of the trust domain only verifies the BSID and does not verify other SIDs in the SID list. Therefore, if other SIDs in the SID list are tampered with, the network will still be attacked. For example, the above Figure 3a For understanding, assuming that the legitimate destination node of the SRv6 message is node R5, if the SID indicating the R5 node in the SID list in the SRv6 message is tampered with to the SID of other nodes in the trust domain 200, it will affect the security of the trust domain 200. If the SID indicating the R5 node in the SID list in the SRv6 message is tampered with to the SID of other nodes in the second domain 300, it will affect the security of the second domain 300.

[0091] The inventor of the present application has found that in another implementation, a key-related hashed message authentication code (HMAC) check can be configured on the edge node of the trust domain to prevent the SRH from being tampered with. The HMAC operation can take the key and data as input and compress the data into a data digest of a fixed length. Specifically, see Figure 4 To understand, Figure 4 A schematic diagram of the structure of another SRv6 message provided in an embodiment of the present application. Figure 4 As shown, the segment routing header SRH includes an HMAC Key ID field and an HMAC field. The HMAC Key ID field is used to identify the key and hash algorithm used for HMAC verification, and the field includes 4 bytes; the HMAC field is used to indicate the data summary of a specific field in the SRv6 message, and the field includes 32 bytes. Among them, the aforementioned specific field includes, for example, Figure 4 The source address (SA) field, the last entry field, the flags field, the SID list field, and the HMAC Key ID field are shown. Figure 4 The fields of the SRv6 message shown are not described in detail here.

[0092] exist Figure 4 In the SRv6 message shown, the SA field includes 16 bytes, the Last Entry field includes 1 byte, the Flags field includes 1 byte, and the SID list field includes 3 segment identifiers, namely segment list[2], segment list[1], and segment list[0], totaling 48 bytes. The value of the HMAC field is the data summary calculated by using the key indicated by the HMAC Key ID and the hash algorithm on the 70-byte data consisting of the aforementioned specific fields. The total number of bytes of the aforementioned specific fields can be determined based on the number of SIDs included in the SID list field. Figure 4 For illustration, the total number of bytes of a specific field is not limited to 70 bytes.

[0093] In the specific implementation, the key and hash algorithm can be stored on the head node outside the trust domain to prevent SRH from being tampered with by using HMAC verification. When the node outside the trust domain generates an SRv6 message, it can use the key and hash algorithm and the aforementioned specific fields to calculate HMAC, and obtain a message with the following characteristics: Figure 4The SRv6 message of the structure shown in the figure is forwarded to the edge node of the trust domain. The edge node of the trust domain may be pre-stored with a key and a hash algorithm. When the edge node of the trust domain receives the SRv6 message, it parses the HMAC Key ID field and uses the HMAC Key ID as an index to find the key and hash algorithm used for HMAC verification. Then, the edge node of the trust domain calculates the aforementioned specific fields in the received SRv6 message according to the key and hash algorithm found to obtain a data summary. The edge node compares the calculated data summary with the value of the HMAC field in the SRv6 message. If the two are the same, it means that the SRv6 message has not been tampered with, so the message can continue to be forwarded. If the two are not the same, it means that the SRv6 message has been tampered with, and the message can be discarded at this time. It should be noted that in this case, the head node outside the aforementioned trust domain can be considered a trustworthy node. Because if the head node holding the key and hash algorithm actively tamper with the message, the security of the entire network cannot be guaranteed.

[0094] In some embodiments, in order to prevent the security of the entire network from being threatened due to attacks on the head node holding the key and the hash algorithm, the aforementioned HMAC may also be calculated by the control management device and sent to the head node, which is not specifically limited in the embodiments of the present application.

[0095] Although the above method can ensure that the SRv6 message is not tampered with, the key and hash algorithm need to be pre-stored on the edge node of the trust domain, and the security of the key and hash algorithm is particularly important to the reliability of the above verification results. Therefore, additional protection measures are required to protect the security of the key and hash algorithm. In general, the edge devices in the trust domain are small forwarding devices with limited data processing capabilities. Protecting the security of the key and hash algorithm will consume more computing resources of the edge devices. Therefore, using the above method to verify whether the SRv6 message has been tampered with will affect the performance of the edge devices in the trust domain, so the possibility of the above method being adopted is relatively low.

[0096] Therefore, how to minimize the security risks when using SRv6 technology for message forwarding while taking into account the performance of the edge nodes in the trust domain is an issue that needs to be solved urgently.

[0097] In order to solve this problem, the present application embodiment provides a message forwarding method, which is combined with Figure 3a The network architecture shown introduces the message forwarding method provided by the embodiment of the present application. Figure 5 , which is a flow chart of a message forwarding method provided in an embodiment of the present application. Figure 5The method 100 shown, for example, can be implemented through the following S101 , S102 and S103 a , or through the following S101 , S102 and S103 b .

[0098] S101: Node R2 receives a first message, where the first message is an SRv6 message and the destination address of the first message is a BSID.

[0099] For node R2, please refer to the above Figure 3a For the SRv6 message and the destination address of the SRv6 message, please refer to the description of the SRv6 message and the SRv6 message forwarding process above, which will not be repeated here.

[0100] In the embodiment of the present application, the first message is sent by a node outside the trust domain to the node R2. The node outside the trust domain may be, for example, Figure 3a Node R1 is shown.

[0101] In the embodiment of the present application, in order to ensure the network topology security of the trust domain, nodes outside the trust domain can only access the trust domain through a legal BSID within the trust domain.

[0102] S102: Node R2 verifies the first message according to the BSID and the target field in the SRH of the first message.

[0103] After receiving the first message, in order to prevent network attacks, node R2 can verify the first message to determine whether the first message is an attack message. Specifically, when the first message passes the verification, it means that the first message is not an attack message, so node R2 can execute the step of forwarding the first message shown in S103a, that is, allowing the first message to be forwarded across the trust domain. When the first message fails to pass the verification, it means that the first message may be an attack message. In this case, if the first message is forwarded across the trust domain, it may cause damage to the trust domain or other networks (such as Figure 3a The second domain 300) causes a network attack. Therefore, the node R2 can execute the step of discarding the first message in S103b.

[0104] In the embodiment of the present application, on the one hand, since nodes outside the trust domain can only access the trust domain through a legal BSID within the trust domain. Therefore, it is possible to determine whether the first message is an attack message based on whether the destination address of the first message is a legal BSID within the trust domain. On the other hand, considering that the SRH of the SRv6 message contains key information for guiding message forwarding, such as the SID list, verifying this key information can determine whether the first message is an attack message. Therefore, node R2 can verify the first message based on the BSID in the first message and the target field in the SRH of the first message.

[0105] In one implementation of an embodiment of the present application, node R2 may execute S102 based on the instruction of the control management device. Specifically, the control management device may send a security protection policy to node R2, and the security protection policy carries instruction information, and the instruction information is used to instruct node R2 to verify the received SRv6 message. Specifically: the instruction information is used to instruct node R2 to verify the SRv6 message according to the BSID in the received SRv6 message and the target field in the SRH. Specifically, the control management device may send the security protection policy to node R2 through the Network Configuration Protocol (NETCONF), the Simple Network Management Protocol (SNMP), the Path Computation Element Communication Protocol (PCEP), the Border Gateway Protocol (BGP), etc. In a specific implementation, the security protection policy may be sent via the Border Gateway Protocol Flow Specification (BGP FS) routing.

[0106] The following is a brief description of BGP FS routing.

[0107] BGP FS routes are routes that contain new BGP network layer reachability information and extended community attributes. Through the new network layer reachability information and extended community attributes, BGP FS routes can carry corresponding BGP FS rules, which can also be regarded as a flow control strategy. Specifically, BGP FS rules can include flow matching conditions and corresponding flow processing behaviors after flow matching. At present, flow matching conditions are carried in BGP FS routes as network layer reachability information, and flow processing behaviors are carried in BGP FS routes as extended community attributes. At present, BGP FS has defined 16 flow matching conditions from type 1 to type 16. These 16 flow matching conditions are not described in detail here. The specific implementation method of S102 can be determined according to the target field. Different target fields have different specific implementation methods of S102. The following introduces the specific content of the target field and the specific implementation method of S102 corresponding to the target field.

[0108] The first implementation method: the target field is the next hop SID of the BSID.

[0109] In the embodiments of the present application, in general, when an SRv6 message needs to be forwarded across a trust domain, the trust domain can provide a BSID to indicate the forwarding path of the SRv6 message within the trust domain. In other words, the next hop SID of the BSID is theoretically used to indicate the out-of-domain node that the trust domain directly interacts with. Figure 3b It is understood that the next hop SID of the BSID is used to indicate the node R5 in the second domain 300 .

[0110] In some embodiments, if the first message is a legitimate message that has not been tampered with, the next hop SID of the BSID can be used to indicate the legitimate destination node of the first message. In order to ensure that the first message can be accurately forwarded to the legitimate destination node, prevent network attacks on other nodes. In the specific implementation of S102, node R2 can, for example, determine whether the BSID is a BSID in the trust domain. Then, node R2 determines whether the next hop SID of the BSID is in a legitimate network segment, and the legitimate network segment refers to the network segment where the legitimate destination node of the first message is located. If the next hop SID of the BSID is in a legitimate network segment, it means that the node indicated by the next hop SID of the BSID is the legitimate destination node of the first message. That is, the first message is forwarded to the legitimate destination node of the first message after being forwarded by the path indicated by the BSID. For this case, it can be considered that the first message passes the verification. Correspondingly, if the next hop SID of the BSID is not in a legitimate network segment, it means that the first message is not forwarded to the legitimate destination node of the first message after being forwarded by the path indicated by the BSID, but is forwarded to other nodes. In this case, the next hop SID of the BSID is likely to have been tampered with. Therefore, the first message is likely to cause an attack to other nodes. Therefore, in the embodiment of the present application, if the next hop SID of the BSID is not in the legal network segment, the first message fails to pass the verification.

[0111] In an embodiment of the present application, the aforementioned legal network segment may be, for example, statically configured on node R2, or may be sent to node R2 by a control management device. The embodiment of the present application does not make specific limitations. If the legal network segment is sent to node R2 by a control management device, the control management device may, for example, send the legal network segment to node R2 by carrying it in the security protection policy when sending the aforementioned security protection policy to node R2. Compared with the control management device sending the security protection policy and the first network segment separately to node R2, this can reduce the number of interactions between the control management device and node R2, and save input-output (IO) resources of the control management device and node R2.

[0112] As mentioned above, the control and management device can carry the security protection policy in the BGP FS route and send it to the node R2. In addition, BGP FS has defined 16 types of traffic matching conditions. Therefore, in the embodiment of the present application, BGP FS can be expanded, for example, a new traffic matching condition type 17 and type 18 are added, and the BSID can be carried in the newly added traffic matching condition type 17, and the legal network segment can be carried in the newly added traffic matching condition type 18.

[0113] In some embodiments, it is considered that the nodes included in the legal network segment may not be limited to the legal destination nodes of the first message. In order to prevent network hackers from tampering with the first message to cause network attacks on other nodes belonging to the legal network segment, in an implementation of the embodiment of the present application, the mask of the legal network segment can be set as long as possible. As an example, the mask length of the legal network segment can also be carried in type 18. Of course, other information can also be carried in type 18, which will not be listed here one by one.

[0114] For the specific implementation of node R2 determining whether the BSID is a BSID in the trust domain, please refer to the above description of Figure 3a The relevant description part will not be repeated here.

[0115] Regarding the aforementioned legal network segment, the embodiments of the present application do not make specific limitations. Considering that in actual applications, when the SRv6 message is forwarded, the SID indicating the destination node of the message may be a node SID, or it may be the SID of a virtual private network (VPN) instance deployed on the node, referred to as VPN SID. Of course, the SID list of the SRH may include both the SID of the destination node and the VPN SID deployed on the destination node. For a node, whether it is the node SID or the VPN SID of the node, it is within the network segment indicated by the locator route of the node. Among them, the locator route of the node refers to the network segment route to which the node SID of the node belongs. Therefore, in one embodiment, the aforementioned legal network segment may be the network segment indicated by the locator route of the legal destination node. In this way, regardless of whether the next-hop SID of the BSID is a node SID or a VPN SID, the legal network segment can be used to determine whether the first message has been tampered with.

[0116] Next, a simple example is given for type 17 and type 18. It should be understood that the relevant scheme for controlling the management device to issue security protection policies is only an exemplary description, and the embodiments of the present application are not limited to this.

[0117] Type 17 includes two fields: type and BSID.<type,BSID> The BSID field is used to carry the legal BSID in the trust domain, and the value of the type field is fixed to 17.

[0118] Type18 includes the type field, operator field, and value field, namely:<type,[operator,value]+> .

[0119] in:

[0120] The value of the type field is 18;

[0121] The value field is used to carry a valid network segment. The value field includes a network prefix and a mask length. The network prefix includes one byte and the mask length includes 16 bytes.

[0122] The operator field consists of 8 bits, bit0 to bit7;

[0123] “+” means that multiple [operator, value] combinations can be included;

[0124] The meaning of each bit in the operator field is shown in Table 2 below:

[0125] Table 2

[0126] Bit0 Bit1 Bit2 Bit3 Bit4 Bit5 Bit6 Bit7 e a reserve reserve reserve reserve Miss Match

[0127] E: end-of-list bit, the value of E is 1, indicating that the current<operator,value> Is the last one<operator,value> combination;

[0128] A: and bit; if the value of a is 1, it means the current<operator,value> Field representation and previous<operator,value> The field is in an "or" relationship. If it is 0, it means the same as the previous<operator,value> The fields are in an "and" relationship;

[0129] reserve: reserved field;

[0130] Miss: indicates the processing action when the next hop of the BSID is not in the network segment indicated by value. A Miss value of 0 indicates forwarding the message, and a Miss value of 1 indicates discarding the message.

[0131] Match: indicates the processing action when the next hop of the BSID is in the network segment indicated by value. A Match value of 0 indicates that the message is forwarded, and a Match value of 1 indicates that the message is discarded.

[0132] Regarding the security protection strategy that carries BSID and legal network segment, an example is given below: For a certain service, BSID b::1 is provided to nodes outside the trust domain to guide the forwarding path within the trust domain. The legal destination node of the service message corresponding to this service is in the network segment c::1 / 64. For the trust domain boundary node, the security protection strategy is issued through BGP FS, specifically: <0x11,b::1> and <0x12,[0x82,c::1 / 64]>.

[0133] Among them, 0x11 indicates type17, b::1 is used to instruct node R2 to verify whether the destination address of the received message 1 is a legal BSID b::1; 0x12 indicates type18, [0x82,c::1 / 64] is used to instruct node R2 to forward message 1 when the next hop SID of the BSID is in the network segment indicated by c::1 / 64, otherwise, discard message 1.

[0134] In some embodiments, in order to prevent the first message from attacking the trust domain, when S102 is specifically implemented, the node R2 can, for example, determine whether the BSID is a BSID in the trust domain. Then, the node R2 determines whether the next hop SID of the BSID is in the first network segment, and the first network segment refers to the network segment to which the node in the trust domain belongs. If the next hop SID of the BSID is in the first network segment, it means that the node indicated by the next hop SID of the BSID is a node in the trust domain. That is, after the first message is forwarded by the path indicated by the BSID, it does not leave the trust domain, but continues to be forwarded in the trust domain. In this case, the next hop SID of the BSID is likely to have been tampered with. Therefore, the first message is likely to cause a network attack on the node in the trust domain. Therefore, in an embodiment of the present application, if the next hop SID of the BSID is in the first network segment, the first message fails to pass the verification. Correspondingly, if the next hop SID of the BSID is not in the first network segment, it means that after the first message is forwarded by the path indicated by the BSID, it leaves the trust domain and is forwarded to other nodes outside the trust domain. In this case, it can be considered that the first message has passed the verification.

[0135] In an embodiment of the present application, the aforementioned first network segment may be, for example, statically configured on node R2, or may be sent to node R2 by a control and management device. The embodiment of the present application does not make specific limitations. If the first network segment is sent to node R2 by a control and management device, then the control and management device may, for example, send the first network segment to node R2 by carrying it in the security protection policy when sending the aforementioned security protection policy to node R2. Compared with the control and management device sending the security protection policy and the first network segment separately to node R2, this can reduce the number of interactions between the control and management device and node R2, and save input and output IO resources of the control and management device and node R2.

[0136] As mentioned above, the control and management device can carry the security protection policy in the BGP FS route to the node R2. In addition, BGP FS has defined 16 traffic matching conditions. Therefore, in the embodiment of the present application, BGP FS can be expanded to add traffic matching conditions type 17 and type 18. The BSID can be carried in the newly added traffic matching condition type 17, and the first network segment can be carried in the newly added traffic matching condition type 18. Of course, other information can also be carried in type 18, such as the mask length of the first network segment, etc., which will not be listed here one by one.

[0137] For type 17 and type 18, please refer to the relevant description above and will not be described in detail here.

[0138] Regarding the security protection strategy that carries the BSID and the first network segment, an example is given below: the address range in the trust domain 200 corresponds to the network segment a::1 / 64. For a certain service, the BSID b::1 is provided to the nodes outside the trust domain to guide the forwarding path within the trust domain. For the trust domain boundary nodes, the security protection strategy is issued through BGP FS, specifically: <0x11,b::1> and <0x12,[0x81,a::1 / 64]>.

[0139] Among them, 0x11 is used to indicate type17, b::1 is used to instruct node R2 to verify whether the destination address of the received message 1 is a legal BSID b::1; 0x11 is used to indicate type18, [0x81,a::1 / 64] is used to instruct node R2 to forward message 1 when the next hop SID of the BSID is not in the network segment indicated by a::1 / 64, otherwise, discard message 1.

[0140] For example, the node R2 can determine whether the BSID is a BSID in the trust domain. Figure 3a The relevant description part will not be repeated here.

[0141] From the above description, it can be known that, using the first implementation method, after the SRv6 message accesses the trust domain through the BSID, the trust domain can be guaranteed not to be attacked, or the first message can be forwarded to the legitimate destination node to avoid the node outside the legitimate destination node from being attacked. Moreover, since it does not involve key and hash algorithm protection, the computing resources of node R2 can be saved. Therefore, the solution of the embodiment of the present application can minimize the security risks when forwarding messages using SRv6 technology while taking into account the performance of node R2.

[0142] The second implementation manner: the target field is N SIDs in the SID list of the SRH of the first message.

[0143] In an embodiment of the present application, the value of N is greater than or equal to 1. When N is equal to 1, the SID is the next-hop SID of the BSID. When the value of N is greater than 1, the N SIDs are N consecutive SIDs in the SID list of the SRH, and the first SID of the N SIDs is the next-hop SID of the BSID. In other words, the BSID and the N SIDs can constitute a first SID list, and the first SID list is used to indicate a forwarding path. In an embodiment of the present application, the first SID list can be used to indicate the complete forwarding path of the first message from the node R2 to the destination node, or the first SID list can be used to indicate a part of the aforementioned complete forwarding path, that is, to indicate the forwarding path of the first message from the node R2 to the first node, and the first node is a node between the node R2 and the destination node of the first message.

[0144] In one implementation of the embodiment of the present application, if the target field is N SIDs in the SID list of the SRH, when S102 is specifically implemented, the SID list may be pre-stored in the node R2, and the SID list stored in the node R2 is used to indicate a legal path. Specifically, one or more SID lists may be pre-stored in the node R2, and one SID list indicates a legal path. Node R2 may compare the aforementioned first SID list with the locally stored SID list. If the locally stored SID list includes the aforementioned first SID list, it means that the path indicated by the aforementioned first SID list is a legal path, so node R2 can determine that the first message has passed the verification. On the contrary, if the locally stored SID list does not include the aforementioned first SID list, it is determined that the first message has not passed the verification.

[0145] Regarding the SID list stored in the node R2, you can refer to the following Table 3 for understanding, which shows two SID lists. Table 3 is output only for the convenience of understanding, and does not constitute a limitation of the embodiment of the present application. The number of SID lists stored in the node R2 is not limited to the two shown in Table 3, and the SID list stored in the node R2 is not limited to BSID-SID1-SID2 and BSID-SID3 shown in Table 3.

[0146] Table 3

[0147]

[0148] As shown in Table 3, the first SID in the SID list stored by the node R2 is a BSID. In one implementation of the embodiment of the present application, in order to improve the efficiency of the node R2 in determining that the locally stored SID list includes the aforementioned first SID list, when storing the SID list, the node R2 may store the first BSID in the SID list as an index of the SID list, and when determining whether the locally stored SID list includes the aforementioned first SID list, the BSID in the first SID list may be used as an index to determine whether the locally stored SID list includes the aforementioned first SID list.

[0149] In one implementation, the SID list stored in the node R2 may be statically configured on the node R2. In another implementation, the SID list stored in the node R2 may be sent to the node R2 by the control management device through a security protection policy.

[0150] As mentioned above, the control management device can carry the security protection policy in the BGP FS route to the node R2. Specifically, the BGP FS can be extended to add a new traffic matching condition type 17 and type 19. The newly added traffic matching condition type 17 can carry the BSID, and the newly added traffic matching condition type 19 can carry other SIDs to be verified.

[0151] For type 17, please refer to the description of type 17 above, and I will not repeat it here. Next, I will briefly explain type 19.

[0152] Similar to type18, type19 includes the type field, operator field, and value field, namely:<type,[operator,value]+> .in:

[0153] The value of the type field is 19;

[0154] The value field is used for SID;

[0155] The operator field consists of 8 bits, bit0 to bit7;

[0156] “+” means that multiple [operator, value] combinations can be included;

[0157] The meaning of each bit in the operator field is shown in Table 4 below:

[0158] Table 4

[0159]

[0160] E: end-of-list bit, the value of E is 1, indicating that the current<operator,value> Is the last one<operator,value> combination;

[0161] segment list number, used to carry the SID number.

[0162] Regarding the security protection strategy of carrying BSID and N SIDs, an example is given below: for a certain service, BSID b::1 is provided to nodes outside the trusted domain to guide the forwarding path within the domain. The legal forwarding path can be represented by the SIDlist shown in Table 5 below.

[0163] Table 5

[0164] Segment list[0] D1::1 Segment list[1] D2::1 Segment list[2] D3::1 Segment list[3] B::1

[0165] In this case, the control and management device can issue security protection policies to the trust domain boundary nodes through BGP FS, specifically including: <0x11,b::1>, <0x13, [0x00,D1::1], [0x01,D2::1], [0x02,D3::1], [0x83,B::1]>.

[0166] Among them, 0x11 indicates type17, b::1 is used to indicate a valid BSID; 0x13 indicates type19, [0x00, D1::1] indicates Segment list[0] = D1::1; <0x13, [0x01, D2::1] indicates Segment list[1] = D2::1; [0x02, D3::1] indicates Segment list[2] = D3::1; [0x83, B::1] indicates Segment list[3] = B::1, and <0x13, [0x83, B::1]> is the last one<operator,value> combination.

[0167] After receiving the above <0x11, b::1>, <0x13, [0x00, D1::1], [0x01, D2::1], [0x02, D3::1], [0x83, B::1]>, the node R2 can save the SID list, which includes: b::1, B::1, D3::1, D2::1 and D3::1.

[0168] In another implementation of the embodiment of the present application, if the target field is N SIDs in the SID list of the SRH, S102 may pre-store several hash values ​​in the node R2 during the specific implementation. For example, the node R2 may pre-store a hash table, which includes several hash values. The hash value stored in the node R2 is obtained by performing a hash operation on the SID list corresponding to the legal path. In this case, the node R2 may perform a hash operation on the first SID list to obtain a first hash value. After the node R2 obtains the first hash value, it may search for several hash values ​​stored locally to determine whether the calculated first hash value is included in the hash value stored locally. Specifically, the first hash value may be used as an index to search for several hash values ​​stored locally, so as to determine whether the first hash value is included in the hash value stored locally. If the first hash value is included in the hash value stored locally, it indicates that the path indicated by the first SID list is a legal path, and therefore, it can be determined that the first message has passed the verification. On the contrary, if the first hash value is not included in the hash value stored locally, it is determined that the first message has not passed the verification.

[0169] In an embodiment of the present application, the first SID in the SID list corresponding to the aforementioned legal path is a BSID. In order to improve the ability of node R2 to determine that the locally stored hash value includes the aforementioned first hash value, when storing the hash value, node R2 may store the first BSID in the SID list from which the hash value is calculated as an index of the hash value. Accordingly, when determining whether the locally stored hash value includes the aforementioned first hash value, the BSID in the first SID list may be used as an index to determine whether the locally stored hash value includes the aforementioned first hash value. Of course, when saving the hash value, node R2 may also store the SID list from which the hash value is calculated, which is not specifically limited in the embodiment of the present application.

[0170] The hash value stored locally by node R2 can be understood in conjunction with the following Table 6. Table 6 shows three possible ways of storing hash values. The first is to store only the hash value, the second is to store the hash value and the BSID, and the third is to store the hash value and the SID list calculated to obtain the hash value. Table 6 is only shown for ease of understanding and does not constitute a limitation on the embodiments of the present application.

[0171] Table 6

[0172]

[0173] In one implementation of the embodiment of the present application, the first message may include a first field, and the first field may be used to indicate the number of SIDs to be verified. After receiving the first message, node R2 may parse the first message to obtain the value of the first field, thereby further obtaining the N SIDs in the aforementioned BSID and SRH, and executing S102 to verify the first message. The embodiment of the present application does not specifically limit the first field, and the first field may be a reserved field in the SRv6 message, or the first field may be an extended field in the SRv6 message. For example, the first field may be Figure 4 The last 4 bits of the Flags field shown. In the embodiment of the present application, the value carried by the first field can be N or N+1, which is not specifically limited in the embodiment of the present application. Specifically, when the value carried by the first field is equal to N, the SID indicated by the first field does not include the destination address of the first message, that is, it does not include the BSID. When the value carried by the first field is equal to N+1, the SID indicated by the first field includes the destination address of the first message, that is, it includes the BSID.

[0174] In some embodiments, when saving a hash value, node R2 may also correspondingly save the number of SIDs included in the SID list that calculates the hash value. Accordingly, when matching the first hash value with the locally stored hash value, the number of SIDs included in the first SID list that calculates the first hash value is further compared with the number of SIDs in the locally stored hash table based on the value of the first field. The first message is determined to have passed the verification only when the first hash value is included in the locally stored hash table and the number of SIDs corresponding to the locally stored first hash value is equal to the number of SIDs included in the first SID list. Otherwise, it is determined that the first message has not passed the verification.

[0175] For this case, you can refer to Table 7 below to understand the hash table stored locally in node R2.

[0176] Table 7

[0177]

[0178] The method for node R2 to verify the first message will be illustrated with reference to Table 7. Assume that the way of storing hash values in node R2 is the first way shown in Table 7. Then when node R2 verifies the first message, for example, it can check whether the locally stored hash values include the first hash value. If the first hash value is hash value 1, then node R2 determines that the locally stored hash values include the first hash value. Further, since the number of SIDs included in the SID list for calculating hash value 1 in the locally stored hash values is a, if the number of SIDs included in the first SID list is a, then node R2 can determine that the first message passes the verification. If the number of SIDs included in the first SID list is not a, then node R2 can determine that the first message fails the verification. Among them, the number of SIDs included in the first SID list can be determined according to the value of the foregoing first field. Specifically, if the SID to be verified indicated by the value of the first field does not include the BSID, the number of SIDs included in the first SID list is equal to the value of the first field plus 1. If the SID to be verified indicated by the value of the first field includes the BSID, the number of SIDs included in the first SID list is equal to the value of the first field.

[0179] As can be seen from the above description, when the first SID list is used to indicate the complete forwarding path of the first message from node R2 to the destination node, using the second implementation method can ensure that the first message can be forwarded to the legal destination node of the first message. When the first SID list is used to indicate the forwarding path between node R2 and the first node, using the second implementation method can prevent the network between node R2 and the first node from being attacked.

[0180] Moreover, the computing resources consumed by node R2 to maintain the locally stored SID list or hash values are much less than the computing resources consumed by node R2 to protect the security of the key and hash algorithm. Therefore, the solution of the embodiment of the present application can minimize the security risks existing when using the SRv6 technology for message forwarding while taking into account the performance of node R2.

[0181] The third implementation method: The target field is the SL field.

[0182] As described above, the trust domain can provide a BSID to represent the forwarding path of the SRv6 packet within the trust domain. In some embodiments, an external node needs to forward an SRv6 packet into the trust domain. For such a case, the next-hop SID of the BSID should not exist in the SRH of the first packet, or rather, the BSID is the last SID indicating the forwarding path of the first packet. For such a case, the value of the SL field in the first packet is 0. Therefore, to ensure that the SRv6 packet forwarded into the trust domain can be normally forwarded into the trust domain. When specifically implemented, the node R2 can, for example, determine whether the BSID is the BSID in the trust domain. Then, the node R2 determines whether the value of the SL field is 0. When the value of the SL field is 0, it indicates that the destination node of the first packet is a node within the trust domain. Therefore, it can be determined that the first packet passes the verification. When the value of the SL field is not 0, the node R2 can verify the first packet using the above first method or the second method.

[0183] S103a: The node R2 discards the first packet that fails the verification.

[0184] The node R2 discarding the first packet can, for example, be that the node R2 deletes the first packet from local storage.

[0185] S103b: The node R2 forwards the first packet that passes the verification.

[0186] In the embodiments of the present application, when specifically implementing the forwarding of the first packet by the node R2, for example, it can obtain the SID list corresponding to the BSID, re-encapsulate the first packet according to the SID list, and forward the re-encapsulated first packet. Regarding the specific implementation manner of the node R2 re-encapsulating the first packet according to the SID list, reference can be made to the description part above for Figure 3b and Figure 3c which will not be repeated here.

[0187] From the above description, it can be seen that by using the packet forwarding method in the embodiments of the present application, it is possible to minimize the potential security hazards existing when using the SRv6 technology for packet forwarding while taking into account the performance of the node R2.

[0188] In one embodiment of the embodiments of the present application, node R2 may also obtain a second packet. The second packet is similar to the first packet and is also an SRv6 packet. The destination address of the second packet is the BSID. After receiving the second packet, node R2 may verify the second packet according to the BSID of the second packet and the target field in the SRH of the second packet. The specific implementation of node R2 verifying the second packet is similar to the method of node R2 verifying the first packet, and will not be repeated here. After node R2 verifies the second packet, it may forward the second packet when the second packet passes the verification. Since the verification of the second packet not only verifies the BSID but also verifies the target field, the second packet that passes the verification can be considered a legal packet. Therefore, forwarding the second packet across trust domains will not pose a security risk.

[0189] The embodiments of the present application also provide a packet forwarding method 200, which can be seen in Figure 6 , Figure 6 which is a schematic flowchart of a packet forwarding method provided by the embodiments of the present application. The following will be described in conjunction with Figure 6 this method. Figure 6 The method shown, for example, can be implemented through S201 - S203.

[0190] S201: The edge node of the trust domain receives a first packet. The first packet is an SRv6 packet, and the destination address of the first packet is the binding segment identifier BSID.

[0191] S202: The edge node verifies the first packet according to the BSID in the first packet and the target field in the segment routing header SRH.

[0192] S203: The edge node discards the first packet that fails the verification.

[0193] Method 200 can be used to implement S101, S102, and S103a executed by node R2 in method 100 mentioned in the above embodiments. When method 200 is used to implement S101, S102, and S103a executed by node R2 in method 100 mentioned in the above embodiments, the edge node of the trust domain corresponds to node R2 in method 100, and the first packet corresponds to the first packet in method 100.

[0194] In one implementation, the edge node may also receive a security protection policy from a control and management device. The security protection policy is used to instruct the edge node to verify the first packet according to the BSID and the target field in the SRH.

[0195] In one implementation, the target field includes the next-hop SID of the BSID; or, the target field includes N SIDs in the segment identifier SID list, where the first SID among the N SIDs is the next-hop SID of the BSID, N is greater than or equal to 1, and when N is greater than 1, the N SIDs are consecutive N SIDs in the SID list; or, the target field includes the segment left SL field.

[0196] In one implementation, when the target field includes the next-hop SID of the BSID, the edge node verifies the first packet according to the BSID in the first packet and the target field in the segment routing header SRH, including: when the BSID is the BSID in the trust domain and the target field is not within the legal network segment, the edge node determines that the first packet fails the verification, and the legal network segment is the network segment where the legal destination node of the first packet is located.

[0197] In one implementation, the legal network segment is the network segment indicated by the locator route of the legal destination node. The legal destination node mentioned here can correspond to Figure 3a the node R5 in the second domain 300 shown.

[0198] In one implementation, the legal network segment is carried in the security protection policy; or, the legal network segment is statically configured on the edge node.

[0199] In one implementation, when the target field includes the next-hop SID of the BSID, the edge node verifies the first packet according to the BSID in the first packet and the target field in the segment routing header SRH, including: when the BSID is the BSID in the trust domain and the target field is within the first network segment, the edge node determines that the first packet fails the verification, and the first network segment is the network segment to which the nodes in the trust domain belong. The first network segment mentioned here can correspond to Figure 3c the network segment to which the nodes in the trust domain 200 shown belong.

[0200] In one implementation, the first network segment is carried in the security protection policy; or, the first network segment is statically configured on the edge node.

[0201] In one implementation, when the target field includes N SIDs in the SID list, the edge node verifies the first packet according to the BSID in the first packet and the target field in the segment routing header (SRH), including: the edge node compares the first SID list formed by the BSID and the target field with the SID list stored in the edge node. If the SID list stored in the edge node does not include the first SID list, the edge node determines that the first packet fails the verification. The SID list stored in the edge node is used to indicate a legal path.

[0202] In one implementation, when the target field includes N SIDs in the SID list, the edge node verifies the first packet according to the BSID in the first packet and the target field in the segment routing header (SRH), including: the edge node performs a hash operation on the first SID list formed by the BSID and the target field to obtain a first hash value; if the stored hash value in the edge node does not include the first hash value, the edge node determines that the first packet fails the verification. The hash value stored in the edge node is obtained by performing the hash operation on the SID list indicating the legal path.

[0203] In one implementation, the first packet includes a first field, and the first field is used to indicate the number of SIDs to be verified.

[0204] In one implementation, the SID list indicating the legal path is carried in the security protection policy; or, the SID list indicating the legal path is statically configured on the edge node.

[0205] In one implementation, when the target field includes the SL field, the edge node verifies the first packet according to the BSID in the first packet and the target field in the segment routing header (SRH), including:

[0206] The edge node determines that the BSID is the BSID in the trust domain; when the value of the target field is not equal to 0, the edge node determines that the first packet fails the verification.

[0207] In one implementation, the edge node may also obtain a second packet, where the second packet is an SRv6 packet, and the destination address of the second packet is the binding segment identifier (BSID); the edge node verifies the second packet according to the BSID in the second packet and the target field in the SRH of the second packet; the edge node forwards the second packet that passes the verification.

[0208] Regarding the specific implementation of Method 200, reference can be made to the description of S101, S102, and S103a in Method 100 above, and the description will not be repeated here.

[0209] An embodiment of the present application also provides a packet forwarding method 300, which can be seen Figure 7 , Figure 7 is a schematic flowchart of a packet forwarding method provided by an embodiment of the present application. The following will be combined with Figure 7 to describe this method. Figure 7 The method shown, for example, can be implemented through S301 - S303.

[0210] S301: The edge node in the trusted domain receives a first packet, the first packet is an SRv6 packet, and the destination address of the first packet is a bound segment identifier BSID.

[0211] S302: The edge node verifies the first packet according to the BSID in the first packet and the target field in the segment routing header SRH of the first packet.

[0212] S303: The edge node forwards the first packet that passes the verification.

[0213] Method 300 can be used to implement S101, S102, and S103b executed by node R2 in Method 100 mentioned in the above embodiments. When Method 200 is used to implement S101, S102, and S103b executed by node R2 in Method 100 mentioned in the above embodiments, the edge node in the trusted domain corresponds to node R2 in Method 100, and the first packet corresponds to the first packet in Method 100.

[0214] In one implementation, the edge node may also receive a security protection policy from a control and management device, and the security protection policy is used to instruct the edge node to verify the first packet according to the BSID and the target field in the SRH.

[0215] In one implementation, the target field includes the next-hop SID of the BSID; or, the target field includes N SIDs in a segment identifier SID list, the first SID among the N SIDs is the next-hop SID of the BSID, N is greater than or equal to 1, and when N is greater than 1, the N SIDs are consecutive N SIDs in the SID list; or, the target field includes a segment remaining SL field.

[0216] In one implementation, when the target field includes the next-hop SID of the BSID, the edge node verifies the first packet according to the BSID in the first packet and the target field in the segment routing header (SRH). In a specific implementation, the edge node may determine that the first packet passes the verification when it determines that the BSID is the BSID in the trust domain and the target field is within a legal network segment. Wherein, the legal network segment is the network segment where the legal destination node of the first packet is located.

[0217] In one implementation, the legal network segment is the network segment indicated by the locator of the legal destination node. The legal destination node mentioned here may correspond to, for example, Figure 3a the node R5 in the second domain 300 shown.

[0218] In one implementation, the legal network segment is carried in the security protection policy; or, the legal network segment is statically configured on the edge node.

[0219] In one implementation, when the target field includes the next-hop SID of the BSID, the edge node verifies the first packet according to the BSID in the first packet and the target field in the segment routing header (SRH). In a specific implementation, for example, it may be: when the edge node determines that the BSID is the BSID in the trust domain and the target field is not within the first network segment, the edge node determines that the first packet passes the verification. Wherein, the first network segment is the network segment to which the nodes in the trust domain belong. The first network segment mentioned here may correspond to Figure 3c the network segment to which the nodes in the trust domain 200 shown belong.

[0220] In one implementation, the first network segment is carried in the security protection policy; or, the first network segment is statically configured on the edge node.

[0221] In one implementation, when the target field includes N SIDs in the SID list, the edge node verifies the first packet according to the BSID in the first packet and the target field in the segment routing header (SRH). In a specific implementation, for example, it may be: the edge node compares the first SID list formed by the BSID and the target field with the SID list stored by the edge node. If the SID list stored by the edge node includes the first SID list, the edge node determines that the first packet passes the verification. The SID list stored by the edge node is used to indicate a legal path.

[0222] In one implementation, when the target field includes N SIDs in the SID list, the edge node verifies the first packet according to the BSID in the first packet and the target field in the segment routing header (SRH), including: the edge node performs a hash operation on the first SID list formed by the BSID and the target field to obtain a first hash value; if the hash values stored by the edge node include the first hash value, the edge node determines that the first packet passes the verification, and the hash values stored by the edge node are obtained by performing the hash operation on the SID list indicating the legal path.

[0223] In one implementation, the first packet includes a first field for indicating the number of SIDs to be verified.

[0224] In one implementation, the SID list indicating the legal path is carried in the security protection policy; or, the SID list indicating the legal path is statically configured on the edge node.

[0225] In one implementation, when the target field includes the SL field, the edge node verifies the first packet according to the BSID in the first packet and the target field in the segment routing header (SRH). In a specific implementation, for example, it may be: the edge node determines that the BSID is the BSID in the trusted domain, and when the value of the target field is equal to 0, the edge node determines that the first packet passes the verification.

[0226] For the specific implementation of method 300, reference may be made to the description parts of S101, S102, and S103b in method 100 above, and the description will not be repeated here.

[0227] The embodiments of the present application further provide a forwarding control method 400, which can be seen in Figure 8 , Figure 8 is a schematic flowchart of a forwarding control method provided by the embodiments of the present application. The following will be described in conjunction with Figure 8 to illustrate this method. Figure 8 The method shown, for example, can be implemented through S401 - S402.

[0228] S401: The control and management device obtains a security protection policy, which is used to instruct the edge node of the trusted domain to verify the received SRv6 packet according to the BSID and the target field in the segment routing header (SRH).

[0229] S402: The control and management device sends the security protection policy to the edge node of the trusted domain.

[0230] Method 400 can be used to implement the steps performed by the control and management device in Method 100 mentioned in the above embodiments. The trust domain in Method 400 can be Figure 3a the trust domain 200 shown. The edge node of the trust domain in Method 400 can correspond to node R2 in Method 100.

[0231] In one implementation, the control and management device can send the security protection policy to the edge node of the trust domain through a PCEP message.

[0232] In one implementation, the control and management device can send the security protection policy to the edge node of the trust domain through a BGP message.

[0233] In one implementation, the control and management device can send the security protection policy to the edge node of the trust domain through a NETCONF message.

[0234] In one implementation, the control and management device can send the security protection policy to the edge node of the trust domain through an SNMP message.

[0235] In one implementation, the target field includes the next-hop SID of the BSID; or, the target field includes N SIDs in the segment identifier SID list, the first SID among the N SIDs is the next-hop SID of the BSID, N is greater than or equal to 1, and when N is greater than 1, the N SIDs are consecutive N SIDs in the SID list; or, the target field includes the segment remainder SL field.

[0236] In one implementation, if the target field includes the next-hop SID of the BSID, the legal BSIDs and legal network segments within the trust domain are carried in the security protection policy.

[0237] In one implementation, the legal BSIDs and legal network segments within the trust domain can be carried in the extended attributes of BGP FS. For example, the legal BSIDs within the trust domain are carried in the extended attribute type17 of BGP FS, and the legal network segments are carried in the extended attribute type18 of BGP FS.

[0238] In one implementation, if the target field includes the next-hop SID of the BSID, the legal BSIDs and the first network segment within the trust domain are carried in the security protection policy.

[0239] In one implementation, the legal BSID and the first network segment within the trust domain can be carried in the extended attributes of BGP FS. For example, the legal BSID within the trust domain is carried in the extended attribute type17 of BGP FS, and the first network segment is carried in the extended attribute type18 of BGP FS.

[0240] In one implementation, if the target field includes N SIDs in the segment identifier SID list, the SID list indicating the legal path is carried in the security protection policy, and the SID list includes the legal BSID within the trust domain.

[0241] In one implementation, the SID list indicating the legal path can be carried in the extended attributes of BGP FS. For example, the SID list indicating the legal path can be carried in the extended attribute type19 of BGP FS.

[0242] Regarding the specific implementation of method 400, reference can be made to the description part of the steps executed by the control and management device in method 100 above, which will not be repeated here.

[0243] In addition, an edge node 900 is provided in an embodiment of the present application. Refer to Fig. 9 as shown Fig. 9 which is a schematic structural diagram of an edge node provided in an embodiment of the present application. The edge node 900 includes a transceiver unit 901 and a processing unit 902. Among them, the transceiver unit 901 is used to perform the transceiver operations executed by node R2 in the corresponding embodiment of the above method 100; the processing unit 902 is used to perform other operations except for the transceiver operations executed by node R2 in the corresponding embodiment of the above method 100. For example: if the edge node 900 is node R2 in method 100, then the transceiver unit 901 is used to perform the step of receiving the first message; the processing unit 902 is used to perform the steps of verifying the first message according to the target field in the BSID and SRH, and discarding the first message that fails the verification.

[0244] In addition, a control and management device 1000 is provided in an embodiment of the present application. Refer to Fig.10 as shown Fig.10 which is a schematic structural diagram of a control and management device provided in an embodiment of the present application. The control and management device 1000 includes a transceiver unit 1001 and a processing unit 1002. Among them, the transceiver unit 1001 is used to perform the transceiver operations executed by the control and management device in the above embodiments. The processing unit 1002 is used to perform the operations other than the transceiver operations executed by the control and management device mentioned in the above embodiments. For example, the transceiver unit 1001 is used to send a security protection policy to the edge node of the trust domain, and the processing unit 1002 is used to obtain the security protection policy.

[0245] In addition, an embodiment of the present application further provides an edge node 1100. Refer to Fig.11 as shown in Fig.11 FIG. [a figure number not provided in the original, should be added according to the actual figure], which is a schematic structural diagram of an edge node provided by an embodiment of the present application. The edge node 1100 includes a communication interface 1101 and a processor 1102 connected to the communication interface 1101. Among them, the communication interface 1101 is used to perform the sending and receiving operations executed by node R2 in the corresponding embodiment of the above method 100; the processor 1102 is used to perform other operations executed by node R2 in the corresponding embodiment of the above method 100 except for the sending and receiving operations. For example, if the edge node 1100 is node R2 in method 100, then the communication interface 1101 is used to perform the step of receiving the first message; the processor 1102 is used to perform the steps of verifying the first message according to the target fields in the BSID and SRH, and discarding the first message that fails the verification.

[0246] In addition, an embodiment of the present application further provides a control and management device 1200. Refer to Fig.12 as shown in Fig.12 FIG. [a figure number not provided in the original, should be added according to the actual figure], which is a schematic structural diagram of a control and management device provided by an embodiment of the present application. The control and management device 1200 includes a communication interface 1201 and a processor 1202 connected to the communication interface 1201. Among them, the communication interface 1201 is used to perform the sending and receiving operations executed by the control and management device in the above embodiments. The processor 1202 is used to perform operations other than the sending and receiving operations executed by the control and management device mentioned in the above embodiments. For example, the communication interface 1201 is used to send a security protection policy to the edge node in the trusted domain, and the processor 1202 is used to obtain the security protection policy.

[0247] In addition, an embodiment of the present application further provides an edge node 1300. Refer to Fig.13 as shown in Fig.13 FIG. [a figure number not provided in the original, should be added according to the actual figure], which is a schematic structural diagram of an edge node provided by an embodiment of the present application. The edge node 1300 includes a memory 1301 and a processor 1302. Among them, the memory 1301 is used to store program code; the processor 1302 is used to run the instructions in the program code, so that the edge node 1300 executes the steps executed by node R2 in the corresponding embodiment of the above method 100.

[0248] In addition, an embodiment of the present application further provides a control and management device 1400. Refer to Fig.14 as shown in Fig.14A structural schematic diagram of a control and management device provided by an embodiment of the present application. The control and management device 1400 includes a memory 1401 and a processor 1402. Among them, the memory 1401 is used to store program codes; the processor 1402 is used to run the instructions in the program codes, so that the control and management device 1400 executes the steps executed by the control and management device in the above embodiments.

[0249] An embodiment of the present application also provides a computer-readable storage medium. Instructions are stored in the computer-readable storage medium. When it runs on a computer, it causes the computer to execute the steps executed by node R2 in the above method 100, or causes the computer to execute the steps executed by the control and management device in the above method 100.

[0250] An embodiment of the present application also provides a communication system. The communication system includes a control and management device and an edge node. In some embodiments, the edge node is node R2 that executes the above method 100. In some embodiments, the control and management device is the control and management device that issues a security protection policy to node R2 in the above method 100.

[0251] Terms such as "first", "second", "third", "fourth", etc. (if any) in the specification, claims and above-mentioned drawings of the present application are used to distinguish similar objects, and do not have to be used to describe a specific order or sequence. It should be understood that such data can be interchanged under appropriate circumstances so that the embodiments described here can be implemented in an order other than those illustrated or described here. In addition, the terms "include" and "have" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product or device that includes a series of steps or units does not have to be limited to those steps or units clearly listed, but may include other steps or units not clearly listed or inherent to these processes, methods, products or devices.

[0252] Those skilled in the art can clearly understand that for the convenience and brevity of description, the specific working processes of the above-described systems, devices, and units can refer to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0253] In several embodiments provided in the present application, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of units is only a logical service division. In actual implementation, there may be other division methods. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed couplings or direct couplings or communication connections to each other can be through some interfaces, and the indirect couplings or communication connections of devices or units can be in electrical, mechanical, or other forms.

[0254] 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 can be located in one place or distributed to multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0255] In addition, in each embodiment of the present application, each service unit can be integrated in a processing unit, or each unit can exist physically alone, or two or more units can be integrated in one unit. The above-mentioned integrated units can be implemented in the form of hardware or in the form of software service units.

[0256] If the integrated unit is implemented in the form of a software service unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, in essence, or the part that contributes to the prior art, or all or part of this technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods in each embodiment of the present application. And the aforementioned storage medium includes: USB flash drives, mobile hard disks, read-only memories (ROM, Read-Only Memory), random access memories (RAM, Random Access Memory), magnetic disks, or optical discs and other various media that can store program codes.

[0257] Those skilled in the art should be able to realize that in one or more of the above examples, the operations described in the present invention can be implemented by hardware, software, firmware, or any combination thereof. When implemented using software, these operations can be stored in a computer-readable medium or transmitted as one or more instructions or codes on a computer-readable medium. The computer-readable medium includes computer storage media and communication media, where the communication media includes any medium that facilitates the transfer of a computer program from one place to another. The storage media can be any available medium accessible by a general-purpose or special-purpose computer.

[0258] The above specific implementation manners have further elaborated on the purpose, technical solutions, and beneficial effects of the present invention. It should be understood that the above is only the specific implementation manners of the present invention.

[0259] In the above, the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit it; although the present application has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that: they can still modify the technical solutions recorded in the foregoing embodiments, or perform equivalent replacements on some of the technical features; and these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the various embodiments of the present application.

Claims

1. A packet forwarding method, characterized in that, it includes: An edge node in the Segment Routing IPv6 (SRv6) trust domain receives a first packet, where the first packet is an SRv6 packet, and the destination address of the first packet is a Binding Segment Identifier (BSID); The edge node verifies the first packet according to the BSID in the first packet and the destination field in the Segment Routing Header (SRH); The edge node discards the first packet that fails the verification, where: The destination field includes one or more of the following: The next-hop SID of the BSID; N SIDs in the SID list of segment identifiers, where the first SID among the N SIDs is the next-hop SID of the BSID, and N is greater than or equal to 1; and The Segment Left (SL) field.

2. The method according to claim 1, characterized in that, the method further includes: The edge node receives a security protection policy from a control and management device, and the security protection policy is used to instruct the edge node to verify the first packet according to the BSID and the destination field in the SRH.

3. The method according to claim 1, characterized in that, when the destination field includes the next-hop SID of the BSID, the edge node verifies the first packet according to the BSID in the first packet and the destination field in the SRH, including: Determining that the BSID is a BSID in the trust domain, and determining that the network segment to which the next-hop SID belongs is not a legal network segment, then the edge node determines that the first packet fails the verification, and the legal network segment is the network segment where the legal destination node of the first packet is located.

4. The method according to claim 3, characterized in that, the legal network segment is the network segment indicated by the locator route of the legal destination node.

5. The method according to claim 3 or 4, characterized in that, the edge node obtains the legal network segment from the security protection policy; or the legal network segment is statically configured on the edge node.

6. The method according to claim 1, characterized in that, when the destination field includes the next-hop SID of the BSID, the edge node verifies the first packet according to the BSID in the first packet and the destination field in the SRH, including: When it is determined that the BSID is a BSID in the trust domain, and it is determined that the network segment to which the destination field belongs is a first network segment, then the edge node determines that the first packet fails the verification, and the first network segment is the network segment to which the nodes in the trust domain belong.

7. The method according to claim 6, characterized in that, the edge node obtains the first network segment from the security protection policy; or the first network segment is statically configured on the edge node.

8. The method according to claim 1, characterized in that, The target field includes N SIDs in the SID list of the SRH, and the edge node verifies the first packet according to the BSID in the first packet and the target field in the segment routing header SRH, where N is an integer, including: The edge node compares the first SID list composed of the BSID and the N SIDs with the SID list stored by the edge node. If the SID list stored by the edge node does not include the first SID list, the edge node determines that the first packet fails the verification. The SID list stored by the edge node is used to indicate a legal path.

9. The method according to claim 1, wherein, The target field includes N SIDs in the SID list of the SRH, and the edge node verifies the first packet according to the BSID in the first packet and the target field in the segment routing header SRH, where N is an integer, including: The edge node performs a hash operation on the first SID list composed of the BSID and the N SIDs to obtain a first hash value; If the first hash value is not included in the hash values stored by the edge node, the edge node determines that the first packet fails the verification. The hash values stored by the edge node are obtained by performing the hash operation on the SID list indicating the legal path.

10. The method according to claim 8 or 9, wherein, The first packet includes a first field, and the first field is used to indicate the number of SIDs to be verified.

11. The method according to claim 8 or 9, wherein, The SID list indicating the legal path is carried in the security protection policy; or the SID list indicating the legal path is statically configured on the edge node.

12. The method according to claim 1, wherein, The target field includes the SL field, and the edge node verifies the first packet according to the BSID in the first packet and the target field in the segment routing header SRH, including: The edge node determines that the BSID is the BSID in the trust domain; When the value of the target field is not equal to 0, the edge node determines that the first packet fails the verification.

13. The method according to any one of claims 1-4 or any one of claims 6-9 or claim 12, wherein, The method further includes: The edge node receives a second packet, the second packet is an SRv6 packet, and the destination address of the second packet is the binding segment identifier BSID; The edge node verifies the second packet according to the BSID in the second packet and the target field in the SRH of the second packet; The edge node forwards the second packet that passes the verification.

14. A communication method, wherein, The method includes: The control and management device generates a first message, and the first message includes a security protection policy, which is used to instruct an edge node of an Internet Protocol Version 6 Segment Routing (SRv6) trust domain to verify an SRv6 message received according to a Binding Segment Identifier (BSID) and a destination field in a Segment Routing Header (SRH); The control and management device sends the first message to the edge node of the SRv6 trust domain; wherein: The destination field includes one or more of the following: The next-hop SID of the BSID; N SIDs in a Segment Identifier (SID) list, where the first SID in the N SIDs is the next-hop SID of the BSID, and N is greater than or equal to 1; and The Segment Left (SL) field.

15. The method according to claim 14, characterized in that the first message is: a Path Computation Element Communication Protocol (PCEP) message; a Border Gateway Protocol (BGP) message; a Network Configuration Protocol (NETCONF) message; or a Simple Network Management Protocol (SNMP) message.

16. The method according to claim 14, characterized in that if the destination field includes the next-hop SID of the BSID, the security protection policy carries the legitimate BSIDs and legitimate network segments within the trust domain.

17. The method according to claim 16, characterized in that the legitimate BSIDs within the SRv6 trust domain and the legitimate network segments are carried in a Border Gateway Protocol Flow Specification (BGP FS) extended attribute.

18. The method according to claim 14, characterized in that if the destination field includes the next-hop SID of the BSID, the security protection policy carries the legitimate BSIDs and a first network segment within the trust domain.

19. The method according to claim 18, characterized in that the legitimate BSIDs within the SRv6 trust domain and the first network segment are carried in the BGP FS extended attribute.

20. The method according to claim 14, characterized in that if the destination field includes N SIDs in a SID list, the security protection policy carries a SID list indicating a legitimate path, and the SID list includes the legitimate BSIDs within the trust domain.

21. The method according to claim 20, characterized in that the SID list indicating the legitimate path is carried in the BGPFS extended attribute.

22. An edge node, characterized in that it includes: a communication interface; and a processor connected to the communication interface; Based on the communication interface and the processor, the edge node is configured to execute the method according to any one of the preceding claims 1-13.

23. A control and management device, characterized in that it includes: a communication interface; and a processor connected to the communication interface; Based on the communication interface and the processor, the control and management device is configured to execute the method according to any one of the preceding claims 14-21.

24. An edge node, characterized in that the edge node includes a memory and a processor; the memory is used to store program code; The processor is configured to execute the instructions in the program code, so that the edge node performs the method according to any one of claims 1-13 above.

25. A control and management device, characterized in that the control and management device includes a memory and a processor; the memory is configured to store program code; the processor is configured to execute the instructions in the program code, so that the control and management device performs the method according to any one of claims 14-21 above.

26. A computer-readable storage medium, characterized in that instructions are stored in the computer-readable storage medium, and when the instructions are run on a computer, the computer is caused to perform the method according to any one of claims 1-13 or claims 14-21 above.

27. A communication system, characterized in that it includes an edge node and a control and management device, wherein the control and management device is configured to perform the method according to any one of claims 14-21 above.

28. A communication system, characterized in that it includes an edge node and a control and management device, wherein the edge node is configured to perform the method according to any one of claims 1-13 above.

Images