Subject: RE: keep RST data nonstandardized for the future!

From: [email-masked] (Jerry Toporek)
Date: Wed, 2 Aug 2000 00:31:59 -0700

> 
> It would be interesting for Apple, Sun (Solaris), and/or Mentat to perhaps
> provide a list of the messages that they currently return so we get an
> understanding of what the possible reasons they've captured are?
> 

Here's where the discussion left off exactly three years ago...

> From jt Wed Jul 30 02:15:28 1997
> To: [email-masked]
> Subject: Re: RST data - meanings
> X-Sun-Charset: US-ASCII
> Content-Length: 1507
> X-Lines: 37
> Status: O
> 
> > Sorry to hurry you on the RST types, but I'm hoping to put the
> > draft in for the IETF deadline - in around 2 days I think...
> > 
> > I'll certainly make sure that the proposed standards deviate
> > as little as possible from your usage anyway
> 
> Ok...  Here's what we have...  It's a pretty shabby collection so I have
> added some commentary in parens to help interpret...
> 
> tcp_accept, state changed	(something weird happened to accepting stream)
> tcp_close, couldn't detach	(resource allocation failure)
> tcp_close, abort rqstd		(SO_LINGER with time -1)
> tcp_close, unread data
> tcp_close, during connect
> tcp_disconnect			(T_DISCON_REQ)
> tcp_eager_blowoff, can't wait	(T_DISCON_REQ before accept)
> tcp_kill_conn			(administrative request to abort connection)
> tcp_kill_conn_by_addr		(same thing, different flavor)
> tcp_lift_anchor, can't wait	(listener closed before accept)
> TCPS_LISTEN-TH_ACK		(unexpected ACK bit while in LISTEN state)
> TCPS_LISTEN-TH_BAD_SECURITY	(bad security specification)
> TCPS_LISTEN-TH_BAD_PRECEDENCE	(bad precedence)
> TCPS_SYN_SENT-Bad_seq
> TCPS_SYN_SENT-Bad_sec_or_prec-TH_ACK
> TCPS_SYN_SENT-Bad_sec_or_prec
> Bad_seq_or_prec-TCPS_SYN_RCVD
> Bad_seq_or_prec
> TH_SYN				(SYN bit with unexpected sequence number)
> TCPS_SYN_RCVD-bad_ack		(SYN-ACK that doesn't ACK SYN)
> new data when detached		(new data received after close)
> TCPS_TIME_WAIT-TH_ACK		(inexplicable segment with ACK while TIME_WAIT)
> TCPS_TIME_WAIT-???		(similar, but no ACK bit)
> 
> Pretty ugly, actually, but helpful for customer support.
> 
> jt
> 
>

---

From: Ian Heavens <[email-masked]>
Date: Wed, 2 Aug 2000 15:52:59 +0100

I've actually written 75% of this draft and included Jerry's codes
that he helpfully sent me three years ago!  Also as far as I am aware
Mentat is the ONLY TCP stack in wide circulation to use these codes.
So if the providers of Mentat-based stacks (HP, Solaris, Apple) are
willing to participate in and implement these codes (the internet draft
will include example code), we have "de facto" standardisation or
at least an example.

I've spoken to William from HP on this.  I suggest he, I and the Sun
TCP people coauthor the draft. William pointed out that the biggest
win would be to get the Microsoft stacks to include the error codes
so we should approach them too.

I've also discussed this with Alison Mankin and we can take this (and other
RST issues ) to the Transport Area WG for discussion as needed.  She
supported the idea (let's face it, if you've ever had to work out why
the heck a TCP connection has aborted for no obvious reason, any clue
is useful).  My thought was to present it as an Informational RFC .  This
could go on the standards track if there was enough interest - which
would then get it into more TCP stacks.

I followed the FTP/SMTP code / string idea in the draft as Rick suggested

cheers
ian 

-- 
Ian Heavens, Spider Software Ltd., http://www.spider.com/
8 John's Place, Leith, Edinburgh EH6 7EL. 
Tel +44 131 475 7015 fax. +44 131 475 7001  [email-masked]

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 02 Aug 2000 11:13:20 -0700

> Mentat is the ONLY TCP stack in wide circulation to use these codes.

ONLY has no relevance to WIDE; it's the ONLY or it's not.

The problem with data in the stream is multi-dimensional. First of all,
the specs let anybody do anything, and I guarantee that somebody is
doing something that won't be appreciated. It is highly likely that
there are at least a few implementations which (1) use some format you
do not, (2) leave binary data as leftovers in the RST, or (3) will do
something else in the future since the spec allows it.

If we are going to standardize on the interpretation of errors, then the
representation should be standardized in such a way that interpretation
is not likely. Reverse-standardizing on legacy representations does not
satisfy that objective. In other words, if we find out that in some
particular scenario there are many stacks which leave binary junk in the
data stream for RST then your spec will be instantly broken.

> I followed the FTP/SMTP code / string idea in the draft as Rick

That will make legacy Mentat implementations non-compliant, and will
require coding around.

The primary benefit of an RST option is that the representation of the
failure is removed from the datastream, guaranteeing that the only
implementations who do anything with it are the implementations who know
WHAT to do with it explicitly.

A secondary benefit is that TEXT data is not required, but instead there
is room for explicit codes/types in 2 bytes of option data (four bytes
if you include all the option overhead which isn't necessary with
options that are not variable-length).

Trying to do this in the free-form datastream is a bad idea all around,
I believe.

-- 
Eric A. Hall                                      http://www.ehsco.com/
Internet Core Protocols        http://www.oreilly.com/catalog/coreprot/

---

From: Alan Cox <[email-masked]>
Date: Wed, 2 Aug 2000 21:10:03 +0100 (BST)

> something else in the future since the spec allows it.

Actually I am more concerned with (4) - corner cases

Do we do PMTU discovery on RST frames that are now too long to fit through
a gateway. Remember the RST can be the reply to the SYN so we have no
prior history here. I guess the RST has to go out < 576 bytes long and not
set DF ?

Now next question:

What language are the RST strings in. Are they UTF8 encoded, how do I use
a TCP option to indicate the language I want the reply in

[Or read] Why the hell are we sending random bits of western european language
only text around anyway ?

Alan