Difference between revisions of "GSOC2012NetworkAddressTranslation"

From Nsnam
Jump to: navigation, search
(Project Contact)
 
(13 intermediate revisions by 2 users not shown)
Line 4: Line 4:
 
* Mentor: [mailto:tomhend@u.washington.edu Tom Henderson],[mailto:daniel.camara@inria.fr Daniel Camara]
 
* Mentor: [mailto:tomhend@u.washington.edu Tom Henderson],[mailto:daniel.camara@inria.fr Daniel Camara]
 
* 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
 +
* Final Review code: https://codereview.appspot.com/6454146/
 +
* Code Repo : http://code.nsnam.org/vsindhuja/ns-3-gsoc-nat/
  
 
==Introduction==
 
==Introduction==
Line 23: Line 26:
 
The work will primarily be divided in two main parts:
 
The work will primarily be divided in two main parts:
  
'''A.Building the Netfilter Framework '''
+
====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.
 
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.
Line 42: Line 45:
 
To maintain the state of the connection making the node one that is stateful.
 
To maintain the state of the connection making the node one that is stateful.
  
'''B.Implementing the main NAT models'''
+
====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).
  
When enabling NAT on a node it is specific to that particular node and it is not necessary to enable NAT on a collection of nodes.
+
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.
  
''Static one-to-one NAT''
+
The source code for this model lives in the directory src/internet/model.
  
This NAT would be persistent for all the connections made from that host. When I port is specified then it would remain specific to that port. This translation can never get cleared out or timed out. Unless one manually removes the configuration.
+
The design of NAT for ns-3 is basically divided into two main categories:
  
''Regular Dynamic NAT''
+
'''- 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.
       
+
This is the NAT where all the traffic is translated to one IP address and multiple ports(Port address translation).
+
 
+
''User Specific API''
+
 
+
At a very generic level of explaining this I start with when nat is enabled on a node. The user would invoke something like :
+
 
+
Nat_Install(node,lan-interface,wan-interface)
+
 
+
This would clearly set the interfaces of the node participating in the NATting.
+
 
+
Once this is done the user would configure the
+
 
+
Static one-to-one:
+
 
+
static_nat(lan-ip,wan-ip);
+
 
+
static_nat(lan-ip,wan-ip,port-range) //in the case of number of ports
+
 
+
Dynamic NAPT:
+
 
+
dynamic_nat(lan-ip network with mask,wan-ip);
+
 
+
A more NS-3 specific interface definition will be updated in the course of this project.
+
  
 +
'''- 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===
 
===Testing===
Line 87: 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
 +
- Checksum computation accuracy
  
- Connection tracking maintained
+
==Usage==
  
- Checksum computation accuracy
+
===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:
  
==Plan==
+
  nat->SetInside (1);
 +
  nat->SetOutside (2);
  
·Week 1: (22/05-29/05) Adapt the existing Netfilter code to the current NS3
+
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:
  
·Week 2: (30/05-06/06) Test the adaptation for the Netfilter code to current NS3
+
  // specify local and global IP addresses
 +
  Ipv4StaticNatRule rule (Ipv4Address ("192.168.1.1"), Ipv4Address ("203.82.48.100"));
 +
  nat->AddStaticRule (rule);
  
·Week 3: (07/06-14/06) Static one-to-one Design and Implementation
+
The following code will help printing the NAT rules to a file nat.rules from the stream:
  
·Week 4: (15/06-22/06) Static one-to-one Design and Implementation
+
  Ptr<OutputStreamWrapper> natStream = Create<OutputStreamWrapper> ("nat.rules", std::ios::out);
 +
  nat->PrintTable (natStream);
  
·Week 5: (23/06-30/06) Test the Static one-to-one Implementations.
+
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:
  
·Week 6: (01/07-08/07) Dynamic Port-Translating NAT Design and Implementation
+
  Ipv4StaticNatRule rule2 (Ipv4Address ("192.168.2.3"), 80, Ipv4Address ("10.1.3.4"), 8080, 0);
 +
  nat->AddStaticRule (rule2);
  
·09/07- Midterm evaluation submission
+
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).
  
·Week 7: (10/07-17/07) Dynamic Port-Translating NAT Design and Implementation
+
===Dynamic Nat Example===
 +
In order to configure the node to perform Dynamic Nat one would do the following:
  
·Week 8: (18/07-25/07) Testing the Dynamic Port-Translating NAT implementation.
+
Follow the steps till setting the inside and outside interface as mentioned in the above example.  
  
·Week 9: (26/07-02/08) Test and Work on integration of the NAT Models
+
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"));
  
·Week 10: (03/08-10/08)Test and Work on integration of the NAT Models
+
The following code adds the port range to which the host would translate
 +
 
 +
    nat->AddPortPool (49153, 49163);
  
·Aug 13 Suggested Pencils Down Date.
+
The following rule would translate all the IP addresses in 192.168.1.0 network in a dynamic translation.
  
·11/08-19/08: Documentation and Integration of the project
+
    Ipv4DynamicNatRule rule (Ipv4Address ("192.168.1.0"), Ipv4Mask ("255.255.255.0"));
 +
    nat->AddDynamicRule (rule);
  
·20/08 - Final Evaluation and Submission.
+
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==
 
==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.