Identifying Producers (aka Servers) and Consumers (aka Clients) for a flow

There are multiple ways (often heuristics) to detect servers:

• If a sensor sees the SYN handshake, it can figure out who the server is.

• Based on time - the initiator of a connection is deemed client.

• Degree model - a server typically has many clients talking to it. In contrast, the degree for client port is expected to be far less.

The priority order is SYN_ANALYSIS/NETSTAT > USER_CONFIG > DEGREE_MODEL.

The thinking behind giving SYN_ANALYSIS higher priority over user config is that config can get stale, and that sensor has the best vantage point to establish ground truth. DEGREE_MODEL is where learning/heuristics come into play, and the accuracy can’t be 100% guaranteed.

It’s possible that our heuristics for client-server detection can go wrong, despite our best intentions and continuous algorithmic refinements that we make in this area. For those scenarios, the OpenAPI interface can be used to punch well-known server ports. These configs aren’t applied to past flows, and only affect markings on flows from that point on (that is, going forward). It’s intended as a last resort fallback, rather than the normal modus operandi.

We also recommend not to keep flipping the client- server marking for the full duration of a given flow (even if we get it wrong, and when our internal models have changed - which they do over time, as more flow patterns are observed/analyzed). Higher/equal priority updates are allowed to override lower priority ones (we will flip client server for the existing flows as well). In other words, the stickiness of marking “for the lifetime of a flow” only applies to degree model based marking.