If I config ISAKMP(phase 1) life time short than IPsec(phase 2) life time. What will happen.

[Xiang Hong Angela YAN]

Since I could not find any Cisco document for guideline (Cisco only mentiond that, the shorter the ISAKMP life time, the more secure) .

I was wondering if I config the ISAKMP(phase 1) life time shorter than IPsec(phase 2) life time. What will happen when I still have traffic passing through the VPN tunnel, the ISAKMP reachs its timeout. Would phase 2 also got terminated, and re-start all the VPN negotiation from Phase 1 again?  

Any help will be appreciated.

- Angela

[Diego Armando Cambronero Arias]

The renegotiation will take place before the lifetime is reached. So no connections will be dropped.

The peers negotiate a new SA before crossing the lifetime threshold of the existing SA to ensure that a new SA is ready when the existing one expires. The peers negotiate a new SA when about 5 to 15 percent of the lifetime of the existing SA remains.

[Xiang Hong Angela YAN]

Hi Diego,

Thanks for the answer.

- Angela

[devaprem12]

If I config ISAKMP(phase 1) life time short than IPsec(phase 2) life time. What will happen.

I have tested this out in my LAB,My Findings are

1. ISAKMP SA is mainly created for IPSEC SA function , so when ISAKMP lifetime expires IPSEC SA still be continues untill it lifetime expires

2.  It doesnt make sense if ISAKMP SA expires then the IPSEC SA also needs to be timeout  because ISAKMP (Phase 1) is performed to make IPSEC SA (Phase 2) to  function

3. When IPSEC SA lifetime expires and if the traffic initiated then the ISAKMP SA established and Followed by IPSEC SA

4. So most of the config change done on the peers need clear crypto session, if not the peers will work with the function negotiated in the last session

[Diego Armando Cambronero Arias]

http://www.cisco.com/en/US/docs/ios/11_3/feature/guide/isakmp.html#wp6739

Check this link.

I hope it helps.

[michael.leblanc]

Angela:

Negotiating a bidirectional ISAKMP SA results in a secure channel that facilitates the negotiation of unidirectional IPSec SAs. Once the IPSec SAs have been negotiated, you could actually delete the ISAKMP SA with "clear crypto isakmp ", the crypto session would remain up, the IPSec SAs would remain intact, and crypto protected data could continue to flow.

If an ISAKMP SA did not exist for a given session when the IPSec SAs needed to be re-negotiated, a new ISAKMP SA would be established first.

Consider the following:

edg01# sh crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst                          src                              state          conn-id     status
        QM_IDLE    2024          ACTIVE
        QM_IDLE    2023          ACTIVE
        QM_IDLE    2022          ACTIVE

Edit ----------------

edg01# clear crypto isakmp 2024
edg01# clear crypto isakmp 2023
edg01# clear crypto isakmp 2022

Edit ----------------

Edit ----------------

edg01# sh crypto isakmp sa

Edit ----------------
IPv4 Crypto ISAKMP SA
dst                           src                          state                         conn-id         status
        MM_NO_STATE       2024           ACTIVE     (deleted)
        MM_NO_STATE       2023           ACTIVE     (deleted)
        MM_NO_STATE       2022           ACTIVE     (deleted)

edg01# sh crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst                            src                            state                    conn-id           status

Note: Takes a while for the ISAKMP SA entries to be removed from the show command output.

edg01# sh crypto session
Crypto session current status

Interface: Tunnel0
Session status: UP-NO-IKE
Peer: port 500
  IPSEC FLOW: permit 47 host host
        Active SAs: 2, origin: crypto map

Interface: Tunnel0
Session status: UP-NO-IKE
Peer: port 500
  IPSEC FLOW: permit 47 host host
        Active SAs: 2, origin: crypto map

Notice that the crypto sessions are still up (UP-NO-IKE), that there is an acknowlwdgement that there are no ISAKMP SAs (UP-NO-IKE), and that the IPSec SAs still exist (Active SAs: 2).

Prior to deletion of the ISAKMP SA for a given session, the output would have looked like this:

Interface: Tunnel0
Session status: UP-ACTIVE
Peer: port 500
IKE SA: local /500 remote /500 Active
  IPSEC FLOW: permit 47 host host
        Active SAs: 2, origin: crypto map

You could also use "show crypto ipsec sa", and observe the packet counts to convince yourself that crypto protected data continues to flow.

    #pkts encaps: 10144, #pkts encrypt: 10144, #pkts digest: 10144
    #pkts decaps: 10424, #pkts decrypt: 10424, #pkts verify: 10424

Sorry for the multiple edits. seem to have gotten carried away with the cut and paste.

Best Regards,

Mike

[Xiang Hong Angela YAN]

Hi Mike,

This is really great. It answers my question in detail. Thank you very

much.

-Angela

[Xiang Hong Angela YAN]

Hi Mike,

Sorry, just come up with further question regarding the same setup.

Per what I know in Cisco. ISAKMP SA,and IPsec SAs is built up per subnet by

default (per session is toooo resource consuming).

If I have simple scenario as below:

- let's say , I keep the Cisco default build up SA per subnet

- and I only set up 1 subnet behind each of the IPsec VPN end point (the

subnet on each end will be in different subnet)

- first, 1 session come up which triggered the VPN tunnel built up( 1

ISAKMP SA + 2 IPsec SAs), traffic of this single session continue flowing

through the tunnel

- When the ISAKMP reachs its timeout. we only have IPsec SAs exist, and

tunnel is still up (which is great)

- at this time, there is another session come up (different source IP and

destination IP). so, we still need to start from negotiate the phase 1 (the

ISAKMP SA), then move to build IPsec SAs. At this point of time, will the

first IPsec SAs for the first session need to torn down per Cisco's default

behavior or we will end up with 2 sets of IPsec SAs for each session ?

- Angela

[michael.leblanc · Accepted solution]

Angela:

We probably need to examine the context of your use of the term "session".

If you were to define a crypto ACL that was comprised of a single Access Control Entry (e.g.: permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255), that would typically* result in the establishment of a single ISAKMP SA, and two IPSec SAs. Lets call that a "crypto session".

As you stated, the establishment of the "crypto session" was triggered by a "session" (e.g.: TCP) between two hosts (each behind their respective tunnel endpoints). Additional sessions (e.g.: TCP) between different hosts at the two sites, do not require additional IPSec SAs. The IPSec SAs previously established, support all traffic defined by the ACE in the crypto ACL.

For each additional ACE in your crypto ACL, you would see the establishment of an additional pair of IPSec SAs (assuming traffic defined by the ACE triggers it).

If you were to define layer 4 criteria (e.g.: TCP port 80) in a crypto ACL, that would be horrendous. IPSec SAs would be negotiated for each destination/source port combination used by a host. E.g.: A single host visiting a single web site (through the crypto tunnel), would typically open multiple TCP sessions (each with a different source port), and IPSec SAs would be negotiated for each TCP session. This would rapidly deplete resources on the crypto endpoints.

We typically use P2P GRE or mGRE with IPSec to exchange dynamic routing info between sites. Because the inter-site traffic is encapsulated within GRE, only a single proxy is required.

edg01#show crypto ipsec sa

interface: Tunnel0
    Crypto map tag: Tunnel0-head-0, local addr

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (/255.255.255.255/47/0)
   remote ident (addr/mask/prot/port): (/255.255.255.255/47/0)

In this case, a single proxy is used. The IP addresses are the external physical IP addresses of the crypto tunnel endpoints. Transport mode is used (hence the 255.255.255.255 masks). The "47" refers to the GRE protocol.

* Note: Sometimes, each of the crypto peers initiates negotiations with the other, resulting in two redundant bidirectional ISAKMP SAs.

Best Regards,

Mike

[Xiang Hong Angela YAN]

Hi Mike,

Your answer waked me up. Many many thanks to you.

-Angela

[michael.leblanc · Accepted solution]

Angela:

Glad to help.

If your questions have been satisfactorily answered, perhaps you may mark the post as "answered". Other forum participants may be more likely to review the post, and derive benefit from it.

If so inclined, you might also consider rating the responses from all responders.

Best Regards,

Mike

[michael.leblanc]

Angela:

With regard to choosing appropriate lifetimes for the ISAKMP and IPSec SAs, I believe the Cisco defaults are 86400 seconds (1 day), and 3600 seconds (1 hour) respectively. The IPSec SA lifetime may also be specified in kilobytes. The IPsec SAs will expire when the defined volume of traffic has transitted the tunnel, or when the SAs have aged sufficiently (whichever occurs first).

I trust that Cisco has chosen these defaults wisely, and that the difference in lifetimes may be representative of the security risk. Although I don't know anything about cracking crypto keys, I suspect the process requires a large sample of captured packets. Assuming you are using IPSec for its encryption (vs. authentication only), there are bound to be many more Encapsulating Security Payload (ESP) packets exchanged between the crypto endpoints than ISAKMP packets. Therefore, I'd be more concerned with restricting the IPSec SA lifetime than the ISAKMP SA lifetime.

I'm not sure that you need to define an ISAKMP SA lifetime shorter than your IPSec SA lifetime. If the ISAKMP SA had expired prior to IPSec re-keying (due to a shorter ISAKMP SA lifetime), and ISAKMP SA negotiation was then triggered, you might be able to identify a revoked X.509 certificate more quickly than if you were to wait for a long ISAKMP SA lifetime to expire (assuming you were using certificates as your ISAKMP authentication method).

We tend to stick with the default ISAKMP SA lifetime. Keep in mind that each SA negotiation imposes a load on your router's resources. If you have a large number of crypto sessions, and you negotiate SAs frequently, that could become an issue.

There are several other factors to consider when provisioning a secure tunnel. In addition to the specified SA lifetimes, attention must be given to your selection of ciphers, hashs, Diffie-Hellman group, and PFS group.These are specified in your ISAKMP Policies, and IPSec transforms.

edg01#sh crypto isakmp default policy

Default IKE policy
Default protection suite of priority 65507
        encryption algorithm:   AES - Advanced Encryption Standard (128 bit keys).
        hash algorithm:         Secure Hash Standard
        authentication method:  Rivest-Shamir-Adleman Signature
        Diffie-Hellman group:   #5 (1536 bit)
        lifetime:               86400 seconds, no volume limit
Default protection suite of priority 65508
        encryption algorithm:   AES - Advanced Encryption Standard (128 bit keys).
        hash algorithm:         Secure Hash Standard
        authentication method:  Pre-Shared Key
        Diffie-Hellman group:   #5 (1536 bit)
        lifetime:               86400 seconds, no volume limit

... more

Best Regards,
Mike