Limitations of IDP

On an SRX Series or a J Series device, when defining IDP, be aware of the following limitations:

• On SRX3400, SRX3600, SRX5600, and SRX5800 devices, application-level distributed denial-of-service (application-level DDoS) detection does not work if two rules with different application-level DDoS applications process traffic going to a single destination application server. When setting up application-level DDoS rules, make sure you do not configure rulebase-ddos rules that have two different application-ddos objects when the traffic destined to one application server can process more than one rule. Essentially, for each protected application server, you have to configure the application-level DDoS rules so that traffic destined for one protected server only processes one application-level DDoS rule.

  Note: Application-level DDoS rules are terminal, which means that once traffic is processed by one rule, it will not be processed by other rules.

  The following configuration options can be committed, but they will not work properly:

  source-zone	destination-zone	destination-ip	service	application-ddos	Application Server
  source–zone-1	dst-1	any	http	http-appddos1	1.1.1.1:80
  source-zone-2	dst-1	any	http	http-appddos2	1.1.1.1:80

• On SRX3400, SRX3600, SRX5600, and SRX5800 devices, application-level DDoS rulebase (rulebase-ddos) does not support port mapping. If you configure an application other than default, and if the application is from either predefined Junos OS applications or a custom application that maps an application service to a nonstandard port, application-level DDoS detection will not work.

  When you configure the application setting as default, intrusion detection and prevention (IDP) uses application identification to detect applications running on standard and nonstandard ports; thus, the application-level DDoS detection would work properly.

• On SRX Series and J Series devices, IP actions do not work when you select a timeout value greater than 65,535 in the IDP policy.
• On SRX210, SRX240, and SRX650 devices, the maximum number of IDP sessions supported is 16,000.
• On SRX Series devices, all IDP policy templates are supported except All Attacks. There is a 100-MB policy size limit for integrated mode and a 150-MB policy size limit for dedicated mode, and the current IDP policy templates supported are dynamic, based on the attack signatures being added. Therefore, be aware that supported templates might eventually grow past the policy-size limit.

  On SRX Series devices, the following IDP policies are supported:

  • DMZ_Services
  • DNS_Service
  • File_Server
  • Getting_Started
  • IDP_Default
  • Recommended
  • Web_Server
• IDP deployed in both active/active and active/passive chassis clusters has the following limitations:
  • No inspection of sessions that fail over or fail back.
  • The IP action table is not synchronized across nodes.
  • The Routing Engine on the secondary node might not be able to reach networks that are reachable only through a Packet Forwarding Engine (PFE).
  • The SSL session ID cache is not synchronized across nodes. If an SSL session reuses a session ID and it happens to be processed on a node other than the one on which the session ID is cached, the SSL session cannot be decrypted and will be bypassed for IDP inspection.
• IDP deployed in active/active chassis clusters has a limitation that for time-binding scope source traffic, if attacks from a source (with more than one destination) have active sessions distributed across nodes, the attack might not be detected because time-binding counting has a local-node-only view. Detecting this sort of attack requires an RTO synchronization of the time-binding state that is not currently supported.