Wired 802.1x: MAB for Silent Endpoint

[biswajit.pradhan]

I'm sure people might have come across this problem numerous times previously. However, I was unabe to get something on this page. So posting this.

We have a deployment where we are turning on wired NAC with dot1x with MAB as failover. My understanding is that switch will allow a single packet from an endpoint which doesn't support 802.1x once EAP times out and thus learns the MAC address of the endpoint. Then switch starts the MAB. All good for endpoints which are active. Now in our deployment, there are couple of endpoints which are on static IP (means n dhcp request packets) and very silent. How does we accommodate these endpoints on MAB?

[balaji.bandi]

come across some issue around with medical device, looking some documents around. 

as mentioned below (hope this help you)

https://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Security/TrustSec_1-99/Dot1X_Deployment/Dot1x_Dep_Guide.html

[howon]

One way is to enable Wake on LAN feature (authentication control direction in) which allows traffic from the network to the client prior to authentication via certain broadcast frame that the client may respond to. Another surefire way is to use open mode (authentication open). Yet another option is to change the order of MAB and 802.1X so MAB happens first (authentication order mab dot1x).

[balaji.bandi]

Another surefire way is to use open mode (authentication open)

how do we deal with this, if the device go silent for Long , they only able to communicate with server when the data required to send ?

how is this process works ? what is the security challenges here ? if we use Authenticate Open ?

[howon]

I just realized there is another option which is to do MAB first then 802.1X. This way, the switch is not ignoring the initial DHCP request from the client when the device connects.

The open mode allows access to the network prior to authentication. One can apply pre-auth ACL and control what access it has prior to the authentication which is commonly called low-impact mode. I suggest going through following for more information.

https://community.cisco.com/t5/security-documents/ise-secure-wired-access-prescriptive-deployment-guide/ta-p/3641515#toc-hId-785487082

[biswajit.pradhan · Accepted solution]

Unfortunately the endpoints are on static IP. Even if you configure DHCP it will be authenticated for the first time then once idle timeout occurs, switch will drop and if somebody tries to access the endpoint now, it will fail. So to keep the endpoint generating traffic either have to keep DHC lease time aggressive (Half of lese time < Idle timeout) or find another solution. I found another solution.

Allowed all (wanted broadcast/ARP basically) traffic from switch to endpoint in pre-auth stage (CLI: authentication control-direction in), configured the port on actual access vlan rather than dummy vlan and changed dot1x order to mab dot1x. Wit this the endpoints comes online even in closed mode as switch will send arp request whenever anyone trying to access the endpoint from outside. Within one RTO it was getting authenticated and online.

[Peter Koltl]

A special interface template may be used for silent endpoints’ switchports (or for all the potential switchports where such clients are probable). This config should have MAB as first in order or at least concurrent MAB and 802.1X (available in IBNS 2.0).

However, this might not be suitable for all types of silent devices. You have to test each type extensively:

• whether the port becomes open after power cycle
• whether the port becomes open after cable disconnect/reconnect
• whether the port becomes open after a ping attempt to the client

It might be revealed that some kind of devices are not reliably allowed onto the network timely. You might need to set up  a continuous ping application.

[biswajit.pradhan]

We are using dynamic VLAN under authorization. All the ports are configured with a dummy vlan and depending upon endpoint type, ISE sends CoA to change it to right VLAN.

Tested quite a few config combination. It only works when the port is in open mode and configured in right vlan (not the dummy vlan). With this configuration it doesn't add any value from security perspective. Have opened a case with TAC as well in parallels to see if they can help.