Home Papers Reports Projects Code Fragments Dissertations Presentations Posters Proposals Lectures given Course notes

Ship to Shore Communication

Werner Van Belle1* - werner@yellowcouch.org, werner.van.belle@gmail.com

1- Internet & Communication Technology Norut IT; Research Park; 9294 Tromsø; Norway

Abstract :  This document describes the possible problems encountenered when developing a realtime ship to shore IP4 connection tracker/spy/packet modifiier when relying on various transport ethers such as satelite links and wifi antennas. It focuses mainly on a Linux based solution.

Keywords:  packet routing ship to shore
Reference:  Werner Van Belle; Ship to Shore Communication; DUALOG Deliverable; 30 pages; August 2006


Table Of Contents
1 Preliminary Investigation Linux Box Based Solution
    1.1 Architectural Design
        1.1.1 Boat
        1.1.2 Communication control: Packets
        1.1.3 Communication control: Connections
        1.1.4 Communication Control: Routing Rules
        1.1.5 Authentication
        1.1.6 High level applications
        1.1.7 Application Programmers Interface
    1.2 Applicability of Linux based routers
        1.2.1 Tunneling in linux
            1.2.1.1 Machine A
            1.2.1.2 Machine B
        1.2.2 Address Translation
        1.2.3 Firewall Piercing Techniques
        1.2.4 Allowing, denying connections
        1.2.5 High level protocol forwarding
2 A Brief Study of the NUFW Architecture
    2.1 NUFW Overview
        2.1.1 Architecture
        2.1.2 Work-flow
    2.2 Downloading & compiling NUFW
    2.3 A one machine multi-user setup
        2.3.1 Kernel & IPTables
        2.3.2 Starting NuFw
            2.3.2.1 Creating SSL certificates
            2.3.2.2 Starting the NuFw connection daemon
        2.3.3 Authentication setup
        2.3.4 Client Authentication
    2.4 Setup on a firewall
    2.5 Conclusion
3 The Dualog Stack
    3.1 Introduction
    3.2 The Stack
        3.2.1 Links
        3.2.2 Mobile IP
        3.2.3 Network Address Translation / Masquerading
        3.2.4 Packet Stopper
            3.2.4.1 Linux
            3.2.4.2 Windows
    3.3 Location, Link & Connection management
        3.3.1 Connection Control
        3.3.2 Link Control
    3.4 Remaining Challenges
    3.5 Glossary
4 IPTables: User Kernel Link
    4.1 User To Kernel
        4.1.1 IPTables command
        4.1.2 LibIptc
        4.1.3 Kernel
    4.2 Kernel To User
    4.3 Conclusion
5 Using rsync as a remote update protocol for ship-to-shore communication
    5.1 Introduction
    5.2 Setup
    5.3 Possibilities
        5.3.1 Decremental Backups
        5.3.2 Detecting system alterations.
    5.4 Drawbacks of Rsync
    Bibliography

1 Preliminary Investigation Linux Box Based Solution

1.1 Architectural Design

1.1.1 Boat

This document discusses a preliminary architecture for packet routing on a Dualog-enabled boat computer. This document specifically assumes linux, however ipfilter seems the only Linux dependent module. If this could be replaced on windows, relying on IPHelper like approaches, then our router will be platform independent.

The router as we see it contains a number of subsystems, each concerned with a specific level of detail. These have been chosen in order to optimize the throughput and avoid unnecessary authentication. (For instance we do not want to authenticate every packet, we rather want to do this at the connection level).

It also leaves open which protocol is used over a specific tunnel, as long as the end-result ends in an ip-packet.

Figure 1: The architectural idea behind the proposal for a ship to shore communication layer
Image architecture-linux

1.1.2 Communication control: Packets

The first level that interest us is the control and alteration of packets such that we can forward them over a tunnel, deliver them locally, neglect them or alter them. The rules used to filter packets must be set from within the connection control module.

The packet module must support connection detection and connection tracking. When a connection is first created it will contact the connection control module, that will either allow or deny the connection by altering the ruleset used by iptables. This requires the possibility to create a new filter queue that lists 'connection-initiating packets'. For connection oriented connections these can be automatically detected, connections that are inherently connection-less should be verified in a lookup table stating sender and/or receiver rules. Everything falling out of those must be considered as connection initiating.

When a connection is allowed the iptable-rules will be such that packets will be forwarded and handled automatically.

1.1.3 Communication control: Connections

The second level where we want to have control over is which connections are allowed. The connection control module will update the ipfilter rules in order to allow or deny connections. It gets informed by the packet control module when a connection is requested and then it can choose to alter the tables to allow this connection or deny it.

A second task for the connection control module is to manage off-boat tunnels by setting up ipip, ppp or other tunnels. This might include submodules (threads) that listen on specific interfaces for incoming packets.

When changes in the connection state occur (tunnel broken, tunnel created), the router control module must be informed. That one will update the rules regarding connection usage.

Every rule in the connection level control system can require authentication which is a flag that can only be set by the authentication system. From a data-management point of view we believe that the following fields are relevant for connection management.

  1. connection-from
  2. connection-to
  3. protocol
  4. user
  5. host
  6. requires authentication
  7. authentication-established
  8. tunnel x: allowed

1.1.4 Communication Control: Routing Rules

This module decides which tunnels are accessible by whom and controls the routing preferences, relying on LCR tables or rules. These rules will take into account billing information and make sure that roaming will be handled properly. E.g: when on-land, an IPIP tunnel might allow fast communication, allowing everybody on board to surf on Internet freely, but as soon as a fall-back to satellite becomes necessary, only specific personell can use Internet freely. Others might require authentication and will be billed for their usage.

Alterations of rules can occur from various places, including the boat's owner, the Dualog support service (receiving updated LCT tables and realizing them) , the current boat administrator (captain ? :)) and possible others. This module interacts with the authentication system to verify whether certain rules can be altered or not.

1.1.5 Authentication

The authentication module keeps track of

  1. users, both on board and on-shore
  2. hosts
  3. connections created by the user.
This module interacts mainly with the connection control module that will update the specific user/host flags and behave accordingly when a connection is pending. In case the connection control module contacts the authentication module for verification of access, then the authentication module will need to communicate over the standard API towards the originating host and user, if possible.

1.1.6 High level applications

Proxies, local databases, various caches and so on. Store and forward might probably find a place here as well. At the moment this is of little importance. However, two applications that will be running on the 'box' (if there is such a device to be sold) deserves mentioning

  1. a web-application providing user authentication
  2. a rule modifications system for the boat administrator

1.1.7 Application Programmers Interface

Provided through a socket, CORBA service or whatever seems necessary. The API towards the router will give a low level access to the functions provided by the router.

1.2 Applicability of Linux based routers

The presented interpretation of a design is based on the idea that linux iptables will be able to provide the required functionality. To this end we did some digging around and came up with the following points of interest

1.2.1 Tunneling in linux

Tunneling in Linux is fairly straightforward. A simple ipip tunnel (ip packets wrapped in other IP packets but receiving a different stamp) can be created as follows:

1.2.1.1 Machine A

LOCALIP=172.16.17.18
REMOTEIP=172.19.20.21
REMOTENET=192.168.0.0/24
TUNDEV=tundev
TADDR=192.168.1.1
GATEWAY=192.168.1.2

1.2.1.2 Machine B

LOCALIP=172.19.20.21
REMOTEIP=172.16.17.18
REMOTENET=192.168.3.0/24
TUNDEV=tundev
TADDR=192.168.1.2
GATEWAY=192.168.1.1

Commands to create such a tunnel:

iptunnel add ${TUNDEV} mode ipip \ 
remote ${REMOTEIP} \ 
local ${LOCALIP} \ 
ifconfig ${TUNDEV} ${TADDR} \ 
netmask 255.255.255.0 \ 
route add -net ${REMOTENET} gw ${GATEWAY} dev ${TUNDEV}
To cancel the tunnel one enters
iptunnel del ${TUNDEV}
IP Tunnels are standard and most OS's support IP Tunneling. It's a standard RFC http://www.ietf.org/rfc/rfc2003.txt RFC2003. On windows 2000 server IP-IP tunnels are standard as well. According to information found at http://www.isi.edu/xbone/windows2000.html a windows ip-ip tunnel can be enabled through the windows control panel
  1. Open Routing and Remote Access
  2. In the console tree, click the server you use & select Routing Interface
  3. R-click Routing Interface & choose 'New IP tunnel'
  4. In interface name, type a name for the tunnel, and click OK
  5. In the console tree, click IP Routing, r-click General, and then click New Interface
  6. In Interfaces, click the IP-in-IP tunnel you just created
  7. On the Tunnel tab
    1. Local address : IP address of the router
    2. Remote address: IP address of the tunnel endpoint

1.2.2 Address Translation

This is of course not the only problem that needs to be resolved a secondary problem is firewalling the inside world and performing address translation where necessary. This is in the linux world fairly standard. Most programs rely on iptables to perform this function nowadays. A program we investigated is called firestarter and it proved to be a very interesting program. It will connect one interface to another and translate packets from one to the other thereby linking the outside world to the inside and the other way around. The rules resulting from something such as netfilter. This simple function is performed with great ease but the complexity of address translation and proper forwarding should not be underestimated. The ruleset resulting from masquerading quickly becomes long and, despite being readbale, there is a big difference between reading the rules and writing them ourselves.

At the moment the linux kernel has a huge list of modules to do ipfiltering that all perform some function. We cannot expect to reimplement large parts of this in a windows based world. We touch upon two important problems that one must be aware of before proceeding to reimplement existing functionality.

Connection tracking- The first is that packet filter rules needs to understand application level protocols before they can be properly rerouted. A typical example are FTP connections. An FTP connection is established by connecting to the server who will return the port and IP address of the actual data deliverer. Since the FTP server is not aware of the fact that it is being filtered, it will return a wrong IP number. To resolve this the packet filter routines need to understand the FTP protocol and replace the returned address and port with a proxy address.

Packet Mangling- Another problem is that packets can be split in pieces through the routing process. This results in packets that do not contain much useful information, except for the stack that will receive it. Many different modules have been implemented to recognize and properly handle mangled packets.

1.2.3 Firewall Piercing Techniques

A big problem with modern networks is that many of them block unwanted ports. This results in many cases that tunnels cannot be set up using standard approaches. We found a document that explains a very interesting technique to pierce through firewalls using standard protocols and ports (http://www.faqs.org/docs/Linux-mini/Firewall-Piercing.html).

We believe such approaches might be very useful to Dualog, for instance by providing the tunnel endpoint on every possible port.

1.2.4 Allowing, denying connections

In this proposal we are interested in another kind of connection tracking as well. We want the ability to lock, authenticate and allow connections from within the local net before forwarding them. We presented an approach that relies on a layered approach, using iptables to do packet filtereing, putting a conenction level tracker on top of that above which a software decission system is put that will either allow or deny connections. This approach is highly modular and we were lucky to find a open source program that seems to rely on a similar kind of setup, indicating that this approach is feasable. (http://www.nufw.org/index.php3?lang=en). Taken from their website:

A packet is emitted by the client. A user Id is associated to this packet and the autorisation is given on a user and filtering base.

  1. A standard application sends a packet.
  2. The Nufw client sees that a connection is being initiated and sends a user request packet.
  3. The Nufw server queues the packet and sends an auth request packet to the Nuauth server.
  4. The Nuauth server sums the auth request and the user request packet and checks this against a authentication authority.
  5. The Nuauth server sends answer back to the Nufw server
  6. The Nufw server transmits the packet following the answer given to its request.

1.2.5 High level protocol forwarding

Another approach that could be useful is to avoid any ip-packet level translation by only (or also) providing high level protocol forwards. A very useful program to demonstrate the power of this approach is 'redir' (http://sammy.net/~sammy/hacks/).

On a local machine the command:

redir -lport 9877 -cport 80 -caddr www.google.com 
will redirect a local webbrowsers' request to port 9877 to the google web server. In general high level protocol translations are only possible in connection oriented environments. It is however unclear which connection less applications will be used because these typically require an IP level address translation that is aware of the protocol being spoken.

2 A Brief Study of the NUFW Architecture

NUFW [1] is a program developed by Eric Leblond <regit@inl.fr> and Vincent Deffontaines <gryzor@inl.fr> that provides single user authentication of network connections. Its elegant design prompted us to investigate the software in more detail. This report describes the overall architecture of NUFW , how to get it working and its current limitations in the setting of ship-to-shore authentication protocols.

2.1 NUFW Overview

Some sections of this document are taken from the NUFW How-To [2]. These sections are marked in italic. We tested version nufw-2.0-beta2 since the previous 'stable' version nufw-1.0.25 did not properly work.

2.1.1 Architecture

Figure 2: The overall architecture of NUFW
\includegraphics[width=1\textwidth]{nufw-architecture}

The overall architecture of NUFW seems similar to the previous document titled 'Preliminary Investigation Linux Box Based Solution'. Figure 2 illustrates the architecture. The software contains 5 different components, some of which optional

  1. Crucial is the Linux Kernel with the Netlink [3]and IPQueue [4, 5] modules enabled and loaded. This allows for a clear socket-link towards iptables from user-land. The iptables will be used to redirect every connection establishing packet (SYN) to a separate queue. The NUFW connection daemon will then make a decision and either drop the packet or allow it through.
  2. The NUFW connection daemon connects to the NUFW authentication daemon on one side and to the kernel on the other side. It authenticates connections by stopping or passing through packets that create connections.
  3. The NUFW Authentication Daemon gathers credentials from users to allow certain connections. It connects with 1 or more NUFW connection control daemons, a database for logging connection activity and one or more Authentication Clients. The authentication daemon can both push and pop 'credential' packets.
  4. The NUFW Authentication Client. This process must be run by the various users. It will provide one or more authentication clients with the proper credentials to set up specific connections.
  5. The Logging Database. The NUFW authentication client can log connections into a standard database (MySql [6], PostgreSql [7]). At the moment there seems no packet counting mechanism in place.

2.1.2 Work-flow
Figure 3: The data flow between various components to set up an allowed connection.
\includegraphics[width=1\textwidth]{nufw-comunciation-flow}

Assuming that the user started an NUFW Authentication client, then the process of setting up a connection can be broken down in smaller pieces. These are presented in the control flow diagram of picture 3. The picture uses a sort of message sequence diagram, loosely based upon UML. We added some notation to support threads and better illustrate the state of concurrent processes. The top line of each message diagram contains the names of the relevant actors. Below every actor we find a vertical line, which represents a (virtual) thread/process. This line is drawn depending on the thread/process state.

  1. If no execution stack is present, no line is drawn.
  2. If an execution stack is present and executing, a full line is drawn.
  3. If an execution stack is present but not executing because it is waiting for any thing to happen, a dotted line is drawn. This means that virtually anybody can re-initiate the execution.
  4. If an execution stack is present but not executing because it is waiting for some specific thing to happen, a vertical line with horizontal dashes is drawn. A specific thing can be, for example, waiting for a return of a message.
If the control flow jumps from actor to actor, we draw horizontal lines. On the line we put a description of the message. More information on these diagrams can be found in [8]. Typically NUFW authentication requires multiple steps This process only happens for the first connection packet of a TCP connection. All other packets in the connection will be passed through immediately, imposing no overhead at all on the connection.

2.2 Downloading & compiling NUFW

From the NUFW How-to [2]: Extract the source to the directory of your choice and go to the created directory. NUFW uses autoconf [9] and automake [10] for compilation and a standard configure script is provided. Above standard options, the following flags are provided :

A detailed list of the options is available via
$./configure -help
Thus you can run ./configure with the options you want and launch compilation and installation:
$ ./configure -with-ldap -with-system-auth -with-mysql-log \ 
  -sysconfdir=/etc/nufw/ -with-debug 
$ make 
$ su # make install
We use debug flags as we want to have all messages for testing the whole setup.

2.3 A one machine multi-user setup

A setup allowing multiple users on one machine to have different access rights can be done in a couple of steps. We discuss the configuration of the various modules.

2.3.1 Kernel & IPTables

The kernel needs to support IPTables [11] and Netlink [3] queue drivers. The NETLINK driver will transfer packets from kernel mode to user mode as requested in IPTables. The module name for the Netlink driver is IP_NF_QUEUE. We have been working with kernel 2.6.13. Remember to load the ip_queue module because NUFW will not warn that the module is not present and IPTables will not deliver the packets to the right place.

In our specific example we blocked two ports, both of which should be authenticated by NUFW before further connections are allowed. These were port 22 (SSH) and port 80 (HTTP). The commands to set up a proper IPTable rule-set merely consist of

iptables -A OUTPUT \ 
         -s 192.168.1.125/32  
         -p tcp  
         -dport 22  
         -m state -state NEW -syn  
         -j QUEUE  
iptables -A OUTPUT  
         -s 192.168.1.125/32  
         -p tcp  
         -dport 80  
         -m state -state NEW -syn  
         -j QUEUE 
iptables -A OUTPUT  
         -m state -state ESTABLISHED,RELATED  
         -j ACCEPT
The first two lines state that any new SYN packet should be placed into the Netlink queue. The last line specifies that all other packets can be delivered to their right address.

2.3.2 Starting NuFw

2.3.2.1 Creating SSL certificates

NuFw can work with multiple authentication daemons ans multiple nufw connection daemons. Since these can run on different machines, a SSL is used. This requires the creation of suitable keys. From the NuFw Howto: Generating your own Certificate authority:

mkdir private chmod 700 private openssl \ 
req -new -x509 -keyout private/CAkey.pem -out private/CAcert.pem
You have to set a strong password here and keep it secret.

Generating nufw and nuauth private keys:

openssl genrsa -out private/nufw-key.pem

openssl genrsa -out private/nuauth-key.pem

Generating Certificate Signing Requests for both nufw and nuauth keys:
openssl req -new -key private/nufw-key.pem -out nufw.csr

openssl req -new -key private/nuauth-key.pem -out nuauth.csr

Having our keys signed by the certificate authority we created:
openssl x509 -req -days 365 -in nufw.csr \ 
-CA private/CAcert.pem -CAkey private/CAkey.pem \ 
-CAcreateserial -out nufw-cert.pem

openssl x509 -req -days 365 -in nuauth.csr \ 
-CA private/CAcert.pem -CAkey private/CAkey.pem \ 
-CAcreateserial -out nuauth-cert.pem

Then copy the files where needed: For nufw:
cp private/nufw-key.pem /etc/nufw/

cp nufw-cert.pem /etc/nufw/

For nuauth:
cp private/nuauth-key.pem /etc/nufw/

cp nuauth-cert.pem /etc/nufw/

And don't forget your key files (here, nufw-key.pem and nuauth-key.pem) should always remain private.

2.3.2.2 Starting the NuFw connection daemon

To start NuFw, simply type

nufw -vvvvvvvvvv
At typical output looks like
root@dig:/usr/src/linux-2.6.13.3# nufw -vvvvvvvvvvvvv 
[07:52:26] [+] Start NuFW 
[07:52:26] [+] NuFW started 
[07:52:26] Try to connect to netlink (IPQ) 
[07:52:26] [+] Packet server started 
[07:52:31] AUDIT: rx=0 tx=0 track_size=0 list=empty 
[07:52:36] Not connected, trying TLS connection 
[07:52:36] Treatment time for connection: 1146729156621.1 ms 
[07:52:36] AUDIT: rx=1 tx=0 track_size=1 list=one packet or more 
[07:52:41] AUDIT: rx=1 tx=0 track_size=0 list=empty 
[07:52:46] AUDIT: rx=1 tx=0 track_size=0 list=empty 
[07:52:51] AUDIT: rx=1 tx=0 track_size=0 list=empty 
[07:52:56] AUDIT: rx=1 tx=0 track_size=0 list=empty 
[07:53:00] Not connected, trying TLS connection 
[07:53:00] Connection to nuauth restored 
[07:53:00] [+] Start auth server thread 
[07:53:01] AUDIT: rx=2 tx=0 track_size=1 list=one packet or more 
[07:53:06] AUDIT: rx=3 tx=0 track_size=2 list=one packet or more 
[07:53:11] AUDIT: rx=3 tx=0 track_size=2 list=one packet or more 
[07:53:16] Treatment time for connection: 1146729196239.8 ms 
[07:53:16] Packet without a known ID: 3972479296 
[07:53:16] AUDIT: rx=3 tx=1 track_size=0 list=empty 
[07:53:20] Treatment time for connection: 1146729200712.0 ms 
[07:53:21] AUDIT: rx=4 tx=1 track_size=0 list=empty 
[07:53:23] Treatment time for connection: 1146729203731.8 ms 
[07:53:26] AUDIT: rx=5 tx=1 track_size=0 list=empty 
[07:53:29] Treatment time for connection: 1146729209678.0 ms 
[07:53:31] AUDIT: rx=6 tx=1 track_size=0 list=empty 
[07:53:36] AUDIT: rx=6 tx=1 track_size=0 list=empty 
[07:53:41] AUDIT: rx=7 tx=1 track_size=1 list=one packet or more 
[07:53:41] Treatment time for connection: 1146729221737.1 ms 
[07:53:46] AUDIT: rx=7 tx=1 track_size=0 list=empty 
[07:53:51] AUDIT: rx=7 tx=1 track_size=0 list=empty 
[07:53:56] AUDIT: rx=7 tx=1 track_size=0 list=empty

2.3.3 Authentication setup

The second process is starting authentication daemons on various machines. The two main purposes for the existence of separate authentication and connection daemons seems to be speed and distribution. By separating the connection module from the authentication and logging, one can put in any heavyweight authentication protocol one might wish for. The connection daemon will not notice any of this and simply provide yes or no answers to connection requests. Similarly, the authentication daemon can be ran on (many) other machines.

Taken from the NUFW How-To [2]: NUFW sources provide a sample configuration file for nuauth nuauth.conf which is available in the conf directory. The two most important configuration variables are : nuauth_client_listen_addr which sets the address where nuauth listens for client requests and nuauth_nufw_listen_addr which sets the address where nuauth listens for nufw requests. The list of nufw servers authorized to connect to server nuauth is the nufw_gw_addr. The next thing to do after setting this variable is to choose your authentication and ACL checking module. Authentication module for user has to be chosen from :

  1. libldap : user credentials are stored on a LDAP server
  2. dbm : user credentials are stored in a gdbm
  3. plaintext : user credentials are stored in a text file
  4. system : authentication is done against PAM and groups are system groups. This provides a convenient way to use nss features and/or pam-modules
This is set with the option nuauth_user_check_module which default is libsystem (if not set in config file). Further choice for the acl checking module has to be done if you choose :
  1. libldap
  2. plaintext
by setting the variable nuauth_acl_check_module.

To be able to proceed quickly to test, we will use the system module for user and the plaintext module for acl. A sample file for the plaintext acl check module is available in the conf directory, acls.nufw. Copy it to /etc/nufw and adjust the group of the ssh acl to have it matching the group of a system user you will use later to authenticate on the system.

In our specific test we have been using libsystem for authentication and libplaintext for access control. In the configuration file /etc/nufw/nuauth.conf the following directives were set.

nuauth_user_check_module="libsystem"

nuauth_acl_check_module="libplaintext"

nuauth_ip_authentication_module="libipauthident" 

plaintext_userfile="/etc/nufw/users.nufw"

plaintext_aclfile="/etc/nufw/acls.nufw"

The file /etc/nufw/acls.nufw contained in our situation the following. The first user has gid 1005, the second user had group if 1007.
[ssh-user1]  
decision=1  
gid=1005  
proto=6  
SrcIP=0.0.0.0/0  
SrcPort=1024-65535  
DstIP=0.0.0.0/0  
DstPort=22  
App=/usr/bin/ssh  
OS=Linux 
 
[ssh-user2]  
decision=0  
gid=1007  
proto=6  
SrcIP=0.0.0.0/0  
SrcPort=1024-65535  
DstIP=0.0.0.0/0  
DstPort=22  
App=/usr/bin/ssh  
OS=Linux 
 
[web-user1]  
decision=0  
gid=1005  
proto=6  
SrcIP=0.0.0.0/0  
SrcPort=1024-65535  
DstIP=0.0.0.0/0  
DstPort=80 
 
[web-user2]  
decision=1  
gid=1007  
proto=6  
SrcIP=0.0.0.0/0  
SrcPort=1024-65535  
DstIP=0.0.0.0/0  
DstPort=80 
This file is based on the sample file found in the source distribution conf/ directory. Starting nuauth gives:
root@dig:/home/werner# nuauth -vvvvvvvvvv  
** Message: debug_level is 9  
** Message: Problem with certificate trust file : Error while reading file.  
** Message: [+] Starting nuauth  
** Message: Loading user checking modules:  
** Message:     module libsystem: using libsystem with confi gfile (null)  
** Message: Loading acls checking modules:  
** Message:     module libplaintext: using libplaintext with configfile (null)  
** Message: Loading define periods checking modules:  
** Message:     module libxml_defs: using libxml_defs with configfile (null)  
** Message: Loading user packet logging modules:  
** Message:     module syslog: using syslog with configfile (null)  
** Message: Loading user session logging modules:  
** Message:     module libsyslog: using libsyslog with configfile (null)  
** Message: Loading certificate check modules:  
** Message:     module libx509_std: using libx509_std with configfile (null)  
** Message: Loading x509 std configuration  
** Message: Loading certificate to uid modules:  
** Message:     module libx509_std: using libx509_std with configfile (null)  
** Message: Loading x509 std configuration  
** Message: Error reading period: Failed to open file '/etc/nufw//periods.xml':  
No such file or directory  
** Message: creating acl cache thread  
** Message: Creating search_and_fill thread  
** Message: Creating 3 acl checkers  
** Message: Creating 3 user checkers  
** Message: Creating 2 user loggers  
** Message: Creating 2 user session loggers  
** Message: Creating 2 decision workers  
** Message: Creating tls authentication server thread  
** Message: Creating tls nufw server thread  
** Message: Threads system started  
** Message: [+] NuAuth started.  
** Message: [+] NuAuth is waiting for client connections.  
** Message: [+] NuAuth is waiting for NuFW connections.  
** Message: Bad password for user "werner"  
** Message: sasl negotiation error: -20

** (process:28519): WARNING: werner@nufw at 192.168.1.125  is a badguy  
** Message: [+] User "werner" connected.  
** Message: Clean connection list: 1 connection(s) suppressed  
** Message: [nuauth] Drop [werner] 1146734440 :  
SRC=192.168. 1.125 DST=207.126.111.225 PROTO=6 SPT=60655 DPT=80  
** Message: [+] NuFW: new client connected on socket 8  
** Message: [plaintext] read_acl_list: reading [/etc/nufw/ac ls.nufw]  
** Message: [plaintext] matching with decision 1  
** Message: [plaintext] Checking for OS sysname=[Linux]  
** Message: [plaintext] OS match (Linux)  
** Message: [plaintext] Checking for App=[/usr/bin/ssh]  
** Message: (DBG) Checking App ACL found=1  
** Message: [plaintext] App match (/usr/bin/ssh)  
** Message: [plaintext] matching with decision 0  
** Message: [plaintext] Checking for OS sysname=[Linux]  
** Message: [plaintext] OS match (Linux)  
** Message: [plaintext] Checking for App=[/usr/bin/ssh]  
** Message: (DBG) Checking App ACL found=1  
** Message: [plaintext] App match (/usr/bin/ssh)  
** Message: [plaintext] matching with decision 1 

2.3.4 Client Authentication

Now before a client can connect he needs to authenticate himself. In our case we chose to use the systems module for authentication, which means that the user names and password are verified against the standard password file. Nevertheless, the authentication client still needs to be started. This is done with

nutcpc -d -H [IP of uAuth server] 
nutcpc -d -H 192.168.1.125
In our case this was somewhat problematic because the nuauth server was listening to all interfaces (127.0.0.1, 192.168.1.125 and 10.0.0.9). If we tried to connect to the local authentication daemon 127.0.0.1, this would succeed, but as soon as the first connection request was sent we would get the response: 'authentication client at 127.0.0.1 authenticated a connection for 192.168.1.125'. The only way to solve this was to connect to the actual 192.168.1.125 address, instead of the localhost.

2.4 Setup on a firewall

We must take into account the information provided in the NUFW FAQ [12], namely.

How does NUFW react to Network Address Translation ? There are two kinds of NAT : Source NAT and Destination NAT. Source NAT is used when source IP of the first packet of a connection is modified, Destination NAT is used when the Destination IP of the first packet of a connection is modified. NUFW cannot cope with Destination NAT because, on one hand, the packet sent to the gateway is changed before it reaches NUFW , on the other hand, the data describing the packet contained in the user authentication packet are not (and cannot be) changed by the NAT. However, it is possible and secure to chain a NUFW gateway with another gateway and perform Destination NAT on the second gateway. So NUFW and Destination NAT are not compatible but Destination NAT can?t be used to cheat NUFW . NUFW works fine with Source NAT, provided Source NAT is performed on the same machine as NUFW , or another machine, but not a host between NUFW server and the client.

2.5 Conclusion

NUFW is a well written program that demonstrates some of the architectural decisions necessary to develop/deploy of a per user authentication system. Whether we actually need a 'per-user' authentication system is unclear. In case we don't need it we might rely on a somewhat simpler, per machine authentication system. The architecture itself is fast (only the initial packets are checked), modular and extensible.

Three parts of the software are at the moment highly platform specific:

  1. The NUFW daemon only works on Linux machines. In windows we would need to create a windows driver similar to netlink, ipq and associated iptable rules
  2. How does NUFW determine which user is setting up a connection ? There is a windows client available, but I believe that this is not such a straightforward client since the NUFW authentication client seems to track which port is opened by whom.
  3. Endianity: the NUFW software relies on Intel specific endianity, so Macintosh users are left to write drivers for themselves :)
The current connection daemon seems unable to count packets per connection at the moment.

The good sides of the current software architecture are its modular authentication and ACL accounting. It supports logging, authenticating with various modules. One of those is PAM. PAM is a very convenient way for extending authentication to "exotic" directories. In particular, PAM lets one interface nuauth on NT domains, Active Directory, Radius, etc. Since NUFW supports PAM authentication, it forms a very viable approach towards authentication.

3 The Dualog Stack

3.1 Introduction

The Dualog stack should provide a platform independent protocol stack that offers efficient address translation (shielding the inner boat from the bad world outside), efficient forwarding over a wide variety boat-land connections, some form of interface that allows a per user authentication and accounting of all incoming/outgoing UDP/IP [13]and TCP/IP [14, 15] connections. The Dualog stack, as envisioned now, consists of a number of modules, each with specific responsibility. The main challenge lies in finding a set of modules (supported in both worlds) that can be easily altered through a user-land API. This document names those modules, describes their responsibility, their support in Windows/Linux and provides information on the programmers interface towards these modules.

Figure 4: The Dualog Stack
\includegraphics[width=0.9\textheight,angle=90]{the-dualog-stack}

3.2 The Stack

Figure 4 presents an overview of the stack. The right side of the picture is mainly located in kernel space. The left side of the picture will provide a uniform interface to alter the stack behavior and is located in user-space. The following subsections correspond to specific modules in the picture.

3.2.1 Links

The devices used within the system are either inward Ethernet devices or outward devices, such as Ethernet, modem, etc. The inward devices communicates towards the boat internal network, the outward devices, through various channels, will all connect to the Dualog haven. In Linux these devices tend to be called /dev/eth0, /dev/eth1. In Windows [16] these devices are called 'network interfaces'.

Most devices will be associated with an IP tunnel [17, 18], that will wrap incoming packets, send them over a specific transport medium and unwrap them at the other side. The IP Tunnels are based on a standard protocol, supported both by Windows and Linux.

The combination of device and IP tunnel is called a link. The interaction between most drivers interacting on the stack is very likely through a shared memory accessing the stack.

3.2.2 Mobile IP

When a device becomes available, the Mobile IP [19] layer will create a tunnel. All available tunnels will be used for off-ship data transmission. As we see it now, the Secgo [20]software will provide the software. It supports both Windows [16]and Linux. In Windows it is available through an NDIS [21]driver. In Windows this process very likely goes though a kernel module [22]. A socket provides the channel over which to reach the Secgo API. It provides status information on link usage, among which notification of new links and dead links. Bandwidth limitation can be altered through this API as well.

3.2.3 Network Address Translation / Masquerading

Network address translation [23, 24] is necessary for translating 'inside the boat' - packets to 'outside the boat'-packets and vice verca. Because connection filtering is based on connections, network address translation might interfere with its proper working. Therefore our NAT module must be placed after the packet filter (as seen on picture 4). As such, if the Dualog NAT module receives a packet going outward, then it can assume that the connection is allowed.

In Windows, NAT can be achieve through using the Windows Firewall [25]. In Linux, IP-Tables [11] can be used for this purpose. The address translation is responsible for keeping track of state information such as necessary for FTP connections. Very likely we will not need to alter the behavior of this module.

3.2.4 Packet Stopper

The packet stopper is probably the most important, yet difficult module, to create. It should be able to manage connections by sending out 'connection requests' when the first packet of a connection arrives as well as sending out 'connection dead' notification when a connection dies. It should be possible to alter the behavior of the packet filter in such a way that it can stop or pass packets (based on a specified bandwidth limitation). Important connection attributes are

  1. source & destination IP's
  2. source & destination ports
  3. type of packet (SYN vs ...)
  4. protocol (TCP/UDP, ...)
The interface towards the packet filter should allow runtime changes of the filter rules and back notification of the specified events.

3.2.4.1 Linux

In Linux a packet stopper can easily be achieved through a combination of IP-Tables [11], IPQ [5, 4] and NetLink[3]. User-space event notification can be realized as described in the previous document titled 'A Brief Study of the NuFw Architecture'.

3.2.4.2 Windows

In Windows a packets stopper can be implemented at various stages. Information on Windows packet filtering and various hooks can be found at [26], including documentation on the Windows 2000 Packet Filtering Interface (user-space possibility to stop or pass through packets), NDIS Intermediate Driver development, the Windows 2000 Filter-Hook Driver and the Windows 2000 Firewall-Hook Driver.

For our purposes, the WIPFW [27] software seems a promising candidate. It is implemented through a firewall hook [28](is this correct ? Is this not a Windows filter hook ?). Altering of the stop/pass rules can be done using a command line interface (CLI), back notification can be achieved at the logging level. The WIPFW does not allow rewriting of packets and thus will not allow packets to be redirected. It also does not allow for bandwidth limitations on specified packet types.

3.3 Location, Link & Connection management

The presented stack requires a high level of interaction with the rest of the system. Depending on the location and available links we will have different rules regarding who is allowed to make which connection or not. This document is not concerned with the rule system at the moment. However, we need to supply a standardized user-space API to allow realisation of a least cost routing/high control system. Two aspects are crucial. First: the LCR system needs a way to set up links. Secondly, the least cost routing system needs a way to specify which connections are allowed. Both behaviors are located at different places in the stack and will thus be presented by two different user-space processes. Those processes are essentially unification modules, translating a (possibly) platform specific API to the bare decision rules needed by the actual kernel section.

3.3.1 Connection Control

With connection we typically mean a TCP/IP connection. How UDP/IP 'connections' are handled is fairly unclear at the moment given the connectionless nature of UDP. The connection control module provide three different services to the LCR.

  1. It will provide a push service that, based on information it receives from the LCR, sets up a suitable rule-set and realizes it in the Dualog Stack.
  2. It will provide a mechanism to request from the LCR system credentials whenever somebody starts using a connection that is not allowed (pull mechanism). This might require the possibility to redirect non-allowed connections.
  3. It will provide logging information for all connection (bandwidth used, time the connection has been actively used, size of the entire transmission and so on.)
The connection control module should also support full rule-set switches, thereby determining which connections should be disconnected and which ones should be kept.

3.3.2 Link Control

The link control provides a uniform interface to alter links: bring them up, shut them down, change bandwidth usage and so on. Two behaviors are necessary

  1. when the LCR decides to set up a link or bring it down, the link control module needs to realize this in the stack.
  2. when important status changes occur in the links (a broken link for instance), the LCR should be informed.

3.4 Remaining Challenges

  1. At the moment it seems somewhat confusing in which order packets are going through the Windows IP stack. There seems a number of hooks to be available (the firewall filter hook, the packet filter hook and the NDIS driver 'hook'). Where those are located is unclear and whether address translation occurs before packet filtering is something to find out. A small demonstrator indicates that the address translation will actually occur after the packet filtering.
  2. The packet filter can easily detect the creation of TCP connections by intercepting SYN packets. There is however no clear alternative to UDP packets. One can simply deny UDP packets from any source to any other source and use the logging mechanism to detect the 'creation' of a connection. There will of course be no 'disconnect' either, so this remains a challenging problem.
  3. The WIPFW software cannot do bandwidth control of connections and cannot change the contents of packets. This could be useful to redirect connections to a local 'authentication' server before allowing the connection through.
  4. There seem large difference in the way filter rules are changed in IP-Tables [11] and in WIPFW. Especially, regarding the notification of stopped packets.
  5. The Secgo [20] Mobile IP stack does not allow per user tunnel use.
  6. We seem to forgetting the delicate interaction between NAT, connection state tracking and allowing/denying connections. E.g: when an FTP connection is allowed then so must its sister port - automatically. To achieve this we must implement state tracking in our packet stopper, or elsewhere.

3.5 Glossary

4 IPTables: User Kernel Link

4.1 User To Kernel

This document reports on the link between user programs and kernel when altering netfilter behavior.

4.1.1 IPTables command

The iptables command we relied on was version 1.3.3 as found in the upstream section of the Debian source distribution. The command is mainly implemented in one big chunk of C (iptables.c or ip6tables.c), which for the largest part concerns itself with command line option checking. A nifty cross-table ensures that only right combinations are recognized.

static char commands_v_options[NUMBER_OF_CMD][NUMBER_OF_OPT] = 
{ /* -n -s -d -p -j -v -x -i -o -f -line */  
/*INSERT*/ {'x',' ',' ',' ',' ',' ','x',' ',' ',' ','x'},  
/*DELETE*/ {'x',' ',' ',' ',' ',' ','x',' ',' ',' ','x'},  
/*DELETE_NUM*/{'x','x','x','x','x',' ','x','x','x','x','x'},  
/*REPLACE*/ {'x',' ',' ',' ',' ',' ','x',' ',' ',' ','x'},  
/*APPEND*/ {'x',' ',' ',' ',' ',' ','x',' ',' ',' ','x'},  
/*LIST*/ {' ','x','x','x','x',' ',' ','x','x','x',' '},  
/*FLUSH*/ {'x','x','x','x','x',' ','x','x','x','x','x'},  
/*ZERO*/ {'x','x','x','x','x',' ','x','x','x','x','x'},  
/*NEW_CHAIN*/ {'x','x','x','x','x',' ','x','x','x','x','x'},  
/*DEL_CHAIN*/ {'x','x','x','x','x',' ','x','x','x','x','x'},  
/*SET_POLICY*/{'x','x','x','x','x',' ','x','x','x','x','x'},  
/*CHECK*/ {'x','+','+','+','x',' ','x',' ',' ',' ','x'},  
/*RENAME*/ {'x','x','x','x','x',' ','x','x','x','x','x'} }; 
The insert command inserts one or more rules in the selected chain. The delete and delete_num commands delete rules based on patternmatching or by number. The replace rule replaces a specific rule number with another one. Append appends a rule to a chain. The list dumps all the rules to the terminal. Flush empties the selected (or all) chains. Zero clear the packet and byte counter in all chains. new_chain and del_chain create/delete chains. The set_policy command sets the target for the chain. If the end of a built-in chain is reached or a rule in a built-in chain with target RETURN is matched, the target specified by the chain policy determines the fate of the packet.

A specific target of interest is QUEUE. QUEUE means to pass the packet to user space. How the packet can be received by a user-space process differs by the particular queue handler. 2.4.x and 2.6.x kernels up to 2.6.13 include the ip_queue queue handler. Kernels 2.6.14 and later additionally include the nfnetlink_queue queue handler. Packets with a target of QUEUE will be sent to queue number '0' in this case. Please also see the NFQUEUE target as described in the iptables manpage. The rename command is aesthetic.

From these commands we are mainly interested in the ones that update the kernel behavior: insert, delete[_num], replace, append, zero, new_chain, del_chain en set_policy. All options are parsed and appended onto internal structures, such as the command flag. Those structures are afterward analyzed and the proper internal functions called. Among these:

switch (command) 
{ 
case CMD_APPEND: ret = append_entry(... 
case CMD_DELETE: ret = delete_entry(... 
case CMD_DELETE_NUM: ret = iptc_delete_num_entry(... 
case CMD_REPLACE: ret = replace_entry(... 
case CMD_INSERT: ret = insert_entry(... 
case CMD_ZERO: ret = zero_entries(... 
case CMD_NEW_CHAIN: ret = iptc_create_chain(... 
case CMD_DELETE_CHAIN: ret = delete_chain(... 
case CMD_SET_POLICY: ret = iptc_set_policy(... 
...

zero_entries, append_entry, replace_entry and insert_entry translate to the same identifiers prefixed with iptc_*.

Those functions are not defined in the iptable command and seem declared in the standard header file /usr/include/libiptc/libiptc.h.

4.1.2 LibIptc

In Debian LibIptc is part of the iptables-dev package, which includes only the static compiled version. The source code can be found in the iptables source package in the /iptables-1.3.3/upstream/iptables-1.3.3/libiptc directory. The libiptc.c file is around 2274 lines but is somewhat more complex. It seems to mange the internal list representation and tracks all changes in a shared memory, which, if something changes is committed to the kernel within the TC_COMMIT function. All the rules and chains are compiler by the iptcc_compile functions which are then send to kernel with a sockopt call.

setsockopt(sockfd, IPPROTO_IP, 
  IPT_SO_SET_REPLACE , repl, 
  sizeof(*repl) + repl->size)
The sockfd descriptor is known through
sockfd = socket(AF_INIT, SOCK_RAW, IPPROTO_RAW)

4.1.3 Kernel

The setsockopt call translates to a kernel function which expects the following structure (as defined in ./include/linux/netfilter_ipv4/ip_tables.h)

/* The argument to IPT_SO_SET_REPLACE. */  
struct ipt_replace {  
/* Which table. */  
char name[IPT_TABLE_MAXNAMELEN];

/* Which hook entry points are valid: bitmask. You can't change this. */  
unsigned int valid_hooks;

/* Number of entries */  
unsigned int num_entries;

/* Total size of new entries */  
unsigned int size;

/* Hook entry points. */  
unsigned int hook_entry[NF_IP_NUMHOOKS];

/* Underflow points. */  
unsigned int underflow[NF_IP_NUMHOOKS];

/* Information about old entries: */  
/* Number of counters (must be equal to current number of entries). */  
unsigned int num_counters;  
/* The old entries' counters. */ 
struct xt_counters __user *counters;

/* The entries (hang off end: not really an array). */  
struct ipt_entry entries[0];  
}; 

The rules are defined as
/* This structure defines each of the firewall rules.  
Consists of 3 parts which are  
1) general IP header stuff  
2) match specific    stuff  
3) the target to perform if the rule matches */ 
struct ipt_entry {          
struct ipt_ip ip;

/* Mark with fields that we care about. */      
unsigned int nfcache; 
/* Size of ipt_entry + matches */          
u_int16_t target_offset;          
/* Size of ipt_entry + matches + target */          
u_int16_t next_offset; 
/* Back pointer */          
unsigned int comefrom;

/* Packet and byte counters. */          
struct xt_counters counters;       
/* The matches (if any), then the target. */          
unsigned char elems[0];  
};

The actual code associated with a replace can be found in /usr/src/linux-2.6.13.3/net/ipv4/netfilter/ip_tables.c, the do_replace function. This function will 'translate' the incoming table and load modules as necessary.
iptable_filter.ko 
iptable_mangle.ko 
iptable_nat.ko
The translation step (translate_table fnction in ip_tables.c) is merely a sanity check which will update the table associated with iptable_filter, iptable_mangle or iptable_nat. The specific modules provides hooks into the table evaluation to make decisions or alter packets as they come along. The ipt_do_table function provides the general rule matching.

4.2 Kernel To User

As previously described the kernel to user space link is easier. A QUEUE target will place any packet into a special connection, which can be approached with lipipq. The packets are wrapped into a structure defined in /usr/include/libipq/ip_queue_64.h. The headers can be found in /usr/include/libipq/libipq.h and are to a large extent self explanatory.

4.3 Conclusion

This document described the current 'user to kernel' link regarding iptables. Since the format is very specific for Linux and rather extensive it seems that copying this interface into an NDIS driver might require too much work. It is probably better to design a set of rules as necessary and then to translate these into iptables rules.

5 Using rsync as a remote update protocol for ship-to-shore communication

In this document we describe the use of rsync as a means to update operating systems between ship and shore, an environment where bandwidth is of utmost importance.

5.1 Introduction

Taken from the documentation: ``The rsync remote-update protocol allows rsync to transfer just the differences between two sets of files across the network connection, using an efficient checksum-search algorithm described in the technical report that accompanies this package.'' The checksum algorithm itself relies on a combined approach of weak (but fast) checksums and strong (but slow) checksums.- When the weak checksums fail, then two blocks are considered different and thus the strong checksums will not be used. Otherwise, the strong ones must match before two blocks are considered to be equal. This two-pronged approach allows rsync to make appropriate decisions on how a block should be transmitted: if a new updated block is similar to any already available block (found in the base-files) then only a reference to that block is transmitted. This prompted us to investigate rsync into slightly more detail as a means to transfer and update the Dualog system without needing to transmit all the data.

5.2 Setup

An especially interesting capability of rsync is that it is possible to fake the remote side locally, meaning that the rsync-diff can be generated entirely at the sending side, then compressed, transmitted and at the receiver side it can automatically be applied. We tested such scenario as follows.

Using VMware we created a Windows XP partition of 2G in a Local directory. This VMware file (called a .vmdk) was then copied to two other directories: a Fake directory and a Remote directory. Our goal was now to verify whether we could create a rsync-diff based on the Local and Fake one, which could then be applied onto the Remote directory. The script to create the local diff:

#!/bin/bash 

rsync -xavy -delete-after -only-write-batch=remote-update Local/ Fake/

Executing this script will create two files called remote-update and remote-update.sh. After opening the VMware windows image and closing it again, we were interested to find the differences between the two files, which lead to an update script of 7.8 Mb uncompressed. After compressing this file with rzip, the differences were around 1.2 Mb, which is a compression ration of 0.0585%.

To aplpy the diff at a certain location we can use the following script. It should be called with an argument specifying the directory to which to apply the diff.

#!/bin/bash

rsync -xavy -delete-after -read-batch=remote-update ${1:-Fake/} 

Of course, this simple test does not take into account any knowledge we might have about specific files (files that should not be updated). Rsync is also capable of performing the same task on a file-system that is not 'one image', however one should be aware that updating files on a running system might not be the smartest thing to do. Therefore we propose the following scenario for one directional updates.
  1. The shore keeps both a Local and Fake directory. The Fake directory should always be consistent with the version available on the ship.
  2. The shore can update the remote system in the Local directory.
  3. To prepare the actual update, rsync is used, the diff file compressed.
  4. The diff is transmitted (whole or in part). Here it is appropriate to note that truncated diff-files' do not form any problem for rsync. There is however a drawback in that the running system might be in a half-half state, so we further assume that we only apply updates once they have been fully correctly transmitted.
  5. The receiver (/the ship)
    1. stops all the Dualog services
    2. applies the rsync-diff
    3. acknowledges the update success or revert the system back to its old state with an error report
  6. When the shore receives notification that a specific update has been successfully applied, then the update is applied against the Fake directory as well.
Figure 5 illustrates this process. A realization of the above script can be done to have two directional updates, where both the ship and the shore can modify specific data on the running system. This process is depicted in figure 6. The idea in such a processes that specific parts of the file system can only be modified by either the shore, or by people on the ship (yellow versus purple).
Figure 5: A one directional update system
\includegraphics[width=1\textwidth]{OnedirectionUpdate}

Figure 6: A two directionally update system
\includegraphics[width=1\textwidth]{TwoDirectionUpdate}

5.3 Possibilities

Aside from the capabilities to transmit only differences, a number of extra features of the standard rsync could be used in Dualog for other practices as well.

5.3.1 Decremental Backups

One of them is the possibility to store backup files of the files that are updated. This could make it possible to backup the old Dualog system by means of decrements instead of increments. A script for doing so is given below

cd /backups backup_dir=`date +%F-%T`

decrement="decrements/<machine>/"$backup_dir"/" 

mkdir -p $decrement 

decline="-backup -backup-dir=/backups/"$decrement 

local_backup="-xav -delete "$decline

rsync $local_backup"<disk>" -exclude '<filepattern>' / <machine>/<disk>

The script assumes that all local disks are mounted under /machine/disk directories. The decrements will be stored in the director y 'decrements'. Each subdirecftory will have a timestamp datnig back to the moment the file was modified or pushed out.

5.3.2 Detecting system alterations.

Since the suggested process involves an entire fake mirror of the state that should be on board of the ship, it is possible to verify which files have been altered without Dualog involvement. Essentially rsync does not provide such a feature since it involves checking the md4 checksum of all files. As I understand it now, this is not done and only for changes will such a thing be done. However, standard tools such as md5sum might still be a viable alternative.

5.4 Drawbacks of Rsync

Rsync is unable to find shifts in files. When a data-stream receives inserts rsync will not be able to find any matching block. It seems that this was artificially introduced in the algorithm to avoid non matching blocks that would have the same checksum ?

Bibliography

1.Nufw, now user filtering works E. Leblond, V. Defontaines Tech. rep., INL Security and Free Software, 2005-2006 http://www.nufw.org/
2.Nufw howto E. Leblond, V. Defontaines Tech. rep., INL Security and Free Software, 2005-2006 http://www.nufw.org/docs/howto.html#id2453545
3.Kernel korner - why and how to use netlink socket He, K Linux Journal; May 2005 http://www.linuxjournal.com/article/7356
4.The netfilter.org "libnetfilter_queue" project H. Welte The netfilter.org project, 1999-2006 http://www.netfilter.org/projects/libnetfilter_queue/index.html
5.LIBIPQ Netfilter Core Team Linux Programmers Manual Ed. 2000-2001 http://www.cs.princeton.edu/~nakao/libipq.htm
6.MySql MySql AB; MySql 1995-2006 http://www.mysql.com/
7.Postgresql 8.1 Postgresql Global Development Group; 1996-2006 http://www.postgresql.org/
8.Automatic Generation of an Intelligent Concurrency Adaptor in order to Mediate the Differences between Conflicting Concurrency Interfaces Werner Van Belle Vrije Universiteit Brussel, 2003, chapter 1.7.3 Conventions, pages 20-21/300 http://werner.yellowcouch.org/Phd/PhdOnTheWeb/node4.html#SECTION01373000000000000000
9.Autoconf http://www.gnu.org/software/autoconf/
10.Automake http://www.gnu.org/software/automake/
11.The netfilter.org "iptables" project H. Welte, J . Kadlecsik, M. Josefsson, P. MChardy, Y. Kozakao, J. Morris, M. Boucher, R. Russell The netfilter.org project http://www.netfilter.org/projects/iptables/index.html
12.Nufw frequently asked questions E. Leblond Tech. rep., INL Security and Free Software, February 2005 http://www.nufw.org/Frequently-Asked-Questions.html
13.User datagram protocol J. Postel RFC768; August 1980 http://www.faqs.org/rfcs/rfc768.html
14.A protocol for packet network intercommunication V. Cerf, R. Kahn IEEE Transactions on Communications COM-22, 5; pages 637-648; May 1974
15.Transmission control protocol, darpa internet program protocol specification J. Postel RFC 793; September 1981 http://www.faqs.org/rfcs/rfc793.html
16.Microsoft Windows Family Homepage Microsoft Cooperation; 2006 http://www.microsoft.com/windows/
17.Generic packet tunneling in IPv6 specification A. Conta, S. Deering RFC2473; December 1998 http://rfc.net/rfc2473.html
18.Ip in ip tunneling W. Simpson RFC 1853; October 1995 http://rfc.net/rfc1853.html
19.IP Mobility Support for IPv4 Internet Engineering Task Force; Internet Society; 2002 http://tools.ietf.org/html/3344
20.Secgo software - just between us Secgo Software Oy; 2006 http://www.secgo.com/
21.Ndis- network driver interface specification, 2006 Technical Report Microsoft http://www.microsoft.com/whdc/device/network/ndis/default.mspx
22.The Windows 2000 Device Driver Book A. Baker, J. Lozano 2nd edition. Prentice Hall PTR, 2001.
23.Network address translation Wikipedia http://en.wikipedia.org/wiki/Network_Address_Translation
24.Traditional ip network address translator (traditional nat) P. Srisuresh, K. Egevang The Internet Society RFC3022, January 2001 http://tools.ietf.org/html/3022
25.Understanding windows firewall Microsoft Cooperation; August 2004 http://www.microsoft.com/windowsxp/using/security/internet/sp2_wfintro.mspx
26.Windows network data and packet filtering Printing Communications Assoc Inc. Pcausa; March 2004 http://www.ndis.com/papers/winpktfilter.htm
27.The wipfw project U.J. S. Antsilevich, P.H. Kamp, A. Nash, A. Cobbs, L. Rizzo, R. Staritsin, V. Goncharov 2006 http://wipfw.sourceforge.net/
28.An adventure: How to implement a firewall-hook driver? O.J The Code ProjecT: Your Visual Studio .NET Homepage http://www.codeproject.com/internet/FwHookDrv.asp
http://werner.yellowcouch.org/
werner@yellowcouch.org