PEP Enablers for IP-Layer Encryptor Performance
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
IP-layer encryptors render Performance Enhancing Proxies (PEPs) inoperative for communications initiated by hosts on the red-side, as they encrypt packets, removing higher-level protocol information, thus preventing red-side packets from benefiting from black-side PEPs.
Innovation Solution
Implementing red-side and black-side Performance Enhancing Proxy Enablers (PEPEs) to encapsulate and reconstruct higher-level protocol information within UDP packets, allowing PEPs on the black-side to enhance transmission performance between IP-layer encryptors, even when packets are encrypted.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If IP-layer encryptors encrypt packets to provide secure communications, then security is improved, but higher-level protocol information is removed making PEPs inoperative
Solution Approach 1:
The patent embeds a covert channel within the encrypted packet structure. Specifically, it utilizes unused bits in the IP header (such as the ECN and DS fields) to encode higher-level protocol information. This nested information allows PEPs to function on the black-side without compromising the encryption security, as the protocol information is hidden within the encrypted packet rather than being separate from it.
Solution Approach 2:
The patent introduces an intermediary mechanism that bridges the encrypted and unencrypted domains. The red-side PEPE extracts protocol information from plaintext packets before encryption, embeds it in the encrypted packet using covert channels, and the black-side PEPE retrieves this embedded information to enable PEP operations. This intermediary covert channel allows PEPs to operate on encrypted packets without requiring the encryptor to be aware of or cooperate with the PEP functionality.
2Productivity
If PEPs are deployed on black-side to enhance transmission performance, then throughput is improved, but they cannot operate on encrypted packets from red-side
Solution Approach 1:
The patent nests protocol information within the encrypted packet structure by utilizing unused or minimally used bits in the IP header. Fields such as ECN (Explicit Congestion Notification) and DS (Differentiated Services) are repurposed to carry protocol identification and control information. This allows black-side PEPs to access necessary protocol information directly from encrypted packets, enabling performance enhancement without requiring decryption or compromising security.
Solution Approach 2:
The patent changes the parameter representation of protocol information by encoding it in a different form within the encrypted packet. Instead of requiring separate unencrypted protocol headers, the protocol information is transformed into a covert channel representation using specific bit patterns in the IP header fields. This parameter transformation allows PEPs to interpret and act on protocol information even though the packet appears encrypted to intermediate devices.
3Adaptability or versatility
If red-side PEPE encapsulates protocol information in UDP packets, then PEP compatibility is improved, but packet overhead increases
Solution Approach 1:
The patent eliminates the need for separate UDP encapsulation by nesting protocol information directly within the encrypted packet structure. Instead of wrapping the encrypted packet in a UDP header (which would add significant overhead), the protocol information is embedded in unused bits of the original IP header. This nested approach provides the same PEP compatibility functionality while minimizing additional packet overhead, as no extra protocol headers are required.
Solution Approach 2:
The patent extracts only the essential protocol information needed for PEP operation and places it directly in the encrypted packet, rather than encapsulating the entire packet in a new protocol wrapper. By extracting and embedding only the necessary control fields (such as protocol type, flow identification, and control flags) in the covert channel, the solution achieves PEP compatibility without the substantial overhead that would result from full UDP encapsulation of the encrypted payload.
Data Source
AI summary
A mechanism to allow hosts on the plaintext side of IP-layer encryptors to utilize Performance Enhancing Proxies (PEPs) on the ciphertext side of IP-layer encryptors is provided. Two processes are utilized for each IP-layer encryptor to extend a higher-level protocol (as represented, for example, by OSI layers 4-7) from the plaintext or red-side of the IP-layer encryptor to the ciphertext or black-side of the IP-layer encryptor. These two processes are known as the red-side Performance Enhancing Proxy Enabler (PEPE) and the black-side PEPE. The red-side and black-side PEPEs of a local IP-layer encryptor work together with red-side and black-side PEPEs of a remote IP-layer encryptor to transmit packets between the IP-layer encryptors using a higher-level protocol. Hence, PEPEs allow packets exchanged by red-side hosts separated by IP-layer encryptors to be transmitted on the black-side using a higher-level protocol. Therefore, PEPEs allow hosts on the red-side to take advantage of PEPs on the black-side.