Packet Header Token Injection for Trusted Flow Filtering
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing packet filtering systems are computationally expensive and vulnerable to attackers mimicking trusted packets due to lack of visibility into higher layer trust mechanisms, necessitating a more efficient and secure filtering method.
Innovation Solution
Inserting a token into a cleartext header field of network packets, calculated from a secret shared between sender and receiver, allowing packet filters to validate the token in initial packets and apply the same trust decision to subsequent packets without decryption, and rotating the token to prevent spoofing.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If packet filtering is performed at higher layers (application layer or TLS layer) to gain visibility into trust mechanisms, then filtering accuracy and security are improved, but computational cost increases significantly due to decryption and deep packet inspection requirements
Solution Approach 1:
The patent extracts the trust verification mechanism from the higher-layer application/TLS processing and moves it to the lower-layer packet filtering stage. A token representing trust status is extracted from higher-layer trust establishment and embedded in the packet header, allowing packet filters at lower layers to verify trust without performing expensive decryption or deep inspection operations.
Solution Approach 2:
The patent introduces a token as an intermediary element that carries trust information from higher-layer trust establishment mechanisms to lower-layer packet filters. This token acts as a mediator that enables cross-layer trust verification without requiring the lower-layer filter to perform the computationally expensive tasks of the higher layers.
2Productivity
If packet filtering is performed at lower layers (IP header or TCP/UDP header) to reduce computational cost, then processing efficiency is improved, but visibility into higher layer trust mechanisms is lost
Solution Approach 1:
The patent segments trust verification from the main packet processing flow. Trust status is determined at higher layers and segmented into a separate token that is embedded in the packet header. This allows lower-layer packet filters to efficiently process packets based on the pre-computed token without needing to perform complex trust verification, thereby maintaining both efficiency and trust visibility.
Solution Approach 2:
The patent performs trust verification as a preliminary action at higher layers before packets reach the lower-layer packet filter. The trust status is determined in advance and encoded into a token that is placed in the packet header, allowing subsequent packet filtering to proceed efficiently without repeating the trust verification process.
3Reliability
If tokens are placed in all packets from trusted senders to ensure continuous verification, then security against spoofing is improved, but network overhead increases
Solution Approach 1:
The patent implements periodic token refreshment rather than continuous verification. Tokens are placed in packets periodically (e.g., in initial packets or at flow boundaries) rather than requiring verification in every single packet. This periodic approach maintains security while reducing the overall quantity of verification operations and associated network overhead.
4Reliability
If tokens are validated in every packet to prevent spoofing, then security is improved, but processing time increases
Solution Approach 1:
The patent performs token validation as a preliminary action in initial packets or at flow boundaries rather than in every subsequent packet. Once trust is established in the initial packet, the packet filter can efficiently process subsequent packets in the same flow without repeating the full validation process, thereby maintaining security while minimizing processing time.
Solution Approach 2:
The patent implements periodic validation rather than continuous validation of every packet. Tokens are validated at periodic intervals (e.g., at the start of flows or at configured intervals), which maintains security against spoofing while significantly reducing the total processing time compared to validating every single packet.
Data Source
AI summary
A class of network packets can be labeled by inserting a token into a packet header field. Preferably the header field is available to intermediary devices in cleartext. A packet filter examines the packets, allowing packets with the token to pass while dropping others. For example, the token can indicate that the packet is part of a “trusted” class. The token can be calculated from a secret, shared between the sender and receiver, and a rotating value. In some embodiments, the token may be placed in all packets associated with a trusted sender or for some time before trust must be re-established. Alternatively, the token can be placed in an initial one or more packets of a particular flow, and the packet filter can look for such packet(s), deciding whether to allow or block them. The packet filter then treats subsequent packets in the same flow in the same way.