Path: utzoo!utgpu!watserv1!watmath!att!tut.cis.ohio-state.edu!ucbvax!MSC.EDU!tjs From: tjs@MSC.EDU (Tim Salo) Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP Spoofing... Message-ID: <9101050942.AA03856@uh.msc.umn.edu> Date: 5 Jan 91 09:42:18 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 63 "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 > 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 > 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.