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

From: Sandy Murphy <[email-masked]>
Date: Fri, 21 May 2004 15:16:24 -0400 (EDT)

>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.

I agree with this wholeheartedly!

The choice between (a) rare timeouts (b) rare aborted connections
and (c) new and unusual splinter case code added to implementations
came down to (a), IMHO.

--Sandy

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

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Fri, 21 May 2004 15:59:03 -0400

Sandy/All:

If there are NO other serious objections.. I will remove
the corner case description and drop it completely..

Speak now if you object...otherwise I will massage some of Mitesh's
wording into that section as appropriate for the -01 version :-D

R

-- 
Randall R. Stewart
ITD - Transport Technologies
815-477-2127(o) or 815-342-5222(c)

---

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

> the corner case description and drop it completely..

I think the corner case should be mentioned along with the rationale for
not treating it specially.

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Fri, 21 May 2004 16:15:53 -0400

>not treating it specially.
I believe that is what Mitesh's wording (or at least some of
it) covers :-D

R

---

From: Allwyn Carvalho <[email-masked]>
Date: Fri, 21 May 2004 18:11:17 -0700

FWIW, I think this is okay.
Allwyn.

---

From: Allwyn Carvalho <[email-masked]>
Date: Fri, 21 May 2004 18:38:23 -0700

Thinking about this some more for the corner case.  How about: if we are in SYN-SENT state and we receive a valid ACK without a SYN, then send RST?  If both sides of the connection implement this fix, won't this solve the corner case problem?

Allwyn.

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Sat, 22 May 2004 06:57:49 -0400

>Thinking about this some more for the corner case.  How about: if we are in SYN-SENT state and we receive a valid ACK without a SYN, then send RST?  If both sides of the connection implement this fi…
Allwyn:

hmm.. lets see

SYN-SENT ------------SYN------->

                                        hits corner case
        <-------------ACK()
---------------------RST----------------->

Now if the RST is exactly the seq number in the
ACK and we send a normal ACK..  Yep.. that would work..

R

---

From: Anantha Ramaiah <[email-masked]>
Date: Sat, 22 May 2004 22:25:56 -0700 (PDT)

> ACK and we send a normal ACK..  Yep.. that would work..

I thought about this before and this would mean change in the SYNSENT
processing in the RFC but wasn't really sure if we would break
some implementations and may be missing some corner cases...

First of all the side which is in SYNSENT state cannot really know if the
other side has hit the "corner case"??

TCP is always (mostly) a 3 way handhake like:

SYN  ------->
SYN-ACK <-----------
ACK --------------->

Except in case of simultaneous open both sides sending a SYN which is
slightly different since both the sides has to transition from
SYNSENT to SYNRCVD to ESTAB.

But
there is no such thing like a "4 way HS"
SYN --------> [move to SYNSENT state ]
<------------ACK ( Valid ACK would get dropped anyway and no state change)
<-------------SYN
--------------> ACK

Because as per simultaneous open you have to transition to SYNRCVD state
which means you should be sending SYN+ACK and not just the ACK.

So I am wondering why we should we even honor a acceptable ACK in SYNSENT
state, just reply with RST? In other words why would a RFC compliant host
ever reply ACK an SYN seperately on receiving an incoming SYN? It is
really useless because the other end will timeout waiting for a
SYN+ACK and just a plain ACK? [ just in case you want to take time
to send a SYN+ACK back]

May be I am missing some cases?

-Anantha