- A virtual community of network engineers
 Home  BookStore  StudyNotes  Links  Archives  StudyRooms  HelpWanted  Discounts  Login
Re: RE : RE : vpn -- SA lifetime posted 11/13/2006
[Chronological Index] [Thread Index] [Top] [Date Prev][Date Next] [Thread Prev][Thread Next]

Hi Richard,
  I've tested and verified this with both Cisco IOS router 12.2(15)T17 and 
  Checkpoint firewalls and the spoke devices with the Cisco Pix version 6.3(5)
  as the hub VPN.  With the HUB VPN IKE timeout setting to 300 seconds
  while both the Cisco router and Checkpoint firewall IKE phase I timeout to
  86400 seconds (1440 minutes on the checkpoint side) and the vpn still works
  without any issues.
  I agree with yout regarding the IETF paper but in practice, vendors do not 
  always implement IETF recommendations.
  Again, feel free to correct me if I am wrong.

Richard Dumoulin <Richard.Dumoulin@xxxxxxxx> wrote:

    v\:* {behavior:url(#default#VML);}  o\:* {behavior:url(#default#VML);}  w\:* {behavior:url(#default#VML);}  .shape {behavior:url(#default#VML);}        st1\:*{behavior:url(#default#ieooui) }                Yes I have noticed that some IOS versions do not follow this and others do (for instance my real 7200 router does but not the 3640 on dynamips) . Also have a look at the book network security principles and practices, the IPSec chapter. The reason is that when IKE is first negotiated, there is still not a trust relationship. Basically it is more secure not to accept any lifetime proposal greater than the one on the server. 
  So absolutely NOT true is a bit harsh. 
  In conclusion, it seems that Cisco behaves differently depending on the IOS version (depending on the programmer?). See for recommendations.
  Regarding Phase 2 lifetimes be careful when working with different vendors. This is what RFC 2407 says:

4.5.4 Lifetime Notification


   When an initiator offers an SA lifetime greater than what the

   responder desires based on their local policy, the responder has

   three choices: 1) fail the negotiation entirely; 2) complete the

   negotiation but use a shorter lifetime than what was offered; 3)

   complete the negotiation and send an advisory notification to the

   initiator indicating the responder's true lifetime.  The choice of

   what the responder actually does is implementation specific and/or

   based on local policy.
  -- Richard
  -----Message d'origine-----
De : tdt_cciesec [mailto:tdt_cciesec@xxxxxxxxx] 
Envoyi : Monday, November 13, 2006 1:02 PM
@ : Richard Dumoulin; Tim; security@xxxxxxxxxxxxxx; ccielab@xxxxxxxxxxxxxx
Objet : Re: RE : vpn -- SA lifetime
  What you said 
"Actually it DOES matter. Try configuring an IKE sa lifetime of an IPSec server (the one with a dynamic map) less than the one of the initiator and you will see that the server rejects phase I."
                                             is absolutely NOT true.  

Pix ----(HUB VPN) --------------(spoke VPN)----Router 

I set "isakmp pol 1 life 360" on the Pix while I have "crypto isakmp pol 10, 
lifetime 86400" on the Cisco router and the vpn still works, and that the Pix
is setup with "crypto dynamic map":

sysopt connection permit-ipsec
isakmp key cisco1234 address netmask no-xauth no-config
isakmp identity address
isakmp enable outside
isakmp policy 1 authe pre
isakmp policy 1 encr 3des
isakmp policy 1 hash md5
isakmp policy 1 group 2
isakmp policy 1 life 86400

crypto ipsec trans cisco esp-3des esp-md5-hmac

crypto dynamic cisco 10 match add 101
crypto dynamic cisco 10 set trans tset
crypto map cisco 10 ipsec-isakmp dynamic cmap
crypto map cisco interface outside

Feel free to correct me if I am wrong. 


Richard Dumoulin <Richard.Dumoulin@xxxxxxxx> wrote:
  Hi Tim,

Actually it DOES matter. Try configuring an IKE sa lifetime of an IPSec server (the one with a dynamic map) less than the one of the initiator and you will see that the server rejects phase I.

Also, having a Phase I lifetime greater than phase II is considered better practice. I see Phase II like the control channel with features like DPD, spi discovery (sync the SPIs. How will the peers synchronise if there is no phaseI?)


-- Richard

-----Message d'origine-----
De : Tim [mailto:ccie2be@xxxxxxxxxx] 
Envoyi : Sunday, November 12, 2006 3:08 PM
@ : 'Richard Dumoulin'; security@xxxxxxxxxxxxxx; ccielab@xxxxxxxxxxxxxx
Objet : RE: vpn -- SA lifetime

Hey Richard,

How ya doing?

Thanks for our quick response. 

Actually, the lifetimes can be different on the 2 peers - at least with
Cisco's implementation. The smaller lifetime wins.

But, that's a different issue than what I was wondering about.

My concern was with respect to the phase 1 versus phase 2 lifetimes on a
given peer.

So, let's say we're configuring Peer 1 and we configure this:

Peer 1

Phase 1 (ISAKMP)

SA lifetime....X

Phase 2 (IPSec)

SA lifetime....Y

Should X be equal to, bigger than or smaller than Y?

Does it matter? Why or why not?

Is there a "Best Practice" when it comes to this?

Thanks again,


-----Original Message-----
From: Richard Dumoulin [mailto:Richard.Dumoulin@xxxxxxxx] 
Sent: Sunday, November 12, 2006 8:56 AM
To: Tim; security@xxxxxxxxxxxxxx; ccielab@xxxxxxxxxxxxxx
Subject: RE : vpn -- SA lifetime

Phase 2 sa lifetimes need to be equal I believe at oth sides.
However Phase 1 sa lifetime of the initiator needs to be smaller than the
one of the server. 

-- Richard

-----Message d'origine-----
De : nobody@xxxxxxxxxxxxxx [mailto:nobody@xxxxxxxxxxxxxx] De la part de Tim
Envoyi : Sunday, November 12, 2006 1:57 PM
@ : security@xxxxxxxxxxxxxx; ccielab@xxxxxxxxxxxxxx
Objet : vpn -- SA lifetime

Hi guys,

Lifetimes, for both the mgmt SA (ISAKMP) and the data SA's (IPSec), can be
configured independently.

That being the case, does it matter what the values are relative to one

IOW, should the lifetime for the mgmt SA be equal to, smaller than or larger
than the data lifetime?

Is there a "Best Practice" when it comes to selecting these values?

I know the lifetime parameter can be left at its default value but I'd like
to know if one value is changed, should the other value also be changed and
how to think about this issue.

Thanks very much for any feedback on this.


Subscription information may be found at:

Any opinions expressed in the email are those of the individual and not
necessarily the company. This email and any files transmitted with it are
confidential and solely for the use of the intended recipient. If you are
not the intended recipient or the person responsible for delivering it to
the intended recipient, be advised that you have received this email in
error and that any dissemination, distribution, copying or use is strictly

If you have received this email in error, or if you are concerned with the
content of this email please e-mail to:

The contents of an attachment to this e-mail may contain software viruses
which could damage your own computer system. While the sender has taken
every reasonable precaution to minimise this risk, we cannot accept
liability for any damage which you sustain as a result of software viruses.
You should carry out your own virus checks before opening any attachments to
this e-mail. 
  Everyone is raving about the all-new Yahoo! Mail beta.

Cheap Talk? Check out Yahoo! Messenger's low PC-to-Phone call rates.