【文章內容簡介】 PPPUDP/IPDATAIPPPPL2TPDATAIP L2TP協(xié)議幀的封裝 TCP/IP協(xié)議棧內部的數(shù)據(jù)流向分析正常情況下，數(shù)據(jù)鏈路層協(xié)議（以下簡稱L2P）的功能是為網(wǎng)絡層提供服務。其基本服務是把源機器中來自網(wǎng)絡層的數(shù)據(jù)傳輸給目的機器的網(wǎng)絡層。數(shù)據(jù)鏈路層與網(wǎng)絡層直接進行數(shù)據(jù)交換，以Linux操作系統(tǒng)為例，其L2P內核直接把數(shù)據(jù)包交給TCP/IP內核，然后再通過底層驅動，通常是Ethernet驅動，路由到目的地址。L2P Kernel（如PPP）L2 Driver(如Modem)Ethernet DriverTCP/IP Kernel TCP/IP協(xié)議棧內部的數(shù)據(jù)流向 加入L2TP協(xié)議后內部數(shù)據(jù)流向分析內核中加入L2TP協(xié)議以后，在L2TP內核中進行數(shù)據(jù)的處理，通過TCP/IP的內核來路由L2數(shù)據(jù)。L2TPD（L2TP守護進程）負責隧道和會話的創(chuàng)建、認證和拆除以及控制包的傳輸。以PPP為例，其中控制包可能是LCP等。數(shù)據(jù)包也就是二層的數(shù)據(jù)，如PPP的幀，在隧道建立完成后，通過L2TP的內核來完成封裝，再通過TCP/IP的內核路由到目的端。L2P DaemonL2P KernelL2 DriverEthernet DriverTCP/IP KernelL2TP KernelL2TPD模塊之間的交互數(shù)據(jù)包流向控制包流向注： 加入L2TP協(xié)議后內部數(shù)據(jù)流向LNS與LAC的區(qū)別在于LAC不去具體對二層協(xié)議幀進行處理，而只是對其進行封裝，在幀頭上做出協(xié)議標識。LNS在收到幀后，根據(jù)協(xié)議的標識，對二層幀頭部作相應的處理。例如，如果發(fā)現(xiàn)是PPP協(xié)議，則把幀交PPP內核進行處理。如果由LNS發(fā)起呼叫，則功能類似于LAC。 實現(xiàn)思路基于以上的討論，我們提出如下的實現(xiàn)思路：① 首先設計一個協(xié)議的總體框架，充分考慮與協(xié)議棧中各協(xié)議的交互協(xié)調；② 設計一個通用的L2TP內核，以便于多種應用的開發(fā)擴展，內核完成的協(xié)議的主要功能；③ 完成與內核相關的協(xié)議分析，包括幀的定義，AVP的定義，狀態(tài)機的分析定義，并完成相關的實現(xiàn)；④ 設計一個L2TP的守護進程，負責完成系統(tǒng)的整體運行，包括協(xié)議系統(tǒng)的初始化，LAC/LNS的配置等功能。后面的章節(jié)就按照這樣的思路分別作了詳細的闡述。第三章 L2TPv3協(xié)議分析與設計本章主要是對L2TPv3協(xié)議的分析，包括報文格式的定義，狀態(tài)機的描述，并繪制了狀態(tài)變遷表。目的是為了本章最后所作的系統(tǒng)設計的需要，包括系統(tǒng)的框架設計以及模塊的劃分等。 L2TPv3隧道報文本節(jié)將對協(xié)議中用到的所有報文的格式及類型進行綜合介紹，包括控制幀和數(shù)據(jù)報文，兩種不同的會話報文頭，AVP的定義，強制和隱藏，控制幀的類型。 控制和數(shù)據(jù)報文L2TP頭的格式包括控制報文和數(shù)據(jù)報文兩種格式，報文發(fā)送時采用高字節(jié)在前的發(fā)送順序。以下對兩種格式作分別介紹。① 控制報文頭格式控制報文的頭格式如下圖所示：01234567890123456789012345678901TLXXSXXXXXXXVerLengthControl Connection IDNsNr 控制報文的頭格式默認情況下，控制報文和數(shù)據(jù)報文在底層介質里一并傳輸，也就是帶內傳輸?？刂茍笪呐c數(shù)據(jù)報文的區(qū)別在于高字節(jié)中的最高位T，但是有時也采用其他的方式來區(qū)分，例如在L2TP over IP中采用的方式就有所不同。如果是控制報文則T就設置為1，否則為0。L值為1，則表示域的長度被設置，S值為1，則表示序列號被設置。X域是保留位作為將來的擴展用，如果是呼出報文的話，保留位則設定為0，如果是呼入報文則忽略。Ver域指明L2TP控制報文頭的版本號。Length域表示報文的字節(jié)長度，計算的方式從報文的頭部開始。控制連接ID域表示某個控制連接的標識。這個標識符只具有本地意義，同一個控制連接的兩個LCCE分別具有唯一的連接標識符。因此在每個報文中的控制連接ID是指指定的接收者，而不是發(fā)送者。在整個控制連接過程中，非0的控制連接ID作為已被分發(fā)的控制連接ID的AVP來進行選擇和交換。Ns表示控制報文的序列號，每個控制報文的發(fā)送以0開始，每次增加1。Nr表示下一個收到的控制報文所期望的序列號，也就是說Nr的值被設定為Ns加1。② 數(shù)據(jù)報文頭格式一般情況下，L2TP數(shù)據(jù)報文包括會話頭，可選的L2特殊子層即偽線控制封裝和入隧的二層幀。L2TP Session HeaderL2Specific SublayerTunneled Frame 數(shù)據(jù)報文的頭格式L2TP會話頭專應用穿過PSN的數(shù)據(jù)流。會話頭應該可以區(qū)分不同的L2TP會話，以及區(qū)分控制報文和數(shù)據(jù)報文。不同類型的PSN必須定義自身的會話頭，能夠明確地區(qū)分頭的格式以及建立會話所需的參數(shù)。文本定義了兩種會話頭，一種用于穿過UDP，一種用于穿過IP。所有的會話頭中都包括Session ID與Cookie兩個域，以下分別做說明。Session ID：是一個32位的域，包括一個會話標識符。會話標識符只具有本地的意義，也就是說在會話的生命期內，控制連接的兩端可以具有不同的會話ID。當控制連接用于會話連接建立時，在會話創(chuàng)建的過程中，會話ID以本地會話ID的AVP來進行選擇和交換。Cookie：這個域是可選的，長度可變，最大為8個字節(jié)，其值用于檢驗所接收的報文與會話的關系。Cookie必須用隨機的一個數(shù)值來填滿整個域。Cookie提供了一種確保數(shù)據(jù)報文直接與會話相關的機制，Cookie選擇恰當可以防止掉隊的報文與會話ID的錯誤關聯(lián)。當L2TP控制連接被用于建立會話時，在會話創(chuàng)立期間，一個隨機的Cookie值就被挑選出來，作為專門的Cookie AVP進行交換。L2特殊子層位于L2TP會話頭和入隧起始幀之間，其中控制域用來使每個幀可以方便的入隧。入隧幀由PW數(shù)據(jù)流組成，包括任何可以入隧的二層幀。數(shù)據(jù)報文頭后緊跟著所要入隧的二層幀。 L2TP over UDP會話報文格式L2TPv3 over UDP必須考慮到已經(jīng)存在的二層隧道協(xié)議，包括L2TPv2與L2F。01234567890123456789012345678901TXXXXXXXXXXXVerLengthSession IDCookie (optional, maximum 64 bits)... L2TPv3 over UDP會話頭T為必須設置為0，表明為數(shù)據(jù)報文。X為保留位，以為將來擴展使用。 L2TP over IP會話報文格式與L2TP over UDP不同，L2TPv3 over IP會話頭不受L2TPv2與L2F的限制。這樣頭格式的設計更加利于包的處理。01234567890123456789012345678901Session IDCookie (optional, maximum 64 bits)... L2TPv3 Over IP 會話頭同樣控制頭也有所不同，當發(fā)送控制報文時，它使報文頭前四個字節(jié)設為全0，這樣處理將使得區(qū)分數(shù)據(jù)報文和控制報文以及報文的校驗更加有效。01234567890123456789012345678901(32 bits of zeros)TLXXSXXXXXXXVerLengthControl Connection IDNsNr L2TPv3 Over IP 控制頭值得注意的使這里的長度不包括前面的32位0位。 AVP定義在確?；ビ眯缘那闆r下，為了最大化報文的可擴展性，在L2TP中采用報文類型和內容統(tǒng)一編碼的方法。這種編碼方法稱為AVP，即屬性值對。01234567890123456789012345678901MHrsvdLengthVendor IDAttribute TypeAttribute Value ...(until Length is reached) AVP格式前六位描述了AVP的一般屬性，其中前兩位被定義，而后四位作為保留位以為將來擴展用。保留位必須設置為0，如果有一位為1，則認為該AVP不可識別。 強制（M）位用于控制收到無法識別或畸形的AVP時的執(zhí)行動作。一個給定的AVP只有在無法識別或者畸形時M位才被檢查。如果一個與特殊會話或者控制連接相關的控制報文AVP無法識別或者是畸形，且M位被設定，則這個會話或連接以及綁定到這個連接上的所有會話必須被終止。如果M位沒有設定，則無法識別的AVP必須被忽略，控制連接應該繼續(xù)運行就好像該AVP不存在。隱藏（H）位用于識別AVP中屬性值域中的隱藏數(shù)據(jù)。其作用是避免敏感數(shù)據(jù)以明文發(fā)送，例如用戶密碼。長度字段（Length）表示這個AVP中的字節(jié)長度，一般為屬性值加6。長度字段共占10位，那么就允許在一個單獨的AVP中最大有1023個字節(jié)的數(shù)據(jù)。最小的AVP長度為6個字節(jié)，這時的屬性值域為空。Vendor ID是IANA分配的SMI網(wǎng)絡管理專有企業(yè)編碼。本文中采用的是0。開發(fā)商在擴展自己的功能時，要避免與其他開發(fā)商以及IETF將來的擴展沖突。這里Vendor ID分配了16位，那么限制了企業(yè)數(shù)為前65535個。屬性類型（Attribute Type）是一個兩字節(jié)的值用以表明AVP的類型。屬性值（Attribute Type）用以表明具體的AVP屬性。 強制AVP當一個無法識別或者畸形的AVP的M位設定時，那么對于會話和控制連接來說將是災難性的。所以M位只應該在一些關鍵的AVP中定義，比如說影響到會話和控制連接的正常運行的AVP。在LAC和LNS收到無法識別的AVP，并且M位已經(jīng)被設定的情況下，會話或者控制連接被終止，那么發(fā)送端應該正確的來處理這個錯誤。在定義這種AVP時應該要考慮到這個問題。在需要使用M位時，如果有其他的選擇，應該盡可能的選用其他選擇。例如，僅僅發(fā)送一個設定了M位的AVP來確定一個特殊的擴展是否存在，不如采用通過在請求報文里發(fā)送一個AVP，以期待在應答報文里是否存在一個相應的AVP這種方法來的要好。如果在一些新的AVP中使用了M比特位，必須能夠提供一定的配置把相聯(lián)系的特性排開，也就是或者不發(fā)送AVP或是發(fā)送時不設置M位。在接收端，當收到的控制報文中的AVP不可識別或是畸形時，應當只檢查這個AVP的M位，反之則不用檢查。這種規(guī)則可以防止當接收方收到一個有效AVP時，由于M位被設定為LCCE不期望的值而被LCCE關斷這個會話或控制連接。 AVP的隱藏每個AVP的頭部的H位提供了一種機制以對接收端的內容是否隱藏。這種機制可以用來隱藏一些敏感的控制報文數(shù)據(jù)，例如用戶ID或者用戶密碼。H位在以下兩種情況下必須采用：（1）兩個LCCE之間存在一個共享密鑰；（2）LCCE認證已經(jīng)完成。共享密鑰對于LCCE認證來說是同一個密鑰。在LCCE認證成功完成以后，隱藏值不可以公開（也許需要隱藏值保存直到附加配置報文接收到）。否則就會冒著在沒有確認共享密鑰的完整性的情況下使用了AVP數(shù)據(jù)的風險。如果在一個給定的控制報文中的任何AVP的H位被設定，一個隨機向量AVP必須出現(xiàn)在報文中并且在第一個帶有H位為1的AVP之前。隱藏AVP值有幾步。第一步獲得原始明文AVP的長度以及值域，并且將其編碼為如下隱藏AVP的子格式。01234567890123456789012345678901Length of Original ValueOriginal Attribute Value ...Padding ... 隱藏AVP的子格式Length of Original Attribute Value：這個字段表示原始屬性值的字節(jié)長度。當增加了Padding后，有必要知道原始數(shù)據(jù)的長度。Original Attribute Value：原始的屬性值。Padding：隨機附加的字節(jié)用于加密被隱藏的屬性值的長度。為了隱藏數(shù)據(jù)大小，可以如上圖所示增加Padding。Padding并不改變Length of Original Attribute Value域，但是改變了合成的AVP的長度。例如，如果屬性值是4個字節(jié)，那么未隱藏的AVP長度是10字節(jié)，即6+屬性值的長度。隱藏以后，AVP的長度變?yōu)?+屬性值的長度+原始的屬性值域的長度+Padding。這樣如果Padding是12個字節(jié)，那么AVP的長度將是6 + 4 + 2 + 12 = 24字節(jié)。第二步，對如下的串進行MD5哈希算法。l AVP兩字節(jié)屬性值l 共享密鑰l 一個任意長的隨機向量哈希表中的隨機向量的值通過隨機向量AVP中的值域來傳輸。發(fā)送者在進行AVP隱藏操作前，必須把這個隨機向量AVP放在報文中。在同一個報文