Development discussion of WireGuard
 help / color / mirror / Atom feed
From: Reid Rankin <reidrankin@gmail.com>
To: Arti Zirk <arti.zirk@gmail.com>
Cc: wireguard@lists.zx2c4.com
Subject: Re: Thoughts on wg-dynamic
Date: Mon, 6 Apr 2020 05:46:02 -0400	[thread overview]
Message-ID: <CAMaqUZ0mx-3RtcNU4WQReGHWNgZ__b+AqpgHQKJpkHwpaqM_4A@mail.gmail.com> (raw)
In-Reply-To: <c41fb7b6ba61a41804ef50a7c92857367c51a36e.camel@gmail.com>

That's a neat tool, and I'd probably use it in my own projects -- I'm
a big fan of the shell-script-only approach for userland tools -- but
the algorithm it uses has a few rough edges I'd prefer didn't get
standardized:

- The hash is taken over a (newline-terminated!) Base64-encoded key
and not the raw bytes; there's nothing else in the protocol that would
require implementations to have a Base64 encoder. (This might matter
in a microcontroller implementation.) It wouldn't be hard to pipe to
`base64 -d` before hashing, which would fix this.
- I'm a fan of SHA-256 in general, but again, there's nothing else in
the protocol that would require implementers to have a SHA-256 engine.
(This would definitely matter in a microcontroller implementation.)
OTOH, `sha256sum` is a commonly available utility and reasonable to
use in a bash script, while `b2sum` is not so much.

My prototype also uses the `(subnet & mask) | (hash & ~mask)`
construction, though I use the full fe80::/10 space, instead of
fe80::/64. There's a decent argument to be made for just using the
/64, though -- it's the "interface identifier" portion of the address,
which is why that's what RFC 3972 does as well. That said, I'm not
sure there's quite the same need for subnetting in a link-local
address space. (I also feel like the subnet id/interface id dichotomy
is going the way of IPv4 class-based routing, and was probably only
conceived of as a clever ploy to keep ISPs from screwing everyone over
by only handing out out /120s.)

I've taken another look at RFC 3972, and the only way it would work
here would be by using well-known modifier and Sec parameters of zero
-- and it would force reliance on SHA-1. So I'm now thinking we don't
bother.

In any case, that makes at least two independent engineering efforts
that both use `(subnet & mask) | (hash & ~mask)` rather than using
subnet as a prefix for the hash.

--Reid

  reply	other threads:[~2020-04-06  9:47 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-05 23:43 Reid Rankin
2020-04-06  8:28 ` Arti Zirk
2020-04-06  9:46   ` Reid Rankin [this message]
     [not found] ` <CAFX-c4sfzqEwCk+1Ec7dRtVD60jougU1w9=V-cAQ-8Qk0S+HZg@mail.gmail.com>
2020-04-06  9:46   ` Reid Rankin

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=CAMaqUZ0mx-3RtcNU4WQReGHWNgZ__b+AqpgHQKJpkHwpaqM_4A@mail.gmail.com \
    --to=reidrankin@gmail.com \
    --cc=arti.zirk@gmail.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).