Re: [MMUSIC] [AVT] Sockets in multicast DTLS-SRTP

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

> -----Original Message-----
> From: Romain Biehlmann [mailto:[e-mail]] 
> Sent: Friday, May 07, 2010 1:35 AM
> To: Dan Wing
> Cc: [e-mail]; Flemming Andreasen; [e-mail]
> Subject: Re: [AVT] Sockets in multicast DTLS-SRTP
> 
> Hi Dan,
> 
> Thank you for your answer: the first solution could solve the problem.

Great; that keeps things simplier.

> I now wonder about KTR: do you consider (a) as a replacement for (b)?
> 
> (a)
> a=dtls-srtp-ktr
> a=dtls-srtp IP4 192.168.0.1 12345
> 
> (b)
> a=dtls-srtp-ktr
> a=dtls-srtp-ktr-server:12345 IN IP4 192.168.0.1

Only difference appears to be a choice of syntax.  I was intending to follow
the same syntax of ICE (I can't follow m=/c= syntax, as they put the IP
address and port on different lines).

-d


> Romain
> 
> 
> 
> On Thu, May 6, 2010 at 11:52 PM, Dan Wing <[e-mail]> wrote:
> > Romain,
> >
> > (added MMUSIC, as this is mostly about SDP in this post.)
> >
> > I talked with Flemming about this and there isn't an 
> existing SDP mechanism we
> > could easily extend to allow unicast keying of a multicast 
> session.  The
> > problem isn't just with multicast; there are some unicast 
> scenarios, such as
> > really large unicast groups, where having the 'speaker' or 
> 'mixer' do the
> > keying doesn't scale very well (and doing DTLS in a 
> separate device can
> > improve things).
> >
> > So, we would need to define a new SDP attribute that 
> indicates the DTLS-SRTP
> > peer for keying, something like this (which shows a 
> DTLS-SRTP-encrypted
> > multicast audio session),
> >
> >        v=0
> >        o=- 25678 753849 IN IP4 192.0.2.1
> >        s=
> >        t=0 0
> >        m=audio 41000 UDP/TLS/RTP/SAVP 98
> >        c=IN IP4 233.252.0.2/255
> >        a=dtls-srtp IP4 192.0.2.2 556677             <<<<<<<
> >        a=dtls-srtp IP6 2001:db8:abcd::1234 556677   <<<<<<<
> >
> > The Answerer would choose IPv6 or IPv4, and initiate a 
> DTLS-SRTP handshake
> > with that address.  However, this won't work well if the 
> DTLS-SRTP 'server' is
> > behind a NAT, and almost begs for ICE to support that 
> situation.  There seem
> > to be two approaches:  (1) avoid the problem or (2) include 
> support for ICE.
> >
> > (1) In this approach, we dictate that the DTLS-SRTP 
> server's IP address(es)
> > must be accessible to the Answerer.  This means the 
> DTLS-SRTP server has to
> > use a publicly-routed IP address.
> >
> > (2) In this approach, we use ICE, inside a=dtls-srtp 
> attribute lines, which
> > would look something like this:
> >
> >        v=0
> >        o=- 25678 753849 IN IP4 192.0.2.1
> >        s=
> >        t=0 0
> >        m=audio 41000 UDP/TLS/RTP/SAVP 98
> >        c=IN IP4 233.252.0.2/255
> >        a=dtls-srtp ice-pwd asd88fgpdd777uzjYhagZg
> >        a=dtls-srtp ice-ufrag:8hhY
> >        a=dtls-srtp candidate:1 1 UDP 2130706431 10.0.1.1 
> 8998 typ host
> >        a=dtls-srtp candidate:2 1 UDP 1694498815 192.0.2.3 
> 45664 typ srflx
> > raddr
> >   10.0.1.1 rport 8998
> >
> >
> > Would approach (1) meet your needs?
> >
> > -d
> >
> >
> >
> >> -----Original Message-----
> >> From: Dan Wing [mailto:[e-mail]]
> >> Sent: Friday, March 26, 2010 11:31 AM
> >> To: 'Romain Biehlmann'
> >> Cc: '[e-mail]'; 'Flemming Andreasen'
> >> 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
> >> > >
> >> > >
> >> >
> >>
> >
> >