[Lots of quote for a short response.]
At 05:08 PM 11/9/1999 -0800, hal@finney.org wrote:
>Bill Frantz, <frantz@communities.com>, writes:
>> When Alice passes Bob a reference to Carol, all Bob knows about Carol is
>> Carol's vatID.
>>
>> To work with Freedom, the vat would have to register with the VLS using the
>> "entry to freedom to get to this vat" address. I believe, that the VLS
>> uses the address of the other end of the TCP connection to define the
>> address thru which a VAT can be contacted in order to support Network
>> Address Translation. A small miracle would allow a vat to contact the VLS
>> thru freedom and have everything "just work".
>
>I suspect that things won't work quite this nicely. It looks to me
>like there is no such thing as an "entry to freedom to get to this
>vat" address. Freedom provides outgoing anonymity, but it doesn't
>seem to provide a way for an anonymous machine to listen for incoming
>connections. It would be difficult to do this because there might
>be multiple connections going on at one time (say, multiple people
>accessing a web server at once connecting on port 80), and each would
>need a separate path through the Freedom network.
>
>I think what you might do would be to use ideas similar to those of
>Frank O'Dwyer in http://www.eros-os.org/%7Emajordomo/e-lang/0600.html.
>He proposed a mix system similar to Freedom, meaning that much of the
>work is already done.
>
>With Freedom you have only a half-anonymous system, as Frank describes.
>What you would want would be "proxy servers" which would be machines at
>well known addresses that would serve as proxies for anonymous machines
>which wanted to listen publicly for connections.
>
>If Carol's machine wanted to be able to receive anonymous connections
>(which would be necessary for Alice to give Bob a reference to Carol), she
>would connect to the proxy server P using Freedom and register with it.
>P would send back the IP/port which would be assigned to Carol (the IP
>would be P's). Carol could then connect anonymously to the VLS and supply
>her VatID and the assigned IP/port from P.
>
>Now when Bob tries to find Carol, he looks up her VatID in the VLS and
>finds P's IP/port. He connects to that, and P sends a message to Carol
>via their existing TCP connection telling her that there is an incoming
>message. Carol's software would then have to create a new TCP connection
>back to P which would be used for the incoming connection to Bob.
>
>P would then serve as a transparent forwarder, passing packets between
>this second connection from Carol and the connection from Bob. Since
>the first thing Carol and Bob would do is to handshake, authenticate
>themselves and set up a secure session, their privacy is protected even
>from P. All he has to do is pass the packets.
>
>The main tricky part in this is the software on Carol which deals with the
>incoming connection from Bob. Normal socket software would do an "accept"
>call, which creates a new socket to handle the incoming connection.
>There are a variety of ways, too, by which the software might be notified
>of the incoming connection.
>
>With the anonymous version, Carol has an always-open socket to P, and
>a remote incoming connection is signaled by some particular message on
>this open socket. At that point Carol's software has to create a new
>outgoing connection back to P, which will then be connected remotely
>to Bob and over which she can communicate with him. It is a slightly
>different sequence of operations than the normal one. Ideally you could
>make a library which would make this look much the same to Carol; she
>gets an event or signal or select() return which tells her there is an
>incoming connection; she calls a variant on accept() which creates the
>outgoing connection to P and returns to Carol the new socket, all ready
>to talk to Bob.
This suggestion resembles
(http://www.erights.org/to-be-sorted/DataCommThruFirewalls.html), an
unimplemented HTTP tunneling protocol.
>
>This way her code can be kept almost unchanged. The main problem is the
>variation in socket access across different OS architectures. You could
>perhaps do it at the Java level, which would help with OS differences,
>but the problem is equally acute for non-Java programmers and it would
>be best to solve it for everyone. Perhaps the Freedom software will
>someday transparently simulate accept() across the anonymous network.
One thing Freedom might be able to do is to allow Carol register an IP:port very much like the VLS does. While it would probably implement a different name space, it could make DNS names like carol.freedom.org, or something like that. Whenever someone wants to connect to Carol, they build their TCP connection to carol.freedom.org:port. If Freedom has a registered client for that address, it routes the connection thru the normal Freedom mix resulting in a TCP connect on the port Carol registered. (Probably Freedom Version 2 :)
>> Port numbers are a different, but related problem.
>
>For this idea to work, the VLS would have to return both an IP address
>and a port number given the VatID. It would also have to be able to
>update these dynamically since at least the port numbers would tend to
>change each time the software was restarted. You wouldn't be able to
>rely on fixed port numbers.
The VLS does accept the port number from the vat. The problem comes if a Network Address Translation layer does port mapping. I don't think we have solved that yet, except by allowing the user to do manual configuration.