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

[paul]

In any mode you should never be rejecting anything connecting to the wired network.  I also never do low impact mode as then you have to deal with the silly preauth ACL if ISE is unavailable.  Your default rule for MAB when not in monitor mode in my opinion should be a limited access DACL that allows ISE to still talk to the endpoint for profiling reasons and optionally redirect the user to a portal that says they have been denied by security and to call the help desk.

In 75+ installs I have never rejected any wired MAB authentications nor implemented low impact mode.

[Johannes Luther]

Ok ... maybe I'll try this in my next deployments.

However in the concept "static pre-auth port ACL" vs. "limited access dACL" theres one litte thing that bugs me, which is TCAM consumption (especially if using platforms with very small TCAM like 2960-X).

Assuming a Cat. 2960-X the lanbase-default SDM template, which provides space for ~600 not aggregrated lines of dACL (on a 48 port switch ~12 lines avergage per port). However ACEs can be aggregrated to require less TCAM consumption.

e.g. the following two ACE only consume one TCAM slot:

permit udp any host 192.168.1.1 eq 22

permit udp any host 192.168.1.1 eq 23

Because the source portion of a dACL is rewritten with the actual IPv4 of the client, the default "limited access" dACL consumes typically more TCAM space, because the entries cannot be aggregrated in most cases.

So the default static port ACL (enrolled with network automation tools) saves some TCAM and leaves more ACL lines for the "per device type" dACLs. I personally think, that 12 lines (average) per port on an 48 port switch is not that much :)

... But who's using 2960-X anyway ;)