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

From: Bernie Volz <[email-masked]>
Date: Wed, 2 Aug 2000 09:33:29 -0400

Well, it isn't difficult to deal with the backwards compatibility issue
PROVIDED none of these messages start with a numeric value. If the n-digit
code followed by the delimiter is not present, assume the entire message is
text.

Using a TCP option is certainly an alternative.

Note that this data is intended for the RECEIVER of the RST. That end of the
connection will typically still be attached to an application. It would
require a new API call or other means to obtain the message and also
changing the applications to call this new API. So, most applications
already written would not get this information unless modified. Perhaps a
'getsockopt' call of SO_RSTMSGTXT and SO_RSTMSGNUM or some such codes could
be used.

- Bernie Volz

-----Original Message-----
From: Eric A. Hall [mailto:[email-masked]]
Sent: Tuesday, August 01, 2000 9:43 PM
To: [email-masked]
Subject: Re: keep RST data nonstandardized for the future!

> Perhaps an FTP/SMTP/... like response format would be useful - <n>
> digit code followed by a delimiter (space) followed by human readable
> text. That way, TCP itself and/or application can decode the numeric
> code and understand it and the application could also display the
> returned message for the human to read.

I think it's pretty unlikely that applications will get the text if TCP
is burning down the connection. Another problem with reverse
standardization around data in the stream is that not everbody who does
it already will be compliant with whatever approach is finished.

Getting explicit errors out of the data stream seems like the best way
to go if there's real interest in this. Maybe a TCP option would be a
better way to handle a standardized format (as opposed to the legacy ad
hoc approach), since that would allow for explicit codes, types and
text, the latter of which could be explicitly passed to the application.
Another benefit of using an option is that it would be ignored by legacy
implementations as a matter of course.

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

---

From: [email-masked] (Jerry Toporek)
Date: Wed, 2 Aug 2000 08:13:26 -0700

A few observations:

- We've had this feature in the field for most of a decade.  It has been
occasionally helpful and I'm not aware of it ever causing a problem.  (There
was one printer which somehow accepted the strings as data and added them
to the last page, but complaints, if any, never got back to us ;-).

- We have always provided a switch to turn off the feature, but I am not aware
of it ever being used.  The default has always been "on".

- We would be happy to clean up using a code/text format.  As I noted, our
current strings are not uniformly attractive nor comprehensible.

- The suggested set of messages would, of course, have to be extendable.  Some
of ours are very implementation specific and would be meaningless in a general
specification.

- I can't imagine how the information would give a hacker anything that they
don't already have.

jt

---

From: [email-masked] (Jerry Toporek)
Date: Thu, 17 Aug 2000 19:50:03 -0700

> >Bad security makes no sense; TCP has no security (SSL does, so does
> >IPSEC, but then _THEY_ should carry that info, or not. not TCP :-) It'd
> >be inappropriate to send a RST in response to failed SYN authentication
> >(to counter DOS attacks); silence is the best response there anyway.
> 
> I'm not disagreeing with you. Both of these are examples of bad codes. They are
> just two examples of the codes that have been suggested on this list by some
> people. I'm guessing (since I don't know the reason why they were initially
> suggested) that they were probably inspired by the text in page 67 of rfc793.

Yes...  Yes...  That's exactly correct, and I should never have let these
appear on the list that I gave to Ian, because to my knowledge these have
never really been active.  Code was written ten years ago to hypothetically
implement the precedence and security checks suggested on page 67 of RFC 793.
The code was never actually compiled into anyone's product, and no longer
exists.

jt