Subject: [Rserpool] Re: how to use multicast in Rserpool?

From: Qiaobing Xie <[email-masked]>
Date: Wed, 10 Apr 2002 14:41:50 -0500

Hi, all

I am citing some off-line email answers from Maureen and Michael (my
fault, I should have cc'ed the list in the first place).

In general, based on responses I've got so far, it seems clear that
multicast has the following pros and cons:

pros:
  - so cheap and so efficient (if available), hard to say no to it :)
  - little setup overhead (you don't need to connect to N peers 1-by-1)

cons:
  - not reliable (sender needs to worry about retrans)
  - hard to secure
  - not always available
  - difficult to identify the payload protocol(?)

Please see my other comments in-line...

regards,
-Qiaobing

[email-masked] wrote:
> 
> my answer to #1 which is:
> 
> 1) I think that the issue of multicast security should be studied by the security design team. This didn't come up during our earlier discussions.  The IETF has a working group called Multicast Security (msec).  I'm not up on their work.  Certainly, this should be investigated.  They have no RFCs as yet and 6 I-Ds.

My feeling is that they are still far away from a solution (not to
mention the actually availability in any OS) and the solution is not
going to be cheap.

> 
> In terms of TLS and multicast, I believe that TLS and multicast don't mix.  In other words, TLS runs on top of TCP by design and is assumed to be unicast.  TLS negotiates ciphersuite, sends certificates, etc. using a client-server (assumed unicast) connection.  TLS assumes that only 2 parties are involved, the client and the server -- no group thing.  So if we want to secure multicast, we are going to have to use something other than TLS.  Eric Rescorla has offered to be our TLS/security helper.  I can send him an e-mail and see what wisdom comes back.  Since he offered to help Rserpool at the IETF Sunday reception when he autographed his SSL and TLS book for me, we should take him up on this offer.
> 

Agreed. It is a good idea to have the security team to look at the
issue.

Michael Tuexen wrote:
...snip....
> 
> Maybe we should use Multicast only for detection of other peers. Once
> we have a candidate we use secure unicast (with authentication) for
> transport.
> If someone is using the multicast stuff to attack the system he could put
> load on the system but he can't survive the authentication phase. So we
> would have to limit some rates....
> 

This is a compromise. With this approach, we still can not use multicast
for inter-ENRP server updates (e.g., propagate new registrations, etc)
if security is demanded to deploy.

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

---

From: Qiaobing Xie <[email-masked]>
Date: Wed, 10 Apr 2002 14:41:50 -0500

Hi, all

pros:

cons:

regards,
-Qiaobing

Michael Tuexen wrote:
...snip....