傳輸模式下ESP的裝包與拆包過程 html
1、傳輸模式與隧道模式區別 算法
當IPsec工做在傳輸模式時,新的IP頭並不會被生成,而是採用原來的IP頭,保護的也僅僅是真正傳輸的數據,而不是整個IP報文。在處理方法上,原來的IP報文會先被解開,再在數據前面加上新的ESP協議頭,最後再裝回原來的IP頭,即原來的IP包被修改過再傳輸。測試
2、傳輸模式下ESP包的結構加密
1、裝包過程url
1. 在原IP報文末尾添加尾部(ESP trailer)信息。如上圖所示,尾部包含三部分。由所選加密算法多是塊加密,那麼當最後一塊長度不夠時就須要進行填充(padding),附上填充長度(Pad length)方便解包時順利找出用來填充的那一段數據。而Next header則用來標明被加密的數據報文的類型,例如TCP。 spa
2. 將原IP報文以及第1步獲得的ESP尾部做爲一個總體進行加密。具體的加密算法與密鑰由SA給出。 htm
3. 爲第2步獲得的加密數據添加ESP頭部。如上圖所示,ESP頭由兩部分組成,SPI和序號(Sequence number)。加密數據與ESP頭合稱爲「enchilada」。 blog
4. 附加完整性度量結果(ICV,Integrity check value),採用MAC算法。對第三步獲得的「enchilada」作摘要,獲得一個完整性度量值,並附在ESP報文的尾部,即ESP MAC。 get
5、拿到本來的IP頭。這樣就能夠發送了。同步
2、拆包過程
拆包過程,即處理接受到的數據包。 接收端在收到一個 ESP包以後,若不對這個包進行處理,就沒法得知它究竟處於隧道模式,仍是傳輸模式。根據對這個包進行處理的SA,即可知道它到底處在什麼模式下。 若是收到的IPSec包是一個分段,必須把它保留下來,直到這個包的其餘部分收完爲止。 咱們不能對一個不完整的IPSec包進行處理,由於可能會致使對它施行的初次校檢失敗。 收到 ESP包後,進行的第一件事情是:檢查處理這個包的SA是否存在,這是基本的 IPSec要求,而不是ESP專有的。若是沒有SA,這個包就會被丟棄。只有在SA存在的狀況下,纔可開始進行輸入處理。一旦驗證經過了一個有效的SA,就可用它開始包的處理。
首先檢查序列號。若是這個包的序列號是有效的—也就是說,它不是一個重複(重播)的包,也不是出如今包含在S A中的序列號窗口的右邊—就開始進行處理。因爲E S P身份驗證密文而不是明文,接下來進行的即是對這個包進行身份驗證。利用恰當的密鑰,把這個完整的ESP包(固然除開身份驗證數據)傳遞到驗證器那裏(它取自SA)。若是其結果能與「身份驗證數據」字段中包含的數據相符(將身份驗證算法可能須要的任何分段考慮在內),就可對這個包進行身份驗證。接下來是解密。經過取自SA的密鑰和密碼算法,就可對 ESP包進行解密,這個ESP包在載荷數據開始之處到下一個頭之間。判斷解密成功的一個最簡單的測試是檢驗其填充。因爲填充內容具備決定意義—要麼是一個從1開始的單向遞增的數,要麼經過加密算法來決定—對填充內容進行驗證將決定這個包是否已成功解密。 傳送身份驗證和解密檢查成功以後,就可對結果數據包進行初步的有效性檢驗。若是用 來處理這個數據包的SA代表在某一特定模式下—要麼是通道模式,要麼是傳送模式—只 能處理ESP包,那麼還必須檢驗這個包的適用性。若是這個包與要求的模式不符,就必須把它丟棄。
對傳送模式而言,上層協議頭與IP頭是同步的,ESP頭的下一個頭字段被複制到IP頭的協議字段中,並計算出一個新的IP校驗和;而對通道模式而言,就拋開外部IP頭和ESP頭—咱們須要的是這個解開封裝的包。這時,必須進行另外一個有效性檢驗。
若是它是一個傳送模式包,就會轉讓到一個高一級的協議層—好比TCP或 UDP—由它們對這個包進行處理。
具體步驟:
1. 接收方收到數據報文後,發現協議類型是50,故知道這是一個IPsec包。首先查看ESP頭,經過裏面的SPI決定數據報文所對應的SA。
2. 計算「enchilada」部分的摘要,與附在末尾的ICV作對比,若是同樣的話說明數據是完整的。不然能夠判定所收到的報文已經不是原來的報文了。
3. 檢查Seq裏的順序號,保證數據是「新鮮」的,防止回放攻擊。
4. 根據SA所提供的加密算法和密鑰,解密被加密過的數據,即「enchilada」。獲得原IP報文與ESP尾部(trailer)。
5. 根據ESP尾部裏的填充長度信息,咱們能夠找出填充字段的長度,刪去後就獲得原來 的IP報文。
6. 最後轉讓到一個高一級的協議層—好比TCP或 UDP—由它們對這個包進行處理。
參考資料:
傳輸模式下的ESP拆包裝包過程