TR-069_Amendment-4：附錄G.穿越NAT網關的鏈接請求方式

 

注意：這種機制只適用於RFC 3489[21]中定義的經典STUN，RFC 5389引入後，這個機制已通過時。這個機制不是設計用於RFC 5389中定義的STUN。IPv6部署要麼不使用NAT，要麼以不一樣的方式使用它。

G.1介紹

CWMP能夠用來對經過網關鏈接的局域網下的CPE設備進行遠程管理。當設備部在NAT網關以後，並被分配了私網IP後，CWMP依然能夠對其進行管理，但有了限制，經過Connection Request觸發CWMP會話的機制不可用。

本附錄定義了一種方式，容許ACS初始化位於NAT網關後的設備的CWMP會話，它提供了與Connection Request相同的功能，但使用的是不一樣的機制，以適應這個場景。

此機制不要求網關支持CWMP協議，僅須要ACS和CPE作出支持。

G.2過程

爲知足此特性，CPE和ACS須要知足以下要求：

l  CPE必須可以發現它到ACS的鏈接是穿過了一個NAT網關，而且這個NAT網關爲CPE分配了一個私網IP地址。

l  CPE必須可以維護一個NAT綁定通道，ACS經過它能夠隨時向CPE發送數據包，而不是僅在收到CPE的請求後，以響應此請求的方式發送數據包。

l  CPE必須可以肯定與NAT綁定通道相關聯的公網IP地址和端口，並將此信息發送給ACS。

爲適應上述各項功能，本附錄定義了一些STUN協議的特別用法，即基於UDP的Connection Request機制，作爲基於TCP的Connection Request的補充。

藉助於STUN，發送UDP Connection Request到CPE，過程總結以下：

l  ACS開啓CPE的STUN功能（若是出廠默認配置下還沒有啓用的話），並告知CPE相應的STUN Server地址。

l  CPE經過STUN，肯定CPE是否位於NAT網關後面，而且被分配了私網地址。

l  若是CPE位於NAT網關後面，而且被分配了私網地址，則CPE使用STUN中定義的過程，探測綁定通道的超時時間。

l  CPE以必定的頻率週期性發送的STUN綁定請求，以維持NAT綁定通道的暢通，偵聽UDP鏈接請求。

l  CPE探測穿越NAT後的公網IP和端口，及其變化，將這些信息發送給ACS。

l  ACS有兩種方式獲取這些信息，一是經過STUN綁定請求消息自己；二是經過TR069中的UDPConnectionRequestAddress參數。

l  當ACS要創建與CPE的鏈接時，向CPE發送UDP Connection Request。爲了適應最普遍的NAT網關，它將從與STUN服務器相同的源地址和端口發送（不然沒法穿越「對稱型NAT網關」）。

G.2.1對CPE的要求

CPE的TR069參數，根據設備狀況，要符合TR098或TR181參數模型。

若是TR069中STUNEnable參數的值爲true，CPE必須判斷與STUN Server之間是否發生了ip/port轉換，若是發生了轉換，CPE必須：

l  判斷穿過NAT後的公網IP和端口。

l  探知NAT綁定通道的超時時間，並以保持綁定通道所需的速率，週期性發送綁定請求。

l  經過STUN可選屬性，指出CPE正在監聽哪一個綁定通道上的UDP Connection Request，以及綁定通道是否發生了更改。另外，更新TR069中的UDPConnectionRequestAddress參數，以指出與綁定通道關聯的公共IP地址和端口。

l  偵聽UDP Connection Request消息，並在這些消息到達時，根據其作出響應。

如上各條目的細節，會在下面的章節中詳述。

G.2.1.1 探知綁定通道

當經過TR069中ManagementServer對象的STUNEnable參數啓用STUN後，CPE必須向指定的STUN服務器（TR069的STUNServerAddress和STUNServerPort參數中指定的）發送綁定請求消息，如[21]中定義的那樣。若是TR069的STUNServerAddress參數沒有值，則必須使用ACS URL的host部分做爲STUN服務器地址。

若是發生了IP/PORT轉換，則爲了探知綁定通道，發送綁定請求的IP/PORT必須是監聽UDP ConnectionRequest的IP/PORT（探知綁定通道的超時時間時，將從不一樣的端口發送）。

CPE經過基本綁定請求消息，探知CPE和STUN服務器之間，是否發生了地址和端口轉換。方法是：比較請求發送的源IP/PORT和STUN服務器返回的MAPPED-ADDRESS屬性，若是IP或PORT不一樣，則說明發生了轉換。

若是探知到發生了IP/PORT轉換，則CPE必須記錄最新收到的MAPPED-ADDRESS屬性的值（一對IP/PORT），UDP ConnectionRequest將發送至其表示的IP/PORT。

後續，爲了維持綁定通道暢通，CPE按期發送綁定請求，此時CPE必須再次肯定是否發生IP/PORT轉換，若是發生了轉換，CPE必須記錄成功響應的MAPPED-ADDRESS屬性值。

若是CPE被預分配了STUNUsername/STUNPassword（TR069參數），而且CPE收到了Bainding Error Response，錯誤碼爲401（未受權），那麼CPE必須從新發送Binding Request，而且攜帶USERNAME和MESSAGE-INTEGRITY屬性。

當發送攜帶MESSAGEINTEGRITY屬性的綁定請求時，若是綁定響應中的MESSAGE-INTEGRITY屬性無效或不存在，CPE必須丟棄相應的綁定響應。

若是CPE的本地IP變動，CPE必須從新探測綁定通道，這種狀況下，TR069中STUNMinimumKeepAlivePeriod參數定義的綁定請求週期的最小限制不適用。

除了STUN服務器響應中明確的使用了401（未受權）錯誤碼，CPE不能在任何Binding Request中包含MESSAGE-INTEGRITY屬性。

CPE中的STUN客戶端，不須要支持STUN綁定請求的CHANGE-REQUEST屬性，也不須要識別綁定響應中出現的屬性的CHANGED-ADDRESS、SOURCE-ADDRESS和REFLECTED-FROM屬性。

CPE中的STUN客戶端，不須要支持交互共享祕鑰的消息，本附錄定義的過程當中，沒有使用這些消息。

G.2.1.2 維持綁定通道

爲了維持綁定通道，CPE必須週期性的發送Binding Request消息，發送消息時，使用監聽UDP ConnectionRequest消息的IP/PORT做爲源IP/PORT。

CPE發送這些綁定請求的頻率不能超過TR069中ManagementServer對象的STUNMinimumKeepAlivePeriod參數所指定的頻率。

CPE必須至少以TR069的STUNMaximumKeepAlivePeriod參數指定的頻率，發送這些綁定請求（若是這個參數有值的話）。

若是TR069中STUNMinimumKeepAlivePeriod和STUNMaximumKeepAlivePeriod參數的值不相等，那麼CPE必須主動發現NAT綁定通道所能維持的最長時間。爲此，CPE必須使用在[21]中描述的過程來探知綁定通道的超時時間。具體地說，CPE必須可以經過輔助源端口（與主源端口不一樣）發送綁定請求，來測試綁定是否超時，並使用綁定請求中的RESPONSEADDRESS屬性，指示將STUN綁定響應發送到主源端口（CPE偵聽UDP Connection Request消息的端口）。

CPE使用輔助源端口發出的綁定請求，來肯定綁定超時的具體過程，由CPE廠商自行決定。 通常由兩個階段組成：一個是發現階段，一個是監控階段。在發現階段，CPE試圖探知綁定超時的時間，並將測試不一樣的超時時間值，來肯定實際的超時值（例如，使用二進制搜索）。在監控階段，CPE將在刷新綁定通道以前，按期測試綁定通道，以肯定綁定通道是否仍然存在。若是綁定通道不存在了，那麼CPE能夠返回到發現階段，以探知新的綁定通道。

TR069中STUNMinimumKeepAlivePeriod參數定義的綁定請求週期，不適用於從輔助源端口發送的綁定請求。

G.2.1.3 將綁定通道的信息發送給ACS

有兩種方法能夠將綁定通道信息告知ACS。這兩種方法，CPE都必須支持。第一種方法，發送Binding Request時，經過STUN的可選屬性告知ACS。第二個方法是，CPE在綁定信息更改時，更新TR069中UDPConnectionRequestAddress參數的值。

Table 103列出了一組STUN屬性。它們使用大於0x7FFF的屬性類型值，STUN規範將其定義爲可選的。不識別可選屬性的STUN服務器須要忽略它們。

Table 103 用於Binding Request消息中的STUN可選屬性。

Attribute Type	Name	Description
0xC001	CONNECTION-REQUEST-BINDING	指出CPE監聽UDP Connection Request的綁定通道信息。 Value元素必須是以下內容： 0x64 0x73 0x6C 0x66 0x6F 0x72 0x75 0x6D 0x2E 0x6F 0x72 0x67 0x2F 0x54 0x52 0x2D 0x31 0x31 0x31 0x20 這至關於字符串：「dslforum.org/TR-111」 最後一個字符是空格，目的是使長度爲4個字符的整數倍。 它的Length元素必須是0x0014，也就是十進制的20。
0xC002	BINDING-CHANGE	表示綁定信息已經變化了。 這個屬性不包含值，它的Length元素必須是0。 這個屬性只能在包含CONNECTION-REQUEST-BINDING的狀況下使用。

CPE使用監聽UDP Connection Request的IP/PORT（即主源IP/PORT）發送的Binding Request，必須包含CONNECTION-REQUEST-BINDING屬性。其餘的全部Binding Request消息，必須不包含這個屬性。

若是TR069中的STUNUsername參數不爲空，包含CONNECTION-REQUEST-BINDING屬性的Binding Request消息必須包含USERNAME屬性，且值爲TR069 STUNUsername參數的值，若是有必要，須要在後面補充空格，以保證長度爲4字節的整數倍（STUN協議規定）。

每當CPE探測到NAT綁定通道變動（也包含第一次探測到綁定通道），必須當即發送一個Binding Request消息，從主源端口，也就是監聽UDP Connection Request消息的端口，而且包含BINDING-CHANGE屬性。此次Binding Request必須不包含RESPONSE-ADDRESS或者CHANGE-REQUEST屬性。在其餘Binding Request消息中，CPE必須不包含BINDING-CHANGE屬性。TR069中STUNMinimumKeepAlivePeriod定義的Binding Request的最小週期限制，對於包含BINDING-CHANGE屬性的Binding Request消息不適用。

對於包含BINDING-CHANGE屬性的Binding Request消息，CPE必須聽從[21]定義的重傳過程，以確保此消息被成功的接收。若是應用了重傳過程，CPE肯定Binding Request仍然失敗，則它不能發送包含BINDING-CHANGE的Binding Request（直到綁定隨後再次更改）。

若是IP/PORT發生了轉換，當CPE肯定綁定更改時（以及第一次CPE肯定綁定時），CPE必須更新TR069中ManagementServer對象中的UDPConnectionRequestAddress參數的值。特別的：

 

l  TR069中UDPConnectionRequestAddress的主機部分，必須設置爲與UDP鏈接請求關聯的綁定通道的公網IP地址。

l  TR069中UDPConnectionRequestAddress的端口部分，必須設置爲與UDP鏈接請求關聯的綁定通道的公網PORT。

若是CPE肯定IP/PORT發生了轉換，CPE必須把TR069中ManagementServer對象的NATDetected參數設置爲true。

若是ACS將TR069中UDPConnectionRequestAddress參數上的通知屬性，設置爲Active Notification，那麼每當綁定通道信息發生變化，CPE必須創建一個到ACS的鏈接，而且包含UDPConnectionRequestAddress參數在Inform消息中。

當TR069中UDPConnectionRequestAddress參數變動時，若是上次發送Notification的時間距如今小於TR069 UDPConnectionRequestAddressNotificationLimit參數，那麼本次Notification必須推遲，直到達到指定的最小時間間隔。

注意：除了指定的最小通知週期外，CPE也能夠根據本身的判斷來延遲通知，以免通知消息過多。這樣的延遲僅用在CPE認爲綁定通道會在一個較短的時間內再次變動時。例如，在主動發現綁定超時的過程當中，能夠合理地預期頻繁的綁定更改。相似地，CPE檢測到安全攻擊致使頻繁的綁定更改，並限制通知的數量，直到攻擊中止。

若是CPE判斷出IP/PORT都沒有發生轉換，那麼也必須通知ACS，通知的方法是，將TR069中NATDetected參數設置爲false，而且，將UDPConnectionRequestAddress設置爲本地IP/PORT，這個本地IP/PORT也就是CPE監聽UDP Connection Request消息的地址。

G.2.1.4 UDP Connection Requests

符合本附錄規定的CPE，必須在指定的端口上的臨聽UDP Connection Request。不管CPE是否檢測到IP/PORT轉換，以及是否啓用了STUN，都必須如此。

注意：CPE必須繼續監聽基於TCP的Connection Request，定義在3.2.1.2。

UDP Connection Request消息的格式定義在Section G.2.2.3。當CPE接收到一個UDP Connection Request消息時，必須進行鑑權和驗證。

當且僅當以下條件知足時，一個UDP Connection Request消息是有效的：

l  不得違反[6]對HTTP 1.1請求消息的要求。

l  Request Line中給出的方法必須是GET。

n  ts查詢參數的值，時間戳，必須嚴格大於最新收到的、有效的、鑑權經過的UDP Connection Request消息。

n  爲了保證上述的比較能夠執行，CPE必須維護一個持久化記錄，保存最新成功驗證和鑑權的UDP Connection Request時間戳（除了CPE發生重啓）。驗證或鑑權失敗的UDP Connection Request消息的時間戳不得保存。CPE能夠在重啓過程當中保留這個值，若是沒有保留，在重啓以後應當即使用0值。

n  CPE對時間戳的要求能夠比上面所述的更嚴格。例如，CPE能夠另外驗證時間戳是否在一個時間窗口內（相對於CPE的當前時間）。若是CPE選擇這樣作，它應該避免時間窗口過窄，以便在CPE和ACS中都容許一個合理的偏差範圍。

l  id參數，即Message ID，必須與最近收到的、有效的、鑑權成功的UDP Connection Request消息不一樣。

l  un參數，即Username，值必須與TR069中ManagementServer對象的ConnectionRequestUsername參數一致。

當且僅當以下條件知足時，一個UDP Connection Request消息是鑑權經過的：

l  sig參數，即Signature，必須與CPE根據Section G.2.2.3使用TR069中ManagementServer對象的ConnectionRequestPassword參數計算出的簽名一致。

每當CPE接收併成功地驗證和鑑權UDP Connection Request時，它必須遵循與3.2.1.2節中定義的基於tcp的鏈接請求相同的要求。

CPE必須忽略驗證或鑑權不成功的UDP Connection Request。

CPE必須忽略UDP Connection Request中可能出現的，任何非空消息體的內容（這些消息體是爲協議的將來版本預留的）。

由於STUN響應和UDP Connection Request將在同一個UDP端口上接收，CPE必須使用消息自己的內容區分STUN消息和UDP Connection Request。

由於[21]中定義的全部STUN消息的第一個字節都是0或1，而UDP Connection Request第一個字節始終是ASCII編碼的字母，因此CPE可使用這種方式來區分消息類型。

端口7547已經被IANA分配給CWMP（見[17]），CPE可使用這個端口來處理UDP鏈接請求。

G.2.2對ACS的要求

ACS必須與一個符合此附錄要求的STUN服務器關聯起來。

G.2.2.1對STUN服務器的要求

STUN服務器必須符合[21]中定義的全部要求，但如下要求除外，STUN服務器能夠選擇不實現這些要求：

l  STUN服務器不須要支持在[21]中定義的共享祕密交換機制。若是使用消息完整性，則必須靜態地提供共享祕密，並與CPE TR069參數中的STUNUsername和STUNPassword參數對應。

l  STUN服務器不須要支持用於發送綁定響應(A2/P2)的輔助源IP地址或端口。若是沒有，使用主地址和端口(A1/P1)填充CHANGE-ADDRESS屬性便可，若是在綁定請求中收到CHANGE-REQUEST屬性，則STUN服務器能夠忽略該屬性。

經過使用錯誤代碼401(未經受權)的Binding Error Response來響應請求，STUN服務器能夠對任何接收到的Binding Request要求消息完整性。

G.2.2.2 判斷綁定通道信息

ACS能夠經過兩種方式來斷定綁定通道信息。

G.2.2.2.1 基於STUN消息的方式

若是ACS選擇使用這種方式，那麼它應該在每一個CPE的ManagementServer對象中設置一個非空的STUNUsername和STUNPassword。在ACS所管理的全部CPE中，STUNUsername必須是惟一的，以確保能夠此惟一關聯CPE。在ACS所管理的全部CPE中，STUNPassword應該是惟一的，而且應該符合[21]規定的密碼強度規則。

每當STUN服務器收到一個Binding Request，而且消息中同時包含BINDING-CHANGE和CONNECTION-REQUEST-BINDING屬性：

l  STUN服務器應該響應回401錯誤，強制CPE重發附帶消息完整性的Binding Request。

l  當STUN服務器接收到重發的具備消息完整性的Binding Request時，應該對請求者進行身份驗證。若是ACS和STUN服務器不是整合在一塊兒的，這可能涉及到STUN服務器和ACS之間的通訊。

l  若是身份驗證失敗，則STUN服務器必須響應[21]中定義的Binding Request Error，而且再也不進行後續的操做。

l  若是身份驗證成功，STUN服務器應該從Binding Request消息中提取出源IP/PORT，而且將其記錄下來，用於發送UDP Connection Request消息。根據實現的不一樣，這可能涉及STUN服務器將IP/PORT與TR069參數STUNUsername的對應關係發送給ACS，ACS將根據CPE對應的STUNUsername保存這些關係。即ACS可據此得知，可用於向特定CPE發送UDP Connection Request消息的IP/PORT。

l  對於一個Binding Request消息中包含的Transaction ID，STUN服務器僅執行一次上述操做。應該忽略具備相同事務ID的綁定請求的冗餘副本（爲保障消息必定能被ACS接收，CPE可能發送屢次）。

使用這種方法，STUN服務器也能夠選擇不要求消息完整性或對綁定請求進行身份驗證，除非它遵循上述過程來肯定綁定信息。

ACS能夠在任什麼時候間斷定當前綁定通道，即便沒有攜帶CONNECTION-REQUEST-BINDING屬性的Binding Request來通知變動（這句翻譯的可能有問題，原句是The ACS MAY determine the current binding at any time even if no change was notified by following the above procedure on any received Binding Request for which the CONNECTION-REQUEST-BINDING attribute is present ）。在這些Binding Request中的USERNAME屬性，可在後續的身份驗證以前，供ACS暫時的斷定CPE的身份。這容許ACS按期驗證綁定信息，以確保在綁定通道更改的消息未到達ACS時，該信息是最新的。

若是ACS肯定CPE再也不位於正在進行IP/PORT轉換的NAT以後，那麼ACS可使用3.2.1.2節中定義的基於TCP的鏈接請求。

G.2.2.2.2 基於TR069 Notification的方式

若是ACS選擇在TR069的UDPConnectionRequestAddress參數上使用Active Notification，它應該執行如下操做：

l  設置UDPConnectionRequestAddress參數的Notification屬性，以激活通知功能。

l  每當Inform參數中包含UDPConnectionRequestAddress參數時，記錄其變動，而且使用最近記錄的地址，做爲發送UDP Connection Request消息的目標。特別的，目標的IP地址由此參數的host部分得來，PORT由此參數的port部分得來。若是，host部分給出的是一個域名，ACS必須使用DNS斷定對應的IP地址。若是端口沒有在UDPConnectionRequestAddress參數中明確指明，則默認使用80端口。

l  觀察TR069中NATDetected參數的值（能夠在UDPConnectionRequestAddress發生變化時讀取它，也能夠在該參數上啓用通知功能）。當該參數爲false時，ACS可使用3.2.1.2節中定義的基於TCP的Connection Request。

使用這種方法，ACS能夠選擇不要求消息完整性或驗證STUN綁定請求，由於這些請求不用於向ACS傳遞信息。在這種狀況下，ACS不須要在CPE中設置STUNUsername或STUNPassword。

G.2.2.3 UDP Connection Request

ACS必須從與STUN服務器相同的源IP地址和端口發送UDP鏈接請求消息。

一個UDP Connection Request必須在單個數據包中傳輸。

ACS應該對同一個UDP Connection Request應該發送屢次，以免丟包。當ACS發送相同UDP Connection Request時，消息的內容（包括Message ID、Timestamp和cnonce）必須相同。

UDP Connection Request沒有對應的響應消息。

UDP Connection Request消息的格式派生自HTTP 1.1 [6] GET消息的格式，儘管不使用HTTP 1.1協議自己。

特別的，UDP Connection Request消息必須知足下列要求：

l  必須是一個有效的HTTP 1.1 GET消息。

l  必須不包含消息體。

l  若是包含Content-Length Header，值必須爲0。

l  Request Line中的Method必須爲GET。

l  Request Line中給出的Request-URI必須是Absolute-URI。URI必須知足以下格式：

n  Scheme部分必須是http或者HTTP。

n  Authority部分必須如[12]中定義的同樣。ACS能夠將這個值設爲TR069的UDPConnectionRequestAddress（若是這個參數有值的話）。不然，ACS必須從實際的目的IP/PORT中派生此字符串。port部分必須存在，除非目標port是80（默認值）。

n  URI的Path部分必須爲空。

n  URI的Query部分，必須包含一個查詢字符串，按照[23]中關於「application/x-www-form-urlencoded」的方式進行編碼。查詢字符串必須包含以下的鍵值對：

Name	Value
ts	Timestamp。從Unix紀元到建立消息時的秒數（標準Unix時間戳）。
id	Message ID。一個無符號整數，消息重傳時必須相同，後續發送的不一樣的UDP Connection Request消息必須不一樣。
un	Username。TR069 ManagementServer.ConnectionRequestUsername參數的值，此參數的值是從CPE讀取的。
cn	Cnonce。一個隨機的字符串，由ACS決定。
sig	Signature。由HMAC-SHA1 (Key, Text) [19]的40個字符十六進制表示（不區分大小寫）組成，知足以下要求： l  key的值是TR069 ManagementServer.ConnectionRequestPassword參數的值。 l  Text是一個字符串，它由如下元素鏈接而成，按照以下列出的順序，且各項之間沒有空格： n  ts的值 n  id的值 n  un的值 n  cn的值

以下是一個URI示例：

http://10.1.1.1:8080?ts=1120673700&id=1234&un=CPE57689&cn=XTGRWIPC6D3IPXS3&sig=3545F7B5820D76A3DF45A3A509DA8D8C38F13512

G.2.3 消息流程

Figure 12 Binding discovery / maintenance from the primary source port

Figure 12是一個消息流示例。

在全部的示例中，全部的ip/port顯示爲(A,P)符號，A表示IP，P表示PORT。在示例中，(A1,P1)爲CPE的主端口，用於監聽UDP Connection Request消息，(A1,P2)爲CPE的輔助端口，用於探測綁定超時時間。穿過NAT後，地址分別轉換成了(A1',P1')和(A2',P2')。在全部的示例中，都假設STUN服務器沒有輔助的IP/PORT，因此Binding Response中的CHANGED-ADDRESS屬性（CPE不須要使用）內容是STUN服務器的主IP/PORT，也就是(A3,P3)。

Figure 12展現了週期性的探知綁定通道、維持綁定通道流程，即CPE發送Binding Request消息（使用主IP/PORT）攜帶CONNECTION-REQUEST-BINDING屬性和USERNAME屬性（若是Username有值的話）。在這個示例中，假定STUN服務器不對請求進行身份驗證。

 

Figure 13 Binding Request from secondary source port for binding timeout discovery

Figure 13展現了CPE從輔端口發送Binding Request消息，用於發現主IP/PORT的綁定是否超時了。在此示例中，Binding Request消息中沒有包含CONNECTION-REQUEST-BINDING屬性，由於這個消息不是從主端口發出的。若是主IP/PORT綁定未超時最後一步的消息（灰色箭頭）將不會出現。（CPE沒有實現這個流程）

Figure 14 – Binding change notification authenticated by the ACS

Figure 14展現了當STUN服務器選擇使用基於STUN的通知方式時，Binding Change的通知流程。這種狀況下，STUN服務器在存儲綁定信息前，要先對Binding Request進行身份驗證。

Figure 15 – Binding change notification not authenticated by the ACS

Figure 15展現了當STUN選擇使用基於TR069 Notification的通知方式時，Binding Change的通知流程。這種狀況下，不須要對Binding Request消息進行身份驗證，由於ACS使用CWMP TR069通知去更新綁定信息。

Figure 16 – UDP Connection Request

Figure 16展現了ACS向CPE發送一個UDP Connection Request，來觸發一個CWMP TR069會話的流程。此示例中，STUN服務器發送了屢次相同的UDP Connection Request，以保障消息能被CPE成功接收。

G.3 安全方面

• STUN協議描述了幾種使用STUN機制進行攻擊的可能性。相關詳述，請參考Section 12 of RFC 3489 [21]。
• 由於綁定變動，會觸發ACS對CPE進行身份驗證，數據庫更新，還可能須要創建CMWP TR069會話從而接收Inform消息，攻擊者可使NAT綁定頻繁變動，從而致使ACS負荷加大。當使用TR069 Notification方式的通知方式時，ACS能夠設置一個最小通知週期來避免過於頻繁的變動通知。可是，要權衡好最大通知速率，和綁定信息過時時間，不然可能致使ACS因綁定信息過時，而沒法向CPE發送Connection Request消息。