Hash Table Protection Against DoS Attacks Using Secure Hashing

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current data transport protocols are vulnerable to denial of service attacks that flood lookup tables with spoofed connection identifiers, leading to prolonged lookups and performance degradation of local servers, as the hash functions used are simple and insecure.

Innovation Solution

Implementing a cryptographically secure hash for packets from unverified remote entities to prevent denial of service attacks on lookup tables, while maintaining performance for verified entities by using separate tables and secure hashing only for unverified entities, thereby preventing attackers from flooding the system.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Speed

If a simple hash function is used for lookup tables, then the performance and speed of packet processing is improved, but the system becomes vulnerable to denial of service attacks with spoofed connection identifiers

Engineering Contradiction:
Improvepacket processing speedVSAvoidprotection against DoS attacks
Core Design Contradiction:
SpeedVSReliability

Solution Approach 1:

The patent applies different hash function qualities to different packet types: simple hash functions are used for verified packets to maintain speed, while cryptographically secure hash functions are used for unverified packets to prevent DoS attacks. This local differentiation resolves the contradiction by optimizing for the appropriate quality level in each context.

Inventive Principle:
Principle #3Local quality

2Reliability

If a cryptographically secure hash function is used for all packets, then protection against denial of service attacks is improved, but the CPU cycle consumption increases and server performance degrades

Engineering Contradiction:
Improveprotection against DoS attacksVSAvoidCPU cycle consumption
Core Design Contradiction:
ReliabilityVSUse of energy by moving object

Solution Approach 1:

The patent applies the expensive cryptographic hash function only partially - specifically only to packets from unverified remote entities - rather than to all packets. This partial application provides sufficient protection against DoS attacks while minimizing unnecessary CPU consumption for verified traffic.

Inventive Principle:
Principle #16Partial or excessive action

Solution Approach 2:

The system performs preliminary verification of remote entities through handshakes before establishing trusted connections. This preliminary action determines which packets require expensive cryptographic hashing, allowing the system to prepare and categorize traffic before the main processing bottleneck occurs.

Inventive Principle:
Principle #10Preliminary action

3Reliability

If separate lookup tables are maintained for verified and unverified entities, then the effectiveness of DoS protection is improved, but the system complexity increases

Engineering Contradiction:
ImproveDoS protection effectivenessVSAvoidlookup table structure
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent segments the lookup table into two separate structures: one for verified remote entities and one for unverified entities. This segmentation isolates the expensive cryptographic hashing operations to only the unverified table, maintaining DoS protection effectiveness while managing system complexity through structured organization.

Inventive Principle:
Principle #1Segmentation

Data Source

PatentUS7634655B2Efficient hash table protection for data transport protocols
Publication Date: 2009.12.15 MICROSOFT TECHNOLOGY LICENSING LLC
  • US7634655B2 patent drawing
  • US7634655B2 patent drawing
  • US7634655B2 patent drawing

AI summary

The present invention protects against denial of service attacks on lookup or hash tables used to store state information for data transfer protocols used to transfer data between two host computers. Two hash tables are provided for holding state information, one for verified remote entities (i.e., those where the remote local address can be traced to a host), and one for unverified entities. A cryptographically secure hash is applied to packets from unverified remote entities, since these are the most likely to attempt attacks on the hash tables. The performance of the local server for packets from verified remote entities, however, is maintained.