Subject: RE: [Rserpool] Data transmission

From: "Gopal Ram (NRC/Boston)" <[email-masked]>
Date: Thu, 26 Jul 2001 09:31:07 -0500

Hello Stewart,

>
>"Gopal Ram (NRC/Boston)" wrote:
>> 
>> Hello Stewart,
>> 
>> See my embedded comments.
>> 
>> >
>> >See my comments as well,
>> >
>> >"Sengodan Senthil (NRC/Boston)" wrote:
>> >>
>> >> This comes with its share of problems as well. If a PU is 
>allowed to
>> >> contact a PE directly, then load sharing can be defeated, and
>> >> denial-of-service attacks can be launched.
>> >
>> >a DOS attack can always be launched no matter if you have an
>> >ASAP layer in place or not. I fail to see how you can prevent
>> >it by adding another layer....
>> >
>> >>                                            Moreover, if a 
>backdoor is
>> >> provided for bypassing the ASAP layer, then clients will
>> >likely go for
>> >> this, which would again defeat load sharing of the system.
>> >
>> >We have never found that anyone bypassed ASAP. The reason
>> >behind ASAP is session layer fault tolerance. By bypassing it
>> >the client looses this.  Your "backdoor" concept  is silly since
>> >no matter what framing you put on you are supposed to supply a
>> >service to the application. If your service is not desireable to
>> >the application they just won't use the service...
>> >
>> >Load sharing can also be defeated.. All I have to do is override
>> >what you say in my tweeked ASAP layer...
>> >
>> 
>> Yes, in today's email to Jose you had made a diagram the PU bypassing
>> the ASAP
>> layer. Bypassing a  layer in order to provide fleixibity ( this also
>> came on that email
>>   ) this is what is meant "backdoor" - no one wants
>> to overload their application - everyone will by pass if you deploy.
>> 
>
>You enforce good behavior in the internet by not forcing but
>encouraging. An application that wants to gain loadsharing and
>fault tolerance will NOT by-pass since it would loose all advantages of
>rserpool. If an application designer wishes to by-pass and not
>get these features then it will simply NOT build rserpool into
>its view. I think Qiaobing summarized it best in one of his
>emails on this thread :)
>
>> 
>> 
>> >
>> >>                                                            We had
>> >> proposed the use of an authorization token that the PU uses
>> >to contact a
>> >> PE. The PU obtains this token from the ENRP server, and 
>the PE upon
>> >> validating the token permits the PU to connect to it. 
>Moreover, this
>> >> solution is applicable irrespective of the transport protocol -
>> >> SCTP/TCP/UDP etc.
>> >>
>> >
>> >Ok, So you give away the keys to the store if the evil doer can
>> >penatrate the ENRP servers. This seems like a very bad way to go.
>> >
>> >Far better to have seperate security outside of ENRP/ASAP as the
>> >requirments state.. and not to tie the whole mess up and give away
>> >the store once the first door is opened.
>> 
>> Yes in terms of security context transfer but encrypting end name and
>> other security
>> issues are within the scope, this puts how to  authentication a  PU's
>> from   PE standpoint
>> is within the scope.
>> 
>You had better go have a look at the requirments. PU to PE
>authentication
>is NOT included in and there are specific warnings on this ... aka
>application level security especialy in terms of failover must be
>taken care of by the applications... 
>

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.

Regards
Ramg

>R
>
>> 
>> Regards
>> Ramg
>> 
>> _______________________________________________
>> rserpool mailing list
>> [email-masked]
>> http://www.ietf.org/mailman/listinfo/rserpool
>
>-- 
>Randall R. Stewart
>[email-masked] 815-342-5222 (cell phone)
>

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

---

From: Qiaobing Xie <[email-masked]>
Date: Thu, 26 Jul 2001 12:04:40 -0500

....
> 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