What does a NetFlow or IPFIX flow record prove about a connection, and what can it never show?
answer
- an accounting summary, not a capture
- five-tuple plus counters and timestamps
- volume and timing, never content
- one record, one direction
- addresses as seen at the exporter
basics
~20 sA flow record proves that two addresses and ports exchanged a counted number of bytes and packets during a time window, as seen at one observation point. It carries no payload, so it never shows what was sent.
solid answer
~50 sNetFlow and IPFIX records are accounting summaries, not captures. Each record carries the five-tuple — source and destination address, source and destination port, protocol — plus byte and packet counters, start and end timestamps, and observation details such as the ingress interface and the union of TCP flags seen. That is enough to say 41 MB left a host toward `203.0.113.42` on port 443 over twelve minutes. It is not enough to say what those bytes were: no payload means no filename, no credential, no request. Two further limits matter in practice. Records are usually unidirectional, so the reverse flow is a separate record; and the addresses are those seen at the exporter, so anything behind NAT appears as the translated address rather than the host. Flow answers whether bytes moved, how many, and when — and nothing about content.
code
text · 12 linesflowStartMilliseconds: 2026-03-11T02:41:07.220Z
flowEndMilliseconds: 2026-03-11T02:53:44.910Z
sourceIPv4Address: 10.14.6.31
sourceTransportPort: 50114
destinationIPv4Address: 203.0.113.42
destinationTransportPort: 443
protocolIdentifier: 6
octetDeltaCount: 41938201
packetDeltaCount: 29144
tcpControlBits: 0x1b
ingressInterface: 12
...go deeper
Be ready to list the fields from memory — five-tuple, byte and packet counts, start and end times — and to say in one sentence that there is no payload, so flow shows volume and timing but never content.
Explain the mechanics behind the record: how the exporter groups packets into flows, why records are unidirectional, and how active and inactive timeouts split one long session into several records you must aggregate.
Show the judgment of writing a finding at the strength of the evidence. State what the record licenses, name the second source you need for the rest, and flag the observation-point and NAT caveats before someone else does.
Own the position flow holds in the telemetry mix: cheap, long-retained, agentless coverage of the wire that answers existence and volume, paired with DNS, proxy and endpoint feeds that supply names, users and processes it structurally cannot.
## What a flow record actually is NetFlow (Cisco's export format, v5 and v9) and IPFIX (the IETF standardisation of v9) are *accounting* protocols. A router, switch or dedicated probe watches packets crossing an interface, groups them into flows — packets sharing a key, classically the five-tuple — and exports one small record describing the group when the flow ends or a timer expires. sFlow is a relative but not the same thing: it samples packets and exports header excerpts plus interface counters rather than assembling complete flows. The point of the design is cost. A busy border link carries terabytes; the flow records describing it are megabytes. That is why flow is the telemetry organisations can afford to keep for months while full packet capture, if it exists at all, rolls over in hours. ## The fields, and what each licenses A typical IPFIX record carries: - `sourceIPv4Address`, `destinationIPv4Address` — the addresses **as seen at this exporter** - `sourceTransportPort`, `destinationTransportPort`, `protocolIdentifier` — completing the five-tuple - `octetDeltaCount`, `packetDeltaCount` — bytes and packets counted for this record - `flowStartMilliseconds`, `flowEndMilliseconds` — the observed window - `ingressInterface` / `egressInterface`, and often the source or destination autonomous-system number - `tcpControlBits` — the union of TCP flags observed across the flow, which distinguishes a SYN-only attempt from an established session but does not preserve their order So the licensed claim is: this many bytes moved, between these addresses and ports, in this window, through this interface. ## What it can never show There is no payload in a flow record — not a truncated one, not a hash of one. This is the single most important property to state out loud in an interview, because most wrong answers on this topic are a quiet upgrade of the claim: - **"41 MB of customer data was exfiltrated."** Flow supports "41 MB left this host toward that address". Whether it was a database dump, a video call or a software update is outside the record. - **"Port 443, so it was HTTPS."** A port is a number in a header. Tunnels are built on 443 precisely because 443 egress is permitted. Only something that saw the handshake — a proxy record, a TLS metadata sensor, endpoint telemetry — can name the protocol. - **"The user uploaded it."** An address identifies an interface at a moment, not a person, and often not even a host once NAT is involved. ## Three traps that catch people who use flow daily 1. **Unidirectional by default.** Classic NetFlow exports one record per direction. The 41 MB in the outbound record says nothing about the response volume; you need the reverse record, or an IPFIX biflow record with reverse counters, to see both sides. Reading one record as a whole session systematically halves your picture. 2. **The observation point defines the truth.** The exporter records what crossed *that* interface. A source address behind port address translation is the gateway's public address; two hosts talking on the same VLAN may never cross an exporter at all, so east-west traffic is frequently invisible even in an estate with "full flow". 3. **Timeouts split sessions.** Exporters use an active timeout (commonly 60 seconds to a few minutes) and an inactive timeout. A two-hour transfer arrives as a stream of records, so any analysis that looks for a single large flow will miss it. Aggregate by five-tuple over a window before you judge volume. ## Where flow earns its place Despite all that, flow is often the most valuable feed a defender has, because it is cheap, retained long, and covers everything on the wire — including devices no agent will ever be installed on. It answers existence, volume and timing questions across the whole estate at once. The discipline is pairing it: DNS query logs supply the names, proxy records supply the hostname and the authenticated user, endpoint telemetry supplies the process that opened the socket. Flow tells you *that* a conversation happened; the other surfaces tell you what and who. ## The direction of the claim When you write a finding from flow, write it at the strength of the evidence: "the border exporter recorded 41 MB from 10.14.6.31 to 203.0.113.42 on TCP/443 between 02:41 and 02:53". Everything beyond that sentence — what the bytes were, which process sent them, whether a human intended it — is an inference that needs a second source, and an interviewer is listening for whether you know which half of your statement is record and which half is inference.
- The flow shows port 443 outbound — can you conclude the session was TLS?No. The port is a number in a header, not a protocol proof, and flow carries no payload to check it against. Tunnels are deliberately built on 443 because that egress is allowed. To name the protocol you need something that saw the handshake: a proxy record, a TLS metadata sensor, or endpoint telemetry naming the process that opened the socket.
- Your feed also carries IDS alerts alongside flow. What does an IDS alert add over a flow record?It points at content the flow record cannot see: a signature or analytic matched something in the traffic the sensor inspected. But it is still only a detection firing, not a verdict, and the vendor severity field is the vendor's opinion of that signature, not your severity for this estate. Consume it as one more feed and corroborate it against flow, DNS and endpoint records before it becomes a conclusion.
- Why do two flow records exist for what a user would call one download?Classic NetFlow keys and counts each direction separately, so the request direction and the response direction are distinct records. Long sessions are also split by the exporter's active timeout, producing several records per direction. Any volume analysis has to aggregate by five-tuple over a window rather than read a single record as the whole session.
It is an itemised phone bill: who called whom, when, and for how long. The bill never contains the conversation.
saying these in an interview costs you the question
- Claims a flow record shows what data was exfiltrated
- Treats the source address as the host, ignoring NAT
- Assumes port 443 proves the session was HTTPS
- Reads one unidirectional record as the whole session
- Thinks flow stores truncated payload or packet headers