封裝：一種封裝多協(xié)議數(shù)據(jù)報的方法。PPP 封裝提供了不同網(wǎng)絡(luò)層協(xié)議同時在同一鏈路傳輸?shù)亩嗦窂?fù)用技術(shù)。PPP 封裝精心設(shè)計，能保持對大多數(shù)常用硬件的兼容性。

　　鏈路控制協(xié)議：PPP 提供的 LCP 功能全面，適用于大多數(shù)環(huán)境。LCP 用于就封裝格式選項自動達(dá)成一致，處理數(shù)據(jù)包大小限制，探測環(huán)路鏈路和其他普通的配置錯誤，以及終止鏈路。LCP 提供的其他可選功能有：認(rèn)證鏈路中對等單元的身份，決定鏈路功能正�；蜴溌肥�敗情況。

　　網(wǎng)絡(luò)控制協(xié)議：一種擴(kuò)展鏈路控制協(xié)議，用于建立、配置、測試和管理數(shù)據(jù)鏈路連接。

　　配置：使用鏈路控制協(xié)議的簡單和自制機制。該機制也應(yīng)用于其它控制協(xié)議，例如：網(wǎng)絡(luò)控制協(xié)議（NCP）。

　　為了建立點對點鏈路通信，PPP 鏈路的每一端，必須首先發(fā)送 LCP 包以便設(shè)定和測試數(shù)據(jù)鏈路。在鏈路建立，LCP 所需的可選功能被選定之后，PPP 必須發(fā)送 NCP 包以便選擇和設(shè)定一個或更多的網(wǎng)絡(luò)層協(xié)議。一旦每個被選擇的網(wǎng)絡(luò)層協(xié)議都被設(shè)定好了，來自每個網(wǎng)絡(luò)層協(xié)議的數(shù)據(jù)報就能在鏈路上發(fā)送了。

　　鏈路將保持通信設(shè)定不變，直到有 LCP 和 NCP 數(shù)據(jù)包關(guān)閉鏈路，或者是發(fā)生一些外部事件的時候（如，休止?fàn)顟B(tài)的定時器期滿或者網(wǎng)絡(luò)管理員干涉）。

　　PPP的兩種認(rèn)證方式是PAP和CHAP。相對來說PAP的認(rèn)證方式安全性沒有CHAP高。PAP在傳輸password是明文的，而CHAP在傳輸過程中不傳輸密碼，取代密碼的是hash（哈希值）。PAP認(rèn)證是通過兩次握手實現(xiàn)的，而CHAP則是通過3次握手實現(xiàn)的。PAP認(rèn)證是被叫提出連接請求，主叫響應(yīng)。而CHAP則是主叫發(fā)出請求，被叫回復(fù)一個數(shù)據(jù)包，這個包里面有主叫發(fā)送的隨機的哈希值，主叫在數(shù)據(jù)庫中確認(rèn)無誤后發(fā)送一個連接成功的數(shù)據(jù)包連接。

　　PPP是一種多協(xié)議成幀機制，它適合于調(diào)制解調(diào)器、HDLC位序列線路、SONET和其它的物理層上使用。它支持錯誤檢測、選項協(xié)商、頭部壓縮以及使用HDLC類型幀格式（可選）的可靠傳輸。

　　階段1：創(chuàng)建PPP鏈路

　　LCP負(fù)責(zé)創(chuàng)建鏈路。在這個階段，將對基本的通訊方式進(jìn)行選擇。鏈路兩端設(shè)備通過LCP向?qū)Ψ桨l(fā)送配置信息報文（Configure Packets）。一旦一個配置成功信息包（Configure-Ack packet）被發(fā)送且被接收，就完成了交換，進(jìn)入了LCP開啟狀態(tài)。應(yīng)當(dāng)注意，在鏈路創(chuàng)建階段，只是對驗證協(xié)議進(jìn)行選擇，用戶驗證將在第2階段實現(xiàn)。

　　階段2：用戶驗證

　　在這個階段，客戶端會將自己的身份發(fā)送給遠(yuǎn)端的接收頭。該階段使用一種安全驗證方式避免第三方竊取數(shù)據(jù)或冒充遠(yuǎn)程客戶接管與客戶端的連接。在認(rèn)證完成之前，禁止從認(rèn)證階段前進(jìn)到網(wǎng)絡(luò)層協(xié)議階段。如果認(rèn)證失敗，認(rèn)證者應(yīng)該躍遷到鏈路終止階段。在這一階段里，只有鏈路控制協(xié)議、認(rèn)證協(xié)議，和鏈路質(zhì)量監(jiān)視協(xié)議的packets是被允許的。在該階段里接收到的其他的packets必須被靜靜的丟棄。最常用的認(rèn)證協(xié)議有口令驗證協(xié)議（PAP）和挑戰(zhàn)握手驗證協(xié)議（CHAP）。 認(rèn)證方式介紹在第三部分中介紹。

　　階段3：調(diào)用網(wǎng)絡(luò)層協(xié)議

　　認(rèn)證階段完成之后，PPP將調(diào)用在鏈路創(chuàng)建階段（階段1）選定的各種網(wǎng)絡(luò)控制協(xié)議（NCP）。選定的NCP解決PPP鏈路之上的高層協(xié)議問題，例如，在該階段IP控制協(xié)議（IPCP）可以向撥入用戶分配動態(tài)地址。

　　這樣，經(jīng)過三個階段以后，一條完整的PPP鏈路就建立起來了。

　　安全問題是此備忘錄的主要話題。PPP中的驗證協(xié)議的交互操作很大程度上依靠于實現(xiàn)者。在文檔中通篇使用SHOULD表明了這點。例如，一旦驗證失敗，有些實現(xiàn)者并不終止鏈路。相反，實現(xiàn)者限制網(wǎng)絡(luò)層的通信量的類型構(gòu)造子網(wǎng)，這樣反過來允許用戶有機會更新秘密或者發(fā)郵件給網(wǎng)絡(luò)管理員說明問題。對于驗證失敗沒有重試機制。然而，LCP狀態(tài)機可以在任何時候重新磋商驗證協(xié)議，這樣就允許了一個新的重試。建議任何用來為驗證失敗的計數(shù)器在成功驗證前或者終止失敗的鏈路前不要重置。

　　不要求驗證是雙向的或者在兩個方向使用相同的協(xié)議。在任一個方向上使用不同的協(xié)議是完全可以接受的。當(dāng)然，這依靠于在磋商時指定的協(xié)議。在實踐中，在每個PPP服務(wù)器上有一個數(shù)據(jù)庫，它聯(lián)合驗證信息的用戶名字。不期望使

　　用多個方法驗證特殊的命名用戶。這樣使用戶容易受到攻擊。作為代替的，對于每一個命名用戶有一個準(zhǔn)確的方法用來驗證用戶名。如果一個用戶在不同的環(huán)境下需要使用不同的驗證方法，那么應(yīng)該采用截然不同的用戶名，每一個準(zhǔn)確代表一個驗證方法。密碼和其他的秘密應(yīng)該保存在各自的端點以至于對它們的訪問盡可能的受到限制。理想的，只能是為了完成驗證而需要訪問的過程可以訪問秘密。

　　應(yīng)該使用一種機制分發(fā)秘密，這種機制能夠限制處理秘密實體的數(shù)目。理想的，沒有通過驗證的人不會再得到秘密的內(nèi)容。使用SNMP安全協(xié)議可以實現(xiàn)這個目標(biāo)，但是這樣的機制不在這個規(guī)范的范圍內(nèi)。目前正在研究和試驗其他的分發(fā)機制。SNMP安全文檔很好的概括了對網(wǎng)絡(luò)的威脅。

更多精彩內(nèi)容，請登入維庫電子通http://www.06jpkg.cn