ISAKMP and IPSec Key Refresh

hammonsrg · ‎08-30-2010

Greetings everyone.

I've been doing a lot of reading and practicing with IPSec and DMVPN setups lately. One thing that's routinely been a point of confusion for me has been ISAKMP rekeying policies. It seems simple enough, when DH is used, a secure management connection exists to share protected cryptographic key information for the standup or continuance of protected communications. I.e., when that management connection times out, no more key material can be shared until a new management connection is in place.

That's a strong assumption. Assume for discussion we're using an old static crypto map setup, with PSK and pure static entries in tunnel mode. If traffic arrives to your border that doesn't match your ACL exactly, traffic will still be allowed across the wire, but it'll be unencrypted.

Let's say I setup an isakmp policy with a lifetime of 200 seconds and in my crypto map I set a security-association policy with a lifetime of 125 seconds. When my ipsec keys approach their end of lifetime, the isakmp management connection will be used to rekey both sides of the connection, correct? What happens when that isakmp policy expires? In my mind, a new connection should be negotiated to provide for continuance of the ipsec rekeying activities. If that were to fail, the keys shouldn't be sent. Or would they be?

I've tested this exhaustively in my labs and to be honest, I'm getting none the wiser. I setup the exact scenario I laid out above: isakmp 200 and ipsec 125 second lifetimes, respectively. I can see the isakmp informational messages coming across when the isakmp policies expire and eventually I will see a new connection when I issue a 'show crypto isakmp sa', but it's not immediate. In fact, on some iterations, the isakmp sa showed me a (deleted) status, yet as I watch the ipsec SAs with 'show crypto ipsec sa' I see each respective SPI's lifetime reach its end-of-life and then as if a gremlin is inside the router, boom, rekeyed.

I've gone through all the RFCs I can stand to read, Deal's entire VPN book, multiple cisco publications, mountains of forums, and I can't understand this simple scenario. It seems logical that phase 2 cannot happen without phase 1, yet I sit here and watch these SAs rekey without the isakmp SA showing me it's been refreshed.

Maybe I've confused the smallest detail somewhere. I'm hoping someone can help me fan this fog out a little.

Cheers!

b.julin · ‎08-30-2010

I think maybe what you might be missing is that ISAKMP is more a dial-on-demand

setup. Crypto maps are installed at both ends, and if traffic matching those maps

arrives and there is no SA, a new one is automatically negotiated. I'm fuzzy on

the detilas of whether there is an optional mechanism to keep an isakmp SA up at all

times, or how phase 2 reneg traffic triggers phase 1 initiation since it is not usually

listed in the maps, but some systems likely simply time out the ISAKMP and rely on the

on-demand aspect to bring up the connection when it is needed, thus renewing

the crypto material.

hammonsrg · ‎08-30-2010

I would lean toward agreeing with you, however, everything I can find about isakmp lists it as the necessary part of IPSec needed to trigger phase 2. To me, that would indicate that phasse one is required to provide the initial keying and subsequent keying.