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

[Magnus Westerlund <[e-mail]>]

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  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------