All I would say here is that networks are not obligated to accommodate every half-baked, livin-in-1988 device that comes along, either. You can say no to the worst offenders, and also work with device manufacturers on occasion to help them drag their stuff into this century rather than risk non-acceptance on campus.
Not to take anything away from David’s good points. Lee Badman (mobile) On Feb 2, 2021, at 11:17 AM, David Logan <tarheeldav...@gmail.com> wrote: One more consideration for network design (especially L2, L3) and policy enforcement architecture, somewhat relevant in this "segment the network? And how?" portion of this thread: the __performance effects/consequences__ of consumer IoT tech operating in the Enterprise setting (what I call BYOT). Here's a couple of examples: All BYOT uses a combination of Bcast and Mcast for ease of installation, peer product discovery and display/print/communications sharing use cases. Flatter networks with no Bcast/Mcast controls in place will propagate the protocols, which in turn will make mobile devices WLAN radios "wake up" more frequently than in an actual in-home location, driving battery life down and causing weirdness for the apps that require these protocols on the BYOT and/or mobile device. This argues for some level of network segmentation, likely beyond macrosegmentation and into microsegmentation. VoIP architectures involving soft clients on BYOD/personal mobile devices and locally hosted media gateways both cause and suffer from performance / scalability problems when the underlying legacy network design forces undesirable network and application behaviors. For example, when a mobile device calls another mobile device in the same "Enterprise" organization, and those devices are associated with a network that prevents East-West flows -- it will require the soft clients to use the (likely) DMZ hosted VoIP Media Gateway to stitch together the call flow acting as a proxy. While these architectures seem to be waning in new deployments, they are still widely deployed, and are frequently sized to support limited inbound/outbound calling through the Media Gateway. This, in turn, causes individual call quality issues and media gateway capacity issues as constant hairpinning occurs, mobile devices roam and need to rekey and potentially re-IP, etc. This argues for consideration of L2/L3/DDI design as applied to BYOD, consideration of where East-West flows are required for expected application behaviors / capacity / cost, in turn requiring consideration for security policy and network-level enforcement. -- David Logan Aruba Networks, CTO office On Mon, Feb 1, 2021 at 8:27 PM William Green <gr...@austin.utexas.edu<mailto:gr...@austin.utexas.edu>> wrote: I don't believe the network is the appropriate place for security to be applied, but witnessing the carnage... I believe there is a careful cost/benefit role. By n=1, I was clumsily referring to Terry Gray's Perimeter Protection Paradox-- wanting to get to a perimeter of 1 (or very few failing that). From a client's perspective, it is more likely to be compromised stepping onto a large campus than staying at home. I haven't convinced myself, but think seriously about the following to help clients. Setting aside the science DMZ exception case... First, if only doing stateful inspection, there are not the combinatorials that occur with firewall rule sets. In the case of most end user device, simple stateful inspection without additional restriction is probably 90% or more of any network isolation/security benefit. Stateful inspection won't likely be coming to access layer switches real soon, but perhaps in a decade. Second, on our campus most traffic is north/south now (very little east/west). Where the north keeps going off to the cloud. At our border, we deploy devices doing full-cone (but could perform stateful at the same rate) where Moore's Law has advanced things quite a bit. Latency through them is under a millisecond at our scale (not perceptible in the general case, and given most is going north to the cloud not really detectable). Third, if one were to trust no devices (about where I am), then why not tunnel all packets from their origination through such a device. Not to protect servers or enforce policies, but to protect the clients. Hardware tunneling capabilities are showing up on access switches, and in the next turn of the silicon likely at more reasonable prices. The same is needed for wireless (since that's were most devices are). Sending all traffic northward for inspection is susceptible to east/west performance issues and increasing failure domains. But if almost everything is already going north that failure domain is already being exercised. ********** Replies to EDUCAUSE Community Group emails are sent to the entire community list. If you want to reply only to the person who sent the message, copy and paste their email address and forward the email reply. Additional participation and subscription information can be found at https://www.educause.edu/community ********** Replies to EDUCAUSE Community Group emails are sent to the entire community list. If you want to reply only to the person who sent the message, copy and paste their email address and forward the email reply. Additional participation and subscription information can be found at https://www.educause.edu/community ********** Replies to EDUCAUSE Community Group emails are sent to the entire community list. If you want to reply only to the person who sent the message, copy and paste their email address and forward the email reply. Additional participation and subscription information can be found at https://www.educause.edu/community
