【文章內(nèi)容簡介】 然而，如果該包在傳送的過程中經(jīng)過 NAT（ Network Address Translation，網(wǎng)絡(luò)地址轉(zhuǎn)換）網(wǎng)關(guān)，其源 /目的 IP地址將被改變，將造成到達目的地址后的完整性驗證失敗。因此，AH在傳輸模式下和 NAT是沖突的， 不能同時使用，或者可以說 AH不能穿越 NAT。 2022/8/27 網(wǎng)絡(luò)安全 李章兵 40 在隧道模式中， AH插入到原始 IP頭部字段之前，然后在 AH之前再增加一個新的 IP頭部。以 TCP為例，圖 AH在隧道模式中的位置。 2022/8/27 網(wǎng)絡(luò)安全 李章兵 41 圖 AH隧道模式 2022/8/27 網(wǎng)絡(luò)安全 李章兵 42 隧道模式下， AH驗證的范圍也是整個 IP包 ，因此上面討論的 AH和 NAT的沖突 在隧道模式下也存在。 在隧道模式中， AH可以單獨使用，也 可以和 ESP一起嵌套使用。 2022/8/27 網(wǎng)絡(luò)安全 李章兵 43 在應(yīng)用 AH進行處理時，相應(yīng)的 SA應(yīng)該已經(jīng)建立，因此 AH所用到的 HMAC算法和密鑰已經(jīng)確定 。從上面的傳輸模式和隧道模式可以看出， AH協(xié)議驗證的范圍包括整個 IP包，驗證過程概括如下： 在發(fā)送方，整個 IP包和驗證密鑰被作為輸入，經(jīng)過 HMAC算法計算后得到的結(jié)果被填充到 AH頭部的“驗證數(shù)據(jù)”字段中；在接收方，整個 IP包和驗證算法所用的密鑰也被作為輸入，經(jīng)過 HMAC算法計算的結(jié)果和 AH頭部的“驗證數(shù)據(jù)”字段進行比較，如果一致，說明該 IP包數(shù)據(jù)沒有被篡改 ，內(nèi)容是真實可信的。 數(shù)據(jù)完整性檢查 2022/8/27 網(wǎng)絡(luò)安全 李章兵 44 在應(yīng)用 HMAC算法時，有一些因素需要考慮。在 IP字段中，有一些是可變的，而且在傳輸過程中被修改也是合理的，不能說明該數(shù)據(jù)包是被非法篡改的。這些字段 在計算 HMAC時被臨時用 0填充 ，具本包括如下。 ToS（ Type of Service）： 8位的服務(wù)類型字段指出了延時、吞吐量和可靠性方面的要求。某些路由器會修改該字段以達到 特定的 QoS服務(wù)質(zhì)量 。 標(biāo)志字段： 這是指用于表示分片的 3位標(biāo)志 —— DF（ Don’t Fragment）、 MF（ More Fragments）和0。 路由器可能會修改這 3個標(biāo)志 。 2022/8/27 網(wǎng)絡(luò)安全 李章兵 45 分片偏移字段： 標(biāo)志字段后面的 13位的偏移字段。 TTL： 生命期，為了防止 IP包的無限次路由，每經(jīng)過一個路由器，該字段減 1，當(dāng) TTL變?yōu)?0時，被路由器拋棄。 頭部校驗和：中間路由器對 IP包頭部作了任何修改之后，必須 重新計算頭部校驗和 ，因此該字段也是可變的。 選項字段。 另外， AH頭部的驗證數(shù)據(jù)字段在計算之前也要用 0填充，計算之后再填充驗證結(jié)果 。 2022/8/27 網(wǎng)絡(luò)安全 李章兵 46 對于一個 IP包，除上述可變字段外，其余部分都認為是應(yīng)該不變的，這些部分也正是受到 AH協(xié)議保護的部分。具體來說，這些不變的部分包括如下。 版本字段。 頭部長度字段。 IP總長字段。 ID字段。 協(xié)議字段。 源 IP地址字段。 目的地址字段。 AH頭中除“驗證數(shù)據(jù)”以外的其他字段。 2022/8/27 網(wǎng)絡(luò)安全 李章兵 47 數(shù)據(jù)：指經(jīng)過 AH處理之后，在 AH頭部后面的數(shù)據(jù)。 傳輸方式下，指 TCP、 UDP或 ICMP等傳輸層數(shù)據(jù)；隧道模式下，指被封裝的原 IP包。 2022/8/27 網(wǎng)絡(luò)安全 李章兵 48 與 AH一樣， ESP（ Encapsulating Security Payload， 封裝安全載荷 ） 協(xié)議 也是一種增強 IP層安全的 IPSec協(xié)議，由 RFC2406定義。 ESP協(xié)議除了可以 提供無連接的完整性、數(shù)據(jù)來源驗證和抗重放攻擊服務(wù) 之外，還 提供數(shù)據(jù)包加密和數(shù)據(jù)流加密服務(wù) 。 IPSec安全協(xié)議 —— ESP ESP概述 2022/8/27 網(wǎng)絡(luò)安全 李章兵 49 ESP協(xié)議提供數(shù)據(jù)完整性和數(shù)據(jù)來源驗證的原理和AH一樣，也是通過驗證算法實現(xiàn)。然而，與 AH相比，ESP驗證的數(shù)據(jù)范圍要小一些。 ESP協(xié)議規(guī)定了所有 IPSec系統(tǒng)必須實現(xiàn)的驗證算法： HMACMDHMACSHA NULL。 NULL認證算法是指實際不進行認證。 數(shù)據(jù)包加密服務(wù) 通過 對單個 IP包或 IP包載荷應(yīng)用加密算法 實現(xiàn)； 數(shù)據(jù)流加密 是 通過隧道模式下對整個 IP包應(yīng)用加密算法實現(xiàn)。 ESP的加密 采用的是對稱密鑰 加密算法。與公鑰加密算法相比，對稱加密算法可以提供更大的加密 /解密吞吐量。不同的 IPSec實現(xiàn)，其加密算法也有所不同。為了保證互操作性，ESP協(xié)議規(guī)定了所有 IPSec系統(tǒng)都必須實現(xiàn)的算法：DESCBC、 NULL。 NULL加密算法是指實際不進行加密。 2022/8/27 網(wǎng)絡(luò)安全 李章兵 50 之所以有 NULL算法，是因為加密和認證都是可選的，但是 ESP協(xié)議 規(guī)定加密和認證不能同時為 NULL。 換句話說，如果采用 ESP，加密和認證至少必選其一，當(dāng)然也可以二者都選，但是不能二者都不選。 2022/8/27 網(wǎng)絡(luò)安全 李章兵 51 ESP協(xié)議和 TCP、 UDP、 AH協(xié)議一樣，是被 IP協(xié)議封裝的協(xié)議之一。一個 IP包的載荷是否是 ESP協(xié)議，由 IP協(xié)議頭部中的 協(xié)議字段判斷， ESP協(xié)議字段是 50。如果一個 IP包封裝的是 ESP協(xié)議，在 IP包頭（包括選項字段）后面緊跟的就是 ESP協(xié)議頭部，格式如圖 。ESP頭部格式包括以下內(nèi)容。 ESP頭部格式 2022/8/27 網(wǎng)絡(luò)安全 李章兵 52 圖 ESP頭部格式 2022/8/27 網(wǎng)絡(luò)安全 李章兵 53 （ 1） SPI SPI是一個 32位整數(shù)，與源 /目的 IP地址、IPSec協(xié)議一起組成的三元組可以為該 IP包惟一地確定一個 SA。 （ 2） 序列號（ Sequence Number） 序列號是一個 32位整數(shù)，作為一個 單調(diào)遞增的計數(shù)器，為每個 ESP包賦予一個序號 。當(dāng)通信雙方建立 SA時， 計數(shù)器初始化為 0。 SA是單向的，每發(fā)送一個包，外出 SA的計數(shù)器增 1；每接收一個包，進入 SA的計數(shù)器增 1。該字段可以 用于抵抗重放攻擊。 2022/8/27 網(wǎng)絡(luò)安全 李章兵 54 （ 3） 載荷數(shù)據(jù)（ Payload Data） 這是變長字段，包含了實際的載荷數(shù)據(jù)。不管 SA是否需要加密，該字段總是必需的。如果采用了加密，該部分就是加密后的密文；如果沒有加密，該部分就是明文。如果采用的加密算法需要一個 IV（ Initial Vector，初始向量）， IV也是在本字段中傳輸?shù)摹Ｔ摷用芩惴ǖ囊?guī)范必須能夠指明 IV的長度以及在本字段中的位置。本字段的長度必須是 8位的整數(shù)倍。 （ 4） 填充（ Padding） 填充字段包含了填充位。 （ 5） 填充長度（ Pad Length） 填充長度字段是一個 8位字段，以字節(jié)為單位指示了填充字段的長度，其范圍為 [0， 255]。 2022/8/27 網(wǎng)絡(luò)安全 李章兵 55 （ 6） 下一個頭（ Next Header） 8位字段，指明了封裝在載荷中的數(shù)據(jù)類型，例如 6表示 TCP數(shù)據(jù)。 （ 7） 驗證數(shù)據(jù)（ Authentication Data） 變長字段。只有選擇了驗證服務(wù)時才會有該字段，包含了驗證的結(jié)果。 2022/8/27 網(wǎng)絡(luò)安全 李章兵 56 和 AH一樣， ESP也有兩種運行模式：傳輸模式和隧道模式。 運行模式?jīng)Q定了 ESP插入的位置以及保護的對象。 ESP運行模式 2022/8/27 網(wǎng)絡(luò)安全 李章兵 57 傳輸模式保護的是 IP包的載荷 ，例如 TCP、UDP、 ICMP等，也可以是其他 IPSec協(xié)議的頭部。 ESP插入到 IP頭部 （含選項字段） 之后，任何被 IP協(xié)議所 封裝的協(xié)議 （如傳輸層協(xié)議TCP、 UDP、 ICMP，或者 IPSec協(xié)議） 之前。以 TCP為例，圖 ESP傳輸模式前后的 IP包格式。 2022/8/27 網(wǎng)絡(luò)安全 李章兵 58 圖 ESP傳輸模式 2022/8/27 網(wǎng)絡(luò)安全 李章兵 59 在圖 ， ESP頭部包含 SPI和序號字段 ， ESP尾部包含填充、填充長度和下一個頭字段 。被加密和被驗證的區(qū)域在圖中已經(jīng)表示出來了。 如果使用了加密， SPI和序號字段不能被加密 。首先，在接收端， SPI字段用于和源 IP地址、 IPSec協(xié)議一起組成一個三元組來惟一確定一個 SA，利用該SA進行驗證、解密等后續(xù)處理。如果 SPI被加密了，要解密之就必須找到 SA，而查找 SA又需要 SPI，這樣就產(chǎn)生了類似于“先有雞還是先有雞蛋”的問題。因此， SPI不能被加密。其次， 序號字段用于判斷包是否重復(fù)，從而可以防止重放攻擊。 序號字段不會泄漏明文中的任何機密，沒有必要進行加密。不加密序號字段也使得一個包不經(jīng)過繁瑣的解密過程就可以判斷包是否重復(fù)，如果重復(fù)則丟棄之，節(jié)省了時間和資源。 2022/8/27 網(wǎng)絡(luò)安全 李章兵 60 如果使用了驗證， 驗證數(shù)據(jù)也不會被加密 ，因為如果 SA需要 ESP的驗證服務(wù)，那么接收端會在進行任何后續(xù)處理（例如檢查重放、解密）之前進行驗證。數(shù)據(jù)包只有經(jīng)過驗證證明該包沒有經(jīng)過任何修改，是可以信任的，才會進行后續(xù)處理。 值得注意的是， 和 AH不同， ESP的驗證不會對整個 IP包進行驗證 ， IP包頭部（含選項字段）不會被驗證。 因此， ESP不存在像 AH那樣的和 NAT模式?jīng)_突的問題。 如果通信的任何一方具有私有地址或者在安全網(wǎng)關(guān)背后，雙方的通信仍然可以用 ESP來保護其安全，因為 IP頭部中的源 /目的 IP地址和其他字段不被驗證， 可以被 NAT網(wǎng)關(guān)或者安全網(wǎng)關(guān)修改。 2022/8/27 網(wǎng)絡(luò)安全 李章兵 61 當(dāng)然， ESP在驗證上的這種靈活性也有缺點：除了 ESP頭部之外，任何 IP頭部字段都可以修改， 只要保證其校