Definition of filter fin and finack

[Nick Diel]

Carter,

Just to make sure I am understanding the finack state correctly, it
represents a half close, waiting for the finack.  Is there another keyword
to represent a closed state (where both fins have been acknowledge)?  I want
to differentiate between two unusual cases with resets.

Case 1:
Fin->
<-ack
<-Fin-ack
->ack
<->reset (dir doesn't matter)
This was successfully closed, but also has the reset bit set


Case 2:
Fin->
<-ack
<-reset
This was not successfully closed and was reset.

In case someone is curious the first case is caused by some dumb statefull
devices (a DSL modem I have tested is one), which is clearing out it's state
table using resets.  The second case is from a number of different
applications, one particular is Internet Explorer doing this for certain
flows.

As for the wording of filters, I think as long as it easy to distinguish
between state filters and bit filters, they will be fine.  Perhaps even
allowing for bit testing as tcpdump does (tcp[xx]).

Nick

On Wed, Aug 27, 2008 at 7:38 PM, Carter Bullard <carter at qosient.com> wrote:

> Hey Nick,Hmmmmmm........
>
> Yes, fin seems to just mean the fin bit is set.  This is syntactically
> correct,
> based on the compiler (individual bit keywords, syn, ack, rst, urg, ece,
> cwr, push, fin) are used to test TCP flag bits.  TCP flag bits are stored
> for each
> side of the TCP, so the keywords "src" and "dst" apply to the simple bit
> tests.
>
> We added all the flag bit tests for argus-3.0.0, so you could pick any bit
> you
> wanted,  and seem to have messed up the original test for syn and fin.
>  (the
> logic is there, but the test is now looking at the wrong offset in the TCP
> dsr).
>
> The TCP states are different, as there is no direction associated with the
> states.
> Thats because for most of the states, they imply the direction.  These are
> printed
> correctly in the status field, but only the synack, finack and 'con'
> keywords actually
> pick up these states.
>
> We have additional compound keywords for TCP, 'normal', and 'est', that
> test some
> of the various tcp state indicators.  But these are not detailed enough to
> pick out,
> say  the fin only flows.  I'll have to come up with some keywords that will
> be easy to
> use and are different than the flags tests,  such as "synonly", "finonly",
> or "syninit",
> "fininit"?
>
>
> Can these work?
>
> Argus is doing the right thing, and the states are represented correctly
> in the records, so its just the client filter that is messed up right now.
>
> Carter
>
>
>
> On Aug 27, 2008, at 5:54 PM, Nick Diel wrote:
>
> Carter,
>
> As always, thanks for the info.  I have a couple more questions.
>
> First, most of my fin packets (from the source who initiated the teardown)
> also have the ack bit set.  So I was a little confused when you said that
> the fin means a packet with onlythe fin bit set.  I don't know what the RFC
> says, I just know the vast majority of my packets are this way (and I have
> billions of them).
>
> I did just a couple of tests where I tested a flow that is complete
> (syn-synack-data-fin-finack).  Then tested one with just a fin packet and
> finally one with just the first fin and the ack for it.  Based on the
> results it appears as if fin means the fin bit was set, while finack seems
> to mean a fin was acknowledged.  I can't put src or dst in front of finack
> to completey test this theory as I get a syntax error.
>
> The results are below, hopefully you can shed some light onto what I am
> missing.
>
> Thanks,
> Nick
>
> First I test a complete flow in argus:
>
> tcpdump -r singleCompleteFlow.pcap
> reading from file singleCompleteFlow.pcap, link-type EN10MB (Ethernet)
> 09:36:54.772992 IP 1.1.1.1.14713 > 2.2.2.2.pop3: S 2565614892:2565614892(0)
> win 64512 <mss 1460,nop,nop,sackOK>
> 09:36:54.789305 IP 2.2.2.2.pop3 > 1.1.1.1.14713: S 2137176771:2137176771(0)
> ack 2565614893 win 49640 <mss 1460,nop,nop,sackOK>
> 09:36:54.789395 IP 1.1.1.1.14713 > 2.2.2.2.pop3: . ack 1 win 64512
> 09:36:55.917052 IP 2.2.2.2.pop3 > 1.1.1.1.14713: P 1:56(55) ack 1 win 49640
> ....
> 09:36:56.442469 IP 2.2.2.2.pop3 > 1.1.1.1.14713: P 216:230(14) ack 55 win
> 49640
> 09:36:56.443141 IP 2.2.2.2.pop3 > 1.1.1.1.14713: F 230:230(0) ack 55 win
> 49640
> 09:36:56.443227 IP 1.1.1.1.14713 > 2.2.2.2.pop3: . ack 231 win 64283
> 09:36:56.479347 IP 1.1.1.1.14713 > 2.2.2.2.pop3: F 55:55(0) ack 231 win
> 64283
> 09:36:56.493103 IP 2.2.2.2.pop3 > 1.1.1.1.14713: . ack 56 win 49640
>
> ra -r singleCompleteFlow.argus - fin
>    09:36:54.772992  e         tcp       1.1.1.1.14713     ->
> 2.2.2.2.pop3         23       1571   FIN
> ra -r singleCompleteFlow.argus - src fin
>    09:36:54.772992  e         tcp       1.1.1.1.14713     ->
> 2.2.2.2.pop3         23       1571   FIN
> ra -r singleCompleteFlow.argus - dst fin
>    09:36:54.772992  e         tcp       1.1.1.1.14713     ->
> 2.2.2.2.pop3         23       1571   FIN
> ra -r singleCompleteFlow.argus - finack
>    09:36:54.772992  e         tcp       1.1.1.1.14713     ->
> 2.2.2.2.pop3         23       1571   FIN
>
> Here I test the same flow, but with only the first fin packet.
>
> tcpdump -r singleF.pcap
> reading from file singleCompleteFlow.pcap, link-type EN10MB (Ethernet)
> 09:36:54.772992 IP 1.1.1.1.14713 > 2.2.2.2.pop3: S 2565614892:2565614892(0)
> win 64512 <mss 1460,nop,nop,sackOK>
> 09:36:54.789305 IP 2.2.2.2.pop3 > 1.1.1.1.14713: S 2137176771:2137176771(0)
> ack 2565614893 win 49640 <mss 1460,nop,nop,sackOK>
> 09:36:54.789395 IP 1.1.1.1.14713 > 2.2.2.2.pop3: . ack 1 win 64512
> 09:36:55.917052 IP 2.2.2.2.pop3 > 1.1.1.1.14713: P 1:56(55) ack 1 win 49640
> ....
> 09:36:56.442469 IP 2.2.2.2.pop3 > 1.1.1.1.14713: P 216:230(14) ack 55 win
> 49640
> 09:36:56.443141 IP 2.2.2.2.pop3 > 1.1.1.1.14713: F 230:230(0) ack 55 win
> 49640
>
>
> ra -r singleF.argus - fin
>    09:36:54.772992  e         tcp       1.1.1.1.14713     ->
> 2.2.2.2.pop3         20       1403   FIN
> ra -r singleF.argus - src fin
>    (no results as expected)
> ra -r singleF.argus - dst fin
>    09:36:54.772992  e         tcp       1.1.1.1.14713     ->
> 2.2.2.2.pop3         20       1403   FIN
> ra -r singleF.argus - finack
>    (no results as expected)
>
>
> Next I test a flow that only has the first half of the tcp teardown
> (initial fin and ack of the fin).
>
> tcpdump -r singleFA.pcap
> reading from file singleCompleteFlow.pcap, link-type EN10MB (Ethernet)
> 09:36:54.772992 IP 1.1.1.1.14713 > 2.2.2.2.pop3: S 2565614892:2565614892(0)
> win 64512 <mss 1460,nop,nop,sackOK>
> 09:36:54.789305 IP 2.2.2.2.pop3 > 1.1.1.1.14713: S 2137176771:2137176771(0)
> ack 2565614893 win 49640 <mss 1460,nop,nop,sackOK>
> 09:36:54.789395 IP 1.1.1.1.14713 > 2.2.2.2.pop3: . ack 1 win 64512
> 09:36:55.917052 IP 2.2.2.2.pop3 > 1.1.1.1.14713: P 1:56(55) ack 1 win 49640
> ....
> 09:36:56.442469 IP 2.2.2.2.pop3 > 1.1.1.1.14713: P 216:230(14) ack 55 win
> 49640
> 09:36:56.443141 IP 2.2.2.2.pop3 > 1.1.1.1.14713: F 230:230(0) ack 55 win
> 49640
> 09:36:56.443227 IP 1.1.1.1.14713 > 2.2.2.2.pop3: . ack 231 win 64283
>
> ra -r singleFA.argus - fin
>    09:36:54.772992  e         tcp       1.1.1.1.14713     ->
> 2.2.2.2.pop3         21       1457   FIN
> ra -r singleFA.argus - src fin
>    (no results as expected)
> ra -r singleFA.argus - dst fin
>    09:36:54.772992  e         tcp       1.1.1.1.14713     ->
> 2.2.2.2.pop3         21       1457   FIN
> ra -r singleFA.argus - finack
>    09:36:54.772992  e         tcp       1.1.1.1.14713     ->
> 2.2.2.2.pop3         21       1457   FIN
>
>
> Nick
>
> On Wed, Aug 27, 2008 at 12:46 PM, Carter Bullard <carter at qosient.com>wrote:
>
>> Hey Nick,
>> Fin means that we saw a TCP packet with only the fin bit set.  It doesn't
>> excude
>> that other states were seen, it just means that we did see a proper FIN
>> packet.
>>
>> Finack means that we saw a TCP packet with only the fin and the ack bit
>> set,
>> so we know that there appears to be a proper response to a FIN packet.
>>
>> If you put "src" or "dst" in front of a TCP flag keyword, you aren't
>> asking about
>> TCP states, you're just asking for the occurrence of the bit being set in
>> any packet
>> observed by the flow record.  For example this filter:
>>
>>   "src \( fin and ack\)"
>>
>> is not the same as
>>
>>   "finack"
>>
>> In the first filter, the fin and the ack bits are not related, in that,
>> they could
>> have occurred in different packets.   The "finack" filter requires that a
>> packet
>> with the fin and ack were seen or'd in the same packet.  This is much
>> different
>> that what you see with Netflow, or any other flow data.
>>
>> Carter
>>
>>
>> On Aug 27, 2008, at 12:45 PM, Nick Diel wrote:
>>
>>  A quick question as I work on a paper.  For the filters "fin" and
>>> "finack", do each one represent one half of the 3-way tear down.  For
>>> example, does "fin" mean that argus saw the first fin and saw the ACK for
>>> this fin?  And on the other side, does "finack" mean that argus saw the
>>> second fin and saw the ACK for this fin?  Or does a complete teardown in
>>> terms of fin and finack filters look like this: (src fin and dst finack) and
>>> (dst fin and src finack)?
>>>
>>> I want to make sure I get my defitions right for a paper.
>>>
>>> Thanks,
>>> Nick
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20080828/802b6ffe/attachment.html>