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 5F83E1A0298 for <>; Tue, 25 Feb 2014 14:27:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wTjPxFW0SCGI for <>; Tue, 25 Feb 2014 14:27:00 -0800 (PST)
Received: from ( [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by (Postfix) with ESMTP id 362791A079F for <>; Tue, 25 Feb 2014 14:27:00 -0800 (PST)
Received: from [] ( []) (Authenticated sender: macmic) by (Postfix) with ESMTP id 61C271C1042E2; Tue, 25 Feb 2014 23:26:58 +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:44:58 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Magnus Westerlund <>
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:05 -0000

Hi Magnus,

thank you very much for the detailed review.
Please see my comments below.

Best regards

On Feb 21, 2014, at 5:27 PM, 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.
OK. Based on another suggestion on the mailing list, I use
SRTP media. Although 'non SRTP media' looks strange...
> 2. Section 1:
> As the other SCTP extensions are discussed in the introduction, I wonder
> why NADA and PR-Policy isn't.
most likely they were not required when this text was written...

So I changed it to:

<t>SCTP as specified in <xref target='RFC4960'/> with the partial reliability
extension defined in <xref target='RFC3758'/> and the additional policies
defined in <xref target='I-D.ietf-tsvwg-sctp-prpolicies'/>
provides multiple streams natively with reliable, and the relevant 
partially-reliable delivery modes for user messages.
Using <xref target='I-D.ietf-tsvwg-sctp-ndata'/> allows to interleave
large messages to avoid the monopolization and adds the support of
prioritising of SCTP streams.</t>

> 3. Section 1:
> Section 5 arguments SCTP over DTLS over UDP;
> "arguments" looks strange in the above sentence fragment.
Replaced by "discusses".
> 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".
According to the above change it reads now:

Note that at any time there may be no SRTP media channels, or all SRTP media
channels may be inactive, and that there may also be reliable data channels
in use.</t>

> 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.
Lets discuss whether this will stay or not... I find it an interesting
use case, would prefer to keep it, and would therefore prefer to
deal with it appropriately in the security considerations.
> 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"?
The bullet list focuses on the benefits of using SCTP/DTLS/UDP instead
of DTLS/SCTP/UDP as indicated by the sentence before the bullet list.
Source authentication and integrity for SCTP control information is
also provided by DTLS/SCTP/UDP, since you can protect it by the AUTH chunk.
Privacy, however, for this information can't be provided by DTLS/SCTP/UDP,
since only the user data is encrypted. So I guess the bullet point as
cited above is correct.
> 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.
I think it is much better to move the DSCP text to
I-D.ietf-tsvwg-sctp-dtls-encaps, where corresponding text regarding the DF bit
already exists and just get rid of the above paragraph.
If OK, this might be a WG LC comment on I-D.ietf-tsvwg-sctp-dtls-encaps
> 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.
The intention of the above sentence to make clear that such a CC can either
be a sender side only mechanism or needs to add negotiation within the
association setup. Not more. Not less. This goes back to a discussion
at an IETF session. For me the paragraph basically covers what you want.
Could you be more specific, where you disagree?
> 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
... put a consensus from an RTCWeb meeting into my words...
> 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.
OK. Makes sense to me. What about:

<t>The support for message interleaving as defined in
<xref target='I-D.ietf-tsvwg-sctp-ndata'/> SHOULD be used.</t>

> 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.
OK. Changed to:

To overcome this limitation, <xref target='I-D.ietf-tsvwg-sctp-ndata'/>
defines an extension to support message interleaving, which SHOULD be used.

So it is consistently SHOULD. The question is why SHOULD. So when not to
use it? Currently the problem is the availability of stable code, but
that is not an argument for a SHOULD vs. a MUST, right?
> 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.
The default is the standard one. Currently there is no other and there
is no way for negotiation. So how to deal with it? Add a statement about
the default? Or remove the negotiation now and add it to a document
defining an alternate CC?
> 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.
My question: What are the requirements from user JS application.
I would like to leave as much room as possible for implementing
these requirements...So up to know I have heard non-strict priorities...

This needs to be in tune with the W3C...
> 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.  ...
OK. It reads now:

Unless otherwise defined or negotiated, the streams are picked based on
the DTLS role (the client picks even stream identifiers,
the server odd stream identifiers).

> 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?
Good question... The whole paragraph reads strange... So I changed its
end to:
In addition to choosing a stream, the application SHOULD also determine the
the options to use for sending messages.
The application MUST ensure in an application-specific manner that
the application at the peer will also know selected stream to
be used, and the options for sending data from that side.</t>

> 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.
Isn't/shouldn't all this be handled in the referenced documents?
> 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