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 componentsSniffer CoreReports 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 protocolOver UDP

General Illustration

Sniffer Core

IP NetworkIP Network

Reports Server

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 functionsStart sniffingStop sniffingConfigure Reports Server address (or disable

feature)Local Log enable / disableChoose “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 function Forwards the frame to local filter

Local Filter Filters 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)

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 parameters

Local/Remote storage of frames Frequency

Reports Server Modules

Syslog Server Receives Syslog messages from the Core with 802.11n frames

as data. Forwards the 802.11n frame to the Local Filter

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 keysThe sender will send the index of the key

stored on the array.The receiver will use the same key to encrypt

dataThat 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

1 n2

…

Keys array stored on both sides of connection

k1 k2 kn

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/topology_tr.pdf

Topology Discovery Algorithm (2)

AssumptionsThe nodes are stationaryOne node collects the entire topology

Consists of two stepsThe Discovery stepThe 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 sub-network topology of the Mesh that they’re roots of – thus the Coordinator have the entire topology at the end of this step