Hello Vincent,

To put it simply, the ipsec protocol consists of two parts. The first part
(phase 1) is what is called ISAKMP key exchange. This is a protocol that
takes places between the two isakmp-daemons running on the peers (on
m0n0/FreeBSD this is racoon). This phase is where the authentication and
initial keying takes place. On the m0n0, only a pre shared text string can
be used as a key (commonly referred to as a PSK). When the negotiation
succeeds it will result in a ISAKMP security association, based on the PSK.
This link will further on be used to send new _random_ keys for the IPSEC
SA:s. The IPSEC SA:s will in turn be used to encrypt the traffic with the
random keys.

So, the P1 can be seen as a "control channel" for the P2. P1 is performing a
more or less "intelligent" key exchange, and P2 is just static "dumb" rules
for how to encrypt the packets in question. For this reason the only real
vulnerable transaction is the initial P1 negotiation. If this is compromised
(or maybe even brute force cracked?) you could theoretically intercept the
keys used for the P2 transactions, and see the traffic the IPSEC is trying
to hide from prying eyes. That's why the P1 lifetime should be as long as
possible, especially when dealing with PSK:s. The P2 is not as vulnerable as
the only thing you can get if you'd brute force it is the content of the
data transmitted during that particular Ipsec SA:s lifetime. This is a
reason for making the P2 shorter.

Hope it makes some sense to you! =)

// Thomas Hertz

> [1] - P1 value is for the tunnel itself. It's similar to dial-on-demand
> idle timeout. The tunnel is closed if there is no network activity for a
> given time period. IPSec are not persistent, by design.


> 
> [2] - P2 value defines a sort of validity period for each newly created
> SA, in term of limited lifetime (the SA being used or not), for security
> reasons.
> 
> [3] - If P2 > P1, many SA are generated and exchanged during the same
> tunnel "session". On the other hand, if P1 > P2, remaining SA are kept
> for future use in another tunnel "session".
> 
> Please let me know where I'm right and where I'm wrong.
> 
> I've seen configurations where P1 > P2 and others with P2 > P1,
> depending on the hardware used. As far as I know, each vendor has a
> different approach of the topic, so it's very confusing and difficult to
> get a good idea of how things work...
> 
> Question: when in use, will a tunnel transparently renew its SA without
> having to disconnect and then reconnect? Will it delay the SA
> re-negotiation until there is no activity on the link. Or will it cache
> SA for further use?
> 
> As long as I use only m0n0wall for all my tunnels, I personnaly don't
> need vendor specific compatibility values. I just would like to minimize
> the tunnel expiration annoyance, from my users' point of view. What are
> the best values in this situation?
> 
> 
> Thanks in advance,
> 
> -- Vincent
> 
>