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

[andrewswanson]

Hi Johannes

I agree with you regarding the documentation for device-sensor (see below). When I started looking at ISE a while back, I thought device sensor would be an alternative to RADIUS/DHCP probes.

http://www.cisco.com/c/en/us/support/docs/security/identity-services-engine/200292-Configure-Device-Sensor-for-ISE-Profilin.html#anc3

Unfortunatley, if a device isn't authentictaed, no accounting packets are sent so device sensor is no good on its own for profiling new devices.

I did use your "workaround" on a monitor mode deployment to authenticate all devices so that device sensor would kick in.

I found that with ISE 2.1 and earlier I could spoof the mac of a profiled device. An example would be a Cisco phone profiled via CDP attributes - I could spoof this phone's mac on my windows laptop and ISE would authenticate it ok (even though the original phone's CDP attributes were missing). I think that with 2.2's "Detect Anomalous Behavior of Endpoints", device senor could be used to confirm a device's profiling attributes after authentication:

http://www.cisco.com/c/en/us/td/docs/security/ise/2-2/release_notes/ise22_rn.html#pgfId-676464

Perhaps device sensor's main strength is to confirm a profiled device's attributes haven't changed rather than to profile new devices.

hth
Andy

[agrissimanis]

Hi Johannes,

I have been trying to find the best way how to deal with this as well. I ended up adding another Authorization rule, just before the last "Deny all", which looks at the MAC OUI of the device and if it is one of our IP Phones or Access points then issues "Access Accept", but with a restrictive dACL (basically the same as my ACL-DEFAULT). That then triggers the Device Sensor to send the additional CDP/LLDP attributes, ISE receives them, issues CoA, and the endpoint hits the correct rule next time which sits above the "profiling helper rule".

Our environment doesn't have many types of devices that need to be profiled using CDP/LLDP and  we also still use the DHCP sensor so at the moment this works fine.

The advantage of this method is that you still see red entries in the logs, for these endpoints that shouldn't be on the network, but  of course scalability is an issue, because you have to modify that rule to include potential new types of devices which require device sensor data in order to be profiled correctly.

Regards,

Agris