Subject: Re: TCP end-to-end Semantics

From: Anil Agarwal <[email-masked]>
Date: Tue, 9 Jan 2001 13:47:47 -0500 (EST)

In message <[email-masked]> Craig Partridge wrote:

>>2. On a more practical plane, things are a little different.
>>
>>   Most well-written TCP applications do not assume that if the sender
>>   TCP has accepted user data, then the data will get delivered to the 
>>   receiver with absolute guarantee. To verify end-to-end data delivery,
>>   such applications use one of several methods -
>>
>>   1. Close the socket, with the LINGER option enabled, and wait for TCP 
>>      to finish its FIN echange and to return success/failure indication
>>      to the user.
>
>Which may fail when spoofing is done.  If the RTT between the sender and
>the spoofing node is sharply less (and less variable) than the RTT between
>the sender and the receiver, it is conceivable (esp. if the real RTT
>includes a satellite delay) that the sender will multiply retransmit
>and finally time out the FIN.
>
>The end result is a transfer that has occurred, but due to spoofing the
>sender deems to have failed and may retry (many times!).
>

Practically speaking, a FIN timeout takes 3.5 minutes, on most
systems, with 11 retransmissions with backoff timeout values and a minimum
timer value of 0.5 seconds. So the above scenario is one where the spoofer
successfully completes the FIN exchange with the distant peer after 3.5
minutes and not earlier.  I am sure everyone will agree that this is
a very low probability (not zero) event for most networks, including
satellite networks (except perhaps for deep-space links).

This scenario is similar to a non-spoofed TCP connection that
sends a FIN, gets a FIN,ACK from the peer and sends a final ACK. If the final
ACK is not delivered to the peer, even after retransmissions of the FIN,ACK
by the peer, then the sender perceives a successful transfer, while the 
receiver does not.

Yet another scenario is a non-spoofed TCP connection that
sends a FIN, but the FIN,ACK from the peer is lost and is never
received even after retransmissions of the FIN by the sender.
Then both the sender and receiver detect a failed connection, even though
the receiver can tell that it received all the sender's data. The receiver
cannot tell the difference between this scenario and the previous one;
so it must discard the received data.

Note: this is related to the "General's Problem".

Hence, TCP does not provide 100% guarantee that both the sender and the
receiver can detect a failed connection, although the probability of
an undetected failure is very small. The probability of spoofing causing
an undetected failure, as shown in Craig's scenario, is of the same
order - I state this of course without proof :(.

>>   2. Do an application-to-application message exchange to verify whether
>>      that all data has been received. This may also be done at intermediate
>>      points in the session.
>
>This works, but is also subject to the timeout problem above.
>

I am not sure why that is so. If the applications successfully exchange
a data msg. saying that all data has been received, than they presumably will
not care whether the FIN succeeds or not.

On the other hand, this is also subject to the "General's Problem" dilemma,
where both sides cannot detect with 100% probability a failed connection.

>> ...
>>
>> With such a spoofer, one can say that applications that use methods 1 and 2
>> mentioned above, will not see any difference in "semantics" or end-results,
>> when operating with an intermediate spoofer.
>
>I think I just illustrated a case where this is not true.
>

See explanations above.

>> Applications that use method 4 will not experience any significant change
>> in probability of success or failure, assuming that the spoofer itself
>> has a low probability of failure. Network or destination host failures
>> will affect the probability of failure by the same amount, whether spoofing
>> is used or not.
>
>By this logic if my chance of failure is originally .001 and I add a spoofer
>with a chance of failure of 0.001, I should not be distressed that my chance
>of failure has roughly doubled to (0.002)?
>

There really isn't much cause for distress here.

Firstly, equipment failures (of the router and spoofer kind) are not measured
in .001 probabilities - they have MTBFs of several years - the equivalent
failure probabilities are much, much lower.

Secondly, the spoofer is generally NOT an additonal piece of equipment in
the network - it takes the place of a router - hence the overall failure
probability is no different than an equivalent network that does not use
the spoofer.

Regards,
Anil Agarwal
LMGT

---

From: Jacob Heitz <[email-masked]>
Date: Tue, 09 Jan 2001 14:06:23 -0800

> order - I state this of course without proof :(.

Nonsense. TCP can and should provide 100% guarantee of detecting a
failed connection. What it cannot do is provide a 100% guarantee of
a successful connection. If the last ack does not arrive, there is
doubt over success or failure. If the last ack arrives, the receiver
of the last ack can be certain that all data was sent and received.

The thing that the receiver of the last ack cannot be sure of is
whether the peer is also sure. That is the General's Problem.
TCP does not solve the General's Problem, but we don't normally
care.

You can spoof anything you like... except the last ack.

> probability is no different than an equivalent network that does not use

Nonsense. If a router fails, the endpoints find out and retransmit.
A spoofer can fail such that the endpoints will never find out.