BILLW@mathom.cisco.com (William "Chops" Westfield) (01/04/91)
"spoofing" usually refers to "faking" an ACK locally, to avoid being slowed down by long round-trip delays. In general, this is only useful in very delay-sensitive protocols (eg those that need an ACK for a packet before they can send the next packet, like XMODEM, old KERMIT, Novell, etc). Since TCP already includes sliding windows, it is NOT particularly delay sensitive, and would not benefit very much from being spoofed. Spoofing is also difficult since there are things other than the data transfer that can effect the window/etc... Header and/or data compression of the packets is a different matter, and is very useful on slow links (especially when you can compress a 40 byte TCP header down to 3 bytes or so, ala CSLIP). For this to be benificial, you have to do the compression before you go over a slow link (in the PC, not in the MODEM.) A modem that compresses TCP headers is not particularly useful unless the link between the modem is as much faster as the compression ratio times the comm speed. (90kbps, for CSLIP style compression!) Even without compression or spoofing, data rates using SLIP are not so bad. We WOULD benefit from as little as packet recognition in modems so that line turn-around type events don't occur until the actual end of packets. What SLIP users usually complain about is echo-response (in telnet), as opposed to ACK-response. If anyone thinks that a modem can do an adequate job of spoofing actual data, I'd invite them to apply their talents to gambling or market research... :-) BillW -------
PADLIPSKY@A.ISI.EDU (Michael Padlipsky) (01/05/91)
Since Reliability (sometimes known as Robustness) is at least a and more likely THE design imperative of TCP, it's a quite severe understatement merely to say that TCP wouldn't benefit from fake (pre-fabricated relative to the destination) ACKs. cheers, map P.S. The extreme undesirability of tampering with the end-to-end acknowledgement of correctly received data is one of the major in- principle objections to "translating/mapping gateways", b/t/w. -------
tjs@MSC.EDU (Tim Salo) (01/05/91)
"Spoofing", (generating an acknowledgement locally rather than allowing
the remote host to generate it), generally [i.e., probably universally]
implies an obligation for the local device to assume responsibility for
the reliable transmission of the data to the remote host.
This has several results:
o The local device must understand more about the protocol(s) than if
spoofing did not occur. In the case of TCP/IP, the local device
must understand TCP as well as IP. (A TCP router?)
o Various end cases don't work particularly well, (i.e., not at all).
For example, if the local device acks some data and the line then
goes down, the local device is unlikely to meet its implied obligation
to reliably transport the acknowledged data to the remote host.
Stated differently, don't use spoofing for ATM (the financial
type) transations.
Tim Salo
Minnesota Supercomputer Center
tjs@msc.edu
(612) 626-0347
P.S. Spoofing is probably also useful when resources other than window
space are important. For instance, spoofing can minimize the local host's
need for buffer space devoted to unacknowledged transmitted data and the
receive host's buffer space devoted to reassembly queues.
P.P.S Spoofing may also help on high-bandwidth, long-propagation-delay,
links (e.g., statellite links) where the window may close prior to
filling the link.
P.P.P.S This rather interesting topic quickly leads to a discussion of the
merits of connectionless protocols ("smart host, dumb network")
protocols versus connection-oriented protocols, ("dumb host, smart network"
protocols). ["Elements of Networking Style" not withstanding.]
> From: William "Chops" Westfield <BILLW@mathom.cisco.com>
> Subject: TCP Spoofing...
>
> "spoofing" usually refers to "faking" an ACK locally, to avoid being
> slowed down by long round-trip delays. In general, this is only useful
> in very delay-sensitive protocols (eg those that need an ACK for a packet
> before they can send the next packet, like XMODEM, old KERMIT, Novell, etc).
> Since TCP already includes sliding windows, it is NOT particularly
> delay sensitive, and would not benefit very much from being spoofed.
> Spoofing is also difficult since there are things other than the data
> transfer that can effect the window/etc...
> [...]
> From: Michael Padlipsky <PADLIPSKY@A.ISI.EDU>
> Subject: Re: TCP Spoofing...
>
> Since Reliability (sometimes known as Robustness) is at least a
> and more likely THE design imperative of TCP, it's a quite severe
> understatement merely to say that TCP wouldn't benefit from fake
> (pre-fabricated relative to the destination) ACKs.
>
> cheers, map
>
> P.S. The extreme undesirability of tampering with the end-to-end
> acknowledgement of correctly received data is one of the major in-
> principle objections to "translating/mapping gateways", b/t/w.PADLIPSKY@A.ISI.EDU (Michael Padlipsky) (01/08/91)
Tim Salo-- Grateful though I am for the passing plug for The Book (gee, four in one day!), and in agreement though I am with the body of your msg, I fear I must take issue with the flavor of your postscripts: In a strictly construed TCP context, intermediate systems CAN'T assume responsibility for correct delivery. Indeed, some pushy purist once complained to me that even an "outboard" TCP protocol interpreter violated the spirit of end-to-endness inherent in the protocol. I of course replied that a proper outboard TCP PI wouldn't send the ACK until it had been assured through its Host-Front End Protocol that the counterpart process had indeed received the data (and yes, the explicit or implicit link protocol of the H-FP IS expected to guarantee the correctness of the data between the PI and the process).... So I would maintain that under NO circumstances should TCP ACKs be "spoofed"--and must admit I'm somewhat surprised Vint Cerf hasn't hurled any thunderbolts on the topic yet, since (1) it's really his idea that Robustness is uber alles in TCP, and (2) we (he and I) once had so strong a disagreement over my view that he was a bit too fanatic on the topic that I can't imagine he'd expect me to spring to its defense for him, even if 14.5 years of water have flowed over that particular dam[n]. (Maybe he's taking a long Solstice break.) (Almost inconceivable I've wound up to the Right of him on that of all topics, but, I guess, a logical possibility.) (Nah, must be on vacation.) cheers, map -------
tjs@MSC.EDU (Tim Salo) (01/08/91)
> Date: Tue 8 Jan 91 00:27:13-EST > From: Michael Padlipsky <PADLIPSKY@A.ISI.EDU> > Subject: Re: TCP Spoofing... > [...] > In a strictly construed TCP context, intermediate systems CAN'T assume > responsibility for correct delivery. Indeed, some pushy purist once > complained to me that even an "outboard" TCP protocol interpreter > violated the spirit of end-to-endness inherent in the protocol. I of > course replied that a proper outboard TCP PI wouldn't send the > ACK until it had been assured through its Host-Front End Protocol that > the counterpart process had indeed received the data (and yes, the > explicit or implicit link protocol of the H-FP IS expected to guarantee > the correctness of the data between the PI and the process).... > [...] 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.). Some interesting commentary on putting applications in a host and TCP in a front-end processor is Dave Clark's discussion of "fate-sharing" in "The Design Philosophy of the DARPA Internet Protocols" at SIGCOMM '88. At the risk of over simplification, "fate-sharing" is an implementation strategy, (putting both functions on the same processor), which ensures that the application and the end-to-end acknowledgement of data (TCP) do not die independently. This strategy obviates the need to develop algorithms to deal with TCP loosing its internal state while the application continues. Many spoofing implementations ignore this case. Note that some protocols allow the host to specify whether acknowledgements have local or end-to-end significance, (c.f., the X.25 "D" bit). I suspect that discussions of whether the customer should be allowed to determine the significance of TCP acknowledgements (allow spoofing) or whether only protocol gurus can make this decision (disallow spoofing) falls into the realm of religion. (I vote to let the customer decide.) Tim Salo tjs@msc.edu (612) 626-0347
barmar@think.com (Barry Margolin) (01/09/91)
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
PADLIPSKY@A.ISI.EDU (Michael Padlipsky) (01/09/91)
In religious terms, letting "the customer decide" where ACKs come from IN THE TCP CONTEXT is tantamount to letting the parishoner decide whether the "nots" belong in the Commandments. Unlike Ekstwennifie's "D" bit, the meaning of the TCP ACK is not defined to be voluntary ... and IS defined to have end-to-end/process-to-process significance. Much as I hate to find myself cast in the role of a strict constructionist --especially while enjoying a pseudosabbatical--I just don't buy the notion that defining characteristics of protocols are subject to re- construction by non-designers. It's not customers vs. gurus that's at issue, it's denotation vs. solecism. cheers, map -------
bob@MorningStar.Com (Bob Sutterfield) (01/09/91)
In article <9101080645.AA05302@uh.msc.umn.edu> tjs@MSC.EDU (Tim Salo) writes:
I suspect that discussions of whether the customer should be
allowed to determine the significance of TCP acknowledgements
(allow spoofing) or whether only protocol gurus can make this
decision (disallow spoofing) falls into the realm of religion. (I
vote to let the customer decide.)
The customer is welcome to do whatever {s}he likes, and may indeed
invent a very pleasant and workable reliable datastream protocol.
Such a protocol may turn out to be widely liked by the worldwide
networking community, and its inventor lauded as a sage with manifest
vision and wisdom. It may turn out to be a commercial success,
enabling the inventor to retire in comfort to whatever palm
tree-covered tropical island paradise {s}he might care to purchase.
(Note that this latter seems to be the goal of many religion
inventors.)
But if it can be spoofed (read: doesn't depend upon the sanctity of
end-to-end ACKs), then it's not RFC793 TCP.gsa@easyaspi.udev.cdc.com (gary s anderson x2911) (01/12/91)
In article <12652397791.27.PADLIPSKY@A.ISI.EDU>, PADLIPSKY@A.ISI.EDU (Michael Padlipsky) writes: |> In religious terms, letting "the customer decide" where ACKs come from |> IN THE TCP CONTEXT is tantamount to letting the parishoner decide whether |> the "nots" belong in the Commandments. Unlike Ekstwennifie's "D" bit, |> the meaning of the TCP ACK is not defined to be voluntary ... and IS |> defined to have end-to-end/process-to-process significance. |> The one element missing from this religious agrument is the scope of the TCP acknowledgement. Applications use the TCP features to reliably move bytes between systems. Applications should not (and generally don't) rely on TCP services to denote success or failure of application activities. For example, the FTP client application relies on a peer (ftp server) response to confirm the completion of an FTP request (e.g. create file). This weak application confirmation strategy fails if the network dies after the request is sent and before the confirmation is received (i.e. did the file actually get created?!!?). NOTE - the great power of TCP was helpless in preventing this problem. My point is that the scope of the TCP acknowledgement is limited to the TCP protocol. This feature is merely a tool used by TCP to provide the guaranteed data delivery mechanism. One can certainly find ways to extend this feature, however, no such standard exists at this instance in time. Consequently, the strength of the solution is not where the ACKs come from, but whether or not the application will successfully operate in this environment (i.e. is the application still provided a reliable data transfer service). NOTE - please do not misconstrue this note as a recommendation for implementing an "intermediate TCP" solution. This was merely an open-minded statement which implies that such a solution can be constructed (with some effort!!!).
BILLW@MATHOM.CISCO.COM (William "Chops" Westfield) (01/13/91)
Regardless of the "legality" of TCP ACK spoofing, I still claim that
that it is not useful to do so. Especially in the situations originally
brought up (speeding up transport on slow modems, similar to telebit's
kermit, modem, and uucp spoofing). The windowing inherent in TCP makes
ACK spoofing in these situation unnecessary, since the ACK return time
is not the limiting factor in the end-to-end throughput.
My point is that the scope of the TCP acknowledgement is limited to
the TCP protocol. This feature is merely a tool used by TCP to
provide the guaranteed data delivery mechanism.
The first sentence is true, the second is most certainly not. The
round trip time (calculated based on the time to get an ACK) is used
to determin retrasmission intervals, and in newer (Van Jacobson) TCPs,
to estimate the effective bandwidth of the network connection, so that
network congestion can be avoided. By spoofing ACKs, you gain very
little, and lose a great deal.
Bill Westfield
cisco Systems.
-------