[Snort-devel] Flags keyword still doesn't treat rserved bits as ECE and CWR

Joshua.Kinard at ...3108... Joshua.Kinard at ...3108...
Mon Apr 11 21:29:52 EDT 2011

Hi snort-devel,

Back in the December timeframe, I sent in a patch to relabel '1' and '2'
to become 'C' and 'E' in the 'flags', as these bits are now official,
per RFC 3168.

In the ChangeLog for snort-, I see this:

  * src/detection-plugins/sp_tcp_flag_check.c:
    Changed the reserved bits flags "1, 2" to "C, E". The old values can
    be used for backwards compatability.

Yet, as of snort-, if I look in
src/detection-plugins/sp_tcp_flag_check.c::ParseTCPFlags(), I see only

            case '1': /* reserved bit flags */
                idx->tcp_flags |= R_RES1;

            case '2': /* reserved bit flags */
                idx->tcp_flags |= R_RES2;

The the patch I submitted should have changed that area to consider 'C'
and 'E' (while keeping '1' and '2' as well).  The manual's TeX code was
also not updated.

Was this patch missed by accident?

It seems one additional bit of the reserved field in the TCP header has
a use now as the 'NONCE', or 'N', flag.  I see references to it in the
Snort source, but uncertain of how well supported it is.  Flags does not
currently check for this bit.  Is this of interest?  Might the remaining
two reserved bits be worth checking incase they contain invalid bits
(kind of like fragbits checking the 'R' or "evil bit")?

Also curious, I see references to TCP options, such as SACK, MSS, etc,
but there does not appear to be a dedicated rule option to parsing and
checking the TCP options field.  Has this ever been considered?  I know
it's a fairly complicated field from looking it up (SACK especially
deals with some variable data), so checking this might need multiple new
rule options.



More information about the Snort-devel mailing list