Subject: Re: TCP end-to-end Semantics

From: Mark Allman <[email-masked]>
Date: Tue, 09 Jan 2001 13:01:46 -0500

> If you linger on the close (such that all data is acknowledged
> before your socket closes -- and assuming no ack spoofing) then
> you'll have a firm guarantee that your data reached the remote
> system.

Modulo LINGER working correctly (which my experience suggests is an
iffy proposition).

> 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 believe the strict application of the end-to-end principle is the
only true answer.  That is, the applications have to ACK the arrival
of the data to its peer application.  Trusting anything (transport
protocols, routers, spoofing boxes, proxies, NATs, etc.) in between
the application processes for "guarantees" is always going to be
dicey (where the defintion of "dicey" sort of depends on what is
involved in between the apps).

allman

---
Mark Allman -- NASA GRC/BBN -- http://roland.grc.nasa.gov/~mallman/

---

From: Anil Agarwal <[email-masked]>
Date: Wed, 10 Jan 2001 08:42:25 -0500 (EST)

In message <[email-masked]>, Fred Baker
wrote:

>
>
>At 05:51 PM 1/9/01 -0500, Mingyan Liu wrote:
>>it be left to the application/user to decide
>>whether they would rather use the spoofer and be exposed to higher failure
>>probability, or just play safe and bypass the spoofer (assume that the use
>>of a spoofer is not mandatory)?
>
>In general, I would agree with that. Now tell me this: do you know that the 
>spoofer is there? How do you evade it?
>
>The cases that come quickly to mind are transparent and non-transparent web 
>caches, Packeteer-style QoS control boxes which fiddle with TCP headers, 
>Arrowpoint-etc devices which front-end sets of web servers, and so on. I 
>can get around the non-transparent caches (SQuID etc) readily enough, but I 
>may not be able to get around the others, and may not even know they are there.
>
>In such cases, the statement above is a great sentiment, one I would 
>wholeheartedly support, but doesn't seem very practical. 

I am curious how we got into this discussion. Does someone have any 
firsthand knowledge that spoofers have a higher failure rate than
other networking equipment? I don't think so - and hence the
premise for this discussion is moot.

The more relevant discussion, to which many authors have contributed
valuable insights, is whether spoofing violates end-to-end TCP semantics,
and at a more practical level, whether spoofing breaks applications
or increases the probability of such breakage, such as reporting
successful transfers when the transfer is in fact unsuccessful and
vice-versa.

Regards,
Anil
LMGT

---

From: Anil Agarwal <[email-masked]>
Date: Wed, 10 Jan 2001 19:32:31 -0500 (EST)

In message <[email-masked]>,
William Ivancic wrote:

>Regarding spoofing:
>
>These questions regarding spoofing surfaced today in  a meeting.  I think I
>understand what will happen, but I would like your opinion.
>
>1.  If I am running an application  that use TCP and using a Virtual Private
>Network, will spoofing improve my performance?

I think the answer is NO. The spoofer will not recognize such packets
as TCP packets and simply route them.

One could come up with some clever way to spoof such connections, but
if the VPN services include IPSec, then I think there is no hope.

>2.  Can a spoofer be utilized in a mobile IP environment were to mobile host 
>or mobile network switches to another network such as in a aeronautical
>internet?
>

I do not know enough about mobile IP to answer that question; but here is
my best guess.

If the spoofer is located somewhere near the current base station,
which changes as the mobile changes cell locations, and IP packets
are routed from the destination via the current base station, then
spoofing will probably not work.

If the spoofer is located somewhere near the "home" base station,
and if all packets get routed via the "home" base station, then spoofing
can be made to work.

Regards,
Anil Agarwal
LMGT