Subject: Re: TCP end-to-end Semantics

From: [email-masked]
Date: Tue, 9 Jan 2001 10:46:30 +0100

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-masked] on 01/09/2001 05:17:40 AM
To:	[email-masked]@SMTP
cc:	[email-masked]@SMTP
Eric Verlind/HAS/BE/PHILIPS@EMEA1
[email-masked]@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-masked]>, 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
>

---

From: Joe Touch <[email-masked]>
Date: Tue, 09 Jan 2001 09:46:37 -0800

[email-masked] wrote:
> 
> Can somebody come up with some examples of practical, relevant applications 
> that will fail under spoofing? 

What about any connection whose spoofed ACKs cause the sender's window to
reuse offsets (i.e., roll-around), and then has a change in the
path that causes the spoofer (with its state) to be outside the path?

The result will _look_ like a successful transfer, but result
in corruption.

Joe

---

From: Fred Baker <[email-masked]>
Date: Tue, 09 Jan 2001 21:32:54 +0800

At 10:46 AM 1/9/01 +0100, [email-masked] wrote:
>Can somebody come up with some examples of practical, relevant 
>applications that will fail under spoofing? Any practical experiences?

yes. Financial applications, wherein the transmission of information 
results in money being removed from an account. When your bank tells your 
ATM to spit out money, if the communication is spoofed you can lose the 
money from your account and not get the bills spit out. More generally, 
transactions lost in flight can have other than a shared fate.

---

From: George Michaelson <[email-masked]>
Date: Wed, 10 Jan 2001 08:49:46 +1000

But this presupposes transactional completeness maps 1:1 into tcp ack flow.

Surely no application of this nature depends on an underlying protocol to 
give closure inside its application-specific logic? Assuming a reliable
bytestream doesn't mean the application says yes or no. 

For instance, one can imagine a nightmare world of mainframes where TCP
terminates in a front-end-processor and backend bisync is required to get
to the cash services engine inside some monster iron. You can't use a spoofed
or non-spoofed TCP ack there to get completion on a transaction.

-George
--
George Michaelson         |  DSTC Pty Ltd
Email: [email-masked]    |  University of Qld 4072
Phone: +61 7 3365 4310    |  Australia
  Fax: +61 7 3365 4311    |  http://www.dstc.edu.au

---

From: Francesco Potorti` <[email-masked]>
Date: Wed, 10 Jan 2001 16:19:51 +0100

>applications that will fail under spoofing? Any practical experiences?

Fred Baker:   
   
I do  hope that no transaction-based  application relies on  TCP acks to
verify that the receiving application  has indeed got the data.  Or, for
that matter, no application at all.  Am I missing anything?

-- 
Francesco Potortì (researcher)         Voice: +39 050 315 3058 (op.2111)
Area della ricerca CNR - CNUCE         Fax:   +39 050 3138091
via Alfieri 1, I-56010 Ghezzano, Pisa  Email: [email-masked]
Web: http://fly.cnuce.cnr.it/          Key:   fly.cnuce.cnr.it/public.key