WG interface to ipv4

ѽ҉ᶬḳ℠ vtol at gmx.net
Sun May 6 10:58:19 CEST 2018


> Why? Can you outline the threat model?
>
> As I mentioned earlier, to disable v6 socket creation, pass
> ipv6.disable=1 on the kernel command line, or just unload the v6
> module. If you're worried about the Linux v6 stack being a pile of
> scary bugs, then you certainly want to be doing this already, and not
> relying on simply disabling v6 routing within that network namespace,
> which you're doing with the conf.default.disable_ipv6=1. In other
> words, if you don't want v6 for reasons of attack surface, then you
> should actually be disabling v6 properly.

Any piece of software is flawed (threat model), proven by the various 
CVE and others yet to be discovered, that including Linux kernel and its 
userland.

ipv6 deployment/utilization is hardly a matter of black and white, i.e. 
turning it off/on during boot time. Some scenarios call for ipv6 to be 
available whilst others not and thus ipv6 routing is disabled whenever 
not needed in order to tailor mitigation of potential attack surfaces. 
Like ssh can be constrained to a particular ipv socket and so it can be 
set for ntp, dnsmasq, bind, unbound, just to name  a few.

Why would WG take the high route and curtail user control of whether to 
open an ipv4 or ipv6 (someone else may not be keen on ipv4) socket, or both?


> Why is this a matter of network security? WireGuard will ignore
> packets that don't have the correct authentication tag. If you're
> receiving authentic packets, you're receiving authentic packets, and
> the origin shouldn't matter, in terms of the packets' authenticity. In
> other words, if an attacker has stolen a private key, this is the
> problem to address.
Why to offer a the broadest surface (0.0.0.0 - all IPv4 addresses on the 
local machine and with the ipv6 socket open also those) for a potential 
attack in the first place and deprive the user of tailoring/binding WG 
deployment to the respective network layout?
> Anyway, regardless of this, if you want to filter
> out packets coming from a certain interface, a certain subnet, or any
> other characteristics, use netfilter and make these preferences
> explicit in your rules, rather than the implicit details of listening
> sockets.

I would not consider binding WG to a particular iface/subnet an implicit 
choice but rather being explicit, but that is perhaps a matter of 
perspective then. Netfilter rules can easily get convoluted in complex 
scenarios.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4174 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20180506/7e030672/attachment-0001.p7s>


More information about the WireGuard mailing list