An exploration of the Internet Key Exchange (IKE) version 1, IKE version 2, and the different modes in which it operates, aggressive, main and quick.
We will step through the operation of IKEv1 aggressive mode going through an actual example; the establishment of an IKEv1 aggressive mode security association between SRX-11 and SRX-13. Both boxes will be using their loopback addresses of 192.168.11.11 and 192.168.13.13 respectively for the endpoints of the SA.
For aggressive mode, we need a couple of slight changes to our IKE configuration sections for both of the SRX boxes involved.
IKEv1 Aggressive Mode Configuration for SRX-11
[edit security ike]
juniper@SRX-11# show
traceoptions {
file ike.log size 10m;
flag ike;
}
proposal IKE-PROPOSAL {
authentication-method pre-shared-keys;
dh-group group1;
authentication-algorithm md5;
encryption-algorithm 3des-cbc;
lifetime-seconds 86400;
}
policy IKE-POLICY {
mode aggressive;
proposals IKE-PROPOSAL;
pre-shared-key ascii-text "$9$iqPQ/CuEclFnclKMN-HqmfFn9ApBRh"; ## SECRET-DATA
}
gateway SRX-13 {
ike-policy IKE-POLICY;
address 192.168.13.13;
external-interface lo0.0;
version v1-only;
}
[edit security ike]
juniper@SRX-11#
IKEv1 Aggressive Mode Configuration for SRX-13
[edit security ike]
juniper@SRX-13# show
traceoptions {
file ike.log size 10m;
flag ike;
}
proposal IKE-PROPOSAL {
authentication-method pre-shared-keys;
dh-group group1;
authentication-algorithm md5;
encryption-algorithm 3des-cbc;
lifetime-seconds 86400;
}
policy IKE-POLICY {
mode aggressive;
proposals IKE-PROPOSAL;
pre-shared-key ascii-text "$9$cberK8-VYZUHX7UHqmF3SrevX7dbs4JG"; ## SECRET-DATA
}
gateway SRX-11 {
ike-policy IKE-POLICY;
address 192.168.11.11;
external-interface lo0.0;
version v1-only;
}
[edit security ike]
juniper@SRX-13#
After committing the changes on both SRXes, and firing off an IKEv1 SA using SRX-11 as the inititator in the conversation we have the following security associations as reported by the SRX boxen.
Phase 1 IKE SA on SRX-11
juniper@SRX-11> show security ike security-associations detail
IKE peer 192.168.13.13, Index 2291736, Gateway Name: SRX-13
Role: Initiator, State: UP
Initiator cookie: 186650cdf4b0f99f, Responder cookie: bea34b61b26a5758
Exchange type: Aggressive, Authentication method: Pre-shared-keys
Local: 192.168.11.11:500, Remote: 192.168.13.13:500
Lifetime: Expires in 86365 seconds
Peer ike-id: 192.168.13.13
Xauth assigned IP: 0.0.0.0
Algorithms:
Authentication : hmac-md5-96
Encryption : 3des-cbc
Pseudo random function: hmac-md5
Diffie-Hellman group : DH-group-1
Traffic statistics:
Input bytes : 528
Output bytes : 740
Input packets: 2
Output packets: 4
Flags: IKE SA is created
IPSec security associations: 1 created, 0 deleted
Phase 2 negotiations in progress: 0
Negotiation type: Quick mode, Role: Initiator, Message ID: 0
Local: 192.168.11.11:500, Remote: 192.168.13.13:500
Local identity: 192.168.11.11
Remote identity: 192.168.13.13
Flags: IKE SA is created
juniper@SRX-11>
Phase 1 IKE SA on SRX-13
juniper@SRX-13> show security ike security-associations detail
IKE peer 192.168.11.11, Index 8353493, Gateway Name: SRX-11
Role: Responder, State: UP
Initiator cookie: 186650cdf4b0f99f, Responder cookie: bea34b61b26a5758
Exchange type: Aggressive, Authentication method: Pre-shared-keys
Local: 192.168.13.13:500, Remote: 192.168.11.11:500
Lifetime: Expires in 86382 seconds
Peer ike-id: 192.168.11.11
Xauth assigned IP: 0.0.0.0
Algorithms:
Authentication : hmac-md5-96
Encryption : 3des-cbc
Pseudo random function: hmac-md5
Diffie-Hellman group : DH-group-1
Traffic statistics:
Input bytes : 740
Output bytes : 528
Input packets: 4
Output packets: 2
Flags: IKE SA is created
IPSec security associations: 1 created, 0 deleted
Phase 2 negotiations in progress: 0
Negotiation type: Quick mode, Role: Responder, Message ID: 0
Local: 192.168.13.13:500, Remote: 192.168.11.11:500
Local identity: 192.168.13.13
Remote identity: 192.168.11.11
Flags: IKE SA is created
juniper@SRX-13>
As we go through this example, we're going to dig through a packet capture of the entire exchange, and crawl through the logs line by line. You can download a packet capture of the entire IKEv1 aggressive mode exchange with pre-shared keys, the IKE logs from the initiator SRX-11 and the IKE logs from the responder SRX-13 in order to parse through.
It begins the same as main mode did (the following paragraph is almost a verbatim recap of main mode): One of the peers, the initiator, deciding that it wants to establish and IKE security association with it's peer -- the responder. In this example, SRX-11 using it loopback address of 192.168.11.11, initiates the session to SRX-13's loopback address of 192.168.13.13.
[Feb 13 05:37:30][192.168.11.11 <-> 192.168.13.13] Received IKE Trigger message with local_gw_addr = 11.11.168.192 remote_gw_addr = 13.13.168.192 [Feb 13 05:37:30][192.168.11.11 <-> 192.168.13.13] In iked_async_ike_trigger_msg_handler; Tunnel = 131073 [Feb 13 05:37:30][192.168.11.11 <-> 192.168.13.13] Triggering the IKE negotiation .... [Feb 13 05:37:30][192.168.11.11 <-> 192.168.13.13] Triggering negotiation for SRX-13 config block [Feb 13 05:37:30][192.168.11.11 <-> 192.168.13.13] iked_pm_trigger_callback: lookup peer entry for gateway SRX-13, local_port=500, remote_port=500 [Feb 13 05:37:30][192.168.11.11 <-> 192.168.13.13] Initiating new P1 SA for gateway SRX-13
The initiator creates a proto SA locally.
[Feb 13 05:37:30][192.168.11.11 <-> 192.168.13.13] ssh_ikev2_ike_sa_allocate: Allocating IKE SA 192.168.13.13;500/4500 [Feb 13 05:37:30][192.168.11.11 <-> 192.168.13.13] Allocated IKE SA index 2291736, ref cnt 0 [Feb 13 05:37:30][192.168.11.11 <-> 192.168.13.13] ikev2_ike_sa_alloc_cb: Allocated IKE SA 8c76400 I186650cd f4b0f99f (192.168.13.13;500/4500) [Feb 13 05:37:30][192.168.11.11 <-> 192.168.13.13] ssh_ikev2_ipsec_create_sa: State = IKE_INIT_SA
The first half of the proto SA is identified by the initiator's cookie: 0x8c76400 I186650cdf4b0f99f which is allocated above. This cookie has exactly the same purpose as it did in main mode: The SRX notes that it only has half of a Phase 1 security association at this point, because it is the initiator; it leaves a field for the responder's cookie padded with zeros. The cookie is used for session identification and as a DoS mitigation technique. The cookie is essentially a random number or a hash derived from some unique system components. The ISAKMP RFC2408 suggests to create a hash from the senders IP address and the destination IP address, port numbers and a locally generated random secret. The cookies will be placed in the ISAKMP header and will be used by both peers to associate incoming ISAKMP packets with the SA that is being setup as part of the IKEv1 exchange.
In aggressive mode, the initiator doesn't wait for the responder to accept a proposal, then do an orderly Diffie-Hellman-Merkel key exchange, and then encrypt it's identity. The initiators identity, the Diffie-Hellman-Merkel public key, and the cryptographic nonce are all sent in the first packet along with the proposal items. All of this is sent in the clear, including the initiators identity. There is only one proposal that is sent. If more than one proposal is desired for an aggressive mode exchange, separate packets attempting to setup and SA need to be sent with different proposals until a reply is received (indicating the one that is agreed upon.)
We can see all of this happening in the logs. In fact, the first thing the SRX is doing is packaging up it's identity:
[Feb 13 05:37:30][192.168.11.11 <-> 192.168.13.13] ikev2_fb_id_request_cb: Local id payload is ID(type = ipv4 (1), len = 4, value = 192.168.11.11) [Feb 13 05:37:30][192.168.11.11 <-> 192.168.13.13] ikev2_fb_idv2_to_idv1: Converting the IKEv2 payload ID ID(type = ipv4 (1), len = 4, value = 192.168.11.11) to IKEv1 ID [Feb 13 05:37:30][192.168.11.11 <-> 192.168.13.13] ikev2_fb_idv2_to_idv1: IKEv2 payload ID converted to IKEv1 payload ID ipv4(any:0,[0..3]=192.168.11.11)
Next it's starting to collect data for the initial packet in the IKE.
[Feb 13 05:37:30][192.168.11.11 <-> 192.168.13.13] Parsing notification payload for local:192.168.11.11, remote:192.168.13.13 IKEv1 [Feb 13 05:37:30][192.168.11.11 <-> 192.168.13.13] iked_pm_ike_spd_notify_request: Sending Initial contact
It allocates the SA, with the second half zero'd out as it doesn't have it's peer's cookie yet.
[Feb 13 05:37:30][192.168.11.11 <-> 192.168.13.13] Initiator's proposing IKE SA payload SA()
[Feb 13 05:37:30][192.168.11.11 <-> 192.168.13.13] ssh_ike_connect: Start, remote_name = 192.168.13.13:500, xchg = 4, flags = 00040000
[Feb 13 05:37:30][192.168.11.11 <-> 192.168.13.13] ike_sa_allocate_half: Start
[Feb 13 05:37:30][192.168.11.11 <-> 192.168.13.13] ike_sa_allocate: Start, SA = { 186650cd f4b0f99f - 00000000 00000000 }
It pulls the attributes from the configuration for it's peer to build the proposal. The IANA Internet Key Exchange (IKE) Attributes can be referenced to decode all of the values -- or you can take my word for it and beleive me that the types and values align with the IKE proposal above.
[Feb 13 05:37:31][192.168.11.11 <-> 192.168.13.13] ssh_ike_get_data_attribute_int: get_int: type = 1 (0x0001), value = 5 (0x00000005), len = 2 (0x0002)
[Feb 13 05:37:31][192.168.11.11 <-> 192.168.13.13] ssh_ike_get_data_attribute_int: get_int: type = 4 (0x0004), value = 1 (0x00000001), len = 2 (0x0002)
[Feb 13 05:37:31][192.168.11.11 <-> 192.168.13.13] ssh_ike_get_data_attribute_int: get_int: type = 2 (0x0002), value = 1 (0x00000001), len = 2 (0x0002)
[Feb 13 05:37:31][192.168.11.11 <-> 192.168.13.13] ssh_ike_get_data_attribute_int: get_int: type = 11 (0x000b), value = 1 (0x00000001), len = 2 (0x0002)
[Feb 13 05:37:31][192.168.11.11 <-> 192.168.13.13] ssh_ike_get_data_attribute_int: get_int: type = 12 (0x000c), value = 86400 (0x00015180), len = 4 (0x0004)
[Feb 13 05:37:31][192.168.11.11 <-> 192.168.13.13] ssh_ike_get_data_attribute_int: get_int: type = 3 (0x0003), value = 1 (0x00000001), len = 2 (0x0002)
[Feb 13 05:37:31][192.168.11.11 <-> 192.168.13.13] ssh_ike_connect: SA = { 186650cd f4b0f99f - 00000000 00000000}, nego = -1
[Feb 13 05:37:31][192.168.11.11 <-> 192.168.13.13] ike_state_step: Current state = Start sa negotiation I (1)/-1, exchange = 4, auth_method = pre shared key, Initiator
[Feb 13 05:37:31][192.168.11.11 <-> 192.168.13.13] ike_state_step: Matched state = Start sa negotiation I (1)
[Feb 13 05:37:31][192.168.11.11 <-> 192.168.13.13] ike_state_step: Calling output function[0] = ike_st_o_sa_proposal
[Feb 13 05:37:31][192.168.11.11 <-> 192.168.13.13] ike_st_o_sa_proposal: Start
Right away aggressive mode generates it's Diffie-Hellman-Merkel secret and public values, and generates a nonce to help prevent replay attacks.
[Feb 13 05:37:31][192.168.11.11 <-> 192.168.13.13] Using software for dh_gen operation [Feb 13 05:37:31][192.168.11.11 <-> 192.168.13.13] Inside kmd_sw_dh_gen... [Feb 13 05:37:31][192.168.11.11 <-> 192.168.13.13] ike_state_step: Calling output function[2] = ike_st_o_nonce [Feb 13 05:37:31][192.168.11.11 <-> 192.168.13.13] ike_st_o_nonce: Start [Feb 13 05:37:31][192.168.11.11 <-> 192.168.13.13] ikev2_fb_isakmp_nonce_data_len: Entered [Feb 13 05:37:31][192.168.11.11 <-> 192.168.13.13] ike_policy_reply_isakmp_nonce_data_len: Start
It packages up it's identity.
[Feb 13 05:37:31][192.168.11.11 <-> 192.168.13.13] ike_state_step: Calling output function[3] = ike_st_o_id [Feb 13 05:37:31][192.168.11.11 <-> 192.168.13.13] ike_st_o_id: Start
Appends some vendor ID payloads for the various IKEv1 extensions.
[Feb 13 05:37:31][192.168.11.11 <-> 192.168.13.13] ike_state_step: Calling output function[4] = ike_st_o_vids [Feb 13 05:37:31][192.168.11.11 <-> 192.168.13.13] ikev2_fb_isakmp_request_vendor_ids: Request vendor ID's policy call entered, IKE SA 8c76400 (neg 8c7a800) [Feb 13 05:37:31][192.168.11.11 <-> 192.168.13.13] ikev2_fb_isakmp_request_vendor_ids: FB; Calling v2 policy function vendor_id_request [Feb 13 05:37:31][192.168.11.11 <-> 192.168.13.13] ikev2_fb_vid_request_cb: Got a VID of length 16 (neg 8c7a800) [Feb 13 05:37:31][192.168.11.11 <-> 192.168.13.13] iked_pm_ike_request_vendor_id: Sending VID RFC 3706 (Dead Peer Detection) [Feb 13 05:37:31][192.168.11.11 <-> 192.168.13.13] ikev2_fb_vid_request_cb: Got a VID of length 16 (neg 8c7a800) [Feb 13 05:37:31][192.168.11.11 <-> 192.168.13.13] iked_pm_ike_request_vendor_id: Sending VID draft-stenberg-ipsec-nat-traversal-01 [Feb 13 05:37:31][192.168.11.11 <-> 192.168.13.13] ikev2_fb_vid_request_cb: Got a VID of length 16 (neg 8c7a800) [Feb 13 05:37:31][192.168.11.11 <-> 192.168.13.13] iked_pm_ike_request_vendor_id: Sending VID draft-stenberg-ipsec-nat-traversal-02 [Feb 13 05:37:31][192.168.11.11 <-> 192.168.13.13] ikev2_fb_vid_request_cb: Got a VID of length 16 (neg 8c7a800) [Feb 13 05:37:31][192.168.11.11 <-> 192.168.13.13] iked_pm_ike_request_vendor_id: Sending VID draft-ietf-ipsec-nat-t-ike-00 [Feb 13 05:37:31][192.168.11.11 <-> 192.168.13.13] ikev2_fb_vid_request_cb: Got a VID of length 16 (neg 8c7a800) [Feb 13 05:37:31][192.168.11.11 <-> 192.168.13.13] iked_pm_ike_request_vendor_id: Sending VID draft-ietf-ipsec-nat-t-ike-02 [Feb 13 05:37:31][192.168.11.11 <-> 192.168.13.13] ikev2_fb_vid_request_cb: Got a VID of length 16 (neg 8c7a800) [Feb 13 05:37:31][192.168.11.11 <-> 192.168.13.13] iked_pm_ike_request_vendor_id: Sending VID draft-ietf-ipsec-nat-t-ike-02 [Feb 13 05:37:31][192.168.11.11 <-> 192.168.13.13] ikev2_fb_vid_request_cb: Got a VID of length 16 (neg 8c7a800) [Feb 13 05:37:31][192.168.11.11 <-> 192.168.13.13] iked_pm_ike_request_vendor_id: Sending VID draft-ietf-ipsec-nat-t-ike-03 [Feb 13 05:37:31][192.168.11.11 <-> 192.168.13.13] ikev2_fb_vid_request_cb: Got a VID of length 16 (neg 8c7a800) [Feb 13 05:37:31][192.168.11.11 <-> 192.168.13.13] iked_pm_ike_request_vendor_id: Sending VID RFC 3947 [Feb 13 05:37:31][192.168.11.11 <-> 192.168.13.13] ikev2_fb_vid_request_cb: Got a VID of length 28 (neg 8c7a800) [Feb 13 05:37:31][192.168.11.11 <-> 192.168.13.13] iked_pm_ike_request_vendor_id: Sending VID NetScreen Technologies [Feb 13 05:37:31][192.168.11.11 <-> 192.168.13.13] ikev2_fb_vid_request_cb: No more VIDs [Feb 13 05:37:31][192.168.11.11 <-> 192.168.13.13] ike_policy_reply_isakmp_vendor_ids: Start [Feb 13 05:37:31][192.168.11.11 <-> 192.168.13.13] ike_state_step: Calling output function[5] = ike_st_o_private [Feb 13 05:37:31][192.168.11.11 <-> 192.168.13.13] ike_st_o_private: Start
Next it packages up all of this information into nice ISAKMP payloads to be packetized.
[Feb 13 05:37:31][192.168.11.11 <-> 192.168.13.13] ike_encode_packet: Start, SA = { 0x186650cd f4b0f99f - 00000000 00000000 } / 00000000, nego = -1
[Feb 13 05:37:31][192.168.11.11 <-> 192.168.13.13] ike_encode_packet: Final length = 416
We summarize these actions performed in a nice little FSM box.
IKEv1 Aggressive Mode Finite State Machine Step 1
Then the initiator sends the first packet out. It is important to note that nothing is encrypted at this stage, but the initiator's identity has already been sent in the clear.
[Feb 13 05:37:31][192.168.11.11 <-> 192.168.13.13] ike_send_packet: Start, send SA = { 186650cd f4b0f99f - 00000000 00000000}, nego = -1, dst = 192.168.13.13:500, routing table id = 0
Packet #1: Initial ISAKMP packet sent to responder in aggressive mode. Click on the packet to download it. View it with tcpdump, Wireshark or Cloudshark.
The responder recieves the first packet in the exchange, and finds that it needs to create a new SA as it is being asked to bring up a new session using aggressive mode.
[Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] *** Processing received packet from 192.168.11.11:500 to 192.168.13.13:0 VR 0
[Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ikev2_packet_st_input_start: [8c11c00/0] Processing received
[Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] Failed to find IKEv1 SA for given spi
[Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ikev2_packet_st_input_v1_create_sa: [8c11c00/0] No IKE SA for packet; requesting permission to create one.
[Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] New connection from 192.168.11.11:500 allowed
[Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ikev2_packet_st_connect_decision: [8c11c00/0] Pad allows connection
[Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ikev2_packet_v1_start: Passing IKE v1.0 packet to IKEv1 library
[Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ike_udp_callback_common: Packet from 192.168.11.11:500, use_natt=0 data[0..416] = 186650cd f4b0f99f 00000000 00000000 ...
[Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ike_get_sa: Start, SA = { 186650cd f4b0f99f - 00000000 00000000 } / 00000000, remote = 192.168.11.11:500
[Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ike_get_sa: We are responder and this is initiators first packet
The responder creates it's own cookie to complete the SA identifier.
[Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ike_cookie_create: Cookie create
[Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] 00000000: 9ea3 e190 edaf 8fa0 ........
[Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ike_sa_allocate: Start, SA = { 186650cd f4b0f99f - 9ea3e190 edaf8fa0 }
[Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ike_udp_callback_common: New SA
It then proceeds to parse through the packet contents, identifying the payloads. See RFC 2408 Section 3.1 to cross reference the payload types.
[Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ike_decode_packet: Start
[Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ike_decode_packet: Start, SA = { 186650cd f4b0f99f - bea34b61 b26a5758} / 00000000, nego = -1
[Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ike_decode_packet: first_payload_type:1.
[Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ike_decode_packet: next_payload_type:4.
[Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ike_decode_packet: next_payload_type:10.
[Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ike_decode_packet: next_payload_type:5.
[Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ike_decode_packet: next_payload_type:13.
[Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ike_decode_packet: next_payload_type:13.
[Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ike_decode_packet: next_payload_type:13.
[Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ike_decode_packet: next_payload_type:13.
[Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ike_decode_packet: next_payload_type:13.
[Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ike_decode_packet: next_payload_type:13.
[Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ike_decode_packet: next_payload_type:13.
[Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ike_decode_packet: next_payload_type:13.
[Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ike_decode_packet: next_payload_type:13.
[Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ike_decode_packet: next_payload_type:0.
The responder parses through the payloads, processing the ID and proposal of the initiator.
[Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ike_decode_payload_sa: Start [Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ike_decode_payload_sa: Found 1 proposals [Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ike_state_step: Calling input function[1] = ike_st_i_id [Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ike_st_i_id: Start [Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ike_state_step: Calling input function[2] = ike_st_i_sa_proposal [Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ike_st_i_sa_proposal: Start [Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ike_free_id_payload: Start, id type = 1
Next it checks to see if it is configured to peer with the initiator, and finds it has a matching IKE gateway configuration called SRX-11 that matches the two IP endpoints packet's address.
[Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] Parsing notification payload for local:192.168.13.13, remote:192.168.11.11 IKEv1 [Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] Search for a tunnel matching the IKE peers, local:192.168.13.13, remote:192.168.11.11 IKEv1 [Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] iked_pm_phase1_sa_cfg_lookup_by_addr: Found SA-CFG SRX-11 by ip address for local:192.168.13.13, remote:192.168.11.11 IKEv1 remote_port:500 ksa_cfg_remote_port=0
The responder verifies the initiators identity. This is just a check, nobody has been authenticated here yet.
[Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] iked_pm_id_validate called with id ipv4(any:0,[0..3]=192.168.11.11) [Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] kmd_ipaddr2ikeid: ipaddr = 192.168.11.11 [Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] iked_pm_id_validate Use default id [ipv4(any:0,[0..3]=192.168.11.11)] [Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] iked_pm_id_validate default id matched.
Next it starts comparing the proposal that was sent over from the initiator against the proposal it has configured for it. If anything doesn't match up 100%, the proposal will be rejected and a notification will be sent back to the initiator telling that the proposal was not accepted.
[Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] address based lookup successful: Sa_cfg:SRX-11 Gateway:SRX-11 [Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ssh_ikev2_sa_select: SA_SELECT: Selecting IKEv1 proposal. [Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ssh_ikev2_sav1_select: Comparing 1 input proposals against 1 policy proposals [Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ssh_ikev2_sav1_select: Comparing input proposal #1 against policy proposal #1 [Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ikev2_choose_v1_proposal: Comparing 1 protocol(s) [Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ikev2_ikev1_attribute_check: Input and policy attributes of type 3 match [Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ikev2_ikev1_attribute_check: Attributes matched successfully [Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ikev2_ikev1_attribute_check: Setting life in seconds to 86400 from policy [Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ikev2_choose_v1_transform: Attributes match; selected input transform 0 [Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ikev2_choose_v1_proposal: Protocols match [Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ikev2_choose_v1_proposal: Selected proposal number 1 and transforms for 1 protocols [Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ikev2_choose_v1_proposal: Selected transform id 1 for protocol 1 [Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ssh_ikev2_sav1_select: Proposals match
In the case, the proposals match, so the IKE exchange can continue without any nasty messages being sent back. The rest of the paramaters sent over by the initiator are then parsed in for processing: the proposal, the initiator's nonce and Diffie-Hellman-Merkel public value is loaded in as well. The proposal will be echoe'd back to the initiator to let it know that it was accepted.
[Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ike_state_step: Calling input function[2] = ike_st_i_sa_proposal [Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ike_st_i_sa_proposal: Start [Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ike_state_step: Calling input function[3] = ike_st_i_nonce [Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ike_st_i_nonce: Start, nonce[0..16] = e9f3840b 042ac71a ... [Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ike_state_step: Calling input function[6] = ike_st_i_ke [Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ike_st_i_ke: Ke[0..96] = 6f5510f8 dd819861 ...
Now the responder computes a hash that will be used by the initiator to authenticate the responder. This hash is a function of the Diffie-Hellman-Merkel values, the nonces, cookies, identity of the responder and the pre-shared-key or certificate.
[Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ike_state_step: Calling output function[6] = ike_st_o_sig_or_hash [Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ike_st_o_sig_or_hash: Start, auth_method = 4 [Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ike_st_o_hash: Start
Now the responder generates it's own Diffie-Hellman-Merkel secret and public values, and chooses a nonce.
[Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ike_state_step: Calling output function[1] = ike_st_o_ke [Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ike_st_o_ke: Start [Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] Using software for dh_gen operation [Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] Inside kmd_sw_dh_gen... [Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ike_state_step: Calling output function[2] = ike_st_o_nonce [Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ike_st_o_nonce: Start [Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ikev2_fb_isakmp_nonce_data_len: Entered [Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ike_policy_reply_isakmp_nonce_data_len: Start
Next we can see the SRX putting together it's identity.
[Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ike_st_o_id: Start [Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ikev2_fb_isakmp_id: IKE ID policy call entered, IKE SA 8985800 (neg 8c7a800) [Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ikev2_fb_id_request_cb: Local id payload is ID(type = ipv4 (1), len = 4, value = 192.168.13.13) [Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ikev2_fb_idv2_to_idv1: Converting the IKEv2 payload ID ID(type = ipv4 (1), len = 4, value = 192.168.13.13) to IKEv1 ID [Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ikev2_fb_idv2_to_idv1: IKEv2 payload ID converted to IKEv1 payload ID ipv4(any:0,[0..3]=192.168.13.13) [Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ike_policy_reply_isakmp_id: Start [Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ssh_set_debug_gw_info: ssh_set_debug_gw_info: set gw debug info - local 192.168.13.13 remote 192.168.11.11 [Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ike_state_step: Calling output function[3] = ike_st_o_id [Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ike_st_o_id: Start
Then the SRX computes the Diffie-Hellman-Merkle shared key.
[Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] Using software for dh_comp operation [Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] Inside kmd_sw_dh_comp...
It continues on processing and packaging all of the payloads that need to be sent back to the initiator.
[Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ike_state_step: Calling output function[7] = ike_st_o_vids [Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ikev2_fb_isakmp_request_vendor_ids: Request vendor ID's policy call entered, IKE SA 8985800 (neg 8c7a800) [Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ikev2_fb_isakmp_request_vendor_ids: FB; Calling v2 policy function vendor_id_request [Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ikev2_fb_vid_request_cb: Got a VID of length 16 (neg 8c7a800) [Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] iked_pm_ike_request_vendor_id: Sending VID RFC 3706 (Dead Peer Detection) [Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ikev2_fb_vid_request_cb: Got a VID of length 16 (neg 8c7a800) [Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] iked_pm_ike_request_vendor_id: Sending VID RFC 3947 [Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] ikev2_fb_vid_request_cb: Got a VID of length 28 (neg 8c7a800) [Feb 13 05:37:31][192.168.13.13 <-> 192.168.11.11] iked_pm_ike_request_vendor_id: Sending VID NetScreen Technologies [Feb 13 05:37:32][192.168.13.13 <-> 192.168.11.11] ikev2_fb_vid_request_cb: No more VIDs [Feb 13 05:37:32][192.168.13.13 <-> 192.168.11.11] ike_policy_reply_isakmp_vendor_ids: Start [Feb 13 05:37:32][192.168.13.13 <-> 192.168.11.11] ike_state_step: Calling output function[8] = ike_st_o_status_n [Feb 13 05:37:32][192.168.13.13 <-> 192.168.11.11] ike_st_o_status_n: Start [Feb 13 05:37:32][192.168.13.13 <-> 192.168.11.11] ike_state_step: Calling output function[9] = ike_st_o_private [Feb 13 05:37:32][192.168.13.13 <-> 192.168.11.11] ike_st_o_private: Start [Feb 13 05:37:32][192.168.13.13 <-> 192.168.11.11] ikev2_fb_private_p_1_out: Phase-I output: packet_number 2 ike_sa 8985800 (neg 8c7a800) [Feb 13 05:37:32][192.168.13.13 <-> 192.168.11.11] ikev2_fb_phase1_pending_natt_operations: Processing pending NAT-T operations
The reponder computes the encryption key that will be used to protect all of the IKE traffic.
[Feb 13 05:37:32][192.168.13.13 <-> 192.168.11.11] ike_state_step: Calling output function[10] = ike_st_o_calc_skeyid [Feb 13 05:37:32][192.168.13.13 <-> 192.168.11.11] ike_st_o_calc_skeyid: Calculating skeyid
However, as the initiator doesn't have the responder's Diffie-Hellman-Merkel public value yet, it can encrypt it's response. It continues to package up all of it's response payloads in an ISAKMP packet without using any encryption. The authentication hash has also been sent in the clear, along with all of the other values that are used to create it aside from the pre-shared-key. This makes it possible to brute-force or guess the pre-shared-key from just a couple of captured packets.
[Feb 13 05:37:32][192.168.13.13 <-> 192.168.11.11] ike_encode_packet: Start, SA = { 0x186650cd f4b0f99f - bea34b61 b26a5758 } / 00000000, nego = -1
[Feb 13 05:37:32][192.168.13.13 <-> 192.168.11.11] ssh_ike_encode_data_attribute: encode B: type = 1 (0x0001), len = 2, value = 0005
[Feb 13 05:37:32][192.168.13.13 <-> 192.168.11.11] ssh_ike_encode_data_attribute: encode B: type = 4 (0x0004), len = 2, value = 0001
[Feb 13 05:37:32][192.168.13.13 <-> 192.168.11.11] ssh_ike_encode_data_attribute: encode B: type = 2 (0x0002), len = 2, value = 0001
[Feb 13 05:37:32][192.168.13.13 <-> 192.168.11.11] ssh_ike_encode_data_attribute: encode B: type = 11 (0x000b), len = 2, value = 0001
[Feb 13 05:37:32][192.168.13.13 <-> 192.168.11.11] ssh_ike_encode_data_attribute: encode V: type = 12 (0x000c), len = 4 (0x0004), value = 00015180 ...
[Feb 13 05:37:32][192.168.13.13 <-> 192.168.11.11] ssh_ike_encode_data_attribute: encode B: type = 3 (0x0003), len = 2, value = 0001
[Feb 13 05:37:32][192.168.13.13 <-> 192.168.11.11] ike_encode_packet: Final length = 348
The IKEv1 Aggressive Mode Finite State Machine has the responder performing the following actions.
Responder's actions in step #2.
And finally the responder sends it's first reply back to the initiator.
[Feb 13 05:37:32][192.168.13.13 <-> 192.168.11.11] ike_send_packet: Start, send SA = { 186650cd f4b0f99f - bea34b61 b26a5758}, nego = -1, dst = 192.168.11.11:500, routing table id = 0
Packet #2: IKEv1 packet sent to initiator.
The initiator receives it's first response from the responder. It looks up the SA, doesn't find it (as it doesn't have an entry for the responder's cookie yet). It soon realizes this belongs to the proto-SA it had setup before and fills in the missing details -- the responder's cookie 0xbea34b61b26a5758
[Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] *** Processing received packet from 192.168.13.13:500 to 192.168.11.11:0 VR 0
[Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] ikev2_packet_st_input_start: [8c11800/0] Processing received
[Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] ike_sa_find: Start, SA = { 186650cd f4b0f99f - bea34b61 b26a5758 }
[Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] ike_sa_find: Not found SA = { 186650cd f4b0f99f - bea34b61 b26a5758 }
[Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] Failed to find IKEv1 SA for given spi
[Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] ikev2_packet_st_input_v1_create_sa: [8c11800/0] No IKE SA for packet; requesting permission to create one.
[Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] iked_pm_ike_rate_limit: Soft limit for p1 negotiation 100.Current active p1 negotiations 0
[Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] New connection from 192.168.13.13:500 allowed
[Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] ikev2_packet_st_connect_decision: [8c11800/0] Pad allows connection
[Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] ikev2_packet_v1_start: Passing IKE v1.0 packet to IKEv1 library
[Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] ike_udp_callback_common: Packet from 192.168.13.13:500, use_natt=0 data[0..348] = 186650cd f4b0f99f bea34b61 b26a5758 ...
[Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] ike_get_sa: Start, SA = { 186650cd f4b0f99f - bea34b61 b26a5758 } / 00000000, remote = 192.168.13.13:500
[Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] ike_sa_find: Start, SA = { 186650cd f4b0f99f - bea34b61 b26a5758 }
[Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] ike_sa_find: Not found SA = { 186650cd f4b0f99f - bea34b61 b26a5758 }
[Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] ike_sa_find_half: Start, SA = { 186650cd f4b0f99f - 00000000 00000000 }
[Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] ike_sa_find_half: Found half SA = { 186650cd f4b0f99f - 00000000 00000000 }
[Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] ike_get_sa: We are intiator, first response packet
[Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] ike_sa_upgrade: Start, SA = { 186650cd f4b0f99f - 00000000 00000000 } -> { ... - bea34b61 b26a5758 }
The initiating SRX then starts the contents of the packet, including the nonce, Diffie-Hellman-Merkel public value, responder's identity and an authentication hash.
[Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] ike_decode_packet: Start
[Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] ike_decode_packet: Start, SA = { 186650cd f4b0f99f - bea34b61 b26a5758} / 00000000, nego = -1
[Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] ike_decode_packet: first_payload_type:1.
[Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] ike_decode_packet: next_payload_type:4.
[Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] ike_decode_packet: next_payload_type:10.
[Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] ike_decode_packet: next_payload_type:5.
[Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] ike_decode_packet: next_payload_type:8.
[Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] ike_decode_packet: next_payload_type:13.
[Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] ike_decode_packet: next_payload_type:13.
[Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] ike_decode_packet: next_payload_type:13.
[Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] ike_decode_packet: next_payload_type:20.
[Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] ikev2_fb_private_p_1_check: New Phase-I private payload: private_payload_id 20
[Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] ikev2_fb_private_p_1_check: RFC 3947 NAT-D payload
[Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] ike_decode_packet: next_payload_type:20.
[Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] ikev2_fb_private_p_1_check: New Phase-I private payload: private_payload_id 20
[Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] ikev2_fb_private_p_1_check: RFC 3947 NAT-D payload
[Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] ike_decode_packet: next_payload_type:0.
[Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] ike_state_step: Calling input function[1] = ike_st_i_nonce
[Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] ike_st_i_nonce: Start, nonce[0..16] = 78092572 311ed7de ...
[Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] ike_state_step: Calling input function[2] = ike_st_i_id
[Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] ike_st_i_id: Start
[Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] ike_state_step: Calling input function[3] = ike_st_i_ke
[Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] ike_st_i_ke: Ke[0..96] = b17ea531 21277a5a ...
[Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] ike_state_step: Calling input function[4] = ike_st_i_hash
[Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] ike_st_i_hash: Start, hash[0..16] = 2d426c74 5d2b65c5 ...
[Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] ike_calc_mac: Start, initiator = true, local = false
Once the initiator finds the responder's nonce (ike_st_i_nonce) and it's Diffie-Hellman-Merkel public value (ike_st_i_ke), it too can compute the Diffie-Hellman-Merkel shared secret.
[Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] Using software for dh_comp operation [Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] Inside kmd_sw_dh_comp...
The initiating SRX processes the rest of the payloads, such as NAT-T.
[Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] ike_st_i_private: Start [Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] ikev2_fb_private_p_1_in: Phase-I input: packet_number 2 ike_sa 8c76400 (neg 8c7a800) [Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] ikev2_fb_private_p_1_in: New payload: packet_number=2, private_payload_id=20: [Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] ikev2_fb_natt_hash_choice: Local end not behind NAT
The initiator verifies the authentication hash.
[Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] ike_st_i_hash: Start, hash[0..16] = 2d426c74 5d2b65c5 ..
It processes the responders identity, and makes sure it matches up to what the initiator thinks it should be.
[Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] iked_pm_ike_sa_done: local:192.168.11.11, remote:192.168.13.13 IKEv1 [Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] ikev2_fb_idv2_to_idv1: Converting the IKEv2 payload ID ID(type = ipv4 (1), len = 4, value = 192.168.13.13) to IKEv1 ID [Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] ikev2_fb_idv2_to_idv1: IKEv2 payload ID converted to IKEv1 payload ID ipv4(any:0,[0..3]=192.168.13.13) [Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] iked_pm_id_validate called with id ipv4(any:0,[0..3]=192.168.13.13) [Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] kmd_ipaddr2ikeid: ipaddr = 192.168.13.13 [Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] iked_pm_id_validate Use default id [ipv4(any:0,[0..3]=192.168.13.13)] [Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] iked_pm_id_validate default id matched.
Satisfied that the responder is actually the responder (as far as it's concerned), t he initiating SRX the starts processing the information to insert into the third and final packet in the Aggressive Mode exchange. It inserts it's own authentication hash, and any other ongoing negotiations -- in this case NAT-T.
[Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] ike_st_o_hash: Start [Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] ike_state_step: Calling output function[2] = ike_st_o_private [Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] ike_st_o_private: Start [Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] ikev2_fb_phase1_pending_natt_operations: Processing pending NAT-T operations [Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] ikev2_fb_handle_send_hash_id: Adding NAT-D payloads: ike_sa 8c76400 (neg 8c7a800)
The initiator now has completed enough of the exchange for itself to declare Phase 1 complete.
[Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] ike_st_o_all_done: MESSAGE: Phase 1 { 0x186650cd f4b0f99f - 0xbea34b61 b26a5758 } / 00000000, version = 1.0, xchg = Aggressive, auth_method = Pre shared keys, Initiator, cipher = 3des-cbc,
[Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] 192.168.11.11:500 (Initiator) <-> 192.168.13.13:500 { 186650cd f4b0f99f - bea34b61 b26a5758 [-1] / 0x00000000 } Aggr; MESSAGE: Phase 1 version = 1.0, auth_method = Pre shared keys, cipher
It then packages up the payloads into and ISAKMP packet, and this time both parties have enough information that the packet can be encrypted and decrypted successfully.
[Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] ike_state_step: All done, new state = AM final I (12)
[Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] ike_encode_packet: Start, SA = { 0x186650cd f4b0f99f - bea34b61 b26a5758 } / 00000000, nego = -1
[Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] ike_encode_packet: Encrypting packet
[Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] ike_encode_packet: Final length = 92
Initiator processes Diffie-Hellman-Merkle components and a nonce.
And the initiator sends the third and final packet in the exchange, this time encrypted.
[Feb 13 05:37:32][192.168.11.11 <-> 192.168.13.13] ike_send_packet: Start, send SA = { 186650cd f4b0f99f - bea34b61 b26a5758}, nego = 0, dst = 192.168.13.13:500, routing table id = 0
Packet #3: ISAKMP packet sent to responder.
The responder recieves the third packet in the exchange and matches it up with the existing SA that isn't quite finished yet.
[Feb 13 05:37:32][192.168.13.13 <-> 192.168.11.11] *** Processing received packet from 192.168.11.11:500 to 192.168.13.13:0 VR 0
[Feb 13 05:37:32][192.168.13.13 <-> 192.168.11.11] ikev2_packet_st_input_start: [8c26000/0] Processing received
[Feb 13 05:37:32][192.168.13.13 <-> 192.168.11.11] ike_sa_find: Start, SA = { 186650cd f4b0f99f - bea34b61 b26a5758 }
[Feb 13 05:37:32][192.168.13.13 <-> 192.168.11.11] ike_sa_find: Found SA = { 186650cd f4b0f99f - bea34b61 b26a5758 }
[Feb 13 05:37:32][192.168.13.13 <-> 192.168.11.11] Found IKEv1 SA
The responder decodes and decrypts the packet. It finds the initiators authentication hash, along with more NAT-T stuff.
[Feb 13 05:37:32][192.168.13.13 <-> 192.168.11.11] ike_decode_packet: Start
[Feb 13 05:37:32][192.168.13.13 <-> 192.168.11.11] ike_decode_packet: Start, SA = { 186650cd f4b0f99f - bea34b61 b26a5758} / 00000000, nego = -1
[Feb 13 05:37:32][192.168.13.13 <-> 192.168.11.11] ike_decode_packet: first_payload_type:8.
[Feb 13 05:37:32][192.168.13.13 <-> 192.168.11.11] ike_decode_packet: Decrypting packet
[Feb 13 05:37:32][192.168.13.13 <-> 192.168.11.11] ike_decode_packet: next_payload_type:20.
[Feb 13 05:37:32][192.168.13.13 <-> 192.168.11.11] ikev2_fb_private_p_1_check: New Phase-I private payload: private_payload_id 20
[Feb 13 05:37:32][192.168.13.13 <-> 192.168.11.11] ikev2_fb_private_p_1_check: RFC 3947 NAT-D payload
[Feb 13 05:37:32][192.168.13.13 <-> 192.168.11.11] ike_decode_packet: next_payload_type:20.
[Feb 13 05:37:32][192.168.13.13 <-> 192.168.11.11] ikev2_fb_private_p_1_check: New Phase-I private payload: private_payload_id 20
[Feb 13 05:37:32][192.168.13.13 <-> 192.168.11.11] ikev2_fb_private_p_1_check: RFC 3947 NAT-D payload
[Feb 13 05:37:32][192.168.13.13 <-> 192.168.11.11] ike_decode_packet: next_payload_type:0.
The responder processes the authentication hash to validate the initiator.
[Feb 13 05:37:32][192.168.13.13 <-> 192.168.11.11] ike_state_step: Calling input function[0] = ike_st_i_hash [Feb 13 05:37:32][192.168.13.13 <-> 192.168.11.11] ike_st_i_hash: Start, hash[0..16] = 51052ef5 a62ec7e0 ...
As the authentication portion completes, the responder declares Phase 1 complete.
[Feb 13 05:37:32][192.168.13.13 <-> 192.168.11.11] ike_st_o_all_done: MESSAGE: Phase 1 { 0x186650cd f4b0f99f - 0xbea34b61 b26a5758 } / 00000000, version = 1.0, xchg = Aggressive, auth_method = Pre shared keys, Responder, cipher = 3des-cbc,
[Feb 13 05:37:32][192.168.13.13 <-> 192.168.11.11] 192.168.13.13:500 (Responder) <-> 192.168.11.11:500 { 186650cd f4b0f99f - bea34b61 b26a5758 [-1] / 0x00000000 } Aggr; MESSAGE: Phase 1 version = 1.0, auth_method = Pre shared keys, cipher
The responder recieves the IKEv1 packet with the initiators authentication data.
The two IKE peers will now move onto Phase 2, Quick Mode.