RobotnixAcademy

Week 08 · lesson

TCP Keeps Connection State; UDP Does Not Promise It

TCP and UDP both carry application data over IP, but they offer different transport behavior.

Understanding that difference makes packet evidence much easier to interpret.

TCP establishes connection state

A simplified TCP handshake is:

CLIENT                         SERVER
  | ------ SYN --------------> |
  | <--- SYN-ACK ------------- |
  | ------ ACK --------------> |

After this exchange, both endpoints maintain state for the connection.

The handshake does not prove the application is healthy. It proves the transport connection establishment represented in the trace completed.

Read the evidence in sequence

Supplied trace A:

1  client → server  SYN
2  server → client  SYN-ACK
3  client → server  ACK
4  client → server  data
5  server → client  data

Supported claim:

The supplied trace contains a completed TCP three-way handshake followed by bidirectional data.

Supplied trace B:

1  client → server  SYN
2  client → server  SYN
3  client → server  SYN

Supported claim:

The client-side trace shows repeated SYN attempts without an observed SYN-ACK at this capture point.

Do not jump directly to “firewall blocked it.” Other mechanisms are possible:

  • no service listening;
  • destination host unavailable;
  • routing failure;
  • packet filtering;
  • response taking a different path not visible to the capture;
  • capture problem.

Evidence narrows hypotheses; it does not award certainty for free.

A reset is different from silence

Supplied trace C:

client → server SYN
server → client RST,ACK

This is different from no response.

In a simple model, a reset from the destination host can be consistent with the host being reachable but no accepting TCP listener existing at that endpoint, though real systems and middleboxes can complicate interpretation.

The key is to distinguish observable patterns.

UDP does not establish the same connection state

A UDP application can send a datagram without a TCP-style handshake.

CLIENT -------- UDP DATA --------> SERVER

The absence of a response does not tell you whether:

  • the datagram arrived and the app chose not to respond;
  • the host was unreachable;
  • filtering dropped it;
  • the service was absent; or
  • the response was lost.

That makes UDP evidence especially dependent on context and observation point.

Do not translate TCP assumptions directly to UDP

A phrase such as “the UDP connection was established” is often misleading because UDP itself does not provide TCP's connection-establishment handshake.

An application can implement its own state above UDP, but that is application behavior, not the same transport mechanism.

Lab: classify four supplied traces

Trace 1

SYN → SYN-ACK → ACK

Trace 2

SYN → SYN → SYN

Trace 3

SYN → RST,ACK

Trace 4

UDP datagram sent; no response observed

For each, write:

  • observed transport pattern;
  • one plausible mechanism;
  • one competing mechanism where applicable;
  • one additional evidence source; and
  • one claim you should avoid.

Correlate transport evidence with socket state

Now add this supplied server evidence:

baseline: LISTEN 127.0.0.1:8080
changed:  LISTEN 0.0.0.0:8080

and this client trace in the changed state:

SYN → SYN-ACK → ACK

Together, the evidence is stronger than either artifact alone:

  • local socket state shows broader binding;
  • packet evidence shows a remote-style lab client completed a TCP handshake to the service endpoint.

You still need application evidence to claim the service function worked.

Retests should climb the stack

If you change a socket binding, retest:

  1. the listening state;
  2. the intended allowed path;
  3. the intended denied path; and
  4. the application response for the allowed path.

That prevents a “fix” that simply makes the service unavailable to everyone.

Extend your Service Exposure Record

Add one TCP trace and classify:

Handshake result:
Observed flags:
Primary interpretation:
Alternate explanation:
Correlated socket evidence:
Application evidence still needed:

Lesson 3 will turn that into an exposure-control decision.