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: <9101080645.AA05302@uh.msc.umn.edu>
Date: 8 Jan 91 06:45:58 GMT
Sender: usenet@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 40

> 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