Hi,
Has anyone thought about a standardized WireGuard IPv6 ULA generated from the
PublicKey ?
WireGuard Unique Identifier (WUI) allowing a host to assign iteslf a unique
64-Bit IPv6 interface identifier (WUI-64) ?
Possibly picking off bits of a hash of the PublicKey ?
For mass deployments, co
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 04/12/17 16:52, Lonnie Abelbeck wrote:
> Hi,
>
> Has anyone thought about a standardized WireGuard IPv6 ULA
> generated from the PublicKey ?
>
> WireGuard Unique Identifier (WUI) allowing a host to assign iteslf
> a unique 64-Bit IPv6 interface
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 rejected it citing the KISS
pr
https://lists.zx2c4.com/pipermail/wireguard/2017-April/001177.html
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
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
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 A
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 p
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 d
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 +
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 pa
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
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 complexi
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 proposal
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 form
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. Link-
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 about
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:
Deriv
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 means
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 or
> 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 respo
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 initi
> 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 to
22 matches
Mail list logo