> >> * 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.
Sure. This is very well-known. This was excessively discussed in the MPTCP WG during the encoding discussion some years ago. 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. (A general question could be if any long option scheme needs a solution to deal with endsystems that completely run out of memory. This has never been a real issue for 40B options. If we allow for 1KB+ options, low end devices could be a concern. For long options, this is not at all specific to tcpinc and encoding issues IMHO should be discussed in TCPM.) > 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. I still don't understand how this can be an issue if the actual buffer and possibly RWND considers the encoding overhead. 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. > >> * 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. 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. 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)? Michael _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
