CN117560168A

CN117560168A - SRv6 message generation and transmission method based on zero trust

Info

Publication number: CN117560168A
Application number: CN202211161461.8A
Authority: CN
Inventors: 范端胜
Original assignee: Tols Tianxiang Net An Information Technology Co ltd
Current assignee: Tols Tianxiang Net An Information Technology Co ltd
Priority date: 2022-08-03
Filing date: 2022-09-22
Publication date: 2024-02-13

Abstract

The application discloses a SRv message generation and transmission method based on zero trust, wherein the generation method comprises the following steps: responding to a triggering instruction of the access request, and sending an access request for applying to access the target object to the controller; receiving a security policy identifier sent by a controller in response to the access request, wherein the security policy identifier corresponds to a security policy, and the security policy is the business access authority of a user to the target object; generating an Optional TLV field in the SRv message based on the security policy identification; based on the Optional TLV field, a SRv message corresponding to the access request is generated, so that SRv message contains a security policy identifier corresponding to the access request, so that the data plane can perform security management on the behavior of the access request based on SRv message.

Description

SRv6 message generation and transmission method based on zero trust

Technical Field

The disclosure relates generally to the technical field of network communication, and in particular relates to a SRv message generation and transmission method based on zero trust.

Background

Segmented routing (SegmentRouting, SR) is a tunneling technique based on source route forwarding mode. The SR data plane adopts two modes of multiprotocol label switching (Multi-ProtocolLabelSwitching, MPLS) or internet protocol version6 (IPv 6). SR based on the IPv6 scheme is called internet protocol version6segment routing (internet protocol version6SegmentRouting, IPv6 SR) or segment routing based on the IPv6data plane (SRv).

In the related art, security control is generally performed according to the network location accessed by the tag in the field of SRv, but such a control mode cannot achieve security control on user behavior.

Disclosure of Invention

In view of the foregoing drawbacks or shortcomings in the prior art, it is desirable to provide a method for generating and transmitting SRv messages based on zero trust, which improves the network security of SRv messages.

In a first aspect, an embodiment of the present application provides a method for generating a SRv6 message based on zero trust, which is applied to a client, and includes:

responding to a triggering instruction of the access request, and sending an access request for applying to access the target object to the controller;

receiving a security policy identifier sent by a controller in response to the access request, wherein the security policy identifier corresponds to a security policy, and the security policy is the business access authority of a user to the target object;

generating an Optional TLV field in the SRv message based on the security policy identification;

and generating a SRv message corresponding to the access request based on the Optional TLV field.

In some embodiments, the generating the Optional TLV field in the SRv message based on the security policy identification includes:

Generating a first Optional TLV field of the SRv6 message corresponding to the access request;

inserting the security policy identifier into the first Optional TLV field to obtain a second Optional TLV field;

generating the Optional TLV field based on the second Optional TLV field.

In some embodiments, the generating the Optional TLV field based on the second Optional TLV field includes:

encryption processing is carried out based on the second Optional TLV field, so that verification information is obtained;

and obtaining the Optional TLV field based on the second Optional TLV field and the verification information.

In some embodiments, the encrypting based on the second Optional TLV field to obtain the verification information includes:

acquiring a segmentation list, a time stamp and a preset one-time key of the SRv message;

and carrying out hash calculation on the segmentation list, the timestamp, the candidate Optional TLV field and the preset one-time key to obtain the verification information.

In some embodiments, further comprising:

responding to a triggering instruction of identity authentication, and sending the user identity information to the controller;

and receiving an authentication result of the controller responding to the user identity information, and monitoring a triggering instruction of the access request when the authentication result is passing.

In a second aspect, an embodiment of the present application provides a method for generating a SRv6 message based on zero trust, which is applied to a controller, and includes:

receiving an access request sent by a client, wherein the access request comprises a target object to which the controller applies for access;

determining a security policy corresponding to the user and a security policy identifier corresponding to the security policy based on the service access authority of the login user of the client to the target object;

and sending the security policy identification to the client.

In some embodiments, the security policy identification and the corresponding security policy are sent to each node device in the service function chain.

In a third aspect, an embodiment of the present application provides a method for transmitting a SRv6 message based on zero trust, which is applied to a node device, where the node device supports a security policy with zero trust, and the method includes:

receiving a SRv message corresponding to an access request sent by a previous node device, wherein the SRv message comprises a security policy identifier corresponding to the access request, the security policy identifier corresponds to a security policy, and the security policy is the service access authority of a user to the target object;

and verifying the security policy identification to be valid, and sending the SRv message to the next node equipment, wherein the security policy identification is valid, the security policy identification recorded in the SRv6 message is unmodified, and the security policy identification is in a valid state.

In some embodiments, the previous node device is a client when the current node is the first node in the traffic function chain.

In a fourth aspect, an embodiment of the present application provides a SRv6 message generating device based on zero trust, which is applied to a client, and includes:

the sending module is used for responding to a triggering instruction of the access request and sending the access request for applying to access the target object to the controller;

the receiving module is used for receiving a security policy identifier sent by the controller in response to the access request, wherein the security policy identifier corresponds to a security policy, and the security policy is the service access authority of a user to the target object;

the first generation module is used for generating an Optional TLV field in the SRv message based on the security policy identification;

and the second generation module is used for generating a SRv message corresponding to the access request based on the Optional TLV field.

In a fifth aspect, embodiments of the present application provide a controller, including:

the receiving module is used for receiving an access request sent by the client, wherein the access request comprises a target object which is applied to be accessed by the controller;

the generation module is used for determining a security policy corresponding to the user and a security policy identifier corresponding to the security policy based on the service access authority of the login user of the client to the target object;

And the sending module is used for sending the security policy identification to the client.

In a sixth aspect, an embodiment of the present application provides a node device, where the node device supports a zero trust security policy, and the node device includes:

the receiving module is used for receiving a SRv message corresponding to an access request sent by the previous node equipment, wherein the SRv message comprises a security policy identifier corresponding to the access request, the security policy identifier corresponds to a security policy, and the security policy is the service access authority of a user to the target object;

and the execution module is used for checking the validity of the security policy identifier and sending the SRv message to the next node equipment, wherein the validity of the security policy identifier is that the security policy identifier recorded in the SRv message is unmodified and the security policy identifier is in a valid state.

In a seventh aspect, embodiments of the present application provide an electronic device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, the processor implementing a method as described in embodiments of the present application when the program is executed.

In an eighth aspect, embodiments of the present application provide a computer readable storage medium having stored thereon a computer program which, when executed by a processor, implements a method as described in embodiments of the present application.

In a ninth aspect, embodiments of the present application provide a computer program product comprising a computer program, characterized in that the computer program, when executed by a processor, implements a method as described in embodiments of the present application.

According to the SRv message generation method based on zero trust, SRv message can contain the security policy identifier corresponding to the access request, so that the data plane can conduct security management on the behavior of the access request based on SRv message 6.

Additional aspects and advantages of the invention will be set forth in part in the description which follows and, in part, will be obvious from the description, or may be learned by practice of the invention.

Drawings

Other features, objects and advantages of the present application will become more apparent upon reading of the detailed description of non-limiting embodiments, made with reference to the following drawings, in which:

fig. 1 is a schematic structural diagram of a segment routing header according to an embodiment of the present application;

fig. 2 is a schematic structural diagram of a segment routing header according to an embodiment of the present application;

FIG. 3 illustrates an implementation environment architecture diagram of an embodiment of the present application;

FIG. 4 shows a flowchart of a method for generating SRv6 message based on zero trust, which is applied to a client according to an embodiment of the present application;

FIG. 5 shows a flowchart of a method for generating SRv6 message based on zero trust according to another embodiment of the present application, applied to a client;

FIG. 6 shows a flowchart of a method for generating SRv6 message based on zero trust according to another embodiment of the present application, applied to a client;

FIG. 7 illustrates a signaling interaction diagram of an embodiment of the present application;

FIG. 8 shows a flowchart of a method for generating SRv6 message based on zero trust, which is applied to a controller according to an embodiment of the present application;

FIG. 9 is a flowchart of a method for transmitting a SRv6 message based on zero trust, which is applied to a node device supporting a security policy with zero trust according to an embodiment of the present application;

FIG. 10 is a block diagram of a SRv message generating device based on zero trust according to an embodiment of the present application, applied to a client;

FIG. 11 is a block diagram of a SRv message generating device based on zero trust according to an embodiment of the present application, applied to a controller;

FIG. 12 is a block diagram of a SRv message transmission device based on zero trust according to an embodiment of the present application, applied to a node device supporting a security policy with zero trust;

fig. 13 shows a schematic diagram of a computer system suitable for use in implementing an electronic device or server of an embodiment of the present application.

Detailed Description

The present application is described in further detail below with reference to the drawings and examples. It is to be understood that the specific embodiments described herein are merely illustrative of the invention and are not limiting of the invention. It should be noted that, for convenience of description, only the portions related to the invention are shown in the drawings.

It should be noted that, in the case of no conflict, the embodiments and features in the embodiments may be combined with each other. The present application will be described in detail below with reference to the accompanying drawings in conjunction with embodiments.

The invention is applied to SRv networks and therefore the concepts associated with SRv will be briefly described below.

One basic design idea of SR (including both MPLS-based or IPv 6-based data plane) is: the state of each flow (i.e., segment routing policy (SRpolicy)) need only be maintained at the head node of the traffic flow path (i.e., SR tunnel), and need not be maintained at the intermediate and tail nodes. Among them, SRv is realized by defining an IPv6 routing header (SRH).

Fig. 1 shows a segment routing header (Segment Routing Header, SRH) provided by an embodiment of the present application. SRH100 includes an IPv6 header that includes a version field 102, a traffic class field 104, a flow label field 106, a payload length field 108, a next header field 110, a hop limit field 112, a source address field 114, and a destination address field 116. Version field 102 is a 4-bit field that identifies an internet protocol (Internet Protocol, IP) version number (e.g., 6). Traffic class field 104 is an 8-bit field used by the network for traffic management (e.g., by the source node and router to identify data messages belonging to the same traffic class and to prioritize data messages). The flow label field 106 is a 20-bit field used by the source to label the sequence of messages to be treated as a single flow in the network. The payload length field 108 is a 16-bit unsigned integer field that indicates the length of the payload, i.e., the remainder of the message following the SRH, in octets, i.e., 8 bits as a unit. The next header field 110 is an 8-bit field for identifying the type of header immediately following the IPv6 header, hereinafter referred to as a route extension header. The hop limit field 112 is an 8-bit unsigned integer field that indicates a limit on the number of hops allowed for a data packet before it is discarded (e.g., discarding a data packet that is stuck in an endless loop due to any routing information error). The hop limit field 112 is decremented by 1 by each node (typically a router) that forwards the message. Source address 114 is 128 bits and includes the IPv6 address of the source node of the message. The destination address field 116 is 128 bits and includes the destination address of the receiver node of the IPv6 message.

As described above, after an IPv6 header, SRH100 includes a route extension header (also commonly referred to as a routing header, a segment routing header, or a segment routing extension header). The IPv6 source uses the routing extension header to list one or more intermediate nodes to traverse on the path to the message destination. The route extension header includes a next message field 118, a header extension Length (Hdr Ext Len) field 120, a route Type field 122, a remaining fragments field 124, a last entry field 126, a flags field 128, a labels field 130, a fragments list including fragments list [0] field 132 through fragments list [ n ] field 134, and an Optional Type Length Value (optiontlv) object field 136. The next header field 118, similar to the next header field 110, is an 8-bit field that identifies the type of header immediately following the routing extension header (e.g., other extension header, transport layer protocol header, etc.). The header extension length field 120 is an 8-bit unsigned integer field that identifies the length of the routing extension header, excluding the first 8 groups of bits. The routing type field 122 is an 8-bit identification for identifying a particular routing header variant (i.e., identifying this structure as a segmented routing extension header). The remaining segments field 124 is an 8-bit unsigned integer character that indicates the number of remaining route segments, i.e., the number of intermediate nodes listed for display that remain to be accessed before reaching the final destination. The last entry field 126 includes an index (starting from 0) of the last element in the segment list. The flags field 128 is an 8-bit field that identifies SRH flags (e.g., clean up and fast reroute). The tag field 130 is used to tag a message as part of a class or group of messages (e.g., messages that share the same set of attributes).

The segment list [0] field 132 through segment list [ n ] field include a set of ordered segments encoded as IPv6 addresses. The segment list is encoded starting with the last segment in segment list 0 field 132. The segment list n field 134 includes the nth segment in the segment list. The fragments may identify any topology or service based instruction, i.e., a fragment list (Segment Identifier List, SIDList) that is used to specify forwarding paths and/or services for IPv6 messages. For example, a segment may be an instruction that a node performs on an incoming message (e.g., forward the message according to the shortest path to the destination, or forward the message over a dedicated interface, or forward the message to a given application/service instance).

Optional TLV object field 136 includes an optional TLV in SRH 100. The TLV provides metadata for the segmentation process. The TLV exists when the header extension length indicated in (Hdr Ext Len) field 120 exceeds the last entry element in the fragment list.

The establishment of the segment list SID of SRv can use both distributed and centralized methods. For example, SID is distributed via interior gateway protocol (Interior Gateway Protocol, IGP), border gateway protocol (Border Gateway Protocol, BGP) protocols. SID and computation paths are collected centrally by a software defined network (Software Defined Networking, SDN) controller.

For SRv, besides the general feature of SR, the most remarkable point is to support network programming (Network Programming), and by means of network programming, SRv6 has very strong scalability and can be applied to various application scenarios.

As shown in fig. 2, the IPv6 extension header of SRv includes three parts, namely, a location information reachability (location), a service Function definition (Function), and an enhancement (enhancement), where the location is generally addressed (related to routing), and indicates the location information reachability, the Function indicates a Function (e.g., topology or service) related to the SID, indicates the service Function definition, and the entity indicates parameters for performing related operations of the Function, that is, indicates enhancement information. While the segment list SID of SRv is specifically and flexibly programmable, the enable path is programmable. The Optional TLV after the fragment list SID is then application programmable enabled.

Having introduced concepts related to SRv6, SRv6 network scenarios are described below. In the SRv network, a plurality of network devices supporting IPv6 segment routing technology are typically included, and these network devices may be routers, switches, and other devices, which may be physical devices, or may be virtual devices implemented based on virtualization technologies, such as virtual servers, virtual routers, virtual switches, and the like.

However, with the development of cloud technology, network traffic of an enterprise is gradually migrated from enterprise internal traffic to enterprise external traffic. On this basis, in order to solve the network security problem, the related art proposes to write the security policy into the SID of SRv, so as to route the data packet to the designated security audit service by using the SID to perform security audit of the service function, thereby implementing a complex security policy. However, such security audit can only audit network location and service functions of the data packet tunnel path, i.e. audit content is irrelevant to user behavior, and cannot meet higher-level security requirements.

Based on this, the application proposes a method, a device and a system for generating and transmitting SRv messages based on SDP.

Among other things, the software defined boundary (Software Defined Perimeter, SDP) is a network security solution with an innovative approach, also called zero trust network (Zero Trust Network, ZTN). SDP (or ZTN) is based on the concept proposed by the Cloud Security Alliance (CSA), and the security stealth clothing is used for replacing the security body armor protection target, so that an attacker cannot see the attack target in the network space and cannot attack, and resources on enterprises or services are protected. Specifically, the key is to break the default 'trust', summarize by a sentence of colloquial, namely 'continuous verification, never trust', namely, defaults do not trust any person, equipment and system inside and outside the enterprise network, and reconstruct the trust basis of access control based on identity authentication and authorization, thereby ensuring identity trust, equipment trust, application trust and link trust. In particular, SDP protects specific accesses using standard-based and authenticated components such as data encryption, remote authentication (authentication of remote access by a host), transport layer security (TLS, a method of cryptographically authenticating client information), security Assertion Markup Language (SAML).

Fig. 3 shows an implementation environment architecture diagram of an embodiment of the present application. The implementation environment proposed in the application is a network architecture integrating an SDP controller and a service function chain (Service Function Chaining, SFC). SFC is a network technology for solving the problem that the deployment and adjustment of network service equipment such as a firewall, a load balancer and the like in the current network are not flexible enough. The sequence of a set of devices with service handling functions (e.g. firewalls, load balancers, etc.) in the network becomes a service function chain SFC.

As shown in fig. 3, the architecture proposed in the present application includes a controller 301, a service function chain SFC302, a client 303, and an application server 304.

The controller 301 may include a system on Chip (SoC) 3011, a unified identity server 3012, a unified policy server 3013, a trust evaluation server 3014, and an SDN controller 3015. Each server in the controller 301 may be an independent physical server, or may be a server cluster or a distributed system formed by a plurality of physical servers. The unified identity server 3012, unified policy server 3013, and trust evaluation server 3014 are used to perform access audit authorization for clients, user identities, and access content. SDN controller 3015 is used to determine a communication path.

The service function chain SFC302 may include SC, SF, and SFF. The SC (Service Classifier ) is responsible for streaming the specified Service message into the Service chain, adding the Service chain related encapsulation, and the SFF (Service Function Forwarder, service Function forwarding device) is responsible for forwarding the Service chain related message to SF processing, where the SF (Service Function device) implements the devices of the specified Service functions (firewall, NAT, DPI, etc.).

That is, after the client 303 sends a login request carrying identity information to the controller 301, the unified identity server 3012 in the controller 301 checks the identity information of the user, and when the identity information check is passed, the client 303 maintains the identity state information and waits for the user to initiate a secure access request.

When a user needs to make a secure access request, a first request for applying for an access target is sent to a controller through a client 303, a unified policy server 3013 and an SDN controller 3015 in the controller 301 allocate corresponding network paths and basic security policies based on user identity information, and allocate security policy identifiers, wherein the security policy identifiers have a corresponding relationship with the network paths and the security policies. The controller 301 sends the security policy identification and the corresponding security policy to the node device supporting the security policy in the service function chain SFC 302. Meanwhile, the controller 301 sends the network path and the security policy identifier corresponding to the first request to the client 302. The client 302 generates SRv message according to the first requested service policy, the received network path and the security policy identifier. The client 302 sends the generated SRv message to the first node device in the network path, so that at least one node device in the service function chain SFC302 forwards the message sequentially according to the network path pair in the SRv6 message. The node device supporting the policy of zero trust in the service function chain SFC302 determines whether the current request is legal according to the SRv message, if so, sends the current request to the next node device according to the network path in the SRv message, and if not, discards the current message. Until the last node device of the service function chain SFC302 sends a SRv message to the application service 304.

Fig. 4 shows a flowchart of a method for generating a SRv6 message based on zero trust according to an embodiment of the present application. The SRv message generating method based on zero trust is applied to the client.

As shown in fig. 4, the SRv message generating method based on zero trust includes:

step 401, in response to a trigger instruction of the access request, sending an access request for applying to access the target object to the controller.

Wherein the access request includes the target object. The client can receive a trigger instruction of an access request input by a user through the interactive interface. For example, the user may determine the target object through the target object identifier in the interactive interface, generate a trigger instruction of the access request when clicking the target object identifier, and then the client sends an access request for accessing the target object to the controller in response to the trigger instruction of the access request.

Step 402, receiving a security policy identifier sent by the controller in response to the access request, where the security policy identifier corresponds to a security policy, and the security policy is a service access right of the user to the target object.

It should be appreciated that the controller, upon receiving the access request, determines the security policy corresponding to the user based on the target object and the user identity information. Specifically, the controller determines the access right of the user to the target object according to the preset mapping relation between the user identity information and the right. Wherein the service access rights include, but are not limited to, one or more of query, copy, and modify. For example, the controller may determine the access rights of the user to the data in the target object according to the user identity information, for example, the user may only be able to query the data in the target object, may allow the user to query and copy the data in the target object, may not allow the user to modify the data in the target object, and may allow the user to query, copy and modify the data in the target object.

It should be understood that the service access rights may be determined by a unified identity server and a unified policy server in the controller, and the service access rights between each user and the target object may be set in advance in the controller, i.e., stored in the unified identity server and/or the unified policy server.

After determining the service access authority of the user to the target object according to the user identity information and the target object, generating a security policy of the user to the target object according to the service access authority range, and compiling a security policy identifier for the security policy, wherein the security policy identifier can be the number of the security policy.

It should be appreciated that there is only one per security policy identification corresponding to user identity information, and that each access request may include at least one security policy identification. Optionally, the security policy identifier may include an identifier section for indicating the identity of the user.

It should be further understood that, since the security policy corresponding to the security policy identifier is issued to each node device by the controller, more information is effectively avoided being transmitted on the data plane each time, so that traffic is saved and communication efficiency is improved.

In step 403, an Optional TLV field in the SRv message is generated based on the security policy identification.

It should be understood that, because the Optional TLV field is programmable, the present application generates the Optional TLV field in the SRv message based on the security policy identifier, so that the SRv message can effectively carry security policy information, and thus the SRv6 message performs security policy validity verification in the transmission process.

Optionally, after receiving the SRv6 packet, the node device may match the security policy identifier carried in the Optional TLV field in the SRv packet with the security policy identifier list received from the controller, when the security policy identifier carried in the Optional TLV field in the SRv packet is successfully matched with the security policy identifier list, it is determined that the packet (i.e. the access request) has permission to execute, the SRv packet may be forwarded to the next node device, when the security policy identifier carried in the Optional TLV field in the SRv packet is unsuccessful in matching with the security policy identifier list, it is determined that the access authority of the packet (i.e. the access request) is changed, that is, the user may not have the service access authority recorded in the SRv packet any more, and if the SRv6 packet is forwarded continuously, illegal access of the user is easily caused, so that the current SRv6 packet is discarded.

Step 404, based on the Optional TLV field, a SRv message corresponding to the access request is generated.

Therefore, the SRv message generating method based on zero trust provided by the embodiment of the application can enable the SRv message to contain the security policy identifier corresponding to the access request, so that the data plane can perform security management on the behavior of the access request based on the SRv6 message.

In one or more embodiments, as shown in FIG. 5, step 403. Generating an Optional TLV field in a SRv message based on the security policy identification includes:

step 4031, a first Optional TLV field of the SRv message corresponding to the access request is generated.

The first Optional TLV field is an initial Optional TLV field generated when the SRv message is generated according to the access request, that is, an Optional TLV field required by the SRv message meeting the requirements of the normal access request.

Step 4032, inserting the security policy identifier into the first Optional TLV field to obtain a second Optional TLV field.

That is, the security policy identifier may be directly inserted into the first Optional TLV field, so that the obtained second Optional TLV field may include the security policy, and the purpose that the SRv message may carry the security policy is achieved.

The field size of the security policy identifier may be set according to practical situations, and the security policy identifier may be 16 bytes, for example, or may be changed according to specific situations, for example, 8 bytes. It should be appreciated that the size of the security policy identification remains consistent in one system to ensure that subsequent execution loops can read and verify.

Alternatively, the security policy identifier may be directly spliced with the first Optional TLV field to obtain the second Optional TLV field.

In step 4033, an Optional TLV field is generated based on the second Optional TLV field.

It should be understood that, in order to further ensure that the transmission SRv message Wen Shibao in the service function chain is not tampered, that is, the tampered message is avoided being forwarded or executed, verification information is added in the Optional TLV field, so that when each node device determines that the message SRv6 is not tampered through the verification information, operations such as validity verification and forwarding of the security policy identifier are performed.

In one or more embodiments, generating the Optional TLV field based on the second Optional TLV field includes: encryption processing is carried out based on the second Optional TLV field, so that verification information is obtained; based on the second Optional TLV field and the verification information, an Optional TLV field is obtained.

It should be understood that the encryption processing is performed through the second Optional TLV field, that is, the initial Optional TLV field and the security policy identifier are encrypted as a whole, so that the node device can determine whether the security policy identifier is tampered with or not through the reconstructed security policy identifier and the security policy identifier recorded in the second Optional TLV field after decrypting the encrypted information, thereby effectively preventing the SRv message from being tampered with.

Alternatively, hash computation is used for encryption.

Further, acquiring a segmentation list, a time stamp and a preset one-time key of the SRv message; and carrying out hash calculation on the segment list, the time stamp, the candidate Optional TLV field and the preset one-time key to obtain verification information.

That is, in order to further improve the reliability of the verification information, in the embodiment of the present application, hash computation is performed on the segment list of the SRv message, the timestamp and the preset one-time key, so as to improve the complexity of the verification information and reduce the risk of tampering.

Wherein the preset one-time key (One Time Password, OTP) is generated using an HOTP algorithm from the preset key, where otp=hotp (K, C) =trunk (HMAC-HASH algorithm (K, C)), K is the preset key, and C is the timestamp.

Optionally, when the node device supporting zero trust verifies SRv, the method further includes verifying a timestamp in the SRv message, that is, determining whether the access request is expired or replayed by the timestamp. Specifically, the last time stamp is recorded in each node device, and if the time stamp in the current SRv message is less than the last time stamp, the playback is considered.

It should be appreciated that to avoid passing keys on every communication, the controller, node device and client may be set to synchronize key updates.

It should be further understood that after receiving the SRv message, the node device may verify whether the SRv message is tampered based on the verification information, and further determine whether the security policy corresponding to the security policy identifier is valid if it is determined that the SRv message is not tampered.

In one or more embodiments, as shown in fig. 6, further comprising:

and step 601, responding to a triggering instruction of identity authentication, and sending user identity information to a controller.

Step 602, receiving an authentication result of the controller in response to the user identity information, and monitoring a trigger instruction of the access request when the authentication result is passing.

That is, before sending an access request to the controller, the user identity information needs to be verified, that is, when the client monitors a trigger instruction of identity authentication, the user identity information is sent to the controller. The controller receives user identity information, a unified identity server in the controller verifies the user identity, when a user corresponding to the user identity information is a user in a preset user authority list, a legal authentication result of the user is sent to the client, namely, the authentication result is passed, and when the user corresponding to the user identity information is not in the preset user authority list, an illegal authentication result of the user is sent to the client, namely, the authentication result is not passed.

As a specific embodiment, as shown in fig. 7, it includes:

in step 701, the client sends user identity information to the controller in response to a trigger instruction of identity authentication.

Step 702, the controller checks the user identity information, and determines whether the user identity information passes.

If not, the controller sends the failed authentication information to the client;

if so, the controller sends the passed authentication information to the client.

In step 703, when the authentication result is passed, the client monitors a trigger instruction of the access request.

In step 704, the client sends an access request for applying to access the target object to the controller in response to the trigger instruction of the access request.

Step 705, the controller allocates a security policy, a security policy identifier corresponding to the security policy, and a traffic flow path to the access request based on the target object and the user identity information in the access request.

In step 706, the controller sends the security policy identifier and the service flow path to the client, and simultaneously sends the security policy and the security policy identifier corresponding to the security policy to the node device supporting zero trust in the service function chain.

The node equipment which does not support zero trust in the service function chain can directly forward the security policy and the security policy identifier corresponding to the security policy to the next node equipment, and the node which supports zero trust receives and stores the security policy and the security policy identifier corresponding to the security policy and forwards the security policy and the security policy identifier corresponding to the security policy to the next node equipment.

In step 707, the client generates SRv message based on the traffic flow path and the security policy identification.

In step 708, the client sends SRv a message to the node in the service function chain.

In step 709, when the node device is a node device that does not support zero trust, the SRv message is sent to the next node device according to the segment list in the SRv message.

In step 710, when the node device is a node device supporting zero trust, the verification information in the SRv message is parsed and reconstructed.

In step 711, the node device supporting zero trust determines SRv whether the message is tampered with based on the authentication information.

If so, the SRv message is discarded, and if not, step 712 is performed.

In step 712, the node device supporting zero trust sends SRv a message to the next node device according to the segment list in the SRv message.

In summary, the SRv message generating method based on zero trust provided by the embodiment of the application can enable SRv message to contain the security policy identifier corresponding to the access request, so that the data plane can perform security management on the behavior of the access request based on SRv message.

Fig. 8 shows a flowchart of a method for generating a SRv6 message based on zero trust, which is applied to a controller according to an embodiment of the present application.

As shown in fig. 8, further includes:

in step 801, an access request sent by a client is received, where the access request includes a target object to which the controller applies for access.

Step 802, determining a security policy corresponding to a user and a security policy identifier corresponding to the security policy based on a service access right of a login user of the client to a target object.

Step 803, the security policy identification is sent to the client.

In one or more embodiments, further comprising: and sending the security policy identification and the corresponding security policy to each node device in the service function chain.

It should be noted that, for details not disclosed in the method for generating SRv6 message based on zero trust in the embodiments of the present application, please refer to details of the foregoing embodiments of the present application, which are not described herein again.

Fig. 9 shows a flowchart of a method for transmitting a SRv6 message based on zero trust according to an embodiment of the present application. The method is applied to the node equipment supporting the zero trust security policy.

As shown in fig. 9, the SRv message transmission method based on zero trust includes:

step 901, receiving a SRv message corresponding to an access request sent by a previous node device, where the SRv message includes a security policy identifier corresponding to the access request, where the security policy identifier corresponds to a security policy, and the security policy is a service access authority of a user to a target object.

Step 902, it is used to verify that the security policy identifier is valid, and send the SRv message to the next node device, where the security policy identifier is valid as SRv, the security policy identifier recorded in the message is unmodified, and the security policy identifier is in a valid state.

In one or more embodiments, further comprising: and receiving the security policy identification sent by the controller and the corresponding security policy.

It should be noted that, for details not disclosed in the SRv message transmission method based on zero trust in the embodiments of the present application, please refer to details of the foregoing embodiments of the present application, which are not described herein again.

In summary, the SRv message transmission method based on zero trust provided by the embodiment of the application can enable SRv message to contain the security policy identifier corresponding to the access request, so that the data plane can perform security management on the behavior of the access request based on SRv message.

Fig. 10 shows a block diagram of a SRv message generating device based on zero trust, which is applied to a client according to an embodiment of the present application.

As shown in fig. 10, the SRv message generating device 10 based on zero trust includes:

a sending module 11, configured to send an access request for applying to access the target object to the controller in response to a trigger instruction of the access request;

the receiving module 12 is configured to receive a security policy identifier sent by the controller in response to the access request, where the security policy identifier corresponds to a security policy, and the security policy is a service access right of the user to the target object;

the first generating module 13 is configured to generate an Optional TLV field in the SRv message based on the security policy identifier;

the second generating module 14 is configured to generate a SRv message corresponding to the access request based on the Optional TLV field.

In one or more embodiments, the first generating module 13 is further configured to:

generating a first Optional TLV field of a SRv message corresponding to the access request;

an Optional TLV field is generated based on the second Optional TLV field.

based on the second Optional TLV field and the verification information, an Optional TLV field is obtained.

acquiring a segmentation list, a time stamp and a preset one-time key of a SRv message;

and carrying out hash calculation on the segment list, the time stamp, the candidate Optional TLV field and the preset one-time key to obtain verification information.

responding to a triggering instruction of identity authentication, and sending user identity information to a controller;

and receiving an authentication result of the controller in response to the user identity information, and monitoring a triggering instruction of the access request when the authentication result is passing.

It should be noted that, for details not disclosed in the SRv message generating device based on zero trust in the embodiments of the present application, please refer to details of the foregoing embodiments of the present application, which are not described herein again.

In summary, the SRv message generating device based on zero trust provided in the embodiments of the present application can enable SRv message to include the security policy identifier corresponding to the access request, so that the data plane can perform security management on the behavior of the access request based on SRv message.

Fig. 11 shows a block diagram of a SRv message generating device based on zero trust, which is applied to a controller according to an embodiment of the present application.

As shown in fig. 11, the controller 20 includes:

a receiving module 21, configured to receive an access request sent by a client, where the access request includes a target object to which the controller applies for access;

the generating module 22 is configured to determine a security policy corresponding to the user and a security policy identifier corresponding to the security policy based on a service access right of the login user of the client to the target object;

a sending module 23, configured to send the security policy identifier to the client.

In some embodiments, the sending module 23 is further configured to: and sending the security policy identification and the corresponding security policy to each node device in the service function chain.

as shown in fig. 12, the node apparatus 30 includes:

the receiving module 31 is configured to receive a SRv message corresponding to an access request sent by a previous node device, where the SRv message includes a security policy identifier corresponding to the access request, and the security policy identifier corresponds to a security policy, and the security policy is a service access authority of a user to a target object.

The execution module 31 is configured to verify that the security policy identifier is valid, send a SRv message to the next node device, and make the security policy identifier valid SRv be the security policy identifier recorded in the message itself unmodified and make the security policy identifier valid.

It should be noted that, for details not disclosed in the SRv message transmission device based on zero trust in the embodiments of the present application, please refer to details of the foregoing embodiments of the present application, which are not described herein again.

In summary, the SRv message transmission device based on zero trust provided in the embodiments of the present application can enable SRv message to include the security policy identifier corresponding to the access request, so that the data plane can perform security management on the behavior of the access request based on SRv message.

It should be understood that the units or modules described in the apparatus correspond to the individual steps in the method described with reference to fig. 2. Thus, the operations and features described above for the method are equally applicable to the apparatus and the units contained therein, and are not described in detail herein. The device can be pre-implemented in a browser of the electronic equipment or other security applications, or can be loaded into the browser of the electronic equipment or the security applications thereof by means of downloading and the like. Corresponding units in the apparatus may cooperate with units in the electronic device to implement the solutions of the embodiments of the present application.

The division of the modules or units mentioned in the above detailed description is not mandatory. Indeed, the features and functionality of two or more modules or units described above may be embodied in one module or unit in accordance with embodiments of the present disclosure. Conversely, the features and functions of one module or unit described above may be further divided into a plurality of modules or units to be embodied.

Referring now to fig. 13, fig. 13 shows a schematic diagram of a computer system suitable for use in implementing an electronic device or server of an embodiment of the present application,

As shown in fig. 13, the computer system includes a Central Processing Unit (CPU) 1301, which can execute various appropriate actions and processes according to a program stored in a Read Only Memory (ROM) 1302 or a program loaded from a storage section 1308 into a Random Access Memory (RAM) 1303. In the RAM1303, various programs and data required for operation instructions of the system are also stored. The CPU1301, ROM1302, and RAM1303 are connected to each other through a bus 1304. An input/output (I/O) interface 1305 is also connected to bus 1304.

The following components are connected to the I/O interface 1305; an input section 1306 including a keyboard, a mouse, and the like; an output portion 1307 including a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and the like, and a speaker, and the like; a storage portion 1308 including a hard disk or the like; and a communication section 1309 including a network interface card such as a LAN card, a modem, or the like. The communication section 1309 performs a communication process via a network such as the internet. The drive 1310 is also connected to the I/O interface 1305 as needed. Removable media 1311, such as magnetic disks, optical disks, magneto-optical disks, semiconductor memory, and the like, is installed as needed on drive 1310 so that a computer program read therefrom is installed as needed into storage portion 1308.

In particular, according to embodiments of the present application, the process described above with reference to flowchart fig. 2 may be implemented as a computer software program. For example, embodiments of the present application include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising program code for performing the method shown in the flowcharts. In such an embodiment, the computer program contains program code for performing the method shown in the flow chart. In such embodiments, the computer program may be downloaded and installed from a network via the communication portion 1309 and/or installed from the removable medium 1311. The above-described functions defined in the system of the present application are performed when the computer program is executed by a Central Processing Unit (CPU) 1301.

It should be noted that the computer readable medium shown in the present application may be a computer readable signal medium or a computer readable storage medium, or any combination of the two. The computer readable storage medium can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or a combination of any of the foregoing. More specific examples of the computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In the present application, however, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, with computer-readable program code embodied therein. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination of the foregoing. A computer readable signal medium may also be any computer readable medium that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, fiber optic cable, RF, etc., or any suitable combination of the foregoing.

The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation instructions of possible implementations of systems, methods and computer program products according to various embodiments of the present application. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, blocks shown in two separate connections may in fact be performed substantially in parallel, or they may sometimes be performed in the reverse order, depending on the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The units or modules described in the embodiments of the present application may be implemented by software, or may be implemented by hardware. The described units or modules may also be provided in a processor, for example, as: a processor includes a transmitting module, a receiving module, a first generating module, and a second generating module. The names of these units or modules do not in some cases limit the units or modules themselves, for example, the sending module may also be described as "sending an access request for applying to access the target object to the controller in response to a trigger instruction of the access request".

As another aspect, the present application also provides a computer-readable storage medium that may be included in the electronic device described in the above embodiment or may exist alone without being incorporated into the electronic device. The computer readable storage medium stores one or more programs which when executed by one or more processors perform the zero trust based SRv message generation method described herein.

The foregoing description is only of the preferred embodiments of the present application and is presented as a description of the principles of the technology being utilized. It will be appreciated by persons skilled in the art that the scope of the disclosure referred to in this application is not limited to the specific combinations of features described above, but it is intended to cover other embodiments in which any combination of features described above or equivalents thereof is possible without departing from the spirit of the disclosure. Such as the above-described features and technical features having similar functions (but not limited to) disclosed in the present application are replaced with each other.

Claims

1. The SRv message generation method based on zero trust is characterized by being applied to a client and comprising the following steps:

2. The method of claim 1, wherein generating the Optional TLV field in the SRv message based on the security policy identification comprises:

generating the Optional TLV field based on the second Optional TLV field.

3. The method of claim 2, wherein the generating the Optional TLV field based on the second Optional TLV field comprises:

4. The method of claim 3, wherein the encrypting based on the second Optional TLV field to obtain the verification information comprises:

5. The method as recited in claim 1, further comprising:

6. The SRv message generation method based on zero trust is characterized by being applied to a controller and comprising the following steps:

And sending the security policy identification to the client.

7. The method as recited in claim 6, further comprising:

and sending the security policy identification and the corresponding security policy to each node device in the service function chain.

8. A SRv message transmission method based on zero trust, which is applied to node equipment, wherein the node equipment supports a zero trust security policy, the method comprising:

9. The method of claim 8, wherein the previous node device is a client when the current node is a first node in a traffic function chain.

10. A SRv message generating device based on zero trust, which is applied to a client, and comprises:

11. A controller, comprising:

12. A node device, the node device supporting a zero trust security policy, the node device comprising:

13. An electronic device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, wherein the processor implements the zero trust based SRv message generation method of any one of claims 1-5, or the zero trust based SRv message generation method of any one of claims 6-7, or the zero trust based SRv6 message transmission method of claims 8-9, when the program is executed.

14. A computer readable storage medium having stored thereon a computer program, which when executed by a processor implements a zero trust based SRv6 message generating method according to any of claims 1-5, or a zero trust based SRv message generating method according to any of claims 6-7, or a zero trust based SRv6 message transmission method according to any of claims 8-9.