Development discussion of WireGuard
 help / color / mirror / Atom feed
From: Luiz Angelo Daros de Luca <luizluca@gmail.com>
To: "Toke Høiland-Jørgensen" <toke@toke.dk>
Cc: Roman Mamedov <rm@romanrm.net>,
	Reid Rankin <reidrankin@gmail.com>,
	ch@ntrv.dk, WireGuard mailing list <wireguard@lists.zx2c4.com>
Subject: Re: Standardized IPv6 ULA from PublicKey
Date: Mon, 29 Jun 2020 15:49:30 -0300	[thread overview]
Message-ID: <CAJq09z7NoX6f+MzYgvhQkZ7oe8aR8_AMqX+YWZn1MHSUArybPA@mail.gmail.com> (raw)
In-Reply-To: <87lfk6gjax.fsf@toke.dk>

It simply does not make sense to set ULA automatically. ULA fc00::/7
is subdivided in fc00::/8 and fd00::/8. The former would use some
global registry while the second one
uses a random 40-bit subnet prefix (to avoid conflicts). You would
need to share this 40-bit random value with every node in order to
have a common /48 prefix. Besides that,
It would not make sense to have a full /48 for a single VPN network.
It should be subdivided into common /64 appending another 16-bit
subnet id. So, in the end, you would
need a way to pass the ULA prefix (40-bit + 16-bit). ULA should be
configured just like any other global address.

If ULA is not the topic, we might need to change the thread name. The
issue here is really about having Link Local Address automatically
set.

I know that Wireguard wants to be as clean as possible not including
any automatic setup logic. However, most protocols that would do that
job, at least, expect LL to be present (DHCPv6).
LL is set by the kernel for ethernet devices but not for TUN
interfaces, probably because there is simply no "link" on a L3
interface. There is, for example, a request to have it set for OpenVPN
(https://community.openvpn.net/openvpn/ticket/415). I would expect
IPv6 LL address to be present in any default scenario. I just don't
know what would be the one to set it up. For ethernet
devices, it is the kernel itself. For wireguard, there is a shared
responsibility between userland (wg and wg-quick) and kernel. However,
as a required feature, I would not depend on any software
that is not required. If wg-quick is optional, it would not be the
place to set the LL address. Maybe wg would be the one to set it as
soon as a IPv6 stack is up for a wireguard interface, even when there
is
no intention to use IPv6. However, if wg is also "optional", it would
be nice if the kernel API could require the userland code to inform
the interface-id (or set a link local address) before IPv6 is up.
For wireguard, LL address setup also means to set allowed IPs automatically.

Regarding what interface id should be used, even random value is
acceptable but not ideal for management as it could be used as part of
device ID.
Wireguard could use a simple algorithm to map pubkey 256-bit into a
64-bit value, just like ethernet 48-bit is mapped to a 64-bit value.
It can be as
simple as getting the last 64-bit from pubkey or any already in use
form of hash. Keep it as simple as possible. It is not expected to be
secret.
The privacy extension, if used, is for automatically generated global
addresses, not link-local one.

Keep in mind that LL is not expected to be a replacement for any
global address (ULA or Internet one). They should still be set. At
least for Linux, no
"normal" process would really use LL addresses without specifying the
outgoing interface ("fe80::...%interface"), which might limit what you
can do with it.

In summary, my suggestions:

1) LL address should be set automatically by wg, better if required by
kernel interface or even set up by kernel module.
2) interface identification can be derived from pubkey with a simple
algorithm. It does not need to be a secure hash.

Regards,
---
     Luiz Angelo Daros de Luca
            luizluca@gmail.com

      parent reply	other threads:[~2020-06-29 18:49 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-04 16:52 Lonnie Abelbeck
2017-12-04 17:14 ` Aaron Jones
2017-12-05  2:53 ` Luis Ressel
2017-12-05  3:31   ` Jason A. Donenfeld
2020-06-24 15:37     ` Florian Klink
2020-06-24 17:08       ` Chriztoffer Hansen
2020-06-24 17:30         ` JuniorJPDJ
2020-06-27 21:43         ` Reid Rankin
2020-06-28 10:15           ` Arti Zirk
2020-06-28 15:19             ` Derrick Lyndon Pallas
2020-06-29 10:22           ` Toke Høiland-Jørgensen
2020-06-29 10:31             ` Roman Mamedov
2020-06-29 10:52               ` Justin Kilpatrick
2020-06-29 11:03               ` Toke Høiland-Jørgensen
2020-06-29 11:38                 ` Roman Mamedov
2020-06-29 12:15                   ` Toke Høiland-Jørgensen
2020-06-29 17:01                     ` Arti Zirk
2020-06-29 18:01                       ` Jason A. Donenfeld
2020-06-29 19:58                         ` Reid Rankin
2020-06-30  1:24                           ` Jason A. Donenfeld
2020-06-30  8:01                             ` Reid Rankin
2020-06-29 18:49                     ` Luiz Angelo Daros de Luca [this message]

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=CAJq09z7NoX6f+MzYgvhQkZ7oe8aR8_AMqX+YWZn1MHSUArybPA@mail.gmail.com \
    --to=luizluca@gmail.com \
    --cc=ch@ntrv.dk \
    --cc=reidrankin@gmail.com \
    --cc=rm@romanrm.net \
    --cc=toke@toke.dk \
    --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).