All,
Here is another way to look at whether "TCP-spoofing" causes violation
of end-to-end TCP semantics. This is similar to Hussein's analysis.
1. In a purely, theoretical sense, the answer is YES, as stated by many
authors. The spoofer acks packets to the sender that have not been
delivered to the destination host.
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.
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.
3. Inquire of TCP as to how much of its data has been acknowledged by
the peer and use that info. to verify whether data has been delivered to
the receiver.
It is theoretically possible for applications to inquire of TCP as to
how much of its data has been acknowledged by the peer. The TCP RFC
does NOT mention this as one of the interface primitives and I don't
think there are any standard socket libraries that allow this.
4. Simply close the connection, with the assumption that the data
will be successfully delivered with a fairly high probability.
Let us assume that the TCP spoofer uses a reliable protocol to deliver
packets to the final destination. Let us also assume that the TCP spoofer
does not spoof the FIN exchange, i.e., the the spoofer ensures
that the FIN exchange finishes successfully only if all sent data
is successfully delivered to and acknowledged by both ends.
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.
Applications that use method 3 will of course be negatively affected. One can
presume that there are not many such applications.
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.
In my humble opinion, TCP spoofing is not as bad as it sometimes sounds!
As an aside, there are many other things that a good TCP-spoofer has to do,
such as faithfully transfer the values of the some of the TCP header fields
such as PUSH, URGENT, checksum and TCP options. We have developed
and sell a TCP-spoofer product for use over satellite links.
Regards,
Anil Agarwal
LMGT
22300 Comsat Dr
Clarksburg, MD 20871
(301)428-4655
[email protected]
This archive was generated by hypermail 2b29 : Tue Jan 09 2001 - 11:34:22 EST