IPsec-傳輸模式可休矣

《IPsec-傳輸模式可休矣》由會員分享，可在線閱讀，更多相關(guān)《IPsec-傳輸模式可休矣（20頁珍藏版）》請在裝配圖網(wǎng)上搜索。

1、 IPsec ，傳輸模式可休矣 西電捷通安全協(xié)議技術(shù)研究 1. IPsec簡介 IPsec （ IP security ）是 IETF（The Internet Engineering Task Force ，互聯(lián)網(wǎng)工程任 務(wù)組）制定的三層隧道加密協(xié)議，它為 Internet 上傳輸?shù)臄?shù)據(jù)提供了高質(zhì)量、可互操作、 基于密碼學(xué)的安全保證。特定的通信方之間在 IP 層通過加密與數(shù)據(jù)源認證等方式，提供了 以下的安全服務(wù)： I、數(shù)據(jù)機密性（ Confidentiality

2、 ）： IPsec 發(fā)送方在通過網(wǎng)絡(luò)傳輸包前對包進行加密。 II、數(shù)據(jù)完整性（ Data Integrity ）： IPsec 接收方對發(fā)送方發(fā)送來的包進行認證，以確 保數(shù)據(jù)在傳輸過程中沒有被篡改。 III 、數(shù)據(jù)源認證（ Data Origin Authentication ）：IPsec 在接收端可以認證發(fā)送 IPsec 報文的發(fā)送端是否合法。 IV 、防重放（ Anti-Replay ）： IPsec 接收方可檢測并拒絕接收過時或重復(fù)的報文。 IPsec 不是一個單獨的協(xié)議， 它給出了應(yīng)用

3、于 IP 層上網(wǎng)絡(luò)數(shù)據(jù)安全的一整套體系構(gòu)架， 包括 AH （ Authentication Header ，認證頭）、 ESP（ Encapsulating Security Payload ， 封裝安全載荷） 、 IKE（ Internet Key Exchange ，因特網(wǎng)密鑰交換）和用于網(wǎng)絡(luò)認證及加密 的一些算法等。 其中， AH 與 ESP 是用于提供安全服務(wù)的協(xié)議， IKE 是用于密鑰交換的協(xié)議。 IPsec 具有以下優(yōu)點： a、支持 IKE（ Internet Key

4、 Exchange ，因特網(wǎng)密鑰交換） ，可實現(xiàn)密鑰的自動協(xié)商功 能，減少了密鑰協(xié)商的開銷?？梢酝ㄟ^ IKE 建立和維護 SA （Security Association ，安全 聯(lián)盟）的服務(wù)，簡化了 IPsec 的使用和管理。 b 、所有使用  IP  協(xié)議進行數(shù)據(jù)傳輸?shù)膽?yīng)用系統(tǒng)和服務(wù)都可以使用  IPsec ，而不必對這些 應(yīng)用系統(tǒng)和服務(wù)本身做任何修改。 IPsec  具有以下缺點： a、安全

5、服務(wù)協(xié)議  AH  和 ESP 所提供的功能重疊率非常高，雖然  IPsec  的最新版本規(guī)定 AH  為可選協(xié)議，但是并沒有解決  IPsec  組合的復(fù)雜度問題。從而導(dǎo)致  IPsec  的工程實現(xiàn)以 及部署維護的成本仍舊非常高。 b 、安全服務(wù)協(xié)議的工作模式眾多：傳輸模式、隧道模式；再加上兩種協(xié)議的組合，導(dǎo) 致 IPsec 的復(fù)雜度高。 協(xié)議包含有太多的選項和

6、太多的靈活性， 做同樣或類似的事有幾種方式， 從而引入的復(fù) 雜度會導(dǎo)致工程實現(xiàn)的系統(tǒng)非常復(fù)雜， 存在的安全漏洞也就非常多， 安全評估也就非常困難， 從某種意義上來講，復(fù)雜是安全的最大敵人。由于歷史原因（例如，在制定之初，有些技術(shù) 還沒有發(fā)展起來； 或者有些應(yīng)用場景還沒有出現(xiàn)） ，IPsec 在不斷地打補丁、 補漏洞導(dǎo)致 IPsec 到目前為止已然成為了復(fù)雜的難以分析其安全性的安全協(xié)議。 從工作模式的角度入手， IPsec 的工作模式分為傳輸模式和隧道模式，而這兩種工作模 式結(jié)合 AH 與 ESP 以及 A

7、H 和 ESP 的組合，又會衍生更多的工作模式，導(dǎo)致 IPsec 在工程 實現(xiàn)、 維護上大大加重了其復(fù)雜度。 系統(tǒng)越復(fù)雜， 存在的安全漏洞就越多， 安全評估就越困 難，復(fù)雜性已然成了安全的敵人。 IPsec 包含有太多的選項和太多的靈活性，實現(xiàn)同樣的或 類似的功能通常有好幾種方式， 這樣的膨脹和復(fù)雜對于一個安全性的標準， 將是毀滅性的危 害。 隨著技術(shù)的發(fā)展， 根據(jù) IPsec設(shè)計工作模式的目標， 結(jié)合工作模式的應(yīng)用場景建議把 IPsec 的傳輸模式淘汰掉（此觀點與在荷蘭阿姆斯特丹工作的獨立

8、的密碼學(xué)顧問尼爾斯 .弗格森和 國際知名的安全專家、 Counterpane Internet Security Inc 公司創(chuàng)始人布魯斯施奈爾合著的 《 A Cryptographic Evaluation of IPsec 》的文章觀點不謀而合） ，以減少其工作模式選 項，降低其復(fù)雜度，從而減少由于工作模式組合而產(chǎn)生的安全漏洞，提高其安全性。 2. IPsec傳輸模式已老矣 2.1 IPsec 應(yīng)用場景 RFC4301文檔《 Security Architecture for the Internet P

9、rotocol 》（《 IP 安全構(gòu)架》）3.1 節(jié)中 描述： 【通過選擇適當安全協(xié)議、密碼算法和密鑰，在 IP 層提供 IPsec 安全業(yè)務(wù)。 IPsec能夠 用于保護一條或多條“路徑” ，在 (a)一對主機間， (b)一對安全網(wǎng)關(guān)間，或 (c)安全網(wǎng)關(guān)和主機 間?！? 這說明 IPsec 的應(yīng)用環(huán)境為主機間、主機與網(wǎng)關(guān)間以及網(wǎng)關(guān)間。 IPsec 主機 IPsec 主機

10、 圖 1 IPsec主機應(yīng)用場景 應(yīng)用主機 IPsec 主機 IPsec 網(wǎng)關(guān) 應(yīng)用主機 圖 2 IPsec 主機網(wǎng)關(guān)應(yīng)用場景 應(yīng)用主機 應(yīng)用主機 IPsec 網(wǎng)關(guān) IPsec 網(wǎng)關(guān) 應(yīng)用主機 應(yīng)用主機 圖 3 IPsec網(wǎng)關(guān)應(yīng)用場景 RFC4301文檔 4.1 節(jié)的歸納中描述：

11、 【 a)IPsec主機實現(xiàn)必須支持傳輸模式和隧道模式。這對主機的本地、 BITS和 BITW 實現(xiàn)都 成立。 b)安全網(wǎng)關(guān)必須支持隧道模式，可以支持傳輸模式。如果它支持傳輸模式，應(yīng)當僅在安 全網(wǎng)關(guān)充當主機時使用，例如，用于網(wǎng)絡(luò)管理，或在路徑上兩個中間系統(tǒng)間提供安全。 】 -注：如果網(wǎng)關(guān)作為主機使用才能支持傳輸模式，那么最終不還是說明傳輸模式應(yīng)該使用在主機間環(huán)境嗎？ “ IPsec安全協(xié)議操作模式具體適合在哪一種應(yīng)用

12、場景下工作” 這一觀點就沒有 RFC2401 文檔《 Security Architecture for the Internet Protocol 》（《 IP 安全構(gòu)架》）闡述得明了和直接。 RFC2401文檔中明確說明傳輸模式適合在主機間工作， 隧道模式適合在帶有網(wǎng)關(guān)的場景下工 作（操作模式適應(yīng)的場景，在 RFC4301 文檔中的最終觀點與 RFC2401 其實是一樣的，只不 過 RFC4301闡述的更加復(fù)雜和模糊。 結(jié)合 RFC2401和 RFC4301文檔對 IPsec安全協(xié)議操作模式適應(yīng)的應(yīng)用場景可以得出結(jié)論

13、： 1、傳輸模式適用于主機間應(yīng)用場景； 2、隧道模式適用于帶有網(wǎng)關(guān)的應(yīng)用場景。 在 RFC2401 和 RFC4301 文檔中都有描述，隧道模式在主機間應(yīng)用場景使用可行。那么為什么還要增加傳輸模式呢？增加這一模式的好處在哪里？傳輸模式相比隧道模式有哪些 無可比擬的優(yōu)點？這些答案在所有關(guān)于IPsec標準文檔中都沒有體現(xiàn)。 IPsec 標準文檔中沒有任何證明來說明增加傳輸模式的必要理由，而且在主機間應(yīng)用場 景下可以使用隧道模式， 在有網(wǎng)關(guān)的應(yīng)用場景下不適合傳輸模式； 再從增加一種模式的額

14、外 花費（針對增加的復(fù)雜性和導(dǎo)致的安全性損失） 是很巨大的觀點出發(fā)， 增加傳輸模式實在是 沒有必要。 從 RFC2401和 RFC4301文檔的 IPsec操作模式應(yīng)用場景的描述來看， 傳輸模式適應(yīng)的應(yīng) 用場景和完成的工作， 隧道模式完全可以勝任。 所以，從應(yīng)用場景的角度出發(fā)， 為了簡化 IPsec 的復(fù)雜選項，減少由于操作模式與其它選項組合而產(chǎn)生的安全漏洞，提高 IPsec整體框架的 安全性，建議 IPsec 安全協(xié)議操作模式中的傳輸模式淘汰。 2.2 操作模式設(shè)計目標

15、 在 RFC4301 文檔中描述： 【每種協(xié)議支持兩種應(yīng)用模式： 傳輸模式和隧道模式。 在傳輸模式中， AH 和 ESP 主要 為下一層（高層）協(xié)議提供保護；在隧道模式中， AH 和 ESP 應(yīng)用于隧道化的 IP 分組?！? 從此段描述中不難看出： 傳輸模式是為高級協(xié)議提供保護而設(shè)計的， 隧道模式是為整個 IP 分組提供保護而設(shè)計的。 那么問題來了，保護 IP 分組的同時是否就可以保護高級協(xié)議了

16、？如果是，那么隧道模 式完全可以取代傳輸模式； 如果不是， 那么就應(yīng)該在 IPsec 的相關(guān)標準文檔中明確指出有哪 些問題或點，亦或功能只可以在傳輸模式下完成， 隧道模式下無法完成。但是很遺憾， 所有 的 IPsec 標準文檔都沒有關(guān)于這方面的證明和描述。 IPsec 標準文檔中沒有任何證明來說明在哪一種情況下只有傳輸模式可以完成的功能， 而隧道模式無法完成。 從操作模式的設(shè)計目標來看，隧道模式的保護范圍又完全包含了傳輸模式的保護范圍。 隧道模式在實現(xiàn)保護高層協(xié)議這一目標的情況下又引入傳輸

17、模式來專職保護高層協(xié)議， 從而 增加 IPsec 的復(fù)雜度， 加大由于選項組合產(chǎn)生的安全漏洞風(fēng)險。 鑒于隧道模式保護范圍大于 傳輸模式，所以建議淘汰傳輸模式，減少由于操作模式與其它選項組合而產(chǎn)生的安全漏洞， 提高 IPsec 整體框架的安全性。 2.3 操作模式技術(shù)實現(xiàn) IPsec 安全協(xié)議的封裝格式為： 模式 傳輸模式 隧道模式 協(xié)議 AH IP頭 AH IP數(shù)據(jù)： 新IP頭 AH IP頭 IP

18、數(shù)據(jù)： TCP/UDP/ICMP TCP/UDP/ICMP IP數(shù)據(jù)： IP數(shù)據(jù)： ESP IP頭 ESP TCP/UDP/ICMPESP-T 新IP頭 ESP IP頭 TCP/UDP/ICMPESP-T AH+ESP IP頭 AHESP IP數(shù)據(jù)： ESP-T 新IP頭 AH ESP IP頭 IP數(shù)據(jù)： ESP-T TCP/UDP/ICMP TCP/UDP/ICMP 圖 4 IPsec 安全協(xié)議封裝格式

19、 從封裝格式可以看出，傳輸模式與隧道模式的區(qū)別在于： 1、傳輸模式保護的是 IP 數(shù)據(jù)，安全協(xié)議頭插在原 IP 頭和 IP 數(shù)據(jù)之間； 2、隧道模式保護的是 IP 分組，安全協(xié)議的頭前增加新的 IP 頭。 但是我們不知道這樣做的目的是什么。 如果把傳輸模式進行隧道化， 那么隧道模式的封 裝就會出現(xiàn)如下特性： 新 IP 頭 =IP 頭 即如圖 5 傳輸模式隧道化所示： 模式 協(xié)議 傳輸模式隧道化 AH IP 頭 AH I

20、P 頭 IP 數(shù)據(jù)： TCP/UDP/ICMP ESP IP 頭 ESP IP 頭 IP 數(shù)據(jù)： ESP-T TCP/UDP/ICMP AH+ESP IP 頭 AH ESP IP 頭 IP 數(shù)據(jù)： ESP-T TCP/UDP/ICMP 圖 5 傳輸模式隧道化 顯而易見， 傳輸模式的隧道化封裝與隧道模式封裝形式上已經(jīng)變成一模一樣了， 只是在 帶寬上，傳輸模式隧道化后會比原傳輸模式多消耗一個 IP 頭的開銷。

21、 那么如果這樣做了， 從功能上和所保護的對象上來看都沒有什么損失。 那么有些人可能 會從網(wǎng)絡(luò)傳輸性能上進行抨擊： 傳輸模式在主機間進行工作， 明顯占用帶寬要比隧道模式減 少一個 IP 頭的開銷。 2.3.1 網(wǎng)絡(luò)傳輸性能 很多人提到傳輸模式在主機間進行工作，明顯占用帶寬要比隧道模式減少一個 IP 頭的 開銷， 意味著傳輸模式節(jié)省了帶寬， 但是隨著傳輸媒介和技術(shù)的發(fā)展， 該優(yōu)勢是否還存在？ 首先：假如主機間通信的傳輸媒介是有線，相互通信的設(shè)備 IP 地址必須在其間的網(wǎng)絡(luò) 可路由

22、 ,例如內(nèi)部網(wǎng)絡(luò)的主機要安全的訪問內(nèi)部服務(wù)器資源；其網(wǎng)絡(luò)帶寬對流量不敏感，增 加或減少一個 IP 頭的開銷并不會影響整個系統(tǒng)，在這種場景應(yīng)用下，大家并不關(guān)心網(wǎng)絡(luò)帶 寬的問題，那么這時隧道模式完全可以替代傳輸模式進行安全通信。 其次： 假如主機間通信的傳輸媒介是無線，且是收費的， 其網(wǎng)絡(luò)帶寬對流量敏感， 那么 隧道模式的 IP 頭壓縮技術(shù)的應(yīng)用是完全可以達到甚至優(yōu)于傳輸模式對帶寬開銷的效果，如 表 1 IP 報頭壓縮增益所示。 表 1IP 報頭壓縮增益 報頭類型 壓縮前長度 壓縮后最小長

23、度 壓縮增益 IPv4/TCP 40 字節(jié) 4 字節(jié) 90% IPv4/UDP 28 字節(jié) 1 字節(jié) 96.4% IPv6/TCP 60 字節(jié) 4 字節(jié) 93.3% IPv6/UDP 48 字節(jié) 3 字節(jié) 93.75% 注： ①通常 IPv4 報頭長為 20 字節(jié)； IPv6 報頭長為 40 字節(jié)； TCP報頭長 20 字節(jié)； UDP 報頭 長 8

24、字節(jié)； ② IP 報頭壓縮，壓縮的是 IPv4/IPv6 和 TCP/UDP報頭。 從表 1 中可以看出，隧道模式 +IP 報頭壓縮對網(wǎng)絡(luò)帶寬的開銷遠遠小于傳輸模式對網(wǎng)絡(luò) 帶寬的開銷；傳輸模式對網(wǎng)絡(luò)僅僅減少了一個 IP 頭的開銷（ IPv4 為 20 字節(jié)， IPv6 為 40 字 節(jié)）；如圖 6 所示（以 IPv4，數(shù)據(jù)為 TCP數(shù)據(jù)為例） IP 頭 TCP頭 數(shù)據(jù) 40字節(jié) 壓縮 帶IP 壓縮的隧道模式 傳輸模式

25、 新IP 頭 IPsec 頭壓縮頭 數(shù)據(jù) IP 頭 IPsec 頭 TCP頭 數(shù)據(jù) 4字節(jié) 20字節(jié) 傳輸模式 - 帶IP 壓縮的隧道模式 = 16 字節(jié)（20-4） 圖 6 帶 IP 壓縮的隧道模式與傳輸模式網(wǎng)絡(luò)開銷對比 如圖 6 ，從對網(wǎng)絡(luò)開銷上來看，帶 IP 壓縮的隧道模式對網(wǎng)絡(luò)的開銷低于傳輸模式。 這時候，還會有人提到傳輸模式的 IP 數(shù)據(jù)報頭如 TCP/UDP報頭也可以使用壓縮技術(shù)實 現(xiàn)網(wǎng)絡(luò)帶寬開銷的減少呀！這種觀點也站不住腳

26、，因為即使傳輸模式使用 IP 數(shù)據(jù)報頭壓縮 技術(shù)也只能使帶寬開銷與隧道模式 +IP 壓縮技術(shù)的帶寬開銷相當，例如 IPv4/UDP 的 IP 壓縮 最小為 1 個字節(jié)，而 IP 數(shù)據(jù)報頭 UDP的壓縮最小也不會比 1 個字節(jié)小。 所以，從帶寬開銷方面來抨擊隧道模式替換傳輸模式的思路實在是太牽強了。 2.3.2 封解包性能 從網(wǎng)絡(luò)開銷方面抨擊隧道模式替換傳輸模式的思路站不住腳，那么，隧道模式使用 IP 報頭壓縮技術(shù)是否會影響封包和解包的性能？ 這其實是從工程實現(xiàn)角度來

27、抨擊隧道模式替換傳輸模式的思路。 首先，隧道模式封解包性能一開始就高于傳輸模式封解包性能，如圖 7 所示： 進行重新封包 IP 頭 TCP頭 數(shù)據(jù) 進行原包文拆封 1 1 解析 IP 報頭 2 進行重新封包 隧道模式 傳輸模式 新IP 頭 IPsec 頭 IP 頭 TCP頭 數(shù)據(jù) IP 頭 IPsec 頭 TCP頭 數(shù)據(jù) 封包方式注： 隧道模式 —對原 IP報文只進行步驟 1 對原 IP 報文進行重新封包

28、 傳輸模式 — 對原 IP 報文需進行兩步才能完成封包： 1 2  對原 IP 報文進行拆封解析 對解析后的報文進行重新封包 圖 7 隧道模式與傳輸模式封包過程對比 從圖 7 可以看出，形成最終能夠傳輸?shù)陌踩珗笪臅r，傳輸模式封包比隧道模式多出一 個拆封解析的過程， 所以其組包性能肯定低于隧道模式 （這一點， 就已經(jīng)是對抨擊影響封解 包性能論者的一個有力回擊） 。 其次，隧道模式引入 IP 報頭壓縮，應(yīng)該會影響隧道模式封包 / 解包性能，如圖 8 所示

29、： IP 報頭壓縮  IP 頭 TCP頭 數(shù)據(jù) 進行原包文拆封 1 1 壓縮頭 數(shù)據(jù) 解析IP 報頭 進行重新封包 2 2 進行重新封包 隧道模式 傳輸模式 新 IP 頭 IPsec 頭 壓縮頭 數(shù)據(jù) IP 頭 IPsec 頭 TCP頭 數(shù)據(jù) 封包方式注： 隧道模式 — 對原 IP報文進行 IP 報頭壓縮的封裝分兩個步驟： 1 對原 IP 報頭進行壓縮形成帶壓縮頭的報文 2 對帶有壓縮頭的報文進行重新封裝 傳輸模式 — 對原 I

30、P 報文需進行兩步才能完成封包： 1 對原 IP報文進行拆封解析 2 對解析后的報文進行重新封包 圖 8 帶 IP 頭壓縮的隧道模式與傳輸模式封包過程對比 從圖 8 帶 IP 頭壓縮的隧道模式與傳輸模式封包對比來看， 原始 IP 報文以隧道模式進行 封裝時與傳輸模式封包所經(jīng)歷的步驟是一樣的，區(qū)別在于重新封包的前一步驟：帶 IP 頭壓 縮的隧道模式在重新組包前需要進行原 IP 報頭壓縮，而傳輸模式在重新組包前需要進行原 IP 報頭的解析。 如果說隧道模式引入 IP 報頭壓縮

31、后其封解包性能降低了， 就應(yīng)該是 IP 報頭壓縮本身的 影響，那么 IP 報頭壓縮本身對性能的影響真的很大嗎？讓我們來看看 IP 報頭壓縮原理。 報頭之所以能夠被壓縮主要是因為報頭字段之間存在很大的冗余度。 這種冗余度不但存 在于同一個包的報頭中 , 而且大量存在于屬于同一包流中的連續(xù)包的報頭字段之間。 報頭的 冗余分為三類： ①保持不變的部分，如 IP 地址、版本號等； ②通過其它方法可以推算出來的部分，如 IP 校驗和、數(shù)據(jù)包長度等； ③兩相鄰的數(shù)據(jù)包的某些字段

32、是按增量變化的，并且變化量很小的部分，如 TCP 的序 列號等。 剩余的部分是隨機變化的部分。 取出上述三種冗余就是對報頭進行壓縮， 在壓縮和解壓 縮端建立壓縮狀態(tài)后，就只傳輸剩下的隨機部分和增量了。 從 IP 報頭的壓縮原理可以看出，壓 / 解壓縮是根據(jù)一套規(guī)則進行 IP 報頭解析，然后把 相關(guān)信息保留在一個上下文中； 上下文中的信息被用來壓縮或解壓縮后面的包； 壓縮器和解 壓縮器在某些事件的激勵下更新它們的上下文信息。那么根據(jù)這套原理不難發(fā)現(xiàn)， IP 報頭 壓縮 / 解壓縮的過程就是報

33、頭解析、對比、恢復(fù) / 刪除 / 更新的過程，沒有使用復(fù)雜的數(shù)學(xué)運 算，因此開銷并不大；隨著技術(shù)的發(fā)展，這早已不是什么性能瓶頸了。 當然，隧道模式引入 IP 報頭壓縮，相比傳輸模式肯定會有封解包性能損失的，但是為 了這一點點的性能提升， 引入傳輸模式增加安全協(xié)議的復(fù)雜度從而導(dǎo)致 IPsec 成為了復(fù)雜得 難以分析其安全性的安全協(xié)議實在是不合理的 （安全協(xié)議卻為了提升性能犧牲安全， 是本末 倒置的做法，不可?。?。 2.3.3 安全性 從封解包性能方面抨擊隧道模式替換傳輸模式的思路的理由

34、也不是很充分， 那么，安全 性呢？是否在某種場合下，使用傳輸模式要比使用隧道模式更安全？ 這一論調(diào)最起碼在 IPsec 的標準文檔中得不到證實；而且從設(shè)計的目標（ 2.2 節(jié)操作模 式的設(shè)計目標）來看，隧道模式的保護范圍包含傳輸模式的保護范圍；從整個 IPsec系統(tǒng)來 看，隧道模式涵蓋了傳輸模式的安全能力。 在荷蘭阿姆斯特丹工作的獨立的密碼學(xué)顧問尼爾斯 .弗格森和國際知名的安全專家、 Counterpane Internet Security Inc 公司創(chuàng)始人布魯斯施奈爾 合著的《

35、A Cryptographic Evaluation of IPsec》一文中有如下描述： 【在確定的模式中， 隧道模式的功能是傳輸模式功能的擴展 （從網(wǎng)絡(luò)的角度出發(fā)， 你可以把 隧道模式看做是傳輸模式的特例，但是從安全的角度出發(fā)卻不是這種情況。 ）我們能看到的 傳輸模式的唯一優(yōu)點是一個較小的網(wǎng)絡(luò)開銷。 但是，隧道模

36、式可以使用我們稍后說明的專業(yè) 報頭壓縮方案進行直接擴展， 這樣就可以達到幾乎與傳輸模式同樣的功能， 而不需要引進一 個完全新的模式，因此我們建議將傳輸模式淘汰。 】 從以上尼爾斯 .弗格森和布魯斯施奈爾的描述中，我們可以看出其與我們的觀點相同： 隧道模式完全涵蓋了傳輸模式的安全能力，傳輸模式確實可以淘汰了。 由于傳輸模式的存在， 使得工程實現(xiàn)變得復(fù)雜， 越復(fù)雜的工程實現(xiàn)， 那么有可能安全漏 洞就越多，存在著潛在的安全風(fēng)險。所以從安全的角度出發(fā)，我們也建議淘汰傳輸模式。

37、 3. 淘汰意義 IPsec的復(fù)雜是網(wǎng)絡(luò)安全領(lǐng)域從業(yè)者都知道的事實。 由于復(fù)雜， 才導(dǎo)致 IPsec成為一種難 以分析其安全性的安全協(xié)議。 IPsec 包含有太多的選項和太多的靈活性，實現(xiàn)同樣的或類似的功能通常有好幾種方式 （如：主機間安全通信就有傳輸模式和隧道模式之選項， 而且隧道模式完全可以代替?zhèn)鬏斈? 式工作），這樣的膨脹和復(fù)雜對于一個安全性的標準，將是毀滅性的危害。 IPsec操作模式的分類就是導(dǎo)致 IPsec復(fù)雜的一個原因。 根據(jù)前面的分析， 傳輸模式可以 廢止，然后傳輸模式的

38、工作全部由隧道模式來完成。如果淘汰傳輸模式，那么意義非常大： ①精簡操作模式， 減少由于傳輸模式與其它選項的組合而產(chǎn)生的安全漏洞， 提高安全性； ②精簡協(xié)議格式，降低解析開銷及難度； ③增加 IPsec 標準文檔易讀性。 3.1 精簡操作模式 IPsec安全協(xié)議由 AH、 ESP組成，操作模式分為兩類，那么再與安全協(xié)議組合，操作模 式將達到六類之多， 如圖 4；如果再加上 UDP、TCP穿透 NAT（ Network Address Translation ， 網(wǎng)絡(luò)地址轉(zhuǎn)換）

39、設(shè)備，那么操作模式的類型將更多。如果淘汰傳輸模式 （傳輸模式的工作完 全由隧道模式來完成） ，操作模式選項組合至少要減少一半，如此操作，好處： ①淘汰傳輸模式， 將會減少由于傳輸模式與其它選項的組合而產(chǎn)生的安全漏洞， 提高安 全性； ②淘汰傳輸模式，隧道模式完全代替其工作， IPsec 的保護范圍以及應(yīng)用場景等不會因 此而受影響； ③淘汰傳輸模式，可以降低 IPsec工程實現(xiàn)及維護過程中產(chǎn)生安全漏洞的可能性。 3.2 精簡協(xié)議格式 AH 安全協(xié)

40、議格式： 圖 9 AH 認證頭格式 ESP 安全協(xié)議格式： 圖 10 ESP 封裝安全載荷格式 如圖 9 與圖 10 所示，各主要字段的意義： SPI：是安全參數(shù)索引；與目標地址及安全協(xié)議（ AH 或 ESP）組合使用，以確保通信的 正確安全關(guān)

41、聯(lián)；接收方使用該值確定數(shù)據(jù)包是使用哪一安全關(guān)聯(lián)標識。 序列號：為數(shù)據(jù)包提供抗重播保護；序數(shù)是 32 位、遞增的數(shù)字（從 1 開始），它表示通過通信的安全關(guān)聯(lián)所發(fā)送的數(shù)據(jù)包數(shù)； 在生存期內(nèi)序列號不能重復(fù)； 接收方將檢查該字段，以確認使用該數(shù)字的安全關(guān)聯(lián)數(shù)據(jù)包還沒有被接收過； 如果一個已經(jīng)被接收， 則數(shù)據(jù)包被拒 絕。 驗證數(shù)據(jù)：包含完整性校驗值 (ICV)，也稱為消息身份驗證碼，用于消息身份驗證與完 整性；接收方計算 ICV 值并對照發(fā)送方計算的值校驗它，以驗證完整性。 載荷長度：表示 AH 報頭的長度。

42、 下一個頭（或首部） ：標識受保護數(shù)據(jù)的第一個頭。 根據(jù)圖 4 的封包格式可以看出，如果是傳輸模式， AH 的“下一個首部”與 ESP的“下 一個頭”都要填 IP 數(shù)據(jù)部分的 TCP/UDP/ICMP等的類型； 由于在一個 session（即一次 IPsec 應(yīng)用）中， AH 或 ESP接下來的 IP 數(shù)據(jù)報頭會隨著業(yè) 務(wù)的不同而不同 （如，在這個 session 中，時而是 TCP業(yè)務(wù)、時而是 UDP業(yè)務(wù)、時而是 ICMP 業(yè)務(wù)等等），而且高級協(xié)議在未來的發(fā)展中很有可能出現(xiàn)新的協(xié)議類型，為了在一個

43、 中區(qū)分不同的高級協(xié)議業(yè)務(wù)，而且對未來高級協(xié)議發(fā)展的兼容，傳輸模式（保護高級協(xié)議） 有必要保留“下一個頭（或首部） “這一字段。  session 但是如果是隧道模式， AH 的“下一個首部”與  ESP的“下一個頭”必須要填  4（ IPv4） 或 41（ IPv6），這是 IP 網(wǎng)絡(luò)通信未來可以確定的事實。 如果現(xiàn)在及未來 IP 報文只有 IPv4 與 IPv6（這已經(jīng)是不爭的事實） ，而且某一應(yīng)用環(huán)境一 旦確定將是長期的，所以在隧道

44、模式下完全可以通過 SA 協(xié)商來確定是 IPv4 環(huán)境還是 IPv6 環(huán)境，沒必要每一個報文都要攜帶“下一個頭（或首部） ”；如此操作，完全沒有必要保留 " 下一個頭（或首部） "字段而增加網(wǎng)絡(luò)開銷加大解析難度。 根據(jù)以上分析，淘汰傳輸模式， “下一個頭（或首部） ”字段只填寫 IP 協(xié)議號；而且 IP 協(xié)議類型可以通過 SA協(xié)議來確定；所以淘汰傳輸模式，安全協(xié)議格式就可以去掉“下一個 頭（或首部） ”，減少解析開銷及難度。 3.3 去除通信主機分離 IPsec 標準文檔把通信主機分離成

45、主機和安全網(wǎng)關(guān)，原因是安全網(wǎng)關(guān)可能不需要傳輸模 式；如果淘汰傳輸模式， 那么就沒有必要進行這種分離； 通信主機間是對等的，都是通過隧 道進行端到端通信；標準文檔在描述上就變得清晰易懂。 4. 結(jié)論 我們假設(shè)系統(tǒng)有 n 個不同的選項，每個都有兩個可能的選擇，那么就有 n(n-1)/2=O(n2) 種不同對的選擇以不可預(yù)料的方式進行互動，總共就有 2n 不同的配置。每一種可能的互動 都會導(dǎo)致安全漏洞， 涉及幾種選擇的可能的復(fù)雜互動數(shù)目巨大， 因此我們可以預(yù)見到實際的 安全漏洞隨著復(fù)雜性的不斷增加會變得更多。 IPsec 包含有太多的選項和太多的靈活性，實現(xiàn)同樣的或類似的功能通常有好幾種方式 （如主機間安全通信既可以使用隧道模式也可以使用傳輸模式） ，這樣的膨脹和復(fù)雜對于一 個安全性的標準，將是毀滅性的危害。 淘汰傳輸模式，對于 IPsec功能和安全并沒有損失；但從復(fù)雜性的角度來看，有效提高 了系統(tǒng)的安全性。所以， 根據(jù)以上的分析給出建議：淘汰傳輸模式，傳輸模式的工作都由隧 道模式來接管。