On Apr 6, 2014, at 9:32 PM, Dave Taht <[email protected]> wrote: > On Fri, Apr 4, 2014 at 8:08 AM, Douglas Otis <[email protected]> wrote: >> >> On Apr 4, 2014, at 6:10 AM, Don Sturek <[email protected]> wrote: >> >> Hi Douglas, >> >> As one who follows the WG and having a keen interest in homenet solutions, >> I fail to see how TRILL addresses the homenet problem set. >> >> Producing a flat L2 architecture and then trying to set up specific >> service filters to contain the traffic seems like an L3 problem to me. >> >> Claiming that L3 does not address "security threats" is not a reason to >> use TRILL since I would imagine setting "specific service filters" in >> TRILL would have the same issues (and without the existing IETF L3 >> security solutions we already have) >> >> Don >> >> Dear Don, >> >> Typical home networks could use link-local addresses for all internal >> devices without the filtering concern that effects enterprise level >> deployments. > > The day that spanning tree or trill works well over wireless 802.11, > 802.14, lte, etc will be the day that I start thinking it's suitable > for home use. > > If the DCB folk were to try implementing their stuff on 802.11 in > particular, with it's 1mbit/sec > multicast rate, perhaps we would come to a meeting of the minds.
Dear Dave, Sorry for the delay. I am currently working on a security consideration update. Data Center Bridging (for FCoE, etc), LTE (mobile wireless), 802.14 (multiple services over Cable-TV systems using ATM QOS), or Shortest Path Bridging (SPB per RFC6329) implemented with two ethernet encapsulating data paths -- 802.1ad (Provider Bridges) and 802.1ah (Provider Backbone Bridges). These technologies are within providers' purview and not directly relevant to CPE. Nevertheless, within a home or small office environment, Rbridge remains a viable incremental solution for combining disparate technologies. mDNS is not easily deployed at large scale over wireless without filtering. Wifi has improved by offering mitigation strategies like multicast queuing per N beacons and multicast specific filters. Even so, these strategies are unlikely needed at home. I make extensive use of mDNS within a dense wireless spectrum containing dozens of nearby access points without difficulty while transferring multiple HD+ streams. I would be interested in knowing what problems you are experiencing within your home. Homenet documentation has largely ignored layer 2 protocols essential for defining network boundaries and for offering typical services such as remote displays. These essential functions can not be replaced by any layer 3 strategy. As such, layer 2 must be included in any homenet relevant security and operational consideration. >> In addition, the mDNS to DNS proxy scheme expects routable >> addresses and rather ugly name conversion and base domain assignments >> ignored in proposed specifications. > > They are, at least, consistent. In expressing desires? >> In comparison, Rbridge which can be introduced incrementally, permits >> continued use of link-local addressing and firewalls to avoid a difficult >> task of assessing network boundaries. Devices using default mDNS names >> would not suddenly become indirectly visible and various network enabled >> displays that handle HDCP media still function within the home. > > Service discovery and service access are different things. I don't mind > (that much) if some larger subset of people than I really want can > see that a resource such as "TRACI LORDS PR0N COLLECTION" > exists on the network, so long only the right people can actually > access it. [1] If a local printer is made available via proxy mDNS exposure, there is no way to secure it. Many devices cannot be updated, cannot be secured, and do not offer authenticated or authorized-only access. These are the kinds of issues that should be raised and discussed, even if only in a BCP document. By using automatically assigned routable IP addresses, thwarting stateful firewall protections becomes far easier. Many devices not suitable for Internet exposure will suddenly lack the benefit of only having the typical link-local address. For mDNS, a service proves it resides on a local link by answering link-local multicast queries. A proxy mDNS resource can never offer that assurance nor can it be expected to. > But others may. > > The scope of announcing that something exists may well need to be restricted > somehow. > >> Even if Rbridge is not a viable solution, I would still request that we look >> at the security impact of any proposal - even if it is just in the form of a >> BCP that would be useful for deployment. > > I agree that security needs to be looked at harder in homenet and dnssd. > > I fail to see how rbridge solves anything from a security perspective > if you have home/guest lans, or any other natural division of link > layer technologies. The point of a guest LAN is to impose access barriers except to the Internet. There are plenty of Internet services able to bridge between two different realms. Such as cleaning up infected systems with only access via a satellite link using UDP communications, for example. :^) > Please implement rbridge support over a busy wireless lan and > get back to us. We have implemented network enabled display access by using non-trivial VLAN configurations well beyond what would be reasonable within a home. Rbridge would have greatly eased configuration efforts. Recently non-backward compatible changes have been implemented in Rbridge extensions to better facilitate such efforts. Regards, Douglas Otis _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
