802.11n Sniffer

1. 802.11n Sniffer Design Overview Vladislav Mordohovich Igor Shtarev Luba Brouk

2. 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

3. 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)

4. General Design Overview (2) • The Core and the Reports Server are communicating via the Syslog Protocol: • Standard Event reporting protocol • Over UDP

5. General Illustration Sniffer Core Reports Server IP Network

6. 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

7. 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.

8. 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

9. 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)

10. 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

11. 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)

12. 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.

13. 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)

14. Development Schedule (Core) System dependant code – ready RadWin driver interface – 5 days Local Filter – 5 days Local Database – 5 days Communication - 5 days

15. Development Schedule (Reports Server) System dependant code – 5 days Local Filter – 5 days Local Database – 5 days Communication - 5 days

16. 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.

17. 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.

18. 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

19. 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 … k2 kn k1 1 2 n

20. 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)

21. 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

22. 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

23. 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.

24. 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