In message <200101091551.f09FplA12716@pleiades.ntd.comsat.com>, Anil Agarwal wr
ites:
>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!).
> 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.
> ...
>
> 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.
> 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)?
Craig
This archive was generated by hypermail 2b29 : Tue Jan 09 2001 - 13:09:49 EST