By Dumb Devices I mean things like Alarm Panels, HVAC Controllers, certain NVR servers, etc.
These devices seem to share a common trait: they "don't speak unless spoken to."
In other words, unless you go to ping it or log into it, that device will never send a frame out on the network. Your interface counter, if reset while the device is idle, will still show 0 bits received like 2-3 days later.
Ok, that's fine, the network is already full of noisey devices that spam broadcasts to everyone, we should be eager to welcome these silent devices into our network.
The problem is in environments where we're mandated to do 802.1X authentication.
These devices don't support 802.1X so they must be authenticated based on their mac address: "MAB" if you're a Cisco guy, "mac-radius" if you're a Juniper guy.
The problem is, in order for mab to work on these devices, the switch has to receive a frame from the dumb device. Depending on the vendor and version, the switch may try to poke the device a few times with EAPOL messages, and then finally declare it an unresponsive device and try to run MAB on it. Or depending on the order you have configured, the switch will just run MAB on it first to see.
If the MAC Address is in the database of the RADIUS server, you're off to the races. The device authenticates, and the switch allows layer 2 traffic to flow.
But for the dumb devices of the first paragraph, they will never, EVER, send a frame to the switch unless some other device sends packets to them first.
Ah now we're getting into the chicken and the egg problem. How can one send packets to a device, that is not authenticated? After all, when a port is in an unauthenticated state, the switch will NOT pass traffic on that port.
Cisco has an option called "control-direction in" that allows the switch to pass EGRESS ONLY traffic on that interface, this allows dumb devices to receive traffic, and then reply to that traffic so that they can be MAB authenticated.
As far as I know, Juniper doesn't seem to have an option for "control-direction in" and just nativley does it (someone who knows different please correct this is wrong.)
So great, now we have control-direction in, our "dumb devices" can work with MAB.
There's only one huge, huge problem, that breaks.. everything.
Dynamic VLAN assignment.
If you're also doing Dynamic VLAN assignment with 802.1x, which you most likely are if you're in an environment that mandates using 802.1x, then more than likely non-authenticated ports will be placed in a dead-end VLAN.
Now suddenly you CANNOT "wake the dumb device up" with traffic, because even despite "control-direction in" you will now NEVER be able to get a packet to the dumb device, because it is sitting on the dead-end VLAN for non-authenticated interfaces. Your packet will become an Unknown Unicast frame that the switch will spam out to every interface in the PRODUCTION vlan, never reaching your poor little silent dumb device, because it's now sitting in the WRONG VLAN.
Well, it's simple, reddit will say--stop doing MAB on dumb devices. That's not secure anyway. Anyone can spoof the MAC Address and boom, you're in.
Only that solution doesn't often work in the real world, in an environment where you HAVE to use 802.1X for every interface, no exceptions can be made. This is a policy issue, not a technical issue.
Another fix? Statically assign the correct VLAN to the dumb device's port. This actually fixes the problem nicely, because the port is still protected by 802.1X authentication, but now with control-direction in you are able to wake the device up, make it talk to the switch, and the switch will MAB authenticate it with the RADIUS server.
Only that solution too is adamently REJECTED in the environment where you are mandated by policy to use dynamic vlan assignment with 802.1X
So, it's the old chicken and the egg problem: There's no real solution at all that works, other than making an exception to your organization's security policy.
I realize only a very few who post here will probably share this specific problem, but on the very off chance that there are: how did you deal with the problem?
Right now we're living in a situation where we're kinda shrugging our shoulders saying "it's not the network" and letting the users get mad and put in tickets every time the device won't respond. Every time we get the ticket we see the device is sitting idle and not authenticated, and we bump .1x on the port get it pinging again and close the ticket.
This has been going on entirely too long and is starting to get extremly frustrating both for our team, and for the users. Yet no one is budging. Good times.
No comments:
Post a Comment