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

From: Sandy Murphy <[email-masked]>
Date: Fri, 21 May 2004 13:47:25 -0400 (EDT)

Mitesh said:

>2. when the SYN has an ISN of RCV.NXT-1 and is within the window
>of our ESTAB connection, here we are proposing to send an ACK
>with value RCV.NXT-1 and not RCV.NXT-2. 

As Allwyn and Don have pointed out, this is not sufficient if
the SYN contains data.  The restarted peer is going to test:

     SND.UNA < SEG.ACK =< SND.NXT  (*)

to see if the ACK is acceptable.  That means that if SEG.SEQ < RCV.NXT
and RCV.NXT <= SEG.SEQ+SEG.LEN , then no RST will be coming back and
both sides will have to timeout.

     [(*) Actually, the RFC793 text says:
     "If SND.UNA =< SEG.ACK =< SND.NXT then the ACK is acceptable."
     but that's a typo (not addressed by rfc1122) since the = case
     was already treated a few lines above and doesn't make any sense
     to be acceptable anyway]

So the suggested behavior, if it's purpose is to avoid the timeout in
this "corner" case, should be:

2. when the SYN has an SEG.SEQ such that
   SEG.SEQ < RCV.NXT <= SEG.SEQ+SEG.LEN here we are proposing to send
   an ACK with value SEG.SEQ ...

Another interesting point: Don's suggested cases don't attempt to
avoid the timeout of the corner case half-open connections.  He does
attempt to avoid sending useless ACK's, but he doesn't adjust the
ACK's to kill the half-open connections.

--Sandy

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

---

From: Don Lewis <[email-masked]>
Date: Fri, 21 May 2004 11:07:54 -0700 (PDT)

> ACK's to kill the half-open connections.

The biggest problem is the ACK value might have to be decreased by a
large value (the maximum segment size) in order to provoke a RST
response and that would cause the RST sequence number to be equally far
outside the window.  In order to detect the RST, we would either have to
widen the window of acceptable RST sequence numbers, which makes the RST
vulnerability worse, or add a bunch of connection state that keeps track
of the acceptable RST sequence numbers.

My plan is to punt on this case because it should be rare.  Also the
FreeBSD T/TCP implementation falls back to just sending a SYN with no
data if it doesn't see a response after the first few SYN segments.

A possible way to fix this problem is to trigger a keepalive sequence.
If the expected keepalive response is not received, assume that the SYN
is legitmate and drop the existing connection.

BTW, there is also the possibility of a similar problem in the
	RCV.NXT > SEG.SEQ+SEG.LEN
case if the peer has sent additional data segments along with the SYN,
which seems to be legal, though probably a bad idea.

---

From: Mitesh Dalal <[email-masked]>
Date: Fri, 21 May 2004 12:03:49 -0700 (PDT)

> ACK's to kill the half-open connections.

the suggestion looks good, but we had some internal discussion and it
seems that the best way forward is to simply do the following:

Irrespective of the sequence number of the incoming SYN, send an
ACK with ack of rcv.nxt. The corner cases of the SYN having data and
or being exactly equal to rcv.nxt-1 are both present in the base
spec and hence should exist even today.(i.e the timeout) and we are
better off leaving it untouched. the aim was to optimize it for the
corner case, but looks like it might not be worth it.

thx
Mitesh