Subject: [rtcweb] Last Call: <draft-ietf-rtcweb-data-channel-12.txt> (WebRTC Data Channels) to Proposed Standard

From: The IESG <[email-masked]>
Date: Thu, 09 Oct 2014 17:48:36 -0700

The IESG has received a request from the Real-Time Communication in
WEB-browsers WG (rtcweb) to consider the following document:
- 'WebRTC Data Channels'
  <draft-ietf-rtcweb-data-channel-12.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2014-10-23. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   The WebRTC framework specifies protocol support for direct
   interactive rich communication using audio, video, and data between
   two peers' web-browsers.  This document specifies the non-media data
   transport aspects of the WebRTC framework.  It provides an
   architectural overview of how the Stream Control Transmission
   Protocol (SCTP) is used in the WebRTC context as a generic transport
   service allowing WEB-browsers to exchange generic data from peer to
   peer.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-channel/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-channel/ballot/

No IPR declarations have been submitted directly on this I-D.

---

From: "Wyss, Felix" <[email-masked]>
Date: Fri, 10 Oct 2014 19:11:54 +0000

I'm sorry for being a bit late to the party, but I have a concern about section 6.5 allowing use of the DTLS role for picking the SCTP stream identifiers (odd vs. even).   It's an abstraction leak and complicates the implementation of middleboxes.  The DTLS role is determined during the connection establishment, so a middlebox that manages connections with two endpoints to record the media passing through it can't guarantee that one side is the DTLS server and the other the DTLS client because in its offers it is required to specify a=setup:actpass (see RFC#5763).  That means it's at the mercy of the endpoint as to which DTLS role they pick.  Worse, it is desirable for the answerers to pick 'active' as that can speed up the DTLS negotiation.  

I feel it would be better to explicitly require that applications are responsible for identifier collision avoidance instead of allowing them to rely on the DTLS roles. 

Thanks,
--Felix Wyss
Interactive Intelligence, Inc.

> -----Original Message-----
> From: rtcweb [mailto:[email-masked]] On Behalf Of The IESG
> Sent: Thursday, October 09, 2014 20:49
> To: IETF-Announce
> Cc: [email-masked]
> Subject: [rtcweb] Last Call: <draft-ietf-rtcweb-data-channel-12.txt> (WebRTC
> Data Channels) to Proposed Standard
> 
> 
> The IESG has received a request from the Real-Time Communication in WEB-
> browsers WG (rtcweb) to consider the following document:
> - 'WebRTC Data Channels'
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> sent to [email-masked] instead. In either case, please retain the beginning of
> the Subject line to allow automated sorting.
> 
> Abstract
> 
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Martin Thomson <[email-masked]>
Date: Fri, 10 Oct 2014 13:33:46 -0700

> I feel it would be better to explicitly require that applications are responsible for identifier collision avoidance instead of allowing them to rely on the DTLS roles.

Are you suggesting that we might want to consider the effect of a MitM
attack on the robustness of this?

---

From: "Wyss, Felix" <[email-masked]>
Date: Sat, 11 Oct 2014 07:21:26 +0000

I'm not looking at this in terms of MitM attacks but for topologies where we want to have back-to-back WebRTC sessions going through a legitimate middlebox.  That middlebox passes the media and data between these sessions while recording and/or performing analytics on it.  Requiring the middlebox to worry about how the two endpoints might pick SCTP stream identifiers and possibly having to map or rewrite them unnecessarily complicates their implementation.  

IMHO from the perspective of the data channels, the DTLS layer should be an opaque tunnel ("bump in the stack") that passes packets between endpoints.  The DTLS role of an endpoint that emerges during connection establishment should not be relevant to the operation of the data channels.  Hence my concerns about the abstraction leak.  

Thanks,
--Felix

> From: Martin Thomson [mailto:[email-masked]]
> Sent: Friday, October 10, 2014 16:34
> To: Wyss, Felix
> Cc: [email-masked]
> Subject: Re: [rtcweb] Last Call: <draft-ietf-rtcweb-data-channel-12.txt>
> (WebRTC Data Channels) to Proposed Standard
> 
> > I feel it would be better to explicitly require that applications are
> responsible for identifier collision avoidance instead of allowing them to rely
> on the DTLS roles.
>

---

From: Michael Tuexen <[email-masked]>
Date: Sat, 11 Oct 2014 09:41:35 +0200

On 11 Oct 2014, at 09:21, Wyss, Felix <[email-masked]> wrote:

> I'm not looking at this in terms of MitM attacks but for topologies where we want to have back-to-back WebRTC sessions going through a legitimate middlebox.  That middlebox passes the media and data between these sessions while recording and/or performing analytics on it.  Requiring the 
So doesn't it terminate the DTLS connections of both peers?

Best regards
Michael
> middlebox to worry about how the two endpoints might pick SCTP stream identifiers and possibly having to map or rewrite them unnecessarily complicates their implementation.  
>

---

From: tim panton <[email-masked]>
Date: Sat, 11 Oct 2014 10:59:20 +0100

> So doesn't it terminate the DTLS connections of both peers?

Yes, it does. I think the worry is that the middle box may end up as DTLS server to both legs.
That leaves both endpoints as DTLS clients. This then breaks the odd-even split and risks the endpoints allocating
the same stream numbers.

For this to happen you have to have a middle box that offers actpass to both endpoints, agrees to passive 
on both legs and then proceeds to terminate the DTLS but bridge the SCTP. Which only works if it also
re-writes the signalling fingerprints ‘correctly' too.

Tim.

---

From: Michael Tuexen <[email-masked]>
Date: Sat, 11 Oct 2014 17:05:58 +0200

> Yes, it does. I think the worry is that the middle box may end up as DTLS server to both legs.
And why can't the middle box avoid this?
> That leaves both endpoints as DTLS clients. This then breaks the odd-even split and risks the endpoints allocating
I think "risks" is the wrong term here. I guess they will run into this almost always.

Best regards
Michael

---

From: "Wyss, Felix" <[email-masked]>
Date: Sat, 11 Oct 2014 16:58:48 +0000

> And why can't the middle box avoid this?

How can it if it is the offerer on both legs?  From RFC#5763, section 5 (page 10): "The endpoint that is the offerer MUST use the setup attribute value of setup:actpass and be prepared to receive a client_hello before it receives the answer."

The answerer thus gets to pick whether it is the client or server.  As mentioned in my original message, the answerer picking client is desirable as it can speed up the DTLS negotiation.  So almost invariably the middlebox will be DTLS server on both legs.

> > That leaves both endpoints as DTLS clients. This then breaks the
> > odd-even split and risks the endpoints allocating the same stream numbers.

Not necessarily if the endpoints draw their IDs at random.  That makes this particularly problematic as everything may appear to work fine but then fail intermittently in the field due to collisions.  

--Felix

---

From: Michael Tuexen <[email-masked]>
Date: Sat, 11 Oct 2014 19:25:12 +0200

> How can it if it is the offerer on both legs?  From RFC#5763, section 5 (page 10): "The endpoint that is the offerer MUST use the setup attribute value of setup:actpass and be prepared to receive a…
OK, I see.
> The answerer thus gets to pick whether it is the client or server.  As mentioned in my original message, the answerer picking client is desirable as it can speed up the DTLS negotiation.  So almost…
Makes sense.
> Not necessarily if the endpoints draw their IDs at random.  That makes this particularly problematic as everything may appear to work fine but then fail intermittently in the field due to collision…
As far as I know the browsers currently don't use random values. They start from small IDs and increment.
Since your middlebox is terminating DTLS, I think you could also terminate both SCTP associations. But I guess
you want to avoid that. So can't you just rewrite the stream IDs?

Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Sat, 11 Oct 2014 19:30:16 +0200

> you want to avoid that. So can't you just rewrite the stream IDs?
My fault: You can't. Both sides might derive something from the ID locally seen and assume it
is the same on the other end...

Best regards
Michael

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 12 Oct 2014 12:18:24 +0200

Given that the middle box has to:

- decrypt and encrypt all packets (because the keys are different)
- assert its own identity towards both endpoints (because otherwise DTLS
doesn't work)
- be trusted by both endpoints (otherwise it's a MITM attack by definition)
- manage SCTP congestion control independently on the two legs (because
that's how SCTP works)

I don't see the reshuffling of packets between channel numbers to be an
excessive *additional* burden.

The kind of "middle box" that "just shuffles bits" while doing something
to them or with them in addition doesn't exist in the WebRTC context.

-- 
Surveillance is pervasive. Go Dark.

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Sun, 12 Oct 2014 13:23:00 +0000

> to them or with them in addition doesn't exist in the WebRTC context.
[Raju] 
+1.
Also, such a middle box can even go with Out-of-band negotiation (instead of inband DCEP with odd/even rule) 
of stream ids, in which case stream ids are selected by the application and odd/even rule does not apply.

BR
Raju

---

From: Michael Tuexen <[email-masked]>
Date: Sun, 12 Oct 2014 15:30:45 +0200

> excessive *additional* burden.
I agree CPU wise. But I have a question: Don't expect both endpoints of a
data channel to see the same "id" attribute? And isn't this attribute
the stream ID? So can conceptually a middlebox map the streams IDs?

Best regards
Michael

---

From: "Wyss, Felix" <[email-masked]>
Date: Sun, 12 Oct 2014 15:15:39 +0000

> - assert its own identity towards both endpoints (because otherwise DTLS doesn't work)
All these are not relevant with respect to how the SCTP packets get from one WebRTC endpoint to the other.  That's really all the data channels care about.  The rest is opaque to them, assumed a given and the concern of other layers in the WebRTC stack.

> - manage SCTP congestion control independently on the two legs (because that's how SCTP works)
Can you please elaborate on why you believe that's required?  As I understand it, from SCTP's perspective in WebRTC DTLS represents the IP layer.  Doesn't that mean congestion control is strictly above DTLS and SCTP should not care about how many hops its packets go through and whether any of these hops decrypt/re-encrypt the packets or pass them on as-is? 

> I don't see the reshuffling of packets between channel numbers to be an excessive *additional* burden.
I respectfully disagree as it adds unnecessary complexity.  Michael furthermore has made a good argument on why it's not that simple.  To add to his concerns: are we certain that none of the application protocols using the data channels will ever reference stream IDs of one SCTP stream in the data of another SCTP stream?  If that ever were the case, the middlebox would have to understand these application protocols and rewrite the stream data, not just the SCTP packets. 

I furthermore have still not seen a convincing argument for requiring this abstraction leak from the lower level by using the DTLS role for something unrelated to DTLS' purpose.  Whether an endpoint started as server or client is completely irrelevant to the payload data transported over it.  While it may be a seemingly convenient hack to avoid explicit conflict resolution, abstraction leaks like that invariably have unintended consequences--as we can see here.  

> The kind of "middle box" that "just shuffles bits" while doing something to them or with them in addition doesn't exist in the WebRTC context.
Well, then it should.  I presented a use-case of a middlebox that records and/or performs analytics of the WebRTC session media.  That is a common application in VoIP. 

--Felix

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 12 Oct 2014 17:28:17 +0200

> the stream ID? So can conceptually a middlebox map the streams IDs?

The two ends don't see the same identity either, so the middle box is 
not transparent.

The application has to know the middle box is there. So it has to be 
written to deal with differing numbers at the two ends too.

---

From: Michael Tuexen <[email-masked]>
Date: Sun, 12 Oct 2014 18:50:48 +0200

On 12 Oct 2014, at 17:28, Harald Alvestrand <[email-masked]> wrote:

> The two ends don't see the same identity either, so the middle box is not transparent.
OK. So this means that the ID defined in 
http://w3c.github.io/webrtc-pc/#widl-RTCDataChannel-id
doesn't have to be the same on both ends, right? It would be useful
to make that clear in the document. I always assumed that they are the same
on both ends...

Best regards
Michael
> 
> The application has to know the middle box is there. So it has to be written to deal with differing numbers at the two ends too.
> 
> 
>

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 12 Oct 2014 19:46:17 +0200

On 10/12/2014 06:50 PM, Michael Tuexen wrote:
> doesn't have to be the same on both ends, right?

It has to be the same on both ends of the SCTP connection.

It's just that (I think) you can't splice SCTP connections together;
either you terminate them, or you don't.

That's my understanding - YMMV.

>  It would be useful

---

From: Michael Tuexen <[email-masked]>
Date: Sun, 12 Oct 2014 21:50:16 +0200

> It has to be the same on both ends of the SCTP connection.
This means you can't remap the streams. Or am I missing something?

Best regards
Michael

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Mon, 13 Oct 2014 00:29:09 +0000

> This means you can't remap the streams. Or am I missing something?
[Raju] When middle box is in the bearer path each end will see middle box as its peer.
If the DCEP is used then it gets terminated at middle box and re-originated towards 
the other end after necessary stream id mapping.
One way to avoid such mapping is to use external negotiation of stream ids as 
an alternative to inband DCEP.

BR
raju

---

From: "Wyss, Felix" <[email-masked]>
Date: Mon, 13 Oct 2014 17:02:52 +0000

> If the DCEP is used then it gets terminated at middle box and re-
> originated towards the other end after necessary stream id mapping.
> One way to avoid such mapping is to use external negotiation of stream ids
> as an alternative to inband DCEP.

They would only see it as a peer if it were a full B2B user agent.  As an example, in VoIP the endpoints do not consider an SBC as a peer--yet it sits in the middle and may inspect the media passing through it.  

With respect to DCEP: If we already define a protocol for establishing the channels in-band, why not make ID selection and conflict resolution an explicit part of it?  That certainly would beat the IMHO rather distasteful DTLS role hack.

--Felix

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Mon, 13 Oct 2014 17:58:11 +0000

> They would only see it as a peer if it were a full B2B user agent.  As an
> example, in VoIP the endpoints do not consider an SBC as a peer--yet it sits
> in the middle and may inspect the media passing through it.

<Raju>
I agree that from signaling point of view SBCs can be as transparent as possible. 
But from bearer point of view, in majority of the cases SBCs are not transparent and acts as a peer.
Especially when services like NAP/T traversal, transcoding, encryption (DTLS) are involved.
</Raju>

> 
> With respect to DCEP: If we already define a protocol for establishing the
> channels in-band, why not make ID selection and conflict resolution an
> explicit part of it?  That certainly would beat the IMHO rather distasteful
> DTLS role hack.

<Raju>
Id selection is already part of the API.
odd/even rule applies only when createDataChannel () API does not provide an id.
An application can always override this by providing its own id allocation scheme.
e.g.:
- Random id (2^16 unique ids). There is still a chance for glare.
- In case of glare (upon SCTP stream reset) app can try to generate another id.

I am still not convinced of a middle box which terminates DTLS but neither
maps stream ids nor uses external data channel negotiation. IMHO, it has to
do either of those or clients need to have their own explicit management of ids.

So, I am not sure of complicating the DCEP to add conflict resolution is worth it.

</Raju>

BR
Raju

---

From: Peter Thatcher <[email-masked]>
Date: Mon, 13 Oct 2014 12:27:06 -0700

As pointed out by others mentioning "external negotiation", the
application can use any mechanism it wants to choose the stream
identifiers (SIDs).  The even/odd choice is merely the default
behavior there for the convenience of simple applications.  More
advanced applications, such as the kind you are describing with a
middle box, can ignore the default even/odd behavior and choose the
SIDs directly.

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 14 Oct 2014 09:33:33 +0200

> With respect to DCEP: If we already define a protocol for establishing the channels in-band, why not make ID selection and conflict resolution an explicit part of it?  That certainly would beat the…

When rethinking this, I've come to the conclusion that my original
conclusion (that there couldn't possibly be a point in preserving
channel numbers across a relay) was probably wrong. Please consider that
withdrawn.

I now see a tradeoff between allowing such non-mapping boxes (operating
below the SCTP layer but above the DTLS layer in our model) and avoiding
additional complexity (either extending DCEP with glare resolution -
something it was designed to avoid needing - or requiring such boxes to
not use actpass).

I agree that the DTLS hack is ugly. But glare resolution is ugly too.

---

From: "Wyss, Felix" <[email-masked]>
Date: Wed, 15 Oct 2014 04:54:31 +0000

> When rethinking this, I've come to the conclusion that my original conclusion
> (that there couldn't possibly be a point in preserving channel numbers across
> a relay) was probably wrong. Please consider that withdrawn.

Thank you!

> something it was designed to avoid needing - or requiring such boxes to not
> use actpass).
> 

Requiring middleboxes to assert a specific DTLS role instead of using actpass as offerer conflicts with RFC#5763.  That risks incompatibility with endpoints that assume they get the choice as answerer and blindly use active--or weren't tested by their vendor to be DTLS server as answerer and misbehave in other ways.  In our experience, interoperability is already challenging enough with how vendors interpret RFCs liberally and appear to use a "sunny weather" approach to test coverage.  End customers won't take "big vendor X doesn't implement an RFC correctly" as excuse why their system doesn't work properly or won't interoperate.  They paid a lot of money to have a working solution--which then requires hacks and workarounds to make it work somehow.  Abstraction leaks and unexpected dependencies greatly increases the risk of incorrect implementations and bugs.  

Speaking from an implementer's perspective, I thus strongly recommend against codification of conflicting requirements between RFCs and/or dubious dependencies across layers.  

--Felix

---

From: Randell Jesup <[email-masked]>
Date: Fri, 17 Oct 2014 05:38:23 -0400

> something it was designed to avoid needing - or requiring such boxes to

I'll note that not only does it have to sit between the SCTP and DTLS 
layers, but also it has to be the offerer to both sides as well.  While 
certainly there are some use-cases for that, it's by no means the common 
case.  WebRTC applications designed to work with such a midpoint may 
need to fall back on "external" negotiation, perhaps running a short 
sequence at opening time to decide who will get even and odd (assuming 
that both sides actually open channels dynamically).

It means you may not be able to drop such a middlebox (and have it 
initiate offers to both sides) without a cooperative application (or one 
known to have a compatible usage patter) - but likely you need some 
level of known compatibility anyways, or more likely the entity 
deploying the middlebox also deploys or chooses the application - 
especially as we've explicitly said that signaling protocols and 
transmission (i.e. sending the offer, etc) is explicitly not defined by 
the WG, so the middlebox, in order to generate the offers to both sides 
*must* be in bed somehow with the applications - at least to where they 
all agree on signaling.

> I agree that the DTLS hack is ugly. But glare resolution is ugly too.

Quite so.  We had glare resolution in earlier versions. It sucked and 
caused lots of problems, especially with 0-rtt opens.

While DTLS role isn't wonderful, neither was anything else proposed.  
Offerer/answerer status has the same problem.  An SDP parameter would 
allow a middlebox to specify to the endpoints compatible (complementary) 
values; however from a DataChannels perspective, this is almost the same 
as external negotiation if the middlebox and applications are 'matched'.

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

---

From: "Wyss, Felix" <[email-masked]>
Date: Fri, 17 Oct 2014 20:00:17 +0000

> > I now see a tradeoff between allowing such non-mapping boxes
> > (operating below the SCTP layer but above the DTLS layer in our model)
> > and avoiding additional complexity (either extending DCEP with glare
> > resolution - something it was designed to avoid needing - or requiring
> > such boxes to not use actpass).
> 
> I'll note that not only does it have to sit between the SCTP and DTLS layers,
> but also it has to be the offerer to both sides as well. 

This is a problem even if the middlebox is the answerer on one side and the offerer on the other (relay).  As offerer it cannot control what role it will play without violating RFC#5763.  As Indicated in my response to Harald from the 15th, I do not believe allowing the offerer to offer anything but actpass to be a desirable approach.  

> While certainly there are some use-cases for that, it's by no means the common case.  
> WebRTC applications designed to work with such a midpoint may need to fall back on
> "external" negotiation, perhaps running a short sequence at opening time to
> decide who will get even and odd (assuming that both sides actually open
> channels dynamically).
> It means you may not be able to drop such a middlebox (and have it initiate
> offers to both sides) without a cooperative application (or one known to
> have a compatible usage patter) - but likely you need some level of known
> compatibility anyways, or more likely the entity deploying the middlebox also
> deploys or chooses the application - especially as we've explicitly said that
> signaling protocols and transmission (i.e. sending the offer, etc) is explicitly
> not defined by the WG, so the middlebox, in order to generate the offers to
> both sides
> *must* be in bed somehow with the applications - at least to where they all
> agree on signaling.

Well, then why not leave the ID generation and conflict resolution completely up to the application?   That takes the DTLS role hack out of the picture too.  Of course, leaving it to the application how it determines the ID risks that poorly written applications just pick it at random or some other criteria and don't worry about collisions ("well, it worked in my tests").  

> Quite so.  We had glare resolution in earlier versions. It sucked and caused
> lots of problems, especially with 0-rtt opens.
> 
> Offerer/answerer status has the same problem.  

Even the offerer/answerer role would be better than the DTLS role.  At least that would work in the case where the middlebox relays the offer and answer.  I think that's still too limiting as I'd rather allow the middlebox to be offerer on both sides, but I'll take it over the DTLS hack any day :-)

> An SDP parameter would
> values; however from a DataChannels perspective, this is almost the same as
> external negotiation if the middlebox and applications are 'matched'.

If in-band negotiation and collision resolution is not an option, adding an SDP attribute would be my second choice.  If it's not present, use offerer/answerer role. 

Thanks,
--Felix

---

From: Randell Jesup <[email-masked]>
Date: Sat, 18 Oct 2014 14:40:29 -0400

>> but also it has to be the offerer to both sides as well.

So if we use SDP, the issues become one of ensuring the two sides always 
have different values.

For direct calls, no problem (offerer sets mine=x, answerer sets mine=!x)
For direct intermediated calls, the same (offer is just forwarded)

For start-in-the-middle calls (3pcc) the middlebox sends offers to both 
sides, but can use complimentary values:

offer->A mine=x, offer->B mine=!x (makes assumptions about how A and B 
will answer! & likely demands use of TURN server or media gateway)
or
offer->A mine=x,  A->answer mine=!x,  "offer"->B mine=!x, B->answer 
mine=x (and then the middlebox will start a renegotiation if for some 
reason B's answer is incompatible with A's response).  May require some 
careful ICE candidate handling to avoid TURN.

Note: I hate this sort of setup in SDP; it almost guarantees issues when 
you don't have tightly-coupled endpoints and thus know how they'll 
respond to the SDP.

Note that in SIP-land-style you'd generally (always?) do it this way to 
avoid re-negotiation and avoid the tight coupling:

offer->A with no SDP; A->"answer" (really createOffer()), offer->B, 
B->answer, answer->A

(In SIP this would be OFFER->A (null SDP), A->200 OK(offer-SDP), 
OFFER->B(offer-SDP), B->200 OK (answer-SDP), ACK->A (answer-SDP), ACK->B 
(null)

Note here that both sides agree who offered and answered, unlike the 
above, AND I believe that DTLS role use would work.

> This is a problem even if the middlebox is the answerer on one side and the offerer on the other (relay).  As offerer it cannot control what role it will play without violating RFC#5763.  As Indica…

Per above, if it's simply asking the application for an offer, then 
forwarding it, there's no issue: the offer is a true offer, you never 
have to "convert" an SDP offer into an answer or vice versa, and the 
offer will be actpass and roles will be consistent (assuming the 
middlebox isn't trying to intercept/sniff the decrypted DataChannel data).

So, if the middle box uses sip-style "empty offers" (ask the app to make 
an offer), then I think there are no issues with DTLS role.  If it tries 
to avoid the 3-way handshake style, or work with apps that don't 
understand it then there'd be an issue (but in webrtc signaling isn't 
specified, so the middlebox MUST be designed to be compatible with the 
signaling used by the apps).

Also, if the middlebox acts as an "answerer-in-the-middle", DTLS roles 
should work:
A->middlebox offer, B->middlebox offer, middlebox->A answer, 
middlebox->B answer (where the answers are derived from the offer on the 
other side).  This again requires that the two Offers be safely 
transformable by the middlebox into answers without a renegotiation. The 
middlebox would select the roles in the answers to be complimentary.

> Well, then why not leave the ID generation and conflict resolution completely up to the application?   That takes the DTLS role hack out of the picture too.  Of course, leaving it to the applicatio…

As per above, an application can *always* do that, it never has to use 
the DTLS-role-reliant allocations.

Webrtc doesn't specify the signaling side; any middlebox must agree with 
the apps on signaling, and thus you can put requirements on how that 
interaction works.  Inserting a middlebox into existing application 
channels that were not designed for a middlebox at most requires you to 
allow the application to be told to generate an offer, OR for the 
application to use it's own generation/conflict resolution.

What is not possible is to insert a middlebox between arbitrary WebRTC 
apps that are not designed with that in mind, AND to try to initiate 
calls from the "middle" (without the SDP solution). However, initiation 
from the middle in that way is fraught with other issues and need to 
renegotiate after the first pass anyways.

> Even the offerer/answerer role would be better than the DTLS role.  At least that would work in the case where the middlebox relays the offer and answer.  I think that's still too limiting as I'd r…

I disagree that role won't work if the middlebox is just forwarding 
offers and answers - that's what every WebRTC signaling server is doing 
today.   However, as I think you implied, you're also terminating DTLS 
but forwarding SCTP (and media).  This a) implies packet-relay; b) 
implicit decryption of all media at the server (NOTE this is a 
security/privacy/MITM issue).

Still, if A->middlebox (offer) is actpass, and middlebox->B (offer) is 
actpass (and they would be), then B chooses the role, and then when 
forwarding the answer to A the middlebox can choose the same role B 
did.  So I still don't see a problem here....

Also, assuming some bits of my analysis are incorrect, or there are edge 
cases we care about we don't handle (the non-SIP-like start-in-middle 
case), then (and only then) as a working group, we need to decide if 
this is a usecase we support.  Obviously B2BUA's (which this 
more-or-less is) are always possible, at varying levels of ease.  The 
question (partly) is should the protocol be designed to ease the use of 
a B2BUA with datachannels *assuming* it doesn't work per above.

> If in-band negotiation and collision resolution is not an option, adding an SDP attribute would be my second choice.  If it's not present, use offerer/answerer role.

If we *cannot* safely use DTLS role for middlebox cases, and care, then 
we should allow SDP to override the DTLS role (not use the SDP offer 
state as the base).  If an offerer doesn't specify even/odd in the SDP, 
but the answer does specify, then the offerer must use the SDP of the 
answerer to select even/odd (i.e. SDP overrides role).

---

From: "Wyss, Felix" <[email-masked]>
Date: Tue, 21 Oct 2014 07:35:39 +0000

> middlebox isn't trying to intercept/sniff the decrypted DataChannel data).

You are right, that case will work.  I was thinking that the middlebox could treat the first leg as more independent and not having to wait for the answer on the second leg for faster connection establishment.   

> middlebox would select the roles in the answers to be complimentary.

The "empty offer" approach makes more sense in the SIP world because endpoints are rather heterogeneous in their codec support.  It thus allows the middlebox more control over codec selection by being the answerer.  One of the big advantages of WebRTC and its mandatory-to-implement codec is that it safe to simply offer Opus and be done with it.  Having to resort to the "answerer in the middle" approach just so the DTLS roles can be picked is actually another good example of how the DTLS role abstraction leak has unintended consequences and is bad.  

> security/privacy/MITM issue).

Yes, that's the intended use-case: The middlebox is a trusted man-in-the-middle.  In order to record and/or perform analytics on the media flowing through it, it obviously has to decrypt it.  That can only be done by terminating DTLS (and decrypting/re-encrypting SRTP.)    

> a B2BUA with datachannels *assuming* it doesn't work per above.

Without inband ID negotiation or an SDP parameter, an "offerer in the middle" middlebox or B2BUA won't be possible.  I think having the flexibility to use either/any scenario is highly desirable. 

> as
> > If in-band negotiation and collision resolution is not an option, adding an
> SDP attribute would be my second choice.  If it's not present, use
> offerer/answerer role.
> 

Having an SDP parameter that overrides the DTLS role instead of the offer/answer role is fine by me.  As long as there is a way to override ID selection instead of using the DTLS role.  I nevertheless feel an in-band solution that doesn't depend on signaling or lower-level transport state would be better as it minimizes dependencies and localizes the complexity in DCEP.

--Felix

---

From: tim panton <[email-masked]>
Date: Tue, 21 Oct 2014 09:00:40 +0100

> Yes, that's the intended use-case: The middlebox is a trusted man-in-the-middle.  In order to record and/or perform analytics on the media flowing through it, it obviously has to decrypt it.  That…

If the middle box is trusted, only interested in media and known about by the application, then the application should create a separate 
direct data channel only DTLS connection between the endpoints that bypasses the middle box, with a small amount of extra application
effort we remove the need for even more random extra SDP lines. Remember these are programmable endpoints - not dumb SIP devices with fixed behaviours.

Unless the middle box is performing ‘analytics’ on the DC data too, but that isn’t the use-case you mentioned.

Tim.

---

From: "Wyss, Felix" <[email-masked]>
Date: Tue, 21 Oct 2014 20:58:44 +0000

> > Yes, that's the intended use-case: The middlebox is a trusted man-in-the-
> middle.  In order to record and/or perform analytics on the media flowing
> through it, it obviously has to decrypt it.  That can only be done by
> terminating DTLS (and decrypting/re-encrypting SRTP.)
> 
> If the middle box is trusted, only interested in media and known about by
> the application, then the application should create a separate direct data
> channel only DTLS connection between the endpoints that bypasses the
> middle box, with a small amount of extra application effort we remove the
> need for even more random extra SDP lines. Remember these are
> programmable endpoints - not dumb SIP devices with fixed behaviours.
> 
> Unless the middle box is performing 'analytics' on the DC data too, but that
> isn't the use-case you mentioned.

Having to use one of the endpoints to fork the media for recording and analytics is not acceptable for us.  Many of our customers require that all interactions are recorded exactly as they occur between the endpoints.  Often they are required to do that for legal or compliance reasons.  It's actually pretty certain that some of them will want the data streams recorded too.  

--Felix

---

From: Randell Jesup <[email-masked]>
Date: Tue, 21 Oct 2014 18:18:25 -0400

> Having to use one of the endpoints to fork the media for recording and analytics is not acceptable for us.  Many of our customers require that all interactions are recorded exactly as they occur be…

I had a suspicion that this was the intended use-case - and it's a real 
use-case for certain applications/industries.

So, for those applications (remembering that webrtc applications are not 
random external devices, but basically code linked to the usage) just 
either use pre-defined or external negotiation for channel assignments, 
or implement *in the application* allocation-choosing strategy.  Such as:

middlebox: offer to A and B (actpass)
A: accept (active)
B: accept (active)
ok, now both are on the same "evenness"
both statically open (pre-defined) channel 0 always
Both send a random token value
The side with the lower random value is even, and the other is odd
All channel allocations are preceeded by message on channel 0 that 
amounts to an "I'm opening channel N with these params" that takes the 
place of DCEP
Encapsulate this behavior in some simple functions that take the place 
of the default createDataChannel()/etc

There are other solutions of course for glare resolution.  If you want, 
if the two sides chose the opposite evenness, you just leave 
createDataChannel alone.  There are a LOT of ways to deal with this at 
the application level, since the application "should" know it's talking 
to (or may be talking to) a middlebox that will decrypt/forward things.

---

From: "Wyss, Felix" <[email-masked]>
Date: Sun, 26 Oct 2014 23:33:15 +0000

> I had a suspicion that this was the intended use-case - and it's a real use-case
> for certain applications/industries.
> 
> random external devices, but basically code linked to the usage) just either
> use pre-defined or external negotiation for channel assignments, or
> implement *in the application* allocation-choosing strategy.  Such as:
> 
> both statically open (pre-defined) channel 0 always Both send a random
> token value The side with the lower random value is even, and the other is
> odd All channel allocations are preceeded by message on channel 0 that
> place of DCEP Encapsulate this behavior in some simple functions that take
> the place of the default createDataChannel()/etc
> 
> There are other solutions of course for glare resolution.  If you want, if the
> two sides chose the opposite evenness, you just leave createDataChannel
> alone.  There are a LOT of ways to deal with this at the application level, since
> the application "should" know it's talking to (or may be talking to) a
> middlebox that will decrypt/forward things.

My discomfort and objection is with using the DTLS roles--even if it's just as default.  Why can't we either leave it up to the application to allocate the IDs, suggest some "best practice" approaches, or codify one as the preferred?  I don't feel strongly either way.  All I care about here is that we don't use the DTLS role for anything related to DCEP.  DTLS should just be an opaque transport for the endpoints' SCTP packets.  If we leave the DTLS role as default in the RFC, middleboxes have to worry about it because it's part of the standard.  It doesn't matter that the application _can_ use other means.   If it's in the RFC, it is part of an implied interface contract and 3rd party developers and system integrators will expect it to be supported and work as specified.  

Thanks,
--Felix