On Tue, Jul 29, 2014 at 4:19 PM, Martin Thomson <[email protected]> wrote: > On 29 July 2014 10:09, Ted Hardie <[email protected]> wrote: >> Not to cross the streams or anything, but I'm wondering why an API >> requirement to protect the headers couldn't be inserted here. Obviously >> there are costs in latency in some of the RST cases described, but if it is >> an available knob, presumably it could get set when it is important to an >> application and left unset when not. > > Probably. In this case, the knob might govern the reaction to an > unprotected RST, rather than whether it is protected. You could > protect RST always and then ignore an authentication failure in some > circumstances too (say, on an idle connection).
This is cryptographic protection we're talking about. Which means either the recipient will have to try N different variations on the header to try to authenticate the message, or we'll have two different authentication tags. Neither approach is reasonable. It's all or nothing. Either the TCP header is authenticated or not. The obvious problem is NAT traversal... Sure, you can leave the port numbers out, but middleboxes might still rewrite the sequence numbers, and if you don't protect the sequence numbers... The obvious thing is to repeat the sequence numbers. Man, IPsec is starting to look good: it has these issues covered. > The trick will likely be working out what the right knobs are. Or, if > we subscribe to the "no API == success" school, that means some other > difficult decisions, like whether we want to define what "idle" means. No please. Always protect as much as possible, at least by default. Nico -- _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
