netdev - Re: [PATCH net-next v3 0/5] net: dsa: remove .set

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: <20171016160941.GA13339@lunn.ch>
Date:   Mon, 16 Oct 2017 18:09:41 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Rodney Cummings <rodney.cummings@...com>
Cc:     Vivien Didelot <vivien.didelot@...oirfairelinux.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "kernel@...oirfairelinux.com" <kernel@...oirfairelinux.com>,
        "David S. Miller" <davem@...emloft.net>,
        Florian Fainelli <f.fainelli@...il.com>,
        David Laight <David.Laight@...LAB.COM>
Subject: Re: [PATCH net-next v3 0/5] net: dsa: remove .set_addr

On Mon, Oct 16, 2017 at 03:23:42PM +0000, Rodney Cummings wrote:
> I am concerned about this proposed change.
> 
> According to IEEE Std 802.1Q, a "higher layer entity" (i.e. end
> station) that is internal to the bridge (i.e. switch) can use the
> same individual global MAC address that the switch is using. That
> behavior is common.
>
> Use of a local semi-random MAC address is dangerous on
> Ethernet. Local MAC addresses can only be safely used in very narrow
> use cases, most of which are Wi-Fi. Generally speaking, local MAC
> addresses can be duplicated in the network, which causes many
> Ethernet protocols to break down. Therefore, general-purpose
> implementations like DSA cannot use a local MAC address in a
> reliable manner.

Hi Rodney

This is interesting. So i did some research. The Marvell Switch only
uses this MAC address for Pause frames. Nothing else.

802.3-2015 Section 2, Annex 31B says:

  The globally assigned 48-bit multicast address 01-80-C2-00-00-01 has
  been reserved for use in MAC Control PAUSE frames for inhibiting
  transmission of data frames from a DTE in a full duplex mode IEEE
  802.3 LAN. IEEE 802.1D-conformant bridges will not forward frames
  sent to this multicast destination address, regardless of the state
  of the bridgeâs ports, or whether or not the bridge
  implements the MAC Control sublayer. To allow generic full duplex
  flow control, stations implementing the PAUSE operation shall
  instruct the MAC (e.g., through layer management) to enable
  reception of frames with destination address equal to this multicast
  address.

  NOTEâBy definition, an IEEE 802.3 LAN operating in full
  duplex mode comprises exactly two stations, thus there is no
  ambiguity regarding the destination DTEâs identity. The use
  of a well-known multicast address relieves the MAC Control sublayer
  and its client from having to know, and maintain knowledge of, the
  individual 48-bit address of the other DTE in a full duplex
  environment.

  When MAC Control PFC operation (see Annex 31D and IEEE Std 802.1Q)
  has been enabled, MAC Control PAUSE operation shall be disabled.

So, received Pause frames never leave the MAC. They don't get bridged,
nor do they get passed up for host processing. They are purely point
to point between two MAC peers. The destination is unambiguous. It is
simple the other MAC peer. The destination address makes it clear it
is a pause frame, the the source address seems to be unneeded.

In this context, a random MAC addresses are safe.

In the more general case, i would agree with you. Collisions are
possible, causing problems.

   Andrew