Subject: RE: [Rserpool] Data transmission

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

Hello Randy,

Please see the comments below:

- Senthil

> -----Original Message-----
> From: ext Randall Stewart at work 
> [mailto:[email-masked]]
> Sent: Wednesday, July 25, 2001 9:55 AM
> To: Gopal Ram (NRC/Boston)
> Cc: Miguel Angel Nieto Jimenez ECE/TL/NA TU-146 Tlf.91.339.4670;
> [email-masked]
> Subject: Re: [Rserpool] Data transmission
> 
> 
> 
> Comments below :)
> 
> "Gopal Ram (NRC/Boston)" wrote:
> > 
> > Hello Stewart,
> > Please see my embedded comments!
> > 
> > >-----Original Message-----
> > >From: ext Randall Stewart at work
> > >[mailto:[email-masked]]
> > >Sent: Wednesday, July 25, 2001 7:55 AM
> > >To: Miguel Angel Nieto Jimenez ECE/TL/NA TU-146 Tlf.91.339.4670
> > >Cc: [email-masked]
> > >Subject: Re: [Rserpool] Data transmission
> > >
> > >
> > >"Miguel Angel Nieto Jimenez ECE/TL/NA TU-146 
> Tlf.91.339.4670" wrote:
> > >>
> > >> Hi,
> > >>    I have some doubts about how data transmission is performed.
> > >> Are the associations for data transmission between ASAP endpoints
> > >> or between the ASAP under the PU and the PE? Reading the draft I
> > >> suppose that is the second one because there is not any ASAP
> > >> message defined for data transmission. If this is OK, what would
> > >> happen in the following scenario. Suppose we have two nodes, one
> > >> has two PU and the other one PE. If both PU want to communicate
> > >> with the PE there would be only one association. Then, how would
> > >> be the PUs multiplexed? Should be used different streams? Should
> > >> be used the SCTP field payloadProtocolId?
> > >>    When should the association been closed? Can be supposed that
> > >> is going to be only an answer from the PE?
> > >>
> > >> Miguel
> > >
> > >Hi Miguel:
> > >
> > >An answer.. or at least I will attempt an answer since I
> > >am not to sure about your questions :-)
> > >
> > >When a PU wants to talk to a PE.. it
> > >
> > >1) Asks ENRP where it is.
> > >2) Gets a list back of PE's that are registered under the
> > >   name... the list has the IP address/ports.
> > >
> > >3) The PU sets up an association with the PE and sends data
> > >   directly to the PE with NO ASAP formatting or any intervention.
> > >
> > >
> > >The idea is that ASAP is a SESSION layer and only handles getting
> > >two endpoints in contact with each other... It does not as such
> > >get involved in the transport of data... for example it does NOT
> > >wrap application data messages with some ASAP wrapper.. but instead
> > >just sends through the data send primitives to the SCTP stack.
> > 
> > I agree that ASAP should not do any thing with the Data which is
> > application
> > specific. But it defeats  a purpose say -  From the above statement,
> > any one (not a PU) who knows the transport address
> > of PE can directly communicate with  PE there is no need for ENRP.
> > 
> 
> Of course if you know the address you SHOULD be able to NOT use
> ENRP and talk to a applicaiton. ENRP provides you
> 
> 1) The location/port number 
> 2) Alternate PE's that can be used for redundancy.
> 3) Dynamic addition and deletion of PE's
> 
> 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. 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.

> 
> > >
> > >Now your question on two PU's and one PE on boxes is quite simple
> > >
> > >one PU (PU1) would say have a port 5555 the other PU2
> > >would have a port say 6666 and our friend the PE that both
> > >wants to talk to would have a port 8888
> > >
> > >So you would end up with an association between
> > >
> > >PU1:5555 <----->PE:8888
> > >and
> > >PU2:6666 <----->PE:8888
> > >
> > >It takes two sets of transport addresses each with a port on
> > >the respective peer to create an association.. so even
> > >if PU1 and PU2 are on the same machine the SCTP layer will
> > >know that it has two assocaiations on both sides based
> > >on the differences in port numbers.
> > >
> > >In a non-multi-homed machine you have the same situation
> > >as in TCP aka a assocaition is comprised of:
> > >
> > >Source Port+Source Address+Destination Port+Destination Address
> > >
> > >In a multi homed case it is a bit more complicated and you 
> end up with:
> > >
> > >Source Port+[Set of source addresses]+Destination Port+[Set of
> > >destination addresses]
> > >
> > >All comprising one associaition..
> > >
> > >
> > >Hope that helps..
> > >
> > >R
> > >
> > >
> > >
> > >
> > >
> > >--
> > >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
> 
> -- 
> 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: Wed, 25 Jul 2001 11:59:10 -0500

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

> We had

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.

regards,
-Qiaobing

---

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

See my comments as well,

"Sengodan Senthil (NRC/Boston)" wrote:
> denial-of-service attacks can be launched.

a DOS attack can always be launched no matter if you have an
ASAP layer in place or not. I fail to see how you can prevent
it by adding another layer....

>                                            Moreover, if a backdoor is

We have never found that anyone bypassed ASAP. The reason
behind ASAP is session layer fault tolerance. By bypassing it
the client looses this.  Your "backdoor" concept  is silly since
no matter what framing you put on you are supposed to supply a
service to the application. If your service is not desireable to
the application they just won't use the service... 

Load sharing can also be defeated.. All I have to do is override
what you say in my tweeked ASAP layer...

> solution is applicable irrespective of the transport protocol -

Ok, So you give away the keys to the store if the evil doer can
penatrate the ENRP servers. This seems like a very bad way to go.

Far better to have seperate security outside of ENRP/ASAP as the
requirments state.. and not to tie the whole mess up and give away
the store once the first door is opened.

R