TR069協議提供了對下一代網絡中家庭網絡設備進行管理配置的通用框架、消息規范、管理方法和數據模型。在網管模型中,ACS負責對終端設備CPE進行遠程集中管理,解決CPE設備的管理困難,節約成本,提高問題解決效率。ACS實現對CPE的遠程管理,核心便是ACS與CPE之間的連接交互,本文主要講解ACS和CPE之間的全雙工實現。
Part 01 ●??TR069協議簡介?●?
協議即約定,通信協議約定了通信雙方交互所遵循的方式和細則。TR069協議約定用戶側設備(Customer Premises Equipment,即CPE)和自動配置服務器(Auto-Configuration Server,即ACS)之間交互的規則。我們知道HTTP協議是基于TCP協議,COAP協議是基于UDP協議,而這里的TR069協議則是基于HTTP1.1的協議傳輸,SOAP標準封裝XML的消息內容格式,消息內容部分如下圖1:
Part 02 ●??TR069協議用途?●?
TR069協議提供了對下一代網絡中家庭網絡設備進行管理配置的通用框架、消息規范、管理方法和數據模型。在網管模型中,ACS負責對終端設備CPE進行遠程集中管理,解決CPE設備的管理困難,節約維護成本,提高問題解決效率。
ACS實現對CPE的遠程管理,核心便是ACS與CPE之間的連接交互。不同于MQTT協議,客戶端與服務器之間維持一個長鏈接,ACS同CPE的連接僅在存在交互需要時建立短鏈接。
Part 03 ●??CPE連接ACS?●?
CPE首次啟動會主動對ACS發起HTTP連接,進行注冊上線動作,通過RPC方法中的inform方法上報0 BOOTSTRAP和1 BOOT(如上圖SOAP封裝的XML消息內容案例),如平臺有需要配置或者獲取的參數,也會在這次連接中進行。交互如下:
第一步:CPE直接對ACS發起HTTP連接請求,請求案例頭部如下:
?
?
POST /ACS-server/test HTTP/1.1 SOAPAction: Content-Length: 3923 ......
?
?
第二步:ACS響應401,要求CPE進行HTTP Digest Authentication認證,即摘要認證,響應案例如下:
?
?
HTTP/1.1 401 Unauthorized Server: XXX WWW-Authenticate: Digest realm="XXX",qop="XXX",nonce="5ad62dabf90594eed8d2d72cec12e5f9",opaque="60D0FDDCC498497B82138713D1383D9F" ......
?
?
第三步:CPE根據ACS響應的WWW-Authenticate信息,以及url、username和password,按照摘要認證算法計算response,構建出再次請求的摘要認證信息Authorization,并再次發起HTTP請求,進行inform上報。攜帶認證信息再次請求,案例如下:
?
?
POST /ACS-server/test HTTP/1.1 SOAPAction: Authorization: Digest realm="XXX", username="XXX", algorithm="MD5", nonce="5ad62dabf90594eed8d2d72cec12e5f9", uri="/ACS-server/test", nc=00000001, cnonce="12327701", response="XXXXXX", opaque="60D0FDDCC498497B82138713D1383D9F", qop="XXX" Content-Length: 3923 ......
?
?
第四步:ACS響應200 OK,SOAP內容為InformResponse,摘要認證到這里已經完成。根據響應頭的Set-Cookie信息設置CPE下個請求的Cookie。案例如下:
?
?
HTTP/1.1 200 OK Server: XXX Set-Cookie: JSESSIONID=15F51C74ED3AE0FE45A382BEBC145D29; Path=XXX;XXX ......
?
?
第五步:CPE發起的一個空的HTTP請求,根據TR069協議,消息體長度必須為0,如下案例可以看到Content-Length是0:
?
?
POST /ACS-server/test HTTP/1.1 Authorization: Digest realm="XXX", username="XXX", algorithm="MD5", nonce="5ad62dabf90594eed8d2d72cec12e5f9", uri="/ACS-server/test", nc=00000002, cnonce="12327701", response="XXXXXX", opaque="60D0FDDCC498497B82138713D1383D9F", qop="XXX" Content-Length: 0 Cookie: JSESSIONID=15F51C74ED3AE0FE45A382BEBC145D29 ......
?
?
第六步:ACS響應HTTP 空請求,封裝SOAP調用RPC方法,對終端設備進行參數配置或者查詢等操作。
?
?
HTTP/1.1 200 OK Server: XXX Content-Type: text/xml;charset=UTF-8 Content-Length: 2226 ......
?
?
第七步:CPE發起請求,封裝SOAP對應響應RPC方法。如果終端管理平臺查詢后還需要進行配置,則第六步和第七步會有兩次,如都不需要,則第六步和第七步可省略。如存在,案例如下:
?
?
POST /ACS-server/acs HTTP/1.1 SOAPAction: Authorization: Digest realm="XXX", username="XXX", algorithm="MD5", nonce="5ad62dabf90594eed8d2d72cec12e5f9", uri="/ACS-server/test", nc=00000003, cnonce="12327701", response="XXXXXX", opaque="60D0FDDCC498497B82138713D1383D9F", qop="XXX" Content-Length: 528 Cookie: JSESSIONID=15F51C74ED3AE0FE45A382BEBC145D29 ......
?
?
第八步:ACS下發一個空HTTP響應,根據TR069協議,狀態碼使用“204(無內容)”,表示本次會話結束。案例如下:
?
?
HTTP/1.1 204 No Content Server: XXX Date: Fri, 23 Jan 2023 0014 GMT
?
?
這里我們針對第三步的摘要認證展開說明。這里簡要說明下WWW-Authenticate和Authorization中涉及到的一些參數,更多詳細內容可以自行參閱RFC2617等相關文檔。
? digest ==>認證方式
? realm ==>領域,領域參數是強制的,必須存在
? qop ==>保護的質量,“auth”表示只進行身份查驗, “auth-int”表示進行查驗外,還有一些完整性保護
? nonce ==>服務器側生成的隨機數,在每個401回應產生時,被唯一創建,為防止攻擊產生,參與加密
? cnonce ==>即client nonce
? uri ==>客戶端想要訪問的URL
? nc ==>連續請求次數,在同一個TCP連接里,設備每POST一次,nc+1
? algorithm ==>用來生產摘要及校驗和的算法對
? response ==>用來證明用戶是否知道口令
response計算通常過程分以下三步[2]:
第一步:計算HA1
HA1=MD5(A1)=MD5(usernamepassword);
第二步:計算HA2
如果 qop 值為“auth”或未指定,那么HA2=MD5(A2)=MD5(method:uri);
如果 qop 值為“auth-int”,那么HA2=MD5(A2)=MD5(methodMD5(entityBody);
第三步:根據HA1和HA2計算response
如果 qop 值為“auth”或“auth-int”,那么response=MD5(HA1ncqop:HA2);
如果 qop 未指定,那么response=MD5(HA1HA2) 。
Authorization構建:CPE端生成cnonce,nc從00000000開始累計,response根據上述公式計算,opaque、qop、nonce、realm繼承自WWW-Authenticate,添加上username、algorithm和uri。
此外,終端管理系統可能還會對Manufacturer、OUI等參數進行查驗,如查驗不通過,響應403,即服務器理解客戶的請求,但拒絕處理它。
Part 04 ●??ACS連接CPE?●?
通過ACS對CPE進行參數配置時,ACS作為主動方觸發本次連接。此時,ACS主動連接CEP,方式有兩種:
(1)非NAT模式下,ACS對CPE發起HTTP連接請求,使用終端上報的地址:Device.ManagementServer.ConnectionRequestURL,終端要求進行HTTP摘要認證。
(2)NAT模式下,ACS在公網環境下與內網下CPE交互,通過NAT穿越獲取CPE公網地址進行交互,實現流程見下文。
NAT,即網絡地址轉換。STUN 存在的目的就是進行NAT穿越[1],這里STUN將作為一個工具來服務于本次的ACS連接CPE實現。讓終端用來發現其在公網IP和端口,并作為一種保活(keep-alive)協議來維持NAT的綁定。
NAT模式下,ACS連接CPE實現具體如下:
第一步:基于STUN協議實現ACS與CPE之間的捆綁請求和響應,并維持。可借助第三方開源JSTUN庫,地址:https://gitee.com/javabedlamite/JSTUN/。如下是相關報文案例:
第二步:根據捆綁響應解析CPE公網IP和端口。根據STUN協議定義,MAPPED-ADDRESS屬性對應即是客戶端映射地址;在這里也是CPE的公網地址。
第三步:根據映射的端口地址構建終端管理系統的UDP回連地址;并上報ACS。涉及使用TR069數據模型中以下兩個參數:
Device.ManagementServer.UDPConnectionRequestAddress=CEP公網地址
Device.ManagementServer.NATDetected=true通過Inform 4 VALUE CHANGE?
通知上報ACS,CPE支持NAT穿越,以及其在公網UDP回連地址。
第四步:某時刻,ACS需要對CPE進行配置,只需終端管理平臺對CPE的發起UDP請求,終端設備側解析后,觸發CPE對ACS發起Inform 6 CONNECTION REQUEST(根據Tr069協議,Inform 6表明本次會話是由ACS側要求而建立的)。到此ACS連接CPE完成。
第五步:在本次連接中,ACS下發對CPE的配置、查詢、重啟、診斷等約定支持的任務,CPE執行并響應。
整體流程大致實現可如下:
Part 05 ●??主流圖形數據庫?●?
ACS和CPE之間雙向連接建立的實現,是終端管理系統遠程管理終端的基本和前提。本文主要就ACS連接CEP和CPE連接ASC,各詳細講述一種連接實現方式和流程。目前,家庭智能網關普遍通過TR069協議納管于各省份的省側管理平臺,一些機頂盒也在通過TR069協議進行納管;在萬物互聯背景下,未來規模也許會更大。
編輯:黃飛
?
評論
查看更多