
Inappropriate TCP Resets Considered Harmful (2002) - based2
https://tools.ietf.org/html/rfc3360
======
JoshTriplett
This should have a [2002] suffix.

A closely related contemporary document, talking about the then-new use of one
of the reserved bits for Explicit Congestion Notification (ECN):
[http://www.icir.org/floyd/ecn.html](http://www.icir.org/floyd/ecn.html)

~~~
i336_
Came here to say the first line; +1

------
kazinator
> _RFC 793 and RFC 1122 both include Jon Postel 's famous robustness
> principle, also from RFC 791: "Be liberal in what you accept, and
> conservative in what you send."_

Which is complete nonsense that doesn't justify anything and only casts
suspicion on the muddled reasoning.

The correct principle is: _be conservative in what you send, and loudly reject
nonconforming, out-of-spec input._

"Be liberal in what you accept" results in situations like some broken piece
of HTML, CSS or JavaScript working in seven diffrent ways on seven different
browsers.

> _However, the phrasing in RFC 793 does not permit sending resets in response
> to TCP packets with a non-zero Reserved field, as is explained in the
> section above._

Non-zero in a reserved field that has no meaning now, and should be loudly
diagnosed as an error until such a time that it has a meaning. Resetting a
connection is a good facsimile of such a diagnostic.

Just like in a C program if you use a name like __foo that is reserved, cows
can fly out of your nose; but diagnosing it is better: diagnosing it now,
while it has no meaning. Once __foo gets a meaning, it will be too late.

If connections are reset when their machines send packets which infringe on
reserved fields, they will quickly learn to fix things so that their machines
stop sending that. Then when the time comes, it will be possible to actually
assign a use to a previously reserved field.

If everyone uses a reserved field willy-nilly and never gets punished with
RST's, it will be difficult to impossible to introduce a standard new use for
that field. Hosts receiving the field will not know whether they are getting a
genuine request with the new meaning of the field, or whether they are getting
garbage which is a continuation of the widespread abuse of the field. And at
that time, it will no longer be possible to send a RST due to the ambiguity,
right? The time to spew a RST in the face of the offending systems is _today_.

The original meaning of RST is to inform the sender that they are sending data
for a connection that doesn't exist. Sending a RST for a nonzero value of a
field is a logical extension of this: it's a piece of data destined for
something that doesn't exist: namely, the meaning of that field! The bits
aren't, ahem, _connecting_ with a meaning. See?

Really, what is the point of a rule that is not _enforced_? If sender are
supposed to leave something zero, but nobody checks that and takes any action
against nonconforming senders, why document such a requirement at all?

~~~
Gibbon1
A while back I needed to re-implement the wheel, an extremely minimalist
routing protocol. I asked my smart friends what to do and one of them
helpfully gave me a really good book by a guy that spent about 30 years
implementing networking 'stuff'. Reading through it he pointed out that at the
bits/bytes level a lot of protocols are broken because of the lack of a
version field[1].

If you have proper versioning you can say; for packet format 001, the field
foonarg[1:3] must be 000. And if it isn't it must treated as garbage and
tossed. If you don't have versioning, you're kinda stuck with a bunch of ad-
hock methods. Stuff like the this unused (we hope) bit in this field is never
set this way for this format. Or this packet is 87 bytes long thus it must be
this format. _head desk_

If you ever have to design binary or even text based data format that needs to
be shared add a version field, you'll hate yourself less later.

~~~
tilt_error
Could you shed some light on which book you are referring to?

~~~
Gibbon1
Digging through my piles of books, it's this one, outdated if you're
interested in current stuff.

Interconnections Bridges Switches and Internetworking Protocols by Radia
Perlman

[http://www.amazon.com/Interconnections-Bridges-Switches-
Inte...](http://www.amazon.com/Interconnections-Bridges-Switches-
Internetworking-Protocols/dp/0201634481)
[https://en.wikipedia.org/wiki/Radia_Perlman](https://en.wikipedia.org/wiki/Radia_Perlman)

------
paulmd
Among other things, this specifies dropping of packets with the "evil bit"
set.

It sounds like this is not the only use that the reserved fields have been
applied to. Zeroing a field is certainly not ideal for the liberal acceptance
proscribed by Postel's law.

~~~
simoncion
I'm... clearly not parsing any of your statements correctly.

As I read it, _one_ of things the linked IETF BCP document does is to implore
authors and configurers of TCP software to ignore and pass through -unchanged-
TCP options that they don't understand, rather than to consider them invalid
and abort the connection.

Did I misunderstand the linked BCP?

------
cyphar
RFC 793 shouldn't have been so strong as to say that the "reserved field MUST
be zero". If I was trying to implement the standard, I would consider such a
packet invalid in the same way that a packet with an invalid checksum is
invalid. You can't use such strong language and then blame implementations for
taking such language seriously.

