Subject: Re: IPSEC in GENERIC
To: Christos Zoulas <christos@astron.com>
From: Jonathan Stone <jonathan@Pescadero.dsg.stanford.edu>
List: tech-kern
Date: 02/22/2006 17:41:35
In message <dtj1m6$che$1@sea.gmane.org>, Christos Zoulas writes:
>In article <E1FC4o2-00020p-00@smeg.dsg.stanford.edu>,
>Jonathan Stone <jonathan@dsg.stanford.edu> wrote:
[Jonathan snips hage amounts, to:
> [...] 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?
I'll act on that, tho' I'll probably run it by you and Thor to see if
there's anything I've missed And please disregard my off-list message,
you've just answered it.
>>>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.
Wow, thank you (very sincerely).