Subject: RE: [Rserpool] Data transmission

From: "Sengodan Senthil (NRC/Boston)" <[email-masked]>
Date: Fri, 27 Jul 2001 12:53:34 -0500

Qiaobing,

In an application server pool, an application can be accessed via one of
several PE handles (transport addresses). Irrespective of whether a PU
has been authorized to access an application or not, if it is not
authorized to access a specific transport address (or PE handle), then
it means that it was not authorized to use that specific transport
address (PE handle) to access the application. This should be checked by
the ASAP layer for proper functioning of an Rserpool system, and the
application itself will not be concerned about this.

- Senthil 

> -----Original Message-----
> From: ext Qiaobing Xie [mailto:[email-masked]]
> Sent: Friday, July 27, 2001 1:34 PM
> To: Sengodan Senthil (NRC/Boston)
> Cc: ext Qiaobing Xie; Gopal Ram (NRC/Boston); 'ext Randall Stewart';
> Miguel Angel Nieto Jimenez ECE/TL/NA TU-146 Tlf.91.339.4670;
> [email-masked]
> Subject: Re: [Rserpool] Data transmission
> 
> 
> "Sengodan Senthil (NRC/Boston)" wrote:
> > 
> > Qiaobing,
> > 
> > I think that Ram and I agree with you that data security to the
> > application itself is out of scope, and should not be 
> considered. But
> > there is a difference between being authorized to access an 
> application
> > and being authorized to access a specific transport address 
> via which
> > the application is accessed. The latter should be part of 
> Rserpool, and
> > this is what we've addressed.
> 
> Senthil,
> 
> Then please tell me what it means if a PU has been authorized 
> to access
> the application but not been authorized to access the 
> specific transport
> address on which the application is running? And who is going to make
> the decision of granting or rejecting the access to a 
> specific transport
> address?
> 
> I just don't see any practical significance or usefulness of 
> making such
> a distinction.
> 
> -Qiaobing
> 
> 
> > 
> > - Senthil
> > 
> > > -----Original Message-----
> > > From: ext Qiaobing Xie [mailto:[email-masked]]
> > > Sent: Thursday, July 26, 2001 1:05 PM
> > > To: Gopal Ram (NRC/Boston)
> > > Cc: 'ext Randall Stewart'; Sengodan Senthil (NRC/Boston); 
> Miguel Angel
> > > Nieto Jimenez ECE/TL/NA TU-146 Tlf.91.339.4670; [email-masked]
> > > Subject: Re: [Rserpool] Data transmission
> > >
> > >
> > > "Gopal Ram (NRC/Boston)" wrote:
> > > ....
> > > >
> > > > Requirement states the end name being encrypted . Secured
> > > channel has to
> > > > be established between
> > > > ENRP - PE to perform message exchange and also applies to
> > > ENRP - PU and
> > > > also between PE to autenticate
> > > > PU,  otherwise whole purpose of end name encryption becomes
> > > meaningless.
> > > >
> > >
> > > Ram,
> > >
> > > The goal of RSERPOOL security is to **protect the integrity
> > > of RSERPOOL
> > > itself**, it is NOT meant to provide data security to the 
> application
> > > above (i.e., anything between PU and PE is the 
> responsibility of the
> > > application, including server access permission, user 
> authentication,
> > > data encryption, etc). It is very important to see this
> > > difference here.
> > >
> > > -Qiaobing
> > >
> 

_______________________________________________
rserpool mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/rserpool

---

From: Qiaobing Xie <[email-masked]>
Date: Fri, 27 Jul 2001 14:16:33 -0500

Senthil,

This kind of access control is already provided by
registration/de-registration functions. E.g., if a PE does not want to
be accessed, it simply de-registers itself from the pool; if the PE is
multi-homed and does not want to be accessed through a specific
transport address, it simply re-registers itself without giving out that
transport address again.

-Qiaobing