On Fri, Apr 28, 2006 at 09:49:01AM -0700, jonathan@dsg.stanford.edu wrote:
> In message <20060428142917.GA16401@tanit.enseirb.fr>DEGROOTE Arnaud writes

> >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'm not really familiar with this model but I think I have understood the
basic of the model.

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

I know it is really important to not have to much overcost when we have
ipsec compiled in the kernel and not used, but maybe in a first time, it
will be better to focuss on a working implementation ?

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

It is not far from my first idea ( at least for the configuration ). Do you
think I can work with some domU ?

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

I'm quite familiar with ipv6 but I'm not an expert. I have worked on some
patch for ipv6 on linux kernel.
>   * Good knowledge of mbuf APIs and usage (creating and modifying mbuf
>     chains, change-in-place restrictions, spl restrictions, etc.)

I think I have a basic understanding of the mbuf api, but I'm not an
expert. I didn't write any software using the mbuf api ( I maybe used a few
time mtod on some tun patch ).

>   * 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).

Ok I'am your man so : I have tons of patience :D

Thanks you for all your answer.

-- 
Degroote Arnaud
degroote@enseirb.fr