Subject: RE: [Rserpool] Data transmission

From: "Gopal Ram (NRC/Boston)" <[email-masked]>
Date: Wed, 25 Jul 2001 15:18:42 -0500

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.

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

Regards
Ramg

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

---

From: Randall Stewart <[email-masked]>
Date: Thu, 26 Jul 2001 08:56:41 -0500

> 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 :)

> issues are within the scope, this puts how to  authentication a  PU's
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... 

R

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)