El 28/07/14 15:28, Eric Rescorla escribió:
On Mon, Jul 28, 2014 at 6:08 AM, Derek Fawcus
<[email protected]
<mailto:[email protected]>> wrote:
On Mon, Jul 28, 2014 at 08:57:10AM +0200, marcelo bagnulo braun wrote:
> One of them is whether to protect or not the TCP header.
Yes. At least the RST flag.
Unfortunately RST is precisely the situation that's most problematic,
because it's also how the other side behaves when it has lost state,
perhaps due to a reboot. So, it seems like we at least want RST
protection to be optional. And if we're not protecting RST, it's
generally not worth protecting other headers, AFAICT.
mmm, is there a sysmtematic study about attacks using the different TCP
headers that we can look at to figure out if this is the case?
-Ekr
> I would like to start the discussion on this topic. Arguments on
one way
> or the other?
I'd like to be able to know that a RST was generated by the remote
peer,
and not simply spoofed by a middlebox.
If the middlebox wants to break the connection, it can do so by
blackholing (and maybe ICMP unreachable) the traffic after it
decides the connection should be dropped.
At least that way, the two scenarios are distinguishable.
.pdf
_______________________________________________
Tcpinc mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/tcpinc
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
