Subject: Re: netkey API has severe problems
To: None <firstname.lastname@example.org>
From: Charles M. Hannum <email@example.com>
Date: 04/03/2000 22:43:35
>>Let's review some of the bad things that happen with racoon. Many of
>>these problems will affect *any* IKE/ISAKMP daemon, not just racoon.
>>* It's possible to get the SPD and racoon out of sync, because racoon
>> does not manage the SPD itself.
> This is because racoon does not follow what kernel says
> (we need to configure two locations exactly the same).
> racoon should grab policy configuration from the kernel and compile
> IKE phase proposal based on it. sakane (cc'ed) is working on it.
I'm not convinced that's the right choice. With that approach, I have
to configure half of IPsec with setkey and half with racoon.conf.
That seems poor.
>>* It's possible for SAD entries to expire (or reach their soft limit)
>> at a different time in the kernel than they do in racoon (c.f. the
>> timeout() lossage mention in my racoon PR).
> racoon manages IKE phase 2 timeouts, not kernel SA timeouts.
> When kernel SA reaches its timeout, a PF_KEY message (EXPIRE) will
> be transmitted to the userland and userland IKE daemon (racoon) would
> notice the lifetime expire.
My point is that you have two places handling the *same* timeout. It
should be done in *one* place. I don't particularly care which.
>> actually, we follow RFC2367. It is because RFC2367 that we can
>> run isakmpd at ease on top of KAME-based IPsec kernel. If we need
>> to talk about changing it, we need to revise RFC2367, not just by
>> hacking NetBSD. If we introduce incompatibility (like "less frequent
>> ACQUIRE") we'll degreade chances to run other IKE daemons.
The problem with the way ACQUIREs work are:
a) We can get a flood of unusable SAs in bad cases. This is
b) It makes '/use' (as opposed to `/require') almost useless, because
we'll try to negotiate a new SA for every 10 packets. This is also
unacceptable. We should not be continually trying to renegotiate
after a failure. At the very least, this should be based on some
clock timer, not on a per-packet basis.
>> None of the above can be handled by userland. If we do not put
>> SPD entries into userland, we end up sending every packet to the
>> userland (like FreeBSD divert socket) so that racoon can check if
>> the packet makes sense.
> correction: 2nd line should read "SPD entries into kernel".
The point was to have racoon manage the SPD *in the kernel*.