Re: [mdnsext] Discussion of BoF during Berlin IETF

On Mon, Jun 10, 2013 at 8:11 PM, Michael Richardson
<mcr+ietf@sandelman.ca>wrote:

>
> >>>>> "David" == David Farmer <farmer@umn.edu> writes:
>     >> But, that doesn't prevent or clearly signal, that mDNS may be
>     >> *unwelcome* on a particular network.   Enterprise folks might want
> to do
>     >> that. I'm not claiming that they will, or should, succeed, btw.  I'm
>     >> pointing out that we don't know what they want, because they don't
> tend
>     >> to participate.
>
>     David> While I wouldn't recommend general use of such a mode of
>     David> operation I do see
>     David> some special situations where I think it could be necessary,
>     David> even on my own
>     David> network, especially in networks or subnets with high security
>     David> requirements.
>
> Exactly (we are in violent agreement).
> Or where having nodes "find" each other automatically is undesireable.
>
> The train has left the station.  There are probably millions of deployed
devices
that already exhibit DNS-SD/mDNS behavior.  How is Enterprise IT to thwart
this existing behavior (e.g. probe and announce) except by black-holing mDNS
traffic *at L2*?  I guess you could hobble the OS somehow, but you're not
going to selectively disable firmware in a printer.

> Do you feel you can represent the Enterprise administrator?
> Do we need to reach out some other place?
>
> I'd put disabling existing functionality pretty far down the list of
priorities, since
the main problem seems to be how to make it work over a wider area, in more
cases.  I think the list of use cases previously mentioned run the spectrum
from
no management/no external servers to (potentially) fully managed DNS.  There
is also a spectrum of security concerns, and I will crank up a new thread
on that
topic tomorrow unless someone beats me to it.

-K-

There may also be situations where multicast is harmful (heavily
> congested wifi, LLNs which do not implement whatever LLN friendly mDNS
> we make).
>
> Blackholing multicast traffic may result in timeouts.
>
> --
> ]               Never tell me the odds!                 | ipv6 mesh
> networks [
> ]   Michael Richardson, Sandelman Software Works        | network
> architect  [
> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails
>    [
>
>
>
>
> _______________________________________________
> mdnsext mailing list
> mdnsext@ietf.org
> https://www.ietf.org/mailman/listinfo/mdnsext
>
>