IPv6數據包的結構可以讓這個下一代網絡協議在可預見的未來實現幾乎無限的可擴展性。然而，經驗表明，這種靈活性是要付出代價的，這個代價就包括安全隱患。在本文中IPv6安全專家Fernando Gont探討了IPv6擴展報頭帶來的安全風險以及降低這種風險的方法。

當涉及到可擴展性時，IPv4數據包結構有兩個主要的限制。

首先，IPv4有著有限的選項空間(至多40字節)，這種數據包結構限制了IPv4可部署的擴展的數量和類型。其次，所有IPv4選項(無論是針對路由器還是主機)共享相同的“容器”，這意味著轉發IPv4數據包的每個路由器都必須處理所有IPv4選項，以防其中一個選項必須要由IPv4路由器處理。

相比之下，IPv6數據包結構則明顯不同。對于可擴展性，IPv6選項通過IPv6“擴展報頭”來傳遞，而不是在強制IPv6報頭(具有固定大小)。IPv6擴展報頭被插入在強制IPv6報頭和上層協議報頭之間，下圖顯示了IPv6數據包的結構，包括兩個擴展報頭。

從這個圖來看，IPv6數據包遵循“菊花鏈”的結構，其中每個IPv6擴展報頭指定了緊跟的報頭類型(通過“Next Header”字段)，并且每個擴展報頭指定了自己的長度(或者具有相關的固定長度)。因此，通過從強制IPv6報頭開始，并且每次跟隨一個擴展報頭，整個IPv6報頭鏈可以傳輸到上層協議報頭。下表列出了一些最常見類型的IPv6擴展報頭(來自IANA協議編號注冊機構)相應的Next Header值：

基于將對選項進行處理的節點類型，它們被傳遞在不同類型的IPv6擴展報頭。例如，預計將由到目標沿路徑的所有節點處理的選項會放在逐跳選項擴展報頭中。而僅由目標節點處理的選項則包含在目的選項擴展報頭中。其他擴展報頭可能有不同的用途。例如，路由報頭用來影響數據包如何轉發到目標節點，而分段報頭則被用于分段/重組機制。

有些擴展報頭必須遵循特定順序。例如，如果有逐跳選項報頭，它必須是強制IPv6報頭之后的第一個擴展報頭。這個概念很簡單;在IPv6報頭鏈中，將由到目標沿路徑的所有節點處理的擴展報頭必須先于僅由目標節點處理的擴展報頭。因此，IPv6路由器并不需要處理IPv6報頭鏈中所有報頭，而是停止在最后一個擴展報頭--其中包含需由IPv6路由器處理的選項。

此外，由于逐跳選項報頭僅包含必須由數據包傳送路徑所有節點處理的選項，路由器將不會浪費資源來處理不必要的選項。

在IPv6中，所有分段相關的報頭字段已經從強制IPv6報頭中刪除，并移動到(可選)“分段報頭”。從概念上講，原始(或“未分段”)數據包總是在發送節點構建，并只有在那時(如果需要)會進行分段。下圖展示了原始IPv6數據包的概念結構：

原始數據包由“不可分段部分”和“可分段部分”組成。不可分段部分包括IPv6報頭以及必須由到目標節點沿路徑所有節點處理的擴展報頭，即到路由報頭的所有報頭(如果存在，也包括路由報頭)，或者逐跳選項報頭(如果存在)，或者沒有擴展報頭。而不可分段部分則由其余數據包部分組成;即只能由最終目標節點處理的所有IPv6擴展報頭，還有上層報頭和數據。不可分段部分將存在于所有產生的片段中，而可分段部分將被分割為多個片段。因此，每個片段是通過“串聯”原始數據包的不可分段部分(具有一個分段報頭)和一塊可分段部分來構建。下圖展示了基于上面描述的邏輯數據包如何分割成多個IPv6片段：

尋找上層協議信息

在IP數據包執行簡單訪問控制列表(ACL)所需的每個路由器或中間體都必須能夠找到上層協議報頭，該報頭通常包括源和目的地端口號。IPv4的數據包結構讓節點可以很容易找到上層協議報頭：通過從IPv4報頭跳過在IPv4“互聯網報頭長度”字段所指示的字節數，處理節點可以簡單地“跳過”選項空間。

然而，在IPv6的情況下，并沒有尋找上層協議報頭的“線索”。因此，尋找上層協議報頭的唯一方法是在強制IPv6報頭開始，處理/緊跟IPv6報頭鏈中的每個擴展報頭，直到發現最后一個報頭。

應當指出的是，這個過程曾經更為復雜：IPv6報頭鏈本身可以是分段的，擴展報頭和上層協議報頭被分成多個片段。因此，無狀態設備(即在檢查前未執行分段重組的設備)不太可能獲取上層協議信息。例如，下面的數據包以前被認為是有效的：

幸運的是，2014年年初發布的RFC 7112已經宣布這些數據包為非法，因此最新的部署并不需要擔心它們(可以丟棄它們)。#p#

IPv6擴展報頭的安全隱患

IPv6擴展報頭的安全隱患通常分為下面幾種：

· 安全控制規避

· 由于處理要求而創造拒絕服務條件

· 因為部署錯誤而創造拒絕服務條件

· 每個擴展報頭特定的問題

正如上文所述，在IPv6數據包中尋找上層協議報頭被證明是一項艱巨的任務。更糟糕的是，有些中間體和安全設備希望上層協議報頭緊跟強制IPv6報頭，因此，當使用IPv6擴展報頭時，無法找到或者識別上層協議。例如，這些安全設備或中間體無法認識到下面的數據包是TCP端，這僅僅是因為使用了目的選項擴展報頭：

這樣的原因在于，上述設備不會處理整個IPv6報頭鏈來尋找上層報頭，而是假設強制IPv6報頭的“下一報頭”字段描述/指示了上層協議類型。因此，上述圖表中的數據包被認為是“目的選項”數據包，而不是TCP段。

如果安全設備采用這種(存在問題的)邏輯，并且已經被配置為執行“默認允許”政策(即允許所有數據包，除非它們符合指定的規則之一)，它們可能將受到規避攻擊。這種攻擊的簡單變體是，數據包采用多個IPv6擴展報頭，或者一個大的擴展報頭來在多個部署中觸發不同的問題。有些部署會限制它們處理的擴展報頭的數量，或者對于它們可以檢查的關于“多少字節進入IPv6數據包”有著特定的限制。這樣的情況可以從下面的圖中反映出來：

執行一種或兩種限制并采用“默認允許”政策的部署也容易受到規避攻擊。而某些極端情況數據包處理的模糊性則代表著規避安全控制的另一種可能。

通過隱藏上層協議類型(正如上文所述)或者隱藏應用數據流，IPv6分段還可以被利用來執行規避攻擊。在過去的幾年中，我們發現很多部署容易受到這些規避技術的攻擊。例如，RFC 7113在RA-Guard事件中描述了這個問題，相同的技術還可以用于繞過某些IPv6防火墻。此外，有些數據包處理方式的不一致可能導致安全控制規避，正如思科公司的Panos Kampanakis和研究人員Antonios Atlasis所指出的。

IPv6擴展報頭可能對設備處理產生負面的性能影響。雖然這可能似乎不像一個安全問題，但這也需要慎重考慮。例如，IPv6路由器部署通常處理在軟件(而不是硬件)中包含逐跳選項擴展報頭的數據包，其他IPv6路由器部署則處理在軟件中部署IPv6擴展報頭(當它們被配置為執行ACL時)的數據包。這意味著，除非有適當的緩解措施(例如數據包過濾/或對采用擴展報頭的數據包的限速)，攻擊者可能會通過簡單地發送大量采用IPv6擴展報頭的IPv6流量來執行拒絕服務(DoS)攻擊。

雖然IPv6協議本身(以及很多部署)已經存在很多年，最近在很多部署中發現了IPv6擴展報頭處理過程中的漏洞問題。發現這些漏洞的可能原因在于，大多數擴展報頭并沒有真正部署在現實世界的流量中，從而很少使用相應的代碼。出于這個原因，在有些部署中發現IPv6擴展報頭的處理中仍然存在漏洞并不令人驚訝。

最后，除了IPv6擴展報頭的一般安全隱患外，每個擴展報頭類型往往都有著自己特定的安全問題。例如，安全研究人員在2007年報道如何使用路由報頭Type 0(現在已經過時)來執行DoS攻擊。另一個具有安全隱患的擴展報頭是Fragment Header，它用于IPv6的分段/重組功能。雖然分段/重組機制的很多安全隱患在IPv4領域已經很有名，但現在很多相關問題已經悄悄潛入IPv6部署，從DoS攻擊到信息泄露或規避攻擊(詳情請參與筆者最近對可預測片段標識值的IETF草案和Antonios Atlasis在2012年歐洲黑帽大會的展示)。

結論

很多(如果不是大多數)源自IPv6擴展報頭的安全問題往往與如何部署相應的支持有關：從有漏洞的代碼，到在軟件(而不是硬件)中處理擴展報頭的設備。有些部署可能提供緩解技術，例如對采用IPv6擴展報頭的數據包進行限速(在創造DoS條件之前丟棄多余的流量)。在其他情況下，管理員可能沒有其他選擇，只能過濾相應的流量。顯然這是值得關注的領域，隨著IPv6網絡部署工作繼續推進，企業網絡安全專業人士必須密切關注。