gzz-dev
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]