Source address verification method, communication device, and storage medium

Abstract

The present application discloses a source address verification method, a communication device, and a storage medium. The method comprises: acquiring a source address identifier corresponding to a source address in a packet to be verified (step S201); and if the source address identifier corresponding to the source address in said packet is consistent with a source address identifier configured on an interface where a first edge communication device has received said packet, determining that verification of the source address of said packet succeeds (step S202).

Description

Source address verification method, communication device and storage medium Technical Field

[0001] The present application relates to the field of communication technology, for example, to a source address verification method, communication equipment and storage medium. Background Art

[0002] With the development of the internet, security has become increasingly important. However, the internet is open to traffic and vulnerable to attacks. Internet routing security can face numerous technical challenges. Current attacks on internet routing primarily include route hijacking, route leakage, and source address spoofing. Route hijacking occurs when an attacker disguises themselves as another trusted network, hijacking network traffic and causing internet traffic disruption or data theft. Route leakage occurs when an internet device advertises prefix information that it should not, leading to network congestion or outages. Source address spoofing occurs when an attacker forges the victim's trusted source Internet Protocol Address (IP address) and sends it to the network, causing a denial of service (DoS) attack on the device. Source address spoofing is the most common method of internet attack. Therefore, identifying source addresses, verifying legitimate source addresses, and filtering for spoofed source addresses can effectively prevent internet routing attacks.

[0003] Common source address verification methods currently include unicast reverse path forwarding (uRPF), including strict uRPF. Strict uRPF is easy to deploy and widely used in networks. However, in cases of asymmetric routing (i.e., when the outbound interface of the source address route is inconsistent with the inbound interface of the actual packet), strict uRPF can mistakenly identify legitimate user packets as packets with forged source addresses, resulting in incorrect filtering of packets with trusted source address prefixes. Consequently, current source address verification methods have a high false positive rate.

[0004] Summary of the Invention

[0005] This embodiment of the present application provides a source address verification method, which is applied to a first edge communication device. The method includes:

[0006] Obtain the source address identifier corresponding to the source address in the message to be verified;

[0007] If the source address identifier corresponding to the source address in the message to be verified is consistent with the source address identifier configured on the interface of the first edge communication device for receiving the message to be verified, it is determined that the source address verification of the message to be verified is passed.

[0008] An embodiment of the present application provides a communication device, comprising: a processor; the processor is configured to implement the source address verification method of any of the above embodiments when executing a computer program.

[0009] An embodiment of the present application also provides a computer-readable storage medium storing a computer program, which implements the source address verification method of any of the above embodiments when executed by a processor.

[0010] With respect to the above embodiments and other aspects of the present application and their implementation, further description is provided in the accompanying drawings, detailed description and claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] FIG1A is a schematic diagram of an application scenario of a source address verification method provided by an embodiment;

[0012] FIG1B is a schematic diagram of another application scenario of a source address verification method provided by an embodiment;

[0013] FIG2 is a schematic diagram of a flow chart of a source address verification method provided by an embodiment;

[0014] FIG3 is a flow chart of another source address verification method provided by an embodiment;

[0015] FIG4 is a schematic diagram of the interaction between the first edge communication device and other communication devices in the embodiment shown in FIG3 ;

[0016] 5 is a schematic diagram of a method for sending a source address and a source address identifier in a source address verification method provided by an embodiment;

[0017] FIG6 is a schematic diagram of another method for sending a source address and a source address identifier in a source address verification method provided by an embodiment;

[0018] 7 is a schematic diagram of another method for sending a source address and a source address identifier in a source address verification method provided by an embodiment;

[0019] FIG8 is a schematic diagram of another method for sending a source address and a source address identifier in a source address verification method provided by an embodiment;

[0020] 9 is a schematic diagram of another method for sending a source address and a source address identifier in a source address verification method provided by an embodiment;

[0021] FIG10 is a schematic diagram of a source address verification device provided by an embodiment;

[0022] FIG11 is a schematic structural diagram of an edge communication device provided by an embodiment. DETAILED DESCRIPTION

[0023] It should be understood that the specific embodiments described herein are only used to explain the present application and are not intended to limit the present application. The embodiments of the present application will be described in detail below with reference to the accompanying drawings.

[0024] Figure 1A is a schematic diagram of an application scenario of the source address verification method provided by an embodiment. As shown in Figure 1A, the edge device (also referred to as the edge device) is arranged between the access network and the backbone network. Figure 1A is illustrated by taking the edge device A and the edge device B as an example. Edge device A and edge device B are both connected between the access network and device C. A subnet mask of the access network can be: AB:: / / 64. Edge device B includes two interfaces fei2 and fei3. On edge device B, data is received from the access network through interface fei2, that is, the path for receiving data from the access network is path L1. On edge device B, data is sent to the access network through interface fei3, that is, the path for sending data to the access network is path L2. It can be seen that the paths of the packets going back and forth are inconsistent, which is a routing asymmetric scenario. The routing table can be pre-configured on edge device B. If, in the routing table of edge device B, the routing exit for packets with the source address AB:: / / 64 is fei3 instead of fei2, then when using strict uRPF for source address verification, packets from the source address AB:: / / 64 will be identified as forged and discarded. This results in a high false positive rate during source address verification.

[0025] Figure 1B is a schematic diagram of another application scenario of the source address verification method provided by an embodiment. As shown in Figure 1B, the edge device ER1 and the edge device ER2 are arranged between the prefix originating network (Prefix Originated Network) and the transit network (Transit Network). The transit network here can be an Open Shortest Path First (OSPF) transit network. The source address (also referred to as the prefix) of the prefix originating network can be published through OSPF. The edge device ER1 and the edge device ER2 access the same sub / stub network (also referred to as the access network, i.e., the prefix originating network in Figure 1B). The edge device ER1 and the edge device ER2 are located in a single autonomous system (Autonomous system, referred to as AS). The edge device ER1 is connected to subnet 1 in the prefix originating network. The edge device ER2 is connected to subnet 2 in the prefix originating network. Of course, the edge device ER1 can also be connected to subnet 2, and the edge device ER2 can also be connected to subnet 1. The prefix originating network (denoted as POI 1) publishes prefix P1 corresponding to subnet 1 to edge device ER1 via interface 1 (denoted as Int1), and publishes prefix P2 corresponding to subnet 2 to edge device ER2 via interface 2 (denoted as Int2). In other words, POI 1 publishes different prefixes to edge devices ER1 and ER2. For example, edge devices ER1 and ER2 may be edge routers.

[0026] Based on OSPF path calculation rules, an OSPF Forwarding Information Base (FIB) is generated on edge devices ER1 and ER2. As shown in Figure 1B, the FIB on edge device ER1 may indicate that the next hop corresponding to destination prefix P2 is Int3. The FIB on edge device ER2 may indicate that the next hop corresponding to destination prefix P1 is Int4.

[0027] Suppose edge device ER1 receives a packet with source prefix P2 and destination prefix P2 from its Int1 interface. Based on its own FIB, edge device ER1 determines that the packet's route goes through edge device ER1's Int3, which is inconsistent with the inbound interface Int1 for source prefix P2. Suppose edge device ER2 receives a packet with source prefix P1 and destination prefix P1 from its Int2 interface. Based on its own FIB, edge device ER2 determines that the packet's route goes through edge device ER2's Int4, which is inconsistent with the inbound interface Int2 for source prefix P1. This is a typical asymmetric and multi-homing scenario. In this scenario, using strict uRPF for source address verification can lead to misjudgments.

[0028] In response to the above problems, in an embodiment of the present application, a source address verification method, communication equipment and storage medium are provided for use in the above scenarios. By obtaining the source address identifier corresponding to the source address in the message to be verified, if the source address identifier corresponding to the source address in the message to be verified is consistent with the source address identifier configured on the interface of the first edge communication device that receives the message to be verified, it is determined that the source address verification of the message to be verified is passed, and accurate verification of the source address is achieved in the routing asymmetric scenario.

[0029] The source address verification method, communication equipment and their technical effects are described below.

[0030] FIG2 is a flow chart of a source address verification method provided by one embodiment. The source address verification method provided by this embodiment is applicable to a first edge communication device (also referred to as a first edge device). As shown in FIG2 , the source address verification method provided by this embodiment includes the following steps.

[0031] Step 201: Obtain a source address identifier corresponding to a source address in a message to be verified.

[0032] To prevent Internet routing attacks, the first edge communication device needs to verify the source address in the received message. In this embodiment, the message to be verified refers to the message that requires source address verification. In this embodiment, the source address is used to indicate the address of the sending device of the message to be verified.

[0033] In one embodiment, the message to be verified may be an address prefix message.

[0034] The source address identifier corresponding to the source address refers to information that can uniquely identify the source address. In one embodiment, the source address identifier can be a Prefix Originated Indicator (POI) Identity (ID).

[0035] It can be understood that multiple source addresses can correspond to one source address identifier.

[0036] In one implementation, the first edge communication device can receive a source address and corresponding source address identifier sent by another communication device and establish a mapping relationship between the source address and the source address identifier. The device can then determine the source address identifier corresponding to the source address in the message to be verified based on this mapping relationship and the source address in the message to be verified. This implementation will be described in detail in subsequent embodiments.

[0037] In another implementation, the message to be verified may carry both the source address and the source address identifier corresponding to the source address.

[0038] In yet another implementation, a mapping relationship between a source address and a corresponding source address identifier may be preconfigured in the first edge communication device.

[0039] Step 202: If the source address identifier corresponding to the source address in the message to be verified is consistent with the source address identifier configured on the interface of the first edge communication device for receiving the message to be verified, it is determined that the source address verification of the message to be verified is passed.

[0040] In this embodiment, the interface of the first edge communication device is configured with a source address identifier corresponding to the interface. In one embodiment, the source address identifier corresponding to the interface of the first edge communication device receiving the message is pre-configured. Specifically, the source address identifier corresponding to each interface can be determined based on network deployment information.

[0041] In this embodiment, after obtaining the source address identifier corresponding to the source address in the message to be verified, it is necessary to determine whether the source address identifier corresponding to the source address in the message to be verified is consistent with the source address identifier configured on the input interface of the first edge communication device, that is, the interface that receives the message to be verified. When it is determined that the source address identifier corresponding to the source address in the message to be verified is consistent with the source address identifier configured on the interface of the first edge communication device that receives the message to be verified, it is determined that the source address verification of the message to be verified has passed, and the message to be verified is a trusted message.

[0042] In one embodiment, the first edge communication device may receive the message to be verified after determining that the source address of the message to be verified passes verification.

[0043] In one embodiment, if it is determined that the source address identifier corresponding to the source address in the message to be verified is inconsistent with the source address identifier configured on the interface of the first edge communication device that receives the message to be verified, it means that the source address of the message to be verified is forged, the message to be verified is an untrusted message, and the message to be verified is discarded.

[0044] The source address verification method provided by this embodiment is described in detail below with reference to FIG. 1A and FIG. 1B .

[0045] Continuing with Figure 1A, assume that the source address AB:: / / 64 corresponds to the source address identifier 5, and the source address identifier configured on interface fei2 of edge device B is also 5. When edge device B receives a message with the source address AB:: / / 64, it obtains the source address identifier 5 corresponding to the message's source address, which is the same as the source address identifier 5 configured on interface fei2. Therefore, it is determined that the source address verification of the message has passed, and the message is trusted.

[0046] Assume that the source address AC:: / / 64 corresponds to the source address identifier 5, and the source address identifier configured on interface fei1 of edge device A is also 5. When edge device A receives a message with the source address AC:: / / 64, it obtains the source address identifier 5 corresponding to the message's source address, which is the same as the source address identifier 5 configured on interface fei1. Therefore, the message's source address verification is confirmed to have passed, and the message is trusted.

[0047] Since the source address AB:: / / 64 and the source address AC:: / / 64 belong to the same access network, in the above example, the source address identifiers of the two source addresses are the same. Of course, it is understandable that the source address identifiers of the source address AB:: / / 64 and the source address AC:: / / 64 may also be different.

[0048] It can be seen that, compared with the strict uRPF verification method, in the scenario in FIG1A , the source address verification method provided in this embodiment can achieve accurate verification of the source address in a routing asymmetric scenario.

[0049] Continuing with Figure 1B, edge devices ER1 and ER2 learn routes for prefixes P1 and P2 from the prefix origin network. Enable the POI policy function on the access-side interfaces of edge devices ER1 and ER2 to filter or verify source prefixes from different prefix source networks. Configure the source address identifier (POI) ID to 1 on the inbound interface Int1 on edge device ER1, which is connected to the prefix origin network. This indicates that packets with a corresponding source address identifier of 1 are valid. Configure the source address identifier (POI) ID to 1 on the inbound interface Int2 on edge device ER2, which is connected to the prefix origin network. This indicates that packets with a corresponding source address identifier of 1 are valid.

[0050] When the edge device ER1 receives a message through Int1, if the source address identifier corresponding to the source address of the message is 1, which is the same as the source address identifier 1 configured on Int1, it is determined that the source address verification of the message passes and the message is a trusted message.

[0051] When edge device ER2 receives a message through Int2, if the source address identifier corresponding to the source address of the message is 1, which is the same as the source address identifier 1 configured on Int2, it is determined that the source address verification of the message passes and the message is a trusted message.

[0052] The source address verification method provided in the embodiment of the present application obtains the source address identifier corresponding to the source address in the message to be verified. If the source address identifier corresponding to the source address in the message to be verified is consistent with the source address identifier configured on the interface of the first edge communication device receiving the message to be verified, the source address verification of the message to be verified is determined to have passed. In the routing asymmetric scenario, accurate verification of the source address is achieved. Compared with the strict uRPF verification method, the misjudgment of source address verification can be reduced.

[0053] Figure 3 is a schematic flow chart of another source address verification method provided by one embodiment. Based on the embodiment shown in Figure 2 and various optional implementations, this embodiment provides a detailed description of how to obtain the source address identifier corresponding to the source address in the message to be verified. As shown in Figure 3, the source address verification method provided by this embodiment includes the following steps.

[0054] Step 301: Receive a source address and a corresponding source address identifier sent by other communication devices.

[0055] In one embodiment, a first edge communication device receives a first source address and a corresponding first source address identifier sent by a first access subnet connected to the first edge communication device. It is understood that the first source address here refers to an address corresponding to a device within the first access subnet. The first source address identifier is an identifier corresponding to the first access subnet.

[0056] In one embodiment, a first edge communication device receives a second source address and a corresponding second source address identifier sent by a second edge communication device. The second source address is the source address of a second access subnet connected to the second edge communication device, and the first access subnet and the second access subnet belong to the same access network. It is understood that the second source address here refers to the address corresponding to a device within the second access subnet. The second source address identifier is an identifier corresponding to the second access subnet.

[0057] Optionally, the first source address identifier and the second source address identifier may be the same. That is, the source address identifiers of multiple access subnets belonging to the same access network are the same. This implementation method can reduce implementation complexity and facilitate configuration of source address identifiers on the interface of the edge device.

[0058] Optionally, the first edge communication device may further send the first source address and the corresponding first source address identifier to the second edge communication device.

[0059] Optionally, the first access subnet connected to the first edge communication device may send the first source address and the corresponding first source address identifier in a flooding manner.

[0060] Optionally, the second edge communication device may send the second source address and the corresponding second source address identifier in a flooding manner.

[0061] Optionally, the first edge communication device may further send the first source address and the corresponding first source address identifier to the second edge communication device in a flooding manner.

[0062] In step 301, it is assumed that the valid source addresses that the first edge communication device can receive are a collection, including the first source address and the second source address, as shown above, and the prefixes of these collections are all associated with the same source address identifier. The valid source addresses and corresponding source address identifiers of the first edge communication device are flooded so that each edge device can receive this information, thereby achieving a mapping of all source addresses and corresponding source address identifiers within the network. In this way, each edge device can implement source address verification of the received message according to the source address verification method provided in this embodiment.

[0063] It can be understood that the number of second edge communication devices in this embodiment can be one or more.

[0064] Step 302: Establish a mapping relationship between the source address and the source address identifier according to the source address and the corresponding source address identifier.

[0065] Optionally, based on the implementation of step 301, a mapping relationship between source addresses and source address identifiers may be established according to the first source address and the corresponding first source address identifier, and the second source address and the corresponding second source address identifier.

[0066] Figure 4 is a schematic diagram of the interaction between the first edge communication device and other communication devices in the embodiment shown in Figure 3. As shown in Figure 4, the first access subnet P1 connected to the first edge communication device carries its own source address and corresponding source address identifier (for ease of description, referred to as the first source address and the first source address identifier) ​​and floods it to the first edge communication device. The first edge communication device floods the first source address and the first source address identifier to the second edge communication device. The second access subnet P2 connected to the second edge communication device carries its own source address and the corresponding source address identifier (for ease of description, referred to as the second source address and the second source address identifier) ​​and floods it to the second edge communication device. The second edge communication device floods the second source address and the second source address identifier to the first edge communication device. The first access subnet and the second access subnet belong to the same access network. In this way, a mapping relationship between the source address and the source address identifier is established on both the first edge communication device and the second edge communication device. The mapping relationship established on the first edge communication device is: first source address - first source address identifier, second source address - second source address identifier. The mapping relationship established on the second edge communication device is: first source address—first source address identifier, second source address—second source address identifier.

[0067] Continuing with Figure 1B, subnet 1 floods the source address and source address identifier 1 to edge device ER1, which then floods this information to edge device ER2. Subnet 2 floods the source address and source address identifier 1 (since subnet 2 and subnet 1 belong to the same prefix origin network, for ease of implementation, we assume that subnet 1 and subnet 2 have the same source address identifier) ​​to edge device ER2, which then floods this information to edge device ER1. After this flooding process, the mapping relationship shown in Table 1 below is established on both edge devices ER1 and ER2.

[0068] Table 1 Mapping relationship

[0069] Step 303: Determine the source address identifier corresponding to the source address in the message to be verified according to the source address in the message to be verified and the mapping relationship between the source address and the source address identifier.

[0070] In this embodiment, the source address identifier corresponding to the source address in the message to be verified may be determined according to the source address in the message to be verified and the mapping relationship between the source address and the source address identifier.

[0071] Continuing with Figure 1B , as shown in step 302, the mapping relationships shown in Table 1 are established on both edge device ER1 and edge device ER2. Therefore, if edge device ER1 receives a message to be verified, assuming the source address of the message to be verified is P2, edge device ER1 determines from the mapping relationship shown in Table 1 that the POI corresponding to P2 is 1. As shown in the embodiment shown in Figure 2 , the source address identifier POI ID 1 is configured on the inbound interface Int1 of edge device ER1, which is connected to the prefix origin network. The source address identifier corresponding to the source address of the message to be verified is 1, which is the same as the source address identifier 1 configured on Int1. Therefore, the source address verification of the message to be verified is determined to have passed, and the message to be verified is authentic. Assuming that interface Int1 of edge device ER1 receives a message with a source address of P3, if the source address identifier corresponding to the source address of the message cannot be found in the mapping relationship shown in Table 1, or if the found source address identifier is not 1, the message is determined to have a forged source address. The message will be discarded by the edge device ER1.

[0072] Step 304: If the source address identifier corresponding to the source address in the message to be verified is consistent with the source address identifier configured on the interface of the first edge communication device for receiving the message to be verified, it is determined that the source address verification of the message to be verified is passed.

[0073] The implementation process and technical principle of step 304 are similar to those of step 202 and will not be described in detail here.

[0074] The following describes the method for sending the source address and the corresponding source address identifier in this embodiment.

[0075] In one embodiment, the source address and corresponding source address identifier are sent via an Interior Gateway Protocol (IGP). That is, in step 301, other communication devices send the source address and corresponding source address identifier via the IGP to implement intra-domain source address verification. Optionally, the first edge communication device may also send the first source address and corresponding first source address identifier to the second edge communication device via the IGP.

[0076] In one embodiment, the IGP in this embodiment includes at least one of the following: OSPF protocol, Intermediate System-to-Intermediate System (ISIS) protocol.

[0077] In one embodiment, the source address and the corresponding source address identifier are sent via a Link-State Advertisement (LSA) in the OSPF protocol.

[0078] In one embodiment, the method for sending the source address and the corresponding source address identifier includes at least one of the following methods: E-Intra-Area-Prefix-LSA in OSPF version 3; E-Inter-Area-Prefix-LSA in OSPF version 3; E-AS-External-LSA in OSPF version 3; Extended Prefix Opaque LSA in OSPF version 2.

[0079] Figure 5 is a schematic diagram of a method for sending the source address and source address identifier in the source address verification method provided in one embodiment. Figure a in Figure 5 is the E-Intra-Area-Prefix-LSA in OSPF version 3. The meaning of each byte has been defined in the draft. It is not repeated in this embodiment. Relevant to this embodiment is the type-length-value (TLVs for short) in Figure a. Figure b in Figure 5 is the Intra-Area-Prefix TLV. It occupies the TLVs in Figure a. Figure c in Figure 5 is the POI TLV format, which occupies the Sub-TLVs in Figure b. The POI TLV in Figure C includes the source address identifier POI ID. Figure B includes the source address (i.e., the address prefix in Figure b). Therefore, based on the format shown in Figure 5, the sending of the source address and the corresponding source address identifier can be achieved.

[0080] Figure 6 is a schematic diagram of another way of sending the source address and source address identifier in the source address verification method provided by one embodiment. Figure a in Figure 6 is the E-Inter-Area-Prefix-LSA in OSPF version 3. The meaning of each byte has been defined in the draft. It is not repeated in this embodiment. The TLVs in Figure a are relevant to this embodiment. Figure b in Figure 6 is the Inter-Area-Prefix TLV. It occupies the TLVs in Figure a. Figure c in Figure 6 is the POI TLV format, which occupies the Sub-TLVs in Figure b. The POI TLV in Figure C includes the source address identifier POI ID. Figure B includes the source address (i.e., the address prefix in Figure b). Therefore, based on the format shown in Figure 6, the sending of the source address and the corresponding source address identifier can be achieved.

[0081] Figure 7 is a schematic diagram of another way of sending the source address and source address identifier in the source address verification method provided by one embodiment. Figure a in Figure 7 is the E-AS-External-LSA in OSPF version 3. The meaning of each byte has been defined in the draft. It is not repeated in this embodiment. The TLVs in Figure a are relevant to this embodiment. Figure b in Figure 7 is the External-Prefix TLV. It occupies the TLVs in Figure a. Figure c in Figure 7 is the POI TLV format, which occupies the Sub-TLVs in Figure b. The POI TLV in Figure C includes the source address identifier POI ID. Figure B includes the source address (i.e., the address prefix in Figure b). Therefore, based on the format shown in Figure 7, it is possible to send the source address and the corresponding source address identifier.

[0082] Figure 8 is a schematic diagram of another way of sending the source address and source address identifier in the source address verification method provided by one embodiment. Figure a in Figure 8 is the Extended Prefix Opaque LSA in OSPF version 2. The meaning of each byte has been defined in the draft. It is not repeated in this embodiment. The TLVs in Figure a are relevant to this embodiment. Figure b in Figure 8 is the Extended Prefix TLV. It occupies the TLVs in Figure a. Figure c in Figure 8 is the POI TLV format, which occupies the Sub-TLVs in Figure b. The POI TLV in Figure C includes the source address identifier POI ID. Figure B includes the source address (i.e., the address prefix in Figure b). Therefore, based on the format shown in Figure 8, the sending of the source address and the corresponding source address identifier can be achieved.

[0083] In one embodiment, the method for sending the source address and the corresponding source address identifier includes: TLV-135, 235, 236 or 237 in ISIS.

[0084] FIG9 is a schematic diagram of another method for sending a source address and a source address identifier in a source address verification method provided by an embodiment. FIG9 a is a TLV in ISIS. FIG9 is an example of a TLV type 236. The sub TLVs in FIG9 a are relevant to this embodiment. FIG8 b is a POI TLV format, which occupies the sub TLVs in FIG8 a. It can be seen that FIG8 a includes a source address (i.e., a prefix in FIG8 a), and the POI TLV in FIG8 c includes a source address identifier POI ID. Therefore, based on the format shown in FIG9 , the sending of the source address and the corresponding source address identifier can be achieved.

[0085] The implementation of FIG. 5 to FIG. 9 can realize sending the source address and the source address identifier in a manner compatible with the protocol in the related art, which is simple to implement and does not affect the original architecture.

[0086] It should be noted that the access network sending information or access subnet sending information described in this embodiment refers to the sending of information by devices in the access network or access subnet. The devices in the access network or access subnet can be a base station, an evolved NodeB (eNB or eNodeB) in Long Term Evolution Advanced (LTEA), a transmission reception point (TRP), a base station in a 5G mobile communication system or the next generation Node B (gNB), a base station in a future mobile communication system or an access node in a Wireless Fidelity (WiFi) system, etc. The base station may include various macro base stations, micro base stations, home base stations, wireless remote stations, routers, WIFI devices or various network-side devices such as primary cells and collaborative cells, and location management functions (LMF) devices. It can also be a module or unit that completes part of the functions of a base station, for example, a centralized unit (CU) or a distributed unit (DU). The embodiments of the present application do not limit the specific technology and specific device form adopted by the equipment in the access network. In addition, the access network equipment can be referred to as a base station.

[0087] The source address verification method provided in this embodiment receives the source address and the corresponding source address identifier sent by other communication devices, establishes a mapping relationship between the source address and the source address identifier according to the source address and the corresponding source address identifier, and determines the source address identifier corresponding to the source address in the message to be verified according to the source address in the message to be verified and the mapping relationship between the source address and the source address identifier. If the source address identifier corresponding to the source address in the message to be verified is consistent with the source address identifier configured on the interface of the first edge communication device for receiving the message to be verified, it is determined that the source address verification of the message to be verified is passed. On the one hand, the mapping relationship between the source address and the source address identifier can be established in advance, which will not affect the current message structure, is simple to implement, and has strong compatibility. On the other hand, it can reduce misjudgment of source address verification.

[0088] FIG10 is a schematic diagram of a source address verification device provided by an embodiment. The source address verification device is provided in a first edge communication device. As shown in FIG10 , the source address verification device provided by this embodiment includes the following modules: an acquisition module 1001 and a determination module 1002.

[0089] The acquisition module 1001 is configured to acquire a source address identifier corresponding to a source address in a message to be verified.

[0090] The determination module 1002 is configured to determine that the source address verification of the message to be verified is successful if the source address identifier corresponding to the source address in the message to be verified is consistent with the source address identifier configured on the interface of the first edge communication device for receiving the message to be verified.

[0091] In one embodiment, the apparatus further includes a receiving module configured to receive a source address and a corresponding source address identifier sent by other communication devices.

[0092] In one embodiment, the receiving module is configured to perform the following steps: receiving a first source address and a corresponding first source address identifier sent by a first access subnet connected to the first edge communication device; receiving a second source address and a corresponding second source address identifier sent by a second edge communication device; wherein the second source address is the source address of a second access subnet connected to the second edge communication device, and the first access subnet and the second access subnet belong to the same access network.

[0093] In one embodiment, the apparatus further includes a sending module configured to send the first source address and the corresponding first source address identifier to the second edge communication device.

[0094] In one embodiment, the apparatus further includes an establishing module configured to establish a mapping relationship between source addresses and source address identifiers based on the first source address and the corresponding first source address identifier, and the second source address and the corresponding second source address identifier.

[0095] In one embodiment, the acquisition module 1001 is configured to determine the source address identifier corresponding to the source address in the message to be verified according to the source address in the message to be verified and the mapping relationship between the source address and the source address identifier.

[0096] In one embodiment, the apparatus further includes a pre-configuration module configured to pre-configure a source address identifier corresponding to an interface of the first edge communication device for receiving messages.

[0097] In one embodiment, the source address and the corresponding source address identifier are sent via IGP.

[0098] In one embodiment, the IGP includes at least one of the following: OSPF protocol, ISIS protocol.

[0099] In one embodiment, the source address and the corresponding source address identifier are sent via LSA in the OSPF protocol.

[0100] In one embodiment, the source address and the corresponding source address identifier are sent in at least one of the following ways:

[0101] E-Intra-Area-Prefix-LSA in OSPF version 3;

[0102] E-Inter-Area-Prefix-LSA in OSPF version 3;

[0103] E-AS-External-LSA in OSPF version 3;

[0104] Extended Prefix Opaque LSA in OSPF version 2.

[0105] In one embodiment, the source address and the corresponding source address identifier are sent in a manner including: TLV-135, 235, 236 or 237 in ISIS.

[0106] In one embodiment, the message to be verified is an address prefix message, and the source address identifier is a POI ID.

[0107] The source address verification device provided in this embodiment can implement the source address verification method of the above embodiment. The implementation principle and technical effects are similar to those of the above embodiment and will not be repeated here.

[0108] The present application also provides a communication device, including a processor configured to implement the method provided in any embodiment of the present application when executing a computer program. For example, the communication device may be an edge device provided in any embodiment of the present application, such as an edge router, and the present application does not impose any specific limitation thereto.

[0109] Illustratively, the following embodiment provides a structural diagram of a communication device that is an edge communication device.

[0110] Figure 11 is a schematic diagram of the structure of an edge communication device provided by one embodiment. As shown in Figure 11, the edge communication device includes a processor 60, a memory 61, and a communication interface 62. The number of processors 60 in the edge communication device can be one or more, with Figure 11 using one processor 60 as an example. The processor 60, memory 61, and communication interface 62 in the edge communication device can be connected via a bus or other means, with Figure 11 using a bus as an example. The term "bus" refers to one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, a processor, or a local bus using any of a variety of bus structures.

[0111] Memory 61, 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 methods in the embodiments of the present application. Processor 60 executes the software programs, instructions, and modules stored in memory 61 to execute at least one functional application and data processing of the edge communication device, thereby implementing the aforementioned methods.

[0112] Memory 61 may include a program storage area and a data storage area. The program storage area may store an operating system and at least one application required for a function; the data storage area may store data generated based on the use of the terminal, etc. Furthermore, memory 61 may include high-speed random access memory and non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state memory device. In some instances, memory 61 may include memory remotely located relative to processor 60, and such remote memory may be connected to an edge communication device via a network. Examples of such networks include, but are not limited to, the Internet, an intranet, a network, a mobile communication network, and combinations thereof.

[0113] The communication interface 62 can be configured to receive and send data.

[0114] An embodiment of the present application further provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the method provided in any embodiment of the present application is implemented.

[0115] 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 component, or any combination of the above. The computer-readable storage medium includes (a non-exhaustive list): an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a flash memory, an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present application, a computer-readable storage medium 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.

[0116] A computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, the data signal carrying computer-readable program code. Such propagated data signals may take various 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 transfer a program for use by or in conjunction with an instruction execution system, apparatus, or device.

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

[0118] Computer program code for performing the operations of the present disclosure may be written in one or more programming languages ​​or a combination of multiple programming languages, including object-oriented programming languages ​​(such as Java, Smalltalk, C++, Ruby, Go), and conventional procedural programming languages ​​(such as "C" or similar programming languages). The program code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may 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 may be connected to an external computer (e.g., via the Internet using an Internet service provider).

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

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

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

[0122] Any block diagram of a logical flow in the drawings of this application may represent program steps, or may represent interconnected logical circuits, modules and functions, or may represent a combination of program steps 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 memory devices and systems (digital versatile discs DVD or CD), etc. Computer-readable media may include non-transitory storage media. A 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 source address verification method, applied to a first edge communication device, the method comprising: Obtain the source address identifier corresponding to the source address in the message to be verified; If the source address identifier corresponding to the source address in the message to be verified is consistent with the source address identifier configured on the interface of the first edge communication device for receiving the message to be verified, it is determined that the source address verification of the message to be verified is passed.

2. The method according to claim 1, further comprising: Receive the source address and corresponding source address identifier sent by other communication devices.

3. The method according to claim 2, wherein: The receiving a source address and a corresponding source address identifier sent by other communication devices includes: Receiving a first source address and a corresponding first source address identifier sent by a first access subnet connected to the first edge communication device; Receive a second source address and a corresponding second source address identifier sent by a second edge communication device; wherein the second source address is a source address of a second access subnet connected to the second edge communication device, and the first access subnet and the second access subnet belong to the same access network.

4. The method according to claim 3, further comprising: Send the first source address and the corresponding first source address identifier to the second edge communication device.

5. The method according to claim 3, further comprising: A mapping relationship between source addresses and source address identifiers is established based on the first source address and the corresponding first source address identifier, and the second source address and the corresponding second source address identifier.

6. The method according to claim 5, wherein: The obtaining of a source address identifier corresponding to a source address in the message to be verified includes: According to the source address in the message to be verified and the mapping relationship between the source address and the source address identifier, the source address identifier corresponding to the source address in the message to be verified is determined.

7. The method according to claim 1, further comprising: A source address identifier corresponding to an interface of the first edge communication device for receiving messages is preconfigured.

8. The method according to claim 2, wherein: The source address and the corresponding source address identifier are sent via the Internal Gateway Protocol IGP.

9. The method according to claim 8, wherein: The IGP includes at least one of the following: Open Shortest Path First (OSPF) protocol and Intermediate System to Intermediate System (ISIS) protocol.

10. The method according to claim 9, wherein: The source address and the corresponding source address identifier are sent via the Link State Advertisement LSA in the OSPF protocol.

11. The method according to claim 10, wherein: The source address and the corresponding source address identifier are sent in at least one of the following ways: E-Intra-Area-Prefix-LSA in OSPF version 3; E-Inter-Area-Prefix-LSA in OSPF version 3; E-AS-External-LSA in OSPF version 3; Extended Prefix Opaque LSA in OSPF version 2.

12. The method according to claim 9, wherein: The sending method of the source address and the corresponding source address identifier includes: TLV-135, 235, 236, or 237 in ISIS.

13. The method according to any one of claims 1 to 12, wherein: The message to be verified is an address prefix message, and the source address identifier is a prefix origination indicator identifier POI ID.

14. A communication device comprising: processor; The processor is configured to implement the source address verification method as claimed in any one of claims 1 to 13 when executing a computer program.

15. A computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the source address verification method according to any one of claims 1 to 13.

Images