Re: [Gzz] firewall issues vs. GISP

[Jukka Honkela]

On Wed, 14 May 2003, Benja Fallenstein wrote:

>> 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"?

Starting from the basic assumption that the firewall is out of end users
control, so port forwarding is not possible. But, modifications to the
protocol itself, tunneling and PUSH models might allow publishing things.

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

It's a bit annoying that the port forwarded case can actually benefit
from the src tag... but then, the whole GISP might be fundamentally flawed
protocol vise, hard to say.

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

Keepalives could help.

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

I've tried out gnutella about twice and never got anything push
related to work, or so it appeared to me :)

PUSH/PUT model could be one way out, anyhow, but even it can only work
between certain cases; there is no easy model where two peers both living
behind NAT firewalls without portforwarding could communicate directly
with each others; there has to be somekind of gateway in any case.

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

A typical stateful firewall with NAT:
Machine A sends an UDP packet with origin port Ap to machine B with
destination port Bp. The firewall notices the first packet and
establishes a "connection" between A and B, appearing as F with
port Fp to machine B. Now, if there is a third host C, and tries
to send packet to F with destination port Fp, the packet will
be firewalled away because there is no established "connection"
between A and C of which firewall would be aware of. So the case
is clearly that only the machine A can establish _any_ connection between
any other machine, if no port forwarding (or tunneling or anything alike)
is in use.

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

First of all, it requires that N has already opened the udp connection
between the two machines.

Secondly, N could siply PUSH/PUT the requested file to A, but, would
require that it already knew what the other end wants.

>> * 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 :-)

Using my previous example from some paragraphs above;
The problem is that the port forwarded port on the firewall, let's call
it FP, nobody guarantees that it will be equal to Fp. If Ap is something,
in most cases, the firewall tries to make Fp == Ap, if possible. If the
port is already in use, then it can't do so but.. Linux 2.2 which has
ipchains, it actually always puts Fp to somewhere above 63000 or so,
no matter what the Ap is.

>I don't think autodetect is impossible-- we simply need to change the
>way we use HTTP ;-)
>
>Gnutella manages it, too, so there... :)

I don't know the gnutella protocol, but it might have more thought behind
it; Seems to be that the designers of GISP have not thought much about NAT,
because of the blind trust on the SRC tag alone.

-- 
Jukka Honkela