[Gzz] firewall issues vs. GISP

[Jukka Honkela]

I've been thinking through the issues related to autodetecting firewall
address and so on.

1) Having http gateway living behind a NAT firewall, without having any
need or ability to use port forwarding: no way to publish anything in
this case, anyhow.

The problems related to is primarily the fact that the protocol
has, rather annoyingly, put the src-tag in it. If it didn't have
it, the whole thing would work "out of the box", without any
modifications. Even then there is a 30 second and 3 minute timeout
problem related to udp connections in linux iptables based
firewalls, though, and probably similar issues with others too.

*  This peer/http gateway could only access content, it could not
   publish content on its own
*  GISP tables would contain references to this host, due to the
   nature of the protocol (dunno if it could be prevented somehow,
   not likely though), which is useless because only the peers
   that this peer knows about can communicate with each others.
   Secondly this peer cannot provide caching help for the other
   peers either.
*  Automatic detection of firewall settings in this case could
   be possible, but even then requires modifications to the
   GISP protocol - I would rather simplify a protocol rather than
   extend it. (by removing the src -tag, rather than extending
   the seen -tag to contain the address it was seen from (which
   is one way it could be rather simply dealt with))

2) A peer living behinhind a NAT, that wants to publish something too.

This case unfortunately needs port forwarding in any case
(due to TCP connections to default port 37000), so the GISP
traffic could as well be port forwarded. Now, the tricky part
is related to the confusion what will result with the
port forwarded UDP connections vs. the connections the host
itself initiatiates. Unfortunately the way how different
firewalls deal with UDP connections, the origin port could
vary in random ways etc.

Problems:
* To be able to publish something, the publishing peer A
  has to be aware of the address and port of firewall F
  the peer A appears as (due to port forwarding). This knowledge
  cannot generally be obtained automaticly, unfortuntely, because:
** The publishing peer does only open the TCP port, it does not
   communicate anywhere by itself using it, there is no way telling
   from inside which port the firewall admin has assigned for the peer.
   -> The information about the port number atleast has to be given
   manually
** This case is also true when consider if one wants to have multiple
   peers with multiple port forwardings available. There is only
   one port 37000 available, if at all, on the firewall, one would
   have to assign other ports for the second (and successive) peer(s).
   Thus, one can't rely that even if the address of the firewall
   was somehow automaticly known, the port can't be automaticly
   detected (or could be, possibly, but would require port scanning :o )
* The src -tag of the GISP protocol affects us here too, but in this
  case it has a vague advantage even. Because if the peer A connects
  peer B (located outside the firewalled network), the connection
  might appear coming from firewall F, port P. Realisticly, though,
  there is only one port that has been portforwarded, and it might not
  be port P at all. So, by manually telling to the peer A that it's
  "correct" port number it should publish is P, it could actually
  work as expected. The other scenario, where the other peers
  might know the peer A as multiple different peers (because depending
  on the way how the firewall has been implemented) is not fun, either.

*****

conclusions so far:

case 1 can be dealt with either by removing src tag from the protocol
or othervise extending it. It is not entirely clear, though, that is
the whole case 1 feasible at the first place, due to the varying nature
of firewall implementations, and due to various possible timeout issues.

case 2 is not a likely candiate for anykind of autodetection, it can
work possibly the best with src tag in the protocol (one could still
modify the GISP stack a little bit, just in case, to rember also
the true address of the host). Absolutely the easiest way is just
to give the port forwarding info to the peer manually and live with
the fact that publishing stuff from behind a NAT is next to impossible
without manual work anyhow.

"final" conclusion:

case 1 is in a sense important but potentially hazardous goal,
case 2 is implementable and solvable by the manual configuration
rather quickly, if not somebody has had it done already while
I've been thinking about it...

-- 
Jukka Honkela