Difference between revisions of "GSOC2012NetworkAddressTranslation"

From Nsnam
Jump to: navigation, search
(Project Contact)
 
(5 intermediate revisions by one other user not shown)
Line 5: Line 5:
 
* Abstract:  Implementing a solid working NAT model for the NS3 framework taking into account the different behavior that NAT exhibits in a network equipping the node to act as a successful network edge device, also giving way for further security (firewall) implementations. This would include reusing Netfilter implementation on NS3 to facilitate NAT and then implement NAT itself. This would mimic the Linux NAT model and have added extensions.
 
* Abstract:  Implementing a solid working NAT model for the NS3 framework taking into account the different behavior that NAT exhibits in a network equipping the node to act as a successful network edge device, also giving way for further security (firewall) implementations. This would include reusing Netfilter implementation on NS3 to facilitate NAT and then implement NAT itself. This would mimic the Linux NAT model and have added extensions.
 
* Mid-Term: https://www.nsnam.org/wiki/index.php/GSOC2012NetworkAddressTranslationMidTermReview
 
* Mid-Term: https://www.nsnam.org/wiki/index.php/GSOC2012NetworkAddressTranslationMidTermReview
 +
* Final Review code: https://codereview.appspot.com/6454146/
 +
* Code Repo : http://code.nsnam.org/vsindhuja/ns-3-gsoc-nat/
  
 
==Introduction==
 
==Introduction==
Line 66: Line 68:
  
 
- Appropriate routing of the packet
 
- Appropriate routing of the packet
 
 
- Packet filtering in place
 
- Packet filtering in place
 
 
- Header fields in the packet updated as per netfilter and nat rules
 
- Header fields in the packet updated as per netfilter and nat rules
 
- Connection tracking maintained
 
 
 
- Checksum computation accuracy
 
- Checksum computation accuracy
  
Line 109: Line 106:
 
The above rule would translate 192.168.2.3:80 in the private realm to 10.1.3.4:8080 in the public realm, for all protocols (last field is zero).
 
The above rule would translate 192.168.2.3:80 in the private realm to 10.1.3.4:8080 in the public realm, for all protocols (last field is zero).
  
==Open Issue Tracker==
+
===Dynamic Nat Example===
 +
In order to configure the node to perform Dynamic Nat one would do the following:
  
* 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.
+
Follow the steps till setting the inside and outside interface as mentioned in the above example.
* 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.
+
The following code with set the address pool to which the dynamic nat translation would occur:
 +
 
 +
      nat->AddAddressPool (Ipv4Address ("192.168.1.5"), Ipv4Mask ("255.255.255.255"));
 +
 
 +
The following code adds the port range to which the host would translate
 +
 
 +
    nat->AddPortPool (49153, 49163);
 +
 
 +
The following rule would translate all the IP addresses in 192.168.1.0 network in a dynamic translation.
 +
 
 +
    Ipv4DynamicNatRule rule (Ipv4Address ("192.168.1.0"), Ipv4Mask ("255.255.255.0"));
 +
    nat->AddDynamicRule (rule);
 +
 
 +
The above would translate the ip addresses from the 192.168.1.0/24 network to the ip 192.168.1.5 with ports between 49153 and 49163.
 +
 
 +
==Open Issue Tracker==
 +
* Adding port pool options to Dynamic nat rather than translating to a single ip and port address translation
 +
* Adding checksum checks to the static and Dynamic Nat.
 +
* Adding test suite for dynamic Nat.

Latest revision as of 15:00, 7 December 2014

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 - Checksum computation accuracy

Usage

Static Nat Example

NAT is a capability that is aggregated to a node that includes an IPv4 stack with Netfilter capability. From a user perspective, NAT is typically configured by creating the NAT object and adding rules to the table.

The following are the steps of things to be done when converting a node to a NAT node:

  // obtain a node pointer "node"
  Ipv4NatHelper natHelper
  Ptr<Ipv4Nat> nat = natHelper.Install (node);

Next, define the inside and the outside interfaces of the NAT. These are the interfaces between which the nat will be processed. The Ipv4Interface indices are used to refer to the NAT interfaces:

  nat->SetInside (1);
  nat->SetOutside (2);

NAT is configured to block all traffic that does not match one of the configured rules. The user would configure rules next, such as follows:

  // specify local and global IP addresses
  Ipv4StaticNatRule rule (Ipv4Address ("192.168.1.1"), Ipv4Address ("203.82.48.100"));
  nat->AddStaticRule (rule);

The following code will help printing the NAT rules to a file nat.rules from the stream:

  Ptr<OutputStreamWrapper> natStream = Create<OutputStreamWrapper> ("nat.rules", std::ios::out);
  nat->PrintTable (natStream);

The above illustrates a typical example of a one to one static NAT. The other variant in the static nat rule for which the ports can be defined:

  Ipv4StaticNatRule rule2 (Ipv4Address ("192.168.2.3"), 80, Ipv4Address ("10.1.3.4"), 8080, 0);
  nat->AddStaticRule (rule2);

The above rule would translate 192.168.2.3:80 in the private realm to 10.1.3.4:8080 in the public realm, for all protocols (last field is zero).

Dynamic Nat Example

In order to configure the node to perform Dynamic Nat one would do the following:

Follow the steps till setting the inside and outside interface as mentioned in the above example.

The following code with set the address pool to which the dynamic nat translation would occur:

     nat->AddAddressPool (Ipv4Address ("192.168.1.5"), Ipv4Mask ("255.255.255.255"));

The following code adds the port range to which the host would translate

    nat->AddPortPool (49153, 49163);

The following rule would translate all the IP addresses in 192.168.1.0 network in a dynamic translation.

    Ipv4DynamicNatRule rule (Ipv4Address ("192.168.1.0"), Ipv4Mask ("255.255.255.0"));
    nat->AddDynamicRule (rule);

The above would translate the ip addresses from the 192.168.1.0/24 network to the ip 192.168.1.5 with ports between 49153 and 49163.

Open Issue Tracker

  • Adding port pool options to Dynamic nat rather than translating to a single ip and port address translation
  • Adding checksum checks to the static and Dynamic Nat.
  • Adding test suite for dynamic Nat.