Transcript First Report

802.11n Sniffer
Design Overview
Vladislav Mordohovich
Igor Shtarev
Luba Brouk
Foreword
802.11n is the new emerging WiFi
Standard
 No suitable Sniffer is in production (as far
we know)
 This project’s aim is to create one and a
General Overview of the design is
presented in the following slides

General Design Overview

Two main components
 Sniffer
Core
 Reports Sever
The Core resides on the machine with the
physical 802.11n interface or “winpicap”
interface, simulating 802.11n card.
 The Reports Server can be installed on
any host with IP access to the Core
component (.net framework required for
GUI, if used)

General Design Overview (2)

The Core and the Reports Server are
communicating via the Syslog Protocol:
 Standard
Event reporting protocol
 Over UDP
General Illustration
Sniffer Core
Reports Server
IP Network
Sniffer Core
Directly interacts with the RadWin driver
 Directly interfaces with “winpicap”,
wrapping ethernet packets with 802.11n
envelop, including MSDU/MPDU
aggregation
 Simple User Interface
 Local frame filtering
 Syslog client
 Local Report Database

Sniffer Core (2)

UI functions
 Start
sniffing
 Stop sniffing
 Configure Reports Server address (or disable
feature)
 Local Log enable / disable
 Choose “winpicap” interface to listen
Change working Frequency / Bandwith of
driver.
Reports Server
Syslog Server
 Ethereal Compatible report Database,
including 802.11n format frames
presentation
 UI (platform independent version) or GUI
(windows host with .net framework
installed)

 Turn
On/Off
Core Modules

RadWin driver interface
 Receives a frame via RadWin hook
 Forwards the frame to local filter

function
Local Filter
frames – for example discards the data of
frames that are too big to be sent over Syslog
 Performs decryption of an encrypted frame
 Forwards the frame to Syslog Server via
Communication module or local database (depends
on configuration)
 Filters
Core Modules (cont.)

Local Database
 If
enabled stores frames received from Local Filter
module

Communication
 Receives
frames from local Filter and forwards them
to Syslog Server

User Interface
 Configures the Core with user’s
 Local/Remote storage of frames
 Frequency
parameters
Reports Server Modules

Syslog Server



Local Filter


Receives Syslog messages from the Core with 802.11n frames
as data.
Forwards the 802.11n frame to the Local Filter
Filters (if needed) the frame and stores the frame in the
Database
Database

The actual storage of the frames:


Simple log with 802.11n headers only
Ethereal compatible log file (only for frames which were received
entirely from the Core – that is, their data was not removed)
Data Flow in Core component




A new frame is assembled by the RadWin driver and the hook
function is called
The hook function forwards the frame to the Local Filter and returns
as quickly as possible
The Local filter performs checks on the frame and decides if it
should be filtered / processed
If the Filter decides to forward the frame (processed or not) it does it
and delivers it (with appropriate flags) to:



The Local Database, if so configured, or
The Communication Module
The Communication module forwards the frame as a data of a
Syslog packet to the Reports Server.
Data Flow in Syslog Server
The server receives a packet from the
Core
 After the analysis of the packet, the
Server:

 Stores
the received 802.11n frame in the
appropriate log (headers only / Ethereal
compatible)
Development Schedule (Core)
System dependant code – ready
 RadWin driver interface – 5 days
 Local Filter – 5 days
 Local Database – 5 days
 Communication - 5 days

Development Schedule (Reports
Server)
System dependant code – 5 days
 Local Filter – 5 days
 Local Database – 5 days
 Communication - 5 days

OS independency

All modules are to be written in C++ with
OS dependent functionality wrapped by
C++ classes. This is in order to simplify
code porting to another platform.
Security

The frame will include data which will be
decrypted by a key, that is known to the
sender, receiver and sniffer, which listens
to the traffic.

The sniffer will use encrypting function
and then parse the data.
Security (cont.)

The sender will encrypt the data,
assuming:
 The
sender and the receiver both will keep
array of decryption keys
 The sender will send the index of the key
stored on the array.
 The receiver will use the same key to encrypt
data
 That means that keys, encryption and
decryption algorithms are known for both
sides
Security (cont.)



P- decrypted message, i-index of decryption key,
F- decryption function ,M-message, C –
encryption function
P = F(M,Ki) – sender sends, P and i
M = C(P,Ki) - receiver uses the encryption
function and gets the original message
Keys array stored on
both sides of
connection
k1
1
k2
2
…
kn
n
Topology Discovery
A component of the project which’s aim is
to discover and present the Network
Topology
 Is a part of the Core (but developed as a
stand-alone application)

Topology Discovery Algorithm
A simplified version of the “Mesh-based
Robust Topology Discovery Algorithm for
Hybrid Wireless Networks” by Ranveer
Chandra
 http://www.cs.cornell.edu/people/ranveer/t
opology_tr.pdf

Topology Discovery Algorithm (2)

Assumptions
 The
nodes are stationary
 One node collects the entire topology

Consists of two steps
 The
Discovery step
 The Gathering step
Discovery Step Of The Algorithm
A coordinating node is initiating the
algorithm
 The initiating message is propagated to
the entire reachable network and a Mesh
is built.
 Throughout the entire step the nodes
collect information of their neighborhood.

Gathering Step Of The Algorithm



Each node uploads it’s entire information up the
Mesh
Leaves’ information consists only of their
immediate neighborhood
Other nodes’ information is the entire subnetwork topology of the Mesh that they’re roots
of – thus the Coordinator have the entire
topology at the end of this step