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

+Suhas

Suhas, thoughts?

On Tue, Nov 18, 2014 at 7:12 AM, Makaraju, Maridi Raju (Raju) <
Raju.Makaraju@alcatel-lucent.com> 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:mmusic-bounces@ietf.org] *On Behalf Of *Harald
> Alvestrand
> *Sent:* Tuesday, November 18, 2014 3:49 AM
> *To:* mmusic@ietf.org
> *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>:
>
>
>
>       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.
>
>
> 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.
>
>
> In this case, I guess we have to....
>
>
>
>
>
>
> On Thu, Nov 13, 2014 at 11:32 AM, Jonathan Lennox <jonathan@vidyo.com>
> wrote:
>
> 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
>
>
>
>
>
>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>
>
>
>
>
>
>  _______________________________________________
>
> mmusic mailing list
>
> mmusic@ietf.org
>
> https://www.ietf.org/mailman/listinfo/mmusic
>
>
>
>
>  --
>
> Surveillance is pervasive. Go Dark.
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>
>