Autonomous APs: Network EAP vs. Open with EAP, the right combination

When configuring an SSID with EAP/802.1X on an autonomous AP, you are given the choice between Network EAP and Open with EAP (or both).

On the CLI, you would say:
dot11 ssid whatever
   authentication open eap eap_methods
   authentication network-eap eap_methods
As Cisco documentation (for example here) is... er... not completely clear (thanks Seth for pointing me to it!), if not completely wrong, here is a quick summary of which one to choose and when.

First, background information on why this is here (skip this part if you don't care about the whys and just care about the hows).
All this started at the time when we had "nothing (Authentication set to 0 in the AP beacons)" or WEP PSK (Authentication set to 1 in the AP beacons). WEP was weak, so everybody needed a replacement for it. Cisco implemented LEAP, which implies both au authenticaion mechainsm and some encryption. So Cisco set the Authentication value to 1 in the AP beacons using LEAP, not to indicate PSK but to indicate "authentication required" (and this is also why you cannot use LEAP with no encryption). But this does not really conform to the (future, when LEAP was created) 802.11i (and WPA) specifications, so this is Cisco specific...
Later on, when WPA and 802.11i appeared, the protocol detailed that, for compatibility with the 802.1X protocol, the authentication would occur at the association phase. In other words, with 802.1X you plug your PC to a switch, and it is only when you do that that authentication occurs. Similarly in the wireless space, you go through the 802.11 authentication phase (request/response) in an open manner, and it is only when you go to the association phase, which is the "hey, plug me to your cell" message, that the AP says "wait, I need to do 802.1X authentication first", and the EAP process starts. So, Authentication is set to 0 (for its 802.11 part), and EAP/802.1X starts at the association phase.
At the same time, in 2004, ASLEAP was released, and so was 802.11i, following WPA the year before. So when Cisco replaced LEAP with EAP-FAST, the information I have is that they conformed to the WPA/802.11i specifications, and Authentication is set to 0.

So, (whatever the documentation above says) Network EAP = LEAP. Open with EAP = Any other EAP. This is something you see when checking Network EAP: the popup window clearly states that if you use EAP-FAST or any other EAP (than LEAP), you should check Open with EAP. You can of course check both when you want to allow LEAP and another EAP, but you will not be able to authenticate using EAP-FAST if you choose Network EAP only...

There is one exception though... for long, LEAP used to be the default "secure" authentication method. This makes that some old Cisco clients (for example access points!) need to be offered LEAP to get started (or turned on, name it the way you like)!
In other words, if you build a wireless link between 2 APs, for a repeater, bridge or Workgroup Bridge configuration, and if you use 802.1X on that link, you need to offer LEAP (i.e Network EAP) for the secure authentication to be used. So you can offer Network EAP, or Network EAP and Open with EAP, but you should not offer just Open with EAP.
Which one is going to be used if you offer both? Well, it all depends on how you configure your client side (non root Bridge, Workgroup Bridge, etc). If you use the "old" EAP Client (optional feature), in the SSID page:

Which is in the CLI:
dot11 ssid whatever
   authentication client username jerome password 7 104D000A0618
This is going to use LEAP only.
If you want to use another EAP, for example EAP-FAST, you need to empty that EAP Client field (it cannot be used in combination with another method), then use the AP Authentication feature.

In this page, you define credentials and method. You can pick up several methods if you want.
Then from the SSID page, you can call these methods:

In the CLI, this is:
dot11 ssid whatever
   dot1x credentials jerome
   dot1x eap profile Myfast
exit
eap profile Myfast
 method fast
dot1x credentials jerome
 username cisco
 password cisco
So you offer both LEAP and Open with EAP, and using the newer AP Authentication method allows you to to use the credentials you defined, and use the most secure method selected. In this example, we use EAP FAST only, so that's the one we'll use. Of course, the RADIUS to which you main AP points (local RADIUS on the main APor external RADIUS) needs to allow that method.
Careful when testing, it is only from the non-root AP / WGB /  repeater CLI that you will use, at authentication time, which method was used. The main AP CLI will just tell you "WPA", or "Open", etc., but not the details of the authentication method used.
If you offer just Open with EAP, as the AP expects LEAP (Network LEAP) among the possibilities, then the EAP part is discarded. Although your link may come up, if you look carefully at your non-root AP CLI, you will see that the authentication is going to be "Open" (NOT with EAP), so there is no real authentication there. As soon as you also offer Network EAP, the non-root AP is happy, being offered LEAP, btu also something stronger, and is going to use the stronger method (EAP-FAST in our example)>
Give it a try in your lab!
;-)

13 reasons to reboot your access points or your controller

Do they hire people fr Microsoft at Cisco? I don't know, but I know for sure that there are more and more features that require you to reboot your controller or your access points. It is quite difficult to keep track of them in the lab, as you do not want to waste time rebooting too often. On the other hand, if you do not reboot, some changes will not take effect, and you will not always be able to test those changes. So here is a list of the changes I found that require a reboot. If you find more, add them to the list!

Access Points: well, those are obvious.

• AP mode: every time you change the AP mode (local to monitor for example), the AP reboots to reload the firmware matching its new mode. Good thing is the AP will popup to tell you it has to reboot.
• Static IP: whenever you switch your AP IP address from static to DHCP or back, from the controller interface, a popup asks you to reboot the AP. Funny thing is that if you change the IP address from the AP CLI (using clear lwapp ap ip address, to remove a static IP address, or lwapp ap ip address a.b.c.d , you just need a shut/no shut.
• Primary, etc.: if you change the AP primary/secondary/tertiary controller and want the AP to use this information, you need to wait for the AP to unicast a discovery message to that controller. Supposedly, this happens every 30 seconds, so whithin half a minute your AP should send an LWAPP keepalive message to that controller, then join it... if AP Fallback is set to Enable (Controller > General) on the current controller to which the AP is associated... well, you may want to reboot the AP to speed up the process and make the discovery more reliable, at least on code 4.2 (on 5.2 and up, seems to work a lot better).
• Webauth WLAN: when you create your first WebAuth WLAN, you need to reboot your APs for the certificate to feature to be enabled on them. This does not seem to be consistent between code versions, on 4.2.130, failure to reboot the APs seems to cause clients to fail to get the certificate warning page, unless you refresh many times. Good practices say "reboot your APs".
• Mesh AP and MAC filter list: no mesh in the lab yet... but for the sake of listing them all... if you have Mesh APs, and check or uncheck the MAC Filter List box in the Wireless > Mesh page (this parameter forces the AP to be authenticated through a MAC address list before being allowed to join the controller), all your mesh APs have to reboot to get applied this parameter. Supposedly they are supposed to reboot automatically... well, more than often, you may want to reboot those APs that forgot that they had to reboot automatically...

Controllers:

• SNMP user/communities: on the 2106 and code 4.2.130 and 4.2.207 at least, the SNMP communities and v3 users seem to be loaded at boot time. You may discover this painfully when trying to add your WLC to you WCS and get "No response from device, check SNMP communities, version or network for issues". Reboot the controller, things should be better. An interesting detail is that this "feature" (that's how we also call the Blue Screen of Death, right?) seems to be platform and code dependant. So you may have or not have this issue... but keep it in mind if you have an SNMP issue with a newly added SNMPv1/2c community or v3 user...
• Virtual Gateway interface: whenever you make any change to the Virtual Gateway Interface (changing its address or associated DNS name), you need to reboot the controller. The Virtual Gateway parameters are loaded at boot time and not refreshed (cannot change dynamically) during the active life of you controller.
• Certificates: whenever you change a certificate on the controller, you need to reboot the controller for this certificate to be loaded in RAM and used. This is true for any certificate (https access to your controller, WebAuth WLAN certificate, local certificate for EAP/802.1X authentication, etc.).
• LAG: if you set LAG to enable or disable, the change only happens next time you reboot.
• NTP server: controllers query NTP servers at boot time, and at intervals defined by the CLI command config time ntp (or on the Controller > NTP page, Polling Interval). The default interval is 24 hours (86400 seconds), a bit too long a wait most of the time. A quick reboot forces the controller to check the NTP server (I am of course assuming a lab environment, not a production environment).
• Max user database: when you change the maximum number of users in the database (from Security > General), this parameter will only be applied upon next reboot.
• Symmetric Mobility Tunnelling: when you enable or disable this feature (from Controller > Mobility Management > Mobility Anchor Config), you need to reboot the controller for this feature to take effect.
• Code and Config download: this is obvious, but whenever you download a new code to the controller or a previously saved config, you need to reboot the controller for those to be applied.

Don't reboot:

• Short/long preambles? Cisco documentation states that you need to reboot the controller if you enable or disable short preambles (in Wireless > 802.11b/g/n > Network). This is a myth (or a leftover from ooooold times). When you change this parameter, you clearly see in the AP beacons capability field the Short Preamble Allowed parameter switching from 1 to 0, and the "long -preamble only" stations failing or succeeding to associate accordingly (tried on an old handheld scanner).

So, in the lab, should you reboot every time you change one of those, or reboot once sometime during the day (for example at lunch break)? I am not sure there is an absolute rule. I find many people saying "reboot once, this will save you time". I like to multi-task. So I would rather reboot when I change one of these parameters, do another task then come back to finish this one. This will ensure that I can test the feature if needed, and that I do not leave too many things to verify when coming back from lunch...

7921: can you do WPA2?

You may have read different stories about the 7921 phone and its support for "strong encryption", that is AES-CCMP in a WPA2 logic. This is what the issue is:
The 7921 phone, until firmware 1.3(4), does support CCKM, WPA and WPA2, but not in any combination of those!
- WPA (TKIP) and CCKM work fine
- WPA (AES) and CCKM work fine, but this is bad practice (so that's a no no, unless you are specifically asked for this awful combination, coz after all, it's a lab, not real life)
- WPA2 (TKIP) and CCKM work fine, but this too is ugly, so another no no, unless they really insist.
- WPA2 (AES) and CCKM do NOT work together. What happens is that the phone does not take the roaming process well for the AES encrypted keys, and forces a full reauthentication.
In other words, you usually want to enable CCKM with Voice, because CCKM caches the key and allows for faster roaming (which is good for voice). But this does not work with the 7921 and a firmware older than 1.3(4).

So what should you do? Use WPA (TKIP) and CCKM, or WPA2 (AES) without CCKM? Well, all pushes you to use WPA (TKIP) with CCKM. The reason is that there is no reasonably usable  attack against WPA/TKIP encryption (provided you use 802.1X authentication, and not PSK), so TKIP is rather secure, and CCKM is definitely a plus for voice.

But all this is is you use a firmware older than 1.3(4). On 1.3(4) and later, you would prefer WPA2(AES) with CCKM, which is a supported combination on 1.3(4) and later. This firmware was released in its stable form at the end of May 2010. The CCIE W lab started a year before. So unless the hardware was updated in the lab (the lab blueprint does not specify a7921 specific firmware version), you will get firmware 1.2.1 and will have to go for the WPA/CCKM combination, if you have voice, 7921s and a requirement for strong encryption... but it may be worth checking!
On your phone, press the down arrow to access the tool box, then go to "6, status", then "4.Firmware version" to check the App Load ID, which will display the firmware with a value in the form CP7921G-1.2.1.LOADS.

CCIE Wireless lab: more seats to come

If you ever tried to book a seat for the CCIEW lab, you probably were shocked to see that the waiting list was at best 3 months, and in many cases 6 months.
So far, there are 3 racks for the CCIE W lab: 2 in San Jose, 1 in Brussels. You can take the lab from 3 locations: San Jose (on San Jose pod 1 or 2, but only one pod is used at a time for San Jose candidates), Brussels (on Brussels pod), and Sydney (using one of the San Jose pods).
The lab team is adding a third physical rack in San Jose, that will be dedicated to RTP candidates. So, from August 1st, you will be able to take the lab from RTP (for those who may not know, RTP is in North Carolina, USA), having a local AP and VoWLAN phone in RTP, and the rest of the pod as rack 3 in San Jose. This is great news, because it will not only add new seats on the East coast, but also partially unload San Jose...
This is huge effort for the CCIE W lab team. Although it looks very simple from outside ("hey, you guys are Cisco, just get to the warehouse, pick up hardware, and set up a new rack!"), it is in fact far more complex. Just like for you and me, getting a lab gear is an investment on the team budget, that has to be justified in terms of utilization... and as you know, each pod is expensive (yeah, of course they have a discount, but it still makes each pod a serious investment), so ROI on such an investment is probably not obvious for most managers, including at Cisco. So they probably have been struggling to get that new pod going so that us, candidates, get more seats. Thanks guys! This will make our attempts easier and the waiting time between attempts shorter.

Coverage hole algorithm thresholds

You know the coverage hole algorithm, triggered when some clients get below a certain SNR, and configured here:

 Now here is a question: I have wireless clients that do not react well when their AP signal gets too low... could you configure the Coverage Hole algorithm to be triggered if any client signal on AP1 gets below 19 dBm SNR? Oh, AP1 power level is statically set to 2  (and level 2, as you could see if you ran the show run-config command on my EUROPEAN controller, is 14 dBm).

Can you find what the threshold should be?

Ok, here is the solution. First, Coverage Minimum Exception Level is to be set to 1 (as the algorithm as to be triggered if "any client"...).

The harder part is the Coverage value. The client SNR cutoff triggering the coverage hole algorithm is calculated as follows:

Client SNR Cutoff Value (|dB|) = [AP Transmit Power (dBm) – Constant (17 dBm) – Coverage Profile (dB)]

My AP power level is set to 14 dBm, and as you can see on the above picture, the default Coverage Profile value is set to 12. So we have:

Client SNR Cutoff Value (|dB|) = 14 -17 -12 = -15

Although this number is negative, we are looking at an SNR cutoff of 15 dBm.

You want 19 instead (so result must be -19)?

The only value we can change is the Coverage Profile, setting it to 16 solves the problem...

Easy he? Yeah, I know...

In code 5.2, it gets a little better, you can also set RSSI values etc...

Do you need DHCP Option 60?

When configuring a DHCP scope for your LWAPP access points, you can return, along with an IP address, the controller Management IP address. This is called option 43, Vendor Specific Option. It is vendor specific in the sense that, in our case, only an access point would know what to do with Controller Management IP address information.
If you have read older papers, you may also have seen the option 60, Vendor Class Identifier. Do you need it, or not?
This is what it is about: when you AP boots, it sends a DHCP discover message. This message contains, among other things, a section that identifies what kind of device is requesting that IP address:

As you can see from this packet capture, in this case the AP says "I am a Cisco AP c1250. Can I get an IP address please?"
When you define an option 60 in your DHCP scope in combination with the option 43, you say "IF client is a Cisco AP c1250, then return the Vendor Specific Option defined in option 43". In other words, the content of option 43 is returned only to those clients that present the right option 60.

When using Windows DHCP server, you do not have much of a choice. The right process is to
- first define the Vendor Class Identifier
- then for this vendor class identifier define what kind of Vendor Specific Option you want to return. In our case, the option is always "option 241: controller Management IP Address" for Aironet APs and "option 102 (also controller Management IP address" for 1000 series Airespace APs
- Last, define the value of this option 241 or 102 (that is, the controller Management Interface IP address you want to send back).
So, with Windows DHCP server, you use option 60 without any real good way to avoid it.

When using an IOS DHCP scope, you do not need to specify an option 60. You can specify only the option 43, which will be option 102 if returned in ASCII and option 241 if returned in Hex.
If you specify an option 60 for that scope, the content of option 43 is returned only to those clients that present the right option 60. If you do not specify an option 60 for that scope, the content of option 43 is returned to any DHCP client asking for an IP address in that subnet.

What is the recommended practice? Or: why do some papers describing option 43 for the IOS mention the option 60, while some (many) others don't?

Well, the answer is quite simple: in the lab, I would try to put my option 60 whenever I can...
In real life, well, option 60 is cleaner: you do not send the content of option 43 to clients that do not need it. On the other hand, you should have a infrastructure addressing space, and a client addressing space. This means that your APs should be in one subnet/VLAN (the AP VLAN on that switch), and clients should be in other subnets. This makes that only APs should be in the subnet for which you provide this option 43. So there should NOT be any client NOT needing this option 43 and still getting an IP address in that scope: all clients of that scope are supposed to be APs! This is why you find many papers without this option... not to mention the fact that this option may be cumbersome to use when you have different APs of different models in the same subnet... but the lab is of course not about what is nice and simple, but what can technically be done, right?
:-)

WPA/WPA2 broadcast key rotation on a controller

This one is (IMHO) way beyond what you should need to remember for the exam, but I actually dreamed about it last night, so I though I should share the fun!
Special dedication to Kyle, he is the one who raised this issue and found the solution.... :-)
So here is the deal: when you use WPA or WPA2, your wireless client gets 2 keys: one unicast key, for its own traffic to and from the AP, and one broadcast key, which is a common key for all clients in the same cell. This broadcast key is used when the AP sends broadcast messages to all clients in the cell, so it's a shared key.
You may want to rotate those keys, change them every now and then so that a wannabee hacker would not have enough packets using a specific key to even dream of running an attack against your encryption scheme.
Changing the unicast key can be done by setting the EAP session, everytime the session is renewed, so is the unicast key... but the broadcast key is not, because it is shared. On the autonomous APs, you can rotate the broadcast keys from the Security > Encryption Manager page:

You can enable rotation at regular intervals. The gotcha here is that only 802.1X clients can join a network that has this feature enabled.
When using WPA, you can also enable key rotation "on membership termination" (every time a client leaves the cell, the key is rotated for the clients still in the cell), or on "membership capability change" (everytime a client using static WEP enters or leaves the cell, the key is rotated).

Ok, but what about the controllers? How to rotate the broadcast key on the WLC? There is no checkbox, and no CLI command for that... the key is rotated every hour... what? I want this feature for my clients security!!
Kyle found this nice info:

CSCsi27596—The controller lacks a supported way to configure the broadcast key rotation interval. Instead, it is hardcoded to a group key rotation interval of 3600 seconds (1 hour).

Workaround: On the console, configure the hidden command devshell dot1xUpdateBroadcastRekeyTimer(seconds). This command does not work in an SSH or Telnet session and does not survive a reboot.

Example:

(Cisco Controller) >devshell dot1xUpdateBroadcastRekeyTimer(86400)

value = 0 = 0x0

I dreamed of it because the example, instead of rotating the key every hour, seems to rotates it every... day (unless 8600 is the max value)! Wow, nice and a lot more secure!

I hope you don't need that for the lab, because this is pushing the system to its limit (and I hope you won't dream of it), but it is fun to know (or at least to know where to find it)...

:-)