Switch security protocol interaction method, device and equipment and storage medium

Abstract

The invention provides a switch security protocol interaction method and device, equipment and a storage medium, and the method comprises the steps: carrying out the protocol type recognition of a received network data frame, and generating first intermediate data according to the recognized protocol type; according to the protocol type identifier of the first intermediate data, converting the format of the network data frame through a protocol mapping rule to generate second intermediate data; determining a security processing strategy corresponding to a preset strategy rule set according to the strategy identification field of the second intermediate data; reconstructing the original content of the second intermediate data into a target data frame conforming to a target protocol format according to a security processing strategy; and according to the security level field and the communication direction of the target data frame, performing path screening through the trusted path list, and determining a target interaction path. According to the scheme, the trusted interaction path can be dynamically screened based on the protocol type and the security level field of the target data frame, and controllable data transmission between switches under security protocol cooperation is realized.

Description

Technical Field

[0001] This application relates to the field of switch technology, and in particular to a switch security protocol interaction method, apparatus, device and storage medium. Background Technology

[0002] With the continuous evolution of cybersecurity threats and the increasing complexity of multi-service network environments, switches, as critical data forwarding devices, no longer merely perform traditional forwarding control functions. They also need to possess the ability to identify, coordinate, and process multiple security protocols. In practical applications, such as data security exchange systems in government intranets, multiple switches often need to simultaneously support multiple secure communication protocols such as IPSec, TLS, and MACsec to meet the data encryption transmission requirements of different business systems. However, existing switch protocol processing mechanisms are mostly statically configured, lacking a unified architecture for dynamic identification of multiple protocols, policy-driven processing, and secure path selection. Especially in environments with mixed protocols, switches cannot achieve coordinated processing based on protocol characteristics and communication levels, leading to problems such as protocol incompatibility, path selection failure, or transmission policy conflicts during data interaction. Summary of the Invention

[0003] This application provides a method, apparatus, device, and storage medium for security protocol interaction in a switch, which addresses the problem of protocol incompatibility in data interaction involving multiple protocols.

[0004] The first aspect of this application provides a method for exchanging security protocols on a switch, the method comprising: The received network data frames are identified by protocol type, and the first intermediate data is generated based on the identified protocol type. Based on the protocol type identifier of the first intermediate data, the format of the network data frame is converted according to the protocol mapping rules to generate the second intermediate data; The security processing policy corresponding to the preset policy rule set is determined based on the policy identifier field in the second intermediate data; According to the security processing strategy, the original content in the second intermediate data is reconstructed into a target data frame that conforms to the target protocol format; Based on the security level field and communication direction of the target data frame, the target interaction path is determined by filtering through a list of trusted paths.

[0005] Optionally, in a first implementation of the first aspect of this application, the step of identifying the protocol type of the received network data frame and generating first intermediate data based on the identified protocol type includes: By extracting feature fields from the received network data frames, a set of protocol parameters corresponding to the protocol identification is generated; By matching the protocol feature fields of the protocol parameter set with a preset protocol fingerprint rule base, the corresponding protocol type identifier is obtained; The communication fields of the network data frame are parsed according to the protocol type identifier to extract context data; The first intermediate data is constructed based on the protocol type identifier and context data.

[0006] Optionally, in a second implementation of the first aspect of this application, the step of converting the format of the network data frame according to the protocol type identifier of the first intermediate data through a protocol mapping rule to generate the second intermediate data includes: Based on the protocol type identifier of the first intermediate data, obtain the field structure template of the corresponding target protocol from the preset protocol mapping rules; A field conversion mapping table is determined by comparing and mapping the protocol fields of the network data frame with the field structure template. The communication fields of the network data frame are reformatted according to the field conversion mapping table to generate intermediate encapsulated data with matching structure. Based on the context information of the intermediate encapsulated data and the first intermediate data, the second intermediate data is constructed.

[0007] Optionally, in the third implementation of the first aspect of this application, the step of determining the security processing policy corresponding to the preset policy rule set based on the policy identifier field in the second intermediate data includes: Based on the strategy identifier field of the second intermediate data, the preset strategy rule set is indexed and retrieved to obtain the strategy rule entry corresponding to the strategy identifier field; By comparing the matching condition field of the policy rule entry with the protocol context field of the second intermediate data, a policy rule group that meets the conditions is determined. Generate a corresponding set of policy parameters based on the processing instruction fields in the policy rule group; By binding the set of policy parameters with the second intermediate data, a security processing policy containing a set of control instructions and processing rules is generated.

[0008] Optionally, in the fourth implementation of the first aspect of this application, the step of reconstructing the original content in the second intermediate data into a target data frame conforming to the target protocol format according to the security processing strategy includes: Obtain the corresponding target protocol structure template according to the control instruction set of the security processing strategy; By extracting fields and mapping formats from the protocol context fields, a protocol structure mapping table that matches the target protocol structure template is generated. According to the protocol structure mapping table, the communication field and data payload field of the second intermediate data are reorganized and format encapsulated to generate an initial data frame in the target protocol format; By adding the security processing parameter set of the security processing strategy to the initial data frame, a target data frame containing a complete protocol structure and security configuration is generated.

[0009] Optionally, in the fifth implementation of the first aspect of this application, the step of determining the target interaction path by filtering paths through a trusted path list based on the security level field and communication direction of the target data frame includes: The preset trusted path list is filtered based on the security level field and communication direction of the target data frame to obtain a set of path candidates that meet the constraints of the field. By extracting credibility indicators from each path node in the path candidate set, a corresponding path credibility parameter table is generated. A path evaluation structure is generated by jointly calculating the path reliability parameter table and the protocol context field in the target data frame. The path evaluation structure is prioritized and sorted to determine the target interaction path with the highest priority.

[0010] Optionally, in a sixth implementation of the first aspect of this application, the method further includes: Based on the path node identifiers of the target interaction path, extract the real-time communication performance metrics of each node from the dynamic path performance library. A dynamic path evaluation parameter table is generated by jointly weighting the real-time communication performance indicators with the security level field of the target data frame. Based on the dynamic path evaluation parameter table, the node sequence of the target interaction path is subjected to link fragmentation and reorganization to generate an optimized path topology. Based on the optimized path topology, the transmitted data packets are segmented and hashed to generate data verification vectors bound to each link fragment, and the data verification vectors are embedded in the extended header field of the target data frame.

[0011] A second aspect of this application provides a switch security protocol interaction device, the switch security protocol interaction device comprising: The identification module is used to identify the protocol type of the received network data frames and generate the first intermediate data based on the identified protocol type. The conversion module is used to convert the format of the network data frame according to the protocol type identifier of the first intermediate data and through protocol mapping rules to generate the second intermediate data; The determination module is used to determine the security processing policy corresponding to the preset policy rule set based on the policy identifier field in the second intermediate data; The reconstruction module is used to reconstruct the original content in the second intermediate data into a target data frame that conforms to the target protocol format according to the security processing strategy. The filtering module is used to filter paths based on the security level field and communication direction of the target data frame through a list of trusted paths to determine the target interaction path.

[0012] A third aspect of this application provides an electronic device, including a memory and a processor, wherein the processor is configured to execute a computer program stored in the memory, and when the processor executes the computer program, it implements the steps of the switch security protocol interaction method provided in the first aspect of this application.

[0013] The fourth aspect of this application provides a computer-readable storage medium storing a computer program thereon. When the computer program is executed by a processor, it implements the steps of the switch security protocol interaction method provided in the first aspect of this application.

[0014] In summary, the switch security protocol interaction method, apparatus, device, and storage medium provided in this application identify the protocol type of received network data frames and generate first intermediate data based on the identified protocol type. Based on the protocol type identifier of the first intermediate data, the format of the network data frames is converted using protocol mapping rules to generate second intermediate data. A security processing policy corresponding to a preset policy rule set is determined based on the policy identifier field in the second intermediate data. The original content in the second intermediate data is reconstructed into a target data frame conforming to the target protocol format based on the security processing policy. Based on the security level field and communication direction of the target data frame, a trusted path list is used for path filtering to determine the target interaction path. Through the implementation of this application, trusted interaction paths can be dynamically filtered based on the protocol type and security level field of the target data frame, enabling controllable data transmission under secure protocol collaboration between switches. Attached Figure Description

[0015] Figure 1 A flowchart illustrating the switch security protocol interaction method provided in an embodiment of this application; Figure 2 A schematic diagram of the program modules of the switch security protocol interaction device provided in the embodiments of this application; Figure 3This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0016] To make the inventive objectives, features, and advantages of this application more apparent and understandable, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0017] To address the protocol incompatibility issues that arise during multi-protocol data interaction in related technologies, embodiments of this application provide a switch security protocol interaction method, such as... Figure 1 This is a flowchart illustrating the switch security protocol interaction method provided in this embodiment. The switch security protocol interaction method includes the following steps: Step 110: Identify the protocol type of the received network data frames and generate the first intermediate data based on the identified protocol type.

[0018] Specifically, the first part of the switch security protocol interaction method involves identifying the protocol type of received network data frames. Its core lies in parsing the feature fields in the data frame (such as frame header type, authentication parameters, encryption identifiers, etc.) to extract feature parameters that can be used to determine the protocol category. This is then compared with a pre-defined protocol fingerprint database to determine the specific protocol type corresponding to the data frame, such as IPSec, TLS, or MACsec. After identifying the protocol type, it is necessary to further extract fields related to the communication context, such as source address, destination address, and session identifier, to construct the first intermediate data structure, providing type and context support for subsequent processing. Therefore, protocol identification not only provides protocol classification but also provides a preliminary summary of the data packet context environment, ensuring accurate operation based on scenario information in subsequent data processing stages.

[0019] In one optional implementation of this embodiment, the step of identifying the protocol type of a received network data frame and generating first intermediate data based on the identified protocol type includes: extracting feature fields from the received network data frame to generate a protocol parameter set corresponding to the protocol identification; matching the protocol feature fields of the protocol parameter set with a preset protocol fingerprint rule base to obtain the corresponding protocol type identifier; parsing the communication fields of the network data frame based on the protocol type identifier to extract context data; and constructing the first intermediate data based on the protocol type identifier and the context data.

[0020] Specifically, in the process of security protocol interaction on a switch, extracting feature fields from received network data frames is a crucial step in protocol type identification. Essentially, it involves extracting fields with protocol identification value from raw binary data. Network data frames generally include a header, payload, and trailer. The header carries feature fields such as protocol flags, version number, service type, and port information. By locating these header fields using a specific parsing module, the byte sequence related to protocol features can be obtained. These fields are distinctive; for example, the ESP (Encapsulating Security Payload) header in the IPSec protocol has a clear next-layer protocol flag field, while the TLS handshake phase includes a version number and a specific ClientHello message structure. Therefore, by performing byte-level shifting, matching, and decoding operations on the original frame structure, a structure called the protocol parameter set is obtained. This structure contains protocol feature fields, a header digest, port number, identifier, and other information that may be used for protocol identification. After obtaining the protocol parameter set, the protocol type identifier needs to be obtained through further matching. A protocol type identifier is a unique identifier used to characterize the protocol to which a data packet belongs. It typically uses encoding formats such as hexadecimal, ASN.1, or an internally defined protocol ID. The matching process relies on a pre-defined protocol fingerprint rule base, which consists of multiple protocol field characteristics, including the value range of key fields, field offsets, and field combination structures. For example, a rule might define that if the first byte is 0x16, the third byte is 0x0301, and the sixth byte contains a payload field of length 512, then the frame is considered to conform to the characteristics of the TLS 1.0 protocol. The matching process uses a field comparison algorithm to match the protocol feature fields in the protocol parameter set one-to-one. If a rule is met, the protocol type of the network data frame can be determined as the corresponding identifier, completing protocol identification. For example, if a network data frame contains the ESP flag, the destination port is 4500, and the payload contains an IKEv2 header structure, it can be identified as the IPSec IKEv2 protocol. After identifying the protocol type identifier, it is necessary to further parse the communication fields in the network data frame using this identifier to extract context data to support subsequent data structure reassembly and policy selection. Communication fields refer to basic control fields related to data communication, including but not limited to source address, destination address, session identifier, flow identifier, sequence number, and authentication token. The structure of communication fields varies depending on the protocol; therefore, the corresponding protocol's field parsing template must be called based on the identified protocol type. For example, in IPSec, the source / destination IP address can be extracted from the IP header, and the SPI (Security Parameters Index) and sequence number can be parsed from the ESP header. In the TLS protocol, the session ID and cipher suite identifier need to be extracted from the handshake record.This process not only provides security context support for subsequent policy matching but also provides data sources for functions such as auditing and logging. Finally, based on the obtained protocol type identifier and context data, a first intermediate data structure can be constructed for subsequent format conversion, policy invocation, and data reconstruction. The first intermediate data is a structured data abstraction that uniformly represents the protocol identity and environment information of network data frames, including but not limited to protocol type, communication field values, initial security level estimate, source / destination identifier, port information, and timestamp.

[0021] Step 120: Based on the protocol type identifier of the first intermediate data, convert the format of the network data frame according to the protocol mapping rules to generate the second intermediate data; Specifically, in this embodiment, the format of the original network data frame is uniformly converted based on the protocol type identifier provided in the first intermediate data. This process calls the field mapping template corresponding to the target protocol type to match, rearrange, and rename the fields in the original frame structure, thereby generating a standardized encapsulation format. The conversion process maps fields with significant structural differences in various protocols (such as encryption headers of different lengths or different flag bits) to a unified data organization method, while preserving key context fields to ensure that security control and routing information are not lost during the conversion process. This encapsulation structure ultimately forms the second intermediate data, signifying that the original data has cross-protocol processing capabilities, establishing a unified semantic foundation for the policy judgment stage.

[0022] In one optional implementation of this embodiment, the step of converting the format of a network data frame and generating second intermediate data according to the protocol type identifier of the first intermediate data through protocol mapping rules includes: obtaining the field structure template of the corresponding target protocol from a preset protocol mapping rule according to the protocol type identifier of the first intermediate data; determining a field conversion mapping table by comparing and mapping the protocol fields of the network data frame with the field structure template; reorganizing the communication fields of the network data frame according to the field conversion mapping table to generate structurally matched intermediate encapsulated data; and constructing the second intermediate data according to the context information of the intermediate encapsulated data and the first intermediate data.

[0023] Specifically, in the switch security protocol interaction method, after protocol type identification, the original network data frame format needs to be structurally converted based on the protocol type identifier in the first intermediate data to unify various heterogeneous protocols into a data format that the system can process. The first step of this conversion process is to obtain the field structure template corresponding to the target protocol from the preset protocol mapping rules based on the protocol type identifier. The field structure template is a protocol description model used to define the position, length, semantics, and nesting relationship between fields in a certain type of protocol. For example, the field structure template of the IPSec protocol may include the ESP header, SPI field, sequence number field, encrypted data area, and authentication data area, while the template of the TLS protocol will include the record layer header, version field, length field, and payload. By calling the field structure template, the system can determine which target format the current data frame should be converted to and establish a structural reference relationship between the original protocol structure and the target format. Once the field structure template is determined, the protocol fields in the original network data frame need to be compared and structurally mapped with the template to construct a field conversion mapping table. This mapping table is a set of logical relationships used to describe which field in the target structure corresponds to a certain field in the original data, and to record how its value is processed, such as truncation, transformation, merging, or replacement. During field comparison, semantic consistency, bit-width correspondence, and field omissions or redundancies caused by protocol differences must be considered. For example, when converting an IPSec structure to a unified data format within the platform, the SPI field in the ESP header needs to be mapped to the "Security Association Identifier" field in the unified format, the sequence number field needs to be retained for subsequent reassembly and sorting, and the encrypted payload field needs to be marked as an "encrypted data block" through mapping, while maintaining the original encrypted structure. If the target template contains fields not included in the source protocol, a default padding or delayed binding strategy can be set in the mapping table. Subsequently, based on the field conversion mapping table, the communication fields in the network data frame are restructured to generate intermediate encapsulated data with a matching structure. Communication fields refer to basic parameters used to identify data exchange relationships, including source address, destination address, port number, session identifier, authentication token, etc., whose forms and positions vary in different protocols. Format refactoring refers to transforming the original protocol structure into a unified format structure through operations such as field rearrangement, field name redefinition, and data structure repackaging, while performing necessary standardization processing on field values. For example, in the TLS protocol, the source address and session ID may reside in different locations at the IP layer and TLS handshake layer, respectively. In the target unified structure, they need to be moved to the unified identifier area in the data frame header, and the protocol-specific session ID is renamed to "unified session identifier" to meet the platform's usage requirements in policy judgment, forwarding control, and other processes. After this process, the generated intermediate encapsulated data has a unified data organization format and has completed the protocol mapping at the field level, providing compatibility assurance for subsequent policy execution.Finally, the second intermediate data needs to be constructed by combining the intermediate encapsulated data with the context information in the first intermediate data. Context information includes, but is not limited to, parameters such as the protocol type, communication direction, security level estimate, timestamp, and path label of the original data frame. This information is not directly reflected in the encapsulated data, but it is of significant reference value for policy evaluation and data reconstruction. When constructing the second intermediate data, the intermediate encapsulated data should be used as the core payload, and the context information should be filled into extended fields of a unified structure to form a structured data object containing the complete protocol structure, communication attributes, and security attributes.

[0024] Step 130: Determine the security processing policy corresponding to the preset policy rule set based on the policy identifier field in the second intermediate data.

[0025] Specifically, in this embodiment, the corresponding security processing policy is further determined based on the policy identifier field in the second intermediate data. This process involves using the policy identifier field as an index to query a preset set of policy rules, and filtering policy entries that match the characteristics of the current data frame based on matching condition fields (such as protocol type, security level, communication direction, etc.). The selected policy entries contain multiple operation instruction parameters, such as protocol conversion requirements, authentication mechanism selection, context binding rules, etc., which are extracted into a set of structured control parameters. This set of parameters will be bound to the data frame, becoming the basis for operation during data reconstruction, and ensuring that subsequent data processing strictly follows the preset security control logic.

[0026] In one optional implementation of this embodiment, the step of determining the security processing policy corresponding to the preset policy rule set based on the policy identifier field in the second intermediate data includes: indexing and retrieving the preset policy rule set based on the policy identifier field of the second intermediate data to obtain the policy rule entries corresponding to the policy identifier field; determining the policy rule group that meets the conditions by comparing the matching condition field of the policy rule entries with the protocol context field of the second intermediate data; generating a corresponding policy parameter set based on the processing instruction field in the policy rule group; and generating a security processing policy containing a control instruction set and processing rules by binding the policy parameter set with the second intermediate data.

[0027] Specifically, in this embodiment, during the security protocol interaction process of the switch, the policy identifier field included in the second intermediate data is used to identify the policy category or processing path associated with the data frame. Its purpose is to establish a connection between the data and the preset security policy system, thereby introducing a control basis for subsequent data processing. The first step in policy matching is to index and retrieve the preset policy rule set using the policy identifier field. The policy rule set is a predefined policy database in the system, where each policy rule entry consists of a unique identifier, a matching condition field, a processing instruction field, and a constraint attribute field. The indexing and retrieval process is based on the mapping relationship between policy identifiers and rule identifiers, locating the rule entry in the database that matches the identifier. This operation not only improves retrieval efficiency but also limits the scope of policy matching, ensuring that only logically related rules are subsequently compared, avoiding unnecessary resource overhead for the system. After indexing the policy rule entries, it is necessary to further compare the matching condition field of the rule entry with the protocol context field in the second intermediate data. The protocol context field is a set of fields characterizing the network behavior and security attributes of a data frame, including protocol type, source address, destination address, security level, communication direction, port number, encryption flag, etc., used to determine whether the current data frame meets the conditions for a specific policy to take effect. The condition comparison process uses a logical judgment algorithm to compare whether the parameter ranges defined in the condition fields are satisfied with the actual values ​​in the context fields. For example, a policy rule entry might define the conditions as protocol=TLS and security_level≥3 direction=outbound, while the actual fields in the data frame are protocol=TLS, security_level=4, and direction=outbound, in which case a match is determined. During the condition comparison process, the system can use priority sorting or intra-group scoring mechanisms to select the most suitable policy combination when multiple rules are satisfied, ultimately determining the policy rule group that meets the conditions. After obtaining the policy rule group, the processing instruction field needs to be extracted from it to generate the corresponding policy parameter set. The processing instruction field is a control field in the rule entry used to describe the execution behavior. It defines the type of action and parameter configuration to be taken for the matched data, such as specifying which encryption algorithm to use, whether to enable authentication, whether to bind a context token, and whether to restrict the path direction. The policy parameter set is a parameter object that has been standardized and structured from these instruction fields. It includes parameters such as encryption algorithm identifier (e.g., AES-256-GCM), key length, authentication method (e.g., HMAC-SHA256), session duration, and maximum payload size. After the policy parameter set is constructed, it needs to be bound to the second intermediate data to form a complete security processing policy.The binding process inserts or appends a set of parameters to the control field of the second intermediate data, making the data structure not only contain protocol content and context information, but also policy instructions that drive subsequent processing behavior. The final generated security processing policy is a structured object containing a set of control instructions and processing rules, and can be directly invoked during protocol data reconstruction and path scheduling.

[0028] Step 140: Reconstruct the original content in the second intermediate data into a target data frame that conforms to the target protocol format according to the security processing strategy.

[0029] Specifically, according to the selected security processing strategy, the content of the second intermediate data is reconstructed into a target data frame conforming to the target protocol format. This process first calls the corresponding field structure standard according to the protocol template definition in the policy control parameters, and then reorganizes the format using the previously extracted communication fields and data payload information. At this stage, key security attribute fields in the data packet structure (such as encryption tags, authentication codes, etc.) need to be embedded into the corresponding positions according to the target protocol requirements, and the encapsulation, arrangement, and identification update of the original content are completed. Finally, the generated target data frame not only meets the target protocol requirements in structure, but also has been bound with security attributes and context information, and can be directly used for cross-device transmission and subsequent verification.

[0030] In one optional implementation of this embodiment, the step of reconstructing the original content in the second intermediate data into a target data frame conforming to the target protocol format according to the security processing strategy includes: obtaining the corresponding target protocol structure template according to the control instruction set of the security processing strategy; generating a protocol structure mapping table that matches the target protocol structure template by extracting and formatting the protocol context fields; reorganizing and formatting the communication fields and data payload fields of the second intermediate data according to the protocol structure mapping table to generate an initial data frame in the target protocol format; and generating a target data frame containing a complete protocol structure and security configuration by adding the security processing parameter set of the security processing strategy to the initial data frame.

[0031] Specifically, in this embodiment, after the policy selection is completed in the switch security protocol interaction method, the data structure needs to be reconstructed according to the control instruction set in the policy to make it conform to the requirements of the target protocol. The control instruction set is an executable configuration set extracted from the security processing policy, containing core parameters such as protocol version, structure format, field definition, encryption policy, and authentication options. The system first needs to obtain the target protocol structure template from the preset protocol template library according to the protocol definition information in the control instruction set. This template describes the data frame structure layout of the target protocol, including the order, name, length, value type, and nesting relationship of the fields. For example, in the structure template of the TLS protocol, it will include a record layer header, version number field, length field, and encrypted payload field, and further define the offset and alignment of each field. The purpose of this operation is to provide a structural reference for subsequent data filling, ensuring that the reconstructed data frame has protocol consistency and processing compatibility.

[0032] After obtaining the target protocol structure template, the protocol context fields in the second intermediate data need to be extracted and format-mapped to generate a protocol structure mapping table that matches the template. The protocol context fields are a set of communication-related fields obtained through previous identification and parsing, including source / destination addresses, port numbers, authentication flags, session identifiers, security levels, etc., used to characterize the communication behavior and security background of data packets. Field extraction involves finding the field's label and offset position to extract relevant fields from the second intermediate data. Format mapping involves renaming and formatting these extracted fields according to the target protocol's field rules. For example, the "session_id" field in the original structure might correspond to "client_random" or "session_ticket" in the TLS record layer after mapping. The mapping table is a key-value pair that explicitly indicates which field in the second intermediate data will be mapped to the corresponding field position in the target protocol structure, along with conversion rules such as byte order changes and encoding method modifications. The purpose of generating this mapping table is to provide a one-to-one operation template for field reassembly, ensuring that the final constructed data frame structurally matches the target protocol. Subsequently, based on the protocol structure mapping table, the communication fields and data payload fields in the second intermediate data are reassembled and formatted to construct the initial data frame in the target protocol format. Field reassembly refers to reordering, merging, or splitting the original fields according to the field correspondence given in the mapping table, and rewriting them in the byte structure required by the target protocol. For example, the source address and port number in the original intermediate data may exist in the IP header and ESP header in IPSec, but in the TLS target format, they need to be encapsulated as part of the "ClientHello" message. In addition, the data payload field, i.e., the original encrypted content or the business data to be encapsulated, also needs to be placed in the payload area of ​​the target structure, and length identifiers, padding bytes, or flag bits are added according to protocol requirements. To ensure that the initial data frame has all the control attributes required for secure transmission, the security processing parameter set provided in the security processing strategy needs to be added to the initial data frame. The security processing parameter set includes encryption algorithm identifiers, key pointers, authentication mechanism selection, encryption domain range, replay protection parameters, etc., which are used to indicate the secure operation mode that the data frame should adopt in the protocol stack. The addition process writes security processing parameters to the corresponding positions based on the reserved or extended fields defined in the target protocol structure template. For example, in the TLS protocol, authentication algorithm and key information can be filled into the CipherSuite area of ​​the handshake message, while in IPSec, the SPI field and authentication code can be inserted into the ESP header. Ultimately, the generated data frame is not only structurally complete but also embeds all the security control information required by the policy, becoming a target data frame containing protocol format, context information, and security policy configuration. This data frame can be directly used for encrypted transmission and secure processing between switches, supporting a unified protocol interaction mechanism.

[0033] Step 150: Based on the security level field and communication direction of the target data frame, filter the path through the trusted path list to determine the target interaction path.

[0034] Specifically, based on the security level field and communication direction carried by the target data frame, the process filters the target interaction path from multiple available paths. This process first takes the target data frame as input, parses its security level and direction parameters, and matches it with a set of paths from the trusted path list that meet the current conditions. Then, based on a path trust score table, each path is scored in terms of encryption capability, error rate, overload status, and other dimensions to generate a path evaluation structure. Finally, a sorting algorithm selects the path with the best score and binds it to the target data frame, ensuring efficient and reliable data transmission between switches while meeting security policies. Thus, the entire interaction method forms a complete closed loop across five stages: data source identification, structure transformation, policy invocation, data reconstruction, and path selection.

[0035] In one optional implementation of this embodiment, the step of determining the target interaction path by filtering paths through a trusted path list based on the security level field and communication direction of the target data frame includes: filtering a preset trusted path list based on the security level field and communication direction of the target data frame to obtain a set of candidate paths that meet the field constraints; extracting trustworthiness indicators from each path node in the candidate path set to generate a corresponding path trustworthiness parameter table; performing joint calculations based on the path trustworthiness parameter table and the protocol context field in the target data frame to generate a path evaluation structure; and prioritizing the path evaluation structure to determine the target interaction path with the highest priority.

[0036] Specifically, in this embodiment, in the switch security protocol interaction method, after the target data frame is generated, to ensure its secure forwarding in the network, the most suitable data forwarding path needs to be selected from the trusted path list in the system based on the security level field and communication direction carried by the data frame. The trusted path list is a set of path resources maintained by the network control system. Each path consists of a group of consecutive switching nodes and includes indicators such as path identifier, link security attributes, bandwidth status, current load, and historical behavior records. The conditional filtering process compares the security level and communication direction specified in the target data frame with the attributes of each path in the trusted path list. The security level field represents the security requirement level of the data, with common levels such as low (Level 1), medium (Level 2), and high (Level 3). The communication direction field indicates whether the data is inbound, outbound, or bidirectional. Only those paths whose security attributes meet or exceed the security level requirements of the target data frame, and whose path direction is consistent with the target direction, will be retained as a candidate path set for subsequent selection. For example, when the target data frame has a security level of Level 3 and the communication direction is outbound, the system only retains path node combinations that have encrypted links, auditing capabilities, and are outbound reachable. After obtaining the path candidate set, to further evaluate path security, it is necessary to extract trustworthiness indicators for each path node in the set and generate a path trustworthiness parameter table. Trustworthiness indicators are a set of parameters that quantify the security and stability of network paths, including node encryption capabilities, authentication support types, key negotiation history, failure rate, average latency, bit error rate, and node hardware security level. These indicators can be dynamically extracted from the device status database of the switching nodes, security module status monitoring logs, or from long-term operational statistics. The system organizes each extracted indicator into a parameter table according to a preset format. This table has a two-dimensional structure, where each row represents a path and each column corresponds to a trustworthiness attribute, forming the path trustworthiness parameter table. After the parameter table is constructed, it also needs to be jointly calculated with the protocol context fields contained in the target data frame to generate a path evaluation structure. The protocol context field includes the data frame's protocol type, security attributes, service category, source address, and port information, representing the data frame's network behavior intent. The joint computation process involves defining a scoring function that maps path trustworthiness parameters to corresponding requirements in the protocol context field and calculates a score for each path based on its weight. For example, a target data frame using the TLS protocol is highly sensitive to latency, so the latency weight in the path evaluation function may be higher than other metrics; if the data frame requires strong authentication, the authentication strength score will have a greater weight than the encryption method. The final generated path evaluation structure contains each path, its corresponding comprehensive score field, and evaluation dimension labels, expressing the path's suitability for the given security requirements.After path scoring is completed, the system prioritizes the path evaluation structure, selecting the path with the highest score as the target interaction path. The ranking mechanism employs descending score order or a multi-dimensional weighted priority queue to ensure that paths meeting the constraints of the target data frame are optimal in terms of functional matching and performance. For example, if two paths have combined scores of 0.92 and 0.87 respectively, the system will prioritize the path with a score of 0.92 and bind its number to the target data frame, ensuring that subsequent forwarding operations are performed according to this path. This process not only enhances the intelligence of path scheduling but also provides stable, reliable, and policy-consistent guarantees for the secure flow of data between multiple switches through a refined evaluation mechanism.

[0037] In one optional implementation of this embodiment, real-time communication performance indicators of each node are extracted from the dynamic path performance library based on the path node identifier of the target interaction path; a dynamic path evaluation parameter table is generated by jointly weighting the real-time communication performance indicators with the security level field of the target data frame; based on the dynamic path evaluation parameter table, the node sequence of the target interaction path is fragmented and reassembled to generate an optimized path topology; based on the optimized path topology, the transmitted data packets are segmented and hashed to generate data verification vectors bound to each link fragment, and the data verification vectors are embedded in the extended header field of the target data frame.

[0038] Specifically, in this embodiment, during the interaction of the switch security protocol, optimizing path selection requires not only static security level matching but also dynamic adjustment of the link structure based on real-time communication performance indicators to achieve optimal transmission quality while meeting security requirements. The primary task to achieve this goal is to extract the real-time communication performance indicators of each node from the dynamic path performance database based on the path node identifiers of the selected target interaction path. The dynamic path performance database is an online monitoring data source maintained in the network control system, recording the latest latency, packet loss rate, bandwidth utilization, and jitter parameters of each node in the link and its connected links. By matching and retrieving the target path node identifiers, all switch nodes involved in the path can be quickly located, and the real-time performance values ​​directly associated with these nodes can be read from the performance database. After obtaining the performance indicators of all path nodes, these real-time communication performance indicators need to be jointly weighted with the security level field of the target data frame to generate a dynamic path evaluation parameter table. The security level field represents the level of security requirements of the data frame for the link; for example, level 3 indicates the highest level of encryption and authentication protection, while level 1 is the lowest level. Joint weighting calculation, by setting weight coefficients for different indicators, normalizes performance indicators and security levels, and then weights and sums them to form a comprehensive score. For example, the scoring formula might set security level to account for 50%, latency for 30%, and packet loss rate for 20%. The comprehensive score for path A→B→C could then be calculated as: 0.5 × security level normalized value + 0.3 × (1 - latency normalized value) + 0.2 × (1 - packet loss rate normalized value). This joint evaluation considers both security and transmission efficiency, ensuring that data packets with higher security requirements are preferentially transmitted on links with lower latency and less packet loss, thereby improving overall network performance and security. After completing the construction of the dynamic path evaluation parameter table, the node sequence of the target interaction path is further fragmented and reassembled to generate an optimized path topology. Link fragmentation and reassembly is a method of splitting a long path into several segments so that different strategies or routing optimizations can be applied to different segments. Based on the scores of each link segment in the evaluation parameter table, the system can divide the path into segments with similar performance or security. For example, it can merge segments with low latency and high bandwidth into one group, and separate segments with high packet loss rates and low encryption capabilities into another group, forming a more granular path topology. This process not only isolates performance bottlenecks but also allows for the application of differentiated encryption or authentication strategies to different segments. For instance, if the packet loss rate of the B→C link segment exceeds a threshold, this segment is fragmented separately, and segmented retry or higher-level authentication mechanisms are used in subsequent transmissions to prevent the loss of data packets in this segment from affecting overall communication. After constructing the optimized path topology, the transmitted data packets need to be segmented and hashed based on this structure to generate data verification vectors bound to each link segment, and these data verification vectors are then embedded into the extended header field of the target data frame.Segment hash tagging refers to the process of calculating a unique verification tag for each fragment link using a cryptographic hash algorithm (such as HMAC-SHA256) on the fragment data and fragment index. This tag is used to verify the fragment integrity and authenticity of its origin when data arrives at the next switching node, thereby quickly detecting and locating problems in the event of packet loss or tampering. Embedding extended header fields by inserting "fragment index – hash tag" pairs into the expandable space of the original protocol header ensures protocol compatibility while enhancing security verification capabilities. During data flow, whenever a segment arrives at the associated link node, it can be quickly verified by comparing the built-in hash tag with the tag value calculated by the node itself. If a discrepancy is found, retransmission or path switching can be initiated immediately, thus ensuring high reliability and security in multi-switch environments.

[0039] According to the switch security protocol interaction method provided in this application, the received network data frames are identified by protocol type, and first intermediate data is generated based on the identified protocol type. Based on the protocol type identifier of the first intermediate data, the format of the network data frames is converted using protocol mapping rules to generate second intermediate data. A security processing policy corresponding to a preset policy rule set is determined based on the policy identifier field of the second intermediate data. The original content of the second intermediate data is reconstructed into a target data frame conforming to the target protocol format according to the security processing policy. Based on the security level field and communication direction of the target data frame, a path is filtered using a trusted path list to determine the target interaction path. This application method can dynamically filter trusted interaction paths based on the protocol type and security level field of the target data frame, realizing controllable data transmission under secure protocol collaboration between switches.

[0040] Figure 2 This application provides a switch security protocol interaction device, which can be used to implement the switch security protocol interaction method in the foregoing embodiments. Figure 2 As shown, the security protocol interaction device of this switch mainly includes: The identification module 10 is used to identify the protocol type of the received network data frames and generate first intermediate data based on the identified protocol type. The conversion module 20 is used to convert the format of the network data frame according to the protocol type identifier of the first intermediate data and through the protocol mapping rules to generate the second intermediate data; The determination module 30 is used to determine the security processing policy corresponding to the preset policy rule set based on the policy identifier field in the second intermediate data; The reconstruction module 40 is used to reconstruct the original content in the second intermediate data into a target data frame that conforms to the target protocol format according to the security processing strategy. The filtering module 50 is used to filter paths based on the security level field and communication direction of the target data frame through a list of trusted paths to determine the target interaction path.

[0041] In one optional implementation of this embodiment, the identification module is specifically used to: extract feature fields from the received network data frames to generate a set of protocol parameters corresponding to the protocol identification; obtain the corresponding protocol type identifier by matching the protocol feature fields of the protocol parameter set with a preset protocol fingerprint rule base; parse the communication fields of the network data frames according to the protocol type identifier to extract context data; and construct first intermediate data based on the protocol type identifier and the context data.

[0042] In an optional implementation of this embodiment, the conversion module is specifically used to: obtain the field structure template of the corresponding target protocol from the preset protocol mapping rules according to the protocol type identifier of the first intermediate data; determine the field conversion mapping table by comparing and mapping the protocol fields of the network data frame with the field structure template; reorganize the communication fields of the network data frame according to the field conversion mapping table to generate intermediate encapsulated data with matching structure; and construct the second intermediate data according to the context information of the intermediate encapsulated data and the first intermediate data.

[0043] In one optional implementation of this embodiment, the determining module is specifically used to: index and retrieve a preset policy rule set based on the policy identifier field of the second intermediate data to obtain a policy rule entry corresponding to the policy identifier field; determine a policy rule group that meets the conditions by comparing the matching condition field of the policy rule entry with the protocol context field of the second intermediate data; generate a corresponding policy parameter set based on the processing instruction field in the policy rule group; and generate a security processing policy containing a control instruction set and processing rules by binding the policy parameter set with the second intermediate data.

[0044] In one optional implementation of this embodiment, the reconstruction module is specifically used for: obtaining the corresponding target protocol structure template according to the control instruction set of the security processing strategy; generating a protocol structure mapping table that matches the target protocol structure template by extracting and formatting the protocol context fields; recombining and formatting the communication fields and data payload fields of the second intermediate data according to the protocol structure mapping table to generate an initial data frame in the target protocol format; and generating a target data frame containing a complete protocol structure and security configuration by adding a security processing parameter set of the security processing strategy to the initial data frame.

[0045] In one optional implementation of this embodiment, the filtering module is specifically used to: filter a preset trusted path list based on the security level field and communication direction of the target data frame to obtain a set of path candidates that meet the field constraints; extract trustworthiness indicators from each path node in the path candidate set to generate a corresponding path trustworthiness parameter table; perform joint calculations based on the path trustworthiness parameter table and the protocol context field in the target data frame to generate a path evaluation structure; and sort the path evaluation structure by priority to determine the target interaction path with the highest ranking.

[0046] In an optional embodiment of this invention, the switch security protocol interaction device further includes a generation module. The generation module is specifically configured to: extract real-time communication performance indicators of each node from a dynamic path performance database based on the path node identifiers of the target interaction path; generate a dynamic path evaluation parameter table by performing joint weight calculation on the real-time communication performance indicators and the security level field of the target data frame; perform link fragmentation and reassembly on the node sequence of the target interaction path based on the dynamic path evaluation parameter table to generate an optimized path topology; perform segmented hashing of the transmitted data packets based on the optimized path topology to generate data verification vectors bound to each link fragment, and embed the data verification vectors into the extended header field of the target data frame.

[0047] According to the switch security protocol interaction device provided in this application, the received network data frames are identified by protocol type, and first intermediate data is generated based on the identified protocol type. Based on the protocol type identifier of the first intermediate data, the format of the network data frames is converted using protocol mapping rules to generate second intermediate data. A security processing policy corresponding to a preset policy rule set is determined based on the policy identifier field of the second intermediate data. The original content of the second intermediate data is reconstructed into a target data frame conforming to the target protocol format according to the security processing policy. Based on the security level field and communication direction of the target data frame, a path is filtered using a trusted path list to determine the target interaction path. This application can dynamically filter trusted interaction paths based on the protocol type and security level field of the target data frame, realizing controllable data transmission under secure protocol collaboration between switches.

[0048] According to the scheme provided in this application Figure 3 An electronic device is provided as an embodiment of this application. This electronic device can be used to implement the switch security protocol interaction method in the foregoing embodiments, and mainly includes: The system includes a memory 301, a processor 302, and a computer program 303 stored on the memory 301 and executable on the processor 302. The memory 301 and the processor 302 are communicatively connected. When the processor 302 executes the computer program 303, it implements the switch security protocol interaction method described in the foregoing embodiments. The number of processors can be one or more.

[0049] The memory 301 can be a high-speed random access memory (RAM) or a non-volatile memory, such as a disk storage device. The memory 301 is used to store executable program code, and the processor 302 is coupled to the memory 301.

[0050] Furthermore, embodiments of this application also provide a computer-readable storage medium, which may be disposed in the electronic device described in the above embodiments, and the computer-readable storage medium may be as described above. Figure 3 The memory in the illustrated embodiment.

[0051] The computer-readable storage medium stores a computer program that, when executed by a processor, implements the switch security protocol interaction method described in the foregoing embodiments. Furthermore, the computer-readable storage medium can also be a USB flash drive, external hard drive, read-only memory (ROM), RAM, magnetic disk, or optical disk, or any other medium capable of storing program code.

[0052] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0053] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0054] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A method for security protocol interaction in a switch, characterized in that, include: The received network data frames are identified by protocol type, and the first intermediate data is generated based on the identified protocol type. Based on the protocol type identifier of the first intermediate data, the format of the network data frame is converted according to the protocol mapping rules to generate the second intermediate data; The security processing policy corresponding to the preset policy rule set is determined based on the policy identifier field in the second intermediate data; According to the security processing strategy, the original content in the second intermediate data is reconstructed into a target data frame that conforms to the target protocol format; Based on the security level field and communication direction of the target data frame, the target interaction path is determined by filtering through a list of trusted paths.

2. The switch security protocol interaction method according to claim 1, characterized in that, The step of identifying the protocol type of the received network data frames and generating first intermediate data based on the identified protocol type includes: By extracting feature fields from the received network data frames, a set of protocol parameters corresponding to the protocol identification is generated; By matching the protocol feature fields of the protocol parameter set with a preset protocol fingerprint rule base, the corresponding protocol type identifier is obtained; The communication fields of the network data frame are parsed according to the protocol type identifier to extract context data; The first intermediate data is constructed based on the protocol type identifier and context data.

3. The switch security protocol interaction method according to claim 2, characterized in that, The step of converting the format of the network data frame according to the protocol type identifier of the first intermediate data and generating the second intermediate data through protocol mapping rules includes: Based on the protocol type identifier of the first intermediate data, obtain the field structure template of the corresponding target protocol from the preset protocol mapping rules; A field conversion mapping table is determined by comparing and mapping the protocol fields of the network data frame with the field structure template. The communication fields of the network data frame are reformatted according to the field conversion mapping table to generate intermediate encapsulated data with matching structure. Based on the context information of the intermediate encapsulated data and the first intermediate data, the second intermediate data is constructed.

4. The switch security protocol interaction method according to claim 1, characterized in that, The step of determining the security processing policy corresponding to the preset policy rule set based on the policy identifier field in the second intermediate data includes: Based on the strategy identifier field of the second intermediate data, the preset strategy rule set is indexed and retrieved to obtain the strategy rule entry corresponding to the strategy identifier field; By comparing the matching condition field of the policy rule entry with the protocol context field of the second intermediate data, a policy rule group that meets the conditions is determined. Generate a corresponding set of policy parameters based on the processing instruction fields in the policy rule group; By binding the set of policy parameters with the second intermediate data, a security processing policy containing a set of control instructions and processing rules is generated.

5. The switch security protocol interaction method according to claim 4, characterized in that, The step of reconstructing the original content in the second intermediate data into a target data frame conforming to the target protocol format according to the security processing strategy includes: Obtain the corresponding target protocol structure template according to the control instruction set of the security processing strategy; By extracting fields and mapping formats from the protocol context fields, a protocol structure mapping table that matches the target protocol structure template is generated. According to the protocol structure mapping table, the communication field and data payload field of the second intermediate data are reorganized and format encapsulated to generate an initial data frame in the target protocol format; By adding the security processing parameter set of the security processing strategy to the initial data frame, a target data frame containing a complete protocol structure and security configuration is generated.

6. The switch security protocol interaction method according to claim 1, characterized in that, The step of determining the target interaction path by filtering paths through a trusted path list based on the security level field and communication direction of the target data frame includes: The preset trusted path list is filtered based on the security level field and communication direction of the target data frame to obtain a set of path candidates that meet the constraints of the field. By extracting credibility indicators from each path node in the path candidate set, a corresponding path credibility parameter table is generated. A path evaluation structure is generated by jointly calculating the path reliability parameter table and the protocol context field in the target data frame. The path evaluation structure is prioritized and sorted to determine the target interaction path with the highest priority.

7. The switch security protocol interaction method according to claim 1, characterized in that, The method further includes: Based on the path node identifiers of the target interaction path, extract the real-time communication performance metrics of each node from the dynamic path performance library. A dynamic path evaluation parameter table is generated by jointly weighting the real-time communication performance indicators with the security level field of the target data frame. Based on the dynamic path evaluation parameter table, the node sequence of the target interaction path is subjected to link fragmentation and reorganization to generate an optimized path topology. Based on the optimized path topology, the transmitted data packets are segmented and hashed to generate data verification vectors bound to each link fragment, and the data verification vectors are embedded in the extended header field of the target data frame.

8. A security protocol interaction device for a switch, characterized in that, The switch security protocol interaction device includes: The identification module is used to identify the protocol type of the received network data frames and generate the first intermediate data based on the identified protocol type. The conversion module is used to convert the format of the network data frame according to the protocol type identifier of the first intermediate data and through protocol mapping rules to generate the second intermediate data; The determination module is used to determine the security processing policy corresponding to the preset policy rule set based on the policy identifier field in the second intermediate data; The reconstruction module is used to reconstruct the original content in the second intermediate data into a target data frame that conforms to the target protocol format according to the security processing strategy. The filtering module is used to filter paths based on the security level field and communication direction of the target data frame through a list of trusted paths to determine the target interaction path.

9. An electronic device, characterized in that, Includes memory and processor, of which: The processor is used to execute computer programs stored in the memory; When the processor executes the computer program, it implements the steps in the switch security protocol interaction method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps in the switch security protocol interaction method according to any one of claims 1 to 7.

Images