[ARGUS] Re: correct?

[Carter Bullard]

Hey Martin,
Sending stuff to the list is important to get others thinking about
the issues.   The retransmission logic has not gotten much list
attention for many years, as most sites use the indication of retrans,
but not the specifics, such as number of retransmissions. BUT, argus
is trying to do something correct here, and I appreciate your pointing
out the design vs reality mismatch.

What I think I will do is investigate it a bit further.  Ip_id is a
strange beast. Argus uses it for fragment reassemply and ICMP response
matching, but other than that, its not a very reliable tag in a packet
Especially since some linux's starting zeroing out the ip_id field when
the Don't Fragment bit is set.  Putting ip_id specific logic in argus
may not be a good investment.

However, you do make a good point, that if there is a discriminator for
a given condition, we want argus to somehow preserve that semantic and
get it into the record.  The best argus can do is keep the last ip_id
and flip a bit if it sees the same ip_id back to back.  Would that help
your analysis?

Carter
 

> From: Martin Olsson <elof at sentor.se>
> Reply-To: Martin Olsson <martin.olsson at sentor.se>
> Date: Mon, 25 Oct 2004 15:39:56 +0200 (CEST)
> To: Carter Bullard <carter at qosient.com>
> Subject: Re: correct?
> 
> 
> 
> On Mon, 25 Oct 2004, Carter Bullard wrote:
>> Hey Martin,
>>    Sorry, but I don't respond to email that is sent directly to me.
>> You need to send bugs to the argus mailing list,
> 
> Ah, sorry. Didn't know that. The manual didn't state any address to send
> bug-reports to, but your address was found there. That's why I mailed you
> directly.
> 
>> but this time I will
>> respond.  I'll try to dig up your mail and resend it to the list
>> if that is what you would like.
> 
> Not neccesary. You know of it now, and hopefully you've put it in your
> todo-list. :-)
> 
> If you are not the only developer of argus/ra*, then you might consider
> resending my bugreports to the list so that others could give teir
> opinions.
> 
>>    You're first email I still need to investigate, as I haven't
>> been able to get to it, maybe today.
> 
> Ok.
> FYI, I see these TCP-keepalive packets in several of our customers
> networks, where ra label them with the "Dst TCP packet retransmissions"
> flag (d). The tcpdump-file I put on your FTP was not a single unique
> occurrance.
> 
>> The second, I'm not sure its a bug at all.  Here is my logic.
>> 
>>    Some machines do not generate sequential ip_id's, in that they
>> generate different ip_id's, but they are not monotonitcally increasing,
>> in fact, they are random.  A packet in the network with the same
>> ip_id is not a violation of any specification, as it can occur on
>> purpose to improve reliability.  With these two points, the
>> occurrence of a packet with the same ip_id is not dubious and as
>> a result its cause is not very specific.  Some OS's, when the Don't
>> Fragment bit is set, do not bother to set the ip_id, and so it
>> can be arbitrary, yet meaningless.  Now some of these ip_id
>> scenarios can be tracked, but some cannot.  As a result, I
>> believe that generating a test for duplicates, based on the ip_id
>> is not reliable enough to put it into argus.
>> 
>>    So, the fall back position is that duplicates are still
>> retransmissions, and so tallying them as such in the TCP metrics
>> is a reasonable thing.
>> 
>> Opinions?
> 
> My problem is that when I read the manual and it states that the flags s,
> d and * mean "TCP retransmissions", then I take it litteraly. I believe
> that the in the flagged sessions, the src, dst or both hosts have resent
> some packets. The way argus works right now one get false positives for
> these flags if some equipment between the source and the destination
> duplicates the packet.
> It would be really great if argus could distinguish between the two cases,
> but I have no knowledge of the inner workings of argus, so I don't know
> how hard this would be to implement.
> 
> If it is too hard for argus to separate duplicates from retransmissions
> I guess the current way is the best. Though you might want to add a note
> about this in the manual. The [sd*] flags indicate restransmissions OR
> duplicate packets.
> 
> 
> As I see it, indicating duplicates in the network is a very nice help for
> the network administrator when using argus for network analysis. It tells
> him that something is not normal, since packets shouldn't be identical
> even if the payload is the same. Some false positives would ofcourse be
> triggered by hosts that do not generate unique ip_id:s, but I'd gladly
> take these few false positives.
> 
> Thanx for great help in network monitoring and analysis!
> /Martin Olsson
> 
>