ra / racluster - filter on TCP options

[David Edelman]

Jon,

The options bitmask that I referred to is just a ordered set of bits each indicating if the option with the type (kind) value equal to the offset into the vector was set or not. In the case of MSS the option type is 2 so bit number 2 in the 256 bit bitmask would be set. (Ignoring optimizations for type 0 and 1 probably make life easier)

TCP options are represented as TLV (Type, Length, Value) objects with provisions for single byte NOOP padding so that options can be 32-bit aligned. The TLV for MSS is 2,4,xx. The type number is 2, the option is 4 bytes long and  16 bits of data. Window scale is type 3, 3 bytes long with a single byte of data. Non-evil TCP stacks add a single byte NOOP after this so that the next option is 32-bit aligned.

Going back to my two original examples, the first asks if TCP option type 2 has its bit set where the TCP SYN flag is not set (a protocol violation) and the second asks is the  option 2 bit set and option 0x1a bit not set.


--Dave


> ----- Original Message -----
> From: jdenton
> Sent: 06/07/13 08:08 PM
> To: David Edelman, Carter Bullard
> Subject: Re: [ARGUS] ra / racluster - filter on TCP options
> 
> 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
> 
> 
> 
> 
> 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
> >
> >
> >
> >
> >
> >
> > 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
> >>>>
> >>>>
> >