從宏觀上來看，ISAKMP主要做了三件事情：
1. SA協商
2. 密鑰交換
3. 認證
SA協商的目的是爲了在通信雙方間協商出一組雙方都認可的安全參數。比如兩端採用相同的加密算法和完整性算法。
密鑰交換的目的是爲已經協商好的算法生成必要的密鑰信息。
認證的目的是鑑別對方的身份，保證自己不是在跟一個僞造的對象通信。
一般有兩種方式。第一種叫做密鑰傳輸，第二種叫做密鑰生成。
密鑰生成與密鑰傳輸有着本質的不同。由於密鑰是不在網絡上傳輸的，這樣，即便一個攻擊者截取了密鑰交換信息，也無法取得密鑰。密鑰生成通常使用Diffie-Hellman算法。首先通信的雙方各自獨立的生成一個私鑰，記爲Xi和Xr。然後利用Xi和Xr生成可以公開的密鑰信息Yi和Yr。雙方交換Yi和Yr，於是發起端擁有Xi和Yr，而接收端擁有Yi和Xr。利用這些信息和DH算法，兩端就可以生成相同的密鑰。
DH算法最大的一個缺陷在於，它無法防止中間人攻擊，因此需要認證。
ISAKMP一般使用UDP傳輸，port爲500；
2.SA - Security Association
SA是IPsec的基礎。IPsec在兩個端點（end point）之間提供安全通信，SA是兩個端點之間某些參數的約定。
比如：
- 使用哪種協議，AH，ESP，還是二者同時；
- 認證算法，MD5，還是SHA1等；
- 加密算法，DES，3DES，還是其它；
- 協議的封裝模式，傳輸模式還是隧道模式；
- 特定流中的Key，以及Key的生存週期；
SA是單向的，連個端點需要雙向通信時，至少需要一對SA；
如果需要同時使用AH和ESP，那麼每個端點都需要針對AH和ESP建立單獨的SA，即雙向通信時需要2對SA；
SA的建立方式：
- 手工建立；
- IKE自動協商建立；
SA的生存週期
- 手工建立，永久的；
- IKE自動建立的SA，有兩種生存週期，基於時間的和基於流量的，分別在達到一定時長或者流量的情況下過期；
3. AH和ESP
AH（authentication header）和ESP（Encapsulating Security Payload）用於提供安全服務。
IPsec協議中的：
AH協議定義了認證的應用方法，提供數據源認證和完整性保證；IP協議號爲51，認證算法有MD5，SHA1等；
ESP協議定義了加密和可選認證的應用方法，提供數據可靠性保證；IP協議號爲50，加密算法有DES，3DES，AES等，作爲可選項，可以使用MD5，SHA1等進行認證；
AH和ESP都可以提供認證服務，不過，AH提供的認證服務要強於ESP。同時使用AH和ESP時，設備支持的AH和ESP聯合使用的方式爲：先對報文進行ESP封裝，再對報文進行AH封裝，封裝之後的報文從內到外依次是原始IP報文、ESP頭、AH頭和外部IP頭。
AH：
next hdr 下一個報頭：使用 IP 協議 ID來標識 IP 負載,。從下圖可知，表示被AH協議包含的那一個協議的類型。例如，TCP數據中，傳輸模式值 6 表示 TCP，隧道模式表示下一個報頭爲IP報頭。
AH len 長度：表示 AH 報頭的長度。
Reserved 保留字段
SPI 安全參數索引 ：與目標地址及安全協議（AH 或 ESP）組合使用，以確保通信的正確安全關聯。接收方使用該值確定數據包是使用哪一安全關聯標識的。
Sequence Number 序數 ：爲該數據包提供抗重播保護。序數是 32 位、遞增的數字（從 1 開始），它表示通過通信的安全關聯所發送的數據包數。在快速模式安全關聯的生存期內序列號不能重複。接收方將檢查該字段，以確認使用該數字的安全關聯數據包還沒有被接收過。如果一個已經被接收，則數據包被拒絕。
Authentication Data 身份驗證數據 ：包含完整性校驗值 (ICV)，也稱爲消息身份驗證碼，用於驗證消息身份驗證與完整性。接收方計算 ICV 值並對照發送方計算的值校驗它，以驗證完整性。ICV 是通過 IP 報頭、AH 報頭與 IP 負載來計算的。AH可對整個數據包（IP 報頭與數據包中的數據負載）提供身份驗證、完整性與抗重播保護。所以不論是傳輸模式還是隧道模式，AH協議都不能穿越nat設備。
下圖中黃色部分表示被AH協議簽名保護的部分。
ipsec協議的操作模式
在傳輸模式下，AH或 ESP被插入到IP頭之後但在所有傳輸層協議之前，或所有其他 IPSec協議之前。
在隧道模式下，AH或 ESP插在原始 IP頭之前，另外生成一個新IP頭放到 AH或 ESP之前。不同安全協議在傳輸模式和隧道模式下的數據封裝形式（傳輸協議以 TCP爲例）如下圖所示：
ESP：
封閉安全載荷ESP包格式
ESP不僅爲IP 負載提供身份驗證、完整性和抗重播保護，還提供機密性。傳輸模式中的
ESP 不對整個數據包進行簽名。只對IP 負載（而不對IP 報頭）進行保護。ESP
可以獨立使用，也可與 AH 組合使用。
ESP屬於IPSec的一種協議，ESP提供機密性、數據起源驗證、無連接的完整性、抗重播服務和有限業務流機密性。ESP本身是一個IP協議，協議號是50。
SPI 安全參數索引（32位）：這個值，和IP頭之前的目標地址以及協議結合在一起，用來標識用於處理數據包的特定的那個安全關聯。SPI本身是個任意數，一般是在IKE交換過程中由目標主機選定的。
Sequence Number 序列號（32位）：序列號是一個獨一無二的、單向遞增的、並由發送端插在ESP頭的一個號碼。發送方的計數器和接收方的計數器在一個SA建立時被初始化爲0，使用給定SA發送的第一個分組的序列號爲1，如果激活抗重播服務（默認地），傳送的序列號不允許循環。因此，在SA上傳送第232個分組之前，發送方計數器和接收方計數器必須重新置位（通過建立新SA和獲取新密鑰），序列號使ESP具有了抵抗重播攻擊的能力。
受保護數據（可變）：通過加密保護的傳輸層協議內容（傳輸模式）或IP包（隧道模式）。如果受保護數據需要加密同步數據，那麼初始化向量IV可以在受保護數據字段的開頭攜帶，並且IV通常不加密，但經常被看作是密文的一部分。
填充（0~255字節）：主要用於加密算法要求明文使某個數目字節的倍數、保證填充長度字段和下一個頭字段排列在32位字的右邊、提供部分業務流機密性。
填充長度（8位）：指出填充字節的數目。
下一個頭（8位）：標識受保護數據的第一個協議頭。例如，IPv6中的擴展頭或者上層協議標識符。
驗證數據（可變）：完整性檢查值。驗證數據是可變長字段，它包含一個完整性校驗值（ICV），ESP分組中該值的計算不包含驗證數據本身。字段長度由選擇的驗證函數指定。驗證數據字段是可選的，只有SA選擇驗證服務，才包含驗證數據字段。驗證算法規範必須指定ICV長度、驗證的比較規則和處理步驟。
ESP 驗證尾端（即上面的驗證數據）包含下列字段：
身份驗證數據：包含完整性校驗值 (ICV)，也稱爲消息身份驗證碼，用於驗證消息身份驗證與完整性。接收方計算 ICV 值並對照發送方計算的值校驗它，以驗證完整性。ICV 是通過 ESP 報頭、負載數據與 ESP 尾端計算的。
數據包簽名與加密：ESP 可爲 IP 負載提供保護。數據包的簽名部分表示數據包的完整性和身份驗證簽名是在哪裏進行的。數據包的加密部分表示什麼信息受到機密性保護。
ESP在傳輸模式時會保護TCP/UDP頭，但是並不保護IP 頭，因此修改IP 地址並不會破壞整個數據包的完整性。但是如果數據包是TCP/UDP數據包，NAT設備就需要修改數據包的校驗值，而這個校驗值是被ESP 所保護的，這樣卻會導致完整性校驗失敗。所以ESP在傳輸模式不能用於NAT穿越。
ESP在隧道模式下， NAT會修改新增的IP頭，新增IP協議的數據時ESP，就不需要想TCP/UDP一樣修改ESP的驗證，所以最終能和NAT一起工作的只能是隧道模式下的ESP。
