Full docs about ra output?

[Matt Brown]

Thanks for the detailed reply.  I suppose to thoroughly understand,
reviewing the source would be best.  Where in the source is the code to
determine the dir?

Thanks very much,

Matt
On May 29, 2012 12:45 PM, "Carter Bullard" <carter at qosient.com> wrote:

> Hey Matt,
> OK, …, so  ,…., the direction indicator is  the result of a pretty simple
> algorithm that tries
> to discern who started (initiated) the flow.  This is important, as the
> destination port,
> from the perspective of the initiator, is almost always the service port,
> and understanding
> the client / service can be pretty important .
>
> For connectionless traffic, like UDP traffic, we can't " know " who really
> initiated a
> request / response volley, but you can attempt to use the protocol and the
> port numbers
> to surmise who is the requestor, and who is the responder.  Argus doesn't
> do any of
> this guessing, it tries to be as simple as possible, providing the hints
> in its output, so
> that the client programs can make the decision.  This may seem more
> complicated
> that it should need to be, but with so many forged packets trying to beat
> stateful firewalls,
> its important to try to determine these relationships.
>
> What argus will do, is guarantee that the flow state, as perceived on the
> wire, is well
> represented.  So argus will always report flows where the source and
> destination
> identifiers (IP addrs for example) are derived from the first packet
> observed.  Argus
> will also provide as many hints as it can, to help client programs change
> that
> assignment, if needed, to report the state of a flow.
>
> This is important, when trying to deal with flows with long idle times,
> asymmetric routing
> situations, failure conditions, spurious packets and forged packets used
> for scanning.
>
> The simple status information that netflow like flow models provide is not
> sufficient for
> understanding the initiator of most TCP connections (masking the TCP flags
> together,
> loses critical information), so argus tries to provide more information,
> to solve this
> problem, and the direction indicator is the result of processing this
> additional information.
>
> So, the algorithm is pretty simple.  If we're working with TCP, and argus
> saw the SYN
> or SYN_ACK flag combinations, then we've got a good idea of who initiated
> the connection, and the direction indicator uses a " - " as the central
> character.  In this
> case, the arrow will point from initiator to responder / target.  Other
> algorithms may
> flip the addresses, but the error should always point from initiator
> (source) to target (dest).
>
> If we haven't met these conditions, you get a " ? ", and the arrow will
> indicate the direction
> of data.  So ?> and <? are uni-directional flows, without connection
> setup.  <?> are
> bidirectional flows without connection setup.
>
> You can do this test yourself with this filter:
>
>    tcp and (syn or synack)
>
>
> For connectionless traffic, UDP for example.  There will not ever be a " ?
> ", and the arrow
> is there simply to indicate direction of traffic. " -> " and " <- " are
> unidirectional flows, and
> " <-> " are bi-directional flows.
>
> You can do this with filters as well:
>
>    not tcp and src pkts gt 0 and dst pkts 0
>    not tcp and dst pkts gt 0 and src pkts 0
>    not tcp and dst pkts gt 0 and src pkts gt 0
>
> Just as examples of course.
>
> Hope this is useful !!!!!!  Don't hesitate to ask, comment, criticize
> whatever,
>
> Carter
>
>
>
> On May 25, 2012, at 6:31 PM, Matt Brown wrote:
>
> Here is a pastebin of some of the records I am talking about:
> http://pastebin.com/c12KvNjk
>
> I'm guessing, from your reply, that <? and ?> mean "I tried, some things
> tell me that it goes in this direction, but I'm not 52-100% sure?"  Or is
> that 52 a 99?
>
> This is skype traffic for sure.
>
> Thanks for your assistance, Mark.
>
>
> -Matt
>
>
> On Thu, May 24, 2012 at 10:33 PM, Matt Brown <matthewbrown at gmail.com>wrote:
>
>> Thanks Mark.
>>
>> I'll grab some stuff out of the DB I populated and reply to this thread.
>>
>> I'm really focusing on creating a variety of macro views and trying to
>> figure out how to consider 'dir' in those derived views.
>>
>> I'm currently focused on the easy stuff as pivot points, source and
>> destination: bytes, packet count, address and port. But I am interested in
>> leverage other parts of the DSR as well, if they are useful. (am I using
>> DSR right?)
>>
>> I'll spend more time reviewing other threads as well as the NSMwiki, but
>> any further examples of how people create macro views of the data, versus
>> considering solely 'dir,' would be appreciated.
>>
>>
>> Thanks,
>>
>> Matt
>>
>>
>>
>> On Thu, May 24, 2012 at 9:39 PM, Mark Poepping <poepping at cmu.edu> wrote:
>>
>>>  Taking a stab (trying to relieve Carter of some of the burden)…****
>>>
>>> ** **
>>>
>>> For directionality specifically, if it’s a well-defined protocol and
>>> argus saw most (if not all) of the packets from the beginning, it will know
>>> the direction, but there are many examples of ordinary and hybrid protocols
>>> where you won’t necessarily know the direction in all cases: peer-to-peer,
>>> ICMP, UDP can all make it hard to understand direction – or direction might
>>> not have meaning.  Packet loss (esp. packet sampling) often causes this
>>> output, and multi-path routing will ‘look like’ packet loss too, depending
>>> on where you’re watching and how your paths are advertised or have evolved
>>> over time.****
>>>
>>> ** **
>>>
>>> On a simple, lightly loaded network (my house), long-running argus
>>> probes generally get the directionality right.****
>>>
>>> At my work, it’s not so simple so it helps to interact with questions
>>> that we have for the data and considerations of probe location and
>>> efficiency given the use cases.****
>>>
>>> ** **
>>>
>>> Hope that helps some, it takes a little getting used to.  If you have
>>> specific questions or confusions, it does help to snap a packet capture
>>> that displays your confusion – that way others may be work with them
>>> directly and try to help you (with no explicit promises, of course).****
>>>
>>> Mark.****
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> *From:* argus-info-bounces+poepping=cmu.edu at lists.andrew.cmu.edu[mailto:
>>> argus-info-bounces+poepping=cmu.edu at lists.andrew.cmu.edu] *On Behalf Of
>>> *Matt Brown
>>> *Sent:* Thursday, May 24, 2012 9:00 PM
>>> *To:* argus-info at lists.andrew.cmu.edu
>>> *Subject:* [ARGUS] Full docs about ra output?****
>>>
>>> ** **
>>>
>>> Hello,****
>>>
>>> I see the man page for ra, but it seems lacking for some DSR value
>>> output.  For instance, there are somethings that aren't implicit, but
>>> appear like they should/were intended to be.****
>>>
>>> Specifically, I see this with 'dir's possible values.****
>>>
>>> The cases if confusion are <? And ?>.  How can argus "not" know the
>>> direction of the transaction "sort of?"****
>>>
>>> Thanks,****
>>>
>>> Matt****
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20120530/a17081d9/attachment.html>