Re: Standardized IPv6 ULA from PublicKey

2020-06-30 Thread Reid Rankin
> Fun fact: initial versions of WireGuard from years ago weren't like > this. We wound up redoing some crypto and coming up with the `_psk2` > variant for this purpose. I'm glad it's useful. I'm interested to > learn: what are you doing this for? Got any code online? That's a dangerous question

Re: Standardized IPv6 ULA from PublicKey

2020-06-29 Thread Jason A. Donenfeld
On Mon, Jun 29, 2020 at 1:59 PM Reid Rankin wrote: > Well, it looks like you've discovered the method behind my madness! > Specifically, while a handshake *initiator* must know the public key > of the responder it's trying to talk to, the *responder* doesn't need > to know anything about the

Re: Standardized IPv6 ULA from PublicKey

2020-06-29 Thread Reid Rankin
> 2. There is very little practical utility. In WireGuard, both sides > must _already_ preshare their public keys, and there's no way around > this. Well, it looks like you've discovered the method behind my madness! Specifically, while a handshake *initiator* must know the public key of the

Re: Standardized IPv6 ULA from PublicKey

2020-06-29 Thread Luiz Angelo Daros de Luca
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

Re: Standardized IPv6 ULA from PublicKey

2020-06-29 Thread Jason A. Donenfeld
Hi folks, We're probably not going to do this, for two reasons: 1. The security model of hashing keys down to tiny hash lengths is dubious, and opens us up to all manner of interesting collision attacks. Cryptkey routing implies a strong binding between IP and pubkey. A hash with collisions

Re: Standardized IPv6 ULA from PublicKey

2020-06-29 Thread JuniorJPDJ
IMO link-local should be assigned by core - RFC4291 which is defining IPv6 clearly says: "Its required Link-Local address for each interface." https://tools.ietf.org/html/rfc4291#section-2.8 On 6/24/20 7:08 PM, Chriztoffer Hansen wrote: On Wed, 24 Jun 2020 at 17:37, Florian Klink wrote:

Re: Standardized IPv6 ULA from PublicKey

2020-06-29 Thread Arti Zirk
On E, 2020-06-29 at 14:15 +0200, Toke Høiland-Jørgensen wrote: > In general I'd say that deviating from the RFC needs a good reason. > Expanding the number of bits we can use for the identifier may be a > good reason to expand the LL interface ID width (although I'm not > actually too worried

Re: Standardized IPv6 ULA from PublicKey

2020-06-29 Thread Toke Høiland-Jørgensen
Roman Mamedov writes: > On Mon, 29 Jun 2020 13:03:40 +0200 > Toke Høiland-Jørgensen wrote: > >> Eh? This is specified pretty clearly in RFC4291, section 2.1: > > It also says: > > - > > 2.5.6. Link-Local IPv6 Unicast Addresses > >Link-Local addresses are for use on a single link.

Re: Standardized IPv6 ULA from PublicKey

2020-06-29 Thread Roman Mamedov
On Mon, 29 Jun 2020 13:03:40 +0200 Toke Høiland-Jørgensen wrote: > Eh? This is specified pretty clearly in RFC4291, section 2.1: It also says: - 2.5.6. Link-Local IPv6 Unicast Addresses Link-Local addresses are for use on a single link. Link-Local addresses have the following

Re: Standardized IPv6 ULA from PublicKey

2020-06-29 Thread Toke Høiland-Jørgensen
Roman Mamedov writes: > On Mon, 29 Jun 2020 12:22:49 +0200 > Toke Høiland-Jørgensen wrote: > >> Reid Rankin writes: >> >> > Each IPv6 network device is *required* to have a link-local >> > address by the RFC >> >> Given this > > What you quoted is the shakiest statement of the entire

Re: Standardized IPv6 ULA from PublicKey

2020-06-29 Thread Justin Kilpatrick
I'm assigning fe80 addresses derived from device MAC addresses for my own Babel + WireGuard use case. To chip in on this I don't think WireGuard should add any 'auto-magical' behavior into it's core code. There are significant advantages to keeping core WireGuard ultra lean and pushing

Re: Standardized IPv6 ULA from PublicKey

2020-06-29 Thread Roman Mamedov
On Mon, 29 Jun 2020 12:22:49 +0200 Toke Høiland-Jørgensen wrote: > Reid Rankin writes: > > > Each IPv6 network device is *required* to have a link-local > > address by the RFC > > Given this What you quoted is the shakiest statement of the entire proposal. Might be a cool idea and all, but I

Re: Standardized IPv6 ULA from PublicKey

2020-06-29 Thread Toke Høiland-Jørgensen
Reid Rankin writes: > Each IPv6 network device is *required* to have a link-local > address by the RFC Given this, and how obvious it is to just hash the pubkey into a LL address, I think the right thing to do would just be to take the hashing scheme you proposed and put it into the wg kernel

Re: Standardized IPv6 ULA from PublicKey

2020-06-28 Thread Derrick Lyndon Pallas
I've been using something similar for ORCHIDv2-ish addressing, q.v. [1]. from base64 import b64decode from hashlib import shake_128 from ipaddress import IPv6Network public_key = b64decode(...) secret = "somesecret".encode('utf-8') network = IPv6Network("2001:20::/28") hash = shake_128(secret

Re: Standardized IPv6 ULA from PublicKey

2020-06-28 Thread Arti Zirk
On L, 2020-06-27 at 17:43 -0400, Reid Rankin wrote: > Luckily, Blake2s is a simple and elegant algorithm, and in an effort > to get some working code out there I've [implemented][1] it in ~100 > lines of Bash script. It turns out that Python includes blake2s implementation that seems to work with

Re: Standardized IPv6 ULA from PublicKey

2020-06-27 Thread Reid Rankin
I've been working on this a bit from a completely independent perspective: bootstrapping embedded systems which have a persistent keypair, but no persistent storage for stuff like `AllowedIPs` assignments. In my usecase, the by-convention assignment of an IPv6 link-local address to each WireGuard

Re: Standardized IPv6 ULA from PublicKey

2020-06-24 Thread Chriztoffer Hansen
On Wed, 24 Jun 2020 at 17:37, Florian Klink wrote: > Deriving an IPv6 link-local address from the pubkey and adding it to the > interface should be a no-brainer and sane default, and already fix Babel > Routing (and most other issues) for "point-to-point tunnels" > (only one peer, both sides set

Re: Standardized IPv6 ULA from PublicKey

2020-06-24 Thread Florian Klink
Hey, Has anyone thought about a standardized WireGuard IPv6 ULA generated from the PublicKey ? This was indeed already discussed, albeit not for ULAs, but link-local addresses (fe80::/64). IIRC, Jason rejected it citing the KISS principle -- and I fully agree with that. Adding a hundred small

Re: Standardized IPv6 ULA from PublicKey

2017-12-04 Thread Jason A. Donenfeld
https://lists.zx2c4.com/pipermail/wireguard/2017-April/001177.html ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Standardized IPv6 ULA from PublicKey

2017-12-04 Thread Luis Ressel
On Mon, 4 Dec 2017 10:52:28 -0600 Lonnie Abelbeck wrote: > Hi, > > Has anyone thought about a standardized WireGuard IPv6 ULA generated > from the PublicKey ? This was indeed already discussed, albeit not for ULAs, but link-local addresses (fe80::/64). IIRC, Jason