Wing - secure deployment in campus

[el_magneto]

Hi, 

In my network security is always a big concern and I wonder how can I maximaze the security of adoption process and communication beetwen APs in RF Domain (common VLAN). In a standard way of adoption  it is based on a MAC adress of an AP (as far as I understand MAC address is a factor that distinguish beetwen devices)  whether I use auto adoption policys or static configuration on controller. But what if I want to be 100% sure that device adopted is mine and noone changed it into its own “hacked” device with spoofed MAC adress (even if this is very hypotetical situation)? Is “auto ipsec” a solution here? Or maybe somthing else? But what about mint links between APs in RF domain - the cannot be secured by ipsec. Am I right?

So the question is - is there a way to secure deployment so only devices which where in my “hands” before deployment can be adopted and form mint link/adjacencies beetwen each other in RF-domain?

If my way of thinking is wrong then correct me please 

[ckelly]

Agree about the spoofing...though the serial number part would certainly be more difficult...but the old adage - Security is like an onion.  Layers.  Make it as difficult for them as possible.

Not sure what you’re referring to with the “ service wireless inter-ap-key”.  I’m wondering if maybe you’re referring to the MINT area-id.  Please expand on that.

[el_magneto]

In a hypothetical situation if someone can spoof MAC of an AP he can also spoof a serial number. Correct me if I’m wrong.

I tired to test service wireless inter-ap-key but it seems not to work. I have a test RF-domain with 2 APs. And I set different keys on them. But they still can see each other, form neighbours link. Are still “mint pingable”. How to check if this command is working properly?

And I noticed that auto IPsec has a downside that on the controller you can set only one PSK and group ID for all APs. I thought I could build group ID + PSK per RF domain.

[ckelly]

If you want to tighten things down, then also consider setting up your auto-provisioning policy to include the serial numbers of the APs as a requirement for adoption.  In this case, if an AP is wanting to adopt, it must have a serial number that matches what you’ve specified.

There are other match criteria, but the serial number would be the best selection here from a security perspective.

[el_magneto]

So.. to summarize pieces of secure deployment:

• 802.1x on switch ports connected to APs (if possible)
• secure management policies on Controllers and APs (minimum access)
• auto-ipsec for adotpion and secure communication between APs and controlers  (but as pre-staging process , no auto-adoption, before adoption AP must be cofigured with key, group etc.)
• “service wireless inter-ap-key” for secure MINT communication within a VLAN bettwern APa in RF domain.

Something needs to be added?

[Tomasz]

Hi,

Agreed. It would be also good to distinguish particular attack vectors as they are going to have different countermeasures possible.

Assuming that securing access to MINT-related VLAN is not possible, we have controller/AP management plane to secure and MINT frames themselves.

Regarding management access, IMO Management Policy is fair enough to restrict management connection attempts to a controller (to just particular source IPs and to particular protocols and ports) and to APs (all can be disabled, you will always be able to reach AP CLI with a console port and thru controller’s CLI with ‘connect’ command).

Regarding MINT security without IPsec… I didn’t play with this command yet, but maybe could help with MINT encryption:

service wireless inter-ap-key

CC @Chris Kelly@vanelm 

Hope that helps,

Tomasz