Subject: RE: [Rserpool] Data transmission

From: "Sengodan Senthil (NRC/Boston)" <[email-masked]>
Date: Sat, 28 Jul 2001 10:48:22 -0500

Qiaobing,

Please see my embedded comments.

- Senthil

> -----Original Message-----
> From: ext Qiaobing Xie [mailto:[email-masked]]
> Sent: Friday, July 27, 2001 6:42 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,
> > 
> > The issue is not of a PE not wishing to be accessed via a certain
> > transport address by all PUs, but that the PE should be 
> accessed via a
> > certain transport address only if the PU is authorized (by 
> ENRP server)
> > to do so.
> 
> So what you are saying is that an ENRP server will tell a PU:
> 
>   this the pool X
>     X has 3 PEs (A, B, C)
>       A ...
>       B ...
>       C has 2 transport addresses (T1, T2), 
>         but you are only authorized to use T1 to access C.
> 
> Why you want to do this? Why can't you just tell the PU:
> 
>   this the pool X
>     X has 3 PEs (A, B, C)
>       A ...
>       B ...
>       C has 1 transport addresses T1
> 

Yes, the ENRP server would only pass out the authorized information to
the PU as in the latter case that you mention. But, consider the
following scenario of your example. The PU queries the ENRP server at a
certain time and the ENRP server returns the info that "C has two
transport addresses T1,T2" implying that the PU is authorized to use
either T1 or T2. At a subsequent time, a query by the same PU to the
ENRP server could result in the ENRP server returning "C has one
transport address T1" implying that the PU is now authorized to use T1.
For the efficient functioning of a highly reliable/available server
pool, clearly the PU should only access T1. But, what stops the PU from
accessing the application via T2 since it has this information from a
previous query? It is for this reason that the authorization token is
included.

- Senthil

> -Qiaobing
> 
> > 
> > - Senthil
> > 
> > > -----Original Message-----
> > > From: ext Qiaobing Xie [mailto:[email-masked]]
> > > Sent: Friday, July 27, 2001 3:17 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
> > >
> > >
> > > 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
> > >
> > > "Sengodan Senthil (NRC/Boston)" wrote:
> > > >
> > > > 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
> > >
> 

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

---

From: Qiaobing Xie <[email-masked]>
Date: Mon, 30 Jul 2001 13:43:27 -0500

...

Senthil,

1. what you describe here is essentially how to deal with a trusted
party that suddenly begins to do bad thing. I don't think that is in the
scope of RSERPOOL and I don't worry too much about that.

2. the most likely consequence for the disobeying PU is to be unable to
reach the PE. What incentive is that?

-Qiaobing