Support for HTTP/2 Traffic Inspection

Introduction

Intrusion Detection and Prevention (IDP) now supports inspection of HTTP/2 traffic. IDP can identify HTTP/2 application traffic and select and apply the appropriate attack signatures during traffic inspection. This support enhances visibility into modern web application traffic and improves detection of threats carried over HTTP/2 connections.

You can apply IDP inspection to HTTP/2 traffic by treating each HTTP/2 connection as a connection session that multiplexes multiple stream-level sessions. IDP inspects each stream similarly to HTTP/1.1 and also evaluates connection-level HTTP/2 protocol context (such as frame length, type, flags, and stream identifiers). This additional context supports custom signatures and connection-level session anomaly detection, for example, detection of anomalies such as invalid frame sizing, unknown frame types, improper flags, and malformed RST_STREAM or PUSH_PROMISE behavior.

You configure HTTP/2 inspection under the existing HTTP service model, reuse predefined HTTP/2 attack signatures, and enforce actions using HTTP/2 semantics. Connection-oriented actions close or drop the connection session (affecting all streams). To ensure accurate policy selection for HTTP/2 traffic, match the correct application (such as the dynamic application junos:HTTPV2). This action enables IDP to classify the parent connection properly and apply the intended policy.

Detection of Attacks on HTTP/2 Contexts

IDP enables signature authors to detect HTTP/2–specific behaviors that are not visible in HTTP/1.1. You can bind custom signatures to the HTTP application and match the following HTTP/2 protocol contexts:

• http2-frame-length—Match on the payload length of a frame to catch long frames.
• http2-frame-type—Match on the frame type (for example, SETTINGS, HEADERS, RST_STREAM, PUSH_PROMISE) to constrain behavior by stream state and phase.
• http2-frame-flag—Match on flags that modify frame semantics (for example, END_STREAM, END_HEADERS).
• http2-stream-id—Scope detection to individual stream identifiers or classes of stream IDs.

By combining these contexts with standard HTTP request/response elements, you can target protocol misuse and application-layer indicators simultaneously.

Detection of HTTP/2 Anomalies

IDP detects and reports malformed or noncompliant HTTP/2 behavior on the connection-level session. Anomaly detections include:

• INVALID_FRAME_LENGTH—A frame length that violates the HTTP/2 specification or peer SETTINGS.
• INVALID_MAX_FRAME_SIZE—A peer negotiates or uses a maximum frame size outside the allowed range.
• INVALID_FRAME_TYPE—A frame type is invalid in the current stream or connection state.
• UNKNOWN_FRAME_TYPE—A frame type is not recognized by the parser.
• UNUSED_FLAGS—Reserved or undefined flags are set on a frame type.
• INVALID_RST_STREAM—RST_STREAM is sent for an idle or closed stream.
• INVALID_PUSH_PROMISE—A server sends PUSH_PROMISE when server push is not enabled or violates stream semantics.

Anomaly events are raised against the connection session, so operators can see connection-level integrity and protocol misuse trends.

Support for Existing HTTP/2 Attack Signatures

Existing predefined HTTP/2 attack signatures continue to function after the internal mapping to HTTP/2 protocol contexts. Examples include:

• HTTP2:APACHE-SETTING-DNS
• HTTP2:MS-IIS-RES-LOOP-DOS

This continuity minimizes operational change. You don’t need to re-author or reassign policy entries to retain coverage.

Apply Actions on the Connection-Level Session

When a rule matches on an HTTP/2 stream, IDP applies the configured action at the appropriate level:

• Stream-level semantics—For a stream-scoped drop, the device sends RST_STREAM for the affected stream while keeping other streams in the connection-level session active.
• Connection-level semantics—For drop-connection, close-server, or close-client-and-server, the device terminates the connection session and removes all stream sessions.
• IP-based semantics—For ip-action, the device enforces the action at the source IP level, not per stream. Because it targets the source IP address, it is not stream-aware. When an ip-action is triggered, the device blocks creation of new connection sessions from that source IP for the configured timeout period. Streams already running under the current connection session—the session on which the attack was detected—continue unaffected because they remain within that established connection session.

You can contain an offending stream without disrupting unrelated work on the same connection, and escalate to connection termination when the signature or anomaly warrants it.

To classify HTTP/2 flows in a security policy, you can reference the dynamic application junos:HTTPV2 in the policy’s application match. With AppID enabled and signatures current, you can either reference junos:HTTPV2 directly in the policy or add it to an application set and reference that set in the policy. The policy action then applies to traffic that AppID recognizes as HTTP/2.