基于RFC 3576協議的BRAS主動控制系統研究

薛曉東，趙永軍（中國鐵通河南分公司，河南鄭州450052）

0 前言

高速寬帶化是當前網絡發展的主要方向。經連年的持續發展，我國寬帶網絡己初具規模。目前各大運營商都在積極開展新業務以吸引更多的用戶，而其中的寬帶認證鑒權與計費系統將扮演舉足輕重的角色。如何在基礎網絡接入業務的基礎上進一步提供更多的服務選擇，是各大運營商目前面臨的共同問題。無疑，通過個性化服務，創造更高的ARUP值，將是寬帶網絡發展的主要方向。

針對上述需求，本文首先對目前各大運營商普遍使用的遠程身份驗證撥入用戶服務（RADIUS）協議組的認證部分作一簡單介紹。介紹如何應用RADIUS協議來實現寬帶網絡接入服務器（BRAS）與RADIUS服務器之間的通信，完成對個人用戶上網認證、授權和計費控制的；然后提出了一些現實問題，并引入RFC3576和一些輔助技術，討論如何設計和實現一套接入設備的主動管理系統。

1 RADIUS協議簡介

RADIUS是一種C/S結構協議，其客戶端最初就是網絡接入服務器（NAS-Net Access Server），現在任何RADIUS客戶端軟件的計算機都可成為RADIUS的客戶端。RADIUS協議認證機制靈活，可采用密碼認證協議（PAP）、挑戰握手認證協議（CHAP）或 Unix 登錄認證等多種方式。

RADIUS協議的基本工作原理是：用戶接入NAS，NAS使用Access-Require數據包向RADIUS服務器提交用戶信息（如用戶名、密碼等，用戶密碼是經MD5加密的），雙方使用共享密鑰，這個密鑰不經網絡傳播；RADIUS服務器對用戶名和密碼的合法性進行檢驗，必要時可提出一個Challenge，要求進一步對用戶認證，也可對NAS進行類似的認證；如果合法，給NAS返回Access-Accept數據包，允許用戶進行下一步工作，否則返回Access-Reject數據包，拒絕用戶訪問；如果允許訪問，NAS向RADIUS服務器提出計費請求（Account-Require），RADIUS 服務器響應 Account-Accept，對用戶開始計費，同時用戶可進行相關操作。

RADIUS服務器和NAS服務器通過用戶數據包協議（UDP）進行通信，RADIUS服務器的1812端口負責認證，1813端口負責計費。采用UDP的基本原因是其效率比較高。為彌補UDP協議在可靠性上的不足，RADIUS協議還規定了重傳機制。如果NAS向某個RADIUS服務器提交請求沒有收到返回信息，則可要求備份RADIUS服務器重傳。由于有多個備份RADIUS服務器，因此NAS進行重傳時可采用輪詢或先主后備方式。如果備份RADIUS服務器的密鑰和以前RADIUS服務器的密鑰有所不同，則需重新進行認證。由于RADIUS協議簡單明了并具有可擴充性，因此得到了廣泛應用（如普通電話、ADSL、小區寬帶上網及IP電話、VPDN、移動電話預付費等）。最近，IEEE提出的802.1x標準是一種基于端口的標準，用于對無線網絡的接入認證，在認證時也采用了RADIUS協議。

1.1 遠端RADIUS驗證-PAP方式

遠端PAP方式見圖1。用戶請求上網時，用戶以明文形式將用戶名及其密碼傳遞給NAS，NAS把用戶名和加密過的密碼放到驗證請求包的相應屬性中傳遞給RADIUS服務器，根據RADIUS服務器返回結果來決定是否允許該用戶上網。

1.2 遠端RADIUS驗證-CHAP方式

遠端CHAP方式見圖2。用戶請求上網時，NAS產生一個16 byte隨機碼（還有一個ID號-本地路由器主機名）給用戶；用戶端得到該包后使用自己獨有的設備或軟件對傳來的各域進行加密，生成一個Response傳給NAS，NAS把傳回來的CHAP ID和Response分別作為用戶名、密碼及原來的16 byte隨機碼傳給RADIUS服務器；RADIUS根據用戶名在服務器端查找數據庫，得到和用戶端進行加密所用的一樣的密碼，然后根據傳來的16 byte隨機碼進行加密，將其結果與傳來的Password進行比較，相同時表明驗證通過，否則表明驗證失敗。另外，如果驗證成功，RADIUS服務器同樣也可生成一個16 byte隨機碼對用戶進行詢問。

1.3 RADIUS協議傳輸模式

采用RADIUSUDP傳輸模式有以下幾個原因。

a）NAS和RADIUS服務器間傳遞的一般是數十至上百個字節長度的數據，用戶可容忍幾秒到十幾秒的驗證等待時間。處理大量用戶時服務器端采用多線程，可支持較高的并發。

b）TCP必須是成功建立連接后才進行數據傳輸的。在大量用戶使用的情況下，TCP的實時性不好。

c）由于向主用服務器發送請求失敗后還必須向備用服務器發送請求，因此RADIUS要有重傳和備用服務器機制，而TCP不能很好地滿足這一機制。

2 RFC3576協議

2.1 簡介

RFC3576協議于 2003年 7月由 Cisco Systems、Circular Logic和Microsoft等3家公司的3位作者發表，全稱為Dynamic Authorization Extensions to RADIUS，可實現對RADIUS的授權動態控制。在被BRAS/NAS實現后，就允許動態地改變一個用戶的會話 （包括中斷用戶會話和修改會話授權2個功能定義）。目前，Juniper、華為、中興等BRAS廠家均采用不同形式實現了該協議。

由RFC2865定義的RADIUS基本協議不支持由RADIUS服務器主動向NAS發出的消息，即用戶一旦撥號上網后，其主動下網前的會話狀態是不受RADIUS服務器控制的，然而不少時候確實是需要在用戶不重新發起一個會話情況下修改用戶會話狀態的。為克服這一限制，多個廠家實現了RADIUS協議的擴展命令，以支持由RADIUS主動發給NAS的命令消息。擴展命令支持停止會話（DM）和授權變更（CoA）2種消息，其中：DM消息實現強制將用戶會話立刻停止，CoA消息實現修改用戶授權 （如數據過濾器、帶寬、ACL、QoS或其他一些廠家支持的屬性）。

2.2 DM

一個斷線請求 （Disconnect-Quest）包由RADIUS服務器發出，在NAS收到此包后結束一個用戶的會話，并丟棄掉相關的上下文信息。斷線請求包將發送到NAS的3799號端口，并在包中通過標識屬性（如ACCT-SESSION-ID）告知NAS需結束的會話。DM消息的原理見圖3。

如果會話上下文被丟棄且用戶會話終止，則NAS需給斷線請求包一個ACK的回應；如果NAS不能中斷會話并丟棄其相關上下文，就需回復一個NAK的包給RADIUS服務器。NAS必須回應斷線請求包。如果NAS不支持這種斷線請求，則需回復一個帶有“Unsupported Service”值的Error-Cause屬性包給RADIUS服務器。在成功終止會話后，在NAS返回給RADIUS的ACK包中需包括值為Admin-Reset的Acct-Terminate屬性（見RFC2866），用以標識會話終止的原因。

2.3 CoA

CoA請求包里包含了要求NAS修改的會話動態授權消息，典型的如修改用戶的過濾器和帶寬。更細顆粒度的帶寬控制可實現上行和下行的區別修改。CoA消息使用的端口和報文格式與DM消息相同。CoA消息的原理見圖4。

同樣，如果NAS成功地修改了用戶的會話授權，則需回復一個ACK消息給RADIUS服務器，否則給RADIUS服務器回應一個NAK報文，在NAK報文中需列出不支持的屬性和值。

3 實現接入設備主動控制系統需解決的問題

RFC3576是個協議建議，并非廠家必須實現的強制性規則。因此，要真正實現一個達到電信級應用要求的接入設備主動控制系統，還需解決大量的實際問題。下面僅就其中的幾個問題進行闡述，并提出解決建議。需要說明的是，這些建議僅為理論研究，而不代表實際測試結果。

3.1 獲得會話的詳細參數簡介

在RFC中，并未描述在不知道當前會話參數的情況下，如何從NAS上獲取參數的辦法。但在實際工程中，如果要實現控制就必須提前了解會話的具體參數，并根據參數內容作出控制的判斷和需控制的參數定制。可通過以下2個方式來獲取一個具體會話的參數。

a）通過Telnet命令仿真獲得。Telnet命令仿真方式是利用軟件來模擬Telnet的命令操作，將需問詢的參數加入到操作命令中，再采用統一的字符代碼表達式對其返回的結果進行格式化，生成屬性對。對于此方式，筆者曾用Python的內置模塊telnetlib測試成功。

b）通過SNMP網管命令獲得。通常的BRAS均支持SNMP網管命令，可通過此命令查詢系統狀態。而對于服務器上的會話狀態，通常需通過廠家提供的MIB庫對其返回的信息進行分析。

3.2 RFC中CoA的語義問題

CoA在RFC3576中有個潛在的模糊問題，即：由于只有一次交互過程，所以在RADIUS發給NAS的CoA報文屬性對中，對未發送的屬性是去掉或保持在語義上是模糊的。例如：RADIUS給BAS發送了帶寬=1 024 bit/s、ACL=XTemplage屬性，而會話本身具有帶寬=512 bit/s、ACL=YTemplage、IsFilter=Yes屬性。 對于“帶寬”和“ACL”屬性沒有2義性來說，很明確是要進行修改操作的，但對于“IsFilter”屬性，是要從會話中刪除此或不作任何個性，協議本身并未明確規定。因此，需準確了解不同廠家的BRAS實現方式，并據其定義相應的規則庫。

3.3 廠家自定義屬性的支持

由于CoA可能實現的功能非常多，具體的功能均通過廠家的擴展屬性來實現。因此在實際工程中，需建立一套對廠家擴展屬性和實現功能的一個規則數據庫。通過此庫來保存不同廠家設備甚至同一型號設備的不同配置方式所帶來的差異性，并提供友好管理界面實現隨時修改和測試功能。

3.4 實現方式

對于接入設備的主動控制系統來說，其功能模塊可按圖5的方式來實現。

由圖5可知，通過一個數據庫來管理BRAS的廠家私有屬性及對協議的支持細節，通過中間的服務提供者完成對不同底層技術的真實實現，并由各服務提供者完成與設備的真正通信。中間由一個統一的服務接口來完成對下層實現細節的屏蔽。上層則提供幾個標準系統，如：通過“基于Web的管理系統”來實現對規則庫的管理及對服務的真實調用；通過“外部接口系統”完成需對系統進行的自動調用或業務系統需實現的帶寬調整等；“服務測試系統”則是提供檢查服務提供者的有效性手段，以方便及時地將各服務提供者及BAS的狀態反饋給各上層系統。

4 結束語

本文簡單介紹了RADIUS協議的基本概念，深入闡述了RFC3576協議的基本原理，簡要論述了如何實現一套基于web的BRAS上網會話的主動控制系統。該系統在實現電信業務上有極大的潛在好處。它打破了以往用戶一旦通過認證并上網后，便不可對其上網會話屬性進行修改的成見，并為實現通過一個門戶網站動態地選擇當前要使用的服務、不斷線的服務升級、動態ACL、動態帶寬、動態QoS控制、方便的服務測試和強制斷線等提供了辦法，還為未來的業務向更友好、更靈活的方面發展打下了基礎。

［1］Rigney C.RFC 2866-RADIUS Accounting［EB/OL］.［2010-12-09］.http://www.cnpaf.net/Class/Rfcen/200502/3931.htm.

［2］Aboba B.，J.Wood.RFC 3539-Authentication，Authorization and Accounting （AAA）Transport Profile ［EB/OL］. ［2010-12-09］.http://www.chinaitpower.com/A200508/2005-08-02/181855.html.

［3］摩根，洛夫林.CCNP ISCW認證考試指南［M］.夏俊杰，譯.北京：人民郵電出版社，2008.