RE KEYING PHASE1 AND PHASE2 (IPSEC)

[sarahr202]

Hi everybody,

I am labbing up following scenario in GNS3:

We are using lPSEC with crypto map, lan to lan mode( tunnel  mode)

R1#show version
Cisco IOS Software, 7200 Software (C7200-ADVIPSERVICESK9-M), Version 15.2(4)S5, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2014 by Cisco Systems, Inc.
Compiled Thu 20-Feb-14 06:51 by prod_rel_team

SET UP:

R1---------R2

when lifetime is set for 120 seconds for phase1 on both R1/R2. i do not see phase1 reestablishes again after 120 sec. 

When lifetime is set for 120 sec for phase2, phase2 re establishes only once after 120 sec.

Other than that, phase1/phase2 once expired , they only reestablish when the interesting trigger the phase1/phase2.

What are your experiences based on different model?    I am seeing a lot of contradictory info that tunnels re-key after the lifetime expires.

Thanks and have a good day!!

[Paul Chapman · Accepted solution]

Hi -

Re-key operations are typically done in the session.  The endpoints do not go through the normal initialization process since the tunnel is already established.  Since you are using routers, change your encryption type from ESP to AH.  This will allow you to see the exchanges in (mostly) clear text in Wireshark.

PSC

[sarahr202]

Thanks Paul for your response.

This is what I see:

Once the lifetime of tunnels is up, tunnels are torn down, I saw that for phase1( life time: 1 day) and phase2 tunnels ( life time:1HR),

Since I am doing it on GNS3,  I was curious if you  guys have similar behavior on real cisco routers that is when the tunnel's time is about to expire, both IPSEC end points generate new keys.

Again I am using on-demand IPSEC tunnels in tunnel mode using legacy IPSEC crypto map method.

Thanks,

I

[Paul Chapman]

Hi -

If you run continuous traffic, you will see that the tunnels don't get torn down.  They continue to run, and the re-key occurs on the fly with no impact to the traffic passing.

As previously stated, by using Wireshark and AH (instead of ESP), you can see the re-key operation occur inside the tunnel.

PSC

[sarahr202]

Hi Paul,

I appreciate your response.

If you run continuous traffic, you will see that the tunnels don't get torn down.  They continue to run, and the re-key occurs on the fly with no impact to the traffic passing.

I do not see the above behavior, regardless whether  there is interesting traffic or not, Tunnels timers are independent, once they expire, tunnels expire.

EXAMPLE:

R1-12.12.12.1----12.12.12.2 R2

R1 has loop1: 1.1.1.1, R2 has loopback2: 2.2.2.2

Interesting traffic is defined as traffic between 1.1.1.1 and 2.2.2.2

R1:

crypto isakmp policy 1
encr 3des
hash md5
authentication pre-share
lifetime 120
crypto isakmp key ZEE address 12.12.12.2

crypto ipsec transform-set ZEE ah-md5-hmac
mode tunnel

crypto map ZEE 1 ipsec-isakmp
set peer 12.12.12.2
set security-association lifetime seconds 120
set transform-set ZEE
match address 101

access-list 101 permit ip host 1.1.1.1 host 2.2.2.2

R2:

crypto isakmp policy 1
encr 3des
hash md5
authentication pre-share
lifetime 120
crypto isakmp key ZEE address 12.12.12.1

crypto ipsec transform-set ZEE ah-md5-hmac
mode tunnel

crypto map ZEE 1 ipsec-isakmp
set peer 12.12.12.1
set security-association lifetime seconds 160
set transform-set ZEE
match address 101

access-list 101 permit ip host 2.2.2.2 host 1.1.1.1

Next I generate a continuous ping from R1 to R2 and see SA's life time as the production traffic continue to flow, you will see  lifetime counters for both tunnels continue to decrement :

R1#ping 2.2.2.2 source 1.1.1.1 repeat 2147483647

PHASE1 Tunnel lifetime continue to decrement, even though there is interesting traffic is flowing:

R2#show crypto isakmp sa detail

IPv4 Crypto ISAKMP SA

C-id Local Remote I-VRF Status Encr Hash Auth DH Lifetime Cap.

1010 12.12.12.2 12.12.12.1 ACTIVE 3des md5 psk 1 00:01:51

R2#show crypto isakmp sa detail

C-id Local Remote I-VRF Status Encr Hash Auth DH Lifetime Cap.

1010 12.12.12.2 12.12.12.1 ACTIVE 3des md5 psk 1 00:01:47

Same goes for PHASE2 tunnel:

R2#show crypto ipsec sa

inbound ah sas:
spi: 0x65D23CD1(1708276945)

sa timing: remaining key lifetime (k/sec): (4229422/86)

outbound ah sas:
spi: 0x3C7F6EC2(1014984386)

sa timing: remaining key lifetime (k/sec): (4229422/86)

R2#show crypto ipsec sa

inbound ah sas:
spi: 0x65D23CD1(1708276945)

sa timing: remaining key lifetime (k/sec): (4229422/66)

outbound ah sas:
spi: 0x3C7F6EC2(1014984386)

sa timing: remaining key lifetime (k/sec): (4229422/66)

Eventually the timers expire. Since there is interesting traffic flowing, phase1 kick in first because its lifetime timer happens to expire first:

Also note that production traffic continue to flow as PHASE2's timer did not expire yet:

Eventually PHASE2 timer expires, we see PHASE2 kicks in:

So we do not see re-keying happening, rather whole tunnels are torn down once lifetime timers are up regardless whether there is interesting traffic or not. Again we are taking about IPSEC using crypto map.  For example IPSEC VTI does not require any interesting traffic to be present ( because of proxy ID any any.

As previously stated, by using Wireshark and AH (instead of ESP), you can see the re-key operation occur inside the tunnel.

I see tunnel torn down once the timer is up, also AH or ESP are applied to interesting traffic, not to PHASE2 control plane communication if any, that will use phase1 keys and will be encrypted regardless of AH or ESP being used.

Thanks and have a nice day!!