"Scharf, Michael (Michael)" <[email protected]> writes:
> I agree that drafts running into such issues have to address this - > but this seems possible and is just a design detail that has to be > solved. I think we are basically in agreement. This has to be added to the list of things to check in any tcpinc draft, but we should anticipate that it is a tractable problem. > I still don't understand how this can be an issue if the actual buffer > and possibly RWND considers the encoding overhead. It doesn't have to be an issue, but it can be an issue if a protocol is not properly designed. And naively attempting to address the problem could lead to other issues (such as exceeding the receive buffer size). For example, one naive way to solve the problem is to implement payload integrity entirely on top of TCP, almost at a different level of abstraction. Something like TLS already works over TCP, so intuitively one might expect this to work. Well obviously not because now the MACs are going to consume options space and cause deadlock in situations where TCP would have been fine. Okay, so the next thing one might try to do is increase the effective send buffer size to be SO_SNDBUF plus the size of all buffered MACs. But this still doesn't solve the problem, because now what if the MAC is computed over more data than the receive window size? Now the receiver will have a bunch of data whose integrity is unknown, and will not have buffer space to receive the MAC. Okay so now allow sender to exceed the receive window and have the receiver buffer data until the next MAC. Okay, but now an ill-behaved sender could create a giant message that massively exceeds the receive buffer size. These are all obvious straw-men. But the point is that the real solution is a bit more complicated. Since as far as I know none of the sequence-number-stretching tcpinc proposals has even been implemented, it's an open question how exactly flow control interacts with such proposals. > I think most TCP stacks don't run a static, fixed TCP buffer of size > SO_SNDBUF or SO_RCVBUF anyway. In particular packet-based stacks seems > to work differently internally. I haven't tested recently, but in my experience SO_RCVBUF definitely impacted the receive window. More importantly, though, even applications that don't set SO_RCVBUF can reasonably assume they get some sane default value, meaning at least 4 MSS and less than infinity. If tcpinc changes this so the effective receive buffer is tiny, it could cause deadlock. If tcpinc changes it so the effective receive buffer is infinity, this breaks flow control. And obviously, while greater than the buffer size, we want some kind of limit on how much buffer space the kernel needs on the sender or receiver. > There may be (legacy) middleboxes (PEPs) that send such Pre-ACKs if > they know/assume that the path between the middlebox and the receiver > is entirely reliable. This is a violation of TCP end-to-end semantics > and probably not a PEP behavior that the IETF recommends. But, in > particular in satellite environments, this could be a mechanism used > for traffic engineering or performance optimization (I've read about > it one decade ago, maybe those PEPs went away in the mean time). If > used for performance tuning, these ACKs would not be a malicious > attack. Probably better just to terminate the TCP connection, no? Particularly given the prevalence of transparent proxies. If there's a choice between breaking flow control and slightly diminishing the throughput of legacy devices that are new enough to use tcpcrypt but not to increase their receive buffer size, I would prefer the latter. > If an attacker that can inject ACKs into the connection, that attacker > could also send RST or other segments with more impact than a faked > ACK, right? So, this is basically a variant of the question whether to > protect against RST (e.g., with TCP-AO)? Well, you can say it's a variant of RST, but the consequences of the attack are different and the defenses are different, so it doesn't seem that useful to lump them together. RST protection can be implemented locally and unilaterally for a variety of TCP modifications. Checking the integrity of ACKs requires specific support from the wire format. Also, RST kills the connection, so it's basically a DoS attack. ACK forgery causes the application to think things are okay, but return incorrect values for things like percent complete and bytes/second. David _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
