Re: [MMUSIC] RFC 6544: DTLS over 4571 framing over TCP
Suhas Nandakumar <suhasietf@gmail.com> Wed, 19 November 2014 05:35 UTC
Return-Path: <suhasietf@gmail.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C73DE1ACF82 for <mmusic@ietfa.amsl.com>; Tue, 18 Nov 2014 21:35:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZBRTM1OR0O3D for <mmusic@ietfa.amsl.com>; Tue, 18 Nov 2014 21:35:41 -0800 (PST)
Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E4F41ACF67 for <mmusic@ietf.org>; Tue, 18 Nov 2014 21:35:41 -0800 (PST)
Received: by mail-pa0-f44.google.com with SMTP id et14so11363740pad.31 for <mmusic@ietf.org>; Tue, 18 Nov 2014 21:35:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rS+eq9PDe+/lMgaoURO7Q8Uu7kXjoWbiftNCH8oNBi4=; b=tB7PWDIrQ+6Im6NoP1/KQb8Vb5bgcXz8GsJK7/T9UiEBOAlcj0VRXgEqRWSbPRPmZO 6s894vrZDzRrmwlTjqLGDp5blASQzLkHtLDgrKdHz5fhHwO9w5oXtee/JJcinAQPQJ47 wuzx60c2oBN7OPXrY9ISm0ADrATVreDy/hIEVBTUUtxIEnof5DAqBV5aAmgEa9MD6y8v HtUQFcX+fPGH/M5DRo3wY4eXgDpnTnwc97PC5adREs6IbgEi3LfjNrDQFstx7rVA1kOy 6+MirFZV+cOpVVD1Lc6BkjzhRhZcfwvA5WVad4e4fffWrU+5BQ+6Z+f0ojHg7o3aZoGm YeHA==
MIME-Version: 1.0
X-Received: by 10.68.206.98 with SMTP id ln2mr42605441pbc.83.1416375339417; Tue, 18 Nov 2014 21:35:39 -0800 (PST)
Received: by 10.70.60.201 with HTTP; Tue, 18 Nov 2014 21:35:39 -0800 (PST)
In-Reply-To: <CAOJ7v-2sEawm_0=Do8SBpsqYpCwG2dni2NDj2q8UzNbmWG0DQg@mail.gmail.com>
References: <44035890-A516-4D01-A679-A85032AA10ED@vidyo.com> <CAOJ7v-3ynhUK+TCQtEDw+pAU2+njLTW4gpd3-0y7SUPw-c48=Q@mail.gmail.com> <546B1615.8010701@alvestrand.no> <E1FE4C082A89A246A11D7F32A95A17828E62AA90@US70UWXCHMBA02.zam.alcatel-lucent.com> <CAOJ7v-2sEawm_0=Do8SBpsqYpCwG2dni2NDj2q8UzNbmWG0DQg@mail.gmail.com>
Date: Tue, 18 Nov 2014 21:35:39 -0800
Message-ID: <CAMRcRGTderVJQEgJhKeC0NxvHKYUqataKcG+KXZ==dnaVK-EmA@mail.gmail.com>
From: Suhas Nandakumar <suhasietf@gmail.com>
To: Justin Uberti <juberti@google.com>
Content-Type: multipart/alternative; boundary="089e0160b784f985d805082f94ac"
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/9dheV6aBuUr93xo2C7JfE--wKZI
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] RFC 6544: DTLS over 4571 framing over TCP
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Nov 2014 05:35:45 -0000
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 On Tue, Nov 18, 2014 at 5:29 PM, Justin Uberti <juberti@google.com> wrote: > +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 >> >> >
- [MMUSIC] RFC 6544: DTLS over 4571 framing over TCP Jonathan Lennox
- Re: [MMUSIC] RFC 6544: DTLS over 4571 framing ove… Justin Uberti
- Re: [MMUSIC] RFC 6544: DTLS over 4571 framing ove… Harald Alvestrand
- Re: [MMUSIC] RFC 6544: DTLS over 4571 framing ove… Makaraju, Maridi Raju (Raju)
- Re: [MMUSIC] RFC 6544: DTLS over 4571 framing ove… Justin Uberti
- Re: [MMUSIC] RFC 6544: DTLS over 4571 framing ove… Suhas Nandakumar