Subject: RE: [Rserpool] Data transmission

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

Hello Qiaobing,

Please see my embedded comments.

Regards
Ramg

>
>"Sengodan Senthil (NRC/Boston)" wrote:
>> 
>> 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. 
>
>This sounds very speculative to me. We may need to confirm this with
>some hackers :-)

Its good to take more opnion. Let me give an example which  may be
somewhat in similar lines,
the convergence of Telephone network with Internet - makes hacker a new
direction.

SS7 signaling systems which is now with in the protected telephone
system will integrate
with the internet network. This gives a chance for hackers to invade the
telephone 
network ( prediction). Because internet is accessible to everyone.

There is a article from counterpane  on CRYPTOGRAM , July 15 explaining
in detail. 
Basically anything which is supposed to be protected if exposed in the
public network 
will attract the attention.

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

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

---

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

"Gopal Ram (NRC/Boston)" wrote:
....
> will attract the attention.

Ram,

What you are talking here is more or less a "hacker
psychology/sociology" issue and I don't think RSERPOOL has much to do
with it. I am not an expert in hacker psychology but one thing seems
obvious to me is that most attacks are **content-related** rather than
technology-related. RSERPOOL has nothing to do with the content, which
belongs entirely to the applications above RSERPOOL.

regards,
-Qiaobing

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 27 Jul 2001 15:31:29 -0500

Ram,

The phreakers got there before the crackers. ;)

--Brian

On Wed, 25 Jul 2001, Gopal Ram (NRC/Boston) wrote:

[snip]

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦