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

[Randell Jesup <[e-mail]>]

On 10/17/2014 4:00 PM, Wyss, Felix wrote:
>>> 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.


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

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.

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

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.


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

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.


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

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