Really, Google? (Or Why We Can’t Have Nice Wireless Networks)
it.toolbox.com
it.toolbox.com
Like when you have to start creating VXLANs to accommodate devices that assume L2 adjacency or installing L7 proxies I think it's fair to say there's some fault with the application vendor.
I don't think the title fully encapsulates how astounded I am that this made it through the multiple layers of the Google corporate machine without someone in the chain, someone, saying, "umm..." Next time someone asks you to review those user docs, really read them this time in case you have to be the one raising your hand. ('cuz I know I've been guilty of kind of skimming them.)
(a server-based fallback would have some value, but I bet people would find something to complain about that too. To slow, unnecessarily sending data back to Google, ...)
I believe the issue at hand is the question of who the user is going to call when that doesn't work. The phone vendor? The phone OS vendor? The telecom? Hmm, somehow I feel that those three options will not be first on the list, but rather who is closest and has technical knowledge of any kind.
I agree with the article on "they should specify what they need exactly" though, for those orgs that want to explicitly allow it in their main infrastructure instead of providing a workaround.
The biggest problem is that this is a product DESIGNED to be placed in educational IT environments. As such, the product should either be designed to work in those environments with reasonable effort and without violating common security practices.
It's like marketing a car specifically to people with garages that are too small to fit the dimensions of the car. Either you make the car fit where it needs to go or you market it somewhere that fits. You DON'T market it to a demographic who can't reasonably use it. You're just making bad press for yourself.
And as a network IT guy myself we have a responsibility to maintain order on the networks we administer. Just because someone calls me down to their desk to install CCleaner on their laptop doesn't mean I'm obligated to do it. Infact I'm obligated to steer him in the right direction and make sure he understands the errors of his ways.
IT is the gatekeeper. You don't tell IT what to do... You tell them what you want to accomplish and let them tell you how to do it.
You go to your doctor and pay him good money so he can tell you how to properly take care of your body. If your doctor tells you that you have diabetes and you continue eating sugar, you will die.
If your IT department tells you something is a bad idea there's a reason for it. You don't have to understand his logic, and he doesn't have to explain it to you. Your company pays him to understand all of that so you don't have too.
Enterprise infrastructure is extremely complex and enterprise applications are often extremely fragile. If the company could exist without their contributions I'm sure there would be no IT department.
And I'm claiming that the effort required is reasonable, and it's thus not that big of a deal, even if slightly annoying in that it requires effort and doesn't just work. In the few environments I've worked in a sysadmin role, it wouldn't have been a problem to provide a one-off network that doesn't touch the official network if requested by a user, and in one it'd been completely fine if the user just set up an isolated AP as long as it didn't interfere with the official ones (university network)
Sounds like Google to me.
It used to be rare for IT to have any real practical UDP/multicast/broadcast experience, mostly because general support was so bad.
Wireless and wired networks commonly are in different network segments, vs Bonjour etc. generally assuming devices are in the same and using only local multicast - so the network explicitly has to provide a proxy bridging that traffic between segments, not having rules forbidding traffic between them (which also would be normal to have) isn't even enough.
Or a weak one from the perspective that security must address usability since otherwise users will route around the “secured” system for functions which should be performed within that system.
If I know the IP of a friend on the LAN, I can connect to him directly, as normal - the connection will not be blocked by the router. But other than that, the router shows my device a view of the world in which it is the only thing connected to the LAN.
Enumerating the private IP space and trying to connect to all of the possible addresses might reveal the actual stuff though? But the multicast protocols I assume use a smarter and more efficient approach which gets blocked by client isolation.
Ruckus calls it bonjour fencing, and has pretty good support for creating useful policy.
http://docs.ruckuswireless.com/smartzone/3.6.2/sz300-vszh-sc...
Also, Enterprise IT is often averse to anything that's not centrally managed, and Bonjour is the anthesis of centralization (it's all peer-to-peer). Some networks turn on client isolation so that peers can't talk to each other at all, often in the name of security.
That said, there are ways to get this stuff to work right in an enterprise setting. It requires careful network design to keep broadcast domains small, ideally with an mDNS Reflector running somewhere. All the major WLAN vendors have custom options for supporting it, with varying levels of customizability:
- Cisco: https://www.cisco.com/c/en/us/support/docs/wireless/aironet-...
- Aruba: https://www.arubanetworks.com/techdocs/Instant_41_Mobile/Adv...
- Ubiquiti: https://help.ubnt.com/hc/en-us/articles/360001004034-UniFi-B...
Admittedly, it's hard to get right, the apps that need it are not usually business critical, and there's not many apps to test with... so most IT shops just turn it off and avoid the additional headache. Which is unfortunate, because it effectively kills off any peer-to-peer functionality on the LAN.
Disclaimer: I work at Google, but not on any of the teams mentioned in the article. I am a big fan of mDNS, but that's my personal opinion.
Fortinet nails this, took me a day to figure out.
This is usually solved through some sort of mDNS proxy, but you don't really want to proxy everything. If your phone discovered all of the apple tvs and chromecasts across campus, then it wouldn't make for a good user experience for anybody.
Mdns proxy would have been the solution, but I was never able to get it to work. It seemed to me that no one actually managed to get it to work, based on my Google searches at the time.
Of course, getting it to work on the corporate network was even less likely.
Any standard firewall contains tools for PIM (protocol independent multicast) routing. PIM router as the GW for both subnets / VLANs does the trick fine, and is easy-ish to setup. Using this for mDNS printer discovery on a guest network to an internal printer network.
This article is right in that multicast is stupid to use for this, but wrong in that the purpose of a net admin is to NET ADMIN. Make it work and quit whining, multicast is not a new or difficult problem.
Also protocols like Bonjour by default only work on the local network which at home might well be all there is while at work might be one of many.
Making a one-size-fits-badly policy is how you get large amounts of shadow IT and assets on non-controlled machines.
The security policy has to balance with what the users are tasked with, and what's expected. And when IT won't budge, you get really weird stuff happening.
I've seen professors running a linksys natted network on a uni lan, precisely because he needed control and lookup of IPs for his robotics setup. And Uni IT did their knuckle-dragging usual of nothing (blame the user). His solution was "insecure" but that went to his real task of robotics prof.
If you came up to me and said "Hey I want to plug in my own router in my office so I can have my own little WiFi network for my projects" I'd tell them no, it's against policy, against SOP, against best everything, and it would be an unmanaged, insecure, non-company asset (probably with default credentials and unpatched firmware). I would then just nod my head at his hemming and hawing and invite him to go over my head.
Now... If you came up to me and said "Hey I've got a ton of wireless devices in my office that are related to my work. What would be the best way for me to network them all together and isolate them from the rest of the network?" I'd gladly draw up a plan to get the task done, order the assets that I want in my shop (with company money), configure it the way I want, and then roll it out and keep tabs on it.
Just doing whatever you want on the network because IT won't let you is asking for trouble, and could/should get you fired.
That's the most common problem users have with IT.
He needed not wpa2 enterprise wireless. WPA2 personal would have sufficed for his robotics... but "Policies". When he asked how to proceed, IT-Networks responded with "We dont tell people how to do their networking. We enforce policy."
He had contacts in IT (my director), and put me to make it work. So I helped configure a better router, made sure DHCP and other protos wasn't leaking out the WAN, set a stupid long PSK. Took me .5h to get a good environment set up. And sure, it violated policy, but it was secure and enabled the prof to continue his swarming robotics experiments.
Is there some kind of interval version of upnp? Nmb is theoretically possible, not wouldn't work outside of specific environments.
Do you have documentation on this product that indicates it scans the subnet?
So then you proved your statement wrong, there is not a setting or feature called "enable p2p"
>This isn't even specifically about multicast
According to the article it is
as far as picking a "fight" I was not, I was being technical. When it comes to talking about Technical things I prefer when people are technical. This is key when writing technical documentation.
For example, if you were writing a technical doc you would not put in the doc "Turn on P2P feature" as that feature does not exist, instead you would say "To enable P2P communication, turn off Client Isolation"
One should be technical when talking about technical things, and assuming "most network engineers know what you are talking about" is often how mistakes are made...
I have seen companies lose millions because one engineer assumed another engineer knew or thought about, or would preform steps not included implicitly in an instruction set
He tried that