Document ID : 115934
Updated : Apr 03, 2013
Contributed by Anu M.Chacko and Atri Basu, Cisco TAC Engineers.
Introduction
This document describes Internet Key Exchange version 2 (IKEv2) debugs on Cisco IOS® when a pre-shared key (PSK) is used. In addition, this document provides information on how to translate certain debug lines in a configuration.
Prerequisites
Requirements Cisco recommends that you have knowledge of the packet exchange for IKEv2. For more information, refer to IKEv2 Packet Exchange and Protocol Level Debugging .
Components Used The information in this document is based on these software and hardware versions:
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Conventions Refer to Cisco Technical Tips Conventions for more information on document conventions.
Core Issue The packet exchange in IKEv2 is radically different from packet exchange in IKEv1. In IKEv1 there was a clearly demarcated phase1 exchange that consisted of six (6) packets followed by a phase 2 exchange that consisted of three (3) packets; the IKEv2 exchange is variable. For more information on the differences and an explanation of the packet exchange, refer to IKEv2 Packet Exchange and Protocol Level Debugging .
Router Configuration This section lists the configurations used in this document.
Router 1
interface Loopback0 Router 2
crypto ikev2 proposal PHASE1-prop
Troubleshoot
Router Debugs These debug commands are used in this document:
deb crypto ikev2 packet Router 1 (Initiator) Message Description Debugs Router 2 (Responder) Message Description Router 1 receives a packet that matches the crypto acl for peer ASA 10.0.0.2. Initiates SA creation *Nov 11 20:28:34.003: IKEv2:Got a packet from dispatcher
First pair of messages is the IKE_SA_INIT exchange. These messages negotiate cryptographic algorithms, exchange nonces, and do a Diffie-Hellman exchange.
Relevant Configuration: crypto ikev2 proposal PHASE1-prop encryption 3des aes-cbc-128 integrity sha1 group 2 crypto ikev2 keyring KEYRNG peer peer1 address 10.0.0.2 255.255.255.0 hostname host1 pre-shared-key local cisco pre-shared-key remote cisco
*Nov 11 19:30:34.811: IKEv2:(SA ID = 1):SM Trace-> SA: I_SPI=F074D8BBD5A59F0B R_SPI=0000000000000000 (I) MsgID = 00000000 CurState: IDLE Event: EV_INIT_SAEV_SET_POLICY EV_GEN_DH_KEY Initiator building IKE_INIT_SA packet. It contains: ISAKMP Header (SPI/version/flags), SAi1 (cryptographic algorithm that IKE initiator supports), KEi (DH public Key value of the initiator), and N (Initiator Nonce). *Nov 11 19:30:34.811: IKEv2:(SA ID = 1) :Next payload: SA, version: 2.0 Exchange type: IKE_SA_INIT, flags: INITIATOR Message id: 0, length: 344 SA Next payload: KE, reserved: 0x0, length: 56KE Next payload: N, reserved: 0x0, length: 136 --------------------------------------Initiator sent IKE_INIT_SA -----------------------> *Nov 11 19:30:34.814: IKEv2:Got a packet from dispatcher
Responder receives IKE_INIT_SA. *Nov 11 19:30:34.814: IKEv2:Next payload: SA, version: 2.0 Exchange type: IKE_SA_INIT, flags: INITIATOR Message id: 0, length: 344
Responder initiates SA creation for that peer. *Nov 11 19:30:34.814: IKEv2:(SA ID = 1):SM Trace-> SA: I_SPI=F074D8BBD5A59F0B R_SPI=F94020DD8CB4B9C4 (R) MsgID = 00000000 CurState: IDLE Event:EV_RECV_INIT EV_VERIFY_MSG EV_INSERT_SA EV_GET_IKE_POLICY EV_PROC_MSG Setting configured policies EV_GEN_DH_KEY EV_OK_RECD_DH_PUBKEY_RESP EV_GEN_DH_SECRET Getting preshared key by address 10.0.0.1 EV_GEN_SKEYID Generate skeyid
Responder verifies and processes the IKE_INIT message: (1) Chooses crypto suite from those offered by the initiator, (2) computes its own DH secret key, and (3) it computes a skeyid value, from which all keys can be derived for this IKE_SA. All but the headers of all the messages that follow are encrypted and authenticated. The keys used for the encryption and integrity protection are derived from SKEYID and are known as: SK_e (encryption), SK_a (authentication), SK_d is derived and used for derivation of further keying material for CHILD_SAs, and a separate SK_e and SK_a is computed for each direction.
Relevant Configuration: crypto ikev2 proposal PHASE1-prop encryption 3des aes-cbc-128 integrity sha1 group 2 crypto ikev2 keyring KEYRNG peer peer2 address 10.0.0.1 255.255.255.0 hostname host2 pre-shared-key local cisco pre-shared-key remote cisco
*Nov 11 19:30:34.822: IKEv2:(SA ID = 1):Next payload: SA, version: 2.0 Exchange type: IKE_SA_INIT, flags: RESPONDER MSG-RESPONSE Message id: 0, length: 449 SA Next payload: KE, reserved: 0x0, length: 48KE Next payload: N, reserved: 0x0, length: 136 N Next payload: VID, reserved: 0x0, length: 24
Router 2 builds the responder message for IKE_SA_INIT exchange, which is received by ASA1. This packet contains: ISAKMP Header(SPI/ version/flags), SAr1(cryptographic algorithm that IKE responder chooses), KEr(DH public Key value of the responder), and Responder Nonce. *Nov 11 19:30:34.822: IKEv2:(SA ID = 1):SM Trace-> SA: I_SPI=F074D8BBD5A59F0B R_SPI=F94020DD8CB4B9C4 (R) MsgID = 00000000 CurState: INIT_DONE Event: EV_DONEEV_START_TMR New ikev2 sa request admitted Incrementing outgoing negotiating sa count by one
Router2 sends out the responder message to Router 1. <-------------------------------Responder sent IKE_INIT_SA --------------------------- Router 1 receives the IKE_SA_INIT response packet from Router 2. *Nov 11 19:30:34.823: IKEv2:Got a packet from dispatcher
I_SPI=F074D8BBD5A59F0B R_SPI=F94020DD8CB4B9C4 (R) MsgID = 00000000 CurState: INIT_DONE Event:EV_START_TMR
Responder starts timer for Auth process. Router1 verifies and processes the response: (1) The initiator DH secret key is computed, and (2) the initiator skeyid is also generated. *Nov 11 19:30:34.823: IKEv2:(SA ID = 1):Next payload: SA, version: 2.0 Exchange type: IKE_SA_INIT, flags: RESPONDER MSG-RESPONSE Message id: 0, length: 449 SA Next payload: KE, reserved: 0x0, length: 48 KE Next payload: N, reserved: 0x0, length: 136N Next payload: VID, reserved: 0x0, length: 24
*Nov 11 19:30:34.824: IKEv2:(SA ID = 1):SM Trace-> SA: I_SPI=F074D8BBD5A59F0B R_SPI=F94020DD8CB4B9C4 (I) MsgID = 00000000 CurState: I_WAIT_INIT Event: EV_RECV_INITEV_GEN_DH_SECRET EV_GEN_SKEYID Generate skeyid
Initiator starts IKE_AUTH exchange and generates the authentication payload. The IKE_AUTH packet contains: ISAKMP Header(SPI/ version/flags), IDi(initiator's identity), AUTH payload, SAi2(initiates the SA-similar to the phase 2 transform set exchange in IKEv1), and TSi and TSr (Initiator and Responder Traffic selectors): They contain the source and destination address of the initiator and responder respectively for forwarding/receiving encrypted traffic. The address range specifies that all traffic to and from that range is tunneled. If the proposal is acceptable to the responder, it sends identical TS payloads back. The first CHILD_SA is created for the proxy_ID pair that matches the trigger packet.
Relevant Configuration: crypto ipsec transform-set TS esp-3des esp-sha-hmac crypto ipsec profile phse2-prof set transform-set TS set ikev2-profile IKEV2-SETUP
*Nov 11 19:30:34.831: IKEv2:(SA ID = 1):SM Trace-> SA: I_SPI=F074D8BBD5A59F0B R_SPI=F94020DD8CB4B9C4 (I) MsgID = 00000000 CurState: I_BLD_AUTH Event:EV_GEN_AUTH Payload contents: IDi Next payload: AUTH, reserved: 0x0, length: 12AUTH Next payload: CFG, reserved: 0x0, length: 28CFG Next payload: SA, reserved: 0x0, length: 309
*Nov 11 19:30:34.831: SA Next payload: TSi , reserved: 0x0, length: 40TSi Next payload: TSr, reserved: 0x0, length: 24TSr Next payload: NOTIFY, reserved: 0x0, length: 24
NOTIFY(INITIAL_CONTACT) Next payload: NOTIFY, reserved: 0x0, length: 8IKE_AUTH , flags: INITIATOR Message id: 1, length: 556 CurState: I_WAIT_AUTH Event: EV_NO_EVENT
-------------------------------------Initiator sent IKE_AUTH -----------------------------> *Nov 11 19:30:34.832: IKEv2:Got a packet from dispatcher IKEv2:(SA ID = 1) :Next payload: ENCR, version: 2.0 Exchange type: IKE_AUTH , flags: INITIATOR Message id: 1, length: 556 IDi Next payload: AUTH, reserved: 0x0, length: 12AUTH Next payload: CFG, reserved: 0x0, length: 28 CFG Next payload: SA, reserved: 0x0, length: 309SA Next payload: TSi, reserved: 0x0, length: 40TSi Next payload: TSr, reserved: 0x0, length: 24TSr Next payload: NOTIFY, reserved: 0x0, length: 24
Router 2 receives and verifies the authentication data received from Router 1.
Relevant Configuration : crypto ipsec ikev2 ipsec-proposal AES256 protocol esp encryption aes-256 protocol esp integrity sha-1 md5
*Nov 11 19:30:34.832: IKEv2:(SA ID = 1):SM Trace-> SA: I_SPI=F074D8BBD5A59F0B R_SPI=F94020DD8CB4B9C4 (R) MsgID = 00000001 CurState: R_WAIT_AUTH Event: EV_RECV_AUTH
Router 2 builds the response to IKE_AUTH packet that it received from Router 1. This response packet contains: ISAKMP Header(SPI/ version/flags), IDr(responder's identity), AUTH payload, SAr2(initiates the SA-similar to the phase 2 transform set exchange in IKEv1), and TSi and TSr(Initiator and Responder Traffic selectors). They contain the source and destination address of the initiator and responder respectively for forwarding/receiving encrypted traffic. The address range specifies that all traffic to and from that range are tunnelled. These parameters are identical to the one that was received from ASA1. *Nov 11 19:30:34.833: IKEv2:(SA ID = 1):Next payload: ENCR, version: 2.0 Exchange type: IKE_AUTH , flags: RESPONDER MSG-RESPONSE Message id: 1, length: 252 ENCR Next payload: VID, reserved: 0x0, length: 224EV_INSERT_IKE AUTH_DONE Event: EV_NO_EVENT
Responder sends the response for IKE_AUTH. <------------------------------------Responder sent IKE_AUTH---------------------------- Initiator receives response from Responder. *Nov 11 19:30:34.834: IKEv2:Got a packet from dispatcher
*Nov 11 19:30:34.840: IKEv2:(SA ID = 1):SM Trace-> SA: I_SPI=F074D8BBD5A59F0B R_SPI=F94020DD8CB4B9C4 (R) MsgID = 00000001 CurState: AUTH_DONE Event: EV_OK_RECD_LOAD_IPSEC
Responder inserts an entry into the SAD. Router 1 verifies and processes the authentication data in this packet. Router 1 then inserts this SA into its SAD. *Nov 11 19:30:34.834: IKEv2:(SA ID = 1):Next payload: ENCR, version: 2.0 Exchange type: IKE_AUTH , flags: RESPONDER MSG-RESPONSE Message id: 1, length: 252 Payload contents: IDr Next payload: AUTH, reserved: 0x0, length: 12AUTH Next payload: SA, reserved: 0x0, length: 28 SA Next payload: TSi, reserved: 0x0, length: 40 TSi Next payload: TSr, reserved: 0x0, length: 24 TSr Next payload: NOTIFY, reserved: 0x0, length: 24EV_RECV_AUTH EV_PROC_MSG EV_VERIFY_AUTH EV_NOTIFY_AUTH_DONE AUTH_DONE Event: EV_CHK4_ROLE
Tunnel is up on the Initiator and the status showsREADY . *Nov 11 19:30:34.841: IKEv2:(SA ID = 1):SM Trace-> SA: I_SPI=F074D8BBD5A59F0B R_SPI=F94020DD8CB4B9C4 (I) MsgID = 00000001 CurState: READY Event: EV_CHK_IKE_ONLY
* Nov 11 19:30:34.840: IKEv2:(SA ID = 1):SM Trace-> SA: I_SPI=F074D8BBD5A59F0B R_SPI=F94020DD8CB4B9C4 (R) MsgID = 00000001 CurState: READY Event: EV_R_OK
Tunnel is up on the Responder. The Responder tunnel usually comes up before the Initiator.
CHILD_SA Debugs This exchange consists of a single request/response pair and was referred to as a phase 2 exchange in IKEv1. It might be initiated by either end of the IKE_SA after the initial exchanges are completed.
Router 1 CHILD_SA Message Description Debugs Router 2 CHILD_SA Message Description Router 1 initiates the CHILD_SA exchange. This is the CREATE_CHILD_SA request. The CHILD_SA packet typically contains: SA HDR (version.flags/exchange type) Nonce Ni (optional): If the CHILD_SA is created as part of the initial exchange, a second KE payload and nonce must not be sent) SA Payload KEi (Key-optional): The CREATE_CHILD_SA request might optionally contain a KE payload for an additional DH exchange to enable stronger guarantees of forward secrecy for the CHILD_SA. If the SA offers include different DH groups, KEi must be an element of the group the initiator expects the responder to accept. If it guesses wrong, the CREATE_CHILD_SA exchange fails, and it will have to retry with a different KEi N(Notify payload-optional). The Notify Payload, is used to transmit informational data, such as error conditions and state transitions, to an IKE peer. A Notify Payload may appear in a response message (usually specifying why a request was rejected), in an INFORMATIONAL Exchange (to report an error not in an IKE request), or in any other message to indicate sender capabilities or to modify the meaning of the request.If this CREATE_CHILD_SA exchange is rekeying an existing SA other than the IKE_SA, the leading N payload of type REKEY_SA MUST identify the SA being rekeyed. If this CREATE_CHILD_SA exchange is not rekeying an existing SA, the N payload MUST be omitted. *Nov 11 19:31:35.873: IKEv2:Got a packet from dispatcherExchange type: CREATE_CHILD_SA , flags: INITIATOR Message id: 3, length: 396 SA Next payload: N, reserved: 0x0, length: 152N Next payload: KE, reserved: 0x0, length: 24KE Next payload: NOTIFY, reserved: 0x0, length: 136NOTIFY (SET_WINDOW_SIZE) Next payload: NONE, reserved: 0x0, length: 12SA ID = 2 ):SM Trace-> SA: I_SPI=0C33DB40DBAAADE6 R_SPI=F14E2BBA78024DE3 (R) MsgID = 00000003 CurState: READY Event: EV_RECV_CREATE_CHILD EV_REKEY_IKESA Getting preshared key by address 10.0.0.2 Setting configured policies EV_GEN_DH_SECRET IKEv2:Construct Notify Payload : SET_WINDOW_SIZE SA Next payload: N, reserved: 0x0, length: 56 N Next payload: KE, reserved: 0x0, length: 24KE Next payload: NOTIFY, reserved: 0x0, length: 136 NOTIFY (SET_WINDOW_SIZE) Next payload: NONE, reserved: 0x0, length: 12
*Nov 11 19:31:35.869: IKEv2:(SA ID = 2 ):Next payload: ENCR, version: 2.0 Exchange type: CREATE_CHILD_SA , flags: INITIATOR Message id: 2, length: 460
*Nov 11 19:31:35.873: IKEv2:Construct Notify Payload: SET_WINDOW_SIZE SA Next payload: N, reserved: 0x0, length: 152N Next payload: KE, reserved: 0x0, length: 24KE Next payload: NOTIFY, reserved: 0x0, length: 136NOTIFY (SET_WINDOW_SIZE) Next payload: NONE, reserved: 0x0, length: 12
This packet is received by Router 2. *Nov 11 19:31:35.882: IKEv2:(SA ID = 2 ):Next payload: ENCR, version: 2.0 Exchange type: CREATE_CHILD_SA, flags: RESPONDER MSG-RESPONSE Message id: 3, length: 300 SA Next payload: N, reserved: 0x0, length: 56N Next payload: KE, reserved: 0x0, length: 24 KE Next payload: NOTIFY, reserved: 0x0, length: 136NOTIFY (SET_WINDOW_SIZE) Next payload: NONE, reserved: 0x0, length: 12CHILD_I_WAIT Event: EV_RECV_CREATE_CHILD CHILD_I_PROC Event: EV_CHK4_NOTIFYEV_VERIFY_MSG CHILD_I_DONE Event: EV_ACTIVATE_NEW_SA CurState: EXIT Event: EV_NO_EVENT
Router 2 now builds the reply for the CHILD_SA exchange. This is the CREATE_CHILD_SA response. The CHILD_SA packet typically contains: SA HDR (version.flags/exchange type) Nonce Ni(optional): If the CHILD_SA is created as part of the initial exchange, a second KE payload and nonce must not be sent. SA Payload KEi (Key-optional): The CREATE_CHILD_SA request might optionally contain a KE payload for an additional DH exchange to enable stronger guarantees of forward secrecy for the CHILD_SA. If the SA offers include different DH groups, KEi must be an element of the group the initiator expects the responder to accept. If it guesses wrong, the CREATE_CHILD_SA exchange fails, and it must retry with a different KEi. N (Notify payload-optional): The Notify Payload is used to transmit informational data, such as error conditions and state transitions, to an IKE peer. A Notify Payload might appear in a response message (usually specifying why a request was rejected), in an informational exchange (to report an error not in an IKE request), or in any other message to indicate sender capabilities or to modify the meaning of the request. If this CREATE_CHILD_SA exchange is rekeying an existing SA other than the IKE_SA, the leading N payload of type REKEY_SA must identify the SA being rekeyed. If this CREATE_CHILD_SA exchange is not rekeying an existing SA, the N payload must be omitted. Router 2 sends the response out and completes activating the new CHILD SA. Router 1 receives the response packet from Router 2 and completes activating the CHILD_SA. *Nov 11 19:31:35.882: IKEv2:(SA ID = 2):Next payload: ENCR, version: 2.0 Exchange type: CREATE_CHILD_SA , flags: RESPONDER MSG-RESPONSE Message id: 3, length: 300 EV_CHK_IKE_REKEY Generate skeyid EV_ACTIVATE_NEW_SA CHILD_R_DONE Event: EV_CHECK_DUPECurState: EXIT Event: EV_NO_EVENT
Tunnel Verification
ISAKMP Command
show crypto ikev2 sa detailed Router 1 Output
Router1#show crypto ikev2 sa detailed Router 2 Output
Router2#show crypto ikev2 sa detailed
IPsec Command
show crypto ipsec sa Router 1 Output
Router1#show crypto ipsec sa Router 2 Output
Router2#show crypto ipsec sa You can also check the output of the show crypto session command on both routers; this output shows the tunnel session status as UP-ACTIVE.
Router1#show crypto session
Related Information Updated: Apr 03, 2013
Document ID: 115934
(Requires a Cisco Service Contract.)