Re: [bfcpbis] TCP/TLS: Who is TLS server when the connection goes down and is re-established?

[Tom Kristensen <[e-mail]>]

On 01/15/2014 03:27 PM, Christer Holmberg wrote:
> Hi,
>
> I realize the following comes late in the process, and I apologize if it
> has been discussed, but it is related to something which just has
> recently popped up in 3GPP, and it’s not addressed in the draft.

Not too late, since we are still not finished! Anyway, the TCP/TLS 
connection reuse is not altered while extending BFCP to support 
unreliable transport. Any fixes now must be backwards compatible in some 
way. That said and based on what I have seen from different vendors, 
most of them still use TCP (without TLS) :)

So, at least if we are changing anything to solve these issues, we 
should add an informational note indicating this is a change where 
legacy, pure RFC 4582 implementations might differ in behaviour...

By the way: How these issues was solved in 3GPP are along the lines of 
what you propose below?

> Section 7 says the following:
>
> “For a TCP/TLS connection established using an SDP
>
> offer/answer exchange [7], the answerer (which may be the client or
>
> the floor control server) always acts as the TLS server.”
>
> Q1:
>
> Assume the TCP/TLS connection, for whatever reason, goes down.
>
> Now, I assume that whoever endpoint is “active” will most likely try to
> re-establish the TCP connection.
>
> But, if the “active” endpoint doesn’t send an Offer (i.e. it simply
> tries to re-establish the TCP connection based on the previously
> negotiated SDP information), who will act as TLS server? There is no
> Answerer.
>
> One alternative would be to mandate the sending of an Offer when the
> TCP/TLS connection is re-established. Then it would be clear who is
> Offerer, and who is Answerer.
>
> Another alternative would be to say that whoever was previously Answerer
> will act as TLS server.

I'm not too fond of yet another re-INVITE being mandated, so if we will 
fix this issue mandating the previous answerer to be the TLS server 
would be my preference.

> Q2:
>
> Assume there is an Offer/Answer transaction during the session. Now, the
> TCP/TLS connection is not affected by that, but the TLS roles may change
> (if whoever was Offerer in the previous O/A transaction is now Answerer).
>
> I think some wording would be needed about that also.
>
> One alternative is to say that the TLS roles may change, but that
> doesn’t affect the TCP/TLS connection.

A healthy TCP/TLS connection shouldn't be affected at all, should it? 
However, any potential connection re-establishment will need to monitor 
who was the last answerer to do the TLS initiation correctly.

Hopefully I did understand the issue here, and added my 2 zlotys or 
pence or whatever,
-- Tom