Re: [AVT] Sockets in multicast DTLS-SRTP

["Dan Wing" <[e-mail]>]

 

> -----Original Message-----
> From: Roni Even [mailto:[e-mail]] 
> Sent: Friday, May 07, 2010 3:47 PM
> To: 'Dan Wing'; 'Romain Biehlmann'
> Cc: 'Flemming Andreasen'; [e-mail]
> Subject: RE: [AVT] Sockets in multicast DTLS-SRTP
> 
> Dan,
> I am not sure I understand the issue. Are you saying that for 
> multicast
> stream you suggest to send the keys as unicast streams to 
> each participants.

No.

> I am not sure this is even possible since if the session is 
> announced using
> declarative SDP for example in the SSM (single source 
> multicast) the sender
> will not know the receivers and there is no offer answer. I 
> assumed that the
> keys will be sent in the multicast session and will probably 
> will need to be
> repeated. 

Yes; EKT does that.  But we need a way for the authorized
endpoints to learn the EKT key.  DTLS-SRTP, with the extensions
to DTLS-SRTP described in draft-ietf-avt-srtp-ekt, is a way to 
accomplish that.

> One other way if the keys are not in the declarative SDP is 
> to allow the
> receivers to ask for keys when joining the multicast group by 
> using RTCP ffedback.

EKT effectively does that.

-d


> Roni Even
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of
> > Dan Wing
> > Sent: Friday, March 26, 2010 9:31 PM
> > To: 'Romain Biehlmann'
> > Cc: 'Flemming Andreasen'; [e-mail]
> > Subject: Re: [AVT] Sockets in multicast DTLS-SRTP
> > 
> > Thanks for explaining the issue.  I believe we don't yet know
> > how to have SDP associate a unicast session (for DTLS-SRTP)
> > with a multicast session (for receiving the SRTP-encrypted
> > stream).  I expect there is an answer in MMUSIC's SDP
> > Capability Negotiation and/or what is being done to mix
> > unicast and multicast in draft-ietf-avt-rapid-acquisition-for-rtp,
> > or somewhere.
> > 
> > Flemming Andreasen (CC'd) will take a look at this over the
> > next week (he is editor of SDP Capability Negotiation and
> > co-author of EKT).  But at this point I believe it will
> > require additional standards work to mix unicast/multicast.
> > 
> > -d
> > 
> > 
> > > -----Original Message-----
> > > From: Romain Biehlmann [mailto:[e-mail]]
> > > Sent: Wednesday, March 24, 2010 1:20 AM
> > > To: Dan Wing
> > > Cc: [e-mail]
> > > Subject: Re: [AVT] Sockets in multicast DTLS-SRTP
> > >
> > > Hi,
> > >
> > > And thank you for your fast answer!
> > >
> > > I actually already planned on using KTR, which uses EKT, but got
> > stuck
> > > by this socket problem.
> > >
> > > I don't get how the data should be multiplexed in the case of a
> > > multicast session since two sockets will be opened on the clients'
> > > side (as shown on the drawing below)... Or am I completely wrong?
> > >
> > > ----------
> > > | server |---- SRTP multicast session -------------------
> > > ----------                                              |
> > >   | | |                                  ------------   |
> > >   | | |--- DTLS KTR unicast session 1 ---| client 1 |---|
> > >   | |                                    ------------   |
> > >   | |                                    ------------   |
> > >   | |----- DTLS KTR unicast session 2 ---| client 2 |---|
> > >   |                                      ------------   |
> > >   |                                      ------------   |
> > >   |------- DTLS KTR unicast session 3 ---| client 3 |---|
> > >                                          ------------
> > >
> > > Thank you very much for the time you take to read me.
> > >
> > > Romain
> > >
> > >
> > >
> > > 2010/3/23 Dan Wing <[e-mail]>:
> > > >> -----Original Message-----
> > > >> From: [e-mail] [mailto:[e-mail]] On
> > > >> Behalf Of Romain Biehlmann
> > > >> Sent: Tuesday, March 23, 2010 5:27 AM
> > > >> To: [e-mail]
> > > >> Subject: [AVT] Sockets in multicast DTLS-SRTP
> > > >>
> > > >> Hi all,
> > > >>
> > > >> I hope my question is not too dumb, and not too
> > > >> implementation-oriented; if so, please accept my apologies
> > > and ignore
> > > >> it.
> > > >>
> > > >> In 
> http://tools.ietf.org/html/draft-ietf-avt-dtls-srtp-07 chapter
> > > >> 5.1.1, we can read the following:
> > > >> "When a user of DTLS wishes to send an RTP packet in 
> SRTP mode it
> > > >> delivers it to the DTLS implementation as an ordinary
> > > application data
> > > >> write (e.g., SSL_write())."
> > > >>
> > > >> From that, I understand that in the case of a unicast session,
> > only
> > > >> one socket is needed for the transmission of STUN, 
> SRTP and DTLS
> > > >> datagrams.
> > > >
> > > > Right, and demultiplexed as shown in
> > > > http://tools.ietf.org/html/draft-ietf-avt-dtls-srtp-07#section-
> > 5.1.2
> > > >
> > > >> I am not sure, though, to get how it should work in the
> > > case of a (one
> > > >> to many) multicast session.
> > > >
> > > > Use DTLS-SRTP with EKT.  EKT allows telling each of the 
> receivers
> > > > the same key.  The sender then sends the same multicast packet
> > > > (or if using unicast, the sender sends the same packet, unicast,
> > > > to each NNN receivers).
> > > >
> > > > EKT is http://tools.ietf.org/html/draft-ietf-avt-srtp-ekt-00
> > > >
> > > > -d
> > > >
> > > >> Isn't the server supposed to send SRTP datagrams to a broadcast
> > > >> address, whereas DTLS data must be sent directly to (unicast)
> > > >> designated clients? Is the sentence in the draft only 
> applicable
> > to
> > > >> unicast?
> > > >>
> > > >> I thank you in advance for your valuable insight.
> > > >>
> > > >> Romain
> > > >> _______________________________________________
> > > >> Audio/Video Transport Working Group
> > > >> [e-mail]
> > > >> https://www.ietf.org/mailman/listinfo/avt
> > > >
> > > >
> > >
> > 
> > _______________________________________________
> > Audio/Video Transport Working Group
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/avt
>