Subject: RE: [Rserpool] Data transmission

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

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

---

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

Hello Qiaobing,

Please see my embedded comments.

Regards
Ramg

>
>
>Lyndon,
>
>Excellent questions!
>
>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.
>
>> 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.
>
 
I am not commenting on your statement i just want to add that any thing
which people claims it is
secured or protected , hackers/crackers  always take a chance.

As per the requirement scope of Rserverpool  is not internet wide. It is
to some extent a 
protected network ( due to end name being  encrpted or some secuired
message exchanges etc).
Any thing which is said to be protected is considered a place of
attaction for attacks. 

I do not want to say that the it will more vulnerable by being part of
Rservpool. But we can feel 
that since PE is supposed to server for Rserverpool ( some what
protected system in logically) 
it is  attractive piece for hackers. 

> 
>> 
>> Cheers,
>> 
>> Lyndon
>> --
>> 
>> On Wed, 25 Jul 2001 12:41:17   Sengodan Senthil (NRC/Boston) wrote:
>> >
>> >
>> Join 18 million Eudora users by signing up for a free Eudora 
>Web-Mail account at http://www.eudoramail.com
>

---

From: "Lyndon Ong" <[email-masked]>
Date: Wed, 25 Jul 2001 15:16:54 -0700

Then I think the problem is really defining what we want as
"load-sharing", whether this is restrictive or non-restrictive
towards the application.  It would be good to get some more
views on this from other people on the list (if there are 
more views!) and in the meeting in London.

Cheers,

Lyndon 
--

On Wed, 25 Jul 2001 17:09:42   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. 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
>
>> From: ext Lyndon Ong [mailto:[email-masked]]
>> Sent: Wednesday, July 25, 2001 2:18 PM
>> To: ext Qiaobing Xie; Sengodan Senthil (NRC/Boston)
>> Subject: RE: [Rserpool] Data transmission
>> 
>> 
>> 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  
>> --
>> 

Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at http://www.eudoramail.com

---

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

Hello Qiaobing,

Oops!  I forget to provide the weblink for the Cryptogram article
http://www.counterpane.com/crypto-gram-0107.html

regards
Ramg

>From: Gopal Ram (NRC/Boston) 
>Sent: Wednesday, July 25, 2001 8:09 PM
>To: 'ext Qiaobing Xie'; Rserpool list
>>"Sengodan Senthil (NRC/Boston)" wrote:
>>> 
>>> Lyndon,
>>> 
>>> 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,
>>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.
>>
>>> 
>>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
>>>

---

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

Hello Qiaobing,

regards
Ramg

---

From: "Lyndon Ong" <[email-masked]>
Date: Fri, 27 Jul 2001 13:54:51 -0700

This is a minor terminology nit, but is PE handle equivalent to
transport address?  Each PE has one or more transport addresses,
but I thought 1 PE handle that is really a logical identifier...

Lyndon 
--

On Fri, 27 Jul 2001 12:53:34   Sengodan Senthil (NRC/Boston) wrote:
>Qiaobing,
>
>In an application server pool, an application can be accessed via one of
>several PE handles (transport addresses). Irrespective of whether a PU
>has been authorized to access an application or not, if it is not
>authorized to access a specific transport address (or PE handle), then
>it means that it was not authorized to use that specific transport
>address (PE handle) to access the application. This should be checked by
>the ASAP layer for proper functioning of an Rserpool system, and the
>application itself will not be concerned about this.
>
>- Senthil 
>
>> Sent: Friday, July 27, 2001 1:34 PM
>> Cc: ext Qiaobing Xie; Gopal Ram (NRC/Boston); 'ext Randall Stewart';
>> Miguel Angel Nieto Jimenez ECE/TL/NA TU-146 Tlf.91.339.4670;
>> [email-masked]
>> > I think that Ram and I agree with you that data security to the
>> > application itself is out of scope, and should not be 
>> considered. But
>> > there is a difference between being authorized to access an 
>> application
>> > and being authorized to access a specific transport address 
>> via which
>> > the application is accessed. The latter should be part of 
>> Rserpool, and
>> > this is what we've addressed.
>> 
>> Senthil,
>> 
>> Then please tell me what it means if a PU has been authorized 
>> to access
>> the application but not been authorized to access the 
>> specific transport
>> address on which the application is running? And who is going to make
>> the decision of granting or rejecting the access to a 
>> specific transport
>> address?
>> 
>> I just don't see any practical significance or usefulness of 
>> making such
>> a distinction.
>> 
>> -Qiaobing
>> 
>> 
>> > 
>> > - Senthil
>> > 
>> > > Sent: Thursday, July 26, 2001 1:05 PM
>> > > To: Gopal Ram (NRC/Boston)
>> > > Cc: 'ext Randall Stewart'; Sengodan Senthil (NRC/Boston); 
>> Miguel Angel
>> > > "Gopal Ram (NRC/Boston)" wrote:
>> > > ....
>> > > >
>> > > > Requirement states the end name being encrypted . Secured
>> > > channel has to
>> > > > be established between
>> > > > ENRP - PE to perform message exchange and also applies to
>> > > ENRP - PU and
>> > > > also between PE to autenticate
>> > > > PU,  otherwise whole purpose of end name encryption becomes
>> > > meaningless.
>> > > >
>> > >
>> > > Ram,
>> > >
>> > > The goal of RSERPOOL security is to **protect the integrity
>> > > of RSERPOOL
>> > > itself**, it is NOT meant to provide data security to the 
>> application
>> > > above (i.e., anything between PU and PE is the 
>> responsibility of the
>> > > application, including server access permission, user 
>> authentication,
>> > > data encryption, etc). It is very important to see this
>> > > difference here.
>> > >
>> > > -Qiaobing
>> > >
>> 
>

---

From: "Guo, Xingang" <[email-masked]>
Date: Fri, 27 Jul 2001 14:02:14 -0700

If a PU is allowed to bypass ASAP and contact PE directly, will a PE has to
be able to handle both PE handle and transport handle?

--Xingang

> From: Lyndon Ong [mailto:[email-masked]]
> Sent: Friday, July 27, 2001 1:55 PM
> Cc: Gopal Ram (NRC/Boston); 'ext Randall Stewart'; Miguel Angel Nieto
> Jimenez ECE/TL/NA TU-146 Tlf.91.339.4670; [email-masked]

---

From: "Sengodan Senthil (NRC/Boston)" <[email-masked]>
Date: Fri, 27 Jul 2001 16:50:32 -0500

Qiaobing,

The issue is not of a PE not wishing to be accessed via a certain
transport address by all PUs, but that the PE should be accessed via a
certain transport address only if the PU is authorized (by ENRP server)
to do so.

- Senthil

> Sent: Friday, July 27, 2001 3:17 PM
> This kind of access control is already provided by
> registration/de-registration functions. E.g., if a PE does not want to
> be accessed, it simply de-registers itself from the pool; if the PE is
> multi-homed and does not want to be accessed through a specific
> transport address, it simply re-registers itself without 
> giving out that
> transport address again.
> 
> -Qiaobing
>

---

From: "Sengodan Senthil (NRC/Boston)" <[email-masked]>
Date: Sat, 28 Jul 2001 11:24:48 -0500

Lyndon,

You're right - I should not have included the term "PE handle" in my
email.

- Senthil

> Sent: Friday, July 27, 2001 4:55 PM