IPsec SA creation steps
There are two steps on the IPsec SA creation, phase 1 is to creat IKE-SA, and phase 2 is to creat IPSEC-SA, the phase2 will be protected by phase 1. phase 1 creat a security tunnel to protect phase2.
step 1: creat IKE-SA, there are two modes on this step, the major is main mode, which including six messages;
1,&2, to negotiate the security policy, 1,initiator send all type policys supported to remote, and if remote search one of them which it support too, it will respone to initiator;
including Authentication method: psk or md5; hash- algorithm : md5 or sha; encryption algorithm :des or 3des ; sa life time (duration) x seconds;
3&4 , to exchange the DH and key, and creat key;
5&6, those two messages had been protected by key_id, to authentication each other;
step2 : craet IPSEC-SA;
1, negotiate the IPSEC-protocol:esp or ah; ipsec-mode:tunnel or transport; hash-algorithm: md5 or sha;
2, ack and ack too .
第一階段
有主模式和積極模式2種
注意!!!只有remote vpn和Easy vpn是積極模式的,其他都是用主模式來協商的
讓IKE對等體彼此驗證對方並確定會話密鑰,這個階段永DH進行密鑰交換,創建完IKE SA後,所有後續的協商都將通過加密合完整性檢查來保護
phase 1幫助在對等體之間創建了一條安全通道,使後面的phase 2過程協商受到安全保護
第二階段
快速模式
協商IPSEC SA使用的安全參數,創建IPSEC SA,使用AH或ESP來加密IP數據流
詳細過程主模式協商
IKE phase 1在IPSEC對等體間交換6條消息,這些消息的具體格式取決於使用的對等體認證方法
一,使用預共享密鑰進行驗證的主模式(6條)
協商過程使用ISAKMP消息格式來傳遞(UDP 500)
第一階段
準備工作
在前2條消息發送以前,發送者和接受者必須先計算出各自的cookie(可以防重放和DOS攻擊),這些cookie用於標識每個單獨的協商交換消息
cookie---RFC建議將源目IP,源目端口,本地生成的隨機數,日期和時間進行散列操作.cookie成爲留在IKE協商中交換信息的唯一標識,實際上cookie是用來防止DOS攻擊的，它把和其他設備建立IPSEC所需要的連接信息不是以緩存的形式保存在路由器裏，而是把這些信息HASH成個cookie值
1&2消息
消息1---發送方向對等體發送一條包含一組或多組策略提議,在策略提議中包括5元組(加密算法,散列算法,DH,認證方法,IKE SA壽命)
1．策略協商，在這一步中，就四個強制性參數值進行協商：
1）加密算法：選擇DES或3DES
2）hash算法：選擇MD5或SHA
3）認證方法：選擇證書認證、預置共享密鑰認證或Kerberos v5認證
4）Diffie-Hellman組的選擇
消息2---接受方查看IKE策略消息,並嘗試在本地尋找與之匹配的策略,找到後,則有一條消息去迴應
注意!!!發起者會將它的所有策略發送給接受者,接受者則在自己的策略中尋找與之匹配的策略(對比順序從優先級號小的到大的)（默認策略實際就是個模版沒作用，如果認證只配置預共享的話，其他參數就會copy默認策略裏的）
在1&2消息中報錯可能出現的原因
1，peer路由不通
2，crypto iskmp key沒有設置
3，一階段的策略不匹配
3&4消息
這2條消息,用於交換DH的公開信息和隨機數
兩個對等體根據DH的公開信息都算出了雙方相等的密植後,兩個nonce連通預共享密鑰生成第一個skeyID
隨後便根據SKEY__ID來推算出其他幾個skeyID
skeyID_d---用來協商出後續IPSEC SA加密使用的密鑰的
skeyID_a---爲後續的IKE消息協商以及IPSEC SA協商進行完整性檢查(HMAC中的密鑰)
skeyID_e---爲後續的IKE消息協商以及IPSEC SA協商進行加密
5&6消息
這2條消息用於雙方彼此驗證,這個過程是受skeyID_e加密保護的
爲了正確生成密鑰,每一個對等體必須找到與對方相對應的預共享密鑰,當有許多對等體連接時,每一對對等體兩端都需要配置預共享密鑰,每一對等體都必須使用ISAKMP分組的源IP來查找與其對等體對應的預共享密鑰(此時由於ID還沒到,彼此先用HASH來彼此驗證對方)
HASH認證成分－－－SKEYID_a,cookieA,cookieB，preshare_key,SA paload,轉換集，策略
在5&6消息中報錯可能出現的原因
1，crypto iskmp key設置錯了
接受者處理過程
1,用skeyID_e對消息進行加密 2,用ID(源IP)查找出與共享密鑰 3,skeyID_a和preshare-key等一堆東西一起來計算HASH 4,和收到的HASH做比較
第二階段(3條)
phase 2的目標是協商IPSEC SA,而且只有一種模式,快速模式,快速模式的協商是受IKE SA保護的
·使用哪種IPSec協議：AH或ESP
·使用哪種hash算法：MD5或SHA
使用什麼模式: 隧道還是傳輸
·是否要求加密，若是，選擇加密算法：3DES或DES 在上述三方面達成一致後，將建立起兩個SA，分別用於入站和出站通信。
1&2消息
消息1---發送方發送一條報文,其中包含HASH,IPSEC策略提議,NONCE和可選的DH,身份ID
HASH:是用於給接受方作完整性檢查的,用於再次認證對等體(必須)HASH的成分和5－6階段一樣
IPSEC策略提議:其中包括了安全協議,SPI,散列算法,隧道模式,IPSEC SA生命週期(必須)
NONCE:用於防重放攻擊,還被用作密碼生成的材料,僅當啓用PFS時用到
ID:描述IPSEC SA是爲哪些地址,協議和端口建立的
PFS(利用DH交換,可選):用了PFS後就會在第二階段重新DH出個數據加密KEY,這個KEY和以前IKE協商出來的KEY沒有任何關係,然後由這個新KEY來加密數據，只有到這個IPSEC SA的生命週期後,會再次DH出新的KEY,這樣,安全性就提高了（普通等ipec SA過期或密鑰超時時，重新生成的數據加密密鑰還是根據以階段DH出來的skeyID_d衍生出來的）（PFS啓用後，數據加密部分使用的密鑰就沒有了衍生的過程）
DH:重新協商IPSEC SA實使用的密鑰(正常情況下IPSEC階段使用的密鑰都是由skeyID_d衍生而來,密鑰之間都有一定的關係,就算IPSEC SA超時,新的KEY還是和skeyID_d有一定的關係)
在1&2消息中報錯可能出現的原因
1，ipsec trasport不匹配
2，感興趣流不對稱