Anil Agarwal wrote:
>
> 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 :(.
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.
>
> >> 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.
Nonsense. If a router fails, the endpoints find out and retransmit.
A spoofer can fail such that the endpoints will never find out.
>
> Regards,
> Anil Agarwal
> LMGT
This archive was generated by hypermail 2b29 : Tue Jan 09 2001 - 17:43:02 EST