[PATCH 1/2] Client Taxonomy

[Arran Cudbard-Bell]

> 
> The signature database we've assembled is available:
> https://gfiber.googlesource.com/vendor/google/platform/+/master/taxonomy/wifi.py
> 
> We intend to extract it out of the git repository it is currently in
> (shared with a number of other tools we use) and into a github repo of
> its own. That would let signature submissions be handled as pull
> requests. We also need to revamp how it gets its inputs. Previously we
> had hostapd writing directly to files, the current signature lookup
> code expects to use those files.
> 
> However using it from hostapd at the time of sending the RADIUS report
> would be challenging. A number of the signatures supplement the
> information from the MLME frames with information from DHCP, and the
> DHCP exchange happens later. We talk about this in the paper
> https://arxiv.org/pdf/1608.01725v1.pdf in sections labelled
> "Supplemental Information" about OUIs and DHCP.
> 
> There are a number of signatures where we could switch from DHCP to
> rely on OUIs, but some of the important ones would be difficult.

It’s reasonably common in commercial equipment that supports DHCP Snooping for RADIUS Interim-Update packets to be sent as soon as the AP learns the IP of the STA.  We could do something similar here. It’s fine for additional data to be added in later accounting packets so long as the Acct-Session-ID attribute stays consistent.

Forwarding the data learned from 802.11 frames to the RADIUS server for aggregation and correlation with DHCP data would also be an option, but I think Interim-Updates would be simpler and easier for people to use.

> For
> example we use the DHCP signature of iOS for the various Apple
> devices. Apple's production volume is such that they consume OUIs
> every couple weeks, faster than we can keep up.

Wow, that’s pretty crazy!

-Arran

Arran Cudbard-Bell <a.cudbardb at freeradius.org>
FreeRADIUS Development Team

FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2