IKEv1協議分爲兩個階段。階段1（Phase 1）用來建立IKE SA安全關聯；階段2（Phase 2）用來建立IPSec SA安全關聯，前者有兩種模式：主模式與野蠻模式。後者有快速模式（Quick mode）完成。
階段1（Phase 1）其中主模式下共由3組報文組成，Phase1建立的IKE SA主要用來保護階段2的協商過程，以及保護狀態信息等的報文傳輸。主模式（Main Mode）的第一組報文用來協商加密及完整性校驗等參數：
有如下日誌log信息可見，responder回覆的協商結果：加密算法使用3DES_CBC、哈希算法採用SHA、認證方法爲預共享密鑰、Diffie-Hellman組選用5（1536-bit modulus對應DH Group 5）。
ike 0: comes 192.168.1.97:500->192.168.1.127:500,ifindex=4....
ike v1: responder: main mode get first message...
ike v1: negotiation result
ike v1: proposal id = 1:
ike v1: protocol id = ISAKMP:
ike v1: trans_id = KEY_IKE.
ike v1: encapsulation = IKE/none
ike v1: type=OAKLEY_ENCRYPT_ALG, val=3DES_CBC.
ike v1: type=OAKLEY_HASH_ALG, val=SHA.
ike v1: type=AUTH_METHOD, val=PRESHARED_KEY.
ike v1: type=OAKLEY_GROUP, val=1536.
ike v1: ISKAMP SA lifetime=28800
ike v1: selected NAT-T version: RFC 3947
ike v1: cookie c8de607e668cc6ef/e5a5cd77892a7659
ike v1: sent IKE msg : 192.168.1.127:500->192.168.1.97:500, len=120
主模式的第二組報文，主要用於交換各自的KE（Key Exchange）與NONCE數據，這兩個數據用來生成之後使用的加密主密鑰（SKEYID），生成過程中將使用第一組報文協商一致後的加密/完整性校驗參數，SKEYID生成公式如下：
預共享密鑰方式：
SKEYID = prf（pre-shared_key, Nonce_initiator | Nonce_responder）
證書方式：
SKEYID = prf（HASH（Nonce_initiator | Nonce_responder）， Cookie_initiator | Cookie_responder）
其中prf爲帶祕鑰的哈希函數（pseudo-random function），Nonce_initiator和Nonce_responder分別爲IKE請求發起者的NONCE值與響應者的NONCE值。
根據主密鑰（SKEYID），生成其它三個祕鑰：
SKEYID_d 用於IKE階段2
SKEYID_a 用於數據完整性校驗
SKEYID_e 用於加密IKE消息
以下爲日誌信息，自此組報文之後的報文都爲加密報文：
ike 0: comes 192.168.1.97:500->192.168.1.127:500,ifindex=4....
ike v1: responder:main mode get 2nd message...
ike v1: NAT not detected
ike v1: sent IKE msg : 192.168.1.127:500->192.168.1.97:500, len=292
ike v1: ISAKMP SA c8de607e668cc6ef/e5a5cd77892a7659 key 24:5886A076EACF9F262C12907359E4F3AB565503F4D7F71094
Main模式的第三組報文，使用SKEYID_e祕鑰加密傳輸，其主要內容爲ID字段與一個HASH值字段。哈希值字段將選取之前的報文中的一些字段生成，目的在於可驗證之前的傳輸是否正常以及做身份認證。其包含的字段有第一組報文交換中的兩個Cookie值（Cookie_i與Cookie_r）和安全關聯（SA）載荷；第二組報文中的兩個Key Exchange數據；第三組報文中自身的ID值；以及主密鑰（SKEYID）。
如下日誌信息顯示，預共享祕鑰認證成功。
ike 0: comes 192.168.1.97:500->192.168.1.127:500,ifindex=4....
ike v1: responder: main mode get third message...
ike v1: PSK authentication succeeded
ike v1: authentication OK
ike v1: sent IKE msg : 192.168.1.127:500->192.168.1.97:500, len=68
ike v1: established IKE SA c8de607e668cc6ef/e5a5cd77892a7659
階段2用於建立IPSec SA，其採用快模式Quick Mode。快模式所有的報文都使用第一階段生成的祕鑰SKEYID_e進行加密，並且使用祕鑰SKEYID_a進行完整性校驗。加密算法與驗證算法都採用第一階段協商的結果。 Quick模式有3個報文組成。
第一個報文用於協商安全關聯提議（SA Proposal）與數據加密轉換集（Transformset），用於包含此數據包完整性的hash值計算如下：
HASH = prf ( SKEYID_a, M-ID | SA Proposal | Nonce_i | (KE) | (CID_I) | (CID_r))
此HASH算法的祕鑰爲SKEYID_a，M-ID爲ISAKMP報文頭中的Message-ID值，此值在快模式的三個報文中相同，標識同一個IPSec SA的建立。Nonce_i爲隨機數。KE（Key Exchange Data）與 CID_i、CID_r（Client ID）都爲可選值，依據配置而定。如果開啓PFS（Perfect Forward Security），就需要KE字段，以便重新生成新的祕鑰。
粗略的講，最後得到的哈希值大致爲整個報文的HASH值。
ike 0: comes 192.168.1.97:500->192.168.1.127:500,ifindex=4....
ike 0: responder received first quick-mode message
ike v1:p2: peer proposal is: peer:0:0.0.0.0-255.255.255.255:0, me:0:0.0.0.0-255.255.255.255:0
ike v1:p2: matched phase2
ike v1:p2: our proposal:
ike v1:p2: proposal id = 1:
ike v1:p2: protocol id = IPSEC_ESP:
ike v1:p2: PFS DH group = 5
ike v1:p2: trans_id = ESP_3DES
ike v1:p2: encapsulation = ENCAPSULATION_MODE_TUNNEL
ike v1:p2: type = AUTH_ALG, val=SHA1
ike v1:p2: trans_id = ESP_AES (key_len = 128)
ike v1:p2: encapsulation = ENCAPSULATION_MODE_TUNNEL
ike v1:p2: type = AUTH_ALG, val=SHA1
ike v1:p2: incoming proposal:
ike v1:p2: proposal id = 1:
ike v1:p2: protocol id = IPSEC_ESP:
ike v1:p2: PFS DH group = 5
ike v1:p2: trans_id = ESP_3DES
ike v1:p2: encapsulation = ENCAPSULATION_MODE_TUNNEL
ike v1:p2: type = AUTH_ALG, val=SHA1
ike v1:p2: trans_id = ESP_AES (key_len = 128)
ike v1:p2: encapsulation = ENCAPSULATION_MODE_TUNNEL
ike v1:p2: type = AUTH_ALG, val=SHA1
ike v1:p2: negotiation result：
ike v1:p2: proposal id = 1:
ike v1:p2: protocol id = IPSEC_ESP:
ike v1:p2: PFS DH group = 5
ike v1:p2: trans_id = ESP_3DES
ike v1:p2: encapsulation = ENCAPSULATION_MODE_TUNNEL
ike v1:p2: type = AUTH_ALG, val=SHA1
ike v1:p2: set pfs=1536
ike v1:p2: using tunnel mode.
ike v1:p2: sent IKE msg : 192.168.1.127:500->192.168.1.97:500, len=356
與報文1類似，第二個回覆報文包括協商後的結果，此報文的HASH值如下，與報文1的hash的唯一不同是隨機數採用Nonce_r：
HASH = prf ( SKEYID_a, M-ID | Nonce_I | SA offer | Nonce_r | (KE) | (CID_i) | (CID_r))
Quick模式的第3個報文確認之前的2個交互報文，其內容僅包括一個HASH值，其值如下：
HASH = prf ( SKEYID_a, 0 | M-ID | Nonce_i | Nonce_r)
ike 0: comes 192.168.1.97:500->192.168.1.127:500,ifindex=4....
ike v1: found 192.168.1.127 4 -> 192.168.1.97:500
ike v1:p2: replay protection enabled
ike v1:p2: SA life soft seconds=1777.
ike v1:p2: SA life hard seconds=1800.
ike v1:p2: IPsec SA selectors #src=1 #dst=1
ike v1:p2: add IPsec SA: SPIs=0dc36847/ebc60db2
ike v1:p2: IPsec SA dec spi 0dc36847 key 24:60B384FEB7463702B30F5DC178A80932A6B2DEE530B2D65C auth 20:DA5DA2B7357A029BF8B8C657EC8F1EF05C779927
ike v1:p2: IPsec SA enc spi ebc60db2 key 24:BDCD7B34121DCE1A2E1E64EF8808FD4A2F9EC05CA660DF80 auth 20:0D9F38476CF79ECCB68AF1E7AFE42DF87C4B0074
ike v1:p2: added IPsec SA: SPIs=0dc36847/ebc60db2
至此IKEv1協議的交互完成，IKE SA與IPSec SA創建完成。