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

[[e-mail]]

Hi Michael, 

Thanks for sharing your thoughts.

The slides you are referring to are not intended to articulate the overall problem space but to illustrate a use case where ** means to unambiguously and persistently identify devices within the home are required ** to protect the Internet but also to avoid collateral damage for subscribers hosting such compromised devices. Filtering at the network is suboptimal. The question then is: 

** how to reliably achieve this without mandating a given network setup and while minimizing subscriber involvement? **

Many ISPs offer apps to seek for an ACK from the subscribers whenever a new device connects to the home network. The identification is usually based on the MAC@. Notifications will be generated each time a new MAC@ is generated, which may be disturbing for the subscriber and may lead to deactivate the app or accept by default all devices. These considerations (and others) are not discussed in these slides because this is supposed to be handed in other use cases (device identification).

Cheers,
Med

> -----Message d'origine-----
> De : Madinas [mailto:[e-mail]] De la part de Michael
> Richardson
> Envoyé : lundi 2 novembre 2020 16:10
> À : [e-mail]
> Objet : Re: [Madinas] [dhcwg] [Int-area] BoF and Non-WG Mailing
> List: madinas -- MAC Address Device Identification for Network and
> Application Services
> 
> 
> 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

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.