[vpn-help] Timeouts?

[Igor Birman]

Great answer, thanks!

Igor



________________________________
From: Matthew Grooms <mgrooms at shrew.net>
To: Igor Birman <igor_birman at yahoo.com>
Cc: vpn-help at lists.shrew.net
Sent: Sat, July 10, 2010 10:58:04 PM
Subject: Re: [vpn-help] Timeouts?

On 7/9/2010 4:53 PM, Igor Birman wrote:
> Can someone explain timeouts with ShrewSoft VPN Client and Juniper SSG
> Routers? My goal is to set it up so it basically never times out - once
> a user signs on I want them to stay signed on until they reboot their
> computer.
> 
> In Shrew Soft, I have a Key Life Time limit of 86400 seconds for Phase
> 1, and 3600 seconds for phase 2, but I am not sure what that means -
> will it time out after 24 hours, or will it stay connected?
> 
> On the SSG, the P1 proposal is set to 28800, and the P2 life time is
> 3600, but again, I am not sure what that means.
> 

Hi Igor,

The most important thing to remember is that the IKSAMP SA lifetime ( phase1 
rekey time ) and the IPsec SA lifetime ( phase2 rekey time ) need to match on 
both the gateway and the client. If they both match, new SAs should be 
re-negotiated as needed with no packet loss. You can think of ISAKMP as the 
control channel and IPsec as the data channel. IKE ( internet key exchange ) is 
a protocol standard that wraps the ISAKMP specification.

The slightly longer answer is that ISAMP SA key material is used to protect IKE 
conversation. That is, the conversation that handles peer and user 
authentication, client configuration ( if applicable ), IPsec SA negotiation, 
notification messages, etc. IPsec SA key material is used to protect IP traffic 
between the two peers ( packets that match IPsec security policies ). Both types 
of SAs could potentially use a different set of security parameters ( ciphers, 
message authentication algorithms, etc ) which is why two separate proposal 
definitions ( phase1 and phase2 ) are required. Traditionally, a lot less 
traffic is passed during an IKE conversation which is why the lifetime is 
usually longer ( 24h vs 1h by default ). DH Exponentiation ( used to derive key 
material ) is a CPU intensive operation, so it makes sense that you use one 
parent SA to securely build lots of additional SA key material. PFS ( or perfect 
forward security ) is a phase2 option that forces a new DH Exponentiation for 
each new SA negotiation. In other words, its a bit more secure but takes more 
CPU cycles.

In any case, there are no messages exchanged between peers when an SA expires. 
That's why its important to make sure the lifetime matches on both ends. 
Otherwise when an SA is expired by one peer, the other peer may still attempt to 
use that SA to protect an important message or IPsec traffic. When this happens, 
communication obviously breaks down.

Hope this helps,

-Matthew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.shrew.net/pipermail/vpn-help/attachments/20100711/45ef838b/attachment-0001.html>