Hello
This is a great question. In the case of Low Impact Mode (i.e. the mode between Monitor and Closed Mode) there is a grey area, because we want to allow devices that have failed 802.1X (or who are incapable of 802.1X) to be profiled by ISE, in case there is a chance we can re-authorize them to make better decisions.
The reason we don't send back an Access-Reject is because the endpoint will be unauthorized on the switch, and that causes the switch to sit in an endless loop of authentication if the endpoint retries (and your Live Logs will be full of errors). To stop this endless cycle, we authorize the endpoint and put them in an ACL jail for the time being.
By authorizing them with a restrictive dACL, that overrides the interface's pre-auth ACL, we can allow some traffic to pass. I typically allow DHCP and SNMP. And only for the purpose of profiling - the end device won't be allowed to communicate meaningly with any end system, but ISE will have some insights via DHCP and SNMP at least. If the device uses static IP then ISE will only learn the IP if the switch has Device-Tracking enabled. DHCP is great for endpoint fingerprinting, because the DHCP Discovery Packet often contains data to identify the operating system. CDP and LLDP pass through and don't need an dACL.
The thing about MAB is that it has a lower security ranking than 802.1X, because of the assertion that it's highly improbably that a hacker will manage to make a cert that passes validation. Therefore, we tend to say that 802.1X auth is the gold standard, and we also tend to relax the dACL for such an auth, assuming with some degree of certainty, that we can trust the device. But we also know that security is not done when NAC has been performed - it's just the beginning.
Getting back to MAB. Any MAB auth should be treated with more risk than 802.1X auth. Therefore, even if a MAB auth'd endpoint has undergone profiling, we should still apply sensible dACLs to that authorization - but how strict? That is a trade-off between convenience and security - the more secure, the harder the job, because you must understand how each endpoint talks to the network (e.g. via extensive netflow analysis). The spectrum of possibilities is wide open. In my experience customers don't have the time to study all of their endpoints' traffic patterns and therefore the dACLs are fairly primitive - in many cases, a "permit any any" (LOL). The assumption is that firewalls further upstream will detect and protect the bad actors.
I used to think that by making my ISE Profiling Policies rely on things like SNMP strings and/or DHCP and CDP/LLDP I was introducing some small level of security. But it's a false sense of security, because all of these mechanisms can be faked by bad actors. The point of Profiling is to eliminate the doubt/ambiguity (e.g. if the Ethernet MAC OUI is from Intel, it tells you nothing about that that device is, thus we need to dig deeper) - it's not there to improve security. By making is mandatory that certain endpoints MUST have SNMP string XYZ, means that new devices must somehow first be pre-configured, before they will be magically profiled by ISE. This adds overhead to the customer, who has to stage/prep these devices and then connect them to the network - it's not always possible or feasible. I tend to use SNMP in cases when it's the only thing that's going to tell apart a printer from a scanner (as an example) when the MAC OUI is from the same vendor, and I want to treat these devices differently. SNMP tends to provide good insights into the device type.
True plug and play profiling happens when you have endpoints that support protocols such as CDP/LLDP/DHCP. Because the manufacturers enable these features (if supported on the endpoint) by default. An installer can unpack a new device and plug it into the network without anyone else needing to prep the device for profiling.
I hope that sheds some light on this topic.
