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

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

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