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

From: Sandy Murphy <[email-masked]>
Date: Wed, 19 May 2004 10:45:14 -0400 (EDT)

There's been a lot of discussion about the modifications to the RST
processing, but not much about the modifications to the SYN processing.

NOTE: All of the following is predicated on an assumption of just what
exactly is meant by "send an ACK segment to the peer but before
sending the ACK segment subtract one from value being acknowledged."
and "send an ACK segment to the peer."  I'm presuming this means send
<SEQ=SND.NXT><ACK=RCV.NXT-1><CTL=ACK> and
<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>.
If that's not correct, just stop reading right here.

Oh, and by the way.  The draft should really spell this out.

The 793 SYN processing produces the desired result if a crashed host
tries to re-connect to its previous partner - that is, the previous
partner's half-open connection would close.  But it produces an
undesirable result if an old SYN arrives - that is, old delayed SYN's
could blow away a perfectly healthy connection if the SEQ is in the
window.

The new processing produces the desirable result that old SYN's in the
window do nothing to an ESTABLISHED connection.  But it appears to me
to have a less desirable result if a crashed host attempts to
reconnect to its previous partner.

If the receiver, A, is in state A.ESTABLISHED and gets a SYN with
SEQ=A.RCV.NXT, then it sends a
    <SEQ=A.SND.NXT><ACK=A.RCV.NXT-1><CTL=ACK>.
If this is a current SYN, then the other end, B, is in state
B.SYN-SENT and the SEQ on its SYN is equal to B.ISS.  So
ACK=A.RCV.NXT-1 is less than B.ISS.  So B sends
           <SEQ=A.RCV.NXT-1><CTL=RST>.
A notices that this is out of its window.  Ordinarily, this would make
A send an ACK with SEQ=SND.NXT and ACK=RCV.NXT, but because the packet
has the RST bit set, it just drops the packet.  So B, the SYN-SENT
side, will retransmit the SYN (causing repeats of this same behavior)
until it times out.

If the SYN's SEQ > A.RCV.NXT, then the ACK is sent with ACK=A.RCV.NXT
and the RST is sent with SEQ=A.RCV.NXT which will cause the connection
to close (baring data in the pipe advancing A.RCV.NXT, but eventually
things should catch up).  So this behavior only occurs when
SEQ=A.RCV.NXT on the SYN.

Could someone confirm that I'm interpreting this (both the 793 spec
and the new draft) correctly?

If I'm correct, does this behavior bother anyone?

--Sandy

P.S.

I've always thought that the 793 behavior when an SYN in the window
was received was potentially dangerous.

If the SYN is a current SYN from a partner who has crashed and
resumed, then resetting the connection is the right thing to do.  But
if this is an old duplicate SYN (in the window) from some previous
connection attempt, then its arrival blows away a healthy connection.
That did not seem like a good thing.

Long ago, when I was studying this, it wasn't that big a deal.  The
most likely scenario was that one connection attempt failed, followed
immediately by one that succeeded, and an old SYN from the first
attempt arrived late.  Given that ISS's at the time typically were
chosen as increments over previous values, it would not be likely that
the ISS of the old SYN would be within the receive window of the new
connection.  Unless the old SYN was delayed so long that the sequence
number had wrapped - hardly likely.

But now that the ISS's are randomly chosen, you've got a
(windowsize/(2**32)) chance of the old SYN being within the window of
the new connection (less chance if successive connection attempts are
delayed by a long-ish time to let old SYN packets die).

So I'm glad to see some modification of the SYN-in-the-window processing.
I'm just not sure this is the best one.

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

---

From: Mitesh Dalal <[email-masked]>
Date: Wed, 19 May 2004 20:14:27 -0700 (PDT)

> <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>.

sorry for late reply. somehow missed it earlier. The
suggestion is to only send rcv.nxt-1 and not 2 ACKs if that
is what you are saying above. Similar points as below were
brought to light on the first day of the draft itself
(April 20 tcpm archive).

> SEQ=A.RCV.NXT on the SYN.

as pointed out by Ananth (April 20), this should apply for SEQ=RCV.NXT-1 and not
SEQ=RCV.NXT as said in draft. For the later case, you continue to use
ACK=RCV.NXT. What we are trying to avoid is send an ACK which will be valid to
the remote end. Hence if we send an ACK with value RCV.NXT in response to an ISN
of RCV.NXT-1, this ACK will be acceptable which we are trying to avoid.
Sending an ACK with RCV.NXT for a SYN of RCV.NXT should be fine and that
is what we are proposing.

Although as you have mentioned above, for the case where we send rcv.nxt-1
ack and the SYN side then sends us a RST with rcv.nxt-1 might not be
acceptable in some implementations that do not have keepalive mechanism. So
letting the remote end time out should be fine as this is a very rare
occurence rather than clean up the TCB. However, if the WG votes for the later
that should be fine too.

Thx
Mitesh

---

From: "Paul Goyette" <[email-masked]>
Date: Wed, 19 May 2004 20:35:16 -0700

Mitesh,

> brought to light on the first day of the draft itself

If I remember correctly, step 3B is going to be changed to

   B) If the SYN bit is set and the sequence number is exactly one less
      than the next expected sequence (SEG.SEQ == (RCV.NXT - 1)) then
      send an ACK segment to the peer but before sending the ACK segment
      subtract one from the value being acknowledged i.e. the value
      being acknowledged should be (RCV.NXT - 2) or (SEG.SEQ - 1).

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Mitesh Dalal
Sent: Wednesday, May 19, 2004 8:14 PM
To: Sandy Murphy
Cc: [email-masked]
Subject: Re: [tcpm] SYN's in draft-ietf-tcpm-tcpsecure.txt :-)

---

From: Mitesh Dalal <[email-masked]>
Date: Thu, 20 May 2004 11:30:12 -0700 (PDT)

>       being acknowledged should be (RCV.NXT - 2) or (SEG.SEQ - 1).

Hi Paul,
we have 2 situations that we are worried about.

1. when the SYN has an ISN of RCV.NXT and is within the window
of our ESTAB connection, here we are proposing to send an ACK
with value RCV.NXT. The remote end will then send a RST with
rcv.nxt seq and we should be able to tear the connection.
So things are fine here.

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. Sorry for the confusing
wording. As Sandy suggested we will spell it out in the next
version. The point why  the RCV.NXT-1 approach will help is
because many OS do have TCP keepalive mechanism and actually
consider an RST with RCV.NXT-1 to be valid. So the actual range
of RST in these implementation is (RCV.NXT-1 to RCV.NXT + RCV.WND).
But again, we will appreciate feedback from the WG about how many
implementations do have keepalive and will accept RCV.NXT-1 RST
valid. If there isnt much support here, we can simply tear down
the connection for this value.

thx
Mitesh

---

From: "Paul Goyette" <[email-masked]>
Date: Thu, 20 May 2004 11:37:48 -0700

> of RST in these implementation is (RCV.NXT-1 to RCV.NXT + RCV.WND).

So, if this is the case, how does #1 differ from #2?  In both 
cases, we will be sending back an Ack segment with <CTL=ACK,
ACK=SEG.ACK> ie we will be acknowledging with the same value
as received in the SYN segment, whether SEG.ACK==RCV.NXT or
SEG.ACK=(RCV.NXT-1).