David Mazieres wrote this message on Mon, Jul 28, 2014 at 08:57 -0700:
> If we are going to protect any header bits at all, I argue it makes
> sense to have a per-connection option to protect against RST, because
> the benefit/cost ratio is very high. It's trivial to condition the
> header integrity check on RST being clear or some socket option being
> set. Conversely, for proposals that aren't designed to protect any
> other header bits, adding RST protection could be a big burden.
The issue I have w/ RST protection is that it's main feature is to
prevent a DoS attack by breaking the connection, but is this really
useful? As we are already dealing w/ TCP, it is expected that the
layers above TCP deal w/ unexpected disconnects... So, the question
is, does protecting the RST buy us much for the upper layer for the
pain that it requires in the protocol...
IMO, it does not... Even the timeout proposal makes the protocol more
complicated, for limited gains.. Yes, it would prevent companies like
Comcast (they testified before the FCC that they did this) from killing
your connections, but it's an expected behavior of the internet...
How many connections (percetage) would be protected by adding this vs.
the complexity to the protocol?
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
