Message processing method and message processing system, validation method, node, and storage medium

Abstract

Provided in the present application are a message processing method and a message processing system, a validation method, a node, and a storage medium The message processing method comprises: adding a message header of an Internet protocol into a message, wherein an extension header of the message header carries source address validation (SAV) information, the SAV information being used for instructing a node, which receives the message, to validate source-address-related information of the message; and sending the message.

Description

Message processing method, verification method, node, message processing system and storage medium Technical Field

[0001] The present application relates to the field of network communication technology, for example, to a message processing method, a verification method, a node, a message processing system and a storage medium. Background Art

[0002] The Internet routing system operates on a best-effort basis. Routers use the destination address in their routing table entries to forward packets along the optimal path possible to the recipient. Forged or spurious routing sources in packets with inauthentic source addresses are not detected or filtered, potentially leading to attacks on the Internet. The Internet lacks verification of the authenticity of the data packet's source, preventing attacks using forged source addresses.

[0003] Summary of the Invention

[0004] The present application provides a message processing method, a verification method, a node, a message processing system and a storage medium.

[0005] The present application provides a message processing method, applied to a source node, including:

[0006] An Internet Protocol message header is added to the message, wherein an extended header of the message header carries source address validation (SAV) information, wherein the SAV information is used to instruct a node receiving the message to verify source address related information of the message; and the message is sent.

[0007] This embodiment of the present application provides a verification method, which is applied to an intermediate node and includes:

[0008] Receive a message, wherein the extended header of the message header carries source address verification SAV information; identify the SAV service identifier, decapsulate the SAV information in the extended header; and complete the SAV verification function of the message according to the SAV information.

[0009] The present embodiment provides a message processing method, applied to a destination node, including:

[0010] Receive a message, wherein an extension header of the message header carries source address verification SAV information; identify the SAV service identifier, decapsulate the SAV information in the extension header; complete the SAV verification function of the message according to the SAV information; strip the message header to obtain a message without the message header added.

[0011] An embodiment of the present application also provides a source node, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the above-mentioned message processing method when executing the program.

[0012] An embodiment of the present application also provides an intermediate node, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the above-mentioned verification method when executing the program.

[0013] An embodiment of the present application also provides a destination node, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the above-mentioned message processing method when executing the program.

[0014] An embodiment of the present application also provides a message processing system, including: the above-mentioned source node, intermediate node and destination node.

[0015] An embodiment of the present application further provides a computer-readable storage medium, on which a computer program is stored. When the program is executed by a processor, the above-mentioned message processing method and verification method are implemented. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] FIG1 is a flow chart of a message processing method provided by an embodiment;

[0017] FIG2 is a schematic diagram of a standard format of an Internet Protocol Version 6 (IPv6) message header provided by an embodiment;

[0018] FIG3 is a flow chart of a verification method provided by an embodiment;

[0019] FIG4 is a flow chart of a message processing method provided by another embodiment;

[0020] FIG5 is a schematic diagram of an AS topology of the same SAV trust domain provided by an embodiment;

[0021] FIG6 is a schematic diagram of a SAV first option type package provided by an embodiment;

[0022] FIG7 is a schematic diagram of a SAV second option type package provided by an embodiment;

[0023] FIG8 is a schematic diagram of a different SAV trust domain AS topology provided by an embodiment;

[0024] FIG9 is a schematic diagram of a SAV third option type message encapsulation provided by an embodiment;

[0025] FIG10 is a schematic structural diagram of a message processing device provided by an embodiment;

[0026] FIG11 is a schematic structural diagram of a verification device provided by an embodiment;

[0027] FIG12 is a schematic structural diagram of a message processing device provided by another embodiment;

[0028] FIG13 is a schematic diagram of the hardware structure of a source node provided by an embodiment;

[0029] FIG14 is a schematic diagram of the hardware structure of an intermediate node provided by an embodiment;

[0030] FIG15 is a schematic diagram of the hardware structure of a destination node provided by an embodiment;

[0031] FIG16 is a schematic structural diagram of a message processing system provided by an embodiment. DETAILED DESCRIPTION

[0032] The present application is described below in conjunction with the accompanying drawings and embodiments. The specific embodiments described herein are merely for explaining the present application. For ease of description, only the parts relevant to the present application are shown in the accompanying drawings.

[0033] The Internet is untrustworthy. Forging source addresses and attacking the network lacks authenticity verification of the datagram's source. To address this issue, a series of technical workarounds exist, such as:

[0034] 1) Using inbound and outbound access control lists (ACLs) to drop packets whose source addresses don't meet the filtering criteria. However, this technique requires manual configuration and, in BGP's inter-AS context, involves a large number of routes, making it inflexible.

[0035] 2) Strict Unicast Reverse Path Forwarding (URPF) is applicable when the routing paths are consistent. However, when the routing is asymmetric, there is a problem of incorrectly discarding packets due to incorrect source address filtering.

[0036] 3) The Feasible-Path Unicast Reverse Path Forwarding (FP-URPF) solution is more effective than strict URPF, but its applicable scenarios are very limited. Its use requires strict adherence to the same prefix route advertising to all neighboring ASes, or advertising the same prefix aggregated route to all neighboring ASes. It can also send specific prefix routes to specific ASes based on specific deployment requirements, resulting in high implementation complexity.

[0037] 4) In the loose unicast reverse path forwarding (URPF) solution, a message is discarded only if there is no corresponding prefix route in the forwarding information base (FIB) entry, which may lead to incorrect message forwarding.

[0038] The IETF SAVNET working group is discussing the issue of cross-autonomous system (AS) source address verification for the Border Gateway Protocol (BGP), including its architecture and solutions. While only the draft has reached a certain level of industry consensus, other aspects are still in the initial stages of standardization. Regarding cross-AS source address verification for BGP, the following two issues need to be addressed:

[0039] 1) The source address prefix message comes from a real trusted path; 2) The source prefix packet data message that meets / does not meet the source address prefix is ​​forwarded / discarded / redirected.

[0040] The message processing method and verification method provided in this application can directly verify the validity of the source address prefix route through Internet Protocol message parsing, and through the specific source address verification (Source Address Validation, SAV) service identifier corresponding to the source address prefix route, realize the convenient carrying of SAV trust domain information, effectively avoiding source address spoofing traffic and attacks on the network caused by the untrustworthy Internet.

[0041] FIG1 is a flow chart of a message processing method provided by an embodiment, which can be applied to a source node. As shown in FIG1 , the method provided by this embodiment includes steps 110 to 120 .

[0042] In 110, an Internet Protocol message header is added to the message, and an extension header of the message header carries source address verification SAV information, and the SAV information is used to instruct a node receiving the message to verify source address related information of the message.

[0043] In 120, the message is sent.

[0044] In this embodiment, an Internet Protocol message header can be added to the data message through the AS originating node (i.e., the source node) where the source address prefix is ​​located. The Internet Protocol can adopt IPV6. The extended header of the message header carries source address verification SAV information. The source address verification SAV information can be understood as valid SAV source address prefix information. The SAV information is used to instruct the node receiving the message to verify the source address related information of the message, so that the IPv6 message carrying the source address verification SAV information is forwarded / redirected, and the data message that does not comply with the source address verification SAV information is discarded to protect the IPV6 network from deceptive traffic or becoming the target of network attacks.

[0045] In one embodiment, the SAV information is encapsulated in a Hop-by-Hop (HBH) extension header or a Destination Options Header (DOH) extension header of the Internet Protocol.

[0046] In this embodiment, depending on different application scenarios, SAV information can be encapsulated using the IPv6 HBH extension header or DOH. For example, to enable intermediate forwarding nodes to identify the presence of SAV information, the IPv6 SAV extension header needs to carry a SAV service identifier. The length and value of the SAV service identifier can be uniformly specified in the standard or selected by the network operator and uniformly configured across the entire network.

[0047] In one embodiment, the SAV information includes at least one of the following:

[0048] SAV service identifier, IPv6 source address prefix, destination address prefix, source autonomous system (AS) information, destination AS information, and AS topology information.

[0049] In this embodiment, an IPv6 header can be added to a data packet by the encapsulation node. This header's extended header carries source address verification (SAV) information. This SAV information includes at least one of the following: a SAV service identifier, an IPv6 source address prefix, a destination address prefix, source autonomous system (AS) information, destination AS information, and AS topology information. This allows for IPv6 in-stream detection without altering the original data packet content. Figure 2 illustrates a standard IPv6 header format according to one embodiment. As shown in Figure 2, the IPv6 header contains a 4-bit version number, an 8-bit service level, a 20-bit flow label, a 16-bit payload length, an 8-bit lower-layer header indicator, an 8-bit hop limit, a 128-bit IPv6 source address, and a 128-bit IPv6 destination address. Furthermore, the IPv6 destination address is used for forwarding IPv6 packets, pointing to the decapsulation node; the IPv6 source address carries the source IPv6 address information. However, packets from the source AS are not verified to verify that this source address information is valid. Therefore, this application carries SAV-related information through the IPV6 extension header, which is used to verify the source address in the SAV path AS domain and the AS where the destination address prefix is ​​located.

[0050] In one embodiment, the SAV information includes a SAV service identifier; and the method further includes:

[0051] When the SAV service identifier is determined, the SAV service identifier corresponding to the source address is notified to nodes in the AS trust domain through BGP.

[0052] In this embodiment, once the SAV service identifier is determined, the encapsulation head node should flood the SAV service identifier corresponding to the source address to the entire network AS trust domain through the BGP routing protocol, so that the intermediate nodes and decapsulation nodes can build a route to the SAV service identifier. If the intermediate node or decapsulation node has an identification problem when processing this IPv6 extended message, the intermediate node and the decapsulation head node will ignore the SAV information of this IPV6 extended message and process it according to the normal forwarding mechanism of the destination address routing.

[0053] In one embodiment, the SAV information is encapsulated in an extension header of the message header using a Type Length Value (TLV); each type of SAV information corresponds to a TLV.

[0054] In this embodiment, after the SAV service identifier, the SAV information is encapsulated in TLV format, namely, the SAV option header type, SAV information length, and SAV information value. In addition, the IPv6 source address can carry one or more types of SAV option information at the same time. Each type of SAV information is carried by a TLV, and multiple types of SAV information are carried by multiple TLVs. The above-mentioned SAV information encapsulation method can avoid the problem in related technologies that the use of ACL or URPF mechanisms may cause IPv6 packets to be erroneously discarded. The IPv6 extension header is used to carry the SAV information. By reading the SAV capabilities of the network nodes in the AS domain, the SAV information carried in the IPv6 extension header is obtained, making it easier for network nodes across AS domains to process the SAV information.

[0055] In one embodiment, for the same SAV trust domain in a Border Gateway Protocol (BGP) AS cross-domain scenario, the SAV information is encapsulated in an HBH extension header of the Internet Protocol, and the SAV information is transmitted hop by hop between nodes in the SAV trust domain.

[0056] In one embodiment, for different SAV trust domains in a BGP AS cross-domain scenario, the SAV information is encapsulated in the DOH of the Internet Protocol, and the SAV information is transmitted end-to-end between nodes in different SAV trust domains.

[0057] FIG3 is a flow chart of a verification method provided by an embodiment, which can be applied to an intermediate node. As shown in FIG3 , the method provided by this embodiment includes steps 210 to 230 .

[0058] In 210, a message is received, wherein an extension header of a message header of the message carries source address verification SAV information.

[0059] In 220, the SAV service identifier is identified and the SAV information in the extension header is decapsulated.

[0060] In 230, the SAV verification function of the message is completed according to the SAV information.

[0061] In this embodiment, after receiving an IPv6 message carrying source address verification SAV information through an intermediate transmission AS domain edge node (i.e., an intermediate node), the SAV service identifier in the IPv6 extension header can be identified, and different types of SAV information in the IPv6 message can be parsed to complete the SAV source address verification function. In addition, the intermediate AS domain edge node reads the first type of SAV information and completes the first type of SAV information function by querying the SAV service identifier and the corresponding IPv6 source address prefix SAV information. Thereafter, if other types of SAV verification information are present, the second type of SAV information is read based on the information type and information length after the first type of SAV information, and the second type of SAV verification function is completed. This process is repeated until all SAV information is read and all SAV verification functions are completed, thereby verifying the validity of the source address prefix route. Furthermore, the specific SAV service identifier corresponding to the source address prefix route is used to conveniently carry the SAV trust domain information, effectively avoiding source address spoofing traffic and attacks on the network caused by the untrusted Internet.

[0062] In one embodiment, the SAV information includes at least one of the following:

[0063] SAV service identifier, IPv6 source address prefix, destination address prefix, source autonomous system (AS) information, destination AS information, and AS topology information.

[0064] In one embodiment, the SAV information is encapsulated in an extension header of the message header using a Type-Length-Value TLV; the method further includes:

[0065] Each type of SAV information in the message is determined according to the SAV service identifier, SAV information type, SAV information length and SAV information value in the extended header.

[0066] FIG4 is a flow chart of a message processing method provided by another embodiment, which can be applied to a destination node. As shown in FIG4 , the method provided by this embodiment includes steps 310 to 340 .

[0067] In 310, a message is received, wherein an extension header of a message header of the message carries source address verification (SAV) information.

[0068] In 320, the SAV service identifier is identified and the SAV information in the extension header is decapsulated.

[0069] In 330, the SAV verification function of the message is completed according to the SAV information.

[0070] In 340, the message header is stripped off to obtain a message without the message header.

[0071] In this embodiment, after receiving an IPv6 message carrying SAV information through the destination AS domain peer node (i.e., the destination node) where the destination address prefix is ​​located, the SAV service identifier can be identified, the SAV information in the extension header can be decapsulated, and the SAV verification function of the message can be completed according to the SAV information. After the destination AS domain node where the destination address prefix is ​​located reads out all SAV information and completes all SAV verification functions, the outer IPv6 message header containing the SAV information is stripped off, and the original data message is restored to realize the validity verification of the source address prefix route. The specific SAV service identifier corresponding to the source address prefix route can be used to realize the convenient carrying of the SAV trust domain information, effectively avoiding the source address spoofing traffic and attacks on the network caused by the untrustworthy Internet.

[0072] In one embodiment, the SAV information includes at least one of the following:

[0073] SAV service identifier, IPv6 source address prefix, destination address prefix, source autonomous system (AS) information, destination AS information, and AS topology information.

[0074] In one embodiment, the SAV information is encapsulated in an extension header of the message header using a Type-Length-Value TLV; the method further includes:

[0075] Each type of SAV information in the message is determined according to the SAV service identifier, SAV information type, SAV information length and SAV information value in the extended header.

[0076] The data transmission method is exemplified below through specific embodiments.

[0077] Example 1

[0078] There are some mechanisms that can solve some of the Internet's source address verification problems. The IETF (Internet Engineering Task Force) Internet Task Group SAVNET (Source Address Validation in Intra-domain and Inter-domain Networks) Intra-domain and Inter-domain Source Address Validation Working Group was established in 2022 to discuss the definition of new SAV functions, architectures, and solutions when intra-domain / inter-domain SAV mechanisms (such as URPF) cannot meet SAV requirements well. This application is based on the analysis of the SAV problem in the draft draft-wu-savnet-inter-domain-problem-statement on the SAV problem of BGP across AS domains submitted by IETF SAVNET, and proposes a method for the router data plane to implement verification of the true source address of packet data messages to protect the network from spoofed traffic or becoming the target of network attacks.

[0079] This embodiment provides an IPV6 HBH solution application. Figure 5 is a schematic diagram of an AS topology of the same SAV trust domain provided by an embodiment.

[0080] As shown in Figure 5, AS4 has four interfaces: Int.1 connects to AS1, Int.2 connects to AS2, Int.3 connects to AS3, and Int.4 connects to AS3. The arrows in the figure represent the customer relationships between ASs. AS1 and AS2 are providers of AS4, and their customer relationship is a customer-provider (C2P) relationship. Similarly, AS4 is a provider of AS3, and their customer relationship is also a C2P relationship. AS1 and AS2 have a provider-provider (P2P) relationship.

[0081] The valid inbound interface for the route prefix P1 originating from AS1 to AS4 is Int.1, and the inbound direction for P1 is Provider. The valid inbound interface for the route prefix P2 originating from AS2 to AS4 is Int.2, and the inbound direction for P2 is Provider. The valid inbound interface for the route prefix P3 originating from AS3 to AS4 is Int.3, and the inbound direction for P3 is Customer.

[0082] The effective inbound interface for the routing prefix P4 originating from AS3 to reach AS4 is Int.4, and the inbound direction of P4 is Customer.

[0083] The effective inbound interface for the routing prefix P3 originating from AS3 to reach AS1 is Int.5, and the AS list that the P3 prefix passes through is [AS4,AS3].

[0084] The effective inbound interface for the routing prefix P4 originating from AS3 to reach AS2 is Int.6, and the AS list that the P4 prefix passes through is [AS4,AS3].

[0085] When AS1 receives a datagram from AS3 with source prefix P3 and destination prefix P1, it verifies that the forwarding path for this datagram is AS3-AS4-AS1, with the inbound interface being Int.5. Upon receiving this datagram, AS1 notifies AS3, which routes prefix P3, carries SAV-specific information, and forwards the datagram along a valid path to AS1, which routes prefix P1.

[0086] 1. Message encapsulation

[0087] This embodiment involves encapsulation of first-type SAV option information and second-type SAV option information. The SAV option information is carried via the HBH extension header of IPv6.

[0088] The first type of SAV option information is used to carry the necessary routing information for the pre-allocated SAV source address prefix. It includes first type SAV option type information, option length information, and SAV option-specific information. The SAV option-specific information includes the SAV ID, SAV source address prefix information, SAV destination address prefix information, SAV source AS information, SAV destination AS information, AS topology information, AS edge router node information and inbound interface information of the AS, and optional checksum information.

[0089] The AS topology information is used to identify the AS domain information through which the SAV source address prefix is ​​routed, and is used to carry the effective SAV routing information.

[0090] The SAV service identifier refers to a specific source address prefix route. In order to determine the validity of this source address prefix route, this source address prefix + source AS number + the inbound port information of the AS where the destination route prefix is ​​located constitutes the key index of this source address prefix route. The source AS and the passing AS triggered by this source address prefix route form the trust domain of this source address prefix. In order to ensure the validity of the source address verification, it is necessary to form the same SAV trust identifier between the AS domains, which can be achieved by assigning a specific SAV service identifier ID to a source address prefix route. The generation rule of the SAV service identifier ID is calculated based on the source address prefix route of the source address prefix + source AS number + the inbound port of the AS where the destination route prefix is ​​located. Figure 6 is a schematic diagram of a SAV first option type encapsulation provided by an embodiment. As shown in Figure 6,

[0091] Source address prefix: The field length is 32 bits, used to encapsulate the routing source address prefix information of the originating router. Destination address prefix: The field length is 32 bits, used to encapsulate the routing destination address prefix information of the router.

[0092] Checksum: The field length is 32 bits. It is used during the SAV address forwarding process. After the routing node sets the checksum, it needs to verify the integrity of the SAV message.

[0093] AS list: This field has a variable length and is used to encapsulate the AS list information that a SAV message passes through during forwarding.

[0094] Local node ID: This field is 16 bits long and is used to identify the next-hop node, local node, or peer node.

[0095] Inbound interface ID: This field is 16 bits long and is used to identify the inbound interface information of the source address prefix packet of the next-hop node / local node / peer node.

[0096] The second type of SAV option information is used to carry the necessary information for tracing the actual SAV source address prefix route. It includes the second type of SAV option type information, option length information, and SAV option-specific information. The SAV option-specific information includes the SAV ID, SAV source address prefix information, SAV destination address prefix information, AS topology information, and information about the transit edge router node and its inbound interface in the AS. Figure 7 is a schematic diagram of a SAV second option type encapsulation provided in one embodiment.

[0097] 2. Data processing flow

[0098] 1) AS3 encapsulates the SAV HBH Option type and, based on the SAV predetermined route, encapsulates the SAV service identifier, SAV first type information, and SAV second type information.

[0099] 2) The edge routing node where the AS3 source address prefix P3 is located encapsulates the source address prefix P3, the destination address prefix P1, and the AS3 information where P3 is located into SAV type 1 information. It also encapsulates P3's next hop node ID and inbound interface Int.3 information into SAV type 2 information.

[0100] 3) After AS4 receives the SAV message with source address prefix P3 and destination address prefix P1 from AS3, based on its ability to parse and support SAV ID, it adds AS4 information and the inbound node ID and inbound interface ID of the next hop AS1 to the SAV type 1 extension header encapsulation; and adds information about the edge nodes passed by this AS and the inbound interface information from AS3 to the SAV type 2 information.

[0101] 4) AS1 receives the data packet with source address prefix P3 and destination address prefix P1 from AS4. After verifying its inbound interface information and the SAV topology of the AS it passes through and the actual inbound interface, AS1 decapsulates the SAV packet and proceeds to the next step according to the routing policy.

[0102] If, in this embodiment, AS4 is a non-trusted domain that does not recognize the SAV capability, AS4 does not process the message from AS1, and forwards or discards it according to the normal routing policy.

[0103] Example 2

[0104] This embodiment provides an IPV6 DOH solution application. Figure 8 is a schematic diagram of an AS topology of different SAV trust domains provided by an embodiment.

[0105] As shown in Figure 8, when AS1 receives a data packet from AS3 with source prefix P3 and destination prefix P1, this packet may pass through AS4, AS3, and other ASs. These AS4 and AS3 may or may not support SAV capability negotiation and verification. In this case, an end-to-end SAV verification scheme can be used. This ignores processing at intermediate transit nodes and focuses only on the source and destination ASs for source prefix P3 and the inbound interface Int.5 of the node containing the destination prefix. Upon receiving this packet, the destination AS1 must notify AS3, which contains the routing prefix P3, carry SAV-specific information, and send the data packet along a valid path to AS1, which contains the destination prefix P1.

[0106] 1. Message encapsulation

[0107] This embodiment relates to the third type of SAV option information encapsulation. The SAV option information is carried through the DOH extension header of IPv6.

[0108] The third type of SAV option information is used to carry the necessary information for end-to-end routing of SAV source address prefixes. It includes third-type SAV option type information, option length information, and SAV option-specific information. The SAV option-specific information includes the SAV ID, SAV source address prefix information, SAV destination address prefix information, SAV source AS information, SAV destination AS information, and the inbound edge router node information and inbound interface information for the AS containing the destination address prefix. Figure 9 is a schematic diagram of a SAV third option type message encapsulation provided by one embodiment.

[0109] In addition to encapsulating the source address prefix and the destination address prefix, this message also needs to carry the AS information of the source address prefix and the destination address prefix, as well as the ID of the peer node where the destination prefix AS is located and the ID of its inbound interface.

[0110] 2. Data processing flow

[0111] 1) AS3 encapsulates the SAV Destination Option Header and, based on the SAV end-to-end routing settings, encapsulates the SAV service identifier and SAV third type information.

[0112] 2) The edge routing node where the AS3 source address prefix P3 is located encapsulates the source address prefix P3, the destination address prefix P1, the AS3 information where P3 is located, and the peer node ID and inbound interface Int.5 information where P3's destination address prefix P1 is located into the SAV third type message.

[0113] 3) After AS4 receives the SAV message with source address prefix P3 and destination address prefix P1 from AS3, it does not parse the SAV information payload and forwards it to the next hop AS1 according to the routing FIB table entry of destination address prefix P1.

[0114] 4) AS1 receives the data packet with source address prefix P3 and destination address prefix P1 from AS4. After verifying its inbound interface information and the SAV topology of the AS it passes through and the actual inbound interface, AS1 decapsulates the SAV packet and proceeds to the next step according to the routing policy.

[0115] The present application also provides a message processing device. FIG10 is a schematic diagram of the structure of a message processing device provided by an embodiment. As shown in FIG10, the decoding device includes:

[0116] The adding module 410 is configured to add an Internet Protocol message header to the message, and the extended header of the message header carries source address verification SAV information, and the SAV information is used to instruct the node receiving the message to verify the source address related information of the message; the sending module 420 is configured to send the message.

[0117] The message processing device of this embodiment is based on adding an Internet Protocol message header to the message. The extended header of the message header carries source address verification SAV information. It can directly verify the validity of the source address prefix route through Internet Protocol message parsing, and conveniently carry the SAV trust domain information through the specific SAV service identifier corresponding to the source address prefix route, effectively avoiding source address spoofing traffic and attacks on the network caused by the untrustworthy Internet.

[0118] In one embodiment, the SAV information is encapsulated in a hop-by-hop HBH extension header or an option extension header DOH of the Internet protocol.

[0119] In one embodiment, the SAV information includes at least one of the following:

[0120] SAV service identifier, IPv6 source address prefix, destination address prefix, source autonomous system (AS) information, destination AS information, and AS topology information.

[0121] In one embodiment, the SAV information includes a SAV service identifier; and the method further includes:

[0122] When the SAV service identifier is determined, the SAV service identifier corresponding to the source address is notified to nodes in the AS trust domain through BGP.

[0123] In one embodiment, the SAV information is encapsulated in an extension header of the message header using a type-length-value TLV; each type of SAV information corresponds to one TLV.

[0124] In one embodiment, for the same SAV trust domain in a Border Gateway Protocol (BGP) AS cross-domain scenario, the SAV information is encapsulated in an HBH extension header of the Internet Protocol, and the SAV information is transmitted hop by hop between nodes in the SAV trust domain.

[0125] In one embodiment, for different SAV trust domains in a BGP AS cross-domain scenario, the SAV information is encapsulated in the DOH of the Internet Protocol, and the SAV information is transmitted end-to-end between nodes in different SAV trust domains.

[0126] The message processing device proposed in this embodiment and the message processing method proposed in the above embodiment belong to the same concept. For technical details not fully described in this embodiment, please refer to any of the above embodiments, and this embodiment has the same effect as the message processing method.

[0127] The present application also provides a verification device. FIG11 is a schematic diagram of the structure of a verification device provided by an embodiment. As shown in FIG11, the verification device includes:

[0128] The receiving module 510 is configured to receive a message, wherein the extended header of the message header carries source address verification SAV information; the identifying module 520 is configured to identify the SAV service identifier and decapsulate the SAV information in the extended header; the verifying module 530 is configured to complete the SAV verification function of the message according to the SAV information.

[0129] The verification device of this embodiment verifies the validity of the source address prefix routing based on the source address verification SAV information carried in the extended header of the message header of the received message, and conveniently carries the SAV trust domain information through the specific SAV service identifier corresponding to the source address prefix routing, effectively avoiding source address spoofing traffic and attacks on the network caused by the untrustworthy Internet.

[0130] In one embodiment, the SAV information includes at least one of the following:

[0131] SAV service identifier, IPv6 source address prefix, destination address prefix, source autonomous system (AS) information, destination AS information, and AS topology information.

[0132] In one embodiment, the SAV information is encapsulated in an extension header of the message header using a Type-Length-Value TLV; the method further includes:

[0133] Each type of SAV information in the message is determined according to the SAV service identifier, SAV information type, SAV information length and SAV information value in the extended header.

[0134] The verification device proposed in this embodiment and the verification method proposed in the above embodiment have the same concept. For technical details not fully described in this embodiment, please refer to any of the above embodiments. This embodiment has the same effect as the verification method.

[0135] The present application also provides a message processing device. FIG12 is a schematic diagram of the structure of a message processing device provided by an embodiment. As shown in FIG12, the decoding device includes:

[0136] The receiving module 610 is configured to receive a message, wherein the extended header of the message header carries source address verification SAV information; the identifying module 620 is configured to identify the SAV service identifier and decapsulate the SAV information in the extended header.

[0137] The verification module 630 is configured to complete the SAV verification function of the message according to the SAV information.

[0138] The acquisition module 640 is configured to strip the message header to obtain a message without the message header.

[0139] The message processing device of this embodiment verifies the validity of the source address prefix route based on the source address verification SAV information carried in the extended header of the message header of the received message, and conveniently carries the SAV trust domain information through the specific SAV service identifier corresponding to the source address prefix route, effectively avoiding source address spoofing traffic and attacks on the network caused by the untrustworthy Internet.

[0140] In one embodiment, the SAV information includes at least one of the following:

[0141] SAV service identifier, IPv6 source address prefix, destination address prefix, source autonomous system (AS) information, destination AS information, and AS topology information.

[0142] In one embodiment, the SAV information is encapsulated in an extension header of the message header using a Type-Length-Value TLV; the method further includes:

[0143] Each type of SAV information in the message is determined according to the SAV service identifier, SAV information type, SAV information length and SAV information value in the extended header.

[0144] The message processing device proposed in this embodiment and the message processing method proposed in the above embodiment belong to the same concept. For technical details not fully described in this embodiment, please refer to any of the above embodiments, and this embodiment has the same effect as the message processing method.

[0145] The present application also provides a source node. Figure 13 is a schematic diagram of the hardware structure of a source node provided in one embodiment. As shown in Figure 13, the source node provided in the present application includes a processor 710 and a memory 720. The processor 710 in the source node can be one or more, and Figure 13 uses one processor 710 as an example. The memory 720 is configured to store one or more programs. The one or more programs are executed by the one or more processors 710, so that the one or more processors 710 implement the message processing method described in the embodiment of the present application.

[0146] The source node further includes: a communication device 730 , an input device 740 and an output device 750 .

[0147] The processor 710, memory 720, communication device 730, input device 740 and output device 750 in the source node may be connected via a bus or other means. FIG13 takes the bus connection as an example.

[0148] The input device 740 may be used to receive input digital or character information and generate key signal input related to user settings and function control of the electronic device. The output device 750 may include a display device such as a display screen.

[0149] The communication device 730 may include a receiver and a transmitter. The communication device 730 is configured to perform information transmission and reception communication according to the control of the processor 710.

[0150] The memory 720, as a computer-readable storage medium, can be configured to store software programs, computer executable programs, and modules, such as program instructions / modules corresponding to the message processing method described in the embodiment of the present application (for example, the adding module 410 and the sending module 420 in the message processing device). The memory 720 may include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required for at least one function; and the data storage area may store data created according to the use of the communication node. In addition, the memory 720 may include a high-speed random access memory and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other non-volatile solid-state storage device. In some instances, the memory 720 may include a memory remotely arranged relative to the processor 710, and these remote memories may be connected to the communication node via a network. Examples of the above-mentioned networks include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0151] The present application also provides an intermediate node. Figure 14 is a schematic diagram of the hardware structure of an intermediate node provided in one embodiment. As shown in Figure 14, the intermediate node provided in the present application includes a processor 810 and a memory 820. The processor 810 in the source node can be one or more, and Figure 14 uses one processor 810 as an example. The memory 820 is configured to store one or more programs. The one or more programs are executed by the one or more processors 810, so that the one or more processors 810 implement the verification method described in the embodiment of the present application.

[0152] The source node further includes: a communication device 830 , an input device 840 and an output device 850 .

[0153] The processor 810, memory 820, communication device 830, input device 840 and output device 850 in the source node may be connected via a bus or other means. FIG14 takes the bus connection as an example.

[0154] The input device 840 may be used to receive input digital or character information and generate key signal input related to user settings and function control of the electronic device. The output device 850 may include a display device such as a display screen.

[0155] The communication device 830 may include a receiver and a transmitter. The communication device 830 is configured to perform information transmission and reception communication according to the control of the processor 810.

[0156] The memory 820, as a computer-readable storage medium, can be configured to store software programs, computer executable programs, and modules, such as the program instructions / modules corresponding to the verification method described in the embodiment of the present application (for example, the addition receiving module 510, the identification module 520, and the verification module 530 in the verification device). The memory 820 may include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required for at least one function; and the data storage area may store data created according to the use of the communication node. In addition, the memory 820 may include a high-speed random access memory and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other non-volatile solid-state storage device. In some instances, the memory 820 may include a memory remotely arranged relative to the processor 810, and these remote memories may be connected to the communication node via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and a combination thereof.

[0157] The present application also provides a destination node. Figure 15 is a schematic diagram of the hardware structure of a destination node provided in one embodiment. As shown in Figure 15, the destination node provided in the present application includes a processor 910 and a memory 920. The processor 910 in the source node can be one or more, and Figure 15 uses one processor 910 as an example. The memory 920 is configured to store one or more programs. The one or more programs are executed by the one or more processors 910, so that the one or more processors 910 implement the message processing method described in the embodiment of the present application.

[0158] The source node further includes: a communication device 930 , an input device 940 and an output device 950 .

[0159] The processor 910, memory 920, communication device 930, input device 940 and output device 950 in the source node may be connected via a bus or other means. FIG15 takes the bus connection as an example.

[0160] The input device 940 may be used to receive input digital or character information and generate key signal input related to user settings and function control of the electronic device. The output device 950 may include a display device such as a display screen.

[0161] The communication device 930 may include a receiver and a transmitter. The communication device 930 is configured to perform information transmission and reception communication according to the control of the processor 910.

[0162] The memory 920, as a computer-readable storage medium, can be configured to store software programs, computer executable programs, and modules, such as program instructions / modules corresponding to the message processing method described in the embodiment of the present application (for example, the receiving module 610, the identification module 620, the verification module 630, and the acquisition module 640 in the message processing device). The memory 920 may include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required for at least one function; and the data storage area may store data created according to the use of the communication node. In addition, the memory 920 may include a high-speed random access memory and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other non-volatile solid-state storage device. In some instances, the memory 920 may include a memory remotely arranged relative to the processor 910, and these remote memories may be connected to the communication node via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and a combination thereof.

[0163] An embodiment of the present application also provides a message processing system. FIG16 is a structural diagram of a message processing system provided by an embodiment. As shown in FIG16 , the message processing system includes: the source node 10, the intermediate node 20 and the destination node 30 as described above.

[0164] In this embodiment, an Internet Protocol message header can be added to the data message through the AS originating node where the source address prefix is ​​located. The Internet Protocol can adopt IPV6. The extended header of the message header carries source address verification SAV information. The source address verification SAV information can be understood as valid SAV source address prefix information. The SAV information is used to instruct the node receiving the message to verify the source address related information of the message, so that the IPv6 message carrying the source address verification SAV information is forwarded / redirected, and the data message that does not comply with the source address verification SAV information is discarded to protect the IPV6 network from deceptive traffic or network attack targets.

[0165] The present application also provides a storage medium storing a computer program, which, when executed by a processor, implements the message processing and verification method described in any of the embodiments of the present application. The message processing method, applied to a source node, includes:

[0166] An Internet Protocol message header is added to the message, wherein an extended header of the message header carries source address verification SAV information, and the SAV information is used to instruct a node receiving the message to verify source address related information of the message; and the message is sent.

[0167] Alternatively, the verification method, applied to an intermediate node, includes:

[0168] Receive a message, wherein the extended header of the message header carries source address verification SAV information; identify the SAV service identifier, decapsulate the SAV information in the extended header; and complete the SAV verification function of the message according to the SAV information.

[0169] Alternatively, the message processing method, applied to the destination node, includes:

[0170] Receive a message, wherein an extension header of the message header carries source address verification SAV information; identify the SAV service identifier, decapsulate the SAV information in the extension header; complete the SAV verification function of the message according to the SAV information; strip the message header to obtain a message without the message header added.

[0171] The computer storage medium of the embodiment of the present application can adopt any combination of one or more computer-readable media.Computer-readable media can be computer-readable signal media or computer-readable storage media.Computer-readable storage media can be, for example, but not limited to: electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices or devices, or any combination of the above.Examples of computer-readable storage media (non-exhaustive list) include: electrical connection with one or more wires, portable computer disks, hard disks, random access memories (RAM), read-only memories (ROM), erasable programmable read-only memories (EPROM), flash memory, optical fibers, portable CD-ROMs, optical storage devices, magnetic storage devices, or any suitable combination of the above.Computer-readable storage media can be any tangible medium containing or storing a program, which can be used by an instruction execution system, device or device or used in combination with it.

[0172] A computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such a propagated data signal may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium that can transmit, propagate, or transport a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0173] The program code contained on the computer-readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wire, optical cable, radio frequency (RF), etc., or any suitable combination of the foregoing.

[0174] The computer program code for performing the operations of the present application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and also conventional procedural programming languages ​​such as "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as an independent software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computer (e.g., using an Internet service provider to connect via the Internet).

[0175] The above description is merely an exemplary embodiment of the present application and is not intended to limit the scope of protection of the present application.

[0176] It will be appreciated by those skilled in the art that the term user terminal covers any suitable type of wireless user equipment, such as a mobile phone, a portable data processing device, a portable web browser or a vehicle-mounted mobile station.

[0177] In general, various embodiments of the present application may be implemented in hardware or dedicated circuits, software, logic, or any combination thereof. For example, some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software that can be executed by a controller, microprocessor, or other computing device, although the present application is not limited thereto.

[0178] Embodiments of the present application may be implemented by executing computer program instructions by a data processor of a mobile device, for example, in a processor entity, or by hardware, or by a combination of software and hardware. The computer program instructions may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages.

[0179] The block diagram of any logical flow in the drawings of this application may represent program operations, or may represent interconnected logical circuits, modules and functions, or may represent a combination of program operations and logical circuits, modules and functions. A computer program may be stored on a memory. The memory may be of any type suitable for the local technical environment and may be implemented using any suitable data storage technology, such as but not limited to read-only memory (ROM), random access memory (RAM), optical storage devices and systems (digital versatile discs (DVD) or compact disks (CD), etc.). Computer-readable media may include non-transitory storage media. The data processor may be of any type suitable for the local technical environment, such as but not limited to a general-purpose computer, a special-purpose computer, a microprocessor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a programmable logic device (FPGA) and a processor based on a multi-core processor architecture.

Claims

1. A message processing method, applied to a source node, comprising: Adding an Internet Protocol message header to the message, wherein an extension header of the message header carries source address verification SAV information, wherein the SAV information is used to instruct a node receiving the message to verify source address related information of the message; Send the message.

2. The method according to claim 1, wherein: The SAV information is encapsulated in a hop-by-hop HBH extension header or an option extension header DOH of the Internet protocol.

3. The method according to claim 1, wherein: The SAV information includes at least one of the following: SAV service identifier, Internet Protocol version 6 IPv6 source address prefix, destination address prefix, source autonomous system AS information, destination AS information and AS topology information.

4. The method according to claim 1, wherein: The SAV information includes a SAV service identifier; the method further includes: When the SAV service identifier is determined, the SAV service identifier corresponding to the source address is notified to nodes in the AS trust domain via the Border Gateway Protocol BGP.

5. The method according to claim 2, wherein: The SAV information is encapsulated in the extension header of the message header using a type-length-value TLV; Each type of SAV information corresponds to one TLV.

6. The method according to claim 4, wherein: For the same SAV trust domain in a BGP AS cross-domain scenario, the SAV information is encapsulated in an HBH extension header of the Internet Protocol, and the SAV information is transmitted hop by hop between nodes in the SAV trust domain.

7. The method according to claim 1, wherein: For different SAV trust domains in a BGP AS cross-domain scenario, the SAV information is encapsulated in the DOH of the Internet Protocol, and the SAV information is transmitted end-to-end between nodes in different SAV trust domains.

8. A verification method, applied to an intermediate node, comprising: Receive a message, wherein an extension header of a message header of the message carries source address verification SAV information; Identify the SAV service identifier and decapsulate the SAV information in the extension header; The SAV verification function of the message is completed according to the SAV information.

9. The method according to claim 8, wherein: The SAV information includes at least one of the following: SAV service identifier, Internet Protocol version 6 IPv6 source address prefix, destination address prefix, source autonomous system AS information, destination AS information and AS topology information.

10. The method according to claim 8, wherein: The SAV information is encapsulated in the extension header of the message header using a type-length value TLV; The method further comprises: Each type of SAV information in the message is determined according to the SAV service identifier, the SAV information type, the SAV information length and the SAV information value in the extended header.

11. A message processing method, applied to a destination node, comprising: Receive a message, wherein an extension header of a message header of the message carries source address verification SAV information; Identify the SAV service identifier and decapsulate the SAV information in the extension header; Complete the SAV verification function of the message according to the SAV information; The message header is stripped off to obtain a message without the message header added.

12. The method according to claim 11, wherein: The SAV information includes at least one of the following: SAV service identifier, Internet Protocol version 6 IPv6 source address prefix, destination address prefix, source autonomous system AS information, destination AS information and AS topology information.

13. The method according to claim 11, wherein: The SAV information is encapsulated in the extension header of the message header using a type-length value TLV; The method further comprises: Each type of SAV information in the message is determined according to the SAV service identifier, SAV information type, SAV information length and SAV information value in the extended header.

14. A source node, comprising: memory, and at least one processor; The memory is configured to store at least one program; When the at least one program is executed by the at least one processor, the at least one processor implements the message processing method according to any one of claims 1 to 7.

15. An intermediate node, comprising: memory, and at least one processor; The memory is configured to store at least one program; When the at least one program is executed by the at least one processor, the at least one processor implements the verification method according to any one of claims 8 to 10.

16. A destination node, comprising: memory, and one or more processors; The memory is configured to store at least one program; When the at least one program is executed by the at least one processor, the at least one processor The device implements the message processing method as described in any one of claims 11 to 13.

17. A message processing system, comprising: The source node as claimed in claim 14, the intermediate node as claimed in claim 15 and the destination node as claimed in claim 16.

18. A computer-readable storage medium storing a computer program, wherein when the program is executed by a processor, the program implements the message processing method according to any one of claims 1 to 7, the verification method according to any one of claims 8 to 10, or the message processing method according to any one of claims 11 to 13.

Images