Subject: [Mud] How does MUD deal with broadcast IP addresses

From: "M. Ranganathan" <[email-masked]>
Date: Thu, 20 Jun 2019 10:21:07 -0400

Various protocols (e.g. mdns) could use LAN broadcast addresses. How do we
deal with these in a MUD file?
e.g. MDNS uses 224.0.0.251. Should this be a controller class?

Thanks,

Ranga

-- 
M. Ranganathan

---

From: "M. Ranganathan" <[email-masked]>
Date: Thu, 20 Jun 2019 10:22:54 -0400

Correction - I meant multicast (not LAN broadcast). Thanks.

-- 
M. Ranganathan

---

From: Eliot Lear <[email-masked]>
Date: Thu, 20 Jun 2019 18:09:17 +0200

I like the idea of using a class for MDNS.  I also think broadcast and multicast are a bit of a special case, relying on the underlying ACL model.  What do other people think?

> On 20 Jun 2019, at 16:21, M. Ranganathan <[email-masked]> wrote:
> 
> Various protocols (e.g. mdns) could use LAN broadcast addresses. How do we deal with these in a MUD file?
> Mud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mud

---

From: Michael Richardson <[email-masked]>
Date: Thu, 20 Jun 2019 15:28:37 -0400

Eliot Lear <[email-masked]> wrote:
    > I like the idea of using a class for MDNS.  I also think broadcast and
    > multicast are a bit of a special case, relying on the underlying ACL
    > model.  What do other people think?

So a MUD file for a device that should be allowed to use mDNS
would create an ACL to 224.0.0.251?

I think that internal ACLs will be very inconsistently applied by
mud-controllers.  While some will be able to hairpin all the traffic,
other environments will make this hard, or will be too costly if there
is a lot of traffic.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Eliot Lear <[email-masked]>
Date: Thu, 20 Jun 2019 23:36:04 +0200

It depends on to-device/from-device.  If the device is including a from-device and it uses multicast it should probably list it, lest an inbound ACL simply block the traffic.  For to-device, it’s unnecessary because there are no source multicast addresses.  Another way to address this in implementations is to simply permit outbound multicast in all cases.

> On 20 Jun 2019, at 21:28, Michael Richardson <[email-masked]> wrote:
> 
> Signed PGP part
>

---

From: "M. Ranganathan" <[email-masked]>
Date: Thu, 20 Jun 2019 18:05:07 -0400

On Thu, Jun 20, 2019 at 5:36 PM Eliot Lear <[email-masked]> wrote:

> It depends on to-device/from-device.  If the device is including a
> from-device and it uses multicast it should probably list it, lest an
> inbound ACL simply block the traffic.  For to-device, it’s unnecessary
> because there are no source multicast addresses.  Another way to address
> this in implementations is to simply permit outbound multicast in all cases.
>

Could permitting outbound multicast for all addresses be listed as
"standard mud  behavior"  ( in the same way as dns, ntp and dhcp are
permitted by default).

-- 
M. Ranganathan

---

From: Michael Richardson <[email-masked]>
Date: Thu, 20 Jun 2019 20:43:57 -0400

Eliot Lear <[email-masked]> wrote:
    > because there are no source multicast addresses.  Another way to
    > address this in implementations is to simply permit outbound multicast
    > in all cases.

Wouldn't to-device be about whether or not the device should receive
multicast traffic?  Yes, rather hard to block in many networks, but a
description should still say that the device will be listening.

And if one says allow it with devices from the same manufacturer, that would
seem to be interesting.

    >>> I like the idea of using a class for MDNS.  I also think broadcast
    >>> and multicast are a bit of a special case, relying on the underlying
    >>> ACL model.  What do other people think?
    >>
    >> So a MUD file for a device that should be allowed to use mDNS would
    >> create an ACL to 224.0.0.251?
    >>

---

From: Eliot Lear <[email-masked]>
Date: Fri, 21 Jun 2019 09:00:58 +0200

> On 21 Jun 2019, at 02:43, Michael Richardson <[email-masked]> wrote:
> 
> Signed PGP part
> 

The IP address you look at for to-device is the source IP, not destination.

> And if one says allow it with devices from the same manufacturer, that would

Yes.  That’s what we’ve been doing in some cases.

Eliot

---

From: Michael Richardson <[email-masked]>
Date: Fri, 21 Jun 2019 16:58:08 -0400

Eliot Lear <[email-masked]> wrote:
    >>> inbound ACL simply block the traffic.  For to-device, it’s
    >>> unnecessary because there are no source multicast addresses.  Another
    >>> way to address this in implementations is to simply permit outbound
    >>> multicast in all cases.
    >>

    > The IP address you look at for to-device is the source IP, not

It took a few iterations in my brain to agree with you.
It sounds, then, like it is impossible to authorize a device to receive
multicast traffic.  So either it's implicitly allowed or denied.

It seems like we need an addendum to have a from-device list that authorizes
traffic to 224.* / ff00::/8, also imply that the device can receive such
traffic?  How would unicast replies work?

(probably I should go read the RFC again to learn if there is a specific
section on this that I missed)