During a city WLAN design review, the security architect asks how clients learn which AKM suites and pairwise ciphers an AP supports before associating. Which element advertises those RSN capabilities?
Select an answer to reveal the explanation.
Short Explanation
Beacons and probes are the AP’s sandwich-board on the sidewalk—RSN info tells clients which locks and key ceremonies are on offer before anyone associates. DHCP and RADIUS accounting show up too late to be that advertisement.
Full Explanation
During a city WLAN design review, clients learn which AKM suites and pairwise ciphers an AP supports before associating from the RSN information advertised in beacons and probe responses. That element is the on-air capability billboard for Robust Security Network parameters, allowing stations to select a mutually supported authentication and cipher combination. Architects who cannot find AKM/cipher truth in the beacon are looking in the wrong protocol layer. The DHCP vendor class string returned after the client already has an IP address arrives too late to advertise pre-association RSN capabilities. RADIUS Accounting-Stop packets list session history, not the live suite menu for prospective clients. The SNMP sysDescr OID on the switch uplink may describe wired infrastructure branding but does not encode the WLAN RSN IE clients need. Exam caveat: transition SSIDs may advertise multiple AKM and cipher options—policy must define which advertised suites are intentional versus accidental leftovers from old templates. Operational check: capture a beacon from each major municipal SSID class, extract the RSN IE AKM and pairwise cipher lists, and reconcile them against the written allowlist before approving the design package.