GSOC2012NetworkAddressTranslation

From Nsnam
Revision as of 07:16, 21 August 2012 by Vsindhuja (Talk | contribs)

Jump to: navigation, search

Project Contact

Introduction

The main goal of this project is going to be to introduce Network Address Translation models into the NS-3 framework. While implementing NAT itself we are also going to focus on working on building the base for a larger framework that supports connection tracking and other firewall features. Most of this design would be modeled off of the Netfilter framework in Linux. The specifics of the implementation will be updated on further progress.

This project builds on the work previously done by Qasim Javed and Adrian Tam in 2009.

Project Rationale

The primary purposes of adding the Nefilter and NAT functionality to NS-3 is to enable the testing the performance of host-based protocols such as peer-to-peer applications, in which case having a nat model would give way for assessing the nat traversal aspects of these protocol models. Another area of interest in introducing the above would be to continue working to build a packet filtering framework that would grow to support connection tracking and firewall modeling in NS-3. This would help recreate more real world network scenarios where firewalls are ubiquitous.

Approach

Design

The work will primarily be divided in two main parts:

Netfilter Framework

For the first part I am considering working off of the existing model that was proposed for performing a Netfilter and suiting it to the current ns3 version.

1.This would have 5 hooks

       o   NF_INET_PRE_ROUTING
       o   NF_INET_LOCAL_IN
       o   NF_INET_FORWARD
       o   NF_INET_LOCAL_OUT
       o   NF_INET_POST_ROUTING

2.Callback chaining

Typically on each of the Hooks above mentioned callback methods are invoked in order to track the action to be taken. The fundamental callback functions that can now be implemented to support nat are for connection tracking and Nat itself. Priorities are also assigned to these to determine the order in which the callbacks are invoked.

3.Connection tracking

To maintain the state of the connection making the node one that is stateful.

Network Address Translation

Network address translation (NAT) is a process of altering the source/destination IP address of a packet in order to make it routable over a network. This is usually applied when packets are passed from a private address realm to a public network. Network address translation is also used in IP address hiding where hosts can be on the address behind the NAT device and cannot be directly reached from an external network. NAT also comes with a number of variants in terms of what fieldd of the packet is translated through the NAT (e.g.port numbers) or the directions of the NAT (e.g. unidirectional vs bidirectional).

While NAT is mainly deployed for operational purposes (managing IP address space), the inclusion of simulation models of NAT may be helpful to developers of peer-to-peer applications for ns-3 who wish to evaluate the NAT traversal aspects of the application.

The source code for this model lives in the directory src/internet/model.

The design of NAT for ns-3 is basically divided into two main categories:

- Static NAT: This type of NAT allows IP flows to be established in either direction. It is designed to perform host to host NAT and also has a variant to specify the nat for specific protocol and port. In practice,this type of NAT may be more often found in enterprise environments.

- Dynamic NAT: This type of NAT typically allows IP flows to be established only in one direction, from private address realm to public address realm. Often, multiple hosts may be multiplexed onto a single public IP address via port translation. The NAT state is dynamic and times out after a period of inactivity. In practice, this type of NAT may be more often found in home networks.

Testing

For the tests of the Nat and Netfilter will focus on a base simulation would be used

n1--n2--n3

where n2 is the nat device with n1 on the private network and n3 is out on the internet. Multiple aspects would be looked at while testing :

- Appropriate routing of the packet

- Packet filtering in place

- Header fields in the packet updated as per netfilter and nat rules

- Connection tracking maintained

- Checksum computation accuracy

Open Issue Tracker

  • Need to consider what is the proper way to generically handle different protocol types for which there is no conntrack helper (i.e. not TCP or UDP). Presently, the code will NF_ACCEPT them.
  • Need to provide patches to code review without white space changes
  • NF_LOCAL_OUT wants an IP header to be attached to the packet. However, for unicast delivery, the function SendRealOut() is where the real header is appended. As a result, if there is a mangle operation on the IP header, this header will not be saved. this requires some refactoring of IPv4L3Protocol to allow the (mangled) header to be saved.