Re: Bad options?

[Jeffrey Denton <dentonj () gmail com>]

On Thu, 26 Aug 2004 15:00:28 -0400, daniel.ramaswami () celera com
<daniel.ramaswami () celera com> wrote:
> Hello,
>
> Has anyone had any detects similar to below? Is this a form of fingerprint
> (this being a fingerprint response? Any insight into what the last TCP
> option
> fields may be? I have seen interesting traffic like this before, but have
> not found any text that could explain it.
>
> Any help appreciated.
>
> 09:27:21.621476 xxx.xxx.xxx.xxx.http > xxx.xxx.xxx.xxx.46045: . ack
> 3207692596 win 8688 <nop,nop,sackOK,[bad opt]> (DF)
>                          4500 0034 e1a2 4000 3e06 b453 xxxx xxxx
>                          xxxx xxxx 0050 b3dd d43c c6f2 bf31 8134
>                          8010 21f0 980d 0000 0101 0402 4c66 7844
>                          0278 c313
>
> Thanks,
> Dan

IP Header:
4500 0034 e1a2 4000 3e06 b453 xxxx xxxx
xxxx xxxx

First 5 32-bit words of TCP Header:
0050 b3dd d43c c6f2 bf31 8134
8010 21f0 980d 0000

TCP header length is 8.

TCP Options:
0101 0402 4c66 7844 0278 c313

http://www.iana.org/assignments/tcp-parameters

01 = nop 
01 = nop 
0402 = sackOK

4c66 7844 0278 c313

Taking flipped bits into consideration doesn't explain this. 
Tunnelling perhaps?  There's not enough here to determine if ASCII
interpretations of the hex mean anything.

Something else that is interesting, from RFC 2018:
  "The selective acknowledgment extension uses two TCP options. The
   first is an enabling option, "SACK-permitted", which may be sent in a
   SYN segment to indicate that the SACK option can be used once the
   connection is established.  The other is the SACK option itself,
   which may be sent over an established connection once permission has
   been given by SACK-permitted."

"2.  Sack-Permitted Option

   This two-byte option may be sent in a SYN by a TCP that has been
   extended to receive (and presumably process) the SACK option once the
   connection has opened.  It MUST NOT be sent on non-SYN segments.
"

But take the sackOK option in a non-SYN packet as meaning anything
with a grain of salt.

Do you have more of these packets that you could share?  Are you on
the sending or receving end of this packet?  We need more info to
really say anything other than, you're right, it is odd.