Restrict clients by MAC address

[fsalomon]

I'm wondering if it would be possible to amend this software to facilitate MAC address restrictions on clients as well. Such a config file could look like this:

net_interface = "wls1" # Put here the network interface you want to use.

[devices]

    [devices."AA:BB:CC:DD:EE:FF"]    # A shared bonjour device
    description = "Test Chromecast"
    origin_pool = 1078               # Tag of the VLAN the device is in
    shared_pools = [1234, 3597]      # Tags of the VLANs which can use this device
    shared_devices = ["AA:BB:CC:DD:EE:FA","AA:BB:CC:DD:EE:FB"]   # Mac addresses of devices that can use this device

So in this example, device AA:BB:CC:DD:EE:FB (VLAN 1234) would be able to access AA:BB:CC:DD:EE:FF, but AA:BB:CC:DD:EE:FC (VLAN 1234) would not.

I'm not fluent in Go, so I'm asking if this seems feasible before I dive into it.

[Gandem]

Per the RFC, mDNS requests and reponses are done in broadcast (FF:FF:FF:FF:FF:FF) meaning that all the devices in a same VLAN will receive a Bonjour request/response.

So regarding your question, it would be possible to filter the mDNS request by client :

If we have Device 1 (D1) and Device 2 (D2), we would only forward D1's requests to the VLAN where the Bonjour device is (dropping D2's requests).

However, there is a gotcha:

The response will be sent to both D1 and D2 (broadcast on vlan 1234). So if D2 was listening for bonjour/mDNS packet, it will receive the answer from the Bonjour device.

[fsalomon]

Thanks, I was suspecting something like that. So D2 would probably be able to discover the "forbidden" device in some scenarios, right?

I'm not familiar with the protocol but I'm guessing that if D2 wanted to cast to the "forbidden" device, the payload would contain the MAC address of the targeted device and at that point the message can be dropped by the reflector, right?

[Gandem]

Yes, D2 would be able to discover the "forbidden" device, in some scenarios.

For casting, this is done with another protocol (mDNS/Bonjour only does the "discovery" part): when D2 discovers the "forbidden" device, it will contact it directly by its IP, thus the traffic would not go through the reflector.

[fsalomon]

Hmm, so I'd need some firewall rules for this as well.

I'm looking at this product
https://www.sonifi.com/staycast/index.php
https://www.hotelbusiness.com/sonfi-unveils-website-pairing-for-staycast/

So this made me optimistic that it's possible to have two VLANS (one of the chromecasts, one for the client devices) and some arbitrary many-to-many relationship between those devices.

Any idea how they get around the discovery issue?

[Gandem]

It would be possible by sending the response to D1 in unicast (by using a many-to-many mapping). However, this would go against the RFC as the answer must be in broadcast unless specified by the client.

Quoting https://tools.ietf.org/html/rfc6762#page-12 :

if the responder has not multicast that record recently
(within one quarter of its TTL), then the responder SHOULD
instead multicast the response so as to keep all the peer
caches up to date, and to permit passive conflict detection.

[fsalomon]

I see. What about emulating a Chromecast entirely? In that case, all clients would see the same (emulated) Chromecast that pretends to be always idle. Once a cast is initiated, the request will be relayed to the appropriate real-world device.

This would of course reduce the assignment to many-to-one, because each client device is assigned to 0 or 1 Chromecasts.

[Gandem]

AFAICT, the most straightforward option would be to make the reflector send unicast responses instead of multicast/broadcast. You can do this by :

• forking the repo to add the functionality or,
• adding it in here to bonjour-reflector behind a well-documented flag

[fsalomon]

Seems worth a try even if it breaks the spec a little bit. However, I wont have the time to create the necessary test setup till April next year.