Why not to use EAP-FAST: Part One

Recently I recommended against the EAP-FAST authentication protocol whilst writing a WLAN design and instead recommended that either EAP-TLS or PEAPv0 (EAP-MSCHAPv2) be used. There were a number of reasons for this recommendation and in this short post I will discuss the first reason - the lack of WLAN chipset support.

For the uninitiated, EAP-FAST is Cisco's answer to the cracked-back-in-'03 LEAP authentication protocol. LEAP was also courtesy of Cisco. EAP-FAST was Cisco-proprietary, became an IETF draft in 2004 and then err, a non-draft fully fledged, fair dinkum IETF RFC in 2007.

Few WLAN chipsets supported EAP-FAST initially but since 2009 it been added to the Wi-Fi Alliance certification program.

Edit (10th Jan 2012): Whilst the numbers below were correct as of November 2011 comments about these figures have made me realise that my methodology was flawed. Whilst I mention below that EAP-FAST has only had since 2009 to be included in the Wi-Fi Alliance certified client listings, I didn't take into account clients that supported EAP-FAST, prior to the Wi-Fi Alliance certification. I doubt even Cisco has an accurate idea of how many clients this includes. In addition, clients that did not originally support EAP-FAST may have since received support via a driver update.

Whilst the numbers may not represent the true extent of EAP-FAST support, my experience has been that fewer clients support EAP-FAST, particularly non-laptop based Wi-Fi devices..Whilst laptop-based driver updates may be available for some clients, driver management in most enterprises is almost non-existent so updating a large enterprise for support of a new authentication protocol would typically not be a light undertaking. This does not even touch on the work required to update devices such as phones, barcode scanners, medical equipment, etc.

Although accurate numbers may be difficult to determine when it comes to EAP-FAST client support, unless you can be sure that the vast majority of your EAP-capable clients do in fact support EAP-FAST I would suggest looking towards PEAP or EAP-TLS in most cases. Part two of this post will document other factors that weigh in when considering an EAP-FAST implementation.

Of the current ~10,000 Wi-Fi Alliance certified WLAN products, ~1,300 support EAP-FAST. By contrast, PEAPv0 is supported by ~4400 products and EAP-TLS by ~5400. Keep in mind that these figures include both enterprise and SOHO products and generally SOHO gear does not support any flavour of EAP. 

So of the three most popular flavours of EAP, the break-down is, as of November 2011:

• EAP-TLS                           : ~54% of Wi-Fi Alliance certified products support it
• PEAPv0 (EAP-MSCHAPv2) : ~44% of Wi-Fi Alliance certified products support it
• EAP-FAST                         : ~13% of Wi-Fi Alliance certified products support it

The number of devices supporting EAP-FAST has been steadily growing but it is still far behind EAP-TLS and PEAPv0. To be fair, EAP-FAST has only had since 2009 as far as Wi-Fi Alliance certification goes whilst EAP-TLS and PEAPv0 certification from the Wi-Fi Alliance has been occurring for much longer. For the time being however, deploying EAP-FAST today means that you may be stuck using (if you're lucky) WPA2-Personal (Pre-shared Key) on some of your managed devices which is far from desirable when alternatives exist.

Cisco Mesh - Ethernet VLAN tagging

The following documents the steps required to get Ethernet VLAN tagging working in a Cisco mesh deployment. This allows you to hang either a single wired client or a switch off of a MAP and allow it to communicate with the rest of the network, via the mesh. This is essentially the mesh-based equivalent of a work-group bridge. The configuration documented below is for connection of a switch to the MAP.

The Cisco documentation for this configuration is ridiculously confusing, contradictory and contains numerous mistakes so much of the following was determined by nutting it out. As such, there may be modifications to the configuration below that also work, depending on requirements but the following has been tested and deployed. There is a BugID for the poor state of the documentation - 'nuff said!

Assumptions

• You have a working knowledge of Cisco mesh deployments
• Having read through the Cisco documentation on Ethernet VLAN tagging and banged your head against the wall may also help
• The following configuration is based on this example topology
• [ACCESS-LAYER SWITCH] --> [MAP] --> [MAP] --> [RAP] --> [CORE SWITCH]

Configuration

VLAN Transparent

• Disable the global parameter VLAN Transparent
• WLC GUI --> WIRELESS --> Mesh --> Un-tick 'VLAN Transparent'

Ethernet Bridging

• Enable Ethernet Bridging on ALL RAPs and MAPs in the mesh network
• If Ethernet Bridging is not enabled on all MAPs and RAPs and the MAP changes its backhaul path through the network, the MAPs and RAPs in the new path may not be able to dynamically create the required VLANs / sub-interfaces on their radio interfaces

• WLC GUI --> WIRELESS --> Access Points --> All APs --> <ap-hostname> --> Mesh -> Tick 'Ethernet Bridging'
• Depending on the number of APs, a quicker way may be to use the WLC CLI command:
• config ap bridging enable <ap-hostname>

 RAP Wired Ethernet Interface (Configured on the WLC)

• If not already set, configure ALL RAPs wired Ethernet interfaces (usually GigabitEthernet0 or GigabitEthernet3) to Normal Mode. This is the default so they probably won't need to be changed
• Contradictions exist in Cisco documentation as to whether Trunk or Normal mode is required. Both work but changing from Normal to Trunk produces a warning that indicates the change hasn't taken place so in effect, the port is still set to Normal, despite being set to Trunk
• The RAP does actually trunk traffic to the switch but the VLANs / sub-interfaces on the GigabitEthernetX wired Ethernet interface are created automatically using a VLAN registration mechanism.
• WLC GUI --> WIRELESS --> Access Points --> All APs --> <rap-hostname> --> Mesh --> <GigabitEthernetX> --> Mode --> Normal

RAP Wired Switchport Interface (Configured on the switch)

• The switchport(s) on the [CORE SWITCH] that the RAP(s) wired Ethernet interface connects to must be configured as a trunkport.
• In the switchport configuration example below:
• VLAN 100 is the Native VLAN and the VLAN that the RAPs and MAPs management IP resides in
• VLAN 200 is the Management VLAN used by the [ACCESS-LAYER SWITCH](es) attached to the MAPs
• VLAN 300 is the User-access VLAN used by wired clients that connect to the [ACCESS-LAYER SWITCH]. Multiple User-access VLANs may be used, if required

• Example switchport configuration:
• interface GigabitEthernet0/1
•  description *** Connection to RAP01 ***
•  switchport trunk encapsulation dot1q
•  switchport trunk native vlan 100
•  switchport trunk allowed vlan 100,200,300
•  switchport mode trunk

• Assuming the [CORE SWITCH] is the appropriate layer 3 point in the network, SVIs for all three VLANs should be created

MAP Wired Ethernet Interface (Configured on the WLC)

• Only the MAP(s) that have an [ACCESS-LAYER SWITCH] connected to them require VLANs configured. All of the other MAPs that act as backhauls for the MAP(s) connected to the [ACCESS-LAYER SWITCH] will automatically pass the VLAN-tagged packets through their radio interfaces.
• Configure the MAP(s) that have an [ACCESS-LAYER SWITCH] connected, by configuring the wired Ethernet interface (usually GigabitEthernet0).
• Configure the same native VLAN and additional VLAN IDs as that configured in the RAP Wired Switchport Interface section above
• These additional VLANs are:
• Management VLAN used by the [ACCESS-LAYER SWITCH] that attaches to the MAPs
• User-access VLAN used by wired clients that connect to the [ACCESS-LAYER SWITCH]

• WLC GUI --> WIRELESS --> Access Points --> All APs --> <map-hostname> --> Mesh --> <GigabitEthernetX> --> Mode --> Trunk
• WLC GUI --> WIRELESS --> Access Points --> All APs --> <map-hostname> --> Mesh --> <GigabitEthernetX> --> Mode --> Native VLAN Id --> <VLAN100>
• WLC GUI --> WIRELESS --> Access Points --> All APs --> <map-hostname> --> Mesh --> <GigabitEthernetX> --> Mode --> Trunk VLAN Id --> <VLAN200>
• WLC GUI --> WIRELESS --> Access Points --> All APs --> <map-hostname> --> Mesh --> <GigabitEthernetX> --> Mode --> Trunk VLAN Id --> <VLAN300>

MAP Wired Switchport Interface (Configured on the switch)

• The switchport(s) on the [ACCESS-LAYER SWITCH] that the MAP(s) wired Ethernet interface connects to must be configured as a trunkport.
• In the switchport configuration example below:
• VLAN 100 is the native VLAN and the VLAN that the RAPs and MAPs management IP resides in
• VLAN 200 is the Management VLAN used by the [ACCESS-LAYER SWITCH] currently being configured
• VLAN 300 is the VLAN used by wired clients that connect to the [ACCESS-LAYER SWITCH] currently being configured

• Example switchport configuration:
• interface GigabitEthernet0/48
•  description *** Connection to MAP01 ***
•  switchport trunk native vlan 100
•  switchport trunk allowed vlan 100,200,300
•  switchport mode trunk

• An SVI & default gateway for management of the [ACCESS-LAYER SWITCH] should also be configured:
• interface Vlan200
•  description ***** [ACCESS-LAYER SWITCH] Management *****
•  ip address 192.168.1.10 255.255.255.0

• ip default-gateway 192.168.1.1

• It is recommended that VTP is set to transparent on this switch

EOF... almost
Cisco Mesh Ethernet VLAN Tagging configuration - what could be simpler? :|

Bad Wi-Fi Never Dies

I am currently in hospital because well, you know, needles are fun and I am sadistic. After going nuts without any mental stimulation all day I finally got a hold of my laptop and was curious to check out the WLAN environment.

Up until now all I could tell was that Cisco 1130 APs are used. The AP density seems to be overly high but without knowing whether some are used for security or location (monitor mode) it is hard to sure. I lost track of those APs with a blue ring after being moved down countless corridors ;).

I am in the bowel of a large hospital and I can't see many APs but despite this I have noticed a number of issues from the small sample size (5 APs). The low AP count is likely to stem from the fact that the hospital was built in the 1850s and therefore the walls are as thick as one would expect - top quality craftsmanship from the convicts!. The particular walls of my room are no doubt newer but this stuff ain't no drywall! Oh, this floor or section of the floor clearly has no APs deployed either.

Five APs and five Wi-Fi sins

• 2 x APs on adjacent channels (channels 2 and 8 in this case);
• 1 x AP using a 40 MHz channel at 2.4 GHz;
• 2 x APs running WEP;
• 1 x AP running WPA using the TKIP cipher (WPA w/TKIP still hasn't been cracked in any useful way so this may not be a massive issue but WPA2 w/AES is preferred);
• 50% of packets transmitted at 802.11b rates (lower than I usually see but far from fantastic).

Interestingly, there are some 802.11b-only devices (bad) but they are probing for WLANs at 11 Mbps. This is a good thing assuming the lower 802.11b data rates have been disabled on the WLAN they are trying to connect to. If you must support 802.11b-only clients, just supporting 11 Mbps is recommended assuming cell coverage allows for it. The MAC OUI vendor of the clients originating these probes is Abbott Labs HPD and a quick search confirms that Abbott Laboratories is a <markting spiel removed> health care company. This makes sense as hospitals are one of the remaining places that you may still find 802.11b-only clients as Wi-Fi equipped medical equipment will generally have a longer usable life than your average laptop. Likewise, WEP and WPA-TKIP may be supported as these 802.11b devices are unlikely to support WPA2 with AES. If you must run WEP still, Dynamic WEP is preferred (if available) along with MAC filtering and one of the few times SSID hiding is recommended. A separate tightly ACLed subnet would be good too. Multiple layers to the onion, no matter how easy to peel ;)

Even though the particular area I am currently in only has a small amount of Wi-Fi activity, many bad practices can be seen with a dash of best practice thrown in. Oh, one last thing - according to the nurse I hit up, Vocera badges don't recognise Irish accents very well and there are an influx of them in Perth at the moment (Irish people; not Vocera badges :)). Something to do with the Western Australian mining boom and Ireland in the hole, one suspects ;)