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 _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
