Recovering Headers from OVS Collisions

The OVS header-recovery attack asks what a collision can reveal when a victim's packet is not visible to the observer. Its answer is deliberately narrower than “the attacker reads the packet”: under the paper's model, repeated microflow observations can recover selected source fields, especially the source IP address and port, when the destination-side fields and cache behavior are known. The useful judgment is whether the collision evidence is strong enough to support that inference, and how the attack's time, noise, and datapath requirements limit it.

The first stage: measure a victim's displacement

The attack places a victim and a queryable service in separate virtual machines on the same OVS. The victim accesses a publicly reachable service. The attacker knows that service's destination IP address, destination port, and protocol, and can query a service co-located with the victim's VM. The co-located service gives the attacker a legitimate-looking request path through the same OVS instance. It does not give the attacker direct access to the victim's VM or packets.

The attack relies on a specific property of the microflow cache. The cache combines five packet-header fields—source IP, source port, destination IP, destination port, and protocol—into a hash. In the paper's evaluated 8k configuration, two 13-bit portions of the hash select two candidate entries. A packet must still match the cached flow exactly; landing at the same location is not enough. But when a new flow competes for occupied candidates, OVS can replace an existing entry according to the compared hash values.

That gives the attacker a way to turn an invisible victim packet into a visible change. The attacker first establishes a reference for microflow entries by sending probes through the co-located service and observing their response times. A fast response indicates that the probed flow is still an exact cache hit. If the victim's traffic causes a collision that displaces that entry, the same probe takes the slower route through the cache hierarchy. The attacker records the change as evidence that another flow occupied a related set of candidate locations.

This is a Prime+Probe-style relationship, but the important object is the OVS flow entry rather than a CPU cache line. “Prime” means creating a known enough cache condition. “Probe” means measuring whether that condition remains. The attacker does not need to know the victim's payload, and the service does not need to cooperate with the victim. The inference comes from the shared microflow state that both traffic paths can affect.

A victim request can produce more than one relevant forwarding flow because a request and its response travel in opposite directions. The paper's probing design accounts for the entries associated with that exchange and repeats the measurements to distinguish victim-induced displacement from noise. This is why the attack is not a single-packet observation. It is a sustained attempt to identify which reference entries stop behaving like exact microflow hits after the victim is active.