In article <E1FC4o2-00020p-00@smeg.dsg.stanford.edu>,
Jonathan Stone  <jonathan@dsg.stanford.edu> wrote:
>
>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? 

I agree. A message from you or thor (who are the people most familiar
with the code to core) would help. Can you please send a message of
what's needs to be done now?

>
>>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?

Yes, I agree. I will see what's involved in getting the NAT_T code
to compile first and fix the options *after* we fix the ping -s 3000
and the mtu issues.

christos