[vpn-help] Timeouts?

[Matthew Grooms]

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