Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-01.txt

From: [email-masked]
Date: Mon, 21 Oct 2013 12:13:43 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF.

	Title           : RTCWeb Data Channel Protocol
	Author(s)       : Randell Jesup
                          Salvatore Loreto
                          Michael Tuexen
	Filename        : draft-ietf-rtcweb-data-protocol-01.txt
	Pages           : 11
	Date            : 2013-10-21

Abstract:
   The Web Real-Time Communication (WebRTC) working group is charged to
   provide protocols to support for direct interactive rich
   communication using audio, video, and data between two peers' web-
   browsers.  This document specifies a simple protocol for establishing
   symmetric data channels between the peers.  It uses a two way
   handshake and allows sending of user data without waiting for the
   handshake to complete.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-protocol

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-data-protocol-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Thu, 24 Oct 2013 16:59:23 +0000

I have a question about draft-ietf-rtcweb-data-protocol-01.  The browser uses DTLS role to determine which side uses even or odd stream identifiers.  What does the application on the side sending the initial SDP offer that establishes the peer connection do if it wants to create data channels before the DTLS role can be determined?  How does the browser know if the application tries to select a disallowed stream id?  If the application asks the browser to select the stream identifier before DTLS role can be determined, what does the browser do?

Thanks,
Richard

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 24 Oct 2013 19:06:11 +0200

> I have a question about draft-ietf-rtcweb-data-protocol-01.  The browser uses DTLS role to determine which side uses even or odd stream identifiers.  What does the application on the side sending t…
Hmm. You can't setup a data channel before you have setup the SCTP association which you
can't setup before the DTLS handshake is complete. So how do you want to setup a data channel
before knowing the DTLS role?

Best regards
Michael
> 
> Thanks,
> Richard
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Justin Uberti <[email-masked]>
Date: Thu, 24 Oct 2013 11:05:02 -0700

In Chrome, the stream identifier isn't chosen until the DTLS roles are
known; as Michael says, this is fine because the DTLS roles are known
before the SCTP association starts up.

Note that the DTLS roles can change during the lifetime of the call, so the
initial role ends up being the one that is used.

On Thu, Oct 24, 2013 at 10:06 AM, Michael Tuexen <
[email-masked]> wrote:

> > I have a question about draft-ietf-rtcweb-data-protocol-01.  The browser
> uses DTLS role to determine which side uses even or odd stream identifiers.
>  What does the application on the side sending the initial SDP offer that
> establishes the peer connection do if it wants to create data channels
> before the DTLS role can be determined?  How does the browser know if the
> application tries to select a disallowed stream id?  If the application
> asks the browser to select the stream identifier before DTLS role can be
> determined, what does the browser do?

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Thu, 24 Oct 2013 18:36:38 +0000

Justin, Michael,
Thanks for the clarifications.  One more question.  What happens if the application tries to select a stream id before the DTLS role is known and it ends up selecting an invalid one?

Michael,
While it’s true that the data channel control protocol cannot open the channel with the peer before the DTLS role is known, the API allows the application to create the data channel before the DTLS role is known, in which case the sending of the Open message must wait until the SCTP association is established.  I want to know what the application is supposed to do it if needs to create data channels with preselected stream ids before the DTLS role is known.  This seems like something that the spec should make clear rather than leaving it to implementation.

Thanks,
Richard

From: Justin Uberti [mailto:[email-masked]]
Sent: Thursday, October 24, 2013 1:05 PM
To: Michael Tuexen
Cc: Ejzak, Richard P (Richard); [email-masked]
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-01.txt

In Chrome, the stream identifier isn't chosen until the DTLS roles are known; as Michael says, this is fine because the DTLS roles are known before the SCTP association starts up.

Note that the DTLS roles can change during the lifetime of the call, so the initial role ends up being the one that is used.

On Thu, Oct 24, 2013 at 10:06 AM, Michael Tuexen <[email-masked]<mailto:[email-masked]>> wrote:

Best regards
Michael
> [email-masked]<mailto:[email-masked]>

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

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 24 Oct 2013 21:20:31 +0200

> Thanks for the clarifications.  One more question.  What happens if the application tries to select a stream id before the DTLS role is known and it ends up selecting an invalid one?
I'm not completely familiar with the JS API, but if you want to select a stream, aren't
you managing the stream completely on your own. I think the DTLS role stuff is only
relevant if the streams are managed by the browser.
> While it’s true that the data channel control protocol cannot open the channel with the peer before the DTLS role is known, the API allows the application to create the data channel before the DTLS…
Can you assign the stream ID in the API? Could you point me to the text?

Best regards
Michael
> On Thu, Oct 24, 2013 at 10:06 AM, Michael Tuexen <[email-masked]> wrote:

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Thu, 24 Oct 2013 20:38:34 +0000

Hi Michael,

> From: Michael Tuexen [mailto:[email-masked]]
> Sent: Thursday, October 24, 2013 2:21 PM

> On Oct 24, 2013, at 8:36 PM, "Ejzak, Richard P (Richard)"
> <[email-masked]> wrote:
> 
> > Justin, Michael,
> > Thanks for the clarifications.  One more question.  What happens if
> the application tries to select a stream id before the DTLS role is
> known and it ends up selecting an invalid one?
> I'm not completely familiar with the JS API, but if you want to select
> a stream, aren't you managing the stream completely on your own. I
> think the DTLS role stuff is only relevant if the streams are managed
> by the browser.

If this is the intent then that clarification would be very useful.  Reading the API text again, it is clear that the browser only manages stream ids that it selects.  Does this mean that the browser stream id selection option is not compatible with the application stream id selection option?  Putting it more precisely, should we require that the application not be allowed to select stream ids prior to determining DTLS role if it expects that either side might use the browser stream id selection option?  It would be easier if the even/odd rule could be determined earlier than DTLS role establishment so that the application could use the same even/odd assignment rule for early data channel creation.

> >
> > Michael,
> > While it's true that the data channel control protocol cannot open
> the channel with the peer before the DTLS role is known, the API allows
> the application to create the data channel before the DTLS role is
> known, in which case the sending of the Open message must wait until
> the SCTP association is established.  I want to know what the
> application is supposed to do it if needs to create data channels with
> preselected stream ids before the DTLS role is known.  This seems like
> something that the spec should make clear rather than leaving it to
> implementation.

http://www.w3.org/TR/webrtc/#methods-1 describes the "id" attribute in the RTCDataChannelInit dictionary that must be the equivalent of the "stream identifier".  No other interpretation makes sense to me but please correct me if I am wrong.  Note in particular the following text within the description of the createDataChannel procedure (my parenthetical): "If the value of the id attribute is null, initialize it to a value generated by the user agent (browser), according to the WebRTC DataChannel Protocol specification, and skip to the next step. Otherwise, if the value of the id attribute is taken by an existing RTCDataChannel, throw a TBD exception and abort these steps."  So "id" must refer to "stream identifier" since there is no other id in your draft that it could refer to.

If I'm right, then it would be good if it were made clear that id refers to "stream identifier", but that is a w3c issue.  Quoting from 5.2.1 (my parentheticals for clarity): "The id was either assigned by the user agent (browser) at channel creation time (not channel opening time) or selected by the script (application). The attribute MUST return the value to which it was set when the RTCDataChannel was created (not opened)."

I used the wrong terminology in my earlier mail when I referred to "open" of the data channel when I meant "creation".  Since the data channel can be "created" before DTLS role is known and before the data channel can be opened, the quoted text above would seem to indicate that the application can never determine the stream id actually assigned to the data channel if id can't be determined at time of creation.  Justin implied that the chrome behavior does not conform to this description.  Comment, Justin?

It still seems to me that a change in the rule describing even/odd stream id assignment would be a good idea.

BR, Richard

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 25 Oct 2013 06:29:41 +0200

> If this is the intent then that clarification would be very useful.  Reading the API text again, it is clear that the browser only manages stream ids that it selects.  Does this mean that the brows…

My reading has been that once you start selecting IDs, you're 
responsible for making sure those don't collide with platform-generated 
ones, or deal with the result if they do.

The result of

A: pc.createDataChannel(label="foo") -> (channel with ID = 5, open 
message sent)
B: pc.createDataChannel(label="bar", id=5)
<open message arrives at B>

should be well defined. I don't much care what the result is, as long as 
it's well defined; closing the channel and calling the onerror() handler 
with DOMError(error="UsageError", message="Duelling paradigms") is fine 
with me.

I can't see a way to mix the two paradigms that guarantees this never 
happening.

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Fri, 25 Oct 2013 20:51:38 +0000

Hi Harald,
You said: " I can't see a way to mix the two paradigms that guarantees this never happening."  The two paradigms being browser selection vs. application selection of data channel stream ids.

I agree with this statement if the browser selection algorithm is based on DTLS role since the application needs to be able to select ids before the DTLS role is known.  It is also clear that this is not an easy problem to solve since the peers need to interact in some way before their relative roles are clearly established.

I am ok with documenting this limitation clearly (i.e., that the application should use either browser selection of stream ids or application selection of stream ids but not both together) but have a suggested alternative solution for consideration.  I would prefer a solution where the two paradigms can be "mixed", if one can be agreed.

My proposal has three elements, which together can guarantee that there are no stream id allocation conflicts between peers:
	1. The browser and application select stream ids based on initial SDP offerer/answerer role rather than DTLS role (e.g., initial offerer uses even ids, initial answerer uses odd ids).  With this rule, the offering application knows its role immediately without waiting for the DTLS or SDP handshake to occur.
	2. For early data channel creation, the browser assumes that it will take the offerer role in selecting stream ids until the application determines its role through the API (using JSEP API calls).
	3. The answerer application refrains from requesting browser selection of stream ids when creating data channels until after the browser knows it will take the answerer role (based on the sequence of JSEP API calls).  This is not a significant limitation since the answerer will typically not even create its end of the peer connection until after it receives the offer.

This approach also has the advantage of being consistent with the data channel API spec as it is currently written, which requires stream id assignment at the time of data channel creation.

Another (admittedly secondary) advantage of choosing a new selection algorithm that makes the two paradigms compatible would be that external negotiation options could use the same algorithm and also be fully compatible with the in-band options.

BR, Richard

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Harald Alvestrand
> Sent: Thursday, October 24, 2013 11:30 PM
> To: [email-masked]
> >> Sent: Thursday, October 24, 2013 2:21 PM On Oct 24, 2013, at 8:36
> PM,
> >> "Ejzak, Richard P (Richard)"
> >> I'm not completely familiar with the JS API, but if you want to
> >> select a stream, aren't you managing the stream completely on your
> >> own. I think the DTLS role stuff is only relevant if the streams are
> >> managed by the browser.
> > If this is the intent then that clarification would be very useful.
> Reading the API text again, it is clear that the browser only manages
> stream ids that it selects.  Does this mean that the browser stream id
> selection option is not compatible with the application stream id
> selection option?  Putting it more precisely, should we require that
> the application not be allowed to select stream ids prior to
> determining DTLS role if it expects that either side might use the
> browser stream id selection option?  It would be easier if the even/odd
> rule could be determined earlier than DTLS role establishment so that
> the application could use the same even/odd assignment rule for early
> data channel creation.
> 
> B: pc.createDataChannel(label="bar", id=5) <open message arrives at B>
> 
> should be well defined. I don't much care what the result is, as long
> as it's well defined; closing the channel and calling the onerror()
> handler with DOMError(error="UsageError", message="Duelling paradigms")
> is fine with me.
> 
> >> the channel with the peer before the DTLS role is known, the API
> >> allows the application to create the data channel before the DTLS
> >> role is known, in which case the sending of the Open message must
> >> wait until the SCTP association is established.  I want to know what
> >> the application is supposed to do it if needs to create data
> channels
> >> with preselected stream ids before the DTLS role is known.  This
> >> seems like something that the spec should make clear rather than
> >> leaving it to implementation.
> > http://www.w3.org/TR/webrtc/#methods-1 describes the "id" attribute
> in the RTCDataChannelInit dictionary that must be the equivalent of the
> "stream identifier".  No other interpretation makes sense to me but
> please correct me if I am wrong.  Note in particular the following text
> within the description of the createDataChannel procedure (my
> parenthetical): "If the value of the id attribute is null, initialize
> it to a value generated by the user agent (browser), according to the
> WebRTC DataChannel Protocol specification, and skip to the next step.
> Otherwise, if the value of the id attribute is taken by an existing
> RTCDataChannel, throw a TBD exception and abort these steps."  So "id"
> must refer to "stream identifier" since there is no other id in your
> draft that it could refer to.
> >
> > If I'm right, then it would be good if it were made clear that id
> refers to "stream identifier", but that is a w3c issue.  Quoting from
> 5.2.1 (my parentheticals for clarity): "The id was either assigned by
> the user agent (browser) at channel creation time (not channel opening
> time) or selected by the script (application). The attribute MUST
> return the value to which it was set when the RTCDataChannel was
> created (not opened)."
> >
> > I used the wrong terminology in my earlier mail when I referred to
> "open" of the data channel when I meant "creation".  Since the data
> channel can be "created" before DTLS role is known and before the data
> channel can be opened, the quoted text above would seem to indicate
> that the application can never determine the stream id actually
> assigned to the data channel if id can't be determined at time of
> creation.  Justin implied that the chrome behavior does not conform to
> this description.  Comment, Justin?
> >
> > It still seems to me that a change in the rule describing even/odd
> stream id assignment would be a good idea.
> >
> > BR, Richard

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 26 Oct 2013 18:30:47 -0400

Richard,

> 	1. The browser and application select stream ids based on initial SDP offerer/answerer role rather than DTLS role (e.g., initial offerer uses even ids, initial answerer uses odd ids).  With this r…

A similar issue has come up in the discussion of partial offers/answers. 
(Regarding how to assign a=mid values.) And a similar solution was proposed.

It was then rejected on the basis that sometimes both "ends" think they 
are offerers or answerers. This comes about as a result of 
signaling-only B2BUAs that play games with O/A on two legs.

	Thanks,
	Paul

---

From: Randell Jesup <[email-masked]>
Date: Sun, 27 Oct 2013 05:34:59 -0400

> I have a question about draft-ietf-rtcweb-data-protocol-01.  The browser uses DTLS role to determine which side uses even or odd stream identifiers.  What does the application on the side sending t…

The W3-level channels are assigned an ID once the DTLS roles are 
determined; until then the id is undefined (in our implementation they 
return 65535, an invalid id value - the exact action here is not yet 
speced in the W3C).

You call createDataChannel(...) one or more times.  The channel.id's 
return 65535; when onopen fires the id has been set (and perhaps before, 
there may be a small window between DTLS role setting/id-selection and 
onopen).  In fact this is the norm, as we won't offer an m=application 
line for data channels unless the first createDataChannel was called 
before createOffer (and once we support negotiationneeded, you'll be 
able to call it later, but that just means negotiationneeded will fire 
and make you call createOffer()). Once you're connected, you can call 
createDataChannel all you want with no further negotiationneeded firings.

On external negotiation, it's the application's responsibility to select 
values that won't collide by mistake with either other 
externally-negotiated values or automatically-generated ones.  There are 
no 'disallowed' values (in the range 0-65534).  You can specify an 
externally-negotiated id value before DTLS roles are set; again, it's up 
to you not to screw it up.  Generally applications won't mix 
external-negotiated channels with data-protocol negotiated ones, but 
that is possible so long as the application is moderately careful.

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

---

From: Randell Jesup <[email-masked]>
Date: Sun, 27 Oct 2013 05:45:34 -0400

On 10/26/2013 6:30 PM, Paul Kyzivat wrote:
>> You said: " I can't see a way to mix the two paradigms that 
>> guarantees this never happening."  The two paradigms being browser 
>> selection vs. application selection of data channel stream ids.

You can.  You just have to be careful.  For example, your application 
could define that pre-negotiated channels will use 100-110, and then 
specify those to both ends before association/offer/answer.  Later it 
could use data-protocol to add dynamic channels (using even-odd).  Since 
we've told both ends about 100-110, there's no problem here.  Even/odd 
is ONLY to avoid glare when both sides decide to open a channel "at the 
same time".  If you add a pre-negotiated channel after initial 
establishment, it's up to you to avoid colliding with any existing 
channels and to avoid colliding with any in-process-of-creation dynamic 
(data-protocol) channels.  There are a number of ways to avoid such a 
collision safely (never use dynamic channels; use the DTLS role or an 
existing dynamic channel id to determine even/odd, etc).

>> My proposal has three elements, which together can guarantee that 
>> there are no stream id allocation conflicts between peers:
>>     1. The browser and application select stream ids based on initial 
>> SDP offerer/answerer role rather than DTLS role (e.g., initial 
>> offerer uses even ids, initial answerer uses odd ids). With this 
>> rule, the offering application knows its role immediately without 
>> waiting for the DTLS or SDP handshake to occur.
>
> A similar issue has come up in the discussion of partial 
> offers/answers. (Regarding how to assign a=mid values.) And a similar 
> solution was proposed.
>
> It was then rejected on the basis that sometimes both "ends" think 
> they are offerers or answerers. This comes about as a result of 

Exactly why we went with DTLS roles.

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 28 Oct 2013 13:05:18 +0100

> http://www.w3.org/TR/webrtc/#methods-1 describes the "id" attribute in the RTCDataChannelInit dictionary that must be the equivalent of the "stream identifier".  No other interpretation makes sense…
I don't see in the document a statement that the id corresponds to the stream identifier.
If that is the case, it should be mentioned. The W3C document indicates that the type
of id is unsigned short?. I don't know enough JS to know if this corresponds to uint16_t
or not. If not, there is a problem...
> It still seems to me that a change in the rule describing even/odd stream id assignment would be a good idea.
It depends on the restrictions we have for external negotiation...

Best regards
Michael

---

From: Randell Jesup <[email-masked]>
Date: Mon, 28 Oct 2013 17:44:30 -0400

> or not. If not, there is a problem...

That's uint16_t, yes.  There's no specific link in the W3C draft that W3 
DataChannel id == SCTP Stream ID, but it's strongly implied and probably 
should be specified now that we allow external negotiation (before that 
it was less interesting).  Also we should specify that 65535 means "no 
id established yet" in the W3 spec.

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Tue, 29 Oct 2013 01:22:43 +0000

Hi Randell,
Thanks for suggesting the stream id assignment algorithm below.  Please bear with me a little longer.  I agree that limited coexistence of application and browser stream id selection is possible, but it seems that there are some significant restrictions.

Using in-band negotiation, I cannot see any way in which application selection and browser selection of stream ids can co-exist before DTLS roles are determined.  If application A selects an odd stream id, the only way to communicate this selection to application B's browser is via the in-band open message after the SCTP association has been established.  It doesn't help to tell application B since it can't report the information to its browser.  So if application B creates another data channel and requests browser selection of a stream id then B's browser might end up selecting the same odd stream id, since it has no way to know to avoid it.  Not unless we reserve id values exclusively for application selection.  Do you agree?  If so, we should document this restriction.

There is no problem if only browser selection of stream ids is allowed before the SCTP association is established since both applications can learn which side owns odd/even values after channel open is reported to the peer (since there has to be at least one data channel created to trigger the establishment of the SCTP association).  Now application and browser stream id selection can co-exist without a hitch.

If we assume only application selection of stream ids is allowed with in-band negotiation before the SCTP association is established, then we can also allow co-existence of application selection and browser selection of stream ids after establishment of the SCTP association, as long as there is a way for each application to determine DTLS role.  They can't use the trick in the last paragraph since the browsers haven't been asked to assign any stream ids.  Is there an API mechanism available to determine DTLS role?  Am I missing something here?

With external negotiation, only application selection of stream ids can be allowed before DTLS role is determined since the external negotiation mechanism needs to be able to report to both peers (and browsers) the stream id(s) selected.  Once DTLS role is determined then application and browser selection of stream ids could co-exist, but requires that the applications learn which DTLS roles were negotiated (same issue as above).  

Interestingly, in-band and external negotiation can co-exist before DTLS role is established as long as application selection of stream ids is used exclusively.  All forms of in-band and external negotiation can co-exist after the SCTP association is established as long as the applications know the DTLS roles.

In summary, the following combinations are allowed:

1) application selection with in-band negotiation before SCTP established and app determines DTLS role
2) browser selection with in-band negotiation before SCTP established
3) application selection with external negotiation before app determines DTLS role
4) application selection with in-band and external negotiation before SCTP established and app determines DTLS role
5) any combination of selection and negotiation after SCTP is established if DTLS role is available to app

If DTLS exchange and SCTP establishment are associated with separate offer/answer transactions, there might be a few more combinations to consider.  The list also does not describe what is possible if DTLS role is not available directly to the apps.

The above discussion might be an argument for segregating the stream ids available for application and browser selection.  There sure are plenty of them.  What do you think?  Then we wouldn't need to make DTLS role available to the app and there would only be a few restrictions on browser selection (it can't be used for external negotiation before DTLS role is determined).  And you could always have an overflow rule.

Please correct me if I have missed anything.  Thanks!

BR, Richard

> Behalf Of Randell Jesup
> Sent: Sunday, October 27, 2013 4:46 AM
> To: [email-masked]
> could use data-protocol to add dynamic channels (using even-odd).
> Since we've told both ends about 100-110, there's no problem here.
> Even/odd is ONLY to avoid glare when both sides decide to open a
> channel "at the same time".  If you add a pre-negotiated channel after
> initial establishment, it's up to you to avoid colliding with any
> existing channels and to avoid colliding with any in-process-of-
> creation dynamic

---

From: Randell Jesup <[email-masked]>
Date: Tue, 29 Oct 2013 00:45:14 -0400

On 10/28/2013 9:22 PM, Ejzak, Richard P (Richard) wrote:
> Using in-band negotiation, I cannot see any way in which application selection and browser selection of stream ids can co-exist before DTLS roles are determined.  If application A selects an odd stream id, the only way to communicate this selection to application B's browser is via the in-band open message after the SCTP association has been established.

No, the application can tell the other end that in conjunction with the 
offer (i.e. in application-specific signaling that accompanies the 
offer).  Any application using external negotiation must, in fact, 
handle external negotiation (even if that 'negotiation' is a set of 
hard-coded channel ids).

Any later non-external-negotiated channel creations will select an 
unused id of the correct even/oddness (per DTLS role).  One SHOULD 
create all initial-connection-time externally negotiated channels before 
adding any new automatic (data-protocol) ones, in order to avoid 
surprises -- though I'd be rather surprised that an application would 
mix them in that way.  If the app does, it will work fine though.

There is an implicit assumption that anything using external negotiation 
is either two instances of the same JS app or a cooperating app and 
server (those are by far the most common cases, and virtually the only 
cases), or two different apps that nonetheless know how to talk to each 
other and negotiate the channels on their own (I'll believe this when I 
see it, but it might happen).  External negotiation was added 
specifically for these pre-cooperating cases.

Also, one point perhaps missed from the W3 spec:

    7. If the value of the |id
    <http://dev.w3.org/2011/webrtc/editor/webrtc.html#dom-datachannel-id>|
    attribute is null, initialize it to a value generated by the user
    agent, according to the WebRTC DataChannel Protocol specification,
    and skip to the next step. Otherwise, if the value of the |id
    <http://dev.w3.org/2011/webrtc/editor/webrtc.html#dom-datachannel-id>|
    attribute is taken by an existing ||RTCDataChannel|
    <http://dev.w3.org/2011/webrtc/editor/webrtc.html#idl-def-RTCDataChannel>|,
    throw a |TBD| exception and abort these steps.

Note this means you can create a channel for external negotation and let 
the browser select the id (which you then would tell the other side, and 
*they* would specify it to their end).  Note that the ID will not be set 
until DTLS roles are decided (and that's when onopen should fire as 
well).  This would not be very useful for setting up channels before 
offer/answer, but once offer/answer has completed, it lets you get a 
local channel id of correct oddness without having to scan all current 
datachannels to find an unused id value (assuming you're mixing styles 
of creation).

(We may need to add a line to the IETF drafts to cover this case; need 
to check).  The application *could* just scan all known channels 
instead, that's just a pain.  And it really only matters if you mix 
types, which is likely to be rare outside of "create these N hard-coded 
channels at offer/answer time, then have some dynamic 
(automatically-assigned-id) channels that get used later if needed."

>    It doesn't help to tell application B since it can't report the information to its browser.  So if application B creates another data channel and requests browser selection of a stream id then B's browser might end up selecting the same odd stream id, since it has no way to know to avoid it.  Not unless we reserve id values exclusively for application selection.  Do you agree?  If so, we should document this restriction.

When you tell the browser/protocol that a channel has been externally 
negotiated, it will mark that as in-use of course. That's why collisions 
can only happen when the other side creates an externally-negotiated 
channel of the "wrong" oddness in a race with an automatic creation from 
this side.  This is trivially avoided when building an app.

Much of this  discussion in the mail I'm replying to is moot, since it's 
based on an incorrect assumption about mixing.

> Interestingly, in-band and external negotiation can co-exist before DTLS role is established as long as application selection of stream ids is used exclusively.  All forms of in-band and external n…

I'm not going to reply line-by-line here, since I think much of this is 
based on a slightly incorrect understanding.

> 5) any combination of selection and negotiation after SCTP is established if DTLS role is available to app

I'd put it this way:

1)  You can create any number of DataChannels before 
createOffer()/createAnswer() so long as all of them are automatically 
assigned ids (what you call browser selection).  The actual ids are 
assigned after the DTLS roles are known.

2)  You can create any number of externally-negotiated channels before 
createOffer().  There is no need for them to match DTLS roles.

3) The answerer must create any externally-negotiated channels from its 
side before the channels can be used, and also SHOULD do so before 
creating automatic channels unless the application has made sure somehow 
a collision is impossible/unlikely.   In reality, there's no reason not 
to install the externally-negotiated channels before trying to create 
more, so the point is basically moot. (Note: you don't have to install 
the externally-negotiated channels before createAnswer, though normally 
I'd suggest doing so, just before creating automatically-generated ones.)

4) You can create externally-negotiated channels and then automatically 
negotiated channels before calling createOffer.  You can even mix them, 
since the automatically-generated ones will be assigned ids later when 
DTLS role is known (and will avoid any already in-use).  I'm not sure 
this is behavior that anyone would *need*, so I see no reason to promote 
mixing in that way - but it'll work.

5) Once the association is up, the application can use the method above 
(negotiated=true but no id=N) to allocate ids without fear of collision 
with automatic channels.

This is all emergent from the even/odd selection and letting the 
protocol choose ids when not externally negotiated.

Pseudo-code:

creation:
     externally-selected-id?
         yes-> mark channel in use
             if channel already in use complain and fail
         no-> dtls role known?
             yes-> assign unused channel of correct oddness; send OPEN
             no-> queue channel id selection
     fire onopen if association is up

incoming OPEN message:
    if channel already in use
       yes-> complain (perhaps fire onerror TBD)
       no-> Mark channel in use; inform application (ondatachannel); 
send ACK

Pretty darn simple.

> If DTLS exchange and SCTP establishment are associated with separate offer/answer transactions, there might be a few more combinations to consider.  The list also does not describe what is possible…

DTLS and SCTP association establishment are async to offer/answer 
(kicked off by successful offer/answer completion).

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Tue, 29 Oct 2013 15:06:23 +0000

Hi Randell,
There is clearly a problem with terminology here that is not allowing us to converge.  Even after your explanation, I believe my issues/questions remain valid.  I understand that we are discussing the data protocol draft, but we cannot ignore the pure external negotiation case when discussing compatibility issues.

When I refer to in-band negotiation, I mean the use of the data channel protocol Open message to inform the peer browser that a specific stream id has been allocated to a data channel.

When I refer to external negotiation, I mean the case where the data channel protocol Open message is NOT used but instead both applications need to use the create data channel method on the API to each browser to create both ends of each data channel.

You apparently also use the term "external negotiation" to apply to the case where in-band negotiation needs to be augmented with additional communication (i.e., in addition to the Open message) between the applications.  I consider this just a special case of in-band negotiation.  Clear terminology to separate these cases would be useful since they have very different characteristics.  Perhaps "augmented in-band negotiation" or "hybrid in-band/external negotiation"?

The application can choose when creating a data channel via the API whether to select the stream id for the data channel or to request the browser to select the stream id.  Apparently there are cases when the application MUST use only one of these options to guarantee correct operation.

The application can also specifically request whether to send the data channel Open message once the SCTP association is established.  It is understood that if the browser does not send the Open message that the peer application must also use its API to create the other end of the data channel.

Without going through all the cases again, I think it's fair to say that the situation warrants some additional explanation (in the drafts) to describe these various cases and under what circumstances each is allowed.  Your pseudo-code does not cover all the cases, and the situation is more subtle than you describe it to be.  The current drafts are far from adequate in this regard.

Please just answer one question: How does the application determine its DTLS role (i.e., whether to request even or odd numbers when choosing to select stream ids)?  Does this need to be inferred from allocated stream ids or can the application determine it directly?

Thanks,
Richard

> Sent: Monday, October 28, 2013 11:45 PM
> To: [email-masked]
> > Thanks for suggesting the stream id assignment algorithm below.
> Please bear with me a little longer.  I agree that limited coexistence
> of application and browser stream id selection is possible, but it
> seems that there are some significant restrictions.
> >
> > Using in-band negotiation, I cannot see any way in which application
> selection and browser selection of stream ids can co-exist before DTLS
> roles are determined.  If application A selects an odd stream id, the
> only way to communicate this selection to application B's browser is
> via the in-band open message after the SCTP association has been
> established.
> 
> create all initial-connection-time externally negotiated channels
> before adding any new automatic (data-protocol) ones, in order to avoid
> There is an implicit assumption that anything using external
> negotiation is either two instances of the same JS app or a cooperating
> app and server (those are by far the most common cases, and virtually
> the only cases), or two different apps that nonetheless know how to
> talk to each other and negotiate the channels on their own (I'll
> believe this when I see it, but it might happen).  External negotiation
> was added specifically for these pre-cooperating cases.
> 
> Note this means you can create a channel for external negotation and
> let the browser select the id (which you then would tell the other
> side, and
> *they* would specify it to their end).  Note that the ID will not be
> set until DTLS roles are decided (and that's when onopen should fire as
> >    It doesn't help to tell application B since it can't report the
> information to its browser.  So if application B creates another data
> channel and requests browser selection of a stream id then B's browser
> might end up selecting the same odd stream id, since it has no way to
> know to avoid it.  Not unless we reserve id values exclusively for
> application selection.  Do you agree?  If so, we should document this
> restriction.
> 
> negotiated, it will mark that as in-use of course. That's why
> collisions can only happen when the other side creates an externally-
> negotiated channel of the "wrong" oddness in a race with an automatic
> creation from this side.  This is trivially avoided when building an
> app.
> 
> Much of this  discussion in the mail I'm replying to is moot, since
> it's based on an incorrect assumption about mixing.
> 
> > There is no problem if only browser selection of stream ids is
> allowed before the SCTP association is established since both
> applications can learn which side owns odd/even values after channel
> open is reported to the peer (since there has to be at least one data
> channel created to trigger the establishment of the SCTP association).
> Now application and browser stream id selection can co-exist without a
> hitch.
> >
> > If we assume only application selection of stream ids is allowed with
> in-band negotiation before the SCTP association is established, then we
> can also allow co-existence of application selection and browser
> selection of stream ids after establishment of the SCTP association, as
> long as there is a way for each application to determine DTLS role.
> They can't use the trick in the last paragraph since the browsers
> haven't been asked to assign any stream ids.  Is there an API mechanism
> available to determine DTLS role?  Am I missing something here?
> >
> > With external negotiation, only application selection of stream ids
> can be allowed before DTLS role is determined since the external
> negotiation mechanism needs to be able to report to both peers (and
> browsers) the stream id(s) selected.  Once DTLS role is determined then
> application and browser selection of stream ids could co-exist, but
> requires that the applications learn which DTLS roles were negotiated
> (same issue as above).
> >
> > Interestingly, in-band and external negotiation can co-exist before
> DTLS role is established as long as application selection of stream ids
> is used exclusively.  All forms of in-band and external negotiation can
> co-exist after the SCTP association is established as long as the
> applications know the DTLS roles.
> 
> > 4) application selection with in-band and external negotiation before
> > SCTP established and app determines DTLS role
> > 5) any combination of selection and negotiation after SCTP is
> > established if DTLS role is available to app
> 
> I'd put it this way:
> 
> this is behavior that anyone would *need*, so I see no reason to
> promote mixing in that way - but it'll work.
> 
> > If DTLS exchange and SCTP establishment are associated with separate
> offer/answer transactions, there might be a few more combinations to
> consider.  The list also does not describe what is possible if DTLS
> role is not available directly to the apps.
> 
> > The above discussion might be an argument for segregating the stream
> ids available for application and browser selection.  There sure are
> plenty of them.  What do you think?  Then we wouldn't need to make DTLS
> role available to the app and there would only be a few restrictions on
> browser selection (it can't be used for external negotiation before
> DTLS role is determined).  And you could always have an overflow rule.
> >
> >> channel "at the same time".  If you add a pre-negotiated channel
> >> after initial establishment, it's up to you to avoid colliding with
> >> any existing channels and to avoid colliding with any in-process-of-
> >> creation dynamic
> >>> offers/answers. (Regarding how to assign a=mid values.) And a
> >>> similar solution was proposed.
> >>>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 29 Oct 2013 11:23:04 -0400

> Exactly why we went with DTLS roles.

I'm not sure this eliminates the problem.

Is it not possible for an intermediary on the signaling path to insert 
itself in the media path, manipulating the SDP such that the two ends 
both establish the DTLS with the intermediary?

	Thanks,
	Paul

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 29 Oct 2013 08:28:21 -0700

On Tue, Oct 29, 2013 at 8:23 AM, Paul Kyzivat <[email-masked]> wrote:

> itself in the media path, manipulating the SDP such that the two ends both
> establish the DTLS with the intermediary?
>

There is a separate role negotiation for DTLS (actpass, etc.) that works
even if both sides think they are the offerer or answerer.

-Ekr

---

From: Matt Fredrickson <[email-masked]>
Date: Tue, 29 Oct 2013 10:35:36 -0500

> establish the DTLS with the intermediary?

Correct me if I'm wrong, but I thought that the SDP itself was supposed to
be signed and able to be validated (perhaps using the identity mechanism),
to explicitly catch nefarious man in the middle type scenarios such as this.

Matthew Fredrickson

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Tue, 29 Oct 2013 15:52:42 +0000

Hi Randell,
Please ignore the question at the end of my email below.  DTLS role can be determined from SDP inspection, which the application might prefer not to do, but would have to be able to do if it uses SDP for external negotiation.  Still, we should point this out in the draft(s).

BR, Richard

> Behalf Of Ejzak, Richard P (Richard)
> Sent: Tuesday, October 29, 2013 10:06 AM
> To: [email-masked]
> There is clearly a problem with terminology here that is not allowing
> us to converge.  Even after your explanation, I believe my
> issues/questions remain valid.  I understand that we are discussing the
> data protocol draft, but we cannot ignore the pure external negotiation
> case when discussing compatibility issues.
> 
> When I refer to in-band negotiation, I mean the use of the data channel
> protocol Open message to inform the peer browser that a specific stream
> id has been allocated to a data channel.
> 
> When I refer to external negotiation, I mean the case where the data
> channel protocol Open message is NOT used but instead both applications
> need to use the create data channel method on the API to each browser
> to create both ends of each data channel.
> 
> You apparently also use the term "external negotiation" to apply to the
> case where in-band negotiation needs to be augmented with additional
> communication (i.e., in addition to the Open message) between the
> applications.  I consider this just a special case of in-band
> negotiation.  Clear terminology to separate these cases would be useful
> since they have very different characteristics.  Perhaps "augmented in-
> band negotiation" or "hybrid in-band/external negotiation"?
> 
> The application can choose when creating a data channel via the API
> whether to select the stream id for the data channel or to request the
> browser to select the stream id.  Apparently there are cases when the
> application MUST use only one of these options to guarantee correct
> operation.
> 
> The application can also specifically request whether to send the data
> channel Open message once the SCTP association is established.  It is
> understood that if the browser does not send the Open message that the
> peer application must also use its API to create the other end of the
> data channel.
> 
> Without going through all the cases again, I think it's fair to say
> that the situation warrants some additional explanation (in the drafts)
> to describe these various cases and under what circumstances each is
> allowed.  Your pseudo-code does not cover all the cases, and the
> situation is more subtle than you describe it to be.  The current
> drafts are far from adequate in this regard.
> 
> Please just answer one question: How does the application determine its
> DTLS role (i.e., whether to request even or odd numbers when choosing
> to select stream ids)?  Does this need to be inferred from allocated
> stream ids or can the application determine it directly?
> 
> Thanks,
> Richard
> 
> 
> > No, the application can tell the other end that in conjunction with
> > the offer (i.e. in application-specific signaling that accompanies
> the
> > before adding any new automatic (data-protocol) ones, in order to
> > avoid surprises -- though I'd be rather surprised that an application
> > would mix them in that way.  If the app does, it will work fine
> though.
> >
> > negotiation is either two instances of the same JS app or a
> > cooperating app and server (those are by far the most common cases,
> > and virtually the only cases), or two different apps that nonetheless
> > know how to talk to each other and negotiate the channels on their
> own
> > (I'll believe this when I see it, but it might happen).  External
> > negotiation was added specifically for these pre-cooperating cases.
> >
> >     <http://dev.w3.org/2011/webrtc/editor/webrtc.html#dom-
> datachannel-
> > id>|
> >     <http://dev.w3.org/2011/webrtc/editor/webrtc.html#dom-
> datachannel-
> > id>|
> > set until DTLS roles are decided (and that's when onopen should fire
> > as well).  This would not be very useful for setting up channels
> > before offer/answer, but once offer/answer has completed, it lets you
> > get a local channel id of correct oddness without having to scan all
> > current datachannels to find an unused id value (assuming you're
> > mixing styles of creation).
> >
> > types, which is likely to be rare outside of "create these N
> > hard-coded channels at offer/answer time, then have some dynamic
> > in-band negotiation before the SCTP association is established, then
> > we can also allow co-existence of application selection and browser
> > selection of stream ids after establishment of the SCTP association,
> > as long as there is a way for each application to determine DTLS
> role.
> > haven't been asked to assign any stream ids.  Is there an API
> > mechanism available to determine DTLS role?  Am I missing something
> here?
> > >
> > browsers) the stream id(s) selected.  Once DTLS role is determined
> > then application and browser selection of stream ids could co-exist,
> > but requires that the applications learn which DTLS roles were
> > negotiated (same issue as above).
> > >
> > DTLS role is established as long as application selection of stream
> > ids is used exclusively.  All forms of in-band and external
> > negotiation can co-exist after the SCTP association is established as
> > long as the applications know the DTLS roles.
> >
> > I'm not going to reply line-by-line here, since I think much of this
> > is based on a slightly incorrect understanding.
> >
> > > 4) application selection with in-band and external negotiation
> > > before SCTP established and app determines DTLS role
> > 3) The answerer must create any externally-negotiated channels from
> > its side before the channels can be used, and also SHOULD do so
> before
> > the externally-negotiated channels before createAnswer, though
> > normally I'd suggest doing so, just before creating
> > automatically-generated
> > ones.)
> >
> > 4) You can create externally-negotiated channels and then
> > automatically negotiated channels before calling createOffer.  You
> can
> > even mix them, since the automatically-generated ones will be
> assigned
> > ids later when DTLS role is known (and will avoid any already in-
> use).
> > I'm not sure this is behavior that anyone would *need*, so I see no
> > reason to promote mixing in that way - but it'll work.
> >
> > 5) Once the association is up, the application can use the method
> > above (negotiated=true but no id=N) to allocate ids without fear of
> > collision with automatic channels.
> >
> > plenty of them.  What do you think?  Then we wouldn't need to make
> > DTLS role available to the app and there would only be a few
> > restrictions on browser selection (it can't be used for external
> > negotiation before DTLS role is determined).  And you could always
> have an overflow rule.
> > >
> > >>>> guarantees this never happening."  The two paradigms being
> > >>>> browser selection vs. application selection of data channel
> stream ids.
> > >> could define that pre-negotiated channels will use 100-110, and
> > >> then specify those to both ends before association/offer/answer.
> > >> Later
> > it
> > >> any existing channels and to avoid colliding with any
> > >> in-process-of- creation dynamic
> > >> (data-protocol) channels.  There are a number of ways to avoid
> such
> > a

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 29 Oct 2013 14:30:20 -0400

Comment at end.

On 10/29/13 11:28 AM, Eric Rescorla wrote:
>
> On Tue, Oct 29, 2013 at 8:23 AM, Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>> wrote:
>     Is it not possible for an intermediary on the signaling path to
>     insert itself in the media path, manipulating the SDP such that the
>     two ends both establish the DTLS with the intermediary?
>

I know about that. That mechanism is also used for TCP negotiation in 
SDP. And that is one place where an intermediary sometimes sticks its 
nose in explicitly to manipulate the roles, allowing both ends to be active.

In the current case, ICE and possible TURN result in getting the media 
path established without those games. So maybe there is less motivation 
for an intermediary. But still, they still seem to show up because 
administrators think they need them. And once there, couldn't the 
intermediary still end up making both ends think they are active?

	Thanks,
	Paul

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 29 Oct 2013 11:46:22 -0700

On Tue, Oct 29, 2013 at 11:30 AM, Paul Kyzivat <[email-masked]>wrote:

>> <mailto:[email-masked]>**> wrote:
> I know about that. That mechanism is also used for TCP negotiation in SDP.
> And that is one place where an intermediary sometimes sticks its nose in
> explicitly to manipulate the roles, allowing both ends to be active.
>
> path established without those games. So maybe there is less motivation for
> an intermediary. But still, they still seem to show up because

Well, it could but then they wouldn't be able to negotiate DTLS.

-Ekr

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 29 Oct 2013 14:59:45 -0400

(trimming)

On 10/29/13 2:46 PM, Eric Rescorla wrote:

>     I know about that. That mechanism is also used for TCP negotiation
>     in SDP. And that is one place where an intermediary sometimes sticks
>     its nose in explicitly to manipulate the roles, allowing both ends
>     to be active.
>
>     In the current case, ICE and possible TURN result in getting the
>     media path established without those games. So maybe there is less
>     motivation for an intermediary. But still, they still seem to show
>     up because administrators think they need them. And once there,
>     couldn't the intermediary still end up making both ends think they
>     are active?
>

Couldn't it negotiation independently on each side - becoming a true MITM.

(I'm not advocating this as a good thing. But if it is possible, there 
will be someone who wants to do it, and somebody willing to sell them 
stuff to do it.)

	Thanks,
	Paul

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 29 Oct 2013 13:47:43 -0700

On Tue, Oct 29, 2013 at 11:59 AM, Paul Kyzivat <[email-masked]>wrote:

> will be someone who wants to do it, and somebody willing to sell them stuff
> to do it.)
>

Sure, but then you would need to also intermediate the SCTP.

I'm not following what you see as the problem here.

-Ekr

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 29 Oct 2013 21:51:12 +0100

Sorry, you are wrong. Since signalling is left 100% to the application, the browser can make no assumption about the integrity of signalling messages.

Matt Fredrickson <[email-masked]> wrote:
>insert
>both
>------------------------------------------------------------------------
>

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 29 Oct 2013 21:54:09 +0100

If a mitm attack is being performed, one may perhaps assume that the attacker will also terminate and reinitialize the data channels?

Paul Kyzivat <[email-masked]> wrote:
>>              insert itself in the media path, manipulating the SDP
>such
>>         that the

---

From: Randell Jesup <[email-masked]>
Date: Tue, 29 Oct 2013 22:13:22 -0400

On 10/29/2013 4:54 PM, Harald Alvestrand wrote:
> If a mitm attack is being performed, one may perhaps assume that the 
> attacker will also terminate and reinitialize the data channels?

Yes they can set up independent SCTP/DTLS/DataChannel connections. If 
they do that, they're responsible for making sure they correctly handle 
both SCTP/DataChannel connections such that both sides are happy.

And also as to the security aspect/MITM:
Yes, which is the reason for identity verification being an option in 
the spec.

---

From: Randell Jesup <[email-masked]>
Date: Tue, 29 Oct 2013 22:39:17 -0400

> There is clearly a problem with terminology here that is not allowing us to converge.  Even after your explanation, I believe my issues/questions remain valid.  I understand that we are discussing…

I'm definitely not ignoring it.  I'm not specifying what the application 
does in the external negotiation; just how that affects the protocol 
stacks at either end.  See my pseudo-code below, which has the advantage 
of avoiding english vagueries.  I think part of the confusion comes from 
looking/thinking about the JS API, not the IETF protocol.

> When I refer to in-band negotiation, I mean the use of the data channel protocol Open message to inform the peer browser that a specific stream id has been allocated to a data channel.

Agreed.

> When I refer to external negotiation, I mean the case where the data channel protocol Open message is NOT used but instead both applications need to use the create data channel method on the API to…

Agreed.  That's how I've been using it, with what happens to decide on 
what the two apps end up using to initialize the two ends being largely 
out-of-scope to this discussion.

> You apparently also use the term "external negotiation" to apply to the case where in-band negotiation needs to be augmented with additional communication (i.e., in addition to the Open message) between the applications.

No, I didn't mean that to be what the term meant.  Where do you think I 
implied that?

>    I consider this just a special case of in-band negotiation.  Clear terminology to separate these cases would be useful since they have very different characteristics.  Perhaps "augmented in-band negotiation" or "hybrid in-band/external negotiation"?
>

There are many ways the application can guarantee correct operation.  
Letting the first side of an external negotiation request the stack 
assign a free id of 'correct' oddness is merely an API helper at the JS 
level; it has no impact on the protocol per se, and the application can 
do it itself (with extra bookkeeping, as I stated).  As such, it's only 
mentioned in the JS API spec, not the IETF drafts.

> The application can also specifically request whether to send the data channel Open message once the SCTP association is established.  It is understood that if the browser does not send the Open me…

This is the external negotiation - both sides tell the stack that a 
channel has been agreed to.   "Agreed to" can be "one side send to the 
other a channel definition, and the second side installs it, completing 
the channel."  It also can be "both sides (same JS app) know a priori 
that channel id 0 is the reliable control channel used for Foo messages, 
and so inform the stack".

> Without going through all the cases again, I think it's fair to say that the situation warrants some additional explanation (in the drafts) to describe these various cases and under what circumstan…

I think the pseudo-code does cover it - as that's also virtually what 
we've implemented (running code and all that). ;-)   The other 
properties discussed emerge from that design and the JS API on top of 
it.  You can see the actual (rather more messy!) code in 
netwerk/sctp/datachannel/DataChannel.cpp in Firefox.  (Need to handle 
failures, requirement to allocate more streams from SCTP, JS interface, 
etc).

Has my discussion above cleared up any of the confusion?  If it has, do 
you have any proposed way to help others avoid that confusion?

Thanks for looking at it before we're at the mics!

     Randell

---

From: Max Jonas Werner <[email-masked]>
Date: Wed, 30 Oct 2013 16:34:36 +0100

> On Tue, Oct 29, 2013 at 10:23 AM, Paul Kyzivat <[email-masked]>wrote:
[...]

> to explicitly catch nefarious man in the middle type scenarios such as this.

Remove the "perhaps" from the sentence in brackets and you got it. If
you want to verify you're communicating with whom you think you're
comunicating you _need_ the identity mechanism that's being standardized
here.

Max

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 30 Oct 2013 13:57:30 -0400

On 10/29/13 4:47 PM, Eric Rescorla wrote:
>
> On Tue, Oct 29, 2013 at 11:59 AM, Paul Kyzivat <[email-masked]
>                       insert itself in the media path, manipulating the
>         SDP such
>                  that the
>                  There is a separate role negotiation for DTLS (actpass,
>         etc.)
>                  that works
>     (I'm not advocating this as a good thing. But if it is possible,
>     there will be someone who wants to do it, and somebody willing to
>     sell them stuff to do it.)
>
>

I'm not certain there is a problem. This just smells like other problems 
that have arisen in the past.

Yes, this attack would require terminating and splicing two SCTP 
associations. Ultimately it comes down to how much work must be done in 
the middle.

So maybe its better to just leave it as hard as possible for 
intermediaries to do so.

	Thanks,
	Paul

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Wed, 30 Oct 2013 20:49:24 +0000

Hi Randell,
Thanks again for your response.

You asked what I thought would help to clear up any confusion around the stream id assignment issue.  I think clearer definitions of the different types of negotiation, and a few more guidelines in the text would be great.  Please correct any of the following suggested guidelines to avoid potential stream id conflicts.

1) For in-band negotiation before establishment of the SCTP association, the application should use only deferred stream id assignment based on DTLS role.  (A little discussion of what this means also wouldn't hurt.)  Otherwise a preselected stream id on one side might conflict with a deferred selection on the other side.
2) For external negotiation before establishment of the SCTP association, the application must select stream ids without waiting for determination of DTLS role.  Both peers need to know the stream id allocated to each data channel via the external negotiation mechanism, so deferred selection cannot be used.
3) Prior to establishment of the SCTP association, if the application has data channels to establish using both in-band and external negotiation, external negotiation data channels should always be created before in-band negotiation data channels.  This allows the protocol to avoid reusing any potentially conflicting stream ids allocated by the external negotiation mechanism.
4) After establishment of the SCTP association, in-band and external negotiation can be freely mixed as long as stream id assignment is based on DTLS role while avoiding already allocated ids.  For application selection of stream ids (rather than protocol selection of stream ids), the application can determine the DTLS role by examining the exchanged SDP messages.

This paraphrases many of the things in your email that aren't yet in the draft.  Some of my confusion was that I was thinking of hybrid negotiation mechanisms to allow application selection of stream ids with in-band negotiation before establishment of the SCTP association, but it's far easier to simply disallow that!

BR, Richard

> Sent: Tuesday, October 29, 2013 9:39 PM
> To: [email-masked]
> I'm definitely not ignoring it.  I'm not specifying what the
> application does in the external negotiation; just how that affects the
> protocol stacks at either end.  See my pseudo-code below, which has the
> advantage of avoiding english vagueries.  I think part of the confusion
> comes from looking/thinking about the JS API, not the IETF protocol.
> 
> > When I refer to in-band negotiation, I mean the use of the data
> channel protocol Open message to inform the peer browser that a
> specific stream id has been allocated to a data channel.
> 
> Agreed.
> 
> > You apparently also use the term "external negotiation" to apply to
> the case where in-band negotiation needs to be augmented with
> additional communication (i.e., in addition to the Open message)
> between the applications.
> 
> >    I consider this just a special case of in-band negotiation.  Clear
> terminology to separate these cases would be useful since they have
> very different characteristics.  Perhaps "augmented in-band
> negotiation" or "hybrid in-band/external negotiation"?
> >
> > The application can also specifically request whether to send the
> data channel Open message once the SCTP association is established.  It
> is understood that if the browser does not send the Open message that
> the peer application must also use its API to create the other end of
> the data channel.
> 
> that channel id 0 is the reliable control channel used for Foo
> messages, and so inform the stack".
> 
> > Please just answer one question: How does the application determine
> its DTLS role (i.e., whether to request even or odd numbers when
> choosing to select stream ids)?  Does this need to be inferred from
> allocated stream ids or can the application determine it directly?
> >
> > Thanks,
> > Richard
> >
> >
> >> Please bear with me a little longer.  I agree that limited
> >> coexistence of application and browser stream id selection is
> >> possible, but it seems that there are some significant restrictions.
> >> selection and browser selection of stream ids can co-exist before
> >> DTLS roles are determined.  If application A selects an odd stream
> >> id, the only way to communicate this selection to application B's
> >> browser is via the in-band open message after the SCTP association
> >> has been established.
> >>
> >> the offer).  Any application using external negotiation must, in
> >> fact, handle external negotiation (even if that 'negotiation' is a
> >> set of hard-coded channel ids).
> >>
> >> own (I'll believe this when I see it, but it might happen).
> External
> >> (We may need to add a line to the IETF drafts to cover this case;
> >> need to check).  The application *could* just scan all known
> channels
> >> channel and requests browser selection of a stream id then B's
> >> browser might end up selecting the same odd stream id, since it has
> >> no way to know to avoid it.  Not unless we reserve id values
> >> exclusively for application selection.  Do you agree?  If so, we
> >> should document this restriction.
> >>
> >> Now application and browser stream id selection can co-exist without
> >> a hitch.
> >> 2)  You can create any number of externally-negotiated channels
> >> before createOffer().  There is no need for them to match DTLS
> roles.
> >>
> >> before creating automatic channels unless the application has made
> >> sure somehow
> >> more, so the point is basically moot. (Note: you don't have to
> >> install the externally-negotiated channels before createAnswer,
> >> though normally I'd suggest doing so, just before creating
> >> automatically-generated
> >> ones.)
> >>
> >> can even mix them, since the automatically-generated ones will be
> >> assigned ids later when DTLS role is known (and will avoid any
> >> already in-use).  I'm not sure this is behavior that anyone would
> >> *need*, so I see no reason to promote mixing in that way - but it'll
> work.
> >>

---

From: Justin Uberti <[email-masked]>
Date: Wed, 30 Oct 2013 17:23:05 -0700

Note also that DTLS role can change during the lifetime of the session
(e.g. a peer that was active can become passive, and vice versa). So we
will need to be more specific about when the role is in fact determined -
perhaps the initial DTLS roles used in the session.

On Wed, Oct 30, 2013 at 1:49 PM, Ejzak, Richard P (Richard) <
[email-masked]> wrote:

> You asked what I thought would help to clear up any confusion around the
> stream id assignment issue.  I think clearer definitions of the different
> types of negotiation, and a few more guidelines in the text would be great.
>  Please correct any of the following suggested guidelines to avoid
> potential stream id conflicts.
>
> 1) For in-band negotiation before establishment of the SCTP association,
> the application should use only deferred stream id assignment based on DTLS
> role.  (A little discussion of what this means also wouldn't hurt.)
>  Otherwise a preselected stream id on one side might conflict with a
> deferred selection on the other side.
> 2) For external negotiation before establishment of the SCTP association,
> the application must select stream ids without waiting for determination of
> DTLS role.  Both peers need to know the stream id allocated to each data
> channel via the external negotiation mechanism, so deferred selection
> cannot be used.
> 3) Prior to establishment of the SCTP association, if the application has
> data channels to establish using both in-band and external negotiation,
> external negotiation data channels should always be created before in-band
> negotiation data channels.  This allows the protocol to avoid reusing any
> potentially conflicting stream ids allocated by the external negotiation
> mechanism.
> 4) After establishment of the SCTP association, in-band and external
> negotiation can be freely mixed as long as stream id assignment is based on
> DTLS role while avoiding already allocated ids.  For application selection
> of stream ids (rather than protocol selection of stream ids), the
> application can determine the DTLS role by examining the exchanged SDP
> messages.
>
> This paraphrases many of the things in your email that aren't yet in the
> draft.  Some of my confusion was that I was thinking of hybrid negotiation
> mechanisms to allow application selection of stream ids with in-band
> negotiation before establishment of the SCTP association, but it's far
> easier to simply disallow that!
>
> BR, Richard
>