guest i-sid security issues

[jeronimo]

1)

Using guest-isid solely for WoL does not seem to be possible when dynamic VLAN assignment is used.

We can configure a 802.1x enabled port with "eapol traffic-control in" which means that ingress traffic will be denied before (successful) authentication takes place.

Now traffic-control limitation does not seem to work in a network with dynamic VLAN assignment, as you have to use either the default port-based VLAN or Guest VLAN to egress the control traffic (WoL). (A silent device = device waiting for WoL does not have a VLAN assigned in dynamic vlan assignment scenario)

I find that rejected clients can talk to each other in guest i-sid. However we just need a way for WoL to work, we don't want rejected devices to actually be able to use the network.

2)

Using mac-based sessions on a port with a) one MAC (auth success) assigned to a prod VLAN and b) another MAC (auth rejected) assigned to guest-isid. (both on the same port)

Now if IP ranges inside both VLANs/i-sids agree, both can talk to each other (Prod to Guest and Guest to Prod). The latter is the main problem.

How to secure all of this?

[Ludovico_Steven]

Hi, I just tested the WOL VSA.... this is from another email I just wrote on the same topic... sorry copy-paste!

These are my findings:

Extreme-Dynamic-Config='WOL'

Does not work with RADIUS assigned bindings. On an auto-sense port it only works if you have set an auto-sense Data I-SID (globally, or for the port itself).

So, that can be a 1st workaround:

• Set an auto-sense Data I-SID
• Authenticate WOL devices with just a RADIUS permit, no RADIUS assigned bindings, and Extreme-Dynamic-Config='WOL'
• After the device hibernates, and the EAP/NEAP session ages out, you will be able to hit it with the WOL packet on the auto-sense Data I-SID

One caveat:

1. If the WOL device even briefly bounces the link as it goes into hibernation (potentially always an issue with WOL) and if you have auto-sense on the port it would result in auto-sense restarting detection, and once the port settles back into UNI state it will have undone the WOL action on the port (no WOL magic packet will then be able to go out anymore).  Whereas if you disable auto-sense, then even a link bounce will not undo the WOL action!

Another, 2nd  workaround, is to use this RADIUS attribute instead of the WOL one:

Extreme-Dynamic-Config='REAUTH'

+ your desired RADIUS assigned binding: Extreme-Dynamic-Client-Assignments='create=vlan,pv=100,vni=1010103,ev=U',

This way, the NEAP session will never age out (provided the RADIUS server kept authenticating it), so the RADIUS assigned VLAN will always remain plumbed on the port, even if the device hibernates.

But there are a couple of caveats to this one..

1. This only works for NEAP, not EAP
2. If the WOL device even briefly bounces the link as it goes into hibernation, then the NAEP session will be lost, and the RADIUS assigned binding with it

Note that (2) is potentially always an issue with WOL; we do have “link-debounce” on VOSS now, and you can enable it even on auto-sense ports… so that could be solved that way… but we would need a way to enable link-debounce via RADIUS as well I think.

You seems to already have REAUTH in your attributes… just keep in mind that REAUTH and WOL basically negate each other, when it comes to NEAP with WOL; one is supposed to never age out the NEAP session while the other is designed to keep the port transmitting once the NEAP session has aged out.

And finally you can try and use the guest VLAN approach. In that case no need to return the WOL VSA as it is useless.

But I’m not sure I like that approach much, as you say not great for security…

I’m raising the issues with engineering.

[jeronimo]

Thanks,

What we have done now is enable (statically on each switch) dhcp snooping and arp inspection on the guest vlan/i-sid. That way, clients are not able to use that vlan (there is no dhcp service in it at all anyway), but WoL packets sent to the subnet broadcast address still get egressed.

It is a crude workaround, but it works for us / now.

BTW Since the guest service is present on all the ports all the time, we also use it to do loop protection at the edge using SLPP.