"Scharf, Michael (Michael)" <[email protected]> writes:
>> * 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? Currently things like TCP options, while they consume memory at endpoints, do not consume window space. What I am saying is that if you change TCP so that things other than payload bytes written to a socket consume sequence numbers, then the window logic MUST be adjusted to account for that. It's not impossible to do, but it's something that has to be taken into account. Note that the attack doesn't require the attacker making calls to SO_SNDBUF or SO_RCVBUF, or even to be on path. It just requires an application that is deadlock free under the assumption that SO_SNDBUF/SO_RCVBUF is a reasonable value. Then the attacker simply induces behavior that chews up way more sequence numbers than payload bytes. This could be Ajax code in the browser issuing a bunch of tiny writes (after the browser disables Nagle). Or it could be a server sending a bunch of one-byte writes to a (Nagle-disabled) web proxy that does cut-through routing in an effort to deadlock a TCP connection between the browser and proxy. >> * 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". This is an attacker who can eavesdrop on traffic (or guess ISNs) and forge packets, but not necessarily tamper with or block legitimate packets. For this particular attack, RWND isn't the issue so much as forged ACK numbers. By continuously forging ACKs for all sent traffic, the attacker can de-synchronize the TCP connection and then continue on to make the sender think all his data is getting through. E.g., the attacker makes curl -d report 500MiB uploaded at 10MiB/sec, 90% complete, when in fact nothing of the sort has happened. David _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
