On Mon, Jul 28, 2014 at 6:08 AM, Derek Fawcus < [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. -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] > https://www.ietf.org/mailman/listinfo/tcpinc >
_______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
