Subject: [MMUSIC] RFC 6544: DTLS over 4571 framing over TCP

From: Jonathan Lennox <[email-masked]>
Date: Thu, 13 Nov 2014 19:32:26 +0000

Here’s the citation from RFC 6544 for DTLS over RFC 4571 framing over TCP.

3.  Overview of Operation

   [...]

   ICE requires an agent to demultiplex STUN and application-layer
   traffic, since they appear on the same port.  This demultiplexing is
   described in [RFC5245<https://tools.ietf.org/html/rfc5245>] and is done using the magic cookie and other
   fields of the message.  Stream-oriented transports introduce another
   wrinkle, since they require a way to frame the connection so that the
   application and STUN packets can be extracted in order to
   differentiate STUN packets from application-layer traffic.  For this
   reason, TCP media streams utilizing ICE use the basic framing
   provided in RFC 4571<https://tools.ietf.org/html/rfc4571> [RFC4571<https://tools.ietf.org/html/rfc4571>], even if the application layer
   protocol is not RTP.

   When Transport Layer Security (TLS) or Datagram Transport Layer
   Security (DTLS) is used, they are also run over the RFC 4571<https://tools.ietf.org/html/rfc4571> framing
   shim, while STUN runs outside of the (D)TLS connection.  The
   resulting ICE TCP protocol stack is shown in Figure 1, with (D)TLS on
   the left side and without it on the right side.

                       +----------+
                       |          |
                       |    App   |
            +----------+----------+     +----------+----------+
            |          |          |     |          |          |
            |   STUN   |  (D)TLS  |     |   STUN   |    App   |
            +----------+----------+     +----------+----------+
            |                     |     |                     |
            |      RFC 4571<https://tools.ietf.org/html/rfc4571>       |     |      RFC 4571<https://tools.ietf.org/html/rfc4571>       |
            +---------------------+     +---------------------+
            |                     |     |                     |
            |         TCP         |     |         TCP         |
            +---------------------+     +---------------------+
            |                     |     |                     |
            |         IP          |     |         IP          |
            +---------------------+     +---------------------+

              Figure 1: ICE TCP Stack with and without (D)TLS

---

From: Justin Uberti <[email-masked]>
Date: Thu, 13 Nov 2014 12:46:03 -0800

I think that makes the framing very clear; it is unfortunate that it is
coupled to ICE, but we can fix that by revving 4571.

On the topic of naming, RFC 4572 <http://www.ietf.org/rfc/rfc4572.txt>
makes the meaning of TCP/TLS clear; it's (non-D) TLS.

However, TCP transport for media isn't guaranteed to be reliable, as
explained in 4571, Section 3 <https://tools.ietf.org/html/rfc4571#section-3>
:

      The reliable nature of a connection does not imply that a framed
      RTP stream has a contiguous sequence number ordering.  For
      example, if the connection is used to tunnel a UDP stream through
      a network middlebox that only passes TCP, the sequence numbers in
      the framed stream reflect any packet loss or reordering on the UDP
      portion of the end-to-end flow.

This necessarily implies that we want to use DTLS whenever the layer 4
transport is TCP.

We could try to be explicit about this by making the identifiers
TCP/DTLS/RTP/SAVPF and TCP/DTLS/SCTP, but this introduces some
inconsistency with RFC5763, which indicates use of DTLS via
UDP/TLS/RTP/SAVPF. (In the context of UDP, this is unambiguous, since you
would only want to run DTLS over UDP).

So I think we have two options:
a) use TCP/TLS/RTP/SAVPF and TCP/TLS/SCTP, and make it clear in the
definitions of these that DTLS is to be used here.
b) use TCP/DTLS/RTP/SAVPF and TCP/DTLS/SCTP, and live with the slight
inconsistency with the UDP variants from 5763.

Personally, I prefer b) as being less error-prone.

Lastly, for SCTP transport over DTLS over UDP, I think we should use
UDP/TLS/SCTP for consistency with 5763.

On Thu, Nov 13, 2014 at 11:32 AM, Jonathan Lennox <[email-masked]>
wrote:

>    described in [RFC5245 <https://tools.ietf.org/html/rfc5245>] and is done using the magic cookie and other
>    provided in RFC 4571 <https://tools.ietf.org/html/rfc4571> [RFC4571 <https://tools.ietf.org/html/rfc4571>], even if the application layer
>    protocol is not RTP.
>
>    Security (DTLS) is used, they are also run over the RFC 4571 <https://tools.ietf.org/html/rfc4571> framing
>             |      RFC 4571 <https://tools.ietf.org/html/rfc4571>       |     |      RFC 4571 <https://tools.ietf.org/html/rfc4571>       |
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>
>

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 18 Nov 2014 01:49:09 -0800

On 11/13/2014 12:46 PM, Justin Uberti wrote:
> I think that makes the framing very clear; it is unfortunate that it
> is coupled to ICE, but we can fix that by revving 4571.
>
> explained in 4571, Section 3
> <https://tools.ietf.org/html/rfc4571#section-3>:
>
> UDP/TLS/RTP/SAVPF. (In the context of UDP, this is unambiguous, since
> you would only want to run DTLS over UDP). 
>

I prefer b) as being more explicit. The RFC 5763 decision to use TLS as
the name for DTLS was unfortunate, and we shouldn't keep on doing it if
we don't have to.

> UDP/TLS/SCTP for consistency with 5763.

In this case, I guess we have to....

>
>
> On Thu, Nov 13, 2014 at 11:32 AM, Jonathan Lennox <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     [email-masked] <mailto:[email-masked]>

-- 
Surveillance is pervasive. Go Dark.

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Tue, 18 Nov 2014 15:12:52 +0000

+1 for option b.
IMO, use of "D" in "TCP/DTLS/RTP/SAVPF" can also be justified because of the use of RFC 4571 for framing to make TCP transport as "datagram transport" (which also allows multiplexing of STUN).

BR
Raju

From: mmusic [mailto:[email-masked]] On Behalf Of Harald Alvestrand
Sent: Tuesday, November 18, 2014 3:49 AM
To: [email-masked]
Subject: Re: [MMUSIC] RFC 6544: DTLS over 4571 framing over TCP

On 11/13/2014 12:46 PM, Justin Uberti wrote:
I think that makes the framing very clear; it is unfortunate that it is coupled to ICE, but we can fix that by revving 4571.

On the topic of naming, RFC 4572<http://www.ietf.org/rfc/rfc4572.txt> makes the meaning of TCP/TLS clear; it's (non-D) TLS.

However, TCP transport for media isn't guaranteed to be reliable, as explained in 4571, Section 3<https://tools.ietf.org/html/rfc4571#section-3>:

This necessarily implies that we want to use DTLS whenever the layer 4 transport is TCP.

We could try to be explicit about this by making the identifiers TCP/DTLS/RTP/SAVPF and TCP/DTLS/SCTP, but this introduces some inconsistency with RFC5763, which indicates use of DTLS via UDP/TLS/RTP/SAVPF. (In the context of UDP, this is unambiguous, since you would only want to run DTLS over UDP).

So I think we have two options:
a) use TCP/TLS/RTP/SAVPF and TCP/TLS/SCTP, and make it clear in the definitions of these that DTLS is to be used here.
b) use TCP/DTLS/RTP/SAVPF and TCP/DTLS/SCTP, and live with the slight inconsistency with the UDP variants from 5763.

I prefer b) as being more explicit. The RFC 5763 decision to use TLS as the name for DTLS was unfortunate, and we shouldn't keep on doing it if we don't have to.

Lastly, for SCTP transport over DTLS over UDP, I think we should use UDP/TLS/SCTP for consistency with 5763.

On Thu, Nov 13, 2014 at 11:32 AM, Jonathan Lennox <[email-masked]<mailto:[email-masked]>> wrote:

Here's the citation from RFC 6544 for DTLS over RFC 4571 framing over TCP.

3.  Overview of Operation

   [...]

   protocol is not RTP.

                       +----------+

                       |          |

                       |    App   |

            |          |          |     |          |          |

            |                     |     |                     |

            |                     |     |                     |

            |         TCP         |     |         TCP         |

            |                     |     |                     |

            |         IP          |     |         IP          |

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

mmusic mailing list

[email-masked]<mailto:[email-masked]>

--

---

From: Justin Uberti <[email-masked]>
Date: Tue, 18 Nov 2014 17:29:40 -0800

+Suhas

Suhas, thoughts?

On Tue, Nov 18, 2014 at 7:12 AM, Makaraju, Maridi Raju (Raju) <
[email-masked]> wrote:

>  +1 for option b.
>
> IMO, use of “D” in “TCP/DTLS/RTP/SAVPF” can also be justified because of
> the use of RFC 4571 for framing to make TCP transport as “datagram
> transport” (which also allows multiplexing of STUN).
>
>
>
> BR
>
> Raju
>
>
>
>
>
> *From:* mmusic [mailto:[email-masked]] *On Behalf Of *Harald
> Alvestrand
> *Sent:* Tuesday, November 18, 2014 3:49 AM
> *To:* [email-masked]
> *Subject:* Re: [MMUSIC] RFC 6544: DTLS over 4571 framing over TCP
>
>
>
> the name for DTLS was unfortunate, and we shouldn't keep on doing it if we
> don't have to.
>
>
>
>

---

From: Suhas Nandakumar <[email-masked]>
Date: Tue, 18 Nov 2014 21:35:39 -0800

Option b looks good to me as well. I can update the draft to capture this.

Also I was wondering if in JSEP or somewhere , we need to capture the fact
that we will never be sending RTP media over RFC5246 TLS Connections framed
using RFC4571 framing for TCP.

Thanks
Suhas