Re: [dnssd] Threat model - answer to questions

[Douglas Otis <[e-mail]>]

On Dec 5, 2014, at 2:51 AM, Hosnieh Rafiee <[e-mail]> wrote:

> Hi Douglas,
> 
> Thanks for your comments. 
> 
>> For resource constrained devices, security is best enforced by use of
> <snip>
>> Omitting proper address selection rules is unlikely to obtain the
>> desired security.  This consideration was omitted in both the Hybrid
>> Proxy and Security Threat documents.
>> 
>> Note: Last hop security depends on header compliance with RA Guard
>> RFC7113.
> Thanks for the clarification. I actually removed it from the document because In IETF 90 when I was presenting, some folks told me that I should only focus on the scope of requirement documents and charter which is more related to DNSSD and a little about mDNS.
> 
> So, maybe this is a good time to raise this question:
> 
> What is the expectation of thread model? Shall I also evaluation the current available documents which discusses also about mDNS or only focus on SD part?

Dear Hosnieh,

The general goal for using mDNS to populate DNS is to approach zero-config when networks are isolated on different bridges unable to automatically propagate multicast traffic without use of protocols like PIM-SM (RFC3569).  The effects of these methods and their best implementation should be part of related threat analysis although draft-ietf-dnssd-requirements excluded important concerns.  In essence, these concerns should include the proper handling of RFC4193 (ULAs).  

A statement like:
,--
DNS-SD did not consider the impact of RFC4193 that should be carefully considered when using mDNS to populate DNS.  As such, a ULA prefix is not to be advertised outside the network domain. Administrators need to clearly set the scope of the ULAs and configure ACLs on relevant border routers to enforce this scope.  If internal DNS is used, administrators should use internal-only DNS names for ULAs and perhaps use split horizon DNS to ensure internal names do not resolve on the Internet as described in RFC6950.

To maintain security, address preference rules employed by a proxy device should properly consider use of ULAs as described by RFC7368.  Per section 2.4, a device should only use its ULA address within its domain. Even where multiple /48 ULA prefixes are in use within a single domain, as may occur when there are multiple Internet uplinks, utilizing a ULA source address and a ULA destination address from two disjoint internal ULA prefixes should still be preferred over GUAs.  When a device has not been specifically enabled to be externally accessible, mDNS proxy into DNS should not publish associated GUAs.  
'--

The section: 3.2.1.  Home, Enterprise, Mesh networks:
,--
When ISP, home router/gateway and service provider (like a printer) 
support IPv6 address, then service providers usually automatically 
sets an IPv6 address. Since this address is global, this node is 
accessible over the internet. If the address of this service provider 
is known to the attacker, then it might be able to compromise this 
service provider and access to this network (because service 
providers usually supports weak security features).
'--

Should be:
,--
When the ISP, home router/gateway, and a service (like a printer) 
support IPv6 addressing, these services may automatically announce over 
mDNS both ULA and GUA addresses.  Since a GUA address is global, 
the associated node may become accessible over the Internet. 

When the GUA address for a service becomes known to an attacker, it 
might grant unintended access to a service otherwise limited by 
boundaries imposed by mDNS discovery.
'--

This paragraph offers no protective strategy for devices within a networking domain supported by DNS-SD populated by the mDNS proxy scheme.  To be better understood, this paragraph should replace the term "service provider" with "service".  Unlike IPv4, there can be multiple IP address assignments per interface.   For example, a printer might return both GUA and ULA addresses.  From a security standpoint, it becomes essential only ULAs be published in DNS-SD populated by mDNS. 

CGA-TSIG or DNS over TLS are incongruent with the use of DNS-SD populated by mDNS since zero-config is being sought.  Omitting proper address selection rules will not ensure basic deployments offer the desired security.  This consideration was omitted in both the Hybrid Proxy and the requirements documents.  Threat related documents should also include header compliance requirements as specified by RA Guard RFC7113 also omitted by this draft.

Regards,
Douglas Otis