Subject: Re: [tcpm] SYN's in draft-ietf-tcpm-tcpsecure.txt :-)

From: Sandy Murphy <[email-masked]>
Date: Thu, 20 May 2004 15:51:03 -0400 (EDT)

>You are encouraged to see my reply to that too :)
>
>"To send the ACK with RCVNXT -1, which would generate the RST but
> only on some systems ( RST with RCVNXT -1 is treated as a RST
> of a keepalive packet) it is acceptable, but on others it is 
>  dropped"

Ah.  I thought the "only on some systems" applied to the generating
the RST or the "it is acceptable" applied to the ACK.  I should
not have been so literal.

--Sandy

_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Sandy Murphy <[email-masked]>
Date: Fri, 21 May 2004 09:33:39 -0400 (EDT)

>Hmn, that case won't be seen if segment processing is done in the order
>specified by RFC 793.  The SYN flag will be trimmed off and SEG.SEQ will
>be incremented before the first step (page 69) before the SYN flag is
>examined in the fourth step (page 71).

Now I'm confused.  In your first message you said:

>This particular case motivated me to move the SYN handling code from
>after the segment is trimmed to fit the window to before the segment is
>trimmed to fit the window in the vulnerability fix that I am proposing
>to implement in FreeBSD.

So where does your new code fit?

--Sandy

---

From: Sandy Murphy <[email-masked]>
Date: Fri, 21 May 2004 14:20:51 -0400 (EDT)

On 20 May, Don Lewis wrote:

>On 20 May, Sandy Murphy wrote:
>>>    RCV.NXT < SEG.SEQ || RCV.NXT >= SEG.SEQ+SEG.LEN
>>>        Just send an ACK and drop the segment.  If we received a
>>>        legitimate SYN, the ACK will trigger a RST response.
>> 
>> In the "corner case" that's the current topic of conversation,
>> SEG.SEQ = RCV.NXT-1.  That means that SEG.SEQ+SEG.LEN = RCV.NXT.
>> Which means that the ACK would look to a SYN-SENT peer like an
>> acceptable ACK, but with the SYN not set, the segment would be
>> dropped and ignored.  Leading to new SYN's until timeout.
>

I think I see better now - you are talking about the current RFC793
processing of the corner case SYN, not your suggested improvement cases.

The SYN could only be trimmed if the segment overlapped the window but
the SYN itself would fall outside the window: i.e., if RCV.NXT =<
SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND but SEG.SEQ < RCV.NXT.  Which
would only happen if the length of the SYN was greater than 1.
When the SYN has length 1, and SEG.SEQ=RCV.NXT-1, the segment is
totally outside the window and an ACK is generated.

But.

That observation points out that a SYN that carries data that makes
the segment overlap the window does not need to be considered in the
corner case processing at all and my previous message was wrong.  The
SYN will disappear in the trimming process.  It would be another case
of blind data injection instead.

--Sandy