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

From: Carsten Bormann <[email-masked]>
Date: Mon, 2 Nov 2020 08:20:51 +0100

On 2020-11-01, at 22:56, Juan Carlos Zuniga <[email-masked]> 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).

(Please reply to [email-masked].)

Grüße, Carsten

---

From: <[email-masked]>
Date: Mon, 2 Nov 2020 08:10:46 +0000

Hi Carsten,

The DDoS attack in the slides is ** from ** a compromised device in a home network. 

Instead of deploying filters at the ISP side, which may impact the overall services offered to the home (collateral damage), the filtering is done at the CPE: the CPE should identify and then isolate the compromise device. 

The identification can be based on the MAC @, but as mentioned in the slides changing the MAC@ can bypass the filtering. Randomization will further exacerbate this. 

Cheers,
Med

> -----Message d'origine-----
> De : Int-area [mailto:[email-masked]] De la part de
> Carsten Bormann
> Envoyé : lundi 2 novembre 2020 08:21
> À : [email-masked]
> Cc : [email-masked]; [email-masked]
> Objet : Re: [Int-area] BoF and Non-WG Mailing List: madinas -- MAC
> Address Device Identification for Network and Application Services
> 
> 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).
> 
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

_________________________________________________________________________________________________________________________

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.

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 2 Nov 2020 09:33:08 +0100

Hi Med,

> On 2020-11-02, at 09:10, <[email-masked]> <[email-masked]> wrote:
> 
> Hi Carsten,
> 
> The identification can be based on the MAC @, but as mentioned in the slides changing the MAC@ can bypass the filtering.

I think I understand all that.

> Randomization will further exacerbate this. 

This is the part where I’m not sure that the impact is significant.
Once these countermeasures are widely deployed, attackers will do counter-countermeasures.  It is easy to change a MAC address on a compromised device.  Also, I don’t think MAC address randomization is effective enough to thwart the countermeasure (too slow time frames), so attackers will have every incentive to do their own MAC address changing.

Instead, I think we need to work on effectively jailing IoT devices in the home without trying to cop out by using the MAC address as a selector.

Grüße, Carsten

---

From: <[email-masked]>
Date: Mon, 2 Nov 2020 08:46:56 +0000

Re-,

Please see inline. 

Cheers,
Med

> De : Carsten Bormann [mailto:[email-masked]]
> Envoyé : lundi 2 novembre 2020 09:33
> À : BOUCADAIR Mohamed TGI/OLN <[email-masked]>
> Cc : [email-masked]
> Objet : Re: [Madinas] [Int-area] BoF and Non-WG Mailing List:
> madinas -- MAC Address Device Identification for Network and
> Application Services
> 
> Hi Med,
> 
> > Instead of deploying filters at the ISP side, which may impact the
> overall services offered to the home (collateral damage), the
> filtering is done at the CPE: the CPE should identify and then
> isolate the compromise device.
> >
> > The identification can be based on the MAC @, but as mentioned in
> the slides changing the MAC@ can bypass the filtering.
> 

[Med] This will depend on how frequent the change will occur (or will be told to occur).   

> Once these countermeasures are widely deployed, attackers will do
> counter-countermeasures.  It is easy to change a MAC address on a
> compromised device.  Also, I don’t think MAC address randomization
> is effective enough to thwart the countermeasure (too slow time
> frames), so attackers will have every incentive to do their own MAC
> address changing.

[Med] Agree. This is the message in the last slide.  

> 
> Instead, I think we need to work on effectively jailing IoT devices
> in the home without trying to cop out by using the MAC address as a
> selector.

[Med] That’s a good target. Interim targets may be, for example, to locally coordinate MAC changes if a device want to continue be granted connectivity access.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 02 Nov 2020 10:09:52 -0500

> https://github.com/boucadair/IETF109BoF/blob/master/madinas-ddos%20mitigation-use%20case-rev%2027102020.pdf

    > 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 <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: <[email-masked]>
Date: Tue, 3 Nov 2020 13:21:43 +0000

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

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

---

From: Michael Richardson <[email-masked]>
Date: Tue, 03 Nov 2020 12:55:03 -0500

<[email-masked]> wrote:
    > 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:

Reading the slides, I understood:
        "Doctor it hurts when I put my foot in the blender"

me: "don't put your foot in the blender"

    > ** 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).

Yes, it's is good that you agree with me that the real problem is not
tracking malicious devices that change evade ACL by changing address, but
rather positively identifying legitimate devices so that their MAC address
changes can be transparently tracked.

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

    mcr> It is easy in current software and protocols to provide a per-device
    mcr> WPA-PSK (for WiFI), and this efficiently binds the device identity
    mcr> to their MAC address.

    mcr> This is unfortunately, not yet a BCP (or as our group at the RIPE81
    mcr> IoT attempted, a BCoP), because we lack the right standardized
    mcr> interfaces to be able build a UI to assign a new WPA-PSK per device.
    mcr> To do this automatically/autonomically, we need BRSKI or DPP or ???,
    mcr> but it could be done via a management "App" connected to the home
    mcr> router.
    mcr> Many ISPs that provide routers provide a management App as well.

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

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

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: <[email-masked]>
Date: Wed, 4 Nov 2020 08:07:44 +0000

Hi Michael,

Please see inline. 

Cheers,
Med

> De : Michael Richardson [mailto:[email-masked]]
> Envoyé : mardi 3 novembre 2020 18:55
> À : BOUCADAIR Mohamed TGI/OLN <[email-masked]>;
> [email-masked]
> Objet : identities for legitimate devices
> 
> 

[Med] I'm sure there is a disconnect here. Having filtering in place does not guarantee that your internal devices won't be compromised. The slides are about when such events happens, it is better for the entity managing the local network to do the right thing. 

But for that to happen and to be efficient, your local device identification should be accurate. 

> Yes, it's is good that you agree with me that the real problem is
> not tracking malicious devices that change evade ACL by changing
> address, but rather positively identifying legitimate devices so
> that their MAC address changes can be transparently tracked.

[Med] Glad to see that we agree on this part...but 

>     mcr> legitimate devices and accept their traffic.  All other

[Med] ... This is not a guard that your "legitimate" devices will be exploited and used to relay attacks.