In message <[email protected]> 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
This archive was generated by hypermail 2b29 : Tue Jan 09 2001 - 14:37:55 EST