We implemented the passive probing component of Listen
(i.e. without active dropping) in about lines of code in C and
have ported the code to Linux and FreeBSD operating systems. The
current prototype uses the libpcap utility [5] to
capture all the packets off the network. This form of implementation
has two advantages: (a) is stand-alone and can be implemented on any
machine (need not be a router) which can sniff network traffic; (b)
does not require any support from router vendors. Additionally, one
can execute bgpd (Zebra's BGP daemon [2]) to receive
live BGP updates from a network router. For faster line-rates
(e.g. links in ISPs), listen should be integrated with hardware
or packet probing software like Cisco's Netflow [1]. The
current implementation cannot support false positive tests since the
code can only passively observe the traffic but cannot actively drop
packets (since this does not perform the routing functionality).
In our implementation, the complexity of listening to a TCP flow is of
the same order as a route lookup operation. Additionally, the state
requirement is for every prefix. We maintain a small hash table
for every prefix entry corresponding to the (src,dst) IP addresses of
a TCP flow and a time stamp. While a SYN packet sets a bit in the
hash table, the DATA packet clears the bit and record a complete
connection for the prefix. Using a small hash table, we can crudely
estimate the number of complete and incomplete connections within a
time-period
. Additionally, we sample flows to reduce the
possibility of hash conflicts. This implementation uses simple
statistical counter estimation techniques used to efficiently maintain
statistics in routers. Hence, the basic form of Listen can be
efficiently implemented in the fast path of today's routers.
Deployment: We deployed our Listen prototype to sniff on
TCP traffic to and from a prefix within our
university. Additionally, we received BGP updates from the university
campus router and constructed the list of prefixes in the routing
table used by the edge router. The tool only needs to know the list of
prefixes in the routing table and assumes a virtual route for every
prefix. The Listen tool can report the list of verifiable and
non-verifiable prefixes in real time. Additionally, the Listen
algorithm is applied only by observing traffic in one direction
(either outbound or inbound).