An IDS must be aware of all of the possible encodings that its end hosts accept in order to match network traffic to known-malicious signatures.
To detect buffer overflow attacks, an IDS might look for the evidence of NOP slides which are used to weaken the protection of address space layout randomization.
One evasion technique is to pause between sending parts of the attack, hoping that the IDS will time out before the target computer does.
If the IDS doesn't handle these protocol violations in a manner consistent with its end hosts, it is vulnerable to insertion and evasion techniques similar to those mentioned earlier.
[3] Attacks which are spread out across a long period of time or a large number of source IPs, such as nmap's slow scan, can be difficult to pick out of the background of benign traffic.
Packets captured by an IDS are stored in a kernel buffer until the CPU is ready to process them.
If the CPU is under high load, it can't process the packets quickly enough and this buffer fills up.
[1][2] This algorithmic complexity attack can overwhelm the IDS with a relatively small amount of bandwidth.
[1] An IDS that also monitors encrypted traffic can spend a large portion of its CPU resources on decrypting incoming data.
[3] In order to match certain signatures, an IDS is required to keep state related to the connections it is monitoring.
For example, an IDS must maintain "TCP control blocks" (TCBs), chunks of memory which track information such as sequence numbers, window sizes, and connection states (ESTABLISHED, RELATED, CLOSED, etc.
[3] Once all of the IDS's random-access memory (RAM) is consumed, it is forced to utilize virtual memory on the hard disk which is much slower than RAM, leading to performance problems and dropped packets similar to the effects of CPU exhaustion.