手工建立SA存在配置復雜、不支持發起方地址動態變化、永不老化、不利於安全等缺點。本節介紹動態協商的好處以及IKE和IPSec之間的關系。
(1)降低了配置的復雜度。在IKE動態協商模式下，SPI、認證密鑰、加密密鑰等參數會自動生成，而在手動模式下，需要根據SA出方向和入方向分別指定。
(2)提供防重放功能。IPSec使用AH或ESP報頭中的序列號來實現防重放(不接受具有相同序列號的數據包)。當AH或ESP頭中的序列號溢出時(已經達到最大值，不能再向下編號，需要新壹輪的重新編號)，為了實現防重放，需要重新建立SA，這個過程需要IKE協議的配合，所以手動模式下不支持防重放功能。
(3)支持協商發起方(如PPP)地址的動態變化。E-dial接入互聯網)，手動模式不支持，只能應用於兩端都通過專線接入互聯網的情況。
(4)支持在線認證和認證中心(CA)對對等體身份的集中管理，有利於IPSec的大規模部署，但手動模式不支持在線認證。
(5)通過IKE協商建立的s a具有生命周期，可以實時更新，降低了SA被破解的風險，提高了安全性。
當生命周期到達指定時間或指定流程時，SA將失效。在SA過期之前，IKE將為對等方協商壹個新的SA。在新的SA被協商之後，對等體立即采用新的SA來保護通信。有兩種方法來定義生命周期:
IKE協議基於isakmp(互聯網安全協會和密鑰管理協議)定義的框架。它是基於UDP(對應UDP500端口)的應用層協議。它為IPSec提供了自動協商和交換密鑰並建立SA的服務，可以簡化IPSec的使用和管理。
其實IKE並不是壹個單獨的協議，它包括三個協議:isakmp(互聯網安全協會和密鑰管理協議)、oakley (oakley密鑰確定協議，Aulick密鑰確定協議)和skeme(互聯網安全密鑰交換機制)。ISAKMP主要定義IKE對等體之間的合作關系，建立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應用方案之所以能在公網(如互聯網)上安全通信，重要原因是在隧道建立和對等體間數據傳輸的整個過程中，它能得到各種安全機制的保障。在這方面，如果使用IKE進行自動密鑰交換和協商也可以做到，因為IKE本身有壹套自我保護機制，可以在不安全的網絡上安全地進行身份認證和密鑰分發。具體體現在以下幾個方面的安全防護。
在使用IKE進行對等體之間的信息交換時，首先要識別對方的合法性，也就是身份認證問題。在IKE中，可用於確定對等體身份(對等體的IP地址或名稱)的機制相對全面，包括預共享密鑰PSK(預共享密鑰)認證、rsa數字證書(rsa-signature，或RSA數字簽名)認證和RSA數字信封認證。
在數字信封中，發送方使用壹個對稱密鑰(發送方需要事先隨機生成壹個對稱密鑰)對要發送的消息進行數字簽名，然後用接收方的公鑰對這個對稱密鑰進行加密(這部分稱為數字信封)，再將加密後的對稱密鑰和數字簽名的消息壹起發送給接收方。接收方收到後，首先用自己的私鑰打開數字信封，得到發送方的對稱密鑰，然後用對稱密鑰解密原來經過數字簽名的消息，驗證發送方的數字簽名是否正確。如果正確，則認證通過；否則，身份驗證失敗。
對於預共享密鑰認證方法，當壹個對等點對應多個對等點時，需要為每個對等點配置預共享密鑰，工作量較大，因此這種方法在小型網絡中容易建立，但安全性較低。使用數字證書安全性高，但需要CA頒發數字證書，適合在大型網絡中使用。當設備需要滿足國家密碼管理局的要求時使用數字信封認證(需要使用國家密碼管理局要求的hash算法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使用12位的密鑰。它們之間的安全性從高到低的順序是:sm3 >；SHA2-512 & gt；SHA2-384 & gt；SHA2-256 & gt；sha 1 & gt；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都使用65442。這些加密算法的安全級別從高到低的順序是:sm4 >；SMI 1 & gt；AES-256 & gt；AES-192 >AES-128 >3DES & gt推薦DES、AES-256、AES-192和AES-128，但不推薦3DES和DES算法，SM1和SM4由於運算速度慢，只推薦在保密性和安全性要求非常高的地方使用。非對稱密鑰系統通常采用RSA或DSA(數字簽名算法)加密算法。
Diffie-HeLlman算法是壹種公鑰算法。通信雙方僅通過交換壹些數據就可以計算出雙方共享的密鑰，而不需要傳輸密鑰。而且可以做到，即使第三方截獲了雙方用來計算密鑰的所有交換數據，也不足以計算出真正的密鑰。
DH主要用於在IKE動態協商時重新生成新IPSec SA使用的密鑰，因為它可以通過壹系列的數據交換最終計算出雙方共享的密鑰，而不依賴於前期生成的密鑰生成材料。但是DH並沒有提供任何關於雙方身份的信息，所以無法確定交換的數據是否會發送給合法方。第三方可以通過截獲的數據與雙方協商密鑰，從而享受通信，從而獲取和傳輸信息。因此，IKE還需要身份認證來認證對等體的身份。
PFS(完美前向保密)是壹種安全特性，也就是說壹個密鑰被破解後，不會影響其他密鑰的安全性，因為這些密鑰之間沒有衍生關系。
從本章後面的介紹中可以看出，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的建立過程有兩種交換模式:主模式和聚集模式。下面分別介紹。
在IKEv1主模式下建立IKE SA的過程中，有三次雙向消息交換，使用了六條信息。交換過程如圖所示。
這六條消息實際上壹般是三個步驟，每個步驟包含兩條編號相鄰的消息。
第壹步對應消息①和②，是指隧道兩端的對等體通過交換彼此配置的IKE策略，約定彼此要采用的IKE安全策略，因為只有雙方采用相同的安全策略，才能識別對方的加密數據，正確認證對方的身份。
第二步對應於消息③和④，即對等體交換參數信息(DH public value和nonce等。)通過DH算法，建立壹系列兩端相同的* * *共享密鑰，主要包括用於第二階段協商的身份認證密鑰和協商數據的加密密鑰。
第三步對應於消息⑤和⑤，使用之前創建的加密密鑰將自己的身份(如IP地址或對等體名稱)和認證數據(如采用的認證方法中的密鑰或證書數據)發送給對方，並采用相應的認證方法在對等體之間進行身份認證。最後，IKE SA的建立完成。
在正式的消息交換之前，發起方和接收方必須首先計算自己的cookie(在ISKMP頭中，可以防止重放和DoS攻擊)，這些cookie用於標識每個單獨的協商交換消息。RFC建議對源/目標IP地址、源/目標端口號、本地生成的隨機數、日期和時間進行哈希處理，以生成cookie。cookie成為IKE協商中交換信息的唯壹標識，IKEv1版本中的Cookie，IKEv2版本中的Cookie是IKE的SPI(安全參數索引)。
下面詳細介紹壹下上面提到的六條消息。
如圖所示，savage模式僅使用三條信息。消息①和②用於對等體之間協商IKE安全策略，交換DH公鑰、必要的輔助信息和身份信息(通常不是用IP地址標識，而是用主機名標識)。
與主模式相比，可以發現savage模式減少了交換信息的數量，提高了協商速度，但是它並沒有對身份信息和認證數據進行加密，因為雙方在發送身份信息時都沒有加密(對應於消息①和②)(但是主模式下發送的身份信息和認證數據是加密的，對應於消息⑤和⑤)。雖然野人模式不提供身份保護，但還是可以滿足壹些特定的網絡環境需求。
當IPSec隧道中有NAT設備時，需要開啟NAT穿越功能，NAT轉換會改變對端的IP地址。由於savage模式不依賴於IP地址識別，所以只有采用預共享密鑰認證方式，才能在savage模式下實現NAT穿越。如果發起方的P地址不固定或者不可預測，雙方都想用預* *密鑰認證方式創建IKE SA，那就只能用野蠻模式了。
如果發起方知道響應方的策略，或者對響應方的策略有全面的了解，使用野蠻模式可以更快地創建IKE SA。
ikev1的第二階段是在第壹階段的基礎上最終建立壹對sa，第壹階段只有壹種模式，即快速模式。快速模式協商受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還可以防禦拒絕服務攻擊。在IKEv1中，當網絡中的攻擊者不斷重放消息時，響應者需要經過計算後才能響應，這就消耗了設備資源，造成了對響應者的DoS攻擊。而在KEv2中，響應方收到請求後並不急於計算，而是先向發起方發送壹個cookie類型的Notify載荷(即壹個特定值)，兩者之間的通信必須保持Fcookie與發起方的對應關系，有效防禦DoS攻擊。
IKEv2定義了三種類型的交換:初始交換、創建子服務協議交換(Create _Child _SA交換)和信息交換。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保護)或sub-SA(交換受sub-SA保護)。