IPsec-傳輸模式可休矣

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

17、模式來專職保護(hù)高層協(xié)議， 從而 增加 IPsec 的復(fù)雜度， 加大由于選項(xiàng)組合產(chǎn)生的安全漏洞風(fēng)險(xiǎn)。 鑒于隧道模式保護(hù)范圍大于 傳輸模式，所以建議淘汰傳輸模式，減少由于操作模式與其它選項(xiàng)組合而產(chǎn)生的安全漏洞， 提高 IPsec 整體框架的安全性。 2.3 操作模式技術(shù)實(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、傳輸模式保護(hù)的是 IP 數(shù)據(jù)，安全協(xié)議頭插在原 IP 頭和 IP 數(shù)據(jù)之間； 2、隧道模式保護(hù)的是 IP 分組，安全協(xié)議的頭前增加新的 IP 頭。 但是我們不知道這樣做的目的是什么。 如果把傳輸模式進(jìn)行隧道化， 那么隧道模式的封 裝就會(huì)出現(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)變成一模一樣了， 只是在 帶寬上，傳輸模式隧道化后會(huì)比原傳輸模式多消耗一個(gè) IP 頭的開銷。

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

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

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 報(bào)頭長(zhǎng)為 20 字節(jié)； IPv6 報(bào)頭長(zhǎng)為 40 字節(jié)； TCP報(bào)頭長(zhǎng) 20 字節(jié)； UDP 報(bào)頭 長(zhǎng) 8

24、字節(jié)； ② IP 報(bào)頭壓縮，壓縮的是 IPv4/IPv6 和 TCP/UDP報(bào)頭。 從表 1 中可以看出，隧道模式 +IP 報(bào)頭壓縮對(duì)網(wǎng)絡(luò)帶寬的開銷遠(yuǎn)遠(yuǎn)小于傳輸模式對(duì)網(wǎng)絡(luò) 帶寬的開銷；傳輸模式對(duì)網(wǎng)絡(luò)僅僅減少了一個(gè) 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ò)開銷對(duì)比 如圖 6 ，從對(duì)網(wǎng)絡(luò)開銷上來看，帶 IP 壓縮的隧道模式對(duì)網(wǎng)絡(luò)的開銷低于傳輸模式。 這時(shí)候，還會(huì)有人提到傳輸模式的 IP 數(shù)據(jù)報(bào)頭如 TCP/UDP報(bào)頭也可以使用壓縮技術(shù)實(shí) 現(xiàn)網(wǎng)絡(luò)帶寬開銷的減少呀！這種觀點(diǎn)也站不住腳

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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