In message <20060222224551.GA8006@panix.com>,
Thor Lancelot Simon writes:
>On Wed, Feb 22, 2006 at 05:20:11PM -0500, Christos Zoulas wrote:
>> On Feb 22, 12:22pm, jonathan@Pescadero.dsg.stanford.edu (Jonathan Stone) wro
>te:
>> | 
>> | Aside from NAT_T (mentioned above) and the well-known lack of IPv6 IPsec
>> | support (due to absense of IPv6-fans willing to acutally do the work),
>> | what's FAST_IPSEC missing?
>> 
>> IPSEC_ESP? I don't know.
>
>Christos,
>
>I think you seriously misunderstand the organization of the various
>IPSEC_FOO options -- which are, really, in my opinion at least, the
>fault of the authors/importers of the KAME code, not of the FAST_IPSEC
>code.
>
>Without exception, AFAICT, the IPSEC_FOO options all provide conditional
>compilation of parts of the KAME code.  So if you don't define IPSEC_ESP,
>the KAME code supports only AH: no encryption.  [...]

And, indeed, if one checks options(4), all except IPSEC_NAT_T (added
since) refer to ipsec(4), not fast_ipsec(4).  I don't see a reference
for FAST_IPSEC in options(4), and I have to blame myself for that; but
(in all sincerity) I beleive an accurate, objective description of the
tradeoffs would have been administratively prohibited, at the time
FAST_IPSEC was committed.


>The FAST_IPSEC code is much more sensible: you define the FAST_IPSEC
>option and you get the whole thing, not bits and pieces.  That you
>can't specify options FAST_IPSEC and then conditionally compile in
>parts of the KAME code (without the rest of it!) should not be
>surprising, any more than that you can't attach an sd to an atabus.
>
>I find it really disappointing that new features continue to be
>developed within NetBSD for the KAME stack, ignoring the FAST_IPSEC
>stack entirely; it was my understanding when the FAST_IPSEC code was
>imported that it was intended to replace the KAME stack, 

That was certainly the sentiment at the time. (See emails from Jason
Thorpe, and others) But since no-one has ever stepped up to adding
IPv6 support to FAST_IPSEC, that continues to be a showstopper. *I*
certainly wouldn't ever propose we forcibly yank IPsec out from under
those who choose to use IPv6+KAME-IPSec.


>and, at the
>very least, I think that core should be requiring that new features
>that _we_ add to the KAME stack also be added to the FAST_IPSEC stack
>before they are committed, to avoid serious integration pain later on.

"Me too". But they aren't.  And after Christos' responses, one might
legitimately begin to wonder whether Core grasps the issues, or not.