netdev - RE: [PATCH net-next 9/9] ipvlan: introduce individual MAC addresses

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]

Message-ID: <695CDAEB5A6CE2498DE413F2A9AA82960915EF08@IRSMSX101.ger.corp.intel.com>
Date:   Thu, 4 May 2017 09:37:00 +0000
From:   "Chiappero, Marco" <marco.chiappero@...el.com>
To:     Dan Williams <dcbw@...hat.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
CC:     "David S . Miller" <davem@...emloft.net>,
        "Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
        "Duyck, Alexander H" <alexander.h.duyck@...el.com>,
        "Grandhi, Sainath" <sainath.grandhi@...el.com>,
        Mahesh Bandewar <maheshb@...gle.com>
Subject: RE: [PATCH net-next 9/9] ipvlan: introduce individual MAC addresses

> -----Original Message-----
> From: netdev-owner@...r.kernel.org [mailto:netdev-owner@...r.kernel.org]
> On Behalf Of Dan Williams
> Sent: Tuesday, May 2, 2017 5:09 PM
> To: Chiappero, Marco <marco.chiappero@...el.com>; netdev@...r.kernel.org
> Cc: David S . Miller <davem@...emloft.net>; Kirsher, Jeffrey T
> <jeffrey.t.kirsher@...el.com>; Duyck, Alexander H
> <alexander.h.duyck@...el.com>; Grandhi, Sainath
> <sainath.grandhi@...el.com>; Mahesh Bandewar <maheshb@...gle.com>
> Subject: Re: [PATCH net-next 9/9] ipvlan: introduce individual MAC addresses
> 
> On Tue, 2017-05-02 at 15:08 +0000, Chiappero, Marco wrote:
> > > -----Original Message-----
> > > From: Dan Williams [mailto:dcbw@...hat.com] On Thu, 2017-04-27 at
> > > 11:20 -0500, Dan Williams wrote:
> > > > On Thu, 2017-04-27 at 15:51 +0100, Marco Chiappero wrote:
> > > > > Currently all the slave devices belonging to the same port
> > > > > inherit their MAC address from its master device. This patch
> > > > > removes this limitation and allows every slave device to obtain
> > > > > a unique MAC address, by default randomly generated at creation
> > > > > time.
> > > > >
> > > > > Moreover it is now possible to correctly modify the MAC address
> > > > > at any time, fixing an existing bug as MAC address changes on
> > > > > the master were not reflected on the slaves. It also avoids
> > > > > multiple interfaces sharing the same IPv6 link-local address.
> > > >
> > > > How is this different than macvlan now?
> >
> > The same way it was before. The purpose of the patch is to make
> > possible to change the MAC address on slaves, not to change the
> > external behavior of ipvlan: ipvlan will still behave as ipvlan,
> > macvlan will still behave as macvlan.
> 
> Ok, it was completely unclear from the commit message that the "internal" MAC
> addresses of the ipvlan interfaces were not reflected "on the wire", but that this
> was essentially (as you say below) MAC NAT.

Sorry about that, I'll fix it in V2.

> I think everyone agrees that being able to change the MAC is useful and was a
> bug.
> 
> What I'm still not clear on is, if IPv6 is already solved, why is it useful to have
> assign ipvlan interface a unique MAC address?  Is it only to make interface
> lookups via MAC easier?

The main motivation is that some higher level management software expect interfaces on the same L2 broadcast domain to obviously have different MAC addresses, either out-of-the-box or via address change - or both.  Instead with ipvlan:
- there is no real/formal segmentation between slaves
- slaves share the same L2 address
This looks conceptually wrong. Yes, ipvlan works at L3 (which is an implementation detail anyway), but slaves are Ethernet interfaces and should behave as much as possible as such regardless, with an individual MAC address assigned.

Additionally there is another related bug as it's currently possible to work around this limitation, although breaking the whole thing, by:
1) changing the MAC address on master from X to Y
2) creating a slave, receiving address Y
3) restoring the original MAC address X on master

So, either we fix this by forcing slaves to stay in sync with master, or correctly support independent MAC addresses, which would be IMO preferable for the above reasons.

Best Regards,
Marco
--------------------------------------------------------------
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.