Subject: RE: [Rserpool] Data transmission

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

Hello Stewart,

>-----Original Message-----
>From: ext Randall Stewart at work 
>[mailto:[email-masked]]
>Sent: Wednesday, July 25, 2001 3:48 PM
>To: [email-masked]
>Cc: Qiaobing Xie; ext Qiaobing Xie; Sengodan Senthil 
>(NRC/Boston); Gopal
>Ram (NRC/Boston); Miguel Angel Nieto Jimenez ECE/TL/NA TU-146
>Tlf.91.339.4670; [email-masked]
>Subject: Re: [Rserpool] Data transmission
>
>
>Qiaobing Xie wrote:
>> 
>> Lyndon,
>> 
>> Excellent questions!
>> 
>Yes.. I could not agree more :) (Even if I have thrown around
>to many PU/PE's today :>)
>
>> Lyndon Ong wrote:
>> >
>> > Isn't guarding against DOS attacks an independent set of 
>issues from
>> > what we're trying to address, though?
>> 
>> I think what we are doing here is to define a standard 
>method of forming
>> transparent server pools for the purpose of app layer fault 
>tolerance,
>> not to solve the general DOS attack problems.
>
>Exactly.. a session layer for fault tolerance is not where you
>address DOS attacks. You do this at the transport.. or with something
>like HIP. Now after reading HIP, it may be to big of a CANNON for what
>we are doing here... TLS may be a better alternative...
>

TLS requires a change all application server. Requrirement does not
forces us to do so.
There are other ways also.  

>
>> 
>> > Or maybe the key question is do you see server pooling as 
>introducing any new methods of DOS attack?
>> 
>> I don't see the introduction of Rserpool weakens the 
>**application's**
>> defense against DOS, i.e., if your application, when running 
>on a single
>> server, has a DOS vulnerability X, it won't become more vulnerable to
>> DOS if you run it over a server pool. In the contrary, 
>running it over a
>> server pool might make the application more survivable 
>against DOS, due
>> to the increased capacity and Rserpool auto-failover mechanism.
>
>Exactly.. having alternate servers that will be available may allow
>a client to automatically deflect to the less loaded client. The
>failover
>mechanisms will kick in and move the PU over to a differnt PE (I just
>could not reset Q :>). Thus this could actually help in a DOS 
>situation,
>it surely will not increase any DOS attack potential :>
>
>
>R
>> 
>> -Qiaobing
>> 
>> >
>> > Cheers,
>> >
>> > Lyndon
>> > --
>> >
>> > On Wed, 25 Jul 2001 12:41:17   Sengodan Senthil (NRC/Boston) wrote:
>> > >
>> > >
>> > >> -----Original Message-----
>> > >> From: ext Qiaobing Xie [mailto:[email-masked]]
>> > >> Sent: Wednesday, July 25, 2001 12:59 PM
>> > >> To: Sengodan Senthil (NRC/Boston)
>> > >> Cc: ext Randall Stewart at work; Gopal Ram 
>(NRC/Boston); Miguel Angel
>> > >> Nieto Jimenez ECE/TL/NA TU-146 Tlf.91.339.4670; 
>[email-masked]
>> > >> Subject: Re: [Rserpool] Data transmission
>> > >>
>> > >>
>> > >> ...
>> > >> > > If you do decide to bypass the session layer then you loose
>> > >> > > the advantages of it... i.e. the fault 
>tolerance/fail-over and
>> > >> > > load balancing characteristics of it.. This is ok.. it is
>> > >> > > the applications choice.
>> > >> > >
>> > >> > > The point is to allow maximum flexibility for the 
>application and
>> > >> > > yet be able to provide a fault tolerant/session 
>layer service.
>> > >> > >
>> > >> > > R
>> > >> > >
>> > >> >
>> > >> > 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. 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.
>> > >>
>> > >> Senthil,
>> > >>
>> > >> I disagree. First, denial-of-service attacks can always
>> > >> happen no matter
>> > >> you allow direct communication or not. Secondly, I don't see the
>> > >> incentive for a client (PU) to side-step the ASAP load 
>balancing. It
>> > >> will more likely hurt itself than gaining anything if 
>it chooses to do
>> > >> so.
>> > >
>> > >Qiaobing,
>> > >
>> > >I agree that DOS attacks can always be launched, but the key is to
>> > >detect them early and snub them. One reason that the client may
>> > >side-step the ASAP load balancing is if he could 
>successfully mount DOS
>> > >attacks.
>> > >
>> > >>
>> > >> > 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.
>> > >>
>> > >> To me, this control is a matter of access permission to the
>> > >> specific app
>> > >> service(s) the pool is providing, and thus should be 
>architecturally
>> > >> part of the application. Session layer is not the right 
>place for
>> > >> service access control.
>> > >
>> > >Access control to the application itself comes at a later 
>stage. The
>> > >issue of access to the particular transport address (out of many
>> > >possible ones) that the application can be accessed from, 
>is what we are
>> > >considering in this case. Capability for detection and 
>prevention of DOS
>> > >attacks needs to be built into the ASAP layer, especially if the
>> > >underlying transport layer is not mandated. Just as TCP 
>stacks have
>> > >built-in mechanisms to prevent SYN attacks (a type of DOS 
>attack) and
>> > >IPSec AH prevents against DOS attacks by rapid verification of the
>> > >authenticator, similarly we should have a built-in mechanism that
>> > >prevents against DOS attacks.
>> > >
>> > >- Senthil
>> > >
>> > >>
>> > >> regards,
>> > >> -Qiaobing
>> > >>
>> > >
>> > >_______________________________________________
>> > >rserpool mailing list
>> > >[email-masked]
>> > >http://www.ietf.org/mailman/listinfo/rserpool
>> > >
>> >
>> > Join 18 million Eudora users by signing up for a free 
>Eudora Web-Mail account at http://www.eudoramail.com
>> 
>> _______________________________________________
>> 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
>

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

---

From: Qiaobing Xie <[email-masked]>
Date: Thu, 26 Jul 2001 11:56:38 -0500

"Gopal Ram (NRC/Boston)" wrote:
....
> There are other ways also.

If you are talking about legacy applications that do not have security,
then why RSERPOOL should force security to the application? After all
whether to use security or how much security is adequate is an
application decision.

-Qiaobing