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

Abstract

The invention provides a message processing method, a message verification method, a node, a message processing system and a storage medium. According to the method, a message header of an internet protocol is added in a message, an extension header of the message header carries source address verification SAV information, and the SAV information is used for instructing a node receiving the message to verify source address related information of the message; and sending the message.

Description

Technical Field

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

[0002] The current implementation mechanism of the Internet routing system is a best-effort mechanism. The router forwards the packet data message to the receiver along the feasible optimal path through the destination address routing lookup in the routing table. Forged or false routing sources with non-real source addresses in packet data messages are not detected or filtered, which may lead to attacks on the Internet network. For the behavior of forging source addresses and attacking the network, the Internet lacks the authenticity verification of the source of data message sending to avoid network attacks. Summary of the invention

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

[0004] The present application embodiment provides a message processing method, which is applied to a source node, including:

[0005] Adding an Internet Protocol message header to the message, wherein an extension 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;

[0006] Send the message.

[0007] The present application embodiment provides a verification method, which is applied to an intermediate node, including:

[0008] Receive a message, wherein an extension header of a message header of the message carries source address verification SAV information;

[0009] Identify the SAV service identifier and decapsulate the SAV information in the extension header;

[0010] The SAV verification function of the message is completed according to the SAV information.

[0011] The present application embodiment provides a message processing method, which is applied to a destination node, including:

[0012] Receive a message, wherein an extension header of a message header of the message carries source address verification SAV information;

[0013] Identify the SAV service identifier and decapsulate the SAV information in the extension header;

[0014] Complete the SAV verification function of the message according to the SAV information;

[0015] The message header is stripped off to obtain a message without the message header added.

[0016] An embodiment of the present application also provides a source node, including: 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.

[0017] An embodiment of the present application also provides an intermediate node, including: 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.

[0018] An embodiment of the present application also provides a destination node, including: 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.

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

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

[0021] Figure 1 A flowchart of a message processing method provided by an embodiment;

[0022] Figure 2 A schematic diagram of a standard format of an IPv6 message header provided by an embodiment;

[0023] Figure 3 A flowchart of a verification method provided by an embodiment;

[0024] Figure 4 A flowchart of a message processing method provided by another embodiment;

[0025] Figure 5 A schematic diagram of an AS topology of the same SAV trust domain provided by an embodiment;

[0026] Figure 6 A schematic diagram of a SAV first option type package provided by an embodiment;

[0027] Figure 7 A schematic diagram of a SAV second option type package provided by an embodiment;

[0028] Figure 8 A schematic diagram of a different SAV trust domain AS topology provided by an embodiment;

[0029] Fig. 9 A schematic diagram of a SAV third option type message encapsulation provided by an embodiment;

[0030] Fig.10 A schematic diagram of the structure of a message processing device provided by an embodiment;

[0031] Fig.11 A schematic diagram of the structure of a verification device provided by an embodiment;

[0032] Fig.12 A schematic structural diagram of a message processing device provided in another embodiment;

[0033] Fig.13 A schematic diagram of the hardware structure of a source node provided by an embodiment;

[0034] Fig.14 A schematic diagram of the hardware structure of an intermediate node provided by an embodiment;

[0035] Fig.15 A schematic diagram of the hardware structure of a destination node provided by an embodiment;

[0036] Fig.16 A schematic diagram of the structure of a message processing system provided in one embodiment. DETAILED DESCRIPTION

[0037] The present application is described below in conjunction with the accompanying drawings and embodiments. It is to be understood that the specific embodiments described herein are only used to explain the present application, rather than to limit the present application. It should be noted that, in the absence of conflict, the embodiments in the present application and the features in the embodiments can be combined with each other arbitrarily. It should also be noted that, for ease of description, only the parts related to the present application rather than all structures are shown in the accompanying drawings.

[0038] The current Internet implementation is untrustworthy. Forging source addresses and attacking the network lacks authenticity verification of the source of the data message. To solve this problem, there are a series of technical circumventions, such as:

[0039] 1) Through the inbound / outbound access control list (ACL) mechanism, packets whose source addresses do not meet the filtering conditions are discarded. However, this technology requires manual configuration, and in the case of BGP across AS domains, a large number of routes are involved, and the implementation is not flexible.

[0040] 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 incorrect packet discarding due to incorrect source address filtering.

[0041] 3) The Feasible-Path Unicast Reverse Path Forwarding (FP-URPF) solution is more effective than strict URPF, but its applicable scenarios are greatly limited. It needs to strictly follow the same prefix route to be published to all neighboring ASs, or publish the aggregated route of the same prefix to all neighboring ASs, and can send specific prefix routes to specific ASs according to specific deployment requirements, which has high implementation complexity.

[0042] 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) table entry, which results in the problem of incorrect message forwarding.

[0043] The IETF SAVNET working group is currently discussing the issue of source address verification across autonomous systems (AS) of the Border Gateway Protocol (BGP), architecture, and solutions. Currently, only the draft of the issue has a certain industry consensus, and other aspects are still in the initial stage of standardization. For the BGP source address verification across AS domains, the following two issues need to be resolved:

[0044] 1) The source address prefix message comes from a real and trusted path;

[0045] 2) Perform scheduling processing such as forwarding / discarding / redirecting on source prefix packet data messages that meet / do not meet the source address prefix.

[0046] The present application provides a message processing and verification method, which 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 source address verification (SourceAddress Validation, SAV) service identifier corresponding to the source address prefix route, thereby effectively avoiding the attack on the network caused by the source address spoofing traffic caused by the current untrustworthy Internet.

[0047] Figure 1 FIG. 1 is a flow chart of a message processing method provided by an embodiment, and the method can be applied to a source node. Figure 1As shown, the method provided in this embodiment includes steps 110 to 120.

[0048] In step 110, an Internet Protocol message header is added to the message, and 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.

[0049] In step 120, the message is sent.

[0050] 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 network attack targets.

[0051] 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.

[0052] In this embodiment, according to different application scenarios, the SAV information can be encapsulated through the HBH extension header or DOH extension header of IPv6. For example, in order to enable the intermediate forwarding node to identify the existence of SAV information, the IPv6 SAV extension header needs to carry a SAV service identifier, and the length and value of the SAV service identifier can be uniformly specified in the standard or selected by the network operator for uniform configuration across the entire network.

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

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

[0055] In this embodiment, an IPv6 message header can be added to the data message through the encapsulation node, and the extended header of the message header carries source address verification SAV information, and the SAV information includes at least one of the following: SAV service identifier, IPv6 source address prefix, destination address prefix, source autonomous system AS information, destination AS information and AS topology information. The function of IPv6 flow detection can be realized without changing the original data message content. Figure 2 A schematic diagram of a standard format of an IPv6 message header provided by an embodiment. Figure 2 As shown, the IPv6 message 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 indication, an 8-bit hop limit, and a 128-bit IPv6 source address and a 128-bit IPv6 destination address. In addition, the IPv6 destination address is used to forward IPv6 messages, and the destination is the decapsulation node; the IPv6 source address is used to carry source IPv6 address information. However, whether this source address information is a message from a valid source AS is not verified. Therefore, the present application carries SAV-related information through an 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.

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

[0057] 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.

[0058] 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 routes to the SAV service identifier. If the intermediate node or decapsulation node has identification problems 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.

[0059] In one embodiment, the SAV information is encapsulated in an extension header of the message header using a type length value (TLV);

[0060] Each type of SAV information corresponds to one TLV.

[0061] In this embodiment, after the SAV service identifier, the SAV information is encapsulated in TLV format, namely, the SAV option header type, the SAV information length and the 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 one TLV, and multiple types of SAV information are carried by multiple TLVs. The above-mentioned SAV information encapsulation method can avoid the problem in the prior art that the use of ACL or URPF mechanism may cause the IPv6 message to be erroneously discarded, and the IPv6 extension header is used to carry the SAV information. By reading the SAV capability of the network node in the AS domain, the SAV information carried by the IPv6 extension header is obtained, which facilitates the processing of the SAV information by the network nodes across the AS domain.

[0062] 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.

[0063] 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.

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

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

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

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

[0068] In this embodiment, after receiving the IPv6 message carrying the source address verification SAV information through the intermediate transmission AS domain edge node (i.e., the 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 queries the SAV service identifier and the corresponding IPv6 source address prefix SAV information, and then takes out the first type of SAV information and completes the first type of SAV information function. After that, if other types of SAV verification information exist at the same time, the second type of SAV information is taken out according to the information type and information length after the first type of SAV information, and the second type of SAV verification function is completed. And so on, until all SAV information is taken out and all SAV verification functions are completed, the validity verification of the source address prefix route is realized, and the SAV trust domain information is conveniently carried through the specific SAV service identifier corresponding to the source address prefix route, which effectively avoids the attack on the network caused by the source address spoofing traffic caused by the current untrustworthy Internet.

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

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

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

[0072] The method further comprises:

[0073] 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.

[0074] Figure 4 FIG. 1 is a flow chart of a message processing method provided by an embodiment, and the method can be applied to a destination node. Figure 4 As shown, the method provided in this embodiment includes steps 310 to 340.

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

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

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

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

[0079] In this embodiment, after receiving an IPv6 message carrying SAV information through a destination AS domain peer node (i.e., a destination node) where the destination address prefix is ​​located, the SAV service identifier is identified, the SAV information in the extension header is decapsulated, and the SAV verification function of the message is completed according to the SAV information. After the destination AS domain node where the destination address prefix is ​​located takes 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 verify the validity of the source address prefix route. By using a specific SAV service identifier corresponding to the source address prefix route, the SAV trust domain information can be conveniently carried, effectively avoiding attacks on the network caused by source address spoofing traffic due to the current untrustworthy Internet.

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

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

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

[0083] The method further comprises:

[0084] 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.

[0085] The data transmission method is exemplarily described below through specific embodiments.

[0086] Embodiment 1

[0087] There are also some existing mechanisms that can solve some Internet 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 the existing intra-domain / inter-domain SAV mechanisms (such as URPF) cannot meet SAV requirements well. This application is based on the analysis of the current SAV problem in the BGP cross-AS domain SAV problem draft draft-wu-savnet-inter-domain-problem-statement 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.

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

[0089] like Figure 5 As shown in the figure, AS4 has 4 interfaces, namely Int.1 connected to AS1, Int.2 connected to AS2, Int.3 connected to AS3, and Int.4 connected to AS4. The arrows in the figure represent the customer relationship between ASs. AS1 and AS2 are the providers of AS4, and their customer relationship is customer-provider C2P; similarly, AS4 is the provider of AS3, and its customer relationship is also C2P; AS1 and AS2 are provider-provider P2P.

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

[0091] The effective inbound interface of the routing prefix P4 originating from AS3 and reaching AS4 is Int.4, and the inbound direction of P4 is Customer.

[0092] The effective inbound interface of the routing prefix P3 originating from AS3 to AS1 is Int.5, and the list of ASs that the P3 prefix passes through is [AS4,AS3].

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

[0094] When AS1 receives a datagram with source address prefix P3 and destination address prefix P1 from AS3, it needs to verify whether the forwarding path of this message is through AS3-AS4-AS1, and the inbound interface is Int.5. When AS1 receives this message, it needs to notify AS3 where the routing prefix P3 is located, carry SAV specific information, and send this datagram to AS1 where the destination address prefix P1 is located along the valid path.

[0095] 1. Message encapsulation

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

[0097] The first type of SAV option information is used to carry necessary information for routing 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 SAV ID, SAV source address prefix information, SAV destination address prefix information, SAV source AS information, SAV destination AS information, AS topology information, AS transit edge router node information and inbound interface information, and optional checksum information.

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

[0099] 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 effectiveness 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 certain 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 FIG. 1 is a schematic diagram of a SAV first option type package provided by an embodiment. Figure 6 As shown,

[0100] Source address prefix: The field length is 32 bits and is used to encapsulate the routing source address prefix information of the originating router.

[0101] Destination address prefix: The field length is 32 bits, used to encapsulate the router's routing destination address prefix information

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

[0103] AS list: The field length is variable and is used to encapsulate the AS list information that the SAV message passes through during forwarding. Local node ID: The field length is 16 bits and is used to identify the next hop node / local node / peer node information.

[0104] Inbound interface ID: The field length is 16 bits and is used to identify the inbound interface information of the source address prefix message of the next hop node / local node / peer node.

[0105] The second type of SAV option information is used to carry the necessary information for tracking 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 SAV ID, SAV source address prefix information, SAV destination address prefix information, AS topology information, AS edge router node information and inbound interface information of the AS. Figure 7 A schematic diagram of a SAV second option type package provided by an embodiment.

[0106] 2. Data processing flow

[0107] 1) AS3 encapsulates the SAV HBH Option type, and encapsulates the SAV service identifier, SAV first type information and SAV second type information according to the SAV predetermined route.

[0108] 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 the first type of SAV information. At the same time, it encapsulates the next hop node ID of P3 and the inbound interface Int.3 information into the second type of SAV information.

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

[0110] 4) AS1 receives the data packet with source address prefix P3 and destination address prefix P1 from AS4, verifies its inbound interface information, and if the SAV topology of the AS and the actual inbound interface is credible, decapsulates the SAV packet and performs the next step according to the routing policy.

[0111] 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 common routing policy.

[0112] Embodiment 2

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

[0114] like Figure 8 As shown in the figure, when AS1 receives a data packet with source address prefix P3 and destination address prefix P1 from AS3, this packet may pass through AS4, AS3, etc. Here, AS4 and AS3 may or may not support SAV capability negotiation and verification. At this time, an end-to-end SAV verification scheme can be used, that is, it does not care about the processing of intermediate transit nodes, but only pays attention to the source AS and destination AS of the source address prefix P3, and the inbound interface Int.5 of the node where the destination address prefix is ​​located. When the destination AS1 receives this packet, it needs to notify AS3 where the routing prefix P3 is located, carry SAV specific information, and follow the valid path to send this data packet to AS1 where the destination address prefix P1 is located.

[0115] 1. Message encapsulation

[0116] 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.

[0117] The third type of SAV option information is used to carry the necessary information for end-to-end routing of the SAV source address prefix. It includes the third type of SAV option type information, option length information, and SAV option specific information. The SAV option specific information includes 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 of the AS where the destination address prefix is ​​located. Fig. 9 A schematic diagram of a SAV third option type message encapsulation provided by an embodiment.

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

[0119] 2. Data processing flow

[0120] 1) AS3 encapsulates the SAV Destination Option Header and encapsulates the SAV service identifier and SAV third type information according to the SAV end-to-end routing settings.

[0121] 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 the destination address prefix P1 of P3 is located into the SAV third type message.

[0122] 3) AS4 does not parse the SAV message received from AS3 with source address prefix P3 and destination address prefix P1.

[0123] The SAV information payload is forwarded to the next hop AS1 according to the routing FIB entry of the destination address prefix P1.

[0124] 4) AS1 receives a data packet with source address prefix P3 and destination address prefix P1 from AS4, verifies its inbound interface information, and decapsulates the SAV packet if the SAV topology of the AS and the actual inbound interface is credible.

[0125] And proceed to the next step according to the routing policy.

[0126] The embodiment of the present application also provides a message processing device. Fig.10 FIG. 1 is a schematic diagram of a message processing device provided by an embodiment. Fig.10 As shown, the decoding device comprises:

[0127] An adding module 410 is configured to add an Internet Protocol message header to a 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;

[0128] The sending module 420 is configured to send the message.

[0129] 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. The validity of the source address prefix route can be verified directly through Internet Protocol message parsing, and the SAV trust domain information can be conveniently carried through the specific SAV service identifier corresponding to the source address prefix route, which effectively avoids the attack on the network caused by source address spoofing traffic caused by the current untrustworthy Internet.

[0130] 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.

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

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

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

[0134] 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.

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

[0136] Each type of SAV information corresponds to one TLV.

[0137] 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.

[0138] 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.

[0139] The message processing device proposed in this embodiment and the message processing method proposed in the above embodiment belong to the same inventive concept. The technical details not fully described in this embodiment can be referred to any of the above embodiments, and this embodiment has the same beneficial effects as the message processing method.

[0140] The embodiment of the present application also provides a verification device. Fig.11 FIG. 1 is a schematic diagram of a verification device provided by an embodiment. Fig.11 As shown, the verification device includes:

[0141] The receiving module 510 is configured to receive a message, wherein an extension header of a message header of the message carries source address verification SAV information;

[0142] An identification module 520, configured to identify a SAV service identifier and decapsulate the SAV information in the extension header;

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

[0144] The verification 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 attacks on the network caused by source address spoofing traffic caused by the current untrustworthy Internet.

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

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

[0147] 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:

[0148] 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.

[0149] The verification device proposed in this embodiment and the verification method proposed in the above embodiment belong to the same inventive concept. The technical details not fully described in this embodiment can be referred to any of the above embodiments, and this embodiment has the same beneficial effects as the verification method.

[0150] The embodiment of the present application also provides a message processing device. Fig.12FIG. 1 is a schematic diagram of a message processing device provided by an embodiment. Fig.12 As shown, the decoding device comprises:

[0151] The receiving module 610 is configured to receive a message, wherein an extension header of a message header of the message carries source address verification SAV information;

[0152] The identification module 620 is configured to identify the SAV service identifier and decapsulate the SAV information in the extension header.

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

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

[0155] 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, thereby effectively avoiding attacks on the network caused by source address spoofing traffic caused by the current untrustworthy Internet.

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

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

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

[0159] The method further comprises:

[0160] 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.

[0161] The message processing device proposed in this embodiment and the message processing method proposed in the above embodiment belong to the same inventive concept. The technical details not fully described in this embodiment can be referred to any of the above embodiments, and this embodiment has the same beneficial effects as the message processing method.

[0162] The embodiment of the present application also provides a source node. Fig.13 A schematic diagram of the hardware structure of a source node provided by an embodiment, such as Fig.13As shown, the source node provided by the present application includes a processor 710 and a memory 720; the processor 710 in the source node may be one or more, Fig.13 A processor 710 is taken 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 as described in the embodiment of the present application.

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

[0164] 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. Fig.13 The example of connecting through bus is taken in the following.

[0165] 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.

[0166] 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.

[0167] The memory 720, as a computer-readable storage medium, may 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 (e.g., the adding module 410 and the sending module 420 in the message processing device). The memory 720 may include a storage program area and a storage data area, wherein the storage program area may store an operating system, an application required for at least one function; the storage data area may store data created according to the use of the communication node, etc. 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 further 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 network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0168] The embodiment of the present application also provides an intermediate node. Fig.14 A schematic diagram of the hardware structure of an intermediate node provided by an embodiment is shown in FIG. Fig.14 As shown, the intermediate node provided by the present application includes a processor 810 and a memory 820; the processor 810 in the source node may be one or more, Fig.14 A processor 810 is taken 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 as described in the embodiment of the present application.

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

[0170] 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. Fig.14 The example of connecting through bus is taken in the following.

[0171] 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.

[0172] 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.

[0173] The memory 820, as a computer-readable storage medium, may be configured to store software programs, computer executable programs, and modules, such as program instructions / modules corresponding to the verification method described in the embodiment of the present application (e.g., the adding receiving module 510, the identification module 520, and the verification module 530 in the verification device). The memory 820 may include a storage program area and a storage data area, wherein the storage program area may store an operating system, an application required for at least one function; the storage data area may store data created according to the use of the communication node, etc. 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 further 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 combinations thereof.

[0174] The embodiment of the present application also provides a destination node. Fig.15 A schematic diagram of the hardware structure of a destination node provided by an embodiment, such as Fig.15 As shown, the destination node provided by the present application includes a processor 910 and a memory 920; the processor 910 in the source node may be one or more, Fig.15A processor 910 is taken 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 as described in the embodiment of the present application.

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

[0176] 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. Fig.15 The example of connecting through bus is taken in the following.

[0177] 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.

[0178] 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.

[0179] The memory 920, as a computer-readable storage medium, may 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 (e.g., 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 storage program area and a storage data area, wherein the storage program area may store an operating system, an application required for at least one function; the storage data area may store data created according to the use of the communication node, etc. 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 further 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 combinations thereof.

[0180] The present application also provides a message processing system. Fig.16 A schematic diagram of the structure of a message processing system provided by an embodiment is shown in FIG. Fig.16 As shown, the message processing system includes: the source node 10, the intermediate node 20 and the destination node 30 as mentioned above.

[0181] 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.

[0182] The embodiment of the present application further provides a storage medium, wherein the storage medium stores a computer program, and when the computer program is executed by a processor, the message processing and verification method described in any one of the embodiments of the present application is implemented. The message processing method, applied to a source node, comprises:

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

[0184] Send the message.

[0185] Or, the verification method, applied to the intermediate node, includes:

[0186] Receive a message, wherein an extension header of a message header of the message carries source address verification SAV information;

[0187] Identify the SAV service identifier and decapsulate the SAV information in the extension header;

[0188] The SAV verification function of the message is completed according to the SAV information.

[0189] Or, the message processing method, applied to the destination node, includes:

[0190] Receive a message, wherein an extension header of a message header of the message carries source address verification SAV information;

[0191] Identify the SAV service identifier and decapsulate the SAV information in the extension header;

[0192] Complete the SAV verification function of the message according to the SAV information;

[0193] The message header is stripped off to obtain a message without the message header added.

[0194] The computer storage medium of the embodiment of the present application can adopt any combination of one or more computer-readable media. The computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. The computer-readable storage medium can be, for example, but not limited to: an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples (non-exhaustive list) of computer-readable storage media include: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (Random Access Memory, RAM), a read-only memory (Read Only Memory, ROM), an erasable programmable read-only memory (ErasableProgrammable Read Only Memory, EPROM), a flash memory, an optical fiber, a portable CD-ROM, an optical storage device, a magnetic storage device, or any suitable combination of the above. The computer-readable storage medium can be any tangible medium containing or storing a program, which can be used by an instruction execution system, a device or a device or used in combination with it.

[0195] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, which carry computer-readable program code. Such propagated data signals may take a variety of forms, including but not limited to: electromagnetic signals, optical signals, or any suitable combination of the above. Computer-readable signal media may also be any computer-readable medium other than a computer-readable storage medium, which may send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0196] 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 above.

[0197] The computer program code for performing the operation 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 the remote computer, or completely on the 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 through the Internet).

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

[0199] 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.

[0200] In general, various embodiments of the present application can be implemented in hardware or dedicated circuits, software, logic or any combination thereof. For example, some aspects can be implemented in hardware, while other aspects can 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.

[0201] 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.

[0202] The block diagram of any logic flow in the drawings of the present application may represent program steps, or may represent interconnected logic circuits, modules and functions, or may represent a combination of program steps and logic circuits, modules and functions. A computer program may be stored in 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 memory 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 general-purpose computers, special-purpose computers, microprocessors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FGPAs) and processors based on multi-core processor architectures.

[0203] By way of exemplary and non-limiting examples, a detailed description of exemplary embodiments of the present application has been provided above. However, various modifications and adjustments to the above embodiments will be apparent to those skilled in the art when considered in conjunction with the accompanying drawings and claims, but will not depart from the scope of the present application. Therefore, the proper scope of the present application will be determined according to the claims.

Claims

1. A message processing method, applied to a source node, characterized in that: include: 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, characterized in that: 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, characterized in that The SAV information includes at least one of the following: SAV service identifier, 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, characterized in that: 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 through BGP.

5. The method according to claim 2, characterized in that: 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, characterized in that For the same SAV trust domain in a cross-domain scenario of the Border Gateway Protocol BGP AS, 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, characterized in that 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, characterized in that: include: 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, characterized in that The SAV information includes at least one of the following: SAV service identifier, 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, characterized in that 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, characterized in that: include: 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, characterized in that The SAV information includes at least one of the following: SAV service identifier, 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, characterized in that 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, characterized in that: include: memory, and one or more processors; The memory is configured to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the message processing method according to any one of claims 1 to 7.

15. An intermediate node, characterized in that: include: memory, and one or more processors; The memory is configured to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the verification method according to any one of claims 8 to 10.

16. A destination node, characterized in that: include: memory, and one or more processors; The memory is configured to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the message processing method as described in any one of claims 11-13.

17. A message processing system, characterized in that: include: 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 having a computer program stored thereon, characterized in that: When the program is executed by a processor, the message processing method according to any one of claims 1 to 7 or 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 is implemented.

Images