Embed Size (px)
Citation preview
Light Weight Access Point Protocol (LWAPP)IETF 57
Pat Calhoun, Airespace
Mobile
AP
AR
Ethernet orUDP
LWAPP
LWAPP Architecture
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.
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)
Division of Labor
Mobile
AP
AR
802.11 Control
802.11 Data & Management
Ethernet orUDP
LWAPP Control (signalling) & Data
LWAPP assumes the MAC is split betweenthe AP and the AR, reducing the functionsrequired on the AP.
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
LWAPP Components
● LWAPP consists of the following:– Control Channel Management– AR Configuration– Mobile Session Management– Firmware Management– Transport Services– Security
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
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
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)
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.
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
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
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?
