Asymmetric Application Identification on Switches
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In distributed hardware-based switching platforms, existing systems face challenges in performing large-scale application identification due to the risk of denial-of-service attacks and the need for multiple IDS/IPS engine instances to handle both sides of traffic flows, which is inefficient and requires unnecessary communication and state creation.
Innovation Solution
The system selects an IDS/IPS engine during the TCP session establishment using the time spent on the three-way TCP handshake, allowing subsequent data packets to be forwarded to the selected engine, thereby supporting multiple engine instances and reducing unnecessary communication and state creation.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If copies of all new flows are sent to IDS/IPS engines at the ingress interface, then application identification can be performed, but it may lead to denial-of-service attacks and requires multiple engine instances
Solution Approach 1:
The patent applies preliminary action by selecting an IDS/IPS engine instance during the TCP three-way handshake phase, before actual data traffic flows. The ingress interface identifies the client IP and port combination during handshake and pre-assigns an engine instance, so that when real traffic arrives, the selection is already complete. This avoids the need to handle all new flows immediately and reduces the burden on IDS/IPS engines.
Solution Approach 2:
The patent extracts the engine selection logic from the data traffic processing path and places it in the control plane during TCP handshake. By separating the selection decision (made during handshake) from the data forwarding path, the system avoids sending copies of all data flows to IDS/IPS engines, reducing unnecessary processing and the risk of denial-of-service attacks.
2Adaptability or versatility
If multiple IDS/IPS engine instances are deployed to handle both sides of traffic flows, then application identification is supported, but unnecessary communication and state creation occur
Solution Approach 1:
The patent applies asymmetry by treating the client-to-server and server-to-client directions differently. During TCP handshake, the system selects an engine instance based on client characteristics (IP and port). Once selected, both directions of traffic for that TCP session are forwarded to the same engine instance. This asymmetric approach (selecting based on one direction's characteristics but handling both directions) eliminates the need for symmetric handling that would require separate engine instances for each direction, reducing communication overhead and state management complexity.
3Measurement precision
If all traffic flows are forwarded to IDS/IPS engines for inspection, then comprehensive application identification is achieved, but system efficiency decreases due to DoS risk
Solution Approach 1:
The patent applies partial action by selectively forwarding only established TCP session traffic to IDS/IPS engines, rather than inspecting all traffic flows. The system uses the TCP handshake phase to identify and select engine instances, then forwards subsequent data packets for those specific sessions. This partial inspection approach maintains application identification accuracy for relevant traffic while avoiding the overhead of inspecting all flows, thus preserving system efficiency and reducing DoS risk.
Data Source
AI summary
A first ingress interface on a switch receives a first control packet for establishing a Transmission Control Protocol (TCP) session and selects a first engine running on a first line card in the switch. A second ingress interface receives a second control packet and selects the same first engine. Data associated with the TCP session received by the first or second ingress interface subsequent to establishing the TCP session is to be forwarded to the first engine. The first ingress interface receives a third control packet and sends, to the selected first engine, a notification indicating the TCP session which is to be tracked. The first or second ingress interface receives a fourth packet with a payload associated with the TCP session and forwards, to the selected first engine, a copy of the fourth packet, thereby facilitating a plurality of engine instances to support application identification.