Method and device for checking SRv6 message

文档序号:291269 发布日期:2021-11-23 浏览:5次 中文

阅读说明:本技术 一种校验SRv6报文的方法及装置 (Method and device for checking SRv6 message ) 是由 鲁冬杰 古锐 文慧智 肖亚群 于 2020-05-29 设计创作,主要内容包括:本申请实施例公开了一种校验SRv6报文的方法,IPSec隧道的出口节点可以接收SRv6报文,该SRv6报文为采用IPSec传输模式封装的报文。该SRv6报文包括AH和至少一个SRH。SRv6报文中携带有第一指示信息,该第一指示信息用于指示出口节点对SRv6报文进行AH校验。AH校验的校验范围包括该至少一个SRH。该方法可以避免网络黑客利用SRH进行网络攻击。例如可以避免网络黑客通过篡改SRH或者插入新的SRH来进行网络攻击。而且,该方案还具备资源消耗少、可以防止重放攻击并支持密钥协商、可以在利用SRH进行SRv6报文转发的前提下,对SRv6报文的SRH进行验证等优点。(The embodiment of the application discloses a method for checking SRv6 messages, wherein an exit node of an IPSec tunnel can receive a SRv6 message, and the SRv6 message is a message encapsulated by adopting an IPSec transmission mode. The SRv6 message includes an AH and at least one SRH. SRv6, the packet carries first indication information, where the first indication information is used to indicate the egress node to perform AH check on the SRv6 packet. The verification range of the AH verification includes the at least one SRH. The method can avoid network hackers from using the SRH to attack the network. For example, it is possible to prevent a hacker from making a network attack by tampering with the SRH or inserting a new SRH. Moreover, the scheme has the advantages of low resource consumption, capability of preventing replay attack and supporting key agreement, capability of verifying the SRH of the SRv6 message on the premise of transmitting SRv6 messages by utilizing the SRH, and the like.)

1. A method of verifying SRv6 a message, the method comprising:

an exit node of an internet protocol security IPSec tunnel receives an internet protocol version 6 routing SRv6 message, the SRv6 message is a message encapsulated in an IPSec transmission mode, the SRv6 message includes an authentication header AH and at least one segment routing header SRH, the SRv6 message carries first indication information, and the first indication information is used for indicating the exit node to perform AH check on the SRv6 message;

and the outlet node performs AH verification on the SRv6 message according to the first indication information and the AH, wherein the verification range of the AH verification comprises the at least one SRH.

2. The method of claim 1, wherein the first indication information is carried in the SRH.

3. The method of claim 2, wherein a reserved field or an extended type length value, TLV, field in the SRH is used for carrying the first indication information.

4. The method of claim 3, wherein the reserved field is a flag field.

5. The method of claim 1, wherein a destination address of the SRv6 message carries the first indication information.

6. The method of claim 5, wherein the first indication information is carried in an alignment field or a function field of the destination address.

7. The method according to claim 5, wherein the egress node stores therein a correspondence between the destination address and the first indication information.

8. The method according to any of claims 1-7, wherein the destination address of the SRv6 message is a first Segment Identification (SID), and the first SID is the SID or BSID of the egress node.

9. The method of any of claims 1-7, wherein the destination address of the SRv6 message is a second SID, and the second SID is associated with the IPSec tunnel.

10. The method of claim 9, wherein the second SID is an egress IP address of the IPSec tunnel.

11. The method according to any of claims 1-10, wherein a second indication information is included in the SRv6 message, and the second indication information is used to indicate that the checking range of the AH check includes the SRH.

12. The method of claim 11, wherein the second indication information is included in the AH.

13. The method of claim 12, wherein the second indication information is carried in a reserved field of the AH.

14. The method according to any of claims 11-13, wherein performing an AH check on the SRv6 packet by the egress node according to the first indication and the AH comprises:

and the outlet node performs AH verification on the SRv6 message according to the first indication information, the second indication information and the AH.

15. The method according to any of claims 1-14, wherein the check range of the AH check further comprises the payload of the SRv6 message.

16. The method according to any of claims 1-15, wherein the check range of the AH check further comprises the IPv6 header of the SRv6 message.

17. The method of any of claims 1-16, wherein the exit node of the IPSec tunnel is an entry node of an SRv6 trust domain.

18. The method according to any of claims 1-17, wherein said SRv6 message comprises a plurality of SRHs, and wherein said range of AH checks comprises said plurality of SRHs.

19. The method according to any one of claims 1-18, further comprising:

the outlet node forwards the SRv6 message passing the AH check; alternatively, the first and second electrodes may be,

the egress node discards the SRv6 packet that fails the AH check.

20. A method of verifying SRv6 a message, the method comprising:

an entrance node of an internet protocol security IPSec tunnel obtains an internet protocol version 6 routing SRv6 message, the SRv6 message is a message encapsulated in an IPSec transmission mode, the SRv6 message includes an authentication header AH and at least one segment routing header SRH, the SRv6 message carries first indication information, the first indication information is used for indicating an exit node of the IPSec tunnel to perform AH check on the SRv6 message, and a check range of the AH check includes the at least one SRH;

and the ingress node sends the SRv6 message to the egress node.

21. The method of claim 20, wherein the first indication information is carried in the SRH.

22. The method of claim 21, wherein a reserved field or an extended type length value, TLV, field in the SRH is configured to carry the first indication information.

23. The method of claim 22, wherein the reserved field is a flag field.

24. The method of claim 20, wherein a destination address of the SRv6 message carries the first indication information.

25. The method of claim 24, wherein an entries field or a function field of the destination address carries the first indication information.

26. The method according to claim 24, wherein said egress node stores therein a correspondence between a destination address of said SRv6 packet and said first indication information.

27. The method as claimed in any one of claims 20 to 26, wherein the destination address of the SRv6 message is a first segment identification SID, and the first SID is a SID or BSID of the egress node.

28. The method of any of claims 20-26, wherein the destination address of the SRv6 message is a second SID, and wherein the second SID is associated with the IPSec tunnel.

29. The method of claim 28, wherein the second SID is an egress IP address of the IPSec tunnel.

30. The method according to any of claims 20-29, wherein a second indication information is included in the SRv6 message, and the second indication information is used to indicate that the checking range of the AH check comprises the SRH.

31. The method of claim 30, wherein the second indication information is included in the AH.

32. The method of claim 31, wherein the second indication information is carried in a reserved field of the AH.

33. The method according to any of claims 20-32, wherein the check range of the AH check further comprises the payload of the SRv6 message.

34. The method according to any of claims 20-33, wherein the check range of the AH check further comprises the IP header of the SRv6 message.

35. The method of any of claims 20-34, wherein the exit node of the IPSec tunnel is an entry node of an SRv6 trust domain.

36. The method according to any of claims 20-35, wherein said SRv6 message comprises a plurality of SRHs, and wherein said range of AH checks comprises said plurality of SRHs.

37. A network apparatus for an egress node of an internet protocol security, IPSec, tunnel, comprising:

a communication interface; and

a processor coupled to the communication interface;

the communication interface and the processor, the egress node configured to perform the method of any of the preceding claims 1-19.

38. A network apparatus for an ingress node of an internet protocol security, IPSec, tunnel, comprising:

a communication interface; and

a processor coupled to the communication interface;

the communication interface and the processor, the ingress node being configured to perform the method of any of the preceding claims 20-36.

39. A network apparatus for an egress node of an internet protocol security, IPSec, tunnel, the network node comprising a memory and a processor;

the memory for storing program code;

the processor, configured to execute instructions in the program code to cause the egress node to perform the method of any of claims 1-19.

40. A network apparatus for an ingress node of an internet protocol security, IPSec, tunnel, the network node comprising a memory and a processor;

the memory for storing program code;

the processor, configured to execute instructions in the program code to cause the portal node to perform the method of any of the preceding claims 20-36.

41. A computer-readable storage medium having stored therein instructions which, when executed on a computer, cause the computer to perform the method of any one of claims 1-19 or claims 20-36.

42. A communication system comprising the network device of claim 37 or 39 and the network device of claim 38 or 40.

Technical Field

The present application relates to the field of communications, and in particular, to a method and an apparatus for checking an SRv6 message.

Background

The Internet Protocol Version 6 (SRv 6) technology may apply the Segment Routing (SR) technology to forwarding of Internet Protocol Version 6 (IPv 6) messages.

At present, certain potential safety hazards exist when the SRv6 technology is used for message forwarding.

Disclosure of Invention

The embodiment of the application provides a method and a device for checking SRv6 messages, which can reduce the potential safety hazard when the messages are forwarded by using SRv6 technology.

In a first aspect, an embodiment of the present application provides a method for checking SRv6 a packet, where the method may be performed by an exit node of an IPv6 Internet protocol security (IPSec) tunnel to verify whether a SRv6 packet transmitted in the IPSec tunnel is tampered. Optionally, the egress node receives SRv6 the packet, where the SRv6 packet is a packet encapsulated in the IPSec transmission mode. The SRv6 message includes a Segment Routing Header (SRH) and an Authentication Header (AH). In this embodiment, the SRv6 packet carries first indication information, where the first indication information is used to indicate the egress node to perform AH check on the SRv6 packet. After the exit node receives SRv6 message, it not only can use SRH to instruct SRv6 message forwarding, but also can perform AH check on SRv6 message according to the first indication information and AH. In the embodiment of the present application, the verification range of the AH verification includes at least one SRH. Therefore, according to the scheme of the embodiment of the application, SRv6 messages can be encapsulated by adopting an IPSec transmission mode, and at least one SRH of SRv6 messages is checked by using AH check. Compared with the method for verifying the SRH by adopting the HMAC verification, the method can reduce the resource consumption caused by the verification of the SRH, prevent replay attack and support key negotiation, and prevent a network hacker from performing network attack by a newly added SRH. Compared with the method for verifying SRv6 messages encapsulated by adopting the IPSec tunnel mode by using AH verification, the method can verify at least one SRH of the SRv6 messages on the premise of using the SRH to forward SRv6 messages. Compared with the traditional method for verifying the IPv6 message encapsulated by adopting the IPSec transmission mode by using AH verification, the method can verify at least one SRH. By using the method, network hackers can be prevented from using the SRH to carry out network attack. References herein to using SRHs for cyber attacks include tampering with SRHs and/or inserting new SRHs for cyber attacks.

In addition, checking the SRH by adopting AH check can support key agreement and prevent replay attack.

In one implementation, the exit node of the IPSec tunnel is an intermediate node on the SRv6 packet forwarding path.

In one implementation, the SRv6 message is forwarded based on SRH in the IPSec tunnel.

In one implementation, the first indication information in the SRv6 message may be carried by the SRH.

In one implementation, the aforementioned first indication information may be carried in the reserved field of the SRH, considering that the meaning of some reserved fields in the SRH is not explicitly specified. In addition, the SRH further includes an extended TLV field for carrying information, and therefore, the first indication information may also be carried in the extended TLV field of the SRH.

In one implementation, the flag field is a reserved field of the SRH, and the meaning of the flag field is not explicitly specified, so that the first indication information may be carried by the flag field of the SRH.

In one implementation, it is contemplated that a node receiving SRv6 a message will parse SRv6 the destination address of the message when determining how to process SRv6 the message, e.g., if the destination address is determined to be its own address, then continue parsing the SRH header and determining the next hop to forward the message. For another example, if it is determined that the destination address is not the own address, the packet is continuously forwarded to the node indicated by the destination address. Therefore, the aforementioned first indication information may be carried in the destination address of the SRv6 message. In this way, the egress node can obtain the first indication information when resolving the destination address without having to resolve other fields.

In one implementation, for the SRv6 message, its destination address includes 128 bits, and the 128 bits may include three fields of locator, function, and attributes. The function and definitions fields are both used to carry the behavior corresponding to the locator. Therefore, the first indication information may be carried by using an alignment field or a function field of the destination address.

In an implementation manner, the egress node stores a corresponding relationship between the destination address and the first indication information, so as to achieve a purpose that the destination address of the message passing through SRv6 carries the first indication information. The exit node may obtain the first indication information according to the corresponding relationship.

In one implementation, the destination address of the SRv6 packet is a first SID, and the first SID is a SID or a BSID of the egress node. After receiving SRv6 the egress node may determine whether a mapping relationship including the first SID exists locally to obtain the first indication information. Alternatively, the first indication information is obtained through an alignment field or a function field of the first SID.

In one implementation, the destination address of the SRv6 packet is a second SID, and the second SID is associated with the IPSec tunnel. As an example, the second SID is an egress IP address of the IPSec tunnel. After receiving SRv6 the egress node may determine whether a mapping relationship including the second SID exists locally to obtain the first indication information. Alternatively, the first indication information is obtained through an alignment field or a function field of the second SID.

In an implementation manner, the SRv6 packet includes second indication information, where the second indication information is used to indicate that the checking range of the AH check includes the SRH. After the exit node receives SRv6 message, it may determine that AH check is required for the SRv6 message according to the first indication information, and determine that a check range of the AH check includes at least one SRH according to the second indication information.

In one implementation, the aforementioned second indication information may be carried by the AH.

In one implementation, the aforementioned second indication information may be carried in the reserved field of the AH, considering that the meaning of some reserved fields in the AH is not explicitly specified.

In one implementation, the performing, by the egress node, an AH check on the SRv6 packet according to the first indication information and the AH includes:

and the outlet node performs AH verification on the SRv6 message according to the first indication information, the second indication information and the AH.

In one implementation, the verification range of the AH check may include the payload of the SRv6 message in addition to at least one SRH, so as to prevent a network hacker from performing a network attack by tampering with the payload.

In an implementation manner, the checking range of the AH check may further include, in addition to the at least one SRH, an IPv6 header of the SRv6 message, so as to prevent a network hacker from performing a network attack by tampering with the IPv6 header.

In one implementation, the exit node of the IPSec tunnel is an entry node of the SRv6 trust domain. For the situation, the security of SRv6 messages forwarded to the trust domain can be ensured by using the scheme, and the attack on the trust domain is effectively avoided.

In one implementation, the SRv6 message includes multiple SRHs, and the AH check range includes the multiple SRHs. Since the checking range of the AH check comprises all SRHs in the SRv6 message, a network hacker can be effectively prevented from performing network attack by adding a new SRH. Network hackers can also be prevented from hacking the original SRH to make network attacks.

In one implementation, when the exit node determines that the SRv6 message passes the AH check, it indicates that the SRv6 message has certain security, at least the SRH is not tampered, and a network hacker does not insert a new SRH. The egress node may continue to forward the SRv6 message. Correspondingly, if the SRv6 message fails the AH check, it indicates that the SRv6 message is an attack message, and if the SRv6 message continues to be transmitted in the network, the network security is affected, so the outlet node can discard the SRv6 message, and the network security is ensured.

In a second aspect, an embodiment of the present application provides a method for verifying SRv6 a message. The method may be performed by an ingress node of an IPSec tunnel. Specifically, the ingress node may obtain SRv6 a message, where the SRv6 message may be a message obtained by encapsulating the received initial message by the ingress node. The SRv6 message is a message encapsulated by the IPSec transmission mode, and the SRv6 message includes SRH and AH. SRv6, the packet carries first indication information, where the first indication information is used to indicate that the egress node performs AH check on the SRv6 packet, and a check range of the AH check includes the at least one SRH. After the ingress node obtains the SRv6 message, it may send the SRv6 message to the egress node of the IPSec tunnel. In this way, the egress node can perform AH check on the SRv6 packet according to the first indication information. Since the checking range of the AH check comprises all the SRHs in the SRv6 message, a network hacker can be prevented from using the SRHs to perform network attack.

In one implementation, the ingress node of the IPSec tunnel is a head node on the SRv6 packet forwarding path.

In one implementation, the SRH carries the first indication information.

In an implementation manner, a reserved field or an extended type length value, TLV, field in the SRH is used to carry the first indication information.

In one implementation, the reserved field is a flag field.

In one implementation, the destination address of the SRv6 message carries the first indication information.

In one implementation, the entries field or the function field of the destination address carries the first indication information.

In one implementation manner, the egress node stores a corresponding relationship between the destination address of the SRv6 packet and the first indication information.

In one implementation, the destination address of the SRv6 packet is a first segment identification SID, where the first SID is a SID or a BSID of the egress node.

In one implementation, the destination address of the SRv6 packet is a second SID, and the second SID is associated with the IPSec tunnel.

In one implementation, the second SID is an egress IP address of the IPSec tunnel.

In an implementation manner, the SRv6 packet includes second indication information, where the second indication information is used to indicate that the checking range of the AH check includes the SRH.

In one implementation, the second indication information is included in the AH.

In one implementation, the reserved field of the AH carries the second indication information.

In one implementation, the check range of the AH check further includes the payload of the SRv6 packet.

In one implementation, the checking range of the AH check further includes an IP packet header of the SRv6 packet.

In one implementation, the exit node of the IPSec tunnel is an entry node of the SRv6 trust domain.

In one implementation, the SRv6 message includes multiple SRHs, and the AH check range includes the multiple SRHs.

In a third aspect, an embodiment of the present application provides a network device, configured to serve as an egress node of an internet protocol security IPSec tunnel, where the network node includes:

a communication interface; and

a processor coupled to the communication interface;

the egress node is configured to perform the method of any one of the preceding first aspect and the first aspect according to the communication interface and the processor.

In a fourth aspect, an embodiment of the present application further provides a network apparatus, where the network apparatus is used for an ingress node of an internet protocol security IPSec tunnel, and the network node includes:

a communication interface; and

a processor coupled to the communication interface;

the ingress node is configured to perform the method of any of the preceding second aspects and the second aspects according to the communication interface and the processor.

In a fifth aspect, an embodiment of the present application provides a network apparatus, configured to be used in an egress node of an internet protocol security IPSec tunnel, where the network node includes a memory and a processor;

the memory for storing program code;

the processor is configured to execute instructions in the program code to cause the egress node to perform the method of any of the first aspect and the first aspect.

In a sixth aspect, an embodiment of the present application provides a network apparatus, configured to be used in an ingress node of an internet protocol security IPSec tunnel, where the ingress node includes a memory and a processor;

the memory for storing program code;

the processor is configured to execute the instructions in the program code to cause the portal node to perform the method according to any one of the second aspect and the second aspect.

The network apparatus provided in any of the third to sixth aspects of the present application may be, for example, a router, a switch, a packet switching network PTN device, or other network devices. Or a single board, a line card or a chip for implementing the related method in the network device. This is not specifically limited by the present application.

In a seventh aspect, this application embodiment provides a computer-readable storage medium, which stores instructions that, when executed on a computer, cause the computer to perform the method of the above first aspect and any one of the above first aspects, or cause the computer to perform the method of the above second aspect and any one of the above second aspects.

In an eighth aspect, an embodiment of the present application provides a communication system, including an ingress node of an internet protocol security IPSec tunnel and an egress node of the IPSec tunnel, where the egress node is configured to perform the method according to any one of the first aspect and the first aspect.

In a ninth aspect, an embodiment of the present application provides a communication system, including an ingress node of an internet protocol security IPSec tunnel and an egress node of the IPSec tunnel, where the ingress node is configured to perform the method according to any one of the second aspect and the above second aspect.

In a tenth aspect, embodiments of the present application provide a computer program product, which includes a computer program and a storage medium, when the computer program runs on a computer, the computer program causes the computer to execute the method of the above first aspect and any one of the above first aspects, or the computer program causes the computer to execute the method of the above second aspect and any one of the above second aspects.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings needed to be used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments described in the present application, and other drawings can be obtained by those skilled in the art without creative efforts.

Fig. 1 is a schematic structural diagram of an SRv6 message according to an embodiment of the present disclosure;

fig. 2 is a schematic structural diagram of yet another SRv6 message provided in the embodiment of the present application;

fig. 3 is a schematic structural diagram of an IPSec packet according to an embodiment of the present application;

fig. 4 is a schematic diagram of an exemplary application scenario provided in an embodiment of the present application;

fig. 5 is a schematic structural diagram of an SRv6 message encapsulated in a tunnel mode according to an embodiment of the present application;

fig. 6 is a schematic structural diagram of an SRv6 message encapsulated in a transmission mode according to an embodiment of the present application;

fig. 7 is a signaling interaction diagram of a method for verifying SRv6 a packet according to an embodiment of the present application;

fig. 8a is a schematic diagram of a SID list provided in the embodiment of the present application;

fig. 8b is a schematic diagram of a SID list according to an embodiment of the present application;

fig. 8c is a schematic diagram of a SID list according to an embodiment of the present application;

fig. 8d is a schematic diagram of a SID list according to an embodiment of the present application;

fig. 9 is a schematic flowchart of a method for verifying SRv6 a packet according to an embodiment of the present application;

fig. 10 is a schematic flowchart of a method for verifying SRv6 a message according to an embodiment of the present application;

fig. 11 is a schematic structural diagram of a network device according to an embodiment of the present application;

fig. 12 is a schematic structural diagram of a network device according to an embodiment of the present application;

fig. 13 is a schematic structural diagram of a network device according to an embodiment of the present application;

fig. 14 is a schematic structural diagram of a network device according to an embodiment of the present application;

fig. 15 is a schematic structural diagram of a network device according to an embodiment of the present application;

fig. 16 is a schematic structural diagram of a network device according to an embodiment of the present application.

Detailed Description

The embodiment of the application provides a message forwarding method, which can reduce potential safety hazards existing in the process of forwarding a message by using an SRv6 technology.

For ease of understanding, a brief description of message forwarding using the SRv6 technique will first be provided.

When the SRv6 technology is used for forwarding the message, the head node designates the message forwarding path, and the intermediate node directs the message forwarding according to the forwarding path indicated by the head node until the message is forwarded to the destination node. Wherein: messages forwarded using the SRv6 technique may also be referred to as SRv6 messages. Specifically, it can be understood with reference to fig. 1, where fig. 1 is a schematic structural diagram of an SRv6 message provided in this embodiment of the present application. As shown in fig. 1, the SRv6 message includes an IPv6 Header (IPv6 Header)101, an SRH102, and a payload 103. The SRH102 includes a segment identifier list (SID list) indicating a packet forwarding path. In one implementation, the SID list may be composed of several node SIDs, for example, several IPv6 addresses, and the node SID is used to indicate nodes passed through in the packet forwarding process. In yet another implementation, the SID list may be formed by several adjacent links SID, where the adjacent links SID are used to indicate adjacent links through which the packet is forwarded. By contiguous link is meant a link directly between two nodes. In yet another implementation, the SID list may also be composed of a node SID and an adjacent link SID.

When the SRv6 technology is used to forward the message, the intermediate node forwards the message based on the SID list, and it does not check the SRH and the payload. Therefore, a network hacker can perform network attack by tampering with the payload or the SRH maliciously, which affects network security.

Currently, the aforementioned cyber attacks can be prevented by defining SRv6 a trust domain. Wherein the trust domain is used to indicate the network scope to prevent the aforementioned network attacks. The trust domain may be determined based on a variety of ways, for example, based on a network scenario, such as designating a core network portion in a network as the trust domain; alternatively, the determination may be based on the service type, such as determining the range of the network transmitting a specific service packet as the trust domain, and so on. Specifically, to ensure that the trust domain is not attacked, an Access Control List (ACL) traffic filtering policy may be configured on an edge node or an intermediate node of the trust domain. For example, the edge node of the trust domain checks the received SRv6 message, and if the destination address of the SRv6 message is the address of the node in the trust domain, the SRv6 message is discarded. As another example, the edge node or the intermediate node of the trust domain checks the received SRv6 message, and if the source address of the SRv6 message is the address of the node outside the trust domain, the SRv6 message is discarded. By the method, SRv6 messages generated outside the trust domain can be prevented from being transmitted into the trust domain, and SRv6 messages generated in the trust domain can be prevented from being forwarded outside the trust domain. The method and the device realize the forwarding of only SRv6 messages generated in the trust domain, and avoid the attack of the trust domain. The edge node of the trust domain refers to a node which directly communicates with a node outside the trust domain, and the middle node of the trust domain refers to other nodes except the edge node.

However, in some scenarios, the SRv6 message needs to be forwarded across trust domains. For example, SRv6 messages outside of the trust domain need to be forwarded into the trust domain, or SRv6 messages generated in a first domain need to be forwarded through the trust domain to a second domain, the first and second domains being different from the trust domain.

To ensure network security when SRv6 packets are forwarded across trust domains, the inventors of the present application found that key-dependent hash-based message authentication code (HMAC) checks may be deployed on intermediate nodes (e.g., edge nodes of a trust domain) of the forwarded SRv6 packet, thereby preventing network attacks due to SRH tampering. HMAC operations may take a key and data as inputs, compressing the data into a fixed-length data digest. Specifically, as can be understood by referring to fig. 2, fig. 2 is a schematic structural diagram of another SRv6 message provided in this embodiment of the present application. As shown in fig. 2, an HMAC Type Length Value (TLV) is included in the SRH, and the HMAC TLV includes an HMAC Key ID field and an HMAC field. The HMAC Key ID field is used for identifying a Key and a hash algorithm used by the HMAC check, and comprises 4 bytes; the HMAC field is used to indicate a data digest for a particular field in the SRv6 message, which includes 32 bytes.

For specific fields participating in HMAC calculation, the meaning of each field shown in fig. 2, and the specific checking method of HMAC, which are not described in detail herein, reference may be made to the relevant description part of request for comments (RFC) 8754.

Although the above manner can verify whether the SRH of the received SRv6 message is tampered, the HMAC check consumes more resources, which may correspondingly affect the performance of the node performing the HMAC check.

Furthermore, HMAC verification only supports verification of the current SRH (e.g., 102 shown in fig. 1), and if a hacker inserts a new SRH after SRH102 shown in fig. 1, HMAC verification does not verify the newly inserted SRH. The network hacker can still make network attack by tampering with the newly inserted SRH, which affects the network security.

The check range of the HMAC check also does not include the payload, so a network hacker can perform a network attack by tampering with the payload.

HMAC checks do not support key agreement yet, and therefore there is a possibility of key leakage. Therefore, a specific key protection method is required to ensure the security of the key, and if no specific key protection scheme exists, the security of the key cannot be guaranteed, and accordingly, the result of the HMAC check is also untrusted, and the execution of the key protection method occupies system resources to the node performing the HMAC check, and affects the performance of the node performing the HMAC check. At present, HMAC verification does not support replay attack prevention, so a network hacker can send a large number of replay attack messages, consuming network resources.

In summary, the HMAC check deployed on the network node forwarding SRv6 packets cannot effectively guarantee network security.

The inventor of the present application also finds that the IPSec technology uses a secure tunnel to protect data transmission in the network, and the IPv6 IPSec technology supports key agreement and replay attack resistance.

Specifically, an IPSec tunnel may be deployed between two nodes, and when a packet is transmitted in the IPSec tunnel, AH check may be used to determine whether the packet transmitted in the IPSec tunnel is tampered.

Referring to fig. 3, this figure is a schematic diagram of a structure of an IPSec packet according to an embodiment of the present application.

As shown in fig. 3, the IPv6 message includes an IPv6 header, an AH header, and an IPv6 payload.

The fields in the IPv6 header will not be described in detail here.

The AH Header includes a Next Header field, an Hdr Ext Len field, a Reserve field, a Security Parameter Index field, a Sequence Number field, and an Authentication Data ICV field. Wherein:

the Next Header field comprises 8 bits and is used for carrying the Next message Header type;

the Hdr Ext Len field comprises 8 bits and is used for carrying the length of a message;

the Reserve field includes 16 bits, which is a reserved field;

the Security Parameter Index (SPI) field includes 32 bits and is used to carry the Security Parameter Index, which may be used to determine the key and encryption algorithm. The node generating the IPSec packet may perform key negotiation with the node performing the AH check, determine a specific value of the security parameter index after the key negotiation is completed, encapsulate the specific value into the IPSec packet, and send the IPSec packet to the node performing the AH check. By means of key agreement, the key is determined by parameters respectively generated by nodes participating in the agreement, e.g. node A and node B perform key agreement, node A generates parameter A1Node B generates parameter B1By setting the parameter A1Parameter B1And carrying out corresponding operation to obtain a key used by AH verification. Therefore, the key is less likely to leak and is highly safe. The security of the key used by the HMAC check is protected without requiring an additional key protection scheme as with the HMAC check. Therefore, compared with the HMAC verification, the AH verification is performed by adopting the IPSEC technology, and the key security is protected without an additional key protection scheme, so that the resource consumption of the node can be reduced.

And a Sequence Number (Sequence Number) field, which can be used for carrying a message Sequence Number, and can realize replay attack resistance based on the message Sequence Number.

An Integrity Check Value (ICV) field of Authentication Data (Authentication Data) is used to carry an AH check value, and the length of the ICV field is not fixed and is an integer multiple of 32 bits.

In a specific example, using AH check to ensure the security of the packet transmitted in the IPSec tunnel may be implemented as follows: an entry node of the IPSec tunnel may encapsulate an AH header in the IPv6 packet, and an obtained packet structure is as shown in fig. 3, where a value of an Authentication Data ICV field is obtained by performing ICV calculation on a field with a shaded portion shown in fig. 3. Correspondingly, when receiving the IPv6 message shown in fig. 3, the egress node of the IPSec tunnel may perform ICV calculation on the field with the shaded portion, compare the calculated value with the value of the Authentication Data ICV field, and if the calculated value and the value of the Authentication Data ICV field are the same, determine that the message has not been tampered with, and continue to forward the message. If the two are different, the message is determined to be tampered, and the message is discarded. By the method, the safety of the transmission of the IPv6 message in the IPSec tunnel can be ensured.

The manner of the AH check described above is only a specific example, and does not constitute a limitation to the embodiment of the present application.

Since the AH check can guarantee the security of the IPv6 message transmitted in the IPSec tunnel, in some embodiments, the AH check may also be applied to the transmission process of SRv6 message to guarantee the security of the SRv6 message transmitted in the IPSec tunnel.

As can be understood with reference to fig. 4, fig. 4 is a schematic diagram of an exemplary application scenario provided in the embodiment of the present application.

As shown in fig. 4, the node R0 needs to forward the packet to the node R6 sequentially through the node R1, the node R2, the node R3, the node R4, and the node R5. Wherein, a SRv6 tunnel is deployed between the node R1 and the node R5. Node R2, node R3, and node R4 belong to the SRv6 trust domain 100. After receiving the original packet from the node R0, the node R1 may encapsulate the original packet to obtain a SRv6 packet. To enable security of SRv6 packets forwarded to the trust domain, an IPSec tunnel may be deployed between node R1 and node R2. And the AH check is used to ensure the security of the SRv6 message transmitted in the IPSec tunnel.

It should be noted that fig. 4 is shown merely for convenience of understanding, and does not limit the embodiments of the present application. For example, the ingress node of the IPSec tunnel may not necessarily be the same as the ingress node of the SRv6 tunnel as shown in fig. 4, but the ingress node of the IPSec tunnel may also be an intermediate node of the SRv6 tunnel. For another example: the egress node of the IPSec tunnel is not necessarily an edge node of the trust domain as shown in fig. 4, but may also be an intermediate node of the trust domain.

In the following embodiment, an example is given in which an exit node of an IPSec tunnel is an edge node of a trust domain, but this is only for convenience of explaining an implementation manner of the embodiment of the present application, and does not constitute a limitation to the embodiment of the present application.

When SRv6 packets to which AH check is applied are transmitted in the IPSec tunnel, the packet encapsulation format may include tunnel mode encapsulation and transport mode encapsulation. Next, a description will be given of a packet structure encapsulated in a tunnel mode and a packet structure encapsulated in a transmission mode, respectively.

Referring to fig. 5, this figure is a schematic structural diagram of an SRv6 message encapsulated in a tunnel mode according to an embodiment of the present application.

As shown in fig. 5, the SRv6 message shown in fig. 5 includes New IP Header, AH Header, IP Header, SRH, and Payload.

Wherein: the New IP Header is a newly added IP packet Header, and the New IP Header may include an entry node address of the IPSec tunnel and an exit node address of the IPSec tunnel, so as to guide the packet to be forwarded in the IPSec tunnel. The AH Header can be referred to the above description of fig. 3 and will not be described in detail here.

For the SRv6 message shown in fig. 5, the value of the Authentication Data ICV field in the AH Header is obtained by performing ICV calculation on fields in the New IP Header, the AH Header, the IP Header, the SRH, and the Payload. In other words, both SRH and Payload participate in ICV calculation, so if AH check of the SRv6 message passes, it is indicated that both SRH and Payload of the SRv6 message are not tampered, and the security of the SRv6 message transmitted in the IPSec tunnel is ensured.

As can be seen from the message structure shown in fig. 5, the New IP Header can instruct SRv6 message to be forwarded in the IPSec tunnel. Moreover, the safety of the SRv6 message transmitted in the IPSec tunnel can be ensured by AH check. However, since the SRH is encapsulated in the inner layer, when the SRv6 message is forwarded in the IPSec tunnel, the forwarding node does not analyze the SRH, and therefore the message cannot be forwarded according to the SRH. In other words, when the SRv6 message is forwarded in the IPSec tunnel, the SRH cannot be used to direct the forwarding of the message, and only when the SRv6 message is stripped from the IPSec tunnel, the New IP Header and the AH Header, the SRH can be used to direct the forwarding of the message. Regarding the encapsulation format of the IPSec transmission mode packet, reference may be made to the related description of RFC4302, which is not described in detail herein, and RFC4302 is incorporated into this application by reference in its entirety.

However, in some scenarios, for example, as shown in fig. 4, the IPSec tunnel is part of the SRv6 tunnel, and it is often required that when SRv6 packets are forwarded in the IPSec tunnel, SRH can be used to direct packet forwarding. Therefore, encapsulation in tunnel mode is not suitable in some scenarios.

Referring to fig. 6, this figure is a schematic structural diagram of an SRv6 message encapsulated in a transmission mode according to an embodiment of the present application.

As shown in fig. 6, the SRv6 message shown in fig. 6 includes an IP Header, an SRH, an AH Header, and Payload. The SRH referred to herein may also be referred to as SRH. The AH Header mentioned here may also be referred to as AH.

As can be seen from fig. 6, unlike fig. 5, here the AH Header is encapsulated in the inner layer and the SRH is encapsulated in the outer layer of the AH Header. Since the AH Header is encapsulated in the inner layer of the SRH, the AH Header is processed after the SRH is processed. In other words, the intermediate node that forwards using SRv6 forwards according to SRH does not perform parsing processing on AH Header. The analysis process of the AH Header is performed only after the SRH is stripped by the tail node forwarded by the SRH, namely the last node indicated by the SID list in the SRH. In some network scenarios, the IPSec tunnel is part of an SRv6 tunnel. I.e., the egress node of the IPSec tunnel is an intermediate node that utilizes SRv6 forwarding. This results in that when the SRv6 message is forwarded in the IPSec tunnel, although the SRH can be used to guide the message forwarding, the AH check cannot be used to ensure the security of the message transmission. Because the exit node of the IPSec tunnel does not perform integrity check on the SRH, even if the SRH is tampered with or a new SRH is maliciously inserted by a network hacker, the packet will continue to be forwarded in the network. Moreover, since the sequence number field in AH is used to protect against replay attacks, the egress node of the IPSec tunnel does not perform the AH verification step, which results in that SRv6 messages cannot protect against replay attacks even when they are transmitted in the IPSec tunnel.

In order to solve the foregoing problem, an embodiment of the present application provides a method for checking SRv6 packets, which may encapsulate SRv6 packets using an IPSec transmission mode, and check at least one SRH of SRv6 packets using AH check. Compared with the method for verifying the SRH by adopting the HMAC verification, the method can reduce the resource consumption caused by the verification of the SRH, prevent replay attack and support key negotiation, and prevent a network hacker from performing network attack by a newly added SRH. Compared with the method for verifying SRv6 messages encapsulated by adopting the IPSec tunnel mode by using AH verification, the method can verify at least one SRH of the SRv6 messages on the premise of using the SRH to forward SRv6 messages. Compared with the traditional method for verifying SRv6 messages encapsulated by adopting the IPSec transmission mode by using AH verification, the method can verify the SRH in the messages.

Next, a message forwarding method provided in the embodiment of the present application is described in conjunction with the application scenario shown in fig. 4. Referring to fig. 7, this figure is a signaling interaction diagram of a method for verifying SRv6 messages according to an embodiment of the present application. The method 100 of checking SRv6 messages shown in fig. 7 may be implemented as follows, S101-S104.

S101: the node R1 obtains a message 1, where the message 1 is a SRv6 message, the message 1 includes AH and at least one SRH, the message 1 carries indication information 1, and the indication information 1 is used to indicate the node R2 to perform AH check on the message 1.

As shown in fig. 4, node R1 is the ingress node of the IPSec tunnel and node R2 is the egress node of the IPSec tunnel.

In this embodiment, the message 1 may be a message obtained by encapsulating, by the node R1, the obtained initial message. As an example, the node R1 may receive the packet 2 from the node R0 and encapsulate the packet 2, resulting in the packet 1. For example, the node R1 receives the IPv4 packet or the IPv6 packet from the node R0, and then the node R1 repackages the packet and adds SRH and AH to the packet, thereby obtaining the packet 1.

In the embodiment of the present application, the node R1 encapsulates the obtained initial packet by using a transmission mode. For the message encapsulation format of the IPSec transmission mode, reference may be made to relevant parts in RFC4302, which will not be described in detail here. As an example, the message structure of message 1 may be the message structure shown in fig. 6.

In this embodiment, when repackaging the received original packet, the node R1 may add the indication information 1, so as to obtain the packet 1 including the indication information 1. The indication information 1 is used to indicate the node R2 to perform AH check on the packet 1. Moreover, in order to avoid network attack caused by the SRH being tampered or a network hacker adding a new SRH in the message, the AH check range includes the at least one SRH. Thus, even if the AH Header is encapsulated in the SRH inner layer as shown in fig. 6, the exit node R2 of the IPSec tunnel is an intermediate node forwarded by SRv6, the node R2 can perform an AH check on the packet 1 according to the indication information 1, and the check range includes the at least one SRH. Thereby preventing hackers from attacking the network using SRH. References herein to utilizing SRHs include, but are not limited to, tampering with SRHs or inserting new SRHs.

In this application, the AH check range may include one SRH or may include a plurality of SRHs.

In this embodiment of the present application, the indication information 1 may be carried by one of the fields in the message 1. The embodiment of the present application does not specifically limit this field. The field for carrying the indication information 1 may be, but is not limited to, the following fields.

As an example, the field may be one of the fields in the SRH. In other words, the aforementioned indication information 1 may be carried in the SRH. For example, the indication information 1 may be carried in a reserved field or an extended TLV field of the SRH. Considering that the meaning of the flag field in the SRH is not clearly defined, the flags field may be considered as a reserved field of the SRH, and therefore, the flags field in the SRH may be utilized to carry the indication information 1.

As another example, it is considered that in practical applications, after the node R1 obtains the packet 1, the destination address in the IPv6 header of the packet 1 is modified to the address of the node R2, so as to send the packet 1 to the node R2. And the node receiving the message 1 will determine whether the destination address is the address of itself, if so, execute the next operation, for example, continue analyzing the SRH segment routing header, and so on. And if the destination address is not the address of the destination address, continuing to forward the message to the node corresponding to the destination address. In other words, when the node R2 receives the message 1, it must resolve the destination address of the message 1. Therefore, in the embodiment of the present application, the field for carrying the indication information 1 may be a destination address field. In other words, the aforementioned indication information 1 may be carried in the destination address of the message 1.

Considering that in practical application, for the SRv6 message, its destination address includes 128 bits, and the 128 bits may include three fields of locator, function and definitions. The locator field is used for carrying a network segment address and a subnet address; the function and definitions fields are both used to carry the behavior corresponding to the locator. For example, when the destination address is a Binding Segment Identification (BSID), the function indicates a behavior of expanding the BSID to a SID list. The BSID may be used to identify a forwarding path, which may be indicated by the SID list. Therefore, in an implementation manner of the embodiment of the present application, the aforementioned indication information 1 may be carried by using a function field or an definitions field of the destination address. For example, a function type (e.g., end.ah mentioned below) may be added, where the function type is used to carry the aforementioned indication information 1 and is used to indicate the node corresponding to the destination address to perform AH check. As another example, in the case where the function field has been used, the aforementioned indication information 1 is carried by using an definitions field. In another implementation manner, the node R2 may store the corresponding relationship between the destination address of the message 1 and the indication information 1, so as to achieve the purpose of carrying the indication information 1 through the destination address of the message 1.

As for the destination address of the message 1, it should be noted that the node indicated by the destination address is the node R2. The destination address is not specifically limited in the embodiments of the present application, and as an example, the destination address may be R2.sid, that is, the destination address may be a segment identifier of R2 node. As yet another example, the destination address may be R2.bsid, i.e., the binding segment id whose destination address is R2 node, for identifying a path starting from node R2. When the destination address of the message 1 is r2.SID, the SID list of the message 1 is as shown in fig. 8 a. When the destination address of the message 1 is r2.bsid, the SID list of the message 1 is as shown in fig. 8 b. With regard to the R5.VPN and the R5.end shown in fig. 8a and 8b, it should be noted that, the R5.end is used to indicate the R5 node, and is used to indicate the node R4 to forward the message 1 to the node R5, and the R5.VPN is used for a specific Virtual Private Network (VPN) instance deployed on the corresponding node R5. As yet another example, the destination address may be associated with an IPSec tunnel. For example, the destination address of packet 1 may be the egress IP address of the IPSec tunnel, r2. end.ah. For this case, the egress IP address may be associated with node R2 in advance and the route is published onto node R1, so that in the case where the destination address of packet 1 is the egress IP address of the IPSec tunnel, packet 1 can be forwarded to node R2. When the destination address of packet 1 is the exit IP address of the IPSec tunnel, the SID list of packet 1 may be as shown in fig. 8c, where r2.bsid is used to indicate a forwarding path. For directing the node R2 to forward the received message 1. Of course, if the BSID is not used to access the trust domain, the SID list of the packet 1 may be as shown in fig. 8 d.

In this embodiment, if the destination address of the message 1 is R2.BSID, the BSID may be generated by the node R2 or the control management device. For this case, the out-of-domain node sets the destination address of the SRv6 packet forwarded to the trust domain as BSID, which can prevent the network topology in the trust domain from leaking.

In some embodiments, an IPSec tunnel may be associated with a VPN instance. In general, one IPSec tunnel may be associated with one or more VPN instances. That is, the IPSec tunnel is used to transmit the packet corresponding to the VPN instance associated with the IPSec tunnel. In addition, BSIDs may also be associated with IPSec tunnels, and one BSID may correspond to one IPSec tunnel.

In this embodiment of the present application, if the destination address of the packet 1 is an exit IP address or an r2.sid of the IPSec tunnel, the IPSec tunnel may be associated with multiple VPN instances, and is used to transmit packets corresponding to the multiple VPN instances. If the destination address of the packet 1 is r2.bsid, the IPSec tunnel may be associated with a VPN instance, which is the VPN instance associated with r2. bsid.

As can be seen from the above description of fig. 3, currently, the check range of the AH check does not include SRH. In the present application, in order to avoid a network attack due to the SRH being tampered with, the AH verification range includes at least one SRH. Specifically, in an implementation manner, the aforementioned indication information 1 may be used to indicate that, in addition to instructing the egress node of the IPSec tunnel to perform AH check, a check range of the AH check includes at least one SRH. In another implementation, when repackaging the received original message, the node R1 may add the indication information 2 in addition to the indication information 1, thereby obtaining the message 1 including the indication information 1 and the indication information 2. Wherein, the indication information 2 is used for indicating that the checking range of the AH checking comprises at least one SRH. For this case, indication information 1 is used to indicate that the egress node of the IPSec tunnel performs AH check, and indication information 2 is used to indicate that the check range of the AH check includes at least one SRH.

In this embodiment, the indication information 2 may be carried by one of the fields in the message 1. The embodiment of the present application does not specifically limit this field. Several possible fields for carrying the indication information 2 are described below.

In view of the fact that an AH check is performed in conjunction with the relevant content in the AH, the indication 2 may be carried by the AH in one implementation. For example, the indication information 2 may be carried in a reserved field of the AH. For example, one of the bits of the Reserve field in the AH may be utilized to carry the indication information 2. Of course, the indication information 2 may also be carried by other fields in the packet 1, for example, by a reserved field or an extended TLV field of the SRH.

It can be understood that, through the indication information 1, the indication information 2 and the AH, the node R2 can perform an AH check on the received packet 1, and the check range of the AH check includes the SRH.

In an implementation manner of the embodiment of the present application, a check range for performing AH check on the packet 1 may further include a payload of the packet 1. When the verification range of the AH verification includes the payload, compared with a scheme adopting the HMAC verification, the scheme provided by the embodiment of the present application can prevent a network hacker from using the payload to perform a network attack. The network attack using the payload mentioned here may include, for example, tampering the payload, so that the attack packet is transmitted in the network, which not only consumes network resources, but also has a certain security risk.

In an implementation manner of the embodiment of the present application, it is considered that SRv6 message processing includes an IP header in addition to an SRH and a payload, and the IP header also carries some important information, for example, a final destination address of a message (for example, a destination address after the tunnel SRv6 exits). If the IP header is tampered with, there is a certain security risk. Therefore, in some embodiments, the check range for AH check on packet 1 may also include the IP packet header of packet 1.

Certainly, the verification range for performing AH verification on the packet 1 may include both the IP packet header of the packet 1 and the payload of the packet 1, thereby implementing integrity verification on the packet 1. The IP headers mentioned here may be, for example, the aforementioned IPv6 headers.

As shown in fig. 3, the AH includes an Authentication Data ICV field, and the value of the field may be obtained by the node R1 performing ICV calculation on a specific field in the message 1. Wherein the fields involved in the ICV calculation are related to the check range of the AH check. If the check range of the AH check includes SRH, the fields participating in ICV calculation may be fields in SRH. If the check range of the AH check includes SRH and payload, the fields participating in ICV computation may be SRH and payload. If the checking range of the AH check includes the SRH and the IP packet header, the fields participating in the ICV calculation may be the SRH and the IP packet header. If the checking range of the AH checking comprises the SRH, the IP message header and the payload, the fields participating in the ICV calculation can be the SRH, the IP message header and the payload. In an implementation manner of the application embodiment, if the message 1 includes the indication information 2, the range of the AH check may be indicated by a value of the indication information 2. For example, when the value of the indication information 2 is a, the range of the AH check includes the SRH and the payload, when the value of the indication information 2 is B, the range of the AH check includes the SRH and the IP header, and when the value of the indication information 2 is C, the range of the AH check includes the SRH, the payload, and the IP header.

When performing AH check on the received message 1, the node R2 also performs ICV calculation on a specific field in the message 1, and compares the calculated value with the value carried in the Authentication Data ICV field of the message 1, thereby determining whether the message 1 is tampered. In practical application, in the forwarding process of the packet 1, values of some fields are kept unchanged (immutable), and values of some fields are changed. The fields with changed values can be divided into two classes, namely a variable but predictable (variable) class and a variable but unpredictable class, which can be referred to as a variable (variable) class for short. Wherein the variable but predictable class means that the value of the field is predeterminable when the node R2 receives the message 1, and the variable class means that the value of the field is not predeterminable when the node R2 receives the message 1.

In order to enable the result of the AH check to correctly indicate whether the message 1 is tampered, in the embodiment of the present application, when the node R1 calculates the value of the Authentication Data ICV field, the ICV calculation may be performed by setting the value of the change field to a preset value, for example, 0, and determining the value of the variable but predictable class field as the predicted value of the field. The prediction value mentioned here refers to the value of the field when the node R2 receives the message 1.

The types of the fields in the SRv6 message can be as shown in table 1 below.

TABLE 1

The specific meanings of the fields shown in Table 1 are not specifically described here.

In addition, the IPv6 payload of the SRv6 message belongs to an invariant field.

It should be noted that, when the node R1 calculates the value of the Authentication Data ICV field, the value of the Destination Address field of the IPv6 header is the exit Address of the IPSec tunnel, and the exit Address of the IPSec tunnel may be R2.sid, R2.bsid, or R2.ah. sid mentioned above. The value of Segment Left is the value corresponding to the node R2 when receiving the message 1. In this embodiment, if the destination address carries indication information 1, when the node R2 receives the packet 1, the destination address field may be analyzed to obtain the indication information 1, and AH check is performed according to the indication information 1. If the destination address is r2.sid, the indication information 1 may be carried in the function field of r2. sid; if the destination address is r2.bsid, the indication information 1 may be carried in an alignment field of r2. bsid; if the destination address is r2.ah.sid, the indication information 1 may be carried in the function field or the attributes field of r2. ah.sid.

S102: the node R1 sends message 1 to the node R2.

S103: node R2 receives message 1.

After node R1 obtains message 1, it may forward message 1 to node R2. The node R2 may receive the message 1 sent by the node R1. As shown in FIG. 4, node R2 is an edge node of the trust domain.

S104: and the node R2 performs AH check on the message 1 according to the indication information 1 and AH, wherein the check range of the AH check comprises at least one SRH.

After the node R2 receives the message 1, it first determines that the destination address of the message 1 is the address of the node R2. Then, the node R2 obtains the indication information 1, and according to the indication information 1, the node R2 may perform an AH check on the packet 1. Specifically, node R2 may parse the AH, determining the ICV algorithm and key used for AH verification, based on the Security Parameter Index field in the AH. In addition, if the indication information 1 is used to indicate that the egress node of the IPSec tunnel performs AH check, and the check range used to indicate the AH check includes at least one SRH, the node R2 may perform AH check on the packet 1 according to the indication information 1, and the check range of the AH check includes at least one SRH. If the indication information 1 is used to indicate the egress node of the IPSec tunnel to perform AH check, and the indication information 2 is used to indicate that the check range of the AH check includes at least one SRH, the node R2 may further determine that the check range of the AH check includes an SRH according to the indication information 2. Regarding the indication information 1 and the indication information 2, reference may be made to the description part of S101 for the indication information 1 and the indication information 2, which is not described in detail here.

In a specific example, AH check of the packet 1 by the node R2 can be implemented as follows: node R2 may perform ICV calculations for specific fields in message 1. For the changed field in the specific field, the value of the changed field may be calculated as a preset value, for example, 0. The specific fields mentioned here may include SRH, SRH and payload, and may also include SRH, IP header and payload. After the node R2 performs ICV calculation on the specific field in the message 1, the calculated value may be compared with the value carried in the Authentication Data ICV field in the message 1, and if the calculated value is the same as the value carried in the Authentication Data ICV field in the message 1, it indicates that the message 1 has not been tampered, and further, the node R2 strips the AH and further performs message forwarding according to the SRH. If they are not the same, it indicates that message 1 has been tampered, and for this case, node R2 may discard message 1 in order to avoid an attack on the network, e.g., a trust domain.

As to a specific implementation manner of the node R2 for forwarding the packet according to the SRH, for example, the next-hop destination node for forwarding the packet may be determined according to values of the SRH and a Segment Left (SL) field, which is not described in detail herein.

In this embodiment, the range of AH check includes at least one SRH, and in one embodiment, the node R2 may check all SRHs in the packet 1, so that if there is an SRH newly added by a network hacker in the SRHs involved in the check, the AH check fails, and it may be determined that the packet 1 is a tampered packet. Therefore, by the scheme, a network hacker can be prevented from attacking the network in a way of adding the SRH.

As can be seen from the above description of fig. 3, the SPI field is included in the AH, so that using the AH check has the advantage of supporting key agreement compared to using the HMAC check. The AH key is more secure because the AH verification supports the key agreement, and an additional key protection scheme is not needed to protect the security of the AH key, so that the resource consumption of the node R2 can be reduced. Moreover, the AH includes a sequence number field, which can prevent a network hacker from repeatedly sending the same packet, i.e., the scheme of the embodiment of the present application further supports replay attack prevention compared with the scheme using HMAC verification, and prevents the same packet from being transmitted in the network and occupying network resources.

As can be seen from the above description, with the scheme of the embodiment of the present application, it is verified whether the packet 1 is tampered during transmission in the IPSec tunnel through AH verification, and the packet 1 is forwarded only when the packet 1 passes the verification, otherwise the packet 1 is discarded. Under the condition that the node R2 is an edge node of the trust domain, the method can ensure the safety of the SRv6 message forwarded to the trust domain, and effectively avoid the attack of the trust domain. Under the situation that the node R2 is not an edge node of a trust domain, by using the scheme of the embodiment of the application, the tampered SRv6 message can be prevented from being continuously transmitted in the network, the network resources occupied by the tampered message are avoided, and the potential safety hazard caused by the tampered SRv6 message being continuously transmitted in the network is eliminated.

It should be noted that the IPSec tunnel in the embodiment of the present application may be established between nodes with higher requirements on security protection, for example. For example, as shown in fig. 4, in order to ensure that the trust domain is not attacked and to ensure the validity of SRv6 messages from outside the trust domain, an IPSec tunnel is deployed between the edge node R2 of the trust domain and the node R1 outside the domain. Alternatively, it may be established between nodes without other security measures. Of course, only two possible scenarios for establishing the IPSec tunnel are indicated here, which do not constitute a limitation to the embodiments of the present application.

The embodiment of the present application further provides a method 200 for verifying SRv6 messages, referring to fig. 9, where fig. 9 is a schematic flow chart of the method for verifying SRv6 messages provided in the embodiment of the present application. This method is explained below with reference to fig. 9. The method shown in fig. 9 can be implemented, for example, by S201-S201.

S201: an exit node of the IPSec tunnel receives an SRv6 message, the SRv6 message is a message encapsulated in an IPSec transmission mode, the SRv6 message includes an AH and at least one SRH, the SRv6 message carries first indication information, and the first indication information is used for indicating the exit node to perform AH check on the SRv6 message.

S202: and the outlet node performs AH verification on the SRv6 message according to the first indication information and the AH, wherein the verification range of the AH verification comprises the at least one SRH.

The method 200 may be used to implement S103 and S104 executed by the node R2 in the method 100 mentioned in the above embodiment, and when the method 200 is used to implement S103 and S104 executed by the node R2 in the method 100 mentioned in the above embodiment, the egress node of the IPSec tunnel corresponds to the node R2, SRv6 message in the method 100, and the first indication information corresponds to the indication information 1 in the method 100.

In one implementation, the SRH carries the first indication information.

In an implementation manner, a reserved field or an extended TLV field in the SRH is used to carry the first indication information.

In one implementation, the reserved field is a flag field.

In one implementation, the destination address of the SRv6 message carries the first indication information.

In one implementation, the entries field or the function field of the destination address carries the first indication information.

In one implementation manner, the egress node stores a corresponding relationship between the destination address and the first indication information.

In one implementation, the destination address of the SRv6 packet is a first segment identification SID, where the first SID is a SID or a BSID of the egress node. The SID of the egress node may correspond to the r2.SID of the method 100 and the BSID of the egress node may correspond to the r2.BSID of the method 100.

In one implementation, the destination address of the SRv6 packet is a second SID, and the second SID is associated with the IPSec tunnel.

In one implementation, the second SID is an egress IP address of the IPSec tunnel. The egress IP address of the IPSec tunnel may correspond to r2.ah. sid in method 100.

In an implementation manner, the SRv6 packet includes second indication information, where the second indication information is used to indicate that the checking range of the AH check includes the SRH. The second indication information may correspond to indication information 2 in the method 100.

In one implementation, the second indication information is included in the AH.

In one implementation, the reserved field of the AH carries the second indication information.

In one implementation, the performing, by the egress node, an AH check on the SRv6 packet according to the first indication information and the AH includes:

and the outlet node performs AH verification on the SRv6 message according to the first indication information, the second indication information and the AH.

In one implementation, the check range of the AH check further includes the payload of the SRv6 packet.

In one implementation, the check range of the AH check further includes an IPv6 packet header of the SRv6 packet.

In one implementation, the exit node of the IPSec tunnel is an entry node of the SRv6 trust domain.

In one implementation, the SRv6 message includes multiple SRHs, and the AH check range includes the multiple SRHs.

In one implementation, the method further comprises:

the outlet node forwards the SRv6 message passing the AH check; alternatively, the first and second electrodes may be,

the egress node discards the SRv6 packet that fails the AH check.

With respect to the specific implementation of the method 200, reference may be made to the above description part for S103 and S104 in the method 100, and the description is not repeated here.

The embodiment of the present application further provides a method 300 for verifying SRv6 messages, referring to fig. 10, where fig. 10 is a schematic flowchart of a method for verifying SRv6 messages provided in the embodiment of the present application. This method is described below with reference to fig. 10. The method shown in fig. 10 can be implemented, for example, by S301 to S301.

S301: an entrance node of an IPSec tunnel obtains SRv6 a packet, where the SRv6 packet is a packet encapsulated in an IPSec transmission mode, the SRv6 packet includes an AH and at least one SRH, the SRv6 packet carries first indication information, the first indication information is used to indicate an exit node of the IPSec tunnel to perform AH check on the SRv6 packet, and a check range of the AH check includes the at least one SRH.

S302: and the ingress node sends the SRv6 message to the egress node.

The method 200 may be used to implement S101 and S102 executed by the node R1 in the method 100 mentioned in the above embodiment, when the method 200 is used to implement S101 and S102 executed by the node R1 in the method 100 mentioned in the above embodiment, the ingress node of the IPSec tunnel corresponds to the node R1 in the method 100, the egress node of the IPSec tunnel corresponds to the node R2, SRv6 message in the method 100, and the first indication information corresponds to the indication information 1 in the method 100.

In one implementation, the SRH carries the first indication information.

In an implementation manner, a reserved field or TLV field in the SRH is used to carry the first indication information.

In one implementation, the reserved field is a flag field.

In one implementation, the destination address of the SRv6 message carries the first indication information.

In one implementation, the entries field or the function field of the destination address carries the first indication information.

In one implementation manner, the egress node stores a corresponding relationship between the destination address of the SRv6 packet and the first indication information.

In one implementation, the destination address of the SRv6 packet is a first segment identification SID, where the first SID is a SID or a BSID of the egress node. The SID of the egress node may correspond to the r2.SID of the method 100 and the BSID of the egress node may correspond to the r2.BSID of the method 100.

In one implementation, the destination address of the SRv6 packet is a second SID, and the second SID is associated with the IPSec tunnel.

In one implementation, the second SID is an egress IP address of the IPSec tunnel. The egress IP address of the IPSec tunnel may correspond to r2.ah. sid in method 100.

In an implementation manner, the SRv6 packet includes second indication information, where the second indication information is used to indicate that the checking range of the AH check includes the SRH. The second indication information may correspond to indication information 2 in the method 100.

In one implementation, the second indication information is included in the AH.

In one implementation, the reserved field of the AH carries the second indication information.

In one implementation, the check range of the AH check further includes the payload of the SRv6 packet.

In one implementation, the checking range of the AH check further includes an IP packet header of the SRv6 packet.

In one implementation, the exit node of the IPSec tunnel is an entry node of the SRv6 trust domain.

In one implementation, the SRv6 message includes multiple SRHs, and the AH check range includes the multiple SRHs.

With respect to the specific implementation of the method 300, reference may be made to the above description part for S101 and S102 in the method 100, and the description is not repeated here.

In addition, an embodiment of the present application further provides a network apparatus 1100, configured to be used as an egress node of an IPSec tunnel, which is shown in fig. 11. Fig. 11 is a schematic structural diagram of a network device according to an embodiment of the present application. The network device 1100 includes a transceiving unit 1101 and a processing unit 1102. Among them, the transceiving unit 1101 is configured to perform transceiving operation performed by the egress node of the IPSec tunnel in the above embodiment. The processing unit 1102 is configured to perform operations other than the transceiving operations performed by the egress node of the IPSec tunnel mentioned in the above embodiment. For example, the transceiving unit 1101 is configured to receive SRv6 a message, and the processing unit 1102 is configured to perform an AH check on the SRv6 message according to the first indication information and an AH carried in the SRv6 message.

In addition, an embodiment of the present application further provides a network apparatus 1200, which is used for an ingress node of an IPSec tunnel, and is shown in fig. 12. Fig. 12 is a schematic structural diagram of a network device 1200 according to an embodiment of the present disclosure. The network apparatus 1200 includes a transceiving unit 1201 and a processing unit 1202. The transceiving unit 1201 is configured to perform transceiving operations performed by an ingress node of the IPSec tunnel in the above embodiments. The processing unit 1202 is configured to perform operations other than the transceiving operation performed by the ingress node of the IPSec tunnel mentioned in the above embodiment. For example, the processing unit 1202 is configured to obtain SRv6 a packet, and the transceiving unit 1201 is configured to send the SRv6 packet to an egress node of the IPSec tunnel.

In addition, an embodiment of the present application further provides a network apparatus 1300, which is used as an exit node of an IPSec tunnel, referring to fig. 13, where fig. 13 is a schematic structural diagram of a network apparatus provided in an embodiment of the present application. The network apparatus 1300 includes a communication interface 1301 and a processor 1302 connected to the communication interface 1301. The communication interface 1301 is used for the transceiving operation performed by the egress node of the IPSec tunnel in the above embodiment; processor 1302 is configured to perform operations other than transceiving operations performed by an egress node of the IPSec tunnel in the above embodiments. For example: communication interface 1301 is used to perform the steps of receiving SRV 6; the processor 1302 is configured to perform an AH check on the SRv6 packet according to the first indication information and the AH carried in the SRv6 packet.

In addition, an embodiment of the present application further provides a network device 1400, which is used as an entry node of an IPSec tunnel, referring to fig. 14, where fig. 14 is a schematic structural diagram of a network device provided in an embodiment of the present application. The network device 1400 includes a communication interface 1401 and a processor 1402 connected to the communication interface 1401. The communication interface 1401 is configured to perform the transceiving operation performed by the ingress node of the IPSec tunnel in the foregoing embodiment; processor 1402 is configured to perform operations other than transceiving operations performed by an ingress node of an IPSec tunnel in the embodiments described above. For example, processor 1402 may be configured to retrieve SRv6 a message and communication interface 1401 may be configured to transmit SRv6 the message to an egress node of the IPSec tunnel.

In addition, an embodiment of the present application further provides a network apparatus 1500, which is used as an egress node of an IPSec tunnel, referring to fig. 15, where fig. 15 is a schematic structural diagram of a network apparatus provided in an embodiment of the present application. The network device 1500 includes a memory 1501 and a processor 1502. Wherein, the memory 1501 is used for storing program codes; the processor 1502 is configured to execute the instructions in the program code to cause the egress node of the IPSec tunnel to perform the steps performed by the egress node of the IPSec tunnel in the above embodiments.

In addition, an embodiment of the present application further provides a network device 1600, which is used for an ingress node of an IPSec tunnel, referring to fig. 16, where fig. 16 is a schematic structural diagram of a network device provided in an embodiment of the present application. The network device 1600 includes a memory 1601 and a processor 1602. Wherein the memory 1601 is used for storing program codes; processor 1602 is configured to execute instructions in the program code to cause the ingress node of the IPSec tunnel to perform the steps performed by the ingress node of the IPSec tunnel in the above embodiments.

Embodiments of the present application further provide a computer-readable storage medium, which stores instructions that, when executed on a computer, cause the computer to perform the steps performed by the egress node of the IPSec tunnel in the above embodiments.

An embodiment of the present application further provides a computer-readable storage medium, which stores instructions that, when executed on a computer, cause the computer to perform the steps performed by the ingress node of the IPSec tunnel in the above embodiment.

An embodiment of the present application further provides a computer program product, which comprises a computer program that, when run on a computer, causes the computer to perform the steps performed by the ingress node of an IPSec tunnel or by the egress node of an IPSec tunnel in the embodiments described above.

The processor referred to in this application may be a Central Processing Unit (CPU), a Network Processor (NP), or a combination of a CPU and an NP. The processor may also be an application-specific integrated circuit (ASIC), a Programmable Logic Device (PLD), or a combination thereof. The PLD may be a Complex Programmable Logic Device (CPLD), a field-programmable gate array (FPGA), a General Array Logic (GAL), or any combination thereof. The processor may refer to one processor or may include a plurality of processors.

The memory referred to in this application may be any memory including volatile memory (RAM), such as random-access memory (RAM); the memory may also include a non-volatile memory (ROM), such as a read-only memory (ROM), a flash memory (flash memory), a hard disk (HDD) or a solid-state drive (SSD); the memory may also comprise a combination of memories of the kind described above. The memory may refer to one memory, or may include a plurality of memories.

In one embodiment, the memory referred to herein has stored therein computer-readable instructions comprising a plurality of software modules, such as a transceiver module and a processing module. After the processor executes each software module, the processor can perform corresponding operation according to the instruction of each software module. In the present embodiment, the operation performed by one software module actually refers to an operation performed by the processor according to the instruction of the software module. For example, in the method 200 described in the embodiment of the present application, the transceiver module may be used to implement operations related to receiving or sending in the method 200, for example, the transceiver module is used to perform an operation of receiving SRv6 messages in S201. The processing module is configured to perform an operation of processing the transceiving, for example, the processing module is configured to perform an AH check operation on the SRv6 packet according to the first indication information and the AH in S202.

The terms "first," "second," "third," "fourth," and the like in the description and in the claims of the present application and in the drawings described above, if any, are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It will be appreciated that the data so used may be interchanged under appropriate circumstances such that the embodiments described herein may be practiced otherwise than as specifically illustrated or described herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed, but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.

It is clear to those skilled in the art that, for convenience and brevity of description, the specific working processes of the above-described systems, apparatuses and units may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again.

In the several embodiments provided in the present application, it should be understood that the disclosed system, apparatus and method may be implemented in other manners. For example, the above-described embodiments of the apparatus are merely illustrative, and for example, a division of a unit is only a logical division, and an actual implementation may have another division, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.

Units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

In addition, each service unit in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit can be realized in a hardware form, and can also be realized in a software service unit form.

The integrated unit, if implemented in the form of a software business unit and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application may be substantially implemented or contributed to by the prior art, or all or part of the technical solution may be embodied in a software product, which is stored in a storage medium and includes instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method of the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk, and other various media capable of storing program codes.

Those skilled in the art will recognize that, in one or more of the examples described above, the services described in this disclosure may be implemented in hardware, software, firmware, or any combination thereof. When implemented in software, the services may be stored on or transmitted over as one or more instructions or code on a computer-readable medium. Computer-readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A storage media may be any available media that can be accessed by a general purpose or special purpose computer.

The above embodiments are intended to explain the objects, aspects and advantages of the present invention in further detail, and it should be understood that the above embodiments are merely illustrative of the present invention.

The above embodiments are only used to illustrate the technical solutions of the present application, and not to limit the same; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; and the modifications or the substitutions do not make the essence of the corresponding technical solutions depart from the scope of the technical solutions of the embodiments of the present application.

33页详细技术资料下载
上一篇:一种医用注射器针头装配设备
下一篇:域名系统中恶意域名的检测方法与检测装置

网友询问留言

已有0条留言

还没有人留言评论。精彩留言会获得点赞!

精彩留言,会给你点赞!

技术分类