This is post-1.0 stuff, sorry.
Discuss all you like, here or on tech. No developers use tech any more
anyway. As for the details... it is essentially equivalent to:
A=<freenet nodes inside private network>
B=<gateway node>
C=<freenet nodes on public internet>
A, B, and C, are all freenet nodes, they route as freenet nodes. A can
talk to anyone in A, and also to B. B always resets references to self
when passing requests between A and C. Any node in C may or may not have
a reference to B; any node in A may or may not have a reference to B. It
is in fact entirely possible that C will completely ignore B (or A
ignore B). Anyway, that's the principle, in its simplest form - one node
can access two networks, nodes on both sides hide behind that node.
You can get a bit further with this concept by somehow allocating each
private network a unique identifier, and including {network id, TCP
address} pairs as extra addresses in the node reference. This would
allow at least for somewhat improved routing involving B nodes.
Now, assuming that the main problem is NAT:
Ultimately, you are going to need to provide a mechanism for path
folding, if the current freenet architecture is to be preserved, with
full routing between anyone in A, B or C. This means you need to be able
to, quickly, from anywhere in A, tell a node in B to connect out. How
can this be done? One possibility is email. It can be quite fast. Or any
other fast publicly writable per account system proxied through the
firewall. Some other possibilities involve a way to find a node in B to
proxy for you, maybe by inserting a list... but this is not likely to be
secure, and more seriously, it means that all the B nodes can be located
by the people trying to shut them down. Another possibility is to put a
gateway node's reference into the A node ref while it is being passed
around in C... this is possible, but what if there is more than one
gateway? It also involves B doing rather more than a normal node... it
was proposed a while ago on the list, look for "shadow nodes" or
something similar in the archives. You might attempt to use freenet to
distribute the please-open-a-connection-to-X messages, but it is far too
slow. Passive requests could speed it up, but then the passive requests
when triggered need to have somewhere to go. So all in all, we are down
to:
a) Shadow nodes. Node ref includes the ref of a gateway node that will
forward (some) traffic from one side of the wall to the other. Node will
endeavour to keep open the link to the shadow node. A fairly precarious
situation, even if we allow it to list several shadow nodes.
b) Notifications go over proxied email, instant messenger, or
whatever.
Regardless,
* This will not solve freenet's problems with hostile environments.
Freenet requires "path folding" for acceptable performance. This means
you can compile a list of all nodes, or of a great many nodes, fairly
quickly through relatively normal freenet interactions. This means
that even with steganography, if freenet is illegal in a given area,
the authorities will be able to eliminate it.
* This is DEFINITELY post-1.0 stuff - new transports, steganography etc.
On Fri, Jan 31, 2003 at 04:05:21AM +0000, jrandom wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> Hi gang, I'm new here, so please don't bite.
> First, thanks for all the good work. The network is working great
> and the public builds have been noticably improving my performance
> and simplified the ease of use.
> What I wanted to ask about was regarding a bridge between public
> freenet nodes and those behind one way firewalls, proxys, NATs,
> and the like. I put together some ideas for this, and I was
> wondering if any of you had any feedback, suggestions, or even
> answers to the questions in the last section.
> I put the HTML (text + 1 jpg) up at
> CHK at LJvxNEV0dE1FqOcpGiqXvVEPv2wNAwI,c7AneNn7hybxcTdKpIxLiw
> I'm sure this group has already gone over all of the issues in
> there before and have probably already figured out a solution, so
> please, tear this apart and point me in the right direction.
> Don't worry, I'm not trying to get y'all to do more work... I'm
> volunteering myself to do some dev. The reason I'm posting to devl
> instead of tech is because as it stands right now, what I'm thinking
> will probably include modifying/extending fred (or at least ripping
> out the FCP handling code)to do what's necessary.
> If you know of a better place for this discussion, please, let me
> know.
> Muchas gracias senors y senoritas
> - -jrandom
> [pgp - SSK at fgbuxwSCCjOJHsUI-9-uijD1haQPAgM/flinks/4//pgpKey.asc]
> -----BEGIN PGP SIGNATURE-----
> Version: PGP 8.0
> iQA/AwUBPjn0i8IgL3Iaet+UEQIk5gCg8Ed/01iDyejYb2APCKFXVXK+25UAnirB
> VK+FsO7JfiSpkSLBeFPPNuzF
> =GRiE
> -----END PGP SIGNATURE-----
>
>
> !+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+
> CryptoMail provides free end-to-end message encryption.
> http://www.cryptomail.org/ Ensure your right to privacy.
> Traditional email messages are not secure. They are sent as
> clear-text and thus are readable by anyone with the motivation
> to acquire a copy.
> !+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+
--
Matthew Toseland
toad at amphibian.dyndns.org/amphibian at users.sourceforge.net
Full time freenet hacker.
http://freenetproject.org/
Freenet Distribution Node (temporary) at
http://amphibian.dyndns.org:8889/it8bAyd1fdw/
ICTHUS.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20030131/7166917f/attachment.pgp>
