WO2023030160A1 - 发送报文的方法、网络设备、存储介质及程序产品 - Google Patents

发送报文的方法、网络设备、存储介质及程序产品 Download PDF

Info

Publication number
WO2023030160A1
WO2023030160A1 PCT/CN2022/114821 CN2022114821W WO2023030160A1 WO 2023030160 A1 WO2023030160 A1 WO 2023030160A1 CN 2022114821 W CN2022114821 W CN 2022114821W WO 2023030160 A1 WO2023030160 A1 WO 2023030160A1
Authority
WO
WIPO (PCT)
Prior art keywords
encrypted
field
srh
message
header
Prior art date
Application number
PCT/CN2022/114821
Other languages
English (en)
French (fr)
Inventor
侯建强
何宏伟
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from CN202111295472.0A external-priority patent/CN115941227A/zh
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Publication of WO2023030160A1 publication Critical patent/WO2023030160A1/zh

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/74Address processing for routing

Definitions

  • the embodiments of the present application relate to the technical field of segment routing, and in particular to a method for sending a message, a network device, a storage medium, and a program product.
  • Point of presence (POP) networking is a network architecture based on software-defined wide area network (SD-WAN) technology.
  • SD-WAN software-defined wide area network
  • enterprise branch sites can access a nearby POP point of the POP network through the local Internet line, and then realize cross-regional business mutual visits through each POP point in the POP network, meeting the needs of enterprise networking, cloud access, and Internet access. and other business needs. Forwarding service data in a POP network needs to ensure the privacy of service data.
  • IPv6-based segment routing Segment Routing over IPv6, SRv6
  • first edge node (edge) in the POP network receives the business data destined for the second edge node, based on the first edge
  • the encrypted tunnel between the node and the second edge node encrypts the service data, and then encapsulates a segment routing header (segment routing header, SRH) before the encrypted service data to obtain the message to be forwarded.
  • the SRH includes a plurality of segment identifications (Segment ID, SID), and each SID in the plurality of SIDs indicates a POP point in the POP networking, so the SRH can indicate the forwarding path of the service data. Then forward the encapsulated message to forward the service data to the second edge node.
  • the SID information in the packets is easily stolen by criminals and used maliciously.
  • the present application provides a message sending method, network equipment, storage medium and program product, which can prevent the SID information in the SRv6 message transmitted in the network from being stolen by criminals and maliciously used. Described technical scheme is as follows:
  • a method for sending a message is provided.
  • a network device sends a message, the message includes a segment routing header SRH and a load, and the SRH includes an encrypted field (encrypted field) and an unencrypted field ( unencrypted field), the encrypted field at least includes an encrypted segment identification SID list, and the SID list indicates the transmission path of the message.
  • This application provides an SRH header encryption mechanism.
  • the SRH header encryption mechanism at least encrypts the SID list in the SRH. Based on the encryption mechanism of the SRH header, the SID list in the SRH of the SRv6 packet transmitted in the POP network is encrypted, so as to protect the SID information in the SRH header from being leaked.
  • the unencrypted field includes a field indicating the index of the last SID in the SID list.
  • the unencrypted field includes at least the field indicating the index of the last SID in the SID list (that is, the Last Entry field), and other nodes can determine the termination position of the SID list based on the Last Entry field, and then determine the starting point of the SRH based on the IPv6 header. start position, and then perform subsequent decryption operations.
  • the unencrypted field further includes a routing type field. At this time, other nodes do not need to determine the starting position of the SRH based on the IPv6 header, but determine it based on the route type field.
  • the unencrypted field further includes a reserved identification field, and a value of the reserved identification field indicates that the SID list has been encrypted.
  • the SRH includes an extended type length value TLV, the extended TLV carries encryption metadata, the encryption field is encrypted based on the encryption metadata, and the encryption metadata is not encrypted.
  • the encrypted metadata used for encryption can be carried in the message.
  • the encrypted metadata may carry an ESP header in the ESP technology.
  • the unencrypted field further includes a header extension length field.
  • the unencrypted field can also include the header extension length (Hdr Ext Length) field. Based on the header extension length field, other nodes can obtain the extended TLV before decrypting the SRH, and then obtain encrypted metadata.
  • the extended TLV includes an encrypted identification field, and the value of the encrypted identification field indicates the positions of the encrypted field and the unencrypted field in the SRH. Since some fields in the SRH are encrypted, the identification field of the extended TLV can be extended so that the value of the identification field indicates the positions of encrypted fields and unencrypted fields in the SRH.
  • the encrypted field further includes encrypted padding data
  • the extended TLV also carries the encrypted padding data
  • encrypted fields also include encrypted padding data.
  • the padding data is carried by extending the TLV.
  • the extended TLV also carries an integrity check value, and the integrity check value is at least used to check the integrity of the field before the SID list and the SID list in the SRH.
  • the encryption mechanism provided by the present application also provides the integrity check function for the SID list.
  • the network device sends a message, the message includes an encrypted part, the segment routing header SRH of the message is in the encrypted part, and the payload of the message is not in the encrypted part.
  • This application provides another SRH header encryption mechanism.
  • the SRH header encryption mechanism encrypts the entire SRH. Based on the SRH header encryption mechanism, the SRH of the SRv6 packet transmitted in the POP network is encrypted, so as to protect the SID information in the SRH header from being leaked.
  • the payload since the payload is not in the encrypted part, in the scenario where the payload is also encrypted, the payload is encrypted in other encrypted parts, so that the intermediate node on the transmission path of the first message only needs to decrypt the encrypted part to determine from the SRH The next hop does not need to decrypt the payload, and it also improves the forwarding efficiency of network equipment while protecting the secure transmission of the payload.
  • the message includes an extended message header, and the encrypted part is carried in the extended message header.
  • This application expands a new message header, which includes the overall encrypted SRH, so as to prevent the SID list from being exposed in the network.
  • the extended message header also carries encrypted metadata
  • the encrypted part is encrypted based on the encrypted metadata
  • the encrypted metadata is not included in the encrypted part.
  • the encrypted metadata used for encryption can be carried in the extended message header.
  • the encrypted metadata may carry an ESP header in the ESP technology.
  • the extended message header also carries an integrity check value, and the integrity check value is at least used to check the integrity of the extended message header.
  • the encryption mechanism provided by this application also provides an integrity check function for the extended message header.
  • the integrity check value when the value of the type field of the extended message header is the first value, the integrity check value is used to check the integrity of the extended message header and the IPv6 header of the first message , when the value of the type field of the extended message header is the second value, the integrity check value is used to check the integrity of the extended message header.
  • a flexible security verification mechanism Based on the extension of the type field in the extended message header, a flexible security verification mechanism can be implemented.
  • the IPv6 header of the first packet is located at the outer layer of the extended packet header, and the next header field in the IPv6 header indicates that the next packet header is the extended packet header.
  • the extended message header can be located in the inner layer of the IPv6 header to replace the SRH, so the value of the next header field in the IPv6 header needs to be extended.
  • the encrypted part further includes encrypted padding data.
  • the encrypted part also includes encrypted padding data.
  • the network device receives the first message, the first message includes a segment routing header SRH and a load, the SRH includes an encrypted field and an unencrypted field, and the encrypted field at least includes an encrypted segment identification SID list, and the SID list Indicate the transmission path of the first message; the network device decrypts the encrypted field to obtain the SRH not including the encrypted field; the network device processes the first message based on the SRH not including the encrypted field.
  • the network device processes the first packet based on the SRH that does not include the encrypted field: when the network device determines that it is not the destination of the payload based on the SRH that does not include the encrypted field
  • the payload-based next hop modifies the SRH that does not include the encrypted field, and generates a second packet based on the modified SRH, where the second packet includes the modified SRH and the payload; and the network device sends the second packet.
  • the network device may also encrypt the modified SRH.
  • the SRH in the second packet includes an encrypted field and an unencrypted field.
  • the unencrypted field includes a field indicating the index of the last SID in the SID list.
  • the implementation process of the aforementioned decryption and encryption fields is as follows: the network device determines the termination position of the SID list based on the field indicating the index of the last SID in the SID list in the SRH; the IPv6 header of the first packet of the network device determines the SID list The starting position of the network device determines to obtain the encrypted SID list based on the starting position and the ending position of the SID list, so as to decrypt the encrypted SID list.
  • the unencrypted field includes a field indicating the index of the last SID in the SID list and a routing type field.
  • the implementation process of the aforementioned decryption and encryption fields is as follows: the network device determines the end position of the SID list based on the field indicating the index of the last SID in the SID list in the SRH; the network device determines the start of the SID list based on the routing type field Location: The network device determines to obtain the encrypted SID list based on the starting location and the ending location of the SID list, so as to decrypt the encrypted SID list.
  • the unencrypted field further includes a reserved identification field.
  • the implementation process for the network device to decrypt the encrypted field may be: when the value of the reserved identification field indicates that the SID list has been encrypted, perform the operation of decrypting the encrypted field.
  • the SRH includes an extended type length value TLV
  • the extended TLV carries encrypted metadata
  • the encrypted metadata is not encrypted.
  • the aforementioned implementation process of the network device decrypting the encrypted field is as follows: the network device obtains the encrypted metadata from the extended TLV; and the network device decrypts the encrypted field based on the encrypted metadata.
  • the unencrypted field includes a field indicating the index of the last SID in the SID list and a header extension length field.
  • the network device may also obtain the extended TLV based on the header extension length field and the field indicating the index of the last SID in the SID list.
  • the value of the type field of the extended TLV indicates the position of the encrypted field and the unencrypted field in the SRH.
  • the network device may also determine the position of the encryption field in the SRH based on the type field of the extended TLV.
  • the encrypted field further includes encrypted padding data
  • the extended TLV also carries the encrypted padding data.
  • the implementation process for the network device to decrypt the encrypted field is: delete the padding data from the decrypted field to obtain the SRH that does not include the encrypted field.
  • the extended TLV also carries an integrity check value.
  • the network device can also verify the integrity of the fields in front of the SID list in the SRH and the integrity of the SID list based on the integrity check value; the fields in the SRH in front of the SID list and the integrity of the SID list are not damaged In the case of , perform the operation of decrypting the encrypted field.
  • the network device receives the first message, the first message includes an encrypted part, the segment routing header SRH of the first message is in the encrypted part, and the load of the first message is not in the encrypted part;
  • the network device decrypts the encrypted part to obtain the SRH; the network device processes the first message based on the SRH.
  • the implementation process of the network device processing the first packet based on the SRH is: when the network device determines that it is not the destination of the payload based on the SRH, modify the SRH based on the next hop of the payload, A second packet is generated based on the modified SRH, where the second packet includes the modified SRH and a payload.
  • the network device further encrypts the modified SRH, and correspondingly, the second packet includes an encrypted part, and the encrypted modified SRH is in the encrypted part.
  • the first packet includes an extended packet header
  • the encrypted part is carried in the extended packet header.
  • the network device obtains the encrypted part from the extended packet header.
  • the extended packet also carries encrypted metadata.
  • the implementation process for the network device to decrypt the encrypted part is as follows: the network device decrypts the encrypted part based on the encrypted metadata.
  • the extended message header also carries an integrity check value.
  • the implementation process of the decryption and encryption part of the network device is: verify the integrity of the extended message header based on the integrity check value; when the integrity of the extended message header is not damaged, execute the decryption and encryption part operation.
  • the implementation process of verifying the integrity of the extended message header based on the integrity check value is as follows: when the value of the type field of the extended message header is the first value, based on the integrity The check value performs integrity check on the IPv6 header of the extended message header and the first message; when the value of the type field of the extended message header is the second value, the extended message is checked based on the integrity check value header integrity check.
  • the IPv6 header of the first packet is located at the outer layer of the extended packet header, and the next header field in the IPv6 header indicates that the next packet header is the extended packet header.
  • the network device obtains the extended packet header based on the next header field in the IPv6 header.
  • the encrypted part further includes encrypted padding data.
  • the implementation process for the network device to decrypt the encrypted part is: delete the padding data from the decrypted field to obtain the SRH.
  • a network device in a fifth aspect, has a function of implementing the behavior of the method for sending a message in the first aspect above.
  • the network device includes at least one module, and the at least one module is configured to implement the method for sending a message provided in the first aspect above.
  • a network device in a sixth aspect, has a function of implementing the behavior of the method for sending a message in the second aspect above.
  • the network device includes at least one module, and the at least one module is configured to implement the method for sending a message provided in the second aspect above.
  • a network device in a seventh aspect, has a function of implementing the behavior of the method for sending a message in the above third aspect.
  • the network device includes at least one module, and the at least one module is configured to implement the method for sending a message provided in the third aspect above.
  • a network device in an eighth aspect, has a function of implementing the behavior of the method for sending a message in the fourth aspect above.
  • the network device includes at least one module, and the at least one module is configured to implement the method for sending a message provided in the fourth aspect above.
  • a network device in a ninth aspect, includes: a memory storing instructions;
  • a computer-readable storage medium is provided, and instructions are stored in the computer-readable storage medium, and when the computer-readable storage medium is run on a processor, the aforementioned first aspect or the second aspect or the third aspect or the first aspect is realized.
  • a computer program product in an eleventh aspect, includes a program, and when the program is run on a processor, any of the aforementioned first aspect or second aspect or third aspect or fourth aspect can be realized.
  • FIG. 1 is a schematic diagram of a mutual access path between an enterprise branch and a headquarters based on a POP networking provided by an embodiment of the present application;
  • FIG. 2 is a schematic diagram of a system architecture of a POP networking provided by an embodiment of the present application
  • FIG. 3 is a schematic diagram of a hardware and software architecture of an edge node provided by an embodiment of the present application.
  • FIG. 4 is a schematic diagram of a hardware and software architecture of a POP node provided by an embodiment of the present application
  • FIG. 5 is a schematic diagram of the format of an IPv6 data message carrying an SRH provided by an embodiment of the present application
  • FIG. 6 is a flow chart of a method for sending a message provided in an embodiment of the present application.
  • FIG. 7 is a schematic diagram of an encryption technology provided by an embodiment of the present application.
  • Fig. 8 is a schematic diagram of the format of a first message provided by the embodiment of the present application.
  • FIG. 9 is a schematic flow chart of sending a message provided by an embodiment of the present application.
  • FIG. 10 is a flow chart of another method for sending a message provided by an embodiment of the present application.
  • FIG 11 is a schematic diagram of another encryption technology provided by the embodiment of the present application.
  • FIG. 12 is a schematic diagram of the format of another first message provided by the embodiment of the present application.
  • FIG. 13 is a schematic flow chart of sending a message provided by an embodiment of the present application.
  • FIG. 14 is a schematic structural diagram of a network device provided by an embodiment of the present application.
  • POP networking is a typical application scenario in SD-WAN.
  • enterprises or operators can deploy virtualized SD-WAN devices on the public cloud as the access point of the POP network.
  • the access point is also called a POP node, and utilizes inter-cloud Internet and cloud dedicated line resources , quickly and flexibly build an SD-WAN backbone network covering a large area.
  • Enterprise branch sites are connected to the nearest POP node through the local Internet line, and cross-regional business mutual access is realized through the SD-WAN backbone network on the cloud to meet the business needs of enterprise networking, cloud access, and Internet access.
  • the aforementioned SD-WAN backbone network is also called a POP backbone network.
  • An enterprise's POP backbone network can be constructed based on cloud resources provided by different public cloud service providers to improve the coverage of POP nodes in the POP backbone network.
  • POP networking needs to support multiple POP nodes, and support cross-POP end-to-end dynamic route selection.
  • FIG. 1 is a schematic diagram of the mutual access path between the enterprise branch and the headquarters based on POP networking provided by the embodiment of the present application.
  • the mutual access paths between the enterprise branch and the headquarters can include the following optional paths.
  • Path 1 (marked as 1 in Figure 1) is a cross-POP path. Path 1 includes two POP nodes, and the POP nodes communicate through cloud dedicated lines.
  • Path 2 (marked as 2 in Figure 1) is also a cross-POP path. Path 2 includes two POP nodes, and the POP nodes communicate through the Internet on the cloud.
  • the third path is also a cross-POP path (marked as 3 in Figure 1). There are three POP nodes on the third path, and the three POP nodes can communicate through the cloud dedicated line or the Internet on the cloud.
  • Path 4 (marked as 4 in Figure 1) is a direct connection path, and the enterprise branch and the site are directly connected through the Internet.
  • Path five (marked as 5 in Figure 1) is also a direct connection path, and the enterprise branch and the site are directly connected through a dedicated line.
  • the common implementation solution of SD-WAN manufacturers in the industry is to use segmented tunnels and hop-by-hop encryption and decryption.
  • the principle of the scheme is: establish an IPsec encrypted tunnel between edge nodes and POP nodes based on the Internet, establish an IPsec encrypted tunnel between POP nodes and POP nodes based on the Internet, or establish an IPsec encrypted tunnel between POP nodes and POP nodes based on operator dedicated lines or cloud Dedicated lines establish encrypted or unencrypted tunnels.
  • the edge node refers to a node on the edge side in the POP network, and the edge node is used to connect the user's message to the POP network.
  • Service messages are transmitted in the POP network based on segment-by-segment tunnels. After the POP decrypts and decapsulates the received service messages, it searches the route according to the IP header of the service messages to find the next hop, and then re-encapsulates and forwards them to the next-hop POP. node or edge node.
  • Segment Routing The scheme principle of transmitting service packets in the POP network based on segment routing is as follows: an end-to-end IPsec encrypted tunnel is established between edge nodes across intermediate POP nodes. When the edge node encapsulates the service packet, the SRH is encapsulated outside the IPsec encapsulation, and the SRH is not encrypted. The SRH records the SID information of the POP node through which the service message passes. The edge node uses the tunnel to send the encapsulated service message to the POP node. When the POP node receives the service message, it does not decapsulate the IPsec message in the service message, and directly forwards the next hop according to the SID information in the SRH. Can.
  • the above solution for forwarding service packets realizes end-to-end encryption of POP networking.
  • the intermediate POP node can forward the service message without decrypting the IPsec message in the service message, so the forwarding efficiency of the POP node is relatively high.
  • the above solution supports the transmission of service messages across multiple POP nodes on the POP network, and the transmission path of service messages can be centrally regulated, so it can support end-to-end route selection across POPs.
  • the embodiment of this application introduces a new SRH encryption technology to solve the above-mentioned contradiction between the performance and security of POP nodes, which not only ensures the forwarding performance of POP nodes in the POP network, but also solves the problem of SID information leakage, reporting Security issues such as text validity verification.
  • FIG. 2 is a schematic diagram of a system architecture of a POP networking provided by an embodiment of the present application.
  • the POP network includes a network controller, a first edge node, multiple POP nodes (POP node 1, POP node 2 and POP node 3 are illustrated in FIG. 2 ) and a second edge node.
  • the communication between the first edge node and POP node 1 is carried out by wired or wireless means
  • the communication between POP node 1 and POP node 2 is carried out by wired or wireless means
  • the communication between POP node 2 and POP node 3 is carried out by wired or wireless means.
  • Communication is carried out in a wired or wireless manner between the POP node 3 and the second edge node.
  • Each edge node and POP node communicates with the network controller in a wired or wireless manner.
  • the network controller in Figure 2 is used to provide the orchestration and network management functions of the POP network. These functions include but are not limited to device deployment of edge nodes and POP nodes, unified management of devices, POP network creation, SR path policy regulation, and various network value-added service policy definitions, alarm/log information collection, link quality statistics, etc. .
  • Edge nodes that is, edge nodes on the enterprise site side that need to be interconnected through POP networking.
  • Edge nodes include enterprise branch sites, corporate headquarters or data center sites, and public cloud sites.
  • the first edge node may be, for example, an edge node deployed on an enterprise branch side, and the first edge node is used to connect the enterprise branch to a POP network.
  • the second edge node may be, for example, an edge node deployed at the enterprise headquarters side, and the second edge node is used to connect the enterprise headquarters to the POP network. Therefore, based on the POP network shown in Figure 2, the enterprise branch and the enterprise headquarters communicate with each other through the POP network.
  • POP nodes as intermediate nodes in the POP network, are on the one hand the entry gateway for edge nodes to access the POP network, and at the same time use the underlying (Underlay) backbone network provided by operators or public clouds to realize the current POP network to other Interconnection of regional POP networks.
  • underlying Underlay
  • edge nodes and three POP nodes are taken as examples in FIG. 2 , and the embodiment of the present application does not limit the number of edge nodes and POP nodes included in the POP networking.
  • FIG. 3 is a schematic diagram of a hardware and software architecture of an edge node provided by an embodiment of the present application.
  • the software of the edge node includes a management module, a routing module, a service module, and an operating system. These software modules run on the hardware of edge nodes.
  • the business module is also called the user plane (User Plane), forwarding plane or data plane.
  • the service module is used to process and forward various types of data on different ports on the device.
  • the service module also implements traffic forwarding based on forwarding entries through hardware.
  • the routing module is also called the Control Plane.
  • the routing module is used to control and manage the operation of all network protocols.
  • the routing module also provides various network information and forwarding lookup items necessary for the data plane.
  • the management module is also called the Management Plane.
  • the management module is used for system operation and maintenance personnel (or external third-party management software), providing input and output, user management, authentication (License), management object monitoring, configuration, alarm, statistics, etc., and does not directly affect the operating status of the system. Influence.
  • the hardware of edge nodes includes processors, memory, hard disks, and communication chips.
  • the processor in Fig. 3 can be a general-purpose central processing unit (central processing unit, CPU), application-specific integrated circuit (application-specific integrated circuit, ASIC) or one or more integrated circuits for controlling the execution of the program program of this application .
  • CPU central processing unit
  • ASIC application-specific integrated circuit
  • the memory in Figure 3 refers to the internal memory that directly exchanges data with the processor. It can read and write data at any time, and the speed is very fast. It is used as a temporary data storage for the operating system or other running programs.
  • Memory includes at least two kinds of memory, for example, memory can be either random access memory or read-only memory (Read Only Memory, ROM).
  • the random access memory is dynamic random access memory (Dynamic Random Access Memory, DRAM), or storage class memory (Storage Class Memory, SCM).
  • DRAM Dynamic Random Access Memory
  • SCM Storage Class Memory
  • the hard disk in FIG. 3 is used to provide storage resources, such as storing data. It can be a magnetic disk or other types of storage media, such as solid state drives or shingled magnetic recording hard drives.
  • the communication chip in Figure 3 uses any device such as a transceiver for communicating with other devices or communication networks, such as Ethernet, radio access network (radio access network, RAN), wireless local area networks (wireless local area networks, WLAN), etc.
  • a transceiver for communicating with other devices or communication networks, such as Ethernet, radio access network (radio access network, RAN), wireless local area networks (wireless local area networks, WLAN), etc.
  • POP nodes can be deployed on servers in a virtualized manner.
  • the POP node is deployed in the operator's data center, or on the public cloud.
  • the software and hardware architecture of the POP node is shown in Figure 4.
  • the system architecture of a virtualized POP node includes a hardware platform, a virtualization platform (hypervisor) and a virtual machine execution space.
  • the hardware platform refers to the physical structure of the POP node, specifically including processors, memory, hard disks, and network cards.
  • the virtualization platform provides an intermediate layer between physical hardware and virtual machines, and is responsible for coordinating the access of each virtual machine to the hardware platform.
  • Each virtual machine runs in the virtual machine execution space, and each virtual machine is equivalent to a virtual POP node, thereby realizing the function of the POP node.
  • the operating system of the virtual machine runs on a virtual hardware platform, which includes a virtual memory (memory), a virtual processor, a virtual hard disk (storage), and a virtual network card (nic).
  • Each virtual machine includes a control plane and a forwarding plane.
  • the control plane is used to manage the forwarding policy of the POP node, and the forwarding plane is used for the POP node to forward service packets, that is, the forwarding plane and the control plane of the POP node are decoupled.
  • the POP node may also be in the form of a physical device.
  • the software and hardware architecture of the POP node is basically the same as that of the edge node in FIG. 3 , and will not be repeated here.
  • the foregoing uses the POP networking as an example to illustrate the application scenario of the present application.
  • the SRH encryption technical solution provided in the embodiment of the present application may also be applied in other scenarios of sending packets based on the SR technology, and no further examples are given here.
  • the SR based on the IPv6 forwarding plane inserts a routing extension header (segment routing header, SRH) into the IPv6 message, pushes an explicit IPv6 address stack into the SRH, and continuously updates the destination address and offset through the intermediate node.
  • the operation of shifting the address stack is used to complete hop-by-hop forwarding.
  • the SRv6 technology adopts the above-mentioned IPv6 forwarding technology and implements network programmability through flexible IPv6 extension headers.
  • SRv6 defines some IPv6 addresses as instantiated SIDs. Each SID has its own explicit role and function. Through different SID operations, simplified VPN and flexible path planning are realized.
  • FIG. 5 is a schematic diagram of the format of an IPv6 data packet carrying an SRH provided by an embodiment of the present application.
  • the IPv6 data message includes an IPv6 header (the IPv6 header is also the outer IP header), SRH, an inner IP header and a payload (the inner IP header and the payload are not shown in FIG. 5 ).
  • the IPv6 header includes a version field, a traffic category field, a flow label field, a payload length field, a next header field, a hop limit field, a source address field, and a destination address field.
  • the next header field indicates the type of the next header in the IPv6 header in the IPv6 data packet.
  • the source address indicates the source address of the IPv6 data message, and the destination address indicates the destination address of the IPv6 data message.
  • SRH includes the next header (Next Header) field, header extension length (Hdr Ext len) field, routing type (Routing type) field, remaining node number (Segment Left, SL) field, indicating that in the SID list
  • the last SID index (Last Entry) field flags (Flags) field, tag (Tag) field, SID list field, and optional type-length-value (type-length-value, TLV) field.
  • the length of each of the six fields of the next header field, the header extension length field, the routing type field, the SL field, the field indicating the index of the last SID in the SID list, and the identification field is 8 bits, and the length of the label field is is 16 bits.
  • the total length of these 7 fields is 8 bytes, and the length of the first 8 bytes in the SRH is fixed.
  • the part before the optional TLV in the SRH is called the SRH standard header, such that the SRH includes the SRH standard header and the optional TLV, and the SRH standard header includes the first 8 fixed bytes and the SID list.
  • next header field indicates the type of the next message header located in the SRH
  • header extension length field indicates the length of other fields in the SRH excluding the first 8 bytes.
  • the route type field indicates the type of the current header, for example, the value of the route type field is equal to 4, indicating that the current packet header is SRH.
  • the number of remaining nodes indicates the number of intermediate nodes that should still be visited before reaching the destination node, and the number of remaining nodes is decremented by 1 every time a message passes through a node indicated by a SID in the SID list.
  • the identification field is used to carry identification information of some data packets, and the label field is used to identify the same group of data packets.
  • Optional TLVs are used by SRH to implement more functions.
  • the SID list includes N+1 SIDs such as Segment List[0], Segment List[1], ..., Segment List[N].
  • Each SID may correspond to a 128-bit IPv6 address, which is used to identify the node or link with the SID on the forwarding path.
  • the first edge node when the first edge node sends a message to the second edge node, it can directly determine a forwarding path from the first edge node to the second edge node , based on the SID of each node on the forwarding path, the SRH header is encapsulated in the message, so as to realize end-to-end direct route selection in the POP networking.
  • the SRH encryption technology provided by the embodiment of the present application is explained in detail below.
  • the embodiment of the present application provides two SRH encryption mechanisms.
  • these two SRH encryption mechanisms are respectively referred to as a first SRH encryption mechanism and a second SRH encryption mechanism.
  • the first SRH encryption mechanism is to encrypt only part of the information in the SRH (the part of information includes at least the SID list), and the second SRH encryption mechanism is to encrypt the complete SRH.
  • the following two embodiments are used to describe the two SRH encryption mechanisms respectively.
  • FIG. 6 is a flow chart of a method for sending a message provided by an embodiment of the present application. This method is used to explain the first SRH encryption mechanism. As shown in Figure 6, the method includes the following steps.
  • Step 601 The first device sends a first message, the first message includes SRH and payload, SRH includes an encrypted field and an unencrypted field, the encrypted field includes at least an encrypted segment identification SID list, and the SID list indicates that the first packet file transfer path.
  • some fields in the SRH are encrypted, and after encryption, the SRH still appears as an SRH format to the outside world, but some fields are changed from plaintext to ciphertext, so SRH needs to include unencrypted fields, and subsequent nodes are based on It can be known that the current packet header is an SRH without encrypting the fields.
  • the unencrypted field includes a field indicating the index (Last Entry) of the last SID in the SID list. Since the length of the first 8 bytes in the SRH is fixed, and the starting position of the SRH can be specified according to the IPv6 header of the SRH outer layer, the starting position and the ending position of the SID list can be specified according to the Last Entry field, and also That is, the specific location of the SID list is determined.
  • the unencrypted field may further include a routing type (Routing type) field in addition to the Last Entry field.
  • Routing type routing type
  • other nodes can confirm the specific location of the SRH based on the routing type (Routing type) field and the Last Entry field.
  • some information used in the encryption process may also be added to the message, so that other nodes may subsequently decrypt the encrypted field based on the information.
  • some information used in the encryption process can be carried by extending the TLV, and the relevant content of the extended TLV will be explained in detail later.
  • the unencrypted field may further include a header extension length (Hdr Ext len) field.
  • the specific position of the TLV in the SRH can be determined according to the Hdr Ext len field and the aforementioned Last Entry field, so that other nodes can be based on the extension TLV to obtain some information used in the encryption process, and then decrypt the encrypted field based on this information.
  • the encrypted field in the SRH needs to include at least the SID list, so as to prevent the SID list from being exposed in the network.
  • the reserved identification (flags) field of the SRH standard header can also be extended to The value of the reserved identification field can indicate whether the SID list is encrypted.
  • the reserved identification field includes a specific bit. When the value of this bit is 1, it indicates that the SID list in the SRH is encrypted. When the value of this bit is 0, it indicates that the SID list in the SRH is encrypted. The SID list is not encrypted.
  • the reserved identification field in the SRH When the value of the reserved identification field in the SRH is used to indicate whether the SID list is encrypted, the reserved identification field cannot be encrypted, that is, the aforementioned unencrypted field also includes the reserved identification field .
  • the above extension may not be performed on the reserved identification field.
  • the reserved identification field can be placed in an encrypted field or an unencrypted field.
  • the encrypted field may further include an SL field, so as to prevent an attacker from inferring a forwarding path after the packet based on the SL field.
  • the encryption field may also include a next header field, a label field, and so on.
  • the first device can generate the above-mentioned first packet and send the first packet.
  • Step 601 will be explained in detail below by taking the example that the first device is the first edge node in the POP networking shown in FIG. 2 and the destination of the payload of the first packet is the second edge node.
  • step 601 can be implemented through the following steps.
  • Step (1) The first edge node receives the service message sent by the local area network (LAN) side of the enterprise branch.
  • LAN local area network
  • the service packet includes an inner IP header (the inner IP header is also referred to as an original IP header) and a payload.
  • the inner layer IP header carries the source IP address and the destination IP address of the business message, wherein, the source IP address can be the IP address of a terminal device in the local area network (LAN) of the enterprise branch, and the destination IP address can be the enterprise headquarters IP address of an end device in the local area network.
  • LAN local area network
  • Step (2) The first edge node generates an SRH, and encrypts part of the information in the SRH, so that the SRH includes encrypted fields and unencrypted fields.
  • the first edge node determines a forwarding path based on the destination IP address in the inner layer IP header of the service message. As shown in FIG. 2 , the forwarding path is: first edge node ⁇ POP node 1 ⁇ POP node 2 ⁇ POP node 3 ⁇ second edge node. Based on the forwarding path, determine the SID list in the SRH, the SID list includes the SID of POP node 1, the SID of POP node 2, the SID of POP node 3 and the SID of the second edge node.
  • the unencrypted SRH can be generated based on the SID list and the basic format of the SRH.
  • the encrypted field at least includes an encrypted SID list.
  • FIG. 7 is a schematic diagram of an encryption technology provided by an embodiment of the present application.
  • the field to be encrypted in the SRH is encrypted using the Encapsulating Security Payload (ESP) encryption technology.
  • ESP Encapsulating Security Payload
  • the basic principle of ESP encryption technology is: use the encryption key together with the field to be encrypted in the SRH (only the SID list is illustrated in Figure 7) and the ESP trailer (trailer), and encrypt it through an encryption algorithm to obtain an encrypted field. Since SRH is currently encrypted, in order to distinguish other ESP technologies in the future, the ESP tail used for SRH encryption in Figure 7 and later is called SRH ESP tail.
  • the integrity check value (integrity check value, ICV) through the verification algorithm
  • the integrity check value is the SRH verification result.
  • Subsequent other nodes may first check the integrity of the SRH according to the integrity check value, and then decrypt the encrypted field after the integrity check is passed, so as to obtain the SRH not including the encrypted field.
  • the ESP header used for SRH encryption is called SRH ESP header
  • the integrity check value generated based on SRH is called SRH ESP check value.
  • the positions of the SRH ESP header, SRH ESP tail, and SRH ESP check value in the message at the bottom of Figure 7 are not the actual positions of the SRH ESP header, SRH ESP tail, and SRH ESP check value in the message. 7 is used to illustrate the functions of SRH ESP header, SRH ESP trailer and SRH ESP check value. The actual positions of the SRH ESP header, SRH ESP tail, and SRH ESP check value will be detailed in the following figure 8.
  • the SRH ESP tail includes padding data (Padding) and padding length (Pad length).
  • padding data Padding
  • padding length padding length
  • the filling length refers to the length of the filled data segment, which is convenient to find the data segment used for filling when unpacking.
  • the SRH ESP header consists of two parts: Security Parameter Index (SPI) and Sequence Number.
  • SPI Security Parameter Index
  • Sequence Number the SPI determines the security association (SA) corresponding to the encrypted field, and other nodes can perform integrity verification on the encrypted field according to the digest algorithm and verification key specified by SA, and according to the encryption algorithm and decryption key specified by SA key to decrypt encrypted fields. Sequence numbers are used to keep data fresh and avoid replay attacks.
  • the above ESP encryption technology is an optional encryption implementation in the embodiment of the present application, and any encryption technology can be used to encrypt the field to be encrypted in the SRH.
  • the service message can also be encrypted and encapsulated with IPsec.
  • the service message encapsulated based on IPsec encryption includes the ESP header, the inner layer IP Header, payload, ESP trailer, and ESP check value.
  • the service packet encrypted and encapsulated based on IPsec is called the inner layer IPsec encrypted payload.
  • the relevant explanation of the ESP header, ESP trailer, and ESP check value in the IPsec-encrypted and encapsulated service message please refer to the above-mentioned relevant explanation of ESP encryption for SRH, and will not be described in detail here.
  • the foregoing integrity check value is generated based on the SRH standard header, so the integrity check value is used to perform integrity check on the SRH standard header.
  • an integrity check value can also be generated according to the entire SRH including the encrypted field, and the integrity check value is used to check the first 8 in the SRH Integrity of bytes, SID lists, and extended TLVs.
  • an integrity check value can also be generated according to the entire SRH and IPv6 header, and at this time, the integrity check value is used to check the integrity of the SRH and the IPv6 header. sex.
  • an integrity check flag field can also be extended in the SRH, and the value of the integrity check flag field can indicate which part of the integrity check value the integrity check value is used to check.
  • the embodiment of the present application does not limit the specific position of the integrity check mark field.
  • the aforementioned integrity check flag field may be extended in the aforementioned SRH flags (Flags) field. That is, in this embodiment of the present application, the Flags field of the SRH further includes an integrity check flag field, and the value of the integrity check flag field indicates the fields that need to be completely checked.
  • the uniformly agreed integrity check value is used to check the integrity of the first 8 bytes in the SRH and the SID list. Or it is uniformly agreed that the integrity check value is used to check the integrity of the entire SRH.
  • the integrity check value for the encrypted fields may not be generated, so that only the encrypted fields need to be decrypted later, and it is not necessary to complete the encrypted fields. sex check.
  • some information used in the encryption process can be added to the message so that other nodes can decrypt the encrypted fields based on the information, or decrypt and check.
  • each node in the network agrees to use a unified encryption verification technology in advance, then there is no need to add some information used in the encryption process to the message, and other nodes process the encrypted fields based on the agreed encryption verification technology That's it.
  • Some of the information used in the process of encrypting the field to be encrypted in the SRH may be called encryption metadata.
  • a TLV may be extended in the SRH, that is, an extended TLV may be added in the SRH, and the extended TLV is used to carry the aforementioned encrypted metadata.
  • the extended TLV carries encrypted metadata
  • the encrypted field in the SRH is encrypted based on the encrypted metadata, and it is necessary to ensure that the encrypted metadata is not encrypted, so that other nodes can subsequently perform SRH based on the encrypted metadata.
  • Encrypted fields are processed.
  • the encrypted metadata includes the SRH ESP header in the aforementioned ESP technology.
  • the identification field of the extended TLV may be extended so that the value of the identification field indicates the positions of encrypted fields and unencrypted fields in the SRH.
  • the extended TLV may also include an encryption flag (encryption flags) field, which indicates the positions of the encrypted field and the unencrypted field in the SRH, so that subsequent other nodes can determine which fields in the SRH are based on the encrypted flag field. Encrypted.
  • the encryption identification field includes 8 bit groups, and these 8 bit groups are respectively related to the next header field, the header extension length field, the routing type field, the SL field, the indication
  • the eight fields of the last SID index field, identification field, label field, and SID list field in the SID list correspond one by one.
  • the value on each bit group indicates whether the corresponding field is encrypted.
  • the encryption identification field includes 8 bits, and these 8 bits are in one-to-one correspondence with the aforementioned 8 fields. For any bit, when the value of the bit is 1, it indicates that the corresponding field is encrypted, and when the value of the bit is 0, it indicates that the corresponding field is not encrypted.
  • the extended TLV also carries encrypted padding data.
  • the encrypted field in the SRH at this time also includes encrypted padding data.
  • the extended TLV when an integrity check value is determined for the encrypted field, the extended TLV also carries an integrity check value, and the integrity check value is used to check the integrity of the encrypted field in the SRH.
  • Fig. 8 is a schematic diagram of the format of a first message provided by the embodiment of the present application.
  • the first packet includes an IPv6 header, SRH, inner layer IP header and payload.
  • IPv6 header the fields in the IPv6 header and the explanation of the inner layer IP header can refer to the above related content, and will not be repeated here.
  • SRH includes SRH standard header and extended TLV.
  • the encrypted fields in the SRH in Fig. 8 include the Next Header (Next Header) field, the SL field, the Tag (Tag) field and the SID list field.
  • the unencrypted fields include the header extension length (Hdr Ext len) field, the routing type (Routing type) field, the field indicating the index (Last Entry) of the last SID in the SID list, and the flags (Flags) field.
  • the value of the first bit in the identification field in the SRH is 1, indicating that the SID list in the SRH is encrypted.
  • the extended TLV includes a type field, a length field, an encrypted identification field, a reserved field, an SPI field, a serial number field, a padding data field, a padding length field, and an integrity check value field.
  • the type field is a type that requires a new application, and the type is used to indicate that the extended TLV is used to carry encrypted metadata.
  • the length field indicates the length of the extended TLV.
  • the encrypted identification field includes 8 bits, which are respectively related to the next header field, the header extension length field, the routing type field, the SL field, the field indicating the index of the last SID in the SID list, the identification field, and the label field , SID list field, these 8 fields correspond one by one. The value on each bit group indicates whether the corresponding field is encrypted.
  • the SPI field and the serial number field are used to carry the SPI and serial number in the aforementioned SRH ESP header respectively.
  • the padding data field and padding length field are used to carry the padding data and padding length in the aforementioned SRH ESP tail respectively.
  • the integrity check value field is used to carry the aforementioned ICV obtained based on the ESP technology.
  • the field to be encrypted in the SRH standard header, the padding data field and the padding length field are used together with an encryption key, and encrypted by an encryption algorithm, so that each field to be encrypted in the SRH in Figure 8 is composed of Plaintext becomes ciphertext.
  • FIG. 8 is an optional implementation manner of the extended TLV provided by the embodiment of the present application, and the embodiment of the present application does not limit the specific format of the extended TLV.
  • Step (3) The first edge node encapsulates the encrypted SRH in the outer layer of the service message, and then continues to encapsulate the IPv6 header in the outer layer of the SRH to obtain the aforementioned first message, and then sends the first message.
  • the first edge node After the first edge node encrypts the SRH, it can obtain the first message through the above step (3).
  • the obtained SID list in the SRH of the first packet is an encrypted SID list, so that the SID list can be prevented from being exposed in the network.
  • the IPv6 header carries the destination IP address
  • the destination IP address in the IPv6 header is the IP address corresponding to the next SID after the SID of the first edge node in the SID list.
  • the first edge node before the first edge node encapsulates the encrypted SRH in the outer layer of the service message, it can also encrypt and encapsulate the service message based on IPsec to ensure the security of the service message.
  • FIG. 9 is a schematic flow chart of sending a message according to an embodiment of the present application.
  • the first edge node receives a service message from the LAN side, the service message includes a payload and an inner layer IP header, searches for a route according to the destination IP in the inner layer IP header, and determines the purpose of the service message IP address of the tunnel interface of the second edge node.
  • the first edge node determines the SID list in the SRH after packet encapsulation based on the tunnel interface IP of the second edge node according to the SR path scheduling policy configured locally or centrally delivered by the network controller.
  • the first edge node performs IPsec encryption and encapsulation on the service message, and the encapsulation content includes an inner IP header and a payload.
  • the first edge node adds an SRH to the IPsec encrypted and encapsulated message, and encrypts and encapsulates the SID list in the SRH.
  • the first edge node re-encapsulates the packet encrypted by the SRH with an IPv6 header to obtain the aforementioned first packet, and then forwards the first packet from the WAN interface to the POP network.
  • the service message may also have been encapsulated with SRH.
  • the first edge node may directly encrypt the SRH based on the above encryption mechanism.
  • Step 602 The second device receives the first message.
  • any node in the network After the first device sends the first message, any node in the network, after receiving the first message, first compares its own IPv6 address with the destination IP address in the IPv6 header of the first message. , then search the local route based on the destination IP address in the IPv6 header of the first message, and then continue to forward the first message based on the found route. If they are consistent, the SRH needs to be decapsulated, and then the first message is processed according to the following steps 603 and 604.
  • the second device may be any POP node or the second edge nodes.
  • Step 603 The second device decrypts the encrypted field to obtain an SRH that does not include the encrypted field.
  • an intermediate node when an intermediate node receives a message, it needs to determine the current operation according to the SRH. Therefore, when receiving the first message, the second device needs to decrypt the encrypted field first, so that the encrypted field in the SRH is converted from plaintext to ciphertext.
  • step 603 when the unencrypted field in step 601 includes the field indicating the index of the last SID in the SID list, the implementation process of step 603 is as follows; the second device indicates the last SID in the SID list based on the SRH The field of the index determines the end position of the SID list, the second device determines the start position of the SID list based on the IPv6 header, and the second device obtains the encrypted SID list based on the start position of the SID list and the end position of the SID list, to Decrypt the SID list.
  • the second device can further determine the start position of the SID list after obtaining the start position of the SRH based on the IPv6 header.
  • step 603 when the unencrypted field in step 601 includes the field indicating the index of the last SID in the SID list and the routing type field, the implementation process of step 603 is as follows; the second device indicates the SID list based on the SRH The field of the index of the last SID in , determines the end position of the SID list, the second device determines the start position of the SID list based on the routing type field, and the second device obtains the encrypted After the SID list, to decrypt the SID list.
  • the unencrypted field in step 601 includes a reserved identification field, and when the value of the reserved identification field indicates whether the SID list is encrypted, the value of the reserved identification field indicates that the SID list has been encrypted. If it is encrypted, the second device will perform the operation of decrypting the encrypted field based on step 603 . Correspondingly, if the value of the reserved identification field indicates that the SID list is not encrypted, the second device does not need to perform step 603 at this time, and can directly perform the next operation based on the unencrypted SRH.
  • the implementation process for the second device to decrypt the encrypted field is as follows: the second device Obtain encrypted metadata from the extended TLV, and decrypt encrypted fields based on the encrypted metadata. Specifically, an encryption algorithm and a decryption key are determined based on the encryption metadata, and an encrypted field is decrypted based on the encryption algorithm and the decryption key.
  • the encryption algorithm used in the embodiment of the present application may be a symmetric encryption algorithm.
  • the encryption key used for encryption in step 601 and the decryption key used for decryption in step 603 are the same key.
  • the encryption algorithm can also be an asymmetric encryption algorithm.
  • the encryption key used for encryption in step 601 is usually a public key and the decryption key used for decryption in step 603 is a private key, that is, The encryption key used for encryption and the decryption key used for decryption are a pair of public and private keys.
  • the second device determines the SA according to the SPI in the ESP header, and decrypts the encrypted field according to the encryption algorithm and decryption key specified by the SA.
  • the unencrypted field also includes a header extension length field
  • the second device is based on the header extension length field and the index indicating the last SID in the SID list field, the position of the TLV in the SRH can be determined, and then the aforementioned extended TLV can be obtained, and then encrypted metadata can be obtained.
  • the extended TLV in step 601 includes an encrypted identification field
  • the encrypted identification field indicates the positions of the encrypted field and the unencrypted field in the SRH
  • it first Determining the position of the encrypted field in the SRH is to determine which fields in the SRH are encrypted.
  • the implementation process of the second device decrypting the encrypted field is: delete the padding data from the decrypted field according to the padding data carried in the extended TLV, and obtain SRH that does not include encrypted fields.
  • the second device deletes padding data of the same length as the padding data length from the decrypted field, so as to obtain an SRH that does not include an encrypted field.
  • the second device checks the SRH standard header based on the integrity check value before decrypting the encrypted field (that is, the SID located in the SRH Integrity of the field before the list and the SID list), in the case that the integrity of the SRH standard header is not damaged, the operation of decrypting the encrypted field is performed.
  • the second device determines the SA according to the SPI in the ESP header, calculates the digest value of the SRH standard header according to the digest algorithm and verification key specified by the SA, and then Comparing the digest value with the integrity check value, if the two are consistent, it indicates that the integrity of the SRH standard header has not been damaged, and then the encrypted field is decrypted. Correspondingly, if the two are inconsistent, it indicates that the SRH standard header has been changed, and other operations need to be performed at this time, which will not be described in detail here.
  • the integrity check value may at least be used to verify the integrity check value of the SRH standard header.
  • the integrity check can be performed with reference to the foregoing embodiments, and no further examples are given here.
  • the value of the integrity check mark field can indicate which part of the integrity check value the integrity check value is used to check value. Then the second device first determines the fields that need integrity verification according to the integrity verification flag field, and then verifies the integrity of these fields according to the integrity verification value.
  • Step 604 The second device processes the first packet based on the SRH not including the encrypted field.
  • the second device can determine the last SID from the SID list, and the last SID is the IPv6 address of the payload's destination.
  • the second device compares the IPv6 address with its own IPv6 address, and if the two are consistent, it determines that it is the destination of the payload, and if the two are inconsistent, it indicates that it is not the destination of the payload.
  • the second device determines that it is not the destination of the payload based on the SRH that does not include the encrypted field, it indicates that the second device is still an intermediate node on the forwarding path indicated by the SID list, so the second device needs to check the SL field in the SRH
  • the modification is performed, for example, the SL value is subtracted by 1, and then a second packet is generated based on the modified SRH, where the second packet includes the modified SRH and the payload.
  • encapsulate the modified SRH in the inner layer message of the first message that is, the aforementioned service message includes the inner layer IP header and load
  • the destination address carried by the IPv6 header is a SID list
  • the second device may first encrypt the modified SRH, then encapsulate the encrypted modified SRH in the inner header of the first packet, and continue to encapsulate the IPv6 header , to obtain the second packet, and then send the second packet.
  • the SRH of the second message also includes an encrypted field and an unencrypted field.
  • the second device encrypts the modified SRH in step 601, which will not be repeated here. That is, for the related explanation of the encrypted field and the unencrypted field in the SRH of the second packet, reference may be made to step 601, which will not be repeated here.
  • the second device determines that there is a dedicated line between itself and the next hop of the message, the modified SRH is not encrypted, and when there is no dedicated line between itself and the next hop of the message, the modified After SRH encryption. It should be noted that, in the embodiment of the present application, the second device may also directly encrypt the modified SRH without distinguishing the situation.
  • the processing process of the subsequent node is the same as the processing process of the second device for the first message, which will not be repeated here.
  • step 604 if the second device determines that it is the destination of the payload. At this time, the second device pops the SRH in the first message to obtain the service message, and then continues the subsequent processing process according to the destination IP address carried in the service message.
  • step 602 to step 604 are illustrated.
  • any POP node receives the encrypted message (that is, the aforementioned first message) from the Internet WAN interface, it parses the IPv6 header and determines the next packet from the "next header" field in the IPv6 header.
  • the packet header is the SRH header.
  • the POP node parses the SRH, and decrypts the encrypted fields in the SRH including the SID list.
  • the POP node obtains the SID list, determines the next hop, and the next hop is the POP node or the second edge node, and modifies the SL value.
  • the POP node performs header encryption on the modified SRH.
  • the POP node encapsulates the IPv6 header, the source IP remains unchanged, the destination IP is the address of the next hop, and forwarded to the next hop.
  • the SRH header can be selected to be popped directly, and then the packet can be forwarded.
  • the POP node selects whether to enable SRH header encryption as required, and if there is a dedicated line between the POP node and the next-hop POP node, encryption is not required.
  • the second edge node When the second edge node receives the encrypted message from the WAN interface, it parses the IPv6 header, and determines that the next header of the message is SRH from the "next header" field in the IPv6 header. The second edge node parses the SRH, and decrypts the encrypted field in the SRH header. The second edge node obtains the SID list, determines itself as the destination node, and performs inner layer IPsec decryption on the message. The second edge node completes the IPsec decryption, and obtains the destination IP and payload of the service message. The second edge node searches the routing table according to the destination IP of the service message and forwards it to the intranet device on the LAN side.
  • the embodiment shown in FIG. 5 provides an SRH header encryption mechanism.
  • the SRH header encryption mechanism at least encrypts the SID list.
  • the SRH header encryption mechanism is established based on the Internet between the edge node and the POP node. If Internet transmission is used between POP nodes, the SRH header encryption mechanism is also established; if dedicated line network transmission is used, SRH header encryption may not be involved. Based on this encryption mechanism, for SRv6 packets transmitted in the POP network, the SID list in the SRH of the SRv6 packets is encrypted to protect the SID information in the SRH header from being leaked.
  • end-to-end encryption of the POP network is realized, and the intermediate POP node does not decrypt the payload, so that the forwarding efficiency of the intermediate POP node is higher.
  • it also provides a security verification mechanism for POP nodes on the Internet to receive messages.
  • FIG. 10 is a flow chart of another method for sending a message provided by an embodiment of the present application. This method is used to explain the second SRH encryption mechanism provided by the embodiment of this application. In the second SRH encryption mechanism, the entire SRH is encrypted. As shown in Figure 10, the method includes the following steps.
  • Step 1001 The first device sends a first message, the first message includes a first encrypted part, the segment routing header SRH of the first message is in the first encrypted part, and the payload of the first message is not in the first encrypted part. section.
  • the SID list In order to prevent the SID list in the SRH from being exposed to the network, the SID list needs to be encrypted. At the same time, in order to prevent subsequent payloads from being attacked, the payload is also encrypted and encapsulated based on IPsec. At this time, in order to ensure that subsequent nodes do not decrypt the payload when decrypting the SRH, it is Encrypt SRH and payload differently. Therefore, the first encrypted part of the first packet in step 1001 includes the SRH but does not include the payload. In addition, the payload encrypted and encapsulated based on IPsec is called the second encrypted part.
  • the embodiment of the present application expands a new message header, which includes the overall encrypted SRH, so as to prevent the SID list from being exposed in the network. Therefore, in some embodiments, the first message includes an extended message header, and the aforementioned first encrypted part is carried in the extended message header.
  • step 1001 the implementation process of step 1001 is as follows: in the process of encapsulating the first message, the first device separately encrypts the SRH of the first message, and encapsulates the separately encrypted SRH in the form of an extended message header , so as to obtain the first message.
  • Step 1001 will be explained in detail below by taking the example that the first device is the first edge node in the POP networking shown in FIG. 2 and the destination of the payload of the first packet is the second edge node.
  • step 1001 may be implemented through the following steps.
  • Step (1) The first edge node receives the service message sent by the local area network (LAN) side of the enterprise branch.
  • LAN local area network
  • step (1) For the implementation of step (1), reference may be made to step 501 in the embodiment shown in FIG. 5 , which will not be repeated here.
  • Step (2) The first edge node generates an SRH, and encrypts the entire SRH.
  • the first edge node determines a forwarding path based on the destination IP address in the inner layer IP header of the service message. Then determine the SID list based on the forwarding path, and then generate the SRH. For a specific implementation manner, reference may be made to step 501 in the embodiment shown in FIG. 5 , which will not be repeated here.
  • FIG. 11 is a schematic diagram of another encryption technology provided by the embodiment of the present application.
  • the SRH is encrypted using the Encapsulating Security Payload (ESP) encryption technology.
  • ESP Encapsulating Security Payload
  • the basic principle of the ESP encryption technology is: the SRH and the ESP trailer (trailer) are encrypted together using an encryption key and encrypted by an encryption algorithm to obtain the first encrypted part. Since SRH is currently encrypted, in order to distinguish other ESP technologies in the future, the ESP tail used for SRH encryption in Figure 11 and later is called SRH ESP tail.
  • the encrypted content can be used as the first encrypted part, and the first edge node encapsulates the first encrypted part in the extended message header. Then use the verification key together with the extended message header and the ESP header, and obtain the integrity check value (integrity check value, ICV) through the verification algorithm, and the integrity check value is the SRH verification result. Subsequent other nodes may first check the integrity of the extended message header according to the integrity check value, and then decrypt the first encrypted part after the integrity check is passed, so as to obtain an unencrypted SRH.
  • the ESP header used for SRH encryption is called SRH ESP header
  • the integrity check value generated based on SRH is called SRH ESP check value.
  • the SRH ESP tail includes padding data (Padding) and padding length (Pad length).
  • the SRH ESP header consists of two parts: Security Parameter Index (SPI) and Sequence Number.
  • SPI Security Parameter Index
  • Sequence Number For related content, refer to the embodiment shown in FIG. 6 , and details are not repeated here.
  • ESP encryption technology is also an optional encryption implementation in the embodiment of the present application, and any encryption technology can be used to encrypt the field to be encrypted in the SRH.
  • IPsec encryption and encapsulation of the service message can also be performed, as shown in Figure 11, based on the service message after IPsec encryption Including ESP header, inner layer IP header, payload, ESP tail and ESP check value.
  • ESP header, ESP trailer, and ESP check value in the IPsec-encrypted and encapsulated service message please refer to the relevant explanation of the above-mentioned ESP encryption performed on the SRH, and will not be described in detail here.
  • the integrity check value for the encrypted field may not be generated, so that only the SRH needs to be decrypted later, and the integrity check of the SRH does not need to be performed.
  • the first encrypted part is obtained by encryption
  • some information used in the encryption process can be added to the message, so that other subsequent nodes can decrypt the first encrypted part based on these information, or decrypt and verify.
  • each node in the network agrees to use a unified encryption verification technology in advance, at this time, it is not necessary to add some information used in the encryption process to the message, and other nodes based on the agreed encryption verification technology. Just do it.
  • Some of the information used in the aforementioned SRH encryption process is called encryption metadata.
  • the extended message header also carries encrypted metadata.
  • the first encrypted part is encrypted based on the encrypted metadata, and it is necessary to ensure that the encrypted metadata is not encrypted, so that subsequent other nodes can process the encrypted fields in the SRH based on the encrypted metadata.
  • encrypted metadata is not in the first encrypted part.
  • the encrypted metadata includes the SRH ESP header in the aforementioned ESP technology.
  • the above encrypted metadata is carried in the extended message header.
  • the encrypted metadata may also be carried in other fields of the first packet, as long as the encrypted metadata is not included in the first encrypted part.
  • the extended header also carries padding data.
  • the first encrypted part at this time also includes encrypted padding data.
  • the extended message header also carries an integrity check value, and the integrity check value is used to verify the integrity check value of the extended message header. integrity. Since the SRH is carried in the extended message header, the integrity check of the SRH is realized through the integrity check of the extended message header.
  • the integrity check provided in the embodiment of the present application may only perform integrity check on the extended message header, or may perform integrity check on both the extended message header and the IPv6 header. That is, the integrity check value carried in the first packet is at least used to perform integrity check on the extended packet header.
  • the integrity check value carried in the extended message header is only generated based on the extended message header.
  • the integrity check value carried in the extended message header is generated based on the extended message header and the IPv6 header.
  • the type field of the extended message header can also be extended.
  • the value of the extended type field is the first value, it indicates that the integrity check value is used to verify the extended message header and the first message.
  • the type field of the extended message header is the second value, it indicates that the integrity check value is used to check the integrity of the extended message header.
  • Fig. 12 is a schematic diagram of the format of another first message provided by the embodiment of the present application.
  • the first packet includes an IPv6 header, an extended packet header, an inner layer IP header, and a payload.
  • the fields in the IPv6 header and the explanation of the inner layer IP header can refer to the above related content, and will not be repeated here.
  • the extended message header includes a header extension length (Hdr Ext Len) field, a type (Type) field, a reserved (Reserved) field, an SPI field, a serial number field, and a first encrypted part (added in Figure 12 bold font), ICV field.
  • the first encrypted part includes the encrypted SRH, the encrypted padding data field and the padding length field.
  • the type field in the first line of the extended message header includes 8 bits, and when the value of the first bit is 0, it indicates that only the integrity check of the extended message header is required. When the value of this bit is 1, it indicates that the integrity check is performed on the extended message header and the IPv6 header at the same time.
  • the value of the next header in the IPv6 header indicates that the next packet header is SRH, but as shown in Figure 12, the value of the next header in the IPv6 header in this embodiment of the application indicates that the next packet
  • the header is an extended message header.
  • the SPI field and the serial number field are used to carry the SPI and serial number in the aforementioned SRH ESP header respectively.
  • the padding data field and padding length field are used to carry the padding data and padding length in the aforementioned SRH ESP tail respectively.
  • the integrity check value field is used to carry the aforementioned ICV obtained based on the ESP technology.
  • the SRH field, padding data field, and padding length field are used together using an encryption key and encrypted by an encryption algorithm, so that the entire SRH in Figure 12 changes from plaintext to ciphertext.
  • next header field in the extended header is also encrypted.
  • this field may not be encrypted. Accordingly, the next header field is not in the first encrypted part.
  • the extended header in Figure 12 follows the basic format of the ESP header.
  • the extended header can also be called the SRH ESP header.
  • FIG. 12 is an optional implementation manner of the extended header provided by the embodiment of the present application, and the embodiment of the present application does not limit the specific format of the extended header.
  • Step (3) The first edge node encapsulates the first encrypted part in the outer layer of the service message, and then continues to encapsulate the IPv6 header to obtain the aforementioned first message, and then sends the first message.
  • the first edge node After the first edge node encrypts the SRH, it can obtain the first message through the above step (3).
  • the SRH of the first message obtained in this way is in the first encrypted part, so that the SID list can be prevented from being exposed in the network.
  • the first edge node can encapsulate the extended message header including the first encrypted part in the outer layer of the service message, and then continue to Encapsulate the IPv6 header to obtain the aforementioned first message
  • the IPv6 header carries the destination IP address
  • the destination IP address in the IPv6 header is the IP address corresponding to the next SID after the SID of the first edge node in the SID list.
  • the first edge node before the first edge node encapsulates the encrypted SRH in the outer layer of the service message, it can also encrypt and encapsulate the service message based on IPsec, so as to ensure the security of the service message.
  • FIG. 13 is a schematic flow chart of sending a message provided in an embodiment of the present application.
  • the first edge node receives the service message on the LAN side, searches for a route according to the destination IP of the service message, and determines the tunnel interface IP of the second edge node at the destination of the service message.
  • the first edge node determines the SID list of the SRH to be encapsulated outside the service message according to the SR path scheduling policy configured locally or centrally delivered by the network controller.
  • the first edge node performs IPsec encryption and encapsulation on the service message, and the encapsulation content includes the inner layer IP header and payload in the service message.
  • the first edge node adds an extended message header to the IPsec encrypted and encapsulated message, and the extended message header includes a separately encrypted SRH.
  • the first edge node encapsulates the extended message header in the outer layer of the service message, it continues to encapsulate the IPv6 header, and the "next header" field in the IPv6 header is the type of the extended message header to obtain the first message. Then forward the first packet from the outgoing interface to the POP network.
  • the service message may also have been encapsulated with SRH.
  • the first edge node may directly encrypt the SRH based on the above encryption mechanism.
  • Step 1002 the second device receives the first packet.
  • step 1002 For the implementation manner of step 1002, reference may be made to the implementation manner of step 602 in the foregoing embodiment in FIG. 6 , and details are not repeated here.
  • Step 1003 the second device decrypts the first encrypted part to obtain the SRH.
  • an intermediate node when an intermediate node receives a message, it needs to determine the current operation according to the SRH. Therefore, when receiving the first message, the second device needs to decrypt the first encrypted part first, so as to obtain the SRH that does not include the ciphertext information.
  • step 1001 when the first message includes an extended message header, and the first encrypted part is carried in the extended message header, the second device first obtains the extended message header, and then obtains the extended message header from the extended message The first encrypted part is obtained from the header, and then the first encrypted part is decrypted to obtain the SRH.
  • step 1001 when the next header field of the IPv6 header indicates that the next header is an extended header, based on the position of the next header field in the IPv6 header, the extended header can be obtained.
  • the implementation process for the second device to decrypt the first encrypted part is as follows:
  • the encrypted metadata is obtained from the message header, and the encrypted field is decrypted based on the encrypted metadata.
  • an encryption algorithm and a decryption key are determined based on the encryption metadata, and an encrypted field is decrypted based on the encryption algorithm and the decryption key.
  • step 603 in the embodiment in FIG. 6 For a specific implementation manner, reference may be made to step 603 in the embodiment in FIG. 6 .
  • the implementation process of the second device decrypting the first encrypted part is: deleting the padding data from the decrypted field to obtain the SRH.
  • the second device deletes padding data of the same length as the padding data length from the decrypted field, thereby obtaining an unencrypted SRH.
  • the second device in the case that the extended message header in step 1001 carries an integrity check value, the second device first checks the integrity of the extended message header based on the integrity check value before decrypting the first encrypted part. In the case that the integrity of the extended message header is not damaged, the operation of decrypting the first encrypted part is performed. For a specific verification method, refer to step 603 in the embodiment in FIG. 6 .
  • the implementation process of verifying the integrity of the extended message header is: in the case that the type field of the extended message header is the first value, based on The integrity check value performs integrity check on the extended message header and the IPv6 header of the first message; when the type field of the extended message header is the second value, the extended message is checked based on the integrity check value header integrity check.
  • Step 1004 the second device processes the first message based on the SRH.
  • the second device can determine the last SID from the SID list, and the last SID is the IPv6 address of the payload's destination.
  • the second device compares the IPv6 address with its own IPv6 address. If the two are consistent, it determines that it is the destination of the payload. If the two are inconsistent, it indicates that it is not the destination of the payload.
  • the second device determines that it is not the destination of the load based on the SRH, it indicates that the second device is still an intermediate node on the forwarding path indicated by the SID list, so the second device needs to modify the SL field in the SRH, for example , subtracting 1 from the SL value, and then generating a second packet based on the modified SRH, where the second packet includes the modified SRH and the payload.
  • the modified SRH in the inner layer message of the first message (that is, the aforementioned service message includes the inner layer IP header and load), and continue to encapsulate the IPv6 header.
  • the destination address carried by the IPv6 header is a SID list
  • the IPv6 address corresponding to the next SID after the SID of the second device to obtain the second packet, and then send the second packet. That is, the second device modifies the SRH based on the next hop of the payload, and generates a second packet based on the modified SRH, where the second packet includes the modified SRH and the payload.
  • the second device may first encrypt the modified SRH, then encapsulate the encrypted modified SRH in the inner header of the first packet, and continue to encapsulate the IPv6 header , to obtain the second packet, and then send the second packet.
  • the SRH in the second packet includes the first encrypted part.
  • the second device encrypts the modified SRH in step 1001, which will not be repeated here. That is, for the relevant explanation of the first encrypted part in the SRH of the second packet, reference may be made to step 1001, and details are not repeated here.
  • the second device determines that there is a dedicated line between itself and the next hop of the message, the modified SRH is not encrypted, and when there is no dedicated line between itself and the next hop of the message, the modified After SRH encryption. It should be noted that, in the embodiment of the present application, the second device may also directly encrypt the modified SRH without distinguishing the situation.
  • the processing process of the subsequent node is the same as the processing process of the second device for the first message, which will not be repeated here.
  • step 604 if the second device determines that it is the destination of the payload. At this time, the second device pops the SRH in the first message to obtain the service message, and then continues the subsequent processing process according to the destination IP address carried in the service message.
  • step 1002 to step 1004 will be illustrated.
  • any POP node receives the encrypted message (that is, the aforementioned first message) from the Internet WAN interface, it parses the IPv6 header and determines the next packet from the "next header" field in the IPv6 header.
  • the packet header is the SRH ESP header.
  • the POP node checks and decrypts the SRH in combination with the information in the SRH ESP header, and parses the plaintext information in the SRH.
  • the POP node obtains the SID list from the decrypted SRH, determines the next hop, and the next hop is the POP node or the second edge node, and modifies the SID pointer information (SL) in the SRH.
  • SL SID pointer information
  • the POP node encrypts the SRH header, and encapsulates the encrypted SRH in the SRH ESP header.
  • the POP node continues to encapsulate the IPv6 header outside the SRH ESP header, the source IP remains unchanged, and the destination IP is the IP of the next hop, and forwarded to the next hop.
  • the SRH header can be selected to be popped directly, and then the packet can be forwarded.
  • the POP node selects whether to enable SRH header encryption as required, and if there is a dedicated line between the POP node and the next-hop POP node, encryption is not required.
  • the second edge node When the second edge node receives the encrypted message from the WAN interface, it parses the IPv6 header, and determines that the next message header is the SRH ESP header from the "next header" field in the IPv6 header. Combined with the SRH ESP header, the SRH is verified and decrypted, and the plaintext information in the SRH is parsed. The second edge node obtains the SID list from the decrypted SRH, determines itself as the destination node, and performs inner layer IPsec decryption on the message. The second edge node completes the IPsec decryption, and obtains the destination IP and payload of the service message. The second edge node searches the routing table according to the destination IP of the service message and forwards it to the intranet device on the LAN side.
  • the embodiment shown in FIG. 10 provides an SRH header encryption mechanism.
  • the SRH header encryption mechanism encrypts the entire SRH.
  • the SRH header encryption mechanism is established based on the Internet between the edge node and the POP node. If Internet transmission is used between POP nodes, the SRH header encryption mechanism is also established; if dedicated line network transmission is used, SRH header encryption may not be involved. Based on this encryption mechanism, the SRH of SRv6 packets transmitted in the POP network is encrypted to protect the SID information in the SRH header from being leaked.
  • end-to-end encryption of the POP network is realized, and the intermediate POP node does not decrypt the payload, so that the forwarding efficiency of the intermediate POP node is higher.
  • it also provides a security verification mechanism for POP nodes on the Internet to receive messages.
  • FIG. 14 is a schematic structural diagram of a network device provided by an embodiment of the present application. As shown in FIG. 14, the network device 1400 includes a processing module 1401 and a transceiver module 1402.
  • the processing module 1401 is used to encrypt the segment routing header SRH in the message.
  • the message also includes a payload.
  • the encrypted SRH includes an encrypted field and an unencrypted field, and the encrypted field includes at least an encrypted segment identifier SID list , the SID list indicates the transmission path of the message.
  • SID list indicates the transmission path of the message.
  • the transceiver module 1402 is configured to send the message. For a specific implementation manner, reference may be made to step 601 in the embodiment in FIG. 6 .
  • the unencrypted field includes a field indicating the index of the last SID in the SID list.
  • the unencrypted field also includes a route type field.
  • the unencrypted field further includes a reserved identification field, and the value of the reserved identification field indicates that the SID list has been encrypted.
  • the SRH includes an extended type length value TLV, the extended TLV carries encrypted metadata, the encrypted field is encrypted based on the encrypted metadata, and the encrypted metadata is not encrypted.
  • the unencrypted field also includes a header extension length field.
  • the extended TLV includes an encryption identification field, and the value of the encryption identification field indicates the positions of the encrypted field and the unencrypted field in the SRH.
  • the encrypted field further includes encrypted padding data
  • the extended TLV also carries encrypted padding data
  • the extended TLV also carries an integrity check value, and the integrity check value is at least used to check the integrity of the field before the SID list and the SID list in the SRH.
  • the embodiment of the present application provides an SRH header encryption mechanism.
  • the SRH header encryption mechanism at least encrypts the SID list.
  • the SRH header encryption mechanism is established based on the Internet between the edge node and the POP node. If Internet transmission is used between POP nodes, the SRH header encryption mechanism is also established; if dedicated line network transmission is used, SRH header encryption may not be involved. Based on this encryption mechanism, for SRv6 packets transmitted in the POP network, the SID list in the SRH of the SRv6 packets is encrypted to protect the SID information in the SRH header from being leaked.
  • end-to-end encryption of the POP network is realized, and the intermediate POP node does not decrypt the payload, so that the forwarding efficiency of the intermediate POP node is higher.
  • it also provides a security verification mechanism for POP nodes on the Internet to receive messages.
  • processing module and the transceiver module in the network device shown in FIG. 14 optionally have the following functions.
  • the processing module 1401 is used to encrypt the message, the encrypted message includes an encrypted part, the segment routing header SRH of the message is in the encrypted part, and the payload of the message is not in the encrypted part.
  • the processing module 1401 is used to encrypt the message
  • the encrypted message includes an encrypted part
  • the segment routing header SRH of the message is in the encrypted part
  • the payload of the message is not in the encrypted part.
  • the transceiver module 1402 is configured to send the message. For a specific implementation manner, reference may be made to step 1001 in the embodiment in FIG. 10 .
  • the message includes an extended message header, and the encrypted part is carried in the extended message header.
  • the extended message header also carries encrypted metadata
  • the encrypted part is encrypted based on the encrypted metadata
  • the encrypted metadata is not included in the encrypted part.
  • the extended message header also carries an integrity check value, and the integrity check value is at least used to check the integrity of the extended message header.
  • the integrity check value is used to verify the integrity of the extended message header and the IPv6 header of the first message, and the extended message header
  • the integrity check value is used to check the integrity of the extended message header.
  • the IPv6 header of the message is located at the outer layer of the extended message header, and the next header field in the IPv6 header indicates that the next message header is an extended message header.
  • the encrypted part also includes encrypted padding data.
  • the embodiment of the present application provides an SRH header encryption mechanism.
  • the SRH header encryption mechanism encrypts the entire SRH.
  • the SRH header encryption mechanism is established based on the Internet between the edge node and the POP node. If Internet transmission is used between POP nodes, the SRH header encryption mechanism is also established; if dedicated line network transmission is used, SRH header encryption may not be involved. Based on this encryption mechanism, the SRH of SRv6 packets transmitted in the POP network is encrypted to protect the SID information in the SRH header from being leaked.
  • end-to-end encryption of the POP network is realized, and the intermediate POP node does not decrypt the payload, so that the forwarding efficiency of the intermediate POP node is higher.
  • it also provides a security verification mechanism for POP nodes on the Internet to receive messages.
  • processing module and the transceiver module in the network device shown in FIG. 14 optionally have the following functions.
  • the transceiver module 1402 is used to receive the first message.
  • the first message includes a segment routing header SRH and a load.
  • the list indicates the transmission path of the first message. For a specific implementation manner, refer to step 602 in the embodiment in FIG. 6 .
  • the processing module 1401 is configured to decrypt the encrypted field to obtain the SRH not including the encrypted field. For a specific implementation manner, refer to step 603 in the embodiment in FIG. 6 .
  • the processing module 1401 is further configured to process the first packet based on the SRH not including the encrypted field. For a specific implementation manner, refer to step 604 in the embodiment in FIG. 6 .
  • the processing module is configured to: in the case that the SRH that does not include the encrypted field determines that it is not the destination of the payload, modify the SRH that does not include the encrypted field based on the next hop of the payload, and generate the second SRH based on the modified SRH.
  • the second message includes the modified SRH and load;
  • the transceiver module is also used to send the second message.
  • processing module is also used to:
  • the modified SRH is encrypted.
  • the SRH in the second packet includes an encrypted field and an unencrypted field.
  • the unencrypted field includes a field indicating the index of the last SID in the SID list
  • Processing modules for:
  • the IPv6 header of the first message determines the starting position of the SID list
  • the unencrypted field includes a field indicating an index of the last SID in the SID list and a routing type field;
  • Processing modules for:
  • the unencrypted field also includes a reserved identification field
  • Processing modules for:
  • the operation of decrypting the encrypted field is performed.
  • the SRH includes an extended type length value TLV, the extended TLV carries encrypted metadata, and the encrypted metadata is not encrypted;
  • Processing modules for:
  • the unencrypted field includes a field indicating the index of the last SID in the SID list and a header extension length field;
  • the processing module is also used to:
  • the extension TLV is acquired.
  • the value of the type field of the extended TLV indicates the position of the encrypted field and the unencrypted field in the SRH;
  • the processing module is also used to:
  • the position of the encryption field in the SRH is determined based on the type field of the extended TLV.
  • the encrypted field also includes encrypted padding data
  • the extended TLV also carries encrypted padding data
  • the processing module is used for;
  • the padding data is removed from the decrypted fields to obtain the SRH which does not include the encrypted fields.
  • the extended TLV also carries an integrity check value
  • the processing module is also used to:
  • the embodiment of the present application provides an SRH header encryption mechanism.
  • the SRH header encryption mechanism at least encrypts the SID list.
  • the SRH header encryption mechanism is established based on the Internet between the edge node and the POP node. If Internet transmission is used between POP nodes, the SRH header encryption mechanism is also established; if dedicated line network transmission is used, SRH header encryption may not be involved. Based on this encryption mechanism, for SRv6 packets transmitted in the POP network, the SID list in the SRH of the SRv6 packets is encrypted to protect the SID information in the SRH header from being leaked.
  • end-to-end encryption of the POP network is realized, and the intermediate POP node does not decrypt the payload, so that the forwarding efficiency of the intermediate POP node is higher.
  • it also provides a security verification mechanism for POP nodes on the Internet to receive messages.
  • processing module and the transceiver module in the network device shown in FIG. 14 optionally have the following functions.
  • the transceiver module 1402 is configured to receive the first message, the first message includes an encrypted part, the segment routing header SRH of the first message is in the encrypted part, and the payload of the first message is not in the encrypted part.
  • the first message includes an encrypted part
  • the segment routing header SRH of the first message is in the encrypted part
  • the payload of the first message is not in the encrypted part.
  • the processing module 1401 is used to decrypt the encrypted part to obtain the SRH.
  • the processing module 1401 is used to decrypt the encrypted part to obtain the SRH.
  • step 1003 in the embodiment in FIG. 10 reference may be made to step 1003 in the embodiment in FIG. 10 .
  • the processing module 1401 is further configured to process the first packet based on the SRH. For a specific implementation manner, reference may be made to step 1004 in the embodiment in FIG. 10 .
  • processing modules are used to:
  • the next hop based on the payload modifies the SRH, and generates a second packet based on the modified SRH, where the second packet includes the modified SRH and the payload.
  • base processing modules are used to:
  • the modified SRH is encrypted.
  • the second packet includes an encrypted part, and the encrypted modified SRH is in the encrypted part.
  • the first message includes an extended message header, and the encrypted part is carried in the extended message header;
  • the processing module is also used to:
  • the extended message also carries encrypted metadata
  • Processing modules for:
  • the encrypted portion is decrypted based on the encrypted metadata.
  • the extended message header also carries an integrity check value
  • Processing modules for:
  • processing modules are used to:
  • the integrity check is performed on the extended message header and the IPv6 header of the first message based on the integrity check value
  • the integrity check is performed on the extended message header based on the integrity check value.
  • the IPv6 header of the first message is located at the outer layer of the extended message header, and the next header field in the IPv6 header indicates that the next message header is an extended message header;
  • Processing modules for:
  • the encrypted part also includes encrypted padding data
  • Processing modules for:
  • the padding data is removed from the decrypted field to obtain the SRH.
  • the embodiment of the present application provides an SRH header encryption mechanism.
  • the SRH header encryption mechanism encrypts the entire SRH.
  • the SRH header encryption mechanism is established based on the Internet between the edge node and the POP node. If Internet transmission is used between POP nodes, the SRH header encryption mechanism is also established; if dedicated line network transmission is used, SRH header encryption may not be involved. Based on this encryption mechanism, the SRH of SRv6 packets transmitted in the POP network is encrypted to protect the SID information in the SRH header from being leaked.
  • end-to-end encryption of the POP network is realized, and the intermediate POP node does not decrypt the payload, so that the forwarding efficiency of the intermediate POP node is higher.
  • it also provides a security verification mechanism for POP nodes on the Internet to receive messages.
  • the network device provided in the above embodiment sends a message
  • it only uses the division of the above functional modules as an example for illustration.
  • the above function allocation can be completed by different functional modules according to needs.
  • the internal structure of the device is divided into different functional modules to complete all or part of the functions described above.
  • the network device provided by the above embodiment and the method embodiment of sending a message belong to the same idea, and the specific implementation process thereof is detailed in the method embodiment, and will not be repeated here.
  • all or part may be implemented by software, hardware, firmware or any combination thereof.
  • software When implemented using software, it may be implemented in whole or in part in the form of a computer program product.
  • the computer program product includes one or more computer instructions. When the computer instructions are loaded and executed on the computer, the processes or functions according to the embodiments of the present application will be generated in whole or in part.
  • the computer can be a general purpose computer, a special purpose computer, a computer network, or other programmable devices.
  • the computer instructions may be stored in or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions may be transmitted from a website, computer, server or data center Transmission to another website site, computer, server or data center by wired (eg coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (eg infrared, wireless, microwave, etc.).
  • the computer-readable storage medium may be any available medium that can be accessed by a computer, or a data storage device such as a server or a data center integrated with one or more available media.
  • the available medium may be a magnetic medium (for example: floppy disk, hard disk, magnetic tape), an optical medium (for example: digital versatile disc (digital versatile disc, DVD)), or a semiconductor medium (for example: solid state disk (solid state disk, SSD) )wait.
  • a magnetic medium for example: floppy disk, hard disk, magnetic tape
  • an optical medium for example: digital versatile disc (digital versatile disc, DVD)
  • a semiconductor medium for example: solid state disk (solid state disk, SSD) )wait.
  • the program can be stored in a computer-readable storage medium.
  • the above-mentioned The storage medium mentioned may be a read-only memory, a magnetic disk or an optical disk, and the like.

Abstract

公开了一种发送报文的方法、网络设备、存储介质及程序产品,属于分段路由技术领域。所述方法包括:网络设备发送报文,该报文包括分段路由头SRH和载荷,SRH包括加密字段和不加密字段,加密字段至少包括加密后的分段标识SID列表,SID列表指示该报文的传输路径。本申请实施例提供了一种加密机制。基于该加密机制,在POP组网中传输的SRv6报文的SRH中的SID列表是被加密的,从而保护SID信息不被泄露。此外,报文传输路径上的中间节点仅仅需要解密SRH中的加密字段即可从SID列表中确定下一跳,无需解密载荷,提高了网络设备的转发效率,并且保护了载荷的安全传输性。

Description

发送报文的方法、网络设备、存储介质及程序产品
本申请要求于2021年08月31日提交的申请号为202111013733.5、发明名称为“分段路由方法和系统”的中国专利申请的优先权,以及于2021年11月03日提交的申请号为202111295472.0、发明名称为“发送报文的方法、网络设备、存储介质及程序产品”的中国专利申请的优先权,其全部内容通过引用结合在本申请中。
技术领域
本申请实施例涉及分段路由技术领域,特别涉及一种发送报文的方法、网络设备、存储介质及程序产品。
背景技术
入网点(point of presence,POP)组网是一种基于软件定义广域网(software-defined wide area network,SD-WAN)技术的网络架构。通过POP组网,企业分支站点能够通过本地互联网线路就近接入到POP组网的一个POP点,然后经过POP网中各个POP点实现跨区域的业务互访,满足企业组网、入云、上网等业务的需求。在POP组网中转发业务数据需要保证业务数据的私密性。
随着基于IPv6的分段路由(Segment Routing over IPv6,SRv6)技术的发展,POP组网中的第一边缘节点(edge)接收到目的地为第二边缘节点的业务数据时,基于第一边缘节点和第二边缘节点之间的加密隧道对业务数据进行加密,然后在加密后的业务数据前封装分段路由头(segment routing header,SRH),得到待转发的报文。该SRH中包括多个分段标识(Segment ID,SID),这多个SID中每个SID指示POP组网中的一个POP点,因此该SRH能够指示该业务数据的转发路径。然后转发封装后的报文,以将业务数据转发至第二边缘节点。
在转发携带业务数据的报文过程中,报文中的SID信息容易被不法分子窃取进而恶意利用。
发明内容
本申请提供了一种发送报文的方法、网络设备、存储介质及程序产品,可以避免网络中传输的SRv6报文中的SID信息被不法分子窃取进而恶意利用。所述技术方案如下:
第一方面,提供了一种发送报文的方法,在该方法中,网络设备发送报文,该报文包括分段路由头SRH和载荷,SRH包括加密字段(encrypted field)和不加密字段(unencrypted field),加密字段至少包括加密后的分段标识SID列表,SID列表指示该报文的传输路径。
本申请提供了一种SRH头加密机制。该SRH头加密机制至少对SRH中的SID列表进行加密。基于该SRH头加密机制,在POP组网中传输的SRv6报文,SRv6报文的SRH中的SID列表是被加密的,从而保护SRH头中SID信息不被泄露。
在一种可能的实现方式中,该不加密字段包括指示SID列表中最后一个SID的索引的字 段。
其中,不加密字段至少包括指示SID列表中最后一个SID的索引的字段(也即Last Entry字段),其他节点基于Last Entry字段可确定SID列表的终止位置,然后基于IPv6头便可确定SRH的起始位置,进而进行后续的解密操作。
在一种可能的实现方式中,该不加密字段还包括路由类型字段。此时其他节点不需要基于IPv6头确定SRH的起始位置,而是基于路由类型字段确定。
在一种可能的实现方式中,该不加密字段还包括预留标识字段,预留标识字段的取值指示SID列表已经被加密。
通过对SRH中的预留标识(Flags)字段的扩展,其他节点通过该预留标识字段的取值便可先判断SID列表是否已经被加密,进而再决定是否需要进行解密操作。
在一种可能的实现方式中,该SRH包括扩展类型长度值TLV,扩展TLV携带加密元数据(encryption metadata),加密字段是基于加密元数据加密的,加密元数据没有被加密。
为了便于其他节点快速解密加密后的SID列表,可以在报文中携带加密时使用的加密元数据。示例地,加密元数据可以携带ESP技术中的ESP头。
在一种可能的实现方式中,该不加密字段还包括头扩展长度字段。在在扩展了扩展TLV的场景中,不加密字段还可以包括头扩展长度(Hdr Ext Length)字段,其他节点基于该头扩展长度字段能够在解密SRH之前先获取扩展TLV,进而获取加密元数据。
在一种可能的实现方式中,该扩展TLV包括加密标识字段,加密标识字段的取值指示SRH中加密字段和不加密字段的位置。由于SRH中是部分字段进行了加密,因此可以对该扩展TLV的标识字段进行扩展,以使标识字段的取值指示SRH中加密字段和不加密字段的位置。
在一种可能的实现方式中,该加密字段还包括加密后的填充数据,扩展TLV还携带加密后的填充数据。
在使用块加密时,如果最后一个数据块长度不足则根据该填充数据进行填充。因此,加密字段还包括加密后的填充数据。在本申请中,通过扩展TLV来携带该填充数据。
在一种可能的实现方式中,该扩展TLV还携带完整性校验值,完整性校验值至少用于校验SRH中位于SID列表前的字段以及SID列表的完整性。
为了进一步提高SID列表的安全性,本申请提供的加密机制还提供了对SID列表的完整性校验功能。
第二方面,提供了另一种发送报文的方法。在该方法中,网络设备发送报文,该报文包括加密部分,该报文的分段路由头SRH在该加密部分之中,该报文的载荷不在该加密部分中。
本申请提供了另一种SRH头加密机制。该SRH头加密机制对整个SRH进行加密。基于该SRH头加密机制,在POP组网中传输的SRv6报文,SRv6报文的SRH是被加密的,从而保护SRH头中SID信息不被泄露。此外,由于载荷不在加密部分中,如此在载荷也加密的场景中,载荷是加密在其他加密部分中的,这样第一报文传输路径上的中间节点仅仅需要解密加密部分即可从SRH中确定下一跳,无需解密载荷,在保护载荷安全传输的情况下,还提高了网络设备的转发效率。
在一种可能的实现方式中,该报文包括扩展报文头,该加密部分携带在扩展报文头中。
本申请扩展一种新的报文头,该新的报文头中包括整体加密后的SRH,以避免SID列表暴露在网络中。
在一种可能的实现方式中,该扩展报文头还携带加密元数据,该加密部分是基于加密元数据加密的,加密元数据不在该加密部分中。为了便于其他节点快速解密加密后的SID列表,可以在扩展报文头中携带加密时使用的加密元数据。示例地,加密元数据可以携带ESP技术中的ESP头。
在一种可能的实现方式中,该扩展报文头还携带完整性校验值,完整性校验值至少用于校验扩展报文头的完整性。
为了进一步提高SID列表的安全性,本申请提供的加密机制还提供了对扩展报文头的完整性校验功能。
在一种可能的实现方式中,该扩展报文头的类型字段的取值为第一值时,完整性校验值用于校验扩展报文头和第一报文的IPv6头的完整性,扩展报文头的类型字段的取值为第二值时,完整性校验值用于校验扩展报文头的完整性。基于对扩展报文头中的类型字段的扩展,可以实现灵活的安全校验机制。
在一种可能的实现方式中,第一报文的IPv6头位于扩展报文头的外层,IPv6头中的下一报头字段指示下一个报文头为扩展报文头。
在本申请中,扩展报文头可以位于IPv6头的内层来替代SRH,如此则需要对IPv6头中的下一报头字段的取值进行扩展。
在一种可能的实现方式中,该加密部分还包括加密后的填充数据。
在使用块加密时,如果最后一个数据块长度不足则根据该填充数据进行填充。因此,该加密部分还包括加密后的填充数据。
第三方面,提供了另一种发送报文的方法。其中,第三方面提供的技术方案的技术效果可以参考第一方面提供的发送报文方法的技术效果,在此不再赘述。
在该方法中,网络设备接收第一报文,第一报文包括分段路由头SRH和载荷,SRH包括加密字段和不加密字段,加密字段至少包括加密后的分段标识SID列表,SID列表指示将第一报文的传输路径;网络设备解密加密字段,得到不包括加密字段的SRH;网络设备基于不包括加密字段的SRH对第一报文进行处理。
在一种可能的实现方式中,网络设备基于不包括加密字段的SRH对第一报文进行处理的实现方式为:在网络设备基于不包括加密字段的SRH确定自身不是载荷的目的地的情况下,基于载荷的下一跳修改不包括加密字段的SRH,基于修改后的SRH生成第二报文,第二报文包括修改后的SRH和载荷;网络设备发送第二报文。
在一种可能的实现方式中,网络设备还可以加密修改后的SRH,相应地,第二报文中的SRH包括加密字段和不加密字段。
在一种可能的实现方式中,不加密字段包括指示SID列表中最后一个SID的索引的字段。这种场景下,前述解密加密字段的实现过程为:网络设备基于SRH中指示SID列表中最后一个SID的索引的字段,确定SID列表的终止位置;网络设备第一报文的IPv6头确定SID列表的起始位置;网络设备基于SID列表的起始位置和终止位置,确定获取加密后的SID列表,以解密加密后的SID列表。
在一种可能的实现方式中,不加密字段包括指示SID列表中最后一个SID的索引的字段和路由类型字段。这种场景下,前述解密加密字段的实现过程为:网络设备基于SRH中指示SID列表中最后一个SID的索引的字段,确定SID列表的终止位置;网络设备基于路由类型字段确定SID列表的起始位置;网络设备基于SID列表的起始位置和终止位置,确定获取加密后的SID列表,以解密加密后的SID列表。
在一种可能的实现方式中,该不加密字段还包括预留标识字段。这种场景下,网络设备解密加密字段的实现过程可以为:在预留标识字段的取值指示SID列表已经被加密的情况下,执行解密加密字段的操作。
在一种可能的实现方式中,SRH包括扩展类型长度值TLV,扩展TLV携带加密元数据,加密元数据没有被加密。这种场景下,前述网络设备解密加密字段的实现过程为:网络设备从扩展TLV中获取加密元数据;网络设备基于加密元数据解密加密字段。
在一种可能的实现方式中,该不加密字段包括指示SID列表中最后一个SID的索引的字段和头扩展长度字段。这种场景下,网络设备还可以基于头扩展长度字段和指示SID列表中最后一个SID的索引的字段,获取扩展TLV。
在一种可能的实现方式中,扩展TLV的类型字段的取值指示SRH中加密字段和不加密字段的位置。这种场景下,网络设备还可以基于扩展TLV的类型字段确定加密字段在SRH中所处的位置。
在一种可能的实现方式中,加密字段还包括加密后的填充数据,扩展TLV还携带加密后的填充数据。这种场景下,网络设备解密加密字段的实现过程为:从解密后的字段中删除填充数据,得到不包括加密字段的SRH。
在一种可能的实现方式中,扩展TLV还携带完整性校验值。这种场景下,网络设备还可以基于完整性校验值校验SRH中位于SID列表前的字段以及SID列表的完整性;在SRH中位于SID列表前的字段以及SID列表的完整性没有被破坏的情况下,执行解密加密字段的操作。
第四方面,提供了另一种发送报文的方法。其中,第四方面提供的技术方案的技术效果可以参考第二方面提供的发送报文方法的技术效果,在此不再赘述。
在该方法中,网络设备接收第一报文,第一报文包括加密部分,第一报文的分段路由头SRH在该加密部分之中,第一报文的载荷不在该加密部分中;网络设备解密该加密部分,得到SRH;网络设备基于SRH对第一报文进行处理。
在一种可能的实现方式中,网络设备基于SRH对第一报文进行处理的实现过程为:在网络设备基于SRH确定自身不是载荷的目的地的情况下,基于载荷的下一跳修改SRH,基于修改后的SRH生成第二报文,第二报文包括修改后的SRH和载荷。
在一种可能的实现方式中,网络设备还加密修改后的SRH,相应地,第二报文包括加密部分,加密后的修改后的SRH在加密部分中。
在一种可能的实现方式中,第一报文包括扩展报文头,加密部分携带在扩展报文头中。这种场景下,网络设备从扩展报文头中获取加密部分。
在一种可能的实现方式中,扩展报文还携带加密元数据。这种场景下,网络设备解密加密部分的实现过程为:网络设备基于加密元数据解密加密部分。
在一种可能的实现方式中,扩展报文头还携带完整性校验值。这种场景下,网络设备解密加密部分的实现过程为:基于完整性校验值校验扩展报文头的完整性;在扩展报文头的完整性没有被破坏的情况下,执行解密加密部分的操作。
在一种可能的实现方式中,基于完整性校验值校验扩展报文头的完整性的实现过程为:在扩展报文头的类型字段的值为第一值的情况下,基于完整性校验值对扩展报文头和第一报文的IPv6头进行完整性校验;在扩展报文头的类型字段的值为第二值的情况下,基于完整性校验值对扩展报文头进行完整性校验。
在一种可能的实现方式中,第一报文的IPv6头位于扩展报文头的外层,IPv6头中的下一头字段指示下一个报文头为扩展报文头。这种场景下,网络设备基于IPv6头中的下一报头字段获取扩展报文头。
在一种可能的实现方式中,该加密部分还包括加密后的填充数据。这种场景下,网络设备解密该加密部分的实现过程为:从解密后的字段中删除填充数据,得到SRH。
第五方面,提供了一种网络设备,所述网络设备具有实现上述第一方面中发送报文的方法行为的功能。所述网络设备包括至少一个模块,该至少一个模块用于实现上述第一方面所提供的发送报文的方法。
第六方面,提供了一种网络设备,所述网络设备具有实现上述第二方面中发送报文的方法行为的功能。所述网络设备包括至少一个模块,该至少一个模块用于实现上述第二方面所提供的发送报文的方法。
第七方面,提供了一种网络设备,所述网络设备具有实现上述第三方面中发送报文的方法行为的功能。所述网络设备包括至少一个模块,该至少一个模块用于实现上述第三方面所提供的发送报文的方法。
第八方面,提供了一种网络设备,所述网络设备具有实现上述第四方面中发送报文的方法行为的功能。所述网络设备包括至少一个模块,该至少一个模块用于实现上述第四方面所提供的发送报文的方法。
第九方面,提供了一种网络设备,该网络设备包括:存储器,存储有指令;
与所述存储器相连的处理器,当所述指令在所述处理器中运行时,使得所述网络设备执行前述第一方面或第二方面或第三方面或第四方面中任一方面所述的方法。
第十方面,提供了一种计算机可读存储介质,所述计算机可读存储介质中存储有指令,当其在处理器上运行时,实现前述第一方面或第二方面或第三方面或第四方面中任一方面所述的方法。
第十一方面,提供了一种计算机程序产品,该计算机程序产品包括程序,当所述程序在处理器上运行时,实现前述第一方面或第二方面或第三方面或第四方面中任一方面所述的方 法。
上述第五方面至第十一方面所获得的技术效果与第一方面至第四方面中对应的技术手段获得的技术效果近似,在这里不再赘述。
附图说明
图1是本申请实施例提供的一种基于POP组网的企业分支与总部之间的互访路径示意图;
图2是本申请实施例提供的一种POP组网的系统架构示意图;
图3是本申请实施例提供的一种边缘节点的硬件和软件架构示意图;
图4是本申请实施例提供的一种POP节点的硬件和软件架构示意图;
图5是本申请实施例提供的一种携带SRH的IPv6数据报文的格式示意图;
图6是本申请实施例提供的一种发送报文的方法流程图;
图7是本申请实施例提供的一种加密技术示意图;
图8是本申请实施例提供的一种第一报文的格式示意图;
图9是本申请实施例提供的一种发送报文的流程示意图;
图10是本申请实施例提供的另一种发送报文的方法流程图;
图11是本申请实施例提供的另一种加密技术示意图;
图12是本申请实施例提供的另一种第一报文的格式示意图;
图13是本申请实施例提供的一种发送报文的流程示意图;
图14是本申请实施例提供的一种网络设备的结构示意图。
具体实施方式
为使本申请的目的、技术方案和优点更加清楚,下面将结合附图对本申请实施方式作进一步地详细描述。
应当理解的是,本文提及的“多个”是指两个或两个以上。在本申请的描述中,除非另有说明,“/”表示或的意思,例如,A/B可以表示A或B;本文中的“和/或”仅仅是一种描述关联对象的关联关系,表示可以存在三种关系,例如,A和/或B,可以表示:单独存在A,同时存在A和B,单独存在B这三种情况。另外,为了便于清楚描述本申请实施例的技术方案,在本申请的实施例中,采用了“第一”、“第二”等字样对功能和作用基本相同的相同项或相似项进行区分。本领域技术人员可以理解“第一”、“第二”等字样并不对数量和执行次序进行限定,并且“第一”、“第二”等字样也并不限定一定不同。
在对本申请实施例进行解释说明之前,先对本申请实施例的应用场景进行解释说明。
POP组网是SD-WAN中的一个典型应用场景。基于POP组网,企业或运营商可以在公有云上部署虚拟化的SD-WAN设备作为POP组网的接入点,该接入点也称为POP节点,并利用云间互联网和云专线资源,快速灵活的构建一张覆盖较大区域范围的SD-WAN骨干网。企业分支站点通过本地互联网线路就近接入到POP节点,经过云上SD-WAN骨干网实现跨区域的业务互访,满足企业组网、入云、上网等业务的需求。前述的SD-WAN骨干网也称为 POP骨干网。
企业的POP骨干网可以基于不同公有云服务商提供的云资源来构建,以提升POP骨干网中POP节点的覆盖能力。在多云POP骨干网的场景下,企业站点间的业务互访路径可以有多种选择,中间跨越的POP节点也可以有多个。在这个背景下POP组网需要支持跨越多个POP节点,以及支持跨POP端到端的动态选路。
在POP组网的场景中,业务互访的路径通常可以用多种选择。这里以企业分支与总部之间的互访路径为例,图1是本申请实施例提供的一种基于POP组网的企业分支与总部之间的互访路径示意图。如图1所示,POP组网选路场景,企业分支与总部之间的互访路径可以包括以下几种可选路径。
路径一(图1中标记为①)为跨POP路径,路径一上包括两个POP节点,POP节点之间通过云专线通信。路径二(图1中标记为②)也为跨POP路径,路径二上包括两个POP节点,POP节点之间通过云上互联网通信。路径三也为跨POP路径(图1中标记为③),路径三上有三个POP节点,这三个POP节点之间可通过云专线或云上互联网通信。路径四(图1中标记为④)为直连路径,企业分支和站点之间通过互联网直连。路径五(图1中标记为⑤)也为直连路径,企业分支和站点之间通过专线直连。
针对上述POP组网的场景,为了保证POP组网上传输业务报文的安全性,业界SD-WAN厂商通用的实现方案是采用分段隧道、逐跳加解密。其方案原理为:边缘(edge)节点与POP节点之间基于互联网建立IPsec加密隧道,POP节点与POP节点之间基于互联网建立IPsec加密隧道,或者POP节点与POP节点之间基于运营商专线或云专线建立加密或不加密的隧道。其中,边缘节点是指POP组网中边缘侧的节点,边缘节点用于将用户的报文接入到POP组网中。业务报文在POP网络中基于逐段隧道传输,POP点对接收到的业务报文解密解封装后根据业务报文IP头查路由找下一跳,再重新加封装转发给下一跳的POP节点或边缘节点。
上述方案中,边缘节点到POP节点、POP节点到POP节点之间都有IPsec加密隧道。因此,通过上述方案能够实现互联网上的业务报文的安全校验。但是在上述方案中,POP节点需要根据内层报文IP头查路由,这样就需要对完整的内层报文进行解密,从而导致解封装查路由效率较低。并且,业务报文在POP节点完整解密后,存在攻击者通过攻击POP节点获取用户数据的安全风险。此外,POP组网中由POP节点逐跳选路,也即是业务报文转发的路径由中间的每一个POP节点选择,无法实现跨POP端到端直接选路。
在此基础上,引入分段路由(Segment Routing)的思想。基于分段路由的POP组网中传输业务报文的方案原理为:边缘节点与边缘节点间跨越中间POP节点建立端到端IPsec加密隧道。边缘节点在封装业务报文时,将SRH封装在IPsec封装外,且SRH不加密。SRH中记录业务报文经过的POP节点的SID信息。边缘节点使用隧道将封装后的业务报文发送至POP节点,POP节点收到业务报文时不对业务报文中的IPsec报文解封装,直接根据SRH中的SID信息做下一跳转发即可。
国内SD-WAN服务提供商目前已基于公有云资源在全球构建了超过400个POP节点,为企业客户提供全球SD-WAN接入服务。且已经能够利用分段路由技术,通过对业务报文的内层(Inner)IP头和载荷(Payload)加密,将SRH暴露在外做路径调控。中间的POP节点收到业务报文后根据SRH中的路径信息来进行报文转发。
上述转发业务报文的方案实现了POP组网端到端加密。且上述技术方案中,中间POP 节点不解密业务报文中的IPsec报文,便可转发业务报文,因此POP节点转发效率较高。另外,上述方案支持POP组网上跨越多个POP节点传输业务报文,业务报文的传输路径可以集中调控,因此能够支持跨越POP的端到端选路。但是上述方案中POP节点的SID信息暴露在互联网上不安全,并且上述方案对合法报文和攻击报文无安全校验机制。
基于上述场景,本申请实施例引入一种新的SRH加密技术,以解决上述POP节点性能与安全性矛盾的问题,既保证了POP网络中POP节点的转发性能,又解决了SID信息泄露、报文合法性校验等安全性问题。
为了后续便于说明,在此先对本申请实施例涉及的POP组网的系统架构进行解释说明。图2是本申请实施例提供的一种POP组网的系统架构示意图。如图2所示,该POP组网中包括网络控制器、第一边缘节点、多个POP节点(图2中示例为POP节点1、POP节点2和POP节点3)以及第二边缘节点。
其中,第一边缘节点和POP节点1之间通过有线或无线方式进行通信,POP节点1和POP节点2之间通过有线或无线方式进行通信,POP节点2和POP节点3之间通过有线或无线方式进行通信,POP节点3和第二边缘节点之间通过有线或无线方式进行通信。各个边缘节点和POP节点均和网络控制器之间通过有线或无线方式进行通信。
图2中的网络控制器用于提供POP组网的编排和网络管理功能。这些功能包括但不限于边缘节点和POP节点的设备开局、设备的统一纳管、POP网络创建、SR路径策略调控以及各种网络增值服务策略定义、告警/日志信息采集、链路质量统计等等。
边缘节点,也即是需要借助POP组网进行互联的企业站点侧的边缘节点。边缘节点包括企业分支站点、企业总部或数据中心站点以及公有云站点等。如图2所示,第一边缘节点示例地可以为部署在企业分支侧的边缘节点,第一边缘节点用于将企业分支接入POP组网。第二边缘节点示例地可以为部署在企业总部侧的边缘节点,第二边缘节点用于将企业总部接入POP组网。因此,基于图2所示的POP组网,企业分支和企业总部之间通过POP组网互相访问。
POP节点,作为POP组网中的中间节点,一方面是边缘节点接入POP组网的入口网关,同时又借助运营商或公有云提供的底层(Underlay)骨干网,实现当前POP组网到其他区域的POP组网的互联。
需要说明的是,图2中以两个边缘节点和3个POP节点为例进行说明,本申请实施例并不限定POP组网中包括的边缘节点和POP节点的数量。
下面对图2中的边缘节点和POP节点的系统架构进行详细解释说明。
图3是本申请实施例提供的一种边缘节点的硬件和软件架构示意图。如图3所示,边缘节点的软件包括管理模块、路由模块、业务模块以及操作系统等。这些软件模块运行在边缘节点的硬件上。
其中,业务模块也称为用户面(User Plane)或转发面或数据面。业务模块用于处理和转发设备上各不同端口上各种类型的数据。业务模块还通过硬件基于转发表项实现流量转发。路由模块也称为控制面(Control Plane)。路由模块用于控制和管理所有网络协议的运行。路由模块还提供了数据面所必须的各种网络信息和转发查询表项。管理模块也称为管理面(Management Plane)。管理模块用于面向系统操作维护人员(或外部第三方管理软件),提 供输入输出、用户管理、认证(License)、管理对象的监控、配置、告警、统计等,不直接对系统的运行状态产生影响。
如图3所示,边缘节点的硬件包括处理器、内存、硬盘以及通信芯片。
图3中的处理器可以是一个通用中央处理器(central processing unit,CPU)、特定应用集成电路(application-specific integrated circuit,ASIC)或一个或多个用于控制本申请方案程序执行的集成电路。
图3中的内存是指与处理器直接交换数据的内部存储器,它可以随时读写数据,而且速度很快,作为操作系统或其他正在运行中的程序的临时数据存储器。内存包括至少两种存储器,例如内存既可以是随机存取存储器,也可以是只读存储器(Read Only Memory,ROM)。举例来说,随机存取存储器是动态随机存取存储器(Dynamic Random Access Memory,DRAM),或者存储级存储器(Storage Class Memory,SCM)。当内存中的数据总量达到一定阈值时,处理器将内存中存储的数据发送给硬盘进行持久化存储。图3中的硬盘用于提供存储资源,例如存储数据。它可以是磁盘或者其他类型的存储介质,例如固态硬盘或者叠瓦式磁记录硬盘等。
图3中的通信芯片,使用任何收发器一类的装置,用于与其它设备或通信网络通信,如以太网,无线接入网(radio access network,RAN),无线局域网(wireless local area networks,WLAN)等。
此外,POP节点可以采用虚拟化的方式部署在服务器上。示例地,POP节点部署在运营商的数据中心,或部署在公有云上。这种场景下,POP节点的软件和硬件架构如图4所示。如图4所示,虚拟化的POP节点的系统架构包括硬件平台、虚拟化平台(hypervisor)以及虚拟机执行空间。其中硬件平台是指POP节点的物理结构,具体包括处理器、内存、硬盘以及网卡等。虚拟化平台提供了物理硬件和虚拟机之间的中间层,负责协调各个虚拟机对硬件平台的访问。虚拟机执行空间中运行了多个虚拟机,每个虚拟机相当于一个虚拟的POP节点,从而实现POP节点的功能。虚拟机的操作系统运行在虚拟硬件平台上,虚拟硬件平台中包括虚拟出来的内存(memory),虚拟出来的处理器,虚拟出来的硬盘(storage),和虚拟出来的网卡(nic)等。每个虚拟机中包括控制平面和转发平面,控制平面用于管理POP节点的转发策略,转发平面用于POP节点转发业务报文,也即是POP节点的转发平面和控制平面解耦。
可选地,POP节点也可以采用物理设备的形态,此时,POP节点的软件和硬件架构和图3中边缘节点的软件和硬件架构基本一致,在此不再赘述。
需要说明的是,上述是以POP组网为例说明本申请的应用场景。可选地,本申请实施例提供的SRH加密技术方案也可以应用在其他基于SR技术发送报文的场景中,在此不再一一举例说明。
由于本申请实施例提供的技术方案用于对SRH加密,因此为了后续便于说明,在此先对SRv6技术进行简单说明。
基于IPv6转发面的SR,通过在IPv6报文中插入一个路由扩展头(segment routing header,SRH),在SRH中压入一个显式的IPv6地址栈,通过中间节点不断的进行更新目的地址和偏移地址栈的操作来完成逐跳转发。SRv6技术就是采用上述的IPv6转发技术,通过灵活的IPv6扩展头,实现网络可编程。SRv6将一些IPv6地址定义成实例化的SID,每个SID有着自己 显式的作用和功能,通过不同的SID操作,实现简化的VPN,以及灵活的路径规划。
图5是本申请实施例提供的一种携带SRH的IPv6数据报文的格式示意图。如图5所示,该IPv6数据报文包括IPv6头(IPv6头也即外层IP头)、SRH、内层IP头和载荷(内层IP头和载荷图5中未示出)。
其中,IPv6头中包括版本字段、流量类别字段、流标签字段、载荷长度字段、下一报头字段、跳数限制字段、源地址字段和目的地址字段等。其中,下一报头字段指示IPv6数据报文中位于IPv6头的下一个报文头的类型。源地址指示IPv6数据报文的源地址,目的地址指示IPv6数据报文的目的地址。关于IPv6头中的其他各个字段的解释可以参考相关标准协议,本申请实施例对此不做限定。
如图5所示,SRH包括下一报头(Next Header)字段、头扩展长度(Hdr Ext len)字段、路由类型(Routing type)字段、剩余节点数量(Segment Left,SL)字段、指示SID列表中最后一个SID的索引(Last Entry)的字段、标识(Flags)字段、标签(Tag)字段、SID列表字段以及可选的类型-长度-值(type-length-value,TLV)字段。
下一报头字段、头扩展长度字段、路由类型字段、SL字段、指示SID列表中最后一个SID的索引的字段、标识字段这六个字段中每个字段的长度均为8比特,标签字段的长度为16比特。这7个字段的总长度为8字节,且SRH中前8个字节的长度为固定的。为了便于后续说明,将SRH中可选的TLV之前的部分称为SRH标准头,如此SRH包括SRH标准头和可选的TLV,SRH标准头包括前8个固定字节和SID列表。
其中,下一报头字段指示位于SRH的下一个报文头的类型,头扩展长度字段指示SRH中不包括前8个字节的其他字段的长度。路由类型字段指示当前头的类型,示例地路由类型字段的值等于4,表明当前报文头为SRH。剩余节点数量指示到达目的节点前仍然应当访问的中间节点数,报文每经过SID列表中的一个SID所指示的节点,该剩余节点数量则减1。标识字段用于携带一些数据包的标识信息,标签字段用于标识同组数据包。可选的TLV用于SRH实现更多的功能。
如图5所示,SID列表包括Segment List[0]、Segment List[1]、…、Segment List[N]等N+1个SID。每个SID可以对应于一个128比特的IPv6地址,用于标识转发路径上具有该SID的节点或链路。
基于图5所示的SRH,对于图2所示的POP组网,第一边缘节点在向第二边缘节点发送报文时,便可直接确定一条第一边缘节点到第二边缘节点的转发路径,基于该转发路径上各个节点的SID,在该报文中封装SRH头,从而实现POP组网中端到端的直接选路。
下面对本申请实施例提供的SRH加密技术进行详细解释说明。具体地,本申请实施例提供了两种SRH加密机制。为了后续便于说明,将这两种SRH加密机制分别称为第一SRH加密机制和第二SRH加密机制。其中,第一SRH加密机制是只对SRH中的部分信息(该部分信息至少包括SID列表)进行加密,第二SRH加密机制是对完整的SRH进行加密。下述两个实施例用于分别对这两种SRH加密机制展开说明。
图6是本申请实施例提供的一种发送报文的方法流程图。该方法用于对第一SRH加密机制进行解释说明。如图6所示,该方法包括如下几个步骤。
步骤601:第一设备发送第一报文,第一报文包括SRH和载荷,SRH包括加密字段和不 加密字段,该加密字段至少包括加密后的分段标识SID列表,SID列表指示第一报文的传输路径。
本申请实施例是对SRH中的部分字段进行加密,且加密之后SRH对外而言仍然表现为SRH的格式,只是部分字段由明文变为暗文,因此SRH中需要包括不加密字段,后续节点基于不加密字段便可知道当前报文头是个SRH。
由于SID列表是至少需要被加密的,为了便于其他节点能够解密出SID列表,其他节点则需要根据SRH中的其他信息明确SID列表的具体位置。因此,在一些实施例中,该不加密字段包括指示SID列表中最后一个SID的索引(Last Entry)的字段。由于SRH中的前8个字节的长度是固定的,且根据SRH外层的IPv6头可以明确SRH的起始位置,因此根据Last Entry字段便可明确SID列表的起始位置和终止位置,也即是,确定SID列表的具体位置。
在另一些实施例中,不加密字段除了包括Last Entry字段,还可以进一步包括路由类型(Routing type)字段。这种场景下,其他节点可以基于路由类型(Routing type)字段和Last Entry字段确认SRH的具体位置。
在另一些实施例中,还可以将加密过程中使用的一些信息添加在报文中,以便于后续其他节点基于这些信息对加密字段进行解密。示例地可以通过扩展TLV来携带加密过程中使用的一些信息,扩展TLV的相关内容将在后续详细解释说明。这种场景下,该不加密字段还可以进一步包括头扩展长度(Hdr Ext len)字段。由于头扩展长度字段指示SRH中不包括前8个字节的其他字段的长度,因此,根据Hdr Ext len字段和前述的Last Entry字段便可确定SRH中TLV的具体位置,以便于其他节点基于扩展TLV来获取加密过程中使用的一些信息,进而基于这些信息解密加密字段。
在本申请实施例中,SRH中的加密字段至少需要包括SID列表,以避免SID列表暴露在网络中。
另外,由于是对SRH中的SID列表加密,为了便于后续其他节点能够快速了解到报文中的SID列表是否被加密了,还可以对SRH标准头的预留标识(flags)字段进行扩展,以使预留标识字段的取值能够指示SID列表是否被加密。在一些实施例中,预留标识字段包括一个特定的比特位,该比特位上的值为1时,指示SRH中的SID列表被加密,该比特位上的值为0时,指示SRH中的SID列表未被加密。在SRH中的预留标识字段的取值用于指示SID列表是否被加密的情况下,该预留标识字段也是不能被加密的,也即是,前述的不加密字段还包括该预留标识字段。可选地,如果网络中各个节点预先约定全部对SID列表加密,则也可以不对预留标识字段进行上述扩展。
可选地,如果SRH中的预留标识字段的取值不用于指示SID列表是否被加密,则此时预留标识字段可以放在加密字段中,也可以放在不加密字段中。
可选地,在一些实施例中,加密字段还可以进一步包括SL字段,以避免攻击者基于SL字段推测到报文之后的转发路径。此外,加密字段还可以包括下一报头字段以及标签字段等等。
基于上述关于加密字段和不不加密字段中的任一实现方式,第一设备便可生成上述第一报文,并发送第一报文。下面以第一设备为图2所示的POP组网中的第一边缘节点,上述第一报文的载荷的目的地为第二边缘节点为例,对步骤601进行详细解释说明。
对于图2所示的组网,在一些实施例中,步骤601的实现过程可以通过以下几个步骤实 现。
步骤(1):第一边缘节点接收企业分支的局域网(LAN)侧发送的业务报文。
该业务报文包括内层IP头(内层IP头也称为原始IP头)和载荷。其中,内层IP头携带该业务报文的源IP地址和目的IP地址,其中,源IP地址可以为企业分支的局域网(LAN)中的一个终端设备的IP地址,目的IP地址可以为企业总部的局域网中的一个终端设备的IP地址。
步骤(2):第一边缘节点生成SRH,并对SRH中的部分信息进行加密,以使SRH包括加密字段和不加密字段。
第一边缘节点基于业务报文内层IP头中的目的IP地址,确定一条转发路径。如图2所示,该转发路径为:第一边缘节点→POP节点1→POP节点2→POP节点3→第二边缘节点。基于该转发路径,确定SRH中的SID列表,该SID列表包括POP节点1的SID、POP节点2的SID、POP节点3的SID以及第二边缘节点的SID。基于SID列表以及SRH的基本格式便可生成还未被加密的SRH。然后确定SRH中哪些字段为待加密字段,哪些字段为不加密字段,以便对SRH中待加密字段进行加密,以使最后生成的SRH包括加密字段和不加密字段。该加密字段至少包括加密后的SID列表。
在确定出SRH中的待加密字段后,便可基于加密技术对待加密字段进行加密。图7是本申请实施例提供的一种加密技术示意图,在图7中,使用封装安全载荷(Encapsulating Security Payload,ESP)加密技术对SRH中待加密字段进行加密。如图7所示,ESP加密技术的基本原理为:将SRH中的待加密字段(图7中仅示例了SID列表)和ESP尾(trailer)一起使用加密密钥,通过加密算法加密,得到加密字段。由于当前是对SRH进行加密,为了后续便于区分其他ESP技术,图7以及后续将用于SRH加密的ESP尾称为SRH ESP尾。然后将SRH标准头以及SID列表和ESP头一起使用校验密钥,通过校验算法得到完整性校验值(integrity check value,ICV),该完整性校验值即为SRH校验结果。后续其他节点可以先根据该完整性校验值校验SRH的完整性,在完整性校验通过之后再对加密字段进行解密,以得到不包括加密字段的SRH。同样地,为了后续便于区分其他ESP技术,图7以及后续将用于SRH加密的ESP头称为SRH ESP头、将基于SRH生成的完整性校验值称为SRH ESP校验值。
需要说明的是,图7最下方的报文中SRH ESP头、SRH ESP尾以及SRH ESP校验值的位置并不是报文中SRH ESP头、SRH ESP尾以及SRH ESP校验值实际位置,图7用于示例说明SRH ESP头、SRH ESP尾以及SRH ESP校验值的功能。关于SRH ESP头、SRH ESP尾以及SRH ESP校验值的实际位置将在后续图8中详细说明。
其中,SRH ESP尾包括填充数据(Padding)和填充长度(Pad length)。在使用块加密时,如果最后一个数据块长度不足则根据该填充数据进行填充。填充长度是指填充的数据段的长度,方便拆包时找到用来填充的数据段。
SRH ESP头由安全参数索引号(Security Parameter Index,SPI)和序列号(Sequence Number)两部分组成。其中,SPI决定加密字段所对应的安全关联(security association,SA),其他节点能够根据SA指定的摘要算法和校验密钥对加密字段进行完整性校验,根据SA指定的加密算法和解密密钥对加密字段进行解密。序列号用于保证数据是新的,避免重放攻击。
上述ESP加密技术是本申请实施例的一种可选地的加密实现方式,任意加密技术均可以用来加密SRH中的待加密字段。
需要说明的是,第一报文中除了对SRH进行上述加密,还可以对业务报文进行IPsec加密封装,如图7所示,基于IPsec加密封装后的业务报文包括ESP头、内层IP头、载荷、ESP尾以及ESP校验值,图7中还将基于IPsec加密封装后的业务报文称为内层IPsec加密载荷。此外,基于IPsec加密封装后的业务报文中的ESP头、ESP尾、以及ESP校验值的相关解释可以参考上述对SRH进行ESP加密的相关解释,在此不再详细说明。
上述完整性校验值是基于SRH标准头生成的,因此完整性校验值用于对SRH标准头进行完整性校验。可选地,在另一些实施例中,在得到加密字段后,还可以根据包括加密字段的整个SRH生成完整性校验值,此时该完整性校验值用于校验SRH中前8个字节、SID列表以及扩展TLV的完整性。可选地,在另一些实施例中,在得到加密字段后,还可以根据整个SRH和IPv6头生成完整性校验值,此时该完整性校验值用于校验SRH以及IPv6头的完整性。
基于上述不同的场景,还可以在SRH中扩展一个完整性校验标记字段,该完整性校验标记字段的值能够指示完整性校验值用于校验哪部分的完整性校验值。本申请实施例不限定完整性校验标记字段的具体位置。示例地,可以在前述SRH的标识(Flags)字段中扩展出前述的完整性校验标记字段。也即是,在本申请实施例中,SRH的标识(Flags)字段还包括完整性校验标记字段,该完整性校验标记字段的值指示需要进行完整校验的字段。
需要说明的是,如果加密机制中统一约定完整性校验值的生成依据,也即是统一约定完整性校验值用于校验哪部分的完整性,此时,则无需扩展上述完整性校验标记字段。示例地,在图6所示的加密机制中,统一约定完整性校验值用于校验SRH中前8个字节以及SID列表的完整性。或者统一约定完整性校验值用于校验整个SRH的完整性。
此外,在另一些实施例中,在对SRH中的部分字段加密之后,也可以不生成针对加密字段的完整性校验值,这样后续只需解密加密字段即可,不需要对加密字段进行完整性校验。
另外,如前述内容介绍,在对SRH中的待加密字段加密之后,可以将加密过程中使用的一些信息添加在报文中,以便于后续其他节点基于这些信息对加密字段进行解密,或解密和校验。可选地,如果网络中各个节点提前约定使用统一的加密校验技术,此时则无需将加密过程使用的一些信息添加到报文中,其他节点基于约定的加密校验技术对加密字段进行处理即可。前述对SRH中的待加密字段加密过程中使用的一些信息可以称为加密元数据。
在一些实施例中,可以在SRH中扩展一个TLV,也即是在SRH中增加扩展TLV,该扩展TLV用于携带上述加密元数据。
示例地,该扩展TLV携带加密元数据,SRH中的加密字段是基于该加密元数据加密的,且需保证该加密元数据没有被加密,以便于后续其他节点基于该加密元数据对SRH中的加密字段进行处理。比如,该加密元数据包括前述ESP技术中的SRH ESP头。
又示例地,由于SRH中是部分字段进行了加密,因此可以对该扩展TLV的标识字段进行扩展,以使标识字段的取值指示SRH中加密字段和不加密字段的位置。换句话说,该扩展TLV还可以包括加密标识(encryption flags)字段,该加密标识字段指示SRH中加密字段和不加密字段的位置,以便于后续其他节点根据该加密标识字段确定SRH中哪些字段是加密的。
在一种可能的实现方式中,该加密标识字段包括8个比特位组,这8个比特位组分别和SRH标准头中下一报头字段、头扩展长度字段、路由类型字段、SL字段、指示SID列表中最后一个SID的索引的字段、标识字段、标签字段、SID列表字段这8个字段一一对应。每 个比特位组上的数值指示相应字段是否被加密。比如,加密标识字段包括8个比特位,这8个比特位和前述的8个字段一一对应。对于任一比特位,该比特位上的值为1时指示相应字段被加密,该比特位上的值为0时指示相应字段没有被加密。
又示例地,在上述基于ESP技术加密的场景中,该扩展TLV还携带加密后的填充数据,如前述ESP加密技术原理可知,此时SRH中的加密字段还包括加密后的填充数据。
又示例地,在对加密字段还确定了完整性校验值的情况下,该扩展TLV还携带完整性校验值,该完整性校验值用于校验SRH中的加密字段的完整性。
图8是本申请实施例提供的一种第一报文的格式示意图。如图8所示,第一报文包括IPv6头,SRH以及内层IP头和载荷。其中,IPv6头中的字段和内层IP头的解释可以参考前述相关内容,在此不再赘述。
如图8所示,SRH包括SRH标准头和扩展TLV。SRH标准头中的字段的解释可以参考图5中的相关内容,在此不再赘述。图8中SRH中加密字段(图8中加黑字体)包括下一报头(Next Header)字段、SL字段、标签(Tag)字段以及SID列表字段。不加密字段包括头扩展长度(Hdr Ext len)字段、路由类型(Routing type)字段、指示SID列表中最后一个SID的索引(Last Entry)的字段和标识(Flags)字段。
SRH中的标识字段中的第一个比特位的值为1,指示SRH中的SID列表被加密。
扩展TLV中包括类型字段、长度字段、加密标识字段、预留字段、SPI字段、序列号字段、填充数据字段、填充长度字段、完整性校验值字段。
其中,类型字段为需新申请的类型,该类型用于指示该扩展TLV用于携带加密元数据。长度字段指示扩展TLV的长度。加密标识字段包括8个比特位,这8个比特位分别和下一报头字段、头扩展长度字段、路由类型字段、SL字段、指示SID列表中最后一个SID的索引的字段、标识字段、标签字段、SID列表字段这8个字段一一对应。每个比特位组上的数值指示相应字段是否被加密。
SPI字段和序列号字段分别用于携带前述SRH ESP头中的SPI和序列号。填充数据字段和填充长度字段分别用于携带前述SRH ESP尾中的填充数据和填充长度。完整性校验值字段用于携带前述基于ESP技术得到的ICV。
如图8所示,具体加密时,将SRH标准头中的待加密字段、填充数据字段和填充长度字段一起使用加密密钥,通过加密算法加密,以使图8中SRH中各个待加密字段由明文变为暗文。
需要说明的是,图8是本申请实施例提供的扩展TLV的一种可选的实现方式,本申请实施例并不限定扩展TLV的具体格式。
步骤(3):第一边缘节点将加密后的SRH封装在业务报文的外层,然后在SRH的外层继续封装IPv6头,以得到前述第一报文,然后发送第一报文。
第一边缘节点在对SRH加密之后,便可通过上述步骤(3)得到第一报文。如此得到的第一报文的SRH中的SID列表是被加密后的SID列表,从而可以避免SID列表暴露在网络中。
此外,上述IPv6头中携带目的IP地址,IPv6头中的目的IP地址为SID列表中位于第一边缘节点的SID后的下一个SID所对应的IP地址。
此外,第一边缘节点在将加密后的SRH封装在业务报文的外层前,还可以将业务报文基 于IPsec加密封装,以保证业务报文的安全性。
示例地,图9是本申请实施例提供的一种发送报文的流程示意图。如图9所示,第一边缘节点收到LAN侧的业务报文,该业务报文包括载荷和内层IP头,根据内层IP头中的目的IP查找路由,确定该业务报文的目的地第二边缘节点的隧道接口IP。第一边缘节点根据本机配置的或由网络控制器集中下发的SR路径调度策略,基于第二边缘节点的隧道接口IP确定报文封装后SRH中的SID列表。第一边缘节点对该业务报文进行IPsec加密封装,封装内容包括内层IP头和载荷。第一边缘节点对IPsec加密封装后的报文增加SRH,并对SRH中的SID列表进行加密封装。第一边缘节点对SRH加密后的报文再封装IPv6头,得到前述第一报文,然后将第一报文从WAN接口转发到POP网络。
此外,对于图2所示的POP组网,第一边缘节点接收到企业分支的局域网(LAN)侧发送的业务报文时,该业务报文中也可以已经封装有SRH,此时对于第一边缘节点,第一边缘节点直接基于上述加密机制对SRH进行加密即可。
步骤602:第二设备接收第一报文。
第一设备在发送第一报文之后,网络中任一节点在接收到第一报文后,先比对自身的IPv6地址和第一报文的IPv6头中的目的IP地址是否一致,如果不一致,则基于第一报文的IPv6头中的目的IP地址查本地路由,然后基于查找到的路由继续转发第一报文。如果一致,则需解封装SRH,然后根据下述步骤603和步骤604对第一报文进行后续处理。
示例地,在第一设备为图2所示的POP组网中的第一边缘节点的情况下,第二设备可以为POP节点1、POP节点2以及POP节点3中任一POP节点或第二边缘节点。
步骤603:第二设备解密加密字段,得到不包括加密字段的SRH。
在SRv6网络中,中间节点在接收到报文时,需要根据SRH来确定当前的操作。因此,第二设备在接收到第一报文时,需要先解密加密字段,以使SRH中加密字段由明文转为暗文。
在一些实施例中,在步骤601中不加密字段包括指示SID列表中最后一个SID的索引的字段的情况下,步骤603的实现过程为;第二设备基于SRH中指示SID列表中最后一个SID的索引的字段,确定SID列表的终止位置,第二设备基于IPv6头确定SID列表的起始位置,第二设备基于SID列表的起始位置和SID列表的终止位置,获取加密后的SID列表,以解密SID列表。
由于SRH中前8个字节的格式是相关标准规定的,因此第二设备在基于IPv6头得到SRH的起始位置后,便可进一步确定SID列表的起始位置。
在另一些实施例中,在步骤601中不加密字段包括指示SID列表中最后一个SID的索引的字段和路由类型字段的情况下,步骤603的实现过程为;第二设备基于SRH中指示SID列表中最后一个SID的索引的字段,确定SID列表的终止位置,第二设备基于路由类型字段确定SID列表的起始位置,第二设备基于SID列表的起始位置和SID列表的终止位置,获取加密后的SID列表,以解密SID列表。
在一些实施例中,在步骤601中的不加密字段包括预留标识字段,且预留标识字段的取值指示SID列表是否被加密的情况下,在预留标识字段的取值指示SID列表已经被加密的情况下,第二设备才会去基于步骤603执行解密加密字段的操作。相应地,在预留标识字段的取值指示SID列表没有被加密的情况下,此时第二设备则无需执行步骤603,直接基于未加密的SRH进行下一步操作即可。
在一些实施例中,在步骤601中的SRH包括扩展TLV,且扩展TLV携带加密元数据的情况下,由于加密元数据没有被加密,因此第二设备解密加密字段的实现过程为:第二设备从扩展TLV中获取加密元数据,基于加密元数据解密加密字段。具体地,基于加密元数据确定加密算法和解密密钥,基于加密算法和解密密钥来解密加密字段。
需要说明的是,本申请实施例使用的加密算法可以为对称加密算法,这种场景下步骤601中加密使用的加密密钥和步骤603中解密所使用的解密密钥为相同密钥。可选地,加密算法也可以为非对称加密算法,这种场景下步骤601中加密使用的加密密钥通常为公钥和步骤603中解密所使用的解密密钥为私钥,也即是,加密使用的加密密钥和解密使用的解密密钥为一对公私密钥。
示例地,上述加密元数据为ESP技术中的ESP头的情况下,第二设备根据ESP头中的SPI确定SA,根据SA指定的加密算法和解密密钥对加密字段进行解密。
此外,在上述基于扩展TLV获取加密元数据的场景中,在一些实施例中不加密字段还包括头扩展长度字段,此时第二设备基于头扩展长度字段和指示SID列表中最后一个SID的索引的字段,便可确定SRH中TLV的位置,进而获取到前述扩展TLV,然后得到加密元数据。
在一些实施例中,在步骤601中的扩展TLV包括加密标识字段,且加密标识字段指示SRH中加密字段和不加密字段的位置的情况下,第二设备解密加密字段之前,先基于加密标识字段确定加密字段在SRH中所处的位置,也即是确定出SRH中哪些字段是加密的。
在一些实施例中,在步骤601中的扩展TLV还携带填充数据的情况下,第二设备解密加密字段的实现过程为:根据扩展TLV携带的填充数据从解密后的字段中删除填充数据,得到不包括加密字段的SRH。
示例地,在扩展TLV包括填充数据字段和填充长度字段的情况下,第二设备从解密后的字段中删除和填充数据长度相同长度的填充数据,从而得到不包括加密字段的SRH。
在一些实施例中,在步骤601中的扩展TLV携带完整性校验值的情况下,第二设备在解密加密字段之前先基于完整性校验值校验SRH标准头(也即SRH中位于SID列表前的字段以及所述SID列表)的完整性,在SRH标准头完整性没有被破坏的情况下,执行解密加密字段的操作。
示例地,上述加密元数据为ESP技术中的ESP头的情况下,第二设备根据ESP头中的SPI确定SA,根据SA指定的摘要算法和校验密钥计算SRH标准头的摘要值、然后对比该摘要值和完整性校验值,如果两者一致,则表明SRH标准头完整性没有被破坏,进而对加密字段进行解密。相应地,如果两者不一致,则表明SRH标准头已被更改,此时则需要执行其他操作,在此不再详细说明。
如步骤601中对完整性校验值的功能介绍可知,完整性校验值可以至少用于校验SRH标准头的完整性校验值。任一场景下的完整性校验值,均可以参考前述实施例进行完整性校验,在此不再一一举例说明。
在另一些实施例中,如果步骤601中在SRH中扩展一个完整性校验标记字段,该完整性校验标记字段的值能够指示完整性校验值用于校验哪部分的完整性校验值。则第二设备先根据该完整性校验标记字段确定需要完整性校验的字段,然后根据该完整性校验值校验这些字段的完整性。
步骤604:第二设备基于不包括加密字段的SRH对第一报文进行处理。
在一些实施例中,第二设备在得到不包括加密字段的SRH之后,便可从SID列表中确定最后一个SID,该最后一个SID即为该载荷的目的地的IPv6地址。第二设备将该IPv6地址和自身的IPv6地址进行比对,如果两者一致,则确定自身是载荷的目的地,如果两者不一致,则表明自身不是载荷的目的地。
在第二设备基于不包括加密字段的SRH确定自身不是载荷的目的地的情况下,表明第二设备还是SID列表所指示的转发路径上的中间节点,因此第二设备需要对SRH中的SL字段进行修改,示例地,将SL值减去1,然后基于修改后的SRH生成第二报文,第二报文包括修改后的SRH和载荷。具体地,在第一报文的内层报文(也即前述业务报文包括内层IP头和载荷)封装修改后的SRH,并继续封装IPv6头,该IPv6头携带的目的地址为SID列表中位于第二设备的SID后的下一个SID所对应的IPv6地址,以得到第二报文,进而发送第二报文。
可选地,在本申请实施例中,第二设备还可以先将修改后的SRH进行加密,然后在第一报文的内层报文头封装加密的修改后的SRH,并继续封装IPv6头,以得到第二报文,进而发送第二报文。此时,第二报文的SRH中也包括加密字段和不加密字段。其中,第二设备加密修改后的SRH可以步骤601,在此不再赘述。也即是,第二报文的SRH中的加密字段和不加密字段的相关解释可以参考步骤601,在此不再赘述。
示例地,在第二设备确定自身和报文的下一跳之间有专线的情况下,不对修改后的SRH加密,在自身和报文的下一跳之间没有专线的情况下,对修改后的SRH加密。需要说明的是,在本申请实施例中,第二设备也可以不区分情况直接对修改后的SRH加密。
第二设备发送第二报文后,后续节点的处理过程和第二设备对第一报文的处理过程相同,在此不再赘述。
此外,在步骤604中,如果第二设备确定出自身是载荷的目的地。此时,第二设备将第一报文中的SRH弹出,得到业务报文,然后根据业务报文中携带的目的IP地址进行继续后续处理过程。
下面仍然以图9为例,对上述步骤602至步骤604进行举例说明。
如图9所示,任一POP节点从互联网WAN接口接收到加密后的报文(也即前述第一报文)后,解析IPv6头,从IPv6头中“下一报头”字段中确定下一个报文头为SRH头。该POP节点解析SRH,对SRH中的包括SID列表的加密字段进行解密操作。POP节点获取到SID列表,确定下一跳,该下一跳为POP节点或第二边缘节点,并修改SL值。POP节点对修改后的SRH进行头加密。POP节点封装IPv6头,源IP不变,目的IP为下一跳的地址,并向下一跳转发。
需要说明的是,若该POP节点的下一跳为目的Edge节点(也即第二边缘节点),可选择直接弹出SRH头,然后转发报文。该POP节点按需选择是否使能SRH头加密,如果该POP节点和下一跳的POP节点间为专线则可不加密。
第二边缘节点从WAN接口接收到加密报文时,解析IPv6头,并从IPv6头中“下一报头”字段确定下一报文个头为SRH。第二边缘节点解析SRH,对SRH头中的加密字段进行解密操作。第二边缘节点获取到SID列表,确定自身为目的节点,从而对报文进行内层IPsec解密。第二边缘节点完成IPsec解密,获取到业务报文的目的IP和载荷。第二边缘节点根据业务报文的目的IP查路由表转发给LAN侧内网设备。
综上所述,图5所示的实施例提供了一种SRH头加密机制。该SRH头加密机制至少对SID列表进行加密。其中,边缘节点与POP节点间基于互联网,建立该SRH头加密机制。POP节点与POP节点间如采用互联网传输,也建立该SRH头加密机制;如采用专线网络传输,可不涉及SRH头加密。基于该加密机制,在POP组网中传输的SRv6报文,SRv6报文的SRH中的SID列表是被加密的,保护SRH头中SID信息不被泄露。并且实现了POP组网端到端加密,中间POP节点不解密载荷,从而使得中间POP节点转发效率较高。此外,还提供了POP节点在互联网上对收到的报文的安全校验机制。
图10是本申请实施例提供的另一种发送报文的方法流程图。该方法用于对本申请实施例提供的第二SRH加密机制进行解释说明。第二SRH加密机制中对SRH整体进行加密。如图10所示,该方法包括如下几个步骤。
步骤1001:第一设备发送第一报文,第一报文包括第一加密部分,第一报文的分段路由头SRH在第一加密部分之中,第一报文的载荷不在第一加密部分中。
为了避免SRH中的SID列表暴露在网络中,需将SID列表加密,同时为了避免后续载荷被攻击,载荷也基于IPsec加密封装,此时为了保证后续节点在解密SRH时不把载荷解密出来,需要将SRH和载荷进行不同的加密。因此,步骤1001中的第一报文的第一加密部分包括SRH但是不包括载荷。此外,将基于IPsec加密封装后的载荷称为第二加密部分。
本申请实施例扩展一种新的报文头,该新的报文头中包括整体加密后的SRH,以避免SID列表暴露在网络中。因此,在一些实施例中,第一报文包括扩展报文头,前述的第一加密部分携带在扩展报文头中。
这种场景下,步骤1001的实现过程为:第一设备在封装第一报文的过程中,将第一报文的SRH单独加密,并将单独加密后的SRH以扩展报文头的方式封装,从而得到第一报文。下面以第一设备为图2所示的POP组网中的第一边缘节点,上述第一报文的载荷的目的地为第二边缘节点为例,对步骤1001进行详细解释说明。
对于图2所示的组网,在一些实施例中,步骤1001的实现过程可以通过以下几个步骤实现。
步骤(1):第一边缘节点接收企业分支的局域网(LAN)侧发送的业务报文。
该步骤(1)的实现方式可以参考图5所示的实施例中的步骤501,在此不再赘述。
步骤(2):第一边缘节点生成SRH,并对SRH整体进行加密。
第一边缘节点基于业务报文内层IP头中的目的IP地址,确定一条转发路径。然后基于该转发路径确定SID列表,进而生成SRH。具体实现方式可以参考图5所示的实施例中的步骤501,在此不再赘述。
在生成SRH后,便可基于加密技术对待SRH进行加密。图11是本申请实施例提供的另一种加密技术示意图,在图11中,使用封装安全载荷(Encapsulating Security Payload,ESP)加密技术对SRH进行加密。如图11所示,ESP加密技术的基本原理为:将SRH和ESP尾(trailer)一起使用加密密钥,通过加密算法加密,得到第一加密部分。由于当前是对SRH进行加密,为了后续便于区分其他ESP技术,图11以及后续将用于SRH加密的ESP尾称为SRH ESP尾。在将SRH加密之后,便可将加密的内容作为第一加密部分,第一边缘节点将第一加密部分封装在扩展报文头中。然后将扩展报文头和ESP头一起使用校验密钥,通过校验算法得到 完整性校验值(integrity check value,ICV),该完整性校验值即为SRH校验结果。后续其他节点可以先根据该完整性校验值校验扩展报文头的完整性,在完整性校验通过之后再对第一加密部分进行解密,以得到未被加密的SRH。同样地,为了后续便于区分其他ESP技术,图11以及后续将用于SRH加密的ESP头称为SRH ESP头、将基于SRH生成的完整性校验值称为SRH ESP校验值。
其中,和图6所示的实施例一样,SRH ESP尾包括填充数据(Padding)和填充长度(Pad length)。SRH ESP头由安全参数索引号(Security Parameter Index,SPI)和序列号(Sequence Number)两部分组成。相关内容参考图6所示的实施例,在此不再赘述。
需要说明的是,上述ESP加密技术同样是本申请实施例的一种可选地的加密实现方式,任意加密技术均可以用来加密SRH中的待加密字段。
此外,和图6所示的实施例一样,第一报文中除了对SRH进行上述加密,还可以对业务报文进行IPsec加密封装,如图11所示,基于IPsec加密封装后的业务报文包括ESP头、内层IP头、载荷、ESP尾以及ESP校验值。其中,基于IPsec加密封装后的业务报文中的ESP头、ESP尾、以及ESP校验值的相关解释可以参考上述对SRH进行ESP加密的相关解释,在此不再详细说明。
另外,在对SRH加密之后,也可以不生成针对加密字段的完整性校验值,这样后续只需解密SRH即可,不需要对SRH进行完整性校验。
另外,在加密得到第一加密部分后,可以将加密过程中使用的一些信息添加在报文中,以便于后续其他节点基于这些信息对第一加密部分解密,或解密和校验。可选地,如果网络中各个节点提前约定使用统一的加密校验技术,此时则无需将加密过程使用的一些信息添加到报文中,其他节点基于约定的加密校验技术对第一加密部分进行处理即可。前述对SRH加密过程中使用的一些信息称为加密元数据。
示例地,在上述扩展了一种新的扩展报文头的情况下,该扩展报文头还携带加密元数据。第一加密部分是基于加密元数据加密的,且需保证该加密元数据没有被加密,以便于后续其他节点基于该加密元数据对SRH中的加密字段进行处理。换句话说,加密元数据不在第一加密部分中。比如,该加密元数据包括前述ESP技术中的SRH ESP头。
上述加密元数据是携带在扩展报文头中。可选地,加密元数据也可以携带在第一报文的其他字段中,只需保证该加密元数据不在第一加密部分即可。
又示例地,在上述基于ESP技术加密的场景中,该扩展报文头还携带填充数据,如前述ESP加密技术原理可知,此时第一加密部分还包括加密后的填充数据。
又示例地,在对扩展报文头还确定了完整性校验值的情况下,该扩展报文头还携带完整性校验值,该完整性校验值用于校验扩展报文头的完整性。由于扩展报文头中携带有SRH,因此通过对扩展报文头的完整性校验,来实现对SRH的完整性校验。
需要说明的是,本申请实施例提供的完整性校验可以仅仅对扩展报文头进行完整性校验,也可以同时对扩展报文头和IPv6头进行完整性校验。也即是,第一报文中携带的完整性校验值至少用于对扩展报文头进行完整性校验。
在仅仅对扩展报文头进行完整性校验的场景中,扩展报文头中携带的完整性校验值仅仅是基于扩展报文头生成的。在同时对扩展报文头和IPv6头进行完整性校验的场景中,扩展报文头中携带的完整性校验值是基于扩展报文头和IPv6头生成的。
基于上述场景,还可以对扩展报文头的类型字段进行扩展,扩展后的类型字段的值为第一值时,指示完整性校验值用于校验扩展报文头和第一报文的IPv6头的完整性,扩展报文头的类型字段为第二值时,指示完整性校验值用于校验扩展报文头的完整性。
图12是本申请实施例提供的另一种第一报文的格式示意图。如图12所示,第一报文包括IPv6头,扩展报文头以及内层IP头和载荷。其中,IPv6头中的字段和内层IP头的解释可以参考前述相关内容,在此不再赘述。
如图12所示,扩展报文头包括头扩展长度(Hdr Ext Len)字段、类型(Type)字段、预留(Reserved)字段、SPI字段、序列号字段、第一加密部分(图12中加粗字体)、ICV字段。其中,第一加密部分包括加密后的SRH以及加密后的填充数据字段以及填充长度字段。
图12中SRH中各个字段的相关解释可以参考图6所示的实施例,在此不再赘述。
其中,扩展报文头中第一行的类型字段包括8个比特位,第一个比特位上的数值为0时,表明后续仅仅对扩展报文头进行完整性校验即可。该比特位上的值为1时,表明后续对扩展报文头和IPv6头同时进行完整性校验。
此外,在SRv6协议中IPv6头中的下一报头的值指示下一个报文头为SRH,但是如图12所示,本申请实施例中IPv6头中的下一报头的值指示下一个报文头为扩展报文头。
SPI字段和序列号字段分别用于携带前述SRH ESP头中的SPI和序列号。填充数据字段和填充长度字段分别用于携带前述SRH ESP尾中的填充数据和填充长度。完整性校验值字段用于携带前述基于ESP技术得到的ICV。
如图12所示,具体加密时,将SRH字段、填充数据字段和填充长度字段一起使用加密密钥,通过加密算法加密,以使图12中SRH整体由明文变为暗文。
另外,如图12所示,具体加密时,将扩展报文头中的下一报头字段也一起加密了。可选地,也可以不对该字段加密。相应地,该下一报头字段不在第一加密部分中。
图12中的扩展报文头沿用的是ESP头的基本格式,这种场景下,该扩展报文头还可以称为SRH ESP头。需要说明的是,图12是本申请实施例提供的扩展报文头的一种可选的实现方式,本申请实施例并不限定扩展报文头的具体格式。
步骤(3):第一边缘节点将第一加密部分封装在业务报文的外层,然后继续封装IPv6头,以得到前述第一报文,然后发送第一报文。
第一边缘节点在对SRH加密之后,便可通过上述步骤(3)得到第一报文。如此得到的第一报文的SRH是在第一加密部分中,从而可以避免SID列表暴露在网络中。
示例地,在扩展了扩展报文头的情况下,第一边缘节点便可将包括第一加密部分的扩展报文头封装在业务报文的外层,然后在扩展报文头的外层继续封装IPv6头,以得到前述第一报文
此外,上述IPv6头中携带目的IP地址,IPv6头中的目的IP地址为SID列表中位于第一边缘节点的SID后的下一个SID所对应的IP地址。
此外,第一边缘节点在将加密后的SRH封装在业务报文的外层前,还可以将业务报文基于IPsec加密封装,以保证业务报文的安全性。
示例地,图13是本申请实施例提供的一种发送报文的流程示意图。如图13所示,第一边缘节点收到LAN侧的业务报文,根据业务报文的目的IP查找路由,确定业务报文目的地第二边缘节点的隧道接口IP。第一边缘节点根据本机配置的或由网络控制器集中下发的SR 路径调度策略,确定待封装在业务报文外侧的SRH的SID列表。第一边缘节点对业务报文进行IPsec加密封装,封装内容包括业务报文中内层IP头和载荷。第一边缘节点对IPsec加密封装后的报文增加扩展报文头,该扩展报文头中包括单独加密的SRH。第一边缘节点将扩展报文头封装在业务报文外层后,继续封装IPv6头,IPv6头中“下一个头”字段为扩展报文头的类型,得到第一报文。然后将第一报文从出接口转发到POP网络。
此外,对于图2所示的POP组网,第一边缘节点接收到企业分支的局域网(LAN)侧发送的业务报文时,该业务报文中也可以已经封装有SRH,此时对于第一边缘节点,第一边缘节点直接基于上述加密机制对SRH进行加密即可。
步骤1002:第二设备接收第一报文。
步骤1002的实现方式可以参考前述图6实施例中步骤602的实现方式,在此不再赘述。
步骤1003:第二设备解密第一加密部分,得到SRH。
在SRv6网络中,中间节点在接收到报文时,需要根据SRH来确定当前的操作。因此,第二设备在接收到第一报文时,需要先解密第一加密部分,以得到不包括暗文信息的SRH。
在一些实施例中,在步骤1001中第一报文包括扩展报文头,且第一加密部分携带在扩展报文头中的情况下,第二设备先获取扩展报文头,然后从扩展报文头中获取第一加密部分,然后解密第一加密部分,得到SRH。
示例地,在步骤1001中IPv6头的下一报头字段指示下一个报文头为扩展报文头的情况下,基于IPv6头中的下一报头字段的位置,便可获取到扩展报文头。
在一些实施例中,在步骤1001中的扩展报文头携带加密元数据的情况下,由于加密元数据没有被加密,因此第二设备解密第一加密部分的实现过程为:第二设备从扩展报文头中获取加密元数据,基于加密元数据解密加密字段。具体地,基于加密元数据确定加密算法和解密密钥,基于加密算法和解密密钥来解密加密字段。具体实现方式可以参考图6实施例中步骤603。
在一些实施例中,在步骤1001中的扩展报文头还携带填充数据的情况下,第二设备解密第一加密部分的实现过程为:从解密后的字段中删除填充数据,得到SRH。
示例地,在扩展报文头包括填充数据字段和填充长度字段的情况下,第二设备从解密后的字段中删除和填充数据长度相同长度的填充数据,从而得到未被加密的SRH。
在一些实施例中,在步骤1001中的扩展报文头携带完整性校验值的情况下,第二设备在解密第一加密部分之前先基于完整性校验值校验扩展报文头的完整性,在扩展报文头完整性没有被破坏的情况下,执行解密第一加密部分的操作。具体校验方式可以参考图6实施例中的步骤603。
示例地,在步骤1001扩展报文头的类型字段扩展了的情况下,校验扩展报文头的完整性的实现过程为:在扩展报文头的类型字段为第一值的情况下,基于完整性校验值对扩展报文头和第一报文的IPv6头进行完整性校验;在扩展报文头的类型字段为第二值的情况下,基于完整性校验值对扩展报文头进行完整性校验。
步骤1004:第二设备基于SRH对第一报文进行处理。
在一些实施例中,第二设备在得到SRH之后,便可从SID列表中确定最后一个SID,该最后一个SID即为该载荷的目的地的IPv6地址。第二设备将该IPv6地址和自身的IPv6地址进行比对,如果两者一致,则确定自身是载荷的目的地,如果两者不一致,则表明自身不是 载荷的目的地。
在第二设备基于SRH确定自身不是载荷的目的地的情况下,表明第二设备还是SID列表所指示的转发路径上的中间节点,因此第二设备需要对SRH中的SL字段进行修改,示例地,将SL值减去1,然后基于修改后的SRH生成第二报文,第二报文包括修改后的SRH和载荷。具体地,在第一报文的内层报文(也即前述业务报文包括内层IP头和载荷)封装修改后的SRH,并继续封装IPv6头,该IPv6头携带的目的地址为SID列表中位于第二设备的SID后的下一个SID所对应的IPv6地址,以得到第二报文,进而发送第二报文。也即是,第二设备基于载荷的下一跳修改SRH,基于修改后的SRH生成第二报文,第二报文包括修改后的SRH和载荷。
可选地,在本申请实施例中,第二设备还可以先将修改后的SRH进行加密,然后在第一报文的内层报文头封装加密的修改后的SRH,并继续封装IPv6头,以得到第二报文,进而发送第二报文。此时,第二报文中的SRH包括第一加密部分。其中,第二设备加密修改后的SRH可以步骤1001,在此不再赘述。也即是,第二报文的SRH中的第一加密部分的相关解释可以参考步骤1001,在此不再赘述。
示例地,在第二设备确定自身和报文的下一跳之间有专线的情况下,不对修改后的SRH加密,在自身和报文的下一跳之间没有专线的情况下,对修改后的SRH加密。需要说明的是,在本申请实施例中,第二设备也可以不区分情况直接对修改后的SRH加密。
第二设备发送第二报文后,后续节点的处理过程和第二设备对第一报文的处理过程相同,在此不再赘述。
此外,在步骤604中,如果第二设备确定出自身是载荷的目的地。此时,第二设备将第一报文中的SRH弹出,得到业务报文,然后根据业务报文中携带的目的IP地址继续后续处理过程。
下面仍然以图13为例,对上述步骤1002至步骤1004进行举例说明。
如图13所示,任一POP节点从互联网WAN接口接收到加密后的报文(也即前述第一报文)后,解析IPv6头,并从IPv6头中“下一报头”字段确定下一个报文头为SRH ESP头。该POP节点结合SRH ESP头中的信息对SRH进行校验和解密,解析SRH中的明文信息。POP节点从解密后的SRH中获取到SID列表,确定下一跳,该下一跳为POP节点或第二边缘节点,并修改SRH中SID指针信息(SL)。该POP节点对SRH进行头加密,将加密后的SRH封装在SRH ESP头中。POP节点在SRH ESP头外继续封装IPv6头,源IP不变,目的IP为下一跳的IP,并向下一跳转发。
需要说明的是,若该POP节点的下一跳为目的Edge节点(也即第二边缘节点),可选择直接弹出SRH头,然后转发报文。该POP节点按需选择是否使能SRH头加密,如果该POP节点和下一跳的POP节点间为专线则可不加密。
第二边缘节点从WAN接口接收到加密报文时,解析IPv6头,并从IPv6头中“下一报头”字段确定下一个报文头为SRH ESP头。结合SRH ESP头对SRH进行校验和解密,解析SRH中的明文信息。第二边缘节点从解密后的SRH中获取到SID列表,确定自身为目的节点,从而对报文进行内层IPsec解密。第二边缘节点完成IPsec解密,获取到业务报文的目的IP和载荷。第二边缘节点根据业务报文的目的IP查路由表转发给LAN侧内网设备。
图10所示的实施例提供了一种SRH头加密机制。该SRH头加密机制对整个SRH进行 加密。其中,边缘节点与POP节点间基于互联网,建立该SRH头加密机制。POP节点与POP节点间如采用互联网传输,也建立该SRH头加密机制;如采用专线网络传输,可不涉及SRH头加密。基于该加密机制,在POP组网中传输的SRv6报文,SRv6报文的SRH是被加密的,保护SRH头中SID信息不被泄露。并且实现了POP组网端到端加密,中间POP节点不解密载荷,从而使得中间POP节点转发效率较高。此外,还提供了POP节点在互联网上对收到的报文的安全校验机制。
图14是本申请实施例提供的一种网络设备的结构示意图。如图14所示,该网络设备1400包括处理模块1401和收发模块1402.
其中,处理模块1401,用于加密报文中的分段路由头SRH,该报文还包括载荷,加密后的SRH包括加密字段和不加密字段,加密字段至少包括加密后的分段标识SID列表,SID列表指示该报文的传输路径。具体实现方式可以参考图6实施例中的步骤601。
收发模块1402,用于发送该报文。具体实现方式可以参考图6实施例中的步骤601。
可选地,不加密字段包括指示SID列表中最后一个SID的索引的字段。
可选地,不加密字段还包括路由类型字段。
可选地,不加密字段还包括预留标识字段,预留标识字段的取值指示SID列表已经被加密。
可选地,SRH包括扩展类型长度值TLV,扩展TLV携带加密元数据,加密字段是基于加密元数据加密的,加密元数据没有被加密。
可选地,不加密字段还包括头扩展长度字段。
可选地,扩展TLV包括加密标识字段,加密标识字段的取值指示SRH中加密字段和不加密字段的位置。
可选地,加密字段还包括加密后的填充数据,扩展TLV还携带加密后的填充数据。
可选地,扩展TLV还携带完整性校验值,完整性校验值至少用于校验SRH中位于SID列表前的字段以及SID列表的完整性。
综上,本申请实施例提供了一种SRH头加密机制。该SRH头加密机制至少对SID列表进行加密。其中,边缘节点与POP节点间基于互联网,建立该SRH头加密机制。POP节点与POP节点间如采用互联网传输,也建立该SRH头加密机制;如采用专线网络传输,可不涉及SRH头加密。基于该加密机制,在POP组网中传输的SRv6报文,SRv6报文的SRH中的SID列表是被加密的,保护SRH头中SID信息不被泄露。并且实现了POP组网端到端加密,中间POP节点不解密载荷,从而使得中间POP节点转发效率较高。此外,还提供了POP节点在互联网上对收到的报文的安全校验机制。
在另一些实施例中,图14所示的网络设备中的处理模块和收发模块可选地具有如下功能。
其中,处理模块1401,用于加密报文,加密后的该报文包括加密部分,该报文的分段路由头SRH在该加密部分之中,该报文的载荷不在所述加密部分中。具体实现方式可以参考图10实施例中步骤1001。
收发模块1402,用于发送该报文。具体实现方式可以参考图10实施例中步骤1001。
可选地,该报文包括扩展报文头,该加密部分携带在扩展报文头中。
可选地,扩展报文头还携带加密元数据,该加密部分是基于加密元数据加密的,加密元数据不在该加密部分中。
可选地,扩展报文头还携带完整性校验值,完整性校验值至少用于校验扩展报文头的完整性。
可选地,扩展报文头的类型字段的取值为第一值时,完整性校验值用于校验扩展报文头和第一报文的IPv6头的完整性,扩展报文头的类型字段的取值为第二值时,完整性校验值用于校验扩展报文头的完整性。
可选地,该报文的IPv6头位于扩展报文头的外层,IPv6头中的下一报头字段指示下一个报文头为扩展报文头。
可选地,该加密部分还包括加密后的填充数据。
综上,本申请实施例提供了一种SRH头加密机制。该SRH头加密机制对整个SRH进行加密。其中,边缘节点与POP节点间基于互联网,建立该SRH头加密机制。POP节点与POP节点间如采用互联网传输,也建立该SRH头加密机制;如采用专线网络传输,可不涉及SRH头加密。基于该加密机制,在POP组网中传输的SRv6报文,SRv6报文的SRH是被加密的,保护SRH头中SID信息不被泄露。并且实现了POP组网端到端加密,中间POP节点不解密载荷,从而使得中间POP节点转发效率较高。此外,还提供了POP节点在互联网上对收到的报文的安全校验机制。
在另一些实施例中,图14所示的网络设备中的处理模块和收发模块可选地具有如下功能。
其中,收发模块1402,用于接收第一报文,第一报文包括分段路由头SRH和载荷,SRH包括加密字段和不加密字段,加密字段至少包括加密后的分段标识SID列表,SID列表指示将第一报文的传输路径。具体实现方式参考图6实施例中的步骤602。
处理模块1401,用于解密加密字段,得到不包括加密字段的SRH。具体实现方式参考图6实施例中的步骤603。
处理模块1401,还用于基于不包括加密字段的SRH对第一报文进行处理。具体实现方式参考图6实施例中的步骤604。
可选地,处理模块用于:在基于不包括加密字段的SRH确定自身不是载荷的目的地的情况下,基于载荷的下一跳修改不包括加密字段的SRH,基于修改后的SRH生成第二报文,第二报文包括修改后的SRH和载荷;
收发模块,还用于发送第二报文。
可选地,处理模块还用于:
加密修改后的SRH,相应地,第二报文中的SRH包括加密字段和不加密字段。
可选地,不加密字段包括指示SID列表中最后一个SID的索引的字段;
处理模块用于:
基于SRH中指示SID列表中最后一个SID的索引的字段,确定SID列表的终止位置;
第一报文的IPv6头确定SID列表的起始位置;
基于SID列表的起始位置和终止位置,确定获取加密后的SID列表,以解密加密后的SID列表。
可选地,不加密字段包括指示SID列表中最后一个SID的索引的字段和路由类型字段;
处理模块用于:
基于SRH中指示SID列表中最后一个SID的索引的字段,确定SID列表的终止位置;
基于路由类型字段确定SID列表的起始位置;
基于SID列表的起始位置和终止位置,确定获取加密后的SID列表,以解密加密后的SID列表。
可选地,不加密字段还包括预留标识字段;
处理模块用于:
在预留标识字段的取值指示SID列表已经被加密的情况下,执行解密加密字段的操作。
可选地,SRH包括扩展类型长度值TLV,扩展TLV携带加密元数据,加密元数据没有被加密;
处理模块用于:
从扩展TLV中获取加密元数据;
基于加密元数据解密加密字段。
可选地,不加密字段包括指示SID列表中最后一个SID的索引的字段和头扩展长度字段;
处理模块还用于:
基于头扩展长度字段和指示SID列表中最后一个SID的索引的字段,获取扩展TLV。
可选地,扩展TLV的类型字段的取值指示SRH中加密字段和不加密字段的位置;
处理模块还用于:
基于扩展TLV的类型字段确定加密字段在SRH中所处的位置。
可选地,加密字段还包括加密后的填充数据,扩展TLV还携带加密后的填充数据;
处理模块用于;
从解密后的字段中删除填充数据,得到不包括加密字段的SRH。
可选地,扩展TLV还携带完整性校验值;
处理模块还用于:
基于完整性校验值校验SRH中位于SID列表前的字段以及SID列表的完整性;
在SRH中位于SID列表前的字段以及SID列表的完整性没有被破坏的情况下,执行解密加密字段的操作。
综上,本申请实施例提供了一种SRH头加密机制。该SRH头加密机制至少对SID列表进行加密。其中,边缘节点与POP节点间基于互联网,建立该SRH头加密机制。POP节点与POP节点间如采用互联网传输,也建立该SRH头加密机制;如采用专线网络传输,可不涉及SRH头加密。基于该加密机制,在POP组网中传输的SRv6报文,SRv6报文的SRH中的SID列表是被加密的,保护SRH头中SID信息不被泄露。并且实现了POP组网端到端加密,中间POP节点不解密载荷,从而使得中间POP节点转发效率较高。此外,还提供了POP节点在互联网上对收到的报文的安全校验机制。
在另一些实施例中,图14所示的网络设备中的处理模块和收发模块可选地具有如下功能。
收发模块1402,用于接收第一报文,第一报文包括加密部分,第一报文的分段路由头SRH在该加密部分之中,第一报文的载荷不在该加密部分中。具体实现方式可以参考图10实施例中步骤1002。
处理模块1401,用于解密该加密部分,得到SRH。具体实现方式可以参考图10实施例中步骤1003。
处理模块1401,还用于基于SRH对第一报文进行处理。具体实现方式可以参考图10实施例中步骤1004。
可选地,处理模块用于:
在基于SRH确定自身不是载荷的目的地的情况下,基于载荷的下一跳修改SRH,基于修改后的SRH生成第二报文,第二报文包括修改后的SRH和载荷。
可选地,基处理模块用于:
加密修改后的SRH,相应地,第二报文包括加密部分,加密后的修改后的SRH在该加密部分中。
可选地,第一报文包括扩展报文头,加密部分携带在扩展报文头中;
处理模块还用于:
从扩展报文头中获取加密部分。
可选地,扩展报文还携带加密元数据;
处理模块用于:
基于加密元数据解密加密部分。
可选地,扩展报文头还携带完整性校验值;
处理模块用于:
基于完整性校验值校验扩展报文头的完整性;
在扩展报文头的完整性没有被破坏的情况下,执行解密加密部分的操作。
可选地,处理模块用于:
在扩展报文头的类型字段的值为第一值的情况下,基于完整性校验值对扩展报文头和第一报文的IPv6头进行完整性校验;
在扩展报文头的类型字段的值为第二值的情况下,基于完整性校验值对扩展报文头进行完整性校验。
可选地,第一报文的IPv6头位于扩展报文头的外层,IPv6头中的下一头字段指示下一个报文头为扩展报文头;
处理模块用于:
基于IPv6头中的下一报头字段获取扩展报文头。
可选地,该加密部分还包括加密后的填充数据;
处理模块用于:
从解密后的字段中删除填充数据,得到SRH。
综上,本申请实施例提供了一种SRH头加密机制。该SRH头加密机制对整个SRH进行加密。其中,边缘节点与POP节点间基于互联网,建立该SRH头加密机制。POP节点与POP节点间如采用互联网传输,也建立该SRH头加密机制;如采用专线网络传输,可不涉及SRH头加密。基于该加密机制,在POP组网中传输的SRv6报文,SRv6报文的SRH是被加密的,保护SRH头中SID信息不被泄露。并且实现了POP组网端到端加密,中间POP节点不解密载荷,从而使得中间POP节点转发效率较高。此外,还提供了POP节点在互联网上对收到的报文的安全校验机制。
需要说明的是:上述实施例提供的网络设备在发送报文时,仅以上述各功能模块的划分进行举例说明,实际应用中,可以根据需要而将上述功能分配由不同的功能模块完成,即将设备的内部结构划分成不同的功能模块,以完成以上描述的全部或者部分功能。另外,上述实施例提供的网络设备与发送报文的方法实施例属于同一构思,其具体实现过程详见方法实施例,这里不再赘述。
在上述实施例中,可以全部或部分地通过软件、硬件、固件或者其任意结合来实现。当使用软件实现时,可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机指令时,全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中,或者从一个计算机可读存储介质向另一个计算机可读存储介质传输,例如,所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如:同轴电缆、光纤、数据用户线(digital subscriber line,DSL))或无线(例如:红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质(例如:软盘、硬盘、磁带)、光介质(例如:数字通用光盘(digital versatile disc,DVD))、或者半导体介质(例如:固态硬盘(solid state disk,SSD))等。
本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成,也可以通过程序来指令相关的硬件完成,所述的程序可以存储于一种计算机可读存储介质中,上述提到的存储介质可以是只读存储器,磁盘或光盘等。
以上所述为本申请提供的实施例,并不用以限制本申请实施例,凡在本申请实施例的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本申请实施例的保护范围之内。

Claims (53)

  1. 一种发送报文的方法,其特征在于,所述方法包括:
    网络设备发送报文,所述报文包括分段路由头SRH和载荷,所述SRH包括加密字段和不加密字段,所述加密字段至少包括加密后的分段标识SID列表,所述SID列表指示所述报文的传输路径。
  2. 如权利要求1所述的方法,其特征在于,所述不加密字段包括指示所述SID列表中最后一个SID的索引的字段。
  3. 如权利要求2所述的方法,其特征在于,所述不加密字段还包括路由类型字段。
  4. 如权利要求2或3所述的方法,其特征在于,所述不加密字段还包括预留标识字段,所述预留标识字段的取值指示所述SID列表已经被加密。
  5. 如权利要求1至4任一所述的方法,其特征在于,所述SRH包括扩展类型长度值TLV,所述扩展TLV携带加密元数据,所述加密字段是基于所述加密元数据加密的,所述加密元数据没有被加密。
  6. 如权利要求5所述的方法,其特征在于,所述不加密字段还包括头扩展长度字段。
  7. 如权利要求5或6所述的方法,其特征在于,所述扩展TLV包括加密标识字段,所述加密标识字段的取值指示所述SRH中所述加密字段和所述不加密字段的位置。
  8. 如权利要求5至7任一所述的方法,其特征在于,所述加密字段还包括加密后的填充数据,所述扩展TLV还携带所述加密后的填充数据。
  9. 如权利要求5至8任一所述的方法,其特征在于,所述扩展TLV还携带完整性校验值,所述完整性校验值至少用于校验所述SRH中位于SID列表前的字段以及所述SID列表的完整性。
  10. 一种发送报文的方法,其特征在于,所述方法包括:
    网络设备发送报文,所述报文包括加密部分,所述报文的分段路由头SRH在所述加密部分之中,所述报文的载荷不在所述加密部分中。
  11. 如权利要求10所述的方法,其特征在于,所述报文包括扩展报文头,所述加密部分携带在所述扩展报文头中。
  12. 如权利要求11所述的方法,其特征在于,所述扩展报文头还携带加密元数据,所述加密部分是基于所述加密元数据加密的,所述加密元数据不在所述加密部分中。
  13. 如权利要求11或12所述的方法,其特征在于,所述扩展报文头还携带完整性校验值,所述完整性校验值至少用于校验所述扩展报文头的完整性。
  14. 如权利要求13所述的方法,其特征在于,所述扩展报文头的类型字段的取值为第一值时,所述完整性校验值用于校验所述扩展报文头和所述报文的IPv6头的完整性,所述扩展报文头的类型字段的取值为第二值时,所述完整性校验值用于校验所述扩展报文头的完整性。
  15. 如权利要求11至14任一所述的方法,其特征在于,所述报文的IPv6头位于所述扩展报文头的外层,所述IPv6头中的下一报头字段指示下一个报文头为所述扩展报文头。
  16. 如权利要求10至15任一所述的方法,其特征在于,所述加密部分还包括加密后的填充数据。
  17. 一种发送报文的方法,其特征在于,所述方法包括:
    网络设备接收第一报文,所述第一报文包括分段路由头SRH和载荷,所述SRH包括加密字段和不加密字段,所述加密字段至少包括加密后的分段标识SID列表,所述SID列表指示将所述第一报文的传输路径;
    所述网络设备解密所述加密字段,得到不包括加密字段的SRH;
    所述网络设备基于所述不包括加密字段的SRH对所述第一报文进行处理。
  18. 如权利要求17所述的方法,其特征在于,所述网络设备基于所述不包括加密字段的SRH对所述第一报文进行处理,包括:
    在所述网络设备基于所述不包括加密字段的SRH确定自身不是所述载荷的目的地的情况下,基于所述载荷的下一跳修改所述不包括加密字段的SRH,基于修改后的SRH生成第二报文,所述第二报文包括所述修改后的SRH和所述载荷;
    所述网络设备发送所述第二报文。
  19. 如权利要求18所述的方法,其特征在于,所述基于修改后的SRH生成第二报文之前,所述方法还包括:
    加密修改后的SRH,相应地,所述第二报文中的SRH包括所述加密字段和所述不加密字段。
  20. 如权利要求17至19任一所述的方法,其特征在于,所述不加密字段包括指示所述SID列表中最后一个SID的索引的字段;
    所述解密所述加密字段,包括:
    所述网络设备基于所述SRH中指示所述SID列表中最后一个SID的索引的字段,确定 所述SID列表的终止位置;
    所述网络设备所述第一报文的IPv6头确定SID列表的起始位置;
    所述网络设备基于所述SID列表的起始位置和终止位置,确定获取加密后的SID列表,以解密所述加密后的SID列表。
  21. 如权利要求17-19任一所述的方法,其特征在于,所述不加密字段包括指示所述SID列表中最后一个SID的索引的字段和路由类型字段;
    所述解密所述加密字段,包括:
    所述网络设备基于所述SRH中指示所述SID列表中最后一个SID的索引的字段,确定所述SID列表的终止位置;
    所述网络设备基于所述路由类型字段确定SID列表的起始位置;
    所述网络设备基于所述SID列表的起始位置和终止位置,确定获取加密后的SID列表,以解密所述加密后的SID列表。
  22. 如权利要求17至21任一所述的方法,其特征在于,所述不加密字段还包括预留标识字段;
    所述网络设备解密所述加密字段,包括:
    在所述预留标识字段的取值指示所述SID列表已经被加密的情况下,执行解密所述加密字段的操作。
  23. 如权利要求17至22任一所述的方法,其特征在于,所述SRH包括扩展类型长度值TLV,所述扩展TLV携带所述加密信息,所述加密信息没有被加密;
    所述网络设备解密所述加密字段,包括:
    所述网络设备从所述扩展TLV中获取所述加密信息;
    所述网络设备基于所述加密信息解密所述加密字段。
  24. 如权利要求23所述的方法,其特征在于,所述不加密字段包括指示所述SID列表中最后一个SID的索引的字段和头扩展长度字段;
    所述方法还包括:
    所述网络设备基于头扩展长度字段和指示所述SID列表中最后一个SID的索引的字段,获取所述扩展TLV。
  25. 如权利要求23或24所述的方法,其特征在于,所述扩展TLV的类型字段的取值指示所述SRH中所述加密字段和所述不加密字段的位置;
    所述网络设备解密所述加密字段之前,所述方法还包括:
    所述网络设备基于所述扩展TLV的类型字段确定所述加密字段在所述SRH中所处的位置。
  26. 如权利要求23至25任一所述的方法,其特征在于,所述加密字段还包括加密后的填 充数据,所述扩展TLV还携带所述加密后的填充数据;
    所述网络设备解密所述加密字段,包括;
    从解密后的字段中删除所述填充数据,得到所述不包括加密字段的SRH。
  27. 如权利要求23至26任一所述的方法,其特征在于,所述扩展TLV还携带完整性校验值;
    所述方法还包括:
    基于所述完整性校验值校验所述SRH中位于SID列表前的字段以及所述SID列表的完整性;
    在所述SRH中位于SID列表前的字段以及所述SID列表的完整性没有被破坏的情况下,执行解密所述加密字段的操作。
  28. 一种发送报文的方法,其特征在于,所述方法包括:
    网络设备接收第一报文,所述第一报文包括加密部分,所述第一报文的分段路由头SRH在所述加密部分之中,所述第一报文的载荷不在所述加密部分中;
    所述网络设备解密所述加密部分,得到所述SRH;
    所述网络设备基于所述SRH对所述第一报文进行处理。
  29. 如权利要求28所述的方法,其特征在于,所述网络设备基于所述SRH对所述第一报文进行处理,包括:
    在所述网络设备基于所述SRH确定自身不是所述载荷的目的地的情况下,基于所述载荷的下一跳修改所述SRH,基于修改后的SRH生成第二报文,所述第二报文包括所述修改后的SRH和所述载荷。
  30. 如权利要求29所述的方法,其特征在于,所述基于修改后的SRH生成第二报文之前,所述方法还包括:
    加密修改后的SRH,相应地,所述第二报文包括所述加密部分,加密后的修改后的SRH在所述加密部分中。
  31. 如权利要求28至30任一所述的方法,其特征在于,所述第一报文包括扩展报文头,所述加密部分携带在所述扩展报文头中;
    所述方法还包括:
    所述网络设备从所述扩展报文头中获取所述加密部分。
  32. 如权利要求31所述的方法,其特征在于,所述扩展报文还携带加密元数据;
    所述网络设备解密所述加密部分,包括:
    所述网络设备基于加密元数据解密所述加密部分。
  33. 如权利要求31或32所述的方法,其特征在于,所述扩展报文头还携带完整性校验值;
    所述网络设备解密所述加密部分,包括:
    基于所述完整性校验值校验所述扩展报文头的完整性;
    在所述扩展报文头的完整性没有被破坏的情况下,执行解密所述加密部分的操作。
  34. 如权利要求33所述的方法,其特征在于,所述基于所述完整性校验值校验所述扩展报文头的完整性,包括:
    在所述扩展报文头的类型字段的值为第一值的情况下,基于所述完整性校验值对所述扩展报文头和所述第一报文的IPv6头进行完整性校验;
    在所述扩展报文头的类型字段的值为第二值的情况下,基于所述完整性校验值对所述扩展报文头进行完整性校验。
  35. 如权利要求31至34任一所述的方法,其特征在于,所述第一报文的IPv6头位于所述扩展报文头的外层,所述IPv6头中的下一头字段指示下一个报文头为所述扩展报文头;
    所述方法还包括:
    所述网络设备基于所述IPv6头中的下一报头字段获取所述扩展报文头。
  36. 如权利要求28至35任一所述的方法,其特征在于,所述加密部分还包括加密后的填充数据;
    所述网络设备解密所述加密部分,包括:
    从解密后的字段中删除填充数据,得到所述SRH。
  37. 一种网络设备,其特征在于,所述网络设备包括:
    处理模块,用于加密报文中的分段路由头SRH,所述报文还包括载荷,加密后的所述SRH包括加密字段和不加密字段,所述加密字段至少包括加密后的分段标识SID列表,所述SID列表指示所述报文的传输路径;
    收发模块,用于发送所述报文。
  38. 如权利要求37所述的网络设备,其特征在于,所述不加密字段包括指示所述SID列表中最后一个SID的索引的字段。
  39. 如权利要求38所述的网络设备,其特征在于,所述不加密字段还包括路由类型字段。
  40. 如权利要求38或39所述的网络设备,其特征在于,所述不加密字段还包括预留标识字段,所述预留标识字段的取值指示所述SID列表已经被加密。
  41. 一种网络设备,其特征在于,所述网络设备包括:
    处理模块,用于加密报文,加密后的所述报文包括加密部分,所述报文的分段路由头SRH在所述加密部分之中,所述报文的载荷不在所述加密部分中;
    收发模块,用于发送所述报文。
  42. 如权利要求41所述的网络设备,其特征在于,所述报文包括扩展报文头,所述加密部分携带在所述扩展报文头中。
  43. 如权利要求42所述的网络设备,其特征在于,所述扩展报文头还携带加密元数据,所述加密部分是基于所述加密元数据加密的,所述加密元数据不在所述加密部分中。
  44. 一种网络设备,其特征在于,所述网络设备包括:
    收发模块,用于接收第一报文,所述第一报文包括分段路由头SRH和载荷,所述SRH包括加密字段和不加密字段,所述加密字段至少包括加密后的分段标识SID列表,所述SID列表指示将所述第一报文的传输路径;
    处理模块,用于解密所述加密字段,得到不包括加密字段的SRH;
    所述处理模块,还用于基于所述不包括加密字段的SRH对所述第一报文进行处理。
  45. 如权利要求44所述的网络设备,其特征在于,
    所述处理模块用于:在基于所述不包括加密字段的SRH确定自身不是所述载荷的目的地的情况下,基于所述载荷的下一跳修改所述不包括加密字段的SRH,基于修改后的SRH生成第二报文,所述第二报文包括所述修改后的SRH和所述载荷;
    所述收发模块,还用于发送所述第二报文。
  46. 如权利要求45所述的网络设备,其特征在于,所述所述处理模块还用于:
    加密修改后的SRH,相应地,所述第二报文中的SRH包括所述加密字段和所述不加密字段。
  47. 如权利要求44至46任一所述的网络设备,其特征在于,所述不加密字段包括指示所述SID列表中最后一个SID的索引的字段;
    所述处理模块用于:
    基于所述SRH中指示所述SID列表中最后一个SID的索引的字段,确定所述SID列表的终止位置;
    所述第一报文的IPv6头确定SID列表的起始位置;
    基于所述SID列表的起始位置和终止位置,确定获取加密后的SID列表,以解密所述加密后的SID列表。
  48. 一种网络设备,其特征在于,所述网络设备包括:
    收发模块,用于接收第一报文,所述第一报文包括加密部分,所述第一报文的分段路由头SRH在所述加密部分之中,所述第一报文的载荷不在所述加密部分中;
    处理模块,用于解密所述加密部分,得到所述SRH;
    所述处理模块,还用于基于所述SRH对所述第一报文进行处理。
  49. 如权利要求48所述的网络设备,其特征在于,所述处理模块用于:
    在基于所述SRH确定自身不是所述载荷的目的地的情况下,基于所述载荷的下一跳修改所述SRH,基于修改后的SRH生成第二报文,所述第二报文包括所述修改后的SRH和所述载荷。
  50. 如权利要求49所述的网络设备,其特征在于,所述基处理模块用于:
    加密修改后的SRH,相应地,所述第二报文包括所述加密部分,加密后的修改后的SRH在所述加密部分中。
  51. 一种网络设备,其特征在于,所述网络设备包括:
    存储器,存储有指令;
    与所述存储器相连的处理器,当所述指令在所述处理器中运行时,使得所述网络设备执行权利要求1-9或权利要求10-16或权利要求17-27或权利要求28-36中任一项所述的方法。
  52. 一种计算机可读存储介质,其特征在于,所述计算机可读存储介质中存储有指令,当其在处理器上运行时,实现权利要求1-9或权利要求10-16或权利要求17-27或权利要求28-36中任一项所述的方法。
  53. 一种计算机程序产品,其特征在于,包括程序,当所述程序在处理器上运行时,实现权利要求1-9或权利要求10-16或权利要求17-27或权利要求28-36中任一项所述的方法。
PCT/CN2022/114821 2021-08-31 2022-08-25 发送报文的方法、网络设备、存储介质及程序产品 WO2023030160A1 (zh)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
CN202111013733.5 2021-08-31
CN202111013733 2021-08-31
CN202111295472.0 2021-11-03
CN202111295472.0A CN115941227A (zh) 2021-08-31 2021-11-03 发送报文的方法、网络设备、存储介质及程序产品

Publications (1)

Publication Number Publication Date
WO2023030160A1 true WO2023030160A1 (zh) 2023-03-09

Family

ID=85411920

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/114821 WO2023030160A1 (zh) 2021-08-31 2022-08-25 发送报文的方法、网络设备、存储介质及程序产品

Country Status (1)

Country Link
WO (1) WO2023030160A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116527405A (zh) * 2023-06-30 2023-08-01 新华三技术有限公司 一种srv6报文加密传输方法、装置及电子设备

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190394211A1 (en) * 2018-06-26 2019-12-26 Cisco Technology, Inc. Providing Processing and Network Efficiencies in Protecting Internet Protocol Version 6 Segment Routing Packets and Functions Using Security Segment Identifiers
CN111010274A (zh) * 2019-12-30 2020-04-14 烽火通信科技股份有限公司 一种安全低开销的SRv6实现方法
CN112615878A (zh) * 2020-12-25 2021-04-06 网络通信与安全紫金山实验室 基于加解密的SRv6路径认证方法、系统、设备及介质
CN113141339A (zh) * 2020-01-20 2021-07-20 华为技术有限公司 一种sr报文传输方法、装置及系统
WO2021148021A1 (zh) * 2020-01-22 2021-07-29 华为技术有限公司 一种报文处理方法、装置及系统

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190394211A1 (en) * 2018-06-26 2019-12-26 Cisco Technology, Inc. Providing Processing and Network Efficiencies in Protecting Internet Protocol Version 6 Segment Routing Packets and Functions Using Security Segment Identifiers
CN111010274A (zh) * 2019-12-30 2020-04-14 烽火通信科技股份有限公司 一种安全低开销的SRv6实现方法
CN113141339A (zh) * 2020-01-20 2021-07-20 华为技术有限公司 一种sr报文传输方法、装置及系统
WO2021148021A1 (zh) * 2020-01-22 2021-07-29 华为技术有限公司 一种报文处理方法、装置及系统
CN112615878A (zh) * 2020-12-25 2021-04-06 网络通信与安全紫金山实验室 基于加解密的SRv6路径认证方法、系统、设备及介质

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116527405A (zh) * 2023-06-30 2023-08-01 新华三技术有限公司 一种srv6报文加密传输方法、装置及电子设备
CN116527405B (zh) * 2023-06-30 2023-09-05 新华三技术有限公司 一种srv6报文加密传输方法、装置及电子设备

Similar Documents

Publication Publication Date Title
US10122574B2 (en) Methods and apparatus for a common control protocol for wired and wireless nodes
US8555056B2 (en) Method and system for including security information with a packet
US9369550B2 (en) Protocol for layer two multiple network links tunnelling
CN103188351B (zh) IPv6环境下IPSec VPN通信业务处理方法与系统
CN110650076B (zh) Vxlan的实现方法,网络设备和通信系统
US10044841B2 (en) Methods and systems for creating protocol header for embedded layer two packets
US11418434B2 (en) Securing MPLS network traffic
US20230102984A1 (en) METHOD AND APPARATUS FOR VERIFYING SRv6 PACKET
WO2020063528A1 (zh) 数据中心中虚拟机之间的通信方法、装置和系统
CN113852552B (zh) 一种网络通讯方法、系统与存储介质
US11088992B2 (en) Context specific keys
WO2023030160A1 (zh) 发送报文的方法、网络设备、存储介质及程序产品
CN116527405B (zh) 一种srv6报文加密传输方法、装置及电子设备
CN115941227A (zh) 发送报文的方法、网络设备、存储介质及程序产品
WO2020228130A1 (zh) 通信设备的网管服务器与网元的通信方法及系统
EP4175227A1 (en) Security for communication protocols
WO2023179174A1 (zh) 一种报文传输方法及相关设备
WO2023125993A1 (zh) 隧道加密,转发和解密方法以及装置
WO2023272498A1 (zh) 一种报文转发方法、装置、网络节点及存储介质
WO2024027419A1 (zh) 报文发送方法、装置及系统
CN115766063A (zh) 数据传输方法、装置、设备及介质
WO2021155918A1 (en) Sending data to a network function
CN117201639A (zh) 一种报文传输方法、网络虚拟化边缘设备及存储介质
CN117640555A (zh) Quic报文的传输方法及相关设备
CN117201075A (zh) 报文传输方法及装置、报文验证方法及装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22863298

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2022863298

Country of ref document: EP

Effective date: 20240313

NENP Non-entry into the national phase

Ref country code: DE