IBNS 2.0 / Device Sensor only for successful authentications (CSCux48616)

[Johannes Luther]

Hi board,

I'm not quite sure if this belongs here or in the switching section. I'll give it a try here first.

I'm using IBNS 2.0 on my switches. My ISE use-case is 802.1X and MAB with profiling. Formerly, I did profiling using the DHCP probe and SNMPQuery probe to gather CDP and LLDP attributes - simple enough!

Now I'm testing the Catalyst 2960-X SW Version 15.2(4)E4 and thought, that the device sensor would be a great alternative and to only activate the RADIUS probe on my PSNs. Despite the usual hassle regarding the device-sensor syntax in IBNS 2.0 I finally got it working and verified the testing results by a RADIUS accounting capture with the device sensor AVPs with an existing endpoint in my endpoint database. So far so good.

The only thing, which is not working is the device sensor in combination with new endpoints, which initially are rejected, because there is no match in the authentication and/or authorization policy.

Obviously, the Cat. switch is only sending out RADIUS accouting messages, containing device-sensor attributes after successful authentication (staus: authorized).

I stumbled over the bug CSCux48616, which describes this behavior. The bug description states that this is a documentation bug instead of a switch bug.

First question: Anybody knows this behavior on switches? Where's the documentation for this? I couldn't find any hint's except in this bug note.

Second question (object to discuss):

If this is the normal behavior, the device sensor functionality doesn't make much sense from my point of view. New devices, that have never been on the network and perform a MAB authentication are rejected by nature, because:

• these devices are not in any endpoint identity group (not profiled) and fail authentication (authentication failure) OR
• these devices are profiled (e.g. Cisco-Device because of OID) but there is no authorization rule for this group (authorization failure).

Even if the devices are rejected by the ISE, link-local operations (CDP,LLDP) are still possible. When using "authentication open" with a pre-auth port ACL, DHCP is possible as well (if allowed in the ACL). At least the local device sensor cache on the switch is populated correctly, even on failed authentication ports.

So why on earth shouldn't the switch give this valuable information to the ISE?! It would help to profile the device to a matching endpoint identity group - eventually issue a CoA, resulting in a passed authorization.

A dirty workaround would be to:

• Modify the MAB authentication policy to "continue" in case the user is not found (for new - not profiled devices)
• Modify the authorization policy to make sure there are no rejected (DenyAccess rule) authorizations (e.g. "if any then dACL DenyAll")

But come on .... this is nonsense ..... or not?!

Or is there a config command to enable device sensor accounting for failed authentication attempts?!

Please share your thoughts.

Kind regards

Johannes

[howon · Accepted solution]

The document described in the defect is this one: https://communities.cisco.com/docs/DOC-68156

What you described as the workaround is what we recommend. If one is using wired guest, then one would be allowing any new endpoints to have limited network access and during that time NAD can collect the endpoint profile. If not using guest access, then you would provide minimum access to collect profiling information as you described. Providing some form of permit has two main benefits as opposed to sending deny. First is that as ISE sends permit, ISE maintains the session and thus can send CoA to reauthenticate the endpoint when the endpoint category is learned so the endpoint can get proper network access. Second is that as the endpoint gets permit, in general endpoint/switch stops trying to authenticate, while when deny is sent, you would end up with the endpoint trying to reauthenticate, thus filling up the logs unnecessarily.

[Johannes Luther]

Thank you for the detailed answer. However, I knew the mentioned document above and I went through this document just a few seconds ago. I couldn't find any hint within this document, which describes the mentioned device sensor behavior (not sending attributes in case of failed auth). Furthermore, I couldn't find any hint, that the "permit access" authorization rule at the end for all unknown (or generally profiled) clients is the recommended way to go.

In fact, there's still the usual low-impact example, that there is a port-ACL on the switch port.

Here are some additional examples:

Document How To: ISE Phased Deployments

The low-impact mode description states that "in the Low-Impact Mode, we will add security on top of the framework that we built in Monitor Mode by applying an (ACL) to the switchport to allow very limited network access prior to authentication. After a user or device has successfully authenticated, they will be granted additional network access."

But you are right, in the document How To: Deploy ISE in Low Impact Mode, the last authorization rule is not DenyAccess. Instead a WebAuth authorization profile is used to support wireless and wired guests. So at the end of the day, each endpoint is authorized in this document. However, what I miss is the statement, that this kind of mandatory that the device sensor works properly. At least I couldn't find an indication in any document. And maybe there are customers, that do not want wired guests in the network, because there is no wired zoning model to support guests in a separate security zone (e.g. MPLS-VPN, SGT, LISP, campus-wide VLANs )

Regarding the mentioned benefits:

First is that as ISE sends permit, ISE maintains the session and thus can send CoA to reauthenticate the endpoint when the endpoint category is learned so the endpoint can get proper network access.

This works in combination with denied unknown endpoints as well (see snippet of IBNS 2.0 / C3PL config)

event authentication-failure match-first

event authentication-failure match-first

10 class DOT1X_NO_RESP do-until-failure

    10 terminate dot1x

20 class MAB_FAILED do-until-failure

    10 terminate mab

    20 authentication-restart 60

30 class always do-until-failure

    10 terminate dot1x

    20 terminate mab

    30 authentication-restart 60

So if the authentication has failed, the dot1x and mab process is restarted every 60 seconds by the switch. So in case an endpoint is successfully profiled (e.g. by SNMPQuery or DHCP probe), the authentication succeeds in the next process run (after 60 seconds)

Second is that as the endpoint gets permit, in general endpoint/switch stops trying to authenticate, while when deny is sent, you would end up with the endpoint trying to reauthenticate, thus filling up the logs unnecessarily.

That's a good point. However, the ISE uses per default a 60 minute rejection and 15 minute reporting interval for the failed clients. So logging on the ISE side should not be a big issue I guess. On the switch side you are absolutely right. Every 60 seconds (with default logging behavior) there is a MAB and Dot1X Auth failed message referring to the example above.

However, especially when introducing NAC to an existing network I like the idea of failed unknown clients more, because of the logging. A MAB endpoint, which succeeds authentication (because of the last rule) is in the log just once if the network connection is maintained. So let's assume a printer, which is never disconnected from the network. It will be authenticated initially and then never again.

It will be very hard in the future to find out these clients (e.g. log retention and log purging). Furthermore, if not carefully designing your periodic RADIUS accouting configuration, this endpoint will even be deleted in the live sessions after five days. So there's no chance to find out that this client even exists.

I guess it's not common practice to send a reauthentication timeout to MAB clients to enforce a new a authentication regulary, right?

Of course another benefit is, that not desired clients will consume another base- and plus- license with a "permitall" policy

Don't get me wrong guys, I like the whole system and all and it's working very good. But there are so many pitfalls and dependencies, which are not documented (e.g. that the WebAuth Rule at the end is crucial that everything works smoothly).

If my described workaround (permit access with limited access at the end of the authorization policy) is the recommended way to go, why would one need the static port ACL on each switch? In this case the port ACL would not be needed, because it will be immediately replaced (merged) with the dACL, which is defined in the last authorization rule.

Or is the default Port ACL intended for the short time (authentication latency) between the connection of the port and the succeded authorization?

You could configure the switch port even closed mode, if utilizing a WebAuth Policy at the end

[howon]

Yes, you raise valid points. In the end it would be nice to be able to profile any endpoints on the network that connects on the wired port regardless of success or failure. That way you can get visibility without having to have proper authentication in place which may be the case for initial setup. However, I don't believe the workaround requires too much effort either.

In terms of static port ACL, it is optional and not needed with later versions of IOS as recent IOS allows one to push dACL without existing port ACL. The intent is to provide minimal access for profiling to take place.

[jsteffensen]

I totally agree with johannes.luther.

It is totally nonsense to only be able to profile devices which are granted access to the network.

Are there any plans to change the behaviour of the device-sensor so that the device-sensor information also can be sent in the Radius Authentication request and not only Accounting packet from the NAS?

I mean currently most switches are able to include VSA information in both AUTH as well as ACC Request...

The workaround Cisco Propose (permitting all devices - and blocking network access using all or whatever) is definitely a NO-GO in environments which requires some kind of security. In these environments you abseloutel WOULD like to see the "Denied" access - in your logs.

(this poposal is like permitting all packets through a firewall to avvoid all the "unnecessary logs" and then do policy based routing to a blackhole to all unwanted traffic that should be dropped.... - and how stupid is that.....)

Best Regards

Jarle

[shamax_1983]

I too agree with both @Johannes Luther and @jsteffensen.

After weeks of trying, I realized that the switch needs an "Access-Accept" before it can send the profiling info to ISE. I am using ISE 2.3 (patch4) with a switch in IOS-XE 16.3.7. The behaviour mentioned above seems to have not changed and it is pretty stupid that Cisco thinks this is the more sensible way to do this.

When Cisco pitch this idea (Using profiling for added security), they always seem to imply that you can use profiling to Accept/Deny network access to a particular device primarily based on its profile info, without mentioning this "hack/trickery" that should be in place to make it work. Which sounds exactly like what @jsteffensen mentioned, allowing all through the FW and trying to drop some using PBR.

Hopefully, Cisco will change this behaviour sooner rather than later and/or most importantly, update the docs so it clearly states what is required to make it work.

[Johannes Luther]

Especially if the solution is quite simple.

Send the RADIUS VSAs for profiling along with the RADIUS-REQUEST of switch. This way there is no need to rely on the RADIUS accounting messages, which are only generated for successful AuthZ sessions.

[howon]

Please note that profiling is passive in nature, so it relies on endpoint to take certain actions on the network in order for the network to collect enough information about an endpoint and profile them as certain device type. The more information ISE receives, better certainty ISE can categorize the device with. For instance, getting MAC address provides basic OUI, but looking at DHCP conversation tells more about the endpoint. DHCP also provides IP to MAC binding, which opens door to other L3+ based probes such as HTTP (browser user agent strings), NMAP, AD, DNS, etc. Notice that unless some network access is provided, the endpoint will not be able to provide useful data beyond the MAC address.

This brings us to the answer on why RADIUS authentication is not a good vehicle for profiling purpose. In general, 802.1X or MAB is done prior to providing network access so there aren’t anything to send at this stage aside from the MAC address. Consider DHCP, for the device sensor to learn all the DHCP options, Class ID, Client ID, and assigned IP, it requires full DHCP transaction to complete, which cannot be done prior to providing network access.

Only exception to the above would be CDP and LLDP information, which is available prior to successful authentication, but the network devices are not enabled to send it with RADIUS authentication nor accounting (due to CSCux48616) currently.

[Johannes Luther]

Hi,

of course this is correct, but authentication in the wired network is not a "one shot and forget".

If MAB authentication fails, the process is restarted periodically (e.g. every 30 seconds), depending on the NAD configuration.

I agree, that on the initial authentication request, the network device and the ISE does not have any useful profiler information.

However on the second and subsequent authentication requests, there is a high chance, that there is additional information (e.g DHCP). So I guess that including the device-sensor RADIUS VSAs additionally in authentication packets, won't hurt anyone :)

[howon]

I am not sure how authenticating repeatedly will change anything if the endpoint is still being denied. Also not sure on how you are suggesting to force the endpoint to try to get an IP address with DHCP without giving some network access.

[Johannes Luther]

Correct, this is why the typical config is:

• Authentication mode: open
• IP Access Control Lists (ACLs) will be used to control pre-authentication and post-authentication network access

This is defined as "low impact mode"

Please see the document for more information:

https://community.cisco.com/t5/security-documents/cisco-ise-wired-access-deployment-guide/ta-p/3641515

[howon]

When 'authentication open' is used (Which is the case for either monitor or low-impact mode), you are essentially providing network access prior to authentication and also when the authentication fails. I thought the ask for including the profiling information during RADIUS authentication was to avoid proving network access prior to successful authentication and still gain profiling information?

Now, if we are going back to the original posting, I understand that you didn't want to send down Access-Accept from the ISE, but as I noted in the initial replies, there is not much gain from sending Access-Reject from ISE, since you are allowing some network access be it via switch policy or ISE policy in the case of monitor/low-impact mode. However, there are much to gain if Access-Accept is sent which includes, device profiling data, session management from ISE which provides CoA, wired web authentication, less authentication failed logs.

[Johannes Luther]

Yes, with authentication open and a pre-auth ACL is in place there is selective network access prior authentication (based on the pre-auth ACL content).

Let's assume the last line in the ISE authorization policy is "DenyAccess" as the default action. So unknown MAB devices fail authentication ==> Device Sensor is not functional.

Of course a workaround would be to PermitAccess with dACL as the default action, but

a) All clients hitting this rule are requiring one or multiple ISE licenses
   ==> All undesired clients are consuming a license

b) I want to have failed attempts (RED entries) for clients that are not allowed in my network. The authentication has failed and I want to see this is the ISE logs and on the switches. Only legetimate clients get a green log entry and are allowed to have a authentication session.

What bugs me is: Using the DHCP or SNMP probe, it does not matter whether the clients as failed or succeeded authentication. The device sensor should provide the same functionality, but it doesn't (which is a shame) :)

[howon]

a) Assuming no guest access is used, 99.9% of the devices connecting to the wired network is probably customer's and needs to be profiled and categorized. 0.1% may be unwanted devices, which customer still would like to gain visibility for. It is cost vs. benefit but ultimately customer's to decide.

b) In general customers would create a AuthZ profile that can easily be identified like 'Limited_Access' or 'Quarantined' for failed authentication. This can be used on ISE logs or SIEM to filter out the events. I understand that colors are nice, but so much to gain with sending permit. Again, customer's choice depending on how important it is.

[paul]

Completely agree. Sending a reject is ultimately going to hamper your wired ISE install and make it less effective. IOS device sensor is just one piece of the profiling puzzle. If you don't let the device on the network you can't NMAP or SNMP scan it.