> * Deadlock freedom and buffer space control. TCP implementations > provide control over buffer space via socket options such as > SO_SNDBUF > and SO_RCVBUF. Applications should be able to send data > simultaneously in both directions without deadlocking if the data > fits > in the specified buffers. An attacker who reduces the effective > buffer space can mount a DoS attack. Note this primarily applies to > proposals that consume extra sequence numbers for non-payload data. > A > straw man would be an attacker who manipulates the window to induce a > bunch of one-byte segments with eight-byte MACs. These must each > consume one byte of buffer space, not nine.
I am not sure if I understand this issue. Can you elaborate a bit? If the attacker can use SO_SNDBUF or SO_RCVBUF calls, it already has control over the application, right? If the attacker can manipulate RWND, it seems to be an on-path attacker that can do more harm by other means. The overhead of a MAC of 8 bytes for protecting one byte is independent of the encoding scheme (payload/option). Specifically, a TCP stack also requires memory for option storage and processing. Today's TCP stacks typically run dynamic buffer management and should not run into deadlock issues as long they have any available memory, as far as I understand it. Or do I miss something? > * Flow control. People assume they cannot continuously write large > amounts of data to a TCP connection unless most of it is getting > through to the other side. Hence, applications use flow control as a > means of reporting progress (based on bytes written), estimating > transfer completion times, and adapting to network conditions. > Unprotected flow control enables attacks that lie somewhere between > mere DoS and integrity failure. An example is someone trying to > upload a video to either of two servers for safe keeping. The user > starts two file transfers then kills the one that seems slower, when > in fact the fast-looking server is hardly getting any data at all > because the attacker has disabled flow control and is faking the ACK > and Window fields. This would be an on-path attacker, right? Note that manipulating RWND may not be an entirely uncommon Performance Enhancement Proxy (PEP) behavior; at least in the past people suggested this to "tune" TCP performance (or deal with legacy TCP stacks with broken window scaling). Manipulating RWND somehow violates e2e semantics and modern TCP stacks usually don't need this due to RWND autotuning. But I think at least in some environments this was in the past (and perhaps still is) a desired traffic engineering behavior by the operator of the PEP. As a result, I am not sure if such traffic engineering is an "attack". Thanks Michael _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
