Re: [Madinas] [dhcwg] [Int-area] BoF and Non-WG Mailing List: madinas -- MAC Address Device Identification for Network and Application Services

[Michael Richardson <[e-mail]>]

Carsten Bormann <[e-mail]> wrote:
    > On 2020-11-01, at 22:56, Juan Carlos Zuniga <[e-mail]> wrote:
    >>
    >> https://github.com/jlivingood/IETF109BoF/blob/master/109-Agenda.md

    > I don’t understand the slides about home device MAC addresses,
    > https://github.com/boucadair/IETF109BoF/blob/master/madinas-ddos%20mitigation-use%20case-rev%2027102020.pdf

    > If mitigations are widely deployed that are based on MAC address
    > filtering, attackers will implement countermeasures (such as varying
    > the MAC address quickly enough to defeat the mitigation signaling).
    > MAC address randomization as implemented by a device vendor would
    > probably be too slow as a countermeasure (if it were, it would save the
    > attacker a little work, but not that much).

Carsten's point is legitimate, and I think that the slides mostly fail to
articulate the problem well enough.
It seems that there are assumptions made about how DOTS might be implemented
by CPEs.

Attacking devices by *construction* have unknown MAC addresses.
You can't filter for that.

The solution is that one has to construct filters to recognize legitimate
devices and accept their traffic.  All other traffic gets blocked.

It is easy in current software and protocols to provide a per-device WPA-PSK
(for WiFI), and this efficiently binds the device identity to their MAC
address.
This is unfortunately, not yet a BCP (or as our group at the RIPE81 IoT
attempted, a BCoP), because we lack the right standardized interfaces to be
able build a UI to assign a new WPA-PSK per device.
To do this automatically/autonomically, we need BRSKI or DPP or ???, but
it could be done via a management "App" connected to the home router.
Many ISPs that provide routers provide a management App as well.

Todays interfaces can accept-list devices by MAC address.
The risk is that these lists go stale if *legitimate* devices change their
MAC address.

The biggest risk, in my opinion, is not that malware will learn to randomize
their MAC address.  It is that malware will learn to login to the CPE
using the "cheestos"[1] authentication of admin/admin, and then just
accept-list their chosen MAC address.

I wrote draft-richardson-homerouter-provisioning last night, because I needed
to reference it, and I hadn't finished describing the mechanism in another
draft where I had intended originally to.
This deals with the lack of privacy on the CPE management API.
While BBF TR369 (USP) seems to have real potential: I am dismayed by the lack
of a security mechanism, and the document seems to endorse every protocol.

[1] https://www.sandelman.ca/mcr/humour/username-admin-password-admin-admin-password-63615994.png

--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide