The original protocol specification [3] labeled T/TCP as an experimental protocol. Since the RFC was published there hasn't been an update to the protocol to fix some of the problems. From the previous sections, the benefits are obvious over the original TCP protocol, but is it a case of the disadvantages out-waying the advantages?
One of the more serious problems with T/TCP is that it opens up the host to
certain Denial of Service attacks. SYN flooding
is the term given to a form of denial of service attack where the attacker
continually sends SYN packets to a host. The host creates a sock structure for
each of the SYN's thus reducing the number of sock structures that can be made
available to legitimate users. This may eventually result in the host crashing
if enough memory is used up. SYN cookies [21] were implemented
in the Linux kernel to combat this attack. It involves sending a cookie to the
sender to verify that the connection is valid. SYN cookies cause problems with
T/TCP as there are no TCP options sent in the cookie and any data that arrives
in the initial SYN can't be used immediately. The CC option in T/TCP does provide
some protection on its own, but it is not secure enough.
Another serious problem which was discovered during research was that attackers
can by-pass rlogin authentication. An attacker creates a packet with a false
IP address in it, one that is known to the destination host. When the packet
is sent, the CC options allow the packet to be accepted immediately, and the
data passed on. The destination host then sends a SYNACK to the original IP
address. When this SYNACK arrives, the original host sends a reset as it is
not in a SYN-SENT state. This happens too late as the command will already have
been executed on the destination host. Any protocols that use an IP address
as authentication are open to this sort of attack. There are methods of avoiding this security hole. Kerberos is a third party
authentication protocol but requires the presence of a certification authority
and an increase in the number of packets transferred. The IP layer has security
and authentication built into it. With the new IP version being standardised,
IPv6, the authentication of IP packets will be possible without third party
intervention. This is accomplished through the use of an authentication header
which provides integrity and authentication without confidentiality [1].
RFC1644 also has a duplicate transaction problem. This can be serious for applications that are non-idempotent (repeat transactions are very undesirable). Requesting time from a time server can be considered idempotent because there is no adverse affect on either the client or the server if the transaction is repeated. In the case of a banking system however, if an account transaction was repeated accidentally, the owner would either gain or lose twice as much as anticipated. This error can occur in T/TCP if a request is sent to a server and the server processes the transaction, but before it sends back an acknowledgement the process crashes. The client side times out and retransmits the request - if the server process recovers in time, it can repeat the same transaction. This problem occurs because the data in a SYN can be immediately passed onto the process, rather then in TCP where the 3-Way Handshake has to be completed before data can be used. The use of two-phase commits and transaction logging can eliminate this problem occurring.