Christian Dickmann
Applied Computer Science student at the University of Göttingen

 NSIS
 Homepage
 HOWTOs
 Testbed setup
 Create your own NSLP
 
Testbed setup

In order to test our NSIS package you should set up a network with several routers. To test a few standard scenarios you will need a number of maschines. These scenarios include:
  • Bypass of non-GIST nodes
  • Bypass of GIST nodes, that do not support a certain NSLP
  • Traversal of NAT/FW nodes, that run FW only
  • Traversal of NAT/FW nodes, that are NAT, but not Edge-NAT
  • Traversal of NAT/FW nodes, that are Edge-NAT


Example network I:

A simple network not containing all listed scenarios is the following one:

  • The "Notebook" is used to control the testbed and doubles as the initiator node for most NSIS operations. The "Notebook" is only connected to the node "Virtual 1".
  • "Virtual 1" can be used as a FW-only node, a non-NATFW node and as a non-GIST node. "Virtual 1" serves as router between "Notebook" and "Virtual 2".
  • "Virtual 2" is the most important node in the network. It has connections to "Virtual 1", "Virtual 3" and "Virtual 4". With respect to the 10.0.0.0/24 network "Virtual 2" serves as a NAT router. In this example, 10.0.0.0/24 is regarded as a global network. Therefore, "Virtual 2" is the Edge-NAT.
  • "Virtual 3" serves as a end host in the private network.
  • "Virtual 4" serves as a router in the global "internet" in this example.

Network configuration:
The IP address configuration is shown in the figure. The routes are configured in a way that "Virtual 2" serves as the gateway to the global network. "Virtual 2" does so by creating a NAT because "Virtual 4" should have no routes into the private network hidden by "Virtual 2".
The configuration of all machines is given by their /etc/network/interfaces file. In addition the file /etc/network/options must enable ip forwarding on the routers. Therefore I provide examples of these file for all machines of the network:


NSIS configuration:
The tests provided below all base on a general configuration of the NSIS implementation. If a test requires a different configuration, the text will explicitly state the change. The example configuration files for all machines can be found here:
PLEASE NOTE: This document is based on release 0.3.1 of our NSIS implementation.


Test I: Basic GIST operation
First of all, the basic GIST operation has to be tested. In order to do so, you should start NSIS on "Notebook", "Virtual 2" and "Virtual 3". NSIS should be configured to start the "Ping tool" NSLP (the provided example configurations for these machines already start the ping tool).
Now run:
bin/gistPing 192.168.21.11
This confirms the general GIST operation. "Virtual 1" is bypassed and "Notebook" and "Virtual 2" are the only involved GIST nodes.

The next test includes 3 nodes, so run:
bin/gistPing 192.168.22.12
This confirms that GIST works in the basic scenario. The only mayor thing missing is a node running GIST but not the "Ping tool". Therefore you should start NSIS on "Virtual 1" and NOT the "ping tool" (in addition you might want to start a different NSLP, e.g. QoS NSLP). The provided example configuration of NSIS does not start the "ping tool", so you do not need to change anything here.
Again run:
bin/gistPing 192.168.22.12
The output should not change. This means, that "Virtual 1" should NOT be listed as a hop.

The output should look like this one:
Running as ping client with (no reliability/no security)
SendRates: init 200, steady 200
PingMessage: hops = 5; length = 124; version = 1; seq# = 0
    Hop: 1137137299.377251 192.168.20.1
    Hop: 1137135604.29728 192.168.21.11
    Hop: 1137135618.281722 192.168.22.12
    Hop: 1137135604.70506 192.168.21.11
    Hop: 1137137299.614122 192.168.20.1


Test II: GIST operation with C-Mode
Test I only used UDP as transport. An important aspect of GIST operation is the use of transport protocol like TCP or SCTP. In addition TLS over TCP is an important transport stack as well. Therefore Test II focusses on the so called "C-Mode", the connection mode of GIST.
You should rerun the tests of Test I in the same order, but add "-r" (reliable) to the gistPing call. For example, the first call should be:
bin/gistPing 192.168.21.11 -r

The output of gistPing should be identical to the previous tests.


Test III: NAT/FW NSLP operation
Having Tests I and II completed, you have a running GIST setup in a network without a NAT. Test III now adds the NAT build by "Virtual 2" and "Virtual 4".
Run GIST and NAT/FW NSLP on "Notebook", "Virtual 1", "Virtual 2" and "Virtual 4" with the standard configuration provided above. In this configuration "Notebook" is behind a NAT and offers some kind of service. "Virtual 1" is a non-NAT Firewall. "Virtual 2" is the Edge-NAT and "Virtual 4" is some host in the global network that wants to talk to the service offered by "Notebook".
To do so, first of all "Notebook" has to request a global address/port combination. It does so by sending a NATFW/REA message towards the global network. The Edge-Nat ("Virtual 2") should receive the message and send a response containing the required info to "Notebook".
Therefore run this line on "Notebook":
bin/nsis-natfw REA 111.222.111.222

nsis-natfw should output a response code of "0". In addition it should provide 10.0.0.1 as the global address and a non-zero port.

Now we assume, that "Virtual 4" learned the IP/port over a third channel and run a CREATE to reserve a communication channel on the path to "Notebook". You need to run:
bin/nsis-natfw CREATE 10.0.0.1 <port> <port>

nsis-natfw again should output "0" as response code. A response code of "1003" would indicate that you messed the IP/sourceport/destinationport parameters in the CREATE, as "1003" means that the Edge-NAT was not able to resolve this reservation.