Bill Frantz, <frantz@communities.com>, writes:
>
> At 10:27 AM 11/9/1999 -0800, hal@finney.org wrote:
> >The first is that Freedom supplies application specific filters to
> >check the outgoing data stream for privacy leaks. IP packet headers
> >contain the source IP address, and of course the system strips those out.
> >However some protocols include this kind of information within the packet
> >bodies as well, and Freedom has special software to check for this.
> >I imagine that Pluribus must send the source IP address at least during
> >its handshake protocol, and possibly at later times as well. This would
> >need to be changed somehow.
>
> The "standard" way for one vat to locate another is thru the Vat Location
> Service (VLS). Vats are named by the hash of their public key, called a
> vatID. The VLS provides a lookup service which returns an IP where the
> named vat will receive connections.
Oh, I see. That's good, then. If you never pass around IP addresses then that should eliminate many of the problems I was worried about.
> 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.
> 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.
Hal