Re: [Gzz] firewall issues vs. GISP

[Benja Fallenstein]

Hi Jukka,

Jukka Honkela wrote:
> I've been thinking through the issues related to autodetecting firewall
> address and so on.

Thanks!

> 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.

Why exactly? Is this "without any modification to the code," or are you 
saying "this will be impossible without modifying the firewall"?

> The problems related to is primarily the fact that the protocol
> has, rather annoyingly, put the src-tag in it.

Could you maybe write to address@hidden and explain this problem? 
Maybe it can be changed easily in GISP?

> 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.

So the GISP peer should keep the connection open. Sending a simple 
keepalive packet to some other peer every minute should suffice, right?

> *  This peer/http gateway could only access content, it could not
>    publish content on its own

Not so that other peers can GET the content from it. However, if other 
peers could, through UDP, ask this peer to PUT a block to them, it 
should work. It might even be possible to send the block through UDP, 
but that seems really ugly.

I think the PUT thing is what e.g. Gnutella uses. It means that one 
natted peer cannot download from another natted peer.

> *  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.

Which firewalls/NATs is this for? We must be careful here; a peer like 
this CANNOT participate in the protocol.

AFAIK the more usual type of NAT can receive UDP packets from any 
source. I don't know about firewalls.

>    Secondly this peer cannot provide caching help for the other
>    peers either.

What is caching help?

> *  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.

Or the NATted peer could be asked through UDP to initiate the TCP 
connection.

Maybe weird and stupid idea, just came to mind: If peer A wants a file 
from natted peer N,

- A sends a UDP packet to N asking it for a connection
- N opens a TCP connection to A, waits
- A uses the TCP connection to HTTP GET the file

Could this work at all?

> 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.

I think we need to be able to detect the most usual ways for dealing 
with UDP connections...

> 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).

Now that's *really* not a problem. The publishing port needs to 
determine or be given its public IP; it can be given the public port at 
the same time.

>    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.

What? F would forward P to port Q on A, but it would not translate 
connections from A:Q to come from F:P? That sounds a bit broken :-)

>   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.

I don't think autodetect is impossible-- we simply need to change the 
way we use HTTP ;-)

Gnutella manages it, too, so there... :)

- Benja