1 Open projects for the netsniff-ng toolkit are listed here. However, those are
2 current ideas for projects that came to our mind. We are also open for blue-sky
3 proposals that are not included in this list. If you are interested in
4 participation, let us know! We are always looking forward to get help in
8 - Better protocol support for netsniff-ng's dissector: Until now, netsniff-ng
9 only supports a small subsets of protocols with rather low-level information
10 output. The aim is to improve currently supported protocols and add new
11 important protocols that should be shipped with netsniff-ng.
13 - Required skills: C, Protocols
14 - Difficulty: Easy - Medium
17 - Extensive testing (with eventual code fixing) and performance evaluation:
18 The three more complex projects of the toolkit need a throughout evaluation
19 of all their features, if they work stable under stress, if the features do
20 what they should do. In error cases, code must be fixed of course. Also,
21 the three tools should be evaluated and reviewed regarding performance (pps),
22 if optimizations can be made in the critical path. Optimizations should be
23 compared in regard to packets per second before and after the change.
24 - Tool: netsniff-ng, trafgen (both with Jumbo frames), curvetun
25 - Required skills: Testing, C
26 - Difficulty: Easy - Hard
29 - Reduce general code size, refactor, improve code (i.e. rewrite parsers):
30 Some of the toolkit's code is quite messy and some code totally unused.
31 The aim is to find such code sections and improve them in order to reduce
32 overall code size, and improve readability and software design without
33 introducing a decrease of performance.
36 - Difficulty: Easy - Hard
39 - Improve manpages, write a user's guide, maybe technical paper: Until now,
40 the focus on the toolkit was the implementation, but not that intensively
41 on the documentation. The latter is even more important for potential users.
42 Hence, manpages should be improved in depth, examples should be given and
43 a more complex documentation or technical paper should be written in LaTeX.
45 - Required skills: POD, Manpages, LaTeX
46 - Difficulty: Easy - Medium
49 - TPACKETv2 (TPACKETv3) support: Right now, the toolkit uses the TPACKETv1
50 API for the RX_RING and TX_RING of the Linux kernel. We would like to know
51 if there's a potential benefit of migrating the code to TPACKETv2 or
52 TPACKETv3 (if released). If so, then the current code should be migrated
53 to the more up-to-date TPACKET version including a review of a potential
54 performance benefit or degradation.
55 - Tool: netsniff-ng, trafgen
57 - Difficulty: Easy - Medium
60 - PCAP anonymization support: Similar to scrub-tcpdump, we would like to see
61 a possibility for packet anonymization in netsniff-ng. This means, that the
62 resulting pcap file can be used for collaboration or released without
63 corrupting anonymity of the network represented by the capture flow.
64 (http://scrub-tcpdump.sourceforge.net/index.php)
67 - Difficulty: Easy - Medium
70 - Improve ifpps with things like 'Gnuplot support', 'Power usage / temperature',
71 'Colorized output': ifpps is a useful tool to monitor the system and
72 especially the network subsystem. It could be even more useful if it has
73 features like exporting data into Gnuplot or RRD files, like adding more
74 sensor data output like power states or temperature values, and additionally
75 it could also have a colored output just like flowtop.
77 - Required skills: C, Gnuplot, Procfs
78 - Difficulty: Easy - Medium
81 - Add IPv6 support: ashunt and flowtop have been implemented in IPv4 with
82 stubs for IPv6 code. IPv6 support should be implemented and tested
83 intensively. Possibly, existing code needs to be improved and refactored
84 for IPv6 integration. IPv6 support in curvetun already exists. However,
85 it still needs throughout testing.
86 - Tool: ashunt, flowtop, curvetun (testing)
91 - Implement Packet departure timing models (i.e. exponential, uniform, cauchy,
92 normal, pareto distributed) and other packet scheduling behaviours (MB/s,
93 ...), ideally as a plugin architecture for trafgen. Until now, there are
94 only two working modes in trafgen: high-speed and a static inter-departure
95 timing gap. Hence, such features need to be added for a traffic generator.
98 - Difficulty: Medium - Hard
101 - Unit test preparation and integration for the whole toolkit: Right now, the
102 netsniff-ng toolkit does not have a suite with test cases, although
103 netsniff-ng highly needs a test suite. This project's intention is to
104 evaluate which test frameworks are appropriate for the toolkit, to integrate
105 those frameworks with an initial set of unit tests for each framework.
107 - Required skills: C, Shell, Sharness?, Coccinelle?, CMake?
108 - Difficulty: Medium - Hard
111 - Interactive txf config generator with a set of supported protocols and
112 support for packet distribution models (IMIX, Cisco, ...): We would like
113 to see an interactive txf generator, so that a set of supported protocols
114 can be used to generate full packets in byte format. For instance,
115 protocols such as VLAN, MPLS, BPDU, IGMP, DNS, ARP, ICMP, HTTP, SIP,
116 IPv4 / IPv6, UDP, TCP. The Cisco-like libcli can be used for the UI.
117 It should be triggered by 'trafgen --generate' and write a txf file in the
118 end. Maybe there's something to reuse from the Mausezahn traffic generator
119 (http://www.perihel.at/sec/mz/)? (http://code.google.com/p/libcli/)
121 - Required skills: C, Protocols
125 - PCAP-ng support: The PCAP-ng format is the next-generation of PCAP as
126 described in (http://wiki.wireshark.org/Development/PcapNg). We would like
127 to support both, the old PCAP and the new PCAP-ng format. Hence, we're
128 looking for PCAP-ng support in netsniff-ng. Design and implement it
129 appropriately, so that both formats can be used and that the source code
130 stays clear and doesn't introduce artificial software layers that can
131 cause a performance bottleneck.
137 - Better obfuscation method of curvetun's protocol to make it hard for DPIs
138 to detect curvetun: Right now, curvetun might be quite hard to detect, but
139 with a little effort, it is still possible for DPIs. Find a way to obfuscate
140 the protocol, so that _either_ it is not distinguishable from random byte
141 garbage _or_ find possible ways to use steganography, thus the encrypted
142 payload stream is hidden in real-world traffic.
145 - Difficulty: Very Hard
148 - Perform a security review of curvetun: The implementation of curvetun is
149 a proof-of-concept and the origin for the implementation was out of interest.
150 Since this tool is useful for real-world deployment, we need security reviews
151 to make sure that the deployment would be appropriate. Hence, this project
152 concentrates on code reviews and improvement regaring security of curvetun.
154 - Required skills: C, Crypto
155 - Difficulty: Very Hard
158 - Design and implement a high-level packet filtering language that compiles
159 to bpf code: Right now, filters for netsniff-ng needs to be implemented
160 with our bpfc compiler (language: http://netsniff-ng.org/bpf.pdf), or
161 generated with ``tcpdump -dd <filter>''. We would like a higher level
162 filter description language that transforms the resulting filter into
163 the bpf language that can be translated by our bpfc compiler.
164 - Tool: either inclusion in bpfc or a new one
165 - Required skills: Haskell or C
166 - Difficulty: Very Hard