Re: [rtcweb] Layers in draft-jesup-rtcweb-data-00

[Eric Rescorla <[e-mail]>]

On Wed, Nov 2, 2011 at 5:44 AM, Magnus Westerlund
<[e-mail]> wrote:
> On 2011-11-01 20:37, Justin Uberti wrote:
>> I think we want one DTLS session for each transport. If we have
>> independent RTP sessions, we have N transports, and N DTLS sessions. If
>> we multiplex RTP/SCTP sessions, we have a single transport, and the same
>> DTLS session is used to protect SCTP traffic, as well as to get keys for
>> SRTP traffic.
>
> Can you please expand on this argument? I think in the case where you
> have IP/UDP/DTLS-SRTP (where DTLS-SRTP represents both the DTLS
> handshakes used to establish the keys for SRTP and SRTP) and want to
> combine it with IP/UDP/DTLS/SCTP I think you are forced to have a single
> DTLS session for that UDP flow.

I want to make sure I understand your question, you're talking about a call
with both SCTP and SRTP carried over the same UDP host-port quartet?
Yes, in that case, you would want to have a single DTLS association
(session turns out to be a technical term in TLS that means something
different than this) for that host-port quartet.

> However, what I do understand of DTLS it
> is possible to have both DTLS protected datagrams and DTLS-SRTP packets
> in the same DTLS session. However, as STUN in this case still is outside
> of the DTLS we anyway have a de-multiplexing.


       +------+                        +------+
       |WEBAPP|                        |WEBAPP|
       +------+------+------+          +------+------+------+
       | DTLS | Audio| Video|          | SCTP | Audio| Video|
 +---------------------------+   +---------------------------+
 | STUN | SCTP |S/RTP |S/RTP |   | STUN | DTLS |S/RTP |S/RTP |
 +---------------------------+   +---------------------------+
 |         Mux/Demux         |   |         Mux/Demux         |
 +---------------------------+   +---------------------------+
 |            UDP            |   |            UDP            |
 +---------------------------+   +---------------------------+

Assuming we're talking about the layering on the right,
then there are two demux phases:

1. STUN vs. DTLS vs. SRTP, which is defined in RFC 5764; S 5.1.2
2. DTLS handshake versus SCTP data (carried as TLS application_data).
   This is just part of the DTLS stack.


> Based on that you from a feasibility point of view combined DTLS-SRTP
> with IP/UDP/SCTP/DTLS and have different DTLS sessions, one on the
> IP/UDP layer and another on the IP/UDP/SCTP layer.

I'm not sure how would be best to handle the case on the
left (which is one reason I prefer the layering on the
right). My instinct was to say that if you were going
to do DTLS-SRTP you would still need to set up a
IP/UDP/SCTP/DTLS channel, so you would have only one
DTLS association. Of course, this still leaves you with
the SCTP vs. S/RTP vs. STUN demux.


> I also think we shouldn't forget what would occur if one has SRTP keyed
> in another way than DTLS as that can also proposed. Then the DTLS for
> SCTP doesn't interact with another DTLS at either IP/UDP or IP/UDP/SCTP.

I'm not sure I get this point.


> I would also like to raise the issue of DTLS resumption which to my
> knowledge is possible to use for any DTLS session between the same
> end-points after the first?

Yes. There's some discussion of the most efficient way to handle
this in Appendix B of RFC 5764. However, this should be invisible
to the endpoints, as it's just a performance optimization.

-Ekr