Re: why is SA lifetime kilobyte limit disabled in racoon?

[hsuenaga%iij.ad.jp@localhost]

On 2011/05/20, at 8:22, Greg Troxel wrote:

> 
> Matthias Drochner <M.Drochner%fz-juelich.de@localhost> writes:
> 
>>> But the key
>>> question is what the other implementions do, and what the standard says.
>> 
>> I've just tried OpenBSD's isakmpd (the oldish version in pkgsrc).
>> It initiates a Phase 2 exchange if the soft timeout on its
>> side expires, even if it was responder initially. (It randomizes
>> the soft timeouts to minimize the chance that both sides start
>> the exchange simultanously.)
>> PFC2409 says that both sides can initiate rekeying. "Can" --
>> this is not much of a guideline for implementors
> 
> True, but it seems the original responder initiating a renegotiation is
> the only reasonable behavior.

If both side start rekeying at same time, there is/was a problem of
SA selection.

The two rekeying session makes two pair of IPsec-SAs. racoon can
do this, and IPsec implementations (kernel side) do one of following:

 a. Use oldest IPsec-SA to send and keep all IPsec-SAs to receive(KAME)
 b. Use newest IPsec-SA to send and keep all IPsec-SAs to receive(Fast IPsec)
 c. Use newest IPsec-SA to send/receive and purge older IPsec-SAs

Of cause, c. is bad behavior, but small implementations(kernel side)
may handle only one sessions and one key pair at a time. 
Standards don't prohibit this. This problem is exist between IKE
standards and IPsec standards. It seems IKEv2 makes this more clean.

Today, most implementations select b. or have configuration for it.
And racoon isn't used on other than KAME, Fast IPsec, or Linux(a. or b.)
I think your logic actually works fine. But racoon is old product,
so it doesn't catch recent trends up.

----------
Internet Initiative Japan Inc.

Product Technology Section,
Product Development Division,
SEIL Business Unit

SUENAGA Hiroki <hsuenaga%iij.ad.jp@localhost>