vrs-development
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Vrs-development] VRS and SEE/DEE goals


From: Tim Terlegård
Subject: Re: [Vrs-development] VRS and SEE/DEE goals
Date: Mon, 25 Mar 2002 19:52:11 +0100

> > I was thinking that NO VRS will accept unknown LDS's.
> > We must remember to keep service users and node owners
> > clearly seperate.
>
> This is good because if one could have a VRS containing
> an unbounded set of LDS's, then the number of participant
> LDS's every other LDS needs to know about and track
> becomes unmanagable.
> I'd rather see the members of an VRS be controlled.

If there's no control it will be easy make a DoS attack to the VRS by adding 
numerous of services.

To become a member of a VRS one should authenticate and then it's decided 
whether the node can join or not? This means there will be a central server 
for adding services, right?

I'd like to see a VRS getting an identity. A VRS will belong to a certain 
domain, which has a name (maybe not world unique as real domains and IPs). If 
a VRS encompasses smaller VRSes, the smaller VRSes are subdomains of the 
encompassing VRS. If my university has a VRS, they can name their VRS domain 
to uni-linkoping-sweden. They can divide their domain into subdomains. This 
way one can choose to add a service to any of the domains. The school might 
not want anyone to be able to add their services to the uni-linkoping-sweden 
Service Discovery, but a subdomain might welcome certain ones to add 
services. The subdomains have their own Cluster Admin, as they are VRSes 
themselves. If I want to add a service to a subdomain of uni-linkoping-sweden 
I ask the subdomain's auth server to add me, the main domain 
uni-linkoping-sweden never gets involved.

Should there be a central Service Discovery Server or can I ask any VRS node 
what services are available?

uni-linkoping-sweden acts, in my example, is the VRS domain for the school. 
If one asks uni-linkoping-sweden what services are available, one gets to 
know all the subdomains. If one asks a VRS node belonging to a subdomain of 
uni-linkoping-sweden, then one should only get to know the services available 
in the subdomain, not in the main domain, right?

Let's get back to Service Discovery. How do you know whom to ask what servces 
are available? Probably my university would put the IP of their VRS node on 
the homepage and one could ask that one. So really, why an arbitrary node be 
capable of telling what services are provided in the domain (VRS cluster)? If 
I want to join a VRS cluster I (probably) have no idea about the IPs of the 
nodes. I must know the IP of a node so I can ask. Let's say every node can 
tell about the domain's services. If someone tells me the IP of a node, 
then I can ask about the cluster's services. But if that machine dies I have 
no idea who to ask. I don't really see where the distribution power of p2p 
can help in this Service Discovery issue.

Right now a central Service Discovery for each domain (and subdomain) where 
one adds services makes most sense to me. What do you think?

If one wants to add a service to a subdomain of uni-linkoping-sweden, it's 
the subdomain one asks for authorization, not the main domain. One doesn't 
ask the root of the DNS tree to add an se subdomain to .linux.org, one asks 
linux.org about this.

How does this work in the p2p applications that are out there? I guess 
there's always a central server which one can ask what other peers are 
connected etc?


> > Although, I suppose it would be quite possible to run
> > a VRS that would accept anyone, I don't see a reason
> > to do this.  But there most certainly might be one
> > that I just don't see.

This doesn't need to be a special case. A domain could perhaps choose their 
way of authenticating services (digital certificates, username/password, 
pre-shared keys etc) A domain might choose "no authentication". This would 
just be another way to authenticate oneself.

-- Tim



reply via email to

[Prev in Thread] Current Thread [Next in Thread]