Re: [MMUSIC] DTLS-SRTP client/server role negotiation

[Christer Holmberg <[e-mail]>]

Hi,

>After rereading this and checking 4583, I realize my comment was based
>on a misunderstanding of what BFCP was doing. I thought you were saying
>that BFCP didn't use a=setup, and that the active party for the TCP/TLS
>connection was always the offerer. I see that was wrong - that it uses
>a=setup for that and says that the answer is the TLS server.

Correct. BFCP does use a=setup for the TCP connection establishment. Sorry if I was unclear.

Regards,

Christer





BFCP seems to have arranged its authentication so either end is capable
of being the TLS server, and it is only necessary to have *some*
mechanism for deciding which one will be. As long as that is the case, I
don't have a particular problem with it.

        Thanks,
        Paul

On 5/3/13 2:58 AM, Christer Holmberg wrote:
> Hi Paul,
>
>>> RFC 4572 specifies that the "active" endpoint also takes the role as TLS client. At least MSRP refers to RFC 4572.
>>>
>>> AFAIR, BFCP specifies its own rule, saying that the SDP offerer always act as TLS client - ie it separates the TCP setup from TLS roles - which I think is very good.
>>
>> I think that approach has limitations. What does one do when doing a subsequent o/a, especially in the opposite direction?
>
> Well, I could ask you to look it up in the BFCP RFC, but I doubt you'll find an answer there :)
>
>> And how does one distinguish when in a subsequent o/a you do/don't want to reestablish the connection rather than retaining the existing one?
>
> I would need some more time to think about that, but a few questions that came to my mind:
>
> 1) If the TLS connection already exists, is there a reason to reestablish it to begin with?
>
> 2) Would you need an o/a to reestablish the TLS connection to begin with? Once the roles have been determined (in the initial o/a), can't everything be handled on the TLS layer?
>
> 3) If the TLS connection already exists, is there a reason to renegotiate the TLS roles?
>
> 4) If a subsequent o/a is needed in order to reestablish the connection, and/or renegotiate the TLS roles, could the TLS connection first be terminated on the TLS layer, before the subsequent of/a is sent?
>
> Regards,
>
> Christer
>
>