PPP點對點協議分析
簡介
PPP(Point to Point Protocol)即點對點協議，為在點對點連線上傳輸多協議資料包提供了一個標準方法。設計目的主要是用來通過撥號或專線方式建立點對點連線傳送資料，使其成為各種主機、網橋和路由器之間簡單連線的一種共通的解決方案。PPP 最初設計是為兩個對等節點之間的 IP 流量傳輸提供一種封裝協議。在 TCP/IP 協議集中它是一種用來同步調製連線的資料鏈路層協議，替代了原來非標準的第二層協議SLIP。除了IP以外PPP還可以攜帶其它協議，包括DECnet和Novell的Internet網包交換(IPX)。
三個組成部分：
一個將IP資料報封裝到序列鏈路的方法。PPP既支援非同步鏈路(無奇偶檢驗的8位元資料),也支援面向位元的同步鏈路。IP資料報在PPP幀中就是其資訊部分。這個資訊部分的長度受最大傳送單元MTU的限制。
一個用來建立、配置和測試資料鏈路連線的鏈路控制協議LCP( Link Control Protoco )。通訊的雙方可協商一些選項。在RFC1661中定義了11種類型的LCP分組。
一套網路控制協議NCP( Network Control protocol ),其中的每一個協議支援不同的網路層協議,如IP、OSI的網路層、 Decnet ,以及 Appletalk 等。
功能：
(1)PPP具有動態分配IP地址的能力，允許在連線時刻協商IP地址；
(2)PPP支援多種網路協議，比如TCP/IP、NetBEUI、NWLINK等；
(3)PPP具有錯誤檢測以及糾錯能力，支援資料壓縮；
(4)PPP具有身份驗證功能。
(5)PPP可以用於多種型別的物理介質上，包括串列埠線、電話線、行動電話和光纖（例如SDH），PPP也用於Internet接入。
基本幀封包格式及各欄位分析
封包格式：
欄位解析：
標誌：佔16位，幀開始標誌
地址：佔8位，在HDLC中,地址欄位用於指定哪個站正在處理,但是由於PPP只關心一個目的地,這個欄位總是被設定為0xFF (所有站)
控制：
協議：佔8或16位，表明攜帶的資料型別。根據 HDLC規範,協議號的分配方式為:高位位元組的最低有效位為0,低位位元組的最低有效位為1。 0x0000-0x3FFF範圍內的值表示網路層協議,。0x8000-0xBFFF範圍內的值表示NCP的相關資料。 0x4000-0x7FFF範圍內的值用於NCP不相關的"很少使用的"協議。 0xC000-0xEFFF範圍內的值表示控制協議,例如LCP。在某些情況下,如果協議欄位壓縮(PFC)選項在鏈路建立時協商成功,協議欄位可被壓縮為1位元組。 LCP分組總是使用 2位元組的未壓縮格式。
FCS：佔16或32位，(一個CRC16,生成多項式為10001000000100001 ), 涵蓋除FCS欄位本身和標誌位元組之外的整個幀。注意, FCS的值涵蓋任何位元組或位被填充之前的幀。LCP選項可將CRC從16位擴充套件到32位。在這種情況下,可採用與前面提到的乙太網相同的CRC32多項式。
標誌：佔8位，幀結束標誌
其他：
標誌衝突：
如果0x7E值出現在幀內部,這時會帶來一個小問題。它可通過兩種方式來處理,這取決於PPP工作在非同步還是同步鏈路上。
對於非同步鏈路, PPP使用字元填充(也稱為位元組填充)。如果標誌字元出現在幀中其他地方,則用2位元組序列0x7D5E (0x7D稱為“ppp轉義字元”)替換。如果轉義字元本身出現在幀中,則用2位元組序列0x7D5D替換。因此,接收方用0x7E替換接收的0x7D5E,並用0x7D替換接收的0x7D5D0。
在同步鏈路(例如T1線路、T3線路)上, PPP使用位填充。注意,標誌字元的位模式為01111110 (連續6個1的位序列),在除了標誌字元之外的任何地方,位填充在5個連續1之後填充一個00這樣做意味著,傳送的位元組可能超過8位,但這通常是正常的,因為低層序列處理硬體能去掉填充的位元流,並將它恢復成未填充時的樣子。
缺少長度欄位：
由於PPP缺少一個長度欄位,並且序列線路通常不提供幀封裝,所以在理論上對一個 PPP幀的長度沒有硬性限制。實際上,最大幀大小通常由MRU指定。當一臺主機指定一個 MRU選項(型別0x01)時,它要求對方不傳送比MRU選項提供的值更長的幀。MRU值是資料欄位的位元組長度,它不計算其他PPP開銷欄位(即協議、 FCS、標誌欄位)。它的典型值是1500或1492,但也可能多達65535。 Pv6操作需要的長度最小為1280。 PPP標準要求具體實現能接收最大1500位元組的幀, MRU更多的是建議對方選擇幀大小,而不是硬性限制幀大小。當小分組和大分組在同一條PPP鏈路上交錯傳輸時,較大分組可能佔用一條低頻寬鏈路的大部分頻寬,並影響小分組的正常傳輸。這可能導致抖動(延遲變化),對互動式應用 (例如遠端登入和VoIP)產生負面影響。配置較小的MRU (或MTU)有助於緩解這個問題, 但會產生更大的開銷。
LCP(Link Control Protocol)鏈路控制協議：
LCP的主要工作是使一條點到點鏈路達到最低要求。
配置訊息使鏈路兩端開始基本配置過程,並建立商定的選項。
終止訊息用於在完成後清除一條鏈路。LCP也提供了前面提到的 一些附加功能。
回送請求/應答訊息可由LCP在一條活躍鏈路上隨時交換,以驗證對方的操作。
放棄請求訊息可用於效能測試,指示對方丟棄沒有響應的分組。
標識和剩餘時間訊息用於管理，瞭解對方的系統型別,指出鏈路保持建立的時間(例如出於管理或安全原因)。
LCP分組格式
LCP的PPP協議欄位值始終是0xC021它不能用PFC刪除,以免產生歧義。
欄位解析：
程式碼：佔8位，給出了請求或響應的操作型別:配置請求(0x01)、配置接受ACK (0x02)、配置部分拒絕NACK (0x03)、配置完全拒絕REJECT(0x04)、終止請求(0x05 )、終止ACK(0x06)、程式碼REJECT(0x07)、協議REJECT(0x08 )、回送請求(0x09)、回送應答(0x0A)、放棄請求(0x0B)、標識(0x0C)和剩餘時間(0x0D)。ACK訊息通常表明接受一組選項, NACK訊息用建議選項表明部分拒絕。REJECT訊息完全拒絕一個或多個選項。
標識：佔8位，由LCP請求幀的傳送方提供的序列號,並隨著每個後續訊息進行遞增。
長度：佔16位，給出了LCP分組的位元組長度,它不能超過鏈路的最大接收單元(MRU)。注意,長度欄位是LCP協議的一部分，PPP協議通常不提供這個欄位。
MP (MP:Multi-Link PPP) 多鏈路點對點協議
可用於將多條點到點鏈路聚合為一條鏈路。這種想法與鏈路聚合相似，並被用於多個電路交換通道(例如ISDNB通道)的聚合。MP包含一個特殊的LCP選項,表示支援多鏈路,以及一個用於多鏈路上PPP幀分片與重組的協商協議。一條聚合鏈路(稱為一個捆綁)可作為一條完整的虛擬鏈路來操作,幷包含自已的配置資訊。鏈路捆綁由大量成員鏈路組成。每個成員鏈路可能有自已的選項集。
實現MP的典型方法是使分組輪流經過備個成員鏈路傳輸。這種方法稱為銀行櫃員算 法,它可能導致分組重新排序,可能為其他協議帶來不良的效能影響。 (例如,雖然TCP/ IP可以正確處理重新排序後的分組,但也可能不如沒有重新排序處理得好。) MP在每個分組中新增一個2 - 4位元組的序列頭部,而遠端MP接收方的任務是重建正確的順序。
MP幀格式
欄位解析：
頭部支援2種格式:短頭部(2位元組)和長頭部(4位元組)。 LCP的短序列號選項(型別18)用於選擇使用的格式。如果一個幀沒有被分片,但使用這種格式傳輸,則B和E位都被置位,表明該分片是第一個和最後一個(即它是整個幀)。否則,第一個分片的B、E位組合被設定為10,最後一個分片的B、E位組合被設定為01 ,它們之間的所有分片被設定為00。序列號給出相對第一個分片的分組號偏移量。
網路控制協議
對於IPv4, NCP被稱為IP控制協議(IPCP)。對於IPv6, NCP被稱為IPV6CP。在LCP完成鏈路建立和認證之後,該鏈路每端都進入網路狀態,並使用一個或多個NCP(例如典型的是一個IPCP)進行網路層的相關協商。
IPCP (針對IPv4的標準NCP)可用於在一條鏈路上建立IPv4連線,以及配置VinJacobson頭部壓縮(VJ壓縮)。 IPCP分組在PPP狀態機進人網路狀態之後交換。IPCP分組使用與LCP相同的分組交換機制和分組格式,除非協議欄位被設定為0x8021,並且程式碼欄位被限制在範圍0 - 7。程式碼欄位的值對應於訊息型別:特定供應商配置請求、配置ACK、配置REJECT、終止請求、終止ACK和程式碼REJECT。 IPCP可協商一系列選項,包括IP壓縮協議(2)、 IPv4地址(3)和移動IPv4 (4)。其他選項可用於獲得主要和次要的域名伺服器。
IPV6CP使用與LCP相同的分組交換機制和分組格式,但它有兩種不同的選擇:介面識別符號和IPv6壓縮協議。介面識別符號選項用於傳輸一個64位的ⅡD值,它作為形成一個鏈路本地IPv6地址的基礎。由於它僅在本地鏈路上使用,因此不需要具有全球唯一性。這通過在IPv6地址的高位使用標準鏈路本地字首,在低位設定某種功能的介面識別符號來實現。
壓縮控制協議
PPP是相對較慢的撥號調變解調器使用的協議。因此,針對PPP鏈路上 壓縮後傳送資料已提出一些方法。壓縮型別是不同的,無論是調變解調器硬體支援的壓縮型別(例如V42bis、 V44),還是我們以後討論的協議頭部壓縮。目前,有幾個壓縮選項可選。可在一條PPP鏈路的兩個方向做出選擇, LCP可協商一個使壓縮控制協議(CCP)生效的選項。ccp的作用就像NCP,只不過在LCP鏈路建立交換階段指明壓 縮選項時才開始處理配置壓縮細節。
CCP在行為上很像NCP,僅在鏈路進入網路狀態時協商。它使用與LCP相同的分組交換過程和格式(除協議欄位被設定為0x80FD之外),另外還有一些特殊選項,並對常見的程式碼欄位值(1~ 7)定義了2個新的操作:復位請求(0x0e)和復位確認(0x0f)。如果在一 個壓縮幀中檢測到一個錯誤,復位請求可用於要求對方復位壓縮狀態(例如字典、狀態變數、 狀態機等)。在復位後,對方響應一個復位確認。
一個或多個壓縮幀可作為一個PPP幀的一部分(即包括LCP資料和可能的填充部分)。 壓縮幀攜帶的協議欄位值為0x00FD,但是如何指明存在多個壓縮幀,這依賴於使用的特定壓縮演算法。當CCP與MP結合使用時,既可用於一個捆綁,也可用於多條成員鏈路的某些組合。如果只用於成員鏈路,協議欄位設定為0x00FB (單個的鏈路壓縮資料報)。
PPP認證
口令驗證協議(PAP):是不提供認證相比,最簡單、安全性最低的認證方案。這種協議非常簡單,一方請求另一方傳送一個密碼。由於該密碼在PPP鏈路上未加密傳輸,竊聽者線上路上可輕易捕獲密碼並使用它。由於這個重大的漏洞,不建議使用PAP進行認證。 PAP分組像LCP分組那樣編碼,協議欄位值設定為0xC023。
查詢一握手認證協議(CHAP):提供了一種更安全的認證方法。在使用CHAP時,一個隨機值從一方(稱為認證方)傳送到另一方。響應通過一種特殊的單向(即不可逆)功能,將一個隨機值和一個共享金鑰(通常由密碼生成)結合形成響應中的一個數字。在接收到這個響應之後,認證方能更可靠地驗證對方金鑰是否正確。這個協議在鏈路上不會以明文形式傳送金鑰或密碼,因此竊聽者難以瞭解相關資訊。由於每次使用不同的隨機值,每個查詢/響應的結果會改變,即使一個竊聽者有可能捕捉到這個值,也無發通過重新使用(回放)來欺騙對方。
可擴充套件身份驗證協議(EAP):是一個可用於備種網路的認證框架。它支援很多(約40個)不同的認證方法,從簡單密碼(例如PAP和CHAP)到更可靠的認證型別(例如智慧卡、生物識別)。 EAP定義了一種攜帶各種認證的訊息格式,但需要額外的規範定義EAP訊息如何在特定的鏈路上傳輸。當EAP被用於PPP時。EAP不是在鏈路建立(LCP 建立)階段協商一種認證方法,認證操作將被推遲到認證狀態(網路狀態的前一個狀態)。這 允許更多資訊型別用於影響遠端訪問伺服器(RAS)的訪問控制決策。當某種標準的協議用 於執行各種認證機制,網路訪問伺服器可能無須處理EAP訊息內容,但可依靠其他基礎設施的認證伺服器(例如RADIUS伺服器)確定訪問控制決策。這是當前的企業網和ISP設計中的首選方案。