What does a connection or session record actually prove?¶
title: "What does a connection or session record actually prove?" card_id: "IP-024" status: "complete" source_document: "https://docs.google.com/document/d/1yrcYdYcmg1KjOu4mi0sdaoczDtf_hKrZl_g7T5AuMAI/edit?usp=drivesdk"
What does a connection or session record actually prove?¶
The words “connection” and “session” sound definite.
But different systems use them to describe very different things.
A firewall might record a connection when it sees the first packet.
A server might only record one after a network handshake has completed.
A platform might use the word session for a series of requests linked by a cookie or token.
So before deciding what the record proves, you need to understand what that particular system means by the term.
At the most basic level, one system may simply have observed a packet from a source IP address heading towards a destination.
That doesn’t necessarily mean the destination received it.
It doesn’t mean that the destination responded.
And it doesn’t mean that any useful communication was established.
With TCP, a device normally starts by requesting a connection.
The receiving system responds, and the originating device must reply again to complete the three-way handshake.
A record of the initial request shows a connection attempt.
A completed handshake is stronger evidence that the two systems could exchange traffic through that network path.
But even an established TCP connection doesn’t prove that a login succeeded, a file was transferred or a person performed a particular action.
It only proves that the network connection reached that stage.
UDP works differently because it doesn’t use the same connection process.
A firewall or monitoring system may still group UDP packets together and call them a connection or session. That’s usually the system creating a convenient record based on addresses, ports, timing and traffic flow.
It isn’t evidence that a TCP-style connection was established.
Application sessions are different again.
A website may create a session to group requests from the same browser. A VPN may create a session when a device or account connects to the VPN gateway. A cloud service may use a session token to keep an account authenticated.
A session record may contain start and end times, an account name, source IP address, assigned internal address, device information and the amount of data transferred.
Those details can be useful, but they still need careful interpretation.
A session lasting two hours doesn’t prove that somebody was actively using the service for the whole two hours.
The device may have remained connected while unattended.
The session may have continued in the background.
The recorded end time might represent a timeout rather than the moment the person stopped using it.
The number of bytes transferred doesn’t tell you what the data contained or whether the transfer was meaningful.
A VPN session also shows access to the VPN gateway. It doesn’t, by itself, prove what the device did after entering the internal network.
That requires records from the systems or services used during the session.
So a connection or session record may establish that systems exchanged traffic, that a network path worked or that a service maintained a period of activity under a particular identifier.
It doesn’t automatically prove what happened within that connection, who was using the device or whether a particular person was responsible.