Path: utzoo!utgpu!watserv1!watmath!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!samsung!uunet!timbuk!shamash!easyaspi.udev.cdc.com!gsa
From: gsa@easyaspi.udev.cdc.com (gary s anderson  x2911)
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  TCP Spoofing...
Message-ID: <29806@shamash.cdc.com>
Date: 11 Jan 91 21:17:53 GMT
References: <12652397791.27.PADLIPSKY@A.ISI.EDU>
Sender: usenet@shamash.cdc.com
Reply-To: gsa@easyaspi.udev.cdc.com (gary s anderson  x2911)
Lines: 30

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!!!).