Communication method and apparatus

Abstract

The application provides a communication method and device, the method comprises the following steps: when a policy template of a binding configuration is configured, a key negotiation is performed with a target Portal server, and a DTLS connection is established; a first registration message is sent to a 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; when a user equipment accesses initiates a request for accessing a network resource, a Portal protocol message is exchanged with the target Portal server through the DTLS connection and the NAT device, and Portal authentication is performed.

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 referred to 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 typically deployed at the access layer and at key data entry points that require protection, and it implements access control. In a network environment using Portal authentication, a user device can initiate Portal authentication by proactively accessing a known Portal server through the access device. Alternatively, the user device can access any non-Portal server website through the access device and subsequently be forced to access the Portal server website, initiating Portal authentication.

[0004] During communication between the access device and the Portal server, the Portal server authenticates the user using protocol messages to control access. The existing Portal protocol specifies that protocol messages should be carried on User Datagram Protocol (UDP) packets and consist of a fixed-length header and variable-length attribute fields.

[0005] However, if the Portal server is remote, the protocol packets sent and received by the access device will be transmitted across the public network when communicating with it. Because UDP packets only encrypt the password portion, while other fields are exchanged in plain text, this can lead to security risks such as protocol packet loss or 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 risks 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 includes:

[0008] When the configured policy template is bound, key negotiation is performed with the target Portal server and a DTLS connection is established.

[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 connected user device initiates a request to access network resources, the DTLS connection and the NAT device are used to interact with the target Portal server, 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 includes:

[0013] The establishment unit is used to perform key negotiation with the target Portal server and establish a DTLS connection when binding the 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 connected 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 comprising a processor and a machine-readable storage medium, wherein 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.

[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 based on 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 after encryption processing 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 during the subsequent Portal authentication process, the Portal protocol messages exchanged between them are encrypted and transmitted. This makes it easier for the access device and the Portal server to connect, and Portal authentication is more secure. In addition, the DTLS mode of single-socket communication and multiple sessions on the access device brings security while also reducing the management cost of the Portal server maintaining a large number of socket communications. It also solves the problem of unsafe risks such as protocol message loss and interception in the existing Portal authentication process because the protocol messages are carried by UDP messages and UDP messages are exchanged 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 the 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, with examples illustrated in the accompanying drawings. In the following description, when referring to the drawings, identical numerals in different figures represent identical or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments are not intended to represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present application, as detailed in the appended claims.

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

[0026] It should be understood that although the terms first, second, third, etc. 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, first information may also be referred to as second information, and similarly, second information may also be referred to as 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 This is 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 the configured policy template is bound, key negotiation is performed with the target Portal server, and a DTLS connection is established.

[0029] Specifically, through a local area network, a user device accesses an interface of an access device that is enabled for Portal authentication. The access device is connected to a Network Address Translation (NAT) device, which is connected to a Portal server via a public network.

[0030] The portal process is started on the access device to implement portal authentication for user devices.

[0031] The access device has a policy template configured that includes information such as various encryption algorithms, Public Key Infrastructure (PKI), and versions. The versions specifically refer to the Datagram Transport Layer Security (DTLS) and Transport Layer Security (TLS) connection versions supported by the access device.

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

[0033] The following briefly describes the process of key negotiation and DTLS connection establishment between the access device and the target Portal server.

[0034] The access device establishes a handshake connection with the target Portal server. During the handshake, the access device authenticates the other party's identity, completes identity authentication, and negotiates keys and cipher suites to encrypt data during subsequent transmission.

[0035] Initial Hello negotiation process:

[0036] The access device sends a ClientHello message to the target Portal server to initiate the handshake process. This ClientHello message includes information such as the DTLS version and cipher suites supported by the access device. After receiving the ClientHello message, the target Portal server sends a HelloVerifyRequest message to the access server. This HelloVerifyRequest message includes information such as the DTLS version, cipher 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 another Client Hello message to the target Portal server. This message includes the encryption suite, the cookie sent by the target Portal server, and a random number. After receiving the Client Hello message, the target Portal server verifies the validity of the cookie. If the cookie is valid, it continues the handshake connection with the access device and sends a ServerHello message to the access device. If the cookie is invalid, 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. This Certificate message includes a digital certificate containing the target Portal server's own public key information, allowing the access device to authenticate the target Portal server. The target Portal server continues to send ServerKeyExchange messages to the access device, including its own temporary public key. The target Portal server continues to send CertificateRequest messages to the access device. This CertificateRequest message is used to request the access device to provide a digital certificate containing its own public key information, allowing the target Portal server to 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 cipher suite negotiation process is complete and key exchange begins.

[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. This Certificate message includes the digital certificate for the access device's own public key information. After obtaining the digital certificate for the target Portal server's own public key information, the access device verifies the validity of the digital certificate for the target Portal server's own public key information. If valid, the access device uses the public key in the digital certificate to encrypt the randomly generated key of the client access device and continues to send a ClientKeyExchange message to the target Portal server. This ClientKeyExchange message includes the encrypted key. The access device continues to send a CertificateVerify message to the target Portal server. This 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. This ChangeCipherSpec message notifies the target Portal server that subsequent messages will be encrypted using the negotiated key and cipher suite. The access device continues to send a Finished message to the target Portal server. This Finished message notifies the target Portal server that the handshake process is complete. The target Portal server sends a ChangeCipherSpec message to the access device. This ChangeCipherSpec message notifies the access device that subsequent messages will be encrypted using the negotiated key and cipher suite. The target Portal server then sends a Finished message to the access device, notifying the access device that the handshake process is complete.

[0043] The key negotiation process between the access device and the target Portal server is now complete.

[0044] After a successful handshake between the access device and the target Portal server, the access device also completes authentication of the target Portal server. This is because the target Portal server, which possesses the private key, can decrypt the key from the ClientKeyExchange message, allowing the subsequent handshake to succeed.

[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] The access device sends a first registration message to the NAT device over a DTLS connection. After receiving the first registration message, the NAT device performs NAT translation on it to generate a second registration message. The NAT device then sends 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 based on the second registration message. This registration entry includes information such as the access device's name, NAT-translated IP address, and port number. The target Portal server generates the registration entry so that it can identify the access device and obtain its NAT-translated IP address and port number when subsequently sending Portal protocol messages to the access device.

[0049] In this embodiment of the present application, the first registration message is a UDP message, which includes a UDP header and a data field. After establishing a DTLS connection with the target Portal server, the access device encrypts the entire data field in the UDP message 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 on the first registration message, it performs NAT on the source Internet Protocol (IP) address and source port, but does not process the encrypted data field, resulting in the second registration message. The second registration message is also an encrypted message.

[0051] Step 130: When the connected 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 an http / https POST request (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 the target Portal server receives the POST request, it 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 device 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 step 120, after receiving the first Portal protocol message, the NAT device performs NAT translation on the first Portal protocol message to obtain a second Portal protocol message. The NAT device then 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 then send it to the NAT device.

[0057] In the embodiments of the present application, the aforementioned Portal protocol messages are all UDP messages, including 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 using the key, encryption algorithm, and other information negotiated during the DTLS connection establishment process. The aforementioned Portal protocol messages are also all encrypted messages.

[0058] It's important to note that the UDP header is not encrypted. When a NAT device performs NAT on a Portal protocol message, it translates the source IP address and source port number, but does not process the encrypted data field. The resulting Portal protocol message is encrypted.

[0059] Optionally, in an 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 registration messages, for example, every 10 seconds by default.

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

[0062] The access device sends a third registration message to the NAT device over the DTLS connection. After receiving the third registration message, the NAT device performs NAT translation on it, generating a fourth registration message. The NAT device then sends the fourth registration message to the target Portal server.

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

[0064] In this embodiment of the present application, the third registration message is a UDP message, which includes a UDP header and a data field. After establishing a DTLS connection with the target Portal server, the access device encrypts the entire data field in the UDP message 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 on the third registration message, it performs NAT on the source IP address and source port, but does not process the encrypted data field, resulting in the fourth registration message. The fourth registration message is also an encrypted message.

[0066] like Figure 2 As shown, Figure 2 This is a signaling diagram of the communication method provided in the 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 on Source IP Address 1 (private IP) and Source Port 1 (private port) included in Registration Message 1, generating Registration Message 2. Registration Message 2 includes the translated Source IP Address 2 (public IP) and Source Port 2 (public port). The NAT device then sends Registration Message 2 to the target Portal server.

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

[0069] When a user device initiates a request to access network resources, the target Portal server and access device encrypt any Portal protocol message and send it to the NAT device over a DTLS connection. The NAT device then performs NAT translation and sends the translated Portal protocol message to the peer device.

[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] The access device sends Registration Message 3 to the NAT device over a DTLS connection. After receiving Registration Message 3, the NAT device performs NAT on Source IP Address 1 (private IP) and Source Port 1 (private port) included in Registration Message 3, generating Registration Message 4. This Message includes the translated Source IP Address 3 (public IP) and Source Port 4 (public port). The NAT device then sends Registration Message 4 to the target Portal server.

[0072] NAT devices in the network are usually carrier devices. The NAT mapping rules configured on the NAT device vary according to the carrier's plans. For example, between 12:00 and 12:00, the NAT mapping rule translates source IP address 1 to source IP address 2; between 12:00 and 12:00, the NAT mapping rule translates source IP address 1 to source IP address 3, and so on.

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

[0074] In this embodiment of the present application, Registration Messages 1-4 are all UDP messages, including a UDP header and a data field. After establishing a DTLS connection with the target Portal server, the access device encrypts the complete data field in the UDP message using 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 on Registration Messages 1 and 3, it performs NAT on the source IP address and source port, but 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 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 again to the NAT device, 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] The first closing notification and the 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 simply 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 between it and the access device has been disconnected after the preset time arrives, and destroy the SSL session that carries the DTLS connection on its own.

[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 messages sent. Alternatively, the existing SSL protocol encryption method can be used to encrypt the messages sent, which is not 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 the local mapping relationship table.

[0084] Specifically, the access device can configure IP addresses of multiple Portal servers. According to the IP address of each Portal server, the access device can respectively perform Socket communication with different Portal servers through different interfaces, and create a Secure Sockets Layer (SSL) session with each Portal server on the Socket communication.

[0085] The created SSL session can be specifically a data structure, for example, a memory block. In the data structure, SSL session information is stored, for example, information of two end devices (IP addresses), a session ID, and carried DTLS information, and the like.

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

[0087] In the embodiment of the present application, the access device can take one of the multiple Portal servers as a target Portal server according to a configuration instruction of a management personnel (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 realized through the description in the foregoing embodiment). At the same time, the access device can acquire, from the local mapping relationship table, a mapping relationship table item matched with the IP address of the target Portal server according to the IP address of the target Portal server. Through the 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 acquire, from the local mapping relationship table, the mapping relationship table item matched with the IP address of the target Portal server according to the IP address of the target Portal server. Through the pointer 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 on the called DTLS connection.

[0091] Furthermore, the access device has a SocketA configured. This SocketA includes SocketA1 for IPv4 networks and SocketA2 for IPv6 networks, depending on the network. Similarly, each Portal server has a SocketB configured. This SocketB includes SocketB1 for IPv4 networks and SocketB2 for IPv6 networks, depending on the network.

[0092] In this embodiment of the present application, all messages exchanged between the access device and the Portal server are carried by the UDP protocol, that is, they are all UDP messages. However, the UDP protocol does not have a connection at the transport level. Therefore, the access device communicates with each Portal server's corresponding SocketB through the aforementioned SocketA. For example, during communication, SocketA calls the sentto() function to send a message to the Portal server's IP address, and the Portal server receives the message through SocketB.

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

[0094] It is understood that in the preceding example, after SocketA1 communicates with SocketB1 on Portal Server 1 and Portal Server 2, respectively, multiple SSL sessions are established on SocketA1. For example, SocketA1 carries two SSL sessions: SSL Session 1 with Portal Server 1 and SSL Session 2 with Portal Server 2. A DTLS connection is created for each SSL session: DTLS Connection 1 on SSL Session 1 and DTLS Connection 2 on SSL Session 2.

[0095] Therefore, by applying the communication method provided in the application, when a policy template configured by binding is established, the access device performs key negotiation with a target Portal server and establishes a DTLS connection; through the DTLS connection, the access device sends a first registration message to a NAT device, 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; when a user equipment connected by the access device initiates a request for accessing a network resource, the access device interacts 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 processed by encryption using a key negotiated and an encryption algorithm.

[0096] In this way, in the scenario of cross-public-network transmission between the access device and the remote Portal server, the access device establishes a DTLS connection with the Portal server, so as to realize encryption processing of Portal protocol messages transmitted between the access device and the Portal server in the subsequent Portal authentication process. In this way, the access device and the Portal server are easy to connect, the Portal authentication is more secure, and the DTLS mode of using a single Socket to communicate multiple sessions on the access device not only brings safety but also reduces the management cost of maintaining a large number of Socket communications of the Portal server. The problem of insecure hidden dangers such as loss and interception of protocol messages in the existing Portal authentication process is also solved, because the protocol messages are carried by UDP messages and interacted in plaintext.

[0097] Based on the same inventive concept, the embodiments of the application also provide a communication device corresponding to the communication method. Referring to Figure 3 , Figure 3 The communication device provided in the embodiments of the application is applied to an access device, and the device comprises:

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

[0099] The sending unit 320 is configured to send a first registration message to a 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;

[0100] The sending unit 320 is further configured to, when the connected user device 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 configured 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 entry 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), configured to acquire, from a local mapping table, a mapping entry that matches the IP address of the target Portal server, according to the IP address of the target Portal server, wherein the mapping 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 configured to establish Socket communication with at least one Portal server via a local Socket, wherein 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 based on 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 after encryption processing 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 during the subsequent Portal authentication process, the Portal protocol messages exchanged between them are encrypted and transmitted. This makes it easier for the access device and the Portal server to connect, and Portal authentication is more secure. In addition, the DTLS mode of single-socket communication and multiple sessions on the access device brings security while also reducing the management cost of the Portal server maintaining a large number of socket communications. It also solves the problem of unsafe risks such as protocol message loss and interception in the existing Portal authentication process because the protocol messages are carried by UDP messages and UDP messages are exchanged in plain text.

[0114] Based on the same inventive concept, the embodiment of the present application further 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 random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device. Alternatively, the computer-readable storage medium 430 may be at least one storage device located remotely 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 gate 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 call 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 embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to the partial description of the method embodiments. The device embodiments described above are merely illustrative, 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 embodiments of the communication device and the machine-readable storage medium, since the method contents involved are basically similar to those of 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 replacements, 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 the configured policy template is bound, key negotiation is performed with the target Portal server and a DTLS connection is established. 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 connected user device initiates a request to access network resources, it exchanges Portal protocol messages with the target Portal server through the DTLS connection and the NAT device, and performs 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 entry 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, wherein 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 table entry that matches the IP address of the target Portal server from a local mapping table, wherein the mapping table entry includes a pointer to a data structure for storing SSL session information; The data structure is accessed through the pointer to call the corresponding SSL session, 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, wherein 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 includes: The establishment unit is used to perform key negotiation with the target Portal server and establish a DTLS connection when binding the 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 connected 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 further comprises: 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 configured 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 entry 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 further comprises: an acquiring unit, configured to acquire, from a local mapping table, a mapping entry that matches the IP address of the target Portal server according to the IP address of the target Portal server, wherein the mapping entry includes a pointer to a data structure for storing SSL session information; An access unit is configured to access the data structure through the pointer so as to call a 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 configured to establish Socket communication with at least one Portal server via a local Socket, wherein the Socket communication carries multiple SSL sessions, and each SSL session carries a DTLS connection.

Images