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

[Michael Tuexen <[e-mail]>]

On Feb 23, 2014, at 10:54 AM, Barry Dingle <[e-mail]> 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
Michael
> 
> Cheers,
> /Barry Dingle
> 
> 
> 
> On Sat, Feb 22, 2014 at 3:27 AM, Magnus Westerlund <[e-mail]> 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  [phone]
> Färögatan 6                 | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb