OpenBSD kernel implementation
david at gwynne.id.au
Wed Dec 12 23:34:54 CET 2018
Hi Jason and Matt,
Just have a question below.
> On 12 Dec 2018, at 01:29, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
> Hi Matt,
> Exciting to see you working on this. However, I'm afraid the
> implementation you describe sounds deeply flawed and kind of misses
> the point of WireGuard.
> On Tue, Dec 11, 2018 at 2:24 PM Matt wrote:
> > Currently, I want to take all the code that doesn't need to be in the
> > kernel and move it to userspace, which is essentially the handshake
> > code, timeout timers and state machine functions. What is left is
> > essentially the transport function (IPSEC transform equivalent),
> > peforming simple crypto on incoming/outgoing packets. This design is
> > somewhat similar to how IPSEC is currently implemented in OpenBSD. I
> > believe this is a reasonable approach, but welcome comments on things I
> > may not have considered.
> Do not do this. This is entirely unacceptable and wholly contrary to
> the design approach of WireGuard. The transport layer and handshake
> layer exist on the same state machine, and I designed the handshake
> specifically to be extremely simple and implementable in kernel space.
> I'm happy to help you clean up your current approach -- which seems
> nicer and closer to the goal -- but your proposed separated approach
> is really deeply flawed, and overly complex. Do not make this mistake.
Did you tie the handshake and data state machines together so you would only have to handle packet crypto operations with a single set of keys? If so, what happens to data packets that are in flight while the handshake is happening? Do you keep the old keys around for a bit to allow operation on them?
> Rather, let's clean up your current WIP together. If you're on IRC,
> I'm happy to discuss with you there (I'm zx2c4 on Freenode) and we can
> get this into shape.
> WireGuard mailing list
> WireGuard at lists.zx2c4.com
More information about the WireGuard