在廣闊的網(wǎng)絡(luò)空間中，各種協(xié)議的使用，支撐了它的強大應(yīng)用。那么在這之中，我們應(yīng)該對點對點PPP協(xié)議有所掌握。因為第2層隧道協(xié)議在很大程度上依靠PPP協(xié)議的各種特性，因此有必要對PPP協(xié)議進行深入的探討。PPP協(xié)議主要是設(shè)計用來通過撥號或?qū)＞€方式建立點對點連接發(fā)送數(shù)據(jù)。PPP協(xié)議將IP，IPX和NETBEUI包封裝在PP楨內(nèi)通過點對點的鏈路發(fā)送。PPP協(xié)議主要應(yīng)用于連接撥號用戶和NAS. PPP撥號會話過程可以分成4個不同的階段。分別如下：

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

點對點PPP協(xié)議使用鏈路控制協(xié)議（LCP）創(chuàng)建，維護或終止一次物理連接。在LCP階段的初期，將對基本的通訊方式進行選擇。應(yīng)當(dāng)注意在鏈路創(chuàng)建階段，只是對驗證協(xié)議進行選擇，用戶驗證將在第2階段實現(xiàn)。同樣，在LCP階段還將確定鏈路對等雙方是否要對使用數(shù)據(jù)壓縮或加密進行協(xié)商。實際對數(shù)據(jù)壓縮/加密算法和其它細節(jié)的選擇將在第4階段實現(xiàn)。

階段2：用戶驗證

在第2階段，客戶會PC將用戶的身份明發(fā)給遠端的接入服務(wù)器。該階段使用一種安全驗證方式避免第三方竊取數(shù)據(jù)或冒充遠程客戶接管與客戶端的連接。大多數(shù)的點對點PPP協(xié)議方案只提供了有限的驗證方式，包括口令驗證協(xié)議（PAP），挑戰(zhàn)握手驗證協(xié)議（CHAP）和微軟挑戰(zhàn)握手驗證協(xié)議（MSCHAP）。

1.口令驗證協(xié)議（PAP）

PAP是一種簡單的明文驗證方式。NAS要求用戶提供用戶名和口令，PAP以明文方式返回用戶信息。很明顯，這種驗證方式的安全性較差，第三方可以很容易的獲取被傳送的用戶名和口令，并利用這些信息與NAS建立連接獲取NAS提供的所有資源。所以，一旦用戶密碼被第三方竊取，PAP無法提供避免受到第三方攻擊的保障措施。

2.挑戰(zhàn)-握手驗證協(xié)議（CHAP）

CHAP是一種加密的驗證方式，能夠避免建立連接時傳送用戶的真實密碼。NAS向遠程用戶發(fā)送一個挑戰(zhàn)口令（challenge），其中包括會話ID 和一個任意生成的挑戰(zhàn)字串（arbitrary challengestring）。遠程客戶必須使用MD5單向哈希算法（one-wayhashingalgorithm）返回用戶名和加密的挑戰(zhàn)口令，會話ID以及用戶口令，其中用戶名以非哈希方式發(fā)送。

CHAP對PAP進行了改進，不再直接通過鏈路發(fā)送明文口令，而是使用挑戰(zhàn)口令以哈希算法對口令進行加密。因為服務(wù)器端存有客戶的明文口令，所以服務(wù)器可以重復(fù)客戶端進行的操作，并將結(jié)果與用戶返回的口令進行對照。CHAP為每一次驗證任意生成一個挑戰(zhàn)字串來防止受到再現(xiàn)攻擊（replay attack）。在整個連接過程中，CHAP將不定時的向客戶端重復(fù)發(fā)送挑戰(zhàn)口令，從而避免第3方冒充遠程客戶（remoteclient impersonation）進行攻擊。

3.微軟挑戰(zhàn)-握手驗證協(xié)議（MS-CHAP）

與CHAP相類似，MS-CHAP也是一種加密驗證機制。同CHAP一樣，使用MS-CHAP時，NAS會向遠程客戶發(fā)送一個含有會話ID和任意生成的挑戰(zhàn)字串的挑戰(zhàn)口令。遠程客戶必須返回用戶名以及經(jīng)過MD4哈希算法加密的挑戰(zhàn)字串，會話ID和用戶口令的MD4哈希值。采用這種方式服務(wù)器端將只存儲經(jīng)過哈希算法加密的用戶口令而不是明文口令，這樣就能夠提供進一步的安全保障。此外，MS-CHAP同樣支持附加的錯誤編碼，包括口令過期編碼以及允許用戶自己修改口令的加密的客戶-服務(wù)器（client-server）附加信息。使用MS-CHAP，客戶端和NAS雙方各自生成一個用于隨后數(shù)據(jù)加密的起始密鑰。MS-CHAP使用基于MPPE的數(shù)據(jù)加密，這一點非常重要，可以解釋為什么啟用基于MPPE的數(shù)據(jù)加密時必須進行MS-CHAP驗證。

在第2階段PPP鏈路配置階段，NAS收集驗證數(shù)據(jù)然后對照自己的數(shù)據(jù)庫或中央驗證數(shù)據(jù)庫服務(wù)器（位于NT主域控制器或遠程驗證用戶撥入服務(wù)器）驗證數(shù)據(jù)的有效性。

階段3：點對點PPP協(xié)議回叫控制（callbackcontrol）

微軟設(shè)計的PPP包括一個可選的回叫控制階段。該階段在完成驗證之后使用回叫控制協(xié)議（CBCP）如果配置使用回叫，那么在驗證之后遠程客戶和NAS 之間的連接將會被斷開。然后由NAS使用特定的電話號碼回叫遠程客戶。這樣可以進一步保證撥號網(wǎng)絡(luò)的安全性。NAS只支持對位于特定電話號碼處的遠程客戶進行回叫。

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

在以上各階段完成之后，PPP將調(diào)用在鏈路創(chuàng)建階段（階段1）選定的各種網(wǎng)絡(luò)控制協(xié)議（NCP）。例如，在該階段IP控制協(xié)議（IPCP）可以向撥入用戶分配動態(tài)地址。在微軟的PPP方案中，考慮到數(shù)據(jù)壓縮和數(shù)據(jù)加密實現(xiàn)過程相同，所以共同使用壓縮控制協(xié)議協(xié)商數(shù)據(jù)壓縮（使用MPPC）和數(shù)據(jù)加密（使用 MPPE）。

數(shù)據(jù)傳輸階段

一旦完成上述4階段的協(xié)商，點對點PPP協(xié)議就開始在連接對等雙方之間轉(zhuǎn)發(fā)數(shù)據(jù)。每個被傳送的數(shù)據(jù)報都被封裝在PPP包頭內(nèi)，該包頭將會在到達接收方之后被去除。如果在階段1選擇使用數(shù)據(jù)壓縮并且在階段4完成了協(xié)商，數(shù)據(jù)將會在被傳送之間進行壓縮。類似的，如果如果已經(jīng)選擇使用數(shù)據(jù)加密并完成了協(xié)商，數(shù)據(jù)（或被壓縮數(shù)據(jù)）將會在傳送之前進行加密。

點對點隧道協(xié)議（PPTP）

PPTP是一個第2層的協(xié)議，將PPP數(shù)據(jù)楨封裝在IP數(shù)據(jù)報內(nèi)通過IP網(wǎng)絡(luò)，如Internet傳送。PPTP還可用于專用局域網(wǎng)絡(luò)之間的連接。 RFC草案“點對點隧道協(xié)議”對PPTP協(xié)議進行了說明和介紹。該草案由PPTP論壇的成員公司，包括微軟，Ascend，3Com，和ECI等公司在 1996年6月提交至IETF.可在如下站點http://www.ietf.org http://www.ietf.org參看草案的在線拷貝。PPTP使用一個TCP連接對隧道進行維護，使用通用路由封裝（GRE）技術(shù)把數(shù)據(jù)封裝成點對點PPP協(xié)議的數(shù)據(jù)楨通過隧道傳送。可以對封裝PPP楨中的負載數(shù)據(jù)進行加密或壓縮。