【正文】 Report鏈路品質(zhì)報(bào)告 c223 挑戰(zhàn) 認(rèn)證握手協(xié)議 新的協(xié)議的開發(fā)者必須從 the Inter Assigned Numbers Authority (IANA), 。 64 信息字段 ? 信息字段是 0或更多的字節(jié)。對(duì)于在協(xié)議字段里指定的協(xié)議，信息字段包含數(shù)據(jù)報(bào)。信息字段的最大長(zhǎng)度，包含填料但不包含協(xié)議字段，術(shù)語(yǔ)叫做 最大接收單元（ MRU），默認(rèn)值是 1500字節(jié)。若經(jīng)過協(xié)商同意，也可以使用其它的值作為 MRU。 65 PPP的工作過程可通過 PPP狀態(tài)圖來描述： 建 立 鑒 別通 信終 止網(wǎng) 絡(luò)靜 止協(xié) 商 選 項(xiàng)鑒 別 成 功N C P 配 置通 信 結(jié) 束失 敗載 波 停 止失 敗檢 測(cè) 到 載 波66 （ 1） Dead: 連接靜止階段（物理層未準(zhǔn)備好） ? 一個(gè)連接的開始和結(jié)束都要經(jīng)歷此階段。當(dāng)一個(gè)外部事件（例如檢測(cè)到載波或網(wǎng)絡(luò)管理人員配置）指示物理層已準(zhǔn)備好并可以使用時(shí)，ＰＰＰ將進(jìn)入建立連接階段。 在此階段，ＬＣＰ協(xié)議自動(dòng)機(jī)（后面將提到）處在初始或正在開始狀態(tài)。當(dāng)進(jìn)入到建立連接階段后會(huì)引發(fā)ＵＰ事件通知ＬＣＰ協(xié)議自動(dòng)機(jī)。 67 （ 2） 建立連接階段 ? LCP負(fù)責(zé)創(chuàng)建鏈路。在這個(gè)階段，將對(duì)基本的通訊方式進(jìn)行選擇。鏈路兩端設(shè)備通過 LCP向?qū)Ψ桨l(fā)送配置信息報(bào)文（ Configure Packets）。一旦一個(gè)配置成功信息包（ ConfigureAck packet）被發(fā)送且被接收，就完成了交換，進(jìn)入了 LCP開啟狀態(tài)。 所有的配置選項(xiàng)都被假定為缺省值，除非在配置交互的過程中改變。 68 （ 3）認(rèn)證階段 (鑒別階段 ) ? 在某些連接時(shí)，在允許網(wǎng)絡(luò)層協(xié)議數(shù)據(jù)包交換之前希望對(duì)對(duì)等實(shí)體進(jìn)行認(rèn)證。 缺省時(shí)，認(rèn)證不是必要的。如果應(yīng)用時(shí)希望對(duì)等實(shí)體使用某些認(rèn)證協(xié)議進(jìn)行認(rèn)證，這種要求必須在建立連接階段提出。 ? 認(rèn)證階段應(yīng)該緊接在建立連接階段后。然而，可能有連接質(zhì)量的決定并行出現(xiàn)。應(yīng)用時(shí)絕對(duì)不允許連接質(zhì)量決定數(shù)據(jù)包的交換使認(rèn)證有不確定的延遲。認(rèn)證階段后的網(wǎng)絡(luò)層協(xié)議階段必須等到認(rèn)證結(jié) 69 （ 4） 網(wǎng)絡(luò)層協(xié)議階段 ? 一旦ＰＰＰ完成了上述階段，每一個(gè)網(wǎng)絡(luò)層協(xié)議必須單獨(dú)的由相應(yīng)的網(wǎng)絡(luò)控制協(xié)議（ＮＣＰ）配置。 每一個(gè)網(wǎng)絡(luò)控制協(xié)議可以隨時(shí)打開或關(guān)閉。 ? 認(rèn)證階段完成之后， PPP將調(diào)用在鏈路創(chuàng)建階段（階段 1）選定的各種網(wǎng)絡(luò)控制協(xié)議（ NCP） ,例如ＩＰ、ＩＰＸ。選定的 NCP解決 PPP鏈路之上的高層協(xié)議問題，例如，在該階段 IP控制協(xié)議（ IPCP）可以向撥入用戶分配動(dòng)態(tài)地址。 70 （ 5） 終止連接階段 ? PＰＰ連接可以隨時(shí)終止。原因可能是載波丟失、認(rèn)證失敗、連接質(zhì)量失敗、超時(shí)計(jì)數(shù)器溢出，或者網(wǎng)絡(luò)管理員關(guān)閉連接。 ＬＣＰ通過交換連接終止包來終止連接。當(dāng)連接正在被終止的時(shí)候，ＰＰＰ會(huì)通知網(wǎng)絡(luò)層以便它采取相應(yīng)的動(dòng)作。 71 認(rèn)證方式 （ 1）口令驗(yàn)證協(xié)議（ PAP） ? PAP是一種簡(jiǎn)單的明文驗(yàn)證方式。NAS（網(wǎng)絡(luò)接入服務(wù)器， Network Access Server）要求用戶提供用戶名和口令， PAP以明文方式返回用戶信息。很明顯，這種驗(yàn)證方式的安全性較差，第三方可以很容易的獲取被傳送的用戶名和口令，并利用這些信息與 NAS建立連接獲取 NAS提供的所有資源。所以，一旦用戶密碼被第三方竊取， PAP無法提供避免受到第三方攻擊的保障措施。 72 （ 2）挑戰(zhàn) 握手驗(yàn)證協(xié)議（ CHAP） ? NAS向遠(yuǎn)程用戶發(fā)送一個(gè)挑戰(zhàn)口令（ challenge），其中包括會(huì)話 ID和一個(gè)任意生成的挑戰(zhàn)字串（ arbitrary challenge string）。遠(yuǎn)程客戶必須使用 MD5單向哈希算法 （ oneway hashing algorithm）返回用戶名和加密的挑戰(zhàn)口令，會(huì)話 ID以及用戶口令，其中用戶名以非哈希方式發(fā)送。 73 PPP的優(yōu)點(diǎn) ? PPP協(xié)議是目前廣域網(wǎng)上應(yīng)用最廣泛的協(xié)議之一，它的優(yōu)點(diǎn)在于簡(jiǎn)單、具備用戶驗(yàn)證能力、可以解決 IP分配等。 74 ? 當(dāng) PPP用在同步傳輸鏈路時(shí)，協(xié)議規(guī)定 采用硬件來完成比特填充 (和 HDLC的做法一樣 )。但當(dāng) PPP用在異步傳輸時(shí)，它就使用一種 特殊的字符填充法 (當(dāng) 0x7d出現(xiàn)在 PPP數(shù)據(jù)幀中時(shí)，那么緊接著的字符的第 6個(gè)比特要取其補(bǔ)碼 ,詳見下頁(yè) ) ? PPP不提供 可靠傳輸?shù)姆?wù) 。 75 1) 當(dāng)遇到字符 0x7e時(shí)，需連續(xù)傳送兩個(gè)字符：0x7d和 0x5e 2) 當(dāng)遇到轉(zhuǎn)義字符 0x7d時(shí)，需連續(xù)傳送兩個(gè)字符： 0x7d和 0x5d 默認(rèn)情況下，如果字符的值小于 0x20，一般都要進(jìn)行轉(zhuǎn)義。例如，遇到字符 0x01時(shí)需連續(xù)傳送 0x7d和 0x21兩個(gè)字符（這時(shí)，第 6個(gè)比特取補(bǔ)碼后變?yōu)?1，而前面兩種情況均把它變?yōu)?0）。 這樣做的原因是防止它們出現(xiàn)在雙方主機(jī)的串行接口驅(qū)動(dòng)程序或調(diào)制解調(diào)器中，因?yàn)橛袝r(shí)它們會(huì)把這些控制字符解釋成特殊的含義。另一種可能是用鏈路控制協(xié)議來指定是否需要對(duì)這 32個(gè)字符中的某一些值進(jìn)行轉(zhuǎn)義。默認(rèn)情況下是對(duì)所有的 32個(gè)字符都進(jìn)行轉(zhuǎn)義 。 特殊的字符填充法 76 PPP協(xié)議之所以不使用序號(hào)和確認(rèn)機(jī)制是出于以下的幾點(diǎn)考慮： \（ 1） 若使用可靠的數(shù)據(jù)鏈路層協(xié)議 (如HDLC)， 開銷就要增大 。 （ 2） 在因特網(wǎng)環(huán)境下 ， PPP的信息字段放入的數(shù)據(jù)是 IP數(shù)據(jù)報(bào) 。 數(shù)據(jù)鏈路層的可靠傳輸并不能夠保證網(wǎng)絡(luò)層的傳輸也是可靠的 。 （ 3） PPP協(xié)議在幀格式中有幀檢驗(yàn)序列FCS字段 。 77 PPP協(xié)議的實(shí)現(xiàn) ? 在同步傳輸鏈路時(shí)， 采用硬件 實(shí)現(xiàn) ? 在異步傳輸時(shí) ,采用軟件實(shí)現(xiàn) ? 在系統(tǒng)中設(shè)置 78 PPP協(xié)議的應(yīng)用 ? 家庭撥號(hào)上網(wǎng)就是通過 PPP在用戶端和運(yùn)營(yíng)商的接入服務(wù)器之間建立通信鏈路。 ? PPP與其他的協(xié)議共同派生出了符合寬帶接入要求的新的協(xié)議，如 PPPoE（ PPP over Ether）， PPPoA（ PPP over ATM）。 ? 網(wǎng)絡(luò)互連 79 習(xí)題 P59 習(xí)題二 1 2