ThinkPad Universal USB-C Smart Dock with multiple MACs

[LuensmannIT]

Hi Community,

our client hardware department is ordering a lot of the new ThinkPad Universal USB-C Smart Docks which seems to bring a couple of problems with them regarding ISE / 802.1x.
These smart docks have a Microsoft Azure Sphere connection build in to be able to update firmware and doing maintenance without having a client connected to the dock. To accomplish this the docks have a burned in IoT MAC on the ethernet interface (and also a Wi-Fi interface for the same reason but this is out of scope in the moment).

We are using authentication host-mode multi-domain on our ports and now run into trouble when a notebook is connected to the dock as we are seeing the burned in IoT MAC from the dock itself and the MAC from the notebook (via pass-through) at the same time.

I know we could switch to authentication host-mode multi-auth to allow more then one MAC in the DATA domain, but we don’t want to allow this behavior in general.

So, my questions:

The client hardware department is saying that they are unable to deactivate the IoT interface, but they may be ok with just not using this interface. Is there a possibility to block specific OUIs (in this case the Lenovo IoT MACs) before even triggering the violation in the DATA domain if multi-domain is set? For example, with port-security? Does anyone have experience with this?

If we must bring the IoT interface online to enable firmware upgrades and doing maintenance without having a client connected to the dock, how about dynamic VLAN assignment? Even if we would allow the IoT MAC to connect to the same client VLAN as the client behind the dock, there is more than one client VLAN at a location.
As far as I know and regarding the docs I have read, there is no way to have multiple clients behind the same physical port to be in different VLAN?

Do you have advice to solve this problem?

Scenario 1:
Switchport <-> IP Phone (Voice VLAN) <-> IoT Dock (IoT VLAN) – No client
 Should be ok, IoT Dock is like a single normal client.

Scenario 2:
Switchport <-> IP Phone (Voice VLAN) <-> IoT Dock (IoT VLAN) – Customer A (VLAN A)
 Does not work if dock and Customer A need to be in two different VLANs, correct?
 Would work if we allow the IoT Dock to be in the same VLAN as Customer A and enable authentication host-mode multi-auth, correct?

Scenario 3:
Switchport <-> IP Phone (Voice VLAN) <-> IoT Dock (VLAN A) – Customer B (VLAN B)
We are offering shared desk environment where different customers can attach to the dock in the same building.
 So even if we put the IoT Dock in the Customer A client VLAN (instead of IoT VLAN) it would work when a Customer A is attaching to the dock, but it wouldn’t work if a Customer B is attaching to the dock, correct?

Thanks for your time in best regards

[LuensmannIT]

Just a quick update: We are still in touch with Lenovo to be provided with a solution....

[Arne Bier]

Hi @LuensmannIT 

If the switch shows the MAC address of the client that is on the other end of the USB-C hub, then you might consider configuring a very aggressive device-discovery reachable-lifetime value, and tie this in with your IBNS policy. I don't know if IBNS 1.0 supports this, but with IBNS 2.0 it's like this. Create a device-tracking policy that is super aggressive (e.g. sending ARP probes every 2 seconds), and then attach this to your NAC enabled access interfaces:

device-tracking policy IPDT_POLICY
 tracking enable reachable-lifetime 2

When a user disconnects from the USB-C dock, then the ARP responses will stop being received within 2 seconds. That makes the session go "inactive"

In the IBNS 2.0 policy you tell the switch what to do when the Sessions go "inactive"  

policy-map type control subscriber PORT-AUTH-POLICY
 ...
...
 event authentication-success match-all
  10 class always do-until-failure
   10 activate service-template IA-TIMER
!
 event inactivity-timeout match-all
  10 class always do-until-failure
   10 clear-session
 

Where the IA-TIMER is configured

service-template IA-TIMER
 description ** Apply inactivity timer and ARP probe **
 inactivity-timer 2 probe

The danger with IA timer is that it will clear sessions if devices are not very chatty. But the probe will fire and if it gets a response the session will stay up.

DISCLAIMER: I have not tried this myself. I have had experience with these concepts insofar that I had to modify the IA Timers for devices that were not very chatty (some Cisco desk phones) and if I left the default of 60 seconds, then the phones would auth every 60 seconds when the CDP was sent my the phone. By increasing the IA to 180 seconds, the phones stopped their endless auth cycle - I had to make the switch a bit more patient.

Your challenge is how to make the switch very IMPATIENT, without affecting all the connected users. I think there might be a suitable combination using the techniques above. Of course, sending ARPs constantly to endpoints is an ugly business, but what can you do to sense whether the device is still there or not?

[LuensmannIT]

Hi @Arne Bier,

that’s a quite interesting idea. So far we do not have IBNS 2 in production. I’m out of office until mid of September but will definitely try your suggestions when back at work.

Best regards,

Sebastian

[gthjohansson]

Hello Sebastian

Did you ever get a workaround or a fix to this issue ? 

regards Gudmundur

[LuensmannIT · Accepted solution]

Hi Folks,

has been quite a long time since my last post. We had a couple of discussions, improvement requests and tests with lenovo, but in the end the only working solution for us is to use a docking station which does not have this IoT Port or use a docking station with a firmware which does not use the IoT Port and thus never violates our policies.
We are fine with this solution and do not engage further to change the behavior of the IoT Port.