Subject: Re: netkey API has severe problems
To: Charles M. Hannum <email@example.com>
From: None <firstname.lastname@example.org>
Date: 04/04/2000 09:04:18
>>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.
last sentence may be bogus, I misread what you have proposed.
>>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.
correction: 2nd line should read "SPD entries into kernel".