On 4/4/14, 11:41 AM, Douglas Otis 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.
Afaik we're operating under a wg charter not the educause petition and I see no reason the discussion should be lititgated on basis of the later. > 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. That would seem to arbirarily constrain the diameter to an l2 domain. Sure you can build your topology that way, many if not most organizations do not. They have good reasons for doing so. > 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 > > > > > > > > >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
