rtp flow

[Carter Bullard]

Hmmmm,
RTP, as an encapsulation protocol, has its own encryption method, that  
leaves the RTP header
in the clear.  But if you're monitoring skype, it doesn't use RTP, so  
if argus classifies it as
RTP, this is not correct, it should just come up as UDP.

The best way to identify skype is through bandwidth ranges and other  
patterns that are
persistent within the packet header format, but that is a bit more  
complex.

Carter



On Jan 13, 2008, at 11:23 PM, CS Lee wrote:

> Hi Carter,
>
> Now the secret is revealed, that really helps a lot from the  
> understanding point of view.
>
> I think in my case  it is identified via the third scenario where -
>
> 3) a monotonically increasing
> (with some logic for out of order packets) sequence number that
> is in the right place, and packet header and data size length that
> seems reasonable.
>
> The udp streams are encrypted so I don't think the first and second  
> scenario applies, I have seen the out of order packets but that's  
> for tcp, I can send you the data for examination if you want to  
> check it out.
>
> Thanks a lot!!!!!
>
>
> On 1/14/08, Carter Bullard <carter at qosient.com> wrote:
> Hey CS Lee,
> How Argus identifies traffic as RTP or RTCP is a secret ;o)
>
> Actually, this is one of the things that makes Argus a pretty
> interesting program, but I consider the RTP/RTCP classification
> logic as just an example of how Argus can do upper layer
> classification, so it is again an example of how to do a whole
> class of actions.
>
> Both Argus and the ra* programs work together to decide
> if a flow is RTP or RTCP.
>
> For Argus, all UDP traffic that has a very specific pattern in the  
> next
> protocol field are tagged as RTP, and every packet that comes
> by is continually tested for minimal conformance to the pattern.
> If a packet that is matched to an RTP flow can't meet the minimum
> criteria, we toss the RTP/RTCP classification, and the stream
> is reported as just UDP (or whatever encapsulation is below the
> RTP/RTCP layer).   The test is basically: 1) a constant RTP version
> number in the right place, 2) a constant reasonable codec value
> that is always in the right place, 3) a monotonically increasing
> (with some logic for out of order packets) sequence number that
> is in the right place, and packet header and data size length that
> seems reasonable.
>
> We get into some issues with sequence number rollover and
> sequence numbers wildly out of order, and flow restarts sometime
> cause us to recategorize the flow incorrectly, but these are simple
> tweaks I'll be doing in the next few weeks.
>
> This, I think is working very well today (and has been for a number
> of years).
>
> Argus does make a mistake, here and there, reporting non RTP/RTCP
> packets, as RTP.  This is unavoidable, when the number of packets
> in the flow are very low (< 5).  So the ra* programs need to decide
> if there is a misclassification.   The ra* support for RTP/RTCP  
> identification
> is in need of repair, and hopefully I'll get to it soon.  There are a
> handful of protocols that will occasionally be mislabeled as RTP or
> RTCP, they include DNS, AFS and some multicast LDAP transactions.
> We use to have argus() correct the flows when it wrote the flow  
> records
> out, but it became clear that it proved better to report the  
> additional
> information and let the clients decide.
>
> The challenge is aggregation, where many RTP records are
> re-enforcing the assignment to RTP, but one matching records
> suggests that its not.  Hard to know what to do in this situation,
> so I've played with not merging or converting the errant flow
> to RTP.  This is a bit of a head scratcher.
>
> Is this helpful?
>
> Carter
>
>
>
> On Jan 13, 2008, at 2:19 AM, CS Lee wrote:
>
>> Hi Carter,
>>
>> I have recently navigated some network flow and interesting the  
>> skype traffic(encrypted) is smartly identified as rtp by argus. May  
>> I know how actually argus justifies that certain udp flow is video/ 
>> audio stream and decode it as rtp, I have checked out the source  
>> code but there are so many conditions so I hope to hear from you in  
>> more layman term.
>>
>> Thanks.
>>
>> -- 
>> Best Regards,
>>
>> CS Lee<geek00L[at]gmail.com>
>>
>> http://geek00l.blogspot.com
>
>
>
>
> -- 
> Best Regards,
>
> CS Lee<geek00L[at]gmail.com>
>
> http://geek00l.blogspot.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20080114/ab392818/attachment.html>