next up previous contents
Next: Performance Analysis Up: Operation Verification Previous: Request or Reply Exceeds

 

Backward Compatibility

Because T/TCP is a superset of TCP, it must be able to communicate seamlessly with other hosts not running T/TCP.

There are a couple of different scenarios in this situation. Some implementations hold the data in the SYN until the three way handshake has passed. In this situation the client only needs to resend the FIN segment to let the server know that all the data has been sent. The server then responds with normal TCP semantics.

In other implementations, the SYN segment is dumped once it has been processed, including the data sent in the initial SYN. The server sends a SYNACK acknowledging only the SYN sent. The client times out after a period and resends the data and FIN. The server then proceeds as normal.

When testing the implementation for backwards compatibility, an unusual feature (bug?) of Linux was found. When a SYN is sent with the FIN bit set, the Linux host responds with the SYNACK segment but with also the FIN bit turned on. This causes the client to mistakenly believe that the server has sent the reply back to the client.

This problem was traced to the way Linux constructs its SYNACK segment. It copies the header of the original SYN (and so all the flags) and then sets all the flags except the FIN flag. This results in the Linux host sending a FIN without knowing it. This was pointed out to the developers of the Linux kernel, but their reasoning was that T/TCP leaves a host open to a SYN flood attack and as such should not be allowed into main stream protocols.

As it turned out, it was only a small check that was needed to solve this problem.


next up previous contents
Next: Performance Analysis Up: Operation Verification Previous: Request or Reply Exceeds

Mark Stacey
Thu Apr 30 12:26:11 IST 1998