GSoc 2008 project proposal.. please suggest any uncovered details

[anish babu]

Hi all,
My name is Anish and I am a graduate student at Texas A&M University ,
college station. I made a proposal for GSoC 2008 and the description
is as follows.


Title: "Passive libpcap based TCP session anomaly detector"
-----
Abstract:
-----------
 A daemon to listen on a network interface and logs the anomalies in
connection is to be designed. If there are no anomalies, then normal
session
information like sequence numbers, acknowledgment numbers, SYN
features etc, are logged to understand the behavior of connection. In
case of anomalies, like duplicate packets, duplicate acknowledgments,
SACK responses, out of order segments etc...  then it logs the packet
headers into the tcpdump file for later analysis by tools like
wireshark.

This tool helps in analyzing various TCP algorithms in real practice
on internet instead of abstract theoretical explanations.

Proposal:
-----------

Steps to capture packets using lippcap library:
1) Open an interface
2) Open the device for capturing packets:
3)Apply filters to capture only TCP packets:
4)Collect a set of 'count' packets and apply a call back function for
each of the pakcet.
We now have the packet in the u_char* packet variable of the callback
function. If we we are accessing TCP/IP packets on an Ethernet, then
we have ethernet, IP. TCP headers in order at the start of packet. So,
we have to strip ethernet headers and IP headers in order to access
TCP headers.

All of the main processing is done in call back function.

Assumptions ( for the below solution):
-------------------------------------------
1)Before this, I have a few doubts regarding sliding window protocol
working. Is there a any way to access the 'Last byte Read by
application', 'Next Byte Expected', 'Last Byte received' values from
our function? I assume that we can somehow know these values.

2)We are maintaining seperate statistics for each session indicated by
(dest.port, dest.IP, Source.port, Source.IP) pair. However, if we are
collecting statistics on a single machine, (dest.port, source.port)
pair is enough to uniquely track each session.

3) That the transmit and receive side buffers are linear. however
below ideas can be easily extended if they are circular.

On Receiving side:
a) Duplicate packets: Maintain a bit array of size ('Last Byte read' -
'Next Byte Expected'). If any packet with sequence numbers in this
range is found , set the bit to 1 if already 0. Otherwise, increment
the counter of duplicate packets. If any packet with sequence number
less that 'Next byte Expected' is found, then just the increment the
counter of duplicate packets.

b) Out of order segments :
For every packet, if the sequence number is less than the 'Last Byte
Received' that means that this is an out of order packet. So increase
the counter for this session.

Sending side:

c) Duplicate Acknowledgements:
Use the 'Last Byte Acknowledged' pointer of sliding window to track
until howmany bytes were acknowledged and check with this for all
incoming ACK packets. Lesser ACK in new packet means this is duplicate
ACk packet and increment the counter for this session.

d) SACK responses: ( I think this is not necessary when we are
maintaining statistic for out of order packets on receiving side. What
you say? )
we can use the SACK packets ( if both sides agree to use SACK option)
to track how many packets are reaching the receiver out of order. Use
the log details stored in Header for the start and end of
non-contiguous bytes reached to receiver.


All of the above statistics are collected for each individual session.
We can apped the details even if the session incarnates( begins
again).
Produce summarized results for easy understanding.

More detailed description is can b