In message <20060428142917.GA16401@tanit.enseirb.fr>DEGROOTE Arnaud writes
>Hi list.
>
>I'm really interested in working on a NetBSD summer of code, particulary
>the integration of fast_ipsec into the ipv6 stack.
>
>I have already some questions about it. I hope you can enlight me.
>
>It seems to have some INET6 code into the netipsec implementation. Can I
>trust this code or it is completely untested ? 

It's completely untested.

Actually, it's known to cause a quick kernel panic if you try to send
packets through that codepath.  I put in some bandaids to ignore IPv6
policies and to drop packets (instead of panicking); and also to print
a warning if anyone tries to add IPv6 IPsec rules to a FAST_IPSEC
kernel.

>The initial netipsec stack seems to share some code with the OpenBSD
>implementation of ipsec. Do you think I can check the implementation of
>ipsec in the current OpenBSD to have some idea how to integrate netipsec
>into our ip6 stack ?

That's a good place to look for ideas; but all the details of how
demux is done, and most of the internal APIs, have changed.

You may be better off rewriting the KAME code to use a continuation-based
model. (The FAST_IPSEC code uses the term "callbacks", and has a set of
*_cb functions, but they're really best thought of continuations.
Provided you're familiar with a continuation-passing model, that is).

I beleive there are also several optimizations in the IPv4 FAST_IPSEC
code that we'd want to replicate into IPv6.  Not least of which is
minimizing overhead when IPsec is not in use, i.e., when no IPsec
policies (rules) are configured.

Can I suggest focusing first on receive-side pricessing?  That way you
can be sure you're receiving well-formed packets from the remote peer.

Set up two KAME IPv6 IPSEC peers. Configure static-keyed SAs (to avoid
IKE) between them. Then, replace one KAME IPsec peer with a FAST_IPSEC
peer, preserving the IP address and KAME IPsec configuration.  Then
you can start implmeenting and debugging the IPv6 IPsec receive path,
using ping6 to generate traffic.


>The last thread about ipsec and fast-ipsec on tech-kern speaks about some
>odd problems with fast_ipsec ( some crash with ping and fast_ipsec ). Has
>the problem been resolved or may I resolve it during the SoC ( if I can, of
>course ) ?

I beleive the panic from ``ping6 ::1'' is avoided, but only by making
IPv6 IPsec (in FAST_IPSEC kernels) a black-hole. Whether you call that
a fix is a matter of taste. For this project, I'd look for a candidate with:

  * familiarity with IPv6  usage and network administration;

  * Good knowledge of mbuf APIs and usage (creating and modifying mbuf
    chains, change-in-place restrictions, spl restrictions, etc.)
   
  * Good skills with BSD kernel debugging.

  * Lots and lots and *lots* of patience. (Debugging  mis-processing
    of encrypted traffic is extremely frustrating; until *everything*
    works correctly, all you get is junk).

That last point may tempt you to focus on AH-only first; however,
that's a slippery slope.  In order to make effective use of hardware
accelerators, FAST_IPSEC does ESP+AH together one fell swoop. So an
AH-only doesn't really help you with ESP (which is what everyone
really wants).