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-
Hello,
syzbot found the following crash on:
HEAD commit:0574e200 enetc: Fix tx rings bitmap iteration range, irq h..
git tree: net
console output: https://syzkaller.appspot.com/x/log.txt?x=15f95b4b10
kernel config: https://syzkaller.appspot.com/x/.config?x=bf3aec367b9ab569
dashboar
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
On Sat, Jun 27, 2020 at 1:58 AM Jason A. Donenfeld wrote:
>
> Hi again Hans,
>
> A few remarks: although gre implements header_ops, it looks like
> various parts of the networking stack change behavior based on it. I'm
> still analyzing that to understand the extent of the effects.
> Something lik
Hello. Updating Wireguard from PPA fails.
$ sudo apt list --upgradable
Listing... Done
wireguard-dkms/xenial,xenial 1.0.20200623-1~16.04 all [upgradable
from: 1.0.20200611-0ppa1~16.04]
$ sudo apt upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Cal
> 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
Works fine for me with 4.4.0-184. Try updating?
Hello,
syzbot found the following crash on:
HEAD commit:4e99b321 Merge tag 'nfs-for-5.8-2' of git://git.linux-nfs...
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1013cb2910
kernel config: https://syzkaller.appspot.com/x/.config?x=20c907630cbdbe5
dash
Hello,
syzbot found the following crash on:
HEAD commit:1590a2e1 Merge tag 'acpi-5.8-rc3' of git://git.kernel.org/..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1664afad10
kernel config: https://syzkaller.appspot.com/x/.config?x=bf3aec367b9ab569
das
Hey Cong,
I'm wondering if the below error is related to what you've been
looking at yesterday. AFAICT, there's a simple UaF on the attrbuf
passed to the start method. I recall recently you were working on the
locking in genetlink's family buffers and wound up mallocing some
things, so it seems li
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
#syz fix: genetlink: get rid of family->attrbuf
#syz fix: genetlink: get rid of family->attrbuf
#syz fix: genetlink: get rid of family->attrbuf
On Mon, Jun 29, 2020 at 6:17 PM Jason A. Donenfeld wrote:
>
> Hey Cong,
Hi, Jason
>
> I'm wondering if the below error is related to what you've been
> looking at yesterday. AFAICT, there's a simple UaF on the attrbuf
> passed to the start method. I recall recently you were working on the
> lock
23 matches
Mail list logo
