CN114567478A

CN114567478A - Communication method and device

Info

Publication number: CN114567478A
Application number: CN202210178583.1A
Authority: CN
Inventors: 余华
Original assignee: Beijing H3C Technologies Co Ltd
Current assignee: Beijing H3C Technologies Co Ltd
Priority date: 2022-02-24
Filing date: 2022-02-24
Publication date: 2022-05-31
Anticipated expiration: 2042-02-24
Also published as: CN114567478B

Abstract

The application provides a communication method and a device, and the method comprises the following steps: sending a first MKPDU protocol message to a second network device, wherein the first MKPDU protocol message comprises a first extended type parameter set, the first extended type parameter set comprises a first flexible label parameter set, and the first flexible label parameter set comprises a first protocol type identifier which does not need encryption; receiving a second MKPDU protocol message sent by second network equipment; if the second MKPDU protocol message comprises a second flexible label parameter set and a support field included by the second flexible label parameter set is a first value, acquiring a second protocol type identifier which does not need to be encrypted from the second flexible label 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 the protocol field carrying the third protocol type identifier, carrying out no 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 communication method and apparatus.

Background

Links across the Internet (Internet) or links across wide area networks are generally considered insecure, and the use of encryption for the links may improve the security of the transmission.

At present, the commonly adopted encryption technology is a traditional Internet Protocol Security (IPsec) three-layer encryption technology. However, the traditional IPsec technology lacks hardware resources, cannot implement line-speed forwarding, and cannot meet user requirements. 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 above, and the performance of the encryption machine cannot meet the requirement of forwarding performance.

Media Access Control (MAC) Security defines a secure communication method for data in a local area network based on IEEE802 protocol, and can provide secure MAC layer data transmission and reception services for users. For example, user data encryption, data frame integrity checking and data source authenticity checking, providing line-speed forwarding of encrypted data for the user, and so forth.

MACsec comprises two functional entities: one is a MAC Security Entity (SecY), and the other is a MAC Security Key Agreement Entity (hereinafter, referred to as MAC Security Key Agreement Entity, KaY). SecY is implemented by a hardware chip at the drive level. And the MAC safety forwarding service is respectively provided for controlled port users and the non-controlled port users on the link ports. SecY uses a Security Association Key (SAK) issued by KaY to encrypt the message sent by the channel according to SA, and decrypt and restore the message received by the Secure channel. While replay protection is performed on a per SA basis on the receive channel.

KaY are implemented in software. And the system is responsible for generating and issuing keys and discovering and establishing a secure channel between devices. SecY is provided with the same SAK for message encryption protection from end to end of the secure channel. KaY the MKPDU protocol message interacted between entities is distinguished from the MACsec protected data Frame message (MACsec Frame) by the Ethernet Type being 0x88-8e (multiplexing 802.1x message Type, subtype EAPOL _ MKA).

The mechanism of passing through the wide area network by the Key Agreement Protocol Data Unit (MKPDU) or MKPDU Protocol message in the MACsec Key Agreement (MKA) session is as follows: the MKPDU is based on 802.1XEAPOL Protocol (english: Extensible Authentication Protocol (EAP) over LANs, chinese: Extensible EAP over lan), and is a common two-layer Protocol packet that is not encrypted under any circumstances, and the Protocol type is 888E after the ethernet (ETH, for short) header, so that the Protocol field of the relevant Protocol can be filled in the corresponding position as needed when passing through the intermediate network. For example, the 802.1Q protocol field of a Virtual Local Area Network (VLAN) can be directly filled in the back of the ETH header and in front of the EAPOL protocol header. In summary, the 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 message structure including 802.1Q protocol fields.

After the MKA negotiation is established, when the MAC layer transmits the data frame message, the data frame message is encrypted through 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 structure of a data frame message after encryption in the prior art. The encrypted Data frame message includes an ETH header and an MAC Protocol Data Unit (MPDU for short) portion. The MPDU portion begins with a MAC Security TAG (hereinafter referred to as "MAC Security TAG") field and the protocol type is 88E 5. The SecTAG field is followed by the encrypted data message and finally by the Integrity Check Value (ICV).

In fig. 2, the protocol fields following the ETH header are all encrypted, e.g., 802.1Q protocol fields, etc. After the data frame message is sent out, the externally displayed information is only the destination MAC and source MAC information, and the data frame message cannot be forwarded through a wide area network.

To traverse the 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 a Port-based VLAN ID (abbreviated as PVID). And the intermediate transmission equipment marks protocol labels such as vlan and the like in the data frame message. Before the MAC sec device B is reached, the intermediate transmission device connected with the MACsec device B deletes the protocol label and forwards the protocol label to the MACsec device B, otherwise, the physical hardware decrypted by the MACsec device B cannot decrypt the data frame message.

In this manner, the advantages of the MACsec protocol are reduced to function like an encryptor. None of the other protocols enabled on the MACsec protocol enabled ports can be used normally with an intermediate network. 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 this, the present application provides a communication method and apparatus for solving the problem that the MACsec protocol encrypted data frame message cannot traverse the intermediate network.

In a first aspect, the present application provides a communication method, which is applied to a first network device, and includes:

sending a first MKPDU protocol message to a second network device, wherein the first MKPDU protocol message comprises a first extended type parameter set, the first extended type parameter set comprises a first flexible label parameter set, and the first flexible label parameter set comprises a first protocol type identifier which does not need encryption;

receiving a second MKPDU protocol message sent by the second network equipment;

if the second MKPDU protocol message comprises a second flexible label parameter set and a support field included by the second flexible label parameter set is a first value, acquiring a second protocol type identifier which does not need to be encrypted from the second flexible label parameter set;

acquiring a third protocol type identifier which is the same as the first protocol type identifier from the second protocol type identifier;

and when the data frame message comprises the protocol field bearing the third protocol type identifier, carrying out no encryption operation on the protocol field bearing the third protocol type identifier.

In a second aspect, the present application provides a communication apparatus, which is applied to a first network device, and the method includes:

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 extended type parameter set, the first extended 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 to be encrypted;

a receiving unit, configured to receive a second MKPDU protocol packet sent by the second network device;

a first obtaining unit, configured to obtain a second protocol type identifier that does not need to be encrypted from a second flexible label parameter set if the second MKPDU protocol packet includes the second flexible label parameter set and a support field included in the second flexible label parameter set is a first value;

a second obtaining unit, configured to obtain a third protocol type identifier that is the same as the first protocol type identifier and the second protocol type identifier;

and the encryption unit is used for not carrying out encryption operation on the protocol field bearing the third protocol type identifier when the data frame message comprises the protocol field bearing the third protocol type identifier.

In a third aspect, the present application provides a network device comprising a processor and a machine-readable storage medium storing machine-executable instructions executable by the processor, the processor being caused by the machine-executable instructions to perform the method provided by the first aspect of the present application.

Therefore, by applying the communication method and apparatus provided by the present application, a first network device sends a first MKPDU protocol packet to a second network device, where the first MKPDU protocol packet includes a first extended type parameter set, the first extended 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 to be encrypted; the first network equipment receives a second MKPDU protocol message sent by the second network equipment; if the second MKPDU protocol message comprises a second flexible label parameter set and a support field included by the second flexible label parameter set is a first value, the first network equipment acquires a second protocol type identifier which does not need to be encrypted from the second flexible label 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; and when the data frame message comprises a protocol field carrying the third protocol type identifier, the first network equipment does not carry out encryption operation on the protocol field carrying the third protocol type identifier.

Thus, if the network devices at both ends support the extended type parameter set and the flexible tag parameter set in the process of performing the MKA negotiation, they notify each other of the protocol type identifiers that are supported by each other and do not need to be encrypted. If the network devices at both ends support the same protocol type identifier without encryption, the same protocol type identifier may not be encrypted any more when the data frame message is sent later. The encrypted data frame message after the MKA negotiation is passed can pass through the intermediate network to be forwarded.

Drawings

Fig. 1 is a schematic diagram of a conventional MKPDU protocol message structure including 802.1Q protocol fields;

fig. 2 is a schematic diagram of a structure of a data frame message after encryption in the prior art;

fig. 3 is a flowchart of a communication method provided in an embodiment of the present application;

fig. 4 is a schematic diagram of an EAPOL message structure provided in the embodiment of the present application;

fig. 5 is a schematic diagram illustrating an MKPDU protocol message including a plurality of parameter sets according to an embodiment of the present application;

fig. 6 is a schematic structural diagram of a first extended type parameter set according to an embodiment of the present application;

FIG. 7 is a diagram of a first flexible tag parameter set structure;

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 provided in the embodiment of the present application;

fig. 10 is a block diagram of a communication apparatus 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 the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent 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 certain aspects of the present application, as detailed in the appended 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 application 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 should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the corresponding listed items.

It is to be understood that although the terms first, second, third, etc. may be used herein to describe various information, such information should not be limited to 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 present application. The word "if" as used herein may be interpreted as "at … …" or "when … …" or "in response to a determination", depending on the context.

The following describes the communication method provided in the embodiments of the present application in detail. Referring to fig. 3, fig. 3 is a flowchart of a communication method according to an embodiment of the present disclosure. 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, sending a first MKPDU protocol packet to a second network device, where the first MKPDU protocol packet includes a first extended type parameter set, the first extended 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 to be encrypted;

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 respective priorities of the first network equipment and the second network equipment. For example, when the configuration is performed according to the priority, the one with the higher priority is configured as a key server (key server) side, and the one with the lower priority is configured as a key client (key client) side. In this embodiment of the present application, if the priority of the first network device is higher than that of the second network device, the first network device is a key server side, and the second network device is a key client side.

The first network equipment serves as a key server end and generates a first MKPDU protocol message, wherein the first MKPDU protocol message comprises a first expansion type parameter set. The first extended type parameter set includes a first flexible tag parameter. The first set of flexible tag parameters includes a first protocol type identification supported by the first network device without encryption.

And after generating the first MKPDU protocol message, the first network equipment sends the first MKPDU protocol message to the second network equipment. After receiving the first MKPDU protocol message, the second network equipment acquires a first extended type parameter set from the first MKPDU protocol message. Then, a first flexible tag parameter set is obtained from the first extension type parameter set. And finally, acquiring a first protocol type identifier from the first flexible label parameter set.

Further, the following describes in detail the message format of the first MKPDU protocol message.

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 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 message structure provided in the embodiment of the present application. In fig. 4, the EAPOL Packet includes a Protocol Version (Protocol Version) field, a Packet Type (Packet Type) field, a Packet Body Length (Packet Body Length) field, and a Packet Body (Packet Body) field (which may be referred to as a first Packet Body field).

When the value of the Packet Type field is 00000101, the EAPOL message is represented as an MKPDU protocol message. That is, the value of the Packet Type field included in the first MKPDU protocol Packet is 00000101.

Each MKPDU protocol message includes a plurality of parameter sets, which are carried in a Body of a message (Packet Body) field. The standard of use for each parameter set is specified by the MACsec key protocol in article 9 of ieee802.1x-2010, the term specifying the encoding of each parameter set.

As shown in fig. 5, fig. 5 is a schematic diagram illustrating an MKPDU protocol message provided in this embodiment of the present application, which includes a plurality of parameter set structures. In fig. 5, the first Parameter Set is the Basic Parameter Set (Basic Parameter Set), which always exists, which may be followed by 0 or more Parameter sets, and finally the ICV field.

In this embodiment, the first network device adds a first extended type (extended Types) parameter set after the basic parameter set. As shown in fig. 6, fig. 6 is a schematic structural diagram of a first extended type parameter set according to an embodiment of the present application. In fig. 6, the first extended Type Parameter Set includes a Parameter Set Type (Parameter Set Type) field (the value of the Parameter Set Type field is 254), a Version (Version) field, a Type (Type) field (the Type Body field may be referred to as a first Type field), a Length (Length) field, and a Packet Body field (the Packet Body field 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 extended type protocol as 1; the type field has a value of 2 (this value may be referred to as a second value) for indicating 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 extended type parameter set; the message body field is used for carrying message contents; when the value of the type field is 2, which indicates the first flexible tag parameter set type, the format of the packet in the packet 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 label parameter set is used for explaining that after the MKA negotiation is passed, when the data frame message to be encrypted is encrypted, the protocol field needing to be reserved is not encrypted. I.e. after which protocol field the Sec TAG field is added.

As shown in fig. 7, fig. 7 is a schematic structural diagram of a first flexible tag parameter set according to an embodiment of the present application. In fig. 7, the first flexible tag Parameter Set includes a Parameter Set Type (Parameter Set Type) field (the value of the Parameter Set Type field is 8), a Support (Support) field (the value of the Support field includes 0 or 1), a Length (Length) field, and a Protocol List (Protocol List) field.

The value of the support field is 1 (this 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, the protocol list field is filled with a first protocol type identifier that is supported by the network device and does not need to be encrypted (for example, the protocol type identifier that does not need to be encrypted is 0x8100, and this protocol type identifier represents that an encryption operation does not need to be performed on the VLAN802.1Q protocol field); the value of the support field is 0, which indicates that the network device does not support the first set of flexible tag parameters, 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., a Packet Body field), and the first message Body field carries the first extended type parameter set.

The first extended Type parameter set includes a first Type field (i.e., Type field) and a second Packet Body field (i.e., Packet Body field), and the second Packet Body field carries the first flexible tag 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 tag parameter set includes a Support field (i.e., a Support field) and a Protocol List field (i.e., a Protocol List field), and the Protocol List field carries a first Protocol type identifier when a value of the Support field is a first value (i.e., a value of the Support field is 1).

In one example, the first protocol type supported by the first network device without encryption may specifically include: VLAN802.1Q protocol, IP protocol. At this time, the first network device fills the two protocol type identifiers into the protocol list field.

It will be appreciated that a protocol type identifier occupies an 8-bit (octet) byte within the protocol list field.

In this embodiment of the present application, if the first network device does not support the first extended type parameter set and the first flexible tag parameter set, the first network device initiates an MKA negotiation with the second network device according to the existing MACsec protocol.

Step 320, receiving a second MKPDU protocol message sent by the second network device;

specifically, as described in step 310, the first network device sends a first MKPDU protocol message to the second network device. After receiving the first MKPDU protocol message, the second network device first obtains the first extended type parameter set from the first message body field.

The second network device identifies whether it supports the first extended type parameter set. If the second network device supports the first extended type parameter set, the second network device obtains the type field from the first extended type set and identifies the value of the type field. If the value of the type field is 2, the first flexible label parameter set is stored in the second message body field.

The second network device obtains the first flexible label parameter set from the second message body field. The second network device identifies a value of the support field. And if the value of the support field is a first value, namely 1, the second network equipment acquires the first protocol type identifier which is supported by the first network equipment and does not need to be encrypted from the protocol list field.

And after acquiring the first protocol type identifier, the second network equipment identifies whether the second network equipment supports the protocol type corresponding to the first protocol type identifier. It is understood that the first protocol type identifier may be a plurality of first protocol type identifiers, and each first protocol type identifier corresponds to one protocol type.

The second network equipment identifies whether the second network equipment supports the protocol type corresponding to each protocol type identification. And the second network equipment generates a second MKPDU protocol message according to the situation of self-supporting protocol types.

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 protocol type corresponding to the first protocol type identifier is specifically A, B, C. The second network device determines that it supports a protocol type specifically A, B, D. At this point, the second network device generates a second set of flexible tag parameters. 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 supported by the second network device without encryption, i.e., the A, B, D protocol type identification.

In the above example, the second network device itself supporting the same protocol type as the first network device itself supporting the same protocol type is taken as an example for explanation. In practical applications, the second network device may support a protocol of the same type as or different from the first network device.

For example, the second network device determines that its own supported protocol type is specifically A, B, C; alternatively, the second network device determines that it supports a protocol type specifically E, F, G.

Similarly, A, B, C protocol type identification; alternatively, the E, F, G protocol type identification may also be carried in the protocol list field.

The second network device carries a second set of flexible tag parameters in a second set of extension types. The second extended type set includes a type field and a third packet body field (the third packet body field is the same as the second packet body field). And the second network device sets the type field to be a second value, namely 2, which indicates that the second flexible label parameter set is stored in the third message body field.

The second network device carries the second extension type set in a fourth packet body field (the fourth packet body field is the same as the first packet body field), so that the second network device generates a second MKPDU protocol packet.

It is understood that the aforementioned other fields included in the second MKPDU protocol message, the second extension type set, and the second flexible tag parameter set may set the values of the fields according to the existing protocol specification and the description of the first extension type set and the first flexible tag parameter set in the aforementioned step 210, and will not be repeated here.

And after the second network equipment generates a second MKPDU protocol message, sending the second MKPDU protocol message to the first network equipment.

And the first network equipment receives a second MKPDU protocol message sent by the second network equipment.

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 to be encrypted from the second flexible tag parameter set;

specifically, according to the description of step 320, after receiving the second MKPDU protocol packet, the first network device first obtains the second extended type parameter set from the fourth packet body field.

After obtaining the second extended type parameter set, the first network device determines 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 the type field from the second extended type parameter set and identifies a value of the type field. And if the value of the type field is 2, the second flexible label parameter set is stored in the third message body field.

The first network device obtains a second flexible tag parameter set from the third packet body field. The first network device identifies a value of the support field. And if the value of the support field is a first value, namely 1, the first network equipment acquires a second protocol type identifier which is supported by the second network equipment and does not need to be encrypted from the protocol list field.

Step 340, obtaining a third protocol type identifier which is the same as the first protocol type identifier from the second protocol type identifier;

specifically, according to the description in step 330, after obtaining the second protocol type identifier that is supported by the second network device and does not need to be encrypted, the first network device compares the first protocol type identifier with the second protocol type identifier.

And the first network equipment acquires the same third protocol type identifier from the first protocol type identifier and the second protocol type identifier.

In an 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, which is 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, which is 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 of A, B, C, the second protocol type identifier corresponds to a protocol type of E, F, G, and the first network device does not obtain the same third protocol type identifier.

Step 350, when the data frame message includes the protocol field bearing the third protocol type identifier, not performing encryption operation on the protocol field bearing the third protocol type identifier;

specifically, according to the description in step 340, after the first network device obtains the third protocol type identifier and the MKA negotiation between the first network device and the second network device is completed, the first network device may interact with the second network device through the data frame packet.

And when the data frame message comprises a protocol field carrying the third protocol type identifier, the first network equipment does not carry out encryption operation on the protocol field carrying the third protocol type identifier.

In an example, the protocol field identified by the third protocol type is an802.1Q protocol type field of the VLAN, and after the first network device encrypts the data frame message, the encrypted data frame message is as shown in fig. 8. In fig. 8, the first network device performs an encryption operation on a portion of the VLAN following the 802.1Q protocol type field.

In another example, the protocol field identified by the third protocol type is an IP protocol type field, and after the first network device performs an encryption operation on a data frame message (e.g., a VXLAN message), the encrypted data frame message is as shown in fig. 9. In fig. 9, the first network device performs an encryption operation on a portion following the IP protocol type field.

In the embodiment of the present application, both the two-layer protocol field (the 802.1Q protocol type field of the VLAN) and the three-layer protocol field (the IP protocol type field) required for traversing the intermediate network may be retained in the data frame message in a plaintext manner, and the data content really required for security may be normally encrypted. Thus, the MACsec encrypted data frame message can traverse various intermediate networks.

It should be noted that, if the first network device does not obtain the same third protocol type identifier in step 340, the first network device determines that there is no protocol type that is supported by the second network device and does not need to be encrypted. That is, if the first network device and the second network device do not negotiate the flexible tag parameter set successfully, the first network device and the second network device perform an encryption operation on the data frame packet according to the existing MACsec protocol when the data frame packet is subsequently exchanged.

After the MKA negotiation between the first network device and the second network device is completed, the first network device may interact with the second network device through the data frame messages. 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 carries out encryption operation on 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 VLAN802.1Q protocol field, and the second protocol type corresponding to the second protocol queue identifier is an IP protocol field.

Then, the data frame message generated by the first network device includes the VLAN802.1Q protocol field, and after the VLAN802.1Q protocol field is located in the ETH header, the first network device performs an encryption operation on a portion 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 when the VLAN802.1Q protocol field is located behind the ETH header, the second network device performs an encryption operation on a portion behind 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 present application, a first network device sends a first MKPDU protocol message to a second network device, where the first MKPDU protocol message includes a first extended type parameter set, the first extended 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; the first network equipment receives a second MKPDU protocol message sent by the second network equipment; if the second MKPDU protocol message comprises a second flexible label parameter set and a support field included by the second flexible label parameter set is a first value, the first network equipment acquires a second protocol type identifier which does not need to be encrypted from the second flexible label 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; and when the data frame message comprises a protocol field carrying the third protocol type identifier, the first network equipment does not carry out encryption operation on the protocol field carrying the third protocol type identifier.

Thus, if the network devices at both ends support the extended type parameter set and the flexible tag parameter set in the process of performing the MKA negotiation, they notify each other of the protocol type identifiers that are supported by each other and do not need to be encrypted. If the network devices at both ends support the same protocol type identifier without encryption, the same protocol type identifier may not be encrypted any more when the data frame message is sent later. The encrypted data frame message after the MKA negotiation can pass through the intermediate network to be forwarded.

Optionally, before step 310 in this 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 does not need to be encrypted in the data frame message, and the protocol field is used for carrying 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 expansion type parameter set is carried in the first MKPDU protocol message, a first flexible label parameter set is carried in the first expansion type parameter set, and a first protocol type identifier which does not need encryption is carried in the first flexible label parameter set.

For example, the command line is specifically: macsec smarttag [ XXX | YY ]

Wherein, the [ ]' is provided with a protocol field which is in the specified data frame message and does not need to be encrypted. Currently, encryption operations are implemented in the part following the VLAN802.1Q protocol field or following the IP protocol field. In practical application, other protocol fields can be set according to requirement extension, and a plurality of protocol fields can be configured and matched.

Optionally, in this embodiment of the present application, after receiving the second MKPDU protocol packet, the first network device further includes a case that the second MKPDU protocol packet does not include the second extended type parameter set.

Specifically, in the process of identifying whether the second network device supports the first extended type parameter set, if the second network device does not support the first extended type parameter set, according to the ieee802.1x-2010 protocol, the second network device skips the parameter set that cannot be identified during processing. That is, the second network device does not identify and process the first extended type parameter set.

It is to be understood that, when the second MKPDU protocol message is generated, the second network device does not include the second extended type parameter set with the same field value as the first extended type parameter set (for example, the parameter set type field has a value of 254), since the second network device does not support the first extended type parameter set by itself.

After the first network device receives the second MKPDU protocol packet, if the second extended 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 perform negotiation of the flexible tag parameter set.

Optionally, in this embodiment of the present application, after receiving the second MKPDU protocol packet, the first network device further includes a case that a support field included in the second flexible tag parameter set is a third value.

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 the third value (that is, 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 the protocol type without performing the encryption operation.

At this time, one of the two end network devices does not support the flexible tag parameter set, and both end network devices perform an encryption operation on a portion after the ETH header according to the specification of the existing MACsec protocol.

After the MKA negotiation between the first network device and the second network device is completed, the first network device may interact with the second network device through the data frame messages.

When the data frame message comprises a protocol field carrying the first protocol type identifier, the first network equipment carries out encryption operation on the protocol field carrying the first protocol type identifier.

For example, the data frame message includes a VLAN802.1Q protocol field or an IP protocol field, and after the VLAN802.1Q protocol field or the IP protocol field are both located in the ETH header, the first network device performs an encryption operation on a portion after the ETH header, that is, the encryption operation of the first network device includes the VLAN802.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 this embodiment, 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 extended type parameter set, the first extended 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 to be encrypted;

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 a second protocol type identifier that does not need to be encrypted from a second flexible label parameter set if the second MKPDU protocol packet includes the second flexible label parameter set and a support field included in the second flexible label parameter set is a first value;

a second obtaining unit 1040, configured to obtain a third protocol type identifier that is the same as the first protocol type identifier and the second protocol type identifier;

an encrypting unit 1050, configured to not encrypt the protocol field carrying the third protocol type identifier when the data frame packet includes 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 that does not need to be encrypted in a data frame packet, 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 extended type parameter set;

the first extended type parameter set comprises a first type field and a second packet body field, and when the value of the first type field is a second value, the second packet body field bears the first flexible label parameter set;

the first flexible tag parameter set comprises a support field and a protocol list field, and when the value of the support field is the first value, the protocol list field carries the first protocol type identifier.

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 extended 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 a support field included in the second flexible tag parameter set is a third value, perform an encryption operation on the protocol field carrying the first protocol type identifier when the data frame packet includes the protocol field carrying the first protocol type identifier.

Therefore, by applying the communication apparatus provided in the present application, a first network device sends a first MKPDU protocol message to a second network device, where the first MKPDU protocol message includes a first extended type parameter set, the first extended 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; the first network equipment receives a second MKPDU protocol message sent by the second network equipment; if the second MKPDU protocol message comprises a second flexible label parameter set and a support field included by the second flexible label parameter set is a first value, the first network equipment acquires a second protocol type identifier which does not need to be encrypted from the second flexible label 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; and when the data frame message comprises a protocol field carrying the third protocol type identifier, the first network equipment does not carry out encryption operation on the protocol field carrying the third protocol type identifier.

In this way, if the network devices at both ends support the extended type parameter set and the flexible tag parameter set during the MKA negotiation process, they advertise the protocol type identifiers that are supported by them and do not need to be encrypted. If the network devices at both ends support the same protocol type identifier without encryption, the same protocol type identifier may not be encrypted any more when the data frame message is sent later. The encrypted data frame message after the MKA negotiation can pass through the intermediate network to be forwarded.

Based on the same inventive concept, the embodiment of the present application further 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, and the processor 1110 is caused by the machine-executable instructions to perform the communication method provided by the embodiment of the present application. The communication apparatus shown in fig. 10 can 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 (RAM) or a Non-volatile Memory (NVM), such as at least one disk Memory. Optionally, the computer-readable storage medium 1130 may also be at least one memory device located remotely from the processor 1110.

The Processor 1110 may be a general-purpose Processor, including a Central Processing Unit (CPU), a Network Processor (NP), and the like; the Integrated Circuit can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), or other Programmable logic devices, discrete Gate or transistor logic devices, discrete hardware components.

In the present embodiment, the processor 1110 reads the machine executable instructions stored in the machine readable storage medium 1130, and the machine executable instructions cause the processor 1110 itself and the call transceiver 1120 to perform the communication method described in the present embodiment.

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 and the invoking transceiver 1120 to perform the communication methods described in embodiments of the present application.

The implementation process of the functions and actions of each unit in the above device is specifically described in the implementation process of the corresponding step in the above method, and is not described herein again.

For the device embodiments, since they substantially correspond to the method embodiments, reference may be made to the partial description of the method embodiments for relevant points. The above-described embodiments of the apparatus are merely illustrative, and the units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the scheme of the application. One of ordinary skill in the art can understand and implement it without inventive effort.

As for the embodiments of the communication apparatus and the machine-readable storage medium, since the contents of the related methods are substantially similar to those of the foregoing embodiments of the methods, the description is relatively simple, and for the relevant points, reference may be made to the partial description of the embodiments of the methods.

The above description is only exemplary of the present application and should not be taken as limiting the present application, as any modification, equivalent replacement, or improvement made within the spirit and principle of the present application should be included in the scope of protection of the present application.

Claims

1. A communication method applied to a first network device, the method comprising:

receiving a second MKPDU protocol message sent by the second network equipment;

2. The method of claim 1, wherein before sending the first MKPDU protocol message 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 to be encrypted 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 comprises a first message body field, and wherein the first message body field carries the first extended type parameter set;

4. The method of claim 1, wherein after receiving the second MKPDU protocol message sent by the second network device, the method further comprises:

and if the second MKPDU protocol message does not comprise a second extended type parameter set, determining that the flexible label parameter set is not negotiated in the process of carrying out the MKA negotiation.

5. The method of claim 1, wherein after receiving the second MKPDU protocol message sent by the second network device, the method further comprises:

and if the second MKPDU protocol message comprises the second flexible label parameter set and a support field included by the second flexible label parameter set is a third value, when the data frame message comprises 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:

7. The apparatus according to claim 6, wherein the receiving unit is further configured to receive a configuration instruction input by a user, where the configuration instruction includes a protocol field that does not need to be encrypted in a data frame packet, and the protocol field is used to carry the first protocol type identifier.

8. The apparatus of claim 6, wherein the first MKPDU protocol message comprises a first message body field, and wherein the first message body field carries the first extended type parameter set;

9. The apparatus of claim 6, further comprising:

a determining unit, 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 extended type parameter set.

10. The apparatus of claim 6, wherein the encryption unit is further configured to perform an encryption operation on a protocol field carrying the first protocol type identifier when the data frame packet includes the protocol field carrying the first protocol type identifier if the second MKPDU protocol packet includes the second flexible label parameter set and a support field included in the second flexible label parameter set is a third value.