Nico Williams <[email protected]> writes: >> 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.
In the case of RST, it's not as bad as you describe. If the RST segment has a MAC, the MAC will be correct. The question is what to do when an RST segment carries no MAC to check (i.e., is unauthenticated). This can be locally configured without coordinating with the other side. There's no scenario in which any host needs to try N > 1 different pseudoheaders until it finds a matching integrity tag. > 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. This is why, for instance, tcpcrypt authenticates not just the sequence numbers (which at 32-bits would be useless anyway), but a 64 bit offset from the initial sequence number, which works just fine through pf and other sequence-modulating NAT boxes. Look, all of these proposals can obviously run into issues with particularly aggressive middleboxes. But at least in the case of tcpcrypt, we've been working on this for years and have actual deployment experience. So the stuff does actually work with the common middleboxes like NATs. While there are certainly open issues to discuss, do give us some credit for overcoming a lot of the most basic problems like this. > Man, IPsec is starting to look good: it has these issues covered. I fully admit that I have no experience using IPSec through NATs, though I understand it can be done. Then again, you presumably haven't used tcpcrypt through NATs. I see no a priori reason to assume IPSec covers these issues better than tcpcrypt. In fact, NAT traversal has been a central goal of tcpcrypt since inception; it would be disappointing if it turned out to traverse NATs less well than IPSec, but I'd want to hear specifics. David _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
