Discussion: Application specific problems when using Phantom

[Michael]

Dear Phantoms,

as promised this thread will be about application specific features,
that will stop working, once we tunnel every network communication by
Phantom.

Walter already mentioned two problems here:
http://groups.google.com/group/phantom-protocol/web/early-ideas-feedback
(corresponding discussion here:
http://groups.google.com/group/phantom-protocol/browse_thread/thread/a1b3909806cb7a35)
and here: http://groups.google.com/group/phantom-protocol/browse_thread/thread/b379a10b877aa915

[1] The first problem he mentioned is DNS.

We need a way to securely resolve DNS addresses within the parallel
Phantom network. I am not talking about IP/DNS addresses, I am (and I
think that is what Walter was aiming at) talking about that many web
applications use DNS technology to work (for webpages and hyperlinks).
So if we do not want to force any server, that decides to join Phantom
to provide an alternative to DNS (e.g. to the hyperlinks used on
webpages hosted on it), we need to think a way of resolving them
ourselves without providing a possible security risk at this point.

Walter suggested the solution of using a local nameserver (PowerDNS),
which would catch any DNS addresses and then resolve them in a way,
that we can use Phantom routing.
I'd like to add a second idea: we should include our Distributed Hash
Table (DHT) in the DNS-resolve-process. What I mean is to use the
Network Database (realized by DHT, explained more thoroughly in
Magnus' white paper: http://www.fortego.se/phantom-paper.pdf) to
resolve DNS addresses. Like that we would avoid the risk of having
central points for DNS, and distribute the risk the same way we
distribute the risk of compromising AP addresses.

Example: My browser displays a webpage hosted on a server, which
joined the Phantom network. I am accessing it, without my browser
knowing about that, by a Phantom routing path. Now the webpage
includes a DNS-hyperlink to yet another webpage and I click on it. The
request for resolving the address is sent to my local PowerDNS
namesever, which accesses the DHT Network Database and tries to find a
resolution for the DNS.
Having the resolution PowerDNS passes the resolved AP-address to the
start node of my routing path, which will eventually deliver me the
requested page.
In case the hyperlink refers to a webpage hosted on a webserver that
has not joined the Phantom network, the resolution will fail and
PowerDNS will send a 404 message to my browser.

As already suggested by Walter here:
http://groups.google.com/group/phantom-protocol/browse_thread/thread/d24d57ff0fa40d1c
I think it is necessary to include a metric of trust to this
resolution (As well as when looking up an AP-Address in the Network
Database). EigenTrust seems a good choice for such a metric. I think
we can modify it a bit to use it as a value of how much we can trust a
DHT entry for a DNS resolution or an AP-Address entry.

[2] The second problem Walter mentioned might be applications which
automatically use some proxy server (with a fixed IP).

I have not thought about a solution for this one, but I wonder how the
TOR or I2P guys solve this problem. Of course they have the advantage
of eventually being able to use that proxy IP-address, but maybe they
found a different solution? We should ask them.
Right now at least I see no way to solve this without finding the AP-
Address corresponding to the proxy, which would mean finding the AP-
Address fitting its IP-address and therefore is out of the question.

maybe someone can look into this some more, for getting started on the
basic implementation it should be no concern for now

Michael

[Magnus Bråding]

Hi Michael,

As you mention, this aspect of the "whole" (i.e. implementing DNS
functionality on top of the AP address space) is not at all critical to
your main goal of implementing the core functionality of Phantom, so
please don't put too much focus on it at all. I would really recommend
that we limit ourselves to AP addresses only at this point, to be able
to keep focus on your goal. Just like many other aspects of Phantom,
this can be easily added on at a later point, as a completely different
"module", which can be designed and implemented by anyone. So please
just ignore it completely at this point, and focus the main effort on
getting the main DHT and the routing path/routing tunnel core to work
under proof-of-concept conditions, which will probably be challenging
enough I think. :-)

And again, unfortunately, many of the discussions here on the list so
far have been based on side tracks, somewhat confused ideas, and/or lack
of reading/understanding the original specification. Thus, please don't
take these discussions too seriously, or at least always read the spec
first, and only if something is missing in there, then see if there has
been suggested some kind of fix for it here on the list. This does not
mean that all ideas regarding DNS-functionality and address resolution
in general here on the list have been bad though, but some of them have
been really way out there.

Regards,
Magnus