IPsec協議總結

1、IPsec 基本介紹

1.1 ipsec基本數據

1.2 ipsec 封裝模式

• 傳輸模式
  傳輸模式在AH、ESP處理前後IP頭部保持不變，主要用於End-to-End的應用場景。
  
• 隧道模式
  隧道模式則在AH、ESP處理之後再封裝了一個外網IP頭，主要用於Site-to-Site的應用場景
  

  1.3 主動模式交互流程

2 隧道模式下基本的封裝和姐封裝流程

2.1 封裝流程

• 在原IP報文中找到TCP報文部分，在其後添加相應的ESP trailer信息。
  ESP trailer 包含三部分：Padding，Pad length 和 Next header。Padding 即使用塊加密時，最後一個數據塊長度不足時所做的填充。Pad length 指填充的長度，方便拆包時找到用來填充的數據段。Next header 標明被封裝的原報文的協議類型，例如 6 = TCP。
• 將原 TCP 報文和第1步得到的 ESP trailer 作爲一個整體進行加密封裝。具體的加密算法和**由SA給出。
• 爲第2步得到的密文添加 ESP 頭。ESP 頭由 SPI (Security Parameter Index) 和 Seq #
  兩部分組成。密文和 ESP頭合起來稱爲"enchilada"，構成認證部分。
• 附加完整性度量結果（ICV）。對第3步生成的"enchilada"認證部分做摘要（ESP Authentication
  Data），得到一個32位整數倍的 ICV，附在"enchilada"之後。ICV 生成算法和驗證**由 SA 給出。
• 將原始的 IP 報文頭中的協議號改爲50（代表 ESP），然後將 IP 報文頭加到第4步的結果之前構成 IPsec 報文。

2.2 解封裝流程

• 接收方收到 IP 報文後，發現協議類型是50，標明這是一個 ESP 包。首先查看 ESP 頭，通過安全參數索引號 SPI
  決定數據報文所對應的 SA，獲得對應的模式（隧道或傳輸模式）以及安全規範。
• 根據 SA 指定的摘要算法和驗證**計算"enchilada"的摘要值，與附在 IP 報文最後的 ICV
  進行對比，二者相同則數據完整性未被破壞。
• 檢查 ESP 頭中的 Seq # 裏的***，保證數據是新的，避免重放攻擊
• 根據 SA 所指定的加密算法和**，解密密文段，得到原來的 TCP 報文和 ESP trailer。
• 根據 ESP trailer 的填充長度信息，找出填充字段的長度，刪除填充字段得到原來的 TCP 報文。 根據 TCP
• 報文頭信息將報文交付給傳輸層。

ipsec 在穿透NAT的特殊處理

這個IPsec過程分兩類報文，一類是IKE報文，一類是ESP報文。然後我們拋開ESP報文不討論。現在，這個現象是這樣的。除了第一次交互（也就是前兩個包）使用500端口之外。之後的所以報文都使用4500端口進行通信。
即使是在發送IKE的rekey或reauth時，也使用4500端口。也就是說500端口，後續的報文序列裏再也不會使用了。

當使用4500承載的時候，IKE報文頭與UDP報文頭之間，會插入4個字節的0，用來區分ESP報文和IKE報文。

1. 由UDP4500承載的ESP報文。2. 由UDP4500承載的IKE報文。3.由UDP500承載的IKE報文。
   然後我們假設不使用4500端口，而全部使用500端口來承載。之後會發生什麼？ 首先，NAT設備是沒有問題的，對於我們這裏討論或假設的任何場景。
   它都可以處理，而且NAT設備也不關心500是不是知名端口，也不對其進行特殊處理。
   好，然後，這三種報文都由UDP 500端口來承載。這個時候操作系統收到了udp 500的包的時候是沒有辦法區分出它到底是IKE還是ESP的。
   於是，我們面臨一個選擇。
   A：讓操作系統首先進入IKE報文的處理流程，然後爲ESP報文加一個特殊的MARK，從而進行區分，識別到ESP報文。
   B：讓操作系統首先進入ESP報文的處理流程，然後爲IKE報文加一個特殊的MARK，從而進行區分，識別到IKE報文。
   最終，這個選擇裏，RFC們選擇了B。理由是ESP報文的數量遠遠多餘IKE報文。在每一個包上加mark（也就是四個字節的0）作爲一種資源消耗。兩種陷害擇其輕，自然便選擇了IKE。
   參考資料：
2. IPSec v*n基本原理
3. IPSec方案部署
4. IPSec穿越NAT
5. IPSec拆包及封包流程（重要）
6. PSec NAT-T技術實現nat穿越
7. IPsec在NAT環境中應用
8. 華爲ipsec配置介紹