Subject: Re: IPSEC in GENERIC
To: Christos Zoulas <christos@zoulas.com>
From: Jonathan Stone <jonathan@dsg.stanford.edu>
List: tech-kern
Date: 02/22/2006 16:58:05
In message <20060222235336.3DE4A56534@rebar.astron.com>,
Christos Zoulas writes:

>On Feb 22,  3:33pm, jonathan@Pescadero.dsg.stanford.edu (Jonathan Stone) wrote
>:
>-- Subject: Re: IPSEC in GENERIC
>

>| "Me too". But they aren't.  And after Christos' responses, one might
>| legitimately begin to wonder whether Core grasps the issues, or not.
>
>They are not integrated because the majority of people (that I know
>of) don't use FAST_IPSEC. 

Well, speaking just for myself, the majority of NetBSD users I know
either don't use IPsec at all, or don't use it on the majority of
their machines.

>Maybe I don't understand the issues regarding
>FAST_IPSEC, but how can you generalize and say that the rest of core
>doesn't either?

But I did *not* do that. I said one might legitimately begin to wonder
about it, and that's *all* I meant.  And I think that was fair enough
too, given that else from Core has commented yet.


>It would have helped if someone made the statement when FAST_IPSEC
>was imported that this was the preferred way and mark the old IPSEC
>options for compatibility or IPV6 use. 

I'll agree with that.  But what I recall of the discussion at the time
is that a small, but *very* senior group of developers (particularly
w.r.t networking issues), who I'll call the Usual Suspects (I'm sure
Christos knows who they are) made fairly strong statements that,
indeed, NetBSD should move to Sam Leffler's version of opencryto and
FAST_IPSEC, as being clearly superior to the existing alternatives.

Yes, it'd be better if that direction had come from Core, and the code
and man-pages was so marked. But if one considers the Core membership
at the time, then (speaking just for myself) I think that'd have been
quite a challenge. Don't you think? 


>Then we could have put some
>effort to fix the FAST_IPSEC pr's specially the 'ping -s 3000' where
>anybody can crash the kernel. I am not saying that the KAME ipsec
>code is bug free, but at least joe user cannot crash the kernel on
>demand.

So maybe, we could, collectively, put in some of that effort now?