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

[Barry Dingle <[e-mail]>]

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 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.

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
>