netdev - Re: [PATCH] net:l2tp: Allow MAC to be configured via netlink

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 24 Jan 2018 13:04:06 +0100
From:   Guillaume Nault <g.nault@...halink.fr>
To:     Isaac Lee <isaac.lee@...iedtelesis.co.nz>
Cc:     netdev@...r.kernel.org
Subject: Re: [PATCH] net:l2tp: Allow MAC to be configured via netlink

On Wed, Jan 24, 2018 at 04:58:44PM +1300, Isaac Lee wrote:
> The linux kernel by default uses random MAC address
> for l2tp interfaces. However, there are situations
> where it is desirable to have a deterministic MAC address.
> 
> A sample scenario would be where the host IP stack is attached
> directly to a tunnel hence the "random" address is now propagated
> via ARP/ND to the other end of the tunnel. If the device reboots,
> a new MAC is used and the communication over the tunnel will be
> disrupted until the new MAC address is re-learned by the peer.
> Therefore it can be useful to have the mac address the same across
> reboots.
> 
> The patch makes the MAC address to be configurable via
> netlink so that a userspace program can specify what MAC address to
> use at interface creation time in the kernel.
> 
Have you considered implementing rtnl_link_ops? I'm a bit worried about
duplicating more features from rtnl_newlink() in l2tp_netlink.c. What
about creating an l2tpeth device in a different network namespace, or
attached to a master device? Are we going to duplicate these features
from rtnl again when the need arise?

I haven't had time to think much about it, and I'd expect implementing
rtnl_link_ops for l2tpeth would be a bit more involved. But IMHO, it's
worth a try.

In case that's too much work for your usecase, can't you just update
the MAC address after creation? l2tpeth implements .ndo_set_mac_address
now.

Sorry if it looks like I'm pushing back on every l2tp patches lately,
but it'd really help if we could move the code forward and take
advantage of existing kernel infrastructures. Otherwise l2tp will keep
lagging behind.