手工方式建立SA存在配置復雜、不支持發起方地址動態變化、 建立的SA永不老化、不利於安全性等缺點。本節具體介紹動態協商方式的好處,以及IKE與IPSec的關系。
（1） 降低了配置的復雜度, 在IKE動態協商方式下，SPI, 認證密鑰和加密密鑰等參數將自動生成，而手工方式中需根據SA出方向和入方向分別指定。
（2） 提供抗重放功能, IPSec使用AH或ESP報頭中的序列號實現抗重放(不接受序列號相同的數據包)。當AH或ESP報頭中的序列號溢出（也是達到了最大值，不能再繼續往下編 號，要開始新壹輪的重新編號了）後，為實現抗重放，SA需要重新建立，這個過程需要IKE協議的配合，所以手工方式下不支持抗重放功能。
（3）支持協商發起方地址動態變化情況下（如采用PPP。E撥號方式接入Internet）的身份認證，手工方式不支持，只能適用於在兩端都采用專線連接方式接入Internet情形。
（4）支持認證中心CA （Certificate Authority）在線對對等體身份的認證和集中管理，有利於IPSec的大規模部署，手工方式不支持在線認證方式。
（5）通過IKE協商建立的SA具有生存周期，可以實時更新，降低了SA被破解的風險，提高了安全性。
生存周期到達指定的時間或指定的流量，SA就會失效。在SA快要失效前，IKE將為對等體協商新的SA。在新的SA協商好之後，對等體立即采用新的SA保護通信。生存周期有兩種定義方式：
IKE 協議建立在 ISAKMP （Internet Security Association and Key Management Pr otocol, Internet安全聯盟和密鑰管理協議）定義的框架上，是基於UDP的應用層協議（對應UDP500端口. 它為IPSec提供了自動協商交換密鑰、建立SA的服務，能夠簡化IPSec的使用和管理。
其實IKE也不是壹個單獨的協議，它包括三大協議：ISAKMP （Internet Security Association and Key Management Protocol,因特網安全聯盟和密鑰管理協議），Oakley （Oakley Key Determination Protocol,奧利克密鑰確定協議）和SKEME （Sec ure Key Exchange Mechanism for Internet,因特網安全密鑰交換機制）。ISAKMP主 要定義了IKE對等體（IKE Peer）之間合作關系，建立IKE SA。OakLey協議是壹個產生和交換IPSec密鑰材料並協調IPSec參數的框架（包括支持哪些安全協議）；SKEM E協議決定了IKE密鑰交換的方式，主要采用DH （Diffie-Hellman）算法。
IKE與IPSec （包括AH和ESP協議）的關系如下圖所示，IKE是UDP之上的壹個 應用層協議（AH和ESP是網絡層協議），是IPSec的信令協議；IKE為IPSec協商建立 SA,並把建立的參數及生成的密鑰交給IPSec; IPSec使用IKE建立的SA對IP報文加密 或認證處理。
對等體之間建立壹個IKE SA後，在IKE SA保護了IPSec隧道的情況下，再根據配置的AH、ESP安全協議等參數協商出壹對IPSec SA,用於對等體間的數據在IPSec隧道中的安全數據傳輸。
IKE協議目前有IKEv1和IKEv2兩個版本。IKEv1版本使用兩個階段為IPSec進行密 鑰協商並最終建立IPSec SA。第壹階段，通信雙方協商建立IKE本身使用的安全通道 （即隧道），即建立壹對IKE SA。第二階段，利用這個已通過了認證和安全保護的安全通道建立壹對用於保護隧道中數據安全傳輸的IPSec SA。而IKEv2版本則簡化了協商過程，在壹次協商中可直接產生IPSec的密鑰，生成IPSec SA。
下面先來了解IKE在產生SA （包括IKE SA和IPSec SA）的過程中所用的壹些安全機制，這是後面介紹具體的IKE協商過程中所要用到的。
IPSec應用方案之所以能在公網（如Internet）上安全地進行網絡通信，其重要原因是可在對等體間的整個隧道建立和數據傳輸過程中均有各種安全機制來做保障，這方面如果采用的是IKE來進行自動的密鑰交換和協商同樣可以做到，因為IKE本身就具有壹整套自我保護機制，可以在不安全的網絡上安全地認證身份，分發密鑰。具體體現在以下幾種安全保護方面。
當使用IKE在對等體間進行信息交換時，首先要識別對方的合法性，也就是身份認證問題。在IKE中可用於確定對等體身份（對等體的IP地址或名稱）的機制比較全面，包括預***享密鑰PSK （pre-shared key）認證，RSA數字證書（rsa-signature,或稱RSA數字簽名）認證和RSA數字信封認證。
在數字信封中，發送方采用對稱密鑰（需要發送方事先隨機產生壹個對稱密鑰）來對要發送的報文進行數字簽名，然後將此對稱密鑰用接收方的公鑰來加密 （這部分稱數字信封）之後，再將加密後的對稱密鑰連同經過數字簽名的報文壹起發送給接收方。接收方在收到後，首先用自己的私鑰打開數字信封，即可得到發送方的對稱密鑰，然後再用該對稱密鑰解密原來被數字簽名的報文，驗證發送方的數字簽名是否正確。如果正確，則認證通過；否則認證失敗。
對於預***享密鑰認證方法，當有壹個對等體對應多個對等體時，需要為每個對等體配置預***享的密鑰，工作量大，所以該方法在小型網絡中容易建立，但安全性較低。使用數字證書安全性高，但需要CA來頒發數字證書，適合在大型網絡中使用。而數字信封認證用於設備需要符合國家密碼管理局要求時使用（需要使用國家 密碼管理局要求的哈希算法SM3），且此認證方法只能在IKEv1的主模式協商過程中支持。
以上所提到的用於身份認證的各種密鑰都屬於IKE認證密鑰，支持的算法有： MD5，SHA1， SHA2-256，SHA2-384，SHA2-512，SM3。MD5算法使用128位的密鑰，SHA-1算法使用160位的密鑰，SHA2-256，SHA2-384，SHA2-512分別采用256 位，384位和512位密鑰，SM3使用128位密鑰。它們之間的安全性由高到低順序 是：SM3>SHA2-512>SHA2-384>SHA2-256>SHA1>MD5。 對於普通的安全要求，認證算法推薦使用SHA2-256，SHA2-384和SHA2-512,不推薦使用MD5和SHA1,對於安全性要求特別高的地方，可采用SM3算法。
以上所涉及的身份認證密鑰（包括預***享密鑰，公/私鑰），證書都是作為發送方的“驗證數據”要通過對應方式發給對方予以驗證的。
IPSec的數據加密機制主要用在兩個方面：壹是在IKE協商階段，保護所傳輸的用於身份認證的數據信息（如***享密鑰、證書、認證密鑰等），二是在IPSec隧道建立後保護在隧道中傳輸的用戶數據。但這裏所說的數據加密機制所采用的對稱密鑰機制，即加密和解密采用相同的密鑰，而不是像前面介紹的數字證書身份認證和數字簽名應用中所采用的非對稱密鑰體系。
IKE支持的加密算法包括:DES，3DES，AES-128，AES-192，AES-256，SM1和SM4等。DES算法使用56位密鑰，3DES使用168位密鑰，AES-128，AES-192，AES-256分別使用128，192和256位密鑰，SM1和SM4均使用128位密鑰。這些加密算法的安全級別由高到低的順序是：SM4 > SMI1> AES-256 > AES-192 > AES-128 > 3DES > DES,推薦使用AES-256、AES-192和AES-128,不推薦使用3DES和DES算法， SM1和SM4僅建議在保密及安全性要求非常高的地方采用，因為它們的運算速度比較慢。非對稱密鑰體系中通常使用的是RSA或DSA （Digital Signature Algorithm,數字簽名算法）加密算法。
Diffie-HeLlman算法是壹種公開密鑰算法。通信雙方可在不傳送密鑰的情況下，僅通過交換壹些數據，即可計算出雙方***享的密鑰。而且可以做到，即使第三方截獲了雙方用於計算密鑰的所有交換數據，也不足以計算出真正的密鑰。
DH主要用於IKE動態協商時重新生成新的IPSec SA所用的密鑰，因為它可以通 過壹系列數據的交換，最終計算出雙方***享的密鑰，而不依賴於在前期生成的密鑰生成材料。但DH沒有提供雙方身份的任何信息，不能確定交換的數據是否發送給合法方，第三方可以通過截獲的數據與通信雙方都協商密鑰，***享通信，從而獲取和傳遞信息，所以IKE還需要身份認證來對對等體身份進行認證。
PFS (Perfect Forward Secrecy,完善的前向安全性)是壹種安全特性，指壹個密鑰被破解後並不影響其他密鑰的安全性，因為這些密鑰間沒有派生關系。
由本章後面的介紹就可知道，IPSec SA的密鑰是從IKE SA的密鑰導出的。由於壹個IKE SA協商可生成壹對或多對有壹定派生關系的IPSec SA，所以當IKE的密鑰被竊取後，攻擊者很可能通過收集到足夠的信息來非法導出IPSec SA的密鑰，這樣就不安全了。如果在生成IPSec階段啟用了PFS，即可通過執行壹次額外的DH交換，生成新的，獨立的IPSec SA，這樣就可以保證IPSec SA密鑰的安全了。
上文已提到，IKEvl版本產生最終的IPSecSA是需要經過兩個階段，分別用來建立IKESA和IPSecSA。本節先介紹第壹階段。
IKEvl的第壹階段的最終目的是在對等體之間創建了壹條安全通道，建立對等 體的IKESA。在這個階段中，IKE對等體間彼此驗證對方，並確定***同的會話密 鑰。這個階段需要用到Diffie-Hellman （簡稱DH）算法進行密鑰交換，完成IKE SA 建立，使後面的第二階段過程的協商過程受到安全保護。
在IKEvl版本中，建立IKE SA的過程有主模式（Main Mode）和野蠻模式（Aggr essive Mode,也稱“積極模式”）兩種交換模式。下面分別予以介紹。
在IKEv1的主模式的IKE SA建立過程中，包含三次雙向消息交換，用到了六條信息，交換過程如圖所示。
這6條消息其實總體上是三個步驟，各包含兩條相鄰編號的消息。
第壹個步驟對應的是消息①和②，是隧道兩端對等體間通過交換彼此配置的IKE策略協商好要***同采用的IKE安全策略，因為只有雙方都采用相同的安全策略才能相互識別對方加密的數據，並對對方身份進行正確認證。
第二個步驟對應的是消息③和④，是對等體間通過DH算法交換彼此的密鑰生成所需的參數信息（DH公開值和隨機數nonce等），建立兩端相同的壹系列***享密鑰，主要包括用於在第二階段協商的身份認證密鑰和協商數據的加密密鑰。
第三步對應的是消息⑤和⑥，用前面已創建好的加密密鑰彼此相互發送各自的身份（如對等體的IP地址或名稱）和驗證數據（所采用的身份認證方式中的密鑰， 或證書數據等），采用相應認證方法在對等體間進行身份認證。最終完成IKE SA的建立。
在正式進行消息交換前，發起方和接收方必須先計算出各自的cookie （在ISKMP報頭中，可以防重放和DoS攻擊），這些cookie用於標識每個單獨的協商交換消息。RFC建議將源/目IP地址，源/目端口號，本地生成的隨機數，日期和時間進行散列操作生成cookie。cookie成為在IKE協商中交換信息的唯壹標識，在IKEv1版本中為Cookie, 在IKEv2版本中的Cookie即為IKE的SPI （安全參數索引）。
下面再具體介紹以上所提到的這6條消息。
如圖所示,野蠻模式只用到三條信息,消息①和②用於在對等體間協商IKE安全策略，交換DH公鑰，必需的輔助信息和身份信息(通常不以IP地址進行標識,而是以主機名進行標識的)。
由野蠻模式和主模式的對比可以發現,與主模式相比，野蠻模式減少了交換信息的數目，提高了協商的速度，但是沒有對身份信息和驗證數據進行加密保護，因為雙方在發送身份信息時(對應第①和第②條消息)是不加密的(但主模式中發送的身份信息和驗證數據是加密的，對應第⑤和第⑥條消息)。雖然野蠻模式不提供身份保護，它仍可以滿足某些特定的網絡環境需求。
當IPSec 隧道中存在NAT設備時，需要啟用NAT穿越功能，而NAT轉換會改變對等體的IP地址，由於野蠻模式不依賴於IP地址標識身份，使得如果采用預***享密鑰驗證方法時，NAT穿越只能在野蠻模式中實現。如果發起方的P地址不固定或者無法預知，而雙方都希望采用預***享密鑰驗證方法來創建IKE SA，則只能采用野蠻模式。
如果發起方已知響應方的策略，或者對響應者的策略有全面的了解，采用野蠻模式能夠更快地創建IKE SA.
ikev1版本的第二階段就是要在第壹階段基礎上最終建立壹對SA ,它只有壹種模式,即快速模式(Quick Mode )。快速模式的協商是受SA 保護的,整個協商過程如圖所示。
在快速模式的協商過程中主要是完成以下IPSec 安全策略的確定:
在上述幾方面達成壹致後,將建立起兩個PSec SA ,分別用於入站和出站通信。
在消息①和②中的IPSec安全提議包括了安全協議，spi，IPSec封裝模式，PfS(可選)，IPSec SA生存周期等。這兩條消息中還包括雙方的身份信息(如IP地址，傳輸層端口)，驗證數據(包括所采用的身份認證機制中的密鑰，證書等)，以及nonce (壹個隨機數，用於抗重放，還被用作密碼生成的材料，僅當啟用PFS時用到)。接收方會利用所收到的對方數據生成加密密鑰,消息③為確認消息,通過確認發送方收到該階段的消息②,使響應方獲知可以正式通信了。
IKEv1需要經歷兩個階段,至少交換6條消息才能最終建立壹對PSec SA, 而IKEv2在保證安全性的前提下, 減少了傳遞的信息和交換的次數,實現起來更簡單。
IKEv2保留了IKEv1的大部分特性,而且IKEv1的壹部分擴展特性(如NAT穿越)作為IKEv2協議的組成部分被引入到IKEv2框架中。與IKEV1不同,IKEv2中所有消息都以“請求-響應”的形式成對出現，響應方都要對發起方發送的消息進行確認,如果在規定的時間內沒有收到確認報文,發起方需要對報文進行重傳處理,提高了安全性。
IKEv2還可以防禦DoS攻擊。在IKEv1中,當網絡中的攻擊方壹直重放消息,響應方需要通過計算後,對其進行響應而消耗設備資源,造成對響應方的DoS攻擊。而在KEv2中,響應方收到請求後,並不急於計算,而是先向發起方發送壹個cookie類型的Notify載荷(即壹個特定的數值),兩者之後的通信必須保持Fcookie與發起方之間的對應關系,有效防禦了DoS攻擊。
IKEv2定義了三種交換類型:初始交換(InitialExchanges)，創建子SA交換(Create _Child _SA Exchange)以及通知交換(InformationalExchange)。IKEv2通過初始交換就可以完成壹個IKE SA和第壹對IPSec SA的協商建立。如果要求建立的IPSec SA大於壹對時, 每壹對IPSec SA值只需要額外增加壹次創建子SA交換(而如果采用IKEv1,則子SA 的創建仍然需要經歷兩個階段)。
IKEv2初始交換對應IKEv1的第壹階段，初始交換包含兩次交換四條消息,如圖所示。消息①和②屬於第壹次交換，以明文方式完成IKE SA的參數協商,主要是協商加密算法，交換nonce 值，完成壹次DH交換,從而生成用於加密,並驗證後續交換的密鑰材料。消息③和④屬於第二次交換,以加密方式完成身份認證(通過交換身份信息和驗證數據)，對前兩條信息的認證和IPSec SA的參數協商。
在初始交換完成後,可以由任何壹方發起創建子SA交換,該次交換中的發起者和初始交換中的發起者可能是不同的。該交換必須在初始交換完成後進行,交換消息由初始交換協商的密鑰進行保護。
創建子SA交換包含兩條消息,用於壹個IKE SA創建多個IPSec SA或IKE的重協商,對應IKEv1的第二階段。如果需要支持PFS,創建子SA交換可額外進行壹次DH交換，建立勇於建立IPSEC SA的新密鑰。
通信雙方在密鑰協商期間,某壹方可能希望向對方發送控制信息,通知某些錯誤或者某事件的發生,這就需要由“通知交換過程來完成。
通知交換如圖2-15所示,用於對等體間傳遞壹些控制信息,如錯誤信息,刪除消息,或通知信息。收到信息消息的壹方必須進行響應,響應消息中可能不包含任何載荷。通知交換只能發生在初始交換之後,其控制信息可以是IKE SA的(由IKES A保護該交換),也可以是子SA的(由子SA保護該交換)。