About non rtcp-mux and DTLS connections

Hi, there is in ORTC's Github site an interesting subject about how
many DTLS connections may take place when rtcp-mux is not used:

https://github.com/openpeer/ortc/issues/134


In order to summarize it:


1) Slide 6 in this document shown in IETF 90 says:
------------------------------
Some lack of clarity about how many DTLS
connections when no RTCP-mux
- The right answer is two per media stream
Proposed resolution: make this clear in doc.
-------------------------------


2) RFC 5764 Section 3 says:
--------------------------------
Between a single pair of participants, there may be multiple media
sessions. There MUST be a separate DTLS-SRTP session for each
distinct pair of source and destination ports used by a media session
(though the sessions can share a single DTLS session and hence
amortize the initial public key handshake!).
--------------------------------


3) RFC 5764 Section 4.2 says:
---------------------------------

   When both RTCP and RTP use the same source and destination ports,
   then both the SRTP and SRTCP keys are needed.  Otherwise, there are
   two DTLS-SRTP sessions, one of which protects the RTP packets and one
   of which protects the RTCP packets; each DTLS-SRTP session protects
   the part of an SRTP session that passes over a single source/
   destination transport address pair, as shown in Figure 2, independent
   of which SSRCs are used on that pair.  When a DTLS-SRTP session is
   protecting RTP, the SRTCP keys derived from the DTLS handshake are
   not needed and are discarded.  When a DTLS-SRTP session is protecting
   RTCP, the SRTP keys derived from the DTLS handshake are not needed
   and are discarded.

      Client            Server
     (Sender)         (Receiver)
   (1)   <----- DTLS ------>    src/dst = a/b and b/a
         ------ SRTP ------>    src/dst = a/b, uses client write keys

   (2)   <----- DTLS ------>    src/dst = c/d and d/c
         ------ SRTCP ----->    src/dst = c/d, uses client write keys
         <----- SRTCP ------    src/dst = d/c, uses server write keys

     Figure 2: A DTLS-SRTP session protecting RTP (1) and another one
    protecting RTCP (2), showing the transport addresses and keys used.
---------------------------------


4) @steely-glint says:
------------------------------------
> What does it mean that a DTLS session can be shared? does it mean that, in case of no rtcp-mux, the DTLS handshake would just take place on one of the two transports? really?

It could work - basically DTLS is just generating an SRTP key - but
how would either end know that was the intent? You’d need to signal it
somehow.
------------------------------------


For me it is clear that when a separate transport is used for RTCP
then it requires a separate DTLS connection (this is, a different DTLS
handshake and separate usage of the "use_srtp" extension, so different
keys for SRTCP).

But the end phrase of bullet 2 above kills me:

> though the sessions can share a single DTLS session and hence amortize the initial public key handshake!.

What does it mean??? is it talking about the common TLS/DTLS session
re-usage? can it be used for two *concurrent* connections? or what?

In short, if my WebRTC implementation opens a socket for SRTP and
another for SRTCP, should I expect two separate DTLS connections on
them? or should I be ready to receive an unique DTLS handshake (in
which port??) and share the key material in the other socket too? and
in that case, how to signal that?


-- 
Iñaki Baz Castillo
<ibc@aliax.net>

Received on Wednesday, 30 July 2014 13:33:59 UTC