Re: [dnssd] I-D Action: draft-rafiee-dnssd-mdns-threatmodel-03.txt

["Hosnieh Rafiee" <[e-mail]>]

Hi Douglas,

Sorry, I guess I overlooked this message and just saw it now.. 
> 
> 
> On 6/1/15 12:18 AM, Hosnieh Rafiee wrote:
> > There's also a htmlized version available at:
> > > https://tools.ietf.org/html/draft-rafiee-dnssd-mdns-threatmodel-03
> Dear Hosnieh,
> 
> This review misses a concern called out in the CERT notice for dnssd at


> https://www.kb.cert.org/vuls/id/550620

Yes, right. 
I have another type of this attack in 
http://tools.ietf.org/html/draft-rafiee-dnssd-mdns-threatmodel-03#section-3.
4.1
I will add another subsection  under 3.5 which is about privacy issues with
the following text

Mixing unicast names and multicast names
A service might respond to unicast queries that originated from sources
outside of the local link network. Such responses may disclose information
and harm the privacy about users of that network

For the DoS part of that I already have a section here
http://tools.ietf.org/html/draft-rafiee-dnssd-mdns-threatmodel-03#section-3.
2

Does it work for you?

> See Section 1 of
> https://tools.ietf.org/html/draft-otis-dnssd-mdns-xlink-06
> 
> The threat model also overlooks data leakage beyond a local link and DNS
> amplification concerns resulting from the browse-ability offered by
resource
> structures as explained in the introduction and the CERT notice.

That is right that I do not have it as DNS amplification but only under the
title DoS attack

I am not sure it is necessary but I can add a subsection under DoS attack
with the following text

DNS amplification attack
Since a service might also response to unicast queries outside of its local
link, then an attacker might be able to learn the IP address of this service
and sends a lot of queries to a unicast DNS with the spoofed source IP
address of this service which result in DNS amplification attack on the
victim service and make this service unavailable to the service requesters,
that is, lead to a DoS attack.

Does it work for you?

> Appendix A gives an example of data leakage exploited in Appendix B.
> 
> A mitigation practice to overcome these risks remains unclear unless some
> means is made available to limit results.


Mitigation might be the Response Rate limit (RRL) as there was discussion in
other WG on the unicast DNS server as well as this service. Then after
receiving the same request from the same source IP, it just discards rest of
the messages.

Is there anything else that needs to be considered in the document. I am
going to add it to the offline of the document and if there is no more
comments, I can submit the new version.

Thanks,
Best,
Hosnieh

P.S. That is fine for me to receive two copy of a same message because I
might overlook messages that I am not in CC or To. thanks