Lwapp Mailing List: RE: Another Way to Think about CAPWAP

[Pat R. Calhoun (pcalhoun]

Title: RE: [Lwapp] Another Way to Think about CAPWAP

I see your point. I have considered "policy" in the wider context.

Still I am not sure embedding policy, even straightforward, in the AP is desirable. One may consider allow/deny/allow-802.1x-only as sufficient, whereas other would like (for example) more granularity over 802.1x (i.e allow/deny TLS/TTLS/MD5/etc) or differentiating authentication methods (WEP/802.1x/etc').

<PRC> actually, WEP is a policy that is supported in a particular protocol ;-). The issue here is that encryption is available and cheap on the AP (it's part of the standard shipping 802.11 chips out there). Doing it in the AC requires custom hardware - which is not ruled out, but does complicate implementations significantly. So you can view a WEP key for a station as a specific policy as well.

Maybe it would be better to restrict policy to be enforced at the AC than to open the door at the AP.

<PRC> See above - increases complexity and cost of AC for no reason.

More specific question: why having deny policy for a specific station over rejecting its association in the first place?

<PRC> Actually I added that one for free - it's not in any protocol that I know of, but was an example.

PatC