Full-duplex implementation between ACS and CPE

Part 01

Introduction to TR069 Protocol

Protocol is an agreement. The communication protocol stipulates the methods and details for the communication between the two parties. TR069 protocol stipulates the rules for the interaction between the customer premises equipment (CPE) and the auto-configuration server (ACS). We know that HTTP protocol is based on TCP protocol, COAP protocol is based on UDP protocol, and TR069 protocol here is based on HTTP1.1 protocol transmission. SOAP standard encapsulates the message content format of XML. The message content is shown in Figure 1:

Part 02

TR069 protocol usage  

TR069 protocol provides a general framework, message specifications, management methods and data models for managing and configuring home network devices in the next generation network. In the network management model, ACS is responsible for remote centralized management of terminal devices CPE, solving the management difficulties of CPE devices, saving maintenance costs and improving problem solving efficiency.

ACS implements remote management of CPE, and the core is the connection interaction between ACS and CPE. Unlike the MQTT protocol, which maintains a long connection between the client and the server, the connection between ACS and CPE is a short connection only when there is a need for interaction.

Part 03

CPE Connecting to ACS  

When the CPE is first started, it will actively initiate an HTTP connection to the ACS to register and go online, and report 0 BOOTSTRAP and 1 BOOT through the inform method in the RPC method (as shown in the XML message content example of SOAP encapsulation in the figure above). If the platform has parameters that need to be configured or obtained, they will also be performed in this connection. The interaction is as follows:

Step 1: CPE directly initiates an HTTP connection request to ACS. The request header is as follows:

 POST / ACS - server / test HTTP / 1.1
 SOAPAction :
 Content - Length : 3923
 ......

Step 2: ACS responds with 401 and requires CPE to perform HTTP Digest Authentication. The response example is as follows:

 HTTP / 1.1 401 Unauthorized
 Server : XXX
 WWW - Authenticate : Digest
 realm = "XXX" , qop = "XXX" , nnotallow = "5ad62dabf90594eed8d2d72cec12e5f9" , opaque = "60D0FDDCC498497B82138713D1383D9F"
 ......

Step 3: CPE calculates the response according to the WWW-Authenticate information of the ACS response, as well as the URL, username and password, using the digest authentication algorithm, and constructs the digest authentication information Authorization for the re-request, and initiates the HTTP request again to report the inform. The example of re-requesting with authentication information is as follows:

 POST / ACS - server / test HTTP / 1.1
 SOAPAction :
 Authorization : Digest realm = "XXX" , username = "XXX" , algorithm = "MD5" , nnotallow = "5ad62dabf90594eed8d2d72cec12e5f9" , uri = "/ACS-server/test" , nc = 00000001 , cnnotallow = "12327701" , respnotallow = "XXXXXX" , opaque = "60D0FDDCC498497B82138713D1383D9F" , qop = "XXX"
 Content - Length : 3923
 ......

Step 4: ACS responds with 200 OK, and the SOAP content is InformResponse. Digest authentication is now complete. Set the cookie for the next request from CPE according to the Set-Cookie information in the response header. The example is as follows:

 HTTP / 1.1 200 OK
 Server : XXX
 Set - Cookie :
 JSESSIONID = 15 F51C74ED3AE0FE45A382BEBC145D29 ; Path = XXX ; XXX
 ......

Step 5: CPE initiates an empty HTTP request. According to the TR069 protocol, the message body length must be 0. In the following example, you can see that Content-Length is 0:

 POST / ACS - server / test HTTP / 1.1
 Authorization : Digest realm = "XXX" , username = "XXX" , algorithm = "MD5" , nnotallow = "5ad62dabf90594eed8d2d72cec12e5f9" , uri = "/ACS-server/test" , nc = 00000002 , cnnotallow = "12327701" , respnotallow = "XXXXXX" , opaque = "60D0FDDCC498497B82138713D1383D9F" , qop = "XXX"
 Content - Length : 0
 Cookies :
 JSESSIONID = 15 F51C74ED3AE0FE45A382BEBC145D29
 ......

Step 6: ACS responds to the HTTP empty request, encapsulates SOAP to call the RPC method, and performs operations such as parameter configuration or query on the terminal device.

 HTTP / 1.1 200 OK
 Server : XXX
 Content - Type : text / xml ; charset = UTF - 8
 Content - Length : 2226
 ......

Step 7: CPE initiates a request and encapsulates the SOAP corresponding response RPC method. If the terminal management platform needs to be configured after querying, steps 6 and 7 will be performed twice. If neither is required, steps 6 and 7 can be omitted. If so, the case is as follows:

 POST / ACS - server / acs HTTP / 1.1
 SOAPAction :
 Authorization : Digest realm = "XXX" , username = "XXX" , algorithm = "MD5" , nnotallow = "5ad62dabf90594eed8d2d72cec12e5f9" , uri = "/ACS-server/test" , nc = 00000003 , cnnotallow = "12327701" , respnotallow = "XXXXXX" , opaque = "60D0FDDCC498497B82138713D1383D9F" , qop = "XXX"
 Content - Length : 528
 Cookies :
 JSESSIONID = 15 F51C74ED3AE0FE45A382BEBC145D29
 ......

Step 8: ACS sends an empty HTTP response. According to the TR069 protocol, the status code is "204 (No Content)", indicating that the session is over. The following is an example:

 HTTP / 1.1 204 No Content
 Server : XXX
 Date : Fri , 23 Jan 2023 00:15:14 GMT​

Here we will explain the digest authentication in the third step. Here we briefly explain some parameters involved in WWW-Authenticate and Authorization. For more details, please refer to RFC2617 and other related documents.

➤ digest ==>Authentication method

➤ realm ==> realm, the realm parameter is mandatory and must exist

➤ qop ==> Quality of protection, "auth" means only identity verification, "auth-int" means verification and some integrity protection

➤ nonce ==> Random number generated by the server, which is uniquely created when each 401 response is generated. It is used for encryption to prevent attacks.

➤ cnonce ==> client nonce

➤ uri ==> URL that the client wants to access

➤ nc ==> Number of consecutive requests. In the same TCP connection, each time the device POSTs once, nc+1

➤ algorithm ==> Algorithm pair used to generate digest and checksum

➤ response ==> used to prove whether the user knows the password

The response calculation process usually consists of the following three steps ^[2] :

Step 1: Calculate HA1

• HA1=MD5(A1)=MD5(username:realm:password);

Step 2: Calculate HA2

• If the qop value is "auth" or not specified, then HA2=MD5(A2)=MD5(method:uri);
• If the qop value is "auth-int", then HA2=MD5(A2)=MD5(method:uri:MD5(entityBody);

Step 3: Calculate the response based on HA1 and HA2

• If the qop value is "auth" or "auth-int", then respnotallow=MD5(HA1:nonce:nc:cnonce:qop:HA2);
• If qop is not specified, then respnotallow=MD5(HA1:nonce:HA2).

Authorization construction: The CPE generates cnonce, nc starts to accumulate from 00000000, response is calculated according to the above formula, opaque, qop, nonce, and realm are inherited from WWW-Authenticate, and username, algorithm, and uri are added.

In addition, the terminal management system may also check parameters such as Manufacturer and OUI. If the check fails, the response is 403, which means that the server understands the client's request but refuses to process it.

Part 04

ACS connected to CPE  

When configuring parameters for CPE through ACS, ACS acts as the active party to trigger this connection. At this time, ACS actively connects to CEP in two ways:

(1) In non-NAT mode, the ACS initiates an HTTP connection request to the CPE, using the address reported by the terminal: Device.ManagementServer.ConnectionRequestURL. The terminal requires HTTP digest authentication.

(2) In NAT mode, ACS interacts with CPE in the public network environment and obtains the CPE public network address through NAT traversal for interaction. The implementation process is shown below.

NAT stands for Network Address Translation. The purpose of STUN is to traverse NAT ^[1] . Here, STUN will be used as a tool to serve the ACS connection CPE implementation. It allows the terminal to discover its public IP and port, and serves as a keep-alive protocol to maintain NAT binding.

In NAT mode, the ACS connects to the CPE as follows:

Step 1: Implement and maintain the binding request and response between ACS and CPE based on the STUN protocol. You can use the third-party open source JSTUN library at: https://gitee.com/javabedlamite/JSTUN/. The following is a related message example:

Step 2: Parse the CPE public IP and port according to the binding response. According to the STUN protocol definition, the MAPPED-ADDRESS attribute corresponds to the client mapping address, which is also the public address of the CPE.

Step 3: Construct the UDP return address of the terminal management system based on the mapped port address and report it to the ACS. This involves using the following two parameters in the TR069 data model:

• Device.ManagementServer.UDPCnotallow=CEP public network address
• Device.ManagementServer.NATDetected=true via Inform 4 VALUE CHANGE

Notify the ACS that the CPE supports NAT traversal, as well as its UDP return address on the public network.

Step 4: At some point, ACS needs to configure CPE. The terminal management platform only needs to initiate a UDP request to CPE. After the terminal device parses it, CPE is triggered to initiate an Inform 6 CONNECTION REQUEST to ACS (according to the Tr069 protocol, Inform 6 indicates that this session is established at the request of the ACS side). At this point, the ACS is connected to CPE.

Step 5: In this connection, the ACS issues tasks such as configuration, query, restart, and diagnosis to the CPE, and the CPE executes and responds.

The overall process can be roughly implemented as follows:

Part 05

Mainstream graph databases  

The establishment of a two-way connection between ACS and CPE is the basis and prerequisite for the terminal management system to remotely manage the terminal. This article mainly describes in detail a connection implementation method and process for ACS to connect to CEP and CPE to connect to ASC. At present, home smart gateways are generally managed by the provincial management platform of each province through the TR069 protocol, and some set-top boxes are also managed through the TR069 protocol; in the context of the Internet of Everything, the scale may be even larger in the future.