From: David Gwynne <david@gwynne.id.au>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: wireguard@lists.zx2c4.com
Subject: Re: OpenBSD kernel implementation
Date: Thu, 13 Dec 2018 08:34:54 +1000 [thread overview]
Message-ID: <F48C44BC-EB3C-4399-A1A4-A7FF6B2691DF@gwynne.id.au> (raw)
In-Reply-To: <d9c01aa2-9dab-44b0-d743-a93ff7936e38@zx2c4.com>
Hi Jason and Matt,
Just have a question below.
> On 12 Dec 2018, at 01:29, Jason A. Donenfeld <Jason@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.
>
> Regards,
> Jason
> _______________________________________________
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
next prev parent reply other threads:[~2018-12-12 22:35 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-11 13:24 OpenBSD kernel implementation Matt
2018-12-11 15:29 ` Jason A. Donenfeld
2018-12-11 21:22 ` Matt
2018-12-12 22:34 ` David Gwynne [this message]
2018-12-12 22:36 ` Jason A. Donenfeld
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=F48C44BC-EB3C-4399-A1A4-A7FF6B2691DF@gwynne.id.au \
--to=david@gwynne.id.au \
--cc=Jason@zx2c4.com \
--cc=wireguard@lists.zx2c4.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).