Subject: [homenet] draft-ietf-homenet-front-end-naming-delegation-04

From: Douglas Otis <[email-masked]>
Date: Sun, 27 Sep 2015 20:59:28 -0700

Dear Homenet wg,

The draft-ietf-homenet-front-end-naming-delegation-04
sections lack needed guidance:

Section 7.3 Guidance and Recommendations

mDNS [RFC6762] DNS-SD [RFC6763] are two examples of these
services.  Currently mDNS is limited to a single link
network.  However, future protocols are expected to leverage
this constraint as pointed out in [RFC7558].

And

Section 11. Security Considerations

The Homenet Naming Architecture described in this document
solves exposing the CPE's DNS service as a DoS attack vector.

Issues:

DNS-SD [RFC6763] Section 9 Service Type Enumeration
facilitates browsing and lists potentially large RRsets at
"_services._dns-sd._udp.<Domain>" returning PTRs
representing services and associated domains.  DNS over UDP
is not robust against source spoofing where large responses
from small queries can place the Internet at risk,
especially when outsourced on substantial networks.

mDNS [RFC6762] resources presume distribution limited to the
local network where DNS-SD [RFC6763] offers few
deterministic strategies restoring such assumptions.
draft-otis-dnssd-scalable-dns-sd-threats-00 describing
service discovery browsing illustrates potential
vulnerabilities likely to persist for years. As of yet,
there are no links to this document in RFC7558.

The solution sought in
draft-ietf-homenet-front-end-naming-delegation-04 fails to
address critical network amplification issues not well
handled by UDP with any size network. Perhaps the strategy
used by draft-ietf-dnssd-push-00 (DNS Push Notifications)
leveraging RFC2136 (DNS UPDATE) can be tailored to also
offer Service Browsing over TCP rather than with UDP queries
against "<_services._dns-sd._udp.<Domain>" to ensure a
scheme that plays well with rBridge and WiFi configurations.

Regards,
Douglas Otis