On Apr 4, 2014, at 9:54 AM, joel jaeggli <[email protected]> wrote: > On 4/4/14, 9:45 AM, Don Sturek wrote: >> Hi Douglas, >> >> I fail to see how turning all devices in a home into a flat link >> local-addressed architecture meets the requirments in the homenet charter >> (http://datatracker.ietf.org/wg/homenet/charter/), particularly around >> home/guest networks plus a few other areas of the charter. >> >> I also fail to see how turning all devices in a dnssd-type deployment into a >> flat link local-addressed architecture meets the requirements in the dnssd >> charter (http://datatracker.ietf.org/wg/dnssd/charter/) particularly around >> enterprise networks (eg campus networks) or mesh networks. > > afaik dnssd wg/charter wouldn't need to exist if we were to constrain > the problem space to a single L2 domain. So i think we can stipulate > that the purpose is to work on a routed network.
Dear Joel, Thank you for you feedback. I am sure they represent what could be described as naive wishful desires. Careful review of the Educause petition indicates their specific desires are NOT satisfied with layer 3 solutions due to additional constraints not within the vendor's purview of which they seem unaware. The constraint limiting the scope of mDNS is due to typical bridge operation. This constraint is better resolved using an _incremental_ layer 2 solution offering TLV table based MAC exchanges to permit routing at this level rather than use of layer 3 IP routing which has the effect of disabling desired services. Within our organization at a similar scale, this issue has been resolved using enterprise grade switches and non-trival configuration. Use of Rbridge, as an example, eliminates complexity without weakening security where network boundaries become indeterminate. At the home scale, no service filters should be needed. At the Educause scale, filters for desired services will be needed. In good conscience, this additional requirement should be part of a DNSSD work product! Apple currently offers global DNS to locate devices based on Kerberos individual account authentications before publishing. There is no reason a similar strategy can't be used within the home network by bundling requisite services to explicitly authenticate devices made visible via DNS. This would also likely satisfy needs of networks unable to support mDNS. Placement of translated mDNS resources MUST NOT be published into DNS due to many security considerations never reasonably satisfied. mDNS should not be considered a safe method to publish internal resources when it impairs network boundary detection and potentially lists devices having default names indirectly accessible by remote actors. Please consider security implications for deployers as part of this thought process. Even if only published as a BCP, it would be most helpful. Regards, Douglas Otis _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
