Alternate state fields

Sat Apr 2 20:47:19 EDT 2016

Hey John,
You’re on the right track.  Argus is much different from other flow technologies with regard to TCP state tracking, and the -z flag is specific to Argus state reporting.  Netflow and IPFIX only report the TCP flags seen, which are OR’d flags seen in a unidirectional stream of TCP packets.  This has its limitations, i.e. you can’t tell the difference between the 2 packets SYN and ACK, vs a single SYN_ACK packet using Netflow/IPFIX.  The semantics of these two different conditions is huge.   Argus, on the other hand, tallys the states that the bi-directional TCP goes through, so that the SYN and ACK are tracked as connection requested (SYN) and connection established (ACK) (s, E), and the -z option is used to print the TCP state that the flow is in.   Don’t think of the sSE as TCP flags, think of them as observed states, and it shouldn’t be confused as misleading.  “sSE” as a state is different than “E” as a state.  With sSE I have observed the SYN, SYN_ACK, and ACK handshake, and the connection is established.  With just an E, argus is saying that it see’s a TCP connection that seems established, but argus can’t verify that the TCP was neogitated. 

The -Z option is just printing the set of TCP flags that were seen for the status interval, so seems that that is more oriented to what you expect to see ???  The -Z option is there for the Netflow crowd, but I rarely look at it.

The ra.1 man page is actually pretty detailed on this ???

Carter

> On Apr 2, 2016, at 12:20 PM, John T. Myers via Argus-info <argus-info at lists.andrew.cmu.edu> wrote:
> 
> Hi Carter,
> 
> I've been experimenting with modifying the state fields using the -z and -Z options with ra.
> 
> I did two SCP transfers, one with each option, and I'm confused on the logic for how the fields are populated, and the manual doesn't quite explain why.
> 
> When using the -z option, it seems like the state field maintains all TCP state changes seen for the entire session, not just that flow record. While using the -Z option, it seems that only TCP flags seen for that flow duration are tracked. I've copied my output below
> 
> I would expect that for the -z option I would see the first flow record have "sSE" in the field and then subsequent records (excluding teardown) would only have "E". Instead every field here has "sSE" which is misleading. Wireshark confirms (as it should b/c this is TCP) that there is only one SYN & SYN/ACK exchange for the SCP session.
> 
> However, using -Z, the SYN flag is only tracked once, on the first session, which is seen with the SPA_* in the field, and all subsequent fields do not have the S present.
> 
> This seems a little inconsistent to me, could you provide any insight?
> 
> I'm using Ra Version 3.0.8.2.rc.2 and Argus Version 3.0.8.1
> 
> jtmhotroute:~ jtm$ ra -S 127.0.0.1:1776 <http://127.0.0.1:1776/> -z - port 22
> 
>          StartTime      Flgs  Proto            SrcAddr  Sport   Dir            DstAddr  Dport  TotPkts   TotBytes State 
> 
>    12:05:28.726620  e s         tcp      192.168.87.28.61864     ->      192.168.87.29.ssh       11791   11853171   sSE
> 
>    12:05:33.728299  e &         tcp      192.168.87.28.61864     ->      192.168.87.29.ssh       24965   25502802   sSE
> 
>    12:05:38.730173  e &         tcp      192.168.87.28.61864     ->      192.168.87.29.ssh       25702   26240872   sSE
> 
>    12:05:43.730638  e &         tcp      192.168.87.28.61864     ->      192.168.87.29.ssh       33712   34532864   sSE
> 
>    12:05:48.731169  e &         tcp      192.168.87.28.61864     ->      192.168.87.29.ssh       53476   54405756   sSE
> 
>    12:05:53.731298  e s         tcp      192.168.87.28.61864     ->      192.168.87.29.ssh       57456   58217859   sSE
> 
>    12:05:58.732201  e s         tcp      192.168.87.28.61864     ->      192.168.87.29.ssh       29702   29707269   sSE
> 
>    12:06:03.733620  e &         tcp      192.168.87.28.61864     ->      192.168.87.29.ssh       30154   30824832   sSE
> 
>    12:06:08.736406  e &         tcp      192.168.87.28.61864     ->      192.168.87.29.ssh        8750    8566056  sSER
> 
> 
> 
> 
> 
> 
> ^Cjtmhotroute:~ jtm$ ra -S 127.0.0.1:1776 <http://127.0.0.1:1776/> -Z b - port 22
> 
>          StartTime      Flgs  Proto            SrcAddr  Sport   Dir            DstAddr  Dport  TotPkts   TotBytes State 
> 
>    12:07:04.327678  e s         tcp      192.168.87.28.61964     ->      192.168.87.29.ssh       11430   11567973 SPA_*
> 
>    12:07:09.328327  e &         tcp      192.168.87.28.61964     ->      192.168.87.29.ssh       28235   28832474  A_PA
> 
>    12:07:14.328806  e &         tcp      192.168.87.28.61964     ->      192.168.87.29.ssh       29312   29921468  A_PA
> 
>    12:07:19.330776  e s         tcp      192.168.87.28.61964     ->      192.168.87.29.ssh       32839   33147266 PA_PA
> 
>    12:07:24.331001  e &         tcp      192.168.87.28.61964     ->      192.168.87.29.ssh       31180   31834004  A_PA
> 
>    12:07:29.331785  e &         tcp      192.168.87.28.61964     ->      192.168.87.29.ssh       34135   34876590  A_PA
> 
>    12:07:34.333754  e &         tcp      192.168.87.28.61964     ->      192.168.87.29.ssh       38064   38903160  A_PA
> 
>    12:07:39.333868  e &         tcp      192.168.87.28.61964     ->      192.168.87.29.ssh       51077   52220114 PA_PA
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20160402/59b42f8a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6837 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20160402/59b42f8a/attachment.bin>