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

From: Magnus Westerlund <[email-masked]>
Date: Tue, 1 Nov 2011 15:10:25 +0100

On 2011-10-26 22:45, Michael Tüxen wrote:
> 
> On Oct 26, 2011, at 10:28 PM, Hadriel Kaplan wrote:

>> But rather this:
>>
>>        +------+                        +------+
>>        |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            |
>> +---------------------------+   +---------------------------+
>>
>> [Note: "S/RTP" = SRTP/SRTCP or RTP/RTCP, "Mux/Demux" = tiny logic to mux/demux]
>>
>> Because the audio/video streams may be using the same UDP port, right?
>>
>> And the two "S/RTP" boxes may be just one box depending on how the MMUSIC multiplexing decision turns out.
>>
>> So if we want to choose the left one, because we expect/want that someday the Operating System provides a SCTP/UDP stack in the kernel, and I think we do, could it do so while demuxing and letting STUN, RTP, and DTLS go up to the app layer?  (i.e., given a socket/BIO/FD model)  I have no idea about such things... just asking.
> This is not possible today. The demultiplexing seems to be specific to this scenario.
> Not sure it fits. For demuxing you use the first byte to distinguish STUN from DTLS and SRTP.
> The first byte us the high order byte of the source port. Once could require
> SCTP to use source ports with the high order byte > 192. That might work.
> However, you would need to get the Mux/Demux into the kernel. Could be done
> using a socket option. But I'm not sure it really fits. Maybe Randy has an
> opinion.
> 

Michael,

I think one of the reasons there is discussion of use land
implementations of SCTP is so that you can do the above stack diagrams
with SCTP above UDP that is being shared for several purposes.

I would also like to correct Hadriel's picture slightly:

>>        +------+                        +------+
>>        |WEBAPP|                        |WEBAPP|
>>        +------+------+------+          +------+------+------+
>>        | DTLS |Audio & Video|          | SCTP |Audio & Video|
>> +---------------------------+   +---------------------------+
>> | STUN | SCTP | DTLS-SRTP   |   | STUN | DTLS | DTLS-SRTP   |
>> +---------------------------+   +---------------------------+
>> |         Mux/Demux         |   |         Mux/Demux         |
>> +---------------------------+   +---------------------------+
>> |            UDP            |   |            UDP            |
>> +---------------------------+   +---------------------------+

I think the above indicating that the common RTP session, potentially
being a DTLS-SRTP keyed RTP session that can co-exist on the same UDP flow.

To make the left one work, I think one has to have a source port where
the first byte value is 192-255 as the de-multiplexing table from
section 5.1.2 of RFC 5764 shows these to be the only available.

Thus I think the options are:

A. Left figure above. (source port must be in 49152-65535)

B. Right figure above

C. SCTP in its own UDP flow plus one UDP flow for each RTP session.

If we would pick SCTP then I think we must have either A+C or B+C working.

cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Michael Tüxen <[email-masked]>
Date: Tue, 1 Nov 2011 16:19:29 +0100

> If we would pick SCTP then I think we must have either A+C or B+C working.
And you want one DTLS connection for key derivation of SRTP and a
separate one for SCTP? Or must they be the same?

Best regards
Michael

---

From: Justin Uberti <[email-masked]>
Date: Tue, 1 Nov 2011 15:37:05 -0400

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.

On Tue, Nov 1, 2011 at 11:19 AM, Michael Tüxen <
[email-masked]> wrote:

> >>> So if we want to choose the left one, because we expect/want that
> someday the Operating System provides a SCTP/UDP stack in the kernel, and I
> think we do, could it do so while demuxing and letting STUN, RTP, and DTLS
> go up to the app layer?  (i.e., given a socket/BIO/FD model)  I have no
> idea about such things... just asking.
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Michael Tüxen <[email-masked]>
Date: Wed, 2 Nov 2011 12:57:26 +0100

On Nov 1, 2011, at 8:37 PM, 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.
OK, thanks for the clarification.

Best regards
Michael
> 
> On Tue, Nov 1, 2011 at 11:19 AM, Michael Tüxen <[email-masked]> wrote:

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 2 Nov 2011 13:44:14 +0100

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

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

Cheers

Magnus Westerlund

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 2 Nov 2011 07:24:35 -0700

On Wed, Nov 2, 2011 at 5:44 AM, Magnus Westerlund
<[email-masked]> wrote:
> 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

       +------+                        +------+
       |WEBAPP|                        |WEBAPP|

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.

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

> SCTP doesn't interact with another DTLS at either IP/UDP or IP/UDP/SCTP.

I'm not sure I get this point.

> 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

---

From: Wolfgang Beck <[email-masked]>
Date: Fri, 4 Nov 2011 15:21:49 +0100

On Wed, Oct 26, 2011 at 10:28 PM, Hadriel Kaplan <[email-masked]> wrote:
..
Has somebody tried to map the relevant combinations into SDP? We can
exclude Audio, Video[/DTLS]/SCTP, right?

Do we have to express the contents of the generic data in a similar
way we are describing the contents -- codecs and parameters -- for RTP
streams?

Wolfgang Beck

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 9 Nov 2011 15:17:46 +0100

> way we are describing the contents -- codecs and parameters -- for RTP

I at least expect that something will be defined similar to COMEDIA RFC
4145 or RFC 4572 for TLS.

cheers

Magnus Westerlund