Intermediary Device for DDoS Protection via Application-Layer Verification

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Servers providing peer-to-peer network services using TCP are vulnerable to Denial of Service (DoS) attacks, particularly Distributed Denial of Service (DDoS) attacks, where attackers poison index tables, leading to resource exhaustion and unintentional participation of innocent clients in SYN flood attacks, which existing firewalls struggle to mitigate effectively.

Innovation Solution

A network device is introduced between clients and servers, equipped with a processor and memory to intercept and analyze synchronization messages, generate SYN/ACK packets with signatures, and provide application-specific ACK messages to verify the authenticity of client requests, thereby protecting the server from DDoS attacks by ensuring only compatible service requests are forwarded.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If a firewall uses SYN cookie technique to protect servers from SYN flood attacks, then the server is protected from resource exhaustion, but the firewall cannot distinguish between legitimate clients and spoofed IP addresses in poisoned index tables, allowing DDoS attacks to proceed

Engineering Contradiction:
Improveserver protection from SYN floodVSAvoidability to distinguish legitimate clients from attackers
Core Design Contradiction:
ReliabilityVSAdaptability or versatility

Solution Approach 1:

The patent introduces an intermediary device positioned between the firewall and the server. This intermediary performs application-layer inspection of TCP connections, examining the application data payload to verify it matches the expected application protocol. The intermediary acts as a mediator that filters malicious traffic before it reaches the server, combining network-layer protection with application-layer verification to resolve the contradiction between protecting against SYN floods and distinguishing legitimate clients.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent implements preliminary verification of application data during the TCP three-way handshake process. Before fully establishing a connection to the server, the intermediary device checks whether the application layer data in the TCP stream is consistent with the expected application protocol. This preliminary action prevents malicious connections from reaching the server, addressing both SYN flood protection and client authentication.

Inventive Principle:
Principle #10Preliminary action

2Ease of operation

If the firewall permits TCP connections with correct SYN cookie signatures, then legitimate connections are established, but spoofed connections from poisoned index tables also reach the server causing DDoS attacks

Engineering Contradiction:
Improvelegitimate connection establishmentVSAvoidspoofed connections from poisoned index tables
Core Design Contradiction:
Ease of operationVSObject-affected harmful factors

Solution Approach 1:

The patent segments the connection verification process into two independent layers: network-layer verification (SYN cookie validation) and application-layer verification (protocol consistency check). The intermediary device performs application-layer segmentation by inspecting the data payload separately from the TCP handshake, allowing legitimate connections to pass through while blocking spoofed connections that lack proper application data.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent changes the verification parameter from purely network-layer (IP address and SYN cookie) to include application-layer parameters (protocol-specific data patterns). By examining application data characteristics such as command structures and data formats, the system can distinguish legitimate clients from attackers even when they present valid SYN cookies, resolving the contradiction between ease of connection and security.

Inventive Principle:
Principle #35Parameter changes

3Productivity

If the server processes all incoming TCP connections, then service availability is maintained, but resource exhaustion occurs due to malicious traffic from DDoS attacks

Engineering Contradiction:
Improveservice availabilityVSAvoidresource exhaustion from malicious traffic
Core Design Contradiction:
ProductivityVSLoss of energy

Solution Approach 1:

The patent implements preliminary filtering of malicious traffic at the intermediary device before connections are established with the server. By verifying application protocol consistency during the TCP handshake, the intermediary prevents resource-intensive processing of malicious connections at the server, maintaining service availability for legitimate users while avoiding resource exhaustion from DDoS attacks.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The intermediary device serves as a protective mediator that absorbs and filters malicious traffic, preventing it from reaching the server. This intermediary layer maintains service availability by ensuring only legitimate connections consume server resources, while malicious traffic is blocked before exhausting server capacity.

Inventive Principle:
Principle #24Intermediary (Mediator)

Data Source

PatentUS8650631B2Server protection from distributed denial of service attacks
Publication Date: 2014.02.11 JUNIPER NETWORKS INC
  • US8650631B2 patent drawing
  • US8650631B2 patent drawing
  • US8650631B2 patent drawing

AI summary

A network device connects between a client and a server. The network device is configured to store information regarding an application operating on the server; receive a first message, from the client, intended for the server; generate a second message in response to the first message; send the second message to the client; receive a third message from the client; generate, based on the information regarding the application on the server, a fourth message, that includes the information regarding the application operating on the server; send the fourth message to the client; receive a service request from the client in response to the fourth message; and establish, based on the service request, a connection between the client and the server.