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

From: "Dan Wing" <[email-masked]>
Date: Thu, 6 May 2010 14:52:35 -0700

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:[email-masked]] 
> Sent: Friday, March 26, 2010 11:31 AM
> To: 'Romain Biehlmann'
> Cc: [email-masked]'; '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:[email-masked]] 
> > Sent: Wednesday, March 24, 2010 1:20 AM
> > To: Dan Wing
> > Cc: [email-masked]
> > 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 <[email-masked]>:
> > >> -----Original Message-----
> > >> From: [email-masked] [mailto:[email-masked]] On
> > >> Behalf Of Romain Biehlmann
> > >> Sent: Tuesday, March 23, 2010 5:27 AM
> > >> To: [email-masked]
> > >> 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
> > >> [email-masked]
> > >> https://www.ietf.org/mailman/listinfo/avt
> > >
> > >
> > 
>

---

From: Romain Biehlmann <[email-masked]>
Date: Fri, 7 May 2010 10:35:26 +0200

Hi Dan,

Thank you for your answer: the first solution could solve the problem.
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

Romain

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 7 May 2010 07:20:38 -0700

> Sent: Friday, May 07, 2010 1:35 AM
> To: Dan Wing
> Cc: [email-masked]; Flemming Andreasen; [email-masked]

Great; that keeps things simplier.

> 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

> >> > >> In 
> http://tools.ietf.org/html/draft-ietf-avt-dtls-srtp-07 chapter

---

From: Roni Even <[email-masked]>
Date: Sat, 08 May 2010 01:47:12 +0300

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

Roni Even

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Dan Wing
> Sent: Friday, March 26, 2010 9:31 PM
> To: 'Romain Biehlmann'
> Cc: 'Flemming Andreasen'; [email-masked]
> > I actually already planned on using KTR, which uses EKT, but got
> stuck
> > by this socket problem.
> >
> > >> From that, I understand that in the case of a unicast session,
> only
> > >> designated clients? Is the sentence in the draft only applicable
> to
> > >> unicast?
> > >>

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 7 May 2010 15:54:42 -0700

> From: Roni Even [mailto:[email-masked]] 
> Sent: Friday, May 07, 2010 3:47 PM
> To: 'Dan Wing'; 'Romain Biehlmann'

No.

> keys will be sent in the multicast session and will probably 

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.

> receivers to ask for keys when joining the multicast group by 
> using RTCP ffedback.

EKT effectively does that.

-d

> Behalf Of
> applicable