netdev - HSR Addressing

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>] [day] [month] [year] [list]

Date:   Thu, 19 Aug 2021 15:18:04 +0200
From:   Tobias Waldekranz <tobias@...dekranz.com>
To:     m-karicheri2@...com, ap420073@...il.com, Arvid.Brodin@...n.com,
        xiyou.wangcong@...il.com, george.mccollister@...il.com,
        marco.wenzel@...berle.de
Cc:     netdev@...r.kernel.org
Subject: HSR Addressing

Hi netdev,

TL;DR: I am having a hard time squaring the kernel's implementation of
HSR with the spec (IEC 62439-3). Has anyone actually deployed this
successfully? Especially in rings containing RedBoxes.

The spec (5.6) says that:

    For the purpose of Duplicate Discard, a frame shall be identified
    by:

    - its source MAC address;
    - its sequence number.

And yet, the kernel seems to match HSR nodes using a {MAC_A, MAC_B}
tuple on ingress, and conversely sends each replicated HSR tagged frame
with the underlying port's MAC address as the SA (instead of the HSR
interface's ditto) on egress.

In a setup with only "DAN-H" nodes (~end-devices) the kernel can be made
to mostly behave, by manually configuring the MAC address of port A and
B to match that of the HSR interface.

But if you connect a "RedBox" (~HSR-to-80's-Ethernet-bridge) to the
ring, the kernel will associate a station behind that RedBox with a
tuple containing {station's real MAC, RedBox's MAC}, leading to
intermittent periods of (1) no traffic, (2) traffic, or (3) duplicated
traffic. This issue seems to stem from the kernel interpreting the
"RedBox TLV" in the supervision frame as the MAC used by the station to
send the replicated frames in the opposite direction.

It seems to me that...

- On egress, both HSR tagged replicas should be identical - with the
  exception of the PathId field.

- Supervision frames could use either the port MAC or the HSR
  interface's MAC in the Ethernet header, but the payload (TLV type 23)
  should always specify the HSR interface's MAC.

- Nodes should be identified by a single source address, no tuple
  matching. (But we should still record the RedBox MAC for debug
  purposes).

... OTOH, it seems highly unlikely that the implementation is this
broken and much more likely that I am mistaken. :)

Hoping someone can shed some light on this. Thanks!