Path: utzoo!utgpu!watserv1!watmath!att!pacbell.com!ucsd!sdd.hp.com!think.com!barmar
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  TCP Spoofing...
Message-ID: <1991Jan8.181242.11993@Think.COM>
Date: 8 Jan 91 18:12:42 GMT
References: <9101080645.AA05302@uh.msc.umn.edu>
Sender: news@Think.COM
Organization: Thinking Machines Corporation, Cambridge MA, USA
Lines: 43

In article <9101080645.AA05302@uh.msc.umn.edu> tjs@MSC.EDU (Tim Salo) writes:
>You are correct in identifying the issue, (in spite of my language), 
>as the distribution of function between a host and front-end processor 
>(or modem, etc.).

Actually, I think spoofing and network front-end issues are only slightly
related.  If acknowledgements are sent by a TCP front-end, this would
presumably be the *receiving* host's front-end.  The receiving host and its
front-end are pretty intimate with each other, so it's almost reasonable to
think of the front-end as a component of the host, in which case such
behavior might be excused.

Spoofing, however, might be done by a device at any link in the route, and
presumably by a *sending* modem (spoofing is normally done by a device that
is sending across a slow medium).  There's no strong connection between the
spoofer and the final receiving host, so it's very difficult to conceive of
a way in which they might conspire to guarantee that all data acked by the
spoofer will eventually be delivered.

As has been mentioned before, the successful spoofing algorithms take
advantage of the knowledge that the protocols above certain transport
protocols are constrained, and that these upper-layer protocols incorporate
their own acknowledgements.  For instance, UUCP g protocol is used only by
UUCP, and it has file-level acknowledgements.  The set of protocols that
use TCP as a transport are virtually unlimited, and many of them take
advantage of TCP's guarantee of correct delivery.

A TCP spoofer *might* be able to get away with it if it peeked at the TCP
ports as well, and determined that the packet is part of a protocol with a
higher-level acknowledgement.  For instance, it might not be too bad to
spoof FTP data connection acks, since the end of the file is indicated by a
FIN handshake (the hard part of spoofing FTP data connections is
recognizing them, as this requires peeking at the FTP control connection to
see the PORT command).

So, there might be some limited cases where TCP could be spoofed.  However,
I think the effort required to identify them and implement a reasonably
reliable spoofer would be better spent elsewhere.
--
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar