ra / racluster - filter on TCP options

[Carter Bullard]

Hey Jon, et al.
We parse the TCP options and set our own bitmask for the options we currently report on.  At the time it was implemented, seems like its been 15 years, we handled all the TCP options there were.  For some options, we indicate that they were present, for some we tag the direction, for some we actually capture option values.  We added ECN option when it was specified. So we haven't added any options in 5-8 years ?

If we want to add Multipath TCP support, we'll need to do some additional mods.

The Mulitpath TCP option has a bit of information you want to capture, especially the id that the different TCPs share.....So if you want to add Multipath TCP option support, lets scope out what you want in the DSR.
Any other TCP options 

But if we filter for TCP options, we'll need syntax for all the options.

Carter

Carter Bullard, QoSient, LLC
150 E. 57th Street Suite 12D
New York, New York 10022
+1 212 588-9133 Phone
+1 212 588-9134 Fax

On Jun 7, 2013, at 4:08 PM, jdenton <jdenton at itcglobal.com> wrote:

> Carter,
> 
> Found the 'Kind' field of 30 in the TCP Options pointed to MPTCP and RFC6824.
> - Other captures of my data show the same, first field 30 { 0x1e }, MultipathTCP.
> 
> So the ra filter may be simply  ra - tcpopt mptcp
> 
> Regards,
> Jon
> 
> 
>> <dggbfjha.png>
> 
> 
> On 6/7/13 2:23 PM, jdenton wrote:
>> Carter, Dave,
>> 
>> Looking at my traffic the network vendor appears to set the first byte to 0x1e in the TCP Options field.
>> This keeps the traffic normal but allows them to detected the packet.
>> To Dave's point, the TCP Options field is 12 bytes of other 'who knows what' info.
>> Would you need a filter with byte offsets?
>> Wireshark tags it as 'Multipath TCP' but I don't know if that is always the case??
>> Will run a few more captures to see if the 'Multipath' label is consistent..
>> 
>> Regards,
>> Jon
>> 
>> 
>> 
>>> <mime-attachment.png>
>> 
>>> <mime-attachment.png>
>> 
>> 
>> On 6/7/13 1:52 PM, David Edelman wrote:
>>> Carter,
>>> 
>>> I think that we once discussed tcp and udp options and that they were
>>> somehow stored as a long bitmask which accommodated both combinations of
>>> options as well as the possibility of locally defined options. If this is
>>> the case, would it make sense to do something based on the assigned option
>>> number or equivalent name allowing for both options specified and not
>>> specified e.g.:
>>> 
>>> ra - tcpopt mss and not syn
>>> 
>>> ra - tcpopt mss and not tcpopt 0x1a
>>> 
>>> --Dave
>>> 
>>> On 6/7/13 5:36 PM, "Carter Bullard" <carter at qosient.com> wrote:
>>> 
>>>> Hey Jon,
>>>> We definately know what the options are, but I don't have any
>>>> filter support right now.
>>>> 
>>>> I can add something like:
>>>>   ra - tcpopt mss
>>>> 
>>>> I'll need some grammar suggestions for all the options we track,
>>>> which are:
>>>> 
>>>> Maxiumum Segment Size
>>>> Window Scale
>>>> Selective ACK OK
>>>> Selective ACK
>>>> TCP Echo
>>>> TCP Echo Reply
>>>> TCP Timestamp
>>>> TCP CC
>>>> TCP CC New
>>>> TCP CC Echo
>>>> Source Explicit Congestion Notification
>>>> Destination Explicit Congestion Notification
>>>> 
>>>> I can put this in pretty quick, once we figure out the syntax.
>>>> Carter
>>>> 
>>>> 
>>>> On Jun 6, 2013, at 6:14 PM, jdenton <jdenton at itcglobal.com> wrote:
>>>> 
>>>>> Hi Carter,
>>>>> 
>>>>> Hope all is well.
>>>>> Working with some network gear that changes the TCP options on packets
>>>>> it processes, is it possible to filter
>>>>> in the argus-clients based on TCP header options??  i.e. All traffic
>>>>> where  TCP option = 26 or 0x1A.
>>>>> 
>>>>> Thanks,
>>>>> Jon
>>>>> 
>>>>> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20130608/8a07fc66/attachment.html>