Generally +1. There is also the case of NATs or state-tracking firewalls and connections they have timed but which are still active at an end-point.
I do wonder if protecting RSTs and thus other parts of the header as well is more tractable with both endpoints using IPv6 (where NAT66 is strongly discouraged and privacy addressing may help some with the reboot case depending how how clients handle rotating priv addrs across reboots) ? Sent from my mobile device On Jul 28, 2014 9:52 AM, "Eggert, Lars" <[email protected]> wrote: > On 2014-7-28, at 15:28, Eric Rescorla <[email protected]> wrote: > > > > On Mon, Jul 28, 2014 at 6:08 AM, Derek Fawcus < > [email protected]> wrote: > > > 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. > > +1 > > Protecting the RST is therefore probably impossible. > > > So, it seems like we at least want RST > > protection to be optional. > > I don't think it even works as an option, because if the other side has > lost state, it needs to send an unprotected RST. > > > And if we're not protecting RST, it's > > generally not worth protecting other headers, AFAICT. > > +1 > > Lars > > _______________________________________________ > Tcpinc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tcpinc >
_______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
