For headless device authenticated on the switch, how to ensure that they don't drop-off the network

[jdryan]

Recently had come across a concern where the given printer was not able to stay authenticated on the mac-auth session it had initiated. 
Digging further into what was causing, it found it to be as the same was classified headless device.

A tiny description of the devices labeled as Headless device(s):
Headless devices such as printers, badge readers, POS Scanner, Industrial sensors, and actuators, IoT devices etc. are known to have simple NICs which are not capable of 802.1x traffic generation.

Given the current security demand, the need to lock every free access port to the network is ever present to avoid unwanted/uninvited guests accessing internal information.

These devices however can-do mac-auth: where they are verified by their MAC addresses

Problem posed:
As with any authentication:
the connection [ethernet connection on the switch] once registers as offline due to no activity on the remote end, the session established when the device had authenticated gets logged off.
and as a part of all process in authentication: we do have a mandatory log off period / timer which does kick out the device, prompting them for a re-auth.

when either of this, happens for a user station on 802.1X its seamless: as the supplicant drivers take care of the re-auth

however, the device logging off the headless device when no traffic is generated can be an issue.

for example : a badge reader : at the door :
people would not be expected to tap the ID cards every minute, thus the traffic generated is sparse and not continuous. due to this when the device does not transmit  and switch moves the device to offline state, as due to no traffic seen.

Workaround that can be tried :
when this is seen : forcing a re-auth for the device would work : however when it comes to headless devices.
they dont generate traffic by themselves, and with port-access control thats imposed by the 802.1x and Mac-ath processes : denies/blocks both inbound and outbound traffic on an interface until authentication is sucessfull

physically reseating the cable : enables the switch to re-learn the connected device on the interface and mac-auth going through will have the same verified. and we will have traffic passing.

this however, is less Ideal as reseating every time : would mean either accessing the wall mounted reader in the closet where connection goes or at the wall mount itself for the task

this can leave bits vulnerable. [ thus defeating the purpose ]

Solution :
there are 2 ways to tackle the issue :
1 > standard and staight forward : exempt that port from authentication.
this however if discovered can be a loop hole in the network.

2 > use Radius attrubite to extend the session's idle window such that it covers the devices inactive period.
this would mean no loop hole in the network. and no need for physical intervention untill necessary.

for this when the authentication profile is set on the RADIUS platform : use the RADIUS IETF attribute of Idle-Timeout. this ensures that the session for a given device will only timeout after the specified interval when no traffic is seen from that specific device .

Attribute details :
Attribute-Name :
Idle-timeout
Attribute-ID :
28
Attribute-Data Type:
Integer
Attribute-Description:
Idle timeout after which the session is cleared when there is no traffic.
This is equivalent to configuring the max-sw age command through the CLI

the value is set in seconds : hence would need to time the same to a generalized period :
> where we can expect the max amount of gap : for ex. : when the office are shutdown during furlough or during the year end shutdown : where for a week's duration
the traffic would be minimal.
under this example : we would have 7 days in a week, 24 hours in a day, 60 minutes in a hour, and 60 seconds in a minute.
i.e. : 7*24*60*60 = 6,04,800

this value when set on the Authentication profile on the Authentication server : on the device's successfull auth will get passed as a Radius attribute.
that will have the session for the device extended.

this however can be set to any time in seconds as per the design's requirement.