Cisco WLC 802.1X Client Exclusion Sometimes Doesn't Work...

I came across an issue recently and though I'd blog it for others...  Cisco WLC client exclusion not working for some 802.1X clients.  In my case this is using CUWN (WLC v7.x, Cisco ACS v5.3).


This issue effects what I call the 'basic' BYOD setup.  Where certificates aren't in play and AD is referenced directly by the client using EAP methods - i.e. PEAP (MS-CHAP-V2).

The issue being reported was AD account lockout being triggered by WLAN clients.  I thought that this would be unlikely as the WLC excludes clients by MAC when they are failing consistently.  The WLC registers RADIUS-REJECT messages and after 3 failures excludes the client.  The WLC drops all RADIUS requests from the excluded client MAC for the period of the exclusion timer (as configured for the WLAN).

I began testing with an iPhone 4 (iOS 7) and sure enough it was able to generate as many failed authentications as it liked without being excluded.  The client debug and AAA logs showed that the WLC isn't excluding the client because it re-associates after just one RADIUS-REJECT message.  The RADIUS-REJECT counter on the WLC never reaches 3 and the client isn't excluded.  Exclusion works fine for clients that repeat 3 auth attempts without disassociating.

I wonder why the WLC would purge the RADIUS-REJECT count when the client disassociates?  Is this by design or due to changes in modern 802.11 driver logic?  I think Windows drivers tend to play more nicely.

The moral of the story here is that this is one (of potentially many) ways that the AD is opened to malicious attack.  Get smart and implement additional measures to protect AD.  For the WLAN use EAP-TLS authentication.  Implement two-factor auth for all other public-facing services.

Have a look at my Building BYOD blog for further info on securing your BYOD services.

Delivering Customised Apps using MSAP

The arrival of the Hostpot 2.0 / Passpoint / 802.11u revolution is imminent (see my previous blog for more info).  I've been looking at how apps and content can be intelligently delivered to the 'information generation'.  If the info is useful, they want the app for it... 

You may wonder why aren't we seeing cool apps being pushed over public Wi-Fi already?  Well... It means the vendor, integrator or the customer needs to work on developing the app.  This can be a challenge, particularly if the app needs to be developed for a wide variety of devices (new model resolutions, new features, bug fixing, etc).  Whilst only a few organisations have made that investment so far... 'monetising' Wi-Fi through 802.11u may well be the catalyst for rapid development in this area.

Another protocol that will kick-start customised app delivery is Mobile Service Announcement Protocol (MSAP).  MSAP is a way of automatically delivering apps and content to 802.11u enabled devices that support the protocol.

Examples of MSAP services:

• Targeted context-aware customer information.
• Location maps - nearest toilets, baby change, ATM, etc.
• Promotional offers for retail units.
• Stadiums - action replays, statistics, commentary.

How does MSAP work?

• MSAP is Cisco proprietary protocol for service discovery. 
• MSAP is transported via 802.11u GAS (Generic Advertisement Service).
• Wi-Fi clients receive icons and service URLs, they show up in the device OS (if enabled by user). Referred to as 'transient apps', they are removed when you leave the service area.
• Content delivery can be location-aware, i.e. you only receive it when you enter an area.

What do you need?

• Cisco MSE - operates as MSAP server, delivering XML content (a URL) to the MSAP device.
• MSAP supported device - currently just Qualcomm SnapDragon S4 chipset. As of Q1 2013, only Android and Windows phones contain this chip.  The notable exception here is Apple devices…
• Content webserver, mobile app developer.

In Summary

MSAP is definitely a protocol that has potential, there is plenty of demand out there for context-aware application delivery.  Initially it will be a quick win for retail - sales and marketing promotions.  With development there will be real-world benefits to users in a large building, university campus, hospital, shopping centre, or stadium.

The main drawback I see at present is that MSAP isn't a standard. At present only a selection of late 2012 Android and Windows phones running the Qualcomm SnapDragon chip (Apple don't support MSAP yet).  Users will also need to be made aware of the opt-in device configuration.

On a wider note, I should mention that mobile apps can be delivered without 'Cisco' MSAP.  It just means that it's not done automagically, the user needs to download it from an App Store or captive portal.

Resources:

Cisco White Paper on 802.11u / Hotspot 2.0 / Passpoint

Qualcomm / Cisco announcement Nov 2012 

Qualcomm SnapDragon Devices

Monetizing SP Wi- Fi 

Cisco acquires Meraki

Cisco's acquisition of Meraki is an interesting prospect for customers, partners and competitors.  Meraki are an unknown quantity to many, so I thought I would share my opinion on what this means to the WLAN industry.

As a WLAN engineer that has been working with Cisco for 10 years I'm pretty happy about it.  I have been looking at Meraki for a while and picked up one of their AP's a few weeks ago.  If you read my blog about BYOD you'll see I have a lot of love for the Meraki product.

Meraki have taken the controller to the cloud, they look after it.  You choose upgrade windows and never have to pay for resiliency, new hardware, software upgrades or power bills.  You can also buy switches and security gateways for the full feature set.  All are cloud managed through a clean and simple web GUI.  The main selling points of the solution are as follows:

• Plug and play access points (DHCP to Internet is all you need)
• Switch and security gateway appliances for additional features
• Feature-rich WLAN services - URL filtering, firewall, VPN
• Slick cloud-based management GUI
• BYOD out of the box - including the illusive trusted CA (see Building BYOD blog part 2)
• Free MDM for iPhone, Android, Windows, OS X
• Layer 2-7 stats and reporting

Cisco's ageing WLC-centric infrastructure has been struggling to compete in the SMB channel for a while now.   For the last few years companies like Aruba, Aerohive and Ruckus have been turning heads.  However, they will now lose many of their (compelling) arguments against Cisco's previously appliance-heavy infrastructure.

The $1.2bn price tag will be questioned, but I feel that this acquisition is vital to Cisco's strong position in the WLAN industry - and worth the investment.  By acquiring Meraki, Cisco will be able to wade back into the SMB market.  I can only see them expanding their customer base.

Cisco partners will be saying "Awesome, now we can offer BYOD and MDM at low cost".

Cisco competitors will be saying "Damn... We had them on the ropes...".

Meraki partners may be saying "Meh… Now we're going to lose out to Cisco Gold partners"

What does it mean for Meraki products and customers?

Anyone who has recently bought into the Meraki revolution might be worrying about what this acquisition means to them.  If it is anything like the Airespace acquisition it will go like this:

• Cisco will rebadge the Meraki products and maintain current pricing.
• Cisco will honour all current support contracts.  Support will be migrated to Cisco TAC.
• Cisco will phase out the Meraki hardware for Cisco hardware, then offer migration deals.

We're all trying to envisage what Cisco will attempt to do with Meraki.  They may leave them to operate in isolation.  As is stated by Meraki here http://www.meraki.com/company/cisco-acquisition-faq

I don't think cloud networking will extend into the Cisco product set quickly.  However, there is nothing to stop network appliances being offered with 'local' or 'cloud' firmware.  Much the same as autonomous or lightweight AP's today.  However, Cisco will need carefully manage how they offer these products  to customers.

The shift from where Cisco are now with their 'tin' approach to where Cisco could be with an 'IaaS' approach is huge.  This conversation goes way beyond my WLAN blog....

Final word... I'm fortunate enough to be a member of the Cisco Mobility PVT.  So I hope to be able to report back about the good things are going to emerge from Cisco in the near future.  Watch this space...

Mental note! Get CCIE before Meraki technology is added to the exam...

Building BYOD part 4 - Choosing the right vendor

A Little History… 

2005 - Aruba and Cisco hit the market with "captive portal" technology that is prevalent in hotspots today.  Aruba's product was better.

2009 - iPhone arrives… Amigopod (soon to be acquired by Aruba) are the first company to market with a BYOD gateway with PKI integration, but it only supports iOS devices and requires SSID switching for client on-boarding.

2010 - Mobile Device Management solutions arrive offering alternative to WLAN vendor solutions for mobile devices.  Smooth profile delivery mechanisms. MobileIron, Airwatch, Good, Zenprise.

2011 - Cisco release Identity Services Engine, but are still behind Amigopod on development.  Other vendors introduce MDM through partnerships.  PPSK was been introduced as a better alternative to web login by Aerohive and Ruckus.

In 2009 vendors succumbed to the fact that there is a world beyond Windows.  The behaviour of mobile devices also made WLAN vendors realise they needed to find an alternative to web login… A raft of new MDM vendors also emerged.  The recent challenge has been to develop web-login portals that integrate with MDM agents to support multiple device types, operating systems and user databases.  The goal for all vendors it to be able to push EAP-TLS profiles and certificates to a wide range of OS - Windows, OS X, iOS, Android, Windows phone, etc.  But also to be able to support traditional web-login or PPSK solution for non-compliant devices and users.

BYOD portal technology is a logical progression from the basic web-login solutions of 2005.  The ideal BYOD portal product offers the following:

• Single point of entry for all users
• Highly customisable walled garden website
• Traditional web-login for visitors
• BYOD on-boarding options for employees
• Client agents for profile delivery
• Support for multiple OS

One thing I feel that is lacking in most vendor offerings is the ability to customise the portal for corporate branding and content delivery.  This is an important part of corporate identity that vendors haven't made enough effort to accommodate.  This may be explained by the aggressive recent development of BYOD.  In reality, vendors have struggled to develop their own BYOD solutions.  Several have partnered with BYOD solution vendors, or simply referred customers who want BYOD to MDM solutions.  

BYOD Vendor Options

Product maturity is the big question.  Not just in terms of the breadth of device OS support, but also through software development.  As you can see from the timeline, Aruba have a mature product with PKI integration.  Cisco have invested heavily in the ISE product and only in recent releases has the feature set and functionality become comparable to Amigopod.  

Both Aruba and Cisco offer BYOD focused security appliances with a multi-purpose captive portal with BYOD integration for IOS and Android.  Aerohive have also recently developed their own portal that offers MDM integration via the JAMF solution for Apple devices.  Meraki have stormed into the BYOD market with a multi-OS BYOD solution that offers an MDM/client app covering all major platforms (Win, OS X, iOS, Android).  This cloud-based "free MDM" approach is so easy to setup in comparison to all other vendors that the cost-savings are huge, not just in MDM costs.  My concern here is that traditionally WLAN vendors aren't focused on MDM.  Will they stay on top of development around bugs, security alerts, OS updates, etc?  Will their support teams be on-par with an MDM vendor?

A note on PPSK - Both Aerohive and Ruckus offer PPSK which is a big improvement over web-login.  This is going to be a great solution for most companies.  Though if tight security is a concern, I would be interested to know if they are able to tie a user to the client session for litigation against Internet misuse.


In Summary


For the last few years Aruba Amigopod and MDM have been the leading BYOD options.  There has also been an IOS exclusivity in the WLAN vendor space until recently.  Cisco have caught up somewhat with Aruba and other vendors are offering well-rounded solutions with less painful deployments. 

Finding the right solution for an organisation will be about taking all the info on board from this and previous blogs, putting it all together and cross referencing agains the vendor solutions.  Not an easy task... 

I do think that SME customers will quickly move away from vendors with appliance-heavy architecture.  Cisco and Aruba should be worried about innovative and agile vendors like Aerohive, Meraki and Ruckus coming in cheaper and winning customers.

Wi-Fi Location Services for Healthcare

It's fairly common for customers to be unaware of what can be achieved with Wi-Fi location services.  I've designed and deployed several large-scale Cisco / AeroScout solutions for UK healthcare in the last few years.  So I thought I would elaborate on the technology behind these types of solution.

I refer to this technology as 'Wi-Fi location services' although you will also hear it described as Wireless Tracking, RF Identification (RFID), Real Time Location Services (RTLS), Asset Management and Context-Aware Services.

There are several vendors in this space, so I apologise if this blog doesn't cover all the options.  However I've researched this field in depth and am confident that I'm covering the front-runners (Ekahau might like to argue that point).



Architecture Overview

There are three general layers to be considered for the deployment of your Wi-Fi location service.

• Devices - RFID tags, Wi-Fi clients.
• Network Infrastructure - Access points, WLAN controllers, chokepoints, positioning engines and management platform.
• Asset Management and Context-Aware Services - Clever server applications....

The diagram below is a good representation of the interaction between components.

Radio Frequency Identification (RFID) Technology

In simple terms RFID is like a barcode whereby a unique ID is used to define an object.  However, RFID is effectively two technologies and "Which type of RFID is right for me?" is usually the question I'm asked.

There are two types of RFID, 'Active' RFID is different to 'Passive' RFID:

• Active RFID uses larger more expensive tags which transmit 802.11 beacons over several metres and make use of the WLAN infrastructure.  Devices are located by triangulation, think of Google maps with 3G phones being located using signal readings from several nearby masts.  You can get accuracy to a couple of metres if you design the WLAN correctly.  Active RFID tags require 802.11 transmitters and a battery, so at smallest they are the size of a matchbox or  a 10mm thick credit card.  Depending on the tag configuration the battery will last between 3 and 4 years if the tag is set to be fairly idle whilst out-of-motion (yes they also have motion sensors).   
• Passive RFID uses low cost tags which are detected using short-range, low-frequency scanners.   Passive tags are battery-free and attached to the object like a sticker, they are flat and inconspicuous.  Note that passive RFID doesn't work on a WLAN, it requires it's own 'reader' infrastructure.  Think of this technology like security tags in clothes stores using security scanners in the doorway.  You can get accuracy to the nearest reader point or to an area you have define by reader 'gateways'.

Active RFID makes most sense for organisations who want an infrastructure that offers multiple services, e.g. a location system with Wi-Fi data and/or voice.  Passive RFID usually comes as a complimentary solution for objects that pass a given point, such as bed-space or a storage area.  For healthcare I found that the short-range nature of passive RFID didn't meet the requirements to track objects to within a few metres anywhere in the hospital in a cost-effective manner.  To do this with passive readers would mean readers on every doorway - too expensive.  Passive RFID is more in competition with barcode technology for things like patient and blood bag tracking (think NFC).

Network Infrastructure

So let's assume you have chosen Wi-Fi for your location tracking solution, how do you begin to make this location data work for you?

• Tracking the position of a Wi-Fi device requires a location-ready WLAN and a positioning engine with some scaled floor plan images.
• The WLAN access points then need to report the RSSI of the beacons received from the 802.11 device to the positioning engine.
• You need to calibrate the positioning engine through fingerprinting exercises to get those extra few metres of accuracy.
• The positioning engine uses the client RSSI data from a minimum of 3 surrounding access points to produce the coordinates of the object.  Which can then be displayed on the map by the management server.  See below for an example of how the triangulation works.

Key Fact! You don't need RFID technology for RTLS.  All Wi-Fi adaptors can be tracked by their radio MAC address.

Key Fact! The positioning engine isn't responsible for accuracy the site surveyor is!  High accuracy is achieved through careful WLAN design and implementation.  Map segmentation, site survey methodology, scaling of maps, access points placement, map calibration of both frequencies.  If you don't get all of this right you won't get the high accuracy you are looking for.

Asset Management

The positioning engines usually have an API which allows the Asset Management solution to draw information from the system.  The Wi-Fi MAC address of the client is used as the unique ID for the asset database.  Essentially Asset Management is achieved through the addition of meaningful information to the object, for example:

• MAC: 'aa:bb:cc:dd:ee:ff'
• Serial: 'S247462'
• Tag type: 'T2000'
• Asset ID: '0012346'
• Category: 'Wheelchair'
• Sub-category: 'Type 4 Child Buggy'
• Department: 'Paediatric'
• Asset Description: 'Sunshine buggy aged 6-10'

Before you add assets you must configure the system with zones, categories, departments and users.  This will enable asset logic.

The asset logic depends upon the features and functionality of the asset management solution. Within AeroScout MobileView you have things like location of devices by name, category, description, current location and status.  You can also generate events like zone entry/exit, status change, par-level by area, proximity, dwell, out-of-sight and low battery.  These events can in turn trigger alerts such as system notifications and messaging.  'Context-awareness' is the term used to describe the ability to be aware of the assets behaviour and state.  Some examples:

• Location
• Status
• Temperature/humidity
• Motion
• Directional motion

The screenshot below shows context-awareness using an RFID tag with MobileView.

The Cisco/AeroScout solution is impressive and has the ability to offer huge benefits to healthcare.  I've written business case justifications and these type of systems can pay for themselves within a couple of years with even the most basic deployment model.  Primarily it saves staff search time, it allows assets to be maintained on time and avoids loan costs or fines for missing maintenance targets. 

Context-Aware-Services (CAS)

Some asset management solutions provide a basic service around the information they gather.  However if you want an advanced business system that is tailored to your requirements you will usually need to find a third-party vendor who integrates with the API of the asset management solution.

One great example I came across was Nervecentre, which is able to integrate the location of assets with portering systems, nurse call, bleep systems, etc.  This is mostly achieved through CUCM, whereby the Cisco 7925 or smartphone running Cisco Mobile has further asset info.  Using this approach the user's phone becomes their location tracker and can also be used for process management apps.

The following scenario is for a 'porter call' system using a voice and location capable WLAN with Contect-Aware Services.

A nurse raises a porter request for a Sunshine buggy from an app on her smartphone.  The system will locate the closest available sunshine buggy to the nurse and send the nearest 5 porters to the buggy a smartphone notification for a 'porter call', when a porter accepts the job he can use the app to track down the buggy.  Once he confirms he has picked up the buggy he will be given the location and phone number of the requesting nurse.  If he likes he can initiate a call to the nurse to make sure he has the right item and where it should be delivered.

The cost savings that the above scenario delivers are difficult to quantify.  There are certainly time savings for staff.  More importantly, there are cases where 'clinical incidents' occur because equipment can't be found in a timely manner - they incur large fines that could be avoided.  You also need to consider the happiness of staff and patients who can become demoralised when vital pieces of equipment can't be located for extended periods of time.  In some cases staff begin 'hoarding' equipment to ensure they can use it when they need it, this is costly behaviour that we've proven can be reversed.


In Summary

The scenario I described above is achievable and is very close to production in a leading UK hospital I have designed for.  The technology gap is currently the Workforce Management applications that integrate the   Context-Aware-Services with things like porter systems, patient systems, nursing systems and VoIP telephony systems.  There is a huge demand for mobile applications in healthcare that improve efficiency.  Nervecentre are one of the early adopters in the UK for this area and I wish them well as they are a great company.

My final thought here is that some customers will be put off by the technical complexity of the solution and the fact that it isn't cheap.  But I have evidence that the cost-benefits far outstrip the TCO... so why not invest in a futuristic and efficient 'context-aware' hospital?

Sorry! Final, final thought for customers out there... Don't try and save money on the site survey it's the most important part of the design.  Find a professional outfit with experienced engineers and expect them to want to perform their own site surveys.  This has bitten many customers before!

Blog Background

A little background on the blog...

Who am I?
I'm a network architect / engineer / consultant from the UK. After writing a paper on WLAN security for my dissertation in 2003 my career in WLAN began.  I've progressed from autonomous access points to large-scale enterprise WLAN solutions.

Why am I blogging?
My intention is to feed into the already excellent Wi-Fi professionals blogging community that exists.  I will be sharing my experiences on WLAN design, deployment and support.  This will mostly be Cisco from a vendor perspective and hopefully some cool emerging technologies.

I hope you find the blog useful :)