ITC/3AV WIKI

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
**Technical note for the section on DHCP fringerprint and as through it, users could classify and apply roles based on them.**

**DHCP Fingerprinting**

 
DHCP Fingerprinting is a method of detecting the end device OS based on the dhcp exchange packets. In today's network where we are talking about IoE , BYOD it is required to identify the devices in your network and mark them accordingly.

**Why do we need Fingerprinting:**
========================

With BYOD personal devices are making their way into the workplace, and it is a tough job for the network administrators to dynamically detect these devices and make sure these devices are compliant and to enforce required polices on these devices. Detecting the devices type/OS is also part of the play.

Due to the proliferation of BYOD (Bring Your Own Devices)/mobile devices connecting mostly over the Wireless Network, it becomes difficult to identify and control the types of devices that can connect to the network, and once connected, to determine what access privileges they might have.

With DHCP Fingerprinting, DHCP Servers or devices like IPAM Controllers or Wireless Controllers, can use DHCP Fingerprinting to identify the device type, manufacturer name and OS of the clients/devices connecting to the network, categorize them into ACLs, and control which device can connect to the network and what it can do.


**How it works:**
===========


**DHCP Fingerprinting is one of the methods that help us in identifying the OS on the devices bases on the dhcp option.**

For example, mobile devices, once identified, can be given Internet access only (without LAN access). Further, Android devices can be denied even Internet access, while iOS devices can be given access only to a specific portal, depending on the company policy. In fact, same user can be given different access privileges, depending on whether he is logging in from his laptop or iPhone, respectively.

Some devices that can be identified by DHCP Fingerprinting include:

Mobiles, Tablets.

Desktops.

Servers.

Routers, Switches, Access Points.

Gaming Consoles.

VOIP Systems.

Printers, etc.

DHCP Fingerprinting can be used to provide device visibility, access control, monitoring usage/application trends, prevent BYOD security risks, etc.

**What else?**

MDM (Mobile Device Management) application can be used to classify and control access to mobile devices on the network, but it is an invasive application that may need an agent to be installed in each mobile device.

There are other methods to classify devices into their respective ACL groups –  DHCP Fingerprinting is one of them, but the later might carry a higher precedence than others.

Since DHCP Fingerprinting operates on attributes after successful authentication, devices that fail authentication will not get IP address to connect to the network in the first place.

DHCP Fingerprinting is mostly a non-intrusive process without overhead of additional network discovery devices/processes.


{{ :aruba_networks:controller:aos-dhcp-fingerprint-appnote.pdf |}}


----

**DHCP FINGERPRINTING WITH Aruba Instant** 

With organizations encouraging corporate users to bring their own device to work; IT staff faces the challenge of differentiating between the devices. Aruba Instant’s Mobile Device Access Control can differentiate devices based on:

a)      DHCP Fingerprinting

b)      EAP Type

This guide provides background information on DHCP fingerprinting and walks through the configuration, troubleshooting steps.

DHCP is a 4-step client – server exchange through which the client obtains an I.P. address and other network parameters such as gateway I.P. address, DNS server from the Server. Below diagram is an overview of client-server transaction. 

{{:aruba_networks:controller:fingerprint.png?600|}}

Along with the actual request; the DHCP messages carry “DHCP Options” – a set of configuration parameters and other control information.  These options can be used to uniquely identify a device type / OS type.

Below is an example of DHCP Options from a Windows 7 client’s DHCP Discover. 

{{:aruba_networks:controller:fingerprint1.png?600|}}

As it can be seen in above example; all the DHCP Options are of the format:: [Option][Length][Value] where option is the Hex value of the Option number. Example :: Option 61 would be 3D in Hex.


Aruba Instant’s DHCP fingerprinting uses only the Option & Value. Example:: DHCP Fingerprint  for Option 61 would be 3D010022FA5F66D6 (See above screenshot). 


The DHCP Fingerprinting is based on inspecting the DHCP options of DHCP Discover & Request i.e. client initiated DHCP traffic. 

**Which Options are Useful?**

Below is the list of DHCP options which can be used for role derivation.  It should be noted that::

· Not all devices send all options. Example :: Apple Devices don’t send Option 60

· Option 12 is configurable by end-user i.e. less reliable.

{{:aruba_networks:controller:fingerprint2.png?600|}}

**Environment:**

The following software and hardware are used in this document to illustrate the concept and configuration steps.

{{:aruba_networks:controller:fingerprint3.png?600|}}

Role assignment via DHCP-Option is available under Access tab of SSID configuration.  Below is an example screenshot.  If a client doesn’t match any of the rules; it would be assigned the Default role (In this example; Fingerprint)

{{:aruba_networks:controller:fingerprint4.png?600|}}

The role assignment can be validated by checking the Clients tab of the User Interface. In the below example; the first two clients have matched a rule and been assigned corresponding rule (Win7 & MLion). The third didn’t match any rule and was assigned the default role.

{{:aruba_networks:controller:fingerprint5.png?600|}}

**Note: When there are multiple rules which a client would matches; the first rule is used to derive role. Hence; the rules must be ordered from most specific to least specific.**

If a VLAN is mapped to the ROLE deriver via DHCP-Option; it will not take effect.

Below is a table which includes fingerprints for major operating systems.

{{:aruba_networks:controller:fingerprint6.png?600|}}


----

**Sample Scenarios**

**GIVE SPECIAL PRIVILEGE TO A SPECIFIC USER**

There maybe instances where one specific user / set of users (example :: CEO’s cellphone) must be treated differently.   Option 61 can be used to achieve this. As Option 61 is based on the MAC address; the device can be uniquely identified and placed in a specific role. It must be noted that Option 61 based rule must always be on top of the rule list to ensure it gets hit first.

**WINDOWS DEVICES**

**Rule for Windows XP, Vista and 7**

All three OS versions send MSFT 5.0 for Option 60.

DHCP-Option value equal to 3C4D53465420352E30 can be used to classify all three latest Windows Client OS versions (i.e. XP, Vista & 7).

**Rule for Windows Vista and 7 alone**

DHCP-Option value equal to 37010f03062c2e2f1f2179f92b can be used to classify Windows Vista & 7 OS devices.
All Windows Devices from Windows 95

A starts-with “37010f03062c2e2f" rule can be used to classify all Windows Client OS devices from Windows 95 till Windows 7.

**APPLE DEVICES**

iOS Devices

DHCP-Option value equal to  370103060f77fc can be used to classify iOS devices

**All Apple Devices**

A rule with DHCP-Option value starts with 370103060f77 can be used to classify all iOS and Mac OS X devices.
 
There can be two cases a) Clients hitting the wrong rule b) Client not hitting the rule.

For the case client hitting the wrong rule; ensure the rules ordered from most specific rule to least specific. This would ensure the client hits the right rule i.e. first match.

For the case of client not hitting the rule; we would need to validate if the DHC-Option value used in configuration is right.

With logging level set to debug for User category; Instant would be able to the DHCP fingerprint and role derivation information.

To enable debugging; navigate to Settings --> Show Advanced Options --> Syslog --> User --> Debug.

{{:aruba_networks:controller:fingerprint7.png?600|}}

With debugging enabled; the required information is available under “AP Log User” option under Support tab.  

Optionally; the output can be filtered using “DHCP”. Below example shows role derivation for a client which matched “Win7” rule.

{{:aruba_networks:controller:fingerprint8.png?600|}}