3 ms·

> You can only reach consensus if the peers can each receive packets that the other sent. So reaching consensus and testing for reachability in both directions

by sedatk 2y ago

> You can only reach consensus if the peers can each receive packets that the other sent. So reaching consensus and testing for reachability in both directions are the same. No, that's not the intent of a handshake. Assume a hypothetical Internet where every node has guaranteed connectivity to every other node that never fails. Do we suddenly lose the need to do a 3-way handshake? No. It's not about testing connectivity, that's semantically wrong. And what's the meaning of testing connectivity for a connection of an arbitrary length and with a quality of unknown degree throughout? It doesn't make any sense. There is no "knowing the connection is good", there is a process of building up consensus. The peers are only interested in an answer to this question: "Does the other party assume a connection?". If we knew the answer to that question beforehand, we wouldn't need a handshake at all. Reachability, transmissibility are all irrelevant. And, UDP actually works like that. Both endpoints assume willingness to connect. That's why you don't need a handshake with UDP. TCP-FO worked liked that too, removing the need for a TCP handshake completely, because it could persist the consensus information.

toast0 2y ago
UDP doesn't include a protocol handshake, and there is no consensus on if the peers are communicating, unless the application adds that. Lack of consensus/lack of handshake on UDP is why protocols with large responses become tools for DDoS reflection, and TCP protocols with large responses don't. TCP protocols with large responses can still be used for DDoS, but only when the target takes an active part --- either filling its outbound bandwidth to serve the large response to distributed requestors or being induced into making a request with a large response that fills its inbound bandwidth. TCP Fast Open is interesting, but didn't seem to go anywhere. Speculatively including one MSS worth of data in the handshake process seems like it could be useful in some circumstances, but the server side implications of processing a request without an expectation that the client will receive the response are hard. (Of course, TCP can't and doesn't guarantee the client will receive the response, but when you have recent consensus on communication, you can expect it will). The crypto context shows evidence of past communication, but does not show evidence of current communication.
- cryptonector 2y ago
  TCP-FO lets you use recent proof of return routability to get 1 MSS of data in the SYN packet. It's akin (if you squint hard) to multiplexing multiple connections onto one. So TCP-FO ought to have become useful, but mainly it's going to be useful in local networks, not on the big bad Internet. And TCP-FO does require more state on the server.
tsimionescu 2y ago
We don't even need to assume a perfect internet where all hosts are always connected, we just need to assume an internet where all hosts are who they say they are, and there is no way to forge your source address. In that case, yes, you wouldn't need a three-way handshake. The client would send a SYN, the server would send a SYN-ACK plus any data it wants (e.g. an SMTP banner), and the client would send any data it wants as well with the next segment (e.g. an SMTP request). If the server doesn't receive anything, it could re-send the SYN-ACK+data, just like any other packet. The reason this isn't done in reality is mainly that using a server's resources to send a lot of data blindly, in response to a very small request, is wasteful (if the reverse path is not accessible, the server is using all those resources retrying for nothing). It is also dangerous, if the source IP of the SYN is forged, then the server ends up sending lots of data to a victim's IP. This often happens with DNS, for example.

by sedatk 2y ago

toast0 2y ago

UDP doesn't include a protocol handshake, and there is no consensus on if the peers are communicating, unless the application adds that. Lack of consensus/lack of handshake on UDP is why protocols with large responses become tools for DDoS reflection, and TCP protocols with large responses don't. TCP protocols with large responses can still be used for DDoS, but only when the target takes an active part --- either filling its outbound bandwidth to serve the large response to distributed requestors or being induced into making a request with a large response that fills its inbound bandwidth. TCP Fast Open is interesting, but didn't seem to go anywhere. Speculatively including one MSS worth of data in the handshake process seems like it could be useful in some circumstances, but the server side implications of processing a request without an expectation that the client will receive the response are hard. (Of course, TCP can't and doesn't guarantee the client will receive the response, but when you have recent consensus on communication, you can expect it will). The crypto context shows evidence of past communication, but does not show evidence of current communication.

cryptonector 2y ago
TCP-FO lets you use recent proof of return routability to get 1 MSS of data in the SYN packet. It's akin (if you squint hard) to multiplexing multiple connections onto one. So TCP-FO ought to have become useful, but mainly it's going to be useful in local networks, not on the big bad Internet. And TCP-FO does require more state on the server.

tsimionescu 2y ago

We don't even need to assume a perfect internet where all hosts are always connected, we just need to assume an internet where all hosts are who they say they are, and there is no way to forge your source address. In that case, yes, you wouldn't need a three-way handshake. The client would send a SYN, the server would send a SYN-ACK plus any data it wants (e.g. an SMTP banner), and the client would send any data it wants as well with the next segment (e.g. an SMTP request). If the server doesn't receive anything, it could re-send the SYN-ACK+data, just like any other packet. The reason this isn't done in reality is mainly that using a server's resources to send a lot of data blindly, in response to a very small request, is wasteful (if the reverse path is not accessible, the server is using all those resources retrying for nothing). It is also dangerous, if the source IP of the SYN is forged, then the server ends up sending lots of data to a victim's IP. This often happens with DNS, for example.