Path: utzoo!utgpu!watserv1!watmath!att!tut.cis.ohio-state.edu!ucbvax!A.ISI.EDU!PADLIPSKY
From: PADLIPSKY@A.ISI.EDU (Michael Padlipsky)
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  TCP Spoofing...
Message-ID: <12652177583.19.PADLIPSKY@A.ISI.EDU>
Date: 8 Jan 91 05:27:13 GMT
References: <9101050942.AA03856@uh.msc.umn.edu>
Sender: usenet@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 32

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
-------