In message <[email protected]>, Luigi Rizzo writes:
>> You're right, spoofing ACKs does violate TCP semantics. Some folks argue
>> that if their intermediate node, that spoofs ACKs, also buffers data then
>> you're safe, but they're wrong -- as the intermediate could fail.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>how is this different from what you say next
>
>> guarantee that your data reached the remote system. This guarantee, however
>,
>> is only for the end system -- it does not say the end application received
>> the data (it may never read it).
>
>i.e. how is your "remote system" different from any intermediate in the
>way -- you may have a better chance of detecting its failure, but no
>guarantees, anyways. The receiving end could well be an on-board CPU+memory
>on the network card (for however a bad idea this can be) and go
>equally unnoticed.
>
>Maybe we could say some intermediate device violates semantics iff
>there is a procedure that deterministically (or with very high
>probability) makes it behave differently from an implementation on
>the end-system ?
Hi Luigi:
That's an astute point, thanks!
The answer is that I view the probability of failure as part of the TCP
semantics. That is, TCP says it provides connectivity between two end
points ("reliable inter-process communications between pairs of
processes in host computers...").
My view is that means that TCP's host-to-host behavior is a function solely
of the two end points. (One could also say this view is a logical consequence
of the simple dumb network approach, of which IP is an example).
So my second example, where the receiver could fail to deliver the data after
ACKing it, in a normal TCP is solely a function of the receiver suffering
one of a (fairly short) list of errors. Adding an intermediary doesn't
change the receiver probability, but adds the probability of the failure
of the intermediary. So the probability of failure is now different from
what it was if just the two hosts were involved.
Thanks for an insightful question and I'll be interested to know what
you think of my reply :-)
Craig
This archive was generated by hypermail 2b29 : Mon Jan 08 2001 - 19:10:06 EST