Pages

Friday, July 22, 2011

Cisco Live! 2011 Wireless & Security Recap, and an Apple Rumor

Last week at Cisco Live! 2011 I attended several sessions related to wireless LAN products and would like to provide a review of the major technical announcements that I took away from these presentations. Due to the overwhelming amount of technical content provided over the course of the 6 days, I won't be providing detailed recaps of each session. However, there were several major announcements that could impact customer roadmaps that I would like to discuss.

You can also read my article on value of live events on professional development and networking on the Cisco Mobility Blog.

CCIE Wireless Version 2 - On Sunday, several of my peers attended a CCIE-W techtorial which discussed the changes to expect in v2 of the written and lab exams. I did not attend this session, but you can find excellent recaps of the information presented by Jason Boyers (IPExpert), George Stefanick (my80211.com), and Blake Krone (Digital Lifestyle). You can also find my previous review of the v2 blueprint changes.

Some of the interesting facts that I caught from other included the relative scarcity of CCIE Wireless engineers - only 45 total worldwide, and only 27 outside of Cisco. Small numbers indeed!

ISE / TrustSec Overview - Several salient details of the new ISE platform include:
  • ISE bundles multiple systems under one product, including ACS, NAC Manager, NAC Server, NAC Profiler, NAC Collector, and NAC Guest Server. These roles can all be installed on a single ISE instance or split between multiple ISE instances.
  • ISE is out of band and provides central policy definition and enforcement.
  • ISE focused on determing both device and user identity for complete contextual policy definition and enforcement. It supports a myriad of EAP types, similar to the Cisco ACS product.
  • ISE also provides policy management for non-802.1X capable clients via MAC Auth Bypass (MAB) and/or web-authentication, which is important for wired network security. 802.1X timeouts will need to be tuned much shorter than the default of 90 seconds to allow MAC Auth Bypass and DHCP processes for non-802.1X clients to continue un-interupted, prior to device profiling and policy enforcement. Pre-auth ACLs can also be defined to limit access until device profiling and policy assignment can occur (PXE boot is one scenario to consider).
  • Flex-Auth aims to allow a single port-configuration to accommodate client devices of all types (802.1X, MAB, web-auth) to ease switch port management. Failover behavior betweent authentication types can be defined to meet customer requirements.
  • ISE supports device profiling using many different methods, including 802.1X authentication parameters, MAC address OUI lookups, DHCP options via SPAN port / IP helper / proxy, reverse DNS lookups, HTTP user-agent via SPAN port / captive web portal on ISE, NetFlow v5/v9, and SNMP queries & traps.
  • Device profiling is hierarchical, can define generic categories then drill into more detailed profiles if desired to apply more specific policies. (Example: IP Phones > Cisco IP Phones > Cisco 7960 Series).
  • Device profiles can be created using combinations of gathered information from the previous bullet point to provide a more educated interpretation of what the device is. This should help reduce false positives and false negatives as well as make it difficult for someone to spoof multiple device capabilities.
  • ISE fully supports RADIUS Change of Authorization (COA) which allows dynamic policy changes in the middle of client sessions if the environment changes. Previously, only support for initial policy assignment upon the initial network access attempt was supported. COA can include client disconnection, re-authentication, port bouncing, or port shutdown. Note that the WLCs support COA as of version 7.0.116.0 code.
  • It supports authorization & policy management via dynamic VLAN assignment, dynamic ACL assignment, downloadable ACLs, and Security Group ACLs.
  • ISE provides a new security paradigm based on Security Group Access (SGA). SGA relies on Security Group Tagging (SGT) which is hardware ASIC dependent. SGTs are assigned based on successful RADIUS authentication and attribute assignment back to the network access device.
  • Older equipment such as the 3750 switches do not support full Security Group Tagging. Such platforms will rely on a software upgrade to support the SGT eXchange Protocol (SXP) which will relay IP address to SGT mappings to neighboring equipment which do support SGT. This allows end-to-end network-wide support for the Security Group Access model and a migration path without forklifting existing equipment. Note that the wireless LAN controllers will support SXP with code version 7.0.116.0 and later. For a full list of hardware and software compatibility, see the Cisco TrustSec SGA Solution Config Guide.
  • SGA simplifies network security policy enforcment with ingress SGA tagging, and egress SGA enforcement based on both the source and destination SGT combinations. This reduces the need to distribute policy definition throughout the entire network, simply enforce security for central servers and data stores once at egress. See the solution guide linked above for more information.
  • It currently does Not Support TACACS+, only RADIUS (focused on client authentication, not admin).
  • ISE logging is much more detailed than the current ACS product, providing more information to troubleshoot authentication and policy management for clients.
  • ISE and NCS management platforms are tightly integrated. The GUI looks very similar to provide consistency, and client reporting in NCS provides ISE specific authentication and profiling information for easier monitoring and troubleshooting.
See my previous posts for a review of Wireless Network Segmentation Options and Dynamic VLAN Assignment.

WLC Code Support - The legacy WiSM-1 and 4400 series controllers will not be supported on code versions 7.2 and later. The latest supported code version will be 7.0. Customers should plan accordingly and prepare for hardware upgrades in the near future if they intent on deploying new features. Note that sotware maintenance for bug fixes and security patches will continue on the 4400 platform until 2014 according to the EoL notice.

ELM aWIPS Limited HW Support - Enhanced Local Mode (ELM) WIPS will only be supported on 802.11n access points. I am not sure if this is due to hardware limitations or not, but this is a huge issue for existing customers looking to support this feature. ELM was designed for highly distributed environments where the cost of an overlay solution was prohibitive. In lieu of that target market, I would have to say that Cisco seems unwise to limit support to new 11n access points. I would venture that most retail or other distributed environments already have deployed wireless network, many with older 11a/b/g hardware. The whole value proposition of ELM to reduce hardware deployment costs gets thrown out the window with this move and really invites customers to evaluate the entire WIPS market which includes other overlay solutions. This can only be a bad move for Cisco!

RRM Modifications - Significant changes to the RRM algorithm have been made between WLC versions 4.2 to 7.0. These include fixes to eliminate pinning (the worst APs cannot improve and prevent other APs in the same RF group from being changed) and cascading (propagation of a single channel change across all APs in the RF group). For example, an AP channel change event can only cause subsequent changes to first-hop APs which are direct RF neighbors of the original AP modified. RRM is preferred over static channel and power assignments becuase most RF environments are dynamic and change over time. Cisco recommends that customers who had issues on older code versions re-evaluate the use of RRM in their environments with these enhancements.

RRM First-Hop Neighbors (purple) Are Allowed
To Change Channels, But Not 2nd-Hop Neighbors (blue)

Also, most RF designs using RRM should be designed to allow APs to operate at medium power levels (values 3-5) so that RRM can adjust power levels up or down as necessary. If the network is designed with minimal overlap and APs operate at maximum power level 1 all the time, then RRM can adjust power higher to compensate for coverage holes or AP failures.

BandSelect Recommendations In-Flux - The historical official recommendation from Cisco documentation, TAC, TMEs and other support personnel has been to disable BandSelect on voice WLANs to prevent roaming delays. Since BandSelect delays probe responses on the 2.4GHz radio, it can cause roaming delays that may impact performance of an active voice call. However, we heard from a few sources during multiple presentations that voice engineers within Cisco may have validated minimal impact to voice calls and recommending customers to turn it on the voice WLANs. No official change has been made to formal recommendations at this point, but may be an interesting topic to watch for changes in the future.

Cisco Stadium Wi-Fi - The new 3500p access point and 25137NP (36 spot-beam dual-polarization antenna) provide focused coverage for stadium seating sections. This solution also incorporates changes to the RRM algorithm and Wi-Fi Clear-Channel Assessment (CCA) specific to supporting a high-density environment. Read more about it here.

Cisco Narrow Beamwidth Antenna Focuses on
Individual Stadium Seating Sections


Layer 3 Roaming Enhancement - New in code version 7.0.116.0 is support for layer 3 client roaming when clients have static IP addresses configured.

Redundant Controller Licensing - Cisco WNBU (Wireless Networking Business Unit) has heard customer requests for backup controller licensing instead of having to purchase redundant units with full licensing for the intended AP capacity required. However, this change has not yet been committed to by WNBU. If you are a Cisco wireless customer and deploy N+1 or N+N redundancy, you should contact your Cisco account team to formally request s this change and throw added pressure on the pile!

Multiple LAG Groups on WLCs - Cisco WNBU is also considering adding support for multiple link aggregation (LAG) groups on the controllers. This would allow more flexible deployment in scenarios where controllers need to connect to separate physical networks, most common in DMZ anchor controller deployments I would imagine. For instance one LAG group connects to physical switches that lead into the core and another LAG group leads to a different set of physical switches that lead to the Internet. Currently, the only way to do this is to not use LAG at all and use a single physical interface for each side of the connection. This limits throughput to 1Gbps maximum. Multiple LAG support is not yet committed to by WNBU, so once again, call your account team to formally request support if it's important to you as a customer.

Rumor Apple will Support Fast Roaming in iOS 5 - There was also a very interesting rumor that was brought up in Wednesday's "Design and Deployment of Enterprise WLANs" that Apple may support 802.11r Fast BSS Transition (fast roaming) in it's upcoming release of iOS5. If this turns out to be true it will be a major improvement for support of Apple mobile devices including the iPhone, iPod Touch, and iPad in an enterprise environment. In a corporate setting these devices are much more likely to be leveraged as a converged devices supporting voice and video integration with corporate PBXs and video collaboration systems which require fast roaming for uninterrupted sessions.

Support for 802.11r should also officially come in Cisco WLC code version 7.2, although hooks have been in the WLC since the first 7.0 train release of 7.0.98.0.

Cheers,
Andrew

4 comments:

  1. This is great. I wasn't aware about that thanks. :)

    .net Code Security

    ReplyDelete
  2. Thank you for the info.

    I have a soon-to-deliver guest solution, and info on current roadmap should be useful to plan any alternative configuration.

    http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCsy32145


    any hint?

    Thank you in advance.

    Ivan

    ReplyDelete
  3. Hi Ivan,
    That is an interesting bug ID and/or feature request. I think this could be very useful if implemented by Cisco. I don't have any details on the bug or a potential roadmap for it being fixed since I do not work at Cisco.

    Andrew

    ReplyDelete
  4. Its amazing to know about cisco wifi stadium.
    Thanks


    Mcclane

    ReplyDelete