Subject: Re: Soc : FAST_IPSEC integration for ipv6
To: None <firstname.lastname@example.org>
From: DEGROOTE Arnaud <email@example.com>
Date: 05/02/2006 11:26:05
On Fri, Apr 28, 2006 at 09:49:01AM -0700, firstname.lastname@example.org 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.