In message <[email protected]>, Jacob Heitz wrote:
>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.
I thank Jacob for his insightful comments. I stand corrected.
Let us define a successful transfer as one where all data and the FIN
is delivered to both ends. With that definition, one can state, that
1. For an unsuccessful transfer, TCP at both ends will detect the failure.
2. For a successful transfer, there is a non-zero probability P that TCP at
one end (or both ends on a "simultaneous" close) may perceive the
transfer as unsucessful.
The probability P is related to the probability of a
network or host outage during the FIN exchange time. This is an
inherent poperty of TCP and has nothing to do with spoofing.
I think we do care about the General's Problem; Fred Baker's example of
the banking application is one reason why. No banking application
designer would naively use TCP's "reliable transfer" mechanism as a means
to solve the distributed transaction atomicity problem.
I also stand corrected on the response to Craig's example. In that
example both ends will notice a failure; the receiver will notice
a failure since it will not get the "last ack".
The probability of this event is related to the probability of the
spoofer-to-destination network becoming "broken" around the
time the first FIN is sent and getting "repaired" around 3.5+
minutes thereafter. One can see that the probability of this event is
smaller than P mentioned above. Incidentally, the same result
would occur if there was no spoofer.
With the above background, and the material I wrote in my first response,
I don't think anyone has come up with a legitimate example where spoofing
causes an application to "break", when the application would work
correctly in the absence of spoofing. It is important when designing
such examples, to study carefully how the results would be different
in a non-spoofed scenario. Also keep in mind, that the good spoofer will
not spoof the FIN ack (or the last ack, as Jacob correctly points out).
>
>>
>> >> 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.
>
If we assume that the spoofer is working in an environment where there
a spoofer failure causes loss of connectivity between the two hosts,
then TCP will not be able to complete a FIN exchange and hence discover
the spoofer failure.
This is the most likely environment in which spoofers get used..
If we discard the above assumption, and assume that after the failure, the
two ends will start communicating via an alternate path, then
1. If the TCP connections were "quiet" for a while before the failure,
and the sequence number have not changed, then the TCP
connections will actually continue, with no harm done (with a properly
designed spoofer, of course, that retains sequence numbers across
the spoofed connections. Our implementation does).
2. If not, then both ends will eventually retransmit and time out,
since the receiver may be missing some data which the sender has already
freed, and declare a failure (with a properly designed spoofer).
(With a spoofer that does not retain seq numbers across spoofed
connections, bad things can happen, probably with relatively
small probability).
The probability of a sequence number "match" while the sequence number at
the sender has rolled over is extremely small and practically not
very likely (the spoofer would have to buffer around 2^32 bytes on
behalf of the sender!). This is no different than the TCP sequence
wrap-around problem, for which PAWS was added; PAWS would solve the
problem here as well.
Anil Agarwal
LMGT
22300 COMSAT Drive
CLarksburg, MD 20871
301-428-4655
This archive was generated by hypermail 2b29 : Wed Jan 10 2001 - 11:27:36 EST