Difference between revisions of "GSOC2009NetworkAddressTranslation"

From Nsnam
Jump to: navigation, search
(Schedule)
Line 6: Line 6:
  
 
We aim to implement something similar to netfilter framework for ns-3. This will make it easy to add firewall functionality to ns-3 in the future.
 
We aim to implement something similar to netfilter framework for ns-3. This will make it easy to add firewall functionality to ns-3 in the future.
 +
 +
== Background ==
 +
 +
A Linux kernel module can register multiple functions at each of the netfilter hooks. The netfilter framework maintains a 2-dimensional array nf_hooks[NFPROTO_NUMPROTO][NF_MAXHOOKS] of circular linked lists. When a function is registered using nf_register_hook, a variable of type "struct nf_hook_ops" (which contains the function to be registered) is added to the appropriate list. The position within the list is determined by the priority specified in the "struct nf_hook_ops" type variable.
 +
 +
When a packet traverses the hook, for instance, in ip_rcv function, NF_HOOK macro is called which ends up invoking nf_hook_slow. This is the interface between the routing code and the netfilter framework. As this is the NF_PREROUTING hook, and assuming that IPv4 is being used, the linked list at nf_hooks[PF_INET][NF_PREROUTING] is consulted and the functions registered at the hook are invoked. The nf_iterate function is used to iterate through the linked list, invoking the "hook" member of the "struct nf_hook_ops" variable in turn.
  
 
== Approach ==
 
== Approach ==

Revision as of 09:23, 11 June 2009

Introduction

The aim of this project is to add Network Address Translation (NAT) functionality to ns-3. Instead of just implementing NAT, we are working on implementing an extensible framework. This way if firewall functionality needs to implemented in the future, the framework can be used to do that. The inspiration for such a framework comes from the netfilter framework in the Linux kernel.

Netfilter creates fives hooks in the Linux kernel networking stack. A developer can register functions at each of the hooks. These functions get called when a packet traverses the hook. While registering a function at a hook, a priority needs to be specified which will determine the order in which the function will be executed. Userspace utilities such as iptables do not interact directly with netfilter, rather, they interact with kernel modules which in turn interact with the netfilter framework.

We aim to implement something similar to netfilter framework for ns-3. This will make it easy to add firewall functionality to ns-3 in the future.

Background

A Linux kernel module can register multiple functions at each of the netfilter hooks. The netfilter framework maintains a 2-dimensional array nf_hooks[NFPROTO_NUMPROTO][NF_MAXHOOKS] of circular linked lists. When a function is registered using nf_register_hook, a variable of type "struct nf_hook_ops" (which contains the function to be registered) is added to the appropriate list. The position within the list is determined by the priority specified in the "struct nf_hook_ops" type variable.

When a packet traverses the hook, for instance, in ip_rcv function, NF_HOOK macro is called which ends up invoking nf_hook_slow. This is the interface between the routing code and the netfilter framework. As this is the NF_PREROUTING hook, and assuming that IPv4 is being used, the linked list at nf_hooks[PF_INET][NF_PREROUTING] is consulted and the functions registered at the hook are invoked. The nf_iterate function is used to iterate through the linked list, invoking the "hook" member of the "struct nf_hook_ops" variable in turn.

Approach

In order to implement Network Address Translation, we need to be able to defragment the IP packets. Also, hooks will be implemented using the ns-3 callbacks. These hooks will be added to appropriate locations in the ns-3 networking stack. More details will be added soon.

There will be a class which will store the mappings created by Network Address Translation. Moreover, there needs to be way for the user to configure NAT. This should be dynamic considering that the framework can be used for packet inspection or firewall.

Connection tracking will implement protocol specific handlers for NAT. For instance, FTP, ICMP, SIP etc. Although this project will not implement the handlers themselves but it aims to provide an API so that developers can implement protocol specific connection tracking.

  • IP packet defragmentation
  • Five hooks (using ns-3 callbacks)
  • A class that stores the NAT mappings (4-tuples)
  • A mechanism to configure NAT
  • Connection tracking


Schedule

The first two weeks will be spent studying the ns-3 networking stack and how a framework similar to netfilter can be implemented for ns-3.

  • Week 3: Implement and test IP packet defragmentation
  • Week 4,5: Implement hooks using ns-3 callbacks and a class for storing the created NAT mappings
  • Week 6: Test basic NAT functionality
  • Week 7-8: Implement Connection tracking API and start testing
  • Week 9: Implement any NAT helpers or user configuration options
  • Week 10: Merge with ns-3 codebase

Questions