Date:	Wed, 19 Sep 2007 00:06:49 +0200
From:	Samo Pogacnik <samo_pogacnik@....net>
To:	netdev@...r.kernel.org
Subject: network functionality - SACIP

Hi,

I want to introduce a new network functionality, where established 
network connections could be preserved after the IP address change
of one or both endpoints of communication.

A general document (not yet finished) about SACIP (Session Aware Change
of IP) and the patch are available at:

http://84.255.254.67/sacip-0.1-en.pdf
http://84.255.254.67/patch-linux-2.6.19-sacip

Short implementation description:
---------------------------------
To be able to preserve established network connections based on inet
sockets without the need to modify applications, three things had to
be done:
1. Extension of inet socket structure by additional pairs for rcv_saddr
   and daddr fields and two indexes referring to currently active values
   of both additional pairs.
2. Modifications of the role of original rcv_saddr and daddr parameters
   to stay bound to the upper socket layer only. Their use in the IP
   layer is being replaced by currently active values from newly added
   pairs. On IP address change only IP layer bound parameters get
   changed.
3. Notification about changed IP has been implemented using a separate
   ICMP message, sent for every established socket related to the
   changed IP address. 

Current functionality is the most basic one, so that the implementation 
would be as simple as possible. So, it covers only ipv4, it does not 
address network address translation in the communication path (see 
doc.), it does not address security aspects. Implementation also does 
not allow loosing old address before notifying about IP change at one 
endpoint and does not enable the use of another network interface by 
setting new IP address.

What can it do then? Well, No additional configuration tool has been 
implemented for this, so features of the ip tool (from iproute2 package)
had been used. First by adding a new address to existing interface and
then by deletion of the first primary address, sacip functionality gets
called. And if new address has been added as a secondary address, then 
the promote secondaries kernel feature has to be enabled as well to 
activate sacip functionality by deletion of the primary address.

After the deletion of the first primary address, all tcp established 
sockets as well as all udp and raw sockets are checked, if their
current active source address correspond to old/deleted ip address.
For each socket found an ICMP message containing only new primary
address is sent to the currently active destination address of a socket.
After that new source addres get assigned as currently active on a
local endpoint. 

On receipt of a sacip ICMP message, remote side also checks its
sockets, if their current active destination address equals to the
source address of the ip packet header carrying the sacip icmp message.
Found sockets get assigned new ip address (received in the icmp message)
as current active destination address, afterwards.

After that communication continues using newly assigned ip address, but
the application (telnet for instance) operates as if old address would
still be assigned.

Testing environment:
--------------------
Currently, there are two test set-ups possible. First set-up needs
at least two nodes, and the second possibility is to use special 
loopback network device "snull" (from Linux Device Drivers book) on a 
single node, but in that case additional sacip kernel configuration 
option has to be enabled.
I was able to test both set-ups, but with a very limited set of 
applications. So mostly telnet was used (interactively or by echoing 
some output in a tight loop on remote side, just to generate one way 
stream). Udp NFS on the other hand also did not show any problems, 
except that access rights for new address of a client had to be 
administrated as well.

Security:
---------
I am aware that malicious sacip icmp messages easily break established
connections in current implementation. That is why no original IP 
address is being sent within the sacip icmp message payload (so it is 
a little harder to generate a fake sacip icmp). But that also limits 
functionality, when we'd like to change IP address, after the old 
network looses access.
If some secrets could be exchanged after connection establishment in 
some standard way to identify established sessions on both ends, most 
security concerns could be solved, imho (suggestions are most welcome). 

Possible future:
----------------
1. All missing features (look above).
2. If security would be covered well, research in the direction of
   possible connection transfer to another node would be interesting
   (especially for tcp).

About the patch:
----------------
The appended patch is for kernel 2.6.19 and all changes are directly
in lined under conditional config macros, so that not a single line of
original code would be changed, if sacip stays not configured. 

Any suggestions to separate added code are welcome as well as any other
comments or criticism, regarding the patch and functionality.

regards, Samo




-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists