GSoC 2018 proposal
I publish this post so that we have all my GSoC 2018 related things together here. Here you can read my original proposal which was submitted to the program. You can also read it on the Summer of Code project page.
Transparent proxy refactoring
Abstarct
Nftables is the successor of {ip,ip6,arp,eb}tables as a network filtering and classification framework. Its enhancement is to unite all the tools for different protocols and provide a complex interface to manage them.
My plan is to refactor the iptables implementation of transparent proxying , and move its functionality to an external library which can then be used by nftables, too.
About me
I am a first-year masters student in Computer Engineering at Budapest University of Technology and Informatics, and my main specialisation is computer networking. My experience includes volunteering in a networking-related IT group, and working at smaller companies, where I did network and system administration (Cisco and Linux), and network function implementation like DDNS service and VoIP measuring instrument (the last one was my BSc thesis).
Apart from Cisco, Linux is an important platform for me, the implemented services mentioned above were made for Linux environment. During my works I used open-source projects and libraries, however I do not have any notable contribution yet.
Contact info
- Full name: Máté Eckl
- Email: xxxxxxxxxxxxxxxxx
- Phone: xxxxxxxxxxxx
Benefits to Community
As iptables was created much before nftables, most of the filtering and manipulation framework functionality was originaly implemented in iptables’ code and thus it was iptables-specific.
TPROXY is still one of these.
With my commitment, it would become possible to use already implemented functionality from both iptables and nftables, thus transparent proxying would become available for the new framework, too. This can later be extended with cli support which finally offers the transparent proxying to the users.
Deliverables
To deliver full functionality, support should be implemented in different parts, which are the following:
- Functionality should be extracted from iptables
- Nftables kernel module should be implemented using the extracted library
- Libnftnl should be extended to support the new functionality
- Nft cli frontend should use the libnftnl interface to offer transparent proxying to users.
The items below the line are considered optional in case the obligatory part is completed much before the final deadline. I only schedule the obligatory part in my working plan.
Documentation will be produced in a way that the community supports (probably different for every part), and if there is no such way (they do not document their code, and they do not accept my way to do it), it will be omitted.
Proposal Timeline
During the coding, I plan to go on holiday for 2-3 days (weekend excluded), during which I will only be available by mobile phone. I do not know exactly when, but I will try to schedule it right after one of the evaluation periods.
Before 23 April
- Investigate differences between transparent proxy and destiation nat
- Set up a fail-proof development environment
- Try transparent proxying with iptables
23 April – 14 May (Community bonding)
- Test network preparation
- Use case investigation
- Preparing traffic generation to help investigation
- Discussing workflow with the mentor(s)
- Get to know to contribution conventions more deeply
- More detailed investigation of relevant netfilter and iptables codebase
14 May – 11 June (Until first mid-term evaluation)
- Identify code to be extracted
- Plan the structure and interface of the library
- Create the library and make iptables module use it
- Constant documentation
11 June – 9 July (Until second mid-term evaluation)
- Submit patches to the community, fix bugs if any, iptables module refactoring should be accepted by the end (maximum of two weeks)
-
Plan the layout of the nftables kernel module, to fit a possible user interface design.
- Start nftables module implementation
9 – 24 July
- Implement the nftables kernel module
- Consulting with the mentor(s) before aproaching the final deadline
24 July – 6 August
This last time slot should be used for one of the following:
- Catching up with delayed work
- Code refinement
- Implementation of parts from the optional section mentioned above.
- Help the community in bug hunting