-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Something that has been a big source of trouble for... well pretty much
forever is a problem I call the "peer introduction problem".
Here it is in a nutshell. Your client C has a connection to site A.
Site A links to a vobject on host B. You have connections to both site A
and site B. It would be wasteful to create a second parallel connection
to host B, since all the vobject caching, listeners and everything else
would be duplicated. How do you ensure that you can associate that
hyperlink to your existing connection to site B?
Well, the obvious answer is, site A sends you a link vip://B/foo, you
recognize B, and everything works.
Except when it doesn't. Such as:
- -> C and B are on a local subnet, but A is on the internet. A doesn't
know the internal hostname/IP address for B, and so A and C use different
hostname/IP addresses to refer to B.
- -> Because of DNS aliases, A and C connected to B using different
hostnames. They again use different names that refer to the same actual
site.
- -> Because of multihoming, A and C connected to B using different IP
addresses (see a pattern here?) They have different addresses that refer
to the same actual site.
- -> A and B are connected using a different protocol than C and B. For
example, A and B are part of a server cluster and are using a gigabit
interconnect, but C is on the internet. (This is a variation on the first
once, since the addresses would also be different...)
Now, the solution is for B to be able to identify itself uniquely in some
way. How do you do that?
Currently, VOS has a concept of "host aliases" and a "preferred hostname".
The way this works is that when a site connects, it provides a list of
other names it is known by, starting with the preferred name, which is the
one that should be used when talking to other sites.
This is a 50% solution and has two flaws. First, this is essentially a
jury-rigged solution that doesn't catch cases where not all valid
hostnames are known -- and, as it turns out, 90%+ of computers on the
internet (in my estimation) don't have their hostnames properly
configured. For example, windows will happily report as a hostname "MOM'S
COMPUTER" or "WORKSTATION"...
However, a far larger problem is security: what happens if a site lies
about its host aliases? It can pretend to be another site.
VOS bends over backwards to address the security issue, and the result
isn't very graceful. During site peering it exchanges special
challenge/response numbers. In order to verify that a site alias is
valid, it goes through and tries to contact each site alias and uses the
challenge key. If it can't contact the site (or doesn't get the correct
challege back) it discards the host alias.
At least, that is what it used to do. I have disabled that code entirely
for the time being, because it doesn't work.
The solution is to completely re-think how a remote site is identified,
and I will discuss this in my next email.
[ Peter Amstutz ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[Lead Programmer][Interreality Project][Virtual Reality for the Internet]
[ VOS: Next Generation Internet Communication][ http://interreality.org ]
[ http://interreality.org/~tetron ][ pgpkey: pgpkeys.mit.edu 18C21DF7 ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFEJ25DaeHUyhjCHfcRAiNaAKCqeIYe5VyRlhoIEGlcdx0P8bAlPgCfb21b
ZRiTKKsnrO4NRLb/7bwCt6E=
=O054
-----END PGP SIGNATURE-----
_______________________________________________
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
