Re: Fwd: Re: [Vrs-development] More info

[Bill Lance]

> We will have to support server and client
> authentication for web services. We could treat that
> as one of the plugin for the Service framework
> 
> 

exactly.


.  Probably, we will use SSL, for
> > several reasons.  One, it's simple to implement.
> And
> > two, SSL traffic on the net is difficult to
> isolate
> > because of it's common use in commercial traffic.
> 
> Good enough. We also might have consider export
> conditions of various countries which prevent
> certain
> the spread of 128 bit encryption. This means that
> different algorithms will have to be used for a
> network as global as VRS.
> 

Export from where?  I believe that the USA is the only
one with issues about this.  But in what way can the
results of this project be construde as being exported
 to anywhere from the USA. or anywhere else, for that
matter?

> > > > There does exists the possibility of IP
> address
> > > > spoofing, however.
> > > Once the client and the server authenticate, i
> > don't
> > > think there will be any IP spoofing.
> > > 
> > Great.  I don't know much about this particular
> > area.
> It all depends on how determined the hacker is.
>


We are going to need to enumerate all of the attacks
that we can imagine on this thing.  And the sooner we
do that the better.  

Know anyone who might bring some expertese to that?

 
>> > 
> > You misunderstand, a VRS Cluster is an isolated,
> > individual entity.  It has no relationship what so
> > ever with other VRS's.
> > 
> > The GLOBUS system might be more like what your
> > thinking about.
> 
> I might have still not understood the concept
> properly. Let me get my thoughts sorted. 
> 
> The LDS connected to the VRS is spread around the
> world. Each VRS cluster is made up of only few LDS
> nodes. How many? and who determines the limit? 
> 

Ultimately, the Cluster Administrator does.  The Admin
is the equivilant of the root user.  

In the first page on the Introduction, I mention that
a VRS Cluster is a humanly controlled entity, a
consensual organization if you will.  Presumably, each
VRS will have a purpose, a reason to exist.  Several
examples are pointed at in the Intro, from a technical
use in a small business to the hobbiest group web
page. The coming of methods and means of exposing
personal and professional information will create
another important reason to use a VRS.

These are all different, and each will most likely be
started with a specific purpose and set of policies
formulated by it's creators.  



> > To further clarify this question, after a new node
> > initially loads the complete CI after loging in,
> > only
> > transactions are sent and recieved. THe whole CI
> > adcts
> > like a DB, changing only in responce to
> > transactions.
> 
> One more clarification, when an LDS joins the
> cluster,
> who provides the cluster image it requires. Since
> none
> of the LDS nodes have any information regarding the
> new LDS, the new node has to modify the existing CID
> and broadcast it. Is this thinking correct.
> 

Joining a VRS Cluster is a two step process.  First,
the new member has to be subscribed by the Admin. 
This involves getting the SLL keys setup, setting the
Trust Level for the new node plus any other
administrative node data needed.

Once subscribed, to logon, the new LDS contacts any
one of the running nodes, which passes them to any 
Level I
node.  All I nodes have the subscription data, so it
can verify and authinticate the new logon.  If the new
logon is a Level I or II node, it is sent the complete
CI image.  The Level I node that did the loging-on
than modifies it's own CI to reflect the status of the
new LDS node in the Cluster.  Then the CI Object
broadcasts that change as a transaction to all Cluster
nodes, including the new one.



> 
> > > A poll can be made of which of the level II LDS
> > > nodes
> > > can be made admin till the level 1 node returns
> > > online.
> > > 
> > >   This means that no new node can be added to
> the
> > > cluster as well as any existing node that has
> gone
> > > down.
> > > 
> > 
> > humm  ... you have a point there.  
> 

>Is it possible to advance a single Level II node to a
>Level I node? This will take care of issues such as
>addition of new nodes.

They should probably just be Level I nodes to begin
with.  There can be more than one Level I node, that's
no problem.  In fact, if every scuscriber is
conpletely trusted, all nodes can be a I.


>Each time a LDS joins the cluster, it could notify
the
>cluster that it has a static IP (an important
>consideration, Is there any other consideration).

Yes.  We're also looking at connection bandwidth, net
distance, and memory quotas set by the LDS's host. 
These hopefully will be usefull in tunning a running
net.

>There will be a slight problem if the cluster admin
>goes down when certain web service clients are
>connected. 

There shouldn't be.  Once a LDS gets a netservice
deligated to it,  it only needs itself and access to
the Repository system.  It has no further relienace on
any administrative functions.



__________________________________________________
Do You Yahoo!?
Yahoo! Sports - live college hoops coverage
http://sports.yahoo.com/