Re: ipf - RST packet w. sequence num.

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

My apologies; I read the original mail too quickly and didn't notice
that the zero sequence number in question was not relative.

> ["correct"]

> 00:39:42.934107 IP (tos 0x0, ttl  56, id 0, offset 0, flags [DF], proto: TCP 
> (6), length: 64) IP0.65530 > IP1.17000: S, cksum 0x6e6f (correct), 
> 1925369280:1925369280(0) win 32768 <mss 1460,nop,wscale 
> 3,sackOK,nop,nop,nop,nop,timestamp 1 0>
> 00:39:42.934155 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], proto: TCP 
> (6), length: 40) IP1.17000 > IP0.65530: R, cksum 0x6842 (correct), 0:0(0) ack 
> 1925369281 win 0

This looks right to me.  793 says

    If the incoming segment has an ACK field, the reset takes its
    sequence number from the ACK field of the segment, otherwise the
    reset has sequence number zero and the ACK field is set to the sum
    of the sequence number and segment length of the incoming segment.
    The connection remains in the CLOSED state.

> ["incorrect"]

> 01:01:00.704813 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP 
> (6), length 64) IP0.65522 > IP2.18000: S, cksum 0xbef6 (correct), 
> 2749057555:2749057555(0) win 32768 <mss 1460,nop,wscale 
> 3,sackOK,nop,nop,nop,nop,timestamp 1 0>
> 01:01:00.844241 IP (tos 0x0, ttl 55, id 0, offset 0, flags [DF], proto TCP 
> (6), length 40) IP2.18000 > IP0.65522: R, cksum 0x7756 (correct), 
> 2013055350:2013055350(0) ack 2749057556 win 0

This looks to me like a fairly clear violation of the above spec from
793.

It's possible 793 has been updated in this respect.  The RFC index
lists only two updates to 793 as of 2009-09-19 (1122 and 3168), even
though I know there are various other updates to TCP (eg, 2581); I
don't know of any way to mechanically identify everything that updates
TCP absent correct maintence of the updated-by fields in the index, and
I'm not about to read over five thousand RFCs - or even RFC titles - to
try to find any that might apply here.

The RST generation code in our tcp_input does use 0 as the sequence
number for RSTs under these circumstances, for what that's worth.  Our
RST handling for SYN_SENT connections does not check this, though, so I
infer that the packet never made it to the TCP stack (unless the
SYN-sending host in question isn't NetBSD).

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B