1. Light Weight Access Point Protocol (LWAPP) IETF 57 Pat Calhoun, Airespace

2. Mobile AP AR Ethernet or UDP LWAPP LWAPP Architecture

3. Why LWAPP? ● At last count, there are at least 6 WLAN switch vendors, plus some of the Ethernet switching incumbents have announced products in this space. ● Most of these products have a proprietary protocol between the AP and the AR (A.K.A WLAN Switch). ● APs are being commoditized, and many AP OEMs see LWAPP as a way to enter the enterprise market - interest is very strong here! ● Standardizing LWAPP would benefit the Internet community by ensuring interoperability between WLAN switches and APs.

4. LWAPP Goals ● Reduction of the amount of protocol code being executed at the light weight AP. ● Centralization of the bridging, forwarding, authentication, encryption and policy enforcement functions for a WLAN, to apply the capabilities of network processing silicon to the WLAN, as it has already been applied to wired LANs. ● Providing a generic encapsulation and transport mechanism, the protocol may be applied to other access protocols in the future (note: the draft needs work here)

5. Division of Labor Mobile AP AR 802.11 Control 802.11 Data & Management Ethernet or UDP LWAPP Control (signalling) & Data LWAPP assumes the MAC is split between the AP and the AR, reducing the functions required on the AP.

6. What does it do? ● LWAPP enables a new architecture for 802.11 infrastructure devices. ● Most of the functionality that is traditionally in the AP can be moved to the centralized AR. ● This gives the AR a greater view of the RF topology, enabling many different types of benefits, such as: – Security. Detecting attacks on a network basis vs. on a single cell – Mobility. Easier to proactively handle mobility events

7. LWAPP Components ● LWAPP consists of the following: – Control Channel Management – AR Configuration – Mobile Session Management – Firmware Management – Transport Services – Security

8. Control Channel Management ● Discovery – The draft currently defines a zero-config dynamic discovery mechanism for Ethernet and IP (when run in same subnet). The draft proposes different discovery mechanisms, but this area probably needs some work ● AP-AR session establishment – Creates a binding between the AP and the AR. This phase also includes a key exchange to secure all control messages ● Heatbeat ● Key Update – Periodically update the AP-AR key

9. AR Configuration ● Configure Response – Allows the AP to securely push its current configuration to the AR ● Configure Update – Allows the AR to securely push configuration to the AP ● Statistics Update – Allows the AP to send current stats to the AR ● Reset Request – Reboots the AP

10. Mobile Session Management ● Add Mobile – Pushes a specific rule (and optionally dynamic TKIP/WEP/AES key) to the AP ● Delete Mobile – Deletes a previous rule (and key)

11. Firmware Management ● During the AP-AR session establishment phase, the peers exchange firmware versions. ● If the versions are out of sync, this allows the AR to securely download a new image to the AP.

12. Transport Services ● The LWAPP document includes a transport section, and currently defines two transports: – Ethernet, allows LWAPP to run natively over Layer 2 – IP, specifies how LWAPP is run over UDP ● The transport section discusses the following: – Transport specific discovery extensions – Packet Framing – Fragmentation/Reassembly issues

13. LWAPP Security ● The document currently assumes that all LWAPP peers have a certificate ● During the AP-AR session establishment phase, a session key is exchanged and all control packets are subsequently encrypted using AES-CCM ● A rekey message exists in order to allow the AP (or AR) to create a new session key

14. Points raised on the mailing list ● Where does encryption occur? ● LWAPP discovery over Layer 3 ● Should LWAPP data messages be secured? ● Should we use certificates or shared keys?

15. LWAPP Mailing List ● The mailing list is accessible at lwapp@frascone.com.