> All the problems I mentioned in the Team-Amiga email were forwarded to
> Linux developers years ago, and last time I checked they had not been
> resolved or even acknowledged. The bug in Linux that requires
> workarounds in Miami is that Linux sends bogus RST packets in response
> to ACK packets after a while if a connection was created with a packet
> that has the SYN+FIN flags set and contains data. The workaround
> involves cloning routes and caching previous connection information
> from responses to T/TCP stype CC and CCecho TCP options, so
> SYN+FIN+data packets are only sent to machines which support T/TCP
> (and are therefore known to not have any bugs in their processing of
> SYN+FIN+data packets). The response I received from the Linux group at
> the time was that SYN+FIN+data packets are illegal anyway, because
> T/TCP is "experimental". Of course that argument is false, because
> SYN+FIN+data packets by themselves have nothing to do with T/TCP and
> are not forbidden by RFC 793, i.e. Linux is supposed to handle this
> case, but does not. The fact that most TCP implementations
> traditionally never send SYN+FIN+data packets (for socket API reasons)
> is irrelevant in this context, and so are opinions on the benefit (or
> lack therefore) of T/TCP. See Stevens' "TCP/IP Illustrated Volume 3"
> for more information on this issue.
Accepting data before a handshake is completed is a security hole. Sadly,
Stevens' book predates script kiddies. I'm sure that the relevant Linux
developers actually said that T/TCP is "fundamentally broken" rather than
"experimental."
-- "Love the dolphins," she advised him. "Write by W.A.S.T.E.."
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/