Re: [rtcweb] Comments on draft-ietf-rtcweb-data-channel-07

Michael Tuexen <> Tue, 25 February 2014 22:27 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B064F1A0298 for <>; Tue, 25 Feb 2014 14:27:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.498
X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_82=0.6, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RFv9qYDoxK9J for <>; Tue, 25 Feb 2014 14:27:05 -0800 (PST)
Received: from ( [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by (Postfix) with ESMTP id A1E7F1A07C1 for <>; Tue, 25 Feb 2014 14:27:01 -0800 (PST)
Received: from [] ( []) (Authenticated sender: macmic) by (Postfix) with ESMTP id D3A791C1042EC; Tue, 25 Feb 2014 23:26:59 +0100 (CET)
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Michael Tuexen <>
In-Reply-To: <>
Date: Tue, 25 Feb 2014 20:50:00 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Barry Dingle <>
X-Mailer: Apple Mail (2.1510)
Cc: "" <>,
Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-data-channel-07
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 25 Feb 2014 22:27:07 -0000

On Feb 23, 2014, at 10:54 AM, Barry Dingle <> wrote:

> In reference to your first Section 1 comments, I agree that we need to clearly differentiate the SRTP media and the SCTP media. (Note - SRTP - not RTP !)
I changed it to SRTP media...
> I agree that there could be real-time media that can be sent over SCTP Channels are still meet the criteria for 'real-time' as being 'received within a few hundred milliseconds of being generated' - see WebRTC Overview section 2.4. 
> Maybe we need to differentiate the Channel types - and then refer to the data going over those Channels. For instance,if we define "SRTP Channels" and "SCTP Channels", we could then refer to 'SRTP Channel media' which would have a specific meaning. 
> The best place for the definition of SRTP Channel and SCTP Channel is probably in the WebRTC Overview document. 
I agree...

Best regards
> Cheers,
> /Barry Dingle
> On Sat, Feb 22, 2014 at 3:27 AM, Magnus Westerlund <> wrote:
> Hi,
> (as individual)
> I have reviewed the WebRTC Data Channels draft
> (draft-ietf-rtcweb-data-channel-07) and have some comments.
> 1. Section 1:
> Non-media data types in the context of WebRTC are handled by using
>    SCTP [RFC4960] encapsulated in DTLS [RFC6347].
> There are many places in this draft where "media data" is a reference to
> the RTP transport media. I would suggest to review this and consider to
> change this to "RTP Transport media", or "RTP media". The reason is that
> I expect also real-time media to flow over the data channel.
> 2. Section 1:
> As the other SCTP extensions are discussed in the introduction, I wonder
> why NADA and PR-Policy isn't.
> 3. Section 1:
> Section 5 arguments SCTP over DTLS over UDP;
> "arguments" looks strange in the above sentence fragment.
> 4. Section 3.1:
>            Note that
>            at any time there may be no media channels, or all media
>            channels may be inactive, and that there may also be reliable
>            data channels in use.
> "no media channels" is a bit strange here as we not really call anything
> regarding RTP channels. I would suggest to change this to "RTP Packet
> Streams" or "RTP Stream".
> 5. Section 3.2:
>    U-C 7:  Proxy browsing, where a browser uses data channels of a
>            PeerConnection to send and receive HTTP/HTTPS requests and
>            data, for example to avoid local Internet filtering or
>            monitoring.
> >From a data channel perspective this doesn't look strange at all,
> however I get the shivers from the security implications of this. To my
> understanding Peer A using Peer B to proxy browse must have B fetch all
> elements that A needs into its sandbox and then transfer it to A over
> the PeerConnections Data Channel. Thus, all you do are revealed to B,
> massive privacy consideration. Or am I missing someway that A can tunnel
> its HTTP request through B without having B see the content of those
> requests, I am especially concerned with HTTPS.
> If this use case is going to stay, I do want some security consideration
> discussion around it.
> 6. Section 5:
> "   o  The congestion control is modifiable for integration with media
>       stream congestion control."
> As this statement is only partial correct. There is no current mechanism
> to negotiate congestion control, nor does it exist any alternative
> defined SCTP congestion control. Thus, I would like to have this
> sentence modified. I am however not certain to what the authors consider
> important. It is the fact that it is possible in the future to define a
> new CC algorithm and use that?
> 7. Section 5:
>    o  provides privacy for the SCTP control information.
> Is "privacy" really the right word here? Either being explicit, "source
> authentication, integrity and confidentiality" or something like "security"?
> 8. section 5:
>    DTLS implementations used for this stack SHOULD support controlling
>    fields of the IP layer like the Don't Fragment (DF)-bit in case of
>    IPv4 and the Differentiated Services Code Point (DSCP) field required
>    for supporting [I-D.ietf-rtcweb-qos].
> First of all this reference must be changed. What I am currently
> uncertain of is what it should point on, most likely
> draft-dhesikan-tsvwg-rtcweb-qos-04. But, I am not yet certain how the
> scope is going to be divided between that document and
> draft-ietf-rtcweb-transports.
> 9. Section 5:
> The initial Path MTU
>    at the IP layer MUST NOT exceed 1200 bytes for IPv4 and 1280 for
>    IPv6.
> I have to say that I think MUST NOT in the above is to strict. I think
> SHOULD NOT is appropriate. The reason is that a deployment may actually
> know that a larger initial MTU is better. This value may also change due
> to how the networks develop in the future.
> 10. Section 5:
> Since SCTP does not support the
>    negotiation of a congestion control algorithm yet, alternate
>    congestion controls SHOULD either only require a different sender
>    side behavior using existing information carried in the association
>    or need also specify a negotiation of of a congestion control
>    algorithm.
> First of all I don't like the SHOULD in this sentence.
> Secondly, I think we need to get a good agreement and statement what to
> do with SCTP's congestion control algorithm in the future. I don't like
> this statement saying basically agree on anything and use that. I think
> the IETF specification should specify something to use that we know is
> safe to deploy. Thus, I would strongly prefer this to simply to be
> changed to say that: We know we want a new congestion control that
> better can handle interaction the the RTP packet streams and its
> congestion control, but that will not be initially available. Thus use
> the specified congestion control and consider these issues. And if a new
> CC algo becomes available that can be used and should be negotiated
> between the endpoints somehow.
> 11. Section 6.1:
>    Once support for message interleaving as currently being discussed in
>    [I-D.ietf-tsvwg-sctp-ndata] is available, it SHOULD be supported.
> I don't know why you have formulated this, so awkward? NDATA is
> currently listed as a normative reference. This document is going to
> hand in the RFC-editor queue until it becomes available or an AD orders
> some rewriting. Thus, why not simply  write a simpler statement making
> clear that one SHOULD support it.
> I would also note that there are disagreement between this and the text
> in Section 6.6.:
> To overcome this
>    limitation, [I-D.ietf-tsvwg-sctp-ndata]  defines an extension to
>    support message interleaving.  Once this extension is available, it
>    MUST be used.
> Thus pick the level of requirement and then simply state that with the
> motivation why. Personally I think SHOULD would be acceptable. There are
> clear motivation why (in 6.6) why one SHOULD implelement it, and the
> basic functionality is still there if it is not supported and its usage
> will be negotiated as SCTP association creation.
> 12. Section 6.2:
>  Additionally,
>    the negotiation SHOULD include some type of congestion control
>    selection.
> Another congestion control statement that I am not happy with. See issue
> 10. There is no default and it is also not clear on what to really
> negotiate.
> 13. Section 6.3:
>    SCTP defines a stream as a unidirectional logical channel existing
>    within an SCTP association one to another SCTP endpoint.
> The "one" looks spurious.
> 14. Section 6.4:
> These priorities MUST NOT be strict priorities.
> Ok, this is one part of the agreement from the earlier meeting. There
> was also agreement on using weighted fair queuing to solve the
> priorities. The inter stream priority handling needs much firmer
> specification.
> 15. Section 6.5:
> "This can be based on the DTLS role (the client picks
>    even stream identifiers, the server odd stream identifiers) or done
>    in a different way."
> This is very unclear and you can't know what will happen. I think it
> would be better to say: Unless otherwise defined or negotiated, the
> streams are picked based on th DTLS role.  ...
> 16. Section 6.5:
> "In addition to choosing a stream, the application SHOULD also
>    inform the protocol of the options to use for sending messages."
> So what is the application, and what is the protocol in this sentence?
> 17. Section 7.
> I find this insufficient. I would this section to answer the following
> questions:
> 1. Any security issues that arise from the combination of mechanism.
> 2. Any significant issue that one needs to know about the behavior of
> the mechanisms, any of the normative specs that should be highlighted?
> 3. Clarification on what security properties one achieve with the
> defined mechanism.
> Cheers
> Magnus Westerlund
> ----------------------------------------------------------------------
> Services, Media and Network features, Ericsson Research EAB/TXM
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  +46 10 7148287
> Färögatan 6                 | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden | mailto:
> ----------------------------------------------------------------------
> _______________________________________________
> rtcweb mailing list
> _______________________________________________
> rtcweb mailing list