[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gzz] firewall issues vs. GISP
From: |
Benja Fallenstein |
Subject: |
Re: [Gzz] firewall issues vs. GISP |
Date: |
Wed, 14 May 2003 20:57:07 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030430 Debian/1.3-5 |
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