Subject: [dnssd] ID Tracker State Update Notice: <draft-ietf-dnssd-requirements-04.txt>

From: IETF Secretariat <[email-masked]>
Date: Thu, 18 Dec 2014 10:47:10 -0800

Last call has been made for draft-ietf-dnssd-requirements and state has been changed to In Last Call
ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/

---

From: Douglas Otis <[email-masked]>
Date: Fri, 26 Dec 2014 12:45:10 -0800

> ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/

The dnssd-requirements overlooks significant concerns when publishing mDNS derived addresses.

ONE:
Section 5. Namespace Considerations
,---
SSD should support rich internationalized labels within Service
Instance Names, as DNS-SD/mDNS does today.  SSD must not negatively
impact the global DNS namespace or infrastructure.
'---

This added requirement to include U-Labels within DNS-SD introduces significant risks related to spoofing domains otherwise protected by restrictions normally imposed by registrars. 

This added namespace requirement would be made safer by including:
,+++
mDNS being published into DNS-SD should permit administrative control of potentially visually conflicting top level domains that would otherwise be in compliance with RFC5895 (IDNA2008) or additional restrictions imposed by the domain registrar. One such strategy might permit use of configured search domains. The published configuration information restricted to local network should have last hop packets ensured to have IPv6 header compliance with the use of RA Guard RFC7113. 
'+++

TWO:
Dnssd-requirements overlooked concerns related to IPv6 address selection.  Unlike IPv4, an interface adapter can be assigned multiple addresses having different scopes. The selection process of these scopes will have a significant impact on local networks given their greater exposure when mDNS information is used to populate DNS-SD information.  

THREE:
This requirements document assumes use of Enterprise environments but ignores distribution of reassigned segment prefixes or those that occur when there are multiple uplinks as may occur when a wired and cellular provider are both being used.

Section 6. Security Considerations
,---
Insofar as SSD may automatically gather DNS-SD resource records and
publish them over a wide area, the security issues are likely to
include the union of those discussed in the Multicast DNS [mDNS] and
DNS-Based Service Discovery [DNS-SD] specifications.  The following
sections highlight potential threats that are posed by deploying DNS-
SD over multiple links or by automating DNS-SD administration.
'---
...
,---
If the scope of the discovery is not properly set up or constrained,
then information leaks will happen outside the appropriate network.
'---

This statement is rather opaque and unlikely to result in providing meaningful guidance.  It makes no mention of different types of addressing often used to limit the scope of an address, especially what is typically offered with IPv6. Instead, this document incorrectly assumes such security concerns related to the automated publishing of mDNS information into DNS-SD have been covered within mDNS or DNS-SD.  They have not!  DNS-SD even states it creates no additional security concerns since this assumes such concerns are management decisions about what to publish. Few CPE devices conforming with RFC7084 permit address specific exceptions for externally initiated sessions.  With such limitation, acceptance of external sessions becomes either a default accept or deny setting. 

The scope of discovery statement should be clarified with:
,+++
DNS-SD did not consider the impact of RFC4193 which must be carefully considered when using mDNS to populate DNS-SD.  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 are not resolve on the Internet as described in RFC6950.

To maintain security, address preference rules employed by publishing within DNS-SD 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.
'+++

Regards,
Douglas Otis