Subject: Re: netkey API has severe problems
To: Charles M. Hannum <firstname.lastname@example.org>
From: None <email@example.com>
Date: 04/04/2000 08:56:43
>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.
>* 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.
>* Because we always use the oldest SA to send a packet, when one
> machine is rebooted, or the SAs get out of sync in some other way,
> no communication is possible until all of the stale SAs time out.
> This is unacceptable.
This is because we have some features missing (like DELETE
information payload handling).
We basically need to follow draft-jenkins-ipsec-rekeying-04.txt.
I think this is the right way to handle the situation.
>In short, the netkey API appears to be extremely suboptimal.
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.
>I propose a few things:
>* If racoon is running, SPD entries should be managed by racoon. It's
> certainly quite wrong to have done in both places, and it is better
> to have all configuration done by racoon in this case.
Not sure what exactly you mean "managed by racoon" here, however, for me
in-kernel SPD makes more sense.
SPDs lives in two places: per-socket and per-packet (IP address
based). SPD entries has two roles:
- whenever incoming packet reaches the socket/ip layer, SPD will
check if the incoming packet make sense against the SPD.
For example, a policy like "in ipsec esp/transport//require" requires
an inbound packet to have ESP.
- whenever outgoing packet reaches the ip layer, SAD entries will be
looked up against the matching SPD entry. If there is no SAD
entries, kernel raises ACQUIRE message to the userland.
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.
>* Expiration of keys (both soft and hard limits) should be handled
> entirely by the kernel -- sending a message to racoon when a new key
> needs to be negotiated.
kernel SA expiration handling is already done in the kernel.
racoon has some duplicated effort for IKE phase 2 timeout handling
which may need correction/improvement.