Interpretation of ra output...

[Russell Fulton]

Hi All,
	here are some logs from my patched ra which displays all the
tcp state info, not just the final state.  In this case
S = SEEN_SYN+ACK and R = RST.

12 Mar 00 11:09:38      tcp  130.216.35.201.1610   |>   202.44.216.10.55302 2      2       0         0        SR
12 Mar 00 11:10:11      tcp  130.216.35.201.1610   |>   202.44.216.10.55350 1      1       0         0        SR
12 Mar 00 11:25:47      tcp  130.216.35.201.2259   |>   202.44.216.10.56948 2      2       0         0        SR
12 Mar 00 11:26:18      tcp  130.216.35.201.2259   |>   202.44.216.10.57005 1      1       0         0        SR
12 Mar 00 11:41:36      tcp  130.216.35.201.2885   |>   202.44.216.10.58437 2      2       0         0        SR
12 Mar 00 11:42:06      tcp  130.216.35.201.2885   |>   202.44.216.10.58483 1      1       0         0        SR
12 Mar 00 11:56:07      tcp  130.216.35.201.3505   |>   202.44.216.10.59825 2      2       0         0        SR
12 Mar 00 11:56:37      tcp  130.216.35.201.3505   |>   202.44.216.10.59865 2      2       0         0        SR

My interpretation of this trace is that the argus server saw a SYN+ACK
packet come in *from* 202.44.216.10 (but never saw the corresponding SYN
packet) and that 130.216.35.201 responded with a RST packet.  Argus/ra
has simply assumed that it missed the SYN packet and has adjusted the
source and destination addresses accordingly.

I don't have any problems with this behaviour ;-) I just want to be
sure I really do understand what is happening here.  Well at the
packet level at any rate - why we have been seeing this stuff over the
weekend is a mystery.

Unfortunately it now appears to have stopped otherwise I would have
cranked up tcpdump to get some more details.

Running this through fullra reveals that the dst TTLs vary wildly
(in this sample from 10 to 170) while the src TTLs are all between
190 and 210.

Carter: how should we interpret these TTL values (given that TTL is
the property of a single packet) are they averages?  I assume that
source TTL refers to the TTL for packets sent by the source and dest
TTL to those sent by the destination.  I find it strange strange that
the TTL associated with 130.216.35.201 varies at all since it is our
student Mail system and is two hops from the argus monitor.  And what
should I make of the wild variation in the other TTL?

Any ideas?

My guess is that this traffic was not generated by a tcp stack and
source addresses forged, why I have no idea.

Cheer, Russell.