[E-Lang] Re: Distributed Toontalk (was: VLS for everyone)

[Ken Kahn]

From: "Bill Frantz" <frantz@pwpconsult.com>
...
> What does Toontalk use for a port number?  Is it a well-known port number?
>

A good question. Since ToonTalk is currently a Windows-only product I am
currently using Microsoft's DirectPlay
(http://msdn.microsoft.com/library/techart/dpov.htm ) and it enables
multiple instances of ToonTalk on a network to connect just using an IP
address. So I've ignored the whole issue of ports and everything works fine.
In general DirectPlay simplifies things but I do worry about the day when
there are Mac and/or Linux versions of ToonTalk and they need to
communicate.

> Is the identity of the Toontalk nest just the IP number, or does it
contain
> additional information.  In other words, what would a requester pass to a
> NLS to ask for a particular nest.
>
Besides the IP number there is a 128-bit GUID (and some versioning info). I
use the Windows API to generate the GUID and I use the version that is fast
and simple but possibly one can guess valid GUIDs.

> In the last E VLS, the vat identity is the hash of it's public key.  The
> port number was registered as part of the registration process (along with
> the IP address).
>
> Do you plan any kind of authentication on the registration.  One attack we
> thought of on the VLS was making a vat unreachable by registering a false
> IP address with the VLS.  The suggested fix for this attack is to require
> that the registration be signed.  Note that the VLS would only have to
> check the signature when it had a current registration for the vat, and
the
> new registration changed the IP address or the port.
>

No current plans. First in ToonTalk nests can be copied (so that each copy
receives a copy of incoming messages) so a false registration wouldn't
interfere with the valid ones. But it would leak information and copies of
any capabilities transmitted to the nest. I am reluctant to do anything that
would make life more complex for the users (e.g. signatures). Remember that
most customers are parents and teachers who find very simple things on a
computer to be challenging (and sometimes scary). If the problem is an
attack that registered a different IP address than the IP address of the
registrant, then this could be stopped by sending to the IP address being
registered a message saying - please confirm this registration by sending me
back this newly generated GUID. Right?

A related attack that I worry a bit about is that anyone with a bird, but
not the nest it flies to, could by breaking the ToonTalk language
abstraction, obtain the GUID of the nest and register so that they'll
receive a copy of all message sent to the nest. In other words a valid
holder of the "send" capability can crack it and turn it into a "receive
copies" capability as well.

I wonder if people think a reasonable strategy for ToonTalk would analogous
to HTTP/HTTPS. If and when security becomes an issue I make a ToonTalk
variant that attempts to be secure (like HTTPS). In the meanwhile, just get
something that works and is simple out there (analogous to HTTP).

Best,

-ken