剛接觸IPSec的時候，一直很奇怪，為什么要做兩階段的協商？先協商出來一個IKE SA，然后再IKE SA的基礎上協商出來一個IPSec SA。直接一步到位協商出IPSec SA不是很好嗎？但是在實際應用中，直接協商IPSec SA就顯得不是那么有效率了。打個比方，某公司A有個子公司B，為了方便子公司B的員工訪問總公司A的內部數據，在雙方的安全網關上部署VPN，使用IPSec進行數據加密。如果雙方都使用IKEv1，而且只有一個協商階段，直接協商出IPSec SA，那么每一次協商可能都需要6個Main Mode消息和3個Quick Mode消息。這樣會產生大量的協商消息，降低了網絡的利用率。而如果采用兩階段協商，只需要在網關間協商出一個IKE SA，然后用這個SA來為應用數據流協商IPSec SA，那么每個IPSec SA只需要一個Quick Mode即可。所以，兩階段的好處在於，可以通過第一階段協商出IKE SA用作IPSec SA協商的載體，從而減少IPSec SA協商的開銷。
那么IKE SA和IPSec SA的區別在哪兒呢？從定義上來看，IKE SA負責IPSec SA的建立和維護，起控制作用；IPSec SA負責具體的數據流加密。比如一個HTTP請求，可能最終需要用到IPSec SA定義的ESP協議和相關ESP加密算法。
IKE SA和IPSec SA協商的內容也是不一樣的，如下：
1. IKEv1的IKE SA協商內容
參考：http://www.iana.org/assignments/ipsec-registry
a. 加密算法
b. 哈希算法
c. 認證方法 - 如證書認證、Pre-shared Key
d. PRF算法 - 用來產生加解密密鑰
e. DH算法和參數
f. Key長度 - 某些算法，如AES-CBC的key長度是可變的，可以通過Attribute來協商Key長度
g. SA的生存時間
2. IKEv2的IKE SA協商內容
參考：http://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xml
a. 加密算法
b. PRF算法
c. Integrity算法
d. DH算法
e. ESN - Extended Sequence Numbers
3. IPSec SA的協商內容
參考：http://www.iana.org/assignments/isakmp-registry
a. ESP加密算法或AH完整性算法
b. 加密模式
c. 認證算法
d. SA生存時間
e. 壓縮算法
f. DH算法和參數
g. 加密密鑰長度
h. 認證密鑰長度
以上均有部分內容是可選的，不是所有的參數都必須協商。上面的三個鏈接里都詳細描述了IANA對每個階段SA協商用到的參數，比如算法的編號等等。
轉載自：https://blog.csdn.net/jiangwlee/article/details/7395903