[Spread-users] changing topology, security, and firewalls

[Jonathan Stanton]

Thanks for the feedback. We really like to know how people are using Spread
and how it can be more useful to them.

On Mon, Apr 01, 2002 at 03:12:54AM -0500, Clark C . Evans wrote:
> Hello.  I have yet to try spread, but I have a question
> about topology changes.  When a new deamon is added to
> the system is there any way to notify the other deamons
> short of changing their configuration file and re-starting
> them?  For instance, can I send a SIGINT and this would
> tell the deamon to re-read its configuration file?

If they are included already in the spread.conf file then the other daemons
will find them automatically. If they are not included in the file, then
currently you do have to restart the daemons with a new spread.conf file. 

A more dynamic way to update the spread.conf file has been requested a
number of times and is something we have looked into. It is not very
easy to get right.

> 
> Secondly, I must say that I'm very interested in security 
> approaches (esp ones with an open source license).   It 
> seems that there are two concerns: (a) secure connections
> between segments, and (b) security within a segment.  From
> what I understand (a) would be a TCP layer connection, where
> (b) is UDP packets.  I suppose the simplest way to cover this
> sort of thing is to use OpenSSL at a layer just above spread
> does this make sense?

The current Spread version that you download only uses UDP, even for
inter-segment messages, so you would need an IP level tunnel instead of a
tcp/http level tunnel. Several people have successfully used IPSEC tunnels
for this purpose with Spread.

Within a segment one can add per-packet encryption using the openssl
crypto libraries to protect the UDP packets within or between segments.

 > 
> Third, I was wondering if communication between segments 
> could be implemented using asymmetric HTTP/HTTPS over port 80/443.  
> This has the distinct advantage of allowing messages to jump 
> over a firewall in small organizations where a system administrator
> is hard to come by (or non-existant).  Yes, it is not the best
> approach, but you'd be suprized how many small organizations
> have a dumb firewall that only allows TCP port 80/443 outgoing
> connections (no incoming connections of any type).  

This is just more reason that restrictive, non-configurable firewalls are a
'bad' thing. Together with NAT they are breaking the basic model of the
Internet. I know I can't fix them myself, but I can try to point out where
they either prevent new, innovative network services or cause everyone to
work around them by tunneling traffic -- thereby defeating the whole purpose
of firewall. I know this doesn't answer your question, I try to do that in
the next paragraph.

I know a lot of existing firewalls do have these kind of problems, and the
short answer is right now Spread has a problem working with them. Since
Spread implements it's own protocols on top of IP/UDP for multicast
generally the firewall has to open up the port that spread needs. IPSEC IP
level tunneling (possibly done by the firewall) is probably the best option
I know of.

Spread is sort of like Internet applications like Real Audio or other
multimedia that also need ports opened on firewalls. Since usually the
poeple installing Spread want to use it, they are also able to configure
their firewall to allow it. 

 > 
> Lastly, I'm kinda new to networking and am not familiar with
> how private networks operate or how spread handles them.  Is
> there any particular reading that would be helpful?  It would
> also be helpful to have a handy reference of what ports and
> such spread uses so that I can grok this better.  

Spread's default port is 4803 (this is not IANA assigned, just a default we
picked). Spread will use that default port number and the next sequential
number for UDP traffic. So by default Spread will have UDP traffic between
ports 4803 and 4804 amoung all of the daemons. If you configure a different
port number in the spread.conf file then it will use that port and that 
port + 1.

Spread does not work with private NAT addresses if more then one segment is
involved. So a single segment of machines in 192.168.0.0/16 space will work
fine. However if several sites are all behind NATs and have private
addresses it won't work with Spread. 

A hack that could work for some situations is the following. If you you have
two sites behind NATs, say 192.168.5.0/24 and 192.168.10.0/24 connected by
the internet. And you have the ability to have 1 machine at each site have a
REAL public internet address like 128.x.5.5/32 and 128.w.10.10/32 where the
128.x.5.5 is also on the 192.168.5.0 private network and 128.w.10.10 is also
on the 192.168.10.0 private network. Then if the machiens with real ip
addresses are configured as the first machine in the Spread segment. Then I
THINK Spread will work. The reason is that the token is only passed to the
first machien in the other segment (which is assigned the real IP address)
and the data messsages are also sent to the first machine in the segment for
it to rebroadcast to the rest of the segment. It is required that the
private address spaces are distinct so every machine has a separate unique
IP address (so both segemnts can't be 192.168.5.0/24 -- which is common in
NAT setups)

I have never tried this hack, so it might require some tweaking, but I think
it can work in theory.

> Overall this looks _very_ neat and that Guido and Tim are over here
> is also encouraging.  I'm looking to build a YAML message bus for 
> my pet project, so I will probably be lurking.  YAML is a language
> independent data serialization language (see yaml.org) similar to
> XML, but without all of the blemishes.  How this gets developed 

This sounds really interesting. Do you have a specifiation for what services
you think a message bus should include?

> such that security, firewalls, and dynamic servers changes seem to
> be my only current question set.  Nice user manuals and Yair's 
> home page / posted class material have been very very helpful to
> understanding how this all works.

Thanks. I have a number of documentation updates I hope to bring out soon
which will answer some of the common questions.

Jonathan
-- 
-------------------------------------------------------
Jonathan R. Stanton         jonathan at cs.jhu.edu
Dept. of Computer Science   
Johns Hopkins University    
-------------------------------------------------------