PhysWall · The Physical-Logic Gateway · four-dimensional gap decomposition

Do your switch counters match the sampled flow?

A physics engine, and a verification tool enforced on top of it. PhysWall inverts a closed, published, non-linear physical law at a single measurement point — and refuses when the inverse is not unique. Seven laws, one engine, and the same refusal in all of them.

Every switch counts bytes exactly. The security layer sees a sample. Nobody compares the two — and the difference is bytes that crossed the wire and were never inspected.

The two numbers have names. The switch’s own total is IF-MIB::ifInOctets, read over SNMP or pushed as an sFlow counter sample. The sampled total comes from flow samples at 1-in-n. A large gap between them points at a sampling rate too aggressive for the link — or at traffic nobody inspected.

A counter and a sample disagreeing is the same shape as a total that does not match its parts, in a subject where the parts are packets.

See it worked through →

HELD — THE ENGINE RUNS, THE MEASUREMENT HAS NOT

There is no tool on this page, and that is not an oversight. The command has never been run against a switch. Everything the engine has been shown is numbers we invented.

Every other page here rests on a source with no interest in whether we succeed — USGS, NOAA, a published standard. This one would rest on us. So it stays held until one real interface has been read.

THE QUESTION

SNMP           counts octets exactly
               no sampling, no estimate
               every switch exports it

NetFlow/sFlow  samples 1 in N, multiplies
               by N, and reports that

the gap        bytes that crossed the wire
               and never reached the collector

Both numbers already exist on every managed network. They are not compared, because they are read by different teams for different reasons.

AND THE NAIVE SUBTRACTION DOES NOT WORK

Three reasons, and all three were found by an outside reviewer reading the first draft — before anyone touched a switch.

ONE — THE GAP IS ALWAYS THERE

SNMP counts layer 2, including framing. NetFlow counts the IP packet length. That is 18 bytes per frame with nothing missing at all:

ACK-heavy traffic     2.9%
typical campus        2.3%
bulk transfer         1.4%

So "is there a gap" returns yes on every link in the world. The question that decides anything is whether the gap is larger than the accounting and the sampling explain together.

TWO — SAMPLED FLOW IS AN ESTIMATE

One packet in a hundred, multiplied by a hundred, is an estimator. An unbiased estimator lands above the true value about half the time — so "flow above the counter" fires in roughly half of all minutes with nothing wrong. A tool that calls that broken gets thrown out in a week.

The threshold is computable rather than chosen:

relative SD = sqrt((N-1)/n) * sqrt(1 + CV^2)

  N   the sampling rate
  n   packets in the window
  CV  spread of packet sizes

THREE — THE COUNTER THAT CANNOT WRAP

Our first draft built its refusal on a counter rolling over. The OID it asked for was 64-bit, which needs 47 years at 100 Gbps. The refusal would never have fired on the number being measured.

And the MIB already supplies ifCounterDiscontinuityTime, the field that separates a restart from continuous counting. Refusing to answer a question the standard already answers is not a refusal — it is not having read the standard.

FIVE VERDICTS

CONSISTENT    inside the band the accounting and
              the sampling noise predict together

IMPOSSIBLE    above the corrected counter by more
              than the noise explains
              -> the measurement is broken

UNACCOUNTED   below it by more than the noise
              explains
              -> bytes crossed and were not seen

NOT_UNIQUE    the counter went down, and a wrap
              and a restart both fit

UNDECIDABLE   an input the verdict needs was
              not supplied

UNDECIDABLE is the one that matters most. Without a sampling rate, a measurement looks exactly like a clean one — and calling that CONSISTENT would be the worst thing this page could do.

It is not a pass and it is not a finding. It is the engine saying which question it was not given enough to answer.

WHY THIS SURVIVES AN ADVERSARY

A detector can be evaded: an attacker sees what you look for and changes shape. A counter cannot be evaded, because it is not looking for anything — it counts what physically crossed the interface.

And what this finds is not the attacker. It is the gap in your own monitoring — and a system that reports less than actually left has a blind spot, which is where exfiltration happens.

It does not say an attack occurred, and it does not prevent one. It says how much could have moved without being seen. That is a number, not a suspicion.

WHAT WOULD RELEASE IT

One managed interface, read three times five minutes apart, with four fields and one question:

ifHCInOctets                exact octet count
ifHCInUcastPkts             for the framing correction
ifCounterDiscontinuityTime  restart or continuous
ifInOctets                  fallback below 20 Mbps

and: what is the flow sampling rate?

Read-only. Nothing changes, and no data leaves the network. If the gap stays inside what the accounting and the sampling explain, this page comes down — and that is a result too.

PhysWall was developed and architected by Gadi Zion.

Built on PhysWall — the same engine reads antenna bandwidth, conductor loss, bit erasure and heat limits. It answers what the measurement implies, and refuses when the measurement cannot say.

Check this instead of believing it. Every number here reproduces from a source that is named, and the claims that turned out wrong are still printed next to what replaced them. The same engine runs all of these — it asks how much a measurement allows you to conclude, and refuses the same way in every field. The same engine runs all of these — it asks how much a measurement allows you to conclude, and refuses the same way in every field. How to check each one →