Subject: RE: [Rserpool] Data transmission

From: "Lyndon Ong" <[email-masked]>
Date: Wed, 25 Jul 2001 11:17:40 -0700

Isn't guarding against DOS attacks an independent set of issues from 
what we're trying to address, though?  Or maybe the key question is do you see server pooling as introducing any new methods of DOS attack?

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

---

From: Qiaobing Xie <[email-masked]>
Date: Wed, 25 Jul 2001 14:06:15 -0500

Lyndon,

Excellent questions!

Lyndon Ong wrote:
> 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.

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

-Qiaobing

---

From: Randall Stewart at work <[email-masked]>
Date: Wed, 25 Jul 2001 14:48:18 -0500

> Excellent questions!
Yes.. I could not agree more :) (Even if I have thrown around
to many PU/PE's today :>)

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

> 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

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