Hi Doug, We currently have a draft published: https://datatracker.ietf.org/doc/draft-bhandari-dnssd-mdns-gateway/
That addresses the service filtering component that you reference. On 4/4/14, 2:41 PM, "Douglas Otis" <[email protected]> wrote: > >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 > > > > > > > > >_______________________________________________ >dnssd mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/dnssd
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
