David Mazieres <[email protected]>: On the other hand, there are some very good use cases where you do want > protection against RST, as evidenced by multiple previous ways to do so. >
There may be good use cases, and prior implementations certainly should help regarding the question whether it *can* be done :-) [*], but just that it's been done before doesn't mean that it was a good idea. Well, maybe it was; however, can someone lay down some actual evidence? Specifically, can we get some more clarity regarding the attack model -- what do you expect attackers to do, and what do you expect to achieve by your defenses? I don't think it has been explicitly stated, but the idea is that if you receive a TCP packet and get an authentication error, you simply ignore that package rather than aborting with an error, right? So if you authenticate RST, you can filter out a bogus RST and keep your connection open. However, unless you authenticate more of the header than just certain flags, the same attacker could also acknowledge data that the recipient has never actually seen, thus similarly rendering the connection useless. If we accept that (but then, maybe we don't), why worry about RST? As said before, I think there'd be value in authenticating FIN. For everything else, I'm not that sure; I'd like to see a more coherent and more complete story. Bodo [*] That said, protecting TCP options is optional for TCP-AO, and TCP-AO clearly doesn't have (and isn't designed for) the wide deployment intended for TCPINC, so I'm not that certain after all. Has anyone done an analysis of TCP-AO deployment in practice? Lessons learnt? 2014-07-28 11:57 GMT-04:00 David Mazieres <[email protected] >: > marcelo bagnulo braun <[email protected]> writes: > > > Hi, > > > > As we discussed in the meeting, we should try to make some design > > decisions for TCPINC. > > One of them is whether to protect or not the TCP header. > > I would like to start the discussion on this topic. Arguments on one way > > or the other? > > Can we rephrase the question slightly and ask: "Which TCP header fields > are worth protecting?" Obviously one way forward is to protect nothing > in the headers. But I don't think anyone is advocating protecting the > whole header. (After all, the charter talks about NAT traversal.) > > At the meeting, I also sensed widespread agreement that people > (including me) consider always protecting the RST bit somewhat > problematic, particularly in the short term. That's why, for instance, > tcpcrypt says implementations SHOULD disable RST validation by default. > On the other hand, there are some very good use cases where you do want > protection against RST, as evidenced by multiple previous ways to do so. > > If we are going to protect any header bits at all, I argue it makes > sense to have a per-connection option to protect against RST, because > the benefit/cost ratio is very high. It's trivial to condition the > header integrity check on RST being clear or some socket option being > set. Conversely, for proposals that aren't designed to protect any > other header bits, adding RST protection could be a big burden. > > A common-sense guideline would be to say once we converge on a > high-level tcpinc design, we shouldn't leave any low-hanging fruit. > (This is the same logic by which the charter requires authentication > hooks, even though our anticipated use case is to protect unmodified > legacy applications against passive eavesdroppers. If we go through all > the trouble of standardizing increased TCP security, it's silly not to > let people authenticate connections.) > > David > > _______________________________________________ > Tcpinc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tcpinc >
_______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
