WLAN/SSID Security Migration into 6GHz Networks

With the introduction of Wi-Fi 6E/6GHz, there is a huge increase in available RF space, multiplying the overall total capacity of any wireless network, and at the same time, removing sources of interference and noise. This increase in performance and quality of the wireless connections will be really exciting and bring multiple opportunities, but this will come with the price of new and better security requirements for our WLAN/SSID configuration migration.

The new standard did not leave security out of the picture and any new device supporting 6GHz, will be required to “only” support the following security standards while in the new band:

◉ WPA3: this enforces mandatory Protected Management Frames (PMF/802.11w)

◉ Opportunistic Key Encryption (OWE). This replaces the concept of “Open SSID”, and allows to have encryption across devices, without any authentication

◉ Simultaneous Authentication of Equals (SAE). This takes the role of PSK (also called “personal”) authentication methods but makes it resistant to offline password attacks, with improved cryptographic algorithms

There are as well provisions for more advanced encryption methods (WPA3 Enterprise-192), and several mandatory things that must “not be supported“, for example:  PMF disabled/optional, TKIP, WEP, etc.

What does this mean for 6GHz deployments?

Well… in the rare case of a greenfield 6GHz deployment, it would be just “awesome, we get new improved security standards by default”…

The problem is that almost deployments will not be greenfield.  You will have to support the coexistence of all current networks and devices with the new standard and migrate existing networks to include the new 6GHz access points and clients.

What is more: with few honorable exceptions, most of the current WLAN/SSIDs configured out there for 2.4 and 5, will “not” work over 6GHz radios, as they do not meet the new security requirements.

This means that your SSID supporting WPA2 Enterprise (802.1x), can’t be broadcasted directly in 6GHz… same for any existing Webauth or WPA2-PSK SSIDs. All of them will need to be changed to conform to the new standard. In order to ensure things can be done properly, this will need planning, and quite possibly, careful testing.

Changes also mean concerns about backward compatibility, and any older devices may not like or support the new security settings, so this is not just a matter of flipping a configuration switch and hoping it works.

The good thing is that there are different options on how to handle brownfield scenarios, with proper and natural coexistence of the new APs and clients supporting WPA3 and 6GHz, with older devices still stuck supporting WPA2 or older standards. Each one has its benefits and implementation costs, so it is important to plan properly.

Figure 1. Radio Policy and 6GHz support

Transition mode

Some people may come back with “But transition mode is available, we should be able to set this WLAN with WPA2/WPA3 transition and get it done”, unfortunately,  things are not so simple. This mode was created to introduce WPA3 into legacy bands, not to make it easy for 6GHz adoption.

WPA3 describes transition mode as a kind of hybrid WPA2/WPA3 scenario, with PMF set to optional, and the group key using legacy crypto, but this is not allowed in 6GHz, so we can’t just flip the existing WLAN from WPA2 to transition mode and get it done…it simply can’t be supported in the new band.

Transition mode is an excellent way to handle a migration into a more secure standard in the legacy band. Older devices can coexist on the same SSID with new devices supporting WPA3/PMF, allowing a smoother migration, but the price to pay is compatibility. Multiple clients may behave erratically, or simply, fail to connect to a transition mode SSID, even if what they support is still allowed, plus this alone can’t solve the 6GHz  security mandatory requirements.

One word of caution: There is a related feature called “Transition Disable”, which can be set in the WLAN Security tab, in the WPA Parameters area.

Figure 2. Transition Disable location

This setting tells the client, that once it has connected successfully to WPA3, it should migrate its SSID profile to support “only” WPA3, and not connect back to WPA2 if that is the only option available. On one side, this is good for security, as it will migrate all client devices to WPA3 only, as they join the transition mode WLAN, but if the network is composed of multiple physical locations, for example, some are set to WPA2, others to WPA3/WPA2 transition mode, this will cause the migrated clients to fail when moved to a location with WPA2 only.

This is a possible scenario for some large networks, with the same SSID covering different controllers/AP setups and with configurations not matching  100%.  The largest example would be Eduroam, which shares the same SSID name worldwide. Setting this could have serious issues for clients  moving across different network providers, so please use this with care, and only if you can ensure the same security setting is set properly across all network locations

So, what options do we have?

Option 1: Everybody Moves

This is the most radical solution. Here we move all SSIDs to WPA3, SAE, or OWE, with a single SSID across all bands. This means that all legacy security support will be removed across all SSIDs.

This is only feasible for the Greenfield scenario, or when we have absolute control of all clients’ device versions and configurations. It is highly probable that customers will never go this route.

Client support

◉ Apple IOS: on 15.1, it does support WPA3/PMF, and SAE, but it does not support OWE. SAE support is not compatible with 6GHz requirements

◉ Android: Supports WPA3/PMF/SAE since version 10

◉ Windows: supported in 11, but should work on version 10-2004

Cons

◉ There is a large list of compatibility issues regarding some of the requirements, and implementing this option will lead to compatibility issues as soon as any older device tries to connect

◉ Migrating the SSID profile on clients may be problematic, depending on operating systems. Several devices will use right away the higher security offerings, others will need to be adjusted

Pros

◉ No need for additional SSIDs

◉ Removes any older low-security SSIDs

Option 2: Tailored SSIDs

In this scenario,  the idea is to create new SSIDs, specifically focused on functionality, with support on each band as needed. New SSIDs would be created for 6GHz support, optionally broadcasted in other bands.

This maximizes backward compatibility, as it leaves anything existing  “untouched”.

For example, a company may have an existing SSID design as:

◉ Legacy SSID: mycompany, broadcasted in 5 GHz supporting WPA2 Enterprise

◉ Guest SSID: mycompanyGuest, supporting webauth in 2.4 and 5 GHz

◉ IoT: mycompanyIOT, with WPA2-PSK, for restricted sensor/telemetry devices in 2.4 GHz

What we would add:

◉ Wi-Fi 6 specific SSID: mycompanyNG, broadcasted on 5 and 6GHz, using WPA3 with 802.1x authentication and PMF

Cons

◉ A new SSID will need to be created and broadcasted

◉ Additional profile configuration across devices. Depending on client management being available, this can be a daunting task

◉ SSID names are a sensitive subject for customers. Selecting a new name may not be simple in some instances

Pros

◉ No impact on anything already existing

◉ You can have a gradual migration of devices supporting the new security standards (WPA3) to the new SSID, without having to do a risky forklift in the client profile configuration

◉ Fast roaming supported between bands for the same WLAN

Option 3:  Same SSID, two WLAN profiles, using transition mode

Keeping the same SSID across bands, touches your existing WLAN profile changing it to WPA3 transition mode and restricting it to 2.4 and 5GHz. Plus adds a new profile, just for 6GHz, with the required security settings.

Following on our previous example:

◉ Legacy SSID: mycompany, WLAN profile mycompany, broadcasted in 5 GHz. Modified now to supporting WPA2 Enterprise and WPA3 in transition mode

◉ Guest SSID: mycompanyGuest, supporting webauth in 2.4 GHz

◉ IoT: mycompanyIOT, with WPA2-PSK, for restricted sensor/telemetry devices in 2.4 GHz

What we would add:

◉ Wi-Fi 6 specific WLAN profile: same mycompany, SSID, with different profile name, mycompanyNG  broadcasted on 6GHz, using WPA3 with 802.1x authentication and PMF

Cons

◉ Several client vendors have issues handling WPA3 transition mode properly

◉ Clients may not like the same SSID with different security settings across bands.

◉ Roaming is not supported across WLANs. A client authenticated in 5 GHz, will have to do full authentication when moving into 6

Pros

◉ No new SSIDs on the client side to be managed

◉ Devices supporting WPA3 will connect in legacy bands with the higher security standard. This will help with security migration

◉ As we have the same SSID name across bands, clients will be able to fallback from 6 to 2.4/5, in case of any coverage problem

Option 4:  Same SSID, two WLAN profiles, no transition

This is basically a small variation of option 3.  The existing profile is left untouched, and we add a 6GHz specific WLAN profile:

◉ Legacy SSID: mycompany, WLAN profile mycompany, broadcasted in 5 GHz. WPA2-Enterprise

◉ Guest SSID: mycompanyGuest, supporting webauth in 2.4 GHz

◉ IoT: mycompanyIOT, with WPA2-PSK, for restricted sensor/telemetry devices in 2.4 GHz

What we would add:

◉ Wi-Fi 6 specific WLAN profile: same mycompany, SSID, with different profile name, mycompanyNG  broadcasted on 6GHz, using WPA3 with 802.1x authentication and PMF

Cons

◉ Clients may not like the same SSID with different security settings across bands. This is yet to be confirmed, so far, no issues reported in testing

◉ Roaming across WLANs is not supported. A client authenticated in 5 GHz, will have to do full authentication when moving into 6

◉ Legacy bands will be stuck on lower security protocols

Pros

◉ No new SSIDs to be managed on the client side

◉ As we have the same SSID name across bands, clients will be able to fallback from 6 to 2.4/5, in case of any coverage problem

◉ Avoids any client interoperability issues with transition mode

Too many options, but which is the best?

For most customers, option 4 (new WLAN profile, same name, new security), is what will be implemented most of the time, as it allows deployments, reducing most risks.

For customers that want better security, option 2 (specific SSID), or option 3 (change to transition mode, add new profile for 6), will be the best suited.

And for sure, don’t move WPA2 networks to WPA2/WPA3 transition mode, without validating with your existing clients, especially if there are any legacy or custom devices present.

Source: cisco.com

Continue reading

Migrating to 6GHz

With more than 18 billion devices in use and 4.2 billion more to be shipping in 2022, the sheer size of existing Wi-Fi deployments worldwide is just mind-boggling. In view of the new Wi-Fi 6E and 6GHz adoption push, it is critical to evaluate what are the best ways to do a migration from existing Cisco on-prem legacy networks into the new world of 6GHz deployments.

For Cisco Enterprise customers, there are several aspects that need to be evaluated for any successful migration planning:

• Existing controller type:
• is it AireOS?
• Model? (Basically, can it  run 8.5 or 8.10?)
• is it IRCM capable (2504/wism2 can’t do mobility to 9800)
• Access point Inventory:
• Are there any 802.11n models still in use? (per example, 2600, 3600, 1520, 1600, etc)
• Are there any Wave1 APs? (last generation of IOS, per example 1700, 2700, 3700)
• Mesh deployments?
• PoE support:
• What is the maximum supported power standard? (802.3bt, 802.3at, etc)
• Any power budged constraints per port?
• Or APs are powered by power injectors?
• Current 5GHz TX power
• Is my network running on average at power level 3-4?
• or it is around 1-2?

6GHz adoption is only supported in the Catalyst 9800 IOS-XE controllers, running 17.7 or higher. This imposes some additional considerations either on controller type migration, or about legacy access points that may need to either be migrated, or supported through Inter Release Controller Mobility (IRCM) solutions

Legacy Access Points

Figure 1. Legacy APs

Over the years, it has always been possible to do co-existence of previous generations of access points with the newly introduced models, ensuring both smooth network upgrades and capacity expansion. Adding new APs is normally not an issue until we hit the scenario of inter-generation gaps.

If a network that for any reason is still running devices 2 generations away (for example, a 2602 AP), and now needs to include new 802.11ax models (for example 9130) or jump to the  9136/9166/9164  for 6GHz support, this will need more complex migration paths.

When there are multiple generation gaps, if the legacy controllers can support IRCM to the IOS-XE 9800,  it is perfectly possible to design a migration plan, without the need to do a “forklift” installation.  This will ensure very little pain to users, and keep the network running until everything is migrated to the new hardware and standards

In the following table, we can see a summary of software support ranges and migration options for most access points models from 11n generation models:

Model/Series	Last AireOS Support	IOS-XE support	IOS-XE AP equivalent	Migration Notes
700/700W Series	8.10	Not supported	9105	Migration through IRCM
1040	8.3	Not supported	9115	AP needs to be replaced
1260	8.3	Not supported	9115	AP needs to be replaced
1600	8.3	Not supported	9115	Either 8.5 IRCM, or Hardware replaced
1700	8.10	17.3	9115	Migration through IRCM
2700	8.10	17.3	9120	Migration through IRCM
3700	8.10	17.3	9130	Migration through IRCM
1810/1810W	8.10	Up to 17.3	9105	Hardware replaced or IRCM between IOS-XE versions
1830/1840/1850	8.10	Supported	9105	Directly supported
AP802/AP802H	8.5	Not Supported	ISR10xx	Migration through IRCM
2600	8.5	Not Supported	1920	Migration through IRCM
2800/3800/4800	8.10	Supported		Directly supported
1540	8.10	Supported		Directly supported
1550	8.5	Not supported		Migration through IRCM
1560	8.10	Supported		Directly supported
1570	8.10	Up to 17.3		Migration through IRCM

For a complete list, you can check the Cisco Wireless Solutions Software Compatibility Matrix, alternatively, you can run the Wireless Config Analyzer Express, to check your migration readiness

Figure 2. AP Migration Decision Flow

Legacy Controllers

Figure 3. Legacy Controller

Depending on the existing controller type, the migration may take different paths. Some scenarios will be simple, allowing a smooth transition. Others may need additional steps to successfully migrate into a Wi-Fi 6E network

What to expect:

◉ “Generation 1” controllers: 5508, 8510. They can support up to 8.5 AireOS version, which will allow mobility scenarios between them and new IOS-XE 9800 controllers (Inter-release Controller Mobility, IRCM support).  Also, they will support  both IOS and AP-COS access points, from 1700 to 3800 models (Wave1, Wave2 802.11ac )

◉ “Generation 2” controllers: 5520, 8540, 3504 . All of these can support up to 8.10 AireOS, also allowing IRCM scenarios with 9800. AP support will additionally include 802.11ax models, like the new Catalyst 9105, 9120, and 9130. etc.

◉ “Generation 1” controllers without IRCM: 2504, WiSM2, vWLC, 7510. No mobility is possible between them and IOS-XE, so additional steps with different migration scenarios are needed

Figure 4. Controller Migration Decision Flow

Migration Scenarios

In general, we should try to migrate “per RF blocks”, defining it as a roaming area or domain where clients can move normally between access points, before hitting idle timeout. Basically, move these RF blocks completely, into the new APs, and IOS-XE controllers. For example, either move a building or a complete floor into the new hardware and software.  We should avoid “salt & pepper” deployments, mixing APs on different controllers at the same time. Not because it is not supported, but because mobility will be more complex, and it may lead to issues sooner or later (just a problem prevention action)

For scenarios where it is impossible to break the RF environment into differentiated blocks (for example a very large building like an airport, or a fully open space office), we will have to either set up artificial boundaries based on roaming frequency and usage or do a forklift upgrade

Figure 5. Example of RF area/building migration

What happens if the AP model is not supported in any IRCM version?

This could be the scenario of a legacy controller, still working in 8.3, with some AP models that are not supported beyond that version. For example, the scenario of 20 APs of 2700 Series, and 10 APs of 1042 Series.

The 1040s are not supported in 8.5. In this case, the preferred option is to prioritize the replacement of those APs first, moving the impacted area into 9800 as the first step. Sometimes, customers have mixed models across a given building. For example, the mix of 2700 and 2600. In those scenarios, the best option is to consolidate models per supported version, moving all APs of a given type together, so they are contained in a specific RF space  in order to facilitate migration in blocks

Scenario 1: Legacy Controller supports IRCM

This will be the most common scenario, where we have either 8.5  (5508/8510) or 8.10 (5520/3504/8540) AireOS controller.  The migration picture will start with the creation of  IRCM setup between AireOS and 9800 controllers, then either replace APs in RF areas connecting them to the new controller, allowing mobility to act when a client needs to roam between legacy and new RF areas.

This method allows the smooth coexistence of both controllers, with RF areas migrated as needed, without any overnight switchover.

Things to keep in mind:

◉ If the controller is limited to 8.5 (5508, 8510), we will need a special IRCM version (8.5.182.104), to connect them to IOS-XE

◉ In general, it is best to split the RF network into different areas, configuring different RF group names between the legacy and IOS-XE controllers. This way each group can do the best calculations that their respective version allows. We should make sure that “Avoid Foreign AP Interference” is enabled on RRM/DCA configuration (it is by default)

◉ Always configure the primary/secondary controller name in access points. The new controllers will reject unsupported APs, but if any AP could work in both controller types, this will avoid APs joining the wrong one, or flip-flopping between them, until the migration is ready to proceed

Scenario 2: Legacy Controller not supporting IRCM

If the legacy network is running on a controller model WiSM2, 2504, 7510, vWLC, it is not possible to establish an IRCM connection between the old controller to the new 9800 handling the 6E APs. This limits significantly the options that are available, and it forces a more aggressive migration process

Migration alternatives:

◉ Keep the two networks separated, and migrate physical RF areas as new APs are added, replacing the old ones. No roaming is possible, and it is very important to keep client VLANs different between controllers, to avoid ARP proxy issues between both controllers. During this process, we must take care on preventing roaming events as client identity, address, etc, will be lost on the change between controller types.  For example, the ideal scenario is to move a complete building from one controller to the new one, doing a forklift AP replacement overnight.

◉ Avoid migrations “per floor”, as in most building types, it is normal to see clients roaming between APs on different floors

◉ Temporarily, replace the legacy controller with one that supports IRCM

Scenario 3: AP is supported up to 17.3 but not in later versions

This will happen when “Wave1” APs are still present, for example, 1700/2700/3700 AP models. For this type of migration, it is possible to move all APs into IOS-XE, with the 17.3 release, then add a secondary wlc to host the new Wi-Fi 6E APs, using 17.9, and establish an IRCM link between both controllers.

On this option, it is possible to do a graceful AP replacement from Wave1, into Wi-Fi 6E models, always trying to do the technology migration, per physical roaming RF area as described (per building, floor, etc). Once all APs are migrated, the 17.3 controllers can be decommissioned

In some instances, the customer may deploy a 9800-CL in 17.3 as a temporary controller to host the legacy APs

6GHz RF Coverage vs 5GHz. AP replacement scenarios

One common discussion point is: How different is going to be the cell coverage, in 6GHz, when compared to a 5GHz AP?

People will want to take a 5GHz AP and do a 1:1 replacement with a 6GHz supported AP, this may seem reasonable, but there are some aspects to consider:

◉ As WiFi-6E uses a higher frequency, the propagation characteristics are different, the signal drops slightly faster in 6 than in 5GHz. The difference should be around 2 dBm on measurements over the same distance. Material absorption will be different as well.

◉ 6GHz has different regulatory power constraints than 5GHz. Currently, most deployments will be using Low Power APs (for simplicity sake’s, let’s say 24dBm in FCC, 23 dBm in ETSI). This means that depending on the current network AP radio’s power levels,  using 6GHz may result in a slightly lower power output

Rule of thumb:

◉ If your power level average is around 3-4, it is possible to do a 1:1 AP replacement, and have a similar coverage level in 5 and 6 GHz

◉ If the power level is in 1-2, then you may need around 10 to 20% additional access points

The easiest way to know the average power level per site is to use WCAE tool and check the “Channel Stats 5GHz” tab. This will present a summary per channel, either at controller, or site tag level, of the average power levels (among other information).  For example, this is a network where migration to 6GHz may need additional access points:

Figure 6. Example of site with low 5GHz coverage

Versus this other one, where the deployment is running on low power, so fitting without issues into 6GHz requirements:

Figure 7. Example of site with good 5GHz coverage

If you use the latest version (0.9.11) of WCAE, you can also get a “6GHz predictive” view of how the power distribution, Nearby relationships, and RSSI for clients would look, if you replaced your current APs with 6GHz capable hardware. The tool will match ETSI or FCC regulatory requirements, adapting powers and differences as needed. This is useful to get a taste of how the network would look, doing a direct migration, without adding any APs.

Figure 8. 6GHz Predictive RRM modeling

For complex or demanding deployment scenarios, the recommendation will always be: do a site survey

Source: cisco.com

Continue reading