Covert Channels Without a Direct Link
The remote OVS covert-channel experiment asks a deceptively simple question: can two parties communicate through a shared virtual switch when the network does not connect them directly? The answer demonstrated by the study is yes, under a specific service-access and timing model. Understanding that result requires following the indirect path—one party changes OVS cache state through a queryable service, another party measures a different service path, and the shared switch turns the change into a timing signal. The channel's bandwidth and accuracy then reveal how much practical capacity the performance artifact has.
A channel made of two ordinary services
A covert channel is a communication path that the system did not intend to provide. The sender and receiver may be prohibited from contacting one another directly, yet they can still exchange information if both can influence and observe a shared resource. In the OVS experiment, that resource is not a file, a shared memory segment, or a deliberately opened port. It is the forwarding state held by an OVS instance used by separate virtual machines.
The experiment places a Memcached service in a VM on the server and co-locates the receiver with that service in another VM. The sender can query the co-located service. The receiver can query a second Memcached service outside the server and measure the response time. The two parties have no direct connection for sending the message. Their relationship is mediated by OVS: the sender's service traffic uses the same forwarding machinery whose state affects the receiver's request path.
Memcached is a convenient demonstration service because a known key-value request produces a predictable exchange of packets. It is not the security assumption that makes the channel work. The paper notes that a database or website could supply a similar queryable path if its traffic reaches the same OVS instance in a sufficiently repeatable way. The service is a vehicle for generating and observing traffic; the channel lives in the shared forwarding state.
The two sides also have different jobs. The sender is an influencer. They generate a chosen pattern of requests that changes cache state. The receiver is an observer. They send probes through a separate path and classify the resulting latency. The receiver does not need to know the sender's application message or inspect the sender's packets. Both parties only need an agreed relationship between a state change and a bit value.
The microflow version uses collision-sensitive exact entries. For a bit represented as “1,” the sender generates traffic that causes contention with a microflow entry the receiver expects to probe. The resulting collision can evict the receiver's entry. For “0,” the sender stays idle with respect to that state. When the receiver later probes, an intact entry produces the faster microflow timing, while an evicted entry produces the slower path. The receiver interprets the difference as the bit.
This is a high-level signaling loop, not ordinary connectivity. The sender does not send the bit to the receiver's network address. The sender changes a condition that both parties can touch indirectly. The receiver's query still goes to the receiver's own external service, and the response still looks like a normal service response. The covert information is carried by the difference between those otherwise similar responses.
The megaflow version uses a slower state transition. Its subtables are checked in sequence and reordered according to hit counts.