Communication method and device

Abstract

The invention provides a communication method and device, and the method comprises the steps: carrying out the key negotiation with a target Portal server when a configured strategy template is bound, and building DTLS connection; the first registration message is sent to the NAT device through the DTLS connection, so that the NAT device sends a second registration message to the target Portal server after performing NAT conversion on the first registration message, and the target Portal server generates a registration table item according to the second registration message; and when the accessed user equipment initiates a request for accessing a network resource, interacting a Portal protocol message with the target Portal server through the DTLS connection and the NAT equipment, and carrying out Portal authentication.

Description

Technical Field

[0001] The present application relates to the field of communication technology, and in particular to a communication method and device. Background Art

[0002] Portal authentication, also commonly known as web authentication, is a mechanism used for network access control. It requires users to authenticate themselves before gaining access to network resources. As a network access control technology, portal authentication plays a vital role in ensuring secure access to network resources.

[0003] Portal authentication is usually deployed at the access layer and at the entrance of key data that needs to be protected, and access control is implemented. In a networking environment that uses Portal authentication, user devices can actively access known Portal server websites through access devices to initiate Portal authentication, or they can access any non-Portal server website through access devices, and then be forced to access the Portal server website, and then initiate Portal authentication.

[0004] In the communication interaction between the access device and the Portal server, the Portal server uses the protocol message to authenticate the user in order to control the user's access. In the existing Portal protocol, it is stipulated that the protocol message should be carried on the basis of the User Datagram Protocol (UDP) message, which consists of a fixed-length header and a variable-length attribute field.

[0005] However, if the Portal server is remote, when the access device interacts with it, the protocol messages sent and received by both parties will be transmitted across the public network. Since the UDP message only encrypts the password part it carries, and the other fields are all exchanged in plain text, this will lead to unsafe risks such as protocol message loss and interception during the Portal authentication process. Summary of the invention

[0006] In view of this, the present application provides a communication method and device to solve the problem of unsafe hidden dangers such as protocol message loss and interception in the existing Portal authentication process because the protocol message is carried by UDP message and the UDP message is exchanged in plain text.

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

[0008] When binding the configured policy template, perform key negotiation with the target Portal server and establish a DTLS connection;

[0009] Sending a first registration message to a NAT device through the DTLS connection, so that the NAT device performs NAT conversion on the first registration message and then sends a second registration message to the target Portal server, and the target Portal server generates a registration entry according to the second registration message;

[0010] When the accessed user equipment initiates a request to access network resources, the DTLS connection and the NAT device are used to interact with the target Portal server to send a first Portal protocol message to the NAT device, and perform Portal authentication;

[0011] The first registration message, the second registration message, and the Portal protocol message are all encrypted messages that are encrypted using the key and encryption algorithm after the key negotiation.

[0012] In a second aspect, the present application provides a communication device, which is applied to an access device, and the device includes:

[0013] An establishment unit is used to perform key negotiation with a target Portal server and establish a DTLS connection when binding a configured policy template;

[0014] A sending unit, configured to send a first registration message to a NAT device through the DTLS connection, so that the NAT device performs NAT conversion on the first registration message and then sends a second registration message to the target Portal server, and the target Portal server generates a registration entry according to the second registration message;

[0015] The sending unit is further configured to, when the accessed user equipment initiates a request to access network resources, exchange Portal protocol messages with the target Portal server through the DTLS connection and the NAT device, and perform Portal authentication;

[0016] The first registration message, the second registration message, and the Portal protocol message are all encrypted messages that are encrypted using the key and encryption algorithm after the key negotiation.

[0017] In a third aspect, the present application provides a network device, including a processor and a machine-readable storage medium, the machine-readable storage medium storing 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.

[0018] Therefore, by applying the communication method and device provided by the present application, when the configured policy template is bound, the access device performs key negotiation with the target Portal server and establishes a DTLS connection; through the DTLS connection, the access device sends a first registration message to the NAT device, so that the NAT device performs NAT conversion on the first registration message and then sends a second registration message to the target Portal server, and the target Portal server generates a registration entry according to the second registration message; when the accessed user device initiates a request to access network resources, the access device exchanges Portal protocol messages with the target Portal server through the DTLS connection and the NAT device, and performs Portal authentication; wherein the first registration message, the second registration message, and the Portal protocol message are all encrypted messages encrypted using the key and encryption algorithm after key negotiation.

[0019] In this way, in the scenario where the access device and the remote Portal server are transmitted across the public network, the access device establishes a DTLS connection with the Portal server, and realizes that in the subsequent Portal authentication process, the Portal protocol messages exchanged between each other are encrypted and transmitted. In this way, the access device and the Portal server are easy to connect, and the Portal authentication is more secure. In addition, the DTLS mode of single Socket communication and multiple sessions is used on the access device, which brings security while also reducing the management cost of the Portal server to maintain a large number of Socket communications. It also solves the problem of unsafe hidden dangers such as protocol message loss and interception in the existing Portal authentication process because the protocol message is carried by UDP message and UDP message is interacted in plain text. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Figure 1 A flow chart of a communication method provided in an embodiment of the present application;

[0021] Figure 2 A signaling diagram of a communication method provided in an embodiment of the present application;

[0022] Figure 3 A structural diagram of a communication device provided in an embodiment of the present application;

[0023] Figure 4 The network device hardware structure provided in the embodiment of the present application. DETAILED DESCRIPTION

[0024] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying 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.

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

[0026] It should be understood that although the terms first, second, third, etc. may be used in the present application to describe various information, these information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of the present 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 "at the time of" or "when" or "in response to determining".

[0027] The communication method provided in the embodiment of the present application is described in detail below. Figure 1 , Figure 1 A flow chart of a communication method provided in an embodiment of the present application. The method is applied to an access device. The communication method provided in an embodiment of the present application may include the following steps.

[0028] Step 110: When binding the configured policy template, perform key negotiation with the target Portal server and establish a DTLS connection;

[0029] Specifically, through the local area network, the user device accesses the interface of the access device, and the interface enables Portal authentication. The access device is connected to a network address translation (English: Network Address Translation, referred to as: NAT) device, and the NAT device is connected to the Portal server through the public network.

[0030] The Portal process is started in the access device to implement Portal authentication for the user device.

[0031] A policy template has been configured in the access device, which includes information such as multiple encryption algorithms, public key infrastructure (PKI), version models, etc. The version model specifically refers to the version model of the Datagram Transport Layer Security (DTLS) and Transport Layer Security (TLS) connections supported by the access device.

[0032] After the Portal process is bound to the policy template, the access device negotiates keys with the target Portal server and establishes a DTLS connection.

[0033] The following is a brief description of the process of key negotiation and DTLS connection establishment between the access device and the target Portal server.

[0034] A handshake connection is established between the access device and the target Portal server. During the handshake process, the identity of the other party is verified, and the key and encryption suite negotiation are completed to encrypt data in subsequent data transmission.

[0035] Initial Hello negotiation process:

[0036] The access device sends a ClientHello message to the target Portal server to start the handshake process. The ClientHello message includes information such as the DTLS version and encryption suite supported by the access device. After receiving the ClientHello message, the target Portal server sends a HelloVerifyRequest message to the access server. The HelloVerifyRequest message includes information such as the DTLS version, encryption suite, and cookie information selected by the target Portal server.

[0037] At this point, the initial Hello negotiation process between the access device and the target Portal server is completed.

[0038] Second Hello negotiation process:

[0039] The access device sends a Client Hello message to the target Portal server again. The Client Hello message includes the encryption suite, the Cookie sent by the target Portal server, and a random number (Random). After receiving the Client Hello message, the target Portal server verifies whether the Cookie is legal. If the Cookie is legal, it continues to handshake with the access device and sends ServerHello to the access device; if the Cookie is illegal, the target Portal server refuses to establish a connection with the access device. The target Portal server continues to send Certificate messages to the access device. The Certificate message includes a digital certificate of the target Portal server's own public key information so that the access device can authenticate the target Portal server. The target Portal server continues to send ServerKeyExchange messages to the access device. The ServerKeyExchange messages include the target Portal server's own temporary public key. The target Portal server continues to send CertificateRequest messages to the access device. The CertificateRequest message is used to enable the access device to provide a digital certificate of its own public key information so that the target Portal server can authenticate the access device. The target Portal server continues to send ServerHelloDone messages to the access device. The ServerHelloDone message is used to notify the access device that the DTLS version and encryption suite negotiation process is complete and key exchange has begun.

[0040] At this point, the secondary Hello negotiation process between the access device and the target Portal server is completed.

[0041] Key negotiation process:

[0042] The access device sends a Certificate message to the target Portal server. The Certificate message includes the digital certificate of the access device's own public key information. After the access device obtains the digital certificate of the target Portal server's own public key information, it verifies whether the digital certificate of the target Portal server's own public key information is legal. If it is legal, the access device uses the public key in the digital certificate to encrypt the key randomly generated by the client access device, and continues to send a ClientKeyExchange message to the target Portal server. The ClientKeyExchange message includes the encrypted key. The access device continues to send a CertificateVerify message to the target Portal server. The CertificateVerify message is used by the target Portal server to authenticate the access device. The access device continues to send a ChangeCipherSpec message to the target Portal server. The ChangeCipherSpec message is used to notify the target Portal server that subsequent messages will be encrypted using the negotiated key and encryption suite. The access device continues to send a Finished message to the target Portal server. The Finished message is used to notify the target Portal server that the handshake process is over. The target Portal server sends a ChangeCipherSpec message to the access device. The ChangeCipherSpec message is used to inform the access device that subsequent messages will be encrypted using the negotiated key and encryption suite. The target Portal server continues to send a Finished message to the access device. The Finished message is used to inform the access device that the handshake process is over.

[0043] At this point, the key negotiation process between the access device and the target Portal server is completed.

[0044] After the access device successfully handshakes with the target Portal server, the access device also completes the identity authentication of the target Portal server. This is because the target Portal server with the private key can decrypt the key from the ClientKeyExchange message, thereby achieving a subsequent successful handshake.

[0045] Step 120: Send a first registration message to a NAT device through the DTLS connection, so that the NAT device performs NAT conversion on the first registration message and then sends a second registration message to the target Portal server, and the target Portal server generates a registration entry according to the second registration message;

[0046] Specifically, according to the description of step 110, after the access device establishes a DTLS connection with the target Portal server, the access device generates a first registration message. The first registration message includes the device name (eg, device ID) of the access device.

[0047] Through the DTLS connection, the access device sends a first registration message to the NAT device. After receiving the first registration message, the NAT device performs NAT conversion on the first registration message to obtain a second registration message. The NAT device continues to send the second registration message to the target Portal server.

[0048] After receiving the second registration message, the target Portal server generates a registration entry corresponding to the access device according to the second registration message. The registration entry includes information such as the name of the access device, the IP address after NAT conversion, and the port number. The target Portal server generates the registration entry to determine the access device and obtain the IP address and port number information of the access device after NAT conversion when sending a Portal protocol message to the access device in the future.

[0049] In the embodiment of the present application, the first registration message is a UDP message, which includes a UDP header and a data field. After the access device establishes a DTLS connection with the target Portal server, the complete data field in the UDP message is encrypted by using the key, encryption algorithm and other information negotiated during the DTLS connection establishment process. The first registration message is also an encrypted message.

[0050] It should be noted that the UDP header is not encrypted. When the NAT device performs NAT conversion on the first registration message, it performs NAT conversion on the source Internet Protocol (IP) address and source port, and does not process the encrypted data field to obtain the second registration message. The second registration message is also an encrypted message.

[0051] Step 130: When the accessed user device initiates a request to access network resources, Portal protocol messages are exchanged with the target Portal server through the DTLS connection and the NAT device, and Portal authentication is performed.

[0052] Specifically, according to the description of step 120, after the access device sends the first registration message to the NAT device, when the accessed user device initiates a request to access network resources (for example, through the login page of the target Portal server, sending a POST request of http / https (carrying a user name and password) to the target Portal server), through the established DTLS connection and the NAT device, the access device exchanges Portal protocol messages with the target Portal server and performs Portal authentication (for example, after receiving the POST request, the target Portal server generates a Portal protocol message. According to the registration entry generated locally in advance, the target Portal server obtains the SSL session that carries the DTLS connection corresponding to the access device. Through the DTLS connection, the target Portal server sends a Portal protocol message to the access device for Portal authentication).

[0053] It should be noted that the process of the user equipment initiating a request to access network resources and the access device performing Portal authentication with the target Portal server is the same as the existing process of initiating an access request and Portal authentication, and will not be described in detail here.

[0054] In the application embodiment, through the established DTLS connection, the access device and the target Portal server can encrypt any Portal protocol message and send it to the NAT device.

[0055] For example, the target Portal server sends a first Portal protocol message to the NAT device. Similarly, similar to the description in the aforementioned step 120, after receiving the first Portal protocol message, the NAT device performs NAT conversion on the first Portal protocol message to obtain a second Portal protocol message. The NAT device continues to send the second Portal protocol message to the access device.

[0056] After receiving the second Portal protocol message, the access device continues to perform Portal authentication. It is understandable that when performing Portal authentication, the access device may also encrypt any Portal protocol message and send it to the NAT device.

[0057] In the embodiment of the present application, the above-mentioned Portal protocol messages are also UDP messages, which include a UDP header and a data field. After the DTLS connection is established, the access device and the target Portal server encrypt the complete data field in the UDP message through the key, encryption algorithm and other information negotiated during the establishment of the DTLS connection. The above-mentioned Portal protocol messages are also encrypted messages.

[0058] It should be noted that the UDP header is not encrypted. When the NAT device performs NAT conversion on the Portal protocol message, it performs NAT conversion on the source IP address and source port, and does not process the encrypted data field to obtain the Portal protocol message after NAT conversion. The Portal protocol message after NAT conversion is also an encrypted message.

[0059] Optionally, in the embodiment of the present application, a process is also included in which the access device periodically sends a registration message.

[0060] Specifically, after sending the first registration message to the NAT device, the access device periodically generates a registration message, for example, every 10 seconds by default.

[0061] The access device generates a third registration message. The third registration message includes the device name (eg, device ID) of the access device.

[0062] Through the DTLS connection, the access device sends the third registration message to the NAT device. After receiving the third registration message, the NAT device performs NAT conversion on the third registration message to obtain a fourth registration message. The NAT device continues to send the fourth registration message to the target Portal server.

[0063] After receiving the fourth registration message, the target portal server updates the registration item corresponding to the access device according to the fourth registration message. The registration item includes information such as the name of the access device, the IP address after NAT conversion, and the port number.

[0064] In the embodiment of the present application, the third registration message is a UDP message, which includes a UDP header and a data field. After the access device establishes a DTLS connection with the target Portal server, the complete data field in the UDP message is encrypted by using the key, encryption algorithm and other information negotiated during the DTLS connection establishment process. The third registration message is also an encrypted message.

[0065] It should be noted that the UDP header is not encrypted. When the NAT device performs NAT conversion on the third registration message, it performs NAT conversion on the source IP address and source port, and does not process the encrypted data field, thereby obtaining the fourth registration message. The fourth registration message is also an encrypted message.

[0066] like Figure 2 As shown, Figure 2 A signaling diagram of a communication method provided in an embodiment of the present application. Figure 2 In the example, the access device first establishes a DTLS connection with the target Portal server. After the DTLS connection is established, the access device generates and sends a registration message 1 to the NAT device through the DTLS connection.

[0067] After receiving Registration Message 1, the NAT device performs NAT conversion on the source IP address 1 (private network IP) and source port 1 (private network port) included in Registration Message 1 to obtain Registration Message 2, which includes the converted source IP address 2 (public network IP) and source port 2 (public network port). The NAT device continues to send Registration Message 2 to the target Portal server.

[0068] After receiving the registration message 2, the target Portal server generates a registration entry corresponding to the access device according to the registration message 2, and saves the registration entry locally.

[0069] When an access user device initiates a request to access network resources, the target Portal server and access device can encrypt any Portal protocol message and send it to the NAT device through a DTLS connection. After the NAT device performs NAT translation, the NAT-translated Portal protocol message is sent to the peer end.

[0070] After sending registration message 1 to the NAT device, the access device generates and sends registration message 3 to the NAT device again every 10 seconds.

[0071] Through the DTLS connection, the access device sends registration message 3 to the NAT device. After receiving registration message 3, the NAT device performs NAT conversion on the source IP address 1 (private network IP) and source port 1 (private network port) included in registration message 3 to obtain registration message 4, which includes the converted source IP address 3 (public network IP) and source port 4 (public network port). The NAT device continues to send registration message 4 to the target Portal server.

[0072] NAT devices in the network are usually operator devices, and the NAT mapping rules configured on the NAT devices change according to the operator's plan. For example, during the time period from 0:00 to 6:00, the NAT mapping rule converts source IP address 1 to source IP address 2; during the time period from 6:00 to 12:00, the NAT mapping rule converts source IP address 1 to source IP address 3, and so on.

[0073] After receiving the registration message 4, the target Portal server updates the registration entry corresponding to the access device according to the registration message 4.

[0074] In the embodiment of the present application, the above-mentioned registration messages 1-4 are all UDP messages, which include a UDP header and a data field. After the access device establishes a DTLS connection with the target Portal server, it encrypts the complete data field in the UDP message through the key, encryption algorithm and other information negotiated during the DTLS connection establishment process.

[0075] It should be noted that the UDP header is not encrypted. When the NAT device performs NAT conversion on the registration message 1 and the registration message 3, it performs NAT conversion on the source IP address and the source port, and does not process the encrypted data field.

[0076] Optionally, in the embodiment of the present application, the process of disconnecting the DTLS connection between the access device and the target Portal server is also included.

[0077] Specifically, after the user device completes the Portal authentication, the access device disables the policy template and disconnects the DTLS connection. The access device also generates a first close notification and sends the first close notification to the NAT device again, so that the NAT device forwards the first close notification through NAT and then sends a second close notification to the target Portal server.

[0078] After receiving the shutdown notification, the target Portal server disconnects the DTLS connection.

[0079] Among them, the above-mentioned first closing notification and second closing notification are both encrypted messages.

[0080] It should be noted that the DTLS connection is carried on the SSL session between the access device and the target Portal server. Therefore, when the access device disconnects the DTLS connection, it can destroy the SSL session that carries the DTLS connection. When the target Portal server disconnects the DTLS connection, it can also destroy the SSL session that carries the DTLS connection after receiving the shutdown notification. If the target Portal server does not receive the shutdown notification, it can also determine that the DTLS connection with the access device has been disconnected after the preset time arrives, and destroy the SSL session that carries the DTLS connection by itself.

[0081] It is understandable that when the access device encrypts the first close notification, it can use the encryption method of the existing SSL protocol to encrypt the first close notification, which will not be repeated here.

[0082] Similarly, when the access device establishes a DTLS connection with the target Portal server, both parties encrypt the sent messages. The sent messages can also be encrypted using the encryption method of the existing SSL protocol, which will not be repeated here.

[0083] Optionally, in an embodiment of the present application, before the access device sends the first registration message to the NAT device through the DTLS connection, the access device also executes a process of determining to call the DTLS connection through a local mapping relationship table.

[0084] Specifically, the IP addresses of multiple Portal servers can be configured in the access device. According to the IP address of each Portal server, the access device can respectively communicate with different Portal servers via different interfaces via sockets, and on the socket communication, the access device creates a secure socket layer (English: Secure Sockets Layer, referred to as: SSL) session with each Portal server.

[0085] The created SSL session may be specifically a data structure, such as a memory block, in which SSL session information is stored, such as device information (IP addresses) at both ends, session ID, carried DTLS information, and the like.

[0086] After creating the SSL session, the access device also generates a mapping table entry locally, which includes the IP address of the Portal server and a pointer to the data structure. The access device stores the multiple mapping table entries in the local mapping table.

[0087] In the embodiment of the present application, the access device can use one of the multiple Portal servers as the target Portal server according to the configuration instruction of the administrator (for example, the configuration instruction includes the IP address of the Portal server).

[0088] On the SSL session established with the target Portal server, the access device creates a DTLS connection with the target Portal server (the specific creation process can be implemented by the description in the aforementioned embodiment). At the same time, the access device can obtain a mapping table entry that matches the IP address of the target Portal server from the local mapping table according to the IP address of the target Portal server. Through a pointer to the data structure, the access device accesses the data structure and updates the stored SSL session information.

[0089] Before sending the first registration message to the target Portal server, the access device can also obtain the mapping table entry matching the IP address of the target Portal server from the local mapping table again according to the IP address of the target Portal server. Through the pointer pointing to the data structure, the access device accesses the data structure block to call the corresponding SSL session and call the DTLS connection on the SSL session.

[0090] Subsequently, the access device can send various encrypted messages to the target Portal server over the invoked DTLS connection.

[0091] Furthermore, a SocketA is configured in the access device, and according to different applicable networks, the SocketA includes SocketA1 applicable to the IPv4 network and SocketA2 applicable to the IPv6 network. Similarly, a SocketB is configured in each Portal server, and according to different applicable networks, the SocketB includes SocketB1 applicable to the IPv4 network and SocketB2 applicable to the IPv6 network.

[0092] In the embodiment of the present application, the messages exchanged between the access device and the Portal server are all carried by the UDP protocol, that is, they are all UDP messages. However, the UDP protocol has no connection at the transmission level, so the access device communicates with the SocketB corresponding to each Portal server through the above-mentioned SocketA. For example, during communication, SocketA calls the sent to() function to send a message to the IP address of the Portal server, and the Portal server receives the message through SocketB.

[0093] For example, Portal server 1 is adapted to IPv4 network, and Portal server 2 is also adapted to IPv4 network. When communicating with Portal server 1 and Portal server 2, the access device communicates with SocketB1 of Portal server 1 and Portal server 2 respectively through the same SocketA1 adapted to IPv4 network.

[0094] It can be understood that in the above example, after SocketA1 communicates with SocketB1 of Portal Server 1 and Portal Server 2, multiple SSL sessions are created on SocketA1. For example, SocketA1 carries two SSL sessions, namely, SSL session 1 created with Portal Server 1 and SSL session 2 created with Portal Server 2. A DTLS connection is created on each SSL session, that is, DTLS connection 1 is carried on SSL session 1, and DTLS connection 2 is carried on SSL session 2.

[0095] Therefore, by applying the communication method provided by the present application, when the configured policy template is bound, the access device performs key negotiation with the target Portal server and establishes a DTLS connection; through the DTLS connection, the access device sends a first registration message to the NAT device, so that the NAT device performs NAT conversion on the first registration message and then sends a second registration message to the target Portal server, and the target Portal server generates a registration entry according to the second registration message; when the accessed user device initiates a request to access network resources, the access device exchanges Portal protocol messages with the target Portal server through the DTLS connection and the NAT device, and performs Portal authentication; wherein the first registration message, the second registration message, and the Portal protocol message are all encrypted messages encrypted using the key and encryption algorithm after key negotiation.

[0096] In this way, in the scenario where the access device and the remote Portal server are transmitted across the public network, the access device establishes a DTLS connection with the Portal server, and realizes that in the subsequent Portal authentication process, the Portal protocol messages exchanged between each other are encrypted and transmitted. In this way, the access device and the Portal server are easy to connect, and the Portal authentication is more secure. In addition, the DTLS mode of single Socket communication and multiple sessions is used on the access device, which brings security while also reducing the management cost of the Portal server to maintain a large number of Socket communications. It also solves the problem of unsafe hidden dangers such as protocol message loss and interception in the existing Portal authentication process because the protocol message is carried by UDP message and UDP message is interacted in plain text.

[0097] Based on the same inventive concept, the present application embodiment also provides a communication device corresponding to the communication method. Figure 3 , Figure 3 A communication device provided in an embodiment of the present application is applied to an access device, and the device includes:

[0098] An establishing unit 310 is used to perform key negotiation with a target Portal server and establish a DTLS connection when binding the configured policy template;

[0099] A sending unit 320 is configured to send a first registration message to a NAT device through the DTLS connection, so that the NAT device performs NAT conversion on the first registration message and then sends a second registration message to the target Portal server, and the target Portal server generates a registration entry according to the second registration message;

[0100] The sending unit 320 is further configured to, when the accessed user equipment initiates a request to access network resources, exchange Portal protocol messages with the target Portal server through the DTLS connection and the NAT device, and perform Portal authentication;

[0101] The first registration message, the second registration message, and the first Portal protocol message are all encrypted messages that are encrypted using the key and encryption algorithm after the key negotiation.

[0102] Optionally, the device further comprises:

[0103] a disconnection unit (not shown in the figure), configured to locally disconnect the DTLS connection when unbinding the policy template;

[0104] The sending unit 320 is further configured to send a first close notification to the NAT device, so that the NAT device performs NAT conversion on the first close notification and then sends a second close notification to the target Portal server, and the target Portal server locally disconnects the DTLS connection according to the second close notification;

[0105] The first closing notification and the second closing notification are both encrypted messages.

[0106] Optionally, the sending unit 320 is further used to send a third registration message to the NAT device through the DTLS connection, so that the NAT device performs NAT conversion on the third registration message and then sends a fourth registration message to the target Portal server, and the target Portal server updates the registration item according to the fourth registration message;

[0107] The third registration message and the fourth registration message are both encrypted messages that are encrypted using the key after the key negotiation.

[0108] Optionally, the device further comprises:

[0109] An acquiring unit (not shown in the figure), configured to acquire, from a local mapping table, a mapping relationship entry matching the IP address of the target Portal server according to the IP address of the target Portal server, wherein the mapping relationship entry includes a pointer to a data structure for storing SSL session information;

[0110] An access unit (not shown in the figure) is used to access the data structure through the pointer to call the corresponding SSL session and call the DTLS connection on the SSL session.

[0111] Optionally, the establishing unit is further used to establish Socket communication with at least one Portal server through a local Socket, the Socket communication carries multiple SSL sessions, and each SSL session carries a DTLS connection.

[0112] Therefore, by applying the communication device provided by the present application, when the configured policy template is bound, the access device performs key negotiation with the target Portal server and establishes a DTLS connection; through the DTLS connection, the access device sends a first registration message to the NAT device, so that the NAT device performs NAT conversion on the first registration message and then sends a second registration message to the target Portal server, and the target Portal server generates a registration entry according to the second registration message; when the accessed user device initiates a request to access network resources, the access device exchanges Portal protocol messages with the target Portal server through the DTLS connection and the NAT device, and performs Portal authentication; wherein the first registration message, the second registration message, and the Portal protocol message are all encrypted messages encrypted using the key and encryption algorithm after key negotiation.

[0113] In this way, in the scenario where the access device and the remote Portal server are transmitted across the public network, the access device establishes a DTLS connection with the Portal server, and realizes that in the subsequent Portal authentication process, the Portal protocol messages exchanged between each other are encrypted and transmitted. In this way, the access device and the Portal server are easy to connect, and the Portal authentication is more secure. In addition, the DTLS mode of single Socket communication and multiple sessions is used on the access device, which brings security while also reducing the management cost of the Portal server to maintain a large number of Socket communications. It also solves the problem of unsafe hidden dangers such as protocol message loss and interception in the existing Portal authentication process because the protocol message is carried by UDP message and UDP message is interacted in plain text.

[0114] Based on the same inventive concept, the embodiment of the present application also provides a network device, such as Figure 4 As shown, it includes a processor 410, a transceiver 420 and a machine-readable storage medium 430, the machine-readable storage medium 430 stores machine-executable instructions that can be executed by the processor 410, and the processor 410 is prompted by the machine-executable instructions to execute the communication method provided in the embodiment of the present application. Figure 3 The communication device shown can be used as Figure 4 The network device hardware structure shown is implemented.

[0115] The computer-readable storage medium 430 may include a random access memory (RAM) or a non-volatile memory (NVM), such as at least one disk storage. Optionally, the computer-readable storage medium 430 may also be at least one storage device located away from the processor 410.

[0116] The processor 410 may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it may 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 gates or transistor logic devices, or discrete hardware components.

[0117] In the embodiment of the present application, the processor 410 reads the machine executable instructions stored in the machine readable storage medium 430, and the machine executable instructions enable the processor 410 itself and the transceiver 420 to execute the communication method described in the aforementioned embodiment of the present application.

[0118] In addition, an embodiment of the present application provides a machine-readable storage medium 430, which stores machine-executable instructions. When called and executed by the processor 410, the machine-executable instructions prompt the processor 410 itself and the calling transceiver 420 to execute the communication method described in the aforementioned embodiment of the present application.

[0119] The implementation process of the functions and effects of each unit in the above-mentioned device is specifically described in the implementation process of the corresponding steps in the above-mentioned method, and will not be repeated here.

[0120] For the device embodiment, since it basically corresponds to the method embodiment, the relevant parts can refer to the partial description of the method embodiment. The device embodiment described above is only schematic, wherein the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the present application scheme. A person of ordinary skill in the art can understand and implement it without paying any creative work.

[0121] As for the communication device and machine-readable storage medium embodiments, since the method contents involved are basically similar to the aforementioned method embodiments, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiments.

[0122] The above description is only a preferred embodiment of the present application and is not intended to limit the present application. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles 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 an access device, and the method includes: When binding the configured policy template, perform key negotiation with the target Portal server and establish a DTLS connection; Sending a first registration message to a NAT device through the DTLS connection, so that the NAT device performs NAT conversion on the first registration message and then sends a second registration message to the target Portal server, and the target Portal server generates a registration entry according to the second registration message; When the accessed user device initiates a request to access network resources, the DTLS connection and the NAT device are used to exchange Portal protocol messages with the target Portal server and perform Portal authentication; The first registration message, the second registration message, and the Portal protocol message are all encrypted messages that are encrypted using the key and encryption algorithm after the key negotiation.

2. The method according to claim 1, characterized in that The method further comprises: When the policy template is unbound, disconnecting the DTLS connection locally; Sending a first close notification to the NAT device, so that the NAT device performs NAT conversion on the first close notification and then sends a second close notification to the target Portal server, and the target Portal server locally disconnects the DTLS connection according to the second close notification; The first closing notification and the second closing notification are both encrypted messages.

3. The method according to claim 1, characterized in that: The method further comprises: Sending a third registration message to the NAT device through the DTLS connection, so that the NAT device performs NAT conversion on the third registration message and then sends a fourth registration message to the target Portal server, and the target Portal server updates the registration item according to the fourth registration message; The third registration message and the fourth registration message are both encrypted messages that are encrypted using the key after the key negotiation.

4. The method according to claim 1, characterized in that: Before sending the first registration message to the NAT device through the DTLS connection, the method further includes: According to the IP address of the target Portal server, obtaining a mapping relationship table entry matching the IP address of the target Portal server from a local mapping relationship table, wherein the mapping relationship table entry includes a pointer to a data structure for storing SSL session information; The data structure is accessed through the pointer so that the corresponding SSL session is called, and the DTLS connection is called on the SSL session.

5. The method according to claim 4, characterized in that The method further comprises: Socket communication is established with at least one Portal server through a local Socket, the Socket communication carries multiple SSL sessions, and each SSL session carries a DTLS connection.

6. A communication device, characterized in that: The device is applied to an access device, and the device includes: An establishment unit is used to perform key negotiation with a target Portal server and establish a DTLS connection when binding a configured policy template; A sending unit, configured to send a first registration message to a NAT device through the DTLS connection, so that the NAT device performs NAT conversion on the first registration message and then sends a second registration message to the target Portal server, and the target Portal server generates a registration entry according to the second registration message; The sending unit is further configured to, when the accessed user equipment initiates a request to access network resources, exchange Portal protocol messages with the target Portal server through the DTLS connection and the NAT device, and perform Portal authentication; The first registration message, the second registration message, and the Portal protocol message are all encrypted messages that are encrypted using the key and encryption algorithm after the key negotiation.

7. The device according to claim 6, characterized in that The device also includes: a disconnection unit, configured to locally disconnect the DTLS connection when unbinding the policy template; The sending unit is further configured to send a first close notification to the NAT device, so that the NAT device performs NAT conversion on the first close notification and then sends a second close notification to the target Portal server, and the target Portal server locally disconnects the DTLS connection according to the second close notification; The first closing notification and the second closing notification are both encrypted messages.

8. The device according to claim 6, characterized in that The sending unit is further used to send a third registration message to the NAT device through the DTLS connection, so that the NAT device performs NAT conversion on the third registration message and then sends a fourth registration message to the target Portal server, and the target Portal server updates the registration item according to the fourth registration message; The third registration message and the fourth registration message are both encrypted messages that are encrypted using the key after the key negotiation.

9. The device according to claim 6, characterized in that The device also includes: an acquiring unit, configured to acquire, from a local mapping relationship table, a mapping relationship table entry matching the IP address of the target Portal server according to the IP address of the target Portal server, wherein the mapping relationship table entry includes a pointer to a data structure for storing SSL session information; The access unit is used to access the data structure through the pointer so as to call the corresponding SSL session and call the DTLS connection on the SSL session.

10. The device according to claim 9, characterized in that The establishing unit is further used to establish Socket communication with at least one Portal server through a local Socket, wherein the Socket communication carries multiple SSL sessions, and each SSL session carries a DTLS connection.

Images