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

From: Magnus Westerlund <[email-masked]>
Date: Fri, 21 Feb 2014 17:27:39 +0100

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: [email-masked]
----------------------------------------------------------------------

---

From: Barry Dingle <[email-masked]>
Date: Sun, 23 Feb 2014 20:54:47 +1100

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 <
[email-masked]> wrote:

> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 25 Feb 2014 11:58:43 +0100

On 2014-02-23 10:54, 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 !)

So SRTP is an extension of RTP, in fact it is a profile, or rather two
(RTP/SAVP or RTP/SAVPF). I wrote RTP because I meant no specific RTP
configuration here, it can be any of the profiles and any of the
extensions. I know and fully support that RTCWEB uses RTP/SAVPF for RTP
transported media, however in the wider context and possible other usage
of the defined mechanism this may or may not be true. Therefore I see a
need to be generic in that discussion. If one want to emphasize the SRTP
part, then use (S)RTP.

> within a few hundred milliseconds of being generated' - see WebRTC
> Overview section 2.4.
> 
> 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.

Well, around RTP we aren't discussing "channels" at all. Thus, this
becomes very ambiguous to what it means, unless you have a definition to
go along with it.

In the context of a PeerConnection we can have one or more RTP session.

Also, I don't know what an SCTP channel is. There is an SCTP
association, which is something between two endpoints. On top of this we
have the SCTP Data channels. So what are you missing or want from these
definitions?

Cheers

Magnus Westerlund

---

From: Barry Dingle <[email-masked]>
Date: Tue, 25 Feb 2014 23:55:15 +1100

On Tue, Feb 25, 2014 at 9:58 PM, Magnus Westerlund <
[email-masked]> wrote:

> I see your point about being generic - and it is consistent with
draft-ietf-rtcweb-rtp-usage.

> I was trying to find a way to identify
(a) 'all the SCTP Streams' (or maybe "all the SCTP Channels") as well as
(b) "all the (S)RTP Streams".

As you suggested, the term "SCTP Association" seems to work for (a). Does
"RTP Session" work for (b) ??

Cheers,
/Barry Dingle

---

From: Randell Jesup <[email-masked]>
Date: Tue, 25 Feb 2014 16:59:32 -0500

> If this use case is going to stay, I do want some security consideration

I'll note that there are active projects looking to use this.  Yes, it 
will likely expose non-https data to the proxy.
https traffic should in theory be as protected as it normally is against 
proxies.

This usage would support various forms of monitoring-avoidance (and 
avoidance of relying on local network resources such as in a WiFi 
hotspot).  It's not a direct replacement for Tor, but it's also much 
less intrusive than Tor.  It inherently requires some level of trust of 
the person proxying for you.

We can expose some of the security considerations, but the primary ones 
would be dependent on how this is used, not that this protocol has the 
characteristics that would support such a use.  This is mostly saying 
"we want it to be low overhead for stream creation and initial messages 
and support a bunch of them at once".

-- 
Randell Jesup -- rjesup a t mozilla d o t com

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 25 Feb 2014 20:44:58 +0100

Hi Magnus,

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

Best regards
Michael

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

> "arguments" looks strange in the above sentence fragment.
Replaced by "discusses".
> 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>

> If this use case is going to stay, I do want some security consideration
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.
> new CC algorithm and use that?
Correct.
> 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.
> 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
> to how the networks develop in the future.
Changed.
> 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?
> currently listed as a normative reference. This document is going to
... put a consensus from an RTCWeb meeting into my words...
> 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>

> 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?
> 10. There is no default and it is also not clear on what to really
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?
> The "one" looks spurious.
Removed.
> priorities. The inter stream priority handling needs much firmer
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...
> 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).

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

> 3. Clarification on what security properties one achieve with the
Isn't/shouldn't all this be handled in the referenced documents?

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 25 Feb 2014 20:50:00 +0100

On Feb 23, 2014, at 10:54 AM, Barry Dingle <[email-masked]> 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 <[email-masked]> wrote:
> Hi,
> (as individual)
>

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 25 Feb 2014 23:33:38 +0100

> need to be generic in that discussion. If one want to emphasize the SRTP
OK, I'll use (S)RTP media...

Best regards
Michael