What is a system? and what are "TCP end-to-end semantics"? Where are they
defined?
I think saying remote and intermediate "system" does more harm
than good in clarifying the issue.
I do not think that the failure of the receiver to deliver data
to the application after ACKing it is a problem of the transport layer
anyway. If we accept layering, and we accept the end-to-end philosophy,
then the guarantee that a transport protocol provides is between the two
_transport_ end points not the two _application_ end points. Right?
Now, there can be two ways to treat the end-to-end argument. If you (or
your application) are a hardliner and require that the transport
protocol ACK packets only if they are received at the destination, then
spoofing is a violation. If, on the other hand, you apply the end-to-end
on a "session" basis, i.e. a transport protocol will only terminate the
session when all packets of the session are received, then, in principle,
one can argue that there exists an intermediary spoofer (e.g. that
doesn't complete the handshake except after the reception of all packets
at the receiver) that will not be violating the semantics, even if it
plays with the data packets/ACKs to its convenience during the course of
the session.
In other words, it depends on whether you define a "per packet" or a "per
session" semantics. I've looked, and I failed to find any substantial
study on how this affects the application layer. I think that it will generally
depend on the application.
My 6 piastres (= 2 cents)
-Hussein.
On Mon, 8 Jan 2001, Craig Partridge wrote:
>
> In message <200101082207.XAA74699@info.iet.unipi.it>, 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 - 23:53:00 EST