https://www.nsnam.org/mediawiki/api.php?action=feedcontributions&user=Vsindhuja&feedformat=atomNsnam - User contributions [en]2024-03-29T11:29:09ZUser contributionsMediaWiki 1.24.1https://www.nsnam.org/mediawiki/index.php?title=GSOC2012NetworkAddressTranslation&diff=7043GSOC2012NetworkAddressTranslation2012-10-24T05:15:06Z<p>Vsindhuja: /* Project Contact */</p>
<hr />
<div>==Project Contact==<br />
<br />
* Student: [mailto:intutivestriker88@gmail.com V. Sindhuja]<br />
* Mentor: [mailto:tomhend@u.washington.edu Tom Henderson],[mailto:daniel.camara@inria.fr Daniel Camara]<br />
* 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.<br />
* Mid-Term: https://www.nsnam.org/wiki/index.php/GSOC2012NetworkAddressTranslationMidTermReview<br />
*Code Repo : http://code.nsnam.org/vsindhuja/ns-3-gsoc-nat/<br />
<br />
==Introduction==<br />
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.<br />
The specifics of the implementation will be updated on further progress.<br />
<br />
This project builds on the work previously done by Qasim Javed and Adrian Tam in [[GSOC2009NetworkAddressTranslation | 2009]].<br />
<br />
==Project Rationale==<br />
<br />
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.<br />
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. <br />
This would help recreate more real world network scenarios where firewalls are ubiquitous.<br />
<br />
==Approach==<br />
<br />
===Design===<br />
<br />
The work will primarily be divided in two main parts:<br />
<br />
====Netfilter Framework====<br />
<br />
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.<br />
<br />
''1.This would have 5 hooks''<br />
o NF_INET_PRE_ROUTING<br />
o NF_INET_LOCAL_IN<br />
o NF_INET_FORWARD<br />
o NF_INET_LOCAL_OUT<br />
o NF_INET_POST_ROUTING<br />
<br />
''2.Callback chaining''<br />
<br />
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.<br />
<br />
''3.Connection tracking''<br />
<br />
To maintain the state of the connection making the node one that is stateful.<br />
<br />
====Network Address Translation====<br />
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).<br />
<br />
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.<br />
<br />
The source code for this model lives in the directory src/internet/model.<br />
<br />
The design of NAT for ns-3 is basically divided into two main categories: <br />
<br />
'''- 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.<br />
<br />
'''- 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.<br />
<br />
===Testing===<br />
<br />
For the tests of the Nat and Netfilter will focus on a base simulation would be used <br />
<br />
n1--n2--n3 <br />
<br />
where n2 is the nat device with n1 on the private network and n3 is out on the internet.<br />
Multiple aspects would be looked at while testing : <br />
<br />
- Appropriate routing of the packet<br />
- Packet filtering in place<br />
- Header fields in the packet updated as per netfilter and nat rules<br />
- Checksum computation accuracy<br />
<br />
==Usage==<br />
<br />
===Static Nat Example===<br />
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.<br />
<br />
The following are the steps of things to be done when converting a node to a NAT node:<br />
<br />
// obtain a node pointer "node"<br />
Ipv4NatHelper natHelper<br />
Ptr<Ipv4Nat> nat = natHelper.Install (node);<br />
<br />
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:<br />
<br />
nat->SetInside (1);<br />
nat->SetOutside (2);<br />
<br />
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:<br />
<br />
// specify local and global IP addresses<br />
Ipv4StaticNatRule rule (Ipv4Address ("192.168.1.1"), Ipv4Address ("203.82.48.100"));<br />
nat->AddStaticRule (rule);<br />
<br />
The following code will help printing the NAT rules to a file nat.rules from the stream:<br />
<br />
Ptr<OutputStreamWrapper> natStream = Create<OutputStreamWrapper> ("nat.rules", std::ios::out);<br />
nat->PrintTable (natStream);<br />
<br />
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:<br />
<br />
Ipv4StaticNatRule rule2 (Ipv4Address ("192.168.2.3"), 80, Ipv4Address ("10.1.3.4"), 8080, 0);<br />
nat->AddStaticRule (rule2);<br />
<br />
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).<br />
<br />
===Dynamic Nat Example===<br />
In order to configure the node to perform Dynamic Nat one would do the following:<br />
<br />
Follow the steps till setting the inside and outside interface as mentioned in the above example. <br />
<br />
The following code with set the address pool to which the dynamic nat translation would occur:<br />
<br />
nat->AddAddressPool (Ipv4Address ("192.168.1.5"), Ipv4Mask ("255.255.255.255"));<br />
<br />
The following code adds the port range to which the host would translate<br />
<br />
nat->AddPortPool (49153, 49163);<br />
<br />
The following rule would translate all the IP addresses in 192.168.1.0 network in a dynamic translation.<br />
<br />
Ipv4DynamicNatRule rule (Ipv4Address ("192.168.1.0"), Ipv4Mask ("255.255.255.0"));<br />
nat->AddDynamicRule (rule);<br />
<br />
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.<br />
<br />
==Open Issue Tracker==<br />
* Adding port pool options to Dynamic nat rather than translating to a single ip and port address translation<br />
* Adding checksum checks to the static and Dynamic Nat.<br />
* Adding test suite for dynamic Nat.</div>Vsindhujahttps://www.nsnam.org/mediawiki/index.php?title=GSOC2012NetworkAddressTranslation&diff=6956GSOC2012NetworkAddressTranslation2012-08-21T07:34:00Z<p>Vsindhuja: /* Testing */</p>
<hr />
<div>==Project Contact==<br />
<br />
* Student: [mailto:intutivestriker88@gmail.com V. Sindhuja]<br />
* Mentor: [mailto:tomhend@u.washington.edu Tom Henderson],[mailto:daniel.camara@inria.fr Daniel Camara]<br />
* 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.<br />
* Mid-Term: https://www.nsnam.org/wiki/index.php/GSOC2012NetworkAddressTranslationMidTermReview<br />
<br />
==Introduction==<br />
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.<br />
The specifics of the implementation will be updated on further progress.<br />
<br />
This project builds on the work previously done by Qasim Javed and Adrian Tam in [[GSOC2009NetworkAddressTranslation | 2009]].<br />
<br />
==Project Rationale==<br />
<br />
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.<br />
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. <br />
This would help recreate more real world network scenarios where firewalls are ubiquitous.<br />
<br />
==Approach==<br />
<br />
===Design===<br />
<br />
The work will primarily be divided in two main parts:<br />
<br />
====Netfilter Framework====<br />
<br />
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.<br />
<br />
''1.This would have 5 hooks''<br />
o NF_INET_PRE_ROUTING<br />
o NF_INET_LOCAL_IN<br />
o NF_INET_FORWARD<br />
o NF_INET_LOCAL_OUT<br />
o NF_INET_POST_ROUTING<br />
<br />
''2.Callback chaining''<br />
<br />
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.<br />
<br />
''3.Connection tracking''<br />
<br />
To maintain the state of the connection making the node one that is stateful.<br />
<br />
====Network Address Translation====<br />
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).<br />
<br />
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.<br />
<br />
The source code for this model lives in the directory src/internet/model.<br />
<br />
The design of NAT for ns-3 is basically divided into two main categories: <br />
<br />
'''- 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.<br />
<br />
'''- 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.<br />
<br />
===Testing===<br />
<br />
For the tests of the Nat and Netfilter will focus on a base simulation would be used <br />
<br />
n1--n2--n3 <br />
<br />
where n2 is the nat device with n1 on the private network and n3 is out on the internet.<br />
Multiple aspects would be looked at while testing : <br />
<br />
- Appropriate routing of the packet<br />
- Packet filtering in place<br />
- Header fields in the packet updated as per netfilter and nat rules<br />
- Checksum computation accuracy<br />
<br />
==Usage==<br />
<br />
===Static Nat Example===<br />
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.<br />
<br />
The following are the steps of things to be done when converting a node to a NAT node:<br />
<br />
// obtain a node pointer "node"<br />
Ipv4NatHelper natHelper<br />
Ptr<Ipv4Nat> nat = natHelper.Install (node);<br />
<br />
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:<br />
<br />
nat->SetInside (1);<br />
nat->SetOutside (2);<br />
<br />
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:<br />
<br />
// specify local and global IP addresses<br />
Ipv4StaticNatRule rule (Ipv4Address ("192.168.1.1"), Ipv4Address ("203.82.48.100"));<br />
nat->AddStaticRule (rule);<br />
<br />
The following code will help printing the NAT rules to a file nat.rules from the stream:<br />
<br />
Ptr<OutputStreamWrapper> natStream = Create<OutputStreamWrapper> ("nat.rules", std::ios::out);<br />
nat->PrintTable (natStream);<br />
<br />
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:<br />
<br />
Ipv4StaticNatRule rule2 (Ipv4Address ("192.168.2.3"), 80, Ipv4Address ("10.1.3.4"), 8080, 0);<br />
nat->AddStaticRule (rule2);<br />
<br />
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).<br />
<br />
===Dynamic Nat Example===<br />
In order to configure the node to perform Dynamic Nat one would do the following:<br />
<br />
Follow the steps till setting the inside and outside interface as mentioned in the above example. <br />
<br />
The following code with set the address pool to which the dynamic nat translation would occur:<br />
<br />
nat->AddAddressPool (Ipv4Address ("192.168.1.5"), Ipv4Mask ("255.255.255.255"));<br />
<br />
The following code adds the port range to which the host would translate<br />
<br />
nat->AddPortPool (49153, 49163);<br />
<br />
The following rule would translate all the IP addresses in 192.168.1.0 network in a dynamic translation.<br />
<br />
Ipv4DynamicNatRule rule (Ipv4Address ("192.168.1.0"), Ipv4Mask ("255.255.255.0"));<br />
nat->AddDynamicRule (rule);<br />
<br />
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.<br />
<br />
==Open Issue Tracker==<br />
* Adding port pool options to Dynamic nat rather than translating to a single ip and port address translation<br />
* Adding checksum checks to the static and Dynamic Nat.<br />
* Adding test suite for dynamic Nat.</div>Vsindhujahttps://www.nsnam.org/mediawiki/index.php?title=GSOC2012NetworkAddressTranslation&diff=6955GSOC2012NetworkAddressTranslation2012-08-21T07:33:31Z<p>Vsindhuja: </p>
<hr />
<div>==Project Contact==<br />
<br />
* Student: [mailto:intutivestriker88@gmail.com V. Sindhuja]<br />
* Mentor: [mailto:tomhend@u.washington.edu Tom Henderson],[mailto:daniel.camara@inria.fr Daniel Camara]<br />
* 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.<br />
* Mid-Term: https://www.nsnam.org/wiki/index.php/GSOC2012NetworkAddressTranslationMidTermReview<br />
<br />
==Introduction==<br />
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.<br />
The specifics of the implementation will be updated on further progress.<br />
<br />
This project builds on the work previously done by Qasim Javed and Adrian Tam in [[GSOC2009NetworkAddressTranslation | 2009]].<br />
<br />
==Project Rationale==<br />
<br />
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.<br />
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. <br />
This would help recreate more real world network scenarios where firewalls are ubiquitous.<br />
<br />
==Approach==<br />
<br />
===Design===<br />
<br />
The work will primarily be divided in two main parts:<br />
<br />
====Netfilter Framework====<br />
<br />
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.<br />
<br />
''1.This would have 5 hooks''<br />
o NF_INET_PRE_ROUTING<br />
o NF_INET_LOCAL_IN<br />
o NF_INET_FORWARD<br />
o NF_INET_LOCAL_OUT<br />
o NF_INET_POST_ROUTING<br />
<br />
''2.Callback chaining''<br />
<br />
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.<br />
<br />
''3.Connection tracking''<br />
<br />
To maintain the state of the connection making the node one that is stateful.<br />
<br />
====Network Address Translation====<br />
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).<br />
<br />
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.<br />
<br />
The source code for this model lives in the directory src/internet/model.<br />
<br />
The design of NAT for ns-3 is basically divided into two main categories: <br />
<br />
'''- 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.<br />
<br />
'''- 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.<br />
<br />
===Testing===<br />
<br />
For the tests of the Nat and Netfilter will focus on a base simulation would be used <br />
<br />
n1--n2--n3 <br />
<br />
where n2 is the nat device with n1 on the private network and n3 is out on the internet.<br />
Multiple aspects would be looked at while testing : <br />
<br />
- Appropriate routing of the packet<br />
<br />
- Packet filtering in place<br />
<br />
- Header fields in the packet updated as per netfilter and nat rules<br />
<br />
- Connection tracking maintained<br />
<br />
- Checksum computation accuracy<br />
<br />
==Usage==<br />
<br />
===Static Nat Example===<br />
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.<br />
<br />
The following are the steps of things to be done when converting a node to a NAT node:<br />
<br />
// obtain a node pointer "node"<br />
Ipv4NatHelper natHelper<br />
Ptr<Ipv4Nat> nat = natHelper.Install (node);<br />
<br />
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:<br />
<br />
nat->SetInside (1);<br />
nat->SetOutside (2);<br />
<br />
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:<br />
<br />
// specify local and global IP addresses<br />
Ipv4StaticNatRule rule (Ipv4Address ("192.168.1.1"), Ipv4Address ("203.82.48.100"));<br />
nat->AddStaticRule (rule);<br />
<br />
The following code will help printing the NAT rules to a file nat.rules from the stream:<br />
<br />
Ptr<OutputStreamWrapper> natStream = Create<OutputStreamWrapper> ("nat.rules", std::ios::out);<br />
nat->PrintTable (natStream);<br />
<br />
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:<br />
<br />
Ipv4StaticNatRule rule2 (Ipv4Address ("192.168.2.3"), 80, Ipv4Address ("10.1.3.4"), 8080, 0);<br />
nat->AddStaticRule (rule2);<br />
<br />
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).<br />
<br />
===Dynamic Nat Example===<br />
In order to configure the node to perform Dynamic Nat one would do the following:<br />
<br />
Follow the steps till setting the inside and outside interface as mentioned in the above example. <br />
<br />
The following code with set the address pool to which the dynamic nat translation would occur:<br />
<br />
nat->AddAddressPool (Ipv4Address ("192.168.1.5"), Ipv4Mask ("255.255.255.255"));<br />
<br />
The following code adds the port range to which the host would translate<br />
<br />
nat->AddPortPool (49153, 49163);<br />
<br />
The following rule would translate all the IP addresses in 192.168.1.0 network in a dynamic translation.<br />
<br />
Ipv4DynamicNatRule rule (Ipv4Address ("192.168.1.0"), Ipv4Mask ("255.255.255.0"));<br />
nat->AddDynamicRule (rule);<br />
<br />
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.<br />
<br />
==Open Issue Tracker==<br />
* Adding port pool options to Dynamic nat rather than translating to a single ip and port address translation<br />
* Adding checksum checks to the static and Dynamic Nat.<br />
* Adding test suite for dynamic Nat.</div>Vsindhujahttps://www.nsnam.org/mediawiki/index.php?title=GSOC2012NetworkAddressTranslation&diff=6954GSOC2012NetworkAddressTranslation2012-08-21T07:32:02Z<p>Vsindhuja: </p>
<hr />
<div>==Project Contact==<br />
<br />
* Student: [mailto:intutivestriker88@gmail.com V. Sindhuja]<br />
* Mentor: [mailto:tomhend@u.washington.edu Tom Henderson],[mailto:daniel.camara@inria.fr Daniel Camara]<br />
* 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.<br />
* Mid-Term: https://www.nsnam.org/wiki/index.php/GSOC2012NetworkAddressTranslationMidTermReview<br />
<br />
==Introduction==<br />
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.<br />
The specifics of the implementation will be updated on further progress.<br />
<br />
This project builds on the work previously done by Qasim Javed and Adrian Tam in [[GSOC2009NetworkAddressTranslation | 2009]].<br />
<br />
==Project Rationale==<br />
<br />
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.<br />
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. <br />
This would help recreate more real world network scenarios where firewalls are ubiquitous.<br />
<br />
==Approach==<br />
<br />
===Design===<br />
<br />
The work will primarily be divided in two main parts:<br />
<br />
====Netfilter Framework====<br />
<br />
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.<br />
<br />
''1.This would have 5 hooks''<br />
o NF_INET_PRE_ROUTING<br />
o NF_INET_LOCAL_IN<br />
o NF_INET_FORWARD<br />
o NF_INET_LOCAL_OUT<br />
o NF_INET_POST_ROUTING<br />
<br />
''2.Callback chaining''<br />
<br />
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.<br />
<br />
''3.Connection tracking''<br />
<br />
To maintain the state of the connection making the node one that is stateful.<br />
<br />
====Network Address Translation====<br />
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).<br />
<br />
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.<br />
<br />
The source code for this model lives in the directory src/internet/model.<br />
<br />
The design of NAT for ns-3 is basically divided into two main categories: <br />
<br />
'''- 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.<br />
<br />
'''- 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.<br />
<br />
===Testing===<br />
<br />
For the tests of the Nat and Netfilter will focus on a base simulation would be used <br />
<br />
n1--n2--n3 <br />
<br />
where n2 is the nat device with n1 on the private network and n3 is out on the internet.<br />
Multiple aspects would be looked at while testing : <br />
<br />
- Appropriate routing of the packet<br />
<br />
- Packet filtering in place<br />
<br />
- Header fields in the packet updated as per netfilter and nat rules<br />
<br />
- Connection tracking maintained<br />
<br />
- Checksum computation accuracy<br />
<br />
==Usage==<br />
<br />
===Static Nat Example===<br />
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.<br />
<br />
The following are the steps of things to be done when converting a node to a NAT node:<br />
<br />
// obtain a node pointer "node"<br />
Ipv4NatHelper natHelper<br />
Ptr<Ipv4Nat> nat = natHelper.Install (node);<br />
<br />
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:<br />
<br />
nat->SetInside (1);<br />
nat->SetOutside (2);<br />
<br />
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:<br />
<br />
// specify local and global IP addresses<br />
Ipv4StaticNatRule rule (Ipv4Address ("192.168.1.1"), Ipv4Address ("203.82.48.100"));<br />
nat->AddStaticRule (rule);<br />
<br />
The following code will help printing the NAT rules to a file nat.rules from the stream:<br />
<br />
Ptr<OutputStreamWrapper> natStream = Create<OutputStreamWrapper> ("nat.rules", std::ios::out);<br />
nat->PrintTable (natStream);<br />
<br />
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:<br />
<br />
Ipv4StaticNatRule rule2 (Ipv4Address ("192.168.2.3"), 80, Ipv4Address ("10.1.3.4"), 8080, 0);<br />
nat->AddStaticRule (rule2);<br />
<br />
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).<br />
<br />
===Dynamic Nat Example===<br />
In order to configure the node to perform Dynamic Nat one would do the following:<br />
<br />
Follow the steps till setting the inside and outside interface as mentioned in the above example. <br />
<br />
The following code with set the address pool to which the dynamic nat translation would occur:<br />
<br />
nat->AddAddressPool (Ipv4Address ("192.168.1.5"), Ipv4Mask ("255.255.255.255"));<br />
<br />
The following code adds the port range to which the host would translate<br />
<br />
nat->AddPortPool (49153, 49163);<br />
<br />
The following rule would translate all the IP addresses in 192.168.1.0 network in a dynamic translation.<br />
<br />
Ipv4DynamicNatRule rule (Ipv4Address ("192.168.1.0"), Ipv4Mask ("255.255.255.0"));<br />
nat->AddDynamicRule (rule);<br />
<br />
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.</div>Vsindhujahttps://www.nsnam.org/mediawiki/index.php?title=GSOC2012NetworkAddressTranslation&diff=6953GSOC2012NetworkAddressTranslation2012-08-21T07:29:31Z<p>Vsindhuja: </p>
<hr />
<div>==Project Contact==<br />
<br />
* Student: [mailto:intutivestriker88@gmail.com V. Sindhuja]<br />
* Mentor: [mailto:tomhend@u.washington.edu Tom Henderson],[mailto:daniel.camara@inria.fr Daniel Camara]<br />
* 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.<br />
* Mid-Term: https://www.nsnam.org/wiki/index.php/GSOC2012NetworkAddressTranslationMidTermReview<br />
<br />
==Introduction==<br />
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.<br />
The specifics of the implementation will be updated on further progress.<br />
<br />
This project builds on the work previously done by Qasim Javed and Adrian Tam in [[GSOC2009NetworkAddressTranslation | 2009]].<br />
<br />
==Project Rationale==<br />
<br />
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.<br />
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. <br />
This would help recreate more real world network scenarios where firewalls are ubiquitous.<br />
<br />
==Approach==<br />
<br />
===Design===<br />
<br />
The work will primarily be divided in two main parts:<br />
<br />
====Netfilter Framework====<br />
<br />
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.<br />
<br />
''1.This would have 5 hooks''<br />
o NF_INET_PRE_ROUTING<br />
o NF_INET_LOCAL_IN<br />
o NF_INET_FORWARD<br />
o NF_INET_LOCAL_OUT<br />
o NF_INET_POST_ROUTING<br />
<br />
''2.Callback chaining''<br />
<br />
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.<br />
<br />
''3.Connection tracking''<br />
<br />
To maintain the state of the connection making the node one that is stateful.<br />
<br />
====Network Address Translation====<br />
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).<br />
<br />
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.<br />
<br />
The source code for this model lives in the directory src/internet/model.<br />
<br />
The design of NAT for ns-3 is basically divided into two main categories: <br />
<br />
'''- 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.<br />
<br />
'''- 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.<br />
<br />
===Testing===<br />
<br />
For the tests of the Nat and Netfilter will focus on a base simulation would be used <br />
<br />
n1--n2--n3 <br />
<br />
where n2 is the nat device with n1 on the private network and n3 is out on the internet.<br />
Multiple aspects would be looked at while testing : <br />
<br />
- Appropriate routing of the packet<br />
<br />
- Packet filtering in place<br />
<br />
- Header fields in the packet updated as per netfilter and nat rules<br />
<br />
- Connection tracking maintained<br />
<br />
- Checksum computation accuracy<br />
<br />
==Usage==<br />
<br />
===Static Nat Example===<br />
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.<br />
<br />
The following are the steps of things to be done when converting a node to a NAT node:<br />
<br />
// obtain a node pointer "node"<br />
Ipv4NatHelper natHelper<br />
Ptr<Ipv4Nat> nat = natHelper.Install (node);<br />
<br />
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:<br />
<br />
nat->SetInside (1);<br />
nat->SetOutside (2);<br />
<br />
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:<br />
<br />
// specify local and global IP addresses<br />
Ipv4StaticNatRule rule (Ipv4Address ("192.168.1.1"), Ipv4Address ("203.82.48.100"));<br />
nat->AddStaticRule (rule);<br />
<br />
The following code will help printing the NAT rules to a file nat.rules from the stream:<br />
<br />
Ptr<OutputStreamWrapper> natStream = Create<OutputStreamWrapper> ("nat.rules", std::ios::out);<br />
nat->PrintTable (natStream);<br />
<br />
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:<br />
<br />
Ipv4StaticNatRule rule2 (Ipv4Address ("192.168.2.3"), 80, Ipv4Address ("10.1.3.4"), 8080, 0);<br />
nat->AddStaticRule (rule2);<br />
<br />
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).<br />
<br />
===Dynamic Nat Example===<br />
In order to configure the node to perform Dynamic Nat one would do the following:<br />
<br />
Follow the steps till setting the inside and outside interface as mentioned in the above example. <br />
<br />
The following code with set the address pool to which the dynamic nat translation would occur:<br />
<br />
nat->AddAddressPool (Ipv4Address ("192.168.1.5"), Ipv4Mask ("255.255.255.255"));<br />
<br />
The following code adds the port range to which the host would translate<br />
<br />
nat->AddPortPool (49153, 49163);<br />
<br />
The following rule would translate all the IP addresses in 192.168.1.0 network in a dynamic translation.<br />
<br />
Ipv4DynamicNatRule rule (Ipv4Address ("192.168.1.0"), Ipv4Mask ("255.255.255.0"));<br />
nat->AddDynamicRule (rule);<br />
<br />
<br />
==Open Issue Tracker==<br />
<br />
* 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.<br />
* Need to provide patches to code review without white space changes<br />
* 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.</div>Vsindhujahttps://www.nsnam.org/mediawiki/index.php?title=GSOC2012NetworkAddressTranslation&diff=6952GSOC2012NetworkAddressTranslation2012-08-21T07:20:21Z<p>Vsindhuja: </p>
<hr />
<div>==Project Contact==<br />
<br />
* Student: [mailto:intutivestriker88@gmail.com V. Sindhuja]<br />
* Mentor: [mailto:tomhend@u.washington.edu Tom Henderson],[mailto:daniel.camara@inria.fr Daniel Camara]<br />
* 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.<br />
* Mid-Term: https://www.nsnam.org/wiki/index.php/GSOC2012NetworkAddressTranslationMidTermReview<br />
<br />
==Introduction==<br />
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.<br />
The specifics of the implementation will be updated on further progress.<br />
<br />
This project builds on the work previously done by Qasim Javed and Adrian Tam in [[GSOC2009NetworkAddressTranslation | 2009]].<br />
<br />
==Project Rationale==<br />
<br />
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.<br />
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. <br />
This would help recreate more real world network scenarios where firewalls are ubiquitous.<br />
<br />
==Approach==<br />
<br />
===Design===<br />
<br />
The work will primarily be divided in two main parts:<br />
<br />
====Netfilter Framework====<br />
<br />
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.<br />
<br />
''1.This would have 5 hooks''<br />
o NF_INET_PRE_ROUTING<br />
o NF_INET_LOCAL_IN<br />
o NF_INET_FORWARD<br />
o NF_INET_LOCAL_OUT<br />
o NF_INET_POST_ROUTING<br />
<br />
''2.Callback chaining''<br />
<br />
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.<br />
<br />
''3.Connection tracking''<br />
<br />
To maintain the state of the connection making the node one that is stateful.<br />
<br />
====Network Address Translation====<br />
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).<br />
<br />
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.<br />
<br />
The source code for this model lives in the directory src/internet/model.<br />
<br />
The design of NAT for ns-3 is basically divided into two main categories: <br />
<br />
'''- 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.<br />
<br />
'''- 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.<br />
<br />
===Testing===<br />
<br />
For the tests of the Nat and Netfilter will focus on a base simulation would be used <br />
<br />
n1--n2--n3 <br />
<br />
where n2 is the nat device with n1 on the private network and n3 is out on the internet.<br />
Multiple aspects would be looked at while testing : <br />
<br />
- Appropriate routing of the packet<br />
<br />
- Packet filtering in place<br />
<br />
- Header fields in the packet updated as per netfilter and nat rules<br />
<br />
- Connection tracking maintained<br />
<br />
- Checksum computation accuracy<br />
<br />
==Usage==<br />
<br />
===Static Nat Example===<br />
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.<br />
<br />
The following are the steps of things to be done when converting a node to a NAT node:<br />
<br />
// obtain a node pointer "node"<br />
Ipv4NatHelper natHelper<br />
Ptr<Ipv4Nat> nat = natHelper.Install (node);<br />
<br />
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:<br />
<br />
nat->SetInside (1);<br />
nat->SetOutside (2);<br />
<br />
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:<br />
<br />
// specify local and global IP addresses<br />
Ipv4StaticNatRule rule (Ipv4Address ("192.168.1.1"), Ipv4Address ("203.82.48.100"));<br />
nat->AddStaticRule (rule);<br />
<br />
The following code will help printing the NAT rules to a file nat.rules from the stream:<br />
<br />
Ptr<OutputStreamWrapper> natStream = Create<OutputStreamWrapper> ("nat.rules", std::ios::out);<br />
nat->PrintTable (natStream);<br />
<br />
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:<br />
<br />
Ipv4StaticNatRule rule2 (Ipv4Address ("192.168.2.3"), 80, Ipv4Address ("10.1.3.4"), 8080, 0);<br />
nat->AddStaticRule (rule2);<br />
<br />
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).<br />
<br />
==Open Issue Tracker==<br />
<br />
* 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.<br />
* Need to provide patches to code review without white space changes<br />
* 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.</div>Vsindhujahttps://www.nsnam.org/mediawiki/index.php?title=GSOC2012NetworkAddressTranslation&diff=6951GSOC2012NetworkAddressTranslation2012-08-21T07:17:05Z<p>Vsindhuja: </p>
<hr />
<div>==Project Contact==<br />
<br />
* Student: [mailto:intutivestriker88@gmail.com V. Sindhuja]<br />
* Mentor: [mailto:tomhend@u.washington.edu Tom Henderson],[mailto:daniel.camara@inria.fr Daniel Camara]<br />
* 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.<br />
* Mid-Term: https://www.nsnam.org/wiki/index.php/GSOC2012NetworkAddressTranslationMidTermReview<br />
<br />
==Introduction==<br />
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.<br />
The specifics of the implementation will be updated on further progress.<br />
<br />
This project builds on the work previously done by Qasim Javed and Adrian Tam in [[GSOC2009NetworkAddressTranslation | 2009]].<br />
<br />
==Project Rationale==<br />
<br />
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.<br />
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. <br />
This would help recreate more real world network scenarios where firewalls are ubiquitous.<br />
<br />
==Approach==<br />
<br />
===Design===<br />
<br />
The work will primarily be divided in two main parts:<br />
<br />
====Netfilter Framework====<br />
<br />
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.<br />
<br />
''1.This would have 5 hooks''<br />
o NF_INET_PRE_ROUTING<br />
o NF_INET_LOCAL_IN<br />
o NF_INET_FORWARD<br />
o NF_INET_LOCAL_OUT<br />
o NF_INET_POST_ROUTING<br />
<br />
''2.Callback chaining''<br />
<br />
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.<br />
<br />
''3.Connection tracking''<br />
<br />
To maintain the state of the connection making the node one that is stateful.<br />
<br />
====Network Address Translation====<br />
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).<br />
<br />
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.<br />
<br />
The source code for this model lives in the directory src/internet/model.<br />
<br />
The design of NAT for ns-3 is basically divided into two main categories: <br />
<br />
'''- 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.<br />
<br />
'''- 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.<br />
<br />
===Testing===<br />
<br />
For the tests of the Nat and Netfilter will focus on a base simulation would be used <br />
<br />
n1--n2--n3 <br />
<br />
where n2 is the nat device with n1 on the private network and n3 is out on the internet.<br />
Multiple aspects would be looked at while testing : <br />
<br />
- Appropriate routing of the packet<br />
<br />
- Packet filtering in place<br />
<br />
- Header fields in the packet updated as per netfilter and nat rules<br />
<br />
- Connection tracking maintained<br />
<br />
- Checksum computation accuracy<br />
<br />
==Open Issue Tracker==<br />
<br />
* 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.<br />
* Need to provide patches to code review without white space changes<br />
* 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.</div>Vsindhujahttps://www.nsnam.org/mediawiki/index.php?title=GSOC2012NetworkAddressTranslation&diff=6950GSOC2012NetworkAddressTranslation2012-08-21T07:16:12Z<p>Vsindhuja: </p>
<hr />
<div>==Project Contact==<br />
<br />
* Student: [mailto:intutivestriker88@gmail.com V. Sindhuja]<br />
* Mentor: [mailto:tomhend@u.washington.edu Tom Henderson],[mailto:daniel.camara@inria.fr Daniel Camara]<br />
* 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.<br />
* Mid-Term: https://www.nsnam.org/wiki/index.php/GSOC2012NetworkAddressTranslationMidTermReview<br />
<br />
==Introduction==<br />
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.<br />
The specifics of the implementation will be updated on further progress.<br />
<br />
This project builds on the work previously done by Qasim Javed and Adrian Tam in [[GSOC2009NetworkAddressTranslation | 2009]].<br />
<br />
==Project Rationale==<br />
<br />
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.<br />
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. <br />
This would help recreate more real world network scenarios where firewalls are ubiquitous.<br />
<br />
==Approach==<br />
<br />
===Design===<br />
<br />
The work will primarily be divided in two main parts:<br />
<br />
====Netfilter Framework====<br />
<br />
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.<br />
<br />
''1.This would have 5 hooks''<br />
o NF_INET_PRE_ROUTING<br />
o NF_INET_LOCAL_IN<br />
o NF_INET_FORWARD<br />
o NF_INET_LOCAL_OUT<br />
o NF_INET_POST_ROUTING<br />
<br />
''2.Callback chaining''<br />
<br />
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.<br />
<br />
''3.Connection tracking''<br />
<br />
To maintain the state of the connection making the node one that is stateful.<br />
<br />
====Network Address Translation====<br />
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).<br />
<br />
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.<br />
<br />
The source code for this model lives in the directory src/internet/model.<br />
<br />
The design of NAT for ns-3 is basically divided into two main categories: <br />
<br />
- 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.<br />
<br />
- 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.<br />
<br />
===Testing===<br />
<br />
For the tests of the Nat and Netfilter will focus on a base simulation would be used <br />
<br />
n1--n2--n3 <br />
<br />
where n2 is the nat device with n1 on the private network and n3 is out on the internet.<br />
Multiple aspects would be looked at while testing : <br />
<br />
- Appropriate routing of the packet<br />
<br />
- Packet filtering in place<br />
<br />
- Header fields in the packet updated as per netfilter and nat rules<br />
<br />
- Connection tracking maintained<br />
<br />
- Checksum computation accuracy<br />
<br />
==Open Issue Tracker==<br />
<br />
* 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.<br />
* Need to provide patches to code review without white space changes<br />
* 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.</div>Vsindhujahttps://www.nsnam.org/mediawiki/index.php?title=GSOC2012NetworkAddressTranslation&diff=6949GSOC2012NetworkAddressTranslation2012-08-21T07:12:22Z<p>Vsindhuja: </p>
<hr />
<div>==Project Contact==<br />
<br />
* Student: [mailto:intutivestriker88@gmail.com V. Sindhuja]<br />
* Mentor: [mailto:tomhend@u.washington.edu Tom Henderson],[mailto:daniel.camara@inria.fr Daniel Camara]<br />
* 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.<br />
* Mid-Term: https://www.nsnam.org/wiki/index.php/GSOC2012NetworkAddressTranslationMidTermReview<br />
<br />
==Introduction==<br />
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.<br />
The specifics of the implementation will be updated on further progress.<br />
<br />
This project builds on the work previously done by Qasim Javed and Adrian Tam in [[GSOC2009NetworkAddressTranslation | 2009]].<br />
<br />
==Project Rationale==<br />
<br />
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.<br />
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. <br />
This would help recreate more real world network scenarios where firewalls are ubiquitous.<br />
<br />
==Approach==<br />
<br />
===Design===<br />
<br />
The work will primarily be divided in two main parts:<br />
<br />
====Netfilter Framework====<br />
<br />
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.<br />
<br />
''1.This would have 5 hooks''<br />
o NF_INET_PRE_ROUTING<br />
o NF_INET_LOCAL_IN<br />
o NF_INET_FORWARD<br />
o NF_INET_LOCAL_OUT<br />
o NF_INET_POST_ROUTING<br />
<br />
''2.Callback chaining''<br />
<br />
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.<br />
<br />
''3.Connection tracking''<br />
<br />
To maintain the state of the connection making the node one that is stateful.<br />
<br />
====Network Address Translation====<br />
Network address translation (NAT) is a process of altering the <br />
source/destination IP address of a packet in order to make it routable over <br />
a network. This is usually applied when packets are passed from a private<br />
address realm to a public network.<br />
Network address translation is also used in IP address hiding where hosts <br />
can be on the address behind the NAT device and cannot be directly <br />
reached from an external network. NAT also comes with a number of variants <br />
in terms of what fieldd of the packet is translated through the NAT (e.g. <br />
port numbers) or the directions of the NAT (e.g. unidirectional vs <br />
bidirectional).<br />
<br />
While NAT is mainly deployed for operational purposes (managing IP address<br />
space), the inclusion of simulation models of NAT may be helpful to developers<br />
of peer-to-peer applications for ns-3 who wish to evaluate the NAT traversal<br />
aspects of the application.<br />
<br />
<br />
<br />
===Testing===<br />
<br />
For the tests of the Nat and Netfilter will focus on a base simulation would be used <br />
<br />
n1--n2--n3 <br />
<br />
where n2 is the nat device with n1 on the private network and n3 is out on the internet.<br />
Multiple aspects would be looked at while testing : <br />
<br />
- Appropriate routing of the packet<br />
<br />
- Packet filtering in place<br />
<br />
- Header fields in the packet updated as per netfilter and nat rules<br />
<br />
- Connection tracking maintained<br />
<br />
- Checksum computation accuracy<br />
<br />
==Open Issue Tracker==<br />
<br />
* 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.<br />
* Need to provide patches to code review without white space changes<br />
* 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.</div>Vsindhujahttps://www.nsnam.org/mediawiki/index.php?title=GSOC2012NetworkAddressTranslation&diff=6948GSOC2012NetworkAddressTranslation2012-08-21T07:11:27Z<p>Vsindhuja: </p>
<hr />
<div>==Project Contact==<br />
<br />
* Student: [mailto:intutivestriker88@gmail.com V. Sindhuja]<br />
* Mentor: [mailto:tomhend@u.washington.edu Tom Henderson],[mailto:daniel.camara@inria.fr Daniel Camara]<br />
* 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.<br />
* Mid-Term: https://www.nsnam.org/wiki/index.php/GSOC2012NetworkAddressTranslationMidTermReview<br />
<br />
==Introduction==<br />
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.<br />
The specifics of the implementation will be updated on further progress.<br />
<br />
This project builds on the work previously done by Qasim Javed and Adrian Tam in [[GSOC2009NetworkAddressTranslation | 2009]].<br />
<br />
==Project Rationale==<br />
<br />
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.<br />
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. <br />
This would help recreate more real world network scenarios where firewalls are ubiquitous.<br />
<br />
==Approach==<br />
<br />
===Design===<br />
<br />
The work will primarily be divided in two main parts:<br />
<br />
'''A.Building the Netfilter Framework '''<br />
<br />
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.<br />
<br />
''1.This would have 5 hooks''<br />
o NF_INET_PRE_ROUTING<br />
o NF_INET_LOCAL_IN<br />
o NF_INET_FORWARD<br />
o NF_INET_LOCAL_OUT<br />
o NF_INET_POST_ROUTING<br />
<br />
''2.Callback chaining''<br />
<br />
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.<br />
<br />
''3.Connection tracking''<br />
<br />
To maintain the state of the connection making the node one that is stateful.<br />
<br />
====Network Address Translation====<br />
Network address translation (NAT) is a process of altering the <br />
source/destination IP address of a packet in order to make it routable over <br />
a network. This is usually applied when packets are passed from a private<br />
address realm to a public network.<br />
Network address translation is also used in IP address hiding where hosts <br />
can be on the address behind the NAT device and cannot be directly <br />
reached from an external network. NAT also comes with a number of variants <br />
in terms of what fieldd of the packet is translated through the NAT (e.g. <br />
port numbers) or the directions of the NAT (e.g. unidirectional vs <br />
bidirectional).<br />
<br />
While NAT is mainly deployed for operational purposes (managing IP address<br />
space), the inclusion of simulation models of NAT may be helpful to developers<br />
of peer-to-peer applications for ns-3 who wish to evaluate the NAT traversal<br />
aspects of the application.<br />
<br />
<br />
<br />
===Testing===<br />
<br />
For the tests of the Nat and Netfilter will focus on a base simulation would be used <br />
<br />
n1--n2--n3 <br />
<br />
where n2 is the nat device with n1 on the private network and n3 is out on the internet.<br />
Multiple aspects would be looked at while testing : <br />
<br />
- Appropriate routing of the packet<br />
<br />
- Packet filtering in place<br />
<br />
- Header fields in the packet updated as per netfilter and nat rules<br />
<br />
- Connection tracking maintained<br />
<br />
- Checksum computation accuracy<br />
<br />
==Open Issue Tracker==<br />
<br />
* 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.<br />
* Need to provide patches to code review without white space changes<br />
* 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.</div>Vsindhujahttps://www.nsnam.org/mediawiki/index.php?title=GSOC2012NetworkAddressTranslation&diff=6947GSOC2012NetworkAddressTranslation2012-08-21T07:10:40Z<p>Vsindhuja: </p>
<hr />
<div>==Project Contact==<br />
<br />
* Student: [mailto:intutivestriker88@gmail.com V. Sindhuja]<br />
* Mentor: [mailto:tomhend@u.washington.edu Tom Henderson],[mailto:daniel.camara@inria.fr Daniel Camara]<br />
* 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.<br />
* Mid-Term: https://www.nsnam.org/wiki/index.php/GSOC2012NetworkAddressTranslationMidTermReview<br />
<br />
==Introduction==<br />
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.<br />
The specifics of the implementation will be updated on further progress.<br />
<br />
This project builds on the work previously done by Qasim Javed and Adrian Tam in [[GSOC2009NetworkAddressTranslation | 2009]].<br />
<br />
==Project Rationale==<br />
<br />
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.<br />
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. <br />
This would help recreate more real world network scenarios where firewalls are ubiquitous.<br />
<br />
==Approach==<br />
<br />
===Design===<br />
<br />
The work will primarily be divided in two main parts:<br />
<br />
'''A.Building the Netfilter Framework '''<br />
<br />
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.<br />
<br />
''1.This would have 5 hooks''<br />
o NF_INET_PRE_ROUTING<br />
o NF_INET_LOCAL_IN<br />
o NF_INET_FORWARD<br />
o NF_INET_LOCAL_OUT<br />
o NF_INET_POST_ROUTING<br />
<br />
''2.Callback chaining''<br />
<br />
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.<br />
<br />
''3.Connection tracking''<br />
<br />
To maintain the state of the connection making the node one that is stateful.<br />
<br />
===Network Address Translation===<br />
Network address translation (NAT) is a process of altering the <br />
source/destination IP address of a packet in order to make it routable over <br />
a network. This is usually applied when packets are passed from a private<br />
address realm to a public network.<br />
Network address translation is also used in IP address hiding where hosts <br />
can be on the address behind the NAT device and cannot be directly <br />
reached from an external network. NAT also comes with a number of variants <br />
in terms of what fieldd of the packet is translated through the NAT (e.g. <br />
port numbers) or the directions of the NAT (e.g. unidirectional vs <br />
bidirectional).<br />
<br />
While NAT is mainly deployed for operational purposes (managing IP address<br />
space), the inclusion of simulation models of NAT may be helpful to developers<br />
of peer-to-peer applications for ns-3 who wish to evaluate the NAT traversal<br />
aspects of the application.<br />
<br />
<br />
<br />
===Testing===<br />
<br />
For the tests of the Nat and Netfilter will focus on a base simulation would be used <br />
<br />
n1--n2--n3 <br />
<br />
where n2 is the nat device with n1 on the private network and n3 is out on the internet.<br />
Multiple aspects would be looked at while testing : <br />
<br />
- Appropriate routing of the packet<br />
<br />
- Packet filtering in place<br />
<br />
- Header fields in the packet updated as per netfilter and nat rules<br />
<br />
- Connection tracking maintained<br />
<br />
- Checksum computation accuracy<br />
<br />
==Open Issue Tracker==<br />
<br />
* 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.<br />
* Need to provide patches to code review without white space changes<br />
* 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.</div>Vsindhujahttps://www.nsnam.org/mediawiki/index.php?title=GSOC2012NetworkAddressTranslation&diff=6855GSOC2012NetworkAddressTranslation2012-07-10T15:49:57Z<p>Vsindhuja: </p>
<hr />
<div>==Project Contact==<br />
<br />
* Student: [mailto:intutivestriker88@gmail.com V. Sindhuja]<br />
* Mentor: [mailto:tomhend@u.washington.edu Tom Henderson],[mailto:daniel.camara@inria.fr Daniel Camara]<br />
* 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.<br />
* Mid-Term: https://www.nsnam.org/wiki/index.php/GSOC2012NetworkAddressTranslationMidTermReview<br />
<br />
==Introduction==<br />
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.<br />
The specifics of the implementation will be updated on further progress.<br />
<br />
This project builds on the work previously done by Qasim Javed and Adrian Tam in [[GSOC2009NetworkAddressTranslation | 2009]].<br />
<br />
==Project Rationale==<br />
<br />
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.<br />
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. <br />
This would help recreate more real world network scenarios where firewalls are ubiquitous.<br />
<br />
==Approach==<br />
<br />
===Design===<br />
<br />
The work will primarily be divided in two main parts:<br />
<br />
'''A.Building the Netfilter Framework '''<br />
<br />
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.<br />
<br />
''1.This would have 5 hooks''<br />
o NF_INET_PRE_ROUTING<br />
o NF_INET_LOCAL_IN<br />
o NF_INET_FORWARD<br />
o NF_INET_LOCAL_OUT<br />
o NF_INET_POST_ROUTING<br />
<br />
''2.Callback chaining''<br />
<br />
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.<br />
<br />
''3.Connection tracking''<br />
<br />
To maintain the state of the connection making the node one that is stateful.<br />
<br />
'''B.Implementing the main NAT models'''<br />
<br />
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.<br />
<br />
''Static one-to-one NAT''<br />
<br />
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.<br />
<br />
''Regular Dynamic NAT''<br />
<br />
This is the NAT where all the traffic is translated to one IP address and multiple ports(Port address translation).<br />
<br />
''User Specific API''<br />
<br />
At a very generic level of explaining this I start with when nat is enabled on a node. The user would invoke something like :<br />
<br />
Nat_Install(node,lan-interface,wan-interface) <br />
<br />
This would clearly set the interfaces of the node participating in the NATting.<br />
<br />
Once this is done the user would configure the <br />
<br />
Static one-to-one:<br />
<br />
static_nat(lan-ip,wan-ip);<br />
<br />
static_nat(lan-ip,wan-ip,port-range) //in the case of number of ports<br />
<br />
Dynamic NAPT:<br />
<br />
dynamic_nat(lan-ip network with mask,wan-ip);<br />
<br />
A more NS-3 specific interface definition will be updated in the course of this project.<br />
<br />
<br />
===Testing===<br />
<br />
For the tests of the Nat and Netfilter will focus on a base simulation would be used <br />
<br />
n1--n2--n3 <br />
<br />
where n2 is the nat device with n1 on the private network and n3 is out on the internet.<br />
Multiple aspects would be looked at while testing : <br />
<br />
- Appropriate routing of the packet<br />
<br />
- Packet filtering in place<br />
<br />
- Header fields in the packet updated as per netfilter and nat rules<br />
<br />
- Connection tracking maintained<br />
<br />
- Checksum computation accuracy<br />
<br />
==Plan==<br />
<br />
·Week 1: (22/05-29/05) Adapt the existing Netfilter code to the current NS3<br />
<br />
·Week 2: (30/05-06/06) Test the adaptation for the Netfilter code to current NS3<br />
<br />
·Week 3: (07/06-14/06) Static one-to-one Design and Implementation<br />
<br />
·Week 4: (15/06-22/06) Static one-to-one Design and Implementation<br />
<br />
·Week 5: (23/06-30/06) Test the Static one-to-one Implementations.<br />
<br />
·Week 6: (01/07-08/07) Dynamic Port-Translating NAT Design and Implementation<br />
<br />
·09/07- Midterm evaluation submission<br />
<br />
·Week 7: (10/07-17/07) Dynamic Port-Translating NAT Design and Implementation<br />
<br />
·Week 8: (18/07-25/07) Testing the Dynamic Port-Translating NAT implementation.<br />
<br />
·Week 9: (26/07-02/08) Test and Work on integration of the NAT Models<br />
<br />
·Week 10: (03/08-10/08)Test and Work on integration of the NAT Models <br />
<br />
·Aug 13 Suggested Pencils Down Date.<br />
<br />
·11/08-19/08: Documentation and Integration of the project<br />
<br />
·20/08 - Final Evaluation and Submission.<br />
<br />
==Open Issue Tracker==<br />
<br />
* 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.<br />
* Need to provide patches to code review without white space changes<br />
* 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.</div>Vsindhujahttps://www.nsnam.org/mediawiki/index.php?title=GSOC2012NetworkAddressTranslationMidTermReview&diff=6854GSOC2012NetworkAddressTranslationMidTermReview2012-07-10T15:49:13Z<p>Vsindhuja: </p>
<hr />
<div>==Introduction==<br />
This project aims to implement IPv4 NAT support for the native IPv4 stack in ns-3. <br />
The NAT requires two prerequisite features: Netfilter and Conntrack. his project builds/extends work previously done by Qasim Javed (mentored by Adrian Tam) in [[GSOC2009NetworkAddressTranslation | 2009]].<br />
<br />
==Current Status==<br />
<br />
===Netfilter===<br />
1) IPv4 Netfilter support is mostly done, based on a port and update of Qasim's original code. New features include tests (still to be completed), new examples, and documentation for the model library. However, the implementation revealed a soft spot in the IPv4L3Protocol implementation that must be resolved; namely, netfilter expects to operate (possibly mangle) complete IP packets, but the IPv4L3Protocol code operates by removing the IP header at an early stage in the packet processing, and adding it in a late stage of <br />
processing. Therefore, any mangle operations on the packet header must be preserved in this model. The current implementation supports a mangle operation in the PRE_ROUTING and POST_ROUTING hooks only (filters can be supported at the other states at present, but not mangle). Support at the additional hook points for mangle needs some refactoring.<br />
The open issues (complete tests, and mangle at other hook points) is scheduled for 18 July.<br />
<br />
===Conntrack===<br />
2) The conntrack module is scoped and ported from Qasim's repository, but untested. An additional aspect is that the user APIs to inspect the state has not been discussed/resolved (e.g. a conntrack-tools-likeinterface, or printouts similar to reading /proc/net/conttrack). We plan to support the necessary features for basic IPv4 NAT; protocol helpers for application-level expectations (e.g. FTP) are out of scope, and dealing with IPv4 fragmentation is out of scope.<br />
<br />
The current code for this component is available at:<br />
http://code.nsnam.org/vsindhuja/ns-3-dev-netfilter/src/internet/model:<br />
- icmpv4-conntrack-l4-protocol.{cc,h}<br />
- ip-conntrack-info.{cc,h}<br />
- ipv4-conntrack-l3-protocol.{cc,h}<br />
- netfilter-conntrack-l3-ipv4.h<br />
- netfilter-conntrack-l3-protocol.h<br />
- netfilter-conntrack-l4-protocol.h<br />
- netfilter-conntrack-tuple.{cc,h}<br />
- tcp-conntrack-l4-protocol.{cc,h}<br />
- udp-conntrack-l4-protocol.{cc,h}c <br />
<br />
The open issues (complete tests, and mangle at other hook points) is scheduled for 1 August.<br />
<br />
===NAT===<br />
3) The NAT code has not really been initiated; some aspects of it exist in the above repository but are stubbed out, to focus on the netfilter and conntrack issues. <br />
<br />
==Future Goals==<br />
<br />
1) Implement the ability to mangle the packets. The next focus would be to get on working with altering the header of the packets and proceed withpassing them through the nodes to see if the changes made are effective. This would be the predecessor to the actual implementation of NAT as that would require packet mangling as a feature.<br />
<br />
2) Conntrack must be modeled in a way that is not very protocol dependent. Decide on a more robust way to deal with packets that do not have the conntrack helpers in place. Examples and tests in place for conn track. The examples for conn track are envisioned to be able to basically dump the connection tables over the period of connection between nodes.<br />
<br />
3) Another important part to look into would be to get packet filtering also working in place. This would provide a solid filtering operation for the NS-3 framework.<br />
<br />
4)NAT modeling must be evaluated on the basis of the existing Netfilter and Conntrack code and taking into consideration their limitations as well.</div>Vsindhujahttps://www.nsnam.org/mediawiki/index.php?title=GSOC2012NetworkAddressTranslationMidTermReview&diff=6853GSOC2012NetworkAddressTranslationMidTermReview2012-07-10T15:44:35Z<p>Vsindhuja: </p>
<hr />
<div>==Introduction==<br />
This project aims to implement IPv4 NAT support for the native IPv4 stack in ns-3. <br />
The NAT requires two prerequisite features: Netfilter and Conntrack. his project builds/extends work previously done by Qasim Javed (mentored by Adrian Tam) in [[GSOC2009NetworkAddressTranslation | 2009]].<br />
<br />
==Current Status==<br />
<br />
===Netfilter===<br />
1) IPv4 Netfilter support is mostly done, based on a port and update of Qasim's original code. New features include tests (still to be completed), new examples, and documentation for the model library. However, the implementation revealed a soft spot in the IPv4L3Protocol implementation that must be resolved; namely, netfilter expects to operate (possibly mangle) complete IP packets, but the IPv4L3Protocol code operates by removing the IP header at an early stage in the packet processing, and adding it in a late stage of <br />
processing. Therefore, any mangle operations on the packet header must be preserved in this model. The current implementation supports a mangle operation in the PRE_ROUTING and POST_ROUTING hooks only (filters can be supported at the other states at present, but not mangle). Support at the additional hook points for mangle needs some refactoring.<br />
The open issues (complete tests, and mangle at other hook points) is scheduled for 18 July.<br />
<br />
===Conntrack===<br />
2) The conntrack module is scoped and ported from Qasim's repository, but untested. An additional aspect is that the user APIs to inspect the state has not been discussed/resolved (e.g. a conntrack-tools-likeinterface, or printouts similar to reading /proc/net/conttrack). We plan to support the necessary features for basic IPv4 NAT; protocol helpers for application-level expectations (e.g. FTP) are out of scope, and dealing with IPv4 fragmentation is out of scope.<br />
<br />
The current code for this component is available at:<br />
http://code.nsnam.org/vsindhuja/ns-3-dev-netfilter/src/internet/model:<br />
- icmpv4-conntrack-l4-protocol.{cc,h}<br />
- ip-conntrack-info.{cc,h}<br />
- ipv4-conntrack-l3-protocol.{cc,h}<br />
- netfilter-conntrack-l3-ipv4.h<br />
- netfilter-conntrack-l3-protocol.h<br />
- netfilter-conntrack-l4-protocol.h<br />
- netfilter-conntrack-tuple.{cc,h}<br />
- tcp-conntrack-l4-protocol.{cc,h}<br />
- udp-conntrack-l4-protocol.{cc,h}c <br />
<br />
The open issues (complete tests, and mangle at other hook points) is scheduled for 1 August.<br />
<br />
===NAT===<br />
3) The NAT code has not really been initiated; some aspects of it exist in the above repository but are stubbed out, to focus on the netfilter and conntrack issues. <br />
<br />
==Future Goals==<br />
<br />
1) The first focus would be to work on packet mangling. To design callbacks that would work on changing certain fields on the header. Then observing if the packets pass through successfully.</div>Vsindhujahttps://www.nsnam.org/mediawiki/index.php?title=GSOC2012NetworkAddressTranslationMidTermReview&diff=6852GSOC2012NetworkAddressTranslationMidTermReview2012-07-10T15:12:10Z<p>Vsindhuja: Created page with "==Introduction== This project aims to implement IPv4 NAT support for the native IPv4 stack in ns-3. The NAT requires two prerequisite features: Netfilter and Conntrack. his pr..."</p>
<hr />
<div>==Introduction==<br />
This project aims to implement IPv4 NAT support for the native IPv4 stack in ns-3. <br />
The NAT requires two prerequisite features: Netfilter and Conntrack. his project builds/extends work previously done by Qasim Javed (mentored by Adrian Tam) in [[GSOC2009NetworkAddressTranslation | 2009]].<br />
<br />
==Current Status==<br />
<br />
1) IPv4 Netfilter support is mostly done, based on a port and update of Qasim's original code. New features include tests (still to be completed), new examples, and documentation for the model library. However, the implementation revealed a soft spot in the IPv4L3Protocol implementation that must be resolved; namely, netfilter expects to operate (possibly mangle) complete IP packets, but the IPv4L3Protocol code operates by removing the IP header at an early stage in the packet processing, and adding it in a late stage of <br />
processing. Therefore, any mangle operations on the packet header must be preserved in this model. The current implementation supports a mangle operation in the PRE_ROUTING and POST_ROUTING hooks only (filters can be supported at the other states at present, but not mangle). Support at the additional hook points for mangle needs some refactoring.<br />
The open issues (complete tests, and mangle at other hook points) is scheduled for 18 July.<br />
<br />
2) The conntrack module is scoped and ported from Qasim's repository, but untested. An additional aspect is that the user APIs to inspect the state has not been discussed/resolved (e.g. a conntrack-tools-likeinterface, or printouts similar to reading /proc/net/conttrack). We plan to support the necessary features for basic IPv4 NAT; protocol helpers for application-level expectations (e.g. FTP) are out of scope, and dealing with IPv4 fragmentation is out of scope.<br />
<br />
The current code for this component is available at:<br />
http://code.nsnam.org/vsindhuja/ns-3-dev-netfilter/src/internet/model:<br />
- icmpv4-conntrack-l4-protocol.{cc,h}<br />
- ip-conntrack-info.{cc,h}<br />
- ipv4-conntrack-l3-protocol.{cc,h}<br />
- netfilter-conntrack-l3-ipv4.h<br />
- netfilter-conntrack-l3-protocol.h<br />
- netfilter-conntrack-l4-protocol.h<br />
- netfilter-conntrack-tuple.{cc,h}<br />
- tcp-conntrack-l4-protocol.{cc,h}<br />
- udp-conntrack-l4-protocol.{cc,h}c <br />
<br />
The open issues (complete tests, and mangle at other hook points) is scheduled for 1 August.<br />
<br />
3) The NAT code has not really been initiated; some aspects of it exist in the above repository but are stubbed out, to focus on the netfilter and conntrack issues. <br />
<br />
==Future Goals==<br />
<br />
1) The first focus would be to work on packet mangling. To design callbacks that would work on changing certain fields on the header. Then observing if the packets pass through successfully.</div>Vsindhujahttps://www.nsnam.org/mediawiki/index.php?title=GSOC2012NetworkAddressTranslation&diff=6816GSOC2012NetworkAddressTranslation2012-06-15T15:20:48Z<p>Vsindhuja: </p>
<hr />
<div>==Project Contact==<br />
<br />
* Student: [mailto:intutivestriker88@gmail.com V. Sindhuja]<br />
* Mentor: [mailto:tomhend@u.washington.edu Tom Henderson],[mailto:daniel.camara@inria.fr Daniel Camara]<br />
* 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.<br />
<br />
==Introduction==<br />
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.<br />
The specifics of the implementation will be updated on further progress.<br />
<br />
This project builds on the work previously done by Qasim Javed and Adrian Tam in [[GSOC2009NetworkAddressTranslation | 2009]].<br />
<br />
==Project Rationale==<br />
<br />
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.<br />
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. <br />
This would help recreate more real world network scenarios where firewalls are ubiquitous.<br />
<br />
==Approach==<br />
<br />
===Design===<br />
<br />
The work will primarily be divided in two main parts:<br />
<br />
'''A.Building the Netfilter Framework '''<br />
<br />
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.<br />
<br />
''1.This would have 5 hooks''<br />
o NF_INET_PRE_ROUTING<br />
o NF_INET_LOCAL_IN<br />
o NF_INET_FORWARD<br />
o NF_INET_LOCAL_OUT<br />
o NF_INET_POST_ROUTING<br />
<br />
''2.Callback chaining''<br />
<br />
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.<br />
<br />
''3.Connection tracking''<br />
<br />
To maintain the state of the connection making the node one that is stateful.<br />
<br />
'''B.Implementing the main NAT models'''<br />
<br />
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.<br />
<br />
''Static one-to-one NAT''<br />
<br />
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.<br />
<br />
''Regular Dynamic NAT''<br />
<br />
This is the NAT where all the traffic is translated to one IP address and multiple ports(Port address translation).<br />
<br />
''User Specific API''<br />
<br />
At a very generic level of explaining this I start with when nat is enabled on a node. The user would invoke something like :<br />
<br />
Nat_Install(node,lan-interface,wan-interface) <br />
<br />
This would clearly set the interfaces of the node participating in the NATting.<br />
<br />
Once this is done the user would configure the <br />
<br />
Static one-to-one:<br />
<br />
static_nat(lan-ip,wan-ip);<br />
<br />
static_nat(lan-ip,wan-ip,port-range) //in the case of number of ports<br />
<br />
Dynamic NAPT:<br />
<br />
dynamic_nat(lan-ip network with mask,wan-ip);<br />
<br />
A more NS-3 specific interface definition will be updated in the course of this project.<br />
<br />
<br />
===Testing===<br />
<br />
For the tests of the Nat and Netfilter will focus on a base simulation would be used <br />
<br />
n1--n2--n3 <br />
<br />
where n2 is the nat device with n1 on the private network and n3 is out on the internet.<br />
Multiple aspects would be looked at while testing : <br />
<br />
- Appropriate routing of the packet<br />
<br />
- Packet filtering in place<br />
<br />
- Header fields in the packet updated as per netfilter and nat rules<br />
<br />
- Connection tracking maintained<br />
<br />
- Checksum computation accuracy<br />
<br />
==Plan==<br />
<br />
·Week 1: (22/05-29/05) Adapt the existing Netfilter code to the current NS3<br />
<br />
·Week 2: (30/05-06/06) Test the adaptation for the Netfilter code to current NS3<br />
<br />
·Week 3: (07/06-14/06) Static one-to-one Design and Implementation<br />
<br />
·Week 4: (15/06-22/06) Static one-to-one Design and Implementation<br />
<br />
·Week 5: (23/06-30/06) Test the Static one-to-one Implementations.<br />
<br />
·Week 6: (01/07-08/07) Dynamic Port-Translating NAT Design and Implementation<br />
<br />
·09/07- Midterm evaluation submission<br />
<br />
·Week 7: (10/07-17/07) Dynamic Port-Translating NAT Design and Implementation<br />
<br />
·Week 8: (18/07-25/07) Testing the Dynamic Port-Translating NAT implementation.<br />
<br />
·Week 9: (26/07-02/08) Test and Work on integration of the NAT Models<br />
<br />
·Week 10: (03/08-10/08)Test and Work on integration of the NAT Models <br />
<br />
·Aug 13 Suggested Pencils Down Date.<br />
<br />
·11/08-19/08: Documentation and Integration of the project<br />
<br />
·20/08 - Final Evaluation and Submission.<br />
<br />
==Open Issue Tracker==</div>Vsindhujahttps://www.nsnam.org/mediawiki/index.php?title=GSOC2012NetworkAddressTranslation&diff=6815GSOC2012NetworkAddressTranslation2012-06-15T15:20:23Z<p>Vsindhuja: /* Project Contact */</p>
<hr />
<div>==Project Contact==<br />
<br />
* Student: [mailto:intutivestriker88@gmail.com V. Sindhuja]<br />
* Mentor: [mailto:tomhend@u.washington.edu Tom Henderson],[mailto:daniel.camara@inria.fr Daniel Camara]<br />
* 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.<br />
<br />
==Introduction==<br />
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.<br />
The specifics of the implementation will be updated on further progress.<br />
<br />
This project builds on the work previously done by Qasim Javed and Adrian Tam in [[GSOC2009NetworkAddressTranslation | 2009]].<br />
<br />
==Project Rationale==<br />
<br />
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.<br />
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. <br />
This would help recreate more real world network scenarios where firewalls are ubiquitous.<br />
<br />
==Approach==<br />
<br />
===Design===<br />
<br />
The work will primarily be divided in two main parts:<br />
<br />
'''A.Building the Netfilter Framework '''<br />
<br />
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.<br />
<br />
''1.This would have 5 hooks''<br />
o NF_INET_PRE_ROUTING<br />
o NF_INET_LOCAL_IN<br />
o NF_INET_FORWARD<br />
o NF_INET_LOCAL_OUT<br />
o NF_INET_POST_ROUTING<br />
<br />
''2.Callback chaining''<br />
<br />
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.<br />
<br />
''3.Connection tracking''<br />
<br />
To maintain the state of the connection making the node one that is stateful.<br />
<br />
'''B.Implementing the main NAT models'''<br />
<br />
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.<br />
<br />
''Static one-to-one NAT''<br />
<br />
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.<br />
<br />
''Regular Dynamic NAT''<br />
<br />
This is the NAT where all the traffic is translated to one IP address and multiple ports(Port address translation).<br />
<br />
''User Specific API''<br />
<br />
At a very generic level of explaining this I start with when nat is enabled on a node. The user would invoke something like :<br />
<br />
Nat_Install(node,lan-interface,wan-interface) <br />
<br />
This would clearly set the interfaces of the node participating in the NATting.<br />
<br />
Once this is done the user would configure the <br />
<br />
Static one-to-one:<br />
<br />
static_nat(lan-ip,wan-ip);<br />
<br />
static_nat(lan-ip,wan-ip,port-range) //in the case of number of ports<br />
<br />
Dynamic NAPT:<br />
<br />
dynamic_nat(lan-ip network with mask,wan-ip);<br />
<br />
A more NS-3 specific interface definition will be updated in the course of this project.<br />
<br />
<br />
===Testing===<br />
<br />
For the tests of the Nat and Netfilter will focus on a base simulation would be used <br />
<br />
n1--n2--n3 <br />
<br />
where n2 is the nat device with n1 on the private network and n3 is out on the internet.<br />
Multiple aspects would be looked at while testing : <br />
<br />
- Appropriate routing of the packet<br />
<br />
- Packet filtering in place<br />
<br />
- Header fields in the packet updated as per netfilter and nat rules<br />
<br />
- Connection tracking maintained<br />
<br />
- Checksum computation accuracy<br />
<br />
==Plan==<br />
<br />
·Week 1: (22/05-29/05) Adapt the existing Netfilter code to the current NS3<br />
<br />
·Week 2: (30/05-06/06) Test the adaptation for the Netfilter code to current NS3<br />
<br />
·Week 3: (07/06-14/06) Static one-to-one Design and Implementation<br />
<br />
·Week 4: (15/06-22/06) Static one-to-one Design and Implementation<br />
<br />
·Week 5: (23/06-30/06) Test the Static one-to-one Implementations.<br />
<br />
·Week 6: (01/07-08/07) Dynamic Port-Translating NAT Design and Implementation<br />
<br />
·09/07- Midterm evaluation submission<br />
<br />
·Week 7: (10/07-17/07) Dynamic Port-Translating NAT Design and Implementation<br />
<br />
·Week 8: (18/07-25/07) Testing the Dynamic Port-Translating NAT implementation.<br />
<br />
·Week 9: (26/07-02/08) Test and Work on integration of the NAT Models<br />
<br />
·Week 10: (03/08-10/08)Test and Work on integration of the NAT Models <br />
<br />
·Aug 13 Suggested Pencils Down Date.<br />
<br />
·11/08-19/08: Documentation and Integration of the project<br />
<br />
·20/08 - Final Evaluation and Submission.</div>Vsindhujahttps://www.nsnam.org/mediawiki/index.php?title=GSOC2012NetworkAddressTranslation&diff=6814GSOC2012NetworkAddressTranslation2012-06-15T15:19:00Z<p>Vsindhuja: /* Project Contact */</p>
<hr />
<div>==Project Contact==<br />
<br />
* Student: [mailto:intutivestriker88@gmail.com V. Sindhuja]<br />
* Mentor: [mailto:tomhend@u.washington.edu Tom Henderson],[mailto: daniel.camara@inria.fr Daniel Camara]<br />
* 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.<br />
<br />
==Introduction==<br />
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.<br />
The specifics of the implementation will be updated on further progress.<br />
<br />
This project builds on the work previously done by Qasim Javed and Adrian Tam in [[GSOC2009NetworkAddressTranslation | 2009]].<br />
<br />
==Project Rationale==<br />
<br />
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.<br />
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. <br />
This would help recreate more real world network scenarios where firewalls are ubiquitous.<br />
<br />
==Approach==<br />
<br />
===Design===<br />
<br />
The work will primarily be divided in two main parts:<br />
<br />
'''A.Building the Netfilter Framework '''<br />
<br />
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.<br />
<br />
''1.This would have 5 hooks''<br />
o NF_INET_PRE_ROUTING<br />
o NF_INET_LOCAL_IN<br />
o NF_INET_FORWARD<br />
o NF_INET_LOCAL_OUT<br />
o NF_INET_POST_ROUTING<br />
<br />
''2.Callback chaining''<br />
<br />
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.<br />
<br />
''3.Connection tracking''<br />
<br />
To maintain the state of the connection making the node one that is stateful.<br />
<br />
'''B.Implementing the main NAT models'''<br />
<br />
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.<br />
<br />
''Static one-to-one NAT''<br />
<br />
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.<br />
<br />
''Regular Dynamic NAT''<br />
<br />
This is the NAT where all the traffic is translated to one IP address and multiple ports(Port address translation).<br />
<br />
''User Specific API''<br />
<br />
At a very generic level of explaining this I start with when nat is enabled on a node. The user would invoke something like :<br />
<br />
Nat_Install(node,lan-interface,wan-interface) <br />
<br />
This would clearly set the interfaces of the node participating in the NATting.<br />
<br />
Once this is done the user would configure the <br />
<br />
Static one-to-one:<br />
<br />
static_nat(lan-ip,wan-ip);<br />
<br />
static_nat(lan-ip,wan-ip,port-range) //in the case of number of ports<br />
<br />
Dynamic NAPT:<br />
<br />
dynamic_nat(lan-ip network with mask,wan-ip);<br />
<br />
A more NS-3 specific interface definition will be updated in the course of this project.<br />
<br />
<br />
===Testing===<br />
<br />
For the tests of the Nat and Netfilter will focus on a base simulation would be used <br />
<br />
n1--n2--n3 <br />
<br />
where n2 is the nat device with n1 on the private network and n3 is out on the internet.<br />
Multiple aspects would be looked at while testing : <br />
<br />
- Appropriate routing of the packet<br />
<br />
- Packet filtering in place<br />
<br />
- Header fields in the packet updated as per netfilter and nat rules<br />
<br />
- Connection tracking maintained<br />
<br />
- Checksum computation accuracy<br />
<br />
==Plan==<br />
<br />
·Week 1: (22/05-29/05) Adapt the existing Netfilter code to the current NS3<br />
<br />
·Week 2: (30/05-06/06) Test the adaptation for the Netfilter code to current NS3<br />
<br />
·Week 3: (07/06-14/06) Static one-to-one Design and Implementation<br />
<br />
·Week 4: (15/06-22/06) Static one-to-one Design and Implementation<br />
<br />
·Week 5: (23/06-30/06) Test the Static one-to-one Implementations.<br />
<br />
·Week 6: (01/07-08/07) Dynamic Port-Translating NAT Design and Implementation<br />
<br />
·09/07- Midterm evaluation submission<br />
<br />
·Week 7: (10/07-17/07) Dynamic Port-Translating NAT Design and Implementation<br />
<br />
·Week 8: (18/07-25/07) Testing the Dynamic Port-Translating NAT implementation.<br />
<br />
·Week 9: (26/07-02/08) Test and Work on integration of the NAT Models<br />
<br />
·Week 10: (03/08-10/08)Test and Work on integration of the NAT Models <br />
<br />
·Aug 13 Suggested Pencils Down Date.<br />
<br />
·11/08-19/08: Documentation and Integration of the project<br />
<br />
·20/08 - Final Evaluation and Submission.</div>Vsindhujahttps://www.nsnam.org/mediawiki/index.php?title=GSOC2012NetworkAddressTranslation&diff=6813GSOC2012NetworkAddressTranslation2012-06-15T15:18:27Z<p>Vsindhuja: /* Project Contact */</p>
<hr />
<div>==Project Contact==<br />
<br />
* Student: [mailto:intutivestriker88@gmail.com V. Sindhuja]<br />
* Mentor: [mailto:tomhend@u.washington.edu Tom Henderson], [mailto: daniel.camara@inria.fr Daniel Camara]<br />
* 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.<br />
<br />
==Introduction==<br />
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.<br />
The specifics of the implementation will be updated on further progress.<br />
<br />
This project builds on the work previously done by Qasim Javed and Adrian Tam in [[GSOC2009NetworkAddressTranslation | 2009]].<br />
<br />
==Project Rationale==<br />
<br />
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.<br />
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. <br />
This would help recreate more real world network scenarios where firewalls are ubiquitous.<br />
<br />
==Approach==<br />
<br />
===Design===<br />
<br />
The work will primarily be divided in two main parts:<br />
<br />
'''A.Building the Netfilter Framework '''<br />
<br />
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.<br />
<br />
''1.This would have 5 hooks''<br />
o NF_INET_PRE_ROUTING<br />
o NF_INET_LOCAL_IN<br />
o NF_INET_FORWARD<br />
o NF_INET_LOCAL_OUT<br />
o NF_INET_POST_ROUTING<br />
<br />
''2.Callback chaining''<br />
<br />
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.<br />
<br />
''3.Connection tracking''<br />
<br />
To maintain the state of the connection making the node one that is stateful.<br />
<br />
'''B.Implementing the main NAT models'''<br />
<br />
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.<br />
<br />
''Static one-to-one NAT''<br />
<br />
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.<br />
<br />
''Regular Dynamic NAT''<br />
<br />
This is the NAT where all the traffic is translated to one IP address and multiple ports(Port address translation).<br />
<br />
''User Specific API''<br />
<br />
At a very generic level of explaining this I start with when nat is enabled on a node. The user would invoke something like :<br />
<br />
Nat_Install(node,lan-interface,wan-interface) <br />
<br />
This would clearly set the interfaces of the node participating in the NATting.<br />
<br />
Once this is done the user would configure the <br />
<br />
Static one-to-one:<br />
<br />
static_nat(lan-ip,wan-ip);<br />
<br />
static_nat(lan-ip,wan-ip,port-range) //in the case of number of ports<br />
<br />
Dynamic NAPT:<br />
<br />
dynamic_nat(lan-ip network with mask,wan-ip);<br />
<br />
A more NS-3 specific interface definition will be updated in the course of this project.<br />
<br />
<br />
===Testing===<br />
<br />
For the tests of the Nat and Netfilter will focus on a base simulation would be used <br />
<br />
n1--n2--n3 <br />
<br />
where n2 is the nat device with n1 on the private network and n3 is out on the internet.<br />
Multiple aspects would be looked at while testing : <br />
<br />
- Appropriate routing of the packet<br />
<br />
- Packet filtering in place<br />
<br />
- Header fields in the packet updated as per netfilter and nat rules<br />
<br />
- Connection tracking maintained<br />
<br />
- Checksum computation accuracy<br />
<br />
==Plan==<br />
<br />
·Week 1: (22/05-29/05) Adapt the existing Netfilter code to the current NS3<br />
<br />
·Week 2: (30/05-06/06) Test the adaptation for the Netfilter code to current NS3<br />
<br />
·Week 3: (07/06-14/06) Static one-to-one Design and Implementation<br />
<br />
·Week 4: (15/06-22/06) Static one-to-one Design and Implementation<br />
<br />
·Week 5: (23/06-30/06) Test the Static one-to-one Implementations.<br />
<br />
·Week 6: (01/07-08/07) Dynamic Port-Translating NAT Design and Implementation<br />
<br />
·09/07- Midterm evaluation submission<br />
<br />
·Week 7: (10/07-17/07) Dynamic Port-Translating NAT Design and Implementation<br />
<br />
·Week 8: (18/07-25/07) Testing the Dynamic Port-Translating NAT implementation.<br />
<br />
·Week 9: (26/07-02/08) Test and Work on integration of the NAT Models<br />
<br />
·Week 10: (03/08-10/08)Test and Work on integration of the NAT Models <br />
<br />
·Aug 13 Suggested Pencils Down Date.<br />
<br />
·11/08-19/08: Documentation and Integration of the project<br />
<br />
·20/08 - Final Evaluation and Submission.</div>Vsindhujahttps://www.nsnam.org/mediawiki/index.php?title=GSOC2012AcceptedProjects&diff=6801GSOC2012AcceptedProjects2012-05-25T08:14:05Z<p>Vsindhuja: /* Network Address and Port Translation (NAT) models */</p>
<hr />
<div>{{TOC}}<br />
<br />
<div style="float: left; width: 100%"><br />
[[File:Gsoc-2012-logo-color.png|center|600px]]<br />
<blockquote><br />
* [http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2012/faqs GSoC Frequently Asked Questions]<br />
* [http://en.flossmanuals.net/gsocmentoring/ GSoC Mentor guide]<br />
* [http://en.flossmanuals.net/GSoCStudentGuide/ GSoC student guide]<br />
* [[GSOC2012StudentGuide |ns-3's GSoC Student guide]]<br />
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br />
* [[GSOC2012StudentApplicationTemplate |GSoC Student application template]]<br />
* [[GSOC2012Projects |GSoC 2012 page]]<br />
* [[GSOC2011Projects |NSoC 2011 Ideas page]] | [[NSOC2011AcceptedProjects |NSoC 2011 Accepted Projects]]<br />
* [[GSOC2010Projects |GSoC 2010 Ideas page]] | [[GSOC2010AcceptedProjects |GSoC 2010 Accepted Projects]]<br />
* [[GSOC2009Projects |GSoC 2009 Ideas page]] | [[GSOC2009AcceptedProjects |GSoC 2009 Accepted Projects]]<br />
* [[GSOC2010OAReport |GSoC Organization Administrator guide]]<br />
* ''Get in contact with the ns-3 team'': [http://mailman.isi.edu/mailman/listinfo/ns-developers ns-developers mailing list] | ''IRC'' #ns-3 on freenode.net<br />
</blockquote><br />
</div><br />
<p>&nbsp;<br />
<br />
= Accepted Projects =<br />
<br />
This page links to more information on the projects accepted for ns-3's 2012 Google Summer of Code effort.<br />
<br />
<br />
== LTE Scheduling with the FemtoForum MAC Scheduler API ==<br />
<br />
* Student: [mailto:q5frc@unb.ca Dizhi Zhou]<br />
* Mentor: [mailto:nicola.baldo@cttc.es Nicola Baldo]<br />
* Abstract: This project will develop several main MAC schedulers for LTE. It also includes corresponding test suites and user manual.<br />
* [http://www.nsnam.org/wiki/index.php/GSOC2012LTEScheduling Wiki]<br />
<br />
== HLA Interfaces for NS-3 ==<br />
<br />
* Student: [mailto:mudit.raaj.gupta@gmail.com Mudit Raj Gupta]<br />
* Mentor: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br />
* Abstract: The project deals with writing a HLA compliant scheduler for NS-3 and relevant supporting classes with an HLA API to help NS-3 participate in distributed simulations with other simulators, preferably scenario simulators. HLA is an IEEE standard, facilitates interoperability among simulations and promotes reuse of simulation models. The project also deals with testing of the same by using a portico RTI and a simple distributed simulation on HLA Repast Symphony and NS-3.<br />
* [http://www.nsnam.org/wiki/index.php/GSOC2012HLA Wiki]<br />
* [http://thehlans-3blog.blogspot.in/ Blog]<br />
<br />
== Network Address and Port Translation (NAT) models ==<br />
<br />
* Student: [mailto:intutivestriker88@gmail.com V. Sindhuja]<br />
* Mentor: [mailto:tomhend@u.washington.edu Tom Henderson]<br />
* 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.<br />
* [[GSOC2012NetworkAddressTranslation | Wiki ]]<br />
* [http://isindhu.wordpress.com/ Blog]<br />
<br />
[[Category:GSoC]]</div>Vsindhujahttps://www.nsnam.org/mediawiki/index.php?title=GSOC2012NetworkAddressTranslation&diff=6800GSOC2012NetworkAddressTranslation2012-05-25T08:11:25Z<p>Vsindhuja: </p>
<hr />
<div>==Project Contact==<br />
<br />
* Student: [mailto:intutivestriker88@gmail.com V. Sindhuja]<br />
* Mentor: [mailto:tomhend@u.washington.edu Tom Henderson]<br />
* 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.<br />
<br />
==Introduction==<br />
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.<br />
The specifics of the implementation will be updated on further progress.<br />
<br />
This project builds on the work previously done by Qasim Javed and Adrian Tam in [[GSOC2009NetworkAddressTranslation | 2009]].<br />
<br />
==Project Rationale==<br />
<br />
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.<br />
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. <br />
This would help recreate more real world network scenarios where firewalls are ubiquitous.<br />
<br />
==Approach==<br />
<br />
===Design===<br />
<br />
The work will primarily be divided in two main parts:<br />
<br />
'''A.Building the Netfilter Framework '''<br />
<br />
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.<br />
<br />
''1.This would have 5 hooks''<br />
o NF_INET_PRE_ROUTING<br />
o NF_INET_LOCAL_IN<br />
o NF_INET_FORWARD<br />
o NF_INET_LOCAL_OUT<br />
o NF_INET_POST_ROUTING<br />
<br />
''2.Callback chaining''<br />
<br />
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.<br />
<br />
''3.Connection tracking''<br />
<br />
To maintain the state of the connection making the node one that is stateful.<br />
<br />
'''B.Implementing the main NAT models'''<br />
<br />
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.<br />
<br />
''Static one-to-one NAT''<br />
<br />
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.<br />
<br />
''Regular Dynamic NAT''<br />
<br />
This is the NAT where all the traffic is translated to one IP address and multiple ports(Port address translation).<br />
<br />
''User Specific API''<br />
<br />
At a very generic level of explaining this I start with when nat is enabled on a node. The user would invoke something like :<br />
<br />
Nat_Install(node,lan-interface,wan-interface) <br />
<br />
This would clearly set the interfaces of the node participating in the NATting.<br />
<br />
Once this is done the user would configure the <br />
<br />
Static one-to-one:<br />
<br />
static_nat(lan-ip,wan-ip);<br />
<br />
static_nat(lan-ip,wan-ip,port-range) //in the case of number of ports<br />
<br />
Dynamic NAPT:<br />
<br />
dynamic_nat(lan-ip network with mask,wan-ip);<br />
<br />
A more NS-3 specific interface definition will be updated in the course of this project.<br />
<br />
<br />
===Testing===<br />
<br />
For the tests of the Nat and Netfilter will focus on a base simulation would be used <br />
<br />
n1--n2--n3 <br />
<br />
where n2 is the nat device with n1 on the private network and n3 is out on the internet.<br />
Multiple aspects would be looked at while testing : <br />
<br />
- Appropriate routing of the packet<br />
<br />
- Packet filtering in place<br />
<br />
- Header fields in the packet updated as per netfilter and nat rules<br />
<br />
- Connection tracking maintained<br />
<br />
- Checksum computation accuracy<br />
<br />
==Plan==<br />
<br />
·Week 1: (22/05-29/05) Adapt the existing Netfilter code to the current NS3<br />
<br />
·Week 2: (30/05-06/06) Test the adaptation for the Netfilter code to current NS3<br />
<br />
·Week 3: (07/06-14/06) Static one-to-one Design and Implementation<br />
<br />
·Week 4: (15/06-22/06) Static one-to-one Design and Implementation<br />
<br />
·Week 5: (23/06-30/06) Test the Static one-to-one Implementations.<br />
<br />
·Week 6: (01/07-08/07) Dynamic Port-Translating NAT Design and Implementation<br />
<br />
·09/07- Midterm evaluation submission<br />
<br />
·Week 7: (10/07-17/07) Dynamic Port-Translating NAT Design and Implementation<br />
<br />
·Week 8: (18/07-25/07) Testing the Dynamic Port-Translating NAT implementation.<br />
<br />
·Week 9: (26/07-02/08) Test and Work on integration of the NAT Models<br />
<br />
·Week 10: (03/08-10/08)Test and Work on integration of the NAT Models <br />
<br />
·Aug 13 Suggested Pencils Down Date.<br />
<br />
·11/08-19/08: Documentation and Integration of the project<br />
<br />
·20/08 - Final Evaluation and Submission.</div>Vsindhujahttps://www.nsnam.org/mediawiki/index.php?title=GSOC2012NetworkAddressTranslation&diff=6799GSOC2012NetworkAddressTranslation2012-05-25T08:10:23Z<p>Vsindhuja: </p>
<hr />
<div>==Project Contact==<br />
<br />
* Student: [mailto:intutivestriker88@gmail.com V. Sindhuja]<br />
* Mentor: [mailto:tomhend@u.washington.edu Tom Henderson]<br />
* 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.<br />
<br />
==Introduction==<br />
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.<br />
The specifics of the implementation will be updated on further progress.<br />
<br />
This project builds on the work previously done by Qasim Javed and Adrian Tam in [[GSOC2009NetworkAddressTranslation | 2009]].<br />
<br />
==Approach==<br />
<br />
===Design===<br />
<br />
The work will primarily be divided in two main parts:<br />
<br />
'''A.Building the Netfilter Framework '''<br />
<br />
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.<br />
<br />
''1.This would have 5 hooks''<br />
o NF_INET_PRE_ROUTING<br />
o NF_INET_LOCAL_IN<br />
o NF_INET_FORWARD<br />
o NF_INET_LOCAL_OUT<br />
o NF_INET_POST_ROUTING<br />
<br />
''2.Callback chaining''<br />
<br />
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.<br />
<br />
''3.Connection tracking''<br />
<br />
To maintain the state of the connection making the node one that is stateful.<br />
<br />
'''B.Implementing the main NAT models'''<br />
<br />
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.<br />
<br />
''Static one-to-one NAT''<br />
<br />
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.<br />
<br />
''Regular Dynamic NAT''<br />
<br />
This is the NAT where all the traffic is translated to one IP address and multiple ports(Port address translation).<br />
<br />
''User Specific API''<br />
<br />
At a very generic level of explaining this I start with when nat is enabled on a node. The user would invoke something like :<br />
<br />
Nat_Install(node,lan-interface,wan-interface) <br />
<br />
This would clearly set the interfaces of the node participating in the NATting.<br />
<br />
Once this is done the user would configure the <br />
<br />
Static one-to-one:<br />
<br />
static_nat(lan-ip,wan-ip);<br />
<br />
static_nat(lan-ip,wan-ip,port-range) //in the case of number of ports<br />
<br />
Dynamic NAPT:<br />
<br />
dynamic_nat(lan-ip network with mask,wan-ip);<br />
<br />
A more NS-3 specific interface definition will be updated in the course of this project.<br />
<br />
<br />
===Testing===<br />
<br />
For the tests of the Nat and Netfilter will focus on a base simulation would be used <br />
<br />
n1--n2--n3 <br />
<br />
where n2 is the nat device with n1 on the private network and n3 is out on the internet.<br />
Multiple aspects would be looked at while testing : <br />
<br />
- Appropriate routing of the packet<br />
<br />
- Packet filtering in place<br />
<br />
- Header fields in the packet updated as per netfilter and nat rules<br />
<br />
- Connection tracking maintained<br />
<br />
- Checksum computation accuracy<br />
<br />
==Plan==<br />
<br />
·Week 1: (22/05-29/05) Adapt the existing Netfilter code to the current NS3<br />
<br />
·Week 2: (30/05-06/06) Test the adaptation for the Netfilter code to current NS3<br />
<br />
·Week 3: (07/06-14/06) Static one-to-one Design and Implementation<br />
<br />
·Week 4: (15/06-22/06) Static one-to-one Design and Implementation<br />
<br />
·Week 5: (23/06-30/06) Test the Static one-to-one Implementations.<br />
<br />
·Week 6: (01/07-08/07) Dynamic Port-Translating NAT Design and Implementation<br />
<br />
·09/07- Midterm evaluation submission<br />
<br />
·Week 7: (10/07-17/07) Dynamic Port-Translating NAT Design and Implementation<br />
<br />
·Week 8: (18/07-25/07) Testing the Dynamic Port-Translating NAT implementation.<br />
<br />
·Week 9: (26/07-02/08) Test and Work on integration of the NAT Models<br />
<br />
·Week 10: (03/08-10/08)Test and Work on integration of the NAT Models <br />
<br />
·Aug 13 Suggested Pencils Down Date.<br />
<br />
·11/08-19/08: Documentation and Integration of the project<br />
<br />
·20/08 - Final Evaluation and Submission.</div>Vsindhujahttps://www.nsnam.org/mediawiki/index.php?title=GSOC2012NetworkAddressTranslation&diff=6798GSOC2012NetworkAddressTranslation2012-05-25T08:07:17Z<p>Vsindhuja: </p>
<hr />
<div>==Project Contact==<br />
<br />
* Student: [mailto:intutivestriker88@gmail.com V. Sindhuja]<br />
* Mentor: [mailto:tomhend@u.washington.edu Tom Henderson]<br />
* 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.<br />
<br />
==Introduction==<br />
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.<br />
The specifics of the implementation will be updated on further progress.<br />
<br />
This project builds on the work previously done by Qasim Javed and Adrian Tam in [[GSOC2009NetworkAddressTranslation | 2009]].<br />
<br />
==Approach==<br />
<br />
==Design==<br />
<br />
The work will primarily be divided in two main parts:<br />
<br />
'''A.Building the Netfilter Framework '''<br />
<br />
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.<br />
<br />
''1.This would have 5 hooks''<br />
o NF_INET_PRE_ROUTING<br />
o NF_INET_LOCAL_IN<br />
o NF_INET_FORWARD<br />
o NF_INET_LOCAL_OUT<br />
o NF_INET_POST_ROUTING<br />
<br />
''2.Callback chaining''<br />
<br />
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.<br />
<br />
''3.Connection tracking''<br />
<br />
To maintain the state of the connection making the node one that is stateful.<br />
<br />
'''B.Implementing the main NAT models'''<br />
<br />
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.<br />
<br />
''Static one-to-one NAT''<br />
<br />
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.<br />
<br />
''Regular Dynamic NAT''<br />
<br />
This is the NAT where all the traffic is translated to one IP address and multiple ports(Port address translation).<br />
<br />
''User Specific API''<br />
<br />
At a very generic level of explaining this I start with when nat is enabled on a node. The user would invoke something like :<br />
<br />
Nat_Install(node,lan-interface,wan-interface) <br />
<br />
This would clearly set the interfaces of the node participating in the NATting.<br />
<br />
Once this is done the user would configure the <br />
<br />
Static one-to-one:<br />
<br />
static_nat(lan-ip,wan-ip);<br />
<br />
static_nat(lan-ip,wan-ip,port-range) //in the case of number of ports<br />
<br />
Dynamic NAPT:<br />
<br />
dynamic_nat(lan-ip network with mask,wan-ip);<br />
<br />
A more NS-3 specific interface definition will be updated in the course of this project.<br />
<br />
<br />
==Testing==<br />
<br />
For the tests of the Nat and Netfilter will focus on a base simulation would be used <br />
<br />
n1--n2--n3 <br />
<br />
where n2 is the nat device with n1 on the private network and n3 is out on the internet.<br />
Multiple aspects would be looked at while testing : <br />
<br />
- Appropriate routing of the packet<br />
<br />
- Packet filtering in place<br />
<br />
- Header fields in the packet updated as per netfilter and nat rules<br />
<br />
- Connection tracking maintained<br />
<br />
- Checksum computation accuracy<br />
<br />
==Plan==<br />
<br />
·Week 1: (22/05-29/05) Adapt the existing Netfilter code to the current NS3<br />
<br />
·Week 2: (30/05-06/06) Test the adaptation for the Netfilter code to current NS3<br />
<br />
·Week 3: (07/06-14/06) Static one-to-one Design and Implementation<br />
<br />
·Week 4: (15/06-22/06) Static one-to-one Design and Implementation<br />
<br />
·Week 5: (23/06-30/06) Test the Static one-to-one Implementations.<br />
<br />
·Week 6: (01/07-08/07) Dynamic Port-Translating NAT Design and Implementation<br />
<br />
·09/07- Midterm evaluation submission<br />
<br />
·Week 7: (10/07-17/07) Dynamic Port-Translating NAT Design and Implementation<br />
<br />
·Week 8: (18/07-25/07) Testing the Dynamic Port-Translating NAT implementation.<br />
<br />
·Week 9: (26/07-02/08) Test and Work on integration of the NAT Models<br />
<br />
·Week 10: (03/08-10/08)Test and Work on integration of the NAT Models <br />
<br />
·Aug 13 Suggested Pencils Down Date.<br />
<br />
·11/08-19/08: Documentation and Integration of the project<br />
<br />
·20/08 - Final Evaluation and Submission.</div>Vsindhujahttps://www.nsnam.org/mediawiki/index.php?title=GSOC2012NetworkAddressTranslation&diff=6797GSOC2012NetworkAddressTranslation2012-05-25T08:06:38Z<p>Vsindhuja: /* Overview */</p>
<hr />
<div>==Project Contact==<br />
<br />
* Student: [mailto:intutivestriker88@gmail.com V. Sindhuja]<br />
* Mentor: [mailto:tomhend@u.washington.edu Tom Henderson]<br />
* 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.<br />
<br />
==Introduction==<br />
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.<br />
The specifics of the implementation will be updated on further progress.<br />
<br />
This project builds on the work previously done by Qasim Javed and Adrian Tam in [[GSOC2009NetworkAddressTranslation | 2009]].<br />
<br />
==Approach==<br />
<br />
==Design==<br />
<br />
The work will primarily be divided in two main parts:<br />
<br />
'''A.Building the Netfilter Framework '''<br />
<br />
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.<br />
<br />
''1.This would have 5 hooks''<br />
o NF_INET_PRE_ROUTING<br />
o NF_INET_LOCAL_IN<br />
o NF_INET_FORWARD<br />
o NF_INET_LOCAL_OUT<br />
o NF_INET_POST_ROUTING<br />
<br />
''2.Callback chaining''<br />
<br />
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.<br />
<br />
''3.Connection tracking''<br />
<br />
To maintain the state of the connection making the node one that is stateful.<br />
<br />
'''B.Implementing the main NAT models'''<br />
<br />
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.<br />
<br />
''Static one-to-one NAT''<br />
<br />
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.<br />
<br />
''Regular Dynamic NAT''<br />
<br />
This is the NAT where all the traffic is translated to one IP address and multiple ports(Port address translation).<br />
<br />
''User Specific API''<br />
<br />
At a very generic level of explaining this I start with when nat is enabled on a node. The user would invoke something like :<br />
<br />
Nat_Install(node,lan-interface,wan-interface) <br />
<br />
This would clearly set the interfaces of the node participating in the NATting.<br />
<br />
Once this is done the user would configure the <br />
<br />
Static one-to-one:<br />
<br />
static_nat(lan-ip,wan-ip);<br />
<br />
static_nat(lan-ip,wan-ip,port-range) //in the case of number of ports<br />
<br />
Dynamic NAPT:<br />
<br />
dynamic_nat(lan-ip network with mask,wan-ip);<br />
<br />
A more NS-3 specific interface definition will be updated in the course of this project.<br />
<br />
<br />
==Testing==<br />
<br />
For the tests of the Nat and Netfilter will focus on a base simulation would be used <br />
<br />
n1--n2--n3 <br />
<br />
where n2 is the nat device with n1 on the private network and n3 is out on the internet.<br />
Multiple aspects would be looked at while testing : <br />
<br />
- Appropriate routing of the packet<br />
<br />
- Packet filtering in place<br />
<br />
- Header fields in the packet updated as per netfilter and nat rules<br />
<br />
- Connection tracking maintained<br />
<br />
- Checksum computation accuracy<br />
<br />
==Plan==<br />
<br />
·Week 1: (22/05-29/05) Adapt the existing Netfilter code to the current NS3<br />
<br />
·Week 2: (30/05-06/06) Test the adaptation for the Netfilter code to current NS3<br />
<br />
·Week 3: (07/06-14/06) Static one-to-one Design and Implementation<br />
<br />
·Week 4: (15/06-22/06) Static one-to-one Design and Implementation<br />
<br />
·Week 5: (23/06-30/06) Test the Static one-to-one Implementations.<br />
<br />
·Week 6: (01/07-08/07) Dynamic Port-Translating NAT Design and Implementation<br />
<br />
·09/07- Midterm evaluation submission<br />
<br />
·Week 7: (10/07-17/07) Dynamic Port-Translating NAT Design and Implementation<br />
<br />
·Week 8: (18/07-25/07) Testing the Dynamic Port-Translating NAT implementation.<br />
<br />
·Week 9: (26/07-02/08) Test and Work on integration of the NAT Models<br />
<br />
·Week 10: (03/08-10/08)Test and Work on integration of the NAT Models <br />
<br />
·Aug 13 Suggested Pencils Down Date.<br />
<br />
·11/08-19/08: Documentation and Integration of the project<br />
<br />
·20/08 - Final Evaluation and Submission.</div>Vsindhujahttps://www.nsnam.org/mediawiki/index.php?title=GSOC2012AcceptedProjects&diff=6783GSOC2012AcceptedProjects2012-05-21T15:33:18Z<p>Vsindhuja: /* Network Address and Port Translation (NAT) models */</p>
<hr />
<div>{{TOC}}<br />
<br />
<div style="float: left; width: 100%"><br />
[[File:Gsoc-2012-logo-color.png|center|600px]]<br />
<blockquote><br />
* [http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2012/faqs GSoC Frequently Asked Questions]<br />
* [http://en.flossmanuals.net/gsocmentoring/ GSoC Mentor guide]<br />
* [http://en.flossmanuals.net/GSoCStudentGuide/ GSoC student guide]<br />
* [[GSOC2012StudentGuide |ns-3's GSoC Student guide]]<br />
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br />
* [[GSOC2012StudentApplicationTemplate |GSoC Student application template]]<br />
* [[GSOC2012Projects |GSoC 2012 page]]<br />
* [[GSOC2011Projects |NSoC 2011 Ideas page]] | [[NSOC2011AcceptedProjects |NSoC 2011 Accepted Projects]]<br />
* [[GSOC2010Projects |GSoC 2010 Ideas page]] | [[GSOC2010AcceptedProjects |GSoC 2010 Accepted Projects]]<br />
* [[GSOC2009Projects |GSoC 2009 Ideas page]] | [[GSOC2009AcceptedProjects |GSoC 2009 Accepted Projects]]<br />
* [[GSOC2010OAReport |GSoC Organization Administrator guide]]<br />
* ''Get in contact with the ns-3 team'': [http://mailman.isi.edu/mailman/listinfo/ns-developers ns-developers mailing list] | ''IRC'' #ns-3 on freenode.net<br />
</blockquote><br />
</div><br />
<p>&nbsp;<br />
<br />
= Accepted Projects =<br />
<br />
This page links to more information on the projects accepted for ns-3's 2012 Google Summer of Code effort.<br />
<br />
<br />
== LTE Scheduling with the FemtoForum MAC Scheduler API ==<br />
<br />
* Student: [mailto:q5frc@unb.ca Dizhi Zhou]<br />
* Mentor: [mailto:nicola.baldo@cttc.es Nicola Baldo]<br />
* Abstract: This project will develop several main MAC schedulers for LTE. It also includes corresponding test suites and user manual.<br />
* [http://www.nsnam.org/wiki/index.php/GSOC2012LTEScheduling Wiki]<br />
<br />
== HLA Interfaces for NS-3 ==<br />
<br />
* Student: [mailto:mudit.raaj.gupta@gmail.com Mudit Raj Gupta]<br />
* Mentor: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br />
* Abstract: The project deals with writing a HLA compliant scheduler for NS-3 and relevant supporting classes with an HLA API to help NS-3 participate in distributed simulations with other simulators, preferably scenario simulators. HLA is an IEEE standard, facilitates interoperability among simulations and promotes reuse of simulation models. The project also deals with testing of the same by using a portico RTI and a simple distributed simulation on HLA Repast Symphony and NS-3.<br />
* Wiki Page: TBD<br />
* [http://thehlans-3blog.blogspot.in/ Blog]<br />
<br />
== Network Address and Port Translation (NAT) models ==<br />
<br />
* Student: [mailto:intutivestriker88@gmail.com V. Sindhuja]<br />
* Mentor: [mailto:tomhend@u.washington.edu Tom Henderson]<br />
* 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.<br />
* [[GSOC2012NetworkAddressTranslation | Wiki Page]]<br />
<br />
[[Category:GSoC]]</div>Vsindhujahttps://www.nsnam.org/mediawiki/index.php?title=GSOC2012NetworkAddressTranslation&diff=6782GSOC2012NetworkAddressTranslation2012-05-21T01:18:02Z<p>Vsindhuja: /* Plan */</p>
<hr />
<div>==Project Contact==<br />
<br />
* Student: [mailto:intutivestriker88@gmail.com V. Sindhuja]<br />
* Mentor: [mailto:tomhend@u.washington.edu Tom Henderson]<br />
* 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.<br />
<br />
==Introduction==<br />
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.<br />
The specifics of the implementation will be updated on further progress.<br />
<br />
This project builds on the work previously done by Qasim Javed and Adrian Tam in [[GSOC2009NetworkAddressTranslation | 2009]].<br />
<br />
==Overview==<br />
<br />
The work will primarily be divided in two main parts:<br />
<br />
'''A.Implementing the NAT Framework in NS3 (using hooks and chaining as in Netfilter)'''<br />
<br />
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.<br />
<br />
''1.This would have 5 hooks''<br />
o NF_INET_PRE_ROUTING<br />
o NF_INET_LOCAL_IN<br />
o NF_INET_FORWARD<br />
o NF_INET_LOCAL_OUT<br />
o NF_INET_POST_ROUTING<br />
<br />
''2.Callback chaining''<br />
<br />
With this implementation I can set the priority for the different NAT translations that are there and check for existing<br />
connections.<br />
<br />
''3.Connection tracking''<br />
<br />
To maintain the state of the connection making the node one that is stateful.<br />
<br />
'''B.Implementing the main NAT models that are key to including all types of network traffic.'''<br />
<br />
''Static one-to-one NAT''<br />
<br />
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.<br />
<br />
''Regular Dynamic NAT''<br />
<br />
This is the NAT where all the traffic is translated to one IP address and multiple ports(Port address translation).<br />
<br />
==Plan==<br />
<br />
·Week 1: (22/05-29/05) Adapt the existing Netfilter code to the current NS3<br />
<br />
·Week 2: (30/05-06/06) Test the adaptation for the Netfilter code to current NS3<br />
<br />
·Week 3: (07/06-14/06) Static one-to-one Design and Implementation<br />
<br />
·Week 4: (15/06-22/06) Static one-to-one Design and Implementation<br />
<br />
·Week 5: (23/06-30/06) Test the Static one-to-one Implementations.<br />
<br />
·Week 6: (01/07-08/07) Dynamic Port-Translating NAT Design and Implementation<br />
<br />
·09/07- Midterm evaluation submission<br />
<br />
·Week 7: (10/07-17/07) Dynamic Port-Translating NAT Design and Implementation<br />
<br />
·Week 8: (18/07-25/07) Testing the Dynamic Port-Translating NAT implementation.<br />
<br />
·Week 9: (26/07-02/08) Test and Work on integration of the NAT Models<br />
<br />
·Week 10: (03/08-10/08)Test and Work on integration of the NAT Models <br />
<br />
·Aug 13 Suggested Pencils Down Date.<br />
<br />
·11/08-19/08: Documentation and Integration of the project<br />
<br />
·20/08 - Final Evaluation and Submission.</div>Vsindhujahttps://www.nsnam.org/mediawiki/index.php?title=GSOC2012NetworkAddressTranslation&diff=6781GSOC2012NetworkAddressTranslation2012-05-21T01:17:28Z<p>Vsindhuja: /* Overview */</p>
<hr />
<div>==Project Contact==<br />
<br />
* Student: [mailto:intutivestriker88@gmail.com V. Sindhuja]<br />
* Mentor: [mailto:tomhend@u.washington.edu Tom Henderson]<br />
* 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.<br />
<br />
==Introduction==<br />
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.<br />
The specifics of the implementation will be updated on further progress.<br />
<br />
This project builds on the work previously done by Qasim Javed and Adrian Tam in [[GSOC2009NetworkAddressTranslation | 2009]].<br />
<br />
==Overview==<br />
<br />
The work will primarily be divided in two main parts:<br />
<br />
'''A.Implementing the NAT Framework in NS3 (using hooks and chaining as in Netfilter)'''<br />
<br />
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.<br />
<br />
''1.This would have 5 hooks''<br />
o NF_INET_PRE_ROUTING<br />
o NF_INET_LOCAL_IN<br />
o NF_INET_FORWARD<br />
o NF_INET_LOCAL_OUT<br />
o NF_INET_POST_ROUTING<br />
<br />
''2.Callback chaining''<br />
<br />
With this implementation I can set the priority for the different NAT translations that are there and check for existing<br />
connections.<br />
<br />
''3.Connection tracking''<br />
<br />
To maintain the state of the connection making the node one that is stateful.<br />
<br />
'''B.Implementing the main NAT models that are key to including all types of network traffic.'''<br />
<br />
''Static one-to-one NAT''<br />
<br />
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.<br />
<br />
''Regular Dynamic NAT''<br />
<br />
This is the NAT where all the traffic is translated to one IP address and multiple ports(Port address translation).<br />
<br />
==Plan==<br />
<br />
·Week 1: (22/05-29/05) Adapt the existing Netfilter code to the current NS3<br />
·Week 2: (30/05-06/06) Test the adaptation for the Netfilter code to current NS3<br />
·Week 3: (07/06-14/06) Static one-to-one Design and Implementation<br />
·Week 4: (15/06-22/06) Static one-to-one Design and Implementation<br />
·Week 5: (23/06-30/06) Test the Static one-to-one Implementations.<br />
·Week 6: (01/07-08/07) Dynamic Port-Translating NAT Design and Implementation<br />
<br />
·09/07- Midterm evaluation submission<br />
<br />
·Week 7: (10/07-17/07) Dynamic Port-Translating NAT Design and Implementation<br />
·Week 8: (18/07-25/07) Testing the Dynamic Port-Translating NAT implementation.<br />
·Week 9: (26/07-02/08) Test and Work on integration of the NAT Models<br />
·Week 10: (03/08-10/08)Test and Work on integration of the NAT Models <br />
<br />
·Aug 13 Suggested Pencils Down Date.<br />
<br />
·11/08-19/08: Documentation and Integration of the project<br />
<br />
·20/08 - Final Evaluation and Submission.</div>Vsindhujahttps://www.nsnam.org/mediawiki/index.php?title=GSOC2012NetworkAddressTranslation&diff=6780GSOC2012NetworkAddressTranslation2012-05-21T00:47:26Z<p>Vsindhuja: /* Introduction */</p>
<hr />
<div>==Project Contact==<br />
<br />
* Student: [mailto:intutivestriker88@gmail.com V. Sindhuja]<br />
* Mentor: [mailto:tomhend@u.washington.edu Tom Henderson]<br />
* 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.<br />
<br />
==Introduction==<br />
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.<br />
The specifics of the implementation will be updated on further progress.<br />
<br />
This project builds on the work previously done by Qasim Javed and Adrian Tam in [[GSOC2009NetworkAddressTranslation | 2009]].<br />
<br />
==Overview==<br />
<br />
The work will primarily be divided in two main parts:<br />
<br />
A.Implementing the NAT Framework in NS3 (using hooks and chaining as in Netfilter)<br />
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.<br />
<br />
1.This would have 5 hooks<br />
o NF_INET_PRE_ROUTING<br />
o NF_INET_LOCAL_IN<br />
o NF_INET_FORWARD<br />
o NF_INET_LOCAL_OUT<br />
o NF_INET_POST_ROUTING<br />
<br />
2.Callback chaining<br />
With this implementation I can set the priority for the different NAT translations that are there and check for existing<br />
connections.<br />
<br />
3.Connection tracking<br />
To maintain the state of the connection making the node one that is stateful.<br />
<br />
B.Implementing the main NAT models that are key to including all types of network traffic.<br />
<br />
1.Network Address Translation Models<br />
<br />
-Static one-one<br />
<br />
This NAT would be persistent for all the connections made from that host. When I port is specified then it would remain<br />
specific to that port. This translation can never get cleared out or timed out. Unless one manually removes the<br />
configuration.<br />
<br />
-Regular Dynamic NAT<br />
<br />
This is the NAT where all the traffic is translated to one IP address and multiple ports(Port address translation).<br />
<br />
==Plan==<br />
<br />
·Week 1: (22/05-29/05) Adapt the existing Netfilter code to the current NS3<br />
·Week 2: (30/05-06/06) Test the adaptation for the Netfilter code to current NS3<br />
·Week 3: (07/06-14/06) Static one-to-one Design and Implementation<br />
·Week 4: (15/06-22/06) Static one-to-one Design and Implementation<br />
·Week 5: (23/06-30/06) Test the Static one-to-one Implementations.<br />
·Week 6: (01/07-08/07) Dynamic Port-Translating NAT Design and Implementation<br />
<br />
·09/07- Midterm evaluation submission<br />
<br />
·Week 7: (10/07-17/07) Dynamic Port-Translating NAT Design and Implementation<br />
·Week 8: (18/07-25/07) Testing the Dynamic Port-Translating NAT implementation.<br />
·Week 9: (26/07-02/08) Test and Work on integration of the NAT Models<br />
·Week 10: (03/08-10/08)Test and Work on integration of the NAT Models <br />
<br />
·Aug 13 Suggested Pencils Down Date.<br />
<br />
·11/08-19/08: Documentation and Integration of the project<br />
<br />
·20/08 - Final Evaluation and Submission.</div>Vsindhujahttps://www.nsnam.org/mediawiki/index.php?title=GSOC2012NetworkAddressTranslation&diff=6779GSOC2012NetworkAddressTranslation2012-05-21T00:32:23Z<p>Vsindhuja: /* Project Contact */</p>
<hr />
<div>==Introduction==<br />
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.<br />
The specifics of the implementation will be updated on further progress.<br />
<br />
This project builds on the work previously done by Qasim Javed and Adrian Tam in [[GSOC2009NetworkAddressTranslation | 2009]].</div>Vsindhujahttps://www.nsnam.org/mediawiki/index.php?title=GSOC2012NetworkAddressTranslation&diff=6778GSOC2012NetworkAddressTranslation2012-05-21T00:31:06Z<p>Vsindhuja: /* Introduction */</p>
<hr />
<div>==Project Contact==<br />
<br />
* Student: [mailto:intutivestriker88@gmail.com V. Sindhuja]<br />
* Mentor: [mailto:tomhend@u.washington.edu Tom Henderson]<br />
* 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.<br />
<br />
<br />
==Introduction==<br />
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.<br />
The specifics of the implementation will be updated on further progress.<br />
<br />
This project builds on the work previously done by Qasim Javed and Adrian Tam in [[GSOC2009NetworkAddressTranslation | 2009]].</div>Vsindhujahttps://www.nsnam.org/mediawiki/index.php?title=GSOC2012NetworkAddressTranslation&diff=6777GSOC2012NetworkAddressTranslation2012-05-21T00:25:51Z<p>Vsindhuja: Created page with "==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 g..."</p>
<hr />
<div>==Introduction==<br />
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. <br />
The specifics of the implementation will be updated on further progress.<br />
<br />
This project builds on the work previously done by Qasim Javed and Adrian Tam in [[GSOC2009NetworkAddressTranslation | 2009]].</div>Vsindhujahttps://www.nsnam.org/mediawiki/index.php?title=User:Vsindhuja&diff=6764User:Vsindhuja2012-05-09T02:25:54Z<p>Vsindhuja: Blanked the page</p>
<hr />
<div></div>Vsindhujahttps://www.nsnam.org/mediawiki/index.php?title=User:Vsindhuja&diff=6763User:Vsindhuja2012-05-09T02:25:42Z<p>Vsindhuja: Created page with "Sindhuja Venkatesh"</p>
<hr />
<div>Sindhuja Venkatesh</div>Vsindhuja