[PATCH 1/2] Client Taxonomy

[Denton Gentry]

On Sat, Aug 13, 2016 at 2:18 PM, Arran Cudbard-Bell
<a.cudbardb at freeradius.org> wrote:
>> On 11 Aug 2016, at 08:35, Johannes Berg <johannes at sipsolutions.net> wrote:
>>
>>
>>> +##### Client Taxonomy #########################################################
>>> +#
>>> +# Has the AP retain the Probe Request and Association Request MLME frames from
>>> +# a client, from which a signature can be produced which can identify the model
>>> +# of client device like "Nexus 6P" or "iPhone 5s"
>>> +# client_taxonomy=1
>>>
>> This being a fairly niche feature, perhaps it should get a build time
>> option so the code can be excluded? Even things almost everybody wants
>> like 11N have build time options, and this one seems to be much more
>> likely to not be desired in all builds. Thoughts?
>
> I think the techniques Avery described in his presentation (https://www.youtube.com/watch?v=yZcHbD84j5Y) are equally useful in Education, Enterprise and Carrier deployments and are not at all niche.
>
> If signature definitions were bundled, and the determination/confidence info were inserted into an attribute like Connect-Info (or a hostapd VSA - I’m sure Alan DeKok will comment on appropriate attribute usage), you’d see very widespread adoption and use.  It’d represent an ultra low barrier to the sort of analysis Google are doing on their ISP network.
>
> If there’s interest, and the Client Taxonomy patches go in, we (FreeRADIUS) would definitely be up for submitting patches to add RADIUS support.
>
> -Arran
>
> Arran Cudbard-Bell <a.cudbardb at freeradius.org>
> FreeRADIUS Development Team
>
> FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

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. 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.