How do IPsec lifetimes and rekeying work, and what are the Cisco defaults?
Show the answer
Say this first
Every SA expires after a time or a traffic volume, whichever comes first, and is replaced before it expires so traffic does not stop. On IOS the IKE SA lifetime defaults to 86400 seconds, and IPsec SAs to 3600 seconds or 4,608,000 kilobytes. In IKEv1 lifetimes are proposed during negotiation; in IKEv2 they are not negotiated and each peer rekeys on its own timer.
Go deeper
Seeing the clock
sa timing: remaining key lifetime (k/sec): (4607862/3412)This line in show crypto ipsec sa shows the kilobytes and seconds left on that SA.
Changing it on IOS
crypto isakmp policy 10
lifetime 28800
crypto ipsec security-association lifetime seconds 3600
crypto ipsec security-association lifetime kilobytes 4608000
crypto ikev2 profile IKEV2-PROF
lifetime 86400Matching rules
- IKEv1 phase 1 on IOS: a policy matches when the peer's proposed lifetime is equal to or shorter than the local one, and the shorter value is used.
- IKEv2: no negotiation. The side with the shorter lifetime starts the rekey.
Why a volume limit
It caps how much data one key protects and forces a rekey before the 32-bit ESP sequence number can wrap. Very fast links use extended sequence numbers (64-bit) for that reason.
They will ask next
Do the IPsec SAs die when the IKE SA expires?
In IKEv1 no: IPsec SAs have their own lifetimes and keep working; a new ISAKMP SA is built when needed for the next quick mode. In IKEv2 the Child SAs belong to the IKE SA: deleting the IKE SA deletes them, so the IKE SA is rekeyed in place with CREATE_CHILD_SA instead.
A long file transfer stalls for a few seconds every hour. Where do you look?
At the rekey. Debug around the stall, check for a PFS or proposal mismatch that only matters at rekey, and check whether the old SA is removed before the new one is installed on both sides.
Traps
- Insisting lifetimes must match or the tunnel fails. Mismatches are tolerated in most cases; they change who rekeys and when.