Migreren naar 6 GHz en Wi-Fi 7 met Cisco Wireless

Inleiding

Dit document beschrijft ontwerp- en configuratierichtlijnen om de prestaties van Wi-Fi 7 te optimaliseren en het 6 GHz-spectrum volledig te benutten.

CX-ontwerphandleiding

CX Design Guides zijn geschreven door specialisten van Cisco CX in samenwerking met ingenieurs van andere afdelingen en peer-reviewed door experts binnen Cisco; de gidsen zijn gebaseerd op de toonaangevende praktijken van Cisco en de kennis en ervaring die is opgedaan met talloze klantimplementaties gedurende vele jaren. Netwerken die zijn ontworpen en geconfigureerd in overeenstemming met de aanbevelingen in dit document helpen veelvoorkomende valkuilen te voorkomen en de werking van het netwerk te verbeteren.

Waarom 6 GHz en Wi-Fi 7

De 6 GHz-band werd in 2020 beschikbaar voor WLAN-bewerkingen en was vereist voor Wi-Fi 6E-certificering. Terwijl Wi-Fi 6 werkt in de 2,4 GHz- en 5 GHz-banden, maakt Wi-Fi 6E gebruik van dezelfde IEEE 802.11ax-standaard, maar breidt de functionaliteit uit naar de 6 GHz-band, mits aan specifieke vereisten wordt voldaan.
De nieuwe Wi-Fi 7-certificering is gebaseerd op de IEEE 802.11be-standaard en ondersteunt bewerkingen in de 2,4 GHz-, 5 GHz- en 6 GHz-banden. Wi-Fi 7 introduceert ook nieuwe functies en verbeteringen in vergelijking met eerdere certificeringen.

Ondersteuning van de 6 GHz-band en/of Wi-Fi 7 wordt geleverd met specifieke vereisten, waarvoor vaak nieuwe configuraties en RF-ontwerpen nodig zijn, vooral in vergelijking met de gevestigde praktijken voor de 2,4 GHz- en 5 GHz-banden met Wi-Fi 6.

Net zoals het gebruik van verouderde WEP-beveiliging voorkomt dat 802.11-standaarden worden overgenomen die verder gaan dan 802.11a/b/g, leggen nieuwere standaarden nog strengere beveiligingsvereisten op om de implementatie van veiligere netwerken aan te moedigen.

Omgekeerd biedt de introductie van de 6 GHz-band toegang tot schonere frequenties, verbeterde prestaties en ondersteuning voor nieuwe gebruikssituaties. Het maakt ook een meer naadloze implementatie van bestaande toepassingen mogelijk, zoals spraak- en videoconferenties.

Basisvereisten voor 6 GHz-bewerkingen en Wi-Fi 7

Dit zijn de beveiligingseisen die zijn vastgelegd in de certificeringen voor 6 GHz- en Wi-Fi 7-bewerkingen.

Vereisten voor de 6 GHz-band

De 6 GHz-band staat alleen WPA3 of Enhanced Open WLAN's toe, wat een van deze beveiligingsopties betekent:

• WPA3-Enterprise met 802.1X-verificatie
• WPA3 Simultaneous Authentication of Equals (SAE) (ook bekend als WPA3-Personal) met wachtwoordgroep. SAE-FT (SAE met Fast Transition) is een andere mogelijke AKM en wordt eigenlijk aanbevolen voor gebruik omdat de SAE-handshake niet triviaal is en FT die langere uitwisseling overslaat.
• Verbeterde open verbinding met opportunistische draadloze codering (OWE)

Hoewel volgens de WPA3 v3.4-specificaties (sectie 11.2) de Enhanced Open-overgangsmodus niet wordt ondersteund met 6 GHz, wordt dat door veel leveranciers (waaronder Cisco tot IOS® XE 17.18) nog niet afgedwongen. Daarom is het technisch mogelijk om bijvoorbeeld een Open SSID op 5 GHz te configureren, een bijbehorende Enhanced Open SSID op 5 en 6 GHz, beide met Transition Mode ingeschakeld, en dit alles zonder te voldoen aan de standaards specificaties. In een dergelijk scenario moet echter worden verwacht dat we eerder een Enhanced Open SSID configureren zonder overgangsmodus en alleen beschikbaar op 6 GHz (clients die 6 GHz ondersteunen, ondersteunen meestal ook Enhanced Open), terwijl onze reguliere Open SSID op 5 GHz blijft, ook zonder overgangsmodus.

Er zijn geen nieuwe specifieke coderingen of algoritmevereisten voor WPA3-Enterprise, met uitzondering van 802.11w/Protected Management Frame (PMF)-handhaving. Veel leveranciers, waaronder Cisco, beschouwen 802.1X-SHA256 of "FT + 802.1X" (dat eigenlijk 802.1X is met SHA256 en Fast Transition bovenaan) alleen als WPA3-compatibel en gewoon 802.1X (dat SHA1 gebruikt) wordt beschouwd als onderdeel van WPA2, daarom niet geschikt / ondersteund voor 6 GHz.

Vereisten voor Wi-Fi 7

Met de Wi-Fi 7-certificering van de 802.11be-standaard heeft de Wi-Fi Alliance de beveiligingsvereisten verhoogd. Sommige van hen maken het gebruik van de 802.11be-gegevenssnelheden en protocolverbeteringen mogelijk, terwijl andere specifiek zijn voor het ondersteunen van Multi-Link Operations (MLO), waardoor compatibele apparaten (clients en / of AP's) meerdere frequentiebanden kunnen gebruiken met behoud van dezelfde associatie.

Over het algemeen vereist Wi-Fi 7 een van deze beveiligingstypen:

• WPA3-Enterprise met AES(CCMP128) en 802.1X-SHA256 of FT + 802.1X (die nog steeds SHA256 gebruikt, zelfs als het niet expliciet is in de naamgeving). Nieuwere WPA3-specificaties verplaatsen de vereiste naar het GCMP256-algoritme. Dit creëert een aantal verschillen in gedrag tussen klanten waarbij sommigen proberen Wi-Fi 7 Enterprise met AES128 te doen, terwijl anderen verwachten GCMP256 al te moeten doen.
• WPA3-Personal met GCMP256 en SAE-EXT-KEY en/of FT + SAE-EXT-KEY (AKM 24 of 25). Wi-Fi 6E vereist WPA3 SAE en/of FT + SAE met reguliere AES (CCMP128) en geen extra uitgebreide sleutelgebruik; dit betekent dat een nieuw cijfer specifiek is geïntroduceerd voor Wi-Fi 7.
• Verbeterde Open / OWE met GCMP256. Hoewel AES(CCMP128) nog steeds op dezelfde SSID kan worden geconfigureerd, ondersteunen clients met AES 128 Wi-Fi 7 niet. Vóór Wi-Fi 7 gebruikten de meeste clients die Enhanced Open ondersteunden alleen AES 128, dus dit is een nieuwe, sterkere vereiste. Voor 6 GHz ondersteuning is geen overgangsmodus toegestaan.

Ongeacht het geselecteerde beveiligingstype zijn Protected Management Frames (PMF) en Beacon Protection vereist om Wi-Fi 7 op het WLAN te ondersteunen.

Omdat Wi-Fi 7 op het moment van schrijven nog steeds een recente certificering is, met een zo vroeg mogelijke release, hebben veel leveranciers al deze beveiligingsvereisten niet vanaf het begin afgedwongen.

Meer recentelijk heeft Cisco de configuratieopties geleidelijk afgedwongen om te voldoen aan de Wi-Fi 7-certificering. Hier zijn de versie-specifieke gedragingen:

IOS XE 17.15.3 en hoger 17.15.x-versies

In deze tak worden alle WLAN's uitgezonden als Wi-Fi 7 SSID's, op voorwaarde dat Wi-Fi 7 wereldwijd is ingeschakeld en ongeacht de beveiligingsinstellingen.

Een client kan Wi-Fi 7 koppelen en Wi-Fi 7-gegevenssnelheden behalen, ongeacht de beveiligingsmethode die wordt gebruikt, op voorwaarde dat deze nog steeds wordt ondersteund door het WLAN. De klant kan echter alleen associëren als MLO-geschikt (op een of meer banden) als deze voldoet aan de strikte vereisten voor Wi-Fi 7-beveiliging, of anders wordt deze afgewezen.

Dit kan mogelijk problemen veroorzaken wanneer sommige vroege Wi-Fi 7-clients die geen veiligere coderingen kunnen ondersteunen, zoals GCMP256, proberen te koppelen als Wi-Fi 7 MLO geschikt voor een WLAN, waarvan de beveiligingsinstellingen niet overeenkomen met de Wi-Fi 7-vereisten. In een dergelijke situatie wordt de client afgewezen vanwege de ongeldige beveiligingsinstellingen (die nog steeds mogen worden geconfigureerd onder het WLAN).

IOS XE 17.18.1 en hoger

Beacon Protection wordt automatisch ingeschakeld als uw WLAN voldoet aan Wi-Fi7, ongeacht of u het selectievakje inschakelt of niet.

17.18.1 en hoger Cisco IOS XE adverteert alleen een WLAN als geschikt voor Wi-Fi 7 en MLO als de juiste beveiligingsvereisten zijn ingeschakeld voor de WLAN-instellingen. Een WLAN dat alleen reclame maakt voor SAE en niet voor SAE-EXT wordt bijvoorbeeld uitgezonden als MLO-incapable.

De 17.18-tak introduceert de functie van een 802.11be-profiel, dat moet worden gekoppeld aan een WLAN-profiel, voor het regelen van de activering van Wi-Fi 7 per SSID en zelfs per radio.

Er wordt een nieuw speciaal menu toegevoegd onder Configuratie > Tags en profielen > 802.11be, waar standaard al een vooraf geconfigureerd 802.11be-profiel bestaat, onder de naam "default-dot11be-profile".

De vier hoofdinstellingen voor het in- of uitschakelen van Wi-Fi 7 bevinden zich onder de sectie "MLO Group". Door ze alle vier uit te schakelen, schakelen we Wi-Fi 7 uit voor alle banden van het WLAN-profiel, waaraan we het 802.11be-profiel koppelen. Door slechts enkele of alle van hen in te schakelen, schakelen we Wi-Fi 7 in op de corresponderende banden/radio's van het WLAN-profiel, waaraan we het 802.11be-profiel koppelen.
Het "default-dot11be-profile" maakt MLO en Wi-Fi 7 op alle radio's mogelijk en is standaard gekoppeld aan elk WLAN-profiel.
Door een nieuw 802.11be-profiel te maken met alle instellingen van de "MLO Group" uitgeschakeld en aan bepaalde specifieke WLAN-profielen te koppelen, kunnen we bijvoorbeeld Wi-Fi 7 selectief uitschakelen voor sommige van onze SSID's.

Op het tabblad "Geavanceerde instellingen" van elk WLAN-profiel is een corresponderend 802.11be-profiel bijgevoegd:

Zoals we in het voorbeeld kunnen zien, is het "default-dot11be-profile" standaard gekoppeld aan elk WLAN-profiel.

Opmerking: als Wi-Fi 7 niet globaal is ingeschakeld op de controller, zoals later wordt uitgelegd, is Wi-Fi 7 uitgeschakeld voor alle WLAN-profielen en worden 802.11be-profielen niet toegepast.

17.18.2 introduceert een kleine wizard op de WLAN-bewerkingspagina waarmee u kunt visualiseren of uw WLAN voldoet aan Wi-Fi7 of niet en u kunt zien wat er ontbreekt:

17.18.2 Beveiligingswizard

Overwegingen met betrekking tot radioontwerp voor 6 GHz-dekking

Zonder dat het de bedoeling is om een volledige prescriptieve gids voor enquêtes ter plaatse te worden, beschrijft dit gedeelte kort enkele basisoverwegingen bij het ontwerpen voor 6 GHz-dekking, vooral als er een reeds bestaande installatie voor 2,4/5 GHz is die we willen migreren naar Wi-Fi 6E of 7.
Zoals voor elke nieuwe Wi-Fi-implementatie die we gewend waren op 2,4 en / of 5 GHz, moet een nieuw draadloos project op 6 GHz ook een bijbehorende speciale 6 GHz-site-enquête bevatten.

Wanneer pre-Wi-Fi 6E/7 AP's al zijn gepositioneerd voor specifieke 5 GHz-dekking en -behoeften, kunnen we in sommige gevallen verwachten dat we ze kunnen vervangen door Wi-Fi 6E/7-compatibele AP's en toch een goede dekking op 6 GHz kunnen krijgen. Om deze theorie te laten werken, moeten onze bestaande AP's al een juiste 5 GHz-dekking bieden voor de beoogde behoeften (alleen gegevens, spraak, specifieke toepassingen, enzovoort) terwijl ze al minstens 3-4 zendvermogensniveaus onder hun maximale limiet hebben. AP's hebben meestal 7 tot 8 energieniveaus en elk energieniveau verdeelt het zendvermogen met de helft. Dit betekent dat een comfortabele plek is wanneer AP's het medium van hun toegestane zendvermogensbereik gebruiken.

Volgens berekeningen van het verlies van vrije ruimte worden 6 GHz-signalen verzwakt door 2 dB meer dan 5 GHz-signalen. Bovendien kunnen 6 GHz-signalen ook meer worden beïnvloed door obstakels dan hun 5 GHz-equivalenten.

Wanneer een Cisco-toegangspunt het zendvermogen met één niveau verhoogt/verlaagt, gebeurt dit met een "sprong" van 3 dB. Een toegangspunt dat van een vermogensniveau van 4 gaat, met een zendvermogen van 11 dBm bijvoorbeeld, tot een vermogensniveau van 3, verhoogt het zendvermogen tot 14 dBm (11 dBm voor vermogensniveau 4 en 14 dBm voor vermogensniveau 3 zijn slechts een algemeen voorbeeld, omdat verschillende modellen/generaties toegangspunten enigszins verschillende zendvermogenswaarden in dBm kunnen hebben voor hetzelfde vermogensniveau).

Als een pre-Wi-Fi 6E/7 AP al een goede dekking biedt op 5 GHz op energieniveau 4, bijvoorbeeld, kan een nieuwer Wi-Fi 6E/7 AP met vergelijkbare 5 GHz-radiopatronen dat voormalige AP vervangen zonder enige significante impact op het bestaande 5 GHz-netwerk.

Ook zou de 6 GHz-radio van de nieuwe Wi-Fi 6E / 7 AP een vergelijkbare 6 GHz-dekking kunnen bieden als de 5 GHz-radio door slechts één zendvermogensniveau (dus 3 dB) hoger te zijn.

Als 5 GHz al correct is afgedekt met de 5 GHz-radio van het toegangspunt bij 3-4 vermogensniveaus onder het maximum, kan de corresponderende 6 GHz-radio dus worden ingesteld op 2-3 vermogensniveaus onder het maximum voor vergelijkbare dekking. Deze veronderstelling werkt op voorwaarde dat de landenregelgeving, waarbij 5 GHz- en 6 GHz-dekkingen worden ingezet, toestaat dat 6 GHz-radio's en EIRP op hogere vermogens dan 5 GHz zijn (mogelijk ook rekening houdend met kanaalaggregaties).

Ook als de 6 GHz-radio al de juiste dekking biedt bij 2-3 vermogensniveaus lager dan het maximum, kan deze nog steeds uitzonderlijk een paar niveaus hoger gaan, bijvoorbeeld om te proberen rond tijdelijke onverwachte dekkingsgaten te werken (het falen van een naburige AP, onaangekondigde obstakels, nieuwe RF-behoeften enzovoort).

Roaminggedrag tussen pre-Wi-Fi 6E/7 en Wi-Fi 6E/7 AP's

Het gebruik van toegangspunten die verschillende standaarden en/of frequentiebanden in hetzelfde dekkingsgebied ondersteunen, is altijd niet aanbevolen, vooral niet als die verschillende generaties toegangspunten op een "zout-en-peper" manier worden geïnstalleerd (dat wil zeggen, gemengd in dezelfde zone).

Hoewel een draadloze controller bewerkingen (bijvoorbeeld dynamische kanaaltoewijzing, transmissievermogensregeling, PMK-cachedistributie, enzovoort) van een groep van verschillende AP-modellen kan verwerken, kunnen clients die tussen verschillende standaarden en zelfs verschillende frequentiebanden bewegen, dat niet altijd goed afhandelen en kunnen ze waarschijnlijk bijvoorbeeld roamingproblemen tegenkomen.

Bovendien ondersteunen Wi-Fi 6E/7 AP's vanwege de nieuwere standaarden GCMP256-cijfers voor WPA3. Hetzelfde kan echter niet altijd waar zijn voor sommige Wi-Fi 6-toegangspunten en eerdere modellen. Voor wachtwoordgroep/WPA3-Personal en Enhanced Open/OWE SSID's, waarvoor de configuratie van zowel AES(CCMP128)- als GCMP256-coderingen vereist is, ondersteunen bepaalde Wi-Fi 6-coderingen (zoals de 9105-, 9115- en 9120-reeks) GCMP256 niet en kunnen deze alleen AES(CCMP128)-coderingen bieden aan gekoppelde clients, waaronder Wi-Fi 6E/7-compatibele clients. Als deze Wi-Fi 6E/7-clients van/naar naburige Wi-Fi 6E/7 AP's met GCMP256 moesten zwerven, zouden ze een gloednieuwe associatie moeten doorlopen, omdat het opnieuw onderhandelen van cijfers tussen AES(CCMP128) en GCMP256 niet wordt ondersteund voor transparante roaming. Bovendien is het over het algemeen niet optimaal om toegangspunten te hebben die verschillende mogelijkheden in hetzelfde gebied bieden: deze implementatie laat klanten niet toe deze mogelijkheden betrouwbaar te gebruiken tijdens het verplaatsen en kan leiden tot kleverigheid of verbroken verbindingen.
Hoewel dit scenario een hoekscenario moet vertegenwoordigen, willen we er toch rekening mee houden dat roaming van Wi-Fi 6E/7-clients tussen 9105/9115/9120 AP's en 9130/9124/916x/917x AP's niet mogelijk is met GCMP256-coderingen die zijn geconfigureerd in het kader van het WLAN, omdat deze laatste reeks GCMP256 ondersteunt en de eerste niet.

Kanaalbreedtes van 40 MHz of meer op 6 GHz kunnen ook plakkerigheid veroorzaken voor 6 GHz-compatibele clients, die kunnen weigeren opnieuw te koppelen aan andere banden. Dit moet nog een reden zijn om AP's die geschikt zijn voor 6 GHz en AP's die niet geschikt zijn voor 6 GHz niet in hetzelfde roaminggebied te combineren.

Wi-Fi 7 wereldwijd mogelijk maken

Wi-Fi 7 wereldwijd mogelijk maken op IOS XE

Bij het installeren of upgraden naar een IOS XE-versie die Wi-Fi 7 ondersteunt, is standaard ondersteuning voor Wi-Fi 7 over het algemeen uitgeschakeld.
Om het te activeren, moeten we navigeren onder het configuratiemenu High Throughput van elke 2,4/5/6 GHz-band en het selectievakje aanvinken om 11be in te schakelen.

Een andere optie zou ook kunnen zijn om deze drie opdrachtregels via SSH / console uit te voeren, in de terminalconfiguratiemodus:

ap dot11 24ghz dot11be
ap dot11 5ghz dot11be
ap dot11 6ghz dot11be

Zoals vermeld in de waarschuwingsnotitie, resulteert het wijzigen van de status van 802.11be-ondersteuning bij het wijzigen van deze instellingen in een kort verlies van connectiviteit voor alle clients via radio's van Wi-Fi 7-toegangspunten. Als u MLO wilt doen, wat betekent dat clients verbinding maken met meerdere banden tegelijk, moet u 11be inschakelen op alle banden waarmee de client verbinding moet maken. Het is niet nodig om alle bands in te schakelen, maar wordt alleen aanbevolen voor prestaties.

Wi-Fi 7 wereldwijd mogelijk maken op Cisco Meraki Dashboard

Wanneer u Wi-Fi 7-compatibele toegangspunten (bijvoorbeeld CW9178I, CW9176I/D1) voor het eerst toevoegt aan een Cisco Meraki Dashboard-netwerk, wordt ondersteuning voor 802.11be-werking op het standaard RF-profiel weergegeven.
Als u het wilt activeren, moet u navigeren onder Draadloos > Radio-instellingen, klikt u op het tabblad RF-profiel en selecteert u het profiel dat aan het toegangspunt is toegewezen (standaard: 'Basisprofiel binnenshuis' voor toegangspunten binnenshuis).

Schakel in de sectie Algemeen 802.11be (on) in, zoals in deze schermafbeelding wordt weergegeven:

Als een of meer WLAN's zijn geconfigureerd met beveiligingsinstellingen die zwakker zijn dan de instellingen die zijn vereist in de Wi-Fi 7-specificatie, wordt op het Dashboard een banner weergegeven die gebruikers waarschuwt, zoals hieronder wordt weergegeven.

Terwijl het Dashboard het mogelijk maakt de configuratie op te slaan, wordt Wi-Fi 7 niet ingeschakeld op de gemarkeerde SSID's totdat de naleving van de Wi-Fi 7-vereisten is gewaarborgd.
Vanaf dit schrijven moeten alle WLAN's die in het netwerk zijn ingeschakeld voldoen aan de vereisten van de Wi-Fi 7-specificatie om te worden ingeschakeld op firmwareversie MR 31.1.x en hoger (dit gedrag verandert in een toekomstige versie van firmware MR 32.1.x).

Zodra de configuratie van de SSID voldoet aan de minimumcriteria voor Wi-Fi 7, verdwijnt de banner.

Zorg ervoor dat in hetzelfde RF-profiel de werking van 6 GHz op de toegangspunten is ingeschakeld.

Dit kan worden gedaan voor alle SSID's in bulk of per afzonderlijke SSID.

Merk op dat Band Steering alleen beschikbaar is tussen 2,4 en 5 GHz.

Voorbeeld van 6 GHz voor alle SSID's.

Voorbeeld van 6 GHz voor één SSID.

Use cases 

802.1X / WPA3-Enterprise-netwerken

Configuratie van WPA3-Enterprise op IOS XE 

WLAN's voor bedrijven op basis van WPA2/3 met 802.1X-verificatie zijn het gemakkelijkst te migreren naar 6 GHz.

Voor het inschakelen van uw 802.1X SSID voor 6 GHz is alleen PMF-ondersteuning nodig, zelfs als deze optioneel is, evenals 802.1X-SHA256 en/of FT + 802.1X AKM's, die beide WPA3-compatibel zijn.

We kunnen WPA2 met standaard 802.1X (SHA1) blijven aanbieden op hetzelfde WLAN en dat wordt alleen geadverteerd op de 5GHz-band. Ondersteuning voor Wi-Fi 7 vereist het inschakelen van Beacon Protection; WPA2 802.1X (SHA1) kan aanwezig blijven op het WLAN als een achterwaartse compatibiliteitsoptie.

Hoewel u mogelijk de deur open kunt houden voor veel apparaten "voor compatibiliteit" door AES128 en GCMP256 in te schakelen, door PMF als optioneel in te stellen en WPA2 AKM zoals gewone 802.1X te tolereren, creëert dit een situatie waarin de clients worden geconfronteerd met veel mogelijkheden en als ze verklaren dat ze Wi-Fi7 ondersteunen, maar op de een of andere manier een combinatie van beveiligingsinstellingen kiezen die niet voldoet aan Wi-Fi7, wordt het toegangspunt gedwongen de client af te wijzen, wat compatibiliteitsproblemen kan veroorzaken.

IOS XE 17.18.2 en lagere versies ondersteunen echter geen GCMP256 voor een Enterprise SSID, de belangrijkste aanbeveling is om een dergelijke use case te behouden voor bedrijfsomgevingen met voornamelijk Windows11-laptops. 

Zodra u 17.18.3 of hoger hebt uitgevoerd, kunt u GCMP256 inschakelen en bredere categorieën mobiele apparaten correct ondersteunen (sommige clients weigeren verbinding te maken als de SSID beweert Wi-Fi7 te zijn, maar alleen AES128 ondersteunt).

Het Meraki Cloud-dashboard ondersteunt GCMP256 en vereist het voor het inschakelen van Wi-Fi7 op de SSID. Het is OK voor een Wi-Fi7-client om alleen AES128 te ondersteunen, maar een gecertificeerde Wi-Fi 7 AP moet zowel AES128 als GCMP256 bieden.

Van een typische WPA2-SSID met deze L2-beveiligingsinstellingen:

We kunnen de configuratie voor WPA3-, 6 GHz- en gedeeltelijke Wi-Fi 7-ondersteuning migreren zoals hier wordt weergegeven:

Deze laatste schermopname ontbreekt GCMP256 voor een goede Wi-Fi7-ondersteuning. Het is ook potentieel problematisch voor klanten om dit veel verschillende cijfers aan te bieden en zo snel mogelijk over te stappen naar een volledig WPA3 WLAN met AES128 + GCMP256 moet worden overwogen.

WPA3-Enterprise-configuratie op het Cisco Meraki-dashboard

Op het moment van schrijven is WPA3-Enterprise alleen beschikbaar met een externe RADIUS-server (ook bekend als "mijn RADIUS-server").

WPA3-Enterprise is niet beschikbaar met Meraki Cloud Authentication.

Beginnend met MR 31.x, zijn de WPA-typen:

• 'Alleen WPA3', dat dezelfde cijfers gebruikt als WPA2, maar 802.11w (PMF) vereist.
• 'WPA3 192-bits', die alleen de EAP-TLS-methode met chipers TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 of TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 toestaat. Voor deze modus moeten dezelfde chipers op de RADIUS-server worden geconfigureerd om deze modus in te schakelen.
• 'WPA3 Transition Mode' (ook bekend als mixed mode), waarmee WPA2-clients naast elkaar kunnen bestaan op hetzelfde WLAN dat voor WPA3 wordt gebruikt. 

Bij gebruik van 'alleen WPA3' of 'WPA3 192-bits beveiliging' is PMF verplicht voor alle clients.

In de meeste toepassingen moet FT (802.11r), hoewel niet verplicht, beter in staat worden gesteld om de gevolgen van roaming en latentie voor herverificatie te beperken bij gebruik van een externe RADIUS-server.

Voor een werking van 6 GHz is PMF (802,11w) vereist. 

Bij het selecteren van de WPA3-overgangsmodus kunnen alle clients die WPA3 kunnen gebruiken, standaard PMF gebruiken. Alle clients die op 6 GHz werken, gebruiken WPA3.

In deze modus kunt u selecteren of de oudere client die WPA2 gebruikt, PMF moet gebruiken (802.11w vereist) of dat die functie optioneel is (802.11w ingeschakeld).

Ongeacht de WPA3-selectie moeten Cisco Meraki-toegangspunten de GCMP 256-coderingssuite kunnen gebruiken in de Wi-Fi 7-modus.

Bovendien is Beacon Protection standaard ingeschakeld op 2,4, 5 en 6 GHz wanneer de toegangspunten werken in de Wi-Fi 7-modus.

Wachtwoordgroep / WPA3-Personal / IoT-netwerken

Het inschakelen van een wachtwoordzin-SSID voor 6 GHz, tot Wi-Fi 6E-ondersteuning, is eenvoudig en vereist SAE en / of FT + SAE, samen met andere WPA2 PSK AKM's indien nodig. Voor Wi-Fi 7-ondersteuning vereist de certificering echter dat SAE-EXT-KEY en/of FT + SAE-EXT-KEY AKM's worden toegevoegd, samen met GCMP256-codering. 

Cisco IOS XE 17.18.1 en hoger kunt u nog steeds configureren WPA2-PSK op de top van de vier genoemde SAE AKM's. Dit roept echter de zorg op dat er mogelijk te veel (alleen vanuit het perspectief van een slechte clientdriver, omdat dit wordt ondersteund in de standaard) AKM's op dezelfde SSID staan. Het wordt aanbevolen dat u in de praktijk controleert of uw WPA2-clients alle AKM's kunnen verwerken die op het WLAN zijn ingeschakeld. In deze situatie, klanten die besluiten om verbinding te maken als WPA2 zijn niet toegestaan om te doen MLO of Wi-Fi7, maar klanten die verbinding maken met SAE-EXT zijn toegestaan om MLO en Wi-Fi7 te doen. Het WLAN zelf adverteert nog steeds met Wi-Fi 7- en MLO-mogelijkheden.

In dergelijke gevallen kunnen we een speciale WPA3-SSID configureren met SAE, FT + SAE, SAE-EXT-KEY en FT + SAE-EXT-KEY, die zowel AES(CCMP128)- als GCMP256-cijfers biedt voor meer recente Wi-Fi 6E- en Wi-Fi 7-clients.

In al deze scenario's raden we sterk aan om FT in te schakelen bij het gebruik van SAE. De SAE-frameuitwisseling is kostbaar in termen van middelen en langer dan de WPA2 PSK 4-weg handshake.

Sommige apparaatfabrikanten zoals Apple verwachten SAE alleen te gebruiken wanneer FT is ingeschakeld en kunnen weigeren verbinding te maken als deze niet beschikbaar is.

WPA3-SAE-configuratie op IOS XE 

Opmerking: Als (FT +) SAE is ingeschakeld op het WLAN en een Wi-Fi 7-client probeert hieraan te koppelen in plaats van (FT +) SAE-EXT-KEY, wordt deze afgewezen. Zolang (FT +) SAE-EXT-KEY ook is ingeschakeld, moeten Wi-Fi 7-clients deze laatste AKM toch gebruiken, en dit probleem mag niet gebeuren.

Hoewel het gebruik van een verouderd WLAN met alleen PSK bovenop een WPA-3 alleen WLAN de hoeveelheid totale SSID's verhoogt, kan het maximale compatibiliteit op één SSID behouden, waar we mogelijk ook andere geavanceerde functies kunnen uitschakelen die van invloed kunnen zijn op de compatibiliteit en die nuttig kunnen zijn voor veel IoT-scenario's, terwijl ze maximale functies en prestaties bieden aan meer recente apparaten via de andere SSID. Dit kan een voorkeursscenario zijn als je oudere of gevoeligere IoT-apparaten in beeld hebt. Als u geen IoT-apparaten hebt, kan het efficiënter zijn om voor een enkele overgangsmodus WLAN te gaan, omdat u slechts één SSID adverteert.

WPA3-SAE-configuratie op het Cisco Meraki-dashboard

Tot firmware MR 30.x is het enige ondersteunde WPA-type 'alleen WPA3' en het dashboard laat u geen andere methode selecteren.

PMF is verplicht in deze configuratie, terwijl FT (802.11r) wordt aanbevolen om ingeschakeld te zijn bij het gebruik van SAE.

Als u Wi-Fi 7 wilt laten werken, moeten de GCMP 256-chipersuite en de SAE-EXT AKM-suite worden ingeschakeld bij de configuratie van de SSID.

Ze zijn standaard uitgeschakeld en kunnen worden ingeschakeld onder 'Geavanceerde WPA3-instellingen'. 

Vanaf dit schrijven moeten alle WLAN's die in het netwerk zijn ingeschakeld, voldoen aan de vereisten van de Wi-Fi 7-specificatie om te worden ingeschakeld op firmwareversie MR 31.1.x en hoger.

Dit betekent dat een Wi-Fi 7-SSID die is geconfigureerd zoals eerder beschreven, niet naast elkaar kan bestaan met een andere SSID in de WPA2-Personal- of WPA3-SAE-overgangsmodus.

Als een WPA2-Personal SSID is geconfigureerd in het dashboardnetwerk, worden alle Wi-Fi 7-toegangspunten weer ingeschakeld voor de werking van Wi-Fi 6E.

Dit gedrag verandert in een toekomstige versie van firmware MR 32.1.x.

Open / Enhanced Open / OWE / Gastnetwerken

Gastnetwerken komen met veel smaken. Meestal hebben ze geen 802.1X-referenties of wachtwoordzin nodig om verbinding te maken en mogelijk een splash-pagina of -portal te impliceren, waarvoor referenties of een code nodig kunnen zijn. Dit wordt traditioneel afgehandeld met een Open SSID en lokale of externe gastportaaloplossingen. SSID's met open beveiliging (geen codering) zijn echter niet toegestaan op 6 GHz of voor Wi-Fi 7-ondersteuning.

Een eerste zeer conservatieve benadering zou zijn om gastnetwerken op zijn best te wijden aan de 5 GHz-band en Wi-Fi 6. Dit laat de 6 GHz-band gereserveerd voor zakelijke apparaten, lost het complexiteitsprobleem op en zorgt voor maximale compatibiliteit, hoewel niet tot Wi-Fi 6E/7-prestaties.

Als aan de ene kant Enhanced Open een geweldige beveiligingsmethode is die privacy biedt en tegelijkertijd de "open" ervaring behoudt (eindgebruikers hoeven geen 802.1X-referenties of wachtwoordzin in te voeren), heeft deze tot op de dag van vandaag nog steeds beperkte ondersteuning tussen eindpunten. Sommige klanten ondersteunen het nog steeds niet en, zelfs als ze dat doen, wordt deze techniek niet altijd soepel afgehandeld (het apparaat kan de verbinding als onbeveiligd weergeven, terwijl deze eigenlijk veilig is, of het kan deze als wachtwoordbeveiligd weergeven, zelfs als er geen wachtwoordzin nodig is met OWE). Aangezien van een gastnetwerk wordt verwacht dat het op alle niet-gecontroleerde gastapparaten werkt, kan het te vroeg zijn om alleen een Enhanced Open SSID te leveren en wordt aanbevolen om beide opties via afzonderlijke SSID's te bieden: een open op 5 GHz en een OWE ingeschakeld op 5 en 6 GHz, beide met hetzelfde captive-portaal erachter als dit ook een vereiste is. De transitiemodus wordt niet ondersteund op Wi-Fi 6E, 6 GHz (hoewel het nog steeds kan worden toegestaan op software) of Wi-Fi 7, dus dat is geen aanbevolen oplossing. Alle portaalomleidingstechnieken (interne of externe webverificatie, centrale webverificatie, ...) worden nog steeds ondersteund door OWE.

OWE-configuratie op IOS XE 

Als we 6 GHz-service aan gasten willen bieden, zou de aanbeveling zijn om een afzonderlijke SSID te maken met Enhanced Open / OWE (Opportunistic Wireless Encryption). Het kan zowel AES (CCMP128)-codering bieden, voor maximale compatibiliteit tot Wi-Fi 6E-clients, als GCMP256-bits voor Wi-Fi 7-compatibele clients.

Op dit moment bieden veel mobiele klanten gedeeltelijke of niet-zo-gebruiksvriendelijke ondersteuning van OWE / Enhanced Open. Test samen met uw klanten om de ondersteuning te meten.

Het hebben van twee afzonderlijke gast-WLAN's (één Open en één OWE / Enhanced Open) kan een oplossing lijken (vooral als u de OWE-beveiligde gast alleen op 6 GHz houdt en de volledig open alleen op 5 GHz houdt), maar dit vereist dat u die twee gast-WLAN's scheidt van verschillende subnetten, anders ontkent het Open WLAN het beveiligingsvoordeel van het andere beveiligde WLAN door niet-gecodeerd te zijn in hetzelfde subnet.

OWE-configuratie op het Cisco Meraki-dashboard

Vergelijkbaar met wat werd gedaan op IOS XE, is de aanbeveling om een afzonderlijke gast-SSID te maken met Enhanced Open / OWE die werkt op 6 GHz op het Cisco Meraki-dashboard.
Dit kan opnieuw worden geconfigureerd in Draadloos > Toegangsbeheer, en 'Opportunistische draadloze codering (OWE)' als beveiligingsmethode selecteren.

Wanneer u firmware tot MR 31 uitvoert, is het enige ondersteunde WPA-type 'alleen WPA3' en kunt u op het dashboard geen andere methode selecteren.

PMF is verplicht in deze configuratie, terwijl FT (802.11r) niet kan worden ingeschakeld.

Merk op dat de etikettering 'alleen WPA3' overbelast is omdat OWE geen deel uitmaakt van de WPA3-standaard; deze configuratie verwijst echter naar OWE zonder overgangsmodus.

OWE Transition Mode wordt beschikbaar gesteld als onderdeel van een toekomstige release van MR 32.1.x.

De AES(CCMP128)-codering is standaard ingeschakeld voor maximale compatibiliteit met Wi-Fi 6E-clients.

GCMP256-bits kunnen naast CCMP128 worden ingeschakeld om te voldoen aan de vereisten voor Wi-Fi 7.

Extra WPA3 en gerelateerde opties

Hoewel WPA3-opties het best kunnen worden beschreven en behandeld in de WPA3-implementatiegids, behandelt dit gedeelte enkele aanvullende aanbevelingen voor WPA3 die specifiek betrekking hebben op 6 GHz- en Wi-Fi 7-ondersteuning.

Bakenbescherming

Dit is een functie die de kwetsbaarheid oplost, waarbij een kwaadwillende aanvaller bakens kan verzenden in plaats van het legitieme toegangspunt, terwijl sommige velden worden gewijzigd om de beveiliging of andere instellingen van reeds gekoppelde clients te wijzigen. Beacon-bescherming is een extra informatie-element (Management MIC) in het baken dat als handtekening voor het baken zelf fungeert, om te bewijzen dat het door het legitieme toegangspunt is verzonden en dat er niet mee is geknoeid. Alleen gekoppelde clients met een WPA3-coderingssleutel kunnen de legitimiteit van het baken verifiëren; probing-clients hebben geen middelen om het te verifiëren. Het extra informatie-element in het baken moet eenvoudig worden genegeerd door clients die het niet ondersteunen (dit verwijst naar niet-Wi-Fi 7-clients) en het veroorzaakt normaal gesproken geen compatibiliteitsproblemen (tenzij met een slecht geprogrammeerd clientstuurprogramma).

Na 17.18 uur worden de bakenbeveiligingselementen automatisch ingeschakeld als uw WLAN voldoet aan Wi-Fi7, ongeacht of u het selectievakje voor bakenbeveiliging inschakelt of niet

Deze screenshot toont een voorbeeld van de inhoud van het Management MIC Information Element:

GCMP256

Tot de Wi-Fi 7-certificering, de meeste clients geïmplementeerd AES (CCMP128) encryptie. CCMP256 en GCMP256 zijn zeer specifieke varianten gerelateerd aan SUITE-B 802.1X AKM. Hoewel sommige eerste generaties van Wi-Fi 7-clients op de markt aanspraak maken op Wi-Fi 7-ondersteuning, implementeren ze soms nog steeds geen GCMP256-codering, wat een probleem kan worden als Wi-Fi 7 AP's die de standaard afdwingen zoals verwacht voorkomen dat deze clients verbinding maken zonder de juiste GCMP256-ondersteuning.

Als GCMP256 is ingeschakeld, wordt in de lijst met Pairwise Chiper Suite geadverteerd met het robuuste netwerkbeveiligingselement (RSNE) in de Beacon Frames voor het WLAN.

Problemen oplossen en controleren

De nieuwste versie van Wireless Configuration Analyzer Express (https://developer.cisco.com/docs/wireless-troubleshooting-tools/wireless-config-analyzer-express-gui/) heeft een gereedheidscheck voor Wi-Fi 7 waarmee de 9800-configuratie wordt geëvalueerd voor alle eerder genoemde Wi-Fi 7-vereisten.

Als u nog steeds twijfelt of uw configuratie klaar is voor Wi-Fi 7, laat de WCAE u weten wat er mis is.

Controlelijst voor probleemoplossing 

• De Web UI (in R32 of 17.18.2 en hoger) vertelt u of uw WLAN voldoet aan de Wi-Fi 7-standaard. Zorg ervoor dat de beveiligingsinstellingen compatibel zijn met de hulp van dit document.
• Zorg ervoor dat de client Wi-Fi7 ondersteunt. In het geval van een Windows-laptop, het vereist Windows 11 24h2 op het allerminimum. Controleer of de stuurprogramma's voor de draadloze adapter zijn bijgewerkt.
• De opdracht "netsh wlan show drivers" in Windows is erg handig om de mogelijkheden van de draadloze adapter te vermelden en de status ervan te controleren.
• In het geval van een laptop gaat u naar de adapterinstellingen en controleert u of de 11be-modus is ingeschakeld. Voor compatibiliteit veel adapters uitgeschakeld 11be in de eerste dagen en werkte als 11ax.
• Neem in geval van twijfel een over-the-air pakketopname om te controleren dat:
  • Het toegangspunt zendt het EHT-informatie-element in het baken uit. Dit kan worden vastgelegd met elke snuffer die zelfs Wi-Fi 7 niet hoeft te ondersteunen, omdat het baken met verouderde snelheden wordt verzonden.
  • Als de AP EHT correct uitzendt, moet de klant het EHT-element in zijn associatieverzoek verzenden. Als dit niet het geval is, geeft dit aan dat de client de beveiligingsinstellingen van het toegangspunt die compatibel zijn met Wi-Fi 7 niet heeft gevonden of dat de 802.11be-instelling van de client is uitgeschakeld in de eigenschappen van de adapter

Referenties

1. Cisco Systems. "WPA3-codering en configuratiehandleiding." 
2. Meraki WPA3-gids