Subject: RE: [Rserpool] Data transmission

From: "Sengodan Senthil (NRC/Boston)" <[email-masked]>
Date: Wed, 25 Jul 2001 17:09:42 -0500

Lyndon,

As you indicate and as Qiaobing and Ram Gopal mentioned in subsequent
emails, vulnerability to DOS attacks does not increase - with the
exception that such a system may be more attractive for attack. However,
as also pointed out by Ram Gopal, if several PUs are allowed to directly
contact a PE bypassing the ASAP layer, then a load-balanced system is
not present anymore. This leads to added delay when a PU uses the ASAP
layer and contacts such an overloaded PE, and has to be redirected to a
different PE. Had all PUs gone through the ASAP layer, this scenario
will be avoided leading to lesser delays.

Given this, a PU can also pass through an ASAP layer but still contact
an ASAP server that it is not authorized to contact (say due to
overload), if no information indicating that the PU has been authorized
by the ENRP server to contact the PE is included.

- Senthil

> -----Original Message-----
> From: ext Lyndon Ong [mailto:[email-masked]]
> Sent: Wednesday, July 25, 2001 2:18 PM
> To: ext Qiaobing Xie; 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
> 
> 
> 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 17:57:48 -0500

"Sengodan Senthil (NRC/Boston)" wrote:
> exception that such a system may be more attractive for attack. 

This sounds very speculative to me. We may need to confirm this with
some hackers :-)

> However,

This scenario itself is quite faulty. For instance, if the
load-balancing policy in use by the pool is "least loaded", it is
obvious that those "bad" PUs (i.e., those who are bypassing the ASAP
layer) will end up with using a heavily loaded PE and suffering the
delay caused by themselves, while the "good" PUs (i.e. those who do use
ASAP) will always have a good chance of avoiding that heavily loaded PE
due to the load-balancing performed in ASAP.

This is exactly how we should enforce good behaviors in Internet.

> by the ENRP server to contact the PE is included.

When the ENRP server approved the name query by the PU and responded
with a list of PEs (i.e., your "ASAP server"), it in effect has already
authorized the access of any one of the PEs on the list. 

If you are talking about the PU intentionally disregarding the
load-sharing policy, then we are back to the previous question and my
above comments applies.

-Qiaobing