In this section, we describe our real-world experiences using the
Listen protocol. We make two important observations from our
analysis. First, we found that a large fraction of incomplete TCP
connections are spurious i.e., not indicative of a reachability
problem. We show that by adaptively setting the parameters of
our listen algorithm we can drastically reduce the probability of such
false negatives due to such connections. Second, we are able to
detect several reachability problems using Listen including specific
misconfiguration related problems like forwarding
errors. Table 2 presents a concise summary of the results
obtained from our deployment. We were able to detect reachability
problems to
different prefixes from our testbed with a very
false negative probabilities of
and
respectively due
to spurious outbound and inbound connections.
We will now describe our deployment experience in greater detail. In our testbed, we use three active probing tests to verify the correctness of results obtained using Listen: (a) ping the destination; (b) traceroute and check whether any IP address along in the path is in the same prefix as the destination; (c) perform a port 80 scan on the destination IP address. These tests are activated for every incomplete connection. We classify an incomplete connection as having a reachability problem only if all the three probing tests fail. We classify an incomplete connection as a spurious connection if one of the probing techniques is able to detect that the route to a destination prefix works. A spurious TCP connection is an incomplete connection that is not indicative of a reachability problem.
Table 3 presents the aggregate characteristics of the
traffic we observed from a network for over
days. In
reality, we found that nearly
of the connections are incomplete
of which a large fraction of these connections are spurious (
inbound and
outbound). A more careful observation at the
spurious connections showed that nearly
of spurious inbound
connections are due to port scanners and worms. The most prominent
ones being the Microsoft NetBIOS worm and the SQL server
worms [6]. Spurious outbound connections occur primarily
due to failed connection attempts to non-live hosts and attempts to
access a disabled ports of other end-hosts (e.g., telnet port being
disabled in a destination end-host).Given this alarmingly high number
of spurious connections, we propose defensive measures to reduce
the probability of false negatives due to such connections.