Re: [mdnsext] Discussion of BoF during Berlin IETF

[David Farmer <[e-mail]>]

On 6/10/13 17:28 , Kerry Lynn wrote:
> On Mon, Jun 10, 2013 at 4:45 PM, David Farmer <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     On 6/5/13 08:42 , Michael Richardson wrote:
>
>         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.
>
>
>     While I wouldn't recommend general use of such a mode of operation I
>     do see some special situations where I think it could be necessary,
>     even on my own network, especially in networks or subnets with high
>     security requirements.
>
>     More fundamentally, I would prefer to see a graceful mechanism to
>     achieve this policy, rather than requiring traffic filtering or
>     another blunt force mechanism to achieve such a policy.  If someone
>     feels they need such a policy they will find a way.  I believe it is
>     far better for the protocol to give them a way to achieve their
>     policy goals then to force them to use other possibly more drastic
>     mechanisms to achieve their policy goal.
>
> The policy goal being "black hole all FF02::FB traffic"?

I would put it slightly differently, "not allowing multicast service 
discovery."  One option could be to "black hole all FF02::FB" and 
224.0.0.251 traffic.  However, a mechanism designed into the protocol 
could be more graceful, allowing an appropriate error message to be 
returned to an application or user.  Whereas, black holing all FF02::FB 
and 224.0.0.251 traffic wouldn't generally provide a useful error 
message, other than maybe a ICMP administratively not allowed. And, only 
if the filtering device is so kind as to actually return an ICMP 
message, which is kind of rare these days unfortunately.  Most things 
that filter just black hole things these days, because "that is more 
secure", BAH!!

Also, a mechanism designed into the protocol could allow more subtle 
policies like "allowing service discovery without allowing service 
registration" with something like the hybrid draft Stuart proposed, or 
"only allowing registration of certain type of services".

-- 
================================================
David Farmer               Email: [e-mail]
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: [phone]
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================