Ike phase 1 rekey & timeout

When you indicate a phase 1 rekey interval of 60 sec., I'm assuming you are referring to the ISAKMP policy command "lifetime".

The default is likely once per day (86,400 sec.).

You might want a lifetime of an hour (3600 sec.).

Can't image why you would want such a short lifetime as 60 seconds.

When do you plan to forward traffic, if all you are doing is building and tearing down SAs?

Best regards, News Reader

Hi

Ya I am refering 60 seconds as isakmp SA lifetime. What I wanted to ask is if I configure isakmp SA lifetime & isakmp sa keepalive timeout duration as SAME then will the isakmp & ipsec SAs will be deleted or since rekey is happening so no need to delete the SAs as peer is reachable. Note that I am not getting any keepalives from any side. If there is any rfc or draft for keepalives or heartbeat then plz let me know. I know DPD but the behavior of keepalives is still not clear to me Thanks Fahad

Assuming I am correct that there is no reasonable circumstance for setting "isakmp sa lifetime" to a value as small as 60 sec., why is it important to you to know what would happen with such a configuration?

The "crypto isakmp keepalive" command specifies the number of seconds between DPD (Dead Peer Detection) messages.

When a crypto endpoint does not receive "three" keepalives in a row (3 x isakmp keepalive interval), it tears down the SAs.

You are tearing down the SAs due to the "isakmp sa lifetime" at, or around the time you would be receiving your first keepalive.

You may want to consult the Cisco IOS Security Command Reference, Release 12.3 T

If your next question is - what if I change the the "isakmp sa lifetime" to equal three times the "isakmp sa keepalive", I'm going to hang up on you. ;>)

Best regards, News Reader

Hi

Thanks for that link. By the way I gave 60 seconds SA duration just as an example :). Perhaps I was not able to phrase my statements properly. The question is if I get 3rd keepalive & at the same time my isakmp SA tears down will the ipsec SA should also tear down as I have received 3rd keepalive or it should continue with the new Isakmp SA & older ipsec sa. Of course now change isakmp duration to around 1500 sec :)

Regards Fahad :)

You won't let go of the "same time", will you? ;>)

Maybe this will help:

I just examined the ISAKMP SA and IPSEC SAs on a router with the following commands:

show crypto isakmp sa detail , note remaining lifetime and connection-id. show crypto ipsec sa detail , note remaining lifetime.

I then cleared the existing ISAKMP SA with the following command:

clear crypto isakmp

I did the ISAKMP show command again to confirm that the ISAKMP SA had been cleared/deleted.

I did the IPSEC show command again and found that the IPSec SAs continued to exist for the remainder of their lifetimes.

This tells me that the two SA types are independent. The expiration/deletion of the ISAKMP SA did not result in the IPSec SAs being torn down.

When the IPSec SAs were due to timeout, a new ISAKMP SA was created (phase 1), and then new IPSec SAs were created (phase 2).

Best regards, News Reader

fahad wrote:

Hi

Yes thats the point I wanted to tell---- If Isakmp & Ipsec SAs are there & Phase1 rekey fails (due to shutdown or change in IP address) before keepalive timeout then Keepalive timer will be deleted bcoz there is no isakmp SA & Ipsec SA will be there till it rekeys & fails to rekey. The same is the case with DPD also. The soluiton might be that give Isakmp SA duration more than IPsec SA duration. No SAME TIME this time. :)

Regards

Fahad

"The same is the case with DPD also."? ... "The solution..."? ... I am confused.

Perhaps it would have been best if you had stated the problem you were trying to overcome, rather than starting with an obscure question.

Earlier, I had asked if you were referring to the command "crypto isakmp keepalive" and you responded with "yes".

According to the Cisco IOS Security Configuration Guide, this command is associated with Enabling IKE Dead Peer Detection. The purpose of the command is - "Allows the gateway to send DPD messages to the router".

DPD Knowledge ........................ Here are some excerpts from some documents I found that may be helpful:

DPD allows the router to detect a dead IKE peer, and when the router detects the dead state, the router deletes the IPSec and IKE SAs to the peer.

Keepalive packets are not sent if traffic is received. In addition, DPD sends keepalive packets only if there is user traffic to send (and no user traffic is received).

You can configure IKE DPD so that DPD sends the keepalive packets whether or not there is outbound user data. That is, as long as there is no inbound user data, the keepalive packets are sent at the configured keepalive interval.

IKE Keepalives vs. DPD .................................... I found the following statements on the subject of: Restrictions for Stateful Failover for IPSec

IKE keepalives are not supported. (Enabling this functionality will cause the connection to be torn down after the standby router assumes ownership control.) However, dead peer detection (DPD) and periodic DPD are supported.

Clearly there is a difference between IKE Keepalives and DPD. Using a command like "crypto isakmp keepalive" to enable DPD just causes more confusion.

Like yourself, I don't know the difference.

Lifetimes ............... I use the same lifetime for ISAKMP and IPSec SAs. When the tunnel is first coming up, if an ISAKMP SA is successfully established, the IPSec SAs will be established shortly thereafter. The ISAKMP SA will be renewed just before expiration of the IPSec SAs. If the ISAKMP SA is not successfully renewed, then no renewal of the IPsec SAs shortly thereafter..

Best regards, News Reader

fahad wrote:

I think there was a typo in one of the excerpts I pasted:

"DPD sends keepalive packets only if there is user traffic to send (and no user traffic is received).

should probably read:

"DPD sends keepalive packets only if there is "NO" user traffic to send (and no user traffic is received).

Best regards, News Reader

News Reader wrote:

I think you need to be specific about which side of the tunnel (source or destination) you are referring to when describing these events.

If the far side peer is shutdown or changes its IP address (the scenarios you described) then you would no longer be receiving traffic through the tunnel. Would you not expect to detect the absence of the peer, and once detected, would you not delete the local ISAKMP and IPSec SAs?

Also, I believe new ISAKMP SAs are established before the existing ones expire.

Best regards, News Reader

fahad wrote:

I've done some reading in the book titled "IPSec Virtual Private Network Fundamentals" which helped.

The book refers to "periodic DPD (IKE keepalives)". In other words, IKE keepalives is the periodic mode of DPD.

On-demand DPD is the default operation. With on-demand DPD, traffic must be forwarded to the remote peer to initiate the discovery of the dead peer. If traffic is not sent to the peer, then the DPD status query message will not be forwarded to the remote peer, and the tunnel SAs will remain installed in the local gateway's SADB for the duration of their previously negotiated lifetimes.

In other words, no dicovery, and therefore no cleanup of the SA database if you are not sending data to the peer.

Conversely,

Periodic DPD (IKE keepalives) provisions for the removal of stale SAs from the SADB regardless of whether or not traffic is actively being forwarded to the dead peer. Periodic DPD can proactively detect dead peers without the presence of traffic in the encryption path.

Best regards, News Reader

fahad wrote:

Further reading indicates that the original statement is true for the default mode of DPD (i.e. on-demand)

"DPD sends keepalive packets only if there is user traffic to send (and no user traffic is received)."

Periodic DPD does not require user traffic in the encryption path. It can query the peer anyway (i.e.: be more proactive).

Best regards, News Reader

News Reader wrote:

Ya... DPD was proposed to overcome the problem with heartbeats. In heartbeat even if you dont want to send traffic heartbeat message will be sent but in DPD(on demand) peer's liveliness is checked when that side is interested in sending traffic. As far as I know cisco doesnt support heartbeats thats y confusion was there over keepalives(I was talking abt hearbeat keepalives not DPD :) ). In periodic DPD also when encrypted traffic is received by the peer, it doesnt trigger DPD so we can get rid of unnecessary heartbeat messages required(prior dpd implementation).

Regards Fahad

I don't think you are understanding Periodic DPD correctly.

I use Periodic DPD with retires, using the following command:

crypto isakmp keepalive 30 10 periodic

This is what I have confirmed with Wireshark on my WAN port:

The two IPSec + GRE peers exchange ISAKMP DPD messages every thirty seconds, regardless of whether traffic is, or is not passing through the tunnel.

I shutdown one of the peers.

The peer that is alive, is expecting to see the next ISAKMP DPD message thirty seconds after the last one. When it does not receive the expected message it starts a timer. Ten seconds later (based on my retry config), it queries the missing peer for the first time. If the peer remains missing, it continues to query every ten seconds. I think that the third un-answered query is what triggers the clearing of the ISAKMP SA, and IPSec SAs from the SADB.

Best Regards, News Reader

fahad wrote:

Yess I said the same thing... but if the peer is getting encrypted traffic within DPD trigger duration(30 sec in ur case) then the peer will not trigger DPD since that encypted traffic from the peer itself is proof of liveliness even in case of periodic DPD.... In the scenario what u have mentioned it will delete SAs after maximum retries configured as it doent get R U There Ack from the other side :)..

regards fahad

Fahad:

I know of periodic and on-demand DPD. You speak of heartbeats as though there is some third mode.

It isn't even clear what your issue is any longer.

I'm moving on.

Good luck.

Best Regards, News Reader

fahad wrote:

My issue is solved now. I have implemented DPD so I dont need any explainations for that :)... My query was simple--- do encrypted traffic reception & heartbeat messages are interrelated or not like DPD. Now my doubt is clear. Thanks for this knowledgable discussion.

Regards Fahad