Hi,
What you say is probably true. However I am puzzled about the consequences of the remark on "session". So the spoofer TCP I am talking to happily sends me ACKs and I think: fine, let's free those buffers and get rid of the old application data. A few
MByte ahead then the spoofer finds out that something is wrong. How do I know where things went wrong? Well yes, I know that something is wrong with the session and that's all.
Some people argue that without spoofing things can go wrong anyway from the application point of view. They are right. However, two remarks on that:
1. Principal:
Applications should in some way "surround" their transfers with means to guarantee that a transfer as a whole
succeeds, i.e. end-to-end communication at the appl. level. For instance, after a file transfer, the correspondent should respond with "Thanx buddy, I've correctly received 4711 bytes from you".
2. Practical:
How often do things go wrong normally? I am afraid that many application builders have the perception that TCP is 100% rock-hard reliable and for that they do not make their applications reliable "'cos TCP does that already". My fear:
* normally, things can indeed go wrong but this is principal/theoretical rather than practical. The chances of failure are so low that -although it happens from time to time-, nobody is bothered by it: if I give it to TCP, it will just arrive. If it goes
wrong, I might perceive this as a BIG exception, i.e. a system failure or strange quirk that I can live with because it happens so rarely.
* the question is whether spoofing changes things in this respect. If "failure" becomes more than an exception but is perceived as a system weakness, that undermines my feeling that the system is trustworthy and rightly so.
Can somebody come up with some examples of practical, relevant applications that will fail under spoofing? Any practical experiences?
- I guess FTP does acking at the application level, but I'd have to check its rfc.
- Web browsing is cached and proxied anyway, as somebody state rightfully.
- What about http file downloads/uploads (other than web pages): any practical problem?
Who can give me a feeling?
Thanks,
Eric Verlind
Software Architect
[email protected] on 01/09/2001 05:17:40 AM
To: [email protected]@SMTP
cc: [email protected]@SMTP
Eric Verlind/HAS/BE/PHILIPS@EMEA1
[email protected]@SMTP
Subject: Re: TCP end-to-end Semantics
Classification: Restricted
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 <[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 : Tue Jan 09 2001 - 05:20:21 EST