Removing T/TCP and replacing it with something simpler

[Andre Oppermann]

Dag-Erling Smørgrav wrote:
> 
> Andre Oppermann <andre at freebsd.org> writes:
> >   o T/TCP only available on FreeBSD.  No other Operating System or TCP/IP
> >     stack implements it to my knowledge.  Certainly no OS that is common.
> 
> AFAIK, both Linux and Windows support it, at least on the server side
> (i.e. they can receive T/TCP connections even if they can't initiate
> them).

Any fully TCP compliant stack should be able to accept T/TCP connection
attempts.  However if it didn't implement T/TCP itself it would simply
do the standard 3WSH.  So yes, you can use T/TCP from the client side
towards any TCP server but you don't get any benefit from it.  Neither
Windows or Linux implement it.  Windows during the NT4 days had a bug
in the TCP stack that allowed something like T/TCP but it wasn't T/TCP
and didn't work with T/TCP compliant clients.

> >   o T/TCP requires different API calls than TCP to use it (UDP like).
> 
> Only on the client side, I believe.

Yes, on the client side.  sendto() instead of connect()+write().

> >   o T/TCP is not supported by any common network application.
> 
> Prior to libfetch, fetch(1) used it by default.

Only if T/TCP was enabled on the machine (net.inet.tcp.rfc1644).

> > Thus after the removal of T/TCP for the reasons above I want to provide
> > a work-alike replacement for T/TCP's functionality:
> 
> Unlike your proposal, T/TCP is described in Internet RFCs (1379 and
> 1644) and well-known by the Internet community.

Well known for its gaping security holes and left unimplemented on any
other OS except FreeBSD.

-- 
Andre