<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:arial,helvetica,sans-serif;font-size:12pt">Great answer, thanks!<br><br>Igor<div style="font-family: arial,helvetica,sans-serif; font-size: 12pt;"><br><div style="font-family: arial,helvetica,sans-serif; font-size: 13px;"><font face="Tahoma" size="2"><hr size="1"><b><span style="font-weight: bold;">From:</span></b> Matthew Grooms <mgrooms@shrew.net><br><b><span style="font-weight: bold;">To:</span></b> Igor Birman <igor_birman@yahoo.com><br><b><span style="font-weight: bold;">Cc:</span></b> vpn-help@lists.shrew.net<br><b><span style="font-weight: bold;">Sent:</span></b> Sat, July 10, 2010 10:58:04 PM<br><b><span style="font-weight: bold;">Subject:</span></b> Re: [vpn-help] Timeouts?<br></font><br>
On 7/9/2010 4:53 PM, Igor Birman wrote:<br>> Can someone explain timeouts with ShrewSoft VPN Client and Juniper SSG<br>> Routers? My goal is to set it up so it basically never times out - once<br>> a user signs on I want them to stay signed on until they reboot their<br>> computer.<br>> <br>> In Shrew Soft, I have a Key Life Time limit of 86400 seconds for Phase<br>> 1, and 3600 seconds for phase 2, but I am not sure what that means -<br>> will it time out after 24 hours, or will it stay connected?<br>> <br>> On the SSG, the P1 proposal is set to 28800, and the P2 life time is<br>> 3600, but again, I am not sure what that means.<br>> <br><br>Hi Igor,<br><br>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.<br><br>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.<br><br>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.<br><br>Hope this helps,<br><br>-Matthew<br></div></div>
</div></body></html>