A stab at the sealer in E
Tue, 9 Nov 1999 17:08:45 -0800
Bill Frantz, <firstname.lastname@example.org>, writes:
> At 10:27 AM 11/9/1999 -0800, email@example.com 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.
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.
> 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.