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

[Eric Rescorla <[e-mail]>]

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

> Comment at end.
>
>
> On 10/29/13 11:28 AM, Eric Rescorla wrote:
>
>>
>> On Tue, Oct 29, 2013 at 8:23 AM, Paul Kyzivat <[e-mail]
>> <mailto:[e-mail]>**> wrote:
>>     On 10/27/13 5:45 AM, Randell Jesup wrote:
>>         On 10/26/2013 6:30 PM, Paul Kyzivat wrote:
>>
>>                 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
>>             signaling-only B2BUAs that play games with O/A on two legs.
>>
>>         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?
>>
>> There is a separate role negotiation for DTLS (actpass, etc.) that works
>> even if both sides think they are the offerer or answerer.
>>
>
> 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?
>

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

-Ekr