On 1 August 2014 14:28, Eric Rescorla <[email protected]> wrote: > The issue isn't middleboxes; it's that if you require integrity protection > for RSTs, then there's no way for a box that reboots to send you an > RST.
I'm starting to think that we might need something more nuanced here. The existence of race condition attacks suggest the need to be able to identify bad actors in some cases. If we do want to expand protections to some of the header, it might be good to be able to identify when the header is bad and then have the option of ignoring that. The rules for deciding whether to accept or discard might be less than trivial, which might ultimately make this a foolish enterprise, but I'd like to at least explore the consequences some. For RST, this is trivial. A RST without any authentication tag (regardless of where that might appear) can be easily identified. An example handling policy might have an implementation delay any actions based on an unauthenticated RST and only ignore the RST if authenticated packets appear afterwards. The same approach doesn't apply to cases where middleboxes strip options (a common practice, I hear). I think that some analysis is required. If that turns out to be too hard, then I'm thoroughly inclined to suggest we actually do what we understand. _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
