Unicast queries/response for mDNS names may be supported to mitigate connectivity impact

[tQsW]

The link-local scope of multicast transactions is one of the primary causes that fail the name resolution, and seems to contribute to the overall connectivity impact of the mDNS technique from the field trial (see this report, https://crbug.com/1005097) . Unicast queries may be supported in the use of mDNS candidates to extend the scope of name queries. Per RFC 6762, Section 5.5 "Direct Unicast Queries to Port 5353",

There may be specialized situations, outside the scope of this document, where it is intended and desirable to create a responder that does answer queries originating outside the local link. Such a responder would need to ensure that these non-local queries are always answered via unicast back to the querier, since an answer sent via link-local multicast would not reach a querier outside the local link.

The corresponding response should be unicast from the principle and also per the above spec.

Ideally, these unique queries would be sent to non-host candidates signaled or learned from the remote peer. The caveat is these candidate will not have the 5353 port but an ephemeral UDP port. It is possible to support the parse of mDNS message by general non-host candidate.

Note that PR #111 currently also proposes the use of unicast responses to reduce the irrelevant traffic for endpoints in the same network.

[nswarnkar]

Thanks for logging this bug..Just pasting the link if people are interested in history : https://bugs.chromium.org/p/chromium/issues/detail?id=1005097#c7

[juberti]

@tQsW, this is a super interesting suggestion. We wouldn't even need to use mDNS, we could simply allow 'signaling' of the host candidate over the srflx/relay connection.

Definitely some security stuff that we'll need to figure out but this definitely seems like something we should pursue.

[nswarnkar]

My suggestion would be, if it is something related to security, we should not use mDNS name across subnets. On same subnet, we can live as it is today.

[juberti]

We don't know if the name is going to cross subnets or not a priori.

[juberti]

I think that allowing tunnelling of generic mDNS queries is probably going to be problematic, you don't want a remote peer to be able to discover local printers, although resolution of the known locally generated names should be fine.

There is also the issue of the app provider jamming a query into TURN traffic to resolve the names, so we can't do this over TURN, even if the query is encrypted by ICE credentials. I considered DTLS, but it's a layer violation and could also be MITMed. So you could only do it if the query went over STUN, but given the design of TURN I don't know if it's possible to properly enforce this (consider an attacker who sends a relay candidate as a srflx candidate).

If we can solve this last part there may be hope, but otherwise not looking good.

[juberti]

The basic problem is this, you can only trust receiving an mDNS query from a source known not to be under application control (including application STUN server or TURN server).

Besides the completely OOB case (e.g. regular mDNS), not clear that this is possible in general. Could perhaps be possible in enterprise environments via some sort of PSK deployed via admin settings.

[tQsW]

The basic problem is this, you can only trust receiving an mDNS query from a source known not to be under application control (including application STUN server or TURN server).

Good point and this is key to the feasibility. I don't have a good answer so far to solve this. The remote peer can simply be controlled by the application, and we won't have the notion of a trusted remote ICE agent implementation. This even rules out the effectiveness of a separate e2ee built into the ICE agent just for this exchange, unless via some managed PSK like you pointed out for p2p use cases.

[juberti]

Right, I think there is no shared secret that we can bootstrap E2EE from. It might be possible to use something from DHCP here though - if all machines in a domain were pushed a secret, you could use that to wrap the address.

[tQsW]

Besides the completely OOB case (e.g. regular mDNS), not clear that this is possible in general. Could perhaps be possible in enterprise environments via some sort of PSK deployed via admin settings.

An approach with this thought is described in https://tools.ietf.org/html/draft-wang-mmusic-encrypted-ice-candidates. See also the working repo https://github.com/tQsW/encrypted-ice-candidates

[youennf]

Labelling as extension. I do not think we anticipate changes to the mDNS doc for now.

[juberti]

I concur.