"Scharf, Michael (Michael)" <[email protected]> writes:
>> 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). > > Sorry, I still don't understand what buffer problem you refer to, > assuming the protocol design is bug-free. Could you please expand a > bit? Great, as long as we are in agreement that a bug-free tcpinc protocol should not deadlock anyplace a vanilla tcp protocol does, then I think you understand me. In particular, since the specs don't go into this level of detail, we should have an implementation of each proposed protocol to kick the tires and have a sanity check that all of this stuff works. >> 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. > > What deadlock is caused when we would use something like TLS for > confidentiality and something like TCP-AO integrity (or TCP-AO for > both)? TCP-AP does not have this problem, because TCP-AO uses TCP option space. The concern I was raising arises from the complexity of sequence number stretching, as happens when protocols consume sequence numbers for MACs. > Maybe it would help to me to better understand the deadlock if I had a > concrete example. Okay, here's a simple example. Both sides set send and receive buffers of 8192 bytes using SO_SNDBUF/SO_RCVBUF. Then both sides write 16384 bytes. Then both sides read 16384 bytes. Under vanilla TCP, this is deadlock-free because the sending kernel and receiving kernel each buffer 8192 bytes not read by the application. All I'm saying is that I'd like such scenarios to continue to be free from deadlock under tcpinc. They might already be under all existing proposals. Or if they aren't, you might already agree with me that this would have to be fixed in any proposal, in which case your confusion might be why I'm mentioning such an obvious point. Only because I can't tell if all the proposals have this. > As far as I know, SO_SNDBUF/SO_RCVBUF is the *socket* buffer size, > which should not be affected if tcpinc offers a socket interface to > the app, as far as I understand it. > > But the socket buffer may not be the buffer TCP uses - if they were > the same, this would be a specific implementation choice. > > The TCP buffer can be larger. For instance, I think Linux uses for TCP > buffering a buffer significantly larger than the socket buffer: Well, then this requires some investigation. For instance, on at least some variants of BSD, SO_RCVBUF directly affects the advertised window size. So perhaps this discussion should be detached a bit from SO_SNDBUF/SO_RCVBUF. The higher-level point is that scenarios that don't deadlock on particular implementations of vanilla TCP should continue not to deadlock when tcpinc is enabled. > If the MAC for header fields is added in a TCP option (e.g., TCP-AO), > I don't understand why buffer space would be a problem. Correct. I'm mostly concerned about sequence-number-stretching proposals, in which tcpinc consumes more sequence numbers than vanilla TCP. TCP-AO does not have this problem. > I don't understand why one would have to allow a sender to exceed the > receive window. Could you please explain why this would be required? > It violates the TCP specs. I was just throwing out bad solutions. All I'd really like to convince you is that once established, a tcpinc connection should not experience deadlock (even with a passive adversary who can forge packets) where vanilla TCP over a secure network wouldn't experience deadlock. The proposals I was putting forth for dealing with sequence-number stretching were bad. But I'm not necessarily advocating sequence-number stretching. > tcpcrypt seems to have to violate TCP flow control for INIT1/INIT2 > (well, using EDO could possibly solve this problem). We would ideally specify a reasonable minimum window size (like 500 bytes). If it turns out that the window is independent of SO_RCVBUF, then this is easy just to mandate it. Possibly EDO could help, too, though ideally tcpinc would benefit from but not be blocked by other proposals. > Again, please help me better understanding why flow control would be > an issue in any other solution. We don't need an implementation to > understand whether protocol semantics are violated or not. But you > have to explicitly state your assumptions and reason why there is no > alternative to them. Okay, so instead of debating whether it's an issue (some of the other draft authors could just weigh in here), can we just agree that even weird/contrived/controlled-by-malicious-javascript/etc. applications that don't deadlock on vanilla TCP shouldn't deadlock on tcpinc? > The tcpinc WG may have to specify that a stack has to ensure that the > TCP buffer is larger than the socket buffer, or the tcpinc WG may > specify that a TCP endpoint using tcpinc must allocate X additional > bytes e.g. to store out-of-band key/MAC data, and fall back to vanilla > TCP if no RAM us available. Why is this a problem? Exactly. We are agreed. So the only problems are, A) calculating X, and B) making sure we actually specify it. If we agree on these points, then I think you understand my main concern and were just thrown off by my pessimism over whether this would happen with sequence-number-stretching proposals. > Pre-ACKs have been suggested in the past because of the huge RTT in > satellite networks. This large RTT also affects congestion control > (e.g., during Slow-Start). The performance difference could be > significant. > > I agree that a transparent TCP proxy may end up in less issues. Also, > I have no data whether there are indeed middleboxes in the Internet > not terminating the connection but faking ACKs. And none of these > middleboxes are desirable regarding end-to-end TCP semantics. But we > have toaccept that people may deploy middleboxes e.g. in satellite > networks without having attacks in mind. Given how fringe these are, I would settle for such scenarios working more slowly with tcpinc enabled, at least until the ACK-forging boxes are upgraded to do something else (like downgrade connections or terminate them and buffer data). >> 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. > > TCP does not guarantee that data indeed arrives at the receiving > application. TCP only guarantees delivery to the receiving TCP > stack. Thus, an application that cares about payload integrity (in > your example: complete upload) has to verify the byte stream at > application level for standard TCP already. In that case, one can > detect that attack already at application level, right? So, I really > wonder faking a complete upload at TCP level is a real problem. TCP does not guarantee that data arrives at the receiving application, or even receiving host (given send buffering). However, actual real applications in widespread use rely on the fact that TCP's buffers are not infinite so as to estimate upload bandwidth. > In addition, one could very easily detect this attack in many > scenarios. If an application reports an upload rate of 42 Gbit/s on a > 4 Mbit/s DSL uplink, that would certainly be strange, right? They could but they don't. So again, if you believe my principle that an established, authenticated tcpinc connection over an insecure network should behave roughly like vanilla TCP over a secure network, flow control should be secured. Similarly, an established unauthenticated tcpinc connection should behave the same if there was no man-in-the-middle. David _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
