Recommended values for synflood and rate limiting

[JP_Berlin]

Hi community,

I have two questions regarding the ISE CLI commands synflood-limit and rate-limit:

1. I do understand the use case for synflood-limit since a high number of TCP-SYN is a clear indication for a malicious attack. But what about the use case for rate-limit? ISE inter-node communication? Communication with integrated 3rd party devices (for example through pxgrid)? Or even access to the ISE portals (Guest, Sponsor...)? I would appreciate if someone shed some light on this.
2. And finally I am looking for recommended values for the synflood-limit and rate-limit commands (in terms of packets per second). In other words: are there any guidelines on how to avoid an impact on ISE operations.

Cheers!

[hslai · Accepted solution]

Such settings could impact authentication TPS; especially EAP-TLS. Please use them with cautions.

The command synflood-limit takes only a numeric value as the argument so it applies to all TCP attempts. A similar command "conn-limit" takes ip and port arguments so give us more choices if we are to implement sync flood protection on TCP connections. The other command "rate-limit" also take ip and port arguments but it applies to all TCP/UDP/ICMP.

[drivera_]

Hello, hslai

I would like to know if maybe you know what is it the recommended rate for configuring with the command "rate-limit" for TCP/UDP/ICMP.  Right now I'm hardening an ISE deployment, and I've been following this guide https://community.cisco.com/t5/security-documents/ise-security-best-practices-hardening/ta-p/3640651 but I don't know what value the rate limit has to take. 

Thank you so much in advance.

[DurzoBlint]

Quite dissapointed that this post was done way back in 2019 with no answer other than "be careful".  I am also in the process if hardening our ISE environment and there is no requirement within our guidelines other than it needs to be set.

[Cristian Matei]

Hi,

     Such values (including @Arne Bier mentioned storm-control values) are specific to each environment, there is NO good value, there is NO recommended value, there is just a working value which is specific to each environment and can only be validated during some sort of trial & error once infra is in its final state; in general, when setting these values, as you want to avoid total failure, you take into account worst-case scenario, like for example when all devices would need to speak with ISE at ~ the same time.

Best,

Cristian.

[Arne Bier]

I agree that the feature could be explained a bit more in detail - I have never touched those values, but only because I don't know what a reasonable value is.  When comparing to switch feature Broadcast/Multicast Storm protection, I once had bad experience by setting a threshold value too low, that caused legitimate multicast traffic to err-disable a switch port. That's why the phrase "be careful" is quite apt, in my opinion.  There is no golden value to set this at.

The ultimate test would be to throw some SYN floods at ISE, using a packet generator, to see what happens. Cisco has the T-Rex which you could install on a separate host and then throw some SYN packets at ISE. If you're more comfortable in Windows, Ostinato is a great tool - I think it also has a trial period.