[go: up one dir, main page]

CN114567478B - Communication method and device - Google Patents

Communication method and device Download PDF

Info

Publication number
CN114567478B
CN114567478B CN202210178583.1A CN202210178583A CN114567478B CN 114567478 B CN114567478 B CN 114567478B CN 202210178583 A CN202210178583 A CN 202210178583A CN 114567478 B CN114567478 B CN 114567478B
Authority
CN
China
Prior art keywords
protocol
parameter set
field
type identifier
network device
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202210178583.1A
Other languages
Chinese (zh)
Other versions
CN114567478A (en
Inventor
余华
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing H3C Technologies Co Ltd
Original Assignee
Beijing H3C Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing H3C Technologies Co Ltd filed Critical Beijing H3C Technologies Co Ltd
Priority to CN202210178583.1A priority Critical patent/CN114567478B/en
Publication of CN114567478A publication Critical patent/CN114567478A/en
Application granted granted Critical
Publication of CN114567478B publication Critical patent/CN114567478B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/162—Implementing security features at a particular protocol layer at the data link layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Small-Scale Networks (AREA)

Abstract

The application provides a communication method and a device, wherein the method comprises the following steps: transmitting a first MKPDU protocol packet to a second network device, the first MKPDU protocol packet including a first extension type parameter set, the first extension type parameter set including a first flexible tag parameter set including a first protocol type identifier that does not require encryption; receiving a second MKPDU protocol message sent by second network equipment; if the second MKPDU protocol packet includes a second flexible tag parameter set and a support field included in the second flexible tag parameter set is a first value, acquiring a second protocol type identifier without encryption from the second flexible tag parameter set; acquiring the same third protocol type identifier from the first protocol type identifier and the second protocol type identifier; and when the data frame message comprises a protocol field carrying the third protocol type identifier, not performing encryption operation on the protocol field carrying the third protocol type identifier.

Description

Communication method and device
Technical Field
The present application relates to the field of communications technologies, and in particular, to a communications method and apparatus.
Background
Links across the Internet (Internet) or across wide area networks are generally considered unsafe, and the use of encryption of the links may increase the security of the transmission.
Currently, the commonly adopted encryption technology is the traditional three-layer encryption technology of Internet security protocol (English: internet Protocol Security, abbreviated as IPsec). However, the conventional IPsec technology lacks hardware resources, so that the line speed forwarding cannot be realized, and the user requirements cannot be satisfied. If an external special encryption machine is used for realizing data encryption, firstly, the cost is too high, secondly, the single-port throughput capacity of the existing network equipment is as high as 10G level or more, and the performance of the encryption machine cannot meet the requirement of forwarding performance.
Media access Control address Security (English: MEDIA ACCESS Control Security, MACsec) defines a data Security communication method in a local area network based on IEEE 802 protocol, and can provide secure MAC layer data transmission and reception service for users. Such as user data encryption, data frame integrity checking, and data source authenticity checking, providing the user with line-speed forwarding of encrypted data, and so forth.
MACsec comprises two part functional entities: one is a MAC Security entity (SecY), and the other is a MAC Security key negotiation entity (english: MAC Security KEY AGREEMENT ENTITY, abbreviated: kaY). SecY is implemented by a hardware chip at the drive level. And the MAC safety forwarding service is respectively provided for the controlled port users on the link ports, and the non-safety service is provided for the non-controlled port users. SecY uses KaY issued security association key (English: secure Association Key, SAK for short) to encrypt the message sent by channel according to SA, and to decrypt and restore the message received by the security channel. And simultaneously, replay protection is carried out according to each SA in the receiving channel.
KaY is implemented in software. And the method is responsible for generating and releasing the secret key, and discovering and establishing a secure channel between devices. SecY is provided with the same SAK for message encryption protection between the end and the end of the security channel. MKPDU protocol messages interacted between KaY entities are differentiated from MACsec-protected data frame messages (MACSEC FRAME) by ETHERNET TYPE =0x88-8 e (multiplexed 802.1x message type, subtype eapol_mka).
The mechanism of the key agreement protocol data unit (English: MACSEC KEY AGREEMENT Protocol Data Unit, MKPDU) or MKPDU protocol message crossing the wide area network in the MACsec key agreement (English: MACSEC KEY AGREEMENT, MKA) session is as follows: MKPDU is a common two-layer protocol message which is not encrypted under any condition based on 802.1 xepol protocol (english: EAP over LANs, chinese: extensible authentication protocol on local area network (english: extensible Authentication Protocol, abbreviated: EAP)), and the protocol type is 888E after the ethernet (ethernet) header, so that the protocol field of the related protocol can be filled in the corresponding position when passing through the intermediate network according to the need. For example, the 802.1Q protocol field of a virtual local area network (English: virtual Local Area Network, VLAN) may be filled directly after the ETH header and before the EAPOL protocol header. In summary, MKPDU protocol messages in the MKA session may traverse the intermediate network.
As shown in fig. 1, fig. 1 is a schematic diagram of a conventional MKPDU protocol packet structure including an 802.1Q protocol field.
After the MKA negotiation is established, when the MAC layer transmits the data frame message, the data frame message is encrypted by a Physical Hardware (PHY) according to an encryption algorithm of the MKA session negotiation. As shown in fig. 2, fig. 2 is a schematic diagram of a conventional encrypted data frame message structure. The encrypted data frame message includes an ETH header and a MAC protocol data unit (english: MAC Protocol Data Unit, abbreviated: MPDU) portion. The MPDU part starts with a MAC Security TAG (English: MAC Security TAG, abbreviated: secTAG) field, and the protocol type is 88E5. The SecTAG field is followed by an encrypted data message and finally an integrity check Value (english: INTEGRITY CHECK Value; ICV for short).
In fig. 2, the protocol fields following the ETH header are all encrypted, for example, 802.1Q protocol fields, etc. After the data frame message is sent out, the information displayed externally is only the destination MAC and source MAC information, and the data frame message cannot be forwarded through the wide area network.
To achieve traversing an intermediate wide area network, an intermediate transmission device must be added before each of the two MACsec devices. Moreover, since the data frame message sent by the MACsec device a does not carry any protocol information, the intermediate transmission device can only receive the data frame message from the Port-based VLAN ID (english: port-base VLAN ID, abbreviated: PVID). The intermediate transmission device marks a vlan and other protocol labels in the data frame message. Before the MACsec equipment B is reached, the intermediate transmission equipment connected with the MACsec equipment B deletes the protocol label and then forwards the protocol label to the MACsec equipment B, otherwise, the physical hardware decrypted by the MACsec equipment B cannot decrypt the data frame message.
In this way, the advantages of the MACsec protocol are reduced to a encryptor-like function. None of the other protocols that are enabled on ports that enable the MACsec protocol can be used properly with intermediate networks. The MACsec protocol also fails to meet the current need for data encryption across links of the internet or across wide area networks.
Disclosure of Invention
In view of the above, the present application provides a communication method and apparatus for solving the problem that a data frame message encrypted by MACsec protocol cannot traverse an intermediate network.
In a first aspect, the present application provides a communication method, the method being applied to a first network device, the method comprising:
Transmitting a first MKPDU protocol packet to a second network device, where the first MKPDU protocol packet includes a first extension type parameter set, where the first extension type parameter set includes a first flexible tag parameter set, and the first flexible tag parameter set includes a first protocol type identifier that does not need encryption;
Receiving a second MKPDU protocol message sent by the second network device;
If the second MKPDU protocol packet includes a second flexible tag parameter set and a support field included in the second flexible tag parameter set is a first value, acquiring a second protocol type identifier without encryption from the second flexible tag parameter set;
acquiring the same third protocol type identifier from the first protocol type identifier and the second protocol type identifier;
and when the data frame message comprises a protocol field carrying the third protocol type identifier, not carrying out encryption operation on the protocol field carrying the third protocol type identifier.
In a second aspect, the present application provides a communications apparatus for application to a first network device, the method comprising:
A sending unit, configured to send a first MKPDU protocol packet to a second network device, where the first MKPDU protocol packet includes a first extension type parameter set, where the first extension type parameter set includes a first flexible tag parameter set, and the first flexible tag parameter set includes a first protocol type identifier that does not need encryption;
a receiving unit, configured to receive a second MKPDU protocol packet sent by the second network device;
A first obtaining unit, configured to obtain, from a second flexible tag parameter set, a second protocol type identifier that does not need to be encrypted if the second MKPDU protocol packet includes the second flexible tag parameter set and a support field included in the second flexible tag parameter set is a first value;
a second obtaining unit, configured to obtain the same third protocol type identifier from the first protocol type identifier and the second protocol type identifier;
And the encryption unit is used for carrying out no encryption operation on the protocol field carrying the third protocol type identifier when the data frame message comprises the protocol field carrying the third protocol type identifier.
In a third aspect, the application provides a network device comprising a processor and a machine-readable storage medium storing machine-executable instructions executable by the processor to cause the processor to perform the method provided by the first aspect of the application.
Therefore, by applying the communication method and the device provided by the application, the first network device sends the first MKPDU protocol message to the second network device, the first MKPDU protocol message comprises a first extension type parameter set, the first extension type parameter set comprises a first flexible tag parameter set, and the first flexible tag parameter set comprises a first protocol type identifier without encryption; the first network equipment receives a second MKPDU protocol message sent by the second network equipment; if the second MKPDU protocol packet includes a second flexible tag parameter set and a support field included in the second flexible tag parameter set is a first value, the first network device obtains a second protocol type identifier without encryption from the second flexible tag parameter set; the first network equipment acquires the same third protocol type identifier from the first protocol type identifier and the second protocol type identifier; when the data frame message includes a protocol field carrying a third protocol type identifier, the first network device does not perform encryption operation on the protocol field carrying the third protocol type identifier.
Thus, if the network devices at both ends support the extension type parameter set and support the flexible label parameter set in the process of performing the MKA negotiation, the protocol type identifiers which are supported by the network devices at both ends and do not need to be encrypted are mutually announced. If the network devices at both ends support the same protocol type identifier without encryption, the same protocol type identifier can not be encrypted any more when the data frame message is sent subsequently. The method realizes that the encrypted data frame message after the MKA negotiation passes can pass through an intermediate network to be forwarded.
Drawings
FIG. 1 is a diagram illustrating a conventional MKPDU protocol packet structure including an 802.1Q protocol field;
FIG. 2 is a schematic diagram of a prior art encrypted data frame message structure;
FIG. 3 is a flow chart of a communication method according to an embodiment of the present application;
FIG. 4 is a schematic diagram of an EAPOL message structure according to an embodiment of the present application;
Fig. 5 is a schematic structural diagram of a MKPDU protocol packet according to an embodiment of the present application, where the packet includes multiple parameter sets;
fig. 6 is a schematic structural diagram of a first extension type parameter set according to an embodiment of the present application;
FIG. 7 is a schematic diagram of a first flexible tag parameter set architecture;
FIG. 8 is a schematic diagram of an encrypted data frame message structure according to an embodiment of the present application;
FIG. 9 is a schematic diagram of another encrypted data frame message structure according to an embodiment of the present application;
fig. 10 is a block diagram of a communication device according to an embodiment of the present application;
Fig. 11 is a hardware structure of a network device according to an embodiment of the present application.
Detailed Description
Reference will now be made in detail to exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, the same numbers in different drawings refer to the same or similar elements, unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with aspects of the application as detailed in the accompanying claims.
The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. As used in this specification and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that the term "and/or" as used herein refers to and encompasses any or all possible combinations of one or more of the corresponding listed items.
It should be understood that although the terms first, second, third, etc. may be used herein to describe various information, these information should not be limited by these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of the application. The word "if" as used herein may be interpreted as "at … …" or "at … …" or "in response to a determination" depending on the context.
The communication method provided by the embodiment of the application is described in detail below. Referring to fig. 3, fig. 3 is a flowchart of a communication method according to an embodiment of the present application. The method is applied to a first network device. The communication method provided by the embodiment of the application can comprise the following steps.
Step 310, a first MKPDU protocol packet is sent to a second network device, where the first MKPDU protocol packet includes a first extension type parameter set, the first extension type parameter set includes a first flexible tag parameter set, and the first flexible tag parameter set includes a first protocol type identifier that does not need encryption;
specifically, the first network device establishes an MKA session with the second network device, and performs MKA negotiation on the MKA session.
And respectively configuring roles of the first network equipment and the second network equipment in the MKA negotiation according to the priorities of the first network equipment and the second network equipment. For example, when the configuration is performed according to the priority, the key service terminal (KEY SERVER) terminal with a high priority is configured, and the key client terminal (KEY CLIENT) terminal with a low priority is configured. In the embodiment of the present application, if the first network device has a higher priority than the second network device, the first network device is KEY SERVER and the second network device is KEY CLIENT.
The first network device serves as KEY SERVER end and generates a first MKPDU protocol message, and the first MKPDU protocol message includes a first extension type parameter set. The first extension type parameter set includes a first flexible tag parameter. The first flexible tag parameter set includes a first protocol type identification supported by the first network device without encryption.
After the first network device generates the first MKPDU protocol packet, the first network device sends the first MKPDU protocol packet to the second network device. After receiving the first MKPDU protocol packet, the second network device obtains the first extension type parameter set from the first extension type parameter set. Then, a first flexible tag parameter set is obtained from the first extension type parameter set. Finally, a first protocol type identification is obtained from the first flexible tag parameter set.
Further, the message format of the first MKPDU protocol message is described in detail below.
The first network equipment generates an EAP protocol message, and encapsulates the EAP protocol through an EAPOL technology to obtain the EAPOL message. EAPOL technology is an encapsulation technology defined by 802.1X protocol and used for carrying EAP protocol messages, and is mainly used for transmitting EAP protocol messages between a client and a server in a local area network.
As shown in fig. 4, fig. 4 is a schematic diagram of an EAPOL packet structure according to an embodiment of the present application. In fig. 4, the EAPOL message includes a Protocol Version (Protocol Version) field, a message type (PACKET TYPE) field, a message Body length (Packet Body Length) field, and a message Body (Packet Body) field (which may be referred to as a first message Body field).
When the value of PACKET TYPE field is 00000101, the EAPOL message is MKPDU protocol message. That is, the first MKPDU protocol packet includes a PACKET TYPE field with a value of 00000101.
Each MKPDU protocol message includes multiple parameter sets carried in a message Body (Packet Body) field. The usage criteria for each parameter set is specified by the MACsec key agreement in ieee802.1x-2010 clause 9, which specifies the encoding of each parameter set.
As shown in fig. 5, fig. 5 is a schematic structural diagram of a MKPDU protocol packet according to an embodiment of the present application, where the packet includes a plurality of parameter sets. In fig. 5, the first parameter set is a Basic parameter set (Basic PARAMETER SET), which always exists, which may be followed by 0 or more parameter sets, and finally an ICV field.
In the embodiment of the present application, the first network device adds a first extended Types (extended Types) parameter set after the basic parameter set. Fig. 6 is a schematic diagram of a first extension type parameter set structure according to an embodiment of the present application, as shown in fig. 6. In fig. 6, the first extension Type parameter set includes a parameter set Type (PARAMETER SET TYPE) field (the value of which is 254), a Version (Version) field, a Type (Type) field (which Type field may be referred to as a first Type field), a Length (Length) field, and a Packet Body field (which may be referred to as a second Packet Body field).
Wherein, the value of the version field is 1, which is used for marking the version of the extension type protocol as 1; the value of the type field is 2 (this value may be referred to as a second value) for representing the type value of the first flexible Tag (Smart Tag) parameter set in the first extended type parameter set; a length field for indicating an overall length of the first extension type parameter set; the message body field is used for carrying message content; when the value of the type field is 2, the message format in the message body field is the first flexible tag parameter set format.
It should be noted that, the type value of the first flexible tag parameter set in the first extension type parameter is 2. The first flexible tag parameter set is used for explaining that when the network equipment encrypts the data frame message to be encrypted after the MKA negotiation is passed, the protocol field to be reserved does not encrypt. That is, the Sec TAG field is added after which protocol field.
Fig. 7 is a schematic diagram of a first flexible tag parameter set according to an embodiment of the present application, as shown in fig. 7. In fig. 7, the first flexible tag parameter set includes a parameter set type (PARAMETER SET TYPE) field whose value is 8, a Support field whose value includes 0 or 1, a Length field, and a Protocol List (Protocol List) field.
Wherein the value of the support field is 1 (the value may be referred to as a first value), which indicates that the network device supports the first flexible tag parameter set, and at this time, a first protocol type identifier (for example, a protocol type identifier without encryption is 0x8100, and the protocol type identifier characterizes that encryption operation on the VLAN 802.1Q protocol field is not required) supported by the network device is filled in the protocol list field; the value of the support field is 0, indicating that the network device does not support the first flexible tag parameter set, and at this time, the protocol list field is empty.
Further, as can be seen from the foregoing description of the message format of the first MKPDU protocol message, in the embodiment of the present application, the first MKPDU protocol message includes a first message Body field (i.e., packet Body field), and the first message Body field carries the first extension type parameter set.
The first extension Type parameter set includes a first Type field (i.e., type field) and a second message Body field (i.e., packet Body field) that carries the first flexible label parameter set when the value of the first Type field is a second value (i.e., the value of the Type field is 2).
The first flexible label parameter set includes a Support field (i.e., support field) and a Protocol List field (i.e., protocol List field), the Protocol List field carrying a first Protocol type identification when the Support field has a first value (i.e., support field has a value of 1).
In one example, the first protocol type supported by the first network device without encryption may specifically include: 802.1Q protocol, IP protocol of VLAN. At this time, the first network device populates the protocol list field with the two protocol type identifications.
It will be appreciated that a protocol type identification occupies an 8-bit (ottet) byte within a protocol list field.
In the embodiment of the application, if the first network device does not support the first extension type parameter set and the first flexible tag parameter set, the first network device initiates the MKA negotiation with the second network device according to the existing MACsec protocol.
Step 320, receiving a second MKPDU protocol packet sent by the second network device;
Specifically, according to the description of step 310, the first network device sends a first MKPDU protocol packet to the second network device. After receiving the first MKPDU protocol packet, the second network device obtains the first extension type parameter set from the first packet body field.
The second network device identifies whether itself supports the first extension type parameter set. If the second network device supports the first extension type parameter set, the second network device obtains a type field from the first extension type set and identifies a value of the type field. If the value of the type field is 2, the value of the type field indicates that the first flexible tag parameter set is stored in the second message body field.
The second network device obtains a first flexible label parameter set from within a second message body field. The second network device identifies the value of the support field. If the value of the support field is a first value, namely 1, the second network device obtains a first protocol type identifier which is supported by the first network device and does not need encryption from the protocol list field.
After the second network device acquires the first protocol type identifier, identifying whether the second network device supports the protocol type corresponding to the first protocol type identifier. It is understood that the number of first protocol type identifiers may be plural, and each first protocol type identifier corresponds to one protocol type.
The second network device identifies whether each protocol type identifier is supported by itself. And the second network equipment generates a second MKPDU protocol message according to the condition that the second network equipment supports the protocol type.
It is understood that the message structure of the second MKPDU protocol message is the same as that of the first MKPDU protocol message, and will not be repeated here.
For example, the first protocol type identifier corresponds to a protocol type of A, B, C. The second network device determines that the self-supporting protocol type is specifically A, B, D. At this point, the second network device generates a second flexible tag parameter set. The second flexible tag parameter set includes a support field and a protocol list field. Similarly, the value of the support field is a first value, namely 1; the protocol list field includes a second protocol type identification, A, B, D protocol type identifications, supported by the second network device without encryption.
In the above example, the case where the second network device itself supports the protocol type partially the same as the first network device itself supports the protocol type is described. In practical applications, it may also occur that the second network device itself supports a protocol type that is the same as or different from the first network device itself.
For example, the second network device determines that the self-supporting protocol type is specifically A, B, C; or the second network device determines that the self-supporting protocol type is specifically E, F, G.
Similarly, A, B, C protocol type identification; or E, F, G protocol type identification may also be carried in the protocol list field.
The second network device carries a second flexible tag parameter set in a second extension type set. The second set of extension types includes a type field and a third message body field (the third message body field being identical to the second message body field). The second network device sets the type field to a second value, namely 2, which indicates that the second flexible tag parameter set is stored in the third message body field.
The second network device carries the second set of extension types in a fourth message body field (the fourth message body field being identical to the first message body field), whereby the second network device generates a second MKPDU protocol message.
It will be appreciated that the second MKPDU protocol packet, the second extension type set, and the second flexible tag parameter set include other fields that are not mentioned, and the values of the fields may be set according to the existing protocol specification and the description of the first extension type set and the first flexible tag parameter set in the foregoing step 210, which are not repeated herein.
After the second network device generates the second MKPDU protocol packet, the second network device sends the second MKPDU protocol packet to the first network device.
The first network device receives a second MKPDU protocol message sent by the second network device.
Step 330, if the second MKPDU protocol packet includes a second flexible tag parameter set and a support field included in the second flexible tag parameter set is a first value, acquiring a second protocol type identifier that does not need encryption from the second flexible tag parameter set;
specifically, according to the description of step 320, after the first network device receives the second MKPDU protocol packet, the second extension type parameter set is first obtained from the fourth packet body field.
After the first network device obtains the second extension type parameter set, it is determined that the second network device also supports the same parameter set type (e.g., the value of the parameter set type field is 254). The first network device obtains a type field from the second extended type parameter set and identifies a value of the type field. If the value of the type field is 2, the second flexible label parameter set stored in the third message body field is indicated.
The first network device obtains a second flexible label parameter set from within the third message body field. The first network device identifies the value of the support field. If the value of the supporting field is a first value, namely 1, the first network device acquires a second protocol type identifier which is supported by the second network device and does not need encryption from the protocol list field.
Step 340, acquiring the same third protocol type identifier from the first protocol type identifier and the second protocol type identifier;
specifically, according to the description of step 330, after the first network device obtains the second protocol type identifier supported by the second network device and without encryption, the first protocol type identifier is compared with the second protocol type identifier.
And acquiring the same third protocol type identifier from the first protocol type identifier and the second protocol type identifier by the first network equipment.
In one example, the protocol type corresponding to the first protocol type identifier is A, B, C, the protocol type corresponding to the second protocol type identifier is A, B, D, and the first network device obtains the same third protocol type identifier, specifically, the protocol type identifier corresponding to the protocol type A, B.
In another example, the protocol type corresponding to the first protocol type identifier is A, B, C, the protocol type corresponding to the second protocol type identifier is A, B, C, and the first network device obtains the same third protocol type identifier, specifically, the protocol type identifier corresponding to the protocol type A, B, C.
In another example, the first protocol type identifier corresponds to a protocol type A, B, C, the second protocol type identifier corresponds to a protocol type E, F, G, and the first network device does not acquire the same third protocol type identifier.
Step 350, when the data frame message includes a protocol field carrying the third protocol type identifier, performing no encryption operation on the protocol field carrying the third protocol type identifier;
Specifically, according to the description of step 340, after the first network device obtains the third protocol type identifier and after the MKA negotiation has been completed between the first network device and the second network device, the first network device may perform interaction of the data frame message with the second network device.
When the data frame message includes a protocol field carrying a third protocol type identifier, the first network device does not perform encryption operation on the protocol field carrying the third protocol type identifier.
In one example, the protocol field of the third protocol type identifier is an 802.1Q protocol type field of the VLAN, and after the first network device encrypts the data frame packet, the encrypted data frame packet is shown in fig. 8. In fig. 8, the first network device encrypts the portion of the VLAN following the 802.1Q protocol type field.
In another example, the protocol field of the third protocol type identifier is an IP protocol type field, and the first network device encrypts the data frame packet (e.g., VXLAN packet) after performing the encryption operation, as shown in fig. 9. In fig. 9, the first network device performs an encryption operation on a portion after the IP protocol type field.
In the embodiment of the application, two-layer protocol fields (802.1Q protocol type field of VLAN) and three-layer protocol fields (IP protocol type field) required for traversing the intermediate network can be reserved in a data frame message in a plaintext manner, and the data content really needing security can be encrypted normally. In this way, MACsec encrypted data frame messages can traverse various intermediate networks.
It should be noted that, if the first network device does not acquire the same third protocol type identifier in step 340, the first network device determines a protocol type that is not commonly supported by the second network device and does not need encryption. That is, if the first network device and the second network device do not successfully negotiate the flexible tag parameter set, the first network device and the second network device encrypt the data frame message according to the existing MACsec protocol when the first network device and the second network device subsequently interact with the data frame message.
After the MKA negotiation is completed between the first network device and the second network device, the first network device may interact with the second network device by using the data frame message. When the data frame message comprises a protocol field carrying a first protocol type identifier or a second protocol type identifier, the first network device or the second network device encrypts the protocol field carrying the first protocol type identifier or the second protocol type identifier.
For example, the first protocol type corresponding to the first protocol type identifier is a VLAN 802.1Q protocol field, and the second protocol type corresponding to the second protocol column identifier is an IP protocol field.
The data frame message generated by the first network device includes a VLAN802.1Q protocol field, and the VLAN802.1Q protocol field is located after the ETH header, and the first network device performs an encryption operation on a portion located after the ETH header, that is, the encryption operation of the first network device includes the VLAN802.1Q protocol field.
Similarly, the data frame message processed by the second network device includes a VLAN802.1Q protocol field, and after the VLAN802.1Q protocol field is located in the ETH header, the second network device performs an encryption operation on a portion located in the end of the ETH header, that is, the encryption operation of the second network device includes the VLAN802.1Q protocol field.
Therefore, by applying the communication method provided by the application, the first network device sends a first MKPDU protocol message to the second network device, the first MKPDU protocol message comprises a first extension type parameter set, the first extension type parameter set comprises a first flexible tag parameter set, and the first flexible tag parameter set comprises a first protocol type identifier without encryption; the first network equipment receives a second MKPDU protocol message sent by the second network equipment; if the second MKPDU protocol packet includes a second flexible tag parameter set and a support field included in the second flexible tag parameter set is a first value, the first network device obtains a second protocol type identifier without encryption from the second flexible tag parameter set; the first network equipment acquires the same third protocol type identifier from the first protocol type identifier and the second protocol type identifier; when the data frame message includes a protocol field carrying a third protocol type identifier, the first network device does not perform encryption operation on the protocol field carrying the third protocol type identifier.
Thus, if the network devices at both ends support the extension type parameter set and support the flexible label parameter set in the process of performing the MKA negotiation, the protocol type identifiers which are supported by the network devices at both ends and do not need to be encrypted are mutually announced. If the network devices at both ends support the same protocol type identifier without encryption, the same protocol type identifier can not be encrypted any more when the data frame message is sent subsequently. The method realizes that the encrypted data frame message after the MKA negotiation passes can pass through an intermediate network to be forwarded.
Optionally, before step 310 of the embodiment of the present application, a step of receiving, by the first network device, a configuration instruction input by a user is further included.
Specifically, the user issues a configuration instruction to the first network device by inputting a command line to the first network device. The configuration instruction comprises a protocol field which is not needed to be encrypted in the data frame message and is used for bearing the first protocol type identifier described in the previous step.
After the first network device receives the configuration instruction, in the process of MKA negotiation between the first network device and the second network device to be started, a first extension type parameter set is carried in a first MKPDU protocol message, a first flexible tag parameter set is carried in the first extension type parameter set, and a first protocol type identifier without encryption is carried in the first flexible tag parameter set.
For example, the command line is specifically: MACSEC SMARTTAG [ XXX|YY ]
Wherein, the configuration in "[ ]" designates the protocol field without encryption in the data frame message. Currently, encryption operations have been implemented in the portion following the VLAN 802.1Q protocol field or the IP protocol field. In practical application, other protocol fields can be set according to the expansion of the requirement, and a plurality of protocol fields can be matched in a configuration mode.
Optionally, in the embodiment of the present application, after the first network device receives the second MKPDU protocol packet, the case where the second MKPDU protocol packet does not include the second extension type parameter set is further included.
Specifically, in the process of identifying whether the second network device supports the first extension type parameter set, if the second network device does not support the first extension type parameter set, the second network device skips the parameter set which cannot be identified when processing according to the ieee802.1x-2010 protocol. That is, the second network device does not recognize and process the first extension type parameter set.
It is appreciated that the second network device, when generating the second MKPDU protocol packet, since it does not support the first extension type parameter set, the second MKPDU protocol packet does not include the second extension type parameter set (e.g., the value of the parameter set type field is 254) with the same field value as the first extension type parameter set.
After the first network device receives the second MKPDU protocol packet, if the second extension type parameter set is not obtained from the fourth packet body field, the first network device determines that the second network device cannot support the same parameter set type (for example, the value of the parameter set type field is 254).
At this time, the first network device negotiates other key parameters with the second network device according to the existing MKA negotiation rule, and does not negotiate the flexible tag parameter set.
Optionally, in the embodiment of the present application, after the first network device receives the second MKPDU protocol packet, the case that the support field included in the second flexible tag parameter set is a third value is further included.
Specifically, if the second MKPDU protocol packet includes the second flexible tag parameter set and the support field included in the second flexible tag parameter set is a third value (i.e., the value of the support field is 0), the first network device determines that the second network device does not support the flexible tag parameter set, that is, the second network device does not support performing encryption operation on the protocol type.
At this time, if one of the two end network devices does not support the flexible tag parameter set, the two end network devices perform encryption operation on the portion after the ETH header according to the specification of the existing MACsec protocol.
After the MKA negotiation is completed between the first network device and the second network device, the first network device may interact with the second network device by using the data frame message.
When the data frame message comprises a protocol field carrying a first protocol type identifier, the first network device encrypts the protocol field carrying the first protocol type identifier.
For example, the data frame packet includes a VLAN 802.1Q protocol field or an IP protocol field, and the VLAN 802.1Q protocol field or the IP protocol field are located after the ETH header, and the first network device encrypts the portion after the ETH header, that is, the encryption operation of the first network device includes the VLAN 802.1Q protocol field or the IP protocol field.
Based on the same inventive concept, the embodiment of the application also provides a communication device corresponding to the communication method. Referring to fig. 10, fig. 10 is a communication apparatus provided in an embodiment of the present application, where the apparatus is applied to a first network device, and the method includes:
A sending unit 1010, configured to send a first MKPDU protocol packet to a second network device, where the first MKPDU protocol packet includes a first extension type parameter set, where the first extension type parameter set includes a first flexible tag parameter set, and the first flexible tag parameter set includes a first protocol type identifier that does not need encryption;
A receiving unit 1020, configured to receive a second MKPDU protocol packet sent by the second network device;
A first obtaining unit 1030, configured to obtain, if the second MKPDU protocol packet includes a second flexible tag parameter set and a support field included in the second flexible tag parameter set is a first value, a second protocol type identifier that does not need to be encrypted from the second flexible tag parameter set;
a second obtaining unit 1040, configured to obtain the same third protocol type identifier from the first protocol type identifier and the second protocol type identifier;
And an encryption unit 1050, configured to, when the data frame packet includes a protocol field carrying the third protocol type identifier, not perform an encryption operation on the protocol field carrying the third protocol type identifier.
Optionally, the receiving unit 1020 is further configured to receive a configuration instruction input by a user, where the configuration instruction includes a protocol field in the data frame packet that does not need to be encrypted, and the protocol field is used to carry the first protocol type identifier.
Optionally, the first MKPDU protocol packet includes a first packet body field, where the first packet body field carries the first extension type parameter set;
The first extension type parameter set comprises a first type field and a second message body field, and when the value of the first type field is a second value, the second message body field carries the first flexible label parameter set;
the first flexible tag parameter set includes a support field and a protocol list field, the protocol list field carrying the first protocol type identifier when the value of the support field is the first value.
Optionally, the apparatus further comprises: a determining unit (not shown in the figure) configured to determine that negotiation of the flexible tag parameter set is not performed in the MKA negotiation process if the second MKPDU protocol packet does not include the second extension type parameter set.
Optionally, the encryption unit 1050 is further configured to, if the second MKPDU protocol packet includes the second flexible tag parameter set and the support field included in the second flexible tag parameter set is a third value, encrypt the protocol field that carries the first protocol type identifier when the data frame packet includes the protocol field that carries the first protocol type identifier.
Therefore, by applying the communication device provided by the application, the first network device sends the first MKPDU protocol message to the second network device, the first MKPDU protocol message comprises a first extension type parameter set, the first extension type parameter set comprises a first flexible tag parameter set, and the first flexible tag parameter set comprises a first protocol type identifier without encryption; the first network equipment receives a second MKPDU protocol message sent by the second network equipment; if the second MKPDU protocol packet includes a second flexible tag parameter set and a support field included in the second flexible tag parameter set is a first value, the first network device obtains a second protocol type identifier without encryption from the second flexible tag parameter set; the first network equipment acquires the same third protocol type identifier from the first protocol type identifier and the second protocol type identifier; when the data frame message includes a protocol field carrying a third protocol type identifier, the first network device does not perform encryption operation on the protocol field carrying the third protocol type identifier.
Thus, if the network devices at both ends support the extension type parameter set and support the flexible label parameter set in the process of performing the MKA negotiation, the protocol type identifiers which are supported by the network devices at both ends and do not need to be encrypted are mutually announced. If the network devices at both ends support the same protocol type identifier without encryption, the same protocol type identifier can not be encrypted any more when the data frame message is sent subsequently. The method realizes that the encrypted data frame message after the MKA negotiation passes can pass through an intermediate network to be forwarded.
Based on the same inventive concept, an embodiment of the present application also provides a network device, as shown in fig. 11, including a processor 1110, a transceiver 1120, and a machine-readable storage medium 1130, where the machine-readable storage medium 1130 stores machine executable instructions capable of being executed by the processor 1110, the processor 1110 is caused to perform a communication method provided by the embodiment of the present application. The communication apparatus shown in fig. 10 may be implemented by using the hardware structure of the network device shown in fig. 11.
The computer readable storage medium 1130 may include a random access Memory (e.g., random Access Memory, or simply, RAM) or a nonvolatile Memory (e.g., NVM), such as at least one magnetic disk Memory. Optionally, the computer readable storage medium 1130 may also be at least one storage device located remotely from the aforementioned processor 1110.
The processor 1110 may be a general-purpose processor, including a central processing unit (english: central Processing Unit, abbreviated as CPU), a network processor (english: network Processor, abbreviated as NP), and the like; it may also be a digital signal Processor (English: DIGITAL SIGNAL Processor; DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable gate array (Field-Programmable GATE ARRAY; FPGA), or other Programmable logic device, discrete gate or transistor logic device, or discrete hardware component.
In an embodiment of the present application, processor 1110, by reading machine-executable instructions stored in machine-readable storage medium 1130, is caused by the machine-executable instructions to implement processor 1110 itself and invoke transceiver 1120 to perform the communication methods described in the previous embodiments of the present application.
Additionally, embodiments of the present application provide a machine-readable storage medium 1130, the machine-readable storage medium 1130 storing machine-executable instructions that, when invoked and executed by the processor 1110, cause the processor 1110 itself, as well as the invoking transceiver 1120, to perform the communication methods described in the foregoing embodiments of the present application.
The implementation process of the functions and roles of each unit in the above device is specifically shown in the implementation process of the corresponding steps in the above method, and will not be described herein again.
For the device embodiments, reference is made to the description of the method embodiments for the relevant points, since they essentially correspond to the method embodiments. The apparatus embodiments described above are merely illustrative, wherein the elements illustrated as separate elements may or may not be physically separate, and the elements shown as elements may or may not be physical elements, may be located in one place, or may be distributed over a plurality of network elements. Some or all of the modules may be selected according to actual needs to achieve the purposes of the present application. Those of ordinary skill in the art will understand and implement the present application without undue burden.
For the communication device and the machine-readable storage medium embodiments, since the method content involved is substantially similar to the method embodiments described above, the description is relatively simple, and reference will only be made to part of the description of the method embodiments.
The foregoing description of the preferred embodiments of the application is not intended to be limiting, but rather to enable any modification, equivalent replacement, improvement or the like to be made within the spirit and principles of the application.

Claims (10)

1. A method of communication, the method being applied to a first network device, the method comprising:
Transmitting a first MKPDU protocol packet to a second network device, where the first MKPDU protocol packet includes a first extension type parameter set, where the first extension type parameter set includes a first flexible tag parameter set, and the first flexible tag parameter set includes a first protocol type identifier that does not need encryption;
Receiving a second MKPDU protocol message sent by the second network device;
If the second MKPDU protocol packet includes a second flexible tag parameter set and a support field included in the second flexible tag parameter set is a first value, acquiring a second protocol type identifier without encryption from the second flexible tag parameter set;
Acquiring a third protocol type identifier of the same protocol type identifier from the first protocol type identifier and the second protocol type identifier;
When the data frame message comprises a protocol field carrying the third protocol type identifier, not carrying out encryption operation on the protocol field carrying the third protocol type identifier;
wherein the number of the protocol type identifiers can be one or more, and each protocol type identifier corresponds to one protocol type supported by the network device.
2. The method of claim 1, wherein prior to sending the first MKPDU protocol packet to the second network device, the method further comprises:
And receiving a configuration instruction input by a user, wherein the configuration instruction comprises a protocol field which does not need encryption in a data frame message, and the protocol field is used for bearing the first protocol type identifier.
3. The method of claim 1, wherein the first MKPDU protocol message includes a first message body field that carries the first extension type parameter set;
The first extension type parameter set comprises a first type field and a second message body field, and when the value of the first type field is a second value, the second message body field carries the first flexible label parameter set;
the first flexible tag parameter set includes a support field and a protocol list field, the protocol list field carrying the first protocol type identifier when the value of the support field is the first value.
4. The method of claim 1, wherein after receiving the second MKPDU protocol packet sent by the second network device, the method further comprises:
if the second MKPDU protocol packet does not include the second extension type parameter set, determining that negotiation of the flexible tag parameter set is not performed in the MKA negotiation process.
5. The method of claim 1, wherein after receiving the second MKPDU protocol packet sent by the second network device, the method further comprises:
And if the second MKPDU protocol packet includes the second flexible tag parameter set and the support field included in the second flexible tag parameter set is a third value, when the data frame packet includes a protocol field carrying the first protocol type identifier, performing encryption operation on the protocol field carrying the first protocol type identifier.
6. A communication apparatus, the apparatus being applied to a first network device, the apparatus comprising:
A sending unit, configured to send a first MKPDU protocol packet to a second network device, where the first MKPDU protocol packet includes a first extension type parameter set, where the first extension type parameter set includes a first flexible tag parameter set, and the first flexible tag parameter set includes a first protocol type identifier that does not need encryption;
a receiving unit, configured to receive a second MKPDU protocol packet sent by the second network device;
A first obtaining unit, configured to obtain, from a second flexible tag parameter set, a second protocol type identifier that does not need to be encrypted if the second MKPDU protocol packet includes the second flexible tag parameter set and a support field included in the second flexible tag parameter set is a first value;
A second obtaining unit, configured to obtain a third protocol type identifier of the same protocol type identifier from the first protocol type identifier and the second protocol type identifier;
an encryption unit, configured to, when the data frame packet includes a protocol field carrying the third protocol type identifier, not perform encryption operation on the protocol field carrying the third protocol type identifier;
wherein the number of the protocol type identifiers can be one or more, and each protocol type identifier corresponds to one protocol type supported by the network device.
7. The apparatus of claim 6, wherein the receiving unit is further configured to receive a configuration instruction input by a user, the configuration instruction including a protocol field in a data frame message that does not need encryption, the protocol field being configured to carry the first protocol type identifier.
8. The apparatus of claim 6, wherein the first MKPDU protocol message includes a first message body field that carries the first extension type parameter set;
The first extension type parameter set comprises a first type field and a second message body field, and when the value of the first type field is a second value, the second message body field carries the first flexible label parameter set;
the first flexible tag parameter set includes a support field and a protocol list field, the protocol list field carrying the first protocol type identifier when the value of the support field is the first value.
9. The apparatus of claim 6, wherein the apparatus further comprises:
and the determining unit is configured to determine that negotiation of the flexible tag parameter set is not performed in the MKA negotiation process if the second MKPDU protocol packet does not include the second extension type parameter set.
10. The apparatus of claim 6, wherein the encryption unit is further configured to encrypt a protocol field carrying the first protocol type identifier when the data frame message includes a protocol field carrying the first protocol type identifier if the second MKPDU protocol message includes the second flexible label parameter set and the support field included in the second flexible label parameter set is a third value.
CN202210178583.1A 2022-02-24 2022-02-24 Communication method and device Active CN114567478B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210178583.1A CN114567478B (en) 2022-02-24 2022-02-24 Communication method and device

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210178583.1A CN114567478B (en) 2022-02-24 2022-02-24 Communication method and device

Publications (2)

Publication Number Publication Date
CN114567478A CN114567478A (en) 2022-05-31
CN114567478B true CN114567478B (en) 2024-07-02

Family

ID=81716724

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210178583.1A Active CN114567478B (en) 2022-02-24 2022-02-24 Communication method and device

Country Status (1)

Country Link
CN (1) CN114567478B (en)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TWI857587B (en) * 2023-04-27 2024-10-01 瑞昱半導體股份有限公司 Communication device and method for accelerating device discovery and identification in a communication environment

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101471923A (en) * 2007-12-27 2009-07-01 华为技术有限公司 Method, equipment and system for sending protocol message and identifying protocol message type
CN110858822A (en) * 2018-08-23 2020-03-03 北京华为数字技术有限公司 Media access control security protocol message transmission method and related device

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070226483A1 (en) * 2006-03-24 2007-09-27 Dennis Cox System and method for storing and/or transmitting emulated network flows
CN112910637B (en) * 2016-11-26 2022-04-22 华为技术有限公司 System, method and device for MKA negotiation between devices
CN112953834A (en) * 2016-12-23 2021-06-11 华为技术有限公司 Network area division method, network equipment and system
US20180302269A1 (en) * 2017-04-17 2018-10-18 Hewlett Packard Enterprise Development Lp Failover in a Media Access Control Security Capable Device
US10601960B2 (en) * 2018-02-14 2020-03-24 Eingot Llc Zero-knowledge environment based networking engine
US20190386824A1 (en) * 2018-06-13 2019-12-19 Hewlett Packard Enterprise Development Lp Failover in a media access control security capabale device
CN110912859B (en) * 2018-09-17 2021-12-14 华为技术有限公司 Method for sending message, method for receiving message and network device
CN113286202A (en) * 2021-05-19 2021-08-20 中山亿联智能科技有限公司 Set top box network program customization method based on http protocol

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101471923A (en) * 2007-12-27 2009-07-01 华为技术有限公司 Method, equipment and system for sending protocol message and identifying protocol message type
CN110858822A (en) * 2018-08-23 2020-03-03 北京华为数字技术有限公司 Media access control security protocol message transmission method and related device

Also Published As

Publication number Publication date
CN114567478A (en) 2022-05-31

Similar Documents

Publication Publication Date Title
CN103747499B (en) Method and apparatus for common control protocol for wired and wireless nodes
US7853691B2 (en) Method and system for securing a network utilizing IPsec and MACsec protocols
CN110650076B (en) VXLAN implementation method, network equipment and communication system
US20050223111A1 (en) Secure, standards-based communications across a wide-area network
WO2012026855A1 (en) Methods and arrangements for secure communication over an ip network
US9137216B2 (en) Session layer data security
US7644187B2 (en) Internet protocol based encryptor/decryptor two stage bypass device
CN104205764A (en) Frame passing based on ethertype
US11595367B2 (en) Selectively disclosing content of data center interconnect encrypted links
CN114567478B (en) Communication method and device
CN114760093B (en) Communication method and device
US11652910B2 (en) Data transmission method, device, and system
EP4436109A1 (en) Key distribution over ip/udp
US7680115B2 (en) Internet protocol based encryptor/decryptor bypass device
US20230246959A1 (en) Security for communication protocols
CN115766063B (en) Data transmission method, device, equipment and medium
WO2023179174A1 (en) Message transmission method and related device
CN120151086A (en) Communication method and device
CN118827570A (en) A flow scheduling method, device and medium
CN115278660A (en) Access authentication method, device and system
CN101527904A (en) Method and device for generating messages
JPH10190704A (en) Ciphering method, decoding method, ciphering device and decoding device for data

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant