華為公司寬帶產(chǎn)品Portal協(xié)議標(biāo)準(zhǔn)全解

1、Q/DKBA華為技術(shù)有限公司企業(yè)技術(shù)標(biāo)準(zhǔn)Q/DKBAXXXX-2001華為公司寬帶產(chǎn)品Portal協(xié)議標(biāo)準(zhǔn)第2部分：Portal標(biāo)準(zhǔn)V2.012001-XX-XX發(fā)布2001-XX-XX實(shí)施華為技術(shù)有限公司發(fā)布修訂說明本文檔對2.0版本做了如下修改：增加了WEB_STATUS_NOTIFY和WEB_ACK_STATUS_NOTIFY命令字修改ReqID字段的說明修改Port字段的說明附錄增加成功上線的報(bào)文示例Q/DKBAXXXX-2001Q/DKBAXXXX-2001密級：機(jī)密Q/DKBAXXXX-2001Q/DKBAXXXX-2001密級：機(jī)密 Attr（屬性字段）AttrTypeAttrL

2、en屬性含義Textinfo0 x05大于等于3,小于等于255本屬性只能在BAS到PortalServer的報(bào)文中存在，同時(shí)，協(xié)議規(guī)定：BAS只是透傳從RADIUS來的錯(cuò)誤信息，屬性的內(nèi)容可以為任意字符串，不帶0結(jié)束符UpLinkFlux0 x062或者10本屬性只能在REQ_INF0和ACK_INF0報(bào)文中存在。數(shù)量不能超過1。當(dāng)Type=REQ_INF0時(shí)，長度為2。當(dāng)Type=ACK_INFO時(shí)，長度為10，內(nèi)容是一個(gè)表示該用戶的流量的8字節(jié)無符號整數(shù)（網(wǎng)絡(luò)順序），單位為kbytesDownLinkFlux0 x072或者10同上Port0 x08大于等于2,小于等于37MA5200F

3、:“主機(jī)名”+“vlan”+“2位端口號”+“一”+（“4位VLAN）+“vlan”MA5200G:“主機(jī)名”+“2位槽號”+“1位子槽號”+“2位端口號”+（“4位VPI”+“5位VCI”）或（“4位外層VLAN”+“0”+“4位內(nèi)層VLAN”）+“vlan”說明：MA5200F的主機(jī)名為14個(gè)字符，內(nèi)容總長度為32字符;MA5200G的主機(jī)名為12字符，只有一層VLAN時(shí)，外層VLAN填“0”，內(nèi)容總長度為32個(gè)字符。表4-3新增屬性的定義5流程和相關(guān)說明Version2的協(xié)議流程除了完全包含Version1的協(xié)議流程之外，還增加了信息查詢和BAS主動(dòng)通知PortalServer下線的流程

4、。舊版本協(xié)議的流程說明如下：5.1Chap認(rèn)證方式上線流程Chap認(rèn)證流程（每一步都正確的情況下）（圖5-1）圖5-1Chap方式認(rèn)證正常流程Chap認(rèn)證流程（請求Challenge失敗或被拒絕的情況下）（圖5-2）圖5-2Chap認(rèn)證方式請求魔術(shù)字失敗流程Chap認(rèn)證流程（請求Challenge沒有響應(yīng)的情況下）（圖5-3）圖5-3Chap認(rèn)證方式，請求魔術(shù)字無響應(yīng)流程Chap認(rèn)證流程（認(rèn)證結(jié)果為失敗或被拒絕的情況下）（圖5-4）圖5-4Chap認(rèn)證方式，認(rèn)證失敗流程Chap認(rèn)證流程（請求認(rèn)證沒有響應(yīng)的情況下）（圖5-5）圖5-5Chap認(rèn)證方式，請求認(rèn)證無響應(yīng)流程Pap認(rèn)證方式上線流程Pa

5、p認(rèn)證流程（每一步都正確的情況下）（圖5-6）圖：5-6Pap認(rèn)證方式正常流程Pap認(rèn)證流程（認(rèn)證失敗或被拒絕的情況下）（圖5-7）圖5-7Pap認(rèn)證方式，認(rèn)證失敗流程Pap認(rèn)證流程（請求認(rèn)證沒有響應(yīng)的情況下）（圖5-8）圖5-8Pap認(rèn)證方式，請求認(rèn)證無響應(yīng)流程下線流程（說明：下線流程不分Chap和Pap）下線成功的流程（圖5-9）圖5-9正常下線流程下線失敗或被拒絕的流程（圖5-10）圖5-10下線失敗流程下線沒有響應(yīng)流程（圖5-11）圖5-11下線報(bào)文無響應(yīng)流程新增流程的說明如下：信息詢問流程（無論成功還是失敗，參見圖5-12）圖5-12信息詢問流程根據(jù)協(xié)議，REQ_INF0消息的定義如

6、下：Ver2TypeREQ_INFOPap/Chap無意義，填0Rsv無意義，填0SerialNo任意，建議使用一個(gè)能用于區(qū)分當(dāng)前不同會(huì)話的一個(gè)數(shù)值。Server將在應(yīng)答消息中使用相同的SerialNoReqID無意義，填0UserIP被詢問的用戶IPUserPort無意義，填0ErrCode無意義，填0AttrNum根據(jù)實(shí)際情況填寫Authenticator根據(jù)RequestAuthenticator的計(jì)算方法進(jìn)行計(jì)算的結(jié)果Attribution這個(gè)消息可以帶屬性UpLinkFlux,DownLinkFlux,和Port中的一個(gè)或多個(gè)，取決于Client需要詢問何種信息。在發(fā)詢問時(shí)，根據(jù)需要

7、詢問的內(nèi)容，帶一個(gè)長度為2的相應(yīng)屬性即可。ACK_INFO的消息的定義如下:Ver2TypeACK_INF0Pap/Chap無意義，填0Rsv無意義，填0SerialNo與相應(yīng)詢問消息的SerialNo一致ReqID無意義，填0UserIP被詢問的用戶IPUserPort無意義，填0ErrCode見上文的對ErrCode的定義AttrNum根據(jù)實(shí)際情況填寫Authenticator根據(jù)ResponseAuthenticator的計(jì)算方法進(jìn)行計(jì)算的結(jié)果Attribution這個(gè)消息可以帶屬性UpLinkFlux,DownLinkFlux,和Port中的一個(gè)或多個(gè)，取決于相應(yīng)的REQ_INFO消息

8、帶了哪些詢問屬性。如果某屬性取不到，則不返回該屬性。所以一個(gè)屬性在本消息中存在的必要條件是：詢問消息中存在能被取得5.5下線通知流程（BAS通知PortalServer）對于從PortalServer向BAS請求用戶下線的流程此處不進(jìn)行描述。用于Server首先檢測到用戶已經(jīng)下線；或者BAS主動(dòng)切斷連接時(shí)，用來通知PortalServer（參見圖5-13）：圖5-13下線通知流程通知消息固定向UDP端口50100發(fā)送。NTF_L0G0UT的定義如下：Ver2TypeNTF_LOGOUTPap/Chap無意義，填0Rsv無意義，填0SerialNo無意義，填0ReqID無意義，填0UserIP被

9、下線的用戶IPUserPort無意義，填0ErrCode見上文的對ErrCode的定義AttrNum根據(jù)實(shí)際情況填寫Authenticator根據(jù)RequestAuthenticator的計(jì)算方法進(jìn)行計(jì)算的結(jié)果Attribution無，或者Server設(shè)備需要通過文字信息描述下線原因，可以帶一個(gè)或多個(gè)TextInfo屬性6其他說明6.1關(guān)于Textlnfo屬性的使用Textlnfo用于傳遞文字信息。建議使用如下慣用法：0正常情況下，任何消息都不帶該屬性。0如果Server通過第三方設(shè)備實(shí)現(xiàn)鑒權(quán)，例如RadiusServer，而該設(shè)備又包含文字信息，應(yīng)使用該信息作為文字信息。0BAS本身產(chǎn)生的錯(cuò)

10、誤信息不傳送到Portalserver。0建議BAS能通過調(diào)試命令關(guān)閉/打開消息透傳的功能。協(xié)議的兼容性顯然，引入了報(bào)文驗(yàn)證字之后，版本Version2與Version1完全不兼容。如果嚴(yán)格按照擴(kuò)充后的協(xié)議，舊版本的下線流程和查詢流程報(bào)文將因?yàn)闆]有攜帶Authenticator字段而被認(rèn)為是非法的報(bào)文。為了實(shí)現(xiàn)與舊版本的兼容，建議在實(shí)現(xiàn)新協(xié)議的軟件中增加版本切換的控制開關(guān)：如果對端使用舊版本協(xié)議，則通過兼容開關(guān)確保能與之對接。協(xié)議的不完善之處盡管對每個(gè)報(bào)文都增加了校驗(yàn)，但是依然可能被BAS和PortalServer之外的第三者利用。本文不對此進(jìn)行詳細(xì)的描述。協(xié)議其他說明1、此協(xié)議規(guī)定承載報(bào)文的

11、是UDP協(xié)議，也即報(bào)文為UDP報(bào)文，BAS設(shè)備在固定端口2000上等待接收PortalServer發(fā)來的各種請求報(bào)文和確認(rèn)報(bào)文；2、在PortalServer端目前不采用超時(shí)重傳和出錯(cuò)重傳，對于PortalServer發(fā)出的各種請求報(bào)文，若在一定的時(shí)間內(nèi)沒有收到BAS設(shè)備發(fā)來的響應(yīng)報(bào)文或著收到的響應(yīng)報(bào)文出錯(cuò)，對于超時(shí)沒有響應(yīng)則PortalServer向BAS設(shè)備發(fā)送一個(gè)表示等待響應(yīng)超時(shí)的報(bào)文，同時(shí)PortalServer認(rèn)為相應(yīng)的請求失敗，直接告訴用戶失?。?、Chap認(rèn)證的相關(guān)說明：、challenge的生成：challenge由BAS設(shè)備在收到請求Challenge報(bào)文的時(shí)候隨機(jī)生成，長度

12、為16個(gè)字節(jié)，跟隨Challenge應(yīng)答報(bào)文下發(fā)到PortalServer。、Chap_Password的生成：Chap_Password的生成遵循標(biāo)準(zhǔn)的Radious協(xié)議中的Chap_Password生成方法(參見RFC2865)。密碼加密使用MD5算法，MD5函數(shù)的輸入為ChapIDPasswordChallenge其中，ChapID取ReqID的低8位，Password的長度不夠協(xié)議規(guī)定的最大長度，其后不需要補(bǔ)零。4、無論采用Chap認(rèn)證還是Pap認(rèn)證，都允許用戶口令為空；5、當(dāng)用戶向PortalServer提交的連接請求里用戶名為空時(shí)，PortalServer在向BAS設(shè)備發(fā)送認(rèn)證請求

13、時(shí)應(yīng)用一個(gè)缺省的用戶名代替(比如*)；6、認(rèn)證流程中各種報(bào)文所帶屬性的個(gè)數(shù)(建議)：、請求Challenge報(bào)文：0個(gè)屬性；、對請求Challenge響應(yīng)的報(bào)文：若請求Challenge成功則為1個(gè)屬性一Challenge屬性，若請求Challenge失敗則屬性個(gè)數(shù)為0個(gè)；、請求認(rèn)證報(bào)文：2個(gè)屬性，分別為用戶名、PassWord或ChapPassWord；、對請求認(rèn)證的響應(yīng)報(bào)文：0個(gè)屬性；、請求下線報(bào)文或表示超時(shí)的報(bào)文：0個(gè)屬性；、對請求下線的響應(yīng)報(bào)文：0個(gè)屬性；、PortalServer對收到從BAS設(shè)備發(fā)來的認(rèn)證成功報(bào)文的確認(rèn)：0個(gè)屬性；7、報(bào)文的長度限制是最小32字節(jié)，最大1024(1K

14、)字節(jié)；7附錄7.1成功的Chap認(rèn)證報(bào)文示例示例中使用的用戶名為：webdefault0密碼為：123456服務(wù)器的密鑰secret：1234567890123456PORTALServer-BRAS的Challenge請求報(bào)文(REQ_CHALLENGE)ver:2type:challengereqMethod:chapSerialNo:4ReqID:0UserIP:172.75.100.253ErrCode:0AttrNum:0報(bào)文的二進(jìn)制形式：0201000000040000ac4b64fd00000000e80da1b279f3b5f2e8cbc2dd324f56dd驗(yàn)證字Authe

15、nticator的計(jì)算方法：以字節(jié)流Ver+Type+PAP/CHAP+Rsvd+SerialNo+ReqID+UserIP+UserPort+ErrCode+AttrNum+16個(gè)字節(jié)的0+requestattributes+secret作為MD5的輸入，得到的MD5輸出就是請求報(bào)文的驗(yàn)證字Authenticator的內(nèi)容。這里就是以0201000000040000ac4b64fd000000000000000000000000000000000000000031323334353637383930313233343536為md5輸入，輸出的就是驗(yàn)證字Authenticator的內(nèi)容:e80

16、da1b279f3b5f2e8cbc2dd324f56ddBRAS-PortalServer的Challenge請求響應(yīng)報(bào)文(ACK_CHALLENGE)：ver:2type:challengeackMethod:chapSerialNo:4ReqID:2UserIP:172.75.100.253ErrCode:0AttrNum:1報(bào)文的二進(jìn)制形式：TOC o 1-5 h z0202000000040002ac4b64fd000000014e1ff4eb215750bc1d4aa4e48b2576110312bb0bcd57415d3db7b7cd5b393fc129e3其中Challenge

17、為：bb0bcd57415d3db7b7cd5b393fc129e3PortalServer-BRAS認(rèn)證請求報(bào)文(REQ_AUTH)：ver:2type:authreqMethod:chapSerialNo:4ReqID:2UserIP:172.75.100.253ErrCode:0AttrNum:20203000000040203000000040002307bbaa5265df528041273cc876a01cab58b010e77656240報(bào)文的二進(jìn)制形式：ac4b64fd00000002e73394972c151b699ab398d7fcc8583664656661756c743

18、0Chap_Password的生成方法：Chap_Password的生成遵循標(biāo)準(zhǔn)的Radious協(xié)議中的Chap_Password生成方法(參見RFC2865)。密碼加密使用MD5算法，MD5函數(shù)的輸入為ChapIDPasswordChallenge其中，ChapID取ReqID的低8位，Password的長度不夠協(xié)議規(guī)定的最大長度，其后不需要補(bǔ)零。這里ReqID的低8位是：02,Password為：313233343536Challenge為：bb0bcd57415d3db7b7cd5b393fcl29e3合并后就是以02313233343536bb0bcd57415d3db7b7cd5b3

19、93fc129e3為md5輸入，輸出的就是Chap_Password：73cc876a01ca9ab398d7fcc85836b58bBRAS-PortalServer認(rèn)證成功報(bào)文(ACK_AUTH):ver:2type:authackMethod:chapSerialNo:4ReqID:2UserIP:172.75.100.253ErrCode:0AttrNum:00204000000040002ac4b64fd00000000a2f6120897fc143d29accfb5582e8b89PortalServer-BRAS認(rèn)證成功響應(yīng)報(bào)文(AFF_ACK_AUTH)：ver:2type:authackaffMethod:chapSerialNo:4ReqID:2UserIP:172.75.100.253ErrCode:0AttrNum:00207000000040002ac4b64fd00000000ec6ebcde70324554e44d421eca0653697.2成功的Pap認(rèn)證報(bào)文示例示例中使用的用戶名為：webd