cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
645
Views
0
Helpful
3
Replies

re-validating previously profiled ISE endpoints

andrewswanson
Level 7
Level 7

Hello

I was having a look at MAC spoofing with ISE 2.1.0.474

I am using RADIUS/SNMP trap and query and DHCP probes. A Cisco 7911 phone correctly gets profiled as "Cisco-IP-Phone-7911". The endpoint in ISE shows all the correct cdp/lldp/dhcp details

When I connect my windows laptop (spoofing the phones MAC), the laptop is authenticated as the phone. The endpoint is still profiled as "Cisco-IP-Phone-7911" - the endpoint shows the correct dhcp details for the laptop but retains the cdp/lldp details of the phone previously profiled. I checked the NAD and the device-sensor cache has no cdp/lldp details for the connected laptop and device-sensor accounting sends only the laptop dhcp tlv's to ISE.

If I delete the endpoint from ISE and connect my laptop (again spoofing the phones MAC), ISE correctly profiles the laptop as "Microsoft-Workstation"

When I disconnect the laptop and reconnect the phone, ISE re-profiles the endpoint as a "Cisco-IP-Phone-7911" based on the newly learnt cdp/lldp info.

ISE can learn new endpoint details through the probes and re-profile an endpoint as shown above. Am I right in saying that ISE won't re-profile an endpoint based on the fact that some attributes (e.g. cdp/lldp) have stopped appearing - only when new attributes are learnt?

Thanks
Andy

1 Accepted Solution

Accepted Solutions

nspasov
Cisco Employee
Cisco Employee

Hello Andy-

What you are experiencing is correct and expected behavior with the current mechanics of ISE. There is an enhancement request that was put in place a while back but it hasn't seen much traction:

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCur48184

The only time a device would move from one profile group to another is when a profiling rule with higher Certainty Factor is hit. For instance, if you create a custom rule with CF of 100 and if that rule is hit then a profiled device will never move to another rule that has CF that is <= to 100. 

As you can tell, profiling is not bullet-proof. This is why it is best practice to limit the network access for profiled devices. For instance, IP Phones should only need access to the voice subnets and the PBX, Printers should only need access to print servers on specific ports, etc

I hope this helps!

Thank you for rating helpful posts!

View solution in original post

3 Replies 3

nspasov
Cisco Employee
Cisco Employee

Hello Andy-

What you are experiencing is correct and expected behavior with the current mechanics of ISE. There is an enhancement request that was put in place a while back but it hasn't seen much traction:

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCur48184

The only time a device would move from one profile group to another is when a profiling rule with higher Certainty Factor is hit. For instance, if you create a custom rule with CF of 100 and if that rule is hit then a profiled device will never move to another rule that has CF that is <= to 100. 

As you can tell, profiling is not bullet-proof. This is why it is best practice to limit the network access for profiled devices. For instance, IP Phones should only need access to the voice subnets and the PBX, Printers should only need access to print servers on specific ports, etc

I hope this helps!

Thank you for rating helpful posts!

Thanks Neno - I'll contact TAC and add some weight to the enhancement request. Once we are out of Monitor mode the key thing will be strict authorization for ISE profiled devices.

Cheers

Andy

Great! Thanks Andy! Let us know what Cisco/TAC has to say about it :)

Neno