Communication method and device

Abstract

The invention provides a communication method and device, and the method comprises the steps: carrying out the broadcasting of a first DHCP request in a two-layer network; when the first DHCP verification sent by the plurality of DHCP servers is received, selecting a target DHCP server from the plurality of DHCP servers; a second DHCP request is sent to a target DHCP server; receiving a second DHCP verification sent by the target DHCP server after the verification of the cookie value and the identifier is passed; generating a first key according to the first encryption attribute information of the target DHCP server, the first key being used for the DHCP client to encrypt and decrypt the complete DHCP message; and sending a third DHCP request to the target DHCP server, so that the target DHCP server performs encryption and decryption processing on the complete DHCP message according to the generated second key.

Description

Technical Field

[0001] This application relates to the field of communication technologies, and in particular, to a communication method and apparatus. Background Art

[0002] The Dynamic Host Configuration Protocol (DHCP) adopts the client / server mode, and the server dynamically assigns network configuration parameters such as IP addresses to network devices. When the DHCP client and the DHCP server are in different physical network segments, the DHCP client can communicate with the DHCP server through a DHCP relay to obtain an IP address and other network configuration information.

[0003] In some scenarios, network administrators will authenticate the source and content of DHCP packets. For example, a DHCP client may be unable to obtain an IP address due to a fake DHCP server; or, there may be "extra" DHCP servers in the network, and the configurations provided by these servers cannot be used properly, resulting in the DHCP client being unable to work properly. Network administrators hope to restrict IP address allocation to authorized hosts and implement software-level security defenses in some environments without security guarantees (for example, wireless networks or certain university environments do not set up firewalls).

[0004] To solve the above problems, the existing DHCP-related protocols have proposed an encryption technology for DHCP protocol interaction packets. The source and content of DHCP packets are authenticated through the newly added Option 90. The Option 90 includes a Protocol field, an Algorithm field, and an Authentication Information field. Among them, the value of the Protocol field is 0 or 1. When the value of the Protocol field is 0, the value of the Algorithm field is also 0, indicating that the interaction between the DHCP client and the DHCP server this time uses the encrypted plaintext method, and the authorization information is displayed in plaintext in the Authentication Information field. When the value of the Protocal field is 1, it represents the use of the Delayed authentication authentication method. In this method, the DHCP client uses the packet content, the key, and the DHCP packet header for hash calculation, and carries the calculated hash value in the Authentication Information field.

[0005] However, the above encryption technology also exposes the following problems: Although the interaction between the DHCP client and the DHCP server increases the authorization information, the IP address assigned by the DHCP server and the MAC address of the DHCP client are still exposed during the transmission process. If an attacker performs packet capture and viewing, the assigned IP address, the MAC address of the DHCP client, and other private option information can still be obtained, posing a risk of exposing user information. Summary of the Invention

[0006] In view of this, the present application provides a communication method and apparatus to solve the problem that the existing encryption technology for DHCP protocol interaction messages has a risk of exposing user information.

[0007] In a first aspect, the present application provides a communication method, which is applied to a DHCP client, and the method includes:

[0008] In a layer 2 network, broadcast and send a first DHCP request;

[0009] When receiving first DHCP verifications sent by multiple DHCP servers according to the first DHCP request, select a target DHCP server from the multiple DHCP servers that send the first DHCP verification;

[0010] Send a second DHCP request to the target DHCP server, where the second DHCP request includes a cookie value and an identifier of the target DHCP server, and the cookie value is generated by the target DHCP server and carried in the first DHCP verification;

[0011] Receive a second DHCP verification sent by the target DHCP server after verifying the cookie value and the identifier, where the second DHCP verification includes first encryption attribute information used by the target DHCP server to generate a first key;

[0012] Generate a second key according to the first encryption attribute information of the target DHCP server, where the second key is used to encrypt and decrypt the complete DHCP message through the second key when interacting with the target DHCP server again for DHCP messages;

[0013] Send a third DHCP request to the target DHCP server, where the third DHCP request includes a key generation result, so that the target DHCP server determines that when interacting with the DHCP client again for DHCP messages, the complete DHCP message is encrypted and decrypted through the first key according to the key generation result.

[0014] Second aspect, the present application provides a communication method, which is applied to a DHCP server, and the method includes:

[0015] Receiving a first DHCP request sent by a DHCP client;

[0016] According to the first DHCP request, sending a first DHCP verification to the DHCP client, where the first DHCP verification includes a cookie value and an identifier of the DHCP server;

[0017] If a second DHCP request sent by the DHCP client is received and the cookie value and the identifier included in the second DHCP request pass the verification, generating a first key according to first encryption attribute information;

[0018] Sending a second DHCP verification to the DHCP client, where the second DHCP verification includes the first encryption attribute information of the DHCP server, and the first encryption attribute information is used to enable the DHCP client to generate a second key;

[0019] Receiving a third DHCP request sent by the DHCP client, where the third DHCP request includes a key generation result;

[0020] Wherein, the first key is used to encrypt and decrypt the complete DHCP message through the first key when the DHCP server and the DHCP client interact with the DHCP message again; the second key is used to encrypt and decrypt the complete DHCP message through the second key when the DHCP client and the DHCP server interact with the DHCP message again.

[0021] Third aspect, the present application provides a communication device, which is applied to a DHCP client, and the device includes: a sending unit, a receiving unit, a selection unit, and a generating unit;

[0022] The sending unit is configured to broadcast and send a first DHCP request in a layer 2 network;

[0023] The selection unit is configured to select a target DHCP server from multiple DHCP servers that send the first DHCP verification when the receiving unit receives the first DHCP verifications sent by multiple DHCP servers according to the first DHCP request;

[0024] The sending unit is further configured to send a second DHCP request to the target DHCP server, where the second DHCP request includes a cookie value and an identifier of the target DHCP server, and the cookie value is generated by the target DHCP server and carried in the first DHCP authentication;

[0025] The receiving unit is configured to receive a second DHCP authentication sent by the target DHCP server after the verification of the cookie value and the identifier is passed, where the second DHCP authentication includes first encryption attribute information used by the target DHCP server to generate a first key;

[0026] The generating unit is configured to generate a second key according to the first encryption attribute information of the target DHCP server, where the second key is used to encrypt and decrypt the complete DHCP message through the second key when interacting with the target DHCP server again for DHCP messages;

[0027] The sending unit is further configured to send a third DHCP request to the target DHCP server, where the third DHCP request includes a key generation result, so that the target DHCP server determines that when the target DHCP server interacts with the DHCP client again for DHCP messages, the complete DHCP message is encrypted and decrypted through the first key according to the key generation result.

[0028] In a fourth aspect, the present application provides a communication device, where the device is applied to a DHCP server, and the device includes:

[0029] A receiving unit, configured to receive a first DHCP request sent by a DHCP client;

[0030] A sending unit, configured to send a first DHCP authentication to the DHCP client according to the first DHCP request, where the first DHCP authentication includes a cookie value and an identifier of the DHCP server;

[0031] A generating unit, configured to generate a first key according to first encryption attribute information if the receiving unit receives a second DHCP request sent by the DHCP client and the cookie value and the identifier included in the second DHCP request pass the verification

[0032] The sending unit is further configured to send a second DHCP authentication to the DHCP client, where the second DHCP authentication includes the first encryption attribute information of the DHCP server, and the first encryption attribute information is used to enable the DHCP client to generate a second key;

[0033] The receiving unit is further configured to receive a third DHCP request sent by the DHCP client, where the third DHCP request includes a key generation result;

[0034] Wherein, the first key is used to encrypt and decrypt the complete DHCP message by the first key when the DHCP server and the DHCP client interact with the DHCP message again; the second key is used to encrypt and decrypt the complete DHCP message by the second key when the DHCP client and the DHCP server interact with the DHCP message again.

[0035] In a fifth aspect, the present application provides a network device, including a processor and a machine-readable storage medium. The machine-readable storage medium stores machine-executable instructions that can be executed by the processor, and the processor is prompted by the machine-executable instructions to execute the method provided in the first aspect of the present application.

[0036] In a sixth aspect, the present application provides a network device, including a processor and a machine-readable storage medium. The machine-readable storage medium stores machine-executable instructions that can be executed by the processor, and the processor is prompted by the machine-executable instructions to execute the method provided in the second aspect of the present application.

[0037] Therefore, by applying the communication method and device provided in the present application, in a layer-2 network, the DHCP client broadcasts a first DHCP request; when receiving first DHCP verifications sent by multiple DHCP servers according to the first DHCP request, the DHCP client selects a target DHCP server from the multiple DHCP servers that send the first DHCP verification; the DHCP client sends a second DHCP request to the target DHCP server, where the second DHCP request includes a cookie value and an identifier of the target DHCP server, and the cookie value is generated by the target DHCP server and carried in the first DHCP verification; the DHCP client receives a second DHCP verification sent by the target DHCP server after verifying the cookie value and the identifier, where the second DHCP verification includes first encryption attribute information used by the target DHCP server to generate a first key; according to the first encryption attribute information of the target DHCP server, the DHCP client generates a second key, and the second key is used to encrypt and decrypt the complete DHCP message by the second key when the DHCP client and the target DHCP server interact with the DHCP message again; the DHCP client sends a third DHCP request to the target DHCP server, where the third DHCP request includes a key generation result, so that the target DHCP server determines that when the target DHCP server interacts with the DHCP client with the DHCP message again, the complete DHCP message is encrypted and decrypted by the first key.

[0038] In this way, through the interaction process of the DTLS protocol, the DHCP client and the DHCP server exchange encrypted attribute information using the newly defined DHCP message, generate a key, and then perform complete encryption and decryption processing on subsequent DHCP messages. At the same time, it also solves the problem that the existing encryption technology for DHCP protocol interaction messages has the risk of exposing user information. Description of the Drawings

[0039] Figure 1 It is a flowchart of a communication method provided by an embodiment of the present application;

[0040] Figure 2 It is a schematic diagram of the format of an Option field provided by an embodiment of the present application;

[0041] Figure 3 It is a flowchart of another communication method provided by an embodiment of the present application;

[0042] Figure 4 It is a signaling diagram of the communication interaction between the DHCP client and the DHCP server provided by an embodiment of the present application;

[0043] Figure 5 It is a structural diagram of a communication device provided by an embodiment of the present application;

[0044] Figure 6 It is another structural diagram of a communication device provided by an embodiment of the present application;

[0045] Figure 7 It is a hardware structure of a network device provided by an embodiment of the present application. Detailed Embodiments

[0046] Here, the exemplary embodiments will be described in detail, and the examples are shown in the drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application. Instead, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.

[0047] The terms used in the present application are only for the purpose of describing specific embodiments and are not intended to limit the present application. The singular forms "a", "the", and "said" used in the present application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term "and / or" used herein refers to and includes any or all possible combinations of one or more of the corresponding listed items.

[0048] It should be understood that although terms such as first, second, and third may be used in this application to describe various information, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from each other. For example, without departing from the scope of this application, the first information may also be referred to as the second information, and similarly, the second information may also be referred to as the first information. Depending on the context, the word "if" as used herein may be interpreted as "when" or "while" or "in response to a determination".

[0049] The communication method provided by the embodiments of this application will be described in detail below. Refer to Figure 1 , Figure 1 which is a flowchart of a communication method provided by the embodiments of this application. This method is applied to a DHCP client. The communication method provided by the embodiments of this application may include the following steps.

[0050] Step 110: In a layer-2 network, broadcast a first DHCP request;

[0051] Specifically, the DHCP client desires to apply for an IP address from the DHCP server. Before applying for the IP address, the DHCP client first performs a handshake interaction with the DHCP server to exchange their respective encryption attributes and generate a key. This key can be used to encrypt the complete DHCP packet when interacting with the peer for subsequent DHCP packets.

[0052] The DHCP client generates a first DHCP request and broadcasts the first DHCP request in the layer-2 network. Among them, the first DHCP request may specifically be a DHCP Hello request.

[0053] Optionally, in the embodiments of this application, the DHCP client may specifically be a DHCPv4 client, and the DHCP server may specifically be a DHCPv4 server. The first DHCP request includes a first Option field, and the first Option field includes a first Code field, a first Length field, and a first Value field; wherein, the value of the first Code field is 53, the value of the first Length field is 1, and the value of the first Value field is 14.

[0054] Among them, the first Option field can be used to indicate the packet type. For example, the DHCP server determines that the received DHCP packet is a DHCP request through the value of the first Value field. In actual implementation, the first Option field is specifically the existing Option53.

[0055] Optionally, in an embodiment of the present application, the DHCP client may be specifically a DHCPv6 client, and the DHCP server may be specifically a DHCPv6 server. The first DHCP request includes a first message type field, and the value of the first Message type field is any value in a first interval; wherein the start value of the first interval is 38, and the end value is 255. The value of the first Message type field may be any value in [38,255], and any value in the first interval is currently not used. In an embodiment of the present application, the value of the first Message type field may be tentatively set to 38.

[0056] Optionally, the first DHCP request further includes an Option field, which includes a DTLS handshake field, which is used to carry a ClientHello message, which includes information such as supported encryption suites, protocol versions, random numbers, etc. The ClientHello message is also used to inform the DHCP server to start the DTLS handshake process.

[0057] The Option field includes a coding field, a length field, and a value field. The value of the coding field can be selected from any one of 163-174, 178-207, and 214-219. In the embodiment of the present application, the value of the coding field can be temporarily set to 163. The value field can also be referred to as the DTLS handshake field. The format of the Option field can be referred to Figure 2 shown.

[0058] In the embodiment of the present application, the DHCP client and the DHCP server may be in a network including a DHCP relay or may be in a network not including a DHCP relay.

[0059] Step 120: When receiving a first DHCP authentication sent by multiple DHCP servers according to the first DHCP request, select a target DHCP server from the multiple DHCP servers sending the first DHCP authentication;

[0060] Specifically, according to the description of step 120, each DHCP server in the layer 2 network will receive the first DHCP request. According to the first DHCP request, each DHCP server generates a first DHCP verification. The first DHCP verification includes a cookie value generated by the DHCP server and an identifier of the DHCP server.

[0061] Among them, the cookie value is randomly generated by the DHCP server; the identifier of the DHCP server is used to uniquely identify the DHCP server. The first DHCP verification can be specifically DHCP Hello verify.

[0062] Each DHCP server sends the first DHCP verification to the DHCP client respectively.

[0063] Optionally, in the embodiment of the present application, the first DHCP verification includes a second Option field, and the second Option field includes a second coding field, a second length field, and a second value field; among them, the value of the second coding field is 53, the value of the second length field is 1, and the value of the second value field is 15.

[0064] Among them, the second Option field can be used to indicate the message type. For example, the DHCP client determines that the received DHCP message is a DHCP verification through the value of the second value field. In actual implementation, the second Option field is specifically the existing Option53.

[0065] Optionally, in the embodiment of the present application, the first DHCP verification further includes a third Option field, and the third Option field includes a first DTLS handshake field, and the first DTLS handshake field is used to carry the value of a small text file (cookie).

[0066] Optionally, in the embodiment of the present application, the first DHCP verification further includes an Option54 field, and the Option54 field is used to carry the identifier of the DHCP server. As Figure 2 shown, Figure 2 is a schematic diagram of an Option field format provided by the embodiment of the present application. In Figure 2 it, the third Option field includes a third coding field, a third length field, and a third value field. The third value field can also be called a first DTLS handshake (DTLS handshake) field, and the first DTLS handshake field is used to carry the cookie value;

[0067] Among them, the value of the third coding field can be arbitrarily selected from 163-174, 178-207, 214-219. In the embodiment of the present application, the value of the third coding field can be tentatively set to 163.

[0068] The above cookie value is randomly generated by the DHCP server according to the source MAC address of the DHCP client through a hash method. The generation method of this cookie value is the same as the existing generation method, and will not be repeated here.

[0069] After the DHCP client receives the first DHCP authentication sent by multiple DHCP servers, it can select a target DHCP server according to the reception time of each first DHCP authentication. For example, the DHCP client sorts the multiple reception times in chronological order, determines the first DHCP authentication with the earliest reception time (i.e., the first one), and uses the DHCP server that sent this first DHCP authentication as the target DHCP server.

[0070] Step 130: Send a second DHCP request to the target DHCP server. The second DHCP request includes a cookie value and an identifier of the target DHCP server. The cookie value is generated by the target DHCP server and carried in the first DHCP authentication.

[0071] Specifically, according to the description in step 120, after the DHCP client determines the target DHCP server, it generates a second DHCP request and sends the second DHCP request to the target DHCP server. This second DHCP request includes a cookie value and an identifier of the target DHCP server.

[0072] Among them, the second DHCP request can specifically be a DHCP Hello request.

[0073] Optionally, in the embodiments of the present application, the second DHCP request also includes a first Option field. The first Option field includes a first encoding field, a first length field, and a first value field. Among them, the value of the first encoding field is 53, the value of the first length field is 1, and the value of the first value field is 14.

[0074] Among them, the first Option field has been described in the foregoing step 110 and will not be repeated here.

[0075] Optionally, in the embodiments of the present application, the second DHCP request further includes a fifth Option field. The fifth Option field includes a third DTLS handshake field, and the third DTLS handshake field is used to carry the cookie value.

[0076] Optionally, in the embodiments of the present application, the first DHCP request further includes an Option54 field, and the Option54 field is used to carry the identifier of the DHCP server.

[0077] It can be understood that the fifth Option field is the same as the third Option field described in the foregoing step 120 and will not be repeated here.

[0078] The above-mentioned fifth Option field and third DTLS handshake field are only used to identify and distinguish from the aforementioned Option field and DTLS handshake field. In actual applications, it can also be the fourth Option field, the second DTLS handshake field, and so on.

[0079] Step 140: Receive the second DHCP verification sent by the target DHCP server after passing the verification of the cookie value and the identifier. The second DHCP verification includes the first encryption attribute information used by the target DHCP server to generate the first key.

[0080] Specifically, according to the description of step 130, after receiving the second DHCP request, the target DHCP server obtains the cookie value and the identifier therefrom. The target DHCP server verifies the cookie value and the identifier.

[0081] If the cookie value is generated by the target DHCP server and the identifier is the identifier of the target DHCP server itself, the target DHCP server determines that the cookie value and the identifier pass the verification. The target DHCP server generates the second DHCP verification, which includes the first encryption attribute information used by the target DHCP server to generate the first key.

[0082] Among them, the second DHCP verification can be specifically DHCP Hello verify.

[0083] Optionally, in the embodiments of the present application, the second DHCP verification also includes a second Option field, which includes a second coding field, a second length field, and a second value field; wherein, the value of the second coding field is 53, the value of the second length field is 1, and the value of the second value field is 15.

[0084] Among them, the second Option field has been described in the aforementioned step 120 and will not be repeated here.

[0085] Optionally, in the embodiments of the present application, the second DHCP verification further includes a fourth Option field, which includes a second DTLS handshake field for carrying the first encryption attribute information.

[0086] It can be understood that the fourth Option field is the same as the third Option field described in the aforementioned step 120 and will not be repeated here.

[0087] The above-mentioned fourth Option field and second DTLS handshake field are only used for identification and differentiation from the aforementioned Option field and DTLS handshake field. In practical applications, it can also be the fifth Option field, third DTLS handshake field, and so on.

[0088] In the embodiment of the present application, the first encryption attribute information is specifically a certificate and key exchange information. The certificate includes the public key information of the target DHCP server and the certificate issuance qualification information; the key exchange information includes encryption algorithms, encryption parameters, random numbers, etc.

[0089] It should be noted that after the target DHCP server determines the cookie value and the identity verification is passed, it first generates a first key locally according to the encryption algorithm, encryption parameters, random number, and public key information. This first key is also the private key of the target DHCP server. The process of generating the key can be executed according to the existing key generation process and will not be repeated here.

[0090] Step 150: Generate a second key according to the first encryption attribute information of the target DHCP server. The second key is used to encrypt and decrypt the complete DHCP packet when interacting with the target DHCP server again through the second key.

[0091] Specifically, according to the description of the aforementioned step 140, after the DHCP client receives the second DHCP verification, it obtains the first encryption attribute information therefrom.

[0092] Using the first encryption attribute information, the DHCP client generates a second key. This second key is used to encrypt and decrypt the complete DHCP packet when the DHCP client interacts with the target DHCP server again through the second key.

[0093] In the embodiment of the present application, the DHCP client uses the public key information, encryption algorithm, encryption parameters, and locally generated random value included in the first encryption attribute information to generate a second key. The process of generating the key can be executed according to the existing key generation process and will not be repeated here.

[0094] It should be noted that after the DHCP client obtains the certificate issuance qualification information from the first encryption attribute information, it can also verify the certificate issuance qualification information to determine whether the certificate sent by the DHCP server is a legal certificate. When the certificate is a legal certificate, the second key is generated using the first encryption attribute information.

[0095] Step 160: Send a third DHCP request to the target DHCP server. The third DHCP request includes the key generation result, so that the target DHCP server determines that when the target DHCP server interacts with the DHCP client again for DHCP messages, the first key is used to encrypt and decrypt the complete DHCP messages.

[0096] Specifically, as described in step 150, after the DHCP client generates the first key, it also generates a third DHCP request, which includes the key generation result. The DHCP client sends the third DHCP request to the target DHCP server.

[0097] Among them, the third DHCP request may specifically be a DHCP Hello request.

[0098] Optionally, in the embodiment of the present application, the third DHCP request includes a first Option field, and the first Option field includes a first coding field, a first length field, and a first value field; wherein, the value of the first coding field is 53, the value of the first length field is 1, and the value of the first value field is 14.

[0099] Among them, the first Option field is the same as the first Option field described in the foregoing step 110, and will not be repeated here.

[0100] Optionally, in the embodiment of the present application, the third DHCP request further includes a sixth Option field, and the sixth Option field includes a fourth DTLS handshake field, and the fourth DTLS handshake field is used to carry the key generation result.

[0101] It can be understood that the sixth Option field is the same as the third Option field described in the foregoing step 120, and will not be repeated here.

[0102] The above-mentioned sixth Option field and fourth DTLS handshake field are only used for identification and distinction from the foregoing Option field and DTLS handshake field. In practical applications, they may also be the fourth / fifth Option field, the second / third DTLS handshake field, and so on.

[0103] After receiving the third DHCP request, the target DHCP server obtains the key generation result therefrom. According to the key generation result, the target DHCP server determines that the DHCP client has generated the second key. Subsequently, when the target DHCP server interacts with the DHCP client again for DHCP messages, the first key is used to encrypt and decrypt the complete DHCP messages.

[0104] Optionally, in the embodiments of the present application, the third DHCP request further includes second encryption attribute information, which specifically includes a certificate and key exchange information. The certificate includes the public key information of the DHCP client and the certificate issuance qualification information; the key exchange information includes an encryption algorithm, encryption parameters, a random number, etc.

[0105] It should be noted that the second encryption attribute information is information carried optionally. The target DHCP server can also verify the certificate issuance qualification to determine whether the certificate sent by the DHCP client is a legal certificate.

[0106] Optionally, in the embodiments of the present application, after determining that the DHCP client generates the second key, the target DHCP server further generates a third DHCP verification. The third DHCP verification is used to inform the DHCP client that the target DHCP server has generated the first key. The subsequent DHCP interactions between the two ends can be implemented for encryption and decryption processing based on the DTLS protocol.

[0107] For example, after the DHCP client generates a DHCP DISCOVER message, it encrypts the DHCP DISCOVER message with the second key and sends it to the target DHCP server. After receiving the encrypted DHCP DISCOVER message, the target DHCP server decrypts the DHCP DISCOVER message with the first key and then processes it.

[0108] It should be noted that when the DHCP client and the target DHCP server perform encryption processing on the DHCP message, the entire DHCP message will be encrypted, including the message header and the data part, and then sent after encryption.

[0109] Among them, the third DHCP verification can be specifically a DHCP Hello verify.

[0110] Optionally, in the embodiments of the present application, the third DHCP verification also includes a second Option field, which includes a second coding field, a second length field, and a second value field; among them, the value of the second coding field is 53, the value of the second length field is 1, and the value of the second value field is 15.

[0111] Among them, the second Option field has been described in the foregoing step 120 and will not be repeated here.

[0112] Therefore, by applying the communication method provided in this application, in a layer-2 network, a DHCP client broadcasts a first DHCP request; when receiving first DHCP validations sent by multiple DHCP servers according to the first DHCP request, the DHCP client selects a target DHCP server from the multiple DHCP servers that send the first DHCP validation; the DHCP client sends a second DHCP request to the target DHCP server, and the second DHCP request includes a cookie value and an identifier of the target DHCP server, and the cookie value is generated by the target DHCP server and carried within the first DHCP validation; the DHCP client receives a second DHCP validation sent by the target DHCP server after the cookie value and the identifier are verified to be passed, and the second DHCP validation includes first encryption attribute information used by the target DHCP server to generate a first key; according to the first encryption attribute information of the target DHCP server, the DHCP client generates a second key, and when the second key is used to interact with the target DHCP server for DHCP messages again, the second key is used to encrypt and decrypt the complete DHCP messages; the DHCP client sends a third DHCP request to the target DHCP server, and the third DHCP request includes a key generation result, so that the target DHCP server determines, according to the key generation result, that when the target DHCP server interacts with the DHCP client for DHCP messages again, the second key is used to encrypt and decrypt the complete DHCP messages.

[0113] In this way, by using the interaction process of the DTLS protocol, the DHCP client and the DHCP server exchange encryption attribute information by using newly defined DHCP messages and generate keys, and then perform complete encryption and decryption processing on subsequent DHCP messages. At the same time, the problem that the existing encryption technology for interacting DHCP protocol messages has the risk of exposing user information is also solved.

[0114] The communication method provided in the embodiments of this application will be described in detail below. Refer to Figure 3 , Figure 3 which is a flowchart of another communication method provided in the embodiments of this application. This method is applied to a DHCP server. The communication method provided in the embodiments of this application may include the following steps.

[0115] Step 310, receive a first DHCP request sent by a DHCP client; specifically, according to the description of the foregoing embodiments, before applying for an IP address, the DHCP client first performs a handshake interaction with the DHCP server to exchange their respective encryption attributes and generate keys.

[0116] The DHCP client generates a first DHCP request and broadcasts the first DHCP request in a layer-2 network.

[0117] Each DHCP server in the layer 2 network receives the first DHCP request. The embodiment of the present application is described by taking one DHCP server as an example.

[0118] In the above embodiment, the specific implementation and format of the first DHCP request have been described in detail, which will not be repeated here.

[0119] Step 320: Send a first DHCP verification to the DHCP client according to the first DHCP request, where the first DHCP verification includes a cookie value and an identifier of the DHCP server;

[0120] Specifically, according to the description of step 310, the DHCP server receives the first DHCP request. According to the first DHCP request, the DHCP server generates a first DHCP verification. The first DHCP verification includes a cookie value generated by the DHCP server and an identifier of the DHCP server.

[0121] The DHCP server sends a first DHCP authentication to the DHCP client.

[0122] In the above-mentioned embodiment, the specific implementation and format of the first DHCP authentication have been described in detail, which will not be repeated here.

[0123] Step 330: If a second DHCP request sent by the DHCP client is received and the cookie value and the identifier included in the second DHCP request are verified, a first key is generated according to the first encryption attribute information;

[0124] Specifically, according to the description of step 330, a first key is generated locally according to the configured encryption algorithm, encryption parameters, generated random numbers, and public key information included in the local certificate. The first key is also the private key of the target DHCP server. The key generation process can be performed according to the existing key generation process, which will not be repeated here. The first key is used for encryption and decryption of the complete DHCP message by the first key when the DHCP server and the DHCP client exchange DHCP messages again.

[0125] Step 340: Send a second DHCP authentication to the DHCP client, where the second DHCP authentication includes first encrypted attribute information of the DHCP server, where the first encrypted attribute information is used to enable the DHCP client to generate a second key;

[0126] Specifically, according to the description of step 310 and step 320, each DHCP server in the layer 2 network will generate and send a first DHCP authentication to the DHCP client. After receiving multiple first DHCP authentications, the DHCP client can select a target DHCP server according to the time when each first DHCP authentication is received.

[0127] For example, the DHCP client sorts multiple receiving times in chronological order, determines the first (ie earliest) first DHCP authentication received, and uses the DHCP server that sends the first DHCP authentication as the target DHCP server. The DHCP client generates and sends a second DHCP request to the target DHCP server.

[0128] In the embodiment of the present application, after sending the first DHCP authentication, the DHCP server determines whether it has received the second DHCP request sent by the DHCP client.

[0129] If the DHCP server receives the second DHCP request, the DHCP server determines that it is selected by the DHCP client, and subsequently allocates an address to the DHCP client.

[0130] After receiving the second DHCP request, the DHCP server verifies the cookie value and the identifier included in the second DHCP request.

[0131] If the cookie value is generated by the DHCP server and the identifier is the identifier of the DHCP server itself, the DHCP server determines that the cookie value and the identifier are verified. After executing step 330, the DHCP server generates and sends a second DHCP authentication to the DHCP client.

[0132] After receiving the second DHCP authentication, the DHCP client generates a second key using the first encryption attribute information included in the second DHCP authentication. The second key is used to encrypt and decrypt the complete DHCP message when the DHCP client and the DHCP server exchange DHCP messages again.

[0133] In the above-mentioned embodiment, the specific implementation and format of the second DHCP request and the second DHCP verification have been described in detail, which will not be repeated here.

[0134] Step 350: Receive a third DHCP request sent by the DHCP client, where the third DHCP request includes a key generation result;

[0135] Specifically, according to the description of step 340, after the DHCP client generates the second key, it also generates a third DHCP request. The DHCP client sends the third DHCP request to the DHCP server.

[0136] The DHCP server receives the third DHCP request.

[0137] In the foregoing embodiments, the specific implementation and format of the third DHCP request have been described in detail and will not be repeated here.

[0138] Optionally, in the embodiments of the present application, after receiving the third DHCP request, the DHCP server also generates a third DHCP verification. The third DHCP verification is used to inform the DHCP client that the DHCP server has generated the first key. Subsequent DHCP interactions at both ends can implement encryption and decryption processing based on the DTLS protocol.

[0139] For example, after the DHCP client generates a DHCP DISCOVER message, it encrypts the DHCP DISCOVER message using the second key and then sends it to the DHCP server. After receiving the encrypted DHCP DISCOVER message, the DHCP server decrypts the DHCP DISCOVER message using the first key and then processes it.

[0140] It should be noted that when the DHCP client and the DHCP server perform encryption processing on the DHCP message, the entire DHCP message will be encrypted, including the message header and the data part, and then sent.

[0141] In the foregoing embodiments, the specific implementation and format of the third DHCP verification have been described in detail and will not be repeated here.

[0142] Therefore, by applying the communication method provided in this application, the DHCP server receives a first DHCP request sent by the DHCP client; according to the first DHCP request, the DHCP server sends a first DHCP authentication to the DHCP client, and the first DHCP authentication includes a cookie value and an identifier of the DHCP server; if a second DHCP request sent by the DHCP client is received and the cookie value and the identifier included in the second DHCP request pass the verification, the DHCP server generates a first key according to the first encrypted attribute information; the DHCP server sends a second DHCP authentication to the DHCP client, and the second DHCP authentication includes the first encrypted attribute information of the DHCP server, and the first encrypted attribute information is used to enable the DHCP client to generate a second key; the DHCP server receives a third DHCP request sent by the DHCP client, and the third DHCP request includes a key generation result; wherein, the first key is used to encrypt and decrypt the complete DHCP packet through the first key when the DHCP server and the DHCP client interact with the DHCP packet again; the second key is used to encrypt and decrypt the complete DHCP packet through the second key when the DHCP client and the DHCP server interact with the DHCP packet again.

[0143] In this way, by using the interaction process of the DTLS protocol, the DHCP client and the DHCP server exchange encrypted attribute information by using a newly defined DHCP packet and generate keys, so as to implement complete encryption and decryption processing of subsequent DHCP packets. At the same time, it also solves the problem that the existing encryption technology for interacting packets of the DHCP protocol has the risk of exposing user information.

[0144] The communication method provided in the embodiments of this application will be described in detail below. Refer to Figure 4 , Figure 4 which is a signaling diagram for communication interaction between the DHCP client and the DHCP server provided in the embodiments of this application. The communication interaction process includes the following steps. The DHCP client in the embodiments of this application is a DHCPv4 client, and the DHCP server is a DHCPv4 server.

[0145] Step 410: The DHCP client sends DHCP Hello request1 to multiple DHCP servers respectively.

[0146] Specifically, the DHCP client wants to apply for an IP address from the DHCP server. Before applying for the IP address, the DHCP client first performs a handshake interaction with the DHCP server to exchange their respective encrypted attributes and generate keys.

[0147] The DHCP client generates a DHCP Hello request 1, and this DHCP Hello request 1 includes Option 53. According to the description of the foregoing embodiments, the value of the value field included in the Option 53 field is 14. This DHCP Hello request 1 further includes Option 163. The DTLS handshake field included in the Option 163 field carries the ClientHello message. This ClientHello message includes information such as supported cipher suites, protocol versions, random numbers, etc. This ClientHello message is also used to inform the DHCP server to initiate the DTLS handshake process.

[0148] The DHCP client broadcasts and sends the DHCP Hello request 1 in the data link layer network.

[0149] Step 420: Multiple DHCP servers respectively send DHCP Hello verify 1 to the DHCP client.

[0150] Specifically, according to the description of step 410, each DHCP server in the data link layer network receives the DHCP Hello request 1. Based on the DHCP Hello request 1, each DHCP server generates a DHCP Hello verify 1. This DHCP Hello verify 1 includes the cookie value generated by the DHCP server and the identifier of the DHCP server.

[0151] Among them, the cookie value is randomly generated by the DHCP server; the identifier of the DHCP server is used to uniquely identify the DHCP server.

[0152] According to the description of the foregoing embodiments, this DHCP Hello verify 1 includes Option 53. The value of the value field included in the Option 53 field is 15. This DHCP Hello verify 1 further includes Option 163. The DTLS handshake field included in the Option 163 field carries the cookie value. This DHCP Hello verify 1 further includes Option 54, and this Option 54 is used to carry the identifier of the DHCP server.

[0153] Each DHCP server respectively sends the DHCP Hello verify 1 to the DHCP client.

[0154] After the DHCP client receives multiple DHCP Hello verify1 sent by multiple DHCP servers, it can select a target DHCP server according to the reception time of each DHCP Hello verify1.

[0155] For example, the DHCP client sorts multiple reception times in chronological order, determines the DHCP Hello verify1 with the first (i.e., the earliest) reception time, and uses the DHCP server that sent the DHCP Hello verify1 as the target DHCP server.

[0156] Step 430: The DHCP client sends a DHCP Hello request2 to the target DHCP server.

[0157] Specifically, according to the description in step 420, after the DHCP client determines the target DHCP server, it generates a DHCP Hello request2 and sends the DHCP Hello request2 to the target DHCP server. The DHCP Hello request2 includes a cookie value and the identifier of the target DHCP server.

[0158] According to the description of the foregoing embodiments, the DHCP Hello request2 includes Option53. The value field of the Option53 field has a value of 14. The DHCP Hello request2 also includes Option163. The DTLS handshake field included in the Option163 field carries the cookie value. The DHCP Hello request2 also includes Option54, which is used to carry the identifier of the DHCP server.

[0159] Step 440: The target DHCP server sends a DHCP Hello verify2 to the DHCP client.

[0160] Specifically, according to the description in step 430, after the target DHCP server receives the DHCP Hello request2, it obtains the cookie value and the identifier therefrom. The target DHCP server verifies the cookie value and the identifier.

[0161] If the cookie value is generated for the target DHCP server and is identified as the identifier of the target DHCP server itself, the target DHCP server determines that the cookie value and the identifier verification pass. The target DHCP server generates a key 1 locally according to the configured encryption algorithm, encryption parameters, the generated random number, and the public key information included in the local certificate. This key 1 is also the private key of the target DHCP server.

[0162] Meanwhile, the DHCP server also generates a DHCP Hello verify2, which includes the encryption attribute information 1 of the target DHCP server.

[0163] The target DHCP server sends the DHCP Hello verify2 to the DHCP client.

[0164] According to the description of the foregoing embodiment, this DHCP Hello verify2 includes Option53. The value field of the Option53 field has a value of 15. This DHCP Hello request2 also includes Option163. The DTLS handshake field included in the Option163 field carries the encryption attribute information 1.

[0165] In the embodiment of the present application, the encryption attribute information 1 is specifically a certificate and key exchange information. The certificate includes the public key information of the target DHCP server and the certificate issuance qualification information; the key exchange information includes an encryption algorithm, encryption parameters, a random number, etc.

[0166] Step 450: The DHCP client sends a DHCP Hello request3 to the target DHCP server.

[0167] Specifically, according to the description of step 440, after receiving the DHCP Hello verify2, the DHCP client obtains the encryption attribute information 1 therefrom.

[0168] Using the encryption attribute information 1, the DHCP client generates a key 2. This key 2 is used to encrypt and decrypt the complete DHCP packet when the DHCP client and the target DHCP server interact with the DHCP packet again.

[0169] It should be noted that after the DHCP client obtains the certificate issuance qualification information from the encryption attribute information 1, it can also verify the certificate issuance qualification information to determine whether the certificate sent by the DHCP server is a legal certificate. When the certificate is a legal certificate, the key 2 is generated using the encryption attribute information 1.

[0170] After the DHCP client generates key 2, it also generates a DHCP Hello request 3, and this DHCP Hello request 3 includes the key generation result 1. The DHCP client sends the DHCP Hello request 3 to the target DHCP server.

[0171] According to the description of the foregoing embodiments, this DHCP Hello request 3 includes Option 53. The value of the value field included in the Option 53 field is 14. This DHCP Hello request 3 also includes Option 163. The DTLS handshake field included in the Option 163 field carries the key generation result 1.

[0172] Optionally, in the embodiments of the present application, the Option 163 field further includes encryption attribute information 2. This encryption attribute information 2 is specifically a certificate and key exchange information. The certificate includes the public key information of the DHCP client and the certificate issuance qualification information; the key exchange information includes an encryption algorithm, encryption parameters, a random number, etc.

[0173] It should be noted that the encryption attribute information 2 is information carried optionally. The target DHCP server can also verify the certificate issuance qualification to determine whether the certificate sent by the DHCP client is a legal certificate.

[0174] Step 460: The target DHCP server sends a DHCP Hello verify 3 to the DHCP client.

[0175] Specifically, according to the description of step 450, after receiving the DHCP Hello request 3, the target DHCP server obtains the key generation result therefrom. Using the key generation result, the target DHCP server determines that the DHCP client has generated key 2. Subsequently, when the target DHCP server and the DHCP client interact with each other again with a DHCP message, the complete DHCP message is encrypted and decrypted using key 1.

[0176] After determining that the DHCP client has generated key 2, the target DHCP server also generates a DHCP Hello verify 3. This DHCP Hello verify 3 is used to inform the DHCP client that the target DHCP server has generated key 1. Subsequently, the DHCP interaction between the two ends can be implemented for encryption and decryption processing based on the DTLS protocol.

[0177] According to the description of the foregoing embodiments, this DHCP Hello verify 3 includes Option 53. The value of the value field included in the Option 53 field is 15.

[0178] Step 470: The DHCP client sends a DHCP DISCOVER message to the target DHCP server.

[0179] Specifically, according to the description in step 460, after the DHCP client determines that the target DHCP server generates key 1, it generates a DHCP Discovery (DISCOVER) message according to the existing DHCP protocol regulations to apply for an address from the target DHCP server.

[0180] After the DHCP client generates the DHCP DISCOVER message, it uses key 2 to encrypt the DHCP DISCOVER message and sends the encrypted DHCP DISCOVER message to the target DHCP server.

[0181] Step 480: The target DHCP server sends a DHCP OFFER message to the DHCP client.

[0182] Specifically, according to the description in step 470, after the target DHCP server receives the encrypted DHCP DISCOVER message, it uses key 1 to decrypt and process the encrypted DHCP DISCOVER message to obtain the DHCP DISCOVER message.

[0183] Select an IP address from the local address pool according to the priority order of IP address allocation. The target DHCP server carries the allocated IP address and other parameters (such as DNS, prefix information, etc.) in the DHCP Offer (OFFER) message. Using key 1, the target DHCP server encrypts the DHCP OFFER message and sends the encrypted DHCP OFFER message to the DHCP client.

[0184] Similarly, after the DHCP client receives the encrypted DHCP OFFER message, it uses key 2 to decrypt and process the encrypted DHCP OFFER message to obtain the DHCP OFFER message. According to the existing DHCP protocol regulations, the DHCP client continues to execute the subsequent steps of address application, which will not be repeated here.

[0185] It can be understood that when the DHCP client and the target DHCP server encrypt the DHCP message, they will encrypt the complete DHCP message, including the message header and the data part, and then send it.

[0186] Based on the same inventive concept, an embodiment of the present application also provides a communication device corresponding to a communication method. Refer to Figure 5 , Figure 5A communication device provided by an embodiment of the present application, the device is applied to a DHCP client, and the device includes: a sending unit 510, a selecting unit 520, a receiving unit 530, and a generating unit 540;

[0187] The sending unit 510 is configured to broadcast and send a first DHCP request in a layer 2 network;

[0188] The selecting unit 520 is configured to select a target DHCP server from multiple DHCP servers that send the first DHCP authentication when the receiving unit 530 receives the first DHCP authentications sent by the multiple DHCP servers according to the first DHCP request;

[0189] The sending unit 510 is further configured to send a second DHCP request to the target DHCP server, the second DHCP request includes a cookie value and an identifier of the target DHCP server, and the cookie value is generated by the target DHCP server and carried in the first DHCP authentication;

[0190] The receiving unit 530 is configured to receive a second DHCP authentication sent by the target DHCP server after the cookie value and the identifier are verified, and the second DHCP authentication includes first encryption attribute information used by the target DHCP server to generate a first key;

[0191] The generating unit 540 is configured to generate a second key according to the first encryption attribute information of the target DHCP server, and the second key is used to encrypt and decrypt the complete DHCP packet when interacting with the target DHCP server again;

[0192] The sending unit 510 is further configured to send a third DHCP request to the target DHCP server, the third DHCP request includes a key generation result, so that the target DHCP server determines that when the target DHCP server interacts with the DHCP client again for a DHCP packet, the complete DHCP packet is encrypted and decrypted by the second key

[0193] Optionally, the DHCP request includes a first Option field, and the first Option field includes a first encoding field and a first value field;

[0194] The value of the first encoding field is 53, and the value of the first value field is 14;

[0195] The DHCP verification includes a second Option field, and the second Option field includes a second coding field and a second value field;

[0196] The value of the second coding field is 53, and the value of the second value field is 15.

[0197] Optionally,

[0198] The DHCP request includes a first Message type field, and the value of the first Message type field is any value within a first range;

[0199] The DHCP verification includes a second Message type field, and the value of the second Message type field is any value within the first range;

[0200] The value of the second Message type field is different from the value of the first Message type field;

[0201] Wherein, the starting value of the first range is 38 and the ending value is 255.

[0202] Optionally, the first DHCP verification further includes a third Option field, and the third Option field includes a first DTLS handshake field for carrying the cookie value;

[0203] The second DHCP verification further includes a fourth Option field, and the fourth Option field includes a second DTLS handshake field for carrying the first encryption attribute information.

[0204] Optionally, the second DHCP request further includes a fifth Option field, and the fifth Option field includes a third DTLS handshake field for carrying the cookie value;

[0205] The third DHCP request further includes a sixth Option field, and the sixth Option field includes a fourth DTLS handshake field for carrying the key generation result.

[0206] Therefore, by applying the communication device provided in this application, in a layer-2 network, the DHCP client broadcasts and sends a first DHCP request; when receiving first DHCP validations sent by multiple DHCP servers according to the first DHCP request, the DHCP client selects a target DHCP server from the multiple DHCP servers that send the first DHCP validation; the DHCP client sends a second DHCP request to the target DHCP server, and the second DHCP request includes a cookie value and an identifier of the target DHCP server, and the cookie value is generated by the target DHCP server and carried in the first DHCP validation; the DHCP client receives a second DHCP validation sent by the target DHCP server after the cookie value and the identifier are verified to be passed, and the second DHCP validation includes first encryption attribute information used by the target DHCP server to generate a first key; according to the first encryption attribute information of the target DHCP server, the DHCP client generates a second key, and the second key is used to encrypt and decrypt a complete DHCP message when the DHCP client interacts with the target DHCP server again through the second key; the DHCP client sends a third DHCP request to the target DHCP server, and the third DHCP request includes a key generation result, so that the target DHCP server determines that when the target DHCP server interacts with the DHCP client again through the second key, the complete DHCP message is encrypted and decrypted through the second key.

[0207] In this way, by using the interaction process of the DTLS protocol, the DHCP client and the DHCP server exchange encryption attribute information by using a newly defined DHCP message and generate a key, and then perform complete encryption and decryption processing on subsequent DHCP messages. At the same time, it also solves the problem that the existing encryption technology for interacting messages of the DHCP protocol has the risk of exposing user information.

[0208] Based on the same inventive concept, the embodiment of this application also provides another communication device corresponding to another communication method. Refer to Figure 6 , Figure 6 which is another communication device provided by the embodiment of this application. The device is applied to a DHCP server, and the device includes:

[0209] A receiving unit 610, configured to receive a first DHCP request sent by a DHCP client;

[0210] A sending unit 620, configured to send a first DHCP validation to the DHCP client according to the first DHCP request, where the first DHCP validation includes a cookie value and an identifier of the DHCP server;

[0211] A generating unit, configured to generate a first key according to first encryption attribute information if the receiving unit 610 receives a second DHCP request sent by the DHCP client and the cookie value and the identifier included in the second DHCP request pass the verification;

[0212] The sending unit 620 is further configured to send a second DHCP verification to the DHCP client, where the second DHCP verification includes the first encryption attribute information of the DHCP server, and the first encryption attribute information is used to enable the DHCP client to generate a second key;

[0213] The receiving unit 610 is further configured to receive a third DHCP request sent by the DHCP client, where the third DHCP request includes a key generation result;

[0214] Wherein, the first key is used to encrypt and decrypt the complete DHCP message through the first key when the DHCP server and the DHCP client interact with the DHCP message again; the second key is used to encrypt and decrypt the complete DHCP message through the second key when the DHCP client and the DHCP server interact with the DHCP message again

[0215] Optionally, the DHCP request includes a first Option field, and the first Option field includes a first coding field and a first value field;

[0216] The value of the first coding field is 53, and the value of the first value field is 14;

[0217] The DHCP verification includes a second Option field, and the second Option field includes a second coding field and a second value field;

[0218] The value of the second coding field is 53, and the value of the second value field is 15.

[0219] Optionally, the DHCP request includes a first Message type field, and the value of the first Message type field is any value in a first range;

[0220] The DHCP verification includes a second Message type field, and the value of the second Message type field is any value in the first range;

[0221] The value of the second Message type field is different from the value of the first Message type field;

[0222] Wherein, the starting value of the first range is 38 and the ending value is 255.

[0223] Optionally, the first DHCP authentication includes a third Option field, and the third Option field includes a first DTLS handshake field for carrying the cookie value.

[0224] The second DHCP authentication includes a fourth Option field, and the fourth Option field includes a second DTLS handshake field for carrying the first encrypted attribute information.

[0225] Optionally, the second DHCP request includes a fifth Option field, and the fifth Option field includes a third DTLS handshake field for carrying the cookie value.

[0226] The third DHCP request includes a sixth Option field, and the sixth Option field includes a fourth DTLS handshake field for carrying the key generation result.

[0227] Therefore, by applying the communication device provided in this application, the DHCP server receives a first DHCP request sent by the DHCP client; according to the first DHCP request, the DHCP server sends a first DHCP authentication to the DHCP client, and the first DHCP authentication includes a cookie value and an identifier of the DHCP server; if the DHCP server receives a second DHCP request sent by the DHCP client and the cookie value and identifier included in the second DHCP request pass the verification, the DHCP server generates a first key according to the first encrypted attribute information; the DHCP server sends a second DHCP authentication to the DHCP client, and the second DHCP authentication includes the first encrypted attribute information of the DHCP server, and the first encrypted attribute information is used to enable the DHCP client to generate a second key; the DHCP server receives a third DHCP request sent by the DHCP client, and the third DHCP request includes a key generation result; wherein, the first key is used to encrypt and decrypt the complete DHCP message through the first key when the DHCP server and the DHCP client interact with the DHCP message again; the second key is used to encrypt and decrypt the complete DHCP message through the second key when the DHCP client and the DHCP server interact with the DHCP message again.

[0228] In this way, through the interaction process of the DTLS protocol, the DHCP client and the DHCP server exchange encrypted attribute information using the newly defined DHCP message and generate a key, and then perform complete encryption and decryption processing on subsequent DHCP messages. At the same time, it also solves the problem that the existing encryption technology for DHCP protocol interaction messages has the risk of exposing user information.

[0229] Based on the same inventive concept, an embodiment of the present application further provides a network device, such as Figure 7 shown, including a processor 710, a transceiver 720, and a machine-readable storage medium 730. The machine-readable storage medium 730 stores machine-executable instructions that can be executed by the processor 710. The processor 710 is prompted by the machine-executable instructions to execute the communication method provided by the embodiment of the present application. The foregoing Figure 5 , Figure 6 shown communication device can be implemented by using the hardware structure of the network device as Figure 7 shown.

[0230] The above computer-readable storage medium 730 may include a random access memory (English: Random Access Memory, abbreviated as: RAM), and may also include a non-volatile memory (English: Non-volatile Memory, abbreviated as: NVM), such as at least one disk memory. Optionally, the computer-readable storage medium 730 may also be at least one storage device located far from the foregoing processor 710.

[0231] The above processor 710 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), etc.; it may also be a digital signal processor (English: Digital Signal Processor, abbreviated as: DSP), an application-specific integrated circuit (English: Application Specific Integrated Circuit, abbreviated as: ASIC), a field-programmable gate array (English: Field-Programmable Gate Array, abbreviated as: FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components.

[0232] In an embodiment of the present application, the processor 710 reads the machine-executable instructions stored in the machine-readable storage medium 730 and is prompted by the machine-executable instructions to be able to implement the processor 710 itself and call the transceiver 720 to execute the communication method described in the foregoing embodiment of the present application.

[0233] In addition, an embodiment of the present application provides a machine-readable storage medium 730. The machine-readable storage medium 730 stores machine-executable instructions, which, when called and executed by the processor 710, cause the processor 710 itself and the transceiver 720 to execute the communication method described in the foregoing embodiments of the present application.

[0234] For the specific implementation process of the functions and roles of each unit in the above device, please refer to the implementation process of the corresponding steps in the above method, which will not be elaborated here.

[0235] For the device embodiment, since it basically corresponds to the method embodiment, the relevant parts can be referred to the partial description of the method embodiment. The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed to multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution of the present application. Those of ordinary skill in the art can understand and implement it without creative efforts.

[0236] For the communication device and the machine-readable storage medium embodiments, since the method content involved is basically similar to the foregoing method embodiments, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiments.

[0237] The foregoing is only a preferred embodiment of the present application and is not intended to limit the present application. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principle of the present application shall be included in the scope of protection of the present application.

Claims

1. A communication method, characterized in that: The method is applied to a DHCP client, and the method comprises: In the Layer 2 network, the first DHCP request is sent by broadcast; When receiving a first DHCP authentication sent by multiple DHCP servers according to the first DHCP request, selecting a target DHCP server from the multiple DHCP servers sending the first DHCP authentication; Sending a second DHCP request to the target DHCP server, the second DHCP request including a cookie value and an identifier of the target DHCP server, the cookie value being generated by the target DHCP server and carried in the first DHCP authentication; receiving a second DHCP authentication sent by the target DHCP server after the cookie value and the identifier are authenticated, wherein the second DHCP authentication includes first encryption attribute information used by the target DHCP server to generate a first key; Generate a second key according to the first encryption attribute information of the target DHCP server, wherein the second key is used to encrypt and decrypt the complete DHCP message by using the second key when exchanging DHCP messages with the target DHCP server again; A third DHCP request is sent to the target DHCP server, where the third DHCP request includes a key generation result, so that when the target DHCP server determines, based on the key generation result, that the target DHCP server exchanges DHCP messages with the DHCP client again, the first key is used to encrypt and decrypt the complete DHCP message.

2. The method according to claim 1, characterized in that The DHCP request includes a first Option field, wherein the first Option field includes a first encoding field and a first value field; The value of the first encoding field is 53, and the value of the first value field is 14; The DHCP authentication includes a second Option field, wherein the second Option field includes a second encoding field and a second value field; The value of the second encoding field is 53, and the value of the second value field is 15.

3. The method according to claim 1, characterized in that The DHCP request includes a first Message type field, and a value of the first Message type field is any value in a first interval; The DHCP authentication includes a second Message type field, and a value of the second Message type field is any value in the first interval; A value of the second Message type field is different from a value of the first Message type field; The starting value of the first interval is 38 and the ending value is 255.

4. The method according to claim 3, characterized in that The first DHCP authentication further includes a third Option field, the third Option field includes a first DTLS handshake field, and the first DTLS handshake field is used to carry the cookie value; The second DHCP authentication further includes a fourth Option field, the fourth Option field includes a second DTLS handshake field, and the second DTLS handshake field is used to carry the first encryption attribute information.

5. The method according to claim 1, characterized in that The second DHCP request further includes a fifth Option field, the fifth Option field includes a third DTLS handshake field, and the third DTLS handshake field is used to carry the cookie value; The third DHCP request further includes a sixth Option field, the sixth Option field includes a fourth DTLS handshake field, and the fourth DTLS handshake field is used to carry the key generation result.

6. A communication method, characterized in that: The method is applied to a DHCP server, and the method comprises: Receive a first DHCP request sent by a DHCP client; Sending a first DHCP verification to the DHCP client according to the first DHCP request, wherein the first DHCP verification includes a cookie value and an identifier of the DHCP server; If a second DHCP request sent by the DHCP client is received and the cookie value and the identifier included in the second DHCP request are verified, generating a first key according to the first encryption attribute information; Sending a second DHCP authentication to the DHCP client, wherein the second DHCP authentication includes first encrypted attribute information of the DHCP server, and the first encrypted attribute information is used to enable the DHCP client to generate a second key; receiving a third DHCP request sent by the DHCP client, wherein the third DHCP request includes a key generation result; The first key is used for encrypting and decrypting the complete DHCP message when the DHCP server and the DHCP client exchange DHCP messages again; the second key is used for encrypting and decrypting the complete DHCP message when the DHCP client and the DHCP server exchange DHCP messages again.

7. The method according to claim 6, characterized in that The DHCP request includes a first Option field, wherein the first Option field includes a first encoding field and a first value field; The value of the first encoding field is 53, and the value of the first value field is 14; The DHCP authentication includes a second Option field, wherein the second Option field includes a second encoding field and a second value field; The value of the second encoding field is 53, and the value of the second value field is 15.

8. The method according to claim 6, characterized in that The DHCP request includes a first Message type field, and a value of the first Message type field is any value in a first interval; The DHCP authentication includes a second Message type field, and a value of the second Message type field is any value in the first interval; A value of the second Message type field is different from a value of the first Message type field; The starting value of the first interval is 38 and the ending value is 255.

9. The method according to claim 6, characterized in that The first DHCP authentication includes a third Option field, the third Option field includes a first DTLS handshake field, and the first DTLS handshake field is used to carry the cookie value; The second DHCP authentication includes a fourth Option field, the fourth Option field includes a second DTLS handshake field, and the second DTLS handshake field is used to carry the first encryption attribute information.

10. The method according to claim 6, characterized in that The second DHCP request includes a fifth Option field, the fifth Option field includes a third DTLS handshake field, and the third DTLS handshake field is used to carry the cookie value; The third DHCP request includes a sixth Option field, the sixth Option field includes a fourth DTLS handshake field, and the fourth DTLS handshake field is used to carry the key generation result.

11. A communication device, characterized in that: The device is applied to a DHCP client, and comprises: a sending unit, a selecting unit, a receiving unit and a generating unit; The sending unit is used to broadcast and send the first DHCP request in the layer 2 network; The selection unit is configured to select a target DHCP server from the multiple DHCP servers that send the first DHCP verification when the receiving unit receives the first DHCP verification sent by the multiple DHCP servers according to the first DHCP request; The sending unit is further configured to send a second DHCP request to the target DHCP server, wherein the second DHCP request includes a cookie value and an identifier of the target DHCP server, wherein the cookie value is generated by the target DHCP server and carried in the first DHCP authentication; The receiving unit is configured to receive a second DHCP verification sent by the target DHCP server after verifying the cookie value and the identifier, wherein the second DHCP verification includes first encryption attribute information used by the target DHCP server to generate a first key; The generating unit is configured to generate a second key according to the first encryption attribute information of the target DHCP server, wherein the second key is used to encrypt and decrypt the complete DHCP message by using the second key when exchanging DHCP messages with the target DHCP server again; The sending unit is further configured to send a third DHCP request to the target DHCP server, wherein the third DHCP request includes a key generation result, so that when the target DHCP server determines, based on the key generation result, that the target DHCP server exchanges a DHCP message with the DHCP client again, the first key is used to perform encryption and decryption processing on the complete DHCP message.

12. A communication device, characterized in that: The device is applied to a DHCP server, and the device comprises: A receiving unit, configured to receive a first DHCP request sent by a DHCP client; A sending unit, configured to send a first DHCP verification to the DHCP client according to the first DHCP request, wherein the first DHCP verification includes a cookie value and an identifier of the DHCP server; a generating unit, configured to generate a first key according to the first encryption attribute information if the receiving unit receives the second DHCP request sent by the DHCP client and the cookie value and the identifier included in the second DHCP request pass verification; The sending unit is further used to send a second DHCP authentication to the DHCP client, where the second DHCP authentication includes first encrypted attribute information of the DHCP server, and the first encrypted attribute information is used to enable the DHCP client to generate a second key; The receiving unit is further configured to receive a third DHCP request sent by the DHCP client, wherein the third DHCP request includes a key generation result; The first key is used for encrypting and decrypting the complete DHCP message when the DHCP server and the DHCP client exchange DHCP messages again; the second key is used for encrypting and decrypting the complete DHCP message when the DHCP client and the DHCP server exchange DHCP messages again.

Images