【正文】 在寬帶接入服務(wù)器上，AAA對(duì)PPP用戶的地址分配原則如下：l 對(duì)于不認(rèn)證的用戶：? 如果接口下配置為對(duì)端分配IP地址，直接把該地址分配給對(duì)端。當(dāng)域和域下的用戶同時(shí)配置了某一屬性時(shí)，基于用戶的配置優(yōu)先級(jí)高于域的配置優(yōu)先級(jí)。所有對(duì)于接入用戶的認(rèn)證、授權(quán)、計(jì)費(fèi)都是在域視圖下應(yīng)用認(rèn)證方案、授權(quán)方案、計(jì)費(fèi)方案來(lái)實(shí)現(xiàn)的，在AAA視圖下分別預(yù)先配置相應(yīng)的認(rèn)證模式、授權(quán)模式、計(jì)費(fèi)模式。在目前AAA的實(shí)現(xiàn)中，所有用戶都屬于某個(gè)域。l 擴(kuò)展的RADIUS+。計(jì)費(fèi)的消息流程和認(rèn)證/授權(quán)的消息流程類(lèi)似。、計(jì)費(fèi)的流程RADIUS通過(guò)建立一個(gè)唯一的用戶數(shù)據(jù)庫(kù)，存儲(chǔ)用戶名、密碼來(lái)對(duì)用戶進(jìn)行驗(yàn)證。l Identifier：一般是順序遞增的數(shù)字，用于匹配請(qǐng)求包和回應(yīng)包。RADIUS服務(wù)器負(fù)責(zé)接收用戶的連接請(qǐng)求，完成認(rèn)證，并把用戶所需的配置信息返回給NAS。RADIUS最初用來(lái)管理使用串口和調(diào)制解調(diào)器的大量分散用戶，后來(lái)廣泛應(yīng)用于網(wǎng)絡(luò)接入服務(wù)器NAS（Network Access Server）系統(tǒng)。l 遠(yuǎn)端計(jì)費(fèi)：支持通過(guò)RADIUS服務(wù)器或HWTACACS服務(wù)器進(jìn)行遠(yuǎn)端計(jì)費(fèi)。l ifauthenticated授權(quán)：如果用戶通過(guò)了認(rèn)證，而且使用的認(rèn)證模式不是不認(rèn)證，則用戶授權(quán)通過(guò)。AAA支持以下授權(quán)方式：l 不授權(quán)：不對(duì)用戶進(jìn)行授權(quán)處理。本地認(rèn)證的優(yōu)點(diǎn)是速度快，可以為運(yùn)營(yíng)降低成本；缺點(diǎn)是存儲(chǔ)信息量受設(shè)備硬件條件限制。這種結(jié)構(gòu)既具有良好的可擴(kuò)展性，又便于用戶信息的集中管理。具體如下：l 認(rèn)證（Authentication）：驗(yàn)證用戶是否可以獲得訪問(wèn)權(quán)，確定哪些用戶可以訪問(wèn)網(wǎng)絡(luò)。l 支持的用戶數(shù)量較多，同時(shí)用戶的請(qǐng)求能夠得到實(shí)時(shí)的響應(yīng)。一個(gè)域中的所有用戶都具有類(lèi)似的屬性。其次，路由器需要對(duì)接入的用戶進(jìn)行控制，防止非法訪問(wèn)。? 如何上線的用戶進(jìn)行準(zhǔn)確的計(jì)費(fèi)，l 解決方案可以使用AAA解決以上問(wèn)題。第五章 AAA及用戶管理 AAA簡(jiǎn)介 AAA的引入l 在用戶接入網(wǎng)絡(luò)的時(shí)候，運(yùn)營(yíng)商就不得不面臨以下的問(wèn)題。而且通過(guò)PPP協(xié)議本身所具有的一些特點(diǎn)，能實(shí)現(xiàn)在廣播式網(wǎng)絡(luò)上對(duì)用戶進(jìn)行計(jì)費(fèi)和管理。PPPoE組網(wǎng)圖在這種網(wǎng)絡(luò)模型中，PPPoE可用于同一個(gè)以太網(wǎng)上的多個(gè)主機(jī)通過(guò)一個(gè)或多個(gè)橋接的調(diào)制解調(diào)器向多個(gè)目的主機(jī)開(kāi)放其PPP會(huì)話。在重發(fā)指定次數(shù)后如果還沒(méi)有收到PADS報(bào)文，主機(jī)應(yīng)該重新發(fā)送PADI。推薦使用前一種方案。雖然ACCookie對(duì)防止某些DOS有用，但它不能防止所有的DOS攻擊，接入服務(wù)器可以使用其它的方法來(lái)保護(hù)。為了防止拒絕服務(wù)DOS（Denial of Service）攻擊，接入服務(wù)器可以使用類(lèi)型為ACCookie的Tag。推薦接入服務(wù)器不時(shí)地向主機(jī)發(fā)送回聲請(qǐng)求（EchoRequest）數(shù)據(jù)包，以確定會(huì)話的狀態(tài)。從主機(jī)發(fā)送到接入服務(wù)器的PPP LCP數(shù)據(jù)包示例圖進(jìn)入PPP Session階段后，在會(huì)話階段，主機(jī)或服務(wù)器任何一方都可發(fā)PADT報(bào)文通知對(duì)方結(jié)束PPP會(huì)話。l Ethernet_Type域設(shè)置為0x8864。PPP通信雙方應(yīng)該使用PPP協(xié)議自身來(lái)結(jié)束PPPoE會(huì)話，但在無(wú)法使用PPP時(shí)可以使用PADT。 PADT數(shù)據(jù)包PADT（PPPoE Active Discovery Terminate）數(shù)據(jù)包可以在會(huì)話建立以后的任意時(shí)刻發(fā)送，表明PPPoE會(huì)話已經(jīng)終止。Destination_address域是發(fā)送PADR數(shù)據(jù)包的主機(jī)的單播以太網(wǎng)地址，Code域設(shè)置為0x65,Session_ID必須設(shè)置為所創(chuàng)建好的PPPoE會(huì)話標(biāo)識(shí)符。其中，Destination_address域設(shè)置為發(fā)送PADO的接入服務(wù)器的單播地址，Code域設(shè)置為0x19，Session_ID必須設(shè)置為0x0000。 PADR數(shù)據(jù)包由于PADI是廣播的，主機(jī)可能收到不止一個(gè)PADO。Destination_address是發(fā)送PADI報(bào)文的主機(jī)的單播地址，Code域?yàn)?x07，Session_ID域必須設(shè)置為0x0000。 PADI數(shù)據(jù)包主機(jī)發(fā)送Destination_address為廣播地址的PADI數(shù)據(jù)包，Code域設(shè)置為0x09，Session_ID域必須設(shè)置為0x0000。l Tag_Length域的長(zhǎng)度是16比特，是一個(gè)網(wǎng)絡(luò)字節(jié)序的無(wú)符號(hào)值，表明Tag_Value的字節(jié)數(shù)。0x0203GenericError該Tag表明發(fā)生了一個(gè)錯(cuò)誤。例如沒(méi)有足夠資源來(lái)創(chuàng)建一個(gè)虛擬電路。它表明了由于某種原因，沒(méi)有理睬所請(qǐng)求的ServiceName。如果Discovery數(shù)據(jù)包中已經(jīng)包含一個(gè)RelaySessionId標(biāo)簽，則不允許再加入該標(biāo)簽。0x0110RelaySessionId該Tag可由中繼流量的中間代理加入到Discovery數(shù)據(jù)包中。Tag_Value的前4個(gè)字節(jié)包含了廠商的識(shí)別碼，其余字節(jié)尚未定義。接入服務(wù)器可以在PADO數(shù)據(jù)包中包含該Tag。它不能由接入服務(wù)器解釋。它可以是商標(biāo)、型號(hào)以及序列號(hào)等信息的集合，或者該接入服務(wù)器MAC地址的一個(gè)簡(jiǎn)單表示。l Tag_Value是不以NULL結(jié)束的字符串。Tag_ValueTag_Type含義0x0000EndOfList該Tag值表明表中是最后一個(gè)Tag。PPPoE的Payload部分包含0個(gè)或多個(gè)Tag。例如在圖中，ServerA收到PADR報(bào)文后，會(huì)向主機(jī)發(fā)送PADS報(bào)文。服務(wù)器發(fā)回PADO報(bào)文主機(jī)可能收到多個(gè)服務(wù)器的PADO報(bào)文，主機(jī)將依據(jù)PADO的內(nèi)容，從多個(gè)服務(wù)器中選擇一個(gè)，并向它發(fā)回一個(gè)會(huì)話請(qǐng)求報(bào)文PADR（PPPoE Active Discovery Request）。l 以上是兩者的servicename都不為空時(shí)的情況。Discovery階段的四個(gè)步驟包括：主機(jī)在本以太網(wǎng)內(nèi)廣播一個(gè)PADI（PPPoE Active Discovery Initial）報(bào)文，在此報(bào)文中包含主機(jī)想要得到的服務(wù)類(lèi)型信息。 Discovery階段當(dāng)主機(jī)開(kāi)始PPPoE進(jìn)程時(shí)，它必須先識(shí)別接入端的以太網(wǎng)MAC地址，建立PPPoE的Session_ID。? Length域的長(zhǎng)度是16比特。? Session_ID域的長(zhǎng)度是16比特，是一個(gè)網(wǎng)絡(luò)字節(jié)序的無(wú)符號(hào)值。l Ethernet_Type設(shè)置為0x8863表示Discovery階段，0x8864表示PPP會(huì)話階段。凈載負(fù)荷Payload的定義各域的含義如下：l Destination_address域是一個(gè)以太網(wǎng)單播目的地址或者以太網(wǎng)廣播地址（0xFFFFFFFF)。Discovery階段一直保持無(wú)狀態(tài)（stateless），直到建立起一個(gè)PPP會(huì)話。在Discovery的過(guò)程中，主機(jī)作為客戶端，發(fā)現(xiàn)某個(gè)作為服務(wù)器的接入訪問(wèn)集中器AC（Access Concentrator）。PPPoE包含一個(gè)發(fā)現(xiàn)協(xié)議來(lái)提供這個(gè)功能。這些功能要求在通信雙方之間存在點(diǎn)到點(diǎn)的關(guān)系，而不是在以太網(wǎng)和其他多訪問(wèn)環(huán)境中所出現(xiàn)的多點(diǎn)關(guān)系。PPP應(yīng)用雖然很廣泛，但是不能用于以太網(wǎng)，因此提出了PPPoE技術(shù)。第四章 PPPoE PPPoE簡(jiǎn)介 PPPoE的引入當(dāng)客戶接入到服務(wù)器時(shí)，客戶希望接入的成本低，而且希望在接入時(shí)不要或者很少改變配置。l PPP頭壓縮：只壓縮PPP報(bào)文頭部分。Length2表示該報(bào)文的總長(zhǎng)度。并且應(yīng)該終止鏈路連接?；貞?yīng)報(bào)文中此域是挑戰(zhàn)報(bào)文字節(jié)流經(jīng)過(guò)一次哈希算法后得到的值。字段長(zhǎng)度（字節(jié)）含義Code1l 1表示是Challenge報(bào)文l 2表示是回應(yīng)報(bào)文Identifier1它標(biāo)識(shí)挑戰(zhàn)報(bào)文和回應(yīng)報(bào)文的對(duì)應(yīng)關(guān)系。只要接收到回應(yīng)報(bào)文，驗(yàn)證方就會(huì)把自己計(jì)算的值和返回值進(jìn)行比較。其他附加挑戰(zhàn)報(bào)文必須在收到有效的回應(yīng)報(bào)文或計(jì)數(shù)器滿后才可以發(fā)送。超出該長(zhǎng)度值的字節(jié)應(yīng)該被認(rèn)為是數(shù)據(jù)鏈路層的填充字節(jié)，在接收時(shí)應(yīng)該被忽略。各字段含義如下表所示。Algorithm1表示使用的一次哈希方法。具體值含義請(qǐng)參見(jiàn)常用協(xié)商類(lèi)型值。其他過(guò)程和驗(yàn)證方配置了用戶名時(shí)相同。根據(jù)查找到的口令和質(zhì)詢報(bào)文，通過(guò)MD5算法進(jìn)行計(jì)算得出一個(gè)數(shù)值，并將計(jì)算得出的數(shù)值和自己的主機(jī)名發(fā)回驗(yàn)證方（Response）。CHAP單向驗(yàn)證過(guò)程分為兩種情況：驗(yàn)證方配置了用戶名和驗(yàn)證方?jīng)]有配置用戶名。CHAP的驗(yàn)證過(guò)程如下圖所示。被驗(yàn)證方經(jīng)過(guò)一次哈希算法后，給驗(yàn)證方返回一個(gè)值。它只在網(wǎng)絡(luò)上傳輸用戶名，而并不傳輸用戶密碼，因此安全性要比PAP高。Length2表示該報(bào)文的總長(zhǎng)度。字段長(zhǎng)度（字節(jié)）含義Code10x02表示AuthenticateAck報(bào)文，0x03表示AuthenticateNak報(bào)文。l AuthenticateAck和AuthenticateNak報(bào)文幀格式如果在驗(yàn)證請(qǐng)求報(bào)文中的用戶名和密碼都能被驗(yàn)證方驗(yàn)證通過(guò)，驗(yàn)證方必須返回Code值是2的AuthenticateAck報(bào)文，表示驗(yàn)證通過(guò)。PeerID Length1標(biāo)識(shí)PeerID域的長(zhǎng)度。具體的code值含義請(qǐng)參見(jiàn)Error! Reference source not found.。當(dāng)收到驗(yàn)證請(qǐng)求報(bào)文后，必須根據(jù)實(shí)際情況回復(fù)不同的應(yīng)答報(bào)文。l Authenticate_Request報(bào)文驗(yàn)證請(qǐng)求報(bào)文用于表示PAP驗(yàn)證的開(kāi)始。l 1表示是AuthenticateRequest報(bào)文l 2表示是AuthenticateAck報(bào)文l 3表示是AuthenticateNak報(bào)文Identifier1標(biāo)識(shí)請(qǐng)求報(bào)文和應(yīng)答報(bào)文的匹配。一個(gè)PAP數(shù)據(jù)報(bào)是封裝在協(xié)議域?yàn)镃023的PPP數(shù)據(jù)鏈路層幀的信息域中的。Length1此時(shí)固定值是4，表示這個(gè)配置參數(shù)選項(xiàng)幀格式總長(zhǎng)度是4個(gè)字節(jié)。協(xié)商PAP驗(yàn)證協(xié)議的配置參數(shù)選項(xiàng)幀格式如下圖所示。l 被驗(yàn)證方發(fā)送本端用戶名和口令到驗(yàn)證方。驗(yàn)證過(guò)程僅在鏈路初始建立階段進(jìn)行。當(dāng)載波丟失、認(rèn)證失敗、鏈路質(zhì)量檢測(cè)失敗和管理員人為關(guān)閉鏈路等情況均會(huì)導(dǎo)致鏈路終止。網(wǎng)絡(luò)層協(xié)議階段（Network）一旦PPP完成了前面幾個(gè)階段，每種網(wǎng)絡(luò)層協(xié)議（IP、IPX和AppleTalk）會(huì)通過(guò)各自相應(yīng)的網(wǎng)絡(luò)控制協(xié)議進(jìn)行配置，每個(gè)NCP協(xié)議可在任何時(shí)間打開(kāi)和關(guān)閉。l PAP：Password Authentication Protocol，密碼驗(yàn)證協(xié)議l CHAP：ChallengeHandshake Authentication Protocol，挑戰(zhàn)握手協(xié)議驗(yàn)證方式的選擇是依據(jù)在鏈路建立階段雙方進(jìn)行協(xié)商的結(jié)果。如果要求驗(yàn)證，在鏈路建立階段必須指定驗(yàn)證協(xié)議。同理可知，另一端也是一樣的，但須注意的是在鏈路配置階段雙方的鏈路配置操作過(guò)程是相互獨(dú)立的。當(dāng)檢測(cè)到鏈路可用時(shí)，則物理層會(huì)向鏈路層發(fā)送一個(gè)Up事件。下一階段的選擇是依據(jù)鏈路兩端的設(shè)備配置的。鏈路建立階段（Establish）它是PPP協(xié)議最關(guān)鍵和最復(fù)雜的階段。在鏈路建立階段主要是通過(guò)LCP協(xié)議進(jìn)行鏈路參數(shù)的配置，LCP在此階段的狀態(tài)機(jī)也會(huì)根據(jù)不同的事件發(fā)生變化。l PPP鏈路將一直保持通信，直至有明確的LCP或NCP幀關(guān)閉這條鏈路，或發(fā)生了某些外部事件，例如用戶干預(yù)。l NCP協(xié)商支持IPCP、MPLSCP、OSCICP等協(xié)商。l 如果配置了驗(yàn)證，將進(jìn)入Authenticate階段，開(kāi)始CHAP或PAP驗(yàn)證。l 開(kāi)始建立PPP鏈路時(shí)，先進(jìn)入到Establish階段。直至所經(jīng)歷的幾個(gè)配置過(guò)程全部完成后，點(diǎn)對(duì)點(diǎn)的雙方就可以開(kāi)始通過(guò)已建立好的鏈路進(jìn)行網(wǎng)絡(luò)層數(shù)據(jù)報(bào)文的傳送了，整個(gè)鏈路就處于可用狀態(tài)。l NCP主要用于協(xié)商在該數(shù)據(jù)鏈路上所傳輸?shù)臄?shù)據(jù)包的格式與類(lèi)型，如IP地址。常見(jiàn)的協(xié)議代碼協(xié)議代碼協(xié)議類(lèi)型0021Internet Protocol002bNovell IPX002dVan Jacobson Compressed TCP/IP002fVan Jacobson Unpressed TCP/IP8021Internet Protocol Control Protocol802bNovell IPX Control Protocol8031Bridging NCC021Link Control ProtocolC023Password Authentication ProtocolC223Challenge Handshake Authentication Protocol常用code值code值報(bào)文類(lèi)型0x01ConfigureRequest0x02ConfigureAck0x03ConfigureNak0x04ConfigureReject0x05TerminateRequest0x06TerminateAck0x07CodeReject0x08ProtocolReject0x09EchoRequest0x0AEchoReply0x0BDiscardRequest0x0CReserved常用協(xié)商類(lèi)型值協(xié)商類(lèi)型值協(xié)商報(bào)文類(lèi)型0x01MaximumReceiveUnit0x02AsyncControlCharacterMap0x03AuthenticationProtocol0x04QualityProtocol0x05MagicNumber0x06RESERVED0x07ProtocolFieldCompression0x08AddressandControlFieldCompression MP簡(jiǎn)介MP是出于增加帶寬的考慮，將多個(gè)PPP鏈路